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.
