Over the last few months I've taken a calm and considered view of ESB. Until now I have decided to 'keep out' of the foolish arguments that have been going on, that was until I read the 'ESB vs BizTalk 2004 Debate Gets Heated in Barcelona' by David A Chappell. Now in its self this shows how heated the various debates can get, then there is the logic behind the arguments, but finally the penny drops for me as to what really underlies the arguments and inparticular this one. Both David and the Microsoft guys are guilty of the same crime - we sell software, we market software and we make our living selling it as product. All of them claim to be evangilists - that b*ll*x if you'll excuse my language, what they are are product marketing people with a technical bent!!
The penny dropped for me as I researched this whole topic. My role for my company - a technology savvy software services company delivering solutions not products to customers - is CTO. I lead the companies Technology Strategy Group and have some of the finest solution architects working with me. The great thing about this is we spend time debating, researching, thinking about and architecting real solutions for real customers. We are not caught up with hype as 'it just don't deliver satisfaction' to customers. So I need to understand what this means as solutions for our customers both new and old and paraphrasing the words of D.H. Rumsfeld - 'the unkown solutions for the unknown customers' (Poetry D.H. Rumsfeld.html). So what penny dropped? Not yet my brave reader you need to come with me on this journey a little longer...
What is ESB?
Well..the good old Wikipedia suggests...
Although the exact definition of an ESB varies, most agree that the following are characteristics of an ESB:
- it requires the clear separation of message headers and message body
- it is usually operating system and language independent; it should work between Java and .Net applications, for example
- it (often) uses XML and Web services to transport messages
- it includes adapter standards (such as J2C) for incorporating existing applications into the bus
- it includes support for asynchronous processing
- it includes intelligent, content-based routing
- it includes a standardized security model to authorize, authenticate, and audit use of the ESB
- it includes transformation services (such as XSLT) between the format of the sending application and the receiving application, including the transformation of data formats
- it includes validation against schemas for sending and receiving messages
- it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
- it can conditionally route or transform messages based on a central policy
- it is monitored for message latency and other characteristics described in a Service Level Agreement
- it (often) facilitates "service classes," responding appropriately to higher and lower priority users
- it supports queuing, holding messages if applications are temporarily unavailable
- it handles a "publish and subscribe" messaging model, including event handling
I quite like this as it steers away from all the 'vested intrest' white papers we've all waded through that describe 'what ESB is' - and this is the rub, and very simply the penny dropping. ESB is marketing dresseed up as technology, its given the 'evangalistical' vestments by people who should know better. But of course they do know better and they know how to market. The evidence is simple. We have lived thro' it before, remember the DNS and DNA from Microsoft? What has hasppened is that as integration grew up and in some ways became SOA, IBM grabbed the lead and the technical high ground. Big Blue Marketing stole the march and the rest where left behind. So something new was needed to negate the SOA strangle hold, also on the wave of SOA a number of startups had joined the party. What was need was to relegate SOA to simply a marketing description and then spin up the technical solution for SOA shifting the focus away from Big Blue et al. So ESB was born! ( there is also a small band of people that believe that it was also born out of a percieved 'dying' of Java in the wake of .NET). ESB, of course, can mean everything to everyone, its a solution for real customers, blsh , blah, blah - and on goes the marketing - note marting blurb. So all the EAI product teams could dust off the product and revise that glossy markting document and show how we deliver ESB's!!!
Now, at this point, we must not forget the start-ups - hey SonicEQ became SonicESB! ESB got added to loads of names! And what they needed was a unique twist to separate them from the long standing EAI boys... This has lead to everyone coming up the 'Definative ESB definition' each version stressing the bits that are 'unique' to their product. And thats the rub, what could have been about delivering soutions to customers and providing a sensible means of describing the complexitites of these has left us with Marketing on steriods again....And the constant specticle of 'Willy waving' mine is bigger and better than yours!
So with that in mind I re-read David's blog. And the outcome is this :
David: 30 mins of leading an auidence to an 'informed' view that Sonic is the only real way of delivering ESB
Microsoft Guys: in true pantomine fashine (None UK folk lookup Pantomine on Wikipedia) of 'Oh no its not' , 'We can do it and do it better'
David: 'Oh no you can't because I defined ESB in such a way as to ensure your product can't'
Microsoft ' Oh yes we can coz we've writen the real ESB definition, and guess what it matches what we can do'
David: 'Well I'm right coz I'm on the stage'
And on it goes.....
Before my pre-xmas rant concludes What really has amused me is IBM - IBM just simple go for Webshpere ESB - isn;t life simple....
Over the post Xmas period I'm going to try and produce a more sensible vision of ESB.
Happy Holidays to all readers...