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 Tue, 09 Dec 2008 17:06:01 GMT
----- Original Message ----

> From: John McClain <John.McClain@Sun.COM>
> To: river-dev@incubator.apache.org
> Sent: Tuesday, December 9, 2008 11:34:47 AM
> Subject: Re: Split JavaSpaces and JINI
> 
> Michael McGrady wrote:
> > Thanks, Greg.  I think your worries are misplaced.  There is nothing in the 
> suggestion regarding splitting JavaSpaces and JINI that will affect JINI 
> negatively.
> > 
> > There is no question, I think, of "taking JavaSpaces our of JINI".  Rather, 
> the idea is to decouple them.
> > 
> > Modern computing, as you know, is in large part all about how to properly 
> organize complex systems.  Two related tools are to decouple modules and to make 
> sure that a module has high cohesion.  So, all that is being discussed here is 
> how to decouple, not a divorce.  This may only require moving the Entry 
> interface over to JavaSpaces.  
> When talk about moving the Entry interface over to JavaSpaces, what does that 
> mean? Move the package it is in, change the project it is in? What will that do 
> to the lookup service interface that also depends on Entry? What about the other 
> net.jini.core dependencies JavaSpaces has (leasing, events, and transactions)?

John McClain...who ran for President? heh heh kidding....I know the names are different, I
just couldn't resist :-D

But, yes, this is what I don't understand either. Seems where we have been talking about breaking
things out more modular is what can take care of some of this. Essentially there are some
shared classes between JavaSpaces and other Jini things, and those could be a jini-common.jar
kind of thing. This to me isn't an issue. There will always be some coupling of some APIs.
There is no way to achieve full on decoupling. Same as we have String and it is used *everywhere*.
NetBeans Lookup is used to decouple many things. However, many things use Lookup. It works
like this:

JavaProject extends
Project Class
-getLookup()
-getProjectDirectory() 

RubyProject extends
Project Class
-getLookup()
-getProjectDirectory() 

Then each of their Lookups provide things specific to those project types. For instance, Java
projects don't know anything about Ruby, so data loaders, file editors, all kinds of things
you can think of including project customization specifics are held in this lookup. Then folks
find a Project using another Lookup, and all they know is it is a Project type, and then depending
on what they need to do with their code they can operate on the project if they know what
kind it is and what object instances are availble in the Lookup, and the Lookup itself allows
this discovery:

Project jp = ...//we lookup the Java project
Lookup lu = jp.getLookup();
ProjectConfiguration pc = lu.lookup(ProjectConfiguration.class);

or you can even lookup more specific and fine grained things unique only to that project type...such
as classes.

Now, that is pretty decoupled. Though, at times this kind of decoupling can become very complex
in itself, and without great documentation on each implementation this gets horrible, most
specific project types are not that easily understood with digging through source code, but
technically this is what spaces provides now though you have a JavaSpace and Entries and then
any classes you need for your specific parts; JavaSpaces is technically the Lookup. Of course
there is Transaction and Lease. So, yes, what exactly needs decoupled and what can't be done?

Wade

Mime
View raw message