% File:    caise99.tex
% Author:  Holm Wegner, Florian Matthes, Patrick Hupe
% Date:    07-12-98
% Purpose: Einreichung für CAISE-99

\documentclass[10pt]{article}

\usepackage{a4wide}
\usepackage[latin1]{inputenc}
\usepackage{sts}
%\usepackage{sts-named}
\usepackage{palatino}

\parskip 0.4\baselineskip
\parindent 0pt

\begin{document}

\title{A Process-Oriented Approach to \\Software Component Definition}
\author{Florian Matthes \and Holm Wegner \and Patrick Hupe}
\date{{\small Software Systems Institute (STS)\\
Technical University Hamburg-Harburg\\
D-21071 Hamburg\\
\{f.matthes,ho.wegner,pa.hupe\}@tu-harburg.de}
}

\maketitle

%-----------------------------------------------------------------------
\begin{abstract}
Commercial software component models are frequently based on
\e{object-oriented} concepts and terminology (e.g., classes, methods,
messages, events) with appropriate binding, persistence and distribution
support. In this paper, we argue that a \e{process-oriented} view
on cooperating software components based on the concepts and terminology
of a language/action perspective on cooperative work \cite{Wino87} (e.g.,
actors, roles, conversations, speech acts, conversation histories)
provides a more suitable foundation for the analysis, design and
implementation of software components in business applications.

We first explain the relationship between data-oriented, object-oriented
and process-oriented component modeling and then illustrate our
process-oriented approach to component definition using three case
studies from projects with German software companies.

We also report on our experience gained in developing a class framework
and a set of tools to assist in the systematic process-oriented
development of business application components. This part of the paper
also clarifies that a process-oriented perspective fits well with
today's object-oriented language and system models.
\end{abstract}

%-----------------------------------------------------------------------

\section{Introduction and Rationale}
\label{Introduction}

Organizations utilize information systems as tools to support
cooperative activities of employees within the enterprise. Classical
examples are back-end information systems set up to support
administrative processes in banks, insurances, or processes in enterprise
resource planning.

Driven by various factors (availability of technology, group
collaboration issues and organizational needs), there is a strong demand
for more flexible and decentralized information system architectures
which are able to support

\begin{itemize}

  \item cooperation of humans over time (persistence, concurrency and
  recovery),

  \item cooperation of humans in space (distribution, mobility, online
  and offline users), but also

  \item cooperation of humans in multiple modalities (batch
  processing, transaction processing, asynchronous email
  communication, workflow-style task assignment, ad-hoc information
  sharing).

\end{itemize}

Another crucial observation is the fact that cooperation support can no
longer be restricted to employees (intra-organizational workflows) but
also has to encompass inter-organizational workflows involving
customers, suppliers, tax authorities, banks, etc.

The objective of our research is to identify abstractions and
architectural patterns which help to design, construct and maintain
software components in such a ``cooperative information system''
environment \cite{DDJ+97,DDJ+98}

In Section~\ref{Approach}, we argue that the successful step in information
system engineering from data-oriented to object-oriented information
system modeling should be followed by a second step from object-oriented
to process-oriented system engineering. Only a process-oriented
perspective allows software architects and organizations to identify and
to reason about actors, goals, cooperations, commitments and
customer-performer relationships which are crucial in a world of
constant change to keep the organizational objectives and the objectives
of the supporting information systems aligned.

In Section~\ref{CaseStudies}, we illustrate our process-oriented approach to
component definition using three case studies from projects with German
software companies.

Details of the underlying process and system model are given in
Sections~\ref{Framework} and \ref{SET}. In these sections, we also
report on our experience gained in developing a class framework and a
set of tools to assist in the systematic process-oriented development
of business application components.  This part of the paper also
clarifies that a process-oriented perspective fits well with today's
object-oriented language and middleware models.

%-----------------------------------------------------------------------

\section{Approaches to Component Definition in Information Systems}
\label{Approach}

In this section, we briefly review the evolution of information system
architectures to highlight the benefits of a process-oriented approach
to component definition.

Figure~\ref{DataObjectAgent} summarizes the main result of this section:

\begin{itemize}

  \item Interaction between system components in an information system
  can be understood at three levels, namely at the level of \e{data}
  access, \e{object} interaction and at the level of \e{process}
  coupling.

  \item At each level, interfaces between system components should be
  declared in an abstract, system-independent syntax which also
  provides a basis for the systematic implementation of
  vendor-independent middleware.

  \item Abstract concepts of the interface language are mapped to
  concrete implementation concepts of the participating system
  components.

  \item A higher-level interface language includes concepts of the
  lower-level interface language but often imposes additional
  restrictions on the use of these concepts. For example, CORBA IDL
  provides data attributes and attribute types similar to record
  attributes and SQL domains, but also provides mechanisms for data
  encapsulation at the object level.

\end{itemize}

\abbildung{0.5}{DataObjectAgent}{Three Approaches to Component Definition in Business Information Systems}

%- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

\subsection{Data-Oriented Component Definition}

Database research and development focused on the entities and
relationships of an information system and led to the development of
conceptual, logical and physical data models, generic systems and tools
as well as software development processes to support the analysis,
design and efficient implementation of (distributed) data components.

Today, virtually all organizations have conceptual models of the
information available in their back-end information systems and
systematic mechanisms to develop and change applications to satisfy new
information needs.

For information stored in relational databases, SQL as the
``intergalactic dataspeak'' \cite{Manifesto90} provides both, a language for the
exchange of vendor-independent data description (schemata, tables,
views, \ldots) as well as a language for (remote) data access (via APIs
like ODBC, JDBC, \ldots; see also Figure~\ref{DataObjectAgent}).

Moreover, SQL databases provide generic tools for interactive and
programatic data access, authentication and access-control which are
crucial for the safe re-use of data components in different parts of the enterprise.

The architecture of many non-relational information systems (also of
``modern'' systems like Lotus Notes, Microsoft Exchange and data
warehouses) is also often described best as a collection of
distributed data components.

%- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

\subsection{Object-Oriented Component Definition}

In modern client-server architectures and in cooperating information
systems, the information assets of an enterprise are modeled (and often
implemented) as collections of distributed and persistent objects
interacting via messages and events.

The interfaces for these components are defined as enriched signatures
in object-oriented languages using concepts like classes, objects,
(remote) references, attributes, methods, qualifiers, subclasses,
interfaces, events, exceptions etc.

These object and component models (CORBA, DCOM, JavaBeans, etc.)
describe the interaction between components by (a)synchronous method
invocation extending and adapting the semantics of dynamic method
dispatching in object-oriented programming languages (see also
Figure~\ref{DataObjectAgent}).

The advantage of object-oriented component models over pure data models
on the one hand side and over purely procedural (remote) function
libraries on the other hand is their ability to describe semantic
entities which are meaningful already at the analysis and at the design
level. The often quoted classes \p{Customer} and \p{Shipment} are
examples for such high-level entities.

As exemplified by ODMG using CORBA IDL, an object-component model can
also be used to describe ``data-only'' components, simply by omitting
elaborate method and message specifications and only providing
(set-oriented) get, set, insert and delete methods.

An object-oriented component interface definition defines a contract
between the user of this component and the implementor of the component.
They both have to agree on the set of valid messages and on the argument
types of these messages.

%- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

\subsection{Process-Oriented Component Definition}
\label{Process}

An object-oriented component definition is ``richer'' than a
data-oriented component definition since the methods (shipment.create,
shipment.addItem, shipment.replaceItem, shipment.deliver) provide a more
suitable protocol for the interaction between a client and a server component
than a sequence of raw SQL statements working on a shipment table.

However, we still see the following deficiencies of object-oriented
component definitions which call for an even richer process-oriented
component definition:

\begin{itemize}

  \item The interface of a software component rarely consists of a
  single object interface but of a large number of highly interrelated
  object interfaces.\footnote{For example, Microsoft Word 7.0 is a
  software component which has approximately one hundred interface
  classes.} Often it becomes necessary to restrict access of a
  specific client to only a subset of these classes and their methods.

  \item Frequently it is necessary for a server to manage multiple
  execution contexts, for example, one for each concurrent client
  session. Clients then often have to pass a \e{session} handle as an
  extra argument to each of these methods. This session handle is also
  required for transactional database access.

  \item In particular in business applications, it is desirable to
  enforce restrictions on the admissible execution order of certain
  method calls (``A shipment can only be send after a payment has been
  received'').  This order is typically defined relative to a specific
  client session.

  \item The lifetime of such execution contexts tends to be longer
  than the lifetime of the server process. Therefore, it becomes
  necessary to make such execution contexts first-class persistent and
  possibly mobile objects.

  \item If a large system is broken down into autonomous
  \e{concurrent} subsystems (a collection of \e{agents}),
  synchronization issues can arise during method invocation (cyclic
  wait-for dependencies, race conditions, non-deterministic execution,
  \ldots).

\end{itemize}

As a solution to these problems we propose not to use object-oriented
component interface definitions but process-oriented interface
definitions between subsystems of a business information system
following the language/action perspective on cooperative work
\cite{Wino87,FGHW88,Sear69,Aust62}. For details on our model, see
\cite{Matt97a,Matt97b,Joha97,Wegn98}.

In a first step, we identify \e{actors} in a business information
system. An actor can either be a human or an active process (thread,
task, job, \ldots) in an information system. For example, a customer, an
SAP~R/3 application server and a Lotus Notes Domino Server can all be
viewed as actors.

In a second step, we identify \e{conversation specifications} to
describe long-term, goal-directed interactions between actors. For
example, if a customer can browse through an Internet product catalogue
on a Lotus Notes Domino Server to place an order online, we identify a
conversation specification called \p{online shopping}. We also assign
\e{roles} to actors within a conversation. The actor that initiates the
conversation (the online shopper) is called the \e{customer} of the
conversation. The actor that accepts conversation requests is called the
\e{performer} of the conversation (Lotus Notes).

An actor can participate in multiple (possibly concurrent) conversations in
different roles. For example, Lotus Notes could use the services of SAP
R/3 to check the availability of products (online or offline). Thus,
Lotus Notes would be the customer of SAP~R/3 for this particular
conversation specification.

Next, we identify \e{dialog specifications} which are process steps
within each of the conversations (login dialog, catalog view, item view,
shopping cart dialog, credit card dialog etc.\ for online shopping and
available items dialog for the availability check). A dialog consists of a
hierarchically structured \e{content specification} plus a set of
\e{request specifications} valid in this particular process step. For
example, the shopping cart dialog could aggregate a set of shopping cart
items (each of which consists of a part identification, a part name, a
number of items and a price per item) plus a total, the name of the
customer, VAT, etc. In the shopping cart dialog, only a restricted set
of requests can be issued by the customer (leave shop, select payment
mode, remove item from cart, etc.). This set of requests is the request
specification for the dialog.

For each request specification in a dialog there is a specification of
the set of admissible follow-up dialogs. If this set contains more than
one dialog, the performer can continue the conversation at run-time with
any of these dialogs. For example, the \p{addItemToShoppingCart} request
in the item view dialog could either lead to the shopping cart view or to
an out of stock error dialog.

It should be emphasized that a dialog specification fully abstracts from
the details and modalities of dialog processing at run-time. For
example, the dialog could be carried out synchronously via a GUI
interface (Windows~/~Lotus Notes) or via HTTP or asynchronously via
email or a workflow-style task manager.

Contrary to object interactions via message passing, this ``form-based''
or ``document-based'' style of interaction at the level of dialogs also
fits well the (semi-)formal interaction between humans. For example, we
are all used to a form-based interaction with public authorities.

We consider the ability to abstract from the modalities of an
interaction (local~/~remote, synchronous~/~asynchronous,
short-term~/~persistent, involving systems~/~involving humans) as a
major contribution of our process model since it makes it possible to
uniformly describe a wide range of interactions between actors that
are relevant for the enterprise.

Figure~\ref{Phasen} illustrates the basic structure of a typical
customer-oriented conversation. In the first step, the
\e{request}-phase, a customer asks for a specific service of a performer
(e.g.\ ``I want to order a hotel-room''). In the second phase, the
\e{negotiation}-phase, customer and performer negotiate their common
goal (e.g.\ conditions of satisfaction, quality of service) and possibly
reach an agreement. To do this, several dialog iterations may be
necessary. In the third phase, the \e{performance}-phase, the performer
fulfills the requested activity and reports completion back to the
customer (``we accepted your order''). The optional fourth
\e{feedback}-phase gives the customer a chance to declare his/her
satisfaction and may also contain the payment for the service.

This basic structure can already be found in data-oriented systems where
a conversation roughly corresponds to a transaction that needs to be
initialized, committed or rolled-back.

\abbildung{0.5}{Phasen}{Phases of typical customer-oriented conversations}

It should be noted that we deliberately restrict our model to \e{binary}
customer~/~performer relationships and that we do not follow established
workflow models (from CSCW) that focus on process chains involving
multiple performers from different parts of the enterprise. For example,
in our model a workflow with three specialized performers could be
broken down into a coordinator that takes a customer request and that
initiates three separate (possibly concurrent) conversations with the
three performers involved. Alternatively, one could construct a chain
where each performer initiates a follow-up conversation after successful
termination of his process step.

This example also illustrates that conversation specifications are an
excellent starting point for component definitions since they help to
identify data and control dependencies. Moreover, it becomes much
simpler to assign (data, behavior and also process) responsibilities to
actors than it is the case for pure data- or object-oriented models.

To summarize, conversation specifications include data specifications
(similar to complex object models) and behavior specifications (similar
to methods in object models) and they provide additional mechanisms for
process modeling:

\begin{itemize}

  \item Actors and their roles in the network of conversations of an
  enterprise are modeled explicitly and at a high level of
  abstraction.

  \item The context of a request is modeled explicitly. For example,
  it is possible to access the history or the client of a
  conversation.

  \item It is possible to restrict requests to certain steps (dialogs)
  within a process.

  \item It is possible to specify (aspects of) the dynamic behavior of
  the process through the set of follow-up dialogs defined for a
  requests.

\end{itemize}

Finally, it should be noted that conversation, dialog, request and
content specifications can be used as \e{static} interfaces between
components. Only at run-time, conversations, dialogs, requests and
contents are created \e{dynamically} as instances of these
classes. This corresponds to the distinction between schema and
database at the data level and the distinction between interface and
object at the object level.

%------------------------------------------------------------------------
\section{Three Case Studies}
\label{CaseStudies}

In this section, we illustrate our process-oriented approach to
component definition using three case studies from projects with German
software companies, namely an internet shop implemented with Lotus Notes
\cite{Lotus98}, a bug tracker system implemented with Microsoft ASP
\cite{ASP98} and a hotel reservation system with an SAP~R/3 backend
using SAP~BAPIs \cite{BAPI98}.

The goal of these projects was to investigate whether the abstract
process component model described in \cite{Matt97a,Matt97b} and successfully
implemented in persistent programming languages \cite{Joha97,Wegn98} is also a
suitable basis for the implementation of process components using
commercially relevant technology.

The conceptual basis for these projects is summarized in
Table~\ref{Mapping} that shows the (rough) correspondence between the
abstract process component model concepts on the one hand side and the
implementation concepts of the respective languages or systems used to
systematically realize these concepts. For convenience, we also added
a column describing the relationship between Java HTTP-Servlets and
our model.

Several cells in the table are marked as ``not applicable'' (n.a.),
since some of the systems lack the required modeling support. However,
these concepts can be emulated by a systematic use of other language
constructs.\footnote{This is similar to the situation in CORBA where
IDL interfaces and modules can also be mapped to simple imperative
programming languages like C or COBOL that lack methods and dynamic
binding.}

\begin{table}
\begin{center}
{\footnotesize
\setlength{\tabcolsep}{1mm}
\begin{tabular}[hb]{|l||l|l|l|l|l|}
\hline %---------------------------------------------------------------------------------------------------------------
\bf Model Concept    & \multicolumn{5}{c|}{\bf Implementation Concept}                                               \\
                       \cline{2-6}
                     & \bf SAP R/3 Dynpro& \bf SAP R/3 BAPI & \bf Lotus Notes  & \bf Java Server  & \bf Microsoft ASP\\
                     & \bf Technology    & \bf Technology   & \bf Technology   & \bf Technology   & \bf Technology   \\
\hline %---------------------------------------------------------------------------------------------------------------
\hline %---------------------------------------------------------------------------------------------------------------
\bf Agent            & R/3 Application   & R/3 Application  & Domino / Lotus   & HTTP-Server with & HTTP-Server with \\
                     & Server            & Server           & Server           & Servlets         & ASP Extension    \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Performer Role   & Collection of     & Collection of    & Collection of    & Collection of    & Collection of    \\
                     & related Dynpros   & related BAPIs    & Agents           & Servlets         & ASPs             \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Customer Role    & n.a.              & n.a.             & n.a.             & n.a.             & n.a.             \\
                     &                   &                  &                  &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Conversation     & R/3 Dynpro        & Client Session / & Session          & Servlet-Session  & ASP-Session      \\
                     &                   & SAP Transaction  &                  &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Dialog           & Dynpro Screen     & n.a.             & Document         & HTML-Form        & HTML-Form        \\
                     &                   &                  &                  &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Request          & Modification of   & BAPI Method      & User Event       & HTTP-Request     & HTTP-Request     \\
                     & GUI  Variable     & Invocation (RFC) &                  &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Content          & Dynpro Screen     & BAPI Method      & Content of a     & HTML-Document    & HTML-Document    \\
                     & Field             & Arguments        & document         &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Rule             & PBO / PAI-        & Implementation   & Agent            & Servlet          & Embedded Script  \\
                     & Module            & of BAPI (RFC)    & (Event Handler)  &                  & Code             \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Conversation     & EPC Description   & n.a.             & n.a.             & n.a.             & n.a.             \\
\bf Specification    & of Dynpro         &                  &                  &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Request Spec     & EPC Event         & n.a.             & n.a.             & HTML-Form        & HTML-Form        \\
                     &                   &                  &                  &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\bf Content Spec     & (I/O values of    & n.a.             & n.a.             & DTD              & DTD              \\
                     & EPC transition)   &                  &                  &                  &                  \\
\hline %---------------------------------------------------------------------------------------------------------------
\end{tabular}
}%small
\end{center}
\caption{Mapping of Process Component Model Concepts to Implementation Concepts}
\label{Mapping}
\end{table}

\abbildung{0.5}{Pattern}{Agents and Conversations of Three Case Studies}

Figure~\ref{Pattern} summarizes the agents and conversation
specifications of the three case studies. In this diagram, an agent is
indicated by a circle with an arrow. A conversation specification
between two agents is indicated by a line with two arrows connecting the
agent icons. If there are multiple agents that are based on the same
conversation specifications, the icons of these agents are stacked. Each
agent is annotated with the letter(s) $P$ or $C$ depending on his role(s) in
the participating conversations (performer or customer role).

Figure~\ref{Pattern} is described in more detail in the following
subsections. At this point, we should simply note that some of the agent
\e{patterns} depicted in this figure (e.g., coordinator, mediator,
broker) tend to appear in multiple application domains. At present we do
not have a precise characterization of the constituents of an agent pattern.

%- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

\subsection{Process-Oriented Modeling of an Internet Shop}

In this example, an internet shop was created to support internet
customers with HTTP clients and inhouse customers using Lotus Notes
clients. The internet shop was implemented using a Lotus Notes Domino
server. This implementation is based on a rather generic implementation
of the agent model outlined in Section~\ref{Approach}. This generic subsystem
is responsible for managing multiple conversations (client sessions and
server connections) and to decouple visual details (and language
characteristics) of the user interface from the rule-based agent
implementation. The server is also able to support persistent client
sessions and to generate traces to obtain a feedback on the dialog
sequences preferred by the customers.

Using this generic infrastructure, the system implementor first defines the
conversation specification for \p{online shopping} including dialogs,
requests and (most importantly) specifications for the admissible
follow-up dialogs in each dialog step. The developer can utilize the
standard Lotus Notes tools to design the dialogs and their content layout.

This initial system prototype is then validated interactively through
the customer. If the customer selects a menu item or presses a button,
he/she is prompted with a list of admissible follow-up dialogs to
continue the conversation.

In a next step, the application developer implements rules (event
handlers) for each request specification that appears in a dialog. This
event handler at run time has to return a dialog object to be displayed
to the user in the next process step. Each rule has access (via
database variables) to the contents and requests of previous dialogs in
the current conversation, a feature that is lacking badly in the
``plain'' Lotus Notes Domino environment.

The Notes Domino server also uses a SAP~R/3 system for invoices,
accounting and product availability checks. All client conversations
share a common conversation with the SAP~R/3 system which effectively
serializes client dialog steps. To accommodate a larger number of
customers, each client conversation could initiate its own conversation
with R/3 or could use a pool of active conversations. This flexibility
can be achieved by having conversations modeled as first-class
(persistent) objects.

\abbildung{0.5}{Internetshop}{Process Component Interaction in an Internet Shop}

%- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

\subsection{A Workflow Manager for Software Bug Tracking}

The next example illustrates how conversation specifications can be
used to structure the interaction between multiple human agents within
an enterprise.

At StarDivision Inc., a cooperative information system was created for
tracking and removing bugs in software (see diagram (a) in
Figure~\ref{Pattern}). There are three kinds of human actors and one
software actor:

\begin{itemize}

  \item A reporter is a human agent (a member of the support staff or
  a person answering the hotline) that is a customer in a conversation
  $ReportBug$. A $ReportBug$ conversation starts with a dialog where a
  description of the bug is entered. This conversation ends when the
  reporter is informed that the bug has been fixed. There can be an
  arbitrary number of reporters.

  \item There is a distinguished coordinator agent (a centralized
  software system implemented with the Microsoft Transaction Manager
  and Microsofts Active Server Pages). The coordinator is the
  performer for the $ReportBug$ conversation but also a customer in two
  other conversations ($AssignBug$ and $RemoveBug$).

  \item A distributor is a human agent responsible for the correctness
  of a particular software component. The $AssignBug$ conversation is
  used by the coordinator agent to request the distributor to propose
  a programmer who may be able to remove the bug. There can be an
  arbitrary number of distributors.

  \item A programmer is a human agent that may be able to locate a bug
  and report successful removal of the bug back to the coordinator
  (conversation $RemoveBug$). There can be an arbitrary number of
  programmers.

\end{itemize}

The task of the coordinator agent is to implement each $ReportBug$
conversation by a sequence of $AssignBug$ and $RemoveBug$
conversations. If a programmer is not able to remove a bug, the bug
report is returned to the distributor who has to propose another
programmer to solve the bug.

\abbildung{0.4}{Bugtracker1}{Agents and Conversation in the Bug Tracker}

Each human agents has access to a list of the active conversations he is
involved in. The list items are grouped by role and conversation
specification and also indicate the currently active dialog step of
each conversation. A human agent can switch freely between conversations
and issue requests (if he is a customer) or create follow-up dialogs
from a list of possible follow-up dialogs (if he is a performer).

Similar to the system described in the previous section, this system has
been implemented based on a generic subsystem for conversation
management and dialog visualization. Since the main objective of the bug
tracking software is to keep track of the state and of the history of
problem-solving conversations in the enterprise, only very little code
had to be written to implement the performer and customer rules of the
coordinator. All synchronization tasks between the conversations have
been successfully factored-out into library code.

Despite the fact that our process model described in Section~\ref{Process} is
based on purely sequential conversations, the implementation of agents
(more precisely the implementation of the customer and performer rules)
may introduce concurrency (by initiating multiple conversations) or
synchronization (via mutexes, events, monitors etc.).

\abbildung{0.4}{Bugtracker2}{Petri Net for combined Conversations of Bug Tracker}

Figure~\ref{Bugtracker1} and \ref{Bugtracker2} illustrate how agents
(as process-oriented software components) can be composed
systematically via conversation specifications using a Petri-Net
formalism:

\begin{itemize}

  \item In a first step, one draws a state for each dialog in a
  conversation. The states are drawn at the borderline between two
  grey boxes. Each grey box corresponds to one of the
  participating agents. In Figure~\ref{Bugtracker1} there are three
  conversations with two resp.\ three dialogs.

  \item In a second step, one connects a state with its follow-up states
  via transitions based on the conversation specification.

  \item In a third step, additional transitions and states (internal
  to an agent, but possibly connecting multiple of its roles) are
  added to formally define the desired interaction and synchronization
  between the agent's conversations.

  Since agents should be self-contained, autonomous software
  components, the only way to establish connections between roles of
  different agents are states corresponding to dialogs of
  conversations.

%  \item The initial placement of the tokens is determined depending on
%  the number of agents. For example, in Figure~\ref{Bugtracker2} there
%  is an arbitrary number of reporters, distributors and programmers.

\end{itemize}

The resulting Petri-net (cf.\ Figure~\ref{Bugtracker2}) could be
analyzed formally for deadlocks, safety and liveness. Alternatively,
simulations could be carried out to detect mismatches between the
design and the system requirements

An interesting question for future research is to investigate whether it
is possible to automatically generate rule implementations which only
serve to connect (i.e.\ synchronize or coordinate) multiple conversation
instances.

%- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

\subsection{A Broker for Hotel Reservations}

The last example in this section illustrates the use of process-oriented
component specifications in a distributed environment that also supports
conversations between \e{mobile and persistent agents}
\cite{MMS96b,MaSc94}.

The work described here is the result of a cooperation project with SAP~AG
which is interested in technologies and architectures suitable for the
construction of scalable cooperative software architectures \cite{Ripp98}.

Diagram (c) in Figure~\ref{Pattern} summarizes the agents and
conversations in this particular scenario. The main agent developed in
this project is a broker agent (e.g., Hotel A) implementing a virtual
hotel front desk.  This front desk is a performer for a
$RoomReservation$ conversation that can be carried out via three
different communication media, namely a HTML front-end for customers,
message passing for remote agents at travel agencies and message
passing for mobile agents that visit the front desk through the
Internet. The front desk has to be able to use a (legacy) system like
SAP~R/3 as a back-office system to do controlling, material management
etc.\ which is not an integral part of room reservations.

The mobile agents and the travel agency agent may in turn act as
\e{brokers} on behalf of customers contacting the agency via internet,
e.g.\ to identify the cheapest offer available.

The agent Hotel B in Figures~\ref{Pattern} (c) and \ref{Hotelscenario}
illustrates an important aspect of our process model: There can be
multiple, possibly different agent implementations for the same
conversation specification ($RoomReservation$ in our case).

Figure~\ref{Hotelscenario} shows some technical details of the
implementations of the agents: The hotel front desk, the mobile agent
and the SAP adapter are all implemented in the programming language
Tycoon, a persistent programming language developed by our group.

\abbildung{0.5}{Hotelscenario}{Scenario for a Hotel Reservation System}

Each of these agents utilizes a common generic object-oriented class
framework which provides means of defining (abstract)
conversation-specifications, agents, roles, rules etc.\ \cite{Wegn98}.
This framework also supports conversations between persistent and mobile
agents.

Moreover, we developed on top of this framework a so-called ``generic
customer'' application, which transparently and automatically visualizes
conversations and dialogs (using HTTP) so that a human user can interact
directly with any agent in the distributed system. If desired, the
generic customer can also be equipped with HTML files which provide
templates to optimize the visual presentation of dialogs from individual
conversations.

%------------------------------------------------------------------------

\section{Building a Generic Conversation Management Framework}
\label{Framework}

In this section we briefly highlight the major steps necessary to build
a generic conversation management framework. Details can be found in
\cite{Wegn98,Matt97a,Joha97}.

The first step is to define (persistent and mobile) representations
for conversation specifications that match the object model of
Figure~\ref{ClassDiagramConvSpec}. The recursive definition of the class
\p{Content Spec} supports complex dialog contents based on base types
like \k{boolean}, \k{integer}, \k{real}, \k{string}, \k{date},
\k{time} and \k{currency}, and structured types like \k{records},
\k{variants}, \k{lists}, and \k{multiple-choices}.
All of these constructs may be combined orthogonally. Finally, dialog
specifications, conversation specifications and content specifications
may appear as the contents of conversations which is useful for
``higher-level'' conversations.

In an object-oriented implementation language, this model maps directly
into a class hierarchy. Using the visitor pattern, the construction of
generators to dynamically instantiate conversations, dialogs and
contents (initialized with default values), to visualize conversations,
dialogs and contents and to transmit these objects is rather
straightforward.

The implementation of concurrent conversations and the synchronization
between multiple concurrent conversations of a single agent is more
intricate, in particular, if agents have to be persistent (i.e.\ outlive
individual operating system processes) or if agents are allowed to
migrate between address spaces while they are participating in
conversations.

\abbildung{0.5}{ClassDiagramConvSpec}%
          {An Object-Oriented Model for Conversation Specifications}

A detail from the $RoomReservation$ conversation specification of the
hotel reservation system is depicted as a state diagram in
Figure~\ref{HotelConvSpec}. The \p{SearchAttributes} dialog has two
attributes denoting the date of arrival and the number of days the
customer wants to stay at the hotel. The content of the dialog
\p{ProductList} is a single-choice-list which contains the different
products that match the customer's query. In the \p{ProductList} dialog,
three requests can be issued by the customer: Return to the
\p{SearchAttributes} dialog to refine the search, move to the
\p{ProductView} dialog to view details of a single product, or order the
product selected from the product list.

\abbildung{0.3}{HotelConvSpec}%
          {A Detail from the $RoomReservation$ Conversation Specification}

The actual definition of an agent implementing this conversation as a
performer looks as follows:

\begin{xple}
    \e{(* create a hotel front-desk agent *)}
    let agent :Agent = Agent.new("Hotel Front Desk"),

    \e{(* use existing RoomReservation specification *)}
    let convSpec :ConversationSpec =
        ConvSpecFactory.create("RoomReservation"),

    \e{(* create a performer role for this conversation specification *)}
    let perf :PerformerRole(PerformerContext) =
        PerformerRole.new( agent, convSpec ),

    \e{(* add rules to the performer *)}

    \e{(* dialog "SearchAttributes *)}
    perf.addRule("SearchAttributes", "search", PerfRuleSearch.new ),

    \e{(* dialog "productList" *)}
    perf.addRule("ProductList", "details", PerfRuleDetails.new ),
    perf.addRule("ProductList", "order", PerfRuleOrder.new ),
    perf.addRule("ProductList", "refine search", PerfRuleRefineSearch.new ),

    \e{(* dialog "productView" *)}
    perf.addRule("ProductView", "back", PerfRuleBack.new ),
\end{xple}

A performer rule is simply an object of a class with a method
\p{transition()} which creates the follow-up dialog and initializes the
dialog content. The follow-up dialog has to be one of the dialogs specified
in the conversation specification (this is verified by the conversation
manager at run-time). All performer rules are subclasses of a common
superclass \p{PerformerRule} which encapsulates rule management details.

As a concrete example, the class \p{PerfRuleDetails} contains
the implementation of the performer rule for the dialog
\p{ProductList} and for the request \p{details}. Each transition
method is executed in the context of an active conversation by a
separate thread and may access the (typed) contents of the current
dialog and the current request. The result of the transition method is
the follow-up dialog.

\begin{xple}
class PerfRuleDetails
super PerformerRule(PerformerContext)
public methods

transition( conv :Conversation(PerformerContext),
            dialog :Dialog,
            request :Request ) :Dialog
\{
    \e{(* create and initialize the follow-dialog *)}
    let next :Dialog = conv.newDialog( "ProductView" ),

    \e{(* fetch current product key from current dialog "ProductList" *)}
    let product :Product =
        lookupProduct( dialog.content["products"].singlechoice.current ),

    \e{(* set attributes of next dialog "ProductView" *)}
    next.content["description"].str := product.name,
    next.content["salesPrice"].currency :=
         product.price *
         conv.history[``SearchAttributes''].content.[``numOfStays''].int,
    next.content["picture"].image := product.picture,

    \e{(* return the next dialog *)}
    next
\}
\end{xple}

%-----------------------------------------------------------------------

\section{State-Enriched Type Checking}
\label{SET}

The rule implementation shown at the end of the previous section
exhibits a significant potential for improvements exploiting the static
knowledge already present in conversation specifications:

\begin{itemize}

  \item Type-safe access to the contents of the current dialog should
  be supported. Thereby, spelling errors and also errors caused by
  schema changes can be detected at compile-time.

  \item The validity of the follow-dialog should be checked already at
  compile-time, exploiting the knowledge about the dynamic process
  structure of the conversation.

  \item Warnings should be issued if an implementor writes code to
  attach rules to requests which are not valid in a given dialog.

  \item Type-safe access to the dialog contents of earlier steps of a
  conversation should be supported. This requires a non-trivial
  control flow analysis of conversation specifications to detect which
  dialogs are guaranteed to appear in the history, which dialogs
  cannot appear in the history and which may appear in the history. We
  have formalized this decision procedure using temporal logic
  formulae \cite{Hupe98}.

\end{itemize}

We have implemented these improvements by means of a so-called
\e{state-enriched type checker} which is able to verify the consistency of
rule implementations based on the additional knowledge of the dynamics
of the system described by an object of class conversation
specification. The state-enriched type checker makes use of a (typed)
representation of the history and the current dialog.

As a consequence, the rule transition described in the previous section
can be written in a more concise and type-safe way as follows:

\begin{xple}
class PerfRuleDetails
super PerformerRule(PerformerContext)
public methods

transition( cv :Conversation(PerformerContext),
            dialog :Dialog,
            request :Request ) :Dialog
\{
    \e{(* create the next dialog *)}
    nextDialog( "ProductView" ),
    \e{(* dialog is the current dialog's identifier *)}
    \e{(* next is the next dialog's identifier *)}

    \e{(* fetch current product from the current dialog "ProductList" *)}
    let product = lookupProduct( dialog.products.current ),

    \e{(* set attributes of next dialog "ProductView" *)}
    next.description = product.description,
    next.salesPrice = product.price * history.numOfStays,
    next.picture = product.picture,

    \e{(* return the next dialog *)}
    next
\}
\end{xple}

The state-enriched type checker ensures that the dialog to be created
in the \p{nextDialog} statement is valid. Similar checks are performed on
requests generated in customer rules.  The checker also ensures that
variables referenced by the identifiers \p{dialog} or
\p{next} are declared in the corresponding dialogs.  In comparison to
the former dynamically-typed code, no type information has to be
specified; the dialogs' variables are completely statically typed.

One of the biggest advantages of state-enriched type checking becomes
apparent when changing conversation specifications, e.g.\ when
extending or refining an existing conversation specification by adding
new paths, new dialogs or moving attributes (i.e.\ dialog content)
from one dialog to another. Without typechecking, all rule code
implementing the specification would have to be browsed and verified
to check the compliance with the altered specification. In our
example, the checker can verify that access to the variable
\p{numOfStays} which is set in a previous dialog, is correct. All
accesses to contents of recent dialogs are expressed by the
identifier \p{history}.

%------------------------------------------------------------------------
\section{Concluding Remarks}

In this paper we described our \e{business conversations} model which is
based on a process-oriented perspective on software components. We
illustrated the use of this model for the construction of distributed
cooperative information systems using three practical examples from
different application domains and explained in quite some detail how
such software components can be implemented in different technologies
using generic conversation management frameworks.

The technology and formalization of state-enriched type checking may
have other interesting application areas (e.g., verifying the
consistency of a set of interacting Java Servlet implementations or
generating strongly-typed access code to CGI-arguments).

A necessary condition for process-oriented component specifications to
become practically relevant is the availability of a widely accepted
syntax~/~language to write down and to exchange such specifications in
distributed heterogeneous environments. One could either ``abuse'' CORBA
IDL as a starting point for conversation specification or one could
utilize SGML~/~XML documents that conform to an agreed-upon
\p{ConversationSpecification} DTD.

%-----------------------------------------------------------------------
\bibliographystyle{alpha}
\bibliography{STS,Literatur}

\end{document}
