Change Propagation in Collaborative Processes Scenarios Walid Fdhila, Stefanie Rinderle-Ma University of Vienna, Austria, Faculty of Computer Science {walid.fdhila, stefanie.rinderle-ma}@univie.ac.at
Abstract—Process flexibility and change constitute major challenges for process-aware information systems. This does not only hold for centralized process scenarios, but also for collaborative ones involving multiple distributed and autonomous partners. If one partner adapts its private process, the applied change might affect the processes of the other partners as well. Hence the change must be propagated to concerned partners in a transitive way. A fundamental challenge is then to find ways of propagating the changes in a decentralized manner. Existing approaches dealing with changes of collaborative processes are limited with respect to the change operations considered and their dependency on certain process specification languages. By contrast, this paper presents a generic change propagation approach based on the Refined Process Structure Tree. Our approach is applicable independently of a particular process specification language. Further, it considers a comprehensive set of change patterns. Finally, it is shown that the provided change propagation algorithms preserve structural dependencies for any change pattern.
I. I NTRODUCTION Process flexibility and change have been identified as major challenges in process management research for more than a decade [1], [2], [3]. Driving forces necessitating the adaptation and evolution of implemented processes include, for example, changes in law, exceptional situations, and process optimization. Change support is not only crucial for centralized processes (i.e., processes running entirely within one organization), but also for collaborative process scenarios involving multiple partners [4]. Typically, these partners run their own private processes and provide public views on them (i.e., local choreography models) to partners. Based on these public views, a global choreography can be formed by exchanging messages in a controlled manner in order achieve some common goal. A characteristic example of a collaborative processes is a supply chain consisting of the three partners customer, producer, and supplier [4]. Based on their internal or private processes, these partners provide local choreography models to the outside communicating through interactions. Centralized processes pose many challenges when changes have to be applied to them. Existing approaches have focused on aspects such as correctness of change [2], change reuse The work presented in this paper has been conducted within the project I743 funded by the Austrian Science Fund (FWF) and by the Deutsche Forschungsgemeinschaft (DFG).
Manfred Reichert University of Ulm, Germany, Institute of Databases and Information Systems
[email protected]
[5], and performance [6]. The same challenges hold for collaborative process scenarios. In fact, changes of collaborative processes are by far more difficult to handle due to the non-availability of the information required to perform, for example, correctness checks. Specifically due to the absence of a central coordinator, such as assumed in previous work [7], information on the partners’ private processes is not available to others aggravating the correct application of process changes. For example, assume a collaborative supply chain scenario as outlined above. Let further a change become necessary at the supplier’s side due an emerging internal policy and assume that an additional notification message is required from the producer and - in the sequel - from the customer. This change would be first applied to the supplier’s internal process. However, since the change affects both partners, it has to be propagated to the respective partner processes as well. In turn, this change propagation raises challenging issues: (a) Which information must be propagated to partners? (b) How to adapt the local choreographies in order to comply with the change? (c) How to adapt the partners’ private processes? (d) How to maintain correctness and consistency of the global choreography as well as compatibility of the local choreography models among each other? So far, only few approaches have addressed these challenges [4]. All these approaches are restricted with respect to the formal specification language used and the set of change operations considered. Furthermore, only the effects on direct partners have been investigated so far, factoring out issues such as transitive changes as well as issues related to the compatibility of the local choreography models as well as the consistency of the global choreography after change propagation. In this paper, we tackle change propagation in collaborative process scenarios in a more holistic way. First of all, we base our considerations on the Refined Process Structure Tree (RPST) [9]. RPST provides a process representation that is independent of any specific process specification language on the one side and enables us to formally specify and propagate changes on the other side. Regarding process changes, we investigated wellknown process change patterns [10] and provide propagation algorithms for the most common change operations such as insert, delete or replace process fragments, and – at a more semantic level – update of, for example, input/output parameters. All considered change patterns operate on process
Book Trip Operation.bpmn
Acquirer
TravelAgency
TravelAgency failure not ificat ion
credit card not approved
TravelAgency
Traveler
Fail
n
Traveler
Acquirer
Airline
Airline failure not ificat ion
t icket purshase cancelled
Airline
Traveler
TravelAgency Airline
book reserve
Acq u i r er
Tr avel Ag en cy
check and cash
n o t i f i cat e f ai l u r e
cr ed i t car d n o t ap p r o ved
Tr avel Ag en cy
Tr avel er
TravelAgency
Acquirer
Acq u i r er
Book Trip Operation Fai l
b o o k r eser ve
ch eck an d cash
Tr avel Ag en cy
Acq u i r er
Airline Operation.bpmn
Airline
Tr avel Ag en cy Ai r l i n e
Tr avel er
Tr avel Ag en cy f ai l u r e n o t i f i cat i o n
Tr avel Ag en cy
paym ent ok
Ai r l i n e t i ck et p u r sh ase Book Trip can cel l ed
n o t i f i cat i o n f ai l u r e
Acq u i r er
Tr avel er
t icket TravelAgency
Acquirer
Ok
cr ed i t car d n o t ap p r o ved
Tr avel Ag en cy
Tr avel Ag en cy
cr ed i t carTravelAgency d not ap p r o ved
n o t i f i cat e f ai l u r e
Tr avel er
Ai r l i n e Tr avel Ag en cy
t i ck et Ok
Acq u i r er
Tr avel Ag enu cy Acq i r er
Ai r l i n e
t ot al value
Tr avel er
Acquirer
Traveler
Ai r l i n e
Acq u i r er
Ai r l i n e f ai l u r ep aym en t o k n o t i f i cat i o n
Fai l
TravelAgency
Purchase confirm at ion
Acq u i r er
approval
Tr avel Ag en cy cr ed i t car d n ot ap p r oved
Tr avel Ag en cy
Tr avel er
Ai r l i n e
t i ck et p u r sh ase Fai can l cel l ed
n o t i f i cat i o n f ai l u r e
t i ck et p u r sh ase can cel l ed
Tr avel er
Ai r l i n e
Tr avel er
Ai r l i n e
Acq u i r er Tr avel Ag en cy f ai l u r e n ot i f i cat i on
TravelAgency
interaction
Ai r l i n e
Tr avel Ag en cy
ch eck an d cash
Tr avel er
Tr avel Ag en cy
b o o k r eser ve
ch eck an d cash
Tr avel Ag en cy
Acq u i r er
Tr avel Ag en cy
AND-split/join
Pu r ch ase co n f i r m at i o n
Ai r l i n e
XOR-split/join
Fig. 1.
p aym en t o k
Interaction
Ai r l i n e
Ai r l i n e f ai l u r e n ot i f i cat i on
t i ck et p u r sh ase can cel l ed
Ai r l i n e
Recei ver
Tr avel er
Tr avel Ag en cy
Tr avel Ag en cy
Acq u i r er
Ai r l i n e
Global Choreography: Book Trip Operation [8] p aym en t o k
ap p r o val
Ai r l i n e
b ook r eser ve
ch eck an d cash
Tr avel Ag en cy
Acq u i r er
t i ck et
Ai r l i n e
Tr avel Ag en cy
Ai r l i n e
Fai l
Ch o r eo g r ap h y t ask
Tr avel er
t i ck et
Tr avel er
Acq u i r er
Sen d er
t ot al val ue Message sent
Tr avel Ag en cy Ok
Tr avel Ag en cy
Acq u i r er
Ai r l i n e
t i ck et
Acq u i r er Ok
Message received
Acq u i r er
Tr avel AgOk en cy
Ai r l i n e
Tr avel Ag en cy
Acq u i r er
Pu r ch ase co n f i r m at i o n t o t al val u e
Pu r ch ase co n f i r m at i o n Trip Operation [] Global Choreography: Book Tr avel Ag en cy
Tr avel Ag en cy
ap p r o val
1 of 1
Fig. 2.
1 of 1
Airline
t i ck et p u r sh ase can cel l ed
cr ed i t car d not ap p r o ved
1 of 1
Traveler
walidus fd
t i ck et p u r sh ase can cel l ed
1 of 1
n o t i f i cat i o n f ai l u r e
book r eser ve
t o t al cr ed i t car dval u e
n o t ap p r o ved
walid fdhila
ch eck an d cash
t i ck et
n o t i f i cat i o n f ai l u r e
book r eser ve
cr ed i t car d n o t ap p r o ved
t ot al val u e
ch eck an d cash
t i ck et
ch eck an d cash
Acquirer
Travel Agency
Pu r sh ase co n f i r m at i o n
ap p r o val Pu r sh ase co n f i r m at i o n
ap p r o val
We illustrate change propagation issues along the booking Fig. 3. Book Trip Operation: Local Views trip choreography example depicted in Figure 1. This example is part of the choreography model described in [8]. It is modeled in BPMN 2.0 and describes a collaboration between four partners, i.e., traveler, travel agency, acquirer, and airline. The traveler sends booking information to the travel agency which, in turn, contacts the acquirer to request a credit check. If the traveler has not enough credit, failure notifications are sent to the travel agency and the airline partners which inform the traveler about the reservation failure and the purchase cancellation respectively. Otherwise, an approval is sent to the travel agency and the airline is triggered to send the ticket and the purchase confirmation. Figure 2 depicts the public views (i.e., local choreography models) of all participants involved in the choreography. Each partner view includes only the interactions in which this partner is involved as well as the control flow between them. Figure 2 does not show the private view (i.e., orchestration) of each partner that includes the internal activities. These local views merged together lead to the global choreography model. Now assume that partner acquirer wants to change the logic of its private process. For instance, instead of sending two failure notifications to airline and travel agency respectively, he notifies only one of them. In Figure 2, fragment F is replaced by fragment F 0 (XOR instead of AND). Then, for
07.05.2012
t i ck et
n o t i f i cat i o n f ai l u r e
p aym en t ok
t i ck et p u r ch ase can cel l ed
07.05.2012
walid fdhila
1 of 1
Pu r sh ase co n f i r m at i o n
t i ck et
07.08.2012
p aym en t ok
1 of 1
Pu r sh ase co n f i r m at i o n
n o t i f i cat i o n f ai l u r e
n o t i f i cat i o n f ai l u r e
n o t i f i cat i o n f ai l u r e
ch eck an d cash
ap p r o val
n o t i f i cat i o n f ai l u r e
p aym en t ok
ap p r o val
Book Trip Operation: Local Views
1 of 1
walidus fd
ap p r oval
Tr avel Ag en cy
t i ck et p u r ch ase can cel l ed
n o t i f i cat i o n f ai l u r e
Acquirer
II. M OTIVATION AND C HALLENGES
Fig. 3.
Tr avel Ag en cy
Acq u i r er
p aym en t ok
t o t al val u e
1 of 1
Ai r l i n e
Pu r ch ase con f i r m at i on
07.08.2012
Global Choreography: Book Trip Operation []
cr ed i t car d not ap p r o ved
collaboration
book r eser ve
Ai r l i n e
ap p r o val
Tr avel Ag en cy
Tr avel Ag en cy
t ot al val u e
Tr avel er
Acq u i r er
Tr avel er
Acq u i r er
walid fdhila
book r eser ve
p aym en t ok
Tr avel Ag en cy
some process instances, partner airline would wait indefinitely for a failure notification if the acquirer chooses to send a notification only to the travel agency. In this case, the acquirer process instance would be blocked in this state and not terminate. Hence, the described change affects the soundness of the choreography model in terms of compatibility between the distributed public views. To overcome this problem, the effects of this local change in the acquirer process model should be propagated to the concerned partners and the interactions should be restructured consequently. Generally, the challenges are as follows: How to compute the impacts of this local change on the other partners and the global choreography? How to propagate the effects of the local change while preserving the soundness of the collaboration in terms of consistency and compatibility [11]? How to deal with transitive effects of changes? What if changes are made dynamically, i.e. during the execution of choreography instances? How to manage the different versions of the choreography model (used in monitoring) and the participants’ processes at runtime?
t o t al val u e
Airline
Fig. 2.
fragments. The associated propagation algorithms are formally defined and illustrated based on a use case. Furthermore, we show that the change propagation results in compatible local choreography models as well as a consistent global choreography. Finally, we sketch the transition from the structural considerations provided in this paper to semantic issues and future challenges. In Sect. 2 the problem space is introduced, followed by fundamental definitions in Section 3. Section 4 provides the change propagation algorithms. Our approach is evaluated in Section 5. In Section 6 we discuss related work and Section 7 summarizes the paper.
08.05.2012
08.05.2012
III. P RELIMINARIES As emphasized, this paper deals with change propagation in collaborative processes. In practice, there are three different, but overlapping viewpoints in a collaboration: orchestration, behavioral interface, and choreography [12]. An orchestration describes the internal business logic of private processes as well as the communication actions in which a particular partner engages. The behavioral interface (also called public view or local choreography model) sketches the message exchanges from the perspective of a single partner as well as the sequencing between them. In other words, it represents an abstraction of an orchestration’s internal actions. The choreography (also called global model) gives a global view of all interactions in the collaboration. It captures the interactions in which the participating partners engage to achieve a goal as well as the dependencies between these interactions. In order to precisely define the notions of orchestration, behavioral interface and choreography, we
collaboration
Airline not if icat ion f ailure
t icket purshase cancelled
book reserve
Airline
Traveler
credit card not approved
Message ex change
t icket purchase cancelled
t icket
t ot al value
paym ent ok
Purshase conf irm at ion
TravelAgency not if icat ion f ailure
credit card not approved
Travel Agency
Fragm ent F book reserve
check and cash t icket
Airline not if icat ion f ailure
t ot al value
Acquirer
Purshase conf irm at ion
approval
TravelAgency not if icat ion f ailure
check and cash
paym ent ok
approval Airline not if icat ion f ailure
St ruct ural change REPLACE(F,F'): AND pat t ern replaced by XOR pat t ern TravelAgency not if icat ion f ailure
Fig. 2.
Fragm ent F'
Book Trip Operation: Local Views
walidus fd
1 of 1
need to adopt a model for representing control-flow relations between activities and interactions. In this paper, we adopt a structured representation of process models. In essence, a process model is represented as a tree whose leaves represent activities or interactions and whose internal nodes represent either sequence (SEQ), parallel (PAR), choice (CHC), or repeat loop (RPT) constructs. Structured process models are very close to BPEL. As an advantage they are simpler to analyze and easier to comprehend. Although it is possible to express unstructured models both when using BPEL and BPMN, recent work has shown that most unstructured process models can be automatically translated into structured ones [13]. Definition 1: [(Structured) Process Model] A process model
πp of partner p (private view) is a tree with the following structure (we use the type definition syntax of the ML language [14]): P rocess N ode Activity InteractionActivity
::= ::= ::= ::=
ControlN ode
::=
Event
::=
Node Activity|ControlNode|Event InternalActivity|InteractionActivity Send (Message, Destination) |Receive(Message, Sender ) SEQ([Node])|CHC ({Node}) |PAR({Node})|RPT (Node) Start |End
In this structuring of a process model, we consider an interaction activity one-to-many-send (respectively one-frommany-receive) as several interaction activities of type send (respectively receive) executed in parallel. We define a fragment as a non-empty subgraph of a process model with a single entry and a single exit edge. In Definitions 2 and 3, we
23.05.2012
refer to the same control nodes and events as in Definition 1. Definition 2: [Local Choreography Model] A local choreography model Lp of partner p states the external behavior of p and is also denoted public view. It includes the interactions with other partners as well as the constraints between them from the view point of this partner: LocalM odel N ode
::= Node ::= Send (Message, Destination) |Receive(Message, Sender ) |ControlNode|Event
Definition 3: [Global Choreography Model] The global choreography model G represents a global view of the interactions between collaborating partners. GlobalM odel N ode
::= Node ::= I (Source, Destination, Message) |ControlNode|Event
where I corresponds to interaction between the partners source and destination. We consider P as the set of all partners participating in the choreography, Π as the set of their process models, and L as the set of their local models. Figure 3 depicts the RPST model of the book trip operation’s global choreography model as presented in Figure 1. Leaves represent interactions and internal nodes represent the control flow patterns used. In order to support changes of collaborative processes, we consider basic change operations since more complex change patterns can be expressed by combining of these operations.
Acquirer
TravelAgency
Book Trip Operation Book Trip Operation not ificat e failure
Book Trip Operation Book Trip Operation
credit card not approved
TravelAgency
Traveler
Acquirer TravelAgency
Acquirer
TravelAgency credit card not
Acquirer Fail
notnot ificat e failure credit card approved Acquirer TravelAgency Acquirer TravelAgency Acquirer notificate failure TravelAgency TravelAgency approved
Acquirer
Airline
approved
cancelled
TravelAgency
TravelAgency
Book Trip Operation Airline
TravelAgency credit card notnot if icat e not fTraveler ailure ificat e failure approved
notcredit if icat ecard f ailure not TravelAgency
not ificat e failure t icket purshase
not ificat ion failure
Acquirer Acquirer
Traveler
TravelAgency
book reserve
check and cash
TravelAgency
Acquirer
Acquirer
seq
Fail
F1
book reserve TravelAgency
Ok
Book Trip Operation
Acquirer
Acquirer
Acquirer
F111
not ificat e failure TravelAgency
TravelAgency
Airline
1 of 1
credit card TravelAgency not approved
credit card
t icket purshase cancelled
not walidus fd
Airline walidus fd
t icket
approved Airline
walidus
book reserve
walidus fd
Traveler
Fig. 3.
Fig. 2.
Traveler
not if icat ion f ailure
cancelled
1 of 1
t ot al value
Book Trip Operation: Refined Process Structure Tree
approval TravelAgency
Change operations are defined as follows. not ificat ion failure
not if icat ion f ailure
credit card not approved
TravelAgency credit card not approved
credit card not approved
not if icat ion f ailure
walidus fd
Traveler
check and cash
Travel Agency
Travel Agency
book reserve
credit card check not andnot cash ificat ionapproved
book reserve
failure
credit card notification not approved t icket credit card failure book check not bookcash reserve and approved
credit card t icket not approved purshase cancelled 1 of 1
not ificat ion failure
Purshase paym ent okconf irm at ion
not ificat ion failure
Purshase confirm at ion
Purshase confirm ation
tPurshase icket purchase confirm at ion cancelled
not ificat ion failure
1 of 1
credit card not approved
t icket purchase not if icat ion cancelled f ailure ticket notification purchase failure cancelled
not ificat ion failure
credit card not approved
Airline
not if icat ion f ailure
Acquirer
paym ent ok
check and cash
Purshase confirmation
approval check and cash
not ificat ion failure
Purshase confirm at ion
Purshase confirm at ion
not ificat ion failure total value approval
approval
not ificat ion failure
paym ent ok
approval
not ificat ion failure
t ot al value
approval
notification failure
not ificat ion failure
check and cash
not ificat ion failure
check and cash
notification failure
paym ent ok
check and cash
not ificat ion failure
paym ent ok
08.05.2012
payment ok
not ificat ion failure
paym ent ok
08.05.2012
approval
t ot al value
approval
not ificat ion failure
approval
not ificat ion failure
paym ent ok
approval
t icket
paym ent ok
Acquirer
credit card not approved
paym ent ok
paym ent ok
approval
credit card not approved
Acquirer
not ificat ion failure
t ot al value
not ificat ion failure
Purshase confirm at ion
approval
ticket
t icket
not ificat ion failure paym ent ok
check notification and cash failure
Purshase confirmation approval
Acquirer
Purshase confirm at ion
and cash
07.05.2012
not ificat ion failure
not if icat ion f ailure
ticket check paym ent and cash ok
Acquirer
Airline
Airline
Acquirer
credit card not approved
paym ent ok
notification failure
t icket purchase payment cancelled ok Purshase confirm at ion check
Purshase confirm at ion
Purshase confirm at ion
t icket
check and cash
paym ent
check ok and cash
not ificat ion failure approval
not if icat ion f ailure
and cash
paym ent ok nottificat ot al ion failure not ificat ion value failure
value
t icket
approval
check and cash
approval
not ificat ion t ot al failure
Acquirer
approval
not ificat ion check failure
Airline
Travel Travel Agency Agency
Acquirer
notification check failure and cash
Acquirer
Travel Agency
Traveler
t icket
check confirm at ion and cashtotal approval value Purshase t icket confirm at ion
approval
t ot al value
t ot al value
Acquirer
book reserve
conf irm at ion
t icket
t icket check Purshase and cash confirm at ion
Acquirer
Travel Agency
book reserve
credit card not approved
book reserve
not ificat ion failure
t icket purchaset icket
t ot alcancelled value Purshase
approval
Acquirer
approval
paym ent
t ot al value paym ent check ok and cash
t icket
Purshase
Purshase
total confirm ation value
approvalok
t ot al value
Acquirer
Purshase confirm at ion
t icket purchase cancelled
Travel Agency
Travel Agency
t icket
Purshase confirm at ion
check and cash ticket
purshase cancelled approval
t ot al value
not ificat ion failure t icket
book credit card reserve not approved
check t ot alion and cash not ificat value failure
book reserve ticket
t icket purshase cancelled
credit card not approved
t icket
book reserve t ot al value
credit card Purshase notconfirm at ion approved not ificat ion failure
Travel Agency
Travel Agency
check and cash
check and cash
t value
Airline
book reserve
not ificat ion failure
book reserve
book
approval
t ot al value
not ificat ion failure
reserve
Purshase reserve conf irm at ion
t icket check book reserve purshase and cash t icket cancelled ot al
Airline
approval
t icket purshase cancelled
book reserve
Travel Agency
Traveler
Travel Agency
confirm at ion
t ot al value
book reserve
t icket
check and cash book reserve Purshase
t icket purshase cancelled
book reserve
credit card not approved
book reserve
Traveler
Traveler
07.05.2012 between the considerations provided in thiscollaboration paperwalidus to fdsemantic issues and 1 of 1the choreography model in terms of compatibility walidus fd 10.05.2012 walidus fd 1 of 1 • send(message, p0)= receive(message, p).07.05.2012 ChangeP attern ::= Structural | Semantical distributed public views. To overcome this problem, the effects future challenges. as well walidus as afd consistent global chore- process instance would be blocked in this state and not ter1 of 1 07.05.2012 of this newFragment) local change thesoundness process model should 2 the Structural problem is introduced, bydescribed •acquirer receive(message, p0)= send(message, p). sketch IntheSect. transition from the space structural minate. followed Hence, the change affectsinthe of ::= REPLACE (oldFragment, beinpropagated to the concerned partners and the interactions in issues Sectionand 3. 1Section 4 provides the the choreography model terms of compatibility between the ed infundamental this paper definitions to semantic of |DELETE 1 10.05.2012 (fragment) If F is a fragment that solely includes07.05.2012 interaction activities, 1 ofconsequently. 1 be restructured change propagation algorithms.walidus Ourfd1 ofapproach is evaluated in should 1 07.05.2012the effects distributed public views. To overcome this problem, F corresponds to a fragment with same structure where each |INSERT (fragment, how , in, out) Section 5. In Section 6 we discuss related work and Sections Generally, the challenges are as follows: How to compute blem space is introduced, followed by of this local change in the acquirer process model should activity is replaced by and its complement. summarizes the paper. the impactspartners of this local on the other partners the how ::= | Choice Sequence bearallel propagated to the |concerned and change the interactions ns in7 Section 3. Section 4 provides the P Fig. 3. Book Trip Operation: Local Views choreography? How to propagate the effects of the local should be restructured global consequently. lgorithms. Our approach is evaluated in UPDATE newValue) Fig. 3. Book Trip Operation: Local Views II. Semantical M OTIVATION AND::= C HALLENGES (activity, attribute, changeare while preserving the soundness of the collaboration in Fig. 3.challenges Book Trip Operation: Local Views How Lemma 6 we discuss related work and Sections Generally, the as follows: to compute 1: abstr ∈Local L =⇒ abstrp0 (F) ∈ p0 (F) p attribute ::=issues partner |the role|Input|Output Fig. 3. How Book Trip Operation: Views terms of consistency and compatibility [11]? to deal with We illustrate change propagation along booking Fig. 3. Book Trip Operation: Local Views and the er. the impacts of this local change on the other Fig. partners 3. Book Trip Operation: Local Views abstr (L ) p p0 transitive effects of changes? What if changes are made dytrip choreography depicted inwalidus Figure The latter is Howwith fd 1 of 1 08.05.2012 global choreography? to propagate the effects of the local Fig. 3. Book Trip Operation: Local Views whereexample REPLACE replaces an 1.existing fragment a new one, The complement of the abstraction of a participant fragment namically, i.e. during the the execution of choreography instances? part of theCDELETE choreography in [8]. It iswalidus modVATION AND HALLENGES example described fd 1 of 1 change while preserving the soundness removes an existing fragment, INSERT adds a of new collaboration in How1 ofto1 manage the different of the choreography eled in BPMN 2.0 andinto describes a collaboration between four F to∈versions Lpwith according to participant p0 is a fragment of the fd 08.05.2012 terms of consistency andout, compatibility [11]? How deal fragment thebooking process model between in and and UPDATE e propagation walidus issues along the walidus fd 1 of 1 model (used in monitoring) and the participants’ processes at to p. 08.05.2012 walidus fd 1 of 1 partners, i.e., traveler, travel agency, acquirer, and airline. The of Lp0 according transitive effects of changes? What if changes abstraction are made 1dyactivity. walidus fd of 1 08.05.2012 mple depicted modifies in Figure an 1. attribute The latterofis a single runtime? fd 1 of 1 traveler sends booking information to the travel agency which, walidus phy example described in [8]. It is mod- namically, i.e. during the execution of choreography instances? in turn, contacts the acquirer to request a credit check. If the 3. Book Trip Operation: Local Views to manageA the different versions choreography Fig. 3. of Book Trip Operation: Local Views d describes a collaboration between four How P RELIMINARIES Definition 5: [Change Operation] a the Proof: Fig.The proof of this lemma can be based on the traveler has not enough credit, failure notifications are sentchange operation isIII. Fig. 3.processes Book Trip Operation: Local Views model (used in monitoring) and the participants’ at travel agency, tuple acquirer, and airline. The (δ,Σ) δ ispartners the change pattern andLocal Σemphasized, is either this the paper following properties of the collaboration [11]. to the travel agency and where the airline which inform deals withcompatibility change propagation in Fig. 3. Book Trip Operation:As Views runtime? g information to the travel agency which, the traveler about the reservation failure purchase collaborative processes. there are three different, process model, or the localandorthe global choreography model to In practice, • If a ∈ L is an activity that interacts with partner p0, p cquirer to request a credit check. If thean approval is sent to the but overlapping viewpoints in a collaboration: cancellation respectively. Otherwise, orchestration, walidus fd 1 of 1 08.05.2012 III.fd P RELIMINARIES be changed. walidus 1 of 1 gh travel credit, agency failure notifications are sent then: ∃b ∈ L with b = a. Fig. interface, 3. Book Trip and Operation: Local Views1 of 1[12]. An p0 08.05.2012 3. Book Operation: Local Views walidus and the Fig. airline is Trip triggered to send the fdticket behavioral choreography orchestration Definition 6: inform [Abstraction function] 1this Abstraction function andand thethe airline partners which As emphasized, paper deals change propagation walidus fd of 1 • logic If ai ,ofinaprivate purchase confirmation. describes thewith internal business processes as activities that interact with the j ∈ L08.05.2012 p are two e reservation failure the processes. In practice, there are threeactions different, (π) is purchase a views projection of choreography a process model according well asπ the communication which p0 a particular Figure 2 abstr depictsλand the public (i.e.,collaborative local same inpartner and β(ai , aj ) is a function that returns ely. Otherwise, an approval is sent to the but overlapping viewpoints in a collaboration: orchestration, criterion λ. It transforms the source π The intobehavioralthe models) of to all participants involved in the choreography. Eachprocess partnermodel engages. interface (alsoprecedence called public relation between a and a (after minimal i j walidus fd1 of 1 1 of 1 08.05.2012 08.05.2012 e airline triggered to send interface, and choreography [12]. An orchestration 0 interactions view or localsatisfychoreography model) sketches the message partneris view includes onlythethe which this a target model πticket wherebehavioral π 0 inincludes only activities reduction), then: ∃b , b ∈ L with b = a , b = aj and i j i j p0 i firmation. describes the internal business logic of private processes as exchanges from the perspective of a single partner as well as partner is involved as well the as thelocal control flow between them. ing λ (e.g., choreography model is an abstraction β(a , a )= β(b , b ) (bi-simulation property [11], [13]) . wellorchestration) as the communication actions between in which a particular e public (i.e., i jwords, iti represents j them. In other Figureviews 2 does not local show choreography the private view (i.e., of the sequencing ofthat respective process model according interaction antseach involved in theitschoreography. Each partner engages. The behavioral interface called public an to abstraction of an(also orchestration’s internal actions. The partner includes the internal activities. These local activities). Atoreduction function may be applied to eliminate view or local choreography model) sketches message s only interactions this choreography choreography (also called the global model) gives a global viewsthe merged together in leadwhich the global model. Definition function] Let π be a process model and F exchanges the perspective aparallel single partner well as 8: [α wellNow as the control between them. assume thatflow partner acquirer wants to change the logic view(e.g., of allof in theascollaboration. It captures the unnecessary control patterns afterfrom abstraction a interactions be a fragment with: ∀o ∈ Fto =⇒ o ∈ π, where o denotes an the sequencing between them. In in other words, represents partners engage w theofprivate view (i.e., orchestration) interactions which the it participating its private process. For instance, instead of sending two pattern between an of activity and an empty transition may be abstraction of an achieve orchestration’s actions. The udesfailure the internal activities. Theseandlocal of type activity or these control node. Then: Function απ (F) a goal asinternal well asobject the dependencies between notifications to airline travel an agency respectively, reduced to sequence) [15],2,[16]. For instance, depending on a interactions. order to precisely define the fragment notions of in the process structure tree of π hetonotifies onlychoreography one of them.model. In Figure fragment F is called choreography (also globalInmodel) gives a global r lead the global returns the smallest certain condition, a different value of afordataorchestration, element d is sent It interface behavioral and choreography, we fragment F 0 (XOR instead of AND). tner replaced acquirerby wants to change the logic view of allThen, interactions in the collaboration. captures the all that contains elements of F. This function is also used to to the same partner p. In the local view, this is reduced to only adopt a model for representing some processinstead instances, wait indefinitely interactions in which need the to participating partners engage tocontrol-flow relations . For instance, of partner sendingairline two would identify a fragment local or global choreography model. for a and failure notification if the acquirer choosesa togoal send between activities In this paper,inwea adopt achieve as a well as theof dependencies between these o airline travel agency respectively, one interaction which corresponds to the sending data d.and interactions. a structured representation of process models. In essence, a notification only to the travel agency. In this case, the acquirer In order fragments to preciselyas define of them. In Figure 2, we fragment F Definition is interactions. Next, extend 6 to consider well the notions of IV. C HANGE P ROPAGATION orchestration, behavioral interface and choreography, we F 0 (XOR instead of AND). Then, for as local and global choreography models. We also assume that s, partner airline would wait indefinitely need to adopt a model for representing control-flow relations section introduces a global view of the proposed λ = p0chooses meanstothe interactions p0. Hence, abstrp0 (LInp )this is paper,This ion if the acquirer send a betweenwith activities and interactions. we adopt 0 approach the abstraction of L according to the interactions with p . p a structured representation of process models. In essence,and a details the different steps to propagate changes e travel agency. In this case, the acquirer credit card not approved
07.05.20
t icket
ok
paym ent ok
Purshase confirm at ion
credit card not approved
07.05.2012
t icket
ticket paym ent
paym ent ok
Definition 7: [Complement function] If a ∈ p is an interFig. 2.instance Global Choreography: Book Trip Operation [] choreography models well as a consistent global choreprocess would be blocked in this state not ter- p0, the complement of a called action activity withand a partner Fig. Fig. 1. 2.as Global Choreography: Book Trip Operation [8] Global Choreography: Book Trip Operation [] ography. Finally, we sketch4:the[Change transition Patterns] from the structural minate. Hence, the described the soundness Definition a ∈change p0 is affects the opposite of a of as follows. collaboration
TravelAgency
collaboration
07.05.2012
t icket
Purshase conf irm at ion
Purshase confirm at ion paym ent ok
t ot al approval value
t icket purchase cancelled
07.05.2012
07.05.2012
t icket
paym ent Traveler ok
Acquirer
t ot al value
total
failure
cancelled
1 of 1
Global Choreography: Book Trip Operation [] cancelled ok t ot al value Fig. 2. Global Choreography: Book Trip Operation [] t icket
Acquirer
t icket purchase 07.05.2012 cancelled t icket not ificat ion purchase failure not ificat ion cancelled
not if icat ion f ailure
purchase cancelledTravelAgency
failure approval
t icket purshase TravelAgency t icket cancelled paym ent purshase
t ot al Fig. 2. Global Choreography: Book Trip Operationvalue [] approval value
total value
t icket purchase Traveler
cancelled 07.05.2012
Acquirer ticket notification Global Choreography: Book Trip Operation [] 1 of 1 t icket purchase not ificat ion failure
Purchase confirm at iont icket TravelAgency
Fig. 1. AcquirerGlobal Choreography: Book Trip Operation [8] collaboration
Fig. 2.
Airline TravelAgency
1 of 1
t icket 1 of 1 purshase
approval
t otapproval al value TravelAgency
TravelAgency
TravelAgency
t ot al value Acquirer
approved
Traveler
Purchase confirmation
TravelAgency t icket purchase cancelled
credit card1 ofTraveler 1 credit not card not Traveler approval approved
Airline
Acquirer t icket purshase fdcancelled TravelAgency Acquirer
TravelAgency book purchase conf irm at ion reserve t ot al value approval Purchase confirm at ion TravelAgency ticket otal al value t icket t ot al tt ot book TravelAgency purshase book purshase value value reserve Traveler book book TravelAgency cancelled collaboration TravelAgency reserve cancelled reserve reserve Traveler
Traveler
not ificat ion TravelAgency failure TravelAgency t ot al value
credit card Ok Acquirer purchase conf irm at ion not credit card approved Purchase confirm at ion paym ent ok not TravelAgency approved
t ot al value
TravelAgency Acquirer
TravelAgency
Airline
t ick et
TravelAgency
Airline
AirlinePurchase confirm at ion
Airline Airline Airline Acquirer
Traveler
Airline
Airline
paym ent ok check and cash collaboration collaboration
TravelAgency TravelAgency
walidus fd
Traveler Traveler
TravelAgency
Airline
collaboration paym ent ok
walidus fd
Airline Airline
Airline
TravelAgency
TravelAgency
Traveler payment ok
Airline
book reserve
t icket
Acquirer
Acquirer TravelAgency
Airline
t icket
Airline
Traveler
paym ent ok paym ent ok
Fig. 2.
Airline
walidus fd
t ot al value t ot al value t ot al value
seq
F1211
Airline
Acquirer Acquirer
TravelAgency TravelAgency TravelAgency
Global Choreography: Book Trip Operation [] Fig. 2. Global Choreography: Book Trip Operation [] Acquirer Ok Acquirer t icket purshase ticket Purchase confirm at ion[] Fail not ificat ion failure Fig. 2. Global Choreography: Trip Operation []BookBook TravelAgency Fig. 2.Book Global Choreography: Operation Airline cancelled Fig. 2. Global Choreography: Trip Trip Operation [] Airline F12111 Ok Acquirer Global Choreography: Book Operation [] paym entTrip ok
Traveler Traveler
Ok
Traveler Airline
Airline TravelAgency TravelAgency Airline
Purchase confirm at ion Purchase conf tirm ion ot alatvalue total value Purchase confirm at ion
TravelAgency
Fail TravelAgency
Traveler
Ok
Ok Traveler Traveler Ok Traveler
Airline TravelAgency credit card not approved t icket
Acquirer Acquirer
TravelAgency
Traveler approval
TravelAgency
AirlineAirline
bookcollaboration reserve
collaboration
check and cash check and cash
ravelAgency ravelAgency
t icket
t icket purshase cancelled
seq
Airline
TravelAgency TravelAgency
book reserve book reserve
t icket
TravelAgency Airline TravelAgency
Traveler
Global Choreography: Book Trip Operation []
ick et purshase t icket tpurshase cancelled cancelled
Traveler
Traveler Traveler
F121
Airline
Acquirer Acquirer check and cash check and cash airline not if icat ion not ificatAcquirer ionf ailure failure Acquirer Airline Airline collaboration
book reserve
ticket Acquirer
Fig. 2.
TravelAgency TravelAgency
book reserve FailFail TravelAgency TravelAgency
credit card not approved Airline Traveler Airline t icket
Airline
Airline TravelAgency TravelAgency Traveler t ot al value TravelAgency Airline TravelAgency Traveler Airline t icket purshase TravelAgency Acquirer not ificat ion failure Acquirer cancelled Traveler t icket Acquirer TravelAgency Acquirer ticket purshase TravelAgency Acquirer Fail notification failure Acquirer Acquirer cancelled Ok Acquirer Airline Traveler TravelAgency TravelAgency credit card not approval Acquirer Airline Acquirer Acquirer Airline not ificat e failure TravelAgency approved Acquirer approval Airline Traveler approval card not credit credit card not approval t icket purshase not if icat ion t icket purshase paym ent ok Traveler notairline TravelAgency FailFailapproved ificat ion failure approval approved TravelAgency Traveler TravelAgency cancelled f ailure cancelled approval TravelAgency Traveler TravelAgency book reserve TravelAgency TravelAgency Traveler Traveler Airline check and cash Traveler Airline Airline Airline Traveler TravelAgency TravelAgency book reserve check and cash TravelAgency Acquirer Airline Airline Acquirer Airline t icket
Fig. 2.
TravelAgency TravelAgency
t icket
Ok
Purchase confirm at ion Acquirer check and cash
approved book reserve
TravelAgency
TravelAgency not icat e f ailure not not ificat failure ifife icat ion f ailure
Airline
Airline TravelAgency
Purchase conf irm at ion Airline TravelAgency Traveler TravelAgency TravelAgency Purchase confirm ation
Traveler F112
TravelAgency
Acquirer Acquirer
TravelAgency
TravelAgency
credit card not Acquirer credit card not approved
not if icat e f ailure not if icat ion f ailure
Traveler TravelAgency Traveler
not ificat e failure
F12
TravelAgency
TravelAgency
seq
t icket purshase t icket purshase cancelled cancelledTraveler
Acquirer TravelAgency Acquirer Ok TravelAgency Acquirer TravelAgency paym ent ok TravelAgency paym ent ok Fail notok ificat ion failure paym ent t ot al value TravelAgency Acquirer credit card not Airline Airline approved Airline Airline creditAirline card not Airline notificate failure Traveler approvedAirline Traveler
not ificat e failure
Airline
Book Trip Operation
Airline t icket purshase Airline Airline cancelled
paym ent ok paym ent ok Acquirer TravelAgency
Purchase confirm at ion paym ent ok Airline
F11
seq
Airline
not if icat ion f ailure Fail cancelled not ificat ion Airline failure Traveler Traveler Airline Acquirer Airline
Airline
Airline
Book Trip Operation
collaboration
t icket purshase cancelled
Airlinet icket Traveler Traveler TravelAgency Traveler TravelAgency Ok Acquirer Traveler TravelAgency Traveler TravelAgency Traveler TravelAgency book reserve check and cash TravelAgency TravelAgency book reserve check and cash book reserve check and cash check and cash paym ent ok book reserve book reserve check Acquirer and cash TravelAgency check cash TravelAgency Book Trip and Operation Acquirer Airline TravelAgency Acquirer TravelAgency Acquirer Airline TravelAgency Acquirer Acquirer Ok Acquirer Ok Acquirer t icket Ok Airline
Traveler Book Trip Operation
Traveler Traveler
not if icat ion f ailure Fail
not ificat ion Airline failure
Fail
TravelerTraveler
Acquirer
Airline Acquirer not ificat ion failure Fail Acquirer ticket purshase notification failure cancelled t icket purshase
Airline
Fail
credit card notcard Traveler credit not approved approved
Traveler TravelAgency TravelAgency
Traveler
Traveler
check and cash
not ificat ion failure
approval
08.05.201
paym ent ok
approval
in collaborative processes.
08.05.2012
Infer interaction changes
Specify change
Start
Variant?
Compute affected partners
Yes
No
Propagate changes public2private
Do
Update local change
Update global choreography model
Select an affected partner Find another alternative
Succeed Succeed
Update local choreography models
End
No Fail
Yes
Compute changes to propagate to this partner
abandon?
Fail
Yes
ok?
No
No Check compatibility and consitency
Fig. 4.
Compute public2private changes
Yes
negociations succeed?
Negotiate changes
Yes
last partner?
No
Change Propagation - Major Steps
A. Overview As afore mentioned, our objective is to support change propagation in choreographies with multiple interacting partner processes. Our approach relies on four major steps: (i) identifying interactions affected by the change as well as the partners involved, (ii) translating the initial change operation into several change operations each related to a particular partner, (iii) negotiating with the affected partners, and (iv) checking consistency and compatibility of the changed choreography. Figure 4 details the previous steps and outlines the different actions to achieve a sound propagation. Given a change operation on one partner orchestration, we extract all interaction activities concerned by the change. Interaction activities are communication actions with other partners (i.e., sending and receiving requests). If the list is empty (i.e., if the local change is restricted to the internal behavior), the other business partners are not affected by the change and there is no need for a new agreement on the global choreography. Otherwise, the list of affected interactions is analyzed to identify all partners involved. For each of these partners, a relative change computation is undertaken to gather the changes to be propagated. The latter are computed according to the change operation type. Then, a negotiation phase is launched with each affected partner. If all negotiations succeed, we apply consistency and compatibility checks to ensure the soundness of the obtained models. If these models are sound, we update the local and the global choreography models affected by the change and, if necessary, adapt concerned orchestrations to their new behavioral interfaces. Section IV-B is structured according to the mentioned steps. It sketches the different algorithms needed for propagating changes. Note that this propagation strongly depends on the change operation type (i.e., INSERT, DELETE, REPLACE and UPDATE). B. Algorithms Enabling Change Propagation Consider a change operation δ on a process model πp . To start, we abstract the changed fragment according to its interaction activities; i.e., we look for the structural or semantical changes that affect the interactions with the
other partners. According to the change operation type, a particular procedure for decomposition is performed. This decomposition transforms the initial change operation into several change actions to be propagated to each affected partner. Due to lack of space, here, we only consider the UPDATE and the REPLACE change patterns. Note that REPLACE can cover patterns INSERT and DELETE. 1) REPLACE Decomposition: Assume we want to replace a fragment F by a new fragment F 0 with a different structure (e.g., in the book trip example depicted in Figure 1; REP LACE(P AR(Airline notif ication f ailure, T ravelAgency notif ication f ailure),CHC(Airline no− tif ication f ailure , T ravelAgency notif ication f ailure) ), πacquirer )). As described in Algorithm 1, the first step computes all partners involved in F and F 0 (e.g., Airline and T ravelAgency) and for each partner p0 we abstract from, the respective interaction activities (abstrp0 (F) and abstrp0 (F 0 )) (e.g., in the example, F and F 0 already include interactions activities only). At this level, for a particular partner, three possible scenarios can be identified: (i) a partner involved in the original fragment F is no longer present in the new fragment F 0 (deletion of the interaction with this partner), (ii) a partner involved in F 0 was not present in F (adding a new interaction), and finally (iii) a partner present in both fragments F and F 0 , but with different structure (updating the conversation with a partner). As a consequence of these scenarios, the REPLACE pattern is translated into a concatenation ∆ of change patterns to propagate to the affected partners. (i) Deletion scenario: If a particular partner p0 interacts with the partner p in fragment F and is not engaged in any conversation with p in the new fragment F 0 , we delete the respective interactions from their local choreography models. To achieve this, we consider each interaction activity a with p0 to be deleted in F. Further, we search for the matching activity a in p0 and derive the change pattern DELETE(a, Lp0 ). Note that this operation is not applied directly since there is a
negotiation phase. Besides, this deletion could have subsequent effects on p0 . Indeed, it is possible that other interactions in p0 semantically depend on the deleted interaction (e.g., supply chains scenarios). This is called transitivity effect and it does not constitute a structural problem, but a semantical one. In this section, we focus only on structural changes, but resolve the transitivity effects separately in Section IV-C. So, if activities to delete are synchronous (e.g., waiting for a response or replying to a request), then we delete the corresponding activities. For example, consider a buyer that invokes a seller for a price request (i.e., send(seller, price request), receive(buyer, price request)). If we delete this interaction, we must delete the corresponding response to the buyer as well (i.e., send(buyer, price response), receive(seller, price response)). This could be achieved using the correlations between activities (e.g., correlation sets known from BPEL). Algorithm 1: Decomposition REP LACEπ (F, F 0 ) 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
of
Change
Pattern
Input: - Set of all local choreography models L = {Lp |p ∈ P} - Global choreography model G begin ∆ ← ∅ //decomposition result P∆ ← List of all business partners involved in F ∪ F 0 for (each partner p∈P∆ ) do FG ← αG (F ) {smallest fragment including F in G} if abstrp (F ) 6= abstrp (F 0 ) then if abstrp (F ) = ∅ then in = T presetp (FG , G) out = T postsetp (FG , G) if (∃a ∈ Lp between in and out) then ∆←∆∧ IN SERTp (abstrp (F 0 ), P arallel, Lp .in, Lp .out) else ∆←∆∧ IN SERTp (abstrp (F 0 ), Sequence, Lp .in, Lp .out) end else if abstrp (F 0 ) = ∅ then for (each a ∈ abstrp (F )) do ∆ ← ∆ ∧ DELET Ep (a) {reduction rules may apply when executing the changes} if (a is synchronous) then ∆← ∆∧DELET Eπ (a0 )∧DELET Ep (a0 ) {a0 and a0 are the relative responses or requests of a and a } end end else ∆←∆∧ REP LACEp (αp (abstrp (F )), γ(abstrp (F 0 ), αp (abstrp (F )))) {γ is the merge function} for each a ∈ F st a ∈ / F 0 do ∆ ← ∆ ∧ DELET Ep (a) {if synchronous we do the same procedure as before} end end end end end Output ∆ ;
end
(ii) Insertion scenario: If a particular partner p0 has no interactions with p in the old fragment F, but interacts with p
in the new fragment F 0 , we have to insert the new interactions in the local choreography model of p0 (Lp0 ). For this purpose, we abstract F 0 according to partner p0 , compute abstrp0 (F 0 ) and lookup for the exact insertion position of the latter in Lp0 . In order to compute this position, while preserving structural dependencies, we make use of the global choreography model. Indeed, partner p0 may have other interactions with p outside the changed fragment F or with other partners outside or inside αG (F) in the global model G (where αG (F) is the smallest fragment that encapsulates F in the RPST of G). Note that FG includes all interactions of p which appear in F merged with other interactions of different partners. For example, consider the change scenario introduced in Section II, where fragment F is replaced by F 0 . The smallest fragment containing the two activities of F (i.e., airline and travel agency failure notifications) in the RPST of the book trip global choreography model is F11 (cf. Figure 3). The latter includes other interactions concerning the airline and travel agency partners (i.e., credit card not approved and ticket purchase cancelled). Algorithm 2: Transitive Preset and Postset Computation: T presetp (F, π) T postsetp (F, π) 1 Init: - T preset = start 2 - T postset = end 3 begin 4 predecessor = F .F irstElement 5 repeat 6 predecessor ← predecessor.parent 7 if predecessor = sequence then 8 repeat 9 childlef t ← predecessor.Child.lef t.next {parse from right to left} 10 childright ← predecessor.Child.right.next {parse from left to right} 11 if ∃F 0 ∈ childlef t st ∃ai ∈ F 0 which invokes p then 12 T preset = abstrp (child) 13 preset path = path between F and T preset 14 end 15 if ∃F 0 ∈ childright st ∃ai ∈ F 0 which invokes p then 16 T postset = abstrp (child) 17 postset path = path between F and T postset 18 end 19 until ; 20 end 21 until ((T preset 6= start ∧ T postset 6= end) ∨ predecessor = rootElement) ; 22 end 23 Output: T postset, T preset ;
Once αG (F) is identified, we compute the transitive preset and postset of αG (F) according to p0 . The transitive postset T postsetp0 (αG (F), G) (preset T presetp0 (αG (F), G)) represents the smallest fragment of G containing interactions of p0 that could be executed just before (just after) αG (F). These two variables are used to identify the insertion position of abstrp0 (F 0 ) in Lp0 . To compute these values we refer to Algorithm 2. Given a fragment F, a process model π, and a partner p, T presetp (F) is calculated as follows: Algorithm 2 first parses the RPST from F to the root element, and for each sequence element found, it parses the child elements from the right to the left and checks whether a child contains activities or interactions with p. If this applies, abstr(child) represents the transitive preset. If no child element contains
ChangePropagation ChangePropagation
Transitive effects: Transitive effects: ticket_purschase_cancelled is notticket_purschase_cancelled always sent to Traveler is not always sent to Traveler
Semantic violation if ticket_purchase Semantic depends violation semantically if ticket_purchase _cancelled of _cancelled depends semantically of Airline_notification_failure Airline_notification_failure
Airline Airline notification notification failure failure ticket ticket purchase purchase cancelled cancelled
(a) first scenario Fig. 5.
ticket ticket purchase purchase cancelled cancelled
Air line Airline
Airline Airline notification notification failure failure
Air line Airline
interaction activities with p, we try to discover the upper level in the tree and repeat the same procedure. The postset is computed the same way except that we discover the right part of the process tree. The transitive preset and postset (in =T presetp0 ( αG (F), G) and out =T postsetp0 ( αG (F), G)) represent the insertion position of the fragment abstrp0 (F 0 ) in Lp0 . If there are no activities between in and out in the initial model, we insert abstrp0 (F 0 ) in sequence. Otherwise, we insert it in parallel.
(b) second scenario Airline: Change Propagation
(iii) Replacement scenario: Finally, the last scenario is when both fragments F and F 0 contain interactions with corresponding activity to a (i.e., reply to a request or receive a partner p0 , but with different structures (control flow). a response) correlating inputs and outputs. We also update This means that the dependencies between interactions have the corresponding activity to a in Lp with the new partner changed and therefore the local view of p0 should be updated p00 . Then, we check whether or not p00 already exists in the to conserve compatibility between the behavioral interfaces. list of partners. In the latter case, we create a new public For instance, in the change operation example from Figure 2, view for p00 containing a and the corresponding activity a00 if F 0 contains the same interaction with airline for sending the the communication is synchronous. If the partner p00 already failure notification, but with different structure (the latter couldwalidus fd exists, we check where to insert a and possibly a0 in Lp00 . 1 of 1 walidus fd 1 of 1 be sent or not depending on the running instance). So, the For this purpose, we use the global choreography model G idea is to abstract the interactions with p0 in F (abstrp0 (F)), and compute the transitive preset and postset of a (in and identify abstrp0 (F) in Lp0 , and replace it with abstrp0 (F 0 ). out) and a0 (in0 and out0 ) according to p00 . If there are other However, this is not possible if the smallest fragment in Lp0 , interactions with p00 between in and out, we compute their which contains the activities of abstrp (F 0 ), includes other dependencies with a and insert the latter in Lp0 accordingly. interactions with different partners. For this purpose, we adopt The same holds for a0 if the communication is synchronous. a merge algorithm to merge abstrp (F) with αp (abstrp (F 0 ). Indeed, merging process models has been widely studied and Algorithm 3: Decomposition of Change Pattern many works were proposed [17], [18]. The key idea is to U P DAT Eπ (a, attribute, newV alue) merge different (and overlapping) process models into a single 1 Input: -Set of all business partners P model without restricting the behavior that was possible in 2 - Set of all local choreography models L = {Li , i ∈ P} the original models. So, if we consider γ as a merge function 34 begin - Global choreography model G then the problem could be solved by deleting the activities of 5 if (attribute = partner) then p0 ← a.partner {oldpartner} abstrp (F) from αp (abstrp (F)) and then merging abstrp (F 0 ) 67 p00 ← value {newpartner} with the rest of activities in αp (abstrp (F)). The merge could 8 if p00 ∈ / P then Create(lp00 ) {new local view} 9 also lead to a semantic violation. For instance, if we refer Add(lp00 , L) and Add(p00 , P) 10 to our change scenario for the book trip operation, the change 11 end ∆ ← ∆ ∧ DELET Ep0 (a) propagation to the airline partner is depicted in Figure 5. Two 12 ∆ ← ∆ ∧ IN SERTp00 (a, P arallel|Sequence, in, out) {in 13 scenarios are possible: the modified fragment is inserted before and out are computed as in previous algorithms} if Synchronous then activity ticket purchase order or it is merged with it. The 14 15 a0 = Response(a) first case is structurally correct in terms of dependencies, and 16 ∆ ← ∆ ∧ DELET Ep0 (a) ∆ ← ∆∧IN SERTp00 (a0 , P arallel|Sequence, in0 , out0 ) it conserves the compatibility between the interfaces. How- 17 {in0 and out0 are computed as in previous algorithms} ever, in case ticket purchase order semantically depends of 18 if p0 = ∅ then remove(p0 , P) and remove(lp0 , L) some parameters of activity airline notif ication f ailure, 19 20 end the second scenario is considered to be more correct. This is 21 end else a semantic issue and should be validated by the target partner 22 end affected. The latter should validate the proposed scenario 23 24 end which goes with its semantics. 25 Output ∆ ; 2) UPDATE Decomposition: As afore mentioned, the UPDATE pattern is used to update the attributes of a single activity. This paper considers the update of attribute partner, but this can be easily be generalized to consider other attributes as well (e.g., input, output, etc.). For instance, we assume that an interaction activity a of πp should be updated to interact with p00 instead of p0 . In this case, we look at a in Lp0 and delete it. If the interaction is synchronous, we delete the
C. Delete pattern: dealing with transitivity We now present a non-exhaustive list of use cases showing the transitivity effects of the DELETE change pattern and the solutions to cope with them. Note that this is a semantic issue and can not be resolved using the propagation algorithms presented so far and focusing on structural propagation.
23.05.2012 23.05.2012
For example, consider three partners p1 , p2 and p3 with p1 invoking p2 , which in turn, invokes p3 . The latter returns the intermediary result to p2 , which applies data transformations and sends the final result to p1 . So, if p1 decides to delete its interaction with p2 , we also must delete the subsequent interaction between p2 and p3 which is just used to deliver the final result. If a partner deletes an interaction, Semantically this means that he is not able to afford this service anymore, or he does not need the data anymore. The challenge is to determine if an interaction is transitive according to another one, to identify the transitivity effects, and to resolve them. Case 1: If partner p is the final consumer of a data element; he launches a communication in which he requires a response. p includes correlated send and receive patterns S/R (non-blocking S/R pattern). •
•
•
p deletes the send/receive patterns. This means that p does not need the data anymore (since p is the final consumer). We delete send and receive. In case where all subsequent interactions with other partners are just used to deliver this data, we delete them (e.g. supply chain scenarios). It is possible that only a subset of the subsequent interactions are used to deliver this data. These are deleted only if they don’t have any other role in the choreography. Example: two concurrent request from A and B to the same partner C. The latter does subsequent interactions and then reply to both of them. If A deletes his interaction, we should not delete the subsequent interactions of C since they are still used to reply to B. p deletes only the send pattern. Two scenarios: (i) Another partner starts the communication instead of him and then we just Update the correspondent send with the new partner, or (ii) p is not responsible anymore for informing the other partner to start the processing of the response (the response starts automatically or under other constraints) and then we Delete the corresponding send. p deletes only the receive pattern. This means either he does not need the data anymore or the data is transferred to another partner. In the first case, we just delete the corresponding receive and look for other interactions correlated with this response (just used for delivering the response). In the second case, we update the corresponding receive with the new partner.
Case 2: Partner p is the final consumer of the data but is not responsible for launching the first interaction (p has only the receive). Then, if p deletes the receive (does not need the data anymore), we delete the corresponding receive as well as all subsequent interactions used only to deliver this data. All interactions that participate in delivering this data but have another role in the choreography, are kept. Case 3: p is the starting point, responsible for starting a communication resulting in a response to another partner (p has the send). Either (i) another partner is responsible for starting this communication; then, we update the send with the
new partner, or (ii) the communication starts automatically or under other constraints on the target partner; then we delete the corresponding send. Subsequent interactions are not deleted since we still need the final data to be delivered to the final consumer. Case 4: p is an intermediary partner in the conversation. • p has correlated receive and send in sequence. p receives a request, starts a subsequent interactions necessary for delivering the final response to the requester. – If p deletes the send and the receive patterns, this means that p is not able to afford the service anymore, but we still need the final response to the requester. In this case, we have two choices: (i) looking for another partner who can do the work of p to deliver this response; in this case, we update the subsequent interactions as well as the interactions of the root partner (the one who invoked p and the one yo which p should send the result) with this new partner, (ii) deleting send and receive as well as all subsequent interactions used only in the context of this intermediary data and looking for another partner or set of partner who fulfill this intermediary task. Then we update the communications with the root partners or p. – If p deletes only the send pattern, this means another partner is responsible for starting this intermediary communication or the subsequent interactions start automatically or under other constraints. In the first case, we update the corresponding receive with the new partner, otherwise we just delete the receive. – If p deletes only the receive pattern, this means that p can not or do not want to do anymore the operations just after the receive and related to the delivery of the final data. (i) If no related operations are necessary to deliver the intermediate data, we update the receive to link it directly with root partner (ii) If related operations are necessary, we look for another partner which can fulfill the same tasks. V. E VALUATION In this paper, we assume that the initial public views of the collaborative processes are compatible with each others and that each private view is consistent with the respective behavioral interface definition (i.e., the local choreography model). We further assume the well-behavedness of the change operation in terms of structure and semantics. In [11], the authors distinguish between structural and behavioral compatibility. • Structural compatibility requires that for every message that may be sent, the corresponding interaction partner is able to receive it. In turn, for every message that can be received, the corresponding partner must be able to send such a message • Behavioral compatibility considers behavioral dependencies (i.e., control flow) between different message exchanges within one conversation.
In our propagation mechanism, structural compatibility is preserved. Indeed, according to the change operation type, for each affected partner we add, update, or remove the complement of what has been changed in the modified process (cf. Lemma 1). This means that for each send pattern in one source partner there is the corresponding receive pattern with the expected attributes in the process of the target partner. Now, consider (δ, πp ) being the change operation to be applied to process model πp and (δ, Lp ) the inferred change to be applied to the local view of p. ∆ is the set of inferred changes from (δ, Lp ) to be propagated to its directly affected partners. For each affected partner pi , (δi , Li ) represents the inferred change operation to be propagated to its public view (∆ = ∧i=1..n (δi , Li ), where n is the number of affected partners). Note that the number of inferred structural changes is finite since we only consider propagations to direct partners. In turn, changes that might have structural effects on other partners (transitive relations) are propagated to them by their direct partners. If (δ, Lp ) is invariant, i.e., it does not affect the behavioral interface of p, consistency and compatibility are preserved over the collaborative processes. In addition, since processes as well as the changed fragments are structured, consistency and compatibility relations are reduced to those between the fragments affected by the change. •
•
The INSERT pattern augments the process models of the partners affected by the change with new activities. Further, it does not affect the structural or behavioral relations between the existing activities. However, some direct precedence relations may be transformed into transitive ones. The decomposition of the INSERT pattern results only in INSERT patterns in the public views of the affected partners. According to one partner, the insertion is done with respect to the direct and transitive dependencies with the activities of the same partner. As explained in Section IV, if F represents the fragment to be inserted in Lp , abstri (F) is the fragment to be inserted in Li . The latter has the same behavior as abstri (F) in terms of control flow. Besides, the insertion position is computed according to the transitive preset and postset of Fi with respect to partner i. This conserves the order between the fragments and ensures the behavioral compatibility after the propagation of the INSERT operation. The DELETE pattern reduces the process models of the affected by the change. The reduction is done in a symmetric way on both sides: p and the partners affected. The deletion of an activity on one side results in the deletion of the corresponding a on the other side. Structural and behavioral compatibilities are kept. However, this might result in some issues, i.e., an activity might wait for a data that would never arrive or send a message that might not be used. The solution proposed in Section IV treats a set of use cases where the correlated interactions are updated or deleted accordingly. This does not affect structural and behavioral compatibility of the propagation.
•
As described, the propagation of the REPLACE pattern results in three scenarios; insert, delete, or merge. The merge may reduce or augment the target models of the affected partners. Assume that the merge function γ is correct and idempotent and that it conserves the behavior of the merged fragments. We consider Fi and Fi0 as the fragments to be merged. Then, the behavior of Fi is included in the merge result γ(Fi , Fi0 ), which is also compatible with the behavior of p (changed process) since we merge the abstraction of the changed fragment (cf. Lemma 1).
The consistency between the public views and the private ones of the processes of the affected partners is checked if the negotiations succeed. Each affected partner must adapt its private process with respect to its modified public view. Using consistency rules, each partner can then check locally whether its local process model is consistent with its behavioral interface. More details about consistency checking and validation in choreographies can be found in [1], [8]. VI. R ELATED W ORK [19] proposes four transfer rules to deal with dynamic changes of distributed business processes. These rules use projection/protocol and lifecycle inheritance relations and check whether a changed process is a subclass of the original one. The suggested method only allows for changes that preserve inheritance transformation rules, i.e., changes having internal effects. Therefore, there is neither a need for change propagation nor new agreement on the global protocols since only inheritance-conforming changes are allowed. By contrast, our method supports changes that affect the external behavior of a process, and computes and propagates the respective changes to the affected partners according to a negotiation phase. In [7], the authors consider change propagation in decentralized orchestrations where a centralized process model is split into several distributed partitions. They mainly propagate change operations made on the centralized model to the respective derived decentralized partitions. They use the decentralization function to compute the affected partitions and infer the respective changes to the private and public views. One organization controls the centralized and decentralized models. Hence, it is easier to exactly compute the affected regions and the changes to be applied. This is different from the current work since changes are made by one partner participating in the choreography and then propagated to the other partners. In this work, we consider fully distributed processes where no partner holds informations about another partner’s private view (no centralized process model). Each partner can only see the public parts of the other partners. This leads to a negotiation phase between the affected partners and could have transitive structural and semantical effects. In contrast with the cited paper, in this work we take into consideration the semantic issues (transitivity). This problem is not considered when we propagate from a centralized to its decentralized partitions since the changes are made on the
centralized model and considered to be correct. An approach similar to [7] is also presented in [20]. In [4], the authors present DYCHOR, a framework addressing the challenge of change propagation in choreographies. Changes are classified into additive and subtractive, and may have variant or invariant impact on the interactions. DYCHOR uses annotated finite state automata to model choreographies and employs a set of operators to compute the changes to be propagated. In our work, we propose four change patterns which deal with more complex fragments instead of single activities only. This leads to new challenges concerning semantical or structural transitivity effects as well as negotiations with the partners affected by the change. We sketched several semantic transitive effects as well as the solutions to deal with them. The model adopted in this paper makes change propagation more easier since process models are structured and only changed regions are affected. Hence, there is no need for re-computing the whole public views of the processes of affected partners, instead only the affected regions are modified. In [21], the authors address the problem of dynamic changes and particularly version management of process models. In the same context in [22], the authors propose an ontology based framework for decentralized workflow change management and define migration rules to adapt to changes in a dynamic way. In [23], the authors deal with change propagation between semantically overlapping process models for which elementary and complex correspondences have been identified. All these approaches are different but complementary to our work. VII. C ONCLUSION , D ISCUSSION , AND O UTLOOK This paper provides algorithms for propagating process changes in collaborative scenarios involving multiple partners. To stay independent of a particular process specification language, RPST is used to define local and global choreography models. The proposed propagation algorithms consider typical process change patterns such as INSERT, DELETE, REPLACE, and UPDATE, and are evaluated based on their structural and behavioral compatibility. Certain assumptions are made in this paper. First, the proposed algorithms consider the application of one change pattern at a time. However, in practical scenarios, several change patterns might be applied in a combined manner within a change transaction. To incorporate such complex changes, optimizations on the change transactions as suggested in [24] can be utilized to calculate the actual effects of the change transaction. Second, change propagation might become necessary in a transitive way, i.e., several partners might be affected. This can be handled by applying the change propagation procedure depicted in Fig. 4 in an iterative way. However, it must be considered whether the transitive propagation becomes cyclic. In this case, mechanisms such as upper bounds on the number of iterations of propagating changes including rollback mechanisms are conceivable.
Currently, we are integrating change propagation algorithms into our cloud-based process execution engine CPEE (cpee. org). We aim at testing and applying the proposed algorithms in case studies, for example, within the automotive domain. R EFERENCES [1] F. Casati, S. Ceri, B. Pernici, and G. Pozzi, “Workflow evolution,” Data and Knowledge Engineering, vol. 24, no. 3, pp. 211–238, 1998. [2] S. Rinderle, M. Reichert, and P. Dadam, “Correctness criteria for dynamic changes in workflow systems: a survey.” Data and Knowledge Engineering, vol. 50, no. 1, pp. 9–34, 2004. [3] M. Reichert and B. Weber, Enabling Flexibility in Process-Aware Information Systems - Challenges, Methods, Technologies. Springer, 2012. [4] S. Rinderle, A. Wombacher, and M. Reichert, “Evolution of process choreographies in DYCHOR,” in CoopIS’06. LNCS, 2006, pp. 273–290. [5] S. Rinderle, B. Weber, M. Reichert, and W. Wild, “Integrating process learning and process evolution - a semantics based approach,” in Int’l Conference Business Process Management, 2005, pp. 252–267. [6] S. Rinderle, M. Reichert, and P. Dadam, “Flexible support of team processes by adaptive workflow systems.” Distributed and Parallel Databases, vol. 16, no. 1, pp. 91–116, 2004. [7] W. Fdhila, A. Baouab, K. Dahman, C. Godart, O. Perrin, and F. Charoy, “Change propagation in decentralized composite web services,” in CollaborateCom, 2011, pp. 508–511. [8] F. M. Besson, P. M. Leal, and F. Kon, “Towards verification and validation of choreographies,” Department of Computer Science - University of So Paulo, technical research report, 2011. [9] J. Vanhatalo, H. Vlzer, and J. Koehler, “The refined process structure tree,” in Business Process Management, vol. 5240, 2008, pp. 100–115. [10] B. Weber, M. Reichert, and S. Rinderle-Ma, “Change patterns and change support features - enhancing flexibility in process-aware information systems.” Data and Knowledge Engineering, vol. 66, no. 3, pp. 438–466, 2008. [11] G. Decker and M. Weske, “Behavioral consistency for B2B process integration,” in CAiSE. Springer, 2007, pp. 81–95. [12] A. Barros, M. Dumas, and P. Oaks, “Standards for web service choreography and orchestration: Status and perspectives,” in Business Process Management Workshops. Springer. LNCS, 2006, vol. 3812, pp. 61–74. [13] A. Polyvyanyy, L. Garcia-Banuelos, and M. Dumas, “Structuring acyclic process models,” Information Systems, vol. 37, no. 6, pp. 518–538, 2012. [14] R. Milner, M. Tofte, and D. Macqueen, The Definition of Standard ML. Cambridge, MA, USA: MIT Press, 1997. [15] B. F. van Dongen, W. M. P. van der Aalst, and H. M. W. Verbeek, “Verification of EPCs: Using reduction rules and petri nets,” in CAiSE. Springer, 2005, pp. 372–386. [16] R. Dijkman, “Diagnosing Differences between Business Process Models,” in Proceedings of the 6th Int’l Conference on Business Process Management (BPM 2008). Springer, LNCS, 2008, pp. 261–277. [17] M. L. Rosa, M. Dumas, R. Uba, and R. M. Dijkman, “Business process model merging : An approach to business process consolidation,” ACM Transactions on Software Engineering and Methodology, 2012. [18] F. Gottschalk, W. M. Aalst, and M. H. Jansen-Vullers, “Merging eventdriven process chains,” in OTM ’08. Springer, 2008, pp. 418–426. [19] W. M. P. van der Aalst and T. Basten, “Inheritance of workflows: an approach to tackling problems related to change,” Theor. Comput. Sci., vol. 270, no. 1-2, pp. 125–203, 2002. [20] M. Reichert and T. Bauer, “Supporting ad-hoc changes in distributed workflow management systems.” in CoopIS’07, vol. 4803. Springer, 2007, pp. 150–168. [21] J. M. K¨uster, C. Gerth, and G. Engels, “Dynamic computation of change operations in version management of business process models,” in ECMFA’10. Springer, 2010, pp. 201–216. [22] V. Atluri and S. A. Chun, “Handling dynamic changes in decentralized workflow execution environments,” in DEXA’03, 2003, pp. 813–825. [23] M. Weidlich, J. Mendling, and M. Weske, “Propagating changes between aligned process models,” Journal of Systems and Software, vol. 85, no. 8, pp. 1885 – 1898, 2012. [24] S. Rinderle, M. Reichert, M. Jurisch, and U. Kreher, “On representing, purging, and utilizing change logs in process management systems,” in Business Process Management, 2006, pp. 241–256.
