Re: The ESB Question

Steve Vinoski’s asks do we need ESB's? Since Steve used to work for Iona, he'll definitely have a point worth listening to. His main argument boils down to:

• ESB's are useful for a limited set of circumstances - dealing with legacy systems that cannot be replaced. Well this is certainly true.
  
• Echo's Patrick Logan's Opinion on ESB's - "just use the base libraries instead and where possible use REST"
• Dynamic languages (Ruby, Python) are better than static ones for integration.
  

I'm going to ignore the last point. It believe it is silly to make such a black and white distinction. If you want to use dynamic languages to integrate two systems together use that. If you don't for whatever reason, then don't. I think the static vs. dynamic language argument is a red herring on the level of VI vs Emacs.

Personally, I prefer dynamic languages, they seem freer (but that is mainly a preference issue for me). Interestingly, most of the first integration problems I encountered in the early 90's I solved using Email + Perl. Later it was Perl + XML + Java + Email/HTTP. Then Perl + XML + Java + XPath + XSLT + Email/HTTP/JMS. Things kept growing like that. It was never a case of static vs. dynamic languages - it was a mix of what do I know, what code / libraries can I find. This is why Patrick's opinion above resonates with me. Now I think there should be a simple easily-to-understand rule that we can use here:

If your problem looks like a simple thing that an ESB can solve (potentially faster than you can code comfortably against the collection of libraries that you may or may not know), then it might be worth downloading and trying it out. If it doesn't solve your problem, or you don't like the look of the solution, then you should not use it.

Now the important points here are whether you are comfortable and whether the ESB actually saves you some time and effort (for surely this is the point of using a framework). There are other points to using a framework (for example consistency, but these are secondary and may not apply to your particular integration problem). So this is the well rehearsed "framework vs library" debate - and when you look at it this way, the main problem with ESB's is that they are all different - which is a problem. Still from a framework point of view we can draw an analogy between MVC and ESB. Do you need an MVC to write a dynamic web-page? Nope. Is it overkill? For one page? Definitely. What about a lot of them? What about pages that load stuff from a database? etc. etc. You can see where this is going.

One interesting thing about frameworks though is that they are generally replaced by other frameworks - they rarely devolve back to code-against many libraries.

This brings me to the second part of Patrick Logan's point: REST. I'll admit it, I'm somewhat confused at REST vs ESB debate. It was REST vs WS* wasn't it? Anyway, seems we don't have enough to argue about. The reason I'm confused about REST vs ESB is that REST is a style of writing and/or consuming Web Services, whereas ESB's are an integration technology for mixing together messages, protocols and web services (WS-* services, REST services and REST's poor relation: XML/HTTP services). So clearly REST on its own is not really what's being described here. So widening it, is this debate "Are REST + APP + Some-other-framework better for integration problems than ESB's?". I think this doesn't make the issue much better. They may be for some problems, but not for all. Why? It is the keyword 'integration'. Many integration problems mix protocols, Web Services WS-* and REST together (no, apparently it isn't illegal). Some even use, you may need to sit down at this point, Microsoft's MSMQ. So clearly a REST+APP+something else isn't going to solve all problems (unless the something else starts to offer features suspiciously similar to those provided by an ESB e.g. protocol adapters/mediators).

The correct way to think of this is back to the REST vs WS-* debate. Which style of web services do you want to write/use? ESB's should be neutral on this question: Have it your way and if you need to mix these and other stuff (e.g. Email) so much the better. Interestingly if you did think that REST+APP on it's own are the only way to integrate systems together, then by definition everything else is legacy. Which brings me neatly to Steve's first point. ESB's are good for legacy. If this is the definition of legacy, then I'm more than okay with that. I work for a company that sells an ESB, so obviously I'm biased
here, but hopefully not too much.