Re: Reshaping the JavaSpaces architecture. Just some thoughts ...

Oliver Plohmann wrote:
> I see that I wasn't specific enough in my last post to this mailing 
> list. I'll try to be more precise while still doing some brain storming. 
> One idea I'm juggling in my mind is to tear JavaSpaces apart and have an 
> open system consisting of various sub-systems based on open-source 
> technology. The approach of having a coherent system for space-based 
> computing is a good idea as such. But I'm afraid that this approach 
> nowadays hinders JavaSpaces from spreading any further. People simply 
> won't chose a single system that does it all any more that in addition 
> is tied to some specific distributed computing paradigm. They want 
> loosely coupled systems they can combine.

The primary issue, from my perspective is that people still not understand the 
who Java proposition.  They are being taught programming, not distributed 
computing, nor about system expandability and extensibility.

> A wild idea of mine would be to pick some distributed cache system 
> (JBoss Cache, EHCache, SwarmCache or whatever) and place a 
> JavaSpaces-like layer on top that provides write/take/read/notify 
> functionality. Let's add a service provider interface for the 
> distributed cache system so that the cache system could be replaced with 
> any other one. If possible use JNDI instead of Jini. My knowledge of 
> Jini is too limited to tell whether that is possible at all. I simply 
> fear that in an enterprise setting Jini would not be accepted as being 
> dead technology. Whether this is true or not won't matter I'm afraid. In 
> the J2EE world, for example, people are very sensitive about only using 
> the latest technology (even when it is easy to see that it's 
> brain-damaged having to implement 4 interfaces to make an object 
> persistent as in EJB2). My general idea is to change JavaSpaces so that 
> it has a chance in the enterprise computing world. Whether to go with 
> RMI or JMS is another issue. Haven't thought much about this so far and 
> therefore I will refrain for the time being from expressing an opinion 
> here.

The primary proposition of Jini is "mobile code".  The secondary feature of Jini 
is "mobile code".  The tertiary consideration of Jini is "mobile code".

The java platform provides this and the foundation of a security model, extended 
by the JERI stack in Jini 2.0, that allows mobile code to be "safe".

The benefits of mobile code are visible in Javascript/DHTML/CSS environment for 
one example.

Everything in Jini is open source under apache2.0 license.

To get the power of Jini (did I mention "mobile code"?), you have to have all 
the features that the language and JVM platform provide.  You can try and 
recreate this, but then you are going to have to settle on some language that 
has the features of Java/the-JVM and recreate a lot of security infrastructure etc.

So why waste all that time when you can just use Jini?

Gregg Wonderly

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html