Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

How to attach a user interface to a Jini service

An in-depth look at the serviceui project from the Jini community

By Bill Venners, JavaWorld.com, 10/20/99

Discussing service UIs on the Jini-users mailing list

My experience with Jini service UIs began back in January, when I posted the following query to the Jini-users mailing list (see Resources):

Where will a user interface usually reside in service items? The service object itself could be an applet, the service item could have methods that put up the UI, or you could attach one or more applets as attributes. If a service has a UI that must be used every time the service is used, would you prefer to make the service object itself an applet, keep the UI separate from the service object and enter all applets as attributes, or invoke a method that puts up a UI?

Or, I suppose, will there be a preference? It seems the "community" will need to develop guidelines on how you should architect service items, and how clients should behave when presented with different types of service objects and service items.

Any ideas?

bv

The first reply to appear on the list was from Brian Jeltima of Sun Microsystems:

In my opinion, the GUI should rarely (I'd like to say never) be an integral part of the service object. I think of the service as a protocol defined via interfaces. A default user or management GUI can be attached as an attribute, but the user of the service is free to interact with the protocol directly and avoid the download of these bundled GUI objects if they are not needed.

I imagine that a preferred approach will evolve rather quickly as device manufacturers will be burning their solutions into ROM. The difficulty of changing code in consumer devices will prompt them to think through these issues early on, I would hope.

Brian

Brian's post was followed by 16 others discussing how to attach a UI to a service. I read all of these posts and then tried to summarize them on the Jini-users FAQ as an answer to the question: Where in the service item should I put the UI for my service? Here's a snippet from that answer, which describes how I think a UI object would get a reference to the Jini service object:

Your factory instantiates and returns a UI object. The [UI object] you write must accept a reference to the service object in its constructor. This reference will be stored in a local variable, so the [UI object] can use it. The [UI object] serves as an intermediary between the user and the service.

In response to my service UI answer, Jeltima made the following comment, which describes his concern about my recommendation that a service object reference be passed to the UI object constructor:

The problem with passing the service object in the constructor is that if the implementor decides to actually provide the GUI as a serialized object in an attribute, then, when the client deserializes the GUI, the constructor won't be called.... So I think [passing a service object reference to] a separateinit() function [of the UI object] is a bit more general [than passing a service object reference to the UI object's constructor.]

I thought Brian's comment made sense, but as I was very busy with other things, my FAQ answer remained relatively unchanged for the next several months.