I am trying to develop a JMS standalone application to read and write to a Queue on MQSeries. My boss asked me to use pure java JMS (not ibm.mq lib) to do that.
Here is the information that need to make the jms connection:
mq.hostname=10.10.10.10
mq.channel=API.CLIENTCHL
mq.queueManager=MQPETAPI
mq.port=1422
Do you know how to do that Or do you have any link that teach me to do that.
This is fairly common. Here are some examples.
I can't teach you JMS in a single post, but I can point you to some of the resources that I used to learn it myself:
If you don't mind writing WMQ-specific code then you can do
then usual JMS resources
and finally create and send a message
(i've typed that in off the top of my head so can't rule out a typo, but it's fundamentally correct). If you're really supposed to be using 'pure JMS' - i.e. with no provider-specific objects - then you need to bind a MQConnectionFactory object in JNDI (take a look at the JMSAdmin tool, it's in the docs) then look it up from your application, i.e.
Typically with JMS you would define the
QueueConnectionFactory
in your container via whatever configuration mechanism it makes available then add it to the container's JNDI registry. Each container would have it's own methods for doing that (i.e. Tomcat versus WebSphere).If you want to forgo JNDI, you could create an instance of
com.ibm.mq.jms.MQQueueConnectionFactory
directly and set the hostname, port, queueManager, and channel properties on it. You can then use that object as you would an instance ofjavax.jms.QueueConnectionFactory
since it implements it.The issue here is the requirement that "My boss asked me to use pure java JMS (not ibm.mq lib) to do that." JMS is a specification and each implementation must comply with the API and the semantics, but is free to do whatever they want at a low level. It is always necessary to use the implementation classes provided by the transport vendor. Therefore if you use WebSphere MQ as the transport, you will need to use the IBM MQ JMS classes to write a JMS application.
That said, if you stick with pure JMS API calls you would be able to plug in any transport vendor's classes. This is what is usually intended when you are given requirements such as that mentioned in the original post.
There's an article describing exactly what you are looking to do called Running a standalone Java application on WebSphere MQ V6.0 It uses only the JMS API and it uses JNDI in a local file system (a .bindings file). By swapping out the IBM JMS classes for another vendor and using their JNDI tools you would be able to plug in any JMS transport without changing your code using this approach.
If you want to do the same thing without JNDI, look at the sample programs provided with the MQ client install where you obtained your Java classes. In a UNIX/Linux system these are in
/opt/mqm/samp
and on Windows they are ininstall_dir/tools/jms/samples
. TheSimpleRequestor.java
sample has the following code for initializing your connection factory without JNDI:Because this approach does not use JNDI, you are required to write code that is not transportable across transport vendors. It is IBM WebSphere MQ specific.
If you grabbed the MQ jars from somewhere and do not have the full install (and thus do not have the samples) you can download it as SupportPac MQC7. The download is free. In general you should use the latest client, even with a back-level queue manager. Obviously you do not get V7 functionality from a V6 QMgr but the JMS implementation in the V7 client is much improved, even for V6 functionality. If for some reason you really must use the V6 client, you can download it as SupportPacMQC6. Whichever client version you use, make sure to use the corresponding Infocenter.
V6 Infocenter
V7 Infocenter
Finally, the landing page with an index for all the SupportPacs is here.
Note: Replace the configuration values