On Mon, Jun 16, 2008 at 5:26 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> I think the ideal outcome would be this: > > * Firstly we allow Axis2 to work cleanly in a OSGi environment. Axis2 need to lax the tight dependency between modules and services. This should be done only in OSGi environment, hence preserve the backward compatibility. This change is essential to Axis2 to work properly in OSGi environment. > > * We also allow Axis2 to work in a non-OSGi environment (full > backwards compatibility). Yes. Backward compatibility will be preserved all time. > > * We define an extension to Axis2 that is available as a separate JAR > that enables OSGi Current axis2 OSGi extension contains all 3rd party jars, which prevents from being proper OSGi. Axis2 will need a "bundle repository" which will download 3rd party bundles on demand. Most of the 3rd party jars that Axis2 uses are bundles (manifest.mf contains required headers). Thus, the bundle repository just need to hold the jars which are not bundles yet and has been converted to bundles. > > * If the OSGi extension is available, then that enables OSGi > deployment of services and modules Need service & modules lax from kernel to work this properly. > > * In other words, there is a well-defined way of creating a bundle > that is a service and a bundle that is a module, and once the OSGi > extension is enabled, the OSGi discovery mechanisms pick up the > extensions. OSGi events, and trivial. > > * Axis2 transports could also have OSGi metadata in the JAR so that > these could use OSGi to be enabled if OSGi is enabled. This is the place were we need to vote between 1. OSGi extender model 2. OSGi service registry model. My money goes to "OSGi service registry model". Where transports(senders/receivers)/builders/mr/deployers/etc can simply be mapped to OSGi service and add to AxisConfiguration as and when needed. I haven't put a not on this yet. At the moment we assume the extender model and these elements are available from bundles. > > I don't know if this is possible :) > Yes it is. We just need the lax between services & modules, and make sure Axis2 API is strong enough to plug the elements we needed. Thank you! Saminda > > Paul > > > On Mon, Jun 16, 2008 at 11:59 AM, Deepal jayasinghe <[EMAIL PROTECTED]> > wrote: > > Saminda Abeyruwan wrote: > >> > >> ================================================= > >> > >> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be > >> able to live in different class spaces. > >> ex: If the bundles needed different hibernate versions they can be > >> easily plug into different class spaces. > > > > With the existing Axis2 class loaders you can easily do that , so no new > > thing is going to add :) > >> > >> 2. We will be able to have multiple version of Axis2 instancres running > >> inside same JVM. > >> This require the need of minimizing System properties. > > > > This is YAGNI. > >> > >> 3. Axis2 will be able to initiate same transport with different > versions. > >> This will require proper integration of OSGi services. I haven't > touched > >> this area yet, otherwise whole situation will be overwhelming. > > > > What is the value of this , aren't we trying to build castles in the sky > > ;-) > >> > >> 4. OSGi life-cycle support. This will give the ability to > >> start/stop/install/update/uninstall bundles. > >> ex: I have myModule.jar which would mimic myModule.mar. We will be > able > >> use the above actions to to manipulate the AxisModule as we need. > > > > Yes , this a valid point that we can consider. > >> > >> 5. Once a user has written a bundle (which mimic > aar/mar/transport/etc), > >> they just need to upload them into a "Axis2 bundle repository", where > the > >> community can search them and install them into there system, without > >> shutting down the running system. > >> > > So isnt this same as service hot deployment ? > >> > >> 6. OSGi event framework. When bundle is (aar/mar/transport/etc) > >> install/started/updated/uninstall, using OSGi events other bundles can > >> change there behaviour. > > > > We already have this in Axis2. I know places like WSO2 WSAS they use this > > feature a lot. > >> > >> 7. When bundle are properly designed, one will be able to deploy these > >> bundles in any OSGi environment. Most of the app servers are in the path > of > >> supporting OSGi. All we have to do is to drop our bundles in their > >> repositories and start them > > > > I do not see a big value of this with respect to Web services containers. > >> > >> 8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles. > > > > You can already do with Axis2 services aar file , by adding "WWW" > directory > > in the services aar file you can achieve almost all the power you have > > mentioned. > >> > >> > >> 8. Once the ConfigurationContext become an OSGi service, any bundle can > >> access it and use it. > > > > Yes :) > >> > >> 9. People will be able to use OSGi registry to register POJOs as OSGi > >> services and make them as web services > >> (http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html) > > > > But with Axis2 you can expose POJO as Web services in very > straightforward > > manner. > >> > >> 10. People would need minimum effort to integrate into OSGi powered > >> Spring etc. > > > > Agreed. > > > > Thank you! > > Deepal > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Paul Fremantle > Co-Founder and CTO, WSO2 > Apache Synapse PMC Chair > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Saminda Abeyruwan Senior Software Engineer WSO2 Inc. - www.wso2.org
