Establishing Remote Connections with WebSphere MQ

A Message oriented Middleware (MoM) is critical for the existence of any SOA
based application. It essentially provides a backbone for reliable delivery of
critical business data and forms an integral part of the Enterprise Service Bus
(ESB).However, not every client application can afford to have a dedicated MoM
product installed. WebSphere MQ provides a reliable, safe, efficient and
guaranteed one time delivery of asynchronous messages amongst applications
written in different languages and running on different operating systems.

In a series of articles, we'll explore the basic MQ administration and get
acquainted with MQ Java API for sending/receiving messages. To begin, we'll
start with remote client connections to MQ that don't require an MQ installation
at the client-end.

Setting up an MQ infrastructure

Before we start, we need to create all the necessary MQ objects like the Queue
Manager (QM), local queues, TCP listener and server connection channel. We'll
create a Queue Manager (QM) called 'PCQ' and define a local queue by the name
'IN' to which a remote application will connect and send messages. The control
and MQ Script Commands in the adjacent image (MQSC) will create all prerequisite
MQ objects.

You can run the crtmqm, strmqm and runmqsc commands on command console to create basic MQ objects.

After running these MQ script commands, we'll have the basic objects ready to
be utilized. Starting with version 6, MQ explorer provides a UI view of MQ
objects.

Defining the Server Connection Channel

In order to connect to a Queue Manager (QM) remotely, we need to create a
Message Queue Interface (MQI) channel. An MQI channel connects a client
application to a queue manager. Under this configuration, clients don't have a
queue manager installed. It's also bi-directional, which means we don't need to
create separate sender-receiver channel pairs. But, before we do that, we also
need to create a TCP listener for listening to client requests. We'll create a
TCP listener for remote client connections on an unused port number. Next, we'll
create a bi-directional MQI channel.

Defining a TCP Listener on an unused port.

Programming the client

For client connections, it's necessary to set appropriate MQEnvironment
variables before connecting to a queue manager. For example, consider the code
fragment presented below which establishes a connection with a queue manger:

public void connectToQueueManager(){

try{

//setup MQ env

MQEnvironment.hostname=" 192.168.1.43";

MQEnvironment.channel="CLIENT.PCQ";

MQEnvironment.port=4444;

// MQEnvironment.userID="";

// MQEnvironment.password="";

qmgr=new MQQueueManager(queueMgrName);

} catch(MQException e) {

e.printStackTrace();

}

}

The hostname property identifies the server machine which hosts MQ server.
Port number on which the server is listening is identified by the port property.
Note that the default value is 1414. Finally, the name of the server-connection
channel is identified by the channel property. We have provided a sample
application on forums.pcquest. com under current issue. It puts a message on the
local queue - IN. After the program is run, you'll notice that the Current queue
depth property of the IN queue will be incremented by 1.

Defining a bi-directional MQI channel.

Further, you can browse the message without deleting the same. The figure
below shows some key properties while the message is browsed.

Notice the 'Put application name' property which describes that the message
was put by the WebSphere MQ client program written in Java programming language.
The actual message is visible under the 'Message date' column.

Conclusion

MQ client connections can help achieve high performance and provide a cost
effective solution by eliminating the need for MQ installation and
administration. Moreover, the user doesn't need to run any MQ code.

As you can see, browsing through the message doesn't delete it from the queue.

Also, client applications can be developed in various other programming
languages like C, C++ and .NET. In the next issue, we'll explore the 'bindings'
connection for developing server side MQ applications.