Connecting to external information sources with WebSphere MQ

This article shows you how to use WebSphere MQ to connect internal business applications to external information sources without the complexity of getting access to corporate firewalls.

Share:

Yi Min Yue (yueyimin@cn.ibm.com), Staff Software Engineer, IBM

Yi Min Yue is a Staff Software Engineer and Software Services Specialist on the Lab-based Services team at the IBM China Software Development Lab in Beijing. He has extensive experience with WebSphere business integration products, including designing and implementing WebSphere Message Broker and WebSphere MQ solutions at customer sites. You can contact Yi Min Yue at yueyimin@cn.ibm.com.



Dr. Zhong Tian (tianz@cn.ibm.com), Senior Architect, IBM

Zhong Tian is a senior architect at Lab Based Services at the IBM China Development Lab. He received a Ph.D. in computer science from FuDan University in 1995. Much of his customer experience is with large manufacturing, banking and transportation industry solution design and development. He has worked in the area of SOA, business process modeling and integration and e-commerce. Dr. Tian is leading architect for solution development at China Development Lab.



Chuan Xu, Software Engineer, Lab-based Services team, IBM

Chuan Xu is a Software Engineer on the Lab-based Services team at the IBM China Software Development Lab in Beijing. You can contact Chuan Xu at xuchuan@cn.ibm.com.



01 November 2006

Introduction

IBM® WebSphere® MQ (hereafter called "MQ") is often used to provide a secure, reliable, and scaleable connection between information providers and information consumers. This article shows you how to use MQ to connect internal business applications to external information sources. Users should have some knowledge of MQ. The article has three sections:

  • Scenario -- Describes a scenario about interaction between two business applications, and then provides a high-level descriptions of product used in addressing the scenario.
  • Solution -- Gives a detailed description of the solution.
  • Implementation -- Shows you step-by-step how to set up and implement the solution.

Scenario

Internet technologies enable enterprises to reach customers anywhere and connect to business partners wherever they are. Often, an enterprise needs to provide external interfaces over the Internet so that existing and new business partners and customers can access controlled areas of internal systems. As an enterprise moves further into on-demand world, they usually need to increase the number of internal applications accessible to partners and customers. Yet at the same time, rapidly increasing security concerns such as Internet fraud and malware attacks are driving enterprises in the other direction -- to strengthen firewalls and strictly regulate resources that can go in a demilitarized zone (DMZ) in the firewall domain. (A DMZ is a neutral zone between a company's internal private network and the Internet or another outside public network, and it can provide an IP address visible to external users.)

Figure 1 below shows the scenario of a typical departmental business application in Company ABC that needs a constant, secure, and reliable data feed from Company XYZ, which is a well established information provider. The Company ABC server that runs the application in has a private IP address, and the Company XYZ server that provides the information has a public IP address. Because of security, budget, and operations considerations, Company ABC is reluctant to put the Company XYZ application into their DMZ.

MQ bridges applications in different network domains through a standardized messaging interface. It provides reliable communication regardless of the complexity of the infrastructure connecting the nodes in the system. MQ runs on a wide variety of platforms:

Figure 1. Scenario
Figure 1. Scenario

Products used

WebSphere MQ

MQ is a message-queuing product and the leading product in the message-oriented middleware (MOM) marketplace, with market-leading messaging and queuing technology. MQ speeds implementation of distributed applications by simplifying the task of connecting applications across heterogeneous environments. Applications communicate using the MQ APIs, which give users a choice of APIs ranging from the traditional Message Queue Interface to the standards-based Java™ Messaging Service (JMS) interface. These APIs provide an easy-to-use, high-level interface that shields programmers from the complexities of different operating systems and underlying networks, so that they can focus is on business logic while MQ manages connections between applications and systems. By using MQ, developers can move or extend application code onto nodes with different underlying infrastructure components, greatly simplifying development efforts

WebSphere MQ Internet Pass-Thru (MQIPT)

MQIPT is an extension to the base MQ product that can be used to implement messaging solutions between remote sites across the Internet. MQIPT runs as a standalone service that can receive and forward MQ message flows, either between two MQ queue managers, or between an MQ client and an MQ queue manager. MQIPT enables this connection when the client and server are on different physical networks. MQIPT lets two MQ systems exchange messages without the need for a direct TCP/IP connection between them. MQIPT listens on one or more TCP/IP ports for incoming connections, which can carry either normal MQ messages, MQ messages tunneled inside HTTP, or messages that are encrypted using Secure Sockets Layer (SSL).

Solution

A Virtual Private Network (VPN) is an extension of an enterprise's private intranet across the Internet or other public network. It creates a secure, private "tunnel" through the Internet to a business partner or customer. In our scenario, we could set up VPN services in either Company ABC or Company XYZ to enable private communication over the public network. However, several issues need to be considered:

  • Security -- Security issues in letting a service provider join the company intranet.
  • Cost -- The cost of setting up and maintaining VPN services.
  • Reliability -- If a VPN goes down, messages will not be able to reach their destinations. Therefore companies often require "always-on" 24x7 VPN services.

The next section describes how to set up an MQ connection to meet the scenario requirements without using VPN services.

Solution overview

This section focuses on how to set up an MQ connection between two MQ servers to implement the requirements. Figure 2 shows the rough topology of the solution:

Figure 2. Physical description
Figure 2. Physical description

The solution involves an MQ server to MQ server connection for messages from Company XYZ to Company ABC. In Company XYZ, an MQIPT in the DMZ enables the MQ server to remain behind the firewall. MQIPT is in the DMZ.

We will set up WebSphere MQ SSL to build secure communication for your reference, but message security is not the focus of this article. Figure 3 shows an overview of the solution:

Figure 3. Logical description
Figure 3. Logical description

You set up the Requester/Server channel using SSL as well. Requester side (MQ Server in Company ABC) can start the channel, and then receive message from Server side (MQ Server in Company XYZ). The Server side (MQ Server in Company XYZ) sends messages to the Requester (MQ Server in Company ABC) from the transmission queue.

Setting up channel

Selecting channel pairing

All network communication in MQ is performed across a channel. Message channels carry messages from one queue manager to another. Possible combinations are:

  • Sender-receiver
  • Requester-server
  • Requester-sender
  • Server-receiver
  • Cluster sender-cluster receiver

Sender-receiver is the most common channel pairing: a sender in one system starts the channel so that it can send messages to the other system. The sender requests the receiver at the other end of the channel to start, and the sender sends messages from its transmission queue to the receiver. The receiver then puts the messages on the destination queue.

Figure 4. Sender-receiver channel
Figure 4. Sender-receiver channel

Sender-receiver channel can only be initiated from the sender side. The direction of channel initiation is the same as the direction of message flow -- from sender side to receiver side. There must be a known IP address for the sender side to connect, so the sender-receiver channel is not available for our business scenario.

The server-requester channel is shown below. A requester in one system starts the channel so that it can receive messages from the other system. The requester requests the server at the other end of the channel to start, and the server then sends messages to the requester from the transmission queue defined in its channel definition:

Figure 5. Server-requester channel
Figure 5. Server-requester channel

The server-requester can be initiated from the requester side, or from the server side if that server is fully qualified with a connection name. However, when a server wants to initiate the communication, it must have the connection name defined, meaning that there must be a visible IP address on the requester side. In our scenario, we define the MQ Server of Company ABC as the requester side and Company XYZ as the server side. Because company ABC without a DMZ area has no visible Internet IP address outside, only requester side (Company ABC) can initiate communication and the message will be transferred from the server side (Company XYZ) to the requester side (Company ABC).

Keeping the channel alive

The connection that we are setting up is based on Internet technologies, and therefore to offer high quality of services, it is important to keep channel running. Message channels are not automatically restarted by MQ after a queue manager is restarted or when they become inactive after reaching their disconnect interval. Manually starting channels using MQSC or WebSphere MQ Explorer is not an efficient mechanism in an infrastructure of interconnected queue managers.

A transmission queue is a special type of local queue used to store messages temporarily before they are transmitted by the MCA to the remote queue manager. In a distributed-queuing environment, you need to define one transmission queue for each sending MCA. A transmission queue may be defined as a triggered queue. When a message arrives on a transmission queue that satisfies the triggering criteria for that queue, a message is sent to the initiation queue, triggering the channel initiator to start the appropriate sender MCA. This means that channels can be started automatically, based on messages arriving on the appropriate transmission queue. However, for our scenario, the requester side that has no transmission queue initiates the communication.

Here we would use WebSphere MQ Programmable Command Formats (PCF) to code for triggering the requester-server channel on the requester side. You can create a simple Java thread to monitor requester-server channel status. When the channel status is not running, the channel should be started automatically.

Setting up MQIPT

MQIPT runs as a standalone service that can receive and forward MQ message flows, either between two MQ queue managers or between an MQ client and an MQ queue manager. MQIPT enables this connection when the servers are not on the same physical network.

Here MQIPT was placed in the DMZ of Company XYZ on a machine with a known and trusted IP address. MQIPT can be used to listen for incoming MQ channel connections from Company ABC, and then forward to the trusted intranet. The inner firewall must let this trusted machine make inbound connections. In this configuration, MQIPT provides a single point of access and prevents external requests for access from seeing the true IP addresses of the machines in the trusted intranet.

In our scenario, MQIPT acts as an MQ protocol forwarder. It listens on a TCP/IP port and accepts connection requests from MQ channels. If a well-formed request is received, MQIPT establishes a further TCP/IP connection between itself and the destination MQ queue manager. It then passes all protocol packets it receives from its incoming connection to the destination queue manager, and returns protocol packets from the destination queue manager back on the original incoming connection.

To use MQIPT, the caller channel (Company ABC) must be configured to use the hostname and port of MQIPT, not the hostname and port of the destination queue manager. MQIPT does not examine the channel name; it is simply passed through to the receiving queue manager.

MQIPT verifies that the messages it receives and transmits are valid and conform to the MQ protocol, which helps prevent MQIPT from being used for security attacks outside of the MQ protocol. MQIPT lets you restrict the total number of incoming connections, which helps protect a vulnerable internal queue manager from denial-of-service attacks. You must protect the configuration file of MQIPT, mqipt.conf, because this file controls access to the internal hosts, and you must prevent unauthorized access to the command port (if it is enabled), because such access allows an external agent to shut down MQIPT

MQ SSL enablement

To build a secure communication, we used the security model provided by MQ, which lets you secure channels of all types using SSL. You can use SSL to provide authentication of the identity of a remote application or queue manager, and to assure confidentiality and data integrity for the communication link after it is established.

Implementation

Assumptions

Figure 6. MQ connection
Figure 6. MQ connection
  • Platform: Microsoft® Windows® XP
  • MQ Server (Company XYZ intranet)
    • Host name (Intranet IP address): biz.xyz.com
    • Queue manager name: QM_XYZ
    • MQ installation directory: C:\MQ6
    • Server channel name: XYZ.TO.ABC
    • Transmission queue: QM_ABC
    • Remote queue: QR
    • MQ CCSID: 1208
    • Listener port: 14001
  • MQ IPT (DMZ in Company XYZ)
    • Internet IP address: 202.10.0.1
    • Listener port: 14000
  • MQ server (Company ABC Internet)
    • Queue manager name: QM_ABC
    • MQ installation directory: C:\MQ6
    • Requester channel name: XYZ.TO.ABC
    • Local queue: QL
    • MQ CCSID: 1208

Change parameters such as intranet IP address, Internet IP address, and port number for your environment.

Build MQ server/server connection

MQ server setup in Company XYZ

  1. Create Queue Manager (QM_XYZ)
    crtmqm QM_XYZ
  2. Start Queue Manager (QM_XYZ)
    strmqm QM_XYZ
  3. Create transmission queue (QM_ABC)
    runmqsc QM_XYZ
    def ql(QM_ABC) usage(xmitq)
    end
  4. Create remote queue (QR)
    runmqsc QM_XYZ
    def qr(QR) RNAME(QL) RQMNAME(QM_ABC) XMITQ(QM_ABC)
    end
  5. Create Server Channel (XYZ.TO.ABC)
    runmqsc QM_XYZ
    def chl(XYZ.TO.ABC) chltype(SVR) XMITQ(QM_ABC) DISCINT(0)
    end
  6. Create Listener Port (14001)
    runmqsc QM_XYZ
    def LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(14001) CONTROL(QMGR)
    start LISTENER('LISTENER.TCP')
    end
  7. Alter MQ CCSID (1208)
    runmqsc QM_XYZ
    alter qmgr ccsid(1208)
    end
    endmqm -w QM_XYZ
    strmqm QM_XYZ

MQ server setup in Company ABC

  1. Create Queue Manager (QM_ABC):
    crtmqm QM_ABC
  2. Start Queue Manager (QM_ABC):
    strmqm QM_ABC
  3. Create local queue (QL):
    runmqsc QM_ABC
    def ql(QL)
    end
  4. Create Requester Channel (XYZ.TO.ABC):
    runmqsc QM_ABC
    def chl(XYZ.TO.ABC) chltype(RQSTR) CONNAME('202.10.0.1(14000)')
    end

    Change parameter CONNAME according to your environment.
  5. Alter MQ CCSID (1208):
    runmqsc QM_ABC
    alter qmgr ccsid(1208)
    end
    endmqm -w QM_ABC
    strmqm QM_ABC

SSL enablement (optional)

MQ server SSL configuration in Company XYZ

  1. Set up a new key repository:
    cmd>runmqckm -keydb -create -db C:\MQ6\Qmgrs\QM_XYZ\ssl\QMXYZKEY -pw passw0rd -type cms 
    -expire 3650 -stash
  2. Change the key repository location for a queue manager:
    runmqsc QM_XYZ
    alter qmgr sslkeyr('C:\MQ6\Qmgrs\QM_XYZ\ssl\QMXYZKEY')
    end
  3. Specify CipherSpecs for server channel:
    runmqsc QM_XYZ
    alter chl(XYZ.TO.ABC) chltype(SVR) SSLCIPH('RC4_MD5_EXPORT')
    end
  4. Create a self-signed personal certificate in the key repository:
    cmd>runmqckm -cert -create -db C:\MQ6\Qmgrs\QM_XYZ\ssl\QMXYZKEY.kdb -pw passw0rd 
    -label ibmwebspheremqqm_xyz -dn "CN=QMGR.QM_XYZ, O=IBM, C=CN" -size 1024 
    -x509version 3 -expire 3650

    The key label field must be in the correct MQ format for a queue manager: ibmwebspheremq followed by the name of your queue manager in lowercase.
  5. Extract MQ Server CA certificate:
    cmd>runmqckm -cert -extract -db C:\MQ6\Qmgrs\QM_XYZ\ssl\QMXYZKEY.kdb -pw passw0rd 
    -label ibmwebspheremqqm_xyz -target C:\MQ6\Qmgrs\QM_XYZ\ssl\ibmwebspheremqqm_xyz.der 
    -format binary

MQ server SSL configuration in Company ABC

  1. Set up a new key repository:
    cmd>runmqckm -keydb -create -db C:\MQ6\Qmgrs\QM_ABC\ssl\QMABCKEY -pw passw0rd -type cms 
    -expire 3650 -stash
  2. Change the key repository location for a queue manager:
    runmqsc QM_ABC
    alter qmgr sslkeyr('C:\MQ6\Qmgrs\QM_ABC\ssl\QMABCKEY')
    end
  3. Specify CipherSpecs for server channel:
    runmqsc QM_ABC
    alter chl(XYZ.TO.ABC) chltype(RQSTR) SSLCIPH('RC4_MD5_EXPORT')
    end
  4. Create a self-signed personal certificate in the key repository:
    cmd>runmqckm -cert -create -db C:\MQ6\Qmgrs\QM_ABC\ssl\QMABCKEY.kdb -pw passw0rd 
    -label ibmwebspheremqqm_abc -dn "CN=QMGR.QM_ABC, O=IBM, C=CN" -size 1024 
    -x509version 3 -expire 3650

    The key label field must be in the correct MQ format for a queue manager: ibmwebspheremq followed by the name of your queue manager in lowercase.
  5. Extract MQ Server CA certificate:
    cmd>runmqckm -cert -extract -db C:\MQ6\Qmgrs\QM_ABC\ssl\QMABCKEY.kdb -pw passw0rd 
    -label ibmwebspheremqqm_abc -target C:\MQ6\Qmgrs\QM_ABC\ssl\ibmwebspheremqqm_abc.der 
    -format binary

Certificate exchange

  1. Copy CA certificate:
    • For MQ Server in Company XYZ, copy CA certificate ibmwebspheremqqm_abc.der of MQ Server in Company ABC to C:\MQ6\qmgrs\QM_XYZ\ssl\.
    • For MQ Server in Company ABC, copy CA certificate ibmwebspheremqqm_xyz.der of MQ Server in Company XYZ to C:\MQ6\qmgrs\QM_ABC\ssl\.
  2. Add MQ Server CA certificate (Company ABC) into MQ Server (Company XYZ):
    cmd>runmqckm -cert -add -db C:\MQ6\Qmgrs\QM_XYZ\ssl\QMXYZKEY.kdb -pw passw0rd 
    -label ibmwebspheremqqm_abc -file C:\MQ6\Qmgrs\QM_XYZ\ssl\ibmwebspheremqqm_abc.der 
    -format binary
  3. Add MQ Server CA certificate (Company XYZ) into MQ Server (Company ABC):
    cmd>runmqckm -cert -add -db C:\MQ6\Qmgrs\QM_ABC\ssl\QMABCKEY.kdb -pw passw0rd 
    -label ibmwebspheremqqm_xyz -file C:\MQ6\Qmgrs\QM_ABC\ssl\ibmwebspheremqqm_xyz.der 
    -format binary

Setting up MQIPT (DMZ in Company XYZ)

Installing Internet pass-thru on Windows

You must have Administrator authority when you install MQIPT.

  1. Download MQIPT (MS81) from the WebSphere MQ SupportPac page.
  2. Unpack ms81_nt.zip into a temporary directory.
  3. Run setup.exe and follow the online instructions.

Setting up Internet pass-thru

  1. In the mqipt installation directory, copy the sample configuration file mqiptSample.conf to mqipt.conf.
  2. Edit mqipt.conf and delete all routes
  3. Set route info for your MQ Server:
    1. Set ListenerPort to the port number on which the route should listen for incoming requests (14000).
    2. Set Destination to the hostname (or dotted decimal IP address) of your queue manager (biz.xyz.com). You should change it according to your environment.
    3. Set DestinationPort address to the one used by your queue manager (14001)
    4. Set SSLProxyMode to true when MQ SSL is enabled.
  4. Here is a sample mqipt.conf for your reference:
    [global]
    CommandPort=1881
    RemoteShutDown=true
    MinConnectionThreads=5
    MaxConnectionThreads=100
    IdleTimeout=20
    ClientAccess=true
    QMgrAccess=true
    HTTP=false
    HTTPChunking=false
    Trace=0
    ConnectionLog=true
    MaxLogFileSize=50
    AccessPW=MQIPT
    
    [route]
    Name=ABC Route Info
    ListenerPort=14000
    Destination=biz.xyz.com
    DestinationPort=14001
    SSLProxyMode=true

Starting Internet pass-thru from the command line

  1. Open a command prompt
  2. Change directory to mqipt bin directory and run mqipt.
  3. The following message indicates successful completion:
    5639-L92 (C) Copyright IBM Corp. 2000, 2003 All Rights Reserved
    MQCPI001 WebSphere MQ internet pass-thru Version 1.3.3 starting
    MQCPI004 Reading configuration information from C:\mqipt\mqipt.conf
    MQCPI011 The path C:\mqipt\logs will be used to store the log files
    MQCPI006 Route 14000 has started and will forward messages to :
    MQCPI034 ....itl.lagaude.ibm.com (14001)
    MQCPI035 ....using MQ protocols
    MQCPI078 Route 14000 ready for connection requests

Starting Requester/Server channel

In the Company ABC side, start MQ Requester/Server channel:

runmqsc QM_ABC
start chl(XYZ.TO.ABC)
end

The channel status should be running so that Company XYZ can provide services to Company ABC by throughputting message to Remote Queue (QR). Company ABC will get the message from Local Queue (QL) and process it.

Keeping channel alive

We use the MQ Programmable Command Format (PCF) to trigger the MQ channel:

Figure 7. Keeping channel alive
Figure 7. Keeping channel alive
  1. A thread monitors the channel status. If the channel is not running, start the channel using the MQ PCF API. Another way to determine whether the channel should be re-started is to use the MQ queue statistic function: when there is no new message put into the queue in a certain interval, restart the channel.
  2. First, define MQ object in MQ_ABC for triggering:
    • Listener Port 14003:
      runmqsc QM_ABC
      def LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(14003) CONTROL(QMGR)
      start LISTENER('LISTENER.TCP')
      end
    • Server Connection Channel SVRCONN_ABC:
      runmqsc QM_ABC
      def chl(SVRCONN_ABC) chltype(SVRCONN)
      end
  3. A configuration file defines the properties needed to connect Queue Manager (QM_ABC). Change these parameters according to your environment:
    QueueManager=QM_ABC
    HostName=biz.abc.com
    MQCCSID=1208
    ListeningPort=14003
    ServerConnectionChl=SVRCONN_ABC
    RequesterChl=XYZ.TO.ABC
    CheckInterval=60
  4. Define Class ChannelMonitor. You need to generate a getter/setter method for each private variable:
    public class ChannelMonitor extends Thread {
     /*
      * Name of Queue Manage
      **/
      private String queueManagerName = null;
     /*
      * Monitoring Interval
      **/
      private int interval;
     /*
      * Host Name or IP Address of Queue Manager for Connecting
      **/
      private String hostName = null;
     /*
      * Listener Port of Queue Manager for Connecting
      **/
      private int port;
     /*
      * Server Connection Channel of Queue Manager for Connecting
      **/
      private String serverConnChl = null;
     /*
      * CCSID of Queue Manager for Connecting
      **/
      private int ccsid;
     /*
      * Requester Channel of Queue Manager to be Monitored/Triggered
      **/
      private String requesterChl = null;
      public ChannelMonitor() {
      }
    }
  5. Define method for checking channel status:
    private boolean isChannelRunning() throws Exception {
        PCFMessageAgent agent = null;
        PCFMessage request;
        PCFMessage[] responses;
        // build a request
        request = new PCFMessage(CMQCFC.MQCMD_INQUIRE_CHANNEL_STATUS);
        // add a parameter designating the name of the channel for which status is requested
        request.addParameter(CMQCFC.MQCACH_CHANNEL_NAME, getRequesterChl());
        // add a parameter designating the instance type (current) desired
        request.addParameter(CMQCFC.MQIACH_CHANNEL_INSTANCE_TYPE, CMQC.MQOT_CURRENT_CHANNEL);
        // add a parameter designating the attributes desired
        int[] attrs = { CMQCFC.MQCACH_CHANNEL_NAME, CMQCFC.MQCACH_CONNECTION_NAME, 
            CMQCFC.MQIACH_MSGS, CMQCFC.MQCACH_LAST_MSG_DATE, 
            CMQCFC.MQCACH_LAST_MSG_TIME, CMQCFC.MQIACH_CHANNEL_STATUS };
        // add the parameter for these attributes
        request.addParameter(CMQCFC.MQIACH_CHANNEL_INSTANCE_ATTRS, attrs);
        try {
            // connect to the queue manager using the PCFMessageAgent
            agent = new PCFMessageAgent();
            agent.setCharacterSet(getCcsid());
            agent.connect(getHostName(), getPort(), getServerConnChl());
            // send the request and collect the responses
            responses = agent.send(request);
            if (responses != null && responses.length > 0){
              int chlStatus = responses[0].getIntParameterValue(CMQCFC.MQIACH_CHANNEL_STATUS);
              if (chlStatus == CMQCFC.MQCHS_RUNNING) {
                  return true;
              }
            }
         } catch (PCFException pcfEx) {
            System.out.println("PCF Exception during checking channel status!!");
            pcfEx.printStackTrace();
         } catch (Exception ex) {
            ex.printStackTrace();
            throw ex;
         } finally {
            if (agent != null) {
                agent.disconnect();
            }
         }
         return false;
    }
  6. Define method for starting channel:
    private void startingChannel() throws Exception {
        PCFMessageAgent agent = null;
        PCFMessage request;
        PCFMessage[] responses;
        // build a request
        request = new PCFMessage(CMQCFC.MQCMD_START_CHANNEL);
        // add a parameter designating the name of the channel
        request.addParameter(CMQCFC.MQCACH_CHANNEL_NAME, getRequesterChl());
        try {
            // connect to the queue manager using the PCFMessageAgent
            agent = new PCFMessageAgent();
            agent.setCharacterSet(getCcsid());
            agent.connect(getHostName(), getPort(), getServerConnChl());
            // send the request and collect the responses
            responses = agent.send(request);
        } catch (PCFException pcfEx) {
            System.out.println("PCF Exception during starting channel!!");
            pcfEx.printStackTrace();
        } catch (Exception ex) {
            ex.printStackTrace();
            throw ex;
        } finally {
            if (agent != null) {
               agent.disconnect();
            }
        }
    }
  7. Override the run method of class Thread:
    public void run(){
      while (true) {
         try {
            if (!isChannelRunning()) {
              startingChannel();
            }
            sleep(getInterval() * 1000);
         } catch (Exception ex) {
            ex.printStackTrace();
         }
    }
  8. Define main method for starting Thread:
    public static void main(String[] args) {
      try {
         ChannelMonitor channelMonitor = new ChannelMonitor();
         //read configuration file and set MQ parameters.
         ...
         //start Thread
         channelMonitor.start();
       } catch (Exception e) {
         e.printStackTrace();
      }
    }

Conclusion

This article introduced a scenario involving interaction between two business applications, and showed you how to set up an MQ connection between MQ Server and MQ Server to enable communication without VPN services. The MQ Requester/Server channel pairing was selected to set up a connection on which the requester side can initiate communication and the message can be transferred from the server side to the requester side. At the same time, MQIPT was placed in the DMZ of the information provider to traverse the firewall. While security details were not covered, the article showed you how to enable MQ SSL.

Acknowledgements

The authors would like to thank the IBM China Development Lab Architecture Board and Associate Architecture Board for their constructive comments and help. We also express our appreciation to Stephen Todd, Jian Min Liu, and Hua Biao Xiao for their valuable ideas.

Resources

  • WebSphere MQ Internet Passthru V1.3
    This downloadable SupportPac, (also known as MQ IPT) is a WebSphere MQ base product extension that you can use to implement messaging solutions between remote sites across the Internet. It makes the passage of WebSphere MQ channel protocols into and out of a firewall simpler and more manageable, by tunnelling the protocols inside HTTP or by acting as a proxy.
  • WebSphere MQ V6 Fundamentals
    This IBM Redbook describes the fundamental concepts and benefits of message queuing technology, and its design-level overview and technical details can help improve design and implementation decisions for WebSphere MQ infrastructures and applications.
  • WebSphere MQ Intercommunication V6
    This book describes intercommunication between WebSphere MQ products. It introduces the concepts of intercommunication (transmission queues, message channel agent programs, and communication links) that are brought together to form message channels, which can link geographically-separated queue managers to form a network of queue managers.
  • Business-to-Business Integration Using MQ and MQSI Patterns for e-business
    This IBM Redbook is part of the "Patterns for e-business" series -- a group of proven, reusable assets that can help speed the process of developing applications. The patterns discussed in this book, Business-to-Business Integration Patterns 2 and 3, form the basis for many of the more complex and functional B2B patterns, and are relevant to all enterprises dealing with partner integration over the Internet.
  • WebSphere MQ Security in an Enterprise Environment
    This IBM Redbook describes some of the procedures and documentation required for WebSphere MQ enterprise security on the z/OS (zSeries), OS/400 (iSeries), IBM AIX (pSeries), and Windows 2000 (xSeries) platforms.
  • WebSphere MQ V6 Security
    This book describes the factors you need to consider when planning security for a WebSphere MQ environment. The book also describes the Secure Sockets Layer (SSL) support in WebSphere MQ..
  • WebSphere MQ developer resources page
    Technical resources to help you design, develop, and deploy messaging middleware with WebSphere MQ to integrate applications, Web services, and transactions on almost any platform.
  • WebSphere MQ product page
    Product descriptions, product news, training information, support information, and more.
  • WebSphere MQ V6 trial download
    A no-charge trial download of WebSphere MQ V6. Includes limited online support for Windows® and Linux® installations at no charge during the trial period.
  • WebSphere MQ V6 information center
    A single Eclipse-based Web portal to all WebSphere MQ V6 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere MQ environment.
  • WebSphere MQ documentation library
    WebSphere MQ product manuals.
  • WebSphere MQ SupportPacs
    Downloadable code, documentation, and performance reports for the WebSphere MQ family of products.
  • WebSphere MQ public newsgroup
    A non-IBM forum where you can get answers to your WebSphere MQ technical questions and share your WebSphere MQ knowledge with other users.
  • developerWorks WebSphere Business Integration zone
    For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
  • WebSphere Business Integration products page
    For both business and technical users, a handy overview of all WebSphere Business Integration products
  • WebSphere forums
    Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  • Most popular WebSphere trial downloads
    No-charge trial downloads for key WebSphere products.
  • Trial downloads for IBM software products
    No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
  • Safari Bookshelf: e-library designed for developers
    Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers.
  • developerWorks technical events and Webcasts
    Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
  • developerWorks blogs
    Ongoing, free-form columns by software experts, to which you can add your comments. Check out Grady Booch's blog on software architecture.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Architecture
ArticleID=172139
ArticleTitle=Connecting to external information sources with WebSphere MQ
publish-date=11012006