Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4AF40932.5070502@zeus.net.au>
Date: Fri, 06 Nov 2009 21:32:02 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: River & OSGi
References: <4AF391EE.70006@zeus.net.au>
 <0D2AF945-B7BF-4DA9-9D27-557F3D296460@topiatechnology.com>
In-Reply-To: <0D2AF945-B7BF-4DA9-9D27-557F3D296460@topiatechnology.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mike McGrady wrote:
> First, I would like to know what the "shared" "Service Pattern" is.
Sharing - Objects moved between jvm's in a distributed environment.

Distributed Service Pattern -  Dynamic Runtime Discovery - Lookup of 
Objects that share a common Interface, receiving a proxy that enables 
the transmission of as Parameters and Returned Methods using Jeri / RMI 
/ Serialization etc.

>   Second, I would like to note that in my opinion changing Felix, 
> which is architecturally on firm ground to accommodate Jini is a huge 
> mistake.
Why? Felix is designed to be embedded into systems, are you suggesting 
Felix isn't suitable, would you prefer I use another Modular 
infrastructure to manage package visibility?  If so which one? The 
current alternative JSR-294 depends on Java 7 and hasn't been released 
yet.  I fail to see why utilising mature code as opposed to expending 
much time reimplementing when something already exists would be a huge 
mistake?   I have considered extending Classworlds, however this would 
require jvm restarts when packages needed to be replaced.  The Java 
Package Version Specification is optional and isn't widely implemented.
>
> I am not convinced that this analysis understands the depth of OSGi.  
> Certainly the module, lifecycle, service levels of abstraction in OSGi 
> seem to me to not coincide with the notion of service in Jini.  This 
> difference is greater when distribution is considered.  I would 
> suggest that no decisions be made without a more developed and better 
> expressed alternative than this.  Felix does not need to compromise 
> it's architectural integrity to accommodate less mature concepts in Jini.

OSGi segregates bundles of software (jar files with metadata) into 
separate classloaders, controls visibility of packages between bundles 
based on compatibility information (metadata) in jar files and enables 
the bundles to be stopped, replaced and restarted.

To utilise OSGi, a Jini program must be distributed in a bundle 
containing dependency information on package version imports.  To be 
made available outside its Classloader (one for each bundle) the 
visibility of Packages must be controlled, it's public API Packages must 
be registered ie the bundle started.  Since Java cannot reload class 
files when a Bundle is upgraded, it must reside in another Classloader, 
so Classloaders are Bundle and version specific.  The service pattern 
enables the bundle to be rediscovered by identity locally within the JVM 
after an upgrade.  A Jini service must be exported and registered to be 
available for lookup, if it is being managed by an OSGi framework it 
must first have it's bundle started and registered.

Jini currently loads class files into classloaders based on the local 
availability of classes or http coadebase URL origin, imposing 
restrictions on sharing of Objects, this is suboptimal, OSGi can assist 
in resolving this issue by providing a framework that manages package 
visibility.  However I don't believe that OSGi alone is enough in a 
distributed environment

Please provide me with facts so we can have a meaningful discussion, 
from your reaction I detect your gut feel is telling you this isn't the 
right approach, my gut feel is that it is. I've based my reasoning on 
facts, I need some factual information to be convinced otherwise.

No offense intended.

Regards,

Peter.
>
> Mike
>
> 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.
>>
>>
>>
>>
>