WebSphere Business Integration Message Broker循序渐进PartII.docx

WebSphere Business Integration Message Broker循序渐进PartII.docx

《WebSphere Business Integration Message Broker循序渐进PartII.docx》由会员分享，可在线阅读，更多相关《WebSphere Business Integration Message Broker循序渐进PartII.docx（15页珍藏版）》请在冰豆网上搜索。

WebSphereBusinessIntegrationMessageBroker循序渐进PartII

WebSphereBusinessIntegrationMessageBroker循序渐进

第二部分：

MessageBroker的应用系统开发

1MessageBroker的应用系统开发

对MessageBroker的应用开发主要包含两部分，一部分是对消息流的开发，另外一部分是对消息格式的定制和开发。

1.1消息流的开发

为了实现对消息的各种计算处理，我们要进行消息流的定制和开发。

1.1.1与消息流开发相关的基本概念

在作消息流的开发时，首先需要了解的主要概念有：

1.1.1.1消息流的基本概念

MessageFlow（消息流）：

在MB中对消息的运算处理、格式转换和路由等功能是通过消息流实现的，每个消息从输入MB到从MB中输出，都将被一个消息流处理，然后发往目的应用系统。

消息流由各种消息处理节点（MessageProcessingNode）组成，消息处理节点可对消息进行各种处理操作，节点与节点相连，便组成了一个消息流。

1.1.1.2消息处理节点的基本概念

MessageProcessingNode（消息处理节点）：

在MB中，对消息的所有计算和处理是通过消息节点实现的，消息节点实际上是被Broker运行环境调用的动态连接库（DLL），通过ESQL语句对消息进行操作，通过对消息节点属性的客户化处理，将使节点能够对流经自己的消息执行特定的功能。

例如：

在一个执行过滤操作的节点，过滤语句是通过节点的客户化处理实现的，这一客户化处理过程特别指定适当的消息作为过滤的对象，并说明过滤操作的内容。

在一个MQInput节点中，相关MQ队列的名称是作为客户化消息的一部分被提供的，一同被提供的信息还包括消息流的事务处理属性等。

这些消息处理节点不仅对消息流内的消息数据进行操作，也能够访问消息流之外的信息，如访问一个数据库等。

每个节点拥有自己的不同类型的端（Terminal），这些端通过连接器（Connector）在逻辑上被连接在一起，通过对选定的节点进行设计和配置，从而建立一个完善的处理环境。

消息节点拥有一组用于从连接器处接收消息或将消息发送给连接器的端，常见的端类型包括接收消息的输入端、发送消息的输出端以及当消息处理过程中发生错误或出现意外情况时进行消息发送的故障端，通过故障端可以规定当消息流中的某一特定节点出现故障时系统将采取什么动作。

连接器的作用是可以将任意数量的节点捆绑在一起，在一个Broker实例的内部构成一个消息流。

消息流由一个输入节点发起，该节点启动一个流经消息流的消息，例如，通过MQInput节点开始一个消息流，它从一个MQ队列中读取一个消息，然后进行后续的处理，最后通过MQOutput节点将处理完成的消息发送到另一个输出队列中。

1.1.1.3消息处理节点的类型和功能

MB提供了多种类型的消息处理节点，用于对消息进行不同的处理。

如果MB缺省提供的消息处理节点仍无法满足您的特殊需求，MB支持你创建客户化的节点并将其插入到MB系统之中。

接下来，我们将简略描述节点的主要常用类型及每种节点的功能。

触发和初始化

常用的可以提供这一功能的节点是MQInput节点，对队列的每个消息流必须以MQInput节点开始。

MQInput节点有一个输入（input）端，输出（output）、失败（failure）和捕获（catch）三个输出端；它使用一个MQGET请求将消息从MQ队列中取出，然后使用输出端将消息流引导至下一个节点；如果出现了错误，则将其引导至故障端；第三种端被称为捕获端，当消息流中随后出现例外情况并且不能得到适当处理以至于接近失效时，这一端将被启动。

如果多个MQInput节点都在对一个MQ队列进行读取操作，有可能会出现与消息先后顺序有关的问题。

另外，MqeInput、SCADAInput等也是针对特殊协议的特殊的输入节点。

检查和过滤

能够提供这些功能的基本节点类型是检查（Check）节点和过滤（Filter）节点。

检查节点检查消息中的消息类型规格是否与某些或全部域（domain）、集（set）和类型（type）所期待的属性相匹配。

通过这一方式，可以对消息的RFH2头信息和其他标准特性进行评估。

消息流经输入端，如果检查是成功的，消息将流经匹配端；否则，它们将被引导至故障端。

过滤节点使用一个SQL表达式作为决策标准，根据内容对输入的消息进行评估。

这种节点可能使用的端包括输入（in）端、实（true）端、伪（false）端、未知（unknown）以及故障端。

输入（in）端、实（true）端、伪（false）端的含义从字面上就可以理解。

如果评估的结果是不确定或未知，则消息会流向未知端。

如果在评估过程中出现错误（如发生算术溢出），则消息会被引导至故障端。

消息处理

能够进行消息处理的基本节点类型是计算（Compute）节点、映射（Mapping）节点、析取（Extract）节点、ResetContentDescriptor等节点。

计算节点是可以对消息进行修改的节点，它的用途是对消息进行逻辑运算，在作逻辑运算时，可以使用ESQL语言对消息进行处理。

映射节点的用途也可以对消息进行修改，它的用途是对消息进行格式转换或创建新的消息，它能够以一种消息类型作为输入，经过转换后以另一个不同的消息类型将其输出，在创建新消息时可能需要用到输入消息的内容或者可能的来自外部关系数据库的数值。

要注意的是，在映射节点中能修改的是消息体的内容以及Environment和ExceptionList的内容，但是不能修改消息头的内容，只有Compute节点可以修改消息头的内容。

析取节点对输入消息进行选择、拷贝和修改，创建一个新的输出消息。

ResetContentDescriptor节点的用途是使用同一消息流内部的另一个解析器类型对消息进行解释。

这一节点的功能类似于将消息从一个MQOutput节点传送到一个MQInput节点。

外部数据库操作

可以执行外部数据库操作的基本节点类型是数据插入（DataInsert）节点、数据更新（DataUpdate）节点、数据删除（DataDelete）节点、数据库（Database）节点以及数据仓库（Warehouse）节点。

这些节点都专门用来访问数据库并对数据库进行操作的，所有这些节点都拥有以下类型的端：

输入端、输出端和故障端。

所有使用这些节点进行的操作可以作为由MQ协调的全局逻辑单元的一部分，它们也可以作为单独的事务来处理。

要注意的是，所有这些节点都不能改变流经自己的消息。

数据插入节点可以将一个新行插入到一个特定的数据库中。

消息中所包含的某些信息可以作为插入内容的一部分，或者消息可以只起到一个触发器的作用，数据插入节点的顺序很可能是跟在一个过滤节点的后面，插入动作的完成是通过一个内部生成的SQL语句实现的。

数据更新节点可以更新某一特定数据库中一行或多行的数值，更新操作也是通过一个内部生成的SQL表达式完成的。

数据删除节点可以从某一指定数据库的数据表中删除一个或多个行，消息在处理过程中不会被改变。

输入消息中的数据可以被用在ESQL表达式中，以说明将从数据库中删除什么样的数据。

数据库节点可以对某一指定的数据库执行某一数据库操作，它不会对消息进行改变，消息从节点的输入端流到输出端。

消息中的数据值可以被包括在执行数据库操作的SQL表达式之中。

由于数据插入（DataInsert）、数据更新（DataUpdate）和数据删除（DataDelete）节点的功能由数据库（Database）节点都可以实现，因此，数据库节点的使用频率较高。

数据仓库节点与数据插入节点类似，用于存储在一个消息数据仓库中流经代理程序的消息。

消息被存储在数据仓库中的目的可以是为了审查，或对消息进行离线处理或批处理，另一个使用数据仓库的理由是对流经消息代理程序的数据进行全面的数据挖掘（DataMining）或数据分析（DataAnalysis）。

消息添加到数据仓库中的数据库是通过一个SQL插入语句完成的，

消息内容的格式可以有很大的不同，我们必须根据消息数据仓库中消息数据的最终用途对所要求的格式进行评估。

可以将消息数据仓库仅仅作为消息的临时存储地点使用，而且数据库不需要知道消息的内容，在这种情况下，消息可以以BLOB的形式存储在数据库中。

另一方面，也可以要求数据库对消息字段中的某些单元进行复杂的处理。

在这种情况下，数据库需要知道消息字段和消息头中所包含的信息，以对存储的数据进行处理。

决策和路径选择

具有这一功能的基本节点类型是MQOutput节点、MQReply节点以及Publication节点。

MQOutput节点是Broker内部消息流的终点。

在这个节点，消息将会通过一个MQPUTMQI调用被写入到一个MQ队列之中，根据消息中所包含的信息，消息可以被写入到一个指定的固定队列，或被发送到一个应答队列，还可以指定一个目的队列的列表。

MQReply节点是MQOutput节点的特殊版本，在消息需要被输出到在消息头中Reply字段规定的MQ队列中时，可以使用MQReply节点。

发布（Publication）节点也可以作为消息流的终点，用于将消息发送给已定义了发布和订阅（PublishandSubscribe）服务的订阅者。

流经发布节点的消息是发布/订阅消息流的一部分，发布节点将根据主题和内容判断消息是否与订阅者的要求相匹配，并将匹配的消息直接发送给本地的订阅者，或将消息引导至其他的代理程序，这些代理程序再进行同样的匹配处理。

错误处理和跟踪

拥有这一功能的基本节点类型有三种，分别是Throw节点、Trace节点和TryCatch节点。

Throw节点只有一个输入端，在消息流的内部用于处理例外情况。

这些例外情况可能是早些时候TryCatch节点在消息流中捕获的，或者可能会引起该特定消息的处理中断和相关事务处理活动的重新运行。

Throw节点可用于将例外情况（根据消息的内容进行判断）丢弃，防止消息流的下游出现更多的失效。

TryCatch节点的用途是防止下游节点出现的对消息或事务处理过程的例外终止处理，当例外返回到作为消息流根节点的MQInput节点时，这种情况是有可能发生的。

消息通过输入端被接收，通过Try端被不加改变的转发出去。

如果例外被TryCatch节点捕获，那么它将通过catch端（如果已被连接）被传播出去，随后就可以对例外进行错误处理。

如果消息流中发生的例外没有被其他节点（如TryCatch节点）捕获，那么它将会被MQInput节点捕获，因为该节点是这一线程的发起者，该节点的catch端将会把这一消息传播出去。

Trace节点用于帮助消息流的调试。

它拥有一个输入端和一个输出端，输出端将输入消息不加修改地发送出去，Trace节点会将一个跟踪记录写入某一指定的地点，通过跟踪记录我们可以分析一个消息在消息流内走过的路径。

我们可以使用多种选项确定跟踪格式，例如可以选择某个操作系统文件，MB的错误日志等作为输出对象。

其他类型的消息处理节点

除了上述我们常用的节点类型之外，MB还缺省提供其他一些类型的消息处理节点，如：

MQeInput节点和MQeOutput节点，用于用MQEveryplace产品输入/输出的节点；SCADAInput节点和SCADAOutput节点，用于使用一种专门的协议SCADA协议输入/输出的节点；HTTPInput节点、HTTPReply节点和HTTPRequest节点，用于WebService支持的节点；AggregateControl节点、AggregateReply节点和AggregateRequest节点，用于输入/输出消息的聚合处理等。

第三方或插入消息处理节点

以上描述的节点都是随MB缺省提供的，用户可以根据自己的特殊需求，开发客户化的消息处理节点，来加强消息代理程序内部消息流的处理。

这些节点的设计必须与MB的消息流框架（MessageflowFramework）的要求相匹配，这样才能够将新的节点加入到MBWorkbench之中，这种节点可能是以C语言写成的，并以Windows动态连接库或UNIX共享库的形式分布在系统中。

1.1.1.4消息流开发语言：

ESQL

在MB中，消息流的开发使用的是ESQL语言。

大家对SQL语言一定都不陌生，它是用来操作数据库的标准开发语言，而ESQL是对SQLV3的扩展，除了用于数据库的操作之外，它还可以操作消息数据，包括GenericXML和MRM格式的消息。

如果大家熟悉SQL语言，那么使用ESQL开发MB中的消息流就会变得十分简单。

在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示例：

SETOutputRoot=InputRoot;

SETOutputRoot.XML.Message.Admin.Manager[]=（SELECTE.FIRSTNME,E.LASTNMEFROMDatabase.EMPLOYEEASEWHRERE.JOB=’MANAGER’ANDE.WORKDEPT=InputBody.Message.Admin.Dept）;

1.1.1.5消息流项目

在开发消息流时，我们需要在Workbench中创建消息流项目，消息流相关的所有资源都将包含在消息流项目中，消息流项目经过编译之后，会生成可部署的消息流。

消息流项目包含如下资源：

.msgflow文件，是消息流的图形表示，包含消息Node（节点）和Connection（连接），一个消息流项目中可以包含多个.msgflow文件；.esql文件，是消息流的ESQL模块，包含了Compute,Filter和Database节点中对消息的处理逻辑；.mfmap文件，是消息格式之间，消息和数据库之间转换操作的描述。

1.2消息格式的定制和开发

为了实现消息格式转换，我们要进行消息格式的定制和开发。

如图所示，

1.2.1与消息格式定制和开发相关的基本概念

图中表示了与消息格式和定义相关的所有部件，

在作消息格式的定制和开发时，首先需要了解的主要概念有：

1.2.1.1MessageBroker支持的消息格式种类

总体而言，MB支持两大类消息格式，一类是自定义（Self-defining）格式，又称为GenericXMLMessage，顾名思义，这种消息自身中包含了对其内容和结构的定义，它遵循XML标准，当Broker接收到这种类型的消息，Broker将会使用XML解析器对其进行解析，生成其消息结构。

另一类是预定义（Predefined）格式，这种格式的消息使用消息模版（MessageTemplate）来定义并被存储在消息存储库中，消息存储库由消息库管理器（MessageRepositoryManager，以下简称MRM）来管理，MRM是ConfigurationManager的一个重要组成部件，是MB中定制消息的主要工具。

预定义格式消息有两方面重要的属性，首先，它有一个逻辑结构和物理结构，逻辑结构描述了消息的结构，如某个消息有CustomerName,CustomerID,CustomerInfo等字段组成；物理结构，又称为WireFormat，它是消息的物理表示，结合上例,物理表示是指上述三个字段的表现形式，是用字符串位流的形式表示，用XML表示还是用分隔符分隔的。

MRM支持如下几种格式：

自定制线格式（CustomWireFormat，简称CWF），是指用户通过MRM工具定制的符合自己需求的消息类型以及C和COBOL中的结构；XML格式；基于分隔符的格式（TaggedDelimitedStrings，简称TDS），例如，我们可以使用逗号等各种符号来分隔各个字段。

1.2.1.2消息模板

由于流经代理程序的不同消息格式的多样性，必须能够通过某种途径区分不同类型的消息。

每种消息类型的定义，或具有相关性的一组消息类型的定义，被描述为一个消息集（MessageSet），每个消息集拥有一个不同的字典。

当接收到一个消息时，消息头中的信息可以帮助确定将被载入的正确字典，以对消息进行解析。

为将其用于代理程序，一个消息集中所有相关的消息都会被指定给一个或多个代理程序，这些代理程序从指定的消息流中接收消息并对其进行处理。

MRM中的消息模板由以下四个数值来定义：

◆消息域（MessageDomain），它描述了消息定义的来源，消息域有如下几种：

MRM，预定制格式；XML，自定义格式；BLOB，无需解析的格式；NEON，由NEON工具定义的格式。

◆消息集或项目（MessageSet），它将某一特定域内的消息、单元和类型集合聚集在一起，创建一个与某一特定消息流或商业操作相关的完整的消息定义。

◆消息类型（MessageType），它精确地定义了消息内部的数据结构，可以提供象字符串的数量和位置这样的细节。

◆消息格式（MessageFormat），它确定了消息的线格式。

1.2.1.3消息字典

1.2.1.3.1消息字典的好处

如前所述，MB的一个关键功能是能够对消息的内容进行解析，然后对消息数据进行处理，为了能够高效地对数据进行解析，必须能够对消息的格式进行检查，以确定每一消息相关字段里的内容，并执行基于节点的各项功能。

消息字典就是为了提供格式信息，从而能够快速地解析消息中的信息，字典中存储的是逻辑消息模型，用于直接访问消息体中的指定字段。

1.2.1.3.2消息字典的组件和功能

消息字典提供的消息服务组件（MessageServicesComponent）能够根据消息字典中的定义对不同格式的消息内容及其相关的消息头进行解析。

这些格式可以包括MQMD消息描述符、MQRFH和RFH2格式头、XML消息、MRM格式，以及根据NEONFormatter定义创建的消息，这些存储在字典内的格式总体上被称为消息类型定义（MessageTypeDefinitions）。

在消息字典内部，这些定义可以被集中在一起形成一个消息集（MessageSets），消息集被应用于对消息进行处理的Broker代理程序。

消息字典的三个主要组件分别是消息资料库过滤器（MessageRepositoryManager,MRM）、资源管理器（ResourceManager）和消息转换接口（MessageTranslationInterface,MTI），但是用户是通过GUI对消息字典进行访问的，上述这些组件对用户来说是透明的。

消息格式的定义，以及模型消息模板内部的字段和单元的标识，都被称为消息模型（MessageModel）。

MRM使用MB的开发工具Workbench来定义和维护消息模型，并将消息模型的信息存储在MRM数据库当中。

MRM中的消息模型可以处理很多格式的消息，如XML消息格式，以及C或COBOL源程序中的记录结构。

在运行时，这些被提供给Broker代理程序的信息被存储在运行时字典（RunTimeDictionary,RTD）中，每个本地部署的Broker代理程序都可以获得这些信息，当通过CM向Broker作部署操作时，就会生成运行时字典，并将消息运行时字典发送到Broker。

这样，信息代理程序就能够在本地高速缓存中维护格式定义，因而提高了对消息格式进行解析的速度。

1.2.1.3.3消息字典的使用

我们将使用Workbench来定义代理程序所期望收到的消息的格式，这些被定义的格式随后会与处理节点和解析器协作，根据通过MQ接收到的线格式消息为消息代理程序提供其使用的逻辑消息格式。

对于消息代理程序来说，消息字典的用途不仅仅是将线格式转换为逻辑消息格式，消息字典还被用于相反的用途，将MQOutput节点和发布节点接收到的逻辑消息格式转换为线消息格式。

通过以下的例子可以清楚地解释这一点。

在本例中，消息的内容是一个COBOL程序生成的COBOL记录结构。

可以使用GUI将COBOL记录的逻辑消息结构定义到消息字典之中。

当代理程序接收到这一消息时，就可以使用消息字典中的定义将消息分解为相关的字段。

不过，当代理程序内部的处理过程完成后，而且需要将这一消息以消息的形式发送给另一个COBOL应用时，必须以线格式创建输出消息，而逻辑格式消息的内容将再次成为COBOL记录结构。

消息字典将再次被用于消息字段的映射，不过这次它映射的对象是COBOL记录中的消息字段，从而创建消息字典中定义的线格式。

本质上，逻辑格式的一个优势在于，如果消息没有被发送给一个COBOL应用，而是被显示在一个Web页上，而且需要以HTML的形式发送出去，那么消息字典中的定义将可以在需要时根据消息模板中的定义创建其他的线格式输出。

1.2.1.4消息结构

1.2.1.4.1消息的组成元素

在MB中，每个消息由若干元素（Element）组成，每个元素都有一个类型（Type），类型又分为简单类型（SimpleType）和复合类型（CompoundType），简单类型是指单一元素对应的类型，如：

Binary,Boolean,Datetime,Decimal,Float,Integer,String等，对于String类型的元素，必须定义其长度；多个单一类型可组成一个复合类型，每个消息必须与一个复合类型向对应。

1.2.1.4.2消息树结构

在MB中，当消息的逻辑结构将会被解析，这时一个树状结构，其中有四个逻辑树，分别为消息树（MessageTree）、环境树（EnvironmentTree）、本地环境树（LocalEnvironmentTree）和例外列表树（ExceptionListTree）。

它们分别有不同的用途：

Ø消息树：

消息树包含真正的消息头和用户数据，它的结构如下：

消息树的根为Root，当消息被输入节点接收并解析时，将生成消息树。

其中，Properties结构将被增加为消息树的第一个元素，它包含了有关消息格式的信息，在对消息进行处理时将起到很重要的作用，其后是MQMD消息描述符，MQMD之后是各种消息头，最后是消息体。

Ø环境树：

当输入消息被消息流接收并解析时，会自动生成一个空的环境树，它将被从一个节点传到消息流中的后续节点，其内容需要你来设置，你可以用它来记录一些消息流处理逻辑中需要的一些标志位或其他信息。

建议使用Variables字段集来创建环境树中的变量信息，例如：

SETEnvironment.Variables.MyVariable=1。

Ø本地环境树：

与环境树类似，当输入消息被消息流接收并解析时，也会自动生成一个空的本地环境树，在早期版本中，被称为DestinationList，你也可以根据需要来设置其内容，包括消息将要发往的目的地列表等。

Ø例外列表树：

在消息被处理的过程中如果出现例外，则系统会自动将例外信息添加到例外列表树中，从而供我们分析。

在消息流中例外发生之后的所有节点都可以接收到此例外信息。

在消息流中，所有类型的消息处理节点对它们都有读