用XML、XQuery和本机XML数据库技术加速SOA

【 技术文章】

    很多 SOA 实现都依赖于用 XML 定义的消息格式。结果，消息模式可能变得非常复杂、不兼容、难以维护，甚至造成严重的可伸缩性和性能问题。在本文中，Frank Cohen 将介绍如何通过在 SOA 中间层使用 XML、XQuery 和本机 XML 数据库技术来提高 SOA 性能的战略和技术。

    很多软件架构师在面向服务体系结构(SOA)设计中使用 XML，虽然没有一种 SOA 标准要求在 SOA 中使用 XML 或者提供相关指南。因此，软件开发社区做了很多实验和调查来发现定义服务端点和消息定义(模式)的最佳方式。这些方法大多数都会带来了糟糕的性能和可伸缩性。

    比如，最早提出用 SOA 实现 ebXML 的 General Motors Corp.，其最初的设计使用的是 Universal Business Language (UBL)，建立的 XML 消息有 150,000 字节到 10 兆字节甚至更大。2004 年，我的性能测试公司 PushToTest 认为当时的 Java™ 应用程序服务器没有提供足够的吞吐量，在 GM Web Services Performance Benchmark 研究中提出了可伸缩性和性能问题。

    当时基于 XML 的 Web 服务技术还非常新，我认为新一代应用程序服务器技术会解决性能问题。但大部分问题仍然存在。

    Web 服务吞吐量问题和复杂的 XML

    2005 年，PushToTest 完成了一项新的 SOA 性能研究(请参阅参考资料)表明，在处理复杂的 XML 消息时，使用当前 Java 应用程序服务器构建的应用程序其性能很差，不足以投入生产。是发现的问题和以前研究中的问题相同:

    简单对象访问协议(SOAP)绑定(代理)低效而缓慢。
    每次请求都需要一组全新的资源(对象、CPU 和网络带宽)来处理响应。没有缓冲模式。
    使用关系数据库技术存储 XML 数据非常慢而且没有可伸缩性。
    为了了解这三个问题，设想一下软件开发人员如何使用 J2EE 应用程序服务器工具构建和部署 XML 服务。

    图 1. WSDL 定义的例子

    虽然可以使用使用不同技术建立基于 XML 的 Web 服务，但我发现多数开发人员更愿意从服务的 Web Services Description Language (WSDL) 定义开始。Java 应用程序服务器提供了输入 WSDL定义和生成代理类的工具。代理器接收 SOAP 请求并把请求转发给 Java 对象或 Enterprise Java Bean (EJB) 进行处理。SOAP 绑定(代理器)是一种 Java 类，可通过 servlet 接口调用它。

    图 2. Java 方法调用

    图 2 说明了 Web 服务消费者如何向服务发出 SOAP 请求。SOAP 绑定对 SOAP 消息体中的 XML 内容进行反序列化。这个过程需要进行大量的处理，非常复杂，因为消息体常常包含复杂的数据类型。比如，消费者可能向服务发送包含多个值的散列表。SOAP 绑定需要解码散列表的内容，对每个值创建 Java 对象的实例。散列表还可能包含其他散列表，因此解码 SOAP 消息内容不是一件容易的事。如果不相信的话，请看一看 Apache Axis 反序列化器的源代码。

    SOAP 绑定实例化包含 SOAP 消息体内容的 Java Request 对象。SOAP 绑定调用目标类中的目标方法，并将 Request 对象作为参数传递。目标 EJB 或 Java 对象提供所有必要的处理来建立对请求的响应。SOAP 绑定将 EJB 或 Java 对象返回的值序列化到 SOAP 响应消息中。SOAP 绑定将响应对象中的值解码成能够序列化到 SOAP 响应消息中的值需要经过同样复杂的过程。

    通过研究用流行的 Java 应用程序服务器工具创建的 SOAP 绑定，我发现了以下问题:

    应用程序服务器工具创建的 SOAP 绑定效率很低。比如，我发现某些 SOAP 绑定创建 SOAP 请求的多个副本，每个请求都实例化为 String 对象 —— 这样做并没有明显的理由。一些 SOAP 绑定创建了 15,000 个 Java 对象来反序列化消息体中包含 500 个元素的 SOAP 请求。
在配备有双 CPU 3.0 GHz Intel Xeon 处理器的服务器上，我发现在处理有效负荷 10,000 字节、包含 50 个元素的简单 SOAP 消息时，每秒处理的事务为 15 到 20 个(TPS)。随着 SOAP 消息复杂性和大小的增加，我发现会造成明显的伸缩性和性能问题。有效负荷 100,000 字节、包含 750 个元素的 SOAP 消息会把吞吐量降低到 1.5 TPS。SOAP 消息体中元素个数越多，每个元素嵌套越深，问题就会越严重。
性能问题在 SOA 设计中会引起连锁反应。SOA 是一种组件软件重用技术。一个服务通常调用其他服务来确定对消费者请求的响应，从而形成一个调用链。

    图 3. 消费者

    不仅仅是一个服务的性能问题，每个服务在序列化、反序列化请求和响应的时候都会增加同样的开销。随着服务调用层次的增加，性能问题也成倍增加。

    加快 SOA 失去的机会

    除了 SOAP 绑定代理速度慢的问题，SOA 设计还常常忽略或者忽视另外两个问题。

    首先，SOA 设计常常忽视了用中间层服务缓冲来提高 SOA 性能的可能性。比如多数 SOA 设计中的 XML 模式都定义了了响应的 time-to-live 值。在这种情况下，缓冲服务响应并在服务再次收到同样的请求时重新使用缓冲的响应是一种提高 SOA 服务性能的合理而适当的方法。

    其次，在 SOA 性能测试中，我尝试了各种不同的 XML 消息解析方法，其中包括 Streaming API for XML (StAX)、XML 绑定编译器、Java Architecture for XML Binding (JAXB) 和 Document Object Model (DOM) 技术。一些技术的性能要优于另一些。比如，很多 StAX 解析器能够提供比 DOM 解析器快 2 到 10 倍的性能。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!