Conference presentation given by Niels Lohmann on September 2, 2008 in Milan, Italy at the Sixth International Conference on Business Process Management (BPM 2008).

1. Extending the Compatibility Notion for Abstract WS-BPEL Processes Dieter KönigSimon Moser Niels LohmannKarsten Wolf Christian Stahl IBM Böblingen LaboratoryGermany University of RostockGermany Humboldt-Universität zu BerlinGermany UNIVERSITÄT ROSTOCK

2. WS-BPEL 2 Web Service Business Process Execution Language specifies a business process by orchestratingWeb services implemented as Web service itself process can be an executable Web services abstract processes ("business protocols")

3. Executable WS-BPEL Process 3 <receive> credit request from customer else salary <= 5000 $ tradesecrets <if> <assign>customer name to blacklist <assign>customer name to database technicaldetails <reply>credit rejection to customer <assign>customer id to credit case <reply>credit approval to customer

4. Executable ➙ Abstract WS-BPEL Process 4 <receive> credit request from customer else salary <= 5000 $ opaque condition tradesecrets <if> <assign>customer name to blacklist <assign>customer name to database <opaqueActivity> <opaqueActivity> technicaldetails <reply>credit rejection to customer <assign>customer id to credit case <reply>credit approval to customer

5. Applications 5 bottom up top-down exchange/documentationformat, template abstract process abstract process abstraction refinement executable process executable process

7. means to check/achieve compatibility:

8. computer-aided verification

9. abstract profilesspecification abstract process ? compatible executable process implementation

10. Compatibility: Computer-aided Verification 7 specification formal model abstract process ✓ compatible ? verification tool compatible ✗ not compatible formal model executable process implementation

11. Compatibility: Abstract Profiles 8 abstract profile defines transformation rules specification implementation intermediate process executable process abstract process intermediate process intermediate process ✓ compatible by design

12. Compatibility: Summary 9 Computer-aided Verification expensive technique (time + memory) only applicable if both specification and implementation are available Abstract Profiles simple syntactic rules applicable during design time(only one process required) some defined in the WS-BPEL specification

13. Abstract Profile for Observable Behavior 10 intention: maintain observable behavior of abstract process implementation must not change this defined syntactically: allowed: replacement of opaque activities, add fault handlers to the process, add non-communicating activities, … disallowed: change/relax execution order, add branches to if or pick activities, deletion of existing activities, …

14. Abstract Profile for Observable Behavior (2) 11 problems: profile is too strict (and even incorrect!) executable process's structure too much depends on abstract process's structure many correct completions are disallowed this paper's contribution: define a novel profile rules base on formal methods anti-rules define forbidden transformations

15. Non-Communicating Activities 12 Rule:Non-communicating activities may be reordered, looped, removed, or embedded into a flow. <opaqueActivity> <assign> <assign> <opaqueActivity> <assign> <opaqueActivity> <assign>

16. Disclaimer: Data and Control Flow 13 Data writing may cause changes in interaction order. Changes caused by data writing are not enforced by the completion rules, but are highlighted here as an advisory note. One example is changing the value of a variable used in a condition that affects branching, in such a way that the new effective branching behavior is in direct conflict with what is specified by the abstract process. WS-BPEL specification

17. Communicating Activities 14 Rule: A sequence of first invoke and then receive can be transformed into a flow. <invoke "a"/> <receive "b"/> ✓ for asynchronousbinding for asynchronousand synchronous binding <receive "b"/> <invoke "a"/>

18. Communicating Activities 15 Rule: A sequence of receive activities can be arbitrarily reordered. <receive "a"/> <receive "b"/> <receive "b"/> <receive "a"/> for asynchronousbinding only ✓ <receive "b"/> <receive "a"/>

19. Anti-Rule: Reordering 16 Anti-Rule: A sequence of sending and receiving activities MUST NOT be reordered. <invoke "a"/> <receive "b"/> ✗ <receive "b"/> <invoke "a"/> ✗ <receive "a"/> <receive "a"/> ✓ <invoke "b"/> <invoke "b"/>

20. Anti-Rule: Reordering (cont.) 17 Anti-Rule: A sequence of sending and receiving activities MUST NOT be reordered. ✗ <invoke "a"/> <receive "b"/> ✗ <receive "b"/> <invoke "a"/> <onMessage"a"/> <onAlarm> <pick> ✗ <invoke "c"/> <invoke "b"/> ✓ <receive "a"/>

21. Additional Communication 18 Rule: New partner links or communicating activities MAY BEbe added. WS-BPEL specification ? <if> ... ... ✗ ✗ <receive "b1"/> <receive "b2"/> ? <invoke "b1"/> <invoke "b2"/>

22. Additional Communication 19 Anti-Rule: New partner links or communicating activities MUST NOTbe added. ? <if> ... ... ✗ ✗ <receive "b1"/> <receive "b2"/> ? <invoke "b1"/> <invoke "b2"/>

23. Conclusion 20 incorrect completions presented novel profile is more liberal than theexisting profiles describes more compatibleexecutable completions can avoid verification future work: adapt existing further rules to WS-BPEL find more rules implement rules in a WS-BPEL editor existing profile novel profile Thank you! Questions?

24. Tools4BPEL (www.informatik.hu- berlin.de/top/tools4bpel) 21 set of allcorrect partners specification Petri net model Operating Guideline abstract process ? ? Fiona equal compatible BPEL2oWFN Petri net model Operating Guideline executable process implementation set of allcorrect partners