Loading ...
Sorry, an error occurred while loading the content.
 

Re: [service-orientated-architecture] Teti on WS & XA

Expand Messages
  • Mark Little
    So you don t think that interoperability is a problem today? I find that hard to understand, particularly given what I see day-to-day. But maybe this is just a
    Message 1 of 19 , Aug 30, 2007
      So you don't think that interoperability is a problem today? I find that hard to understand, particularly given what I see day-to-day. But maybe this is just a breakdown in communication: WS-AT, WS-ACID (from WS-CAF) and Atoms (from BTP) were never intended to be used for loosely coupled interactions. That's the job of WS-BA, WS-LRA, WS-BP (both from WS-CAF) or Cohesions (from BTP).  WS-AT is there for short duration interactions between heterogeneous transaction system implementations: purely for transaction service interoperability. We tried to do transaction interoperability in the OMG through the OTS, but that took a long time and not everyone supports OTS/JTS (when was the last time you saw Microsoft with an OTS implementation?)

      Web Services offer interoperability as one of their main benefits. We now have demonstrated transactional interoperability between all of the major TP vendors. For customers who have heterpogeneous implementations, then this is a critical component. I see large and small companies wanting to have their WebLogic apps talk to WebSphere or JBossAS, and do it transactionally. And we do not do that today with XA. Sitting in both camps (Red Hat supports XA, OTS/JTS, Web Services transactions and other extended transaction models), I'm fairly comfortable repeating that the easiest way to do heterogeneous transaction service interoperability today is via something like WS-AT. That doesn't mean that it's necessarily the most efficient in all cases, but from what we're seeing so far, it definitely hits the 80/20 rule.

      As authors of the specifications, we have *never* said that WS-AT et al should be used for long duration interactions. Over the past 8 years the reasons for not doing so have been well documented by myself and others. Now we can't prevent people from using WS-AT in other situations. But it's an education thing.

      BTW, even Jim (Gray) admitted that Paxos isn't the solution. There is no single solution. All protocols make certain assumptions about the environment in which they work. Paxos is good. 3PC also exists. Nested transactions. Multi-colored actions, etc. etc. One size does not fit all.

      Mark.



      On 30 Aug 2007, at 18:57, Stuart Charlton wrote:

      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.
    • Anne Thomas Manes
      Eric, I agree completely with what you ve just said. It s appropriate to use 2PC to coordinate a transaction that involves a single unit of work that must
      Message 2 of 19 , Sep 1, 2007
        Eric,

        I agree completely with what you've just said. It's appropriate to use 2PC to coordinate a transaction that involves a single unit of work that must update multiple data sources -- but I strongly recommend that the single unit of work be performed by a single service. It is generally a bad idea to distribute that single unit of work over multiple services. As long as a single service performed the single unit of work, then SOAP doesn't need to be involved in the 2PC protocol.

        Anne

        On 8/29/07, Eric Newcomer <e_newcomer@...> wrote:
        Hi Anne,
         
        I think what you mean is good advice, but "distributed 2PC" is imprecise since 2PC is distributed by definition.  2PC applies when the data updates are distributed among two or more data resources, whether local or remote.  And a local ( i.e. not over the network) 2PC is often a very good option.  Coding around that yourself is not a good idea.  The most common form is when someone needs to update a message queue and a database in the same transaction.  This is 2PC, and as I said 2PC is distributed.  A distributed transaction is one that involves more than one resource.
         
        I apologize if this seems kind of nit picky to you, but it seems like people are starting to advise against 2PC in any and all cases, and I don't think that's good advice.  I am sure that's not what you meant but there's so much misunderstanding out there about transactions that I think we need to be careful not to say something that could be misinterpreted.  I.e. 2PC is not inherently a bad thing.
         
        Eric

        ----- Original Message ----
        From: Anne Thomas Manes < atmanes@...>
        To: service-orientated-architecture@yahoogroups.com
        Sent: Wednesday, August 29, 2007 7:11:10 AM
        Subject: Re: [service-orientated-architecture] Teti on WS & X

        Eric,

        Let me repeat what I said:

        There are many ways to implement transactional integrity, and as a general rule, it's best to avoid using a 2PC distributed transaction protocol if possible.

        and clarify what I meant:

        I agree that if you really need 2PC, then you should use 2PC. But my point is that using alternative designs, in many cases you don't really need 2PC. Keep in mind: if you really do need 2PC, then the system will be tightly coupled. My recommendation is that you should avoid using a SOAP invocation in the midst of a 2PC transaction. There are better protocols to use in this situation.

        Anne

        On 8/26/07, Eric Newcomer <e_newcomer@yahoo. com > wrote:
        Hi Anne,
         
        I would have to say it's not a good general rule to avoid 2PC if that's what you really need.  Coding around 2PC, or coding up something yourself that does the same thing is not easy, and risks all kinds of data inconsistency problems that are much harder to resolve manually.  It's a bit like the rule of thumb that says it's much more expensive to correct a mistake on a bank statement or phone bill than it is to ensure the bills are correct in the first place.  There may indeed be many cases in which 2PC does not make sense, but when it does there is really not a good substitute.  The cost of a protocol is only one part of the equation, and to in order evaluate whether or not 2PC fits your requirement you also have to look at the benefit part of the equation.
         
        As another general statement, I'd say that the "container managed" transaction approach has hurt rather than helped since it's so easy to misuse 2PC and turn it on when it isn't really needed.  I think this is especially true in the Java world because OTS/JTS forces an artificial choice between local and global transactions - meaning you can't code an object for a local transaction and then easily change it to a global transaction.  This resulted in the so-called "one phase commit optimization" which is not an optimization at all since an independent transaction manager has no role in a single resource transaction.
         
        One of the easiset things to forget in distributed computing when thinking about transactions is that a transaction has no meaning outside of an operation on data.  In other words, client side transactions are meaningless unless they perform an operation on data (you will get some argument about this but I emphasize it because people tend to forget that the purpose of the transaction abstraction is to group related operations on data).
         
        With regard to WS-TX, it is not so much an abstraction of XA as it is an abstraction of the transaction manager.  For Java this is the implementation of JTA (typically OTS/JTS) and for Windows this is DTC.  Both OTS/JTS and DTC use XA for integration with data resources, but XA is not a distributed API, it is local between the independent transaction manager and the transactional resource.
         
        Phil and I are in the middle of updating our TP book, "Principles of Transaction Processing" to include newer technologies and standards, but the fundamental principles haven't changed very much in about 40 years.
         
        One interesting item is the Spring transaction API, which does not include support for remote transactions.  I expect they are aiming at the 80% case, which is that 2PC is most often used to coordinate operations between a transactional queue manager ( e.g. JMS) and a database. 
         
        The way this goes is that to have a transaction at all you need a transactional resource manager, which includes pretty much every database management system and most queue management systems.  I would say that the vast majority of database operations are transactional today.  A transactional resource manager has its own embedded transaction manager that implements the start and commit/rollback commands.
         
        Once you have two different transactional resource managers, you need an independent transaction manager to coordinate the work of the individual transaction managers embedded in each resource manager.  This is when 2PC comes into play, since the only way for an independent transaction manager such as OTS/JTS or DTC can coordinate the operations of multiple transactional resource managers is to use 2PC (well there are theoritically other ways it can be done but in practics 2PC is what's available).
         
        If you have a remote transactional resource manager you need to coordinate, then you are into remote 2PC, and this is a somewhat different kettle of fish.  I believe this is the particular aspect of 2PC you are cautioning against using without carefully evaluating the requirements. 

        I can give you a good example of why someone might want to do this - if there are geographical databases maintaining similar data (i.e. customer records) that need to be brought into consistency on a regular basis, it helps to have 2PC perform updates to both (or neither in the case of rollback) since the application users don't have to manually verify whether or not the databases are consistent.
         
        There is a long and somewhat tortuous history of attempts at establishing standards for both transaction managers and remote 2PC interoperability, and while I think it's fair to say that nothing has really achieved universal adoption WS-TX represents an improvement in the situation.
         
        I was on the committee that defined XA and we defined a lot of other things back then, including three styles of 2PC interoperability, none of which really took off.  XA remains the old X/Open DTP's biggest success, but it is not for interoperability across transaction managers, or even for remote coordination of transactional resource managers.  XA is what the local independent transaction manager uses to interact with local transactional resource managers.
         
        Eric
         


         
        ----- Original Message ----
        From: Anne Thomas Manes <atmanes@gmail. com>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Saturday, August 25, 2007 3:15:13 PM
        Subject: Re: [service-orientated -architecture] Teti on WS & XA

        There are many ways to implement transactional integrity, and as a general rule, it's best to avoid using a 2PC distributed transaction protocol if possible. 2PC transaction hold locks on resources until the transaction either commits or rolls back.Locking up resources for more than a few microseconds is typically considered a bad thing.

        If, in fact, a 2PC transaction is required, you certainly don't want to do so over a loosely coupled connection. I agree with the author that you probably don't want to use a web service invocation in the midst of a 2PC distributed transaction.

        But I question the author's contention that WS-Transaction is somehow different from XA. My interpretation of the spec is that WS-Transaction acts as a abstraction layer through which services indicate transaction information and events (create, enroll, commit, rollback, etc), but that the coordinator (defined by WS-Coordination) is really just a facade over a traditional XA manager.

        Maybe I'm wrong, though.

        Anne

        On 8/24/07, Gervas Douglas < gervas.douglas@ gmail.com > 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).

          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).

        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-AtomicTransactio n (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://searchwebser vices.techtarget .com/tip/ 0,289483, sid26_gci1268976 ,00.html? track=NL- 451&ad=600655&asrc=EM_NLC_ 2047205&uid=5532089





      • Michael Poulin
        I fully agree with Anne (while quite impressed with the family of WS-Transaction specs - to Mark Little and Eric N.) - Michael Anne Thomas Manes
        Message 3 of 19 , Sep 2, 2007
          I fully agree with Anne (while quite impressed with the family of WS-Transaction specs - to Mark Little and Eric N.)
          - Michael

          Anne Thomas Manes <atmanes@...> wrote:
          Eric,

          I agree completely with what you've just said. It's appropriate to use 2PC to coordinate a transaction that involves a single unit of work that must update multiple data sources -- but I strongly recommend that the single unit of work be performed by a single service. It is generally a bad idea to distribute that single unit of work over multiple services. As long as a single service performed the single unit of work, then SOAP doesn't need to be involved in the 2PC protocol.

          Anne

          On 8/29/07, Eric Newcomer <e_newcomer@yahoo. com> wrote:
          Hi Anne,
           
          I think what you mean is good advice, but "distributed 2PC" is imprecise since 2PC is distributed by definition.  2PC applies when the data updates are distributed among two or more data resources, whether local or remote.  And a local ( i.e. not over the network) 2PC is often a very good option.  Coding around that yourself is not a good idea.  The most common form is when someone needs to update a message queue and a database in the same transaction.  This is 2PC, and as I said 2PC is distributed.  A distributed transaction is one that involves more than one resource.
           
          I apologize if this seems kind of nit picky to you, but it seems like people are starting to advise against 2PC in any and all cases, and I don't think that's good advice.  I am sure that's not what you meant but there's so much misunderstanding out there about transactions that I think we need to be careful not to say something that could be misinterpreted.  I.e. 2PC is not inherently a bad thing.
           
          Eric

          ----- Original Message ----
          From: Anne Thomas Manes < atmanes@gmail. com>
          To: service-orientated- architecture@ yahoogroups. com
          Sent: Wednesday, August 29, 2007 7:11:10 AM
          Subject: Re: [service-orientated -architecture] Teti on WS & X

          Eric,

          Let me repeat what I said:

          There are many ways to implement transactional integrity, and as a general rule, it's best to avoid using a 2PC distributed transaction protocol if possible.

          and clarify what I meant:

          I agree that if you really need 2PC, then you should use 2PC. But my point is that using alternative designs, in many cases you don't really need 2PC. Keep in mind: if you really do need 2PC, then the system will be tightly coupled. My recommendation is that you should avoid using a SOAP invocation in the midst of a 2PC transaction. There are better protocols to use in this situation.

          Anne

          On 8/26/07, Eric Newcomer <e_newcomer@yahoo. com > wrote:
          Hi Anne,
           
          I would have to say it's not a good general rule to avoid 2PC if that's what you really need.  Coding around 2PC, or coding up something yourself that does the same thing is not easy, and risks all kinds of data inconsistency problems that are much harder to resolve manually.  It's a bit like the rule of thumb that says it's much more expensive to correct a mistake on a bank statement or phone bill than it is to ensure the bills are correct in the first place.  There may indeed be many cases in which 2PC does not make sense, but when it does there is really not a good substitute.  The cost of a protocol is only one part of the equation, and to in order evaluate whether or not 2PC fits your requirement you also have to look at the benefit part of the equation.
           
          As another general statement, I'd say that the "container managed" transaction approach has hurt rather than helped since it's so easy to misuse 2PC and turn it on when it isn't really needed.  I think this is especially true in the Java world because OTS/JTS forces an artificial choice between local and global transactions - meaning you can't code an object for a local transaction and then easily change it to a global transaction.  This resulted in the so-called "one phase commit optimization" which is not an optimization at all since an independent transaction manager has no role in a single resource transaction.
           
          One of the easiset things to forget in distributed computing when thinking about transactions is that a transaction has no meaning outside of an operation on data.  In other words, client side transactions are meaningless unless they perform an operation on data (you will get some argument about this but I emphasize it because people tend to forget that the purpose of the transaction abstraction is to group related operations on data).
           
          With regard to WS-TX, it is not so much an abstraction of XA as it is an abstraction of the transaction manager.  For Java this is the implementation of JTA (typically OTS/JTS) and for Windows this is DTC.  Both OTS/JTS and DTC use XA for integration with data resources, but XA is not a distributed API, it is local between the independent transaction manager and the transactional resource.
           
          Phil and I are in the middle of updating our TP book, "Principles of Transaction Processing" to include newer technologies and standards, but the fundamental principles haven't changed very much in about 40 years.
           
          One interesting item is the Spring transaction API, which does not include support for remote transactions.  I expect they are aiming at the 80% case, which is that 2PC is most often used to coordinate operations between a transactional queue manager ( e.g. JMS) and a database. 
           
          The way this goes is that to have a transaction at all you need a transactional resource manager, which includes pretty much every database management system and most queue management systems.  I would say that the vast majority of database operations are transactional today.  A transactional resource manager has its own embedded transaction manager that implements the start and commit/rollback commands.
           
          Once you have two different transactional resource managers, you need an independent transaction manager to coordinate the work of the individual transaction managers embedded in each resource manager.  This is when 2PC comes into play, since the only way for an independent transaction manager such as OTS/JTS or DTC can coordinate the operations of multiple transactional resource managers is to use 2PC (well there are theoritically other ways it can be done but in practics 2PC is what's available).
           
          If you have a remote transactional resource manager you need to coordinate, then you are into remote 2PC, and this is a somewhat different kettle of fish.  I believe this is the particular aspect of 2PC you are cautioning against using without carefully evaluating the requirements. 

          I can give you a good example of why someone might want to do this - if there are geographical databases maintaining similar data (i.e. customer records) that need to be brought into consistency on a regular basis, it helps to have 2PC perform updates to both (or neither in the case of rollback) since the application users don't have to manually verify whether or not the databases are consistent.
           
          There is a long and somewhat tortuous history of attempts at establishing standards for both transaction managers and remote 2PC interoperability, and while I think it's fair to say that nothing has really achieved universal adoption WS-TX represents an improvement in the situation.
           
          I was on the committee that defined XA and we defined a lot of other things back then, including three styles of 2PC interoperability, none of which really took off.  XA remains the old X/Open DTP's biggest success, but it is not for interoperability across transaction managers, or even for remote coordination of transactional resource managers.  XA is what the local independent transaction manager uses to interact with local transactional resource managers.
           
          Eric
           


           
          ----- Original Message ----
          From: Anne Thomas Manes <atmanes@gmail. com>
          To: service-orientated- architecture@ yahoogroups. com
          Sent: Saturday, August 25, 2007 3:15:13 PM
          Subject: Re: [service-orientated -architecture] Teti on WS & XA

          There are many ways to implement transactional integrity, and as a general rule, it's best to avoid using a 2PC distributed transaction protocol if possible. 2PC transaction hold locks on resources until the transaction either commits or rolls back.Locking up resources for more than a few microseconds is typically considered a bad thing.

          If, in fact, a 2PC transaction is required, you certainly don't want to do so over a loosely coupled connection. I agree with the author that you probably don't want to use a web service invocation in the midst of a 2PC distributed transaction.

          But I question the author's contention that WS-Transaction is somehow different from XA. My interpretation of the spec is that WS-Transaction acts as a abstraction layer through which services indicate transaction information and events (create, enroll, commit, rollback, etc), but that the coordinator (defined by WS-Coordination) is really just a facade over a traditional XA manager.

          Maybe I'm wrong, though.

          Anne

          On 8/24/07, Gervas Douglas < gervas.douglas@ gmail.com > 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).
            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).
          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-AtomicTransactio n (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://searchwebser vices.techtarget .com/tip/ 0,289483, sid26_gci1268976 ,00.html? track=NL- 451&ad=600655&asrc=EM_NLC_ 2047205&uid=5532089







          Luggage? GPS? Comic books?
          Check out fitting gifts for grads at Yahoo! Search.

        Your message has been successfully submitted and would be delivered to recipients shortly.