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 transport.
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
