developerWorks 中国.docVIP

developerWorks 中国????Architecture?|?SOA and Web services?|?WebSphere?? 探索企业服务总线，第 2 部分: 为什么 ESB 是 SOA 的基本组成部分 文档选项 打印本页 将此页作为电子邮件发送 未显示需要 JavaScript 的文档选项 讨论 英文原文 级别： 中级 Greg Flurry, 资深技术主管 (STSM), IBM　Rachel Reinitz (rreinitz@), 杰出工程师, IBM　 2008 年 4 月 17 日 本文是本系列的第 2 部分，您将在其中了解为什么 IBM? 认为企业服务总线（Enterprise Service Bus，ESB）体系结构模式在采用面向服务的体系结构（Service-Oriented Architecture，SOA）时提供了极大的价值。作者 Greg Flurry 和 Rachel Reinitz 将与您分享从有关采用了 ESB 的成功 SOA 客户项目的广泛经验中获得的与 SOA、ESB、SOA 入口点、连接性等相关的见解和最佳实践。此外，通过了解有关实现 ESB 模式的 IBM 系列产品的更多信息，从而了解 IBM 如何致力于推动 ESB：WebSphere? Message Broker、WebSphere Enterprise Service Bus 和 WebSphere DataPower? Integration Appliance XI50。 本系列的 第 1 部分 描述了称为企业服务总线（Enterprise Service Bus，ESB）的体系结构模式如何适应 IBM SOA Foundation，以及 ESB与 Foundation 的其他部分如何相关。 引言 IBM 对 ESB 的立场是——并且一贯是——认为 ESB 作为 SOA 中的一种体系结构模式发挥了根本性的作用。ESB 是实现成功 SOA 采用的重要入口点，并且是任何面向服务的解决方案的关键成功因素。事实上，作为对 SOA 中的 ESB 承诺的一部分，IBM 提供了实现 ESB 模式的三个战略产品。 本系列的第 1 部分描述了企业服务总线 (ESB) 体系结构模式如何适应 IBM SOA Foundation，以及 ESB与 Foundation 的其他部分如何相关。 本文介绍以下主题： 设计良好和实现良好的 ESB 能够为面向服务的解决方案提供的价值 一些在设计和实现 ESB 时要遵循的最佳实践 IBM 对作为 SOA 组成部分 ESB 的承诺 对 Bobby Woolf 的文章“面向 ESB 的体系结构：一种错误的采用 SOA 的方式”的说明 Bobby 的文章引起了轩然大波。不幸的是，该文让某些读者误认为 IBM 不再看重 ESB 的价值。但是正如本文所述，事实远非如此。过去，Bobby Woolf 曾与一些未遵循本文列出的最佳实践的客户合作过。这些客户设计并实现了 ESB，却没有用于采用 SOA 的路线图或与路线图不一致。所以他们不成功也就毫不奇怪了。幸运的是，这些客户仅代表少数派；大多数客户设计并实现了带路线图的 ESB，并且是在一个或多个 SOA 项目的上下文中设计和实现的，其中 ESB 体系结构和产品选择由跨多个项目（并且通常是跨不同的业务部门）的需求所驱动。 该文不过是在一个路线图的上下文中提出了以下开发 ESB 的最佳实践建议，该路线图定义了将实现所需业务目标的采用计划。下面是摘自该文的一些示例： “基于面向 ESB 的体系结构的项目需要成为基于 SOA 的项目，才能帮助确保成功地提供业务价值”。这与“连接性入口点与任何入口点一样，必须作为交付业务价值的总体 SOA 路线图的一部分进行选择”的断言是一致的。 “暗示服务不相关，就是在说使用总线的应用程序不相关，应用程序如何使用总线不相关，而且应用程序集成需求（算不上业务需求）不相关。”这也与“一定不能在真空中部署 ESB，而是要将其作为总体 SOA 路线图的一部分进行部署”的断言是一致的。 “ESB 本身不产生任何业务价值。ESB 是达到某个目标的手段，而不是该目标本身”，而且，“面向 ESB 的体系结构天生就有缺陷，因为它构建可能永远没有人希望使用的连接。除非系统彼此连接并协同工作，否则业务并不会带来任何其他价值。”如果企业购买一个 ESB 产品并安装该产品，而不曾预期使用该产品来连接服务，那么该 ESB 产品是否提供了任何价值呢？很可能没有。这是常识。这些陈述再一次强调了“ESB 或任何其他 SOA 采用方法必须成为确定业务价值和如何实现业务价值的总体路线图的一部分”的事实。 “作为开发 SOA 的一部分开发 ES