Sponsored Link •
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:
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.