XML兼容性的问题
企业服务总线的技术实现必须是标准的，而不能是某某企业以前的所谓某某CORBA中间件平台，或COM+中间件平台简单的“新瓶装旧酒”。虽然对于提供商而言它们是以比较小的成本快速地切入企业服务总线市场，但是对于企业自身而言，基于这些所谓中间件平台搭建出来的企业服务总线，首先要受到标准化的很多限制，它们本身采用的很多技术不是这个时代的产品。虽然说SOA是个概念，但是如果基于这些平台的中间件，在实现完全XML化的各个SOA组成的新的版本上就需要更多的时间。
同样的，对于企业服务总线产品本身使用的持久层数据库选择上也要慎重。毕竟在SOA环境中SOAP、XML、XSD、WSDL、BPEL的本质上都是XML，采用具有“双核”特性的XML数据库产品才可以更好地检索和使用它们，通过压缩XPath和XQuery的执行时间来从整体上确保每一个组成元素的更高运行效率。如果相应的企业服务总线采用遗留产品的中间件平台，那么它们的持久层也由于历史的原因一般会使用纯关系数据库完成。这种做法首先在XML的解析上就很可能存在一定的差距，更不用说XPath和XQuery查询。
虽然SOA的理念是通过集成达到资源整合的目标，但是鉴于大家普遍采用的XML Web Service实现方式，笔者还是建议在SOA的调度层开发或者产品购买上要选择Native支持XML的新开发技术和新数据库产品。
同样，对于XML兼容性的考虑也要在确定每个Service Endpoint的集成方式上。下面笔者以一个.NET Remoting + SQL Server 2005，一个COM+ + SQL Server 2000和一个J2EE的EJB + Oracle 8i应用的集成为例，讨论XML兼容问题对于集成过程的影响，三个应用的功能如下：
（1）.NET Remoting应用是企业的统一授权平台，负责用户的认证和授权检查。
（2）COM+应用是企业的财务系统。
（3）J2EE应用是企业的内部生产系统，负责处理业务单据。
它们最后封装的Service Endpoint是提供给企业合作方，通过在线银行做在线的小额订单自动核销。流程如下：
（1）合作方的应用系统把自身的身份、合同号、银行回执号发送到小额订单和小服务的接口。
（2）该服务首先调用.NET Remoting应用做用户认证和全县检查。
（3）确认后，调度COM+应用划账，并调用J2EE应用修改订单的工作流和处理状态。
（4）最后，服务接口反馈合作方应用的Web Service，确认核销成功。
相对而言，效率较差的实现就是为每一个应用独立设计一个基于应用内置组件功能的Web Service，最后在其上再开发出一个协调的Service。
图：纯Web Service调用方式
一个效率上改进的方法就是把.NET Remoting与COM+应用做一个整合，通过互操作在.NET Remoting应用中增加一个新的接口，把步骤1与步骤2作为一个内部的步骤完成。
图：内部面向性能集成后的结果
上述两个方法不仅仅有处理上的性能差异，而且对于不同开发技术对于XML的集成支持上也有一定意义。简单的通过.NET Remoting的HTPP Channel + SOAP Formatter，就可以将需要COM+通过较为繁琐的SOAP Toolkit开发旁路过去。
对于不同消息模式的考虑
注：由于笔者所在行业习惯于称事务性为交易性，所以下文笔者也将继续采用“交易性”的称呼。
一般而言，企业的绝大多数处理都是必须有交易性保证的，但是针对具体的应用点，还是可以具体分析的，起码来说消息模式上最少就有如下三种方式：
（1）单项的One way（Simplex）：
图：Simplex消息模式
（2）异步的双向One way（Duplex）：
图：Duplex消息模式
（3）质询——响应（Request – Response）：
图：Request – Response消息模式
三种模式下，其实仅有Request – Response 模式可能会需要交易性的保证。从实际的使用上，查询操作本身也不需要交易性保证，只有涉及到DML操作的时候才真正需要启动交易。因此在企业SOA环境的设计上，WS-Transaction、 WS-Coordination这些较为重磅的协议要考虑独立配置到具体的SOAP调用上，而不是一股脑的建立一个“凡是”的SOA 交易性环境。并且从安全设计上考虑，单纯的查询与设计DML的操作，也完全可以通过拆分服务，并为其配置不同访问权限的账号来进一步加强系统的安全性。
后记
文中笔者仅仅根据自身经验，对于企业SOA环境建设中几个技术设计考虑的要点进行了讨论，随着类似工作的继续进行，笔者会将更多的设计要点拿出来与各位架构师探讨。
