关于IBM MQSeries和FMQ的资料

关于IBM MQSeries和FMQ的资料

• IBM MQSeries使用指南...
• FMQ数据交换平台...
• “FMQ”  VS “IBM MQ ”.
• MQ--IBM MQSeries使用指南...

 

关于IBM MQSeries和FMQ的资料

 

1. IBM MQSeries使用指南...
2. FMQ数据交换平台...
3. “FMQ”  VS “IBM MQ ”.
4. MQ--IBM MQSeries使用指南...

 

IBM MQSeries使用指南 
(来源：http://www.ccw.com.cn)  

随着计算机网络和分布式应用的不断发展，远程消息传递越来越成为应用系统中不可缺少的组成部分。商业消息中间件的出现保证了消息传输的可靠性，高效率和安全性，同时也减少了系统的开发周期。目前应用最多的消息中间件产品为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下一般情况下在建立队列管理器时会自动建立侦听器，启动队列管理器时则会自动启动侦听程序。当然也可以手动配置侦听程序。 
修改winntsystem32driversetcservices文件，在文件中加入一行： 
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之后，在javabin目录下找到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:]/pathname 用于文件系统上下文 
iiop://hostname[ort]/[?TargetContext=ctx] 用于访问websphere CosNaming名称空间 
 
最后还有一个参数SECURITY_AUTHENTICATION，用于说明JNDI是否把安全性凭证传递给了您使用的服务供应商。只有当使用了LDAP服务供应商时，才使用此参数。此参数有三个值，none（匿名认证）、simple（简单认证）和CRAM-MD5认证机制。如果没有提供有效值，缺省值为none。 
 
确认配置文件之后，可以在javabin目录下启动JMSAdmin控制台。也可以在任何目录下用下面的命令来启动控制台： 
JMSAdmin –cfg MQ_JAVA_INSTALL_PATHjavabinJMSAdmin.config 
其中MQ_JAVA_INSTALL_PATH为MQSeries Client for Java安装的根目录。 
若启动失败，则好好检查一下您的环境变量是否设置正确。根据我个人的经验，除了把com.ibm.mq.jar和com.ibm.mqjms.jar加入到环境变量外，还要把fscontext.jar和providerutil.jar加入到环境变量。 
进入JMSAdmin控制台后，您可以自由定义sub context。对于子上下文的操作，主要有一下命令： 
display ctx 
define ctx(ctxname) 
change ctx(ctxname) 
change ctx(=up) 
change ctx(=init) 
delete ctx(ctxname) 
 
当然，在这里的主要任务并非是用来定义sub context，而是用来定义以下几个对象： 
MQQueueConnectionFactory 
MQTopicConnectionFactory 
MQQueue 
MQTopic 
（还有其它的一些对象，如MQXAQueueConnectionFactory等，不常用到，在此不作说明。） 
可以使用很多动词来操纵目录名称空间中的受管理对象。ALTER、DEFINE、DISPLAY、DELETE、COPY和MOVE，它们的用法都算比较简单，这里只列举一二以作说明。 
例一：定义一QueueConnectionFactory，连接主机10.10.10.18，端口1414 
DEFINE QCF(EXAMPLEQCF)+ 
DESC(Example Queue Connection Factory)+ 
TRAN(CLIENT)+ 
HOST(10.10.10.18)+ 
QMGR(QM_EXAMPLE)+ 
CHAN(S_EXAMPLE)+ 
PORT(1414)+ 
CCSID(1381) 
 
例二：定义一Queue，其对应于MQ中的Q_EXAMPLE 
DEFINE Q(EXAMPLEQL)+ 
DESC(Local queue)+ 
QMGR(QM_EXAMPLE)+ 
QUEUE(Q_EXAMPLE)+ 
CCSID(1381) 
 
四．用JMS实现MQ编程 
上面我们说明了怎样用JMSAdmin Tool定义MQ对象的上下文。我们的最终目的是要用JMS来实现MQ编程，以实现在程序中对MQ队列进行收、发消息。所以，下面我们将重点讨论一下MQ的JMS实现。 
如果您对JMS编程很熟悉，那么您也就会用JMS来实现MQ编程，因为用JMS来编写MQ程序与编写一般的JMS程序没有太大的差别。举个例子，当我们想发送一条消息到MQ的队列中，再从该队列中取回消息时，我们编程时主要有四个步骤。首先我们要初始化在程序中要用到的对象，然后才可以发送消息到队列中去，再就是收取消息了，最后要清除那些永久对象。这些都和普通的JMS程序相当。程序的源代码如下： 
 
import java.util.Hashtable; 
import javax.jms.*; 
import javax.naming.*; 
import javax.naming.directory.*; 
 
public class sample { 
protected QueueConnectionFactory factory=null; 
protected QueueConnection connection; 
protected QueueSession queueSession; 
protected TextMessage outMessage; 
protected QueueSender queueSender; 
protected QueueReceiver queueReceiver; 
 
public static final String qcfLookup="EXAMPLEQCF"; 
public static final String qLookup="EXAMPLEQL"; 
public static final String icf = "com.sun.jndi.fscontext.RefFSContextFactory"; 
public String url ="file:/d:/temp"; 
 
public void sampleInit() throws Exception { 
Hashtable environment = new Hashtable(); 
environment.put(Context.INITIAL_CONTEXT_FACTORY, icf); 
environment.put(Context.PROVIDER_URL, url); 
environment.put(Context.REFERRAL, "throw"; 
Context ctx=new InitialDirContext(environment); 
factory = (QueueConnectionFactory)ctx.lookup(qcfLookup); 
Queue q1=null; 
q1=(Queue)ctx.lookup(qLookup); 
connection = factory.createQueueConnection(); 
queueSession = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); 
 
queueSender = queueSession.createSender(q1); 
queueSender.setDeliveryMode(DeliveryMode.NON_PERSISTENT); 
outMessage = queueSession.createTextMessage(); 
queueReceiver = queueSession.createReceiver(q1); 
connection.start(); 
} 
public void sendMessageOut(String message) throws JMSException { 
outMessage.setText(message); 
queueSender.send(outMessage); 
} 
public String receiveMessage() throws Exception{ 
return ((TextMessage)queueReceiver.receive()).getText(); 
} 
public void sampleClose() throws JMSException { 
queueSession.close(); 
connection.close(); 
} 
 
public static void main(String[] args){ 
String rec; 
sample sp = new sample(); 
try { 
sp.sampleInit(); 
sp.sendMessageOut("Hello World!"; 
java.lang.Thread.sleep(4000); 
rec=sp.receiveMessage(); 
System.out.println("Receive text is : "+rec); 
sp.sampleClose(); 
}catch(Exception e) { 
e.printStackTrace(); 
} 
} 
} 
 
五．远程管理 
MQ在WINDOWS平台下具有图形化管理界面，但在UNIX平台下却只能通过命令行来进行操作。这样就给使用者带来很大的不便。我们都希望能通过图形界面来进行管理配置。为了实现我们的想法，我们就必须建立远程管理。 
实现远程管理有以下几个步骤： 
1．被管理队列管理器上的命令队列SYSTEM.ADMIN.COMMAND.QUEUE存在并可用。对于MQ 2版本应执行 amqscoma.tst 脚本来创建。 
2．使用strmqcsv命令来启动被管理队列管理器上的命令服务器。 
3．确定被管理队列管理器上的服务器连接通道SYSTEM.ADMIN.SVRCONN是否存在，如果不存在则创建它。 
4．一般Unix、Linux平台中MQ默认的字符集为819，而Windows平台为1381，所以你必须改变其字符集，使两边的字符集相同。一般改被管理的字符集。 
5．如果被管理队列管理器上的操作用户与管理队列管理器上的操作用户不同，那么你首先要确认管理队列管理器上的操作用户在被管理队列管理器上存在并且有管理MQ的权限，再者，你需要修改服务器连接通道SYSTEM.ADMIN.SVRCONN的MCAUSER属性为管理队列管理器上的操作用户。 
6．启动被管理队列管理器上的侦听器。 
 
做完这些工作之后，直接在管理队列管理器的MQ管理工具中显示被管理队列管理器即可。然后你就可以象操作本地队列管理器一样，在被管理队列管理器上定义你需要的MQ对象。 
 
六．通道维护 
在配置远程连接的时候，我们曾经创建过进程定义。那我们为什么要去创建进程定义呢？这就涉及MQ通道维护的概念。 
通道长时间没有消息触发就会自动断开连接，不再保持运行状态。时间的长短可以由自己设定，默认值为6000秒。消息请求再次来临的时候，就必须再次启动通道。有些通道，如服务器连接通道、接收方通道等是自动触发启动的。当消息请求发送到通道后，通道立即启动，进入运行状态。但也有一些通道不会自动启动，最典型的就是发送方通道。当有消息请求需要使用通道进行消息传递的时候，发送方通道也不会自动启动并把消息发送到远程队列，而是把消息留在了与其相关联的传输队列中。 
但是，在实际应用中我们又不可能每过一段时间去启动一次通道，或当有消息来再去启动通道。那应该怎么办？首先我们创建一个进程定义，这个进程定义的目的就是用来启动发送方通道。然后我们在传输队列的进程名称属性栏指定刚才定义的进程定义名称，再把触发器控制开关打开。这样，当有消息进入传输队列后，传输队列的触发器会启动触发执行指定的进程，从而启动发送方通道，把消息传输到远程队列中去。 
 
七．总结 
也许你会说你已经理解了MQ，包括基本概念、配置、管理以及程序的编写，那么恭喜你。我也希望如此。不过MQ也许并非如此简单，因本人水平有限，也只能到此为止，希望大家再接再厉。顺便说一句，如果有什么好想法，千万别忘了告诉我一声。 

FMQ数据交换平台

是一款构架在FMQ(文件&消息队列)基础上的、易使用、易管理、高效率的中心控制分布式应用整合平台，可以管理、规范、监控整个网络的传输。它在网络传输层与用户应用层之间建立强大的数据交换管理层，屏蔽不同网络系统之间的差异，为各计算机之间、各应用系统之间提供可靠的消息、文件传输。FMQ数据管理平台由后台服务、管理配置工具以及平台API接口组成，主要提供文件、消息传输、 管理规范网络传输、整合应用系统等功能。FMQ数据交换平台的主要特点：

易使用：

• 平台安装简单：免配置，无需预先建立各种通道、队列等对象。
• 增、删、改节点简单：无需全网广播。
• 使用简单：提供各种方式接口，无需编程亦可使用。
• 维护简单：提供图形化和命令行方式的管理工具。
• 传输简单：屏蔽系统、网络差异，路由自动分析。
• 使用灵活：既支持多个节点集群成一个节点增大吞吐量，也支持一个节点模拟多个节点减少设备投入。
• 系统要求低：占用资源小，无需高昂的设备投入。
• 对传输内容无特殊要求：上G的大文件或是大量小文件平台都能处理自如。

易管理

• 支持远程管理：通过远程管理工具直接对远程节点进行维护管理。
• 提供日志功能：通过对日志的分析查看数据的来龙去脉。
• 提供统计功能：通过统计传输情况可以分析出交换节点的使用情况，为进一步决策提供依据。
• 提供分析报告功能：对平台运行情况进行智能分析并给予报告，无需详细查看系统状态，一目了然。

高效率

• 虚拟链路系统：数据交换节点与管理中心之间建立特有的虚拟链路进行消息传递。
• 采用增补链技术：通过该技术实现的排队算法无需任何循环便能够高效率的检索数据。
• 智能流技术：采用类滑动窗口技术对数据进行智能拆包与装包，采用异步Socket技术进行并行发送。
• 平台在传输中采用断电保护、断点续传、Send-Request等技术手段保证数据安全可靠的传输。
• 采用线程池、连接池技术避免频繁的启动线程或者建立连接。
• 采用动态捆绑技术，对消息、索引的操作无需锁定，增快处理速度。

??FMQ数据交换平台与操作系统无关支持多种平台： Linux系列、IBM AIX、Windows系列、HP Unix、SUNsolaris、UnixWare等。
??FMQ数据交换平台采用TCP/IP协议支持多种网络链路形式：局域网、广域网、DDN、X.25、帧中继、卫星网络等。
??FMQ数据交换平台提供多种API接口：FMQ APIFor C 、FMQ API For C++、FMQ API For Java、FMQ OCX API等。
??FMQ数据交换平台支持松耦合方式接口：与数据应用整合平台结合使用，提供目录接口、消息触发、手工发送等方式，无需编程亦可使用数据交换管理平台。
??FMQ数据交换平台提供图形方式与命令行方式的管理工具: 支持远程管理、无需登录到后台服务器亦可完成管理监控工作，既适合单点管理也适合中央集中监控管理。

解决方案：

1.1. 在内部网构建公共数据交换体系

 

随着信息化建设的发展，政府以及各职能部门都建立了各自的内部网络环境，应用处理系统在内部网络环境中进行各自的数据消息传递，每个需要进行数据消息传递的应用系统都要开发自己的网络传输模块，由于网络状况的不同、操作系统的不同使得网络传输方面开发难度比较大、复杂度比较高，想要传输稳定可靠则需要投入大量的人力物力，而应用系统的工作大部分围绕着业务处理这一块，使得一些应用系统在数据传输方面采用如共享目录、FTP等方式，而这些方式在使用的方便性、安全性、管理性等方面都存在着严重的不足，建立统一的、规范的、易用的公共数据交换体系成为了一种需要。

采用FMQ数据交换管理平台可以很好的满足这种需要，FMQ数据交换管理平台也是为了这种需要而诞生的。请参考4.2节的FMQ中央控制分布式结构图，这个图也是公共数据交换体系的一个部署图，采用FMQ数据交换管理平台只需三个步骤，便可以简单、便捷、灵活的构建出公共数据交换体系。

第一步：按照行政等级或者政府职能等方式，规划整个公共数据交换体系的网络层次。

第二步：按照规划的网络层次建立数据交换管理中心。

第三步：在需要传输的节点安装FMQ数据交换管理平台（或FMQ交换客户端)，并将其注册到对应的管理中心。

建立了公共数据交换体系以后，应用系统只需使用FMQ数据交换管理平台提供的各种紧耦合、松耦合方式接口进行数据消息发送、接收即可。这样既保证传输的稳定可靠，又节约了成本，可以说是事半功倍。

 

1.2. 数据采集上报系统示例

 

目前有很多的应用系统是按照行政等级以树状结构部署的，末级节点面向终端用户，且拥有自己的数据存储（如财务数据、业务数据等）。在业务需求上往往其上级节点也会需要末级节点产生的各种数据信息，如何随需应变的采集所需要的数据是一个急待解决的难题。

将FMQ数据交换管理平台安装到数据采集点，与上级节点一起架构一个虚拟网络，利用FMQ在队列管理器配置灵活的特性，可以应付各种因集中办公、联合执勤等带来的复杂的节点架构。

需要数据采集的节点根据业务需求生成数据采集命令，并交给数据交换管理平台；交换管理平台将命令广播到每个数据采集点；数据采集点上根据业务解析命令，并通过数据交换管理平台将生成数据上报给发出命令的节点，这样就完成了一次数据采集任务。

 

       数据采集流程图：

 

 

综述：采用了FMQ数据交换管理平台，应用系统只需要关心采集命令如何定义，以及采集命令如何解析即可，大大降低了开发的复杂度，节约了成本。

1.3. 基于FMQ的公文流转示例

 

公文（或者数据）在处理的过程中可能需要经过多个步骤，采用FMQ数据交换管理平台对流转的公文进行流转和暂存，是一个非常有效、且易用的解决方案。

FMQ交换管理平台可以保障公文稳定、可靠的传输，利用其提供的队列对公文数据进行存储，通过数据类型标识公文目前处理的状态，将整个流程划分为若干阶段，每阶段的应用程序只需关心它所处理的业务即可，程序的入口是交换管理平台，程序的出口也是交换管理平台，无论下一流程的处理程序是在本机还是在跨地域的其他机器上，应用程序都不需关心，只要把公文交给数据交换管理平台即可，这样可以大大减轻应用程序设计的复杂度以及开发的工作量。

 

1.4. 数据异地备份示例

 

FMQ数据交换管理平台的出现改变了应用程序之间信息交换的方式，如果没有公共数据交换管理平台，应用程序之间需要进行直接的信息交换，如果使用数据交换管理平台，每个应用程序只需和数据交换管理平台进行信息交换。

在数据源端，可以利用应用程序自动产生需要备份的数据，也可以用手工导出的方式产生需要备份的数据，采用哪种方式对于备份数据的接收端是没有影响的。通过交换管理平台提供的接口将需要备份的数据交给交换管理平台，交换管理平台会自动将数据安全、稳定、可靠的传输到接收端。如果在传输的过程种发生断线等状况，交换管理平台会使用断点续传的功能从断点处继续传输，而不用重头再传。当数据完整的到达接收端后，平台会将其交给导入备份的应用程序处理。

数据异地备份流程图：

 

1.5. 数据路由应用示例

 

某业务部门管辖着一个大型应用系统，这个应用系统架构是全国范围内跨区域分布式的，每个业务节点有着自己的数据库、表。在实际应用中，根据业务需要一部分节点的数据需要发送给其他的业务节点，这就需要一种手段可以灵活的定义源业务节点与目的地节点以及发送的内容，并解决数据传输的问题，还可以根据业务变化灵活的调整，尤其要解决跨地域、跨部门的数据传递，。

FMQ数据路由平台是架构在FMQ数据交换管理平台基础之上的软件平台产品，应用该产品可以有效的解决上述难题。

使用FMQ数据路由产品，按照业务需要自由定义数据路由信息，当数据产生后进入FMQ数据路由平台，路由平台按照路由规则进行路由解析，并将解析后的数据通过数据交换管理平台交给目的地端的应用程序进行处理。

 

1.6. 数据库增量同步示例

 

随着信息技术的发展，软、硬件存储能力显著提高，数据集中、信息中心成为了一种大的趋势。无论是数据集中还是信息中心都需要将分散在各地的数据信息采集起来。数据库中已经存在的数据有很多的办法、手段进行采集，但是在采集数据之后，对于日后数据库的变化（增、删、改）如何二次采集是一个难题。

一些跨地域的业务系统为了处理业务的迅速、方面，基本都在本地的局域网内建立数据库，而其中一些业务系统需要在整个业务系统内（跨地域）保障数据的完整性、一致性，在每个业务节点之间如何进行数据库增量同步，也是一个难题。

FMQ数据增量同步平台，可以有效的解决上述难题，无需任何编程知识，只需设置相应的采集工具、入库工具便可以实现数据库增量同步。

FMQ数据增量同步平台是构架在数据路由平台与数据交换管理平台基础之上的应用平台，提供数据库增量同步中需要的各种先进的工具软件产品，可以简单、有效的完成数据增量同步。

 

1.7. 数据文档模板转换示例

 

跨业务部门、跨应用系统实现消息、数据共享，需要每个应用系统彼此能够识别对方的格式，当发生变化的时候（某一应用系统更改了消息、数据格式或者增加了一种新的应用系统），与其连接的应用系统都要进行相应的修改，这为应用系统带来了很多的不便和巨大的工作量。

要解决这个问题，需要在应用系统之间建立一个公共的、中间态的，拥有消息、数据格式转换能力的平台。应用系统只需识别自己的格式，而不必关心其他应用系统的格式。平台以一个中间态格式来描述保存的消息、数据，在消息、数据出平台的时候会被自动转换成接收端应用系统能够识别的格式。

数据文档模板转换平台在这个需求下诞生了，它构架在FMQ数据交换管理平台基础上，通过文档模板管理中心，管理文档模板转换适配器，管理平台内所有的消息，并在需要的时候调用相应的适配器进行格式转换。

 

 

数据文档模板转换平台流程图：

 

 

 

 

 

1.8. 基于请求代理架构的模糊查询

 

查询是业务系统提供一项基本功能，一些业务系统通过WEB等手段对外提供数据查询服务，这需要用户了解提供服务的业务系统有哪些，以及如何登录这些系统、如何使用这些系统，对于那些不知道具体应该在哪个业务系统来查询的请求往往很难被处理。

以公安系统的人口查询为例，某干警根据业务需要想查找一个人的相关资料，已经知道的信息有姓名：XXX  性别：男 籍贯：北方人（黑、吉、辽、蒙）年龄：25～30左右，这位干警想知道他可以查到的一切信息，比如人口信息、犯罪记录、在逃记录等等。对于这种业务需求，使用上述的业务系统将很难完成查询，即使能够查询也大大增加了这位干警的工作量与工作难度。

基于请求代理架构的模糊查询可以帮助完成上述需求。请求代理架构是一种适合目前已有业务系统灵活的框架，它由三部分组成：请求分析中心、请求处理客户端、请求结果处理中心。

 

请求代理平台整体结构图：

　　

从业务数据所处的位置来看，查询有两种情况，一种是本地查询，数据库与查询服务位于同一个局域网内且归同一个部门管理，另一种是异地查询，数据库位于同一个局域网但归另外的行政单位管理，或者该数据位于跨地域的其他地区，使用请求代理架构可以灵活的适应上述的两种情况，规避或解决在实际应用中可能遇到的问题。

请求分析中心与请求处理客户端是一对多的关系，在系统部署实施方面也可以大大节约成本，不用大量购买昂贵的设备，只需安装一台请求分析中心，在能提供业务数据的节点上安装请求处理客户端即完成了整个请求代理架构的搭建。随着日后业务处理的不断增多，或者下级节点也需要自己的请求代理中心，只需添置相应的请求分析中心就能满足需要。

在这种架构上实现上述的模糊查询将变得非常容易。干警只需登录模糊查询系统，录入查询条件，并提交给请求分析中心就完成了查询的工作。请求分析中心根据资源库，查找可以处理该请求的客户端，并将查询请求发送过去；客户端程序处理查询请求将结果发到结果处理中心，结果处理中心将所有发过来的数据进行整理、清洗（去掉重复、无效的结果），最后将结果显示出来，这位干警在提出请求后，查看结果处理中心的结果就能得到他所要的查询结果了。

 

“FMQ”  VS “IBM MQ ”

原文网址：mq吧

  FMQ属于软件平台产品，它不同于MQ等中间件产品，软件平台与软件中间件之间有着很多相似之处，它们最大的不同在于中间件产品往往需要专业人士进行二次开发才能使用，而平台软件只需根据业务需要进行相关的配置或者少量的二次开发即可使用。

   FMQ作为平台软件，同时也拥有中间件的一切特征，可以说比单纯的中间件又进了一个层次，而且FMQ的架构不同于MQ，中央控制分布式架构，集管理和效率于一身，完美解决了CS方式的效率问题与P2P方式难以管理的问题。

   我们公司曾做过很多MQ项目，也可以称得上是MQ专家了：），MQ这个东西用的越深越感觉到有些问题，毕竟是上个世纪90年代的产物了，从MQ2.1到MQ5.3传输机制还是那样，比如两个点要进行传输必须实现要建立队列、通道对象，每个队列最大为2.1G，多个通道多个队列共享同一个日志空间，还要受到日志的限制，最大个数为63个等等，还有碰到一些意外的情况比如磁盘爆满MQ会启动100多个通道进程，直接将A服务器搞死，或者其他的一些原因,狂写错误日志将磁盘空间涨死等等，象什么序列号不一致、通道启动不起来呀等等错误，IBM的人过来了都没解决。

   FMQ从面世到如今经历了2年了，它的稳定性、高效性、易用性是我们所自豪的，普通的PC，每秒可以传输800多个消息（每个消息为持久性消息，保证顺序、可靠传输，防关机、断电；有日志、统计、事务）每天可以传几千万的数据量，短信级的数据交换平台；如果加上建立FMQ群集，这个量就更大了～ 公安部的人口数据就用FMQ传的～

FMQ本身拥有的东西还有很多，这里就不一一列举了～～～

虽然说了MQ这么多不足，但是作为程序员，我还是要说，IBM的MQ是个大师级的产品，里面的很多思想绝对高～～～，希望有人也会这么评价FMQ！：）