river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Wed, 22 Jul 2009 17:29:35 GMT
Niclas Hedhman wrote:
> OSGi zealots don't like Jini for many reasons, probably in reality
> driven by politics more than technology. One key technology that has
> repeatedly been mentioned to me as a show-stopper for even considering
> Jini in a more central role, is the differences in "service
> attributes/properties". Jini's 'exact-match' Entry matching is
> considered inferior of the LDAP expressions of OSGi. Somehow it feels
> like a weak argument, and I think River today would consider
> convergence on this point.

The issue which I think is never fully considered is that lookup is based on the 
Java type system, including complex types, and not based on string matching.  If 
it was just string matching, we'd have RE support now.  But there is no defined 
RE syntax for "derived from" or "implements X" etc.  The Java type system 
provides that.

I will concede that the mechanics of matching in reggie are a reimplementation 
of the type system semantics, because code is not unmarshalled (as a versioning, 
code corruption, and security measure, at the least).

I'm more than willing to put together a new lookup service that does provide 
"string only" lookup of Entry.toString() values.  It would be possible to 
include new data, taken from the Entry values before they are marshalled for 

My changes to reggie to support deferred downloading, include the packaging of 
all class and interface names as part of the MarshalledInstance so that you can 
ask if an Entry (or the service itself) "is a" without having to unmarshall it.

Mobile code is non-trivial.  Many of us have experience now, and River has some 
additional tools that were not in place before (PreferredClassLoader for one) 
which can "help" manage class dependency trees so that unmarshalled object can 
avoid being corrupted.

My http://griddle.dev.java.net project illustrates that you can have a 
"Javaspace" like thing with live code, including matching using code.  I 
separated the keys from the data though so that you can use native types for 
keys and unmarshalling them doesn't "load" any code.

There are lots of things that I suspect the OSGi camp is only now discovering to 
be necessary "evils".  Some will be things we can work around or do differently.

Designing a completely new lookup, and getting it into the "Jini world" might be 
a useful task, but we will only be able to do that one time, I'm guessing.

OSGi was aimed at "everyone you want, can participate" in this VM.  Jini was 
aimed at "everyone who wants to, can run code" in this VM.  There are different 
considerations for each.

Participation in OSGi is selected participation because the container is loaded 
with what you want to run.  Jini is open participation, because the network is 
full of things that want to run.  It's the subtle, but important difference in 
who initiates the installation of the software that makes all the difference.

Gregg Wonderly

View raw message