Happy new year, everyone.

One of my goals for 2013 is to push JSR 347 into action again.  To kick start this, I propose a meeting among expert group members - anyone else with an interest in the JSR is welcome to attend as well.

Details are in my post to the mailing list.  Please respond to the mail list if you are interested in participating.

Cheers Manik

PCWorld has published an article on the recent data grid JSR that I have submitted.  As a follow-up to PCWorld’s article, I would like to make a few comments to clarify a few things.

I don’t quite understand what is meant by Red Hat’s approach not being the best solution.  Do people take issue with having a standard in the first place?  Or is it the standards body used in this particular case (the JCP)?  If it is the details of the standard itself, one should keep in mind that this has yet to be defined by an expert group!

It is unfortunate that the "others" mentioned in the article - who feel that Red Hat’s approach is not the best - were not able to provide any details about their objections. I would love to hear these objections and make sure that the JSR addresses them.

The importance of a standard, to remove vendor lock-in, etc., is pretty well understood, so I won’t go into too much detail here.  But with that in mind, I find Pandey’s comment regarding a "self-beneficial move" an odd one.  A standard makes it easier for people to switch between products (which may explain why no one else may have stepped up to the plate to propose such a standard thus far).  Proposing a standard makes it easier for end-users to move away from Infinispan.  Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch.  The only real beneficiary here is the end-user.  In fact, I’d like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users.

With regards to JSR-107, I believe Pandey has misunderstood the intention in proposing a data grid JSR.  I have proposed extending and building on top of JSR-107 - not throwing it away - and I have expressed this the JSR-107 expert group mailing list, of which Terracotta’s Greg Luck is a member.  In fact, without Pandey’s actually seeing my data grid proposal blog post - PCWorld’s article was written before I published details of the JSR submission, based on a high-level Red Hat press release - one has to wonder where such strong words come from!  :-)

Cheers Manik

Following up on my previous response to Antonio Goncalves' blog post, I have submitted a JSR to the JCP on a data grid standard, titled "Java Data Grids".  It has yet to be assigned a number by the JCP, but I thought I’d talk about it a little here anyway.

Here is the description of the JSR that I have submitted:

Data grids are gaining prominence and importance in enterprise Java, particularly as cloud-style deployments gain popularity:

With one of Java EE 7’s stated goals being "cloud-friendliness", the above are powerful arguments for the inclusion of a distributed data grid standard in Java EE 7.

What about JSR-107?  JSR-107 - the temporary caching API proposed in 2001 - certainly has a role to play in Java EE too.  Temporary caches are an important part of enterprise middleware, but yet a standard has been sadly missing from a Java EE umbrella specification for far too long.  Spring, having identified the need as well, has a temporary caching abstraction in their current development versions.  Several other non-Java frameworks define temporary caching APIs too (Ruby on Rails, Django for Python, .NET).  There is no denying JSR-107 is necessary, and necessary as a part of Java EE.

But JSR-107 isn’t a data grid.  JSR-107 falls short as a standard for data grids, specifically as it doesn’t take into account characteristics of distribution and replication of data, and doesn’t define a contract that implementations would have to adhere to when it comes to moving data around a cluster.  Crucial things for a data grid that, if not baked into a specification, will hinder portability and render the standard itself useless and impotent.

Further, with remote capabilities in mind, a data grid should also expose a non-blocking API, since network calls can be a limiting factor.  Invoking methods that involve remote calls should be able to be done in an asynchronous fashion.  Stuff that is irrelevant to a temporary caching API like JSR-107.

So with all that in mind, I’d love to hear your thoughts on the data grid JSR.  In addition to Red Hat, the JSR is currently backed by a major Java EE and data grid vendor which cannot be named at this stage, along with independent JCP members with relevant interest and background.

Cheers Manik