ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 使用JMS和ESB构建强大而可靠的SOA之一

使用JMS和ESB构建强大而可靠的SOA之一

原创 Linux操作系统 作者:lambor_zhou 时间:2009-02-03 22:31:31 0 删除 编辑

引言

  面向服务的体系结构 (SOA) 永远不能建立在真空中。在任何实际的环境中,都必须考虑现有的 IT 环境,功能(和数据)的提供并不能简单地通过提供一组新服务来实现。因此,构建 SOA 的一个关键方面就是将现有应用程序分解为更小的块(即“服务”),这些块通过标准协议进行通信,并具有定义良好的接口。这样做的优势在于,此类环境更为灵 活,整个系统的各个部分之间并不存在紧密耦合。

  松散耦合且具有平台独立性的服务的概念通过使用企业服务总线(Enterprise Service Bus,ESB)得到了进一步发展。其中,ESB 充当使用不同数据和消息格式、网络协议和编程语言的服务之间的“粘合剂”。ESB 充当服务使用者和服务提供者之间的中间层,允许部署中介,以执行各种操作,如向交互应用服务质量或执行所需的数据转换。

  在本系列的文章中, 我们将了解一个 ESB 充当此类中间层的具体例子。我们将利用 IBM WebSphere Enterprise Service Bus (WebSphere ESB) V6.0.1 产品来链接服务使用者和服务提供者,同时使用 JMS 作为消息传递机制。在第一篇文章中,我们将简单了解一下 WebSphere ESB 产品及其工具环境,即 WebSphere Integration Developer V6.0.1。第 2 部分将描述实际的 ESB 场景,并说明如何构建服务使用者和服务提供者,而在第 3 部分,我们将演示如何构建运行于 WebSphere ESB 中的使用者和提供者之间的中介。您将学习如何部署和运行解决方案,我们将提供进行此操作所需的所有代码构件。

  企业服务总线和 Java Message Service

  SOA 由彼此进行通信的服务使用者和服务提供者组成。它们通常通过企业服务总线进行通信。每个服务具有服务定义,在其中描述如何从使用者接受消息和如何向其使用 者返回消息(“单向”服务时例外)以及其他一些事项。因此,构建 ESB 与消息传递有很大关系。一直以来,以稳健、快速而可靠的方式发送和接收消息是 IT 系统的一项关键要求,ESB 的到来并未改变这一点;它恰恰给解决方案带来了额外的要求——例如,支持描述消息格式的标准、服务间的事务交换等等。

  同时,基于 Java J2EE 平台的系统通常会利用 Java Message Service (JMS) API 来满足其消息传递需求。简单说来,JMS 描述如何将消息从一个应用程序发送到另一个应用程序,对服务的事务质量进行了潜在的利用。

  充 分考虑到很多应用程序已经在使用 JMS 了,而 SOA 内的服务又需要一种进行消息传递的方式,这样就能很好地理解 JMS 在 ESB 上下文中所扮演的角色。每个 ESB 都必须能够通过 JMS 从服务使用者接收消息,并将其转发到相应的服务提供者(通过 JMS 或其他协议,如 HTTP),反之亦然。而且,JMS 还定义了可发送的若干不同类型的消息。例如,Text 消息包含消息的字符串表示形式;Object 消息包含序列化的 Java 对象;Map 消息包含键/值对的映射,等等。Web 服务通常使用 SOAP 作为其消息格式,但很多应用程序都使用纯 XML。因此,ESB 必须支持各种网络和消息协议。图 1 显示了服务使用者和服务提供者可能支持的一系列协议组合。请注意,ESB 充当了这两者间的中间层,允许在不受协议限制的前提下连接任何使用者和提供者。

  图 1. SOA 中的消息和网络协议示例

  图 1. SOA 中的消息和网络协议示例

  如果设置 WebSphere ESB,以支持不同的组合,这正是我们将在本系列中讨论的内容。不过,首先让我们看一下该产品本身以及其主要组件。

  WebSphere ESB V6.0.1

  WebSphere ESB 产品是 IBM SOA Foundation 的一部分。尽管其版本号可能会让人觉得此产品已经存在很长时间,但该产品却是在 2005 年末首次发布,与其他已经存在的 WebSphere 产品系列成员共享很多组件。例如,它使用基于 J2EE 的 IBM WebSphere Application Server 作为其核心运行时。WebSphere Application Server 提供了一个 JMS 实现,该实现由 WebSphere ESB 进行了重用。它还使用了服务组件体系结构(Service Component Architecture,SCA)作为其基础编程模型,并与 WebSphere Process Server 共享 SCA 运行时。

  图 2 显示了 WebSphere ESB 及其基本组件的概况。

  图 2. WebSphere ESB 概况

  图 2. WebSphere ESB 概况

  WebSphere ESB 支持通过 JMS 的基本消息传递,可以通过 WebSphere Application Server 中的 MQLink 与 WebSphere MQ 进行通信。使用 SOAP over HTTP 和 SOAP over JMS 的 Web 服务是插入到 ESB 中的,支持很多 Web 服务标准和通过应用服务器提供的 UDDI 注册表。WebSphere ESB 不仅可以从标准 J2EE 客户端使用,也提供 C/C++ 和 .Net® 的客户端支持。而且,它还通过 WebSphere Adapter 提供了到各种遗留环境的连接。

  WebSphere ESB 和服务组件体系结构

  我 们在前面提到 WebSphere ESB 所使用的编程模型基于 SCA。SCA 描述了一个完整的服务编程模型,涉及到大量可采用相同的方式描述和访问的组件(即服务)。此类组件可以为 BPEL 流程、业务规则或传统 Java 组件等等。WebSphere ESB 向 SCA 模型引入了一个新的组件类型,即中介流组件。从 SCA 的角度而言,中介流组件与任何其他服务组件没有任何区别,因为中介组件具有以下特征:

  • 存在于模块中(更准确地说,存在于中介模块中,它采用这种方式部署到服务器运行时中)。
  • 具有接口,采用 Java 或 WSDL 描述。
  • 通过导出向客户端公开,导出可以有多个不同协议的绑定(我们将在以后对此进行讨论)。
  • 具有对其他服务的依赖关系(通过导入,导入也具有描述协议详细信息的绑定)。

  就某种程度而言,中介流编程模型是独一无二的;它支持访问和操作关于正在处理的服务消息的绑定特定信息(通常为 Header 类型的信息)。有关 SCA 及其编程模型的详细信息以及如何通过其构建和部署组件,请参阅 Building SOA solutions with the Service Component Architecture 系列文章。(在本系列的剩下部分中,我们将假定您已具有 SCA 的基本知识,因此我们将不会对已在其他地方得到详细阐述的内容进行复述。)

  中介流组件提供了一种服务组件的新实现,即中介流的实现。中介流通常使用可视流编辑器进行构建,用于通过一系列中介原语描述请求和响应消息流。这些原语可以读取和更改消息,或将其路由(“筛选”)到不同的目标位置。虽然您可以构建自己的自定义中介原语,该产品仍然提供了一系列用于以下用途的预定义原语:

  • XSLT 转换
  • 消息日志记录
  • 消息筛选
  • 数据库访问。

  图 3 显示了一个使用若干中介原语实现响应流的中介流组件实现。

  图 3. 中介流示例

  图 3. 中介流示例

  顺便说明一下,我们将在第 2 部分详细讲解创建此类流所需的各个步骤。

WebSphere ESB 和服务消息对象

  我们尚未讨论的是,消息“在总线中”时如何对其进行处理。也就是说,如何对发送到中介流组件的数据进行表示?答案是,每个消息到达中介流组件时,将立即被转换为服务消息对象。与此类似,在离开中介流组件前,会将其重新转换为消息的目标所要求的任何格式。

  服务消息对象是 Service Data Object (SDO) 规范的扩展,该规范描述了一种以独立于源的方式访问数据的方法。因此,并不会考虑消息是否通过 HTTP 或 JMS 或任何其他协议传入,也不会考虑消息是 SOAP 消息还是纯文本,而会始终将其转换为一种可由实际中介流实现(如中介原语)使用的通用格式。

  因此,SCA 提供了用于调用中介流组件的编程模型,而 SMO/SDO 则表示在此组件中处理的实际消息。这二者实现了紧密的协作。

  SCA 导出和导入绑定

  正如前面提到的,SCA 组件使用导入和导出与外部世界通信(即,与使用组件的客户端和组件的实现使用的其他服务通信)。对 WebSphere ESB 及其中介流组件而言,可以将导出视为 ESB 的入站端口,而将导入视为出站端口。

  例如,假定您有一个现有服务使用者和一个现有服务提供者,二者通过 SOAP over HTTP 进行通信。现在您希望向此连接中插入 WebSphere ESB 中介,以便能对通过的每个消息进行记录。通过创建中介流组件,并为其提供与目标服务相同的接口,就可以实现此目标。然后为导入创建 Web 服务绑定, 以引用目标服务的 WSDL(包括端点地址),从而创建指向现有 Web 服务的导入。也就是说,已将导入“绑定”到该 Web 服务。类似地,为导出创建 Web 服务,从而生成新 WSDL 文件,并构建一个指向中介流组件的端点。最后,部署此组件,并告知服务使用者使用新端点地址。消息现在将定向到 WebSphere ESB,通过一系列中介原语,然后转发到实际的目标 Web 服务。

  还记得我们曾提到每个消息都将成为总线中的一个 SMO 吗?Web 服务绑定是一段将传入 SOAP/HTTP 请求消息转换为服务消息对象的逻辑,而出站 Web 服务绑定则提供其反向逻辑;即,它将传出 SMO 转换回 SOAP/HTTP 消息。这些都是自动进行的。运行时知道入站消息的格式,因为这个消息是由相应的 WSDL 定义进行了全面的描述,运行时可以据此进行分析和处理。

  为了保证正确性,自定义绑定仅处理消息的正文部分。Header 字段由基础设施自动处理,将在不需任何编程的情况下在 JMS 消息和 SMO 之间进行转换。

  不过,如果传入的消息并不遵循 SOAP 之类的特定消息协议,会发生什么呢?例如,如果有 JMS 映射消息发送到导出,则不能使用默认绑定,因为不知道此映射的格式。此时自定义绑定就派上用场了。必须以 Java 类的形式提供从传入消息到 SMO 的转换,以执行相应的分析逻辑和构建正确的 SMO。在出站端(即导入)也应该进行相同的处理。自定义绑定实现知道如何获取 SMO 并将其转换为正确的格式。

  在本系列的第 2 部分和第 3 部分,我们将详细讨论自定义 JMS 绑定的示例(支持全部五种 JMS 消息类型的绑定),因此我们会再次讨论自定义绑定的话题,并演示如何将自定义绑定作为中介模块的一部分部署到运行时中。

  WebSphere Integration Developer V6.0.1

  WebSphere ESB 的目标之一是简化创建中介并将其插入到企业的消息流中。在某种程度上来说,这个目标是通过利用 SCA 编程模型实现的,该模型允许使用一个描述和部署机制处理不同类型的服务。SCA 规范还描述了用于将这些组件装配为较大的解决方案的方法。而且,我们希望支持以细粒度中介原语为基础构建的中介流组件。WebSphere Integration Developer V6.0.1 支持所有这些操作。

  我们在前面提供了使用多个原语的中介流组件实现的图。该工具也支持采用可视方式将中介流组件、导出和导入装配为中介模块,以便部署和安装到运行时中。例如,图 4 演示了如何使用装配编辑器来构建包含中介流组件的中介模块。

  图 4. 包含中介流的中介模块

  图 4. 包含中介流的中介模块

  前面提到的系列文章“Building SOA solutions with the Service Component Architecture”详细讨论了使用此工具的示例场景。我们还将在第 3 部分逐步说明如何构建中介模块。

  结束语

  在本文中,我们讨论了可以如何使用 WebSphere ESB 产品构建企业服务总线,该产品支持可用于连接到现有服务和新服务的各种消息和网络协议。其中一个协议就是 JMS。

  WebSphere ESB 基于新的服务组件体系结构,使用服务数据对象作为其内部消息格式模型。SCA 定义了绑定的概念,可利用绑定对客户端提供服务组件,并让其与其他组件进行通信。在采用五种不同的 JMS 消息类型的情况下,我们需要提供自定义绑定实现,以便支持任何消息格式。

  在本系列的其他两篇文章中,我们将提供一个示例,演示如何利用 WebSphere ESB 来处理 JMS 客户端和(基于 JMS 的)消息驱动 Bean 交换的消息。您将了解如何开发和部署自定义绑定实现,如何全程使用 WebSphere Integration Developer 作为工具环境来构建相应的解决方案。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9665688/viewspace-545179/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-11-18

  • 博文量
    28
  • 访问量
    23419