Actually, I didnt misunderstand.  My point is that I don't believe it will be a robust, widely supported reality for many years, especially considering we do this today with XA (painstakingly).  The market for this kind of protocol is pretty conservative, they likely will not transition for many, many years, robbing vendors of field experience to harden their implementations.

  I am particularly concerned with how isolation will be achieved in practice across all of these diverse platforms, with all sorts of service interfaces that have varying granulatity, supposedly pluggable transport protocols, etc.

  And in the end, we would have much the same heartache we have with today's coarse-grained locking approaches and dealing with in doubt transactions.

Basically, I think WS-TX is great plumbing for problems we had 15 years ago.  I'm not saying that consistency and isolation are bad - when you need them, you need them. I am saying, "shouldn't we be looking at newer ideas?"  For example, perhaps if the industry created a standard for Paxos agreement, and drove adoptipn in databases, some of our 2pc headaches would ease.

Cheers

Stu

Sent from my iPhone

On Aug 30, 2007, at 5:39 AM, Mark Little <nmcl2001@...> wrote:

I think you completely misunderstood what I said and what the aims of  

the specifications (and WS-* in general) are: interoperability. WS-TX  

(and WS-CAF) were never meant as replacements for XA but as  

complimentary. I think the original article missed that completely too.

But have you ever tried to get CICS to talk to Tux out-of-the-box? Or  

Tux to Encina? Yes, IONA has a protocol bridge to do this. Yes,  

there's been work on TIP-to-OTS bridging. But it's all required  

intimate knowledge of how each end behaves and under what  

circumstances. It's done on a one-to-one basis. I spent many years  

working with the OTS to achieve interoperability in the standard and  

several implementations and the main problems weren't with the OTS:  

they were with the based CORBA platform and peculiarities of  

implementations.

With WS-TX, we got interoperability with CICS, Encina, JBossTS, MSFT- 

DTC, (no Tux because BEA dropped out of the process) straight away.  

No expensive consultants. No one-on-one interoperability that doesn't  

scale. No vendor specific extensions or wire protocols. And yes, some  

of us were using XA at the back-end to drive things like participant  

updates, logs etc.

I can't obviously speak for Eric (the co-chair of WS-TX and someone  

I've co-authored WS-TX and WS-CAF as well as other transaction  

standards), but speaking personally: after spending 20+ years working  

in the transaction arena I find that pretty impressive. But then  

maybe I'm just easily pleased ;-)

Mark.

On 29 Aug 2007, at 14:42, Stuart Charlton wrote:

In my experience, distributed transaction interoperability is  

almost always conducted at the language-level with XA resource  

managers, because most databases or message queues use proprietary  

wire protocols.   This happens whether it is the MSDTC in COM+  or  

a Java transaction service, etc.  IIOP and the OTS only works  

between CORBA-compatible servers, which works in the J2EE world,  

but the Microsoft world chose TIP.  Environments like CICS could do  

this at the protocols level quite well, though (when crossing  

regions)..

While Ws-ReliableMessaging arguably removes the need for  

proprietary messaging protocols to some degree, I don't see a  

similar wire protocol for queries and data services (and tightly- 

binding result sets to a custom domain-dependent XSD is  

questionable).  XA likely will reman the plodding workhorse that it  

is for a long time....

Cheers

Stu

Sent from my iPhone

On Aug 25, 2007, at 2:06 AM, Mark Little <nmcl2001@...> wrote:

I'm really not quite sure what to say about this article. While the  

author is right that XA is more mature than WS-TX, and that  

transactions are an important tool in an achitect's tool-belt,  

saying that XA is a replacement for Web Services transactions is a  

bit like saying that because IIOP is more mature than SOAP we  

should all be using it. It's true, but it's never going to happen  

and overlooks what Web Services bring to distributed transactions:  

interoperability.

It's nice to hear that Oracle have identified problems with WS-TX.  

We all have. But then who hasn't identified problems in the way  

different XA implementations interpret the XA specification? Last  

time I looked, we had several workarounds for the differences  

between Oracle 9i and 10g, let alone how they differ between DB2  

and SQLServer.

Mark.

On 24 Aug 2007, at 17:17, Gervas Douglas wrote:

<<Today, many technologists believe that Web services are the  

proper mechanism for integrating with disparate database  

environments. Contrary to public opinion, Web services and  

distributed (aka XA) transactions are complementary, not  

alternative, technologies.

Recently, I read an article that stated that:

"Enterprise service buses are the preferred tools for integrating  

systems with heterogeneous data interchange interfaces and based on  

a wide array of technologies, from COBOL to CORBA to JEE". (Eugene  

Ciurana, Mule: A Case Study, TheServerSide.com)

While Web services are clearly useful for integration with  

heterogeneous data sources, relying solely on Web services,  

especially for heterogeneous (that is, distributed) transactions is  

more complex than supporting XA and architecturally limiting.  

Furthermore, the Web services specifications and resulting  

implementations are new, and therefore not as mature as XA. If Web  

services are pursued, a number of other WS-* specifications would  

need to be in place to begin to construct the transactional  

management that XA provides.

Still, I agree with Dan Foody, CTO of Actional in that "The long  

term success of Web services and SOA is directly affected by their  

ability to be used for mission critical solutions in the  

enterprise. Because many mission critical applications require  

transactional integrity, WS-TX (Web Services Transaction) will  

enable these applications to be successfully built and deployed  

using Web services without sacrificing multi-vendor interoperability."

Business and technical requirements

For the most part, all business software systems are derived from  

corporate processing requirements. Even the modern concept of an  

"enterprise service bus" I am sure was developed within a  

PowerPoint presentation of a senior business analyst in order to  

address the dysfunctional enterprise environment after a merger and  

acquisition.

Still, business process analysts should not be encumbered by the  

technological feat of a process design during the visioning stage  

of a new application, even if the requirements indicate the need  

for heterogeneous transactions between legacy applications. After  

all, that is what XA is all about.

My most recent project can be characterized as a significant  

enhancement to a five-year-old J2EE application, which by today's  

standards is part service bus and part business process management.  

This application was designed to integrate and unify the many  

claims management systems within a large insurance company.

These integration points are at the individual claim transaction  

level, so internal consistence of workflow transactions is  

paramount to the overall "enterprise-wide" system staying  

internally consistent. Based on these requirements and the  

specified logical units of work (see figures: Logical Unit of Work  

1 and 2), it became clear to me that the best way to guarantee  

transaction integrity was to develop a set of XA-style  

transactions. While some analysts suggest that a set of Web  

services could accomplish the same object, there are limitations to  

using that construct, which will be further discussed.

XA-style distributed transactions

The XA interface is a mature protocol for treating DB2, Oracle and  

JMS (an XA-compliant interface to a physical queue) as essentially  

one resource, where logical transactions can be committed and  

rolled back. Using an XA-style transaction, the programmer does not  

need to be concerned with handwriting defensive, compensating  

transaction code, which is by nature error prone, in the event of  

unknown application-bound SQLExceptions or Java runtime exceptions.

The programmer, because of the enabling XA technology, can focus  

more on simply creating the atomic transaction code, let the XA  

resource manager handle rollback and commit logic. Without XA, the  

programmer needs to find a creative solution to rolling back the  

distributed transaction in case one of the participating resources  

fails, instead of a standard mechanism. Alternatively, the  

programmer might develop an optimistic construct and assume that  

his code will never fail, and it may not … until he/she leaves the  

project.

According to the XA specification documents in the Open Group's X/ 

Open Distributed Transaction Processing (DTP) model, which defines  

how an application program uses a transaction manager to coordinate  

a distributed transaction across multiple resource managers, any  

resource manager that adheres to the XA specification can  

participate in a transaction coordinated by an XA-compliant  

transaction manager, thereby enabling different vendors'  

transactional products to work together.

High-end JEE application servers, such as, Oracle Application  

Server, WebLogic and WebSphere support JTA (Java Transaction API)  

required for XA style transactions. An XA transaction involves  

coordination among the various resource managers, which is the  

responsibility of the transaction manager.

The transaction manager is responsible for making the final  

decision either to commit or rollback any distributed transaction.  

JTA specifies standard Java interfaces between the transaction  

manager and the application server and the resource managers.

All XA-compliant transactions are distributed transactions. XA  

supports both single-phase and two-phase commit. A distributed  

transaction is a transaction between two or more independent  

transactional resources (for example, two separate databases). For  

the transaction to commit successfully all of the individual  

resources must commit successfully; if any of them are  

unsuccessful, the transaction must roll back in all of the resources.

XA - The forgotten protocol

However, finding individuals initiated to XA is now becoming a  

somewhat elusive endeavor. Although, a colleague of mine within the  

organization corroborated that XA would be an appropriate  

mechanism, based on the design requirements (see figures below).

My next step was to contact the infrastructure manager(s) to see if  

XA was supported in the enterprise environment. I was surprised  

that the individual I contacted, although at least candid, did not  

know what XA was. After contacting other administrators that did,  

they were opposed to supporting XA, because of the additional OS  

and middleware (i.e. XA-specific database drivers) support the  

technology would require.

I first used XA on a large-scale DCE (Distributed Computing  

Environment) project with a major NYC bank where we used Transarc's  

Encina Transaction C++ (now an IBM company). This was in the middle  

'90s and XA was already established and one of the key protocols  

within the DCE. After all, if you are going to call yourself the  

"distributed computing environment" you better support distributed  

transactions.

XA, then and even now has a reputation for being slow, mainly  

because of the complex prepare and commit transaction lifecycle  

among disparate resources coordinated by the transaction manager.  

Although, considering the alternatives, it remains an important  

tool in the integration architect's toolbox. Indeed, XA outside the  

banking industry still appears to be an unknown or at least a  

little-used protocol.

Identifying the need for a distributed transaction

If your organization doesn't have a high-end data integration tool,  

you may need to develop custom distributed transactions  

applications. Here is a short list of reasons for using XA:

Moving data between a database and a JMS message within a tightly  

coupled workflow -- An application may need to move data from a  

database to another database and then send a JMS message to another  

disparate system or a message-driven bean that indicates the new  

data has arrived (see figure below).

<part1.06030403.00020201>

Moving data between disparate databases as a transaction hand-off  

-- Moving data from one database to another requires an XA-style  

transaction or a normal transaction that includes a compensating  

transaction in the event of a failure. For example, the insert  

completes and the update fails (see figure below).

<part2.02070306.02000807>

Alternatives to XA: The creative art of compensating transactions

As mentioned, most Java programmers use bean-managed transactions  

for developing distributed transactions. While bean-managed  

transactions can be straightforward, developing compensating  

transactions in the event of a failure sometimes can be  

challenging, especially with JMS in the mix that is.

A compensating transaction can take the form of a delete operation  

or a forced rollback. For example, for bean-managed transactions,  

an update, although successful, can be rolled back if the insert  

operation fails (see Logical Unit of Work 2) in order to keep the  

application workflow internally consistent.

Alternatively, for Logical Unit of Work 1, if the JMS send fails,  

the application construct can be built to be idempotent. That is,  

if the send operation fails it can be "repeated safely" maybe not  

immediately, because a failure might indicate that the resource is  

in an inconsistent state, but at some future time. Again, the  

application workflow will remain internally consistent. As a  

colleague of mine once cautioned, maintaining state in a  

distributed environment is an evil thing.

The point here is not that designing and developing compensating  

constructs is necessarily complicated. It is that in the absence of  

XA, non-standard and sometimes very unique strategies need to be  

devised for each distributed action failure, instead of letting the  

XA protocol and underlying resource manager manage the transaction.  

Essentially, the programmer has a standard mechanism for managing  

distributed transactions.

Alternatives to XA: Web services

Today some technologists are even positioning the enterprise  

service bus (ESB) as a standard mechanism for integrating systems  

with heterogeneous data interfaces. While ESB and Web services can  

clearly be used to move data between disparate data sources, I  

would not recommend using a set of Web services to implement a  

distributed transaction if the transaction requirements could be  

achieved by using XA, even if the enabling Web services technology  

supported WS-Transaction (WS-TX). The one advantage Web services  

have over XA is that XA is not a remote protocol, though.

WS-Transaction is the name of the OASIS group that is currently  

working on the transaction management specification. WS-TX is the  

name of the committee, and they are working on three specs:

WS-Coordination (WS-C) - a basic coordination mechanism on which  

protocols are layered;

WS-AtomicTransaction (WS-AT) - a classic two-phase commit protocol  

similar to XA;

WS-BusinessActivity (WS-BA) - a compensation based protocol  

designed for longer running interactions, such as BPEL scripts.

In practice, WS-AT should be used in conjunction with XA to  

implement a true distributed transaction. WS-TX essentially extends  

transaction coordinators, such as OTS/JTS and Microsoft DTC to  

handle transactional Web services interoperability requirements.

I recently spoke with a senior member of the OASIS WS-TX committee  

from Oracle while researching this article regarding the robustness  

of WS-AT versus XA. He clearly indicated that while the technology  

was similar, testing at Oracle was problematic in certain system  

use case scenarios. This discussion has further corroborated my  

opinion that in the near future, if a distributed transaction is  

warranted, I will rely on XA rather that an immature, albeit,  

modern solution.

XA supported within JEE application servers, OS platforms and  

databases

Oracle, WebSphere and WebLogic application servers support XA  

transactions on Microsoft Windows (32-bit versions only), IBM AIX,  

Sun Solaris and HP-UX. The following enterprise grade databases are  

XA-compliant: IBM DB2 Universal Database V8.2 and Oracle 9i and  

10g. Note that this is not a complete list of XA-compliant DBMS and  

it depends on your definition of enterprise grade.

Of interest to the Open Source and Java communities, MySQL 5.0 now  

has distributed transaction processing support through XA.  

Additionally, FirstSQL/J Enterprise Server has comprehensive  

support for connection pooling and Java Transaction APIs (JTA) for  

distributed transaction (that is, XA) capabilities.

Implications

Truth be told, XA is viewed as a luxury and not a "required"  

application tool for programmers within most organizations.  

However, infrastructure groups that don't support XA are  

essentially establishing an asymmetrical transaction failure risk  

curve that is skewed against the application programmer.>>

You can read this at:http://searchwebservices.techtarget.com/tip/ 

0,289483,sid26_gci1268976,00.html? 

track=NL-451&ad=600655&asrc=EM_NLC_2047205&uid=5532089

______________________________________________________________________ 

______________

Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:  

mail, news, photos & more.

http://mobile.yahoo.com/go?refer=1GNXIC

Yahoo! Groups Links

tings via email:

   mailto:service-orientated-architecture-digest@yahoogroups.com 

   mailto:service-orientated-architecture-fullfeatured@yahoogroups.com

____________________________________________________________________________________

Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.

http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  

Yahoo! Groups Links

<*> To visit your group on the web, go to:

    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:

    Individual Email | Traditional

<*> To change settings online go to:

    http://groups.yahoo.com/group/service-orientated-architecture/join

    (Yahoo! ID required)

<*> To change settings via email:

    mailto:service-orientated-architecture-digest@yahoogroups.com 

    mailto:service-orientated-architecture-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:

    service-orientated-architecture-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

    http://docs.yahoo.com/info/terms/