Nicole, More comments inline -
>it would be great if you could send us your sample code :-) >Playing with the source code will help us to understand. Packaging it now. You'll get the samples and the prototype runtime as well. I'll have it in the mail to you and Robert today. I think it'll really help our discussions, instead of me waving my hands about my head and writing about things you haven't seen! ;-) >I have some comments to your EMail: >I don't want to propose something antithetical to OSGi's philosophy. >We had the OSGi R4 Declarative Service(DS) specification in mind. In the >bundle manifest you can configure the component.xml files for the >components >contained in the bundle. The DS 'scans" or "searches" for the >component.xml >files and is reponsible for the dependency management (as defined in the >component.xml >files) and activation/registration of components. >We thought that the proposed "Tuscany runtime service" could do >something similar >to the DS. Perhaps 'antithetical' is too strong a word... My 'scanner' is basically a bundle listener. Scdls in activated bundles get deployed as applications into the Tuscany runtime. My thought was, don't try and replace DS. Let DS deal with interdependencies between OSGi services, and let the OSGi service binding be the mediator between DS and Tuscany. >The next question (which is not easy to answer for me) is if every SCA >component should get its >own Tuscany runtime. I would say this depends on the view or the level >of integration. >From my understanding we're currently talking about "SCA/Tuscany >embedded in OSGi". That's one >level of integration. Another level of integration might be an "OSGi >based SCA container". >For "SCA embedded in OSGi" I have one Tuscany runtime (which consists of >a small number of >OSGi bundles) in mind and which is able to host many SCA components. I should probably make a distinction here - if you look at the WebApp runtime, for example, it creates a single Tuscany system runtime, and deploys a single application into it. The runtime interface definition even reflects this mapping. What I've got takes a single system runtime and deploys multiple applications into it. So when I said multiple runtimes, what I meant was multiple application runtimes. >For "OSGi based SCA container" I have an OSGi container in mind, which >supports 'out-of-the-box' >SCA. We could have an entry in the Manifest pointing to the scdl file >(like today a link to >the component.xml file). Every OSGi service can use the full feature set >of SCA. In addition we >have implementation types like an EJB implementation type. The >implementation type itself >would provided in another OSGi bundle, e.g. an EJB container running in >an OSGi bundle. All EJBs will >be deployed in the EJB container bundle. This would mean we have SCA >components written in EJB >technology running in one OSGi bundle and SCA components written in >'OSGi technology' running in >separate bundles. Here's one way to deal with that - if the bundle has a default.scdl in a Tuscany folder under meta-inf, give it it's own system runtime corresponding to the default.scdl, and deploy it's apps into that runtime. If the bundle had application scdls under an Sca folder, then use the default runtime to deploy into. That way we can provide a single runtime to support both models. Sound good? Best regards Nicole -----Original Message----- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 4:55 PM To: [email protected] Cc: Jasny, Robert Subject: RE: OSGi Binding Hi guys - answers (and more questions) inline: -----Original Message----- From: Wengatz, Nicole [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 10:32 AM To: [email protected] Cc: Jasny, Robert Subject: RE: OSGi Binding Hi Joel, I discussed your EMail with my colleague Robert. We have a lot of questions, I assume because we are new to Tuscany and SCA :-) >>I'm having issues with the Axis2 binding right now. >What is your use case, using the Axis2 binding to invoke an OSGi >Service from a SCA component running outside of the container? >Have you deployed a SOAP bundle in the OSGi container? >(We're using a SOAP bundle provided by the Knopflerfish project, it runs >in the Equinox container). I've got an Axis2 bundle that we use for apache Muse. I'd like to try the Knoplerfish bundle. I'll pop out to their site and grab it. Thanks! >>dual classloader hierarchy' requirement >What exactly do you mean? Do we want to have different classloaders for >the bindings and the applications? >>The down side is that we lose the capacity to start and stop extension >>bundles, >Our understanding about fragments bundles is the following: >If OSGi bundle B has defined a 'Fragment-Host: bundle A', bundle A will >have one classloader which will be extended by bundle B's exported >classes as soon bundle B is started. As much we understood the OSGi >spec there's >only >one classloader in bundle A which holds all classes from bundle A as >well from it's fragment bundle B. How can this help to support the >'dual classloader hierarchy' >requirement for SCA applications? >Fragment bundles can be started and stopped independently from their >host bundle. >If you stop a fragment bundle, the host bundle must be refreshed (or >restarted) >to update the host's classloader. Why would we lose the capacity to >start/stop extension bundles? Well, in equinox, if you try to stop a fragment bundle you get: org.osgi.framework.BundleException: A fragment bundle cannot be stopped: [EMAIL PROTECTED]:file:../../../../workspaces/CORONA_SCA/tuscany-binding -osgi/ You can uninstall/re-install to you hearts content, and that will require a refresh. Perhaps this is an equinox problem? >>One of the major pains of porting existing extensions is the assumption >>about >>file locations. >I assume you're talking about the scdl files? Yup. And wsdls. And schema. ;-) >>For each bundle with an application composite (scdls under an "sca" >>folder), I create a Tuscany runtime using the extended system config, >>and run the application composite inside it. >If we understand you correctly, this would mean that we have for a >number of x SCA components, x Tuscany runtimes running in the OSGi >container? Yes. >We would prefer a solution where exactly one Tuscany runtime is running. >What about having a Tuscany runtime service in the OSGi container >deployed which scans a given directly for scdl.files (contained in the >JARs of the SCA application composites)? >For every scdl the defined components will be started in the Tuscany >runtime and services with OSGi binding will be registered automatically >in the OSGi registry. It seems like your requirement would be met by just deploying one big scdl for your application. My view of an OSGi host for Tuscany is somewhere between an app server (where Tuscany components would communicate over a remotable interface like WS) and a plain old SCA composite (where components are directly wired). By supporting multiple SCA applications in a single OSGi, you can provide a degree of isolation that isn't possible when dumping everything into a single SCA runtime. You'll have the ability to stop and restart portions of your SCA 'fabric'. Plus, you can provide fast inter-application communication using the OSGi service binding mechanism. I thought it was kind of nice! I really want to stay away from any type of scanning solution, as that seems antithetical to OSGi's philosophy. Of couse, I'm willing to be voted down! >>void doIt(BundleContext context){ >>String APP_FILTER = >>"(&((objectclass=org.apache.tuscany.sca.osgi.core.ApplicationContextSe r >>v >>ice)(Name="SupplyChainShipper)))"; >> ServiceReference[] refs = >>context.getServiceReferences("org.apache.tuscany.sca.osgi.core.Applica t >>i >>onContextService" >Is there really a need to register the ApplicationContextService is >OSGi? >I thought we could directly register the service interface provided by >the SCA component. Otherwise I do not understand how a standard OSGi service >is able to get the reference of the SCA service? If an SCA component is bound as an OSGi service, all you need to do is use the typical OSGi service registry code. If an SCA component isn't bound and an osgi service, but you want to interact with it from outside, the thought was that you could resolve the SCA context containing the desired component and invoke it directly. I'll send you my sample code. That might make it clearer. I'm trying (really!) to get this stuff back in sync so that I can give Jim another patch. Cheers, Joel The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
