在本系列的第一部分中,我们以维基百科基础的企业服务总线定义(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 的使用案例。
评论