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 Sat, 20 Dec 2008 18:02:44 GMT
----- Original Message ----

> From: Michael McGrady <mmcgrady@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

Mime
View raw message