T Spaces: The Next Wave

Listen

What is this miracle software? It's something new, made up of a combination of older things, a large piece of which, is tuplespace. Yes, the same tuplespace that was popularized for parallel programming by the Linda project at Yale University back in the 1980's [ACG86, Gel85, CG89]. As you recall, a Tuplespace is a globally shared, associatively addressed memory space. The central concept of a Linda Tuplespace is very simple--agents communicate with other agents by writing, reading and consuming tuples (a tuple is an ordered set of typed values) in a universally visible Tuplespace. What makes the tuplespace model so attractive is that it replaces synchronous point to point communication with asynchronous (and anonymous) associatively addressed messaging, where the messages are kept in a persistent message store.

A tuplespace is a very robust and reliable mechanism for parallel and distributed applications. Since the communication is asynchronous and anonymous, a variable number of agents can work together on a task. And, since the message addressing is associative, a dynamic set of message receivers can register their interest and participate. In any direct addressing scheme, even with multi-cast, a truly dynamic set of message receivers would be hard to manage.

The new world of network-connected embedded computer devices, such as wireless 2-way PDAs (personal digital assistants), smart cell phones and automobile PCs is a perfect setting for the tuplespace communication model. Yet more than just tuplespace is needed to create the complete network middleware package. To connect all devices we must have a common language platform on which to run. The disparity in hardware platforms and language compilers can create a formidable barrier to creating seemless network middleware. Also, for information to flow freely between devices, network computers and mainframes, a significant cache of information must be managed by the middleware, which implies that some amount of database function is needed. Thus, a network middleware package that fits the upcoming requirements of the newly connected world uses the tuplespace communication model, a ubiquitous programming language and database support. This paper describes T Spaces, a project at the IBM Almaden Research Center that is a serendipitous blend of the Java Programming Language, the Linda tuplespace communication model and database functionality.

Outline

The structure of this paper is as follows. Section 2 briefly discusses the previous work in Tuplespace systems, showing how we evolved from the original global communication systems to T Spaces. Section 3 presents the function of T Spaces. Note that we do not discuss the internal implementation of T Spaces, as that is covered in detail in the T Spaces architecture paper [WMLF98]. Section 4 shows impact of T Spaces on network and mobile computing, and how it has the potential to change the way those systems work. Finally, Section 5 concludes the paper.

Today's Tuplespace systems have their roots in the artificial intelligence blackboard systems that were created in the 1970's. Using the abstract notion of expert agents that could participate in a group computation, blackboard systems demonstrated the usefulness of a global communication buffer for collaborative computing. Later, the Linda Tuplespace systems and follow-on projects took a narrower view of the global communication buffer, using it almost exclusively for high-speed messaging between parallel processes of large high-performance computations. From there, several projects explored various combinations of Linda and database systems, Linda and Java, and Linda and distributed systems.

Tuplespace: A Brief Description

A Tuplespace is a globally shared, associatively addressed memory space. The basic element of a Tuplespace system is a tuple, which is simply a vector of typed values, or fields. Tuples are associatively addressed via matching with other tuples. A Tuplespace is simply an unstructured collection of tuples. A tuple is created by a process and placed in the space via the out primitive (from the perspective of the client, the tuple is pushed out). Tuples are read or removed with read and in primitives, which take a tuple template and return the first matching tuple. (Note that, because the space is unstructured, the choice among multiple matching tuples is arbitrary and implementation-dependent). Most Tuplespace implementations provide both blocking and non-blocking versions of the tuple retrieval primitives. A blocking read, for example, waits until a matching tuple is found in the Tuplespace, while a non-blocking version will return a "tuple not found" value if no matching tuple is immediately available.

In the "falling bodies" example below, Client A issued a Read command for a falling body of type "Meteor". Since there was a tuple with that value, a copy of the tuple would be returned for either a blocking or nonblocking read. In the second case, Client B issued a blocking In command for a falling body of type "Nova". Since there are no falling bodies of that type, the client blocked on that command, waiting for a falling body of that type to be added to the tuplespace (it will be a long wait). In the third case, Client C issued a non-blocking Read command for a falling body of type "Pulsar" (clearly Clients B and C are a bit confused). In the non-blocking case, since there are no falling bodies of type "Pulsar", a Null value is returned immediately.

 +----------+                           +-------------------+ 
 | Client A |------<Read "Meteor">----> |+----------------+ | 
 +----------+ <--[return "Meteor"]------|| <Fireball>     | | 
 +----------+                           || <Meteor>       | | 
 | Client B |------<In "Nova">--------> || <Ice Ball>     | | 
 +----------+       (Blocked)           || <Mir Shards>   | | 
 +----------+                           ||                | | 
 | Client C |------<Read Pulsar>------> ||+---------------+ | 
 +----------+ <--[return Null]----------|   Space 1         | 
                                        +-------------------+ 
                                              TS Server 

Note: most implementations, including T Spaces, have changed the names of the primitives to be less confusing than the original "out", "in" and "read" operators. T Spaces, for example, uses "write", "take" and "read", respectively.

Tuplespace provides a simple yet powerful mechanism for inter-process communication and synchronization, which is the crux of parallel and distributed programming. A process with data to share "generates" a tuple and places it into the Tuplespace. A process requiring data simply requests a tuple from the space. Although not quite as efficient as message-passing systems, Tuplespace programs are typically easier to write and maintain, for a number of reasons:

• Destination uncoupling (fully anonymous communication): Most message passing systems are partially anonymous: it is not necessary for the receiver of a message to identify the sender, but the sender always has to specify the receiver. The creator of a tuple, however, requires no knowledge about the future use of that tuple, or its destination.
• Space uncoupling: Since tuples are retrieved using an associative addressing scheme, multiple address-space-disjoint processes access tuples in the same way.
• Time uncoupling: Tuples have their own lifespan, independent of the processes that generated them, or any processes that may read them. This enables time-disjoint processes to communicate seamlessly.

Blackboard Systems

The idea of a globally accessible "data-space" for communication among multiple independent processes dates back to the blackboard systems used in Artificial Intelligence research since the early 1970s. Blackboard systems used the idea of a global slate (the blackboard) on which experts from various backgrounds could collaborate to solve difficult problems. The first and most famous of these systems was the Hearsay-II speech-understanding system developed at Carnegie Mellon University [EHL+80]. The system was structured as a group of diverse and independent agents called knowledge sources, which communicate through the blackboard (a global database). The knowledge sources search the blackboard for problem descriptions matching their domains of expertise, and write solutions for these problems (once they are calculated) back to the blackboard. The blackboard serves two purposes: representing intermediate states of the problem-solving activity, and communicating hypotheses about solutions among the knowledge sources. The blackboard architecture was widely recognized as an interesting and flexible approach to the problem of integrating diverse independent agents into a cooperative system. However, until the early 1990s, few general-purpose blackboard systems were available, and each project that used this approach designed an ad-hoc solution [Cor91, BBTech]. So even though the general idea of a collaborative space was a useful and constructive one, the global communication buffer didn't catch on as a general distributed programming tool.

The Original Tuplespace

Although not mentioned in the literature by name until 1985, Tuplespace originated from a system developed at SUNY Stony Brook in the late '70s and early '80s. This system, the Stony Brook microcomputer Network (SBN), was a parallel computer composed of a set of processors in a torus-shaped communication grid. In order to support distributed computations on the network, a scheme was devised [BG80] to communicate the global state of the system to each node. The supported operations were read and write, which a node could use to find or update information about the network state. A systems programming language called Linda was designed for the SBN, consisting of two communication primitives, in and out. These were essentially wrappers for the read and write (respectively) operations provided by the network system. Linda also contained some novel parallel language constructs which later evolved into the study of "symmetric" programming languages but which will not be discussed here. As Linda evolved, a non-destructive read primitive was added (see [GB82]), and the concept of associative addressing by structured name was introduced. By 1985, the term "tuplespace" had replaced "global buffer" in the literature [Gel85], and Gelernter had begun work on porting Linda to different architectures. The next year, Linda evolved into a set of communication primitives and C-Linda appeared in the literature (see [ACG86]). Despite many changes in implementation and use, tuplespace has remained essentially unchanged since that time.

Tuplespace projects

For many years, Tuplespace research was restricted to the parallel programming community. Tuplespace systems were available in the form of products and freely available research projects. The most famous tuplespace project, Linda, was trademarked by Scientific Computing Associates, and marketed to large financial enterprises as the simple solution to their parallel computing needs. However, there were many other tuplespace systems that were created for parallel computer. Since we describe them in a previous paper [MLW98], we will simply list them here: POSYBL [Sc90], Glenda [SBA93], P4-Linda [BL94], The University of York Linda implementations [DWR95, RW96, DRR+96, BWA94], Javelin [CC+97] (and Javelin-like systems [KF98, JMW98], Piranha [Carriero+95] and Linder [Mcl95].

With time, the tuplespace work expanded from pure parallel applications into the more diverse distributed computing. A number of projects, including Laura [RT93], JavaSpaces [SUN97] and Jada [jada] (which was part of Pagespace [pagespace]), showed that decoupling clients and servers is easily accomplished using Tuplespace. Then, as Tuplespace implementations in C++ became more common, the opportunity to enhance the matching process became obvious. ObjectSpace [AP93] and Objective Linda [TK95] added the basic ideas of object orientation to the standard Linda model. At the same time, other researchers investigated combinations of tuplespace and database systems. Although the similarities between Tuplespace and databases has long been recognized, surprisingly few projects have explored the connections between the two subjects. Persistent Linda (PLinda) [AS91] was the first project to add database functionality, including transactions and a simple query and join engine, to Linda. Perl-Linda did not extend Linda with database operations per se, but they did combine Linda primitives and the Perl scripting language, creating a system for web developers who need a simple data repository [WS95]. Finally, the 1990's was also a period in which Linda became a target for fault tolerant systems, such as FT-Linda [BS95], MOM [CD94], and Persistent Linda 2.0 (PLinda2.0) [AS91, Jeong+97].

Discussion

Tuplespace was a hot research area in the 1980's, but since then interest has dwindled. Its rise and fall in popularity was strongly correlated with the rise and fall of research on parallel processing, and parallel hardware in particular. Although the Linda model for parallel processing is simple, and can be made reasonably efficient for applications where the amount of communication is much lower than the amount of computation, the basic work in the area was done thoroughly in the 1980's at Yale, and there has not been much commercial interest in such systems. Later work, such as the fault tolerance projects, used Linda as a testbed for their parallel and distributed ideas; they did not attempt to improve on or add functionality to the Linda model itself. Linda is a good communication mechanism and model for distributed and parallel research because of its flexibility and simplicity.

In the late 1980's, systems for building distributed applications cropped up. Linda is a good starting point for such systems because it provides communication, synchronization, and a simple data repository in one framework. Yet these systems did not attract much interest. Although they provided some heterogeneity, portability, and inter-operability, they never were able to provide a solution that addressed all the issues well. Recently, Tuplespace has received renewed interest. This is the result of the platform independence and ubiquity of Java, and the explosion of distributed applications on the World Wide Web. Linda is attractive for these systems because it is easy to implement and provides the tools needed to build simple distributed applications. These Web-based Linda systems are mostly targeted at distributed applications, but there is also work being done on parallel systems. The advent of Java and the growth in world wide connectivity has enabled distributed applications from brake systems in cars to super computers to inter-operate. There are thousands of different types of these devices and they all have varying communication needs; the challenge now is to provide them with a flexible communication substrate. We believe that a Tuplespace system, augmented with Java and database technology, will go a long way towards meeting this challenge.

Although previous systems have tried pairs of these combinations (Tuplespace + database, Tuplespace + Java, database + java), these efforts either remain relatively obscure, or, in the case of "database + java", they do not meet the communication needs of the distributed applications. T Spaces combines the best elements of all three: a classical Tuplespace system, a main memory relational database management system and the Java programming language. The tuplespace component gives T Spaces an excellent communication model. The database component gives it stability, durability, advanced query capabilities (associative addressing) and true data storage. Java gives it instant portability. Also, because of Java's ability to download new types (classes) on the fly, it creates unparalleled flexibility in its ability to perform new functions and handle new types.

The salient features of the T Spaces system are:

• Tuplespace Operator Superset: T Spaces implements the standard set of Tuplespace operators: read, in (take), and out (write). In addition, it includes both blocking and non-blocking versions of take and read, set oriented operators such as scan and consuming scan, and a novel rendezvous operator, rhonda.
• Persistent Data Repository: T Spaces employs a real data management layer, with functions similar to heavy-weight relational database systems, to manage its data. T Space operations are performed in a transactional context, which ensures the integrity of the data.
• Database Indexing and Query Capability: The T Spaces data manager indexes all tagged data for highly efficient retrieval. The expanded query capability provides applications with the tools to probe the data with detailed queries, while still maintaining a simple, easy-to-use interface.
• Dynamically Modifiable Behavior: In addition to the expanded set of built-in operators, T Spaces allows new operators to be defined dynamically. Applications can define new datatypes and new operators that are downloaded into the T Spaces server and used immediately. This is in contrast to relational database systems that have limited datatype support and limited dynamically defined function (usually in the form of triggers or, to a lessor extent, user-defined functions).
• Event Notification: Applications can register to be notified of events as they happen in the T Spaces server.
• Access Controls: Users can establish security policies by setting user and group permissions on a Tuplespace and operator basis.
• Large Object Support: Applications can specify URLs as field values. The URL properties can be set as "copy immediate" or "remote reference". "Copy Immediate" implies that the contents of the URL are copied between the client and server when the tuple is transferred. "Remote Reference" leaves the URL where it is. However, another operator, "getURL" fetches the URL contents for local processing.

System Structure

A T Spaces server houses potentially billions of spaces. It is up to the application writer to decide whether to use several spaces (a space being a partitioning criteria) or just one space (using values inside of the tuples as the partitioning criteria). Since access control (discussed later in this section) is performed at the space level, this may impact the decision to use one or more spaces.

In a T Spaces server, there are two special spaces: The Admin Space and the Galaxy Space. The Admin Space contains all of the users, groups and passwords for the entire server. The Galaxy Space contains all of the information about the server itself, as well as information about all of the spaces (including itself) defined in the server. The Galaxy Space contains the equivalent of the system catalogs in a relational database system. But, unlike a relational database system, a T Spaces engine does not contain much schema information about the data. Tuples of any size, shape or form are allowed to co-exist in the same space. Just as the LORE project [MAG+97] uses semi-structured data in order to support dynamic or inconsistent (web oriented) data sources, T Spaces is made to suit the needs of thousands of types of clients -- an environment where it could be almost impossible to get everyone involved to stop long enough to agree on a single common schema.

Indexes and Queries

Clients of T spaces are exposed to a simple interface of tuple commands, mostly oriented towards reading and writing tuples. T spaces users have found that this simple interface is sufficient for a wide variety of applications [IBM GCS Implementation Team]. However, for the sophisticated user, T spaces also provides some advanced query functionality as well.

Basic T spaces Tuple Commands

The basic tuple operations are write, take, and read. Write stores its tuple argument in a T space. Take and read each use a tuple template argument which is matched against the tuples in a space (see the next section for the matching algorithm). Take removes and returns the first matching tuple in the space, while read returns a copy of the matched tuple, leaving the space unchanged. If no match is found, take and read each return the Java type null, and leave the space unchanged. Blocking versions of these are provided, waittotake and waittoread, which (if no match is found) block until a matching tuple is written by another process. (Linda programmers will recognize the semantics of these primitives as out, inp, rdp, in and rd). T spaces also extends the standard Tuplespace API with the operations scan, consumingscan, and count. Scan and consumingscan are multi-set versions of read and take, respectively, and return a <tuple of tuples> that matches the template argument. Count simply returns an integer count of the matching tuples. In addition to these basic operators, we have implemented a new operator, rhonda, which performs an atomic rendezvous. The rhonda operator takes a template tuple as an argument and atomically swaps two matching tuple templates. That is, if process 1 and process 2 perform rhondas on matching templates, the tuple that is returned to them is the other processes template tuple. This is useful for atomic synchronization (but not to be confused with the type of synchronization achieved with semaphores).

Tuple Matching

An extended Linda tuple-matching algorithm is used to determine if a tuple in a space satisfies a tuple retrieval request (read take etc.). In the standard (Linda) case, the template is simply a tuple, with one or more formal fields. (A formal field has a type, but no associated value). A tuple matches the template when all of the following conditions hold:

1. the tuple and template have the same number of fields,
2. each of the tuple's fields is an instance of the type of the corresponding field of the template, and
3. for each non-formal field of the template, the value of the field matches the value of the corresponding tuple field.

Advanced tuple matching

The basic structural matching described above is similar to that used in most Tuplespace systems. However, in order to provide greater flexibility and database-like functionality, T spaces uses a more object-oriented approach, which offers more advanced matching options. These options are object compatibility, named field matching, and query semantics.

Object compatibility: For a tuple to match an object compatibility template (known as a SubclassableTuple template), the type of the tuple in the space must be a subclass of the type of the template. In this way, a programmer can treat tuples as objects, customizing them to specific tasks. For simple applications where only structural equivalence matching is needed, the T spaces---Tuple class is final (i.e., it cannot be subclassed), and thus, when it is used as a tuple or a template, it will only match other tuples or templates of type Tuple. The following table shows some sample tuples and templates.

Named fields: One of the differentiating features of T spaces is that it builds an index on each named field in a tuple. This enables clients to request tuples based solely on values in fields with a given name, regardless of the structure of the rest of the tuple (or even the position of the named field within the tuple). For example, an index query of the form (<foo>,8) will select all tuples (of any format) containing a field named <foo> with the integer value 8. It is also possible to specify a range of values to be found in the index.

Queries: Tying it all together The current implementation of T spaces provides four types of queries: Match, Index, And and Or queries. A Match query performs structural or object compatibility matching (depending on its argument), while an Index query performs a named-field query. And and Or queries can be used to combine these and build complex query trees. More detailed examples of these queries can be found in the T Spaces architecture paper [WMLF 98].

Dynamic Behavior

The Tuplespace commands mentioned in the previous section are operators that are predefined in the T Spaces system. However, other operators can be defined as well by users with the appropriate system permission. Each operator is associated with an operator group (such as the Tuplespace group or the Administration group) and an operator implementation, known as a handler. To define a new operator, a user loads a new handler into the T Spaces server using the addHandler() operator. After a new handler class is loaded into the server, the server may then potentially negotiate with the client to obtain all of the relevant class files needed to run the new handler class.

Handlers are managed by handler factories, which manage all of the handlers for a particular group. It is possible to also load a new factory to either define a new operator group or to modify an existing factory's method for managing a handler.

Event Notification

A T Space event is defined as the execution of a command on a T Space (exceptional conditions are not events). Any event may be registered for using the eventRegister method. Besides the T Space and command of interest, the client also specifies an object that implements the Callback interface. When the event occurs, the system automatically calls that objects' call method. The call back occurs in the context of its own transaction. If the client has failed or been disconnected, the T Spaces server will create a call back tuple in the event T Space which the client is responsible for collecting once it reconnects to the server.

Access Controls

Access control is performed at both the global server level and at the individual space level. Users can be defined at both levels (e.g. system user "Joe" and space user "SpaceName:Bill"). Rather than have predefined permissions, as one might expect of an operating system, the permissions are tied to individual operators (e.g. read, write, take, scan, addHandler). With this flexibility, it is easy to set the permissions of new operators that are dynamically defined. However, for ease of use, users (or administrators) are not required to set these fine-grained permissions. They may instead set very coarse-grained permissions (none/read/write/all) which map to the fine-grained permissions (although, dynamically defined operators may not map to read and write, so they might require the fine-grained access).

Each user belongs to a certain number of groups, with every user belonging to the AllUserGroup. The T Spaces Access Control Administration Tool may be used to define or delete groups, define or delete users, and add or remove user group associations. The Admin T Space is used to retrieve all the groups the client executing a command belongs to and the mapping of groups to Attributes (i.e., which groups are allowed to do which operations). For each Attribute, the system checks if the client belongs to a group that the T Space defines as satisfying the attribute. If the client does not satisfy all the AccessAttributes, a security exception is propagated back to the client thread that executed the request. Otherwise, the handler is used to execute the operation. Because checking access permissions is done on every operation and accesses the Admin space, this access is done directly rather than through the Galaxy space.

Web Access

T Spaces has a built-in web server so that authorized users can view the contents of a space with a web browser. Although only those field values that are printable can be seen with the web browser interface, this relatively simple device is a huge aid in debugging programs. Over time we'll enhance the web interface with more function -- currently users can read and delete tuples in a space.

Distribution, Replication and Caching

Note: in the current implementation, T Space servers are centralized, though clients are free to talk to as many different servers (and spaces) as they like -- the servers simply do not cooperate yet. However, in the design, each T Spaces server will contain a replicated copy of the global hierarchical directory of TS Name Servers that can, in turn, locate any specific server. So, in general, a client would need to talk to only the nearest T Spaces server to have her request forwarded anywhere in the TS Global network.

In a truly global data management system, data replication is needed for both fault tolerance and performance. However, with data replication comes the problem of resolving multiple updates to the same data. We are experimenting with the algorithms founded at Xerox PARC to produce a reliable ordering of updates to multiple copies of data.

With infinite information stores available on the network, it is clear that PDA's and laptops will be able to cache only a small amount of data locally. However, it is very useful to be able to update that information in a mobile environment. Therefore, we are exploring algorithms that will allow T Spaces to broker information between mobile clients and backend data warehouses.

Java---A New Implementation Platform

Using Java as the implementation language had a more profound effect on the design of T Spaces than just dynamic nature of the class files. Since it is based on virtual machine, there's an additional layer of abstraction between the data structures used in the T Space database system and the underlying computer system. As a result, there is no direct mapping between disk pages and physical memory; there is only a logical mapping between sets of tuples and disk files (used for logging and checkpointing). On the one hand this slows the performance down somewhat (exact numbers are hard to quantify), but on the other hand we gain significantly in flexibility and portability. Since performance automatically doubles every year with hardware improvements, we felt that this was a reasonable tradeoff.

The future of today's mobile wireless computing seems straight-forward. PDA's will be able to communicate with ISP's (internet service providers) which will then give them access to the internet and possibly, after the signing of many legal documents, access to the company INTRAnet. But, once that is in place, PDA's will be just like the existing network-attached computers. The system resources not available to the network computers also will not be available to the PDA's. T Spaces can change that.

So what's special about T Spaces? Just this. T Spaces adds a new layer to the existing operating system and network protocols that gives high level associative access to any network-connected process in the world. Today's TCP/IP has seven layers (Physical, data-link, Network, transport, session, presentation, application). T Spaces could almost be thought of as a new layer (associatively addressed process groups).

Solving the Printing (and General Services) Problem

Using T Spaces as the infrastructure that allows any process on any platform to easily locate and communicate with any other process on any other platform, we can easily export any system service on any platform to any program (or person) anywhere. For example, even though the technology of printing services is mature, it's often not possible to get to a particular network attached printer from some other particular network attached computer. With T Spaces as the middleman, this problem can be solved easily. Building on the existing system infrastructure, T Spaces adds a general purpose system layer that allows application processes to communicate with any network attached printer. In a similar fashion, any system service can be made available to any network attached device, even those connected through ISP's, such as wireless PDA's or laptops.

Solving the ISP Problem

The larger issue, though, is the growing population of PDA's. In their current configuration, most PDA's are simply an extension of a desktop computer. The desktop contains the backup/archive of the PDA contents, so the main interaction between the desktop and PDA is to synchronize with each other. There are two problems with this picture. First, the PDA is tied mostly to one machine. Although there is growing support for additional functionality (web browsing, stock quotes, etc), the PDA does not act as a fully independent network computer. It cannot independently interact with the services available on the network. Second, there is a problem today with ISP's and firewalls. If a person's desktop machine is behind a firewall and their wireless ISP does not have a secure gateway through the firewall (which is most often the case), the wireless PDA cannot reach the desktop machine.

Fortunately, T Spaces has a solution to both problems. First, by interacting directly with T Spaces and not a specific desktop machine, all of the resources available through T Spaces are available to the PDA. So, all printing services, online faxing services, email services, paging services, program transformation services, remote control services and remote file system services are available to the PDA or laptop computer, where possibly nothing was previously available. Second, clients inside the firewall can communicate with a T Spaces server outside the firewall (the server keeps the connection open so that it never has to try to reconnect through the firewall). Thus, a wireless PDA can connect to an externally visible T Spaces server, which can in turn establish secure communications to applications and services inside the firewall

Intelligent Middlemen

The truly exciting aspect of T Spaces is that there are so few limitations to what can be accomplished. Not only does T Spaces allow any process on any computer to talk to any other process on any other computer, but it allows other intelligent processes to interact with the conversation, adding needed information or redirecting various aspects of it. For example, Client X wants to send one of his "X-files" to the printer. However, Client X doesn't know (or care) that he sent a postscript file to a non-postscript printer. A smart printing middleman watches the site printing space in the T Spaces server for print jobs to determine if any additional processing is needed. In this case, it sees the input job, a postscript file, and the output printer, an inexpensive inkjet printer, and translates the postscript file into one that will be understood by the printer. Similarly, if Client wanted to view the postscript file on his PDA, he would need the services of another program to generate the screen images appropriate for his PDA.

The global communication buffer concept has had a long career, but not an overly prominent one. So far, all of the Blackboard systems and Tuplespace systems have existed in relative obscurity, even though the features they brought to the computing community were very useful. Our experience in building a large system and many small applications using T Spaces has shown us that this is a very powerful model and needs to be brought to the mainstream. One reason it has stayed quiet is the availability. Most implementations have been university projects written in C or C++. As a result, they were not finished systems that could be deployed in the real world and they were not portable to many platforms. The real power of a system like T Spaces is having access to it from virtually every computer, from the microchip sewn into your clothing all the way up to the mainframe running the corporate (or federal) database.

A classical Tuplespace system alone, however, is not enough. Our experience has shown that even though Tuplespace has an excellent communication model, it also needs a data repository and a more advanced query capability. This is the direction that we've tried to steer T Spaces.

New Directions

Since it is a general purpose distributed application conduit with data repository capabilities, T Spaces has the opportunity to revolutionize how distributed computers operate. By connecting a set of devices and global services to a set of connected T Space servers, we can create a set of Common Network Services that are available to any computer. Platform specific applications can provide services to any application that is attached to the global T Spaces bridge. So, from any platform a client will be able to request any service, such as printing, scanning, faxing, email, paging, file transfer, inter-platform program "pipe" data transfer, program transformation (e.g. turn a Latex document into postscript or a Gif file into a Tiff file), remote device control and cross platform program synchronization.

However, providing network services to PDAs is just one (and a boring one at that) of many possibilities. People have referred to "the internet dialtone" as something we will one day take for granted. Our ubiquitous PDA's (which will be incorporated into our watches) will buzz with that dialtone, giving us access to anything and everything. So far, no one has been quite sure what could supply that dialtone. Now we know. It's T Spaces.

References