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.