Jini, developed by Sun Microsystems, is a distributed system that simplifies the access to services in a network. The outstanding advantages of a network are resource sharing and the possibility to use re-mote data and services from different points. It is a classical challenge for a network to provide lookup services for clients and to establish the corresponding connections dynamically. However, in most cases such connections have to be made by means of manual network configuration. The task of Jini is to simplify this configuration task by using refined protocols for lookup and other services. The easy usage of networked devices and services is one of Jini's primary goal. Jini, positioned in an area that is often referred to as middleware, is a logical layer built upon JVMs, that are connected over an arbitrary network. A set of Jini-based computing devices is called a Djinn. In a Djinn we find three different kinds of entities.
|(at least one) lookup service|
A service is an abstract term for a resource that can be used via the network, like specific hardware (in our special case: sensors and/or actuators), software or a communication channel. A service user is the entity that uses one or more services. The protocol between service and service user is not defined at this stage, it is based on Java-based interfaces. Hence, the actual implementation of the communication between the two partners is defined by the service it-self (notice: the underlying code is loaded dynamically by the service user!). Last but not least the lookup service acts as the middleman between services and service users. In case someone wants to announce a new service at the Djinn, Jini provides the discovery protocol, that reveals all available lookup services. Afterwards the service may be registered by means of Jini's join protocol. If a service user is inclined to use a specific resource, the discovery protocol establishes once more a connection to an available lookup service. With the help of search attributes, the lookup service can find the services of interest. This is done by Jini's lookup protocol. Finally the service user can call the desired functions of the resource as indicated above. In addition to this basic lookup functionality (which is suitable for dynamic adding and removing services to/from a Djinn), Jini also addresses networking issues like temporarily missing devices (e.g. due to a system crash) or privacy, authorization and authentication. The underlying concepts are protocols for leasing, transactions, security and events. To underline the three basic protocols in a Jini environment, those are discussed in more detail below.
Before an EIB service can take advantage of other Jini services it must find one or more Jini communities (so called Djinns). This is done by finding the lookup services that keep track of the shared resources of that community. The process of finding available lookup services is called discovery. Jini supports several discovery protocols useful in different situations (for instance the Multicast Request Protocol useful for new services to find lookup services or the Unicast Request Protocol for services that already know the address of a particular lookup service).
The result of the discovery process is that the EIB service is handed one ore more references to the lookup services (ServiceRegistrar). Using these references the EIB service can advertise (publish) its facilities.
Downloadable proxies are one of Jini's key concepts. Hence, each EIB service contains
If an EIB service wants to announce its facilities it has to join all or some lookup services returned from the discovery process. This is done via the join protocol, so to say by the method register()provided by the ServiceRegistrar interface.
To ensure that a service is still up (and did not crash due to software, hardware or even communication errors) the service has to re-register from time to time. This technique is called leasing. If the lease is not renewed and the service goes away without cleaning up after itself, its leases will eventually expire and the service will drop out of the Djinn.
From the service user's point of view discovering the lookup service is the same as for services. Hence after a Multicast Request or Unicast Request the service user gets one or more references of the lookup services back. Once it has the reference it can "lookup" for certain services of interest. Again Jini provides several ways to do so, the most commonly used will probably be the ones based on searching for types of downloadable proxys and others based upon the searching for particular attributes. The process of finding is called lookup done via the method lookup()provided by the interface ServiceRegistrar.