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

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

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

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

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

　　可靠性和可用性

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

　　扩展性

　　基于总线的架构提供了对服务的真实的部署拓扑结构的一种抽象。增加Web服务器、应用服务器、第三方软件、遗留应用和数据库实例——服务描述中功能的真正执行者——的处理能力，将不会影响到服务的消费者。实际上，工作可以进一步委托给联合的总结，这样ESB本身可以按照最有效的利用硬件和网络资源的方式来部署。

　　安全

　　已经实现的服务不应该承担管理什么用户在什么情况下能够访问服务的重担。用户的角色可能随着时间而变化。这种横切(cross-cutting)的功能应该处于ESB中的各种服务之外。

　　延伸性和敏捷性

　　随着业务适应于变化的时代和新的机会，业务流程同样会变化。对于一个成功的SOA实现来说，对灵活性的规划非常关键。转换应当在尽可能的靠近往来于商业信息模型的集成端点处完成。这种方法可以便于流程的灵活自动化，组合服务的编排(orchestration)和将流程相关的商业规则从服务的商业功能中抽取出来。

　　总之，功能完善的integration broker会提供核心的ESB功能，以及其他的一些异构的服务拓扑中必须的功能。这类技术能够为复杂的结构提供一个“简化的”外壳，否则这种简化需要在每个应用或者服务里面取实现。