1. Abstract Processes in BPEL4WS Tony Andrews Software Architect Microsoft

2. Agenda Overview Overview Scenarios Scenarios Rationale Rationale Issues Issues

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

4. Executable vs. Abstract WSDL SOAP others... BPEL4WS Core Concepts Executable Abstract Portability Interoperability BPEL e BPEL a

5. Scenarios Implementation first (inside-out) Implementation first (inside-out)  Extract abstract behavior (BPEL a ) from:  existing process implementation (manual)  BPEL e (automatic or semi-automatic)  Build partner behavior(s) by inspection of “my” behavior  Difficult to automate, in general Protocol first (outside-in) Protocol first (outside-in)  Use BPEL a as an environment for rapid design, prototyping and verification  Build executable skeleton from abstract processes (BPEL a  BPEL e )

6. Use cases “Here’s how I behave – work with me!” “Here’s how I behave – work with me!” BigCo BPEL a “Here’s how I behave – you should behave like this” “Here’s how I behave – you should behave like this” BigCo BPEL a “It would be great if we all worked together like this” “It would be great if we all worked together like this” BPEL a IndustryCommittee

7. Key questions we can ask 1. Are the members of a set of abstract processes mutually compatible? 2. Does a process implementation conform to a specification of public behavior? 3. Do two abstract processes (e.g. different versions of the same process) exhibit the “same” public behavior?

8. Compatibility System is guaranteed “stuck-free” System is guaranteed “stuck-free”  All processes terminate normally under all conditions  No un-processed messages No BPEL exceptions possible No BPEL exceptions possible  Exceptions in BPEL e are more like assertion failures here No invalid request/response sequences No invalid request/response sequences More? (see issues later) More? (see issues later)

9. Conformance SmallCo asks – “does my implementation satisfy the abstract behavior I used as a template?” SmallCo asks – “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?) BigCo asks – “my implementation changed – will my partners notice?” BigCo asks – “my implementation changed – will my partners notice?”  Is my new public behavior identical to my old behavior as far as anyone can tell? (Are my new & old behaviors bisimilar?)

10. Refinement vs. Bisimulation Not sure how much theory I want to get into here, but we may need to touch on this Not sure how much theory I want to get into here, but we may need to touch on this

11. Rationale Need to speak to the following: Need to speak to the following:  Expressive power of BPEL  Yes, it’s Turing-complete – but useful systems will still be finite  The need to reference message data  Motivate this with a couple of examples  Opaque assignment  Talk about the importance of coping with non- determinism – it allows us to talk about how the “real world” influences us. It also allows us to hide private aspects of a process cleanly.  The need to be specific about timeouts, for example, in describing behavior This will probably expand to 3 or 4 slides This will probably expand to 3 or 4 slides

12. Recent changes Simpler syntax Simpler syntax  No need to declare message variables when not otherwise required  Makes simple processes clearer and more concise  (Is it politically appropriate to give SAP credit for this suggestion?) Opaque assignment expanded Opaque assignment expanded  Unconstrained (but simple) types now supported (think UUID)  Required by the simplified syntax (above)

13. Static Analysis What can/should we say here? Parts of the spec only make sense if you know that we had model-checking in mind as a key tool for static analysis. What can/should we say here? Parts of the spec only make sense if you know that we had model-checking in mind as a key tool for static analysis. I’d like to say that we believe BPEL to be highly amenable to analysis by model-checkers, and that we intended for the extraction of models from BPEL to be a relatively straightforward process. I’d like to say that we believe BPEL to be highly amenable to analysis by model-checkers, and that we intended for the extraction of models from BPEL to be a relatively straightforward process.

14. Issues (1) Precise statement of operational semantics needed Precise statement of operational semantics needed  Perhaps a reference implementation in some suitably abstract and neutral form (ML? Haskell?) Lack of a “global model” Lack of a “global model”  No way to speak of wiring between services  No mechanism to describe the “external” instantiation of a process

15. Issues (2) Better support for specifying “safety” properties Better support for specifying “safety” properties  currently prohibited in BPEL a  Something like an assertion would be even better Design patterns for “sound” compensation Design patterns for “sound” compensation  Need to explore and understand how to build robust compensations for the library of BPEL use cases we create

16. Issues (3) Inability to refer to properties appearing outside the message body Inability to refer to properties appearing outside the message body  No access to SOAP header contents Lame type system in XPath Lame type system in XPath  Restrictions on expressions would be more easily described with XQuery A well-specified model for annotations would be useful A well-specified model for annotations would be useful  Provide useful context to humans for conditional expressions & opaque assignments

17. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.