【IT专家网独家】如今，许多技术相信Web服务对于在不同的数据库环境下集成是一种非常恰当的机制。然而与大众看法相反的是，Web服务以及分布式(又名XA)事务是互补的，而不是相替代的技术。

　　最近我读了一篇文章，其中摘录如下：

　　尽管Web服务对于集成仅仅依赖于Web服务的异构数据源的集成非常有用，特别是对于比支持的XA以及构架限制还要负责得多的异构(也就是分布式)业务来说。除此之外，Web服务规范定义以及带来的实现都是全新的，并且因此不如XA成熟。如果购买了Web服务，那么就将需要许多其他的WS规范定义文档来开始构建XA提供的业务管理服务。

　　因此，我仍然同意Actional的首席技术官Foody的观点。“Web服务以及SOA长期的成功的直接原因就是他们能够在企业里至关重要的解决方案中被使用。因为一些关键应用程序需要业务整合，WS-TX (Web服务交易)使得这些应用程序能够成功地构建并且部署使用Web服务，并且不需要牺牲多厂商互操作性。”

　　商业和技术要求

　　在大多数情况下，所有的商业软件系统都来自于公司处理过程的要求。即使流行的概念“企业服务总线”，我也敢断定，源自一个高级商业分析家的PowerPoint演示过程，以解决合并和收购活动后失调的企业环境。

　　而且，业务流程分析家们不应该在一个新的应用程序的构想阶段被一个流程设计中的技术特性所妨碍，即使需求分析表明需要在以前的应用程序中异构交易。毕竟，这是XA该做的。

　　我最近的一个项目能够看作对于有五年历史的J2EE应用程序来说有一个重大的进步，一个J2EE应用程序在现在的标准下是部分的服务总线以及部分的业务流程管理。设计这个应用程序是为了在一个大的保险公司里面集成并且统一一些管理系统。

　　这些集成点正处在个人声明交易水平，因此工作流业务内部的一致性对于整体的“企业级”的系统保持内部的一致性显得至关重要。基于这些需求以及定义的逻辑工作的单元(见图：逻辑工作单元1和2)，最好的保证业务完整性的解决办法对我们来说就很清楚了，那就是开发一整套XA风格的业务。当一些分析家们建议一整套Web服务能够完成同样的目标的时候，使用那个架构还有一些限制条件，我们以后将会再讨论。

　　XA风格的分布式业务

　　此XA接口是一个成熟的协议，不管是使用db2，Oralcle还是JMS(一个XA的接口到一个物理队列)作为基本的数据源，数据源主要作为逻辑的交易，可以发送和收回。使用一个XA风格的交易，程序员不再需要关注修改业务代码，修改业务代码经常是自然的错误，在不知道的应用程序范围的SQLExceptions或者Java运行时异常。

　　因为有了帮助很大的XA技术的支持，程序员可以更关注于简单地创造很小的业务代码，而让XA资源管理者去处理收回和发送逻辑。如果没有XA的帮助，一旦这些分散的资源中的某一个失败了的话，程序员就需要找到一个有效的办法来回收分布式的业务，而不是找到一个标准的机制。或者，程序员可能开发一个乐观的模型并且假设他的代码可以永远运行一直到他/她离开那个项目组。

　　根据开源组织的X/开发分布式业务处理模型中的XA规范定义文档——这个模型定义了一个应用程序怎样使用一个业务管理从而在多个资源管理者之间协调分布式业务，任何遵守XA规范定义的资源管理者都能够参与到XA业务管理者合作的业务中来，因此使得不同的厂商的业务产品可以一起工作。

　　高端的JEE应用程序服务器，例如，Oracle应用程序服务器，WebLogic以及WebSphere支持JTA(Java业务API)需要XA风格的业务。一个XA业务包括各种不同资源管理之间的协调，这是一个业务管理的职责。