在我们继续前进并且牺牲我们的先前努力，丢掉前面的每个技术，并且向失败举起我们的双手之前，还有一条路能够让我们能够利用从学来的宝贵经验，并且仍然远离偶然架构—那就是采用ESB。 集成的最佳实践，已经经过对集成Broker的经验被精炼，如今还可以结合建立于XML、Web Services、可靠的异步消息、以及分布式的ESB集成组件之上的基于标准的架构来一起使用。 他们一起形成一个高度分布的、松散耦合的集成架构，以提供集成Broker的所有主要功能，却没有其所有的障壁。
远离偶然架构并且使用 ESB重构到的一个统一的和一致的集成骨干，涉及到下面小结描述的步骤。
虽然ESB 确实能够传送许多类型的数据格式，但是采用XML作为应用间交换数据的手段 (图 2-2)，如同已经被用在一些传统的 EAI 方式中一样，可以由很多好处。我们将会在第 4 章中看到，使用XML可以一劳永逸地隔绝全局的数据格式和接口的变更和偶然架构本身。ESB可以进一步通过检查XML消息的内容，并且控制其向何处提交，有时候还可以改变提交路径来包括可能会修改和增加数据的附加服务，一次来促进业务处理。
图表 2‑2 ESB 使用XML来作为应用间共享数据的方式
2.3.2 采用Web ervices并实现 SOA
以 SOA 的方式来思考和规划在向 ESB重构的一个基本步骤。如图 2-3 所示，服务级接口的引入在提供了一个公共抽象层来创建接口和实现之间的分离。这样就通过使用一种通用的接口定义机制，比如Web Services描述语言(WSDL)，来减轻了由细粒度服务接口组成的复合业务流程定义的构造的难度。
图表 2‑3 Web 服务和 SOA 提供了一个隔离接口和实现的通用抽象层
虽然服务级接口的抽象是正确方向上的一步，结果仍然是一个路由逻辑密合于应用之内的硬连接 ( 注意在图 2-3 中，“流程逻辑”仍然黏附于应用)。Web Services中的传统智慧已经模仿了客户/服务器模式。甚至在一个Web Services分布式网络中，一个应用总是另一个 “客户”。范例用法仍然需要抽象层也包括胶水代码，比如说“调用服务X上的方法a，然后调用服务Y上的方法 b()….”诸如此类。。
Web Services实现中所确实的东西是将流程路由逻辑从接口定义和应用逻辑中分离出来观念。如图 2-4所示，ESB 就提供了那种隔离，并且仍然完全利用SOA。
图表 2‑4 ESB 将业务流程的路由逻辑从接口定义和应用实现中分离出来
通过分离接口定义和流程路由逻辑，我们已经开始看到ESB 形式的总线层(图 2-5)。通过将流程业务路由逻辑和接口定义放入总线层之内，应用能够继续自己集中于实现逻辑。 我们在第 1 章中看到过，ESB 被实际上区分为多个功能层。它为应用间的可靠的、异步的、基于消息的通信提供了一种坚固的底板。也是在这里，流程路由通过基于检查消息中的XML内容来附加的条件决策点，从而变得具具智能。这个智能路由是被可管理地定义的、可以被修改、并且可以加上增值服务，比如补充数据变换功能。ESB 提供了一个可扩展的集成服务网络，并且可以无限伸展，同时仍然可以以逐渐增加的方式进行构建
图表 2‑5 ESB 可靠地连接和协调SOA 的服务之间的交互