The GigaSpaces Blog » Blog Archives » One Space

One Space - Many Faces

Posted 21 February 2007 @ 12:15 pm by Nati Shalom

We are at a critical time in computing history. Major changes are taking place in the way applications are being architected and JavaSpaces has an opportunity to take a leading role in providing the basis for many of these solutions. Sadly, we spend much of our energy in the space community arguing amongst ourselves and quibbling over semantic and community-control issues rather than focusing on the job of providing the best solution to those who desperately need them.

The space model is not new and has been available for several years already, yet despite its maturity and unlike many other specifications or standards spaces represent a challenging and new way of thinking about distributed computing - not just a new API. This is why discussions about spaces often end in long threads arguing different opinions about distributed computing. These range from comparisons of existing middleware/infrastructure such as messaging and databases to discussions about open-source and standards vs vendor implementations.

As a technology that has been out there for years, you would expect that there would be clear agreement on what JavaSpaces is and what it's good for. If you follow the latest discussions [1 , 2 , 3 , 4 ] about JavaSpaces you immediately realize that this is not the case. Everyone seems to have different opinions about what Spaces are and what they should be and everyone also is very passionate about their opinion!

I will try to summarize very shortly what I have found to be the leading opinions and give my thoughts on this matter. I'll categorize the thought leaders into two groups: the "purists" (those that claim to look at things from a "pure" technology view) vs. the "pragmatists" (those that mostly look at technology as a means to solve business problems). The purists tend to divide the world into concrete and separate technology worlds. They don't like to see overlap and if there is overlap they must be able to clearly identify it. They therefore tend to say that JavaSpaces is not a database, not a cache, not a messaging solution. They say it is something else - a "coordination framework", if you like. The pragmatist, on the other hand, will say that JavaSpaces is actually a combination of both a messaging solution and a data store, and can be used as a great resource for implementing caching or distributed shared memory (In-Memory-Data-Grid).

The purist will tend to look at issues such as simplicity, interoperability with other programming models and frameworks as less important as they don't hold "real" technology value. The pragmatist will look at these same issues in a completely different way. Simplicity and interoperability are key to the effective adoption of the technology. Why is this important?

To a certain extent it is not important. We live in a free world and everyone has the right to have their own view. However, there must be greater agreement among us purists and pragmatists if we are going to properly define the future direction of JavaSpaces. Without more consensus on what JavaSpaces is good at and where it should be going, it will be hard to move forward with the technology. Examples of features that remain debated rather than standardized as a result of the lack of agreement are FIFO, Query and POJO support.

My personal view is that for years the Jini and JavaSpaces community has been dominated by the purists. They are a unique group of very talented and bright people that were able to bring innovative thinking into the traditional software world. Having said that, I think that it is absolutely critical to bring the pragmatist view into this community if we want to increase the adoption of the technology.

For starters, we should re-examine how the technology should fit within new popular programming models such as POJO, Annotations, and Declarative behavioral models to address one of its main obstacles for widespread adoption - complexity.

The recent movement of Jini into the Apache River project created an opportunity to have second thoughts on the current approach and to bring new ideas and people into the active community. I believe the future success of this community will be largely based on how open it will be to those with a different way of thinking.

One of the immediate things that will need to change in this community is the anti-vendor attitude as presented in this recent TSS thread . While I understand the roots of the resistance to allowing vendors to guide the standard (given the past J2EE experience), in my opinion it represents the easiest and wrong route. One of the good things about vendors (take the objective position here:-) is that they have to solve real problems in order to make a living. Therefore, they have to be pragmatic in their approach by necessity. A healthy community should be one that combines purist and pragmatist - leveraging both viewpoints to create the best available solution (even if the pragmatist happens to be a vendor). In my next posts I will try to present some of my thoughts on this topic and suggest a new model for the next-generation declarative space model (proudly pragmatic in nature). I would be interested to hear what others think about my views and whether they have further ideas or suggestions on where JavaSpaces should be heading.