ESBs have become the cornerstone of many SOA deployments, providing a reliable and flexible integration backbone across enterprises. However, the Cloud Computing model has given ESBs a new lease of life as the link between the safe, secure world behind the firewall and the great unknown of the Cloud.
As ESB vendors look for more reasons for users to buy their products, the Cloud model has emerged at just the right time. Companies looking to take advantage of Cloud Computing quickly discover that because of key inhibitors like data location, they are forced to run applications that are spread between the Cloud and the Enterprise. But the idea of hooking up the safe, secure world of the enterprise, hiding behind its firewall, and the Cloud which lies out in the big, wide and potentially hostile world is frightening to many. Step forward the ESB – multi-platform integration with security and flexibility, able to hook up different types of applications and platforms efficiently and securely.
More and more ESB vendors are now jumping on the ‘Cloud ESB’ bandwagon. Cast Iron, now part of IBM, made a great name for itself as the ESB for hooking Salesforce.com with in-house applications; Open Source vendor MuleSource has been quick to point to the advantages of its Mule ESB as a cost-effective route to cloud integration; Fiorano has tied its flag to the Cloud bandwagon too, developing some notable successes. Recently, for instance, Fiorano announced that Switzerland’s Ecole hôtelière de Lausanne (EHL) had adopted the Fiorano Cloud ESB to integrate 70 on-premise applications with its Salesforce.com CRM system.
Over the next few months, we expect to see a growing number of these ‘cloud ESB’ implementations as more companies realize the potential benefits of combining ESBs and Cloud.
I was recently doing some research into the latest state of play in the Enterprise Service Bus (ESB) market, and decided to take a look at Microsoft’s ESB – or rather its pretend ESB.
I had never been sure about Microsoft and SOA- it tends to focus instead on BizTalk and the Microsoft world. However, recently I have heard a lot of encouraging noises from Microsoft about its belief in SOA, and how it sees BizTalk as a key component in an SOA architecture for application design and deployment. But I must admit I had not realized that Mircosoft gave any credence to the ESB concept.
With an element of hope I delved into Microsoft’s ESB stuff – only to be disappointed to discover it is not an ESB product at all, but ’ESB Guidance’, a collection of samples, templates and artifacts to deliver ESB functionality. In essence, Microsoft does not yet acknowledge the existence of the ESB class of product, preferring instead to take the old IBM line of a few years back pretending that an ESB is a style of implementation rather than a product. However, I thought, this doesn’t really matter as long as Microsoft offers ESB functionality, however it packages it.
But then sad reality dawned. Microsoft ESB Guidance is not even supported. It is a collection of samples and pieces offered on an ASIS basis, take it or leave it. Use it if you like, but don’t come to us with any issues or problems. How disappointing. See the Microsoft Guidance notes -
The Microsoft ESB Guidance for BizTalk Server R2 is a guidance offering, designed to be reused, customized, and extended. It is not a Microsoft product. Code-based guidance is shipped “as is” and without warranties.
So, it looks like Microsoft isn’t really on the ESB bandwagon yet. The new release of BizTalk Server this year may introduce a ‘real’ ESB, but at this point in time Microsoft appears to be paying lip-service to SOA compliance, but not actually doing much about it.