CapBasED-AMS|A Framework for Capability{Based and Event{Driven ...

CapBasED-AMS|A Framework for Capability{Based and Event{Driven Activity Management System1 Kamalakar Karlapalem Helen P. Yeung Patrick C. K. Hung Department of Computer Science University of Science and Technology Clear Water Bay, Kowloon, Hong Kong. e-mail: fkamal,heleny,[email protected] Research

Abstract Activity management system deals with management and execution of activities. A problem solving agent is a human, or a hardware, or a software system having an ability to execute activities. An activity consists of multiple interdependent tasks that need to be coordinated, scheduled and executed by a set of problem solving agents, where each task is an atomic activity executed by exactly one problem solving agent. In this paper, we develop a framework for activity management system through capabilitybased activity speci cation, decomposition and identi cation of the problem solving agents to execute the tasks, and event-driven execution of the activities.

1 Introduction Many application domains like, oce automation, planning, medical diagnosis, manufacturing systems, etc., need interaction between and humans and systems, and among humans for conducting day-to-day work. The problems in these application domains have been modeled by using dierent frameworks like, distributed cooperative problem solving [1, 4], distributed arti cial intelligence and multiagent problem solving [2], Contract-Net Protocols [16, 7], work ow management [11, 6], and cooperative information systems [14, 18, 13, 3] ([4] compares the dierent frameworks proposed for cooperative problem solving). But the work done by a problem solving agent (PSA) is modeled as a task or an activity or a 1 This

research has been funded by RGC CERG

grant No. HKUST 609/94E.

work ow in these frameworks. Therefore, it is crucial that the problem of managing activities is resolved so that these dierent frameworks to execute activities can be further developed. Activity management system deals with this important problem and is the focus of this work. In this paper, we provide a solution starting from activity speci cation and decomposition, identifying the problem solving agents (PSAs) to execute the activities, and ending with the execution of the activities. We introduce the concept of capability-based activity speci cation and decomposition, and event-driven activity execution. We are currently implementingthis system and in parallel conducting case-studies from manufacturing systems, oce automation and medical diagnosis application domains.

1.1 Concepts and Terminology A Problem Solving Agent (PSA) is either an hardware or software system or a human, with an ability to execute a nite set of tasks in an application domain. An activity consists of one or more tasks which can be executed by one or more PSAs. A task is an atomic activity which can be executed by exactly one PSA. Activity management consists of decomposition of activities into tasks, coordination and data sharing among multiple PSAs executing the activity, and monitoring, scheduling and controlling the execution of multiple tasks of an activity. A software system that facilitates the speci cation, maintenance, and execution of activities is known as an Activity Management System (AMS). Capability-based activity speci cation and decomposition: Each PSA has its competence de ned by a set of abilities it has to execute tasks.

Each activity requires a certain competence from the PSAs speci ed as a set of needs for executing

all of its tasks. This ability/need combination is nothing but the capabilities possessed by PSAs to execute an activity and capabilities required by an activity for its execution. Each activity is decomposed into a set of tasks by using the property that each task must be executed by exactly one PSA, further, each task is matched to a PSA by selecting a PSA that has the abilities to meet the needs of the task. We de ne this approach to these two aspects of activity management as capability-based activity speci cation and decomposition. Event-driven activity execution: An activity consists of multiple inter-dependent tasks that need to be coordinated, scheduled and executed. The dependencies between tasks can be, i) data dependency - a task waits for data from a PSA, ii) temporal dependency - a task must wait for some temporal event to occur, iii) control dependency the execution of the task depends on the outcome of other tasks, and iv) external dependency - the task is executed only after some external event occurs. All these dependencies can be expressed by means of an uniform framework of events, for e.g., occurrence of an event can denote receipt of data from a PSA, or a completion of a task, or a temporal event. The execution and coordination of tasks of an activity can be based on occurrence of one or more events. The execution of tasks of an activity is orchestrated by the occurrence of the events. We de ne this approach to execute activities as event-driven activity execution.

Example: The graduate admission oce processes the applications of the potential graduate students twice a year by using a set of university and departmental guidelines. The graduate admissions committee headed by a Graduate Coordinator, supported by a Graduate Secretary and consists of few faculty members review the applications. The graduate admission activity proceeds as follows. Each time a batch of new student application records are inserted into the database the completeness of the students application is checked. If the students application is incomplete, a message requesting additional documents by a due date is sent to the candidate. If there is no receipt of additional documents from the student by the due date, the student record is deleted. If the application is complete, the graduate coordinator initiates a task to review the students application by a decision due date, during that time the status of students application is \pending". The result of the review process can be i) accept the student and a letter of acceptance is sent to the student, ii) reject the student and a reject letter is sent to the student, and iii) interview the student and an

interview call letter is sent to the student. The result of the interview process is either to accept or reject the student. If the review of the students application is not completed by decision due date, a reminder is sent to the Graduate Coordinator and a new decision due date is set.

The above example will be used as a running example to illustrate the speci cation, decomposition and execution of activities by CapBasED-AMS. Figure 1 shows the architecture of CapBasED-AMS. The architecture clearly shows the capability-based activity speci cation and decomposition, and event driven activity execution parts. The activity speci cation component consists of an Activity Speci cation Language (ASL) processor which facilitates the description and speci cation of the activities. The activity decomposition into tasks is done by the Activity Decomposer module, and PSAs to execute the tasks are identi ed by the Match Maker. The activity decomposer and match maker generate a coordination plan which is speci ed by using Task Speci cation Language (TSL). The eventdriven activity execution is supported by i) Activity Generator: which takes as input a speci cation in TSL and generates an Activity Graph and an Event Graph, ii) Activity Coordinator: which coordinates the execution of the activity by using the activity and event graphs, and iii) Recovery Manager: which handles failures during task execution and iv) Task Log Manager: which maintains a log of successfully executed tasks. Activity Specification Language (ASL) Processor PSA1

PSA2

Activity Decomposer

Match Maker

GUI

Knowledge

Capability-Based

Base

Activity Specification and Decomposition

PSA3

Capability

Activity Generator

Database Event-Driven Activity Execution

Shared Workspace

Case

and Monitoring

Active

Activity Coordinator

Database

Base

Task Log Manager

Recovery Manager

Data and Control flow between module and database Data and Control flow between modules

Data and Control flow between modulues and PSAs through GUI

Figure 1: Architecture of CapBasED-Activity Management System

The salient features of the capability-based and event-driven activity management system are:

 the speci cation, and decomposition of activ



 

ities into tasks is independent of the execution and monitoring of the activities. evaluation of activity can be done at activity speci cation level to determine whether the activity can be executed, or not, and if the activity can be executed then which PSAs can execute the activity. the coordination among PSAs executing the activity is event-driven and hence independent of how each PSA executes a particular task, this is useful in an evolving activity management system where PSAs are added in to the environment. the protocols used by human PSAs to communicate can be automatically initiated, monitored and executed by using the occurrences of events. an uniform framework of events is used to model dierent kinds of dependencies (like, temporal, control, data, and external) between tasks.

The rest of the paper is organized as follows, section 2 describes the activity speci cation and decomposition, section 3 describes the activity execution, section 4 presents the related work and section 5 presents the conclusions and summary.

2 Activity Speci cation and Decomposition 2.1 Capability Modeling In this section, we shall rst describe how the abilities of PSAs and the needs of the tasks are modeled. The abilities of the PSAs and the needs of the tasks are speci ed by using tokens. A token is an unique xed-length character string that embodies a capability describing the ability of a PSA to execute certain functions/procedures/tasks. Similarly, the set of needs to execute a task is speci ed as a set of tokens a PSA needs to have to execute the task. All the tokens describing the capabilities used in activity execution are speci ed and stored in the capability database. The PSAs and their abilities (as a set of tokens) are speci ed by the user. During the activity decomposition phase, each (sub-)activity is decomposed into set of tasks and for each task the

set of tokens needed execute the task are speci ed. During the match making phase the PSAs to execute each of the tasks is identi ed. For the rest of paper, capability represented by a token implies either ability or need depending on the context in which it is referred.

2.1.1 Token Speci cation and Management

As mentioned above, each token is an unique xedlength character string that symbolizes a capability possessed/needed by a PSA/task respectively. The tokens can be speci ed at i) PSA speci cation time, while describing the capabilities of PSA, ii) Task speci cation time, while describing the needs for a task to be executed, or iii) Independently, that is, all the tokens are described and stored in the capability database, or iv) a combination of above methods. The token hides how a PSA achieves the ability and just speci es what this ability is. This reduces the number of tokens that need to be speci ed because a token symbolizes all possible ways PSAs achieve the ability represented by a token. Note that how a PSA achieves that capability is internal to the PSA and may not be always revealed to the outside environment. During match making additional constraints can be speci ed to identify the PSA that achieves an ability according to some user speci ed constraints. Each token has an unique Token Id and Token Description which is speci ed by the user. An user can access the token description to assess the capability symbolized by the token. The tokens can be displayed to the user by using the \man pages" concept so as to provide additional information about related tokens, and to enable the users to specify appropriate tokens for PSAs and tasks.

Example (cont.) The following table describes some of the tokens for the Graduate admission activity. Token Id. KPR KFA CTA COC SBD

Token Description knowledge about university and departmental guides for Graduate Admissions. knowledge about faculty's research areas and current projects. ability to approve students admission. ability to use computer system for word. processing, spreadsheet, and database access. Database management system.

2.1.2 PSA Speci cation

Each task of an activity is executed by exactly one PSA. The set of PSAs in an application domain

are known a priori. The PSAs are de ned by the administrators of the CapBasED{AMS. PSA role abstraction is used to specify basic set of abilities for a set of similarly capable PSAs. An example of a PSA role can be \Graduate Admissions Committee Member" with abilities to \evaluate" students application. A PSA can be an active PSA (like, a human) or passive PSA (like, a word processing system) speci ed by (role-) type. Each PSA role has a set of tokens denoting the set of abilities PSAs taking this role have. Each PSA must have at least one role, each role may have several PSAs. The PSA roles are described by using following constructs and stored in th PSA Role table. PSA Role Name Description Type Abilities Constraints

/* Unique PSA Role Name*/ /* Description of PSA Role */ /* Active or Passive */ /* List of tokens */ /* Constraints on PSAs with this role */

Example (cont.) Here is the list of PSAs for the Graduate admissions activity. PSA Role Name Graduate Coordinator. Description Coordinator of Graduate admission committee. Type Active. Abilities fKPR, KFA, CTAg PSA Role Name Graduate Secretary. Description Departmental administrative sta. Type Active. Abilities fCOCg PSA Role Name DBMS. Description Database management system. Type Active. Abilities fSBDg

The list of PSAs are stored in the PSA table with following attributes.

update, and select) are executed in a database system. A temporal event occurs when a condition speci ed on time is evaluated to be true. Explicit events are the events triggered by users or PSAs and need to be registered with the AMS. An event can be composed of multiple events, we shall use the SNOOP language developed by [5] to specify composite events. Here is the partial list of operators used to specify composite events. The semantics of these operators are given in [5].

 Disjunction (r): E 1rE 2 occurs when E1 occurs or E2 occurs.

 Sequence (;): E 1; E 2 occurs when E2 occurs given that E1 has already occured.

 Conjunction (Any, All): Any(I; E 1; E 2; : : :; En) i  n occurs when any I events out of the n distinct events occur.

 Aperiodic Event Operators (A, A*): allows for the speci cation of an aperiodic event bounded by the occurrences of two arbitrary events (de ning an interval of time).

 Periodic Event Operator (P, P*): allows for

the speci cation of an event that repeats itself within a constant and nite amount of time.

2.2 Activity Speci cation Language

In this subsection, we shall rst describe the high level activity speci cation language. This language is used to describe the activities by using a set of declarative constructs. Each activPSA Id. /* System wide unique PSA identi er */ Roles /* List of one or more roles taken by PSA */ ity consists of an activity identi er, a set of subLocation /* The place where PSA is located */ activities, a set of input external (IE) events which Constraints /* Any constraints on the PSAs */ trigger the execution of the activity, a set of output external (OE) events which convey the outExample (Cont.) Here is the list of PSAs for put of executing the activity, and additional opthe Graduate Admissions activity. tional constructs like activity description, and constraints. The sub-activities being activities themPSA Id. Roles Location selves, are speci ed using ASL just like activities. Prof. Smith Graduate coordinator Room 233 During the activity decomposition phase the subMiss Chow Graduate Secretary Department oce activities are decomposed recursively till the specSybase Server DBMS Room 4231 i cation of tasks. The coordination among the sub-activities of an activity is derived and veri ed 2.1.3 Event speci cation by using the input and output external events of In CapBasED-AMS, dierent types of events octhe sub-activities. The input and output external cur, and are used to coordinate, schedule and exeevents are speci ed by using the SNOOP event cute the tasks of an activity. Database events ocspeci cation language. The constructs of ASL are cur when database operations (like, insert, delete, given below:

Activity Id. Description IE Events Sub-Activities OE Events Date Created

/* Unique Activity Identi er*/ /* Description of Activity */ /* SNOOP Event expression */ /* Sub-Activity id's */ /* SNOOP Event expression */ /* Date */

Example (cont.) The speci cation of Graduate Admission activity in ASL is given below. The top level activity is \Graduate Admission" which consists of two sub-activities \Application Completeness Check" and \Application Review". The descriptions of the sub-activities are derived during the activity decomposition phase. Activity Id. Description

Graduate Admission; Processing of applications to Graduate Studies, executed during October-November and February-March each year; IE Events Receipt of(\Applications"); Sub-Activities Application Completeness Check, Application Review; OE Events Send(\Acceptance Letter") r Send(\Reject Letter") r Delete(\Record"); Date Created 7/12/94.

2.3 Activity Decomposition The activity that has been speci ed at the high level must be recursively decomposed to generate a coordination plan at task level. This coordination plan is speci ed by using Task Speci cation Language. Figure 2 presents an algorithm to decompose activities. As it is obvious from the above description of the activity decomposition, we take a pragmatic approach. Each activity needs to be decomposed to task level speci cation once by the user, after which this decomposed task speci cation of the activity can be used for future executions of the activity. Note that from Step 2.(a).ii, if the decomposition of the sub-activity is already available in the knowledge base then it can used. Thus subactivities common to more than one activity need to be decomposed only once.

Example (cont.) The decomposition of subactivities Application Completeness Check, Application Review gives rise to following activity speci cation for Graduate Admissions activity. Note that by matching the output external events and input external events of the (sub-)activities we can derive the coordination plan at this level of speci cation.

Activity Decomposition(Activity)

1. Check if a decomposition of the activity has been done earlier, by checking if the activity is present in the knowledge base. (a) If the decomposition exists, present this task speci cation to the activity initiator for modi cation (if required) and approval. (b) Replace the activity by its Task Speci cation equivalent. 2. If the decomposition does not exist, the user is requested to decompose the activity into sub-activities, (a) For each sub-activity speci ed in Step 2, if it is i. a Task, ask the user to specify the task description. ii. not a task, call Activity Decomposition(Sub-Activity) 3. Continue Steps 1 and 2 till there are no subactivities left to be speci ed. 4. Store the task level speci cation of the activity in the knowledge base. Figure 2: Activity Decomposition Algorithm. Activity Id. Description

Graduate Admission; Processing of applications to Graduate Studies, executed during Oct-Nov and Feb-Mar each year; IE Events Receipt of(\Applications"); Sub-Activities Application Completeness Check, Application Review; OE Events Send(\Acceptance Letter") r Send(\Reject Letter") r Delete(\Record from Database"); Date Created 7/12/94. Activity Id. Application Completeness Check Description Check the completeness of the application IE Events Receipt of(\Applications") r Insert(\Application Incomplete"); OE Events Insert(\Application Complete") r Insert(\Application Incomplete") r Delete(\Application") Activity Id. Application Review; Description Review the applications; IE Events Insert(\Application Complete"); OE Events Any(1,\Accept",\Reject") r Delete(\Application").

Figure 3 shows the coordination plan of graduation admission activity at this level of decomposition. Now we shall describe the task speci cation language.

Application_

Delete(‘‘Application’’)

Completeness_ Applications

Check

End Application_Complete

Start

Application_

Application_

Any(1, Accept,Reject)

Review

Incomplete

Figure 3: The Coordination Plan of Postgraduate Admission Activity

2.3.1 Task Speci cation Language and Match Making

A task is an atomic activity executed by exactly one PSA. The PSA executing the task responds by generating one of the two events \successful execution" or \failure". For some tasks, the PSA can generate other events to convey the status of the task execution. A task is speci ed by using following constructs. Task Id. Description Task Needs Task Type Input Events

/* Unique Identi er of Task */; /* Description of the task */; /* the needs for the task execution */; /* User-de ned or System */; /* A SNOOP expression for input events */; Output Events /* A SNOOP expression for output events */; PSA /* a query statement to select the PSA to execute the task */;

The PSA to execute the task is identi ed at run time by executing the query of form: SELECT PSA.Identi er FROM PSA, PSA Role WHERE PSA.Role = PSA Role.Name AND PSA Role.Abilities = Task.needs;

The match-maker module generates for each task an SQL SELECT statement speci ed above to identify the PSAs that have the abilities to execute the task. If there are more than one PSAs capable of executing the task then one of the PSAs is chosen either randomly, or based on a userspeci ed priorities, or constraints speci ed for task and/or PSAs. The PSAs can be bound to a task at task speci cation time (i.e. static binding) or at task execution time (i.e. dynamic binding). CapBasED{AMS supports both types of binding. If there is no PSA that is selected to execute the task, then we use close world assumption to determine that the task cannot be executed by the activity management system. The user input is

requested to either identify the appropriate PSA by modifying the task needs or to specify a new PSA that has the abilities to execute the task. In our framework we support both these approaches.

Example (cont.) Here is the speci cation of some of the tasks for Graduate admissions activity. Task Id. Description

Insert record (T1); To insert the records of the application forms; Needs fSBDg; Task Type User-de ned; Input Events Arrived(\batch of records"); Output Events Any(1,Finished(\Insertion of records"), Incomplete(\documents")); PSA SELECT PSA.Identi er FROM PSA, PSA Role WHERE PSA.Role = PSA Role.Name AND PSA Role.Abilities = SBD; Task Id. Review record (T2); Description To review the status of each application; Needs fKPR, KFA, CTAg; Task Type User-de ned; Input Events Finished(\Insertion of records") r System(\Time out"); Output Events Finished(T2); PSA SELECT PSA.Identi er FROM PSA, PSA Role WHERE PSA.Role = PSA Role.Name AND PSA Role.Abilities = fKPR, KFA, CTAg;

The graphical representation of task level speci cation of is shown in gure 4.

Example (cont.)Table 1 gives the complete list of tasks, their input external events, and their output external events.

Note that the graphical representation of TSL can be generated by mapping the input external events of one task with output external events of other tasks. A given task cannot start unless its input external events are raised. The TSL is used to describe all the tasks of an activity. The TSL allows for i) hierarchically structured activities, ii) sequential activities, and iii) graph structured activities. We have an intermediate language representation for the coordination plan of the tasks which will be used by the activity generator to generate the activity graph and event graph. We do not present this intermediate language representation due to lack of space. The next section deals with the event-driven execution of the activity.

3 Execution Model for Activity Management The activity coordinator is responsible for propagating the information, coordinating the problem solving agents (PSAs), scheduling and monitoring

T5 Send

E5 T2

reject E12

T4

Review

letter

Check

record

time

E4

T1

T6

E11

Send

out E2

E15

E14

acceptance

Insert

letter

E16

record T3 E3

E10 E13

Request

E7

additional

E1

T9

T7 Arrange

document

interview Delete E6

Start

E17

T8

E8

record E9

Check time out End

Disjunction of Events

Figure 4: Graphical Representation of Task Level Speci cation of Graduate Admissions Activity the execution of tasks of an activity. Interface to the activity coordinator is the activity generator which is responsible for generating the runtime activity graph and de ning set of ECA rules in the active database. The active database system by applying ECA rules supports the activity coordinator in initiating and monitoring the execution of tasks. The activity coordinator by using the active database system has the ability to communicate and exchange data with PSAs through the active database (which can be viewed as a persistent blackboard). Upon failure of a task execution by a PSA, the activity coordinator will also support initiation of prede ned recovery and contingency plans in order to complete the execution of an activity. After the activity decomposition and matchmaking phase, each task of an activity is annotated with the type of PSA selected to execute the task. The activity generator will then generate an intermediate representation of the activity (an activity graph) which shows the graphical representation of the coordination plan for the activity. Dierent kinds of information are obtained from the activity speci cation and the activity decomposition phase, and are used in the generation of the activity graph. Also, an event-based graph (an event graph) will be generated by a mapping of each task with the events whose occurrence will trigger the execution of tasks. Once the activity coordinator initiates the activity execution, a global activity template and

task templates will be created. These templates are used for keeping track of task status. Some of the information contained in these templates is obtained from the speci cation given by the problem manager while others are created to initialize tasks' status before execution. This status information will get updated during actual execution of the activity/tasks. Therefore, the users involved in the activity could be informed about the status of task execution from these templates. During the execution of a task, events involved in the task are raised and corresponding actions are triggered if corresponding conditions are evaluated to be true. Events which do not correspond to any events prede ned in the ECA rule schema of the active database, will be added dynamically during runtime after validating the triggered actions by the users. Since the types of runtime data are de ned before the execution, the actual data needed for execution could be fetched from dierent sources (users or data stores) during runtime and stored in the active database (as a shared workspace, blackboard). Access (both read and write) to these data for the PSAs is only through the activity coordinator which interfaces with the active database manager. Besides, two types of logging, events logging and task logging, are required during execution of tasks. Events logging is done by the active database manager while the tasks logging is done by the task log manager which is also controlled by activity coordinator. Logging is mainly use-

Table 1: List of all the Tasks for Graduate Admissions Activity Task Id. Task Name T1 Insert Records T3

IE Events E1:Applications r E17:Insert(documents) Review Record E2:Application Complete r E7:Application Complete Request Additional Documents E3:Application Incomplete

T4

Check Time Out

E4:Review Due Date

T5

Send Reject Letter

T6

Send Accept Letter

T7

Arrange Interview

E12:Reject Application r E14:Reject Application E11:Accept Application r E13:Accept Application E10:Interview Candidate

T8

Check Time Out

E6:Document Due Date

T9

Delete Record

E8:Time out

T2

ful for recovery if there is any failure during tasks execution. If there is any failure detected during task execution, the activity coordinator will call the recovery manager for nding alternative solutions to nish the task. The recovery manager will consult the capability database system to select a new PSA to nish the task or consult the users to take decisions. Figure 5 gives the architecture of the execution model for activity management.

OE Events E2:Application Complete r E3:Application Incomplete E4:Review Due Date E17:Insert(documents) r E6:Document Due Date E5:Review not complete r E12:Reject Application r E11:Accept Application r E10:Interview Candidate E15:Successful E16:Successful E12:Reject Application r E11:Accept Application E7:Application Complete r E8:Time out E9: Successful

 generating the activity graph which is an intermediate representation of activities,

 generating the event graph which is an eventbased mapping to the activity graph,

 de ning the schema of active database to manage the run time data,

 de ning a set of ECA rules to coordinate and schedule the activity.

The input to activity generator is set of annotated activities in internal language representation generated at the end of the activity speci cation and decomposition phases.

System Catalog Activity Generator PSA1

Activity Graph

Shared Workspace Event Graph ECA rules Runtime Data

PSA2

Templates GUI

3.1.1 Representation of Activity Graph

Activity Coordinator PSA3

Active Database Event Detector

PSA4 Rule Manager Recovery Manager

Task Log Manager

Condition Evaluator ECA rules Database schema

Event Log Manager Capability Database

ActiveDatabase Manager

persistent blackboard for run time data

Capability Manager

Control & Data Flow between modules

Control & Data Flow between Activity Coordinator and PSAs

Figure 5: Architecture for an Event-Driven Activity Execution Model

3.1 Activity Generator The activity generator is responsible for:

For each activity in the AMS, there exists an activity graph which shows the coordination plan of tasks involved to perform the activity. This graph is generated before the actual task execution and gets updated during run time to give the overall activity progress status. The activity graph is represented at the granularity of task level. Each task is atomic and is assigned to one PSA which is capable of executing the task. The activity graph illustrates the schedule of tasks of an activity that need to be executed. Figure 6 shows an example of activity graph. There are basically two types of tasks involved: user-de ned task (represented by a rectangle) which is performed by a PSA (could be hardware, software, human, passive tools or active objects

AND(Task10,Task11;S4)

ANY(Task3,Task4,Task5)

Begin

REP(Task9;Event)

For each task in the Activity Graph { Get relevant events from Task_Event_Table For each event {

ALT(value;Task7,Task8) Task3

SEQ(Task1,Task2)

Task10

If the event not in ECA Definition Table then message user to define and create the ECA rule into the ECA Definition Table

START

Task1

Task2

Task4

S1

Task6

S2

Task7

Task9

S3

S4

Task12

Else { retrieve corresponding ECA rule from ECA Definition Table

END

Task11 Task5

Task8 } End

START/END signalled by Activity Coordinator

User-defined Task performed by PSA

System Task performed by Activity Coordinator

Figure 6: Activity Graph like robot) and system task (represented by a circle) which is performed by the activity coordinator. The synchronization and control structures used in representing the activity are as follows:

 Each user-de ned task or system task is an

activity.  Given a set of activities A1 ; A2; : : :; An: 1. A = AND(A1; A2 [; A3:::; An];An+1) is an activity: all the activities Ai , i = 1; n have to be executed and then An+1 must be executed for activity A to be executed. 2. A = ANY(A1 ; A2[; A3:::; An]) is an activity: any one of the activities Ai , i = i; n must be executed for activity A to be executed. 3. A = SEQ(A1 ; A2[; A3:::; An]) is an activity: activity Ai+1 must be executed after Ai for i = 1; n ? 1 for activity A to be executed. 4. A = REP(A1 [; A2; :::; An];Event ) is an activity: Ai , i = 1; n ? 1 must be repeatedly executed until Event occurs for activity A to be executed. 5. A=ALT(decision value;A1[; A2; :::; An]) is an activity: one of the activities Ai i = 1; n ? 1 must be executed depending on the decision value for activity A to be executed. 6. Any number of invocations of above ve rules.

Example (cont.) Consider the graduate ad-

mission activity, Figure 7 shows the activity graph generated by the activity generator.

Each task may raise one or more events. When an event occurs and if it corresponds to an ECA rule previously de ned, the corresponding action(s) is triggered if the corresponding condition

} add the rule to the task-rule set } augment the event graph with the new event

Figure 8: Algorithm to generate Event Graph from Activity Graph by the Activity Generator is satis ed. The ECA rules stored in the active database are retrieved and used in generating an event graph. Similar to the activity graph, the event graph is created before actual execution of the activity and gets updated during runtime. If the event(s) raised do not correspond to any of the prede ned ECA rules but are relevant to the task execution, then an ECA rule is created and added to the ECA rule table in the active database schema and the event graph gets updated at the same time. Thus, each activity graph will be mapped to a corresponding event graph. Figure 8 gives the algorithm to generate the event graph from the activity graph. Figure 9 shows partial mapping between few tasks and the corresponding event graph. SNOOP language [5] is used to specify events raised in each task. Task2

Task1

S1

S2

Task3

E5

R5

E6

E1

R1

E3

R3

R2

E2

R6

R7

E7

R9

E10

R10

R8

E8

E4

E9

E11

Entities/Relationships, PSA (human agent or hardware/software agent)

Rule relevant to overall activity execution

Event relevant to overall activity execution Event irrelevant to overall activity execution Fires

Rule irrelevant to overall activity execution Raises

Affects/Affected_by

Figure 9: Mapping between a task and its events

Example (cont.) Figure 10 shows the events raised for T1, T2 and S1. Events for other tasks are generated similarly.

T5 send reminder

T6 arrange interview

timeout

T7 ’reject’

’interview’ document status = ’complete’

START

T1 Insert / Update candidate record

Not timeout S4 S3 timeout check review. review due_date status

T2 review record

S1 check document status status= ’incomplete’

T8 ’accept’

T3 request additional documents

timeout S2 timeout candidate. due_date

send reject letter

send acceptance letter

END

T4 delete candidate record

Not timeout

Figure 7: Activity graph for Graduate Admission Activity T1

E1 start (T1)

Event Rule

R1

Fires

T2

S1

E2 finish(T1)

E2 finish(T1)

R2

E3 start (S1)

R3

E3 start (S1)

E4 start (T2)

E4 start (T2)

E5 finish(T2)

R4

R5

E5 finish(T2)

E6 start (S3)

Raises

Figure 10: Mapping between activity graph and event graph for graduate admission activity

3.1.2 Generating ECA rules and Active Database Schema Before activity execution, ECA rules relevant for tasks execution are created and stored in an ECA De nition Table in the active database. Also, relevant entities/relationships, data sources, PSAs (human, software, hardware) aected by these ECA rules have to be stored in the run time active database to support activity execution. An ECA De nition Table is de ned as RuleTable(Ruleid,Eventid ,Conditionid,Actionid ). The table has an index on Eventid which will be used for fast retrieval of ECA rules stored in the active database. Besides, the following relations are de ned for storing details about event, condition and action components of an ECA rule: Event(Eid ; Etype ; Description; Objectaffected,Rulefires) Condition(Cid ; Ctype; Description) Action(Aid ; Atype ; Description; Objectaffects,Eventraises)

During actual execution of tasks, an Event Log Table de ned as EventLog (Time, Event, Object, Preaction, Postaction) is created in the active database and controlled and managed by the Event Log Manager. This table stores for each event, the time of occurrence, event identi er, status of pre-action and post-action of the object affected.

Example (cont.)For semantic details, refer to the corresponding Rule De nition Table, Event Table, Condition Table and Action Table de ned for this example.

Ruleid R1 R2 R3 R4 R5 EId E1 E2 E3 E4 E5

Rule De nition Table: Eventid Conditionid E1 C1 & C2 E2 C3 E3 C4 E4 C4 & C5 E5 C6 & C7

EType sys(message) ext(signal) sys(message) sys(message) ext(signal)

Actionid A1 A2 A3 A4 A5

Event Table: Description Objectaffected start(T1) Secretary nish(T1) Secretary -> Candidate database start(S1) Act Cdr start(T2) Grad Cdr nish(T2) Grad Cdr -> Candidate database

Rulefires R1 R2 R3 R4 R5

In the aected objects column the term \Secretary -> Candidate database" implies that Graduate secretary has to perform the task of inserting a new record into the candidate database. This explicitly models the interaction between active PSA and passive PSA. This is useful in recovery as AMS can immediately identify the active PSA for assistance. Similarly, other interactions are explicitly speci ed. CId C1 C2 C3 C4 C5 C6 C7

Ctype ext db sys ext db sys sys

Condition Table: Description available(Secretary) inserted(Candidate.database) available(Act Cdr) available(Grad Cdr) updated(Candidate.database) available(Act Cdr) timeout(T2)

AId A1 A2 A3 A4 A5

AType sys(message) sys(message) sys(message) sys(message) sys(message)

Action Table: Description Objectaffects nish(T1) Secretary - > Candidate database start(S1) Act Cdr start(T2) Grad Cdr nish(T2) Grad Cdr - > Candidate database start(S2) Act Cdr

Eventraises E2 E3 E4 E5 E6

During runtime, the Event Log Manager in the Active Database will log the events raised in the Event Log Table. Time T1 T2 T3 T4 T5

Eid E1 E2 E3 E4 E5

Event Log Table: Object Preaction Secretary available Candidate.database NULL Act Cdr available Grad Cdr available Candidate.database NULL

Postaction busy inserted busy busy updated

3.2 Activity Coordinator The Activity Coordinator is responsible for:  Initiating and Controlling execution of tasks with the support of active database  Updating and Monitoring task execution status  Serving as a communication agent among PSAs of which have no direct communication capability among themselves  Logging task execution for recovery purpose  Passing control to the activity recovery manager if a failure occurs during the task execution  Sequencing and scheduling tasks to be performed Before the execution of tasks, the activity coordinator is also responsible for creating dierent types of templates which are mainly used for keeping track of status of active and completed tasks and relevant raised events. These templates are used for users enquiries about the current progress of the activity execution and the status information are shown by means of a GUI to the users. The following is the list of templates required to keep track of activity execution: 1. Activity Template : keep track of the global activity status. Activity Template = : STRING; % activity identi er ( activity id : list(tasks); % list of tasks task list owner : STRING; % activity issuer constraints : STRING; % global constraints Interrupts : list(interrupts); % interrupts occur nished list : list(tasks); % nished tasks : list(tasks); % executing tasks executing list : list(tasks); % un nished tasks un nished list Input para : in para list; % input data : out para list; % output data Output para % execution result Execution status = (not started, executing, nished, aborted) )

2. Task Templates : keep track of each task execution status. task template = ( task id : STRING; % task identi er owner : STRING; % task issuer activity : STRING; % relevant activity PSA : STRING; % PSA responsible : STRING/NULL; % previous task(s) Pre task(s) Post task(s) : STRING/NULL; % next task(s) : STRING/NULL; % relevant task(s) relevant task(s) Events : list(events); % events raised Input para : in para list; % input data : out para list; % output data Output para % execution status Execution status = (not started, executing, nished, aborted) ) 3. Event Template : de ne properties of a event. Event Template = ( event id : STRING; % event identi er : STRING/NULL; % relevant task task id event type : event type; % object(s) aected aected object(s) : STRING; at time{stamp % initial value NULL by PSA name ) % initial value NULL where event type = (db(insert,modify,retrieve,delete), ext(signal), sys(message)) 4. Condition Template : states conditions need to be evaluated when a event raised. Condition Template = ( condition id : STRING; % condition identi er : condition type; % type of condition condition type condition description : STRING; % descriptions event(s) : list(event) ); % relevant event(s) where condition type = (db, ext, sys) 5. Action Template : states actions to be taken when an event raised and its conditions are true. Action template = ( action id :STRING; % action identi er :action type; action type event(s) :list(events); % events triggered task(s) :list(tasks); % relevant tasks % objects aected aects object(s) :list(objects); action status = (success, fail); at time{stamp by PSA name ) where action type = (db(modify,insert,retrieve,delete), ext(signal), sys(message))

3.2.1 Initiating and Controlling Execution of Tasks

Upon receiving the START event raised by activity owner, the activity coordinator will start the activity execution. At this time, all the templates mentioned above will be created. By using the event detector in the active database, the activity coordinator will be noti ed which events are raised, and it will pass control to the condition evaluator and evaluate relevant conditions and the corresponding actions are triggered. Such actions again will raise some events and the cycle repeats until the END event is raised. Therefore, the execution of tasks is guided by the chains of ECA rules which are prede ned prior to the actual execution. The activity coordinator serves as the global manager which has the knowledge and ability to schedule and control the overall execution of tasks. Figure 11 presents the algorithm used by activity coordinator to execute the activities.

Example (cont.)The following is the activity template de ned for this example before execution of tasks.

Activity Template = : GradAdm; ( activity id task list : (T1,T2,T3,T4,T5,T6,T7,T8,S1,S2,S3,S4); owner : Activity Coordinator; global constraints : Deadline=5 May, 94; events/interrupts : (E1,E2,E3,E4,E5,...); : NULL; nished list executing list : NULL; : (T1,T2,T3,T4,T5,T6,T7,T8,S1,S2,S3,S4); un nished list Input para : application records in candidate database : student records in student database Output para Execution status = (not started));

On start (Activity) Begin Activity.execution_status = NULL; Create and Initiate Activity_Template ; For each task in the activity { Create and Initialize Task_Template ; For each event raised by the task { Create and Initialize ECA_Templates ; } } While Activity_execution_status != FINISH For each task in the task_list

{

If the PSA = Activity Coordinator then Activity Coordinator starts execution of the task ; Else { Send message to the PSA to execute the task

;

On receive (message) from PSA If task_execution_status = FAIL then Call RecoveryManager to select another PSA to do the task; ; } Update Activity_Graph, Event_Graph; Update Activity_Template, Task_Template, ECA_Templates; Call TaskLogManager to do task log; Call EventLogManager to do events log On receive (message) from users Retrieve relevant information from templates and prints to the users. If task_execution_status = SUCCESS and Activity.execution_status != FINISHthen continue; Else Actvitity.execution_status = FINISH; } End

Figure 11: Algorithm to execute activity by the Execution Manager

3.2.2 Monitoring of Tasks Execution Templates created prior to the execution of tasks need to be updated as tasks execution continue to re ect the most updated status information for both task and events involved in the activity. Thus, responses to enquiries from authorized users or PSAs are eectively managed. Update is done by the activity coordinator since it has the overall control of the system.

Example (cont.)After execution of tasks T1,

S1 and during execution of T2, the activity template de ned for this example is updated as shown below. Activity Template = ( activity id : GradAdm; task list : (T1,T2,T3,T4,T5,T6,T7,T8,S1,S2,S3,S4); owner : Activity Coordinator; constraints : Deadline=5 May, 94; interrupts : (E1,E2,E3,E4,E5,...); : (T1,S1); nished list executing list : (T2); : (T2,T3,T4,T5,T6,T7,T8,S2,S3,S4); un nished list : application records in candidate database Input para Output para : student records in student database Execution status = (executing));

3.2.3 Communication Protocol between Activity Coordinator and PSAs

For each PSA capable of doing a task of an activity will communicate with the activity coordinator as follows: 1. Wait for request from the activity coordinator to process the task. 2. Process the task. 3. Report the state of processing at periodic intervals by raising events informing the status of task execution. 4. After nishing the task, report the nal execution status as a failure event or a success event.

The activity coordinator will issue the command to the assigned PSA to carry out the task. Periodically, the activity coordinator will be noti ed about the task execution status by the PSA and the activity coordinator will update the template information accordingly. Note that all the above communication between the PSAs and the activity coordinator is orchestrated by the occurrence of events, satisfaction of corresponding conditions, and triggering of corresponding actions.

3.2.4 Task Logging and Event Logging

There are two main types of logging needed in CPS environment, namely, task logging and event logging. The logging component is mainly reserved for recovery purposes in case of failures. Task logging is done by Task Log Manager. The activity coordinator passes control to the task log manager which obtains log data from the blackboard portion of active database and the templates. On the other hand, events log is done by the Event Log Manager within the active database system.

3.2.5 Activity Failure Recovery

The activity coordinator carries out the sequences of actions to execute the activity. If a task is executed correctly, the activity coordinator launches the next task, otherwise, in case of failure, it will pass control to the recovery manager. If an execution failure occurs during activity execution, the recovery manager analyses the situation (i.e. locates the origin of the failure). A priori information about the possible failures of a task execution are retrieved and appropriate action is initiated. One of the actions could be that the recovery manager passes control back to the match maker

which will consult the capability database to select another PSA to complete the task execution.

3.3 Active Database Manager In our CapBasED{AMS environment, the active database manager is responsible for:

 Managing ECA rules by event detector, condition evaluator and rule manager

 Managing access of data in the blackboard

portion (shared workspace populated with runtime data) through the active database transaction manager

 Logging events by the Event Log Manager

3.4 Database Support for Activity Management System The CapBasED{AMS is a database supported system and dierent types of databases are maintained to facilitate activity speci cation, decomposition and execution. Firstly, the active database supports the activity coordinator in monitoring the execution of tasks. ECA rules de ned in the active database are useful in detecting events and triggering the corresponding actions. The active database contains the ECA rules and schema information for task execution. A portion of the active database is also used as a dynamic and temporary global shared work space for storing data, knowledge, execution information and constraints for cooperating PSAs. This information is used by the activity coordinator for activity execution. Secondly, the capability database in AMS is used to store the knowledge regarding the capabilities of PSAs. After activity decomposition phase, a PSA which have the ability to execute a task of an activity is selected and assigned to execute the task. The capability database is also accessed by recovery manager to select alternate PSA to execute the task in case of failure. Thirdly, the knowledge base is used for storing knowledge acquired during problem decomposition. This knowledge is used for facilitating automatic activity decomposition by the AMS instead of consulting users whenever a similar activity initiated again. Fourthly, the case base is reserved as problem catalog library for re-usability and to avoid duplicating costly modeling eort. It stores the procedural and semantic knowledge about activity execution as ASL speci cation, TSL speci cation,

activity graph and even graph. Thus facilitating ecient execution of frequently initiated activities. Finally, the system catalog stores the activity graph which is generated by the Activity Generator. During activity execution, a runtime copy of the activity graph will be placed in the shared workspace. The system catalog will also contain the ASL, TSL speci cation of the activity and the schema description of tables storing the PSAs, and tokens.

4 Related Work The OASIS architecture which supports work ow management as discussed in [18] comprises a network of MOAP nodes of each has xed infrastructure in order to achieve overall coordination. All the PSAs in our proposed system are autonomous, cooperative and independent. The centralized AMS is built upon these existing PSAs which cooperate to nish an activity under prede ned coordination strategy. Therefore, our proposed system is more exible as our AMS system is not limited to an homogeneous environment. The communication and synchronization protocol in our AMS is mainly controlled by the activity coordinator and through the active database persistent blackboard. The interaction is event-based. On the other hand, each agent in ABS work ow management system [6] is con ned to the same synchronization policy in order to communicate and cooperate to nish the activity. Also, [6] do not elaborate on how the capabilities are managed and match making is performed. FlowMark [12] is another system that supports work ow management based on DAG representation of tasks for business process management. The activity graph cannot be modi ed at run time. FlowMark does not use capability based activity decomposition. The ConTract Model [17] focuses on activity control and execution and not activity speci cation and decomposition. Reliable Flow Manager based on [8, 10] uses tree based activity graph which has limited applicability and focuses only on activity execution and not on speci cation and decomposition. The CapBasED-AMS proposed in this paper is based on the centralized architecture for cooperative problem solving proposed in [4]. The system has no inherent ability to reason about the nature of the problems and solve it. It solves a certain class of problems about which the system has the knowledge to solve. Also, problem decomposition knowledge and coordination strategy are a priori de ned, activity execution and facilities provided for exception handling for unexpected system fail-

ure are also prede ned and stored in the database for recovery purposes. Finally, this paper does not concentrate on the speci cation and execution of multiple work ows as discussed in [9, 15]. However, our proposed system will be extended to cover concurrent execution of activities.

5 Conclusions and Future Work In this paper, we have i) presented an architecture for activity speci cation, decomposition and execution, ii) developed the concept of capability bases activity decomposition and match making, iii) identi ed the interaction among various modules of activity management system during activity execution, and iv) developed an event-driven execution model for activity execution. By splitting the architecture into capability-based activity speci cation and decomposition, and event-driven activity execution we have provided some levels of independence between these two components. This facilitates development and incorporation of novel techniques for activity decomposition without modifying activity execution component and vice versa. This also facilitates provision for interface at dierent levels, namely, activity speci cation level, task speci cation level, and activity graph level. An immediate advantage of this will be support for automatic speci cation and execution of the activities. Any system that can generate activity speci cation at activity graph level can be an user of the CapBasED{AMS. This is useful in distributed activity management. CapBasED-AMS does not limit the PSAs that it can interact with, as long as the activity coordinator can send a message for initiating the task to the PSA, and PSA can execute the task after the receipt of the message, and then send a \successful" or \failure" message after the task execution. This is a major advantage with our approach because we can add PSAs as long as we store their abilities in capability database. For example, we can add an activity decomposition module as a PSA and give it an activity to decompose, thus enabling boot-strapping. Since the communication among PSAs is handled through the activity coordinator, protocols in business decision taking can be supported by CapBasEd{AMS. We are currently implementing the AMS based on the framework proposed in this paper. In parallel, we are conducting case-studies to evaluate and validate our approach to activity management and execution. After building the basic system, we are going to incorporate handling of dependencies between concurrently executing activities and

support for distributed activity management. Acknowlegements: We thank Fred Lochovsky and Qing Li for their comments and suggestions on this work.

References

[1] A. Barr, P.R. Cohen, and E.A. Feigenbaum. The Handbook of Arti cial Intelligence, vol.IV. Addison-Wesley, 1989. [2] A.H. Bond and L. Gasser. Readings in Distributed Arti cial Intelligence. Morgan Kaufmann, 1988. [3] M. L. Brodie and S. Ceri. On intelligent and cooperative information systems: A workshop summary. International Journal of Intelligent and Cooperative Informat ion Systems, 1(2):249{290, June 1992. [4] S. Chakravarthy, K. Karlapalem, S.B.Navathe, and A.Tanaka. Database supported cooperative problem solving. International Journal of Intelligent and Cooperative Information Systems, 2(3):249{287, September 1993. [5] S. Chakravarthy and D. Misra. Snoop: an expressive event speci cation language for active databases. Data & Knowledge Engineering, 14(1):1{26, Nov 1994. [6] Stefan Jablonski Christoph Bussler. An approach to integrate work ow modeling and organizationa modeling in an enterprise. Proceedings of the Third IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE), MorganTown, West Virginia, USA,

[7] [8] [9]

[10] [11]

April 1994. R. Davis and R. G. Smith. Negotiation as a metaphor fo distributed problem solving. Arti cial Intelligence, 20(1):63{109, 1988. U. Dayal. Active Database Management Systems. In Proceedings 3rd International Conference on Data and Knowledge Bases , Jerusalem, Israel, June 1988. D. Georgakopoulos, M.F. Hornick, F. Manola, M.L. Brodie, S. Heiler, F. Nayeri, and B. Hurwitz. An extneded transaction environment for work ows in distributed object computing. A Quarterly Bulletin Computer Society IEEE Technical Committee on Data Engineering, 16(2), June 1993. M. Hsu, A. Ghoneimy, and C. Kleissner. An execution model for an activity management system. DEC TP West, April 1991. Meichun Hsu. Special issue on work ow management. A Quarterly Bulletin of IEEE Computer Society Technical Committee on Data Engineering, 16, June 1993.

[12] F Leymann and D. Roller. Business process management with owmark. In IEEE Compcon, 1994. [13] F. Manola, S. Heiler, D. Georgakapoulos, M. Hornick, and M. Brodie. Distributed object management. International Journal of Intelligent and Cooperative Information Systems, 1(1):5{42, March 1992. [14] M. P. Papazoglou, S. C. Laufmann, and T. K. Sellis. An organizational framework for cooperative intelligent information systems. International Journal of Intelligent and Cooperative Informat ion Systems, 1(1):169{202, March 1992. [15] A. Sheth and M. Rusinkiewicz. On transactional work ows. A Quarterly Bulletin Computer Society IEEE Technical Committee on Data Engineering, 16(2), June 1993. [16] R. G. Smith. The contract net protocol: High level communication and control in a distributed problem solver. IEEE Transactions on Computers, 29(12):1104{1113, 1980. [17] H. Waechter and A. Reuter. Database Transaction Models for Advanced Applications. A. Elmagarmid (Ed.) Morgan Kauman Publishers, 1992. [18] C. C. Woo and F. H. Lochovsky. Knowledge communication in intelligent information ssytems. International Journal of Intelligent and Cooperative Informat ion Systems, 1(1):203{228, March 1992.