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:41:40 GMT
Mike McGrady wrote:
> 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.
Not OSGi, but existing applications that utilise OSGi bundles. To scale 
out over multiple machines, then to manage the 8 fallacies of 
distributed computing, a remote Jini service might replace an existing 
local service and it might do so for multiple machines to easily share 
some common information.  I can think of several reasons.
> Sent from my iPhone
> On Nov 5, 2009, at 7:03 PM, 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