Published on Proc. 5th IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 96)
P. Ciancarini and D. Rossi and F.Vitali
University of Bologna
-
A. Knoche and R. Tolksdorf
Technische Universität Berlin
The ubiquity of the Internet suggests its use for supporting applications involving remote cooperation and document sharing. Such applications coordinate a dynamic numer of users, which enter and leave these systems to cooperate and share services and resources. The WWW is clearly showing how effective can be such applications, even if its current scope simply consists of large scale information retrieval and exchange operations [3].
The goal of our research is to facilitate the construction and integration of distributed applications supporting coordination, cooperation, and communication, both synchronous and asynchronous. In the following table we classify a number of applications according to the kind of basic mechanisms they need.
| synchronous | asynchronous | |
| communication | IRC, teleconferencing | |
| cooperation | groupware | DBMS |
| (eg. co-authoring systems) | (ftp,WWW) | |
| coordination | distributed game playing (MUD) | workflow |
| auction system | (eg. meeting scheduler) |
Communication mechanisms allow to exchange messages and/or data streams; these are the basic services needed to build applications like IRC (Internet Relay Chat), e-mail, or teleconferencing systems [8].
Cooperation mechanisms allow to share documents and resources; groupware applications like coauthoring systems [4, 5] and shared data repositories need specific cooperation protocols, respectively synchronous or asynchronous.
Last but not least, coordination mechanisms allow the orchestration of multiple activities and services, useful to build applications like either distributed game-playing environments or workflow support systems.
In this paper we are especially interested in discussing coordination mechanisms. In fact, we are developing a coordination concept for the WWW called the PageSpace, aiming at offering middleware support useful for designing coordination systems, both synchronous and asynchronous.
Most applications on the Web require active processing and coordination of services and software components. Today, activity within the Web is tied to server machines and there is no integrated mechanism that allows it to coordinate activity located at clients, such as applets. In order to allow for really distributed application in the Web, such coordination platforms have to be built. The Web middleware in its current state does not provide enough support for multiuser applications, such as groupware or workflow, as its basic nature is that of a passive information system. Browsers supporting applet scripting languages, such as Java, allow activity at the user interface, however there is no integrated middleware to coordinate activities tied to multiple, distributed clients. Coordination has to be centralized at some server to which all users participating in an application have to connect to. Thereby, the activity located at the browser does not really make the application distributed, as applets at the browser cannot connect to other applets providing services to them directly.
The PageSpace [2] is a platform to support distributed applications on the WWW. It introduces a notion of active objects - the agents - which are able to both use and provide services from an to other agents, without requiring centralized coordination from servers.
Distributed PageSpace applications involve heterogeneous machine-, network- and operating-system architectures. Coordinating agents in such an environment means to make these heterogeneities transparent to the programmer. Transparency of network heterogeneity is achieved by using the Internet middleware underlying the communication platform. Transparency of different hardware architecture and operating systems is provided by Java.
In fact, the PageSpace is build on a set of existing technologies:
Coordination technology provides the conceptual platform for the coordination of activities amongst asynchronously working collaborating agents. Coordination technology has been initiated by the language Linda. The underlying basic conception of uncoupled coordination has been subject to a large variety of research projects, focusing on parallel, distributed, and open distributed systems, on its theoretical foundations by giving semantics to coordination languages, and on a number of implementation oriented research concerning the embedding of coordination languages and their efficient implementation.
Web technology provides a wide-spread communication and presentation platform to PageSpace. Browsers allow at least the access to the PageSpace and with HTML a uniform graphical interface for the applications can be defined.
Java technology provides a uniform processing platform. Java is popularized by its integration into standard Web-browsers and is available on all major hardware platforms.
The PageSpace integrates these basic building blocks and thereby adds value to them. PageSpace uses Java as the implementation language for the platform, as well as the application programming language enhanced with a high level coordination support for distributed, concurrent agents to Java. The PageSpace adds value to the underlying building blocks by integrating them in a manner in which the extensive reuse and combination of existing and wide-spread complementary technologies leads to a platform that aims at supporting real-life applications. Our guideline is to add the coordinating glue to bind these technologies together, rather than extending them individually.
We identified the centralized nature of the current Web as its major drawback: all actual processing for the application is tied to the server-machine. Also, in most advanced applications on the Internet, the WWW is only used as a static access mechanism to an existing external environment: DCE components, CORBA objects, DBMS applications. The PageSpace architecture distributes the activity by incorporating coordination technology and decentralizes applications.
The PageSpace is populated by agents. Some of them are concerned with the application itself, others have more specific tasks. We distinguish the following concepts in a PageSpace, each denoted by a different Greek letter:
An Alpha interface connects via HTTP to the associated Beta broker agent. This carries out interactions within a Gamma coordination space with some application-specific Delta agents on behalf of the user. The Epsilons provide special services to the Deltas which are mainly location dependent. All agents use coordination primitives provided by the Gamma environment. A Zeta provides a gateway to other worlds, e.g. the CORBA world.
All agents (except possibly Alphas and HTTP interface of Betas) are programmed in Java using special classes and executed as byte-code by Java virtual machines.
Each user has a 'homeagent' called Beta that can use services in the PageSpace on behalf of the user and collects incoming messages. The user`s interface to his Beta is called Alpha-Interface that displays the resulting data and offers means to request services.
There is a complete freedom in thinking of these Alpha-Interfaces but a few issues must be faced:
We are supposing that several independent applications run within the same PageSpace. For instance, some players are playing poker, others are taking part to a distributed auction. Within the PageSpace, only agents interact - whose user interface is transported to Alpha. The autonomously interacting agents that are part of applications, are called Delta agents and reside constantly on the PageSpace, where they use and provide application specific services. For instance, there will exist a poker agent for every player, indirectly connected with the human user via Beta and Alpha and coordinating with the other agents in order to play the game. The software agent can be assumed to be reliably accessible by other agents for the whole length of the game, while the user can come and go at her leisure.
Deltas can exhibit a varying degree of autonomy for responding to other agents requests even in the absence of the human master. The response can range from a simple "My master cannot respond" to a more complex and autonomous behavior. For instance, a user can instruct her auction agent to wait until the object she is interested in is being offered and then perform offers of 100 dollars higher than the current level until the maximum price of 5000 dollars is reached, and then leave.
Communication among Delta agents (and Betas) uses the coordination technology in PageSpace. Thus, messages are exchanged by an I/O mechanism to a shared information space. The Delta-Delta protocol is application specific: A poker agent will speak a Poker-game-protocol, while a chess Delta speaks a chess protocol, each requesting or providing poker or chess services from others. In addition to these application specific messages, a basic set of common services is defined for Deltas, such as telling others about their version.
Epsilons are agents which have administrative tasks. They are able to do privileged things that are prohibited to Delta and Betas. Each machine belonging to the same PageSpace has exactly one Epsilon agent constantly running.
Epsilon has two faces. On the one hand, it offers a set of common privileged services to Deltas and Betas (Start a Delta with some state, stop a Delta by brute force, and keep a log of started Deltas; store checkpoints of Delta-states somewhere; tell Deltas about their location and initiate the move of a Delta to some other machine).
In addition, Epsilon actually implements ``behind the stages'' the coordination structure which we call the Gamma environment. It is based on concepts from Linda. The role of Epsilon is central to our architecture. Its implementation goes far beyond just providing the common services. Epsilon is responsible to manage the Beta user brokers, just as a Web server manages homepages. In order to provide the access mechanism to Betas, Epsilon includes an HTTP server. Epsilon includes all mechanisms concerning the coordination platform.
The Delta-Delta protocol in the PageSpace is location independent, as other agents are addressed associatively, or by name. The Delta-Epsilon protocol is implicitly location dependent, as it addresses the single Epsilon agent co-located with the Delta agent. In order to move an agent, there must be some way to express the destination location of an agent. An agent should be able to ask for its current location. This can be achieved by a simple service of the Epsilon agents, allowing a Delta to communicate its location to other agents.
At least three situations may trigger the move of an agent to a different machine:
When an agent knows where to move to, it can initiate the move. A move comprises three issues: Removing the agent from its old location, transferring the agent, and starting the agent at its new location.
In our architecture, the move and transfer of state is handled by the Epsilon agents. A Delta agent uses a service of its Epsilon. Epsilon, in turn, invokes a remote Epsilon, which restarts the moved Delta agent an initializes its state. This protocol emphasizes the role of the Epsilon as the only agent able to address another agent at some specific location. Also, Epsilon is the only agent that has to have hold of the byte code of a Delta agent.
Java is an object orienteed language whose syntactical structure resambles C++ but inherits a better object-oriented approach from SmallTalk and Objective C. Objects are instaces of classes. A class can inherit from a basic class (just one, multiple inheritance is not supported) to extend basic class's behavior. The language model is somehow limited but its strongest point is its great simplicity. Java code is linked on the fly when loaded to be run [6]. All the dependencies in the byte-code are symbolic and are resolved only at load time. This way we can change the behavior of a base class without the need to recompile a derived one. Furthermore, loading a class happens only when it is required and can happen also from a remote host in the network.
Java is architecture neutral. Every architecture dependant code is not part of the language itself but of its standard library. Java's libraries are classes' collections called ``packages''. We can think of Java as an enviroment built by the language itself and its standard packages; many aspect of the language depend indeed from it. For instance, multithreading is native in Java, but there is no way to create a thread other than using a method of the Thread class.
A Java application can be ``spread'' around the network. The simplest way to take advantage of this feature is to think about a Java application just like a document. Watching a Java application means let it run in our host, possibly in a integrated fashion with our browser. The Java way to obtain this is to build each piece of Java code to be run in a browser as an ``applet''. An applet is the byte-code result of a compilation of a class that extends the basic class Applet contained in the java.applet package. This way each applet inherits a standard behaviour from Applet to adhere to a set of conventions which let them run within a Java-compatible browser.
Java suffers the lack of coordination among objects. There is no way to handle a simple client/server connection, except for explicitly using sockets and decode byte-stream requests and replies. Things get even worse when we have the need for the objects to cooperate in a more complex fashion. If we want the WWW to become an infrastructure for both developing and implementing distributed applications we need the ability to manage coordination between remote applications from Java. We solve such a problem using a well known coordination approach: adding Java a set of primitives to access Linda-like shared tuple spaces.
We designed Jada (Java+Linda) aiming to simplicity rather than performance. We choose a straight client/server approach to manage the tuple spaces. Each tuple space is a shared remote resource accessed through a tuple space server. The tuple space server is addressed using the IP address of the host it runs on and with its own port number (as usual with socket connections). This way we can run (almost) as many tuple space server as we like in a network so applications can operate on many tuple spaces.
Differently from other Linda-like implementations which include a preprocessor for small syntax changes to programming languages, we rather write a set of classes to access the tuple space using the tuple as a basic object, allowing the users to stay with their standard development tools.
The Tuple class offers a set of methods to access single items of the tuple itself. Tuples are usually built using a string containing the classic tuple representation: (item, item, ...). When an item cannot be successfully parsed as a number it is assumed it is a string. So the tuple (1,alpha,3) has type (Integer,String,Integer).
Each tuple item is accessed using the type Object. We can create the tuple shown in the previous example with:
Tuple tuple("(1, alpha, 3)");
To get, say, the second item we can use:
String second_item=(String)tuple.getItem(1);
(items are counted starting from zero).
Tuples can be partially undefined in order to be used as matching tuples for in and read operations. Fields within a tuple can be undefined and used only for their type in the matching algorithm. To define a tuple that matches any tuple having type (String, Integer) and having the first item set to ``alpha'' we can use:
Tuple matching_tuple("(alpha, ?Integer)");
In our representation an undefined item starts with a ? preceding the name of the class type it represent. A short form is provided for Integer and String (?i and ?s respectively).
Tuples can be used to perform operations in a tuple space. We created a class TupleSpace which implements the in, out, and read methods. This class representes a local tuple space and does not perform blocking operations (trying to read a tuple that is not present in the tuple space leads to a failure).
The in and read methods, whose structure is:
Tuple in(Tuple match); Tuple readTuple match;
return a tuple that matches the given match one (in also removes such a tuple from the tuple space). If no matching tuple is available they return null.
The remote TupleServer uses the TupleSpace class to manage its tuple space. TupleServer listens to socket connections and reads the operation to perform on the tuple space from this connections. To implement blocking in and read, TupleServer blocks the requesting application until the operation succeedes (i.e. when someone else puts a matching tuple in the tuple space). The server must then be able to handle concurrent multiple requests. We used Java's multithreading capabilities to ``spawn'' a new thread for each new request, allowing applications to put a tuple in the tuple space while other application are waiting for tuples to become available.
To avoid the need to use directly socket management code in the client application side we provided a TupleClient class that translates the usual in, out and read operations with server communications. This way the application just needs to create an instance of TupleClient and uses its in, out and read methods (in this case in and read are blocking calls) to perform operations on a remote tuple space. From the application's point of view there is no difference between the TupleSpace and TupleClient class other then the latter has blocking methods.
To build a Jada application is then just matter of running a TupleServer in a host and use TupleClient in the application code.
We are using Jada to build more complex PageSpaces, for instance based on object transactions [1] or agent-based services. In fact, agents in the PageSpace use and offer services. They do so by doing special versions of in's and out's of service requests and offers. These types services are denoted by some interface specification, which is the basis to match offers and requests. Thus, the Epsilon kernels will also be able to match descriptions of service types similar to forms [10]. The hold a Linda-like repository of service interfaces, and match them according to a subtyping relation amongst offer and request types.
An agent willing to use a service performs a service operation, which is in essence an out of a service request and an in of the results. A service offerer performs a serve - similar to an in of a service request -, performs the service and finally emits a result, which outs the results of the service. A matching on the subtype relation on the types of services given as arguments of the operations is applied when looking for a matching offerer, a Linda-like matching on the result-data (extended with a unique identifier) is applied when looking for the retriever of the results.
Thereby, we are able to coordinate multiple offerers of the same service in different versions, and follow Linda uncoupled coordination style, and offer a high level abstraction of service coordination.
All operations necessary for service coordination in the PageSpace are available for the programmer of Delta agents - that wrap the implementation of services - by inheriting from a pagespace.object class.
By combining three existing technologies - namely WWW, Java, and coordination-technology - it is possible to build a flexible platform to support open distributed applications. The necessary mechanisms turn out to be simple and require no extensions to the building blocks used. The protocols needed seem to be simple and scalable. PageSpace adds value to its building blocks by providing a highly abstract coordination mechanism for the development of open distributed applications.
Other approaches of enhancing the Web with coordination technology are WWWinda [7] and WULinda [9]. The former is a Web accessible interface to a local Linda tuple space; the latter uses local Linda-like coordination for modules within browsing and helper applications. The PageSpace approach is different in that it makes use of coordination technology to build distributed applications.
The PageSpace is currently under development; further
information can be found at
http://www.cs.tu-berlin.de/~pagespc.
PageSpace is supported by the EU as ESPRIT Open LTR Project 20179.
Coordination Technology for the WWW
This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds. The command line arguments were: The translation was initiated by Robert Tolksdorf on Wed Mar 20 09:43:27 MET 1996
About this document ...
latex2html -split 0 wetice.tex.
Robert Tolksdorf
Wed Mar 20 09:43:27 MET 1996