A Survey of Web services Orchestration and Choreography with

A Survey of Web services Orchestration and Choreography with Formal Models Damjan Kovaˇc ∗ , Denis Trˇcek 1 University of Ljubljana, Faculty of Computer and Information Science, Laboratory of e-media, Trˇzaˇska cesta 25, SI-1001 Ljubjana, Slovenia

Abstract The service-oriented architecture (SOA) promises a new generation of information systems applications based on a new set of standards for enabling self-describing interoperable Web services. Web service orchestration and choreography are both concerned with the composition of Web services to meet the needs of business processes. There are two important standards for modeling and implementing workflows and business processes based on Web services: BPEL follows the orchestration paradigm, and WS-CDL covers the choreography. This paper gives a formal methods focused survey of BPEL and WS-CDL languages. Basic language constructs are presented as core building blocks for business processes. From the perspective of composing Web services to execute business processes, the orchestration is a more flexible approach compared to the choreography. For that reason we concentrate on some BPEL orchestration aspects using formal models: error, event, and compensation handling using extended version of π-calculus, correlation mechanisms using process algebra, and control flow constructs using Petri nets. All of the formal models allow the analysis and verification of BPEL processes what gives a good starting point for better understanding and further investigations on selected BPEL issues. This could also contribute towards the improvement of the quality of BPEL specification, the applicability of BPEL itself and the implementation of real orchestration engines. Key words: SOA, Web Services, Orchestration, Choreography, BPEL, WS-CDL, Correlation, Control flow

∗ Corresponding author. Tel.: +386-1-4768921; fax: +386-1-4264647 Email addresses: [email protected] (Damjan Kovaˇc), [email protected] (Denis Trˇcek). 1 Tel.: +386-1-4768918

Preprint submitted to Elsevier

January 9, 2011

1

Introduction

The most recent answer to the integration challenge of existing and legacy business applications is the Service Oriented Architecture (SOA) on the basis of Web services technologies. The general view of the SOA sees different business applications of different legacy and new developed applications in a standard way through the Web services. Developing the Web services and exposing their functionalities is not sufficient. The further step is a need to compose these functionalities in the right order to define business process, which will make use of exposed functionalities. This is where the BPEL (Business Process Execution Language) [1,12] becomes important. BPEL is a language for the definition and execution of business processes using existing Web services. BPEL enables the top-down realization of SOA through composition, orchestration, and coordination of Web services. So it provides a straightforward way to compose several Web services into new composite services (business processes). BPEL is built on the foundation of XML and Web services; it uses an XML-based language that supports the Web services technology stack, which includes SOAP [26], WSDL [30], UDDI [17], WS-ReliableMessaging [3], WS-Addressing [28], WSCoordination [13], and WS-Transaction [14,15]. Web services can be composed in two ways – by an orchestration and a choreography: • Orchestration refers to a composed business process that may use both internal and external Web services to fulfill its task. The business process is controlled by one of the agent in the system. The process is described at the message level, i.e. in terms of message exchanges and execution order. • Choreography addresses the interactions that implement the collaboration between services. Multiple agents are present where each of them describes its own part in interaction. • Orchestration and choreography address different perspectives. Orchestration is focused on the internal behavior of a business process (process model ). Choreography is focused on the external perspective, looking at process interaction (interaction model ). These perspectives are essential aspects of the SOA. There are two different ways of describing business processes that support orchestration and choreography: • Executable processes allow specifying the exact details of business processes. They follow the orchestration paradigm and can be executed by an orchestration engine. • Abstract business protocols allow a specification of the public message ex2

change between parties only. They do not include the internal details of process flows and are not executable. They follow the choreography paradigm. BPEL follows the orchestration paradigm. Choreography is covered by other standards, such as WSCI (Web Service Choreography Interface) [27] and WSCDL (Web Services Choreography Description Language) [29]. It is worth mentioning that the choreography has not gained support from the industry which would be comparable to BPEL. BPEL is a workflow language that contains a number of primitive and structured activities. This leads to possibility of complex BPEL processes which are hard to analyze, because the semantics of BPEL is not always clear as its specification is presented in an informal way. Important feature of BPEL is that it supports the stateful, long-running interactions involving many parties. As a consequence there are many aspects that should be considered: concurrency, synchronization, correlations, events, faults and compensations handling [21,9]. Researchers attempt to offer theoretical and formal foundations of those aspects; there are many formal mechanisms and methods for analyzing and solving open issues in BPEL, e.g., process algebras [24,25,9,19,33], timed automata [10,11,21], and Petri nets [4,18,6]. This paper presents a brief overview of orchestration and choreography languages with some formal methods. It is organized as follows. Section 2 describes the semantics overview of BPEL orchestration language. Section 3 gives a brief overview of WS-CDL choreography language. In section 4 some BPEL issues are pointed out with their formal representation. Section 5 provides some concluding remarks.

2

BPEL overview

BPEL [1] is an XML-based specification language for business processes orchestration through the interaction of different, existing or possibly dynamically emerging Web services. Business processes can be described in two ways. An executable business process models actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. BPEL is meant to be used to model the behavior of both executable and abstract processes [1]. BPEL process definition can be executed by an orchestration engine, which is the central coordinator. The engine reads the BPEL document and invokes the 3

necessary Web services in the specified order, be it sequentially or in parallel. The process itself will be offered as a new Web service to the clients and can be invoked in the same way. BPEL can express a conditional behavior. For example, an invocation of a Web service can depend on the value of a previous invocation. It can also constructs loops, declares variables, copies and assigns values, defines fault handlers. By combining all the constructs a complex process processes can be defined in an algorithmic manner. BPEL is built on top of the WSDL [30] language for describing the interface of Web services. A Web service interface is specified in terms of port types, operations, and messages (e.g., in an object-oriented area would correspond to interface types, the method names, and method types). As far as BPEL is concerned, the port types are list of operations that are SOAP [26] based messages (e.g., XML data records). A BPEL process can be synchronous (use one, or more request-response operation) or asynchronous (use one or more one-way operation). A synchronous BPEL process blocks the client until the process finishes and returns a result to the client. An asynchronous process does not block the client as it uses a callback to return the result (if any). The structure of BPEL process is described by the following fragment of XML Schema [32,16]:

In a few words, a BPEL process is composed of: (i) a list of partners involved in the process and their role, (ii) the mechanisms to manage events (eventHandlers) and abnormal situations (faultHandlers and compensationHandler), (iii) the business process that is the activities that must be performed to accomplish the service. A BPEL process consists of steps. Each step is called an activity. BPEL sup4

ports basic (atomic actions) and structured (for concurrency and synchronization) activities. The XML Schema fragment describes activity elements [9]:

The next subsections describe the main basic and structured activities, the event, fault and compensation handling mechanisms. Some syntactical details are omitted; elements are expressed using BNF (Backus-Naur Form) formalisms instead of XML Schema. Frequency operators elem?, elem+, elem* mean respectively zero or one, one or more, zero or more occurrences of the element elem.

2.1

Basic activities

The following subsections describe some basic (primitive) BPEL activities [9,7,8], which are used for message exchange. Basic activities are: invoke, receive, reply, throw, compensate, empty, terminate (exit in BPEL 2.0 [12]), assign, and wait.

2.1.1

Invoke

The activity represents an invocation of a Web service operation, which can be synchronous or asynchronous accordingly with the interaction modality used by invoked service. The invoke activity is defined as follows:

In short, partnerLink, portType and operation are used to denote the specific operation supplied by a certain partner, the end-point of the invoked operation and the transport protocol for SOAP requests (HTTP, SMTP,...); 5

inputVariable and outputVariable denotes the variables passed as input to and as output from the service.

2.1.2

Receive

The activity waits for a request and has to specify the interacting partner in terms of its role in the process, port type and operation. The syntax is as follows: standard-elements

2.1.3

Reply

The activity is used to generate a response. There is an important constraint that the reply activity should always be preceded by a receive activity for the same partner, port type and operation. Syntax is as follows: standard-elements

2.1.4

Throw

Throw is used to explicitly signal an internal fault or an exception, which has to have a globally unique name. When the throw is executed, the name has to be specified as well as some variables containing information about the fault. Faults are caught by fault handlers. The syntax is as follows: standard-elements

2.1.5

Compensate

The activity is used to invoke the compensation handler (to undo the effects of already completed activities), which are associated to scopes. Compensation handlers can be invoked only by a fault handler or by a compensation handler associated with outer scopes. If no compensation handler is defined, the default handler compensates all the children scopes. The syntax is: standard-elements

6

2.2

Structured activities

Structured activities describe how a business process is created by composing basic activities into complex structures expressing workflow, control patterns, dataflow, faults handling, external events management and coordination of message exchange between process instances involved in business process. Main structured activities of BPEL include: (i) ordinary sequential or branching composition (sequence and switch), (ii) parallel composition and synchronization (flow), and (iii) nondeterministic choice (pick). The description of these activities follows.

2.2.1

Sequence

Sequence defines sequential composition of activities. A sequential activity contains one or more activities that are executed in the order in which they are listed within the sequence element. The sequence activity finishes when the final activity in the sequence has completed. The syntax: standard-elementsactivity+

2.2.2

Flow

Flow allows parallel execution of basic activities. The flow construct provides concurrency and synchronization. A flow finishes when all of the parallel activities it contains have completed. The simplest use of this activity is equivalent to a nested concurrency construct. The syntax is defined as it follows: standard-elements ? + activity+

2.2.3

Links

This construct allows setting up certain constraints on the elements inside a flow activity. The control link – constraint specifies some order on the execution of the parallel activities. Using links a flow can be viewed as a graph – nodes are activities and edges are the links expressing the interdependencies among activities, that is the order with which they have to be executed. Links are used to express synchronization dependencies between activities. A 7

control link with its name defines a connection between two activities: one defined as a source and one defined as a target. Both, the source and the target, must define explicitly their role in the syntax. The source activity may also specify a transition condition that is a Boolean expression over the process variables; if it is not defined it is intended to be true. A control link between activities A and B indicates that B cannot start before A has either completed or has been skipped. B can only be executed if its associated join condition evaluates to true; otherwise B is skipped. The join condition is expressed in terms of tokens carried by control links leading to B. Each token can take positive (true) or negative (false) value. An activity X propagates a token with a positive value along an outgoing link L if and only if X was executed and the transition condition associated to L evaluates to true. The process by which positive and negative tokens are propagated along controls links, causing activities to be executed or skipped, is called dead path elimination [18]. Control links can cross the boundaries of most structured activities but they cannot cross a scope.

2.2.4

Switch

This construct represents a case-switch construct for implementing branches. The activity consists of an ordered list of one or more conditional branches defined by case elements that can be followed by an optional otherwise branch. The case branches are evaluated in the order in which they appear. The condition is Boolean expression of process variables. The first branch whose condition is true defines the activity to be performed by the switch. The whole activity completes when the selected activity completes. The syntax: standard-elements + activity ? activity

It is worth mentioning that the new BPEL 2.0 [12] renamed switch activity to if activity with equivalent semantics. The if syntax is as follows: standard-elements bool-expr activity * bool-expr activity ? activity

8

2.2.5

Pick

This construct performs the nondeterministic execution of one of several paths depending on an external event. The form of a pick is a set of branches of the form event-activity where exactly one of these branches will be selected. A branch is selected if the event associated with it occurs. When the pick activity has accepted an event, the other events are no longer accepted. Events can be message events handled with the onMessage activity or alarm events handled with the onAlarm activity [12]. The pick activity waits the occurrence of one of the defined events and performs the associated child activity. If more than one of the events occurs then the selection depends on which one occurred first. When the child activity completes then the pick activity completes. The syntax is as follows: standard-elements + ? + activity * activity

2.2.6

Scope

Scopes are hierarchically organized parts into which a complex business process can be divided. Scope provides a behavior context for each activity inside. Each scope has a primary activity that defines the behavior of a scope for normal execution. The primary activity of the scope can be basic activity such as invoke, or it can be a structured activity such as sequence or flow. If the primary activity of a scope is a structured activity, it can have many nested scopes, in which the nesting depth is arbitrary. The scope is shared among all the nested activities. A scope can also have nested scopes with arbitrary depth. Besides activities, scopes can also define local correlation sets, fault, compensation, and event handlers. Variables definition inside a scope holds until it is active and they are visible only within the defined scope. A scope becomes active when its activities can be executed and terminates when all the activities it contains are completed. It is important to point out that the two mechanisms for dealing with abnormal situations, the fault and compensation handler, are in essence concerning with different stages of the computation. In particular, fault handler is the mechanism used during execution of the scope activities, while the compensation is used after the successful termination of 9

the scope. Fault handlers attached to a scope handle faults of all the nested activities of the scope. Faults not caught in a scope are rethrown to the parent scope. Scopes in which faults have occurred are considered to have ended abnormally even if a fault handler has caught the fault and not rethrown it. The syntax is as follows: standard-elements ? ... ? ... ? ... ? ... ? ... activity

Any scope can include fault, compensation and event handlers whose description follows.

2.2.7

Compensation handler

This construct enables a process to undo the effect of a successfully completed scope [18]. The compensation handler is allowed to be performed when the scope terminates successfully – if no fault has been thrown during the execution and all the activities have been performed. It is allowed to access the variables state as they appear at its termination as to interact with other services. Compensation handlers are defined by the following syntax: ? activity

When the compensation activity is executed for a given scope, the compensation handler of this scope will be executed when it is available. This may involve the execution of the compensation handlers associated to only the subscopes of the above given scope. The compensation handler can be invoked by using the compensate activity (Section 2.1.5), which names the scope for which the compensation is to be performed, that is, the scope whose compensation handler is to be invoked. A compensation handler for a scope is available for invocation only when the scope completes normally [1,12]. 10

2.2.8

Fault handler

This construct defines reactions to internal or external faults that occur during the execution of a scope. The catch element handles a fault specified by a fault name. The catchAll element is able to capture any fault. The throw activity (Section 2.1.4) signals faults and interrupts the normal execution of the scope activating the relative fault handler. If it is not defined, a default handler executes. The default handler compensates all the children scopes and the pending fault is rethrown to the parent scope as the whole BPEL process is considered as scope by specification [1,12]. The scope that manages the signaled fault has not the normal termination and its compensation handler is not allowed to be performed. The syntax of the fault handler is the following: ? * activity ? activity

2.2.9

Event handler

The handler defines event-action rule associated with a scope. An event handler is enabled when its associated scope is under execution and may execute concurrently with the main activity of the scope. When an occurrence of the event associated with an enabled event handler is registered (this may be a timeout with onAlarm construct or a message receipt with onMessage construct), the activity of the handler is executed while the scope’s main activity continues its execution. Messages that are caught by an event handler are consumed and it is not allowed that a message sent from a certain partnerLink, portType and operation can be simultaneously consumed by more than one event handler (the same holds true for the receive activity). Event handlers can be defined by the following syntax: ? * ? + activity * activity

11

3

WS-CDL overview

As explained in the previous sections BPEL follows the orchestration paradigm of Web services composition where the central process takes control over the involved Web services and coordinates the execution of different operations (describes process model). The choreography on the other hand does not rely on the central coordinator. Each involved Web service knows exactly when to execute its operations and whom to interact with. The choreography is a collaborative effort focused on exchange of messages from a global point of view (describes interaction model) where all participating services are treated equally [2]. All participants of the choreography need to be aware of the business process, the operations to execute, the messages to exchange, and the timing of message exchanges. Choreography is covered by standards such as WSCI (Web Services Choreography Interface) [27] and more novel WS-CDL (Web Services Choreography Description Language) [29,2]. We focus on WS-CDL description because it can be actually used in conjunction with BPEL in modeling and implementing business processes. The purpose of the WS-CDL is to define multi-party contracts, which describe the externally observable behavior of Web services and their clients (usually other Web services) by describing the message exchanges between them. WS-CDL is an XML-based language standard. As we consider some open BPEL orchestration aspects in the following sections, only the basic overview of WS-CDL is given. It is worth noting the fundamental difference between the concept of choreography and the concept of behavioral interface (i.e. BPEL abstract process). The choreography focuses on interactions seen from the global viewpoint, while behavioral interfaces focus on communication actions seen from the viewpoint of one of the participants [33]. This difference is orthogonal to control flow and the same control flow constructs could be used for describing choreographies and interface behaviors. WS-CDL and BPEL could share the same set of control flow constructs. Choreography models are inherently design-level artifacts and are not intended to be directly executed (like BPEL orchestration models).

3.1

Choreography Package

A WS-CDL choreography description is contained in a package and is essentially a container for a collection of activities that may be performed by one or more of the participating Web services. The behavioral aspect of the message exchanges is described in one or more choreographies (in the Choreography12

Notation section) in terms of activities. There are three types of activities in WS-CDL, namely control-flow activities, workunit activities and basic activities. The syntax of the root package is: informationType* token* tokenLocator* roleType* relationshipType* participantType* channelType* Choreography-Notation*

3.2

Control-flow activities

These activities are block-structured in the sense they enclose a number of sub-activities. They specify ordering rules of activities within that choreography. The control-flow activities include sequence, parallel, and choice. The detailed syntax is described by [9,2]. A sequence activity describes one or more activities that are executed in sequential order – in the same order that they are defined. A parallel activity describes one or more activities that can be executed in concurrent order. This activity completes successfully when all defined activities performing work within it complete successfully. A choice activity enables the selection of only one activity among the set of alternatives. The choice activity has two types of choices: (a) data-driven choice, which is based upon a Boolean condition on data variables and (b) event-driven choice that depends on the occurrence of one among a set of competing events. Such events may be the consequence of an interaction or of an action in the choreography that results in certain variables being populated.

3.3

Workunit activity

A workunit activity prescribes the constraints that have to be fulfilled for making progress and thus performing actual work within choreography. It describes the conditional and repeated execution of an activity. It has several parts, including a reference to the enclosed activity, a guard, a block, and a repetition condition that are modeled as Boolean expressions. The guard and repeat conditions are used to determine whether or not the enclosed activity is executed one or more time. The execution of workunit activity will start with the evaluation of the guard condition; if it is true, the enclosed activity 13

is executed; otherwise it is skipped. If the activity is executed, and once is completed, the repeat condition is evaluated and depending on the result, the activity can be executed again. Thereby it provides a mean for structured loops. The block condition is used to determine if the guard and repeat conditions should wait for variables to become available before being evaluated. A workunit completes successfully when all its enclosed actions complete successfully. The syntax is as follows: Activity-Notation

3.4

Basic activities

These activities represent request/response actions for local activities and invocations of external services. There are five kinds of the basic activities: interaction, perform, assign, noaction and silentaction. The activities noaction and silentaction describe points in a choreography where one participant (role) performs no action or performs an action that does not affect the rest of choreography. The assign activity is used to transfer the value of one variable to another variable within a participant. The perform activity is used to call another choreography to be performed within the context of the execution choreography. The called choreography may be defined within the same package as the caller, or it may be from a completely separate package that has been imported. The perform activity has a binding mechanism to allows the caller’s variables to be bound to free variables in the called choreography. The most important element of WS-CDL is the interaction activity [2]. It describes an exchange of information between participants with a focus on the receiver of the information. An interaction may specify either a request, a response, or a request-response type of information exchange. Its description has three main parts corresponding to (i) the participants involved (element participate); (ii) the information being exchanged; and (iii) the channel for exchanging the information. Information is described by variables, which are used to represent three different types of information: an applicationdependent information (e.g., product code), a state information (e.g. order received), and a channel information. Variables contain values and have an information type. More specific details and syntax is described by [29,2,33]. 14

4

Formal aspects of orchestration

An orchestration language must support activities from both communicating with other Web services and handling workflow semantics. As presented in the previous sections BPEL provides basic and structured activities to address these two issues. Basic activity can be seen as a basic component that interacts with something external to the process itself. In contrast, structured activities manage the overall process flow by specifying the order in which composing activities have to run. BPEL covers most of the business process requirements [20]: asynchronous interactions, flow coordination, business transaction activity and management. BPEL provides different mechanisms to deal with some particular situations. Abnormal situations are covered by exception, event and compensation handling. Fault handler is used during the execution of an activity while the compensation handler when it has been completed. Compensations are related with long running transactions as web transactions can be considered as transactional interactions between organizations. The ACID properties of transactions are not enough as they make sense only when trusted parties are involved over short period of interaction time. SOA presumes loosely coupled world of autonomous trading partners where hard locking of local resources is unfeasible. BPEL introduces the concept of long running transactions as compensation and could be one of the possible methods of implementing WS-BusinessActivity [15] specification, which heavily relies on WSAtomicTransaction [14], and WS-Coordination [13] specifications. Thus the compensation is an important aspect in BPEL and the topic of further research. But due to its complexity there is no work currently in automatic verification of BPEL that supports compensation completely – as stated by [21]. BPEL is not equipped with formal semantics and since it includes a large number of aspects, it is difficult to formally reason on process behavior. There are many issues that are a subject of a research and investigation using different formal methods. Some of the actual BPEL issues as part of process behavior are the following: • dynamism of activities, concurrency, death paths and deadlocks elimination, time analysis of the process, reachability of activities, behavior specification [22,4,11,18]; • correlation mechanisms as concurrent behavior of process instances [24,21]; • describing relationships and semantics of process elements using ontology [23]; • modeling control flows, formal semantics of the composition operators, verification of different properties, detection of inconsistence, timed analysis 15

properties [6,21]; • error, event, and compensation handling mechanisms [9]. The list of these issues is quite long. We concentrate on some of them and try to formally describe them with various formal methods: π-calculus, process algebras, Timed Automata, and Petri nets.

4.1

Error, event and compensation handling

As explained, BPEL provides three different mechanisms, which allow dealing with abnormal situations: fault, compensation and event handling. Documentation shows ambiguities especially about the interdependencies among these mechanisms. We present a model with the smallest set of operators, which meet behaviors presented above. A process algebra π-calculus [10] is used which is appropriate for the orchestration purposes. Its syntax represents processes, parallel composition of processes, synchronous communication between processes through channels, creation of fresh channels, replication of processes, and nondeterminism. A process is an abstraction of an independent thread of control. A channel is an abstraction of the communication link between two processes. Although the π-calculus seems to offer a convenient framework for orchestration, it does not support any transactional mechanism. An extension of the π-calculus is taken into consideration to support transactions [9]. The syntax of processes relies on an infinite set N of names which are ranged over by u, v, w, x, y, z. Tuple (vector) of names {u1 , . . . , un } is denoted by ue, n is understood from the context. I is a finite nonempty set of indexes. The process P can be defined as follows: P ::= 0 |

Inaction

|

P |Q P

|

x(u).P

Input

|

xhui.P

Output

|

(x)P

Restriction

|

if (x = y) then P else Q Conditional

|

!P

Replication

|

h|P ; Q|ix

Transaction

i∈I

Parallel composition Pi

Alternative composition

16

As shown P can be void process 0, P | Q denotes a process composed of P P and Q running in parallel. Alternative composition i∈I Pi indicates a process that behaves like one of Pi (e.g., in binary summation P1 + P2 like P1 or P2 ). An input x(u).P (also called positive prefix) denotes a process that waits to read a name u from the channel (port) x and then behaves like P ; to be more specific x(u).P inputs an arbitrary name z at port x (e.g, a message xhzi that equals xhzi.0) and then behaves like P (z/u) – it means a substitution of free occurrence u with z. An output xhui.P (also called negative prefix) denotes a process that sends the name u along the channel (port) x and then behaves like P . A restriction (x)P behaves as P except that inputs and messages on x are prohibited. A conditional branch is based on name equality. A replication !P denotes an infinite number of copies of P running in parallel; as a consequence a replicated input can be defined: !x(u).P consumes xhwi and behaves like Pi (wi /ui )|!x(u).P . A transaction process is an extension to π-calculus; h|P ; Q|ix behaves as the body P until a transaction abort xhi is signaled and in this case behaves as the compensation Q. The input x(u).P and restriction (x)P are binders of names u and x. The scope of these binders is the process P ; bn(P ) is a set of bound names of P and bni (P ) is set of bound names of P with inputs and replicated inputs as binders. The free names fn(P ) of P are just those names which occur in P not bound either by an input 2 or by a restriction. We write fn(P1 , P2 , . . . ) = fn(P1 ) ∪ fn(P2 ) ∪ . . . . The following equivalence can be given: fn(h|P ; R|ix ) = fn(P ) ∪ fn(R) ∪ {x}. If we want to express BPEL constructs as π-calculus processes we need to consider only processes from a set P rocess that contains well-formed π-calculus processes. The definition follows. Definition 4.1.1 A process is well-formed if the two conditions are met: (a) Received names cannot be used as subjects of input or of replicated inputs – if a process P contains u(v) or !u(v) then u ∈ / bni (P ). (b) Transaction names are distinct. Different transactions cannot share the same activation name and every abort message is able to activate a single compensation. Formally, if a process is of the form P1 | h|P ; Q|ix | P2 | h|R; S|iy | P3 for some P1 , P2 and P3 then x 6= y. The first property says that if a name is received by a certain process it does not use that name to perform input on it. This means that a situation where different Web services support the same operation can be avoided. The second property is used to avoid ambiguity on scope names reflecting BPEL itself that is no any transaction is univocally identified. The semantics of the language is consisting of the laws, which govern the static 2

Note that an output does not bind a name.

17

relations between processes and the laws that rule their interaction. The first step is achieved by defining a static structural congruence relation over the processes. It consists of collection of axioms that allow minor manipulation on the process structure. Definition 4.1.2 The structural congruence is the least congruence satisfying the abelian monoid laws for parallel composition (associativity, commutativity, 0 as identity element) with respect to the following axioms: (a) Scope laws (u)0 ≡ 0, (u)(v)P ≡ (v)(u)P P | (u)Q ≡ (u)(P | Q) if u ∈ / fn(P ) h|(z)P ; Q|ix ≡ (z)h|P ; Q|ix if z ∈ / fn(Q) ∪ {x} (b) Transaction laws h|0; Q|ix ≡ 0 h|h|P ; Q|iy | R; R0 |ix ≡ h|P ; Q|iy | h|R; R0 |ix (c) Floating laws h|zhui | P ; Q|ix ≡ zhui | h|P ; Q|ix The first transaction law defines committed transactions that are equivalent to 0 and cannot fail anymore. The second law moves transactions outside parent transactions but they may still affect children (nested) transactions by means of transaction names. Floating law moves messages outside the transaction thus the messages are moving towards their inputs independently. The laws that describe dynamic interactions between processes are defined by reduction relation which definition follows. Definition 4.1.3 The reduction relation → is the least relation that satisfies the following axioms and rules: xi hvi |

P

i xi (ui ).Pi

→ Pi {v/u}

[COM]

xhxi | !x(u).P → P {v/u} | !x(u).P

[REP]

xhi | h|P ; Q|ix → Q

[FAIL]

P 6= 0

if (x = x) then P else Q → P if (x = y) then P else Q → Q

[IFT] x 6= y

[IFF]

[COM] and [REP] rules model input-output interaction and replication. [FAIL] models transaction failures – when a message on a transaction name is emitted, the body is terminated and the compensation is activated. Transaction aborts are not possible if the transaction is already terminated. [IFT] and [IFF] describe the behavior for conditional branching. 18

4.1.1

Expressing BPEL semantics

This section describes semantics of BPEL in terms of extended π-calculus. We only take a subset of whole BPEL – some basic and structured activities, and error handling as the primary issue as they can be expressed with parallel and synchronization π-calculus primitives. Because BPEL has not formally defined semantics it is complicated to compare its behavior with the one of π-calculus. A mapping is possible if it is limited to concurrency and synchronization mechanisms of BPEL. The syntax of BPEL processes relies on countable sets of port names, ranged over by x, y, z, u, i, o, . . . , fault names, ranged over by f , g, h and scope names, ranged over by z, z 0 ,. . . . Tuples of names are written by ue. The syntax of process A can be described as follows. A ::= empty

Empty

|

invoke(xs , ei, oe)

Synchronous invoke

|

invoke(xs , ei)

Asynchronous invoke

|

receive(xs , ei)

Receive

|

reply(xs , oe)

Reply

|

throw(f, oe)

Throw

|

compensate(z, oe)

Compensate

|

sequence(A, A)

Sequence

|

flow(A, A)

Parallel flow

|

switch(x = y)A; A

Conditional

|

pick((x, ie1 , A), (x, ie2 , A)) Alternative

|

scopez (A, Se , Sf , A)

Scope

This syntax is intuitive and represents an abstraction of the actual BPEL syntax. The scope construct deserves some consideration. The Se and Sf are a finite set of triples of the form (x, ue, A) and (f, ue, A). That means that the event related to port name x or the exception f is handled by the activity A which receives ue as parameters. The term scopez (A, Se , Sf , Ac ) defines a scope with name z, where A represents the process associated with the scope, Se is the set of handled events, Sf is the set of handled exceptions, and Ac is the compensation activity associated with that scope. The set ABP EL contains only well-formed BPEL activities. To give the semantics in terms of π-calculus algebra a function [[[]]]yheui : ABP EL → P rocess is used [9], which maps BPEL activities into π-calculus processes that execute the BPEL activity and flag out yhuei to signal termination. 19

The encoding of some basic and structured BPEL activities into π-calculus algebra follows. a) Asynchronous invoke (one-way) The Web service is invoked by using a channel as service identifier to identify as specific operation of a certain service. Any operation implemented by a Web service can be considered associated to a channel, which is dedicated to receive invocations of the supplied operation. This behavior is translated as follows (xs is the end-point of the service): [[[invoke(xs , ei)]]]yheui = xs heii | yhuei b) Synchronous invoke (request-response) This kind of invocation needs two variables; o is identified as the result of invocation. Session name r is introduced to correlate the invocation with its response (the invoked service S uses this channel to reply): [[[invoke(xs , ei, oe)]]]yheui = r(xs hr, eii | r(oe).yhuei) c) Raising an exception It is combined of an output message on a failure channel that activates the handler responsible for catching it, and by another output that signals to the scope that has to be terminated. The throw(f, oe) is translated as follows: [[[throw(f, oe)]]]yheui = r(throwhi | f hr, oei | r().yhuei) where f represents the exception name while oe the value passes to the handler. The fault signal is consisting of two outputs: one is caught by the fault handler (f hr, oei) that performs an output on r when it completes its activity, and the other one (throwhi) by the scope that terminate its activity. The throw(f, oe) is finished when the fault has been handled. d) Compensate This mechanism is programmed by performing an output on a channel, whose name is the fault name with parameters that have to be passed to the compensation handler: [[[compensate(z, oe)]]]yheui = zhoei | yhuei e) Sequential composition Let the (A, A0 ) be the sequential composition of activity A and A0 ; the encoding of such activity is as follows. [[[sequence(A0 , A00 )]]]yheui = y 0 ([[[A0 ]]]y0 hevi | y 0 (ue).[[[A00 ]]]yheui ), ve = fn(A00 ) The sequencing of BPEL is not a binder operator like π-calculus. Variables scopes infer different semantic behavior with respect of usual binding of 20

process algebra. The problem is when sequentially combining two activities, which include some name input on common names. Thus the second activity cannot be just triggered when the first one terminates but passing additional information to bind the free names of the second activity is required. f ) Parallel composition BPEL allows usage of links to express synchronization dependencies between activities. As noted by [9] it is redundant and the message passing should be used instead. [[[flow(A0 , A00 )]]]yheui = y 0 y 00 ([[[A0 ]]]y0 heu0 i | [[[A00 ]]]y00 heu00 i | y 0 (ue0 ).y 00 (ue00 ).yhuei) g) Scopes Scopes can be interpreted as the wrapping structure containing BPEL processes. Activities inside can be associated to particular mechanisms to handle asynchronous events and failures. Let Az = scopez (A, Se , Sf , C) be a scope. When no fault happens it behaves as the main activity A; event and fault handlers both play their role during the execution of this activity: they are enabled when A is performed and they are disabled when it terminates. Events are handled concurrently with A while faults interrupt its execution. In the case when an event xhvei occurs during the normal execution of a main activity A, if a suitable handler (x, ue, B) ∈ Se is defined for some ue and B, the event is consumed and the scope behaves as the parallel composition (flow) of As and B{ve/ue}. Here ue represents the formal parameters of the handler. If during the execution of a scope an exception throw(f, ve) occurs two different behaviors are possible, depending whether the current fault is handled or not. In the first case, when (f, ue, B) ∈ Sf for some ue and B, the scope behaves as the fault handler B{ve/ue} where ue are the names that represent the formal parameters. In the second case the scope behaves like the parallel composition of throw(f, ve) (the exception is rethrown to the outer scope) and the default handler compensating all the children scopes. Compensation handlers are installed when the activity A terminates without faults. In this case, when compensate(z, o˜) is performed, the scope Az behaves as C{oe/ue} where ue are names substituted by oe. If compensate(z, oe) is performed when A has not completed, the scope behaves as the default handler compensating all the children scopes. The encoding of scope in π-calculus can be described as composition by many threads running in parallel, some managing scope activities, some to event, fault, and compensation handlers. Let hf and he be functions that, given a scope, return the set of handled faults and handled events: hf (scopez (A, Se , Sf , C)) = {x | (x, ue, B) ∈ Sf } he (scopez (A, Se , Sf , C)) = {x | (x, ue, B) ∈ Se }

21

We can use a short form hf (Sf ) and he (Se ). We also define function sn that given A ∈ ABP EL returns the set of scope names contained in A. h) Event handler The definition consists of two parallel processes: the first catching events while the second handling them. Let Se be the set of handled events and yeh a name used to signal the event handler has been disabled, the process implementing the event handling behavior is as follows: EH(Se , yeh ) = (y 0 )({ex | x ∈ he (Se )}) * eneh ().

Y (x,e u,A)∈Se

+ !x(ue).ex huei; yeh hi

diseh



 Y

!ex (ue).[[[Ax ]]]y0 hi 

(x,e u,Ax )∈Se

The signal eneh enables the overall process to become responsive to all the events included in Se . The transaction is introduced to disable event handling: when the signal diseh is raised, events are no longer considered and the termination signal yeh is performed. The actual event handling activities Ax are outside the transaction what ensures that once disabled the whole handler, the activities that are still alive can complete their execution as predicted in BPEL specification. Event handlers are composed in parallel and are specified by the replicated input guarded processes waiting for an incoming message on an event related channel. i) Fault handler The encoding of this construct is similar to the event handler except for the fact, when a fault is thrown, the main activity of the scope must be terminated. After the fault handling, the entire scope has to be terminated as well. Let Sf be set of handled faults and yf h a name used to signal fault handler termination, the process describing the fault handling behavior is as follows: F H(Sf , yf h )) = (y 0 ) * enf h ().

X

f (r, ue).([[[A]]]y0 hi

throwhi)

(f,e u,A)∈Sf

y

0

+ ().(rhi yf h hi); yf h hi

disf h

Fault handler is encoded by alternative composition of input guarded processes waiting for a message on a relative channel. Any process associated to a fault behaves in a way that, when it terminates, the whole fault handler F H also terminates. When the fault handling completes, the including scope and the activating throw(f, ue) are notified. The first by an output on yf h , the second by an output on r. Then they are terminated. j) Compensation handler This construct has to be programmed in a different way. It has to be enabled when the scope starts and installed at the end of the execution if no fault happened. Let A and C be scope and compensation activities, z a scope 22

name and ych a name used to signal handler installation. The process for the scope compensation is defined as follows: CH(A,* C, z, ych ) = ench ().

e).(CC(A, u e) z(u Q 0

CC(A, u) =

throwhi); (y

0

+ )z(ue).[[[C]]]y0 hi ych hi

instch

z 0 ∈sn (A) z hui

where CC(A, ue) is an auxiliary process used to compensate children scopes of A. In the case the handler has been enabled but not yet installed, the behavior means the termination of the scope activity (throwhi) and the compensation of the children scopes (CC(A, ue)). The second case where the compensation handler has been installed consists of the compensation process defined by designers. Specifying the complete scope construct is composed of the event, fault and compensation handlers and by a process that represents the main activity of the scope. Some other open BPEL issues (e.g. speculative parallelism) can be defined in π-calculus algebra as well [9]. In this section we outlined the semantics of BPEL where some constructs has been formally defined with the main focus on BPEL error recovery framework. This framework includes event, fault and compensation handlers, which are programmed by exploiting the event-based mechanisms based on π-calculus language. One important property of such language is mobility: it is possible to transmit channel names that can be used by any process receiving them. This aspect is essential in the formalization of BPEL and plays an important role in the formalization of interaction with request-response services. Another approach of formalizing most of BPEL constructs (including fault handler) is with µ-BPEL and Timed-Automata (TA) language [21] where some time-related properties can be verified.

4.2

Correlation

A basic characteristic of a business process is that its global task is divided into different sessions, called process instances, where each is responsible for carrying on a separate service or work for each client. Service instances must be stateful processes and for that purpose the variables are defined that carry XML data values, messages, and they also define the state of each service instance. Variables can also contain partner links, which are abstract references to other services; similar as in π-calculus where channels are used to exchange the names of channels [9]. Correlation sets are introduced to identify interactions that are related to a 23

given process instance, which is necessary for correct order of dispatched messages between the various concurrent sessions. Each correlation set contains the properties that are aliases for parts of messages and are late-bound constants – once initialized its content will never change. At the given time each process instance has a number of active correlation sets, and the values associated to all their properties uniquely identify the process instance. As an example, all the messages related to a given client request must have the same unique identifier (e.g., client ID).

4.2.1

Case study

As a reference case study we consider a simple example that demonstrates how incoming messages are delivered to the correct process instance by the BPEL engine using correlation mechanisms. The example deals with correlation sets. The BPEL process provides two operations: setValue and getValue. The string value passed to the setValue operation is returned when the getValue operation is invoked. The call to setValue creates a new instance of the BPEL process, which is identified by the identifier passed in with the request message. This request message is stored with the process instance until the getValue operation is invoked. To ensure that the request message for the getValue operation is directed to the correct process instance, the same identifier value must be used in the request message. The operation setValue can be invoked multiple times each time with different identifier to create multiple process instances. The getValue operation can be invoked using different identifiers to retrieve the values passed in by each of the set operations. Only one partner link is specified representing the customer service with two operations setValue and getValue. Four types of exchange messages are used: setValueRequest that is composed of an identifier and a value part, setValueResponse with an identifier part, getValueRequest that has a single identifier part, and getValueResponse, which has a single return value part. To use the correlation sets a property identifier is declared that represents the value for correlating request messages with process instances. Next two properties alias elements are declared, one for each message type (setValueRequest or getValueRequest), which specify how the value is extracted from the message. These elements specify the message type, the part, and the XPath [31] query to use. Four variables are used in BPEL process for storing request (setValueRequestMessage, getValueRequestMessage) and response messages (setValueResponseMessage, getValueResponseMessage). One correlation set with name instanceID is defined that contains the property identifier. This correlation set is then referenced from within the two 24

receive activities. The reference to the correlation set on the first receive has an attribute initiate="yes" which indicates that the correlation set is initialized with the value from the incoming message. This value remains unchanged for the lifetime of the process instance. The reference to the correlation set on the second receive activity ensures that only messages with a matching value for the identifier property are passed to that process instance. If a request message for getValue operation does not contain an identifier value that matches one of the active processes, it is rejected. The logic of the BPEL process can be described in the following pseudo code: Receive setValue request /* create process instance & initializes correlation set */ Reply to setValue with request identifier Receive getValue request /* with matching correlation set value */ Initialize getValue Reply Reply to getValue

The whole BPEL process is defined as follows. Some XML code is omitted for the sake of brevity. xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:ns="http://tempuri.org/Correlation.wsdl" xmlns:ns1="http://tempuri.org/Correlation.xsd1" xmlns:tns="http://tempuri.org/Correlation.wsdl">

25



4.2.2

Abstract syntax

To express basic BPEL correlation constructs a process language has to be introduced. We rely on language defined by [25], which is consisted of mapping BPEL syntax to abstract language syntax to provide an operational semantics that describe the actual behavior and state of a business process at a given 26

time. [24] presents a similar but a more powerful formal process language construction and correlation analysis. Let u be a meta-variable ranging over integer and Boolean values, v over variables of all values, and p over properties that form correlation sets. Metavariable l ranges over Web services end-points that can be conceptually described as triples of partner link, an action name, and a direction; they identify an interaction channel in a unique way. Given meta-variable x, x indicate sequences of x elements such as hx1 , x2 , x3 , . . . , xk i, xi is the i-th element of one such sequence, x ∈ x is used to indicate that x = xi for some i, and the symbol ◦ is used for empty sequence. The syntax of the language is as follows. w ::= v | p

Variables and properties

e ::= any | u | v | f (e)

Expressions

s ::= 0

Empty specification

|

send(l, v, w)

Send a message

|

recv(l, v, w)

Receive a message

|

while(e){a}

Iteration

|

switch(e){a : a}

Switching structure

|

assign(v, e)

Variable assignement

|

source(λ) | target(λ) Internal links operation

|

a; a | (a k a) | a + a

a ::= s

Sequence, flow, and choice Activity

Meta-variable w rages over both variables and properties; their assignment to a value defines the current state of a given process instance. Expressions can be the any identifier, which may have any value in non-deterministic way. With the syntax language definition is quite simple to map BPEL XML elements into the abstract syntax [25]. The part, which needs more accurate description, is the management of correlations. Activities send and recv have extra argument w. Abstract syntax represents messages as sequence of values; thus v indicates variable holding messages, and vi indicates the corresponding variable over its ith subpart or field. As example the one-way invoke activity without correlation ...

is expressed as send(l, v varN ame , v varN ame ). The first parameter is the message receiver end-point, the second is the variables that will contain the received message, and the third contains information on correlations; when no correlations exists this parameter is exactly the same as the second. Let the SOAP message has type msg, which is composed of three parts part1, 27

part2, and part3, it is denoted by variable v = hv1 , v2 , v3 i and let us suppose that the following correlation set is specified inside the invoke activity: ...

By the definitions of correlation sets

the name cname represents a correlation set made of the properties p1 and p2, which are linked to the first and second part of message msg. The correlation set denotes those process instances that exchange messages with given values in the first and second part of the msg messages. The proper abstract syntax is now send(l, hv1 , v2 , v3 i, hp1 , p2 , v3 i). The third parameter hp1 , p2 , v3 i indicates that while the third part of the message in not related to any correlation set, it is exactly the variable v3 , the first two parts are properties p1 and p2 and are correlated to the process instance. If in the current process instance p1 is bound to value u1 and p2 to u2 , then the first and second part of the message are automatically set to u1 and u2 . In the opposite case the recv(l, hv1 , v2 , v3 i, hp1 , p2 , v3 i) only a message carrying u1 and u2 in the first and second part can be received by the process instance. The sample BPEL process defined in Section 4.2.1 can be expressed in the abstract syntax. Four endpoints are used: ls represents an action setValue invoked by the client, ls0 is used to send a response to the client after the invocation of setValue, lg represents an action getValue invoked by the client, and lg0 is used to send a response after invocation of getValue. The symbol v s is used for a variable setValueRequestMessage, containing a request message, which is composed by two parts v1s and v2s representing Identifier and 0 Value. The symbol v s is used for a variable setValueResponseMessage con0 taining a part v1s representing Identifier. Then, the symbol v g represents a variable getValueRequestMessage, containing a part v1g for Identifier, 0 and the symbol v g is used for a variable getValueResponseMessage with a 0 part v1g representing Value. A property p of the correlation set is used for Identifier. The abstract syntax of the example is directly mapped from the BPEL specification as follows: recv(ls , v s , hp, v2s i); 0

assign(v1s , v1s ); 0

0

send(ls0 , v s , v s ); recv(lg , v g , hpi); 0

assign(v1g , v2s ); 0

0

send(lg0 , v g , v g )

28

This activity sequence is more compact as actual BPEL specification.

4.2.3

Operational semantics

To provide an operational semantics describing the actual behavior of orchestrating Web services, the presented abstract syntax is needed to represent the state of a business process at the given time. Abstract syntax has to be extended with run-time aspects. The symbol for activity a is extended as [25]: a ::= 0 | (w → u)s | !a | a kP a Notation (w → u) is called a store and it indicates that in the activity specification s, variable of property wi is associated to value ui for any i. Notation (w → u)(w → u) has the same meaning as (w, w → u, u). Symbol !a indicates that the activity a can be replicated (spawned) and then executed infinite times; the operator kP is used for parallel composition of process instances while the operator k indicates parallel composition different activities inside the same process instance. While stores are used to model the current state of a process instance (in terms of variables and correlation sets), replication is used at the top level to deal with process instances. If s is a BPEL activity, then !(◦ → ◦)s is the initial state of the business process that replicates a new process instance with initially empty store each time the first message of each work session is received. To define operational semantics some congruence rules [24,25] (similar as in section 4.1.1.) have to be specified in abstract syntax as shown below: !a ≡ !a kP a (w → u)0 ≡ 0

[CREP]

a kP 0 ≡ a a kP a0 ≡ a0 kP a a kP (a0 kP a00 ) ≡ (a kP a0 ) kP a00 [CPAR] s k 0 ≡ s s k s0 ≡ s0 k s s k (s0 k s00 ) ≡ (s k s0 ) k s00

[CFLW]

s + 0 ≡ s s + s0 ≡ s0 + s s + (s0 + s00 ) ≡ (s + s0 ) + s00

[CCHO]

s; 0 ≡ s 0; s ≡ s (s; s0 ); s00 ≡ s; (s0 ; s00 )

[CSEQ]

To differ variables from properties a partial operator ⊕ is introduced; it models the store update enforcing the idea that properties are constants: into a process the value of correlation set identifies the process identity that never changes. Operator is defined as follows: (w → u) ⊕ (v → u) ∼ = (w → u)(v → u) (w → u)(p → u) ⊕ (p → u) ∼ = (w → u)(p → u) ∼ (w → u) ⊕ (p → u) = (w → u)(p → u) if p ∈ /w The first definition denotes that variable assignment always updates the store, 29

the second and third that updating property assignment are allowed only if an equivalent assignment already happens in the store. This definition is used to enforce the idea that messages sent and received by a given process instance must suit the correlation set; the notation (p → u) ⊕ (p → u0 ) is meaningless when u 6= u0 . The notation for the stores is simplified as we write (w → u) ⊕ (w0 → u0 ) as a short form for (w → u) ⊕ (w10 → u01 ) ⊕ (w20 → u02 ) ⊕ · · · ⊕ (wk0 → u0k ), where k is the size of w0 and u0 . Evaluation of expression e under the store (w → u) if defined by the notation {w/u}e with the semantics [25]: {w/u}u ∼ = u {w/u}wi ∼ = ui {w/u}f (e) ∼ = f ({w/u}e) ∼ ∼ {w/u}any = u v ∈ / w ⇒ {w/u}v = u As shown in order, values are evaluated to themselves, variables and properties to their associated values, functions by propagating the evaluation to their parameters, the any identifier or a variable not already initialized to any value u. The notation for an evaluation is again simplified by using {w/u}e. Operational semantics is defined by a labeled transition system hA, →, Ii, where A is the set of activities (states of modeling system), ranged over by meta-variable a, and I is the set of labels representing interactions, ranged over by meta-variable α with syntax: α ::= τ | l!u | l?u Presented transition system is used to find out how the state of the business α process evolves as interactions with the partners occur; notation a −→ a0 indicates an activity (state) a moving to a0 by interaction α. τ is the silent action that represents internal computation inside the business process; l!u represents the business process sending a message to the end-point l specifying a message u, and similarly l?u represents receiving a message from the endpoint l. Some rules defining transition relation → are shown below. α

a kP a00 −→ a00 kP a0

α

if a −→ a00

[PAR]

α

α

(w → u)(s0 ; s1 ) −→ (w0 → u0 )(s00 ; s1 ) if (w → u)s0 −→ (w0 → u0 )s00 [SEQ] τ

(w → u)assign(v, e) −→ (w → u) ⊕ (v → {w/u}e)0 l?u0

(w → u)recv(l, v, wp ) −→ (w → u) ⊕ (v → u0 )(wp → u0 )0 l!{w/u}v

(w → u)send(l, v, wp ) −→ (w → u) ⊕ (wp → {w/u}v)0

[ASG] [REC] [SND]

For better understanding of operational semantics, we can use it to describe our correlation example (see Section 4.2.1) and its behavior. For a brevity, we denote the abstract specification shown in Section 4.2.2 by sC composed by ss and sg : 30

sC ::= recv(ls , v s , hp, v2s i); ssa ; sss ; sgr ; sga ; sgs 0

ssa ::= assign(v1s , v1s ) 0

0

sss ::= send(ls0 , v s , v s ) sgr ::= revc(lg , v g , hpi) 0

sga ::= assign(v1g , v2s ) 0

0

sgs ::= send(lg0 , v g , v g )

As an example we consider the following evolution: • The initial state of a business process is a0 = !(◦ → ◦)sC , that is, any copy of the specification sC is ready to be replicated (spawned) whose initial store is void. • At some time, a client sends a request for setValue operation of the kind hproc1 , val1 i asking to set value val1 :

a0

ls ?hproc1 ,val1 i

−→

a0 kP a1

a1 = (v s → hproc1 , val1 i)(p → proc1 )ssa ; sss ; sgr ; sga ; sgs

This is obtained first by replicating-spawning a new process instance by congruence rule [CREP] that receives the request by operational rule [REC], which is executed in the context of [SEQ]. The result of this execution is that the store will contain the variable v s for the received message, while the correlation set property p defining the identifier of the process instance is bound to proc1 . • A new client sends the request hproc2 , val2 i asking to set value val2 ; a new process instance is created similarly to the previous case:

a0 k P a1

ls ?hproc2 ,val2 i

−→

a0 k P a1 k P a2

a2 = (v s → hproc2 , val2 i)(p → proc2 )ssa ; sss ; sgr ; sga ; sgs

Two process instances a1 and a2 are now currently active, each with own state of the store denoted by different instanceID. • The execution of both process instances stops at the sgr activity that waits for getValue request message. The evolution of the process a1 is the follow31

ing (it is similar for a2 ): τ

a0 kP a1 −→ 0

a0 kP (v s → hproc1 , val1 i)(p → proc1 )assign(v1s , v1s ); 0

τ

0

send(ls0 , v s , v s ); sgr ; sga ; sgs −→ 0

a0 kP (v s → hproc1 , val1 i)(p → proc1 )(v1s → proc1 ) 0

0

send(ls0 , v s , v s ); sgr ; sga ; sgs

ls0 !hproc1 i

−→

0

a0 kP (v s → hproc1 , val1 i)(p → proc1 )(v1s → proc1 )sgr ; sga ; sgs The process instance waits now for the request message. The incoming message is necessarily associated to the proper process instance due to the fact that it is allowed only within the process instance providing compatible correlation sets. • The client sends the request for getValue operation in the form hproc1 i asking to get proper stored value from the appropriate process instance a1 identified by the identifier proc1 . The evolution of the process state moves forward: 0

a0 kP (v s → hproc1 , val1 i)(p → proc1 )(v1s → proc1 )recv(lg , v g , hpi); sga ; sgs

lg ?hproc1 i

−→

0

a0 kP (v s → hproc1 , val1 i)(p → proc1 )(v1s → proc1 )(v g → hproc1 i) 0

τ

assign(v1g , v2s ); sgs −→ 0

a0 kP (v s → hproc1 , val1 i)(p → proc1 )(v1s → proc1 )(¯ vg → hproc1 i) 0

0

0

lg0 !hval1 i

(v1g → val1 )send(lg0 , v g , v g ) −→ a0 When the client receives the response value val1 , the process instance a1 terminates because it has no further activities to perform. The same evolution would take place for process instance a2 . If a request message for a getValue operation arrives, which does not contain an identifier value (e.g. different from proc1 , proc2 ) that matches one of the active process instances, the error occurs and the request is rejected by the BPEL server. The presented example shows a fragment how to formalize BPEL process language and express it with proper operational semantics with the concurrent programming languages of well known process algebraic constructs. This allows defining a core formal language for BPEL orchestration language. The correlation mechanisms are modeled in a process algebra, which provides some heterogeneous features and precise modeling an important portion of BPEL. 32

4.3

Control flow

The kernel of BPEL consists of simple communication primitives that may be combined using control-flow constructs expressing sequence, branching, parallelism, synchronization, concurrency, etc. Analysis of these dynamic aspects and their properties is not easy without formalization of BPEL control flow. The constructs found in BPEL, especially those related to control flow, are close to those found in workflow definition languages. In the area of workflow, it has been shown that Petri nets [4,18,6] provide an appropriate foundation for static analysis and verification. Thus the analysis can be performed on BPEL processes by translating them to Petri nets and apply existing Petri net-based analysis techniques and tools. There are many issues that can be analyzed with Petri nets – dead locks, detection of unreachable activities, reachability of specific states, path coverage, liveness, soundness, and reductions of BPEL workflow nets. Several approaches are presented how to translate BPEL constructs to Petri nets (High level Petri nets with colored tokens [4], Petri net based algebra [6], plain Petri transition/place nets [18]) that are used as an intermediate representation where different theoretical techniques and tools can be applied (WofBPEL [18], pose++ [4]).

4.3.1

Petri nets

A Petri net (also known as a place/transition net or P/T net) is one of several mathematical representations of discrete distributed systems. A Petri net is a directed, connected, and bipartite graph in which each node is either a place or a transition [6]. A directed arc connects place with transition. Tokens occupy places. Transition is enabled when there is at least one token in every place connected to a transition. Any enabled transition can fire removing one token from every input place, and depositing one token in each output place. Therefore, a Web service is basically a partially ordered set of operations. It is quite straightforward to map it into a Petri net. Operations are modeled by transitions and the state of the service is modeled by places. The directed arcs between places and transitions are used to specify causal relations. A Petri net that represents the behavior of a Web service contains one input place for absorbing information (with no incoming arcs) and one output place for emitting information (no outgoing arcs). Such Petri net is a good model [6] to manage definition of the composition operators and the analysis as the verification of certain properties (reachability, deadlocks, liveness). We can define formal representation of Petri net and Web service as a foundation for definition of the formal semantics. 33

Definition 4.3.1 A service net is a labeled place/transition Petri net represented by a tuple SN = (P, T, W, i, o, `) where: -

P is finite set of places, T is finite set of transitions that represents the operations of the service, W ⊆ (P × T ) ∪ (T × P ) is a set of directed arcs (flow relation), i is the input place with •i = {x ∈ P ∪ T | (x, i) ∈ W } = ∅, o is the output place with o• = {x ∈ P ∪ T | (o, x) ∈ W } = ∅, ` : T → A ∪ {τ } is labeling function where A is a set of operation names; τ denotes a silent operation, τ ∈ / A.

Silent operations are transition firings that cannot be observed and they are used to distinguish between external and internal behavior of the service. The formal definition of a Web service follows. Definition 4.3.2 A Web service is a tuple S = (N ame, Desc, Loc, U RL, CS, SN ) where: -

N ame is the name of the service, used as its unique identifier, Desc is description of the service (what the service offers), Loc is the location of the server where the service is located in, U RL is the address for the invocation of the Web service, CS is a set of its component services; if CS = {N ame} then S is the basic service otherwise is a composite service, - SN = (P, T, W, i, o, `) is the service net modeling the dynamic behavior of the Web service.

The place i is the initial marking of the service S (only i contains a token). The execution of service S starts when a token is in the place i and finishes when a token reaches the place o.

4.3.2

Modeling Web services

Web service has a specific task and may depend on other Web services. Composition of two or more services generates a new service providing the original individual behavioral logic and a new collaborative behavior to accomplish a new composite task. The algebra is presented that allows the creation of new Web services using existing ones as building blocks. The set of Web services can be defined by 34

the basic grammar [6] in BNF notation: S ::= 

Empty service

|

X

|

S ⊗ S Sequence

|

S ⊕ S Alternative (choice)

|

S  S Unordered sequence

|

µS

|

S k S Parallelism

|

S kc S Parallelism with communication

Service constant

Iteration

The algebra guarantees that each result of an operation on services is a service (closure property) to which algebra operators can be applied again. This can be used to build more complex services by aggregating and reusing existing services through declarative expressions of the service algebra. It is important to note that service composition applies to syntactically different services. Places and transitions of the composed services must be disjoint for proper composition. Let Si = (N amei , Desci , Loci , U RLi , CSi , SNi ) with SNi = (Pi , Ti , Wi , ii , oi , `i ) for i = 1 . . . n be n Web services such that Pi ∩ Pj = ∅ and Ti ∩ Tj = ∅ for i 6= j. a) Sequence This operator allows the execution of two services S1 and S2 . S1 must complete before S2 can start. This is typically the case when a service depends on the output of the previous service. Definition: The service S1 ⊗S2 is defined as a tuple (N ame, Desc, Loc, U RL, CS, SN ) where: • • • • • •

N ame is the name of the new service, Desc is description of the new service, Loc is the location of the new service, U RL is the address for the invocation of the new service, CS = CS1 ∪ CS2 , SN = (P, T, W, i, o, `) where: · P = P 1 ∪ P2 , · T = T1 ∪ T2 ∪ {t}, · W = W1 ∪ W2 ∪ {(o1 , t), (t, i2 )}, · i = i1 , · o = o2 , · ` = `1 ∪ `2 ∪ {t, τ }.

Graphical representation by the Petri net is shown in Fig. 1. 35

S1

S2 ........

i=i1

..

........ o1

..

i2

o=o2

........

Figure 1. Composite service with sequence operator S1 ⊗ S2

b) Alternative The alternative operator allows with given two services S1 and S2 to model the execution of either S1 or S2 , but not both. Definition: The service S1 ⊕S2 is defined as a tuple (N ame, Desc, Loc, U RL, CS, SN ) where: • • • • • •

N ame is the name of the new service, Desc is description of the new service, Loc is the location of the new service, U RL is the address for the invocation of the new service, CS = CS1 ∪ CS2 , SN = (P, T, W, i, o, `) where: · P = P1 ∪ P2 ∪ {i, o}, · T = T1 ∪ T2 ∪ {ti1 , ti2 , to1 , to2 }, · W = W1 ∪W2 ∪{(i, ti1 ), (i, ti2 ), (ti1 , i1 ), (ti2 , i2 ), (o1 , to1 ), (o2 , to2 ), (to1 , o), (to2 , o)}, · ` = `1 ∪ `2 ∪ {(ti1 , τ ), (ti2 , τ ), (to1 , τ ), (to2 , τ )}.

Graphical representation by the Petri net is shown in Fig. 2. S1 ......... .. i1

i

.. ..

.. ..

o1

S2

o .......... . i2

.......... .

o2

Figure 2. Alternative service S1 ⊕ S2

c) Parallelism with communication The parallel operator allows the concurrent execution of two or more services. Concurrent services can synchronize and exchange information (e.g., BPEL control links).

36

Definition: Let C = {(α, β) | (α, β) ∈ T1 × T2 ∪ T2 × T1 } be a set of communication elements. The new service S1 kc S2 is defined as a tuple (N ame, Desc, Loc, U RL, CS, SN ) where: • • • • • •

N ame is the name of the new service, Desc is description of the new service, Loc is the location of the new service, U RL is the address for the invocation of the new service, CS = CS1 ∪ CS2 , SN = (P, T, W, i, o, `) where: · P = P1 ∪ P2 ∪ {i, o} ∪ {pi / (αi , βi ) ∈ C}, · T = T1 ∪ T2 ∪ {ti , to }, · W = W1 ∪ W2 ∪ {(i, ti ), (ti , i1 ), (ti , i2 ), (o1 , to ), (o2 , to ), (to , o)} ∪ {(αi , pi ), (pi , βi ) / (αi , βi ) ∈ C}, · ` = `1 ∪ `2 ∪ {(ti , τ ), (to , τ )}.

Given S1 and S2 and C = {(α, β), (λ, α)}, S1 kc S2 is graphically represented by the Petri net shown in Fig. 3. S1

....... i1

...

o1

... α

p1

i

p2

...

o

... β

i2 S2

...

...

o2

γ

Figure 3. Flow service with control links

It is worth mentioning that other similar mapping models to Petri net exist. [4] present a high-level Petri net (HPN) with guard expression and colored tokens. Translation of BPEL process into HPN consists of translating an operation (atomic operation level translation) where input and output messages are decomposed based on their data type. Next step is generation of HPNs, which denote relationships on operations such as one input message of one operation, is one output message of another operation (operation cluster translation). Final step is combining HPNs produced by the previous steps into one HPN according to activity relationships defined in BPEL specification. More exhaustive approach is presented by [18]. All of the BPEL constructs (activities, control links, event handlers, fault handling, compensation, and termination) are mapped to plain Petri nets. Labeled transitions are used to model basic activities and events. The labels encode meta-data, which is associated with 37

the names of message types sent or received. The unlabeled τ -transitions represent internal actions that cannot be observed by external participant. All of the mapping approaches to Petri nets allow the usage of existing theoretical results and Petri net analysis techniques (analysis of dynamic properties related to unreachable activities, conflicting messages, deadlocks, reduction techniques).

4.3.3

Sample process

We briefly present an example of a process for handling a purchase order that can be mapped to Petri net using mapping rules described in the previous section. On receiving the purchase order from a customer, the process initiates three tasks concurrently: a calculation of the final price for the order, a selection of a shipper, and a schedule of the production with a shipment for the order. While some of the processing can be performed concurrently, there are control and data dependencies between the three tasks. In particular, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule. When the three tasks are completed, invoice processing can be performed and the invoice is sent to the customer. The purchase order process can be described in a BPEL language – some elements (partner links, fault handlers) are omitted for the sake of simplicity and clarity. BPEL definition follows.

38



The process contains three separate sequences that can be executed concurrently: shipping, invoicing, and scheduling. Three basic services with operations are used in the particular sequence: • shippingService with operation requestShipping, • invoiceService with operations initiatePriceCalculation, and sendShippingPrice, 39

• schedulingService with operations requestProductionScheduling, and sendShippingSchedule. The process itself is exposed as purchaseService with a single operation sendPurchaseOrder. Two additional operations are used to receive callback messages during the asynchronous message exchange: sendSchedule, and sendInvoice. The set of communication element is C = {(sendShippingPrice, requestShipping), (sendShippingSchedule, sendSchedule)}. We use parallelism with communication construct to model regular Petri net. The new composite service purchaseService representing business process is defined as shipping kc invoicing kc scheduling = (N ame, Desc, Loc, U RL, CS, SN ): • • • • • •

N ame = “Purchase order service”, Desc = “Process for handling a purchase order”, Loc = “location 1”, U RL = “http://tempuri.org/purchase/sendPurchaseOrder, CS = {invoiceService, shippingService, schedulingService}, SN = (P, T, W, i, o, `) where: · P = {i, i1 , P ship1 , P ship2 , o1 , i2 , P inv1 , P inv2 , o2 , i3 , P sch1 , o3 , o}, · T = {ti , τ , requestShipping, sendSchedule, initiatePriceCalculation, sendShippingPrice, sendInvoice, requestProductScheduling, sendShippingSchedule, to }, · W = {(i, ti ), (ti , i1 ), (ii , τ ), (τ , P ship1 ), (P ship1 , requestShipping), (requestShipping, P ship2 ), (P ship2 , sendSchedule), (sendSchedule, o1 ), (o1 , to ), (ti , i2 ), (i2 , initiatePriceCalculation), (initiatePriceCalculation, P inv1 ), (P inv1 , sendShippingPrice),(sendShippingPrice, P inv2 ), (P inv2 , sendInvoice), (sendInvoice, o2 ), (o2 , to ),(ti , i3 ), (i3 , requestProductScheduling), (requestProductScheduling, P sch1 ), (P sch1 , sendShippingSchedule), (sendShippingSchedule, o3 ), (o3 , to ), (sendShippingPrice, p1 ), (p1 , requestShipping), (sendShippingSchedule, p2 ), (p2 , sendSchedule)}, · ` = {τ , requestShipping, sendSchedule, initiatePriceCalculation, sendShippingPrice, sendInvoice, requestProductScheduling, sendShippingSchedule}.

Graphical representation of the purchase order process by the Petri net is shown in Fig. 4. The result of mapping can be used to perform formal verification and analysis of BPEL processes on the basis of the existing Petri net analysis techniques (reachability, deadlock detection, concurrency, coverage, reduction, and optimization). Thus the BPEL processes can be verified and validated before deploying them into production environments. Several tools for automated analysis of Petri net exist: BPEL2NML, WofBPEL [18], pose++ [4]. 40

i

ti Invoicing sequence

Shipping sequence

Scheduling sequence i3

i1

i2

τ (assign)

initiatePriceCalculation

Pship1

requestShipping

requestProductScheduling

Pinv1

p1

Pship2

sendShippingPrice

Psch1

sendShippingSchedule

Pinv2

o3

p2 sendSchedule

sendInvoice o2

o1

to o

Figure 4. Purchase order composite service

5

Conclusion

This paper gives a survey of BPEL orchestration and WS-CDL choreography languages with formal representation of some selected aspects. BPEL and WSCDL are two important standards for modeling and implementing workflows and business processes based on Web services. BPEL follows the orchestration paradigm that is more flexible approach compared to the choreography. It is becoming de-facto standard for business process modeling and is gaining increasing adoption as a process oriented service composition language. Choreography, which specifies a business process in terms of interactions among the participating parties from a global point of view, has not gained support from the industry comparing to BPEL. The orchestration paradigm follows a central coordinator, which coordinates the execution of different operations on the involved parties. As BPEL has no defined formal semantics to analyze the behavior of business process this paper focuses on some important orchestration aspects that can be analyzed with different formal methods. First we concentrate on error, event, and compensation handling mechanisms that are formally described in the extended version of π-calculus algebra. The second important issue of BPEL is the correlation mechanism that allows to relate operations of the same sessions – this is achieved through correlation sets. The correlation mechanism is expressed using a process algebra that consists of abstract syntax and opera41

tional semantics. The algebra allows studying some properties and features of the correlation. Last important issue of BPEL that is considered in this paper is a control flow. BPEL consists of simple communication primitives that can be combined using control-flow constructs to express sequence, branching, parallelism, synchronization, concurrency, etc. As Petri nets provide an appropriate foundation for static analysis and verification of control flow constructs, the Petri net-based algebra is described and a translation approach into the algebra from BPEL constructs. We have presented a subset of possible formal methods, which are the most suitable for selected orchestration aspects. Our future work could present some other powerful formal models and methods – Timed Automata [22] for the timed analysis, Finite State Automata [4] for the behavior specification and concurrency, Communicating Sequential Processes (CSP) [33] for the behavior verification of collaboration Web services. Other interesting issues are investigation of ontologies between process objects and elements [23], integration of Web services security and trust mechanisms into the existing BPEL and WS-CDL business process languages.

References

[1] Andrews T et al. Business Process Execution Language for Web Services Version 1.1. 5 May 2003. BEA Systems, IBM, Microsoft, SAP AG, Siebel Systems, 2003. URL: http://download.boulder.ibm.com/ibmdl/pub/ software/dw/specs/ws-bpel/ws-bpel.pdf. [2] Barros A, Dumas M, Oaks P. A critical overview of the web services choreography description language (WS-CDL). BPTrends, 2005. [3] Bilorusets R et al. Web Services Reliable Messaging Protocol (WSReliableMessaging). BEA System, IBM, Microsoft, TIBCO Software, 2005. URL: http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdf. [4] Dong W, Yu H, Zhang Y. Testing BPEL-based Web Service Composition Using High-level Petri Nets. Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC ’06). p. 441-444. IEEE Computer Society; 2006. [5] Ghedira G, Mezni H. Through Personalized Web Service Composition Specification: From BPEL to C-BPEL. Electronic Notes in Theoretical Computer Science 2006;146(1):117-132. [6] Hamadi R, Benatallah B. A Petri Net-based Model for Web Service Composition. Proceedings of the 14th Australasian database conference (ADC ’03)–Volume 17. p. 191-20. Adelaide, Australia 2003.

42

[7] Juriˇc MB. Enterprise Java Community: BPEL and Java. TheServerSide.com, April 2005. URL: http://www.theserverside.com/tt/articles/article. tss?l=BPELJava. [8] Juriˇc MB. A Hands-on Introduction to BPEL, Oracle Technology Network. URL: http://www.oracle.com/technology/pub/articles/matjaz\_bpel1.html. [9] Lucchi R, Mazzara M. A pi-calculus based semantics for WS-BPEL. The Journal of Logic and Algebraic Programming 2007;70(1):96-118. [10] Milner R. Communicating and Mobile Systems: The π-Calculus. Cambridge University Press, 1999. [11] Nakajima S. Model-Checking Behavioral Specification of BPEL Applications. Electronic Notes in Theoretical Computer Science 2006;151(2):89-105. [12] OASIS. Web Services Business Process Execution Language Version 2.0 OASIS Standard 11 April 2007. OASIS WSBPEL TC, 2007. URL: http://docs. oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html. [13] OASIS. Web Services Coordination (WS-Coordination). OASIS WS-TX TC, 2007. URL: http://docs.oasis-open.org/ws-tx/wscoor/2006/06. [14] OASIS. Web Services Atomic Transaction 1.1 (WS-AtomicTransaction). OASIS WS-TX TC, 2007. URL: http://docs.oasis-open.org/ws-tx/wstx-wsat-1. 1-spec.pdf. [15] OASIS. Web Services Business Activity (WS-BusinessActivity) Version 1.1. OASIS WS-TX TC, 2007. URL: http://docs.oasis-open.org/ws-tx/ wstx-wsba-1.1-spec-os.pdf. [16] OASIS. Schema for Executable Process for WS-BPEL 2.0. OASIS Standard, 11th April 2007. OASIS WSBPEL TC, 2007. URL: http://docs.oasis-open. org/wsbpel/2.0/OS/process/executable/ws-bpel\_executable.xsd. [17] OASIS. Universal Description, Discovery and Integration (UDDI). OASIS UDDI Spec TC, 2002. URL: http://www.uddi.org/specification.html. [18] Ouyang C, Verbeek E, Vabn der Alst WMP, Breutel S, Dumas M, Hofstede AHM. Formal semantics and analysis of control flow in WS-BPEL. Science of computer programming 2007;67(2-3):162-198. [19] Pahl C, Zhu Y. A Semantical Framework for the Orchestration and Choreography of Web Services. Electronic Notes in Theoretical Computer Science 2006;151(2):3-18. [20] Peltz C. Web Services Orchestration and Choreography. IEEE Computer 2003;36(10):46-52. [21] Pu G, Xiangpeng Z, Shuling W, Zongyan Q. Towards the Semantics and Verification of BPEL4WS. Electronic Notes in Theoretical Computer Science 2006;151(2):33-52.

43

[22] Qian Y, Xu Y, Wang Z, Pu G, Zhu H, Cai C. Tool Support for BPEL Verification in ActiveBPEL Engine. Proceedings of the 2007 Australian Software Engineering Conference (ASWEC ’07). p. 90-100. IEEE Computer Society, 2007. [23] Shen J, Grossmann G, Yang Y, Stumptner M, Schrefl M, Reiter T. Analysis of business process integration in Web service context. Future Generation Computer Systems 2007;23(3):283-294. [24] Viroli M. A core calculus for correlation in orchestration languages. Journal of Logic and Algebraic Programming 2007;70(1):74-95. [25] Viroli M. Towards a Formal Foundation to Orchestration Languages. Electronic Notes in Theoretical Computer Science 2004;105:51-71. [26] W3C. Simple Object Access Protocol (SOAP). WC3, 2000. URL: http://www. w3.org/TR/soap/. [27] W3C. Web Service Choreography Interface (WSCI) 1.0. W3C Note 8 August 2002. W3C, 2002. URL: http://www.w3.org/TR/wsci/. [28] W3C. Web Services Addressing (WS-Addressing). W3C Member Submission, 10 August 2004. URL: http://www.w3.org/Submission/ws-addressing/. [29] W3C. Web Services Choreography Description Language Version 1.0. W3C Candidate Recommendation 9 November 2005. W3C, 2005. URL: http://www. w3.org/TR/ws-cdl-10/. [30] W3C. Web Services Description Language (WSDL) 1.1. W3C Note 15 March 2001. W3C, 2001. URL: http://www.w3.org/TR/wsdl. [31] W3C. XML Path Language (XPath) Version 1.1. W3C Recommendation. W3C, 1999. URL: http://www.w3.org/TR/xpath. [32] W3C. XML Schema. WC3, 2004. URL: http://www.w3.org/XML/Schema. [33] Yeung WL. Mapping WS-CDL and BPEL into CSP for Behavioural Specification and Verification of Web Services. Proceedings of the European Conference on Web Services (ECOWS ’06). p. 297-305. IEEE Computer Society, 2006.

44