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.
