Implementation of Web-based Event-driven Activity Execution in CapBasED-AMS

The CapBasED-AMS (Capability-based and Event-driven Activity Management System) is a workflow system developed in [5] deals with the management and execution of activities. A Problem Solving Agent (PSA) is a human, or a hardware system, or a software system having an ability to execute activities. An activity consists of multiple inter-dependent tasks that need to be coordinated, scheduled and executed by a set of PSAs. The activity execution is based on the occurrence of events. That is, a PSA after completion of a task (atomic activity) generates events, which are captured by the activity management system, for initiating the execution of the next task. In this paper, we describe three-tier system architecture to implement Web-based event-driven activity execution of CapBasED-AMS. Introduction and Motivation Many application domains like, office automation, planning, medical diagnosis, manufacturing systems, etc., need interaction between humans and systems, and among humans for conducting day-to-day work. Moreover, workflow systems are becoming very popular and are being used to support such activities in large organizations. One of the major problems with workflow system is that they often use heterogeneous and distributed hardware and software systems to execute a given activity. With the popularity of Internet technologies, this is a need for web-based workflow system, which is platform independent. In this paper, we describe three-tier system architecture to implement Web-based event-driven activity execution in CapBasED-AMS. Architecture of Secure CapBasED-AMS 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 specification, maintenance, and execution of activities is known as an Activity Management System (AMS). Capability-based activity specification and decomposition: Each PSA has its competence defined by set of capabilities it has to execute tasks. Each activity requires a certain competence from the PSAs specified as a set of needs for executing all of its tasks. 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 capabilities to meet the needs of the task. In AMS, we use tokens to model the capability/need of a PSA/task respectively. This is the new idea which has not been applied in related works, because most of the related works model this concept by applying role based or hard-coded solutions. We present a new philosophy of applying capability-based approach as the bridge mechanism for matching a PSA to a task. A token is more flexible to handle and organize in the Capability Database, since a token does not belong to any fixed architecture. The match making of each task to an appropriate PSA can be done automatically by simple SQL queries on the Capability Database. The specification of activities, sub-activities, tasks and PSAs are all user-driven. We define this aspect of activity management as capability-based activity specification and decomposition [4]. 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 expressed by means of a uniform framework of events, as i) system event models data/control dependencies among tasks of an activity within the AMS, e.g., receipt of data from a PSA or completion of a task denotes the occurrence of a system event, ii) external event models external dependency which affects the execution of an activity from a stimuli outside the AMS, and iii) temporal event models temporal dependency. For each task, there are two types of events associated with it, namely In-events and Out-events. In-events are the situations in which the task is initiated to execute whereas Out-events are the effects after the execution of the task. Both In-events and Out-events can be one or more of the event categories described above. Note that both In-events and Out-events can correspond to receipt and delivery of documents processed by a task. Based on the events raised, an Event-Condition-Action Rule [2] (ECA Rule) is