在本系列的第一部分中，我们以维基百科基础的企业服务总线定义（ESB）开始我们的讨论。
看起来，共识之一是 ESB 是与编制（orchestration）和业务过程管理（Business Process Management）截然不同的单独一类产品。此外，对于 ESB 到底是产品还是模式还有很大的争议。
在本系列的第二部分，InfoQ 调查了 ESB 的使用目的 - ESB 的使用案例和需求是什么？
Sonic 公司的 Dave Chappell 开启前文中的讨论，部分1 暗示了Sonic 软件公司可能事实上正试图标准化基于UML 的模式集，实质上，它们定义了ESB 的参考架构。
Stuart Charleton （BEA 系统策略咨询服务的企业架构师，位于 Canada 的 Toronto）提供了以下的使用例子：
- 消费者使用基于 HTTP/S 的认证，生产者使用 WS-Security。
- 消费者使用 HTTP/RSS，生产者使用 WebSphere MQ 或 JMS。
- 消费者使用 HTTP/REST 和 URI，生产者使用 SOAP/WSDL。
- 消费者有一组证书，生产者有另一组（键链映射）。
- 一端使用 FTP 站点作为“服务接口”，而另一端文件被拆分成 JMS 消息。
- 在路由到目的地之前，消息需要被充实，这样就可以执行 callout 来收集额外信息。
- 生产者要求协议独立的负载均衡和 / 或故障转移。
- 消息需要被存储转发，在不可靠服务上改进可靠性。
同时，作为这些主题的补充， Paul Fremantle （WSO2 的共同创建者和技术副总裁）增加道：
因此，ESB 是实现仲裁（mediation）的通信基础设施。ESB 应该有什么样的拓扑结构呢？我认为它应该是灵活的：你可以将 ESB 构建为中间层的单个且大的代理，也可是很多智能终端。当然，拓扑结构会影响可管理性，但是只要有配置 ESB 的中心注册表 / 仓库，那么它将工作很好。这其中的关键点是 ESB 应该由策略而非书写代码驱动。
Burton Group 的 Anne Thomas Manes 也说道：
“......ESB 特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多 ESB 也支持可靠消息传递、异步消息传递和发布 / 订阅交换模式。这些能力都非常有用，但是，在 SOA 项目的初始阶段可能不会发挥多大的用途。（每个组织有很多不选用这些能力的项目。）在 SOA 项目的后期，你还可能需要一个编制（orchestration）引擎，并且大多数的 ESB 都会提供一个。即便如此，ESB 也绝对不是组织启动 SOA 的起点。所有这些能力你一开始并不需要。因此，ESB 应该在后期购买。”
以上强调将 ESB 作为桥接传统应用的手段。 Network Computing 的近期研究中：调查一组回答者，让他们使用“从强烈同意到强烈反对”的标准，为一组关于 ESB 技术的表述评分。回答者强烈同意的前 4 个表述是：
- ESB 必须给企业数据源（SAP、Peoplesoft、Oracle、SQL Server）提供适配器。
- ESB 必须至少支持基础的业务过程管理。
- ESB 实现需要支持开放标准（JMS、Web 服务）。
- ESB 必须与现有的企业应用集成（EAI）和面向消息产品平滑集成。
这暗示着传统数据源（如 ERP 和 EAI 系统）是 ESB 的重要接口，并且它们应该将那些应用层作为基于标准的消息暴露。有趣的发现是，终端用户似乎同意"至少基础的"业务过程管理是 ESB“必须支持的”。
关于最后的评论，Steve Jones（来自 CapGemini）暗示，ESB 的问题事实上是 3 个毫不相关的问题：集成、构建和业务。
……第一个挑战是利用现有资产发掘功能（集成），第二个则是构建新的应用（构建），最后则是管理新应用间的交互（业务）。待会儿我将在我的博客中讨论这些。集成产品有很多非常不同的需求，并且驱动力来自于人们想在更面向标准的空间中实现交互，而我不太确定混淆这两个领域为什么有意义。同样的，构建新应用（使用过程或面向对象语言）则需要不同的技术和方法。
集成总线以其能力作为衡量标准，而业务服务总线则在于简单性和应用开发解决方案的灵活性。并且无论何种合理规模的业务也不会有一劳永逸的解决方案。
ESB 综述的第二部分期望能帮助定义用户要求的使用案例，尤其是当他们需要 ESB 时。共识是：业务过程工具与 ESB 是不同的，加上 ESB 包含来自最终用户的完全相反的兴趣，这也暗示着可能将不同种类的产品合并为成了一个。
欲了解这个讨论，请关注适合于 ESB 的使用案例。
评论