Microsoft's Enterprise Services Bus (ESB) Strategy - Part 4/4
About: This is the fourth post in a series of four about Microsoft’s strategy for Enterprise Service Bus. This post discusses Microsoft offerings in the area of ESB
Greetings,
Let me start by wishing all of you a very happy 2007. In the previous three posts I had described the core concepts behind an ESB, tried to dispel some myths about it and discussed the tangible manifestations of the concept. This post focuses on Microsoft’s offerings in the area of ESB.
Microsoft does not believe on a one-size-fits-all approach to ESB and has so far resisted the pressure to rename Biztalk or a variation of it as an ESB. Microsoft’s approach to ESB is to understand the customer’s core reasons for seeking an ESB and then propose a solution that suits the need of that enterprise. I strongly believe that this is a better approach than selling ESB-in-a-box; however, it has made some analysts unhappy who believe that Microsoft should have a product marketed under the ESB label. Based on my experience of what is being sold in the marketplace under the ESB label, Biztalk could definitely qualify as one, but I am glad that we have refrained for renaming it so far.
Microsoft has contributed to the idea of ESB as an architectural pattern and has made available some of the technology-agnostic thinking and best practices in the integration patterns book and associated articles.
In terms of the technologies some of the key offerings that address the integration issues that ESB try to resolve are as follows:
- Windows Communication Foundation
Windows Communication Foundation is a messaging API that allows you to develop a standards-based integration mechanism; WCF can help you implement an ESB as an architectural pattern. One of the best things about WCF is the richness of the API which reduces the amount of code that you have to write for infrastructure plumbing (reliable messaging, transactions, security etc.) by many orders of magnitudes. It is of course possible to implement an ESB pattern without WCF but not having to write, customize and/or generate tens of thousands of lines of code that you have to maintain, is a good reason for using WCF
- Biztalk 2006
Based on the reasons for why you want to have an ESB, Biztalk provides features like Brokered Communication, Web Services Support, integration with development tools, Business Activity Monitoring, Service orchestration and a number of others ESB features. Considering what is selling today in the market place as an ESB, Biztalk plus web services and base connecter classes can provide a superset of features and functionalities. The decision to use Biztalk as an ‘ESB’ would depend on your needs and whether you will end up building Biztalk yourself. One of the key benefits of Biztalk is the availability of adapters that greatly ease the process of ‘plugging’ in systems, for a complete set of adapters and other information about Biztalk please visit http://www.microsoft.com/biztalk/default.mspx
- Host Integration server
If your reason for implementing an ‘ESB’ was to expose your legacy mainframe systems as part of SOA than you can consider Host Integration Server. I know that it does not qualify as a pure ESB but in the real world that seems to be one of the core driving reasons behind why customers want to buy an ESB.
- Messaging software + Web Services
Finally by combining .NET 3.0 and your existing messaging software you can construct a number of features provided by the ESB
In summary, do not buy an ESB-in-a-box (yes even Biztalk) unless you understand the benefits it would provide to your IT and business, also do not build something that can buy J I know it sounds contradictory, what I am trying to communicate is that rather than starting from what’s selling as an ESB, start with your organizational needs, construct a requirements matrix and then apply that on the available choices to reach a conclusion that suits you.
Stay tuned for a series on Web 2.0 Demystified
Best regards,
Mohammad