服务的监控及提供相对比较简单。最让人困惑的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消息的来 回传送带来额外开销时，她更是觉得不能接受。
性能、安全和运行时治理
要不要使用ESB取决于每家组织的独特需求和情况。譬如说，如果分布式服务的编制必不可少，而这些服务没有接入到异步消息传送基础架构，编制起来难度就会相当大。
不过单单有了ESB并不等于就有了SOA。在实施的各种规模的SOA中，一般不会只有一种。可能需要连接多条消息总线，而且消息在这些总线上传送过程中还需要转换。
思科、Forum Systems、IBM DataPower、Layer 7和Reactivity等厂商提供的新一代XML设备非常胜任这项工作，这类设备主要用于保护、管理及提升SOA的性能。这些厂商销售的设备可以根据内 容来转发XML消息，并使用专门为此设计的处理器高速完成XML转换、转发及映射等工作。
这些设备大多集成了一系列功能，其中许多功能与ESB的功能相重叠。它们尤其善于对服务进行虚拟化处理，这样一旦需要提升性能时，就可以动态创建服务，而且可以在运行时使用集中管理软件，执行针对服务制订的策略。大多数设备还包括了一系列XML安全功能。
实际上，上述这些厂商销售的首批设备是XML防火墙，用来阻挡基于XML的威胁和拒绝服务攻击。如今，XML安全设备支持加密/解密、验证、身份管理、XML模式验证及更多功能，既可以控制应用访问，又能保护网络边界。
随着SOA日趋成熟，安全服务必不可少。ADP公司就是这种情况，该公司现正致力于部署标准安全模型，作为供其他所有服务使用的集中流程。同 样，技术服务提供商USi也在使用联合身份管理验证用户身份。高级技术部门的副总裁Mike Rulf说: “服务可能甚至不知道用户是谁，但知道该用户已在服务传送过程中的某个阶段通过了验证，因为服务传送了这些验证信息。”
文章来源于领测软件测试网 https://www.ltesting.net/
