120 likes | 244 Views
BPSS Lessons Learned. WS-CHOR F2F Meeting, Chicago June 2003. BPSS offers only one message exchange pattern with some options. Business Transaction vs MEP. BPSS introduced some “business” concepts like “Business Transaction” with notions such as non-repudiation and legally binding
E N D
BPSS Lessons Learned WS-CHOR F2F Meeting, Chicago June 2003
BPSS offers only one message exchange pattern with some options
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”
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
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
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
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
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>
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>
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.
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