river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bowers, Ronald (Civ, ARL/SLAD)" <rbow...@arl.army.mil>
Subject Re: Future of Jini/River
Date Fri, 14 Nov 2008 13:04:04 GMT
On 11/12/08 6:58 PM, "Jools" <joolski@gmail.com> wrote:

>> The out-of-the box experience: IMHO, the real trouble is that Jini is a
>> network technology and networks just aren't nice, a single machine can
>> have a myriad of network interfaces, some of them with dynamic IP
>> addresses, some of them registered in DNS, some of them supporting
>> multicast etc.  To address this problem requires agreeing on what a
>> minimally acceptable environment might be, having a means to determine
>> whether any given machine meets the necessary requirements and where it
>> doesn't generate useful debugging information to assist in a fix.  It
>> also means deciding on what should be possible out of the box, chances
>> are the more ambitious one is, the fewer machines there will be that
>> satisfy the environmental needs by default.
> Agreed. And this is the fundamental issue with Jini, we do expose some of
> the more difficult issues when dealing with networks, but we should be
> looking at guiding the user through the mire.
> I recall a project starting a while back which would probe your system and
> give you some advice in regards to how best to configure jini, not sure
> where this is now.....
> However, once the hurdles are dealt with, users of the technology become
> instant fans.
> But the initial curve is a bit steep.
> But the benefits are worth the investment.
> My team have just deployed a Rio based system, which provides Restful based
> services, dynamic load balancing and deployment all using the Rio toolkit.
> Getting up to speed with Rio was a breeze for the developers as Rio handled
> all the nasty stuff most developers just want to leave to the admin staff,
> and the admin staff can tune the rio system for their needs.
> So, getting back to the point. Jini is not the issue, IMHO. The how easy we
> make it for the user, and how confident they'll be in the end result when
> trying to convince management that it'll work.
> --Jools


I agree whole-heartedly on the joys of working with Rio rather than with
'naked' Jini/River. We* are developing a distributed simulation environment.
We stared it in Jini, but quickly ran into issues. First, as you said the
learning curve was steep. That made it difficult to get other team members
to be able to help with service development. Other issues were

- How do I deploy my services to the dozens or hundreds of available
- Given a heterogeneous computing environment, how can I ensure that
services are deployed only to machines capable of handling them, and
- A whole lot of boilerplate code to establish relationships between

Anyway, now that we are using Rio, we spend much more of our time working at
the application level rather than at the service communication level. In
turn, this has enabled us to take a project that was near death and start
making it successful. I am also very pleased to say that we have been able
to contribute back to the community by funding several enhancements to


* The U.S. Army Research Laboratory
** shameless plug :)

View raw message