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) <[EMAIL PROTECTED]> > On 11/12/08 6:58 PM, "Jools" <[EMAIL PROTECTED]> 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 :) > >
