On Sat, Feb 12, 2011 at 8:41 PM, Mike McGrady <mmcgr...@topiatechnology.com> wrote: > Isn't OSGi now distributed? See Fuse 4.0.
OSGi has a specification for remote services and how to express capabilities vs requirements, but the actual transport as such is left out, and it hooks into new APIs that the framework has to expose to intercept lookup and registration of services. Do, yes, what I mention is part of the OSGi scope, but since the River community has decided to not work together with OSGi (I think I brought that up first time in 2006 or so), similar functionality should be part of Jini. Java is no longer a "single platform", as it was in 1999 when Jini came about. Byte codes is another example of 'service proxy selection' constraints that come to mind. Native code could be another. Security permissions should probably also be 'advertised' in advanced. I think all this need to be speced out, for River to become interoperable, as Jini once promised. So, I think the actual problem is not that it can't be done, or that people are not doing it, but Jini's failure initially (IMHO) was the lack of interoperbility enablers, that there were no standards on top. People spoke of "there could be a Printer interface" but no one said "This is the base Printer interface, and extensions to it is made in this way...". And one starting point is the "environment", the first stepping stone of requirements vs capabilities matching... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug