级别： 中级 Rachel Reinitz (rreinitz@us.ibm.com), IT 咨询专家, IBM
Andre Tost (atost@us.ibm.com), 高级技术人员, IBM
2006 年 1 月 01 日 这是使用 IBM WebSphere Application Server V6 构建企业服务总线系列文章的最后一部分。本文中，我们将概括前面文章中介绍的内容，并回顾所描述的核心功能和场景。此外，将展望 ESB 技术的发展，特别是 WebSphere 产品系列是如何对 ESB 提供支持的。
摘自 IBM WebSphere 开发者技术期刊。
引言
在这一系列中，我们介绍了许多关于企业服务总线 (ESB) 的背景知识与基本特征，通过一个示例业务场景描述了基于 ESB 的解决方案是如何应对挑战的。我们有选择的实现了 ESB 中包括的一些关键特性，然后通过 IBM WebSphere Application Server V6 对消息传递的支持，实现我们所需要的业务功能。包括对基于 JMS 的基本消息传递、Web 服务的使用、消息中介以及最终的多协议消息交换的支持。在本文中，我们将简要地回顾之前的各个部分，并说明如何将这些部分组合在一起，以构成一个基于 ESB 的解决方案。
此外，我们将展望 ESB 技术的发展趋势。最近IBM 发布了一些与企业服务总线相关的新产品和新版本。我们将向您介绍一些新技术，以及与本系列中所使用的 SIBus 的关系。令人兴奋的是，一种新的编程模型规范——服务组件体系结构 (SCA)已经制定出来了，该规范得到了 IBM 和许多其他供应商的支持。
本系列文章回顾
第 1 部分：服务集成总线回顾
在本系列的第 1 部分中，我们描述了在 WebSphere Application Server V6 中称之为服务集成总线 (SIBus) 的基本功能。通过提供“目的地”，SIBus 提供了基本 ESB 功能，目的地用作要发送到总线的消息的目标。为了操作到达目的地的消息（例如，改变其格式或路由），SIBus 使用了中介的概念，每个中介都由一个或多个中介处理程序组成，当消息到达总线时，这些中介可以对其进行访问。只要消息到达目的地，它们就会被转换成服务数据对象 (SDO)，这使得能够以通用的方式对消息内容进行访问。SDO 是 IBM SOA 编程模型的基础。它支持一种跨许多不同的数据源访问数据的通用方式，这使得开发与数据有关的代码（和工具）更加容易。当然，这对 ESB 实现非常有用，因为它使得有可能开发独立于创建消息的源来访问消息的代码。最近，IBM 发布了其编程模型的另一关键部分，即服务组件体系结构 (Service Component Architecture)，这一部分解决了以通用的方式访问服务的问题。SCA 和 SDO 的组合构成了一个通用模型，可以用于处理服务及其提供的数据。本文后面还有更多关于这方面的内容的讨论。
第 2 部分：业务场景回顾
我们的 ESB 场景基于一个名为 Posts-R-Us 的送货公司的示例。对于许多企业而言，这家虚拟公司所面临的问题是非常典型的，即：它有许多完全不同的系统，这些系统应该彼此集成，以更快地适应新的和改变的业务流程，而不需要一直不断地人工开发新的功能或集成逻辑。
这里务必谨记的是，业务级需求并不直接要求具有 ESB。我们假定 Posts-R-Us 决定开始构建面向服务的体系结构，以创建一组直接解决业务相关问题的服务。ESB 提供了一个层次，在这一层次中，服务请求者和服务提供者之间的关系是间接的和分离的，这使得可以更好地分离关注点。换句话说，集成逻辑（例如，协议转换、消息格式转换）与业务逻辑（即，服务执行的实际功能）是分离的。ESB 可以提供虚拟服务，以便能够通过基于标准的服务接口来有效地包装现有的应用程序逻辑。因而，ESB 有助于架设一座桥梁，以弥合业务问题（提供一组灵活的可以实现所需的业务流程的服务）和现有 IT 环境（包含所有的协议、格式以及现有的遗留应用程序）之间的差距。
最终将得到一种高级体系结构，如下图所示（摘自本系列的第 2 部分）：
图 1. 使用 ESB 简化所需连接
第 3 部分：JMS 消息传递回顾
大多数 ESB 需要支持各种消息格式和协议，包括 Web 服务和消息传递，例如 IBM WebSphere MQ 和 JMS。我们首先实现了使用 JMS 支持的示例，接着实现了使用 MQ 支持的示例，以演示非 Web 服务协议的重要性以及如何将这些关键协议用于 SIBus。我们定义了对 JMS 消息传递的支持，并将其作为第 3 部分中的 ESB 解决方案的核心需求之一。JMS 协议提供了系统集成中通常要求的服务质量 (Qualities of Service)，因此，在 Java 2 Enterprise Edition (J2EE) 环境中，JMS 协议是一个常见的 ESB 需求。例如，JMS 包含对保证的消息传递的支持，它支持事务，并且提供了对发布/订阅消息模式等的支持。此外，它是一个标准 API，属于 J2EE 的一部分，并且受到许多跨不同平台的应用服务器的支持，因而可以确保异类环境之间具有良好的连接性。
WebSphere Application Server V6 中的消息传递资源是应用服务器的缺省 JMS 提供程序。通过发送和接收来往 JMS 队列的消息，JMS 应用程序可以直接绑定到 SIBus 目的地，这使得对于消息使用者和生产者 SIBus 是透明的。
第 4 部分：中介回顾
如上所述，中介是支持消息操作的 SIBus 组件。在第 4 部分中，我们介绍了一个示例，它详细地演示了如何创建一个中介处理程序并将其部署到 WebSphere Application Server V6 中的中介。只要消息到达目的地（不管是从 JMS 客户端发送的还是由于 Web 服务调用产生的），它就会被转换成 SDO DataGraph 并转发到与该目的地相关联的任何中介。包含在中介内的中介处理程序可以读取和更改消息、上下文信息甚至路由信息（即下一步将消息发送到何处）。从而可以有效地将集成逻辑应用于消息，这是 ESB 的核心特性之一。中介模型具有很大的灵活性，可以满足各种各样的需求，其中包括基于内容的路由、记录和数据转换。
第 5 部分：Web 服务回顾
在第 5 部分中，我们讨论了 WebSphere Application Server V6 SIBus 中的 Web 服务支持。ESB 的一个重要特性是支持多种协议，其中包括对基于消息传递的协议和 Web 服务的支持。Web 服务正在逐步成为服务和提供异类系统之间的互操作性的主流技术。WSDL 所描述的独立于实现和基于标准的接口将提供者和使用者的实现技术分离开来。通过在提供者和使用者之间使用 ESB，可以为进行其他方面的分离提供机会：
- 使用者不再受到提供者的位置改变的影响。
- ESB 可以使用不同于提供者的协议来支持使用者。
- ESB 可以在使用者的消息格式和提供者的消息格式之间进行转换。
- ESB 可以提供持久性的队列支持，当使用者发送服务请求时，可以通过这种支持来解耦必须处于可用状态的提供者。
在前面的文章中，我们描述了如何构建 ESB 作为用于服务交互的间接层次，以便提供对某种服务质量 (QoS) 以及消息操作和路由等关键特性的支持。
WebSphere Application Server V6 和 SIBus 完全支持使用 SOAP over HTTP 和 SOAP over JMS 进行的服务交互。它使用所谓的出站服务来将消息转发到现有的 Web 服务，并且使用入站服务来给请求者提供 Web 服务接口。在后台，它使用 WebSphere Application Server V6 的内置 Web 服务支持，这种支持基于针对 Web 服务的相关 J2EE 标准。高级 Web 服务特性（如 JAX-RPC 处理程序和 WS-Security）可以用于 SIBus 中的入站和出站服务。在 developerWorks 网站和 WebSphere Application Server Information Center 中可以找到关于这些特性的信息。
第 6 部分：WebSphere MQ 连接性回顾
ESB 的另一个常见需求是对本机 WebSphere MQ 连接性的支持，如第 6 部分中所述。许多组织对此都有强烈的需求，其原因在于，WebSphere MQ 已经应用了很长的时间，并且几乎成为了企业消息传递的实际解决方案。它广泛应用于应用集成，所以任何新的集成技术（如 ESB）都必须考虑对其进行支持。事实上，许多应用程序已经在 WebSphere MQ 中提供了接口，从而使得 ESB 可以更容易地利用它们。
WebSphere Application Server V6 附带了称为 MQLink 的功能，这使得 SIBus 看起来就像是另一个 WebSphere MQ 队列管理器。因而可以将 SIBus 无缝集成到现有的 WebSphere MQ 功能中，以便它的引入可以立即影响现有的遗留应用程序。要使用 MQLink，必须在 SIBus 和 MQ 队列管理器中进行配置，如第 6 部分所述。
第 7 部分：消息协议切换回顾
关于构建 ESB 的最后一个关键需求是能够在不同协议之间切换消息，如第 7 部分所述。
在我们的示例中，Posts-R-Us 将一个常见的可重用服务实现为 Web 服务，并且使其可以通过 ESB 进行使用。ESB 还可以使该服务可以用在无法直接使用 SOAP/HTTP 接口的客户端。这是 ESB 的显著优势之一。我们向您演示了如何使用 SIBus 来连接 MQ 消息队列，以便与具有提供实际业务功能的现有 Web 服务的客户端应用程序进行交互。此可重用服务现在只需要构建一次，再次说明，我们已经分离了开发合适的业务逻辑和支持在整个企业的范围内访问该功能的关注点。
协议和消息转换（我们称之为集成逻辑）是使用 SIBus 中的中介构建的，根本不会影响系统的其余部分。中介了解入站和出站协议，并且通过 SIBus 支持来利用它们。潜在的消息格式更改是通过相关 SDO 接口完成的。
这最后一个场景结束了我们最初描述的 ESB 功能集：对消息传递、路由、数据转换、Web 服务和多协议消息传递的支持。除此之外，还存在许多其他方面的问题：对更高级的功能的支持（如 SOA 管理和安全性）、提供更容易的开发集成逻辑的机制的工具，以及通用服务调用编程模型。下一部分将介绍 IBM 即将推出的下一代 ESB 产品中的一些支持。
正在推进的 IBM ESB 策略
IBM 最近宣布了新的 WebSphere Enterprise Service Bus 产品 (WebSphere ESB)、WebSphere Message Broker V6，以及新的组成 Service Component Architecture 和 Service Data Objects 的 SOA 编程模型。
IBM 继续相信企业服务总线是体系结构模式。客户根据他们的需求实现其唯一的 ESB。由于各个企业是不同的，因此每个企业对连接过程、应用程序和数据的要求是不用的。事实上，可以使用各种不同的 ESB 产品（WebSphere Application Server 及其 SIBus 功能、WebSphere Message Broker 和 WebSphere ESB）构建服务总线。WebSphere ESB 实际上是以 ESB 为中心的产品，可以帮助创建该模式的特定实例。
WebSphere ESB 和 WebSphere Message Broker 提供了各种预构建中介功能、可视化构造工具以及其他功能，远远超出了 SIBus 中的消息传递支持。WebSphere ESB 与 WebSphere Process Server 紧密集成，它的中介模型使用 SCA 和 Service Message Objects（对 SDO 的扩展，以包括消息 Header 和数据图形上下文）。
IBM 与其他行业合作伙伴合作，共同引入了对构造 SOA 应用程序的高级抽象，从而使您能够在不直接了解组件所使用的基础技术的情况下组装组件，然后通过中介属性在系统中自定义组件的实现。SCA 是与语言和技术无关的体系结构，使用这种体系结构，可以对服务进行组合，而不管用来实现组件的语言和技术。服务组件应该捕获用于组件的逻辑。可以定义组件之间的连接，以便支持对其他组件实现的延迟绑定；集成开发人员的工作重点是将服务组件连接在一起。SDO 补充了 SCA。它们提供了一种通用方法来帮助用户利用驻留在多个位置且具有各种格式的数据，这使得开发人员可以更容易地使用应用程序编程接口，而不必自己进行编写。
那么，对于 SIBus，WebSphere ESB、WebSphere Message Broker V6 和 SCA 意味着什么呢？SIBus 还是 WebSphere Application Server 的缺省 JMS 提供程序和核心消息传递平台。WebSphere ESB 和 WebSphere Process Server 在 WebSphere Application Server 的基础上添加了一些功能，并将 SIBus 用于核心消息处理。在为 WebSphere ESB 和 WebSphere Process Server 提供基本的基础结构时，您可以考虑 SIBus。IBM 增强了自己对目前将 SIBus 作为其 ESB 实现的核心部分的客户的承诺。随着时间的推移，SIBus 将不断发展，其编程模型将与 WebSphere ESB 相集成。
在设计 ESB 时，需求应该驱动 ESB 产品选择。WebSphere Application Server 及其 SIBus 功能为构建企业服务总线提供了基础，如我们的系列文章所述。您需要评估 SIBus 以及其他更高级的 ESB 产品，以确定什么对于构建您的 ESB 是最好的。
结束语
在这一系列文章中，我们介绍了如何使用 WebSphere Application Server V6 的 SIBus 中引入的 WebSphere Message Resources 来构建企业服务总线的核心功能。在这最后的一部分中，我们概述了本系列所介绍的场景、需求和功能，并且简单地展望了 IBM 的 ESB 技术的未来。
参考资料 学习
获得产品和技术
作者简介  | 
| |
Rachel Reinitz 是 IBM Software Services for WebSphere 中重点研究 Web 服务的高级 IT 咨询专家。Rachel 为客户和独立软件供应商提供咨询，向其讲解如何使用面向服务的体系结构和 Web 服务来实现他们的业务以及技术目标。她开发了 IBM 高级 Web 服务培训课程，并且经常出席会议。Rachel 同时也是一名经验丰富的极限编程指导，她有四年 XP 实践经历。她居住在加利福尼亚州的 Bay 区，喜爱徒步旅行、社交活动以及国际旅行。 |
| 
| |
Andre Tost 是 Software Group 的 Enterprise Integration Solutions 组织的一名高级技术人员，他在这个部门帮助 IBM 的客户建立面向服务的体系结构。他专长于 Web 服务技术。在开始从事目前的工作之前，他有十年的时间在 IBM 软件开发工作中担任各种合作伙伴启动、开发和构架设计方面的角色，目前他在 WebSphere Business Development 小组工作。他出生于德国，目前在美国明尼苏达州的罗彻斯特居住和工作。在业余时间，他喜欢和家人在一起，并且有空就去踢球或看球赛。 |
对本文的评价
| 
