IBM Integration Bus Editions compared

IBM Integration Bus Edition/Mode comparison

This post will explain the difference between the different IBM Integration Bus edition.

IIB is available in four different modes described at the link http://goo.gl/oIVCLM.
Comparison of the different editions is also provided at the page IBM Integration Features.

These are (from the higher to the lower capacity): Advanced, Standard, Scale and Express.
Note that

• There is a trade up path from any lower version to a higher one. 
• The mode can be changed without requiring to reinstall the product, it's just a command line

In this post I will not linge on the scale mode as it was introduced to have a migration path for users running on WebSphere Enterprise Service Bus.
As this later will be end of support in 2018, users have the possibility to convert their WESB licenses to IBM Integration Bus in scale mode. This mode as some restrictions to match what WESB was offering.

The following schema provides an overview of the Advanced, Standard and Express mode:

Express vs Standard

The Express and Standard mode have a common limitation: they can only have one Integration Server per node. This will be explained in further detailed later when comparing Advanced to Standard.
The difference between Standard and Express stands in features that are provided.
The features available for each mode are provided here at the knowledge center features per operation mode.
Express only provides a subset of features that are already very rich. You can implement flows using most of the nodes, performs transformations using graphical mapper, java, .NET.

Please find after the most important features that are not provided and would help you decide if this mode is appropriate for your usage:

• Resequence nodes: to resequence the messages order using a built-in node
• ERP nodes: SAP, SIEBEL, ...
• CICS, IMS nodes
• File Read node: to retrieve a file content in the middle of a flow
• DataBase Input node: polling a database using a built-in node
• Collector node: been able to collect messages from different sources using a correlation
• Policy Enforcement Point node (PEP): been able to enforce the security in the middle of a flow
• MQ Managed File Transfer nodes
• ESQL code

Standard vs Advanced

In Standard all the features are allowed: in term of features, there is no difference between standard and advanced.
The difference stands in the number of Integration Server that can be defined per Integration Node.
Find at the following post the overview of the runtime if you are not familiar with the terms:  a-view-of-ibm-integration-bus-runtime.


This overview will help to understand the main differences and implication of the different editions:

• Isolation: on advanced mode, you can have multiple integration server per Integration node. This means that you have a greater isolation when running on advanced mode as you can have flows deployed on separate integration server. You gain isolation in term of memory and address spaces.  If one flow makes the process to crash, it will not affect flows deployed on other Integration Server. 
• Administration: you can administrate only one integration node at a time. You can administrate multiple Integration Servers of one Integration Node through the same web user interface. If you have multiple Integration Node, you would need to have multiple UI. Also if you need to apply a configuration change that requires the process to restart, all the flows deployed in the Integration Node will be impacted.
• Queue Manager: in advanced mode all Integration Server of the Integration Node can access in binding mode the same queue manager associated with the Integration node (in V10, integration node doesn't required to have a queue manager - in some cases you would need to do so though). If you have multiple Integration Node it may be required to interconnect them.
• Scalability: as each Integration Server is one process, it may be possible to better distribute the load across available processors when running in advanced mode. 

If you would like to know the limitation in term of license between these two modes, please find this information at the following post ibm-integration-bus-licensing-principle.

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.