IBM WebSphere MQ Bridge for HTTP (MA0Y) Tested

At the end of June IBM released the IBM WebSphere MQ Bridge for HTTP support pack. What it basically does is to bring an HTTP API, in a RESTful way, to WebSphere MQ.

MA0Y requires:

• An application server supporting J2EE Connector Architecture, version 1.5.
• WebSphere MQ J2EE Connector Architecture (JCA) resource adapter deployed and operational (included in IBM WebSphere MQ version 6.0.2.1)

An WebSphere MQ resource adapter support statement can be found here.

The MA0Y support pack includes two downloads:

• Install
  • includes the WMQHTTP web application archive
• Samples
  • A pre-packaged IBM WebSphere Application Server Community Edition with WMQHTTP web application and WebSphere MQ J2EEConnectorArchitecture (JCA) resource adapter
  • A client samle application called P2PConsole.
  • Deployment plans for IBM Webphere Application Server Community Edition (applicable to Geronimo as well)

Get going with the samles download

• Download and extract from the support pack site
• Verify that you have a local queue manager set up named HTTP.QM
• Navigate to the ma0y.samples\WASCE\bin directory and execute startup.bat
• Navigate to the ma0y.samples\P2PConsole directory
• Run this command java -cp . HTTPPOST SYSTEM.DEFAULT.LOCAL.QUEUE localhost:8080 mq to put a message onto the SYSTEM.DEFAULT.LOCAL.QUEUE on queue manager HTTP.QM.
• Run this command to get (an WMQ get, not HTTP get) messages of the queue java -cp . HTTPDELETE SYSTEM.DEFAULT.LOCAL.QUEUE localhost:8080 mq.

Get going with a clean Geronimo and curl

• Verify that the queue manager HTTP.QM is started on your system.
• Download Geronimo 1.1.1 from here, extract the archive.
• Start Geronimo
  • Open a command window in GERONIMO_HOME\bin
  • Issue this command: SET JAVA_HOME=PATH_TO_IBM_JAVA. Substitute PATH_TO_IBM_JAVA with a path to an existing IBM Java 1.5 runtime (one is included in the samples package explained above). Using a Sun Java runtime will fail, see the Using JCA article at the IBM site.
  • Execute startup.bat
  • Geronimo is now started.
• Deploy the WebSphere MQ J2EEConnectorArchitecture (JCA) resource adapter
  • Open the Geronimo Console by pointing your favourite browser to http://localhost:8080/console, log in using system/manager.
  • Open Console Navigation > Applications > Deploy New
    • Archive: WMQ_HOME\Java\lib\jca\wmq.jmsra.rar
    • Plan: ma0y.samples\deployedFiles\WASCEPlans\geronimo-ra.xml
    • Click Install
• Deploy the WMQHTTP web application archive
  • Open the Geronimo Console by pointing your favourite browser to http://localhost:8080/console, log in using system/manager.
  • Open Console Navigation > Applications > Deploy New
    • Archive: ma0y.samples\deployedFiles\WMQHTTP.war
    • Plan: ma0y.samples\deployedFiles\WASCEPlans\geronimo-web.xml (if you use the geronimo jetty bundle replace tomcat with jetty within the file)
    • Click Install
• Start testing
  • Download curl from the curl site, I used this version: curl-7.16.4-win32-ssl-sspi.zip. Extract and navigate to the directory.
  • To PUT a message on a queue
    • curl –data “Hello World” –header “Content-Type: text/plain” –verbose http://localhost:8080/mq/msg/queue/SYSTEM.DEFAULT.LOCAL.QUEUE
  • To BROWSE the first message in the queue
    • curl –get –verbose http://localhost:8080/mq/msg/queue/SYSTEM.DEFAULT.LOCAL.QUEUE
  • To GET a message off a queue
    • curl –request DELETE –verbose http://localhost:8080/mq/msg/queue/SYSTEM.DEFAULT.LOCAL.QUEUE

Colclusion

• Works like a charm (except for the IBM Java runtime dependency)
• Not yet supported (Category 2 support pack), but most likely will be in the near future.
• Heavy-weigh, needs an application server and resource adapter.

Filed under: ibm, MA0Y, mq, support pack, wmq

New version of RFHUTIL (IH03) supports SSL connections

Today a new release of the IH03: WebSphere Message Broker V6-Message display, test & performance utilities support pack was released (more commonly known as RFHUTIL).

The most interesting and important feature for me in my day to day work was the introcuced SSL capabilities. RFHUTIL now works as you would expect from a native WebSPhere MQ client application, reading the MQSSLKEYR environment variable to locate the keystore.

I used a script like this to connect to a remote queue manager using a server connection channel with a NULL_SHA SSL configuration:

@echo off

set RFHUTIL_HOME=”%cd%”

set SVRCONN=CLIENTS.ADMIN
set HOST=10.10.10.10
set PORT=1414

set MQSSLKEYR=C:\ih03\ssl\key

set MQSERVER=%SVRCONN%/TCP/%HOST%(%PORT%)

%RFHUTIL_HOME%\rfhutilc.exe

The keystore is named key.kdb and is stored together with stash and the other related files in the c:\ih03\ssl\ folder.

I used these settings in the “Set Connection User Id” dialog (click the Set Conn Id button to open):

Be sure to select the correct settings from the Queue Manager Name drop-down list.

This will enable the usage of IH03 in in environments with SSL security requirements, a really good thing!

Filed under: ibm, ih03, mq, rfhutil, support pack, tool, websphere, wmq

WMQ Explorer and SSL

A couple of fixpacks ago I tested to connect to a remote queue manager sing a SSL configured server connection channel. Then things didn’t work out that well, but now a couple of refresh/fixpacks later everything wors much better.

To start with I must say that I don’t really fancy the way SSL is enabled from the WMQ Explorer point of view. The keystore parts of the configuration is ok but to connect to a queue manager using SSL you need to provide the WMQ Explorer with client channel definition table (CCDT).

For those of you not familiar with CCDT: it’s basically a binary format where an MQ server can store it’s client connections. Client connections in turn is data needed to connect to a queue manager in a client mode (includes parameters as connection, ssl etc). The CCDT file can be distributed to clients who can use it as the basis for their connection. As the CCDT file is binary there is no easy way to create it by hand. Running runmqsc on a WebSphere MQ server box will make it possible to create the CCDT but that is a bit heavy-weight in my opinion. The best aproach I’ve found so far is to use the MO72: MQSC Client for WebSphere MQ support pack by Paul Clarke.

MO72 has the follwing features (among others):

• Running mqsc on remote queue managers (inclusing WebSphere MQ security using SSL)
• Creating/altering/deleting client connections
• Can use the configuration file of the MO71 support pack

To create a CCDT from scratch using MO72 run the following command:

mqsc -n -t c:\AMQCLCHL.TAB

to add a client connection channel issue a define script:

DEFINE CHANNEL('CLIENTS.ADMIN') CHLTYPE(CLNTCONN) CONNAME('11.111.1.111(1414)') MAXMSGL(104857600) QMNAME('QM1') SSLCIPH('NULL_SHA') TRPTYPE(TCP) REPLACE

This CCDT assumes that there are a server connection channel named CLIENTS.ADMIN defined in the queue manager listening on port 1414 and host 11.111.1.111 with the rest of the properties in the client connection channel also defined in the server connection channel.

To gain access to the remote queue manager using SSL:

• The key and truststores need to be configured (Window -> Preferences -> WebSphere MQ Explorer -> SSL Client Certificate Stores)
• Add the queue manager
  • Right-click on Queue Managers -> Select “Show Hide Queue Managers” -> Click Add
  • Choose “Connect” and fill in the name of the queue manager, click Next
  • Choose “Use client channel definition table, and browse for the CCDT file, click Finish

Mission accomplished, SSL now works as a charm.

But why was this implemented using CCDT’s? I can’t see any reason really. I would like to see something like a custom SSLSocketFactory implemented in WebSphere MQ Explorer making it possible to use multiple key and trust stores and easier configuration on top of that. An example of an custom SSLSocketFactory was published by Peter Broadhurst on the a Hursley view on WebSphere MQ blog a couple of months ago.

Perhaps I’ll send in a proposal/requirement to get this configuration more simple and understandable.

Filed under: ibm, MO72, mq, support pack, websphere, wmq

Great post on MQMON (support pack)

In a previous post of mine is promised to get back to the details of the new version of the MQMON support pack. That hasn’t happened, as you might have noticed, but luckily someone else has 😉

The a Hursley view on WebSphere MQ blog, has an interesting  post on the HTTP capabilities of the MQMON support pack.

Filed under: mo71, mq, mqmon, support pack, websphere, wmq

IS02 in WebSphere MQ clustered environment

In my current assignment I’m architecting “a version two” of my customers corporate ESB.

These core components that make up the actual ESB runtime:

1. WebSphere Message Broker 6.0.0.3
2. WebSphere MQ 6.0.2.1

As a part of the architectural work I needed to look into the management possibilities of the components. I’ve been working with both WMQ 5.3 and WBIMB 5.0 before but newer the 6.0’s.

What I wanted to do, if possible, was to use the IS02 support pack in favor the WebSphere Message Broker Toolkit to administer the broker domains. The Toolkit is based on Eclipse and includes both administration and development capabilities (a huge overhead for pure operational tasks).

The runtime setup as follows (BK=Broker, CM=Configuration Manager, QM=Queue Manager):

• Server1: BK1/QM1 + CM/QM2
• Server2: BK2/QM3
• QM1, QM2 and QM3 is part of Cluster1

Objectives: Use IS02 to connect to CM (through QM2) and administer BK1 and BK2 from Workstation1.

Result:

IS02 (v2 – the current one) doesn’t work in a clustered environment (one without XMIT queues and sender/receiver (non-cluster) channels. The senders (QM2 to QM1 and QM2 to QM3) channel is needed on QM2 for the tooling to display the brokers. The receiver corresponding receiver channels are needed to administer the brokers (sending messages basically)

Well, I set up the XMIT’s and channel’s and tried again. The brokers and configuration manager is nicely shown in the IS02 eclipse plugin. You can do the things you can expect like deploying (to multiple execution groups “concurrently”) , starting,  stopping and removing flows etc.

Still some things doesn’t work as expected:

• Message Set’s can be removed from a broker but that isn’t reflected in the UI (need restart)
• The configuration to connect to the Configuration Manager vanish the moment the Eclipse environment is restarted.

Based on what I’ve heard at IBM the problems should hopefully be fixed in the upcoming release.

Filed under: ibm, is02, mq, support pack, wmb, wmq