[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC
|
Hi, All, While we are arguing about how to support different transaction protocols, I'd like to bring up some different thoughts. It is possible that today's available transactions specs (BTP,WS-BA,WS-TXM) are NOT really best designed to reflect the de-coupled features of Web Service technologies : The complexity of coordination of transactions propagates all the way to the Web Service Consumer sides, and in the future we can not consume a transactional Web Services without installing a full-fledged transaction protocol?
I am thinking that the Web Service Consumers should NOT be aware of intermediate states of remote Web Service, thus the Web Service Consumers should only care about the resulting states of remote web services: successful, failed, canceled. It does not mean we do not need a more sophisticated transaction protocol, but it coordinates all states on the Web Service Server side.
Experts, Please validate! Thanks Yanming
-----Original 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)
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]