Sponsored Link •
This article gives a brief history of the ServiceUI project at jini.org. It provides a glimpse into the nascent Jini Community process, and gives a link to the current ServiceUI proposal.
The ServiceUI project
attempting to define a recommended or standard way of attaching a
user interface (UI) to a Jini service.
In this month's Jiniology I
give a short history of the ServiceUI project (a glimpse
glimpse of the Jini community process in action)
present ServiceUI's current working proposal.
My own experience with Jini service UIs got started way back in January, when I posted this query to the JINI-USERs mailing list:
Where will user interface usually reside in service items? The service object itself could be an applet. Or the service item could have methods that put up UI. Or one or more applets could be attached as attributes.
If a service has a UI that needs to be used every time the service is used, will the prefered way to organize that be to make the service object itself an applet? Or will the prefered way always be to keep UI separate from the service object, and put all applets in as attributes? Or will the prefered way be to invoke a method that puts up UI?
Or, I suppose, will there be a prefered way? It seems to me that the "community" will need to develop some guidelines on how service items should be architected, and how clients should behave when presented with different types of service objects and service items.
The first reply to appear on the list was from Brian Jeltima of Sun:
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 difficult of changing code in consumer devices will prompt them to think through these issues early on, I would hope.
Brian's post was followed by 16 other posts discussing how to attach UI to a service. I read all of these posts and then tried to summarize them in an answer to the question, "Where in the service item should I put the UI for my service?" on the JINI-USERS FAQ. Here's a snippet from that early FAQ answer, describing my idea of how a UI object would get a reference to the Jini service object:
(For the full historical record of this first attempt to summarize how to add a UI to a service, see the answer to question 14 on this early version of the JINI-USERS FAQ.)
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 it can be used by the [UI object]. The [UI object] serves as an intermediary between the user and the service.
I posted this FAQ to the JINI-USERS mailing list and received a few comments from Brian Jeltima about my service UI answer. Among Brian's comments was this paragraph, which describes his concern about my recommending 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 separate init() 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, my attention turned to other things and my FAQ answer remained relatively unchanged for the next several months.