A message-oriented architecture is an architectural style for the development of systems that share information by exchanging messages. There are many different ways to implement a message-oriented architecture and some of them may not be considered a “true” MOM, but I’m going to cover them all because they can be useful in their own way.
What is Message Oriented Architecture?
To get started we need to understand what is a message? A message is simply data with semantic meaning. That means it’s just data, but it has meaning, and the definition of what that data means are well defined. Messages are usually wrapped in a standard format such as SOAP, XML, or JSON (or plain text), which provides convenience for both senders and receivers because they can agree on the format and structure of the messages they exchange.
A Message-Oriented Architecture is sometimes called Message-Oriented Middleware or MOM because there’s a middle tier or middleware that acts as the broker to relay messages from producers to consumers. At the most succinct definition, MOM is simply an architecture that supports sending and receiving messages. That’s an extreme simplification and when implementing MOM many more facets of its design come into play, so I’m going to expand into some of the common ways of implementing a message-oriented architecture over time. So, I may go outside of MOM from a purist’s point of view.
Advantages of Message Oriented Architecture
Message-oriented architecture has many advantages over other types of architecture. It allows applications to communicate independently of each other and they don’t need to know anything about each other. This leads to loose coupling between systems because they can evolve independently. It also makes it easier to scale systems because messages can be easily parallelized and load-balanced across multiple consumers.
Benefits of Message Oriented Architecture
Flexibility is one of the important benefits of message-oriented architectures. A message-oriented architecture is limited only by the coupling you impose. If you have some sort of middleware and don’t impose any requirements on how your message needs to be processed, your messages can be processed on any platform and at any point in time. Need to publish a message from Windows and have it consumed in a Windows 7 Phone? No problem. Need that processing to occur almost instantly? It’s entirely up to the consumer how quickly they need to consume a message. The message doesn’t need to be processed right away? Again, no problem the consumer can take as long as it needs to process the message.
The flexibility of the system results in many indirect benefits. The producer doesn’t know anything about the consumer of a message (or how many consumers there are, if any) which means the message is free to be routed, aggregated, and delivered completely independently of the producer.
One of the most important aspects, in my opinion, of message-oriented architectures, is scalability. By separating producers and consumers at the process level from one another by way of a message you introduce the ability to horizontally scale almost infinitely. Because a producer asynchronously produces a message and one or more consumers may process the messages of a consumer, the broker is free to load balance or scale out to multiple consumers. This is not without purposeful, and correct, design; but offers system-level scalability that supports vertical and horizontal scaling. For example, multiple consumers can be running on a computer to take advantage of each processor on that computer (vertical) or multiple consumers can be running on multiple computers to take advantage of any number or type of computers (horizontal) resulting in an architecture that supports near-infinite scalability.
Drawbacks of Message Oriented Architecture
One of the biggest drawbacks of a message-oriented architecture is the topology. You’re generally looking at least at a publishing computer, a computer to house the messaging middleware, and another computer that handles the consumption. Each of these computers needs to be configured and publishers/consumers/middleware needs to be deployed and working correctly. This can be cost-prohibitive on smaller systems and implies much management.
If a message-oriented architecture is used in a situation it is not intended for, there can be drawbacks to using it. If a producer needs to synchronously produce a message (i.e, now when the consumer handles the message before it continues on with anything else), this can be a difficult scenario to implement. If the producer needs to know about the consumer or consumers, this can also be a difficult scenario to implement. Both of the scenarios can cause various headaches in a particular deployment. I don’t really consider these drawbacks because MOM is not truly being used correctly, but the technology is not widely understood and the concepts it requires are often misunderstood so I mention them here because the implementation of MOM may encounter them early in the implementation.
Standards have come a long way recently, but—depending on your choice of implementation—there may be no real messaging standard. This could mean you end up being tied to a particular vendor or even a particular platform with no means of extending to other platforms or other components using another messaging mechanism.