IBM MQ介绍

【编者按】关于MQ，我之前只是有个大概概念。譬如以前，就是根据前端送过来的消息，format成后端所须要的消息格式，并将format后的消息放入一个Queue文件中，若是消息发送成功（收到该request成功或者失败的response），该消息将从Queue文件中删除；若是与后端的链路断掉了，该消息会一直重发，直到链路连通，后者重试N次后放弃（N次：配置在文件中，譬如9999）。

如下都是转载内容，包含的主题以下：

初识 IBM MB与MQ ==> good
消息中间件介绍
IBM WebSphere MQ 编程 ==> good
IBM MQSeries的使用指南 ==> good
IBM WebSphere MQ 简介和概述 ==> good

 

 

 

 

初识 IBM MB与MQ

 

转自：http://hi.baidu.com/һҹʮһ��/blog/item/adc02753211c3c2943a75b6c.html

MQ和MB的特性，以及他们的区别与联系

首先从概念上来讲，MQ是消息中间件（号称：一旦发出保证送达），MB是ESB产品。

MQ负责在两个系统之间传递消息，这两个系统能够是异构的，处于不一样硬件、不一样操做系统、用不一样语言编写，只须要简单的调用几个MQ的API，就能够互相通信，你没必要考虑底层系统和网络的复杂性。MQ做为IBM的一个拳头产品，虽然功能看上去很简单，就是个消息队列，但他倒是IBM中间件的核心，也是相比其余厂商（好比BEA）的一个优点。MQ不只有很高的性能，并且对各类平台的支持很是好，几乎你能想到的硬件和操做系统平台以及编程语言，MQ都有专门的API支持。

但MQ的功能仅限于消息队列，至于应用A发给应用B的消息格式是怎样的、能不能被应用B解析，MQ管不了，他只是尽力将消息发到目的地（MQ可以应付多种异常状况，例如网络阻塞、临时中断等等）。此外，若是应用的数目多了，那互相之间都要创建MQ链接，网络拓扑就成了蜘蛛网了（就好像是最初的电话系统）

所以，咱们将网络的星型拓扑引入系统架构中，把一对一的MQ换成一个中心节点，即ESB，MB便是IBM的ESB产品。

MB处于系统的中心，起到一个总线的做用，全部应用都直接链接到MB（通常是经过MB主动调用），而不是应用之间直接互联，这样的好处不言而喻，能够极大的下降应用之间的耦合性。由此引出MB的两大核心功能：消息路由和数据转换。
由于各个应用都插入到MB上，因此应用A只管把消息丢给MB，MB自动根据消息字段、以及业务逻辑，判断要把消息交给谁，这就像路由器同样，根据数据包的头把包路由到相应地址。MB内部的业务逻辑由开发人员设定，固然利用MB的Toolkit，编写业务逻辑也很是简单：拖一些节点，用箭头把它们连起来，就像是画流程图同样，很是形象简单。再用MB的脚本语言（相似sql的脚本）实现逻辑判断，通俗地说就是判断要走哪一个逻辑分支（if...else.....）。

不过各个应用是怎样与MB链接的呢？MB提供了三种方式：MQ、文件和web service（好像不单三种http、tcp/ip）

MQ方式便是利用MQ将MB与应用互联；文件方式则是指定某个目录，MB会自动监视那个文件目录，一旦文件有改变则认为是新的消息到来，MB自动读取指定文件的内容；而web service就不用解释了，直接利用web service进行通信。MB支持这些互联方式也是为了最大化兼容性，特别是对于那些遗留系统或是不支持主流通信方式的系统。

最后说说一个比较偏门的ESB产品：websphere ESB。听过的人可能很少，由于IBM在中国推广的比较少，这个WESB很像是MB的精简版，只支持JMS、WS等少数几种J2EE的通信方式，因此是为J2EE专门准备的。不像MB，支持数十种平台和通信方式，例如FTP，甚至不少你根本没据说过的很古老的通讯协议。这二者的性能相差很多，价格也有三四倍的差距。更要命的是，原先在WESB上开发的东西，是不能迁移到MB使用的，IBM彷佛铁了心要狠狠宰咱们，惟一的方法是再买一个MB，而后用MQ把WESB和MB链接起来，各跑各的。

漏了一个DataPower，这东西我只是略有了解，它的卖点在于硬件支持XML，因此性能比较好，此外还支持一下web service安全方面的东东。所以，WESB是最小功能集，而MB与datapower功能上有必定重叠，如XML，可对数据进行格式转换（貌似还能够提供JAVA接口作更复杂的个性化的格式转换）。

消息中间件介绍

转自：http://hi.baidu.com/��Ű���/blog/item/6519d04febba3b3fafc3abb7.html

消息中间件概述

消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。经过消息队列，应用程序可独立地执行--它们不须要知道彼此的位置、或在继续执行前不须要等待接收程序接收此消息。

在分布式计算环境中，为了集成分布式应用，开发者须要对异构网络环境下的分布式应用提供有效的通讯手段。为了管理须要共享的信息，对应用提供公共的信息交换机制是重要的。

设计分布式应用的方法主要有：远程过程调用(PRC)--分布式计算环境(DCE)的基础标准成分之一；对象事务监控(OTM)--基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合；消息队列(MessageQueue)--构造分布式应用的松耦合方法。

(a) 分布计算环境/远程过程调用 (DCE/RPC)

RPC是DCE的成分，是一个由开放软件基金会(OSF)发布的应用集成的软件标准。RPC模仿一个程序用函数引用来引用另外一程序的传统程序设计方法，此引用是过程调用的形式，一旦被调用，程序的控制则转向被调用程序。

在RPC实现时，被调用过程可在本地或远地的另外一系统中驻留并在执行。当被调用程序完成处理输入数据，结果放在过程调用的返回变量中返回到调用程序。RPC完成后程序控制则当即返回到调用程序。所以RPC模仿子程序的调用/返回结构，它仅提供了Client(调用程序)和Server(被调用过程)间的同步数据交换。

(b) 对象事务监控 (OTM)

基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合，在CORBA规范中定义了：使用面向对象技术和方法的体系结构；公共的Client/Server程序设计接口；多平台间传输和翻译数据的指导方针；开发分布式应用接口的语言(IDL)等，并为构造分布的Client/Server应用提供了普遍及一致的模式。

(c) 消息队列 (Message Queue)

消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中，经过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，好比要求服务、交换信息或异步处理等。

中间件是一种独立的系统软件或服务程序，分布式应用系统借助这种软件在不一样的技术之间共享资源，管理计算资源和网络通信。它在计算机系统中是一个关键软件，它能实现应用的互连和互操做性，能保证系统的安全、可靠、高效的运行。中间件位于用户应用和操做系统及网络软件之间，它为应用提供了公用的通讯手段，而且独立于网络和操做系统。中间件为开发者提供了公用于全部环境的应用程序接口，当应用程序中嵌入其函数调用，它即可利用其运行的特定操做系统和网络环境的功能，为应用执行通讯功能。

若是没有消息中间件完成信息交换，应用开发者为了传输数据，必需要学会如何用网络和操做系统软件的功能，编写相应的应用程序来发送和接收信息，且交换信息没有标准方法，每一个应用必须进行特定的编程从而和多平台、不一样环境下的一个或多个应用通讯。例如，为了实现网络上不一样主机系统间的通讯，将要求具有在网络上如何交换信息的知识（好比用TCP/IP的socket程序设计）；为了实现同一主机内不一样进程之间的通信，将要求具有操做系统的消息队列或命名管道(Pipes)等知识。

目前中间件的种类不少，如交易管理中间件(如IBM的CICS)、面向Java应用的Web应用服务器中间件(如IBM的WebSphere Application Server)等，而消息传输中间件(MOM)是其中的一种。它简化了应用之间数据的传输，屏蔽底层异构操做系统和网络平台，提供一致的通信标准和应用开发，确保分布式计算网络环境下可靠的、跨平台的信息传输和数据交换。它基于消息队列的存储-转发机制，并提供特有的异步传输机制，可以基于消息传输和异步事务处理实现应用整合与数据交换。

IBM 消息中间件MQ以其独特的安全机制、简便快速的编程风格、卓越不凡的稳定性、可扩展性和跨平台性，以及强大的事务处理能力和消息通信能力，成为业界市场占有率最高的消息中间件产品。

MQ具备强大的跨平台性，它支持的平台数多达35种。它支持各类主流Unix操做系统平台,如：HP-UX、AIX、SUN Solaris、Digital UNIX、Open VMX、SUNOS、NCR UNIX；支持各类主机平台，如：OS/390、MVS/ESA、VSE/ESA；一样支持Windows NT服务器。在PC平台上支持Windows9X/Windows NT/Windows 2000和UNIX (UnixWare、Solaris)以及主要的Linux版本(Redhat、TurboLinux等)。此外，MQ还支持其余各类操做系统平台，如：OS/二、AS/400、Sequent DYNIX、SCO OpenServer、SCO UnixWare、Tandem等。

 

IBM WebSphere MQ 编程

转自http://hi.baidu.com/injava/blog/item/7e2fb6ec15cf493c269791b3.html

消息队列（MQ）是一种应用程序对应用程序的通讯方法。应用程序经过写和检索出入列队的针对应用程序的数据（消息）来通讯，而无需专用链接来连接它们。消息传递指的是程序之间经过在消息中发送数据进行通讯，而不是经过直接调用彼此来通讯，直接调用一般是用于诸如远程过程调用的技术。排队指的是应用程序经过队列来通讯。队列的使用除去了接收和发送应用程序同时执行的要求。

IBM WebSphere MQ 产品支持应用程序经过不一样组件如处理器、子系统、操做系统以及通讯协议的网络彼此进行通讯。例如，IBM WebSphere MQ 支持 35 种以上的不一样操做系统。

IBM WebSphere MQ 支持两种不一样的应用程序编程接口：Java 消息服务（JMS）和消息队列接口（MQI）。在 IBM WebSphere MQ 服务器上，JMS 绑定方式被映射到 MQI。如图 3 所示，应用程序直接与其本地队列管理器经过使用 MQI 进行对话，MQI 是一组要求队列管理器提供服务的调用。MQI 的引人之处是它只提供 13 次调用。这意味着对于应用程序编程员它是一种很是易于使用的接口，由于大部分艰苦工做都将透明完成的。

图形 2. IBM WebSphere MQ 编程

 

 

图 2 显示了 IBM WebSphere MQ 编程的原理。第一步是让应用程序与队列管理器链接。它经过 MQConnect 调用来进行此链接。下一步使用 MQOpen 调用为输出打开一个队列。而后应用程序使用 MQPut 调用将其数据放到队列上。要接收数据，应用程序调用 MQOpen 调用打开输入队列。应用程序使用 MQGet 调用从队列上接收数据。

图中还显示了消息通道代理（MCA）、通道出口和对象权限管理器（OAM）。MCA 是 IBM WebSphere MQ 程序，它使用现有传输服务诸如 TCP/IP 与 SNA 将消息从本地传输队列移到目标队列管理器。这些传输服务即通道。通道出口是用户写入库，能够在通道运做期间，从已定义位置号之一进入这些库。OAM 是命令和对象管理的缺省受权服务（针对操做系统）。这三个组件对 IBM WebSphere MQ 的现有安全性解决方案很是重要。

 

 

 

 

 

 

介绍关于IBM MQSeries的使用指南

文章转载自网管之家：http://www.bitscn.com/pdb/java/200605/21739.html

　　随着计算机网络和分布式应用的不断发展，远程消息传递愈来愈成为应用系统中不可缺乏的组成部分。商业消息中间件的出现保证了消息传输的可靠性，高效率和安全性，同时也减小了系统的开发周期。目前应用最多的消息中间件产品为IBM MQSeries。本文就针对MQ的基本操做与配置进行详细的阐述，但愿对读者有所帮助。
　　
　　一．MQ基本操做
　　
　　MQ中有几个很重要的组件：队列管理器（QueueManager）、队列（Queue）和通道（Channel）。其基本的操做方法以下：
　　
　　建立队列管理器
　　crtmqm ?q QMgrName
　　-q是指建立缺省的队列管理器
　　
　　删除队列管理器
　　dltmqm QmgrName
　　
　　启动队列管理器
　　strmqm QmgrName
　　若是是启动默认的队列管理器，能够不带其名字
　　
　　中止队列管理器
　　endmqm QmgrName 受控中止
　　
　　endmqm ?i QmgrName 当即中止
　　
　　endmqm ?p QmgrName 强制中止
　　
　　显示队列管理器
　　dspmq ?m QmgrName
　　
　　运行MQSeries命令
　　runmqsc QmgrName
　　若是是默认队列管理器，能够不带其名字
　　
　　往队列中放消息
　　amqsput QName QmgrName
　　若是队列是默认队列管理器中的队列，能够不带其队列管理器的名字
　　
　　从队列中取出消息
　　amqsget QName QmgrName
　　若是队列是默认队列管理器中的队列，能够不带其队列管理器的名字
　　
　　启动通道
　　runmqchl ?c ChlName ?m QmgrName
　　
　　启动侦听
　　runmqlsr ?t TYPE ?p PORT ?m QMgrName
　　
　　中止侦听
　　endmqlsr -m QmgrName
　　
　　MQSeries命令
　　
　　定义死信队列
　　DEFINE QLOCAL（QNAME） DEFPSIST（YES） REPLACE
　　
　　设定队列管理器的死信队列
　　ALTER QMGR DEADQ（QNAME）
　　
　　定义本地队列
　　DEFINE QL（QNAME） REPLACE
　　
　　定义别名队列
　　DEFINE QALIAS(QALIASNAME) TARGQ(QNAME)
　　
　　远程队列定义
　　DEFINE QREMOTE（QRNAME） +
　　RNAME（AAA） RQMNAME（QMGRNAME） +
　　XMITQ（QTNAME）
　　
　　定义模型队列
　　DEFINE QMODEL（QNAME） DEFTYPE（TEMPDYN）
　　
　　定义本地传输队列
　　DEFINE QLOCAL(QTNAME) USAGE(XMITQ) DEFPSIST(YES) +
　　INITQ（SYSTEM.CHANNEL.INITQ）+
　　PROCESS(PROCESSNAME) REPLACE
　　
　　建立进程定义
　　DEFINE PROCESS（PRONAME） +
　　DESCR（‘STRING’）+
　　APPLTYPE（WINDOWSNT）+
　　APPLICID（’ runmqchl -c SDR_TEST -m QM_ TEST’）
　　其中APPLTYPE的值能够是：CICS、UNIX、WINDOWS、WINDOWSNT等
　　
　　建立发送方通道
　　DEFINE CHANNEL（SDRNAME） CHLTYPE（SDR）+
　　CONNAME（‘100.100.100.215(1418)’） XMITQ（QTNAME） REPLACE
　　其中CHLTYPE能够是：SDR、SVR、RCVR、RQSTR、CLNTCONN、SVRCONN、CLUSSDR和CLUSRCVR。
　　
　　建立接收方通道
　　DEFINE CHANNEL（SDR_ TEST） CHLTYPE（RCVR） REPLACE
　　
　　建立服务器链接通道
　　DEFINE CHANNEL（SVRCONNNAME） CHLTYPE（SVRCONN） REPLACE
　　
　　显示队列的全部属性
　　DISPLAY QUEUE（QNAME） [ALL]
　　
　　显示队列的所选属性
　　DISPLAY QUEUE（QNAME） DESCR GET PUT
　　DISPLAY QUEUE（QNAME）MAXDEPTH CURDEPTH
　　
　　显示队列管理器的全部属性
　　DISPLAY QMGR [ALL]
　　
　　显示进程定义
　　DISPLAY PROCESS（PRONAME）
　　
　　更改属性
　　ALTER QMGR DESCR（‘NEW DESCRIPTION’）
　　ALTER QLOCAL（QNAME） PUT（DISABLED）
　　ALTER QALIAS（QNAME） TARGQ（TARGQNAME）
　　
　　删除队列
　　DELETE QLOCAL（QNAME）
　　DELETE QREMOTE（QRNAME）
　　
　　清除队列中的全部消息
　　CLEAR QLOCAL（QNAME）
　　
　　二．配置一个可以通讯的远程链接
　　
　　以上讲述了MQ的基本命令操做，但只知道这些是没有实际意义的。MQ的最终目的是实现远程通讯，因此下面就以一个具体的例子来讲明如何实现远程链接。这个例子的目的是创建能够实现消息传递的一对MQ服务器，它们分别基于NT和UNIX平台。
　　
　　首先在NT端建一队列管理器
　　crtmqm ?q QM_NT
　　
　　启动队列管理器
　　strmqm QM_NT
　　
　　运行MQ控制台命令
　　runmqsc QM_NT
　　
　　建立死信队列
　　DEFINE QL(NT.DEADQ) DEFPSIST(YES) REPLACE
　　
　　更改队列管理器属性，设置其死信队列
　　ALTER QMGR DEADQ（NT.DEADQ）
　　
　　建立进程定义
　　DEFINE PROCESS（P_NT）+
　　APPLTYPE（WINDOWSNT）+
　　APPLICID（’ runmqchl -c SDR_NT -m QM_NT’）
　　
　　建立本地传输队列
　　DEFINE QL(QT_NT) USAGE(XMITQ) DEFPSIST(YES) +
　　INITQ（SYSTEM.CHANNEL.INITQ）+
　　PROCESS(P_NT) REPLACE
　　
　　建立远程队列定义，对应于UNIX机器上的本地队列Q_UNIX，传输队列为QT_NT
　　DEFINE QREMOTE（QR_NT）+
　　RNAME（Q_UNIX） RQMNAME（QM_UNIX）+
　　XMITQ（QT_NT）
　　
　　建立发送方通道，其传输队列为QT_NT，远程主机地址为10.10.10.2，侦听端口为1414
　　DEFINE CHANNEL（SDR_NT） CHLTYPE（SDR）+
　　CONNAME（‘10.10.10.2(1414)’） XMITQ（QT_NT） REPLACE
　　
　　建立服务器链接通道
　　DEFINE CHANNEL（S_NT） CHLTYPE（SVRCONN） REPLACE
　　
　　在UNIX端建立队列管理器
　　crtmqm ?q QM_UNIX
　　
　　启动队列管理器
　　strmqm QM_UNIX
　　
　　添加侦听程序
　　
　　修改/etc/services文件，加入一行：
　　MQSeries 1414/tcp #MQSeries channel listener
　　
　　修改/etc/inetd.conf文件，加入一行（启动侦听程序）
　　MQSeries stream tcp nowait mqm /usr/lpp/mqm/bin/amqcrsta amqcrsta ?m QM_UNIX
　　
　　运行如下命令，以使修改起做用
　　refresh ?s inetd
　　
　　运行MQ控制台命令
　　runmqsc QM_UNIX
　　
　　建立死信队列
　　DEFINE QL(UNIX.DEADQ) DEFPSIST(YES) REPLACE
　　
　　更改队列管理器属性，设置其死信队列
　　ALTER QMGR DEADQ（UNIX.DEADQ）
　　
　　建立接收方通道，其名字必须与远程发送方相同
　　DEFINE CHANNEL（SDR_NT） CHLTYPE（RCVR） REPLACE
　　
　　建立本地队列
　　DEFINE QL（Q_UNIX） DEFPSIST(YES) REPLACE
　　
　　建立服务器链接通道
　　DEFINE CHANNEL（S_UNIX） CHLTYPE（SVRCONN） REPLACE
　　
　　通过以上操做以后，远程链接的配置工做完成。接下来须要验证配置是否正确。
　　
　　在NT端启动发送方通道
　　runmqchl ?c SDR_NT ?m QM_NT 或 start chl(SDR_NT)
　　
　　从NT端发送消息到UNIX端
　　amqsput QR_NT QM_NT
　　
　　在UNIX端接收消息
　　/usr/mqm/samp/bin/amqsget Q_UNIX QM_UNIX
　　
　　若能收到消息，说明配置成功。
　　
　　另，在NT下通常状况下在创建队列管理器时会自动创建侦听器，启动队列管理器时则会自动启动侦听程序。固然也能够手动配置侦听程序。
　　
　　修改\winnt\system32\drivers\etc\services文件，在文件中加入一行：
　　
　　MQSeries 1414/tcp #MQSeries channel listener
　　
　　启动侦听程序
　　runmqlsr ?t tcp ?p 1414 ?m QM_NT
　　
　　以上说明了怎样创建简单的单向传输网络。消息从NT端传送到UNIX端。创建从UNIX端到NT端的远程链接和以上相仿，要创建双向的传输网络也是一样的道理。
　　
　　三．配置JNDI
　　
　　用JMS实现消息的发送和接收时，常常会用到JNDI。由于JNDI这种方式比较灵活，对于编程也比较简单。
　　在安装了MQSeries Client for Java以后，在\java\bin目录下找到JMSAdmin.config文件。该文件主要用来讲明Context的存储方式及存储地址，对应于文件中的两个参数INITIAL_CONTEXT_FACTORY和PROVIDER_URL。典型的JMSAdmin.config文件内容以下：
　　
　　#INITIAL_CONTEXT_FACTORY=com.sun.jndi.ldap.LdapCtxFactory
　　INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
　　#INITIAL_CONTEXT_FACTORY=com.ibm.ejs.ns.jndi.CNInitialContextFactory
　　#
　　#PROVIDER_URL=ldap://polaris/o=ibm,c=us
　　PROVIDER_URL=file:/d:/temp
　　#PROVIDER_URL=iiop://localhost/
　　#
　　SECURITY_AUTHENTICATION=none
　　
　　INITIAL_CONTEXT_FACTORY表示JMSAdmin Tool使用的服务提供商。当前有三种受支持的值。com.sun.jndi.ldap.LdapCtxFactory用于LDAP，若是使用它就必须安装一个LDAP服务器。com.sun.jndi.fscontext.RefFSContextFactory用于文件系统上下文，它只须要使用者提供存放上下文的文件路径。com.ibm.ejs.ns.jndi.CNInitialContextFactory是专门为websphere提供的，它须要和websphere的CosNaming资源库一块儿使用。
　　PROVIDER_URL表示会话初始上下文的URL，由JMSAdmin tool实现的全部JNDI操做的根。它和INITIAL_CONTEXT_FACTORY一一对应。
　　
　　ldap://hostname/contextname 用于LDAP
　　file:[drive:]/path

转自：http://dev.yesky.com/185/7728685.shtm

IBM WebSphere MQ 简介和概述

　　在开始以前，让咱们先来肯定使用 WebSphere MQ 解决的业务问题的种类，并了解 WebSphere MQ 如何可以帮助您知足业务要求。

　　问题：自动化孤岛

　　在大多数业务中，业务的信息技术 (IT) 基础结构中存在许多不一样的技术。系统由这些来自许多供应商的不一样的技术组成，而且具备不一样的硬件平台、编程语言、操做系统和通讯链路。一般，链接不一样的系统很是复杂而且可能代价高昂，因此许多系统之间都相互隔离。

　　目前，愈来愈多的业务还须要以电子的方式与其客户和供应商进行通讯，而这些客户和供应商可能比该业务自己使用了更多不一样的技术。所以，须要某种简便的、廉价的和可靠的机制用来链接这些异类的系统(“自动化孤岛”)，以便在内部和外部对业务的 IT 基础结构进行集成。

　　解决方案：WebSphere MQ

　　经过提供一种程序到程序的通讯方式，WebSphere MQ 很是适合于上面所描述的环境。图 1 显示了这种通讯方式的基本机制。

　　图 1. 程序到程序的通讯

　　

　　程序 A 准备好一条消息，并将其放入队列。而后，程序 B 从该队列中获取消息，并对其进行处理。这两个程序都使用一种应用程序编程接口 (API) 与该队列进行交互。WebSphere MQ API 称为消息队列接口 (MQI)。任何一个程序都无需了解对方的存在，而且这两个程序无需同时执行。若是程序 A 在程序 B 还没有执行的时候将一条消息放入队列，那么该队列将存储这条消息，直到程序 B 开始执行并准备处理这条消息。相似地，当程序 B 从队列中检索消息时，程序 A 可能已经再也不处于执行状态。

　　应用程序设计

　　使用 WebSphere MQ 提供的基本通讯机制，能够进行同步和异步的应用程序设计。

　　在同步的应用程序设计中，如图 2 所示，假定同时执行这两个应用程序。程序 A 向队列 1 发送一条消息并等待应答。程序 B 检索获得该消息，并对它进行处理，而后将应答消息发送到队列 2 中，以便程序 A 进行检索。在使用 WebSphere MQ 设计应用程序时，一般每一个程序使用不一样的队列向其余程序发送消息。虽然这不是必需的，但这样能够提供更简单的应用程序设计和编程逻辑。另外请记住，这里假定两个程序同时执行。若是当程序 A 发送消息时，程序 B 没有执行，那么程序 A 将阻塞，直到程序 B 启动并对消息进行处理。这是同步应用程序通讯中的设计问题。

　　图 2. 同步应用程序设计

　　

　　在异步应用程序设计中，如图 3 所示，程序 A 再次将消息放到队列 1，以便程序 B 对其进行处理，但如今，程序 C 与程序 A 进行异步地操做，它检索消息并对其进行处理。一般，程序 A 和程序 C 是相同应用程序中的不一样部分。

　　图 3. 异步应用程序设计

　　

　　对于 WebSphere MQ 来讲，异步设计是一种很是合适的模型。程序 A 将消息放到队列中，并继续执行，即便程序 B 并不对这些消息进行处理，也是如此。在这种状况下，队列将存储这些消息，直到程序 B 从新启动。这种模型有一种变种，即程序 A 将一条或多条消息放到队列中，并继续进行其余的处理，而后返回来检索和处理应答消息。

　　程序之间的这种通讯方式称为消息传递。它与其余通讯方式(如对话式的通讯或调用和返回通讯)的不一样之处在于，进行通讯的程序之间具备时间独立性。程序接收消息做为输入，并输出其结果做为消息，而不须要同时运行发送或接收程序。

　　队列管理器和 MQI

　　WebSphere MQ 中的队列由队列管理器所拥有并进行管理。队列管理器还为应用程序提供了MQI API，容许它们访问队列以及其中包含的消息。MQI 在 WebSphere MQ 支持的全部平台中保持一致，并对应用程序隐藏了队列管理器的实现细节。

　　MQI 中有 8 种主要的调用：

　　MQCONN——链接到队列管理器

　　MQCONNX——使用链接选项链接到队列管理器

　　MQDISC——断开与队列管理器的链接

　　MQOPEN——打开队列以便进行访问

　　MQCLOSE——关闭访问的队列

　　MQPUT——将一条消息放入队列

　　MQGET——从队列中获取一条消息

　　MQPUT1——打开队列，放入一条消息，而后关闭该队列

　　MQI 中有 5 种次要的调用：

　　MQBEGIN——开始一个工做单元

　　MQCMIT——提交一个工做单元

　　MQBACK——回滚一个工做单元

　　MQINQ——查询 WebSphere MQ 对象(队列是一种 WebSphere MQ 对象，队列管理器是另外一种对象)的属性

　　MQSET——设置 WebSphere MQ 对象的属性

　　消息

　　WebSphere MQ 中的消息包含两个部分：WebSphere MQ 使用的 Header 和应用程序数据。图 4 显示了一条 WebSphere MQ 消息。

　　图 4. WebSphere MQ 消息

　　

　　应用程序数据能够包含任何字节序列。它是使用 WebSphere MQ 与其余应用程序进行通讯的应用程序所私有的，而且对 WebSphere MQ 没有什么意义。对于应用程序数据的内容没有任何限制，但不一样的平台所容许的消息的最大长度有所不一样。在大多数系统中，最大长度为 100MB，但有些系统的最大长度为 4MB。

　　消息中可能包含各类各样的 Header，但全部的消息都包含一个称为消息描述符 (MQMD) 的 Header。其中包含了关于该消息的控制信息，队列管理器和接收应用程序将使用到这些控制信息。稍后将提供关于 MQMD 和其余 Header 的更详细的信息。

　本地和远程队列

　　队列管理器能够位于相同或不一样的计算机上，它们能够彼此通讯，并在不一样队列管理器的队列之间传递消息。队列管理器为消息提供了可靠的传递。例如，当应用程序将消息放入到队列中时，队列管理器将确保消息的存储是安全的、可恢复的，并向接收应用程序传递一次且仅传递一次，即便必须将消息传递到另外一个队列管理器所拥有的队列，也是如此。

　　当应用程序打开队列时，应用程序所链接的队列管理器将肯定该队列是队列管理器所拥有的本地队列，仍是由另外一个队列管理器所拥有的远程队列。对于本地队列，直接将消息放入到该队列。若是队列是远程的，那么队列管理器将消息放到一个称为传输队列的特殊队列。

　　而后，消息通道代理 (MCA) 从传输队列中获取消息，并将其经过网络发送到接收端的 MCA。接收 MCA 将该消息放到目标队列。在将消息放到目标队列中以后，便将其从传输队列中删除。消息流在队列管理器之间能够是双向的，如图 5 中所示。

　　图 5. 发送消息

　　

　　若是接收MCA 不能将该消息放到目标队列中，那么将根据消息描述符中的选项对其进行处理。可能将其放到死信队列，也可能将其返回给发送者，甚至将其丢弃。

　　经过这种在队列管理器之间传递消息的能力，WebSphere MQ 提供了两种重要的优势：

　　应用程序开发人员不须要了解网络的详细信息。

　　MCA 可使用各类网络和通讯协议与其余的 MCA 相互通讯，而且甚至能够在一段时间以后更改所使用的协议。可是，应用程序开发人员仅须要了解与队列管理器通讯所需的 MQI 调用。

　　仅须要创建更少的通讯链路。

　　许多应用程序使用一个队列管理器，它们能够与使用另外一个队列管理器的应用程序通讯，可是在一对 MCA 之间只须要一条通讯链路。

　　设计可能性

　　如今您已经比较清楚地了解了 WebSphere MQ 的工做方式，即便仅仅是在概略的层次上，下面让咱们来看看在使用 WebSphere MQ 设计系统时，应用程序设计的可能性。

　　并行处理

　　要完成整体的业务事务，应用程序可能须要执行多项任务。例如，旅行社可能须要预约航班、预订酒店房间和预订出租车。使用 WebSphere MQ，能够将请求消息放到为航班预约系统、酒店预订系统和轿车出租应用程序提供服务的 3 个队列中。每一个应用程序均可以与其余两个应用程序并行地执行本身的任务，而后将应答消息放到旅行社应用程序提供的队列中。在收到这 3 个应答以后，旅行社应用程序能够生成综合的旅行路线。这种并行处理的方式能够极大地提升总体性能。

　　客户端/服务器处理

　　另外一种应用程序设计方案是客户端/服务器处理。在这种状况下，一台服务器仅使用一个队列接收来自多个客户端应用程序的消息。每一个请求消息的消息描述符能够指定一个应答队列。在服务器完成对消息的处理以后，它将应答消息发送到消息描述符中指定的应答队列，这样可使得每一个客户端应用程序相对于其余客户端应用程序独立地接收到其应答消息。

　　消息描述符中还有一个包含消息标识符的字段。应答消息的消息描述符能够包含对应的请求消息的标识符。这样作使得客户端应用程序能够在应答消息和之前发送的请求消息之间进行关联。

　　要使用客户端/服务器处理来提升应用程序的性能和可靠性，可使用多个服务器应用程序实例为同一个请求队列服务。

　　触发

　　WebSphere MQ 能够在消息放入到队列中以及某些条件知足时，启动一个应用程序。这称为触发。下面是触发的工做方式：

　　程序将消息放入到支持触发的队列中。

　　若是触发的条件知足，则发生触发事件。

　　队列管理器检查应用程序队列所引用的进程对象。该进程对象指定了须要启动的应用程序。

　　队列管理器建立包含关于进程对象和队列的信息的触发消息。

　　将该触发消息放到启动队列。

　　由一个称为触发监视器的程序负责检索消息，并启动合适的应用程序，将触发消息的信息传递给这个应用程序。

　　当第一次将消息放到队列中时、当队列中包含的消息达到某个数目时、或者每次将消息放到队列中时，均可能发生触发事件，尽管最后这种状况一般不推荐使用。

　　数据完整性

　　有些应用程序使用会话式的程序到程序的通讯方式，以使用两段式提交协议来支持分布式工做单元的实现，如图 6 中所示。

　　图 6. 同步分布式工做单元

　　

　　这种功能仅在下面的状况下须要使用，业务要求在任什么时候刻都必须很是精确地维护两个分布式数据库之间的一致性。在实际中，这种类型的需求不多出现。当这种需求的确存在时，单个分布工做单元可能使用许多资源，而且变得很是复杂，尤为是当涉及到许多处理时。

　　WebSphere MQ 提供了一种更简单的解决方案，使得多个工做单元能够异步执行，如图 7 中所示。

　　图 7. 异步分布式工做单元

　　

　　第一个应用程序写入数据库，将包含对其余系统中的第二个数据库进行更新所需数据的消息放到队列中，而后提交对这两种资源的更改。由于该队列是远程的，因此消息仅进入第一个工做单元的传输队列。

　　第二个工做单元包含发送 MCA 从传输队列中获取该消息，并将其发送给接收MCA，然后者负责将该消息放到目标队列。

　　在第三个工做单元中，第二个应用程序从目标队列中获取该消息，并使用该消息中包含的数据对数据库进行更新。

　　工做单元 1 和 3 的事务完整性，加上工做单元 2 中由 WebSphere MQ 提供的消息的一次且仅一次的可靠传递，从而确保了整个业务事务的完整性。

　　安全性

　　WebSphere MQ 中的安全特性包括：

　　队列管理器可检查某个用户是否通过受权能够提交管理队列管理器的命令。

　　队列管理器可检查某个用户或应用程序是否通过受权能够在指定的操做中访问 WebSphere MQ 资源，如队列。

　　在容许 MCA 之间进行消息通讯以前，MCA 能够对合做伙伴 MCA 进行身份验证。

　　能够在 MCA 发送消息以前对其进行加密，而后在接收到该消息以后再对其进行解密。

　　消息描述符能够包含用户 ID 和关于消息发出者的其余信息。这种信息称为消息上下文，它能够用来对消息进行身份验证，并检查该消息的发送者是否通过受权能够访问接收系统中的 WebSphere MQ 资源。

　　WebSphere MQ 客户端

　　WebSphere MQ 客户端能够安装在没有运行队列管理器的系统中。客户端能够将在同一系统中运行的应用程序做为WebSphere MQ 客户端，以链接到运行于另外一个系统中的队列管理器，并向该队列管理器发出MQI 调用。这种应用程序称为 WebSphere MQ 客户端应用程序，而这种队列管理器称为服务器队列管理器。图 8 显示了这种配置。

　　图 8. 客户端和服务器之间的连接

　　

　　WebSphere MQ 客户端应用程序和服务器队列管理器使用MQI 通道实现彼此之间的通讯。当客户端应用程序发出 MQCONN 或 MQCONNX 调用时启动 MQI 通道，当客户端应用程序发出 MQDISC 调用时结束该通道。

　　要使 WebSphere MQ 客户端进行有效地处理，须要快速的和可靠的同步通讯链接。

　　WebSphere MQ Framework

　　用户和软件供应商可使用已定义的接口来扩展或替换队列管理器功能。WebSphere MQ Framework 提供了这样的接口。

　　WebSphere 容许对各类功能进行修改，以便：

　　提供选择是否使用 WebSphere MQ 所提供的组件、或对其进行替换、或使用其余的组件对其进行扩充的灵活性。

　　容许独立的软件供应商经过提供其余新技术所使用的组件，从而参与其中，无需对 WebSphere MQ 内部的内容进行更改。

　　容许 WebSphere MQ 更快地利用各类新技术，从而更迅速地提供相关产品。

　　WebSphere MQ Framework 中的组件包括：

　　触发监视器接口 (TMI)

　　消息通道接口 (MCI)

　　名称服务接口 (NSI)

　　安全支持接口 (SEI)

　　数据转换接口 (DCI)