Abstract Processes Background First there was Abstract Processes
Abstract Processes
Background • First there was : – Abstract Processes in 1. 1: • • Made with the intention of observable behavior but requests for more flexibility for other use-cases. Two main attempts to make it more flexible: 1. Attempts to clarify abstract processes in spec version 1. 1 (original 82) 2. Flexible minimalistic definition with no semantics. A combined approach is presented here that cleanly bridges these polarized views
A Closer Look • From AP v 1. 1: Restricted Syntax, All validity constraints from core BPEL apply: Pros: Well-formed processes Clear intent Cons: Limits use cases due to limited opacity capabilities. Semantics not completely defined • Full Opacity Capalities, Only Schema validation: Pros: Anything can be opaque so processes for all use cases can be written. Cons: There are no semantics Burden on the designer and on recipient to understand semantics and intent empty reply ? empty receive
Bridging the Gap
Adding Expressivity Current (1. 1): Executable BPEL 1. 1 Abstract BPEL 1. 1 Proposed: Executable BPEL 2. 0 Abstract BPEL 2. 0
Common Ground: Opaque tokens Executable BPEL 2. 0 ? ? = Opaque tokens Common ground for incomplete processes If: activities, expressions and attributes then what happens to: Constraints? Semantics? If: leaf activities and expressions (incl. assignment) then clearer semantics, but limited usage
Spectrum Of Design Choices No Opacity Exec. BPEL Schema+its Constraints Syntax: level of opacity Validity/Constraints Replace only opaque: Activities w/ “empty”. Expressions w/ assignment+get. Var. Data Attributes w/ anything Opacity of Activities, Expressions, Attributes Exec. BPEL Schema. No Constraints Replace opaque w/ anything and add new BPEL elements anywhere Completions
How to Choose? • It depends on the use case you have in mind. • Proposal: – Usage Profiles that share a common space whose boundaries are defined by: • Executable BPEL w/ abstract process=yes: – full syntax, semantics; targeted usability. • “Base” Abstract BPEL (Full flexibility): – open syntax, semantics, usability. – A Profile is defined by choosing where it lies wrt opacity, validity, and possible completions. – Each abstract process refers to particular profile by a URI – AP 1. 1 w/ minor modifications becomes one profile in the specification for observable behavior.
Summary: Opacity of Activities, Expressions, Attributes Exec. BPEL Schema. No Constraints Replace opaque w/ anything and add new elements anywhere The Space of Abstract Processes and their Usage Profiles
- Slides: 9