Message-oriented middleware is a software or hardware infrastructure that uses message exchange instead of shared memory. It is, without any doubt, the most reliable and useful concept in terms of data exchange in high performance and sensitive systems.
Message-oriented middleware, M.O.M. or just messaging, can be understood as an architecture of a distributed system, where it represents a middle layer (therefore the name “message-oriented middleware), and it is being used as a complete and secure solution for transfering data in a fast and smooth manner between different components of the system, that will further process that data.To make it simple: M.O.M. is the mailman in a distributed system. It takes a message from point A to point B, where the two elements can be perfectly decoupled => element A doesn’t have to be available when the message is being being delivered, element B doesn’t have to have available also, but the message is never lost. How can that be ?
Asynchronous messaging steps in. Asynchronous messaging is a concept in which the two points are completely decoupled from one another. Let’s continue with the most pragmatic example. Let’s assume that Element A is Andrew and Element B is Barbara and Andrew needs to send a private message to Barbara. Andrew leaves his letter (message) to the post company (our messaging solution) which will now deliver the message to Barbara. Andrew doesn’t have to follow-up the sending process anymore, as the letter is now in the hands of the post company. The post company processes the letter and delivers it to Barbara. If Barbara is not home, the letter will be left in her mailbox and she will receive it when she becomes available. The letter gets to its destination anyway, independently of the fact that either Andrew or Barbara were not available at the time of delivery.
Therefore, getting back to IT infrastructure, we’re going to switch to the world of business and see how this technology fits in. Messaging is being used for sending data in a rapid manner, therefore it can be found in sales, healthcare, military, finance and banking, computing, business and basically every domain that computes and processes data. Let’s change the previous example into something more “corporate”. Element A is now a car dealership, located in Atlanta, part of a large organization that has vehicle local dealerships all over the world: Carmart. Whenever Carmart Atlanta sells a car, it sends that data to the Headquarters of the company. You can see in the video below how a normal point-to-point communication works:
Carmart HQ processes that data in different manners: they inform the Procurement department that a new car will need to be sent to the dealership in Atlanta, they also inform the Finance department that they have new income thanks to that sale, and last but not least, they inform the Logistics department that they need to prepare for a new delivery to Atlanta and of course, they inform Carmart Atlanta of when will they receive a new car to replace the recently sold one. Here it is how it generally works:
So Carmart HQ, after having received the message from Carmart Atlanta, it decides what to do it. And here you get to a very important and interesting paradigm in messaging: publish/subscribe also known as pub/sub or fan-out, depending on the messaging solution that we employ. Inside the Carmart HQ, we have a topic entitled Car sold!!!. The purpose of a topic is to spread the message to whoever might be interested in it. Therefore, everyone who wants to be informed about a new sale, needs to subscribe to that topic (if authorized) and they will receive a copy of the message.
Message-oriented middleware solutions
We have been talking a lot about messaging solutions without properly explaining what they are and what do they do. Let’s take an example from IT. Data is being structured under a concept called a database. There are a lot of database solutions: Oracle, MySQL, DB2, etc. Therefore, in this case, the general concept is a database and the database solution is, for instance, Oracle Database. If you don’t know what Oracle or a database is, don’t worry, you’re still going to get what this is all about, but you might need some computer knowledge before continuing with these tutorials. Let’s go back to our first example, the most pragmatic one. Who is the post company? It could be USPS, Fedex, UPS or a local not very popular one.
Well, getting back to messaging or message-oriented middleware, the solution is the software or hardware that makes messaging possible. The catch is here: traditionally, if you wanted to send a message from an application to another and ensure its delivery in a fast and secure way, the amount of code and knowledge needed for that is tremendous. Instead, software solutions have been developed that do just that: the application puts a message into the software’s logical unit and it’s the message-oriented middleware software who takes care of delivering it to its destination. The most popular messaging solutions are IBM MQ, RabbitMQ, ActiveMQ, MSMQ, etc. And there is a hardware solution as well: IBM MQ Appliance – a plug-n-play server designed to be the messaging solution in a large enterprise with heavy data circulating through the network, like banking.
To resume, let’s keep in mind the following crucial concepts in message-oriented middleware:
Messages are the most important part of messaging. The purpose of M.O.M. is to deliver data between different components of a computer system or network.
Point-to-point and Pub/Sub are the most common paradigms when talking about ways of transfering the data, but there are a lot of concepts out there that one can apply, according to his needs.
Messaging solutions are software or hardware components that securely transfer the data.
Welcome to the MQ-Academy, the new encyclopedia of middleware-oriented messaging!