1. BPSS Lessons Learned WS-CHOR F2F Meeting, Chicago June 2003

2. BPSS offers only one message exchange pattern with some options

3. Business Transaction vs MEP BPSS introduced some business concepts like Business Transaction with notions such as non-repudiation and legally binding BPSS introduced some business concepts like Business Transaction with notions such as non-repudiation and legally binding –IMHO, this is another layer on top of WS- CHOR, BPSS should really have had two layer –Business exceptions (web) Service Exceptions

4. WS-CHOR Should Incorporate more MEPs Should Incorporate more MEPs –Could go as far as having an MEP language as part of ws-chor (would not be that different from the ws-chor language itself) I think that a choreography protocol is mandatory for WS-CHOR (on top of RM) I think that a choreography protocol is mandatory for WS-CHOR (on top of RM) –The difficulty will come from decoupling the protocol from MEPs –Most people find BPSS protocol too complex

5. BPSS Business Transaction Activity State Computation

6. BPSS Control Flow Was based on UML activity diagram Was based on UML activity diagram –Explored two other models This was a big mistake This was a big mistake –The most humbling moment was when I used BPSS to model a real-world collaboration –Many semantics were missing

7. WS-Chor Control Flow Pi-Calculus is obviously a possibility Pi-Calculus is obviously a possibility State Transition could also be considered State Transition could also be considered Based on the Event-Calculus model I would respectfully suggest that we explore an event based control flow Based on the Event-Calculus model I would respectfully suggest that we explore an event based control flow –This was suggested by Kartsen Riemer (SUN) –I implemented his suggestion as a proposal to BPSS which was not accepted because of we had to use UML activity diagram semantics

8. WS-CHOR Control Flow Event-Based Control Flow Event-Based Control Flow –When a message is exchanged or an MEP is completed, it enables and disables other messages or MEPs –This is really how people think about a choreography –It supports parallelism and recursivity with almost no complexity

9. Event based control flow (example) <Choreography> <MEPs> </MEP></MEPs></Choreography>

10. Event Based Control Flow (another example) <Choreography> <MEPs> </MEP> </MEP> </MEP>…</MEPs></Choreography>

11. WS-CHOR Control Flow The hard parts of the control flow are The hard parts of the control flow are –Messages that can be exchanged any number of times until an event occurs –Messages that can be sent in arbitrary order –If you mix the two it becomes really hard to get a decent control flow without the enable/disable method.

12. Conclusion BPSS was designed in a context (b2b) as part of an architecture (ebXML) BPSS was designed in a context (b2b) as part of an architecture (ebXML) It is essential to well define the ws-chor context and define its position in WSA It is essential to well define the ws-chor context and define its position in WSA I hope that a choreography protocol can make it to the requirement list I hope that a choreography protocol can make it to the requirement list The control flow definition semantics must be chosen very carefully and validated The control flow definition semantics must be chosen very carefully and validated