river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Chance <sgcha...@gmail.com>
Subject Re: River & OSGi
Date Fri, 06 Nov 2009 14:18:25 GMT
I give credit to Dennis; he consistently brings the focus back to
releases! In the short term, I suppose he is correct. In the longer
term, this matter of OSGi and River - perhaps more accurately
distributed OSGi (RFC 132) - is more strategically important.

If you guys were to look at my (few) posts you would note quite a bit
of emphasis on (distributed) OSGi "with" River.  Similarly, you
probably would note quite a bit of emphasis on releases from Dennis.

It seems prudent to focus activities on getting releases completed. We
could return to D-OSGi afterward. Or just let the conversation
continue to refine the argument, and thus, allow for a more sound
specification to be defined.

To be sure, it is not easy for me to say this because of my desire to
see "the right" intersection of River and OSGi - now! :-)

Thank you!

On 11/6/09, Dennis Reedy <dennis.reedy@gmail.com> wrote:
> Wow, this should be another interesting thread!
> Before we all get started on this rampage again, I suggest you read
> this article http://www.artima.com/weblogs/viewpost.jsp?thread=202304.
>  From my standpoint I think this project really needs some focus. OSGi
> adoption into River is certainly something to consider for future
> adoption, but IMO it is not something that should be presented as a
> possible future until River begins to produce releases and stabilizes
> as a project. We have now been waiting for quite some time for AR2.
> Can we get that moving? Please?
> Once River gets rolling perhaps considering how OSGi may play in the
> future of River can be considered. Maybe:
> - Looking at how River services can themselves be OSGi bundles [1]
> - Looking at a River platform that could also instantiate OSGi bundles
> and expose a service contained within that bundle as a dynamic
> service, accessible through the network using River technology [2]
> Dennis
> [1] I see this as the low hanging fruit here.
> [2] This and other things are also being investigated with Rio.
> On Nov 5, 2009, at 1003PM, Peter Firmstone 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.

Sent from my mobile device

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)

View raw message