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 Jini.org 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 Jini.org 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
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
The ServiceUI homepage is at http://www.artima.com/jini/serviceui/.