【IT168 技术文章】

    面向服务架构(Service-oriented architecture，SOA)可以通过J2EE和使用企业服务总线(ESB)硬件部分的XML流程实现， RouteOne公司技术指导T.N. Subramaniam说到……

    由为其经销权提供基于服务的汽车借贷过程的主要汽车制造厂商共同尝试的RouteOne也是IBM公司将其DataPower XML流程应用程序定位到一个ESB上的产物。使用IBM公司的DataPower工具箱来加快XML流程的速度，Subramaniam介绍说他正在将一个老化的企业应用程序的集成系统转化成一个使用XML流程的SOA以及J2EE。

    这个拥有五年历史的公司的系统为一个汽车购买者采用基本的信用应用程序信息，验证它并且将商业规则应用于其中，然后同时中间件发送信息给出借方。这个出借方处理这个应用程序并且再往回发送一个响应给经销方。

    “为了加快这个过程的处理速度我们拥有数量庞大的Web服务，”Subramaniam说到，“比方说，得到客户的征信社的分数和信用报告。Web服务可以花大力气安排以实现它。”

    所有的系统都是为了提供多种不同方法而设计的。最终用户应用程序的信息能够在代理方得到，包括Web浏览器前台到资金系统，以及大量来自出借方和征信社的系统，他说到。尽管Web服务携带着XML格式的数据信息，它还是不得不被转化成Java对象，从而被J2EE应用程序所处理，他解释到。

    “我们过去经常使用企业集成(enterprise integration)产品作为消息系统的后台，” Subramaniam说到，“我们现在正在将其迁移到使用IBM公司的DataPower上来。”

    即使是在老的EAI系统中，RouteOne还是使用了最早的DataPower XML应用程序，首席构架师说到。

    “当DataPower还处于beta阶段的时候，我们就使用DataPower了。”他谈到最早的实现的时候说到。“我们使用DataPower是因为我们对于证明我们的系统是很有效的拥有相当紧迫合理的需求。我们为客户交换相当可靠的财政数据信息，因此安全系数会非常高。所有我们选择它作为XML数字签名。我们所有的进来以及出去的消息中，绝大多数都是数字签名的。在过去(五年以前)确实没有一个软件解决办法足够快速地解决XML数字签名。因此我们发现了DataPower并且我们购买了XS-40设备，XS-40设备是XML的安全包。”

    当原始的系统是恰当的时候，Subramaniam开始寻找一个方法来处理更多的过程，从而更好地利用XML和XML标准，并且尽可能少地利用J2EE来将XML数据转换成Java对象。

    “在很长一段时间，我认识到所有这些业务，不管是编组的还是未编组的，在处理XML方面效率都不够高。”他回忆到说。“大多数微软公司以外的企业基本上都使用Java应用程序。所以趋势就是以Java的思想考虑问题，因为你已经习惯于它了。因此人们正常情况下会采用XML，将其转换成一个Java对象来用多种方式处理此过程，并且在流程中将其交给下一步流程。”

    在寻求一个更高效的办法来处理XML流程的时候，Subramaniam说到，他有一天突然有很多想法——就像一阵头脑风暴一样，在和一个同事讨论这个问题的时候。

    “我认识到XML架构在过去是非常好的。”他说到。“你拥有XQuery。你拥有XML安全协议，XML图例。因此为什么不直接像处理XML一样处理XML呢。大多数人不这样做的原因就是因为XML流程使得CUP和内存占用，这取决于你如何实现它。”

    由于其偶然发现的大脑风暴，IBM公司的代表们已经同他讨论过一个想法，这个想法是使用下一代DataPower工具包作为ESB来解决XML流程中的CUP和内存问题。

    “因此我们和IBM交流，并且他们研制出了一个叫做X150的新产品，他们将这个产品定位为一个硬件级的企业服务总线。”他说到。“此产品拥有一个企业服务总线应该具有的所有功能特性。它能够路由和传输，以及验证数据。它能够和许多事物通信。它能够和LDAP服务器以及SQL数据库通信。并且它还能够与任何SOA或者Web服务应用程序通信。”

    RouteOne从DataPower XS40升级而来，DataPower XS40过去用来负责X150的安全性能，并且XML流程在硬件中被处理。这就允许了Subramaniam最小化J2EE应用程序流程的数量。

    “我们在应用程序到达J2EE层之前就决定把一些硬件包推出，从而让消息能够验证并且传输。”他说到，“它路由到正确的网关，路由到正确的服务端。我们在硬件中完成那些功能。”

    这使得他可以避免以Java为中心的实现SOA的方式，而他发现这种方式“非常笨重”。他举了一个例子说明他为什么相信基于J2EE的SOA是存在问题的。

    “我们正在使用的XML有效载体，在一些情况下我们不得不将其配置成一个Java对象。”他解释到说，“它通常工作的方式是你取得图例并且运行一个编译器来生成类。在我们的例子中它生成100个类。很难说清楚所有这些类的功能是什么。”

    Subramaniam设计的新的构架模型使用最少的Java对象来处理XML。

    “我们使用一种对象绑定框架，”他解释到说，“我们使用XSLT来在硬件中传输它。因此当XML来到的时候，所有应用到的验证服务，所有商业规则，所有的传输都完成了。所以我们得到一个干净的XML，这个XML非常精确地符合我们想要的那个。因此我们能够生成一个Java调用，并且我们拥有一个对象。我们没有编译过的class文件。我们没有映射。什么都不需要。”

    这个方式绕过了J2EE流程，非常著名的Richard Monson-Haefel of the Burton Group Inc.的分析家们警告说，它并不适合SOA。

    “我们基本上相信你应该能够通过XML处理XML流程，”Subramaniam说到，“如果你拥有一个基于硬件的企业服务总线，你就能够高效地实现它。”

    尽管在RouteOne的SOA环境中还是有J2EE层，它和XML的交互已经被最小化了。

    “举例说，”他说到，“如果你收到一个消息，并且这个消息在某种验证的时候失败了，J2EE层甚至根本不知道它的存在，因为我们已经将它返回给了最开始的在内部的服务。”