Introduction to Jini and JavaSpaces
Jini is, in the words of the Sun FAQ:
A network architecture for the construction of distributed systems where scale, rate of change, and complexity of interactions within and between networks are extremely important and cannot be satisfactorily addressed by existing technologies. Jini technology provides a flexible infrastructure for delivering services in a network and for creating spontaneous interactions between clients that use these services regardless of their hardware or software implementations.
Jini-based systems are described as "network plug and play," which is a reference to the dynamic, discovery-based nature of interactions between clients and services in a Jini system.
Jini provides both an infrastructure and a programming model. The Jini infrastructure consists of a series of core service components that enable the distribution, discovery, security, and use of a federation of services. These core services include service registration and lookup, distributed event notification and messaging, principal and access control list security, and a model for distributed transactions.
Although Jini is not a complete grid framework, its core services provide a foundation for the construction of grid-like heterogeneous systems. Several initiatives are under way to extend the core Jini services to provide further grid-like functionality, such as scheduling and wide-area service discovery. An example of one such effort is the JGrid project, which is hosted at http://www.jini.org.
The Jini programming model extends the core Java classes to include semantics for distributed computing. This programming model is based on a set of interfaces defining public requirements for behaviors such as transactionality across nodes and distributed event subscription and notification. Another key concept of the model is embodied by the lease interface, which incorporates the notion of time into a reference to a non-local object. A Jini lease grants access to a service for a certain time period and can be renewable. Leases allow for the dynamic nature of a grid environment, in which services and clients join and leave the system. When a lease expires, resources allocated for the service can be freed on both the client and the provider. Leases on a service can be shared or exclusive.
In addition to its core services, Jini includes JavaSpaces, which is a distributed, associative, network-accessible, shared memory system implemented as a Jini service. At the highest level, a JavaSpace provides synchronized, transactional, read, write, and associative search access to objects in a persistent shared memory space. Contents of a JavaSpace are associative, meaning that they are addressed (searched) by their contents instead of a specific location identifier. Clients to a JavaSpace can use it to share information, including divisions of a problem that can be solved in a distributed and parallel fashion. JavaSpaces lends itself to blackboard-style processing, in which specialized processes take items from the shared board, perform their function, and then return results to the shared memory space. JavaSpaces is described in a Sun Microsystems specification as part of Jini, and a reference implementation called Outrigger is distributed with the Jini Starter Kit.
On their own, the concepts behind JavaSpaces are neither directly related nor limited to grid computing. JavaSpaces can, however, serve as an enabling technology for a class of useful services implemented on a grid.
The JavaSpaces associative blackboard-style system provides a very simple mechanism for communication between the nodes in a distributed system. Using the space as a means of communication and synchronization simplifies distributed design and development (as opposed to something like direct RPC [Remote Procedure Calls] or inter-node message passing). Nodes in the distributed system do not need to be directly aware of each other, do not need to share the same process or hardware, and can operate asynchronously. (You might think of the blackboard as an implementation of the Mediator pattern, which reduces the coupling between objects.) As a result, the blackboard method of communication alleviates the need for a centralized or even distributed resource border or meta-scheduler.
The JavaSpace model is based on David Gelernter and the Yale Linda Group's Linda Coordination Language. The Linda model defines a shared "tuple-space," which functions like a blackboard in which nodes in a distributed system can read from and write to. A tuple in the space is a vector of data values. The nodes use simple operations to access the tuple-space blackboard. A typical distributed system based on a tuple space has producers and consumers of tuples. Producer nodes populate the space with some kind of tuple representing partitions of a problem. Consumer nodes take tuples from the space and perform some task, possibly placing results back into the space as different tuples. This arrangement is sometimes referred to as the Master-Worker or Compute Server pattern.
A JavaSpace provides the same basic operations as a Linda "blackboard:"
write. Writes an entry (tuple) to the space.
read and readIfExists. Reads a entry from the space based on a template. read will block until a matching entry is available; readIfExists will not.
take and takeIfExists. Removes an entry from the space based on a template. take will block until a matching entry is available; takeIfExists will not.
notify. Requests notification when an entry matching a template is written to the space.
The JavaSpace version of a Linda tuple is called an entry and described by the net.jini.core.entry.Entry tagging interface. An entry is defined by its public reference-typed, serializable attributes, which are the only part of an entry that will be moved to and from the space. For those familiar with Linda, an entry differs from a Linda tuple in that it is strongly typed and may contain behavior (methods) in addition to data (attributes).
JavaSpaces (and tuple spaces in general) are well-suited to solve problems that avail themselves to blackboard-style solutions or more generally, implementations following the compute-server pattern. These problems are usually not IO-intensive and are easily subdivided and parametrized.