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
mmcgr...@topiatechnology.com
