My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Wednesday, February 27, 2008
« SAML, WS-Federation and More | Main | Attending IDtrust 2008 »

The BusMany people believe that an Enterprise Service Bus (ESB) is a must have component of a SOA infrastructure.  The  usual argument put forth is that if you want security, manageability and reliability in your environment, you must have something that looks like a "bus" in your environment.

I have a slightly different perspective on this.  From my experience, there are other components that do an outstanding job when it comes to security functionality. In addition, an ESB really can't manage services that are not "plugged-in" to it (you need something like a WSM product). And finally, with the approval of and support for WS-ReliableMessaging as an OASIS standard, you no longer need some proprietary messaging technology to provide reliable messaging. You can leverage the support for the standard built into the basic service platform itself. So my experience has been that you do not need a "bus" in the middle through which all traffic should flow and all things in your enterprise should be connected to.

Service Platform But at the same time, where I have seen the value of an ESB is from the perspective of its ability to easily tap into a variety of back-end systems and expose them using a contracted web service interface. So in my world, the ESB provides me ease of use when it comes to tapping into custom or Enterprise class systems (ERP, RDBMS, Mainframe) and "service-enabling" them. So an ESB is simply a type of Service Platform which can be used to build services and not a bus to which everything is connected.  The service created in this manner can be treated like any other service that you build or buy, and can be secured and managed just like you would any other service. 

In this model, I really did not see much value in having an ESB, given that we have a pretty comprehensive existing and heterogeneous SOA infrastructure that is designed to work together in a standards compliant manner and provides pretty much all of the functionality that an ESB is touted to fulfill. The only exception would be if there existed some back-end system that I could not natively tap into from a standard service platform and needed the facilities of an ESB to ease the connection into that proprietary or legacy system.

But I had the opportunity yesterday to listen to Anne Thomas Manes of the Burton Group at the "Pragmatic SOA  Governance" workshop that was put together by Michael Meehan and his crew from TechTarget.com. Great event, BTW!

Platform plus Protocols What Anne's comments opened my eyes to was to take what I had above to the next step. From her perspective, an ESB is the new generation of Application Servers, and what it brings to the table is the ability for an organization to be resilient to application protocol changes.  So an ESB provides the ability to leverage the same core business logic that is used to build a capability, and expose it over multiple service protocols/interfaces. And if a new protocol needs to be supported, it is simply a matter of the ESB supporting it. Keep in mind the end product is still a contracted service interface. But in this case, that interface is not limited to SOAP but can be many others that may be much more peformant or optimized for that particular domain.

Conceptually, I can buy into this. Will have to see how well it does in real life.

del.icio.us tags: ,

Technorati tags: ,
2/27/2008 10:48 PM Eastern Standard Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.