river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject River & OSGi
Date Fri, 06 Nov 2009 03:03:10 GMT
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.





Mime
View raw message