Cisco AON: Another nail in the coffin for ESB

I had such a fun time speaking in this Ark-Group event. Getting involved in the expert panel discussion led by Neal Ford of ThoughtWorks was a blast. We had a very good ratio of academic researchers and real-world industry and field experts in the audience to work out a very well-balanced discussion.

As usual, I come from a real-world industry approach and sometimes, I cannot help but take pot-shots at the academics, all in good fun. i-wink. As Neal calls me, William the pragmatist.

I was noted in the event as one who tends to go against convention (and this is not the first time I am doing this). For example, I am not about to get caught up in the SO(A) buzz and I urged the audience not to as well. The design principles of SO(A) such as loose-coupling, etc is something that has been around for years and the branding of all these principles under a new name just doesnt fool me. Of course, I challenged the audience to define the so-loosely-defined term SO(A) and everyone seems to have so many mixed views. It is one of those things that I termed 100 different answers for 50 different people --- depending on the time of day. Service-Orientation is a different thing altogether as it talks about how you should be using certain principles or tenets to design the interfaces and how to go about using them. Now, that I buy !

This is also one of the few times I spoke out and caution against the use of a ESB or what I prefer to call as a message broker. Especially if the ESB is a productization of a vendor`s proprietary technology. As one of the speakers had noted, it is not easy to maintain one, let alone implement it. Patches and fixes come in fast and furious. Someone in the audience has asked about the use of the ESB outside of the E, which I think the entire panel, including me, agreed that this will not happen in a long time to come (if at all).

As I think I have articulated well enough to the audience, the reason for ESB today (and yes, value can still be derived from it today) is to hook up legacy systems using messages and for them to be using advanced (read: Enterprise) features such as Security, Reliability and Transactions which the broker provides. Of course, it is mostly a pull-thing here because the standards for these specifications are not ratified and matured yet. I am a firm believer that the emphasis is on the message and NOT the endpoints. Once the specifications mature and the Super-platform players introduce them baked into its kernel and core, the dumb nodes around the supposedly smart ESB plumbing suddenly wont seem so dumb after all.

I have a strong inkling that _Indigo_ will lead the way for that.

Having said that, I dont think a mass-uptake will happen anytime soon. There is a huge consolidation in the ESB market today with WS-Management and WS-Registry players coming into the mix. I expect even further consolidation when Cisco introduced its appliance-based Application-Oriented Networking into the market.

Will this be another nail in the coffin for ESB I believe it will be - provided the below quote is true.

There`s good news here -- no one interviewed for this piece believes that the Cisco move will spark a new generation of protocols.

However, one potential issue is whether applications will have to be written specifically to AON and the network in order to take advantage of AON features. Cisco says no, but Randy Heffner, Vice President in Forrester`s Application Development & Infrastructure research group, notes that "from the application side, it`s going to take a while to figure out the implications of this. The key question is, "do I have to rethink my networking messaging processing"

Somehow, I think this will go to some great lengths in addressing the latency constraints of Service-Orientation. I hope so and I like what the market is doing to go all out to embrace the world of XML-Messaging.