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
95-843: Service Oriented Architecture
Master of Information System
Management
1
Today’s Topics
• Basic BPEL constructs to Petri Nets
• Generating and Handling Faults
• Defining Scopes and Scope Rules
• Correlation Sets
• Compensation
• Event Handling
95-843: Service Oriented Architecture
Master of Information System
Management
2
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
95-843: Service Oriented Architecture
Master of Information System
Management
3
A Basic Activity
to_skipx

rx
X
sx
X
“skip”
cx
skippedx

95-843: Service Oriented Architecture
Master of Information System
Management
fx
4
Structured Activities (normal behavior)
(a) sequence
rx
X
sx
<sequence name=“X”>
activity A
activity B
</sequence>
rA
A
fA
rB
B
fB
95-843: Service Oriented Architecture
Master of Information System
Management
fx
5
Structured Activities (normal behavior)
(b) flow
<flow name=“x”>
activity A
activity B
</flow>
rx
X
sx
rA
rB
B
A
fA
fB
cx
95-843: Service Oriented Architecture
Master of Information System
Management
fx
6
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”

rA

B

A
fA
“~Z1 Z2”

rB
fB
cx
95-843: Service Oriented Architecture
Master of Information System
Management
fx
7
Structured Activities (normal behavior)
(d) pick
rx
<pick name=“X”>
<onMessage e1>
activity A
</onMessage>
<onAlarm e2>
activity B
<onAlarm>
</pick>
X
sx
e1

rA

B

A
fA
e2

rB
fB
cx
95-843: Service Oriented Architecture
Master of Information System
Management
fx
8
Structured Activities (normal behavior)
(e) while
<while name=“X”
<condition>
z
</condition>
activity A
</while>
X
“~z”
sx
“z”
rA
A
fA
cx
95-843: Service Oriented Architecture
Master of Information System
Management
fx
9
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?
95-843: Service Oriented Architecture
Master of Information System
Management
10
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
<portType name="X">
<operation name="foo">
<input message="param1"/>
<output message="param2/>
<fault name="fault" message="someError"/>
</operation>
</portType>
95-843: Service Oriented Architecture
Master of Information System
Management
11
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>
95-843: Service Oriented Architecture
Master of Information System
Management
12
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>
95-843: Service Oriented Architecture
</process>
Master of Information System
Management
13
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.
95-843: Service Oriented Architecture
Master of Information System
Management
14
Handling the Fault(3)
(2) Using pick after an asynchronous invoke to handle
a fault.
<pick>
<onMessage>...
</onMessage>
<onMessage>...
</onMessage>
<onAlarm>...
</onAlarm>
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.
</pick>
95-843: Service Oriented Architecture
Master of Information System
Management
15
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).
95-843: Service Oriented Architecture
Master of Information System
Management
16
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>
95-843: Service Oriented Architecture
Master of Information System
Management
17
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.
95-843: Service Oriented Architecture
Master of Information System
Management
18
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>
95-843: Service Oriented Architecture
Master of Information System
Management
19
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.
95-843: Service Oriented Architecture
Master of Information System
Management
20
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>
95-843: Service Oriented Architecture
Master of Information System
Management
21
Scope Example (2)
<scope>
<faultHandlers>
<catch> ... </catch>
<catch>... </catch>
</faultHandlers>
<invoke>
This is equivalent
to the inline fault handling
:
example.
</invoke>
Faults not caught in a scope
</scope>
are re-thrown to the enclosing
95-843: Service Oriented Architecture
Master of Information System
Management
scope.
22
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>
95-843: Service Oriented Architecture
Master of Information System
Management
23
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.
95-843: Service Oriented Architecture
Master of Information System
Management
24
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.
95-843: Service Oriented Architecture
Master of Information System
Management
25
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.
:
95-843: Service Oriented Architecture
Master of Information System
Management
26
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.
:
:
95-843: Service Oriented Architecture
Master of Information System
Management
27
Use The Correlation(3)
:
:
:
<invoke> Make a callback on the client with the
correlation included
<correlations>
<correlation set=“TicketOrder”
pattern=“out”/>
</correlations>
</invoke>
:
:
95-843: Service Oriented Architecture
Master of Information System
Management
28
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.
95-843: Service Oriented Architecture
Master of Information System
Management
29
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.
95-843: Service Oriented Architecture
Master of Information System
Management
30
Compensation Handlers(1)
• Compensation handlers may be
defined for the process, scope or
The process
invoke activity.
compensation
handler may only
<process>
be called after the
<partnerLinks>…
process has
<variables>…
completed
<faultHandlers>…
normally.
<compensationHandler> drop course activities
How it is invoked
</compensationHandler>
is dependent on
<sequence> register for course
the run-time
</sequence>
environment.
</process>
95-843: Service Oriented Architecture
Master of Information System
Management
31
Compensation Handlers(2)
• Compensation handlers may be defined
for the process, scope or invoke
activity.
Call with
<scope>
<compensate scope=“XXX”/>
<variables>…
Where XXX is the name of the
<correlationSets>…
scope.
<faultHandlers>…
<compensationHandler> drop course
activities
<eventHandlers>…
activities to register for a course
</scope>
95-843: Service Oriented Architecture
Master of Information System
Management
32
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>
95-843: Service Oriented Architecture
Master of Information System
Management
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.
33
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.
95-843: Service Oriented Architecture
Master of Information System
Management
34
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
95-843: Service Oriented Architecture
Master of Information System
Management
35
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.
95-843: Service Oriented Architecture
Master of Information System
Management
From IBM Developer Works
36
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
95-843: Service Oriented Architecture
Master of Information System
Management
37
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
95-843: Service Oriented Architecture
Master of Information System
Management
38