How to attach a user interface to
a Jini service - JavaWorld October
1999
Tutorial Details:
How to attach a user interface to a Jini service
How to attach a user interface to a Jini service
By: By Bill Venners
An in-depth look at the serviceui project from the Jini community
he serviceui project at Jini.org (see Resources ) 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 cover the serviceui project's short history and its current working proposal.
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.
(For a complete record of this first attempt to show how to add a UI to a service, see the answer to question 14 on an early version of the Jini-users FAQ.)
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 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 with other things, my FAQ answer remained relatively unchanged for the next several months.
Discussing service UI at the Jini Community Summit
At the Jini summit last May in Aspen, CO, however, the issue of attaching a UI to a service was revisited. During his presentation called "Creating and Building New Jini Services," Jon Bostrom of Sun said that it was important that someone define a standard way of attaching a UI to a service.
Most people at the presentation agreed. I also voiced my agreement and described January's Jini-users discussion and the resulting FAQ answer. I also mentioned Jeltima's preference of using an init() method rather than 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 each of our Jini services." I also added that if no standard way of attaching a UI to a service became generally accepted, service providers would attach UIs independently and clients would need to know 500 different ways to look for a service UI.
Unfortunately, I discovered as I was writing this article that the example I gave at the Jini summit was wrong. As I myself had noted in the first FAQ proposal, the UI object was being created and returned by a factory method. A factory method is meant 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 -- needs to worry about whether to pass a service object reference to a constructor, an init() method, or some other method. Nevertheless, the attendees of Bostrom's meeting seemed to accept my conclusion that even minor differences in the way UIs are attached to services can complicate programming Jini clients.
In the end, we all agreed that defining a standard made sense, and that the Jini community was the one to tackle the problem. Bostrom said that while he'd be happy to have his team work on the approach, he thought it would be best if someone who was not from Sun started it.
Later that day, another Sun employee slipped me this note:
Bill,
On Jini.org, we can now 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 later, Ken Arnold of Sun 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, and so forth.
Suppose you want to work on the correct design for GUI attributes (a popular discussion among Jini users). You can go to the projects page on Jini.org and see if someone is already working on it. If not, you can create a new project....
Ken
Creating the serviceui project
I must have subconsciously taken Bostrom's and Arnold's comments as hints, because soon after this message was posted, I created a project on Jini.org 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 because a personal experiment in chaos -- I mean, democracy -- seemed intriguing, 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 creating it.
Shortly after creating the serviceui project, however, I had a minor 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 acting like some trigger-happy cowboy? Time, however, calmed my anxieties. Over the next few weeks, many people joined the project and an interesting and fruitful discussion commenced on the serviceui mailing list.
So far, the project felt like a group of engineers sitting in a virtual conference room, discussing a design problem, and homing in on a solution. I have served as scribe, attempting to capture the consensus in writing. (Our current proposal forms the bulk of this article.)
I believe that in general the serviceui experiment has been successful. Our main problem has simply been that because no one is getting paid and we are all busy, our work has gone slowly. Nevertheless, we have made quite a bit of progress. Hopefully, our work will be timely enough to do some good. One of your most important goals when trying to establish a de facto standard is to define it as early as possible, before people invest too heavily in other approaches.
I hope to get a solid proposal by the next Jini summit, to be held in Annapolis, MD, in October (see Resources .) Someone from the project, perhaps myself, will present the proposal at the summit.
I'll now give you the serviceui project's current working proposal. Any feedback you have is welcome. You can submit comments to my usual discussion forum at Artima.com . Or you can join the serviceui project at Jini.org and post comments to its mailing list.
How to add a UI to a Jini service
As a general rule, you should not make a Jini service object extend a class from a user interface library, such as Panel or JPanel . Think of the service object as the way clients interact with a service through the well-known Java interfaces that the service object implements. To associate a UI with a service, use attributes.
You can associate many UIs with a service by placing entries for the UIs in the service item's attributes. One reason to keep the UI separate from the service object is that services may be used in devices that don't have user interface libraries available. If you attach a UI to a service item as attributes, those clients who have user interface libraries can retrieve your UI and display it. Clients who don't have them can just use your service object directly.
Each UI is represented by one UI object, which may or may not represent a graphical UI component. A UI object could represent a voice-only interface, a text interface, a combination of voice and graphics, a 3D-immersible world, and so on. Each distinct kind of UI, including a 3D-immersible world with voice and a virtual-text display, would be represented in the attributes by one UI object.
Figu
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: How to attach a user interface to
a Jini service - JavaWorld October
1999
View Tutorial: How to attach a user interface to
a Jini service - JavaWorld October
1999
Related
Tutorials:
 Locate services with the Jini lookup
service
Locate services with the Jini lookup
service
|
Jini-like
discovery for RMI
Jini-like
discovery for RMI
|
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
|
Deploy code
servers in Jini systems
Deploy code
servers in Jini systems
|
Use Web services
to integrate Web applications with
EISs
Use Web services
to integrate Web applications with
EISs
|
Cache SOAP services on
the client side
Cache SOAP services on
the client side
|
Jtrix: Web
services beyond SOAP
Jtrix: Web
services beyond SOAP
|
Repair invalid cached services in the Service Locator pattern
Repair invalid cached services in the Service Locator pattern
|
Jabber away with instant
messaging
Jabber away with instant
messaging
|
Jini's relevance emerges, Part
1
Jini's relevance emerges, Part
1
|
Jini's relevance emerges, Part
2
Jini's relevance emerges, Part
2
|
J2SE 1.4
breathes new life into the CORBA community, Part
1
J2SE 1.4
breathes new life into the CORBA community, Part
1
|
Publish and find UDDI tModels with JAXR and
WSDL
Publish and find UDDI tModels with JAXR and
WSDL
|
A first look at JavaServer Faces, Part
2
A first look at JavaServer Faces, Part
2
|
Jini Starter Kit 2.0 tightens Jini's security framework
Jini Starter Kit 2.0 tightens Jini's security framework
|
SAAJ: No strings attached
SAAJ: No strings attached
|
Aspect-Oriented Annotations
Aspect-Oriented Annotations
Annotations are one of the new language features in J2SE 5.0, and allow you to attach metadata onto any Java construct. Meanwhile, Aspect-Oriented Programming (AOP) is a fairly new technology that makes it easier for you to en
|
Application Integration: Sun Java System Access Manager 2004Q2 and JDBC Authentication Module
Today, most user authentication solutions for Web applications are ad hoc and are based on proprietary schema definitions in relational databases. So, if you have multiple Web applications, you may have a separate user database for each of your applicatio
|
SQL Uniform
SQL Uniform is a general interface (GUI), a helper application to relational databases of various types regarding query, maintenance, data comparison, export (convert).
|
Game Canvas Basics
Introduces the MIDP 2.0 GameCanvas class and the game loop concept. Required reading for all aspiring "first person shooter" developers.
|
|
|
|
