RESToring addresses to Jini

There have been many attempts to produce robust and well-used
infrastructures for distributed computing. These include message-based
socket programming, RPC and object-oriented systems such as CORBA
and Java RMI. Jini was proposed as one extreme of an object-oriented
approach. More recently, Web Services (typically based on SOAP) have
been promoted as a solution.

Regrettably, most of these have failed to deliver as large scale 
distributed infrastructure systems. They all have their niche
markets: CORBA for example is used as the distributed framework
for the KDE system under Linux, while Jini has been successful in
many vertical markets. The current brred of Web Services show little
widespread acceptance outside of in-house systems.

Despite these apparent failures, the Web thunders on. New web sites
are added at an enormous daily rate, and the number of web pages
increases at an even faster rate. The so-called REST approach to
distributed services attempts to determine what exactly it is about
the web that causes it to be so successful, and to emulate that 
success for a distributed services architecture.

Several reasons have been advanced for the success of the web:

- a simple markup language, HTML

- tolerance of HTML parsers to incorrectly formatted documents

- widespread availability of open source HTML browsers and HTTPD servers

- simple addressing of resources through URIs, in a text format

- addressability of every resource 

In the REST approach, addressability of all resources and the simplicity
of HTTP access to these resources is the key. While it remains to be seen
if this is in fact they key, there is increasing interest in the REST
approach and an increasing number of web services exposing a REST
interface.

Jini is generally regarded as one of the purest of the O/O approaches
to distrbuted systems. It is a coherent and tightly knit set of
protocols, ideas and implementations, based around the ideas of 
type-safe computing in the face of unreliable networking. Jini services
appear to have no addresses, or other features taht would align them
to REST services.

This paper argues that Jini does in fact display many features of REST
services, and with only a few modifications can be brought fully into
the REST framework.

ServiceIDs
----------

A Jini servie registers itself with a lookup service, basically a 
directory of services. However, it differs from many directory services
such as LDAP, RMI Registry or CORBA XXX in that it is not hierarchically
based on names. It uses an object-oriented matching process in which
a hierarchy is built on object inheritance rather than on directory
paths.

For example, an LDAP service might index laser printers on a directory
hierarchy of


	  computers/peripherals/printers/laser-printers

while a Jini service might index on
      
	laser-printer inherits printer inherits object

A disadvantage of a naming system is that it does not provide any
type safety: there is nothing to stop someone putting a fax machine
(by mistake) into a printers directory. It is not until an attempt is
made to invoke printer methods on the fax machine that the error will
be discovered.

Jini, using a system based on class inheritance is supposed to be immune
to this kind of error. In fact, it is not quite as type-safe as is commonly
supposed, and really relies on Java naming conventions for the uniqueness
of classes. Java suggests that classes be organised into packages by e.g.
org-name.local-package. e.g.

	package au.com.jan.foo

However, if this is not followed correctly, then a server might export

package foo;

interface Bar {
    void f();
}

while a client might know about

package foo;

interface Bar {
    int g(int n);
}

The Jini lookup mechanism is in fact based on fully qualified class
names (rather than on runtime "instanceof"), so the client searching
for an object of type "foo.Bar" would get a service implementing a 
different type.

Neither mechanism is completely type safe, but the Jini mechanism is
safer.

However, neither of these mechanisms provides an addressing scheme in this
way, which is the corner stone of REST. If we look closer, though, we
see that Jini also has a ServiceID element. This is similar to the CORBA
id, and is a globally unique identifier for the service. This is NOT in
the same category as the URL for a Web Service, which only identifies 
the SERVER, not the SERVICE. The Jini ServiceID is intende to uniquely 
identify the service, and is not tied to any particular server. 

There is ongoing debate about numeric ids versus human readable ids.
The COBRA and Jini ids are numeric. The downside of this is that you
never find them on billboards, in TV adverts, etc. They can appear in
emails, etc, as you can copy and paste them without regard to 
human comprehension.

In early Jini specifications, this ServiceID was expected to be automatically
generated by lookup services. This has now changed to an expectation that
the server generates an id for each of its services. 

The Jini service id is a number, but that is no big deal: any hashing
algorithm can generate a number from a string, so a human readable
string can be used withe little chance of collision. With a minor
modification to the Jini API, strings can be used for service ids
as well as 128-bit numbers.

Jini URI
--------

One possibility could be  a Jini URI scheme. Such a scheme could look
like

	jini://class-hierarchy
as in

	jini://printer/laser/jans-home-printer

or - similar to an HTTP scheme - related to a domain under which I have 
control as in

   	jini://jan.com.au/printer

For any new URI scheme, a dereferencing mechanism is required. For this
Jini scheme, it would be

     locate a Jini lookup service
     lookup a Jini service using this URI
     if the lookup succeeds
     	cast the return object to our expected class type
	call methods on the object

This requires access to a Jini lookup service, and moreover, will only
succeed if the service has been registered with the lookup service.
This is currently more fragile than HTTP URIs which rely on DNS for
resolution of domains, as there is no Jini equivalent of the DNS
hierarchy of name servers. Such a hierarchy is possible, but it just
does not exist at present, and realistically could not be expected.

Removing the LUS?
----------------