What is Jini its trick? What are the principles behind the interface? How can we implement these principles. According to Sun Microsystems, the company which invented Jini, we should use Java over an TCP/IP network. So practically speaking, I will approach Jini as a set of Java Programming Interfaces and a protocol stack. Note that basic knowledge of object-oriented programming and TCP/IP networks is assumed.
The following subjects will be treated:
Jini offers a way to make devices automatically form a network. After connecting Jini-enabled devices to a network, they spontaneously form a community, working together to get the job done.
Jini defines a runtime infrastructure, meaning the combination of logical connections and their states between different Jini devices. This can be a computer capable of running Java, which is connected to the network. This runtime infrastructure resides on the network and offers techniques to add, remove, change and locate services. It can reside in three places: in clients, in Jini devices (or service providers) and in lookup services. A lookup service is a central point of communication. When devices are connected to the network, they register themselves at the lookup service. This is so clients can find services; they just check the lookup service.
The runtime infrastructure uses one protocol on networklayer, called discovery and two protocols on the object-level: join and lookup. Discovery makes communication possible between devices and lookup services. With Join, a device can register itself at the lookup service. With Lookup, clients can search for a certain service.
Let us look at a practical example. Let us take a digital photocamera which connects to the network. As soon as the connection is built, the camera broadcasts a presence announcement targeted to a certain well-known port number. This special packet contains an IP address and a port number on which the camera can be reached and some other stuff.
Lookup services listen to the network, alert for any presence announcements. When a lookup service receives one, he checks its contents. From the contents, the lookup service can determine whether or not he should contact the sender of the presence announcement. Suppose our camera wants the lookup services to contact him. In that case, the lookup service constructs a TCP connection to the IP address and port number provided by the presence announcement package. Through RMI (Remote Method Invocation) the lookup service sends an object called the service registrar to the camera. The purpose of the object is to provide the camera with a way to communicate with the lookup service. Or more specific: when the camera calls methods of the just received object, it can do join and lookup actions on the lookup service. The camera would then register its service with a join. This service is of course providing the pictures which the camera has saved in its memory.
When a Jini-device (also called a service provider) has done a join, it is part of the community of services which are registered in the lookup service. For this join, the service provider calls the register() method and passes a service item object along as its parameter. This object is actually a collection of objects which together describe the service. The lookup service in its turn saves the service item object for later use. Now, the service is registrated by the lookup service.
Amongst the collection of objects which are kept together by the service item object, resides one with the name service object. This object is used by clients to communicate with the service provider. It can contain numerous attributes, such as version information, manufacturer information, icons for a user interface, actually anything which can be put in an object.
Service objects usually implement one or more interfaces with which the clients can communicate with the service. For example, a lookup service is a Jini-service and its service object is the service registrar. The register() method which is called by service providers while they joined, is declared in the ServiceRegistrar interface, which all service registrar objects implement. Clients and service providers talk to the lookup service through the service registrar object by calling methods which are declared in the ServiceRegistrar interface. Related to the cam, it could provide a service object which implements an image retrieval service. Clients would do lookup and then grab data by using the image retrieval service.
When a service has registered itself at a lookup service through the join process, this service is available for other devices doing the lookup thing. It is in this way, that clients can call for help by a service.
To do a lookup, the clients calls the lookup() method of a service registrar object (which is obtained by discovery). The client passes, as a parameter, an object called a service template. This is an object containing certain criteria. The service template can contain a number of attributes which must exactly match the service items as they have been uploaded by the several service providers. Optionally, the service template attributes can contain wildcards for a more loose selection. Of special interest is the serviceID attribute, which uniquely identifies services. The result of this whole lookup() method is a reference to zero or more service objects.
I've shown you what makes Jini so special: the separation of interface and implementation. A service object can offer services to clients on many different ways. The object can represent the whole service, which can be downloaded (by using Lookup) and then locally executed. Also, the service object can act as a kind of proxy towards a remote server.
One important consequence of Jini's architecture is that the network protocol between a representing service object and the belonging server has not to be known by the client. The network protocol is part of the service implementation. And it is chosen by the developers of the service. The client doesn't need to know anything about network protocols, because it can talk to the interface! And since the interface is implemented by the service object, this object does all the network communication.
I've also shown you how different implementations of the same service interface can use completely different implementations and network protocols. A service can use specialized hardware or handle all requests by software. Or both. Or both, related to a timeline! The service object, as it is used by the client, is just an interface for the client.
In my opinion, the beautiful thing about Jini is that it pulls up the level of abstraction. Namely, from network-protocol layer to object-interface layer. With Jini, all sorts of embedded devices can be hung onto the network -- Jini makes any agreement between device manufacturers unneccesary on the subject of network-protocol layer. They only need to talk about the Java interface through which devices communicate. When this is done, the idea of the spontaneously formed community becomes reality.
Sources
For more information related to Jini, you could check the following sites:
http://www.sunmicrosystems.com/
Last updated April 2001