The Workflow Reference Model

WfMC is a non-profit organization whose mission is to establish standards for workflow terminology, interoperability and connectivity [2]. The Workflow Reference Model [8] proposed by WfMC, as illustrated in Figure 2, defines several components and interfaces.

The interface around the workflow enactment service is designated as Workflow APIs (WAPI) and Interchange formats, which may be considered as a set of constructs by which the services of the workflow system may be accessed and which regulate the interactions between the workflow control software and other system components.

Figure 2. WfMC's Workflow Reference Model 2.2 Past researches

There are several WfMSs designed and implemented to support interoperability[3][9][10][11][12][13][14][15][16][17][19][20][21]. Events and rules have been used in several workflow projects. Fabio Casati [11] [12] presents a workflow event model, of which it is a message passing based model, and it allows interoperation among processes in different organizations in the WIDE [16] project. In his work, the traditional

workflow model by enhancing the traditional workflow to publish and subscribe to event for interaction was extended. The event dispatching mechanism that he proposed handles the events according to the priorities of event publication, business convention or cost…etc. The METEOR [17] project of Georgia University uses the interface-based generator to produce the interoperable interfaces during design time. When two WfMSs need to be interactive with each other, they call interfaces via CORBA-IIOP [18]. Stanley YW Su [3][13] presents a solution to achieve dynamic Inter-enterprise workflow management using the e-services provided by cooperative e-business enterprises. This constraint-based dynamic e-service binding mechanism allows inter-enterprise workflow process models to be processed in the Internet environment, in which business organizations and their services are changing constantly. Davulcu [19][20] proposes a framework based on Concurrent Transaction Logic (CTR) for modeling and reasoning about interactions in a virtual enterprise. He uses CTR to coordinate execution sequence of processes. However, it is difficult for user to construct workflow processes. Dickson [21] proposes a meta-model of workflow views and develops an interoperation model based on workflow views. However, each party may need to make modification to its own workflow for interoperable interface. The interoperation mechanism is not loosely coupled; in other words, a party that modifies its own workflow may influence other party’s workflows or views.

The Workflow Management Coalition (WfMC) [2] has also proposed an abstract interoperability specification to allow the interoperability of workflow specifications supported by different WfMSs. It releases Wf-XML [22] specification of standard message format for interoperation. It provides a structure and well-defined model for WfMSs interoperability, which is independent from the transport mechanism and platform. These standard specifications are summarized and used to propose a new cooperative workflow meta-model to define cooperative processes between different WfMSs. Projects mentioned above extend the WfMC’s WPDL model by adding different constructs to model the

organizational process. Their works primarily focus on transport mechanism of inter-organizational process.

Based on organizational viewpoint, it is necessary to decompose an inter-organizational process and propose an integrated workflow component model to describe it.

The security issues of enacting and monitoring an inter-organizational process between different WfMSs across organizational boundaries should be considered for different workflow applications. The inter-organizational process monitor and administration between different WfMSs should be configured with appropriate authority for distinct workflow application.

2.3 A Simple overview of PLAN

The Software Process Model, PLAN (Process LANguage) [4], developed in our laboratory, is used to model the software development project. PLAN was built to write the context that indicates how activities will be performed. This in turn manipulates artifacts with the required resources, as shown in Figure 3. A role, such as programmer, defines the responsibilities within an organization. Besides, a role has administrative relationships with sub-roles. To do a project, each role needs to communicate with other roles. A process can also be decomposed into a set of sub-processes/activities. There are two kinds of activities:

operation and analysis. An operation modifies the state of an artifact(s). To gauge project information, an analysis refers to, but not the changes of artifact states. Process behavior controls the execution sequences of activities. Each artifact has its own lifecycle, which is characterized by states during development. Furthermore, an artifact may consist of a set of sub-artifacts. As depicted in the conceptual framework, a PLAN process definition also contains the web-linking semantics of a software process.

Figure 3. Conceptual Framework of PLAN

Chapter 3 Workflow Development Environment - Agentflow

3.1 Cooperation Workflow Model CA-PLAN

The main issue for a workflow system is answering the question “who must do what, when and how”. Workflow is defined by WfMC [2] as the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules [1]. According to the definition, a process consists of three major elements as shown in Figure 4.

z Activity – activities involved in the processes coordinate according to a set of procedural rules. An activity (the “what” part of the issue) presents something to be done and transitions define the appropriate sequence of activities of a process (the

“when” part of issue).

z Artifact – documents, information handled by the processes. The “how” part of the issues specifies an associated application of each activity.

z Role – the roles of the participants involved in the processes. The “who” part of the issue specifies the participants of each activity.

Figure 4. Three major elements of a process: activities, roles, and artifacts

3.1.1 CA-PLAN Meta Model

The workflow meta-model describes the top-level entities contained within a workflow process definition, their relationships and attributes. Cooperative Agentflow Process LANguage (CA-PLAN) meta-model as shown in Figure 5 supports general workflow processes, and simplifies seamless remote process invocation to suit for inter-organizational workflow.

Figure 5. The CA-PLAN Meta Model

A Project is a collection of related processes, artifacts and project roles providing access protection and namespace management. A Process can be decomposed into a set of sub-processes/activities. An activity can be divided into two types: automatic activity and human activity. A human activity is assigned to Process Participants to perform the work and

an automatic activity is automatic execution by computer applications. An Activity also contains entrance condition, exit condition, version, time/event functions, exceptions, and process actions (Pre-Action, Action, Post-Action) attributes.

Artifact has two elementary properties Artifact States and Artifact Attributes. Artifact Attributes define the data model of workflow-application that handled by a process. Each Artifact has its own lifecycle, which are characterized by Artifact States during development.

Each Artifact State contains a state condition that is a logic expression defined by Artifact Attributes.

An Activity may manipulate an Artifact and change the state of the Artifact. The Process Transitions define the execution sequences of Activities. Each individual Process Transition has three elementary properties, the from-activity, the to-activity and the conditions (involving expressions which are evaluated to permit or inhibit the transition) under which the transition is made. The Transition condition is an expression by an Artifact State of the operation Artifact of the form-activity. The transaction is fired when the from-activity manipulates the attributes of the operational artifact and changes the artifact’s state that satisfies the condition of the transaction.

An Artifact can view as a workflow-application data model and have many different types of views (Form). A Form can have many types presentation (HTML, Applet, ActiveX, PDF form, Word, etc…). A Form contains a set of Form Fields and Form Actions. An electronic Form is a container that can contain all of the software components (label, button, text field etc…) in the window's GUI. The Form Field specifies the attributes of the software components. Form Actions (PreAction, OpenFormAction, CloseFormAction, PostAction, and Corresponding Actions of Software Components) define corresponding operations that are triggered when users manipulate the Form.

Each Process Participants can communicate with other Process Participants by Messages. The Process Participant provides descriptions of resources that can act as the

performer of the various activities in the process definition. The Process Participant assignment mechanism has two binding types: Design-Time-Binding or Run-Time-Binding.

The Design-Time-Binding mechanism selects the candidates for the Process Participant in the process design time phase. However, Run-Time-Binding selects the candidates for the Process Participant to delay in the process enact phase. The Process Participant declaration may refer to organization model, project role model, process performer of another Activity, Artifact Field (that contains user information) or user customized method that implemented by scripts of process actions, as shown in Figure 6.

Figure 6. Process participant assignment mechanism

Agentflow provides an event-action handling paradigm for user to interact with runtime operations of a WfMS. The workflow runtime system may generate many kinds of Runtime Events, for example ServerStart (workflow engine starting), ServerStop (workflow engine closed), RedispathTask (administrator reassign a task), DeputyEnable (user enable the deputy mechanism) … etc. Event Actions can be registered as event listener on a Runtime Event. If the Runtime Event is fired by system, the corresponding registered Event Actions will be triggered and executed. The Process Action, Form Action, and Event Actions use the Agentflow scripting language that the syntax is same as JavaScript [23] and extends some Agentflow host objects) to manipulate, customize and automate the facilities of Agentflow workflow system.

To adapt dynamic and competitive business environment, enterprises constantly reconsider and optimize the way they do business and change their information system and applications to support evolving business processes. Agentflow system provides a process version mechanism to support process evolution. In the mechanism, if a process definition needs to change, the reviser creates a new definition version from current version and modifies the created one.

To support process design with better modularity and provide process a reuse mechanism, Agentflow system provides a Call-Process activity construct. A Call-Process activity is an activity that contains the attributes including a called process’s ID and a unique identity. The called process’s ID refers to an ID of the called process. The definition of a called process may evolve to a new version; if no specification, the Call-Process will use the definition of newest version for the enacted process (instance) process to execute. This version mechanism allows user to modify the definition of a called process with different versions, and all Call-Processes will take the changes.

A Workflow Domain (WD) is a workflow management boundary that provides a common Process Definition Repository (PDR) and Runtime Repository (RTR). The PDR stores process definitions including projects, processes, artifacts, and forms. The RTR stores execution and log data of processes including process instances, artifact instances, and form application data. A workflow domain may consist of one or more workflow engines that access the same PDR and RTR. An organization can be deemed to be associated with one or more workflow domain. As shown in Figure 7, organization A contains workflow domain A which contains two WfMSs WA1 and WA2. Organization B contains two workflow domains, B1 and B2, where domain B1 contains WfMS WB1 and domain B2 contains WfMS WB2.

Figure 7. Call-Process Model (local/remote environment)

The activities of an inter-organizational process are provided by different organizations to achieve a common business goal. Each organization can design the corresponding activities within its organization into (intra-)processes and pack these processes as its Process Services. When a process P1 needs to integrate with a process P2 of another organization, P1 can use an activity that points to Remote Process RP_A to refer to the process service PS_A of the target organization for registration and thus P2 is enacted.

Each process service acts as a proxy for an intra-process and also defines the signature, the process arguments, and it returns the values of the intra-process. The inter-process uses a Remote Process (RP) to refer to a specified process service, and then the target process service (instance) is used to refer to the actual intra-process.

The workflow control and application data are passed through Process Call Data (PCD). The PCD is a mapping mechanism that specifies the communication data of two types:

IN and OUT, between process service and remote process. When an inter-organizational workflow process runs to its RP step, a set of process data are passed to the corresponding process service for handlings. When the process service is completed, the result data are sent back to the RP for resuming the next activities. Based on parameter types, IN and OUT, a mapping mechanism is constructed between virtual parameters of a RP and physical parameters of a process service in our system, as shown in Figure 8. A Parallel-Event is used for RP to synchronize peer remote-process in whole inter-workflow process during cooperation.

Figure 8. Mapping mechanism of parameters in an inter-organizational process 3.2 Integrated Workflow Component

In this sub-session, we present a cooperative workflow meta-model CA-PLAN to model inter-organizational processes. An inter-organizational process is a process whose activities are performed to cooperate, coordinate, and interact among different organizations over Internet. CA-PLAN extends the underlying model, PLAN [4], by adding remote processes, process services, and process control data as its modeling activity definitions, and by allowing a process in one WfMS to enact and monitor a remote process in another WfMS over network. In CA-PLAN, an inter-organizational process could be partitioned into several

parts based on organizations. CA-PLAN lets a workflow system inside an organization be modeled as an Integrated Workflow Component (IWC) as shown in Figure 9.

Figure 9. Integrated Workflow Component

Each IWC contains a process service interface specifying the process services provided by the organization, in conjunction with a remote process interface specifying the remote processes used in the intra-organization processes, and intra-organizational processes of the organization. Process service and remote process are input and output connector pin of an IWC. An inter-organizational process is defined as a routing path and assembled by IWCs through connection between their process services and remote processes. Each organization provides a set of process services for its partners. Each process service is referred to an intra-organizational process of the organization. An organization can integrate partner's process services by using remote processes. The activities/processes (of an intra-organizational

process) refer to the remote processes and then the remote process refers to a process service provided by partners.

For example, organization A in Figure 10 contains an intra-organizational process ProcessA1 which has an activity Act4 that refers to a remote process (RPA1). The RPA1 refers to Process service PSB1 of organization B. The PSB1 then refers to intra-organizational process ProcessB1 of organization B. The organizations A and B construct an inter-organizational process that links ProcessA1 and ProcessB1 by RPA1 and PSB1.

Figure 10. An inter-organizational process diagram

By using the indirect mapping mechanism for these two layers, an inter-organizational process can be partitioned into intra-organizational processes within different organizations.

Whenever the corresponding process service has no change, an intra-organizational process may change to adapt the business requirements. This mechanism increase modularity, flexibility and reusability in design inter-organizational process. Besides, an intra-organizational process can be deemed as an inter-intra-organizational process again, and this mechanism can be applied in a top down manner recursively.

There are three layers adopted for presentation and detailed handlings in CA-PLAN.

The top layer lets designer devise an inter-organizational process as an intra-organizational

process (i.e., processes in WfMS). The medium layer, based on Java machine, provides a communication and management mechanism to help the design implicitly. This cooperative mechanism between WfMSs in CA-PLAN is modeled as a Remote Call Process (RCP) mechanism. RCP is a process-specific middleware that allows a process to enact a remote process as if it were a local (intra-organizational) process. RCP also supports the ability to manage, control and monitor the execution of an inter-organizational process instance. RCP hides the underlying mechanism of enacting a remote process, transporting process arguments and returns the values across the WfMSs. The bottom layer is a transport layer that may use http, web service, java rmi …etc.

In the top layer, the designer applies the tools in the workflow management system, (here we use Agentflow system to support the behavior) to write his/her inter-organizational workflow (processes). What he/she needs to concern is the existence of service process instances in corresponding sites and their input/output data. The tools in Agentflow system contain convenient graphical process design to pack a process service and to model inter-organizational processes. Agentflow also provides a process runtime environment to enact, control, and monitor the execution of inter-organizational processes.

On the other hand, the facility for following a workflow is an important tool. When a role finishes the work inside a workflow, i.e., when completing the interaction with a process inside the flow, he/she might want to trace the current status of the workflow for other work.

The status information includes the current side(s) or handling role, and when is the work to be completed, etc. The tool providing the facility might allow all the participants who have completed his work to own the function. For those who do not get their job inside the workflow, they do not even know the existence of such a workflow. Therefore, they do not own the function. In a workflow system of single workflow engine, the tool can be built associated with the engine directly by constructing a flow map which can be read by the participants who own the functionality only.

In an inter-organizational workflow, a participant might not own such a function described as above. For example, the role inside the process enacted through process service is better to be hidden from the information outside the organization. It is a better design for the function to be owned by the participants in the organization where the inter-organizational workflow is enacted. On the other hand, for the security and information hiding, the status replied by a workflow of the organization different from the original is limited according to the organizational policy. The function and status information is different from that is traced inside the workflow system of an organization. There are two rules summarized: 1) The participants have the above-mentioned tracing function on the intra-organizational process (workflow) inside their organization, and 2) An inter-organization process (workflow) only allows the participants who are in the original organization to have the power. Besides, the information returned from an organization is decided by its policy respectively.

Obviously, the tool for the status tracing in an inter-organizational process is different from the one inside an intra-organizational process. The design and implementation of the tool will be discussed later.

The cooperative mechanism between WfMSs in CA-PLAN is named as Remote Call Process (RCP) mechanism. RCP is a process-specific middleware that allows a process to enact an external process remotely as local process. RCP also provides management, control and monitor of execution of an inter-organizational process instance. RCP hides the underlying mechanism of enacting remote processes, transporting process arguments and it returns values across the WfMSs.

RCP uses two process elements, Remote Process (RP) and Process Service (PS) to implement inter-process interaction across different WfMSs. The intra-processes are registered to a RCP-Registry and generate the corresponding PS. Each PS acts as a proxy to

RCP uses two process elements, Remote Process (RP) and Process Service (PS) to implement inter-process interaction across different WfMSs. The intra-processes are registered to a RCP-Registry and generate the corresponding PS. Each PS acts as a proxy to