I agree with all but "I think JINI is conceptually dependent on JavaSpaces. No JavaSpaces, No Jini...", and I'll get to that, but the point is we do agree, or it seems to me we do. I think however the point is that folks are confused because Jini is the overall project. Under the jini packages you have spaces, lookup, etc. Within that you have different classes which are common which can be used in multiple systems, and then there is a blurry line between what is used when, the requirements, and whether there is a chicken in the egg problem or not, not what I'm perceiving is your view or Jini or JavaSpaces.
At a high level I see: Jini -JavaSpaces -Services (lookup etc) -Common (Entry, Transaction, Lease) technically can be used for other ideas. Now, to use a space, one needs to find one. That is where services comes in. Or, you could have a JavaSpace which is totally lookup independent used out right with no need to perform a service lookup. However, with such an approach can you ever achieve a truly distributed system. One which is capable of providing Linda concepts; a system which can be changed to distrbuted or single processor at the drop of a dime and transparently to the implementing code/logic, and continue to use JavaSpaces? If so, would it then not need to be locateable/discoverable some how? Is this not what other parts of Jini provide? What is the goal of JavaSpaces? Is it to provide a base Linda style system for Java? Is it a distributed persistence or tuple space? I believe the answer to both of those is yes. Now, does it make sense for JavaSpaces to operate without the ability to be distributed? I don't see why it can't serve two goals, so I say yes. However, for it to operate distributed, that space needs to be able to be found. Thus a lookup service of some form or another is needed. You lookup a JavaSpace and you now have a distributed space. Or, you use it directly, and you forgo the ability to have an automatic and transparent, distributed space. Either way you need Transactions of some kind. We have that now. You don't always need Lease. Maybe JavaSpace (Entry and Transaction) and LeaseableJavaSpace (All three). I don't know, but I still see spaces at large needing to be tied to service lookup at the base level, so what is the point of changing that smallest of pieces when a standalone implementation which is simple to use would serve the same purpose without all the other projects having to change their base concept of a JavaSpace. If you try to decouple JavaSpaces from the current need to use lookup to get to one, then you are going to have to replace that with something, and you wouldn't want separate things for spaces and the rest of Jini in my opinion. Do services need to depend on JavaSpaces? No. Any type of a distrubuted data model can be created with services without JavaSpaces being used, and you still have a viable distributed system. And, this is where I disagree with the assertion that Jini is tied to spaces instead of the other way around for specific needs. Now, JavaSpaces does take care of that for the developer so they don't have to create their own distributed persistence, but that doesn't preclude them from doing so. None of this precludes us from having better cohesion in the project or finding some areas where coupling can be improved in my opinion. I don't think taking it to the nth degree of decoupling is going to do anyone justice though considering the way that works today and the goals of Jini. Maybe some simpler ways of using those things and a standalone space could be a good thing, but I honestly don't think a distributable JavaSpace without Jini is a good idea, because the other parts of Jini are handling the most complicated tasks. 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 ----- Original Message ---- > From: Michael McGrady <[email protected]> > To: [email protected] > Sent: Thursday, December 11, 2008 6:54:43 PM > Subject: Re: Split JavaSpaces and JINI > > 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. > > 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. > > 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. > > Mike > > On Dec 11, 2008, at 6:37 PM, Gregg Wonderly wrote: > > > Michael McGrady wrote: > >> The idea of having JavaSpaces be dependent upon JINI rather than vice > >> versa > has no justification that I can see. Why would you do that? > > > > Michael, you keep saying this without illustrating which parts of Jini > JavaSpaces shouldn't use. > > > > Can you describe the type structure that you would convert all the things > > in > the JavaSpace interface API to which would allow a new JavaSpace with your > described independence work in an environment with applications that use the > current JavaSpace? That might help us understand the path of adoption into > existing application bases. > > > > Gregg Wonderly > > Michael McGrady > Senior Engineer > Topia Technology, Inc. > 1.253.720.3365 > [email protected]
