 | ||
Stable release 2.2.3 (February 21, 2016; 12 months ago (2016-02-21)) [±] Website | ||
Jini (pronounced like genie i.e. /ˈdʒiːni/), also called Apache River, is a network architecture for the construction of distributed systems in the form of modular co-operating services.
Contents
Originally developed by Sun, Jini was released under an open source license (Apache license). Responsibility for Jini has been transferred to Apache under the project name "River".
History
Sun introduced Jini in July 1998. In November 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. Ken Arnold has joked that it means "Jini Is Not Initials", making it a recursive anti-acronym, but it has always been just Jini. The word 'jini' means "the devil" in Swahili; this is borrowed from the Arabic word for a mythological spirit, originated from the Latin genius, which is also the origin of the English word 'genie'.
Jini provides the infrastructure for the Service-object-oriented architecture (SOOA).
Using a service
Locating services is done through a lookup service. Services try to contact a lookup service (LUS), either by unicast interaction, when it knows the actual location of the lookup service, or by dynamic multicast discovery. The lookup service returns an object called the service registrar that can be used by services to register themselves so they can be found by clients. Clients can use the lookup service to retrieve a proxy object to the service; calls to the proxy translate the call to a service request, performs this request on the service, and returns the result to the client. This strategy is more convenient than Java remote method invocation, which requires the client to know the location of the remote service in advance.
Limitations
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