Message Boxes: do you still need MOM?
Asynchronous, reliable message passing is one of the cornerstones of an integration infrastructure. Traditionally, asynchronous reliable transport has been provided by message-oriented middleware. Many EAI vendors started as MOM vendors. Simply put, it is difficult to imagine an EAI solution without MOM.
However, before you go and buy yourself MQ Series, TIBCO, or one of their imitators, you should know that there is an alternative.
Why asynchrony?
Synchronous communication implies temporal coupling. Both the client and the server must be up for the
interaction to occur, or an error occurs. This is fine for situations where a response is immediately needed (for example, UI). For other requirements (response eventually needed, fire-and-forget, i.e. long running workflow or data integration) temporally-coupled systems are more fragile than systems built on the basis of reliable asynchronous communication. This is especially significant in distributed network-connected environments.
Traditional solution: MOM
The traditional solution is simple: put MOM in between the interacting parties. In a fire-and-forget scenario (diagram below), the publisher deposits a message to MOM queue. The subscriber retrieves message from queue when the subscriber is ready. Nothing fails the subscriber is down at the time publishes originated the message.
Is there a problem with MOM
Not really. It is an excellent foundation for an EAI solution. However, sometimes it may offer too much functionality and therefore be more expensive and more complex than it needs to be. However, as I asserted in the beginning, you do need asynchrony.
Message-box: a poor (wise?) man’s MOM
A month ago I started working with BizTalk. I like BizTalk for many reasons [TODO: link to BizTalk versus ICS comparison] BizTalk provides a somewhat unique concept of a message box that I illustrated on the following diagram:
In BizTalk, all cross-broker interactions involve Message Boxes. Adapters deposit inbound events / messages in Message Boxes and retrieve outbound messages from message boxes, before delivering them to target applications.
Effectively, all interactions are asynchronous and temporally de-coupled. If the subscriber in the example above is down, there is no problem. The to-be-delivered message is stored in the message box until the adapter can deliver the message, so once the subscriber is up.
Truly, message boxes are not all that innovative if at all. The concept has been around forever, for example in operating systems. However, BizTalk – to my knowledge – is unique with this concept ( IBM/Crossworlds ICS provides a similar functionality)
Message-box versus MOM
I love the concept of Message Box. I believe that it can replace MOM for small and medium installations.
What a Message Box is not?
- It does not solve your transport problem like MOM does, i.e. it does not eliminate the distance from the equation. If you need to distribute information, especially over wide area networks, there is nothing like MQ and the likes.
- It does not give you the fancier stuff, like UDP-based message dissemination.
- Since it is database-based, it will not perform like MQ or TIBCO EMS. It will be more like WebLogic’s database-based JMS implementation.
However, in certain cases, Message Boxes can replace MOM and yield a more elegant, simpler, cheaper, and more manageable solution. Assume that you’ve built a multi-transport broker-type [TODO: link-to broker-centric versus transport-centric] EAI (diagram below):
If your integration is limited distance-wise, and you have a broker with Message Boxes, this can be effectively accomplished without MOM, with quiet a few benefits:
- Simplicity. Just the broker, no MOM.
- Asynchrony and temporal de-coupling is there. Notice that all transports between broker and integrated applications are synchronous and commodity. No extra cost.
- It is easy to monitor and audit. Just run reports against the database.
Summary
Message Box may completely eliminate a need for MOM. In fact, it really is a simplified MOM, with lesser performance and no ‘remoting’ / transport. It will do fine, if you don’t have fancy or hight transport requirements. It works if you build a broker-style integration – for obvious reasons, it will not work in a bus model.
So, before you start evaluating the MOMs to buy, take a look at BizTalk. Maybe you don’t need MOM at all.