三．配置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一一对应。
http://www.cnblogs.com/xFight/admin/ldap://hostname/contextname 用于LDAP
file:[drive:]/pathname 用于文件系统上下文
iiop://hostname[]/[?TargetContext=ctx] 用于访问websphere CosNaming名称空间
最后还有一个参数SECURITY_AUTHENTICATION，用于说明JNDI是否把安全性凭证传递给了您使用的服务供应商。只有当使用了LDAP服务供应商时，才使用此参数。此参数有三个值，none（匿名认证）、simple（简单认证）和CRAM-MD5认证机制。如果没有提供有效值，缺省值为none。
确认配置文件之后，可以在\java\bin目录下启动JMSAdmin控制台。也可以在任何目录下用下面的命令来启动控制台：
JMSAdmin –cfg MQ_JAVA_INSTALL_PATH\java\bin\JMSAdmin.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)
五．远程管理
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秒。消息请求再次来临的时候，就必须再次启动通道。有些通道，如服务器连接通道、接收方通道等是自动触发启动的。当消息请求发送到通道后，通道立即启动，进入运行状态。但也有一些通道不会自动启动，最典型的就是发送方通道。当有消息请求需要使用通道进行消息传递的时候，发送方通道也不会自动启动并把消息发送到远程队列，而是把消息留在了与其相关联的传输队列中。
但是，在实际应用中我们又不可能每过一段时间去启动一次通道，或当有消息来再去启动通道。那应该怎么办？首先我们创建一个进程定义，这个进程定义的目的就是用来启动发送方通道。然后我们在传输队列的进程名称属性栏指定刚才定义的进程定义名称，再把触发器控制开关打开。这样，当有消息进入传输队列后，传输队列的触发器会启动触发执行指定的进程，从而启动发送方通道，把消息传输到远程队列中去。
