Jini

From Wikipedia, the free encyclopedia
Jump to: navigation, search
jini
Stable release 2.2.2 (November 18, 2013; 4 months ago (2013-11-18)) [±]
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]

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. Ken Arnold has joked that it means "Jini Is Not Initials", making it a recursive anti-acronym,[3] 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'.

Jini provides the infrastructure for the Service-object-oriented architecture (SOOA).

Using a service[edit]

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[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]

References[edit]

External links[edit]