Configure connection factories and destinations in a JNDI namespace
JMS applications access administered
objects in the naming and directory service through the Java Naming and Directory Interface (JNDI). The JMS administered objects are stored in a location within the
naming and directory service that is referred to as the JNDI namespace. A JMS application can look up the administered objects to
connect to IBM MQ and access destinations for sending or
receiving messages.
About this task
JMS applications look up the names of the
JMS objects in the naming and directory service by
using contexts:
Initial context
The initial context defines the root of the JNDI namespace. For each location in the naming and
directory service, we need to specify an initial context to give a starting point from which a
JMS application can resolve the names of the
administered objects in that location of the naming and directory service.
Subcontexts
A context can have one or more subcontexts. A subcontext is a subdivision of a JNDI namespace
and can contain administered objects such as connection factories and destinations as well as other
subcontexts. A subcontext is not an object in its own right; it is merely an extension of the naming
convention for the objects in the subcontext.
We can create contexts using either IBM MQ Explorer or
the IBM MQ JMS administration tool.
Before an IBM MQ classes for JMS application can retrieve
administered objects from a JNDI namespace, we must first create the administered objects using
either IBM MQ Explorer or the IBM MQ JMS administration tool. We can create and
configure the following types of JMS object:
Connection factory
A JMS connection factory object defines a set of
standard configuration properties for connections. A JMS application uses a connection factory to create a
connection to IBM MQ. We can create a connection
factory that is specific to one of the two messaging domains, the point-to-point messaging domain
and the publish/subscribe messaging domain. Alternatively, from JMS 1.1, we can create domain-independent connection factories
that can be used for both point-to-point and publish/subscribe messaging.
Destination
A JMS destination is an object that represents
the target of messages that the client produces and the source of messages that a JMS application consumes. The JMS application can either use a single destination object to
put messages on and to get messages from, or the application can use separate destination objects.
There are two types of destination object:
JMS queue destination used in point-to-point
messaging
JMS topic destination used in publish/subscribe
messaging
The following diagram shows an example of JMS
objects created in an IBM MQ JNDI namespace.Figure 1. JMS objects created in IBM MQ
If we use JMS messaging between WebSphere Application Server and IBM MQ,
create corresponding objects in WebSphere Application Server to use
to communicate with IBM MQ. When you create one of these
objects in WebSphere Application Server, it is stored in the WebSphere Application Server JNDI namespace as shown in the following diagram.
Figure 2. Objects created in WebSphere Application Server, and the corresponding
objects in IBM MQ
If the application uses a message-driven bean (MDB), the connection factory is used for outbound
messages only and inbound messages are received by an activation specification. Activation
specifications are part of the Java EE Connector Architecture 1.5 (JCA 1.5) standard. JCA 1.5 provides a standard way to integrate JMS providers, such as IBM MQ, with Java EE application servers such as WebSphere Application Server. A JMS activation specification can be associated with one or
more message driven beans (MDBs) and provides the configuration necessary for these MDBs to listen
for messages arriving at a destination.
We can use either the WebSphere Application Server administrative console
or wsadmin scripting commands to create and configure the JMS resources that we need.
An IBM MQ classes for JMS application can retrieve the
administered objects from the JNDI namespace and, if required, set or change one or more of its
properties by using either the IBM
JMS extensions or the IBM MQ JMS extensions.