Process Coordination in BPEL
CounterProposal
Bob Haugen
What is Process Coordination



Coordination is about enabling a collection of
autonomous entities to perform joint work using
predictable interaction patterns
Familiar example: Traditional ACID transactions
Process coordination differs from ACID transaction
coordination in many respects
 But the abstract protocols are very similar
What can be done in BPEL?


We cannot take a dependency on any context-based
coordination specification
 There is no commonly agreed dependence target
 But all current candidates are sufficiently similar to be
plug-compatible
Cross process coordination is a common design
pattern already for BPEL processes, using ordinary
Web service operations across partnerLinks


See next slides…
The coordination required for issue 2, and many
variants of 53-59 can in fact be very conveniently
accomplished with no new features using ordinary
Web service operations (see example next slide)

See also counter-example
Anatomy of a Subordinate Process
EH
Application Specific
portType for Coordination
ProcessPO
scope
Process the PO
CancelOrder
ReturnToInventory
ConfirmAndShip
Pick
Alternative Pattern
Buyer
Seller
<<Process>>
Economic Exchange
Buyer
<<Scope>>
Place
Order
<<Process>>
Economic Exchange
Seller
<<SubProcess>>
offer
<<SubProcess>>
Order
Transaction
Initiator
response
counter
offer
counter
response
Order
Transaction
Participant
<<Scope>>
Respond
to
Order
confirm
confirmed
cancel
canceled
Order
[accepted]
Order
[accepted]
<<Scope>>
Cancel
Order
<<SubProcess>>
<<Scope>>
Receive
Goods
<<SubProcess>>
Goods
[received]
Cancel Order
Transaction
Initiator
Delivery
Transaction
Participant
request
response
confirm
confirmed
<<SubProcess>>
Cancel Order
Transaction
Participant
<<SubProcess>>
notification
response
confirm
confirmed
Delivery
Transaction
Initiator
<<Scope>>
Respond
to
Cancellation
<<Scope>>
Deliver
Goods
Goods
[received]
Recommendation

BPEL has a notion of an instance-level
compensation handler



But BPEL has no mechanism for invocation of
this handler nor for its discharge
Moreover the handler has no parameters and
hence cannot share state with the coordinator
It is recommended that we remove the
instance level compensation handler since
we do not provide a way to make it useful

Agreed. But add Confirm and Cancel handlers.
What is lost by not adding any features?




Certain kinds of infrastructure support can make the realization of
some coordination patterns easier (e.g., participant/subordinate
initiated work)
To make this useful and interoperable, we would need to take a
dependency on some external specifications
 For BPEL purposes, all candidate external specs are plugcompatible
We neither have any such dependency available nor does our
charter include this type of work
 Re dependencies: since all candidates are plug-compatible,
BPEL can safely add minimal hooks.
 Re charter: BPEL usage scenarios consistently require
coordination.
We must therefore limit the scope of our work in this area to what
BPEL can do with existing features
Ok, so there’s two ways to do coordination
in bpel:



Code-your-own coordination logic in each bpel
process
Put in hooks to delegate the completion phase
of the coordination problem to business
transaction managers
Two phases:


Active phase: application messages
Completion phase: protocol messages
Recommended hooks for coordination:





Final Cancel/Confirm
Request completion
Context
Participant registration
Create context
Do we really have to be dependent on a
particular coordination protocol ?

bpel participant behaviour can only be




Some differences may be visible in the coordination
side


all-or-none, selection
Most differences are at global level



give up before initial work completes
confirm initial work beyond threat of negation
negate initial work beyond threat of confirmation
Q: protocol does/does not need to reflect this
that’s a binding question, so not our problem
Issue 2 coordination doesn’t need a standard protocol
anyway
On WS-Atomic Transaction

It is important to note that the atomic, two-phase
model is only with respect to the services involved.
Sites or infrastructure offering services may
advertise two-phase commit, but use some other
intra-enterprise model like compensation or
versioning. This freedom makes a simple two-phase
commit model more useful for long-running Internet
computations.

from “Secure, Reliable, Transacted Web Services” Ferguson, Storey, Lovering, Shewchuk
Where do app-specific protocols break
down?

One coordinator, many participants:


Composition of prebuilt participants:


Same question
Zero or minimal configuration B2B ecommerce:


Different protocol for each participant?
Different protocol for each trading partner?
Economic networks (e.g. supply chains):

Different protocol for each node?
What do you lose without a business
transaction manager?

Throw coordination work on application programmer


E.g. need to re-invent transaction state machines in BPEL
Process controlling multiple participants gets very
complicated

numerous clean-up paths



some have accepted, some in-flight when decide to reverse
recovery and state re-alignment
Something has to tie the message and state changes
together

reliable messaging manipulation inside a transaction