Formalizing exception handling in WS-CDL and WS-BPEL for conformance verification

Transcription

1 Lingnan University From the SelectedWorks of Prof. YEUNG Wing-lok December, 2009 Formalizing exception handling in WS-CDL and WS-BPEL for conformance verification Wing Lok YEUNG, Lingnan University, Hong Kong Available at:

2 Formalizing Exception Handling in WS-CDL and WS-BPEL for Conformance Verification W. L. Yeung Department of Computing and Decision Sciences Lingnan University Hong Kong Abstract We have previously developed a formal approach to verifying conformance for web services choreography based on the formalism of Communicating Sequential Processes (CSP). In this paper, we extend the approach to cover exception handling, which is commonly used in specifying the choreography as well as orchestration of web services. In particular, we show how timeout exceptions and message events are handled in the formal approach and illustrate it using a document ordering and delivery process as an example. Keywords-WS-CDL; WS-BPEL; exception handling; conformance Choreographic description (WS CDL) WS CDL to CSP translation Choreographic process (CSP) Abstract process descriptions (BPEL) BPEL to CSP translation Abstract processes (CSP) I. INTRODUCTION Web services have emerged as the building blocks of a service-oriented architecture that promises a high level of interoperability for information systems applications. Web services orchestration and choreography are both concerned with the composition of web services in supporting business processes. The Web Service Business Process Execution Language (BPEL) [1], also known previously as BPEL4WS, supports the orchestration of web services. While orchestration always represents control from one party s perspective, choreography tracks message sequences among multiple parties from a global point of view [2]. The W3C has proposed the Web Services Choreography Description Language (WS- CDL) [3] for specifying the order of interactions among Web services involved in a business process from a global point of view. WS-CDL is expected to be used in conjunction with WS-BPEL in modeling and implementing business processes. In [4], [5], [6], we developed an approach (see Figure 1) to verifying the conformance of WS-BPEL abstract processes with a WS-CDL specification based on Communicating Sequential Processes (CSP) [7], [8]. Following this approach, WS-CDL and WS-BPEL can both be mapped into CSP for conformance verification with the help of model checking. However, one important feature missing from the mappings is exception handling, which is supported in both WS-CDL and WS-BPEL. In this paper, we extend our approach to address exception handling. We illustrate the extended approach with a digital Derive data independent version FDR2 model checking tool Derive data independent version Figure 1. A formal approach to conformance verification for web services choreography library example. A summary of the CSP notations used in this paper is included in the Appendix. II. RELATED WORK Exception handling in web services choreography has so far received relatively little attention from researchers. Yang et al [9] explored the connection between choreography and orchestration regarding exception handling based on a choreography language with only a small set of essential features and a formal semantics. Li et al [10] also proposed a language for modeling exception handling and finalization of WS-CDL. The conformance between WS-CDL and WS-BPEL have been studied based on other formalisms including finite state automata [11], timed automata [12] and Petri nets [13]. A formal approach similar to the one reported in this paper uses the FSP algebra to formalize WS-BPEL and WS-CDL and check for conformance by model checking [14]. Model

3 checking was also applied to the verification of WS-BPEL executable processes against WS-BPEL abstract processes in [15], as well as the analysis of behavioral properties of composite web services [16], [17]. Lu et al [18] propose a different approach to checking the correctness of workflow models based on the Hoare-style pre- and post-conditions semantics of workflow constructs. They also describe algorithms for automatically checking the correctness of workflows and for automatic workflow generation. III. EXCEPTION HANDLING IN WS-CDL A WS-CDL document describes the message exchanges among the participating Web services in a business process. The behavioral aspect of the message exchanges is described in one or more choreographies (in the Choreography-Notation section) in terms of activities. There are three types of activities, namely controlflow activities, workunit activities, and basic activities. The control-flow and workunit activities are structuring constructs that include sequence, parallel, and choice which correspond the usual programming constructs; the workunit construct corresponds to Dijkstra s guarded command. There are four kinds of basic activities: An interaction activity describes an exchange of information between participants with a focus on the receiver of information. An interaction may specify either a request, a response, or a request-response type of information exchange. A perform activity calls a separately defined choreography. An assign activity assigns the value of one variable to another variable within a participant. A noaction activity does nothing. WS-CDL supports the handling of different types of exceptions including interaction failures, timeout errors, validation errors, etc [3]. One or more exception workunits may be defined within the exceptionblock of a choreography. The particular type of exceptions handled by an exception workunit is defined in the workunit s guard condition using the hasexceptionoccurred function; the absence of such a guard condition renders the exception workunit applicable to any type of exception. Figure 2 shows a UML activity diagram which models a choreography for an online document ordering and delivery process. The process involves three parties, the member, the online catalogue (OC), and the document repository (DR). Figures 3 and 4 show the relevant parts of a WS-CDL document for the process. Figure 3 shows the two WS-CDL interaction activities, namely Search and Check Document, which involve exceptions. In the Search interaction, a timeout exception is raised if the interaction cannot complete within a certain period of time. In the Check Document activity, an orderrejected Search Timeout [send search to Online Catalog; receive search results from Online Catalog] Member Online Catalog Document Repository Order Document [send document order to OC] Make Payment [send payment info to OC] Acknowlegde Delivery [send ack to OC] Figure 2. Check Document [send order details to DR; receive availability from DR] Confirm Order [send DO acceptance to member] Order Delivery [send document order to DR] Cancel Order [send DO rejection to member] A choreography example orderrejected Get Delivery Instructions [send request to member; receive details from member] exception is caused if the Repository responds to an order request with an orderrejectedtype message. Note that the choice between a orderrejected response and a receiveavailability response is implicit in the definition of the CheckDocument interaction. Upon the occurrence of an exception of either types, a corresponding exception handler as shown in Figure 4 will take over. The timeout exception handler simply stops any further interactions without any taking any actions. The orderrejected exception handler does prescribe the sending of a cancelation message from OC to the member. IV. EXCEPTIONAL HANDLING IN WS-BPEL A WS-BPEL process (abstract or executable) specifies the orchestration of web services in terms of activities which can be primitive or structured. Primitives activities include: invoke - calling a Web service s operation receive - waiting for a message reply - sending a message wait - pausing for a period of time assign - assigning value of one variable to another throw - initiating an exception terminate - terminating the service empty - doing nothing Structured activities are structuring constructs including sequence, switch, while, which correspond to the usual programming constructs, as well as pick (selection based on timing or incoming triggers), flow (parallel fork), scope (for exception handler), and links (parallel join).

4 <choreography name="documentordering" root="true> <sequence> <interaction name="search" channelvariable="searchchannel" operation="receivesearch"> <participate relationshiptype="membercatalogue" fromroletyperef="member" toroletyperef="catalogue"/> <exchange name="sendsearch" informationtype="searchterm" action="request"> <send variable="getvariable( st )"/> <receive variable="getvariable( st )"/> <exchange name="receiveresults" informationtype="resulttype" action="respond"> <send variable="getvariable( results )"/> <receive variable="getvariable( results )"/> <timeout time-to-complete=""> <interaction name="orderdocument" > <interaction name="checkdocument" channelvariable="checkchannel" operation="receiveorder"> <participate relationshiptype="cataloguerepository" fromroletyperef="catalogue" toroletyperef="repository"/> <exchange name="sendorder" informationtype="ordertype" action="request"> <send variable="getvariable( order )"/> <receive variable="getvariable( order )"/> <exchange name="receiveavailability" informationtype="availabilitytype" action="respond"> <send variable="getvariable( av )"/> <receive variable="getvariable( av )"/> <exchange name="orderrejected" informationtype="orderrejectedtype" action="respond"> <send variable="getvariable( orderrejected )" causeexception="orderrejected"/> <receive variable="getvariable( orderrejected )"/> causeexception="orderrejected"/> <interaction name="confirmorder" > <parallel> </parallel> <!-- exception handlers --> </choreography> Figure 3. WS-CDL choreography of the document ordering process <exceptionablock name="handletimeoutexception"> <workunit name="handletimeout" guard= "hasexceptionoccurred( TimeoutException )"> <noaction> </workunit> </exceptionblock> <exceptionablock name="handlerejectedorderexception"> <workunit name="handlerejectedorder" guard="hasexceptionoccurred( orderrejected )"> <interaction name="cancelorder" channelvariable="cancelchannel" operation="cancelorder"> <participate relationshiptype="membercatalogue" fromroletyperef="catalogue" toroletyperef="member"/> <exchange name="receivecancelation" informationtype="cancelationtype" action="request"> <send variable="getvariable( av )"/> <receive variable="getvariable( av )"/> </workunit> </exceptionblock> Figure 4. WS-CDL exception handlers of the document ordering process <process name="memberprocess" > <partnerlinks> </partnerlinks> <variables> </variables> <sequence> <invoke partnerlink="searching" operation="searchrequest" inputvariable="searchterm" outputvariable="results" </invoke> <eventhandlers> <onalarm> <for>$maxinteractionduration</for> <!-- Timeout handler --> <exit/> </onalarm> </eventhandlers> </scope> </process> Figure 5. process Handling of timeout in WS-BPEL for the document ordering WS-BPEL provides elaborate support for exception handling. Faults (exceptions) can be thrown to signal exceptional conditions that are handled (caught) by fault handlers as well as compensation handlers. Time-based exceptions (e.g. timeouts) are handled by event handlers. Figure 5 shows the relevant part of the WS-BPEL process for the handling of timeout for the role of the Member. The timeout exception is specified through an onalarm event handler which is associated with the web service invocation concerned. If an invocation cannot complete within the

5 <process name="catalogueprocess" > <partnerlinks> </partnerlinks> <variables> </variables> <sequence> <receive partnerlink="checking" operation="sendorder" messagetype="ordertype" variable="order"> </receive> <reply partnerlink="checking" operation="checkavailability" messagetype="availabilitytype" variable="av" </reply> <eventhandlers> <onevent partnerlink="checking" operation="checkavailability" messagetype="orderrejectedtype" variable="orderrejected"> <sequence> <reply partnerlink="ordering" operation="cancelorder" > </reply> <exit/> </scope> </onevent> </eventhandlers> </process> Figure 6. process Exception handling in WS-BPEL for the document ordering maximum duration allowed, the event handler will take over and in this case simply halts the process. Figure 6 shows the relevant part of the WS-BPEL process for the handling of a message event for the role of the Online Catalogue. The message event corresponds to a order rejected exception which occurs upon the receipt of a order rejected message. The handling of this exception involves sending an order cancelation message to the Member. V. MAPPING WS-CDL AND WS-BPEL INTO CSP Table I shows the mapping between a subset of WS-CDL and CSP. This mapping extends the previous one [5] with provision for exception handling features. Following WS-CDL s intention, interactions are biased towards the receiver: a request message exchange therefore corresponds to an input by the receiver process whereas a response message exchange corresponds to an output by the receiver process. Note that a response message could either be an expression or a nondeterministic value of the corresponding information type. The latter case applies when CHOREOGRAPHY ( = ) search?x : W y:r results!y SKIP STOP; order?z : R details?u : R avail?v : {Ok, No} if v = Ok then confirm!accept payment?w : C ack?r : {Ok, No} SKIP delivery?s : R request?t : R instruct?i : D SKIP else confirm!reject SKIP Figure 7. The choreography example expressed in CSP the actual computation of the value is an internal activity that is not revealed in the choreographic description. The timeout operator of CSP lends itself to the correspondence with WS-CDL s timeout construction. Figure 7 shows the WS-CDL choreography example mapped into CSP. Note that we have abbreviated the information types of search keywords, search results, payment details, and delivery details as W, R, C, D, respectively. Table II shows the correspondence between a subset of WS-BPEL activities and CSP. Note that a reply message could either be an expression or a nondeterministic value of the corresponding message type. The latter case applies when the actual computation of the value is an internal activity that is not revealed in the abstract process description. As an example, the abstract process for the search activity as shown in Figure 5 can be mapped into CSP as follows: ( SEARCH = search?x : W ) results!y SKIP Stop y R where W and R are the information types of search keywords and search results, respectively. VI. CONFORMANCE VERIFICATION In [5], we defined the notion of choreography conformance for a web services based business process in terms of the traces semantics of CSP: a set of WS-BPEL processes conforms to a WS-CDL choreography if and only if the latter is traces-refined by the former. Formally, CHOREOGRPAHY t PROCESS where CHOREOGRAPHY and PROCESS stand for the WS- CDL choreography and the combined behavior of the participating WS-BPEL processes expressed in CSP, respectively. An advantage of this notion of conformance is that it allows for premature termination of individual web services due to exceptions such as those discussed in the present paper.

6 WS-CDL interaction request interaction response Table I CORRESPONDENCE BETWEEN A SUBSET OF WS-CDL ACTIVITIES AND CSP interaction request-response interaction request-response noaction <sequence > P 1; ; P n <parallel > P 1 P n CSP channel?variable : informationtype SKIP x:informationtype channel!x SKIP or channel!expression SKIP channel?variable : informationtype x:informationtype channel!x SKIP or channel?variable : informationtype channel!expression SKIP SKIP </parallel> <choice > P 1 P n </choice> <workunit name="" guard="b" > activity P if b then P else STOP </workunit> <interaction name="p" > <timeout time-to-complete=""> <exceptionblock name="q"> P Q <workunit name="" guard="cdl:hasexceptionoccurred ( TimeoutException,)"> </workunit> </exceptionblock> Furthermore, the verification of conformance based on CSP is supported by the FDR model checking tool [19] as demonstrated in [5]. VII. CONCLUSION AND FURTHER WORK We have presented an extension of our previous work on mapping WS-CDL and WS-BPEL into CSP for conformance verification. The extension addresses exception handling in web services choreography and orchestration. In particular, the use of timeouts and message events is discussed and illustrated by an example in this paper. Further work includes the treatment of other advanced features such as compensation as well as interfaces with other WS-* standards such as WS-Security. ACKNOWLEDGMENT The authors would like to thank the anonymous referees for their helpful comments. This research is supported by the Lingnan University Conference Grant. REFERENCES [1] OASIS, Web Services Business Process Execution Language Version 2.0, April [Online]. Available: OS/wsbpel-v2.0- OS.html [2] C. Peltz, Web services orchestration and choreography, Computer, pp , October 2003.

7 Table II CORRESPONDENCE BETWEEN A SUBSET OF WS-BPEL ACTIVITIES AND CSP WS-BPEL receive message reply response empty terminate <sequence > P 1; ; P n <flow > P 1 P n CSP partnerlink?variable : messagetype SKIP x:messagetype partnerlink!x SKIP or partnerlink!expression SKIP SKIP STOP </flow> <switch > <case condition="b 1"> if b 1 then P 1 </case> else if b 2 then <case condition="b 2"> <otherwise> else P n </otherwise> </switch> <while condition="b" > activity P μ X if b then P; X else SKIP </while> activity P <eventhandlers> <for>duration</for> P Q activity Q </eventhandlers> </scope> P <eventhandlers> <onevent partnerlink="q" P (q?x : m Q) messagetype="m" variable="x" > Q </scope> </onevent> </eventhandlers> </scope> [3] N. Kavantzas et al., Web Services Choreography Description Language Version 1.0, 2005, 10/. [4] W. L. Yeung, Mapping WS-CDL and BPEL Into CSP for Behavioural Specification and Verification of Web Services, in Proc. Fourth European Conference on Web Services, [5], CSP-Based Verification for Web Service Orchestration and Choreography, Simulation, vol. 83, no. 1, pp , January [6], Formalizing State Alignment Interaction in Web Service Choreography, 2007, submitted to International Conference on Enterprise Systems and Applications (ICESA 2007). [7] C. A. R. Hoare, Communicating Sequential Processes. Prentice Hall, [8] A. W. Roscoe, The Theory and Practice of Concurrency. Prentice Hall, [9] Y. Hongli, Z. Xiangpeng, C. Chao, and Q. Zongyan, Exploring the connection of choreography and orchestration with

8 exception handling and finalization/compensation, in FORTE 07: Proceedings of the 27th IFIP WG 6.1 international conference on Formal Techniques for Networked and Distributed Systems. Berlin, Heidelberg: Springer-Verlag, 2007, pp [10] J. LI, J. He, G. Pu, and H. Zhu, Towards the Semantics for Web Service Choreography Description Language, in Proc. ICFEM 06. Springer, [11] M. Baldoni et al., A Priori Conformance Verification for Guaranteeing Interoperability in Open Environments, in Proc. International Conference on Service-Oriented Computing, Chicago, IL, USA, December 2006, A. Dan and W. Lamersdorf, Eds. Springer, 2006, pp [12] M. E. Cambronero, G. Díaz, V. Valero, and E. Martínez, A tool for the design and verification of composite web services, in Proc. Second Workshop on Formal Languages and Analysis of Contract-Oriented Software, November 2008, Malta, G. J. Pace and G. Schneider, Eds., 2008, pp [13] V. Valero, M. E. Cambronero, G. Díaz, and H. Macia, A Petri net approach for the design and analysis of Web Services Choreographies, Journal of Logic and Algebraic Programming, vol. 78, no. 5, pp. 9 16, May-June [14] H. Foster, S. Uchitel, J. Magee, and J. Kramer, Model-Based Analysis of Obligations in Web Service Choreography, in Proc. IEEE International Conference on Internet & Web Applications and Services, [15] G. Salaun, L. Bordeaux, and M. Schaerf, Describing and reasoning on web services using process algebra, in Proc. IEEE International Conference on Web Services, [16] X. Fu, T. Bultan, and J. Su, Analysis of interacting BPEL web services, in Proc. WWW2004, [17] H. Foster, S. Uchitel, J. Magee, and J. Kramer, Tool support for model-based engineering of web service compositions, in ICWS 05: Proceedings of the IEEE International Conference on Web Services. Washington, DC, USA: IEEE Computer Society, 2005, pp [18] S. Lu, A. Bernstein, and P. Lewis, Automatic workflow verification and generation, Theoretical Computer Science, vol. 353, no. 1, pp , [19] Formal Systems (Europe) Ltd., Failures-Divergence Refinement: FDR2 User Manual [Online], 2003, [Accessed 9 April 2009]. APPENDIX: NOTATIONS OF CSP In the language of CSP, a process is described in terms of the possible interactions it can have with its environment, which may be thought of as another process or set of processes. Interactions are described in terms of instantaneous atomic synchronisations, or events. A process can be considered as a black box with an interface containing a number of events through which it interacts with other processes. The set of all events in the interface of a process P, written αp, is called its alphabet. It is important to note that interface events are intended as synchronisations between the participating processes and not as autonomous actions under the control of a single process. The following paragraphs briefly introduce the CSP operators used in this paper. A comprehensive description of the language is found in [7], [8]. The language of CSP used in this paper is defined by the following pseudo Backus-Naur form definition: P ::= STOP a P a : A P a μ X P P P P P if b then P else P SKIP P; P P P P \ A A where Σ is the set of all possible events, a ranges over Σ, and A Σ; b is a Boolean expression; X ranges over any CSP processes. Let a and b be events and P, Q, and R be CSP processes. The process STOP is the deadlocked process, unable to engage in any events or make any progress. The prefix process a P is ready to engage in event a (and in no other event). It will continue to wait until its environment is also ready to perform a, at which point synchronisation on this event will occur. Once the event is performed, the subsequent behaviour of a P will be that of process P. The prefix choice a : A P a remains willing to perform any event from set A until one is chosen. Its subsequent behaviour, described by P a, is dependent on that event. A construct can be defined to allow the input on channel in of any item x in a set M, and the value x determines the subsequent behaviour: in?x : M Q(x) = a : in.m P a where the set in.m = {in.m m M} and P in.m = Q(m) for every m M. The atomic synchronisation events here are of the form in.m. Furthermore, given channels in 1, in 2, defined over message types M 1, M 2,, { in 1, in 2, } is short for the union of the sets in 1.M 1, in 2.M 2,. The complement to the input construct is the output prefix which has the form out!a P and this is simply a shorthand for out.a P. The notation μ X P defines a process recursively by allowing X to appear within P. For instance, μ X a X is the process that repeatedly offers to engage in a. Given two processes P and Q, an external choice P Q is initially ready to engage in events that either P or Q is ready to engage in. The first event performed resolves the choice in favour of the component that was able to perform it, and the subsequent behaviour is given by this component. In contrast, an internal choice P Q is resolved non-deterministically and the environment plays no parts in resolving the choice. if b then P else Q is the usual boolean choice. The binary operators for internal and external choice

9 also have their indexed versions, e.g. x {0,1,2} P i is short for P 0 P 1 P 2. SKIP is the process that does nothing but terminates successfully. In the sequential composition P; Q, the combined process first behaves as P and Q becomes active immediately after the successful termination of P. P Q is the parallel composition of P and Q in which A the two processes must synchronise on events in the set A. For instance, ( ) (a P b Q) (a R) =a {a} P R {a} In P \ A, P s ability to synchronise with the environment on any event a A is disabled, with all such events taking place internally (hidden) as soon as they are ready. Given two CSP processes P and Q, P is a tracesrefinement of Q, written as Q t P, if any trace of events happen in P can also happen in Q. For instance, if Q = a Q b Q and P = a P, wehave: Q t P since Q does allow for an indefinite sequence of a s, as it happens in P (although Q also allows other sequences involving both a s and b s). Finally, a process is defined with a name in an equationlike format: name = expression