All this talk of OSGi has probably got some people worried, don't worry,
I'll create an experimental area on svn for the OSGi side of things, so
you can dip your toes in first.
I have no intent of trying to map OSGi services to Jini Services or vice
versa.
I'd only be utilising the basic OSGi framework, so there wouldn't be any
further dependencies to worry about, I'd include it all in the one
download archive. That would keep the different services models
separate, as they should be, to be used where each service type makes
sense. OSGi Services for local JVM services, as it is used now and Jini
Services for remote, as I said I wont attempt to map these services as
their intended purpose and design is different and specific for each
niche. You wouldn't try to map an SPI interface directly to a Jini
service and vice versa, so why do it with OSGi.
The OSGi service registry is used to look up an OSGi service by its
fully qualified class name. In Jini you must match all the interfaces
in a ServiceItem. If you try using OSGi service semantics in remote
services, you'll run into all sorts of problems with the visibility of
interface inheritance hierachy's, ClassLoader visibility, unrecognised
required dependency's and class not found exceptions. This would occur
because you don't know all the interfaces the proxy class must support,
interfaces which must be visible to the proxy at the client at load
time. I know this from issues other projects have had with OSGi and
reflective proxies and my own experiences with ClassLoader's
OSGi currently has the Oscar Bundle Repository, which is a http or https
codebase. I'm thinking of modifying this to utilise a Jini Service to
download java bundles from. This will allow codebase services to be
discovered at runtime.
Cheers,
Peter.
