\documentclass{sig-alternate}
%\documentclass[10pt,twocolumn]{article}

\usepackage{graphicx,epsfig}
\usepackage{url}
\newcommand{\tuple}[1]{\texttt{[{#1}]}}
\newcommand{\msgclass}[1]{\emph{{#1}}}
\def\more-auths{%
\end{tabular}
\begin{tabular}{c}}

%\setlength{\overfullrule}{5pt} % mark overfull hbox's
%\renewcommand{\baselinestretch}{1.8}
\begin{document}
\title{Decentralized Orchestration of Business Processes in Service-oriented Architectures}
%\numberofauthors{2}
%
%\author{
%    \alignauthor G.~Li \hspace*{3mm}  E.~Fidler \hspace*{3mm} H.-A.~Jacobsen \hspace*{3mm} A.~Cheung \hspace*{3mm} V.~Muthusamy \hspace*{3mm} P.~Wan \hspace*{3mm} S.~Mankovski \\
%    \affaddr{Middleware Systems Research Group, University of Toronto} \\
%}

\author{G.~Li \hspace{0.3cm} E.~Fidler \hspace{0.3cm} H.-A.~Jacobsen\hspace{1.3cm}\\ A.~Cheung \hspace{0.3cm} V.~Muthusamy \hspace*{3mm}  P.~Wan  \hspace*{15mm}
S.~Mankovski \\
    \affaddr{Middleware Systems Research Group ~~University of Toronto~~~~~~Cybermation Inc.}
}

%\institution{ Middleware Systems Research Group~~~~~University of Toronto, Canada\\
%}


%\toappear{Copy Right,To appear in the ACM/IFIP/USENIX 6th
%International Middleware Conference, Grenoble, France}

%%%               Embalming Technique, June 1991, Alfaretta, Georgia.}


\maketitle


%\begin{abstract}
%
%We develop a content-based publish/subscribe platform, cal\-led
%PADRES, which is a distributed middleware platform with features
%inspired by the requirements of workflow management and business
%process execution. These features constitute original additions to
%publish/subscribe systems and include an expressive subscription
%language, historic, query-based data access, composite
%subscription processing, a rule-based matching and routing
%mechanism, and the support for the decentralized execution of
%workflow applications. PADRES serves as runtime environment for
%the decentralized execution, control, and monitoring of workflow
%and business processes.
%
%\end{abstract}

%=====================================================================================
\section{Introduction}
\vspace*{-1mm}

The PADRES~(Publish/subscribe Applied to Distributed REsource
Scheduling) aims to create a distributed content-based
publish/subscribe~(p/s) system. The project is a collaboration
between the Middleware Systems Research Group at the University of
Toronto and Cybermation Inc. The primary research focus of PADRES
is applying and extending the content-based p/s paradigm to fit
the requirements of workflow management and business process
execution in a large-scale distributed environment (e.g. hundreds
of nodes, thousands of users). Specifically, PADRES is seen as a
message-oriented middleware layer for such a system, although some
non-typical middleware features such as event correlation and
historic data access in p/s are included. A secondary goal of
PADRES is to seamlessly connect centralized messaging systems. By
providing bindings for existing messaging formats, other messaging
systems can be connected as PADRES clients and can communicate
with each other. PADRES can \emph{federate} disparate messaging
systems to support distributed applications, such as distributed
workflow management and business process execution.

Distributed business process execution in content-based p/s
systems is the focus of this demonstration. PADRES is
distinguished from existing content-based p/s systems by the
following novel features inspired from the requirements of
supporting the decentralized execution and management of business
processes. Event correlation, a powerful subscription language and
matching engine, seamless access to historic data, highly scalable
message routing, and flexible network links are several of the key
features.

First, the PADRES subscription language is based on the
traditional \tuple{attribute, operator, value} predicates used in
several existing content-based p/s
systems~\cite{SIENA,Rebeca,icfi05}. This traditional language is
augmented by the use of \emph{composite
subscriptions}~\cite{gli-middleware05,icfi05}. Composite
subscriptions are a novel concept of combining several
\emph{atomic subscriptions}. Composite subscriptions provide a
higher level view of events for clients by combining information
into higher level concepts through aggregation or through logical
operators. PADRES explores sophisticated event correlations in p/s
networks by allowing subscribers to express composite
subscriptions. Predicates in composite subscriptions can contain
variables for correlating events matching the individual composite
parts (i.e., the atomic subscriptions.) For example, a composite
subscription \{\{\tuple{appl, eq, \$x} \tuple{task, eq, B}...\}
\emph{and} \{\tuple{appl, eq, \$x} \tuple{task, eq, C}...\}\} is
satisfied when both task \emph{B} and \emph{C} have successfully
executed and are part of the same application. The matching engine
for subscription and publication matching in PADRES is built using
a Rete-based rule engine~\cite{Rete}. The rule engine is a
powerful method of performing complex content-based matching, and
naturally supports composite subscriptions.

Second, unlike existing p/s systems, PADRES allows the subscriber
to subscribe to data published in both the {\it future} and the
{\it past}. For future publications, PADRES uses the standard p/s
messaging paradigm. Clients can subscribe to historic data
(publications) by specifying \emph{time range} predicates in their
subscriptions.  Historic databases are attached to the brokers
thought database bindings. Upon receiving a request for the
historic data, the brokers re-publish relevant publications from
their databases.  From the client's point of view, PADRES
transparently delivers both past and future publications in the
same manner. The subscription language supported in PADRES allow
clients to correlate past and future publications through temporal
joins.


%================================================================================
\section{Related Work}
\vspace*{-1mm}

There are several existing p/s systems that share some of the
features of PADRES. The PADRES content-based routing protocol is
similar to the protocol used in SIENA~\cite{SIENA}, extended with
the subscription merging concept of Rebeca~\cite{Rebeca}. PADRES
relies on mandatory advertisements to optimize subscription
propagation. The PADRES matching engine is built using the
Rete-based rule engine. There is essentially nothing in the
literature about using the Rete algorithm or a rule engine in this
manner. The historic data access methods in PADRES is unique in
the p/s context. There is some work on propagating historical
publications, but only in the limited context of mobile
clients~\cite{Rebeca:historic}.

Event correlation is an important concept for the network
management application and active database~\cite{compositeEvent}
contexts and have not received much attention in the p/s
literature. An instance of a composite event is formed by a
temporal or causal combination of constituent event instances. For
example, a sequence operator. $E_C = (e_1;e_2)_t$ means that if
the event $e_1$ is satisfied before $e_2$ within the time
difference $t$, the composite event $E_C$ is satisfied. In the
context of p/s this could be cast into a \textit{composite
subscription} concerned with the temporal state of the matched
subscription expressions. For example, a subscription $S_C$ can be
defined as $(s_1;s_2)_t$, where $s_1$ and $s_2$ are conventional
expressions comprising predicates. The semantic of such a
subscription is that the subscriber wants to get the notification
only if there occur two events $e_1$ and $e_2$ within the time
difference $t$ such that $e_1$ satisfies $s_1$ and $e_2$ satisfies
$s_2$.


%==================================================================================

\section{PADRES System Description}

The PADRES system is a distributed content-based p/s system which
consists of a set of brokers connected by a peer-to-peer overlay
network. Clients connect to brokers using Java Remote Method
Invocation (RMI) and Java Messaging Service (JMS).



\begin{figure}[b]
\centering \epsfig{file=network.eps,scale=0.58} \caption{PADRES
Network Architecture} \label{fig:network}
\end{figure}

{\bf Network Architecture}: The overlay network connecting the
brokers is a set of connections that form the basis for message
routing. The overlay routing data is stored in Overlay Routing
Tables~(ORT) at each broker. Specifically, each broker knows its
neighbors from the ORT. Message routing in PADRES is based on the
publication-subscription-advertisement model established by the
SIENA project~\cite{SIENA}. We assume that publications are the
most common messages, and advertisements are the least common
ones. A publisher issues an advertisement before it publishes. An
advertisement is an indication of the publications a publisher
will publish in the future and serves as optimization as described
below. Advertisements are effectively flooded to all brokers along
the overlay network. A subscriber may subscribe at any time. The
subscriptions are routed according to the Subscription Routing
Table~(SRT), which is built based on the knowledge of
advertisements. The SRT is essentially a list of
\tuple{advertisement,last hop} tuples. If a subscription overlaps
an advertisement in the SRT, it will be forwarded to the last hop
broker the advertisement came from. Subscriptions are routed hop
by hop to the publisher, who advertises information of interest to
the subscriber. Meanwhile, the subscription will be used to
construct the Publication Routing Table~(PRT). Like the SRT, the
PRT is logically a list of \tuple{subscription,last hop} tuples,
which is used to route publications. If a publication matches a
subscription in the PRT, it will be forwarded to the last hop
broker of that subscription until it reaches the subscriber. A
diagram showing the overlay network, SRT and PRT is provided in
Fig.~\ref{fig:network}. In this figure, step \emph{1)} an
advertisement is propagated from $B_1$. Step \emph{2)} a matching
subscription enters from $B_2$. Since the subscription overlaps
the advertisement at broker $B_3$, it is sent to $B_1$. Step
\emph{3)} a publication is routed along the path established by
the subscription to $B_2$. A subscription/advertisement covering
and merging scheme~\cite{icdcs05} is used to optimize
content-based routing by reducing network traffic and routing
table size, especially for applications with highly clustered
data.

\begin{figure}[t]
\centering \epsfig{file=brokercore.eps,scale=0.6} \caption{PADRES
Broker Architecture} \label{fig:brokercore}
\end{figure}

{\bf Broker Architecture}: The PADRES brokers are modular software
components built on a set of queues: one input queue and multiple
output queues. Each output queue represents a unique message
destination. A diagram of the broker internals is provided in
Fig.~\ref{fig:brokercore}. The matching engine maintains the SRT
and PRT. For example, in the PRT, subscriptions are mapped to
rules, and publications are mapped to facts. The rule engine
performs matching and decides the next-hop destinations of the
messages as a router. This novel approach allows for powerful
subscription semantics and naturally enables composites
subscriptions, which are more complex rules in the engine. Mapping
the subscription language to a rule language is relatively
straightforward. Extending this subscription language does not
require significant changes in the engine. Furthermore, rule
engines are well-studied, allowing PADRES to take advantage of
existing research. The rule-based matching is quite efficient,
especially for composite subscriptions.



%=====================================================================

\section{Business Process Execution}
\label{sec:workflow}

\vspace*{-2mm}

\begin{figure}[btph]
\centering \epsfig{file=SOA.eps,scale=0.4}
\caption{Service-oriented Architecture of PADRES} \label{fig:soa}
\end{figure}

A distributed p/s system offers a loosely-coupled messaging
paradigm, which is a natural fit for the decentralized execution
of business processes. Fig.~\ref{fig:soa} shows the
service-oriented architecture of the decentralized business
process management system based on PADRES. The business process
managers and web service agents are clients of the p/s system. In
our approach, business process specifications are defined using
Business Process Execution Language~(BPEL). The process itself
could be a web service which is a composition of other web
services and activities. We refer to \emph{tasks} in the rest of
this paper. PADRES provides a distributed environment for
decentralized business process execution. Business process manager
could start an execution instance by issuing a trigger
publication. The execution is performed in a fully decentralized
manner without the interference of a centralized manager. All
interaction, message routing, and data transfer are initiated,
controlled, and performed in the p/s layer. PADRES could invoke
web services through the agents using p/s messages. It also
provides interfaces to internet users so that they could access
the decentralized executed web services. The interface supports
both synchronous and asynchronous calls.


\subsection{Business Process Translation}

Business processes are specified in BPEL detailing the logic of
tasks and the various dependencies between tasks. In order to
execute a process in PADRES, the BPEL files are translated into a
set of p/s messages. Each task maintains a {\it dependency
subscription}, which encode the dependencies among tasks. In the
diamond process shown in Fig.~\ref{fig:wrapper}, for instance, the
task \emph{B} subscribes to messages of task \emph{A}. If the
subscription is matched, a notification is delivered to the agent
of \emph{B}. This signals the agent that task \emph{B} is ready to
run. A dependency subscription may be a composite subscription, as
a task depends not only on all its predecessor tasks, but also on
resources, such as data. {\it Advertisements} and {\it task
execution information} are generated from the BPEL to establish
subscription routing pathes and provide task execution parameters.


\begin{figure}[t]
\centering \epsfig{file=wrapper-1.eps,scale=0.45}
\caption{Business Process Deployment} \label{fig:wrapper}
\end{figure}

\subsection{Business Process Deployment}
\label{sec:deploy}

The goal of process deployment is to send the subscriptions and
advertisements generated from the description file to
corresponding task agents. Fig.~\ref{fig:wrapper} shows how a
message is \emph{injected} to an agent. Messages are wrapped into
an \emph{envelope}, which is an agent control publication. The
agent subscribes to wrapper envelopes by default. It extracts the
subscription from the received wrapper envelope, and issues the
subscription as its own. The same process applies for
advertisements. After all the subscriptions and advertisements are
injected, the dependency information of the process is set up and
the agents are ready to receive and publish information to drive
the process execution. This deployment is performed entirely in
the p/s layer.

A process deployed in the p/s network can be modified dynamically.
If we want to remove a task from a process, the corresponding
agent is asked to unsubscribe its dependency subscriptions, and
any successor task agents are asked to modify their subscriptions.
This is done in the same message injection-based manner as the
deployment phase. The change only effects related activity agents.

\subsection{Business Process Execution}

The process is ready to execute after the deployment phase. An
agent is a bridge between a web server and PADRES network. Agents
act as both subscribers and publishers. It allows PADRES broker to
invoke web services and enables web servers communicate with each
other through the p/s messaging paradigm, realizing the
coordinated execution of the business process. The manager
triggers the first task in the process to start a new instance,
which is driven by events of finished tasks. If a task is
finished, its agent publishes a message which will trigger the
successor tasks. Execution continues until all the tasks defined
in the process are completed. The key to process execution are
dependency subscriptions, which determine the execution order and
data resources of the tasks. The message routing is automatic and
transparent to the process management layer.

Dependency subscriptions are composite subscriptions, If a task
has more than one predecessor task, it will not be executed until
all the predecessor tasks are completed. The use of composite
subscriptions allows clients to specify complicated task
dependencies without requiring significant processing or storage
capabilities in the agents. Essentially, a distributed p/s system
with composite subscriptions makes the execution of business
process efficient in terms of matching performance, massage
latency, and bandwidth.

Each process execution instance has a unique instance ID. That is,
multiple instances of the processes can be executed concurrently
without interfering.


%===============================================================================


%======================================================================================

%\section{Discussion}
%
%There are several advantages of using a p/s system for workflow
%management. First, workflows are by nature event-driven. A
%workflow is started by a trigger issued by a workflow manager
%located anywhere on the network and is driven by publication
%messages of finished tasks (i.e., succeeded or failed.)  Through
%p/s routing, messages among task agents are automatically and
%transparently routed to the appropriate agents and the workflow
%manager does not interfere this process once execution starts.
%Second, workflows can easily be executed across multiple
%platforms, as the p/s paradigm seamlessly supports cross-platform
%applications in a distributed environment only requiring an agreed
%upon message format for p/s messages. Third, the decentralized
%solution for executing workflows in a p/s system, avoids the
%single point of failure and potential scalability bottleneck of a
%centralized solution. Fourth, the monitoring and control of
%workflow executions are flexible. Monitoring is a natural fit for
%the p/s paradigm, since the workflow manager can subscribe to any
%task execution or status information. Furthermore, it is easy to
%add, modify or delete tasks from a workflow. The modification can
%be performed dynamically by having task agents unsubscribe and
%re-subscribe, for instance. Fifth, concurrent execution of several
%workflow instances is possible.
%
%In this paper we have provided an overview of a decentralized
%approach to workflow execution and management based on PADRES. Our
%prototype is implemented in Java with JDK 1.4.2 using Rete-based
%approach as message routing engine. To accommodate workflow
%processing, the standard p/s paradigm had to be significantly
%extended. This involved the development of an expressive
%subscription language, supporting composite subscriptions,
%variable bindings in subscriptions, subscriptions to historic
%data, and a time-based mechanism to correlate future and past
%data.
%
%An evaluation of PADRES proves that our rule-based matching approach
%works efficiently. It takes about 5 {\it ms} to route a publication
%against 200,000 subscriptions, while a matching algorithm that is
%similar to the predicate counting algorithm~\cite{predcount} takes
%about 82 {\it ms}; another naive matching algorithm which linearly
%scans the routing table takes about 299 {\it ms}. Moreover, the
%workflow management system built with PADRES successfully performs the
%decentralized execution of workflows and workflow monitoring based on
%composite subscriptions and historic data access. The network traffic
%is reduced by 63 \% compared to a centralized approach in which the
%centralized workflow manager must collect all event information and
%decide what task to execute next in the workflow.



\section{Demonstration}
\vspace*{-2mm}

\begin{figure}[btph]
\centering \epsfig{file=demo.eps,scale=0.5} \caption{Demo
Configuration} \label{fig:demo}
\end{figure}

The objective of the demonstration is to show the decentralized
execution of business process with the PADRES system.  The
business processes are physically distributed over eight agents
connected to five brokers, as show in Fig.~\ref{fig:demo}. The
five brokers are connected to form an overlay network over three
physical nodes. In the demonstration the nodes will be laptop
computers. The physical and logical network organization of the
demonstration is shown in Fig.~\ref{fig:demo}.

In the demonstration we plan to execute several business processes
consisting of four to eight tasks. A task is a Web service or an
application ran as part of the business process execution.  The
demonstration of process deployment, process execution and process
monitoring is visualized through a monitor.  PADRES provides a
graphical interface which allows a user or developer to visualize
the network topology, the status of running brokers, the message
routing, and the execution business processes, as shown in
Fig.~\ref{fig:monitor}.

\begin{figure}[btph]
\centering \epsfig{file=monitor.eps,scale=0.35} \caption{PADRES
Monitor} \label{fig:monitor}
\end{figure}

{\bf Business process deployment}: Business processes are
transformed into a set of p/s messages (i.e., subscriptions and
advertisements.) The business process deployer component, acting
as a p/s client, issues the messages as publications addressing
the destination agents with content-based addresses. Agents
receive publications by subscribing to messages addressed to their
content-based address. Once all agents receive the corresponding
messages, the logic of the business process is encoded in the
network.  Since business processes are distinguished by names and
generation identifiers, multiple deployers can connect to the
broker network and deploy processes concurrently.

PADRES can trace messages by message identifier. This tracing
feature allows the user to observe messages online as they
traverse through the network. We use this function to trace all
the deployment messages related to a given business process. We
count the messages routed across each link and display the number
of messages on the link in the monitor. The deployment procedure
is visualized in the monitor by increasing the message numbers on
the link while the process deployment is in progress, as shown in
Fig.~\ref{fig:monitor-msg}.

\begin{figure}[b]
\centering \epsfig{file=monitor-msg.eps,scale=0.38}
\caption{Monitoring Process Deployment} \label{fig:monitor-msg}
\end{figure}

{\bf Business process execution}: To start a process execution,
the deployer issues a trigger, which is a publication indicating
the process name and generation identifier. The trigger is
received by the first task in the process. Tasks in this
demonstration are Web services and plain Java applications that
connect through an agent, a p/s client, to the PADRES network.
Agents publish the execution result when the tasks are finished.
We simulate the success and failure of tasks by interacting with
agents through a GUI. If a task succeeds, its successors task is
executed after receiving the status message; otherwise the
compensation functions are invoked, if they are defined in the
business process. We will demonstrate the process execution with
different success and failure scenarios.  We also trace the
execution messages through business process generation identifiers
to visualize the execution. The visualization is in the same as in
the deployment scenario.

{\bf Failure detection}: Failure detection functions are supported
in PADRES. We simulate the failure of a broker by stopping and
resuming a broker in the monitoring tool (a feature added for
demonstration purposes only.) Brokers emit periodic heartbeats to
indicated proper operation to their neighbors who subscribe to
heartbeat publications of their own neighbors and use a
timer-based mechanism to watch for missing heartbeats. A broker
failure is detected after a specific number of heartbeats are
lost. Failure-detecting brokers issue failure publications,
subscribed to by the monitor. The failed broker is colored red and
turns green in the broker overlay graph when the failed broker
comes back online in the monitor. This effect is also demonstrated
by unplugging a network cable between two physical nodes in the
overlay network. The failure is visualized in the monitor in the
same manner.

PADRES is an on-going project. A direction currently under
investigation is the discovery of resources in the distributed
environment and the static and dynamic planning and scheduling of
resources for a given business process.

\section{Acknowledgements}
\vspace*{-1mm}

{ \small We would like to thank the PADRES team for their help and
feedback in carrying out this research. The first generation of
students working on the project also include Matt Medland, David
Matheson, and Ferdous Jewel. Between May 2003 and April 2005, the
PADRES project was supported by Cybermation, Inc., CITO, and
NSERC. }

%\section{Demonstration}
%
%
%\begin{figure}[btph]
%\centering \epsfig{file=demo.eps,scale=0.5} \caption{Demo
%Configuration} \label{fig:demo}
%\end{figure}
%
%The objective of the demonstration is to show the decentralized
%execution of business process in PADRES system. We will
%demonstrate a content-based p/s network. Five brokers and eight
%agents run on three laptops. A business process deployer and a
%monitor are connected to the broker network. The PADRES component
%layout is shown in Fig.~\ref{fig:demo}. We have serval business
%processes consisting of four to eight tasks, each of which could
%be a web service itself. The demonstration of process deployment,
%process execution and monitoring is visualized in a monitor
%module. PADRES provides a graphical interface which allows a user
%or developer to visualize the network topology, the status of
%running brokers, the message routing, and the business processing,
%as shown in Fig.~\ref{fig:monitor}.
%
%
%\begin{figure}[btph]
%\centering \epsfig{file=monitor.eps,scale=0.35} \caption{PADRES
%Monitor} \label{fig:monitor}
%\end{figure}
%
%{\bf Deploy a business process} Business processes are transformed
%into a set of p/s messages~(e.g. subscriptions and advertisements)
%stored in a file. The process deployer reads the file, and issues
%the messages out as part of agent control publications indicating
%the destination agents. Agents receive the publications by
%subscribing to them. Once the agents get the corresponding p/s
%messages, the logic of the business process is encoded by the
%dependency subscriptions. We provide three simple business
%processes for this demonstration. The deployment is described in
%details in Section~\ref{sec:deploy}. Since business processes are
%distinguished by names, multiple deployers can connect to the
%broker network and deploy processes concurrently.
%
%The deployment procedure is visualized in the monitor. PADRES can
%trace messages by message ID. This tracing feature allows the
%online observation of messages as they traverse the network. We
%use this function to trace all the deployment messages related to
%this business process. We count the messages routing across each
%link and display the number of messages on the link in the
%monitor. The monitor visualizes the deployment by updating the
%message numbers on the link while the process deployment goes on,
%as shown in Fig.~\ref{fig:monitor-msg}.
%
%\begin{figure}[b]
%\centering \epsfig{file=monitor-msg.eps,scale=0.35}
%\caption{Monitoring Process Deployment} \label{fig:monitor-msg}
%\end{figure}
%
%{\bf Execute a business process} To start a process execution, the
%deployer issues a trigger, which is a publication indicating the
%process name and instance ID. The trigger is received by the first
%task in the process. Agents of tasks in this demonstration could
%execute the task or invoke a web service. Agents publish the
%execution result when the tasks are finished. We simulate the
%success and failure of tasks by interacting with agents. If a task
%is success, its successors are executed after receiving the
%notification; otherwise the compensation functions are invoked if
%they are defined in the business process. We will demonstrate the
%process execution in different scenarios. The concurrent process
%execution is allowed in PADRES as long as each instance has unique
%instance ID.
%
%We also trace the execution messages by process instance ID to
%visualize the process execution. The visualization is in the same
%manner as the deployment.
%
%{\bf Detect a failure} Failure detection functions are supported
%in PADRES. We simulate the crash and reboot of brokers by stopping
%and resuming a broker in the monitoring tool. The monitor uses
%heartbeats to guarantee the activeness of brokers. The crash of a
%broker will be detected by the monitor after a specific number of
%heartbeats are lost. The crashed broker turns in red in the
%visualized overlay graph and comes back to green when the broker
%is rebooted. We can also demonstrate the link failure by
%unplugging a cable. The link failure will be visualized in the
%monitor after a certain timeout period.
%
%%PADRES provides a graphical interface which allows a user or
%%developer to visualize the network topology, the message routing,
%%and the business processing, as shown in Fig.~\ref{fig:monitor}.
%%The monitor can display the status of a running broker. Through
%%the monitor run-time monitoring can be performed to help debug and
%%troubleshoot workflows in a design environment and perform
%%real-time execution monitoring in a production environment. The
%%monitor can display the status of a running workflow instance by
%%subscribing to messages indicating the status of task executions.
%%It can visualize the workflow execution and message exchange
%%between tasks. The monitor can view the details of task instances,
%%i.e., the value of a particular variable in a task.  Furthermore,
%%the monitor can modify the value of a variable, if necessary,
%%through \emph{agent control messages} indicating the new value.
%%Further run-time control can be exerted with \emph{agent control
%%messages}. The manager can ask the workflow instance to pause,
%%resume, or halt. The workflow control works on all concurrent
%%running instances or a particular instance by identifying the
%%instance ID. With the historic data access supported by PADRES,
%%the manager can view and manipulate previously executed and
%%currently executing workflow instances by issuing historic queries
%%and correlating historic and future queries through temporal
%%joins. The monitor can manipulate the instances by date and
%%execution status. Moreover, through composite subscriptions, the
%%executing and previously executed workflow instances can be
%%monitored at the same time. Based on all this information,
%%statistics over workflow execution instances can be generated to
%%provide a high-level analysis of the system operation.
%
%
%
%PADRES is an on-going project. A direction currently under
%investigation is the discovery of web service resources in the
%distributed environment, the static and dynamic planning and
%scheduling of these resources for a given business process.
%
%\section{Acknowledgements}
%\vspace*{-1mm}
%% ***   Put your Acknowledgements here.   ***
%
%{ \small
%
%We would like to thank the PADRES team for their help and feedback
%in carrying out this research. The first generation team members
%also include Matt Medland, David Matheson, and Ferdous Jewel.
%Between May 2003 and April 2005, the PADRES project was supported
%by Cybermation, Inc., CITO, and NSERC.
%
%}
%\section{Acknowledgements}
%We would like to thank the members of the PADRES team: Gerald
%Chan, Alex Cheung, David Matheson, Matt Medland, and Pengcheng
%Wan.

\bibliographystyle{abbrv}
%\footnotesize
\bibliography{padres}
\end{document}