Thursday, May 01, 2008

A decision makers concern about ESB

Today everyone assumes that all IT organizations will procure an ESB whenever they decide to adopt SOA. This is true today, especially as the technologies and standards are not mature as yet. Following are a couple of comments/concerns that the decision makers had about ESB (yes! they did buy the product but their concerns are real).

On an average I already have 7 hops for providing my customer the relevant information whenever they login to my web site. Based on your reference architecture recommendation I would increase the number of hops. What does that do to the performance? Isn't that adding one more layer to the current architecture? - Chief Architect of a large Financial Company

Our strategy is to grow by acquisitions and with each acquisition we increase the number the data centers, each having thousands of Servers. In my opinion we are one acquisition away from disaster and you expect me to tie it together by leveraging and ESB? Why shouldn't I stay with my existing messaging infrastructure? - CTO of a large transportation company.


At the same time, to be competitive vendors are starting to include additional functionality into the ESB that do not belong there. In short, making it heavier requiring additional resources to implement the solution. Vendors have now also started pushing embedding ESB into each of the products (not a smart move).

In my opinion the ESB shall be irrelevant by 2010 for the following reasons:
  • There is a push by end-users and vendors to develop standards (SCA) to decouple the business logic from the bindings. I expect this to result into a meta-data driven (SCA) container both for exposing services as well as referencing (invoking) services.
  • Even though the some vendors do not yet decouple the logical name (such as "Credit Card Approval for Mortgage") from the physical name, the market will drive them there.
  • As services are deployed into production, the SCA container shall leverage P2P technologies such as JXTA, Jini, UPnP and/or WS-Discovery to dynamically discover the dependent services. Newton is a prime example of such a container
I expect that by 2010 the SCA container shall eventually be the next generation container and unlike the JEE container will be independent of the technology implementation. This shall address the concerns of the decision makers about the ESB. No more need of additional hops (yes! the transformations shall be performed by the SCA Container).

Of-course like all previous waves and ESB will not go away but be used to interface with existing legacy systems. As for J2EE/JEE - they would still be the technology of choice for some of the SCA containers.

- Yogish

1 comment:

Android app developers said...

Nice to present this kind of information.This is one of the challenging post.We can learn some useful tips from this post.

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...