river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Split JavaSpaces and JINI
Date Mon, 08 Dec 2008 18:01:18 GMT

On Mon, 2008-12-08 at 12:18, Michael McGrady wrote:
> Thanks, Holger,
> 
> The idea is not to jettison but to decouple JINI from JavaSpaces.   
> Similarly, in part, various Web frameworks (e.g., Struts) are  
> decoupled from Servlets.  Without something like JINI, JavaSpaces  
> would be useless but this is different than creating a situation where  
> JINI itself, rather than something like JINI, would be required.
> 

I can understand the view that JavaSpaces is an "application" on top of
Jini, therefore could be separated.  But I don't get what you do with
JavaSpaces sans Jini.  As someone else pointed out, how do you lookup
your space without Jini?

> The idea too is not to suggest that JINI is something that needs to be  
> replaced.  The idea, rather, is that it needs to be decoupled to  
> follow architectural best practices and that the lack of cohesion in  
> JIN:-JavaSpaces due to the coupling is not a good thing and can be  
> seen as the reason for a lot of the unnecessary complexity in River.
> 

Could you perhaps expand on what unnecessary complexity you see?  
> Mike
> 
> 

Cheers,

Greg.

> On Dec 8, 2008, at 7:43 AM, Holger Hoffstätte wrote:
> 
> > Michael McGrady wrote:
> >> Thanks, John.  I agree with everything you say.  However . . .  
> >> but . . .
> >> why not do what it takes to split them?  Why not put all the classes
> >> necessry to do JavaSpaces in JavaSpaces?  Now would be the time to do
> >> it, if ever?  If one of JavaSpaces or JINI has to "wear the pants",
> >> shouldn't it be JavaSpaces and not JINI, i.e., shouldn't JINI  
> >> depend on
> >> JavaSpaces and not the reverse?
> >
> > And how you would look up your JavaSpace "without Jini"?
> > Jini by itself doesn't really do anything useful, the services are  
> > key -
> > but that means they have to depend on the foundation. You don't have  
> > to
> > use the foundation if you don't have to, though the Entry interface  
> > is a
> > good example for why things are (and have to be) the way they are.
> >
> > -h
> 
> Michael McGrady
> Senior Engineer
> Topia Technology, Inc.
> 1.253.720.3365
> mmcgrady@topiatechnology.com
> 
> 
-- 
Greg Trasuk.  
Senior Technical Trainer/Solutions Designer
Ph: 905-315-9509
Cell: 905-921-6464



Mime
View raw message