InfoQ 从 Frank Cohen 的书《FastSOA》里摘录出一个章节进行了发布。趁着这个机会，InfoQ 对Frank Cohen 进行了一次访谈，Frank Cohen 是FastSOA 解决方案的创建者，访谈的议题关于当在中间层尝试使用XQuery 处理XML 消息时的可伸缩性以及文件对象关联映射。
InfoQ：你能简要地解释一下“FastSOA”背后的想法吗？
Frank Cohen：过去的 5-6 年，我一直在调查一个普通的 Java 开发者的选择会对最终应用可伸缩性和性能所产生的影响，这种选择的范围包括技术、协议和构建服务的模式。例如，Java 开发者现在有 21 种不同的 XML 解析器可供选择。每种解析器都有着自己的可伸缩性、性能和开发者开发效率。所以一个开发者的技术选择将在运行时方面产生巨大影响。
我关注过使用消息中间件来进行远程调用的分布式系统。后来又关注过基于 SOAP 的 Web Services。最近更多地关注 REST 和 AJAX。这些经验促使我考虑当使用应用服务器、企业服务总线（ESB）、业务流程执行（BPEL）和业务集成（BI）工具时 SOA 的性能和可伸缩性。通过所有的这些技术，我发现了一个一致的主题：在 XML 和 SOA 的汇聚点存在意义重大的可伸缩性和性能问题。
FastSOA 是一种测试方法学，同时也是用于找到并解决可伸缩性和性能问题的一套架构模式。这些模式告诉 Java 开发者，除了 Java 解决方案以外，还存在着本地 XML 技术，例如 XQuery 和本地 XML 持久化引擎，可以考虑使用。
InfoQ："Fast"是什么意思？
Frank Cohen：首先，让我描述一下问题的范围。Java 开发者现在开发基于 WEB 的软件有着很多的选择。我们都听说过的技术包括面向服务架构（SOA）、Web Services、REST 和 AJAX 等。虽然这些技术存在很多不同和相互竞争的定义，但我问过的大多数的 Java 开发者都期望通过使用编码数据（通常是 XML 格式）发送消息给本地或远程服务器上的其他对象来操作对象。
这些被互联的服务的本质意味着我们的软件需要处理消息，这些消息可以是从小到大的，也可以是从简单到复杂的。比如随着消息的大小逐渐增长，使用 SOAP 接口和 XML 流解析器（StAX）来对该简单消息模式进行处理时，性能就会出现严重的问题。一台先进且昂贵的多核服务器每秒钟可以轻松处理 40 到 80 个网页，但却只能每秒钟处理 1.5 到 2 个 XML 请求。
在不采用某种补救方法的情况下，因为 XML Schema 和 XML 解析器之间的不匹配，Java 软件在处理 XML 数据时经常慢的像在爬行一样。例如，我们查看了一个 SOAP 堆栈，堆栈显示有 14385 个 Java 对象被用来处理一条请求消息，而这条消息只有 7000 个字节大小，包含了 200 个 XML 元素。
当然，把我的工作命名为 SlowSOA 听起来不那么好。FastSOA 提供了解决这些可伸缩性和性能问题的方法。FastSOA 使用本地 XML 技术在中间层提供服务加速、转换和服务绑定。例如，XQuery 引擎提供 SOAP 接口给服务以对请求解码，把请求数据转换成一些更有用的东西，然后把这个请求路由到一个 Java 对象或是其他服务中去。
InfoQ：在 Java 里处理 XML 数据绑定，一个可选择的方法是使用 XML 技术，例如 XPath 和 XQuery。为什么要使用 XQuery？为什么不只使用 Java 技术？
FC：我们都有着相同的基本目标：
- 在 SOA 和 XML 环境里的良好可伸缩性和性能。
- 软件代码的快速开发。
- 当外部环境和需求发生变化时，软件代码良好的灵活性和可维护性。
在 SOA、Web Service 和 XML 领域，我发现通常的 Java 技术选择都没有达到上面三个所有的目标。
Chris Richardson 在他的书《POJOs in Action》里解释了领域模型模式。领域模型是构建 WEB 应用一个流行的模式，它也被许多开发者用来构建 SOA 复合应用和数据服务。
领域模型把应用划分成三个部分：表现层，应用层和数据层。表现层使用 Web 浏览器附加 AJAX 和 RSS 能力来创建富用户界面。浏览器把 HTML 和 XML 合并起来对应用层发起请求。同样在表现层，可以使用一个基于 SOAP 的 Web 服务界面来容许用户系统直接访问系统功能，例如一个制造业者服务里的部件排序功能。
在应用层，EJB 或者 POJO 实现业务逻辑来响应请求。EJB 或者 POJO 使用 MVC 框架，例如，Spring MVC，Struts 或者 Tapestry，生成 Web 响应界面来响应请求。MVC 框架使用 O/R 框架，例如 Hibernate 或者 Spring，来从关系数据库里存储和获取数据。
我发现了一些当在 XML 环境下使用领域模型时会引起可伸缩性和性能问题的地方：
- 当 XML 消息大小和复杂性增加时，XML-JAVA 映射需要越来越多的处理时间。
- 每一个请求都需要操作整个服务。例如，许多时候用户将比订单状态变化更快地检查订单。如果系统记录了最近大多数响应的 time-to-live 期限，那么它将不必操作所有的服务，来产生大多数先前已经缓存的响应。
- 供应商应用要求 XML 形式的请求消息。先前由 EJB 处理的由 XML 转换为 Java 对象的数据现在作为请求消息的一部分又需要重新转换为 XML 元素。许多 Java 到 XML 的框架，例如，JAXB，XMLBeans 和 Xerces 等都需要处理器密集地执行转换。并且，我发现使用这些框架需要我去写一些困难和复杂但不必要的代码来完成这些转换。
- 服务使用 ORM 框架将订单信息持久化到关系数据库里。ORM 框架把 Java 对象转换为关系行集合并且对多个表执行 JOIN 操作。随着对象的复杂和大小的增加，我发现许多开发者需要调试 O/R 映射来提高速度和性能。
我绝不是主张你抛弃现有的 Java 工具和系统。有很多方法我们可以用来解决这些问题而不用抛弃任何东西。例如，我们可以使用 XQuery 和一个本地 XML 数据库引入一个中间层服务缓存从而减轻和加快许多 XML 领域特定请求。
把 FastSOA 架构作为一个中间层服务缓冲使用的优点在于它能够存储任何一般类型的数据，以及它能够从一堆复杂的参数里快速匹配相应的服务，从而更有效率地决定什么时候一个服务请求可以从缓存中获得服务。FastSOA 中间层服务缓冲架构通过维护两个数据库实现这一功能：
- 服务数据库。保存着被缓存的消息负荷。例如，服务数据库保存一则 XML 形式的 SOAP 消息，一个 HTML 网页，一条短消息的文本，以及一张 JPEG 或者 GIF 图片的二进制数据。
- 策略数据库。保存着业务逻辑单位，这些逻辑查找服务数据库内容并在处理请求时做出决定：是从服务数据库里获取数据以服务请求还是直接把这个请求发送到应用层。例如，收到一个 SOAP 请求时的策略，这个策略会在 SOAP 消息头里验证安全信息来确认用户也许可以接受先前缓存的响应数据。在另外一个例子里，策略从一个股票价格行情的引用里检查 time-to-live 的值，由这个值决定是否从服务数据库里获取股票价格来响应请求。
FastSOA 使用 XQuery 数据模型来实施策略。XQuery 数据模型支持任何一般类型的文件和用于获取和构建文件的任何一般动态参数。用于实施策略的 XQuery 引擎容许 FastSOA 高效率地评估服务缓存里数据的共同标准，同时 XQuery 的灵活性允许用户接口驱动模式的模糊匹配，从而高效率地表现缓存。
由于性能和可伸缩性的原因，FastSOA 使用本地 XML 数据库技术实现服务和策略数据库。关系数据库技术也可以提供满意的性能，但前提是所存储的 XML 消息 schemas 一致，并且消息的大小不大。
InfoQ：这样能够对性能提供什么样的好处？
FC：我做过一个可伸缩性测试来比较本地 XML 技术和 Java 技术，用它们各自实现一个接受 SOAP 请求的服务。
在这个测试里，请求消息的大小在三个水平中变化：68k，202k，403k 个字节。测试测量了从客户发起请求到响应的来回时间。测试的结果来自于一台配备有双 CPU 3.0 GHz Intel Xeon 处理器的服务器，该服务器运行于一个千兆位的以太网里。我用两种方式实现代码：
- FastSOA 技术：使用本地 XML 技术提供一个 SOAP 服务接口。使用了一个商业的 XQuery 引擎暴露出一个 socket 接口来接收 SOAP 消息，解析消息内容，并且装配响应的 SOAP 消息。
- Java 技术：使用由一个流行的商业 Java 应用服务器生成的 SOAP 绑定代理接口。一个简单 Java 对象从绑定里接收 SOAP 请求，使用 JAXB 创建的绑定来解析消息内容，并且使用绑定来装配响应的 SOAP 消息。
结果显示当使用 FastSOA 技术暴露服务接口时性能比使用 Java 技术有了 2 到 2.5 倍的提高。FastSOA 方法之所以能更快是因为它避免了大量的映射和转换，这些映射和转换在 Java 绑定处理 XML 数据时执行。XML 数据越复杂越大，性能的提升越明显。
InfoQ：在使用了更新的 Java 工具后，这些问题不会更容易地被解决吗？
FC：我记得听到过 Tim Bray，XML 的联合发明者，在 2005 年鼓动了一大群软件开发者写出他们应用中所需要的任何的 XML 格式。看看现在存在的所有与 REST 和 AJAX 相关的不同的 XML schema。它们全部是不同的，并且大多数都随着时间的变化，目标正在发生变化。结果，当应用或是服务与 Java 和 XML 一起使用时，常常需要面对以下三个无法改变的事实：
- XML schema 没有一个管理者。所以一个任意 schema 的消息可以在任何时候到达你的对象。
- 消息可以是任意大小。例如，一些消息可以非常小（小于 200 个字节），同时一些消息可以非常庞大（大于 10 兆字节）。
- 消息使用的 schema 可以复杂也可以简单。例如，消息 schema 可以有非常少的层次（每个元素少于 5 个子元素），同时其他消息可以有非常多的层次（每个元素多于 30 个子元素）。
我们需要一种简单的方法来处理任意大小和复杂的 XML 数据，并且随着时间的流逝当 XML 发生变化时能够轻松地维护。这种变化的场景正是 XQuery 被创造出来去解决的。
InfoQ：FastSOA 仅仅是突出提高服务接口性能吗？
FC：FastSOA 处理以下问题：
- 通过减少对 Java 对象的需求同时更多地使用本地 XML 环境提供 SOAP 绑定，解决 SOAP 绑定性能问题。
- 引入一个中间层服务缓存加速、转换和联合 SOA 服务。
- 使用本地 XML 持久化来解决 XML，对象和关系数据库的不匹配性。
FastSOA 是一种架构，提供了中间层服务绑定，XQuery 处理器和本地 XML 数据库。绑定是一个本地的和基于 XML 数据流的处理器。XQuery 处理器才是真正的中间层，它解析传入的文档，确定事务，与本地的服务交互获得存储的数据，把数据序列化为 XML 并且把数据存储到缓存中同时记录下 time-to-live 期限。同时面向 XML 设计的 XQuery 和本地 XML 数据库处理非 XML 的数据，包括图片、二进制文件和附件等。XQuery 处理器另一个同等重要的优点是能够定义策略，这些策略被中间层用来在运行期操作数据。
在客户要求一种特定的 schema 而服务只能提供一种不同和不匹配的 schema 作为响应时，FastSOA 提供了中间层转换。FastSOA 中间层里的 XQuery 在不匹配的 schema 类型之间转换请求和响应。
最后，当一个服务一般需要从多个服务的响应里组合出一个响应时，FastSOA 提供了服务联合。例如，一些出版者比如《纽约时代周刊》使用 RSS 协议提供新的文章。FastSOA 可以通过 RSS feeds 把发表在一个网站上的新闻评论文章和刚刚发生的新闻故事关联起来。这个也可以在你的应用里实现，但最好是在 FastSOA 里做这件事，因为内容（新闻故事和 RSS feeds）通常都包含 time-to-live 值，所以非常适合 FastSOA 的中间层缓存。
InfoQ：你能详细说明在将 XML 与对象和关系数据库结合时你所发现的问题吗？
FC：我推荐使用本地 XML 数据库来持久化 XML，但其实也可以成功地使用关系数据库。需要做的是仔细关注你的应用的 XML 的质量和本质。例如，XML 已经被广泛地用于表现文件、文件格式、互用性标准和服务组织等。甚至有的软件开发社区讨论，描绘了以 XML 形式的服务管理并且基于 XQuery 方法进行操作。在一个到处都是 XML 的世界，我们开发者必须问这样一个问题：使用关系持久引擎保存 XML 数据是否是有意义的？请考虑下面这些共同的问题：
把 XML 数据保存到关系数据库里究竟有多难？
把关系数据给一个需要 XML 数据的服务或对象究竟有多难？我的数据库能不能无损地恢复和最初 XML 数据一致的 XML 数据？我的数据库在操作存储在数据库中的 XML 数据时能否提供可以接受的性能和可伸缩性？哪些数据库操作（查询，更新，复杂的连接）在性能和资源的消耗（cups，网络，内存，存储空间）方面是最大的开销。
你对这些问题的答案将形成一个标准，一个使用关系数据库是否有意义的标准，或者也可能没有。对关系引擎来说一个可供的选择是本地 XML 持久化引擎，例如 eXist，Mark Logic，IBM DB2 V9，TigerLogic 等等。
InfoQ：PushToTest 方法学背后的主要想法是什么？它与 SOA 的关系是什么？
FC：很少有企业、机构和组织拥有一整套测试服务性能和可伸缩性的方法，这经常让我感到惊讶。一家财富 50 强公司会雇佣一个夏季实习生在他其他工作的空隙进行了一些性能测试，这个测试用来检查和理清在他们 SOA 应用中存在的可伸缩性问题。那是他们进行可伸缩性和性能测试的全部方法。
一旦企业形成一套包含以下几个方面的测试方法，连续的可伸缩性和性能测试就会产生企业价值。
- 选择正确的测试用例集。例如，一个多接口和大体积的服务的测试与一个处理周期性大消息量请求的服务的测试是不同的。测试需要考虑最终用户使用服务的目的和提供可供行动参考的知识。
- 正确的运行测试。理解测试一个服务的可伸缩性和性能需要一打到数百个测试用例的运行。测试结果的特别记录是令人不满的。有很多自动化测试工具并且经常是免费的。
- 当分析结果时，做出正确的结论。理解一个服务的可伸缩性和性能需要理解如何测量吞吐量，当服务消费者增加消息的大小和复杂性和增加并发请求时如何以每秒钟多少个事务（TPS）来测量吞吐量。
所有这些要求的知识比一个特别的方法达到有用和可操作的过程要多的多。所以我创建并发布了 PushToTest 测试方法学来帮助软件架构师，开发者和测试人员。在 PushToTest.com 网站有对 PushToTest 的描述并且我还维护了一个叫 PushToTest TestMaker 的开源自动化测试工具来自动化和操作 SOA 测试。
PushToTest 使用我们的方法和工具给用户提供全球化服务，并以此来提供 SOA 可伸缩性知识。我们经常能成功地说服企业或供应商为了研究的方便与 PushToTest 签订合同，并让我们在一个开源许可下发布这些研究。例如，SOA 性能工具包含了内码样式，XML 解析器和使用案例。这个工具可以在 http://www.pushtotest.com/Downloads/kits/soakit.html 免费下载，旧的版本在 http://www.pushtotest.com/Downloads/kits 。
InfoQ：非常感谢接受我们的采访。
Frank Cohen 是测试和优化以 SOA 和 Web Service 设计开发的软件领域的领导者。Frank 是一家公司的 CEO，并且是 PushToTest 的创建者和 TestMaker 的发明者。TestMaker 是一个开源的自动化测试工具，它帮助软件开发者、QA 技术员和 IT 经理理解和优化他们系统的可伸缩性，性能和可靠性。Frank 还是好几本关于优化信息系统方面书籍的作者（2004 年 Prentice Hall《Java Testing and Design》，2006 年 Morgan Kaufmann《FastSOA》）。在过去的 25 年他领导开发了一些在软件工业里最成功的产品，包括 Norton Utilities 的 Macintosh 版本，Stacker 和 SoftWindows 等。他最开始给微型计算机写操作系统，帮助建立电子游戏产业，帮助建立 Norton Utilities，领导苹果公司在中间件和互联网技术的研发，并且曾经是 SUN 社区服务器的主要架构师。他和别人共同创办了 Inclusion.net (OTC: IINC) 和 TuneUp.com(现在是 Symantec Web Services)。你可以通过 fcohen@pushtotest.com 和 http://www.pushtotest.com 联系他。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论