1 SOA Seminar Service Oriented Architecture Lecture 8: More BPEL Notes selected from the paper “Formal Semantics and Analysis of control flow in WS-BPEL by Ouyang and others and the book “Business Process Execution Language for Web Services” by Matjaz Juric

2 SOA Seminar Topics Basic BPEL constructs to Petri Nets Generating and Handling Faults Defining Scopes and Scope Rules Correlation Sets Compensation Event Handling

3 SOA Seminar Basic BPEL Constructs to Petri Nets For all of the BPEL constructs converted to Petri nets see the paper by Ouyang and others. The notation: r x ready for activity x s x starting activity x c x completed activity x f x finished activity x

4 SOA Seminar A Basic Activity  sxsx X cxcx fxfx rxrx “skip” skipped x to_skip x X

5 SOA Seminar Structured Activities (normal behavior) (a) sequence X fxfx rxrx activity A activity B sxsx rArA A fAfA rBrB B fBfB

6 SOA Seminar Structured Activities (normal behavior) (b) flow rxrx sxsx rArA A B rBrB fAfA fBfB cxcx fxfx activity A activity B X

7 SOA Seminar Structured Activities (normal behavior) (c) switch  rxrx sxsx  fxfx fBfB fAfA rBrB rArA AB Z 1 activity A Z 2 activity B “Z 1 ” “~Z 1  Z 2 ” cxcx X

8 SOA Seminar Structured Activities (normal behavior) (d) pick  rxrx sxsx  fxfx fBfB fAfA rBrB rArA AB activity A activity B e1e1 e2e2 cxcx X

9 SOA Seminar Structured Activities (normal behavior) (e) while cxcx A fAfA rArA sxsx “z” “~z” <while name=“X” z activity A fxfx X

10 SOA Seminar Generating and Handling Faults Different types of fault behavior when programming in the large. What do we do if the network is down? What do we do if some other process returns an error? How do we signal errors to synchronous and asynchronous clients?

11 SOA Seminar Fault Source (1) (1)We perform a synchronous invoke and get back a fault. The possibility of a fault being returned is described in the WSDL of the foreign service

12 SOA Seminar Handling the Fault(1) Suppose the synchronous invoke generates a fault. We can handle it inline: perform activities perform activities...

13 SOA Seminar Handling the Fault(2) Suppose the synchronous invoke generates a fault. This is another approach. We can use a fault handler.... handle fault invoke

14 SOA Seminar Fault Source (2) (2) We perform an asynchronous invoke and later we get back a fault. The possibility of a fault being returned is described in the WSDL of the foreign service. Normally, we would handle the return value of an asynchronous request with a receive activity. To prepare for the possibly of a fault, we will use a pick activity.

15 SOA Seminar Handling the Fault(3) (2) Using pick after an asynchronous invoke to handle a fault.... The onMessage can act as a normal receive with almost the same syntax.... The other onMessage can be used to receive the fault notification.... The onAlarm element specifies an end time or duration. It may contain a series of activities or a throw.

16 SOA Seminar Fault Source (3) The BPEL process itself may throw a fault. The BPEL run time may throw a fault. If the fault is not handled the process terminates. There is no automatic passing of the fault back to the client (the business process has to do it).

17 SOA Seminar Handling The Fault (4)... reply or invoke with fault message back to client the invoke option requires the client to provide a regular callback and a callback for the fault handle fault handle fault :

18 SOA Seminar Defining Scope Why define scope? We can define different fault handling for different parts of a process. We can define variables that are local to a scope. We can define local correlation sets, compensation handlers, and event handlers in a scope.

19 SOA Seminar Scope Syntax variables local to the scope... local handlers... BASIC OR STRUCTURED ACTIVITIES

20 SOA Seminar Scope Rules Each scope has a primary activity. This activity may be a basic activity or a structured activity such as sequence or flow. If a scope has a structured activity, it can have many nested activities (all in the same scope). A scope can also have nested scopes with arbitrary depth. Faults not caught in a scope are re-thrown to the enclosing scope. Scopes in which faults have occurred are considered to have ended abnormally even if a fault handler has caught the fault and not re-thrown it.

21 SOA Seminar Scope Example(1)... invoke 1 invoke 2 :

22 SOA Seminar Scope Example (2)... : This is equivalent to the inline fault handling example. Faults not caught in a scope are re-thrown to the enclosing scope.

23 SOA Seminar Concurrency & Scope If an event handler in a scope is executing at the same time as the main process of a scope there is the possibility of conflicting use of shared variables. Scopes that require concurrency control are called serializable scopes. Concurrency is prohibited in the following scope:...

24 SOA Seminar Correlation Correlation is used to match messages with business process instances. A set of properties shared by messages and used for correlation is called a correlation set. Correlation sets are defined and then used in invokes and receives.

25 SOA Seminar Define The Correlation … <correlationSet name=“TicketOrder” properties=“aln:FlightNo”/> Properties are defined with the WSDL extensibility mechanism and are associated with an Xpath query into a message. So, aln:FlightNo is a name that points into a message and TicketOrder is the name of the correlationSet.

26 SOA Seminar Use The Correlation(1) Make an asynchronous call for a flight number. Receive the response at a later time. : Build a correlation set. <correlation set=“TicketOrder” initiate=“yes”/> :

27 SOA Seminar Use The Correlation(2) : Synchronously confirm with the correlation <correlation set=“TicketOrder” pattern=“out-in”/> :

28 SOA Seminar Use The Correlation(3) : Make a callback on the client with the correlation <correlation set=“TicketOrder” pattern=“out”/> :

29 SOA Seminar Compensation(1) Suppose we register for a really cool SOA course but after one week of classes we change our minds. We would prefer to take a course in Latin American History. Lucky for us, the university provides us with the ability to drop/add. The drop is a compensating activity. It undoes what we initially thought was a good idea.

30 SOA Seminar Compensation(2) In business processes, the compensation activity must be explicitly defined. Business processes often last a long time and traditional transaction processing methods are often inappropriate. It’s not the case that a fault is thrown and an error needs to be handled. The operations completed successfully but now need to be undone.

31 SOA Seminar Compensation Handlers(1) Compensation handlers may be defined for the process, scope or invoke activity. … drop course activities register for course The process compensation handler may only be called after the process has completed normally. How it is invoked is dependent on the run-time environment.

32 SOA Seminar Compensation Handlers(2) Compensation handlers may be defined for the process, scope or invoke activity. … drop course activities … activities to register for a course Call with Where XXX is the name of the scope.

33 SOA Seminar Compensation Handlers(3) Compensation handlers may be defined for the process, scope or invoke activity. register for SOA activities to drop SOA The syntax used to call the handler is <compensate name=“xxx” /> where xxx is the name of the invoke activity that needs to be compensated.

34 SOA Seminar Calling Compensation Handlers The activity that is to be compensated must have been completed normally. Nothing happens if we try to compensate an activity that has not completed normally. The values of variables will be the same in the compensation handler as those values after the activity took place.

35 SOA Seminar Event Handlers(1) Example (1): a claims handling process supports the cancellation of a claim while the process is currently running. This may occur once or not at all. To do this, the client of the process invokes the cancellation operation that is implemented using an event handler. This is from IBM Developer Works

36 SOA Seminar Event Handlers(2) Example (2): Expiration of a timeout: A manager wants to be informed when a process takes longer than a week to be finished. Repeated expiration of timeout: a manager wants to be informed when a process takes longer than a week to be finished. After the week is over, the manager wants to be informed each day until the process is finished. From IBM Developer Works

Event Handlers in BPEL WS-BPEL defines two types of event handlers, as follows: An onEvent event handler handles the occurrence of an external message event. This is the invocation of an operation. An onAlarm event handler handles the expiration of a timeout. From IBM Developer Works 37 SOA Seminar

Concurrency Multiple onEvent and onAlarm events can occur concurrently and they are treated as concurrent activities. An event handler is permitted to have several simultaneously active instances. A private copy of all process data and control behavior defined within an event handler is provided to each instance of an event handler. From IBM Developer Works 38 SOA Seminar