river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jools <jool...@gmail.com>
Subject Re: Future of Jini/River
Date Fri, 14 Nov 2008 13:16:38 GMT
Ronald,

I totally agree with you !

The dynamic dependency download and SLA mechanisms have been a real boon for
us.
No more installing jars anymore, rio just downloads and installs them. Then
clears them away when you've finished with them !

We are currently developing a maven download manager for Rio, so you can
deploy directly from the dependencies in a pom.xml

But I digress :-)

--Jools






2008/11/14 Bowers, Ronald (Civ, ARL/SLAD) <rbowers@arl.army.mil>

> 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
>
> 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
> machines?
> - 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
> services.
>
> 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
> Rio.**
>
> -Ron
>
>
> * The U.S. Army Research Laboratory
> ** shameless plug :)
>
>

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