% File:    main.tex
% Author:  Florian Matthes
% Date:    08-08-1997
% Purpose: Business Conversations Paper (DBPL'97 submission)
%
\documentclass[a4paper]{article}
\usepackage{a4}
\usepackage{epsfig}
\usepackage{sts} 
\usepackage{sts-named} 
% 'a4paper,twoside' are standard LaTex2e
% 'german.sty' and 'epsfig' are unmodified standard files
% 'sts' is used by many STS publications 
% 'sts-named' supports long citations as used by 'sts-named.bst'
%
\begin{document}

\title{Business Conversations\\
A High-Level System Model for Agent Coordination}

\author{Florian Matthes}
\date{{\small AB 4-022 Softwaresysteme\\
Technical University Hamburg-Harburg\\ 
D-21071 Hamburg, Germany\\
f.matthes@tu-harburg.de}
}

\maketitle

\begin{abstract} \noindent In this paper we introduce Business Conversations as a high-level software structuring concept for distributed systems where multiple autonomous agents (possibly in different organizational units) have to coordinate their long-term activities towards the fulfillment of a cooperative task. We first motivate Business Conversations as a system model suitable for the description of human-human, human-software as well as software-software cooperation. We then explain why we consider this model be more suitable for the description o organizational cooperative work than software-centered object models. The core concepts of the Business Conversation model are described using an object-oriented model. Finally, we report on our experience gained building a prototypical agent programming framework with Business Conversations for agent coordination based on mobile and persistent threads as provided by the persistent programming language Tycoon.
\end{abstract}

\section{Motivation and Background}

Following \cite{DDJ+97} a cooperative information system (COOPIS) can be described using three complementary facets: A system integration facet which addresses data transfer as well as semantic and control integration, a group collaboration facet which is concerned with how people working on a common business process can coordinate their activities, and an organizational facet which views cooperation from a formal organizational perspective, regardless by whom or with what technology it is carried out.

In this paper we propose a high-level system model for the system integration facet where distributed autonomous (human or software) agents coordinate their long-term activities towards the fulfillment of a cooperative task via structured Business Conversations. In our prototypical implementation of this model agents and conversations are treated as first-class entities: They can be named, classified, specialized, made persistent and they can migrate across heterogeneous execution and communication platforms. 

As should become clear in the remainder of this paper, this system integration model fits well with modern models for the group collaboration facet (business process modeling, workflow management, groupware support systems) and the organizational facet (virtual enterprises, electronic commerce, radically decentralized information processing). Our model therefore has the potential to simplify the central task of {\em change propagation} between the facets of a larger-scale COOPIS.

To our understanding, any model developed for the system facet should allow system builders to abstract from the details of

\begin{enumerate}
\item cooperation over {\bf time}: Agents and artifacts should exist as long as required by the business processes they support, independently of the underlying language and system concepts, e.g. the lifetime of operating system processes or of database schema revisions.

\item cooperation within {\bf space}: Agents and artifacts should be able to migrate freely within a physically distributed environment, independently of the particular system platforms or organizational structures (e.g. business units) involved in the cooperative work.

\item cooperation in multiple {\bf modalities}: Artifacts should be accessible uniformly for agents that cooperate in different modalities (simple overnight batch processing, online transaction processing, direct manipulation by human agents via form-based or graphical user interfaces, computer-supported cooperative work by humans, computer-assisted workflow management, automatic information processing by mobile software agents) and using different media (email messages, EDI-messages, HTTP requests, CORBA object requests, RPC invocations).
\end{enumerate}

\noindent As a consequence, a system builder can focus on the ``what'' and ``how'' of the particular problem at hand (e.g. compilation of an insurance offer) without worrying about the ``when'' (batch processing, interactive session, long-term conversation with a human customer), the ``where'' (on a centralized host, on a server within sales department, on a mobile laptop of a salesperson) and the ``who'' (customer via letter, salesperson, workflow management system, visit of an Internet agent). Moreover, applications are not cluttered with unnecessary data movement, synchronization and conversion details and can absorb much better changes in time, platform and modality than it is the case today.

Our research work of the past three years has focused on the issues (1) and (2) by providing full {\bf persistence} and {\bf mobility} abstraction in the platform-independent Tycoon system \cite{MaSc94,MMS95b} culminating in the development of persistent migrating threads \cite{MMS96b} which can be used to implement software agents similar to Telescript agents \cite{Math96,Joha97}. In this paper, we describe Business Conversations as a contribution to the third issue, cooperation in multiple modalities. Even though Business Conversations are implemented in the Tycoon environment, this high-level system model has a much wider applicability since it makes little assumptions about the underlying agent infrastructure and (persistent) programming model. 

This paper is organized as follows: In Section \ref{Sec:sysmodels} we position our activity-oriented approach to system cooperation relative to other, more traditional, data-oriented and object-oriented models. In Section \ref{Sec:bc} we give a high-level overview of our Business Conversation model using examples from the insurance sector. Details of this model are then given in Section \ref{Sec:bc} which also discusses our prototypical implementation of the model. The paper ends with a comparison with related work and an outlook on future work.

\section{System Models for Cooperative Business Applications}
\label{Sec:sysmodels}

In this section we motivate the need for a high-level, activity-oriented agent coordination model and also relate our work to other models for cooperative business applications.

At a certain level of abstraction, the evolution of system models for
cooperative business applications can be classified roughly into three stages.
Within each of these ``historic'' stages, the primary focus of research and
development has been on a certain aspect of business applications, namely data,
behavior and activity. As a consequence, one can distinguish roughly between
data-oriented, object-oriented and agent-oriented approaches for the construction of distributed business applications.

\subsection{Distributed Business Data} 

The sharing of business data between multiple applications of an enterprises has been the first approach to the construction of large cooperative information systems (banking systems, airline reservation systems, management information systems, CIM systems). A cooperation
of multiple applications is supported by persistence and distribution
abstraction as provided, for example, by modern relational database systems. Due
to the failure of distributed database technology, most existing cooperative IS
are based on centralized data servers, as exemplified by integrated business
application systems like SAP R/3, Baan or Oracle Financials.

In a nutshell, such cooperative information systems are viewed as collections of
shared database servers and distributed database clients (application programs
or ad-hoc human users).

\subsection{Distributed Business Objects}

The promise of distributed object management is to arrive at more flexible,
scaleable and maintainable system architectures by building cooperative
information systems using distributed business objects \cite{OHE96}. A business
object encapsulates business data and achieves a higher degree of autonomy by
restricting access to the business data through well-defined method interfaces.
Clients of a business object not only can abstract from the internal
representation of the business information but they can also rely on an open
communication platform (middleware) that achieves full distribution and platform
transparency, possibly also across organizational boundaries. Moreover, it is
expected that there exists a refinement relationship between business objects
(e.g., a car insurance contract is a refinement of a general insurance contract
which is in turn a refinement of a generic customer contract) which can be
exploited to develop generic domain-specific application models or to define standardizable business APIs.

In the Distributed Business Object model, a cooperative information system is
viewed as a collection of distributed objects which exchange messages that are
dispatched by an ``ubiquitous'' object request broker infrastructure.

In our view, Distributed Business Objects are a promising software structuring
concept for rather tightly integrated business applications, e.g. in-house
desktop clients accessing corporate business object servers. However, we believe
that it does not scale well for more advanced patterns of cooperative work
involving truly autonomous ``profit centers'' within an organization or involving
several departments of independent enterprises which are unlikely to agree on a
common business object model and a shared object infrastructure which may be
expensive to maintain.

The interaction between business objects and the coordination of their
behavior is ``hard-coded'' and often distributed in a complex way over the
methods of multiple objects. This is to be seen in contrast with the need for
multiple modalities for cooperative work quoted in the introduction of this
paper and the flexibility requirements imposed by business process reengineering \cite{DDJ+97}.

\subsection{Distributed Business Agents}

In recent years, activity-oriented models centered around the notion of ``agents''
have attracted a lot of interest in the research community. Despite significant differences in detail, all of these models suggest to view cooperative systems as being composed of largely
autonomous agents, each with a well-defined ``responsibility'', ``independent
activity'', private ``knowledge'', ``memory'' and ``capabilities''. Moreover, agents
are to be regarded as a unit of persistence and mobility.

Agents provide a system structuring concept appropriate for the decomposition of
cooperative systems into smaller subsystems responsible for well-defined
short-term or long-term tasks (claims processing, order management, shopping,
information retrieval) which can be carried out either by a human or a software
agent (demon, robot, script invocation, etc.) at a single site or involving a
migration from site to site.

In order to avoid the deficiencies of business objects described at the end of
the previous section, the notion of a business agent should not simply expand
the notion of a business object (consisting of encapsulated state and behavior)
by adding autonomous activity (active objects) and platform-independent
mobility as suggested by some software agent models.

Instead of this, our proposal de-emphasizes the importance of agents themselves (how they are created, classified, duplicated, etc.) and concentrates on their externally observable behavior, namely their ability to sustain long-term, goal-directed conversations with other agents which is also an important mechanism to {\em coordinate} agents (synchronization, delegation, replication, \ldots).

Another view on the evolution of cooperation models is to regard it as a gradual generalization process, since each of the newer models subsumes concepts of its predecessors and puts them into a larger context which tends to be more stable over the lifetime of a cooperative information systems.

\begin{itemize}
\item Data-centered modeling: Which data structures are maintained by the system? What are their attributes and relationships? Which integrity constraints exist on these data structures?

\item Object-centered modeling: Which operations can be applied to these data structures? What are legal state transitions on these objects?

\item Activity-centered modeling: How does the system interact with its environment over time? Are there subsystems with restricted communication links to other subsystems? What is the long-term goal to be achieved by a sequence of communication steps between subsystems?
\end{itemize}


\section{Concepts of the Business Conversation Model}
\label{Sec:bc}

The leitmotiv of the Business Conversation model are speech acts between customers and performers. The model is inspired by the work of Terry Winograd and Fernando Flores  in the domain of computer-supported cooperative work \cite{Wino87,FGHW88,MWFF92} which introduce the concept of ``conversations for action"  based on linguistic studies and the speech act theory developed by Austin and Searle \cite{Aust62,Sear69}. However, our goals are different from the more descriptive work of Winograd and Flores in that we intend to develop a {\em system model} and system design techniques which can be used during system analysis, system design and system implementation (similar to the work on distributed object models).

\subsection{Business Conversations of an Enterprise}

In the Business Conversation model, an enterprise or a business unit is viewed as an agent that is involved in a number of (long-term) business conversations with other agents
like customers, suppliers or government agencies. Within each of these
conversations, each agent has a fixed role (either customer or performer). For
example, an insurance broker is a performer for its customers and at the same
time a customer for several insurance agencies.

The main purpose of a business conversation is to coordinate the otherwise
autonomous activities of both agents towards a common goal which is typically
specified in the course of the conversation. A business conversation can be
decomposed into an ordered sequence of speech acts which can be classified into
four phases that occur in the following order (see also Figure
\ref{Fig:lang-acti}):

\begin{figure}[bt]
\centerline{\epsfbox{langacti.eps}}
\caption{The four phases of a Business Converation}
\label{Fig:lang-acti}
\end{figure}

\begin{itemize}

\item Request Phase: During this conversation phase, the customer identifies himself to the performer and states its (business) goal to be achieved during the conversation. The main purpose with respect to the customer is to check whether the performer is ready to start such a conversation or not. (``I want to insure my car'').

\item Negotiation Phase: A sequence of negotiation speech acts may be necessary to align the specific customer needs and the available performer services. Only if both partners (as autonomous agents) agree on the (refined) common goal, a commit of the performer is reached which can be understood as a ``promise" about its future activity. During the negotiation phase, exception handling and recovery policies (or more general ``quality of service" parameters) for the remainder of the conversation can be specified. (``Here are our insurance policies'', ``Your insurance contract number is 12345'').

\item Performance Phase: The performer reports on the progress of and/or the completion of the requested activity to the customer. This may also involve requests for additional information or actions from the customer to take place under the already committed QoS conditions. (```We covered your last accident'', ...)

\item Feedback Phase: This phase gives the customer the opportunity to declare its satisfaction with the service provided and may comprise the obligation for payment. During the feedback phase, no further services have to be provided by the performer.

\end{itemize}

If required by a specific real-world cooperative activity, some of these phases may be skipped. For example, a simple atomic client/server transaction (money bank transfer) involves neither a negotiation nor a feedback phase. 

\subsection{Cooperation in Multiple Modalities}

%\begin{figure}[bt]
%\centerline{\epsfbox{bcmedia.eps}}
%\caption{Cooperation alternatives of human and software agents}
%\label{Fig:bcmedia}
%\end{figure}

\noindent The utterances of customers and performers quoted in the preceding section are deliberately chosen to resemble natural language statements of human actors. However the Business Conversation model and the system infrastructure described in Section \ref{Sec:bc} are intended to cover uniformly human as well as software agents. Given a formal conversation specification for a specific business task such as claims handling, it can be utilized directly to support agent cooperation in four modalities

\begin{description}
\item[Application Linking:] Customer and performer are realized as two autonomous applications that synchronize via asynchronous message exchange.
\item[GUI Management:] A human user interacts with a software system. Legal interaction patterns are described by the Business Conversation specification which are interpreted by a software system called ``generic customer''.
\item[Workflow Management:]  A software system (as a customer) requests actions from a human user who is guided by a software system called ``generic performer''.
\item[Structured Message Handling:] The cooperative work of two human users can also profit from tool-supported message handling ensuring the adherence to pre-defined business rules.
\end{description}

An interesting technical implication of this unification of human and software agents is the ability to first develop a stand-alone information system based on its externally observable interaction patterns (similar to Visual Basic or Visual Age) and then to scale this application to a richer distributed environment where it is necessary to cooperate with other information systems without modifying the application logic of the individual systems.

Moreover, we are currently building generic application wrappers for legacy applications (Windows-95 applications and SAP R/3) which translate automatically conversation specifications and dialog steps to support the integration of such applications (without access to their source code) as agents into an open cooperation environment.

Finally, it should be noted that the modality may change dynamically during an ongoing conversation. For example, similar to an automated telephone call center, standard requests could be handled by a software agent which transfers its conversation (i.e. a  simple trace of past communication steps) to a human performer as soon as more complex or exceptional requests occur. 

\subsection{Refinement and Abstraction}

\label{Sec:refine}
An externally observable ``customer-oriented'' business conversation (primary business conversation) of an enterprise may lead to other internal business conversations (secondary business conversations) between autonomous business units of an enterprise.

A secondary business conversation follows the same communication pattern described for primary conversations. For example, a performer in a primary conversation may become a customer in multiple secondary conversations to coordinate the cooperative work of multiple subordinate agents towards the common goal requested by the external customer in the primary conversation.

\begin{figure}[bt]
\centerline{\epsfbox{coodelg.eps}}
\caption{Interactions between conversations: delegation and coordination}
\label{Fig:coodelg}
\end{figure}

Such a situation is displayed in the upper part of Figure \ref{Fig:coodelg}, where the external customer establishes a conversation with a performer which delegates the customers requests transparently to the respective subordinate performer specialized on this particular kind of task (claims processing, assessment of damage) and reports their utterances back to the customer of the primary conversation. 

An agent can also take the performer role in multiple conversations simultaneously (see the lower part of Figure \ref{Fig:coodelg}), hiding coordination details (planning, prioritizing, \ldots) in cases where the customers request activities on shared resources. 

Similarly, an ``external'' customer may consist of a collection of cooperating subordinate agents (secretary, deputy) which cooperate through (externally invisible) means like peer to peer business conversations or simple authority chains (from boss to employee).\footnote{In the remainder of this paper we ignore the implications of the concept of subordinate agents which participate in business conversations on behalf of their authority (security, addressing, mobility, \ldots).}

To summarize, the iterated decomposition of a binary customer/performer conversation into secondary conversations or subordinate agents ultimately terminates with a collection of human or software agents which carry out their work tasks in total autonomy but which are linked by a tree of speech acts (requests, commitments and task completion dependencies) and by an authority hierarchy.

\subsection{Structured Dialogs and Conversation Specifications}

In our model, the speech acts (protocols) between customer and performer are constrained to be {\em structured dialogs} and they have to adhere to explicit {\em conversation specifications}.

Two adjacent speech acts of a business conversation are grouped together and form a  dialog step which involves the exchange of a dialog understood as a document with a hierarchically structured content according to the following basic pattern:  The performer sends a dialog with an initial content, for example, a list of insurance offers with a partially filled-out contract that contains placeholders to prompt the customer for additional information. (3.) The customer updates its copy of the dialog (i.e., ``fills out the form") and returns it
to the performer with a request from a set of possible requests available in this particular dialog step (e.g. ``Please revise the offer'' or ``I accept the offer''). 

A conversation is initiated by the customer with an initial request consisting of a description of the conversation specification (protocol) the customer will utilize for the remainder of the conversation. This description is represented as a structured dialog itself.

The conversation terminates successfully only when both agents agree that the conversation is completed. In each dialog step, a time-out can be regarded as an implicit request (of the customer) or as an implicit reply (of the performer), respectively.

Each structured document exchanged between customer and performer is required to contain 
a document header that permits the receiving agent to uniquely identify
the context of the dialog (i.e. the enclosing conversation). As a consequence,
the very first request in a conversation uttered by the customer (``I want to
start a new conversation conforming to specification X'') has to be different from all its subsequent requests which are shipped together with the revised content of its previous dialog step and a reference to an already existing conversation.

The advantage of imposing additional structure onto conversations and of constraining conversations by structured meta data (conversation specifications) can be best understood by the analogy with the concept of data and object types which also provide a stable basis for formal reasoning, for tool support (consistency checking) and for system analysis (classification, generalization, parameterization).

Moreover, this meta information (protocol information) is readily available (business rules, workflow specifications, object interaction diagrams) at system design time and is essential for the understanding of large reactive agent systems. \footnote{``An object-oriented program's run-time structure often bears little resemblance to its code structure. The code is frozen at compile-time, it consists of classes of fixed inheritance relationships. A program's run-time structure consists of  rapidly changing networks of communicating objects. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa''. \cite{GHJV95}}

\section{Implementing Business Conversations}
\label{Sec:implementation}

This section gives an overview of our prototypical implementation of the business conversation model sketched in the previous section. This implementation consists of a polymorphically-typed framework written in the Tycoon persistent and distributed programming environment \cite{MSS95}, exploiting mobile persistent threads described in \cite{MMS96b}. The framework components are replicated at each agent-enabled network site and are therefore viewed as an ``ubiquitous'' infrastructure.

The three layers of this library framework are depicted in Figure \ref{Fig:agmodel}:

\begin{figure}[bt]
\centerline{\epsfbox{agmodel.eps}}
\caption{Layers of the Business Conversations library framework}
\label{Fig:agmodel}
\end{figure}

\begin{description}
\item[Application system layer:] This layer contains the application-specific agent definitions ("domain-specific business logic") consisting of Business Conversation specifications with attached event specifications which in turn are bound to statically scoped and typed Tycoon application code.

\item[Agent system layer:] The API provided by the agent system layer is used by the agents to interact with their environment. This layer is responsible for the coordination of concurrent conversations and the tracing of conversation instances. Furthermore, agent mobility and persistence services are localized in this layer.

\item[Message handling layer:] This layer provides a programming abstraction from local and remote communication implementing a store-and-forward messaging scheme. Message queues ensure the correct transmission of a message even in cases where the receiver is temporarily unavailable \cite{MSMQ95}.

All interactions between agents at higher layers are carried out via this component. Furthermore, the message handling system provides an abstraction of the underlying communication infrastructure. As of today, simple (secure) Internet socket connections are used to transfer linearized typed Tycoon objects. We are currently experimenting with software components for automatic forms processing (FAX communication channel) and with SGML (in particular HTML) converters as commercially-relevant alternatives for communication in open networks with legacy applications.
\end{description}

In the following sections we focus on the object types and services provided by the agent system layer to the application systems.

\subsection{Conversation Specifications as First-Class Objects}

A conversation specification is a contract between two agents since it constrains the behavior of the performer and provides a promise to the customer. A conversation specification can express type constraints (the structure of the documents sent and received) but also as state-dependent constraints on the conversation history (e.g., claims can only be settled after a contract has been signed and the first payment has been received). A more software-oriented example is the state-dependent specification that a customer will never execute a {\em pop} operation on an empty stack.

In contrast to earlier models based on the speech act model like the Coordinator Tool \cite{FGHW88}, a conversation specification is not given as part of the business conversations model. Instead of this, a conversation specification is a dynamically-created structured object which describes the set of all possible conversations between a customer and a performer in a given application domain expressed in the syntax of the business conversation model.

The object model in Figure \ref{Fig:tbcspec} defines the abstract elements of conversation specifications using the Mainstream Objects Model as a meta model notation \cite{YWT*95} (IH = inheritance, A = aggregation. Circle = cardinality zero, double line = optional, crow foot = cardinality n).

Technically speaking, conversation specifications are typed, persistent and mobile objects that are created bottom up using constructors of their respective classes (compare Figure~\ref{Fig:tbcspec}), for example: 

\begin{figure}
\centerline{\epsfbox{tbcmod2.eps}}
\caption{Class diagram for content, dialog and conversation specifications}
\label{Fig:tbcspec}
\end{figure}

\begin{xple}
\k{let} contract = RecordContentSpec.new()
  .add(``name''  AtomicContentSpec.new(String))
  .add(``first''  AtomicContentSpec.new(String))
  .add(``birthday''  AtomicContentSpec.new(Date))
  .add(``method of payment'' MultipleChoiceSpec.new().add( \ldots ) )
\k{let} contractDialog = DialogSpec.new(contract)
  .addPossibleRequest("Accept" \#(confirmationDialog)) 
  .addPossibleRequest("Reject" \#(negotiationSubConversation, noAgreementDialog))
\k{let} carInsuranceConversationSpec = ConversationSpec.new("carInsurance")
  .add(``Welcome'' welcomeDialog)
  .add(``Contract'' contractDialog)
  \ldots 
\end{xple}

It is also possible to generate a conversation specification from a textual or graphical representation of the dialog graph or to receive it from a remote agent, for example, a ``conversation broker''. 

A conversation specification (``car insurance'') is a dictionary of named dialog specifications with a distinguished initial dialog specification which describes the initial state for both communication partners. A dialog specification can be are either a concrete dialog specification (``contract'') or a subconversation specification (``negotiation on contract details''). The latter is obtained by an incremental modification of an existing conversation specification. This incremental modification concept is intended to generalize the concept of inheritance on object classes to conversation specifications. 

A concrete dialog specification consists of a record dialog content specification and a (possibly empty) set of request specifications available for this dialog. A record dialog content specification aggregates named content specifications (``name'', ``birthday'', ``method of payment'') which in turn (and recursively) can be either atomic (integer, string, ...), record, variant, sequence, single choice and multiple choice content specifications. In this way, content specifications define a simple monomorphic type system. More details on the Tycoon implementation can be found in \cite{Joha97}.

A dialog specification can be understood as a labeled state of a non-deterministic finite automaton. The states of a conversation are connected by directed edges, each labeled by a request (uttered by the customer, e.g. ``reject contract''). In a given dialog, there may be multiple outgoing edges with the same label. This nondeterminism makes it possible for the performer to choose between multiple follow states (``no agreement possible'', ``start with negotiation''). 

\begin{figure}
\centerline{\epsfbox{tbcinst.eps}}
\caption{Class diagram for agents, roles and conversation instances}
\label{Fig:tbcinst}
\end{figure}


\subsection{Event-Based Software Agent Programming}

Once a Business Conversation specification object has been created, performer and customer agents which adhere to this specification can be defined by rules consisting of an event and a piece of code. This code typically triggers state transitions, initiates secondary conversations or performs actions through effectors attached to the agent. The code is parameterized by a conversation descriptor which holds conversation-specific data (identity of the conversation partner, contents and requests of all preceding dialog steps, etc.). This descriptor can be expanded by agent-specific data (invisible to other agents) and greatly simplifies the management of concurrent conversations with multiple customers and performers, respectively. On termination, the code attached to an event has to return an object that matches the constraints expressed in the corresponding conversation specification which is then transferred back to the customer. 


An agent can support multiple customer and performer roles (e.g. performer for car insurance, performer for freight insurance). For each of these roles there exists a set of customer and performer rules, respectively. 

A performer rule is defined for a particular request of a particular dialog specification (contract.accept, to be issued by a an agent in a customer role) and has to return an object of class dialog while a customer role is defined for a particular dialog specification (e.g., contract, to be generated by an agent in the performer role) and has to return an object of class request which has to be one of the requests admissible in this dialog step (e.g., accept, reject, explain). 

The matching between dialog and dialog specification is checked by the agent system which gives a special treatment to the distinguished initial request of a conversation (``I want to start a new conversation of type X'') and a predefined ``breakdown'' request which is allowed to occur in any state of the conversation.

An active conversation links exactly one customer role and one performer role of an agent. It also implements exactly one conversation specification and aggregates an ordered list of history elements which record the past dialog steps and requests of this conversation.

Figure~\ref{Fig:tbcinst} summarizes the semantic relationships between the relevant classes, some of which have already been introduced in Figure~\ref{Fig:tbcspec}.

Customer and performer neither share data nor code or thread state. In particular, the conversation specification and the conversation trace are duplicated in the address spaces of both communication partners which ensures a high degree of agent autonomy and mobility. 

The generic customer and performer described in Section \ref{Sec:refine} are also implemented using this event-based execution model and simply transfer incoming and outgoing information to a human agent via a (HTML-based) user interface.

\subsection{Agents, Places and Place Guards}


Our prototypical execution environment for Business Conversation agents incorporates a rich spatial world metaphor for the ``agent world'' which is similar to the one of Telescript based on the concepts of  {\em domain} and {\em place} (see Figure \ref{Fig:AgWeltStruktur}). A domain is associated with a node in a network and has its own communication end point on the network. A domain is uniquely addressable in the network and consists of at least one place which constitutes the root of the local place hierarchy of this domain.  A place can host an arbitrary number of other places and agents for which it provides a dynamic name space. Each place is represented by a specialized agent, a so-called place guard. This guard can selectively grant access to agents which request to enter its place through agent migration.

\begin{figure}[bt]
\centerline{\epsfbox{aelog.eps}}
\caption{Logical structure of the agent world}
\label{Fig:AgWeltStruktur}
\end{figure}

An agent can establish conversations with agents at its own place. A place (resp. its place guard) can be accessed from within its place as well as from other places and it is therefore positioned on the borderline of its place in Figure \ref{Fig:AgWeltStruktur}. Agent migration is controlled by a path consisting of the network domain of the destination domain and of the names of all places on the way to the target place. Local migration can be controlled by relative path names.

By treating agents and places (via their place guards) uniformly, both utilize the business conversation model for cooperative work. In particular, a migration conversation consists of a migration request of an agent, followed by a negotiation with its place guard, a subconversation with the target place guard(s) carried out by the place guard, a completion report and finally a declaration of satisfaction of the agent as soon as it resumes execution at the receiver side.

Similarly, the core model makes very little assumptions about the mechanisms through which a customer localizes a matching performer in a wide-area network. This well-known problem of {\em trading} or {\em brokering} in client/server programming can be solved above the core agent system layer by transmitting conversation specifications as part of ordinary trading conversations.

 \subsection{Comparison with Related Work}

Dialog-oriented cooperation based on the Business Conversation model has several advantages over cooperation based on direct object interaction (message passing) which underlies popular agent system like Telescript \cite{GM95a}, Mole \cite{Hoh95}, Facile \cite{Kna95}, COSY \cite{Had95}, Tcl/MIME agents \cite{Ros93} and Obliq \cite{Card94}:

\begin{itemize}

\item Conversations do not impair agent autonomy. By exchanging well-defined dialog content with copy semantics only, no private object bindings become available to the communication partner. Therefore, it is not necessary to introduce new binding mechanisms like the ill-defined concept of ``object references'' described in \cite{Whit94,GMI95} which attempts to distinguish objects belonging to the customer and the performer, respectively.

\item Conversations do not restrict agent mobility since local and remote agents are treated uniformly. Therefore, it is possible for an agent to migrate between address spaces while sustaining long-term conversations, e.g. with its human ``owner''.

\item The agent system already provides a well-defined concurrent execution model. Contrary to direct object interactions, the coordination of multiple agents and conversations is encapsulated in the agent system layer and there is no necessity for application-level synchronization in cases where shared resources are manipulated. The application programmer is thus shielded from much of the complexity that arises in highly concurrent agent systems

\item The details of the information exchange between agents are to a large degree independent of the underlying communication infrastructure. In particular, it is possible to translate existing object-based distribution mechanisms (e.g., CORBA \cite{OPM96}) systematically into Business Conversations.

\item Conversations are based on static process descriptions (conversation specifications) which are first-class run-time objects available to both communication partners as soon as a  conversation is initiated. This makes it possible to detect mismatches between the customer and performer view early.

\end{itemize}

\subsection{Concluding Remarks}

We have presented a high-level coordination model for autonomous agents which is tailored to the needs of (cross-enterprise) business information systems and which is excelled by its uniform treatment of human and software agents. The model exhibits several advantages over other agent models and can be implemented with limited effort in modern platform-independent, distributed and persistent programming languages like Tycoon, Napier and P-Java.

Open issues include a formalization of the refinement relationship between conversation specifications (subtyping) and of their incremental modification by overriding (inheritance). Moreover, we plan to investigate whether it is possible to build a static type checker that guarantees that a software agent generates (at run-time) only conversation traces which conform to a given static conversation specification.

{\small
\bibliography{florian-macros,florian}
}
\end{document}

