The point about JavaSpaces and Jini and River that many are making are they are all part of the same thing on a higher level. JavaSpaces is just as much Jini as the other APIs because they are all part of the same Linda implementation albeit a Linda implementation with perks which is what Jini (River) has outside of tuple spaces, lookup, and discovery. Essentially to have a Linda system we have to have Lookup and Discovery and it be an abstracted hidden behind the scenes kind of thing for different pieces of the puzzle to make things distributed or single VM at the drop of a dime...smart proxies and the like...in VM or out. The components using it are not to have to know about running in a single JVM, multiple, or likewise. Annotations can help here with the ability to be changed by configuration files and markup.
Entry and Transaction are what they are...simple as pie. Entry...Message. An Entry, being how it is a marker interface, is not really Spaces nor Jini from the perspective you are writing about cohesion and coupling. The same can be said for a Transaction, net.jini.core.event.*, ...lease.*, and many others. They are core libraries in the total Jini package now called River which could technically be used for other things, reside on their own as simple libraries, and they just happen to reside here as an API used by the other pieces. org.apache.river.core org.apache.river.spaces org.apache.river.lookup or org.apache.river.jini.core org.apache.river.jini.spaces org.apache.river.jini.lookup Seems essentially like what we have today less the package names are different; obviously this is simplified leaving out some things. Spaces will still need core. Lookup will still need core as will other things. Entry, Transaction, Lease, Event, etc all will still be in core as I can see it, and obviously other classes will be moved around into some different packages, or at least they need to be if we make this more modular. Regardless, there has to be some level logical ordering into final units as all we will accomplish, until the interface count is higher, if it ever is, will be making a bunch more JAR files for no good reason (until those JARs are large enough...doesn't mean we can't have things in different packages). Each JAR file or separate classpath just means extra lookup and overhead, this is true from a pure JVM level and from an OSGi and NetBeans module system level, though most likely when used in OSGi or an NB module these things would wind up in the same module and classloader. So, cohesion, coupling, technicalities and a perfect world are often more blurred than we'd like. You or someone has mentioned Linda before. Entry and Transaction are needed at the core of a JavaSpace though I see nothing in Linda which says the entry can't be an arbitrary class nor that the model of transaction is a requirement, but something like it is needed and we already have it; POJO support even at the Entry level. Anyways, those classes are needed in other places and used by Jini (an extended Linda system with more capabilities). There is no need to try to have different classes represent the same thing in different parts of River if this is the level of cohesion and decoupling you would like to achieve. I'm still not clear on your exact meaning here as it relates to what you specifically want is why I say that, and *is why I wrote before about an example being best*. Now, I'll give you there needs to be some better separation of the core, the interfaces, and different concrete classes, and in the movement better modularize I believe we can find many different sub-APIs which can be used for multiple purposes even outside of Jini. Some examples would be classes like ServiceDiscoveryManager which uses com.sun...jini and net.jini...seemingly pulling in implementation details from multiple places; all I'm really saying is that stuff could most likely be better organized I just don't all of which ones yet. Regardless, I wouldn't want us to break things up if they are insignificant in size to make extra JAR files unless they are becoming larger, though packages I don't necessarily have an issue as long as we are not duplicating interfaces just for the sake of decoupling and cohesion. Simple reason is technical overhead and it does add more management to the entire project; plus duplicating interfaces, even by name, is more confusing. Too, I think many of the things Jini/River provides are the actual components we *must* have for a Linda system, though I won't argue some things can't be better. I'm just saying that nothing is keeping us from using these pieces as a logical Linda system in a single JVM or multiple, and those components do provide that capability. You just have to go through lookup and discovery to get to them whether that is local or not if you want to use them in true Linda fashion so that you can change to a network distributed system on the fly without having to change the source code. Seems we are talking of making River something different than what it is, and at the different libraries level I don't necessarily have a problem with them being multi-faceted, as many are capable now by their shear simple nature; I don't want to lose the essential concept that is River in the process however though I do think the different components maybe can be made easier to use either through annotations, different services, and new ideas. Either way, a difficult topic until we get much more concrete and specific with some branches or something. Seems we'll all have some coding to do just to get to a better understanding let alone agree on what we want, need, and are willing to support. The life of developers :-D 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: Wednesday, December 10, 2008 12:07:28 PM > Subject: Re: Split JavaSpaces and JINI > > COHESION WORST TO BEST > > Cohesion is a measure of how strongly related the various responsibilities > (operations, methods) of a software module (class, etc.) are. High cohesion > results in robust, reliable, reusable and understandable code. Low cohesion > results in difficulties with maintenance, testing, reuse and understanding > difficulties. (Do any of these ring a bell with JINI?) > > > 1. Coincidental: no relation > 2. Logical: grouping, for example, by IO routines even though different in > nature. > 3. Temporal: grouped by when they are processed. > 4. Communicational: grouped because they operate on the same data. > 5. Sequential: grouped because the output of one part is the input of > another > part like an assembly. > 6. Functional: grouped because they all contribute to a well-defined task, > e.g., calculating the sine of an angle. > > COUPLING WORST TO BEST > > Coupling is the degree to which a module relies on other modules. High, > tight, > strong coupling contrasted with low, loose, weak coupling. Low coupling is > when > a module interacts with another module and does not need to be concerned with > the other module's internal implementation. > > 1. Content: one module relies on the internal workings of another module so > that changing the second module produces data will lead to changing the first > module. > 2. Common: two modules share the same global data. > 3. External: two modules share an externally imposed data format, > communication, protocol or device interface. > 4. Control: one module controls the logic of another by passing it > information > on what to do. > 5. Stamp: modules share a composite data structure and use only part of it, > e.g., passing a whole record but only needing part of it. > 6. Message: modules are not dependent and use a public interface to exchange > parameterless messages or event. > > Various technical levels have tight and loose coupling: > > TECHNICAL LEVEL > > A. physical - tight is a direct physical link - loose is a physical > intermediary. > B. communication style - tight is synchronous - loose is asynchronous > C. type system - strong type (interfgace semantics) - weak typing (payload > semantics) > D. interaction pattern - OO style naviation or complex object trees - > data-centric self-contained messages. > E. Control of process logic - statically bound services - dynamically bound > services > F. Service discovery and binding - strong OS and lanaguage dependencies - OS > and > language independent > G. Platform dependencies > H. Time - compile time binding - runtime binding. > > What I suggested was putting in JavaSpaces all the interfaces that are part > of > the JavaSpaces functionality. > > Mike > > > On Dec 10, 2008, at 10:54 AM, Dan Creswell wrote: > > > Michael McGrady wrote: > >> +1 This is not, I would stress, to question or to otherwise lessen the > >> value of JINI. This is just to allow JavaSpaces to live its "natural > >> life" and to move what is in JINI but belongs in JavaSpaces to > >> JavaSpaces so that a Java implementation of Linda spaces can stand on > >> its own. Then, as Niclas has noted, JINI can use and extend JavaSpaces > >> as required. > >> > > > > Could you please explain your logic for placing some of these core (and > > shared across services) classes into JavaSpaces. I hear what you're > > saying but at least for me right now it feels like you'd be making a > > less cohesive system rather than a better split one. > > Michael McGrady > Senior Engineer > Topia Technology, Inc. > 1.253.720.3365 > [EMAIL PROTECTED]
