river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Concurrency and River
Date Mon, 01 Oct 2007 20:36:52 GMT
Gregg Wonderly wrote:
> Rick Moynihan wrote:
>> My guess is that they probably are solving *some* problems Jini has
>> solved, but that Jini from the outside appears to be about synchronous
>> RPC/RMI-like communication (even though it's not necessarily).
> 
> One of the primary arguments I get for Jini in places that I've tried to
> hype it, is that it requires Java.  Now this is from the same crowds
> that are happy that SOAP requires XML, or that REST requires(or is) HTTP
> servers.  So, I'm not sure how they justify, to themselves the
> requirement of one technology that is at a programming language level as
> been worse than a technology that is at the network
> layer/transport/encoding level which still makes it have to be everywhere.
> 
> Many of the arguments are about the fact that they believe that they'll
> have to rewrite all of the existing apps to exploit Jini technologies. 
> I guess they think that they can just rewrite "parts" of their
> applications to use "XML"/SOAP for messaging, or HTTP for transfers.
> 
> For me, this gets back to some of the issues that we haven't provided
> concrete examples for.  I.e. we don't have an example use of a JERI
> ILFactory that does something besides native method invocation.  We
> probably need to demonstrate how one might talk to a Javaspace, from
> .NET using SOAP for example.  The point of such an example would be to
> demonstrate that it's possible.  It might also be interesting to do an
> HTTP ILFactory that provided the translation from method calls to HTTP
> POST operations.  For me, this is not exciting, nor do I need it.  But,
> we do have people in the community which are doing cool things to put
> Jini into the web services world.
> 
> Somehow we need to help people understand that Jini no longer requires
> RMI on both ends, let alone Java.  Without traceable examples with well
> thoughtout scenarios and great documentation, I don't know how to make
> the point.
> 

I don't know that you can make the point ever - see half the reason for
the rebellion against Java in these cases is the "we might need to
integrate anything with anything else sometime, somehow somewhere"
philosophy.

Basically they're all assuming that using any Java-only solution between
two Java things is bad because there might one day need to be a link to
some other non-Java system.  The fact that they don't know what that
system might look like and that there are a million ways to solve that
problem better than forcing lowest common denominator interfaces
everywhere (a la CORBA, no offence to Waldo intended) goes
ignored/un-noticed.

Fundamentally the people you are arguing with are pursuing heavenly,
silver bullet, one size fits all dreams and your treading on those
dreams (slight W.B. Yeats mis-quote) will be stiffly resisted with
endless unfathomable, unreasoned, meaningless rhubarb.  And there's no
winning that battle.  These people will just have to build another
borked system, and another, and another until maybe (unlikely) they'll
realize that some more principled thought is required.

> I've tried and tried to no avail, and I'm ready to throw in the towel on
> being able to make the point with the arguments I can muster.
>

It's not all doom and gloom - the trick is to develop a few simple
verbal discussion tools that allow you to quickly determine whether the
audience is friendly/thinking.  Then you can either continue the
discussion or find something better to do with your time.

> Gregg Wonderly
> 

Dan.

Mime
View raw message