JS.1.1. The JavaSpaces Application Model and Terms
A JavaSpaces service holds entries. An entry is a typed group of objects, expressed in a class for the Java platform that implements the interface net.jini.core.entry.Entry. Entries are described in detail in The Jini Technology Core Platform Specification, “Entry”.
An entry can be written into a JavaSpaces service, which creates a copy of that entry in the space [2] that can be used in future lookup operations.
[2] The term “space” is used to refer to a JavaSpaces service implementation.
You can look up entries in a JavaSpaces service using templates, which are entry objects that have some or all of its fields set to specified values that must be matched exactly. Remaining fields are left as wildcards—these fields are not used in the lookup.
There are two kinds of lookup operations: read and take. A read request to a space returns either an entry that matches the template on which the read is done, or an indication that no match was found. A take request operates like a read, but if a match is found, the matching entry is removed from the space.
You can request a JavaSpaces service to notify you when an entry that matches a specified template is written. This is done using the distributed event model contained in the package net.jini.core.event and described in The Jini Technology Core Platform Specification, “Distributed Events”.
All operations that modify a JavaSpaces service are performed in a transactionally secure manner with respect to that space. That is, if a write operation returns successfully, that entry was written into the space (although an intervening take may remove it from the space before a subsequent lookup of yours). And if a take operation returns an entry, that entry has been removed from the space, and no future operation will read or take the same entry. In other words, each entry in the space can be taken at most once. Note, however, that two or more entries in a space may have exactly the same value.
The architecture of JavaSpaces technology supports a simple transaction mechanism that allows multi-operation and/or multi-space updates to complete atomically. This is done using the two-phase commit model under the default transaction semantics, as defined in the package net.jini.core.transaction and described in The Jini Technology Core Platform Specification, “Transaction”.
Entries written into a JavaSpaces service are governed by a lease, as defined in the package net.jini.core.lease and described in The Jini Technology Core Platform Specification, “Distributed Leasing”.
JS.1.1.1. Distributed Persistence
Implementations of JavaSpaces technology provide a mechanism for storing a group of related objects and retrieving them based on a value-matching lookup for specified fields. This allows a JavaSpaces service to be used to store and retrieve objects on a remote system.
JS.1.1.2. Distributed Algorithms as Flows of Objects
Many distributed algorithms can be modeled as a flow of objects between participants. This is different from the traditional way of approaching distributed computing, which is to create method-invocation-style protocols between participants. In this architecture’s “flow of objects” approach, protocols are based on the movement of objects into and out of implementations of JavaSpaces technology.
For example, a book-ordering system might look like this:
A book buyer wants to buy 100 copies of a book. The buyer writes a request for bids into a particular public JavaSpaces service.
The broker runs a server that takes those requests out of the space and writes them into a JavaSpaces service for each book seller who registered with the broker for that service.
A server at each book seller removes the requests from its JavaSpaces service, presents the request to a human to prepare a bid, and writes the bid into the space specified in the book buyer’s request for bids.
When the bidding period closes, the buyer takes all the bids from the space and presents them to a human to select the winning bid.
A method-invocation-style design would create particular remote interfaces for these interactions. With a “flow of objects” approach, only one interface is required: the net.jini.space.JavaSpace interface.
In general, the JavaSpaces application world looks like this:
Clients perform operations that map entries or templates onto JavaSpaces services. These can be singleton operations (as with the upper client), or contained in transactions (as with the lower client) so that all or none of the operations take place. A single client can interact with as many spaces as it needs to. Identities are accessed from the security subsystem and passed as parameters to method invocations. Notifications go to event catchers, which may be clients themselves or proxies for a client (such as a store-and-forward mailbox).
JS.1.2. Benefits
JavaSpaces services are tools for building distributed protocols. They are designed to work with applications that can model themselves as flows of objects through one or more servers. If your application can be modeled this way, JavaSpaces technology will provide many benefits.
JavaSpaces services can provide a reliable distributed storage system for the objects. In the book-buying example, the designer of the system had to define the protocol for the participants and design the various kinds of entries that must be passed around. This effort is akin to designing the remote interfaces that an equivalent customized service would require. Both the JavaSpaces system solution and the customized solution would require someone to write the code that presented requests and bids to humans in a GUI. And in both systems, someone would have to write code to handle the seller’s registrations of interest with the broker.
The server for the model that uses the JavaSpaces API would be implemented at that point.
The customized system would need to implement the servers. These servers would have to handle concurrent access from multiple clients. Someone would need to design and implement a reliable storage strategy that guaranteed the entries written to the server would not be lost in an unrecoverable or undetectable way. If multiple bids needed to be made atomically, a distributed transaction system would have to be implemented.
All these concerns are solved in JavaSpaces services. They handle concurrent access. They store and retrieve entries atomically. And they provide an implementation of the distributed transaction mechanism.
This is the power of the JavaSpaces technology architecture—many common needs are addressed in a simple platform that can be easily understood and used in powerful ways.
JavaSpaces services also help with data that would traditionally be stored in a file system, such as user preferences, e-mail messages, and images. Actually, this is not a different use of a JavaSpaces service. Such uses of a file system can equally be viewed as passing objects that contain state from one external object (the image editor) to another (the window system that uses the image as a screen background). And JavaSpaces services enhance this functionality because they store objects, not just data, so the image can have abstract behavior, not just information that must be interpreted by some external application(s).
JavaSpaces services can provide distributed object persistence with objects in the Java programming language. Because code written in the Java programming language is downloadable, entries can store objects whose behavior will be transmitted from the writer to the readers, just as in an RMI using Java technology. An entry in a space may, when fetched, cause some active behavior in the reading client. This is the benefit of storing objects, not just data, in an accessible repository for distributed cooperative computing.
JS.1.3. JavaSpaces Technology and Databases
A JavaSpaces service can store persistent data which is later searchable. But a JavaSpaces service is not a relational or object database. JavaSpaces services are designed to help solve problems in distributed computing, not to be used primarily as a data repository (although there are many data storage uses for JavaSpaces applications). Some important differences are:
Relational databases understand the data they store and manipulate it directly via query languages. JavaSpaces services store entries that they understand only by type and the serialized form of each field. There are no general queries in the JavaSpaces application design, only “exact match” or “don’t care” for a given field. You design your flow of objects so that this is sufficient and powerful.
Object databases provide an object oriented image of stored data that can be modified and used, nearly as if it were transient memory. JavaSpaces systems do not provide a nearly transparent persistent/transient layer, and work only on copies of entries.
These differences exist because JavaSpaces services are designed for a different purpose than either relational or object databases. A JavaSpaces service can be used for simple persistent storage, such as storing a user’s preferences that can be looked up by the user’s ID or name. JavaSpaces service functionality is somewhere between that of a filesystem and a database, but it is neither.
JS.1.4. JavaSpaces System Design and Linda [3] Systems
[3] “Linda” is the name of a public domain technology originally propounded by Dr. David Gelernter of Yale University. “Linda” is also claimed as a trademark for certain goods by Scientific Computing Associates, Inc. This discussion refers to the public domain “Linda” technology.
The JavaSpaces system design is strongly influenced by Linda systems, which support a similar model of entry-based shared concurrent processing. In Section JS.4.1, “Linda Systems”, you will find several references that describe Linda-style systems.
No knowledge of Linda systems is required to understand this specification. This section discusses the relationship of JavaSpaces systems with respect to Linda systems for the benefit of those already familiar with Linda programming. Other readers should feel free to skip ahead.
JavaSpaces systems are similar to Linda systems in that they store collections of information for future computation and are driven by value-based lookup. They differ in some important ways:
Linda systems have not used rich typing. JavaSpaces systems take a deep concern with typing from the Java platform type-safe environment. In JavaSpaces systems, entries themselves, not just their fields, are typed—two different entries with the same field types but with different data types for the Java programming language are different entry types. For example, an entry that had a string and two double values could be either a named point or a named vector. In JavaSpaces systems these two entry types would have specific different classes for the Java platform, and templates for one type would never match the other, even if the values were compatible.
Entries are typed as objects in the Java programming language, so they may have methods associated with them. This provides a way of associating behavior with entries.
As another result of typed entries, JavaSpaces services allow matching of subtypes—a template match can return a type that is a subtype of the template type. This means that the read or take may return more states than anticipated. In combination with the previous point, this means that entry behavior can be polymorphic in the usual object-oriented style that the Java platform provides.
The fields of entries are objects in the Java programming language. Any object data type for the Java programming language can be used as a template for matching entry lookups as long as it has certain properties. This means that computing systems constructed using the JavaSpaces API are object-oriented from top to bottom, and behavior-based (agent-like) applications can use JavaSpaces services for co-ordination.
Most environments will have more than one JavaSpaces service. Most Linda tuple spaces have one tuple space for all cooperating threads. So transactions in the JavaSpaces system can span multiple spaces (and even non-JavaSpaces system transaction participants).
Entries written into a JavaSpaces service are leased. This helps keep the space free of debris left behind due to system crashes and network failures.
The JavaSpaces API does not provide an equivalent of “eval” because it would require the service to execute arbitrary computation on behalf of the client. Such a general compute service has its own large number of requirements (such as security and fairness).
On the nomenclature side, the JavaSpaces technology API uses a more accessible set of terms than the traditional Linda terms. The term mappings are “entry” for “tuple,” “value” for “actual,” “wildcard” for “formal,” “write” for “out,” and “take” for “in.” So the Linda sentence “When you ‘out’ a tuple make sure that actuals and formals in ‘in’ and ‘read’ can do appropriate matching” would be translated to “When you write an entry make sure that values and wildcards in take and read can do appropriate matching.”
JS.1.5. Goals and Requirements
The goals for the design of JavaSpaces technology are:
Provide a platform for designing distributed computing systems that simplifies the design and implementation of those systems.
The client side should have few classes, both to keep the client-side model simple and to make downloading of the client classes quick.
The client side should have a small footprint, because it will run on computers with limited local memory.
A variety of implementations should be possible, including relational database storage and object-oriented database storage.
It should be possible to create a replicated JavaSpaces service.
The requirements for JavaSpaces application clients are:
It must be possible to write a client purely in the Java programming language.
Clients must be oblivious to the implementation details of the service. The same entries and templates must work in the same ways no matter which implementation is used.
JS.1.6. Dependencies
This document relies upon the following other specifications:
Jini Entry Utilities Specification,
Java Object Serialization Specification
Java Remote Method Invocation Specification
Jini Technology Core Platform Specification,
Section “Entry”
Section “Distributed Events”
Section “Distributed Leasing”
Section “Transaction”