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 user interfaces.
The solution chosen was to add a level of indirection. ServiceUIs come
with a description of themselves detailing 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 class files, 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 -- attaching user interfaces to services; and it provides
insight to some often-recurring design decisions for Jini services
that may well be the basis for Jini-specific design patterns.
The ServiceUI homepage is at http://www.artima.com/jini/serviceui/.