Contents

Interaction with a service is specified by its interface. This will be the same across all implementations of the interface. This doesn't allow any flexibility, and of course it shouldn't. It is the bottom level for using this type of service. But service implementations do differ, and there is a need to allow for this. The mechanism used in Jini is to put these differences in Entry objects. Typical objects supplied by vendors may include Name and ServiceInfo.

Clients can make use of the interface and these additional entry items, primarily in the selection of a service. But once they have the service, are they just constrained to use it via the type interface? Many services will probably benefit from some sort of user interface. For example, a printer may supply a method to print a file, but it may have the capability to print multiple copies of the same file. Rather than relying on the client to be smart enough to figure this out, the printer vendor may want to call attention to this by supplying a user-interface object with a special component for ``number of copies''.

The user interface for a service cannot expect to have all details supplied by the client - at best a client could only manage a fairly generic user interface. It should come from the vendor, or maybe even third parties. When your video player becomes Jini enabled, it would be a godsend for someone to supply a decent user interface for it, since the video player vendors seem generally incapable of doing so! The Entry objects need not just provide static data - as Java objects they are perfectly capable of running as user-interface objects.

User interfaces are not part of the Jini standard. But the Jini community (with a semi-formal organisation as the ``Jini Community'') is coming towards a standard way of specifying many things, including user-interface standards and guidelines. Guideline number one is: user interfaces for a service should be given in Entry objects.

In the chapter on ``More Complex Examples'' some discussion was given to the location of code, using user-interface components as examples. The chapter suggested that user interfaces should not be created on the server side but on the client side. So the user-interface should be exported as a factory object that can create the user-interface on the client side.

More arguments can be given to support this:

1. A service exported from a low resource computer, such as an embedded Java engine may not have the classes on the service side needed to create the user-interface (it may not have the Swing or even the AWT libraries)
2. There may be many potential user-interfaces for any particular service: the Palm Pilot (with small grey-scale screen) requires a different interface to a high-end workstation with huge screen and enormous numbers of colours. It is not reasonable to expect the service to create every one of these, but it could export a factory capable of doing so
3. Localisation of internationalised services cannot be done on the service side, only on the client side

The service should export a user-interface factory, with a method to create the interface, such as getUI(). The service and its user-interface factory entry will both be retrieved by the client. The client will then create the user-interface. Note that the factory will not know the service object - if it was given one during its construction (on the service side) it would end with another copy of the service. So when it is asked for a user-interface (on the client side), it should be passed the service as well. The actual creation may fail in lots of ways: no suitable libraries, out of memory, screen too small, etc. So this method may need to throw an exception.

The factorty will probably know many attributes of the user-interface: preferred and minimum screen sizes, required class libraries etc. These can all be stored in a map feature of the factory. Two have been singled out as being of general importance: the name and the role (such as main and admin). The current definition of a user-interface factory is

public class UIFactory extends AbstractEntry {
    public String name;
    public String role;
    public map properties;

    public UIFactory(String name, String role);
    public UIFactory(String name, String role, Map properties);

    public Object getUI(Object service) throws UICreationException;
}

There are many kinds of user-interface objects that can be returned. They could be individual components such as buttons or lists, containers such as panels, or components with their own toplevel windows such as frames and dialogs. Dialogs may be modal or non-modal. These will all need to be handled by a client in different ways: a component needs to be placed within a container, a frame is shown and processing independently continues, a modal dialog blocks execution of the calling process until it is dismissed. The client will need to know these broad categories.

A user interface may just use AWT components. It may use Swing components. But it may also use the 2-D or 3-D classes, or even things like the MPEG class from the Media API. Perhaps it doesn't have a ``traditional'' screen interface, but uses a speech interface instead.