为什么在面向服务的景观图中又加入了一个移动的部分?难道对面向服务的应用的管理还不够复杂?引入企业服务总线（ESB）的原因和许多年前选择企业应用集成策略的原因是一样的。

在SOA实现的早期阶段，当目录仅仅由一个或者两个基于项目的服务组成的时候，ESB看起来是英雄无用武之地。但是幸运的是，如果在企业中采用ESB，那么服务的部署会被加速。任何一项策略都被要求能够提供随需应变的扩展性，可靠性和足够的性能等特点。从构架的角度，使用一个合理的原则避免服务混乱不失为一个好的想法。

随着企业SOA的逐步成熟，业务功能会从各种源头被挖掘和发现出来。这些服务的提供者可能是遗留的应用，第三方软件包或者主要解决方案提供的功能。虽然理想状态是所有这些服务都使用相同的技术，但是现实情况证明这是不可能的。很有可能Web Service标准仅仅是使用的技术中的一个而已。

高级的SOA功能，比如服务编排(archestration)，自动业务流程，事件驱动架构和复杂事件处理，都依赖于健壮的企业应用集成架构。

将这些注意事项牢记在心，判定带有ESB的完整功能的integration broker的标准就很清楚了。

　　可靠性和可用性

由于多层应用的出现，对分布式软件中所有移动部分的可见性是一项重大的挑战。由于消费者完全从应用面向对象开发中分开，服务的消费者必须能够发现服务并且预计服务的可用性、质量和性能特征。ESB能够处理服务注册，同时有助于兼容SLA(服务等级协议，service level agreement)。为了监控服务的健康状态，就必须清楚该服务对其他服务的依赖，以及运行平台的状态。当问题被检测出来，就会发出警报和通告。许多integration broker的产品或者提供内建的监控功能，或者，更常见的情况，提供钩子(hook)给监控工具以便获得更全面的可见性。这些工具可以提供审计，日志和异常处理的通用服务。