270 likes | 450 Views
Verification and transformation of. BPEL processes. Agenda. BPEL Transformation QUT Ouyang c.s. HU Stahl c.s. VV Bisgaard Lassen c.s. Verification Soundness Operational guideline Conclusions. BPEL – Basic activities. invoke reply receive empty assign wait throw compensate
E N D
Verification and transformation of BPEL processes
Agenda • BPEL • Transformation • QUT Ouyang c.s. • HU Stahl c.s. • VV Bisgaard Lassen c.s. • Verification • Soundness • Operationalguideline • Conclusions
BPEL – Basicactivities • invoke • reply • receive • empty • assign • wait • throw • compensate • terminate
BPEL – Structuredactivities • sequence • switch • pick • while • flow • links • transition condition • join condition • dead path elimination
BPEL – Scopes • variables • event handlers • fault handlers • compensation handler
BPEL – Specification I • If, during the performance of structured activity S, the semantics of S dictate that activity X nested within S will not be performed as part of the behavior of S, then the status of all outgoing links from X is set to negative.
BPEL – Specification II • If during the execution of a business process instance, two or more receive activities for the same partner link, portType, operation and correlation set(s) are in fact simultaneously enabled, then the standard fault bpws:conflictingReceive MUST be thrown by a compliant implementation.
QUT – Basicactivity • Positive path • Negative path • Synchronous faults(not shown)
HU – Basicactivity (Receive) • Positive path • Communication place • Asynchronous faults
QUT – Links • Join condition • Negative path(not shown)
HU – Links • Outgoing links
QUT – Switch • Negative paths
HU – Switch • Outgoing links
Demo – ProM Transformation Verification Soundness State spaces Conflicting receives? • QUT • HU
VV • Patterns • Library • Extensions
Demo – ProM Transformation • VV
BPEL – Conclusions • Semantics? • Complexity • Event handlers • Fault handlers • Compensation handlers • Pragmatic approach • BPEL 2.0? • Tons of issues