Make room for JavaSpaces, Part 1
Ease the development of distributed apps with JavaSpaces
Page 2 of 5
Figure 1. Processes use spaces and simple operations to coordinate activities
Copyright Sun Microsystems, Inc.
Spaces are object stores with several important properties that contribute to making JavaSpaces a powerful, expressive tool.
Let's take a closer look:
- Spaces are shared: Many remote processes can interact with a space concurrently -- the space itself handles the details of concurrent access,
leaving you to focus on the design of the high-level protocols between your processes.
- Spaces are persistent: Spaces provide reliable storage for objects. When you store an object in a space, it will remain there indefinitely until
it is removed. You can also request a lease time during which an object should be stored. Once stored in the space, an object will remain there until its lease time (which
can be renewed) is over, or until a process explicitly removes it. We will discuss leases in more depth later in this series.
- Spaces are associative: Objects in a space are located via associative lookup, not by memory location or by identifier. Associative lookup provides a simple means of finding the objects in which you're
interested according to their content, without having to know what the object is called, who created it, or where it is stored.
To look up an object, you create a template (an object with some or all of its fields set to specific values, and the others left as
null to act as wildcards). An object in the space matches a template if it matches the template's specified fields exactly. You'll
see that, with associative lookup, you can easily express queries for objects such as "Are there any tasks to compute?" or
"Are there any answers to the prime factor I asked for?"
- Spaces are transactionally secure: JavaSpaces makes use of Jini's transaction service to ensure that an operation on a space is atomic (either the operation
is applied, or it isn't). Transactions are supported for single operations on a single space, as well as multiple operations
over one or more spaces (either all the operations are applied, or none are). As you will see later in the series, transactions
are an important way to deal with partial failure.
- Spaces let you exchange executable content: While in a space, objects are just passive data -- you can't modify them or invoke their methods. However, when you read
or take an object from a space, a local copy of the object is created. As with any other local object, you can modify its
public fields and invoke its methods, even if you've never seen an object like it before. This capability gives you a powerful
mechanism for extending the behavior of your applications through a space.
As this series progresses, we will show you how these properties play a key part in letting you create distributed applications
that work well in the Jini environment, where networking is often spontaneous, and processes join and leave the computation
dynamically, sometimes because of device or network failure.
Origins of JavaSpaces
We've described JavaSpaces as a new distributed computing model, but its origins can be traced back to Yale University in
the early 1980s. There, Dr. David Gelernter developed a tool called Linda for creating distributed applications. Linda consists of a small number of operations combined with a persistent store called
a tuple space. These operations are orthogonal to any particular programming language; they are part of a coordination language that can be added to any other computation language. The result of the Linda research was surprising: by using an object store along with a small number of simple operations,
you can easily implement a large class of parallel and distributed problems using techniques that alleviate many of the pitfalls
of building networked systems. In other words, space-based systems are not only simple (requiring only a few operations),
but also expressive (lending themselves well to solving many distributed problems).