Process Coordination in BPEL CounterProposal

1
Process Coordination in BPELCounterProposal

• Bob Haugen

2
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

3
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

4
Anatomy of a Subordinate Process
EH
Application Specific portType for Coordination
scope
ProcessPO
ConfirmAndShip
Pick
5
Alternative Pattern
6
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.

7
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 plug-compatible
• 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

8
Ok, so theres 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

9
Recommended hooks for coordination

• Final Cancel/Confirm
• Request completion
• Context
• Participant registration
• Create context

10
Do we really have to be dependent on a particular
coordination protocol ?

• bpel participant behaviour can only be
• give up before initial work completes
• confirm initial work beyond threat of negation
• negate initial work beyond threat of confirmation
• Some differences may be visible in the
  coordination side
• all-or-none, selection
• Most differences are at global level
• Q protocol does/does not need to reflect this
• thats a binding question, so not our problem
• Issue 2 coordination doesnt need a standard
  protocol anyway

11
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

12
Where do app-specific protocols break down?

• One coordinator, many participants
• Different protocol for each participant?
• Composition of prebuilt participants
• Same question
• Zero or minimal configuration B2B ecommerce
• Different protocol for each trading partner?
• Economic networks (e.g. supply chains)
• Different protocol for each node?

13
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