Radovan recently posted a compelling argument regarding the shortcomings of ESBs. The main reason I like it and largely agree with him is because of what he says about the power and utility of moving integration capabilities to the endpoints.
So many integration projects have taken a centralized approach that it's led many to believe that centralized integration is the only viable integration solution. After all, with a centralized/bus approach, the integration problem is obviously greatly reduced, since each endpoint need only integrate with the bus rather than integrating with each of the other endpoints. In other words, the bus affords an O(N) solution rather than an O(N^2) solution.
Hypothetically, the reduction in connections offered by the bus approach is certainly true, but in practice, the centralized/bus cure is often worse than the disease, for several reasons:
- Centralized approaches force the existence of canonical protocols, transports, and data formats, which adversely affect efficiency. Everything being integrated must be able to convert its own protocols, transports, and data formats to and from those of the bus. This means that to integrate System A with System B, in the best case you require two conversions: A to canonical, and canonical to B. Worst case is when A and B have protocols, transports, or data formats in common, thus requiring no conversions, and yet the canonical/centralized approach forces the conversions to occur regardless.
- Since everything has to connect through the bus, the overalll system capabilities are limited by the capabilities of the bus and its canonical formats, protocols, and transports.
- Buses are typically proprietary, though with the advent of web services, this is improving.
If you instead move integration capabilities directly to the endpoints themselves, they can speak directly to each other. If they have protocols or formats in common, there's no need for any conversions -- they can just talk directly. If their data formats are different but not by much, then just a little bit of data mapping is required, rather than requiring potentially heavy-handed conversions into and out of a canonical format in the middle. They're free to use whatever protocols and data formats they choose, rather than being limited by the capabilities of the bus. Likewise, the speed and efficiency of their connection is not limited to that of the bus.
"Ah," you say, "but connecting endpoints directly to each other brings us back to the N^2 connection problem." Hypothetically, yes. In practice, no. In practice, nobody ever needs to connect everything to everything else. The N^2 problem just doesn't arise. Installing a bus to solve the hypothetical problem and trading away all possibilities for speed, efficiency, and flexibility in the process is often an extremely poor choice.