WebSphere MQ, Version 7.0 integrates JMS configuration into its graphical, Eclipse-based tool, MQ Explorer, making it easier to design and deploy JMS solutions. JMS objects, such as connection factories and destinations, are now displayed in MQ Explorer along with WebSphere MQ objects, such as queues and channels. MQ Explorer can remotely configure the entire WebSphere MQ network, it is now easier to explore and configure JMS messaging across the network. Now MQ Explorer makes it easier to see all the properties of JMS resources at a glance and update JMS object properties. It is easier to create JMS resources, such as connection factories, using step-by-step wizards.
Administered Objects:
Administered objects encapsulate provider specific implementation and configuration information about connections and destinations. Administered Objects can be accessed by client applications through standard JNDI lookup code.
There can be several types of Administered Objects like Destination, ConnectionFactory, XAConnectionFactory, SOAPEndpoint, etc.
Destination represents a physical destination.
ConnectionFactory establishes physical connection between a client application and a Message Queue message server.
XAConnectionFactory is used to establish physical connections that support distributed transactions.
Although the JMS specification does not require JMS clients to lookup administered objects in a JNDI namespace, there are distinct advantages to doing so: it allows for a single source of control. it allows connections to be configured and reconfigured without having to recode, and it allows clients to be portable to other JMS providers.
Using administered objects means that client programmers do not have to know about provider specific syntax and object naming conventions or provider specific configuration properties. By specifying that administered objects be read only, administrators can ensure that client applications cannot change administered object attribute values that were set when the administered object was first created.
Administered Objects are placed in an object store, where they can be accessed by client applications through JNDI lookup.
Message Queue supports two types of objects tore: a standard LDAP directory server and a file-system object store. LDAP is recommended object store for production messaging systems.
MQ classes for JMS
IBM provides Web Sphere MQ classes for Java, which encapsulate MQI, and native MQ API's with some object oriented interfaces. A Java application can directly use MQ classes for Java, to perform any kind of operation.
IBM also provides MQ classes for JMS, which implement the javax.jms package.
Difference can be noticed while using the API's.
For instance using MQ classes for Java, we use MQQueueManager and MQQueue.
while using MQ classes for JMS we use ConnectionFactory and Destination.
where connection factory generally corresponds to Queue Manager, and Destination corresponds to Queeue.
MQ classes for JMS comes with two extensions, i.e. two extension's of JMS API or two implementations of JMS API.
First set of extension is implemented in objects such as MQConnectionFactory, MQQueue, and MQTopic objects.hese objects have properties and methods that are specific to WebSphere MQ. The objects can be administered objects, or an application can create the objects dynamically at run time.
With MQv7 came a new set of extension which is more generic and is implemented in objects such as JmsQueueConnectionFactory, JmsXAConnectionFactory, JMSQueue, JMSTopic, etc. This new set of extension is also called IBM JMS extension. Main focus for this extension is creating an configuring Connection Factory and Destination dynamically at runtime.
Remember, there is a big difference in using the previous API, and the new API.
Previous API expected that Connection Factory and Destination should be administered objects, i.e., bind to JNDI namespace, and client can perform lookup and use them to send and receive messages.
But new IBM JMS extension API's main focus is to creating and configuring Connection Factory and Destination dynamically at runtime.
Below, we are going to discuss the first set of API, where we are going to see how to make administered JMS objects, i.e. how to bind connection factory and destination to JNDI name, and how client can use them.
The JMS specification expects ConnectionFactory and Destination objects to be administered objects. An administrator creates and maintains administered objects in a central repository, and a JMS application retrieves these objects using the Java Naming and Directory Interface (JNDI). WebSphere MQ classes for JMS supports the use of administered objects, and an administrator can use either the WebSphere MQ JMS administration tool or WebSphere MQ Explorer to create and maintain administered objects.
Create .bindings file using MQ Explorer.
Create JMS Objects under a specific JNDI namespace.
Basically we would be creating a .bindings file, which would hold all information related to JNDI root, JNDI namespace, and JMS objects( for Queue Manager & Queue)
We would be creating a file based JNDI context and configure the JMS objects in that JNDI namespace.
These JMS objects would be used by applications running in OC4J to connect WebSphere MQ Manager.
The setting is for file based JNDI. So first cerate a directory where to create .bindings file.
In this case it is (C:\MQ-JNDI)
Pressing :Next” would give this screen:
Next screen contains “Context nickname” which would be used in the applications deployed in OC4J.
Connect the Newly created Context:
Right Click “Connection Factories” and create new Connection Factory.
Select “Queue Connection Factory” as type.
Select “Transport” as “Bindings” if in case MQ and client applications are on the same machine.
But generally, this would be rare, and also in this case you would need some dll's.
Transport should be selected as “MQ Client”, if Queues would be accessed by remote applications.
I would suggest, alsways use Client transport mode, so that you can access Queue(/Destination), from remote location also.
Selecting "Bindings" means bindings transport mode, which improves speed, but needs application to be on same machine and also needs some MQ server dll's.
Name of the Connection Factory is important as this name can be used by Message Driven Bean, and deployment descriptors.
Select the Queue Manager to be associated with this Connection Factory:
i.e. click “Base queue manager:”, select the our newly created queue manager.
Check finish.
This would create a Queue Connection Factory which would connect applications to the mentioned Queue Manager.
Queue manager has Queue, and this Queue would be “destination”. Destination from where our MDB would pick messages.
In coming steps we would be adding the queue as a destination, to which MDB would be listening.
Select Destinations and create a new destination:
Enter name of destination. This name is very important as this name would be used in the MDB, and this is the destination name where MDB would be listening.
Also, Select Queue Manager and Queue to be associated with this destination.
Queue manager should be same as the one to which we created the connection factory.
After this wizard completes, .bindings file is created in the location C:\MQ-JNDI.
Don't make any changes to this file.
Assuming that, we mentioned the name of QueueConnectionFactory as "MQQCF", and Destination as "MQQ", below is the sample Java program to send message on the MQ Queue:
Remember, always use "Client Transport mode", to make above program work.
It will also need many jars to work, like jms.jar, jndi,jar, fscontext.jar, etc.
Administered Objects:
Administered objects encapsulate provider specific implementation and configuration information about connections and destinations. Administered Objects can be accessed by client applications through standard JNDI lookup code.
There can be several types of Administered Objects like Destination, ConnectionFactory, XAConnectionFactory, SOAPEndpoint, etc.
Destination represents a physical destination.
ConnectionFactory establishes physical connection between a client application and a Message Queue message server.
XAConnectionFactory is used to establish physical connections that support distributed transactions.
Although the JMS specification does not require JMS clients to lookup administered objects in a JNDI namespace, there are distinct advantages to doing so: it allows for a single source of control. it allows connections to be configured and reconfigured without having to recode, and it allows clients to be portable to other JMS providers.
Using administered objects means that client programmers do not have to know about provider specific syntax and object naming conventions or provider specific configuration properties. By specifying that administered objects be read only, administrators can ensure that client applications cannot change administered object attribute values that were set when the administered object was first created.
Administered Objects are placed in an object store, where they can be accessed by client applications through JNDI lookup.
Message Queue supports two types of objects tore: a standard LDAP directory server and a file-system object store. LDAP is recommended object store for production messaging systems.
MQ classes for JMS
IBM provides Web Sphere MQ classes for Java, which encapsulate MQI, and native MQ API's with some object oriented interfaces. A Java application can directly use MQ classes for Java, to perform any kind of operation.
IBM also provides MQ classes for JMS, which implement the javax.jms package.
Difference can be noticed while using the API's.
For instance using MQ classes for Java, we use MQQueueManager and MQQueue.
while using MQ classes for JMS we use ConnectionFactory and Destination.
where connection factory generally corresponds to Queue Manager, and Destination corresponds to Queeue.
MQ classes for JMS comes with two extensions, i.e. two extension's of JMS API or two implementations of JMS API.
First set of extension is implemented in objects such as MQConnectionFactory, MQQueue, and MQTopic objects.hese objects have properties and methods that are specific to WebSphere MQ. The objects can be administered objects, or an application can create the objects dynamically at run time.
With MQv7 came a new set of extension which is more generic and is implemented in objects such as JmsQueueConnectionFactory, JmsXAConnectionFactory, JMSQueue, JMSTopic, etc. This new set of extension is also called IBM JMS extension. Main focus for this extension is creating an configuring Connection Factory and Destination dynamically at runtime.
Remember, there is a big difference in using the previous API, and the new API.
Previous API expected that Connection Factory and Destination should be administered objects, i.e., bind to JNDI namespace, and client can perform lookup and use them to send and receive messages.
But new IBM JMS extension API's main focus is to creating and configuring Connection Factory and Destination dynamically at runtime.
Below, we are going to discuss the first set of API, where we are going to see how to make administered JMS objects, i.e. how to bind connection factory and destination to JNDI name, and how client can use them.
The JMS specification expects ConnectionFactory and Destination objects to be administered objects. An administrator creates and maintains administered objects in a central repository, and a JMS application retrieves these objects using the Java Naming and Directory Interface (JNDI). WebSphere MQ classes for JMS supports the use of administered objects, and an administrator can use either the WebSphere MQ JMS administration tool or WebSphere MQ Explorer to create and maintain administered objects.
Create .bindings file using MQ Explorer.
Create JMS Objects under a specific JNDI namespace.
Basically we would be creating a .bindings file, which would hold all information related to JNDI root, JNDI namespace, and JMS objects( for Queue Manager & Queue)
We would be creating a file based JNDI context and configure the JMS objects in that JNDI namespace.
These JMS objects would be used by applications running in OC4J to connect WebSphere MQ Manager.
The setting is for file based JNDI. So first cerate a directory where to create .bindings file.
In this case it is (C:\MQ-JNDI)
Pressing :Next” would give this screen:
Next screen contains “Context nickname” which would be used in the applications deployed in OC4J.
Connect the Newly created Context:
Right Click “Connection Factories” and create new Connection Factory.
Select “Queue Connection Factory” as type.
Select “Transport” as “Bindings” if in case MQ and client applications are on the same machine.
But generally, this would be rare, and also in this case you would need some dll's.
Transport should be selected as “MQ Client”, if Queues would be accessed by remote applications.
I would suggest, alsways use Client transport mode, so that you can access Queue(/Destination), from remote location also.
Selecting "Bindings" means bindings transport mode, which improves speed, but needs application to be on same machine and also needs some MQ server dll's.
Name of the Connection Factory is important as this name can be used by Message Driven Bean, and deployment descriptors.
Select the Queue Manager to be associated with this Connection Factory:
i.e. click “Base queue manager:”, select the our newly created queue manager.
Check finish.
This would create a Queue Connection Factory which would connect applications to the mentioned Queue Manager.
Queue manager has Queue, and this Queue would be “destination”. Destination from where our MDB would pick messages.
In coming steps we would be adding the queue as a destination, to which MDB would be listening.
Select Destinations and create a new destination:
Enter name of destination. This name is very important as this name would be used in the MDB, and this is the destination name where MDB would be listening.
Also, Select Queue Manager and Queue to be associated with this destination.
Queue manager should be same as the one to which we created the connection factory.
After this wizard completes, .bindings file is created in the location C:\MQ-JNDI.
Don't make any changes to this file.
Assuming that, we mentioned the name of QueueConnectionFactory as "MQQCF", and Destination as "MQQ", below is the sample Java program to send message on the MQ Queue:
It will also need many jars to work, like jms.jar, jndi,jar, fscontext.jar, etc.
