Many organizations that have made .NET an important part of their IT landscape will start with the belief that BizTalk Server is the logical choice for an integration platform. What I wanted to do in this post is point out some of the capabilities delivered by IBM Integration Bus (IIB) that challenges this assumption.
To start, IIB version 9 introduces several new capabilities that will make .NET developers more productive.
If you’ve made a significant investment in .NET then that may be a direct result of having invested in Microsoft applications like Dynamics CRM. IIB 9 includes patterns for Dynamics CRM that helps transform and synchronize client data with another system, including a pattern that can assist with integration to SAP (see more here). There is another pattern that allows a Microsoft Dynamics CRM application to be updated by using various other mechanisms, including WebSphere MQ, HTTP, or flat files (see more here)
.NET Input Node
This IIB node provides an easy way to drive message flows that can receive data from other applications that have Microsoft .NET or Component Object Model (COM) interfaces. The node includes Visual Studio templates for C#, VB, and F#, which can be used to get data from MSMQ. This article provides details on how to use the .NET Input Node.
Additionally, IIB 9 includes sample code for the node that shows how to integrate with MSMQ.
These features represent an enhancement to the .NET Framework support provided in WebSphere Message Broker 8 (the name used for the previous version of IIB), which allowed you to run .NET code or applications inside of Broker.
IIB Performance Advantages
But getting a fast start is not the only reason to choose IIB over BizTak. In a study conducted by Summa Technologies, Message Broker was shown to deliver more than 6X better performance in terms of response time for web service and file based integration scenarios. The actual throughput advantage for Message Broker was even greater – 450 transactions per second (tps) for Broker vs. 7 tps for BizTalk, in both web service and queuing scenarios. Batch file throughput testing resulted in more than a 6X advantage for Broker.
This video helps to illustrate IIB’s performance advantage:
A developer wrote on MSDN on the topic of improving BizTalk’s performance when using the ESB Toolkit, eventually resorting to writing code to see if performance could be improved:
“I decided to create a new, faster version of the Transform Service. Once again I started from the code of the original TransformService class, but this time I radically changed its code to cache map metadata and exploit the capabilities provided by the XslCompiledTransform class.”
This resulted in a maximum of 12.2 tps using this code, which nearly tripled the original figure of 4.68 tps in this developer’s testing. These results seem to align well with Summa’s tests of BizTalk performance although unfortunately for BizTalk, the performance achieved still pales in comparison to what IIB can deliver (not to mention that the code created would then have to be maintained and re-tested with every new release).
In an upcoming post I am going to take a closer look at developer productivity and how IIB goes about delivering a first class experience to .NET developers.