WebSphere ESB provides a set of standard templates for deployment topologies, which share a common approach and cover the vast majority of deployment scenarios. The most popular of these is the “Remote Messaging and Remote Support topology pattern”, which is commonly referred to as the golden topology.
The following diagram summarizes a deployment based on a golden topology with two physical/virtual machines processing data coming in via HTTP and JMS.
The following table lists the key features of the WebSphere ESB golden topology shown above, and gives a high level summary of the equivalent feature in IBM Integration Bus.
|WebSphere ESB golden topology feature||IBM Integration Bus feature|
| 1) Active/active AppTarget cluster
In the WebSphere ESB golden topology, the integration flows are deployed to a WebSphere Application Server cluster. This is the ‘WebSphere ESB AppTarget’ cluster in the above diagram.
When the flows are deployed (as mediation modules) to the WebSphere ESB cluster by the deployment manager of the WebSphere Application Server cell, the same flow is automatically deployed to every member of the cluster.
| Active/active deployment of IBM Integration Bus
The same Integration flow can be deployed to as many Integration nodes as required, to build an active/active environment. See the Active/active and active/passive – Scale and High Availability (HA) section for details.
| 2) Active/passive Messaging cluster
The Messaging technology is the IBM WebSphere Application Server default messaging provider, also known as the Service Integration Bus (SIBus).
The message layer has multiple uses, in two broad categories:
Storing transient state, such as correlation state for asynchronous request/reply processing
SIBus messages are persisted to the Database for High Availability, so that the same messages are available regardless of which server the SIBus Messaging Engines are running on. If you have multiple AppTarget clusters, you might have multiple Messaging clusters.
| Multiple features, including Messaging
The Messaging technology is IBM WebSphere MQ, and each active Integration node has its own active Messaging runtime (a WebSphere MQ Queue Manager).
Support for active/passive operation of a whole IBM Integration Node (including the Messaging layer) is also provided, using either a network-attached filesystem, or fibre/SCSI storage switched via an external HA clustering solution. See the Active/active and active/passive – Scale and High Availability (HA) section for more details on HA failover.
It is often incorrect to assume that because Messaging was used in WebSphere ESB to solve a particular problem, using Messaging in the same way will be simplest and most efficient solution in IBM Integration Bus.
See the Correlation state section, for the options available when converting Integration flows that store transient state.
See the JMS and SOAP/JMS Exports section, for the options available when converting Integration flows that expose a Messaging-based service interface.
| 3) Additional use of the Database for audit and error handling
As well as for SIBus messages, the Database is also used for the Failed Event Manager and the Message Logger mediation primitive.
Note: other built-in functions of WebSphere ESB use the Database, such as event sequencing and the Proxy Gateway Business Space widget, but are not discussed in detail in this article.
|Connectivity to an external database, including Record and Replay
IBM Integration Bus does not require a database to operate, and as a result no database entitlement is supplied with the product.
Full connectivity is provided to an external database of your choosing, and efficient features are provided out of the box for for storing audit data in a database. See the Storing Data for Audit and Error Handling section for details.
| 4) Support / Web cluster
Some ancillary services in WebSphere ESB are hosted in a separate cluster, including the Business Space powered by WebSphere Web 2.0 administration interface, and processing for the Common Event Infrastructure (CEI).
| Web Administration
IBM Integration Bus Web 2.0 administration interface is built into the Integration Node, and no additional infrastructure is required. See the Web administration section for details.
For customers emitting events from WebSphere ESB to external business monitoring solutions via CEI, see SupportPac IA9V.
| 5) HTTP Server
This optional layer is used to hide complexity when there are multiple AppTarget clusters, to redirect traffic in the case that one server in a cluster is down, as a simple reverse proxy layer, and as part of the workload management strategy for the cluster.
| Built-in HTTP routing, and support for an external HTTP Server
Routing from a single HTTP endpoint to multiple active runtimes is performed within the IBM Integration Node. As a result no entitlement to a HTTP Server is supplied with the product.
Use of an external HTTP Server, including IBM HTTP Server, is supported by IBM Integration Bus. See the Hosting both technologies on the same infrastructure section for an example of how use IBM HTTP Server to build a unified URL scheme for WebSphere ESB and IBM Integration Bus.
| 6) DataPower / Gateway / Load Balancer tier
There is almost always a physical appliance / IP sprayer / IBM WebSphere Edge Components layer in front to workload balance traffic across the machines.
This is generally present even if there is a HTTP Server layer, as there is usually one HTTP Server per machine for high availability reasons.
Including IBM WebSphere DataPower as part of this layer to make it gateway, rather than just a load balancer, adds SOA policy enforcement, security processing and XML threat protection for SOA interfaces exposed across Enterprise boundaries.
| DataPower / Gateway / Load Balancer tier
The majority of WebSphere ESB customers using a WebSphere DataPower gateway or load balancer will see no change to this tier of their architecture as a result of converting to IBM Integration Bus. No entitlement for WebSphere Edge Components is supplied with the IBM Integration Bus product.
IBM Integration Bus also has full support for TCP/IP workloads, such as ISO8583, in addition to HTTP workloads. Use of a load balancing tier is also common for inbound TCP/IP workloads.