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联系他。
