(Source: http://www.ccw.com.cn)
With the continuous development of computer networks and distributed applications, remote messaging is increasinglycoming an indispensable component in an application system. The emergence of commercial message middleware ensures the reliability, high efficiency and security of message transmission, and also reduces the system development cycle. Currently used messaging middleware products for IBM MQSeries. This article explains in detail for the basic operations and configuration of MQ, and I hope to help readers.
One. MQ basic operation
There are several important components in MQ: QueueManager, Queue, and Channel. The basic method of operation is as follows:
Create queue manager
Crtmqm -q qmgrname
-q refers to creating a default queue manager
Delete Queense Manager
DLTMQM QMGRNAME
Start queue manager
Strmqm QMGRNAME
If you are starting the default queue manager, you can do your name
Stop Queue Manager
Endmqm QMGRNAME controlled stop
Endmqm -i qmgrname stops
Endmqm -p QMGRNAME forced stop
Show queue manager
DSPMQ -M QMGRNAME
Run MQSeries command
Runmqsc QMGRNAME
If it is the default queue manager, you can bring its name
Put your message in the queue
amqsput Qname QMGRNAME
If the queue is the queue in the default queue manager, you may not take the name of its queue manager.
Remove the message from the queue
amqsget Qname QMGRNAME
If the queue is the queue in the default queue manager, you may not take the name of its queue manager.
Start channel
Runmqchl -c chlname -m qmgrname
Start listening
Runmqlsr -t type -p port -m qmgrname
Stop listening
Endmqlsr -m qmgrname
MQSeries command
Define the dead letter queue
Define Qlocal (QNAME) Defpsist (YES) REPLACE
Set the dead letter queue of the queue manager
Alter QMgr Deadq (QNAME)
Define local queue
Define QL (QNAME) REPLACE
Define an alias queue
Define Qalias (QaliasName) Targq (QNAME)
Remote queue definition
Define QRemote (QRNAME)
RNAME (AAA) RQMNAME (QMGRNAME)
Xmitq (QTName)
Define model queue
Define QMODEL (QNAME) DEFTYPE (TEMPDYN)
Define local transmission queues
Define Qlocal (QTName) USAGE (Xmitq) Defpsist (Yes)
INITQ (System.Channel.initq)
Process (ProcessName) Replace
Create a process definition
Define Process (PRONAME)
DESCR ('string')
AppLtype (WindowsNT)
Applicid ('Runmqchl -c SDR_TEST -M QM_ Test')
Where the value of AppLType can be: CICS, UNIX, Windows, Windows, etc. Create a sender channel
Define Channel (SDRNAME) CHLTYPE (SDR)
Conname ('100.100.100.215 (1418)) XMITQ (Qtname) Replace
The CHLTYPE can be: SDR, SVR, RCVR, RQSTR, CLNTCONN, SVRCONN, CLUSSDR, and Clusrcvr.
Create a recipient channel
Define Channel (SDR_ Test) CHLTYPE (RCVR) REPLACE
Create a server connection channel
Define Channel (SVRCONNNAME) CHLTYPE (SVRCONN) REPLACE
Display all properties of the queue
Display queue (QNAME) [all]
Show the selected properties of the queue
Display Queue (QNAME) Descr Get Put
Display Queue (QNAME) MaxDepth Curdepth
Display all properties of the queue manager
Display QMGR [all]
Display process definition
Display Process (Proname)
Change properties
Alter QMgr Descr ('New Description')
Alter Qlocal (QNAME) PUT (Disabled)
ALTER Qalias (QNAME) Targq (targqname)
Delete queue
Delete Qlocal (QNAME)
Delete QRemote (QRNAME)
Clear all the messages in the queue
Clear Qlocal (QNAME)
two. Configure a remote connection that can communicate
The above is described in the basic command operation of MQ, but only knows that these are not practical. The ultimate goal of MQ is to implement remote communication, so below will explain how to implement remote connections with a specific example. The purpose of this example is to establish a pair of MQ servers that enable messaging, which are based on NT and UNIX platforms, respectively.
First build a queue manager at NT
Crtmqm -q qm_nt
Start queue manager
Strmqm QM_NT
Run the MQ console command
Runmqsc QM_NT
Create a dead letter queue
Define QL (NT.DEADQ) Defpsist (YES) REPLACE
Change the Queen Manager property and set its dead letter queue
Alter QMGR Deadq (NT.DEADQ)
Create a process definition
Define Process
AppLtype (WindowsNT)
Applicid ('Runmqchl -c SDR_NT -M QM_NT')
Create a local transmission queue
Define QL (QT_NT) Usage (xmitq) Defpsist (Yes)
INITQ (System.Channel.initq)
Process (p_nt) Replace
Create a remote queue definition, corresponding to the local queue Q_Unix on the UNIX machine, the transfer queue is Qt_NT
Define QRemote (QR_NT) RQMNAME (QM_UNIX)
Xmitq (QT_NT)
Create a sender channel, its transmission queue is qt_nt, the remote host address is 10.10.10.2, the listening port is 1414
Define Channel (SDR_NT) CHLTYPE (SDR)
Conname ('10.10.10.2 (1414) ') XMitq (Qt_NT) Replace
Create a server connection channel
Define Channel (S_NT) CHLTYPE (SVRCONN) REPLACE
Create queue manager in UNIX
Crtmqm -q qm_unix
Start queue manager
Strmqm QM_Unix
Add a listener
Modify the / etc / services file, join a line:
MQSeries 1414 / TCP # MQSeries Channel Listener
Modify the /etc/inetd.conf file, join a line (start the listener)
MQSeries Stream TCP NOWAIT MQM / USR / LPP / MQM / BIN / AMQCRSTA AMQCRSTA -M QM_UNIX
Run the following command to make modifications
Refresh -s inetd
Run the MQ console command
Runmqsc QM_Unix
Create a dead letter queue
Define QL (UNIX.deadq) Defpsist (Yes) Replace
Change the Queen Manager property and set its dead letter queue
Alter QMgr Deadq (UNIX.DEADQ)
Create a recipient channel, its name must be the same as the remote sender
Define Channel (SDR_NT) CHLTYPE (RCVR) Replace
Create a local queue
Define QL (Q_Unix) Defpsist (YES) Replace
Create a server connection channel
Define Channel (S_UNIX) CHLTYPE (SVRCONN) Replace
After the above operation, the configuration of the remote connection is completed. Next, you need to verify that the configuration is correct.
Start the sender channel in the NT end
Runmqchl -c SDR_NT -M QM_NT or START CHL (SDR_NT)
Send a message from the NT side to UNIX
amqsput qr_nt qm_nt
Receive messages on UNIX
/ usr / mqm / samp / bin / amqsget Q_Unix QM_Unix
If you can receive a message, the configuration is successful.
In addition, in NT, the listener is automatically established when the queue manager is established, and the listener is automatically started when the queue manager is started. Of course, you can also manually configure the listener.
Modify / Winnt / System32 / Drivers / etc / services file, add a line in the file:
MQSeries 1414 / TCP # MQSeries Channel Listener
Start listening program
Runmqlsr -t tcp -p 1414 -m qm_nt
The above explains how to establish a simple one-way transmission network. The message is sent from the NT terminal to the UNIX terminal. Establish a remote connection from UNIX to the NT side, which is similar, and the same reason is to establish a two-way transport network.
three. Configuring JNDI
When you use JMS to realize the sending and reception of messages, JNDI is often used. Because JNDI is more flexible, it is relatively simple for programming. After installing the MQSeries Client for Java, find the JMSAdmin.config file in the / java / bin directory. This file is mainly used to illustrate the storage mode and storage address of the Context, corresponding to the two parameters in the file, initial_context_factory, and provider_url. Typical JMSADMIN.CONFIG files are as follows:
# Ion_context_factory = com.sun.jndi.ldap.ldapctXFactory
Initial_context_factory = com.sun.jndi.fscontext.reffsContextFactory
# Ion_context_factory = com.ibm.ejs.ns.jndi.cninitialcontextFactory
#
# Urgeder_url = ldap: // Polaris / O = IBM, C = US
Provider_url = file: / d: / temp
# Provider_url = iiop: // localhost /
#
Security_authentication = none
Initial_Context_Factory represents the service provider used by JMSAdmin Tool. There are currently three supported values. com.sun.jndi.ldap.ldapctXFactory is used for LDAP, if you use it, you must install an LDAP server. com.sun.jndi.fscontext.reffsContextFactory is used in the file system context, which only requires the user to provide the file path to the context. com.ibm.ejs.ns.jndi.cninitialContextFactory is designed for WebSphere, which needs to be used with WebSphere's CoSNaming repository.
Provider_url indicates the URL of the session initial context, and the root of all JNDI operations implemented by JMSADMIN TOOL. It corresponds to initial_context_factory.
LDAP: // Hostname / ContextName for LDAP
FILE: [Drive:] / Pathname Used for File System Context
IIOP: // Hostname [: port] / [? TargetContext = CTX] is used to access WebSphere cosnaming namespace
Finally there is a parameter security_authentication, which is used to explain whether JNDI passes the security credentials to your service provider. This parameter is only used when using an LDAP service provider. This parameter has three values, NONE (anonymous authentication), Simple, and CRAM-MD5 authentication mechanism. If no valid value is provided, the default is None.
After confirming the configuration file, you can start the JMSADMIN console in the / java / bin directory. You can also start the console with the following command in any directory:
JMSADMIN -CFG MQ_JAVA_INSTALL_PATH / JAVA / BIN / JMSADMIN.CONFIG
Where mQ_java_install_path is the root directory installed by MQSeries Client for Java.
If the startup fails, check if your environment variable is set correctly. According to my personal experience, in addition to add com.ibm.mq.jar and com.ibm.mqjms.jar, add fscontext.jar and providerutil.jar to the environment variable.
Once you enter the JMSADMIN console, you can freely define the Sub Context. For the operation of the sub context, there is a command: Display CTX
Define CTX (CTXName)
Change CTX (CTXName)
Change CTX (= Up)
Change CTX (= init)
DELETE CTX (CTXName)
Of course, the main task here is not used to define sub context, but used to define the following objects:
MQQueueConnectionFactory
MQtopicConnectionFactory
MQQueue
MQtopic
(There are other objects, such as MQXaqueueConnectionFactory, etc., are not commonly used, this is not described here.)
Many verbs can be used to manipulate managed objects in the directory namespace. Alter, Define, Display, Delete, Copy and Move, their usage is relatively simple, and only one or two will be described here.
Example 1: Define a QueueConnectionFactory, connect 10.10.10.18, port 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)
Example 2: Define a Queue, which corresponds to Q_EXAMPLE in MQ
Define Q (ExampleQL)
DESC (LOCAL Queue)
QMGR (QM_EXAMPLE)
Queue (Q_Example)
CCSID (1381)
four. Implement MQ programming with JMS
Above we explain how to define the context of the MQ object with JMSADMIN TOOL. Our ultimate goal is to use JMS to implement MQ programming to implement the MQ queue in the program. So, below will focus on discussing the MQ JMS implementation.
If you are familiar with JMS programming, you will use JMS to implement MQ programming, because use JMS to write MQ programs and write a general JMS program without much difference. For example, when we want to send a message to the Queue of MQ, we have four steps when we retrieve the message from the queue. First we have to initialize the object to be used in the program, and then send a message to the queue, and then collect the message, and finally clear those permanent objects. These are quite equivalent to ordinary JMS programs. The source code of the program is as follows:
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 ();
QueueESession = connection.createqueuesis (false, session.auto_acknowledge);
Queuesender = queness.createsender (q1);
Queuesender.SetDeliveryMode (DeliveryMode.non_Persistent);
Outmessage = queness.createtextMessage ();
Queueeeceiver = queness.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.RecEceptage ();
System.out.println ("Receive Text IS:" REC);
Sp.SAMPLECLOSE ();
} catch (exception e) {
E.PrintStackTrace ();
}
}
}
Fives. Remote management MQ has a graphical management interface under the Windows platform, but can only be operated by the command line under UNIX platforms. This brings a lot of inconvenience to the user. We all want to manage configuration through graphical interfaces. In order to achieve our thoughts, we must establish remote management.
Realizing remote management has the following steps:
1. The command queue on the managed queue manager system.admin.command.queue is available and available. The amqscoma.tst script should be created for MQ 2 versions.
2. Use the strmqcsv command to launch the command server on the managed queue manager.
3. Determine if the server connection channel SYSTEM.ADMIN.SVRCONN on the managed queue manager exists if it does not exist.
4. General Unix, the default character set in the Linux platform is 819, and the Windows platform is 1381, so you must change its character set to make the two sides of the character set. Generally changed the managed character set.
5. If the operational user on the managed queue manager is different from the operating user on the management queue manager, then you first have to confirm that the operations on the management queue manager exists on the managed queue manager and manage MQ, and then In addition, you need to modify the server connection channel system.admin.svrconn's McAuser property to the operational user on the management queue manager.
6. Start the listener on the managed queue manager.
After doing these work, display the managed queue manager directly in the MQ administrative tool of the Management Queue Manager. Then you can define the MQ object you need on the managed queue manager as you can operate the local queue manager.
six. Channel maintenance
We have created a process definition when configuring a remote connection. Then why do we have to create a process definition? This involves the concept of maintenance of MQ channels.
There is no message trigger for a long time without messaging, and the operation is not maintained. The length of time can be set by yourself, the default is 6000 seconds. When the message request is coming again, the channel must be started again. Some channels, such as server connection channels, receiver channels, etc. are automatic trigger startup. When the message request is sent to the channel, the channel starts immediately and enters the running state. But there are also some channels that will not start automatically, the most typical is the sender channel. When there is a message requesting to communicate using channels, the sender channel does not start automatically and sends the message to the remote queue, but the message is left in the transmission queue associated with it.
However, in practical applications, we can't start a passage every time, or when there is a message to start the channel. What should I do? First we create a process definition, the purpose of this process is to initiate the sender channel. Then we specify the process definition name just defined in the process name attribute bar of the transfer queue, and turn the trigger control switch on. Thus, after the message enters the transmission queue, the flip-flop of the transmission queue starts the trigger to execute the specified process, to initiate the sender channel, transfer the message to the remote queue.
Seven. to sum up
Maybe you will say that you have understood MQ, including basic concepts, configuration, management, and programming, so congratulations. I hope so too. However, MQ may not be so simple, because I have limited level, I can only go here, I hope everyone will continue to work harder. By the way, if there is anything good idea, don't forget to tell me.
