A question, after the previous question is answered. Why in heavens
name would OSGi want to utilize Jini? That is a mish mash so far as I
can see.
Sent from my iPhone
On Nov 5, 2009, at 7:03 PM, Peter Firmstone <[email protected]> wrote:
Well, I've had a good think about it, this is presently the way I'd
like to utilise OSGi:
First let me make one thing clear:
1. Both OSGi and Jini utilise the Service Pattern.
2. Jini utilises the Service Pattern for sharing distributed
pluggable java software.
3. OSGi utilises the Service Pattern for making java software
modular, versioned and pluggable without JVM restarts.
When I refer to Jini I'm referring to the Jini Platform, when I
refer to River, I'm referring to the Apache River implementation of
Jini.
Java Also uses the Service Pattern with SPI for 3rd Party Vendors to
Provide Pluggable implementations of JVM components or extensions,
eg JDBC, Encryption software etc. Gregg inspired me by pointing out
possible PreferredClassLoader changes utilising the RMIClassLoaderSPI.
By embedding an OSGi implementation such as Felix into River in a
pluggable manner (usage is optional) River can support OSGi
applications and provide Jini Services to those local applications.
Doing so will require modification to the Felix Codebase, which is
probably best managed as a Patch for a Particular Version of Felix.
Additionally, I figure further modifying to Felix to support
interactions with Remote Codebase Services utilising Static Analysis
to identify Package API. The Static Analysis will be used for three
reasons, one to identify compatibility between software in addition
to the Bundle & PackageVersion metadata, two to identify later
versions of import packages that are compatible using a Subset of
their API used by a Bundle. Lastly but perhaps most significantly
to allow software to evolve without fear of runtime exceptions
caused by binary incompatibilities. Modification to Felix would be
done in a manner that didn't break compatibility with OSGi.
Let me make one thing clear, OSGi does not compete with River, nor
is OSGi's remote service standard intended to compete with
distributed frameworks, nor are they intending to implement a
distributed framework, the API is there to be utilised by
distributed frameworks, OSGi made a statement to this effect.
Benefits:
1. Existing OSGi Applications can be hosted by River.
2. Existing OSGi Applications can utilise Jini Services without
modification to OSGi applications, in a pluggable fashion.
3. The River Platform (with OSGi felix embedded) is the minimum
installation requirement (apart from Java), all sofware can be
downloaded on demand from codebase services, guaranteed
compatible, including additional security benefits from having
bytecode API identified by Static Analysis from a code base with a
trust relationship. The codebase would never execute uploaded
bytecode, just analyse and distribute it. Hence codebases are
mediators/proxy's for disconnected or untrusted service providers
or clients. All code and API apart from a minimal core platform
code could evolve dynamically over time.
4. OSGi enables local bundles to be restarted, this would allow River
to locally update older bundle's when a need no longer exists to
utilise an older version bundle or if another bundle requires a
later version, complementing software evolution.
I know that this is perhaps a somewhat bold ambition, however I
believe it would increase the interest in the River project,
especially from the OSGi community.
There are plenty of details to work out, such as how to implement
persistence services for bundles and their import packages over
restarts, how to coordinate starting and stopping of bundles that
contain Jini remote services. How to proxy Jini Lookup services
from within the OSGi framework to make these services available to
existing OSGi applications. OSGi would not be able to work with
Jini Services that didn't themselves utilise OSGi, Felix wouldn't
know which bundles were required for compatibility reasons. That's
where codebase services would come to the rescue, by checking for
known OSGi bundles that are in fact compatible and substituting
them. If a compatible bundle couldn't be found the codebase service
would have to create a bundle using available code.
One remaining concern I have is the approach of integrating Felix
into River. I'd like to make the required changes within Felix
Pluggable components if possible, so that the existing felix
implementation would only require some minor changes that we might
be able to get them to accept. That would allow us to have a
totally independent implementation which could continue to work with
future versions of Felix, and possibly other OSGi implementations,
in case word spreads about River in the OSGi community. I can't see
that I could use OSGi for replacing OSGi system components, but it
might be possible using SPI, ironically again another Service Pattern.
I acknowledge that the alternative method of making River a bundle
within OSGi is possible without changes to OSGi, however it doesn't
make it possible then for OSGi to utilise the codebase services I'm
interested in. If someone can show me that it is possible to do so
I'll consider the option seriously.
Cheers,
Peter.
