WBIMB技术白皮书

《WBIMB技术白皮书》由会员分享，可在线阅读，更多相关《WBIMB技术白皮书（28页珍藏版）》请在装配图网上搜索。

1、WebSphere Business Integration Message Broker循序渐进第一部分：Message Broker基本概念和基础架构1 Message Broker设计理念和功能概述Message Broker是IBM的应用整合中间件，是IBM WebSphere 业务整合解决方案的重要组成部分之一，用于企业应用整合领域。Message Broker目前的最新版本是V6.1，它的前身为WebSphere MQ Integrator Borker V2.1。谈到Message Broker的设计理念，我们有必要先来了解一下EAI（企业应用整合）的发展趋势和技术走向。每个企业

2、在信息系统建设过程中必然涉及到多个应用系统（这些应用系统可能运行于不同的平台之上，并且采用的开发语言与模式也不同）之间的相互集成需求，也就是大家熟知的EAI，因此对这些系统采用何种集成体系结构必须慎重考虑。当前大部分企业采用的应用系统之间的集成是一种点对点的体系结构，具体见下图：点对点的应用系统集成结构的出发点很简单，当两个系统之间需要相互协作时，为这两个系统开发相应的连接组件(又称Adaptor或Connector)将二者互联，这种由简单出发的结构存在着严重的隐患：随着应用系统个数的增加，连接组件的数目将快速增长（总数将为n*(n-1)个连接组件，其中n为应用系统的个数），而且在不同应用系统

3、之间由于缺乏自动提交请求的机制，必须在相关的连接组件内部固化请求的提交功能，应用系统之间存在着高度的藕合性，这为系统的维护带来了巨大的复杂性，任何一个系统的升级或改动都将影响到其它与之相关的应用系统的修改；同时当一个新的应用系统需要纳入整个应用集成体系时整个工作变得非常复杂。良好的EAI体系结构应该保证不同应用系统之间的高度内聚，同时又保持各个应用系统的相对独立性，系统之间存在着松散的藕合关系。基于Application Hub(应用集线器)的EAI结构能够满足复杂的企业应用集成需求和发展的需求。与点对点的EAI结构相比，在基于应用集线器的EAI体系结构中，连接组件的数目很少（在被集成的应用系

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

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

6、务，是我们实现企业应用互联和应用整合的最佳实现方案。由于”Hub&spoke”模式的采用，Message Broker可以将复杂的网状结构变为星型结构，大大简化系统配置；它为各种应用提供一个统一借口，从而大大减少系统间接口的个数；同时，它可以作为一个数据中心，提供各种数据处理服务，如：数据的计算、过滤、数据库操作等；它可以实现各种不同数据格式之间的转换，如：自定义格式、传统数据格式与XML格式之间的转换，针对不同系统所处理的消息格式各不相同的特点，它提供了专门的消息格式解析器在不同的消息格式之间按照预先定义好的转换规则进行自动的格式转换，然后将结果自动路由到目标应用系统。它提供强大的连接性，利

7、用各种适配器，可以与多种应用系统进行无缝连接，如SAP, Siebel, Notes, SWIFT, People Soft, I2 等。2 MB的基础架构2.1 MB的运行环境组成部件如图所示，在MB的运行环境中，主要组成部件有：Broker、Execution Group、Broker Domain:、Configuration Manager:、User Name Server等组成。2.1.1 Broker：消息代理Broker(消息代理): 是MB的消息处理引擎，它提供MB的所有运行时服务，在Windows系统上它是一个系统服务，在Unix平台上它表现为一个后台进程。应用程序利用与M

8、Q的连接和队列将消息发送到消息代理，代理根据消息集(Message Set)和消息流(Message Flow)的定义，来路由每个消息，并且对消息进行各种处理，必要时同时按照接收端需要的消息格式进行格式转换。Broker与Broker之间，Broker和Configuration Manager之间通过普通的MQ发送和接收类型的消息通道进行通讯。在一个主机上可以创建一个或多个Broker。每个Broker需要一个数据库，利用数据库来存储broker需要和相关的信息，其中包括：有关Broker中定义的各种资源的控制数据，例如，已经部署的消息流等。因此，在创建Broker之前，必须先创建一个数据库

9、并且赋予Broker用户对其应有的权限，这样在创建Broker时会在数据库中建立所需要的表。Broker使用ODBC与数据库连接。每个Broker还需要一个队列管理器，并且多个Broker之间是不能共享同一个队列管理器的，每个Broker必须有自己特定的、唯一的队列管理器。每个Broker只能被一个CM控制。当你使用MB的开发环境进行开发时，需要在Workbench的Broker 拓扑栏中，”创建”一个Broker，这里的创建严格上说是注册Broker，是将您利用MB命令或工具创建的Broker进行注册，所以是指同一个Broker。在注册Broker之后，你要将配置信息的变化部署到Broker

10、中。部署操作是非常重要的，它的作用体现在若干方面：它将启动Broker和CM之间的通讯；将配置信息从CM发送到Broker；并且将其保存到配置存储库中；更为重要的是，它将初始化Broker，使其为执行消息流做好准备。每个Broker只能由一个配置管理器控制。2.1.2 Configuration Manager：配置管理器Configuration Manager(配置管理器)：CM是工作台，配置存储库和Broker之间的一个接口，它维护Broker Domain的配置信息，向Broker提供初始化配置信息以及之后的变化信息。配置管理器是MB用于管理那些组成Broker Domain的全部部件

11、和资源的核心运行时部件。配置管理器的主要功能有： 维护配置存储库中的详细配置信息，它提供配置存储库所有部件的集中记录； 向Broker部署Broker的拓扑结构和消息处理操作，Broker archive(归档)文件通过配置存储库部署到Broker的执行组中； 产生部署结果和Broker状态的报告； 使用MQ通讯服务与Broker Domain中的其他组件通讯。对每一个Broker Domain必须创建一个配置管理器，配置管理器只在Windows平台上运行。每个配置管理器也需要一个数据库和一个队列管理器，并且可以和Broker共享队列管理器。配置管理器和Broker之间也需要通过MQ之间的消息

12、通道进行通讯。与V2不同的是，配置管理器本身不再存储任何配置信息，它只用来进行控制和部署，在MB V5.0中，配置信息被存储在Configuration Repository（配置存储库）中，它是一个安装了版本控制系统的文件系统，可以放在共享介质上被多个用户共享。2.1.3 Broker Domain：消息代理域Broker Domain（消息代理域）：共享相同配置的若干Broker组成一个消息代理域，每个消息代理域由一个唯一的配置管理器来控制，在一个消息代理域中，可以创建，启动一个或多个Broker，和一个可选的User Name Server。域中的Broker和配置管理器使用建立在数据库

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

14、查看和修改。2.1.4 Execution Group：执行组Execution Group(执行组)：执行组是若干消息流的组合，是消息流运行引擎。每个执行组是一个独立的进程，这样，在同一个执行组中的消息流就可以做到在运行时相互独立；在一个执行组内部，消息流在不同的线程池内运行，为了提高性能，我们可以通过设置每个消息流的运行实例的个数来指定每个消息流的线程池的大小。2.1.5 Administration Agent: 管理代理配置管理器并不在域内直接对Broker进行配置，而是访问每个Broker中都有的管理代理（administrative agent）。当一个Broker第一次在一台计算

15、机上安装完以后，配置管理器将使用管理代理从配置存储库中获得所需要的配置信息，并将其应用于有关的定义。这些定义将被存储在一个Broker的高速缓存之中，任何需要进行的更新将排队进入管理代理程序并被用于Broker配置的刷新。每个Broker只有一个控制器进程，而且其设计必须确保完全可靠，以保证Broker能够按照要求运行。管理代理发出请求（如启动一个消息流运行引擎），控制器执行这些请求。如果控制器进程失败，一个新的控制器进程将被启动，这一新进程将通过消除孤立的进程（如管理代理和任何消息流运行引擎）来整理以前的进程，并重新启动新的实例。管理代理在失效时也将重新启动一个Broker的执行组。当一个执

16、行组的线程出现一个可以导致该执行组内所有线程关闭的未能捕获的例外时，这种情况就会发生，管理代理随后将重新启动该执行组。2.1.6 User Name Server：用户名称服务器User Name Server(用户名称服务器): 任何关键系统的一个重要的组成部分就是通过提供一个有效的安全机制来确保资产安全的能力。系统的安全性功能必须有效地保证没有获取授权的用户不能对资产进行使用，而且必须保证获得授权的用户能够访问这些资产。系统安全性的管理功能必须易于使用，保证管理员在实现安全性功能时不会产生错误。MB中包含了一个特殊的被称为用户名称服务器的部件，用于定义和控制产品授权用户和组的列表，这一产品

17、来自底层操作系统的安全定义。为使处理变得简单，用户名称服务器将只在域内的一台计算机上进行安装，不需要在这台计算机上定义任何代理程序，用户名称服务器将从这台计算机上获得完整的用户和组列表，在此列表基础上才会建立访问控制列表。用户名称服务器是一个可选的运行时组件，它提供Publish/Subscribe操作相关的用户和组的安全控制。当你使用MB的Publish/Subscribe功能时，用户名称服务器用来实现与消息主题相关的安全控制，例如控制谁可以发布哪个主题，谁可以订阅哪个主题。用户名称服务器不需要数据库，但它同样也需要一个队列管理器，并且可以和Broker、CM共享同一个队列管理器，它和Bro

18、ker、CM之间的通讯也是通过MQ的消息通道来实现。2.2 MB的开发环境-Workbench在MB版本5.0中，提供了新的开发工具Message Brokers Toolkit for WebSphere Studio代替了V2中的Control Center(控制中心)，它是建立在WebSphere Studio Workbench基础上，新的开发工具的引入达成了与整个WebSphere产品家族开发平台的统一，都建立在一个统一的基础架构之上，使得用户的开发环境和开发体验更加一致。该开发工具仍然使用MQ Java Client的方式与配置管理器进行连接，每个开发客户端可以同时和多个配置管理器

19、进行连接。第二部分：MB的应用系统开发3 MB的应用系统开发对MB的应用开发主要包含两部分，一部分是对消息流的开发，另外一部分是对消息格式的定制和开发。3.1 消息流的开发为了实现对消息的各种计算处理，我们要进行消息流的定制和开发。3.1.1 与消息流开发相关的基本概念在作消息流的开发时，首先需要了解的主要概念有：3.1.1.1 消息流的基本概念Message Flow(消息流)：在MB中对消息的运算处理、格式转换和路由等功能是通过消息流实现的，每个消息从输入MB到从MB中输出，都将被一个消息流处理，然后发往目的应用系统。消息流由各种消息处理节点(Message Processing Node

20、) 组成，消息处理节点可对消息进行各种处理操作，节点与节点相连，便组成了一个消息流。 3.1.1.2 消息处理节点的基本概念Message Processing Node（消息处理节点）：在MB中，对消息的所有计算和处理是通过消息节点实现的，消息节点实际上是被Broker运行环境调用的动态连接库（DLL），通过ESQL语句对消息进行操作，通过对消息节点属性的客户化处理，将使节点能够对流经自己的消息执行特定的功能。例如：在一个执行过滤操作的节点，过滤语句是通过节点的客户化处理实现的，这一客户化处理过程特别指定适当的消息作为过滤的对象，并说明过滤操作的内容。在一个MQInput节点中，相关MQ队列

21、的名称是作为客户化消息的一部分被提供的，一同被提供的信息还包括消息流的事务处理属性等。这些消息处理节点不仅对消息流内的消息数据进行操作，也能够访问消息流之外的信息，如访问一个数据库等。每个节点拥有自己的不同类型的端（Terminal），这些端通过连接器（Connector）在逻辑上被连接在一起，通过对选定的节点进行设计和配置，从而建立一个完善的处理环境。消息节点拥有一组用于从连接器处接收消息或将消息发送给连接器的端，常见的端类型包括接收消息的输入端、发送消息的输出端以及当消息处理过程中发生错误或出现意外情况时进行消息发送的故障端，通过故障端可以规定当消息流中的某一特定节点出现故障时系统将采取什

22、么动作。连接器的作用是可以将任意数量的节点捆绑在一起，在一个Broker实例的内部构成一个消息流。消息流由一个输入节点发起，该节点启动一个流经消息流的消息，例如，通过MQInput节点开始一个消息流，它从一个MQ队列中读取一个消息，然后进行后续的处理，最后通过MQOutput节点将处理完成的消息发送到另一个输出队列中。3.1.1.3 消息处理节点的类型和功能MB提供了多种类型的消息处理节点，用于对消息进行不同的处理。如果MB缺省提供的消息处理节点仍无法满足您的特殊需求，MB支持你创建客户化的节点并将其插入到MB系统之中。接下来，我们将简略描述节点的主要常用类型及每种节点的功能。i 触发和初始化

23、常用的可以提供这一功能的节点是MQInput节点，对队列的每个消息流必须以MQInput节点开始。MQInput节点有一个输入(input)端，输出(output)、失败(failure)和捕获(catch)三个输出端；它使用一个MQGET请求将消息从MQ队列中取出，然后使用输出端将消息流引导至下一个节点；如果出现了错误，则将其引导至故障端；第三种端被称为捕获端，当消息流中随后出现例外情况并且不能得到适当处理以至于接近失效时，这一端将被启动。如果多个MQInput节点都在对一个MQ队列进行读取操作，有可能会出现与消息先后顺序有关的问题。另外，MqeInput、SCADAInput等也是针对特殊

24、协议的特殊的输入节点。i 检查和过滤能够提供这些功能的基本节点类型是检查（Check）节点和过滤（Filter）节点。检查节点检查消息中的消息类型规格是否与某些或全部域（domain）、集（set）和类型（type）所期待的属性相匹配。通过这一方式，可以对消息的RFH2头信息和其他标准特性进行评估。消息流经输入端，如果检查是成功的，消息将流经匹配端；否则，它们将被引导至故障端。过滤节点使用一个SQL表达式作为决策标准，根据内容对输入的消息进行评估。这种节点可能使用的端包括输入（in）端、实（true）端、伪（false）端、未知（unknown）以及故障端。输入（in）端、实（true）端、伪

25、（false）端的含义从字面上就可以理解。如果评估的结果是不确定或未知，则消息会流向未知端。如果在评估过程中出现错误（如发生算术溢出），则消息会被引导至故障端。i 消息处理能够进行消息处理的基本节点类型是计算（Compute）节点、映射(Mapping)节点、析取（Extract）节点、ResetContentDescriptor等节点。计算节点是可以对消息进行修改的节点，它的用途是对消息进行逻辑运算，在作逻辑运算时，可以使用ESQL语言对消息进行处理。映射节点的用途也可以对消息进行修改，它的用途是对消息进行格式转换或创建新的消息，它能够以一种消息类型作为输入，经过转换后以另一个不同的消息类型

26、将其输出，在创建新消息时可能需要用到输入消息的内容或者可能的来自外部关系数据库的数值。要注意的是，在映射节点中能修改的是消息体的内容以及Environment和ExceptionList的内容，但是不能修改消息头的内容，只有Compute节点可以修改消息头的内容。析取节点对输入消息进行选择、拷贝和修改，创建一个新的输出消息。ResetContentDescriptor节点的用途是使用同一消息流内部的另一个解析器类型对消息进行解释。这一节点的功能类似于将消息从一个MQOutput节点传送到一个MQInput节点。i 外部数据库操作可以执行外部数据库操作的基本节点类型是数据插入（DataInser

27、t）节点、数据更新（DataUpdate）节点、数据删除（DataDelete）节点、数据库（Database）节点以及数据仓库（Warehouse）节点。这些节点都专门用来访问数据库并对数据库进行操作的，所有这些节点都拥有以下类型的端：输入端、输出端和故障端。所有使用这些节点进行的操作可以作为由MQ协调的全局逻辑单元的一部分，它们也可以作为单独的事务来处理。要注意的是，所有这些节点都不能改变流经自己的消息。数据插入节点可以将一个新行插入到一个特定的数据库中。消息中所包含的某些信息可以作为插入内容的一部分，或者消息可以只起到一个触发器的作用，数据插入节点的顺序很可能是跟在一个过滤节点的后面，插

28、入动作的完成是通过一个内部生成的SQL语句实现的。数据更新节点可以更新某一特定数据库中一行或多行的数值，更新操作也是通过一个内部生成的SQL表达式完成的。数据删除节点可以从某一指定数据库的数据表中删除一个或多个行，消息在处理过程中不会被改变。输入消息中的数据可以被用在ESQL表达式中，以说明将从数据库中删除什么样的数据。数据库节点可以对某一指定的数据库执行某一数据库操作，它不会对消息进行改变，消息从节点的输入端流到输出端。消息中的数据值可以被包括在执行数据库操作的SQL表达式之中。由于数据插入（DataInsert）、数据更新（DataUpdate）和数据删除（DataDelete）节点的功能

29、由数据库（Database）节点都可以实现，因此，数据库节点的使用频率较高。数据仓库节点与数据插入节点类似，用于存储在一个消息数据仓库中流经代理程序的消息。消息被存储在数据仓库中的目的可以是为了审查，或对消息进行离线处理或批处理，另一个使用数据仓库的理由是对流经消息代理程序的数据进行全面的数据挖掘（Data Mining）或数据分析（Data Analysis）。消息添加到数据仓库中的数据库是通过一个SQL插入语句完成的，消息内容的格式可以有很大的不同，我们必须根据消息数据仓库中消息数据的最终用途对所要求的格式进行评估。可以将消息数据仓库仅仅作为消息的临时存储地点使用，而且数据库不需要知道消息

30、的内容，在这种情况下，消息可以以BLOB的形式存储在数据库中。另一方面，也可以要求数据库对消息字段中的某些单元进行复杂的处理。在这种情况下，数据库需要知道消息字段和消息头中所包含的信息，以对存储的数据进行处理。i 决策和路径选择具有这一功能的基本节点类型是MQOutput节点、MQReply节点以及Publication节点。MQOutput节点是Broker内部消息流的终点。在这个节点，消息将会通过一个MQPUT MQI调用被写入到一个MQ队列之中，根据消息中所包含的信息，消息可以被写入到一个指定的固定队列，或被发送到一个应答队列，还可以指定一个目的队列的列表。MQReply节点是MQOut

31、put节点的特殊版本，在消息需要被输出到在消息头中Reply字段规定的MQ队列中时，可以使用MQReply节点。发布（Publication）节点也可以作为消息流的终点，用于将消息发送给已定义了发布和订阅（Publish and Subscribe）服务的订阅者。流经发布节点的消息是发布/订阅消息流的一部分，发布节点将根据主题和内容判断消息是否与订阅者的要求相匹配，并将匹配的消息直接发送给本地的订阅者，或将消息引导至其他的代理程序，这些代理程序再进行同样的匹配处理。i 错误处理和跟踪拥有这一功能的基本节点类型有三种，分别是Throw节点、Trace节点和TryCatch节点。Throw节点只有

32、一个输入端，在消息流的内部用于处理例外情况。这些例外情况可能是早些时候TryCatch节点在消息流中捕获的，或者可能会引起该特定消息的处理中断和相关事务处理活动的重新运行。Throw节点可用于将例外情况（根据消息的内容进行判断）丢弃，防止消息流的下游出现更多的失效。TryCatch节点的用途是防止下游节点出现的对消息或事务处理过程的例外终止处理，当例外返回到作为消息流根节点的MQInput节点时，这种情况是有可能发生的。消息通过输入端被接收，通过Try端被不加改变的转发出去。如果例外被TryCatch节点捕获，那么它将通过catch端（如果已被连接）被传播出去，随后就可以对例外进行错误处理。如

33、果消息流中发生的例外没有被其他节点（如TryCatch节点）捕获，那么它将会被MQInput节点捕获，因为该节点是这一线程的发起者，该节点的catch端将会把这一消息传播出去。Trace节点用于帮助消息流的调试。它拥有一个输入端和一个输出端，输出端将输入消息不加修改地发送出去，Trace节点会将一个跟踪记录写入某一指定的地点，通过跟踪记录我们可以分析一个消息在消息流内走过的路径。我们可以使用多种选项确定跟踪格式，例如可以选择某个操作系统文件，MB的错误日志等作为输出对象。i 其他类型的消息处理节点除了上述我们常用的节点类型之外，MB还缺省提供其他一些类型的消息处理节点，如：MQeInput节点

34、和MQeOutput节点，用于用MQ Everyplace产品输入/输出的节点；SCADAInput节点和SCADAOutput节点，用于使用一种专门的协议SCADA协议输入/输出的节点；HTTPInput节点、HTTPReply节点和HTTPRequest节点，用于Web Service支持的节点；AggregateControl节点、AggregateReply节点和AggregateRequest节点，用于输入/输出消息的聚合处理等。i 第三方或插入消息处理节点以上描述的节点都是随MB缺省提供的，用户可以根据自己的特殊需求，开发客户化的消息处理节点，来加强消息代理程序内部消息流的处理。这

35、些节点的设计必须与MB的消息流框架（Message flow Framework）的要求相匹配，这样才能够将新的节点加入到MB Workbench之中，这种节点可能是以C语言写成的，并以Windows动态连接库或UNIX共享库的形式分布在系统中。3.1.1.4 消息流开发语言：ESQL在MB中，消息流的开发使用的是ESQL语言。大家对SQL语言一定都不陌生，它是用来操作数据库的标准开发语言，而ESQL是对SQL V3的扩展，除了用于数据库的操作之外，它还可以操作消息数据，包括Generic XML和MRM格式的消息。如果大家熟悉SQL语言，那么使用ESQL开发MB中的消息流就会变得十分简单。在

36、ESQL中提供的函数种类主要有：用于字符串操作的函数，如：LENGTH，LTRIM, RTRIM, LOWER, POSITION, SUBSTRING, UPPER等；用于数字操作的函数，如：ABS, FLOOR, MOD, SQRT, ROUND, TRUNCATE等；用于时间和日期操作的函数，如：CURRENT_DATE，CURRENT_TIME，CURRENT_TIMESTAMP等；用于字段操作的函数，如：CARDINALITY, FIELDNAME, FIELDTYPE等；其他一些重要的函数，如：CAST函数用于不同数据格式之间的转换，CASE，PASSTHRU等。下面是一段ESQL

37、示例：SET OutputRoot = InputRoot;SET OutputRoot.XML.Message.Admin.Manager = (SELECT E.FIRSTNME, E.LASTNME FROM Database.EMPLOYEE AS E WHRER E.JOB=MANAGER AND E.WORKDEPT=InputBody.Message.Admin.Dept);3.1.1.5 消息流项目在开发消息流时，我们需要在Workbench中创建消息流项目，消息流相关的所有资源都将包含在消息流项目中，消息流项目经过编译之后，会生成可部署的消息流。消息流项目包含如下资源：.ms

38、gflow文件，是消息流的图形表示，包含消息Node(节点)和Connection（连接），一个消息流项目中可以包含多个.msgflow文件；.esql文件，是消息流的ESQL模块，包含了Compute, Filter和Database节点中对消息的处理逻辑；.mfmap文件，是消息格式之间，消息和数据库之间转换操作的描述。3.2 消息格式的定制和开发为了实现消息格式转换，我们要进行消息格式的定制和开发。如图所示，3.2.1 与消息格式定制和开发相关的基本概念图中表示了与消息格式和定义相关的所有部件，在作消息格式的定制和开发时，首先需要了解的主要概念有：3.2.1.1 MB支持的消息格式种类总

39、体而言，MB支持两大类消息格式，一类是自定义(Self-defining)格式，又称为Generic XML Message，顾名思义，这种消息自身中包含了对其内容和结构的定义，它遵循XML标准，当Broker接收到这种类型的消息，Broker将会使用XML解析器对其进行解析，生成其消息结构。另一类是预定义(Predefined)格式，这种格式的消息使用消息模版(Message Template)来定义并被存储在消息存储库中，消息存储库由消息库管理器(Message Repository Manager，以下简称MRM)来管理，MRM是Configuration Manager的一个重要组成部

40、件，是MB中定制消息的主要工具。预定义格式消息有两方面重要的属性，首先，它有一个逻辑结构和物理结构，逻辑结构描述了消息的结构，如某个消息有CustomerName, CustomerID, CustomerInfo等字段组成；物理结构，又称为Wire Format，它是消息的物理表示，结合上例物理表示是指上述三个字段的表现形式，是用字符串位流的形式表示，用XML表示还是用分隔符分隔的。MRM支持如下几种格式：自定制线格式(Custom Wire Format，简称CWF)，是指用户通过MRM工具定制的符合自己需求的消息类型以及C和COBOL中的结构；XML格式；基于分隔符的格式(Tagged

41、Delimited Strings，简称TDS)，例如，我们可以使用逗号等各种符号来分隔各个字段。3.2.1.2 消息模板由于流经代理程序的不同消息格式的多样性，必须能够通过某种途径区分不同类型的消息。每种消息类型的定义，或具有相关性的一组消息类型的定义，被描述为一个消息集(Message Set)，每个消息集拥有一个不同的字典。当接收到一个消息时，消息头中的信息可以帮助确定将被载入的正确字典，以对消息进行解析。为将其用于代理程序，一个消息集中所有相关的消息都会被指定给一个或多个代理程序，这些代理程序从指定的消息流中接收消息并对其进行处理。MRM中的消息模板由以下四个数值来定义： u 消息域(

42、Message Domain)，它描述了消息定义的来源，消息域有如下几种：MRM，预定制格式；XML，自定义格式；BLOB，无需解析的格式；NEON，由NEON工具定义的格式。u 消息集或项目(Message Set)，它将某一特定域内的消息、单元和类型集合聚集在一起，创建一个与某一特定消息流或商业操作相关的完整的消息定义。u 消息类型(Message Type)，它精确地定义了消息内部的数据结构，可以提供象字符串的数量和位置这样的细节。u 消息格式(Message Format)，它确定了消息的线格式。3.2.1.3 消息字典3.2.1.3.1 消息字典的好处如前所述，MB的一个关键功能是能

43、够对消息的内容进行解析，然后对消息数据进行处理，为了能够高效地对数据进行解析，必须能够对消息的格式进行检查，以确定每一消息相关字段里的内容，并执行基于节点的各项功能。消息字典就是为了提供格式信息，从而能够快速地解析消息中的信息，字典中存储的是逻辑消息模型，用于直接访问消息体中的指定字段。3.2.1.3.2 消息字典的组件和功能消息字典提供的消息服务组件（Message Services Component）能够根据消息字典中的定义对不同格式的消息内容及其相关的消息头进行解析。这些格式可以包括MQMD消息描述符、MQ RFH和RFH2格式头、XML消息、MRM格式，以及根据NEONFormatt

44、er定义创建的消息，这些存储在字典内的格式总体上被称为消息类型定义（Message Type Definitions）。在消息字典内部，这些定义可以被集中在一起形成一个消息集（Message Sets），消息集被应用于对消息进行处理的Broker代理程序。消息字典的三个主要组件分别是消息资料库过滤器（Message Repository Manager, MRM）、资源管理器（Resource Manager）和消息转换接口（Message Translation Interface, MTI），但是用户是通过GUI对消息字典进行访问的，上述这些组件对用户来说是透明的。消息格式的定义，以及模型

45、消息模板内部的字段和单元的标识，都被称为消息模型（Message Model）。MRM使用MB的开发工具Workbench来定义和维护消息模型，并将消息模型的信息存储在MRM数据库当中。MRM中的消息模型可以处理很多格式的消息，如XML消息格式，以及C或COBOL源程序中的记录结构。在运行时，这些被提供给Broker代理程序的信息被存储在运行时字典（RunTime Dictionary, RTD）中，每个本地部署的Broker代理程序都可以获得这些信息，当通过CM向Broker作部署操作时，就会生成运行时字典，并将消息运行时字典发送到Broker。这样，信息代理程序就能够在本地高速缓存中维护格

46、式定义，因而提高了对消息格式进行解析的速度。3.2.1.3.3 消息字典的使用我们将使用Workbench来定义代理程序所期望收到的消息的格式，这些被定义的格式随后会与处理节点和解析器协作，根据通过MQ接收到的线格式消息为消息代理程序提供其使用的逻辑消息格式。对于消息代理程序来说，消息字典的用途不仅仅是将线格式转换为逻辑消息格式，消息字典还被用于相反的用途，将MQOutput节点和发布节点接收到的逻辑消息格式转换为线消息格式。通过以下的例子可以清楚地解释这一点。在本例中，消息的内容是一个COBOL程序生成的COBOL记录结构。可以使用GUI将COBOL记录的逻辑消息结构定义到消息字典之中。当代

47、理程序接收到这一消息时，就可以使用消息字典中的定义将消息分解为相关的字段。不过，当代理程序内部的处理过程完成后，而且需要将这一消息以消息的形式发送给另一个COBOL应用时，必须以线格式创建输出消息，而逻辑格式消息的内容将再次成为COBOL记录结构。消息字典将再次被用于消息字段的映射，不过这次它映射的对象是COBOL记录中的消息字段，从而创建消息字典中定义的线格式。本质上，逻辑格式的一个优势在于，如果消息没有被发送给一个COBOL应用，而是被显示在一个Web页上，而且需要以HTML的形式发送出去，那么消息字典中的定义将可以在需要时根据消息模板中的定义创建其他的线格式输出。3.2.1.4 消息结构

48、3.2.1.4.1 消息的组成元素在MB中，每个消息由若干元素(Element)组成，每个元素都有一个类型(Type)，类型又分为简单类型(Simple Type)和复合类型(Compound Type)，简单类型是指单一元素对应的类型，如：Binary, Boolean, Datetime, Decimal, Float, Integer, String等，对于String类型的元素，必须定义其长度；多个单一类型可组成一个复合类型，每个消息必须与一个复合类型向对应。3.2.1.4.2 消息树结构在MB中，当消息的逻辑结构将会被解析，这时一个树状结构，其中有四个逻辑树，分别为消息树（Messa

49、ge Tree）、环境树(Environment Tree)、本地环境树(Local Environment Tree) 和例外列表树(Exception List Tree)。它们分别有不同的用途： 消息树：消息树包含真正的消息头和用户数据，它的结构如下：消息树的根为Root，当消息被输入节点接收并解析时，将生成消息树。其中，Properties结构将被增加为消息树的第一个元素，它包含了有关消息格式的信息，在对消息进行处理时将起到很重要的作用，其后是MQMD消息描述符，MQMD之后是各种消息头，最后是消息体。 环境树：当输入消息被消息流接收并解析时，会自动生成一个空的环境树，它将被从一个节点

50、传到消息流中的后续节点，其内容需要你来设置，你可以用它来记录一些消息流处理逻辑中需要的一些标志位或其他信息。建议使用Variables字段集来创建环境树中的变量信息，例如：SET Environment.Variables.MyVariable=1。 本地环境树：与环境树类似，当输入消息被消息流接收并解析时，也会自动生成一个空的本地环境树，在早期版本中，被称为DestinationList，你也可以根据需要来设置其内容，包括消息将要发往的目的地列表等。 例外列表树：在消息被处理的过程中如果出现例外，则系统会自动将例外信息添加到例外列表树中，从而供我们分析。在消息流中例外发生之后的所有节点都可以

51、接收到此例外信息。在消息流中，所有类型的消息处理节点对它们都有读权限；Filter节点和与数据库相关的节点可以修改环境树和本地环境树；Compute节点可以修改环境树、本地环境树和例外列表树，并生成新的消息树。每种类型的消息（除了自定义格式类型，如XML）都要求以上的这些定义，任何消息流都期望获得这些定义。一旦完成了每种消息的定义，消息字典中也定义了有关的消息集，而且已经将适当的字典指定给了消息流，那么当收到一个消息时，就可以通过消息头中的信息确定信息的类型，访问适当的消息字典，最终调用消息解析器（Message Parser）对消息进行分解。使用MRM对消息进行定义时必须非常小心，如果消息仅

52、仅是通过消息代理程序而不进行任何改变，那么只需要定义一个消息，因为输出消息与输入消息没有什么不同。如果需要进行任何形式的改变，如将某些元素加入到消息或从消息中将元素删除，那么就必须在MRM中定义输入消息和输出消息的格式。输入和输出消息的格式定义完毕以后，就可以对消息进行转换，这一改变可能是在一个计算节点内完成的，那么计算节点将会把输入格式作为内部消息，并将会根据执行转换操作的节点的定制属性将这一消息被转换为输出消息格式。需要指出的是，MRM并不对输入和输出消息的格式进行区分。3.2.1.5 消息解析器（Message Parser）一旦消息模板定义完毕，就可以使用解析器来分析应对接收到的消息如

53、何进行处理，解析器可以解析出消息的逻辑结构，将物理的位流(Bit-Streams)消息解析为消息树状结构中的各个字段。MB中提供了多种消息解析器，其中包括：MRM解析器，用于解析利用MRM工具定制的消息，如：TDS格式，基于C/COBOL的格式，由DTD或Schema定义的MRM格式等；XML解析器，用于解析自定义XML格式。用户也可以根据需要开发自己的解析器。在作消息解析时，消息流的输入节点，如MQInput节点将首先调用MQMD解析器，消息都是以MQMD结构开始的；在MQMD之后可能会有其他一些消息头，如：MQDLH等，因此在调用MQMD解析器之后，将调用与这些消息头相关的解析器；在所有的

54、头消息被解析之后，接下来解析消息体，输入节点会按照如下规则解析消息体：1）如果消息中含有MQRFH和MQRFH2头，则根据MQRFH和MQRFH2头中由消息域属性指定的解析器来对消息进行解析；2）如果消息中不含有MQRFH和MQRFH2头，则根据MQInput节点的属性中指定的解析器进行解析；3）如果消息虽然含有合法的MQMD，但是无法确定其消息域，则使用BLOB解析器。3.2.1.6 创建MRM消息的步骤创建MRM消息的步骤如下：1）首先，创建消息的逻辑结构，这需要以下步骤： 创建组成消息的各个元素(Element)，这些元素为简单类型的； 创建消息中嵌套的复合结构； 向已创建的复合结构中添

55、加元素； 创建针对消息的复合结构； 创建消息。2）然后，为逻辑模型指定消息的逻辑表示类型，步骤为： 添加消息的物理线格式(Wire Format)，如前所述，MRM支持如下几种物理表示类型，即CWF, XML和TDS； 设置线格式的属性。3.2.1.7 消息集项目在开发消息集时，我们需要在Workbench中创建消息集项目，消息集项目包含了消息集的定义，经过编译之后将生成可部署的运行时消息字典。消息集项目包含如下资源：messageSet.mset文件，包含了消息集级别的属性，例如消息流中自定义格式CWF消息的属性等；.xsd和.mxsd文件，消息格式的定义，.xsd是消息逻辑模型，通常用XM

56、L Schema表示，.mxsd文件是消息物理模型；.category文件，相关消息集的集和；import文件，包括XML Schemas, XML DTD, C的头文件和COBOL的copybook。第三部分：Message Broker技术纵深4 MB应用程序设计4.1 一般指导原则首先我们谈一谈MB应用程序设计的一些指导原则(Guidelines)。实际上，MB的应用程序就是一个MQ的应用，它也是利用MQ的API编写的一支应用程序，因此，MB应用程序首先要遵循MQ应用开发的指导原则，除此之外，要考虑如下一些主要因素：4.1.1 消息亲合性：当应用程序从业务需求的角度需要从逻辑意义上将多个

57、消息作为一个完整业务来处理，或者需要保证消息被处理的顺序时，就需要保证消息亲合性。消息亲合性的要求妨碍了我们对消息的并行处理，群集功能使得MQ和MB具有很好的可扩展性，但是，消息亲合性需要多个消息被同一个线程处理，所以影响了可扩展性，并造成系统瓶颈。因此，在MB应用程序中要避免对消息亲合性的要求。例如：在某个系统中，我们需要将若干条条目组成一个定单，最简单的方法是将每一个条目作为一条MQ的消息，但是，这种做法有很大的弊端：由于多个消息才能产生一个完整的业务数据从而导致了消息亲合性，这就需要在MB的消息处理中加入组合消息的处理逻辑。在这种情况下，更好的设计方法可以将所有条目作为一条消息交由MB来

58、处理。另外一个消息亲合性的例子是当对消息处理的顺序有要求的情况。例如：在一个系统中我们要处理新客户的信息，并且将其增加到客户数据库中。这时可能需要处理程序在一个单线程中运行，以保证为每个新客户产生正确的客户编号，并且避免在数据库中产生重复的记录。4.1.2 消息的永久性设置永久性消息保证了消息在系统和网络等故障下的安全可靠，但是同时从性能角度来讲会比非永久性消息要差，因此，要从不同的角度进行权衡和分析，然后决定消息的永久性属性。当对性能要求很高，可靠性要求相对不高时，可以采用非永久性消息。例如，某个请求端应用通过MB向另一个系统发出一个查询请求，交易量为每秒3000次，在该情形中，某个消息的丢

59、失对请求端应用的影响不是很严重，它可以重发请求，因此，我们可以使用非永久性消息。4.1.3 消息的RFH头的使用RFH分为版本1：RFH1和版本2：RFH2两个版本，RFH2与RFH1的结构基本相同，但是增加了对Pub/Sub的扩展支持，所谓扩展支持，是指基于内容(Content based)的Pub/Sub的功能，对这两种版本MB都支持。通常情况下，我们不需要使用RFH头，因为对每一种消息的处理我们会定义不同的消息流，而不同的消息流对应的输入队列也会不同。这样做的主要益处在于： 简化了发送和接收端的应用程序的编写，如果在MB中要使用RFH头，我们就必须在向MB发送消息时，为其添加RFH头，增

60、加了应用的复杂程度； 不同类型的消息被不同的消息流处理便确保了每种不同的消息在MB中被不同的线程处理； 确保了消息类型和应用程序相对Broker的独立性，我们不需要在应用程序层来定义消息的类型。当然，当我们使用Pub/Sub相关的功能时，我们可以在Pub/Sub应用中使用RFH头，或者在消息流中利用一个计算节点(Compute Node)来处理RFH头。4.1.4 逻辑工作单元(Logical Units of Work)的使用在MB中有多种方法来定义逻辑工作单元，整个消息流是不是会被作为一个全局逻辑工作单元来处理取决于消息的永久性属性设置、MQInput 节点属性的设置等多方面，如下表所示：

61、消息永久性MQInput 节点交易属性设置MQOutput 节点交易属性设置结果?永久性消息非永久性消息Yes(缺省)NoAuto-maticYesNoAuto- matic(缺省)Under Syncpoint?Y-Y-AY-NY-AYY-N-AN-N-N-ANY-A-AY-N-A-AN任何MQOutput节点设置将覆盖MQInput节点设置Y-Y任何MQOutput节点设置将覆盖MQInput节点设置-N-N但是要注意的是：逻辑工作单元不能跨越多个输入消息。当一个消息流涉及到与数据库的操作时，我们可以设置该数据库操作是否参与全局逻辑工作单元，当它参与全局逻辑工作单元时，数据库操作和消息处理

62、将遵循两阶段提交协议，这时，MQ担当XA协调器。4.2 消息流设计MB可以使复杂的消息格式转换工作变得非常容易，在MB中创建消息流也非常容易，因此不少用户在MB中利用消息流对消息进行非常复杂的业务逻辑处理，通常这是要避免的。我们的建议是不要把Msg Flow设计得过于复杂，MB是设计用来转换和路由消息的，同时对消息进行必要的处理，它不是一个MQ的应用服务器，不是对周边的应用程序的替代。例如，在下列场合可能效果就不是很好： 在一个消息流中要涉及对多个数据库的更新操作，并且所有这些操作都要在同一个逻辑工作单元完成； 消息流中涉及对数据库的复杂操作，尤其是通过ODBC连接对远程数据库进行该操作，在这

63、种情况下，数据库可能会成为消息流的瓶颈； 需要对多个输入消息进行组合的消息流； 处理逻辑非常复杂的消息流，例如包含许多计算节点的消息流，设计原则是最好保证单个消息流中总节点的个数不超过30个，其中需要对消息进行复杂处理或参与逻辑工作单元的节点不超过10个。从最大限度上来说，单个消息流中的节点总数也是有限制的，一般来说不能超过500个。如果不能避免，推荐使用多个消息流来处理； 对消息处理顺序有要求的消息流，在消息流中加入对顺序的控制需要复杂的逻辑，这样会影响消息流的性能； 处理非常大消息的消息流，一般情况下，建议消息大小不超过10MB。应用集线器的采用主要是它在系统架构上的优势，避免了应用程序点

64、对点的直接连接，从而减少接口开发的个数，提高系统的可扩展性，降低系统间的耦合度。MB适用于对消息进行格式转换和较为简单的运算处理，但是性能要求很高的场合。我们可以将复杂的业务逻辑运算放到应用程序端处理。4.3 ESQL高级使用对消息流的开发，最关键的是对ESQL的编写技巧，表现在对ESQL的熟悉和熟练程度，ESQL为我们提供了十分丰富的功能，实际项目中，我们要对其灵活使用，以便充分发挥其作用和效能。这里以THE、ITEM和EVAL的使用来举个简单的例子：当我们使用SELECT语句作SQL查询时，可能会返回一个结果集，THE的作用是使SELECT语句只返回一条结果。如：SET OutputRoot