river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Split JavaSpaces and JINI
Date Fri, 12 Dec 2008 18:19:34 GMT
Michael McGrady wrote:
> I have given you my answer but I will do so again.
> 
> I think JINI is conceptually dependent on JavaSpaces.  No JavaSpaces, no 
> JINI, conceptually.

Jini is a system for building distributed system.  JavaSpaces uses the 
facilities of the Jini system to provide a distributed memory subsystem.  Is 
that something that you don't see?

> JavaSpace is not dependent on JINI.  No JINI, no worries, conceptually.  
> That is only a problem now because interfaces that should be in 
> JavaSpaces are in JINI.

A Linda space implementation doesn't have to use Jini because it's not a 
technology, it's a mechanism/architecture that can have infinite 
implementations.  Search for "Java Linda Space" on google.  Lots of people have 
created implementations of a Linda like space "thing" in Java.

JavaSpaces uses features of Jini to participate with other Jini enabled services 
so that they can utilities a Linda tuple-space for distributed memory.  If the 
Entry interface was in JavaSpaces and not in Jini, than it would have an 
identical copy in Jini so that service registration and lookup could use it, 
since it's in that API too.

You might think, that's okay, no problem.  But, it is a problem for developers 
because they'd always wonder which one was being used when they saw the text 
Entry.  So, you might say, they can have different names like SpaceEntry and 
ServiceEntry etc.  Well, perhaps so, but that's water under the bridge.  At this 
point, there are existing Jini services all deployed with the existing type 
hierarchy and class structure.  If you change that in an incompatible way, then 
you've broken Jini as a concept related to portability and inter-working 
services and clients.

> I think that JavaSpaces must include certain features, e.g., entries, 
> operations on entries, etc.  This is the core technology to my way of 
> thinking.  There is no cookie cutter exact answer to exactly where to 
> draw the line.  JavaSpaces should be completely independent of JINI.  
> JINI should be intelligence on top of JavaSpaces with a different and 
> additional purpose.

Which do you want out of JavaSpaces?  The function of Entry related to read(), 
put() and take() on the space, with the matching mechanisms etc, or do you want 
that and the ability to access the JavaSpace from another machine (or two, or more)?

If you want a network, you need network technologies to do that.  If you want 
reliability in the flow of your data between systems, you need Transactions.  If 
  you want reliability in the recovery of your system from partial failure, you 
need leasing.

Again, which parts of Jini do you think JavaSpaces has no need for?  And I do 
mean NO NEED FOR.

Gregg Wonderly

Mime
View raw message