IBM TSpaces User's Guide


TSpaces is a new software package that provides a common set of services for a network of hetergeneous computers and operating systems. It offers group communication services, database services, URL-based file transfer services and event notification services. Compared to the systems whose function it emulates, TSpaces is tiny. And so, given its small footprint, it is an ideal solution for bringing network services to small and embedded systems.

A TS Network with various clients

From a TSpaces client point of view, being connected to TSpaces is like being connected to the perfect assistant. It will remember things for you, it will carry out any tasks that you assign it, it will report incoming messages and deliver outgoing messages, and it will notify you of any events in which you're interested. By adding additional client applications, it is possible to use TSpaces as a unversal print service, email service, pager service, remote control service, and so on.

Since it is written in Java, T Space client applications can be loaded dynamically into any network attached computer and run. In addition, the T Space server, also written in Java, can be updated with new function and capabilities while it is running, thus avoiding costly downtime for system upgrades.

1.0 Background

Network applications have been around for 15 years and yet, in that time, convenient middleware for sharing data across applications has not been plentiful. Sure, there are numerous tools and utilities for getting programs and devices to communicate, but so far there has been no network-oriented, easy-to-use data repository that is widely available. The packages have been too low level (e.g., TCP/IP sockets) to cover much of the needed functionality or too heavy weight (e.g., "real" database systems) to be really convenient.

Of course, these trends are not without reason. It is hard to build really useful middleware across heterogeneous platforms. One of the hardest problems is just dealing with the representations of objects (e.g., C and C++ objects), which often have differing structure layouts per compiler and per platform. Some attempts have been made to solve this problem alone (e.g., CORBA), but so far there's been no clear success story at the communication layer, much less at the middleware layer.

Now, the story is even worse. Besides the mediocre mechanisms involved, the mode in which distributed network applications run is changing. In the early years, it was a complete success simply to have two programs start execution, exchange a packet of data, then terminate. The data didn't live any longer than the programs. Now, this is changing. As the Database Developers can attest, data is living longer than ever. Even data that is not in a heavy weight repository often outlives the program instance that generated it. As a result, today's network-oriented application programs require data repositories that can hold the data beyond the life of the generating applications. In addition, these repositories must allow application programs to attach to the data, execute some logic on it, and terminate, all in an ad hoc basis.

What do we have that will meet these needs? The solution has several pieces, but luckily, they are all falling into place. One of the larger pieces is Java. Java has single handedly solved the communication part of the problem. Another major piece is TSpaces. TSpaces, coupled with Java's dynamic and ubiquitous nature, creates a uniform platform on which we can create applications to perform practically any service desired. "Where did TSpaces come from?" you ask. Well, it's an interesting story. Mostly, it started out as the marriage of a tuplespace system with a database system.

1.1 Something Old

In the mid-1980's, David Gelernter, a professor at Yale University, created a project called LINDA [Carriero 84], [Gelernter 82], [Gelernter 84], [Gelernter 85]. LINDA was a programming language designed to address the communication problems of parallel programming. Part of this project was a concept known as Tuplespace. Tuplespace embodied three main principles:

Although the LINDA Tuplespace was originally intended as a global communication buffer for parallel programs (which are concerned mostly with synchronization and high performance), we found that it also works well for distributed programs which often need a ubiquitous persistent communication buffer.

The central concept of a LINDA Tuplespace was surprisingly simple -- agents post unstructured tuples to a univerally visible Tuplespace using an "Out" command, consume tuples using an "In" command and read tuples using a "Read" command. LINDA was a bit hit in the parallel programming community, but it has not enjoyed much visibility outside of that particular research area.

1.2 Something New

In 1996 (which used to be "new") we had heard that SUN and others were showing interest in LINDA. SUN has more recently publicized an internal Tuplespace project, written in Java, called JavaSpaces. We experiemented with the Tuplespace idea -- implementing a simple prototype in Java. And, almost immediately, we saw a number unexpected opportunities. We saw a ubiquitous platform with powerful object oriented types to express any type of data, dynamic class loading so that new types could be loaded on the fly, and most importantly, new commands (operators) could be defined to the server. Thus, a Tuplespace Server can be "taught" how to perform more than the initial OUT, IN, READ commands.

1.3 Something Borrowed

Given that we're in the database research group at IBM, we naturally thought of TSpaces as being a lightweight data repository in addition to being a global communication buffer, so we basically "borrowed" some of the database technology that we had sitting around. Interestingly, SUN claims that Javaspaces is most definitely NOT a persistent data repository. Anyway, being a repository, TSpaces needed several database features for data integrity and search speed, such as transaction support, index support and a simple query language (much simpler than SQL, but better than the overly restrictive "formal" tuple queries offered by LINDA). In addition, the TSpaces server can also deal with an arbitrary collection of Java types, as clients wishing to add new types just define them to the server and then use them.

1.4 Something Blue

Our favorite choice for the name of this project was "Bluespaces" (kind of a tongue in cheek play on the name "Javaspaces"), but it seems that, as a corporation, we're trying not to overuse the "blue" name. So, as a second choice, we ended up with "TSpaces".

2.0 Using TSpaces

TSpaces is network middleware. Middleware has no face, no frontend to speak of. It is the applications, the middleware clients, that users see. Thus, the usefulness of the middleware is determined by the usefulness of the client applications. Fortunately, the function offered by TSpaces is sufficiently powerful that it is easy to write meaningful and useful applications. Look at the TSpaces example programs. We wrote these just to demonstrate how TSpaces programs can be written, but it turns out that we use some of these programs for everyday work.

TSpaces has many faces and these different faces serve different application needs. You can think of TSpaces as any or all of the following: