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
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 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
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 ” and “publish and subscribe ” 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
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 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 (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.