river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <mmcgr...@topiatechnology.com>
Subject Re: Split JavaSpaces and JINI
Date Sun, 21 Dec 2008 01:20:02 GMT
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