The document discusses extending the compatibility notion for abstract WS-BPEL processes, highlighting the need for executable web services to adhere to compatibility rules. It introduces a novel profile using formal methods to optimize the compatibility and observable behavior between abstract and executable processes while addressing limitations of existing profiles. The paper suggests that the new profile allows more flexible variations in executable processes while avoiding certain disallowed transformations, thus promoting effective business process execution.

1. Extending the Compatibility Notion for Abstract WS-BPEL ProcessesDieter KönigSimon MoserNiels LohmannKarsten WolfChristian StahlIBM Böblingen LaboratoryGermanyUniversity of RostockGermanyHumboldt-Universität zu BerlinGermanyUNIVERSITÄT ROSTOCK

2. WS-BPEL2Web Service Business Process Execution Languagespecifies a business process by orchestratingWeb servicesimplemented as Web service itselfprocess can be anexecutable Web servicesabstract processes ("business protocols")

3. Executable WS-BPEL Process3<receive>credit request from customerelsesalary <= 5000 $tradesecrets<if><assign>customer name to blacklist<assign>customer name to databasetechnicaldetails<reply>credit rejection to customer<assign>customer id to credit case<reply>credit approval to customer

4. Executable ➙ Abstract WS-BPEL Process4<receive>credit request from customerelsesalary <= 5000 $opaque conditiontradesecrets<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. Applications5bottom uptop-downexchange/documentationformat, templateabstract processabstract processabstractionrefinementexecutable processexecutable process

6. Compatibility6specification and implementation must be compatible

7. means to check/achieve compatibility:

8. computer-aided verification

9. abstract profilesspecificationabstract process?compatibleexecutable processimplementation

10. Compatibility: Computer-aided Verification7specificationformal modelabstract process✓compatible?verification toolcompatible✗notcompatibleformal modelexecutable processimplementation

11. Compatibility: Abstract Profiles8abstract profile defines transformation rulesspecificationimplementationintermediate processexecutable processabstract processintermediate processintermediate process✓compatible by design

12. Compatibility: Summary9Computer-aided Verificationexpensive technique (time + memory)only applicable if both specification and implementation are availableAbstract Profilessimple syntactic rulesapplicable during design time(only one process required)some defined in the WS-BPEL specification

13. Abstract Profile for Observable Behavior 10intention:maintain observable behavior of abstract processimplementation must not change thisdefined 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) 11problems:profile is too strict (and even incorrect!)executable process's structure too much depends on abstract process's structuremany correct completions are disallowedthis paper's contribution:define a novel profilerules base on formal methodsanti-rules define forbidden transformations

15. Non-Communicating Activities12Rule: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 Flow13Data 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 Activities14Rule: A sequence of first invoke and then receive can be transformed into a flow. <invoke "a"/><receive "b"/>✓for asynchronousbindingfor asynchronousand synchronous binding<receive "b"/><invoke "a"/>

18. Communicating Activities15Rule: 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: Reordering16Anti-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.)17Anti-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 Communication18Rule: New partner links or communicating activities MAY BEbe added.WS-BPEL specification?<if>......✗✗<receive "b1"/><receive "b2"/>?<invoke "b1"/><invoke "b2"/>