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

[Danny van der Rijn <dannyv@tibco.com>]

+1
----- Original Message ----- 
From: "Tony Fletcher" <tony_fletcher@btopenworld.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Tuesday, January 20, 2004 8:42 AM
Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC


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)