Jini
From Wikipedia, the free encyclopedia
 |
This article or section contains information about computer software currently in development. The content may change as the software development progresses. |
 |
Jini (pronounced like genie and also called Apache River) is a network architecture for the construction of distributed systems in the form of modular co-operating services.
Originally developed by Sun, responsibility for Jini is being transferred to Apache under the project name River.
Contents |
[edit] Overview
Jini provides facilities for dealing with some of the Fallacies of Distributed Computing, problems of system evolution, resiliency, security and the dynamic assembly of service components. Code mobility is a core concept of the platform and provides many benefits including non-Protocol dependence.
The Jini team at Sun Microsystems has always stated that Jini is not an acronym. Some have joked that it meant Jini Is Not Initials, but it's always been just Jini. The word "Jini" means "the devil" in Kiswahili; this is a loan from an Arabic word for a mythological spirit, which is also the origin of the English word 'genie'.
One of the goals of Jini is to shift the emphasis of computing away from the traditional disk-drive oriented approach, to a more network oriented approach. Thus resources can be used across a network as if they were available locally. Jini is based on Java, and is similar to RMI but more advanced. Jini allows more advanced searching for services, through a process of discovery of published services (making Jini more similar to the SOA concept).
There are three main parts to a Jini scenario. These are the client, the server, and the lookup service.[1]
The service is the resource which is to be made available in the distributed environment. This can include physical devices (such as printers or disk drives) and software services (for example a database query or message service). The client is the entity which uses the service.
[edit] Using a service
The first step in creating a Jini service is for the service to find the lookup service (LUS) - a process called discovery. Once the LUS is found, it returns a Service Registrar object to the service, which is used to register the service in the lookup (the join process). This involves providing information about the service to be provided, such as the ID of the service, the object which actually implements it and other attributes of the service.
When a client wishes to make use of a service, it too uses discovery to find the LUS - either by unicast interaction, when it knows the actual location of the LUS, or by dynamic multicast discovery. After contacting the LUS, the client is returned a Service Registrar object, which it uses to look up a particular service. It does this by consulting the lookup catalogue on the LUS and searching based on the type, name or description of a service. The LUS will return a Java proxy, specifying how to connect directly to the service. This is one of the ways in which Jini is more powerful than RMI, which requires the service to know the location of the remote service in advance.
Using the Proxy, the client may connect directly to the service implementation (without further interaction with the LUS), and use it as if it were a local service. However, there are some differences to the event model, in that the order of events occurring across a network cannot be guaranteed.
Services in Jini will not necessarily be permanently available, which leads to the concept of leasing. When a service registers with a LUS, a lease is granted, with a certain duration. This can be manually decided, or set to a default (such as 'forever'). Leases will need to be periodically renewed, to check a service is still 'alive', which means if a service fails or becomes unreachable, it can be timed out.
Jini uses serialization to send Java objects across the network. This means an entire Java object can be saved and sent, and used remotely as if it were local, as opposed to creating a specific format for sending data in each new implementation.
Jini services can be grouped together, to allow a client to search for specific groups. A group of services in Jini is called a federation.
[edit] Limitations
Because Jini uses a lookup service to broker communication between the client and service, it is essentially a centralized model (though the communication between client and service can be seen as decentralized). This means that it does not scale well to very large systems. Jini is usually used only within intranets and internal networks, as opposed to as an internet-wide structure. Companies providing services to other companies (in the new trend to treat IT as a utility) would be unlikely to use Jini, instead relying on an SOA approach based on more general (not language specific) technologies like WSDL and SOAP.
[edit] See also
- Java RMI
- Ken Arnold, one of the original Jini architects
- Juxtapose (JXTA)
- Java Management Extensions (JMX)
- JavaSpaces
- Simple Network Management Protocol (SNMP)
- Zero Configuration Networking
- OSGi Alliance
- Service Location Protocol
- Salutation
- Universal Plug and Play (UPnP)
[edit] References
- ^ Taylor, Ian J. From P2P to Web Services and Grids - Peers in a Client/Server World. Springer, 2005
[edit] External links
- Jini.org
- Apache River Project
- The Jini Technology Vision
- Citations from CiteSeer
- technique comparison
- Article "Jini: Out of the Bottle and Into the Box" by Daniel H. Steinberg
- Project Rio
- Jan Newmarch's Guide to Jini Technologies
- Newton Open source Jini & OSGi based distributed component framework
- Bantam - an open-source web framework for distributed systems
|
||||||||||||||
