+ . . . . . .
The assign construct enables to copy messages from one variable to another. The variables are the one declared in the top variable tag. More than just copy, the assign construct permits the use of general expressions (see Section 3.2.3) to perform simple computation often required to define a business process, and assigning the result to a variable.
3.2.5
Structured Activities
The sequence activity [ Activity ] +
A sequence construct contains a list of activities, basic or structured, that must be executed sequentially, following the order in which they are listed. The sequence activity completes when the last activity of the sequence has completed. The switch activity + [ Activity ]
CHAPTER 3. BPEL
33
[ Activity ]
The switch construct permits to define different behaviors of the process depending on boolean condition. The first activity whose condition is true will be executed. If all conditions are false the activity in the otherwise construct is executed, or an empty activity if the otherwise is not present. The boolean conditions are defined in Section 3.2.3. The while activity [ Activity ]
The while activity will execute the inner activity, basic or structured, as long as the boolean condition is true. The pick activity + [ Activity ] ∗ [ Activity ]
The pick activity is waiting for events to happen. To each event is associated an activity. The first occurring event will trigger the associated activity. All the subsequent event will be ignored. The pick activity completes when the triggered task completes. There are basically two types of events. The first type is the arrival of a message, i.e. a partner invokes an operation, defined with a onMessage construct, similar to a receive activity. The second kind of event is alarm based. It can be defined, as in the case of the wait activity, with a duration or an absolute deadline. It is defined with the onAlert element. The flow activity
CHAPTER 3. BPEL
34
< l i n k s> [ Activity ] +
The flow construct permits launching several activities concurrently. The links defined in the flow scope permits to enforce precedence between these activities, i.e. it permits synchronization. We present the link semantics in Section 3.2.6. The flow activity completes when all activities in the flow have completed. Completion of an activity however includes the possibility of it to be skipped. This happens when its enabling condition is false. This is explained in the Dead-Path-Elimination Section (3.2.6). The scope activity . . . . . . . . . . . . . . . [ Activity ]
The scope constructs defines the context, i.e. local variables, fault handlers, compensation handlers and others, of the enclosed activities. Its structure is similar to the process constructs. The compensate activity [ Activity ]
Compensation handlers permit recovering from a fault on a case by case basis, its role is to recover to the state before the activity started. The compensation handler will be called with the following rule: ’Run all available compensation handlers for immediately enclosed scopes in the reverse order of completion of the corresponding scopes’. However a compensation handler can also be called explicitly through the compensate constructs.
CHAPTER 3. BPEL
3.2.6
35
Links
The link construct enables the expression of synchronization between concurrent activities, that is somewhere in the scope of a flow element. A link has a name, a source and a target. In its simplest expression, the link express the fact that the target activity waits for the source activity to complete. Links are declared as children of the flow construct (see Section 3.2.5). Any activity can be declared source or target of a link, via the source or target attribute respectively. Each link must have exactly one source and one target. The source activity may also declare a transition condition through the transitionCondition attribute. This condition when evaluated, just after the source activity completes, will determine the status of the link: positive or negative if the condition evaluates to true or false respectively. The status of the link will determine if the target activity is executed or skipped. The target activity can also specify a join condition, i.e. boolean function dependent on the incoming links’ status, that will define if the activity will be executed or skipped. To determine if a concurrent activity can start or must be skipped three steps are taken. First it should be checked that without join condition the activity can start. Next, the status of all its incoming link should be determined (the source activities must have completed or been skipped). Finally, the activity is executed if the join condition evaluates to true and skipped otherwise. In case of normal execution the transition condition sets the status of the outgoing links, or, if absent, they are set to positive. however, if an activity is skipped, because its join condition evaluates to false, then all its outgoing links’ status are set to negative. The idea is that links set to false will lead to other activities being skipped. This phenomenon is called Dead-PathElimination. Example < l i n k s>
CHAPTER 3. BPEL
36
3.3
Conclusion
In this chapter, we presented the main concepts of the BPEL language. We saw that BPEL has four main characteristics. Firstly, BPEL has built-in constructs to interact with external WSDL Web Services through the invoke, receive, reply and throw constructs. Secondly, all data and messages are encoded in XML documents with a strong incentive to use XML Schema as the data type definition system. Thirdly, the data manipulation is done through XPath expressions. Finally, the flow construct associated with the link concept enables out-of-the-box definitions of concurrent executions.
Chapter 4 Model Checking BPEL Services Contents 4.1
4.2
4.3
Petri Nets model . . . . . . . . . . . . . . . . . . .
38
4.1.1
Mapping BPEL into Petri Nets . . . . . . . . . . . 38
4.1.2
Static Analysis of BPEL Processes . . . . . . . . . 43
Guarded Automata Model . . . . . . . . . . . . .
45
4.2.1
Guarded Automata Peers Model . . . . . . . . . . 46
4.2.2
LTL Properties . . . . . . . . . . . . . . . . . . . . 47
4.2.3
From BPEL to Guarded Automata to Promela . . 48
4.2.4
Results . . . . . . . . . . . . . . . . . . . . . . . . 52
Conclusions . . . . . . . . . . . . . . . . . . . . . .
53
Model checking of BPEL services has been the attention of quite a lot of works recently. In [3, 8] the authors use finite state machine models to formalize and check LTL properties of BPEL processes. Their modeling stays at the control flow level, abstracting the data manipulation part of the process. Petri nets modelization is popular too. Indeed the control flow constructs found in BPEL are inspired by the concepts found in workflow definition languages and thus very close to them. The Petri net model has been shown to be a powerful tool to analyze workflow [23]. The Petri net based analysis of BPEL processes has been studied thoroughly in [15, 21, 31]. Abstract state machine models are also applied to the verification of BPEL processes in [5, 6]. Finally process algebra is also a natural fit to verify temporal logic properties as well as concurrent ones. Koshkina [16] verifies a simplified version of 37
CHAPTER 4. MODEL CHECKING BPEL SERVICES
38
BPEL, called the BPE-calculus, using the Concurrency Workbench of New Century (CWB), a general tool for verifying finite-state concurrent systems. Some efforts is also invested in process algebra in [7]. We choose to briefly introduce the Petri net modelization of van der Aalst et al. [18] since it is the first full formalization of control flow of BPEL processes. Moreover their formalization culminates in an automated tool that permits useful static verification. Finally we present, also very briefly, the work of Bultan et al. Their work [9] is the first attempt to verify BPEL processes including modelization of the data manipulation part of the process, i.e. the XPath expressions.
4.1
Petri Nets model
W. van der Aalst et al. validate the soundness of using Petri nets as a model for the analysis of the control flow of BPEL processes. This is achieved through a complete mapping of the control flow constructs onto Petri nets. As a first result, a fully complete formal semantics for BPEL processes at the control flow level is obtained [18]. This formal Secondly, a tool, wofBPEL [19] , automating this mapping and the static analysis of the resulting Petri net was developed. The automatic translation from BPEL to PNML, Petri net modeling language, is performed via BPEL2PNML. So that wofBPEL can statically analyze the corresponding Petri net and thus the modeled process. We briefly presents this mapping now.
4.1.1
Mapping BPEL into Petri Nets
Activity Activities are modeled as shown in Figure 4.1. An activity can have a number of targets (incoming links). For each of these targets we have two places, one for the positive status (true target) and one for the negative status of the link (false target). The join condition (see Section 3.2.6) is a boolean condition over the set of targets, it is modeled with the arcs linking the target and the ’sf’ and ’st’ transitions. There will be one ’st’ transition for each set of target values such that the join condition evaluates to true. And exactly one ’sf’ for each set of target values such that the join condition evaluates to false. When the activity has completed the transition ’et’ or ’ef’, depending if the activity has been skipped or not, forwards the token to the correct value of the sources and puts a token in the end place.
that will be traversed if this activity has either been completed or skipped. If skipped, the corresponding link will have a negative status. If completed, then an optional transition condition determines its status. The targets are the incoming st et start. Aend links that needstart to be traversed beforeActivity this activity can traversed target can have either a positive or started a negative status. completed CHAPTER 4. MODEL CHECKING BPEL SERVICES
false targets start
Fig. 2. Mapping for skipa link-less activity. sf
ef
39
false sources end
Figure 2 shows how we map an activity without sources or targets. Becaus Activity et st truemust refer trueflow activity highe ny source or target to some link defined in some targets sources started p in the hierarchy, the top activity in thecompleted hierarchy cannot have sources o rgets. Thus, this top activity will have exactly one source place (start) an Figure 4.1: Petri net representing an activity. xactly one sink place (endFig. ). 1. Mapping for an activity.
2
Figure 1 Links
The activity itself is a sub-petri-net, one of the constructs presented below. The source and target places are components of links that we present shows how we map this onto a Petri net fragment. The now.
place start contains a token if the hierarchical structure enables this activity. For every target, a trueLinks place and a false place are present. If the corresponding link has been traversed, either the true place contains a token (indicating that the link has a positive status) or the false false place contains a token false (indicating that the link ff sourcejoin condition is mappedtarget has a negative status). The onto a set of st (start true) transitions: One st transition for every valid combination of targets. For every tf invalid combination of targets, a sf (start false) transition is present. If the set of positive targets is valid, that to “true”, then the true true is, if the join condition evaluates tt target source activity is started. After the activity has been completed, the corresponding et (end true) transition forwards control to both the next activity in the hierarchical structure (through placeFigure end )4.2:and tonetthe sources.a Link If the Petri representing [25].set of positive targets is Fig. 3. Mapping for a link.
The links (see Figure 4.2), in the model of van der Aalst are actually a model of the transition condition. If the activity has been skipped, the false source has a token, this token is passed along to the negative target (deathIf theaprevious activity a executed the positive If the sourc gure 3 showspth-elimination). how we map link onto Petrinormally, net fragment. source has a token, which will be passed to the positive or negative targets ctivity was skipped, then place false source contains a token, and we simply hav following the transition condition of the BPEL process. For every source and of an path activity elimination) we will have such ato construct pass this negative control ontarget (dead the target activit modeling its link. However some activities don’t have any source, nor a hrough the place false target. If the source activity was completed, then plac target, these are simply modeled as below.
ue source contains a token, and the transition condition determines whethe positive control or a negative control needs to be forwarded. If the transitio ondition evaluates to “true”, then a positive control is forwarded through plac ue target (that is, transition tt fires), otherwise a negative control is forwarde hat is, transition tf fires). Note that transition tf (true false) is absent if n ansition condition is given for this link.
that a roll back will set the status of all its incoming links to positive. Because the activity had been started, its join condition must have been evaluated to “true”, and we assume that a join condition will evaluate to “true” if all incoming links have a positive status. Therefore, it seems safe to roll back to a state where all incoming links have a positive status. CHAPTER 4. MODEL CHECKING BPEL SERVICES
3.4
40
Sequence Activities Sequence
Activity A
Activity B
Activity C
started
completed
Fig. Mapping a sequence activity. Figure5.4.3: Petri net for representing a Sequence [25]. A Sequence construct is trivially modeled by putting the activities in sequence linking each activity to the next (Figure 4.3. The Sequence completes activity contains set of activities, and takes care of when the last activity ordered has completed.
A sequence executing these contained activities in the given order. Figure 5 shows how this can be Switch onto a Petri net fragment. (trivially) mapped between Activities A, B and5C (and can be in modeled in Figure to 4.4. come), it is AlthoughA itswitch is not shown in Figure manyas figures With one token in the started place, one of the Activities A, B or C will possible that links exists between enclosed activities. For example, there could execute. The actual switch condition is not modeled and thus is part of be links fromtheActivity to Activity C,model, fromit Activity tofor Activity ’black-box’Bassumptions of the is supposedA that any of theC, and there condition is some run inactivities which this condition be sequence. true. could be even links there to and from outsidewill the Figures 1 and Moreover in the BPEL specification a switch statement is an ordered sequence of activities with an associated condition, the first activity with its condition evaluating to true will be executed. This model, since it’s not taking into account the actual condition, cannot detect that an activity can never execute if, for example, its associated condition is true only when a prior activity’s condition is true. Finally the BPEL specification asks for an empty activity being executed when none of the condition is true. How the translation process deals with this problem is not clear (adding an empty activity or not?). While The while construct will execute Activity A as long as a condition is true (Figure 4.5). This model abstracts the condition and thus suppose Activity A will or will not execute eventually. The While activity completes as soon as the condition is false.
3 show how such links are mapped onto Petri net fragments, which extend the Petri net fragment resulting from Figure 5. CHAPTER 4. MODEL CHECKING BPEL SERVICES
3.5
41
Switch Activities
Activity A
Activity B started
completed Activity C
Fig. 6.4.4: Mapping a switch activity. Figure Petri net for representing a Switch [25].
A switch activity contains an ordered set of activities with associated conditions, and executes the first contained activity for which the associated condition evaluates to “true”. The last activity in the ordered set of activities can be an otherwise activity, for which the associated condition always evaluates to “true”. If no otherwise activity is present, an empty otherwise activity is considered present. ct Thus, one of the associated conditions will evaluate to “true”. Figure 6 shows how we can map this onto a Petri net fragment. Note that we abstract from the started Activity A actual conditions and the order in which they are evaluated. Also note that in case all conditions can evaluate to “false”, we need to add an empty activity, that is, a transition that forwards control from the started place to the completed completed cf place. Note that each of the activities in a switch may have links. As a result, parts of the model may not while they contain Figure 4.5:executed Petri netfor representing a activity. While [25]. links that may block Fig. 7. be Mapping a while concurrent activities. Although [5] is not completely clear about the semantics such constructs, the text “If, during the performance of structured activity S, thetransition semanticsctof(condition S dictate that activity X nested withinto S the will contained not be performed en true) will forward control activity as partactivity of the behavior of S, then theput status all outgoing X is setconto When A completes, it will theofcontrol back. links If thefrom associated negative.” (page 65, [5]) transition suggest that need tofalse) be taken anyway. the A similar tion evaluates to “false”, cf links (condition will forward control problem occursplace, on theindicating receiving side. thiswhile paper, we willhas abstract from these the completed that In this activity now completed. problems and assume that both the source and target of a link are traversed or both are skipped. This problem is not limited to switch activity but also applies
7
Pick Activities
A. When activity A completes, it will put the control back. If the associated condition evaluates to “false”, transition cf (condition false) will forward the control to the completed place, indicating that this while activity has now completed. 3.7
Pick Activities
CHAPTER 4. MODEL CHECKING BPEL SERVICES
event A
Activity A
event B
Activity B
started
Activity C
42
completed
Figure 4.6:8.Petri net representing a Pick [25]. Fig. Mapping for a pick activity.
A pick activity contains a (non-zero) number of onMessage elements and a (posActivity A sibly zero) number of onAlarm elements. Each onMessage element contains a reference to some event, a possible set of correlations, and an activity. As soon as Activity B aj as the event has occurred, the pick activity can start the corresponding activity. completed Each onAlarm started element contains either a absolute time or a relative time, and Activity C has been reached or the relative time an activity. As soon as the absolute time has been passed, the pick activity can start the corresponding activity. A pick activity starts only one activity. After it has started an activity, a pick activity Fig.has 9. for aAflow Figure 4.7:Mapping Petri net representing Flow [25]. completes as soon as its waits until that activity completed. pickaactivity. activity started activity completes. Figure 8 shows how we can map this onto a Petri net fragment.Pick parallel. However, due tocontains the link structure, activities might not be able to A pick construct a set of activities some each waiting for an event to start (Figure 4.6). The first activitycompletes that receivedas thesoon expected event execute. activities start immediately. A flow activity as all itswill contained 3.8 Flow Activities The pick activity9 completes whenwe the can started innerthe activity has completed. have completed. Figure shows how map hierarchical structure onto A flow contains a number of links a (non-zero) of activia Petri netactivity fragment, for the link structure weand refer to Figure 1number and Figure 3. Flow In the hierarchical structure, all contained activities are enabled In ties. Figure 9, transition as activity (AND-split) enables all activities, and transition aj in In a flow construct, all activities are executed concurrently, this is modeled by (AND-join) producing completes the flow activity. a token in the started place of each of the activities (Figure 4.7). 3.9
A
The Flow completes when all the concurrent sub-activities have completed. This is achieved by the ’aj’ transition that can fire only when all the subactivities have completed, placing a token in the corresponding place. Reduction
false targets
ef
sf skip
start st
false sources end
et
places “started” and “completed”. As a result, we will show places like “start” and “true sources” only if they are relevant for the activity at hand. 3.3
CHAPTER 4. MODEL CHECKING BPEL SERVICES
43
Basic Activities
Basic Activity
started start
true targets
completed false sources
c
b
a
end
4.8: Note Basic activity mapping [25]. Fig. 4. Mapping for a basic Figure activity. that standard connections shown in Figure 1 have been omitted. A Basic Activity (reply, receive, invoke. . . ) is modeled with the Petri net in Figure 4.8. The ’c’ transition denotes the normal execution of the activity, the ’a’ transition models its abortion and the ’b’ transition is for rolling back of the(like, activity.for example, invoke, receive, and reply) does activity
A basic not contain any other activity. A basic activity can be completed, aborted (by not catching a 4.1.2 Static Analysis of BPEL Processes thrown exception), or rolled back (using a compensation handler). Figure 4 shows [24] is a state-of-the-art Petri-net-based analysis tool for verifying the how we map Woflan this onto a Petri net fragment. Transition c models the completion correctness of a workflow process. Woflan was developed by Eric Verbeek and of the activity, abortion, andin transition b its rolling Wil transition van der Aalst a as aits tool to detect errors workflows formalized as WF- back. Note net.will Theyset extended this toolof in all a natural way to handle BPEL by Because the that a roll back the status its incoming links toprocesses positive. simply pluging-in an automatic translator of BPEL processes to PNML, the activity had been started, join condition must have been evaluated to “true”, Petri-net modeling its language. and we assume that a join condition will evaluate to “true” if all incoming links Reachability Analysis have a positive status. Therefore, it seems safe to roll back to a state where all Reachability all activities is desired for any BPEL process, i.e. the posincoming links have a of positive status. 3.4
sibility for any one of the activities that appear in the process definition to be executed. This won’t be the case if we have some dead transition in the corresponding Petri net. Sequence Activities The authors deployed, without receiving any warning from the BPEL container, the BPEL process described below. It is easy to see that the empty activity named ’nonEric’ can never execute. Indeed, for this activity to execute the link ’linkEric’ must be activated and thus the condition of the first ’case’ of the switch construct must be true. This is not possible since Activity Activity B we are already in Athe otherwise condition. The processActivity will C wait infinitely for the link to be activated. started
completed
Fig. 5. Mapping for a sequence activity.
A sequence activity contains ordered set of activities, and takes care of executing these contained activities in the given order. Figure 5 shows how this can be
CHAPTER 4. MODEL CHECKING BPEL SERVICES
44
< l i n k s>
Using WofBPEL the deadlock was reported. Moreover the tool accurately points the empty task in the otherwise construct to be the cause of the error. Competing Message-Consuming Activities In Section 3.2.4 we mention that “A business process MUST never have two receive activities for the same partnerLink, portType and operation active at the same time”. In short, a process cannot have two competing messageconsuming activities, competing being interpreted as above: same partner link, port type and operation. More generally, this constraint must hold for any consuming activity, which are not only the receive activities but also the pick activities and the event handlers.
In [20] the petri nets model permits detection of processes violating this constraint. In the example above, two sequences are run concurrently. If invoke ’A1’ and receive ’rcv2’ have completed, then ’rcv3’ and ’rcv1’ are competing for the message ’pl2/pt2/op2’. To discover this competing messageconsumption violation a full state space search was needed. Garbage Collection of Queued Messages Using the same model, it is possible to compute for each activity ’a’ of a process all the possible message types that could eventually be consumed by the process after the execution of ’a’. Computing this set for each activity enables the annotation of the BPEL process, by indicating for each activity the message types that are still relevant to the process. If the process, after execution of activity ’a’, receives a message that is not in the corresponding set of message types of ’a’, then this message can be discarded (garbage collected).
4.2
Guarded Automata Model
In the Loan Approval Service, we find 3 partners: the Loan Approval Service, the assessor and the customer. Each of these services could possibly be implemented as a BPEL process. They can be viewed as interacting distributed processes (Figure 4.9). In this paper [9], Xiang Fu et al. expose a method to transform interacting BPEL processes into Promela, the input language of the well-known SPIN model checker. This enables them to check the BPEL processes against LTL properties. Moreover, building on previous work [10], their translation allows for the handling of XPath expressions which are central to control the flow of the BPEL process. This constitutes an interesting enhancement over older approaches that were completely abstracting the data manipulation part of the process. This leads to a more fine grained verification.
andards for web services dation. Since communied on different locations tforms, agreeing on a set
Customer
RACTIONS
46
Assessor
risk assessment service. services. In particular, One can use pre- and post-conditions to associate behavmodel as an intermediate ioral descriptions for “atomic” web services that are speciervices results in a modfied in WSDL [17]. These pre- and post-conditions can be or our web service analused to reason about the composed behaviors of web services ecification languages can [13]. However, BPEL provides more expressive behavioral d various model checking descriptions. BPEL not only allows manipulation of XML ty analysis introduced in data structures using XPath expressions [26], but also proback-end. CHAPTER 4. programming MODEL CHECKING vides constructs BPEL such asSERVICES sequence, conditional as follows. Section 2 disand case statements, parallelism, and loops. ces and interaction modr the technical problems efines a formal model for n 4 presents two translaLoanProcess rded automata, and from pectively. Section 5 imction 4 by proposing the ives sufficient conditions on 6 concludes the paper.
Figure 3: Interacting BPEL Web Services
Figure 4.9: Loan Approval Service Interactions [9]. 622 Finally they exhibit the synchronizability concept as a way to handle infinite queues. This important result permits the complete verification of properties of a large class of Web services with unbounded input queues.
4.2.1
Guarded Automata Peers Model
As intermediate representation between BPEL and Promela the authors use a model based on guarded automata communicating through message queues. The model consists of three elements (Figure 4.10). Firstly a conversation schema declares the communicating peers, i.e. the BPEL processes involved, and all the possible type of messages that they can exchange. In the example below there are three peers (A, B and C) with msg1 the only message type that A can send to B, msg2 and msg6 the possible types of message peer B can send to A, and so on. Secondly, there are the guarded automata peers that represent the BPEL processes them self. A message queue that store the incoming messages sent by the other peers is attached to each automata. Finally a virtual watcher records all the messages by all peers in the order that they are produced. It actually records the whole conversation. A guarded automata, here, is a tuple (Miin , Miout , Li , si , Fi , ∆i ). Miin is the set of incoming message types, Miout is the set of outgoing message types, Li are the local variables, and Ti , si , Fi are the states, the initial state and the set of final states. All the messages, in and out, as well as all the values of the local variables are all XML documents. ∆i is the transition relation. A transition t ∈ ∆i is in one of the following three forms: (q1 , g, q2 ), called a local transition, (q1 , ?a, q2 ), a receive transition and (q1 , (b!, g), q2 ), called a
CHAPTER 4. MODEL CHECKING BPEL SERVICES
Conversation Schema
msg1
Peer A
Peer A
msg2, msg6
msg4
Peer B
Input Queue
In our model, messages are XML d messages correspond to XML Sche type c ∈ M , let dom(c) denote all th are of type c. Given a set of mess the message alphabet as Σ = c∈M element m ∈ Σ is called a messag denote the type of message m. We s of type(m).
Peer C
Peer C
Peer B !msg1
msg3, msg5
?msg1 !msg3
?msg3 !msg2
?msg2 ?msg5
!msg5 ?msg6
!msg6
... Virtual Watcher
!msg4
?msg4
?
47
G(msg1 ⇒F(msg3 ! msg5)) LTL property
Figure 4: A Simple Example Demonstrating Our Model
Figure 4.10: Guarded Automata model [10].
3.1 Guarded Automata Pee
For each peer pi , its implementat tomaton (Miin , Miout , Li , Ti , si , Fi , ∆ are incoming (outgoing) message ty of local variables for pi , and Ti , si , the initial state, and the set of final s messages, we assume that local vari uments. For each local variable l ∈ denote all the XML documents that laration of l. Similar to message t variables also correspond to XML S
Figure 3 shows a part of the composite loan processing
Each transition τ ∈ ∆i of the gua send transition. ofthat these transitions change the state the peer from q1 webEach service includes LoanProcess, Assessor, andof Cuspeer pi has a source state q1 ∈ Ti tomer. individualcondition services mayand be specified BPEL or, to q2 . The guard g isThe a boolean a set ofinassignments. Send q2 ∈ Tand i and is in one of the followin in simple cases, WSDL. The directed edges represent the local transition are executed only if the guard condition evaluates to true. communication links among the individual services. Note τ = (q1 , g, q2 ) The receive transition executes when the corresponding message is 1.atlocal-transition, the that Assessor may contact Customer directly. As a result, tion guard. The transition c front of the message queue theservice peer. that Thecan assignments of the send transitions there is no singleofweb keep track of automaton from q1 to q2 and “global” state of the service execution (i.e., there is no meables represent the content of the message being sent. The assignment of local based on the guard g. diator process as described in [13]). Clearly, analyzing intertransitions update local The guard actions the of such webvariables. services presents a great conditions challenge dueand the2.guard receive-transition, τ = (q1 , ?a assignments are XPath expressions, to their distributed behaviorjust [13].as in the BPEL process. The transition changes the s goalproperties in this paper to analyze and verifyi.e. properfrom In order to Our verify onis the conversation, the sequence of q1 to q2 and removes th ties of composite web services consisting of multiple BPEL type a) from the input queue messages exchanged, allcommunicating the messagesasynchronously sent between peers web services such as theare one recorded in a virtual watcher, concept introduced in [11]. Every message being added to a shown in Figure 3. 3. send-transition, τ = (q1 , (!b, g and g is the transition guard. peer’s message queue is also added to the virtual watcher in the order they the state of the automaton fro are produced.3. A FORMAL MODEL FOR the sent message (of type b) to receiving peer. INTERACTING WEB SERVICES
give a formal model for composite Note that, sent messages are not re web services which consists of multiple peers communicating chronously, rather, they are instan with asynchronous messaging. 4 gives informal il-on the converThe authors used LTL formulas [17] to Figure express the an properties the appropriate input queue. A m lustration of our conversation based model. A composite after it moves sations. The web LTLservice formulas areofbased on twoschema type of atomic propositions, a to the head of the inp consists a conversation that specifies A guard consists of a guard con peers and the transmitted peers, message type the m set or of a predicate onmessages the message typeamong m.pred. signments. A send- or local-transit and a set of guarded automata specifying the behavior of guard condition evaluates to true, each individual peer. As communication among web serhave no guards because they simp Example vices is asynchronous, each peer is equipped with a FIFO from the head of the input queue queue to store incoming messages. We assume that there send-transition, then the assignmen • G($register -> watcher F($accept v $reject)) is a virtual which records the sequence of messages the contents of the message that is b as they are sent by the peers. The sequence of messages tion is a local-transition, then the a recorded by the watcher is-> called a conversation. (Note that • G($register//stockID==a F($request//stockID==a)) update the values of the local varia the virtual watcher is a construct we use to reason about Given a send-transition τ = (s, (! the interactions among different peers and it is not implethe sender for the message type b, g mented.) A conversation can be regarded as a linearization the following form: g(m, m " × "l ), w of the message events, similar to the approach used in definbeing sent, the vector m " contains t ing the semantics of Message Sequence Charts [16] in [1]. message type that is received or sen Formally, a composite web service is a tuple S = !(P, M ), Miout ) and "l represents the values A1 , . . . , An ", where (P, M ) is a conversation schema, n = Li . |P | and each Ai is an implementation for peer pi ∈ P . A Given a local-transition τ = (s, g conversation schema is a pair (P, M ) where P is a finite set is a predicate of the following form of peers and M is a finite set of message types. Each message type c ∈ M is transmitted between only one pair of peers. and "l are as described above, and
4.2.2
this section, we LTLInProperties
CHAPTER 4. MODEL CHECKING BPEL SERVICES
48
The first proposition (which has nothing to do with the previous example), based on message types as atomic propositions, states that each message ’register’ will be eventually followed by an ’accept’ or a ’reject’ message. The second, an example of formula with predicates on message content, states that every stockID that appears in a register will finally appear in a request message. In order to verify that a BPEL process satisfies a property, the author developed a translation tool from BPEL to the guarded automata peers model and from this model to Promela, the input language of the SPIN modelchecker which verifies LTL properties. However even in a simple case verifying properties is not decidable [9]: “Given a composite web service S with finite content and an LTL property φ, checking that S satisfies φ is undecidable”. A web service composition is said to be with finite content when the set of all possible messages (not just the message types) in the system is finite. Since this result is due to the presence of unbounded message queues, putting a bound on these queues enables verification and the use of the SPIN model checker.
4.2.3
From BPEL to Guarded Automata to Promela
BPEL to Automata Model Translating the BPEL definition to the guarded automata can be done in two steps. First, the conversation schema must be derived. Then each guarded automaton is produced from the BPEL document. The conversation schema consists of, firstly, the declaration of the peers, one per BPEL input document. Secondly the message types, as well as their senders and receivers, are easily deduced from the BPEL and WSDL documents of the partners in all interactions. These message types of the conversation schema must be unique for a sender, a receiver and an operation. The translation of BPEL documents into extended guarded automata is similar to its translation into Petri nets as in the previous section. The table below exemplifies the translation of the assign, receive, invoke, sequence and flow constructs. The XPath expressions are directly translated into guard conditions and assignment expressions. The flow construct is translated through a Cartesian product of all subactivies (interleaving).This may lead to a great number of states in the resulting automaton and has a scaling problem as a consequence.
CHAPTER 4. MODEL CHECKING BPEL SERVICES
BPEL
Sample Code
assign
receive
invoke
49
Translation
[ aprvInfo / accept := ‘yes’ ]
[request := approve_In] ? approve_In
[approve_In := request] ! approve_In loanfault ? loanfault
!
? approve_Out
handler1 [aprvInfo := approve_Out]
!
fault1 act1
fault2 !
act1 [b_link1 := cond1 ]
act2
[b_link1] product
act2
Figure 5: From BPEL to Guarded Automata
Figure 4.11: Translation to Guarded Automata Model [10]. We first construct the conversation schema, and then translate the control flow of each BPEL process. As BPEL process specifications are fed as input, the peer list P of the schema tuple (P, M ) is already known. Message types M are extracted from WSDL files. For each input/output/fault parameter of an operation in each port and each service link of each BPEL process, a message type is declared. For example if a BPEL process loanProcess has an operation approve declared in a port aprvPT, and its input parameter is of WSDL message format creditInfo , a message type loanProcess aprvPT approve In will be declared in the com-
tion expresses the ass different approaches f word part used in the We translate all of th and these XPath exp guards of the generate is translated into a two transition receives the signs the input variab invoke statement is tr first transition sends that is being invoked, ceive the response and there are no exception during invoke, and w tions to handle them which leads to an “ex about the fault is asso a fault handler is wrap translator connects th exception exit. BPEL control flow and while are used t cussed above. In Fig sequence. We connect local transitions, and except the last one. T are recollected and pr constructs can be han trol flow to the transit for flow construct (w its branches), we simp all its branches. The among the activities each link into a boole reflected in the guard activity. Translation of the c chines or petri-nets h ference in our work is nipulation using guar as XPath expressions about XML data ma done using approache stract away the data c
4.2 Translation
CHAPTER 4. MODEL CHECKING BPEL SERVICES
50
Automata to Promela Translating a model composed of a conversation schema and the corresponding guarded automata into Promela is not an easy task. The main difficulties reside in the translation of the types and of the XPath expressions. This translation can be presented in 4 steps: types, processes, channels and XPath. Types The types of the variables in a Promela specification are essential to the success of the verification. Indeed, the state space explosion problem is directly linked to the size of the domain of the system variables, i.e. their types. Each type of the specification is mapped to a typedef in Promela. Strings are used only as constants, they are mapped to the enumerated type of Promela, mtype. Boolean and numeric types are mapped to the corresponding Promela types. Processes Each automaton is translated into a Promela process, proctype. Inside each proctype, corresponding to an automaton, i.e. corresponding to a BPEL document, we find the declaration of the local variables, corresponding to each variable of the BPEL document. Moreover an additional variable is declared to record the current state of the automaton. The process itself is composed of a single loop. This loop contains one big switch/case statement. Each branch, or case, of this statement corresponds to a transition of the automata. The condition for the branch to be taken is, firstly that the current state of the automaton is the source state of that transition and secondly that the corresponding guard condition evaluates to true. The guard condition is an XPath expression that must be translated as explained below. Furthermore, for receive transitions, the corresponding message is also required, i.e. a message of that type must be in the process channel. A send transition is translated in a similar way. Finally a final transition will be translated into a jump out of the loop. Channels The queue of the automaton is associated with a Promela communication channel. The Promela channels have a finite fixed length, this corresponds to bounded queues. While this is a serious restriction on the model, the author exhibited a property ’synchronizability’ that permits the full model checking of a large class of BPEL processes with unbounded queues.
CHAPTER 4. MODEL CHECKING BPEL SERVICES
51
XPath XPath translation is hard. In [10], the author proposes a method for translating bounded XML data and XPath expressions into Promela. Since SPIN is a finite state system verification tool, the model variables must all be bounded. Thus the XML data in this case are supposed to be bounded, i.e. there should only be a finite number of XML documents as possible value of a variable. While we will not introduce the method here, we give an example of the translation that speaks for itself on the complexity of the task. We observe that this simple XPath leads to a complex Promela translation containing 5 integer and 4 boolean variables. This could leads to into scalability issues due to the state explosion problem. $ r e q u e s t // s t o c k I D / i n t ()= $ r e g i s t e r // s t o c k I D [ i n t ( ) > 5 ] [ p o s i t i o n ()= l a s t ( ) ] / i n t ( )
translates into: /∗ r e s u l t o f t h e XPath e x p r e s s i o n ∗/ bool bResult = f a l s e ; /∗ r e s u l t s o f t h e p r e d i c a t e s 1 , 2 , and 1 r e s p . ∗/ b o o l bRes1 , bRes2 , bRes3 ; /∗ index , p o s i t i o n ( ) , l a s t ( ) , index , p o s i t i o n ( ) ∗/ i n t i1 , i2 , i3 , i4 , i 5 ; i 2 =1; /∗ pre−c a l c u l a t e t h e v a l u e o f l a s t ( ) , s t o r e i n i 3 ∗/ i 4 =0; i 5 =1; i 3 =0; do : : i4 < v r e g i s t e r . requestList . stockID occ −> /∗ compute f i r s t p r e d i c a t e ∗/ bRes3 = f a l s e ; if : : v r e g i s t e r . r e q u e s t L i s t . s t o c k I D [ i 4 ] . i n t v a l u e >5 −> bRes3 = t r u e : : e l s e −> s k i p fi ; if : : bRes3 −> i 5 ++; i 3 ++; : : e l s e −> s k i p fi ; i 4 ++; : : e l s e −> break ; od ; /∗ t r a n s l a t i o n o f t h e whole e x p r e s s i o n ∗/ i 1 =0;
CHAPTER 4. MODEL CHECKING BPEL SERVICES
52
do : : i1 < v r e g i s t e r . requestList . stockID occ −> /∗ f i r s t p r e d i c a t e ∗/ bRes1 = f a l s e ; if : : v r e g i s t e r . r e q u e s t L i s t . s t o c k I D [ i 1 ] . i n t v a l u e >5 −> bRes1 = t r u e : : e l s e −> s k i p fi ; if : : bRes1 −> /∗ s e c on d p r e d i c a t e ∗/ bRes2 = f a l s e ; if : : ( i 2 == i 3 ) −> bRes2 = t r u e ; : : e l s e −> s k i p fi ; if : : bRes2 −> /∗ t r a n s l a t i o n o f e x p r e s s i o n ∗/ if : : ( v r e q u e s t . s t o c k I D . i n t v a l u e == v r e g i s t e r . r e q u e s t L i s t . stockID [ i 1 ] . i n t v a l u e ) −> b R e s u l t = t r u e ; : : e l s e −> s k i p fi : : e l s e −> s k i p fi ; /∗ update p o s i t i o n ( ) ∗/ i 2 ++; : : e l s e −> s k i p fi ; i 1 ++; : : e l s e −> break ; od ;
The full translation is shown in [9]. More important are the concrete results of the application of this technique and their scalability problems. This is presented in the next section.
4.2.4
Results
In contrast to previous work, Bultan et al. present an approach that does not abstract the data manipulation part of the BPEL process. Their tool, WSAT [22], permits the verification of LTL properties of interacting BPEL processes with bounded queues. WSAT also checks if the process verifies the
CHAPTER 4. MODEL CHECKING BPEL SERVICES
53
synchronizability property and if it is, proceed to the appropriate modification of the model that permits the verification of the LTL properties, the results are then still valid for unbounded queues. While a class of processes can be verified with unbounded queues, the processes that are synchronizable, there are still lots of processes that do not verify that property and thus the verification of LTL property are limited to finite queues for these processes. Moreover, the method does not scale well. In their conclusion, the authors report on their experiments on a model containing 3 peers: “When integer domain is set to [0,1], the verification time is 3 seconds and memory consumption is around 50MB. When the domain is increased to [0,3], the memory consumption grows to over 600MB. However, our experience shows that SPIN is still useful in identifying errors in protocols by restricting the data domains”.
4.3
Conclusions
Verification of BPEL processes has been investigated for some times now. Two approaches have been subject to research. The first approach makes abstraction of XPath expressions, the data manipulation part of a BPEL process, it concentrates fully on the control flow level. This first approach is quite successful and several automated tools have been developed enabling verification of soundness and LTL properties. The second tries to include XPath expressions in the model. While some results are obtained, the method does not scale well, verification is limited to very simple processes.
Chapter 5 Testing BPEL Web Services Contents
5.1
5.1
Test Suites . . . . . . . . . . . . . . . . . . . . . .
54
5.2
Generating Test Cases using SPIN for BPEL Services . . . . . . . . . . . . . . . . . . . . . . . .
55
5.2.1
BPEL to Promela . . . . . . . . . . . . . . . . . . 56
5.2.2
SPIN to Test Cases
5.2.3
Results . . . . . . . . . . . . . . . . . . . . . . . . 58
. . . . . . . . . . . . . . . . . 58
Test Suites
The use of model checking and formal methods helps reducing the number of errors in the early stages of software development. In the later stages, testing is a popular method for verifying the correctness of the implementation against its expected behavior. Testers usually write a lot of test cases. A test case or unit test is the description of an input on which the software is to be executed. A test case can also contains the expected result or response from the program. The program passes the test if the actual response is the response that was expected. A set of test cases is called test set or test suite. Judging the quality of a test suite is the subject of a lot of researches [32]. Coverage analysis is a popular way of assessing the quality of a test set. However there are several different coverage criteria that have been proposed and argued. Statement coverage checks that every statement is executed. 54
CHAPTER 5. TESTING BPEL WEB SERVICES
55
Branch coverage checks that every branch is actually taken. Path coverage check that every path is taken. Mutation coverage checks that the tests discriminate against every small change in the code, i.e. mutation of the code. Let consider the following code: if(t==0) { a = 1; } if(s==0} { b = 1; } To have 100 percent statement coverage it is sufficient to have t==0 and s==0, so a single test is required. To have full branch coverage the true and false branch of each test must be covered. It is sufficient to have two tests, one with t==0 and s==0 and another where t!=0 and s!=0. Finally to have complete path coverage at least four tests are required, one for each combination of possible values of t==0 and s==0. The mutation coverage is not illustrated here, it strongly depends on the mutation operator (e.g. syntactic mutation of the code). To achieve full coverage the results of the tests must detect all non-equivalent mutants. Getting a test set that is of good quality with regards to one of the criteria above can be tedious. Automatically generating these test cases alleviates that task.
5.2
Generating Test Cases using SPIN for BPEL Services
Model checking can be used to help generate test cases [14, 2]. Indeed, model checkers like SPIN or SMV check if a property, specified as an LTL formula, holds for a given model. If it does not hold, then the model checker extracts the trace of an execution on the model that violates the property, i.e. a counterexample. In order to get a test case for a property C, it suffices to run the model checker on the model with the property ’C never holds’. The model checker will, thus, exhibit a counterexample that describes an execution where the C property holds. This counter example, if it exists, can be the source of a test case.
CHAPTER 5. TESTING BPEL WEB SERVICES
56
In [12], the authors used SPIN to generate test cases for BPEL processes. Firstly, they transform the BPEL process into Promela. Next, they identify all the transitions, from one activity to another, of the BPEL process. Finally the generation proceeds as follows. To each transition, X, is associated the LTL property: ’Transition X is never executed’. The SPIN model checker is run with the Promela model and each of the above LTL properties. The counterexample is an execution that triggers the transition X. A test case can be produced accordingly. The overall process is illustrated in the Figure 5.1. This method will generate a test suite that covers all transitions of the BPEL process, provided that a counterexample can be found for each transition. Other coverage criteria can be used, so long as one can express it as an LTL formula.
5.2.1
BPEL to Promela
The translation into Promela is quite similar to the one presented in Section 4.2.3. However, instead of going through an intermediate representation, i.e. the guarded automata model, the authors present a direct transformation. While this Promela translation has a lot in common with the previous one, there are also important differences. The BPEL process is translated into a Promela process construct, as are all the partner processes. However, unlike in the former translation, the partner processes are deduced from the BPEL document, i.e. no need here to provide (simple) BPEL documents for each partner. These partners are deduced from the partner definition in the BPEL document, via the associated WSDL definition. Additionally, the behavior of the partner, the messages it sends, is deduced by analysis of how the process actually uses the information. For example, in the Loan Approval Service, the process receives a riskAssessment.risk from the assessor. The value of the risk variable is tested against the constant ’low’. Therefore the corresponding Promela process will send ’low’ or ’other’ as risk response in order to cover all branches of the test. The behavior of the deduced Promela process follows 3 rules: 1. If the BPEL document has no reference to the data, then its unique possible value is undefined 2. If the BPEL document compares it to a numerical constant: the possible value are the constant as well as a lower and an higher value
CHAPTER 5. TESTING BPEL WEB SERVICES
Garcia-Fanjul, Tuya, de la Riva
Fig. 3. An overview of the proposed method
Figure 5.1: Generation of test cases with SPIN [12].
consisting of three attributes of type byte. Each portType will have two channels: one for input messages and another for output. Message types are declared as typedefs in PROMELA (a construct similar to “record” in the C programming language). BPEL data types are discretized from the original ones: every simple data type becomes byte except for boolean, which stays the same. Each activity must be appropriately modelled to represent the behaviour of the business process. For example, invoke and receive activities use the ! and ? 88
57
CHAPTER 5. TESTING BPEL WEB SERVICES
58
3. If the value is discrete in the BPEL document: the possible values are all the discrete values as well as other. Afterwards, the partner processes and the process in itself are mapped into the Promela specification. The processes port types are transformed into Promela channels, the message types into Promela typedefs and each data type is discretized from the BPEL type into boolean for all data, except for boolean that are mapped to Promela boolean. The invoke and receive activities are modeled through the ! and ? channel operators. The flow controls, i.e. sequence, while, link, flow constructs. . . , are then mapped (manually?) into the Promela specification.
5.2.2
SPIN to Test Cases
To fulfill the transition coverage criteria, LTL formulae are used to produce counterexamples triggering the targeted transitions. In their implementation the authors use a boolean variable for each transition, e.g. for transition X the variable is transX. This variable will be set to true in the Promela model when the transition is executed. The corresponding LTL formula will thus be : ’[] !transX’ (i.e. always not transX). To deduce the actual test case from a counterexample, one must simply use the sequence of exchanged messages. Indeed, they give a complete description of the interaction between the partners leading to the execution of the targeted transaction. To produce the complete transition coverage, one has to run the model checker with the LTL formula of not yet executed transitions as long as such transition exists. In some cases some transitions are just unreachable, however the authors do not explicitly treat this case.
5.2.3
Results
The authors applied their technique to the Loan Approval Services. In less than three runs they obtained a test suite covering all transitions. The performance on this simple example was really good. The paper is only preliminary results and it is the first and only one investigating the application of model for test suite generation for BPEL processes. The translation process is not automated. Moreover, the example investigated is very basic, it has only trivial XPath expressions. The application to BPEL process with more complex XPath must be studied. Even more, as we saw in Section 4.2.3, a generic translation of BPEL to Promela, including XPath expression, has a scalability problem. The scalability of the
CHAPTER 5. TESTING BPEL WEB SERVICES
59
present technique, i.e. with more complex, real life BPEL processes, must be looked into.
Chapter 6 Conclusions and Future Works BPEL is a fully fledged, high level programming language for business processes based on Web Services. As with any other software system, the need to verify and validate BPEL processes is clear. Commonly two methods are used for verifying and validating softwares: model checking and testing. Model checking of BPEL processes has been closely investigated. These researches about it split into two approaches. The first approach makes abstraction of the XPath expressions, the data manipulation part of a BPEL process, it concentrates fully on the control flow level. This first approach is quite successful and several automated tools have been developed enabling verification of soundness and LTL properties. The second approach tries to include the XPath expressions in its model. While some results are obtained, the method does not scale well, verification is limited to very simple processes. On the testing side of the validation, very few works explicitly tackle the generation of test suites based on model checking techniques. The one we presented in Chapter 5 is a proof of concept. More investigations are needed to assess the scalability of the technique. Abstract interpretation techniques like the one used in the Blast model checker [1] is an alternative model checking technique. Its application to BPEL processes and especially to XPath expressions could yield interesting results and should be explored. Moreover Blast was extended to automatically generate test suites from counterexamples [4]. However, more research is needed to handle with Blast the concurrency capability built into BPEL.
60
List of Figures 1.1 Web Services Architecture Stack [13]. . . . . . . . . . . . . . . 1.2 The Loan Approval Service. . . . . . . . . . . . . . . . . . . .
5 8
2.1
XML Schema data types [30]. . . . . . . . . . . . . . . . . . . 13
3.1
Flow diagram of the Loan Approval Service.. . . . . . . . . . . 26
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11
Petri net representing an activity. . . . . Petri net representing a Link [25]. . . . . Petri net representing a Sequence [25]. . Petri net representing a Switch [25]. . . . Petri net representing a While [25]. . . . Petri net representing a Pick [25]. . . . . Petri net representing a Flow [25]. . . . . Basic activity mapping [25]. . . . . . . . Loan Approval Service Interactions [9]. . Guarded Automata model [10]. . . . . . Translation to Guarded Automata Model
5.1
Generation of test cases with SPIN [12]. . . . . . . . . . . . . 57
61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [10].
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
39 39 40 41 41 42 42 43 46 47 49
Bibliography [1] The blast model checker. http://embedded.eecs.berkeley.edu/blast/. [2] Paul Ammann, Paul E. Black, and William Majurski. Using model checking to generate tests from specifications. In ICFEM, page 46, 1998. [3] Jes´ us Arias-Fisteus, Luis S´anchez Fern´andez, and Carlos Delgado Kloos. Formal verification of bpel4ws business collaborations. In EC-Web, pages 76–85, 2004. [4] Dirk Beyer, Adam J. Chlipala, and Rupak Majumdar. Generating tests from counterexamples. In ICSE ’04: Proceedings of the 26th International Conference on Software Engineering, pages 326–335, Washington, DC, USA, 2004. IEEE Computer Society. [5] Dirk Fahland. Complete abstract operational semantics for the web service business process execution language. Technical report, HumboldtUniversit at zu Berlin, 2005. [6] Roozbeh Farahbod, Uwe Gl¨asser, and Mona Vajihollahi. Specification and validation of the business process execution language for web services. In Abstract State Machines, pages 78–94, 2004. [7] Andrea Ferrara. Web services: a process algebra approach. In ICSOC ’04: Proceedings of the 2nd international conference on Service oriented computing, pages 242–251, New York, NY, USA, 2004. ACM Press. [8] H. Foster, S. Uchitel, J. Magee, and J. Kramer. Model-based verification of web service compositions. Eighteenth IEEE International Conference on Automated Software Engineering (ASE), Montreal, Canada, 2003., 2003. [9] X. Fu, T. Bultan, and J. Su. Analysis of interacting bpel web services. In ACM Press, editor, the 13th International World Wide Web Conference (WWW’04), USA, 2004., 2004. 62
BIBLIOGRAPHY
63
[10] X. Fu, T. Bultan, and J. Su. Model checking xml manipulating software, 2004. [11] Xiang Fu, Tevfik Bultan, and Jianwen Su. Conversation protocols: a formalism for specification and verification of reactive electronic services. Theor. Comput. Sci., 328(1-2):19–37, 2004. [12] Jos´e Garc´ıa-Fanjul, Javier Tuya, and Claudio de la Riva. Generating test cases specifications for bpel compositions of web services using spin. In International Workshop on Web Services Modeling and Testing (WSMaTe), 2006. [13] Web Services Architecture Group. Web services architecture. http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. [14] Elsa Gunter and Doron Peled. Model checking, testing and verification working together. Form. Asp. Comput., 17(2):201–221, 2005. [15] Sebastian Hinz, Karsten Schmidt, and Christian Stahl. Transforming bpel to petri nets. In W.M.P. van der Aalst, B. Benatallah, F. Casati, and F. Curbera, editors, Proceedings of the Third International Conference on Business Process Management (BPM 2005), volume 3649 of Lecture Notes in Computer Science, pages 220–235, Nancy, France, September 2005. Springer-Verlag. [16] Mariya Koshkina and Franck van Breugel. Modelling and verifying web service orchestration by means of the concurrency workbench. SIGSOFT Softw. Eng. Notes, 29(5):1–10, 2004. [17] Shin NAKAJIMA. Model-checking verification for reliable web service. In OOPSLA 2002 Workshop on Object-Oriented Web Services., 2002. [18] C. Ouyang, W.M.P. van der Aalst, S. Breutel, M. Dumas, A.H.M. ter Hofstede, and H.M.W. Verbeek. Formal semantics and analysis of control flow in ws-bpel. Technical report, BPM-05-13, BPMcenter.org, 2005. [19] Chun Ouyang, Eric Verbeek, Wil M. P. van der Aalst, Stephan Breutel, Marlon Dumas, and Arthur H. M. ter Hofstede. Wofbpel: A tool for automated analysis of bpel processes. In ICSOC, pages 484–489, 2005. [20] Chun Ouyang, Eric Verbeek, Wil M. P. van der Aalst, Stephan Breutel, Marlon Dumas, and Arthur H. M. ter Hofstede. Wofbpel: A tool for automated analysis of bpel processes. In ICSOC, pages 484–489, 2005.
BIBLIOGRAPHY
64
[21] Karsten Schmidt and Christian Stahl. A petri net semantic for bpel4ws - validation and application. In Ekkart Kindler, editor, Proceedings of the 11th Workshop on Algorithms and Tools for Petri Nets (AWPN’04), pages 1–6. Universit¨at Paderborn, October 2004. [22] Jianwen Su, Tevfik Bultan, and Xiang Fu. The wsat analysis tool. http://www.cs.ucsb.edu/ su/WSAT/. [23] Wil v. d. van der Aalst and Kees v. van Hee. Workflow Management: Models, Methods, and Systems (Cooperative Information Systems). The MIT Press, January 2002. [24] Eric Verbeek and Wil van der Aalst. http://is.tm.tue.nl/research/woflan/.
The woflan model checker.
[25] H.M.W. Verbeek and W.M.P. van der Aalst. Analyzing bpel processes using petri nets. In of the Second International Workshop on Applications of Petri Nets to Coordination, Workflow and Business Process Management, pages pages 59–78. Florida International University Miami, Florida, USA, 2005. [26] W3C. Extensible markup language (xml). http://www.w3c.org/XML. [27] W3C. Simple object http://www.w3.org/TR/SOAP/. [28] W3C. Web services http://www.w3.org/TR/wsdl/.
access description
protocol
(soap).
language
(wsdl).
[29] W3C. Xml path language (xpath). http://www.w3.org/TR/xpath/. [30] W3C. Xml schema. http://www.w3c.org/XML/Schema. [31] YanPing Yang, QingPing Tan, and Yong Xiao. Verifying web services composition based on hierarchical colored petri nets. In IHIS ’05: Proceedings of the first international workshop on Interoperability of heterogeneous information systems, pages 47–54, New York, NY, USA, 2005. ACM Press. [32] Hong Zhu, Patrick A. V. Hall, and John H. R. May. Software unit test coverage and adequacy. ACM Comput. Surv., 29(4):366–427, 1997.
