November 27, 2000, 12:00 AM — 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.