[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [business-transaction-comment] Public Comment
To answer this question we have to tackle it from two aspects: technical and
political.
Let's look at the technical first. Firstly, it's wrong to say that two-phase
(2PC) commit was not widespread until XA came on the scene. 2PC has been
around since the 1960s and was in widespread use on mainframe platforms long
before XA. Take a look at the historical records on CICS, ACMS and IMS as
examples. What XA did was standardize the interaction protocols and this was
very important. However, the evolution of XA was driven by vendors (of
transaction systems and databases) and users, who required the ability to
interact with different vendor implementations (predominately
databases/resource managers).
Unfortunately, only certain aspects of the X/Open XA specifications actually
got widespread adoption. For example, X/Open standardized on the OSI TP
(including XA+) but this didn't really take off. So in many cases
distributed transaction interoperability has remained a goal.
BTP is unfortunately not the best protocol or technical committee in which
to look at standarization for Web services transactions. From a technical
perspective, the protocol was a good first attempt at this, but it suffers
from over complexity and lack of support from any of the major players in
this space. You need to understand that the vast majority of the WS-CAF
consortium were involved with BTP, many from the outset. Some of us even
have implementations. However, based on experiences with these
implementations and talking to customers, it became apparent that BTP was
not appropriate for the uses to which people wanted to put it.
Let's look soley at the domain that both the original WS-CAF consortium and
IBM/BEA/Microsoft came from: Web services. Both sets of specifications
define multiple protocols (3 for WS-CAF and 2 for WS-T), built on a generic
coordination service, which, in the case of WS-CAF, is built on a context
service. Each of these protocols has been designed to be useable for a
specific set of use cases (e.g., ACID transaction interoperability, or long
running compensation based interactions).
There has been a deliberate attempt not to define a single protocol that
tries to satisfy all user requirements, simply because that doesn't work and
certainly doesn't scale. Both WS-T and WS-TXM (the transaction part of
WS-CAF) have essentially taken the micro-kernel approach. Back in the late
1980's we had what were subsequently dubbed macro-kernels that were bloated
operating systems trying to provide services for every possible use case,
even when most use cases probably weren't applicable to 80% of users. The
result was massive memory utilization and degredation in performance. The
early 1990's saw the evolution of micro-kernels where the core kernel
service was very small and additional functionality could be added
dynamically as and when required. The aim was to allow a kernel to be
customizable on a per deployment basis. The advantages to this approach are
obvious.
The designers of WS-T and WS-TXM believe that this is the right approach for
Web services transactions too. No one protocol can be applicable to all use
cases and we shouldn't attempt to design such a thing based on our current
limited knowledge of how transactions will be deployed in the evolving Web
service arena.
It has been said that BTP is a two-phase completion protocol and that most
of the protocols in WS-T and WS-TXM can be mapped onto a two-phase protocol
as well. However, this glosses over an important point. Although you could
implement WS-T and WS-TXM using a sufficiently flexible two-phase commit
engine, this is purely an implementation choice. In some of the protocols,
the first phase or second phase might be a null-op, for example. So, if you
were to design an implementation of these protocols from scratch would you
really do that by implementing a two-phase engine first and then casting
aside portions of that engine simply because they don't need to be there for
some protocols? Probably not. But again, that's an implementation choice.
BTP is fine for some use cases, but for others it requires extensions or
additional functional and agreements outside the scope of the current
protocol. This is in no way meant to imply that it is an invalid protocol
and we in WS-CAF have always believed that as a protocol BTP should be able
to fit into WS-TXM. What this is meant to say is that BTP as a unifying glue
for all Web services transactions requirements is not the solution - and
there is no single solution.
Now for the political aspects. What all of this comes down to is that X/Open
and XA aren't exactly the best analogies to make. From a high-level
perspective it may seem like they united the world of distributed
transaction processing, but in reality they didn't. In order to accomplish
such a goal you need the backing of all of the major players in this area.
For technical reasons, the WS-CAF consortium was founded outside of BTP. We
have tried very hard to work with IBM/Microsoft/BEA to get them to work
within WS-CAF and donate WS-C/T. However, although we are more than willing
to work in an open standards process, at the moment they are not. That makes
it very difficult to come up with a single solution that will unite the
world.
We therefore have only two solutions: wait until IBM/Microsoft/BEA are ready
to play in the standards world (which could be a long time), or progress
things in the way that we think is right.
Obviously waiting for IBM etc. to make up their minds about standards is not
going to happen. It doesn't benefit anyone: vendors or customers. So that
leaves the second option.
WS-CAF is technically as proficient in solving current real-world use cases
as WS-C/T from IBM/Microsoft/BEA. We know this from talking to our customers
on what their requirements are and from conversations with others in the
industry.
BTP does not make sense as an umbrella standard since it has not succeeded
and is not widely implemented (certainly not by the major vendors). The same
could be said about WS-CAF excepting the fact that WS-CAF is designed
explicitly for us with Web services (BTP is not) and also is designed to
work with BTP, WS-T, WS-BPEL etc.
So, WS-CAF is the answer because it was designed for the problem. If you
were to take BTP as the starting point, you'd be going the opposite way,
trying to influence everyone to adopt a single solution rather than a
framework designed to encompass multiple models, which is what Web services
ultimately needs (since a Web service can wrap anything).
How WS-CAF interacts with WS-C/T will only become apparent when/if IBM etc.
donates these protocols to some standards body. Until then, multiple
specifications are an unfortunate fact of life. Even at this late stage, the
WS-C/T authors can become involved in WS-CAF and we still hope they will.
Mark Little & Eric Newcomer.
-----Original Message-----
From: Lublinsky,Boris S. [mailto:Boris.Lublinsky@cna.com]
Sent: Wednesday, October 22, 2003 1:05 PM
To: William Z Pope; Keith Swenson;
business-transaction-comment@lists.oasis-open.org
Cc: OASIS BTTC (Main List)
Subject: RE: [business-transaction-comment] Public Comment
I agree with Bill,
Historically the same was happening with the classical two phase-commit
protocol. Until industry adopted XA, two-phase was not wide spread. I see
the same thing happening in Web Services transactions, until the industry
will agree on a single protocol, we won't see a massive adoption of web
services transactions. And the fact that BPEL has effectively introduced its
own transactional model confirms this.
----------------------------------------------------------------------------
From: William Z Pope [mailto:zpope@pobox.com]
Sent: Wednesday, October 22, 2003 2:53 PM
To: Keith Swenson; Lublinsky,Boris S.;
business-transaction-comment@lists.oasis-open.org
Cc: OASIS BTTC (Main List)
Subject: RE: [business-transaction-comment] Public Comment
Boris' email complains about the proliferation of web services
transaction standards. I have a
hard time seeing yet another standard addressing the same thing in a
slightly different way as
what he's looking for. Can you describe how different protocols can be
mixed? This seems
like a way to institutionalize non-interoperability.
=bill
-----Original Message-----
From: Keith Swenson [mailto:KSwenson@fsw.fujitsu.com]
Sent: Wednesday, October 22, 2003 12:00 PM
To: boris.lublinsky@cna.com;
business-transaction-comment@lists.oasis-open.org
Subject: RE: [business-transaction-comment] Public Comment
WS-CAF (Composite Application Framework) is probably what you are
looking for. WS-CAF has three layers, the offers a context, the second
offers coordination, and the top level transactions. The framework is a
standard way to plug in different transaction model/protocols. Both BTP and
WS-Transaction are cited in the spec as example transaction protocols that
can be used. It is supposed to be possible to mix different protocols.
Link to the OASIS TC:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf
Cover Page: http://xml.coverpages.org/ni2003-09-18-a.html
Keith D Swenson, kswenson@fsw.fujitsu.com
Fujitsu Software Corporation
3055 Orchard Dr. San Jose, CA, 95134
(408) 456-7667 mobile: (408) 859-1005
-----Original Message-----
From: comment-form@oasis-open.org [mailto:comment-form@oasis-open.org]
Sent: Tuesday, October 21, 2003 10:17 AM
To: business-transaction-comment@lists.oasis-open.org
Subject: [business-transaction-comment] Public Comment
Comment from: boris.lublinsky@cna.com
Transaction processing for Web Services today suffers significantly
from proliferation of the Web Services transactions standards. Between BTP
and WS-transactions, there is a lot of similarities, but yet the standards
are different. What makes the situation even worse is the fact that the
leading web Services Business Process management standard - BPEL, introduces
yet another transactional model, which is not alligned with either BTP or
WS-Transactions. It would certainly make sense to try to merge all these
multiple standards together. It would also make sense to use BTP as an
umbrella standard, due to the fact that it seem to have the broadest
coverage and allows to express most of the semantics, that can be found in
other transaction protocols
To unsubscribe from this list, send a post to
business-transaction-comment-unsubscribe@lists.oasis-open.org, or visit
http://www.oasis-open.org/mlmanage/.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]