In one of the courses I taught this year, I got a lot of questions about the Message Broker and how to implement it for Reliable Messaging.
Why WSO2 Message Broker
Compared to other message brokers, WSO2 Message Broker is a very easy message broker to setup, manage and cluster.
It has support for JMS v1.0, JMS v1.1 and AMQP. On top of this you can choose to store the messages in memory or in Cassandra. Cassandra is the most used noSQL big data database around. So this means WSO2 Message Broker is the perfect broker to have in your production environment. It can handle a lot of reliable messages.
WSO2 used the latest technology to create the WSO2 Message Broker and it runs like all other WSO2 products on their Carbon core, which makes it very easy to cluster and maintain.
For more information about the WSO2 Message Broker please visit: http://wso2.com/products/message-broker/
Going back to the training I presented the following case:
1. The Client sends a message to the ESB
2. The ESB put the message on a queue
3. The ESB tells the Client the message has been delivered
4. Another ESB (Or the same ESB but a different service) pulls the message of the queue and processes it.
This case is the base of creating a Publish and Subscribe pattern or a Guaranteed Delivery pattern.
Installation
We will install 2 products:
1. WSO2 ESB
2. WSO2 Message Broker
Our Enterprise Service Bus will have an offset (see carbon.xml) of 0, while our Message broker will have an offset of 10.
WSO2 products can be installed very easily next to each other by only changing the port offset in the carbon.xml config file. All default ports will be added on top of the offset number.
After setting the right offset ports we can configure the Enterprise Service Bus so it will use our WSO2 Message Broker.
Within the axis2.xml (ESB_HOME/repository/conf/axis2/axi2.xml) uncomment the following blocks:
1
|
<transportSender class="org.apache.axis2.transport.jms.JMSSender" name="jms"/> |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
<!--Uncomment this and configure as appropriate for JMS Ā Ā Ā Ā <transportReceiver class="org.apache.axis2.transport. Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="myTopicConnection Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="java.naming. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="java.naming. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="transport.jms. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="transport.jms. Ā Ā Ā Ā Ā Ā Ā Ā </parameter> Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="myQueueConnection Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="java.naming. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="java.naming. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="transport.jms. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="transport.jms. Ā Ā Ā Ā Ā Ā Ā Ā </parameter> Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="default"> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="java.naming.factory.initial">org.wso2.andes.jndi. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="java.naming.provider.url">repository/conf/jndi. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="transport.jms.ConnectionFactoryJNDIName">Queue Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <parameter locked="false" name="transport.jms.ConnectionFactoryType">queue</parameter> Ā Ā Ā Ā Ā Ā Ā Ā </parameter> Ā Ā Ā Ā </transportReceiver> There is a reference to the jndi.properties in the configuration. This property files contains the Queue and Topic Factory urls. Replace the content of the jndi.properties with the following code: |
1
2
3
|
connectionfactory.QueueConnectionFactory = amqp://admin:admin@clientID/carbon?brokerlist='tcp://localhost:5682' connectionfactory.TopicConnectionFactory = amqp://admin:admin@clientID/carbon?brokerlist='tcp://localhost:5682' |
This is all the configuration that needs to be done. We can now start both products.
We can now begin to create our Proxy services on the Enterprise Service Bus to implement our case.
Proxy Development
For this case we have to create 2 Proxy services.
1. CasePutProxy, Will receive the message and puts it on the Message Broker
2. CasePullProxy, Will pull the message and process it.
CasePutProxy
This Proxy will do no more than receive the message and send it directly to the queue on the WSO2 Message Broker.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
<?xml version="1.0" encoding="UTF-8"?> <proxy http://ws.apache.org/ns/synapse">http://ws.apache.org/ns/synapse" name=" Ā Ā Ā Ā <target> Ā Ā Ā Ā Ā Ā Ā Ā <inSequence> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <log> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <property name="CasePutProxy" value="START" Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā </log> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <send> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <endpoint xmlns= Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <address uri="jms:/MyCase?transport. Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā </endpoint> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā </send> Ā Ā Ā Ā Ā Ā Ā Ā </inSequence> Ā Ā Ā Ā Ā Ā Ā Ā <outSequence/> Ā Ā Ā Ā Ā Ā Ā Ā <faultSequence/> Ā Ā Ā Ā </target> </proxy> As you can see in the above code the endpoint has a very large string. |
These parameters can also be added to the axis2.xml at the JMS sender protocol, the values will be static then for all services that are using the JMS Sender transport.
Also you can provide the queue name to use; in our case we used the queue MyCase.
When not providing any queue name it will automatically use the name of the Proxy service.
CasePullProxy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
<proxy http://ws.apache.org/ns/synapse">http://ws.apache.org/ns/synapse" name="CasePullProxy" transports="jms"> Ā Ā Ā Ā Ā Ā <target> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <inSequence> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <property action="set" name="OUT_ONLY" value="true"/> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā ... Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Do something with the message Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā ... Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā </inSequence> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <outSequence> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <send/> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā </outSequence> Ā Ā Ā Ā Ā Ā </target> Ā Ā Ā Ā Ā Ā <parameter name="transport.jms.ContentType"> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <rules> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <jmsProperty>contentType</jmsProperty> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā <default>application/xml</default> Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā </rules> Ā Ā Ā Ā Ā Ā </parameter> Ā Ā Ā Ā Ā Ā <parameter name="transport.jms.Destination">MyCase</parameter> Ā Ā </proxy> |
Make sure to set the property OUT_ONLY to true, this makes sure you have no errors in your log about not being able to send a message back to the Message Broker.
We set the transport on JMS and added two parameters to the proxy:
1. The ContentType of the message inside the queue.
2. The name of the queue (transport.jms.Destination).
We are now all set and done and ready to test the case!
This is a very simple set up, but is also the basic of most patterns you want to implement.
WSO2 Message Broker Administration Console
You can login to the WSO2 Message Broker admin console with the following url: https://localhost:9453
After login you will see the admin console, which has the same look and feel because of the common Carbon core as other WSO2 products.
In here you can browse and add Queues and Topics, browse the dead letter channel or check the subscriptions.
After receiving the first message on the Message Broker it will automatically create the queue.
You can check this by clicking the Browse link under Queues.
References:
http://wso2.com/products/enterprise-service-bus/
http://wso2.com/products/message-broker/
https://docs.wso2.com/display/MB220/About+WSO2+Message+Broker