Business Process Execution Language for Web Services Goals
Business Process Execution Language for Web Services Goals and Nuances Satish Thatté 12/19/2021 Draft 1
Outline n n n Design goals and assumptions Properties and Correlation Fault and Compensation handling Business protocol modeling Don’t boil the ocean 12/19/2021 Draft 2
BPEL 4 WS Design Goals n Provide a standard model for Web service orchestration q Integrate the two common control models n q Service orchestration for aggregation, adaptation and composition of discrete Web services n n q q Block structured and graph-like long running behavior, correlation and recovery consume and provide Web services with inbound operations q But provide for conversational relationships (partner. Links) Orchestration of cross-enterprise processes No support for full-blown data-handling n 12/19/2021 separation of concerns between orchestration and “real work” Draft 3
n Expect most practical usage in q q Design of business protocols (external behavior) Design of best practices and templates (executable models) n n Realistic process implementations will need platform-specific resources in the form of C#/Java components, etc. Common model for “public” and “private”behavior q The boundary between private and public can shift n q q Outsourcing, mergers, etc. Conformance relationships, export and import, is easier if the underlying set of core concepts is the same Focus has been and should continue to be on common core concepts n 12/19/2021 Minimal extensions for usage patterns (executable vs abstract) Draft 4
Outline n n n Design goals and assumptions Properties and Correlation Fault and Compensation handling Business protocol modeling Don’t boil the ocean 12/19/2021 Draft 5
Properties and Correlation n Think of properties as “abstract message tags” with a QName and a type: they permit protocol-relevant data to be embedded in messages q n In the latest version, properties are explicitly constrained to be of simple type, to allow for opaque assignment to all properties A multi-party conversation can be uniquely tagged by a set of properties, a “conversation key” q q q This is what BPEL calls a correlation set A property in BPEL does not have a value by itself, it has a value relative to a message or a correlation set Correlation sets are late-initialized constants (but may have scoped lifetime) 12/19/2021 Draft 6
Correlation for message sending n Conversations are always initiated by a process sending a message, thus for any complete business protocol specification q q The process instance with the initial send is in an initiator role The correlation set must be associated with the initiating send n q q In some “rendezvous” cases there may be multiple “conversation initiators” For non-initiating sends an associated correlation set is an assertion or constraint that can be verified dynamically A process instance that initiates participation in a conversation by receiving a message is in a follower role n 12/19/2021 There may be a single follower with multiple initiators Draft 7
Buy Side Broker Settlement Service Instance 12/19/2021 Securities Exchange Correlated By Order number Ticker Symbol Draft Sell Side Broker B E S 8
Outline n n n Design goals and assumptions Properties and Correlation Fault and Compensation handling Business protocol modeling Don’t boil the ocean 12/19/2021 Draft 9
Forward and Reverse Work Fault and compensation handlers n n n BPEL fault semantics is very standard q Faults may be suppressed or propagated The main twist is that BPEL supports compensation q Compensation is only possible for successfully completed scopes In BPEL a fault in a scope dooms the scope q The scope cannot complete successfully There is a huge temptation to say: let a fault handler perform an “alternative normal completion” by doing “forward work” q We all like to have a way to get things fixed We have not been able to make this actually work q Fault handlers are designed to perform “reverse work” by “undoing things” — e. g. , invoking compensation handlers q Forward work in fault handlers makes them schizophrenic q Which in turn makes compensation behavior unmanageable 12/19/2021 Draft 10
WS-TX Business Activity Protocol A Model for Nested Scopes in BPEL Figure 2: Business. Agreement Protocol State Diagram Exited Register Cancel Active Completed Faulted Canceling Completed Closed Closing Ended Compensate Compensating Faulted Forget Faulted Coordinator generated 12/19/2021 Participant generated Draft 11
Fault handlers for “Normal Completion” A few vexing questions n n n If a fault handler performs alternative normal completion, which of its work should be compensated during default compensation? q Some of the work will be damage control If there are multiple normal completion paths, how will a custom compensation handler be designed to deal with all of them? q It would have to figure out which successful path was actually taken and also which failed work was already compensated If there is a fault in a fault handler, how do we distinguish between a “rethrow” during reverse work and a real fault during forward work? In the latter case q Should another fault handler be invoked? But other fault handlers are uninstalled to avoid fault cycles q Should default handling compensate partial work? 12/19/2021 Draft 12
Outline n n n Design goals and assumptions Properties and Correlation Fault and Compensation handling Business protocol modeling Don’t boil the ocean 12/19/2021 Draft 13
Business Protocols: the Boilerplate n A cross-enterprise business protocol has q Two or more autonomous participants q Communicating via message-based operations n q n With no central coordinating authority Each participant has q Well-defined behavior n q n 12/19/2021 With full-duplex communication That may depend on the data content of messages exchanged Well-defined relationships with other participants Only the wire behavior can be specified q Relationships between participants are expressed in terms of agreed upon communication patterns q The concrete implementation of each participant is opaque q The behavior of participants is described in abstract terms Draft 14
A “party-neutral” protocol specification Port Buyer 12/19/2021 Port FSM Protocol Seller Draft FSM Protocol Shipper 15
A Protocol with Abstract Processes Port Buyer 12/19/2021 Port Partner. Link Port Seller Draft Partner. Link Shipper 16
Why use an abstract process approach for modeling external behavior? q Abstract process models work well with full-duplex protocols n n Business protocol partners are autonomous See Appendic C: Coordination protocol example q q q Abstract process models work well with data dependent behavior n n q q Full-duplex protocols tend to have inherent races Require explanation outside the formal model for full semantics Difference between “rush” and “normal” orders might be in the message content, not message type A PO with 7 line items requires 7 separate availability responses Abstract process models work well with import/export paradigm Abstract process models accommodate party-specific variation n n 12/19/2021 In real deployment parties often want to “tweak” their protocol behavior commitments Common experience with EDI and Rosetta. Net Draft 17
Races in the Business Activity Protocol The perils of party-neutral modeling Figure 2: Business. Agreement Protocol State Diagram Exited Register Cancel Active Completed Faulted Canceling Completed Closed Closing Ended Compensate Compensating Faulted Forget Faulted Coordinator generated 12/19/2021 Participant generated Draft 18
Outline n n n Design goals and assumptions Properties and Correlation Fault and Compensation handling Business protocol modeling Don’t boil the ocean 12/19/2021 Draft 19
TC focus: Core Concepts n Validate, complete, refine core concepts q q Business-focused use cases for validation There are many known issues and requirements yet to be addressed in the core Need precise operational semantics for the core (will surface issues) Minimal and essential extensions for abstract and executable processes n 12/19/2021 Charter emphasizes limitation to essential extensions to maintain focus and schedule Draft 20
Time is short, so we should focus n n If we want to finish we should not set out to “boil the ocean” BPEL is about providing the right set of abstractions for specification of process models at the abstract behavior level q q n Separable concerns should be addressed separately q q n Sufficient completeness: the bar for new features should be high Precise operational semantics: this will help triage complexity vs benefit Higher level “analyst friendly” and visual modeling Reliability, security, transactions, registry We should think hard about must-haves for composability q q How will we prepare for using XPATH 2. 0 and XQuery 1. 0? How will the WSDL 1. 2 MEPs affect us? How will we work with coordination protocols (e. g. , WS-TX)? How will we use session-based communication to minimize explicit correlation? 12/19/2021 Draft 21
- Slides: 21