The concept of an Enterprise Service Bus (ESB) was first described as "a new architecture that exploits Web Services, messaging middleware, intelligent routing and transformation" by Roy Schulte of Gartner, in the paper "Predicts 2003: Enterprise Service Buses Emerge" in December 2002. Since then, Schulte's statement has been the genesis of much discussion, research, and product development.
IBM z/OS customers have become increasingly aware of and interested in the ESB concept. Over time, some confusion has arisen as to whether ESB is a product or architecture. IBM describes the Enterprise Service Bus, first and foremost, as an architectural pattern. In fact, you can construct service buses from a variety of different underlying integration technologies and products. IBM provides several products that are well-suited to the construction of an ESB. Many customers have already used these products to construct their own ESB, and IBM's product portfolio is evolving to include more "ESB-centric" product offerings. To understand which software products and technologies can be used to build an ESB, you first need to understand the architectural aspects of the ESB.
This article provides an ESB architectural overview, and explains IBM products related to using ESBs in the context of the IBM z/OS environment.
ESB as an architecture
Enterprise Service Bus is a software architecture pattern that builds on proven enterprise integration architecture techniques that provide a flexible connectivity infrastructure. You can use an ESB pattern to effectively integrate services in a Service Oriented Architecture (SOA) environment.
A key software architecture design concept is "separation of concerns", which is the process of breaking a program or system into distinct features that minimize the overlap in functionality. Separation of concerns is a guiding principle for the ESB pattern because it seeks to remove from applications and services the burden of implementing integration features that can more reasonably be handled by an architectural infrastructure layer. The ESB reduces the number, size, and complexity of interfaces among applications and services and, therefore, simplifies those applications and services in the process. It enables the applications and services to attend exclusively to the business logic, which should be their primary focus. It enables the standardization of the integration solution that was previously delivered by a plethora of application specific approaches. Finally, by centralizing features into a single layer, you can more easily manage, secure, and maintain these features.
Many integration architects agree that an ESB must at least do the following.
- Decouple service requestors from service providers
- Route messages between services
- Convert transport protocols between requestor and service
- Transform message formats between requestor and service
As shown in Figure 1, requesters and providers are connected to the ESB, instead of to each other; therefore, they are decoupled from each other.
Figure 1. Fundamental ESB message flow
When a service requester connects to the ESB, the ESB provides its requests using messages to the service provider that offers the function and quality of service that the requester needs. The ESB, using the capabilities described above, acts as a facilitator, and is capable of handling mismatched transport protocols, mismatched message formats, and the fact that the requestor or provider do not necessarily know each others location.
The ESB accomplishes these tasks by:
- Decoupling location and identity
Requestors and providers need not know the location or identity of their counterparts. Requesters are unaware that a request could be serviced by any of several providers. This possibility improves flexibility because service providers can be added or removed without disrupting the requester.
- Communication protocol transparency
Requestors and providers need not share a common communication protocol. Requestors that use SOAP over HTTP can just as easily communicate with providers which use SOAP over JMS as they can with providers using SOAP over HTTP.
- Data format transparency
Requestors and providers need not agree on a common data exchange format. The ESB resolves format differences by transforming request and response messages into a form expected by the recipient.
- Controlled qualities of service
Requestors and providers or systems administrators declare how requests should be routed and any quality-of-service requirements such as authorization of requests, encryption and decryption of message contents, and automatic auditing of service interactions.
- Interaction mediation
Placing the ESB between participants provides an opportunity to adjust interactions using a logical ESB component called a mediation. Mediations operate on messages as they travel between requesters and providers. They are used to implement routing, transformation, enrichment, and logging functions of the ESB.
Figure 2. The ESB enables exchange of mismatched message protocols
The ESB provides a sound architectural approach to enabling a service oriented architecture. Architectures have great value in terms of informing the construction of reliable and manageable software systems. They provide the conceptual framework to guide the implementation of the desired functional capability. Construction of an operational system requires that you select software products that can provide the desired operational characteristics. The following sections describe the IBM products that can and have been used to build ESBs.
IBM ESB product offerings
Just as the conceptual and architectural underpinnings of the ESB have evolved in recent years, so too have the products used to construct them. IBM's core products for constructing an ESB are:
- WebSphere® Message Broker V6 (Message Broker)
- WebSphere Enterprise Service Bus V6.0.2 (WebSphere ESB)
Additional products that have been used to construct ESBs include:
- WebSphere Web Services Gateway (part of WebSphere Application Server Network Deployment; it is also known as WSGW)
- WebSphere Platform Messaging (part of WebSphere Application Server; also known as SIBus)
- WebSphere DataPower SOA Appliances
Many early efforts to construct ESBs where based on WSGW, SIBus, and earlier versions of Message Broker. Those approaches are giving way to solutions involving Message Broker V6 and WebSphere ESB, which are being developed and extended to more completely address the requirements of the ESB architecture pattern. WebSphere DataPower provides a hardware appliance based approach to constructing ESBs.
All have had their place in the ESB landscape, but the focus of future ESB related product deliveries will be Message Broker, WebSphere ESB and WebSphere DataPower. Discussion of SIBus and WSGW as an ESB strategy is presented here to provide an awareness of early stage ESB deployments that might benefit from migration to the more recent products that have been specifically designed and enhanced to meet ESB requirements.
WebSphere Message Broker
The introduction of WebSphere Message Broker predates the development of the ESB concept. It was originally designed to address many of the same integration issues that the conceptual ESB addresses. It continues to be enhanced to support ESB requirements.
Message Broker non-J2EE z/OS-started tasks provide the ESB runtime support. Development support is provided by the Eclipse-based Message Broker Toolkit that is deployed on a developer's workstation. The programming model in the toolkit is based on modeling message formats using the tooling and binding those models to mediations (message flows in Message Broker terminology). This enables Message Broker to render any message format into an internal data independent format (message tree in Message Broker terminology) that Message Broker mediation primitives (nodes) can act on. Finally, it provides the capability to package mediations and deploy them to the Message Broker runtime environment.
Message Broker is ideally suited to ESBs where legacy data formats such as EDI, SWIFT, FIX, COBOL Copybooks, HIPAA, ACORD, and HL7 are the norm. You can also model proprietary formats with Message Broker. It supports open standards such as XML and SOAP.
The Message Broker Toolkit lets you use a "wiring diagram" metaphor to graphically construct mediations (message flows) by connecting together operation primitives (nodes).
Message Broker Toolkit provides these primitives (and many more):
- WMQ â Receives/sends messages using WebSphere MQ
- HTTP(S) - Receives/sends messages using HTTP(S)
- Insert - insert data into relational database tables
- Update - update data in relational database tables
- Delete - delete data from relational database tables
- Filter â provides routing based on message contents
- Service Registry Lookup â Lookup services in WebSphere Service Registry and Repository information (support Pac ia9l)
- XML Transform â transformation using XSLT
- Compute â transformation using Java™ or ESQL
Flow Control and Exception
- Input/Output â terminates sub-flows
- TryCatch â exception handling
- CICS Request â executes CICS transactions (Support Pac ia12)
- VSAM â access to VSAM datasets (Support Pac ia13)
- If the supplied primitives are insufficient to meet your requirements, you can construct custom primitives using Java.
Message Broker was originally based on messages delivered by WebSphere MQ, but has evolved to support messages delivered by a variety of protocols including:
- IP real-time/multicast
- web services
When hosted on z/OS, Message Broker takes advantage of many z/OS features to assure availability, scalability, auditability, and performance.
Availability and workload management
Message Broker is Automatic Restart Manager (ARM) enabled. Brokers registered with ARM can be restarted automatically on either the same z/OS image or another available image.
To improve availability, you can enable Message Broker to take advantage of WebSphere MQ Clustering in environments that are not SYSPLEX enabled. The WMQ Cluster assures that any newly arrived messages will be delivered to a remaining broker when any broker in the cluster fails. Even though messages that arrived at the broker prior to a failure may be marooned, this "shared nothing" configuration coupled with ARM support is a substantial availability improvement in the absence of SYSPLEX support.
Message Broker relies on the SYSPLEX aware resource managers WebSphere MQ and DB2®. You can make the queues and tables used by Message Broker available to any image in the SYSPLEX. Message Brokers that participate in a WMQ queue sharing group can continue to process messages on any remaining z/OS image that has a queue manager in the queue sharing group. Because of the SYSPLEX shared resources, no message destined for the broker can become trapped in a local resource manager, unlike what would happen with "shared nothing" configurations.
An ESB is a critical piece of the enterprise infrastructure that must be continuously available. Message Broker exploitation of SYSPLEX, ARM, and WMQ Clustering features provides a means to assure the ESB is highly available.
Workload management is also an important aspect of any ESB platform. You can use the z/OS Workload Manager (WLM) with Message Broker to make sure resources are available for the most important work entering the system. Message Broker partitions processing activities into Execution Group address spaces. You can assign these address spaces to WLM service classes so that WLM can control Message Broker processing based on goals established for the specified service class. This practice insures that high priority requests are handled at the expense of less important work.
Scalability and Isolation
ESB enables the number of participants to increase easily over time, which increases the processing activity on the ESB. The ESB must scale in response to variation in workloads. Message Broker takes advantage of the inherent scalability of the z/OS hardware. An individual instance of a message flow runs under its own TCB; it can take advantage of the multiple CPUs available on a given System z image which allows message flows to take advantage of multiprocessing. If the workload that a message flow handles increases, the system can dynamically add more message flow instances to increase the processing capacity. Deploying the message flow across multiple execution groups also provides improved capacity. Additional scaling is also possible by deploying the message flows to multiple brokers across the SYSPLEX. All of this can be done without design or code changes and it can be done dynamically to avoid outages.
There are also scenarios, such as those imposed by government regulations in the finance industry, that require workloads to remain separated from one another. For those situations that require isolation of processing, the Message Broker execution group offers an assurance that isolation will be sustained. Execution groups are implemented as z/OS address spaces and do not have visibility into the storage of another address space.
Accounting, performance and capacity planning
Because ESB is an enterprise-wide shared resource, allocation of the operational expense to the users of the resource is a significant consideration. Message Broker is SMF enabled and records information at the message flow (mediation) level. The broker measures a broad range of flow-related and node-related metrics, including CPU, IO, and user-relevant metrics such as number of messages processed, maximum message size, and average elapsed time. Therefore, enterprise have the data to establish a way to charge for the use of a message flow.
SMF enablement, including coordinated reporting with WMQ and DB2, also provides a means for collecting important performance and capacity planning information.
WebSphere Enterprise Service Bus
WebSphere Application Server is a well-established platform for implementing enterprise scale architectures. Its support for evolving Web services standards makes it an ideal platform for service-oriented architectures. WebSphere Enterprise Service Bus is built on, and hosted by WebSphere Application Server; its focus is meeting ESB requirements in a Web services environment. WebSphere ESB 6.0.1 for z/OS became generally available on June 31, 2006 and it was enhanced in March 2007 with WebSphere ESB 6.0.2.
A WebSphere ESB augmented WebSphere Application Server provides the ESB runtime support. Development support is delivered by the Eclipse-based WebSphere Integration Developer product that is deployed on a developer's workstation. Development support is based on the Service Component Architecture (SCA) and Service Data Objects (SDO). SCA defines the model for describing service components and offers a way to assemble them into solutions; SDO defines a model for the information exchanged between these components. SCA and SDO are based on Web services standards such as Web Services Definition Language (WSDL), XML Schema Definition Language (XSD), and Web Services Policy Framework (WS-Policy).
SCA separates business and implementation logic, so that you can focus on assembling an integrated application without knowing implementation details. The implementation of services is contained in SCA components. WebSphere ESB mediations are composed into SCA modules that are deployed to the WebSphere ESB runtime.
WebSphere Integration Developer provides a simple "wiring diagram" metaphor to graphically construct mediations which requires only minimal programming skills to use. It provides the following primitives for constructing mediation modules:
- MessageLogger - writes a copy of the message to a database for future retrieval or audit.
- DatabaseLookup - retrieves values from a database and stores them in the message.
- MessageFilter - compares the content of the message to expressions configured by the user, and routes the message to the next mediation primitive based on the result.
- Endpoint Lookup - Lookup end point in WebSphere Services Registry and Repository
- XSLTransformation - transforms messages according to instructions defined by anXSL style sheet
- Message Element Setter â a simplified way to change message elements without XSLT
- Fail - throws an exception and terminates the path through the mediation flow.
- Stop - Stop primitive silently terminates the path through the mediation flow.
- Event Emitter - generate Common Base Events and send to a Common Base Event Infrastructure server
Where the supplied primitives are insufficient to meet requirements custom primitives can be constructed using Java.
Each of these primitives acts on a message delivered by a requestor to an inbound endpoint that is bound to one or more delivery protocols. It passes the message on to the service provider by an outbound endpoint that is bound to one or more delivery protocols. The protocols supported are:
- MQ Native
- SOAP over HTTP Web Services
- SOAP over JMS Web services
To support for other protocols and enterprise applications such as SAP use the IBM WebSphere Adapters with WebSphere ESB.
You assemble mediations into SCA modules and those modules are in turn packaged as enterprise archive (EAR) files. Then, you deployre that EAR file to the WebSphere ESB server like any other application; you can use either the browser-based WebSphere Administration Console or the command line based wsadmin tool can be used to deploy the mediation.
WebSphere ESB deployed on z/OS benefits from its features to assure availability, scalability, auditability, and performance. WebSphere ESB inherits these benefits by virtue of being hosted on an instance of WebSphere Application Server Network Deployment.
Availability and workload management
WebSphere Application Server ND V6 gives you the ability to group WebSphere ESB servers into a cluster. You can deploy servers within a cluster on the same LPAR or on different LPARs in a SYSPLEX. Therefore, you can enable WebSphere ESB to remain highly available, even if an application server process or LPAR fails. Automatic Restart Manager (ARM) can restart failing WebSphere ESB servers (including the controller and dependent servant address spaces) on the original image. If the server cannot be restarted on the original LPAR, then the WebSphere Application Server ND high availability (HA) Manager recovers in-flight transactions to a hot standby WebSphere ESB server on a different LPAR. You can use these capabilities to maintain high availability of the business critical WebSphere ESB.
WebSphere ESB also benefits from the proven workload management capabilities provided by z/OS Workload Manager. Workloads destined for WebSphere ESB are passed from the application server control region to the servants hosting producers and consumers that use WebSphere ESB to communicate by a WLM queue. The WLM subsystem determines where to route such requests based on the resource utilization goals you set. You can also configure the WebSphere ESB server to start additional servant instances based on WLM's understanding of current system loads and resource availability.
Scalability and isolation
A key feature of the ESB pattern is that the number of participants can be easily increased over time. The WebSphere ESB Server exploits the inherent scalability of the multiple CPU zSeries hardware that is delivered by the multi-processing capabilities of the application server and z/OS. Scaling across systems is accomplished by deploying multiple instances of the WebSphere ESB Server within a cluster that spans LPARS in a Sysplex.
For scenarios where regulation may require separation of workloads, you can deploy multiple WebSphere ESB cells and clusters, and segretate traffic accordingly. Isolation of the WebSphere ESB server cells is assured because they run as separate z/OS address spaces which do not share resources.
Accounting, performance and capacity planning
WebSphere Application Server is SMF enabled. You can use information recorded by SMF to provide allocation of operational expense, performance analysis, and capacity planning for WebSphere ESB.
WebSphere Platform Messaging
WebSphere Application Server V6 introduced a new messaging engine written completely in Java. It serves as the default JMS provider for WebSphere Application Server V6. It provides many of the capabilities required by an ESB. This support is also known as the Service Integration Bus (SIBus).
SIBus provides a decoupling mechanism; service requesters and service providers connect to the bus to exchange requests, instead of with each other. It accepts inbound Web services requests by SOAP/HTTP or SOAP/JMS, and supports outbound responses through SOAP/HTTP, SOAP/JMS, and RMI/IIOP; therefore, it can provide protocol conversion. It also provides a mediation programming framework that enables messages to be manipulated as they pass through the bus.
The core components of the SIBus messaging engine are:
- The Bus
The transport mechanism that enables messages to be exchanged between the requester and provider. It is a scalable distributed entity in a WebSphere Application Server ND environment.
Logical entities owned by the Bus, where requestors send their messages and providers retrieve them, providing decoupling. Messages can be routed between destinations before they reach the intended provider.
Java classes that can operate on messages as they travel through the Bus. They are bound to specific destinations. Mediations can use XSLT to perform transformations, examine message content to provide dynamic routing decisions, can log messages, and amend the content with data from a database.
Is WebSphere ESB just another flavor of the SIBus? Although they provide similar functions, WebSphere ESB is far easier to deploy and use. You must manually construct SIBus mediations as Java classes, without any supporting tooling. There are no pre-built mediation primitives provided. The developer must custom code request/reply correlation logic.
For WebSphere ESB, you use WebSphere Integration Developer tooling wich includes a visual construction environment with pre-built primitives designed to speed the development of mediations. It provides automatic correlation of request and response messages. The combination of WebSphere ESB and WebSphere Integration Developer creates a powerful development and run time tool set to speed development of the ESB significantly beyond what is available in SIBus.
WebSphere Web Services Gateway
The WebSphere Web Services Gateway (WSWG) is a feature introduced in WebSphere Application Server ND V5 that lets you make your internal Web services available externally, and make external Web services available to your internal systems. In WebSphere Application Server ND V6, it became a fully integrated part of the Service Integration Bus. It has been used as a deployment platform for ESBs focused on communication between enterprises. It provides a framework to safely exchange messages between service requestors and service providers that reside in different enterprises. It supports what has been described as the "Gateway-ESB" pattern.
WSWG provides some of the basic capabilities of the ESB pattern. It decouples service requestors from service providers by introducing a SOAP Proxy Service between them. It accepts inbound traffic as SOAP/HTTP or SOAP/JMS. Outbound traffic is delivered by SOAP/HTTP, SOAP/JMS, or RMI/IIOP. It is, therefore, capable of protocol transformation. It provides mediation capabilities (transformation, routing, and enrichment) by both SIBus mediations and JAX-RPC Handlers. Both are implemented by Java classes, and no specific development tooling support is provided. It also takes advantage of both WebSphere Application Server security and the WS-security standard to assure safe inter-enterprise communication.
Like WebSphere ESB, WSWG is an extension of WebSphere Application Server Network Deployment and derives all of the benefits that WebSphere Application Server ND provides. It too inherits z/OS availability, scalability, and reliability attributes through WebSphere Application Server ND. The run time provides a set of capabilities that are sufficient for building a gateway ESB, but it lacks associated development tooling.
WebSphere DataPower Appliances
WebSphere DataPower Appliances are network hardware devices with embedded messaging capabilities. These devices provide impressive message processing speed and can offload bandwidth, CPU, and memory intensive processing to a dedicated device.
WebSphere DataPower Appliances are a new addition to IBM's product line and were introduced through the acquisition of DataPower in October of 2005. Their relevance from a z/OS perspective lies in the fact that they can offload significant message parsing and security overhead from z/OS, freeing up resources for other work.
WebSphere DataPower devices are unique in terms of network devices because they operate at the higher "message" level instead of at the "packet" level, so they have visibility into, and can take action of, application level content. The specific offerings are:
XA35 XML Accelerator
The XA35 is focused specifically on offloading XML processing from overtaxed servers. It can validate XML (XML Schema) and transform between XML formats using XSLT.
XS40 XML Security Gateway
The XS40 focuses on comprehensive XML Security including Web services transactions, encryption, firewall filtering, digital signatures, schema validation, WS-Security, XML access control, and XPath. It includes all the capabilities of the XA35 XML Accelerator as well.
XI50 Integration Device
The XI50 includes the capabilities of both the XA35 XML Accelerator and the XS40 XML Security Gateway. In can also process non-XML messages including COBOL copybook, CORBA, ISO 8583, ASN.1, and EDI, and handles routing and protocol transformation.
What does a DataPower Appliance have to do with ESB? Like the other products discussed in this article, the XI50 Integration Device provides decoupling, protocol and data transformation, routing, and security capabilities. The device does not persist messages or perform two phase commit operations. In limited applications, it can provide ESB-like capabilities. It is an evolving technology. Today, you can use these devices to complement the other IBM offerings especially where security and processing offload are a concern.
Which product should you use?
There currently is no easy answer to that question. Enterprise Service Bus is a sound architectural framework that helps to enable service-oriented architectures as well as older Enterprise Application Integration approaches. Like most architectures, implementation details are often driven by issues such as existing software and skill investments. You can begin to decide by partitioning the problem in the following ways:
Web Services standards-based ESBs
For those situations where advanced Web services standards are critical, the capabilities provided by WebSphere ESB and WebSphere DataPower should immediately come to mind. Although WSWG and SIBus both provide some capabilities in this area, consider WebSphere ESB and DataPower which provide additional function and tooling.
Legacy standards-based ESBs
In most enterprises there is a large business application inventory that is based on legacy standards and protocols. As important as Web services, SOAP, XML, and so on are, enterprises need to continue to support legacy standards such COBOL copybooks, EDI, and proprietary third party formats and protocols. For these situations today, consider WebSphere Message Broker.
Inter-enterprise ESB gateways
Where inter-enterprise gateways are concerned, WebSphere Web Services gateway and DataPower provide excellent options to mediate traffic between enterprises because of the additional security aspects they provide.
Because the ESB landscape continues to evolve, it is likely that most large enterprises will need to consider federating early stage ESBs. In all likelihood, multiple ESB deployment platforms will still be a reality for some time to come. Products will evolve to more completely cover the ESB landscape.
Why host the ESB on z/OS?
As deployment of Enterprise Service Bus infrastructures becomes more common they will become critical pieces of an enterprise's ability to conduct business. All of the characteristics of z/OS that make it desirable for mission critical workloads also make it an excellent platform for a mission critical integration backbone such as the ESB. To take such an important role in modern business, the ESB must have access to the well established availability, reliability, performance, and security of the z/OS platform. Using an ESB also provides a new flexibility in reusing the enormous application inventory that currently exists on z/OS. It can accelerate modernization efforts by providing a standard means for exposing z/OS based services to consumers both on and off the z/OS platform.
The core ESB products discussed above, Message Broker and WebSphere ESB, are both available on z/OS. The other supporting technologies are also available on z/OS, with the exception of DataPower which plays a special role in optimizing the use of z/OS resources.
What does your z/OS staff need to do to get started?
The concept of the Enterprise Service Bus is now at least three years old; it draws on earlier concepts from Enterprise Application Integration. z/OS architects and developers have addressed integration challenges for many more years. Those architects and developers can begin by leveraging their existing understanding of integration techniques and augmenting that with specific information on ESB architectural patterns. For an excellent description of ESB as an architectural pattern, see the IBM Redbooks listed in Resources.
Second, architects and developers must familiarize themselves with the product options described earlier. Many z/OS staff members are already familiar with WebSphere Message Broker; WebSphere ESB is new to z/OS. See Resources for more information on all the products discussed in this article. There are many more detailed articles as well at the IBM developerWorks website.
The construction of an ESB is an inherently incremental process. You do not need to approach it initially as an enterprise wide project, although that would be the ultimate goal. Selection of small pilot projects that focus on reuse of existing software components is an ideal way to start. This approach enables a team to scope a project that can be delivered in a reasonable amount of time while gaining skill with the deployment platform selected.
Enterprise Service Bus is an architectural concept that is well supported by the IBM product portfolio, which is composed of new and mature products that will continue to be enhanced to meet the evolving requirements of the ESB. Using an ESB will become a critical system resource for many enterprises and using an ESB hosted on z/OS will provide the availability, reliability, manageability, and security necessary. Because the ESB is an evolution of earlier EAI approaches IT staff can leverage existing understanding of those approaches to quickly come up to speed on ESB.
- IBM Redbook: Patterns: Implementing an SOA Using an Enterprise Service Bus, SG24-6346-00.
- IBM Redbook:Patterns: Integrating Enterprise Service Buses in a Service-Oriented Architecture, SG24-6773-00.
- IBM Redbook: WebSphere Version 5.1 Application Developer 5.1.1 Web Services Handbook, SG24-6891-01. Chapter 10. Web Services Gateway.
- IBM Redbook: WebSphere Version 6 Web Services Handbook Development and Deployment, SG24-6461-00. Chapter 22. Web services and the service integration bus.
- Increasing IT flexibility with IBM WebSphere ESB software
- IBM WebSphere Developer Technical Journal: Building an Enterprise Service Bus using WebSphere ESB -- Part 1. An introduction to using WebSphere ESB, or WebSphere ESB vs. SIBus
- IBM WebSphere Developer Technical Journal: Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 1. Introduction to WebSphere V6 Messaging Resources
- The value of WebSphere Message Broker V6 on z/OS
- WebSphere Enterprise Service Bus resources
- WebSphere Message Broker resources
- WebSphere Enterprise Service Bus for z/OS V6.0.1 Product Overview (GC34-6762-00)
- WebSphere Enterprise Service Bus library
- WebSphere Message Broker: Delivering business value through an advanced enterprise service bus