AdaptAgent: Integrating Adaptive Workflows and Multi-Agent Conversations for B2B E-Commerce 1 By N.C. Narendra E-Solutions & Technology Center (ESC) Hewlett-Packard India Software Operations Ltd; 29 Cunningham Road, Bangalore – 560 052; INDIA Phone: +91-80-2051289; Fax: +91-80-2200196 Email:
[email protected]
Abstract Adaptive Workflow and Software Agent technology have the potential to revolutionize B2B E-Commerce in the 21st century. Adaptive workflow allows for dynamism in business process definition and enactment, while Agent technology helps to automate decision making among the entities executing the adaptive workflows. Hence integrating Adaptive Workflow and Agents is highly essential for effectively facilitating B2B E-Commerce. However, efforts to integrate the two have been lacking so far. In this paper, which is an extension of [18], we describe our work on developing and implementing an integrated architecture called AdaptAgent where Adaptive Workflows and Multi-Agent Conversations are modeled, executed and adapted together seamlessly. AdaptAgent extends our previous work on a 3-tier adaptive workflow architecture [12]; it also builds on our earlier work on what we call “flexible workflow support” [14], which provides a means for increased flexibility in defining and managing adaptive workflows. In addition, the unique contribution of this paper is a flexible and lightweight mechanism for managing adaptivity in multi-agent conversations. Indeed, we believe that this is the first serious attempt to rigorously categorize and model adaptivity in multi-agent conversations, especially from an architectural perspective. Keywords: agents, adaptive workflow, agent-oriented workflow, agent-oriented architectures for B2B
1. Introduction There are two new technologies that have the potential to revolutionize B2B E-Commerce in the 21st century: Adaptive Workflow, which aims to manage the ever-changing business processes automated by
1
This paper is a revised and expanded version of [18].
Page 1 of 36
information systems, and Software Agent technology, which promises to endow information systems with the requisite autonomy and decision-making capability so as to make them adaptable to the constantly changing business scenario that is a part of the 21st century business environment. Workflow and Agent technologies are complementary to each other, and there has been a lot of work on integrating the two [2, 5, 27]. However, there is one thing that stands out when reviewing the research work in this area, and it is that there has been little work integrating Adaptive Workflow and Agents. In B2B ECommerce, adaptive workflows are essential for allowing dynamism in business process definition and enactment. Over and above this, Agent technology is useful in automating cross-organizational decision making, viz., determining new business processes, adapting existing business processes, negotiating (resp. renegotiating) new (resp. existing) contracts, which would result in workflow creation (resp. adaptation). Hence the need to integrate Adaptive Workflow and Agents in order to effectively facilitate B2B ECommerce. In this paper, we present an integrated architecture called AdaptAgent, where the adaptive workflow processes and multi-agent conversations are integrated and modeled seamlessly. Apart from this, the unique contribution of our work, is the idea of “flexible workflow support”, drawing on our earlier work [14]. This approach classifies workflow processes and agent conversations on the basis of a 3-tiered control level approach consisting of loose, medium and tight control levels. The “tighter” the workflow or agent conversation, the more centralized is its definition and adaptation. Using this approach, it is possible to provide extra flexibility in supporting and managing agent-oriented adaptive workflow processes. This paper is organized as follows. We present definitions and concepts in the next section. In Section 3, we present our 3-tier adaptive workflow architecture. Section 4 discusses our flexible workflow support approach, which also extends our 3-tier architecture. In Section 5, we present our integrated AdaptAgent architecture. In Section 6, we extend the AdaptAgent architecture to incorporate mechanisms for managing adaptivity in multi-agent conversations – this is the main extension of our paper over our earlier work described in [18]. In Section 7, we briefly discuss related work. The paper concludes in Section 8 with suggestions for future work.
2. Preliminaries 2.1 Workflows
Page 2 of 36
We borrow our workflow definitions from our earlier work on adaptive workflow [12], which is in turn based on [38]: a workflow is modeled as a directed graph whose nodes are the tasks with edges denoting the flow of control between the nodes. Nodes are of two types – work nodes and route nodes. In work nodes actual task execution takes place, while route nodes are decision nodes that route the workflow information to the appropriate work nodes based on evaluation of certain rules. Edges are of four kinds – forward edge, loop edge, soft-sync edge and strict-sync edge. Forward edges depict the normal workflow execution, which is in a forward direction. Loop edges are backward pointing edges that are used to depict the repeated execution of loops. The rules in the route nodes are mainly of the Event-Condition-Action (ECA) type [9]. That is, each rule specifies a particular action to be performed, upon receipt of an event, provided the condition is met. The “sync” edges are used to support synchronizations of tasks from different parallel branches of a loop, and they are of two types: •
A “soft-sync” edge is used to signify a “delay dependency” between two nodes n 1 and n 2 , i.e., n 2 can only be executed if n 1 is either completed or cannot be triggered anymore. This type of synchronization does not require the successful completion of n 1 .
•
A “strict-sync” edge between n1 and n2 requires that n1 successfully complete before n 2 executes.
Clearly, the use of such edges must satisfy some conditions: •
Redundant control flow dependencies between nodes and loops should be avoided
•
A sync edge may not connect a node from inside a loop body with a node not contained within that loop
An example workflow graph that illustrates these definitions, is shown in Figure 1 below.
Page 3 of 36
Figure 1: Workflow Definitions
C B
START
E
D
Soft/Strict sync edge
H
A F
Route Node
G Loop Edge
END
Work Node
We can also define states for each node, depending on where it is during the workflow execution. Hence we define the following states for nodes: NOT-ACTIVATED, ACTIVATED, DONE, FAILED, SUSPENDED. The definition of these states naturally leads to the conclusion that we can define the state transition diagram that each node has to obey. Indeed, this means that the state of every node in the workflow instance, is governed by the transition rules in the state transition diagram. This diagram is given in Figure 2.
Commit
ACTIVATED
Start
DONE NOT-ACTIVATED
Suspend
Resume
2.2 Abort Figure 2: Workflow Node States
SUSPENDED FAILED
2.2 Agents Currently, there is not much consensus on what an "agent" is, and many definitions abound. For our purposes, we will combine the following definitions: ♦
[11]: "An agent is a computer program that acts autonomously on behalf of a person or organization"
Page 4 of 36
♦
[5]: "an autonomous software component that interacts with its environment and with other agents"
Hence we define an agent as "a software component that acts autonomously on behalf of a person or organization, and is also able to interact with its environment and with other agents". Agents can be characterized as "weak" or "strong" agents [26]. Weak agents possess the following characteristics: autonomous (having goals and plans for achieving them), social (can interact with other agents and their environment), reactive (can perceive their environment and respond to changes that occur) and pro-active (affect their environment rather than passively allowing their environment to affect them). In addition to the above characteristics, strong agents also possess the following characteristics: mentalistic notions (have beliefs, desires and intentions), rationality (can reason about their actions and perform actions which further their goals in line with their beliefs, desires and intentions) and learning (have the ability to learn from their actions and their environment and other agents). In this paper, we will restrict our attention to weak agents. A 7-axis characterization of agents can be found in [5], and has the following dimensions: Adaptability, Autonomy, Collaboration, Intelligence, Mobility, Persistence, Personality/Sociability. For our purposes, we require our agents to have high adaptability, autonomy, collaboration and persistence. The other 3 axes, i.e., intelligence, mobility and personality/sociability, are not applicable for us, since we are concerned with "weak" agents. The Federation for Intelligent and Physical Agents (FIPA ), has been developing standards for agents and multi-agent systems. Their reference architecture for agent platforms is accessible from [4]. There are many interesting linkages between workflow and agents, which we will be exploiting in this paper [5]: •
Agents can collaborate to perform a workflow, e.g., telecom provisioning, service provisioning, scheduling
•
Agents can be used to make workflow more intelligent, e.g., by adding negotiation, reasoning or decision points
•
Workflow can be used to choreograph a set of agents, e.g., application management
Page 5 of 36
•
Workflow can be used to coordinate interaction between people and agents, having agents delegate to people or other agents, e.g., telecom management system alerting a human operator, or assigning a repair or provisioning engineer
For our purposes, we recognize that the first two linkages represent agent-enhanced workflow (using agents to enhance workflow systems, i.e., agents representing workflow systems) and the last two represent multiagent conversations (i.e., using workflow concepts to model agent interactions in multi-agent systems). Later in this paper, we will realize that both types of linkages are essential for our AdaptAgent. Agentenhanced workflow will be used to define what we will call "macro-workflow"; and multi-agent conversations will be used to model what will be termed "micro-workflow". Hence "macro-workflow" will model Adaptive Workflows, whereas "micro-workflow" will model Multi-Agent conversations.
3. Three Tier Approach for Adaptive Workflow Management 3.1 System Architecture In [12], we have developed a 3-tier approach to adaptive workflow management, which is based on the graph-based workflow model described in Section 2.1. We have identified that adaptivity is basically of three types: •
Adaptivity at instance level: here, only the workflow instances need to be modified, perhaps to make them more efficient, or to make them easier to execute. The modules in our architecture that implement this, are: ♦
Basic Workflow Model - stores the instances of our workflow model
♦
Workflow Change Model - stores the constructs for specifying dynamic workflow changes as graph transformations
♦
Workflow Change Verifier - performs the syntactic and semantic checking of the graph transformations
♦
Workflow-Schema Interface Manager - is an interface module that interacts with the next higher layer, which is the Schema Layer
•
Adaptivity at schema level: here, the workflow schema will need to be modified - this would arise if certain "ways of doing things" change, and will necessitate radical modifications to all the workflow instances of the schema in question. The modules that implement this, are:
Page 6 of 36
♦
Schema Handler - creates, versions and stores the workflow schema
♦
Schema Migration Manager - handles migration of workflow instance between schemas, and interfaces with the Schema Handler
♦
Schema-Planning Interface Manager - interface module that interacts with the layer above, i.e, Planning Layer
•
Adaptivity at planning/goal level: here, the goals of the workflow may themselves have to be modified in response to changing environmental conditions - this could cause radical changes in the schema themselves, which could cause disruptive changes in the workflow instances. The modules that implement this, are: ♦
Organizational Workflow Repository - organization-wide repository of all workflow processes stored into the system; stores the workflow schemas and their instances, and also stores the goals and sub-goals that led to the creation of the workflow in the first place.
♦
Goal Specification Module - through this module, the workflow designer first enters the goals and sub-goals that the workflow has to satisfy. He/she can then look into the Organizational Workflow Repository, for reusing any workflows from the past that can satisfy – either fully or partially – the goals that he/she has specified.
♦
Workflow Design Module - with this module, and with the goal and workflow information from the Organizational Workflow Repository, the workflow designer can design the workflow schema. He/she will then check it into the Organizational Workflow Repository. The schema will then be transferred into the Schema Handler via the Schema-Planning Interface Manager, where it will be appropriately versioned and stored. The appropriate version number is then communicated to the user.
The pictorial representation of this architecture is given in Figure 3 below.
Page 7 of 36
Users
WF Design Module
Goal Specification Module
Figure 3: Three-Tier Adaptive Workflow Architecture
WF Repository
PLANNING LAYER
Schema - Planning Interface Manager
Schema Migration Manager
Schema Handler
SCHEMA LAYER
Workflow - Schema Interface Manager
Workflow Change Verifier
Basic Workflow Model
Workflow Change Model
INSTANCE LAYER
3.2 Workflow Adaptation Any change to be made on-the-fly to an already executing workflow, has to proceed as per the following steps: •
The proposed change has to be specified in terms of a graph transformation (as already mentioned in Section 3.1)
•
The graph transformation is verified using graph queries in the system; if the transformation is not feasible, the user is notified, and the unsatisfied portions of the query are also informed to the user
•
If the transformation is feasible, the user is informed and the query is executed.
Our algorithms are as follows. Graph Transformations:
Page 8 of 36
If a change is needed to the workflow definition on the fly, then this will have to be specified by the user to the system via graph transformations. Each graph transformation obeys the following sequence: •
Specify the sub-graph which needs to be transformed – this will involve isolating that part of the workflow, by specifying the beginning and ending nodes of the sub-graph
•
Specify what the sub-graph will be after the transformation – here, the user will have to specify the new workflow sub-graph that will substitute for the old sub-graph
•
Specify the basic operations needed in terms of node addition/deletion and edge addition/deletion, that define the transformation – in order to get from the old sub-graph to the new sub-graph, the user will have to specify the order in which the transformation, which is essentially a combination of node and edge additions/deletions, will have to take place
Graph Queries: The graph transformation provided by the user triggers certain queries within the graph-oriented internal representation of the workflow model. The queries that are executed by the system, are: •
Checking syntactic correctness and consistency of the transformation (using the graph-theoretic properties of the workflow model as in [38]) – these include the following: Ø
All input parameters of a node are supplied before the node is executed
Ø
Nodes from different parallel branches of a loop are not allowed write access to the same data element, unless they are synchronized by a sync edge
•
Checking semantic correctness and consistency of the transformation (using the ECA-type rules provided in the route nodes)
If the queries are executed successfully, the user is notified and the appropriate changes are made to the workflow definition. If not, the user is informed as to which queries failed. Changing the Workflow Schema: Changing the workflow instance on the fly, naturally raises the question of whether – and if so, when – to migrate the new instance onto the definition, so that the workflow schema itself changes. There are two options here: •
Modify the workflow schema as soon as the new workflow instance is created
Page 9 of 36
•
Mark the new workflow instance as a new version of the old workflow schema, thereby creating version trees of workflow schemas and their associated instances (as described in [6])
For example, if a workflow instance I of a schema S is adapted to I', then one of two things can happen: •
I' is "rolled into" S, thereby changing S
•
I' is stored as an instance of S-version2, where S is stored as S-version1
3.3 Typical Usage Scenario In order to illustrate how our architecture is used, we sketch a typical usage scenario. We do this by enumerating the possible reasons for a workflow designer to adapt the workflow. (a) Changes in goals - the goals underlying the currently existing workflow processes may have changed, necessitating a major change in the workflow schema (for example, the business will have to be substantially reengineered and repositioned, or its product line itself may undergo a major change). Perhaps the current workflow schema may have to be discarded and a new one created, along with its associated workflow instances. This will have to be done at the Planning Layer. (b) No changes in goals, but changes in business relationships and environment - this will necessitate a change in the workflow schema, since the business models governing the workflow may have to change, although the overall business goals may remain unchanged (for example, the workflow may need to be implemented in a distributed fashion, by using sub-contractors, necessitating a change in the workflow schema). This will have to be done at the Schema Layer. (c) No changes in either goals or business environment, but the need to improve delivery efficiency or the need to introduce alternative processes (this is sometimes referred to in the literature as "exception handling [33]") - this will necessitate a change in the workflow instances only. This can be restricted to the Instance Layer itself. Hence we can look at the following typical scenario: •
The workflow designer perceives a situation in the organization where there is a need to change some business processes. He/she then determines which of the situations above, viz., (a), (b) or (c) apply.
•
In case (c) applies: In this case, only an instance of the workflow schema is being modified. This may essentially be a one-time exception in order to deal with a special case that was not thought of earlier. In this situation, as described in Section 3.2 ("Changing the Workflow Schema"), a new version
Page 10 of 36
of the workflow schema is created. After the workflow process has completed executing, the workflow designer can then consider migrating all the workflow instance to the new workflow schema version, and discard the old version, should he so choose. This can be done following the rules as described in [6]. •
In case (b) applies: This could have a serious impact on the business, since business relationships may themselves have to be rewritten. This will involve evolving a new workflow schema, and ensuring that all future workflow instances are derived from this schema and not the older one. Again, as described above, migration of the existing workflow instances will have to be decided as described in Section 3.2 ("Changing the Workflow Schema") and in [6].
•
In case (a) applies: Such a situation would arise if the business itself is being reengineered or repositioned. In such a case, the most likely response would be complete all the currently running workflow instances (depending on whether they can be completed - this will have to be a business decision) and starting the workflow design from scratch for future activities - to define new goals, workflow schema and instances.
4. Flexible Workflow Support Traditionally, workflow management has been regarded as being centralized, monolithic, rigid and not easily amenable to adaptation; once a workflow process was defined, it was regarded as more or less “cast in stone,” and to be executed with little change. Moreover, the monolithic nature of workflow has always implied rigid centralized control, thereby forcing all users to follow the workflow without question. However, this does not meet the needs of most businesses and B2B E-Commerce systems today, due to their inherent dynamism and decentralized nature. To this end, in our previous work, we extended ideas from [7] and developed an architecture for what we called “flexible workflow support” [14], containing the following ideas: •
Any workflow can be classified to belong to one of the following three “control levels” – loose, medium or tight
•
Loose workflows can be defined, started and adapted by any user (not necessarily the Workflow Administrator) in collaboration with the other participants in the workflow. Such a workflow can adapt itself as much as possible, depending on the need and on the participants.
Page 11 of 36
•
Medium workflows are also defined, started and adapted by any user, but need approval from the Workflow Administrator, in order to ensure that they adhere to a particular workflow schema.
•
Tight workflows are the traditional workflows, which are defined, started and adapted centrally by the Workflow Administrator.
•
In this regard, the following points are to be noted: o
Henceforth, in this paper, we will refer to the person defining the workflow (who can be any user or the Workflow Administrator) as “workflow definer”.
o
In this paper, we will not be discussing the issue of determining whether a workflow instance adheres to a workflow schema. Rather, we will be leaving that to the judgement of the workflow definer. Obviously, an instance can be said to adhere to a schema if it obeys the "overall structure" of the schema, perhaps with a few exceptions and deviations. In the literature [29, 30], there have been some techniques proposed for solving this problem, by looking at the issue of "workflow inheritance" in a manner similar to that of object-oriented inheritance, but this problem is far from being solved fully.
•
Hence our extensions to Figure 3 to accommodate flexible workflow support, are the following (as depicted in Figure 4 below): Ø
Logically separate the Workflow Repository for representing and storing these three types of workflows.
Ø
Have a Schema Discovery Module as part of the Goal Specification Module, which will assist the Workflow Administrator in observing the execution of several instances of a loose workflow and then “upgrade” it to medium level by designing a schema for it; all future executions of this workflow will then have to be at medium level, adhering to the schema.
Ø
Similarly, the Workflow Administrator can, using the Goal Specification Module, also observe the execution of several instances of a medium workflow and “upgrade” it to the tight level; the assumption behind this is that workflows that are executed sufficient number of times are more closely understood and can be controlled centrally.
Hence the same workflow adaptation technique as described in Sections 3.2 and 3.3 can be used here, the main difference being the new role of the workflow definer vis-à-vis that of the workflow administrator.
Page 12 of 36
Users
Goal Spec Module
Schema Discovery Module
WF Design Module
WF Repository
Loose WFs
Figure 4: Flexible Workflow Planning Layer
•
To Schema-Planning Interface Manager
Medium WFs Tight WFs
Extending this to distributed workflow means that there are two categories of workflows, which can be at different control levels – the overall workflow and its constituent sub-workflows (which could be executed at different workflow servers) – resulting in nine different combinations for the three control levels. Essentially they are the following: Ø
If the overall workflow process is at loose level, this means that it is defined among the workflow servers in a peer-to-peer fashion by the workflow definer. However, each constituent sub-workflow can be at any of the three levels, and managing the constituent subworkflows becomes an internal matter for the individual workflow servers.
Ø
If the overall workflow process is at medium level, this will need a Central Coordinator (also known as CC – similar to that of Workflow Administrator) that will need to approve the workflow before it is executed. The individual workflow processes can be at any control level; however, the CC will ensure – from the viewpoint of the overall workflow process – that the individual workflow processes are represented as “black boxes” with predefined inputs and outputs, which the individual workflow servers will need to satisfy.
Ø
If the overall workflow process is at tight level, then the CC itself is in charge of defining and imposing the overall workflow process on the individual workflow servers. Here also, the individual workflow processes are specified as “black boxes” with predefined inputs and
Page 13 of 36
outputs, and it will be the responsibility of the individual workflow servers to design workflow processes to satisfy the inputs and outputs. v Hence the CC in this case is also an adaptive workflow system just as the one described in Section 3 and pictorially depicted in Figures 3 and 4, with the important difference that it supports and manages the overall distributed workflow process, with the constituent sub-workflows being managed by (probably geographically separated) individual workflow servers. •
Here, we see that adaptation can take place at many levels – at the overall workflow level, and at the levels of the individual sub-workflows and their sub-workflows (if any), and so on. However, since sub-workflows are always defined as “black boxes” at the level of their parent workflows, it is the responsibility of the individual workflow definers to adapt their sub-workflows should there be a need to do so, at their respective Instance, Schema or Planning layers. In other words, workflow adaptivity here is defined in a "top-down" fashion starting at the CC, and is dependent on the overall business goals.
5. AdaptAgent Architecture The AdaptAgent architecture is envisioned as an extension of our 3-tier adaptive workflow and the flexible workflow-derived Central Coordinator (CC) ideas described above, in order to accommodate multi-agent interactions. That is, the CC not only coordinates the workflow processes but also the conversations among the agents that represent the workflow servers. Our basic premise is that agents execute workflows as part of meeting their goals; in addition, they would also need to interact with each other via conversations that would involve message passing among them in a language such as KQML [10]. An example of this is a supply chain scenario, where the agents represent an automobile company and its suppliers (which are also agents), working together to produce an automobile. All the agents will execute the overall workflow process needed for automobile production consisting of its constituent workflows which are executed by the individual supplier agents. In addition, the supplier agents will also interact with each other and their CC via multi-agent conversations that would not necessarily involve the data transfer or product delivery that is common with workflow process execution. One such example of a multi-agent
Page 14 of 36
conversation, would be a negotiation [26] over prices or delivery schedules, whereas delivery of an automobile component would be an example of a workflow execution by a supplier agent. Hence as defined in Section 2, workflow processes are modeled as “macro-workflows”, with agent conversations being modeled as “micro-workflows”. The reason for this, is that micro-workflows can be modeled as single tasks within the macro-workflows with predefined entry and exit criteria (which are essentially boolean conditions); within a micro workflow, its related macro workflows are represented within these entry and exit criteria. We therefore have to extend our CC architecture of Section 4 in order to accommodate two types of distributed workflows – macro and micro workflows, with the following additional characteristics: •
A micro workflow is defined after its respective macro workflows have been created. As explained in the supply chain example above, the micro workflow is a conversation conducted by the agent executing the macro workflow, jointly with the other agents involved in the conversation. The conversation is started after the agent’s macro workflow execution has crossed the point represented by the predecessor of the task representing the micro workflow. After the conversation is completed, the agent will then resume its macro workflow execution from the successor of the task representing the micro workflow. This will be the same for every other agent participating in the conversation. Naturally, the outcome of the conversation could determine the course of the future macro workflow executions of the agents, as per the macro workflow definitions. Hence it is necessary for the micro workflow to be defined after its respective macro workflows have been created.
•
Macro and micro workflow processes can be adapted relatively independent of each other; however, when a macro (resp. micro) workflow is adapted, the effect of the adaptation on its related micro (resp. macro) workflows will need to be considered before going ahead with the change. This is done as follows:
Ø If the change is to a macro workflow instance or schema, then the affected micro workflow instance will be syntactically and semantically checked. If, as a result of this, a change in the micro workflow is needed, then it must also be adapted as per the procedure to be described later in Section 6.
Page 15 of 36
Ø
If the change is to the micro workflow, then if there is a corresponding change in its input or output to any of its related macro workflows, the macro workflow may also need to be adapted as per the procedures described in Sections 3 and 4.
•
Macro and micro workflows can be at different control levels; however, this should not cause any issues, due to the highly modular way in which the micro workflows have been modeled as “black boxes” within macro workflows. This enables micro workflows to be managed independently of macro workflows, as long as the input and exit criteria for the micro workflows are satisfied.
•
Since multi-agent conversations are structurally different from macro workflows, they can be represented as multi-graphs using techniques such as Dooley Graphs [24]. However, from the viewpoint of the macro workflows, they are merely single tasks with predefined entry and exit criteria. Similarly, the presence of the macro workflow is modeled in the micro workflow by means of the entry and exit criteria.
•
Agent Communication Languages (ACLs) such as KQML [10] can be used for implementing the multi-agent conversations. Each edge in the multi-graph will represent a performative sent by an agent to its recipients, which would either be a broadcast message to the recipients, request for information, reply to an earlier message, etc.
6. Adaptive Multi-Agent Conversations As already described in Section 5, multi-agent conversations can also, just like macro workflows, exhibit adaptivity. However, adaptivity of conversations is quite different, for the following reasons: •
Conversations typically involve more than one party interacting with each other. Hence their structure needs to be quite different from that of macro workflows.
•
Unlike macro workflows, adaptivity in conversations can occur much more frequently and rapidly; it is, after all, easier for an agent to change the “course” of a conversation than is it for a (human or automated) worker to change the course of a workflow. This is because conversations consist of a collection of “speech acts” [1, 23] that are primarily message exchanges between agents, and which could easily change an agent’s internal state.
•
Due to this, conversations are typically much more flexible and “lightweight” than traditional workflows, and hence conversation management is quite different from workflow management.
Page 16 of 36
•
While individual macro workflow tasks possess state (see Section 2.1), state information in conversations is present only at the overall conversation level. This is because state information makes sense only for entire conversations, i.e., whether the conversation is NOT-ACTIVATED, ACTIVATED, SUSPENDED, FAILED or DONE.
Hence adaptivity in conversations requires to be studied quite differently from that of macro workflows.
6.1 Adaptivity in Multi-Agent Conversations Due to the lightweight nature of conversations, it should be easier to adapt conversations extensively in mid-stream without the need to change the Conversation Schema, since such a change would be disruptive to all the participating agents. To that end, although we retain the original 3-tier architecture, i.e., PlanningSchema-Instance for conversations, we split the Schema layer into two sub-layers: •
The “upper” sub-layer, will continue to be the Schema layer, and will interface with the Planning layer
•
The “lower” sub-layer will be called the Conversation Mode Sub-Layer (CMSL), and will provide the necessary added flexibility and structure as explained below.
In the traditional macro workflow architecture, a Schema is essentially a process template, and an instance is derived from it. In that sense, a macro workflow typically possesses a “linear” flow, in that possesses a single beginning and a single end. A conversation, on the other hand, is the result of a multitude of speech acts “uttered” by several agents, some of them simultaneously. Hence a conversation can be simultaneously started and successfully completed by several agents acting together. Thus a conversation schema should be an unordered set of speech act sequences along with some composition rules that dictate how the speech act sequences should be composed. With this in mind, we define our layers as follows: •
The Planning Layer will contain the Goals that the conversation should meet, along with Policies [21]. This layer will also store the Commitments [25] that participating agents make to each other, which are derived from the Goals. Policies are global rules that constrain how the Schema should be designed to meet the goals. They can be regarded as boolean conditions in first-order logic. Hence they can be represented in computerreadable form. For example, policies can be represented in the Z formal notation as in [28].
•
The Schema Layer will contain the Conversation Schema (simply called Schema), which is essentially an unordered set of legal (as per the Policies) sequences of speech acts.
Page 17 of 36
•
The CMSL will contain a subset of the speech act sequences belonging to the Schema, and this is the Conversation Mode (simply called Mode). If the total number of legal speech act sequences in the Schema is S, then there are theoretically 2 S possible modes for a Schema.
•
The Instance Layer will consist of a Conversation Instance (simply called Instance), which is a particular legal (as per the Policies) arrangement of the speech act sequences in the mode.
Hence the following mappings can be made with our original 3-tier architecture of Figures 3 and 4: •
Planning Layer: Ø
The WF Repository will store conversations along with their associated macro-workflows
Ø
The Goal Specification Module will store the conversation goals and their associated policies in addition to macro-workflow goals
Ø
The WF Design Module will be used by the workflow definer to define conversation schema/modes/instances also
•
Schema Layer: Ø
The Schema Handler creates, versions and stores the conversation schema along with the macroworkflow schema
Ø
The Schema Migration Manager will handle schema level adaptations for agent conversations and macro workflow. In addition, for managing Modes, this module will contain an additional module within it called Mode Handler, which will also play the role of the CMSL.
Ø •
The Schema-Planning Interface Manager interacts with the layer above, i.e., the Planning Layer
Instance Layer: Ø
The Basic Workflow Model stores the conversation instances along with the macro workflow instances
Ø
The Workflow Change Model will store the constructs for specifying changes to conversations, and also for macro workflows
Ø
The Workflow Change Verifier will check whether the proposed conversation changes are consistent with the Policies, just as it also verifies whether proposed macro workflow changes are syntactically and semantically valid.
Ø
The Workflow-Schema Interface Manager will interface with the Mode Handler
Page 18 of 36
Hence the CMSL provides both flexibility and structure in the following way: •
It provides a structure to the conversation by limiting the number of possible speech act sequences in the Mode as a subset of the Schema
•
It provides flexibility through the ability to “mix and match” the speech act sequences in the Mode, subject to the Policies
In Section 6.5, we will provide an example that illustrates all these ideas, especially the utility of the CMSL.
6.2 Adaptive Conversation Architecture In Figure 5 below, we provide a UML-like class diagram representation of our adaptive conversation architecture. The diagram describes the different components of the architecture, and how they relate to each other, as described in Section 6.1. In this section we will also focus on how this architecture could actually be implemented in practice.
Page 19 of 36
Figure 5
Conversation Policies
0..*
Conversation Goals 1 1..*
Commitments
1
1..*
1..*
1
Conversation Schema
0..*
0..*
1 1 1..*
Conversation Modes 1
1..* Conversation Instances
1..* 1
1
1
1..* 1
Combinations of Speech Acts
1..* Speech Acts
Conversation States
0..*
Page 20 of 36
As already stated earlier, a multi-agent conversation is an ordered sequence of speech acts that should fulfill certain Goals. The goals are constrained by zero or more Policies [21] that are essentially constraints on how Schemas can be derived to meet the goals. A Goal would be met by the participating agents meeting one or more Commitments [25] to each other. A Schema consists of at least one Mode which, as defined in Section 6.1, is a subset of the speech act sequences belonging to the Schema. From a Mode, one or more Instances can be derived. Each such instance consists of at least one Speech Act. A combination of zero or more speech acts represents a State of the conversation (if no speech act has been executed at all, then the conversation remains in NOT-ACTIVATED state). A state signifies either meeting or violating zero or more commitments; for example, for a conversation that is in DONE state, all commitments made by the participating agents (and hence all the goals of the conversation) are expected to have been met. For a conversation in any of the other states, not all the commitments may have been met. In [17] we have shown how distributed macro workflows can be adapted, based on the state information of individual macro workflow tasks. Basically, a macro workflow adaptation consists of a combination of task addition and/or task deletion, and workflow adaptation can happen in one of two ways: by aborting or rolling back tasks. Only tasks that are in either ACTIVATED, SUSPENDED, DONE or FAILED state can be rolled back. Likewise, only tasks that are in either NOT-ACTIVATED, ACTIVATED or SUSPENDED state can be aborted, as long as the abortion does not permanently alter the state of the workflow repository. Also, tasks that are being rolled back cannot be aborted, and vice versa. Hence, since conversations as a whole possess state, the state management techniques for macro workflow tasks as described in [17] need to be suitably tailored for conversations. To that end, we formulate the following rules: •
Only speech acts of a conversation that is in ACTIVATED, SUSPENDED, DONE or FAILED state can be rolled back, and those commitments made (if any) by those speech acts are nullified. This will cause the conversation to move back to a state prior to the utterance of those speech acts.
•
Only conversations that are in either NOT-ACTIVATED, ACTIVATED or SUSPENDED state can be aborted, and this will also nullify any prior commitments that an agent may have made during the course of the conversation.
Page 21 of 36
•
If a part of a conversation is being rolled back, then the conversation cannot be aborted. Likewise, for a conversation that is being aborted, no part of it can be rolled back.
Hence a conversation has to be aborted entirely, in which case it will return to NOT-ACTIVATED state (if it is not already in that state); whereas, a conversation can be rolled back partially to the state that it was in before the utterance of the speech acts that were deleted during the roll-back. Thus, the crucial question that we have to answer, is how to relate speech act sequences to states and state changes. For example, what does it mean for a conversation to change state from ACTIVATED to SUSPENDED or DONE state? Hence support needs to be provided for the workflow definer to define which combinations of speech acts will keep the conversation in the same state, and which will change the conversation state. This information can be kept in tuples of the following form: This information can be stored as a set of tuples in the Schema Layer, and it can be used for determining which state the conversation is currently in, and when its state could change. Those Policies from the Schema that apply here, are also stored in the tuple. Depending on the conversation state, the necessary adaptation mechanisms are implemented, as described below in Section 6.3.
6.3 Conversation Adaptation Mechanism Since a typical conversation will involve several agents, a well-defined protocol is necessary for adapting conversations, as follows: a)
One of the agents feels the need for a change and proposes a change to the workflow definer (please recall that multi-agent conversations can be at any control level, depending on who the workflow definer is - whether loose, medium or tight control). Alternatively, the workflow definer may himself decide to change the conversation.
b) The change is considered by the workflow definer, who will then create a new conversation instance. Of course, before doing so, the conversation is syntactically and semantically checked to ensure that it adheres to the mode/schema and the Policies, respectively - this checking can be done by the system in a manner similar to that done for macro workflows in Section 3.2. If the conversation is at medium level, then the workflow administrator also has to approve this change.
Page 22 of 36
c)
The change is then implemented by the workflow definer, i.e., the conversation is adapted. Depending on the nature of the adaptation - instance level, mode level or schema level - the appropriate modifications are made to the instance/mode/schema. As we shall see in Section 6.3.1, this implementation can be automated while preserving safety and correctness properties.
d) Similar to the approach described in Section 3.2, version trees of instances, modes and schemas are also maintained, with appropriate links to each other. However, the major difference here, as compared to macro workflows, is this: since a schema is an unordered set of speech act sequences, one schema version can have multiple mode versions. Also, since an instance is a particular arrangement of the speech act sequences in a mode, a single mode version can have multiple instance versions. This idea will become clearer in Section 6.5, where it will be demonstrated in an example. In order for the conversation to be adapted, it must be either aborted or rolled back, after which the new conversation instance can start to be used. For this, the state information stored in the tuples mentioned in Section 6.2 need to be first used, in order to determine which state the conversation is in. The conversation is aborted by the workflow definer by the sending of an abort message to each participating agent, that all speech acts that they have sent to each other during the course of the conversation are null and void, and have to be erased from their individual memories. This is to be done so that the (probably persistent) internal state of each agent is not permanently affected by those speech acts. In the case of conversation roll-back , only those speech acts signifying prior commitments, need to be deleted (and their associated commitments nullified, as already described in Section 6.2). This is done by the workflow definer notifying all participating agents that these commitments are nullified, and deleting the appropriate speech acts so as to nullify the commitments. This will cause the conversation to move back to a state prior to the utterance of these speech acts, so that the adapted conversation can be introduced.
Sec 6.3.1 Ensuring Safety and Correctness during Conversation Adaptation During on-the-fly conversation adaptation, one of the most important requirements is to maintain safety and correctness properties while the conversation is being adapted. This is needed in order to ensure that the adaptation does not cause inconsistencies in the conversation state. For example, if one of the conversation goals has been met during the course of the conversation and the conversation is to be rolled back so that the goal is to be nullified, then all the related speech acts should be deleted from the conversation. If the
Page 23 of 36
goal is to remain even in the modified conversation, then the related speech acts should be retained; otherwise, the goal will not be satisfied, resulting in an inconsistency in the conversation. Hence step c) of the adaptation protocol presented in Section 6.3 above needs to be elaborated in order to ensure that consistency is maintained. In this Section, we present this elaboration. Essentially, we utilize the relationships depicted in Figure 5. From that Figure, we see that the conversation goals are satisfied by the collection of speech act sequences that make up the conversation schema. In particular, a goal is mapped to a set of commitments that together help realize the goal. Each commitment is a speech act by an agent to other agents in the conversation. Hence we can assume the existence of a "commit" speech act as a "reserved" speech act for expressing commitments. This will then help in keeping track of which goals have been satisfied so far in the conversation, via the goalßàcommitments mapping for each goal. As already described in Section 6.3, the conversation is either aborted or rolled back depending on which state it is in. The following are the state changes that are possible: •
NOT_ACTIVATED à ACTIVATED Ø
•
This happens once an agent starts the conversation by sending a message to any other agent(s)
ACTIVATED à SUSPENDED Ø
This is supposed to be done only by the workflow definer or the Workflow Administrator, by sending a "suspend" speech act (another “reserved” speech act)
•
SUSPENDED à ACTIVATED Ø
This happens once the workflow definer or the Workflow Administrator sends a "resume" speech act (another “reserved” speech act) to the agents, and the agents once again resume the conversation
•
ACTIVATED à DONE Ø
The conversation ends successfully once all the necessary "commit" speech act have been sent by the appropriate agents, which would result in all the conversation goals being satisfied
•
ACTIVATED à FAILED Ø
The conversation is said to end in failure when the agents stop sending speech acts before all the goals have been satisfied by their respective "commit" speech acts
Page 24 of 36
Based on the above preliminaries, we are now ready to describe the step c) in more detail below (please note that this entire procedure can be automated, hence this means that the safety and correctness properties can be preserved automatically): •
All the “commit” speech acts of that portion of the conversation that is to be adapted, are identified
•
If the conversation is in ACTIVATED or SUSPENDED state: o
If the conversation is being aborted, all the relevant speech acts are to be erased from the Workflow Repository and also from the internal memories of the participating agents. If the conversation is being rolled back, only the “commit” speech acts are to be erased.
o
Since, in either case, the “commit” speech acts will have to be erased from the conversation and also the individual memories of the participating agents, the goalßàcommitments mapping is checked to ensure that the related goals are also stored in the Workflow Repository as not satisfied.
o
Once this is done, the adapted conversation starts. If the conversation had been in SUSPENDED state earlier, it is then brought back into ACTIVATED state by the sending of the “resume” speech act
•
If the conversation is in NOT_ACTIVATED state, then the adapted conversation simply starts in ACTIVATED state.
•
If the conversation is in DONE state, it can only be aborted. Hence in this case, all new conversation instances will adhere to the new conversation mode or schema. If the earlier conversation has to be aborted, then all the speech acts in the conversation are erased, and the conversation goals are stored in the Workflow Repository as not satisfied.
•
If the conversation is in FAILED state, then the situation is similar to that of the DONE state. The major difference, however, is that only a few conversation goals may have been satisfied, in which case only these goals are to be stored in the Workflow Repository as not satisfied.
6.4 Relation to Macro-Workflow As already explained in Section 5, a multi-agent conversation is represented as a single task in a macroworkflow with predefined entry and exit criteria. We now see that these criteria are nothing but the Goals that the conversation has to meet. Hence if the related macro-workflows of the conversation change, this
Page 25 of 36
could trigger an adaptation of the conversation. Alternatively, a change in the conversation could trigger an adaptation of the related macro-workflows.
6.5 An Example In this section we present a simple yet non-trivial example that illustrates our basic definitions. This is a variant of the well-known Contract Net Protocol (CNP) example that is used to illustrate multi-agent conversations. In particular, our example is inspired by the CNP variants discussed in [19]. Basically, the CNP involves negotiations between a prime contractor and several sub-contractors; the prime contractor wants to award a contract to one or more sub-contractors based on certain criteria determined by it. In fact, we see that the prime contractor can be the automobile company (recall the example at the beginning of Section 5), while the sub-contractors are the automobile company's suppliers. Hence the goals of this conversation are the following: G1 = The prime contractor should obtain the “best” bid as per its criteria G2 = At least one sub-contractor is the winner (there could be more than one winner, depending on the number and complexity of the criteria defined by the prime contractor) G3 = The winners are those that have submitted the “best” bids The goals G1 through G3 imply the following commitment that signifies that the conversation has reached the DONE state: C1 = The prime contractor commits to selecting one or more winners based on their bids Hence the first step would be to define the Schema that will meet the goals. Our schema is therefore the set of the following speech act sequences: S1 = prime contractor accepts all bids, then chooses the “best” bids S2 = prime contractor accepts the first M bids in first-come-first-served order, and chooses the first bid(s) that meet its criteria S3 = conversations between the prime contractor and sub-contractors, on issues/clarifications regarding the contract and its criteria (i.e., the “fine print” of the contract) S4 = prime contractor re-issuing the call for bids after a “time-out” period or after the first M bids have arrived and are found unsuitable Some example Policies accompanying the Schema could be the following:
Page 26 of 36
P1 = S1 and S2 should not occur together in the same Mode P2 = S3 should be executed after S1 has started P3 = S4 can be executed only after S1 has completed, and with the conversation being in FAILED state We could choose the following Mode from the Schema (we can see that this Mode obeys the Policies): Mode1 = {S1, S3, S4} From Mode1 we can generate the following Instance (let us call it Instance1):
START
S1
S3
S4
S1
END
In Instance1, the prime contractor will wait until all bids are received (as per the first S1). In the meantime, it will negotiate with individual sub-contractors about the “fine print” of the contract (as per S3) and may even award a few “winning” bids that may have come in early (as per the first S1). If no bids are submitted within the “timeout” period the contractor will simply issue a fresh call for bids (as per S4). Finally, the prime contractor will select the best bids among those received and award the contract to the winners (as per the second S1 in Instance1). From Instance1 we can see that there are multiple ways in which the speech act sequences in Mode1 can be “mixed and matched”. For example, an example of Instance-level adaptivity would be to change from Instance1 to Instance2, which is depicted below:
START
S1
S3
S4
S1
END
5 times
In Instance2, the prime contractor attempts to call for bids from all sub-contractors 5 times before settling on winners. This is a minor deviation from Instance1; hence we see the utility of the CMSL (introduced in Section 6.1) in helping us to quickly modify the conversation instance without having to refer to the schema.
Page 27 of 36
If Instance1 has to be adapted to Instance2, and if this has to be done while the conversation is executing S4, then it is still in ACTIVATED state. Also, since the second S1 is still to be executed, Instance1 can be modified into Instance2 without aborting or rolling back the conversation (of course, the conversation can still be aborted at this stage, since doing so would cause minimal impact; however, this is a decision that the workflow definer has to take). If Instance1 has to be adapted to Instance2 while the second S1 is being executed, then, depending on how far S1 is executed, some commitments that the prime contractor may have made to a “winner” sub-contractor, may have to be erased/nullified (along with their associated goals as described in Section 6.3.1), so that the execution of the second S1 can begin afresh, and can be done 5 times. Mode-level adaptivity occurs if Mode1 is replaced by Mode2 (which also obeys the Policies), where Mode2 = {S2, S3, S4} Hence an instance of Mode2 could be Instance3, which is depicted below:
START
S2
S3
S4
S2
END
Thus if the Mode changes from Mode1 to Mode2, the conversation instance would change from Instance1 (or Instance2) to Instance3. Here also, if S2 has to replace the second S1 of Instance1 (or Instance2), then the second S1 will have to be deleted (and its commitments, if any, erased/nullified along with their associated goals as per Section 6.3.1) so that S2 can be introduced (i.e., another conversation roll-back). In order to demonstrate Schema-level adaptivity, let us introduce a new sequence to the schema (with the Policies remaining unchanged): S5 = one of the “winners” expresses inability to execute his part of the contract as promised, hence that part of the contract is cancelled Hence we can define Mode3 (which also obeys the Policies) as follows, and which would replace Mode1 or Mode2: Mode3 = {S1, S3, S4, S5}
Page 28 of 36
This could result in Instance1 (or Instance2) being replaced by Instance4, which is depicted below:
START
S1
S3
S5
S1
END
The meaning of Instance4 is that the prime contractor has to keep accepting fresh bids after one or more the “winners” default due to inability to meet the terms and conditions of their part of the contract. This process has to continue (without any limit defined on the number of attempts) until suitable and capable winners are found. We can maintain the above information in the version trees, by first making the following mappings: Schema-version 1 = {S1,S2,S3,S4} Schema-version 2 = {S1,S2,S3,S4,S5} Mode-version 1 = Mode1 Mode-version2 = Mode2 Mode-version 3 = Mode3 Instance-version 1 = Instance1 Instance-version 2 = Instance2 Instance-version 3 = Instance3 Instance-version 4 = Instance4. We can then store the following linkages among the version trees, thus: Schema-version 1 à Mode-version 1 à {Instance-version 1, Instance-version 2} Schema-version 1 à Mode-version 2 à Instance-version 3 Schema-version 2 à Mode-version 3 à Instance-version 4
7. Related Work Our paper has explored two important research areas for B2B E-Commerce: integrating adaptive workflow and agents, and adaptive agent conversations. As we have already stated in Section 1, we believe that our work (i.e., [18] and this paper) is the first serious attempt to integrate adaptive workflow and agents.
7.1 Adaptive Agent Conversations
Page 29 of 36
In the context of agent conversations, however, a lot of work has been done modeling conversations and investigating conversation policies (see http://www.boeing.com/special/agents99/papers.html for a large number of papers on conversation policies, too numerous to describe individually in detail here). However, none of these papers tackles the problem of conversation adaptivity directly (although [21] does touch upon it briefly). A 3-tier layered approach for modeling agent conversations and their related policies has also been proposed in [19]. Our approach is similar to [19]; indeed our example in Section 6.5 is inspired by the example provided in that paper. However, we provide a systematic way to manage adaptivity of multiagent conversations, which that paper lacks.
7.2 Adaptive Workflow Adaptive workflow is an area of active research. In most adaptive workflow research, workflow adaptation has been motivated by the need for exception handling when workflow failures are encountered [33]; in particular, in [33], a knowledge-based approach to invoking the appropriate stored procedures for exception handling is described. From our perspective, this is instance-level adaptation. Other research on adaptive workflow, notably ADEPT [38], the work of Ellis and colleagues [35] and Aalst [37], have primarily focused on the structural aspects of workflow graphs during adaptation. These are definitely invaluable contributions to the area of adaptive workflow; indeed, we have leveraged from ADEPT in our workflow adaptation algorithm in Section 3.2 where syntactic correctness is checked. In our opinion, the most significant work on managing exceptions is to be found in [36]. This paper describes how exceptions can be catalogued, stored and managed. Two main classes of exceptions are identified – expected and unexpected. For unexpected exceptions, a language and template has been developed for supporting dynamic modification of workflow schema. For expected exceptions, a rule-based specification language has been developed; this language enables the definition of exceptional situations and
their
handling.
More
details
are
available
from
http://www.hpl.hp.com/personal/Fabio_Casati/docs/Fabtesi.zip. Correctness issues for workflow management in general are discussed in [32]. In [31], the authors have presented a novel architecture for ensuring safety and correctness properties during workflow adaptation. In this architecture, the workflow change management function is modeled in a separate layer; in that layer a Tracking Agent keeps track of all workflow changes and a Change Coordination Agent automates the
Page 30 of 36
workflow adaptation after ensuring that safety and correctness rules are satisfied. Our work differs in two major respects from this. Firstly, we consider automated adaptation only for agent conversations; secondly, for agent conversations our Workflow Definer (with the appropriate oversight from the Workflow Administrator) plays the roles of both the Tracking and Change Coordination Agents.
8. Conclusions In this paper we have presented an integrated approach for Adaptive Workflow and Agents, which is an extension of [18]. Adaptive Workflow is implemented within each agent by means of a 3-tier workflow architecture that we have previously developed [12]. This architecture is augmented with our later idea of “flexible workflow support” [14], which provides user flexibility in defining, executing and adapting workflow processes by classifying them into loose, medium and tight control levels. This augmented architecture has been further enhanced by representing agent-oriented workflow as a combination of “macro-workflow” (agent-enhanced workflow) and “micro-workflow” (conversations among the agents representing individual workflow systems). We have also presented a similar (but different) conceptual architecture for managing adaptivity of multi-agent conversations, where we have highlighted the different way in which this has to be handled as opposed to adaptivity in “macro workflow”. Indeed, we believe that this is the first serious attempt to rigorously categorize and model adaptivity in multi-agent conversations. There are several opportunities for future work: •
Detailed Architecture Specification and Implementation – we have briefly described the main modules of our 3-tier architecture, and the architecture itself needs to be implemented and experimentally evaluated (especially with reference to how macro-workflow and conversation adaptation - including version management and the actual adaptation protocols themselves - can be implemented in practice). For this, we are investigating the use of the TupleSpaces approach [20, 34], since it is a very simple and convenient method for implementing the asynchronous workflow and multi-agent coordination that our architecture requires. Another important area of architectural research is to integrate our AdaptAgent architecture with agent behavior models such as SmartAgent [39]. Schema adherence is another research topic that needs to be investigated; that is, how to automatically determine if an instance "obeys" a schema? Research on workflow inheritance [29, 30] that attempts to answer this question, needs to be leveraged to answer this question.
Page 31 of 36
More detailed research on Policies and Commitments (especially with respect to the tuples that are used for maintaining conversation state information), and their relation to the Goals and Schema, is also another important area for future research. We will be looking at this as our next research topic, and we hope to leverage on the formal theory for agent conversations developed in [28]. Yet another important research issue is (semi-) automatic derivation of the appropriate adaptive workflows and agent conversations to meet the goals specified in the Goal Specification Module. We have made a minor beginning in [13], but much more work remains to be done in this area. •
Security and Trust Management – issues such as Security and Trust Management [8] become crucial in multi-agent interactions, hence the Goal Specification Module functionality should be enhanced to implement Security and Trust Management. Protocols for establishing trust among participating agents also need to be developed and implemented, in a manner similar to that described in [40].
•
Distributed Service Management – the Planning Tier should be augmented to implement distributed Service Management of macro-workflows and multi-agent conversations, in a manner similar to that described in [22].
•
Agent Conversation Representation – in our paper we have not imposed any particular representation (such as Petri Nets [19], FIPA-ACL [4], KQML [10] or Dooley Graphs [24]), preferring instead to concentrate on the architectural aspects. Hence this is a fertile area for future research. Indeed, we plan to integrate our work with the ongoing AgentCities work on agent conversation language description [41].
9. Acknowledgments The author wishes to thank Dr. Bernard Burg of Hewlett-Packard Laboratories for his useful feedback on [18], on which this paper is based. The author also wishes to thank his manager, Srivatsa Krishnaswamy, and the ESTC Center Manager, Padma Ravichander, for supporting his work.
10. References [1] J.L. Austin, How to Do Things With Words, Oxford University Press: Oxford, England, 1962. J.O. Urmson, editor. [2] Q. Chen, P. Chundi, U. Dayal and M. Hsu, "Dynamic Agents," International Journal of Cooperative Information Systems, 1999
Page 32 of 36
[3] C. Dellarocas, “Contractual Agent Societies: Negotiated shared context and social control in open multi-agent systems,” Workshop on Norms and Institutions in Multi-Agent Systems, 4th International Conference on Multi-Agent Systems (Agents-2000), Barcelona, Spain, June 2000; also available from http://ccs.mit.edu/dell/aa2000/paper13.pdf [4] FIPA 2000 Specifications, available from http://www.fipa.org/specifications/index.html [5] M.L. Griss, ""My Agent Will Call Your Agent … But Will It Respond?," Software Development Magazine, 2000 [6] M. Kradolfer and A. Geppert, “Dynamic Workflow Schema Evolution based on Workflow Type Versioning
and
Workflow
Migration,”
November
1998;
available
from
http://www.ifi.unizh.ch/dbtg/Projects/TRAMs/trams.html [7] K. Whittingham, "OpenWater - White Paper", IBM Research Division, Zurich Research Laboratory, 1999 [8] A. Herzberg, Y. Mass, J. Mihaeli, D. Naor and Y. Ravid, “Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers,” available from http://www.hrl.il.ibm.com/index.asp [9] G. Kappel, S. Rausch-Schott and W. Retschitzegger, Coordination in Workflow Management Systems A Rule-based Approach, Springer LNCS 1364, 1998 [10] T. Finin, Y. Labrou and J. Mayfield, "KQML as an Agent Communication Language," in Software Agents,
Jeffrey
Bradshaw
(editor),
AAAI/MIT
Press,
1997;
also
available
from
http://www.csee.umbc.edu/~jklabrou/publications/mitpress96.pdf [11] OMG's MASIF (Mobile Agent System Interoperability Facilities) specification; available from ftp://ftp.omg.org/pub/docs/orbos/98-03-09.pdf [12] N.C. Narendra, "Adaptive Workflow Management: An Integrated Approach and System Architecture," ACM Symposium on Applied Computing 2000 [13] N.C. Narendra, “Goal-based and Risk-based Creation of Adaptive Workflow Processes,” American Association for Artificial Intelligence (AAAI) Spring Symposium 2000 [14] N.C. Narendra, “Flexible Support and Management of Adaptive Workflow Processes,” submitted to Information Systems Frontiers, 2001
Page 33 of 36
[15] N.C. Narendra, “Flexible Agent Societies: Flexible Workflow Support for Agent Societies,” Proceedings of CIMCA 2001 [16] N.C. Narendra, “An Integrated Security Infrastructure for Adaptive Workflow,” submitted to Journal of Research and Practice in Information Technology, 2001 [17] N.C. Narendra, “Integrating Flexible Workflow and Multi-Agent Conversations in Flexible Agent Societies,” Journal of Association for Information Systems, to appear [18] N.C. Narendra, “AdaptAgent: Integrated Architecture for Adaptive Workflow and Agents,” Proceedings of International Conference on Artificial Intelligence, Special Session on Agent-Oriented Workflow Architecture for B2B, 2001 [19] M. Nowostawski, M. Purvis and S. Cranefield, "A Layered Approach for Modelling Agent Conversations," Autonomous Agents 2001 [20] M. Nowostawski, M. Purvis and S. Cranefield, “Agent-Oriented Modelling for Complex Systems,” available from http://marni.otago.ac.nz/~mariusz/papers.html [21] L.R. Phillips and H.E. Link, "The Role of Conversation Policy in Carrying Out Agent Conversations," Proceedings of Workshop on Specifying and Implementing Conversation Policies, Autonomous Agents '99; also available from http://www.boeing.com/special/agents99/sandia2.pdf [22] A. Sahai, J. Ouyang, V. Machiraju and K. Wurster, “End-to-End E-service Transaction and Conversation Management through Distributed Correlation”, HP Labs Technical Report HPL-2000-145, also available from http://lib.hpl.hp.com/techpubs/2000/HPL-2000-145.pdf [23] J.R. Searl, Speech Acts: An Essay in the Philosophy of Language, Cambridge University Press, Cambridge, England, 1969. [24] M.P. Singh, “Synthesizing Coordination Requirements for Heterogeneous Autonomous Agents,” Autonomous Agents and Multi-Agent Systems. volume 3, number 2, June 2000, pages 107-132; also available from http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/aamas-synthesis.pdf [25]
M.P.
Singh,
"An
Ontology
for
Commitments
in
Multiagent
Systems:
Toward
a
Unification of Normative Concepts,” Artificial Intelligence and Law, volume 7, 1999, pages 97--113; also available from http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/ai+law-final.pdf
Page 34 of 36
[26] M. Wooldridge and N. R. Jennings, "Intelligent Agents: Theory and Practice," In Knowledge Engineering Review 10(2), 1995; also available from http://www.csc.liv.ac.uk/~mjw/pubs/ker95.ps.gz [27]
The
Zeus
Agent
Building
Toolkit
Home
Page,
available
from
http://www.labs.bt.com/projects/agents/zeus/index.htm [28] R. A. Flores and R. C. Kremer, "A Formal Theory for Agent Conversations for Action", available from http://www.cpsc.ucalgary.ca/~robertof/publications/ci-acl/ci-acl2001Flores&Kremer.pdf [29] W.M.P. van der Aalst and T. Basten, "Inheritance of Workflows: An approach to tackling problems related to change," Computing Science Reports 99/06, Eindhoven University of Technology, Eindhoven, 1999; also available from http://tmitwww.tm.tue.nl/staff/wvdaalst/Publications/p85.pdf [30] C. Bussler, "Workflow Class Inheritance and Dynamic Workflow Class Binding," Proceedings of the Workshop on Software Architectures for Business Process Management at the 11th Conference on Advanced Information Systems Engineering CAiSE*99, Heidelberg, Germany, June 1999; also available from http://hometown.aol.com/chbussler/ [31] P. Bose and M. G. Matthews, “Dynamic Change in Workflow-Based Coordination of Distributed Services,” Proceedings of the 2001 International Workshop on Self-Adaptive Software, Balatonfüred, Hungary, 2001. [32] M. Kamath and K. Ramamritham, "Correctness Issues in Workflow Management," available from http://citeseer.nj.nec.com/kamath97correctness.html [33] Mark Klein, "A Knowledge-Based Approach to Handling Exceptions in Workflow Systems," Journal of Computer-Supported Collaborative Work, Special Issue on Adaptive Workflow Systems, Vol. 9, No 3/4, August 2000; also available from http://ccs.mit.edu/klein/papers/cscw-99.pdf [34] G. Cabri, L. Leonardi, F. Zambonelli, "Auction-based Agent Negotiation via Programmable Tuple Spaces," Proceedings of the 4th International Workshop on Cooperative Information Agents (CIA) 2000, LNCS
n.
1860,
Boston
(USA),
July
2000;
also
available
from
http://sirio.dsi.unimo.it/MOON/papers/cia00.pdf [35] C. Ellis, K. Keddara, and G. Rozenberg, "Dynamic change within workflow systems," In N. Comstock and C. Ellis, editors, Conference on Organizational Computing Systems, pages 10 - 21, ACM SIGOIS, ACM, Aug 1995. Milpitas, CA.
Page 35 of 36
[36] F. Casati, M. Fugini, and I. Mirbel, "An Environment for Designing Exceptions in Workflows," Information Systems 24(3), pp. 255-273, 1999. [37] W.M.P. van der Aalst and S. Jablonski, "Dealing with Workflow Change: Identification of Issues and Solutions," International Journal of Computer Systems, Science, and Engineering, 15(5):267-276, 2000; also available from http://tmitwww.tm.tue.nl/staff/wvdaalst/Publications/p112.pdf [38] M. Reichert and P. Dadam, “ADEPTflex – Supporting Dynamic Changes of Workflows Without Loosing Control,” Technical Report No. 97-07, University of Ulm, Germany, April 1997; available from http://www.informatik.uni-ulm.de/dbis/f&l/forschung/workflow/ftext-adapt_e.html [39] M.L. Griss, S. Fonseca, D. Cowan and R. Kessler, “SmartAgent: Extending the JADE Agent Behavior Model,” available from http://www.hpl.hp.com/techreports/2002/HPL-2002-18.html [40] L. Kagal, T. Finin and A. Joshi, "Developing Secure Agent Systems Using Delegation Based Trust Management," Security of Mobile MultiAgent Systems (SEMAS 02) held at Autonomous Agents and MultiAgent Systems (AAMAS 02); also available from http://www.csee.umbc.edu/~lkagal1/papers/lkagaldevelopingsecure.pdf [41] S. Ambroszkiewicz, L. Rozwadoswki, D. Mikulowski, T. Nowak, K. Miodek, M. Kisiel-Dorohinicki and K. Centarowicz, "Requirements for Service Description and Composition in AgentCities," preliminary draft, 2002.
Page 36 of 36
