最近遇到一个IT项目，由于项目前期已经做了一些工作，系统功能被分散到了各个预先定义好的子系统中，后面接手的设计师根据这一现实，以及项目中需要用到一些业务流程，坚持要用ESB来集成这些子系统。
一定要用ESB吗？
究竟ESB是什么，适用于什么开发场景？我们不得不回到最初的问题。
ESB是什么？
ESB 是一种体系结构模式，而不是软件产品。不同的软件产品可以构成 ESB。在某些情况下，公司在不同的区域中使用多种产品，利用特定的功能来满足其独特的需求。可以将这些不同的产品联合在一起实现 ESB 模式。
概括地讲，ESB 具有四个主要功能：
- 消息路由：将传入消息发送到目的地，该目的地通过硬编码方式连接的逻辑确定或基于内容的动态方式确定。路由是启用服务虚拟化的关键功能。在调用方和服务之间建立中间层可以在调用方不知道更改的情况下移动服务的位置。
- 消息转换：将传入消息从一种格式转换为另一种格式。例如，可以将逗号分隔的消息转换为 SOAP，这样可以将数据传递到 Web 服务。
- 协议中介：传入消息使用不同的协议从发出位置发送。例如，传入消息可以使用 HTTP，而传出消息可以使用 WebSphere MQ。
- 事件处理：事件的传入消息一般通过发布和订阅模型分发给许多端点。
在给定的事务中，通常会合并这些主要高级功能。例如，传入消息可能是一个使用 SOAP/HTTP 的 Web 服务调用，而目的地是需要使用 WebSphere MQ 的固定长度消息格式的遗留系统。必须转换消息、协调协议并且必须将消息路由到正确的位置。
对 ESB 编程通常涉及虚拟环境，并将逻辑表示为称为消息流或中介流的连接活动流。这些流都是事务型的，使用的是两阶段提交之类的机制，这样在失败时可以回滚整个流，或者在成功时提交整个流。这些流是无状态的；通常情况下是消息传入，流对该消息执行各种操作，然后发送传出消息。
由于 ESB 的无状态事务特性，因此高性能是前提条件。在大型组织中，ESB 每天处理数百万条消息的情况并不少见。
ESB的优点
ESB 的主要优点之一就是处理消息。消息的传入和传出也许会用到协议或格式中介。当这些需求明显需要处理消息时，使用 ESB 可以提供许多优势，其中包括在转换中处理较复杂事务的能力。当这些需求需要使用 ESB 基本功能（如消息路由、转换或协议中介）之一时，则 ESB 是最佳选择。
ESB 的另一个优点是性能。ESB 在计划上能够处理大量的消息。例如，如果需求是每天处理 200,000 条消息，则 ESB 显然是较好的选择。
如果需求是以数据为中心的，则显然要选择 ESB。
需要思考的问题
就我们这个项目而言，没有遗留系统，所有子系统间的边界、消息可以重新定义和设计（原有设计中有很多不合理之处）。首先可以通过数据集成、重新划分业务的方式，减少子系统的数量。其次，通过把子系统间交换的信息定义标准化来解决子系统间集成的问题。根本没有必要一定要使用ESB，这是典型的过度设计。