ServiceUI - Attaching User Interfaces to Services

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. 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

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon