When you design your IBM Integration Bus topology to run in parallel with and/or eventually replace your WebSphere Enterprise Service Bus (WebSphere ESB) topology, you will need to make some key decisions. This section highlights some of the key similarities and differences between the technologies, to help you choose the right IBM Integration Bus topology for your integration needs.

WebSphere ESB is built upon an IBM WebSphere Application Server run time, and exploits the network deployment features of that runtime to provide scalability and high availability, along with a pre-requisite database used for storing run time state.

IBM Integration Bus has its own custom-built run time, suitable for hosting all forms of integration logic (Graphical, Java, Microsoft .NET, C/C++, ESQL). It contains a built-in Messaging run time (for JMS and MQ workloads), a distributed Global Cache for storing state, and connects to a wide range of Databases – although it does not require a Database to run.

In this section we consider the similarities and differences between the two technologies for two of the most common interfaces exposed by an ESB: HTTP and JMS. This includes SOAP/HTTP, SOAP/JMS, REST, XML/MQ and any other data formats coming in via a HTTP/HTTPS, JMS or MQ.

The back-end systems connected into the ESB are not covered explicitly, as they tend not to affect the topology choice.

Assumption: We assume you have a Network Deployment WebSphere ESB environment, with multiple active nodes. All of the diagrams show two active nodes, although you might have more than two in your environment.

Note: We will use the general term ‘integration flow’ to refer to the integration logic (mediation modules or message flows) built inside WebSphere ESB or IBM Integration Bus.

Join The Discussion

Your email address will not be published. Required fields are marked *