next up previous
Next: 3 Support Services Up: 2 Proposed Architecture Previous: 2.2.2 Application Management Functionalities

2.3 The Client

In our architecture, the main component of the client tier is an object-oriented framework which provides both an uniform graphical user interface (GUI) for various applications and a message-based communication component. The framework is based on JIMA which is presented in [13]. In order to access a BES from the client framework, the corresponding application-specific logic has to be provided by subclassing so-called hotspots [12] of the framework. Each data entry of a BES is described by a so-called general InputComponent. This component does not provide a common data model. Instead it describes a data entry of the BES by three attributes. The attribute name assigns a name to a data entry, the attribute type describes the type of a data entry (e.g. Integer, List, Picture, ...), and the attribute value is a link to the actual data. As far as the GUI is concerned, it only needs to access the entries in an uniform manner, whereas application-specific logic on the client-side is responsible for interpreting the respective InputComponents. The visualization of the data depends on the value of the type attribute. This means that the visual representation is identical for a given type independent of the application-specific representation. Therefore the user interface is uniform with respect to a given type. In Section 4.1.1 an example of an InputComponent is given. Generally, the client framework offers facilities to build user-specific collections of BES at the client-side. A collection is basically a group of BES which provides an uniform WWW interface to the entire bundle of BES. The client framework can be used transparently as an applet via the Internet or as a common application which is installed locally on a computer.

The GUI separates presentation and interaction logic in distinct layers at the framework level. The presentation layer provides uniformly accessible interfaces for the visualization of tables, lists, text components, menus, etc. The interaction layer notifies the application logic of changes initiated by the user. However, both layers are coupled loosely by the command pattern [5] which provides a general callback facility within the framework. The GUI-related framework components are largely reused by each BES.

The communication component is a message-based manager for handling client requests. There is one single instance of it for all integrated BES. This client-based manager forms the communication end-point to RESPONDEO, which resides in the middle tier. Each request that is initiated by the GUI component is wrapped in a message and transferred to the communication manager. According to the execution strategy of the BES, the message is sent to RESPONDEO synchronously or asynchronously. When transmitting messages asynchronously, a callback handler has to be provided in order to handle the results appropriately. Additionally, the communication manager is responsible for choosing the right communication strategy, such as the compression or security channel described above.


next up previous
Next: 3 Support Services Up: 2 Proposed Architecture Previous: 2.2.2 Application Management Functionalities

Ralf-Dieter Schimkat
Thu Dec 9 14:08:00 GMT+1 1999