ibmMQ--第一部分第二章

第二章Websphere MQ体系结构
目标
4，	了解WebSphere MQ的对象。
5，	描述WebSphere MQ的体系结构。
6，	学习WebSphere MQ的客户机和服务器。
7，	理解WebSphere MQ的触发机制。
8，	学习使用WebSphere MQ的队列管理器群集。
2.1基本概念
2.1.1 WebSphere MQ对象(objects)
	WebSphere MQ对象是一种由WebSphere MQ管理的具有可恢复能力的资源。在本书中描述的许多任务都和下列对象相关：
	队列管理器（Queue managers）
	队列（Queues）
	名字列表（Namelists）
	分发列表（Distribution lists）
	进程定义（Process definitions）
	通道（Channels）
	存储类（Storage classes）

这些对象在异种平台上都是统一的。对于系统管理员来说，操纵对象的命令都是可用的。这些命令格式，对于不同平台是有区别的。当你创建队列管理器时，会自动地创建缺省对象。这些缺省对象可以帮助您来定义所需的对象。
	每一个对象都有一个名字，以便通过命令和MQI调用可以引用它。通常在这些对象类型中的每一种对象的名字必须唯一。例如，一个队列和一个进程的名字可以相同，但是不可以有两个相同名字的队列。这意味着一个本地队列名不能和模板队列、远程队列或别名队列相同。但是也会有些特殊情况。另外在互连的队列管理器网络中，队列管理器名必须唯一。
	WebSphere MQ的对象名是大小写敏感的，因此在定义对象时，需要仔细选择好大小写字母。在 WebSphere MQ 中，除最多有 20 个字符的通道之外，名称最多可以有 48 个字符。

2.1.2 消息
消息是对使用它的应用程序有意义的以字节为单位的字符串。消息可以用来实现在相同或不同平台上应用程序间的通信。 
WebSphere MQ 消息由两个部分： 
应用程序数据。 
应用程序数据的内容和结构由使用它的应用程序定义。 
消息描述符。 
消息描述符标识消息，并包含其它控制信息，如消息类型和消息的优先级，如图所示：

 
图，消息结构

消息描述符的格式由 WebSphere MQ 定义。有关消息描述符的完整描述，参看《WebSphere MQApplication Programming Reference》。
2.1.2.1消息的类型
	WebSphere MQ定义了四种基本类型的消息。应用程序可以定义其他类型的消息。四种基本类型是：
	请求消息 Request message
请求消息需要应答。从客户端发往服务器的查询和更新信息往往是一条请求消息。请求消息中应该包含回复消息的路由信息，即回复消息发往什么地方。
	回复消息 Reply message
回复消息是对请求消息的回应。请求消息中的信息决定了回应消息的目的地。处理请求和回应的应用程序控制着消息间的关联，这种关联和队列管理器没有关系。消息自身带有足够的信息供应用程序实现这种关联。
	报文消息 Datagram message
数据报消息是不需要回复的消息，报文消息只是一次单向的信息传送。
	报告消息 Report message。
报告消息用于对一些系统故障的响应。有些报告消息是由应用程序创建的，有些报告消息是由队列管理器创建的。后一种情况是由于远程队列已经满或者远程队列不存在引起消息不能正确发送。最初发送者条消息的应用程序不能检测到这种错误，只有等远程队列管理器创建了这样一条报告消息并发往本地队列管理器之后，应用程序才能作相应的处理。
队列管理器把报告消息也用于其他目的，比如报告一些事件。消息可能有一个失效时间限制。如果一条消息在失效时间过后还没有被某个应用程序处理，该条消息将被队列管理器从系统中清除。当队列管理器清除一条失效消息之后，它将创建一条报告消息，这条报告消息的目的地址由失效消息提供。
报告消息的另一个用途是确保消息的到达。应用程序可以要求它们所发送的消息到达目的地后，他们收到一条报告消息，这叫做接收确认（Confirmation of arrival）。与此相类似，应用程序也可以要求当另外一个程序取走这条消息时它们收到一条报告消息，这被叫做交付确认（Confirmation of delivery）。这两种情况，都是由队列管理器创建报告消息，并把报告消息发送到适当地目的地。
另外还一类特殊的消息叫触发消息。触发消息是由队列管理器创建的一类特殊消息。WebSphere MQ的队列管理器提供了一种当满足某一条件时，自动触发应用程序的机制，而触发消息是触发机制的重要组成部分。

应用程序也可以定义新的消息类型。队列管理器不能解释这些类型，应用程序设置的消息类型由一个范围。这些类型值可用来区分不同类型的应用程序在同一个输入队列中放入的消息。
	
2.1.2.2消息长度
最大消息长度为 100 MB（其中 1 MB 等于 1 048 576 字节），缺省最大消息长度是 4 MB。实际上，消息长度受以下方面的影响： 
•	接收队列定义的最大消息长度 
•	队列管理器定义的最大消息长度 
•	传输队列定义的最大消息长度 
•	发送或接收应用程序定义的最大消息长度 
•	存储消息的可用空间
所以有时可能需要由多个消息组成的信息才能满足应用程序的要求。
2.1.2.3应用程序如何发送和接收消息？
应用程序使用 MQI 调用来实现发送和接收消息。 
例如，要将消息放入队列，应用程序： 
1.	通过发出 MQI  MQOPEN 调用打开所需的队列 
2.	发出 MQI  MQPUT 调用以将消息放入队列 
另一个应用程序可以通过发出 MQI MQGET 调用，从同一队列取出消息
2.1.3 队列
队列是用于存储消息的数据结构,目前WebSphere MQ 版本 5.3 支持超过 2 GB 大小的队列。
2.1.3.1队列的类型
按创建方法分类
•	预定义队列由管理员使用相应的 MQSC 或 PCF 命令创建。 预定义队列是永久的；它们的存在与应用程序是否实用它们无关，并且 WebSphere MQ 重新启动后继续存在。 
•	动态队列在应用程序发出设定模型队列名的MQOPEN调用时创建的。被创建的队列是基于一个模板队列。 您可以使用 MQSC 命令 DEFINE QMODEL 创建模板队列。动态队列继承了模板队列的属性。模板队列有一个属性可以说明动态队列是永久的还是临时的。永久队列在应用程序和队列管理器重新启动后继续存在；临时队列在重新启动后消失。
按功能分类
1.	本地队列（local queue）：
一个本地队列是一个物理上位于本地队列管理器中的队列。本地队列实际上存在与本地系统的内存或磁盘存储终。本地队列管理器控制队列的访问。
	应用程序可以“PUT”消息到本地队列，也可以从本地队列“GET”消息，另外程序还可以查询或修改这些队列的某些属性。对队列属性的修改需要相应的权限。
2.	远程队列（remote queue）：
	一个远程队列属于一个不与该应用程序直接相连的队列管理器。对这类队列的访问包含有本地队列管理器和远程队列管理器的通信过程。这种通信涉及到通道。
	应用程序可对远程队列进行某些操作，比如程序可以向一个远程队列放一条消息，但程序不能从远程队列中去消息。应用程序只能从本地队列读取消息。
 	应用程序有两种不同的方法可用来访问远程队列。第一种是当程序打开一个远程队列时同时提供队列管理器名和队列名两个参数。这要求程序知道目的队列属于哪个队列管理器。第二种方法是在本地队列管理器上存在一个远程队列的定义，这个定义包含有足够的信息让本地队列管理器确定该远程队列所在的队列管理器。
	远程队列定义中的目的队列不一定是远程队列管理器的本地队列，它也可以是一个远程队列定义，如图所示。

 

	应用程序放一条消息到Q1，Q1是本地队列管理器QM1上的一个远程队列定义：Q2 at QM2。QM2是远程队列管理器。Q2是QM2上的一个远程队列定义Q3 at QM3。Q3是QM3的一个本地队列，经过两次传送，消息最终到达Q3这个QM3的本地队列。
	有多种原因使这种多跳（Multihop）传送变得有意义。在一个TCP/IP网络内部，所有机器都有IP地址，IP协议本身处理节点间的路由选择。但假设消息需要穿过不同类型的网络，这就需要中间件参加路由选择。在图中，QM2位于一台连接TCP/IP网和SNA网的机器上，只需在QM2上提供一个远程队列定义Q2：Q3 at QM3，就可以实现消息的跨网络传输。
	因为对远程队列的访问总是涉及到队列管理器之间的通信，因而我们需要定义其他一些资源，比如通道、传输队列（Transmission queue）。

3.	传输队列(Transmission queue)：
	传输队列是临时存储目标为远程队列管理器的消息的队列。队列管理器利用传输队列把消息分阶段地发向远程队列。队列管理器和消息移动程序一起负责把数据传送到远程队列。当队列管理器收到把一条消息发往远程队列的要求后，它把消息发送到一个与目的队列管理器相关联的传输队列，传输队列位于本地队列管理器上。目的队列管理器的名称可能由应用程序提供，也可以从远程队列定义中得到。

	一个传输队列是两个队列管理器之间的连接的一端。所有直接目的地是同一队列管理器的消息都可放在同一个传输队列上，这些消息的最终目的可能不一样。把消息从一个队列管理器传送到另一个队列管理器只需要一个传输队列，然而也有可能在两个队列管理器之间存在着多个连接以提供不同的传输服务，每个连接都带有一个不同的传输队列。

	传输队列是由MCA处理的，MCA负责在队列管理器之间可靠地传送消息。MCA实际上是处理传输队列上消息的MQI应用程序。

4.	动态队列和模板队列：
除了有固定定义的队列之外，WebSphere MQ还为程序在它们执行时提供了动态地创建队列的能力。例如,一个应用程序作为某种服务的客户，它可能创建一个动态队列，并通知服务器把对服务要求的响应发送到该动态队列。当然，这种情况也可以使用具有永久定义的队列。为了简化在创建动态队列时所必需设置的许多参数，动态队列总是基于模板队列被创建的，模板队列定义了动态队列的所有属性。当应用程序试图打开一个模板队列时，WebSphere MQ就创建一个动态队列。WebSphere MQ为应用提供了系统模板队列。
动态队列也可以分成两种，它们的生存周期和故障恢复特性不同。在创建临时动态队列（Temorary dynamic queue）的应用程序关闭时，这些队列将被删除，队列上的消息将丢失。这类动态队列不支持消息的持久性。如果队列管理器发生故障重新启动，临时动态队列也不会被恢复。另一种动态队列是持久动态队列（Permanent dynamic queue）。只有当一个应用程序关闭持久动态队列时定义删除选项，持久动态队列才会被删除。删除持久动态队列的程序不一定是创建持久动态队列的程序，持久动态队列在队列管理器重启后会被恢复，并且支持具有持久性的消息。

5.	启动队列 
启动队列是在触发中使用的队列。如果队列管理器将使用触发，则必须至少为此队列管理器定义一个启动队列。队列管理器在触发器事件发生时将触发器消息放入启动队列。触发器事件是由队列管理器检测的条件的逻辑组合。例如，当队列上的消息数达到预定义深度时，可能会生成触发器事件。此事件使队列管理器将触发器消息放入指定的启动队列。此触发器消息由触发器监视器（即监视启动队列的特殊应用程序）检索。然后触发器监视器启动在触发器消息中指定的应用程序。 
  
6.	群集传输队列 
每个在群集中的队列管理器有一个称为 SYSTEM.CLUSTER.TRANSMIT.QUEUE 的群集传输队列。当您定义队列管理器时，按缺省情况创建此队列的定义。 作为群集一部分的队列管理器可以将群集传输队列上的消息发送到在同一群集中的任何其它队列管理器。 在路由解析期间，群集传输队列优先于缺省传输队列。 当队列管理器是群集的一部分时，缺省操作是使用 SYSTEM.CLUSTER.TRANSMIT.QUEUE，除非当目标队列管理器不是此群集的一部分。 
7.	死信队列 （Dead letter queue）
死信（未传递的消息）队列是存储无法发送到其正确目的地的消息的队列。有时候会出现队列管理器不能把消息发送到目的地的情况，此时消息将被发送到某个死信队列中。死信队列中的消息常常暗示了系统可能出现的问题。例如当一条消息到达目的队列管理器之后却发现目的队列并不存在。或者目的队列出现不能接收信消息的情况，比如目的队列已经满了，或者它被设置成不允许再加入新的消息。并不是所有的放消息操作的失败都导致消息被放入死信队列，例如，由于本地队列出现错误造成应用程序不能“放”消息，此时MQI调用直接把错误码返回给应用程序。
	有些错误只能由死信队列报告，例如，一条消息穿越网络之后到达目的队列管理器，却发现目的队列已满。发现错误的机器不同于最初“放”消息应用程序所在的机器，甚至可能放消息的应用程序已不在运行状态。此时目的队列管理器把这条消息发往它所拥有的死信队列，而不是简单地扔掉该条消息。这样使得这次错误是可见的，也给应用程序提供了一个改正错误的机会。
		死信队列是WebSphere MQ面对远端系统错误时的一种解决方案。应用程序可以利用WebSphere MQ提供的其他一些工具来监视并确保消息的可靠传送和接收。
		在队列管理器创建时，系统会缺省创建一个死信队列，队列名是SYSTEM.DEAD.LETTER.QUEUE。 建议在生产系统上，需要独立创建一个死信队列，而不使用系统缺省的死信队列。
8.	命令队列 
命令队列 SYSTEM.ADMIN.COMMAND.QUEUE 是用来存放由应用管理程序放的具有PCF（program command format）的消息的队列。该队列主要用于编写管理程序时使用。具体的使用将在后续章节介绍。在创建队列管理器时将为每个队列管理器自动创建命令队列。 
9.	回复队列 
当应用程序发送请求消息时，接收消息的应用程序可以将回复消息发送给发送应用程序。此回复消息放入一个称为回复队列的队列中，它通常是发送应用程序的本地队列。回复队列的名称由作为消息描述符一部分的发送应用程序指定。 

10.	别名队列
	别名队列实际上是本地队列、远程队列定义或队列名表的另外一个名字。它是一种简单的名字到名字的映射，它允许应用程序用另外一个名字来访问队列。WebSphere MQ已经为应用程序屏蔽了许多底层系统细节，特别是网络通信的细节，而别名队列允许在不修改应用程序的条件下访问其他名字的队列。
2.1.3.2定义队列
在WebSphere MQ中可以使用以下方法定义队列： 
	在MQSC命令行中使用DEFINE
	在程序中使用PCF创建队列命令

在定义队列时需要指定队列的类型和属性。例如，可以设置队列可存放的消息最大长度，以及队列的最大深度等属性。有关定义队列对象的进一步详细信息，请参阅《WebSphere MQ 脚本（MQSC）命令参考》或《WebSphere MQ Programmable Command Formats and Administration Interface》。 
2.1.3.3从队列检索消息
适当授权的应用程序可以根据以下检索算法从队列检索消息： 
•	先进先出（FIFO）。 
•	在消息描述符中定义的消息优先级。以 FIFO 为基础检索具有相同优先级的消息。 
•	特定消息的程序请求。 
来自应用程序的 MQGET 请求确定所使用的方法。 

2.1.4队列管理器
在WebSphere MQ中队列管理器是基本的软件系统，队列管理器可看成是队列和其他对象的容器。WebSphere MQ中的每一个队列都属于一个队列管理器，队列管理器是为应用程序和WebSphere MQ部件（一些管理工具）提供对队列管理中对象的访问。
一个队列管理器是WebSphere MQ中的一个基本的独立的执行单元。一台机器上可以运行一个或多个队列管理器。
任何需要访问WebSphere MQ提供的服务的应用程序都必须先和队列管理器相连，和应用程序相连的队列管理器对该应用程序而言就叫“本地队列管理器”（Local Queue Manager）,本地队列管理器为程序提供MQI调用的支持。应用程序可以操作、管理本地队列管理器所拥有的各种资源，也可以向其他的队列管理器发送消息。
应用程序通过一种叫做MQI的编程接口向队列管理器申请服务。这些服务包括“放”一条消息到队列或从队列“取”一条消息等一些基本操作。队列管理器还使队列成为可靠的存储消息的地方，它也控制安全性管理，并提供一些特殊的队列功能，比如触发队列。
为了减少应用程序对于它所运行环境的依赖性，WebSphere MQ的应用程序可以和一个它不知道名字的队列管理器相连，这个队列管理器就是一台机器上的缺省队列管理器。如果程序在调用MQCONN时，把队列管理器名参数设置为空，MQCONN将返回与缺省的队列管理器连接的句柄。

队列管理器拥有每个队列。队列管理器负责维护它所拥有的队列，以及将它接收到的所有消息存储到相应的队列。可以由应用程序或队列管理器将消息放入队列，这些是它的正常操作的一部分。
2.1.4通道
2.1.4.1消息通道（Message channels）
消息通道是一种提供从一个队列管理器到另一个队列管理器的通信路径。消息通道用在分布式的队列把消息从一个队列管理器发送到另一个队列管理器。它们使应用程序屏蔽了底层的通信协议。队列管理器可能存在同种或异种平台之间。为了实现队列管理器之间的通信，您必需在一个队列管理器中定义一个发送消息的通道对象，在另一个队列管理器中定义一个接收消息的通道对象。消息通道是一个单向链接。它通过消息通道代理（message channel agents）把两个队列管理器连接起来。如图所示：

 

不要和MQI通道（MQI channel）通道混淆。MQI通道有两种类型，分别是服务器连接（server-connection）和客户器连接（client-connection）。
消息通道分类
消息通道的定义可以分为以下6种类型：
	发送通道（Sender） 
	接收通道（Receiver） 
	服务器通道（Server） 
	请求器通道（Requester） 
	群集发送通道（Cluster sender） 
	群集接收通道（Cluster receiver）

消息通道的组合形式
如果要在队列管理之间实现消息传输，必须要在两个队列管理器上都要定义相应的通道。发送方和接收方通道的组合形式如下：

	发送通道-接收通道（Sender-receiver ）
	请求器通道-服务器通道（Requester-server）
	请求器通道-发送通道（Requester-sender (callback) ）
	服务器通道-接收通道（Server-receiver ）
	群集发送通道-群集接收通道（Cluster sender –cluster receiver）

注意：通道的组合形式有5种形式，每种组合方式是固定的，用户不能随意组合。每对通道的名称必需相同例如：在发送通道-接收通道组合中，发送通道名和接收通道名必须一致，否则通道将无法启动。
消息通道用法
发送通道-接收通道（Sender-receiver）
图5 发送通道-接收通道
用法：由一个系统的发送通道来启动通道，以便它可以发送消息到另一个系统。发送通道向接收通道发送启动请求。发送通道从传输队列发送消息到接收通道。接收通道把消息放到目标队列。
请求器通道-服务器通道（Requester-server） 

用法：
(1)由一个系统中的请求器通道来启动通道，以便它能从另一个系统接收到消息。 请求器通道向通道另一端的服务器通道发送请求来启动。服务器通道从传输队列把消息发送到请求器通道。
(2) 服务器通道也能启动通道，并发送消息到请求器, 但这仅应用于完全意义的服务器通道, 也即服务器通道定义中应含有对方的连接名。一个完全意义的服务器通道可以由请求器通道启动, 也可以发起和服务器通道的通讯。
(3) 最好不要手工去停止Server和Request通道，而是依靠Server通道的Discint的属性来停止通道。

请求器通道-发送通道（Requester-sender (callback)）
用法：请求器通道启动通道，发送通道终止这个会话。 发送通道然后依据它的通道定义中的信息(称为 callback)来重新启动会话。它把消息从传输队列发送给请求器通道。最好不要手工去停止Sender和Request通道，而是依靠Sender 通道的Discint属性来停止通道。

服务器通道-接收通道（Server-receiver）
用法：类似于发送通道-接收通道，但仅应用在完全意义的服务器通道。也即服务器通道定义应含有对方的连接名，通道的启动方是服务器通道。

群集发送通道（Cluster sender）
用法：在一个群集中，每个队列管理器都有一个群集发送通道，通过它可以把送群集信息发送到其中一个队列管理器资源管理器。 队列管理器通过这个通道也可以把消息发送到其他的队列管理器。


群集接收通道（cluster receiver）
功能：在一个群集中，每一个队列管理器都有一个群集接收通道。通过这个通道可以接收数据消息和关于群集的消息。

2.1.4.2 MQI通道
	MQI通道是WebSphere MQ 客户端和服务器上的队列管理器的通信的通道。当客户端应用程序发出MQCONN或MQCONNX调用时，才开始建立连接。它是一个双向的通道，可以负责发送和接收，被用作MQI调用的传送和响应。如图所示：
 
图，MQI通道

一个MQI通道可以把一个客户端连接到单个队列管理器，MQI通道有两种类型，它们定义了双向的MQI通道。
客户端连接通道（Client-connection channel）
这种类型为WebSphere MQ 的客户端所使用。
服务器连接通道（Server-connection channel）
这种类型为运行队列管理器的服务器端所使用，运行在WebSphere MQ 客户端的应用程序将使用这种通道进行通信。
2.1.4.3比较消息通道和MQI通道
消息通道与MQI通道之间的区别可以从两方面进行比较：
	MQI通道是双向的：一个MQI通道可以被用来发送请求，也可用来接收响应。而消息通道则只能单向数据通信。如果要在两个队列管理器之间实现双向通信，那么需要定义两个消息通道，一个用来实现数据的发送，另一个用来实现数据的接收。
	MQI通道的通信是同步的：当一个MQI请求从客户端发送服务器端时，WebSphere MQ的客户端在发送下一个请求之间必须要等待来自服务器端的响应。而消息通道，在通道中传输的消息是与时间无关的。大量的消息可以从一个队列管理器发送到另一个队列管理器，发送队列管理器不必等待来自接收队列管理器的任何响应。


2.1.5进程
进程定义对象定义响应 WebSphere MQ 队列管理器上的触发器事件启动的应用程序。进程定义属性包含应用程序标识、应用程序类型和特定于应用程序的数据。 
2.1.6群集
在使用分布式排队的传统 WebSphere MQ 网络中，每个队列管理器是独立的。如果队列管理器需要将消息发送到另一个队列管理器，则它必须定义一个传输队列、一个到远程队列管理器的通道，以及它要将消息发送到的每个队列的远程队列定义。 
群集是一组以队列管理器可以在不需要传输队列、通道和远程队列定义的情况下在单个网络上彼此直接通信的方法设置的队列管理器。 
2.1.7名称列表
名称列表是包含其它 WebSphere MQ 对象列表的 WebSphere MQ 对象。通常，应用程序（如触发器监视器）使用名称列表，它们用于标识一组队列。使用名称列表的优点是它独立于应用程序维护；可以在不停止任何使用它的应用程序的情况下更新它。并且，如果一个应用程序失败，则名称列表不受影响，其它应用程序可以继续使用它。 
名称列表还与队列管理器群集一起使用，以维护多个 WebSphere MQ 对象引用的群集列表。 
2.1.8认证信息对象
队列管理器认证信息对象（AUTHINFO）组成安全套接字层（SSL）安全性的 WebSphere MQ 支持的部件。它提供使用 LDAP 服务器检查证书撤销列表（CRL）所需的定义。CRL 允许认证中心取消不再可信的证书。 
本书描述对认证信息对象使用 setmqaut、dspmqaut、dmpmqaut、rcrmqobj、rcdmqimg 和 dspmqfls 命令。有关 SSL 概述以及 AUTHINFO 的使用，请参阅 WebSphere MQ Security。 
2.1.9系统缺省对象
系统缺省对象是一组每次创建队列管理器时自动创建的对象定义。您可以复制和修改这些对象定义中的任何一个，以在安装时用于应用程序。 
缺省对象名具有项 SYSTEM.DEFAULT；例如，缺省本地队列是 SYSTEM.DEFAULT.LOCAL.QUEUE，并且缺省接收方通道是 SYSTEM.DEFAULT.RECEIVER。您无法重命名这些对象；这些名称的缺省对象是必需的。 
当您定义对象时，从相应的缺省对象复制您不明确指定的任何属性。例如，如果您定义本地队列，则从缺省队列 SYSTEM.DEFAULT.LOCAL.QUEUE 获取您未指定的那些属性。 
请参阅附录1, "系统和缺省对象"以获取有关系统缺省的更多信息。 

2.1.10 MQI（message queue interface）
MQI(消息队列接口)有下列组成部分：
	函数接口：应用程序通过函数可以访问队列管理器和它的部件。
	数据结构：应用程序使用提供的数据接口来是实现把数据传递给队列管理器，或从队列管理器中获得数据。
	基本数据类型：也是用来实现从队列管理器传递数据，或从队列管理器中获得数据。

2.2体系结构
	WebSphere MQ的体系结构如图所示，它是由许多对象所组成的，主要包括队列管理器、队列、通道、进程定义等对象。队列管理器和DB2数据库中的实例相似，它是有一组MQ进程和一些内存空间所组成的。它实现了应用程序通过MQI调用可以访问MQ的对象。
队列管理器为应用程序提供了排队服务，并管理属于它的队列。它确保： 
	根据接收到的命令更改对象属性。 
	当满足相应条件时，生成特殊事件（如触发器事件或检测事件）。 
	按照发送 MQPUT 调用的应用程序的请求，将消息放入正确的队列。如果不能完成，则将通知应用程序并给出适当的原因码。

所以在使用WebSphere MQ时，首先需要创建一个队列管理器，然后再队列管理器中在创建队列和通道等其他对象。

 
图，WebSphere MQ的结构


2.2.1 WebSphere MQ和消息排队
2.2.1.1 WebSphere MQ 和消息排队
WebSphere MQ 使应用程序通过使用消息排队来实现消息驱动处理，使用对应的消息排队软件产品实现在不同平台之间进行通信。从而使应用程序屏蔽了底层的通讯结构。 
WebSphere MQ 产品提供了消息队列接口（或 MQI）的公共应用程序编程接口，如果应用程序使用了MQI，将非常容易将应用程序从一个平台移植至另一个平台。 
WebSphere MQ 还提供高级别消息句柄 API，它使程序员更容易在企业内或企业间部署商业流程集成的智能网络。这称为应用程序消息传递接口（AMI）。AMI 将许多通常由消息传递应用程序执行的消息处理功能移动到中间件层，在此将代表应用程序应用企业定义的一组策略。 
如需更详细地了解 MQI 和 AMI，请参看《WebSphere MQApplication Programming Reference 》。 
2.1.2与时间无关的应用程序
程序不在网络上直接相互通信，而是间接地将消息放入消息队列。因为程序没有直接的联系，所以它们不必同时运行。消息放入适当的队列时目标程序可以是忙的。消息的到达并不影响程序的当前处理，也不意味程序需要立即处理该消息。消息放入队列时接收程序甚至根本不需要正在运行。接收程序可以在需要的时候开始执行。
2.1.3消息驱动处理
当消息到达队列时满足了触发条件，它们可以使用自动触发应用程序。 
2.2.2 队列管理器的进程	
 
图，队列管理器进程
启动了队列管理器之后，将会启动一组进程（如上图所示），现以unix平台为例，简单介绍一些进程的功能：
	以amqc开头的进程是和通道相关的进程。 
	amqhasmx进程是负责记录日志的进程(Logger)。
	amqharmx进程是负责日志格式化。(仅在线性日志中使用)。
	amqzllp0进程是检查点处理器(Checkpoint processor)。
	amazlaa0进程本地队列管理器的代理（Local queue manager agents）。
	amqzxma0进程是执行控制器（ Execution controller）。

2.3客户机和服务器

WebSphere MQ 支持其应用程序的客户机－服务器配置。 WebSphere MQ客户端通过MQI通道与WebSphere MQ服务器进行通讯。
WebSphere MQ 客户机是允许在系统上运行的应用程序对在另一个系统上运行的队列管理器发出 MQI 调用的组件。此调用的输出发送回客户机，此客户机将其输出传送回应用程序。 
WebSphere MQ 服务器是为一个或多个客户机提供排队服务的队列管理器。所有 WebSphere MQ 对象，例如，仅存在于队列管理器机器（WebSphere MQ 服务器机器）而不存在于客户机的队列。WebSphere MQ 服务器还可以支持本地 WebSphere MQ 应用程序。 
WebSphere MQ 服务器和普通队列管理器之间的差异是服务器与每个客户机有专用通信链路。要获取有关创建客户机和服务器的通道的更多信息，请参阅《WebSphere MQ Intercommunication》。 
要获取有关客户机支持的信息，请参阅 《WebSphere MQ 客户机》。 
客户机－服务器环境中的 WebSphere MQ 应用程序
当连接到服务器时，客户机 WebSphere MQ 应用程序可以与本地应用程序相同的方法发出大多数 MQI 调用。客户机应用程序发出 MQCONN 调用，以连接到指定的队列管理器。然后此队列管理器处理指定从连接请求返回的连接句柄的任何其它 MQI 调用。 您必须将您的应用程序链接到相应的客户机库。请参阅 《WebSphere MQ 客户机》 一书，以获取进一步信息。 

2.4触发机制
2.4.1触发的概念
队列管理器把某种条件叫做触发事件，如果队列被设置为触发类型并且触发事件发生了，队列管理器发送触发消息到一个叫做启动队列的队列中，触发消息被放置到启动队列过程意味着产生了触发事件。
由队列管理器产生的触发消息不是永久性消息，这将减少日志工作量（因此提高性能），并最小化系统重启时间。
处理启动队列中的消息叫做触发监控程序（trigger-monitor application）,他的工作是读取触发消息并根据触发消息的信息作出相应的处理。通常将启动别的应用程序来处理产生触发消息的队列。从队列管理器来看，触发监控程序没有什么特殊的，它只是一个从启动队列读取消息的应用程序。

如果队列被设置成触发形式，你可以选择创建一个进程定义（process-definition）的对象，这个对象包含了一个应用程序名，这个应用程序用来处理引起触发事件的消息。如果创建了进程对象，队列管理器将把应用程序名包含在触发消息中，以便触发监控程序可以使用。进程对象名需要在本地队列的ProcessName的属性中设置。每个队列可以配置一个进程对象，或几个队列可以共享同一个进程对象。

对于所有WebSphere MQ 或WebSphere MQ V5的产品，如果你想触发启动通道，可以不必定义进程对象。

有些平台的WebSphere MQ客户端也支持触发机制，例如：UNIX，Windows,OS/2。

运行在客户端的应用程序和运行在完全WebSphere MQ 环境的应用程序是一样的，只是应用程序链接的库有区别。同时触发监控程序和应用程序必需要都在同一系统中运行。

触发所涉及的对象：
	应用队列：是一个本地队列，并设置为可触发的。当触发条件满足时，将会产生触发消息。
	进程定义：一个应用队列可能由一个进程定义对象和它关联。进程定义中包含应用程序的信息。该应用程序负责从应用队列中取出消息。
	传输队列：如果用触发方式来启动通道，则需一个传输队列。传输队列的TriggerData属性中设置成将被启动的通道名。这将可省略进程的定义。
	触发事件：它是一种引起队列管理器产生触发消息的事件。
	触发消息：当触发事件发生时，队列管理器将产生触发消息。触发信息来自于应用队列和与应用队列关联的进程定义，它包含了将要被启动的程序名。
	启动队列：也是一个本地队列，它是被用来存放触发消息的队列。一个队列管理器可以拥有多个启动队列。一个启动队列可以为多个应用队列服务。
	触发监控器：是一个持续运行的程序，当一个触发消息到达启动队列时，触发监控器获取触发消息，并利用触发消息中的信息，启动应用程序来处理应用队列中的消息，并把触发消息头发送传递给应用程序，消息头中包括应用队列名。

在所有平台上，有一个特殊的触发监控器叫做通道启动器（channel initator），它的作用是启动通道。

2.4.2触发类型
	EVERY:当应用队列中每接收到一个消息时，都将产生触发消息。如果应用程序仅处理一个消息就结束时，可采用这种触发类型。
	FIRST：当应用队列中的消息从0变为1才会发生触发事件。如果当队列中的一个消息到达时启动应用程序，直到处理完所有消息就结束，则采用这种触发类型。
	DEPTH：当应用队列中的消息数目和TriggerDepth的属性值相同时，才会产生触发事件。当一系列请求的恢复都收到时，才启动应用程序，则采用这种触发类型。
当采用depth触发时，产生触发消息后，队列将被修改成非触发方式，如果需要再次触发，将要重新设置成允许触发。
队列的TriggerDepth属性表示引起depth触发事件发生时，队列中的消息数目。
2.4.3触发的工作原理
为了更好地能理解触发机制，我们举一个触发类型为FIRST的例子。
1.	只有一个本地或远程的应用程序A，往应用队列(Application Queue)中PUT了一条消息。
2.	当队列原来的深度为0时，也即队列为空，这时PUT一条消息到队列中，将会形成触发事件，同时会产生一条触发消息，触发消息中将包含进程定义（Process）中的信息。
3.	队列管理器创建触发消息，并把它PUT到与应用队列相关的启动队列（Initiation Queue）。
4.	触发监控器从启动队列中GET出触发消息。
5.	触发监控器处理触发消息，发出启动应用程序B的命令。
6.	应用程序B打开应用队列，并处理队列中的消息。

注意：
1.	如果队列的触发类型为FIRST或DEPTH，同时有多个应用程序往应用队列发送消息，这种情况下将不会形成触发事件。
2.	如果启动队列设置成不允许PUT消息，那么队列管理器将不产生任何触发消息，直到把启动队列的属性修改成允许PUT消息。
3.	如果通道设置成触发方式，建议触发类型为FIRST或DEPTH。


 

图 2.1触发消息和应用流程
一般情况下，特别是工作负载不均匀分布时，人们总希望有消息需要处理时，才启动相应的应用程序。
这种自动启动应用程序的机制被称作“触发”（Triggering）。基本原理是：当队列管理器发现有一条消息到达被触发的队列之后，他将产生一条


2.5 队列管理器群集
2.5.1 群集的概念
如果您熟悉WebSphere MQ和分布式队列，则可以把群集认为是一个队列管理器的网络，或是一个队列管理器的集合，群集中的队列管理器可以是不同的操作系统平台。每当您在群集中创建一个接收通道或定义一个队列时，则系统将自动在其它队列管理器中创建相应的发送通道和远程队列定义。
在群集中您不需要创建传输队列定义，因为WebSphere MQ在每个队列管理器中已经定义了一个传输队列。这个传输队列可以把消息发送到任何队列管理器中。
群集的信息是存放在资源库中。大多数队列管理器只保留它们自己所需要的信息，这些信息包括与它们通信的队列管理器和队列的信息。一些队列管理器包含了群集中所有队列管理器的所有信息。
下图显示了一个叫CLUSTER的群集：
	在这个群集中有三个队列管理器，QM1,QM2和QM3。
	QM1和QM2存放了群集中队列管理器的信息。它们被叫作完全资源队列管理器。
	QM2和QM3中有几个队列，这些队列能被群集中任何其它队列管理器。这些队列被叫作群集队列。
	每一个队列管理器有一个接收通道的定义，它被叫作群集接收通道。用来接收消息。
	每一个队列管理器也有一个发送通道的定义，它将和完全资源管理器的群集接收通道相连。这个通道叫做群集发送通道。在下图中,QM1和QM3有群集发送通道连接到TO.QM2，QM2有群集发送通道连接到TO.QM1。
一旦群集接收通道和群集发送通道已经定义好了，通道将自动启动。
 
图，队列管理器群集

2.5.2 群集的优点
使用群集有两个优点：
1.	减少系统管理
即使您创建了一个很小的群集，都将减少系统管理的工作。在群集中建立队列管理网络比在分布式队列建立网络将使用更少的定义。由于使用更少的定义，您将能够更快和更容易地建立和改变网络。并且降低了定义错误的风险。 
2.	增强可用性和实现负载均衡
简单的群集将更容易管理。对于复杂的群集，将提高了扩展性和可用性。因为您可以定义在不同的队列管理器定义相同的队列，因此工作负载可以在群集的队列管理器实现均衡。


2.5.3 群集的组件
	群集资源库（队列）
资源库中存放了群集中队列管理器的信息，包括队列管理器名，以及它们的通道和队列等。这些资源库信息通过一个叫SYSTEM.CLUSTER.COMMAND.QUEUE的队列进行交换，并存放到一个叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的固定队列中。
资源库可能是完全或部分的。每个队列管理器至少要连接到一个拥有完全资源库的队列管理器。
每一个群集队列管理器必须有一个叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的本地队列，在群集中至少一个群集队列管理器含有完全资源库。对于每个群集队列管理器，必须要预定义一个群集-发送通道连接到资源库队列管理器中。资源库队列管理器之间必须要互连，网络状况要比较好，和具有高可用性。普通队列管理器只包含有部分资源库信息。

	群集-发送通道
群集-发送通道的类型为TYPE(CLUSSDR)，群集队列管理器使用群集-发送通道可以把消息发送到完全资源库队列管理器中。这个通道被用来通知队列管理器状态的改变，例如，队列的删除和创建。它仅和第一个完全资源库队列管理器联系。
	群集-接收通道
群集-接收通道的类型为TYPE(CLUSRCVR)，群集队列管理器可以使用它接收群集内的消息。每一个群集队列管理器至少需要一个群集-接收通道。
	群集传输队列
从一个队列管理器发送到其它队列管理器的消息都将被放到SYSTEM.CLUSTER.TRANSMIT.QUEUE队列中，在每个队列管理器中必须要存在群集传输队列。

2.5.4 创建群集
下表是一个创建群集的脚本示例，群集名为NPC。

ALTER QMGR REPOS(NPC)

DEFINE CHANNEL(TO.QM0000) +
CHLTYPE(CLUSRCVR) CONNAME(‘192.168.10.11(1414)’ ) +
CLUSTER(NPC)

DEFINE CHANNEL(TO.QM1000) +
CHLTYPE(CLUSSDR) CONNAME(‘192.168.10.22(1414)’) +
CLUSTER(NPC) + 
DESCR(‘To Other Repository’)

DEFINE QLOCAL(0000_1) + 
CLUSTER(NPC)
其中群集传输队列和命令队列不用显示定义，队列管理器QM0000是NPC群集中一个完全资源库队列管理器。一个队列管理器可以同时属于多个群集。

在MQSeries v5.2以后版本，在群集中能够支持DHCP：
	在定义群集-接收通道时，不用说明队列管理器的网络地址。
DEFINE CHANNEL(TO.QM0000) +
CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER(NPC) 
	在定义群集-发送通道时，不用说明资源库队列管理器名。
DEFINE CHANNEL(TO.+QMNAME+) +
CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CONNAME(...) +
CLUSTER(NPC)

2.5.5 实现负载均衡
当在群集中含有同一队列的多个实例时，WebSphere MQ通过使用负载管理算法把消息发送到最方便的队列管理器中。负载管理算法尽可能地选择本地队列管理器作为目的地。如果在本地队列管理器中没有队列，这个算法将选择最合适的目标。合适的原则是取决于通道状态、队列管理器和队列的可用性。在满足条件的队列管理器之间，这个算法使用了轮循的方法进行选择。从而可以实现负载均衡的功能。

使用群集可以减少系统管理，也可以在群集中的几个队列管理器中创建同名的队列。只有拥有队列的队列管理器才能处理队列中的消息，但应用程序发送消息时不用显示说明队列管理器名。负载管理算法决定了那个队列管理器应该处理消息。

下图中显示了一个群集中定义了多个Q3队列的定义。当在QM1的应用程序放一个消息到Q3时，它不必知道是那个Q3队列将处理消息。
当消息正在传输时，群集中的一个本地队列变得不可用，那么消息将被转发到另一个队列中（但需要以BIND_NOT_FIXED的选项打开队列）。如果其它队列也不可用，这个消息将被放到死信队列中。
如果目标队列管理器不能工作，那么消息将仍然被放在传输队列中，系统将尝试更换消息的路由。这样做并不会影响消息的完整性，但如果出现队列管理器失败并消息处在可疑（in doubt）状态，这个消息将不能更换路由。
 
图，在群集中一个队列有多个实例

注意：
2.	在群集中创建同一队列的多个实例时，需要确保您的消息互相之间没有依赖，例如，消息需要按照特定顺序处理或被同一队列管理器处理。
3.	使同一队列的不同实例的定义相同，否则执行MQINQ调用将产生不同的结果。

在大多数情况下负载管理算法将满足系统的需求，然而您也可以编写用户出口(user-exit)程序来定制负载管理算法，WebSphere MQ中包含用户出口和群集负载出口（cluster workload exit），可以使用ALTER QMGR命令来激活群集负载出口。例如，ALTER QMGR CLWLEXIT(myexit) 欲了解更详细的有关信息，请参考《Queue Manager Clusters》。

2.5.6 群集管理
您有时需要对群集中的队列管理器进行维护，例如，您可能需要备份队列中的数据，或把补丁应用到系统中。如果队列管理器包含队列，则必须暂停队列管理器。当维护结束后，将继续队列管理器的工作。
	为暂停队列管理器，可以使用命令SUSPEND QMGR，例如：

SUSPEND QMGR CLUSTER(SALES)

它将临时从群集中移走一个队列管理器，这样将不会有任何消息发送到这个队列管理器。暂停的队列管理器和对象的信息都被保留在资源库中，但是队列管理器被标记为暂停。

	当维护队列管理器的工作完成后，需要让队列管理器继续工作。通过执行RESUME QMGR则可以实现，例如：
RESUME QMGR CLUSTER(SALES)
RESUME QMGR命令将通知完全资源库，这个队列管理器将又重新可用。完全资源队列管理器散布这个信息到其它队列管理器。
	在群集中的队列管理器可以执行刷新启动命令。在正常环境下不需要执行刷新命令，
例如：
        REFRESH CLUSTER(SALES)
    执行刷新命令，将丢弃所有本地的关于群集的信息。
	如果要从群集中强制除去一个队列管理器，则可以通过RESET CLUSTER命令实现。或一个队列管理器已经被删除，但是定义到群集的群集-接收通道仍然存在，那么您也可以使用RESET CLUSTER命令来快速地清理这些定义信息。

使用RESET CLUSTER命令是删除自定义群集-发送通道的唯一方法。在正常的环境中，您不必运行这个命令。这个命令只能在资源管理器中执行，例如：
RESET CLUSTER(SALES) QMNAME(QM0000) ACTION(FORCEREMOVE) QUEUES(NO) 
	查看群集中队列管理器信息，可以使用命令DISPLAY CLUSQMGR，例如：
DISPLAY CLUSQMGR(*) CLUSTER(SALES) 
	您可以定义群集队列，例如：
DEFINE QLOCAL(0000_1) CLUSTER(SALES) 

欲了解更详细的有关群集管理的信息，请参考《Queue Manager Clusters》。

2.6本章小结
	本章主要介绍WebSphere MQ的基本概念和体系结构，WebSphere MQ核心是由队列管理器、队列和通道组成。队列和通道分别有多种类型。在实际应用中，根据系统的实际需要选择合适的对象类型进行配置。描述了WebSphere MQ队列管理器的触发机制和群集的概念并介绍了它的优点以及实现方法。

2.7本章练习
1，	IBM WebSphere MQ中包含了那些对象？
2，	练习安装和连接WebSphere MQ客户端到服务器端的过程。
3，	在系统中创建的第一个队列管理器是缺省队列管理器？
(1) 是                 （2） 否
答案：（2）
4，	WebSphere MQ 使用一种什么接口，实现通过程序可以访问队列管理器的资源：
（1）	程序到程序的API(the program to program API)
（2）	消息队列接口（Message Queue Interface）
（3）	同步模式(the synchronous model)
（4）	触发机制(triggering)
答案：（2）
5，	WebSphere MQ仅异步环境的消息队列。
（1）对            （2）错
答案：（2）
6，	一个消息可以由下列那些部分组成：
（1）	应用数据（application data）
（2）	死信头 (a dead-letter header)
（3）	安全头 (security header)
（4）	消息描述块 (a message descriptor)
（5）	以上所有的 (all the above)
答案：（1）（2）（4）
7，	所有的消息至少有一个头，它是：
（1）	MQXQH（transmission header）
（2）	MQDLH (dead letter header)
（3）	MQMD (message descriptor)
（4）	MQTH (trigger header)
答案：（3）
8，	在WebSphere MQ触发机制，队列管理器启动被触发的程序：
（1）对                  （2）错
答案：（2）
9.临时动态队列中可以包含下列那些消息类型：
（1）	仅回复消息
（2）	仅报告消息
（3）	仅非永久性消息
（4）	永久性和非永久性消息
         答案：（3）