Madness? THIS. IS. SOA!

There is an interesting war being fought in the blogosphere over the use (or overuse) of ESB (enterprise service buses) to build out a SOA (service oriented architecture). It certainly appears that Dave Linthicum is taking on the role of Leonidas and the Spartans at the battle of Thermopylae while everyone else is on the side of Xerxes and the Persians.

Dave is defending his view that ESBs are overused and often, apparently, misused against a host of ESB and SOA focused bloggers like Joe McKendrick and Jeff Schneider.

But everyone is talking in abstractions, and no one's really giving anyone a good idea of when to use an ESB or when to avoid them. No one seems to be looking at why people are or aren't using ESBs and getting to the root of the question - when are they appropriate for use in a SOA and when are they simply being implemented for the sake of being implemented?

So when should you consider implementing an ESB as part of your SOA?

1. You have a need to orchestrate services. Orchestration of services is one of the greatest strengths of an ESB. ESBs layer transaction management around orchestration of services and provide value when two or more services need to be composed into a single "transaction".

2. You have a need to integrate middleware messaging with applications. Let's face it, service-enabling MQ or JMS is a pain in the ... neck. An ESB makes this process simple and allows for orchestration of asynchronous services that might otherwise be difficult to integrate into an architecture.

3. Multi-application updates (a la integration). I know this is an unpopular thing to say, but sometimes the best solution to the problem of enterprise application integration in a SOA world is to use an ESB. ESBs are more than capable of orchestrating updates in a parallel processing scenario, and if you have multiple legacy applications or services that need updating during the same process, then an ESB is going to provide significant value in implementing such processes.

4. You plan on doing any of the above in the future. Laying the foundation for orchestration, integration, and parallel processing of messages means laying the foundation now, not rip-and-replace later. If there are plans in your SOA's future that would include an ESB, then implement sooner rather than later.

SOA is supposed to help align IT with the business. If you need an ESB, or three or ten, to accomplish that goal, then that's what you need to do. While it may not be a "pure" SOA in implementation, if you're staying true to its goal then it's definitely a "pure" SOA in design and intent.