Imagine the computing power you would have if you could link the processors of every computer in your company. That’s what JavaSpaces technology is designed to do. And the authors of JavaSpaces Principles, Patterns, and Practice predict that such distributed computing will revise the way we look at application development and deployment in the next decade.

So far, distributed computing has been used mostly in academia and for large research projects. The business-use possibilities certainly haven’t been tapped yet, probably because distributed computing is so complex and has required the sharpest of the sharp.

But the purpose of JavaSpaces technology is to make it easier to build distributed environments. Will distributed computing go mainstream? I can’t say. What I do know is that JavaSpaces seems to hold potential as a way to take advantage of the processing capabilities of devices on your network and make you think twice about the way you handle transactions and move data around. In this article, I’ll introduce you to some of the concepts surrounding this innovative technology.

JavaSpaces in theory
If you’ve heard of the Search for Extraterrestrial Intelligence (SETI) project, you already know something about distributed computing. SETI lets you volunteer your Internet-connected computer processor, when you’re not using it, to download and analyze radio telescope data in the quest for intelligent life in outer space. Although the SETI platform and program are built as a single unit and are not using JavaSpaces, they serve as an example of distributed computing.

Officially introduced in 1999, JavaSpaces is a programming model, part of the Jini technology standard, to paste processes together in a distributed application. It’s based on the earlier Linda systems, which supported entry-based, shared, concurrent processing. Unlike conventional distributed tools, JavaSpaces “views an application as a collection of processes cooperating via the flow of objects into and out of one or more spaces,” according to information available on Sun’s Web site. You can use the JavaSpaces API with your Jini implementation, but you can also use it separately as a tool for building collaborative and parallel applications.

Nuts and bolts
Basically, a distributed application involves multiple processors and devices. To build a space-based application, you design distributed data structures and add the distributed protocols that operate above them. All devices must be running Java Virtual Machine (JVM). A JavaSpaces distributed application includes spaces, objects, templates, and processes. Here is an explanation of each:

  • A space is a shared memory.
  • An object is an instance of a class that includes data and methods. When a client makes a request, the identity of the server is irrelevant. Objects are posted into the space as an anonymous service. Because objects in the space are passive, processes aren’t able to modify objects or invoke their methods directly in the space until the process takes (removes) it, updates it, and reinserts it. Objects are persistent, which means they can remain in the space after processes are finished.
  • A template is an object where all fields are null except for those you’re searching on. Only exact matches are returned. It doesn’t attempt to match fields that are set as null in a template—only fields for which you’ve provided values.
  • A process coordinates the exchange, storage, and manipulation of objects through spaces, or the shared memory. Space-based computing uses devices connected to a network as a repository for objects.

Sun says that a JavaSpaces system “can be thought of as an event-driven distributed cache with behavior transfer capabilities,” which “extends well beyond the base functionality of a simple messaging system.”

The programming interface itself is pretty simple and is composed of the following methods:

  • Write
  • Read
  • Take
  • Notify
  • Snapshot
  • Realblocking
  • Takeblocking

The four (yes, just four) main methods are write, read, take, and notify. Objects are put into the space using write. Users explore the space using read and take. Read returns entries that match the template. Take removes matching entries for modification. Notify is used to communicate matches of a template.

Theory in action
Suppose we were building a dating-service application using JavaSpaces. To do so, we would need to create a series of processes: a person creation process, a questionnaire evaluation process, a matchmaker process, and a match notifier process:

  • Person creation process. This process builds objects, which we’ll call persons. Within person objects are parameters, such as male, female, looking-for characteristics, location, etc. A user accesses a Web site to enter information and completes a personality profile questionnaire. The Web page submits the data to a person creation process, which creates the person object. The person creation process writes the person object to the space.
  • Questionnaire evaluation process. This process looks for person objects that haven’t had their personality profiles categorized and evaluated. The process will take the person objects from the space holding objects that need the questionnaire categorized and evaluated. Using the details from the questionnaire, the process creates a personality typing. Next, the process updates a field on the person object, which we’ll call the personality profile field, and which could include categories like “Outdoorsy,” “Geek (but in a good way),” “ Cosmopolitan,” and so on.
    There can be from one to as many processes as you need running. JavaSpaces technology hides all the plumbing that goes along with working on this process, whether there are three or 3,000 questionnaires to evaluate on two or a dozen or more servers. JavaSpaces simplifies all that goes along with having many computers evaluating those questionnaires. A hundred computers on the network could be available, getting people objects, evaluating them, and getting them back out to be available for dating matchups.
  • Matchmaker process. In this process, we create a template that finds and takes unmatched person objects and then builds another template for finding a person match based on that person’s profile and specified preferences. For every person object found, the process would update a match count, create a match object, and store it in the space.
  • Match notifier process. This process takes the next match object and e-mails the person objects listed in the match. Then, it updates the match object to “e-mail sent today’s date” and writes it back to the space.

In addition to these processes, we’d probably need a few cleanup processes for getting rid of old match objects.

The processes in our dating-service example handle e-mailing, evaluation, and matching. Basically, the processes find objects that match their template. The great thing here is that you can have multiple machines working on each of the processes, and none of the processes care about any of the other processes. If one machine goes down, the work load balances to the other remaining servers until the machine comes back online. The processes are loosely coupled, meaning that processes themselves are not dependent on other processes. Keep in mind, though, that the workflow itself does depend on the other processes completing properly and in order. The complete workflow of all of these processes together, working in a space, constitutes a complete distributed application.

A work in progress
While the benefits of using a distributed system like this are many, such a system is unlikely to replace corporate mainframes anytime soon. For a distributed system, problems may include issues with failures of multiple devices, latency in the network, and synchronization. Sun will probably rely on the developer community to provide the real-life implementations that help JavaSpaces to mature and gain popularity. As you might expect, there’s always plenty of information available from Sun’s Web site if you want to check it out for yourself and start putting those idle PCs to work.