| 很多软件架构师在面向服务体系结构（SOA）设计中使用XML，虽然没有一种SOA标准要求在SOA中使用XML或者提供相关指南。因此，软件开发社区做了很多实验和调查来发现定义服务端点和消息定义（模式）的最佳方式。这些方法大多数都会带来了糟糕的性能和可伸缩性。
比如，最早提出用SOA实现ebXML的GeneralMotorsCorp.，其最初的设计使用的是UniversalBusinessLanguage(UBL)，建立的XML消息有150,000字节到10兆字节甚至更大。2004年，我的性能测试公司PushToTest认为当时的Java?应用程序服务器没有提供足够的吞吐量，在GMWebServicesPerformanceBenchmark研究中提出了可伸缩性和性能问题。
当时基于XML的Web服务技术还非常新，我认为新一代应用程序服务器技术会解决性能问题。但大部分问题仍然存在。
Web服务吞吐量问题和复杂的XML
2005年，PushToTest完成了一项新的SOA性能研究（请参阅参考资料）表明，在处理复杂的XML消息时，使用当前Java应用程序服务器构建的应用程序其性能很差，不足以投入生产。是发现的问题和以前研究中的问题相同：
·简单对象访问协议（SOAP）绑定（代理）低效而缓慢。
·每次请求都需要一组全新的资源（对象、CPU和网络带宽）来处理响应。没有缓冲模式。
·使用关系数据库技术存储XML数据非常慢而且没有可伸缩性。
为了了解这三个问题，设想一下软件开发人员如何使用J2EE应用程序服务器工具构建和部署XML服务。
图1.WSDL定义的例子
虽然可以使用使用不同技术建立基于XML的Web服务，但我发现多数开发人员更愿意从服务的WebServicesDescriptionLanguage(WSDL)定义开始。Java应用程序服务器提供了输入WSDL定义和生成代理类的工具。代理器接收SOAP请求并把请求转发给Java对象或EnterpriseJavaBean(EJB)进行处理。SOAP绑定（代理器）是一种Java类，可通过servlet接口调用它。
图2.Java方法调用
图2说明了Web服务消费者如何向服务发出SOAP请求。SOAP绑定对SOAP消息体中的XML内容进行反序列化。这个过程需要进行大量的处理，非常复杂，因为消息体常常包含复杂的数据类型。比如，消费者可能向服务发送包含多个值的散列表。SOAP绑定需要解码散列表的内容，对每个值创建Java对象的实例。散列表还可能包含其他散列表，因此解码SOAP消息内容不是一件容易的事。如果不相信的话，请看一看ApacheAxis反序列化器的源代码。
SOAP绑定实例化包含SOAP消息体内容的JavaRequest对象。SOAP绑定调用目标类中的目标方法，并将Request对象作为参数传递。目标EJB或Java对象提供所有必要的处理来建立对请求的响应。SOAP绑定将EJB或Java对象返回的值序列化到SOAP响应消息中。SOAP绑定将响应对象中的值解码成能够序列化到SOAP响应消息中的值需要经过同样复杂的过程。
通过研究用流行的Java应用程序服务器工具创建的SOAP绑定，我发现了以下问题：
·应用程序服务器工具创建的SOAP绑定效率很低。比如，我发现某些SOAP绑定创建SOAP请求的多个副本，每个请求都实例化为String对象——这样做并没有明显的理由。一些SOAP绑定创建了15,000个Java对象来反序列化消息体中包含500个元素的SOAP请求。
·在配备有双CPU3.0GHzIntelXeon处理器的服务器上，我发现在处理有效负荷10,000字节、包含50个元素的简单SOAP消息时，每秒处理的事务为15到20个（TPS）。随着SOAP消息复杂性和大小的增加，我发现会造成明显的伸缩性和性能问题。有效负荷100,000字节、包含750个元素的SOAP消息会把吞吐量降低到1.5TPS。SOAP消息体中元素个数越多，每个元素嵌套越深，问题就会越严重。
性能问题在SOA设计中会引起连锁反应。SOA是一种组件软件重用技术。一个服务通常调用其他服务来确定对消费者请求的响应，从而形成一个调用链。
图3.消费者
不仅仅是一个服务的性能问题，每个服务在序列化、反序列化请求和响应的时候都会增加同样的开销。随着服务调用层次的增加，性能问题也成倍增加。
加快SOA失去的机会
除了SOAP绑定代理速度慢的问题，SOA设计还常常忽略或者忽视另外两个问题。
首先，SOA设计常常忽视了用中间层服务缓冲来提高SOA性能的可能性。比如多数SOA设计中的XML模式都定义了了响应的time-to-live值。在这种情况下，缓冲服务响应并在服务再次收到同样的请求时重新使用缓冲的响应是一种提高SOA服务性能的合理而适当的方法。
其次，在SOA性能测试中，我尝试了各种不同的XML消息解析方法，其中包括StreamingAPIforXML(StAX)、XML绑定编译器、JavaArchitectureforXMLBinding(JAXB)和DocumentObjectModel(DOM)技术。一些技术的性能要优于另一些。比如，很多StAX解析器能够提供比DOM解析器快2到10倍的性能。
我怀疑如果使用其他东西而不是Java对象来提供SOAP绑定是否能够改进性能。比如，如果收到的SOAP请求在本机XML环境中处理，那么基于Java的SOAP绑定就不再是必需的了，同时还可以避免因为序列化成Java对象而导致的性能降低。
此外，一些本机XML环境使用JavaVirtualMachine环境，但会避免构造Java对象。比如，RainingData的TigerLogicXDMS和Kawa/Qexo通过将XQuery查询直接转换成Java字节码来实现XML处理代码。这样做是因为与使用Java对象相比，使用XQuery字节码实现的XML处理代码的吞吐量更大，代码更短。
FastSOA解决方案
FastSOA是解决这些问题的一种体系结构和软件编码实践：
·FastSOA通过减少Java对象的需要，更多使用本机XML环境提供SOAP绑定来解决SOAP绑定（代理）性能问题。
·FastSOA引入了中间层服务缓冲来加快SOA服务。
·FastSOA使用本机XML持久性来避免XML到关系数据库的转换造成的性能问题。
下图显示了FastSOA体系结构。
图4.FastSOA体系结构
FastSOA体系结构与现有的基于Web的基础结构结合在一起，作为中间层缓冲部署来接收服务消费者的请求。比如，一个消费者向服务发出SOAP请求。中间层缓冲提供SOAP绑定（代理）。绑定调用XQuery在XQuery引擎处理XML请求文档。XQuery检查缓冲，查看以前是否收到该请求；在这种情况下，FastSOA服务可以从缓冲中返回响应，不需要逆流而上再请求服务。该过程通过缓冲加快SOA执行从而实现了SOA提速。
FastSOA方法的优点包括：
·服务端点是标准的。对于应用程序的其他部分而言，FastSOA中间层缓冲就像是一种服务。
·不需要修改现有的系统或代码。FastSOA中间层缓冲作为一种数据聚合和迁移服务嵌入到已有的数据中心。
·如果上游服务暂时不能用，当服务离线的时候，FastSOA方法提供了一种浏览缓冲数据的机制。
·通过缓冲服务的请求降低了为支持消费者和服务之间的通信通常所需的带宽要求。
为了从实践的角度理解FastSOA，考虑下面的应用程序。
XML的例子
GeneralMotors采用SOA模式创建服务，让汽车代理商使用基于ebXML的模式和协议从生产厂家订购零部件。该服务能够识别SoftwareTechnologyinAutomotiveRetailing(STAR)组织的一种XML模式。STAR是大型汽车厂商共同努力的结果，其中包括GM。STAR创建并维护BusinessObjectDocument(BOD)模式，定义了目录检查请求（以及其他许多东西）。
CheckInventory请求检查请求者和目录的级别与状态。服务消费者根据STAR模式创建目录请求文档。消费者将文档编组成请求，并通过网络发送给服务。服务发回目录状态响应说明库存中有哪些零部件。
通过降低网络带宽的需要和减少为了响应冗余请求而造成的服务带宽需要，零件订购服务可以从FastSOA模式中受益。
比方说，汽车零售商的零件目录响应中包含一个Time-To-Live(TTL)元素。TTL元素定义了响应有效的秒数。比如GM可能将其设为60秒。在这60秒内，FastSOA用中间层存储的目录响应缓存响应目录请求。这样服务就减少了带宽的使用，并缩短了请求响应时间。
下表说明了如何计算网络中的服务提速效果，这些服务位于本地网络之外的服务器上，FastSOA数据缓冲收集服务在本地网络中。
表1.计算服务加速效果
动作 无缓冲2 启用缓冲2
第一次请求处理的时间 17651 22181
在缓冲中存储请求的时间 01 4531
后续相同或冗余请求 17651 3201
使用的Internet带宽 30,400K字节304K位
使用的总时间 2941分钟 533分钟
1这里所有的时间都是毫秒，1秒=1,000毫秒。
2假设：
·消费者和缓冲服务使用100M以太网连接和1.5M左右的DSL连接。
·TimetoLive(TTL)为60秒。
·请求/响应包含38,000个字节。
·TTL期间有100,000次请求。
在FastSOA实现中，用XQuery实现零部件订购服务。XQuery请求目录服务，读取响应的内容，在运行时确定是否可以使用以前存储的响应而不必再次请求目录服务。
这样就在服务环境中实现了FastSOA数据缓冲收集体系结构。XQuery和本机XML数据库提供了重用以前缓冲响应数据的服务，只要请求与以前的请求匹配并且数据仍然不过时。结果是服务提速了。
FastSOA技术选择
可以使用Java代码和关系数据库技术实现FastSOA体系结构。但是，在测试使用Java对象创建的服务绑定和使用关系数据库持久XML时，我发现了重要的性能和可伸缩性问题。这些问题很突出，考虑使用XQuery、XSLT和本机XML数据库技术很有必要。
我对XQuery感兴趣，是因为它是作为应用程序开发的本机XML环境来实现的。与早期的Java技术非常相似，XQuery社区充满了扩张和证明XQuery是一种开发平台的活力。实际上，多数XQuery实现都经过扩展超出了XQuery标准，以便XQuery能够进行SOAP请求。比如，XQuery可以查询其他服务、J2EE对象和通过JDBC、SOAP、JMS协议查询数据源。此外，已经有10种或更多非常可靠的商业化和开放源码XQuery实现。
最后，FastSOA使用本机XML数据库作为中间层缓冲，因为SOA数据通常采用XML编码格式，而关系数据库在持久存储和索引XML这样的层次性非结构化数据方面有很大不足。存储XML数据的关系数据库通常使用大型二进制对象（BLOB）字段类型存储XML。不仅效率低，而且很难建立索引以便快速搜索。对于流数据采用关系方法通常也不是最佳办法。如果在基于Web服务的网络中发送XML消息，最好用基于流的方法处理该消息，而关系数据库对此无能为力。
FastSOA的未来
除了本文所述的SOAP绑定性能改进之外，采用中间层服务缓冲还会为企业带来很多好处。其他好处包括中间层模式转换、服务版本化、策略选路和服务质量（QOS）处理。比如，FastSOA提供了中间层XML消息模式转换，以便保证需要不同和不兼容的消息类型的服务之间的兼容性。
结束语
本文考察了如何提升SOA的性能和可伸缩性，详细介绍了在中间层使用XQuery支持结合XML持久的SOA设计所带来的好处。FastSOA设计结合使用了本机XML持久性和XQuery，因此每次收到服务调用时，中间层都要决定是使用以前请求的缓冲值响应，还是传递请求。服务使用XQuery根据对服务请求元数据查询的结果描述判定缓冲是否有效。
|