JavaSpaces

Navigate Concurrent Programming topic: Threads and Runnables Basic Synchronization Client Server Programming Remote Method Invocation (RMI) Enterprise JavaBean Programming (EJB) Java Spaces Programming (Jini)

After J2EE, Sun had a vision about the next step of network computing: in a network environment, there would be many independent services and consumers. That is JavaSpaces. JavaSpaces would allow these services/consumers to interact dynamically with each other in a robust way. It can be viewed as an object repository that provides a distributed persistent object exchange mechanism (persistent can be in memory or disk) for Java objects. It can be used to store the system state and implement distributed algorithms. In a JavaSpace, all communication partners (peers) communicate by sharing state. It is an implementation of the Tuple spaces idea.

JavaSpaces is used when someone wants to achieve scalability and availability and at the same time reducing the complexity of the overall system.

Processes perform simple operations to write new objects into a JavaSpace, take objects from a JavaSpace, or read (make a copy of) objects from the JavaSpace.

In conventional applications, objects are assembled from the database before presenting to the end user. In JavaSpace applications, we keep the ready made "end user" objects and store them in the JavaSpace. In JavaSpace applications the services are decoupled from each other; they communicate through objects that they write and read/take from the JavaSpace. Services search for objects that they want to take or read from the Space by using template object.

JINI

JavaSpaces technology is part of the Java Jini technology. The basic features of JINI are:

• No user intervention is needed when services are brought on or offline. (In contrast to EJBs where the client program has to know the server and port number where the EJB is deployed. In JINI the client is supposed to find, discover the service in the network.)
• Self healing by adapting when services (consumers of services) come and go. Services need to periodically renew a lease to indicate that they are still available.
• Consumers of JINI services do not need prior knowledge of the service's implementation. The implementation is downloaded dynamically and run on the consumer JVM, without configuration and user intervention. For example, the end user may be presented with slightly different user interface depending which service is being used at the time. The implementation of those user interface code would be provided by the service being used.

This fact that the implementation is running on the consumer/client's JVM can increase performance, by eliminating the need of remote calls.

A minimal JINI network environment consists of:

• One or more services
• A lookup-service keeping a list of registered services
• One or more consumers

The JINI Lookup Service

The lookup service is described in the : Jini Lookup Service Specification (reggie). This service interface defines all operations that are possible on the lookup service. Clients locate services by requesting with a lookup server that implements a particular interface. Client asks the lookup server for all services that implement the particular service interface. The lookup service returns service objects for all registered services that implement the given interface. The client may invoke methods on that object in order to interact directly with the server.

Lookup Discovery

Jini Discovery and Join Specification describes how does the client find the jini lookup service. There is a protocol to do that, jini comes with a set of API's that implement that protocol. The Jini Discovery Utility Specification defines a set of utility classes that are used to work with the protocol.

Leasing

When a service registers with the lookup service, it receives a lease from the lookup service, described in the Jini Distributed Leasing Specification.