Eric Newcomer on WS Transaction Standards

Posted by Stefan Tilkov on Sep 27, 2006 12:00 AM

Community

SOA

Topics

WS Standards

Tags

WS-Coordination,

WS-AtomicTransactions,

Standardization,

WS-BusinessActivity,

Iona

In a recent blog post, IONA CTO Eric Newcomer wrote about the OASIS Transaction TC's progress in standardizing the Web services WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity specifications. Eric talked to InfoQ about this particular set of specifications, as well as the standardization process and the role of the big players in general.

InfoQ:  Would it be fair to say that WS-CAF and BTP are going to be obsoleted by this new activity, similarly to WS-Reliable Messaging succeeding WS-Reliability? Would it be correct to say that basically, the MS/IBM folks have "won" the WS-* standards battle?

EN: Well it's actually kind of a long story. The basic answer is yes, these are going to be the winning specs. But the background is different than WS-Reliability vs WS-Reliable Messaging. BTP was basically dead on arrival. Although it was supported by a very vocal minority, almost no one implemented it.

WS-CAF has the same architecture as the WS-TX specs. All of these share a common root in the extended OTS spec we did for the OMG. Several of us who were involved in that are on the WS-TX committee, and two of us were on WS-CAF. The OMG spec was the start of factoring out the coordinator as a generic mechanism with pluggable protocols. WS-CAF started as a complement to WS-Transactions and still contains some things — WS-Context and the business process transaction protocol, among others — that WS-Transactions doesn't have.

But certainly the influence of Microsoft and IBM is a big factor. These guys have been leading the web services specifications for several years. Even when WS-CAF was in OASIS and the WS-TX specs were not, customers asked for the WS-TX specs, not the WS-CAF specs.

In WS-CAF TC we are still progressing with WS-Context, which could have a future within SCA. Otherwise I think those of us in the TP community are going to wait and see what may happen in the future, especially around advanced transaction protocols, after the curent WS-TX work is completed. WS-Context is designed to be extended with additional protocols, such as BPM from WS-CAF.

InfoQ: Can you provide a little more detail on WS-Context's future within SCA?

EN: SCA has a requirement to support conversational communications — this was described in the original specifications published last November, and is a current discussion item. WS-Context has been proposed as one possible mechanism for sharing persistent context between conversational services.

InfoQ: Many SOA architects believe that two-phase commit (2PC) transactions are inappropriate for Web services-based interactions. Do you agree? What would be a scenario where I would want 2PC over Web services?

EN: I would say in a controlled environment where the benefits outweigh the costs. We get this requirement from our mainframe customers, for example, when connecting to offhost clients or moving part of a mainframe application offhost. Most mainframe applications are transactional, pretty much by default, and extending them or moving them usually requires an extension to the transactional environment in which they are designed and coded to run - in other words the applications already depend upon transactional infrastructure and would have to be significantly rewritten if the infrastructure wasn’t there.

We have done this in the past with CORBA but today Web services are often the best alternative for service enabling mainframe applications, especially those written using COBOL, PL/I, or another legacy programming language. Other examples would include bridging .NET to J2EE transactions since WS-AT is the standard that Microsoft supports for transactional interoperability. On the J2EE side today you have WebSphere and JBoss supporting WS-AT. The use of 2PC incurs a performance cost, but XML via Web services interfaces and protocols doesn’t have to increase that significantly if you can control the environment and tune the applications. In any measurement of response time, applications always spend the majority of the time on database processing, not messaging. For some applications the benefits justify the costs. An implied question here is why use 2PC at all given its cost. The other side of the equation always needs to be considered, which are the benefits obtained by the additional cost. One good thing to think about is the ability to automatically recover an application to a known state, for example to the last completed order in a distributed order entry application (i.e. more than one database has to be updated to capture the order). In this case the business might well decide that the benefit to the business of being able to resume processing orders from a known point when the application recovers is worth the cost of 2PC, especially considering the additional programming and manual operations procedures that would need to be executed to accomplish the same thing.

InfoQ: You also mention alternative transaction protocol models, which are more appropriate for asynchronous or long-running applications, such as WS-BusinessActivity. I wonder whether such models are not too complicated to be favored over application-specific solutions. Apart from local transactions and 2PC transactions, nothing else seems to have achieved wide-spread adoption in 25 years. Why should it now?

EN: We are seeing new requirements for combining reusable services as the trend toward SOA grows. Web services allow you to abstract any type of software system behind a service description — synchronous RPC, asynchronous messaging, database management, or packaged application. Each of these may have a different transactional style or model that may also need to be abstracted in order to obtain reusability for transactional services. Current transactional models tend toward synchronous, and we are seeing a trend in SOA and elsewhere toward an emphasis on asynchronous (e.g. loosely coupled) processing. We are also seeing a trend toward including services "on the Web" into enterprise applications, and these services are not deployed within a company’s controlled environment. So for a lot of reasons, and due to a number of significant new pressures that are creating different relationships among application components, and creating new types of abstractions, I think we will see the emergence of new transactional models. One example is compensation, which is starting to gain more adoption than in the past.

InfoQ: Isn't it frustrating to succeed in getting a standard through the official process, only to see it obsoleted through the sheer market power of others? Can you think of a solution to this?

EN: The standards process is frustrating for everyone. Getting a specification approved by a standards body is only one part of the overall process of standardization. The ultimate measure of a standard is its market adoption. You almost need a kind of "perfect storm" phenomenon to achieve standardization — a perfect combination of a strong customer requirement, a good technical solution, and a good level of investment by vendors. Many specifications have gone through an open committee processes (and every standards organization has its own process — they are not the same) and have either never been implemented or never been purchased sufficiently to become established as an industry standard. I think it’s safe to say that no one really knows how to accomplish this with any real predictability. During the last 5-6 years Microsoft and IBM have gotten themselves into a leadership position with Web services for a variety of reasons, including market position. They have also tended to write the best specifications. One solution to the problem I believe you are bringing up, which is vendor domination of the standardization process, is for users to take more control. If you can shift the influence over standardization from what vendors are willing to invest to what users are willing to buy, we might see a change in the current dynamics around this. We might be seeing the start of this with SOA, since customers are starting to understand that SOA isn’t something you can buy from a vendor.

InfoQ: Thank you very much!

• Older >