Business Process Execution Language for Web Services BPEL4WS

1
Business Process Execution Language for Web
Services (BPEL4WS)
2
BPEL vs. WSDL

• WSDL supports a stateless model which describes
  operations supported by web servers
• One or two messages needed for client/server
  communication
• No mechanism for describing state between
  operations
• A business process (BP) typically characterized
  by long-running, statefull sequence of operations
  with one or more web services (business partners).

3
Simple Example Ordering Stationery

• cobegin
• invoke Staples.StationeryQuote(staples-quot
  e)
• invoke Office-Max.StationeryQuote
  Service(max-quote)
• coend
• if staples-quote
• invoke Staples.StationeryPurchase
• else
• invoke Office-Max.StationeryPurchase

state
4
New Issues

• Must be able to communicate with other Web
  Services
• Must be able to access and modify data received
  in messages
• Use XPath to extract information from messages
• Must have control constructs
• sequence, switch (if), flow (concurrency), while,
  link (synchronize concurrent processes), invoke,
  etc
• Must be able to handle faults

5
Example (BPEL)

• interfacestaplesPurchasePt
• operationrequestQuote
  inputVariablestationeryReq
• outputVariablestaplesStati
  oneryQuote
• interfaceofficeMQuotePT
• operationrequestQuote
  inputVariablestationeryReq
• outputvariableofficeMStati
  oneryQuote
• .. Continued
  on next slide ..

6
Example (BPEL)

• plesStationeryQuote, quote)
• bpwsgetVariableProperty(officeMStationeryQuote,
  quote) /
• interfacestaplesQuotePt
• operationpurchStation
  ery inputVariablestationeryPurch
• outputVariablestation
  eryResp
• interfaceofficeMQuotePT
• operationpurchStation
  ery inputVariablestationeryPurch
• outputVariablestation
  eryResp

7
Business Process (BP)

• A BP consists of both internal computations and
  invocations of operations exported by web service
  partners
• The operations it exports constitute its
  interface to its partners
• The sequence of invocations it executes is
  referred to as a protocol and
• is data dependent
• responds to exceptional conditions

8
Abstract Vs. Executable BPs

• Executable BP complete description of BP
  (including all computations)
• Abstract BP contains only externally visible
  (communication related) behavior of BP
• Not executable
• Internal decision making algorithm and data
  manipulation not described
• Languages for describing abstract and executable
  BPs share a common core, but differ primarily in
  data handling capabilities
• BPEL4WS is used to specify both abstract and
  executable BPs

9
Executable BPs

• BPEL is sufficient for describing a complete
  (executable) BP that
• Relies on web services and XML data
• Is portable (platform independent)
• Executable BP is a complete specification of the
  Web Service
• Actual implementation, however, might not use
  BPEL,
• Abstract BP specifies external interface and can
  be exported for use by business partners

10
Abstract BP

• Unfolding of protocol related portion of BP
• depends on properties - a subset of the data
  contained in messages
• Ex. Message invoking getQuoteRequest might have
  parts instrumentType (with value stock or bond)
  and symbol (which identifies a particular
  instrument of that type)
• instrumentType will be a property if it affects
  the course of the protocol
• symbol will not if it does not affect the course
  of the protocol
• Only properties are visible to abstract BP

11
Abstract Vs Executable BP

• Internal computation of executable BP not
  included in abstract BP
• If assignment is to a variable that is not a
  property, it is eliminated from abstract process
• Ex. Address data might not affect the protocol
• If assignment is to a variable that is a
  property, it (generally) affects the protocol
• Ex. Value of bidPrice might affect protocol
• if (bidPrice1000) invoke webService1 else invoke
  webService2
• bidPrice will be a property, but its value is
  computed by an internal algorithm
• The computation that produces the new value is
  generally not relevant to the protocol

12
Abstract BP Non-determinism

• Description of abstract BP allows assignment of
  non-deterministic values to properties to model
  this
• Abstract and executable BPs differ in data
  handling ability
• Executable can explicitly manipulate all data
• Abstract can access only properties in limited
  ways and can assign non-deterministic values to
  them
• Executable cannot assign non-deterministic values
  to anything

13
Abstract BP Non-determinism
computation that assigns a value to part x
non-deterministic assignment to property
x? (alias of x)
switch(x)
switch(x? )
Abstract BP
Executable BP
14
Communication Client Side

• Invoking an operation of an interface (specified
  in WSDL) exported by server
• Client assigns message to operations input
  variable
• Client executes invoke on operation
• Asynchronous (in-only WSDL pattern)
• Client resumes execution immediately
• Synchronous (in-out WSDL pattern)
• Client waits for response and then resumes
  execution
• Client can access response message in operations
  output variable

15
Communication Client Side

• Receiving an operation (e.g., an asynchronous
  response to a prior invocation) on a (callback)
  operation exported by client
• Client executes receive on operation
• Client waits for message
• Client can access message in variable associated
  with operation and resume execution

16
Communication Client Side
client
server invoke invoke invoke receive

client waits
(synchronous invoke)
server exports interface

(asynchronous invoke)
client continues

problem how do you associate request
with response?


client exports (callback) operation
17
Communication Server Side

• Accepting an operation invocation on an
  (exported) interface (specified in WSDL)
• Server executes receive on operation and waits
• Responding to a synchronous operation invocation
• Server executes reply on operation (rpc)
• Invoking a clients exported (callback) operation
• Server executes invoke on operation

18
Communication Server Side
client
server invoke
receive

(synchronous invoke)
reply
receive
server exports interface
invoke
(asynchronous invoke)

receive
invoke



receive
invoke
client exports (callback) interface
19
Example Purchase Order (PO) Service
receive purchase order
concurrency
sequencing
initiate price calculation
decide on shipper
initiate production scheduling
complete price calculation
arrange logistics
complete production scheduling
synchronization
invoice processing, reply
20
PO Service
PO Service
receive
synchronous invocation
POMsg
Body of PO Service
customer
operation sendPurchOr on interface purchOrIf
InvMsg
reply
21
PO Service Interface (WSDL)
xmlnshttp//schemas.smlsoap.org/wsdl/
typesnscustInfo/ typesnspurchOr/ nameInvMsg typesnsInvoice/ .. namepurchOrIf namesendPurchOr messageposPOMsg/ -- arguments supplied
-- response
..
interface exported by PO Service
prefix for target namespace in this document

22
Variables (BPEL)

• Variables maintain the state of a BP
• Used to store messages that have been sent or
  received or for local storage (no message
  involved)
• Has an associated type
• Can be a message type
• Can be an XML simple type
• Can be an XML schema element (which might have a
  complex type)
• Has an associated scope

lns is prefix in BPEL document for the WSDL
document
23
Partner Link Type (WSDL)
describes the way two BPs
interact - names an interface that must
be declared in each - associates
with each end of the interaction
Not a process (allows actual partner to be
specified dynamically)
Identifies a BPEL schema




Unit of collaboration
Only one role since only POService needs to
provide an interface
24
Partner Link Type (WSDL)



f/
description of a possible relationship between
two BPs
BP playing role of invoice requester
BP playing role of invoice service
invoiceCallbackIf
computePriceIf
25
Partner Link (BPEL)
Connection to another BP described by a
partner link construct in BPEL
names a process and associates it with a
role in that link.
partner specification in PO service

name of partnerLink
prefix lns refers to WSDL document
partnerLinkTypelnspurchLT
myRolepurchService/
hence PO service must provide purchOrIf
26
Partner (BPEL)

• A BP might interact with another BP called a
  partner - through several partnerLinks
• Need a mechanism that asserts that the same BP is
  at the other end of a set of partnerLinks
• Ex BPs might support getFareIf and
  purchaseTicketIf an acceptable partner is one
  that supports both

27
Process Name

• Each BP is assigned a name in the tag

namespace declarations query
language (default XPath)
expression language (default XPath)
declarations and process body ss namepurchOrProcess
similarly declarations and body of
PO service
28
Linkage Customerto PO Service
plnk prefix in WSDL doc refers to
WSDL extension pos target ns of WSDL doc lns
prefix in PO Service refers to WSDL
doc cns prefix in customer refers to
WSDL doc



namelinkToPurch
partnerLinkTypecnspurchLT
partnerRolepurchService/ namepurchLink partnerLinkTypeln
spurchLT myRolepurchService/
WSDL inter- face exported by PO Service
partner specification in customer process
partner specification in PO Service
29
Partners
In general - A partnerLinktype is not
specific to a particular BP it is a
global, bilateral (WSDL) description of the
interaction between two BPs. - A
partnerLink declaration (BPEL) describes how the
local BP interacts with other BPs
through a
partnerLinktype.

er partnerLinkTypelnsinvoice
LT myRoleinvoiceRequester
partnerRoleinvoiceServices/ partnerLinks
30
PO Service (BPEL)
messageTypelnsPOMsg/ nameInvoice messageTypelnsInvMsg/ les nk interfacelnspurchOrIf
operationsendPurchOr variablePO/
. concurrent body.
interfacelnspurchOrIf
operationsendPurchOr variableInvoice/ quence
Both necessary since PO Service might
communicate with several BPs
through the same interface
31
Interaction with Shipping Provider
operation requestShipping on interface shippingIf
decide on shipper (invoke)
shipReqMsg
shippingProvider
shipInfoMsg
scheduleMsg
arrange logisitics (receive)
role shippingService
operation sendSchedule on port shippingCallbackIf
role shippingRequester
32
Handling Shipping (WSDL)

message/ face nameshippingIf namerequestShipping message/

interface exported by PO Service
interface imported from shipping service
33
Handling Shipping



kIf/ rtnerLink nameshippingProvider
partnerLinkTypelnsshippingLT
myRoleshippingRequester
partnerRoleshippingService/
WSDL
BPEL
34
Handling Shipping (BPEL)
contains input message


partcustInfo /
ider interfacelnsshippingIf
operationrequestShipping
inputVariableshippingReq
outputVariableshippingInfo
partnerLinkshippingProvider
interfacelnsshippingCallbackPT
operationsendSchedule variableshippingSc
hedule/
35
Links (BPEL) Synchronizing Concurrent Activities
w/I a BP

• Production scheduling cannot be completed until
  logistics have been arranged

Concurrent sequence activities in flow
data produced by arrange logistics is needed
by complete production scheduling data
communicated through globally shared variable
decide on shipper
initiate production scheduling
arrange logistics
complete production scheduling
link
source
target
36
Links



. partnerLink .
variableshippingSched linkNameship-sched/
partnerLink. partnerLink. inputVariableshippi
ngSched / .
decide on shipper
shipping
arrange logistics
complete production scheduling
scheduling
37
Properties (WSDL)

• Some message data is protocol-relevant.
• Used in conditional behavior of BP
• Used to relate messages sent to a particular
  instance of a BP
• A property declares a global name that can be
  assigned to data items that may be parts of
  several different message types and carry the
  same meaning
• taxpayerID might be a part of one message type in
  one namespace (e.g., Internal Revenue), ssn might
  be a part of another in a different namespace
  (e.g., Social Sec. Admin)
• Both might represent the same information of type
  txtypSSN

typetxtypSSN/
38
Property Alias (WSDL)

• Used to associate a property name with a field in
  message part
• A particular property can be associated with
  different fields in different messages

typetxtypSSN/
propertyNamecustomerID
messageTypetxmsgtaxpayerInfo
parttaxpayerID

query/socialSecNum /
query string specified in XPath - to locate the
field in the part
39
Correlation Sets (BPEL)

• A web service might be configured with multiple
  instances of a BP to concurrently handle
  (stateful) conversations with multiple clients.
• All receive requests over the same port
• With SOAP over HTTP, messages arrive on port 80
• A mechanism is needed to
• Route an arriving message that is part of a
  particular conversation to the correct BP
  instance
• Messages of a particular conversation can be
  recognized by the fact that they will generally
  all carry some identifying value(s) (e.g.,
  customerID and orderNum)

40
Correlation Sets

• A correlation set is a set of properties whose
  value is shared by all messages in a particular
  conversation.
• Hence, an address is really
  (host address, port, correlation
  set)
• A correlation set identifies the BP instance

propertiescorcustomerID
cororderNum/
aliased to items of information contained in
the messages of a conversation
41
Using Correlation Sets

• A particular receive operation can be used in a
  BP to accept the start of a new conversation
• All subsequently arriving messages with same
  value of PurchaseOrder will be directed to this BP

asynchronous purchase requst
interfaceSPPurchasingIf
operationasynchPurchase
variablePO
initiateyes/
create a new correlation set value for BP
instance
42
Using Correlation Sets

• Response returns the correlation set value
• Asynchronous (callback) response to previous
  invocation
• A reply to a synchronous invocation would be
  similar

interfaceSPBuyerIf
operationasynchPurchaseResp
variablePO

initiateno/
use the set to address the message
43
Multiple Correlation Sets
messages of a single conversation
buyer

server invoke(corrSetPO inityes)
receive(corrSetPO inityes) receive(c
orrSetPO initno
invoke(corrSetPO initno
corrSetinv inityes)
corrSetinv inityes)
subsequent messages sent and received
use
correlation set inv
messsage contains both correlation sets
44
Multiple Correlation Sets

• With synchronous invocation two messages are
  involved the pattern attribute associates a
  correlation set with a message.

invoke (partnerLinkBuyer interfaceSPBuyerIf
operationsynchPurchaseResp
inputVariablePO
outputVariableinvoice
initiateyes
patternout/ (initiated in outbound msg)
initiateyes
patternin/ (initiated in inbound msg,

which contains both sets)

45
Data Manipulation

• Data (state) stored in variables (used for
  messages and local storage)
• Expressions use expression language (XPath
  default) to access data in variables
• Executable processes can use
• All processes can use
• Returns the part (or, if the locationPath is
  specified the field within the part) in the named
  variable.
• If a single node is not specified, a fault is
  returned.

bpwsgetVariableData (variableName, partName,
locationPath?)
query string
bpwsgetVariableProperty(variableName,
propertyName)
property alias contains query string
46
Assignment

• Allows copying of data
• One form (for executable processes)
• query is an absolute expression (if XPath is the
  query language) that identifies a single node w/i
  the document fragment specified by part
• from child can also contain a literal value or a
  simple arithmetic expression (for data
  transformation)

partp1 queryq1/
partp2 queryq2/
47
Assignment in Abstract Process

• A non-deterministic value from a propertys
  domain can be assigned to the property by an
  abstract process using opaque assignment
• Allows simulation of execution traces

48
Invoking Web Service Operations

• invoke might have child elements related to
  faults and compensation (discussed
  subsequently), and links and correlation
  (discussed previously)
• invoke specifies a partnerLink since an interface
  can be associated with several partnerLinkTypes
  connected to different BPs

interfacelnsshippingIf
operationrequestShipping
inputVariableshippingRequest
ouputVariableshippingInfo
49
Invoking Web Service Operations

• invoke can be
• Synchronous
• input and output variables specified
• waits for a response
• Asynchronous
• no output variable specified
• no waiting

interfacelnscomputePriceIf
operationinitiatePriceCalc
inputVariablePO
50
Synchronous Vs. Asynchronous Invocation

• Web service communication characterized by
• Services are not always available.
• Loads tend to be unpredictable.
• Attempts to handle too many requests in real time
  can lead to thrashing and failure.
• Many requests cant be handled instantly even
  with low loads.
• Asynchronous invocation will play an increasingly
  important role.

51
Providing Web Service Operations

• receive waits for an invocation to arrive
• specifies a partnerLink since an interface can be
  associated with several partnerLinkTypes
  connected to different BPs

interfacelnspurchOrIf
operationsendPurchOr variablePOmsg/

52
Providing Web Service Operations

• Initiating a new instance of a BP
• createInstanceyes a new instance of the BP
  is created and this is its initial activity.
• The receive should be the first activity in the
  BP (since prior activities will not be executed
  within the new instance)
• If the message is the start of a conversation
  then a correlation child element should be
  specified

interfacelnspurchOrIf
operationsendPurchOr variablePOmsg
createInstanceyes/
initiationyes/
53
Providing Web Service Operations

• reply is used to respond to a synchronous
  invocation.
• connection between receive and reply based on
  constraint that not more than one synchronous
  request from a particular (partnerLink,
  interface, operation) can be outstanding at a
  time
• Response to an asynchronous invocation is made
  using an invoke on a callback operation
• partnerLink between requestor and requestee must
  have two roles

OrIf operationsendPurchOr
variableInvoice/
54
Other Basic Activities

• or

55
Structured Activities

Involves only properties if process is abstract
at least one case element conditions evaluated
in order
if present, executed if all conditions fail, else
an empty otherwise is assumed
56
Structured Activities

• -- waits for the
  occurrence of first event
• interface..
• operation..
  variable..
• untildeadlineExp

at least one, acts like receive
zero or more
57
Structured Activities

• concurrently executes nested (child)
  activities
• Terminates when all children terminate

partnerLink / /

58
WSDL Review

• WHAT interface describes abstract functionality
  (operations, messages)
• HOW binding describes how elements of an
  interface (operations, messages) are mapped to a
  particular transport protocol (e.g., SOAP over
  HTTP, data encoding)
• WHERE endpoint maps a binding to an address
  (particular server at a URL)
• service is a collection of related endpoints

59
Endpoint References

• A BP is statically dependent on the interfaces
  with which it communicates
• However, the endpoints associated with those
  interfaces (and hence the identity of the BP
  instances with which it communicates) can change
  dynamically
• Endpoints can be sent in messages
• A BP can dynamically select a provider
• Example client can send a callback interface to
  which server can send response

60
Endpoint References

• A message part of EndpointReferenceType can hold
  addressing information
• Every role in a partnerLink has an associated
  EndpointReference (of that type) that identifies
  an endpoint (address) and an associated process
  instance
• An EndpointReference element is an alternative to
  a service element

61
WS-Addressing Specification for Endpoint Reference
a URI
-- required ties properties (child elements)
are inserted here . es

ce
wsa identifies WSDL extension namespace for
endpoint references Information to identify a
particular instance of a BP can also be
supplied
62
Endpoint Reference

• Properties mapped literally to SOAP headers
• MessageId
• Action action to be taken by destination
• ReplyTo
• Interface identifies the associated interface
• ServiceName identifies the associated service

63
Endpoint Reference Example
. nameserviceReference typewsaEndpointRefer
enceType/ namebuyerIf

namebuyerCallbackIf . namebuyerStoreLT




64
Endpoint Reference Example
partnerLinkTypeasbuyerStoreLT
myRolestore partnerRolebuyer/ namebuyerData messageTypeasbuyerData/
partnerLinkbuyer
interfaceasbuyerIf operationsubmit
variablebuyerData/ ..
partendpointReference/ partnerLinkbuyer/
partnerLinkbuyer
interfaceasbuyerCallbackIf
operationanswer
inputVariable /
65
Assignment and Endpoint References

• Sending an address from child can have the form
• A BP might want to send its own address (e.g.,
  for a callback) or its partners address
• Receiving an address to child must be associated
  with partnerRole (cant change your own address)

endpointReferencemyRolepartnerRole /

66
Links Synchronizing Flow Activities


linkNameXtoY/
linkNameXtoY/

nameD

• any activity can have a source
• or target child element
• every link must have exactly
• one activity w/i the flow as
• its source and one as its target
• sequence Y cant start until
• sequence X completes
• source and target need not be
• nested at same level (CtoD)
• link must not cross a while
• boundary
• - links must not create a loop

67
Link Semantics at the Source

• Each source child of an activity has an
  implicit or explicit transitionCondition whose
  value is
• - Implicit true when activity terminates
• - Explicit the value of the
  transitionCondition when the activity terminates
• transitionConditiongetVariablePrope
  rty(eval, risk) low /
• - The transitionCondition determines the
  link status (positive or negative) when the
  activity terminates

variable name
property name
68
Link Semantics at the Target

• Without considering links, an activity is
  ready to execute in accordance with normal
  flow-of-control rules (sequence, switch, etc.)
• In addition, an activity might be the target
  of several links.
• - Every such activity has a joinCondition
  which can be
• evaluated when the status of all
  incoming links has been
• determined. Execution starts when the
  activity is ready and its
• joinCondition is true.
• Default joinCondition status of at least one
  incoming link is true

linkNameAtoX/
.
69
Link Semantics at the Target

• joinCondition can be explicitly provided as
  an attribute using getLinkStatus() function.

nkStatus(AtoX) AND bpwsgetLinkStatus(BtoX)
linkNameBtoX/ .
must specify an incoming link for activity X
70
Link Semantics at the Target

• If the joinCondition evaluates to false a
  joinFailure fault is thrown, else the activity is
  started
• If an activity, X, will not be executed (e.g. a
  case in a switch, an activity that does not
  complete due to a fault) then the status of all
  outgoing links from X is set to negative.

71
Link Semantics


nce
conditionC1
nameA
linkNameAtoC/
. conditionC2
.
.

• only one case is executed
• joinCondition at C cannot
• be evaluated until status of
• both links are determined
• if C1 is chosen for execution
• the status of BtoC is set to
• negative (if that were not
• done C would never start)
• default joinCondition at C is
• true when either C1 or C2
• completes - since their (default)
• transitionCondition is true

72
Link Semantics

• Problem in some cases a false joinCondition is
  not a fault it is an indication that the
  activity should not be performed in at a
  particular point in the execution
• In that case the status of all outgoing links
  should be set to false so that the joinCondition
  of other activities can be evaluated
• Solution use activity attribute
  suppressJoinFailure

73
Link Semantics

• If value of the suppressJoinFailure attribute of
  an activity, A, is yes, then if the joinCondition
  of A or any nested activity has value false when
  it is ready to execute
• status of all of its outgoing links is set to
  negative
• it is skipped and execution continues (as if it
  had terminated without raising a fault)
• referred to as dead-path-elimination

74
Link Semantics
suppressJoinFailureyes


conditionC1
nameA

.
nameB .
.

• C is executed if C1 is chosen
• if C1 is not chosen
• the status of AtoC is set to
• negative and a joinFailure
• would occur
• suppressing joinFailure allows
• C to be silently skipped

75
Scope

• Nested scoping is provided through the scope
  activity in the conventional way.
• Variables, fault and compensation handlers, and
  correlation sets can be declared.
• Properties are global since they are mapped to
  data in messages.

76
Faults

• Fault has a unique name and an (optional) fault
  variable describing the event
• Sources of faults
• Explicit raising of a fault
• faultVariabledescr/
• Standard BPEL faults
• bpwsjoinFailure - joinCondition has
  value false
• bpwsconflictingReceive two receives for
  same partnerLink, interface and
  operation pending within a flow at
  the same time

77
Faults

• Source of faults (cont)
• Fault response to an invoke. The reply
• raises the fault unableToHandleRequest in
  customer
• that has synchronously invoked request on
  interface

ServiceIf operationrequest
variableerror faultNameunableToHan
dleRequest/
namerequest
patternhttp//www.w3.org/2003/06/wsdl/in-out



messageerrorMsg/
78
Faults

• The reply raises the unableToHandleRequest
  fault in customer which is handled by

leRequest faultVariableerror
. handle the fault .

Re-throw the same fault and/or clean-up and/or
invoke a compensation handler
79
Handlers

• Handler is associated with an implicit or
  explicit scope catches faults that occur in that
  scope

faultNameunable faultVariableerror
. handle the fault
other handlers
activities c interfacelnsloanserviceIf
operationrequest
activities
interfacelnsloanserviceIf
operationrequest ..
faultVariableerror . handle the
fault.
or
80
Fault Flow of Control

• When a fault f occurs in some scope, B
• Execution of activities within are terminated
• If a fault handler for f or a catchAll handler
  has been declared local to B, it is executed and
  execution resumes in the next enclosing scope at
  the activity following B
• Else f is thrown in the next enclosing scope
• In both cases B is said to have exited abnormally
• The handler might reverse changes it has made to
  variables global to B and invoke compensation
  handlers for scopes nested in B that have
  completed normally.

81
Fault Flow of Control
A
B
catch f throw g or exit
abnormal exit
throw f
82
Atomicity

• A BP is a long running process involving
  invocations of operations at a number of web
  services.
• It is unrealistic to treat a BP as a single
  transaction, since a particular service will not
  hold locks for the duration of the BP
• Instead, a single operation at a service might be
  treated as a transaction that commits when it
  sends reply
• BPEL does not support global atomicity (e.g.,
  two-phase commit) over multiple invocations by a
  BP

83
Long-Running Business Transactions (LRT)

• Reversing the effect of a BP relies on
  compensation
• a web service might offer a compensating
  operation for a synchronous operation
• Ex. CancelPurchase compensates for Purchase
• BPEL supports an LRT by providing compensation
  handlers
• Allows application to specify a recovery strategy
  using compensating operations
• No guarantee of atomicity or isolation
• Future work in this direction is being carried
  out in the context of the WS-Transaction
  specification

84
Compensation Handler

• Handler can be in the immediate scope of invoke
  or declared local to scope
• Undoes the effect of the scoped activities

interfaceSPPurch
operationsyncPurch inputVariablesendPO
outputVariablegetResponse

initiateyes patternout/
--
patternout indicates set applies to request
msg
partnerLinkseller interfaceSPPurch
operationcancelPurch
inputVariablegetResponse outputVariablegetCo
nfirm



-- invSeller is name of scope
85
Invoking Compensation

• Compensation can only be performed for scope
  (e.g., invoke, scope) that has completed
  normally
• A compensation handler is not installed until
  the associated scope has completed normally.
• Hence handler must be invoked from outside the
  scope
• Compensation occurs when a failure is detected
• Hence handler is invoked from a global fault or
  compensation handler

86
Invoking Compensation

• At most one compensation handler can be
  explicitly declared local to a scope (in contrast
  to fault handlers)
• Scope has a name handler is invoked using
• Handler is installed when scope is exited
  normally (at that point compensation is
  meaningful)

87
Handler Invocation
fault handler for f
A
catch f compensate B
B
compensation handler for B
compensate C compensate D
C
compensation handler for C
compensation handler for D
D
Although B, C and D may have exited normally, A
will exit abnormally in this case
throw f
88
Compensation
faultNameunable faultVariableerror

nameinvBank partnerLinkmyBank
interfacebankIf operationOp .

operationcancelOP
..

interfacelnsloanserviceIf
operationrequest ..

fault
compensate
normal exit
abnormal exit
89
Default Handlers
A

• Problem Suppose a fault handler is not declared
• Compensation handler for C cannot be called from
  within A
• Solution default fault handlers automatically
  invoke declared compensation handlers of
  immediately enclosed scopes and then rethrow the
  fault

B
default handler for f
C
compensation handler for C
throw f
90
Default Handlers
catch f compensate B
fault handler for f
A

• Problem Suppose a compensation handler
  is not declared
• Compensation handler for C cannot be called from
  within A
• Solution default compensation handler
  automatically invokes declared compensation
  handlers of immediately enclosed scopes

B
default compensation handler
C
compensation handler for C
throw f
91
Structure of a BP
/



activity