JavaSpaces « Library Product « Java Articles

Building distributed applications with conventional network tools usually entails passing messages between processes or invoking methods on remote objects. In JavaSpaces applications, in contrast, processes don't communicate directly, but instead coordinate their activities by exchanging objects through a space, or shared memory. A process can write new objects into a space, take objects from a space, or read (make a copy of) objects in a space; Figure 1 depicts several processes (represented by Dukes) interacting with spaces using these operations. When taking or reading objects, processes use simple matching, based on the values of fields, to find the objects that matter to them. If a matching object isn't found immediately, then a process can wait until one arrives. In JavaSpaces, unlike conventional object stores, processes don't modify objects in the space or invoke their methods directly -- while there, objects are just passive data. To modify an object, a process must explicitly remove it, update it, and reinsert it into the space.

In addition, there was significant interest in continuing to advance the JavaSpaces technology, and a number of areas were suggested for its improvement. One problem that the conference attendees wanted to confront was the painful process of setting up and running JavaSpaces (as well as Jini) for the first time -- probably the greatest barrier to using the technology. This problem is now being addressed in a new working group started by Ken Arnold, called Out of the Box (for more information, see the Resources section at the end of the article). Another area of community effort involves the development of helper or utility interfaces and classes that provide a valuable set of tools for new JavaSpaces developers. This article is based around one of those tools in particular: the compute server.

In general, transactional systems let you group together a set of operations so that they are performed atomically -- that is, either all of the operations complete, or none of them do. Without this transactional ability, the states of systems can easily become inconsistent -- especially distributed systems in which participants can crash the network or leave the network before an operation has completed. By using transactions, you can ensure that the operations do complete, or if they don't, that the state of the entire distributed system remains unchanged.

Despite its admirable properties, the compute server still isn't quite ready for the real world yet. In this article, I'll show you how to make two big improvements to gear the system up for real-world use. If you read Part 4 of this series, you've probably guessed that one of the compute server's weaknesses is that it neglects to account for the presence of partial failure. Armed with what you know about Jini transactions from that article, I'll now have you revisit the compute server code and show you how to make it more fault tolerant. Another potential shortcoming of the compute server is its use of a single JavaSpace, running on a single CPU. Under some circumstances, reliance on one space may introduce a bottleneck, so I'll revisit the compute server code to show how you can make use of multiple spaces to allow for greater scalability.

This month I'll show you how to use JavaSpaces to coordinate processes in a networked environment. At the same time, I'll start tying JavaSpaces and Jini closer together. If you've experimented with JavaSpaces, you already know that it is implemented on top of Jini. In fact, a new article, "The Nuts and Bolts of Compiling and Running JavaSpaces Programs" (see Resources), can help you get your JavaSpaces programs up and running, which can be a frustrating task, given all the Jini machinery needed underneath. What may not be as clear is that JavaSpaces is a powerful tool for communication and coordination between a Jini federation's entities. In particular, space-based communication and coordination works well in the Jini networked environment, where entities may rapidly appear and disappear at will (or against their will, in the case of machine, software, or network failures).

JavaSpaces is, in very simple terms, a kind of client/server map, a grid in which data lives. This map doesn't have a distinct key, using a sort of query-by-example to retrieve data. It also has notification capabilities.

Despite the simplicity of the JavaSpaces API, setting up, compiling, and running JavaSpaces programs can be frustrating, given that it depends heavily on the Jini technology infrastructure underneath. This article steps you through the details of setting up your machine environment, compiling JavaSpaces programs, and correctly running them (whether you're working on a Windows or Solaris platform). Along the way I'll explain why things are set up the way they are and how you can configure your environment such that your code will be likely to work in a production environment (one in which clients and servers run across multiple machines, as opposed to the single machine you're likely to start out developing and testing your code on). If you'd like to learn more about the JavaSpaces API and concepts, you may want to take a detour to some of the references listed under Resources; this article focuses purely on the nuts and bolts of getting your JavaSpaces programs up and running.

Unlike sequential programs, space-based programs often make use of unordered data structures -- in other words, collections of objects. These collections are sometimes called bags, because they are like bags of objects. With ordered collections, you pinpoint and manipulate specific elements in the structure; with unordered collections, you perform just two basic operations: put (i.e., add a new object to the collection) and get (i.e., remove and return any object from the collection). Think of a box that holds raffle tickets. If you want to participate, you fill out a ticket with your information and just throw it into the box, without caring where it goes. When the contest is over, someone reaches into the box and grabs an arbitrary card -- any card will do. Bags are very easy to create in space-based programs: to create one, you simply define an entry class and write as many instances of that entry into the space as you want.

Clustering solution designers can select supporting technology from anywhere in the spectrum. We can see that the JavaSpaces solution ranks quite high, while the JavaGroups solution that we looked at last time ranks slightly lower. In the next and final article in this series, we will take a closer look at an exciting emerging distributed systems fabrication technology that ranks even higher than JavaSpaces on the conceptual spectrum, and see how it can help us to do more with less code when designing high-impact Web tier clustering solutions.