%&LaTeX
%\documentclass{article}

%R done: did several technical LaTeX-corrections
%R todo: ispell again. I did some spellchecking, but your changes have
%to be rechecked.
%R todo: take a decision on capitalization of headings and captions
%and implement it consistently throughout the paper.
%R done: changed figure placement \begin{figure} to \begin{figure}[htb]


\documentclass[citeauthoryear]{llncs}

%R packages I use
\usepackage{comment,path,breakcitelabels}
%R this sets figures as tight as possible
\setcounter{topnumber}{5}\setcounter{bottomnumber}{5}\clubpenalty=10000
\setcounter{totalnumber}{10}\renewcommand{\topfraction}{1}
\renewcommand{\topfraction}{1}\renewcommand{\bottomfraction}{1}
\renewcommand{\textfraction}{0}\widowpenalty=10000

\usepackage{graphics, xspace, epsfig}

\newcommand{\OOP}{object oriented programming\xspace}
\newcommand{\OO}{object oriented\xspace}
\newcommand{\WWW}{Word Wide Web\xspace}

\newcommand{\Tuple}{{\tt Tuple}\xspace}
\newcommand{\ObjectClient}{{\tt ObjectClient}\xspace}
\newcommand{\ObjectSpace}{{\tt ObjectSpace}\xspace}
\newcommand{\ObjectServer}{{\tt ObjectServer}\xspace}
\newcommand{\JadaItem}{{\tt JadaItem}\xspace}
\newcommand{\Integer}{{\tt Integer}\xspace}
\newcommand{\Float}{{\tt Float}\xspace}
\newcommand{\String}{{\tt String}\xspace}

\newcommand{\Out}{{\tt out}\xspace}
\newcommand{\In}{{\tt in}\xspace}
\newcommand{\Read}{{\tt read}\xspace}
\newcommand{\Innb}{{\tt in\_nb}\xspace}
\newcommand{\Readnb}{{\tt read\_nb}\xspace}

\newcommand{\mudarch}{{\it MUDArch}\xspace}
\newcommand{\service}{{\it ConfManager}\xspace}

\newcommand{\infig}[3]{
        \begin{figure}[htb]
        \centering
%       \includegraphics[totalwidth=\textwidth]{#1}
        \epsfig{file=#1, width=\textwidth}
        \caption{#2}
        \label{#3}
        \end{figure}
}

\newcommand{\at}{\char64}
\newcommand{\ampersand}{\char38}
\newcommand{\tb}{\hspace*{0.7cm}}
\newcommand{\br}{\linebreak}
\newcommand{\pbr}{\pagebreak}

\newcommand{\li}{\begin{itemize}}
\newcommand{\il}{\end{itemize}}
\renewcommand{\i}{\item}

\newenvironment{source}
{\medskip\begin{small}\begin{tt}\parindent=0pt}
{\end{tt}\end{small}\medskip}

\newenvironment{medaglione} {
        \begin{center}\setbox0=\hbox\bgroup
        \begin{minipage}{\linewidth} %\parindent=1em
        \begin{center}
} {
        \end{center}
        \end{minipage}
        \egroup \fboxsep=0.5em\fbox{\box0}
        \end{center}
}

\tolerance=500
\emergencystretch=100pt

\begin{document}
\setcounter{tocdepth}{5}
\setcounter{secnumdepth}{5}

%\tableofcontents

\title{The World Wide Web as a Place for Agents}

%R did lncs like preamble
\author{P. Ciancarini\inst{1} and
  Robert Tolksdorf\inst{2}
  and F. Vitali\inst{1}}
\institute{%
Dipartimento di Scienze dell'Informazione\\
Mura Anteo Zamboni, 7 -- 40127 Bologna, Italy\\
University of Bologna - Italy\\
E-mail: {\small{\tt \{ciancarini,vitali\}\at cs.unibo.it}}
%\textsl{mailto:ciancarini@cs.unibo.it},
%\textsl{http://www.cs.unibo.it/\char126cianca/}}
\and
Technische Universit\"at Berlin, Fachbereich Informatik, FLP/KIT,\\
Sekr.\ FR 6--10, Franklinstr.\ 28/29, D-10587 Berlin, Germany,\\
\textsl{mailto:tolk@cs.tu-berlin.de},
\textsl{http://www.cs.tu-berlin.de/\char126tolk/}}

\date{}

\maketitle

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% abstract
%
\begin{abstract}

The \WWW was born as an Internet service supporting
a simple distributed hypertext management system.
Since its start a number of technologies
have been proposed to enhance its capabilities.
In this paper we describe our concept of an {\em active Web},
namely how we design the software architecture of interactive
cooperative applications based on the \WWW.
An active Web includes {\em agents} able to use the services
offered by \WWW clients and servers.
In an active Web both users and agents can interoperate using a set of
basic mechanisms for communication and synchronization.
The active Web we describe here is based on coordination technology:
we explore two alternative implementations,
both based on Java enriched with alternative coordination kernels.

\end{abstract}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Introduction
%
\section{Introduction}
\label{sec:intro}

The \WWW is currently the de facto standard platform to access several
Internet services, like FTP or USENET news.  Given its pervasivity, it
has the potential to become the most used infrastructure to build
geographically distributed applications as well.  In fact, several
enterprises are turning to the \WWW as the environment of choice for
building innovative and sophisticated applications leveraging on the
open standards, their diffusion, and the programmable nature of the
environment.  In fact, the Internet can be used as an effective and
economical infrastructure for business support.  For instance, there
is a growing interest in groupware applications based on the WWW
infrastructure.  These applications are typically {\it multiagent},
meaning that they are highly concurrent, distributed, and based on
mobile code (\cite{MunDew97}).

However, the Web in its current state does not provide enough support
for applications based on agent-oriented programming, like groupware
or workflow, which require multi-agent coordination and complex
transactions.  Most WWW applications are either server-centric
(applications interfacing via CGI to a central mainframe-like server
machine), client-centric (applications made mostly of applets
providing services to users), or not integrated at all with the Web
(applications whose user interface is implemented by applets or
plug-ins using some proprietary protocol to connect to a proprietary
server).  All these approaches do not really satisfy the idea of an
active Web based on some structured configuration of (autonomous)
agents: they are either not really distributed, or not integrated with
the Web.

The PageSpace architecture (\cite{CTVRK98}) provides a design framework
for overcoming these limitations, creating a new paradigm for
Web-based applications that are composed of autonomous agents
performing their duties regardless of their physical locations.  The
PageSpace architecture is based on the Linda coordination model
(\cite{CarGel92a}) and can be controlled with different coordination
languages.  In this paper we demonstrate the flexibility of the
architecture by describing two different coordination languages and
applications where the PageSpace architecture has been fruitfully
used.

The paper is structured as follows: 
in section~\ref{sec:coordwww} we
discuss the issues arising when one has to design distributed,
interactive applications on the WWW.  
In section~\ref{sec:pagespace}
we illustrate the PageSpace reference architecture, that can be used
to design these applications.
In section~\ref{sec:pagespace} we discuss a direct implementation 
in Java of the PageSpace reference architecture.
In section~\ref{sec:pagespacejacopo} we discuss how we implemented a
PageSpace-based application using Java enriched with some coordination
primitives.
In section~\ref{sec:survey} we discuss alternative research and commercial
efforts to provide interactivity and coordination on the Web.
Section~\ref{sec:conclusions} concludes the paper.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Designing active Web applications
%
\section{Designing active Web applications}
\label{sec:coordwww}

The \WWW was born as a simple and efficient distributed system for
managing hypertext documents.  
The minimal set of components of such a system are
servers, clients, and documents including hyperlinks.  The
interactions among these components are driven by the HTTP protocol
and the CGI (Common Gateway Interface) mechanism.  HTTP is a very simple
TCP/IP based
protocol used by clients in order to retrieve documents stored on a
disk under the control of an HTTP server.  Usually documents are
stored in HTML format, a mark-up language with a typographical
semantics used by browsers to display the document contents.  However,
documents can also be created on-the-fly by a server-side application.
With CGI a client requests a document as the output of a process
that is run on the server when the request comes in. This simple
mechanism can be used in a ``tricky'' way in order to implement more
complex forms of interaction among documents, clients, and servers
(\cite{Ban97}).

According to the original design the only activity that can be
dynamically triggered in the \WWW is associated to the CGI
mechanism.  Soon users asked for more interaction than just browsing
documents and this brought to the development of a family of languages
that can be embedded into an HTML document and executed by the user's
browser. These languages are very different in their capabilities and
target; in fact, some are scripting languages intended to interact
heavily with the document itself (as in the case of JavaScript or
ActiveX), some are complex and fully-fledged languages that have
minimal interaction with the document (as in the case of Java).

Although these technologies allow us to ``activate'' the two key
components of the WWW architecture, namely servers and clients, we
still need techniques and protocols to control the coordination of
such components.

%
% The WWW as an agent world
%
\subsection{The WWW as an agent world}
\label{sec:wwwagent}

Intuitively, an {\it active Web} is a system based on standard WWW
clients and servers including some kind of agents performing some
activities on Internet resources.  The activities can take place at the
client, at the server, at the middleware level, at the gateway with
another active software system (eg.\ an external database, a decision
support system or an expert system), or even at the user level.

An active Web includes several {\it agents}. In fact, each component
of an active Web is as an autonomous agent in a world offering several
services to agents: thus, an agent is not just capable of computations
but can also interact (in possibly complex ways) with other agents.

The interaction among agents is usually accomplished using a
client/server architecture (as in any RPC-based system, such as CORBA)
(\cite{Lew95a}).  However, sometimes the client-server architecture is
not adequate: the interactions among the components may change in
time and their client/server relationship needs to be reversed, or
a designer may need to decouple the components, for instance to deal
with an application distributed over a world-wide intranet including
heterogeneous networks and machines.

A solution to these problems consists of designing the distributed
application as made of spatially scattered agents acting autonomously:
such a schema fits quite well into the so called {\it distributed
  objects model} (\cite{Adl95a,OHE96}).  When an application is composed of
several agents, the control of their coordination is an important issue.
In our approach we distinguish between agent computation and agent
coordination.

{\em Agent computation} is what concerns the internal behavior of an
agent.  An agent performs actions which are either method invocations
or message deliveries.  Synchronization actions (eg.\ starting,
blocking, unblocking, and terminating an activity) are the remaining
mechanisms in object invocation.

{\em Agent coordination} is what concerns the relationship between an
agent and its environment, namely synchronization, communication, and
service provision and usage.

Coordination languages separate coordination from computation, not as
independent or dual concepts, but as orthogonal ones: they are two
dimensions both necessary to design agent worlds (\cite{Cia96c}).

A coordination language should thus combine two languages: one for
coordination (the inter-agent actions) and one for computation (the
intra-agent actions). The most famous example of a coordination model
is Linda's Tuple Space (\cite{CarGel92a}, implemented on several
hardware architectures and integrated with several programming
languages.

Linda can be seen as a sort of assembly coordination language in two
ways. First and foremost, it includes very simple coordination
entities, active and passive tuples, which represent agents and
messages, respectively; it includes a generic coordination medium,
namely the Tuple Space, in which all tuples reside; it includes a
small number of coordination primitives.  Second, we say that Linda is
a minimalist coordination assembly because it can be used to implement
higher leve,l more complex coordination languages.  For instance, we
have used it to implement Shade, an extension of Java including a
concept of transactions (\cite{CiaRos98b}).

In fact, the Linda coordination model is quite minimalist to be
immediately used to coordinate WWW components (\cite{BCG97}).  What
lacks is the definition of a {\it reference architecture}, including
the basics of tuple space coordination but adding specific services
for WWW agents.  The interest for coordination architectures is
rapidly rising in the industrial world: CORBA can be considered one of
these architectures. Another one is Jini, by SunSoft.  In the next
section we describe PageSpace, that is an example of such an
architecture.

%R todo: remove greek names everywhere

%
% The PageSpace
%
\section{The PageSpace}
\label{sec:pagespace}

PageSpace is a reference architecture for multiagent applications
built on top of the WWW (\cite{CTVRK98}). PageSpace applications consist
of several distributed agents which coordinate themselves to
accomplish some cooperative task.

\begin{figure*}[htb]
\begin{center}
    \epsfig{file=pagespace.eps,width=.7\textwidth}~
\end{center}
\caption{The PageSpace reference architecture}
\label{fig:pagespace}
\end{figure*}

In the PageSpace reference architecture, therefore, we distinguish
several types of \emph{agents}, as depicted in
Fig.~\ref{fig:pagespace}:

\begin{itemize}
\item \emph{User interface agents} (also called {\it alpha agents}),
  implement application-specific user interfaces in general-purpose
  browsers. They are displayed in a browser according to the requests
  of the user.  Depending on the complexity of the application and the
  capabilities of the browser, there may be different instantiations
  of user interface agents (in HTML, JavaScript, Java, etc.) that are
  displayed or executed on the browser.

\item \emph{Homeagents} (also called \emph{beta agents}) are a
  persistent representation (avatar) of users in a PageSpace.  Even if
  at any moment users can disconnect from the shared workspace, it is
  still necessary to collect, deliver, and possibly act on the
  messages and requests of the other agents.  The homeagent receives
  all the messages bound to a user, and delivers them orderly to the
  user on request (ie.\ when the user is on-line).  Evoluted
  homeagents can in some circumstances actively perform actions or
  provide answers on behalf of the user in her absence.

\item \emph{The coordination kernel} (or \emph{gamma}) is the actual
  operating environment where agents live and communicate.  In
  PageSpace we do not dictate the use of a specific coordination
  kernel. In fact, different coordination kernels may provide
  different mechanisms for creating and controlling the agents of an
  application.  Thus, a designer should choose the coordination kernel
  most suitable to his application.  In this paper we will describe
  two different coordination kernels we have used, both based on Java.

\item \emph{Application agents} (also called \emph{delta agents}), are
  the agents that actually perform the working of the coordinated
  application.  They are specific of one application, and can be
  started and interrupted according to the needs of the application.
  They live and communicate in the coordination kernel, offer and use
  each other's services, interact with the shared data, and realize
  useful computations within the PageSpace.

  Some application agents will not interact directly with a user in
  any way, and therefore will have no need for a user interface.  They
  will just use or offer services to other agents. Other application
  agents, on the other hand, will have to be controlled and monitored
  by a user.  In this case, they will provide on request an ad hoc
  user interface agent, in the form of an HTML document, a Java
  applet, etc., which will be delivered to the requesting user and
  will be displayed or executed on the user's machine.

\item \emph{Kernel agents} (also called \emph{epsilon agents}),
  provide system services to the application agents.  They perform
  management and control task on the agents active within the
  PageSpace environment.  They deal with the activation, interruption,
  and mobility of the agents within the physical configuration of
  connected nodes.  Ideally, there would be one kernel agent for each
  participating machine, providing access to the local workspace.
  Kernels maintain the illusion of a single shared PageSpace when it
  is actually distributed on several computers, and provide mobility
  of the agents on the different machines for load balancing and
  application grouping as needed.

\item \emph{Gateway agents} (also called \emph{zeta agents)}, provide
  access to the external world for PageSpace applications.
  Applications needing to access other coordination kernels, network
  services, legacy applications, middleware platforms, etc., may do so
  by requesting services to the appropriate gateway agent.  Each
  gateway agent is specialized for dealing with one type of external
  environment, and will translate and deliver externally the services
  requests of the application agents, and will deliver the
  corresponding response back to the appropriate agent.

\end{itemize}

We call ``agents'' the entities present in the PageSpace architecture
since they are more complex than pure objects: the application agents
are autonomous and possibly mobile, homeagents can include knowledge
bases to work on behalf of a user, etc.

We foresee a user interface agent in each user browser, which is
connected to a homeagent providing stable access to the PageSpace.  A
set of application agents implement the functionality of a distributed
application, and a gateway agent provides access to a external
environment, for instance, some OLE-based document-centered
applications, like a spreadsheet, or some network service, like e-mail
or news.


\section{A prototypical implementation of PageSpace}
\label{sec:psd}

In this section we describe one initial instance of the PageSpace reference
architecture that has been implemented in Java for evaluation purposes.
Since this prototypical implementation never had any other name, we will
inappropriately use here the term ``PageSpace'' to refer to it, rather than
to the reference architecture described in \cite{CTVRK98}, as we do in the
rest of the paper.

%F The previous sentence was added to prevent misunderstanding in the reader
%F between the architecture and the implementation. If you know of a better
%F way, please do it.

The user interacts with his homeagent via the user interface agent
as shown in a Web browser. The homeagent is identified by a normal
URL, such as \path|http://pagespace.cs.tu-berlin.de/cgi-bin/beta|. A
specific homeagent is identified by the URL plus a user name, such as
\path|http://pagespace.cs.tu-berlin.de/cgi-bin/beta/robert|.

After logging into the homeagent, the browser displays an user interface
such as the one shown in
Figure~\ref{beta:homerobert}. The list on the top left contains all the
messages received from all the application agents needing to communicate
with the user. The control area on the top right offers the user a set of
buttons to control the homeagent. Finally, by clicking on one of the
messages in the list an appropriate application-specific user interface is
shown in the display area on the bottom.

\begin{figure*}[htb]\begin{center}
    \epsfig{file=homerobert.eps,width=.7\textwidth}~
  \end{center}
  \caption{\label{beta:homerobert}A user interface agent}
\end{figure*}

Specifically, the steps involved in using an application are the following
ones:

\begin{enumerate}
\item The user selects an application from a list in the control area
  and instructs the homeagent to use it.
\item The homeagent retrieves additional data on the application via
  HTTP and the initial interface for that application (a static HTML
  document stored somewhere on some Web server).  This interface is
  sent as a message for the user.
\item The user selects the correct item from the message queue and
  the corresponding interface is shown in the display area. A set of
  buttons there defines the
  set of possible interactions with the application.
\item Selecting a button results in a request to the homeagent to use
  a specific method of the application agent.  The homeagent issues a
  corresponding service request with the PageSpace coordination
  operations. The result of that interaction with an application agent
  is a string containing the new application interface generated by the agent,
  command, which is stored as a message for the user.
\item The user selects that message and is presented with the next interface,
  which includes the results of the previously-invoked operation.
\end{enumerate}

%R the following paragraph plus figure could be removed for space
Figure \ref{beta:archfig} shows the architecture of homeagents for the
experimental prototype. It consists of three components that are
implemented as different processes or threads: the interface for the
interaction with the user which is visible as the generated user
interface, the interface to the coordination kernel, and a repository
where received messages are kept until they are deleted by the user

\begin{figure*}[htb]\begin{center}
    \epsfig{file=betaarch.eps,width=.7\textwidth}~
  \end{center}
  \caption{\label{beta:archfig}The Architecture for the Homeagents}
\end{figure*}

Applications in PageSpace are identified by a URL to a resource which
contains a special application description. The use of a URL makes this
approach wholly integrated with the Web. Paralelly to plain
document-oriented Web, the agent-oriented PageSpace uses no central
directory of applications.

Any application agent consists of three modules called Kernel,
Service-Handler and Kernel-Connector.  The Kernel is the
``main-program'' that loads and launches the module containing the
provided services of the specific application, the Service-Handler. 
The
Kernel-Connector provides the connection to the Coordination Kernel of
PageSpace by managing the connection to a Kernel agent and by
propagating messages.

Kernel Agents are daemon processes that exist on specific machines
and together spawn the Coordination Kernel, the virtual room for
coordinating agents. Their functionality is central to the
prototypical architecture of PageSpace.  Kernel Agents contain the
following modules:

\begin{itemize}
\item A \emph{central control-unit} that invokes the kernel modules
  and executes them as Java threads. It constantly controls them by
  checking their states and taking appropriate action in the case of
  failures.
\item A \emph{server for homeagents} that is accessible via HTTP.
\item The \emph{Kernel-Connector} that establishes and manages the
  connections to other Kernel-Agents and implements the protocols for
  the distributed coordination kernel
\item Some \emph{Repositories} as the actual coordination technology used.
  They usually consist of a store of data items and methods to access
  them by coordination operations. In this prototypical PageSpace
  implementation, repositories for the coordination
  languages Laura (\cite{Tol98a}) and Java/Linda are foreseen.
\item The \emph{Kernel-Connector} for the application and gateway
  Agents.
\item The \emph{Agent-Store} as a repository of application Agents
  that operate as threads within the Kernel-Agent.  Application agents
  can be loaded by the Kernel and started as threads but do not
  necessarily have to. Gateway agents are always assumed to run
  external to the kernel.
\end{itemize}

\begin{figure*}[htb]\begin{center}
    \epsfig{file=epsilon.eps,width=.7\textwidth}~
  \end{center}
  \caption{\label{beta:epsilon}The structure of the kernel agents}
\end{figure*}
Figure~\ref{beta:epsilon} outlines the structure described. The
initial prototype of PageSpace was implemented to evaluate our
approach. Its implementation basis was Java 1.02 -- with the RMI
mechanism in Java 1.1 several technical details would change.

%R done: commented out section

\begin{comment}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Building a PageSpace using Paradise
%
\section{Building a PageSpace using Paradise}
\label{sec:pagespaceparadise}

We present here an implementation of a PageSpace based on
Paradise, a proprietary coordination kernel.
We used this implementation to build a WWW-based electronic commerce
application, namely a stock exchange accessed over the WWW.

%
% Paradise
%
\subsection{A coordination kernel: Paradise}
\label{sec:paradise}

Paradise is a commercial version of Linda for coordinating open
systems distributed over a network (\cite{Paradise}).
We recall that in Linda coordination is achieved
using a medium called {\em tuple space}.
Agents are usually sequential processes (eg.\ written in C or
FORTRAN) that use special operations to access the tuple space.
These operations allow an agent to add to the tuple space
an active/passive tuple or to read/remove a tuple
using an associative addressing scheme.

Paradise includes these operations and adds support for persistent
multiple tuple spaces and transactions across tuple spaces.
The tuple spaces (that can be dynamically created) implement an access
restriction policy (so that, for example, only authorized agents can
remove tuples from a tuple space) that is similar to the one used in
Unix file systems.

We present an example to show how a simple groupware
system, namely an e-mail distribution system, could be designed
using Paradise. Suppose that a little company owns only one
mailbox visible from outside, whereas each company employee has a
personal internal mailbox. We design a system able to
distribute mail from the global mailbox to the private ones.
We use a tuple space for the global mailbox, and one tuple
space for each private mailbox (Fig.~\ref{fig:PT}).

\infig{postoffi.ps}{Post Office example}{fig:PT}

The Paradise program shown in \ref{tab:prog1} implements the
software architecture for PostOffice.

\begin{table}
\begin{medaglione}
\small{
\begin{verbatim}
/**************************************
PROGRAM 1
Create a persistent PostOffice
and several LetterBox tuple spaces
***************************************/
#include <paradise.h>

main() {
  TSHANDLE myts, rmyts;

  open @ rootts();

   /* Create Post Office tuple Space */
  myts = create @ rootts(PARADISE_PERSISTENT,
                         PARADISE_LABEL("PostOffice"));
  rmyts = restrict @ myts(PERM_OUT);
  register_handle("PostOffice","Sender","xxxx", &rmyts);
  rmyts = restrict @ myts(PERM_IN);
  register_handle("PostOffice","Broker","xxxx", &rmyts);
  close @ myts();

   /* Create a LetterBox for each employee */
  myts = create @ rootts(PARADISE_PERSISTENT,
                         PARADISE_LABEL("LetterBox Employee 1"));
  rmyts = restrict @ myts(PERM_OUT);
  register_handle("Employee 1","Broker","xxxx", &rmyts);
  rmyts = restrict @ myts(PERM_IN);
  register_handle("Employee 1","Employee","xxxx", &rmyts);
  close @ myts();

   /* Create a LetterBox for unknow employee */
  myts = create @ rootts(PARADISE_PERSISTENT,
                         PARADISE_LABEL("LetterBox Unknow"));
  rmyts = restrict @ myts(PERM_OUT);
  register_handle("Unknow","Broker","xxxx", &rmyts);
  close @ myts();

  close @ rootts();
}
\end{verbatim}
}
\end{medaglione}
\caption{Creating the software architecture for PostOffice}
\label{tab:prog1}
\end{table}

This program first opens a persistent tuple space named {\tt rootts};
it is a service space which represents the basic
Paradise abstraction (the Paradise server) used to create new
tuple spaces.

Then, operation {\tt create} creates a persistent tuple space (a
persistent tuple space survives even after the Paradise program
terminates) labeled PostOffice. Such an operation requires a
{\it handle}, namely a reference to an open tuple space.
It also returns a handle ({\tt myts}) that can be used
to access the new tuple space.

Paradise agents can only use handles to access tuple spaces;
names are reserved to the Paradise admin,
who uses them to access the Paradise server in case of problems.

A handle can be redefined as a ({\it restricted tuple space
handle}) using {\tt restrict}. The agent creating a tuple space
has full access, namely it can write, read, and delete tuples.
The {\tt restrict} operation creates a new handle to the same
tuple space using a different set of access rights. In our
example, the handle Sender is registered only for {\tt out},
while the handle Broker is registered only for {\tt in} (see
Fig.~\ref{fig:handle}).

The registration of handles is managed by the Paradise server,
which exports the available handles to all agents. Registration
happens as follows:

{\tt register\_handle(name1, name2, password, ts\_handle)}

where {\tt name1}, {\tt name2}, and {\tt password} are strings
whereas {\tt ts\_handle} refers to a tuple space. Strings name1
and name2 implement a two-layers name space; the proposed
password is only needed when the handle must be deleted.

\infig{handle.ps}{The handle system in the PostOffice example}{fig:handle}

The program in Tab.~\ref{tab:prog2}) shows how a sender works.
Function {\tt lookup\_handle} requires the names to identify a
handle and returns the handle as {\tt \&myts}, if found.

\begin{table}
\begin{medaglione}
\small{
\begin{verbatim}
/************************************
PROGRAM 2
Insert a new message into PostOffice
*************************************/
#include <paradise.h>
main() {
   TSHANDLE myts;
   lookup_handle("PostOffice", "Sender", &myts);
   open @ myts();
   out @ myts("Employee 1", "Hello!");
   close @ myts();
}
\end{verbatim}
}
\end{medaglione}
\caption{Sending a message}
\label{tab:prog2}
\end{table}

The program in Tab.~\ref{tab:prog3}) reads messages from
PostOffice and delivers them to private mailboxes.

\begin{table}
\begin{medaglione}
\small{
\begin{verbatim}
/***************************************
PROGRAM 3
Broker
****************************************/
#include <paradise.h>
main() {
   TSHANDLE myts;
   char addressee[100];
   char message[256];
   int stat;

   lookup_handle("PostOffice", "Broker", &myts);
   open @ myts();

   while (TRUE) {
           in @ myts(?addressee, ?message);
           if (lookup_handle(addressee, "Broker", &myts) == 1) {
                   open @ myts();
                   out @ myts(addressee, message);
                   close @ myts();
           }else{
                   lookup_handle("Unknow", "Broker", &myts)
                   open @ myts();
                   out @ myts(addressee, message);
                   close @ myts();
           }
   }
}
\end{verbatim}
}
\end{medaglione}
\caption{Broker agent}
\label{tab:prog3}
\end{table}

After having obtained a handle, the broker agent waits for a
message for any receiver with the operation
{\tt in @ myts(?addressee, ?message)}.
When a message is put in the tuple
space, the operation succeeds and the message is delivered to the
addressee's private mailbox; if the address is unknown then a
default tuple space is used for delivery.

Transactions in Paradise are used to group several
operations as a unique atomic operation in which either all
or none succeed.
The operation {\tt xaction} starts a transaction,
while the operation {\tt commit} terminates it.
Once a transaction is started there are two possible results:
either the transaction is permanently recorded or it is aborted.
An agent can explicitly abort a transaction using the {\tt cancel}
operation, but only if the transaction has not been concluded yet
with a commit ({\it pending transaction}).

For instance, suppose that in the PostOffice example we have to
count and enumerate the messages for each employee. A possible
solution consists of inserting a counter in each private mailbox.
The counter tuple is the tuple {\tt ("Counter", num)}, where {\tt
``Counter''} is a string, while {\tt num} is an integer.

\begin{table}
\begin{medaglione}
\small{
\begin{verbatim}
/***************************************
PROGRAM 3
Broker using transactions
****************************************
#include <paradise.h>

main() {
   TSHANDLE myts, ts;
   char addressee[100];
   char message[256];
   int stat, num;

   lookup_handle("PostOffice", "Broker", &ts);
   open @ ts();
   while (TRUE){
           /* Read message from "PostOffice" tuple space */
           in @ ts(?addressee, ?message);

           if (lookup_handle(addressee, "Broker", &myts) == 1) {
                   open @ myts();
                   /* Put the message in the "Employee" tuple space */
                   xaction @ myts();
                   in @ myts ("Counter", ?num);
                   out @ myts(num, addressee, message);
                   out @ myts ("Counter", num+1);
                   commit @ myts();
                   close @ myts();
                } else {
                   lookup_handle("Unknow", "Broker", &myts)
                   /* Put message in the "Unknown" tuple space */
                   open @ myts();
                   out @ myts(addressee, message);
                   close @ myts();
           }
   }
}
\end{verbatim}
}
\end{medaglione}
\caption{Broker agent using transactions.}
\label{tab:prog4}
\end{table}

The program shown in Tab.~\ref{tab:prog4} defines a new broker agent
using transactions to enumerate messages.  Such a broker agent reads a
counter tuple, stores a message giving its number, then stores a new
incremented counter tuple.

%
% The Stock Exchange
%
\subsection{The Stock Exchange}
\label{sec:stockexcg}

The Stock Exchange is an application for Electronic Commerce
we built with our Paradise-based PageSpace.
Currently, most e-commerce applications on the WWW can be
classified as virtual malls. A {\em virtual mall} is like a shop
in which a user can enter, examine the items on sale, and buy
some items.  The actual delivery of the items is performed by a shipping
service in the real world.  At the moment virtual malls often contain
specialized products, such as books, software, hardware, records, etc.
Each mall specializes in a product type and offers a catalogue of its
products.

>From a technical point of view virtual malls differ in the
proprietary interaction schemata they use. Thus, each virtual mall
is a component of its own on the WWW. This mirrors what happens
in the real world: different shops in different places need
different people to manage each shop. However, such heterogeneity
is a drawback on the WWW: buyers have to check on each site what form of
payment is accepted, which security measures are guaranteed, which
privacy level is assured, and so on.

% Fabio: Se solo questi sono i problemi, e' poca roba.
% Io la farei lunga sulla differenza tra applicazioni:
% modelli di navigazione, tipo di interazione, ordine
% delle pagine, modo di acquisto, etc.

We developed a Stock Exchange application as a first step towards
an integrate infrastructure to support Electronic Commerce
applications based on the WWW.

In this application our items on sale are those vegetables for
which an EC quality recommendation exists. In fact, the
application has been developed according to the specifications
given by the managers of Bologna's Food Gross Market.

The basic requirements for the application were:
\li
\i the interface must be able to show one or more pictures of the product;
\i the interface must be able to show a quality label for each product and
must
provide access to the complete description of the quality recommendations.
\il
The application must support two major interaction paths:
\li
\i direct: the user directly manages exchanges;
\i via software agents: the user delegates software agents to
manage exchanges in an autonomous way but under the control of
general behavior rules.
\il

This application gives its users the ability to perform some
buy/sell operations; here is a rough list
of the services offered:

\li
\i give the list of pending ''buy'' offers for a product;
\i give the list of available ''sell'' offers for a product;
\i submit a ``buy'' or ``sell'' offer;
\i ``buy'' or ``sell'' transaction request;
\i abort a ``buy'' or ``sell'' transaction request.
\il

The design of the application architecture is based
on Pagespace (some ad-hoc changes were necessary in order to
adapt to the application requirements). The first step is to
identify alpha, beta, gamma, and delta. Alpha agents are,
of course, the user interfaces in WWW browsers;
beta agents are the browser
companion processes that act like bridges between the user
interface and the coordination layer; delta agents are the
service providing components used by the Stock Exchange manager
in order to create a virtual stock market environment; the gamma
environment is, of course, Paradise.

All agent interactions are based on tuple exchanges using private
tuple spaces as channels. Most interactions follow the following
protocol:

\li

\i the first agent puts a tuple in second agent's tuple space
asking for an operation;

\i the second agent performs the requested operation and puts the
resulting data, in form of tuples, into the first agent's tuple
space.

\il

All these operations are performed using distributed transactions
in order to avoid inconsistencies due to
network lag or host failures.

%
% The Stock Exchange application as a PageSpace
%
\subsection{The Stock Exchange application as a PageSpace}
\label{sec:agentsparadise}

We have used Paradise as a Gamma coordination environment, used
by all agents to coordinate their activities. Using multiple
tuple spaces we built a modular system in which tuple spaces are
used as both the communication channels and the coordination media.

\infig{paradisepagespace.eps}{PageSpace with Paradise}{fig:paradisepagespace}

In Fig.~\ref{fig:paradisepagespace} we depict the architecture of
the PageSpace as written in Paradise.

When the system boots up the Tuple Space Manager (an Epsilon
agent) is executed; it creates the Handles' Tuple Space, the
Common Tuple Space and it activates the remaining Epsilon agents.

All the other tuple spaces are created (and possibly deleted) on
the fly by agents. The Tuple Space Manager is used to register
each new tuple space in order to keep track of what is going on
in the system.

\infig{paradisedeltadelta.eps}{Delta Interaction}{fig:paradisedeltadelta}

The Common Tuple Space is used by agents in order to find each
other; once they join in the Common Tuple Space they can
dynamically create a new private tuple space (as depicted
in Fig.~\ref{fig:paradisedeltadelta}.

The User Manager takes care of managing PageSpace's users. The first
time a user logs into the PageSpace she accesses an HTML page where,
using forms, she writes username, password, and other information. The
CGI script activated by posting the form sends the relevant
information to the User Manager. This returns a pointer to the user's
Beta agent, creating it if necessary.
\end{comment}

%R todo: the section title has to be change here, as a pagespace with
%java has already been described above. what about a ``pagespace with
%Linda''?
%F How is this?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Building a PageSpace using Java+Linda
%
\section{Building a PageSpace for cooperation: MUDWeb}
\label{sec:pagespacejacopo}

In (\cite{CiaRos97} we introduced Jada, a Java-Linda combination.
Jada was a first experiment in combining Java with a coordination
model.  Here we describe JaCoPo, a combination of Java with a more
expressive coordination model based on nested tuple spaces, as in
Paradise.

JaCoPo is composed of a syntactic extension of the Java Language and a
run-time environment.  The syntactic extension enriches Java with a
set of Linda-like coordination constructs.  The run-time environment,
implemented in Jada, supports multiple nested tuple spaces.  The basic
entity in a JaCoPo program is the \emph{agent}.  Each agent can access
the available tuple spaces or create new ones.  Every agent has a
\emph{reference tuple space} that is used as the default shared space
for the coordination operations that do not specify one.

A ``move'' operation is provided to allow an agent to change its
reference tuple space at run-time, enabling what we call ``migration
by reference'': although the agents do not move physically, their
references for the outside world do, thus modifying the agent's
environment.  This is similar to what happens to Unix processes when
they ``move'' across a file system changing their working directory.

In JaCoPo a {\em handle} identifies the root of a tuple space tree.
Each tuple space tree is handled by a JaCoPoManager server named {\tt
  root}. An agent can access a JaCoPoManager server using {\tt Open},
then any {\em TupleSpace} managed by that server can be accessed using
a path name as follows:

\ttfamily
\begin{verbatim}
root # "ATupleSpace":"Subspace#1":"Subsubspace#2"
\end{verbatim}
\normalfont

\noindent
{\tt "ATupleSpace"} is a subspace of {\tt root},
{\tt "Subspace\#1"} is a subspace of {\tt "ATupleSpace"},
{\tt "Subsubspace\#2"} is a subspace of {\tt "Sub\-spa\-ce\#1"}.

All tuple space operations should specify a pathname. If no pathname
is used, the operation refers to the default reference tuple space.

JaCoPo includes the basic {\em Linda-like} primitives: {\tt Out}, {\tt
  Read}, and {\tt In}, either blocking or non-blocking.  Moreover, it
includes some set-oriented operations, like {\tt rdall} and {\tt
  inall}, whose result is a multiset of tuples stored in an array.
For instance, the operation {\tt rdall("message",?String:messages)}
stores in array {\tt messages} all strings found in the tuple space.

The JaCoPo runtime is based on two main classes, namely {\tt
  JaCoPoManager}, which manages a tree of nested tuple spaces, and
{\tt JaCoPoObject}, which exploits the coordination services offered
by a JaCoPoManager object.

%
% MUDWeb
%
\subsection{MUDWeb}
\label{sec:MUDWeb}

MUDWeb is a groupware platform we have designed and implemented using
JaCoPo.  We were inspired by MUD (Multi User Dungeon), a cooperative
environment in which many people socialize and interact.  MUDs can be
used as enabling technologies for several groupware applications
(\cite{Das97,Row97,TDD97,DHW98}).  A MUD platform usually offers the
infrastructure of a role-playing game (hence the name) where human and
robot players interact, visit dark and magical places, fight monsters
or other players, and seek treasures.  More generally, a MUD is an
abstract platform that users can program to create shared virtual
realities.  Thus, a MUD is a very powerful abstraction to describe a
general platform for cooperative work on the WWW, that provides a
general framework for users to interact with each other and to manage
items to be shared, such as documents and resources.

MUDWeb consists of a number of agents which coordinate themselves with
respect to a set of services according to a number of protocols based
on tuple exchanges. MUDWeb includes several ``rooms'' which correspond
to tuple spaces including some default services.

A room is defined by a set of attributes: its name, some exits, some
HTML code, some access rights, and some services.  For instance,
Fig.~\ref{fig:roomcode} shows the declaration of a room.

%R done: remove ~ used for indent
\begin{figure}[htb]
\begin{verbatim}
room JustARoom
access USER1, WIZARD
code "http://java/gaggi/nik/html/RoomCode.html"
service Counter "Services.CounterService"
    START\_VAL="1"
    HTML\_FILE="html/RoomCode.html"
exit OtherRoom1, OtherRoom2, Hall
data ("Tuple\_1", 1), ("Tuple\_2", 2, 2)
end
\end{verbatim}
\caption{\label{fig:roomcode}A room in MudWeb}
\end{figure}

This room is named {\tt JustARoom}.  The clause {\tt access}
specifies that only users USER1 and WIZARD can enter the room.  Clause
{\tt code} is mandatory, and describes the HTML code to be displayed
when a user enters the room.  Clause {\tt service} specifies an agent
named {\tt Counter} being active in the room, offering service {\tt
  Services.CounterService} (see below a description of the main
available services).  Clause {\tt exit} specifies other rooms
connected to this one, so that a user can ``navigate'' from room to
room.  Clause {\tt data} specifies that this room contains two tuples.

The MudWeb architecture is implemented by a number of coordinated
servers offering the basic abstraction of nested tuple spaces.
Fig.~\ref{fig:mudarch} shows the software architecture of MUDWeb.

\begin{figure}[htb]
\center{\epsfbox{mudarch.eps}}
\caption{A MUD-like active Web}
\label{fig:mudarch}
\end{figure}

Services are autonomous agents that wait for command tuples and
perform services based on their content. Services are generally very
small and specialized modules that react to a limited list of
commands. The functionalities of an application are thus implemented
by a score of services cooperating together.  Clients are user
interfaces using some role-specific HTML page or Java applet.

%
% MUDWeb as a PageSpace
%
\subsection{MUDWeb as a PageSpace}
\label{ssec-agentsjacopo}

We have used JaCoPo as a coordination kernel, used by all agents to
coordinate their activities.  A MUDWeb server contains three kinds of
agents: the \emph{avatars}, the \emph{services}, and the
\emph{mudshell}.  The avatar is the persistent representation of a
human user: it is a Homeagent controllable by the user through the
Interface agent to be displayed within a browser.  Actually an avatar can
accept commands and return data in a variety of methods, including
e-mail messages.  Services are the Application agents in the shared space,
that implement the actual computations of the distributed application.
The Mudshell is the client of the MUDWeb application, and is the
interface framework where the interaction with the user takes place:
the MUDshell provides primitives for moving from one available shared
space to another, and allow the user to interact with the services by
providing a MUD-like text box for direct commands, and displaying the
most common ones on appropriate buttons. Furthermore they allow
avatars to display their interfaces just like the other services.

\begin{figure}[htb]
\center{\epsfbox{mudarch.pagespace.eps}}
\caption{\label{fig:mapping}MUDWeb as a PageSpace.}
\end{figure}

Comparing Fig.~\ref{fig:mudarch} with \ref{fig:mapping} we see how
MUDWeb implements the PageSpace architecture.

The main innovation consists of how Homeagents are implemented.  In
MUDWeb a Homeagent is based on two different classes: the MudShell client
and the Avatar.  Both classes implement the MudPlayer interface, which
define how people can interact with the architecture.

MUDWeb services are defined as agents operating in a room.
Interestingly, some services are implemented as gateway agents.  For
instance, this is useful when a service has to input messages formed
according to some special protocol like NNTP (news) and output their
contents in some MUDWeb room.  As another example, avatars exploit
specific gateway agents to answer by e-mail to their users. An avatar
can also emulate an HTTP server, because it has to be accessible by
HTTP as well.

The design of a cooperative application based on MUDWeb consists of
instantiating the classes of the framework showed in
Fig.~\ref{fig:mudweb}.

\begin{figure}[htb]
\center{\epsfbox{framework.eps}}
\caption{The MUDWeb framework.}
\label{fig:mudweb}
\end{figure}

\subsection{Conference management in MUDWeb}

MUDWeb has been used to design and implement a workflow system
supporting the management of a scientific conference.  The system,
named \service, has the goal to simplify the management of the review
of papers submitted to an international scientific conference.

The problem of managing the peer-review of papers submitted to a
conference can be considered a case study in coordination.  In fact,
authors, reviewers, and program committee members can interact with
the system using both synchronous (online WWW) and asynchronous
(e-mail) communication interactions.  Several activities can be
automated, aiming at supporting the coordination protocols typical of
a specific conference model.

\begin{figure}[htb]
\center
\epsfbox{confman.eps}
\caption{\label{fig:confman}
Using MudWeb to design a Conference management System}
\end{figure}

\service includes the following rooms:

%R done: changed layout

\begin{itemize}

\item \emph{SubmittedPaper} Every paper is stored in a room of this
  type, that is dynamically created when the paper is submitted.  The
  room will also store the reviews when they will be ready.

\item \emph{ReviewRoom} is used by reviewers to store their reviews
  before they are finalized.

\item \emph{SelectRoom} is a room accessible to the program committee
  members only; it stores the scores assigned to papers.

\item \emph{Papers} is a room reserved to the conference organizers:
  it contains managing data like the full list of submitted papers and
  the address data of authors.

\end{itemize}

\service offers in each room some specific services.  All services
come in two flavors, either synchronous or asynchronous.  For
instance, the service {\it Services.Announcer} accepts reviews coming
by e-mail, checking that they refer to the paper stored in the same
room.  The service {\it Services.Submitter} is similar to the
preceding one, but supports on line user interaction.

Asynchronous services rely upon \emph{avatars}, which have to be
programmed to perform the necessary tasks.  The (server-side) avatar
acts as an e-mail client of an e-mail server; it controls the user
mailbox and processes the messages it contains.

%R what is this? A subheading???
{\bf Services for authors of papers}
%R removed new line here
A new room is added when a new paper is submitted, and an avatar is
created for the author(s).  Submission is either online or by email:
in both cases the command \texttt{submit} is used.
Fig.~\ref{service:fig2} shows the format of an e-mail submission.

\begin{figure}[htb]
\begin{verbatim}
submit
Title: The World Wide Web as a Place to Work in
Authors: P. Ciancarini and R. Tolksdorf and F. Vitali
URL: http://hostname/click\_here
In this paper we describe our concept of an active Web,
namely how we design the software architecture of interactive
cooperative applications based on the WWW.  END
\end{verbatim}
\caption{\label{service:fig2}Submitting a paper.}
\end{figure}

The method \texttt{processMail()} parses and interprets the message.
The message has to specify the values for the title,
authors, and URL fields on different lines. Other lines (eg.\ the abstract)
are considered plain text to be simply translated in HTML and inserted in
the room associated to the paper.

Another service that can be invoked by an author is \texttt{status},
in order to know some information on the review status (see below).

{\bf Services for reviewers} Each {\it SubmittedPaper} room, created
to store a submitted paper, will also store the reviews to it.
User input is handled by HTML forms and two CGI scripts.  The CGI
scripts generate a form and build a tuple, respectively.  The tuple is
temporarily stored in the same room containing the paper being
reviewed until it is ``confirmed''; after the confirmation the tuple
is moved in the selection room.

A reviewer can work either on-line or by email.  If the reviewer is working
on-line he/she has to be in a paper's room.  If the reviewer is using
e-mail, he/she has to send a message \texttt{announce}, such as the one in
Fig.~\ref{fig:reviewcmd}.

\begin{figure}[htb]
\begin{verbatim}
announce
Paper: 1
Agent: reviewer1
\end{verbatim}
\caption{\label{fig:reviewcmd}Announcing a review.}
\end{figure}

The message specifies an article id number and a username associated
to the agent sending the message.  A reviewer then fills in a form
according to some evaluation grades.
The filled form is sent to the reviewer avatar which transforms
the message in a tuple to be stored in the paper room.
Then the service \texttt{Services.Submitter} will be activated.

{\bf Services for PC members}
The service {\it Services.Selector} can be activated in the
room {\it SelectRoom} and is implemented by the class {\tt Services.Selector}.

This service is essentially a chat system
to be used by PC members to talk and
browse the stored dialogs.


\section{Technology for Coordinating Web Applications}
\label{sec:survey}

The PageSpace reference architecture 
is intended as a framework to help designers 
to deal with the coordination of distributed activities
in Web based applications. 
It is interesting to compare our solution
with alternative ones.
One can distinguish different approaches 
studying where a Web application designer puts
the main focus of activity in such applications,
namely server-side, or client-side, or somewhere
``in the middle'', namely in the middleware.

In fact, the most conventional location of activity 
in Web based applications is at the servers side. 
This approach was taken very early in standard Web server technology by
the introduction of the {\it Common Gateway Interface (CGI)}. 
According to CGI, 
some program can be executed upon the request of a URL, 
which dynamically generates an HTML page by
performing some activity. 
The classical example for this approach
is the generation of a report from some database contents, 
to be delivered to the requesting Web client 
in the form of an HTML page.

Mechanisms to preprocess additional tags within HTML pages appeared
soon with early server software as ``{\it server-side includes}''. 
For higher expressiveness, 
complete languages were made available. 
The Web* system is
a good example of such server sided activity is Web* (\cite{Alm95}).
Such a system interfaces a Web server
with a Tcl/Tk interpreter, 
which in turn can access objects via CORBA.
As a variant, the OreO approach implemented processing of information
by using proxies (\cite{BMMM94}).

Meanwhile, commercial vendors provided complete server-based solutions
for interactive and collaborative applications on the Web, such as
Lotus Domino, or the systems based on Microsofts' active server pages.

In conclusion, today systems with server-side activity in applications are
the dominant technology for Web applications. 
However, they inherit all problems of centralized systems, 
for example with respect to
single point of failures, or performance bottlenecks.

A different option for designers of
Web applications is to put the main focus of 
activity at the client side.
With the first browser generations, only 
{\it helper} applications could be
activated at the client side. A helper is an autonomous
program callable from the browser but offering 
a different user interface, usually displayed
in a different window: a typical example
is the helper to display PostScript documents.
Systems like SHAREDweb
(\cite{KGK94}) used helpers to provide application services,
rather than displaying special media types. 
The coordination of multiple helpers
became an issue; 
for example, the WWWinda system (\cite{GNSP94})
used Linda-like coordination technology 
to coordinate a browser orchestrating multiple helpers
to be synchronized for multimedia documents.

It became rapidly clear that it was desirable 
to integrate an execution environment
\emph{within} the browser.  A variety of prototypical browsers
was developed for various languages, such as Objective Caml
(\cite{Rou96}), or Python, (see the Grail browser at
\path|http://grail.cnri.reston.va.us/grail/tcl|), etc.

The dominance of Java and JavaScript, incorporated in the two
major Internet browsers, has pretty much satisfied the ``market'' for
client-side activity. However, despite the initial hopes, both are
currently not widely used for distributed applications.
Java can be used to design highly ``intelligent terminals'' to access
special applications -- an example is Internet banking software, such
as Twister from Brokat (see \path|www.brokat.de|). 
Instead, JavaScript seems
to be used only to enhance the user interface of Web pages, hardly ever
more than ``highlighting'' parts of pages by exchanging displayed
images when the mouse pointer moves across them.

HTTP as the communication protocol in the Web makes interactive applications
very complicated to implement. This is mainly due to the connectionless,
unidirectional paradigm embedded in HTTP. Activity could be coordinated by
extensions to the communication protocol.

With the advent of plugins, this option has been used to establish
communication channels between plugins and proprietary servers, that go beyond
the limitations of HTTP. The HTTP-NG protocol currently developed by the World
Wide Web Consortium will also contain extensions to allow coordination of
activity at the server and the client side.  Currently, however, HTTP provides
the communication platform for the Web and it is unclear which browser
generations will support more sophisticated protocols.

One could also understand HTTP as a pure transport protocol and stick to
existing middleware environments to coordinate open systems for applications.
First prototypes used CORBA (\cite{REMBM95}) and DCE
(\cite{BIVYW95}) as the actual implementation basis for open
applications.

Soon, commercial vendors have developed systems and specifications
that allow for interaction of distributed components and objects via
the Web. Examples are RMI from Sun within the Java standard, DCOM from
Microsoft, and IIOP, an Internet integration of CORBA that can be
found, for example in Netscapes Java libraries giving access to OMG
compliant object brokers.

Today, there seems enough of such enabling technology implemented and
available within Web technology. However, there is still no ``killer
application'' in widespread use that turns 
Internet users into participants
in a distributed world of active objects or agents.
Our proposal, namely PageSpace, defines a design framework
and offers some enabling tools to help designers
of coordinative, agent-based Web applications.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Conclusions and Future Work
%

\section{Conclusions and Future Work}
\label{sec:conclusions}


Our initial vision of PageSpace had to be refined in the course of designing
and implementing the platform.  During the project we made several
observations on applying coordination technology to the Web.
In fact, the issue of coordination in Web applications is still an open
question which is not settled in a satisfactory manner.
The Web can be the environment in which 
coordination technology could prove its
strength and provide a convincing example of its usefulness of
because it has the potential for the integration
of an active, agent-based Web 
by a uniform notion of activity and coordination.
Interestingly, the family of Linda-like coordination languages 
we have developed is only one possible flavor of coordination
technology, and it stands in direct competition with other,
more industrial technologies, like distributed,
heterogeneous object-oriented platforms \`a la CORBA. 
In the field of Web applications, 
coordination technology has to compare with approaches that
at moment have a much stronger industrial support and
service resources.
The implementation of coordination technology 
in the form of a programming language to control agents
over the World Wide Web
faces severe engineering problems with respect to 
the organization of shared coordination media to be used, 
their replication, the addressing of elements
therein, and handling potentially high load demands.

At the moment we are exploring the interaction capabilities offered by
Linda-like coordination models to mobile Java agents. Another issue we
are exploring is security, that is especially important for e-commerce
applications based on PageSpace (\cite{CKRTV97b,RNSP97}).
We also are studying how the advent of XML technology
can be exploited for agent-based programming.
More information on current activities in PageSpace can be found
on the Web at \path|http://www.cs.tu-berlin.de/~pagespc|.

\bigskip\noindent
\textbf{Acknowledgments}.
PageSpace has been supported by the EU as ESPRIT Open LTR project
\#20179.
It is currently supported by the German DAAD and the Italian CNR
within the VIGONI program.  Several people contributed to the
development of the ideas described in this paper; we thank here
especially the students G.\ Busi and N.\ Gaggi of UniBologna,
and A. Knoche of TU Berlin.

{\small
\bibliographystyle{apalike}
\bibliography{biblio}
}
\end{document}
