]> User Interfaces as Entries User Interfaces from Factory Objects Current Factories Marshalling Factories UIDescriptor Toolkit File Classifier Example Support Classes Images ServiceType Summary 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 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. But services can be implemented in many different ways, and service implementations do in fact differ. 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? 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. 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 are not just restricted to providing static data - as Java objects they are perfectly capable of running as user-interface 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: 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) 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 factories capable of doing so Localisation of internationalised services cannot be done on the service side, only on the client side The service should export zero or more user-interface factories, with methods to create the interface, such as getJFrame(). 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 beforehand - if it was given one during its construction (on the service side) it would end up with a service-side copy of the service instead of a client-side copy! So when it is asked for a user-interface (on the client side), it should be passed the service as well in a parameter to user-interface creation. In fact, it should probably be passed all of the information about the service, as retrieved in the ServiceItem obtained from a lookup service. A typical factory is the one that returns a JFrame. This is defined as package net.jini.lookup.ui.factory; import javax.swing.JFrame; public interface JFrameFactory { String TOOLKIT = "javax.swing"; String TYPE_NAME = "net.jini.lookup.ui.factory.JFrameFactory"; JFrame getJFrame(Object roleObject); } The factory imports the minimum number of classes for the interface to compile and be exported. An implementation of this interface will probably use many more. The roleObject passes in any necessary information to the UI constructor. This is usually the ServiceItem, as this contains all the information (including the service) that was retrieved from a lookup service. The factory can then create a UI that acts as an interface to the service, and can use any additional information in the ServiceItem such as entries for ServiceInfo or ServiceType which could be shown, say, in an ``about'' box. A factory that returns a visual component such as this should not make the component visible. This will allow its size and placement to be set before showing it. Similarly, a ``playable'' UI such as an audio file, should not be in a ``playing'' state. A service may supply lots of these factories, each capable of creating a different user interface object. This is to allow for the differing capabilities of ``viewing'' devices, or even for different user preferences. One user may always like a Web-style interface, another may be content with an AWT interface, a third may want the accessibility mechanisms possible with a Swing interface, and so on. The set of factories currently includes DialogFactory which returns an instance of java.awt.Dialog (or one of its subclasses) which depends on the AWT but not Swing FrameFactory which returns an instance of java.awt.Frame (or one of its subclasses) which depends on the AWT but not Swing JComponentFactory which returns an instance of javax.swing.JComponent (or one of its subclasses such as a JList) JDialogFactory which returns an instance of javax.swing.JDialog (or one of its subclasses) JFrameFactory which returns an instance of javax.swing.JFrame (or one of its subclasses) JWindowFactory which returns an instance of javax.swing.JWindow (or one of its subclasses) PanelFactory which returns an instance of java.awt.Panel (or one of its subclasses) which depends on the AWT but not Swing WindowFactory which returns an instance of java.awt.Window (or one of its subclasses) which depends on the AWT but not Swing These can be extended by any user, but to allow wide understanding of these factories any new factories should be approved by the Jini Community. These factories are all defined as interfaces. An implementation will define a getXXX() method that will return a user interface object. The current set of factories returns objects that belong to the Swing or AWT classes. Factories added in later iterations of the specification may return objects belonging to other user interface styles, such as speech objects. Although an interface may specify that a method such as getJFrame() will return a JFrame, an implementation will in fact return a subclass of this, which also implements a role interface. There may be many factories for a service, and each of them will generate a different user interface. These factories and their user interfaces will be different for each service. The standard factory interfaces will probably be known to both clients and services, but the actual implementations of these will only be known to services (or maybe to third-party vendors who add a user interface to a service). If a client receives a ServiceItem containing entries with many factory implementation objects, it will need to download the class files for all of these, as it instantiates the entry objects. There is a strong chance that each factory may be bundled into a jar file that also contains the user interface objects themselves. So if the entries directly contain the factories, then the client will need to download a set of class files, before it even goes about the business of deciding which of the possible user interfaces it wants to select. This downloading may take time on a slow connection, such as wireless or home network link. It may also cost memory which may be scarce in small devices such as PDA's. So it is advantageous to hide the actual factory classes until the client has decided that it does in fact want a particular class. Then, of course, it will have to download all of the class files needed by that factory. In order to hide the factories, they are wrapped in a MarshalledObject. This keeps a representation of the factory, and also a reference to its codebase, so that when it is unwrapped the necessary classes can be located and downloaded. By putting it into entries in this form, no attempt is made to download its classes until it is unmarshalled. The decision as to whether or not to unmarshall a class can be made on a separate piece of information, such as a set of String's which hold the names of the factory class (and all of its superclasses and interfaces). This level of indirection is a bit of a nuisance, but not too bad: if (typeNames.contains("net.jini.lookup.ui.factory.JFrameFactory") { factory = (JFrameFactory) marshalledObject.get(); .... } A client that does not want to use a JFrameFactory will just not perform this test, unmarshalling or attempted coercion. This does place a responsibility on service-side programmers to ensure this coercion will be correct. In effect, this is a manoeuvre to circumvent the type-safe model of Java purely for optimisation purposes. There is one final wrinkle on loading the class files for a factory: a running JVM may have many class loaders. When loading the files for a factory, you want to make sure that the class loader is one that will actually download the class files across the network as required. The class loader associated with the service itself will be the most appropriate for this. An entry for a factory must contain the factory itself hidden in a MarshalledObject and some string representation of the factory's class(es). It may need other descriptive information about the factory. The UIDescriptor captures all this package net.jini.lookup.entry; public class UIDescriptor extends AbstractEntry { public String role; public String toolkit; public Set attributes; public MarshalledObject factory; public UIDescriptor(); public UIDescriptor(String role, String toolkit, Set attributes, MarshalledObject factory); public final Object getUIFactory(ClassLoader parentLoader) throws IOException, ClassNotFoundException; } There are several features in the UIDescriptor that we haven't mentioned yet, and the factory's type appears to be missing (it is one of the attributes). A user interface will typically require a particular package to be present or it will just not function. For example, a factory that creates a JFrame will require the javax.swing package. This can provide a quick filter on whether or not to accept a factory: if it is based on a package the client doesn't have, then it can just reject this factory. This isn't a bullet-proof means of selection. For example, the Java Media Framework is a fixed-size package designed to handle lots of different media types. So if your user interface is a Quicktime movie, then you might specify the JMF package. However, the media types it handles are not fixed, and can depend on native code libraries. For example, the current Solaris version of the JMF package has a native code library to handle MPEG movies, which is not present in the Linux version. So having the package specified by the toolkit does not guarantee that the class files for this user interface will be present. It is primarily intended for narrowing lookups based on the UIs offered. There are many possible roles for a user-interface. The role is intended to cover this. This is specified as an interface, with one field role, which is the fully qualified path name of the interface. There are currently three interfaces: The net.jini.lookup.ui.MainUI role. This role is for the standard user interface used by ordinary clients of the service package net.jini.lookup.ui; public interface MainUI { String ROLE = "net.jini.lookup.ui.MainUI"; } The role net.jini.lookup.ui.AdminUI is for use by the service's administrator package net.jini.lookup.ui; public interface AdminUI { String ROLE = "net.jini.lookup.ui.AdminUI"; } net.jini.lookup.ui.AboutUI for information about the service, which is presentable by a user interface object package net.jini.lookup.ui; public interface AboutUI { String ROLE = "net.jini.lookup.ui.AboutUI"; } A service will specify a role for each of the user interfaces it supplies. This role is given in a number of ways for different objects The role field in the UIDescriptor must be set to the string ROLE of the role interface The user interface indicates that it acts a role by implementing the particular role specified. The factory does not explicitly know about the role, but the factory contained in a UIDescriptor must produce a user interface implementing the role. The service must ensure that the UIDescriptors it produces follows these rules. How it actually does so is not specified. There are several possibilities, such as When a factory is created, the role is passed in through a constructor. It can then use this role to cast the roleObject in the getXXX() method to the expected class (currently this is always a ServiceItem). There could be different factories for different roles, and the UIDescriptor should have the right factory for that role The factory could perform some ``sanity'' checking if desired: since all roleObject's are (presently) the service items, it could search through these for the UIDescriptor, and then check that it's role matches what the factory expects. There has been much discussion about ``flavours'' to roles, such as an ``expert'' role, or a ``learner'' role. This has been deferred as too complicated, at least for the first version of the specification. The attributes section of a UIDescriptor can carry any other information about the user interface object that is deemed useful. Currently this includes A UIFactoryTypes which contains a set of String's. This contains the strings for the fully qualified class names of the factory this entry contains. The current factory hierarchy is very shallow so this may be just a singleton set, such as {JFrameFactory.TYPE_NAME}. There is an unfortunate wrinkle with Java sets and Jini entries: the lookup matching mechanism for entries tests byte equality of serialised forms, and most implementations of the Set interface are not constant across all Java virtual machines. So instead of common set types such as HashSet you should use special types such as com.artima.lookup.util.ConsistentSet This has a constructor which takes a Set in its constructor. This makes slightly messy code a bit more messy: Set attribs = new HashSet(); Set typeNames = new HashSet(); typeNames.add(JFrameFactory.TYPE_NAME); typeNames = new ConsistentSet(typeNames); attribs.add(new UIFactoryTypes(typeNames)); attribs = new ConsistentSet(attribs); Note that a client is not usually interested in the actual type of the factory, but rather of the interface it implements. This is just like Jini services themselves, where we only need to know the methods that can be called, and are not concerned with the implementation details. An AccessibleUI object. Inclusion of this is a statement that the user interface implements javax.accessibility.Accessible and that the user interface would work well with assistive technologies A Locales object which specifies the locales supported by the user interface A RequiredPackages object which contains information about all of the packages that the user interface needs to run. This is not a guarantee that the user interface will actually run, nor a guarantee that it will be a usable interface! But it may help a client decide whether or not to use a particular user interface The file classifier has been used throughout as a simple example of a service, to illustrate various features of Jini. We can use this here too, by supplying simple user interfaces into the service. Such a user interface would consist of a text field to enter a filename, and a display of the MIME type of the filename. There is only a ``main'' role for this service, as no administration needs to be performed. Figure shows what a user interface for a file classifer could look like.

After the service has been invoked it could pop up a dialog box as in figure

A factory for the ``main'' role that will produce an AWT Frame is The user interface object that performs this role is The server which delivers both the service and the user interface has to prepare a UIDescriptor. In this case it only creates one such object for a single user interface, but if the server exported more interfaces then it would simply create more descriptors Finally, a client needs to look for and use this user interface. The client finds a service as usual, and then does a search through the Entry objects looking for a UIDescriptor. Once it has a descriptor it cab check if it meets the requirements of the client: here we shall check if it plays a MainUI role, and can generate an AWT Frame. To use the service UI, additional classes are required that are not in the standard Jini distribution. These need to be downloaded from http://www.artima.com/jini/serviceui/index.html User interfaces often contain images. They may be used as icons in toolbars, for general images on the screen, or for the icon image when the application is iconified. When a user interface is created on the client, these images will also need to be created and installed in the relevant part of the application. Images are not serializable, so they cannot be created on the server and exported as live objects in some manner. They need to be created from scratch on the client. The Swing package contains a convenience class ImageIcon. This can be instantiated from a byte array, a filename, or most interestingly here, from a URL. So if an image is stored where an HTTP server can find it, then the ImageIcon constructor can use this directly. There may be failures in this: the URL may be incorrect or malformed, or the image may fail to exist on the HTTP server. Suitable code is ImageIcon icon = null; try { icon = new ImageIcon(new URL("http://localhost/images/mindstorms.jpg")); switch (icon.getImageLoadStatus()) { case MediaTracker.ABORTED: case MediaTracker.ERRORED: System.out.println("Error"); icon = null; break; case MediaTracker.COMPLETE: System.out.println("Complete"); break; case MediaTracker.LOADING: System.out.println("Loading"); break; } } catch(java.net.MalformedURLException e) { e.printStackTrace(); } // icon is null or is a valid image A user interface may use such code directly to include images. The service may also supply useful images and other human-oriented information in a ServiceType entry object. package net.jini.lookup.entry; public class ServiceType { public String getDisplayName(); // Return the localized display // name of this service. public Image getIcon(int iconKind) // Get an icon for this service. public String getShortDescription() // Return a localized short // description of this service. } The class is supplied with empty implementations, returning null for each method. A service will need to supply a subclass with useful implementations of the methods. However, it is a useful class that could be used to supply images and information that may be common between a number of different user interfaces for a service, such as a minimised image. The ui-service group is evolving a standard mechanism for services to distribute user-interfaces for Jini services. The preference is to do this by entry objects. ©right;