MASTER'S THESIS A Java Component User Interface for ... - CiteSeerX

MASTER’S THESIS A Java Component User Interface for the Minstrel Push System Martina Umlauft

December 2000

Advisors: Prof. Mehdi Jazayeri, Dr. Manfred Hauswirth c 2000 Distributed Systems Group

http://www.infosys.tuwien.ac.at/

Abstract This thesis is part of the Minstrel project, an efficient reference implementation of a push system relying on open standards only. Minstrel follows the component model for push systems introduced in [Hau99]. In the push communication model, an information producer announces the availability of certain types of information, an interested consumer subscribes to this information, and the producer periodically publishes the information (pushes it to the customer). This simplifies the discovery of information and provides timely information dissemination. This thesis describes the architecture, design and implementation of the graphical user interface (GUI) for the Minstrel push system. The main goals were usability, flexibility, and extensibility. To meet the goal of usability the graphical design of the GUI is inspired by other well-known applications. Users were integrated into early stages of the design process and their feedback was incorporated into the design. Instead of a monolithic application a general component framework is used to integrate all parts of the application into a “command center”. The command center presents all functions to the user in a uniform way. Existing component technologies are evaluated and found too heavy-weight, so a light-weight and flexible framework architecture is developed. Other Minstrel components such as the protocol engine, the content management system [Hab00], and the wallet [Püh00] are integrated successfully into the framework infrastructure. Also, several components of general use are developed and made available to other developers.

Acknowledgements First of all I would like to thank my parents for making all this possible for me. Thanks to Stefan Haberl and Michael Pührerfellner of the Minstrel development team for the good co-operation. Special thanks to my advisors Manfred Hauswirth and Mehdi Jazayeri for supervising this thesis and always encouraging me in my work. And — last but not least — thanks to Linus Torvalds for an operating system that’s fun to work with.

Druids occupy themselves with the building of large stone circles for computing purposes; these seldom work properly but the druids always take the view that the problems can be solved only by building a much larger and more expensive circle. Sixty-six-megalith circles are now commonplace. [PB97]

Contents 1 Introduction 1.1 Goals and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 3

2 Minstrel Concepts 2.1 Minstrel Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 A typical Minstrel Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Minstrel Terminology and Data Structures . . . . . . . . . . . . . . . . . . . . .

5 5 5 7

3 User Interface Design Criteria

11

4 Component Software in a Nutshell 4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Evaluation of existing Technologies . . . . . . . . . . . . . . . . . . . . . . . .

15 15 15 16

5 User Interaction and Graphic Design 5.1 Application Overview . . . . . . . 5.2 MinstrelDock . . . . . . . . . . . 5.3 Offers . . . . . . . . . . . . . . . 5.4 Channels . . . . . . . . . . . . . 5.5 Search . . . . . . . . . . . . . . . 5.6 Wallet . . . . . . . . . . . . . . . 5.7 Preferences . . . . . . . . . . . . 5.8 The Minstrel Logo . . . . . . . . 5.9 Channel Bookmarks . . . . . . . . 5.10 About . . . . . . . . . . . . . . . 5.11 Exit . . . . . . . . . . . . . . . .

19 19 19 21 23 26 28 28 29 29 30 30

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

6 Architecture 31 6.1 Framework Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2 Installing Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.3 Minstrel Receiver specific Architecture . . . . . . . . . . . . . . . . . . . . . . 34 i

CONTENTS

ii 6.3.1 6.3.2

Components used in the Minstrel Receiver . . . . . . . . . . . . . . . . 34 Component Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Design and Implementation 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 MinstrelDock in Detail . . . . . . . . . . . . . . . . . . . . . 7.3 Installing Components into the MinstrelDock . . . . . . . . . 7.4 Minstrel Receiver Components . . . . . . . . . . . . . . . . . 7.4.1 SimpleMinstrelReceiverComponent . . . . . . . . . . 7.4.2 Offer Component . . . . . . . . . . . . . . . . . . . . 7.4.3 Channel Components . . . . . . . . . . . . . . . . . . 7.4.4 Search Component . . . . . . . . . . . . . . . . . . . 7.4.5 Wallet Components . . . . . . . . . . . . . . . . . . . 7.4.6 Preferences Component . . . . . . . . . . . . . . . . 7.4.7 Customizer Tool Bar Component . . . . . . . . . . . 7.4.8 ComboDemo Tool Bar Component . . . . . . . . . . 7.4.9 MinstrelAboutService and About Tool Bar Component 7.4.10 ContentManager Service . . . . . . . . . . . . . . . . 7.4.11 Protocol Service . . . . . . . . . . . . . . . . . . . . 7.4.12 Viewer Service . . . . . . . . . . . . . . . . . . . . . 7.5 Reusable Components . . . . . . . . . . . . . . . . . . . . . 7.5.1 ClickableLinkTableCellRenderer . . . . . . . . . . . 7.5.2 RightAlignedTableCellRenderer . . . . . . . . . . . . 7.5.3 JTotalField . . . . . . . . . . . . . . . . . . . . . . . 7.6 Service Usage Reference . . . . . . . . . . . . . . . . . . . . 7.7 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

41 41 44 44 46 47 47 50 52 53 54 55 55 56 57 57 57 58 59 60 60 61 61

8 Evaluation and Future Work 67 8.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 8.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Bibliography

72

List of Figures 1.1

Pull vs. Push [FFBL96, IGM 97] . . . . . . . . . . . . . . . . . . . . . . . . .

1

2.1 2.2 2.3 2.4 2.5

Minstrel Architecture Overview . A typical Minstrel Interaction . . . Channels and Vendors in Minstrel Offers and Samples in Minstrel . . Shipments in Minstrel . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6 7 8 8 9

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12

Minstrel Receiver Application Storyboard . . . . . . . . . . . . . . . . . . The MinstrelDock Tool Bar . . . . . . . . . . . . . . . . . . . . . . . . . . The Offer Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Viewer Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Channel Index Window . . . . . . . . . . . . . . . . . . . . . . . . . The Channel Contents Window . . . . . . . . . . . . . . . . . . . . . . . . The Subscribe Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Search Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Search Dialog showing Search Results . . . . . . . . . . . . . . . . . Configuring general Options with the Preferences Dialog . . . . . . . . . . Configuring Channels for automatic Reception with the Preferences Dialog The About Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

20 20 22 23 23 25 26 26 27 28 29 30

6.1 6.2 6.3 6.4 6.5 6.6

Types of Minstrel Receiver Components . . . . . . . . . . . . . Minstrel Receiver Framework Architecture . . . . . . . . . . . Component Interaction for Subscribing to a Channel . . . . . . Component Interaction for Reception and Viewing of a Sample . Component Interaction for Payment and Request of a Shipment . Component Interaction for Reception and Viewing of a Shipment

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

32 32 37 38 39 40

7.1 7.2 7.3 7.4 7.5 7.6

Overview of the MinstrelDock Component Design The MinstrelReceiverComponent Interface . . . . . The MinstrelReceiverService Interfaces . . . . . . MinstrelDock in Detail . . . . . . . . . . . . . . . Installing SVCs and TBCs into the MinstrelDock . Installation Failure due to doubly installing SVCs .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

41 42 43 44 45 46

. . . . .

. . . . .

iii

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

LIST OF FIGURES

iv 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 7.23 7.24 7.25

Installation Failure due to missing SVC . . . . . . . . . . . . . . UML Class Diagramm of SimpleMinstrelReceiverComponent . . UML Class Diagramm of the Offer Tool Bar Component . . . . . UML Class Diagramm of the Tables in the OfferDialog . . . . . . UML Class Diagramm of the Channel Tool Bar Component . . . UML Class Diagramm of the ChannelViewer Service Component UML Class Diagramm of the ChannelMgmt service component . UML Class Diagramm of the Search Tool Bar Component . . . . UML Class Diagramm of the Preferences Tool Bar Component . . UML Class Diagramm of the Customizer Tool Bar Component . . UML Class Diagramm of the Combo Demo Tool Bar Component UML Class Diagramm of About Tool Bar Component . . . . . . . UML Class Diagramm of Content Manager Service Component . UML Class Diagramm of the Protocol Service Component . . . . UML Class Diagramm of the DraftViewer Service Component . . UML Class Diagram of the ClickableLinkTableCellRenderer . . . UML Class Diagram of the RightAlignedTableCellRenderer . . . UML Class Diagram of JTotalField . . . . . . . . . . . . . . . . . Package Diagramm for the Minstrel Receiver GUI . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

47 48 49 49 50 51 52 53 54 55 55 57 58 59 60 61 62 62 64

8.1 8.2

Slashdot.org, a Web based Newspaper . . . . . . . . . . . . . . . . . . . . . . . 69 An improved User Interface for the Minstrel Receiver . . . . . . . . . . . . . . . 70

List of Tables 7.1

SVC Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

v

vi

LIST OF TABLES

Chapter 1 Introduction On the World Wide Web (WWW), typically Customers must actively look for information they are interested in. In this model of distributed information systems the client actively “pulls” information from the server (see upper half of Figure 1.1).

Figure 1.1: Pull vs. Push [FFBL96, IGM 97]

In contrast in a push system customers subscribe to an infrastructure and receive information without any further request (see bottom half of Figure 1.1) – analogous to a subscription of a printed magazine. In push systems content is actively distributed (“pushed”) to customers, whenever it becomes available. Information providers announce the availability and a description of new content in Channels. Providers typically maintain a Catalog of channels, which allows customers to decide which channels to subscribe. This thesis describes an extensible and flexible graphical user interface (GUI) for the Minstrel push system [Hau99]. It is based on the implementations of a protocol engine [Hab00], a content management system [Hab00], a payment component [Püh00] and a remote control facility for Netscape [HJ99]. 1

CHAPTER 1. INTRODUCTION

2

1.1

Goals and Contributions

The main goal of this work is to develop an extensible and flexible graphical user interface for the client side (“Receiver”) of the Minstrel push system. This means that the component implementations mentioned above must be integrated in a way that gives users the feeling of using a single application rather than unrelated components while still retaining the flexibility to exchange or add components. All user interaction with the Minstrel Receiver will be conducted via the GUI. Therefore, it must meet the demands of the users as well as the demands of application programmers who wish to extend the system and of third parties who wish to customize the system. From the user interface design point of view the requirements are: Conformance to standards: The GUI must conform to the Java Look and Feel Guidelines [Mic99]. It should also be similar to other applications the users know from similar domains. Models and mappings: The GUI must provide a good conceptual model of the system. It must support the user by providing natural mappings between intentions and required actions. Accessibility: All important functions should be accessible easily. Seldomly used functions (e.g., certain configuration options) should not get into the way of everyday use. Non-modality: Wherever possible, users should not be locked into modes where they have to “complete” one dialog box first before they can work with the rest of the system again. Instead, users should be able to switch freely between functions (i.e., be able to look something up in another window before confirming a dialog). A detailed description of user interface design goals is provided in Chapter 3. From the application programmer’s point of view the requirements are: Extensibility: The API must provide a simple way to extend the functionality of the Minstrel Receiver. Customizability: The GUI’s appearance must be customizable by third parties, e.g., software resellers who want to change the software to display their company logo. Component Framework: Several existing components must be integrated into a uniform GUI. This also means that some sort of “glue code” must be implemented to support communication between components. A detailed description of these goals is given in Chapter 4. The Java component user interface for the Minstrel push system can be seen as a component framework which integrates and provides communication between several components under a uniform GUI so the user is presented with a single “Minstrel Receiver” application.

1.2. STRUCTURE OF THE THESIS

1.2

3

Structure of the Thesis

Chapter 2 describes the main concepts and terminology of the Minstrel Push System. A full description of the Minstrel Push System can be found in [Hau99]. Chapter 3 gives a short introduction of the principles of user interface design and defines the design criteria applied in this work. Chapter 4 provides an overview of component-oriented software design. The design goals for the component framework developed for this thesis are being defined and existing technologies are evaluated in respect to our project requirements. Chapter 5 presents the graphical design developed for the Minstrel receiver GUI. Underlying design decisions are discussed and compared to the criteria given in Chapter 3. Additionally this chapter can be used as the user’s manual. Chapter 6 describes the component architecture developed for this thesis and compares it to the criteria presented in Chapter 4. Chapter 7 describes the class design. It gives a detailed description of component features and interactions and implementation intricacies. Chapter 8 summarizes the thesis and evaluates it against the goals given in Section 1.1 and Chapters 3 and 4. In additon, an overview of future research areas and optimizations is presented which we have come across during design and implementation.

4

CHAPTER 1. INTRODUCTION

Chapter 2 Minstrel Concepts 2.1

Minstrel Architecture Overview

Abstracting from the transportation hierachy of Minstrel, the Minstrel push system consists of three major components: A Broadcaster, a Receiver, and an optional Payment Server. The Broadcaster contains an Administration Interface, a Content Management System (CMS), a Protocol Engine, and a Receipt Registry. They interact via a Communication Framework. This framework provides peer-to-peer, one-to-one, event based communication. The Receiver is composed of a Graphical User Interface (GUI), the receiver part of the protocol engine, a CMS, and an optional Wallet for payment which also interact via the communication framework. The Payment Server is a seperate entity, which is different for every payment protocol. A payment server must exist for every supported protocol. Figure 2.1 depicts the general architecture and gives an overview of the interaction between the main components: An Information Provider enters new data via the admin interface and triggers the distribtion process (1). An Offer which can contain sample data is sent by the protocol engine to all subscribed receivers (2). At the receiver the GUI presents the new offers to the Customer. He/she chooses the offers he/she is interested in (3). The protocol engine requests the corresponding Shipment from the broadcaster (4) which is returned if available (5). If the shipment must be paid for, the wallet contacts the payment server (a) which conducts the payment on the user’s behalf. The receipt of a successful payment is registered at the broadcaster (b) and returned to the receiver’s wallet (c). This receipt is presented to the broadcaster by the protocol engine together with the request of the shipment.

2.2

A typical Minstrel Interaction

This section details the process introduced above. To be as clear as possible we ommit error conditions, and interaction with the CMS is not shown in detail. 5

CHAPTER 2. MINSTREL CONCEPTS

6

Information Provider

1 Broadcaster Admin Interface

Communication Framework

Payment Server

b

Receipt Registry

Protocol Engine

5

4

CMS

2

a c Wallet

Protocol Engine

CMS

Communication Framework

GUI Receiver 3

Customer

Figure 2.1: Minstrel Architecture Overview As shown in Figure 2.2, the information provider enters new date into the system (an offer with a sample and a shipment) (1). The dissemination process is triggered (2) and the offer is distributed to all subscribed receivers (3). Upon receipt the protocol engine stores the offer in the CMS and notifies the GUI component which is responsible for showing new offers (4). The user decides whether the corresponding shipment should be fetched (5). Two scenarios are possible: First, if the shipment is for free, the protocol engine is instructed directly to fetch the shipment (6). Second, if payment is required, a payment request is issued to the receiver’s wallet (6’) prior to fetching the shipment. In the second case the wallet contacts the payment server to fulfill the payment request (a). The payment server checks, whether the shipment is known to the broadcaster (b) and conducts the payment. After successful payment, the receipt is registered at the broadcaster’s receipt registry (c) and sent back to the receiver’s wallet (d). The wallet notifies a payment listener component (e), which initiates the shipment request (f).

2.3. MINSTREL TERMINOLOGY AND DATA STRUCTURES

7

Information Provider

Broadcaster Admin Interface

2 g

b

Payment Server

Protocol Engine

Receipt Registry

CMS

h

c

8

7

3

Protocol Engine

a d

1

Payment Listener

CMS

f

Protocol Service

e 4

Wallet

6’

9

6

GUI (Offers)

GUI (Shipments) Receiver

5

10

Customer

Figure 2.2: A typical Minstrel Interaction In both cases, the sequence continues with (7): The protocol engine requests the shipment (possibly including the payment’s receipt) at the broadcaster. Free shipments are delivered immediatly. Otherwise, the protocol engine performs a receipt lookup (g) and delivers only paid shipments. Then the receipt registry is informed of successful transmission of the content (h). The registry then may remove the corresponding receipt’s record (this depends on the payment business model; see [Hau99] for details).

2.3

Minstrel Terminology and Data Structures

This section details the terminology and data structures introduced above. An information provider or Vendor offers information Channels to interested customers. Customers can subscribe to these channels. Vendors have a name and are identified by a unique id (Figure 2.3). Channels have a name and a description and are identified by a unique id. Channels are related to vendors by the vendor


8 vendor id (vid) uniquely identifies the vendor related to this channel

Channel Vendor cid: Id channelId: Id vendorId: Id name: String description: String

vendorId

vid: Id name: String

Figure 2.3: Channels and Vendors in Minstrel id. A vendor announces Offers with product Samples (Figure 2.4) in these channels which are then pushed to the subscribed customers. ProductInfo pid: Id name: String version: int mimeTypes: String size: int expires: Date

Agent aid: Id version: int expires: Date mimeTypes: String[] codebaseURL: Url

1 0..1

Offer Cargo cid: Id mimeType: String packing: String description: String contentURL: Url

Sample 0..1

sid: Id subject: String timestamp: Date priority: int

1

oid: Id timestamp: Date vendorId: Id channelId: Id validFrom: Date validTo: Date description: String quantity: int price: double currency: String pyamentUrl: Url receiptRegistrationUrl: Url

Figure 2.4: Offers and Samples in Minstrel A sample has a unique id, a subject, a timestamp, and a certain priority. It contains a single offer describing the business terms and the ProductInfo which describes the promoted product. It may carry a Cargo with sample data (e.g., a thumbnail of a picture or a text excerpt.) An Agent can be provided to process non-standard MIME types. Customers can decide for which offers they want to receive Shipments with the actual product (Figure 2.5.) A shipment is identified by a unique id and has a subject and a timestamp. It is related to the original offer by the uniqe offer id. In contrast to samples a shipment must contain a cargo which contains the product. An agent for handling the cargo can be provided, too. Comprehensive information on samples and shipments and descriptions of all fields can be found in [Hau99] and [Hab00].

2.3. MINSTREL TERMINOLOGY AND DATA STRUCTURES

9

ProductInfo pid: Id name: String version: int mimeTypes: String size: int expires: Date

Agent

offer id (oid) uniquely identifies the offer related to this shipment

aid: Id version: int expires: Date mimeTypes: String[] codebaseURL: Url

1 0..1

Offer Cargo cid: Id mimeType: String packing: String description: String contentURL: Url

Shipment 1

sid: Id subject: String offerId: Id timestamp: Date

1 offerId

Figure 2.5: Shipments in Minstrel

oid: Id timestamp: Date vendorId: Id channelId: Id validFrom: Date validTo: Date description: String quantity: int price: double currency: String pyamentUrl: Url receiptRegistrationUrl: Url

10


Chapter 3 User Interface Design Criteria This chapter gives a short introduction to the principles of user interface design and defines the design criteria used for this work. In [Nor90] Donald Norman argues that design should:

Make it easy to determine what actions are possible at any moment (make use of constraints).

Make things visible, including the conceptual model of the system, the alternative actions, and the results of actions.

Make it easy to evaluate the current state of the system. Follow natural mappings between intentions and the required actions; between actions and the resulting effect; and between the information that is visible and the interpretation of the system state. “In other words, make sure that (1) the user can figure out what to do, and (2) the user can tell what is going on.” [Nor90]

To achive this, the following seven principles of design are given: 1. Use both knowledge in the world and knowledge in the head.1 2. Simplify the structure of tasks. 3. Make things visible: bridge the gulfs of Execution and Evaluation. 4. Get the mappings right. 5. Exploit the power of constraints, both natural and artificial. 1

In [Nor90] using knowledge in the head is refers to relying on a user’s memory. Using knowledge in the world means providing the user with, e.g., visual clues like a label or “obvious” positioning of levers so he/she must memorize less.

11

CHAPTER 3. USER INTERFACE DESIGN CRITERIA

12 6. Design for error. 7. When all else fails, standardize.

Together with more specific design rules given in [Mic99] and [Tog00] the following design goals were deemed most important for the work in this thesis: Standards conformance: The GUI must conform to the Java Look and Feel Guidelines [Mic99] and to the generally expected behaviour of a modern graphical user interface:

Overall application consistency: Since the Minstrel receiver consists of several exchangeable (pluggable) components (see Chapter 6) and its appearance must be customizable special provisions must be made to achieve this goal. Menus must always appear in the same order and a standard “Help” menu must be available. The same user interface elements should be used for the same or similar tasks throughout the application. This should also lead to better code reuse.

The Minstrel receiver consists of many primary windows. If the user opens a lot of other applications it might become difficult to keep track which window belongs to which application. Displaying the application’s name as part of the title of every window can help to prevent confusion. Therefore, all dialogs’ and windows’ titles must be of the form Application Name : Title . To achieve this in a consistent manner across pluggable components a mechanism to provide components with information like the application’s name, version, icon and about dialog has to be developed.

Since our target audience is based in the western hemisphere all dialogs must be created with tab traversal order from top left to bottom right. This corresponds to the reading order in this culture. Important fields or fields which should be filled out first should be placed nearer the top left corner of the dialog. Less important fields which should be filled out after others should be placed nearer the bottom right.

Guideline compliance (to [Mic99]) especially for very basic concepts like being able to confirm a dialog with ENTER or cancel a dialog with ESC . This is extremely important since most people are so used to these features that they will automatically try to use them. The GUI should use design elements the users know from other applications in similar domains. Since Minstrel is a network application the GUI can borrow design elements not only from modern GUI desktop applications but also from web browsers and web pages.

Models and mappings: The GUI must provide a good conceptual model of the system. A good conceptual model enables the users to predict what state changes their actions will cause in the system. This makes users more confident to use the system — because they know what will happen when they initiate an action. It must also support the user by providing natural

13 mappings. Natural mappings put knowledge in the world, thereby making it unnecessary to learn which button to press (e.g. by putting a button that operates on a list right next to the list it operates on). A good conceptual model helps users to choose which action they should take and a good mapping prevents users who know what they want to do from “accidentally hitting the wrong button.” Accessibility: To fulfill design principle 2 – “Simplify the structure of tasks” – tasks can be either narrow2 or shallow.3 Since users are impatient all important functions should be accessible easily (activating the function should be a shallow task). Seldomly used functions (e.g., certain configuration options) should be hidden so they not clutter the interface. Non-modality: Use of modeless dialog boxes wherever possible. Dialog boxes can be modal or modeless. A modal dialog box prevents users from interacting with the application until the dialog box is dismissed. A modeless dialog box does not prevent users from interacting with the application they are in. Users can go back and forth between a modeless dialog box and other application windows. Whenever possible, users should not be locked into modes where they have to “complete” one dialog box first before they can work with the rest of the system again. Instead, users should be able to switch freely between functions (i.e., be able to look something up in another window before confirming a dialog). This also fits the model of pluggable and reusable components better: If a component does not know in which context it will be used it should not block (disturb) the rest of the application if at all possible. According to [Pre94] user-centered system design employs a rapid, iterative design process with comprehensive evaluations and involves the production of a number of intermediate representations of the final artefact. Therefore, a prototype of the interface should be shown to users as early as possible in the design process. User feedback should be incorporated into the next design cycle.

2 3

many steps to go through serially but only few choices at each step many choices but only one or few steps

14

CHAPTER 3. USER INTERFACE DESIGN CRITERIA

Chapter 4 Component Software in a Nutshell This chapter provides an overview of component-oriented software design [Szy99]. The design goals for the component framework developed for this thesis are being defined and existing technologies are evaluated in respect to our project requirements [GT00].

4.1

Definitions

[SP97] defines a software component as follows: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. A component framework can be defined as a software entity that supports components conforming to certain standards and allows instances of components to be “plugged” into the framework [Szy99]. It establishes environmental conditions and regulates interaction between components. A component framework accepts insertion of components at runtime. Components are forced to use the framework to perform certain tasks such as connecting to other components. The framework can control and enforce policies for these tasks.

4.2

Design Goals

The Minstrel receiver was to be developed as a Java application [Inc99]. All parts of the application will execute on a single machine. To run the application on low-end or older computers it has to be as lightweight as possible. To support flexibility and reuse, a component-oriented design instead of a monolithic application was chosen. To connect components either an existing component framework must be deployed or a custom component framework has to be developed. 15

CHAPTER 4. COMPONENT SOFTWARE IN A NUTSHELL

16

4.3

Evaluation of existing Technologies

Two technologies were considered for this thesis: CORBA [Gro98, Gro00b] and JavaBeans [Mic00c, Mic00d, Mic00b].

CORBA CORBA was developed to enable open interconnection of distributed object-oriented systems in different languages running on different plattforms. To achieve this, considerable overhead must be introduced: CORBA uses object request brokers (ORBs) which communicate not on a binary level but via high-level protocols. Objects which want to offer services must register with an ORB via an object adapter. Their interfaces must be specified in a special interface definition language (OMG IDL [Gro00a]) which must then be compiled to create the required stubs and skeletons for remote object access. Clearly this was too heavyweight for the Minstrel receiver which is implemented in only one language. Furthermore, the Minstrel receiver does not need to access distributed components – all components execute on the same machine.

JavaBeans JavaBeans, first introduced in 1996 specify a component model for Java classes. Beans have been designed with a dual usage model in mind: at “design time” bean instances are assembled by an assembly tool such as Sun Microsystems’ BeanBox [Mic00a] and then used at “runtime.” The bean model provides means for beans to find out whether they are used at “design time” or at “runtime” and behave differently in each mode. The main aspects of the bean model are: Events: A bean can announce that it is a potential source of or a listener for specific events. The marker interface java.util.EventListener is used to enable the connection of listeners to event sources by the assembly tool. Properties: Beans expose their properties through pairs of get() and set() methods. Additionally, properties can be bound or constrained. Bound properties trigger a property change event when they change. For constrained properies registered listeners are notified of impending changes and can veto the change. Properties must follow certain naming conventions to be discoverable by the assembly tool. Introspection: A bean can be inspected by an assembly tool to find out about its properties, events, and methods. To support this event and property methods (get(), set() methods) must use standard interfaces and follow strict naming conventions. To use names outside the naming conventions, the bean must implement the java.beans.BeanInfo interface and provide elaborate methods to support querying of properties by the assembly tool. Customization: A bean can be customized by setting its properties via the assembly tool.

4.3. EVALUATION OF EXISTING TECHNOLOGIES

17

Persistence: Customized and connected beans are saved by the assembly tool and reloaded at “runtime”. It would have been very desirable to conform to the JavaBeans specification which would enable usage of the components in application builders. However, several problems led to the decision not to use JavaBeans: first and foremost, the BeanBox, the application builder provided by Sun Microsystems, did not work very stable on our development plattform used (Linux, Kernel Verstion 2.2.13-SMP.) Also, the BeanBox does not support the creation of applications but only of applets. Second, if no assembly tool is used, support for introspection and customization through an assembly tool is not required and thus is unnecessary overhead. Therefore we decided to develop a custom light-weight component framework which only supports installation and deinstallation of components and basic communication services. By assuming that components will be implemented in one language only, execute on the same machine, and know about each other’s features it is possible to omit support for distribution and multiple languages as in CORBA and introspection and customization as in JavaBeans. So a rather light-weight implementation can be achieved.

18

CHAPTER 4. COMPONENT SOFTWARE IN A NUTSHELL

Chapter 5 User Interaction and Graphic Design This chapter presents the graphical design developed for the Minstrel receiver GUI. Underlying design decisions are discussed and compared to the criteria given in Chapter 3. Additionally this chapter can be used as the user’s manual.

5.1

Application Overview

The Minstrel receiver consists of the MinstrelDock framework and plug-in components. The MinstrelDock makes the functions of the Minstrel receiver’s components available to the user. Although the architecture of the Minstrel receiver would allow for on-the-fly installation in this implementation components must be installed by changing a configuration file and restarting the application. MinstrelDock is not limited to the components shipped with the Minstrel project. Since it provides a general communication framework it can be used for arbitrary GUIs and can support any components conforming to the required interfaces. New components which offer novel features can be developed and used transparently to existing components. It is also possible to transparently use existing components with a different implementation of the MinstrelDock (which could use another graphical representation, for example). Thus the appearance and features of the Minstrel receiver GUI can be customized to a very high degree. When the Minstrel receiver is started the MinstrelDock tool bar is presented to the user. From this tool bar the user can open various dialogs and windows: he/she can view and select new offers, manage and open channels, search in the database of received shipments, set his/her preferences, control the electronic wallet, view information about the Minstrel project or exit the application. The storyboard of the Minstrel receiver GUI is shown in Figure 5.1.

5.2

MinstrelDock

The graphical represenstation of this implementation of the MinstrelDock is a tool bar. Figure 5.2 shows the typical Minstrel configuration. 19

CHAPTER 5. USER INTERACTION AND GRAPHIC DESIGN

20

About Dialog

Viewer (Sample)

Offer Dialog

Search Dialog

Search Results

MinstrelDock Tool Bar

Channel Index

Wallet Dialog

Preferences Dialog

Channel Contents

Viewer (Shipment)

Figure 5.1: Minstrel Receiver Application Storyboard

Figure 5.2: The MinstrelDock Tool Bar The tool bar can hold two types of components: Tool bar components: These display a graphical element in the tool bar. Most tool bar components will display a button in the tool bar which will then open a window or dialog. This does not mean that the MinstrelDock is limited to buttons – other GUI elements like labels or combo boxes can be installed as well. Service components: These do not appear in the tool bar but provide services used by other components. A service component can display a window or dialog or be completely invisible to the user. An example of a service component which opens a window is the channel viewer service described in Section 5.4. The protocol service which is used for communication with the broadcaster (see Chapters 6 and 7) is an example of an invisible service.

5.3. OFFERS

21

Tool bar components will appear in the tool bar from left to right in the order of their installation. They can be installed in any order. In the Minstrel case tool bar components are installed in a way so the most often used buttons appear at the leftmost positions according to the reading direction of the intended target audience. The conceptual model we want to represent here is: First, offers are received for which the users must decide if they want to receive shipments. If they decide to receive shipments, these will appear in the respective channel. Therefore, the leftmost button “Offers” opens the offer dialog described in Section 5.3, and the second button “Channels” opens the index of all channels. From this window a channel can be opened and a shipment in that channel can be opened (see Section 5.4). The second important group is placed at the right end of the tool bar to exploit the users’ knowledge about similar applications and because the eye picks up information at the ends of a long tool bar better than in the middle. The “Exit” button (see Section 5.11) is placed at the far right because many users will come from a windows environment where a close button is at the far right of the window’s title bar. It also uses a similar button image. The “About” button (Section 5.10) left to the “Exit” button to correspond to the location of the menu item “about” which is usually found in the help menu which by convention is the rightmost menu. A combo box containing bookmarks of channels (Section 5.9) is placed left to the “About” button. Since a combo box looks very different from a button it still catches the user’s eye even though it is placed closer to the middle. Finally, the least often used components are placed in the middle of the tool bar. From left to right this group consists of the buttons “Search” (Section 5.5), “Wallet” (Section 5.6), and “Preferences” (Section 5.7). The button “Preferences” which is probably used only every once in a while is grouped together with the logo (Section 5.8) at the place that attracts the least attention: the middle of the tool bar.

5.3

Offers

The button “Offers” opens the dialog “New Offers” shown in Figure 5.3. New offers which arrive at the receiver are shown in this dialog. The user can view the samples sent with these offers in another window and choose if he/she wants to receive a shipment of the offered data. The left table “New Offers” shows a list of all new offers to the user. The user can select offers by marking them1 with the mouse. Pressing the “ ” button will then transfer the offer(s) to the fetchlist. Similar to the shopping carts used on many e-commerce sites the fetchlist holds all offers for which a shipment will be fetched. To remove an offer from the fetchlist, the user selects it and presses “ ”. The offer will be returned to the offerlist. More than one offer can be selected at the same time; non-continuous selections (selections with gaps) can be made by pressing Ctrl (as specified in [Mic99]) while selecting. The total size of all offers in the fetchlist is shown in the field “Total Size” below the fetchlist. If the user is satisfied with his/her choice he/she can initiate the retrieval of the shipments by 1

By selecting the row of the table.


22

Figure 5.3: The Offer Dialog clicking the “Fetch!” button. If any of the shipments cost money, the electronic wallet service component is invoked to perform the necessary payment transaction (see [Püh00]). If no wallet service component is installed only free shipments can be requested. The “Close” button will hide the dialog without fetching any shipments. Closing the dialog does not change selections or arrangements in the two lists. Offers which are not fetched are kept in the list of new offers until the user presses the “Clear Offerlist” button. This will discard all offers currently in the list of new offers. The “Help” button opens the help dialog with context sensitive help for the “New Offers” dialog. The “New Offers” dialog and the window for viewing samples (see Figure 5.4) are modeless. The conceptual model here is that new offers arrive and users can choose the offers for which the corresponding shipments will be fetched. There are several criteria on which users base their decision, e.g: The sample data shipped with the offer.

The shipment’s price and size.

The total size of requested shipments: Possibly users want to delay or avoid receiving huge shipments.

These mechanisms support users in coming to a decision: 1. The links in the table are clickable: If the user clicks on the subject of the offer the sample will be shown with the viewer service. A screenshot of the viewer is shown in Figure 5.4. If the viewer window is not yet open it will be opened. To give visual indication of

5.4. CHANNELS

23

clickability the subject is rendered in bold. We assume that users know the concept of clickable links from the web. The “bold” rendering was chosen because Swing does not provide an “underline” font rendering and current web sites now replace underlined links with a bold rendering. The clickable link design element is used to open or view objects throughout the Minstrel receiver application. 2. Shipment size and price are shown in the list of offers. 3. the total size of all shipments to be fetched is shown below the fetchlist.

Figure 5.4: The Viewer Window The design of this dialog was inspired by the popular windows ftp program “WS FTP” by Ipswitch, Inc.[Ips00] Again, reading direction is used to naturally map between source (the list of new offers) and target (the list of offers for which shipments should be fetched). Also for mapping reasons the button “Clear Offerlist” is not grouped with the main command buttons (“Fetch!”, “Close” and “Help”) but with the offerlist it operates on.

5.4

Channels

Channel Index Window The button “Channels” opens the window “Channel Index” shown in Figure 5.5. This window shows all channels and allows the user to open, subscribe, unsubscribe and delete them. The user can also enter or change the description of a channel. To open a channel the user can click on the channel’s title which is a clickable link. To change a channel’s description (eg. if the channel’s title is meaninless or to have some sort of annotation) the user can enter text in the field “Description” by clicking in this field. Conforming to the standard behavior of Swing tables the ESC key cancels changing the field, leaving the field with Enter or the cursor keys will accept the new description. The menu “Channel” contains the following options: Open: If a channel is selected (its table row is marked) it is opened. As described above a channel can also be opened by clicking on its title. Both actions will open the window shown in Figure 5.6.


24

Figure 5.5: The Channel Index Window Subscribe opens the dialog “Subscribe Channel” shown in Figure 5.7 in which the user can subscribe to a new channel. Only if a channel is subscribed offers and (possibly) shipments are received for this channel. Unsubscribe: If one or more channel(s) are selected they are unsubscribed by triggering this action. If a channel is unsubscribed no more offers or shipments will be received in this channel but it will not be removed. Most users will want to keep a channel even if they cancel the subscription. Especially if they had had to pay for the content. This means users can still open the channel and view the already received (old) contents in this channel. The “Delete” command in the menu “Edit” (see below) can be used to remove a channel. Close closes this window. The menu “Edit” contains the following options: Delete deletes selected channel(s). Channels are only deleted only if they are empty to prevent users from accidentally deleting a channel with all its (possibly valuable) contents. This design decision was made because it is a common error among users is to confirm deletion of a wrong file [Nor90]. This occurs because when the confirm dialog appears the user is still confident about the file name and confirms the action rather than the file name. Since accidental deletion of an empty channel is not a costly operation for the user — he/she can simply subscribe to the channel again — no “trashcan for channels” was implemented. Select All selects all channels. Unselect All unselects all channels. The menu “Help” is a standard menu for the Minstrel receiver (it is the same throughout the whole application) and contains the following options: Help shows help for the current window/dialog. Contents shows the table of contents of the help system. Index shows the keyword index of the help system. Search allows the user to search through help texts. About Minstrel shows the about dialog box which provides version and copyright information.

5.4. CHANNELS

25

Contents of Channel Window When a user opens a channel the window “Contents of Channel” shown in Figure 5.6 is opened. This window shows all the shipments in a channel and allows the user to open or delete them.

Figure 5.6: The Channel Contents Window The menu “Object” contains the following options: Open opens the selected shipment. A shipment can also be opened by clicking on its subject. This will show the shipment with in a viewer window as shown in Figure 5.4. If the viewer window is not yet open it will be opened. Close closes this window. The menu “Edit” contains the following options: Delete removes the selected shipment(s). This implementation does not provide a trashcan for shipments. From an UI design viewpoint there should be a way to undo deletion of a shipment, for example, by including a trashcan, since it is a potentially costly operation for the user (see also Chapter 8) if he/she deletes a shipment which had to be paid for. Select All selects all shipments. Unselect All unselects all shipments.

Subscribe Channel Dialog The dialog “Subscribe Channel” shown in Figure 5.7 allows the user to subscribe to a new channel. First, the user chooses a vendor. The user can either choose from the list of known vendors or enter a new vendor name, vendor id and URL. If the user chooses a known vendor, its id and URL are shown automatically. The user then chooses a channel to subscribe. He/she can choose from the list of known channels or enter a new channel name, channel id and description. If the channel is already known (the channel was unsubscribed but not deleted) its id and description will be shown automatically. The user can confirm his/her choice with “OK” to subscribe the channel or cancel the dialog with the “Cancel” button.


26

Figure 5.7: The Subscribe Dialog

Other Issues The windows “Channel Index” and “Contents of Channel” are modeless, the dialog “Subscribe Channel” is modal to prevent race conditions. The conceptual model represented here is selecting objects (a channel, a shipment) from a list to open them. Another way of representing this model would have been a Java JTree in forest mode where the channels are the roots of the tree and channel contents appear on the next level. But we felt that this would clutter the display too much, especially when channels contain many shipments. Also, when using the standard JTree implementation this would leave not much space for additional channel information. Since we considered this and especially the “Description” field to be very important we decided against the use of a tree structure. The design of the subscribe dialog was made under the assumption that users choose channels from a vendor. More specifically, first they must know which vendor they want to subscribe channels from and then choose which channel exactly to subscribe. This is similar to exploring a web site where users know the home address of a vendor and explore the site from there. However, it is quite different to watching TV where the users only know the channel name and do not care who broadcasts the channel.

5.5

Search

The button “Search” opens the modeless dialog “Search” shown in Figure 5.8. This dialog allows the user to perform searches.

Figure 5.8: The Search Dialog The user can enter one or more keywords and select the channel and timeframe to search in.

5.5. SEARCH

27

The search function performs keyword search in the subject and description fields of shipments and their cargo. The user can decide to search all channels or one specific channel and the timeframe can be today, this week, this month, this year, or all. If more than one keyword is entered shipments containing all keywords are searched (AND combination). When the user presses “Search” the search is started. To show the results of the search the original search dialog is expanded and additionally shows a list of matching shipments (Figure 5.9.) Results can be viewed by clicking their subjects which will open the viewer window as described above.

Figure 5.9: The Search Dialog showing Search Results The user can now search in the search results and incrementally narrow the search conditions by entering new keywords and pressing “Search” again. The dialog will remain in this mode until the user clears the result list by pressing the “Clear Results” button. When the user presses “Clear Results” the dialog will shrink to its initial size. A subsequent search will then be performed on the whole database again. The user can temporarily leave the dialog with the “Cancel” button without losing his/her search results — the dialog will remember in which state it was in. We decided to include relatively few options into the search dialog because experiences of Internet search engine operators show that users get overwhelmed by too many options and do not exploit them. Therefore, many search engines on the Internet offer a basic search with few options on their main page and “advanced search” for experienced users only on a sub-page.


28

As with the dialog “New Offers” described in Section 5.3 the “Clear Results” button is grouped with the search results to provide a better mapping.

5.6

Wallet

The Minstrel wallet is outside the scope of this thesis. A Millicent wallet which can be plugged in the Minstrel receiver was developed in another thesis [Püh00] which provides a full description. A general overview of payment in Minstrel can be found in Section 2.

5.7

Preferences

The button “Preferences” opens the dialog “Preferences” shown in Figures 5.10 and 5.11. This dialog allows the user to configure the Minstrel receiver. The “Preferences” dialog may include further configuration options in new releases.

Figure 5.10: Configuring general Options with the Preferences Dialog With the first tab “General” shown in Figure 5.10 the user can configure his/her user id and the host and port of the broker server used for payment. The second tab “Channels” (Figure 5.11) allows the user to configure the channels for which to receive shipments automatically. Since it is cumbersome to process each and every offer manually via the dialog “New Offers” as described in Section 5.3 the user can configure the receiver to request shipments automatically for certain channels. For these channels the offers will not be shown in the dialog “New Offers” and shipments will be automatically requested. Only free shipments can be received automatically.

5.8. THE MINSTREL LOGO

29

Figure 5.11: Configuring Channels for automatic Reception with the Preferences Dialog All changes in all tabs will only be accepted if the dialog is closed with the “OK” button, “Cancel” will discard all changes. The preferences dialog is modal to prevent race conditions. The design of the preferences dialog is analogous to configuration dialogs commonly found in other windows applications. They usually use tabs to separate and group configuration options. Since users might want to re-check the channel when they decide whether to receive shipments automatically the channel contents window can be opened directly from the preferences dialog by clicking on the channel title. This is especially necessary because the preferences dialog is modal which means that users could not press the “Channels” button and choose a channel from there.

5.8

The Minstrel Logo

As described in Section 5.1 the Minstrel receiver’s appearance can be customized by installing other components than buttons into the tool bar. An example for this is the Minstrel logo and application name displayed next to the button “Preferences” in the tool bar (see Figure 5.2).

5.9

Channel Bookmarks

Another example of a non-button tool bar component is the combo box installed next to the Minstrel logo. This combo box provides a bookmark-like shortcut to accessing channels. Selecting a channel from the combo box will open the window “Channel Contents” (see Figure 5.6) for the selected channel.


30

5.10

About

The button “About” opens the dialog box “About” shown in Figure 5.12. This dialog box shows copyright and version information about the Minstrel project. The figure shows Minstrel’s default about dialog box; a software reseller can install a different about service (see Sections 6 and 7) to customize this dialog box.

Figure 5.12: The About Dialog

5.11

Exit

The button “Exit” exits the Minstrel receiver.

Chapter 6 Architecture This chapter describes the component architecture developed for this thesis and compares it to the criteria presented in Chapter 4.

6.1

Framework Architecture

The Minstrel receiver consists of the MinstrelDock framework and plug-in components. The three main functions of the MinstrelDock are: managing installed components;

providing communication between components; and

providing a graphical representation to which components can add their GUI elements and thus become accessible to the user.

MinstrelDock is not limited to the components shipped with the Minstrel project. All components conforming to the required interfaces (described in Chapter 7) can be installed. New components which offer novel features can be developed and used transparently to existing components. It is also possible to transparently use existing components with a different implementation of the MinstrelDock. As described in Chapter 5.2 the graphical represenstation of this implementation of the MinstrelDock is a tool bar. Components can provide a GUI element (usually a button) which is displayed in the tool bar. There are two types of Minstrel receiver components: Minstrel receiver tool bar components (TBCs) and Minstrel receiver service components (SVCs) as shown in Figure 6.1: Tool bar components: These components display a graphical element in the tool bar. Most tool bar components will display a button in the tool bar which will then open a window or dialog. This does not mean that the MinstrelDock is limited to buttons – other GUI elements like labels or combo boxes can be installed as well. 31

CHAPTER 6. ARCHITECTURE

32

MinstrelReceiver ServiceComponent MinstrelReceiver Component MinstrelReceiver ToolBarComponent

Figure 6.1: Types of Minstrel Receiver Components Service components: These components do not appear in the tool bar but provide services used by other service components or tool bar components. A service component can display a window or dialog or can be completely invisible to the user. Service components have a name. under which they are installed in the MinstrelDock. Examples of service components which open a window are: showing the contents of a channel (CHANNELVIEWER service) described in Chapters 5.4 and 7.4.3, showing a shipment (VIEWER service), or conducting payment (WALLET service). The protocol service (PROTOCOL) which is used for communication with the broadcaster (see Chapter 7.4.11) or the content management service (CM, see Chapter 7.4.10) are examples of invisible services. The framework architecture is shown in Figure 6.2. Service Component

Default About Service

NAME

ABOUT

Service Component NAME

Service Component NAME

(3) (2)

MinstrelDock (1)

Tool Bar Component

Tool Bar Component (4)

Tool Bar Component

Figure 6.2: Minstrel Receiver Framework Architecture MinstrelDock manages installed tool bar components and service components in two separate lists. When a component wants to use a service component it requests the service from the MinstrelDock by name (1). If the service is installed MinstrelDock returns a handle of the requested service to the requester (2). Then the components establish a connection and communicate directly (3) without further intervention of the MinstrelDock. The installation process (4) is also managed by the MinstrelDock. A detailed description of component installation is provided in Section 6.2.

6.2. INSTALLING COMPONENTS

33

Service components can be used by tool bar components or other service components. To establish a connection between two tool bar components a different approach is needed since tool bar components are not registered under a name and therefore are not requestable. In this case an intermediary service component is needed. For example, if a tool bar component changes a global state that other tool bar components want to know about, the callback idiom [WB99] could be used. An intermediate service component would act as a server that all interested components can register with. If one component changes the global state it would notify the server which would in turn notify all registered client components via callbacks. In practice, however, tool bar components should not be designed to be used as services but as “end users” of service components which should minimize the need for intermediary services. If the function of a tool bar component is needed by more than one component this function should be designed as a service component and the original tool bar component should be replaced by the implementation of a button (or other graphical element) which simply invokes rather than contains the funtionality. A special case of a service component is the about service. To fulfill the user interface design requirements discussed in Chapter 3 all components need access to the application’s name, version, icon and about message. Therefore, a default implementation of this very basic service is provided by the MinstrelDock. To allow for customization the default about service can be replaced at startup. This architecture fulfills the design criteria defined in Chapter 4: It provides a light-weight framework into which components can be installed and components can discover each other through the framework but must know about each other’s features since no support for introspection is provided. By default no support for components in different languages and distributed components exists. Support for different languages can be introduced easily by writing Java wrappers using JNI [Mic97] for components developed in other languages. Support for distributed components is not necessary since all components used in the application execute on the same machine.

6.2

Installing Components

Service components must be installed before components which need this service. Typically this means that service components which are needed by other service components are installed first1 , service components which are needed by tool bar components are installed next and tool bar components are installed last. When a Minstrel receiver component is installed into the MinstrelDock, the following happens: 1. If the component is a service component MinstrelDock checks if a service with this name is already installed. If so MinstrelDock throws an exception. At any one time only one service with a certain name can be installed. This applies for all services except for the about service which is a special case: MinstrelDock provides a default about service. A 1

especially a replacement for the default about service must be installed before anything else


34

new about service can superimpose the default about service exactly once and only before any other component is installed. 2. Component initialization is invoked by the MinstrelDock. 3. During initialization the component requests services from the MinstrelDock. If the requested services are not installed the component will throw an exception and the installation will fail. 4. If initialization completed successfully MinstrelDock adds service components to an internal HashMap with their name as key. If the component is a tool bar component it is added to a separate internal list and its GUI element is added to the tool bar. When the Minstrel receiver is exited it shuts down all installed components before exiting: 1. All tool bar components are shut down. 2. All services are shut down.

6.3

Minstrel Receiver specific Architecture

While the last two sections discussed the general architecture which could be used to implement practically any application this section provides the details of the architecture and interaction of the Minstrel receiver components.

6.3.1

Components used in the Minstrel Receiver

The Minstrel receiver consists of the MinstrelDock and the following Minstrel receiver components: Offer TBC: The offer TBC provides the button “Offers” shown in Figure 5.2 and the offer dialog shown in Figure 5.3. Chapter 7.4.2 details the design of the offer TBC. The offer TBC is used to present new offers to the user and let him/her request shipments for the offers he/she chooses. Channel TBC: The channel TBC provides the button “Channels” shown in Figure 5.2 and the channel index window shown in Figure 5.5. Chapter 7.4.3 details the design of the channel TBC. The channel TBC displays an index of all channels and allows the user to subscribe, manage and open channels. Search TBC: The search TBC provides the button “Search” shown in Figure 5.2 and the search dialog shown in Figures 5.8 and 5.8. Chapter 7.4.4 details the design of the search TBC. The search TBC allows the user to search shipments in the CM.

6.3. MINSTREL RECEIVER SPECIFIC ARCHITECTURE

35

Wallet TBC: The wallet TBC provides the button “Wallet” shown in Figure 5.2 and a dialog where users can check the balance of their wallet. Minstrel’s wallet was developed in the course of another thesis [Püh00]. Preferences TBC: The preferences TBC provides the button “Preferences” shown in Figure 5.2 and the preferences dialog shown in Figures 5.10 and 5.11. Chapter 7.4.6 details the design of the preferences TBC. The preferences TBC allows the user to configure the Minstrel receiver in a comfortable way. Customizer TBC: The customizer TBC provides the label next to the button “Preferences” shown in Figure 5.2. Chapter 7.4.7 details the design of the customizer TBC. The customizer TBC is used to display a nice logo in the tool bar of the MinstrelDock. ComboDemo TBC: The combo demo TBC provides the combo box shown in Figure 5.2. Chapter 7.4.8 details the design of the combo demo TBC. The combo demo TBC is a bookmark facility that users can use as a shortcut to open channels. About TBC: The about TBC provides the button “About” shown in Figure 5.2. Chapter 7.4.9 details the design of the about TBC. The about TBC uses the ABOUT SVC to display the about dialog box of the MinstrelReceiver. About SVC: The about service provides the following functions under the service name ABOUT: access to application name, version, icon and about dialog box. A detailed description is given in Chapter 7.4.9. Channel viewer SVC: The channel viewer service uses the service name CHANNELVIEWER. It can display the contents of a channel. A screenshot is shown in Figure 5.6 and a detailed description is given in Chapter 7.4.3. Channel management SVC: The channel management service uses the service name CHMGMT. It is used as an intermediary service (as discussed in Section 6.1) to inform interested components of changes in the channel index. A detailed description is given in Chapter 7.4.3. Content manager SVC: The content manager service uses the service name CM. It provides access to the CM database to other Minstrel receiver components. The content manager service is a wrapper for the content management system (CMS) used in Minstrel. A detailed description of the CMS is given in [Hab00]. A description of the service wrapper can be found in Chapter 7.4.10. Payment listener SVC: The payment listener service uses the service name PAYMENTLISTENER. The WALLET SVC notifies this service of the results of payment transcations. If payment was successful, the payment listener service requests the paid shipment from the broadcaster. A detailed description is given in Chapter 7.4.5.


36

Protocol SVC: The protocol service uses the service name PROTOCOL. It provides a communication service with the broadcaster to the Minstrel receiver components. The protocol service is a wrapper for the protocol engine developed in [Hab00]. A description of the service wrapper is given in Chapter 7.4.11. Viewer SVC: The viewer service uses the service name VIEWER. It displays samples and shipments to the user. A screenshot is shown in Figure 5.4. A detailed description is given in Chapter 7.4.12. Wallet SVC: The wallet service uses the service name WALLET. It is used to conduct payment transactions.

6.3.2

Component Interaction

This section presents the main interaction scenarios: 1. subscription of a channel; 2. reception of an offer and request of a free shipment; 3. request of a shipment which must be paid for; and 4. reception and viewing of a shipment. A brief overview of scenarios 2, 3, and 4 was already given in Chapter 2. Subscription of a Channel To subscribe to a channel the channel tool bar component (Channel TBC) uses four service components: the protocol service (PROTOCOL), the content management service (CM), the channel management service (CHMGMT), and the about service (ABOUT.) As described in Section 6.2 the channel TBC requests all required services from the MinstrelDock during installation. The MinstrelDock provides handles to the requested SVCs to the channel TBC. After installation completes successfully the channel TBC requests the application name to use in window title bars and registers as a ChannelChangeListener with the CHMGMT SVC and as a ReceiverListener with the PROTOCOL SVC ((1) in Figure 6.3.) When the user subscribes a channel with the subscribe dialog2 a subscribe request is issued to the PROTOCOL SVC (2) which relays the request to the concerned broadcaster (not shown). In the case the subscription failed at the broadcaster (e.g., the channel does not exist) or an error ocurred step (3) is skipped and an asynchronous error message is issued to the channel TBC (4). In this case the error is displayed to the user who can then decide to re-enter subscription data into the subscribe dialog or cancel the process. 2

Not shown: the CM SVC is used to retrieve information about already known vendors and channels to show in this dialog.


ABOUT

(1)

Channel

(1)

Channel Index

37

TBC

SVC (1) (2)

Protocol Engine

(7)

CHMGMT SVC

(4) (6)

PROTOCOL SVC

Subscribe Dialog

(3) (5)

CMS

CM SVC

Receiver

Figure 6.3: Component Interaction for Subscribing to a Channel If the broadcaster acknowledges the subscription the PROTOCOL SVC uses the CM SVC to insert the subscription into the database (3) and issues an asynchronous acknowledgement message to the channel TBC (4). The channel TBC then uses the CM SVC to insert additional administrative data (5) and finally notifies the CHMGMT SVC of the change in channel index (6). The CHMGMT SVC in turn notifies all registered ChannelChangeListeners of the change (7). In the case of the channel TBC this is the channel index window which updates its display accordingly. Reception of an Offer and Request of a free Shipment Figure 6.4 shows the process of receiving an offer and requesting the according free shipment. One TBC and four SVCs interact in this process: The offer TBC, the protocol service (PROTOCOL), the content management service (CM), the viewer service (VIEWER), and the about service (ABOUT.) All visible components use the about service to get the current application name. The offer TBC registers as ReceiverListener with the PROTOCOL SVC. When new samples are sent by the broadcaster, PROTOCOL stores the sample and the included offer by instructing the CM SVC accordingly (2) and notifies the offer TBC of the new offers via an asynchronous callback (3). The offer TBC updates its display and shows the new offers to the user. The user now decides for which offers he/she wants to request shipments. The user can choose to view the samples


38

ABOUT

(1)

TBC

Offer

SVC (1)

Offer Dialog

(1)

VIEWER

(a)

(3)

Protocol Engine

(4)

PROTOCOL SVC

SVC

(b)

(2)

CMS

CM SVC

Receiver

Figure 6.4: Component Interaction for Reception and Viewing of a Sample distributed with the offers by invoking the VIEWER SVC (a). VIEWER uses the CM SVC to retrieve the samples from the CMS (b). If the user chooses to request free shipments a shipment request is issued to the PROTOCOL SVC (4) which will then relay the request to the broadcaster. Reception of a shipment is described below. Request of a Shipment which must be paid for Request of a shipment which must be paid for is analogous to the request of a free shipment described above except for the following issues: two additional SVCs, the wallet service (WALLET) and the payment listener service (PAYMENTLISTENER) are needed at the receiver side to conduct payment. Steps (1) through (3) in Figure 6.5 are identical to the steps described above. If a user chooses to receive a shipment which must be paid for, the offer TBC uses the CM SVC to retrieve administrative data needed for the payment process (4) and then instructs the WALLET SVC to the conduct payment (5). The WALLET SVC then connects to the payment server (not shown) to pay for the shipment. A detailed description of Minstrel’s wallet and the payment process is given in [Püh00]. Eventually, the WALLET SVC will receive a receipt for successful payment from the payment server. WALLET will then notify the PAYMENTLISTENER SVC via an asynchronous callback (6) which in turn will use issue a shipment request including the receipt to the PROTOCOL SVC (7). Finally, PROTOCOL relays the shipment request to the broadcaster


39

TBC

Offer

(1)

Offer Dialog

Protocol Engine

(3)

PROTOCOL SVC

(7) (5)

WALLET (4)

CMS

SVC

(6)

PAYMENT LISTENER

(2)

SVC

CM SVC

Receiver

Figure 6.5: Component Interaction for Payment and Request of a Shipment (not shown.) If the payment request fails, the WALLET SVCs will eventually inform the PAYMENTLISTENER (6) which will display an error message to the user. Reception and Viewing of a Shipment During reception of a shipment four SVCs interact: the protocol service (PROTOCOL), the content management service (CM), the channel viewer service (CHANNELVIEWER), and the about service (ABOUT.) To view a shipment the channel TBC and five SVCs interact: PROTOCOL, CM, CHANNELVIEWER, ABOUT, and the viewer service (VIEWER). As mentioned before, all visible components (channel TBC, CHANNELVIEWER, VIEWER3 ) request the application name from the ABOUT SVC and then CHANNELVIEWER registers with the PROTOCOL SVC as a ReceiverListener ((1) in Figure 6.6.) When a shipment is received the PROTOCOL SVC uses the CM SVC to store the received shipment in the CMS (2). Then the PROTOCOL SVC informs the CHANNELVIEWER SVC 3

not shown


40

(1)

ABOUT SVC

Channel

TBC

(1)

(1)

Channel Index

Protocol Engine

(b)

CHANNEL VIEWER

(3)

PROTOCOL SVC

Subscribe Dialog

SVC (c)

VIEWER

(4)

SVC

(2)

(d)

(a)

CMS

CM SVC

Receiver

Figure 6.6: Component Interaction for Reception and Viewing of a Shipment via an asynchronous callback of the newly received shipment (3). CHANNELVIEWER checks if the shipment was received in the currently displayed channel – which requires that its display must be updated. In this case, the shipment information is retrieved from the CMS via the CM SVC (4). If the shipment was not received in the currently displayed channel, step (4) is skipped. To view a shipment users use the channel TBC to open the channel index window. The channel TBC uses the CM SVC to retrieve information about the current channel index (a). In the channel index window the user selects which channel to open and the channel TBC uses the CHANNELVIEWER SVC to display the contents of this channel (b). The user can then select which shipment he/she wants to view. The CHANNELVIEWER SVC will then instruct the VIEWER SVC to display the chosen shipment (c). Finally, the VIEWER SVC retrieves the shipment from the CMS via the CM service and displays it.

Chapter 7 Design and Implementation This chapter describes the class design. It gives a detailed description of component features and interactions and implementation intricacies.

7.1

Overview

As described in Section 6 the MinstrelDock is the “control center” of the Minstrel receiver. It provides a communication framework for Minstrel receiver components and makes them accessible to the user. The graphical represenation of the MinstrelDock is a tool bar (see Section 5, Figure 5.2). As shown in Figure 7.1 the MinstrelDock implements the MinstrelDockServices interface and manages a number of MinstrelReceiverComponents.

MinstrelDockServices installComponent(MinstrelReceiver Component) requestService(): MinstrelReceiverService exitMinstrel()

MinstrelDock

1..n

MinstrelReceiverComponent init(MinstrelDockServices) shutdown()

Figure 7.1: Overview of the MinstrelDock Component Design All Minstrel receiver components must implement the MinstrelReceiverComponent interface shown in Figure 7.2. There are two types of MinstrelReceiverComponents: MinstrelReceiverToolBarComponents (TBCs) and MinstrelReceiverServiceComponents (SVCs). 41

CHAPTER 7. DESIGN AND IMPLEMENTATION

42

MinstrelReceiverComponent InitFailedException

throws

init(MinstrelDockServices) shutdown()

Mother of all service interfaces

MinstrelReceiver ToolBarComponent getToolBarComponent():JComponent

MinstrelReceiver ServiceComponent getName():String getVersion():int

Figure 7.2: The MinstrelReceiverComponent Interface TBCs provide some functionality and a GUI element to install into the MinstrelDock tool bar. Usually this GUI element will be a button (which then opens a dialog or window) but it can be any other descendant of JComponent, e.g. a JComboBox or a JLabel. Examples of TBCs are the offer component (button “Offers” and the “New Offers” dialog) or the preferences component (button “Preferences” and “Preferences” dialog) described in Sections 5.3 and 7.4.2. SVCs provide a service for other MinstrelReceiverComponents and have no GUI element in the tool bar. This does not mean that a SVC must be completely invisible. Instead, it can also open a dialog or window when invoked, but it is not directly accessible through the tool bar. This makes sense for components which are used by several TBCs or SVCs or for components which are meaningless to the user if used standalone. Unlike TBCs, SVCs can be completely invisible. Examples of invisible SVCs are the protocol engine and the content manager. SVCs are identified by a unique name. SVCs must implement the MinstrelReceiverServiceComponent interface as shown in Figure 7.3. Typically most TBCs will use SVCs and only some SVCs will depend on other SVCs.

7.1. OVERVIEW

43



MinstrelAboutService

MinstrelChannel Viewer

MinstrelContent ManagerService

pay()

getAppName() getAppVersion()

MinstrelWallet

setChannel()

getAppIcon()

showChannel()

showAboutMessage()

closeChannelViewer()

MinstrelViewer

addPaymentListener() removePaymentListener()

Minstrel PaymentListener

setDisplayobject() showOffer()

returnReceipt()

showShipment()

paymentFailed()

closeViewer()

setCurrentChannel() setCurrentOffer() getChannelIndex() getChannelName() getChannelDescription() setChannelDescription() getVendorName() getVendorId() getBroadcasterURL() getSubscriptionId() getReceiptRegistrationURL() getPaymentURL() getOfferIndex() offerHasShipment() getShipmentSubject() getSampleSubject() getShipmentDate() getOfferDate() getSize() getPrice() getCurrency() getShipmentURL() getSampleURL() searchOffers() deleteOffer() subscribeChannel() deleteChannel() getChannelOfShipment() getCMEngine()

Figure 7.3: The MinstrelReceiverService Interfaces


44

7.2

MinstrelDock in Detail

The design of the MinstrelDock is shown in detail in Figure 7.4. Its graphical representation is a tool bar which in turn contains the GUI elements of installed TBCs.

MinstrelDockServices

ows

thr

InstallFailed Exception

installComponent(MinstrelReceiver Component) requestService():

throws

MinstrelReceiverService

ServiceNotAvailable Exception

exitMinstrel()

JFrame

MinstrelDock

WindowListener

1..n


ActionListener 1

MinstrelAboutService getAppName() getAppVersion() getAppIcon() showAboutMessage()

Figure 7.4: MinstrelDock in Detail MinstrelDock implements the MinstrelDockServices interface. This makes it possible to use other implementations of MinstrelDockServices without having to change any MinstrelReceiverComponents. The MinstrelDock provides a default MinstrelAboutService (see Section 7.4.9) which can be replaced. MinstrelDock manages all installed MinstrelReceiverComponents.

7.3

Installing Components into the MinstrelDock

A MinstrelReceiverMain program creates an instance of MinstrelDock and instances of all desired SVCs and TBCs and installs them into the MinstrelDock. The Minstrel receiver can be customized by changing a configuration file accordingly. A successful install of a SVC and a TBC is shown in Figure 7.5. First the SVC ist installed with MinstrelDock.installComponent(). If no SVC with this name is already installed, MinstrelDock calls the SVC’s init() method. Via init() a component receives a reference to the MinstrelDock so it can invoke its methods later on. The SVC now performs internal initializations, and then requests all SVCs it needs (if any) from the MinstrelDock. If the internal initialization is successful and all service requests are

7.3. INSTALLING COMPONENTS INTO THE MINSTRELDOCK

45

:Minstrel Receiver Main

new The main program creates a new MinstrelDock

... and an SVC

The Dock is given the SVC to install

:MinstrelDock

new

:MinstrelReceiver ServiceComponent

installComponent() checks if SVC with this name is already installed init()

...initializes the SVC

* requestService()

SVC requests other SVCs

adds SVC to internal HashMap SVC install completes successfully the main program creates a TBC

The Dock is given the TBC to install

new

:MinstrelReceiver ToolBarComponent

installComponent() init()

...initializes the TBC TBC requests SVCs

* requestService()

adds TBC to internal list adds GUI element to tool bar TBC install completes successfully

Figure 7.5: Installing SVCs and TBCs into the MinstrelDock

successful init() returns. The MinstrelDock then adds the SVC to an internal HashMap which manages all installed SVCs and returns from installComponent(). After that the main program creates and installs a TBC with MinstrelDock.installComponent(). MinstrelDock calls the TBC’s init() method and the TBC performs internal initializations and service requests as described above. Upon return from init() the TBC is added to an internal list and its GUI element is added to the tool bar. TBCs appear in the tool bar from left to right in the order of their installation. The MinstrelReceiverMain program can then decide to install more MinstrelReceiverComponents or end the installation process. Typically all SVCs will be installed before TBCs are installed. Figure 7.6 shows a failed installation attempt. MinstrelReceiverMain tries to install a SVC with a name of an already installed SVC (tries to install a SVC twice). To keep the design of MinstrelDock simple only one SVC with a certain name can be installed at any one time. An InstallFailedException indicates that the installation failed. Everything said above applies to all SVCs except for the about service with the special name ABOUT. Since the about service provides essential information such as the application name, version number, icon and the about dialog which are needed by every other MinstrelReceiverComponent the MinstrelDock provides a default about service. To support customization MinstrelDock allows to install a customized about service once if no other MinstrelReceiverComponent


46 :Minstrel Receiver Main

The main program creates a new MinstrelDock

new

:MinstrelDock

installs SVCs (not shown)

...later creates a SVC

The Dock is given the SVC to install

:MinstrelReceiver ServiceComponent

new

installComponent() checks if SVC with this name is already installed

SVC already installed

InstallFailedException

[already installed]

Installation fails

Figure 7.6: Installation Failure due to doubly installing SVCs

has been installed yet. This restriction ensures that all components conform to the Look and Feel as described in [Mic99]: For example, every window and dialog box must use the application title in its title string. To meet this requirement the about service can only be replaced before any other component is installed. By having an exchangeable about service, everyone can customize the Minstrel receiver easily. Another example for a failed installation attempt is shown in Figure 7.7. This time installation fails because a component (a TBC or SVC) requests a SVC which is not installed. In this case MinstrelDock will throw a ServiceNotAvailableException. The component can then try to request alternative services, make do without the SVC or throw an InitFailedException. In the latter case, the MinstrelDock will abort installation by throwing an InstallFailedException.

7.4

Minstrel Receiver Components

This section describes the MinstrelReceiverComponents implemented for this thesis. First, a description of the abstract helper class SimpleMinstrelReceiverComponent is given, then the TBCs are described in their order of appearance in the tool bar as shown in Figure 5.2, and then the SVCs are described in alphabetical order.

7.4. MINSTREL RECEIVER COMPONENTS

47

:Minstrel Receiver Main

new The main program creates a new MinstrelDock

:MinstrelDock

:Minstrel Receiver Component

new

... and a component.

installComponent()

The Dock is given the component to install

[is SVC] checks if SVC with this name is already installed init()

...initializes component

* requestService()

component requests SVCs

ServiceNotAvailableException

...which are not available

can try to request alternative SVCs InitFailedException Initialization fails

InstallFailedException

Installation fails

Figure 7.7: Installation Failure due to missing SVC

7.4.1

SimpleMinstrelReceiverComponent

This abstract class was designed to simplify creation of TBCs whose tool bar GUI element is a button (the most common form of a TBC). Figure 7.8 shows this class. SimpleMinstrelReceiverComponent implements the MinstrelReceiverToolBarComponent interface. Its init() method stores the MinstrelDockServices reference in the protected field minstrelDock for use by derived classes. It has a JButton which is returned by getToolBarComponent(). To configure the JButton, button title, icon, command string and tool tip string can be passed to the constructor of SimpleMinstrelReceiverComponent. A SimpleMinstrelReceiverComponent also registers itself as ActionListener for its JButton but does not implement actionPerformed(). A TBC with a JButton GUI element can be created by inheriting from SimpleMinstrelReceiverComponent, configuring the button’s appearance via the constructor and implementing the actionPerformed() method of the ActionListener interface. All JButton TBCs developed for this thesis use this approach.

7.4.2

Offer Component

Package at.ac.tuwien.minstrel.receiver.gui.offers contains the offer TBC. It provides an OfferButton and an OfferDialog as shown in Figure 7.9. As described in Section 5.3 the OfferButton opens the OfferDialog when pressed. OfferDialog provides two tables where the user can choose for which of the new offers he/she wants to


48


MinstrelReceiver ToolBarComponent

getToolBarComponent():JComponent

1

JButton

ActionListener

SimpleMinstrel ReceiverComponent {abstract} minstrelDock: MinstrelDockServices;

Figure 7.8: UML Class Diagramm of SimpleMinstrelReceiverComponent request shipments. The design of the table structure is shown in Figure 7.10 (class JTotalField which displays the total size and price of the shipments to fetch is described in Section 7.5.3.) OfferTableModel and FetchTableModel manage the entries displayed in the offer list and the fetch list respectively. FetchTableModel implements SummableTableModel. As shown in Figure 7.24 JTotalField registers as a TableModelListener for a certain column and is informed of table changes. If a table change occurs it uses SummableTableModel’s getTotal() method to get the total value of the column it listens to. The Offer TBC needs the following SVCs:

ABOUT

CM

PROTOCOL

VIEWER

WALLET (optional, if no wallet service is installed only free shipments can be requested)


49

SimpleMinstrel ReceiverComponent

1

JButton

{abstract} minstrelDock: MinstrelDockServices;

JDialog

OfferToolBar Component

OfferDialog

JTotalField

1

2

actionPerformed()

1

1

OfferTableModel

FetchTableModel

Figure 7.9: UML Class Diagramm of the Offer Tool Bar Component

TableModel

TableRowManipulator removeRow() removeRows() addRow() addRows() removeAllRows()

IDSupplier AbstractTableModel

SummableTableModel

getObjectIDAt() getTotal():Object

getObjectTitleAt()

{abstract}

OfferTableModel

FetchTableModel

Figure 7.10: UML Class Diagramm of the Tables in the OfferDialog


50

7.4.3

Channel Components

Package at.ac.tuwien.minstrel.receiver.gui.channel contains three components: the Channel TBC, the ChannelViewer SVC and the ChannelMgmt SVC. Channel TBC The Channel TBC provides a ChannelButton, a ChannelIndex, and a SubscribeDialog as shown in Figure 7.11. ChannelIndex is an index of all channels the user is subscribed to. The channels’ titles are clickable. The class ClickableTableCellRenderer which is used to detect these clicks is described in Section 7.5.1 . If a user clicks a title the ChannelViewer SVC displays the contents of that channel. ChannelIndexTableModel manages the entries displayed in the channel index table. As shown in Figure 7.22 the ClickableLinkTableCellRenderer triggers the registered ActionListener. This ActionListener uses the IDSupplier interface to get the title and id of the channel in the table row which was clicked from the table model. SubscribeDialog allows the user to subscribe to / unsubscribe from channels. 1


JButton

{abstract} minstrelDock: MinstrelDockServices;

JFrame

ChannelToolBar Component

ChannelIndex

1

JDialog

WindowListener

1

SubscribeDialog

actionPerformed()

1

AbstractTableModel {abstract}

ChannelIndexTableModel

IDSupplier getObjectIDAt() getObjectTitleAt()

Figure 7.11: UML Class Diagramm of the Channel Tool Bar Component The Channel TBC needs the following SVCs:

ABOUT

CHANNELVIEWER

CHMGMT

CM


51

PROTOCOL

ChannelViewer SVC The ChannelViewer SVC is an implementation of the MinstrelChannelViewer interface (Figure 7.12.) Its service name is CHANNELVIEWER. ChannelViewer displays the contents of a channel in a JTable. The subjects of the objects in the channel are clickable: If a user clicks them the object is displayed with the viewer service that was installed into the MinstrelDock. As described above the IDSupplier interface is used by the ActionListener registered with the ClickableTableCellRenderer to determine the title and id of clicked the shipment.

MinstrelChannelViewer

MinstrelReceiver ServiceComponent

setChannelTitle() getObjectIDAt()

showChannel()

getObjectTitleAt()

closeChannelViewer()

ChannelViewer

1

ChannelViewerTableModel

JFrame

IDSupplier

setChannel()

WindowListener

AbstractTableModel {abstract}

Figure 7.12: UML Class Diagramm of the ChannelViewer Service Component The ChannelViewer SVC needs the following SVCs:

ABOUT

CM

VIEWER

ChannelMgmt SVC The ChannelMgmt SVC is an implementation of the MinstrelChannelMgmtService interface (Figure 7.13). Its service name is CHMGMT. ChannelMgmt acts as an intermediary SVC to communicate changes in the channel index to all interested components (usually several TBCs). Components interested in changes in the channel index can register themselves as ChannelChangeListeners with the ChannelMgmt SVC. If a component changes the channel index it must call the service method fireChannelIndexChanged(). ChannelMgmt SVC will then notify all registered components of the change.


52



MinstrelChannelMgmtService addChannelChangeListener() removeChannelChangeListener() fireChannelIndexChanged()

ChannelMgmt

1..n

MinstrelChannel ChangeListener channelIndexChanged()

Figure 7.13: UML Class Diagramm of the ChannelMgmt service component

7.4.4

Search Component

Package at.ac.minstrel.receiver.gui.search contains the Search TBC. Its class design is shown in Figure 7.14. It consists of a SearchButton and a SearchDialog. As described in Section 5.5 the dialog initially consists only of a JTextfield where the user enters his/her search keywords and some JComboBoxes to select the channel and timeframe to search (see Figure 5.8) in. Searches are performed in shipments’ subject and description fields (Shipment.subject and Shipment.Cargo.description, Figure 2.5). If the user enters more than one keyword, the keywords are connected logically with AND. If matches are found the SearchDialog expands and shows the search results in a JTable managed by SearchResultTableModel (see Figure 5.8). Consecutive searches are performed on the search results until the results are cleared by the user (incremental search.) Clearing the results also closes the lower part of the dialog. The Search TBC needs the following SVCs:

ABOUT

CM

VIEWER


1

JButton

53


JDialog

SearchToolBar Component

SearchDialog 1

actionPerformed()

1

SearchResultTableModel

Figure 7.14: UML Class Diagramm of the Search Tool Bar Component

7.4.5

Wallet Components

The wallet component consists of two services and a wallet TBC: Wallet SVC implements the MinstrelWallet interface shown in figure 7.3. Its SVC name is WALLET. A full description of Minstrel’s wallet service is given in [Püh00]. The Wallet SVC needs the following SVCs:

PAYMENTLISTENER

Payment listener SVC implements the MinstrelPaymentListener interface shown in Figure 7.3. Its SVC name is PAYMENTLISTENER. The payment listener SVC needs the following SVCs:

PROTOCOL

Wallet TBC is a tool bar component which provides a wallet button and a dialog in which users can check their accounts and can configure the wallet. A full description of Minstrel’s wallet is given in [Püh00]. The Wallet TBC requires the following SVCs:

ABOUT WALLET

Upon installation the Wallet SVC requests a payment listener SVC and installs it with addPaymentListener(). When the user selects a non-free offer in the OfferDialog (see Figure 5.3) the wallet service’s pay() method is called. All payment transactions are then conducted by the wallet service as described in [Püh00]. When payment is completed, the wallet service notifies the payment


54

listener service via the returnReceipt() method. If a payment fails paymentFailed() is called. Upon successful payment the payment listener service initiates the request of the paid shipments.

7.4.6

Preferences Component

Package at.ac.minstrel.receiver.gui.preferences contains the Preferences TBC. Its class design is shown in Figure 7.15.

1

JButton


JDialog

JPanel

ReceiverListener 1

PreferencesToolBar Component

UserPanel

PreferencesDialog 1

actionPerformed()

1

ChannelPanel

1

ChannelTableModel

Figure 7.15: UML Class Diagramm of the Preferences Tool Bar Component It consists of a PreferencesButton and the PreferencesDialog. PreferencesDialog contains several JPanels in a JTabbedPane. UserPanel shows settings about the user. ChannelsPanel allows the user to select the channels for which to request shipments automatically (see Section 5.7). The Preferences TBC registeres as a ReceiverListener with the protocol service. When a sample arrives, the sampleReceived method is called. If the channel in which the sample was received is set for automatic receive sampleReceived returns true, thereby instructing the protocol service to automatically fetch the corresponding shipment. The Preferences TBC needs the following SVCs:

ABOUT

CHANNELVIEWER

CHMGMT

CM

PROTOCOL


7.4.7

55

Customizer Tool Bar Component

Package at.ac.minstrel.receiver.gui.demo contains the Customizer TBC. The Customizer TBC displays a JLabel with the application name and icon in the tool bar. It uses the about service described in Section 7.4.9 to get the application name and icon. Its class design is shown in Figure 7.16. By installing another about service it is possible to customize the appearance of the Minstrel receiver.


JLabel

CustomizerTool ToolComponent actionPerformed()

Figure 7.16: UML Class Diagramm of the Customizer Tool Bar Component The Customizer TBC needs the following SVCs:

7.4.8

ABOUT

ComboDemo Tool Bar Component

Package at.ac.minstrel.receiver.gui.demo contains the ComboDemo TBC. Its class design is shown in Figure 7.17. The ComboDemo TBC displays a JComboBox containing all channel names in the tool bar. When a channel is selected it displays this channel with the CHANNELVIEWER service described in Section 7.4.3.


JComboBox

ComboDemoTool ToolComponent actionPerformed()

Figure 7.17: UML Class Diagramm of the Combo Demo Tool Bar Component The ComboDemo TBC needs the following SVCs:


56

CHANNELVIEWER

CHMGMT

CM

7.4.9

MinstrelAboutService and About Tool Bar Component

According to [Mic99] windows and dialogs should display the application’s name in their title string. To support easy customization the application name must not be hard coded. Instead, MinstrelReceiverComponents are required to request the application name from a SVC with the name ABOUT. This SVC implements the MinstrelAboutService interface as shown in Figure 7.3 and provides the following information: application name;

application version;

application icon; and

a method to display the about message (usually a dialog containing some information on the development team and maybe an easter egg1 ).

These values must not be hardcoded in any MinstrelReceiverComponents or the MinstrelDock itself but must be requested from the about service. E.g., if a component wishes to display the about dialog it must not open a dialog box itself but rather do the following: 1. request a reference to the SVC with the name ABOUT from the MinstrelDock 2. call MinstrelAboutService.showAboutMessage() Since the about service is so basic that it is needed by virtually every other MinstrelReceiverComponent the MinstrelDock provides a minimal default about service. Unlike other services this service can be exchanged (see also Section 7.3). The MinstrelDock will accept a one-time installation of an alternative SVC with the name ABOUT if and only if no other MinstrelReceiverComponent has been installed before. The reason for this restriction is to prevent inconsistencies. Installing an alternative about service will change application title, version, icon and appearance of the about dialog box consistently throughout the whole Minstrel receiver. The package at.ac.minstrel.receiver.gui.demo contains the About TBC shown in Figure 7.18. The About TBC provides an AboutButton for MinstrelDock’s toolbar. This button simply calls the MinstrelAboutService.showAboutMessage(). The About TBC needs the following SVCs:

1

ABOUT

I.e., a small hidden program which performs an amusing gimickry function that can be called by pressing a secret key combination.


1

JButton

57 SimpleMinstrel ReceiverComponent {abstract} minstrelDock: MinstrelDockServices;

AboutToolBar Component actionPerformed()

Figure 7.18: UML Class Diagramm of About Tool Bar Component

7.4.10 ContentManager Service

Package at.ac.tuwien.infosys.minstrel.receiver.gui.cm contains CMService, an implementation of the MinstrelContentManagerService interface (Figure 7.19.) CMService is an SVC with the name CM. It is a wrapper for the content management system described in [Hab00]. The ContentManagerService provides high-level access to at.ac.tuwien.infosys.minstrel.da The ContentManager SVC needs no other SVCs.

7.4.11 Protocol Service Package at.ac.tuwien.infosys.minstrel.receiver.gui.demo contains ProtocolService, an implementation of the MinstrelProtocolService interface (Figure 7.20.) ProtocolService is an SVC with the name PROTOCOL. It is a wrapper for the protocol engine (Receiver) described in [Hab00]. Since Receiver supports only one ReceiverListener and SecurityListener, ProtocolService registers itself as ReceiverListener and SecurityListener, acting as an event adapter: Other components who wish to act as ReceiverListener or SecurityListener can register with ProtocolService which will notify all registered listeners. The classes Receiver, ReceiverListener and SecurityListener are described in [Hab00] and are contained in the package at.ac.tuwien.infosys.minstrel.receiver2. The Protocol SVC needs the following SVCs:

CM

7.4.12 Viewer Service Package at.ac.tuwien.infosys.minstrel.receiver.gui.demo contains DraftViewer, an implementation of the MinstrelViewer interface. DraftViewer is an SVC with the name VIEWER (Figure 7.21.) It uses a JEditorPane to display the cargo of samples and shipments.


58



MinstrelContent ManagerService setCurrentChannel() setCurrentOffer() getChannelIndex() getChannelName() getChannelDescription() setChannelDescription() getVendorName() getVendorId() getBroadcasterURL() getSubscriptionId() getReceiptRegistrationURL() getPaymentURL() getOfferIndex() offerHasShipment() getShipmentSubject() getSampleSubject() getShipmentDate() getOfferDate() getSize() getPrice() getCurrency() getShipmentURL() getSampleURL() searchOffers() deleteOffer() subscribeChannel() deleteChannel() getChannelOfShipment() getCMEngine()

ContentManager

1

CMService

sharedInstance() init() shutdown() store() retreive() query() remove() getOverwrite() setOverwrite()

Figure 7.19: UML Class Diagramm of Content Manager Service Component This draft viewer will be replaced with the NRCF facility [HJ99] in a future version of the Minstrel receiver (see Chapter 8.) The Viewer SVC needs the following SVCs:

7.5

ABOUT

Reusable Components

Some of the classes and interfaces developed for Minstrel are of general use. They were made available to the public as standalone programs by submitting them to http://codeguru.com. These classes are packaged in the at.ac.tuwien.infosys.minstrel.general package.

7.5. REUSABLE COMPONENTS

59



MinstrelProtocol Service addReceiverListener() removeReceiverListener() addSecurityListener() removeSecurityListener()

ReceiverListener

subscribe() unsubscribe()

Receiver

requestShipment() sampleReceived() shipmentReceived()

subscribe() subscriptionAck() unsubscribe() error() requestShipment() shutdown()

ProtocolService

1 getMrrpClient() getMadpServlet()

SecurityListener

getContentManager() madpAuthorize() madpNotify()

authorize() mrrpSubscribeAck() mrrpUnsubscribeAck() mrrpShipment() mrrpSample() mrrpSampleAuthorize() mrrpError()

Figure 7.20: UML Class Diagramm of the Protocol Service Component

7.5.1

ClickableLinkTableCellRenderer

ClickableLinkTableCellRenderer is a custom renderer for JTable objects which can display cells containing strings (see Figure 5.5, first column of the table.) ClickableLinkTableCellRenderer provides a click-on link: users can click on the cell and some action (e.g., opening a window) is performed. ClickableLinkTableCellRenderer’s class design is shown in Figure 7.22. To decouple the action from the cell renderer implementation the ActionListener interface is used: First an ActionListener is registered with ClickableLinkCellRenderer. When the user clicks on the cell an ActionEvent is sent to the registered ActionListener. This ActionEvent contains the following information:

a reference to the JTable in which the click occured;


60



MinstrelViewer setDisplayobject() showOffer() showShipment()

JFrame

closeViewer()

DraftViewer

1

JEditorPane

Figure 7.21: UML Class Diagramm of the DraftViewer Service Component

the column; and

the row.

The ActionListener can then start any action, e.g., pop up a window. To provide visual feedback for the user, the cells are rendered in bold in Java’s MetalLookAndFeel Primary1 color2 . ClickableLinkTableCellRenderer is used in several tables throughout the Minstrel receiver.

7.5.2

RightAlignedTableCellRenderer

RightAlignedTableCellRenderer is a custom renderer for JTable objects which displays right aligned cells (see Figure 5.6, price column.) RightAlignedTableCellRenderer’s class design is shown in Figure 7.23.

7.5.3

JTotalField

JTotalField is shown in Figure 7.24. 2

RGB Hex #666699 as described in [Mic99]

7.6. SERVICE USAGE REFERENCE

61

JTable

*

TableCellRenderer getTableCellRenderer Component():Component

MouseListener

ClickableLinkTableCellRenderer

1

ActionListener

mouseClicked() actionPerformed()

paint()

e.g.

ChannelView

Figure 7.22: UML Class Diagram of the ClickableLinkTableCellRenderer It is a read-only descendant of JTextField which is used to display the sum of a table’s column assuming the table contains data for which addition makes sense. This requires that the table has a SummableTableModel. JTotalField registers with the SummableTableModel and listens to TableModelEvents for changes. If the model changes it inquires the SummableTableModel for the new total value of the column and displays it. JTotalField is not dependant on the type of value (int, double,...); it can display any type that supports a meaningful toString() method. The string which is displayed if getTotal() returns null (e.g., if the table is empty) can be defined in the constructor. If no string is given "" is used. JTotalField is used in the OfferDialog of the Minstrel receiver.

7.6

Service Usage Reference

Table 7.1 shows which SVCs are used by which TBCs and SVCs.

7.7

Packages

The Minstrel receiver GUI is packaged as at.ac.tuwien.infosys.minstrel.receiver.gui, classes of general use described in Section 7.5 are packaged in at.ac.tuwien.infosys.minstrel.ge


62

JTable

*

TableCellRenderer getTableCellRenderer Component():Component

JLabel

RightAlignedTableCellRenderer paint()

Figure 7.23: UML Class Diagram of the RightAlignedTableCellRenderer

JTextField

TableModelListener tableChanged()

JTotalField 1

SummableTableModel getTotal():Object

Figure 7.24: UML Class Diagram of JTotalField Figure 7.25 shows the packages of the receiver GUI. ...minstrel.receiver.gui: contains the main classes and interfaces (IF.) MinstrelAboutService (IF) MinstrelChannelChangeListener (IF) MinstrelChannelMgmtService (IF) MinstrelChannelViewer (IF) MinstrelContentManagerService (IF) MinstrelDockServices (IF) MinstrelPaymentListener (IF) MinstrelProtocolService (IF) MinstrelViewer (IF) MinstrelWallet (IF) MinstrelReceiverComponent (IF) MinstrelReceiverToolBarComponent (IF) MinstrelReceiverServiceComponent (IF)

7.7. PACKAGES

TBCs Offer Channel Search Wallet Preferences Customizer ComboDemo About SVCs ABOUT CM PROTOCOL CHMGMT CHANNELVIEWER VIEWER WALLET PAYMENTLISTENER

63 ABOUT

CM

PROTOCOL

CHMGMT

CHANNEL VIEWER

X X X X X X

X X X

X X

X

X

VIEWER

WALLET

X

X

PAYMENT LISTENER

X X

X

X

X

X

X

X

X

X X X X

X X

X X X

Table 7.1: SVC Usage MinstrelDock InitFailedException InstallFailedException ServiceNotAvailableException SimpleMinstrelReceiverComponent ...minstrel.receiver.gui.channel: Channel components. ChannelToolBarComponent, Channel24.gif ChannelIndex ChannelIndexTableModel SubscribeDialog ChannelMgmt ChannelViewer ChannelViewerTableModel ...minstrel.receiver.gui.cm: Content manager component. CMService ...minstrel.receiver.gui.offers: Offer component. OfferToolBarComponent, Offer24.gif OfferDialog OfferTableModel FetchTableModel ...minstrel.receiver.gui.preferences: Preferences component. PreferencesToolBarComponent, Preferences24.gif


64

at.ac.tuwien.infosys.minstrel.receiver.gui MinstrelDock

at.ac.tuwien.infosys. minstrel.general


channel Minstrel SVC interfaces, Exceptions

cm

demo

offers

preferences

search

tools

Figure 7.25: Package Diagramm for the Minstrel Receiver GUI PreferencesDialog PreferencesChannelTableModel ...minstrel.receiver.gui.search: Search component. SearchToolBarComponent, Search24.gif SearchDialog SearchResultTableModel ...minstrel.receiver.gui.demo: Classes demonstrating how to build a Minstrel receiver GUI; Minstrel receiver components; and test data generators. AboutToolBarComponent, About24.gif ComboDemoToolBarComponent CustomizerToolBarComponent DraftViewer PaymentListener ProtocolService MinstrelReceiverMain TestDataGen ...minstrel.receiver.gui.tools: Useful classes which are only used by the Minstrel receiver GUI. Classes of general use can be found in the at.ac.tuwien.infosys.minstrel.general package. IDSupplier (IF) DialogHelper HelpMenu

7.7. PACKAGES

65

...minstrel.general Minstrel receiver GUI classes of general use. SummableTableModel (IF) TableRowManipulator (IF) ClickableLinkTableCellRenderer RightAlignedTableCellRenderer JDataTipTable JTotalField

66


Chapter 8 Evaluation and Future Work 8.1

Evaluation

This thesis presented a Java component user interface for the Minstrel push system. User interface and architectural design criteria were developed and current component framework technologies were evaluated in terms of this project. On the basis of these criteria a user interface design focussing on usability was developed. Users were integrated into the design process through early presentations of the GUI design and suggestions from users were taken into account. The user group to which the design was presented were experienced computer users. User feedback showed that interaction concepts were presented well and mappings were considered to be good. To conduct a significant design study a user survey including novice users will have to be performed. The GUI was implemented and tested and integrated with the rest of the Minstrel receiver components (protocol engine, content management system and wallet). Additional outcomes of the thesis are generally usable components and a lightweight component framework. This framework, called the MinstrelDock supports installation / deinstallation of components and provides communication facilities for the installed components. It is used as the basis for the component-oriented design and implementation of the Minstrel receiver. To prevent overhead introspection of components, multi-language support, and distribution of components across several machines are not provided. This means that components must know about each other’s features, must be implemented in Java and must execute on the same machine which is sufficient for the Minstrel receiver application. However, many applications have such prerequisites. The component framework is general enough to support such applications. It can be applied when other component frameworks such as CORBA or JavaBeans are too heavy-weight.

8.2

Future Work

During the design and implementation of the Minstrel GUI several areas for future work were identified. Some of these ideas are straightforward to implement while others require consider67

68

CHAPTER 8. EVALUATION AND FUTURE WORK

able effort and may be implemented in future releases of the Minstrel project. Integration with the NRCF The current implementation of the Minstrel receiver uses a very basic viewer (DraftViewer) to display samples and shipments. Due to time NRCF [HJ99] which supports the use of Netscape Communicator as a viewer was not integrated. Integration can be achieved by writing a wrapper for NRCF which conforms to the MinstrelViewer interface. Trashcan A standard “trashcan” functionality for deletions should be included. Number of new shipments received Currently shipments appear in their respective channel when they arrive but no notification is given to the user. An indication of the number of the new shipments received for each channel should be given in the channel index window. This can be achieved by registering the channel component as ReceiverListener, counting received shipments for each channel as they arrive and displaying this number in the channel index. Extended framework functionality In the current implementation exactly one component with a certain name can be installed. As applications evolve, it may occur that some components rely on a specific version of another component while other components need a later version of the same component. If a new version of a component is not backwards compatible this is a serious problem. Therefore it may be desirable to support the installation of several versions of a component. This would require changes in the MinstrelDock and MinstrelDockServices interface to support version number checking and requesting of components not only by name but also by version number. Improved user interface As explained in Section 8.1 user interface presentations were only given to quite experienced users. To make the application more attractive for the average user an improved user interface may be necessary as outlined in the next section.

An improved User Interface for the Minstrel Receiver An improved GUI design would hide the complexity of receiving offers with samples in a list (see Chapter 5.3) and make selecting shipments to receive more seamless to the user. A good analogon to use would be the well-known design of electronic newspapers. A typical example is given in Figure 8.1. A design sketch of the proposed user interface is shown in Figure 8.2: When the user starts the application new offers would be presented to the user similar to the headlines / excerpts of Figure 8.1. For shipments which were already received (automatic request) the offer would be marked as accordingly. Free shipments which have not yet been received would be marked as “free”. Other offers would be displayed with their price.

8.2. FUTURE WORK

69

Figure 8.1: Slashdot.org, a Web based Newspaper If possible samples would be shown inline (text, images) while other content would be represented by an icon denoting the file’s type and would be “shown” by clicking on the sample. A list of all channels would be shown to the user on the left side of the screen and old shipments would be kept in their respective channel.

CHAPTER 8. EVALUATION AND FUTURE WORK

70

Heading News for 20.11.2000

List of channels

Display area showing samples Subject

$ 0.5

Channel name

Price Description

Channel description

Sample Cargo

Subject

free

Subject

received

Subject

free

Figure 8.2: An improved User Interface for the Minstrel Receiver

Bibliography [FFBL96] R. Fielding, H. Frystyk, and Tim Berners-Lee. Hypertext Transfer Protocol – HTTP/1.0. Technical report, Network Working Group, May 1996. RFC 1945. http://www.ietf.org/rfc/rfc1945.txt/. [Gro98]

Open Management Group. Common Object Request Broker Architecture (CORBA) 2.3.1 specification, December 1998. http://www.omg.org/ library/c2indx.html/.

[Gro00a]

Object Management Group. Corba language mapping specifications, December 2000. http://www.omg.org/technology/documents/formal/ corba_language_mapping_specifica.htm.

[Gro00b] Object Management Group. Corba/iiop specification 2.4.1, November 2000. Document Number “Formal/2000-11-03” http://www.omg.org/technology/documents/formal/ corbaiiop.htm. [GT00]

Volker Gruhn and Andreas Thiel. Komponentenmodelle. DCOM, JavaBeans, Enterprise JavaBeans, CORBA. Addison-Wesley, 2000. ISBN 382731724X.

[Hab00]

S. Haberl. An efficient and open Implementation of the Minstrel Broadcasting Infrastructure. Master’s thesis, Distributed Systems Group, Technical University of Vienna, Austria, 2000.

[Hau99]

Manfred Hauswirth. Internet-Scale Push Systems for Information Distribution — Architecture, Components, and Communication. PhD thesis, Technical University of Vienna, August 1999.

[HJ99]

Manfred Hauswirth and Stefan Jakl. Netscape remote control facility. Technical report, Distributed Systems Group, Technical University Vienna, Austria, 1999. http://www.infosys.tuwien.ac.at/Minstrel/Receiver/NRCF/.

[IGM 97] U. Irvine, J. Gettys, J. Mogul, H. Frystyk, and Tim Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. Technical report, Network Working Group, January 1997. RFC 2068. http://www.ietf.org/rfc/rfc2068.txt/. 71

BIBLIOGRAPHY

72 [Inc99]

Sun Microsystems Inc. The Java 2 Platform API Specification, 1999. http:// java.sun.com/products/jdk/1.2/docs/.

[Ips00]

Inc. Ipswitch. Company homepage, 2000. http://www.ipswitch.com.

[Mic97]

Sun Microsystems. Java native interface, May 1997. http://java.sun.com/ products//jdk/1.2/docs/guide/jni/index.html.

[Mic99]

Sun Microsystems. Java Look and Feel Design Guidelines. Addison-Wesley, 1999. ISBN 0201615851, Also available at http://java.sun.com/products/ jlf/guidelines.html.

[Mic00a] Sun Microsystems. Bean development kit 1.1 download, August 2000. http://java.sun.com/products/javabeans/software/bdk_ download.html. [Mic00b] Sun Microsystems. Javabeans specifications for the java 2 plattform, August 2000. http://java.sun.com/products/javabeans/glasgow/. [Mic00c] Sun Microsystems. Javabeans (tm), August 2000. http://java.sun.com/ docs/books/tutorial/javabeans/. [Mic00d] Sun Microsystems. Javabeans tutorial, 2000. products/javabeans/.

http://java.sun.com/

[Nor90]

Donald Norman. The Design of Everyday Things. Doubleday/Currency, 1990. ISBN 0385267746.

[PB97]

Terry Pratchett and Stephen Biggs. The Discworld Companion - An invaluable Guide for the discerning Discworld Traveller. Vista Paperback, 1997. ISBN 0575600306.

[Pre94]

Jenny Preece. Human Computer Interaction. Addison-Wesley, 1994.

[Püh00]

M. Pührerfellner. An implementation of the Millicent micro-payment protocol and its application in a pay-per-view business model. Master’s thesis, Distributed Systems Group, Technical University of Vienna, Austria, 2000.

[SP97]

C. Szyperski and C. Pfister. Workshop on component-oriented programming, summary. In M. Mühlhäuser, editor, Special Issues in Object-Oriented Programming – ECOOP96 Workshop Reader, Heidelberg, 1997. dpunkt Verlag.

[Szy99]

Clemens Szyperski. Component Software – Beyond Object-Oriented Programming. Addison-Wesley, 1999. ISBN 0-201-17888-5.

[Tog00]

Bruce Tognazzini. Ask tog: First principles, 2000. http://www.asktog.com/ basics/firstPrinciples.html.

[WB99]

Nigel Warren and Philip Bishop. Java in Practice - Design Styles and Idioms for Effective Java. Addison-Wesley, 1999. ISBN 0-201-36065-9.

Technical University of Vienna Distributed Systems Group Argentinerstraße 8/184-1, A-1040 Vienna, Austria http://www.infosys.tuwien.ac.at/