Abstract Processes in BPEL4WS

1
Abstract Processes in BPEL4WS

• Tony Andrews
• Software Architect
• Microsoft

2
Agenda

• Overview
• Scenarios
• Features Rationale
• Issues

3
Abstract Processes

• Description of public behavior
• If WSDL is vocabulary, BPEL is grammar
• Independent of implementation
• Just as WSDL doesnt require use of a particular
  language
• Permits data-dependent behavior
• Message types arent always enough
• Limited expressive power
• Facilitates use of well-known techniques for
  static analysis
• Impact of private aspects on public behavior can
  be contained
• via non-determinism (i.e. opaque assignment)

4
Executable vs. Abstract
Portability
Interoperability
Executable
Abstract
BPELa
BPELe
BPEL4WS Core Concepts
XPath
others...
WSDL
5
Scenarios for BPELa

• Code first (inside-out)
• Extract abstract behavior (BPELa) from
• existing process implementation (manual)
• BPELe (automatic or semi-automatic)
• Build partner behavior(s) by inspection of my
  behavior
• Difficult to automate, in general
• Protocol first (outside-in)
• Use BPELa as a tool for rapid design, prototyping
  and verification
• Build executable skeleton from abstract processes
  (BPELa ? BPELe )

6
Use cases

• Heres how I behave work with me!

7
Key questions we can ask

1. Are (two or more) abstract processes mutually
   compatible?
2. Does a process implementation conform to a
   specification of public behavior?

8
Compatibility

• System is guaranteed robust
• All parties terminate successfully under all
  conditions
• No un-processed messages
• No exceptions possible
• Exceptions in BPELe are more like assertion
  failures here
• No invalid request/response sequences

9
Conformance

• Does my implementation satisfy the abstract
  behavior I used as a template?
• Is my behavior the same as (or an acceptable
  subset of) the specification I started
  from?(Does my implementation refine my
  specification?)

10
How expressive is BPELa?

• Rich control flow with arithmetic operations on
  message data, but...
• Access to message data is limited
• Operations on data are restricted to...
• promote separation of concerns between process
  and implementation
• facilitate static analysis

11
Opaque assignment

• Captures the net outcome of some complex or
  private computation
• Abstraction of implementation details
• Two usage styles
• Constrained targets like a dice roll
• Select from a reasonably bounded set of
  alternatives
• Unconstrained targets like a UUID
• Useful for modeling the creation of correlation
  keys

12
Changes in 5/5 draft

• Simpler syntax
• No need to declare message variables when not
  otherwise required
• Makes simple processes clearer and more concise
• Opaque assignment expanded
• Unconstrained (but simple) types now supported
• Required by the simplified syntax (above)
• boolean permitted as target (mistakenly omitted
  in earlier versions)

13
(No Transcript)