river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <mmcgr...@topiatechnology.com>
Subject Re: Split JavaSpaces and JINI
Date Sat, 13 Dec 2008 19:35:56 GMT
See infra:


On Dec 12, 2008, at 1:19 PM, Gregg Wonderly wrote:
>>
>
> 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?

Yes this is something I do not see.  JavaSpaces as a Linda spaces  
implementation is not dependent on JINI in this way.

>
> 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.

A Linda space implementation is a technology.  Implementations don't  
have implementations infinite or finite.

I would like to have a Linda spaces implementation, which JavaSpaces  
claims to be, by the way, without having to choose yea or nay on  
JINI.  You are forcing that choice in JINI.  That forced choice could  
be excised and those other implementations of Linda spaces in Java  
could become secondary to JavaSpaces.  Further, this would not hurt  
JINI at all.  Win/win, as i said before.  Why would you fight against  
this?

>
>
> 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.

First, if the entry interface was in JavaSpaces, it would not need a  
copy in JINI.  JINI might need a different implementation that was  
more specialized than the JavaSpaces implementation, as Niclas has  
noted, but that is good, not bad.

>
>
> 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.


If there were only one hierarchy, Gregg, it would not be disturbed by  
restructuring and moving the entry interface to JavaSpaces.  It would  
have no effect at all.

>
> 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.

I don't want to get rid of anything.  I just want the structure of the  
framework, of JINI and JavaSpaces to make sense.  Presently, in my  
opinion, the structure does not make sense, which accounts for all the  
activity around JINI but excluding JINI.  People are building things  
they need but JINI precludes, even though with proper structuring it  
would not have to preclude these uses.  The time to change is now  
because spaces is being discovered and is passing River by at this  
time.  I am going to use spaces and I am going to use it in large,  
interesting, applications.  If River is not changing, then it won't be  
River.

Mike

Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
mmcgrady@topiatechnology.com





Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message