服务的监控及提供相对比较简单。最让人困惑的SOA决策是服务如何联系、服务之间应采用哪种仲裁机制。

　　在理想情况下， SOA中的每个服务都应符合标准的Web服务规范，健壮可靠，而且可以供需要服务的应用或者XML负载的一系列众多授权的应用或者服务直接使用。但实际上，企业需要应对使用从MQ到AS2等各种专有协议的遗留系统。而许多人认为，只有WS-Reliable Messaging等Web服务协议完全成形，并得到广泛实施，Web服务的传送才会获得企业所需的可靠性。

　　于是，ESB蜂拥而入——ESB是如今与SOA关系最紧密的一类产品。ESB是一种消息传送总线及服务平台，有了它，连接旧系统、管理及编制服务就会比较简单。与企业应用集成（EAI）产品一样，ESB也负责转换及发送消息。ESB厂商对自己的产品是否基于标准非常重视，目前大多数使用Java消息服务（JMS）或者某种专有的消息传送协议，目的是为了提供必要的可靠性。

　　支持者喜欢ESB是因为ESB让他们可以配置服务、管理服务之间的联系。经历了好几年没有ESB的日子后，工资单处理服务市场的巨擘ADP公司最近采用了分布式ESB，因为“很难维护大批一对一的消息传送适配器”，该公司雇主服务部门的CIO Bob Bongiorno说。这家公司的服务数量从9个增加到了30个以上，但在此过程中，“管理难度绝不是仅仅增加了三倍”。Intuit公司集成架构解决方案部门的首席架构师Martin Moseley说，ESB适用于需要编制的长时间运行流程，譬如订单处理。在这种流程中，各步骤必须按某种次序来进行，而且整个过程都要进行验证。譬如，在计算运费或者批准使用信用卡之前，订单流程可能需要验证顾客的地址（原因是验证信用卡往往需要地址）；只有完成了所有步骤，才可以发送货物清单。Intuit的订单处理系统就使用这样一种仲裁服务方法。

　　但也有人认为ESB只是改头 换面的EAI而已，他们认为ESB有悖于SOA的开放性。伯顿集团的分析师Anne Thomas Manes认可使用ESB配置服务，甚至把细粒度服务编制成可广泛访问的粗粒度服务，但抨击了总线作为传送所有服务的网关这一概念，尤其当ESB消息的来回传送带来额外开销时，她更是觉得不能接受。

　　我的意见是：

　　根据你的项目中对soa识别，soa服务，soa接口掌握的需求程度，以及soa预算所需要的情况来决定。而且在中国，务必要考虑旧系统的整合，你要站在信息中心主任的角度去思考：我应该把这个项目定义为一个EAI项目呢？还是一个soa项目？毕竟许多国内的项目是为了soa而soa的，选择厂商的同时也就决定了你的配置，因为soa项目目前作为一个集成类项目来搞的可能性很大，经济搭台，技术唱戏。如果客户已经选了esb,那你作为架构师就要随学蠕动，充分的去搞定使用esb的问题带来的性能问题。所以需要esb与否还是要casebycase来看。架构师需要做的，还是抽象再抽象，熟练的可以进行webservice的封装调用，客户买了esb就用esb做，没有esb就自己来搞，毕竟，项目的成功验收才是王道。