Websphere MQ是IBM的商业通讯中间件(Commercial Messaging Middleware)。Websphere MQ提供一个具有工业标准、安全、可靠的消息传输系统。它的功能是控制和管理一个集成的商业应用,使得组成这个商业应用的多个分支程序(模块)之间通过传递消息完成整个工作流程。Websphere MQ基本由一个消息传输系统和一个应用程序接口组成,其资源是消息和队列(Messagingand Queuing)。
消息:消息就是一个信息单元,这个信息单元可以是一个请求(Request message),也可以是一个应答(Reply message),或者是一个报告(Report message)或一份报文(Datagram messge)。一个消息包含两个因素——消息描述(用于定义诸如消息传输目标等)和数据消息(如应用程序数据或数据库查询等)。程序之间的通信通过传递消息而非直接调用程序。
队列:一个安全的存储消息的地方,消息的存储一般是顺序的,队列是消息分阶段地传送和接收。因为消息存放在队列中,所以应用程序可以相互独立的运行,以不同的速度,在不同的时间,在不同的地点。
消息传输系统:用于确保队列之间的消息提供,包括网络中不同系统上的远程队列之间的消息提供。并保证网络故障或关闭后的恢复。
应用程序接口:应用程序和消息系统之间通过Websphere MQ API实现的接口Websphere MQ API在所有Websphere MQ平台上是一致的。API只有14个调用,2个关键动词:发送(PUT)和接收(GET)。
三、WebSphere MQ的重要特点
3.1 统一接口
跨越IBM和非IBM平台。简单的PUT和GET动词在WebSphere MQ支持35种IBM和非IBM平台上完全相同。使得WebSphere MQ提供了这样的特性:目标应用程序位置的透明性(targetapplicationlocationtransparency)。对于一个应用程序的开发者,他需要知道的全部只是队列的名字,这个队列与一个特定的服务有关,而与系统的平台或系统在什么地方无关。
使开发人员避开网络的复杂性。因为WebSphere MQ负责处理所有的通讯,开发人员不必编写任何通讯方面的程序。并且编程和调试非常简单和直接,不需要具体的系统和通讯方面的知识。尤其在开发客户机/服务器模式的应用时,开发人员可以集中精力在与业务有关的客户端和服务器端的应用,而不必考虑操作系统和通讯,特别是底层的网络通讯,节省大约50%到75%of通讯编程工作。
3.2 处理不依赖时间的限制
意思是说在信息创建和发送时,信息的接收方或到接收方的通道不需要激活.不受时间的限制增加了处理的灵活性,允许事务处理在它们想做或有时间做时。彼此通讯程序可以运行在不同的时间。这样程序的运行是独立的,如果逻辑允许,它们不必等待其它程序的应答而继续工作,利用这种异步处理功能,可以更有效的使用资源,更灵活的处理模式,应用处理可以是独立的,并行的,重叠的,从而改进用户服务。
3.3 给分布式处理提供的强健的中间件
包括逻辑工作单元支持(logicalunitofwork),备份和恢复机制,大信息传递和高性能等特点。其中最重要的是确保信息传输,意思是一旦WebSphere MQ接受一个信息传输的任务,会确保信息被传送到目标平台。信息的传输是一次且仅一次.另外,强健的中间件机制保证业务数据一致性,并可在系统发生故障时,及时恢复,业务不会受到影响。
四、MQ的基本概念
4.1 WebSphere MQ对象(objects)
WebSphere MQ对象是一种由WebSphere MQ管理的具有可恢复能力的资源。
队列管理器(Queue managers)
队列(Queues)
名字列表(Namelists)
分发列表(Distribution lists)
进程定义(Process definitions)
通道(Channels)
存储类(Storage classes)
这些对象在异种平台上都是统一的。对于系统管理员来说,操纵对象的命令都是可用的。这些命令格式,对于不同平台是有区别的。当你创建队列管理器时,会自动地创建缺省对象。这些缺省对象可以帮助您来定义所需的对象。
每一个对象都有一个名字,以便通过命令和MQI调用可以引用它。通常在这些对象类型中的每一种对象的名字必须唯一。例如,一个队列和一个进程的名字可以相同,但是不可以有两个相同名字的队列。这意味着一个本地队列名不能和模板队列、远程队列或别名队列相同。但是也会有些特殊情况。另外在互连的队列管理器网络中,队列管理器名必须唯一。
WebSphereMQ的对象名是大小写敏感的,因此在定义对象时,需要仔细选择好大小写字母。在 WebSphere MQ 中,除最多有 20 个字符的通道之外,名称最多可以有 48 个字符。
4.2 消息
消息是对使用它的应用程序有意义的以字节为单位的字符串。消息可以用来实现在相同或不同平台上应用程序间的通信。
WebSphere MQ 消息由两个部分:
应用程序数据。
应用程序数据的内容和结构由使用它的应用程序定义。
消息描述符。
消息描述符标识消息,并包含其它控制信息,如消息类型和消息的优先级,消息描述符的格式由 WebSphere MQ 定义。
WebSphere MQ定义了四种基本类型的消息。应用程序可以定义其他类型的消息。四种基本类型是:
请求消息 Request message
请求消息需要应答。从客户端发往服务器的查询和更新信息往往是一条请求消息。请求消息中应该包含回复消息的路由信息,即回复消息发往什么地方。
回复消息 Reply message
回复消息是对请求消息的回应。请求消息中的信息决定了回应消息的目的地。处理请求和回应的应用程序控制着消息间的关联,这种关联和队列管理器没有关系。消息自身带有足够的信息供应用程序实现这种关联。
报文消息 Datagram message
数据报消息是不需要回复的消息,报文消息只是一次单向的信息传送。
报告消息 Report message。
报告消息用于对一些系统故障的响应。有些报告消息是由应用程序创建的,有些报告消息是由队列管理器创建的。后一种情况是由于远程队列已经满或者远程队列不存在引起消息不能正确发送。最初发送这条消息的应用程序不能检测到这种错误,只有等远程队列管理器创建了这样一条报告消息并发往本地队列管理器之后,应用程序才能作相应的处理。
队列管理器把报告消息也用于其他目的,比如报告一些事件。消息可能有一个失效时间限制。如果一条消息在失效时间过后还没有被某个应用程序处理,该条消息将被队列管理器从系统中清除。当队列管理器清除一条失效消息之后,它将创建一条报告消息,这条报告消息的目的地址由失效消息提供。
报告消息的另一个用途是确保消息的到达。应用程序可以要求它们所发送的消息到达目的地后,他们收到一条报告消息,这叫做接收确认(Confirmation of arrival)。与此相类似,应用程序也可以要求当另外一个程序取走这条消息时它们收到一条报告消息,这被叫做交付确认(Confirmation of delivery)。这两种情况,都是由队列管理器创建报告消息,并把报告消息发送到适当地目的地。
另外还一类特殊的消息叫触发消息。触发消息是由队列管理器创建的一类特殊消息。WebSphere MQ的队列管理器提供了一种当满足某一条件时,自动触发应用程序的机制,而触发消息是触发机制的重要组成部分。
应用程序也可以定义新的消息类型。队列管理器不能解释这些类型,应用程序设置的消息类型由一个范围。这些类型值可用来区分不同类型的应用程序在同一个输入队列中放入的消息。
消息长度
最大消息长度为 100 MB(其中 1 MB 等于 1 048 576 字节),缺省最大消息长度是 4 MB。实际上,消息长度受以下方面的影响:
接收队列定义的最大消息长度
队列管理器定义的最大消息长度
传输队列定义的最大消息长度
发送或接收应用程序定义的最大消息长度
存储消息的可用空间
所以有时可能需要由多个消息组成的信息才能满足应用程序的要求。
4.3 队列
队列是用于存储消息的数据结构,目前WebSphere MQ 版本 5.3 支持超过 2 GB 大小的队列。
4.3.1 队列的类型
按创建方法分类
预定义队列由管理员使用相应的 MQSC 或 PCF 命令创建。 预定义队列是永久的;它们的存在与应用程序是否使用它们无关,并且 WebSphere MQ 重新启动后继续存在。
动态队列在应用程序发出设定模型队列名的MQOPEN调用时创建的。被创建的队列是基于一个模板队列。 您可以使用 MQSC 命令 DEFINE QMODEL 创建模板队列。动态队列继承了模板队列的属性。模板队列有一个属性可以说明动态队列是永久的还是临时的。永久队列在应用程序和队列管理器重新启动后继续存在;临时队列在重新启动后消失。
按功能分类
1. 本地队列(local queue):
一个本地队列是一个物理上位于本地队列管理器中的队列。本地队列实际上存在与本地系统的内存或磁盘存储终。本地队列管理器控制队列的访问。应用程序可以“PUT”消息到本地队列,也可以从本地队列“GET”消息,另外程序还可以查询或修改这些队列的某些属性。对队列属性的修改需要相应的权限。
2. 远程队列(remote queue):
一个远程队列属于一个不与该应用程序直接相连的队列管理器。对这类队列的访问包含有本地队列管理器和远程队列管理器的通信过程。这种通信涉及到通道。 应用程序可对远程队列进行某些操作,比如程序可以向一个远程队列放一条消息,但程序不能从远程队列中去消息。应用程序只能从本地队列读取消息。
应用程序有两种不同的方法可用来访问远程队列。第一种是当程序打开一个远程队列时同时提供队列管理器名和队列名两个参数。这要求程序知道目的队列属于哪个队列管理器。第二种方法是在本地队列管理器上存在一个远程队列的定义,这个定义包含有足够的信息让本地队列管理器确定该远程队列所在的队列管理器。远程队列定义中的目的队列不一定是远程队列管理器的本地队列,它也可以是一个远程队列定义。(这就话和之后的网关队列管理器的创建有关系)
应用程序放一条消息到Q1,Q1是本地队列管理器QM1上的一个远程队列定义:Q2at QM2。QM2是远程队列管理器。Q2是QM2上的一个远程队列定义Q3 at QM3。Q3是QM3的一个本地队列,经过两次传送,消息最终到达Q3这个QM3的本地队列。
有多种原因使这种多跳(Multihop)传送变得有意义。在一个TCP/IP网络内部,所有机器都有IP地址,IP协议本身处理节点间的路由选择。但假设消息需要穿过不同类型的网络,这就需要中间件参加路由选择。在图中,QM2位于一台连接TCP/IP网和SNA网的机器上,只需在QM2上提供一个远程队列定义Q2:Q3 at QM3,就可以实现消息的跨网络传输。
因为对远程队列的访问总是涉及到队列管理器之间的通信,因而我们需要定义其他一些资源,比如通道、传输队列(Transmission queue)。
3. 传输队列(Transmission queue):
传输队列是临时存储目标为远程队列管理器的消息的队列。队列管理器利用传输队列把消息分阶段地发向远程队列。队列管理器和消息移动程序一起负责把数据传送到远程队列。当队列管理器收到把一条消息发往远程队列的要求后,它把