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 Sat, 13 Dec 2008 19:23:19 GMT
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  

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.


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 <
> hwadechandler-apache@yahoo.com> 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 <mmcgrady@topiatechnology.com>
>>> To: river-dev@incubator.apache.org
>>> 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
>>> mmcgrady@topiatechnology.com

Michael McGrady
Senior Engineer
Topia Technology, Inc.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message