Docstoc

semantics of bpel4ws like fault and compensation handling

Document Sample
semantics of bpel4ws like fault and compensation handling Powered By Docstoc
					Semantics of BPEL4WS-like Fault and Compensation Handling
Qiu Zongyan, Wang Shuling, Pu Geguang, and Zhao Xiangpeng
LMAM and Department of Informatics, School of Math., Peking University, Beijing 100871, China Email: zyqiu@pku.edu.cn, {joycy, ggpu, zxp}@math.pku.edu.cn

Abstract. BPEL4WS is one of the most important business process modelling languages. One distinct feature of it is the fully programmable fault and compensation handling mechanism, which allows the user to specify the compensation behaviors of processes in application-specific manners. In this paper, we present a formal operational semantics to a simplified version of BPEL4WS, with some important concepts related to fault and compensation handling proposed and discussed, especially, the compensation closure and the compensation context. We also discuss some insights into the BPEL4WS language and its implementation obtained from this study. Keywords: Business Process, Language, Semantics, BPEL4WS, Compensation handling, Fault handling

1

Introduction

In recent years, many business process modelling languages (also known as choreography languages) have been introduced and used in the business application fields, such as XLANG [3], WSFL [4], BPEL4WS [5], and StAC [7]. These languages are used to define the services composed by a set of processes across networks, especially over the Internet. The complex services are defined in term of the interaction among simpler services, which might be still a composition in the same manner. Now, BPEL4WS is the most accredited candidate for becoming a standard of this field. Some of these languages are aimed to describe services with long duration, based on communication of distributed processes, and manipulate sensitive business data in back-end databases, to support the concept of Long-Running (Business) Transactions (LRTs). Here, the ordinary assumptions about primitive operations (Atomicity, Consistency, Isolation, Durability, ACID) are not applicable in general, because that locks and isolation cannot be maintained for the long periods, and technical and business errors and fault conditions can occur in any business process instance, propagate to other processes via interactions, and cause them to go into troubles. In [5], the authors wrote:
Supported by National Natural Science Foundation of China (No. 60173003).

1

As a result, the overall business transaction can fail or be cancelled after many ACID transactions have been committed, and the partial work done must be undone as best as possible. Error handling in business processes therefore relies heavily on the well-known concept of compensation, that is, application-specific activities that attempt to reverse the effects of a previous activity that was carried out as part of a larger unit of work that is being abandoned. The concept compensation has, of course, become one of the most important elements of the languages of this category. Although the compensation can be regarded as a kind of exception handling mechanism, however, it has the distinct feature that compensation handlers are installed dynamically during the execution. There is still no standard definition for the compensation mechanism. [9] defined the compensation as the action taken to recover from error or cope with a change of plan, while [6] proposed a formal framework for the automatic invocation of compensation handlers in the reverse order with respect to the order of their installation. Aimed to be a language for web services and the LRTs, BPEL4WS provides a special form of compensation mechanism. In combination with its fault handling mechanism, it offers the full ability to define fault and compensation handling in application-specific manners. The characters of the compensation mechanism in BPEL4WS include: Scope-based (not activity-based). The compensation handlers can only be attached to the scopes; Fault trigged. A compensation handler can only be invoked directly or indirectly by some fault handler, which is triggered by a fault in the execution; Fully programmable. The compensation handlers are named. The installed handlers can be invoked in any order, interweaved with any other activities. Although some works have been done on the semantics of BPEL4WS, e.g. [12], or on the compensation mechanisms, e.g. [7] and [6], there have not been formal studies on the BPEL4WS-like compensation mechanisms. As an industrial language aimed to be a standard language with seminal features, formal studies may clear the opaque points in the languages, and even uncover inadequate combinations or inconsistencies there. This is the aim of our work. In this paper, we defined a simple language BPEL in Section 2, which is a simplification of BPEL4WS, and covers the most important features related to the fault and compensation handling mechanisms of the language. We presented a formal semantics for BPEL in Section 3, and developed the concepts of compensation closure and compensation context, which form a clear framework to the BPEL4WS-like fault and compensation handling mechanisms. We also proved two theorems to validate the semantics defined, and presented some examples for the demonstration. In Section 4, some issues related to the compensation features of BPEL4WS were discussed, including some unclear points in the language specification. We also proposed a possible dynamic resource optimization technique for the implementation of BPEL4WS compensation and 2

fault handling mechanisms. We discussed some issues related to the extensions of our framework, with respect to the features omitted in BPEL. In the last two sections, some relative works were discussed, and then the conclusion.

2

The BPEL Language

BPEL is a subset of BPEL4WS. It includes the most important features related to the fault and compensation handling mechanism of BPEL4WS. We omit all details of BPEL4WS on the data handling level. A complete program written in BPEL is called a Business Process, or BP for the abbreviation. The syntax of BP and its components are defined as follows: P ::= | | | | | | C, F ::= A skip P;P P b P P P n : {P ? C : F } n (basic activities) (do nothing) (throw) (sequence) (conditional) (flow, parallel composition) (scope) (compensation invocation with name) (compensation all) (similar to P ) (business process)

| | ... BP ::= {|P : F |}

Here n stands for names, b for boolean expressions. Their definitions are omitted. P stands for the process. A scope n : {P ? C : F } has the name n and the primary activity P . F and C stand for the fault handler and compensation handler of the scope, respectively. The handlers have the same structures as processes, except that they may include basic activities n and additionally. We ask that the appearing in a fault handler F is not in a branch of a parallel composition in F . The reason of this requirement will be discussed in Section 4. The basic activities in BPEL4WS include assignment, various communication activities, and some others. These activities have effects on the data state or the environment. The details here are out of the concentration of this paper. We use A to represent them. The basic activity throws a fault explicitly. We assume that any fault will be caught by the fault handler of the immediately enclosing scope. We will not consider the named fault until Section 4. In BPEL4WS, the compensation or fault handler of a scope can be omitted. In these cases, the language specification assumes that the scope has the default fault and/or compensation handler with the behaviors as follows: C0 = = F0 = ; =
def def

the default compensation handler the default fault handler

The handler C0 runs all compensation handlers for immediately enclosed scopes in the reverse order of completion of those scopes. The handler F0 runs all available compensation handlers for immediately enclosed scopes in the reverse order 3

of completion of the corresponding scopes, and rethrows the fault to the next enclosing scope. Here we simply assume that every scope has the two handlers defined, perhaps some of them are C0 or F0 . The compensation handling mechanism in BPEL (as in BPEL4WS) is scopebased, fault triggered and programmable. The compensation handlers become active only when they are invoked, directly or indirectly, by a fault handler after a fault occurs during the execution. A compensation handler C, when installed by the normal completion of the primary activity of its scope, has the same name as the scope. The name of a handler is visible only in the immediately enclosing scope, thus, C can be invoked only in the fault handler or compensation handler of the scope. Furthermore, a set of compensation handlers installed can be selected as desired, invoked in any order. That is why we say that the compensation is fully programmable.

3

Semantics

Now we present the semantics of BPEL, with the focus on the fault and compensation handling. We adopt the big-step operational semantics here. Some standard sequence operators are used in the definitions: a0 · a1 , . . . , an = a0 , a1 , . . . , an hd( a1 , a2 , . . . , an ) = a1 tl( a1 , a2 , . . . , an ) = a2 , . . . , an a1 , , . . . , an b1 , . . . , bm = a1 , . . . , an , b1 , . . . , bm Here we consider only the interactive activities that communicate with other services or clients, assuming that all basic activities are different from each other, while they may contain unique identities. The execution of a basic activity might complete (terminate successfully) or fail (terminate with a fault). We use A→ A→ A completes A fails

respectively, to denote the two cases. We call and the termination marks, and will use to represent either of them, ∈ { , }. Note that the termination status of an activity is determined by the environment of the BP. We will use Γ , possibly with subscript, to represent the environment under consideration. An environment Γ is of the form A1 → , . . . , An → . We assume that in any valid environment, Ai = Aj when i = j, and use Γ1 ∪ Γ2 to represent the combination of environments, assuming there is no confliction between Γ1 and Γ2 . The configuration of the transition system includes a process or a mark to denote the termination status, and a compensation context α: P, α or ,α

We call configurations of the form , α the terminated configurations. A compensation context is a sequence (possibly empty) of compensation closures of 4

the form (n : C : α1 ), where n is a name, which is actually the same as that of the scope where compensation handler C is defined, and α1 is a compensation context. When compensation handler C is invoked, it will run in company with the context α1 . When c = (n : C : α), we use c.1, c.2 and c.3 to obtain the name, the compensation handler, and the context, respectively. The semantics of a process is given by the relation Γ cfg 1 → cfg 2 , where cfg 2 is a terminated configuration. Now we list the rules that define the semantics with brief explanation. 3.1 Sequential Process

We consider the sequential part of BPEL in this section. The activity skip always completes, in any environment: Γ skip, α → ,α (throw) fails in any environment, (THRW) (SKIP)

The basic activity Γ ,α → ,α

In BPEL4WS, the throw activity carries a globally defined name, to transfer the control to a specific fault handler. We omit this facility and suppose that a fault is always caught by the fault handler of its immediately enclosing scope. It is not hard to extend the definitions here to deal with named faults. An interactive activity will complete or fail depending on the environment. It has no effects on the compensation context: A→ A, α → ,α (BASIC)

Here we use to represent those two different cases, ∈ { , }. We introduce following rule for the environment extension: Γ1 P, α → , β Γ1 ∪ Γ2 P, α → , β (EXTD)

From now on, whenever we write Γ cfg 1 → cfg 2 , we will always assume that the environment Γ provides enough information for all basic activities in cfg 1 , to determine their termination status. The semantics of the sequential composition P1 ; P2 is defined by two rules, depending on the completion or failure of P1 : Γ1 P1 , α → Γ1 ∪ Γ2 , γ Γ2 P2 , γ → P1 ; P2 , α → , β ,β Γ Γ P1 , α → , β P1 ; P2 , α → , β (SEQ-S)

When P1 completes, the termination status of P1 ; P2 is determined by P2 . If P1 fails, P2 will not be taken into the execution. The execution of P1 (and P2 , in the first case) may extend the compensation context α to another compensation context β, by adding some compensation closure(s) in the front of α. 5

For the conditional, we suppose that the boolean expression b gives a value of true or false, and determines which branch is chosen. In a more detailed semantics, we will need a data state to support the evaluation of b. b = true Γ P1 , α → , β Γ P1 b P2 , α → , β b = false Γ P2 , α → , β Γ P1 b P2 , α → , β (COND-S)

The compensation handler and fault handler are defined in a scope s, in addition to the primary activity P of s. When the execution comes to s, the primary activity P is executed with an empty context initially. When P completes, the compensation handler is installed with its context accumulated during the execution of P , which forms a compensation closure, and put in the front of α. A sequence of compensation closures will accumulate in this way: Γ Γ P, → , β n : {P ? C : F }, α → , (n : C : β) · α (SC-SUC)

When P fails, the execution switches to the fault handler, and the termination status of the fault handler F is the termination status of the scope: Γ1 P, → , β Γ2 F, β → , γ Γ1 ∪ Γ2 n : {P ? C : F }, α → , α (SC-FLT)

Please note that, when P fails, compensation handler C will never be installed. The operations and n can appear only in the body of the fault and compensation handlers. The operation invokes each handler in the related compensation context sequentially. There are two rules for the cases that α is not empty, and one for α = : Γ Γ , → , , (CP-ALL0) (CP-ALL1) (CP-ALL2)

C, β → , γ Γ ,α → Γ , (n : C : β) · α → , Γ C, β → , γ , (n : C : β) · α → ,

Γ

Because the compensation closures are accumulated in the front of the context, will invoke them in the reverse order of their installation. The execution of a series of compensation closures is not the same as the execution of a sequential composition process. There is no accumulated compensation context, and the context need to switch each time. A compensation handler is always invoked directly or indirectly as part of the processing of some fault handler. If the behavior of a compensation handler C invoked by F causes a fault, and the fault is uncaught by scopes within the chain of compensation handlers invoked by F , it is treated as being a fault within F . Above semantic rules reflect this situation, as the definition of BPEL4WS specification. 6

Operation n looks up the compensation closure with the name n in current compensation context. If no closure with the name is found, it acts like a skip, otherwise, the handler in the closure is executed in company with its context: Γ gp(n, α), ge(n, α) → Γ n, α → , α ,β (CP-NM)

where gp(n, α) and ge(n, α) extract the handler and the context of the compensation closure with name n from α, respectively: gp(n, ) = skip gp(n, (n : C : β) · α ) = C gp(n, (m : C : β) · α ) = gp(n, α ) when n = m ge(n, ) = ge(n, (n : C : β) · α ) = β ge(n, (m : C : β) · α ) = ge(n, α ) when n = m

The compensation context accumulated in the invocation is abandoned. Here are the rules for the complete business process: Γ 3.2 Γ P, → , α {|P : F |}, → , Parallel Process Γ1 P, → Γ 1 ∪ Γ2 ,α Γ2 F, α → {|P : F |}, → , ,β (BP)

The parallel operator allows more than one activities to be executed concurrently. This brings new problems into the semantics. If we have P0 ; (P1 P2 ); P3 , two branches P1 and P2 start simultaneously after P0 completes, and only when both of them complete, can P3 start its execution. In fact, BPEL4WS offers further mechanism to control the execution order of the parallel activities—the link dependencies. We omit this feature and put it into the further study. From the BPEL4WS specification, when one of the branches fails, the fault handler of the innermost surrounding scope begins its behavior by implicitly terminating all other (concurrent) activities enclosed in the scope, and then starts the execution of its body. This mechanism is called the forced termination (by a fault occurring in another activity). To define the forced termination, a new termination mark is introduced to describe that a process is forced to terminate. We should modify some rules defined before for the sequential processes, to take the forced termination into account. Firstly, all basic activities will be allowed to complete their work as before1 . But the completion can be thought as a forced termination: Γ Γ Γ1
1

A, α → A, α →

,α ,α

(FORCE)

The rules for the sequential composition are modified as follows: P1 , α → , γ Γ2 P2 , γ → τ, β Γ1 ∪ Γ2 P1 ; P2 , α → τ, β where τ ∈ { , , } (SEQ-SUC)

In BPEL4WS, simple basic activities, e.g., assignment, are allowed to complete their work, but the activities involving communication are interrupted and terminate prematurely. We can have other choices, and will discuss the issues in Sec. 4.

7

and Γ Γ P1 , α → τ, β P1 ; P2 , α → τ, β where τ ∈ { , } (SEQ-FLT)

The rules for conditionals are modified to (where τ ∈ { , , }): b = true Γ P1 , α → τ, β Γ P1 b P2 , α → τ, β b = false Γ P2 , α → τ, β Γ P1 b P2 , α → τ, β (COND)

The original rules for the scope are kept. One new rule is added: Γ1 P, → , β Γ2 F, β → , γ Γ1 ∪ Γ2 n : {P ? C : F }, α → , α (SC-FORCE)

When a scope is forced to terminate, its primary activity P is forced to terminate, and the control transfers to the fault handler. The language forbids the fault handler to re-throw a fault. In the other word, in this case, the fault occurring during the execution of F will not be propagated out of F . With above rule, a fault handler F will terminate with either or , but never with . Thus, it can always finish its work, whatever it is invoked by a fault occurring in the normal execution, or invoked by the forced termination. Now we can have a rule for parallel composition: Γ1 P, α → τ1 , α α Γ2 Q, α → τ2 , α α Γ1 ∪ Γ2 P Q, α → τ1 ⊗ τ2 , (α α ) · α where τ1 , τ2 ∈ { , , } (PAR)

The operator ⊗ is defined in the following table: ⊗

It is similar to the corresponding operator defined in [6]. A new form of elements is introduced into the compensation context to support parallel compensation. In this case, we should add two rules for : Γ1 and Γ1 , α → τ1 , β Γ 2 , α → τ2 , β Γ1 ∪ Γ2 , (α α ) · α → , either τ1 = or τ2 = (CP-PAR2) , α → , β Γ2 Γ1 ∪ Γ 2 ∪ Γ 3 ,α → ,β Γ3 , α → , (α α ) · α → , ,β (CP-PAR1)

The rule for n remains the same, but the functions used in it should be revised by adding two rules as follows: gp(n, (α ge(n, (α α ) · α) = gp(n, α α α ) · α) = ge(n, α α α) α) 8

In a scope, the names for the immediately enclosed sub-scopes must not be the same. Thus, we can simply concatenate the compensation contexts. The technique for the forced termination here is enlightened by the work in [6], and modified according to our needs. Please note that, in the execution of P Q, if P fails, Q should be forced to terminate. BPEL4WS has a detailed definition of forced termination on each type of activities. All activities other than the simplest ones are immediately interrupted and finished prematurely. The exact termination points depend on the relative speed of the processes. The semantics defined here, and also what in [6], is at an abstract level, which guarantees that the active activities in Q will turn to the forced termination at some points. This brings a form of non-determinism. 3.3 Two Theorems

Theorem 1 (Completeness). The big-step semantics for the BPEL language defined above is complete, i.e., for each well-formed process {|P : F |}, there exists a finite deduction (with a suitable environment Γ ): Γ 1 p 1 , α 1 → τ 1 , β1 ······ Γ n p n , α n → 1 , βn Γn+1 q1 , γ1 → τn+1 , βn+1 ··· Γn+m qm , γm → 2 , βn+m Γ {|P : F |}, → 3 , for some n and m, where Γi ⊆ Γ, τj ∈ { , , }, k ∈ { , }, pn = P , qm = F , and each formula in the sequence is deduced from some formula(e) before it in the sequence using the operational rules defined above. Here pi and qj are some texts. We use the different names for them to emphasis that there is a deduction sequence for the primary activity P and a deduction sequence for the fault handler F . The second sub-sequence can be empty. Proof. Suppose we can construct a deduction sequence ds1 for P with the initial compensation context . If the termination mark of the last formula in ds1 is , then from the rule (BP), the deduction sequence of {|P : F |} is ds1 Γ {|P : F |}, → , (written horizontally to save space)

If the termination configuration of the last formula in ds1 is , α, and suppose we can construct a deduction sequence ds2 for F with the initial compensation context α, and the termination mark of the last formula in ds2 is , then the deduction sequence of {|P : F |} is ds1 ds2 Γ {|P : F |}, → ,

Thus, what we really need to prove is that the deduction sequences for P and F can be constructed. We will prove this by induction on the structure of P 9

and F . Because the only difference between P and F is that there can be some compensation invocations in F , additionally, thus, we can prove the most of cases of them together. In the following, when we say P (possibly with subscription), it always means P or F . And we will suppose the current compensation context is α all the while. – Case P = A, P = skip, or P = . The proof is trivial. – Case P = P1 ; P2 . By induction hypothesis, P1 has a deduction sequence ds1 , with the termination status of P1 . If P1 completes, by the hypothesis, we can construct a deduction sequence for P2 and denote it by ds2 . Thus, from rule (SEQ-S), the complete deduction sequence for P will be: ds1 ds2 Γ P1 ; P2 , α → ,β

where and β are the same as in the last formula of ds2 . In the case when P1 fails, the construction of the deduction for P is simpler. – Case P = P1 b P2 . The deduction sequence for P depends on the value of b. If b is true, we can have a deduction sequence for P1 , and denote it as ds1 . According to rule (COND-S), the deduction sequence for P is: ds1 Γ P, α → ,β

where and β are the same as in the last formula of ds1 . The construction is similar when b is false. – Case P1 P2 . By hypothesis, we can construct a deduction sequence for P1 where the termination status has two possibilities: or till now. Here we must notice that from rule (PAR), P1 may be forced to terminate. So we must consider the construction of a deduction sequence with the forced termination at end. We will not list them here. In fact, the construction is the same as above except that in some places, should be extended to include and the corresponding rules for parallel processes are used instead. We should also note that, the forced termination can only be triggered ultimately by a real fault. In general, each real fault may cause a forced termination “tree” down and backwards. Suppose the deduction sequences for P1 and P2 are ds1 and ds2 respectively, then the deduction sequence for P1 P2 is: ds1 ds2 Γ P1 P2 , α →
1

⊗

2, β

where 1 and 2 are the termination marks of the last formulae in ds1 and ds2 , respectively. And β can also be formed from them too. When the parallel operator is the outmost one in P , i equals iff another j equals , so P can has only two possibly termination states: or . – In order to construct the deduction sequence for n : {P ? C : F }, We must first consider the compensation invocations that can appear in fault handlers. Also, here we can solve the problem when P fails in the cases above. • Case F = n. Suppose the process and compensation context of the closure with name n are c and γ respectively. By hypothesis, we suppose 10

a deduction sequence for c in context γ is ds. From rule (CP-NM), we can get a deduction sequence for P : ds Γ P, α → ,α

where is the termination mark of the last formula in ds. • Case F = . The deduction sequence of is a series of deduction sequences corresponding to the compensation handlers, constructed by the rules (CP-ALL1), (CP-ALL2), (CP-PAR1), and (CP-PAR2). The construction of the deduction sequence for a fault handler F is the same as for a normal process P , and this statement is applicable to the compensation handlers as well. We omit the details here. In the following, we will prove that the deduction sequence for a scope can be constructed. – Case P = n : {P ? C : F }. By hypothesis, we can get a deduction sequence for P , and denote it by ds1 . If P completes, according to rule (SC-SUC), we get the deduction sequence for P: ds1 Γ P, α → ,β

Otherwise, the fault is caught by F . By hypothesis, we denote the deduction sequence for F by ds2 . Then the deduction sequence for P is: ds1 where ds2 Γ P, α → ,β

is the termination mark of the last formula in ds2 .

At the outmost level, the forced termination can appear only in the parallel composition. At the inner levels, we need to consider it for other cases. This will not make real trouble to us, thus, we will not restate that here. BPEL4WS asks that “the fault handler for scope C begins by implicitly terminating all activities directly enclosed within C that are currently active”. With our semantics, we have a theorem as follows. We omit the details of the proof here. Theorem 2 (Forced Termination). The behavior of any fault handler F for scope n : {P ? C : F } begins by terminating all activities directly enclosed within the scope that are currently active. 3.4 Examples

Example 1: A Sequential Process. Consider process b1 = {|n : {A1 ; m : {A2 ? C2 : F2 }; A3 ? C : m; A4 } : F |}, where all basic activities but A3 complete, i.e., the environment Γ is: A1 → , A2 → , C2 → , A3 → , A4 → . For def def simplicity, let P = n : {A1 ; m : {A2 ? C2 : F2 }; A3 ? C : m; A4 }, P = A1 ; m : = = {A2 ? C2 : F2 }; A3 , and F = m; A4 . In the following, we use the semantic rules = for BPEL above to reason about the execution of b1 .
(1) (2) (3) A1 → A2 → A2 → A1 , A2 , → → , , → , (m : C2 : ) (BASIC) (BASIC) (SC-SUC, (2))
def

m : {A2 ? C2 : F2 },

11

(4) (5) (6) (7) (8) (9) (10) (11)

A3 → A1 → C2 → C2 → A4 → C2 → Γ Γ P, b1 ,

A3 , (m : C2 : ) → , A2 → C2 , , A3 → → ,

, (m : C2 : ) P , → , (m : C2 : )

(BASIC) (SEQ-S, (1), (3), (4)) (BASIC) (CP-NM, (6)) (BASIC) (SEQ-S, (7), (8)) (SC-FLT, (5), (9)) (BP, (10))

m, (m : C2 : ) → A4 , (m : C2 : ) → , A4 → → → , ,

, (m : C2 : ) , (m : C2 : ) , (m : C2 : )

F , (m : C2 : ) →

Although some activity fails in the execution of b1 , the whole business process completes because of proper compensation. Example 2: A Parallel Process. We add an activity B1 ; B2 to Example 1, that is parallel with the activity A3 , then have a process b2 = {|n : {A1 ; m : {A2 ? C2 : F2 }; (B1 ; B2 ) A3 ? C : F } : F |}. P , P are defined as before except that all appearances of A3 are replaced by (B1 ; B2 ) A3 , and Γ is extended to include B1 → , B2 → . However, we may also modify F . Here we omit the details and suppose that Γ F , (m : C2 : ) → , β. According to rule (PAR), activity B1 ; B2 is forced to terminate because of the fault occurring in A3 . With the semantics, we can build two derivations shown below, where the branch B1 ; B2 is forced to terminate before or after the start of B2 . The execution of b2 is based on the results of Example 1. In the first case, we have
(1) (2) (3) B1 → B1 → B1 → B1 → B2 → B2 → B1 → , B2 → , B2 → B1 , (m : C2 : ) → B1 , (m : C2 : ) → , (m : C2 : ) , (m : C2 : ) , (m : C2 : ) (BASIC) (FORCE, (1)) (SEQ-FLT, (2))

B1 ; B2 , (m : C2 : ) → B1 , (m : C2 : ) → B2 , (m : C2 : ) → B2 , (m : C2 : ) → ; B2 → , A3 → , A3 →

In the second case,
(1) (2) (3) (4) B1 → B1 → , (m : C2 : ) , (m : C2 : ) , (m : C2 : ) (BASIC) (BASIC) (FORCE, (2)) , (m : C2 : ) (SEQ-SUC, (1), (3)) ⊗ , (m : C2 : ) (PAR) , (m : C2 : )

B1 ; B2 , (m : C2 : ) → (B1 ; B2 ) (B1 ; B2 )

Both of them have the fact below:
A3 , (m : C2 : ) → A3 , (m : C2 : ) →

From the example, we can see that when a branch in parallel process fails, the time when the other activities that are currently active are forced to terminate is non-determinate.

4
4.1

Discussion
Language Issues

The intention of this work is to make our language BPEL as close as possible to what of BPEL4WS [5], within the issues considered here. With this idea, we 12

meet many problems, with the language specification, and with how to formally define it. We discuss some problems related to the language in this subsection. Within this work, we uncovered some problems which are not clearly defined in the BPEL4WS specification, or probably defined not adequately. We list some of them here with brief discussions: – The BPEL4WS specification says that, the operator (operator compensate in [5]) runs “all available compensation handlers for immediately enclosed scopes in the reverse order”. It says nothing about the handlers installed parallelly. In our definition, we assume that these handlers will execute parallelly. Another choice is to linearize them arbitrarily. – The operator goes not very well with parallel structures. For example, could we write a fault handler of the form P1 ; (Q1 (Q2 ; ; Q3 )); P2 ? What happens when Q1 fails, or a handler called by fails? Beware that a sequence of handler invocations is not the same as a sequential composition, because the compensation context should be switched for each of the handlers. When one of the parallel branches fails, should the other branches be forced to terminate? The language specification does not define this. In fact, any definition will bring some problems. Under this consideration, we simply forbid that runs in parallel with other processes. – BPEL4WS is announced to become a language to specify business processes and protocols, and support LRTs. We are ready to think about a business process that needs to run over days, or even over months or years. As shown very clearly in our semantics, the longer the process runs, the bigger the compensation contexts accumulate. This accumulation will consume much resource. What we think is that, when a transaction in a process comes to its real end, the programmers need a means to clear the compensation context related to it, for example, the accept operator of StAC [7]. The last point above raises some implementation issues as well. When a subtask P in a business process comes to its real end, we could enclose it in a scope n : {P ? skip : . . .}, i.e., with an empty compensation handler. In this form, all the compensation handlers in the enclosed scopes (including those in the even nested scopes) will never be invoked. Thus, the implementation can clear the compensation context accumulated in the execution of P . We hope that the implementation is smart enough to recognize this situation. Furthermore, if a compensation handler is not invoked directly or indirectly by a fault handler, it will never have a chance to run. Then, when a scope completes, we might have a chance to abandon some compensation handlers and their companion contexts. For example, if for the scope n : {P ? C : F }, P completes and produces a context c1 , c2 , c3 , and C calls only c2 , then we can make a closure of the form (n : C : c2 ), and release all resources occupied by c1 and c3 . This is a kind of dynamic resource optimization. We can also think it as a kind of garbage collection. 13

4.2

Other Problems

If a fault occurs in a scope, the fault handler terminates all activities in the scope that are currently active. The rule (FORCE) allows basic activities to complete their work. In BPEL4WS, with the same situation, the activities involving communication are interrupted and terminate prematurely. We can use the rule below to replace rule (FORCE), to simulate the premature termination: A→ A, α → ,α

This means that, even if A can complete, it might be forced to terminate in some situation. Furthermore, we can divide the basic activities into two categories, in which one is interruptable, while the other is not. There are some other structures in BPEL4WS, including the choice, iteration, wait operation, etc. Dealing with the choice and wait operation asks us to include data state into the framework described here. We can include the iteration by extending the syntax with a form b ∗ P . If there are scopes in an iteration, and the scopes complete, more than one compensation closures with the same name may be installed into the corresponding context. This brings no problem to operator . However, what is the meaning when we invoke such handlers by n? BPEL4WS specification does not make it clear. If what we want is to call all the closures with name n in the reverse order of the installation, we can modify the rule (CP-NM) to implement that. In fact, as we think, the iteration goes not very well with the named compensation in BPEL4WS. For example, if we have b ∗ (. . . ; (n1 : {P1 ? C1 : F1 }); (n2 : {P2 ? C2 : F2 }); . . .) and the body of it is executed a number of times, a series of compensation closures named n1 and n2 alternately will be installed. In this case, could we write n1 afterward? And what is the meaning of it? Any answer will not be very satisfactory. It seems that the fully programmable compensation handling is a good idea, and indispensable in some cases. The authors of BPEL4WS give an example in the [5], Section 13.2. On the other hand, the allowance of any structures and combinations in the fault and compensation handlers might bring troubles to the semantics, the implementation and the use of the language. A bundle of mechanisms to provide enough powerful, safe and easy-use programmable compensation is still a topic to investigate.

5

Relative Works

The concept compensation has its root to the seminal work of Saga [8] and open nested transactions [11], and has been studied for a long time in the transaction processing world. In recent years, some works have been done towards the formal definition of the concept. M. Mazzara et al. suggested to merge the fault and compensation handling into a general framework of event handling [10], and presented an operational semantics for their language. They also explained how 14

to program manually the processes of exception handling and nested transactions with compensation handlers in their language. In the recent paper [6], R. Bruni, et al. presented the operational semantics for a series of languages, and some additional features. The compensation in these languages is basic-activity-oriented (each basic activity is in company with a compensation) with no name. The compensation is triggered by a special command, and always executed in the reverse order with respect to the installation. Although there is a simple discussion about programmable compensation, that is not really programmable—at least not as what in BPEL4WS. The paper [7] showed the recent work of M. Butler et al. on their language StAC (Structured Activity Compensation), where the language and its formal operational semantics were presented. The semantics of StAC was defined on its semantic language StACi , which had a complex operational semantics based on the indexed compensation tasks. The authors suggested to use their indexed compensation to model the compensation of BPEL4WS. L. Bocchi, et al. presented in their paper [2] an extension of the asynchronous π-calculus with long-running transactions. The language has a structure called failure bag, which plays the similar role as the compensation context in our semantics, but presents at another level. On the other hand, paper [1] proposed a general framework to systematically evaluate the capabilities and limitations of the language, and presented a detailed, but informal analysis of the language BPEL4WS. The author of [12] developed a process algebra to derive the interactive behavior of a business process out from a BPEL4WS specification. However, the paper focus on the detailed semantics of BPEL4WS, and intentionally neglects a number of aspects, including timeouts, fault handlers, compensation handlers, and so on.

6

Conclusion

BPEL4WS is one of the most important business process modelling languages, aimed to specify the business services which are formed by distributed, interoperational and heterogeneous components (processes) over networks. One distinct feature of BPEL4WS is the fully programmable fault and compensation handling mechanism, which allows the user to specify the compensation behaviors of processes in application-specific manners. The compensation is scopebased, fault-triggered. Each compensation handler belongs to a scope, and can be active only when it is invoked directly or indirectly by a fault handler. In this paper, we studied the semantics of the fault and compensation handling in the BPEL4WS vein. A simple language BPEL is defined, which covers the features of BPEL4WS related to fault and compensation handling. Then a formal operational semantics for the language is presented. In this semantics, we proposed the concepts compensation closure and compensation context, which capture the execution structure and the process of the programmable compensation, and form a good framework to the semantics, and perhaps, to the structures of implementation of BPEL4WS. 15

We defined first a set of rules for the semantics of the sequential part of the language, and then extended it to deal with the parallel parts, with an additional concept of forced termination. Then we proved that the semantics is complete, and it follows the requirement that before a fault handler starts its work, the activities of the same scope which are active will all terminate (as defined by the BPEL4WS specification). At last, some examples are given to show how this semantics works. From this study, we obtain good insights into something of the BPEL4WS-like compensation, which are related to the language design and the implementation. We proposed a dynamic resource optimization technique for the implementation, and discussed some subtleties of the language. As the further work, we are going to integrate the link mechanism into this framework, which is an important way supporting the synchronous of parallel structures in BPEL4WS specification. This will help us to capture and understand all the control flow of the BPEL4WS-like languages. We have already started the work on the semantics of the detailed level of BPEL4WS, and plan to integrate these works together, to form a complete semantics of the language.

References
1. W. Aalst, M. Dumas, and A. Hofstede, and P. Wohed, Analysis of web services composition languages: the case of BPEL4WS. LNCS 2813, pp. 200-215. Springer, 2003. 2. L. Bocchi, C. Laneve, and G. Zavattaro. A calculus for long-running transactions. Proc. of FMOODS’03, LNCS 2884, pp. 124-138. Springer, 2003. 3. S. Thatte. XLANG: Web Service for Business Process Design, http:www.gotdotnt.com/team/xmlwsspecs/xlang-c/default.html. 4. F. Leymann. WSFL: Web Serices Flow Languag, http://www3.ibm.com/software/solutions/webservices/pdf/WSDL.pdf. 5. BPEL4WS, Business Process Execution Language for Web Service, http://www.siebel.com/bpel, 2003. a 6. Roberto Bruni, Hern´n Melgratti, and Ugo Montanari, Theoritical foundations for compensation in flow composition languages, POPL’05, ACM, 2005. 7. M. Butler and C. Ferreira. An operational semantics for StAC, a language for modelling long-running business transactions. LNCS 2949, pp. 87-104. Springer, 2004. 8. H. Garcia-Molina and K. Salem. Sagas, Proc. of ACM SIGMOD’87, pp. 249-259. ACM Press, 1987. 9. J. Gay and A. Reuter. Transaction Processing: Concepts and techniques, Morgan Kaufmann, 1993. 10. M. Mazzara and R. Lucchi. A framework for generic error handling in business processes. Proc. WS-FM’04, ENTCS Vol. 105, pp. 133-145, Elsevier, 2004. 11. J. Moss. Nested Transactions: An Approach to Reliable Distributed Computing. PhD thesis, Dept. of Electrical Eng. and Computer Sci., MIT, 1981. 12. M. Viroli. Towards a formal foundation to orchestration languages. Proc. of WSFM’04, ENTCS Vol. 105, pp. 51-71, Elsevier, 2004.

16


				
DOCUMENT INFO
Shared By:
Stats:
views:4
posted:12/18/2009
language:English
pages:16
Description: semantics of bpel4ws like fault and compensation handling