Messaging system just like RDBMS systems are very well understood by Software industry just like RDBMS. They have been researched and developed over a long period and they are as important as RDBMS. Many implementation and specifications exists both from open source world and commercial vendors.
Many of the features are common and some unique to each offering. Some are even fine tuned for some specific industry like finance and telecom.
Some of them are really really expensive and some are free.
Microsoft has MSMQ for free on Windows Servers and in Java world two protocols are most famous. a.) JMS b.) AMQP
For JMS there are many implementations
Active MQ, Hornet Q, Fioranao to name a few. Lot of times you can choose any of them and it wont make much of a difference. Somewhere I read “Nobody gets fired for using Apache product” so I choose Active MQ for my implementation.
As this blog focuses more on architectural aspects we will talk about how and where JMS fits into your application design and why it has to be part of your system from very beginning.
In the last post we talked about how software system (how big or small does not matter) should be broken into different components. We will start from where we left. Wiring up of these component systems
So how do we call an API exposed in another system. Couple of choices.
a.) We expose a SOAP service
b.) Expose a REST API
c.) Create a socket connection and do RMI
We can choose any of these depending on situation. If we are exposing to outside world (like Facebook/Twitter/Google exposing their APIs then over the wire only choice ‘a’ and ‘b’ are viable. If you want to expose APIs to internal components then you can choose either of three.
With choice c.) issue is about serialization/deserialization. and to do low level RMI programming is not that easy and require fair amount of expertise.
Error prone, time consuming and difficult to maintain this may lead to disasters.
Problem with choice is a & b is that we have to expose these services via a container like tomcat/jetty/jboss etc if we are working with Java stack or Apache/Nginx if we are working with PHP for example. Though you have free softwares available there but issue is that do you really want to spawn a new instance of a container just for exposing services internally to your systems.
One can not surely say that these containers are lightweight. It seems bit like overkill to me running so many instances of tomcat on various machines though its a personal choice. Not sure but I think Amazon does this SOA style of programming but we are not talking about Amazon here :-).
Choice c. is hard to implement so we should hope for a framework that can do heavy lifting for us including serialization/deserialization of objects.
Fortunately for us there is help available in form of Apache Thrift/Avro/ProtoBuff . Thrift is a full stack interface for creating scalable TCP servers.
A tcp server can expose a particular service and thrift helps creating stubs for your client. You send a POJO and you get a POJO that’s all. What’s more you can do cross-language RMI using thrift as it supports lot of languages. An amazing lightweight framework contributed by Facebook to open source community makes your life very easy. We will talk about thrift some other time in detail for now let’s stick to Messaging systems.
Apart from choices mentioned above there is one more choice available called messaging. When you want to take some action just fire a message and let component interested in that message do it’s job.
This mechanism sometimes called fire and forget is also a key to creating high performance systems. It’s also at heart of Event Driven Development.
Components are just waiting for some interesting event and when it happens they get a notification and they can do what they have to do.
So once we decide that we have to talk to other components via sending messages then we need a system which will let us do this easily. This is where messaging systems such as JMS comes in the picture.
It sits between different components and transfers messages from once place to another much like a post office. So it’s a pretty dumb piece of software just running in it’s own process space and doing nothing but transferring messages between one place to another. we will see it’s not that dumb though at later stage.
So you want to process an order..Just send it to JMS which will take the pain of sending it to OrderProcessing component which sits somewhere on other machine and does its job when it gets an Order message. When you want to create a system which is made of many small small components you need to rely on your message sending mechanism because messages
a.) may fail to get delivered
b.) they may get delivered multiple times
c.) they may get lost in transportation.
This is where you need a robust system which guarantees you to be able to handle these issues and Active MQ is one of them.
Let’s just see when we talk about 3 box app how does it look like.
A geek's blog 