|
Hello
Yanming,
A few
brief points in reply.
Firstly, I am sure you are correct that all the presently
available transactions specs (BTP,WS-AT/BA,WS-TXM) will be replaced in a
year or two or three time, but the intent is to standardise BPEL in the next few
months so we have to deal current situation.
Secondly, although the details may change there is a basic
'essence' (or pattern) to transaction protocols that has not changed over the
last 15 or more years, and that will continue. I therefore think that the
level of abstraction that we have in the proposed elements and attributes for
BPEL will allow for these types of protocols in the future as well as the
current ones.
Thirdly, although it may not be apparent until you dig in and find out
what is really happening most of complexity in supporting transactions is
actually in the web services. They are the ones that have to make sure
that the transactional work is done correctly, react to cancel and confirm
appropriately and so on. Simply put the Web Service Consumer only has to
start and stop the transaction, find out the result, and continue on its
way. So your basic premise is correct in my view. If the Web service
consumer is not included in the transaction at all then it will not benefit from
the transactional characteristics especially under failure conditions. So
it does need to be involved and support its 'light touch' version of the
transaction protocol. (It is, of course, always possible for a web service
consumer to interact with an intermediary web service not using a
transaction protocol at all, and for the intermediary then to interact
transactionally (as a Web Service Consumer) with other Web Services using
transactions, if the 'driving' web service consumer does not support
transactions at all.)
I hope
this helps.
Best
Regards Tony
A M Fletcher
Home: 35, Wimborne Avenue, IPSWICH IP3
8QW
Tel: +44 (0) 1473 729537 Mobile: +44
(0) 7801 948219
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-----
From: Tony
Fletcher [mailto:tony_fletcher@btopenworld.com]
Sent: Tuesday, January 20, 2004 8:43
AM
To:
wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 53 - Motion
for consideration by the TC
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
Home: 35, Wimborne Avenue,
IPSWICH IP3 8QW
Tel: +44 (0) 1473
729537 Mobile: +44 (0) 7801 948219
|