1 / 12

Exploring BPSS and WS-CHOR Control Flow: Lessons Learned from Chicago Meeting 2003

This document discusses critical insights from the June 2003 BPSS meeting in Chicago, focusing on the complexities of Business Process Specification Schema (BPSS) and Web Services Choreography (WS-CHOR). It highlights the limitations of BPSS in message exchange patterns, discusses event-based control flow models, and critiques the UML activity diagram approach. The need for a robust choreography protocol and a valid control flow definition is emphasized, along with suggestions for improving BPSS to better handle real-world collaborations.

tavon
Download Presentation

Exploring BPSS and WS-CHOR Control Flow: Lessons Learned from Chicago Meeting 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • 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 • 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) • 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 • Explored two other models • 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 • State Transition could also be considered • 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 • 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> <enable mep=“ProcessPO”/> <MEPs> <MEP type=“ProcessPO”> <enable mep=“Process Invoice” condition=“Success” /> <disable mep=“self” /> </MEP> </MEPs> </Choreography>

  10. Event Based Control Flow(another example) <Choreography> <enable mep=“ProcessPO”/> <MEPs> <MEP type=“ProcessPO”> <enable mep=“ChangePO” condition=“Success” /> <enable mep=“CancelPO” condition=“Success” /> <disable mep=“self” /> </MEP> <MEP type=“ChangePO” duration=“P2D”> <enable mep=“ProcessInvoice” condition=“timeout” /> <disable mep=“CancelPO” condition=“timeout” /> <disable mep=“self” condition=“timeout” /> </MEP> <MEP type=“CancelPO” duration=“P2D”> <terminate choreography=“self” condition=“success” /> <enable mep=“ProcessInvoice” condition=“timeout” /> <disable mep=“ChangePO” condition=“timeout” /> <disable mep=“self” condition=“timeout” /> </MEP> … </MEPs> </Choreography>

  11. WS-CHOR Control Flow • 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) • 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 • The control flow definition semantics must be chosen very carefully and validated

More Related