如果你正在吹捧面向服务的架构，Frank Cohen相信你将需要改变一下步调才能成功地从实验品走向的产品。他的项目FastSOA是一种不同的架构，它利用了XML查询语言(XML Query Language，XQuery)，并在中间层使用了本地XML数据库来处理J2EE应用服务器的可扩展性和性能问题。FastSOA将用并行的方式运行企业级现有架构。

　　Cohen是TestMaker 开源测试工具及框架的主要维护人员，还是位于加州Irvine的Raining Data Corp负责解决方案工程的主管。他说，根据他的测试，用当今的商用或开源J2EE应用服务器实现的Web services只能达到每秒1.5到2.0 个事务(TPS)，他认为对产品需求还是不够好。他说:“我们期望FastSOA的性能能够在15到20TPS之间，并期望它能在优化SOA性能上起到很大的作用。”

　　Cohen已经在过去三年半内对很多J2EE应用服务器进行了测试。他说:“当我两年前为General Motors运行Web services性能测试时，糟糕的性能扼杀了两个项目。SOA开发人员没有工具让实验品变成产品。”Cohen说他期望SOAP协议栈和工具能得到改进，但是他说:“尽管WebLogic、WebSphere、JBoss及其它被测试的服务器已经生产了两代，但在基于SOAP的Web services方面性能还是很慢。”

　　Cohen指出，FastSOA架构解决了两层问题。他说:“SOAP绑定的应用服务器使性能下降。而且人们没有易用的工具来开发有效的、能扩展的、性能高的SOA。根本不可能把缓存机制引入SOA，或者有某个策略系统让你知道是否你已经处理这种请求。”

　　Cohen说:“企业不必抛弃他们的应用服务器或数据库来使用FastSOA。可以通过添加一个中间持久层来获得性能和可扩展性。在这一层中，可用XQuery处理到达的Web services请求，而且还可以用本地XML数据库做缓存。这将能加速服务。”

　　他还指出FastSOA不需要Raining Data产品。他说:“有很多开源技术能用来实现FastSOA。”

　　FastSOA可用于Java和. NET开发，但Cohen说他还没有对 .NET Web services做性能测试，所以他无法说明性能问题。但是，他说:“.NET用文档字符编码作为基本的SOA工具，这给了.NET很大好处。Java中使用的则是SOAP RPC编码。从研究中我们发现SOAP RPC不好测量，而文档字符编码则可以测量，让 . NET有了优势。”

　　Cohen承认不是每个人都认同W3C的规格说明书XQuery。他说:“存在着两种观点，从软件开发人员的角度看，它是SQL的高级形式。而另一种观点就是XQuery是一种的新的开发平台，和Java与.NET刚开始的时候差不多。把它视为高级SQL的人认为它花了太多时间也没有成为标准。因为在开始之后这么多年了，我们依然没有一个1.0版本的标准。”

　　Cohen说:“尽管成为标准的步伐很缓慢，我还是相信XQuery，因为本地XML环境要比任何Java和.NET等对象技术有优势。”

　　Cohen正在测试FastSOA。而Raining Data则已经委托进行了一项研究，该研究将用Raining Data的TigerLogic作为XQuery引擎和本地XML数据库。“我们将对Mark Logic(一种XML服务器)、eXist(一种开源本地XML数据库)进行测试，还将把Oracle 10g作为底线与相关服务技术进行比较。”测试将跑在BEA WebLogic服务器上，Cohen认为它是五种包括它自己先前测试的应用服务器中表现最好的。开发人员正在为测试编写代码，Cohen希望能在11月底完成所有测试。他说今天晚些时候还有发布FastSOA性能工具包的计划。

　　尽管FastSOA还不是正式的开源项目，不过Cohen说Raining Data将对此作出决定，但开发人员和架构师可以在www.xquerynow.com网站上提供反馈，它是Raining Data的一个在线社区。访问者还能下载Cohen的即将在2006年出版的新书《FastSOA》。