ESB revisited
Dave Chappell of Sonic Software and ESB book fame, contacted me last week regarding my thoughts on ESB. He posted a response on his O'Reilly site. Here's my take on his response:
Hey Dave: Great to see your considered response to my last post on the subject of ESB.
You make many good points and clarify a number of the (somewhat rhetorical) questions I raised. You point out that ESB's should provide all the capabilities offered by EAI technologies, and many they lack. You point out that ESB's should provide the core communications backbone for entire enterprises, regardless of their topologies, heritage, platform, protocol and information representations, etc. You clearly articulate that ESB's have adapters and translators enabling messages from different systems to be translated and transformed in order to ease integration of heterogeneous systems.
However, I get this. I see exactly where various players are going when they advocate the many "benefits" of ESB.
The point I was trying to raise is that I am fundamentally at odds with the notion of buying and/or building a communications "bus" for an enterprise. I am totally opposed to the idea of building enterprise apps on top of this "bus" which I hope will solve all my integration needs. Why? There are several reasons for my concerns, but it all essentially comes down to one thing: WS-*
Our industry is (finally) growing up! We're at last coming to understand that no one vendor/technology/platform will ever be the only vendor.technology/platform in a given environment. Who would have thought just 5 years ago, that Microsoft, IBM, BEA, Sun, Oracle, Verisign, AOL, CA, EDS, etc. would be cooperating on working to define open wire-protocols that permit secure, reliable, transacted communications to take place across their systems? If we'd even countenanced it back then we'd have been committing gross acts of techno-blasphemy!
But it is happening - now! Within the next 18-24 months, many major (and smaller) vendors will be supporting WS-* natively within their product sets. Microsoft already ships some of these capabilities (through WSE) and some of our partners and competitors are now adding WS-* support to their products. By the time we ship "Indigo" next year, we'll implement the vast majority of the WS-* protocols necessary to build applications that communicate securely, reliably and in a transacted manner if necessary, across platforms, machines and organizations. It'll only be a matter of time until broad support for these vital technologies arrives.
While there are many competing and incompatible protocols out there today, over time, we should expect that most technology vendors should start supporting WS-* within their product stacks. Systems, Services, Applications and Components should be able to communicate freely amongst each other by default, regardless of which tools were used to write the code, which OS and runtime hosts the code, which processor executes the code and which device is used.
Yes, there will be a need to integrate existing/heritage systems with this brave new world, but this integration should be performed only where necessary, not as a matter of course. Once these systems have been upgraded/replaced and attain the ability to talk WS-* too, then the integration engine should be removed, permitting free and open communications between systems. Essentially, the need for integration technologies such as those proposed by the ESB movement should be increasingly pushed to the outer-edges of the enterprise world, replaced instead by mature platforms that provide most (if not all) of the capabilities of an ESB at each node in the system.
To my mind, there is also an darker side to ESB: What if I wanted to remove or replace my current ESB platform? Surely, this is more insidious than any operating system, development tool or other such vendor lock-in concern? Because each ESB is implemented in an entirely proprietary manner, with no guarantees that the messages transmitted across the bus are actually based on any form of open standard protocol, there is absolutely no guarantee that any technology offered by a company other than the ESB platform vendor will be able to communicate freely via the bus. So, not only am I held to ransom by the ESB platform vendor because I cannot easily replace one ESB with another, but I am also likely to only be able to integrate systems which the ESB vendor provides specific adaptors for.
Isn't this precisely what we're trying to get away from?
Essentially, integration via translation and transformation should be an edge-case scenario with integration happening on the wire by default. ESB does not embrace this and this is why I think that ESB is the wrong strategic approach to take when approaching the integration problem.
I love your closing line: "Comments are welcome here from others as well. Please keep the Java vs. MS bashing stuff to a minimum. This is really about architecture." - I couldn't agree more :)
