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.
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.
An individual integration server can host many different integrations, and each individual integration can have many threads.
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).