TSpaces is network middleware for the new age of ubiquitous computing.
A succinct description of TSpaces would be,
a network communication buffer with database capabilities.
However, it is often easier to describe it in terms of what it does.
It enables communication between applications and devices in a network of
heterogeneous computers and operating systems. TSpaces provides group
communication services, database services, URL-based file transfer
services, and event notification services.
It is implemented in the Java programming language and thus it
automatically possesses network ubiquity through platform independence,
as well as a standard type representation for all datatypes.
In more technical terms, TSpaces extends the basic Linda Tuplespace framework with real data management and the ability to download both new datatypes and new semantic functionality. The salient features of the TSpaces system are:
The TSpaces system is appropriate for any application that has distribution or data storage requirements. It can perform many of the duties of a relational database system without imposing an overly restrictive (and primitive) type system, a rigid schema, a clumsy user interface or a severe runtime memory requirement. In a sense, it is a database system for the common everyday computing device---one that doesn't generate complex SQL queries, but one that needs reliable storage that is network accessible.
Since TSpaces basically connects all things to all things, there are many things it is good at. Also, since it is main memory and Java, it is also ideal to do many things on very small devices, even those (maybe especially those?) that do not have disk drives. So, sure you can build a chat room application, a shared whiteboard application, a distributed cut and paste buffer application, a remote file system viewer or tons of multi-user games. However, there is ONE MAIN THING that we think TSpaces will be especially good at. It can (will?) be the common platform on which we build links to all system and application services. What do I mean by that? Suppose I want to print a file on a network printer from a generic client. That's fine if I have a UNIX client and a UNIX network. It's a little more involved if the client is Win NT or Win95 and much more involved if the client is an Apple. However, what if the client is a PDA? At a large site, such as ours, how do I go about adding all 100 network printers to my Pilot interface? How do I even add one? Now look at it from the other side. When I have a private locally attached Win 95 printer (or Mac printer, etc), how do I access that from a UNIX machine? Sure, there are specific answers to some of these problems, with regard to printing, such as running a specialized LP Daemon program that will talk to UNIX print clients. Now let's cover scanning, faxing, email, paging, application services (e.g. convert a word document to a postscript file, invoke a web search on a topic, fetch and parse XML data) or remote device control (e.g. drive a network attached machine through an API, access a remote drive).
In the TSpaces world, a common computing environment, with access to all possible network services, is surprisingly easy to build. A set of applications, written in Java, map the system-specific service (e.g. printing service) or application (e.g. web search) to a standard tuple representation. Then, any client from any platform can generate a tuple and send it to a TSpaces server. Applications, listening for specific tuples, pick up jobs when they see them and execute them. (This is all fairly fast, since it is implemented with an underlying memory-resident database system.) In building this environment, one would write the service application to run on the platforms where they could do the most good. At the IBM Almaden Research Center, most network printers are visible to AIX systems. Therefore, one AIX printer service application could listen for tuples posted to the "printing space", pick them up and send them to an AIX Queue. Similarly, queries about queues and print status could also be done. Then, on every other local printer that should be attached to the common platform, a user simply runs the local print application (although, in practice, the local application can probably handle a number of services). Notice, however, that we are NOT trying to replace any existing tools or services---we are simply augmenting them with platform independence and flexibility.
One of the really cool things about this environment is that it injects a smart middleman into the picture. So, as mentioned above, you can build this nice platform independent print service that gives you access to any printer in the building. That might be ok, but perhaps you don't have a clue about where all those printers are. With a smart middleman, you can add intelligence. When your PDA includes a location sensor (with no sensor you just have to tell it which room you're in) the smart middleman printer client locates the non-busy printer nearest you (that still has paper and toner) and sends the job there -- then shows you a map of how to get there. When visiting a new location, this sort of service would be incredibly convenient.
The number of common network services is limited only by our imaginations. We're counting on the university population to come up with some revolutionary ideas. We've thought about cool ways to incorporate PDAs into the network. If they run Java, then great. If not, then they will have to communicate some other way, such as using TCP/IP and sending only primitive types in the message.
There is one more important point to make (or two, depending on how you count). First, this creates a SINGLE interface for talking to practically every single service that exists on the network -- everything uses tuples. The exact language that goes inside the tuples will have to be ironed out over time, of course. Second, while this all works fine from a command line or GUI interface, tuples can be sent from programs (from Java programs or from programs that invoke Java programs). That means that your program can easily send email, faxes, pages, print jobs, web searches, remote device commands --- all as easy as sending or receiving a tuple. We've been waiting ages for smart agents to act on our collective behalf. One of the things that has slowed down their progress is the interaction to the outside world (so many different platforms, so many different interfaces, so little time).
(Editorial note: Last year, a SUN Microsystems speaker confessed that when SUN came out with the saying, "The Network *IS* the computer" they really didn't know what they meant. They just figured it would make sense eventually. Well, now it does.)
The generic diagram that we draw for TSpaces is below. TSpaces, this database enabled communication buffer, can connect absolutely everything. With an emerging world of smart, and network connected, electronic devices, having an existing common platform, like TSpaces, that they can plug into only makes them more powerful and useful from the start.
