river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Split JavaSpaces and JINI
Date Sun, 21 Dec 2008 05:14:49 GMT
Well, spaces is not actually coupled to lookup. To use a space currently in Linda fashion in
Jini then yes, you need the lookup stuff, but the spaces themselves are not bound to lookup;
not coupled at all. You have this space in a given distributed system, and it must be found.
Now, you could very well have a space found by any custom means necessary without anything
else from the Jini APIs except for Entry, transaction, and lease. Those other things just
happen to be some common concepts which spaces uses. Just because it uses them should not
mean they reside in the spaces API or some packing specifically for spaces. 

I 100% *disagree* that an entry is useless without a space if we are talking about a JavaSpace
versus a generic notion of a memory space of some kind. An Entry is just as valid in different
contexts as it is in a JavaSpace. The methods in which it is used are not defined necessarily.
There is an expected way of using them as templates and matching for comparing them etc along
with expected ways they will be serialized and conversely deserialized.

That argument aside, there is nothing currently forcing you to use the other things in Jini
with spaces, except for those required concepts detailed here, though lookup is the only way
to use spaces in the context of a distributed system if all you have is Jini. You can take
all the things actually required to use a space, never use lookup, include those things on
your classpath, and be on your way. However, you'll have to create an entire architecture
to deal with the distributive nature one would normally want to use with a space.

Maybe that is where you need to focus what you are proposing. I don't think you'll ever convince
me or most others those other concepts need to be in spaces as they are very generic and can
be used for numerous other things where one may never want spaces. However, you might have
something you can detail with respect to a different type of a distribution mechanism to offer
some light concepts or something. I think there is a lot there to deal with however which
is what the rest of Jini does. You might have or come up with some design which you can get
some rudimentary things working to share and prove it. Seems anything really useful if you
go that far though would really just be a remote space with some pluggable tranport mechanisms
which you could then use other technologies to wrap around it, but truly that sounds like
the same thing Jini is/does unless you have some specifics.

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 <mmcgrady@topiatechnology.com>
> To: river-dev@incubator.apache.org
> Sent: Saturday, December 20, 2008 8:20:02 PM
> Subject: Re: Split JavaSpaces and JINI
> 
> I don't think your comments are from an engineering perspective, Wade, and i 
> like very much what you have said.  This is encouraging  I don't think system 
> architecture and system engineering can be completely divorced either.
> 
> Architecturally, i think that the concept of a space necessarily contains an 
> entry which has various operations.  I think a space is not only useless without 
> an entry but an entry is useless without a space.  From my point of view, lookup 
> should be decoupled from spaces, entries and the operations, e.g., read and 
> write.
> 
> I could go on but would be interested if anyone else thinks that this much is 
> solid.  I would also like to hear if others think this is not a viable way of 
> thinking.
> 
> On Dec 20, 2008, at 10:02 AM, Wade Chandler wrote:
> >> 
> > 
> > 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
> 
> Michael McGrady
> Senior Engineer
> Topia Technology, Inc.
> 1.253.720.3365
> mmcgrady@topiatechnology.com


Mime
View raw message