The Artima Developer Community
Sponsored Link

Separating UI and Functionality
The Flexible Way to Architect a Jini Service
by Bill Venners
October 1999

<<  Page 3 of 5  >>

Advertisement

User Adapters

When you design a Jini service, you should attempt to capture the entire functionality of the service in the service object interface. To access any aspect of the service you are providing, a prior-knowledge client should need only one thing: a reference to the service object. The service object should not include any code that defines a user interface to the service, just code that provides the functionality of the service on the conceptual level of method invocations.

To provide a user interface for the service, you should encapsulate the user interface code in a separate "UI object." As shown in Figure 2, a UI object grants a user access to a Jini service. Think of a service UI object as a "user adapter" -- an object that adapts the interface of the service object, which a human user can't interact with directly, into some form that a human user can interact with directly. Sitting between the interface offered by the service object and a human user that wants to use the service, a UI object grants a user access to a service.


Figure 2. A user interacts with a service via a UI object.

A UI object can represent a graphical UI component, such as an AWT Frame or Swing JPanel, but need not. A UI object could also represent a speech interface, a text interface, a combination of speech and graphics, a 3D immersive world, even a semantic expression of the UI that provides input to a dynamic UI builder. (The UI object is called "UI object," rather than "GUI object" or "view object,", because the object is intended to be more general than just an object, such as a JFrame, that represents a graphical user interface.) Any kind of Jini service UI, even a 3D immersive world with speech and a virtual text display, should be represented by a single UI object, which is distinct from the service object.

The programmers of clients that will be used by a human user need not have prior knowledge of all the services hosted by the client. A user can be shown a list of services compiled by browsing a lookup service. The user can select one, which the client downloads. Given a standard way to attach a UI to a Jini service, the client can select a UI and attach the UI to the service object. The user interacts with the UI, and the UI interacts with the service object. Thus, the programmers of the client need not have prior knowledge of a service when a UI and user are also present. Because the programmers of the UI had prior knowledge of the service object interface, the programmers of the client need only have prior knowledge of the standard way to find and select an appropriate UI associated with a service. In Figure 2, it is the UI code, not the client code, that talks to the service object interface directly.

<<  Page 3 of 5  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us