| When bandwidth that can support RPCs is absent, or in a situation where a server cannot be depended upon to always be up and running, message-oriented middleware may be the better choice for an application integration project. Like RPCs, MOM provides a standard API across hardware, operating system platforms, and networks (see Figure 7.8). MOM has the additional benefit of being able to guarantee that messages will reach their destination even when the destination is not available at the time the messages are sent. Figure 7.8. MOM provides an API to allow programmers to access its services. 
MOM utilizes one of two "macro-messaging" models: process-to-process or message queuing. In the process-to-process model, to exchange messages, both the sending and receiving processes must be active. In the queuing model, only one process must be active because messages can be stored in a queue. The queuing model is best when communication takes place between computers that are not always up and running, over networks that are not always dependable, or when there is a limitation on bandwidth. When taking MOM usage into account, it's no surprise that we see movement from process-to-process to queuing. Unlike RPCs, which block processing until the procedure call returns, MOM is asynchronous and consequently allows the application to process when the middleware API is invoked. MOM message functions can return immediately, even though the request has not been completed. This allows the application to continue processing, assured that it will know when the request is completed. The queuing model works best with transaction-oriented application integration applications that must traverse many platforms. Unlike DCE, the queuing model does not require that the platform be up and running for an application to request services. If the server is down, the request remains in a queue. As soon as the server comes back online, the request is processed. In addition to these queuing features, MOM provides concurrent execution features that allow processing of more than one request at a time. Aren't Message Brokers MOM? Of course they are. After all, they use messaging as the primary form of communication. Technically, that makes them MOM. However, for the purposes of this section's discussion, when we refer to MOM, we are referring to more traditional MOM, or message-queuing software. In fact, many people now call message brokers "integration brokers" because of their complexity and specialized purpose of many-to-many application integration. Queuing software requires that you use an API to change both source and target systems, adapting them to the middleware. They almost always function point-to-point (one application to one application). In contrast, message brokers can connect many applications to many applications. They provide message transformation, routing, and rules-processing services. They can also leverage adapters that minimize the impact on the integrated applications. Message brokers seem to provide a good fit for application integration. Traditional messaging middleware generally does not. Message brokers are so important to application integration that they deserve their own middleware category, a category we will deal with more completely later in this book. |
With all these beneficial features, when should MOM be applied? It is a good choice for store-and-forward communication, or when dealing with applications that are not expected to be reachable at the same time. MOM is a good choice for "defensive communication" communication between applications when networks frequently fail. MOM is also a good choice for journaled communication when communication between processes needs to be logged. Overall, MOM and messaging tend to be better application integration choices than RPC-based middleware. However, if we've learned anything during our examination of application integration solutions, it is that there is no single, objective "best" choice. Most solutions require a certain amount of thoughtful mixing and matching. MOM is no different in this respect. By itself, it does not provide the complete infrastructure necessary for application integration. Message brokers add value to traditional MOM products by providing data and schema transformation functions, along with intelligent routing and event-driven processing to move information throughout an enterprise. Such a scenario relies on MOM products as little more than functional transport layers (see Figure 7.9). Figure 7.9. Message brokers may use MOM to transport messages. 
Examples of MOM Each MOM product delivers messaging in its own way. Two of the most popular MOM products MSMQ from Microsoft and MQSeries from IBM give us insight into how different products approach their tasks. In the world of MOM, IBM's MQSeries is the proverbial 800-pound gorilla. With a queuing middleware market share of over 65 percent, it can do just about anything it pleases. Although it may not be the most feature-rich messaging middleware product, MQSeries sits atop the application integration world as the preferred messaging layer for moving information throughout an enterprise. The most notable benefit of MQSeries is the number of platforms it supports. MQSeries works with IBM OS/390, Pyramid, Open VMS, IBM AIX, NCR UNIX, UP-UX, Solaris, OS/2, Windows NT, SCO UNIX, MacOS, and many others. MQSeries supports all the features of MSMQ, including support for transactions, journaling, message routing, and priorities. MQSeries also provides a common API for use across a variety of development environments. (These interfaces are sold by third-party vendors.) MQSeries products provide a single, multiplatform API. As a result, messages can be sent from a Windows 2000 workstation and routed through UNIX, VMS, or even a mainframe before reaching their final destination. Platforms running MQSeries work in concert, ensuring that messages are delivered to their destination (see Figures 7.10 a and b). They can also route around network and system failures. MQSeries can be used as a transactional recovery method and a mail transport mechanism, ensuring the delivery of messages. Figure 7.10a. MSMQ provides messaging queuing for Windows. 
Figure 7.10b. MQSeries is a heterogeneous MOM solution. 
MQSeries supports what IBM refers to as an "advanced message framework." This framework consists of three layers: customer application options, a trusted messaging backbone, and comprehensive communication choices (see Figure 7.11). The customer application options provide services such as basic messaging, transactional messaging, workflow computing, mail messaging, option messaging, cooperative processing, data replication, and mobile messaging. Transactional messaging allows developers to coordinate message flow with updates to other resource managers. (For example, several databases on different platforms can be updated at the same time.) The mail-messaging feature allows any Vendor-Independent Messaging (VIM) or Mail API (MAPI) application to transmit e-mail securely and reliably by leveraging the power of MQSeries' messaging infrastructure. MQSeries supports messaging between distributed objects and facilitates cooperative processing between two or more processes. Figure 7.11. The three layers of MQSeries. 
MQSeries' messaging backbone guarantees that messages are delivered to their destinations and that the information encapsulated in those messages is secure. Its comprehensive communication choices allow it to leverage any number of protocols and networks for message traffic. The latest version of MQSeries offers a peek at "things to come" in messaging middleware. Traditional MOM focused on simple A-to-B asynchronous message passing. In an attempt to be competitive with other MOM vendors and other middleware products, MQSeries now provides many value-added services services never envisioned in the original concept of MOM. That original concept never included, for example, the encapsulation of transactions. Today, nearly every MOM package takes advantage of the notion of a transaction (a "unit of work"), with the ability to maintain states. MOM can now maintain message persistence and logging, enabling it to provide enhanced manageability and fail-over capabilities. The best of the queuing products available (like MQSeries) are in the process of reinventing themselves by adding a publish/subscribe engine. It is a smart move. This positive development is intended to gain entry for queuing products into the exploding world of middleware products for information dissemination. Once the playing field is leveled, they will be competitive with existing publish/subscribe middleware from vendors such as TIBCO. The current MQSeries has taken the leap directly from Version 2 to Version 5, stepping up the IBM installation procedures so that it will be "up to speed" with other IBM products. In the past, MQSeries was notoriously difficult to install. This upgrade should successfully address this frustration. IBM also claims that this new version of MQSeries works better with its DB2, Transaction Server, and other Software Server components. Other new features include Database-Message Resource Coordination (DMRC) and smart message distribution. Long available on a large number of server platforms, MQSeries now supports Windows NT and OS/2, as well. Before this latest version, MQSeries required a transaction manager or a sophisticated application program in order to combine database updates and messaging activity into a single unit of work. With Version 5.1 and the introduction of DMRC, MQSeries includes MQ and SQL activity support through the new MZBEGIN verb to register a unit of work. Thus, subsequent work can be committed or backed out, depending on whether the procedure succeeds. MQSeries supports the notion of a transaction, without having to employ a TP monitor or application server. Smart message distribution minimizes the amount of network traffic required to distribute a copy of a single message to multiple users whose queues reside on a single node. MQSeries 5.1 can send a single copy of the message to each target MQ system, using a list of recipients at the target systems. From there, the receiving MQ system produces and queues the copies locally. In addition, the package includes performance enhancements, such as fast messages (changes to MQSeries' message channel agents to reduce the time and resources required to move nonpersistent messages) and enhancements to internal channel architecture and trusted bindings. Another significant improvement in this upgrade is MQSeries' ability to support large messages. The previous limit of 4MB per message has been extended to 100MB per message. Additionally, messages may now be built or retrieved in segments and passed by reference. The publish/subscribe feature in the newest version of MQSeries automates the distribution of relevant information to people and applications. Using the new pub/sub engine, MQSeries developers can ensure that clients who subscribe to a particular topic receive exactly what they want. Meanwhile, behind the scenes, MQSeries uses the MQ messaging infrastructure to move the messages throughout the enterprise. With pub/sub, an MQ-enabled application no longer needs to understand anything about the target application. Now it simply sends the information to be shared to a destination within the pub/sub engine, or broker. The broker can redistribute the information to any interested application. The real advantage to offering pub/sub is the degree of reliability that MQSeries delivers. The most significant downside is not within the MQSeries environment, but with those pub/sub vendors that now find themselves competing against IBM. TIBCO, which has long dominated pub/sub, might find that MQSeries' new features will finally threaten its "king of the hill" status in the world of finance. In addition, the pub/sub features of MQSeries are the same as many features offered by traditional message brokers, although without schema and content transformation facilities. IBM adopted NEON's message-brokering features and placed them on top of MQSeries as an add-on package the MQ Integrator. IBM's ultimate goal is to become the information bus for the enterprise. With this latest release of MQSeries, it takes a giant step toward achieving that lofty goal. |
Future of MOM Despite its shortcomings, MOM still has its place within the enterprise and within some application integration projects. Connecting applications to applications, it is more applicable to EAI than to application integration. Why? MOM requires major changes to source and target applications, which is generally frowned upon in most application integration problem domains. Still, our discussion of MOM has been worthwhile in the context of middleware, because messaging is the basis for many application integration solutions, including message brokers. RPCs have an even longer shot at becoming the basis of application integration. Their synchronous nature and heavy overhead, as well as their deep impact on source and target applications, will keep RPCs intraenterprise. However, as with MOM, RPCs are a worthwhile discussion, because many application integration solutions leverage RPCs (such as a solution using Java's RMI as a mechanism to enable application-to-application communication). It is worth remembering: Good technology is always built on the foundation of good technology. Both RPCs and MOM are good technology. They will continue to be the basis of many technology advances. |
