A while ago I’ve posted a little article after watching a ThoughtWorker giving a presentation on InfoQ stating that no one needs an ESB, and that if you do need one, use squid.
Althought it is a very extreme point of view, it is definetly a valid one. Web Services, SOAP and WS-* specifications were all built with federation in mind. What does that mean exactly? In one easy sentence, “mind your own business”. Federation fosters and encourages integrations that are in fact point-to-point, but in a standardized and controllable manner.
The promise of ESBs is adding in easy management to those apparently “wild” services, and making changes of service location and versions transparent to the end users. Allowing for multiple protocols, and solving impedance mismatches between application data formats is another one of their advertised uses.
Some time has passed since that infamous blog post, and I’ve had contact with some more real world SOA, and specially ESB deployment. It turns out most ESBs are actually service containers in disguise, with some routing and transformation capabilities.
Some pepople are using ESBs or tools like Weblogic Integration to accomplish service orchestration and composition. Orchestration engines, most notably BPEL-based ones such as Apache ODE or Progress Sonic BPEL Server are a lot more capable and appropriate for those tasks, making joining message parts for instance, effortless. Trying to achieve that in an ESB such as Progress Sonic ESB, Mule or Apache Synapse is not only not recommended, but a huge effort.
Nevertheless, most people seem to think of ESBs as service containers. They build new services around text files, old apps, databases, and host them in the ESB. How far is this from, say, a JCA container? Too close to consider it a “service hub”, I’d say. Most ESB deployments don’t treat the ESB as a router, but as a container for services. Even the recent SCA and JBI specs, and the so-called JBI ESBs (OpenESB, Apache ServiceMix) are nothing but service containers with routing capabilities as a second thought.
Isn’t it about time we agree to live with the idea of the service container instead, and decide that we don’t need a router or “central point of contact” in SOA deployments?
Mulesource’s Ross Mason has written a very nice blog post regarding wether you should use and ESB or not. Although he won’t go as far as I did in this post questioning the real need for the tools, his questions can set you on the right track.
I’d love to hear thoughts on the subject and discuss it, here or somewhere else. Just shoot me a comment or email.