A view of IBM Integration Bus runtime

If you are searching information on the components that IBM Integration Bus is composed of or just would like to know the terminolgy used (i.e. what is an Integration Node, an Integration Server, a message flow, ...) this post is for you !

I don't have the intention to explain every runtime components but rather provide enough information to understand the main components and the processes that are running.

First all, the IBM Integration Bus is a standalone application that is not running on a J2EE environment.
The runtime architecture provides a very strong resilience against failure and scalability capability.The core engine is very efficient and provides high performances with limited ressource usage. 
It can be easily deployed in a development workstation (development toolkit and runtime) without requiring a ferrari: I usually do demos (that includes IIB but DB2 as well) using a standard laptop having 4GB RAM.

The following figure describes the IBM Integration Bus runtime:

An integration node is composed by different processes and one queue manager. Note that in the former version of the Integration Bus, WebSphere Message Broker, the term IBM Integration Bus was called "Broker".
There are two kind of Integration node processes: those use to run the flows called Integration Servers  and those use for Integration Bus internal tasks.

The internal tasks processes are:

• TheIntegration Node wide listener, the "biphttplistener": this process is a http listener and it is started when the Integration node is configured to receive http request (http://www-01.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/bc43700_.htm?cp=SSMKHH_9.0.0%2F1-11-1-5-1-3-0-0&lang=en). It is started if the Integration node has been configured to have a Integration Node wide listener.
• The “watchdog” process, the "bipservice": it is a very small process that monitors (and restarts if necessary) the Admin Agent (bipbroker process).
• The Admin Agent (process name = bipbroker): this process is designed to monitor and administrate the Integration Servers. It performs such functions as handling deploy requests and restarting any Integration Servers that would stopped for unexpected reason. It does not process any message flows, but its size is governed by the size of the deploy requests that are being received.

The Integration servers are the processes where message flows are deployed and run. The name of the corresponding process is "dataflowengine". Message flows deployed in an Integration Server run as Threads.
Integration Servers are processes that are created by an administrator. 
IBM Integration Bus is proposed in different editions: express, standard and advanced. In the express and standard edition, only one Integration Server can be attached to an Integration Node.

All the integration servers within the same Integration Node use the same unique queue manager, the Integration Node queue manager. It is used as well to store eventual internal information as to get or put MQ messages processed by message flows.

The Integration Node queue manager is a standard WebSphere MQ Queue manager and can be administrated as any other queue manager. Even though it can be integrated into a WebSphere MQ network, using a MQ cluster or channels, and accessed by applications as a normal WMQ queue manager (using client connections for example), the usage of the Integration Node Queue Manager is restricted from a license point of view:it can process MQ messages as long as it is processed in one way or another by a message flow deployed on the Integration Node.

A message flow can be deployed on one or multiple Integration Servers. A number of instance of the message flow (corresponding to a number of threads) can be defined  on each Integration Server where it is deployed. Different message flows can be deployed on the same Integration Server.

Finally a message flow is composed by multiple message flow nodes (MQInput, MQOutput, SOAPInput, …) that are wired together.