03 Bpel2

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 1!
Management
Todays Topics
Basic BPEL constructs to Petri Nets
Generating and Handling Faults
Defining Scopes and Scope Rules
Correlation Sets
Compensation
Event Handling

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

Management
A Basic Activity
to_skipx
rx
X
sx
X
skip
cx
skippedx fx
Management
Structured Activities (normal behavior)
(a) sequence
rx
X
<sequence name=X> sx
activity A
activity B
</sequence> rA
A
fA
rB
B
fB

Master of Information System fx 5!
Management
(b) flow
<flow name=x>
activity A
activity B rx
</flow>
X
sx
rA rB
A B
fA fB
cx
95-843: Service Oriented Architecture fx

Management
(c) switch
<switch name=X> rx
<case>
<condition> X
Z1
</condition> sx ~Z1 Z2
activity A
Z1
</case>
<case>
rA rB
<condition>
Z2 A B
</condition>
activity B fA fB
</case>
</switch>
cx
95-843: Service Oriented Architecture fx

Management
(d) pick
rx
<pick name=X>
<onMessage e1> X
activity A
</onMessage>
sx
<onAlarm e2> e1 e2
activity B
<onAlarm> rA rB
</pick>
A B
fA fB
cx

Master of Information System
fx 8!
Management
(e) while
<while name=X
<condition>
z X
</condition>
~z sx
activity A z
</while>
rA
A
fA
cx

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

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>
Management
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>
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.

Management
(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>

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).

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>
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.
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>

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.

Management
<process> Scope Example(1)
<partnerLinks>...
<variables>...
<faultHandlers>...
<sequence>
<receive>
<scope>
<variables>
<faultHandlers>
<sequence>
<flow>
invoke 1
invoke 2
</flow>
</sequence>
</scope>
<scope>
:
</scope>
</sequence>
</process>
Management
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
scope.
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>
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.
Management
Define The Correlation
Properties are defined
<process> with the WSDL extensibility
mechanism and are
<partnerLinks> associated with an
<variables> Xpath query into a
message.
<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.

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>
:

Management
:
:
:
<invoke> Synchronously confirm with the
correlation
<correlations>
pattern=out-in/>
</correlations>
</invoke>
:
:
Management
:
:
:
<invoke> Make a callback on the client with the
correlation
<correlations>
pattern=out/>
</correlations>
</invoke>
:
:

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/add.
The drop is a compensating activity. It
undoes what we initially thought was a
good idea.

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.
Its 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.

Management
Compensation Handlers(1)
Compensation handlers may be
defined for the process, scope or
invoke activity. The process
compensation
<process> handler may only
be called after the
<partnerLinks> process has
<variables> completed
<faultHandlers> normally.
<compensationHandler> drop course activities
</compensationHandler> How it is invoked
<sequence> register for course is dependent on
the run-time
</sequence> environment.
</process>
Management
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>

Management
Compensation handlers may be defined for the
process, scope or invoke activity.
<invoke>
The syntax used to call
register for SOA the handler is
<compensationHandler> <compensate
name=xxx />
activities to drop SOA where xxx is the name
</compensationHandler> of the invoke activity
that needs to be
</invoke>
compensated.

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.

Management
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

Management
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
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.
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.

Management

03 Bpel2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

03 Bpel2

Enviado por

Direitos autorais:

Formatos disponíveis

Service Oriented

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture fx

95-843: Service Oriented Architecture fx

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

Normally, we would handle the return value

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

Você também pode gostar