RabbitMQ is an open-source implementation of the Advanced Message Queuing Protocol (AMQP) standard and is one of the most widely used middleware platforms. Traditionally, RabbitMQ has been used for server to server communication as a way to add resiliency and controls to message delivery. But with the growing adoption of cloud deployments and the ever extending reach of the enterprise, there is a growing need to connect RabbitMQ to clients in the web. So what can you do with it?
• Drop in an adapter that extends your existing RabbitMQ deployment to end users in the web with minimal changes
• Delegate all of the complexities of dealing with web users to a trusted entity
• No longer worry about scale, security, device types, device status, connection types, supported applications, etc
• Not only send messages to these web users, but also receive messages back in real time
We've built an integration which allows you to instantly extend the reach of your RabbitMQ deployment to the web. It's open source and free so you're welcome to extend it, modify it, or start using it right away. Now, are you excited or scared?
Connecting Mobile and Web clients RabbitMQ Broker
So first let's talk about the problem we are solving before we get too deep into how we tackle it.
If you had a few web clients in known locations, then you could build an AMQP client for them and connect them to your RabbitMQ deployment. Easy.
But let's look at some more ambitious scenarios. What if you had to handle potential flash crowds with many connections in many different locations with many different types of devices? Managing that many devices would quickly become burdensome. Opening up your backend to the web would introduce lots of security hurdles as well. Not as easy any more.
You could roll your own web adapter cluster to extend RabbitMQ to web users. But there are a lot of corner cases you would need to consider. Some devices may be switching from wireless networks to wifi, some may go idle in the user's pocket, some may have unsupported software, some may be in lossy locations on the other end of the world. Do you have the expertise and cycles to build a complete feature set, troubleshoot corner cases, and operationalize the whole thing? Anything but easy.
The Solution with PubNub as the Secure Connection Gateway with RabbitMQ
Now let's talk about our RabbitMQ adapter for PubNub.
The RabbitMQ adapter to PubNub allows you to hand over the responsibility to send and delivery messages in the cloud. PubNub handles the security, availability, reliability, and scalability concerns in the cloud. The striking part is that your existing RabbitMQ continues business as usual with no changes. Just drop in the adapter and you instantly extended your reach into the cloud.
Workflow of RabbitMQ and Mobile Web Clients Flowchart
RabbitMQ – The middleware layer incorporating the message exchange and queue to handle delivery of messages. The message exchange/broker/queue are all referred to together as RabbitMQ for the purposes of the demo
Producer – The backend server which produces messages to RabbitMQ. This modifies NewTask.java from the RabbitMQ tutorial two java by changing the RabbitMQ channel name defined in the variable TASK_QUEUE_NAME and changing the default message. No other changes are required.
Consumer – The backend server which consumes messages from RabbitMQ. This modifies Worker.java from the RabbitMQ tutorial two java by changing the RabbitMQ channel name defined in the variable TASK_QUEUE_NAME. No other changes are required.
SubscribeAdapter – The PubNub adapter which takes messages from Cloud Clients sent through PubNub and produces qualified messages to RabbitMQ.
PublishAdapter – The PubNub adapter which consumes messages from RabbitMQ and then publishes qualified messages to PubNub to be sent to Cloud Clients.
Cloud Client – Any client communicating over tcp port 80 (or optionally 443 for ssl). This will be the client out in the cloud that we have now extended RabbitMQ's reach to. This client can possibly be a web page using PubNub's javascript SDK, a client app using one of PubNub's sdk's (ie java, javascript, iOS, android, etc), or an app issuing simple REST API calls.
In our demo, we send a message from a Cloud Client to PubNub. For simplicity, we use the PubNub Dev Console to send the message.
The SubscribeAdapter receives this message from PubNub using PubNub's java SDK, and then calls a method named Produce(). Produce will apply business logic and decide whether to produce the message to RabbitMQ.
As far as the business logic within Produce(), our demo simply makes sure that the Amount element contains a valid number and then appends its name to the Verifier field within the message body.
Nothing fancy to show here really. It's very simple. But it's a powerful example of business logic that you could potentially use to filter, aggregate, qualify, reformat, reroute, or recalculate the message before moving on. Qualified messages are tagged with additional data and sent along to RabbitMQ, while invalid messages are simply discarded.
The Consumer is then able to consume the message from RabbitMQ. The Consumer has a properly formatted, digestible message that has been validated by business logic and qualified first. This message was plucked right off of RabbitMQ, without any concern or care that the message originated in the cloud from some web client.
On the outbound side, the Producer class produces a message to RabbitMQ. The PublishAdapter consumes this message, applies business logic to determine whether to discard the message, reformats the message, and publishes to PubNub.
This message is now available to clients in the Cloud. It has been collected, inspected, verified, and routed to the appropriate channel. The beauty is that the backend server that produced the initial message only knows that the message was sent to RabbitMQ. The PublishAdapter passes the message to PubNub and PubNub will deliver to clients in the cloud.
Did I mention that PubNub has industry-leading features and best practices around security and authorization? Did I mention that we also have the notion of history and playback so clients can catch up to messages that they missed while they were offline? I think we can come up with an enterprise-grade solution here for end-to-end message delivery, with minimal effort. But this will have to wait for a future blog post.
Get Started
Sign up for free and use PubNub to power RabbitMQ
