Why Did Commons Cache Die?

There have been a number of attempts to create a uniform caching API in the last couple of years. None has succeeded.

A fairly known one is JCache which is based on JSR 107 for Java users. JSR 107 has been “in progress” for a few years now…

Another initiative which failed was to “common” the Java cache API. The Commons Cache project has been declared end-of-life after not being able to ramp up.

Failing to create a standard cache API would not have been odd to me and I wouldn’t have spent my free CPU cycles around it, unless thinking of the cache selection process in banks, for instance. It strikes me that maybe there is a need for such an API. Banks, looking to select a data-grid solution, usually go through a very similar process. More than that, they design, implement, and run their “very specific” test harness. At the end of the day, they all look alike and have the exact same methods and semantics.

Would a uniform cache API help these banks execute their exercise and ease their selection process?

Moreover, is such an API needed in our industry?

I have my views and thoughts, but I'm very interested to hear yours before posting those. Feel free to leave a comment or email me to guy dot sayar at gmail dot com.

-Guy

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.

My Blog

So…

I've been thinking about blogging for a while now, and finally decided to join the bloggers community. I will be blogging about distributed computing, software architecture, general java stuff and other happenings which keep my wheels rolling.

I work for GigaSpaces where I am a part of a field team working with prospects and customers across Europe. There are many exciting experiences working in this field, and I enjoy the opportunity to participate in various interesting projects. I will not be mentioning names etc' but will share my experiences and thoughts here.

Stay tuned.

Guy