First, can you give me a quick summary of Message Oriented Middleware?

To understand message oriented middleware (MOM), it’s helpful to understand a little about the history of corporate software integration. Most company’s software integration architecture looks something like this:

Simplified View of your company's integration architecture

Simplified View of Your Company’s Integration Architecture

No one intentionally designs architectures like this. Interfaces are simply constructed as they are needed and, overtime, yikes! Some of the interfaces may use ftp, SOAP over HTTP, direct sockets, remote procedure calls, CORBA, queues, proprietary connections, simple extract, transfer and load techniques (ETL, which is a very common interface), or even physically carrying a disk across the room to the Footnote 1: Have you noticed this author uses footnotes way, way to often? Sheesh, now he’s actually footnoting the word “the”. other system.

How do MOMs help?

Messaging middleware can be introduced to better organize communication. A simple messaging oriented middleware (MOM) architecture can allow clients to reliably pass asynchronous messages (and possibly synchronous messages) to other software systems. MOM cleans up your communication network so it looks more like this:

Single Hub Integration Diagram

Single Hub Integration

Message oriented middleware greatly organizes interconnections since the hub and spoke architecture allows any system to communicate with any other system. MOMs bring with them all the benefits of reliable delivery, both “point to point Footnote 2: Akin to a person to person phone call, where only two parties are involved. ” and “publish and subscribe Footnote 3: Akin to an advertisement in the newspaper, where one sender communicates with multiple message receivers. ” delivery mechanisms, routing determination based on message content, traffic monitoring, message transformations based on what format the receiver wants, failover, encryption, authentication and authorization of messages, audit mechanisms, etc. Many MOMs allow for integration over different hardware and software platforms as the messages themselves are in a vendor-neutral format.

Is this how queues really end up looking in the real world?

While the centralized hub and spoke architecture shown above comes with numerous advantages, in practice, queues are frequently split into independent realms. A single hub may not be able to cross areas of corporate responsibility or may span widely separated geographic locations, so often a single hub architecture is not possible. Moreover, hubs can become performance bottlenecks or single points of failure. For any of these reasons, message-based architectures frequent require multiple hubs, and end up looking like this:

Multi Hub Integration Diagram

Multi Hub Integration

Can a queue talk to our SAP, Oracle, or other proprietary application?

Often distributing hubs in this manner across an enterprise requires the purchase of an additional product to enhance the underlying centralized queue architecture. For example, IBM Crossworlds (now WebSphere Interchange Server) is primarily about integrating multiple hubs across long distances and getting those hubs to use the same business object definitions. Vendors frequently sell specialized “adapters” separately that are used to connect a system to a hub. Adapters are provided for common systems like SAP, Siebel, PeopleSoft, Oracle eBusiness, or for applications that comply to communications standards like JCA. MOMs can come with many add on products, so hang on to your wallet.

How do MOMs related to Enterprise Service Buses?

While messaging architectures aid in reducing the number of interfaces in an enterprise, messaging software tends to provide some other important features too. Message delivery can be made “reliable” with return message receipts. Messaging hubs can intelligently distribute work load Footnote 4: Not bad for a software system, considering how many managers don’t know how to do this. as systems become bogged down. They can secure transmissions that were formerly unsecured. Since queue technologies are generally at the heart of MOM architectures, they nearly always provide asynchronous communication, which is a weak area for web services. Enterprise Services Buses often use MOMs as their base implementation, because they make up for many of the security, reliability, and asynchronous requirements that are lacking in web services. That is, frequently MOMs + web services = ESBs Footnote 5: Note that (MOMs + web services)/(PHP * C#) mod (Python/Ruby^J2EE) = Perl (see chapters on Web Services and ESBs). IBM’s MQ Series, which is very widely used queue software, provides an old style but rock solid basic queuing approach. Microsoft’s Queue Manager provides the PC equivalent of that product. webMethods is another proprietary middleware product for integrating systems, and a wealth of other products exists in industry to provide message storage, routing, and transformation.


What are the common project-killing mistakes people make with messaging software?

Queue software is generally underrated by industry.  It’s viewed as an old-style approach and it doesn’t have the hype that other service oriented architecture approaches have.  It's well-test and very fast, but messaging software isn’t right for every occasion either.  It’s very important to understand where a queue based approach is appropriate and where it is not, and that's exactly what we cover in the book you can order below.  If you’re already using queuing software, you’d be well-advised to know what the most common queuing project mistakes are.  Over the years, we've seen companies make those mistakes repeatedly. A few dollars spent today might save you a lot of headaches in the future and keep your career erect, full, and upward.  Click the “Buy Now” button below  today – it’s a business expense and you're likely to be surprised at some of the common mistakes revealed in the other chapters as well. Don't just settle for the book excerpt on this page. Act now to protect your career.