A Look at the Jini Community's ServiceUI Project

First published in JavaWorld, October 1999

---

The ServiceUI project at jini.org is 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) and present ServiceUI's current working proposal.

Discussing Service UI on the JINI-USERS Mailing List

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.

Any ideas?

bv

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

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:

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.

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

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.

Discussing Service UI at the Jini Community Summit

At the Jini community summit in May, however, the issue of attaching a UI to a service came up again. During a presentation called "Creating and Building New Jini Services," given by Jon Bostrom of Sun, Bostrom said that he thought it was important that someone define a "standard" way of attaching a UI to a service. Bostrom opened the issue for discussion, and most people seemed to agree. I voiced my agreement and described January's JINI-USERS discussion from and the resulting FAQ answer. I also mentioned Brian Jeltima's comment about his preference of using an init() method over a constructor to pass a service object reference to a UI object. I said, "If I do it my way and Brian does it his way, then clients will have to know about both ways to offer UIs to both my and Brian's Jini services." I said that if no recommended or standard way of attaching a UI to a service became generally accepted, that service providers would all do their own things and clients could end up needing to know 500 different ways to look for a service UI."

Unluckily, it ocurred to me as I was writing this article that the example I gave at the Jini Community summit was wrong, because from the very first proposal in the FAQ, the UI object was being created and returned by a factory method. The idea of a factory method is to hide from the client the way an object (in this case, the UI object) is instantiated. Because the factory method is responsible for initializing the new UI object, only the factory method -- not the client -- need worry about whether to pass a service object reference to a constructor, an init() method, or some other method. Nevertheless, the attendees of Jon Bostrom's meeting seemed to accept my conclusion that even minor differences in the way UIs are attached to services by different service providers can make programming Jini clients very complicated.

In the end, we all seemed to agree that it made sense to define a standard way to attach a UI to a service, and that the Jini Community was the right organization for tackling this problem. Bostrom summarized by saying that someone ought to come up with this recommended approach, and that he'd be happy to have people from his team work on it, but he thought it would be best if it was started by someone not from Sun.

Later that day at the summit, a different Sun employee who happened to be sitting next to me slipped me this note:

Bill,

On jini.org we now have the ability to create "projects". This may be a possible forum for the GUI working group that we were all discussing in the "Jini Services" breakout session.

A few days after the summit, Ken Arnold posted this message to the JINI-USERS mailing list:

We have added a new feature to the jini.org web site -- you can create collaborative projects for shared development of Jini service definitions, development utilities, clients, documentation, etc.

Suppose you want to work on the correct design for GUI attributes (a subject that has been under much discussion on jini-users). You can go to http://developer.jini.org and look at the projects page to see if someone is already doing that. If not, you can create a new project for working on that.

[...]

Ken

Creating the ServiceUI Project

I must have subconsciously taken all these comments about someone outside of Sun starting a service UI project as hints, because right after I read Ken Arnold's post, I went over to jini.org and created a project called ServiceUI. I did this partly because the message that Sun wanted someone external to start the project had been firmly imprinted on my brain, partly as a personal experiment in chaos -- I mean, democracy -- and partly because it was so fast and easy to create a project at jini.org that I didn't think much about it before I did it.

Shortly after creating the ServiceUI project, however, I had a panic attack. What business did I have starting this project? Shouldn't I have at least posted a query to the JINI-USERS list to build a consensus before just creating the project like some trigger happy cowboy? With time, however, my anxieties were calmed. Over the next few weeks, many people joined the project and an interesting and fruitful discussion commensed on the ServiceUI mailing list. So far, the project has been kind of like a group of engineers sitting around a virtual table in a virtual conference room, discussing a design problem and zeroing in on a solution. I have served as scribe, attempting to capture the consensus of the group in writing. (Our current best proposal forms the bulk of this article.)

I would say that the ServiceUI experiement has been successful in general. Our main problem, as I see it, has been simply that because no one is getting paid to do this and we are all busy, progress has been slow. But we have, nevertheless, made quite a bit of progress. Hopefully our work will be fast enough to do some good. One of the most important ingredients needed to establish a de facto standard is to get it out there early, before people get too heavily invested in other approaches.

We still have quite a bit of work to do at the ServiceUI project. I am hoping to get the proposal quite solid by the next Jini Community summit, which will be held in Annapolis, Maryland in October. Someone from our project, perhaps me, will be presenting the proposal at that meeting.

The rest of this article as published in JavaWorld gave the current working proposal of the ServiceUI project. To see the current proposal, visit the ServiceUI project pages. We welcome any feedback you may have. I've created my usual discussion forum at artima.com, so that's a good place to submit comments. The other option is to join the ServiceUI project at jini.org and post comments to its mailing list.

Portions of this article were first published under the name The How to attach a user interface to a Jini service in JavaWorld, a division of Web Publishing, Inc., October 1999.

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners has been writing software professionally for 14 years. Based in Silicon Valley, he provides software consulting and training services and maintains a Web site for Java and Jini developers, artima.com. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill.