IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope: Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  WebSphere  >

WebSphere Business Integration Message Broker 循序渐进(一)

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 初级

娄丽军, 软件部售前工程师, IBM公司

2004 年 4 月 01 日

WebSphere Business Integration Message Broker是IBM业务整合解决方案的重要组成部分,为了让大家从技术上更好地使用和掌握该产品,我们推出该系列文章.

前言:WebSphere Business Integration Message Broker 是 IBM 业务整合解决方案的重要组成部分,为了让大家从技术上更好地使用和掌握该产品,我们推出该系列文章,共分三部分,第一部分介绍 Message Broker 的基本概念和基础架构,第二部分介绍其应用系统开发,第三部分从技术纵深的角度同大家分享一些有关 Message Broker 的性能和系统管理等方面的话题。

第一部分:Message Broker 基本概念和基础架构





回页首


1 Message Broker 设计理念和功能概述

WebSphere Business Integration(简称WBI) Message Broker(本文中简称MB) 是 IBM 的应用整合中间件,是 IBM WebSphere 业务整合解决方案的重要组成部分之一,用于企业应用整合领域。Message Broker 目前的最新版本是 V5.0,它的前身为 WebSphere MQ Integrator Borker V2.1。

谈到 Message Broker 的设计理念,我们有必要先来了解一下EAI(企业应用整合)的发展趋势和技术走向。每个企业在信息系统建设过程中必然涉及到多个应用系统(这些应用系统可能运行于不同的平台之上,并且采用的开发语言与模式也不同)之间的相互集成需求,也就是大家熟知的 EAI,因此对这些系统采用何种集成体系结构必须慎重考虑。当前大部分企业采用的应用系统之间的集成是一种点对点的体系结构,具体见下图:


点对点的应用系统集成结构的出发点很简单,当两个系统之间需要相互协作时,为这两个系统开发相应的连接组件(又称Adaptor或Connector)将二者互联,这种由简单出发的结构存在着严重的隐患:随着应用系统个数的增加,连接组件的数目将快速增长(总数将为n*(n-1)个连接组件,其中n为应用系统的个数),而且在不同应用系统之间由于缺乏自动提交请求的机制,必须在相关的连接组件内部固化请求的提交功能,应用系统之间存在着高度的藕合性,这为系统的维护带来了巨大的复杂性,任何一个系统的升级或改动都将影响到其它与之相关的应用系统的修改;同时当一个新的应用系统需要纳入整个应用集成体系时整个工作将变得非常复杂。

良好的 EAI 体系结构应该保证不同应用系统之间的高度内聚,同时又保持各个应用系统的相对独立性,系统之间存在着松散的藕合关系,基于 Application Hub (应用集线器)的 EAI 结构能够满足复杂的企业应用集成需求和发展的需求。


与点对点的 EAI 结构相比,在基于应用集线器的 EAI 体系结构中,连接组件的数目很少(在被集成的应用系统的总数为n的环境中,每个应用系统只存在一个对应于应用集线器的连接组件,使得连接组件的总数减少到n个);而且各相互集成的应用系统之间不存在直接的关联,所有的集成工作通过中央的应用集线器进行,当某应用系统需要与其它的系统集成时该应用程序发请求(一般通过消息的方式)给应用集线器,由应用集线器自动地将该请求转发给相应的目标系统进行处理后将结果返回给请求者。在这种体系结构中,系统的维护非常简单,每一个应用系统的更新和修改都能够实时地实现,同时当新的应用系统出现时能够简便的纳入到整个IT环境当中,与其它的应用系统相互协作,共同为用户提供服务。

Message Broker 就是采用这种设计理念,它首先保证在一个异构的环境中实现信息稳定、可靠的传输,屏蔽掉用户实际中的硬件层、操作系统层、网络层等相对复杂、烦琐的界面,为用户提供一个统一、标准的信息通道,保证用户的逻辑应用和这些底层平台没有任何关系,最大限度地提高用户应用的可移植性、可扩充性和可靠性;最重要的是它提供一个基于 Application-Hub 的先进应用整合理念,最大限度地减少应用系统互联所面临的复杂性。基于 WBI Message Broker 系统的实现维护都相对简单,保证每一个应用系统的更新和修改都能够实时地实现,真正体现了应用整合的精髓;同时当新的应用系统出现时能够简便的纳入到整个 IT 环境当中,与其它的应用系统相互协作,共同为用户提供服务,是我们实现企业应用互联和应用整合的最佳实现方案。

由于"Hub&Spoke"模式的采用,Message Broker 可以将复杂的网状结构变为星型结构,大大简化系统配置;它为各种应用提供一个统一借口,从而大大减少系统间接口的个数;同时,它可以作为一个数据中心,提供各种数据处理服务,如:数据的计算、过滤、数据库操作等;它可以实现各种不同数据格式之间的转换,如:自定义格式、传统数据格式与XML格式之间的转换,针对不同系统所处理的消息格式各不相同的特点,它提供了专门的消息格式解析器在不同的消息格式之间按照预先定义好的转换规则进行自动的格式转换,然后将结果自动路由到目标应用系统。它提供强大的连接性,利用各种适配器,可以与多种应用系统进行无缝连接,如SAP, Siebel, Notes, SWIFT, People Soft, I2 等。





回页首


2 Message Broker 的基础架构

2.1 Message Broker 的运行环境组成部件


如图所示,在 MB 的运行环境中,主要组成部件有:Broker(消息代理)、Execution Group(执行组)、Broker Domain(代理域)、Configuration Manager(配置管理器)、User Name Server(用户名服务器)等组成,下面逐一介绍这些部件的功能。

2.1.1 Broker:消息代理

Broker(消息代理): 是 MB 的消息处理引擎,它提供 MB 的所有运行时服务,在 Windows 系统上它是一个系统服务,在 Unix 平台上它表现为一个后台进程。应用程序利用与 MQ 的连接和队列将消息发送到消息代理,代理根据消息集(Message Set)和消息流(Message Flow)的定义,来路由每个消息,并且对消息进行各种处理,必要时同时按照接收端需要的消息格式进行格式转换。

Broker 与 Broker 之间,Broker 和 Configuration Manager(简称CM)之间通过普通的 MQ 发送和接收类型的消息通道进行通讯。

在一个主机上可以创建一个或多个 Broker。每个 Broker 需要一个数据库,利用数据库来存储 Broker 需要和相关的信息,其中包括:有关 Broker 中定义的各种资源的控制数据,例如,已经部署的消息流等。因此,在创建 Broker 之前,必须先创建一个数据库并且赋予Broker 用户对其应有的权限,这样在创建 Broker 时会在数据库中建立所需要的表。Broker 使用 ODBC 与数据库连接。

每个 Broker 还需要一个队列管理器,并且多个 Broker 之间是不能共享同一个队列管理器的,每个 Broker 必须有自己特定的、唯一的队列管理器。每个 Broker 只能被一个配置管理器(CM)控制。当你使用 MB 的开发环境进行开发时,需要在 Workbench 的 Broker 拓扑栏中,"创建"一个 Broker,这里的创建严格上说是注册Broker,是将您利用 MB 命令或工具创建的 Broker 进行注册,所以是指同一个 Broker。在注册Broker之后,你要将配置信息的变化部署到Broker中。部署操作是非常重要的,它的作用体现在若干方面:它将启动 Broker 和 CM 之间的通讯;将配置信息从 CM 发送到 Broker;并且将其保存到配置存储库中;更为重要的是,它将初始化 Broker,使其为执行消息流做好准备。

2.1.2 Configuration Manager:配置管理器

Configuration Manager(配置管理器):CM 是工作台、配置存储库和 Broker 之间的一个接口,它维护 Broker Domain 的配置信息,向Broker 提供初始化配置信息以及之后的变化信息。配置管理器是 MB 用于管理那些组成 Broker Domain 的全部部件和资源的核心运行时部件。配置管理器的主要功能有:

  • 维护配置存储库中的详细配置信息,它提供配置存储库所有部件的集中记录;
  • 向 Broker 部署 Broker 的拓扑结构和消息处理操作,Broker Archive(归档)文件通过配置存储库部署到 Broker 的执行组中;
  • 产生部署结果和 Broker 状态的报告;
  • 使用 MQ 通讯服务与 Broker Domain 中的其他组件通讯。

对每一个 Broker Domain 必须创建一个配置管理器,配置管理器只在 Windows 平台上运行。每个配置管理器也需要一个数据库和一个队列管理器,并且可以和 Broker 共享队列管理器。配置管理器和 Broker 之间也需要通过 MQ 之间的消息通道进行通讯。

与 MB 版本2不同的是,配置管理器本身不再存储任何配置信息,它只用来进行控制和部署,在 MB V5.0中,配置信息被存储在Configuration Repository(配置存储库)中,它是一个安装了版本控制系统的文件系统,可以放在共享介质上被多个用户共享。

2.1.3 Broker Domain:消息代理域

Broker Domain(消息代理域):共享相同配置的若干 Broker 组成一个消息代理域,每个消息代理域由一个唯一的配置管理器来控制,在一个消息代理域中,可以创建、启动一个或多个 Broker,和一个可选的 User Name Server。域中的 Broker 和配置管理器使用建立在数据库表之上的配置存储库来存储和共享域中组件和资源的相关信息。

一台计算机上可以运行多个代理程序,但每一个被定义的代理程序都必须使用自己的队列管理器。所有这些代理程序都可以在一个管理域(administrative domain)内进行管理。域是一组代理程序的管理范围,它可以只限于一台计算机,也可以包括大量不同的计算机,一个域内的所有代理程序共享同一拓扑结构并能够在彼此之间进行通信。对域进行管理所需要的信息都存储在配置管理器(configuration manager)内部,这样的配置管理器在每个管理域内有一个且只有一个。通过一个 GUI 能够对配置管理器进行访问,而通过配置管理器可以对现有的系统定义进行查看和修改。

2.1.4 Execution Group:执行组

Execution Group(执行组):执行组是若干消息流的组合,是消息流运行引擎。每个执行组是一个独立的进程,这样,在同一个执行组中的消息流就可以做到在运行时相互独立;在一个执行组内部,消息流在不同的线程池内运行,为了提高性能,我们可以通过设置每个消息流的运行实例的个数来指定每个消息流的线程池的大小。

2.1.5 Administration Agent: 管理代理

配置管理器并不在域内直接对 Broker 进行配置,而是访问每个 Broker 中都有的管理代理(administrative agent)。当一个 Broker 第一次在一台计算机上安装完以后,配置管理器将使用管理代理从配置存储库中获得所需要的配置信息,并将其应用于有关的定义。这些定义将被存储在一个Broker的高速缓存之中,任何需要进行的更新将排队进入管理代理程序并被用于 Broker 配置的刷新。

每个 Broker 只有一个控制器进程,而且其设计必须确保完全可靠,以保证 Broker 能够按照要求运行。管理代理发出请求(如启动一个消息流运行引擎),控制器执行这些请求。如果控制器进程失败,一个新的控制器进程将被启动,这一新进程将通过消除孤立的进程(如管理代理和任何消息流运行引擎)来整理以前的进程,并重新启动新的实例。管理代理在失效时也将重新启动一个 Broker 的执行组。当一个执行组的线程出现一个可以导致该执行组内所有线程关闭的未能捕获的例外时,这种情况就会发生,管理代理随后将重新启动该执行组。

2.1.6 User Name Server:用户名称服务器

User Name Server(用户名称服务器): 任何关键系统的一个重要的组成部分就是通过提供一个有效的安全机制来确保资产安全的能力。系统的安全性功能必须有效地保证没有获取授权的用户不能对资产进行使用,而且必须保证获得授权的用户能够访问这些资产。系统安全性的管理功能必须易于使用,保证管理员在实现安全性功能时不会产生错误。

MB中包含了一个特殊的被称为用户名称服务器的部件,用于定义和控制产品授权用户和组的列表,这一产品来自底层操作系统的安全定义。为使处理变得简单,用户名称服务器将只在域内的一台计算机上进行安装,不需要在这台计算机上定义任何代理程序,用户名称服务器将从这台计算机上获得完整的用户和组列表,在此列表基础上才会建立访问控制列表。

用户名称服务器是一个可选的运行时组件,它提供 Publish/Subscribe 操作相关的用户和组的安全控制。当你使用 MB 的 Publish/Subscribe 功能时,用户名称服务器用来实现与消息主题相关的安全控制,例如控制谁可以发布哪个主题,谁可以订阅哪个主题。用户名称服务器不需要数据库,但它同样也需要一个队列管理器,并且可以和 Broker、CM 共享同一个队列管理器,它和Broker、CM之间的通讯也是通过MQ的消息通道来实现。

2.2 Message Broker的开发环境-Workbench

在 MB 版本5.0中,提供了新的开发工具 Message Brokers Toolkit for WebSphere Studio 代替了V2中的 Control Center(控制中心),它是建立在 WebSphere Studio Workbench 基础上,新的开发工具的引入达成了与整个 WebSphere 产品家族开发平台的统一,都建立在一个统一的基础架构之上,使得用户的开发环境和开发体验更加一致。

该开发工具仍然使用 MQ Java Client 的方式与配置管理器进行连接,每个开发客户端可以同时和多个配置管理器进行连接。



关于作者

娄丽军,IBM公司软件部售前工程师,1998年加入IBM公司软件部,四年来一直从事IBM通讯及业务整合中间件(WebSphere Business Integration家族)产品的技术支持工作,是软件部从事该领域技术支持时间最长的工程师之一,拥有WebSphere Business Integration相关的产品经验,这些产品包括WebSphere MQ家族的所有产品:MQSeries, MQ Integrator, MQ Workflow以及CrossWorlds等,并具有很多大型项目的支持经验,曾参与国家税务总局,人民银行清算系统、华夏银行电子联行系统、中国联通计费系统、海关与国家税务总局互连系统,以及公安部、铁道部、中信实业银行、电信等重要客户的有关项目的技术支持。




对本文的评价










回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款