Reasoning about Channel Passing in Choreography - CiteSeerX

Reasoning about Channel Passing in Choreography? Yang Hongli1 , Cai Chao1 , Peng Liyang1 , Zhao Xiangpeng1 , and Qiu Zongyan1 LMAM and Department of Informatics, School of Math., Peking University, Beijing 100871, China {yhl,caic,ply,zxp,qzy}@math.pku.edu.cn

Abstract Web services choreography describes global models of service interactions among a set of participants. For an interaction to be executed, the participants taken part in it must know the required channel(s) used in the interaction, otherwise the execution will get stuck. Because of dynamic composition, the initial channel set on each participant is often insufficient to meet the requirements. It is the responsibility of the participants to pass required channels owned (known) by one to some others. Since a choreography may involve many participants and complex channel constraints, it is hard for designers to specify channel passing in a choreography exactly as required. In this paper, we address the problem of checking whether a choreography lacks channels or has redundant channels, and how to automatically generate channel passing based on interaction flows of the choreography in the case of channel absence. Concretely, we propose a small language Chorc named for an channel interaction sub-language for modeling the channel passing aspect of choreography. Based on the formal operational semantics of Chorc , the algorithms for static checking choreography and generating channel passing are studied as well. Moreover, a purchase order choreography example is presented to show how to formalize and analyze a choreography with channel passing in Chorc . Keywords: Choreography, Channel passing, Service interactions

1 Introduction Web service composition, the process of combining several web services to provide a value-added service, is fundamental to the support of business-to-business and the integration of enterprise applications. Two levels of views to the composition of web services exist, namely orchestration and choreography. While the orchestration view focuses on interactions between one party and the others, the choreography view emphasizes a global perspective. In large service-oriented systems, stockholders may require a global picture of the way by which services interact with each other, rather than multiple small pictures of individual services [30]. Web Service Choreography Description Language (WSCDL) [1] is a typical example of the languages for describing global models of service interactions. Developed by W3C’s Choreography Working Group, WS-CDL describes ?

Supported by open foundation of State Key Laboratory of Computer Science, Institute of Software, Chinese Academy of Sciences (No. SYSKF0703), and National Natural Science Foundation of China (No. 60603033 and No. 60573081)

1

business protocols from a global viewpoint and the description will be implemented by individual distributed processes without center control [14]. As said in the specification, WS-CDL is neither an “executable business process description language nor an implementation language”. The execution logic of the application is handled by languages at another level, such as XLANG [25], WSFL [21], BPEL [2], BPML [3], etc. while WS-CDL focuses only on describing the business protocol among different participants. All the behaviors are performed by the participants, and WS-CDL provides a global observation. In the early phases of the service development life cycle, emphasis should not be put on building the individual services, but rather on identifying potential services and understanding and analyzing their interactions. In a global choreography model, interactions are described from the viewpoint of an ideal observer who oversees all interactions between a set of services [30]. In other words, the observer knows about the set of participants, and the control flow of the interactions among them. All of this knowledge come from practical business protocol. For instance, in a simple purchase order service choreography, there are three participants: Client, Seller and Shipper. The Client sends a request to Seller through a Seller’s channel. This implies that Client must know this channel before the request interaction. Similarly, for the interaction between Seller and Shipper, the Seller must know the Shipper’s channel. The interesting thing is the interaction between Shipper and Client. In the most common cases, Shipper does not know the channel of Client. It is the responsibility of Seller to pass the corresponding channel to Shipper. But at the most beginning of the choreography, it is not possible for Seller to know each potential Client. It gets the channel information from the request interaction launched by Client. On the other hand, if Client want to nominate a specific shipper, it must pass this nominated shipper’s channel to Seller during the request interaction. It is obvious that channel passing plays very important role in a choreography. Because of the business rules and practical reasons, the channel set available to each participant at the beginning of the choreography is often insufficient to meet the requirements, thus the channel passing is necessary in the execution course. On the other hand, the business rules might also put constraints on which participant should know which channels. These constraints ensure channel information will not leak to the participants who should not know it. Clearly, an important issue arises when we deal with the global models of service interactions, that is, how to validate channel passing in the large service interaction systems, while these systems may involve many participants and complex channel constraints. Consider the following problems which may occur during the interactions: – Channel-absent: A required channel is not available to a participant when an interaction needs to be carried out, in which either the participant needs to use the channel in the interaction, or it needs to pass the channel to another participant. In this case, the choreography will get stuck. – Channel-redundant: In the executing flows, some channels are passed to some participants who will never use them in the choreography. Dealing with complex choreography, we need an accurate model to make the judgments about these problems. Moreover, due to the complexity of channel passing, it is 2

helpful to have an algorithm to generate channel passing based on the given participants and control flows of interactions. This paper describes our work on this aspect for choreography, as a continuous effort to explore the essence of choreography with formal models, e.g. [28]. In our framework presented in this paper, a choreography denotes a set of participants and the collaboration among them. Initially, each participant owns (knows) a set of channels that can be used for interactions. Each interaction is executed on a dedicated channel, which may pass some channels to the target participant of the interaction. Based on this framework, we study properties relative to the channel passing flows. In particular, we develop some algorithms for static checking the following problems: Could a choreography fall into stuck because not enough channels are available? Does redundant channels exist in a choreography? Moreover, we develop an algorithm for generating channel passing automatically in a choreography in the case of the absence of channels. Organization: We first introduce a choreography language Chorc with syntax and semantics in section 2. Section 3 develops algorithms on static analysis of channel passing specified in Chorc , and the algorithm for generating channel passings. An example is presented in Section 4 to show how a business protocol can be described in Chorc , and how to analyze channel passing based on our model. Section 5 discusses related work. Section 6 concludes this paper with a brief discussion on future work.

2 The Chorc Language In this section we present the language Chorc , where we use subscript c to emphasis our concern on channel. Since the participants in a choreography always play different roles for cooperation, we simply use the term role in stead of the term participant in the paper. 2.1 Syntax In the definitions below, meta-variable R ranges over role declarations; A and B range over activities; r, r1 and r2 range over role names; h ranges over channel names and H ranges over sets of channel names. For simplify the description, we will use h · H for {h} ∪ H . Additionally, variable op ranges over the operations offered by the roles. We will use R as a shorthand for a set of role declarations, R1 , · · · , Rn , for some n, similarly, for h, op, etc. A choreography declaration consists of a name C, some roles R, and an activity A, with the form: C[R , A] Each role R has name r, an initial channel set h, and observable behaviors represented as a set of operations op. The signature and function of operations are defined elsewhere and will not be considered here. A role declaration with name r is of the form: R ::= r[op , h] 3

The basic activities in choreography are the follows: BA ::= skip | (r1 → r2 , op, h, H ) | (r1 ← r2 , op, h, H ) | (r1 ↔ r2 , op, h, H )

(skip) (request) (response) (req-resp)

The skip activity does nothing. The interaction activity is either a request, a response or a request-response, in which operation op specifies what the recipient should do when it receives the message. The channel h specifies where the information is sent to in the interaction. The H denotes a set of channels passed during the interaction. The syntax of the activities in Chorc is: A, B ::= | | |

BA A; B AuB AkB

(basic) (sequence) (non-deterministic) (parallel)

An activity is either a basic activity, or a structural activity, which is either a sequence activity A; B, a non-deterministic activity A u B, or a parallel activity A k B. We introduce some well-formedness rules for Chorc program: 1. In a choreography, different roles have different names, and different channels have different names. 2. In a request or request-response interaction, the operation op should belong to the behavior interface of recipient role r2 ; while in a response interaction, op also belong to role r2 that means r2 return the result of operation op to r1 , which requested op before this interaction. It is the responsibility of a static checker to verify whether these rules hold. In the semantic definition, we will only consider the well-formed Chorc programs. 2.2 Semantics In this section, the operational semantics for Chorc is presented. The semantics reflects the intention that we are going to study only the communication and channel-passing behavior of choreographys in Chorc in this paper. We define that a configuration is of the form hA, σi, where A is an activity, and σ is a channel state which is a function of the form {r1 7→ (K1 , U1 ), ..., rn 7→ (Kn , Un )}

for n roles

For a role r and a channel state σ, the notion σr denotes a pair (K, U ), where K and U are the channel sets denoting the known and used channels of r in σ, respectively. We will use (σr).K and (σr).U to take the K set and U set of r from σ. Specially, h ∈ (σr).U means that r has carried out an interaction through h or passed h to the target role. In other words, r has used this channel h. 4

For convenience, we use expression σ[(H1 , H2 ) . r] to denote a channel state built from σ by adding all the channels in H1 to the known channel set of role r, all the channels in H2 to the used channel set of r, leaving channels of the rest of the roles unchanged. Moreover, we use h², σi to denote a terminal configuration, where ² denotes the empty process. Now we give the semantic rules for the activities of Chorc . The execution of skip activity always terminates successfully, leaving everything unchanged. hskip, σi −→ h², σi (SKIP) In an interaction, some channel can be passed from one role to another. After the interaction, the passed channels will be added to the known channel set of the target role. As shown in the following rules, an interaction is possible only if the dedicated channel h is available on the sender of the interaction, and a role can pass only those channels it knows currently. h ∈ (σr1 ).K, H ⊆ (σr1 ).K h(r1 → r2 , op, h, H ), σi −→ h², σ[(H , ∅) . r2 , (∅, h ·H ) . r1 ]i h ∈ (σr2 ).K, H ⊆ (σr2 ).K h(r1 ← r2 , op, h, H ), σi −→ h², σ[(H , ∅) . r1 , (∅, h ·H ) . r2 ]i h ∈ (σr1 ).K h ∈ (σr2 ).K ∪ H , H ⊆ (σr1 ).K h(r1 ↔ r2 , op, h, H ), σi −→ h², σ[(H , ∅) . r2 , (∅, h ·H ) . r1 ]i

(REQ)

(RESP)

(REQ-RESP)

The semantical rules of sequential composition and non-deterministic choice are regular, and we will not explain them in details. hA, σi −→ h², σ 00 i, hB, σ 00 i −→ h², σ 0 i hA; B, σi −→ h², σ 0 i

(SEQ)

hA u B, σi −→ hA, σi

(NON-DET1)

hA u B, σi −→ hB, σi

(NON-DET2)

If both the execution of A and B terminate, the parallel activity A k B will terminate. hA, σi −→ h², σ 0 i, hB, σi −→ h², σ 00 i (PARA) hA k B, σi −→ h², σ 0 ⊕ σ 00 i Operator ⊕ unions the corresponding channel sets on each role, i.e. def

σ 0 ⊕ σ 00 = { ri 7→ ( (σ 0 ri ).K ∪ (σ 00 ri ).K, (σ 0 ri ).U ∪ (σ 00 ri ).U ) | i ∈ 1, . . . , n} 5

(1)

For the execution of a choreography C[R, A], we need to build up its initial configuration. This is done by a function start(C) which extracts the initial known channel sets for all the roles in C, and creates the initial configuration of C. def

start(C[ri [op i , h i ], A]) = hA, {r1 7→ (h 1 , ∅), . . . , rn 7→ (h n , ∅)}i

3 Reasoning about Channel Passing In this section, we first define the notion of channel-absent and channel redundant for a choreography, then develop algorithms for checking whether these two defects exist in a choreography. In the case of channel absence, an algorithm for generating channel passing is also presented. 3.1 Some definitions Let us define terminology stuck configuration in the case a choreography can not complete. Definition 1. A choreography C[R, A] is in a stuck configuration (A0 , σ), if start(C[R, A]) −→ (A0 , σ), and there is no rule for (A0 , σ) can apply. From the rules presented above, the only possible reason for a choreography to get stuck is that some role can not take part in a communication due to absence of some channel(s): either it attempts to communicate on the channel, or it need to pass the channel(s) to other roles. Thus we introduce the concept of channel absent choreography: Definition 2. We say a choreography is channel absent, if its execution might get into a stuck non-terminal configuration. Similarly, we introduce the concept of channel redundant choreography: Definition 3. A choreography C[R, A] is channel redundant, if there exists a configuration h², σi such that start(C) −→ h², σi and (σri ).K − (σri ).U 6= ∅ for some role ri . That is, if there is an terminated execution, in that there exists a role who knows some channels but does not use them. Thus, the channel is redundant. Here we use “K − U ” to get those channels which are in K but not in U . 3.2 Checking Algorithms In order to judge whether a choreography is channel absent or redundant, we propose some algorithms here. The central one is check, which generates the necessary information for making the judgment. For performing the calculation, check requires four parameters Σ, Ω, A, and Ac , and returns a pair of updated Σ and Ω. Here Σ is a set of σ defined in Section 2.2, and Ω is a set of interactions having been found that can not be executed due to the 6

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

check (Σ, Ω, A, Ac ) if Σ = ∅ ∨ A = ² then return (Σ, Ω) switch according to the form of A do case skip: return check (Σ, Ω, Ac , ²) case (ri → rj , op, h, H ) or (rj ← ri , op, h, H ): foreach σ ∈ Σ do if H ∪ {h} * (σri ).K then Ω ∪= {A}; Σ −= {σ} else (σri ).U ∪= H ∪ {h} (σrj ).K ∪= H end return check (Σ, Ω, Ac , ²) case (ri ↔ rj , op, ch, H ): foreach σ ∈ Σ do if H ∪ {h} * (σri ).K or h ∈ / (σrj ).K ∪ H then Ω ∪= {A}; Σ −= {σ} else (σri ).U ∪= H ∪ {h} (σrj ).K ∪= H (σrj ).U ∪= {h} end return check (Σ, Ω, Ac , ²) case A1 ; A2 : return check(Σ, Ω, A1 , A2 ; Ac ) case A1 k A2 : (Σ1 , Ω1 ) := check(Σ, Ω, A1 , ²) (Σ2 , Ω2 ) := check(Σ, Ω, A2 , ²) return check(Σ1 ⊕ Σ2 , Ω1 ∪ Ω2 , Ac , ²) case A1 u A2 : return check(Σ, Ω, A1 , Ac ) ∪ check(Σ, Ω, A2 , Ac ) end

Algorithm 1: Checking choreography

absence of some channel(s), A is the activity to be executed, and Ac is the continuation, expressing the activity that will be executed after A. To check choreography C[R, A], we call check({σ}, ∅, A, ²), where σ is start(C[R, A]).2, denotes the channel state in the initial configuration. We also take Ω an empty set, and Ac an empty activity. In completing of this algorithm, we get a result pair of (Σ 0 , Ω 0 ), where Σ 0 contains all possible channel states of successfully terminated configurations. Σ 0 may be empty, which means there is no successfully terminated execution. Ω 0 records all the interactions that can not be executed. In the following algorithm, we will use S ∪= S1 to represent the update S := S ∪ S1 , use S −= S1 to represent the update S := S − S1 , where S and S1 are two sets. The algorithm check is given in Algorithm 1. It follows a depth-first strategy to check the interaction flows based on the semantics of Chorc defined in Section 2.2. The skip activity has no effect on channel state. If current activity A is an interaction lacking 7

1 2 3 4

isAbsent (C[R, A]) (Σ, Ω) := check({start(C[R, A]).2}, ∅, A, ²) if Ω 6= ∅ return true else return false

Algorithm 2: Detecting absent channels 1 2 3 4 5 6

isRedundant (C[R, A]) (Σ, Ω) := check({start(C[R, A]).2}, ∅, A, ²) for each σ ∈ Σ do for each ri (i ∈ {1, . . . , n}) do if (σri ).K − (σri ).U 6= ∅ return true return false

Algorithm 3: Detecting redundant channels required channels under a state σ, then it is inserted into Ω, otherwise the known and used channel sets K and U of each role under current channel state σ are updated, and the algorithm goes on to check the continuation Ac . For a sequential composition, the first activity is checked in advance, while the second is saved for later work. If we meet a choice, each branch is checked with Ac and the resulted sets from each branch are combined using a union operator defined below: (Σ1 , Ω1 ) ∪ (Σ2 , Ω2 ) = (Σ1 ∪ Σ2 , Ω1 ∪ Ω2 ) For a parallel composition, the algorithm checks each branch separately and merges the results using operator “⊕”as defined below, then goes on with the continuation. def

Σ1 ⊕ Σ2 = {σ1 ⊕ σ2 | σ1 ∈ Σ1 , σ2 ∈ Σ2 }

(2)

where σ1 ⊕ σ2 is defined in (1). This implies Σ ⊕ ∅ = ∅ for any Σ. Algorithm isAbsent (Algorithm 2) utilizes the result obtained by check to test whether a given choreography is channel-absent. It returns true if the set Ω returned from check is not empty. Here Ω is the set of interactions that are failed to be executed due to the channel absence. Otherwise, it returns false. Algorithm isRedundant (Algorithm 3) tests whether a given choreography is channel redundant by using the result of check. Concretely, it compares known channels and used channels of each role in each terminal channel state of Σ. We give those three algorithms separately to provide some helpful information rather than a simple boolean value to the users. If time and memory were concerned, we can combine check with isAbsent or isRedundant to avoid recording all the terminated states and return as soon as finding something unsuitable. On the other hand, the algorithms can be enhanced to generate the failure path and point out which is the exact interaction where the activity can not going on. 3.3 Generating Channel Passing For a static checker or a compiler, its duty is finding out erroneous codes and giving error messages and/or warnings. How to handle these message is the responsibility of 8

the programmers. Of course, it is helpful if the compiler was smarter which could repair the errors it has found. For a channel-absent choreography, can we have algorithms to repair it automatically? The answer is yes, and we have several different approaches. We will discuss them in this section and give an incomplete algorithm. There are three situations which will lead to a channel-absent choreography: 1. The initial channel sets of some roles in the choreography are not sufficient. 2. The interaction flows among roles of a choreography are not sufficient to carry on the work. 3. Some roles may not pass enough channels to their partner for them to proceed. For each of these situations, we can take a corresponding approach to fix the problem. For instance, if we find that role ri lacks channel ch in an interaction, we can add ch into the initial channel set of ri , or add an interaction from some role who knows ch to send it to ri . Both of these two methods seem to be ok, but in fact they may introduce new problems in addition to repair channel absence. The reason is that the initial known channel sets of each role and the interaction flows in a choreography are decided by standard business practice. It is not wise for us to generate choreographies that may not satisfy business requirements. We will also propose an algorithm for repair channel absent choreographies, in which we consider only the third problem listed above. In many time we can not distinguish these cases. An example is C[{r1 [op , ∅], r2 [op , {ch, ...}]}, (r1 → r2 , op, ch, ∅)]. Role r1 doesn’t know channel ch, the mistake is either designer forgetting to add ch into r1 ’s initial set or missing an interaction from r2 to r1 which passing ch. The other two cases are both possible corresponding with different business scenarios. How to make a choice is beyond the scope of computer science and the ability of checker. Thus, if a choreography can not be repaired by our algorithm, the designer should discuss the problem with the business manager and try to find a solution for it. Thus, on the other hand, our algorithm is relative complete with respect to our considerations. In the following, we will focus on the third situation listed above and assume the initial known channel sets of each role and interaction flows in a choreography are given and unchangable. Based on this assumption, we will develop algorithms to indentify the absent channels in the choreography, and try to repair them by generating channel passing in the choreography. Auxiliary definitions For developing the channel generating algorithm, we need an auxiliary algorithm for repairing absent channels. In order to repair, we need to record the paths that get to each role during checking the choreography. In the case that a role ri is missing channel ch for the execution of an interaction, we need check all the potential execution paths that get to ri , find out some role rj who knows ch, and generate a channel passing from rj to ri . During the repair procedure, some interactions on the path getting to ri may be modified by adding in a new channel to pass. For this to be done, it is necessary to define an interaction environment ∆ to reflect the updates of interactions. The ∆ is defined as a function which maps an interaction identity I to its definition (the corresponding interaction). For convenience, we use ∆(I).rf to denote the sender 9

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

repair (σt , ∆, h, r) for each t ∈ (σt r).T do t.cur := t.tail Ttemp := (σt r).T while Ttemp 6= ∅ do for each t ∈ Ttemp do if h ∈ t.cur.2 then do { I := t.cur.1 ∆(I).H ∪= {h} σt (∆(I).rt ).K ∪= {h} t.cur := succ(t.cur) } while (t.cur ! = hi) return (σt , ∆, true) else if isHead(t.cur) then Ttemp −= {t} else t.cur := prev(t.cur) return (σt , ∆, false)

Algorithm 4: Repairing channel-absent chorography

of interaction I, ∆(I).rt for the receiver, ∆(I).op for the operation, ∆(I).h for the channel, and ∆(I).H for the set of channel passing during the interaction. We will denote ∆(I).rf as I.rf for short, if it is not ambiguous. So do I.rt and I.H . Now we define first the concept of a path. Definition 4. (Path) A path t is a finite sequence t = h(I0 , K0 ), (I1 , K1 ), . . . , (In , Kn )i, where Ii is an interaction, and Ki is a channel set which is known by Ii .rf , and for each j ∈ {1, . . . , n}, Ij .rf = Ij−1 .rt . When we maintain all the paths with information as the definition in tracing the execution, if we meet an interaction which can not be executed due to channel-absence in some roles, we can use the information recorded in the pathes to find a suitable way to fill in the gap. This is the basic idea behind the algorithm. The algorithm repair (Algorithm 4) takes input σt , ∆, h, and r. Here σr is a map similar to σ used in our semantics, but maps each role to a pair (K, T ), where K is the current known channel set of the role, and T is the set of paths getting to the role. Besides, ∆ is the interaction environment described above, r is the role who is missing channel h. The algorithm returns tuple (σt , ∆, true) if it has successfully completed repair, otherwise, it returns (σt , ∆, false). Here σt may be modified by the algorithm since the known channel sets of some roles may be changed when we add some new channel passing. The algorithm is in fact a breadth-first search on all the paths. As used before, here (σt r).K is the known channel set of role r, and (σt r).T is the path set. We use t.cur to denote the current checking node (I, K) in path t, t.cur.1 denotes the interaction I in (I, K), and t.cur.2 denotes the known channel set K in (I, K). The notation succ(t.cur) and prev(t.cur) denotes the successor and predecessor of current check10

1 2 3 4 5 6

absent(σt , A, ri , rj ) if A is of form (ri ↔ rj , op, h, H ) then Y := {h | h ∈ / (σt rj ).K ∪ H } else Y := {} X := {x | x ∈ H ∪ {h} ∧ x ∈ / (σt ri ).K} return (X, Y )

Algorithm 5: Finding out absent channels

ing node in path t. Further, t.tail denotes the last node in t, and isHead(t.cur) tests whether current node is the head of t. In line 2, the current checking node of each path in (σt r).T is initiated to the tail node of the path. The for loop checks the current node of each path one by one. If the current node of path t knows h, then some interactions on path t will be updated by adding new channel passing, and repair returns successfully. If path t reaches its head, we delete t from (σt r).T . Otherwise, we move the current item forward through path t. When the path set (σt r).T becomes empty, which means it is impossible to repair the required channel on role r, the algorithm returns unsuccessfully. Using the breadth-first style, we will always find the shortest repairing path, that is, the repairing by adding minimum number of new channel passing. Moreover, we need two more auxiliary algorithms that are defined as follows. The algorithm absent (Algorithm 5) takes input as σt , A, ri and rj . Here A is an interaction, the roles ri and rj are participants of A. After the algorithm, the absent channels X on role ri and absent channels Y on role rj for executing the interaction A under σt are returned. The algorithm repairM (Algorithm 6) takes input as σt , ∆, ri , X, rj and Y . Here X and Y are sets of absent channels on role ri and rj . For repairing each absent channel, it will call algorithm repair defined before. When one of absent channels is failed to be repaired, the algorithm returns tuple (σt , ∆, false). In the case that all the absent channels are repaired successfully, the algorithm returns (σt , ∆, true). The σt and ∆ returned from the algorithm may be changed due to the adding of new channel passings. Generating algorithm The algorithm generate (Algorithm 7) takes Σt , Ωt , ∆, A, and Ac as inputs, and returns a tuple of the form (Σt , Ωt , ∆). Here Σt is a set of σt defined in subsection 3.3, Ωt is the set of interactions in the choreography that lack channels for execution and fail to be repaired, ∆ is the interaction environment. A and Ac have the same meaning as for the algorithm check. Initially, we call generate with the Σt as a singleton set {σt0 }, where for each role ri (i ∈ {1, . . . , n}), (σt0 ri ).K takes the known channel set for role ri , and (σt0 ri ).T is an empty set. The initial argument for Ωt is also an empty set, and ∆ maps each interaction identity in choreography to its definition. When the algorithm finishes, Σt contains all possible known channel states of each role and paths getting to the role in the successful termination configuration with the help of the channel repair procedure. The set Σt may be empty, which means there is no potential execution path can be 11

1 2 3 4 5 6 7 8 9 10 11 12 13 14

repairM (σt , ∆, ri , X, rj , Y ) if X! = ∅ then foreach x ∈ X do (σt0 , ∆0 , b0 ) := repair(σt , ∆, x, ri ) if ¬b0 then return (σt , ∆, false) σt := σt0 ; ∆ := ∆0 end if Y ! = ∅ then for each y ∈ Y do (σt0 , ∆0 , b0 ) := repair(σt , ∆, y, rj ) if ¬b0 then return (σt , ∆, false) σt := σt0 ; ∆ := ∆0 end return (σt , ∆, true)

Algorithm 6: repairing multiple absent channels

repaired or terminated normally. ∆ returned from algorithm reflects the updates of some interaction definitions by adding new channel passing. In the algorithm, if the current activity A is an interaction, then for each σt in Σt , firstly calls the algorithm absent defined in 3.3, and finds out the absent channels on both participants of A under σt . If one of sets of absent channels returned are not empty, the algorithm repairM defined in 3.3 is called to repair multiple absent channels. Lines 12 and 13 deal with the situation when the repair of all the absent channels on both participants are failed. Here we simply record the interaction A by adding it to set Ωt . In addition, σt is deleted from Σt . The “continue” means to return for next cycle. For the successful repair of all absent channels, the algorithm need update σt and ∆ with corresponding values returned from repairM. Either successful repair of absent channels or no channel absence situation, we need update the set of paths getting to role rj as follows: If set σt (ri ).T is not empty, then we create a new path getting to rj by concatenating each path in σt (ri ).T with hI, σt (ri ).Ki, and add it to σt (rj ).T . If path set σt (ri ).T is empty, then we simply add hI, σt (ri ).Ki to the path set σt (rj ).T . The whole structure of the algorithm is similar to algorithm check in Section 3.2, especially the cases for composition structures. The operator “⊕” for σt and Σt are defined similarly as the definition in equations (1) and (2). In the algorithm, we use operator “⊗” for two interaction environments ∆1 and ∆2 which have the same domain, and all components in their range are the same, except the H . Here is the definition:  ∆(Ii ).rf = ∆1 (Ii ).rf      ∆(Ii ).rt = ∆1 (Ii ).rt ∆(Ii ).op = ∆1 (Ii ).op ∆ = ∆1 ⊗ ∆2 iff   ∆(I  i ).h = ∆1 (Ii ).h   ∆(Ii ).H = ∆1 (Ii ).H ∪ ∆2 (Ii ).H for each i ∈ {1, . . . , n} Here we present an simple example to illustrate the usage of the algorithm.

12

(3)

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

generate(Σt , Ωt , ∆, A, Ac ) if Σt = ∅ ∨ A = ² then return (Σt , Ωt , ∆) switch according to the form of A do case skip: skip case (ri → rj , op, h, H ) or (rj ← ri , op, h, H ) or (ri ↔ rj , op, h, H ) : foreach σt ∈ Σt do (X, Y ) := absent(σt , A, ri , rj ) if X 6= ∅ ∨ Y 6= ∅ then (σt0 , ∆0 , b0 ) := repairM(σt , ∆, ri , X, rj , Y ) if b0 == false then Ωt ∪= {A}; Σt −= {σt }; continue else σt := σt0 ; ∆ := ∆0 (σt rj ).K ∪= H if σt (ri ).T 6= ∅ then for each t ∈ σt (ri ).T do σt (rj ).T ∪= {ta hA, σt (ri ).Ki} else σt (rj ).T ∪= {hA, σt (ri ).Ki} end case A1 ; A2 : returngenerate(Σt , Ωt , ∆, A1 , A2 ; Ac ) case A1 k A2 : (Σt0 , Ωt0 , ∆1 ) := generate(Σt , Ωt , ∆, A1 , ²) (Σt00 , Ωt00 , ∆2 ) := generate(Σt , Ωt , ∆, A2 , ²) return generate(Σt0 ⊕Σt00 , Ωt0 ∪ Ωt00 , ∆1 ⊗ ∆2 , Ac , ²) case A1 u A2 : (Σt0 , Ωt0 , ∆1 ) := generate(Σt , Ωt , ∆, A1 , Ac ) (Σt00 , Ωt00 , ∆2 ) := generate(Σt , Ωt , ∆, A2 , Ac ) return (Σt0 ∪ Σt00 , Ωt0 ∪ Ωt00 , ∆1 ⊗ ∆2 ) end return generate(Σt , Ωt , ∆, Ac , ²)

Algorithm 7: Generating channel passing

Example 1. Suppose we have three roles defined as: r1 [op , {h1 , h2 , h3 , h4 }], r2 [op , {h2 }], r3 [op , {}]; There are four interactions: I1 → 7 (r1 → r2 , op, h1 , ∅) I2 7→ (r2 → r3 , op, h2 , ∅) 7 (r1 → r3 , op, h3 , ∅) I4 → 7 (r3 → r2 , op, h4 , ∅) I3 → which form an activity A = I1 ; (I2 u I3 ); I4 . Now suppose C1 is a choreography with roles {r1 , r2 , r3 } and activity A. Now let us check C1 with the algorithm generate. Initially, set Σt has only a single element σt0 , where σt0 = {r1 7→ ({h1 , h2 , h3 , h4 }, ∅), r2 7→ ({h2 }, ∅), r3 7→ (∅, ∅)}. Ωt is an empty set, and ∆ is the interaction environment, which maps each interaction identity to its definition. 13

The algorithm generate is executed with these initial parameter values, and with A as the current activity and ² the continuation activity. After I1 is handled, (σt r2 ).T contains only one path h(I1 , {h1 , h2 , h3 , h4 })i. Then a choice with two branches is encountered; those branches are handled by generate(Σt , Ωt , ∆, I2 , I4 ) and generate(Σt , Ωt , ∆, I3 , I4 ) respectively. After finishing the treatment of I2 , we have Σt0 = {σt0 }, where σt0 is the same as the σt except that (σt r3 ).T has one path h(I1 , {h1 , h2 , h3 , h4 }), (I2 , {h2 })i. Then the algorithm goes on with I4 . Since the required channel h4 is not known by role r3 , repair(σt0 , ∆, r3 , h4 ) is executed. The only path getting to role r3 is checked from the tail node to the head. Since the node (I1 , {h1 , h2 , h3 , h4 }) on the path knows the channel h4 , the algorithm updates the definition of interaction I1 by passing channel h4 , revising the interaction to (r1 → r2 , op, h1 , {h4 }), and adding the passing into the interaction I2 from r2 to r3 , thus the definition of I2 becomes (r2 → r3 , op, h2 , {h4 }). The second branch is checked and repaired in the same way. During the repair for the absence of channel h4 on role r3 , the definition of interaction I3 is revised by adding a new channel passing for h4 . After the whole algorithm finishes, Σt contains σt0 and σt00 obtained from two branches respectively. The set Ωt is still empty since all the absent channels have successfully repaired. The interactions in ∆ has changed as follows: I1 → 7 (r1 → r2 , op, h1 , {h4 }) I2 7→ (r2 → r3 , op, h2 , {h4 }) I3 → 7 (r1 → r3 , op, h3 , {h4 }) I4 → 7 (r3 → r2 , op, h4 , ∅) This finishes the example.

4 An Example This section demonstrates the expressiveness of the language Chorc and the semantics with a business protocol. The example comes from the dynamic routing example of service interaction patterns in [5]. After illustration of the protocol, we present the description of the protocol using Chorc . We also show how to statically check channel passing in a Chorc choreography. 4.1 Informal Description In the Figure 1, six roles involve in this protocol: Buyer (B), Sales department (S), Finance (F), Warehouse (W), Shipper nominated by the buyer (SH b), and the default Shipper (SH w) known by the warehouse. The protocol describes a process in which the buyer makes a purchase order for a product to the sales department. After processing the received order, the sales department sends a request to the finance department to process to generate an invoice and payment receipt for the order. This request contains a reference to the buyer’s procurement service and possibly also to a shipping service nominated by the buyer. After arranging invoicing and payment by interacting directly with the buyer, the finance service forwards the order to the warehouse service. The warehouse issues a request to a shipping service which may be either the company’s default shipping service, or the one originally nominated by the buyer. The shipping service eventually sends a shipping notification directly to the buyer. 14

Buyer(B)

Warehouse (W)

Finance(F)

Sales(S)

Shipper_B (SH_b)

Shipper_W (SH_w)

POReq,chs,{chb} PayReq,chf,{chb} payment,chb,{} pickReq,chw,{chb}

Alt

ShipReq,chsb,{chb}

ShipReq,chsw,{ chb} notify,chb,{}

Order Purchase Choreography

Figure 1. Order Purchase Choreography

4.2 Representation in Chorc Now we give the formal description of above protocol using our language Chorc . In the following, we will use names B, S, F, W , SHb and SHw to denote the six roles respectively, and use hb , hs , hf , hw , hsb and hsw for corresponding channels to these roles. Particularly, hsb refers to the channel to the shipper SHb nominated by the buyer, and hsw refers the channel to the default shipper known by warehouse. For convenience, we attach labels Ii (i = 0, · · · , 7) to each of the interactions in the protocol. Initially, based on the protocol, each role have to know some channels for carrying on the interactions. For instance, the buyer must know the channel hs referring to sales department and the channel hsb referring to its nominated shipper service. Each of the roles knows the channel referring to itself. Here are the role declarations of the protocol, in which each role has been associated to an initial channel set. B [{payment}, {hb , hs , hsb }] S [{poReq}, {hs , hf }] F [{payReq, }, {hf , hw }] W [{pickReq}, {hw , hsw }] SHw [{shipReq, notif y}, {hsw }] SHb [{shipReq, notif y}, {hsb }] 15

Following the informal description of the protocol, we (might) write down, in the first, the activity A of the choreography as follows: I0 I1 I2 I3

:: :: :: ::

(B → S, poReq, hs , {hb }) ; (S → F, payReq, hf , {hb }) ; (F ↔ B, payment, hb , {}) ; (F → W, pickReq, hw , {hb }) ; { I4 :: (W → SHb , shipReq, hsb , {hb }) ; I5 :: (B ← SHb , notif y, hb , {}) u I6 :: (W → SHw , shipReq, hsw , {hb }) ; I7 :: (B ← SHw , notif y, hb , {}) }

This completes a formal representation of the protocol as a choreography. It is really not easy to see whether some defects related channel passing will be happened in this choreography. With the formal model and the algorithms presented before, we can formally make the judgment. Using function start defined in Section 2.2, we obtain the initial channel state σ0 of the execution as follows. σ0 = {B 7→ ({hb , hs , hsb }, {}), S 7→ ({hs , hf }, {}), F 7→ ({hf , hw }, {}), W 7→ ({hw , hsw }, {}), SHw 7→ ({hsw }, {}), SHb 7→ ({hsb }, {})}

4.3 Analysis of Channel Passing

Now we can run the algorithm check to generate the two sets Σ and Ω. We start from initial interaction I0 , going through each interaction in the control flow of the choreography, and checks whether the required channel is available on the sender of the interaction. With the choreography defined above, we find that the interaction I1 , I2 and I3 are all fine. However, interaction I4 is not executable because when the execution arrives to the point where interaction I3 completes, role W (the warehouse) does not know the channel hsb , thus the execution gets stuck. To solve this problem, we can first pass channel hsb from role B to role S, then from S to F , finally from F to W . We can also use the algorithm generate to get suggestions for repairing the choreography. After the correction, the revised activity of the choreography is depicted as follows: 16

I0 I1 I2 I3

:: :: :: ::

(B → S, poReq, hs , {hb , hsb }) ; (S → F, payReq, hf , {hb , hsb }) ; (F ↔ B, payment, hb , {}) ; (F → W, pickReq, hw , {hb , hsb }) ; { I4 :: (W → SHb , shipReq, hsb , {hb }) ; I5 :: (B ← SHb , notif y, hb , {}) u I6 :: (W → SHw , shipReq, hsw , {hb }) ; I7 :: (B ← SHw , notif y, hb , {}) }

5 Related work In recent years, many researches pay attentions on the study of the formal foundation of choreography based on process calculi. Brogi et al. [8] presented a formalization of Web Service Choreography Interface (WSCI) using CCS [22], and discussed the benefits of such formalization. In [10], Busi et al. proposed a simple choreography language whose main concepts are based on WS-CDL. Foster et al. [18] discussed a modelbased approach to verify web service compositions. In [29], Zaha et al. presented the language Let0 s Dance for modeling service choreography targeting the early phases of the development life cycle. The language Let0 s dance main focuses on the control flow aspect of choreography, and simply denotes elementary interaction as atomic. Decker et al. provided an execution semantics for this language in [15]. The semantics is defined in terms of a translation to π-calculus [24]. There are some literatures on the modeling of interactions in choreography. In [20], Gorrieri et al. presented the formal semantics of a significant fragment of WS-CDL that provides a mean to deal with interactions, and reasoned about the adequacy of such interaction patterns when the alignment property is considered. However, they did not model channel and channel passing in the interactions. In [13], Carbone et al. defined a “global calculus” originated from WS-CDL based on the session types. A session is initiated by a service channel with fresh session channels and interactions. An interaction is the in-session communication over a session channel. This global calculus does not pay attentions on the complex channel passing issues. For pushing the service composition technology to progress further, Barros [5] presented a collection of patterns of service interactions that allow emerging web services functionality to be benchmarked against abstracted forms of representative scenarios. The example presented in this paper comes from this paper. Decker [16] used π-calculus for representing several of these service interaction patterns, but it is still not clear stated how to analyze the channel passing in their formalization. As for the projection and conformance validation between choreography and orchestration, much work has been carried out, while much is still on going. Carbone et al. [14] studied the description of communication behaviors from both global message 17

flows and end-point behavior levels respectively. Three principles for well-structured global description and a theory for projection are developed. In [9], Busi et al. formalized conformance with a bisimulation-like relation. In their another paper [11], the notion of state variables in the semantics of the orchestration model is used to build a relation between choreography to orchestration operationally. By means of automata, Schifanella et al. [4] defined a conformance notion that tests whether interoperability is guaranteed. Fu et al. [19] specified a conversation protocol by a realizable B¨uchi automaton, and the peer implementations are synthesized from the protocol via projection. Bravetti and Zavattaro [7] proposed a theory of contracts for conformance checking. They defined an effective procedure that can be used to verify whether a service with a given contract can correctly play a specific role within a choreography. Moreover, Decker et al. discussed the issue of local enforceability of Let’s Dance choreographies in [17]. Aalst [26] focuses on conformance by comparing the observed behavior recorded in logs with some predefined model. All the literatures above did not model and analyze channel passing in their interaction models. We have previously provided a small language with operational semantics [28], which is a formal model of the simplified WS-CDL. Based on the formal model, we can project a given choreography to orchestration views, which provided a basis for the implementation of the choreography by a number of web services [31]. Particularly, in [23], we defined the concept of restricted natural choreography that is easily implementable, and proposed two structural conditions as a criterion to distinguish the restricted natural choreography. In the paper, we proposed the concept dominator role and proposed two language structures, namely dominated choice and dominated loop, and discussed their usage in choreography. Moreover, [27] defined a collection of rules that can be used to statically check whether a choreography is well-typed.

6 Conclusion and Future Work Inter-organizational business processes are composed of relatively autonomous roles. There is no central role to control the composite behavior of various participant services. Moreover, the roles taken part in a choreography may not know each other at the beginning, and each role may or may not have prior knowledge of the channels of all roles with which it will cooperate in the future. Channel passing refers to the ability that a sender role rf passes some channels to a receiver role rt in an interaction. The channels passed from rf to rt will allow rt to fully identify and interact with some other roles in the following interactions of choreography. Therefore, it is essential that each of the channel passing involved in the interactions of choreography should be carried out as the receiver roles expect. In this paper we demonstrated the feasibility of checking channel passing activities in choreography. Especially, we show that it is possible to detect the absence and redundance of channels, and to generate automatically channel passing in the case of the absence of channels. Due to the focus of this work, we have not put some other features of WS-CDL into consideration, such as fault handling and timeout. Some real business protocols, e.g., those protocols presented in Carbone et al. [12] and Barros et al. [5] involve in 18

service interactions with faults and timeout. As a future work, we plan to to extend our interaction model with these features and analyze related properties. As another direction, we observe that most choreography models presented currently are abstracted from data flows, and focus only on the interaction flows. Some people proposed the artifact-centric approach which couples control and data into a framework and has emerged in the practice of business process design [6]. Actually, in the dynamic routing pattern presented in [5], there is a requirement on expressing forwarding a purchase order from one service to another service. Here the order is something like an artifact, which has a life cycle from creation to completion through interaction flows. Therefore, we are thinking to introduce artifact concept to choreography for modeling artifact-centric business protocols. Acknowledgments We would like to thank Prof. Sharon Murrel for many useful comments on the presentation.

References 1. Web services choreography description language (WS-CDL), version 1.0, 2005. http://www.w3.org/ TR/2005/CR-ws-cdl-10-20051109/. 2. Business process execution language for web services (BPEL4WS), version 1.1, May 2003. http://www.ibm. com/developerworks/webservices/library/ws-bpel/. 3. A. Arkin. Business process modeling language, November 2002. http://www.bpmi.org. 4. M. Baldoni, C. Baroglio, A. Martelli, V. Patti, and C. Schifanella. Verifying the conformance of web services to global interaction protocols: A first step. In EPEW/WS-FM, volume 3670 of LNCS, pages 257–271. Springer, 2005. 5. Alistair P. Barros, Marlon Dumas, and Arthur H. M. ter Hofstede. Service interaction patterns. In Business Process Management, volume 3649, pages 302–318, 2005. 6. Kamal Bhattacharya, Cagdas Gerede, Richard Hull, Rong Liu, and Jianwen Su. Towards formal analysis of artifact-centric business process models. Business Process Management, pages 288–304, 2007. 7. M. Bravetti and G. Zavattaro. Towards a unifying theory for choreography conformance and contract compliance. In Proc. of Software Composition’07. Springer, 2007. 8. Antonio Brogi, Carlos Canal, Ernesto Pimentel, and Antonio Vallecillo. Formalizing web service choreographies. Proc. of WS-FM 2004, Electr. Notes Theor. Comput. Sci, 105:73– 94, 2004. 9. N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and orchestration: A synergic approach for system design. In Service-Oriented Computing - ICSOC 2005, Amsterdam, Netherlands, December 12-15, 2005, Proceedings, volume 3826 of LNCS, pages 228–240. Springer, 2005. 10. N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Towards a formal framework for choreography. In WETICE’05. IEEE Computer Society, 2005. 11. N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and orchestration conformance for system design. In Coordination Models and Languages- COORDINATION 2006, Bologna, Italy, June 14-16, 2006, Proceedings, volume 4038 of LNCS, pages 63–81. Springer, 2006. 12. M. Carbone, K. Honda, N. Yoshida, R. Milner, G. Brown, and S. Ross-Talbot. A theoretical basis of communication-centred concurrent programming. Technical report, To be published by W3C., 2006. Available at http://www.dcs.qmul.ac.uk/ carbonem/cdlpaper/workingnote.pdf.

19

13. Marco Carbone, Kohei Honda, and Nobuko Yoshida. A calculus of global interaction based on session types. In Electronic Notes in Theoretical Computer Science (ENTCS), volume 171. Elsevier Science Publishers B. V. Amsterdam, Netherlands, 2007. 14. Marco Carbone, Kohei Honda, and Nobuko Yoshida. Structured communication-centred programming for web services. In ESOP, volume 4421 of LNCS, pages 2–17. Springer, 2007. 15. G. Decker, J. M. Zaha, and M. Dumas. Execution semantics for service choreographies. In Proc. of WS-FM 2006, LNCS 4184. Springer, 2006. 16. Gero Decker, Frank Puhlmann, and Mathias Weske. Formalizing service interactions. In BPM, volume 4102 of LNCS, pages 414–419. Springer, 2006. 17. Gero Decker and Mathias Weske. Local enforceability in interaction petri nets. In BPM, volume 4714 of LNCS, pages 305–319. Springer, 2007. 18. H. Foster, S. Uchitel, J. Magee, and J. Kramer. Model-based analysis of obligations in web service choreography. In Proc. of International Conference on Internet and Web Applications and Services 2006. IEEE CS, 2006. 19. X. Fu, T. Bultan, and J. Su. Conversation protocols: A formalism for specification and verification of reactive electronic services. Theoretical Computer Science, 328, 2004. 20. Roberto Gorrieri, Claudio Guidi, and Roberto Lucchi. Reasoning about interaction patterns in choreography. In EPEW/WS-FM, volume 3670 of LNCS, pages 333–348. Springer, 2005. 21. Frank Leymann. Web services flow language (WSFL 1.0), May 2001. http://www.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf. 22. Robin Milner. Communication and Concurrency. Prentice Hall, 1989. 23. Zongyan Qiu, Xiangpeng Zhao, Chao Cai, and Hongli Yang. Towards the theoretical foundation of choreography. In Proc. of WWW 2007, Banff, Canada. ACM, 2007. 24. Davide Sangiorgi and David Walker. The π-Calculus: a Theory of Mobile Processes. Cambridge University Press, New York, NY, 2001. XLANG web services for business process design, 2001. 25. S. Thatte. http://www.gotdotnet.com/team/ xml wsspecs/xlang-c/default.htm. 26. W.M.P. van der Aalst, M. Dumas, C. Ouyang, A. Rozinat, and H.M.W. Verbeek. Choreography conformance checking: An approach based on BPEL and Petri Nets (extended version). Technical report, BPM Center Report BPM-05-25, BPMcenter.org, 2005. 27. Hongli Yang, Xiangpeng Zhao, Zongyan Qiu, Chao Cai, and Geguang Pu. Type checking choreography description language. In 8th International Conference on Formal Engineering Methods, ICFEM 2006, Macao, China, November 1-3, 2006, Proceedings, volume 4260 of LNCS, pages 264–283. Springer, 2006. 28. Hongli Yang, Xiangpeng Zhao, Zongyan Qiu, Geguang Pu, and Shuling Wang. A formal model for web service choreography description language (WS-CDL). In Proc. of ICWS’06, pages 893–894. IEEE Computer Society, 2006. 29. Johannes Maria Zaha, Alistair P. Barros, Marlon Dumas, and Arthur H. M. ter Hofstede. Let0 s Dance: A language for service behavior modeling. In OTM Conferences (1), pages 145–162, 2006. 30. Johannes Maria Zaha, Marlon Dumas, Arthur ter Hofstede, Alistair Barros, and Gero Decker. Service interaction modeling: Bridging global and local views. In the 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC’06), 2006. 31. Xiangpeng Zhao, Hongli Yang, and Zongyan Qiu. Towards the formal model and verification of web service choreography description language. In Web Services and Formal Methods, Third International Workshop, WS-FM 2006, Vienna, Austria, September 8-9, 2006, Proceedings, volume 4184 of LNCS, pages 273–287. Springer, 2006.

20