ESB as a Transistor for Protocol Switching Between AMQP and MQTT - Part 2

In the previous post i described how WSO2 ESB could be used to switch between AMQP and MQTT protocols. In that the pattern of having AMQP queue producer and and MQTT as a consumer was discussed. In this post i would be elaborating how a message could be published to AMQP topic and received by both AMQP and MQTT consumers.

2.0 AMQP Topic to MQTT Topic 

Please follow the instruction described in the previous post to setup the environments if it has not being done already.

Usage: Publishing message to AMQP topic and receiving is from both AMQP and MQTT consumers

Message Flow

Use case: This sample demonstrates how a message published to AMQP topic via JMS could be consumed by both MQTT and AMQP topic consumers.

1. Start the ESB server and log into its management console UI (https://localhost:9443/carbon). In the management console, navigate to the main menu and click source view in the service bus section. Next, copy the configuration which could be found in ESBConfiguration.xml
2. Replace the jndi.properties file which could be located in the ESB ($ESB_HOME /repository/conf) directory with jndi.properties.
3. Start two JMeter instances, one which would act as a JMS message publisher and the other which will act as a JMS message consumer. The consumer could be found in AMQPTopicConsumer.jmx and the producer could be found in AMQPTopicPublisher.jmx.
4. Start MQTT fx client and subscribe to the topic ‘TrackLocationMqttTopic’.
5. Execute the Jmeter consumer and producer and observe.

Observation

JMS message which was published to ‘TrackLocationAMQPTopic’ would be received by both the AMQP subscriber who subscribed to the topic ‘‘TrackLocationAMQPTopic’’ and MQTT subscriber who subscribed to ‘‘TrackLocationMqttTopic’”.

JMS Topic Publisher (JMeter)

JMS Topic Subscriber (JMeter)

MQTT Topic Subscriber (MQTT Fx)

Note : Message Broker current version ( < 3.1.0) does not support subscribing to the same topic name with two different protocols. I.e AMQP and MQTT, hence the consumers were subscribed to two different topic names and was correlated through the ESB. however, Message Broker future releases intend to allow the capability to subscribe to a common topic name by different protocols. 

The next two patterns "Publishing to MQTT topic and receiving from AMQP queue consumer" and "Publishing to MQTT topic and receiving from AMQP topic consumer" would discuss the inverse of the two patterns discussed in part 1 and 2. Will elaborate these patterns in the upcoming days. 

ESB as a Transistor for Protocol Switching Between AMQP and MQTT - Part 1

In my previous post, i discussed how both protocols AMQP and MQTT could be of use for different enterprise requirements. Both protocols has its own advantages, in my opinion AMQP could be more robust over MQTT due to its maturity, however MQTT would outperform AMQP to its lightweight nature making the protocol more suitable for applications intended to be executed in low powered and constrained network environments. 

Due to the potential of both the protocols the apparent question would be the possibility of using both of them. Could this be achieved ? the simple answer would be yes. The following post would discuss in a series on how this could be achieved using both WSO2 ESB and MB.   

Transistor is typically used to switch electronic signals (typically between hight powered circuits to low powered once) i would like to apply that term to describe how WSO2 Enterprise Service Bus could act as a transistor to allow switching between both the protocols (AMQP protocol and MQTT) supported by WSO2 Message Broker, imagining the use case of an enterprise having AMQP as the high powered source and MQTT as the lightweight source deployed on devices running in constrained environments. 

I would like to describe 4 patterns which could be followed when protocol switching,

1. Publishing to a AMQP queue and receiving from MQTT topic consumer
2. Publishing to AMQP topic and receiving from both MQTT and AMQP topic consumers. 
3. Publishing to MQTT topic and receiving from AMQP queue consumer 
4. Publishing to MQTT topic and receiving from AMQP topic consumer

The above patterns would be described in a generic fashion which could be implied to various use cases,

Setting Up

Prerequisites 

• Download WSO2 MB and  WSO2 ESB from the website. (Also note i used WSO2 ESB 4.9.0 and WSO2 MB 3.1.0 for this post)
• To send/receive AMQP messages via JMS we use apache JMeter.
• To send/receive MQTT messages we use MQTT Fx as the client.

Configuration 

• Enable MQTT Transport sender and receiver in the ESB.
• Enable JMS Transport sender and receiver in the ESB.
• Copy the MB client libraries from $MB_HOME/client-lib to $JMeter_HOME/lib/ext and also copy the client libraries to $ESB_HOME/repository/components/lib/
• Create the jndi.properties file and add the following to it. Make sure to track the url of the jndi file location. This location should be replaced in the ‘Provider URL’ of the jmeter script file. The jndi file could be found in jndi.properties.
• Startup MB server. Make sure the MB server is running on its default offset.
• Startup ESB server. Make sure that you offset the ESB by 1.

1.0 AMQP Queue to MQTT Topic

Usage : Publishing message to AMQP Queue and consuming the message from MQTT client.

Message Flow

Use Case : This sample demonstrates how a message published to AMQP queue via JMS could be consumed by an MQTT consumer.

1. Start the ESB server and log into its management console UI (https://localhost:9443/carbon). In the management console, navigate to the main menu and click source view in the service bus section. Next, copy the configuration which could be found in ESBConfiguration.xml .
2. Replace the jndi.properties file which could be located in the ESB ($ESB_HOME /repository/conf) directory with jndi.properties.
3. Start JMeter and import the script file AMQPQueuePublisher.jmx.
4. Start MQTT fx client and subscribe to the topic ‘LocationTrackerTopic’.
5. Execute the Jmeter script and observe.

Observation

The JMS message which was published to the LocationQueue should be received by the MQTT client consumer who is subscribed to LocationTrackerTopic.

As illustrated below in the screenshots,

JMS Client (JMeter)

MQTT Client (MQTT Fx)

Next post would describe the pattern of having AMQP topic producer distributing messages to both AMQP and MQTT consumers. 

What would you chose AMQP or MQTT ?

WSO2 Message Broker currently supports both AMQP and MQTT protocols. whether to use AMQP or MQTT was a frequent question i came across. The answer would subjective in my opinion, in simple terms both protocols has its own advantages, hence i would like to share a few of my findings on various strengths of both these protocols.

	AMQP	MQTT
Large Messages Transmission	Uses buffer oriented approach and supports fragmentation, hence it’s more suitable in comparison	Stream oriented protocol, does not support fragmentation. Hence more suitable for smaller size messages
Message Exchanges	Supports both topics and queues, suitable for long lived messages	Optimized for active routing, publisher-subscriber based.
Transactional Support	Supports different level of transactions and acknowledgment modes i.e distributed XA transactions, client acknowledgement, auto acknowledgment	Supports three acknowledgment modes. Specifically focusses on exactly once delivery
Connection Security	Supports standard TLS through SASL.	Supports basic auth and SSL. Security is embedded into the protocol itself. This requires security changes to be included in the protocol itself.
Last value queues	Does not support explicitly	Supports this in the form of RETAIN flag.
Reliable Messaging	Supports reliability using different acknowledgment modes and session durability	Supports reliability using different acknowledgment modes and session durability
Failover	Supports native failover	Need to support failover explicitly

Depending on the enterprise needs the above selection of protocols could defer, AMQP is a more matured protocol in comparison to MQTT and its readily available for the use of enterprise requirements, however AMQP is more heavy weight than MQTT which makes it less suitable for devices running in low powered and constrained network environments.

What if you want to use both these protocols? I would be discussing on how protocols could be switched in my next post.