“因此我们和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层甚至根本不知道它的存在，因为我们已经将它返回给了最开始的在内部的服务。”