----- Original Message ---- > From: Michael McGrady <mmcgr...@topiatechnology.com> > To: river-dev@incubator.apache.org > Sent: Saturday, December 20, 2008 11:06:42 AM > Subject: Re: Split JavaSpaces and JINI > > > On Dec 20, 2008, at 2:54 AM, Dan Creswell 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? > >> > > > > Jini doesn't need JavaSpaces - JavaSpaces is merely one service built > > atop Jini. > > > > I've built a bunch of Jini systems that don't use JavaSpaces, I can't > > build Jini systems with JavaSpaces alone because it doesn't do lookup > > and underpinning discovery which is the Jini fundamental. > > > What you say is agreed upon. It does not relate to what I said. Again, I > don't > think you have a good grasp of what architectural dependencies are all about. > > You think engineering. There are two distinct disciplines: systems > architecting > and systems engineering. They are related but very different. Congress > mandates that in large scale systems, such as aerospace, they be so distinct > that the systems architecting be a nonprofit corporation, e.g., Mitre/CAASD > and > Aerospace Corporation. >
I'll say this then I'm pretty done. I would much rather Nick, Dan, Gregg, Michal, Jools, others and myself pull together and really start looking for actual issues and fixing things and moving on some of the ideas from the enumerated list plus some other things which has been talked about on the list. Those things will actually move us forward. The fact there are two distinct disciplines has nothing to do with what we are talking about here. We can be engineering or designing a system. Right now, we are talking about the design and the architecture which I'm pretty certain most understand ;-). Within the architecture...design...of Jini is a set of concepts. There is Entry, lookup, lease, transaction, and spaces,. All concepts. We all have a general notion of the generic concept of what a lease is. It is not different in Jini. The concept of a lease is very general and not unique to Jini or anything for that matter. A transaction is a series of steps which has a beginning and an end. It fails or it completes. Its changes are rolledback or commited. We all have a good idea of what a transaction is. I'm fairly certain all of us have a bank account or a credit card. Entry is much more than a marker interface. An entry is a special item which is written, read, and found in a certain way; through special protocols. The design and specifications detail how entry works. You can read it; I have already given you the link. A space is nothing more than a given abstraction where information can be read and information can be written. It happens to use some of the other concepts; concepts by the way which are not unqiue to Jini. To understand the architecture of Jini you have to first understand those concepts. There is no such thing as an architecture without requirements, nor in todays times are there systems not using common elements derived from concepts learned over time unless that concept is new; maybe someone gets cold fusion (energy not web technology) working today I don't know. You keep talking about the bad design. But, what you have thus far failed to illustrate is where the requirements are filled by a specific design which is better. I can open up books and give you a thousand concepts in a thousand different contexts, but until we get down into the details what we are specifically talking about, vague notions of those concepts have no meaning. Jini was designed to solve a specific set of problems. In that design lie concepts for some specific domains which some are mentioned above, and these have been the main areas of our recent discussions. Most notably entry. The problem with your argument for many of us is that you keep using words like cohesion and decoupling, which is pretty evident many understand, and yet you offer no valid reason why entry should belong in spaces, and have not even touched on why you keep ignoring folks comments that Entry is a common class and belongs in neither specific place other than entry itself, nor why the rest of the Jini APIs should depend on spaces versus spaces depending on some common ideas which other APIs also happen to depend. Jini has at its core a goal to make distributed systems easier. Not all distributed systems need to rely on spaces. One can easily enough create a system which uses a single database to provide common data between different systems. At that point spaces becomes irrelevant. Now, to get proxied database connections spontaneously and emergently (yes I saw your other emails) they must ask something for those things or have a programming language with all that support built in. Since Java isn't that language at its core we have the rest of Jini. Enter lookup (sort of like Bruce Lee kicking butt) to allow resources to be obtained from In-JVM or some other system. Lookup allows those data services to be found in Linda fashion. Now, you may content I'm just looking at this from an engineering perspective if you would like, but at some point the rubber has to hit the road. We have already detailed our concepts. We know from the concept of a space that something has to be written to it. Why not reuse the generic concepts we have defined to exist in multiple domains? That is logical, and you yourself believe it to be true because you are asking for Entry to reside in spaces, and at such a point in a debate I would have not written a single line of code, but indeed a good design has to be something which is able to be implemented and used without a bunch of complexity and duplication. If the architects do not understand the requirements, concepts, domains, and the resources which to implement solutions they can make the problem worse instead of better, and if the other concepts are not naturally dependent upon spaces why force that into a design? Spaces can logically and naturally be dependent upon those other concepts, though at this very moment it isn't dependent upon lookup unless one wants to use it in true Linda fashion. So, if one doesn't want to use the rest of Jini to use spaces they don't have to, but they still end up using common concepts such as entry, transaction, lease etc, and they can do whatever they like with the rest and to get a Linda system with spaces. Note the spaces specifications assumes the rest of Jini will be used to reach its true distributed capabilities (Linda). Yes, I'll go ahead and say it even though I'll hear if from more than you... Heh. After Jan., or before if President Bush gets on board with the crazy money flood again, Congress is also gonig to bail out an industry which is going belly up because of horrible executive decisions and being held hostage by unions. Anyone in business realizes they can't be saved if they can't make decisions based on the money they actually have versus some legal contract they never should have entered which has them spending more than they make. Too, there are too many times government contracts go way beyond their deadlines because someone who thinks they know how to architect a system that knows nothing about engineering one gets involved, is ingrained in the details, does nothing, is horrible at their job, and can't be fired either because of some silly contract or some kind of a nutty union or government deal; much like teachers unions. Point being, we have a bunch of know nothings in Congress who want to whine and spend money they don't have because they don't really understand the situation in most cases, and this same ignorance spills over into everything else including the space agency (their buget comes to mind), so their decisions don't really hold sensible weight to be used well in an argument. They can take that money they don't have, waste it, and be no better off except for a nation in more debt for no good reason, or they can make some legal and binding changes which affects the way a business can be held hostage by people with no stake in them other than a job, make sure publicly traded companies are not giving bonuses to people in certain exceeds and never when nonprofitable, be darn sure that if the governemnt gives those companies money they have the right to make some changes across the board, and that government programs or funded programs are run correctly and transparent as it relates to tax payers; we'll see what they do, but at this point why should we think they can get anything right? Wade
