A talk given by Dirk Fahland at the 3rd Central European Workshop on Services and their Composition (ZEUS'11) in Karlsruhe, February 22, 2011. The talk explains behavioral phenomena in services choreographies where several service instances interact with each other.

1. Dirk FahlandMassimiliano de LeoniBoudewijn F. van DongenWil M.P. van der Aalst Many-to-Many:Interaction in Artifact Choreographies ZEUS 2011, February, Karlsruhe

2. PAGE 1 A process that needs multiple instances 1 2

3. PAGE 2 A process that needs multiple instances 2 1 complex relations between service instances

4. PAGE 3 A process that needs multiple instances  2 1

5. PAGE 4 A process that needs multiple instances  2 1

6. PAGE 5 A process that needs multiple instances   2 1  complex relations between service instances

7. Data each process is founded in its data objects an order a delivery tour the data-objects can be in complex relations PAGE 6 The reason of complex relations + order delivery tour * * follow-up *

8. encapsulate each class of data objects in a service service behavior = data object life-cycle service interface = retrieve data, update data, … delivery tour order PAGE 7 Artifacts life-cycle life-cycle + order delivery tour * * follow-up *

9. wiring:relations between service instances (= objects) cardinality constraints expresshow many instances interact with each other PAGE 8 Choreography inherits relations delivery tour order + * life-cycle life-cycle * + * order delivery tour * + * follow-up *

10. PAGE 9 Formal notation: Proclets

11. order 1 order2 PAGE 10 Example execution create create delivery1 load split split 3 1 2

12. PAGE 11 Many instances talking to each other

13. Artifacts a service instance encapsulates a data object relations between data objects complex communications between service instances Two research problems addressing instances: correlation completing artifact choreographies PAGE 12 New Paradigm  New Problems

14. a set of corresponding communication events between a fixed set of instances C1: order1, delivery1 C2: order2, delivery1, delivery2 C3: order1, delivery2 conversations can overlap PAGE 13 Conversation

15. conversation = a set of related interaction events correlation: mechanism to define whether an event is part of a specific conversation key-based correlation: data-fields of the event same value  same conversation(e.g. orderID, deliveryID) available in BPEL and BPMN 2.0 PAGE 14 Correlation

16. <receive partnerLink="Buyer" portType="SP:PurchasingPT“operation="PurchaseRequest" variable="PO"><correlations><correlation set="PurchaseOrder" initiate="yes" /></correlations> </receive> ... <invoke partnerLink="Buyer" portType="SP:BuyerPT„ operation="PurchaseResponse" inputVariable="POResponse"><correlations><correlation set="PurchaseOrder" initiate="no" /> <correlation set="Invoice" initiate="yes" /></correlations> </invoke> PAGE 15 Correlation Handling in WS-BPEL incoming message: service instance now participates in the conversation C defined by PurchaseOrder outgoing message part of conversation C and initiates a new conversation C2 [wsbpel-v2.0-OS, page 81]

17. BPEL expresses correlation on a per-message basis two correlation patterns require more multiple consumption:one send event several receive events in different instances dynamic list ofcorrelation values PAGE 16 Artifacts Require Stronger Correlation

18. atomic consumption:several send events indifferent instances one receive event dynamic list of sendevents correlation values notknown to receiver  OR-join problem PAGE 17 Artifacts Require Stronger Correlation PAGE 17

19. Artifacts a service instance encapsulates a data object relations between data objects: complex communications between service instances Two research problems addressing instances: correlation completing artifact choreographies PAGE 18 Two Research Problems

20. PAGE 19 Intuitively not allowed incompleteconversation

21. describe interaction between service instances from start to completion proposal: specify as an artifact again PAGE 20 Specify conversations

22. Replace channels with conversation artifact composition: synchronous, dynamic PAGE 21 Refine choreography

23. Given: artifact choreography with asynchronous channels correlation specification and desired properties, e.g.goal states per artifact + “no messages in channels” Wanted: conversation artifacts s.t. the composition satisfies the desired properties and artifacts fit correlation specification(e.g. each conversation artifact implements associated correlation properties) PAGE 22 New problem: choreography completion

24. Processes in reality are driven by data objects Artifacts: each service instance encapsulates a data objects Choreography: wiring reflects object relations Two new problems More involved correlation: which events belong to one conversation? Choreography completion: find the conversation protocol s.t. the choreography has desired properties PAGE 23 Take home points

25. Dirk Fahlandhttp://about.me/dirk.fahlandhttp://acsiproject.eu Many-to-Many:Interaction in Artifact-Choreographies