Enable Mutual SSL with WSO2 ESB and IBM MQ

This article will explain how to connect to an SSL enabled channel in MQ using WSO2 ESB. Here I’m using ESB version 4.8.1 and MQ 8.0.0.2 versions. Java version java 1.7.0-60 or above.

• First we have to import the MQ certificate to WSO2 ESB’s client trust store. You can import the certificate using the following command in keytool.
• ./keytool -import -file PATH_TO_MQ_CERTIFICATE/USU08QM2.cer -alias ALIAS_NAME_OF_MQ_CERTIFICATE -keystore PATH_TO_CLIENT_TRUST_STORE/client-truststore.jks -storepass password

• Then you have to export the certificate from wso2carbon.jks and import that to MQ keystore in MQ server. To export the certificate from wso2carbon.jks use the following command in keytool.

•  ./keytool -export -keystore PATH_TO_KEY_STORE/wso2carbon.jks -storepass KEY_SOTRE_PASSWORD -alias ALIAS_NAME_OF_WSO2_KEY_STORE -file PATH_TO_STORE_THE_CERTIFICATE/wso2esb.cer

•  Then this certificate should be should be imported to MQ JKS using the command listed in step 1.

• Then you have to specify the matching cipher suite for ESB. In IBM MQ when SSL is enabled, they specify a cipher spec to the channel. You have to find the matching cipher suite for that cipher spec and specify it in ESB as an environment variable. Cipher spec to cipher suite mapping can be found in here. Environment variable can be set in ESB by setting the following propery in wso2server.sh file.
•  -DCMQC.SSL_CIPHER_SUITE_PROPERTY="SSL_RSA_WITH_3DES_EDE_CBC_SHA" \

• Note:Here I have specified the cipher suite as SSL_RSA_WITH_3DES_EDE_CBC_SHA. The matching cipher spec for this cipher suite is TLS_RSA_WITH_3DES_EDE_CBC_SHA.

• Next you have to copy MQ jta.jar to ESB_HOME/repository/components/lib folder. (Remove the old jar files if there are any existing ones). Make sure you copy MQ 8.0.0.2 jar files. The client jars in [1] is not working with SSL. Therefore you have to create a new OSGI bundle with new MQ 8.0.0.2 client jars. To do that you can clone the wmq-client-8.0.0.2 project from here and copy following jar files to lib folder in wmq-client-8.0.0.2/lib. Then build the project.
• com.ibm.mq.allclient.jar
• fscontext.jar
• jms.jar
• providerutil.jar

• Note: Copy the wmq-client-8.0.0.2.jar file in target directory to ESB_HOME/repository/components/dropins folder. Remove if there are any old jar files.

• Remove following line from <ESB_4.8.1_Home>\repository\conf\etc\launch.ini
• javax.jms,\

• Regenerate .bindings file with following property.
• Provider Version : 8

Then restart the server and then you are ready to go with SSL. !!!


[1] http://nandikajayawardana.blogspot.com/2015/03/configuring-ibm-mq-with-wso2-esb.html

WSO2 Message Broker 3.0.0 Slot Based Architecture

The major problem we had in MB 2.2.0 is that message copying from Global queues to Node queues and vice versa.  This consumes lots of time since each message goes through several database readings and writings before delivering.

As a solution to this problem slot based message delivery system was introduced to WSO2 MB 3.0.0. Slot is basically a chunk of messages in a message store which can only be owned by one node at a time. A queue is mapped to a row in message store and queue can be divided into several slots. Below diagram shows how slots are divided for a queue name foo. All the messages for the queue foo is stored in one row in message store.

Architecture

In new message delivery model slot manager acts as the coordinator of slot distribution among subscribers. Above use case diagram shows the services provided by the slot manager. At publisher’s side publisher returns its last message ID to slot manager after every 1000 messages (this value is configurable) or after a timeout. Slot manager keeps these IDs in a hazelcast distributed map and use it to generate slots when a subscriber asks.

At subscriber’s side, subscriber talks to slot manager at several times.

1. Get a slot

When a subscriber arrives, subscriber asks for a slot from slot manager. If there are free slots which are not allocated to any node, the slot manager returns a slot to subscriber node and update the slot assignment map . Slot assignment map is kept to trace currently assigned non-empty slots.

2. Delete slot

When all the messages read from slot are sent and all the acks are received, member node asks the slot manager to delete the slot. At slot manager’s side, when a slot delete call is triggered, slot manager removes the entry from slot assignment map.

3. Re-assign slot when last subscriber leaves

This method is called when the last subscriber of a particular node leaves the cluster. When this method is triggered, slot manager reassign the non-empty slots which were belonged to callee node, to free slots pool.

Other than these functions, when a member node leaves the cluster, slot manager reassign the non-empty slots which were belonged to the leaving node, to free slots pool.

Message Publishing

When publishing messages, a row in message store is dedicated to each queue. Row key is equal to queue name as shown in the image. All the publishers for that queue will store messages in that row.

Message Delivering

Message delivering is done by a thread known as Slot Delivery Worker(SDW). There can be more than one Slot Delivery Workers and each slot delivery worker is assigned with set of queues. Each slot delivery worker ask for a slot from slot manager when a subscriber arrives. If the slot delivery worker gets a non-empty slot, it reads all the messages in the slot in one row and deliver it to any subscriber in round robin manner. If a message delivery is failed or rejected those messages will be buffered in a queue at Message Flusher which is responsible of delivering messages subscribers. These messages are buffered queue wise in Message Flusher. Slot Delivery Worker read the messages from the slot and pass it to the Message Flusher. Message Flusher passes these messages to its queue wise separated message buffers. Message slot state diagram is shown in the below diagram.

Message Flow state diagram