加快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模式中受益。
