Jini is a relatively new distributed middleware technology for building dynamically configurable systems. It allows services to join networks, to broadcast their presence, and be located by clients requiring their services. A Jini "djinn" consisting of clients and services is designed to be flexible under network conditions, where partial failure of the network can cause parts of a system to disappear without warning.
A number of Jini systems have begun to appear, including print systems, storage systems, and a number of other distributed systems. Work is underway on a large number of Jini systems, and it is expected that Jini will play a major role in mobile and adhoc networks, as well as fixed networks.
The Jini infrastructure does not mandate any particular way of dealing with a Jini service, except through a published interface for that service. This allows for a client to interact with a service in a purely programmatic manner. However, there may be situations in which a service wishes to provide a user interface so that users may interact with it directly. The "Service UI" proposal addresses these issues, whereby a service may advertise a number of user interfaces.
Increasingly in the Web world, users are demanding Web interfaces for interaction with services. A Web interface is not included as a possibility in the Service UI proposal as a URL is not a Java object that can be returned as an "interface object". Work on URL's as interfaces was deferred by the Service UI group.
This paper reopens this issue, and makes proposals for architectural choices in order that an HTML interface can be supplied for Jini services. This involves some minor additions to the Service UI proposal, which could be treated as a separate proposal.
Java has a number of graphical user interface objects. The container
objects such as Frame, Dialog and
Panel can contain a mix of other intercace objects and
be linked to other non-graphical objects. Making one of these containers
visible causes code to run within these objects, and by this they are
able to provide an interaction with the user.
A URL on the other hand, is simply the address of a resource on the
Internet. It is not "active" in itself. First it must be fetched using
a socket connection, and then must be interpreted by a suitable user-side
agent. The nature of the resource is not known until it is fetched,
where it can be found from the "Content Type" specification in the
HTTP stream. For example, if it is an HTML document then it can be
displayed in an HTML browser or a Java JEditorPane;
if it is a GIF image it may be displayed in a browser (except
non-graphical browsers such as Lynx) or in a Java JLabel.
A single HTML page may convey information. Generally it is linked to other pages so that the user may "browse" the information sources. An interface for a service, such as a book store, may contain these link elements, but also is built out of a succession of Forms. This set of Forms will form a session, in which state needs to be maintained on the server side (for example, the contents of a shopping trolley).
In order to initiate a session with a service on the Web, an initial URL must be given, and this should return an HTML page (possibly with embedded image URL's and JavaScript/VBScript). This page should lead to a series of further pages, with the particular choice of pages usually chosen by state changes in a server-side agent.
A Web user interface for a service thus consists of a persistent server-side object that generates a sequence of Web pages in response to user input.
A service need not have a known location. Within multicast reach, a Lookup Service does not need to have a known location either. On the other hand, a URL is at a fixed and known location. A browser will need to know this URL in order to access the resource at that URL. There is no contradiction here: the URL can be a typical Jini client that searches for a service. It can then call methods on this service like any other client. However, it will get instructions about which methods to call from the URL's form data. After execution of service methods, it will need to prepare an HTML page as output and return that to the HTML browser.
Diagrammatically, this will appear as in Figure 1.
The Jini client may be implemented in many ways. For preservation of state between pages, this may be best done by a Java servlet.
HTML browsers are not the only means of displaying HTML documents.
HTML pages can be displayed by objects in a variety of languages,
such as tcl/Tk and Perl/Tk. In Java, a Swing JEditorPane
can be used. This can allow a Java application to use a familiar
HTML display format.
Applications using non-browser widgets can use a known URL to load the initial interface page. In addition, applications that are written in Java can also use Jini lookup methods to search for a service, so that the URL does not need to be known in advance.