ESB综述2：ESB使用案例

在本系列的第一部分中，我们以维基百科基础的企业服务总线定义（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个表述是：

1. ESB必须给企业数据源（SAP、Peoplesoft、Oracle、SQL Server）提供适配器。
2. ESB必须至少支持基础的业务过程管理。
3. ESB实现需要支持开放标准（JMS、Web服务）。
4. ESB必须与现有的企业应用集成（EAI）和面向消息产品平滑集成。

这暗示着传统数据源（如ERP和EAI系统）是ESB的重要接口，并且它们应该将那些应用层作为基于标准的消息暴露。有趣的发现是，终端用户似乎同意"至少基础的"业务过程管理是ESB“必须支持的”。

关于最后的评论，Steve Jones（来自CapGemini）暗示，ESB的问题事实上是3个毫不相关的问题：集成、构建和业务。

……第一个挑战是利用现有资产发掘功能（集成），第二个则是构建新的应用（构建），最后则是管理新应用间的交互（业务）。待会儿我将在 我的博客中讨论这些。

 

集成产品有很多非常不同的需求，并且驱动力来自于人们想在更面向标准的空间中实现交互，而我不太确定混淆这两个领域为什么有意义。同样的，构建新应用（使用过程或面向对象语言）则需要不同的技术和方法。

集成总线以其能力作为衡量标准，而业务服务总线则在于简单性和应用开发解决方案的灵活性。并且无论何种合理规模的业务也不会有一劳永逸的解决方案。

ESB综述的第二部分期望能帮助定义用户要求的使用案例，尤其是当他们需要ESB时。共识是：业务过程工具与ESB是不同的，加上ESB包含来自最终用户的完全相反的兴趣，这也暗示着可能将不同种类的产品合并为成了一个。

欲了解这个讨论，请关注适合于ESB的使用案例。

查看英文原文：ESB Roundup Part two: ESB Use Cases