- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 22 May 2003 12:51:45 -0700
- To: Ricky Ho <riho@cisco.com>
- CC: Mark Little <mark.little@arjuna.com>, public-ws-chor@w3.org
Ricky Ho wrote: > > My understanding of BPEL is they don't have the notion of "provisional > work". So you do the real work and compensate it later. Effectively, > they only have the <compensationHandler> and <cancelHandler>. Their > model is certainly simpler but less sophisticated. If you read by > airline company example and Assaf's solution, I think having a > <prepareHandler> and <commitHandler> is cleaner. > > I think this concept from BTP is pretty useful and I don't see much > additional complexities it brings. Why drop that in BA ? The BA still has the concept of prepare by sending a complete message if you register to the protocol version that includes that notification. An engine may do that if it can delay work to the very end, but I don't think you want to do that in the language using a specific handler. The assumption process languages make is that you start things in order to complete them. So after you send a response you may do additional steps to prepare the work on the assumption you would complete it, and then you can just send a message indicating you completed the work. You may need to wait for someone to tell you to go ahead and do it (like book), but that should be an explicit message not an out-of-band message. If it's out-of-band it belongs to the engine and not the process, at least in all the use cases I've seen. It's just a separation of concern and simplification of the language that is trying to model processes, not every possible implementation of a Web service. arkin > > Rgds, Ricky
Received on Thursday, 22 May 2003 15:54:52 UTC