Jini
| Stable release | 2.2.0 (May 6, 2013) [±] |
|---|---|
| Website | http://river.apache.org/ |
Jini (pronounced like genie i.e. /ˈdʒini/), 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, Jini was released under an open source license (Apache license).[1] Responsibility for Jini has been transferred to Apache under the project name "River".[2]
Contents |
History[edit]
Sun introduced Jini in July 1998. In November of 1998, Sun announced that there were some firms supporting Jini.
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 has always been just Jini. The word 'jini' means "the devil" in Swahili; this is a loan from an Arabic word for a mythological spirit, which is also the origin of the English word 'genie'.
Using a service[edit]
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 catalog 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 Java remote method invocation, which requires the service to know the location of the remote service in advance.
Limitations[edit]
Jini uses a lookup service to broker communication between the client and service. This appears to be a centralized model (though the communication between client and service can be seen as decentralized) that does not scale well to very large systems. However, the lookup service can be horizontally scaled by running multiple instances that listen to the same multicast group.
See also[edit]
- Ken Arnold, one of the original Jini architects
- Juxtapose (JXTA)
- Java Management Extensions (JMX)
- Simple Network Management Protocol (SNMP)
- Zero Configuration Networking
- OSGi Alliance
- Service Location Protocol
- Universal Plug and Play (UPnP)
- Device Profile for Web Services (DPWS)
References[edit]
External links[edit]
- Jini.org (link broken: http://www.jini.org/)
- Apache River Project
- The Jini Technology Vision
- Citations from CiteSeer
- 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
