river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Split JavaSpaces and JINI
Date Sat, 13 Dec 2008 20:36:15 GMT
----- Original Message ----

> From: Michael McGrady <mmcgrady@topiatechnology.com>
> To: river-dev@incubator.apache.org
> Sent: Saturday, December 13, 2008 2:35:56 PM
> Subject: Re: Split JavaSpaces and JINI
> 
> 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.
>

Yes it is. It is extremely dependent upon the other concepts in Jini for Linda. The only way
that is not so is if you *just* have interfaces. Which you can do now albeit all needs to
be broken out into smaller pieces a bit better and modularized at the deployment and package
level.
 
> > 
> > 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?
> 

I think folks are fighting against your misunderstanding that JavaSpaces can be Linda without
the rest of Jini. There is a heck of a lot more to Linda than the interfaces you are referring.
To use JavaSpaces as Linda you need a lookup or some other mechanism which abstracts away
all the network or single process stuff. Currently, using JavaSpaces with the other features
of the Jini packages gives you the distributed system; Linda capabilities. Spaces is just
the distributed tuples and anything in between getting you information and writing it. 

Just having Entry, Transaction, Lease etc in spaces isn't going to get you that, and having
those classes in their own subproject makes more sense than what are you talking about doing
because they are more than just related to spaces. You have to have those other things Jini
provides, and without that spaces can not stand alone unless all that work is duplicated or
they are just interfaces leaving everything else for folks to implement. You can use the interfaces
now, but you have to have the common things.

Anyways, yes, JavaSpaces claims to enable Linda, but not without Jini. Check the specs:
http://www.jini.org/wiki/JavaSpaces_Specification

JavaSpaces is dependent upon Jini though you can write your own special things using just
the interfaces and filling in the blanks. Though unless you do all the network and distributed
work, you don't have Linda. Linda isn't dependent upon Jini nor JavaSpaces obviously, and
JavaSpaces and some other Jini stuff was influenced by Linda. Nothing about JavaSpaces was
ever designed to not have the other classes from Jini in mind, and that does not predetermine
that those classes belong in spaces. They are their own set of ideas used by different systems,
and most things in Jini have separate specifications with others building on others which
is a natural system.

Better broken out all the different pieces can be implemented as needed through unlimited
means. You can do that now just not as easily if things were broken out into smaller build
artifacts and better logically partitioned perhaps. Nothing in the above means the system
is low quality or bad as you wrote in another message.

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

No if that were the case it wouldn't matter, but the issue is that if you want spaces to be
able to be in a JAR by itself then you need another common JAR to use along with it. That
would contain Entry. Other things use entry. It is not specific to spaces. See:
http://www.jini.org/wiki/Jini_Entry_Specification

It defines a specific way of using Entry; protocols. This is not specific to the rest of Jini
nor JavaSpaces. It is something else and can stand alone without the other concepts.

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

Why do you feel Entry is JavaSpaces specific?
I don't think it is spaces or the rest of Jini specific. It is used
outside of spaces for many other things, and if spaces was no more,
Entry would still be used and viable. Jini is much more than JavaSpaces. You can have a common
set of things, the rest of Jini, and spaces. How is that a bad architecture? I don't see it.


You don't have to swallow the whole turkey to use spaces, but if you want to use spaces like
Linda then, yes, you need all of Jini unless you fill in the blanks. What is your suggestion
on the blanks? Do you think all that distribution can be made simpler? Where is that to go?
In spaces? 

If so, then it really becomes a different animal, and it seems you need a whole other thing
which is not JavaSpaces but something else that you name what ever you like taking the spaces
logic and breaking out anything Jini from it and coming up with a new project entirely. Now,
if it is just a simple standalone, non-distributed implementation of the current spaces interfaces
not needing to be looked up through other Jini APIs then sure, a River sub-package that uses
common and spaces.

If you mean to just use the interfaces and implement all the rest then that is something else
entirely. Would you not be able to take a common library, javaspaces, and then do that? Or
are you saying that would be too much that javaspaces rely on another package just as the
rest of river does? If you have a set of interfaces, and the ability to remotely load a JavaSpaces
implementation, then you have spaces untagled from the rest of Jini. Transaction, Lease, etc
can all be in a common library as part of River to me. Then you have that capability. 

Or, are you saying that you want a spaces *implementation* in River that is not single process
or JVM and does not rely on the rest of the River/Jini concepts? My question, if yes, is:
Do you already have a design for this? Are you implementing something like this now just not
using spaces? What do you have now which matches spaces? If you have something now then showing
folks the JavaDocs etc gives them something to look over. 

Either way, there is a lot of good stuff in Jini that would have to be taken care of *yet
again* to come up with a comparable solution, and frankly I think you are wrong if you think
all the code is low quality. It isn't any lower quality than Tomcat or many other open source
projects, even at Apache, I have seen, and I bet you are using them. If you use JBoss or Tomcat,
or anything that embeds it, not forked from it, but embedded, then for years you have had
a lurking issue you most likely didn't even know existed because a JBoss developer, at the
time, removed the concurrency of the Application, Session, and Request maps in Tomcat, and
it was just now fixed, recently, in only the later releases of Tomcat; the reason was performance
:-S. It might have even bit you a time or two and you most likely would not have known other
than you could have lost some data or crashed a couple times. You can dig around for that
in the tomcat issues...I had to help
 point out the issue and offer reasons for why this was bad regardless of performance, but
I won't name names.

Wade

 ==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

Mime
View raw message