IBM WebSphere MQ消息通道的配置和维护(四)

在所有平台上,都有一个特殊的触发监控器叫做通道启动器(Channel Initator),它的作用就是启动通道。

2.2.2   触发类型

l  EVERY:

应用队列中每接受到一个消息时,都将产生触发消息。如果应用程序仅仅处理一个消息就结束,可采用这种触发类型。

l  FIRST:

应用队列中消息从0变为1时会触发事件。如果当队列中的一个消息到达时启动程序,直到处理完所有消息才结束,则采用这种触发类型。

l  DEPTH:

应用队列中消息数目和TriggerDepth(引起触发事件发生时,队列中的消息数目)属性值相同时,才会产生触发事件。当一系列请求的回复都收到时,才启动应用程序,则可以采用这种方法。

需要注意的时,当DEPTH属性值为0的时候,实际上就形成了同步通信。另外,当采用Depth触发时,产生触发消息以后,队列将被修改为非触发方式,如果需要再次触发,需要重新设置成允许触发。

一般而言,在实际应用中,如果通道设置成触发方式,触发类型往往设置成为FIRST和DEPTH。

2.2.3   触发器工作流程

1)        本地或远程应用程序A,往应用队列(Application Queue)中PUT了一条消息。

2)        如果队列的触发类型设置为first,当队列原来深度为0时(队列为空),这时PUT一条消息到队列中将形成触发事件,同时产生一条触发消息,触发消息中将包含进程定义中的信息,因为进程定义中包含启动程序B所需的信息,所以触发消息中也包含了启动程序B所需的信息。

3)        队列管理器创建触发消息,并把它PUT入与应用队列相关的启动队列Initiation Queue。

4)        触发监控器(Trigger Monitor)从启动队列(Initiation Queue)中GET触发消息。

5)        触发监控器处理触发消息,发出启动应用程序B的命令。

6)        应用程序B打开应用队列(Application Queue),并处理队列中的消息。

 

注:如果是通道触发将可以不需要创建进程对象(process object),只是在传输队列的trigdata中设置需要启动的通道名。

 

2.2.4   配置消息通道触发

配置消息通道触发启动,需要使用到的对象有传输队列,通道启动队列,发送通道,通道启动器。我们本配置案例中传输队列名是QMB,通道启动队列采用SYSTEM.CHANNEL.INITQ,发送通道名QMA.QMB,通道启动器为runmqchi,该进程在队列管理器启动的时候自动启动。下面我们通过举例来演示配置实现消息通道触发启动。

l  首先我们来查看一下传输队列QMB都有哪些属性,显示如下清单所示,其中清单中的标注红色的属性和通道触发配置相关。

dis ql(QMB)

1 : dis ql(QMB)

AMQ8409: 显示队列细节。

QUEUE(QMB)                           TYPE(QLOCAL)

ACCTQ(QMGR)                          ALTDATE(2009-02-06)

ALTTIME(11.41.44)                       BOQNAME( )

BOTHRESH(0)                           CLUSNL( )

CLUSTER( )                             CLWLPRTY(0)

CLWLRANK(0)                             CLWLUSEQ(QMGR)

CRDATE(2008-12-05)                      CRTIME(10.37.53)

CURDEPTH(0)                             DEFBIND(OPEN)

DEFPRTY(0)                              DEFPSIST(NO)

DEFSOPT(SHARED)                         DEFTYPE(PREDEFINED)

DESCR( )                                DISTL(YES)

GET(ENABLED)                            HARDENBO

INITQ( )                                IPPROCS(1)

MAXDEPTH(5000)                          MAXMSGL(4194304)

MONQ(QMGR)                              MSGDLVSQ(PRIORITY)

TRIGGER                                 NPMCLASS(NORMAL)

OPPROCS(1)                              PROCESS( )

PUT(ENABLED)                            QDEPTHHI(80)

QDEPTHLO(20)                            QDPHIEV(DISABLED)

QDPLOEV(DISABLED)                       QDPMAXEV(ENABLED)

QSVCIEV(NONE)                           QSVCINT(999999999)

RETINTVL(999999999)                     SCOPE(QMGR)

SHARE                                   STATQ(QMGR)

TRIGDATA( )                             TRIGDPTH(1)

TRIGMPRI(0)                             TRIGTYPE(FIRST)

USAGE(XMITQ)

阅读更多

IBM WebSphere MQ消息通道的配置和维护(三)

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)        触发监控器:是一个持续运行的程序,当一个触发消息到达启动队列时,触发监控器获取触发消息,并利用触发消息中的信息,启动应用程序来处理应用队列中的消息,并把触发消息头发送传递给应用程序,消息头中包含应用队列名。

IBM WebSphere MQ消息通道的配置和维护(二)

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发起连接后接收数据。