{\em Parallelism} and {\em concurrency} are two separate concepts.
{\em Parallelism} indicates ability of performing parallel execution of 
	different components of the computation. Thus, its 
main aim is  {\em efficiency}.
 {\em Concurrency} indicates the
 ability to express concurrent execution of
	different components of the program. This is a {\em semantic}
	issue.
Both
the issues are of primary importance in the context of Internet-based
applications.
 Management of multiple
agents takes big advantage from parallelism,
while
  interacting
sessions or  managing multiple connections
represent  concurrency
issues.


Web-related applications are going to become, in our opinion, one of the major areas
of application of techniques for parallel execution. 
In the rest of this section we will analyze the two different forms of parallelism
that we envision as most promising for W-ACE. We distinguish between
{\em Intra-Parallelism}---exploitation of parallelism
    within a single browsing/serving activity---and 
{\em Inter-Parallelism}---exploitation of 
	 {\em ``parallelism''} between separate
    Internet sessions.


\subsubsection{Intra-Parallelism}
The concept of intra-parallelism originates from the exploitation of
parallelism within a single browsing/serving activity.
In both cases, this form of parallelism can be obtained by using
the basic support for parallel execution which is supplied by the
ACE parallel system. The ACE system supports both and-parallelism
and or-parallelism in  logic programs. 

{\em And-parallelism} attempts parallel execution of different
subgoals belonging to the current query. Thus, in a computation
like

\noindent
\hspace{.5cm}$?- \mbox{\em extract\_links}(L,Page), \mbox{\em extract\_pics}(P,Page)$

\noindent
the two subgoals can be solved in parallel. It is common
\cite{annals} to distinguish two flavors of and-parallelism:
{\em independent parallelism} which originates when
		the parallel subgoals are not allowed to affect
		each other's executions \cite{santa-barbara},
and  {\em dependent and-parallelism} where
		\cite{dependent,pasco} subgoals executed in
		parallel are allowed to share variables and compete
		for their bindings.

{\em Or-Parallelism} allows parallel execution of the 
	alternatives associated to a resolution step---i.e., allows
	to explore in parallel the different clauses that can
	be used to reduce the selected subgoal.
	Thus or-parallelism is a mechanism to speedup the exploration
	of the search space generated by a logic program.

In the previous work on ACE we
have studied mainly the issue of parallelism.
Nevertheless, the results we have achieved have the nice side-effect
of offering a very flexible language to express concurrency, as well
as very efficient mechanisms to implement it. 
In addition, as soon
as extra processors become available, 
concurrency in ACE becomes real parallelism.
In ACE, concurrency emerges from the fact that an intermediate language
is supplied which allows to express points where parallelism can
be exploited---i.e., notation that allows to define program components
that can be logically exploited in parallel. 
The  concurrent language supported by ACE consists of the following
components:
\begin{list}{$\bullet$}{\setlength{\topsep}{2pt}
			\setlength{\itemsep}{1pt}
			\setlength{\parsep}{0pt}
			\setlength{\leftmargin}{10pt}}
\item {\em and-concurrency:} the notation $p(X) \& q(Y)$  is used to
    denote conjunctions of subgoals in which the two subgoals can
    be run in parallel. The notation becomes slightly more complex
    if we allow dependences between the concurrent subgoals (we need
	to indicate the source of dependences---either manually
	or through a static analyzer).    
    Dependent execution in ACE is structured in such a way to respect
    the sequential semantics of the language \cite{dependent}.
	 Nevertheless, W-ACE allows us to specify for each 
	argument position in
    a concurrent subgoal whether such position should be treated as a 
    producer or consumer position. This can be supplied simply as mode
    declarations (in the same fashion as in Parlog), or 
	 by explicitly describing the dependence graph to be
	used during execution.
    This feature is extremely powerful, as it allows to 
    create separate computations and to use variables as unidirectional
    communication channels.
    
\item {\em or-concurrency:} ACE admits the declaration {\sf parallel}
    to indicate which procedures of the program have to be considered
    for or-parallel execution.
    
\end{list}
An and-concurrent execution has the following semantics: given a query
like $(p(X) \& q(Y)),r(X)$, then $p(X)$ and $q(Y)$ are concurrent, while
$r(X)$ is constrained to start its execution only after both $p$ and
$q$ have been completed. Thus, an implicit barrier is present at the
end of the parallel call. There are situations  where we do not want such
barrier to be present. The operator $\bar{\&}$ can be
used to this purpose---in $p(X) \bar{\&}q(Y)$, 
the first
subgoal to complete will  proceed with the continuation
of the parallel call, while the other will complete and disappear.


Regarding or-concurrency, W-ACE admits an extension that is currently
present also in ACE: the possibility of declaring a procedure to be
{\sf reactive}. This is aimed at capturing the behaviour typical of
guarded commands. A reactive procedure implies that, at the moment
of clause selection, the selection process will not consider one
clause at the time, in their textual order, but it will loop
through the different clauses in the procedure until a successful
head unification will be completed. This follows the same idea behind
Hoare's non-deterministic guarded commands. This, combined with the use
of producer/consumer and-parallelism (as described above), allows the
development of servers which can react to different kinds of stimuli
coming from the clients.



\smallskip\noindent
{\bf And-Parallelism in Web Applications:}
 Executions
over recursive data structures, data-parallel computations, producer/consumer
pipelined computations are all examples of executions which are very likely
to offer large amounts of and-parallelism \cite{santa-barbara}.

More specific to the case of W-ACE, the explicit use of notations to
indicate concurrency can be directly translated to parallel executions.
 This is typical, for example, of multiple agents which
are exploring different set of HTML documents searching for certain 
patterns/keywords.  
Another example is represented by efficient servers which are implementing
various forms of ``distributed'' management of data. Queries arriving
from client applications can be 
\begin{list}{$\bullet$}{\setlength{\topsep}{2pt}
			\setlength{\itemsep}{1pt}
			\setlength{\parsep}{0pt}
			\setlength{\leftmargin}{10pt}}
\item partitioned between different servers that are maintaining different
	databases---this does not involve anything more than an
	independent form of concurrency;
\item processed through a pipelined organization of multiple servers---this
	requires communication between different active entities, i.e.,
	a form of dependent and-concurrency.
\item assigned to independent instances of servers, to allow overlapping
	of requests handling.
\end{list}



\smallskip\noindent
{\bf Or-Parallelism in Web Applications:}
 In general
or-parallelism is associated to the concept of {\em search}. Thus 
most of the applications which involve  a sufficiently
complex search  are suitable to 
this form of parallelization. 
Typical examples are:
\begin{list}{$\bullet$}{\setlength{\topsep}{2pt}
			\setlength{\itemsep}{1pt}
			\setlength{\parsep}{0pt}
			\setlength{\leftmargin}{10pt}}
\item agents which are performing a search over the nodes of
	the HTML graph; alternative paths emanating from a given
	node can be explored in parallel;
\item analysis of data often requires non-deterministic steps---e.g.,
	parsing data to identify their structure with respect to a
	given structural description (e.g., a grammar, a finite state
	automata);
\item searching for an element from a given set which satisfies a
	certain property (e.g., looking for dead links between the
	set of all links in an HTML document).
\end{list}

\smallskip\noindent
{\bf Modal Parallelism:}
An additional form of parallelism emerges from the introduction of
modality in the language. The operations to be performed across different
worlds can be easily cast into parallel executions. {\em Necessity} modal
operators ($\Box$) require the verification of a goal across all the
worlds belonging to a certain modal interpretation (e.g., all the 
logical theories currently accessible through the HTML graph); 
this verification can be done in parallel (exploring concurrently 
different worlds). This
is a generalization of and-parallelism, and the W-ACE system can be
easily extended to accommodate for it.
{\em Possibility} modal operators ($\Diamond$) are required to verify
whether a given goal holds in at least one of the accessible worlds; this
can also be attempted in parallel, by considering alternative accessible
worlds in parallel. This can be seen as a generalization of or-parallelism.


\subsubsection{Inter-Parallelism}

The possibility of expressing parallel computations and 
communication assumes
 extreme importance when dealing with different executions which should be
capable of interacting. The mechanisms required for this sort of computations are
the same described in the previous section. W-ACE goals represents the different concurrent
computations while {\em shared} variables are used as communication channels
between them.

These mechanisms are actually sufficient by themselves to cover most
of the interesting cases emerging from Web-related applications.
Nevertheless, there are some new issues that have been recently emerging
within the Internet community which require more sophisticate
mechanisms:
\begin{list}{$\bullet$}{\setlength{\topsep}{2pt}
			\setlength{\itemsep}{1pt}
			\setlength{\parsep}{0pt}
			\setlength{\leftmargin}{10pt}}
\item the notion of a single server supplying HTML documents to the
	various clients is progressively overcome by the notion of
	servers providing more comprehensive services
	(e.g., access to knowledge bases).
	The need to perform complex computations as answers to client
	requests may require the need to allow servers to distribute
	computations across different connected hosts. Analogously,
	client themselves can use HTTP protocol to distribute a 
	computation between different computing resources.
	This may require  assigning execution of
	certain computations to specific resource (e.g., a specific
	host). 

\item  in various situations (e.g., independent agents that decide
	to combine their results) we can envision the need to 
	combine independent computations.
	W-ACE provides this feature, through the predicate
	{\sf meet}. A careful memory organization allows to combine with minimal
	effort the memory images of two W-ACE workers. 
\end{list}


\subsubsection{Serving HTML Clients}

The problem of having a server handling multiple clients through
Web-connections has been largely underestimated. The issue, as
pointed out by Szeredi \cite{aurora-html}, is of extreme importance:
modern ``intelligent'' servers are AI-like applications, which
are large and expensive; maintaining a separate running copy of the
server for each client connection may not be a suitable solution,
since 
\begin{list}{$\bullet$}{\setlength{\topsep}{2pt}
			\setlength{\itemsep}{1pt}
			\setlength{\parsep}{0pt}
			\setlength{\leftmargin}{10pt}}
\item the impact of the multiple running computations on the server's
	side may be unbearable;
\item keeping separate server processes makes interactions between
	them (if necessary, e.g., accessing and modifying a common
	database) extremely challenging to program and expensive
	to maintain.
\end{list}

On the other hand, the ideal situation of handling the different 
connections within the scope of a single server can be as difficult
to realize within a sequential programming framework---and can easily
lead to  inefficient systems (which may force an unnatural sequentiality
between clients' requests).

The potential of using parallelism to serve different browsing sessions
has already been  pointed out in the literature. One good example,
within the area of Prolog,
can be found in Szeredi's work \cite{aurora-html}. Szeredi suggested
the use of the Aurora Or-Parallel system to handle this situation,
preserving the declarative nature of the program and with a good level
of efficiency.


\smallskip\noindent
{\bf W-ACE for Remote Diagnosis (Example):}
The application we considered is an intelligent system for the
diagnosis of Acid-base disorders \cite{bang}. The system was
originally developed in standard Prolog and was capable of supporting
a single interactive user session. Purpose of the program is to 
acquire successive details of data from the user in order to produce
one or more medical diagnosis.

The program was transformed into a Web-based application using
the preliminary  W-ACE prototype (the whole process
took hardly a day of work). The original organization of the resulting
system is shown in figure \ref{bang1}.
\begin{figure}[htb]
\centerline{\psfig{figure=bang1.pic.eps,width=.49\textwidth}}
\caption{General Structure of Diagnosis System}
\label{bang1}
\end{figure}
The diagnosis server is an independent running application, which
listens to a socket for queries and data coming from the HTML
pages (through a small CGI script, hidden in the W-ACE interface).
The server in this scheme is capable of serving a single client 
session at the time, suspending every time a client input is required.
A tight interaction between HTML browsing and server execution is
kept (using backtracking to ``follow'' the user if he decides to
use the {\sf back} button of the browser).

The serious problem in this context is
serving multiple clients. Various solutions to this problem have
been envisioned in \cite{aurora-html}, ranging from developing a
server capable of directly handling multiple sessions (very complex
and leading to a loss of the logical structure of the server), to
using complex logic features ({\sf freeze}, {\sf continuations}).
Neither of these solutions is particularly attractive. 

The different sessions are {\em separate threads} of computation.
 Furthermore, in
order to make possible an efficient usage of resources, the different
threads should {\em share} the same resources as much as possible (thus,
spawning a new process for each client connection is not a viable
solution).

In \cite{aurora-html} an  solution to a similar problem is
proposed using an {\em or-parallel} Prolog system (Aurora). The solution
suffers of various drawbacks:
\begin{list}{}{\setlength{\topsep}{2pt}
			\setlength{\itemsep}{1pt}
			\setlength{\parsep}{0pt}
			\setlength{\leftmargin}{10pt}}
\item [1.] it is not particularly elegant, since different client connections
	have to be encoded as separate ``alternatives'' of a choice
	point;
\item [2.] alternatives of a choice point are {\em necessarily} independent,
	and cannot directly communicate. This means that only 
	independent client sessions can be directly modeled in this
	scheme. Communications can be realized in a very unnatural
	(and {\em expensive}) fashion through the use of unsynchronized
	side-effect predicates ({\sf assert} and {\sf retract}).
\item [3.] last but not least, or-parallelism does not gracefully offer
	ways of suspending branches (e.g., while waiting for some
	input from the client). Aurora's developer have tried to 
	solve the problem by introducing new explicit built-ins to
	suspend and resume branches.
\end{list}

The solution in W-ACE is very natural. Multiple client sessions can
be easily handled as separate subgoals, which are executed in
and-parallel---which better capture the ``coexisting'' nature of 
client sessions, instead of the unnatural ``alternative'' nature
attributed in the Aurora scheme. A loop like:

{\tt
\noindent
main(Sockets,Args) :-


   wait\_connection(Sockets,Inst),

  ( client\_execution(Sockets,Inst,Args) \&

\noindent
\hspace{.85cm}main(Sockets,Args)

  ).
}

\noindent
is used. Suspensions are automatically obtained thanks to the 
suspension mechanism used by dependent and-parallelism \cite{dependent}.
In the specific case of the diagnosis application, the different client
sessions are independent---thus the {\tt Args} argument is actually
empty. Communication with the browser is through separate sockets (one
per worker) and is completely transparent to the programmer.
The preliminary version of the Web-based diagnosis system has been
completed (figure \ref{bang2} shows a snapshot of an execution).

\begin{figure}[htb]
\centerline{\psfig{figure=bang2.ps,width=0.45\textwidth}}
\caption{Snapshot of Execution of Diagnosis Program}
\label{bang2}
\end{figure}

\smallskip\noindent
{\bf Interacting Clients (Example):}
In the previous example client sessions are non-interacting
and independent (same assumption as in \cite{aurora-html}).

There are many cases in which it is
desirable to allow clients to interact with each others. This may
range from the simple {\em indirect} interaction caused by accessing 
and modifying a common database, to the more complex case of
a {\em direct} client interaction, as in a multi-players game. 
Schemes like the one used in Aurora  do not support this pattern of execution---it
can be realized only using additional expensive mechanisms (communication
through common files). Traditional languages (e.g., Java) require
complex and explicit communication mechanisms (sockets, IPC messages).

On the other hand, the scheme adopted in W-ACE allows to avoid any
additional complexity. Since each separate client connection is
represented by a separate recursive subgoal, they can directly interact
via shared variables \cite{dependent}.  
We have tested this feature in a simple server application which
allows two client sessions to play tic-tac-toe
one against the other.

\subsubsection{Applications}

\noindent
{\bf Communicating Agents:}
Interacting agents has been
for long a relevant topic in the AI community; within the framework
of the WWW, this concept assumes a great importance; the search space
for agents traveling on the Web is extremely large, and concurrent,
interacting agents may lead to drastic reductions in search time.
Using traditional programming languages, the practical development
of communicating agents is a very challenging task (e.g.,
dealing with threads, communication, etc.).

W-ACE offers a framework where managing communicating agents
is extremely simple. Each agent is represented by a goal 
(i.e., a call to a predicate defining the agent); parallel execution
is readily available through the and-concurrent support;
communication is directly available through shared variables. For
example, a W-ACE top-level call to generate two communicating
agents will be as follows:
\begin{verbatim}
      ... mark([Ch1,Ch2]),
          In1=Ch1,In2=Ch2,
          Out1=Ch2,Out2=Ch1,
           (agent(1,In1,Out1) & 
            agent(2,In2,Out2)),...
\end{verbatim}
The two unidirectional communication channels ({\tt Ch1,Ch2}) are
set between the two agents. For example, agent 1 will send a 
message to agent 2 by instantiating its {\sf Out} channel in
the following way: {\tt Out = [Message | NewOut]}, where 
{\tt Message} is the message to be sent and {\tt NewOut} is a
new variable (representing the ``new'' access to the output
channel).

\smallskip
\noindent
{\bf Generalized Browsing:}
The browsing activity is strictly a single user-single step execution.
The user moves from one page to the other, but at any time he is
focused on only one document. Availability of concurrency allows
for various extensions:

\noindent
{\em 1. Concurrent browsing:} allows a single
 user to concurrently explore 
different paths of the HTML graph. This is easily realized by having
a client spawning separate processes to carry on the navigation of
the documents. The separate sessions may be independent (i.e., they
separately report results in different parts of the user interface),
or the may interact during the navigation---for example, one of the navigation sessions may attempt to explore a
document which has been explored previously by another session---this
can be avoided by having a shared representation of the HTML graph between
the different navigations.

\noindent
{\em 2. Cooperative browsing:}
it is also important to allow separate navigation sessions, eventually
initiated by different users, to interact. A good example of this is 
represented by the  principle of {\em annotating}
HTML documents \cite{annotated,nmsu-www1}.
 Members of a working team may be separately operating
via different browsing sessions (e.g., they are browsing the Web in
search of information on a given topic). The members of the team, even
if they are carrying on independent activities,  need to interact,
in order to avoid re-visiting twice the same document and to allow 
a member  of the team to gather information regarding 
documents visited by other members. 
This can be realized using communicating browsers
(e.g., shared database of annotations, shared
representation of the visited HTML graph, etc.)


