Re: Jini Service Container advice...

[Calum Shaw-Mackay <ca...@gmail.com>]

Neon can host Jini services..... well it turns agents into Jini services

2008/11/30 Dan Rollo <da...@gmail.com>:
> Hi All,
>
> I'm in the midst of some redesign discussions with other devs on the
> CruiseControl project (plug link:
> http://cruisecontrol.sourceforge.net/distributed/index.html). ;)
>
> We have a "Distributed extension" aka: DistCC (for remote build agents) that
> we are trying to merge into the core of the project. We are also working to
> remove some coupling to "shared file systems" that have limited our options
> going forward. Towards that end, I see Jini as a way to keep hostname and
> other hardcoded network configuration out of the picture.
>
> In my stumblings with Jini, I've more that once done things the "wrong way",
> and I think I have an opportunity to use a nice "Jini Container" that will
> do things the "right way", and protect me from myself in the future. ;)
>
> While searching for such "Jini Service Containers", I have a few questions
> about what might be the best fit:
>
> Rio
> https://rio.dev.java.net/
> This is the one I've heard the most about, but I'm a little concerned about
> the size of it's footprint. Any thoughts here? Are there smaller "rio parts"
> that could be deployed, without requiring a ~15mb download on each client?
> Even if not, it's probably not a show stopper, but it may be harder to get
> buy in...
>
> Seven
> http://www.cheiron.org
> This link appears broken. Is it replaced by:
> https://whatsitdo.dev.java.net/  ?
> Is there some other "most up to date" URL to use for Seven?
>
> Harvester
> https://harvester.dev.java.net/
> Is this still active, and has the latest code been published somewhere?
>
> Others?
>
> CruiseControl has a fairly decent size user base, and I'd really like to
> find a way to remove (or at least hide) my "worst practices" Jini code (and
> also of course, make the system more stable, scalable, etc.) ;) Right now,
> only the "build agents" are distributed across the network via Jini, but
> ideally, we'd like to have every node be able to handle all tasks
> (bootstrapping, scheduling, building, publishing, etc). I think a container
> framework is the best way to make this happen, and with such a framework in
> place, we could then do things like replace the  build queue with a
> javaspace, etc, but that's step 203 of 5,000. Other suggestions are also
> welcome.
>
> Thanks!
> Dan Rollo
>