Jini has the behavior that clients dynamically discover the "code"
that they will use. OSGi has the attribute that clients load packages for the
"code" that they use. In both cases, the deployment mechanism has established
the content that is "the code". OSGi includes more literal dependency
specifications from each packages perspective. Jini doesn't do it that way.
Instead, the "codebase" and "classpath" mechanisms are used to "tell" the system
that is built what to do.
Thanks Gregg, an interesting observation.
With Jini Services, the client and service may be written by different
developers, or owned by separate parties and may come into contact at
runtime in a deployment environment, without ever having been tested
together. The client and proxy both depend on the Service API, the
client doesn't depend on the proxy. In OSGi, the client get's to choose
the packages and versions it imports. In Jini, it's the service
implementor.
An application developer could use OSGi to manage versioning, and your
CodebaseAccessClassLoader contribrution makes this possible. I guess
the proxy developer could use the OSGi framework for the correct
packages the proxy needs, provided OSGi is installed in the clients
classpath.
If someone is doing this successfully, I'm interested to hear your results.
Cheers,
Peter.
