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.

IBM Integration Bus licensing principle on distributed explained

CPU Licensing principle for Distributed

Proper license has to be acquired in order to use IBM Integration Bus in a licensed environment.

The license agreement is related to the number of CPUs used by the IBM Integration Bus (IIB).

The number of CPUs used depends on the environment where the IBM Integration Bus is installed as the following figure shows:

If the IBM Integration Bus is installed on a non virtualized machine then the number of CPUs to take into consideration for license point of view is the total number of CPUs installed on that machine.

In a x86 virtualized environment, it is possible to allocate a variable number of CPUs to a virtual machine. In this environment the IIB is running in a virtual machine and the number of CPU to take into account for a license point of view is the number of virtual CPU allocated to this virtual machine with a maximum set to total number of physical CPU. This mean that if IIB is running in only one virtual machine having one virtual CPU, the number of CPU to take into account for the license will be 1 even though this virtual CPU is mapped to a physical CPU that is shared with other virtual machines. In the same way, if IIB is running in two virtual machines sharing the same physical CPU, each virtual machine having 1 virtual CPU mapped to the same physical CPU, the number of CPU to take into account for the license will be 2.

In a Power/ZSeries, it is possible as in the distributed environment to allocate a variable number of CPUs to a LPAR. However in this environment it is possible to share a CPU between LPARs with the restriction that a minimum of one CPU has to be taken into consideration for the license point of view. If we take the same example used above in the x86 environment then if IIB is running in only one LPAR having a micro partition of CPU, meaning that the LPAR is sharing the physical CPU with other LPARs, the number of CPU to take into account for the license will be 1. However if IIB is running on two LPARs sharing the same physical CPU, then the number of CPU to take into account for the license will still be 1.

IBM Integration Bus Editions Licensing

There are three mains edition available for IBM Integration Bus: express, standard and advanced.

The express edition targets customers that have a basic set of features and have only low capacity requirements. In this mode only a subset of message flow nodes can be used and only one Integration Server can be created by Integration Node. The available subset of nodes can be found at the following link (http://www-01.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/an67720_.htm?lang=en)

In the Standard Edition all the message flow nodes can be used (except the decision service node used to execute business rules and that requires specific entitlements). The limitation in this mode is that only one Integration Server can be created by Integration Node. The license doesn't restrict however the number of integration nodes.

In the Advanced Edition there are no limitation on the number of Integration Server per Integration Node. The restriction on the decision service remains.

The following figure shows this principle for the Standard and Advanced Edition:

Please note that this is my point of view and I am speaking for myself and not on behalf of IBM.