After four years fiddling with ESBs, I thought it could be interesting to share what I have found to be pragmatic use cases for that tool. But, first, what do I mean by pragmatic?
By pragmatic, I mean free of any vendor kool-aid or SOA hype ; and driven by concrete needs instead of general fantasies of "business processology and ontological governance" (you get the picture). I also mean cases where an ESB did not feel overkill for the job and where its inherent drawbacks were acceptable compared to the features it brought.
So here are some use cases grouped by themes, with highlights of what particular virtues an ESB brings in them.
The external world outreach use case
Isolating corporate software from the pesky details of calling third party services over the internet is a very good use case for an ESB. Indeed, these services tend to have bizarre authentication schemes, IP range or access count limits and random down times. It is then worthwhile to hide these remote services behind an abstraction layer that allows developers to invoke them without having to learn about their particularities.
Consuming feeds is also another task for which it is more desirable to write configuration instead of code, something an ESB offers natively.
Reaching servers inside a DMZ with non-HTTP protocols is also another good usage for an ESB, with nodes installed in each firewalled subnet. I have talked about this before.
ESB virtues: Distributed, Content base routing, Configuration over code.
The instant legacy integration use case
Though I have been lucky enough to be spared the traditional legacy integration consulting gigs, I had to perform some stunts in the realm of instant legacy integration. This kind of software does not consider that standards carry any value, hence often opt for weird invocation protocols or communication mechanisms.
The message transformation and protocol adaptation features an ESB offer come very handy in this kind of scenario: a remote synchronous mambo-jumbo talking service can then be exposed as a SOAP or MQ one to the interested applications.
The versatility of an ESB, which allows it to come into play with various systems without having to modify them or needing them to know anything about the bus, compensates the black box middleware it can appear to be. It is in fact often desirable to keep the ugly details of talking the crazy talk of some systems in a black box to preserve the sanity of the software developers who need to use them.
ESB virtues: Message transformations, Protocol adaptation, Non invasiveness.
The fast talker use case
An interested case I was once faced with involved dealing with high performance communications alongside with a more standard database oriented web application. Even the hip J2EE application server I was using at that time was not designed to handle this kind of traffic: EJB, SOAP or CORBA were fine but not bursts of data packets over POTCPIP (Plain Old TCP/IP).
This was another good use case for an ESB, as it offered not only an excellent support for even such a low level protocol, but also the capacity to configure and manage pools of threads and components used to process the particular load of this side of the application. Acting as a "heat shield", the ESB was then analyzing, aggregating and pre-chewed data packets in messages ready to be sent to the rest of the J2EE application over standard EJB and JMS channels.
ESB virtues: Configurable behavior (threading/polling), Protocol support, Message aggregation.
Now to the real expert
So where is the "ESB in the middle of all remote service calls" use case? Well, though very satisfying for the mind, this kind of deployment very often ends up as a not so great idea. Jim Webber, who is a real expert, can explain you why.
