Note: is in rebuild. Please accept my apologies for broken links, missing stuff, etcetera - more

One of the first community-originated standards to be "blessed" by the Jini community is the ServiceUI specification, which is a method to attach user interfaces to services.

Discussion on this topic started right at the first Jini community meeting in Aspen, May 1999, and moved to the mailing lists soon afterwards. There were long and intense discussions on the list and at the following meetings, but at the third meeting in Santa Clara, the specification lead Bill Venners could finally give a demonstration.

It is a pity that this newsletter doesn't have enough space to dive into these discussions - I am quite sure that every participant, including most people of the Sun Jini team, learnt a lot about the design of services and all the issues around it. If you are interested, you'll can find the mailing list archives on the website. I'll just present you with the executive summary.

The goal of the ServiceUI project was to attach arbitrary user interfaces to services. Arbitrary in this context means "arbitrary technology", so plain old graphical user interfaces should be attachable just as well as voice interfaces, special interfaces that help people with disabilities, etcetera. Also, separation of concerns was important: ideally, service user interfaces should be pluggable by third parties on existing services. This would make it possible for a supplier of voice interfaces to install a voice user interface on an existing print services, for example.

One of the biggest issues to be dealt with was delaying class instantiation. Normally, with Jini, you lookup based on a type. So, a logical approach for a ServiceUI would be to look for a "javax.swing.JFrame" if you wanted a Swing user interface. However, sending "raw" types attached to services could easily overload small devices: a handheld device with a lightweight AWT implementation would probably not be able to deal with a service that came, like a Christmas tree, loaded with "live" objects for five different user interfaces.

The solution chosen was to add a level of indirection. ServiceUI's come with a description of themselves that detail the purpose of the user interface (like "administration interface", "about box") and the sort of user interface (defined as the Java package the UI is based in: "javax.swing", or "com.voicesrus.talker", etcetera). Based on these descriptions a client device can do a selection of the interface it wants, and only then it will unwrap a factory object and call that to instantiate the actual user interface. Unwrapping the factory object from its container (a MarshalledObject) will trigger the download of supporting classfiles, but by that time the client device has made an explicit decision for that UI type and thus is expected to be able to deal with the results.

ServiceUI is interesting for two reasons: it solves an important problem, that of attaching user interfaces to services; and it provides insight in some often-recurring design decisions for Jini services, that may well be the basis for Jini-specific design patterns.

The ServiceUI homepage is at

Copyright (C)2000-2011 Cees de Groot -- All rights reserved.