Business Process Execution Language for Web Services BPEL4WS - PowerPoint PPT Presentation

About This Presentation
Title:

Business Process Execution Language for Web Services BPEL4WS

Description:

1. Business Process Execution Language for ... invoke Staples.StationeryQuote(staples-quote) ... invoke partnerLink='Staples' interface='staplesPurchasePt' ... – PowerPoint PPT presentation

Number of Views:258
Avg rating:3.0/5.0
Slides: 92
Provided by: arthurbe
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com