Thursday, 15 November 2007

What's in an ESB?

A number of times now I have had meeting where I have been asked to describe how Gigaspaces integrates with ESBs. Some have even gone farther and sketched how they envision their ideal architecture. They put the database, business logic pieces, an ESB and the Space in between. We were then asked to explain how GigaSpaces would help in achieving their goal – Implementing an SOA based application.

After asking some leading questions about the application and its use-cases, it became clear (at least to me) that what they were really after was an SOA approach and not necessarily an ESB. People tend to confuse the two and refer to ESB as the underlying basis for an SOA based design.

So… When should one really use an ESB and how is different from an SOA approach? There are a few interesting articles and posts around that topic. Check these out. Just what is an ESB, anyway?, What is the business case for ESB?, and the wikipedia take on ESB and SOA.

My take is that an ESB is a blueprint rather than a product. There is a number of implementations which, in essence, implement the concepts of ESB. An ESB can comply with your SOA, should you choose to use one. But, moving forward, you should know that there are other, sometime more appropriate, alternatives to implementing SOA.

One of them is to use GigaSpaces. GigaSpaces provides all the facilities needed to implement an SOA. GigaSpaces provides a distributed, highly-available, stateful execution environment combined with location transparent synchronous and asynchronous invocation mechanism, and an in-memory data-access. Check out the FAQ entry, and the example.

In case you conclude that you do require an ESB because you have backend systems that an ESB provides adaptors to, check out the open-source Mule project, which provides a variety of adaptors and recently announced a SalesForce.com adaptor, and how GigaSpaces integrates with Mule to provide the scalability and state-management capabilities.

2 comments:

nirpaz said...

Very Good post, I like the clarity of the explanation.

Mickey said...

Well, an ESB like SOA is an abstract concept.
ESB does not implement a service-oriented architecture but provides the features with which one may be implemented.
It tries to decouple the services from the actual transport layer, like in EAI. Using Web Services as I see it, breaks the idea of an ESB, as it couples all services by forcing this API as the interoperability layer.
a proper ESB should support a variety of protocols to enable the transition and decoupling of different systems/services and languages.

In Enterprise organizations that are having hundreds of interfaces and systems the ESB is a valuable entity (together with the implementation of SOA). implementing an ESB will give them the visibility and reuse they are seeking together with the means to force security and permission policy.

In the efficient low latency world an ESB might impact performance, and is quite a "white elephant" as the benefit from reuse, decoupling and visibility are usually a second priority to performance, and is archived by OO design together with visual monitoring tools.