Chapter 4. Technology capabilities for an additional ESB
4.2 A review of ESB technologies
This section provides a short review of various ESB topics that will be used when discussing the three additional ESB examples later in this chapter.
4.2.1 WebSphere Integration Reference Architecture
The WebSphere Integration Reference Architecture provides a comprehensive set of services to enable business integration. The services provide the breadth of functionality needed to solve integration requirements. More important, the component services can be implemented in stages to allow incremental evolution on a project-by-project basis while working toward an enterprise integration solution architecture. Although specific projects may not require all of these services, enterprise-level integration will require the ability to add these functional capabilities to the integration architecture. The resultant architecture provides for separation of concerns by allowing business logic, control logic, routing, and transformation logic, to be loosely coupled and, as a result, more
flexible to change. At the organizational level, this approach facilitates simpler integration solution development and enhances maintainability and operation of the solution.
The WebSphere Integration Reference Architecture shows the key integration functions that are required for comprehensive, enterprise-level solutions. These service groupings provide the ability to apply separation of concerns to
enterprise integration requirements and lead to a convergence with the principles of SOA as they apply to integration.
At the core of the WebSphere Integration Reference Architecture is the Connectivity Services layer. This component provides the infrastructure to support and instantiate the Enterprise Service Bus (ESB) architectural pattern and is shown in Figure 4-1.
Figure 4-1 WebSphere Integration Reference Architecture
The ESB architectural pattern within the WebSphere Integration Reference Architecture can be implemented using the service integration bus component of WebSphere Application Server or with WebSphere Business Integration
Message Broker. There are additional product options within the Connectivity Services layer but these are outside the scope of this book.
Development Services
Interaction
Services ServicesProcess InformationServices
Partner Services Business Application Services Application and Information Assets Infrastructure Management Services Business Performance Management Services
4.2.2 General capability discussion
The following section provides a general discussion and background information for some of the topics that will be discussed in the two examples later in this chapter.
WebSphere MQ and JMS
WebSphere Application Server provides support for the JMS API and for using WebSphere MQ as the JMS provider. JMS defines a message format that JMS providers must support. Many JMS providers (such as WebSphere MQ) that were designed before JMS was finalized have to provide a mapping between MQ and JMS message formats. Within WebSphere MQ the MQRFH2 is optional and is omitted in many native WebSphere MQ applications, but for JMS messages it carries JMS-specific information. Therefore, it should always be included in a WebSphere MQ message when the sender knows that the receiving destination is a JMS application. Figure 4-2 on page 68 shows how the structure of a JMS message is transformed to a WebSphere MQ message and back again.
The IBM Enterprise Service Bus strategy:
In September 2005, IBM announced two products intended to be the primary solution for building ESBs:
WebSphere Enterprise Service Bus V6
Delivers an ESB with Web services connectivity and data transformation. WebSphere Message Broker V6
Delivers an advanced ESB with universal connectivity and data transformation.
At the time this book was written, WebSphere Enterprise Service Bus was not generally available. In lieu of this product, the service integration bus of WebSphere Application Server V6 is used in the redbook scenario implementations to build ESB solutions.
For more information about the IBM ESB strategy see:
Figure 4-2 Mapping of WebSphere MQ and JMS message formats
SOAP/JMS support
When sending or receiving a JMS message as part of a Web services interaction using SOAP/JMS and using WebSphere Application Server V6 as the consumer or producer, additional properties are required. Chapter 10, “Directly Connected heterogeneous ESBs” on page 241 discusses a suggested mapping for
SOAP/JMS messages flowing between WebSphere Application Server V6 and WebSphere Business Integration Message Broker. Knowing and understanding this mapping is important when deciding on an additional ESB and in the architectural design of the solution.
Message persistence levels
The WebSphere Application Server V6 messaging engine is a new server component that provides the core messaging functionality of a WebSphere Application Server service integration bus. As such it is the native JMS provider for WebSphere Application Server V6. A messaging engine manages bus resources and provides a connection point for applications. It provides additional persistence levels from the defined JMS delivery modes and from WebSphere MQ persistence levels. These persistence levels are shown in Table 4-3. Table 4-3 Persistence level mapping
WebSphere Application Server messaging engine reliability level
JMS delivery mode
WebSphere MQ persistence level
Best effort nonpersistent Nonpersistent NonPersistent
Express nonpersistent Nonpersistent NonPersistent
Reliable nonpersistent Nonpersistent NonPersistent
JMS Message JMS Client Data MQMD WebSphere MQ Message Copying Mapping Header Properties Data JMS Message JMS Client Header Properties Data Copying Mapping RFH2 Other Data
Linking the service integration bus to a WebSphere MQ
network
The new service integration bus component in WebSphere Application Server has been designed to allow extension to:
Other service integration buses A WebSphere MQ infrastructure
The purpose of this topic is to discuss the integration between the service integration bus component of WebSphere Application Server and WebSphere MQ since these will be frequent candidates for ESBs that have to be integrated. Using the WebSphere MQ link within the service integration bus of WebSphere Application Server you can exchange point-to-point messages, and use publish and subscribe between WebSphere Application Server and a WebSphere MQ network by viewing the WebSphere MQ network as a
foreign bus
.The WebSphere MQ link is defined on a messaging engine in a service integration bus. It makes exchanging messages very simple by automatically converting them so their characteristics are retained or mapped to similar settings.
A WebSphere MQ link engine is the messaging engine through which other messaging engines on the same bus send messages to, and receive messages from, a WebSphere MQ queue manager. This queue manager acts as a gateway to other WebSphere MQ queue managers. This gateway queue manager is represented as a foreign bus when you configure the WebSphere MQ link. Figure 4-3 on page 70 shows how messages exchanged between the messaging engine with the WebSphere MQ link and the gateway queue manager can be sent and received by other messaging engines on the same bus, and other queues on the gateway queue manager.
Reliable persistent Persistent NonPersistent
Assured persistent Persistent Persistent
WebSphere Application Server messaging engine reliability level
JMS delivery mode
WebSphere MQ persistence level
Figure 4-3 Communication between the service integration bus and WebSphere MQ