%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% ReSpecT Documentation
% A. Omicini 4/8/2008
% M. Casadei 5/4/08
% excerpt from
% TuCSoN Documentation %
% A.Ricci, 5/4/01 %
% E.Denti, 31/5/01 %
% A.Ricci, 10/01 %
% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[11pt]{report}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\textwidth 6.8 in % Width of text line.
\textheight 9.4 in
\oddsidemargin -0.1 in % Left margin on odd-numbered pages.
\evensidemargin -0.1 in % Left margin on even-numbered pages.
\topmargin -0.2 in
\headheight 0 in % Width of marginal notes.
\headsep 0 in
\topskip 0 in
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newif\ifpdf
\ifx\pdfoutput\undefined
\pdffalse % we are not running PDFLaTeX
\else
\pdfoutput=1 % we are running PDFLaTeX
\pdftrue
\fi
%%%%%%%%%%%%%%%
\ifpdf
\usepackage[pdftex]{graphicx}
\else
\usepackage{graphicx}
\fi
%%%%%%%%%%%%%%%
\ifpdf
\DeclareGraphicsExtensions{.pdf, .jpg, .tif}
\else
\DeclareGraphicsExtensions{.eps, .jpg}
\fi
%%%%%%%%%%%%%%%
%\usepackage{times}
\newcommand\xa[1]{\appendixname~\ref{app:#1}}
\newcommand\labelsec[1]{\label{sec:#1}}
\newcommand\xs[1]{\sectionname~\ref{sec:#1}}
\newcommand\xsp[1]{\sectionname~\ref{sec:#1} \onpagename~\pageref{sec:#1}}
\newcommand\labelssec[1]{\label{ssec:#1}}
\newcommand\xss[1]{\subsectionname~\ref{ssec:#1}}
\newcommand\xssp[1]{\subsectionname~\ref{ssec:#1} \onpagename~\pageref{ssec:#1}}
\newcommand\labelsssec[1]{\label{sssec:#1}}
\newcommand\xsss[1]{\subsectionname~\ref{sssec:#1}}
\newcommand\xsssp[1]{\subsectionname~\ref{sssec:#1} \onpagename~\pageref{sssec:#1}}
\newcommand\labelfig[1]{\label{fig:#1}}
\newcommand\xf[1]{\figurename~\ref{fig:#1}}
\newcommand\xff[2]{\figurenames~\ref{fig:#1}~and~\ref{fig:#2}}
\newcommand\xfp[1]{\figurename~\ref{fig:#1} \onpagename~\pageref{fig:#1}}
\newcommand\labeltab[1]{\label{tb:#1}}
\newcommand\xt[1]{\tablename~\ref{tb:#1}}
\newcommand\xtt[2]{\tablenames~\ref{tb:#1}~and~\ref{ab:#2}}
\newcommand\xtp[1]{\tablename~\ref{tb:#1} \onpagename~\pageref{tb:#1}}
\newcommand\labelenum[1]{\label{enum:#1}}
\newcommand\xen[1]{(\ref{enum:#1})}
\newcommand\xenp[1]{(\ref{enum:#1}) \onpagename~\pageref{enum:#1}}
\newcommand{\code}[1]{\texttt{\small{#1}}}
%******************************************************************************%
\newcommand{\LIA}{\mbox{\textsf{LIA}}}
\newcommand{\aclt}{\mbox{$\mathcal{ACLT}$}}
\newcommand{\respect}{\mbox{\sf{{R}e{S}pec{T}}}}
\newcommand{\luce}{\mbox{\sf{{L}u{C}e}}}
\newcommand{\tucson}{\mbox{\sf{{T}u{CS}o{N}}}}
\newcommand{\soda}{\mbox{\sf{{SODA}}}}
\newcommand{\alice}{\mbox{\sf{{aliCE}}}}
\newcommand{\tuprolog}{\mbox{{\sf{tu}}Prolog}}
%******************************************************************************%
\newcommand{\respectversion}{1.0.0}
\newcommand\ttit[1]{\texttt{\textit{#1}}}
\newcommand\version[1]{\mbox{Document revision: #1}}
\newcommand\approvedby[1]{\mbox{Approved by: #1}}
\newcommand\receivedby[1]{\mbox{Received by: #1}}
\newcommand\creationdate[1]{\mbox{Creation date: #1}}
\newcommand\lastchangesdate[1]{\mbox{Last Changes date: #1}}
\newcommand\noa[2]{\noindent\emph{Note of the author (#1): }#2\\\\}
\newcommand\logo{
\begin{figure}[tp]
\begin{center}
\includegraphics[width=4cm]{./shared/logo}
\end{center}
\end{figure}
}
%******************************************************************************
%
\title{{\huge{\bf{\respect{} Guide\\\mbox{ }\\}}}
\respect{} version: \respectversion{}\\\mbox{ }\\
{\small{
\version{001}\\
\creationdate{2008-04-05}\\
\lastchangesdate{2008-04-05}\\
% \receivedby{aricci}\\
% \approvedby{aricci}\\
}}
}
\author{ \mbox{ }\\DEIS, Universit\`{a} di Bologna, Italy\\
Sede di Cesena (FC)\\
Sede di Bologna (BO)\\
}
\date{}
\begin{document}
\logo
\maketitle
\sloppy
\tableofcontents
\part{\respect{} Basics}
%=======================================================================
\chapter{Introduction}\label{cp:intro}
%=======================================================================
\respect{} (\textsf{Re}action \textsf{Spec}ification \textsf{T}uples\footnote{The \respect{} technology is available as an open source project from the \respect{} web site \cite{respect-home}}) is a logic-based language for MAS coordination \cite{respect-scico2001}.
%
\respect{} is based on a coordination model providing \emph{tuple centres} as first-class abstractions to design and develop general-purpose coordination media.
%
The behaviour of \respect{} tuple centres is programmed through the \respect{} first-order logic language.
%
A tuple centre is a tuple space enhanced with the possibility to program its behaviour in response to interactions.
%
So, first of all, agents can operate on a \respect{} tuple centre in the same way as on a Linda tuple space \cite{linda}: by exchanging \emph{tuples} (which are ordered collection of knowledge chunks) through a simple set of coordination primitive.
%
An agent can write a tuple in a tuple centre with an \code{out} primitive; or read a tuple from a tuple centre with primitives such as \code{in}, \code{rd}, \code{inp}, \code{rdp} specifying a \emph{tuple template}---that is, an identifier for a set of tuples, according to some \emph{tuple matching} mechanism.
%
Reading tuples can be destructive (\code{in}, \code{inp} remove the matching tuple) or non-destructive (\code{rd}, \code{rdp} simply read the matching tuple), suspensive (\code{in}, \code{rd} wait until a matching tuple is found) or non-suspensive (\code{inp}, \code{rdp} immediately return either the matching tuple or a failure result)---but is anyway non-deterministic: when more than one tuple in a tuple centre are found that match a tuple template, one is non-deterministically chosen among them.
Accordingly, a tuple centre enjoys all the many features of a tuple space, which can be classified along three different dimensions: generative communication, associative access, and suspensive semantics.
%
The main features of generative communication (where information generated has an independent life with respect to the generator) are the forms of uncoupling (space, time, name) based on mediated interaction: sender and receiver do not need to know each other, to coexist in the same space or at the same time in order to communicate (to exchange a tuple, in particular).
%
Associative access (access based on structure and content of information exchanged, rather than on location, or on name) based on tuple matching promotes synchronisation based on tuple structure and content: thus, coordination is data-driven, and allows for knowledge-based coordination patterns.
%
Suspensive semantics promotes coordination patterns based on knowledge availability, and couples well with incomplete or partial knowledge.
%
A tuple centre is a programmable tuple space---thus adding programmability of the coordination medium as a new dimension of coordination.
%
While the behaviour of a tuple space in response to interaction events is fixed (so, the effects of coordination primitives is fixed), the behaviour of a tuple centre can be tailored to the application needs by defining a set of specification tuples, or reactions, which determine how a tuple centre should react to incoming / outgoing events.
%
% ReSpecT
%
While the basic tuple centre model is not bound to any specific language to define reactions \cite{respect-scico2001}, \respect{} tuple centres are obviously programmed through the \respect{} logic-based specification language.
%
%-------------------------------------------------------------------------------
%\subsection{\respect{} as a Core Coordination Language}
%\labelssec{respect-lang}
%-------------------------------------------------------------------------------
The original \respect{} \cite{respect-entcs48} is a logic-based language for the specification of the behaviour of tuple centre.
%
As a behaviour specification language, \respect{}:
%
\begin{itemize}
%
\item enables the definition of computations within a tuple centre, called \emph{reactions}, and
%
\item makes it possible to associate reactions to events occurring in a tuple centre.
%
\end{itemize}
%
So, \respect{} has both a declarative and a procedural part.
%
As a \emph{specification language}, it allows events to be declaratively associated to reactions by means of specific logic tuples, called \emph{specification tuples}, whose form is \texttt{reaction(\emph{E},\emph{R})}.
%
In short, given a event \emph{Ev}, a specification tuple \texttt{reaction(\emph{E},\emph{R})} associates a reaction \texttt{\emph{R$\theta$}} to \emph{Ev} if \emph{$\theta$ = mgu(\texttt{E},Ev)}.\footnote{\emph{mgu} is the most general unifier, as defined in logic programming.}
%
As a reaction language, \respect{} enables reactions to be procedurally defined in terms of sequences of logic reaction goals, each one either succeeding or failing.
%
A reaction as a whole succeeds if all its reaction goals succeed, and fails otherwise. Each reaction is executed sequentially with a transactional semantics: so, a failed reaction has no effect on the state of a logic tuple centre.
All the reactions triggered by an event are executed before serving any other event: so, agents perceive the result of serving the event and executing all the associated reactions altogether as a single transition of the tuple centre state.
%
As a result, the effect of a coordination primitive on a logic tuple centre can be made as complex as needed by the coordination requirements of a system.
%
Generally speaking, since \respect{} has been shown to be Turing-equivalent \cite{respect-sac98}, any computable coordination law could be in principle encapsulated into a \respect{} tuple centre.
%
This is why \respect{} can be assumed as a general-purpose core language for coordination: a language that could then be used to represent and enact policies and rules for coordination systems of any sort.
Adopting the declarative interpretation of logic tuples, a \respect{} tuple centre has then a twofold nature \cite{respect-entcs48}: a theory of communication (the set of the ordinary tuples) and a theory of coordination (the set of the specification tuples).
%
This allows in principle intelligent agents to reason about the state of collaboration activities, and to possibly affect their dynamics.
%
Furthermore, the twofold interpretation of \respect{} specification tuples (either declarative or procedural) allows knowledge and control to be represented uniformly (as Prolog-like facts) and encapsulated within the same coordination artifact.
%=======================================================================
\chapter{Getting started}
%=======================================================================
TO BE DONE
%=======================================================================
\chapter{\respect{} IDE}
%=======================================================================
%-----------------------------------------------------------------------
\section{The \texttt{CLIAgent} tool}
%-----------------------------------------------------------------------
TO BE WRITTEN DOWN
%The \respect{} \texttt{CLIAgent} tool allows users to invoke the
%commands of the \respect{} coordination language, which are of the
%general form:
%%
%\begin{center}
% \texttt{\textit{TCName} @ \textit{TCAddress} ?~\textit{op}(\textit{Tuple})}
%\end{center}
%%
%where:
%%
%\begin{itemize}
% \item \textit{TCName} is the tuple centre name: any string may be used,
% including strings with spaces (in that case enclosed by apices).
% So, \texttt{room}, \texttt{'Multimedia'},
% \texttt{team05}, \texttt{'my documents'}, for instance, are all
% valid tuple centre names.
% %
% \item \textit{TCAddress} is the tuple centre address: it must be a valid
% host name or IP address --- represented as logic term ---, such as \texttt{'deis.unibo.it'},
% \texttt{'192.0.0.3'},or \texttt{myHost}.
% %
% \item \textit{op} is the operation to be performed: see Table~\ref{operations}
% for a short reference on allowed operations.
% %
% \item \textit{Tuple} is the information content involved in the operation: it
% must be a valid logic tuple or tuple template (that is, roughly speaking,
% a Prolog term). Examples include \texttt{pippo(1)},
% \texttt{authors(['Bukowski','Joyce'])},
% \texttt{pippo(X)},
% \texttt{writer(name('Charles'),surname('Bukowski'))},
% etc.
%\end{itemize}
%\noindent A key feature of the \tucson{} model is to provide a twofold view
%of the coordination space, which can be seen both as a \textit{global
%resource} and as a \textit{local resource}.
%%
%As a global resource, a tuple centre is available from anywhere on the
%network, by explicitly specifying its name and address, as above.
%%
%As a local resource, instead, a tuple centre is referenced simply by name,
%since the implicit address is the address of the local node.
%%
%In this case, operation commands assume the simplified form:
%%
%\begin{center}
% \texttt{\textit{TCName} ?~\textit{op}(\textit{Tuple})}
%\end{center}
%\noindent Moreover, in order to provide an easy-to-use support for simple
%coordination needs, \tucson{} defines a \textit{default tuple centre} for
%each node, which is called \texttt{default}: if the tuple centre name is
%omitted, like in the case below, the default tuple centre is assumed:
%%
%\begin{center}
% \texttt{\textit{op}(\textit{Tuple})}
%\end{center}
%
%\noindent Let us see some examples:
%\begin{itemize}
% \item \texttt{table @ 'deis.unibo.it' ?~out(chops(1,2))}\\
% \begin{small}
% Outputs tuple \texttt{chops(1,2)} into the tuple centre
% \texttt{table} of node \texttt{deis.unibo.it}.
% \end{small}
% %
% \item \texttt{docs ?~out(article(title('TuCSoN'),authors(['Bukowski','Joyce'])))}\\
% \begin{small}
% Outputs tuple \texttt{article(title(\ldots),authors(\ldots))} into tuple centre
% \texttt{docs} of the local node.
% \end{small}
% %
% \item \texttt{'my docs' ?~rdp(p(First,Second))}\\
% \begin{small}
% Checks for the presence of a tuple matching the template \texttt{p(First,Second)}
% in tuple centre \texttt{my docs} of the local node.
% \end{small}
% %
% \item \texttt{docs @ '192.0.0.3' ?~in(article(title(X),authors([Y,'Joyce'])))}\\
% \begin{small}
% Removes a tuple matching the template \texttt{article(title(\ldots),authors(\ldots))}
% from tuple centre \texttt{docs} of the node denoted by the IP
% address 192.0.0.3.
% \end{small}
% %
% \item \texttt{set\_spec('reaction(in(p(X)), (pre, out\_r(p(1)))).')}\\
% \begin{small}
% Adds the specification tuple \texttt{reaction(\ldots)} to the
% default tuple centre of the local node.
% \end{small}
% %
% \item \texttt{lab00 @ '137.204.191.21' ?~set\_spec('reaction(out(X),(out\_r(copy(X)))).')}\\
% \begin{small}
% Adds the specification tuple \texttt{reaction(\ldots)} to the tuple centre
% \texttt{lab00} of the node denoted by the IP address 137.204.191.21.
% \end{small}
% %
% \item \texttt{default @ localhost ?~get\_spec(Spec)}\\
% \begin{small}
% Gets a specification tuple from the default tuple centre of the
% local node.
% \end{small}
% %
% \item \texttt{in(p(X,1))}\\
% \begin{small}
% Removes a tuple matching the template \texttt{p(X,1)} from the default tuple
% centre of the local node.
% \end{small}
%\end{itemize}
%\noindent The command \texttt{quit} can be used to exit the
%interpreter.
%\begin{table}
% \begin{tabular}{p{5cm}|p{10.5cm}}\hline\hline\\
% \textsf{out} & to put the specified tuple in the specified tuple
% centre \\\\\hline\\
% \textsf{in} & to remove a tuple matching the specified tuple template from
% the specified tuple centre\\\\\hline\\
% \textsf{rd} & to read a tuple matching the specified tuple template from
% the specified tuple centre\\\\\hline\\
% \textsf{inp} & to remove, if present, a tuple matching the specified tuple template from
% the specified tuple centre (if not present the operation fails)\\\\\hline\\
% \textsf{rdp} & to read, if present, a tuple matching the specified tuple template from
% the specified tuple centre (if not present the operation fails)\\\\\hline\\
% \textsf{set\_spec} & to set the behaviour of the specified tuple centre; tuple
% must be a valid ReSpecT program, in the form of a text (understood as a string atom) or list of
% reaction\\\\\hline\\
% \textsf{get\_spec} & to get current behaviour of the specified tuple centre\\\\\hline\hline
% \end{tabular}
% %
% \caption{\label{operations}\tucson{} operations}
%\end{table}
%-----------------------------------------------------------------------
\section{The \texttt{Inspector} tool}
%-----------------------------------------------------------------------
TO BE DEVELOPED: MAYBE BY A THESIS?
%-----------------------------------------------------------------------
%\section{Other tools}
%-----------------------------------------------------------------------
%-------------------------------
%\subsection{The SpecEditor tool}
%-------------------------------
%-------------------------------
%\subsection{SetSpec}
%-------------------------------
%-------------------------------
%\subsection{Keeper}
%-------------------------------
%=======================================================================
\chapter{\respect{} API for \respect{} Tuple Centres from Java Agents}
%=======================================================================
%\tucson{} has an application programming interface, which allows
%to exploit the service from applications written in Java and in
%\tuprolog{} (our Prolog environment).
%%
%In order to access the \tucson{} infrastructure, an \emph{agent
%coordination context}(ACC) \cite{ctx-ubiquitous} must be first
%acquired.
%%
%An ACC represents a sort of interface that an agent must have
%in order to invoke coordination primitives on tuple centres
%belonging to an organisation, living on \tucson{}.
%%
%In the full-fledged version of the ACC (available only in \tucson{} 2.0.0),
%the ACC defines defines what actions are allowed or better
%what actions are forbidden to an agents, by virtue of the roles
%the agent is playing inside the organisation.
%%
%In this version of \tucson{} an ACC -- represented by objects
%implementing the \texttt{TucsonContext} interface -- can be obtained by calling
%one of the \texttt{enterContext} static methods of the class \texttt{Tucson}.
%%
%The method results in an ACC object which the agent can
%exploit to interact with tuple centres.
%-----------------------------------------------------------------------
\section{Accessing \respect{} from Java}
%-----------------------------------------------------------------------
\part{\respect{} Advanced}
%=======================================================================
\chapter{Programming Tuple Centre Behaviour}
\label{respect}
%=======================================================================
As pointed out in Chapter \ref{cp:intro}, tuple centres are programmable tuple spaces whose
%
behaviour can be programmed by using \respect{} as a logic-based coordination language to define the coordination laws ruling agent interaction.
%
%--------------------------------------------------------------------------------
\section{The \respect{} Language}
%--------------------------------------------------------------------------------
%
% SPEC DESCR
%
A \respect{} program takes the form of a set of \textit{reactions}:\\\\
%
\texttt{reaction(\textit{Event}, ( \textit{Body} )).}\\\\%
%
\texttt{\textit{Event}} is an extended communication event, including the execution
of basic coordination primitives (\texttt{out}, \texttt{in}, \texttt{rd}, \texttt{inp}, \texttt{rdp}),
and the successful execution of some \respect{} primitives (\texttt{out\_r}, \texttt{in\_r}, \texttt{rd\_r},
\texttt{no\_r}) which will be described in the following.
%
\texttt{\textit{Body}} is a sequence of \respect{} predicates. The main predicates are listed in the \xt{respect-semantics}\xt{respect-semantics-1}: basically, they make it possible to inspect and change the content of the tuple set, by inserting / retrieving / reading associatively tuples.
%
Also some basic Prolog predicate / builtin functors are available, mainly for making easier the manipulation of symbols and numbers, and their comparison.
%
The full syntax of \respect{} is described in \xt{respect-syntax}, while the informal semantics of the main predicates is described in \xt{respect-semantics}.
Whenever an event occurs inside a tuple centre -- for instance caused by the invocation of a coordination primitive by an agent -- the set of reactions triggered by the event is collected and then the body of each reaction is executed.
%
Reactions are executed one by one, sequentially.
%
The order of execution is non-deterministic.
%
Actuallty reactions on \texttt{in} and \texttt{rd} events are triggered two times:
%
the first time when the coordination primitive is issued by the agent \UTF{00A0}(called \emph{pre} stage), and when eventually a result (a tuple) is sent back to the agent making the request (called \emph{post} stage).
%
For details see the paper \cite{respect-entcs48}.
%
%
%
\begin{table}[tp]
%
\begin{center}{\tt{\small{
\begin{tabular}{p{14cm}}\hline\\\\
\emph{Spec} ::= \emph{Reaction*}\\
%
\emph{Reaction} ::= reaction( \emph{Event}, ( \emph{Body} ) ).\\
%
\emph{Event} ::= \emph{CommunicationEvent} | \emph{InternalEvent} \\
%
\emph{CommunicationEvent} ::= \\
%
\mbox{~~~~~~~~~~~~~~}out(\emph{T}) | in(\emph{TT}) | rd(\emph{TT}) | rdp(\emph{TT}) | inp(\emph{TT})\\
%
\emph{InternalEvent} ::= \\
\mbox{~~~~~~~~~~~~~~}out\_r(\emph{T}) | in\_r(\emph{TT}) | rd\_r(\emph{TT}) \\
%
\emph{Body} ::= \emph{Predicate}\{, \emph{Body}\} \\
%
\emph{Predicate} ::= \emph{BasicPredicate} | \emph{ExtendedPredicate} \\
%
\emph{BasicPredicate} ::= \\
\mbox{~~~~~~~~~~~~~~}out\_r(\emph{T}) | in\_r(\emph{T}) | rd\_r(\emph{TT}) | no\_r(\emph{TT}) | \\
\mbox{~~~~~~~~~~~~~~}pre | post | \\
\mbox{~~~~~~~~~~~~~~}current\_tuple(\emph{TT}) | current\_agent(\emph{TT}) |
current\_op(\emph{TT}) | \\
\mbox{~~~~~~~~~~~~~~}current\_tc(\emph{TT}) \\
%
\emph{ExtendedPredicate} ::= \\
\mbox{~~~~~~~~~~~~~~}\emph{X} is \emph{Expression} | \\
\mbox{~~~~~~~~~~~~~~}\emph{BooleanExpression} | \\
\mbox{~~~~~~~~~~~~~~}out\_tc(\emph{TC},\emph{T}) | \\
\mbox{~~~~~~~~~~~~~~}spawn(\emph{AgentId},\emph{AgentType},[ \{ \emph{ArgList} \} ] ) | \\
\mbox{~~~~~~~~~~~~~~}current\_time(\emph{TT}) \\
%
\emph{Expression} ::= \emph{ArtimeticExpression} \\
%
\emph{BooleanExpression} ::= \emph{ArtimeticComparison} \\
%
\emph{AgentType} ::= java(\emph{AgentClassName}) | prolog(\emph{TheoryFileName}) \\
%
\emph{ArgList} ::= \emph{T} \{ , \emph{ArgList} \} \\\\
\hline
\end{tabular}
}}}\end{center}
\caption{\respect{} Syntax}
\labeltab{respect-syntax}
\end{table}
%
% descrizione primitive
%
\begin{table}[th]
\begin{center}{{\small{
\begin{tabular}{p{5cm}|p{10.5cm}}\hline\hline\\
%
\textsf{out\_r(T)} & always succeed and as effect the logic tuple T is inserted in the tuple set \\\\\hline\\
%
\textsf{in\_r(TT)} & succeed if a logic tuple matching the template TT is present in the tuple set, and as effect the tuple is removed and unified with TT. Otherwise the predicate fails. \\\\\hline\\
%
\textsf{rd\_r(TT)} & succeed if a logic tuple matching the template TT is present in the tuple set, and as effect the tuple is unified with TT. Otherwise the predicate fails.\\\\\hline\\
%
\textsf{no\_r(TT)} & succeed if no logic tuple matching the template TT is present in the tuple set, otherwise the predicate fails.\\\\\hline\\
%
%
\textsf{pre} & succeed if the event triggering the reaction is a request (\texttt{in} or \texttt{rd}) in the \emph{pre} stage, i.e. just requested by the agent.\\\\\hline\\
%
\textsf{post} & succeed if the event triggering the reaction is a request (\texttt{in} or \texttt{rd}) in the \emph{post} stage, i.e. providing the result to the requesting agent.\\\\\hline\\
%
\textsf{success} & succeed if the event triggering the reaction is a successful \texttt{inp} or \texttt{rdp} \\\\\hline\\
%
\textsf{failure} & succeed if the event triggering the reaction is non successful \texttt{inp} or \texttt{rdp}\\\\\hline\\
%
\textsf{current\_agent(TT)} & succeed if \texttt{TT} unifies with a logic tuple denoting the identity of the agent responsible of the communication event which generated the reaction \\\\\hline
%
\hline
%
\end{tabular}
}}}\end{center}
%
\caption{\labeltab{respect-semantics}\respect{} primitives semantics}
\end{table}
%
% descrizione primitive
%
\begin{table}[th]
\begin{center}{{\small{
\begin{tabular}{p{5.5cm}|p{10cm}}\hline\hline\\
%
\textsf{current\_tuple(TT)} & succeed if \texttt{TT} unifies with current logic tuple specified in the event triggering the reaction \\\\\hline\\
%
\textsf{current\_tc(TT)} & succeed if \texttt{TT} unifies with a logic tuple denoting the name of current tuple centre \\\\\hline\\
%
\textsf{current\_time(TT)} & succeed if \texttt{TT} unifies with a logic tuple denoting current tuple centre virtual machine time \\\\\hline\\
%
\textsf{out\_tc(TC,T)} & succeed if \texttt{TC} is a valid and reachable tuple centre name (which can reside on a different node). The primitive has the same effect (and also is modelled as) an out operation on the specified tuple centre: the tuple \texttt{T} is inserted in the tuple centre \texttt{TC}, \\\\\hline\\
%
\textsf{spawn(AgentID,AgentType,ArgList)} & succeed if \texttt{AgentID} is a valid agent identifier, \texttt{AgentType} denotes a valid agent types and \texttt{ArgList} is a list of tuples.
%
The primitive has the effect of spawning a new agent with the specified characteristics, passing some booting arguments.
%
Currently, \texttt{AgentType} can be \texttt{java(\textit{ClassName})} or \texttt{prolog(\textit{FileName})}: in the former case, the agent is a Java agent, as an instance of the specified class (which must be found in \tucson{} class path).
%
In the latter case, the agent is a Prolog agent, whose theory is described in the specified file (which must be present in the file systems).
%
\\\\\hline\hline
\end{tabular}
}}}\end{center}
%
\caption{\labeltab{respect-semantics-1}\respect{} primitives semantics (cont.)}
\end{table}
%
%
%
A simple example of reaction is:
\begin{verbatim}
reaction(out(p(X)),(
out_r(backup(p(X))) )).
\end{verbatim}
%
%
In this example, whenever a tuple matching the template p(X) is inserted in the tuple centre, another tuple backup(p(X)) is created.
Another example is:
\begin{verbatim}
reaction(out(X),(
in_r(n_tuples(N)),
N1 is N + 1,
out_r(n_tuples(N1)))).
reaction(in(X),(
in_r(n_tuples(N)),
N1 is N - 1,
out_r(n_tuples(N1)))).
reaction(inp(X),(
in_r(n_tuples(N)),
N1 is N - 1,
out_r(n_tuples(N1)))).
\end{verbatim}
%
Here you want to keep track of the number of tuples inside the tuple centre, by means of the tuple \texttt{n\_tuple(N)}.
%
So whenever a tuple is inserted or removed, this tuple is updated (by removing and inserting a new tuple).
%
% ATOMICITY
%
The execution of a predicate can be successful or can fail:
%
an example of a failure is when trying to retrieve a tuple by means of an \texttt{in\_r} and no tuples matching the request are found.
%
In this case the reaction is aborted \emph{atomically}, i.e. every change apported to the tuple set by the invocation of predicate belonging to the body of the reaction is undone;
%
in other words, the content of the tuple set is reset to the state it had before reaction execution.
%
%
%
Reactions can be triggered also by the successful execution of some \respect{} predicates:
%
\texttt{out\_r, in\_r, rd\_r}.
%
When the predicates is executed with success, the list of triggered reactions is collected and added to the set of the reactions whose execution is pending.
%
If a reaction fails, also all the reactions triggered by the successful execution of the predicates of the reaction are cancelled.
%
\section{Coordination as computations on the interaction space}
\respect{} is a Turing equivalent language, i.e. \emph{any} possible computable function / algorithm can be coded in terms of a \respect{} specification (see \cite{respect-sac98} for a demonstration).
%
The tuple set is the data structure acting as input / output of \respect{} computations:
%
the fact that the language is Turing-equivalent means that given any couple of tuple set configurations \emph{C} and \emph{C'} it is possible to write a \respect{} program transforming \emph{C} in \emph{C'}.
%
Interactions enabled by a tuple centre
The fact that this is sufficient for creating any coordination algorithms manipulating interactions can be understood then by realising that any interactions enabled by the tuple centre can be \emph{reified} as tuples in the set, which can be manipulated by \respect{} specification.
%
As an example, consider the following code:
%
\begin{verbatim}
reaction(in(p(X)),(
pre,
no_r(p(X)),
out_r(tuple_request(p(X))) )).
\end{verbatim}
%
In this case we reify the request of a tuple (matching the template \texttt{p(X)}) currently not present in the tuple set by inserting a new tuple \texttt{tuple\_requested(p(X))}.
%
%
%
So, the tuple set then can be adopted as a space where to build and manipulate data structures, described in terms of structured tuples.
%
Reactions defines the algorithmic behaviour working on the data structures.
\subsection{Basic computation constructs in \respect{}: Selection, Iteration and Recursion}
The basic constructs which typically are adopted in developing algorithms can be realised in \respect{} by suitably composing reactions. Here we consider some basic ideas and idioms to realise selections, iterations and recursion.
\subsubsection{Selections}
Selection construct can be realised by a set of reactions with the same triggering event and containing in the first part of their body predicates succeeding on exclusive conditions, making it possible to have only one succeeding reaction at a time.
As a first simple example, suppose you want to do some operations A reacting to an event E, then to execute the operation block B or C according to the presence of a certain tuple T in the tuple set.
%
Then, a possible reaction schema can be the following:
%
\begin{verbatim}
reaction( E , (
A,
out_r(check(T)))).
reaction(out_r(check(T))),(
rd_r(T),
B )).
reaction(out_r(check(T))),(
no_r(T),
C )).
\end{verbatim}
%
% SELECTION (2)
%
As another example, suppose you want to insert a tuple \texttt{is\_greater(X,Y)} whenever a tuple \texttt{compare(X,Y)} is inserted in tuple centre if X is greater than Y, supposing that X and Y are both numbers;
%
viceversa a tuple \texttt{is\_less(X,Y)} if X is less than Y.
%
A set of reactions realising the behaviour is:
%
\begin{verbatim}
reaction(out(compare(X,Y)),(
X > Y,
out_r(is_greater(X,Y)) )).
reaction(out(compare(X,Y)),(
X < Y,
out_r(is_less(X,Y)) )).
\end{verbatim}
\subsubsection{Recursion and iterations}
Recursions in \respect{} consists in reactions triggering themselves, and it is the only means to realise iterations, suitably exploiting also selections.
%
In the following example a factorial number is computed:
%
\begin{verbatim}
reaction(out(factorial(N,_)),(
in_r(factorial(N,_)),
out_r(fact_loop(1,N,1)))).
reaction(out_r(fact_loop(N,N,F)),(
in_r(fact_loop(N,N,F)),
out_r(factorial(N,F)))).
reaction(out_r(fact_loop(I,N,F)),(
in_r(fact_loop(I,N,F)),
N > I,
I1 is I + 1,
F1 is F * I1,
out_r(fact_loop(I1,N,F1)))).
\end{verbatim}
%
%
The strategy consists in transforming a tuple \texttt{fact\_loop(I,N,F)} until a point in which the first two argument coincide: the first is the classic index ranging all the integer numbers included within 1 and N.
%
When the first two arguments coincide, then the third -- which is transformed along with the index -- contains the factorial number of the second argument.
%
The third reaction is recursive: it is triggered by an event (the insertion of a \texttt{fact\_loop}) which the reaction generates itself.
% \subsection{Structuring reactions}
% %\tbc{}
% \subsection{Forcing Sequence Reactions}
% %\tbc{}
\section{Common mistakes}
\subsection{Binding variables more than once}
\respect{} is a logic language, following Prolog rules for what concern variable management. In particular variables can be bound to a term only once: trying to bind variables multiple times causes the predicate to fail. For instance:
%
\begin{verbatim}
reaction( out(T),(
in_r(tuple_count(C)),
C is C + 1,
out_r(tuple_count(C))))
\end{verbatim}
%
The reaction is supposed to update a tuple \texttt{tuple\_count} keeping track of the number of tuples. The reaction fails since C is used twice. A correct version is:
%
\begin{verbatim}
reaction( out(T),(
in_r(tuple_count(C)),
C1 is C + 1,
out_r(tuple_count(C1))))
\end{verbatim}
%
%%\tbc{}
\part{Engineering systems with \respect{}}
%%=======================================================================
%\chapter{How to engineer systems: a Task-oriented approach}
%\label{methodology}
%%=======================================================================
%From a methodological point of view, engineering systems on top of \tucson{} involves basically the design and development of -- on the one side -- the computational parts (agents) and -- on the other side -- the coordination part (tuple centres protocols and behaviour).
%%
%Given the uncoupling property of the coordination model, the two parts can be designed and developed almost independently.
%%
%\tucson{} is an answer in particular for the coordination part.
%%
%For the purpose, \soda{} is a methodology that can be adopted as a guide for the analysis and the design of the system \cite{soda-aoseI}.
%
%%--------------------------------------------------------------------------------
%\section{Task-oriented engineering}
%%--------------------------------------------------------------------------------
%
%Thinking in terms of \textit{tasks} to be pursued, instead of control flows to
%be achieved, provides the appropriate abstraction level to capture and enforce
%the required separation of control among system components: in this context,
%tasks are the higher-level abstractions that drive the development of control
%flows, intended as lower-level mechanisms.
%%
%So, identifying the relevant tasks for a given goal intrinsically implies
%separating control between the components charged of such tasks, since the
%control logic for achieving a task is embedded within a single entity.
%%
%As a result, each agent interacts with the others only as much as its task
%needs to interact with the other tasks, thus also inherently decoupling
%software designers from each other.
%Since reducing the agents' need to interact with each other means reducing the
%mutual dependencies among tasks (which is precisely what needs to be
%coordinated), this approach reduces the need to coordinate control among
%components.
%%
%So, a software engineering methodology providing encapsulation of control, and
%identifying independent autonomous components, promotes precisely the
%concurrent application of the different engineering stages required by CSE.
%From the viewpoint of teamwork organisation, the task metaphor allows a
%software team to design an interactive system by first identifying the required
%tasks, and then introducing as many components as needed to carry out such
%tasks.
%%
%Interestingly, this is well adequate to the cases where the same person is in
%charge of designing and implementing several components: in fact, thinking of
%tasks instead of control flows (such as which object methods to call, which
%signals to send, etc.) provides precisely the design flexibility that is
%fundamental for an effective project management.
%%
%The task metaphor granularity is also adequate to support a quick
%re-arrangement of the development process if the team composition changes over
%time: a new member can be given one or more (extra) tasks, while the tasks of a
%leaving member can be re-assigned to the other people in the team in much a
%simpler way than sharing and understanding other people's code libraries,
%objects, etc.
%%
%Again, this situation promotes the CSE approach, since the same task can be
%subject of the concurrent and coordinated work of multiple designers,
%developers and testers.
%However, defining and assigning the single tasks to components is only a part
%of the job: the key issue is how to \emph{design the ``glue''} so that they
%actually behave as an \emph{ensemble}.
%%
%This is where engineering issues come out.
%%
%If tasks and components were the only relevant entities, the system would be
%nothing more than the mere sum of its parts -- a multitude of individuals --
%and interaction, merely rhyming communication, would be just the result of the
%random interleaving of the observable component behaviour.
%But in complex systems, some tasks inevitably need to access distributed and
%shared resources, involving several components: that is, they naturally endorse
%a \emph{social} nature.
%%
%Such \emph{social tasks} cannot, by definition, be assigned to the
%responsibility of an individual component: instead, their accomplishment
%requires an approach to system analysis, design, and development that
%recognises interaction as a fundamental dimension, to be accounted for since
%the earliest design phases.
%%
%Thus, suitably engineering interaction becomes a crucial ability to be able to
%engineer the collective system behaviour.
%%
%This is perhaps why the design of complex, interactive applications has long
%been considered out-of-reach for small design teams, while this is only the
%superficial effect of neglecting the role of interaction -- governing the
%social tasks and rules.
%
%%--------------------------------------------------------------------------------
%\section{Design and development of coordination in \tucson{}}
%%--------------------------------------------------------------------------------
%\tucson{} is focused on the design, development and runtime management of the social tasks, i.e. the coordination part of the system.
%%
%The design of this parts involves essentially:
%%
%\begin{itemize}
%%
%\item \emph{Tuple centre cardinality and location} -- establishing how many and what tuple centres to use, and their location in terms of nodes.
%%
%Different strategies can be adopted, ranging from adopting a single tuple centres for enabling and governing any agent interaction, to adopting a tuple centre for each agent of the systems, acting as its private message box.
%%
%Typically, you need a tuple centre for each coordination task and adopt distinct tuple centres for supporting independent coordination tasks.
%%
%As general rules,
%%
%\emph{(i)} you can introduce \emph{a} tuple centre whenever there are dependencies (interactions) among agents you want to capture and manage; in other words:
%%
%\emph{(ii)} you can introduce \emph{a} tuple centre whenever you need a \emph{coordination artifact} to support a set of agents in achieving a shared goal, to support their cooperative work;
%%
%\item \emph{Tuple-based protocols} -- establishing the format of the tuples used and exchanged, and the related protocols, specifying the sequence of insertion / removal / reading of the tuples to/from the tuple centres;
%%
%\item \emph{Tuple centre coordinating behaviour } -- programming the behaviour of the tuple centre(s) in order to realise the coordination policies / laws which characterise the social tasks.
%%
%\end{itemize}
%%
%%
%The programming of the tuple centres can be avoided, defining all the coordination in terms of tuple based protocols (as it would happen in tuple space coordination models).
%%
%The need of exploiting tuple centre programming emerge soon however when engineering complex systems, in order to get engineering properties concerning encapsulation, modularity, robustness with respect to open systems, dynamism support.
%%
%For a more detailed explanation of the steps to be adopted when engineering a systems with a coordination infrastructure you can refer to the \soda{} methodology \cite{soda-aoseI}, and as examples some case studies that have been developed in literature \cite{tucson-ijcis02,esaw03drr}.
%=======================================================================
\chapter{Examples and Patterns}
\label{examples}
%=======================================================================
In this chapter we present a set of simple examples and patterns, where \respect{} is adopted as a coordination language to realise agent communication and coordination.
%
The examples can be considered samples for a wider classes of applications.
%
Any example is given in its simplest form, for easing the understanding of the problem and of the solution: indeed, the examples can be the starting point for developing more robust version for real world applications.
%--------------------------------------------------------------------------------
\section{Some Communication Patterns}
%--------------------------------------------------------------------------------
%--------------------------------------------------------------------------------
\subsection{Blackboard-based Communication}
%--------------------------------------------------------------------------------
Obviously, blackboard based communication is supported naturally in \respect{}.
%
Agents communicate (and coordinate) by writing information on a blackboard -- i.e. inserting tuples in a tuple centre --, and reading / cleaning such information -- i.e. reading / retrieving tuples from the tuple centre, exploiting pattern matching.
%
This form of communication -- which is the case of tuple centre is called \emph{generative communication} -- features a number of interesting properties:
%
\begin{itemize}
%
\item \emph{space uncoupling} -- communication is possible even if the participants don't know where they actually are;
%
\item \emph{time uncoupling} -- communication is possible even if the participants are not simultaneously in the same interaction context, or even alive at the same time;
%
\item \emph{identity uncoupling} -- communication is possible even if the participants don't know who they actually are.
%
\end{itemize}
%
These properties make this approach suitable in particular for open and dynamic systems, with a dynamic set of participants, whose identity can be unknown during the communication activities.
%--------------------------------------------------------------------------------
\subsection{Message-oriented Communication}
%--------------------------------------------------------------------------------
\respect{} can be easily adopted for realising classical message-based communication among agents.
%
In the example a simple design is adopted (which can be easily extended, generalised according to need):
%
\begin{itemize}
%
\item A tuple centre \texttt{msgbox} is adopted as a shared message box or blackboard, where messages are placed and retrieved;
%
\item A tuple \texttt{msg(\textit{Dest},\textit{Msg})} is used to represent a message:
%
\texttt{\textit{Dest}} represents the (logic/virtual) identifier (or name, nickname) of the agent receiver of the message;
%
\texttt{\textit{Msg}} represents the message;
%
\item The protocol:\\\\
%
\texttt{out(msg(\textit{Dest},\textit{Msg}))}, for sending a message \texttt{\textit{Msg}} to an agent \texttt{\textit{Dest}};\\\\
%
\texttt{in(msg(\textit{Dest},\textit{?Msg}))}, for receiving a message (issued by the agent \texttt{\textit{Dest}} target of the message)\footnote{Question mark before the parameter means that it is an input parameter, so typically a variable};\\\\
%
\texttt{inp(msg(\textit{Dest},\textit{?Msg}))}, for receiving a message, without blocking in the case that no message is available;
%
\end{itemize}
%
%A simple sender agent, sending a string message (specified as third parameter) using a tuple centre as a message box (specified as first parameter) to an agent receiver (whose identifier is specified ad first parameter):
%%
%{\small{
%\begin{verbatim}
%import alice.tucson.api.*;
%import alice.logictuple.*;
%public class TestSend {
% public static void main(String[] args) throws Exception {
% // tuple centre used as a message box
% TupleCentreId tid = new TupleCentreId(args[0]);
% // receiver of the message
% Value dest = new Value(args[1]);
% // content of the message: in this case a simple string
% Value msg = new Value(args[2]);
% TucsonContext cnt = Tucson.enterDefaultContext();
% cnt.out(tid,new LogicTuple("msg",dest,msg));
% }
%}
%\end{verbatim}}}
%%
%\noindent Note that in this case an agent is realised as a simple main, with no other classes (such as Threads or classes extending the alice.tucson.Agent class) involved.
%%
%An example of agent execution:
%%
%{\small{
%\begin{verbatim}
% java -cp tucson.jar TestSender msgbox@'137.204.107.188'
% cesare 'hello, see you at 5.00 pm.'
%\end{verbatim}}}
%%
%\noindent In this case a tuple centre called \texttt{msgbox} located on the node 137.204.107.188 (a node running the \tucson{} infrastructure) is used, \texttt{cesare} is the identifier of the agent receiver and the simple string message is 'hello, see you at 5.00 pm.'.
%\medskip
%%
%Then, a simple receiver agent, receiving string messages using a tuple centre as message box (specified as first parameter) specifying his identity (as second parameter) follows:
%%
%{\small{
%\begin{verbatim}
%import alice.tucson.api.*;
%import alice.logictuple.*;
%import alice.tucson.api.*;
%import alice.logictuple.*;
%public class TestReceive {
% public static void main(String[] args) throws Exception {
% // tuple centre used as a message box
% TupleCentreId tid = new TupleCentreId(args[0]);
% // Identifier of the message reader
% Value myid = new Value(args[1]);
% TucsonContext cnt = Tucson.enterDefaultContext();
% LogicTuple msg = cnt.in(tid,new LogicTuple("msg",myid,new Var("Msg")));
% System.out.println("New message for "+myid+": "+msg.getArg(1));
% }
%}
%\end{verbatim}}}
%\noindent An example of agent execution:
%{\small{
%\begin{verbatim}
% java -cp tucson.jar TestReceiver msgbox@'127.204.107.188' cesare
%\end{verbatim}}}
%%
%%
%\noindent In this case the agent waits for messages sent to \texttt{cesare} on the \texttt{mailbox} tuple centres.
%%
%Note that if no message are available, the agent waits (\texttt{in} primitive).
%\medskip
%%
%As a slightly different version, the following agent plays the role of a receiver, but without blocking:
%%
%{\small{
%\begin{verbatim}
%import alice.tucson.api.*;
%import alice.logictuple.*;
%import alice.tucson.api.*;
%import alice.logictuple.*;
%public class TestReceiveNB {
% public static void main(String[] args) throws Exception {
% // tuple centre used as a message box
% TupleCentreId tid = new TupleCentreId(args[0]);
% // Identifier of the message reader
% Value myid = new Value(args[1]);
% TucsonContext cnt = Tucson.enterDefaultContext();
%
% LogicTuple msg = cnt.inp(tid,new LogicTuple("msg",myid,new Var("Msg")));
% if (msg==null){
% System.out.println("No new message for "+myid);
% } else {
% System.out.println("New message for "+myid+": "+msg.getArg(1));
% }
% }
%}
%\end{verbatim}}}
%\noindent Again for executing the agent:
%{\small{
%\begin{verbatim}
% java -cp tucson.jar TestReceiverNB msgbox@'127.204.107.188' cesare
%\end{verbatim}}}
%%
%%
%\noindent Any tuple centre (on any node of the infrastructure) could be used for the example.
%%
%for instance if you want to test the system locally, start a \tucson{} node on the local machine then -- for instance -- use only \texttt{msgbox} as identifier for the tuple centre (localhost is used by default).
%
%%
%%
%%
%Note that in this example we exchange simple strings as messages:
%%
%actually it is possible to exchange any kind of complex or structured information (including images, serialized Java objects, etc. encoded as blobs of bytes, encapsulated in strings), coded as logic tuple.
%%
%%--------------------------------------------------------------------------------
%\subsection{Remote Procedure Calls and Services}
%%--------------------------------------------------------------------------------
%Client-server communication -- as found in Remote Procedure Call or service-oriented architectures (such as Web Services) -- can be modelled with a simple tuple based protocol.
%%
%As a simple example consider the following design:
%%
%\begin{itemize}
%%
%\item A tuple centre is adopted as a mediator between clients and service providers;
%%
%\item A tuple \texttt{request(\textit{Who},\textit{What})} is used to represent a service request, issued by the client \texttt{\textit{Who}}, described by \texttt{\textit{What}}.
%%
%A tuple \texttt{result(\textit{Who},\textit{What},\textit{Result})} is used to represent a service result, issued by a service provider answering a previous request issued by the client \texttt{\textit{Who}}, described by \texttt{\textit{What}}.
% %
%\item The protocol:\\\\
%%
%clients requests a service by inserting a tuple \texttt{request} in the tuple centre, with a \texttt{out(request(\textit{ClientID},\textit{What})))};
%%
%then, they collects results by retrieving the related \texttt{request} tuple, with an \texttt{in(result(\textit{ClientID},\textit{What},\textit{?Result}))}; \\\\
%%
%service providers accept a request by removing a \texttt{request} tuple with an \texttt{in(request(\textit{?ClientID},\textit{?What})))} and provide results by inserting the corresponding tuple \texttt{out(result(\textit{ClientID},\textit{What},\textit{Result}))}.
%%
%\end{itemize}
%%
%\noindent Of course for real world applications more robust and articulated protocols can be adopted.
%%
%The following is an example of simple service provider agent (the service provided concerns the sum of two number: request tuples are of type \texttt{request(\textit{Who},sum(\textit{X},\textit{Y}))} and result tuples \texttt{result(\textit{Who},sum(\textit{X},\textit{Y}),\textit{Result})}):
%{\small{
%\begin{verbatim}
%import alice.tucson.api.*;
%import alice.logictuple.*;
%class ServiceProviderAgent extends Thread {
% private TupleCentreId tid;
%
% public ServiceProviderAgent(TupleCentreId tc){
% tid = tc;
% }
% public void run() {
% try {
% TucsonContext ctx = Tucson.enterDefaultContext();
% System.out.println("ServiceProviderAgent started.");
% while (true) {
% LogicTuple req = ctx.in(tid,
% new LogicTuple("request",new Var("Who"),
% new Value("sum", new Var("X"),new Var("Y"))));
% System.out.println("A new request arrived "+req);
% try {
% TupleArgument who = req.getArg(0);
% int x = req.getArg(1).getArg(0).intValue();
% int y = req.getArg(1).getArg(1).intValue();
% int res = x + y;
% ctx.out(tid,new LogicTuple("result",who,req.getArg(1),new Value(res)));
% } catch (Exception ex){
% ex.printStackTrace();
% System.err.println("Error in processing the request.");
% }
% }
% } catch (Exception ex){
% System.err.println("Problems in accessing TuCSoN.");
% }
% }
%}
%public class ServiceProvider {
% public static void main(String[] args) throws Exception {
% new ServiceProviderAgent(new TupleCentreId(args[0])).start();
% }
%}
%\end{verbatim}}}
%%
%%
%%
%\noindent An example of service provider agent execution:
%{\small{
%\begin{verbatim}
% java -cp tucson.jar ServiceProvider services@'127.204.107.188'
%\end{verbatim}}}
%%
%\noindent In this case the tuple centre \texttt{services@'127.204.107.188'} is used as clients-providers mediator.
%\medskip
%\noindent As a simple client agent:
%{\small{
%\begin{verbatim}
%import alice.tucson.api.*;
%import alice.logictuple.*;
%public class ServiceRequester{
% public static void main(String[] args) throws Exception {
% TucsonContext ctx = Tucson.enterDefaultContext();
% TupleCentreId tid = new TupleCentreId(args[0]);
%
% Value who = new Value(args[1]);
% Value v0 = new Value(Integer.parseInt(args[2]));
% Value v1 = new Value(Integer.parseInt(args[3]));
% System.out.println("Agent "+who+" requesting the sum of "+v0+" and "+v1+"...");
% Value service = new Value("sum",v0,v1);
% ctx.out(tid, new LogicTuple("request",who, service));
% LogicTuple res = ctx.in(tid,new LogicTuple("result",who,service,new Var("R")));
% int result = res.getVarValue("R").intValue();
% System.out.println("The result is "+ result);
% }
%}
%\end{verbatim}}}
%\noindent An example of client agent execution:
%{\small{
%\begin{verbatim}
% java -cp tucson.jar ServiceRequester services@'127.204.107.188' client00 13 17
%\end{verbatim}}}
%%
%\noindent In this case the client, identified as \texttt{client00} is requesting the sum of the numbers 13 and 17, using the tuple centre \texttt{services@'127.204.107.188'}.
%=======================================
\section{Simulating New Coordination Primitives}
%=======================================
The programmability of the tuple centre makes it possible to extend the basic coordination primitive set (in, out,...) with new primitives, without altering the basic set but realising their behaviour with suitable \respect{} reactions.
%
%--------------------------------------------------------------------------------
\subsection{rd\_all}
%--------------------------------------------------------------------------------
The \texttt{rd\_all} primitive makes it possible to collect (without removing) \emph{all} the tuples matching a specified tuple template. \\\\
%
Usage: \texttt{inp(rd\_all(+\textit{TupleTemplate},-\textit{List}))} \\\\
%
Semantics: the request fails if the primitive is not supported (the \respect{} specification has not been installed). Otherwise, the request succeeds, by returning a list (eventually empty) of the tuples matching the template.\\\\
%
\noindent \respect{} specification realising the \texttt{rd\_all} behaviour:
{\small{\begin{verbatim}
reaction(inp(rd_all(T,L)),(
pre,
out_r(rdall_collect(T,[])))).
reaction(out_r(rdall_collect(T,L)),(
current_tuple(rdall_collect(T1,_)),
in_r(T1),
in_r(rdall_collect(T,L)),
out_r(rdall_collect(T,[T1|L])))).
reaction(out_r(rdall_collect(T,_)),(
current_tuple(rdall_collect(T1,_)),
no_r(T1),
in_r(rdall_collect(T,L)),
out_r(rd_all(T,L)),
out_r(rdall_restore(L)) )).
reaction(out_r(rdall_restore([])),(
in_r(rdall_restore([])) )).
reaction(out_r(rdall_restore([H|T])),(
in_r(rdall_restore([H|T])),
out_r(H),
out_r(rdall_restore(T)) )).
\end{verbatim}}}
%--------------------------------------------------------------------------------
\subsection{in\_all}
%--------------------------------------------------------------------------------
The \texttt{in\_all} primitive makes it possible to collect (and remove) \emph{all} the tuples matching a specified tuple template. \\\\
%
Usage: \texttt{inp(in\_all(+\textit{TupleTemplate},-\textit{List}))} \\\\
%
Semantics: the request fails if the primitive is not supported (the \respect{} specification has not been installed). Otherwise, the request succeeds, by removing and returning a list (eventually empty) of the tuples matching the template.\\\\
%
\noindent \respect{} specification realising the \texttt{in\_all} behaviour:
{\small{\begin{verbatim}
reaction(inp(in_all(T,L)),(
pre,
out_r(collect(T,[])))).
reaction(out_r(collect(T,L)),(
current_tuple(collect(T1,_)),
in_r(T1),
in_r(collect(T,L)),
out_r(collect(T,[T1|L])))).
reaction(out_r(collect(T,_)),(
current_tuple(collect(T1,_)),
no_r(T1),
in_r(collect(T,L)),
out_r(in_all(T,L)))).
\end{verbatim}}}
%=======================================
\section{Basic Synchronisation Patterns}
%=======================================
The basic coordination primitives offers natively a good support for realising synchronisation patterns, by suitably creating protocols by means of primitives composition.
%
However, the programmability of tuple centres makes it possible to realise (basic as well as complex) synchronisation patterns incapsulating them in tuple centre behaviour, without the need to rely on agent protocols.
%
In other words, tuple centres can be programmed to act as \emph{coordination artifacts}, featuring some kind of synchronisating / coordinating functionality.
%
As examples, here we consider the basic patterns as found in literature.
%--------------------------------------------------------------------------------
\subsection{Semaphores}
%--------------------------------------------------------------------------------
In order to realise a semaphore coordination artifact, there is no need of a specific \respect{} specification.
A simple semaphore can be modelled directly as a tuple -- for instance \texttt{token};
%
Then, any agent can invoke the classic P operation on the semaphore, i.e. semaphore request to pass, by retrieving the tuple with an \texttt{in(token)}.
%
The classic V operation on the semaphore, i.e. semaphore release, is realised by inserting back the tuple with an \texttt{out(token)}.
%
A \respect{} specification can be adopted for making this approach more robust.
%
For instance: suppose that we want to avoid multiple signaling on the semaphore (generating multiple \texttt{token} tuples).
%
Then the following reactions avoid the proliferation of \texttt{token} tuples:
{\small{\begin{verbatim}
reaction(out(token),(
in_r(token),
no_r(token),
out_r(token))).
reaction(out(token),(
in_r(token),
in_r(token))).
\end{verbatim}}}
In order to realise a semaphore with N agents allowed to enter simultaneously, then it is sufficient to have N token tuples.
%--------------------------------------------------------------------------------
%\subsection{Semaphores with a queue}
%--------------------------------------------------------------------------------
%--------------------------------------------------------------------------------
\subsection{Synchronisation Barrier}
%--------------------------------------------------------------------------------
A typical coordination artifact needed in concurrent systems is the \emph{synchronisation barrier}, which basically makes it possible to synchronise the activity of multiple agents.
%
The problem concerns N agents which need to synchronise before proceeding in their individual activities:
%
every agent executes its task until reaching the synchronisation point, and can proceed only when all the agents involved in the coordinated activities have reached it.
%
As requirements, the agent set can be dynamic, with agents not necessarily knowing who is involved in the coordination activity.
A simple (simplified) solution in \respect{} consists in adopting the following as individual agent protocol\footnote{A process algebra-like syntax is adopted for describing protocols, with A.B meaning sequential operation, A | B parallel operations, A + B non deterministic choice between operations }:\\\\
%
\texttt{out(ready)} . \texttt{rd(ready\_all)} \\\\
%
i.e. the agent inserts a \texttt{ready} tuple when he finished his activity, then wait to see a \texttt{ready\_all} tuple before before proceeding.
%
Then, a tuple centre behaving as a synchronisation barrier can be obtained with the following specification:
\begin{verbatim}
reaction(out(ready),(
in_r(ready),
in_r(ready_agents(N)),
N1 is N+1,
out_r(ready_agents(N1)) )).
reaction(out_r(ready_agents(N)),(
rd_r(barrier_size(N)),
in_r(ready_agents(N)),
out_r(ready_agents(0)),
out_r(ready_all))).
\end{verbatim}
%
For hypothesis, the tuple centre must contain a tuple \texttt{barrier\_size}, containing current number of agents which need to be synchronised, and a tuple \texttt{ready\_agents} containing the dynamic counts of agents already synchronised (starting from 0).
%=======================================
\section{Other Basic Coordination Patterns}
%=======================================
%--------------------------------------------------------------------------------
\subsection{Interoperability}
%--------------------------------------------------------------------------------
A tuple centre can be programmed in order to enable communication among agents using different communication languages and ontology, as a \emph{syntactic and semantic mediator}.
%
This is important in particular in open application contexts, where agents need to interact and fruitfully communicate even if they do not know each other, in terms of languages, protocols, ontology adopted.
%
This is a typical case in complex systems where agents are developed by different developers, belonging to different organisations, and need to participate to and interact in the same application context.
%--------------------------------------------------------------------------------
\subsection{Resource Allocation}
%--------------------------------------------------------------------------------
%\tbc{}
%=======================================
\section{Some Coordination Idioms}
%=======================================
Coordination idioms are frequent solution adopted exploiting the peculiar features of the \respect{} coordination model.
%--------------------------------------------------------------------------------
\subsection{Tuple on demand}
%--------------------------------------------------------------------------------
%\tbc{}
%--------------------------------------------------------------------------------
\section{Other examples}
%--------------------------------------------------------------------------------
Other examples concerning forms of synchronisations and ather coordination patterns can be found in the slides companion of this documents and in the \tucson{} package as demos (dining philosophers, chat systems, tictactoe, multimedia master-worker, etc).
\subsection{Dining Philosophers}
%\tbc{}
\subsection{Contract Net Protocol}
%\tbc{}
\subsection{Workflow Engine}
%\tbc{}
%=======================================================================
\part{Extensions}
\label{extension}
%=======================================================================
%=======================================================================
\chapter{Timed \respect{}}
%=======================================================================
\section{Introduction}
In most application scenarios characterised by a high degree of opennes and dynamism, coordination tasks need to be time-dependent.
%
On the one hand, it is very useful to specify (and then enforce) given levels of liveness and of quality of service --- e.g. requiring agents to interact with the coordination artifact at a minimum/maximum frequency.
%
On the other hand, temporal properties are also fundamental aspects concerning interception of violations in the agent-artifact contract: an agent might be required to provide a service within a given deadline, or might require the artifact to do the same.
%
Accordingly, this version of \respect{} has been extended to include the capabilities of managing time event, in order to support the definition and enactment of time-aware coordination policies.
%
The basic idea is to exploit the programmability of the coordination medium extended with a temporal framework to get the capability of modelling \emph{any} time-based coordination patterns, realised directly by specifying a suitable behaviour of the artifact.
%====================================================================
\section{Extending {\large{\respect{}}} with Time}
\labelsec{model}
%====================================================================
%
%
First of all, the model is extended with a notion of current time of the tuple centre \emph{Tc}:
%
each tuple centre has its own clock, which defines the passing of time \footnote{In current implementation the temporal unity is the millisecond}.
%
Actually, tuple centre time is a physical time, but it is value considered to be constant during the execution of an individual reaction:
%
in other words, we assume that \emph{Tc} refers to the time when the reaction started executing.
%
This choice is coherent with \respect{} philosophy concerning reactions, which are meant to be executed atomically (in the case of successful reactions).
%
In order to get \emph{Tc} in \respect{} programs a new primitive is introduced:\\\\
%
%
\mbox{~~~~~~~~}\texttt{current\_time(\textit{?Tc})\footnote{A Prolog notation is adopted for describing the modality of arguments: + is used for specifying input argument, - output argument, ? input/output argument, @ input argument which must be fully instantiated}}\\
This primitive (predicate) is successful if \ttit{Tc} (typically a variable) unifies with the current tuple centre time \emph{Tc}.
%
As an example, the reaction specification tuple
%
{\small{%
\begin{verbatim}
reaction(in(p(X)),(
current_time(Tc),
out_r(request_log(Tc,p(X)))
)).
\end{verbatim}}}
%
\noindent inserts a new tuple with timing information each time a request to retrieve a tuple \texttt{p(X)} is executed, realising a temporal log of the requests.
%
The model is then extended with the notion of \emph{trap event} or simply \emph{trap}, which is an event generated when the tuple centre reaches a specific time point.
%
A trap occurs because of a \emph{(trap) source}, characterised by a unique identifier \textit{ID}, a time \textit{Te} and a description tuple \textit{Td}.
%
The language is extended with the possibility to generate and manipulate trap events and sources.
%
In particular we introduce the two following features:
%
\begin{itemize}
%
\item internally in the tuple centre, a coordination law (i.e. one or more reaction specification tuples) might install a trap source, which causes a trap to occur at a specific time.
%
For instance,
%
we may want to generate a trap described by the tuple \texttt{expired(\textit{T})} a certain interval \textit{LeaseTime} after the insertion of a tuple \texttt{leased(\textit{T})};
%
\item the tuple centre reacts to a trap event analogously to communication events, by means of proper reaction specification tuples.
%
In the case above, we may want the tuple \textit{T} to be removed when the trap described by \texttt{expired(\textit{T})} occurs.
%
%
\end{itemize}
%
In order to support trap generator installation, the language is extended with two new primitives:\\\\
%
\mbox{~~~~~~~~}\texttt{new\_trap(\textit{-ID},\textit{@Te},\textit{+Td)}}\\\\
%
\mbox{~~~~~~~~}\texttt{kill\_trap(\textit{@ID})} \\\\
%
The first is successful if \ttit{Te} is an integer equal or greater than zero.
%
Its effect is to install a new trap source --- with \ttit{ID} as identifier --- which enters a queue of installed sources.
%
When tuple centre time \textit{Tc} time will be equal or greater than current time plus \ttit{Te}, a trap event described by the tuple \ttit{Td} will be then generated and inserted into the queue of triggered trap events, whereas its source is deinstalled --- i.e. removed from its queue.
%
Notice that because of the success/failure semantics of \respect{} semantics, if the reaction including an invocation to primitive \texttt{new\_trap} fails, no trap source is installed, actually.
%
An example involving the \texttt{new\_trap} primitive is as follows:
%
{\small{
\begin{verbatim}
reaction(out(leased(T,LeaseTime)),(
new_trap(_,LeaseTime,expired(T))
)).
\end{verbatim}}}
%
\noindent The reaction is triggered when a tuple matching \texttt{leased(T,LeaseTime)} is inserted, and it installs a new trap source which will generate a trap described by the tuple \texttt{expired(T)} after \ttit{LeaseTime} units from then.
%
Primitive \texttt{kill\_trap} is instead used to deinstall a source given its identifier: such a primitive fails if not installed sources has is characterised by the identifier provided.
%
Then, the language has been extended with the possibility to write reactions triggered by the occurrence of trap events.
%
The syntactical and semantic models of trap reactions are analogous to the reactions to communication events:\\\\
%
\mbox{~~~~~~~~}\texttt{reaction( trap(\textit{Tuple}), \textit{Body})}\\\\
%
\ttit{Body} specifies the set of actions to be executed when a trap with a description tuple matching the template \ttit{Tuple} occurs.
%
In the following simple example
%
{\small{
\begin{verbatim}
reaction(trap(expired(T)),( in_r(T) )).
\end{verbatim}}}
%
\noindent when a trap described by a tuple matching the template \texttt{expired(T)} occurs, the tuple specified in \texttt{T} is removed from the tuple set.
%
Notice that if the tuple is not present the \texttt{in\_r} fails causing the whole reaction to fail --- as the trap event is occurred, however, the trap source is erased.
%
% Funzionamento generale: pi\UTF{00F9} semantiche
%
Trap events are listened one by one as soon as the tuple centre is not executing a reaction; that is --- according to the tuple centre semantics \cite{respect-scico01,respect-entcs48} --- when it is in the idle state, or between a listening and a speaking stage, or during a reacting stage (between the execution of two reactions).
%
When a trap event is listened, it is first removed from the trap event queue, the set of the reactions it triggers is determined --- by matching the reaction head with the trap description tuple --- and then executing sequentially all such reactions.
%
As for the \respect{} reacting stage, the order of execution of the reactions is not deterministic.
%
An important semantic aspect of this extension concerns the priority of reactions fired by external communication events (standard execution) with respect to those of trap events (trap execution).
%
The model and implementation described here feature higher priority of reactions fired by trap events.
%
This means that if during the standard executions of a reaction chain a trap event occurs, the chain is broken, and the reactions fired by the trap are executed.
%
It's worth noting that the individual reactions are still atomic, not interruptible as in the basic \respect{} model:
%
traps event in the trap queue are listened (and related reactions executed) after the completion of any reaction eventually in execution.
%
Then, chains of reactions can be broken, not individual reactions.
%
This is fundamental in order to preserve the semantic properties of \respect{} model \cite{respect-entcs48}.
%
Also reactions triggered by a trap event are atomic, and they cannot be interrupted or suspended:
%
in other words, trap handlers are not interruptible and cannot be nested.
%
%
%
The possibily of breaking reaction chains is important to build robust coordinating behaviour, in particular with respect to possible bugs generating terminating reaction chains.
Nevertheless, it is worth mentioning here that other semantics are possible and interesting.
%
By giving higher priority to the standard execution, one ensures that traps never interfere with it.
%
In exchange of the better isolation of code achieved, in this case one can no longer guarantee the same timing constraints: trap executions must wait for the standard execution to complete.
%
Notice that such aspects are mostly orthogonal to the actual applicability of temporal coordination laws as shown e.g. in next section.
%
Moreover, a straightforward generalisation of our model can be realised by specifying the priority level of a trap (higher, lower, or equal to the that of external communication events) at the time its source is installed\footnote{This interesting feature which is subject of current research is not described in this paper for brevity.}.
%====================================================================
\section{Examples}
\labelsec{examples}
%====================================================================
In this section we describe some simple examples of how temporal coordination primitives and coordination laws can be modelled on top of extended \respect{}.
%
It's worth noting that these examples -- even if simple -- appear in several research work in literature as a core of timing features extending the basic model;
%
typically, in the literature there is a specific extension for each timing feature described here:
%
on the contrary, we remark the generality of our approach, which is meant to support these and several other time-based coordination patterns on top of the same model.
\begin{table}%
{\tt\scriptsize
\begin{tabular}{p{8cm}}\hline\hline\\\\
%
\mbox{1~~}reaction( in(timed(Time,Tuple,Res)), (\\
\mbox{~~~~~}pre, in\_r(Tuple), \\
\mbox{~~~~~}out\_r(timed(Time,Tuple,yes)))).\\\\
%
\mbox{2~~}reaction( in(timed(Time,Tuple,Res)), (\\
\mbox{~~~~~}pre,no\_r(Tuple),\\
\mbox{~~~~~}new\_trap(ID,Time,expired\_in(Time,Tuple)),\\
\mbox{~~~~~}out\_r(trap\_info(ID,Time,Tuple)) )).\\\\
%
\mbox{3~~}reaction( trap(expired\_in(Time,Tuple)),(\\
\mbox{~~~~~}in\_r(trap\_info(ID,Time,Tuple)), \\
\mbox{~~~~~}out\_r(timed(Time,Tuple,no)) )).\\\\
\mbox{4~~}reaction( out(Tuple),(\\
\mbox{~~~~~}in\_r(trap\_info(ID,Time,Tuple)), \\
\mbox{~~~~~}kill\_trap(ID),\\
\mbox{~~~~~}out\_r(timed(Time,Tuple,yes)) )).\\\\
%
\hline\hline
\end{tabular}}
\caption{\respect{} specification for modelling a timed \texttt{in} primitive\labeltab{timed-in}}
\end{table}
%------------------------------------------------------------------------------------------------
\subsection{Timed Requests}
%------------------------------------------------------------------------------------------------
In this first example we model a timed \texttt{in} primitive, i.e. an \texttt{in} request that keeps blocked only for a maximum amount of time.
%
An agent issues a timed \texttt{in} by executing primitive \texttt{in(timed(\textit{@Time},\textit{?Template},\textit{-Res})}.
%
If a tuple matching \ttit{Template} is inserted within \ttit{Time} units of time, the requested tuple is removed and taken by the agent as usual with \ttit{Res} being bound to the \texttt{yes} atom.
%
Conversely, if no matching tuples are inserted within the specified time, \ttit{Res} is bound to \texttt{no} atom.
%
%
\xt{timed-in} reports the \respect{} specification which makes it possible to realise the behaviour of this new primitive.
%
%
When the \texttt{in} request is issued, if a tuple matching the template is present a proper tuple satisfying the request is created (reaction 1).
%
Instead, if no tuple is found, a trap source is installed for generating a trap at the due time (reaction 2).
%
Also, a tuple \texttt{trap\_info} is inserted in the tuple set, reifying information about the installed trap source, required for its possible removal.
%
If a tuple matching a template of a pending timed \texttt{in} is inserted on time, the related trap source is removed and a proper tuple matching the timed \texttt{in} request is inserted (reaction 4).
%
Finally, if the trap occurs --- meaning that no tuples have been inserted on time matching a pending timed \texttt{in} --- then a tuple matching the timed \texttt{in} request carrying negative result is inserted in the tuple set (reaction 3).
\begin{table}%
{\tt\scriptsize
\begin{tabular}{p{8cm}}\hline\hline\\\\
%
\mbox{1~~}reaction( out(leased(Time,Tuple)), (\\
\mbox{~~~~~}new\_trap(ID,Time,lease\_expired(Time,Tuple)),\\
\mbox{~~~~~}in\_r(leased(Time,Tuple)),\\
\mbox{~~~~~}out\_r(outl(ID,Time,Tuple)) )).\\\\
%
\mbox{2~~}reaction( rd(Tuple),( pre,\\
\mbox{~~~~~}rd\_r(outl(ID,\_,Tuple)), \\
\mbox{~~~~~}out\_r(Tuple) )).\\\\
%
\mbox{3~~}reaction( rd(Tuple),(post,\\
\mbox{~~~~~}rd\_r(outl(ID,\_,Tuple)),\\
\mbox{~~~~~}in\_r(Tuple) )).\\\\
%
\mbox{4~~}reaction( in(Tuple),( pre,\\
\mbox{~~~~~}in\_r(outl(ID,\_,Tuple)), \\
\mbox{~~~~~}out\_r(Tuple), \\
\mbox{~~~~~}kill\_trap(ID) )).\\\\
%
\mbox{5~~}reaction( trap(lease\_expired(Time,Tuple)), ( \\
\mbox{~~~~~}in\_r(outl(ID,Time,Tuple)))).\\\\
%
\hline\hline
\end{tabular}}
\caption{\respect{} specification for modelling tuples with a lease time \labeltab{lease-out}}
\end{table}
%------------------------------------------------------------------------------------------------
\subsection{Tuples in Leasing}
%------------------------------------------------------------------------------------------------
In this example we model the notion of \emph{lease}, analogously to the lease notion in models such as JavaSpaces \cite{javaspaces-book} and TSpaces \cite{tspaces}.
%
Tuples can be inserted in the tuple set specifying a lease time, i.e. the maximum amount of time for which they can reside in the tuple centre before automatic removal.
An agent insert a tuple with a lease time by issuing an \texttt{out(leased(\textit{@Time},\textit{@Tuple}))}.
%
\xt{lease-out} shows the \respect{} specification programming the tuple centre with the desired leasing behaviour .
%
When a tuple with a lease time is inserted in the tuple centre, a trap source is installed for generating a trap when the tuple centre time reaches the lease due time (reaction 1).
%
Also a tuple \texttt{outl} is inserted in the tuple set with the information on the trap source and the leased tuple (note that the flat tuple with the lease time is not directly present in the set).
%
Then, for each \texttt{rd} issued with a template matching a leased tuple, a flat tuple satisfying the request is first inserted in the tuple set (reaction 2), and then removed after the \texttt{rd} has been satisfied (reaction 3).
%
An \texttt{in} request instead causes directly the removal of the lease tuple and of the trap source (reaction 4).
%
Finally, if a trap event occurs (meaning that the lease time of a tuple expired), the \texttt{outl} tuple carrying information about the presence of the leased tuple is removed (reaction 5).
\begin{table}%
{\tt\scriptsize
\begin{tabular}{p{8cm}}\hline\hline\\\\
%
\mbox{1~~}reaction(in(all\_timed(Time,Tuple,OutList)),(\\
\mbox{~~~~~}new\_trap(ID,Time,inat(Time,Tuple,OutList)),\\
\mbox{~~~~~}out\_r(current\_in\_all(ID,Time,Tuple,[])),\\
\mbox{~~~~~}out\_r(remove\_in\_all(ID)))).\\
%
\mbox{2~~}reaction( out\_r(remove\_in\_all(ID)),( \\
\mbox{~~~~~}in\_r(remove\_in\_all(ID)),\\
\mbox{~~~~~}rd\_r(current\_in\_all(ID,Time,Tuple,L)),\\
\mbox{~~~~~}in\_r(Tuple),\\
\mbox{~~~~~}in\_r(current\_in\_all(ID,Time,Tuple2,L)),\\
\mbox{~~~~~}out\_r(current\_in\_all(ID,Time,Tuple2,[Tuple|L])),\\
\mbox{~~~~~}out\_r(remove\_in\_all(ID)))).\\
%
\mbox{3~~}reaction( out\_r(remove\_in\_all(ID)),( \\
\mbox{~~~~~}in\_r(remove\_in\_all(ID)),\\
\mbox{~~~~~}rd\_r(current\_in\_all(ID,\_,Tuple,\_)),\\
\mbox{~~~~~}no\_r(Tuple))).\\
%
\mbox{4~~}reaction( out(Tuple),(\\
\mbox{~~~~~}in\_r(current\_in\_all(ID,\_,Tuple,L)),\\
\mbox{~~~~~}in\_r(Tuple),\\
\mbox{~~~~~}out\_r(current\_in\_all(ID,\_,Tuple,[Tuple|L])))).\\
%
\mbox{5~~}reaction( trap(inat(Time,Tuple,OutList)), (\\
\mbox{~~~~~}in\_r(current\_in\_all(ID,Time,Tuple,L)),\\
\mbox{~~~~~}out\_r(all\_timed(Time,Tuple,L)))).\\\\
%
\hline\hline
\end{tabular}}
\caption{\respect{} specification mimicking an \texttt{inall} with a duration time\labeltab{inall}}
\end{table}
%-------------------------------------------------------------------------------------
%\subsection{Dining Philosophers with Maximum Eating Time}
%-------------------------------------------------------------------------------------
\begin{table}%
{\tt\scriptsize
\begin{tabular}{p{8cm}}\hline\hline\\\\
%
\% a request of the chopsticks is reified with a \\
\% required tuple\\
\mbox{1~~}reaction(in(chops(C1,C2)),(pre,out\_r(required(C1,C2)))).\\\\
%
%
\% if both the chopsticks are available, a chops \\
\% tuple is generated\\
\mbox{2~~}reaction(out\_r(required(C1,C2)),(\\
\mbox{~~~~~}in\_r(chop(C1)),in\_r(chop(C2)),out\_r(chops(C1,C2)))).\\\\
%
%
\% with the retrieval of the chops tuple, \\
\% the chopsticks request is removed\\
\mbox{3~~}reaction(in(chops(C1,C2)), (post,in\_r(required(C1,C2)))).\\\\
%
%
\% the release of a chops tuple still valid (on time) \\
\% causes the insertion of individual chopsticks, \\
\% represented by the two chop tuples \\
\mbox{4~~}reaction(out(chops(C1,C2)), ( \\
\emph{\mbox{~~~~~}current\_agent(AgentId),}\\
\emph{\mbox{~~~~~}no\_r(invalid\_chops(AgentId,C1,C2)),}\\
\mbox{~~~~~}in\_r(chops(C1,C2)),out\_r(chop(C1)),out\_r(chop(C2)))).\\\\
%
%
\% a chops tuple is generated if there is \\
\% a pending request, and both chop tuples\\
\% are actually available \\
\mbox{5~~}reaction(out\_r(chop(C1)), (rd\_r(required(C1,C)),\\
\mbox{~~~~~}in\_r(chop(C1)),in\_r(chop(C)),out\_r(chops(C1,C)))).\\
%
\mbox{6~~}reaction(out\_r(chop(C2)), (rd\_r(required(C,C2)),\\
\mbox{~~~~~}in\_r(chop(C)),in\_r(chop(C2)),out\_r(chops(C,C2)))).\\\\\\
%
%
%
\% a chopsticks request causes also creating a \\
\% new trap generator, keeping track of its information
\% in the chops\_pending\_trap tuple \\
\mbox{7~~}reaction(in(chops(C1,C2)),( pre, \\
\mbox{~~~~~}rd\_r(max\_eating\_time(Tmax)),\\
\mbox{~~~~~}new\_trap(ID,Tmax, expired(C1,C2)),\\
\mbox{~~~~~}current\_agent(AgentId),\\
\mbox{~~~~~}out\_r(chops\_pending\_trap(ID,AgentId,C1,C2)))).\\\\
%
\% when chops are released on time, the trap \\
\% generator is removed \\
\mbox{8~~}reaction(out(chops(C1,C2)),(\\
\mbox{~~~~~}in\_r(chops\_pending\_trap(ID,C1,C2)),\\
\mbox{~~~~~}kill\_trap(ID))).\\\\
%
\% trap generation causes the insertion back \\
\% of the missing tuples and the insertion of tuple \\
\% keeping track of the invalid chops\\
\mbox{9~~}reaction(trap(expired(C1,C2)),( \\
\mbox{~~~~~}no\_r(chop(C1)), no\_r(chop(C2)),\\
\mbox{~~~~~}current\_agent(AgentId),\\
\mbox{~~~~~}in\_r(chops\_pending\_trap(ID,AgentId,C1,C2)),\\
\mbox{~~~~~}out\_r(invalid\_chops(AgentId,C1,C2)),\\
\mbox{~~~~~}out\_r(chop(C1)), out\_r(chop(C2)))).\\\\
%
\% chopsticks released that are invalid (due to \\
\% time expiration) are immediately removed \\
\mbox{10~}reaction(out(chops(C1,C2)), ( \\
\mbox{~~~~~}current\_agent(AgentId),\\
\mbox{~~~~~}in\_r(invalid\_chops(AgentId,C1,C2)),\\
\mbox{~~~~~}in\_r(chops(C1,C2)))).\\\\
%
\hline\hline
\end{tabular}}
\caption{\respect{} specification for coordinating dining philosophers with a maximum eating time \labeltab{philo}}
%\vspace{0.3cm}
% }
\end{table}
\subsection{Dining Philosophers with Maximum Eating Time}
The \emph{dining philosopher} is a classical problem used for evaluating the expressiveness of coordination languages in the context of concurrent systems.
%
In spite of its formulation, it is generally used as an archetype for non-trivial resource access policies.
%
The solution of the problem in \respect{} consists in using a tuple centre for encapsulating the coordination policy required to decouple agent requests from single requests of resources --- specifically, to encapsulate the management of \emph{chopsticks} (for details refer to \cite{respect-scico01}).
%
Each philosopher agent \emph{(i)} gets the two needed chopsticks by retrieving a tuple \texttt{chops(C1,C2)}, \emph{(ii)} eats for a certain amount of time, \emph{(iii)} then he provides back the chopsticks by inserting the tuple \texttt{chops(C1,C2)} in the tuple centre, and \emph{(iv)} finally he starts thinking until next dining cycle.
%
A pseudo-code reflecting this interactive behaviour is the following:
%
{\small{
\begin{verbatim}
while (true){
think();
in(chops(C1,C2));
eat();
out(chops(C1,C2));
}
\end{verbatim}}}
%
The coordination specification in \respect{} (first 6 reactions of \xt{philo}, bottom) mediates the representation of the resources (\texttt{chops} vs. \texttt{chop} tuples), and most importantly avoid deadlocks among the agents.
%
Here we extend the basic problem by adding a further constraint: the maximum time which philosophers can take to eat (i.e. to use the resources) is given, stored in a tuple \texttt{max\_eating\_time(\emph{MaxEatingTime})} in the tuple centre.
%
To keep the example simple, if this time is exceeded, the chopsticks are regenerated in the tuple centre, avoiding the starvation of the philosophers waiting for them, and the chopsticks eventually inserted out of time are removed.
%
The solution to this problem using the extended \respect{} model accounts for adding only the \respect{} specification (the agent code and related protocols are untouched) with the reactions 7--10 described in \xt{philo} (bottom), and extending reaction 4 with the part in italics.
%
Essentially, the new reactions install a new trap source as soon as a philosopher retrieves his chopsticks (reaction 7).
%
If the philosopher provides the chopsticks back in time (before the occurrence of the trap), then the trap source is removed (reaction 8).
%
Otherwise, if the trap event occurs, the triggered trap reaction recreates the missing chopsticks tuples in the tuple centre and inserts a tuple \texttt{invalid\_chops} which prevent chopsticks insertion out of fime (reaction 9).
%
This prevention is realised by checking the existence of the tuple \texttt{invalid\_chops} when the tuple \texttt{chops} are released by a philosopher (reaction 10).
%
It is worth noting that keeping track of the maximum eating time as a tuple (\texttt{max\_eating\_time} in the example) makes it possible to easily change it dynamically, while the activity is running;
%
this can be very useful for instance in scenarios where this time need to be adapted (at runtime) according to the workload and, more generally, environmental factors affecting the system.
%
%
Finally, it's worth remarking that the approach is not meant to alter the autonomy of the agent, for instance by means of some form of preemption in the case of timing violations;
%
on the contrary -- as a coordination model -- all the constraints and (timed based) rule enforcing concerns the interaction space.
%------------------------------------------------------------------------------------------------
\subsection{An Artifact for Timed Contract Net Protocols}
%------------------------------------------------------------------------------------------------
%
As a final example, we describe a coordination artifact modelling and embodying the coordinating behaviour of a time-aware Contract Net Protocol (CNP).
%
CNP is a well-known protocol in MAS, used as basic building block for bulding more articulated protocols and coordination strategies \cite{smith79contract}.
%
Following \cite{weiss99book--02}, we consider the CNP in a task allocation scenario:
%
a master announces a task (service) to be executed,
%
potential workers interested provide their bids,
%
the announcer collects the bid and selects one;
%
after confirming his bid, the awarded bidder becomes the contractor, taking in charge of the execution of the task and finally providing task results.
We extend the basic version with some timing constraints. In particular we suppose that:
%
\emph{(i)} the bidding stage has a duration, established at a ``contract'' level;
%
\emph{(ii)} there is a maximum time for the announcer for communicating the awarded bidder;
%
\emph{(iii)} there is a maximum time for the awarded bidder for confirming the bid and becoming the contractor;
%
\emph{(iv)} there is a maximum time for the contractor for executing the task.
According to our approach, a coordination artifact can be used to embody the coordinating behaviour of the time-aware CNP, fully encapsulating the social/contractual rules defining protocols steps and governing participant interaction, including temporal constraints.
%
The coordination artifact is realised as a tuple centre -- called \texttt{tasks} --, programmed with the \respect{} specification reported in \xt{cnp-spec}.
%
\xt{cnp-agents} shows the pseudo-code representing the interactive behaviour of the master (top) and workers (bottom).
%
The usage protocol of the artifact for the master consists in:
%
making the announcement (by inserting a tuple \texttt{announcement}), collecting the bids (by retrieving the tuple \texttt{bids}), selecting and informing the awarded bidder (by inserting the tuple \texttt{awarded\_bid}) and, finally, collecting the result (by retrieving the tuple \texttt{task\_done});
%
for the workers, the usage protocol accounts for reading the announcement (by reading the tuple \texttt{announcement}), evaluating the proposal and providing a bid (by inserting a tuple \texttt{bid}), reading the master decision (by retrieving the tuple \texttt{bid\_result}), and -- in the case of awarding -- confirming the bid (by inserting the tuple \texttt{confirming\_bid}), performing the task and, finally, providing the results (by insering the tuple \texttt{task\_result}).
%
The artifact behaviour in \respect{} described in \xt{cnp-spec} reflects the various stages of the CNP protocol, and traps are used for modelling the timing constraints related to the various stages: from bidding, to awarding, confirming, and task execution
%
A brief description of the artifact behaviour follows:
%
when a new announcement is done (reaction 1), the information about the new CNP are created (tuple \texttt{task\_todo} and \texttt{cnp\_state}) and a new trap source is installed, generating a trap when the bidding time is expired.
%
At the trap generation (reaction 2) -- meaning that the bidding stage is closed -- all the bids inserted are collected (reaction 3), the information concerning the protocol state updated, and a new trap source is installed, generating a trap when the awarding time is expired.
%
If the master provides information about the awarded bidder before this trap generation, the trap source is killed, the tuples concerning awarded and non-awarded bidders are generated (reactions 5, 8, 9), and a new trap source for managing confirmation expire is installed (reaction 5).
%
If no awarded bidder is provided on time or a wrong (unknown) awared is communicated, the tuple reporting the CNP state is updated accordingly, reporting the error (reactions 4, 6, 7).
%
If the awarded bidder confirms on time his bid (reaction 10), the execution stage is entered, by updating the CNP state properly and installing a new trap generator for keeping track of task execution time expiration.
%
Otherwise, if the confirm is not provided on time, the related trap event is generated and listened (reaction 11), aborting the activity and updating accordingly the CNP state tuple.
%
Finally, if the contractor provides the task result on time (reaction 13), the trap generator for task execution is killed, the tuples concening the terminating CNP are removed and the result information are prepared for being retrieved by the master.
%
Otherwise, if the contractor does not provide information on time, the trap is generated and the artifact state is updated accordingly, reporting the error (reaction 12).
\begin{table}%
{\tt\scriptsize
\begin{tabular}{p{8cm}}\hline\hline\\
\mbox{~~}tasks ?\ out(announcement(task(TaskId,TaskInfo,MaxExecTime))) \\
\mbox{~~}tasks ?\ in(bids(TaskId,BidList)) \\
\mbox{~~}Bid $\leftarrow$ selectWinner(BidList) \\
\mbox{~~}tasks ?\ out(awarded\_bid(TaskId,AgentId)) \\
\mbox{~~}tasks ?\ in(task\_done(TaskId,Result,Duration)) \\\\
\hline\\
\mbox{~~}tasks ?\ rd(announcement(task(TaskId,TaskInfo,MaxExecTime)))\\
\mbox{~~}MyBid $\leftarrow$ evaluate(TaskInfo)\\
\mbox{~~}tasks ?\ out(bid(TaskId,MyId,MyBid))\\
\mbox{~~}tasks ?\ in(bid\_result(TaskId,MyId,Answer))\\
\mbox{~~}if (Answer=='awarded') \{\\
\mbox{~~~~~~}tasks ? out(confirm\_bid(MyId))\\
\mbox{~~~~~~}Result $\leftarrow$ perform(TaskInfo)\\
\mbox{~~~~~~}tasks ? out(task\_result(TaskId,MyId,Result))\\
\mbox{~~}\}\\\\
%
\hline\hline%
\end{tabular}}
\caption{Sketch of the behaviour of the agents participating to the timed Contract Net Protocol: masters \emph{(Top)} and workers \emph{(Bottom)}
%
\labeltab{cnp-agents}}
\end{table}
\begin{table*}
\fbox{
{\tt\scriptsize
\centering
\begin{tabular}{cc}
%
\begin{minipage}{8cm}
%
\emph{\% When an announcement is made, a trap generator is\\
\% installed for generating a timeout for bidding time}\\
\mbox{1~~}reaction(out(announcement(task(Id,Info,MaxTime))),(\\
\mbox{~~~~~}out\_r(task\_todo(Id,Info,MaxTime)),\\
\mbox{~~~~~}out\_r(cnp\_state(collecting\_bids(Id))),\\
\mbox{~~~~~}rd\_r(bidding\_time(Time)),\\
\mbox{~~~~~}new\_trap(\_,Time,bidding\_expired(Id)))).\\\\
%
\emph{\% When the bidding time has expired, the master can\\
\% collect the bids for choosing the winner. A trap \\
\% generator is installed for defining the maximum \\
\% awarding time}\\
\mbox{2~~}reaction(trap(bidding\_expired(TaskId)),(\\
\mbox{~~~~~} in\_r(announcement(\_)),\\
\mbox{~~~~~} in\_r(cnp\_state(collecting\_bids(TaskId))),\\
\mbox{~~~~~} out\_r(collected\_bids(TaskId,[])),\\
\mbox{~~~~~} out\_r(cnp\_state(awarding(TaskId))),\\
\mbox{~~~~~} rd\_r(awarding\_time(Time)),\\
\mbox{~~~~~} new\_trap(\_,Time,awarding\_expired(TaskId)))).\\
%
\mbox{3~~}reaction(out\_r(collected\_bids(TaskId,L)),(\\
\mbox{~~~~~} in\_r(bid(TaskId,AgentId,Bid)),\\
\mbox{~~~~~} out\_r(bid\_evaluated(TaskId,AgentId,Bid)),\\
\mbox{~~~~~} in\_r(collected\_bids(TaskId,L)),\\
\mbox{~~~~~} out\_r(collected\_bids(TaskId,\\
\mbox{~~~~~~~~~~~~~~~} [bid(AgentId,Bid)|L])) )).\\\\
%
%
\emph{\% When the awarding time has expired, the bidders are\\
\% informed of the results. If no winner has been\\
\% selected the protocol enters in an error state, \\
\% otherwise the protocol enters in the confirming\\
\% stage, setting up a maximum time for it}\\
\mbox{4~~}reaction(trap(awarding\_expired(TaskId)),(\\
\mbox{~~~~~} in\_r(cnp\_state(awarding(TaskId))),\\
\mbox{~~~~~} out\_r(check\_awarded(TaskId)))).\\
%
\mbox{5~~}reaction(out\_r(check\_awarded(TaskId)),(\\
\mbox{~~~~~} in\_r(check\_awarded(TaskId)),\\
\mbox{~~~~~} rd\_r(awarded\_bid(TaskId,AgentId)),\\
\mbox{~~~~~} in\_r(bid\_evaluated(TaskId,AgentId,Bid)),\\
\mbox{~~~~~} out\_r(result(TaskId,AgentId,awarded)),\\
\mbox{~~~~~} out\_r(cnp\_state(confirming\_bid(TaskId,AgentId))),\\
\mbox{~~~~~} rd\_r(confirming\_time(Time)),\\
\mbox{~~~~~} new\_trap(ID,Time,confirm\_expired(TaskId)),\\
\mbox{~~~~~} out\_r(confirm\_timer(TaskId,ID)),\\
\mbox{~~~~~} out\_r(refuse\_others(TaskId)))).\\
%
\mbox{6~~}reaction(out\_r(check\_awarded(TaskId)),(\\
\mbox{~~~~~} in\_r(check\_awarded(TaskId)),\\
\mbox{~~~~~} rd\_r(awarded\_bid(TaskId,AgentId)),\\
\mbox{~~~~~} no\_r(bid\_evaluated(AgentId,Bid)),\\
\mbox{~~~~~} out\_r(cnp\_state(aborted(TaskId,wrong\_awarded))))).\\
%
\mbox{7~~}reaction(out\_r(check\_awarded(TaskId)),(\\
\mbox{~~~~~} in\_r(check\_awarded(TaskId)),\\
\mbox{~~~~~} no\_r(awarded\_bid(TaskId,AgentId)),\\
\mbox{~~~~~} out\_r(cnp\_state(aborted(TaskId,award\_expired))))).\\
%
%
\end{minipage}
&
\begin{minipage}{8cm}
\mbox{8~~}reaction(out\_r(refuse\_others(TaskId)),(\\
\mbox{~~~~~} in\_r(bid\_evaluated(TaskId,AgentId,Bid)),\\
\mbox{~~~~~} out\_r(result(TaskId,AgentId,'not-awarded')),\\
\mbox{~~~~~} out\_r(refuse\_others(TaskId)))). \\
%
\mbox{9~~}reaction(out\_r(refuse\_others(TaskId)),(\\
\mbox{~~~~~} in\_r(refuse\_others(TaskId)) )).\\\\
%
%
\emph{\% At the arrival of the confirm from the awarded\\
\% bidder, a timeout trap is setup for checking the \\
\% execution time of the task}\\
\mbox{10~~}reaction(out(confirm\_bid(TaskId,AgentId)),(\\
\mbox{~~~~~} in\_r(confirm\_bid(TaskId,AgentId)),\\
\mbox{~~~~~} in\_r(cnp\_state(confirming\_bid(TaskId,AgentId))),\\
\mbox{~~~~~} current\_time(StartTime),\\
\mbox{~~~~~} out\_r(cnp\_state(executing\_task(TaskId,StartTime))),\\
\mbox{~~~~~} in\_r(confirm\_timer(TaskId,IdT)),\\
\mbox{~~~~~} kill\_trap(IdT),\\
\mbox{~~~~~} rd\_r(task\_todo(TaskId,\_,MaxTime)),\\
\mbox{~~~~~} new\_trap(IdT2, MaxTime, execution\_expired),\\
\mbox{~~~~~} out\_r(execution\_timer(TaskId,IdT2)))).\\\\
%
\emph{\% The occurrence of the confirm expired trap means \\
\% that the confirm from the awarded bidder has not \\
\% arrived on time, causing the protocol to be aborted}\\
\mbox{11~~}reaction(trap(confirm\_expired(TaskId)),( \\
\mbox{~~~~~} in\_r(cnp\_state(confirming\_bid(TaskId,AgentId))),\\
\mbox{~~~~~} in\_r(confirm\_timer(TaskId,\_)),\\
\mbox{~~~~~} rd\_r(awarded\_bid(TaskId,AgentId)),\\
\mbox{~~~~~} out\_r(cnp\_state(aborted(TaskId,
\mbox{~~~~~~~~~~~~~~}confirm\_expired(AgentId)))))).\\\\
%
\emph{\% The occurrence of the execution expired trap means \\
\% that the awarded bidder has not completed the \\
\% task on time, causing the protocol to be aborted}\\
\mbox{12~~}reaction(trap(execution\_expired(TaskId)),( \\
\mbox{~~~~~} in\_r(cnp\_state(executing\_task(TaskId,StartTime))),\\
\mbox{~~~~~} in\_r(execution\_timer(TaskId,\_)),\\
\mbox{~~~~~} rd\_r(awarded\_bid(TaskId,AgentId)),\\
\mbox{~~~~~} current\_time(Now),\\
\mbox{~~~~~} Duration is Now - StartTime, \\
\mbox{~~~~~} out\_r(cnp\_state(aborted(TaskId,\\
\mbox{~~~~~~~~~~~~~~}execution\_expired(AgentId,Duration)))))).\\\\
%
\emph{\% The awarded bidder provided task result on time\\
\% terminating correctly the protocol}\\
\mbox{13~~}reaction(out(task\_result(TaskId,AgentId,Result)),(\\
\mbox{~~~~~} in\_r(task\_result(TaskId,AgentId,Result)),\\
\mbox{~~~~~} in\_r(awarded\_bid(TaskId,AgentId)),\\
\mbox{~~~~~} in\_r(execution\_timer(TaskId,Id)),\\
\mbox{~~~~~} kill\_trap(Id),\\
\mbox{~~~~~} in\_r(cnp\_state(executing\_task(TaskId,StartTime))),\\
\mbox{~~~~~} in\_r(task\_todo(TaskId,Info,MaxTime)),\\
\mbox{~~~~~} current\_time(Now),\\
\mbox{~~~~~} Duration is Now - StartTime, \\
\mbox{~~~~~} out\_r(task\_done(TaskId,Result,Duration)) )).\\\\
%
%\hline\hline%
\end{minipage}
\end{tabular}}}
\caption{Behaviour of the artifact realising a timed CNP, encoded in the \respect{} language}
%
\labeltab{cnp-spec}
\end{table*}
\appendix
%=======================================================================
\chapter{Related Documents and Publications}
\label{publication}
%=======================================================================
The updated list of articles, papers and documents about \respect{} can be
found at the official \respect{} website
\begin{center}
\texttt{http://www.alice.unibo.it/xwiki/bin/view/ReSpecT/}
\end{center}
\begin{itemize}
\item \cite{respect-scico01} -- describes the tuple centre
coordination model;
\item \cite{respect-entcs48} -- describes the \respect{} language used to specify
behaviour of tuple centre as coordination laws;
\item \cite{respect-coord97} -- describes the fundamental concept of
programmable coordination medium;
\item \cite{respect-sac98} -- describes the expressive power of \respect{} tuple centre;
\item \cite{tucson-aamas99} -- introduces \tucson{} as Coordination Model/Infrastructure
for {I}nternet Application Development;
\item \cite{coord-aiia00} -- describes the concept of hybrid coordination model;
\item \cite{coordbook2001} -- book about coordination models, technologies and applications
for {I}nternet agents;
%\item \cite{himat-hpcn00} -- describes \tucson{} topology and security model suitable
%for mobile agents;
%\item \cite{soda-aoseI} -- describes the \soda{} software engineering methodology,
%whose design and development part can be supported by \tucson{};
%\item \cite{ctx-ubiquitous} -- introduces the notion of Agent
%Coordination Context;
%\item \cite{tuprolog--padl2001} provides a general overview about
%\tuprolog{} project and technology;
\end{itemize}
%=======================================================================
\chapter{Document History}
\label{history}
%=======================================================================
\begin{table}[h]
%
\begin{center}{\small\tt
\begin{tabular}{p{3cm}|p{8cm}|p{2cm}}\hline\hline \\
\large{Date} & \large{Action} & \large{Responsible} \\\\ \hline\hline\\
2008-04-05 & The document is created & macasadei \\
\hline
% 2002-31-05 & minor revision & edenti \\
% \hline
% 2002-09-21 & major revision & aricci \\
% \hline
% 2004-07-10 & major revision & aricci \\
% \hline
% 2004-10 & major revision & aricci \\
% \hline
% 2006-11 & updates to 1.4.5 & aricci \\
% \hline
\end{tabular}
}\end{center}
\end{table}
%=======================================================================
\chapter{Planned Development of this Document}
\label{future}
%=======================================================================
The following arguments/chapters are work in progress and will be
added as soon as possible:
\begin{itemize}
%
\item Detailed description of the concept of \respect{} tuple centre as a means to build concurrent systems on a single node%
\item the relations between \tucson{} and \respect{}: \tucson wraps a \respect{} tuple centre by adding new services and putting it in a distributed context.
\item the twofold nature of \respect{} as a coordination language and a technology to actually develop concurrent systems.
\item Description of the entire \respect{} Java API.
\item Description of the Java tools for inspecting \respect{} tuple centres and related coordination laws.
\item Of course, development of the previously mentioned tools.
%
\end{itemize}
%=======================================================================
\bibliography{tucson}
\bibliographystyle{abbrv}
%=======================================================================
%\chapter{Demos}
%=======================================================================
%-----------------------------------------------------------------------
%\section{philosophers}
%-----------------------------------------------------------------------
%-----------------------------------------------------------------------
%\section{tictactoe}
%-----------------------------------------------------------------------
%-----------------------------------------------------------------------
%\section{multimedia}
%-----------------------------------------------------------------------
%-----------------------------------------------------------------------
%\section{demolux}
%-----------------------------------------------------------------------
%-----------------------------------------------------------------------
%\section{chat}
%-----------------------------------------------------------------------
%-----------------------------------------------------------------------
%\section{workgroup}
%-----------------------------------------------------------------------
%=======================================================================
%\chapter{Known Bugs}
%=======================================================================
%=======================================================================
%\chapter{ToDo}
%=======================================================================
%=======================================================================
%\chapter{PAQ (probably asked questions) }
%=======================================================================
\end{document}
%--------------------------------------------------------------------------------
\section{Basic Computations on Tuples}
%--------------------------------------------------------------------------------
\respect{} is a Turing equivalent language. The basic construct concerning selections and loops are realised by means of reaction triggered on the primitive invocation.
%
For instance:
%
% SELECTION (1)
%
Suppose to
%
% SELECTION (2)
%
Another example: suppose you want to insert a tuple is\_greater(X,Y) whenever a tuple compare(X,Y) is inserted in tuple centre if X is greater than Y, supposing that X and Y are both numbers;
%
viceversa a tuple is\_less(X,Y) if X is less than Y.
%
A set of reactions realising the behaviour is:
\begin{verbatim}
reaction(out(compare(X,Y)),(
X > Y,
out_r(is_greater(X,Y)) )).
reaction(out(compare(X,Y)),(
X < Y,
out_r(is_less(X,Y)) )).
\end{verbatim}
NOTA:
ReSpecT \UTF{00E8} Turing Equiv:
come fare loops
come fare selezioni
come fare procedure...
come fare ricorsioni
NOTA:
Turing equivalent --> LOOP
%--------------------------------------------------------------------------------
\section{Basic idioms and patterns}
%--------------------------------------------------------------------------------
\subsection{Defining the coordination primitives}
%
% Esempi
%
%
%
%
COSA CI FACCIO
- creazione di nuove primitive: es in\_all e rd\_all
- leggi di coordinazione: es synch
- interoperabilita fra agenti
-TUTTE quelle della presentazione..