RE: [wsbpel] Issue 53 - Motion for consideration by the TC

["Tony Fletcher" <tony_fletcher@btopenworld.com>]

Title: Message

Dear Colleagues,

 

It seems to me that we are making this more complicated than it need be.

 

BPEL is neutral to the actual application semantics (unlike BPSS, for instance, which does provide a structure for distributed applications through its 'Business Transactions', and Binary and Multi-Party Collaborations which both aid and constrain the development of the application exchanges). That is to say BPEL does not require any additional application semantic specific language features.

 

For the abstract process use of BPEL it might be possible to initiate and terminate transactions from the application and pass through the BPEL layer. However, this approach clearly breaks down for executable BPEL processes, which are used to define the actions to be taken on the confirm and cancel signals used to terminate the transaction. As I'm sure we would want be consistent, this argues for incorporating transaction demarcation into the BPEL language itself (and both the abstract and executable 'flavours'). 

 

While incorporating transaction demarcation into the BPEL language is not completely trivial, it is not that hard and the Choreology submission has already shown precisely how this could be done. Therefore it seems to me that providing transaction demarcation in BPEL now is relatively straightforward.

 

The BPEL specification does not need to take a dependency on any particular distributed transaction processing specification.

 

On the other hand implementers of BPEL are assured that there is at least one publicly available, royalty free specification that fits neatly into this particular slot (that is the OASIS Business Transaction Protocol Committee Specification - there are implementations and it works fine in the web service environment).  However, as other distributed transaction specifications become accepted and acceptable, they can be slotted in as alternatives, if desired.

 

The proposed confirm and cancel handlers are required to be added into the language in order to gain special features of handlers, but that is all.  Their content can be filled with existing language constructs.

 

It is generally agreed, it seems to me, that the ability to group specified interactions into a transaction is an important feature of some applications, and that BPEL will be deficient if we do not provide this transaction capability of allowing the application designer to state clearly through the BPEL language where a Transaction starts and stops, and exactly what it includes and what should happen when it does stop. As the work to add this capability has already been provided to the TC and it does not bring with it any critical dependencies, then I strongly support adding the capability at this time.

 

Best Regards     Tony

A M Fletcher

Home: 35, Wimborne Avenue, IPSWICH  IP3  8QW

Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219

 amfletcher@iee.org     (also tony.fletcher@talk21.com  &  tony_fletcher@btopenworld.com)