第 1 章 概念与原理
1.1简介
计算机软件发展到今天，很多具有独立功能的应用模块都被逐渐隔离出来形成软件产
品，这些软件往往是针对某一种应用需求，在相关的领域中具有很强的通用性。它们通常界
于操作系统和应用程序之间，为应用程序提供一些标准的服务，我们称这一类软件为中间件。
中间件根据其应用领域也分成多种，比如交易中间件、消息中间件、Web 中间件等等。
WebSphere MQ 本质上是一种消息中间件，用于保证异构应用之间的消息传递。应用程
序通过 MQ 接口进行互连通信，可以不必关心网络上的通信细节，从而将更多的注意力集
中于应用本身。MQ 在所有的平台上有统一的操作界面，这使得应用程序可以很方便地移植
到各种操作系统中。
1.1.1 消息中间件
在早先的时候，人们往往使用两个程序之间直接通信的方式。这种办法最大的问题就是
通信协议相关性，也就是说与通信协议相关的代码充斥在应用程序之中，而且可能出现在程
序的任何地方, 甚至影响程序的设计与结构。这种办法的另一个问题就是应用程序不容易写
出可靠强壮的代码。应用程序的通信部分会因为工作方式的灵活性、网络协议的通用性，以
及为实现一些实用功能变得非常庞大，往往超过应用程序本身的逻辑代码，变得本末倒置，
且代码很难写好，也很难维护。
人们开始慢慢意识到应该把通信代码放到外面，变成独立的工作进程或工作模块，不同
的工作进程可以适同于不同的通信协议，而应用程序与通信程序之间使用通用的本地通信方
式。这样一来，应用程序与通信程序的代码完全分开，各自的逻辑清晰自然，易于管理与维
护，在通信方式上前进了一大步。但是，这种方式对通信程序的编程要求比较高，如果考虑
到平台的广泛适用性，通信程序可能要写一大堆，要设计一个通用高效的本地通信接口也非
易事，再考虑到通信上的一些附加功能，其实现对普通编程人员是有一定困难的。人们很自
然地想到，这种工作最好交由专业的通信软件来完成。
于是，市场逐渐出现了专门负责消息通信的软件。它通常是一个独立运行的通信环境，
有统一的编程调用接口，可以跨平台，跨协议。不同结点之间的软件可以通过配置相互连通，
搭起统一的通信平台，从而出现更强大的功能。这种通信软件往往安全可靠、配置灵活，其
地位在操作系统之上，在应用程序之下，所以被称为消息中间件 (MOM) 。WebSphere MQ
就是其中的一款。
1.1.2 WebSphere MQ
WebSphere MQ 是IBM 公司于2003 年 2 月推出的面向消息传递的中间件产品，是IBM
MQSeries 产品线的最新力作。目前的版本是 5.3，它的前身是 MQSeries 5.1 和 MQSeries 5.2。
到了 5.3 版，产品的功能更丰富，更集成。与 IBM 公司的电子商务应用中间件 WebSphere
产品有很高的集成度和亲合性，从产品更名为WebSphere MQ 这一点就可见一斑。事实上，
WebSphere Application Server 5.0 版就可以内置安装一个嵌入式的WebSphere MQ。
WebSphere MQ 在面向消息传递的中间件 (Message Oriented Middleware, MOM) 市场
中赫赫有名，是用来连接异构平台之间企业应用的专业产品。通过 WebSphere MQ 可以屏
蔽不同的通信协议之间的差别，可以最大程度地简化网络编程的复杂性。通过 MQ 的配置，
通信双方的程序可以以松耦合的方式独自运行，并不关心对方所在的位置和状态，通过消息
驱动或消息触发的方式来相互联系。它支持多种平台，对消息支持交易式的提交与回滚。
WebSphere MQ 产品主页为 http://www.ibm.com/software/ts/mqseries ，相关的 WebSphere
MQ 产品家族主页为：http://www-3.ibm.com/software/integration/mqfamily/。在相关网站上可
以下载有效期为90 天的 WebSphere MQ 试用版。
WebSphere MQ 的补丁被称为CSD (Corrective Service Diskette)，比如CSD01 就是一号
补丁，后一号的补丁其内容完全覆盖前一号的补丁。WebSphere MQ 补丁可以在产品首页中
找到，其下载网址为 http://www-3.ibm.com/software/integration/mqfamily/support/summary/。
WebSphere MQ 还有大量的免费资料可以下载，其中包括 Client 端软件、例程代码、相
关工具、测评文档等等，内容十分丰富。IBM 公司称之为 MQ SupportPac ，下载网址为：
http://www-3.ibm.com/software/integration/support/supportpacs/。
1.1.3 WebSphere MQ 产品
IBM 公司将 WebSphere MQ 分成三个不同版本的产品：WebSphere MQ Express ，
WebSphere MQ，WebSphere MQ Extended Security Edition。其中，WebSphere MQ 是核心产
品，本书也只针对这个产品进行介绍。
基本上，WebSphere MQ 包含了 WebSphere MQ Express 的全部功能，而 WebSphere MQ
Extended Security Edition 又包含了 WebSphere MQ 的全部功能。它们的功能关系如图 1-1。
WMQ Extended Security Edition
WMQ
WMQ Express
图1-1 WebSphere MQ 产品
1.1.3.1 WebSphere MQ Express
WebSphere MQ Express 可以认为是 WebSphere MQ 的简化版，或称为体验版。它由
WebSphere MQ Client 和 WebSphere MQ Server 组成，其中 Client 部分可以在Windows、AIX、
HP-UX 和 SUN Solaris 平台上运行，每一个 UNIX 平台又可以有 SSL 附加功能。但 Server
部分仅限于Windows 和 Linux for Intel 平台，在使用上也有一定的限制。一个队列管理器的
通道连接最多只能有 10 个，Client 端通道连接最多也只能有 10 个，消息大小不能超过4MB
(当然，可以用消息分组的办法突破这一限制) 等等。WebSphere MQ Express 也不能所为远
程资源管理器加入全局交易中。
另外，WebSphere MQ Express 产品提供了一些独有的程序。比如：Express 产品漫游，
Express 文件传送，Express 信息中心等等。但是，在功能上并没有什么创新，仍然被WebSphere
MQ 所包含。
WebSphere MQ Express 适合于那些中小型的企业应用，在并发度上要求不高，传递数
据的量也不大，投资较少。WebSphere MQ Express 也适用于树状结构中下一层的结点，这
些结点通常对连接数要求不高。
1.1.3.2 WebSphere MQ
WebSphere MQ 是核心产品，它包含了 WebSphere MQ Express 的全部，也突破了连接
上的限制。完整的版本由 Client 和 Server 及相应的文档组成。Server 部分支持 Windows、
AIX、HP-UX、Solaris、Linux for Intel、Linux for zSeries 和 iSeries 平台。Client 部分除了支
持所有 Server 平台之外还支持很多其它平台，可以在 SupportPac 网站上免费下载。
Client 分为普通 Client 和 Extended Transactional Client。后者可以支持 Server 所为远程
资源管理器加入全局交易中。当然，这种环境需要有全局资源管理器，比如WebSphere、CICS、
Tuxedo 等等，具体参见 “交易”一章。对于 UNIX 平台，普通 Client 又可以选用支持 SSL
协议，用于配置基于 SSL 的Client/Server MQI 安全通道。
WebSphere MQ 是构建完整的异构应用互连平台所必需的，由于对连接数量没有限制，
可以根据需要架构各种复杂的网状或树状结构，通常对于大中型企业应用。
1.1.3.3 WebSphere MQ Extended Security Edition
WebSphere MQ Extended Security Edition 由WebSphere MQ 的全部加上Tivoli Access
Manager for Business Integration (TAMBI) 组成。它除了具有 WebSphere MQ 的全部功能，可
以保证数据传送之外，还有 TAMBI 的功能，提供一个集成的 MQ 安全环境，可以对消息加
密传送，可以生成数字签名等等。大型企业应用和敏感数据传送应用都可以选择这个产品。
1.2 概念与对象
WebSphere MQ 运行环境中有较多的概念，其中有一部分是可以作为实体进行的操作
的，称为 MQ 对象。每一个对象都有各自的属性，不同的属性决定了对象的特性和工作方
式。消息、队列、队列管理器、通道是 MQ 中最重要的概念和对象。
1.2.1 消息 (Message)
消息是WebSphere MQ 中最小的概念，本质上就是一段数据，它能被一个或多个应用
程序所理解，是应用程序之间传递的信息载体。消息可以大致分成两部分： 应用数据体和
消息数据头。(图 1-2)
消息数据头 应用数据体
消息属性 1001010101010101010100001010010101001001010101010100 … …
图1-2 消息的结构
l 消息数据头是对消息属性的描述，这段信息往往被队列管理器用来确定对消息的处
理。消息数据头可以由应用程序或系统的消息服务程序共同产生，它包含了消息在
传送中的必要信息，如目标队列管理器的名字，目标队列的名字，以及消息的其它
一些属性。
l 应用数据体是应用间传送的实质的数据消息，它可以是字串、数据结构甚至二进制
数据。包含的内容可以是文本、文件、声音、图像等任何数据，这些数据只对特定
的应用具有特定的含义。所以，应用数据体的结构和内容由应用程序定义，通信双
方需要事先约定报文格式。
消息可以分成持久 (Persistent) 消息和非持久 (Non-Persistent) 消息。所谓 “持久”的
意思，就是在 WebSphere MQ 队列管理器重启动后，消息是否仍然能保持。
在 WebSphere MQ 中，消息可以是有限长度的任何一段信息。所谓有限长度，在开放平
台 (Windows NT/2000/XP，AIX，HP-UX，Solaris，Linux) 上缺省是 4MB，但这个上限可
以调整到 100MB。也就是说，每段信息应该控制在这个有限长度中。当然，这并不限制
WebSphere MQ 用来传递更大的信息，比如文件。相关内容参见 “分组与分段”章节。
1.2.2 队列 (Queue)
我们可以简单地把队列看成一个容器，用于存放消息。队列按其定义可分成本地队列、
远程队列定义、别名队列定义、模型队列定义。图 1-3。其中只有本地队列是真正意义上的
队列实体，可以存放消息。远程队列定义和别名队列定义只是一个队列定义，指向另一个队
列实体。远程队列定义指向的是其它队列管理器中的队列，而别名队列指向的是本地队列管
理器中的队列。模型队列有一点特殊，它本身只是一个队列定义，描述了模型的属性，但是
当打开模型队列的时候，队列管理器会以这个定义为模型，创建一个本地队列，被称为动态
队列。
一个队列管理器下辖很多个消息队列，但每个队列却只能属于一个队列管理器。队列在
它所属的管理器中只能有一个唯一的名字，不能与同一个管理器的其它队列重名。当消息被
添加到队列中，它缺省将被加到最后，与之相反，删除消息缺省却是从头开始。
本地队列 别名队列 远程队列 模型队列
本地队列
普通队列
初始化队列 目标队列 死信队列
应答队列 命令队列
传输队列
图1-3 队列的分类
1.2.2.1 本地队列
本地队列按功能又可分成初始化队列，传输队列，目标队列和死信队列。初始化队列用
做消息触发功能。传输队列只是暂存待传的消息，在条件许可的情况下，通过管道将消息传
送其它的队列管理器。目标队列是消息的目的地，可以长期存放消息。如果消息不能送达目
标队列，也不能再路由出去，则被自动放入死信队列保存。(图 1-4)
应用程序 A 应用程序 B
队列管理器 1 队列管理器 2
消息通道
远程队列 别名队列
目标队列
传输队列
死信队列
图1-4 各种队列在消息传送时的作用
1.2.2.1.1 普通队列
能够真正长期存放消息的本地队列，我们称之为普通队列。一般说来，应用程序只对其
做简单的 MQGET 和 MQPUT 以收发消息，这也是系统中用得最多的消息队列。通常在不
致引起混淆的情况下，我们也将普通本地队列简称为本地队列。
1.2.2.1.2 传输队列
要送往远地的消息将放入传输队列。在适当的时候，消息会被从传输队列中取出并送往
远地，最终放入远端的本地队列。所以，从本地系统的立场来看，传输队列是用来暂时存放
输出消息的。
传输队列本身是一个本地队列，它与普通队列的差别是传输队列具有的属性 USAGE
(XMITQ)。
1.2.2.1.3 初始化队列
初始化队列是配合消息触发用的，如果队列上配置有消息触发功能，则需要指定另一个
相关队列以存放触发消息，这个队列就是初始化队列。初始化队列本质上就是一个普通本地
队列。
1.2.2.1.4 目标队列
在消息通信的时候，消息最终的目的地称为目标队列。如果消息是通过传输队列转发，
WebSphere MQ 会自动为消息体添加一个传输消息头，其数据结构为 MQXQH。其中的
RemoteQName 和 RemoteQMgrName 两个域指明了目标队列和目标队列管理器。如果消息被
放入死信队列，则 WebSphere MQ 会自动为消息体添加一个死信消息头，其数据结构为
MQDLH，其中 DestQName 和 DestQMgrName 两个域指明了原消息的目标队列和目标队列
管理器。
1.2.2.1.5 死信队列
死信队列本质上是普通的本地队列，由于队列管理器的DEADQ 属性指定的该队列为死
信队列，所以队列管理器认为无法投递的消息都被自动送去该队列。由于无法投递的消息很
像信件投递中的死信，故而得名。
队列管理器在将消息放入死信队列的时候，会自动为消息体添加一个死信消息头，其数
据结构为 MQDLH。其中 Reason 域指明了消息无法投递的原因。
1.2.2.1.6 应答队列
由于消息在发送后需要有对方的回应。这种回应可以是系统自动产生的报告消息，也可
以是对方应用生成的应答消息。就应用而言，这些回应消息的目标队列就是应答队列。应答
队列通常设置在消息头 (MQMD) 的 ReplyToQ 域中，它也总是与消息头中的另一个域
ReplyToQMgr 一起使用。
1.2.2.1.7 命令队列
指的是 WebSphere MQ 队列管理器中预定义的SYSTEM.ADMIN.COMMAND.QUEUE 。
任何 MQSC 命令都可以送往该队列，并被队列管理器的命令服务器 (Command Server) 接收
处理。
1.2.2.2 别名队列
别名队列只是一种队列定义，它自身只是队列的逻辑名字，并不是队列实体本身。别名
队列的TARGQ 属性指明了其代表的目标队列名称，目标队列通常是本地队列。其实别名队
列只是提供了队列名称之间的映射关系，可以将别名队列看作是指针，指向其目标队列。注
意，这里的目标队列自身又可以是一个别名队列，指向下一个目标队列。然而，在对别名队
列打开 (MQOPEN) 操作时，只允许别名队列指向的目标队列是一个本地普通队列，即一层
映射关系。如果存在上述的多层映射关系，则报错MQRC_ALIAS_BASE_Q_TYPE_ERROR。
通过别名定义，WebSphere MQ 也可以动态改变消息流向。比如：某程序在代码中指定
消息写入队列 A，但是您希望在不变动代码的情况下将消息写入队列 B。这时只要定义别
名 B，使之指向 A 即可。再如：某队列 C 是可读可写的本地队列，管理员希望它对于一
类程序只可读，对另一类程序只可写，这时可以对 C 定义两个别名 D 和 E，D 只允许读，
E 只允许写。也就是说，本地队列 C 的属性为GET(ENABLED) 且 PUT(ENABLED)，将 D
的属性设置为GET(ENABLED) 且 PUT(DISABLED)，E 的属性为GET(DISABLED) 且
PUT(ENABLED)。将 D 和 E 分别提供给上述两类程序使用，这样可以完全避免应用程序的
误操作。
1.2.2.3 远程队列
远程队列与别名队列类似，也只是一个队列定义，用来指定远端队列管理器中的队列。
使用了远程队列定义，程序就不需要知道目标队列的位置 (所在的队列管理器) 了。
远程队列定义包括目标队列管理器名和目标队列名，而这种队列定义对于访问地的应用
程序是透明的。这种技术不但使应用程序只需要对一个简单的队列名操作，而且可以在线地
通过修改远程队列定义，而动态改变路由。
1.2.2.4 模型队列
模型队列定义了一套本地队列的属性集合，一旦打开模型队列，队列管理器会按这些属
性动态地创建出一个本地队列。模型队列的 DEFTYPE 属性可以取值 PERMDYN 和
TEMPDYN ，分别代表永久动态队列和临时动态队列。
1.2.2.4.1 永久动态队列
永久动态队列由模型队列动态创建，并可以永久存在。在调用 MQOPEN 时创建，以后
就和普通的本地队列一样工作。在调用 MQCLOSE 时，缺省情况下会保留消息和队列，当
然也可以通过设置关闭选项 (Close Option) 的来清除消息甚至删除永久动态队列。
1.2.2.4.2 临时动态队列
临时动态队列也是由模型队列动态创建，但只在会话 (Session) 中临时存在。在调用
MQOPEN 时创建，在同一个线程中 MQCLOSE 时关闭并自动删除。MQCLOSE 时无所谓关
闭选项 (Close Option) 的取值。
1.2.3 队列管理器 (Queue Manager)
队列管理器构建了独立的WebSphere MQ 的运行环境，它是消息队列的管理者，用来维
护和管理消息队列。一台机器上可以创建一个或多个队列管理器，每个队列管理器有各自的
名字，通常情况下，它不能与网络中的其它队列管理器重名。如果我们把队列管理器比作是
数据库，那么队列就是其中的一张表，消息就是表中的一条记录。
队列管理器是负责向应用程序提供消息服务的机构。在 WebSphere MQ 中，队列管理
器集成了对象的定义、配置、管理、调度以及提供各种服务的功能于一身。WebSphere MQ
的系统管理工具提供了对系统部件配置与管理的功能，应用程序必须首先连接到队列管理
器，然后在队列管理器的控制下对各种对象进行操作。
WebSphere MQ 中的队列管理器可以含有很多个队列，但一个队列只能属于一个队列管
理器。一个操作系统平台可以创建一个队列管理器，也可以创建多个队列管理器。队列管理
器、队列、通道等等都是 WebSphere MQ 的对象，所有的对象都有各自的属性，有些属性
必须在对象创建的时候指定，有些可以在创建以后更改。
1.2.4 通道 (Channel)
通道是两个队列管理器之间的一种单向的点对点的通信连接，消息在通道中只能单向流
动。如果需要双向交流，可以建立一对通道，一来一去。站在队列管理器的角度，这一对通
道可以按消息的流向分成输入通道和输出通道。通过配置，对于放入本地传输队列中的消息，
队列管理器会自动将其通过输出通道发出，送入对方的远程目标队列。
两个队列管理器之间可以有多条通道负责传输不同的内容，这样设计往往是为了将不同
优先级的消息错开，运行于不同速率的网络连接上。或者即便是所有通道都运行于相同的网
络物理连接上，也可以将不同大小的消息传送分开，以免小数据传送被大文件所堵塞。如果
多条通道共享一条网络物理连接，通道的速率之和受限于网络速度。这样可以增加传送的并
发度但并不能增加整体的传送速度。
在通道上可以配置不同的通信协议，这样就使得编程接口与通信协议无关。通道两端的
配置必须匹配，且名字相同，否则无法连通。队列管理器之间的通信是通过配置通道来实现
的，通道两侧的队列管理器对这个通道的相关参数应该能对应起来，一个通道只能用一种通
信协议，但不同的通道可以有不同的通信协议。可见，通道是架设在通信协议之上的对象，
架设在不同通信协议上的通道在应用层看来都大同小异。
1.2.4.1 通道类型 (Channel Type)
WebSphere MQ 用通道类型属性 (CHLTYPE) 约定了通信双方在连接握手协议中的主
动方和被动方以及应用消息的流向。可选以下这些类型：
l SDR Sender 。握手协议的主动方，消息的发送方
l RCVR Receiver 。握手协议的被动方，消息的接收方
l SVR Server 。在握手协议中可以是主动方也可以是被动方，消息的发送方
l RQSTR Requester 。在握手协议中可以是主动方也可以是被动方，消息的接
收方
l CLNTCONN Client Connection 。在 Client-Server 连接时，定义客户端连接定义表
(Client Channel Definition Table) 时使用。握手协议的主动方，消息
的发送方
l SVRCONN Server Connection。在 Client-Server 连接时，定义服务器端连接时使
用。握手协议的被动方，消息的接收方
l CLUSSDR Cluster Sender 。在群集中发送配置信息和应用消息。握手协议的主
动方，消息的发送方
l CLUSRCVR Cluster Receiver 。在群集中接收配置信息和应用消息。握手协议的被
动方，消息的接收方
通信双方的通道类型配对并不是可以随意排列组合的，共有六种。如图 1-5：
Sender Server Server Sender
Requester
Receiver Receiver Requester Requester
Sender Connection Cluster Sender
Receiver Connection Cluster Receiver
图1-5 通道类型的配对
图中细线箭标表示握手协议中的主动连接，粗线箭标表示应用消息流向。消息在所有的
通道上都是单向传送的。
l Sender/Receiver 是所有连接中最简单、最常用的一种。Sender 是通道主动方，也是
消息发送方。
l Requester/Server 也是常用的一种连接方式。Requester 是通道主动方，但通道连接
后，它作为消息接收方，Server 是消息发送方。
l Server/Receiver 与 Sender/Receiver 类似，Server 是消息的发送方，也是连接的主动
方。与 Sender 定义类似，Server 定义中必须指定 CONNAME 参数。
l Sender/Requester 的连接过程稍微复杂一些，Requester 首先与 Sender 连接，在通知
对方连接参数后连接断开。Sender 进行反向连接，消息也是反向传送的。这种反向
连接的方式，称为 Callback Connection 。
l Sender Connection/Receiver Connection 与 Sender/Receiver 方式相同 。用于
Client/Server 之间的 MQI 通道。
l Cluster Sender/Clueter Receiver 与 Sender/Receiver 方式相同。用于群集中队列管理
器之间的连接。
由于Sender/Receiver、Server/Receiver 的连接主动方和消息发送方相同，所以可以在发
送端设定通道触发 (Channel Trigger) 。
由于Sender/Receiver、Server/Receiver、Requester/Server 的连接被动方事先不需要知道
主动方的连接参数，所以可以用于连接主动端是动态地址的应用场合。
由于Sender/Requester 有反向建立连接的功能，所以常常用于双向安全认证。
1.2.4.2 消息通道协议 (MCP)
消息通道协议是 WebSphere MQ 用来传递消息时使用的通信协议。MCP (Message
Channel Protocol) 可使用多种底层通信协议传递消息 （LU6.2, DECNet ...）。消息通道协议使
得消息的传送独立于通信协议，应用程序通过统一的接口与 MQ 打交道，而不再需要关心
通信层使用的是TCP/IP 还是SNA。目前MCP 支持的通信协议有LU6.2、DECNet 和TCP/IP。
不同操作系统的 WebSphere MQ 支持的通信协议的数量和种类可能稍有不同，详情请
参见本操作系统的 《WebSphere MQ 用户手册》
1.2.4.3 消息通道代理 (MCA)
消息通道代理 (MCA，Message Channel Agent) 本质上是一个通信程序，它用来在队列
管理器之间传递消息。通道可以以进程的方式工作，即独立的MCA 进程。也可以以线程的
方式嵌入系统 MCA 进程中工作。对于前者，根据不同的 MCP ，发送端进程和接收端进程
的MCA 名通常是不同的。
1.2.5 名称列表 (Name List)
名称列表是WebSphere MQ 的一种对象，它实质上是多个其它 WebSphere MQ 对象的名
称集合。其内容由多个字串组成，中间用逗号隔开，每个字串就是一个对象名称。
名称列表本身无法代表它所含的对象，例如无法对名称列表进行 MQPUT 或 MQGET
操作，类似的操作应该由分发列表 (Distribution List) 完成。定义名称列表只是定义了一个
集合，往往是为了方便应用访问多个对象。比如应用程序动态地从名称列表中读出操作对象
并依次进行操作，如果操作的对象有所增减，只需要修改名称列表即可。名称列表使管理人
员可以在不修改应用的前提下，通过动态地增减名称列表中的内容来进行管理。
名称列表多用于群集 (Cluster) 环境中指定一个队列管理器同时属于多个群集的情况，
这时名称列表的内容就是多个群集的名称集合。名称列表可以用于以下一些对象属性：
l QMgr.REPOSNL
l QMgr.SSLCRLNL
l Queue.CLUSNL
l Channel.CLUSNL
WebSphere MQ 中每个对象都有各自的属性，它们中的大多数是可以创建后修改的。这
里，我们采用 “对象.属性”的记号方式表示对象的属性，例 Queue.CLUSNL 表示队列的
CLUSNL 属性。以下同。
1.2.6 分发列表 (Distribution List)
分发列表可以使WebSphere MQ 应用程序一次将一条消息同时发送到多个队列上。这里
的一次发送指调用一次 MQPUT 或 MQPUT1，多个目标队列可以是本地队列也可以远程队
列，如果多个远程队列的目标队列管理器相同，则在网络上只需要传送一次即可，节省了网
络开销。当消息到达目标队列管理器后，再自动分发到各个目标队列中，当然这要求源队列
管理器和目标队列管理器都支持分发列表功能。
分发列表的操作是可以在一个交易中完成的，也就是说，多个队列的发送是可以一起提
交或回滚的。
1.2.7 进程定义 (Process)
进程定义对象用于 WebSphere MQ 的触发机制中，用来描述触发程序的对象。这个程序
可以是一个操作系统程序，可以是一个 MQ 应用，也可以是一个 CICS 交易，在进程定义的
属性中需要设定触发程序的路径、名称、参数等等信息。
在消息触发环境中，一旦触发条件满足即可引起触发，队列管理器在生成触发消息的时
候会参考进程定义，将定义中某些属性被抄入触发消息头 (MQTM 结构) 中，形成触发消息。
该触发消息被触发监控器读走并处理，监控器可以根据 MQTM 触发消息头中的信息启动相
应的进程。
1.2.8 认证信息 (Auth Info)
认证信息 (Authentication Information) 定义了SSL 认证所需要的证书吊销列表 (CRL，
Certificate Revocation List) 所在的 LDAP 服务器，同时定义了连入该LDAP 服务器所需的用
户名和口令。
1.2.9 客户端和服务器端 (Client & Server)
WebSphere MQ 分成客户端和服务器端，只有服务器端有对象的概念，所以只有服务器
端的应用程序可以对本地对象进行直接操作。客户端通过 MQI 通道与服务器端相连接，客
户端应用程序发出的所有操作指令都通过该通道传送到服务器，在服务器端执行后结果返回
客户端。通常情况下，客户端的应用程序代码与服务器端相同，在程序编译时连接的库文件
不同。
1.2.10 操作界面 (MQ Interface)
应用程序通过操作界面与 WebSphere MQ 打交道，这里的操作界面就是消息队列接口
(Message Queue Interface，MQI)。MQI 实际上是一套编程接口，负责处理应用程序向
WebSphere MQ 提交的各种操作请求，应用程序完全不需要关心 WebSphere MQ 的内部结构
与具体实现，如消息队列，传输队列等等。
当应用程序通过 MQI 送出一条消息到远程队列，队列管理器会在它的消息数据头中加
上路由信息，消息被转入传输队列，等待送出。MQI 的操作非常简单直观，如：MQOPEN、
MQCLOSE、MQGET 、MQPUT 等等。
由于MQ 的互连通信是通过存储转发机制完成的，所以操作与传输是异步的。这意味
着应用程序通过操作界面将消息发送出去时，消息首先存储在本地，当通信畅通时再被转发。
应用程序可以继续处理自己的逻辑，而不必等待消息传达对方。
1.2.11 应用程序 (MQ Application)
应用程序可以是商业的或用户自行开发的含有对 WebSphere MQ 操作的程序。MQI 提
供了支持的有平台的通用编程接口，如 VSE/ESA 上的 COBOL，Tandem Guardian 上的
TAL 和 C，其它平台上的 C。应用程序只要能够调用相应的库函数，它就可以操作
WebSphere MQ。
这一节介绍了 WebSphere MQ 中的基本概念和对象，其中最核心的部分是消息、队列、
队列管理器和通道。对于编程设计人员，通常更关心消息和队列，对于维护管理人员，通常
会更关心队列管理器和通道。下面让我们来看一看这些对象的工作原理。
1.3工作原理
WebSphere MQ 的工作原理的核心就是存储转发。在单个队列管理器的环境中，队列可
以用于存储应用间传递的消息，从而使应用程序在各自环节上进行处理，并通过队列形成环
环相扣的处理流程。在多个队列管理器的环境中，消息可以跨平台进行流动，从而使整个处
理流程在分布式计算环境中完成。
1.3.1 PUT 和 GET
WebSphere MQ 的应用程序可以通过MQ 界面 (MQI，MQ Interface) 进行操作。实际上，
MQI 提供了有限的 API，其中最本质的两个动作是 PUT 和 GET 。PUT 指应用程序放一条消
息放入到队列中，GET 则相反，应用程序将一条消息从队列中取出。WebSphere MQ 通过队
列机制来完成消息排队和传递的工作，从而使应用程序之间实现松耦合的联系。如下图，应
用程序 A 产生消息，通过 PUT 调用放入队列中，应用程序 B 将消息取出并进行相应的处理，
消息的报文格式及内容决定了应用程序 B 处理的具体工作。这样就实现了应用程序 A 到 B
之间的单向消息传递，如果需要双向传递消息则必须再类似地约定反向队列。图 1-6。
消息 消息
应用程序A 应用程序B
队列
图1-6 应用通过队列传递消息
应用程序设计的时候必须约定双方的报文格式，如果用通用格式 (如 XML) 则需考虑
由此带来的灵活性和信息冗余，在两者之间平衡选择。在运行环境中，还需要考虑 PUT 和
GET 的频率与速度，以免消息有在队列中堆积起来。
WebSphere MQ 提供的远程队列机制可以将目标队列设定到另外一个队列管理器中，这
样应用程序 A 和 B 就可以在两台机器上运行而不改动任何代码，应用程序 A 仍然做着相同
的 PUT 操作将消息放入队列中，该消息会自动路由到另一个队列管理器中的队列中，应用
程序 B 从该队列中 GET 消息，与原先一样地处理。也就是说，这种配置结构上的改变对应
用程序是完全透明的。WebSphere MQ 的这种特性使得其应用的扩展性极佳，任何应用在设
计之初并不需要考虑太多的性能及扩展性问题，在需要时可以很方便地将应用中任何一部分
拆到其它的机器上，实现多机计算。图 1-7。
消息 消息
应用程序A 应用程序B
队列 队列
图1-7 应用通过队列跨网络传递消息
1.3.2 协同工作
通常说来，一个应用系统会由多个应用模块组成，一个处理流程也会由多个处理步骤组
成。它们之间可能是串行的关系，也可能是并行的关系。在 WebSphere MQ 应用设计中，我
们可以自然地将多个模块或多个步骤设计成不同的应用程序，而它们之间的中间数据则通过
消息的方式传递，用队列暂存。图 1-8。这样一来，应用系统会有以下好处：
1. 结构清晰，容易并行开发和调试。
2. 扩展性极好，能够很容易地布署到跨平台环境中。
3. 灵活性好，一旦流程改变了，可以较容易地进行修改。
队列2
应用程序A 应用程序B 应用程序C
队列 1 队列4
队列3
图1-8 协同工作
这样，在应用系统设计的时候只需要考虑它的逻辑架构，而无需担心它的物理布署。各
个处理环节可以通过 WebSphere MQ 贯穿起来，协同工作。
1.3.3 互连通信
1.3.3.1 消息通道 (Message Channel)
WebSphere MQ 跨平台的互连通信是依靠队列管理器之间的消息通道实现的，消息通道
就是消息传递的管道，架设在队列管理器之间，消息从一头流入从另一头流出，消息的内容
和次序完全不变。
配置通道时需要注意通道在两个队列管理器中同名，且类型要配对，见 “概念与对象”
章节。WebSphere MQ 中通道中消息是单向传递的，但通道上的协议控制信息可以双向传递。
如果需要双向传送消息，则需要创建双向的通道定义。
1.3.3.2 消息路由 (Message Routing)
我们首先拿现实生活中寄信做例子来类比 WebSphere MQ 中的一些基本概念，从而理
解 WebSphere MQ 的工作原理。现实生活中家家户户都可能有一个通信地址，对应着一个存
放到达信件的信箱。每一封寄出的信件总是先到本地邮局，通过邮局之间的信件交换，到达
对方所在的邮局，最后到达对方的信箱里。中间的邮路越复杂，时间就越长。这里的邮局相
当于 WebSphere MQ 中的队列管理器，信箱相当于队列，信件相当于消息。我们的每一封
信件都有信封和信瓤两部分，信封上面往往有收信人通信地址和发信人通信地址，信瓤里是
真正的内容 (图 1-9)。WebSphere MQ 中的消息也一样，它分成消息头和消息体两部分。消
息头是消息的属性集合，含有目标队列管理器名和目标队列名，WebSphere MQ 就是利用这
段消息来找到目标队列的。消息体是消息的内容，可以是任意的一段内存信息。
Hi,
How are you?
图1-9 信封和信瓤
WebSphere MQ 依靠每条消息头上所含的路由信息，将消息准确地送达目的地。路由信
息中的远程队列管理器名指的是远端系统的名字，远程队列名指的是远端系统中的目标队列
名。一个完整的队列名应该包含两部分：队列管理器名和队列名，格式为
queue_name@queue_manager_name。两部分名字的长度上限都是 48 字节，这两部分名字构
成了消息路由的最基本的信息，算法其实很简单：
如果队列管理器名未标明，则缺省加上本地队列管理器的名字。队列名会缺省地匹配要
地普通队列，而队列管理器名会缺省地匹配本地队列管理器名或传输队列名。一般说来，建
议传输队列名与远程队列管理器同名。消息传送过程如下：
1. 应用程序通过 MQI 发送消息
2. WebSphere MQ 查看 queue_manager_name 是否是本地队列管理器
a) 如果是的，将消息放入本地的名为 queue_name 的消息队列中
b) 如果不是，将消息放入名为 queue_manager_name 的传输队列中
3. MCP 会把传输队列中的消息送达远端
4. 远端的消息队列将消息放入远端系统中名为 queue_name 的消息队列中
5. 远端的应用程序从远端的本地队列中取得消息
这种办法提供了简单的路由功能，但有一个明显的缺点，直接使用全名会要求应用程序
了解软件的网络结构分布，哪些队列在哪里。这有悖于 WebSphere MQ 对应用程序隐藏网
络细节的设计初衷。所以，在跨队列管理器的应用中，通常使用别名队列和远程队列来指定
对方队列的名字，从而将队列的分布信息保留在配置中。
1.3.3.3 消息传送
我们在实现消息的跨队列管理器之间的传送时，通常会在本地队列管理器上配置远程队
列和传输队列，在远端的队列管理器上配置本地队列，并通过通道将两者连接起来。图 1-10。
这里的远程队列只是一个定义并无队列实体，也就是说远程队列不能存放消息。应用程
序一旦将消息通过 MQPUT 送出，则立刻放入传输队列中。传输队列暂时存放待由通道发送
的消息，一旦通道连通且条件允许，系统通信程序MCA 会立即将消息送出。消息到达对方
目标队列管理器后，由对方的通信程序MCA 接收下来并放入相应的目标队列。这里的目标
队列就是目标队列管理器上的本地队列。整个过程的效果就好像应用程序直接将消息送入目
标队列一样。
队列管理器1 队列管理器2
应用程序
远程队列
消息
MCA MCA
传输队列 目标队列
图1-10 消息的传递过程
远程队列的定义实际上就是指定的目标队列的位置及传输路径。其中，目标队列的位置
通过设定目标队列名和目标队列管理器名来确定，消息在路由过程中寻找该目标地址。传输
路径就是传输队列名，消息会通过该传输队列送出。不同的远程队列可以共用一个传输队列。
传输队列本质上是一个本地队列，只是由系统通信进程MCA 监护。应用程序可以人为
地通过 MQPUT 放一条消息到传输队列上，但如果该消息没有传输头 (MQXQH) ，则不会被
发送，消息按以下方式处理：
1. 如果队列管理器设置了缺省死信队列，则消息放入该死信队列，死信消息原因码为
MQFB_XMIT_Q_MSG_ERROR。
2. 如果队列管理器未设置缺省死信队列，则对于非持久性消息，消息被仍掉。对于持
久性消息，消息会留在传输队列中无处可去，这时有可能会堵住后继的消息，造成
通道无法发送。
消息在经过远程队列放入传输队列时会由队列管理器自动添加一个传输头 (MQXQH) ，
且传输头中的内容会根据远程队列定义自动填写。如果说，原先的消息是MQMD + Body，
则放入传输队列的消息为MQMD + MQXQH + Body。
第2 章 安装
我们在前面介绍了 WebSphere MQ 的相关概念及其工作原理，从这一章开始介绍动手操
作和管理，让我们从产品安装开始。
WebSphere MQ 的安装过程中有不少选择分支，从而可以安装出不同的效果。事实上，
安装中的选择大部分可以在以后的管理和配置中再进行调整。由于初学者对这一过程不熟悉
比较容易混淆，从而给以后的操作带来不便。这里以 Windows 平台上的 WebSphere MQ 5.3
为例，详细描述产品安装的全过程。同时也简单介绍了其它UNIX 平台的安装过程。
