文档介绍：谨以此文献给那些对MQSeries感兴趣的朋友,取名“MQSeries连环画“。1。在早先的时候,人们往往使用两个程序之间直接通信的方式。这种办法最大的问题就是通信协议相关性,也就是说与通信协议相关的代码充斥在应用程序之中,而且可能出现在程序的任何地方,甚至影响程序的设计与结构。这种办法的另一个问题就是应用程序不容易写出可靠强壮的代码。应用程序的通信部分会因为工作方式的灵活性、网络协议的通用性,以及为实现一些实用功能变得非常庞大,往往超过应用程序本身的逻辑代码,变得本末倒置,且代码很难写好,也很难维护。2。人们开始意识到应该把通信代码放到外面,变成独立的工作进程或工作模块,不同的工作进程可以适同于不同的通信协议,而应用程序与通信程序之间使用通用的本地通信方式。这样一来,应用程序与通信程序的代码完全分开,各自的逻辑清晰自然,易于管理与维护,在通信方式上前进了一大步。但是,这种方式对通信程序的编程要求比较高,如果考虑到平台的广泛适用性,通信程序可能要写一大堆,要设计一个通用高效的本地通信接口也非易事,再考虑到通信上的一些附加功能,其实现对普通编程人员是有一定困难的。人们很自然地想到,这种工作最好交由专业的通信软件来完成。在这种情况下,市场逐渐出现了专门负责消息通信的软件,其中IBMMQSeries是其中起步较早,功能出众的一款。经过多年的“大浪淘沙“,目前市场上MQSeries终于成为优势产品,占有率在70%以上,在同类产品中,MicrosoftMSMQ与BEA的TuxedoQ也是不错的产品。MQSeries利用内部的消息排队与调度机制将应用程序之间的通信的“活儿“全包了。目前支持超过23种平台,基本可以实现任何两种异构平台之间的互连。在消息传递的过程中,本地应用发送消息,通过MQSeries界面MQI(MQSeriesInterface)在消息头中会加入消息路由信息,这条消息放入本地传输队列。消息通道协议MCP(MessageChannelProtocol)使用合适的通信协议将消息送达远端。另一方面,消息送达远端后会被远端MQSeries系统识别,并根据路由信息存入相应的远程目标队列中,远端的应用就这样轻而易举地通过MQI操作在家门口读到可能是来自大洋彼岸的消息。消息分成两部分--消息数据头和应用数据体:消息数据头:包含了消息在传送中的必要信息,如目标队列管理器的名字,目标队列的名字,以及消息的一些属性。应用数据体:包含了应用程序有用的信息。队列按其定义可分成本地队列,远程队列定义,别名队列定义。其中只有本地队列是真正意义上的队列,远程队列定义和别名队列定义只是一个队列定义,指向另一个队列实体。本地队列按功能又可分成初始化队列,传输队列,目标队列和死信队列。初始化队列用做消息触发功能。传输队列只是暂存待传的消息,在条件许可的情况下,通过管道将消息传送其它的队列管理器。目标队列是消息的目的地,可以长期存放消息。如果消息不能送达目标队列,也不能再路由出去,则被自动放入死信队列保存。在MQSeries中应用程序可以用消息触发的方式启动。应用程序A将请求消息放入本地队列后,由于本地队列配有触发开关指向某过程对象,该过程对象含有应用程序B的路径。当触发条件满足时,MQSeries会根据过程对象自动产生一条通知消息,放入初始化队列。这条通知消息会被触发***(可以用系统提供的,也可以自己编写)读到,进而启动应用程序B。这时,通知消息已经从初始化队列中取走,而原先的请求消息仍在本地队列中,所以,一般说来,应用程序B的工作模式应该是从本地队列中取出请求消息并作相应的处理。MQSeries支持通用的数据库,如DB2,Oracle,Sybase,RDB和Ingres。通过MQSeries,我们可以做到前台数据库和后台数据库的一致更新。例如:应用更新了本地的Sybase数据库,它同时将更新消息异步地传送到后台,由后台的应用更新后台的DB2数据库。由于任何原因(如线路问题),消息不能送达,MQSeries都会自动重试。如果在设定的超时重试次数内仍未成功,如果这时本地Sybase数据库尚未提交,MQSeries会将本地的数据库操作回滚,以保持前后台的一致。如果本地Sybase数据库已经提交,消息会保留在MQSeries中,它的送达保证机制会自动在线路恢复的第一时间将消息送到后台,从而更新后台的DB2数据库。就这样,MQSeries保证了所有对Sybase的操作也会同样地作用于DB2。由前后端的应用保证各自交易的一致性,由MQSeries保证两端的数据传输。在前端,可以保证发送消息与数据库更新作为一个交易执行,在后端可以保证读取消息与数据库更新也作为一个交易执行。这样,通过分段联保,确保了整个业务的完整一致。所谓“用户出口”实际上指的是嵌入系统中的一段程序