IBM WebSphere MQ消息通道的配置和维护介绍（一）

转自：http://hi.baidu.com/xiangnvbing/blog/item/4f8e11f71bb10332730eecc5.html

IBM WebSphere MQ消息通道的配置和维护介绍（一）

2010-11-19 1:18

1. 概述 WebSphere MQ作为IBM软件家族的消息传输中间件产品，以其出色的特性和功能在业界享有盛誉。WebSphere MQ独特的安全机制、简便快速的编程风格、卓越不凡的稳定性、可扩展性和跨平台性，以及强大的消息通讯能力，使得它在银行、电信，还是在交通运输、政府机关等各行各业，赢得了很高的市场份额。在中国，WebSphere MQ同样拥有广泛的用户基础和许许多多的成功案例。它不仅具有跨平台、跨网络的特性，而且以其特有的先进机制保证对消息的"Once and Once only"的传输，做到不丢失、不复传。在WebSphere MQ给客户带来的众多价值中，有一点十分重要，就是它的通讯感知和恢复机制，尤其适用于我国目前的现状，在我国很多地方存在网络线路质量差，网络状态不稳定的现状。因为WebSphere MQ在支持同步通讯的同时，提供了基于消息队列存储-转发机制的异步通讯模式，应用程序只需将消息交给WebSphere MQ，就由WebSphere MQ负责将消息安全、可靠地发送出去，不再需要应用和人工的干预，当网络出现故障的情况下，或对方主机发生故障时，WebSphere MQ能够作到不需要人工干预，自动探测网络状况的好坏，并且在网络恢复正常之后能够继续正常工作，也即断点续传。 在WebSphere MQ的系统配置和维护中，通道(Channel)的配置和维护是较复杂也是最重要的部分，本文将对如何配置和维护WebSphere MQ消息通道进行介绍，并附录有关实现WebSphere MQ队列管理器双向通讯对象配置脚本。 2. 消息通道的配置 2.1 消息通道的类型 消息通道是把消息从一个队列管理器送到另一个队列管理器的通道。不要和MQI通道混淆，MQI通道是在MQ客户端和MQ服务器队列管理器之间发送消息的通道。我们这里讨论的是消息通道。WebSphere MQ中通信双方的消息通道类型有6种： l Sender l Receiver l Server l Requester l Cluster sender l Cluster receiver 上述消息通道类型配对共有5种： l Sender-receiver l Requester-server l Requester-sender(callback) l Server-receiver l Cluster sender-cluster receiver 下面分别对各种组合进行介绍，并给出配置脚本 2.1.1   Sender-receiver Sender/Receiver通道是最常见的通道配置方式，Sender作为通道的发送方也是通道连接的主动发起方，Receiver作为通道的接收方也是通道连接的被动监听方。 在下面配置脚本中，通道连接两个队列管理器QM1和QM2。其中，QM1为Sender方，QM2为Receiver方。在QM1上配置了远程队列（QR2）和传输队列（TO.QM2），其中QR2指向队列管理器QM2上的本地队列（QL2），且QR2与TO.QMB2对应，即凡是要放入QR2队列的消息，在加上传输消息头后直接放入TO.QM2中等待发送。QM1上配置Sender通道（QM1.QM2）需要指定传输队列名以及对方的通信参数（IP地址和端口），通信参数必须与QM2上的侦听程序设置匹配。 Sender通道与传输队列TO.QM2对应，表示凡是在TO.QM2中等待发送的消息最终都可以由该通道送出。双方通道必须同名。 在连接通道的时候，我们只需在QM1端启动通道Start channel(QM1.QM2)。 2.1.2   Server-receiver Server/Receiver与sender/Receiver类似。Server端是消息的发送方，也是连接的发起方。在配置的时候，必须指定对方的通信参数，由CONNAME设定。 2.1.3   Server-requester Server/Requester通道也是一种较常见的通道配置方式，如图2所示。从消息流向来看，Server作为消息的发送方，requester作为消息的接收方。但是从连接方式来看，requester却是连接的主动方，server是被动方。这种模式常用于动态IP地址的环境中，Server是静态IP地址的服务器，Requester的机器上网后自动分配到一个IP地址，所以是动态的，由Requester发起连接后接收数据。 2.1.4  Sender-requester Sender/Requester的连接过程稍微复杂一些，如图3所示。Requester首先与Sender连接，在通知对方连接参数后连接断开。Sender进行反向连接，消息也是反向传送的，即由Sender传给requester。这种反向连接的方式，称为回调连接（callback connection）。这种模式也常用于做双向验证，即双方必须都要知道对方的通信参数才能完成回调连接。 2.1.5   Cluster sender-cluster receiver 在一个cluster环境中，每一个队列管理器都一个Cluster sender通道，通过这个通道把消息发送到完全资源队列管理器，每一个队列管理器也有一个cluster-receiver通道可以用来接收cluster中的消息。 在本文中我们不重点介绍cluster sender-cluster receiver通道。 2.2 消息通道的触发机制 2.2.1   触发器原理 触发（Triggering），是一种自动启动应用程序的机制。 队列管理器把某种条件称为触发事件。如果队列被设置为触发类型，并且触发事件发生了，那么队列管理器将发送一个触发消息到一个称作启动队列的队列中。触发消息被放置到启动队列的过程意味着产生了触发事件。 处理队列管理器中的消息是触发监控程序(Trigger-Monitor Application)，他的工作是读取触发消息并根据触发消息的信息做出相应的处理。触发监控程序没有什么特殊，它只不过是从启动队列读取消息的应用程序。 当队列管理器发现由一条消息到达被触发的队列之后，它产生的触发消息将被存放到启动队列中，触发监控程序将从启动队列中取出触发消息，并根据触发消息中的内容，启动相应的消息处理程序来处理被触发队列中的消息。 触发所涉及的对象如下所示： 1)       应用队列(Application Queue)：一个本地队列并设置为可触发。当触发条件满足时，将会产生触发消息。 2)       传输队列：如果用触发方式来启动通道，则传输队列将对应了触发的应用队列。在传输队列的TriggerData属性中设置为将被启动的通道名，这将省略进程的定义。 3)       进程定义(Process Object)：一个应用队列可能由一个进程定义对象和它关联。进程定义中包含应用程序的信息。该应用程序负责从应用队列中取出消息。 4)       触发事件：它是一种引起队列管理器产生触发消息的事件。 5)       触发消息：当触发事件发生时，队列管理器将产生触发消息。触发信息来自于应用队列和于应用队列关联的进程定义，它包含了将要被启动的程序名。 6)       启动队列：一个本地队列。被用来存发触发消息的队列。一个队列管理器可用拥有多个启动队列。一个启动队列可以为多个应用队列服务。 7)       触发监控器：是一个持续运行的程序，当一个触发消息到达启动队列时，触发监控器获取触发消息，并利用触发消息中的信息，启动应用程序来处理应用队列中的消息，并把触发消息头发送传递给应用程序，消息头中包含应用队列名。 在所有平台上，都有一个特殊的触发监控器叫做通道启动器（Channel Initator），它的作用就是启动通道。