WebSpherMQ教程.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,1,Web Sphere MQ,教程,2,提要,Websphere MQ,介绍,安装和配置,Websphere MQ,Websphere MQ,集群,Websphere MQ,分布式队列管理,Websphere MQ,故障诊断,3,议程,MQ,概念,中间件,MOM,异步通信,消息原理,MQ,对象,演示,Reference,(,备用,),应用案例,4,MQ,简史,1992,SSI(Server Side Includes,服务器端包含,),，开发了消息产品,ezBridge;,IBM,为网络通信定义了,3,个,API,标准：,CPI-C,RPC,MQI,1992-3,IBM,开发消息产品（代码,Victory,）,1993,IBM,从,SSI,那里购买了,ezBridge,的版权,之后,MQSeries version1,产生（主要运行在大型机上）,1994/1995,IBM,发布三个平台的,MQ:,AIX,OS/2,和,AS/400.,到,MQSeries 5.3(WebSphere MQ5.3),已支持超过,35,个平台,Windows,Linux,多个,Unix,2006,年初,WebSphere MQ,6,发布,CPI,C(Common Programming Interface Communication,IBM,公共通信编程接口,),是一个与平台无关的,API,，它与一套公用的,APPC,（高级程序间通信）接口。,简单直接，在支持,CPI-C,的所有平台上都可移植。,CPI-C,旨在为跨,IBM,平台执行应用程序提供一个公用环境。这些平台包括,IBM MVS,（多重虚存系统）、,VS,（虚存系统）、,OS,400,和基于,OS/2,的系统等。,5,RFC(,远程过程调用,):,架构在,CPI-C,接口之上，,RFC,的调用都将转换为,CPI-C,的调用完成,.,6,7,什么是,WebSphere MQ(MQ Series)?,（,1.1,）,是一种中间件产品，它实现了一个消息队列框架,.,中间件,将不同的计算环境连接起来的中间软件,.,Unix,MVS,OS/400,VMS,Windows NT/2k,etc.,SNA,NetBios,TCP/IP,Cobol,C,JAVA,是介于应用与操作系统之间的系统软件，是相关应用的基准平台。,8,MQ,概念,中间件（,1.1.2,）,中间件类型,产品举例,面向消息中间件,(MOM),IBM MQSeries,Microsoft MSMQ,BEA MessageQ,JBossMQ,数据连接,ODBC,JDBC,etc.,远程过程调用,(RPC),DCE,NSF,对象请求代理,(ORB),符合,CORBA,标准的，如,Orbix,Visibroker,BEA Objectbroke,Java IIOP;,还有,Java RMI,交易流程控制,(TPM),Microsoft Transaction Server(MTS),IBM CICS,IBM Encina,BEA Tuxedo,9,三种通信技术的比较（,1.2,）,CPI-C,同步的对话通信模式,RPC,（远程过程调用）,同步的、对话方式的模型,MQI,（,Message Queue Interface,，消息队列接口）,为程序提供了一种异步通信方式，一个程序以一个队列作为中转与另一个程序相互通信,10,MQ,概念,Message Oriented Middleware,（,1.3,）,简单地说，,MOM,就是这样的中间件，它允许一个应用向另一个应用发送消息，而无论该应用是否在线。,平台,A,消息队列,子系统,A,应用,A”,放入“消息,平台,B,消息队列,子系统,B,应用,B”,获取“消息,消息队列,11,MQ,概念,消息和队列,消息,程序之间的通信是通过发送消息数据而不是相互间直接调用,.,队列,消息通过放入队列而存储下来,减少了程序间逻辑性连接的需要,.,消息传输系统,应用程序接口,12,MQ,概念,异步,vs.,同步通信,消息队列框架的通信模式是,异步,的！,同步,:,应用发送请求后一直等待，直到请求被处理。,客户端请求的,同时,，服务必须在线。,异步,:,应用发送请求，然后在将来检查请求是否被处理完成。,客户端请求时，服务无需在线。,13,中间件类型,同步,异步,MOM,X,Data Connectivity,X,RPC,X,ORB,X,TPM,X,14,同步的,good/bad,易编程,输出立即可知,更易恢复错误,(,通常,),更好实时响应,(,通常,),服务必须启动、在线,请求方阻碍占用资源,通常要求面向连接的通信协议,Good,Bad,15,异步的,good/bad,请求无需指定服务器,服务无需在线,由于没有占用,资源可以释放,可以使用非连接协议,响应时间不可预测,错误处理通常复杂,难以设计程序,?,Good,Bad,16,消息的长处,消息的长处：,我们可以集中精力去做应用本身的设计,.,再也不用管有关环境方面的细节了,.,应用变得可以移植、扩展了,.,17,图解消息工作原理,程序通过放置消息到队列来进行通信,.,图中,A,程序 将消息放入,Queue1,B,程序读取,Queue1,的消息,.,Note:,A,和,B,不必位于同一台机器上,!,18,消息工作原理,(2),通信可以是单向或者双向。图中,A,发送到,B,上的,Queue1,然后,B,又 响应到,A,的,Queue2,19,消息工作原理,(3),之,消息队列特性,关于消息队列，有三个关键事实使得它不同于其他通信方式,:,1),要通信的应用程序可以运行在不同时间,.,2),对于应用间的结构没有限制,.,3),对于应用程序来说，底层的环境差异被屏蔽掉,.,让我们一一看去,.,20,消息队列特性,-,应用程序可以运行在不同时间,程序,A,B,不必同时在线,关键,:,消息队列相对于使用它们的应用而言是独立存在的,!,21,消息队列特性,对于应用间的结构没有限制,应用之间可能是一对多,或者是多对一,22,消息队列特性,环境差异被屏蔽掉,不用关心运行在什么,OS,之上,.,不用关心程序由什么语言写的,.,不用关心底层使用什么通信协议,.,23,消息队列特性,-,环境差异被屏蔽掉,应用程序,编程,API,通过消息通道,进行通信,队列管理器,队列管理器,消息队列,24,WebSphere MQ,的原理（,1.3,）,25,MQ,对象,（,2.1,）,队列管理器（,Queue managers,）,队列（,Queues,）,名字列表（,Namelists,）,分发列表（,Distribution lists,）,进程定义（,Process definitions,）,通道（,Channels,）,存储类（,Storage classes,）,26,MQ,对象,:,队列管理器,（,Queue Manager,）,（,2.1.4,）,队列管理器,控制对队列的访问,:,管理,(,创建队列,删除队列,等,),使用,(,放入,读取 消息,),对于所有队列操作可统一进行事务控制,.,通过,MQI,接口访问,如同主机名，队列管理器名字在网内必须唯一,.,27,MQ,对象,:,队列,（,Queues,）,（,2.1.3,）,MQ,定义了四种队列,.,队列是用它的队列管理器和队列名称来完全确定的,.,本地队列,实际队列，会为它分配存储空间,.,包含传输队列。,远程队列,其他队列管理器上的队列的映射定义,(,类似于指针、引用,),别名队列,某一本地或远程队列的别名,.(,用于编程的灵活性,),模型队列,队列模板，可用于创建本地队列,(“create queue xxx“like”queue yyy).,28,MQ,对象,：队列的属性,最大消息长度,最大队列深度,允许,/,禁止 放入消息 或 取出消息,持久,/,非持久,用法：正常,/,传输,Demo,：,MQ,资源管理器,29,MQ,对象,:,消息通道,（,2.1.4,）,定义：,为两个队列管理器（相同或不同平台）提供通信的通路,.,一个消息通道只能在一个方向上传送消息,.,如要双向通信，就得在队列管理器间建立两个消息通道,.,一个通道可以为队列管理器上的任意多个队列服务,30,MQ,对象,:,消息通道（,2,）,通道类型,:,Sender,发起到,Receiver,的连接,Server,接受,requester,的请求,变成,Sender,通道,Receiver,被动,;,等待,Sender,的连接,Requester,启动时活动,变成,Receiver,通道,Cluster-sender(,用于队列管理器集群,),Cluster-receiver(,同上,),31,MQ,对象,:,消息如何在通道传输,(1),应用程序将消息放入传输队列,(2)Sender MCA,取出消息然后发送到,partner MCA,(3)Receiver MCA,将消息放入目标队列,(4),对于应用来说消息可用了,32,MQ,对象,:,有保障传输,若队列是持久的,消息也是持久的,则,MCA,最终一定会将消息传送到目标队列,进而被目标应用获取,!,MCA,是可恢复的（有状态的），而且是面向连接的协议,.,消息不会从传输队列中删除，除非对方,MCA,确认消息到达了目标队列,消息通道代理（,message channel agents,，,MCA,）,33,MQ,对象,:,消息（,2.1.2,）,消息包含有,:,消息头,(MQMD),包含消息的属性（由,QM,和程序处理）,用户数据,程序到程序的数据,(“,负载”,),对于,MQ,来说是透明的,34,MQ,对象,:,消息属性,目标队列,应答队列名,可存在时间,(,失效时间,),格式,相关标识,持久性,“,报告”选项,35,MQ,的体系结构（,2.2,）,WebSphere MQ,和消息排队,WebSphere MQ,使应用程序通过使用,消息排队,来实现消息驱动处理，使用对应的消息排队软件产品实现在不同平台之间进行通信。从而使应用程序屏蔽了底层的通讯结构。,WebSphere MQ,产品提供了消息队列接口（或,MQI,）的公共应用程序编程接口，如果应用程序使用了,MQI,，将非常容易将应用程序从一个平台移植至另一个平台。,36,2.3,客户机和服务器,WebSphere MQ,支持其应用程序的,客户机服务器配置,。,WebSphere MQ,客户端通过,MQI,通道与,WebSphere MQ,服务器进行通讯。,37,2.4,触发机制,2.4.1,触发的概念,2.4.2,触发类型,2.4.3,触发的工作原理,38,队列管理器群集,（,2.5,）,群集的概念,群集的优点,群集的组件,创建群集,群集管理,39,在,Websphere MQ,集群中，成员队列管理器可以创建,本地队列,，并将其在集群中,共享,，集群中的其他成员队列管理器不需要任何额外的配置操作，就可以像访问本地队列一样向该队列放入（,PUT,）消息；,每个成员队列管理器都可以创建与之同名的,共享队列,，于是该共享队列在集群中就拥有了多个,副本,，所有的副本将作为一个虚拟的整体；,对访问者（调用,MQPUT,的应用）而言，它们就是一个队列，应用不需要关心如下细节：,物理上有多少队副本；,队列副本部署的物理列位置；,消息实际发送到哪个队列副本。,所有这些细节问题由集群负责处理，由此实现了集群的负载均衡功能。,为了减少应用程序对于它所运行环境的依赖性，,WebSphere MQ,的应用程序可以和一个它不知道名字的队列管理器相连，这个队列管理器就是一台机器上的,缺省队列管理器,。如果程序在调用,MQCONN,时，把队列管理器名参数设置为空，,MQCONN,将返回与缺省的队列管理器连接的句柄。,40,41,如果要从集群的外部发送消息到集群，并希望消息在集群的成员间合理的分配，那么集群中作为与外部环境接口点的队列管理器上就,不能存在任何共享队列的副本,，否则所有消息将积压在接口点队列管理器上，使集群的负载均衡功能英雄无用武之地。,通常的解决方案是为集群配置至少一个特殊的队列管理器，通常称为,网关（,Gateway,）队列管理器,，该队列管理器上没有任何共享队列的副本，只需配置,与集群外部的通讯设置（通道、监听器等）,和,相关的队列管理器别名（,Queue-manager alias,）,。建立队列管理器别名的方法是建立一个,RNAME,属性为空的远程队列。,42,WebSphere MQ,互连通信,基本概念,实现应用程序通信,通道的维护,配置侦听程序,43,WebSphere MQ,恢复和重新启动,WebSphere MQ,的数据日志,使用数据日志进行恢复,保护,WebSphere MQ,日志文件,备份和恢复,WebSphere MQ,恢复方案,使用,dmpmqlog,命令转储日志,44,WebSphere MQ,问题诊断,错误日志,死信队列,配置文件和问题确定,跟踪,首次故障支持技术（,FFST,）,45,WebSphere MQ,问题诊断,WebSphere MQ,使用许多错误日志来捕捉,WebSphere MQ,自身的操作、任何队列管理器的启动和正在使用的通道的错误信息。,错误日志的位置取决于队列管理器名，以及错误是否与客户机相关。,8.1,错误日志分析,在,WebSphere MQ Windows,版中，假设,WebSphere MQ,已经安装在缺省位置中：,如果队列管理器名称是已知的，则错误日志位于：,c:Prog,ram,FilesIBMWebSphere MQqmgrs,qmname,errors,如果队列管理器不是已知的，则错误日志位于：,c:Program FilesIBMWebSphere MQqmgrsSYSTEMerrors,若错误与系统有关，则错误日志位于：,c:mqmerrors,如果错误发生在客户机应用程序，则错误日志位于客户机的根目录中：,c:Program FilesIBMWebSphere MQ Clienterrors,46,日志文件,在,MQ,产品安装时，在,qmgrs,路径下会建立,SYSTEM,的子目录，在,errors,子目录下会产生三个日志文件：,AMQERR01.LOG,AMQERR02.LOG,AMQERR03.LOG,47,当你建立了队列管理器以后，该队列管理器所需的日志文件随之产生。在,mqmqmgrQMgrNameerrors,子目录下会产生三个日志文件：,AMQERR01.LOG,AMQERR02.LOG,AMQERR03.LOG,每个文件的大小为：,256KB,。,48,当错误信息产生后，被放在,AMQERR01.LOG,中。当,AMQERR01.LOG,大于,256KB,时，,AMQERR01.LOG,中的信息被拷贝到,AMQERR02.LOG,中，新的错误信息又放在,AMQERR01.LOG,文件中，依此类推。,49,最新的错误信息总是存储在,AMQERR01.LOG,中，历史信息存储在,AMQERR02.LOG,和,AMQERR03.LOG,中。应该按照该顺序察看错误信息，并从该文件中获取信息，根据它的提示采取相应的措施：,如果,TCP/IP,出错，需要检查一下网络状态是否正常；,如果发现无法连接对方的队列管理器，需要检查一下对方的,MQ,是否处于运行状态以及对方的通道侦听程序是否启动；,如果错误日志显示,“,通道未在远程定义,”,，可以检查定义的通道的大小写是否正确等。,50,8.2,常见故障分析,在开始详细分析问题的原因之前，应该首要考虑一下可能导致问题的一些较明显的因素，或导致问题发生的最大可能性因素，这样便于把分析问题的范围限制到最小。,有关的,MQ,的异常情况的发生，通常主要与三方面的因素有关，即：,MQSeries,本身,网络,客户的应用,51,8.2.1,初步分析,基本问题罗列：,此之前,MQ,是否运行正常？,从最近一次成功运行以来，是否在某些地方作过改动？,在此之前，应用是否运行成功？,52,如果系统曾经运行正常，那麽在出现问题之前，对哪些部分做了改动？,如：有的用户可能由于网络重新规划而更改了某个主机的,IP,地址，则可能导致通道无法连通；,有的用户新设置了防火墙，则需要进行相应的配置，才能使,MQ,的通道运行正常。,如果没有对系统配置做过更改，可以分析是否运行环境发生了变化？,如：是否由于业务量的加大导致应用程序队列满了，需要加大队列的最大深度；是否由于连接数量的增加，导致无法建立新的连接，这时需要察看在队列管理器配置文件中，与通道相关的,MaxChannels,和,MaxActiveChannels,的配置是否足够大。,53,有无错误信息？,可以察看错误日志，得到错误信息。,是否与,MQI,应用有关，利用返回码能否解释原因？,对于每一个函数调用，,MQ,都会返回一个,Completion Code,和,Reason Code,，通过,MQI,返回码,Reason Code,，可以在,API,一层，确定错误原因，,Reason Code,代表的含义可以参考编程手册，或者从,cmqc.h,头文件中获得。如：,RC2035,，代表没有操作权限；,RC2085,，表示没有该对象；,RC2080,，表示应用程序给出的,buffer,小于消息的实际大小等。,问题能再现吗？,从最近一次成功运行以来，是否在某些地方作过改动？,在此之前，应用是否运行成功？,网络是否连接正常？,问题是否总在每天的某一固定时刻发生？,54,8.2.2,深入分析,8.2.2.1,与队列相关的问题,1),队列状态是否正常？,用,DISPLAY QUEUE,命令查看队列的各项状态,用得到的队列信息进一步查看：,a),如果,CURDEPTH,达到,MAXDEPTH,，表明队列深度已满，新消息已不能再进入队列，要及时处理队列中积存的消息；或者增大队列的,MAXDEPTH,属性。,b),如果,CURDEPTH,还没有达到,MAXDEPTH,，再考虑以下两种情况：,如果队列被设置为可触发类型的，要检查触发条件有没有满足？相关触发进程的定义是否正确？,如果队列不是触发类型的，要检查队列是否为可共享的，是否允许,PUT,或,GET,的操作等。,55,2),消息是否成功地放入队列,?,如果消息没有成功地放入队列，可以检查：,队列是否被正确定义,?,例如，队列的,MaxMsgLength,属性是否足够大以容纳所需大小的消息,?,队列是否被允许放入,?,队列是否已满,?,这可能意味着应用程序无法将要求的消息放入队列。,有没有另一个应用程序取得了独占队列的权力,?,56,3),是否可以从队列取出任何消息,?,如果无法从队列中取出任何消息，检查：,其他应用程序能否从队列中取出消息,?,有没有另一个应用程序取得了独占队列的权力,?,57,如果正在开发应用程序，检查：,是否需要使用一个同步点,?,如果使用同步点控制来放入或检出消息，它们直到工作单元被提交前不能用于其它任务。,是否等待了足够长的时间,?,作为,MQGET,调用的一个选项，可以设置等待间隔。应该确保等待响应足够长的时间。,是否在等待一条由消息或相关标识符（,MsgId,或,CorrelId,）标识的特定消息,?,58,检查在等待的消息的,MsgId,或,CorrelId,是否正确。成功的,MQGET,调用会把这些值设置为检索到的消息的值，所以可能要重设这些值以便成功地取出另一条消息。,对消息是否进行了分段处理，是否在利用,MQGET,读取消息时，采用了正确的选项,(MQGMO),，从而获取消息的整体。,还要检查一下是否能够从队列中取出另一条消息。,期望的消息有没有被定义为持久的,?,如果没有，并且,MQ,重新启动后，消息将已丢失。,59,4,）问题是否与远程队列有关？,如果问题是否与远程队列有关，则要考虑以下几个方面：,远程队列的定义是否正确；,检查通道是否启动，如果通道是可被触发的，要检查触发监视器是否运行正常；,检查往远程队列里发送消息的应用程序是否运行正常；,从错误日志中查找信息；,60,8.2.2.2,与通道相关的问题,通道状态异常时应采取的措施：,1),查看网络连接是否畅通,MQ,的通讯是建立在系统网络运行正常的基础之上的，当通道不通时，要首先检查网络连接是否正常。您可以使用操作系统,ping,命令，也可以采用,ftp,方式，在两个主机之间尝试进行数据传输，以判断网络是否正常。,2),查看通道定义是否正确,通道所使用的传输队列定义是否正确，通道两端的定义是否匹配，如两条通道最大传输的消息长度，,Message sequence number wrap,是否一致。若不一致，要重新定义通道，可使用,MQSC,命令,DEFINE CHANNEL,命令。,61,3),查看通道的状态,用以下命令来判断通道状态：,dis chstatus(ChannelName),或,dis chs(ChannelName),其中，,ChannelName,代表通道的名称，该命令支持通配符，可用,dis chs(*),来查看所有通道的状态，,当通道无法正常启动时，必须重新启动通道，可使用,MQ,的控制命令,runmqchl,命令，或,MQSC,命令,START CHANNEL,来启动通道。,注意：如果通道的接收方状态处于,STOPPED,状态，必须用,start chl(ReceiverChl),来重置它的状态，注意，这并不意味着启动了通道，欲启动通道，必须从发送端来启动。,62,如果通道处于可疑,(in-doubt),状态，则通道启动阶段的互相同步工作无法完成，也会导致通道无法启动。解决方案是：用,Resolve Channel,命令来确定通道状态；,Resolve Channel,命令带有两个参数：,COMMIT,和,BACKOUT,，用,COMMIT,参数将传输队列中的消息删除，用,BACKOUT,参数将传输队列中的消息重新恢复。,63,4),查看操作系统、,MQ,的,TCP/IP,参数是否设置成功以及,runmqchi,进程是否处于运行状态,如果通道在网络出现异常或对方队列管理器重启后，,MQ,通讯不能正常恢复，则要检查操作系统的,keepidle,的,TCP/IP,相关参数是否设置成功并且生效，同时要检查队列管理器的属性,TCP:KeepAlive,是否设置为,Yes,，另外，,runmqchi,进程是否处于运行状态。,注意：上述三者共同作用，才能保证,MQ,通道的正常恢复，缺一不可。,64,5,）查看通道的当前消息序列号,用,dis chstatus(ChannelName),或,dis chs(ChannelName),查看通道的当前一些属性值，在通道的属性值中，,current sequence number,代表通道当前的消息序列号值，若消息序列号不一致，则可用,MQSC,命令,RESET CHANNEL,命令来将消息序列号重新置,1,。,注意：一般情况下，只有当某一方,MQ,系统重新安装，队列管理器重建，或人为操作时，才会使通道的消息序列号变为,1,。,65,6),查看错误日志,关于,MQ,提供的错误日志之前已经作过较为详细的介绍，错误日志是出现异常情况时，系统管理员查找原因时要最先考虑也最为简洁奏效的办法。通道错误日志中的错误信息，往往能很快解决问题。,通常从以上几方面考虑，通道问题都能迎刃而解。,66,8.2.2.3,死信队列,如果由于某种原因，消息不能被正常发送，它会被送到死信队列中。你可以用,MQSC,目录,DISPLAY QUEUE,来查看死信队列的深度，若队列中有消息，可利用应用程序浏览消息的内容，来确定消息被放入死信队列的原因，从而确定如何处理死信中的消息。消息有可能出现在本地的队列中，也有可能出现在目的地的死信队列中。若发生前一种情况，说明本地某有正确的路由途径，可以使消息继续下传；若发生后一种情况，说明目的地一端所指定的目的队列不存在。,67,8.2.2.4,配置文件,对于每一个队列管理器而言，都有一个名为,qm.ini,的配置文件，如果该配置文件被误删除，会导致,“queue manager unavailable”,类型的错误。在,Windows NT/2000,平台上，该配置文件以注册表方式存在，可以使用,MQ,提供的图形界面进行修改。注意：对,qm.ini,和队列管理器属性的修改，必须在队列管理器重新启动之后才能生效。,68,8.2.2.5,数据日志,前面曾经提到,MQ,的数据日志，一般情况下，中国用户大多采用循环日志，我们建议您在估算消息容量之后，确定适当的日志大小和个数。如果，在运行过程中，出现了日志写满的情况，,MQ,也无法正常运行，您可以采取修改,qm.ini,配置文件的方法，加大日志大小和个数。,69,8.2.3,查看系统及应用的运行情况,若从上述两个方面都没有解决问题，最后您就要从系统和应用的角度去进一步分析问题了，比如，您可查看您的系统运行速度是否正常，系统资源是否耗尽等，从而确认是否系统问题影响了,MQ,的正常运行。,70,8.3 Trace,错误跟踪也是一种跟踪故障的手段，在,MQ for Windows NT/2000,环境中，我们可以用,“strmqtrc”,命令来追踪问题的发生原因。,Trace,文件除特殊指定，一般放在,mqmworkerrors,目录下，文件的命名规律是：,AMQppppp.TRC,(,注：,ppppp,是产生,trace,的进程标识符,(PID),。,注意：启动,trace,跟踪，会影响系统的性能，所以在生产环境中要慎重使用。,Trace,文件的内容，用户是无法分析和读懂的，要由,IBM,实验室进行分析。,71,8.4 FFST(First Failure support technology),在,WindowsNT,环境中，,FFST,消息文件位于,c:mqmerrors,目录下。这些错误一般较为严重，一般表现为系统错误或,MQ,内部错误。,FFST,文件的命名规则为：,AMQnnnnn.mm.FDC,nnnnn-,报告错误的进程标识符,(PID),mm-,序列号，一般为,0,72,在,FDC,文件中，对我们有帮助的是它的开始部分，我们可以参考它的,ErrorCode,Probe Type,Probe Description,部分的内容来分析原因。它的主要部分也是需要由,IBM,试验室来分析的，,IBM,借助,MQM Function Stack,和,MQM Trace History,来分析故障原因。,73,74,演示,演示一 将消息发送至本地队列,创建队列管理器,创建本地队列,将测试消息放入本地队列,验证是否已发送测试消息,演示二 将消息发送至远程队列,创建队列管理器,在发送队列管理器上创建队列,创建消息通道,（,Sender,Receiver,）,将测试消息放入队列,验证是否已发送测试消息,75,参考,(Reference),IBM WebSphere MQ home,-,6.0,文档库,-,6.0,帮助系统（英文）,-,developerWorks,（中文）,-,MQ supportPacs,-,-MessageQ-Messaging-www.jboss.org/wiki/Wiki.jsp?page=JBossMQ,ActiveMQ-activemq.apache.org/,更多开源产品（,JMS,实现）,-JMS4Speed,mom4J,UberMQ,MantaRay,OpenJMS,JORAM,77,参考,(Reference),之三,IBM MQ,消息产品家族其它成员,WebSphere MQ Workflow-Message Broker-ESB-WBI,家族的,EAI,产品,-,