JavaSpaces is a powerful Jini service specification from Sun Microsystems that provides a simple yet powerful infrastructure for building distributed applications. The JavaSpaces specification defines a reliable distributed repository for objects, along with support for distributed transactions, events and leasing. In the JavaSpaces programming model, applications are viewed as a group of processes, cooperating via the flow of objects into and out of "spaces."
Inspired by "Tuple-Spaces"
JavaSpaces is based on the concept of "tuple-spaces" first described in 1982 in the Linda programming language and system originally propounded by Dr. David Gelernter at Yale University. The public-domain Linda system is a coordination language for expressing parallel processing algorithms without reference to any specific computer or network architecture and provides interprocess coordination via virtual shared memories or tuple-spaces that can be accessed associatively.
The tuple-space model is especially useful for concurrent algorithms. Although JavaSpaces technology is strongly influenced by the Linda system, it differs from Linda in several ways - such as Java's richer typing, object orientation, subtype matching and transactional support spanning multiple spaces, leasing and events.
JavaSpaces in Today's Networked World
Although the programming model and concepts underlying JavaSpaces may at first seem abstract and theoretical, JavaSpaces does in fact provide an elegant and practical approach to solving common real-world scenarios in today's increasingly networked world. Distributed, collaborative and parallel applications can be solved using a JavaSpaces-based solution since JavaSpaces lends itself to applications such as trading services, reservation systems, online ordering systems, online auction systems, large computation-intensive jobs, workflow systems, mobile offices and agent technology.
A Distributed Algorithm as a Flow of Objects Between Spaces
Any application developed using JavaSpaces technology would need to be modeled as a flow of objects through one or more spaces. JavaSpaces represents a fundamentally different approach from that of the more traditional invocation of methods on remote objects or direct exchange of information between processes. With the method-invocation approach, specific remote interfaces are needed for each operation. With the JavaSpaces' flow-of-objects approach, on the other hand, only one interface is required: namely, the JavaSpaces interface (from the package net.jini.space).
What's a Space?
The term space refers to an implementation of the JavaSpaces service specification. Like the rest of the Java technology, there's a separation between the specification and its implementation of the specification. A number of vendors may provide implementations. A JavaSpaces client is expected to receive identical service and functionality from all such space implementations, though their internal designs may vary. A space, then, is a particular implementation of the specification and represents a persistent object exchange "area" via which remote processes can coordinate their actions and exchange data. The space thus provides a ubiquitous, cross-platform framework for distributed computing.
Advantages of JavaSpaces
The JavaSpaces model has numerous advantages:
Characteristics of the "Space"
- Multiple processes can access data concurrently.
- There is a loose coupling between senders and receivers, which enhances software reuse and flexibility of design.
- The model has extremely high scalability.
- At the same time it is simple, flexible and reliable.
- The space provides support for distributed events and leasing.
- Atomicity, transactional security, synchronization and coordinated concurrent access are inherently built into JavaSpaces.
A space is a shared, persistent, associative, transactionally secure and network-accessible repository for objects that allows processes to read, remove and insert objects into itself and thus communicate by such an exchange of objects through one or more spaces. Let's review the chief characteristics:
- Shared: A space is a network-accessible, shared region of memory with which multiple remote processes can concurrently interact. The space manages the details of concurrent access, leaving you to focus on your application's protocols.
- Persistent: A space provides a reliable storage mechanism. An object that is stored in a space will reliably remain in the space until it's removed from the space or until its lease time - as specified at the time of writing into the space - is up.
- Associative: A space supports an associative lookup mechanism. An "associative lookup" provides a means of finding objects of interest according to their content and type, rather than by name or memory location.
- Transactionally secure: A space supports a transaction model, which ensures that all operations on a space are atomic and transactionally secure. A single space transaction may include multiple operations on one or more spaces.
While within the space, objects can't be modified or methods invoked on them. Processes must exclusively remove objects from the space, update or invoke methods on the objects only while outside the space, and then reinsert objects back into the space, as required from the application standpoint. The insertion and removal of an entry into and from a space are guaranteed to be atomic.
Each implementation of a JavaSpaces service will export objects to the local client that implement the JavaSpaces interface (from package net.jini.space), via which the local client can interact with the remote JavaSpaces service. The JavaSpaces interface isn't a remote interface.
What Can Be Placed into the Space
A space stores "entries." An entry is a class in the Java platform that implements the Entry interface (package net.jini.core.entry) as defined in the Jini Entry Specification. Once you've created an entry, you're ready to perform operations that interact with the "space." Any class whose instances are intended to be written into a space or used as the basis of an associative lookup must implement the Entry interface.
Associative Lookup Using Templates
The associative lookup functionality provided by the space is based on the template's fields. A template is an entry object of the same class or a superclass of the entry of interest, with its fields set to values that will be matched against entries within the space in a read or take operation. Null fields in the template act as wild cards. In case there are multiple entries that match a template, only one will be returned. The space makes an arbitrary choice - there's no ordering of entries within the space.
The four primary operations that can be applied to a space are write, read, take and notify.
The write() operation places a copy of an entry object into the space such that the entry can subsequently be accessed via a read or take operation.
The read() operation returns an entry that matches the template, without removing the entry from the space. Multiple processes can read the same entry at the same time. If a matching entry isn't available immediately, the read() operation will wait for an entry to be introduced into the space, or until its timeout period is up. The constant JavaSpaces.NO_WAIT may be used as the timeout value, in which case the read request will return immediately, even if no matching entry is found. The readIfExists() works like the read() except that it returns immediately without waiting for the timeout period unless a matching entry happens to exist within a currently occurring transaction - in which case readIfExists() will wait up to its timeout value for that transaction to complete. Thus readIfExists() returns immediately except in cases when a matching value exists within a transaction.
The take() operation returns an entry that matches the template and simultaneously removes the entry from the space. The take() operation is atomic, thus ensuring synchronization and concurrency. The takeIfExists() operation works in a manner similar to the readIfExists() operation.
The notify() method is used to register interest in the arrival of an entry into the space that matches a specified template. The space notifies you that an entry that matches your template has arrived into the space. This notification and distributed event mechanism relies on the Jini distributed event model as described in the Jini Distributed Event Specification.
The concepts of entry, template and operations are central to JavaSpaces. Though fairly straightforward, they're immensely powerful.
Leasing and the Lease Interface
The Lease interface from the package net.jini.lease includes signatures for methods including getExpiration() and renew(). A request to write an entry into a space is accompanied by the requested lease time, the time for which the caller requests the entry to be stored within the space. The write operation actually returns a Lease object representing the lease time granted by the space, which may be less than the requested lease time. When the granted lease time is up, the entry is removed from the space. Thus any entry written into a space may be removed either explicitly with the take() operation or when its granted lease time is up. Once a lease has been granted for a finite period of time, it may subsequently be renewed. The lease time associated with a write operation may be requested and granted for the constant Lease.FOREVER, which means that the entry will remain in the space persistently until such time that it is explicitly removed from the space via a take operation. Leasing, as applicable to JavaSpaces, is defined in the Jini Distributed Leasing Specification. Leases and lease times may also be applied to transactions. Just as an entry is removed from a space when its lease time is up, a transaction will be aborted if it has not completed when its lease time is up, in which case none of the transaction's constituent operations will be committed.
JavaSpaces technology provides a distributed event model that uses the Jini event model as described in the Jini Distributed Event Specification. Just as the event model in the single JVM environment comprises the event source, event object and event listener, the Jini distributed model comprises the event source, the remote event object and the remote event listener. The space acts as the event source that fires events when entries are written into it and notifies processes that have registered interest in entries that match specified templates.
Transactional support is an essential aspect of any distributed service framework, and JavaSpaces technology provides a distributed transaction service based on the Jini transaction model as described in the Jini Distributed Transaction Specification. The JavaSpaces transaction model simplifies the use of the more general Jini transaction model, and provides a means of grouping multiple space operations on one or more spaces. A process that requires transactional functionality will need to look up the transaction manager (a remote service), obtain the transaction from the manager, then pass the transaction to each space-based application that's intended to be part of the transaction. The transaction manager oversees all transactions. A transaction is actually a leased resource; if a transaction is neither explicitly committed nor explicitly aborted, the transaction manager will abort it upon expiration of its lease. Transactions affect space operations in several ways: for instance, an entry that is returned by a read() operation that's part of a transaction can't be taken by a take() operation that's part of another transaction until the first transaction is completed.
Understanding JavaSpaces Techology in Relation to Other Technologies
JavaSpaces and Three-tier Architecture
A JavaSpaces application typically represents the middle tier of a three-tier model, since clients and servers throughout the network can exchange objects via the space. The main advantage is high scalability and concurrency. JavaSpaces technology supports the thin-client model.
JavaSpaces and J2EE
The J2EE technology groups several technologies - EJB, Java Servlets, JavaServer Pages, JavaMail, Java Message Service, JDBC, CORBA technology and so on. The emphasis is on interaction with existing enterprise resources and standardization so that the consumer's past and current investment in IT efforts is protected by the use of standard interfaces, ease of legacy integration and application server vendor/implementation independence. JavaSpaces and Jini represent a new and futuristic paradigm that endeavors to meet the complex needs of tomorrow's increasingly networked world by emphasizing dynamic communication, spontaneous "lookup 'n' discovery" and network enablement.
JavaSpaces and Messaging Systems
JavaSpaces goes far beyond a mere messaging system. It's a powerful and flexible service that provides a distributed object repository with persistence storage along with support for events, leasing and transactions. JavaSpaces isn't limited to any particular architecture such as point-to-point or publish/subscribe. For instance, publishers and subscribers in the publish/subscribe messaging architecture use subject-based messaging, while JavaSpaces provides a more flexible associative lookup by value and type.
JavaSpaces and JMS
Java Message Service provides a high-level generic interface to messaging products that support the JMS API. While both JavaSpaces and JMS represent a model with uncoupled senders and receivers, JavaSpaces provides support for leasing and represents a more generic model that is not limited to the point-to-point and publish/subscribe models supported by JMS.
JavaSpaces and Databases
Although JavaSpaces provides a distributed object persistence service, it's neither a relational nor an object database. A space is an unordered collection of objects that may contain data as well as the behavior. JavaSpaces focuses on supporting ease of writing distributed applications rather than merely providing a data repository functionality. There's also a difference in the querying mechanism supported by JavaSpaces in that querying is only for exact-match-or-don't-care for a particular field. A space can find, match and reference objects by both type and value, which means any object-based program or device can join a JavaSpaces system.
The JavaSpaces-related API is small-sized and simple, yet the concepts of space operations, distributed events, leases and transactions when applied together form a powerful infrastructure for building robust, large-scale, distributed applications.
- JavaSpaces Specification 1.0, Sun Microsystems 1999.
- Freeman, E., Hupfer, S., and Arnold, K. (1999). JavaSpaces: Principles, Patterns and Practice. Addison-Wesley.
- Waldo, J. "The End of Protocols." Java developer connection:
- Freeman, E., and Hupfer, S. Make Room for JavaSpaces, Parts 1, 2 and 3.
- Jini Entry Specification 1.0.1, Sun Microsystems 1999.
- Jini Entry Utilities Specification 1.0.1, Sun Microsystems 1999.
- Jini Distributed Leasing Specification 1.0.1, Sun Microsystems 1999.
- Jini Distributed Event Specification 1.0.1, Sun Microsystems 1999.
- Jini Distributed Transaction Specification 1.0.1, Sun Microsystems 1999.
Sanjay Mahapatra is a Sun certified Java 1.1 programmer and architect (Java Platform 2) and works for Cook Systems International, Inc., a consulting and solutions company. Sanjay can be contacted at: