[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; email@example.com 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:firstname.lastname@example.org] Sent: Wednesday, October 22, 2003 2:53 PM To: Keith Swenson; Lublinsky,Boris S.; email@example.com 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: firstname.lastname@example.org; email@example.com 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, firstname.lastname@example.org Fujitsu Software Corporation 3055 Orchard Dr. San Jose, CA, 95134 (408) 456-7667 mobile: (408) 859-1005 -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] Sent: Tuesday, October 21, 2003 10:17 AM To: email@example.com Subject: [business-transaction-comment] Public Comment Comment from: firstname.lastname@example.org 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 email@example.com, or visit http://www.oasis-open.org/mlmanage/.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]