Service Oriented Architecture

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 Master of Information System Management

Today’s Topics • Basic BPEL constructs to Petri Nets • Generating and Handling Faults • Defining Scopes and Scope Rules • Correlation Sets • Compensation • Event Handling Master of Information System Management

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: rx ready for activity x sx starting activity x cx completed activity x fx finished activity x Master of Information System Management

to_skipx  rx A Basic Activity X sx X “skip” cx skippedx  fx Master of Information System Management

Structured Activities (normal behavior)(a) sequence rx X sx <sequence name=“X”> activity A activity B </sequence> rA A fA rB B fB fx Master of Information System Management

Structured Activities (normal behavior)(b) flow <flow name=“x”> activity A activity B </flow> rx X sx rA rB B A fA fB cx fx Master of Information System Management

Structured Activities (normal behavior)(c) switch rx <switch name=“X”> <case> <condition> Z1 </condition> activity A </case> <case> <condition> Z2 </condition> activity B </case> </switch> X sx “~Z1 Z2” “Z1” rB rA   A B fB   fA cx fx Master of Information System Management

Structured Activities (normal behavior)(d) pick rx <pick name=“X”> <onMessage e1> activity A </onMessage> <onAlarm e2> activity B <onAlarm> </pick> X sx e2 e1 rB rA   A B fB   fA cx fx Master of Information System Management

Structured Activities (normal behavior)(e) while <while name=“X” <condition> z </condition> activity A </while> X sx “~z” “z” rA A fA cx fx Master of Information System Management

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? Master of Information System Management

Fault Source (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 <portType name="X"> <operation name="foo"> <input message="param1"/> <output message="param2/> <fault name="fault" message="someError"/> </operation> </portType> Master of Information System Management

Handling the Fault(1) • Suppose the synchronous invoke generates a fault. • We can handle it inline: <invoke .... > <catch faultName = "SomeFaultName"> perform activities </catch> <catch faultName="SomeOtherFaultName"> perform activities </catch> <catchAll> ... </catchAll> </invoke> Master of Information System Management

Handling the Fault(2) • Suppose the synchronous invoke generates a fault. This is another approach. • We can use a fault handler. <process...> <partnerLinks>...</partnerLinks> <variables>...</variables> <faultHandlers> <catch faultName or faultVariable> handle fault </catch> <catch faultName or faultVariable> handle fault </catch> <catchAll> handle fault </catchAll> </faultHandlers> <sequence> invoke </sequence> </process> Master of Information System Management

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. Master of Information System Management

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

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). Master of Information System Management

Handling The Fault (4) <process...> <partnerLinks>...</partnerLinks> <variables>...</variables> <faultHandlers> <catch faultName or faultVariable> 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 </catch> <catch faultName or faultVariable> handle fault </catch> <catchAll> handle fault </catchAll> </faultHandlers> <sequence> : <throw faultName="someFaultName"/> </sequence> </process> Master of Information System Management

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. Master of Information System Management

Scope Syntax <scope> <variables>variables local to the scope</variables> <correlationSets>...</correlationSets> <faultHandlers>local handlers</faultHandlers> <compensationHandler>...</compensationHandler> <eventHandlers>...</eventHandlers> BASIC OR STRUCTURED ACTIVITIES </scope> Master of Information System Management

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. Master of Information System Management

Scope Example(1) <process> <partnerLinks>... <variables>... <faultHandlers>... <sequence> <receive> <scope> <variables> <faultHandlers> <sequence> <flow> invoke 1 invoke 2 </flow> </sequence> </scope> <scope> : </scope> </sequence> </process> Master of Information System Management

Scope Example (2) <scope> <faultHandlers> <catch> ... </catch> <catch>... </catch> </faultHandlers> <invoke> : </invoke> </scope> This is equivalent to the inline fault handling example. Faults not caught in a scope are re-thrown to the enclosing scope. Master of Information System Management

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: <scope variableAccessSerializable="yes"> ... </scope> Master of Information System Management

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. Master of Information System Management

Define The Correlation Properties are defined with the WSDL extensibility mechanism and are associated with an Xpath query into a message. <process> <partnerLinks>… <variables>… <correlationSets> <correlationSet name=“TicketOrder” properties=“aln:FlightNo”/> </correlationSets> So, aln:FlightNo is a name that points into a message and TicketOrder is the name of the correlationSet. Master of Information System Management

Use The Correlation(1) <sequence> <invoke> Make an asynchronous call for a flight number. <receive> Receive the response at a later time. : Build a correlation set. <correlations> <correlation set=“TicketOrder” initiate=“yes”/> </correlations> </receive> Let’s confirm this flight on the next slide. : Master of Information System Management

Use The Correlation(2) : : : <invoke> Synchronously confirm flight with the correlation <correlations> <correlation set=“TicketOrder” pattern=“out-in”/> </correlations> </invoke> OK, the flight is confirmed. Tell the customer on the next slide. : : Master of Information System Management

Use The Correlation(3) : : : <invoke> Make a callback on the client with the correlation included <correlations> <correlation set=“TicketOrder” pattern=“out”/> </correlations> </invoke> : : Master of Information System Management

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. • The drop is a compensating activity. It undoes what we initially thought was a good idea. Master of Information System Management

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. • This is not an opportunity for the Two Phase Commit protocol. • The operations completed successfully but now need to be undone. Master of Information System Management

Compensation Handlers(1) • Compensation handlers may be defined for the process, scope or invoke activity. <process> <partnerLinks>… <variables>… <faultHandlers>… <compensationHandler> drop course activities </compensationHandler> <sequence> register for course </sequence> </process> 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. Master of Information System Management

Compensation Handlers(2) • Compensation handlers may be defined for the process, scope or invoke activity. <scope> <variables>… <correlationSets>… <faultHandlers>… <compensationHandler> drop course activities <eventHandlers>… activities to register for a course </scope> Call with <compensate scope=“XXX”/> Where XXX is the name of the scope. Master of Information System Management

Compensation Handlers(3) • Compensation handlers may be defined for the process, scope or invoke activity. <invoke> register for SOA <compensationHandler> activities to drop SOA </compensationHandler> </invoke> 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. Master of Information System Management

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. Master of Information System Management

Event Handlers(1) • Suppose we have a long running claims handling process. • 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 Master of Information System Management

Event Handlers(2) • Suppose a managed process takes too long. • 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 Master of Information System Management

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 Master of Information System Management

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 Master of Information System Management

Service Oriented Architecture