----- Original Message ---- > From: Michael McGrady <mmcgr...@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
