W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Re: Co-ordination protocol and BPEL

From: Assaf Arkin <arkin@intalio.com>
Date: Thu, 22 May 2003 12:51:45 -0700
Message-ID: <3ECD2A51.8000204@intalio.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:17 GMT