A company uses an existing IT configuration provided by IBM MQ Version 8.0 installed on a server with a Windows operating system. This scenario describes migrating the
initial IT configuration to an equivalent IT configuration provided by IBM MQ Version 9.0 on the same server.
The initial IT configuration includes several components that an administrator configures or
uses, as shown in Figure 1: Figure 1. Initial IT configuration. The initial IT configuration includes an initial context, added for IBM MQ Explorer to connect to the root of the JNDI namespace. The JNDI
namespace includes a connection factory, added for the sample JMS application to use to connect to IBM MQ, and a destination, added for the sample JMS application to connect to the IBM MQ queue. That IBM MQ queue has also been added into the initial IT
configuration for use by the sample JMS application.
JMS application
A stand-alone application that business users interact with, for example to register an order.
The application uses the Java Message Service (JMS) for asynchronous messaging.
JMS is the Java EE messaging standard that is widely supported. JMS-based applications are therefore portable across many
messaging products.
JMS provides a level of abstraction from the
details of the messaging layer, simplifying the application development process.
JMS provides asynchronous communication,
enabling applications to run without having to wait for a reply, unlike tightly coupled systems such
as remote procedure call (RPC).
Applications that use JMS do not directly
specify details to access resources. Instead, they look up and use administered JMS objects such as a connection factory and a destination.
For some situations, other messaging standards might be more suitable than
JMS. For example IBM Message Service Clients for C, C++ and .NET, also known as XMS, are APIs that provide similar
benefits to JMS for non-Java applications. XMS is therefore more suitable if you are
using the .NET platform, or you want to integrate
existing C++ applications with newer Java EE
applications.
The application uses point-to-point messaging to send messages to a queue in the infrastructure
and processes reply messages, to provide the business user with an appropriate response.
In this messaging model, an application sends a message to a queue, and another
application receives the message from the queue and acknowledges receipt of the message. This model
is the simplest form of messaging because it involves only two endpoints. This model is also the
most appropriate for the scenario sample application: a single client requests information from a
single server.
In the alternative messaging model, publish/subscribe, a publisher
publishes a message to a message topic. Subscribers subscribe to the topic to receive messages. The
publisher and subscriber do not have any information about each other, and the message is received
by zero or more recipients.
Queue manager sampleQM
The IBM MQ queue manager that provides the initial
messaging infrastructure. It hosts the queue that the JMS application works with.
Q1 [Message queue]
The IBM MQ queue that the JMS application sends messages to.
JNDI namespace
A Java Naming Directory
Interface
JNDI namespace is used to hold JMS administered objects, which applications can use to
connect to IBM MQ and access destinations to send or
receive messages.
JNDI is part
of Java EE, and provides a standard way for
applications to access various types of naming and directory services, for the retrieval of
application components. For example, we can use JNDI to access a naming service on a file system to retrieve the location of a printer object, or to
access a directory service on an LDAP server to retrieve a user object which contains ID and
password information. JNDI therefore enhances the
portability of JMS-based applications, and makes it
easier to integrate those applications with each other and into existing systems. For JMS messaging, we use JNDI to store objects that represent the target destination
of a message, or the connection factory that creates the connection between our application and its
messaging destination.
Any application or process with access to the JNDI namespace can use the same administered objects. The properties of the administered objects can
be changed in JNDI, with all the applications or
processes able to benefit from those same changes.
Initial context
An initial context defines the root of the JNDI
namespace. To use IBM MQ Explorer to create and configure
administered objects, you first add an initial context that defines the root of the JNDI namespace. Similarly, a JMS application first obtains an initial context, before it
can retrieve administered objects from the JNDI
namespace.
Connection factory, myCF
A JMS connection factory
object defines a set of standard configuration properties for connections. An application uses a
connection factory to create a connection to IBM MQ.
Destination, myQueue
A JMS destination can be a topic or a queue. In
this scenario, the destination is a queue, and identifies the IBM MQ queue that applications send messages to, or from which an
application receives messages, or both. An application looks up the destination in the JNDI
namespace to create a connection to the IBM MQ queue.