WIDE Workflow model and architecture - CiteSeerX

WIDE Workflow model and architecture F. Casati*, P. Grefen**, B. Pernici*, G. Pozzi*, G. Sánchez*** * Politecnico di Milano, Italy ** University of Twente, The Netherlands *** Sema Group sae, Spain

mailing address: Barbara Pernici Politecnico di Milano, piazza Leonardo da Vinci 32 I-20133 Milano MI, Italy e-mail: [email protected]

Abstract Workflow management is emerging as a challenging area for databases, stressing database technology beyond its current capabilities. Workflow management systems need to be more integrated with data management technology, in particular as it concerns the access to external databases and as a support technology for workflow management, to support intelligent exception handling and transaction management. Thus, a convergence between workflow management and databases is occurring. In order to make such convergence effective, however, it is required to improve and strengthen the specification of workflows at the conceptual level, by formalizing within a unique model their "internal behavior'' (e.g., interaction and cooperation between tasks), their relationship to the environment (e.g., assignment of work task to agents) and the access to external databases. 1

In the WIDE (Workflow on Intelligent and Distributed database Environment) project , a rich conceptual model is proposed, including an organizational model as a basis for task assignment proposed for the project, advanced functionalities for exception handling, the concepts of multitask and supertasks for workflow modularization, and integrated extended transactional semantics.

1

WIDE is an ESPRIT Project of the European Commission (Project N. 20280). Partners in WIDE are: Sema Group sae Spain, Politecnico di Milano, University of Twente, Hospital General de Manresa, ING Bank.

WIDE

1. Introduction Workflows are activities involving the coordinated execution of multiple tasks performed by different processing entities to achieve a common business goal. In business related workflows, a task defines some work to be done by a person, by a software system or by both of them. Specification of a workflow (WF) involves describing those aspects of its component tasks (and the processing entities that execute them) that are relevant to control and coordinate their execution, as well as the relations between the tasks themselves. Information in a WF mainly concerns when a certain work task (WT) has to start, the application information needed for performing the tasks, the criteria for assigning the WT to agents and which WTs are activated after its end; therefore, less emphasis is placed on the specification of the WT itself in business related workflows (which may be informally described and only partially automated) than in other process-oriented approaches (e.g., to support software processes), while the focus is on the WTs' coordination. Connections among WTs can be rather complex, and some of them may be execution dependent. A Workflow Management System (WFMS) permits both to specify WFs and to control their execution. During a WF execution, a WFMS has to schedule WTs (including their assignment to users) on the basis of the (static) WF specifications, of the (dynamic) sequence of events signaling the completion of WTs, of available data, and of generic events produced within the execution environment (including exceptions). In addition, important aspects of a WFMS are the ability to handle information needed to perform the tasks and to represent the organization structure in order to have information in the WFMS concerning the capability of performing the different WF tasks and activities. The first descriptions of WFs have been proposed within office modeling, as a way of describing office procedures [BP84]. Such descriptions were based on extensions of classical formal models (such as Petri Nets, production rules and flowcharts); a number of modeling support tools were proposed. The need of a closer relationship between modeling techniques and enactment of processes has been particularly developed within the process modeling area in software engineering. This research has produced several methodological contributions and WF specification languages [EN93, GHS95]. Several tools for process modeling, generally based on Petri Nets, are focused on the ability of "animating'' WFs, thereby understanding their dynamic behavior [BFG93]. In the literature [ASSR93, DHL90, EN93, FKB95, GHS95, H93, RS94, SR93] the proposed models present a limited expressive power concerning the possibility of specifying WT interactions and the mapping from the WF specification to WF execution, in particular concerning exception handling. Recently, a growing interest has concentrated on connecting WF systems to existing information systems. In particular, the desire of interconnecting to existing data and of coping with large volumes of WF information has provided impetus to the bridging of WF and database technologies. The challenge posed by WF management pushes towards removing some of the classical limitations of databases in the context of concurrency and transactional models [H93]. Novel features of databases, such as active rules, are seen as particularly promising in the context of WFs [DHL90, WC95, SSU95]. Another major problem in WFMS is the bias towards IT aspects of current WF specification models. A problem which needs to be considered in more detail is modeling organizational aspects in the WF schema and constraints associated to them, and to base on this information the assignment of tasks. 2

WIDE

The purpose of this paper is to present the WIDE approach to workflow management, with particular emphasis on its original features with respect to existing Workflow Management Systems. We are proposing a conceptual model and a language specifically focused on modeling WF interaction with external sources of information and on exception handling. In the WIDE (Workflow on Intelligent and Distributed database Environment) ESPRIT Project, started in November 1995, the goal is to provide a technologically advanced support to an existing workflow management system [FORO95a], based on active database support and advanced transaction management in a distributed environment. Such a support allows the definition of a semantically rich workflow model. One of the original aspects in WIDE modeling is the consideration of the issue of organizational modeling with respect to the WF schema modeling. Finally, particular attention is being paid to the WF modularization problem, to be able to specify WF schemas at different levels of detail, and to change versions of WF schema (or parts of schemas). The initial inputs for the model proposed for the WIDE project are the work on workflow management systems at Sema [FORO95a, FORO95b, FORO95c] and on workflow conceptual modeling at Politecnico di Milano [CCPP95a, CCPP95b, CCPP96]. The ongoing effort by the Workflow Management Coalition [WFMC95] has also been taken into account in the definition of the WIDE model. User partners in the project provided a set of requirements and suggestions for their specific application domains (hospital, banking, and insurance) and, finally, on the model in general. The outline of the paper is as follows. Section 2 introduces the WIDE approach to workflow management. Section 3 presents the organizational model at the basis of workflow management. Section 4 deals with the workflow process specification. Section 5 presents the exception specification in the workflow description language. Section 6 discusses the architecture of the WIDE environment. In Section 7, some examples are illustrated and in Section 8 related work is discussed.

2.

The WIDE approach

The main goals of the WIDE Project are the following: • to define an advanced conceptual model for describing both the flow of activities and the organizational environment in which these activities are performed; a particular emphasis has been put on specifying exceptions in the normal flow of activities, and to support different types of exceptions and abnormal situations; • to provide an advanced technological support to workflow management through advanced database systems including active database technology and advanced transaction management in a distributed environment with long running transactions. Workflow conceptual modeling Concerning modeling, an important design decision in WIDE is the strict separation between the description of the organization and workflow process specification. In fact, several different workflow schemas are usually defined in an organization on the basis of a common 3

WIDE

organization structure. We define workflow schema (the generic term “process” is used in [WFMC95]) as a coordinated set of Work Tasks (or activities) which are connected in order to achieve a common goal according to a predefined sequence of execution. Each workflow schema can be instantiated in several instances of the workflow schema, called cases in the following. One of the problems to be solved in a WFMS is how to assign work tasks to be executed to members of the organization (or to software processes if the tasks are performed automatically), in a possibly changing organizational environment, and taking also into account the complex structure of the organization and not only individual users performing the work tasks. The approach taken in WIDE is to separate the specification of the organization model and the specification of the process model (Fig. 1). The mapping between the elements of the two models allow the specification of which agents may perform given roles.

TASK/ SUPERTASK 1:n

perf_stat 1:m

Role process model

0:n

authorized

push/pull decision

0:m

Agent

organization model

Figure 1 - WIDE models

In the organizational model, the organization is defined in terms of different types of agents, including individuals, specifying the (possibly complex) structure of the organization, as illustrated in next section.

4

WIDE

In the process model, the elements of the workflow schema are defined. In particular, Figure 1 shows that elements to be defined in the process model are concerning task assignment and their relationship with the organization structure: work tasks and roles. Work tasks are defined as tasks and supertasks in the WIDE model as described in the following of the paper; each task can be associated to one or more roles. The complete process model adopted in WIDE, including coordination aspects between work tasks, is described in Section 4. The authorized relationship permits to associate agents modeled in the organization to one or more roles modeled in the process. The two models and the corresponding authorizations are defined at different times. In addition, it is assumed both that the structure of the organization can be changed at any moment, and that new workflow schemas can be defined and the existing ones modified, and that the authorization to agents to perform a given role may vary over time, and can be dynamically changed during workflow execution. Such an issue is orthogonal both to process modeling and to organizational modeling, as shown in Figure 1. In fact, the relevant aspect is the mapping between the two models, rather than being hardwired to the model of the process, or, in alternative, to the model of the organization.

WIDE architecture Concerning the architecture of the Workflow Management System, WIDE provides a distributed environment, based on an active DBMS to support workflow enactment, as shown in Figure 2.

WIDE client

WIDE client

WIDE server

Object mapper

Access to other WIDE WF servers and external DBs

DBMS

Figure 2 - WIDE architecture WIDE is based on a client-server architecture. Clients are activated by the agents working with the system. Several servers are defined for the distributed workflow management system, and interact sending messages to each other, requesting services and activating tasks remotely, and accessing external databases. The DBMS shown in the figure is an active

5

WIDE

database supporting specifically the WIDE server functionalities (e.g., workflow schema specifications defined in the server, the organization model, task activation information, and so on). The WIDE architecture and its functional modules are discussed in Section 6 of the paper.

3.

Organization model

As mentioned in the previous section, one of the characterizing aspects of WIDE is the separation of concerns between modeling the organization and modeling the workflow processes within a given organization. From the organizational perspective, the following aspects have to be considered: • the structure of the organization; • the identification of an agent using the workflow management system; • the authorization for a given agent to perform a given task, from the workflow perspective. These perspectives are illustrated on the basis of the concepts defined in the meta-schema in Figure 3, which shows details of the WIDE organizational model already sketched in Figure 1, with some examples of domain specific organizational entities (in dashed lines).

3.1. Organization structure The more generic concept in the organization model is the agent concept. An agent is a processing entity that can perform tasks in a workflow process execution. In the organization model, the following entity types are defined as disjoint subtypes of the Agent entity: Actor. An actor is an individual processing entity that may be of human or automated (mechanical or electronic) nature. The availability of an actor can also be specified (in terms of calendar, holidays, free time, and illnesses in case of human actors; in terms of down time, for instance for maintenance, in case of automated actors). Group. A group is a specification of a set of actors based on common organizational characteristics, e.g., agents working in a specific project or in a particular geographical location, or an organizational unit. Organization function. An organization function corresponds to the definition of a function in the organization. A function may be performed by a group (or a number of groups) or by individual actors. A skill attribute is associated to the function entity. Specialization may be used to further specialize agents in subentities of organizational functions or of groups in a particular organization. For instance, two examples of specialization are shown in the figure to exemplify domain specific class definitions (with dashed lines): the generic Organizational Function is specialized into “risk mgmt unit

6

WIDE

responsible” (indicated in the figure), secretary, staff (further specialized into junior and senior staff), not shown in the figure, and Group is specialized into “risk mgmt unit”.

name

TASK/ SUPERTASK

agent const. state

perf-stat is_a access rights

ROLE

authorized

name

AGENT

ass. rule

process model

push/pull decision

domain

organization model

sec. level

workdesk d U

skills

U

U authoriz.

ORG. FUNCTION has-fun risk mgmt unit resp.

assignedto

GROUP

part-of

ACTOR

part-of

risk mgmt unit

supervis.

avail.

Figure 3 - EER diagram of task assignment data model The elements corresponding to the actual organizational structure in a specific organization are specified during the organization design. All specific functions, groups, and actors are specified. In addition, instances of each element must also be defined, to associate functions to individuals or groups, and to populate groups. Such assignments may vary during the lifetime of the workflow management system, and imply the need of defining adequate policies to handle such changes from the point of view of the correct behavior of the WFMS. 7

WIDE

The proposed model allows the specification of organizations according to different organizational models [M87], such as matrix organizations, product hierarchies, functional hierarchies, or centralized and decentralized market hierarchies. The structure of the organization is specified in terms of actors, groups, and organization functions. A number of individual actors, the existing groups, and the necessary organization functions will be created when the organization schema for a specific organization is created. The composition of groups and the assignment of functions to actors or groups will also be specified. The relationships has-function and assigned-to link a group or an actor to a function. The relationship part-of links an actor to a group the actor belongs to or a subgroup to the group the subgroup is part of. The relationship supervises links an actor to the actors supervised by this actor.

3.2. Agent identification in the system As discussed before, a workflow system is usually of a distributed nature as it routes work between users working at different places or sites. Often, it necessary to explicitly specify the site where work has to be executed, e.g. because identical agents (functions) exist at multiple sites or a group of agents is distributed across multiple sites. To clearly identify agents in a distributed system, we adopt the common convention to partition the organization served by the WFMS into domains (corresponding to identifiers of workflow servers in the network, hierarchically organized), each one including a number of individual users. A domain is one area served by a WFMS, including users connected to it. A dot notation is used to indicate hierarchically structured domains (e.g. domain1.subdomain12, indicating subdomain 12 inside domain 1). The WFMS is able to identify the domain it is serving. Each agent is assigned a name (defined and uniquely identified within a given domain). Therefore, as shown in Figure 3, each agent instance in the system (be it an individual actor, a group, or a function) is identified by a domain-name pair in the WFMS. In addition, to enforce security mechanisms, a specific workdesk may be associated to each agent, if needed, and a security level inside the organization.

3.3. Authorization mechanisms From the perspective of the authorization mechanisms for task execution, we define the concepts of task/supertask and role. A task is an atomic unit of work in a workflow process model. A supertask is defined as a set of related tasks that can be considered one unit of work at a higher level of abstraction and be assigned to one responsible agent. Tasks in the WF have to be performed by authorized agents. There is the necessity of specifying which agents are allowed to perform given tasks, to associate access rights to them, and to identify which tasks are actually performed, or for which there is a commitment to perform.

8

WIDE

We adopt the concept of role for specifying the ability for an agent to perform a given task [P90]. A role is a description of the processing entities that can and are allowed to perform a specific task. Roles are defined separately from agents and from the organizational structure. In fact, the definition of roles is performed during process design, i.e., when specifying the characteristics of a given workflow schema. The definition of a role may be common to several tasks, defined in the same workflow or in different workflows, and therefore with different actions and access rights to information, depending on the specific task to be performed. Using roles for specifying the assignment of work in the process is valuable in two ways: • independence between individuals and definition of the process; • to provide a way to balance distribution of work. The mapping between roles and specific agent entities is performed when the authorization information is defined, i.e., the set of roles that may be performed by each agent (at the function, group or individual level). It must be noted that in some process and organization definitions the same name could be associated both to a role and to an organizational function. We still retain the separation between the two concepts, which will be linked by an authorization relationship where appropriate. An important point in this issue is the commitment for each user defined in a given agent entity type to perform all the tasks associated to the roles he/she actually assumes. There is a separation of concern between the ability of performing a given task and the commitment to do it. A set of constraints can be associated to roles performing given tasks, in particular concerning access and manipulation of information related to an agent. The relationship performs-statically links a task to be performed to a role describing the processing entities that may perform the task. The cardinality of the relationship is M:N. The relationship is populated during the workflow process design. The model allows the specification of which agents are authorized to perform a given through the authorized relationship between agents and roles. The relationship authorized links a role describing the processing entities that may perform a task to the type of agent that may actually perform the task. The relationship is populated at workflow design time (usually after organizational design has been performed). For instance, a Program Committee (PC) member (defined as a function in the organizational model for a conference organization system) can have the following roles during the conference organization processes: reviewer, or discussant, while the function Chairman will be authorized to act as reviewer, but will probably not be associated with the discussant role.A PC member is always assumed and authorized to review papers, while he/she may or not be a discussant (although he is authorized to do so; in addition, a PC member is assigned to review a given paper as an instantiation of the reviewer role, as opposed to the generic capability of performing paper reviewing associated to the role definition; as a consequence, if a PC member is assigned the role to discuss a given paper in a specific case, he/she

9

WIDE

commits to perform certain tasks (e.g., write a short report on that specific paper). We can assume that a user defined as a PC member is not allowed to review his own papers submitted to the conference. But, as a member of the PC, he may be allowed to see the anonymous results of the evaluation of the paper (even those which are normally restricted to PC members but not shown to the authors of papers). As another example, we may define the following roles corresponding to risk management processes in the organization: Responsible of risk mgmt unit, secretary, risk mgmt unit member. The role of risk mgmt unit member can be played by any agent part of senior staff group or by an individual actor with name=“Smith”. WF set up functionalities allow the definition of the organization model specific to a given organization. For instance, entity types related to risk management, such as shown in dashed lines in Fig. 3, as well as individual actors. Actual assignment of tasks (instances) to agent (instances) are performed at WF execution time, i.e., during case execution. Such assignment (assign operation) can be either automatic, manual, or computer supported, and is performed according to the defined process and organizational models, including constraints as defined in Section 5. A possible assignment operation is also the delegation of a task by an agent to another agent. A task assignment rule may be dynamically evaluated on the basis of this information before task execution if task assignment to agents is automatic.

3.4. Agent definition in the WFMS With respect to WF execution, we identify the following specific agents: • Case executor: the agent who starts the case. In general, WF schemas have a list of allowed agents enabled to start cases of that WF. • Case responsible: the agent that has the final responsibility over the case. By default, it is set to the user who starts the case, but can also be modified after the initiation of the case. • Task executor: the agent who is performing (or has performed) a task. Some of these agents are specially useful for reporting problems or for the management of exceptional situations. With respect to WF specification, we identify the following specific agents: • WF designer: the designer of the specification of workflow processes, in terms of workflow schemas; designers may also modify existing schemas; • Workflow administrator: the agent(s) in charge of administrating a workflow domain; the workflow administrator defines also the structure of the specific organization and the actors working with the WFMS, defining corresponding users of the system.

10

WIDE

3.5. Task assignment to agents If the agent associated to a task includes more than an individual, in a subsequent phase the task has to be linked to a specific user identified in the WFMS for execution. This assignment may either be performed by a scheduler, where the scheduler engine of the WFMS assigns the task to the best individual actor of that set according to the policy of work assignment (automatic assignment), or chosen directly for execution by a user (manual assignment, which may be computer assisted to identify priorities and critical cases). The necessity of both ways of linking a task to a user emerges in all situations in which the task is assigned to a group of agents (or to a specific domain-dependent agent entity type), but there is no need to schedule in advance who is actually going to perform the task. To handle this type of situations, in WIDE we propose the Push/Pull model for task assignment described in the following. The differences between the two modalities are in the passiveness or activeness of the users with respect to capability of selecting the task to perform. The push/pull modality is associated to the authorization relationship. The default modality is that a task is assigned to an individual actor, therefore following the “Push” model, while it is also possible to assign a task to a function or to a group of users (“Pull model”). The PUSH model Following this model, the users behave passively with respect to assignment of tasks. Each user has his own representation into the system, together with the list of tasks he has to perform. When the system decides a new task should be performed by a concrete agent, the workflow engine pushes that task into that user desk. The workflow engine might also provide different scheduling policies, possibly active at the same time, in a concrete workflow implementation. The PULL model Following this model, the users behave actively with respect to assignment of tasks. The system has a desk for some roles, shared by different agents, where the workflow engine inserts the tasks to be performed. Once the user is connected to the system, he browses this shared desk, and pulls the desired task. Different queuing model can be applied in order to regulate task pulling (e.g., FIFO, priority queues, random access). The workflow engine takes care of concurrent access to the shared desk, and of those tasks in the desk that are never pulled. The type of modality to be adopted is associated to the authorization of an agent to play a given role.

4.

Workflow process model

The process definition in WIDE has specific characteristics which are motivated from the office information system perspective which is taken in the WIDE environment. Users of the WIDE WFMS are interested in performing their work mainly by manual activities, with the possibility of invoking specific applications to support such work, and exchanging documents and sharing data, possibly stored in databases which are used also by other systems and 11

WIDE

applications, not only for workflow management. The main aspect needed to support this type of work is the ability of coordinating the flow of execution of tasks according to a general workflow schema defined for a given office procedure. A particular attention in WIDE is paid to the problem of managing exceptional situations during workflow execution. While details of exception specifications are presented separately in Section 5, in the present section we illustrate how exceptions are inserted in a workflow specification. A special attention in wide is also paid to transactional aspects to ensure the correct semantics of workflow enactment. A detailed discussion of these aspects is however outside the scope of the present paper. In the present section, we present the characteristic aspects of the WIDE process model. First, in Section 4.1, we describe how information is shared in workflows and with other applications and the types of data which are needed for workflow management. In Section 4.2, we discuss task definition and in Section 4.3 sequencing of tasks in the workflow; in Section 4.4, we illustrate two constructs defined in WIDE to support abstractions: supertasks and multitasks. Finally, in Section 4.5 we illustrate the structure of the Workflow Definition Language (WFDL).

4.1. Information model The information model identifies and describes the documentation elements involved in a process. The following paragraphs define the types of information in workflows. In Section 4.1.1, general information is discussed, in Section 4.1.2, issues related to modeling temporal data are presented. 4.1.1 General information Information used in workflows can either be defined at the workflow schema level, or be based on shared databases, or consist of documents exchanged through the WFMS. Schema variables Variables defined at the schema level are visible only to the case using them. Other cases, even if they are instances of the same schema, cannot access those variables: each case has its own copy of variables. In addition to schema variables specified at design time, there is a number of predefined variables associated to every case and to every task (e.g., the case initiator, the task responsible, the starting date of the task, and the like). These variables are illustrated in the following of the section, where the process definition constructs are discussed.

Shared DB The schema declaration may also include the definition of persistent data (DB) which are shared by all WF agents and possibly by agents of other WFs. These data can be externally defined (i.e., in this case their existence is independent of the particular WF application being modeled). In our approach, data manipulation and retrieval is one way of exchanging structured data with other WFs and between tasks, thus following a blackboard approach.

12

WIDE

Other external databases which are independently accessed by agents during the execution of their WTs do not need to be explicitly defined. Data exchange via documentation elements: definition and types A documentation element is any set of information explicitly used, created or modified by a user to complete a task. The types of documentation elements defined are the following: • Document: any set of information whose contents is not interpreted by the WIDE WFMS. Documents are created and modified by means of external tools. Examples: a textual document, a picture, an image of a scanned paper document, etc. • Form: a set of data fields whose contents can be interpreted by the WIDE WFMS. Forms are filled out using the WIDE Form Editor or any other tool able to handle WIDE forms. Data entered in a form are stored within the form and can be interpreted by the WIDE WFMS. In addition, data in a form can also be associated with attributes of shared databases. A variable of the process can be used by the form (e.g. to display it, to perform a calculation, to determine whether to show a field in the form, etc.). • Compound Document: a set consisting of any fixed combination of documents, forms and other compound documents. Once a compound document is open, its contained documents and forms can be accessed as if they existed by themselves. Likewise, its contained compound documents can be opened to access their contents. Compound documents are useful when we want to logically group a set of documentation elements that always go together as input or output of a task. • Dossier: a set consisting of any variable combination of documents, forms, compound documents and other dossiers. The contents of a dossier may vary over time, as the process' flow unwinds. A dossier can be defined to be empty or to have an initial contents. A dossier is also knows as folder. Dossiers are useful when we want to logically group a set of documentation elements of which some are optional as input of a task. A dossier can be passed from task to task, each task taking out what it needs and putting in what it produces. 4.1.2 Modeling temporal information The definition of temporal information is of great importance in an evolving system. The following concepts related to the management of temporal information are defined: • temporal instant: it is a time point which can be expressed at different levels of granularity: year, month, day, hour, minute, seconds. For workflow applications, we assume that granularity at the second level may suffice as the finest granularity. • temporal intervals: an interval is the set of temporal instants included inside two boundaries. Boundaries are, in turn, temporal instants. The lower boundary is called starting instant; the upper boundary is called ending instant. • duration: a duration is the time elapsed between the starting point and the ending point of the considered temporal elements (e.g., a task, or a case, or a wait condition).

13

WIDE

Temporal instants and temporal intervals related to the same temporal element can be specified at different levels of granularity, thus allowing the definition of a task to be started at a given date, e.g., on November 1992 (month granularity) and to last for 3 days. Temporal information for workflows can be used for different purposes: typical usage aims at monitoring if a certain time instant has been reached, or if a certain time interval elapsed from another time instant. Temporal conditions can be expressed by using temporal information. The most important uses of temporal conditions can be: • instant condition: e.g. at 2:34pm, November 12th 1996 a certain action must be started. This condition is expressed as: @hour, minute, second, month, day, year. As an example, consider the organization of a conference where papers can be submitted by e-mail and the deadline for receipt is 17:00:00, April 1st 1996. After the deadline expired, paper selection has to start immediately to avoid to miss the notification deadline. The Analyze_Received_Paper task starts as soon as the current time is 17:00:00, April 1 1996. • interval condition: to test if a certain amount of time elapsed from another event: e.g., after the start of a task, the end of that task has not been reached yet and the task seems to have been running for too long. This condition is expressed as: elapsed(year, month, day, hour, minute, second) since begin(task). As an example, consider a patient who entered a waiting list for a visit at the hospital: if after 10 days he/she entered the waiting list he/she is still waiting for a final appointment, an exception must be risen because the patient has been waiting for too long. This can be achieved by the condition elapsed(0, 0, 10, 0, 0, 0) since begin(Stay_in_Waiting_List) which gets a TRUE value if the time interval elapsed from the beginning of the task Stay_in_Waiting_List is greater that 10 days and the task is still running: as a reaction to this exception, a message can be sent to the responsible informing that a patient has been in the waiting list for more than the allowed period. • periodic (iterative or cyclic) time condition: to test if some periodical time definitions are satisfied by current time. This condition is expressed using the Leban notation: e.g., to specify the first Monday of the month, we write 1/Mondays:during:Months. [LebanXXX]. As an example, consider a computer science department where every Sunday a general back-up procedure must be started. The condition can be expressed specifying Sundays as the first day of the week: 1/Days:during:Weeks. If we want the task to be scheduled at 0:00:00, the condition must be completed by the following: 1/Days:during:Weeks@0:00:00. Examples of typical uses of temporal conditions are exception management: if a certain time is reached (either because that instant has been reached or because an interval elapsed or because of periodic time) an exception is risen; at the schema definition level, one may wish the case to be completed within a certain time interval: if after that time interval the case is not over yet, an exception is risen and the case responsible is notified; at task definition level, exceptions similar to those for the schema level can be specified. They remain valid only as long as the task is not completed. Time-outs can also be specified, to test if a task has been waiting for more than a certain time (e.g. for a precondition to become true). Wait conditions can be used to specify a time which must be awaited for before the case execution can proceed. 14

WIDE

4.2. Tasks Tasks are the elementary work units that collectively achieve the workflow goal. The workflow engine takes care of determining when a certain task must start being executed, and of assigning it to agents, according to the policies for task assignment discussed in Section 3. The workflow engine is also in charge of providing to the agent the full set of documents needed to achieve the goal of the task, as it is stated in the description of the task. 4.2.1 Structure of a task Each task has the following major characteristics: • Name: a mandatory string identifying the task. • Description: few lines, in natural language, describing the task. This description is used by the agent in order to know the goals of the task. • Version: the version number associated to the task definition. • Actions: an action can either be manual (a textual description is given in this case) or a sequence of statements in WFDL which define how both temporary and persistent WF data are manipulated by the WT. Note that the specification of actions in the WT is concerned with a fraction of the WT's semantics; in general, the user executing the WT has full freedom on the way the WT itself should be executed, provided that eventually the actions which are listed in its action part are performed. Therefore, the action specification is somehow equivalent to giving the WTs' postcondition. If the keyword AUTO is specified in the task declaration, then the actions are to be automatically executed by an automatic processor, otherwise they will be carried out by the human agent. • Roles: list of roles which may perform the task, and a set of constraints concerning task assignment to agents. The following types of constraints have been identified: - constraint based on variables IF var1 > 100 then agent in senior staff - constraints on where task is executed agent.workdesk=“D1” agent.domain=“dom2” - constraints related to authorization in task-specific cases loan.person.name agent.name (a loan case cannot have the person applying for the loan between its processors, even if the person normally performs loan authorization as his job) - constraints related to dynamics of task execution based on functions on the history of the case, such as, for instance, 15

WIDE

agent PreviousTask.agent An option is to define also a substitute agent for the task. • Task information (documents, forms, dossiers, accessed databases): classified as input and output to be used/produced when achieving the task. - input information: any number of documentation elements of any type can be specified as the input of a task. Each of the input documentation elements may be assigned a condition. In this case, the task takes the document element in question as input iif the condition holds true at the time that task gets ready for execution. - output information: any number of documentation elements of any type can be specified as the output of a task. Each of the output documentation elements may be assigned a condition. In this case, the task takes the document element in question as output iff the condition holds true at the time the task gets ready for execution. Each of the output documentation elements is marked as mandatory or optional. This attribute is meaningful only if the condition associated with that documentation element was evaluated to true when the task started execution. In this case, the attribute 'mandatory' means that the document element needs to be completed before the task can be finished. Any document element can be specified both as an input and as an output of a given task. • Exceptions: in every task one or more sets of pairs can be specified to handle abnormal events that may happen during the execution of a task and need to be managed properly. A condition is a predicate, which may include time-related and query predicates on available information. • Authorized actions: it is possible to restrict the actions that may be applied to a task (from the global set of actions defined in next paragraph: reject, cancel, ...). See next section for a complete description of possible actions over a task. • Compensation action: it is possible to specify a compensation action for recovery of task during transaction management if a failure occurs. 4.2.2 Task execution The execution of a task is initiated by the workflow engine. After this point, the execution is controlled by the agent in charge of executing the task, or in case of task rejection, is controlled by a combination of the workflow engine and the different agents that are executing the task. Under this assumption, a task is created once and disappears only when it is finally completed or canceled. In some cases, the participation of different agents is needed, which is registered in the history log of the task. Tasks are atomic units of work, i.e., their effects have an all-or-nothing character with respect to resources under control of the workflow management system, depending on success or failure of task execution. Failed task executions are automatically undone by the workflow management system. The state model shown in Fig. 4 reflects the execution of the task in the whole workflow environment, incorporating the workflow engine as well as the context of the agent

16

WIDE

performing the task. A task is started when the analysis of the flow determines it is ready for execution (entering Waiting state). Then the task is assigned by the workflow engine to a given agent, going to the Running state. It is assigned to an individual user if a PUSH model is adopted, while it remains in a list of pending tasks if a PULL model is chosen for the assignment of the task. All possible operations on a task are: Delay (Postpone), Select, Reject, Cancel, and Complete. The task remains Running until the user decides to complete or to cancel it. In this case the task enters a final state. If the task is postponed (delayed), it enters the Delayed state from which its execution is resumed with the select operation. When the user decides to execute an action on the task, the task is considered modified. In case of rejection, the workflow engine resumes its execution trying to assign the same task to a new suitable agent. In case of completing or canceling, the workflow engine resumes its execution taking as input these events. The next step will be to find the next task to execute, if any. Several instances of the same task can be activated (and can coexist at the same time) during a single case enactment; different instances are characterized by a different activation number. delay Delayed select

modify

complete

Completed

cancel

Canceled

Waiting select Running pull assign Rejected

reject cancel cancel

Figure 4 - Task execution state diagram

4.3. Sequencing of tasks: connectors in a WF Connections describe interactions among tasks, i.e., the process flow; in WIDE, the goal is to provide advanced features for definition of semantically rich connections between tasks. We relate the presentation of the WIDE model to connectors available in the WFMC glossary definitions, concentrating on differences and advanced features in the presentation. All graphical symbols are shown in Fig. 5, and they are connected through arrows (an example of schema definition is shown in Fig. 9). Connectors may be connected to tasks or to other connectors, for a greater flexibility in specifying workflow schemas.

17

WIDE

k

























































Fig. 5.a - wait connector, start-stop symbol, total fork/total join, conditional fork, conditional fork with mutual exclusion, partial join, cycle

j

k Fig. 5.b - task, supertask, multitask

Figure 5 - Graphical symbols for WF definition 4.3.1 Start and Stop Symbols Start and stop symbols enable the creation and completion of WF instances (cases). Each WF schema has one start symbol and several stop symbols; the start symbol has one successor symbol and each stop symbol has one predecessor symbol. After the WF case creation, the successor of the start symbol is started; when any stop symbol becomes ready, the WF case is completed. Tasks which are still active are canceled, and their executors are notified. No other task of that case will be activated. Actions and labels can be associated to each stop symbol: the meaning is that as a stop symbol is reached, case execution ends and the corresponding action is performed (e.g., starting a new case). 4.3.2 Split With respect to WFMC definitions, we distinguish splits (called forks in the model), into the following types: • Total (also called AND-split or "All after this"): after the predecessor ends, all successors are ready for execution. • Conditional (also called OR-split, or "The true ones after this"): each successor is associated with a condition; after the predecessor ends, conditions are instantaneously evaluated and only successor tasks with a true condition are ready for execution. • Conditional with mutual exclusion: only one condition can be true; thus, after the predecessor ends, if no condition or more than one conditions are true, an exception is risen; otherwise, one of the successors is ready for execution. 18

WIDE

4.3.3 Join With respect to AND- and OR-joins in WFMC definitions, we allow the association of conditions to joins. They are classified as: • Total (also called AND-join or "All before this"): the successor becomes ready only after the end of all predecessors. • Partial (also called k-AND-join, or "Some k before this"): the join is associated with a value k; the successor becomes ready after the end of k predecessor tasks with the same activation number. For instance, in a paper refereeing process, if 4 reviews are requested and only 3 arrive, it may be considered acceptable to proceed with paper evaluation after an appropriate waiting time for all the reviews has elapsed, not to delay the selection. Values k may also be a number or be associated with constants, variables, or functions expressed in WFDL; in the last two cases, their value becomes known at execution time. • Cycle (also called OR-join): the successor becomes ready every time a predecessor task ends. 4.3.4 Wait connectors A wait connector inserted in a sequence has a condition associated with it. Conditions can be based on available application data and documents, on time, on the occurrence of an event, and so on. Execution of the process is resumed in that execution branch when the condition is true. We assume that the condition variables are available (and may be tested) after the wait connector satisfaction (e.g., to be used in following conditions in fork connectors).

4.4. Modularization of workflows In Fig. 5.b, the symbols for different types of tasks are shown. In addition to the basic task definition, two constructs are introduced for simplicity of WF specification, and to allow a more abstract specification of parts of the WF. The supertask (ST) construct allows the definition of a WF module, within a given WF schema, with a single starting point and one end point. This concept is similar to the concept of subprocess in WFMC definitions. The multitask (MT) construct allows the specification of the characteristics of similar tasks/supertasks to be executed in parallel. 4.4.1 Supertasks Supertasks have features of both workflows and tasks. Like WFs, they are internally decomposed into tasks (and possibly other STs); each ST has one start symbol and several stop symbols. Like tasks, STs have name, version, description, information, exceptions, roles, compensation actions. Supertasks can be in turn hierarchically decomposed into supertasks. The action part is not defined for supertasks, as the job the ST performs is in effect decomposed into smaller jobs performed by the component tasks. STs have variables 19

WIDE

definitions, whose scope is restricted to the component tasks, and input and output data definitions. Modularization of workflows is also dependent on the required transactional semantics of the execution of the workflows. Tasks that are grouped into a supertask may form a unit of execution from a transactional point of view, i.e. they have an implicit notion of atomicity and a relaxed notion of isolation within the boundaries of the supertask. A supertask may either be defined as an atomic unit of work or as a non-atomic ST. Failed supertasks executions are automatically undone by the WFMS. Intermediate results of supertask execution are visible to all tasks in the supertask, but not outside the supertask. Each atomic supertask is associated with an explicitly defined compensating supertask action that can be used to undo the effects of the supertask at workflow level after it has been successfully completed. 4.4.2 Multitasks In many WFs it is necessary to define a set of WTs (or STs) that perform exactly the same job in parallel, with some parameter that may vary between the different instances. In order to do so, the concept of multitask (MT) is introduced in the model. Like tasks, MTs have name, description, actions (or a ST description), and exceptions. Exceptions for MTs can be divided into two categories: task/ST exceptions and final exceptions. Task/ST exceptions are replicated into every composing task: these exceptions can use variables local to the entire MT or to any composing task. Final exceptions are tested only at the end of the MT, no matter if one or more instances of the composing task(s) is still running. These exceptions are generally used to manage failures from composing tasks or to notify the responsible about tasks still running. The need of the concept of multitask (MT) comes from two different aspects. The first one is the need of factorization, that is, to find out common aspects between a set of tasks to perform. Once these common factors have been discovered, a multitask can be defined using them as the varying parameters. The second one is the dynamic aspects that appear when it is not possible to compute in advance the number of tasks to be executed in parallel. For instance, the paper reviewing process inside a conference organization depends on the number of received papers, and a multitask can be defined, with the task Single_Paper_Review instantiated for each of the submitted papers in parallel. A multitask is seen from two different points of view. When modelling, a multitask is seen as a unique task (Fig. 6.a), with a set of input and/or output information, to be performed by some agent(s). When executing, a multitask is split into different instances that are executed independently of the rest of tasks belonging to the multitask, as represented in Fig. 6.b. Each multitask has an input parameter (indicated as j in the figure) indicating the number of work task instances that become ready when the MT's predecessor (called A in Figure 6) ends. It is also possible to specify when a multitask must be considered finished, by associating to it a threshold value or expression, called quorum (denoted as k in Figure 6). When the number of task instances which have ended reaches the quorum, the MT is also ended, and the MT's successor (C) becomes ready. The definition of the quorum is similar to the case of partial joins: it may be a fixed number or depend on available WF information.

20

WIDE

A

A

j j B

B.1

B.2

.....

B.j

k k

C

a) MT definition

C

b) MT execution

Figure 6 - Multitask 4.4.3 Termination of tasks A case can finish if all tasks belonging to the case are finished. This applies only to the tasks that have been active in any moment during the life of the case. Those tasks that have never been activated do not participate into the termination condition of the case. Let us see two different examples. 1. If the case has an OR-join connector, two tasks may be active at the same time (those tasks that are inputs to the operator). In order to continue the execution of the case, one of the tasks has to finish. However, before the case finished, the rest of the tasks in the OR-join have to finish as well. Note that both cancellation and completion are final states for tasks. 2. If the case has a multitask, the situation is similar. Once the multitask has been started, in order to continue the execution of the case, the quorum must be reached. As soon as the quorum is reached, all the instances in the multitask which are still active have to be managed properly: this can be achieved by the exceptions of the MT. As above, both cancellation and completion are final states for tasks. This approach leads a new issue concerning termination. The flow can be in a final state, but, since there are tasks still running (in multitasks or in OR-join connectors), the case cannot finish. This could imply some delays in having the case as a finished one. We propose two different alternatives: • using the exception support, some alarms can be fired as soon as the case is over to raise exceptions that terminate/cancel those tasks that are still alive. 21

WIDE

• the WF manager is pro-active in the sense that is able to notify to the corresponding users they have tasks that do not need to be terminated. A mixed usage of these two solutions is also possible, to assure termination is always possible even if the design does not include the needed alarms to implement the correct termination of the case.

4.5. Workflow Description Language In this section we describe the main features of the WIDE workflow description language (WFDL). The WIDE WFDL allows the definition of workflow schemas. The WFMS allows the instantiation of these schemas (WF cases) and supports their execution with the workflow engine. A schema description consists of two parts: 1. A declaration section, where WF information items (variables, shared databases, WF documents, dossiers) and tasks are defined. 2. The definition of the flow structure, where the WF schema is defined. A flow, that has a starting point and one or more end points, is built using tasks and connectors, as illustrated in the previous sections (a textual definition language is also defined, but its presentation is outside the scope of the present paper; an example is presented in the appendix). 4.5.1 Declaration section The declaration section contains definitions of some items that are used throughout the specification of the workflow. A conceptual modeling of WF schemas features the following major topics: • Name: a mandatory string identifying the workflow. • Description: a brief description - generally a few lines - describing in a natural-language sentence the goal of the WF. • Administrator: the agent who designed the schema. • Version: the current release of the schema. This feature is useful if schema changes are allowed. • Exceptions: in every workflow it is possible to specify one or more sets of pairs to handle abnormal situations at the WF level: an abnormal situation can happen at any time and must be managed properly. Every time an exception is raised, the corresponding reaction is performed. • Variables, types and functions: variables store information that can be referenced by any task of that schema. Variables can be used to share information among tasks of a case. Some variables can be defined as fixed, meaning that their value cannot be modified once they are initialized. Types and functions are defined inside the WF schema to specify WF-

22

WIDE

dependent data types and WF-specific functions (e.g., associated to conditions of joins, multitasks, or wait connectors). Functions are defined on the basis of available data in variables or in shared DBs. For instance, a function AlarmWaterLevel(WaterDB,10,Lombardy) shows the use of a function that retrieves data from a database named WaterDB, and returns true if there are at least 10 different locations in which the current water level in the Region called Lombardy is out of range. • Responsible agent: it is possible to define the list of roles that are allowed to start a case. • Start-case condition: define the conditions under which the case can be automatically started by the WFMS. For instance, it can be the arrival of an e-mail message of a given type, or of a document of a given type, or a manual start (the default), or a periodic temporal condition (e.g., at the end of each month). The designer can also specify the different document items (documents, forms, ...) used in the WF. The schema declaration may also include the definition of persistent data (DB) which are shared by all WF agents and possibly by agents of other WFs. These data can normally be externally defined (i.e., their existence can be independent of the particular WF application being modeled); for simplicity, we use the relational data model to denote persistent data.

5.

Exceptions in workflows

Exceptions are situations out of the normal flow of control of the workflow, in which asynchronous actions are fired to handle the anomalous situation. Several types of exceptions are managed within the WIDE environment. Some exception are linked to an abnormal situation during the execution of the workflow according to the defined workflow schemas; other exceptions may be linked to changes to the organization model. Accordingly, exceptions in WIDE are classified as follows: •

alarms: planned exceptional situations defined in the workflow schema, not part of the normal flow of execution of the process; this type of exceptions takes into account the occurrence of application dependent events, such as the arrival of a particular message or a time-out;

•

workflow execution exceptions: such exceptions occur when the agents working with the workflow do not follow the sequence of execution of tasks defined in workflow schemas; exceptions of this type are always predefined in the WFMS, but their treatment can be customized by WF schema designers;

•

organization exceptions: such exceptions arise when a change in the organization affecting workflow execution occurs (e.g., an actor leaves the organization; all the tasks assigned to the actor must be reassigned); also this type of exceptions is usually predefined in the WFMS, but they can be customized by WF schema designers.

Exceptions can appear in three different levels:

23

WIDE

• at the task level. • at the supertask level • at the workflow level. Exceptions at the task level are active (i.e., its condition is monitored and, as it become true, the reaction is executed) when the task is active.Similarly, exceptions at the supertask (workflow) level are active when the supertask instance(workflow instance) is in execution. More than one exception can be declared for each level.

5.1 Specification of exceptions The way of specifying the different types of exceptions (or the customization of a given exception) follows a common structure. They are made of a condition-reaction pair: when the condition is verified, the corresponding reaction is executed. The condition part of an exception may be based on workflow information (forms, documents, schema and task variables, shared database values), on temporal references, and on occurrence of events, as it will be detailed in the following. The reaction part can be a generic action (or a sequence of actions) involving modification of process data or of the shared database, task state changes (typically task cancellation), case cancellation or end, or notification of the exception to task or case responsible. Different types of actions are associated to the three types of exceptions defined in WIDE. Each type of exception is discussed in the following. 5.1.1 Conditions Conditions can be specified according to workflow information and temporal conditions and to the occurrence of events. Conditions associated to workflow information are exemplified in the following: • conditions on WF schema variables: Employee.Salary>100.000$, where Employee is a form and Salary is a field in the form • conditions on values in shared databases: John Watson is in select Name from Rejected, is evaluated as true when candidate John Watson has already been examined and rejected in a job selection • temporal conditions: @5.00 am, elapsed(60 days) since start(task) • conditions on predefined schema variables (temporal or data conditions): case_duration>expected_duration (where case duration is a predefined function and expected-duration is a case variable).

24

WIDE

Exceptions can be raised by the occurrence of events. Events can be classified as (see Fig. 7): • temporal events, referring to instant, intervals or periodicity • WF events, which in turn can be regular (e.g., constraint violation or variable updates) or exceptional (e.g., task cancellation or rejection, case cancellation, agent not available) • external events, such as arrival of documents, telephone calls, or e-mails. Events can have arguments that are passed to the corresponding reaction to parametrize their behaviour. It has to be noted that conditions associated to Wait connectors are specified in a similar way, although in the case of wait connectors a normal flow of execution is specified as part of the workflow process, since the effect is to continue the execution of the WF case when the condition is verified.

Event

Temporal

Instant

Constraint violation

Interval

WFEvent (Internal)

Periodic

Object/variable update

Variable out of range

Regular

Completion events

Task completion Multitask completion Supertask completion Case completion

Exceptional

Assignment events

Task assigned

External

DBEvent

Document/ Dossier Arrival

TASK_CANCELLATION CASE_CANCELLATION MANUAL_TASK_REJECTION AUTO_TASK_REJECTION ROLE_NOT_AVAILABLE USER_NOT_AVAILABLE JUMP_FORWARD JUMP_BACKWARD

Telephone Call (with subtypes)

Typed e-mail arrival

Figure 7 - Classification of events 5.1.2 Reactions Different types of reactions can be defined, depending on the different types of exceptions: • informative actions; 25

WIDE

• corrective actions; • exception handlers. Informative actions An informative action consists of a notification to a given agent. There are different kinds of informative actions: •

NOTIFY_MAIL Text. The system sends an e-mail to Agent, with the enclosed Text and information concerning the alarm that has just been fired, and the attached expression.

•

NOTIFY_BEEP [HOLD] Freq. The system sends a beep signal to Agent, with the Frequency specified.

•

NOTIFY_FLASH [HOLD] Freq. The system sends a visual signal to Agent, with the Frequency specified.

•

NOTIFY_POPUP [HOLD] Text. The system pops up a Text in the Agent environment.

Some of these actions allows a HOLD indication. If HOLD is set, the action will be active until: • the expression is evaluated as false, and/or • the task goes to a final state (i.e., it disappears from the set of active tasks). The agent in this case specifies a human actor inside the workflow process. Several actors can be specified: • the responsible of the task, • the responsible of a different task, • the responsible of the case, • the WF administrator, • a combination of the above. Corrective actions A corrective action is a change of the state of the task, directly or indirectly through the case it belongs to, as a consequence of firing the alarm. There are different kinds of corrective actions: •

CANCEL_TASK

•

CANCEL_CASE

26

WIDE

•

REJECT_TASK [MANUAL | AUTO]

In case of a task (or case) receiving a corrective action, the full activity has to be stopped. Implementation of corrective actions usually raises the corresponding execution exception. Exception handlers A set of exception handlers is predefined in the system. The name of the handler is composed by adding the suffix _HANDLER to the name of the related exception, such as, for instance, TASK_CANCELLATION_HANDLER

5.2 Alarms Alarms are defined to specify planned exceptions in workflow schemas. Alarms differs slightly from exceptions, since they are not out of the normal flow of control of the workflow. However, they present the same structure and this is why they are included as an specialization of exceptions. Alarms are application dependent, so their conditions are based on workflow information associated to the workflow schema, and actions are performed, which can either be informative actions For instance, condition can be the identification of a delay in performing a task, such as "Elapsed(60 days)", and the corresponding reaction is to notify the case responsible (informative action). Alarms are defined at design time; therefore, alarms are answers to planned actions by the designer. There are two kinds of actions to perform when an alarm is fired: informative actions and corrective actions. In case a duration is specified (either at case level or at task level), and no corresponding action is specified, a default informative action is taken (notification to the case and the task responsible, respectively). Other types of implicit alarms which are being designed for the future versions of the WIDE system include the possibility of generating a set of dynamic and implicit alarms will be activated for the different tasks participating in the flow on the basis of the specification of the duration for the whole case.

5.3 Execution exceptions The system provides a set of predefined execution exceptions, to handle anomalous situations that could occur during the execution of any WF case; they are defined by default for every task or workflow. An execution exception in a workflow is a predefined anomalous situation that may appear during the execution of a workflow, such as, for instance, the explicit cancellation of a task by a human actor who has been assigned to the task.

27

WIDE

An exception handler is the way the system reacts to an exception when it is raised. Exception handlers can receive argument to parameterize their behavior. The system provides default exception handlers for all exceptional events defined in the system. The user can define new exception handlers to customize how an exception is to be managed. The default exception handlers are also available when defining new handlers. This means that new handlers can be built as extensions of the default exception handlers, by performing some actions before raising again the same exception to the upper level. Thanks to the definition of new exception handlers, the user has a powerful and flexible mechanism to control the flow in case of problems. 5.3.1 Typology of execution exceptions The exceptions to be handled by the system through exception handlers constitute a limited and known set, part of the WFMS environment. The following exceptions can be raised during the execution of a workflow: •

TASK_CANCELLATION. A given task is to be canceled. The action can be started either by the user or by the system (for example, through the alarm mechanism).

•

CASE_CANCELLATION. The case where the exception has been raised is to be canceled. The action can be started either by the user or by the system.

•

MANUAL_TASK_REJECTION. A given task is to be manually rejected. The action can be started either by the user or by the system (for example, thrown through the alarm mechanism).

•

AUTO_TASK_REJECTION. A given task is to be automatically rejected. The action can be started either by the user or by the system (for example, thrown through the alarm mechanism).

•

ROLE_NOT_AVAILABLE. A role does not exist in the scope where the task can be assigned.

•

USER_NOT_AVAILABLE. No user with the characteristics that are required by the task to be executed (assigned) exists in the scope of execution of the task.

•

JUMP_FORWARD. The normal flow is broken and the control is passed to a new point (task) into the flow that has never been previously executed.

•

JUMP_BACKWARD.

28

WIDE

The normal flow is broken and the control is passed to a new point (task) into the flow that has been previously executed.

5.4 Organization exceptions Organization exceptions are predefined exceptions linked to events which represent changes in the organization structure that may affect the workflow execution. In a certain way, these exceptions also correspond (are fired by) to different features of the Administration tool, like user deletion, group adding, and so on. Such events are any modification, insertion, or deletion of elements of the organization model, and of their relationships. For instance, a new actor, or a new group, may be added, or an actor may change the group to which he/she is assigned. Advanced mechanisms for organization exceptions management are being defined in WIDE, on the basis of the approach described above. For each of these events, task reassignment, or reassignment of responsibilities at case level, may be necessary. For instance, if the case responsible is leaving the company, a new responsible must be selected for the case. The actions related to these events are in general informative, and the appropriate agent is notified. In the above example, for instance, the supervisor of the case responsible agent should be notified of the fact that a case has no responsible and that a new one should be assigned.

6.

WIDE Architecture

The architecture of the WIDE system is shown in Fig. 8. The WIDE WFMS servers, based on the FORO system [FORO95b] provide functionalities to run locally the tasks and their activation according to the WF schemas stored in the server, including exception support. The WIDE servers manage also the interaction with other servers (for task distribution, for remote execution), and global transaction management, to ensure transaction management at the workflow level. All WF elements are handled as C++ objects at this level. The support to persistently store information, both related to the workflow execution, and to WF specific data and application data, is provided by an indexed file system and/or by a Database Management System. In the present realization of the system, persistent storage is going to be provided by the Oracle 7 DBMS. The mapping between the objects at the WIDE server layer and the data stored in the persistent storage is provided by the Basic Access Layer module. Other modules are part of the WIDE architecture, but they are not shown in the figure since they are not discussed in the present paper. For sake of completeness we briefly mention them:

29

WIDE

• a WF schema compiler (a module included in the WIDE servers): it transforms WF schema definition in appropriate data structures to allow case instantiation according to the schema specifications; • a WF design environment (on top of the WIDE server, provided as an external module): this module includes facilities for designing a graphical WF schema definition; a complete design environment based on reusable components will be developed during the WIDE project; • a WF set up environment: to specify the organization structure, and the individual actors using the WFMS; • WF monitoring support: graphical monitoring of the progress of a case, statistical reports on the WF executions, and the like. In the next sections, we detail the functionalities provided by three layers composing the WFMS. FORO servers Schema Automation Tool

GTM

Temporal Event Generator

Scheduler

Active Rule Manager

CORBA / IDL Interface

BAL (Basic Access Layer) LTM

Object Manager

Query Manager

Change Notificator

ORACLE Triggers

External Data

WF Specific Data

FORO Data

Figure 8 - WIDE modules

30

WIDE

6.1 Database support for WFMS The persistent storage layer functionalities are dependent on the technology adopted in this layer. While the first versions of this layer were based on a hierarchical indexed file system, the new versions of the WIDE WFMS are adopting the relational database technology. The advantage of the DMBS technology are the possibility of providing advanced and efficient support for transaction management and for exception management in the WFMS, in addition to a more powerful access to shared application data. Different types of data are stored in the database: • WIDE data: all WF schemas entered in the WIDE server and the organizational model are stored as permanent data in the database; a predefined set of relational tables is defined to store such data. • WF specific data: as shown in the WIDE model section, to each WF schema a number of local variables can be defined to share data between different tasks in the same workflow and to provide support for exception management (e.g., the definition of the case responsible, the definition of shared local WF data) • external data: external data include all shared DBs which are available during WF execution; such external data access must be specified at the level of WF schema definition, to allow a correct management of shared data with the transaction management mechanisms. Modifications of external data can also be an event type monitored by conditions associated to exceptions in WF schemas. • stored triggers: basic exception handling and condition monitoring mechanisms are provided by triggers defined in the Oracle DB and automatically derived from the WF schema during WF schema compilation. Each WIDE server has a local database associated with it to manage its local data and to store the related WF schema information. The local database can also be accessed by other applications, for information concerning shared application data.

6.2 WFMS server layer The WIDE WFMS server layer provides the core functionalities of the WFMS. The Schema Automation tool is in charge of interpreting a workflow schema instance, a case, selecting the next task to be assigned/executed according to the status of each case and the termination of tasks by agents. The Local Scheduler module is responsible of dispatching requests for allocation of tasks to agents. This modules uses different criteria when choosing between a set of agents who can perform a task. Workload, availability of agents, and priorities are some of the available discrimination mechanism. This module can also be instructed to assign directly a task to a given agent. This module is part of the Scheduling System; this is a distributed service which operates in a network of WIDE nodes. If the Local Scheduler module is not able to satisfy the request in its domain, then re-sends the request to the Global Scheduler modules which finds

31

WIDE

a suitable Local Scheduler module, in the net, to satisfy the request. In this way, the assignment of tasks to agents can be done in a distributed way. The Global Transaction Manager (GTM) module is responsible for high level transaction management on the workflow level. Specifically, it controls a relaxed version of transaction atomicity. For this purpose, it makes use of an advanced compensation mechanism, based on the saga transactional concept [GS87]. The GTM module uses the LTM module for lowerlevel transaction management. It is independent of the underlying database management system, and is therefore located in the WIDE server set. The Active Rule Manager, coupled with a Temporal Event Generator, are modules needed for advanced exception management functionalities. Temporal events are generated by the Temporal Event Generator according to the existing schema specifications and case activations in the server, using also underlying data stored in the database. The occurrence of other events, related to task execution (e.g., a task has been canceled), to application specific data, or to a change of the organization structure, is monitored internally in the database, and this information is accessible to the Active Rule Manager, which tests the conditions associated to the events and specified in the WF schemas, and triggers the corresponding actions.

6.3 Basic Access Layer The basic access layer provides functionality needed to manage the objects handled by the WIDE servers as persistently stored objects. This layer decouples the functionalities provided at the WIDE WFMS server level and the underlying database support, making the server level independent from the actual technological platform used to provide persistent storage. The following functionalities are provided by the Basic Access Layer: • Dynamic query manager: to provide querying functionalities at the server level on the objects stored in the database; • Object mapping: to provide insertion, deletion, and modification functionalities on objects; • Change notificator: to provide information about events occurring at the database level to the server for high level exception management; • The Local Transaction Manager (LTM) modules is responsible for middle level transaction management on the individual supertask level. Specifically, it controls the isolation and atomicity property within the boundaries of a supertask, based on a nested transaction concept [DHL91]. The LTM module uses the transactional mechanisms of the underlying database management system, and is therefore located in the WIDE interface layer.

32

WIDE

7.

Example

The enrollment WF handles the volunteer enrollment procedure of a military office. The candidate being examined fills in an application form and gives his personal data get Applicant which are entered into the global WF variable Applicant by the task's agent. At this point, the identity of the applicant becomes known; if the applicant is already known as Drafted or as Rejected, an exception is risen and the case is forced to completion. The exception is expressed as a dynamic SQL2 query on the Drafted and Rejected tables, which use the Applicant variable. The candidate has to pass some physical and psychological tests: these tests are performed into a visiting room. Thus, before starting the physical test, the candidate has to wait for a visiting room to become free; this is a precondition, also expressed as a SQL2 query on the FreeVisitRoom table. The action's specification consists in allocating the room to the specific test; the room is then made free at the end of the visit, when the candidate is either drafted or rejected.

33

WIDE Military Enrollment Get and record data

Workflow variables:

A new candidate is registered get Applicant; exists (select * from Drafted where Drafted.SSN = Applicant.SSN or select * from Rejected where Rejected.SSN = Applicant.SSN): endWF

struct Applicant_type { int SSN; string Name; string Data} Applicant; enum TestResult_type {Good, Bad} TestResult; int Room;

exists (select * from FreeVisitRoom) Physical test The candidate is submitted to physical test Room = select-one Room from FreeVisitRoom; delete from FreeVisitRoom where FreeVisitRoom.Room = Room; get TestResult;

TestResult=Bad

TestResult=Good

Psychological test The candidate is submitted to psychological test get TestResult;

TestResult=Good

TestResult=Bad

Draft The candidate is enrolled

Reject The candidate is refused

insert into Drafted ; insert into FreeVisitingRoom

insert into Rejected ; insert into FreeVisitingRoom

WF exception: exists (select * from Revoke where Revoke.SSN = Applicant.SSN): insert into FreeVisitRoom ; update set Drafted.Revoked = `Y' where Drafted.SSN = Applicant.SSN; update set Rejected.Revoked = `Y' where Rejected.SSN = Applicant.SSN; endWF Figure 9 - The volunteer military enrollment example

34

WIDE

After the physical test, the physician enters data about the result of the test itself in the form of a binary variable get TestResult. If the result is Bad, the candidate is refused and his data are stored into the Rejected table. Otherwise, he goes through a psychological test. The outcome of the psychological test is also summarized into the same binary variable, which finally indicates whether the candidate is drafted (and his data are stored into the Drafted table) or rejected. These two tasks terminate the workflow. Duing the entire case execution at any time the volunteer can always decide to revoke his application. As this happens, the global exception Revoke, defined at the schema level, is activated to manage the situation: should the exception be risen after the candidate has been drafted or rejected, the attribute Revoked is marked as true in the suitable table and the case is terminated (endWF).

8.

Related work

In this section we discuss the characteristics of the WIDE environment with respect to existing proposals, both from the research and commercial applications point of view. First we discuss general characteristics of workflows, then results achieved by research in conceptual workflow modeling and in the use of active rules to support workflow execution management; finally, the characteristics of the main commercial WFMSs are described.

8.1 Characterizing workflows At present there is no commonly accepted classification of workflows. A first characterization, appeared in [GHS95] classifies workflows according to the complexity of the flow structure: scarcely-structured workflows involve a set of tasks to be executed in sequence; highly-structured workflows may on the other hand involve complex synchronization mechanisms among tasks, possibly based on case-specific conditions. One of the most widely used classifications, first proposed in [M92] distinguishes among ad hoc workflows, administrative workflows, and production (or transactional) workflows. Ad hoc workflows describe simple, unstructured processes where it is difficult to find a schema for tasks coordination. This kind of workflows is usually defined for being executed in one or a limited number of instances, and requires human interaction also in the task coordination part. In this case, WFMSs must support communication between (human) agents, and inform about the state of case execution. Administrative workflows describe repetitive processes, whose execution can therefore be effectively automated. WFMSs are encharged of assigning tasks to the proper agent and of collecting results. Production workflows involve complex and highly-structured processes, whose execution requires a high number of transaction accessing different information systems. WFMSs supporting production workflows must allow definition of complex workflow schemas and must provide an efficient and automated exception-handling mechanism. In [GHS95] workflows are also characterized along a continuum from human-oriented to system-oriented. In human-oriented workflows, human agents cooperate in the coordination

35

WIDE

and execution of tasks, while system-oriented workflows are highly automated and involve the executions of complex software tasks, with little human intervention. We believe that the WIDE model is suited to describe and support the execution of all these workflow types. Although its focus is on paper-driven applications, WIDE effectively supports transactional, highly-structured, system-oriented workflows. In fact, the model includes a very flexible schema specification, allowing a static specification of casedependent properties, such as number of tasks to be executed in a multitasks and flow routing; WIDE also provides an exception-handling mechanism that reduces to a minimum the necessity of human intervention. Furthermore, the DBMS-oriented nature of WIDE eases the transactional support and the monitoring of application data, which can be tightly integrated with the WFMS, allowing a wider control on workflow execution.

8.2 Workflow Conceptual Models The first descriptions of WFs have been proposed by office modeling as a way of describing office procedures [BP84]. Such descriptions were based on extensions of classical formal models (such as Petri Nets, production rules and flowcharts); a number of modeling support tools were proposed. The need of a closer relationship between modeling techniques and enactment of processes has been particularly developed within the process modeling area in software engineering. This research has produced several methodological contributions and WF specification languages [GHS95, EN93]. Several tools for process modeling, generally based on Petri Nets, are focused on the ability of “animating” WFs, thereby understanding their dynamic behavior [BFG93]. Recently, a growing interest has concentrated on connecting WF systems to existing information systems. In particular, the desire of interconnecting to existing data and of coping with large volumes of WF information has provided impetus to the bridging of WFs and database technologies. The challenge posed by WF management pushes towards removing some of the classical limitations of databases in the context of concurrency and transactional models [H93]. Novel features of databases, such as active rules, are seen as particularly promising in the context of WFs [DHL90, WC95]. A powerful specification mechanism is proposed in ObjectFlow [HK96]. The specification of tasks’ coordination can be very complex and case-dependent, and the model includes advanced task types (static and dynamic compound tasks), with a semantic similar to that of supertasks and multitasks in WIDE. Task assignment is based on a pull model; roles are defined in the system, and tasks are assigned to roles. Agents can then select tasks associated to the roles they belong to. Agents, before terminating a task, can also specify successors tasks to be executed, bypassing the flow description. The effects of the change are local to a specific WF instance. ObjectFlow also offers a limited exception handling mechanisms: special tasks can be defined to handle anomalous situation. When an agent detects an exception, it aborts active tasks in the normal flow and modify the flow structure in order to give the control to the handler task. The WIDE approach is different, since we allow case execution to proceed, and in the meantime the WFMS (possibly with the aid of a human agent) performs the exception handling procedure. This should avoid undue losses of work. Anyway, ObjectFlow behaviour may be represented in the WIDE model by defining suitable exception handling routines. 36

WIDE

The ObjectFlow model is very well suited to implement administrative workflows, but the lack of a flexible exception handling mechanism and of explicit access to external databases could limit its effectiveness for production workflows. In the model developed at Bellcore [RS94] the focus is on transactional workflows. The most peculiar feature of this model is that possible task states may differ from task to task. This is because tasks can have different characteristics according to their transactional behaviour. Tasks may also have different isolation properties: the results of an incomplete task may be made visible to other concurrent tasks, or they may be deferred until task commitment. Flow control is determined by scheduling preconditions, that can be static (defined before the workflow execution) or dynamic (created during workflow execution). Preconditions may relate execution states of other tasks, local workflow variables or external variables (i.e., variables modified by external events, such as time values). Simple preconditions can be combined with Boolean operators to form complex scheduling constraints. This model gives to the workflow designer a greater flexibility with respect to the WIDE model; on the other hand, the fact that in principle a task could start independently from the execution state of the others, and in particular independently from the end of other tasks does not ease the specification of ad hoc and administrative workflows. Furthermore, it is difficult to give a graphical representation of the flow structure, since the start of a task is not necessarily related to the end of another task. In [BW95] a taxonomy of activities and exceptions is introduced. A interesting proposal, absent in other workflow models, relate the definition of batch activities, i.e., activities that require control and data coordination among different instances of a workflow. A proposed example relates the ranking of candidates for a position. In WIDE, batch activity can be implemented in ad-hoc schemas, that synchronize with other cases of other workflows by wait connectors and the shared database.

8.3 Active rules for workflow management Active rules were indicated as a promising operational model for workflows [WC95], but so far few concrete proposals were made to substantiate this claim. Work of Dayal et al. [DHL90] describes the use of active rules for supporting workflow management. A detailed description of how active rules can be used for workflow enactment is proposed in [KLRR95]. The paper describes ECA rules to manage workflow execution on the top on an object-oriented database (GemStone). Rules are also provided to select task executors and to manage agents’ worklists. The paper does not discuss in detail rule derivation and how active rules can be used to handle exceptions. In [CCPP95b], the ECA rules operate on the top of a relational database; besides defining rules to manage ordinary workflow execution, the paper shows how rules can be derived from workflow specifications and how they can be effectively used for exception handling. Although both papers offer very useful contribution, the WIDE approach is different: an extensive use of active rules could in fact degrade system performance and reduce the portability, since characteristics and flexibility of active rules vastly differ with the particular

37

WIDE

DBMS. On the other hand, the power of active rules is very valuable in detecting and signaling event generated by database modifications caused by user applications. Therefore, active rules in WIDE are mainly used to implement exceptions. A decentralized model for multiple executions of the same task based on active rules is presented in [BJ94]; in this model all eligible agents are notified, but only the correct number of task instances are executed. This model focuses on a very specific subproblem in workflow enactment, as it neither discuss task interconnections and interactions, nor exceptions and access to shared databases.

8.4 Related systems and models Many commercial systems have been introduced to support WFM, and we discuss here some characteristics of WIDE with respect to some of the most popular commercial systems, namely IBM FlowMark, ActionWorkflow, and InConcert. Extensive reviews of commercial WFMSs can be found in [GHS95, BIS95]. FlowMark (IBM) is an object-oriented WFMS for OS/2, Windows, and RISC systems. It supports a heterogeneous client-server environment, and it is based on ObjectStore. It supports automatic tasks execution, by allowing specifications of software applications that must be started when a task begins. Unlike WIDE and many other WFMS, FlowMark is not a stand-alone product: it must be integrated with external software (such as Lotus Notes) to provide a complete document management solution. Assignment is based on roles and organization, in a flexible way. Tasks in FlowMark may be associated to executables on a variety of client platforms, and can access the WFMS data containers. Application access to databases is not modeled in FlowMark, which also has limited mechanism to support exception handling. FlowMark leaves a lot of freedom to process activities, and its focus is on coordination rather than control. With respect to WIDE, this allows increased modularity and software reuse, but it reduces the capability of the WFMS to monitor and supervise task executions, and to offer an efficient exception handling mechanism. The InConcert workflow management system by Xerox Xsoft [MS93] is strongly DBMSbased, like WIDE. The system builds a partly object-oriented layer on top of a commercial database management systems, like Oracle or Sybase. The aim is not to provide advanced database mechanisms to the workflow management layer, as in the WIDE case, but rather use the DBMS support to store views of object attributes and process histories. The system provides a flexible interface to enable specialisation towards specific application areas. InConcert is a document-centered product, although it is moving towards transactional workflows and fully distributed architectures. The Action Technologies workflow management system [MWFF92] does not use a DBMS basis, but the Lotus Notes groupware system as its storage layer. The system uses a workflow paradigm that is based on speech act, i.e. on specific communication patterns between actors that require the performance of tasks and actors that provide the performance of tasks.

38

WIDE

Workflow applications are modeled in so-called business process maps, consisting of interlinked workflow loops. The workflow model is very peculiar: the goal is to achieve customer satisfaction rather than task completion. Customers and performers agree (after some negotiations) on the work to be done. Again, the flexibility of this model is paid by a steeper learning curve and by a harder formalization of simple, repetitive processes.

9.

Concluding remarks and future work

In the present paper, the WIDE model and architecture have been illustrated. The main characteristics of the WIDE approach are an advanced organization model and exception specification from the modeling point of view, and, from the architecture point of view, a distributed database support for workflow execution, including transaction management and active database support of exception management. A first version of the system is operational on a Unix Sun OS environment for the servers, and PCs as clients; the ongoing development is including mainly architectural improvements, based on the architecture defined in Section 6, using the Oracle 7 DBMS for supporting workflow execution, as well as modules for intelligent exception and transaction management. Support for advanced features of the model, such as complex exceptions and the full organization model, is being studied, are being developed. On going research work for future developments of the system includes issues related to workflow interoperability and full distribution of workflow execution. Other research work will include: • identification of systematic exceptions from logs of tasks, to identify Business Process Reengineering (BPR) requirements. The reengineering activity itself is out of the scope of the project; • definition of examples/prototypes/typical situations/standards to be re-used in several process definitions, as typical situations or patterns, possibly involving a set of tasks; • change management support for dynamically evolving workflows, including version management for WF schemas and supertask schemas. You can find more information about WIDE in the following URL: http://www.sema.es/projects/WIDE.

Acknowledgements This work has been partially supported by the European Commission under ESPRIT Project N. 20280 WIDE. The authors acknowledge the contribution to the present work of all participants in the project from Sema Group sae, Politecnico di Milano, University of Twente, Hospital General de Manresa, ING Bank, and in particular of Prof. Stefano Ceri.

39

WIDE

10. References [ASSR93] Attie, P., Singh, M., Sheth, A., Rusinkiewicz, M., Specifying and Enforcing Intertask Dependencies, Proc. 19th VLDB Conf., Dublin, Ireland, 1993. [BFG93]

Bandinelli, S., Fuggetta, A., Ghezzi, C., Software Process Model Evolution in the SPADE Environment, IEEE Transactions on Software Engineering, December 1993.

[S95]

Silver, B. (senior consulting partner), The BIS Guide to Workflow Software, BIS Strategic Decision, September 1995.

[BJ94]

Bussler, J., Jablonski, S., Implementing Agent Coordination for Workflow Management Systems using Active Database Systems, Proceedings of the 4th International Workshop on Research Issues in Data Engineering: Active Database Systems (RIDE-ADS '94), Houston, Texas, USA, February 1994.

[BN95]

Blumenthal, R., Nutt, J., Supporting Unstructured Workflow Activities in the Bramble System, Conference on Organizational Computing System, 1995.

[BW95]

Barthelmess, P., Wainer, J., Workflow systems: a few definitions and a few Suggestions, Conference on Organizational Computing System, 1996.

[BP84]

Bracchi, G., Pernici, B., The Design Requirements of Office Systems, ACM Trans. on Office Information Systems, Vol. 2, No. 2, April 1984.

[CCPP95a] Casati, F., Ceri, S., Pernici, B., Pozzi, G., Conceptual Modeling of Workflows, Proceedings of the 14th Intl. conference on Object Oriented and Entity Relationship, Gold Coast, Australia, December 1995 [CCPP95b] Casati, F., Ceri, S., Pernici, B., Pozzi, G., Workflow Enactment by Active Rules, submitted for publication [CCPP96] Casati, F., Ceri, S., Pernici, B., Pozzi, G., Semantic Workflow Interoperability, Proceedings of the 12th Intl. conference on Extending Database Technology, Avignon, France, March 1996 [DE95]

Data Engineering, Special issue on Workflow Systems, March 1995, vol. 18, n. 1.

[DHL90] Dayal, U., Hsu, M., Ladin, R., Organizing Long-running Activities with Triggers and Transactions, Proc. ACM SIGMOD, 1990. [DHL91] Dayal, U., Hsu, M., Ladin, R., A Transactional Model for Long-Running Activities, Proc. 17th International Conference on Very Large Databases, Barcelona, Spain, 1991. [EKR95]

Ellis, S., Keddara, K., Rozenberg, G., Dynamic Change within Workflow Systems, ACM Conf. on Organizational Computing Systems (COOCS 95), 1995.

[EN93]

Ellis, C., Nutt, G., Modeling and Enactment of Workflow Systems, in Application and Theory of Petri Nets, 1993, M. Ajmone Marsan Ed., Lecture Notes in Computer Science 691, New York: Springer Verlag, 1993.

[FKB95]

Forst, A., Kuhn, E., Bukhres, O., General Purpose Workflow Languages, Distributed and Parallel Databases, vol. 3, n. 2, April 1995.

[FORO95a] The FORO Method (v2.11), FORO Team. November, 1995 40

WIDE

[FORO95b] The FORO Designer User Manual (v2.11), FORO Team. November, 1995 [FORO95c] The FORO Desk User Manual (v2.11), FORO Team. November, 1995 [GHS95]

Georgakopoulos, D., Hornick, M., Sheth, A., An Overview of Workflow Management: from Process Modeling to Workflow Automation Infrastructure, Distributed and Parallel Databases, vol. 3, n. 2, April 1995.

[GS87]

Garcia-Molina, H., Salem, K., Sagas; Proceedings 1987 ACM SIGMOD International Conference on Management of Data; USA, 1987.

[H93]

Hsu, M. (ed.), Special Issue on Workflow and Extended Transaction Systems, Data Engineering Bulletin, 16(2), June 1993.

[HK96}

Hsu, M., Kleissner, C., ObjectFlow: Towards a Process Management Infrastructure, Distributed and Parallel Databases, 4, 1996.

[KLRR95] Kappel, G., Lang, P., Rausch-Schott, S., Retschitzegger, W., ``Workflow Management Based on Objects, Rules and Roles'', Data Engineering, vol. 18, n. 1, March 1995. [LMF89]

Leban, B., McDonald, D.D., Forster, D.R., A Representation for Collections of Temporal Intervals, Science, Knowledge Representation, 1989, PP. 367-371

[M87]

Malone, T.W., Modeling coordination in organizations and markets, Management Science, vol. 33, No. 10, Oct. 1987

[M92]

McCready, S., “There is more than one kind of workflow software”, ComputerWorld, November 1992.

[MS93]

McCarthy, D.R. , Sarin, S.K., Workflows and Transactions in InConcert, IEEE Data Engineering Bulletin, June 1993.

[MWFF92]

Medina-Mora, R., Winograd, T., Flores, R., Flores, F., The Action Workflow Approach to Workflow Management Technology; Proceedings ACM 1992 Conference on Computer-Supported Cooperative Work, Toronto, Canada, 1992.

[P90]

Pernici, B., Objects with roles, ACM SIGOIS Conf. on Office Information Systems, Boston, MA, 1990

[RS94]

Rusinkiewicz, M., Sheth, A., Specification and Execution of Transaction Workflows, in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994.

[SR93]

Sheth, A., Rusinkiewicz, M., On Transactional Workflows, Data Engineering Bulletin, 16(2), June 1993.

[SSU95]

Silberschatz, A., Stonebraker, M., Ullman, J., Database Research: Achievements and Opportunities Into the 21st Century, Report of an NSF Workshop on the Future of Database Research, May 26-27, 1995.

[WC95]

Widom, J., Ceri, S., Active Database Systems, Morgan-Kaufmann, San Mateo, Ca, May 1995.

[WFMC95] WMC Members. Glossary. A Workflow Management Coalition Specification, August 1995. http://www.aiai.ed.ac.uk/WfMC/

41

WIDE

42

WIDE

APPENDIX 1

Military enrollment: graphical presentation of execution

43

WIDE

This is a graphical representation of the workflow schema shown as an example in Section 7 using the FORO Process Graph viewer, part of the FORO environment. This graph includes the following elements: • Starting and (multiple) end points, marked as traffic-lights, • Tasks are represented as small windows. If the task has been already performed, a check mark is added to the icon. The active tasks (only one in this case) are in blue (gray in the figure), and those tasks that are not part of the flow or are beyond the current point of interpretation of the flow are in white. • Conditions are question marks in a circle. If the condition has already been evaluated, the question mark is in black; otherwise, it is in white. Positive branches are in green and negative one are in red.

44

WIDE

PDL definition of Military enrollment

PROCESS "Military enrollment" FILE milita.pro DESCRIPTION 'Compulsory enrollment procedure of a military office.` DECLARATION CONSTANTS NONE VARIABLES VAR "Physical Test Result" BOOLEAN NULL VAR "Psychological Test Result" BOOLEAN NULL VAR "Drafted" BOOLEAN NULL VAR "Applicant Data" STRING "" KEYS KEY "Applicant SSN" INTEGER 0 KEY "Applicant Name" STRING "" INFOS FORM "Application" applica.for EXPRESSIONS COND "@[Physical Test Result]" : NULL ENDCOND COND "@[Psychological Test Result]" : NULL ENDCOND TASKS TASK "Get and record data" ROLE AdministratorOfficer SERVER Server@Case USER User@Case DESCRIPTION 'A new candidate is registered.` IN NONE OUT FORM "Application" MANDATORY ENDTASK TASK "Physical test" ROLE Doctor SERVER Server@Case USER User@Case DESCRIPTION 'The candidate is submitted to physical test and the result is registered in the "Application" form.` IN FORM "Application" MANDATORY OUT FORM "Application" MANDATORY ENDTASK 45

WIDE

TASK "Psychological test" ROLE Psychologist SERVER Server@Case USER User@Case DESCRIPTION 'The applicant is submitted to psychological test and the result is registered in the "Application" form.` IN FORM "Application" MANDATORY OUT FORM "Application" MANDATORY ENDTASK TASK "Draft" ROLE AdministratorOfficer SERVER Server@Case USER User@Case DESCRIPTION 'The candidate is enrolled and the "Application" form is completed.` IN FORM "Application" MANDATORY OUT FORM "Application" MANDATORY ENDTASK TASK "Reject" ROLE Officer SERVER Server@Case USER User@Case DESCRIPTION 'The candidate is refused and the "Application" form is completed.` IN FORM "Application" MANDATORY OUT FORM "Application" MANDATORY ENDTASK ENDDECLARATION TASK "Get and record data" IF TASK "Get and record data" THEN TASK "Physical test"; IF TASK "Physical test" THEN COND "@[Physical Test Result]"; IF COND "@[Physical Test Result]" THEN TASK "Psychological test"; IF TASK "Psychological test" THEN COND "@[Psychological Test Result]"; 46

WIDE

IF COND "@[Psychological Test Result]" THEN TASK "Draft"; IF (OR (NOT COND "@[Physical Test Result]") (NOT COND "@[Psychological Test Result]")) THEN TASK "Reject"; (OR TASK "Draft" TASK "Reject") END

47