% Robert marks his comments with
%R
%R Fabio, thanks a lot for merging the comments with the source.
%R
%R I suggest to continue that way with %P and %D
%R
%R I did to following
%R - Lots of LaTeX stuff
%R - Removed the greek letters.
%R - Changed ``user agent'' to ``user interface agent'' - this is what we
%R   agreed upon and this is the true description of alpha.
%R - Changed ``midware'' to ``middleware'' for consistence
%R
%R Remarks:
%R - Please fill in/check biographies at the end.
%R - Davide, is there a way to redo the screen shot from the auction so that
%R it does not include netscapes buttons and the url?
%R - Please let us be more consistent concerning capitalization in headings
%R - and for terms like ``Figure'' and ``figure''.
%R--------------------------------------------------
%- section 3.5, first paragraph: is it really true that jada is the
%kernel on which we implement laura/share? do we really want to claim
%this?
%
%D I did a touch up to the auction image and I removed the URL but the
%  buttons are still there. The new eps file is auction2.eps
%R And I had to finish that work and removed the buttons. The new eps is
%R auction3.eps

%R Second round for me:
%R - Used ``section'' consistently
%R - Used ``Fig.'' consistently
%R - Used ``tuplespace'' consistently
%R - Used ``object space'' consistently
%R - Made usage of capitalization in headings consistent
%R - Fixes several typos
%R - Tried to take out references to the section on electronic commerce, which
%R   we have cut
%R - Replaced any boldface by emphasis for consistency and better look
%R - ispelled (am I the only one with ispell??)

%- section 5.3. is problematik. we do have more material on mobility
%and should use it here. the title "features" should be changed.
%R I changed ``features'' to ``options''

%- section 7 is problematic, as this is _outdated_. the work referred
%could be used in some motivating/introduction section, but this is
%definetly not the state-of the art in related projects. as related
%work, I would suggest aglets from IBM and javaspaces from sun.
%R The current selection there is better now, as it matches our stuff on loci
%R of activity

%> >c. The novel contribution of the paper should be the architecture,
%> >since the programming paradigm exploited by Jada is the one developed
%> >in Linda and just reimplemented in Java by the authors. Still, the
%> >presentation of the architecture is limited to a few pages. You should
%> >clearly identify the novel contribution of the paper.
%>
%> I can work on this. The point is to explain the advantages of the PageSpace
%> architecture. I can do that.

%what also could be mentioned here is that the pagespace architecture
%is really sort of a reference architecture. I have not seen
%architectures that show that our collection of agent-classes is too
%large, I have, however seen architectures where I can point to
%pagespace and show them that they left something out. If we keep the
%word "reference architecture" in the title, there should be some
%paragraph mentioning this. so, one of the contributions of pagespace
%is the identification of a reference architecture for distributed
%application on the web. we instantiate this arch with our second
%contribution by using coord-tech.

%R I dropped in the word reference and wrote a paragraph on that

%> >e. The paper does not clearly identified the components (or code
%> >skeletons or whatever technology) that constitute the Page Space
%> >application-independent constituents. What is given by Page Space and
%> >what is requested to a programmer as application-specific programming?

%R I wrote a paragraph and an itemization on that.

%>
%> I can do a first cut of this, to which somebody (Robert, Davide?) may want
%> to add something more specific.

%ok. as far as the laura-part is concerned, I can fill up the gaps that
%you indicate.

%R I wrote one paragraph for Laura

%R--------------------------------------------------
% FIRST REVIEWER (R1)
% I have several general concerns about the paper:
%
% a. The presentation and the English need a lot of improvement. I would
% suggest the paper be reviewed by a native English writer.
%
% b. The semantics and interoperation among the different technologies
% used in Page Space is difficult to understand. I have not understood
% how Shade works. Nor it is clear to me how it interacts with the other
% components (Jada and Laura). See detailed comments later on.
%
% c. The novel contribution of the paper should be the architecture,
% since the programming paradigm exploited by Jada is the one developed
% in Linda and just reimplemented in Java by the authors. Still, the
% presentation of the architecture is limited to a few pages. You should
% clearly identify the novel contribution of the paper.
%
% d. Section 6 is really disappointing. There is long, superficial, and
% useless discussion of financial applications. Then a concrete example
% is presented, but the authors admit that it is very simple.
%
% e. The paper does not clearly identified the components (or code
% skeletons or whatever technology) that constitute the Page Space
% application-independent constituents. What is given by Page Space and
% what is requested to a programmer as application-specific programming?
%
% Detailed comments:
%
% f. Page 4: The third alternative presented by the authors ("Activity
% located in midware") is really obscure to me. What does it mean?
% Middleware per se does not include any application semantics. It is an
% enabling technology, not part of the application. Even traditional
% client-server applications use middleware services to operate. So this
% third alternative does not make any sense when compared with the first
% two cases. Unless the authors mean something different, which I was
% not able to derive from the paper.
%
% g. Page 5: The concept of tuplespace is defined after it is used. I would
% move the description of Linda at the beginning of page 5, so that the
% discussion of its properties and characteristics ("The following
% features ...") is easier to read.
%
% h. Page 8: The section on Shade is really obscure to me. I understand
% that Jada is a set of classes that can be used in the development of
% Java programs. What are then the nature and role of Shade? Is it a set
% of classes built on top of Jada (or simply Java) to implement what? A
% monitor-like data structure? How am I supposed to exploit Jada and
% Shade? An example would be really useful to understand this. Finally,
% the discussion on atomicity in Shade is really obscure to me. What is
% atomic? How is a transaction defined and then invoked? This section
% really needs a major rewriting effort.
%
% i. Page 10: the authors define here the different agents that
% characterize the Page Space architecture. Is this just a taxonomy or
% is there some customizable software component that can be used to
% create the different kinds of agents? For instance, is your concept of
% Alpha agent just a definition, or do you have some code skeleton or
% generative technology that can be used to create the Alpha agent for a
% specific application?
%
% j. Page 11: You say that "The latter characteristic shows the potential
% of Page Space to support any of the structure ...". I assume you are
% referring to the bullet just following Figure 2. That bullet, however,
% presents standard web features. What is Page Space specific there?
% Again the third bullet on "midware mediated activity" is really
% obscure to me. Clearly, the point here is related to the definition
% given on Page 4 (see first comment).
%
% k. Page 12: What does the first paragraph on homeagents mean? Does it
% mean that the code of all Alpha agents is the same? Namely, is this
% code application-specific or general purpose? If it is not general
% purpose, what features are offered to the Alpha agent developer to
% create it?  Does he need to start from scratch?
%
% l. What technology can a programmer use to develop a Delta agent? Just
% the Jada/Shade/Laura primitives? Or do you offer some technology to
% support the development of the agent? The issue is the same: is your
% classification of agents just a classification, or is there also some
% technology or predefined agent code that implements the semantics of
% each kind of agent?
%
% m. Page 16: I have not understood what you mean by distributed
% PageSpace. I understand that the different components of Page Space
% can reside at different machines. But I guess you mean here a
% federation of Page Space instances. Is this correct? If yes, I assume
% that there must be some mechanism that assigns tuples and agents'
% names to different PageSpace's. How does this work? Not just from an
% implementation viewpoint, but also from the viewpoint of the
% programmer.
%
% n. Page 17: I am quite disappointed by Section 6. There is a long and
% generic discussion on financial applications. Then you spend a couple
% of pages to describe an example than, in your own words, is very
% simple. I would drop the initial discussion and provide a richer and
% more significant example.
%
% o. Page 25: The conclusions are quite shallow. This might partially
% depend on the lack of clear focus of the paper. If the architecture is
% the core, than try to summarize why your approach is novel and useful.
%
%
%
%-----------------------------------------------------------------------------
% SECOND REVIEWER (R2)
%
% A. Contribution and focus - The paper contribution is not clear - the
% focus needs sharpening. What is the paper trying to achieve?
%
% B. It would be much more convincing if other environments, preferably
% widely used ones like PVM (Parallel Virtual Machine), were criticized
% showing what they lack and why Linda or Linda-like should be preferred
% over them.  For example in terms of coordination, loose coupling,
% concurrency and separation of concerns.
%
% C. Why can't CORBA, or Java itself, be used to achieve the very same
% objective? If there is an added value to having Linda/Jada/... to
% Linda it should be shown clearly. this is also not explained in the
% Related Approaches section.
%
% D. Where do we define the structure of an application? How can it be
% changed? when running? communication primitive s supported?

% E. Fault tolerance and mobility -are "features" which are not really
% explained or justified (p. 16-17) Foe example, how do agents detect
% when to move, where to?...can they be moved at any time?
%
% F. Terms - The paper goes into great detail about Linda and Jada. There
% are too many other terms like Laura,, forms, signature, STL,
%R I removed STL
% Shade,..., many of which are not really introduced
%
% G. Literature - Does not adequately cover literature. A too big portion
% is related to Linda. A much wider coverage of work done in this field
% other than Linda (there is a lot) is needed.
%
% H. Figures - Many of the figures need to be clarified as they don't
% add much (e.g. Figs 2, 4, 5,
%R I removed some of them.

%
%
% More specific questions:
%
% I. What is meant by "associative" (p.6)
% J. Laura - why do we need another name for connecting a request
% to a response (p.7)?
% K. Rule-based coordination - not clear (p.9)
% L. Why do we need so many types of agents (p.10)?
% M. The auction example detailed in Section 6: what is the
% advantage of Linda here?
%
%
%
%
%-----------------------------------------------------------------------------
% THIRD REVIEWER (R3)
%
% A. The work behind this paper may be worth reporting, but the paper as it
% stands is not good enough for publication. It is poorly structured and
% does not truly present what the title announces, a reference
% architecture. Various ideas are loosely presented and not sufficiently
% justified in architectural terms, there is no clear separation between
% conceptual and implementation levels, and although several related
% approaches are mentioned there is no effort to put the proposed system
% in perspective and compare strong and weak points. An effort is needed
% to present a more coherent picture of what the PageSpace architecture
% really is, possibly via a more top-down discussion of architectural
% issues of spaces, agents, coordination, distribution, etc.
%
% B. Section 2 advocates the middleware approach (is this the standard
% notion of middleware?) to mediation among applications. But what is
% this middleware? In the ensuing discussion of coordination and tuple
% spaces, one is led to believe that a tuple space is at the middleware
% level, but in section 3.2 we learn that it is really a resource
% available through a server in some host. So, after all, it does not
% provide for a coordination medium that abstracts away from
% distribution as the middleware picture suggests but is more akin to
% the classic client/server approach.  This needs to be clarified,
% specially because later in section 5.2 there is a reference to
% distributed implementations of Linda.
%
% C. Section 3 looks like a collage of brief descriptions of Jada, Laura
% and Shade. This should be better motivated and integrated. Is Laura
% totally independent from Shade, both in conceptual and implementation
% terms? Is Jada just the implementation layer for Laura/Shade
% abstractions, or is Jada directly available in PageSpace? (i.e. are
% services and rules THE coordination abstractions of PageSpace?)  [C1] In
% 3.3, 3rd paragraph, "no names are used" is misleading as names are
% part of a signature.  [C2] Subsection 3.4 is called "distributed
% transactions" but the transactional phase of a rule application is
% just local. [C3] In the last paragraph "object" and "name" should be the
% same? [C4] In 3.5 "the tuplespace...is replaced with..."; shouldn't it be
% "the tuplespace...is..." ?  [C5] The qualifier "declarative" for rules
% should be dropped (no high-level abstraction power in rules).
%
% D. Section 4 should give a clear picture of an architecture but it does
% not. A striking fact is that coordination (the previous topic) is
% almost absent here, only casually mentioned. Shouldn't it be a central
% feature of the architectural design? [D1] Another worry is that conceptual
% and implementation levels are not clearly separated. Epsilon and Zeta
% agents are clearly an implementation necessity, so they shouldn't
% belong in the architectural level depicting the abstract functional
% structure of an application, where I think the other types of agents
% belong. (A Zeta, from the description, may be a particular
% implementation of a Delta.) [D2] In the description of Deltas, these may
% provide a user interface, but then are these not Alphas? [D3] "a Zeta
% provides access to a CORBA based coordination environment" - is this
% THE coordination environment in PageSpace? Is this how remote access
% in Jada works?  [D4] In describing "Midware mediated activity" one reads
% about "the coordination operations provided by PageSpace"; it is not
% clear from the paper exactly what these operations are, and this
% should be a crucial point! I.e. what types of interactions with Delta
% agents are possible? [D5] There are a lot of references to messages, and it
% is not clear how these messages relate to the Shade/Laura/Jada
% coordination features. [D6] In 4.2, pragraph before last, "it is easy to
% enforce a certain functionality of Deltas and to provide a default
% behaviour". Is there any concrete idea on this default funcionality?
% This should be important for understanding the architecture.
%
% E. The last paragraphs of 5.1 discuss names as URLs, but this is not very
% clear. Do these URLs have the "http:" tag? What does one get by
% accessing that URL? Is there a Web server inside Epsilon?
%
% F. In section 5.2 a hierarchy is mentioned, but it is not clear whether
% it is just an implementation issue or conceptually important for the
% PageSpace architecture.
%
% G. In the Introduction it is said that "electronic commerce should serve
% as a benchmark" and "Section 6 summarizes the requirements and
% describes a case study". This would be nice but is not quite true. The
% first part of section 6 discusses the structure of financial
% institutions rather than the problems posed by electronic commerce. It
% is said that "PageSpace technologies can be applied to develop
% solutions for several needs..." but it is hard to see why specifically
% PageSpace is good for the very generic needs which are listed. "The
% real problem...is that...mainframe-centric...is not adequate..."; this
% is not a very serious diagnosis of real problems. In the auction
% example, the figures are worthless, it would be better to describe
% what agents there are and how their behaviour described by the 3
% phases is achieved with coordination actions. Was this system designed
% from a real demand?
%
% H. Section 7 contains a good number of references to related work, but
% there should definitely be more critical comment on how they differ,
% overlap or complement the PageSpace model.
%
%
%-----------------------------------------------------------------------------
% FOURTH REVIEWER (R4)
%
% SUMMARY
%
% This paper describes an architecture called PageSpace for multiagent
% collaboration on the World Wide Web.  The architecture relies on
% existing Web technologies such as Java, HTTP and HTML, and it provides
% a Linda-like coordination facility to support various styles of agent
% collaboration.  I feel that the technology presented in the paper
% should be of interest to readers of a journal issue on mobility, even
% though the paper itself has little to say about mobility.  Therefore,
% I recommend acceptance of the paper subject to the authors addressing
% the comments below.
%
% DETAILED COMMENTS
%
% A. The introductory material in Sections 1 and 2 is quite nice--it
% defines the problem and tells why existing mainstream Web technologies
% alone are insufficient to solve the stated problem.  [A1] But then in
% Section 3 the paper dives into a lot of detail without establishing
% any high-level framework to explain the significant ideas.  The reader
% is left trying to relate all the pieces of information into a coherent
% mental picture.  This could have been rectified to some extent in
% [A2] Section 7 where related approaches are discussed, but there the
% authors need to make detailed comparisons between PageSpace and its
% competitors, to explain the contributions that PageSpace makes, and to
% enumerate its advantages and disadvantages over the other technologies
% that are discussed.
%
% B. Paradoxically, the auctioneer example discussed in Section 6 is
% presented at too high a level for the reader to glean any technical
% insights.  For instance, it would have been very nice to see some
% examples of the rules that were used to specify the agents, and it
% would have been helpful to see some detail about the effort involved
% in constructing such an application (e.g., lines of code).
%
% C. In Section 3 I had a few concerns about some details that were glossed
% over.  [C1] On p. 6, the Java interface for the Linda-like coordination
% primitives is described, but it is not clear how unbound placeholder
% variables are specified in a "read" or "in" operation (i.e., variables
% like ?b and ?int on p. 5).  The allowance for multiple tuple spaces
% now makes application-building more complex.  [C2] Applications have to
% somehow agree on which tuple space to communicate through (either by
% having this information hard-coded into the programs or else
% negotiating it at runtime).  The need for multiple tuple spaces needs
% to be explained, since the associative address scheme can be used to
% support "virtual" spaces within a single physical space.  If it is for
% reasons of distribution efficiency, presumably a single tuple space
% could be ph ysically distributed, with the distribution details hidden
% from the programmer.  In addition, the need to locate and establish
% connections with a service makes application-building more complex.
%
% D. On p. 7, more information is needed about the type system and the
% subtyping rules.  It's not completely clear exactly what the semantic
% model is.  Is it subtyping over operation argument and result types
% plus operation name matching?  Since the subtyping is done over sets
% of operation interfaces, how do you avoid the
% covariance/contravariance problem?  How strict are the rules regarding
% the number, name and order of operation declarations?  A service
% requestor requests a single operation, yet the subtype matching is on
% whole interfaces, so how flexible are the matching rules to focus on
% the ultimate need of the requestor?
%
% E. On p. 8, the reader will naturally ask how long messages persist in
% Shade.  Is it forever?  Where are the messages physically stored?
%
% ----------------------------------------------
%
% R1-A: Verify english
%
% Fabio
% R2-A: Better Focus
% The paper has changed focus somewhat. My point was to find the
% greatest common denominator of the german and italian side of
% PageSpace. The solution I came up with was to stress the
% PageSpace as a reference architecture for the common goal of
% doing coordination over the WWW. This was the only way we could
% explain why we had two different coordination languages;, Laura
% and Jada, and several disjoint and non-cooperating prototypes and
% applications. Thus the paper re-focused itself: after an
% introduction, we first discuss the base technology and paradigms
% we were working with. Laura and Jada, being specific
% implementations of them, were put in a later section. Then the
% reference architecture is explained, carefully showing that these
% are not, except in some cases, actual classes and modules, but a
% general descriptive role of the modules we were actually working
% on. Then implementations of the PageSpace concepts were meant to
% be included, as well as the discussions about Laura and Jada.
% Shade was considered too technical and specific to be worth more
% than a mention in the auction example, and thus its section was
% removed. Finally, as suggested, the blurb about the e-commerce
% was removed, and only the example was kept. The change from
% actual arcgitecture to reference architecture also meant the
% demotion of the discussion about epsilon and gamma to the
% implementation section, as one example of a real implementation
% of the PageSpace ideas, rather than THE implementation of the
% espilon agents. This of course can be discussed, and needs the
% relevant sections to be rewritten, but it seems more consistent
% now. At least to me.
%
% R3-A: Better structure
% The paper has been re-structured:
%    Sections 2, 3.1 and 3.5 (part) have been joined in one
%    Part of 3.5 has been put in the trash
%    Section 3.2 e 3.3 moved in Implementations
%    Section 3.4 put in trash
%    Section 6, first part put in trash
%               second part in Implementations


%R switched to the final layout for IEEE transactions
%R There might be more to be done for the CRC...

\hyphenation{Page-Space tuple-space}
\newcommand{\Out}{{\tt out} }
\newcommand{\In}{{\tt in} }
\newcommand{\Read}{{\tt read} }
\newcommand{\Innb}{{\tt in\_nb} }
\newcommand{\Readnb}{{\tt read\_nb} }
\def\todo#1{\textsl{\textbf{\large#1}}}


\documentclass[twocolumn,twoside]{IEEEtran}
\usepackage{epsfig,pathsl,path,xspace,subfigure,comment}%,ieeec}%,enhbib}


\begin{document}
\author{Paolo Ciancarini,\thanks{%
Paolo Ciancarini, Fabio Vitali and Davide Rossi are with the
Dept.\ of Computer Science,
Univ.\ of Bologna,
Via Mura A.\ Zamboni, 7,
I-40127 Bologna, Italy.
\textsl{mailto:\{cianca$|$vitali$|$rossi\}@cs.unibo.it}
\textsl{http://www.cs.unibo.it/\{\char126cianca$|$\char126rossi\}}}
%R \and
Robert Tolksdorf,\thanks{%
Robert Tolksdorf and Andreas Knoche are with the
Tech\-nische Universit\"at Berlin,
Fachbereich 13, Informatik,
FLP/KIT, FR 6--10,
Franklinstr.\ 28/29,
D-10587 Berlin, Germany.
\textsl{mailto:\{tolk$|$knoche\}@cs.tu-berlin.de}
\textsl{http://www.cs.tu-berlin.de/\char126tolk/}}
%R \and
Fabio Vitali,
%R \and
Davide Rossi,
%R \and
Andreas Knoche
}

\title{Coordinating Multiagent Applications on the WWW: A Reference
  Architecture}

\noindent
\textbf{Title:}\\
%R different
Coordinating Multiagent Applications on the WWW:\\
A Reference Architecture

\bigskip\noindent
\textbf{Authors:}\\
\noindent
Paolo Ciancarini\\
Dept.\ of Computer Science,\\ Univ.\ of Bologna,\\
Via Mura A.\ Zamboni, 7,\\
I-40127 Bologna, Italy.\\\textsl{mailto:cianca@cs.unibo.it}\\

\noindent
Robert Tolksdorf\\
Technische Universit\"at Berlin, \\Fachbereich 13, Informatik,\\
FLP/KIT, FR 6--10,\\Franklinstr.\ 28/29,\\
D-10587 Berlin, Germany. \\\textsl{mailto:tolk@cs.tu-berlin.de}\\
Tel: +49-30-314-25184\\FAX: +49-30-314-73622\\

\noindent
Fabio Vitali\\
Dept.\ of Computer Science,\\Univ.\ of Bologna,\\
Via Mura A.\ Zamboni, 7,\\%Pza.\ di Porta S.\ Donato, 5,\\
I-40127 Bologna, Italy.\\\textsl{mailto:vitali@cs.unibo.it}\\

\noindent
Davide Rossi\\
Dept.\ of Computer Science,\\Univ.\ of Bologna,\\
Via Mura A.\ Zamboni, 7,\\%Pza.\ di Porta S.\ Donato, 5,\\
I-40127 Bologna, Italy.\\\textsl{mailto:rossi@cs.unibo.it}\\

\noindent
Andreas Knoche\\
Technische Universit\"at Berlin, \\Fachbereich 13, Informatik,\\
FLP/KIT, FR 6--10,\\Franklinstr.\ 28/29,\\
D-10587 Berlin, Germany. \\\textsl{mailto:knoche@cs.tu-berlin.de}

\bigskip\noindent\textbf{Keywords:}\\
Java, Linda, Coordination, Internet, Web Applications,\\
Open Distributed Systems

\thispagestyle{empty}\setcounter{page}{0}\clearpage

\maketitle

\begin{abstract}
  The original Web did not support multiuser, interactive
  applications.  
  This shortcoming is being studied, 
  and several approaches have been proposed to use the Web as a
  platform for programming Internet applications.
  However, most existing approaches are oriented to centralized applications
  at servers, or local programs within clients. To overcome this deficit, we
  introduce PageSpace, that is a reference architecture 
  for designing interactive multiagent applications.
  In this paper we describe how we
  control agents in PageSpace, using
  variants of the coordination language Linda
  to guide their interactiond. 
  Coordination technology is integrated with the
  standard Web technology and the programming language Java.

  Several kinds of agents live in the PageSpace: User interface agents,
  personal homeagents, agents that implement applications, 
  and agents which interoperate with legacy systems.
  Within our architecture it is possible to support
  fault-tolerance and mobile agents as well.
\end{abstract}

\begin{keywords}
  Distributed programming systems, Java, Linda, Coordination, Internet, Web Applications.
\end{keywords}

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

\PARstart{T}{he Web} has evolved into 
the dominating software architecture for information
systems on the Internet. 
There is increasing demand to use it as a platform
for programming distributed applications 
in which processing of information occurs. 
For instance, the application domains 
of project and workflow management \cite{Ly97}
and electronic commerce \cite{APP97} include
classes of applications that require distributed access and processing due
to the distributed nature of the work these applications support. 

Currently there is no widely accepted reference architecture 
for implementing interactive distributed applications on
top of the Web.
Web browsers supporting 
Internet programming languages such as Java
allow activity at user interface level 
in the form of {\it applets}.
However, languages like Java need integrated middleware
(eg.\ CORBA) to coordinate
activities tied to multiple, distributed clients \cite{EvaRog97}.
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.
In fact, providers of Java technology
are developing middleware in the form of Java libraries
called Java RMI (Remote Methods Invocation),
to interface (new) remote applications written in Java as well,
and JavaIDL (Interface Description Language),
to interface via CORBA legacy applications
written with other languages.

We have developed an original
solution to this problem. In fact,
the PageSpace \cite{CKTV96} is
a reference architeture 
to support distributed applications on the WWW.
It is based on the core Web technology for access
and presentation, on Java as the execution mechanism, and on 
{\em coordination technology} \cite{Cia96c}
to manage the interaction of agents in a distributed application.
This paper describes the rationale of PageSpace, its design, and the
implementation strategies currently applied.

Currently, the field of electronic commerce is of particular interest for the
application of platforms like PageSpace. In fact, electronic commerce should
serve as a benchmark for the validation of our approach wrt.\ applications
requirements. Section \ref{sec:app-ec}
describes a case study.

This paper is organized as follows.  
In section \ref{sec:exappr} we review the main approaches to implement
applications that require active processing on the Web.  
In section~\ref{sec:coordps} we then describe our
specific approach to coordination of distributed applications.
Section~\ref{sec:psagents} describes the PageSpace and the various
kinds of agents it includes.  
Then, in section~\ref{sec:psimp} we outline our approach in
engineering and implementing PageSpace
and describe a case study.
Finally, section~\ref{sec:related} 
we compare our approach to a number of alternative
solutions introduced to design interactive multiagent WWW applications.

\section{Programming the Web}

Since 1993 the Web as the dominating Internet service has evolved into the
most popular and widespread platform for world wide accessible information
systems.  
The software for accessing and offering information on the Web is
available in the public domain 
for all hardware and operating system platforms in use.


\subsection{Existing Approaches for Programming the Web}
\label{sec:exappr}

At its core, the Web is a static hypertext graph in which documents
marked up in HTML are offered by servers, retrieved by clients
with the HTTP protocol, and displayed by graphical interface that is very
easy to use. Because of its diffusion, it is
desirable to use the Web as a platform 
for dynamic, distributed applications.
The support offfered by
the core Web platform for applications is very rudimentary --
only the CGI mechanism allows for processing of information that is entered by
the user in forms, or retrieved from auxiliary systems, such as database
servers.

Several mechanisms have been proposed 
in order to make the Web a more effective platform 
for multiuser distributed applications. 
The following classification is
structured according to the loci of activity 
where these mechanisms act.

\begin{itemize}
\item \emph{Activity located at Web servers}.

  The CGI mechanism can be used to access other application servers from the
  Web. A typical example is database access, where some form allows the
  formulation of a query in a browser and a CGI script at the server passes
  that query -- probably in a translated form -- to some database server. The
  results of the query then are converted to HTML and sent back to the users
  browser.  Fig.~\ref{fig:servact} shows the structure of such a distribution
  of activity.

  \begin{figure}[htbp]
    \begin{center}
      \leavevmode
      \subfigure[Application at one Web server]{
      \epsfig{file=servact.eps}\label{fig:servact}}
      \subfigure[Activity at Web clients]{%
      \epsfig{file=clienact.eps,width=\columnwidth}\label{fig:clienact}}
      \subfigure[Activity within middleware]{%
      \epsfig{file=midact.eps,width=\columnwidth}\label{fig:midact}}
    \caption{Activity in Web applications}
    \end{center}
  \end{figure}

  This approach
  turns out to have nothing in common with distributed paradigms like
  client-server interaction.
  In fact, interfacing an application via CGI to the Web does not mean to
  offer a distributed application. There is no processing at the client
  besides displaying results. Moreover, there is only one central location of
  activity -- the server. 
  Thus, such an application is basically a mainframe/terminal system
  on the Internet. 
  The Web server is comparable to a mainframe -- the
  only location of processing.  
  The Web browsers are nothing but graphical, easy-to-use
  terminals, interpreting HTML as the display language.

\item \emph{Activity located at Web clients}.

  When a Java applet is executed within the browser, 
  again it usually performs no
  distributed application. 
  The applet is just a program that is run locally on
  the user's machine. There is no generally accepted way to connect 
  applets running on different machines;
  the remote method invocation 
 (RMI) mechanisms lead to security problems that are
  not solved yet.  Some applets
  and plug-ins -- such as RealAudio players -- connect to other proprietary
  servers and thereby abandon core Web technology.

  Fig.~\ref{fig:clienact} shows this structure of activity focused on
  clients, which contains no generally accepted framework for distributed
  applications on the Web.

\item \emph{Activity located in middleware}.

  A third approach to distributed applications on the Web is to use middleware
  to connect the active parts in an application, which can be located in
  clients and/or servers. Here, the Web technology takes the r\^ole of
  providing a uniform access and presentation mechanisms.
  Fig.~\ref{fig:midact} depicts that structure.
  The paper \cite{Adl95a} discusses
  which kind of coordination interactions
  need modern distributed applications.
  These include direct/indirect service requests, 
  explicit/implicit invocations of multiple servers,
  blocking/nonblocking primitives for receiving responses.
\end{itemize}

Implementing this approach requires language
mechanisms like Remote Procedure Calls
or Message Passing, which typically provide an Application Programming
Interface for posting messages and retrieve responses.
The approach we follow instead consists of using 
a coordination language.
The key concept is the use of 
Linda-like coordination to manage the interaction
among agents. This is the topic of the next section.

\subsection{Coordination Technology for the Web}
\label{sec:coordps}

  % R2-B: There are other paradigms besides coordination. Es. PVM
  % R3-C: Too many details. We want a coordinated explanation
  % R4-A1: Too many details, there is no framework

The PageSpace software architecture
(\cite{CKTV96}) is based on the notion of agents that
use coordination technology for their interactions.  We use the term
\emph{agent} reflecting that processing is performed in such an entity.  Each
user has a \emph{homeagent} that provides the interface to the PageSpace and
its agents.
%R exchanged sentences
Applications are composed by a set of distributed agents therein.  We rely on
Java as the implementation language for our agents.  The main focus of
PageSpace is the issue of coordination amongst these distributed, concurrent
agents.  We explored the use of Linda-like coordination technology to solve
that coordination problem.

Three issues are important in a distributed, concurrent application: How do
agents synchronize their work, how do they communicate, how are their
activities started?  Amongst the various approaches to solve these
coordination problems, there is a specific line of research called
\emph{coordination technology} that is based on the concepts introduced by the
language Linda \cite{CarGel89a}.

  % R1-G: Explain Linda before its advantages
  % F: Moved part on Linda

Linda provides an abstraction for programming concurrent agents and
defines a very small set of coordination operations.
%R In a program based on Linda,
In a Linda based system, an ensemble of agents work on a task within a shared
environment, called the \emph{tuplespace}.  A tuplespace contains tuples,
which are structured containers of information relevant for the application.
Many variants of tuplespaces, like distributed, or hierarchically structured
ones, have been studied over the last fifteen years.

Linda's primitives provide means for agents to manipulate that shared
tuplespace, thereby introducing coordination operations.  A tuple can be
emitted to the tuplespace by an agent performing the \texttt{out}-primitive.
As an example, \pathsl|out("amount",10,a)| emits a tuple with three fields,
that contain a string, an integer, and the contents of the program variable
\texttt{a}.  This operation is non-blocking.

Two blocking primitives are provided to retrieve data from the tuplespace:
\texttt{in} and \texttt{rd}. Both take a \emph{template} as argument -- for
example \pathsl|in("amount",?int,?b)|.

A \emph{matching rule} defined in Linda governs the selection of a
tuple from the tuplespace: The template and the tuple must have the
same length, the types of the fields must be the same, and the values
of constant fields (called \emph{actuals}) have to be identical.

The example template retrieves a tuple that contains the string
\texttt{amount}
as the first field, followed by an integer, followed by a value of the same
type as the program variable \texttt{b}.  The notation \texttt{?b} indicates
that the retrieved value is to be bound to the variable \texttt{b} after
retrieval.

The difference between \texttt{in} and \texttt{rd} is that the former removes
the matching tuple, while \texttt{rd} leaves it untouched in the tuplespace.
Both operations are blocking -- while there is no matching tuple found in
the tuplespace, they do not return.  Linda makes no further guarantees on the
selection of matching tuples and waiting operations.

It has been demonstrated \cite{CarGel89b} that Linda is capable to
express all major styles of coordination in parallel programs.
\texttt{in} is a very powerful operation -- it combines
synchronization (the operation blocks until a matching tuple it found)
with communication (the binding of values to program variables).

All together, Linda's operations form a so-called 
\emph{coordination language} \cite{CarGel92a},
which, when combined with a sequential
programming language, generates a new language for concurrent systems.
Such a combination is called \emph{embedding} and can be implemented
by changes to the sequential programming language syntax and runtime
\cite{ACGK88}, by preprocessing source code \cite{CarGel90a}, by
libraries \cite{Paradise}, or can be provided as an extended operating
system \cite{Lel90}.

Linda-like coordination is attractive for programming distributed
applications on the Web because it allows for several unique characteristics
not found in other similar technologies, such as Parallel Virtual
Machines (PVM \cite{GeiSun92}):

\begin{itemize}
\item \emph{Uncoupling of agents}.

  PVM is based on message passing, that means that
  agents must know each other to communicate.
  Instead, a tuplespace uncouples the coordinating agents
  in space and time. An agent can perform an \texttt{out} even when a
  ``destination'' agent does not yet exist, and can terminate before the
  \texttt{out}-ed tuple is retrieved. The tuplespace 
  abstracts away from locality issues.

\item \emph{Associative addressing}.

  PVM agents use direct naming. In a Linda program,
  the template used to retrieve a tuple specifies what kind of tuple is
  sought, rather than how to find such a tuple.  
  This addressing is more abstract and declarative than
  specifying a given message from/for a given correspondent.

\item \emph{Separation of concerns}.

  A coordination model like Linda
  focuses on the issue of coordination only: 
  a derived coordination language ideally
  is not influenced by features specific of a host programming
  language.
  Interestingly, PVM can be used to implement
  Linda-like coordination (a project named Glenda did
  exactly this), however at a high price, in terms of
  syntactic complexity and lack of semantic optimization.
\end{itemize}

Linda-like coordination is available for a number of
different programming languages and hardware architectures.
All implementations usually offer an abstraction of shared
tuple space and primitives based on associative addressing.
We consider and use here Jada and Laura, 
two specific Linda-like coordination packages 
that are described in section \ref{sec:psimp}.

% This comes from section 3.5

%R The figure _has_ to be redone. It tell close to nothing. The figure is a
%R completly abstract collection of geometric forms. How should a reader find
%R out the intuition behind ovals, circles, rectangles? And, the figure adds
%R in no way to the text.
%R I took the figure out, if it is redone, it might be reintroduced.

Coordination can be added to WWW 
in at least three different ways
as illustrated in Fig. \ref{fig:original}.

  \begin{figure}[htb]
    \begin{center}
      \leavevmode \epsfig{file=lindawww.eps,width=.7\columnwidth}
      \caption{Three ways to enhance the WWW with Linda-like
        coordination. Top: client-side coordination. Middle: server
        side coordination. Bottom: application-wide coordination.}
      \label{fig:original}
    \end{center}
  \end{figure}

Such a picture illustrates three different ways
of using Linda-like coordination to enhance the current WWW
softeare architecture. It shows that
the introduction of a tuplespace 
can be useful at all the three layers
of a WWW-based distributed application:

\begin{itemize}
\item \emph{Client-layer}.

  Several clients (or several applets in a client)
  can coordinate themselves through a shared tuplespace.  
  It is not difficult to coordinate (eg. synchronize)
  browsers running on different machines or devices. 
  Alternatively, the browser itself 
  can be composed of several independent modules that are
  coordinated through a shared tuplespace.

  For instance, the WWWinda approach is based on a modular browser
  The WWWinda approach demonstrates this with a design for a modular browser
  \cite{GNSP94}.
  To facilitate a tighter integration of browsers and their helper
  applications, the WWWinda research team designed a flexible, modular browser
  architecture based on the Linda coordination model. 
  It is composed of several independent tools, 
  each implementing a different part of the Web
  browser or a helper application.
  This allows for a highly modular architecture, where new
  components can be added without modifications to the others.
  The collaboration among components is implemented with Linda coordination
  technology: all modules make use of a ``software bus''
  that is a shared tuple space. 
  Current examples include a
  musical orchestration system (called ``distributed karaoke''), in which
  several independent instruments (possibly even running on different
  machines) extract from the shared tuplespace the tune to be played note by
  note.  No instrument is aware of how many other instruments are present, and
  new ones can be added on the fly, even in the middle of a note.

\item \emph{Server-layer}.

  Different components of a server-side application (or several
  different applications) can 
  coordinate and communicate through a tuplespace.
  In this case the HTTP protocol acts as the interface to the
  modules seen as a whole
  and is the default access mechanism used to manage the components of
  the application via a CGI interface.  The tuplespace may be used as a
  connection mechanism for applications running on different machines.

  An obvious application consists of distributing the load among several
  HTTP servers.
The WU Linda Toolkit \cite{Sch95a} is 
an example of such an interface to a Linda tuplespace
implementation using a WWW browser and an HTTP server.
Users can fill out HTML forms with Linda commands that are executed at a
shared tuplespace at the server.  
The main application on show is a disc-load
viewer that allows a first glance check of current disk usage of the computers
of a cluster.  Each computer posts tuples describing its current load.  These
tuples are then collected and sent to the browser in a graphical HTML display.


\item \emph{Application-layer}.

Client/server reference architectures define how an application
obtains a service from another. In several situations
such architectures put strong constraints on 
designers, who actually need extended model architectures
able to coordinate multiple, independent programs to 
provide complex services to components which sometimes
play the role of clients and sometimes
play the role of servers \cite{Adl95a}.

Coordination architectures \cite{Cia96c} are useful to design 
this kind of applications, because they
offer a way to handle coherently and uniformly diverse design issues,
like locating resources,
supporting interprogram communication, and
coordinating the distributed execution.

This paper presents PageSpace, which is an example
of a multiagent reference architecture
useful to design distributed multiuser WWW applications.
In Sect. we will present and compare 
PageSpace with other architectures proposed to 
build distributed WWW applications.

\end{itemize}

\section{The PageSpace Architecture}
% Fabio re-writes. Paolo, Robert, Davide, re-check and correct
% R1-C: limited presentation of the architecture
% R1-E: PS components are not clearly identified.
% R2-I: What are agents? Taxonomy or code? Explain
%R I added a paragraph on agents as ascription here
% R2-D: give more details about the creation of new applications
% R2-L: why so many kinds of agents?
%R I added a paragraph about that the set of agents is generic and
%R representative for lots of architectures
% R3-D: We are not talking about coordination here, and we don't
%       separate implementation  and architecture.
% R3-D5: messages are unclear.

\label{sec:psagents}

PageSpace is a reference software architecture 
for coordinating applications such that:

\begin{itemize}

\item Applications can be seen as the combination of several independent
  {\it agents} whose interaction defines the application behavior.
  
\item The applications can serve several users independently accessing the
  shared environment.  The users are using the 
  current generation HTML browsers.

\item The applications can be transparently distributed across several
  computers or centralized on a single host.  The actual settings of each
  shared workspace should have no influence on the implementation of the
  applications.

\item Several independent applications
  that run independently can interact.  
  Coordination and communication may happen not just
  among different modules of a single, complex application, but may arise
  naturally from independent applications dealing with the same types of
  information.

\item The configuration of users, applications, and hosts 
  can change and evolve dynamically with none or minimal disruption of
  the services of the shared environment.  In particular, users are supposed
  to log in the system using standard HTML browsers on possibly unreliable
  and/or non-persistent connections.  A user therefore may need or want to
  change the page currently displayed in the browser, may be subject to
  network interruptions, or may opt to close a dial-up connection during the
  run-time of the application, and log back in some time later. These
  situations should not interrupt the regular functioning of the environment
  and of the applications, and should gracefully allow the disappearance and
  re-appearance of the users.

\end{itemize}

In the PageSpace reference architecture, therefore, we distinguish several
kinds of \emph{agents}:

\begin{itemize}
\item \emph{User interface agents} %R, or {\it alpha agents},
  are the interfaces of applications.  They are manifested as a display in the
  users browser and are delivered to the client by the other agents of the
  application according to the requests of the user.  Depending on the
  complexity of the application and the capabilities of the user's browser,
  there may be different instantiations of user interface agents (in HTML,
  JavaScript, Java, etc.)  that are displayed or executed on the browser.
  User interface agents are displayed within a general interface framework
  that provides support for the stable interface elements
%R (i.e., those that do
%R  not depend on the actual application that is being
  to manage the interaction with the homeagent.

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

\item \emph{The coordination architecture}
%R(also called \emph{gamma})
  is not an agent: it is the operating environment, 
  a shared workspace, where the
  agents live and communicate.  
  Different coordination architectures may provide different
  capabilities and, ultimately, a different paradigm for creating the agents
  of the application.  In section \ref{sec:psimp} we will mention two
  different coordination architectures we are using, Jada and Laura.

\item \emph{Application agents} %R, or {\it 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 on the coordination architecture, 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 human in any way,
  and therefore will have no need for a user interface.  They will just use
  and offer services to other agents.  Some other application agents, on the
  other hand, will have to be controlled and monitored by a human.  In this
  case, they will provide on request the user interface agent, in the form of
  an HTML document, a Java applet, etc., which will be delivered to the
  requesting user as a normal message and will be displayed or executed on the
  user's machine.

% RS-D1: Zeta and epsilon are only an implementation necessity.
% Fabio: I hope I have explained why they are similarly needed
% as the other agents.

\item \emph{Gateway agents} %R, or {\it zeta agents},
  provide access to the external world for PageSpace applications.
  Applications needing to access other coordination environments, 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.

\item \emph{Kernel agents} %R, or {\it epsilon agents},
  provide sensible 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 movement 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.

\end{itemize}

We call ``agents'' the entities present in the PageSpace architecture
since they are more than pure objects: the application agents are
autonomous and can be active, homeagents work on behalf of the user,
etc.

%F The following statements are extremely strong and are not
%F justified in the text (nor I think they can be).
\begin{comment}
%R new
The selected set of agents can be considered a reference architecture,
since practically all components of current approaches for distributed
applications on the Web can be mapped onto this specific set of
agents.
We also consider this set as complete: We have not come across another
architecture which introduces fundamentally new kinds of agents than the ones
presented here.
\end{comment}

%F New, to provide an alternative with the previous deleted sentence
The selected set of agents can be considered a reference architecture
since they provide a definite set of components and interactions
among them that correspond naturally with the set of requirements seen
previously \cite{ShaGar96}.

% R3-D3: the reference to Zeta and Corba is not clear.
% Fabio: I hope I have explained.

In fig.~\ref{fig:pagespace} we summarize the PageSpace architecture. 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, a CORBA-based
interoperability environment, or some legacy application,
like a spreadsheet, or e-mail and news.

The PageSpace environment is maintained by a set of kernel agents on different
nodes. Note that application and gateway agents are location independent, the
user interface agent is located at the user's machine, the homeagent is at
some fixed location, and kernels are present on each participating machine.

  \begin{figure*}[htb]
    \begin{center}
      \leavevmode
      \epsfig{file=pagespace.eps,width=.7\textwidth}
      \caption{An application in  PageSpace}
      \label{fig:pagespace}
    \end{center}
  \end{figure*}

In the following, we describe these agents in more detail.

\subsection{User Interfaces and Homeagents}
\label{sec:appint}

The PageSpace and its applications are accessible to the user from any Web
browser.  This browser may usually be located on a different machine than the
actual agents performing the applications.  The user activities are not tied
to the applications running on the PageSpace.  For instance, he/she can
display other pages, activate other applications, even disconnect him/herself
from the network for some time.  Also, the user can move from one browser and
machine to others during the lifetime of the applications.

Access to the applications of the PageSpace is performed through the user
interface agents. User interface agents are delivered by the application
agents whenever the user requests to interact with the application.  The
interface, in the form of a plain HTML document or a Java applet embedded in
an HTML document, is delivered to the user's browser through the homeagent.

Given the unpredictable behavior of the user activities, the
unpredictable availability of the user's machine, and the
unpredictable type of connection that has been established between the
user's machine and the rest of the PageSpace, user agents can not be
considered fully participants to the shared workspace.

In the simplest situation, the user interface agent is an HTML
document (eg.\ a form) delivering messages through an HTTP connection to
the homeagent, which in turn delivers them to the appropriate application
agents of the running computations, and returns back the relevant responses.

More sophisticated user agents are interactive Java applets that may even
establish a proper connection to the closest machine hosting an instance of
PageSpace.  In this case the local computer establishes a local instance of
the PageSpace where application agents can perform useful computations.  These
agents will nonetheless be required to gracefully degrade their participation
in the PageSpace according to the user's behavior (e.g.\ when the user leaves
the current HTML page), and to the state of the connection.  Furthermore, the
user may request the current display to be interrupted and re-instated on a
different browser on a different machine.

These reasons imply that as little local state as possible is stored on the
user agent, and that it is possible to suspend a running user agent and
restore it anew at any moment, with no harm to the running applications.

These characteristics show the potential of PageSpace to support any
of the structures for applications on the Web as outlined in
section~\ref{sec:exappr}:

% R1-J: the following itemization is not clear. Ref. also R1-F on page 4.
% R3-D4: it is not clear why the delta provides the interface
% R1-K: what is a user agent and what should the programmer do?
% Fabio: I have tried to explain the alpha again, and hopefully
% this is now clearer. You tell me if you don't agree.
%R I do not really agree, see comments below.

\begin{itemize}
\item \emph{Server located activity} is trivially supported by having
  all the application agents running on a remote host, and interacting
  with the user through the homeagent and a plain HTML page as the interface.

\item \emph{Client located activity} is obtained by 
  activating from a client a local (ie.\ in the same host)
  instance of the PageSpace where
  application agents can be transferred and run.  Communication between the
  local application agents and their interfaces is therefore faster and more
  direct.

\item \emph{Middleware mediated activity} is obtained distributing
  several independent application agents somewhere on a LAN.
  They cooperate and communicate with users' clients 
  (on different hosts as well) through their homeagents.

\end{itemize}

A homeagent is a persistent representation of the user in the
PageSpace.  
From the active interface, 
a user can use applications and start agents.  However,
she does not have to be online while the application is running.
Consider as an example a groupware application 
in which users all around the
world participate in some work.
It would be unacceptable to force the users to be logged 
all the time, as their tasks are asynchronous in nature.  
Thus, a user is free to log in and out. While a 
user is not connected, her homeagent can still receive messages from one
of the applications she joined in.

To the PageSpace, the homeagent looks like an autonomous agent.  
It has full access to the coordination architecture, 
and sends and receives messages.
For application agents, the homeagent is the default destination of all the
messages meant for the human user.  That is, only the homeagent ``knows''
whether the user is currently present or absent from the PageSpace.

The homeagent stores all the incoming messages in a persistent store until the
user retrieves them and reacts to them.  If there is a bidirectional
connection in place between the homeagent and the user interface agent, then
the homeagent can deliver the messages to the user as soon as they come in.
If the user accesses the PageSpace through an HTTP connection, on the other
hand, the application agent queues all messages and delivers them as soon as
the user agents opens an HTTP connection to the homeagent.  We are exploring
mechanisms to give homeagents a limited autonomy in responding automatically
to incoming messages whenever possible.

Since the homeagent is the collector of the messages bound to the user agent
(and, ultimately, to the user him/herself), the user agents interacts directly
only with it.  A stable part of the user interface should therefore be
assigned to interacting with the homeagent.

In fig.~\ref{fig:alpha} we show a prototype interface for a Poker
application.  The interface is divided in three parts: the lower part contains
the specific interface for the application currently considered by the user.
The top right side contains a form whereby the user, through a plain HTTP
connection if necessary, can instruct the homeagent to perform some
operations, such as activating or destroying an application, get a list of the
latest incoming messages, etc.  On the top left side, a list of recent
messages is displayed from some of the currently active application agents
around the PageSpace.

This list is updated by the homeagent on receiving a new message if a
persistent, bidirectional connection is in place, or, if relying on standard
HTTP connections, either automatically by the browser at regular intervals
through client pull technologies, or manually by the user whenever he/she asks
for an immediate connection.

  \begin{figure}[htb]
    \begin{center}
      \leavevmode \epsfig{file=alpha.eps,width=\columnwidth}
%D THE interface looks a little stonger to me, A interface sounds better
%R Ok, but still it is An interface...
      \caption{An interface to PageSpace for the user}
      \label{fig:alpha}
    \end{center}
  \end{figure}

\subsection{Applications and Agents}
\label{sec:appag}

Applications in the PageSpace are composed of agents. In an application in
use, three sorts of them are involved:

% R1-L: how do I create deltas?
%R tried to make this a bit clearer below
% R3-D2: "provides the specific user interface": isn't this done
% by the alpha?
%R I think that the paragraph below is clear - it is diplay as _part_ of the
%R user interface agent.
%R explained better
% Davide, Robert, Paolo, will some of you check this section, answer
% to these questions, and generally rewrite it so that it is clearer?

\begin{itemize}
\item Application agents, which provide the specific user-interface of the
  application. As described in section~\ref{sec:appint}, we separate the user
  interface and the application in order to give access to it via a Web
  browser. Thus, an application agent can define a user interface, for example
  as an HTML
  document or a Java applet, 
  which is then passed to the homeagent of a user of the
  application. From there, it is retrieved and displayed as part of the user
  interface agent in a browser.

\item Agents that implement the actual application specific functionality. A
  subset of a distributed application consists of agents that share an
  application specific context, which is of no use for other agents.

\item Agents that are used by an application, but that offer services to any
  application. These services are generic in that they can be used in the
  context of any application.
\end{itemize}

All agents are started by users within the PageSpace. 
They remain therein and
answer to service requests by other agents 
until they are withdrawn by their owner.
Several kinds of accounting for
the use of agents and services can be introduced here.

Agents are programmed using specific classes. With the
inheritance mechanisms of Java, a default behavior is provided and a
mandatory minimal functionality enforced.
The programmer of an application agent focuses on the implementation of the
functionality of the service offered. 

A designer using PageSpace should take
care of the following:

\begin{itemize}
\item Users' interaction with the PageSpace;
\item Instantiation of user interfaces;
\item Management of coordination by offering an API for the interaction
  with other agents;
\item Management of distribution and concurrency;
\item Provision of a skeleton functionality for application agents.
\end{itemize}

% R3-D6: do we have any example?
% Fabio: I think that the previous discussion of which classes are
% used is too specific and in contrast with the "reference
% architecture" approach that I've been trying to follow.
% Robert, Paolo, will you agree and check this and everywhere else where
% this approach is inconsistently applied?

%R You are right. I commented out the names of classes above. Work remains for
%R Davide to make his description a bit less Java-based and technical -
%R however, I would not recommend to omit all technical details there.

% Robert, Paolo: simmetry asks for a longer discussion of Zeta agents here.
% Just an additional couple of paragraphs should suffice.
%R I did two paragraphs.

The integration of legacy applications and gateways to other coordination
environments can be achieved by wrapping and gateway agents.
They are similar to application agents in that they offer services to the
PageSpace, however, they implement them by interacting with a closed
application or via some middleware protocol to other middleware specific
object.

A gateway agent that wraps a legacy application offers its services to
the PageSpace just like other application agents.  However, the
implementation of the functionality is embodied in the application
being wrapped.  The gateway agents \emph{passes} this functionality as
services.

A gateway agent which interfaces to another environment is concerned with
\emph{mediating} requests from the PageSpace environment to appropriate
services found elsewhere and \emph{translating} requests and answers. It may
use certain knowledge to ensure semantic correctness of this translation.

\begin{comment}
\subsection{The Kernel Agent}
\label{sec:kernel}

The coordination environment used by all agents is established by kernel
agents in PageSpace.  On each machine participating the PageSpace, one kernel
agent is running. Its obligations and its implementation is described in
section~\ref{sec:kernels}.

  On each host participating the PageSpace, one kernel agent is running.
  It can be considered the kernel of the coordination functionalities of the
  PageSpace. Kernel agents have several purposes:

% Robert: simmetry also asks for a section on kernel. I've tried
% taking from the section "The PageSpace Kernel Agents", but it is
% too specific and not consistent with the reference architecture
% approach. Can you write 5/6 aragraphs in the style of the other
% subsections here?
%R sec:kernels is a thorough description and rationale for the kernels. I
%R beliebe that we would just run into repititions if we say too much here.
%R In addition, PageSpace is perfectly understandable at this point without an
%R in-depth description of the kernels.
%F Ok but then the whole subsection has to go.
\end{comment}

\section{Implementations of the PageSpace Platform}
\label{sec:psimp}

The PageSpace architecture has currently been implemented in a few
prototypes used for demonstration purposes and for the exploration of
further concepts. Our prototypes follow the implementation strategy
outlined in the previous section.  While work remains to be done on
the engineering of the architecture, we believe that its main
principles can remain unchanged.
Some of the prototypes we built
are available on line (see the last section for links).

\subsection{Basic coordination technology in PageSpace: Jada}
\label{sec-jada}

% R2-F: too many details, too many terms.
% R2-C: Why is Java and CORBA not enough?
%R The related approaches states this (directed invocations)
% R3-C1: how do you specify unbounded variables?
%R Huh? What does this sentence mean?
% Davide, please rewrite section according to our approach.
%R Davide, I changed the layout very much. This is not a manual but a
%R paper. btw., \pathsl typesets stuff so that it breaks lines at characters
%R like .,- etc. Please leave details of formatting to the final CRC editing.

\begin{comment}
In the Jada language, the Linda approach has been adapted to Java
\cite{CiaRos97}.  
Differently from other Linda-like implementations, which
usually include a preprocessor, 
Jada is merely based on a set of Java classes to be
used to access a tuplespace.

In Jada a \emph{tuple} is represented by the \texttt{tuple.Tuple} class and
contains a set of \emph{objects}. Thus, \pathsl|Tuple my_tuple=new Tuple(new
Integer(10),"test");| is an example of a Jada tuple.  It includes two actual
fields; the first item is an \texttt{Integer} object valued 10, the second one
is a \texttt{String} valued ``test''.

To build a tuple with one formal field of type \texttt{String} we can write
\pathsl|Tuple formal_tuple=new Tuple(new String().getClass());|.  Thus, a
Class type used as argument in the constructor of a tuple is used to represent
a formal field.  To build a tuplespace using Jada we write
\pathsl|tuple_space=new TupleSpace();| We can share this object among multiple
threads.

When we want a thread to put a tuple into the tuplespace we write
\pathsl|tuple_space.out(new Tuple(new Integer(10),"test"));| The new
tuple can be later read by another (or even by the same) thread using
the \Read or the \In methods: \pathsl|Tuple
read_tuple=tuple_space.read(new Tuple(new Integer(10),"test"));| The
access to the tuplespace performed by the \In and \Read operations is
associative: these operations return a tuple matching the one used as
argument.  Jada uses the same matching rule described above for Linda.

To support distributed programming, the classes \texttt{TupleServer} and
\texttt{TupleClient} allow remote access to a tuplespace. In fact, each
tuplespace is a shared remote resource available through a tuplespace server
running on some host at a specific port.  This way we can run as many
tuplespace servers as we like in a network, so that applications can
independently operate on several, distributed tuplespaces.
\texttt{TupleServer} is a multi threaded server class which translates requests
received from the \texttt{TupleClient} class in calls to the methods of the
\texttt{TupleSpace} class.  \texttt{TupleClient} interfaces with a remote
\texttt{TupleServer} object, holding the real tuplespace, and requests it to
perform the \In, \Read and \Out operations.

% R4-C2: Multiple spaces: it is complex, and needs to be explained.
%R I am not sure whether we should open that field here.

\end{comment}

Jada is a language which extends Java with the Linda coordination
language \cite{CiaRos97}.
%R I comment out this sentence, as the reader does not know about how Linda
%R systems are implemented here
\begin{comment}
  However, differently from other Linda-like implementations, which usually
  include a preprocessor,
\end{comment}
Jada is based
on a set of Java classes to be used to access shared object spaces.
%R This is what can be expected
%R thus actually it is fully Java compatible.

An {\tt ObjectSpace} is an object container offering a set of methods for
accessing its contents using a Linda-like coordination model.  An object space
can be shared among multiple threads since its access is thread-safe, because
the accessing methods manage critical sections.  To create an object space we
write \path|ObjectSpace my_object_space=new ObjectSpace();|

Following the Linda coordination model, \Out is the method to put an object in
the {\tt ObjectSpace}, whereas \In and \Read are the methods to get an object
from the {\tt ObjectSpace}.  Actually Jada implements several variants of
these basic operations.  For instance, to put an object in the object space we
write \path|my_object_space.out(new String("foo"));|

%R reformulated a bit
%F reformulated a bit more
To access the {\tt ObjectSpace} searching for objects an associative matching
mechanism is used: a call to the \In (or \Read) method includes an object to
be used as a matching pattern.  The object returned by the {\tt in} method (if
any) is an object found in the the object space that matches the given
pattern.  The same applies to the \Read method, although only \In removes the
matching object from the object space.

Tuple-matching is based on the concepts of {\em formal} and {\em actual}
objects: a formal object is an instance of the {\tt Class} class (the
meta-class used by Java).  Any other object is an actual object.  Then
the Jada matching rules are:

\begin{itemize}
\item \emph{actual-actual}: two actual items match if
\begin{itemize}
\item they implement the {\tt JadaItem} interface: the method {\tt
matchesItem}, applied to the object in the object space, passing as
parameter the other object, returns {\tt true}.

\item they do not implement the {\tt JadaItem} interface: the method {\tt
equals}, applied to the object in the object space, passing as parameter
the other object, returns {\tt true}.
\end{itemize}

\item \emph{actual-formal}: a formal item matches any object which is an
instance of it.

\item \emph{formal-formal}: two formal items match if they represent
the same class.
\end{itemize}

%R reformulated a bit
The matching mechanism in Jada is thus object-oriented; this means that
inheritance is applied when checking for two objects to be of the same type:
the returned type from an \In or \Read operation can then be a subclass of the
specified object. Note that inheritance is not applied to formal-formal
matching.  So, for example, \path|object_space.in(new Object().getClass())|
%R ``a non-formal'' instead of ``any non-formal'' - the later is wrong.
collects a non-formal object stored in the object space.

The Jada matching rules are quite simple yet powerful.  Since the
actual-actual matching is customizable (using either {\tt equals} or {\tt
  matchesItem} methods) the mechanism is also very flexible: we can, for
example, write an Integer wrapper class with ad-hoc matching rules so that an
object matches any object whose contents is less that the one given in the \In
or \Read call.  However, sometimes is necessary a way to associate values,
like an integer with a string that represents the meaning of the integer, such
as {\tt "counter"}.  Thus, like in Linda, we introduce the {\tt Tuple} class,
an object container class with an extended matching mechanism.

In Jada a {\it tuple} is a set of objects (also referred as {\it items}) and
it is implemented via the {\tt jada.Tuple} class.  
This is an example of Jada
tuple: 

\noindent\path|Tuple my_tuple=new Tuple(new Integer(10),"test");|

Such a tuple
includes two items (we say that its cardinality is two): the first item is an
{\tt Integer} object, the second one is a {\tt String} object.  We define
actual and formal items within a tuple the same way we defined them for Jada.

To use the associative object space access with tuples we can use the
tuple matching mechanism: two tuples {\tt a} and {\tt b} match if they
have the same cardinality and each item of {\tt a} matches the
corresponding item of {\tt b}.  The usual Jada mechanism is used to
check if the items match.

Thus, the tuple 

\path|Tuple a=new Tuple(new Integer(10),"test");|

matches the tuple:

\path|Tuple b=new Tuple(new Integer(10),new String().getClass());|.

  Note that to exchange a tuple (and generally any kind of object) two threads
  do not need to perform synchronous \Out and \Read operations (Jada does not
  need rendezvous communication).  In fact, suppose the threads {\tt ta} and
  {\tt tb} have to exchange a message: {\tt ta} will put a message inside the
  object space, {\tt tb} will read the message from the object space.  If {\tt
    ta} performs the \Out operation before {\tt tb} performs the \Read
  operation it does not have to wait for {\tt tb}: it simply continues its
  execution, and the tuple is now stored into the object space.  When {\tt tb}
  performs the \Read operation it will be able to read it.

  Instead, if {\tt tb} performs the \Read operation before {\tt ta} performs
  the \Out operation, {\tt tb} will be blocked until an object that satisfies
  the \Read request will become available (i.e. until {\tt ta} performs the
  \Out operation).

The \In and \Read methods are blocking.  To avoid blocking a thread when a
matching object for the \In and \Read operations is not available we can use
the \Innb and \Readnb methods. They access the object space the same way as
\In and \Read, but return {\tt null} if no matching object is available.

A more sophisticated flavor of \In and \Read that aborts after a
time-out is also available.  It is also possible to associate a
time-out to each object put in the object space: when the time-out is
over the object can be garbage-collected and deleted from the object
space.

To allow remote access to an object space, the {\tt jada.net.ObjectServer} and
{\tt jada.net.ObjectClient} classes are provided.  We used a client/server
architecture to manage the object spaces; in fact, each object space is a
shared remote resource accessed through an object space server.

The object space server is addressed using the IP address of the host it runs
on and with its own port number for a socket connection.  This way we can run
almost as many object space servers as we like in a network, so that
applications can independently operate on several, distributed object spaces.
{\tt ObjectServer} is a multi-threaded server class which translates requests
received from the {\tt ObjectClient} class in calls to the methods of the {\tt
  ObjectSpace} class.

In fact, both {\tt ObjectServer} and {\tt ObjectClient} are based on {\tt
  ObjectSpace}.  {\tt ObjectServer} and {\tt ObjectClient} communicate using
sockets.  {\tt ObjectServer} uses {\tt ObjectSpace} to perform the requested
operations.

The {\tt ObjectClient} class extends {\tt ObjectSpace} changing its internals
but keeping its interface and behavior (apart from some new constructor and
some new methods).  
Thus, a {\tt ObjectClient} object is used just like an 
{\tt ObjectSpace}, 
except that it provides access to a remote object space
which can run in any host of the network.
What {\tt ObjectClient} does is to interface with a remote {\tt ObjectServer}
object (which holds the real object space) and requests it to perform the \In,
\Read, and \Out operations and (eventually) to return the result.



\subsection{Service Interoperability in PageSpace: Laura}

% R2-F: too many terms are unclear
%R nice comment :-) I cannot explain if I don't know what is unclear
% R2-I: what does associative mean?
%R It is not used in the Laura section. Perhaps this refers to a sentence in
%R the former Shade part ``Messages are not just associative, they are also
%R persistent:''
% R3-C1: "no names are used" is misleading
%R expanded a bit more precisely
% R4-D: give more details on the type system.
%R hmmm. introduced one paragraph.
% Robert, this is your stuff.

%F,P: added an introductory sentence on Laura

Laura is a coordination model based on Linda where the
``tuplespace'' is enhanced into the concept of a \emph{service-space}
which is a collection of \emph{forms}, special tuples shared by all
agents.  A form can contain a description of a service-offer, a
service-request with arguments, or a service-result with results.

In Laura, a service is described as an interface consisting of a set
of operation signatures.  The signatures describe the types of the
operations in terms of their names and their argument- and
result-types.  It is therefore a record of function-types.  A form
contains a description of this interface-type for
service-identification.  Putting a service-request form into the
service-space triggers the search for a service-offer form so that the
interface-type of the offer is in a matching relation to that of the
request.

In Laura, no names for interfaces are used to identify services or for
the types of data involved in an operation.  Instead, a service
offered or requested is described solely by an unnamed interface
signature consisting of a set of operations signatures.  The operation
signatures consist of a name and the types of arguments and
parameters.

Laura therefore emphasizes \emph{what service} is requested, not
\emph{which agent} is requested to perform it.  A crucial point
therefore is the identification of services.

In Laura interfaces are notated in a service type language. In \cite{Tol95b}
we formally defined a type-system which is used in the definition of the
semantics of such interface definitions.  Such a type system includes rules
for subtyping and this subtyping is the key for Laura's identification of
services: given the interface descriptions in forms, a service offer matches a
service request, if the type of the offered interface is a subtype of the
requested one.

Subtyping in Laura is defined so that a type A is a subtype of B if all values
of type A can be substituted when a value of type B is requested; the
``values'' we type are services. Such a subtyping enables us to use a service
of type A if a service of type B is requested.

%R new
Specific of Laura's type system is that it deviates from approaches to the
management of types in open systems in three ways.  First, it abolishes global
names for interfaces for services and relies on matching of interface types
only. Second, it ignores names of structured types.  Finally, it uses
syntactic equivalence only for the names of operations appearing in an
interface.

A service is the result of an interaction between a service-provider and a
service-user. In Laura, two operations coordinate this interaction for the
service-provider, \texttt{serve} and \texttt{result}.

An agent willing to offer a service to other agents puts a serve-form into the
service-space. It does so by executing \texttt{serve}, which takes as
parameters the type of the service offered and a list of binding rules that
define to which program variables arguments for the service should be bound.

When a \texttt{serve} is executed, a serve-form is built from the arguments.
Then, the service-space is scanned for a service-request form whose
service-type matches the offered service by being a supertype.  The provided
arguments are copied to the serve-form and finally bound to program variables.
\texttt{serve} blocks as long as no matching request-form is found.

After performing the requested service, the service-provider uses
\texttt{result} to deliver a result-form to the service-space.  A result-form
is built which consists of the service-interface and -- depending on
\texttt{operation} -- a list of result values according to the binding list.
The agent is responsible to store the results of the service properly in those
variables. The operation is performed immediately and the form is put into the
service-space.  An agent offering services usually operates in a loop
consisting of the sequence \texttt{serve}--\emph{perform the
  service}--\texttt{result}.

% R2-J. Laura - why do we need another name for connecting a request
% to a response (p.7)?
%R Where is this stated in the text??

An agent that wants to use a service has to execute Laura's third and last
operation, \texttt{service}. Its arguments are the service-type requested, the
operation requested, arguments for the operation and a binding-list.

When executing \texttt{service}, two forms are involved: a service-put form
and a service-get form. The first is constructed from the service-interface
and the arguments and then inserted to the service-space. If another agent
performs a \texttt{serve}-operation and the service-put- and serve-forms
match, the arguments are copied as described above and the service-provider
starts processing the requested operation.

The service-get form is constructed from the service interface and the binding
list for the results. Then, a matching result-form is sought in the
service-space and -- when available -- the results are copied and bound to the
program variables.  When the request-form is entered to the service-space, it
is matched with some serve-form. When the result-form is retrieved, the
results are bound to program variables of the requesting agent.

The interaction of agents coordinating services with Laura consists
either of putting a request for a service to the service-space,
finding a matching offer form and copying of arguments or of trying to
get the results of a service, by finding a matching result-form and
copying of the results.  This interaction is uncoupled, as
service-provider and service-user remain completely anonymous to each
other.

%R new
Laura provides the basic means to implement the service exchange among
application agents. We adapt the paradigm of exchanging form within the Laura
API. With the reflection API in Java 1.1, we could well change from our
service description language to Java interfaces in forms.

\subsection{The PageSpace Kernel Agents}
\label{sec:kernels}

%F Since this is the implememntation section of a reference
%F architecture, we cannot allow to describe Kernels as part of the
%F architecture, but of a specific implementation. Added an introductory
%F sentence and changed a bit here and there to adhere to this.

Every implementation of the PageSpace architecture will have to
provide a way for agents to be able to be started, blocked, moved, and
generally managed within the selected coordination environment. We
have designed a specific class of agents to deal with these tasks,
the {\emph kernel agents}. Our implementation runs on a Java virtual
machine and manages multiple threads. It requires that one kernel
agent runs on each machine participating to the PageSpace. The kernel
agents provides several services:

\begin{comment}
%R todo: does this repeat a paragraph above?
%R It did, so I reformulated the paragraph above as a reference to this
%R section
On each machine participating the PageSpace, one kernel agent need to
be running.
%R  It can be considered the kernel of PageSpace. Each kernel
It runs on a Java virtual machine and manages multiple threads.
The kernel agents have several purposes:
\end{comment}

\begin{itemize}
\item \emph{Provision of access to the PageSpace}

  A user accesses PageSpace via her homeagent that is contacted
  by HTTP from a browser.  Thus, a Web server has to be co-located
  with a kernel.  As there are several implementations of Web servers
  in Java -- like Jigsaw from the W3C --, the HTTP server could be
  integrated as a thread of the kernel, thus avoiding the CGI
  mechanism to pass information to homeagents.

\item \emph{Management of homeagents}

  Homeagents are in fact implemented as a single object within a
  kernel.  They are parameterized with the identification of a
  PageSpace user.  Thus, after passing a login form in which a
  PageSpace user name and password is entered, each user receives the
  same user interface agent components, but each one is based on a
  different message queue stored persistently in a database on the
  kernel.

  Besides interacting with messages, the user can use applications,
  and start application agents from its homeagent.  Both result in the
  execution of a thread within the homeagent object.  To use an
  application, that thread issues the appropriate coordination
  operation, waits for the results, stores it in the database and
  terminates.  To start an agent, a method of the kernel object is
  invoked which starts an application agent.

\item \emph{Management of application agents}

  Each application agent is executed as a thread. This is reasonable,
  as we can make use of the native interaction mechanisms within one
  Java virtual machine for threads, and to not have to execute
  multiple virtual machines on the node that participates in
  PageSpace.

  \begin{comment}
  All application agents have the same kernel structure as depicted in
  fig.~\ref{fig:delta}.  The main purpose of it is to pass invocations
  of the coordination primitives on to the kernel.  Besides, the
  specific coordination style can be supported by pre-fabricated
  handlers, for example for the dispatching of methods when the
  service-based Laura operations are used.

  \begin{figure}[htb]
    \begin{center}
      \leavevmode \epsfig{file=delta.eps, width=\columnwidth}
      \caption{The logical structure of application agents}
      \label{fig:delta}
    \end{center}
  \end{figure}
\end{comment}
% R2-H: the figure is too obscure
% Robert, this is yours.
%R I commented out that region

  The kernel agent manages program exceptions and monitors the
  operation of the agent threads.  Thus, it establishes an operating
  environment for coordinated application agents within a Java virtual
  machine.  We inherit all aspects of thread management from Java, and
  add the ``multi-agent'' interaction mechanisms by coordination
  technology.

\item \emph{Implementation of the coordination operations}

%R
%R  As outlined in section~\ref{sec:coordtech},
%R should this reference go to the jada/laura description??


%F  As outlined in section~\ref{sec:psimp}, we include several flavors of
  Several flavors of coordination environments can be
  used in PageSpace.  All of these have in common that they are
  centered around the use of a shared space of element of some kind,
  and that some matching rule guides the coordination primitives.

  Thus, each kernel contains instances of a generic component, the
  \emph{repository}. A repository is a collection of elements of some type.
  Each repository implements the specific operations of a coordination
  language with a specific matching routine, thus it may be optimized, but it
  is based on the management of a pool of elements of some type. Within the
  kernel architecture, multiple repositories can be integrated to the internal
  control and data streams.

\item \emph{Implementation of the distribution architecture}

  Each kernel has an interface to other kernel agents, through which the
  distribution protocol is spoken. We foresee the possibility of different
  distribution architectures integrated via a set of interconnected
  sub-PageSpaces.

\end{itemize}

Fig.~\ref{fig:kernel} shows an excerpt of the logical structure of our
implementation of the kernel agents.  All the objects that run in
threads are connected by sets of streams for both data exchange and
agent management.

\begin{figure}[htb]
  \begin{center}
    \leavevmode \epsfig{file=epsilon.eps, width=\columnwidth}
    \caption{An outline of the logical structure of a kernel agent}
    \label{fig:kernel}
  \end{center}
\end{figure}

A kernel agent includes: 
a kernel console, to control its activity;
an agent store, which stores application agents programs;
a homeagent server, which stores homeagents;
some agent connectors, to let agents interoperate
with agents in other kernels;
some repositories, which persistently
implement some flavor of coordination tuplespace;
some kernel connectors, to implement
distributed PageSpaces.

In middleware platforms, the issues of discovering, naming, and accessing
services are central. 
In PageSpace we do not enforce a (distributed) registry
of existing agents, but take a different approach similar to the way of
accessing pages in the Web.

%As a kernel agent knows about all agents it is managing, it is able to provide
%lists of these and their interfaces. The natural way to access such a list is
%by providing it with the built-in HTTP server for Web access.  Thus, the
%``name'' of an agent for the outside world is a simple URL.

%% R3-E: this is not clear.
%% Robert, this is yours.

%Users that want to use agents, keep their personal list of known agents --
%just as one does for known Web pages with a bookmark-list. This list is used
%by a homeagent to offer the use of agents and applications to the user. It can
%be extended by the user, and be the subject to public catalogs of agents --
%resembling search engines and index services on the Web.

%For example, for a service-based use of the PageSpace, the interface of a
%requested agent has to be passed to the coordination operations. This
%interface is accessible from the kernel that manages an respective agent.
%%R todo: is this true?
%The homeagent retrieves it via HTTP, and construct the appropriate
%coordination operation.

%R reworked this

Web pages are named and referenced by URLs and accessed by contacting the
corresponding Web server. Similarly, information about agents is offered
via HTTP
by the kernel agent at a given site. This meta information consists of formal
data, like the interfaces of services offered by an agent, and non-formal
parts, like a natural language description of the agent.

An agent can thus be accessed by retrieving this meta information via a
URL and using it appropriately in coordination operations. The meta
information will be generated dynamically by the kernel agent.

The discovery of information in Web pages is currently mediated by
catalog services and search engines.  In analogy, we foresee catalogs
of links to agent meta data and search services on them.  Users
collect links on Web pages of interest in personal catalogs as
bookmarks. By the same analogy, homeagents can offer the user such
personal lists of interesting agents and applications.

\subsection{Distributed PageSpaces}
\label{sec:distrib}

%F Added the next sentence to clarify this section in the context of a
%F reference architecture.

We have extended our prototype kernel implementation to handle
distributed PageSpaces.

% R1-M: Is this a federation of PS?
% Robert
%R Yes, I used the term below.

Our implementation of the kernel agents manage and coordinate agents
on one machine.  For distributed applications, these kernels have to
have a distribution architecture and a communication protocol.  A
special concern with such a protocol is scalability -- the ability to
provide efficient coordination for a platform involving a large number
of machines.

The approach of establishing a shared repository of information can lead to
scalability problems due to the amount of overhead for replication. We can
take a flexible approach to structuring the system to overcome these problems.

% R3-F: is the hierarchy an implementation necessity, or what?
% Robert, Paolo
%R Argh. Hmm. I take out the term hierarchical.

We follow the approach of the Internet to scalability: the machines that
participate in the PageSpace are organized in a loose federation. Locally
connected machines follow a replication schema in a logical sub-PageSpace and
one machine is defined as the gateway to other sub-PageSpaces. Thereby, we
imitate the interconnected subnets of the Internet.

The specific organization of kernels within one sub-PageSpace is a local
decision. Known architectures for distributed implementation of Linda-like
systems include full replication of a repository to all nodes, no replication
with a single, centralized repository,
%R no replication of repositories in a ring-like organization \cite{Pol95},
or a partial replication as in \cite{CarGel86a}.  As long as there is one
defined node that follows a gateway protocol to other sub-PageSpaces, our
architecture supports all of them. In fact, the current Jada implementation
uses a centralized or fully replicated repository, whereas Laura implements a
partial replication scheme.

For a gateway, a ``routing-table'' exists that instructs the gateway
as to which other sub-PageSpaces should be forwarded the requests for
matching elements.  Thus, the distribution structure can be configured
statically or dynamically.

This configuration will be based on the structure and behavior of the agents
within a sub-PageSpace, and supports them in their coordination requirements.
All the flavors of coordination employed in PageSpace give way to several
intelligent optimizations that are yet to be evaluated.

%R Changed title
%\subsection{Features of the PageSpace Platform}
\subsection{Options for Fault Tolerance and Mobility in PageSpace}
\label{sec:feat}

The PageSpace architecture has several features that are yet to be explored.
We discuss two of them, namely fault tolerance and mobility.  We show how
these features have been introduced to the platform, and how they are enabled
by the design of the platform.

\begin{itemize}

\item \emph{Fault tolerance}

%R2-E: please explain better and with examples.
%R Hmm. for fault tolerace, the examples are given. for mobility, we simple do
%R not have examples, as we did not think about mobility really.

\label{sec:faultt}
%R new first sentence
What happens when agents in our architecture fail?
Failures of the user interface agents -- because of a crashing browser, or a
fault in the users machine -- do not affect the PageSpace at all. The failure
of a homeagent does not introduce problems, insofar as the queue of messages
for a user is kept persistent.

Homeagents, application and gateway agents are managed by the coordination
kernel.  This means that the kernel can keep a log of their external
interactions and request state information that is stored persistently. A
kernel thus can monitor the managed agents, and restart them in case they
crashed with a given state.  We foresee that any managed agent can provide a
method that transfers state information to the kernel agent.

In the case of an kernel failure, the kernel and all managed objects are
lost. The log of external interactions can be used to reestablish the
repositories after restart; the managed agents can be restarted accordingly.

\item \emph{Mobile PageSpace agents}

\label{sec:mob}
As application agents interact transparently with respect to their
location, they are candidates to support mobility of agents within
PageSpace.  In order to do so, they have to be able to pass their
internal state to a kernel, which can start it.

Application agents may want to be moved because they detect that they
interact with each other and try to make the coordination more
efficient by ``meeting'' at a specific location.  They can be asked to
move by an authoritative kernel, because of a specific policy applies
to their current location (eg.  workload management, or dedicated
machines).  It has yet to be evaluated what protocols are most efficient
to perform such operations, and what strategies for mobility should be
followed.
\end{itemize}

%R New section heading
\subsection{Using PageSpace to design an Application}
\label{sec:app-ec}


% R4-B: the level is too high. Some details, please
% R2-M: How is Linda used here?
% R3-4: the images are useless. What are the agents, and how
% do they interface?
% Davide, Paolo, this is yours.

%D changed from future to present all the protocols

The PageSpace has been introduced for interactive
multiuser applications, so usually
we start designing a PageSpace application
from defining which user roles need a specific
user interface agent.

For instance,
we realized an auction bidding system within the PageSpace project 
as a case study in electronic commerce.
The auction system has three types of users: 
the \emph{Auctioneer},
who sells items to the highest offer, 
the \emph{Participants}, who buy
items sold during the auction, and 
the \emph{Observers}, passive
audience to the auction. 
The auctioneer and the participants 
communicate during the bidding, 
whereas the observers 
simply follow the bidding.

The activities of the users can be divided in the following phases:

\begin{itemize}

\item[] \emph{Phase 0}: 
The auctioneer provides information about the auction
  using messages to newsgroups and mailing lists, and setting up a WWW site.
  The auctioneer provides for an information package explaining the modalities
  for the users interested in the auction. Users can either simply observe the
  auction, or actively participate to the bidding. In the first case, they
  are informed of the bids, but they are not allowed to place a bid and
  buy an item. In the second case, they can actively participate to the
  bidding, sending bids for an item.

  The auctioneer then starts an application agent building the environment
  for the auction. All participants and observers activate their own
  application agents to handle their bids. To do so, they ask their homeagent
  to start up a new specialized application agent. 
  All messages relevant
  to the auction are exchanged among these agents.
  If a user is not online at bidding time, 
  he can be represented by an autonomous agent, 
  which may follow some bidding policy 
  that does not require a
  direct user intervention.

\item[] \emph{Phase 1}: 
 The auctioneer puts an item up for auction and starts a
  timeout for receiving bids. 
  He notifies to all connected users the
  new item and its base price. 
  As soon as the new item is put on sale, the
  auction agent notifies all participants and observers.

\item[] \emph{Phase 2}: As soon as the 
  information about the new auction item is made
  available to the participants,
  they can submit the auctioneer a new bid,
  or request to unsubscribe from the current item, i.e. by stopping
  to receive updates for the current item and waiting for the next one.

\item[] \emph{Phase 3}: The auctioneer accepts any valid bid (i.e. larger than
  the current bid) from registered participants, and resets the timeout
  value. Every new bid causes a broadcast of the new value to all
  participants and observers. 
  When no new valid offer is received within the time out period, the auction
  stops and the item is considered sold. The auctioneer notifies all users
  that the sale is closed, and starts a new auction for the next item,
  resetting the list of participants.

\end{itemize}

The user interface agent for the auction system is shown in
Fig.~\ref{fig:auction}.

\begin{figure}[htb]
  \begin{center}
    \leavevmode \epsfig{file=auction3.eps,width=\columnwidth}
    \caption{The interface agent of the auction system}
    \label{fig:auction}
  \end{center}
\end{figure}

It is divided in three frames containing a number of applets.  
The top left
frame displays the item currently offered. 
The top right frame allows users to
place bids, and on the bottom the currently valid bid is displayed. Every time
a new valid bid is received by the auctioneer, all bottom frames are updated
with the new value. After a time out, an animation of a mallet hitting a
surface is displayed to signify a final sale.

Fig.~\ref{fig:useragent} shows the applets which compose a user agent:
they coordinate via Jada both locally and remotely.

\begin{figure}[htb]
    \begin{center}
      \leavevmode \epsfig{file=AgentsAuction.eps}
      \caption{Applets in useragents}
      \label{fig:useragent}
    \end{center}
\end{figure}

The agent {\tt bid} is interactive: 
it allows a customer to place a bid,
This applet is always active,
waiting for user input.

The customer has to choose
an amount to increment the current bid
(displayed by applet {\tt display}).
The customer must insert in {\tt TextField} the username; 
the amount is chosen by the ({\tt Choice}) 
button (in Fig.\ref{fig:auction}
this shows {\tt \$550}); finally,
the user has to press another button to send the offer. 

Agent {\tt next\_item} is a button which allows
to skip the current item on auction to another one. 

Agent {\tt cartoon} animates a gavel representing
that the current auction is still in progress,
or it is finished (the gavel falls).
The animation is based on a sequence of five images. 

Agent {\tt display} shows the current bid and its owner. 
This agent is especially critical,
because it must show the same information
to all bidders. 

The most critical agent is the {\tt auctioneer}
which is the logic coordinator of the whole system
and can run on any host: 
it decides when an offer is valid;
it tells agent {\tt display} about the current bid;
it sells an item, etc.
This agent is not displayed by an applet.
The tuple space
has to run on a server machine running also the auctioneer
for security constrains imposed by Java.
Other agents have no constrains at all.

This is a simple yet realistic
example of using the PageSpace reference architecture
in a context of electronic commerce.
In the application we have developed, 
we allow customers to participate offline
to the auction, and we interoperate via a gateway agent with a database
containing images and descriptions of auction items.
The behavior of agents representing customers
is defined by rules in a manner very similar
to that described in \cite{APP97}.

As another case study we developed a distributed WWW-based card game.
The game itself is a variant of the well-known {\it Hearts} card game.
The components of this interactive distributed application are:

\begin{itemize}
\item the players;
\item the table server;
\item the hearts servers;
\item the chat servers.
\end{itemize}

The table server manages the arrangement for the tables: players can
join/leave a table sending a request to the table server. When a table has
four players the game starts.
Once the game is started the players have to talk with a
hearts server, created on the fly by the table server, in order to compete
in the game. 
While the players are arranging the table or playing they can
exchange text messages using the chat server.


\section{Related Approaches}
\label{sec:related}

% R2-G: too much literature on Linda
%R not true now.
% R3-H: Good references, but no comparison to PS
% R4-A2: compare detailatedly PS with others.
%R I tried to compare
% Paolo, Robert, this is yours.

Several research and commercial efforts are currently concerned with adding
various functional features to the Web. 
Being based on a client-server
software architecture, the WWW can be extended in three different
parts: either the server, or the client, or the communication protocol, or a
combination of them. Here we present a few academic and industrial projects
that show examples of these extensions.

Middleware standards such as CORBA and DCE are the results of the effort of
industry committees consecrated to making commercial applications interoperate
as smoothly and as painlessly as possible for the application designer, the
system developers, and for the final users. These platforms provide standard
ways to define, locate and request computational services from participating
applications, both locally and remotely. Middleware solutions may help the WWW
define a standard and unique way to access and execute remote services,
letting it potentially become the standard interface to all networked services
available now and in the future.

For instance, ANSA is pursuing the integration of WWW technologies and
CORBA-related standards \cite{REMBM95}. Their approach is two-sided: on the
one hand, they are creating a standard set of CGI gateways to allow
bidirectional interaction between a CORBA based environment and HTTP tools
(CORBA clients accessing to HTTP resources and HTTP software accessing CORBA
distributed objects).  On the other hand, they are building a set of WWW tools
to integrate and replace HTTP: a server that can provide services using both
HTTP and IIOP (the Internet Inter-ORB Protocol providing the connection layer
to all CORBA 2.0 compliant platforms) and an Arena-based browser using IIOP as
its connection mechanism.

On the other hand, Marco is a CGI gateway to OSF's DCE servers \cite{BIVYW95}
developed as a demonstration of a proposed general architecture for
integrating generic middleware components into the WWW through CGI. Two
modules are identified: a ``type manager'', which knows about data contained
in the middleware services connected, and a ``trader'', which knows about the
details of service instances and interface descriptions of the services
connected. A general interaction protocol is defined, allowing clients to
identify the service through a two-step request, receive an HTML form document
suited to the kind of service requested, and perform the most efficient
request.

%R new
These two projects are examples for server-centered architectures for
Web-applications. They provide only a Web interface to an otherwise not
Web-enabled infrastructure such as CORBA and DCE. In contrast, PageSpace is
not a mere gateway, it is a reference architecture integrated with the Web and
allowing for applications that are in part distributed to the users client.

Two recent developments enable applets to become parts of truly distributed
applications.  With Netscape Communicator 4, a CORBA interface is available
for applets with the inclusion of the Visigenic ORB and the respective Java
interface. The revision 1.1 of Java introduced a standardized way of
communication amongst distributed Java objects, the Remote Method Invocation
API.

Similar to PageSpace, both enable truly distributed applications, either in
an open CORBA world, or within the Java paradigm. In contrast to PageSpace,
both rely on client-server technology. PageSpace is different in the
characteristics of the coordination technology applied. The main specific
difference is that any remote invocation in CORBA or 
Java RMI is directed towards a
specific, existing object, whereas PageSpace employs undirected coordination
which is decoupled in space and time.

  Jada applets are similar to Oblets, or ``distributed active objects''
  \cite{BroNaj96}.  An \emph{oblet} is a program written in Obliq and executed
  on a Obliq-aware browser. 
  Each oblet can use high-level primitives to communicate with
  other oblets running on possibly remote browsers.
Instead of Obliq, Jada uses original, pure Java enhanced
with simple coordination primitives.

We know of two projects directly based on Linda-like coordination:
Bauhaus and JavaSpaces.

The Bauhaus ``Turingware Web'' \cite{CGH97} designed in Yale University, the
homeland of Linda, is similar at least in spirit to the WU Linda toolkit.  The
main idea consists of using a standard browser to access a Bauhaus server.
Bauhaus is a coordination language based on nested multiple tuplespaces which
can be used in this case for both controlling the hierarchical structure of
the pages of a web site, and for associating agents and their activities to
the pages themselves.  For instance, one attribute of a page could be the list
of users ``acting'' in such a page, who are displayed by a graphic icon and
can interact using some ad-hoc cooperation services.

Sun has announced but at moment not yet released
JavaSpaces, a Java library which uses Linda-like
coordination for supporting distributed applications \cite{Wal97}. It
focuses on transactional Linda operations and is intended as a platform to
provide distributed persistence for exchangeable objects.

Both systems are within the same line of research as PageSpace, combining
coordination technology and the Web. However, both focus on single issues.
The Bauhaus approach is possibly less general,
insofar as it redefines the basic WWW software architecture.
Instead,
JavaSpaces is advertised as a layer added on top of Java allowing for simple
programming of applications which require transactional operations.
In contrast,
PageSpace is a reference architecture based on coordination technology
which defines a multiagent WWW
infrastructure for coordination-based applications.

\section{Conclusion}
\label{sec:conc}

The PageSpace integrates three basic building blocks:

{\em Web technology}, which provides a uniform communication and
presentation platform:
standard (Java-enabled) browsers are used to access the PageSpace.

{\em Java technology}, which provides a uniform host language.
PageSpace enhances Java with a high level
coordination support for distributed agents.

{\em Linda-like coordination technology}, which provides a simple
tool to describe and control activities of asynchronous
agents.

We remark that the idea 
of coordination has been subject to a large variety of
research projects, focusing on parallel or distributed
coordination architectures, 
on theoretical foundations of coordination languages, 
and on a number of implementation oriented research efforts concerning the
embedding of coordination models 
into practical programming platforms.
We have shown that 
combining Linda-like coordination with Java
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. 

More information on PageSpace can be found on the Web at
\pathsl|http://www.cs.tu-berlin.de/~pagespc|.

\section*{Acknowledgments}

PageSpace has been supported by the EU as ESPRIT Open LTR project \#20179.
We thanks for their comments the anonymous referees.

\bibliographystyle{ieeebib}

\bibliography{biblio}

\begin{biography}{Paolo Ciancarini}
  is Associate Professor of Computer Science at the Univ. of Bologna.
  He got a PhD in Computer Science from the University of Pisa in 1988. 
  His research interests include: 
  coordination languages and systems, 
  programming systems based on distributed objects, 
  and formal methods in software engineering.  
  He has been a member of ESPRIT BRA Project COORDINATION on
  Coordination models and languages, a co-proponent of the PageSpace Open
  LTR project, and a member of the ESPRIT Working Group Coordina
  ``From Coordination Models to Applications''.
\end{biography}

\begin{biography}{Robert Tolksdorf}
  is Assistant Professor at the study group Formal models, Logic and
  Programming at the Technical University of Berlin, Department for Computer
  Science. He received his Dr.-Ing.\ in Computer Science from the TU Berlin in
  1995.  His research interests include coordination languages, open
  distributed systems, and Web-technology. He is one of the main proponents
  and responsible for the coordinating TU Berlin site of the ESPRIT Open LTR
  project 20179 PageSpace on coordination in distributed WWW applications. He
  is a member of the ESPRIT Working Group Coordina ``From Coordination Models
  to Applications''.
\end{biography}


\begin{biography}{Fabio Vitali}
 is Research Associate of Computer Science at the Univ. of Bologna.  
 He received a PhD in Computer Science and Law
 from the University of Bologna in 1994.
 His interests include user interface design,
 hypertext models, markup languages,
 versioning systems, and coordination languages.
\end{biography}

\begin{biography}{Davide Rossi}
 is a PhD candidate in Computer Science at the Univ. of Bologna.
 His interests include object-oriented programming,
 operating systems design,
 coordination languages, mobile agents, and compression algorithms
 for graphic formats
 (he cooperated to the design of one of the early packages
 for JPEG compression).
\end{biography}

\begin{biography}{Andreas Knoche}
  worked in the PageSpace Open LTR project at the TU Berlin as a research
  assistant. He now is with the KIT-ZVLB project at TU Berlin which builds a
  VRML based information system. His research interests include coordination
  languages, open distributed systems, and Web-technology.
\end{biography}

\end{document}