Anatomy of an Integration Node in IBM Integration Bus v9

A virtual/physical machine can contain one or more integration nodes (in previous releases of IBM WebSphere Message Broker these were called brokers).

The following diagram shows the anatomy of integration nodes, running active/active on a two virtual or physical machines.
Anatomy of an integration node

Each integration node manages one or more integration servers (in previous releases of IBM WebSphere Message Broker these were called execution groups). The integration servers host the integration flows.

Each integration server runs in a separate operating system process, with its own JVM inside the process for IBM Integration Bus and user Java code. The same integration node also hosts the runtime for Graphical Mappings, a Microsoft .NET Common Language Runtime (Windows only) for hosting integration code and calling Microsoft .NET APIs, as well as runtimes for other integration logic (ESQL, C/C++, PHP etc.). As a result, using a mixture of logic within the same integration is extremely efficient and does not involve any network communication.

An individual integration server can host many different integrations, and each individual integration can have many threads.

It is common to use multiple integration servers within an integration node, to isolate one piece of integration logic from another, as well as to aid vertical scale.

For example, a dedicated integration server might be allocated to a particularly important business unit to isolate it from other business units from a security and risk perspective.

Equally, higher performance might be obtained by allocating multiple separate integration servers to an individual integration flow, to scale beyond process-wide resources (such as unavoidable process-wide locks or JVM garbage collection).

Integration servers can accept direct HTTP connections. However, it is common to use the HTTP listener of the integration node to direct traffic to the appropriate integration server.

The integration node has a one-to-one relationship with an MQ queue manager. The MQ queue manager enables MQ, JMS and SOAP/JMS service interfaces to be exposed directly from IBM Integration Bus, and the MQ queue manager is used internally by a number of built-in functions of the integration node – including as an XA transaction manager.

It is also possible to connect remotely to another MQ queue manager, or to a 3rd party JMS provider, from Integration flows (using JMS nodes).

1 comment on"Anatomy of an Integration Node in IBM Integration Bus"

  1. Samuel Alejos April 10, 2019

    So, its interesting to know which components are shared through Integration server and nodes. Indeed I have a doubt, in the case of mq integrtions, is it mandatory to have the mqmanager installed in the same machine than the integration node?

Join The Discussion

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