Supporting aspect orientation in business process ...

Supporting aspect orientation in business process management Authors:

Amin Jalali Chun Ouyang Petia Wohed Paul Johannesson

This is the authors version of a work that was submitted/accepted for publication in:

International Journal on Software and Systems Modeling (SoSyM)

The final publication is available at Springer via

Springer

Notice: Changes introduced as a result of publishing processes such as copy-editing and formatting may not be reflected in this document. For a definitive version of this work, please refer to the published source: http://dx.doi.org/10.1007/s10270-015-0496-7

c

Copyright 2015 Springer

Noname manuscript No. (will be inserted by the editor)

Supporting aspect orientation in business process management From process modelling to process enactment Amin Jalali · Chun Ouyang · Petia Wohed · Paul Johannesson

Received: date / Accepted: date

Abstract Coping with complexity is an important issue in both research and industry. One strategy to deal with complexity is separation of concerns, which can be addressed using Aspect-Oriented paradigm. Despite being well researched in Programming, this paradigm is still in a preliminary stage in the area of Business Process Management (BPM). While some efforts have been made to introduce aspect orientation in business process modelling, there is no holistic approach with a formal underlying foundation to support aspect-oriented business process design and enactment, and this gap restricts Aspect-Oriented paradigm from being practically deployed in the area of BPM. Therefore, this paper proposes a sound systematic approach which builds on a formal syntax for modelling aspect-oriented business processes and a Petri-net-based operational semantics for enacting these processes. The approach enables the implementation of software system artefacts as a proof of concept to support design and enactment of aspect-oriented business processes in practice. The approach is demonstrated using a banking case study, where processes are modelled using a concrete notation that conforms to the proposed formal syntax and then executed in a state-of-the-art BPM system where the implemented artefacts are deployed. Keywords Business Process Management; AspectOriented Decomposition; Process Modeling; Process Enactment; Weaving; Cross-Cutting Concerns.

A. Jalali Stockholm University, Forum 100, SE-164 40 Kista, Sweden E-mail: [email protected] C. Ouyang, P. Wohed and P. Johannesson E-mail: [email protected]; {petia,pajo}@dsv.su.se

1 Introduction 1.1 Context Complexity is a common but important issue in everyday life. People call a phenomenon complex, when the understanding about the phenomenon exceeds their capacity [34]. Different approaches are employed to deal with complexity, among those separation of concerns proposes to break down a phenomenon, like a system, into smaller meaningful and manageable pieces. As a result, it reduces complexity and improves re-usability of sub-systems and makes the evolution of the overall system simpler. Separation of concerns is performed through modularization, which enables focusing on each individual concern by examining the respective subsystem (or module) [53]. However, it is often challenging to support separation of concerns if certain concerns are scattered across different systems, intertwined with each other, or both. These are often known as cross-cutting concerns. For example, there are concerns about money laundering in the financial domain for which different policies are defined to prevent fraud in banking processes, and such concerns are often scattered across various processes in a bank. Moreover, each process in a bank not only should consider concerns related to money laundering but also other concerns such as security and privacy. Separation of cross-cutting concerns can often be addressed through a so-called Aspect Orientation modularization technique. The technique is well investigated in Programming [33,53] and Requirement engineering [22, 37, 42], but it is still in its preliminary stage in the area of Business Process Management (BPM). In BPM, aspect-oriented business process modelling has been investigated to separate cross-cutting concerns

2

from process models [8, 15, 28]. Despite these efforts, none of the existing techniques has a formal syntax definition to support the modelling of aspect-oriented business processes in general, and no execution semantics yet exists to support the enactment of these processes. The lack of theoretical support has also restricted the application of Aspect-Oriented paradigm in practice.

1.2 Problem elaboration This section explains the problem using a fictitious example of Transfer Money processes in a bank as illustrated in Fig. 1. There are different processes specifying alternative ways a customer can transfer his/her money, e.g. i) via the Internet (captured in Internet Transfer Money process); ii) at a branch of the bank (Branch Transfer Money process); iii) using mobile to mobile transfer service (M2M Transfer Money process); iv) through Automated Teller Machine (ATM Transfer Money process); etc. There exist two policies with which these processes should comply, i.e. security and logging policies. A security policy states that additional actions should be taken if the transaction is nominated as inadequately secured. The definition of such a nomination varies in each of these processes. For example, such circumstance is defined in Internet Transfer Money process when the customer wants to transfer money to others’ accounts. In Branch Transfer Money or ATM Transfer Money process, such an investigation is not needed since the identity of the customer is verified by a clerk or by Personal Identification Number. In M2M Transfer Money process, such investigation is needed when the customer wants to transfer money to unregistered numbers or the amount to transfer exceeds the limit set by the customer as default. The extra security considerations involve a sequence of actions such as the customer to sign the transaction, the system to investigate if the transaction is a potential fraud (through Sign Transaction and Detect Fraud tasks, respectively) before the money can be transferred. Moreover, the Customer Relationship Management (CRM) department should notify the customer about the transaction through Notify Customer task after the money transfer. As a logging policy, all transactions should be archived after the money has been transferred (through Archive Information task). Both policies are illustrated using the Internet Transfer Money process in Fig. 1, where the customer should first Fill Form, and then move on to Transfer Money. In reality, the above policies are scattered over the different Transfer Money processes, meaning that they

A. Jalali et al.

are repeated in many process models - known as scattering problem. Process models are also tangled to these policies, meaning that each process should comply to different policies - known as tangling problem. Traditional modularization like vertical (a.k.a. hierarchical) and horizontal decomposition techniques can hardly address these problems in encapsulating the relevant processes and policies into modules, because vertical decomposition cannot solve the scattering problem while horizontal decomposition cannot solve the tangling problem. To this end, aspect-oriented modularization is seen as a new technique to tackle the scattering and tangling problem, which is also known as the cross-cutting problem, during process decomposition and modularization.

1.3 Envisaged solution Fig. 2 depicts how modularization of the processes in Fig. 1 is envisaged. In essence, the tasks related to the security aspect are extracted in a process called Confirm. Similarly, the tasks required by the logging policy are encapsulated in process Archive. These processes are related to the core processes (e.g. Internet Transfer Money, Branch Transfer Money) via certain rules. At runtime, these processes will be triggered when the states fulfilling these rules are reached. Such modularization may bring the following benefits. Firstly, it increases the re-usability since the concerns are defined once and used in several processes. Secondly, it facilitates maintenance as a change to a concern only needs to be specified in one place. Thirdly, it reduces the complexity of business process models because: i) it can “hide” unnecessary information for some stakeholders while displaying it in a concise form to relevant stakeholders; ii) it often reduces the overall number of tasks; and iii) it may even eliminate the need for split and join behaviour in the core processes, as such behaviour would already be specified in the connection rules between main process and cross-cutting concerns.

1.4 Positioning of the work This paper presents a technique for business process decomposition, namely aspect-oriented modularization, which enables the abstraction and encapsulation of crosscutting concerns of business process models. Such modularization facilitates the management of companies’ policies and their impact on business processes in a structured and concise way. This paper takes inspiration from the advances in the Aspect-Oriented Programming (AOP) area [33, 53].

Internet Transfer Money

3

Customer Sign Transaction

CRM Detect Fraud

Customer Fill Form Transfer to Own account in the bank

Transfer Money

Notify Customer Transfer to others account Archive Information

Legend

M2M Transfer Money

Branch Transfer Money

...

ATM Transfer Money

Supporting aspect orientation in business process management

Start

XOR Split

OR Split

Task

End

XOR Join

Control Flow

Resource

Customer Fill Form

Transfer Money

- When Transferring Money Archive

Advised Join Point

Logging Aspect

Branch Transfer M.

Internet Transfer M.

ATM Transfer M.

M2M Transfer M.

...

Fig. 1 Transfer Money processes

PROCEED

Archive Information

Advice

Confirm

Security Aspect

Pointcut

- When Transferring Money through Internet to others accounts

Customer Sign Transaction

CRM Detect Fraud

PROCEED

Notify Customer

Aspect

Fig. 2 Transfer Money processes - through Aspect-Oriented Business Process Modelling

In contrast to earlier work on Aspect-Oriented Business Process Modelling [8, 15], this paper proposes a sound systematic approach to support aspect orientation from business process modelling to process enactment, which are the two key phases of a BPM lifecycle. On the one hand, we define a formal syntax for modelling aspect-oriented business processes and operational semantics for enacting these processes. These form the main theoretical contribution of our work to the area of BPM. On the other hand, we implement our approach into software system artefacts1 , as a proof of concept, which offer practical support to the design and enactment of business processes. The presentation of the paper is aligned with the main phases of the work. Section 2 presents the formal syntax. Section 3 proposes the operational semantics. Section 4 summarizes the implementation. Section 5 discusses the case study. Section 6 elaborates on a review of the related research.Finally, Section 7 concludes the work and presents directions for future research. 1 Artefacts are defined as objects made by humans with the intention that it be used to address a practical problem [32].

2 Modelling of Aspect-Oriented Business Processes 2.1 Basic concepts and terminology This section introduces basic concepts and terminology of aspect-oriented business process models using the example of the modularised Transfer Money processes shown in Fig. 2. Those concepts and terms related to aspect orientation are mostly sourced from the area of Aspect-Oriented Programming (AOP). A process, which contains the core functionality of a business process, is called core-concern or main process, e.g. the Internet Transfer Money process in Fig. 2. A potential point in a main process, for which a crosscutting concern can be defined, is called a join point, e.g. task Fill Form or Transfer Money in the above main process. A process, which models a cross-cutting concern, is called an advice, e.g. the Confirm or Archive process in Fig. 2. The advices representing similar concerns can be classified into the same group, which is called an aspect, e.g. the Security Aspect or Logging Aspect. A join point (e.g. Transfer Money) can be related to one or several advice(s) (e.g. Confirm and

4

A. Jalali et al.

Archive) via certain rules. Such a rule is known as a pointcut, e.g. the two rules in the Logging and Security Aspects in Fig. 2. A join point to which an advice is linked via a pointcut is called an advised join point, e.g. the Transfer Money task in Fig. 2. An advice (process) contains a special task called PROCEED, which is a placeholder for carrying out the corresponding advised join point (task). There are three types of advices in terms of the position of a PROCEED task in an advice process. A PROCEED task may be positioned in the beginning of an advice, in which case, the advice is expected to be executed after the occurrence of the advised join point (that the PROCEED task refers to). Such an advice is called an ‘after ’ advice, e.g. the Archive advice in Fig. 2. Similarly, a PROCEED task may be specified at the end of an advice, in which case, the advice occurs before the advised join point and is thus called a ‘before’ advice. Finally, a PROCEED task may be defined in the middle of an advice, and such an advice is called an ‘around ’ advice. For example, in Fig. 2 the Confirm advice is an ‘around’ advice, where the Sign Transaction and Detect Fraud tasks are executed before the corresponding advised join point Transfer Money, and the Notify Customer task is executed after Transfer Money. In the area of AOP, a join point model comprises three elements: i) join point (specifying when an advice can run), ii) pointcut (specifying a way to quantify a join point), and iii) advice (specifying what to run before, after or around a join point). Here, ‘quantifying a join point’, also known by the term quantification, is performed based on pointcut specification, i.e. what conditions can be defined to select join points from a main program. In the context of business processes, join points, which are defined by activities or tasks in process models, often convey information about different perspectives of processes, and such information can be used in quantification. For example, the Transfer Money task in the Transfer Money processes in Fig. 2 may carry information about the transfer amount (process data perspective), the person or the system who performs the task (process resource perspective), the time the task is scheduled or actually occurs (process time perspective). When referring to an activity, quantification often uses the activity name and specifies conditions (for different perspectives) based on which the relevant actions should be performed2 . In Fig. 2, the statements above each of the advices, Archive and Confirm, are simplified examples of quantification which refer to only the activity name and/or process name (and conditions are omitted in the examples). 2

We adopt this common approach in our paper.

2.2 Formal abstract syntax Now we formally define an abstract syntax for business process models extended with the aspect-oriented considerations. An abstract syntax is independent of any specific language or system. Firstly we specify a business process model in general. Definition 1 (Business process model) A business process model P can be defined as a tuple (T , C, CI , CE , X , F, L, D, R, Name, Dat, Act) where – – – – – –

– – – – – –

T is a set of tasks. C is a set of conditions. CI ⊂ C is a set of initial conditions. CE ⊂ C is a set of end conditions. X is a set of routing constructs. F ⊆ (C\CE × (T ∪ X )) ∪ ((T ∪ X ) × C\CI ) ∪ ((T ∪ X ) × (T ∪ X )) is the flow relation, such that every node in the graph (T ∪ C ∪ X , F) is on a direct path from an initial condition i ∈ CI to an end condition e ∈ CE . L is a set of task labels. D is a set of data objects. R is a set of (human resource) roles. Name : T → L assigns a label to a task. Dat : T 9 D associates a data object with a task, Act : T 9 2R designates one or multiple roles to a task (that requires user interaction). t u

Next, an advice process is a special business process that contains at least one PROCEED task. There are three types of advice processes, which capture the ‘before’, ‘after’, and ‘around’ advices. Definition 2 (Advice process) An advice process P a can be specified by a business process model (T , C, CI , CE X , F, L, D, R, Name, Dat, Act) in which ∃t∈T Name(t) = ‘PROCEED’ (where ‘PROCEED’ ∈ L is a preserved label for PROCEED tasks). Let PA be a set of advice processes and AN a set of advice names, Advice : PA → AN assigns to each advice process an advice name, and Type : PA →{‘before’, ‘after’, ‘around’ } specifies when an advice process can occur given the associated join point. t u An aspect specification comprises a number of advice processes belonging to the same aspect and a set of (pointcut) rules specifying when these advices are expected to be used by the relevant business processes. Definition 3 (Aspect specification) Let PA be a set of advice processes, Q a set of business processes, and TP the set of tasks in each P ∈ Q, an aspect specification S can be defined as a tuple (A, Pointcut) where

Supporting aspect orientation in business process management A

– A ∈ 2(P ) isSa number of advice processes. – Pointcut: ( P∈Q TP ) × BoolExpr 9 A defines a set of predicates that relate a specific task (which is called an advised join point), under a given condition (from the set of boolean expressions BoolExpr ), to the corresponding advice process in A. Let S be a set of aspect specifications and SN a set of aspect names, Aspect : S → SN assigns to each aspect specification an aspect name. t u An aspect-oriented business process model is composed of a main process and a number of relevant aspects. The main process contains advised join point tasks, which are associated with the relevant advice processes according to specific pointcut rules, and has no PROCEED task. Definition 4 (Aspect-oriented business process model) An aspect-oriented business process W is a tuple (P, TA , S) where – P is a business process model that captures the coreconcern, where given the set of tasks T of process P, ¬∃ t ∈ T such that Name(t) = ‘PROCEED’. – TA ⊆ T is the set of advised join points. – S is a set of aspect specifications. – ∀ t ∈ TA , ∃ S ∈ S and ∃ c ∈ BoolExpr such that (t, c) ∈ dom(Pointcut). t u Note that in the above syntax definitions, relevant concepts of aspect orientation are defined in the context of business processes. Instead of a standalone definition of join point model, this concept is specified across both Definitions 3 and 4. Discussion. The purpose of defining a formal abstract syntax of aspect-oriented business process models is three-fold. Firstly, it provides a sound basis for developing a concrete syntax for modelling aspect-oriented business processes, which can be an extension to an existing business process modelling notation such as BPMN3 or YAWL4 . For example, if using YAWL, XPath is the concrete language for quantification (see the case study depicted in Fig. 16). Secondly, it serves as a standard reference during the development of an operational semantics of aspectoriented business process. For example, it is used as a reference to the modelling of the data structure of a pointcut specification (see a selected example of the operational semantics model shown in Fig. 9). 3 BPMN stands for Business Process Model and Notation (http://www.bpmn.org/). 4 YAWL stands for Yet Another Workflow Language (http://www.yawlfoundation.org/)

5

Thirdly, it is an essential step towards the definition of a formal semantics of aspect-oriented business process models to support design-time analysis of the processes such as checking their behavioural correctness (also known as soundness verification [3]). As designtime verification of aspect-oriented business processes is an individual topic by itself, and it is beyond the scope of the paper, we will not discuss this further.

3 Weaving of Aspect-Oriented Business Process Models To go beyond modelling of aspect-oriented business processes, it is necessary to define how cross-cutting concerns and core processes interact with each other during process execution. This sections defines an operational semantics for executing aspect-oriented business process models.

3.1 Static vs dynamic weaving In the domain of Aspect-Oriented Programming (AOP), the process of composing the core concerns with crosscutting concerns is called weaving. The weaving can be performed in two different ways, static weaving (a.k.a. design-time weaving), which refers to the merging of core concerns and cross-cutting concerns at design time, and dynamic weaving (a.k.a. runtime weaving), which refers to uniting these pieces at runtime. We adopt the above notion of weaving in our approach to support the execution of aspect-oriented process models. For static weaving, the main process model is expected to be firstly merged with its associated advice process models at design time. The merged model, called woven model, is then deployed in a Workflow Management System (WfMS) as one integral process model. For dynamic weaving, the main process model is executed in a WfMS on its own and the relevant advice process models are deployed, when necessary, during the execution of the main process at run time. Each of these two weaving mechanisms has its advantages and drawbacks. Static weaving produces wellformed code since the code is generated at design time and can be optimized by compilers prior to execution. Also, it does not require evaluation of join points at runtime, thus reducing the runtime overhead. However, the main disadvantage of static weaving is the lack of flexibility support. It assumes that all concerns are known at design time. If a concern changes, the compiled program has to be stopped, recompiled and re-deployed. Dynamic weaving provides more flexibility in adapting changes by supporting late binding of advices and

6

process models at runtime [39]. This approach requires (comparably) more computation at runtime, but it can cope with changes at run time without interrupting the running process instances. In the BPM area, the advantages listed for static weaving are not expected to be significant. Process optimization is mostly driven by business needs and not by the WfMS implementing the processes. Business process instances run often through a long period of time. The time taken for the evaluation of the pointcuts is insignificant in the context of the long life span of the process instances. The drawback on flexibility support in static weaving, however, is a serious disadvantage. As business processes’ instances run over long period of time, the impact of updating and re-deploying a process will be significant and most luckily require transition planning for the process’ changes and migration planning for the process instances. Dynamic weaving, on the other hand, offers support for such flexibility. The runtime weaving of aspects to core processes enables gradual development and change of aspects, which can be done independently from the development and evolution of the core processes. An advice can easily be added to an already deployed and running process. Such change does not demand re-deployment of a running process, but only the deployment of a newly defined advice. This means that aspects do not need to be known beforehand [41], and changes and additions can be applied on-the-fly. This feature is essential in adapting business processes during their deployment, where changes in the crosscutting concerns are expected to occur frequently. Based on the arguments above, we choose to implement the dynamic weaving strategy as our preference for the weaving of aspects. Although this strategy has been studied in a few areas such as programming [40,41] and service composition [12], it is still new and yet to be investigated in the area of BPM.

3.2 Overview of the solution The binding in dynamic weaving needs to be supported by an information system, called weaver. In order to describe the operational semantics of such a weaver, Fig. 3 depicts an abstract example for a process model (p1) with three advices. This process has three tasks (A, B and C), where task B is related to three advices (a1, a2 and a3). a1 is an around advice, a2 is an after advice, and a3 is a before advice. The weaver should enforce the correct execution order of tasks. In this example, task A should be followed by a set of tasks in related advices, which should be

A. Jalali et al.

p1

A

1

a1 a2 a3

B

C

D PROCEED

G

4

3

2 PROCEED

F

A

E

Result

PROCEED Legend:

Fig. 3 Dynamic weaving of aspects

executed before the advised join point. This set includes all tasks in advices which are positioned before the PROCEED placeholder, i.e. tasks D and G. The PROCEED holds the place of task B in this example, so this task should be executed next. Tasks in advices which are positioned after PROCEED placeholders, E and F , should follow task B. Finally, task C in the main process should be executed. Using regular expression this can be written as A(D||G)B(E||F )C. The weaving process contains two activities, called join point selection and advice injection [20]. The first activity selects advised join points by evaluating all join points. The second activity imposes advices in appropriate places regarding the advised join point, i.e. before, after or around it. In this example, all tasks shall be evaluated in join point selection. The result of evaluation is task B, which has three advices. In dynamic weaving, the advice injection activity can be performed in four steps [29,30], namely Launching, Pausing, Resuming and Finalizing: 1 Launching: the weaver launches and enforces the enactment of all valid advices before the enactment of their associated advised join point. Each valid advice is determined by the weaver through join point selection. 2 Pausing: the weaver pauses the enactment of an advice when reaching the PROCEED placeholder. It also enables the enactment of the corresponding advised join point, when all PROCEED placeholders are reached. 3 Resuming: the weaver enforces the enactment of the rest of advices after enacting the advised join point. It also pauses enactment of the rest of the main process. 4 Finalizing: the weaver enables the enactment of the rest of the main process when all advices are completed.

Supporting aspect orientation in business process management

During all these steps, the data is also synchronized between the main process and its advices. These steps require a complex interaction between the weaver and the enactment engine. An overview of interaction points between the weaver and the enactment engine is given in the following section.

7

between Active and Suspended states in a task instance enables the weaver to enforce the correct execution order between advices and the core process.

Suspended Restart

3.3 Dynamic weaving in Workflow Reference Model We adopt the Workflow Reference Model [23] which describes the major functional components, interfaces and information interchange flows of a general Workflow Management System (WfMS). Fig. 4 shows the major components and interfaces of a general WfMS. Interfaces are drawn around each component. The Workflow API and Interchange formats is a layer, which acts as a unified service interface supporting functionalities for other interfaces to work with Workflow Enactment Service.

Suspend / Resume Initiate

Running

Terminated Iterate through all active activities Active

Restart (1 or more activity instances) Complete

Fig. 5 Workflow Reference Model - Example state transitions for a process instance (taken from [23])

Suspended Suspend / Resume Start

Process Definition Tools

Start

Initiated

Terminate / Abort

Inactive

Active

Completed

(has Work Item)

Interface 1 Workflow API and Interchange formats Interface 5

Workflow Enactment Service

Administration & Monitoring Tools

Workflow Engine(s)

Interface 2 Workflow Client Applications

Interface 4 Other Workflow Enactment Service(s) Workflow Engine(s)

Interface 3 Invoked Applications

Fig. 4 Workflow Reference Model - Components & Interfaces (taken from [23])

The Workflow Enactment Service is responsible for managing and executing workflow instances. In our case, this service manages and executes all main processes and related advices. The Workflow Engine provides a runtime environment for a workflow instance. It is responsible for interpreting a process instance, controlling its state, managing tasks execution, managing data, executing supervisory actions for controlling processes etc. A process instance can have different states, and they are varied in different systems. A basic state transition of a process instance has Initiated, Running, Suspended, Active, Terminated and Complete states [23] (see Fig. 5). Moreover, a task instance can have different states. Such states are general in different systems like Inactive, Suspended, Active (also named /Started [45] or /Running [55]) and Completed [23] (see Fig. 6). The ability to move between Running, Suspended and Active states in a process instance and

Fig. 6 Workflow Reference Model - Example state transitions for a task instance (taken from [23])

It is important to know the state of the task instance in which the weaver can perform the quantification. The quantification should be performed when the task instance is Active for the following two reasons. Firstly, the information about the task instance is not available before the corresponding work item is created, i.e. in the Active state of the task instance. For example, the task instance might be offered to several people, and it is not known who will perform the task until it gets started. Secondly, the process might contain deferred choice, i.e. “A point in a process where one of the several branches is chosen based on interaction with the operating environment”5 . Examples of such pattern are demonstrated in Fig. 7 for both BPMN and YAWL notations. In this example, task Checkout can be followed

Pay by credit card

Checkout

Pay by credit card

Checkout Pay by Paypal

Payment scenario in BPMN

Pay by Paypal Payment scenario in YAWL

Fig. 7 Deferred Choice Example 5

http://www.workflowpatterns.com/

8

A. Jalali et al. Inactive Start

resume Created

Inactive

Suspended

Created

suspend Suspended forward

suspend Ready

Ready Reserved

Ready

Error

Reserved

Exited

resume

Offered to a single resource

suspend

Allocated to a single resource

start

resume delegate

Offered to multiple resources

(has Work Item)

suspend In Progress

In Progress

Obsolete

Active

Failed

Started

resume

resume

Suspended

suspend

Completed

Failed

Completed

Completed

Closed

WS-HumanTask Lifecycle

WfMC Task Instance Lifecycle

YAWL Workitem Lifecycle

Fig. 8 Comparing Workitem Lifecycles in different approaches (adopted from [46])

by Pay by credit card or Pay by Paypal. However, it is not known if the customer is to pay by credit card or paypal in advance, so an instance of each task is created at runtime. As soon as the customer chooses to pay by credit card or paypal instance, the other instance will be deleted by the system. Imagine that we need an advice to be considered before Pay by credit card, the weaving cannot be performed when the instance is created since we are not sure about the customer’s choice at that moment. To choose the weaving point, we consider the Workflow Reference Model’s Task Instance Lifecycle. We map this lifecycle to WS-HumanTask and Workflow Resource Pattern Lifecycles, respectively. Fig. 8 illustrates the two mappings. The WS-HumanTask Lifecycle attempts to provide a series of extensions to WS-BPEL 2.0 to support human involvement in the execution of business processes [43]. The Workflow Resource Pattern Lifecycle, as realised in the YAWL Workitem Lifecycle, has the same aims. Next, the weaver can be considered as a Workflow Client Application that interacts with the Workflow Enactment Service through Interface 2. It should perform both join point selection and advice injection. To select join points, changes in the task instances and process instances should be monitored by the weaver. The weaver, as a Workflow Client Application, is notified about state change in instances of process or tasks using Interface 2. To inject aspects, the weaver needs to follow four weaving steps, i.e. Launching, Pausing, Resuming and Finalizing. In Launching, the weaver needs to suspend the advised join point and create and

start advices (as process instances). It should also instantiate the process using the main process data. In Pausing, the weaver needs to pause advices and update the data of advised join point using advices’ data. It should also resume the advised join point. In Resuming, the weaver needs to suspend the main process and update the data of advices using the main process data. The advices should also be resumed. In Finalizing, the weaver needs to update the data of the main process using advices’ data. The main process’ state should also be changed to Active. All of these functionalities are available through Interface 2. The weaving requires a number of interactions between the weaver (as a Workflow Client Application) and the Workflow Enactment Service. These interactions may be concurrent since multiple instances can be performed simultaneously. The resulting behaviour is complex, and to model such behaviour precisely, we decided to use a formal modelling language. 3.4 Operational Semantics of the Weaving Behaviour The weaver can be defined as an application which communicates with the enactment service to select join points and inject advices. The semantics of this application should consider complex issues like concurrency, communication and synchronization. For the definition of the formal semantics we have chosen the Coloured Petri Nets (CPN) [31]. CPN were selected because it has a supporting environment where models can be designed, executed, simulated and verified. This environment is called CPN Tools [31].

Supporting aspect orientation in business process management

9

[isProceed=false, isValidJP(s,tList)] matchPointcut

(i, getTreeAspect((s, t, setAspectConstraint(pre)), tList), d)

pointcutRetrieved

tList

selectPointcut

IDxTREExDATA

(c, i, getAspectType((s, t, setAspectConstraint(pre)))) (c, id, aType)

notFulfilled

((s, c, t, i, d), cd, pre, isProceed)

selectPointcut

(id, [], d)

handler IDxEXLETxDATA

pointcutSpec

workitemConstraint

TREELIST

evITEMCONSTRAINT

saveAspectInfo CASEIDxITEMIDxASPECTTYPE

tList

[isValidCase(s, tList)] ((s, c, t, i, d), cd, pre, isProceed)

[pre=true, isProceed=true] isProceedCmd

(s, c, d, false)

endAdvice

caseConstraint evCASECONSTRAINT

(c, d)

if aType=postAspect then 1`(id, d) else empty

completedAdvice CASExDATA

AdvisedJP

CASEIDxITEMIDxDATA

weaveAspect weaveAspect

[xlt!=[]] enableAspect

ITEMIDxDATA

(c, i, d) Proceed

(id, xlt, d)

(c, id, aType)

if aType=preAspect then 1` (c, id, xlt, d) else empty

AspectInfo

CASEIDxITEMIDxEXLETxDATA

Fig. 9 Join point selection process

As mentioned earlier, the semantics of the weaver contains two parts, i.e. join point selection and advice Injection. Fig. 9 shows the join point selection process. The process gets activated when the weaver receives a notification from the enactment service. The notification indicates a change in a state of an instance of a task or a process, called workitem and case correspondingly, using Interface 2. These notifications are simulated in the net using tokens, and their occurrences change the state of the weaver. The states which show receiving of these notifications are visualized using two places called, workitemConstraint and caseConstraint. The raising of one of the notifications is signified in the CPN model in Fig. 9 as a token arriving in the workitemConstraint or caseConstraint places correspondingly. In other words, these places are the starting points of the net. As it can be seen in Fig. 9, the service recognizes whether the WorkitemConstraint is related to a task or to a Proceed placeholder (see the matchPointcut and isProceedCmd transitions). The weaver performs the quantification at runtime based on the name of the process, task and conditions that are composed using XPath for data perspective. If the received WorkitemConstraint belongs to a task, the matchPointcut investigates whether a pointcut is defined for the task. This part checks the process name and task name of the pointcut. Next, the quantification part of the pointcut is evaluated to determine which advices should be launched using subnet selectPointcut. The quantification is based on XPath over the data perspective. The result of the evaluation is a set of ad-

AspectInfo In

CASEIDxITEMIDxEXLETxDATA

completedAdvice In CASExDATA

Launching

Finalizing Finalizing

Launching

ICore COREMSG

Core Pausing

Core

Resuming Resuming

Pausing

Proceed In

AdvisedJP CASEIDxITEMIDxDATA

In

ITEMIDxDATA

Fig. 10 Advice injection process

vices that should be imposed. If the set is empty, the notFulfilled transition is enabled, otherwise, transition enableAspect is enabled. The result leads to the Launching step if the advised join point is started (the enableAspect transition produces a token in place AspectInfo). However, if the advised join point is completed, Resuming should be started (the enableAspect transition produces a token in place AdvisedJP). If it is a Proceed placeholder, no Pointcut is needed to be checked (the isProceedCmd transition produces a token in Proceed place). As a result, the Pausing can be started. The Finalizing can be started if all advices are finished. This condition is checked using endAdvice transition, which produces a token in completedAdvice place if a token representing the end of a launched advice appears in caseConstraint.

10

The net in Fig. 9 shows how join points are selected in order to enable advice injection. The semantics of advice injection is defined in the weaveAspect subnet shown in Fig. 10. The weaveAspect net contains five subnets: Launching, Pausing, Resuming, Finalizing and Core. The first four subnets describe the semantics of the four weaving steps, and the last one describes the communications between the service and enactment engine. It also describes when and what sort of data should be persisted between weaving steps. Many variables are defined in this net among which s refers to a specification, c refers to a case, t refers to a task, i refers to a workitem, d refers to a workitem data, cd refers to a case date, pre determines if the event happens before or after the workitem, and isProceed indicates if the task is a proceed placeholder. The CPN model allowed us to verify the design of the weaver using state space analysis. This analysis showed that the nets were free of deadlocks. Moreover, the Strongly Connected Component (SCC) graph of the model has the same number of nodes and arcs as the corresponding state space. This indicates that there is no cycle in the CPN model, which is expected since the weaving process taken into account within the scope of current work is free of cycles6 . The model contains 57 colour sets and 33 functions. Some of the colour sets, variables and functions are reused from the Worklet Service CPN model [4].

A. Jalali et al.

YAWL Workflow Engine

A YAWL Editor

R

A

B

A

B

X

B

R Resource Service

Aspect Service

O

Admin

worklist

X

Event Log

Organizational Model Pointcut Repository

Process Repository

Advice Repository

Users

Pointcut Editor

Fig. 11 System Architecture

Fig. 12 shows how a task can be defined as a PROCEED placeholder when designing an advice, where the user can set the YAWL Registered Service Detail option to Proceed.

4 Implementation The defined semantics was used as a blueprint for implementing the weaver service, called ‘Aspect Service‘. Fig. 11 shows the architecture of the whole system. At design time, the user can define Aspect-Oriented Business Process Models by specifying the core concern, cross-cutting concerns and pointcuts. The user can model the core concern and cross-cutting concerns through YAWL Editor. Core concerns and cross-cutting concerns models are stored in the Process Repository and Advice Repository respectively. The user can also define the pointcuts using the Pointcut Editor. This editor stores pointcuts in the Pointcut Repository. To define the cross-cutting concerns, the functionality of YAWL Editor is extended by registering the Aspect Service in the YAWL Workflow Engine to support definition of PROCEED tasks for advices. This extension is supported as the result of communication between the editor and the engine through Interface A. 6 Full details of the model and the results of simulation and state space analysis are publicly available and can be downloaded from http://www.aobpm.com

Fig. 12 Proceed decomposition in YAWL

To define the pointcuts, the Pointcut Editor is implemented. As it can be seen in the architecture (Fig. 11), this editor enables definitions of rules that specify what advice should be considered for what process models (see connections to Process and Advice Repositories). The result is written into Pointcut Repository.

Supporting aspect orientation in business process management

Fig. 13 shows a screenshot of the Pointcut Editor. In this figure, two advices are defined for the Deal Aspect, i.e. Deal For Speculation Advice and Change Asset Deal Advice. When a user starts to Make a Deal, the pointcut condition DealType=‘CAD’ indicates that the Advice should be triggered when the type of the deal is Change Asset Deal (CAD). The pointuct rules are specified through XPath and are interpreted by the Aspect Service at runtime.

Fig. 13 Pointcut Editor

At runtime, YAWL Workflow Engine is responsible for enacting core and cross-cutting concerns. This part is equivalent to the Workflow Enactment Service in the Workflow Reference Model (Fig. 4). The Resource Service (Fig. 11) supports functionalities of two components, the Workflow Client Applications and the Administration & Monitoring Tools, in the Workflow Reference Model. The worklist generates forms via which a user can fill information and take appropriate actions. Moreover, the designer can develop its own custom form if needed. The administration support is provided through the Admin user interface, and the user interactions is supported through the worklist interface. The Resource Service authorizes users based on the definitions in the Organizational Model. During the runtime, the Aspect service interprets the pointcuts and weaves the advices and the main process. The service has access to the Advice Repository and uploads the advice specifications that have not yet been used. It does not have a user interface, since its role is to automatically select and inject advices into appropriate places.

11

5 Case Study A banking case study was selected because a variety of cross-cutting policies are applied in the financial domain. To choose appropriate processes, i.e. simple yet representative examples, an interview was conducted with a domain expert from a bank. From the interview it was learned that the deal processes in the bank, which generally are not too complicated, can be good candidates for our case study. While these processes share a similar flow of main activities, different concerns shape different variants of the processes. As a result, two examples of deal processes were selected, which are Deal For Speculation process and Change Asset Deal process. The goal of the former is to make a profit and the latter is about converting some of the bank’s asset from one currency to another. Three groups of cross-cutting concerns were recognized in the above processes, namely Deal Concerns, DealSlip Concerns and SWIFT Concerns. The first two concerns are specific to deal processes, whereas the last group of concerns are also associated with other processes that handle SWIFT messages in the bank. In order to study how SWIFT concerns are considered in other business processes in the bank, we conducted an interview with another domain expert, from whom we learned that the processes concerned with Letter of Credit (LC) also involve sending and receiving SWIFT Messages. Three different LC processes exist in the bank, which relate to issuing, negotiating, and making payment for LC. Among these we selected the Issue LC process due to its simplicity but being sufficient for the purpose of our case study. After we had decided on the three processes to use for the case study, we conducted follow-up interviews with the domain experts to obtain necessary details about the processes.

5.1 AS-IS process models The three selected processes (i.e. Change Asset Deal, Deal For Speculation, and Issue LC ) were firstly modelled in a traditional way, i.e. without considering aspectorientation. Fig. 14 depicts the three process models in the YAWL notation, where three cross-cutting concerns (i.e. Deal, DealSlip, and SWIFT Concerns) are annotated across these models. 5.1.1 Deal processes Change Asset Deal and Deal For Speculation are two examples of the deal processes. Both have a very similar flow of activities but are different in how Deal Concerns

Fig. 14 AS-IS process models of deal and issuing LC processes

Issue LC

Junior Dealer

Clerk

Register Order

Deal For Speculation

Make a Request

Back Office

Change Asset Deal

Assign the Work

Chief Dealer

Confirm

General Manager

Exchange Money

automated

Amount > ChiefDealer.Limit

Chief Dealer

Amount