| Figure 8-4 shows some examples of protocol stacks that can be used for transporting messages across an ESB. These protocol stacks include SOAP-over-HTTP/S, WS-Rel* SOAP, MOM/JMS, SOAP-over-JMS-over-HTTP/S, and JMS-over-SSL. Figure 8-4. Protocol stacks for transporting XML messages include 1) SOAP-over-HTTP/S; 2) WS-Rel*; 3) MOM/JMS; 4) SOAP-over-JMS-over-HTTP/S; and 5) JMS-over-SSL 
Here are brief descriptions of these protocol stacks:
- SOAP-over-HTTP/S
-
The standard means of carrying a SOAP message over an HTTP or HTTP/S transport.
- WS-Rel*
-
Using WS-Reliability or WS-ReliableMessaging as a transport. (Although not shown here, WS-Security, WS-SecureConversation, etc., can be used to secure SOAP over HTTP messages.)
- MOM/JMS
-
Using a MOM channel, JMS-based or otherwise, to transport messages.
- SOAP-over-JMS-over-HTTP/S
-
Using JMS to carry SOAP messages, combined with tunneling of a JMS connection through a firewall using the HTTP or HTTP/S protocol. This can be done between a JMS client and a message server, or between two JMS servers. This usually involves mutual authentication using x509 digital certificates.
- JMS-over-SSL
-
The act of tunneling a JMS connection through a firewall using the SSL protocol. This can be done between a JMS client and a message server, or between two JMS servers. This usually involves mutual authentication using x509 digital certificates.
SOAP is not a prerequisite for an ESB, although it is fairly common for ESB channels to carry SOAP messages. In some cases, the ESB may even strip off the SOAP envelope and just use the remaining XML payload information as the message that gets passed between services. Quality of Service (QoS) levels can vary depending on which protocol is chosen to carry a message. This is another reason why there is a unified MOM at the core of the ESB. In fact, the enumeration of benefits to having a MOM at the core of the ESB is almost the antithesis of the disadvantages of the accidental architecture: Consistent QoS levels Consistent management Metrics and monitoring Consistent troubleshooting techniques Consistent scalability methodology Consistent performance tuning techniques Consistent security and ACL model Publish-and-subscribe broadcast of information Message persistence and reliability of message delivery
8.2.1 Protocol Bridging Bridging is one way to attach a legacy protocol such as FTP or SMTP (email) into an ESB. As illustrated in Figure 8-5, an FTP or SMTP bridge is implemented as a specialized messaging client, which converts data from one protocol to and from the MOM channel. Figure 8-5. A protocol bridge converts between an "external" protocol and the ESB MOM channel 
You could write the protocol bridge yourself, but most messaging vendors supply them for you. Later in this chapter (Section 8.3.5) we will explore how a custom file-drop ESB service performs a similar bridge function. What you gain by using a protocol bridge is a common backbone for transporting data across the enterprise. This pushes the unreliable FTP out to the outermost edge of your integration network, and in many cases completely eliminates its use by removing the dependency on FTP for transporting bytes across the network, and simply retaining the file-based interface between an application and an ESB. Chapter 9 will explore this scenario in more detail. 8.2.2 MOM Bridging An ESB also provides a bridge across MOM implementations. Many corporations, especially larger ones that have been through a few acquisitions, have multiple installations of MOM from different vendors across their organization. A new installation of an ESB can link with these existing MOM installations using a MOM bridge. For example, you might have SonicMQ as a MOM core of an ESB, which links into WebsphereMQ and TIBCO RV, as illustrated in Figure 8-6. Figure 8-6. Bridging between two different MOM vendors 
Recall the concept of "leave and layer" as introduced in Chapter 1. Bridging between MOM vendors accomplishes this goal, allowing an ESB to extend its reach into an existing MOM-based integration infrastructure without needing to tear it out and replace it. Figure 8-7. Bridging an ESB into an existing MOM infrastructure accomplishes "leave and layer" 
Figure 8-7 represents a bridge layer sitting between the message channels of the ESB's native MOM core and the message channels of an existing MOM infrastructure. As standards for connectivity and messaging integration mature and are implemented by messaging and ESB vendors, the ESB may be able to treat "foreign" message channels directly as endpoints. Examples of these specifications are the Java Business Integration (JBI, JSR-208) effort that is underway within the JCP, and Reliable SOAP specifications such as WS-Reliability and WS-ReliableMessaging (WS-Rel*). Figure 8-8 shows an ESB infrastructure that directly interfaces with MOM endpoints from SonicMQ, WebSphereMQ, and E4JMS. Figure 8-8. An ESB interfacing directly with MOM channels from multiple vendors using emerging specifications such as JBI and WS-Rel* 
8.2.3 Direct Protocol Handlers One form of integrating an ESB MOM core with another protocol is through direct support for that protocol within the MOM's message broker. In this scenario, the message broker itself provides the bridging, or mapping, between the external protocol and the internal MOM channel for example, a mapping between SOAP-over-HTTP and SOAP-over-JMS. Figure 8-9 shows the kinds of protocols that are typically supported in this fashion. Figure 8-9. Direct protocol support in the MOM's message broker 
The ability to process HTTP requests, both inbound and outbound, is a critical component that enables two of the four basic parts of an ESB as described by Gartner: MOM and web services. Providing the HTTP protocol support directly in a message broker allows the configuration and management of server clustering, fault tolerance, and high availability from a single vantage point without additional external processes. The servers in the cluster may act as one logical server, which can communicate on multiple protocol channels that send and receive MOM messages, SOAP messages, or non-SOAP HTTP requests. This means there are no additional moving parts or additional processes, such as web servers, servlet engines, or ISAPI filters, that can become bottlenecks or points of failure. 8.2.3.1 Synchronous request/reply: invoking an ESB service via HTTP An ESB should provide an invocation framework that allows an ESB service to be invoked as a result of an external HTTP request. A single HTTP request, whether SOAP-based or otherwise, may even trigger the kickoff of an entire business process. The interface to the ESB service or business process can be described using WSDL and exposed to the outside world as a first-class web service endpoint. While an ESB is by and large intended for asynchronous processing, it should also be able to process a synchronous request/reply. Figure 8-10 shows the ESB processing components involved in making a simple inbound synchronous request/reply service invocation. Figure 8-10. HTTP invocation from an "external" client can trigger an ESB service or an entire ESB process to be invoked 
Figure 8-11 shows one of the many possible interaction patterns. An ESB should be capable of interacting with HTTP requests, both synchronous and asynchronous, and inbound and outbound. This introduces the concept of an HTTP protocol handler, which allows an ESB message broker to listen for inbound HTTP or SOAP requests, much like a web server or application server would. The protocol handler performs a mapping of the HTTP content into a JMS message and places the JMS message into a queue or a pub/sub topic destination. In an asynchronous messaging environment, a request/reply is accomplished by setting up two messaging channels: one for the request and one for the reply. The channels may be either pub/sub-based or point-to-point queue-based. The service handler on the other end of the queue or topic will invoke the service, correlate the reply with the request, and place the reply on another "outbound" queue to be sent back to the HTTP protocol handler using the ReplyTo pattern. Figure 8-11 shows the interaction in more detail. Figure 8-11. Interaction pattern for a synchronous request/reply 
In the event that the service or part of the business process is temporarily unavailable, the HTTP protocol handler can generate an error back to the sender if the response time exceeds a configurable timeout period, as noted in Figure 8-11. If the service invocation generates an error, then that error will also be propagated back to the caller. 8.2.3.2 Asynchronous request/reply Interactions between an HTTP request and an ESB process or service often need more than the requisite subsecond response time required to satisfy a synchronous request/reply. This could be due to a number of reasons: The service represents an interface to an application with regularly scheduled downtime for maintenance purposes. The service represents an interface to an application, or a portion of your business that still relies on nightly batch processing and has not yet been fully brought into a real-time integration with the ESB. Therefore, the data required to fulfill the request will not be available until the next batch integration process. The process involves some human interaction, which could cause delay in getting the information needed.
In these cases, you'll need to utilize asynchronous request/reply. Figure 8-12 shows the interaction patterns for an asynchronous request/reply. Figure 8-12. Interaction pattern for an asynchronous request/reply 
This is a slight variation on synchronous request/reply. The main difference is Step 2, which sends an HTTP reply back to the sender immediately. The reply can be any valid HTTP response code to indicate success or failure. This response code indicates the success or failure of the HTTP request; it is not an indication of the actual service invocation. The "reply" to the service invocation will come at a later time (asynchronously). The implication is that the sender has asynchronous capabilities as well. The inbound request must contain a URI indicating where to send the reply, which should map to a web service endpoint that the requestor uses to listen for the reply. 8.2.4 SOAP Protocol Handler The previous discussion on request/reply was intended to be as simple as possible, and left out the details of processing the SOAP envelope and mapping it onto a JMS message and back again. Figure 8-13 illustrates the same architecture using a protocol handler that understands SOAP. Figure 8-13. SOAP protocol handler processing inbound and outbound SOAP requests 
This is a slight variation on the HTTP direct example. The main difference is the presence of a SOAP handler that can understand a SOAP envelope, and can therefore validate it and generate SOAP faults under error conditions. Figure 8-14 shows the interaction patterns using a SOAP protocol handler. Figure 8-14. Inbound SOAP request with asynchronous reply 
Note the subtle differences between the SOAP inbound processing and the previous HTTP direct example. In Step 2, validation is performed to verify that the content of the inbound request is indeed a SOAP envelope, and in Step 3, a SOAP fault is generated if the validation fails. In the case of a synchronous request/reply, a SOAP fault would also be returned if the request could not be fulfilled for some reason. Getting Some Help from JBI The Java Business Integration (JBI) specification can help provide a greater degree of protocol independence. If the ESB supports JBI, there will be a JBI-compliant binding component between the ESB and the service container. This binding component represents a contract between two vendor-supplied pieces of software: the MOM interface and the service container. JBI will normalize the message as it passes through to the service container, so it doesn't really matter how the message is packaged as long as it is supported by the binding component. More information on JBI can be found in Chapter 10. |
8.2.5 Where Do Asynchronous Errors Go? If an outbound request cannot be satisfied because a web service invocation is unavailable, the message still exists on the outbound queue. A service can be set up to retry, or to fail over to another URL if a particular web service is unavailable. If the MOM supports the notion of a centralized error location, sometimes referred to as a Rejected Message Endpoint (RME) or Dead Message Queue (DMQ), then the failed message can be placed there (Figure 8-15). Figure 8-15. Dead Message Queue handles failures from asynchronous requests 
The choice of whether the message goes to an RME or a DMQ can vary depending on the ESB or the MOM implementation. The ESB may have its own higher-level RME that's independent of the underlying MOM implementation, or it could delegate that responsibility to the MOM. Most MOMs have a DMQ concept; SonicMQ has something specifically referred to as a DMQ, and WebsphereMQ and MSMQ have something called a Dead Letter Queue. What's important is that there is a place to put errors that occur as the result of failed asynchronous requests, and that the messages are kept fully intact with a reason code explaining why they got there. The result of such failures can also vary depending on the implementation. An alert can be raised to an administration and management framework, which could cause something to happen in an administrative console. The DMQ is a queue just like any other queue. A custom error-handling service could be written using familiar queue-based APIs that are native to the MOM; this service would peel messages off of the DMQ, analyze them, and decide what to do based on individual business rules. For example, if the message contains an address header, such as a WS-Addressing header, that specifies a fault location where all SOAP faults are to be sent, the administrative application could be written to route all messages to that location. Or better yet, the ESB could be configured to automatically examine the WS-Addressing header and route messages there. This behavior of centralized error reporting and error handling is not unique to SOAP requests; it is inherent in all message processing across the ESB. This is yet another reason why a MOM is core to the ESB architecture: issues such as those addressed by a DMQ have already been solved and have infrastructure built around them. | 