内容


IBM WebSphere 开发者技术期刊

使用 WebSphere Application Server V6 构建企业服务总线 —— 第 1 部分

WebSphere V6 消息传递资源入门

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

引言

目前,"企业服务总线"(ESB)是被广泛讨论并频繁阐述的术语,它表示了构建基于面向服务体系结构(SOA)解决方案时企业所使用基础架构的关键部分。简而言之,ESB 提供了连接企业内部及跨企业间新的和现有软件应用程序的功能,以一组丰富的功能启用管理和监控应用程序之间的交互。

IBM WebSphere Application Server V6 介绍了新的消息传递引擎,它包括许多构建企业服务总线必须的功能特性。ESB 以及 SOA 的架构方面在多种资源中得到描述(参阅 参考资料)。作为替代,我们将会关注这一新技术的实际应用,怎样使用 Messaging Resources 特性构建 ESB 的特定实例。

WebSphere Application Server V6 中存在超出 Messaging Resources 的能够有助于构建 ESB 的辅助特性(例如 EJB 客户机或 JMX MBeans)。在本系列文章中我们不会讲述这些内容。同样存在其他 IBM 软件产品,包括 WebSphere 产品,它们常常用于构建具有一些相同特性的 ESB —— 并且具有超出 WebSphere V6 Messaging Resources 提供的功能。

这是本系列的第一篇文章,我们将会从介绍新的消息传递引擎开始,并简要讲述它提供的主要功能特性。在接下来的文章中,我们将会深入研究每一种特性并且演示那种特性怎样有助于完成 ESB 场景。

WebSphere V6 Messaging Resources 是什么?

WebSphere Application Server V6 拥有用 Java™ 编写的全新的消息传递引擎。从 J2EE™ 角度看,该引擎成为应用程序服务器的缺省 JMS 提供程序。这意味着任何运用 J2EE 消息传递的应用程序组件(例如,消息驱动 bean)都能够运用这一引擎。其它 JMS 提供程序将继续受到支持,包括 WebSphere MQ。在我们的 ESB 场景中,我们将同时使用 WebSphere MQ 和 WebSphere V6 Messaging Resources 提供 ESB 功能。

WebSphere V6 Messaging Resources 统一支持排队、发布/预订、以及 Web 服务,并且在这种情况下为一些关键的消息传递和交互模式提供平台。例如,同步请求/响应消息传递和异步单向消息传递都受到支持。这样就建立了"集成总线"的概念;消息产生者和消息消费者之间通过与总线交互进行通信,而不是彼此直接通信。这一级别的间接寻址能够在不影响应用程序组件的情况下使集中管理与监控功能结合在一个局部实体中。接下来我们将对这方面进行更详细的研究。

新平台的重要特性就是使用各种协议向总线发送消息以及从总线接收消息。例如,在 HTTP 上消息能够作为基于 SOAP 协议的 Web 服务请求消息发送到总线上。接下来总线可以将消息转发至 JMS 消费者,例如消息驱动 bean。象其它实例,您可以向总线通路 WebSphere MQ 发送消息并且将它作为 EJB 方法调用转发至 EJB。消息的消费者和生产者因此完全降低了耦合度,包括消息以及传输协议在内。这样的耦合度的降低是 ESB 的核心优点。

提供支持的各种协议以及那些协议的格式转换是通过使用公用信息表示法而受到支持的,消息在流入总线时被转换为信息表示法。然而,在协议层和应用层常常需要其它形式的转换。例如,消费者也许将订单号称为 PO_NUM,而生产者也许将其称之为 PurchaseOrderNumber,所以必须编写提供那种转换的定制转换。Messaging Resources 为您提供了编写您自身转换以及其它定制总线功能的支持。

三种核心组件:总线,目的地,以及中介

位于其核心位置,消息传递引擎由三种主要组件组成:

  • 总线 充当消息的主要传输机制。就像之前描述的,消息的消费者和生产者并不直接交换消息;他们从总线上发送和接收消息。事实上如果当总线可能是分布在许多处理器和机器上时,应用程序与提供了可伸缩性的单总线实体进行交互(稍后将进行更详细的讨论)。管理员也可以配置一些单独应用程序的总线实例。
  • 每条总线包括目的地列表。目的地是每一条发送到总线上的消息的逻辑目标。您可以把目的地看作是队列及主题的泛化。消息的发送端与接收端就是这样区分开的:消息发送到目的地,将从接收端(客户)接收。当然,在 pub/sub 场景中多接收端可以损耗消息。

    WebSphere V6 Messaging Resources 提供了健壮、灵活的消息传递支持,包括了发送关于不同目的地的不同质量服务的能力,例如制定消息的持久性策略。

    重要的是,在接收端没有消费消息之前也能够将消息从一个目的地路由到另一个目的地。这样使得无需影响发送端和接收端就可以将消息的路径选择逻辑封装到总线中去。这一功能性使您能够实现基于 SOA 的 ESB 的主要特性之一:分离业务。消息的处理(或路由选择)是通过总线做到的,并且没有扰乱任何业务逻辑。
  • 第三种组件,中介,有助于分离业务。中介是经常与目的地相联系的一部分代码。中介代码在遍历目的地时对消息产生影响。基于公共 Java 消息表示法的程序设计模型是为编写中介而设的;Java 对象表示了消息及其属性。

当讨论公共 Java 消息表示法的时候,这一通用性在于消息的格式,不是转换为消息内容自身的公共数据模型;换句话说,是获得消息长度的通用方法,例如,PO_Number 标签。公共模型在下文中会进一步详述。

中介中两种最普通的功能:

  • 将信息数据从一种消息内容格式转换为另一种。如果消息的发送端和接收端支持的消息格式不完全相同,这将会很重要。可以编写中介来完成必要的转换运用,例如,XSLT 样式表。
  • 进行路由判定。中介能够读入消息的内容,基于这一内容,将消息路由到不同的目的地。

能够通过编写 Java 代码从头开始简单地开发中介,或者能够将它们根据现有的中介组装为处理器列表。在这一系列即将发表的文章中,我们将会说明您怎样才能开发自己的中介,提供中介范例,并且说明怎样组合处理器列表。目的地和中介的组合让您可以当消息在集成总线中传播时管理消息,从而为构建 ESB 提供重要功能。

图 1 说明目的地和中介的基本概念。

图 1. 目的地和中介
图 1 目的地和中介图。
图 1 目的地和中介图。

Web 服务

大量关于企业服务总线和面向服务体系结构的著作关注于 Web 服务。广泛地采用 Web 服务,SOA 的主要技术,很大程度上是由于他们的平台以及编程语言的独立性。Web 服务已经成为 J2EE 世界中的头等公民,特别是随着 J2EE Version 1.4 中 Web 服务的 Java API 的出现(为 WebSphere Application Server V6 所支持)。

位于其核心位置,Web 服务技术全部是关于应用程序之间交换消息的,因此 WebSphere V6 Messaging Resources 对 Web 服务的一流支持便有了意义。消息发送者能够很容易地成为 Web 服务客户机/请求程序,并且消息的消费者可以成为 Web 服务的提供程序。

WebSphere Application Server 管理控制台中支持的 WebSphere V6 Messaging Resources 拥有享用总线中服务和生成构件(专用侦听器和目的地)的 Web 服务描述语言(WSDL)文件的向导。这些向导能够接收来自 Web 服务请求程序的 Web 服务消息及(或)向 Web 服务提供程序发送 Web 服务消息。

HTTP 上的 SOAP 以及 JMS Web 服务上的 SOAP 都受到支持。目的地是用于表现 Web 服务客户机以及总线中的提供程序。中介能够影响 Web 服务消息。因此,WebSphere V6 Messaging Resources 使得 Web 服务消息能够得到管理与监听,包括动态路由选择以及转换方法,在总线中仅仅作为另一种消息类型。

此外,此处的目的是降低服务请求程序和提供程序的耦合度,所以附加的服务及管理质量能够应用于总线。重要的是,对于 Web 服务的程序设计模型没有施加任何影响。总线上的 Web 服务可能就像各种其它平台的 Web 服务一样被调用。例如,可以经由 JAX-RPC 调用 Web 服务。变化在于 SOAP 请求消息将会发送到总线上的目的地,而不是直接发送到服务。

从开发的角度看,客户机无法分辨出差别。客户机所需的唯一变化就是将 URL 地址从真实的服务改变为总线中的服务目的地。服务提供程序无需任何改变,并且服务可能是经由总线或直接通过 Web 服务客户机调用。服务中的业务逻辑并没受到影响。通过 WSDL 配置总线的 Web 服务不限于 J2EE 服务,并且可以使任何平台上符合 WS-I 的 Web 服务。

如果这一切您听起来相当的抽象,不要着急。我们将会在将来的文章中详尽描述这一主题,文章将会引领您按照一切必要的步骤完成这一工作。可以这样说,Web 服务是连接到总线上的主要资源。

多重协议,多重 API

在上述的内容中,我们阐释了总线目的地起到了虚拟连接到总线上的资源的主要方法的作用。这包括使用多重协议及 API 访问那些资源的能力;消息能够发送到协议上的总线并且经由另一个协议可以获得其消费者。

流程都是关于降低耦合度以及分离业务。客户机应该不必分辨出资源的定位,与什么协议彼此相应,以及什么 API 应该用于向其发送消息。这一切都能通过总线得以解决。在总线上配置作为(有效的)目的地的资源使得这一目标有实现的可能。使用 HTTP 上的 SOAP 可以将消息发送到目的地,或是使用 IIOP 上的 MQ 或 RMI,只是命名一些可能性。在任意的协议上消息的消费者也能够接收相同的消息,与其怎样到达总线无关。在将来的文章中这一评价将会成为讨论的重要的主题。

通用的消息格式

在总线中以协议独立的方式管理消息需要也是协议独立的数据表示格式。对于 WebSphere 消息传送引擎来说,按照这样的格式选择服务数据对象(SDO)。(详尽地描述 SDO 已经超出了本文的范围,所以请参阅参考资料部分中讨论了该主题的论文和文章。)

简单说明就是,SDO 描述了以独立于数据源的方式表示数据的方法;例如,数据是否源于 Web 服务调用或 JMS 客户机。一组 Java API 因访问 SDO 而存在并且消息的 SDO 模型用于表示关于消息的数据,例如长度、格式、头信息等等。每一条到达总线的信息都转换成 SDO 对象图。总线中的中介使用 SDO 程序设计模型操纵消息中的数据。

一切 SDO 的使用都是关于协议独立的。总线没有将消息的内容(例如,XML 标签)转换成规范数据模型;如果有必要进行标准化,可以编写定制中介。

应用程序服务器 + 消息传送 = ESB?

本文中描述的消息传递功能是作为 WebSphere Application Server V6 附带的一部分。在应用程序服务器中有效的持有该技术产生了性能的强大组合:您可以构建、组成加强的主机和可升级的应用程序及服务,如同主 J2EE 应用程序服务器所提供的,并且同时可以访问形成任意面向服务体系结构的先进的消息传递技术。

新的消息传递引擎充分利用了应用程序服务器的集群以及负载平衡的特性。在"消息传递引擎"中用实例证明了集成总线可以在同一台机器的多个进程中存在,或分为单独的物理逻辑单元。换句话说,业务实例和消息目的地是完全虚拟的,并且能够规定为极高程度的事务负载。

应用程序服务器以及消息传递引擎的安装与管理以相同的方式无缝生成。例如,在正规的应用程序服务器管理控制台中您定义并配置了总线上的消息目的地。此外,消息总线能够利用它的内部组件的基础运行时间。例如,中介以无状态会话 EJB 的形式配置到引擎中。这自动地使得中介交互、可升级、并且安全。

最终,一切消息传递引擎和应用程序服务器的工具都是公共有效的。Application Server Toolkit 与应用程序服务器一起并且为构建、配置、以及调试 J2EE 和消息传递解决方案提供了所需的工具。Rational® Application Developer V6 也为应用程序开发提供了大量成套的工具,包括 Web 服务、J2EE、XML 开发、数据库、UML 可视化、以及很多工具。

结束语

本文提供了 WebSphere Application Server V6 和企业服务总线中心消息传递引擎的高级描述。WebSphere V6 Messaging Resources 基于三种核心组件:集成总线,作为连接到总线的虚拟化资源方法的目的地,以及能够路由和操纵流经总线的消息的中介。在本系列文章的第二部分,我们将会为您示范怎样开始着手普通场景,设置总线和目的地,并且使用 JMS 连接总线。保持协调。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=58048
ArticleTitle=IBM WebSphere 开发者技术期刊: 使用 WebSphere Application Server V6 构建企业服务总线 —— 第 1 部分
publish-date=03012005