111.

  

User Interfaces as Entries

Interaction with a service is specified by its interface, and the interaction will be the same across all implementations of the interface. This consistency doesn't allow any flexibility in using the service, since a client will only know about the methods defined in the interface. The interface is the defining level for using this type of service.

However, services can be implemented in many different ways, and service implementations do in fact differ . For example, one service may be offered on a "take it or leave it" basis, while another might have a warranty attached. This does not affect how the client calls a service, but it may affect whether or not the client wants to use one service implementation or another. There is a need to allow for this, and 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 type interface and these additional entry items primarily in the selection of a service. But once clients have the service, are they just constrained to use it via the type interface? The type interface is designed to allow a client application to use the service in a programmatic way by calling methods. However, many services could probably benefit from some sort of user interface (UI). 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 option by supplying a user-interface object with a special component for the number of copies.

Note  

In this chapter I talk about interfaces we have been using throughout the book, and also about user interfaces. To avoid possible confusion, in this chapter I will use the term "type interface" to refer to a Java interface as used in the rest of this book, and "user interface" for any sort of interaction with the user.

A client can only be expected to know about the type interface of a service. If it uses this to build a user interface, then at best it could only manage a fairly generic one that will work for all service implementations. A vendor will know much more detail about any particular implementation of a service, and so the vendor is best placed to supply the user interface. In some cases, the service vendor may be unwilling or incapable of supplying user interfaces for a service, and a third party may supply it.

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 are not just restricted to providing static data; as Java objects, they are perfectly capable of running as user-interface objects.

User interfaces are not yet part of the Jini standard, but the Jini community (with a semi-formal organization as the "Jini Community") is moving toward a standard way of specifying many things, including user-interface standards and guidelines. Guideline number one from the serviceUI group is this: user interfaces for a service should be given in Entry objects.