| At the core of the ESB communications layer is a MOM infrastructure that is capable of supporting a variety of industry-standard access mechanisms and protocols (Figure 8-1). Think of the MOM as a multiprotocol messaging bus that supports asynchronous delivery of messages with configurable QoS options ranging from exactly-once delivery with transactional integrity through high-performance, low-latency best-effort delivery (a.k.a. at-most-once delivery). The MOM support underneath an ESB should support scalable clustering that is capable of being deployed across the various types of geographical layouts that have been discussed throughout this book. Figure 8-1. An enterprise MOM at the core of the ESB architecture 
The physical topology of the underlying messaging layer is completely independent of the service-oriented view of an ESB process flow. An ESB must be capable of spanning geographic locations and of traversing firewall security using full certificate-based authentication. An ESB must also be capable of delivering messages reliably using message persistence and a store-and-forward capability. As illustrated in Figure 8-2, these capabilities are delegated to the underlying MOM layer. Figure 8-2. Clustering, security, and geographic dispersion are qualities of the underlying MOM 
The messaging layer should have the ability to cluster message servers into a gridlike infrastructure, where all message traffic can be routed seamlessly between message servers without exposing the underlying routing details to the application level or the ESB process level. As illustrated in Figure 8-3, an ESB needs to be capable of connecting and transporting messages across multiple transports and protocols such as JMS, proprietary MOM, HTTP/S, SOAP, WS-Rel*, FTP, and SMTP (email). Figure 8-3. The ESB supports multiple transports and protocols as "on-ramps" and "off-ramps" 
A variety of protocols can be bus-enabled: Direct support in a messaging broker (HTTP direct) WS-ReliableMessaging WS-Reliability A bridge or gateway to the MOM core As a custom ESB service that acts as a bridge to another interface method such as RMI, CORBA, or File Access As an alternative to the MOM core, e.g., SonicESB over WebSphereMQ
These protocols are primarily a means of getting into and out of the ESB. The main reason for supporting these protocols is so that the ESB can integrate with applications or business partners that use them. The main trunk line of an ESB is always MOM-based. Ideally the MOM is compliant with JMS in order to be as standards-based as possible, but even that is not a requirement; An ESB could conceivably be built upon MSMQ and Indigo. Advanced deployment configurations of an ESB might support MOMs from multiple vendors. The MOM, along with the ESB containers, is deployed in as many places as you have control over. This is because the MOM provides scalability through clustering of message servers, a unified view of security, and asynchronous reliable delivery of messages using the store-and-forward capabilities discussed in Chapter 5. 8.1.1 MOM Interoperability When using a MOM, the sender and receiver need a piece of client software supplied by the MOM vendor in order to participate in a messaging conversation. JMS is the only adopted standard for MOM, but it does not define an interoperable on-the-wire format and therefore does not alleviate this situation. The reason for this is that the internals of the wire protocol are part of a MOM vendor's proprietary implementation for providing highly efficient, reliable delivery of messages. This is not about UDP versus TCP/IP versus something else; it's about the next protocol level above that the message transport layer which has to do with what governs the behavior of things such as message-level acknowledgments and retries. JMS does dictate that messages must be interoperable between vendors. This means that a JMS message must be capable of being received from a topic or queue from one JMS vendor implementation, and placed on a topic or queue of another without modification. Most JMS vendors (and ESBs) provide bridge technology to allow this. WS-Reliability and WS-ReliableMessaging (collectively referred to as WS-Rel*) are industry efforts that define an open interoperable wire protocol for reliable messaging based on the SOAP protocol. It is conceivable, even probable, that a MOM implementation could be based entirely on one of these WS-Rel* specifications. However, it would still require a piece of MOM infrastructure on both sides of the wire to handle behavior such as acknowledgment of receipt, message persistence, and recovery from failure. From that perspective, having an open protocol means that the MOM piece of software on either side of the conversation can be provided by different vendors. Unfortunately, it also means that you have less room to innovate on efficiencies of acknowledgments at the message transport layer. 8.1.2 The 80/20 Rule of MOM Backbone Versus External Protocols There's an 80/20 rule to be considered when you're talking about MOM backbones versus external protocols. For the most part, you aren't mixing MOM implementations on a regular basis unless you are bridging together a new project with an old one, or if you are connecting different departments, business units, or business partners with roots in one implementation or another. Therefore, for the 80% of normal cases, you are using one MOM vendor for a particular project, so the internal protocol between the pieces of the MOM software shouldn't matter any more than whether there was an open standard for how a DBMS writes and manages storage on disk. However, for the 20% of cases, you'll be mixing MOM vendors via bridging technology or WS-Rel* endpoint implementations. In some organizations and deployment situations, the ratio is 90/10 or even higher. To determine the ratio for your own situation, consider all the applications that are spread out across your company that could benefit by being integrated together. These are best integrated using the MOM core of the ESB as the underlying transport. Compare that with how many instances of integration you need to do with outside entities where you have no control over what software gets installed. In these cases, you would need to have an open, reliable protocol such as WS-Rel*. As interoperable standards for messaging such as WS-Rel* and process definition language specifications such as BPEL4WS become more prevalent, this will allow even more cross-vendor interoperability, and the 80/20 ratio will decrease even more. Is JMS a Protocol? An ESB relies on a MOM, which can be JMS-based, to carry XML-formatted messages over message channels. Some people view JMS simply as a common API for connecting into a MOM. It is certainly that, but in addition to being an API, JMS also provides a set of rules for defining the semantic behavior of message delivery. Such behavior includes asynchrony, exactly-once delivery, and transactional recovery due to failure of the messaging provider or of the sending and receiving applications. In addition, JMS provides a clear set of definitions for structuring message content and headers. When transporting messages across an ESB, JMS can be thought of as a protocol in the sense that a MOM channel or JMS queue is treated as a transport for carrying XML messages. In that sense, the terms "protocol" and "transport" are treated synonymously; i.e., JMS, HTTP, and WS-ReliableMessaging are all treated equally, even though they are all at different levels on the protocol stack. SOAP-over-HTTP can also be considered a "protocol" as far as the ESB is concerned. This treatment of JMS is also occurring in the open source Apache Web Services project, Apache Axis. In Axis, JMS is allowed as a pluggable transport for web services invocations, as an alternative to HTTP. |
|
