Thanks, John, I am really glad you said this. The question I am
raising is not whether JINI is useful. I assume that JINI is very
cool. In fact, i will admit only to you that I want to use JINI but
do not want a messy architecture because my projects require semantic
sense because they require ultraquality. (The only way to make sure
that you don't have bugs at the end is not to introduce them along the
way.)
There are many, many of us out here who would like to use JINI,
JavaSpaces, etc. However, I am suggesting that River needs to see
there is a reason it is not being used and it is neither because we
are lazy nor because JINI is not cool.
I don't care that there is a way to figure out how to use JINI. I
care if the product is properly architected because I know that if it
is not it will bite me in the butt along the way, And, my view of it
is that it should separate JavaSpaces out.
You might look at another bit of functionality that has the same
problem, mobile agents. The mobile agent field has a wonderful
standard in FIPA (see OMG, Sun Microsystems and IEEE) and a very cool
product. Nobody uses it. Nobody. The product is wholly academic
because you have to swallow the whole damned turkey when you only
wanted part of the drumstick. What if you just wanted a migration
service and not artificial intelligence, CORBA, and the rest of the
kitchen sink? Same with JINI.
Structure things so they are useful rather than useful only to someone
who wants the whole shebang. The lack of interest in a cool product
rather proves that there is a problem with the architecture.
How does that old saying go? If want what you got, keep doing what
you have been doing. If you want something difference, change what
you are doing.
Mike
On Dec 12, 2008, at 1:19 PM, John Sarman wrote:
Mike,
Suppose the Javaspace API became totally decoupled from Jini. So
now you
are busy writing code and you are happy. Now your customer asks if
you can
make a system to send Gigs and Gigs of data and have 20 distinct
physical
locations with automatic fail-over. So now with your JavaSpace,
I'll call
it the NakedSpace, you need to build some networking infrastructure to
accommodate the clients requirements. You wisely decide to use the
space as
a mechanism for looking up and retrieving the information needed to
make the
high bandwidth connection. Lets say you decide to store in the
tuple the
streams meta-data for searching and a network endpoint to create the
connection. Also you have some security tokens, blah in this
tuple. Great,
so now you build all this network code to provide the failover times
20.
Once you complete this you read more about Jini and realize you just
reinvented the wheel. I think from reading the posts, that you have
not had
that moment of realization of the power of Jini. Everyone wants the
easy
button. Well I think Dan Creswell's site explains in great detail
how to
get a jini service up. Yes Jini is not for the faint of heart and it
does
take some real work. But once you get over the learning curve then
network
distributed computing with full recognition of the fallacies of
distributed
computing becomes possible and simple . Sure everything has a
RemoteException. Well its Remote! or can be. Sure Leases or
complex, well
knowledge that a failed remote point has failed is hard to obtain!
I got jini to work my first time in 2000 on a Windows 98, definitely
no
easy button then. But then when we took that work and moved it from
localhost to other computers and it just worked, that was my WOW
moment.
When I attended Discovery 01 jini convention me and another attendee
built a
jini enabled lego mindstorms robot. Before I a chance to test the
ServiceUI
gui that we added to the service, another attendee that did not have
any
knowledge of our project other than observing from a distance our
tinkering,
took control of our robot. Well we added the attribute to our
service to
allow him to remotely download our Gui, we just didn't realize that
someone
was running some code to actually see our service appear on the
network and
to locate the service and launch the GUI via ServiceUI API. But man
was that
the coolest thing ever!
Enough rambling, try out Jini builds some services, forget about the
easy
button, when you get stuck, post messages and I am sure all the energy
devoted to this topic by the excellent programmers would be more
that enough
to assist you. After you try it and you get the WOW moment, ask
yourself
the same question, I think you may change your opinion!
John Sarman
On Fri, Dec 12, 2008 at 8:49 AM, Wade Chandler <
[email protected]> wrote:
I didn't say you were a dodo :-D Anyways, forget that, see my other
reply
to your points. Seems the only real area I disagreed with you there
is no
javaspaces no jini.
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 <[email protected]>
To: [email protected]
Sent: Friday, December 12, 2008 4:57:02 AM
Subject: Re: Split JavaSpaces and JINI
Thanks, Wade.
You have my point askew. I don't know how to switch your
thinking. I
understand that one package or product often will need another.
That is
obvious. I also understand that classes can be arranged in
packages that
are
badly structured. It would, for example, make no sense for the
class
Class to
be in the concurrency package. Your description of what I think
makes me
a
dodo.
Mike
On Dec 12, 2008, at 12:30 AM, Wade Chandler wrote:
Oh jeesh man. Yes, stakeholders, projects, and relation. You have
just
been
writing about how it is such a no-no for JavaSpaces to use Entry
because
it is
not specifically a part of spaces....well String isn't either...and
neither is
Class.
Wade
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
