river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: River & OSGi
Date Fri, 06 Nov 2009 11:43:41 GMT
Thanks Sam,

Maybe Paremus might have some resources or consider participating 
developing in River.  All assistance is appreciated.



Sam Chance wrote:
> Peter,
> I'm intrigued by your assessment. I may not be "answering properly",
> but I think you may find some of the work completed. There are Jini
> jars that have been made as OSGi bundles. I recall seeing them in the
> OSGi Alliance's OBR.
> As for the Jini/River engineering you described, much of it probably
> is completed in the Paremus Service Fabric. You might consider
> visiting www.paremus.com and www.codecauldron.org.
> Richard Nicholson, the Founder and CEO of Paremus has contributed
> substantially to distributed OSGi. In fact, I understand he holds [an
> elected] position on the OSGi Alliance.
> It just seems like much of the engineering is captured in Paremus' software.
> Regardless, I am glad to read your email.
> Thank you!
> Sam
> On 11/5/09, Peter Firmstone <jini@zeus.net.au> 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.

View raw message