Hi Graham, I'm still not sure if the proposal is consistent.
Let my explain my concerns: Every OSGi container provides an OSGi registry. In the OSGi enterprise expert group we are currently discussing that proxies for other services (e.g. EJB stateless Bean which is accessible via IIOP) will be created and registered in the OSGi registry. >From this point of view, your proposal for the implementation.osgi is consistent. But do we want to have different behaviour for different SCA implementations types? Do you expect for example that an implementation.ejb adds remote proxies to the JNDI service? Or what about implementation.net or implementation.c, do we need now a registry for all implementation types? I still think that explicit bindings are better. What do the others on the list think? Thanks Nicole P.S.: Graham, Tim told me today that you are going to be at the F2F in Munich next week. Looking forward to meeting you there :-) -----Ursprüngliche Nachricht----- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Juni 2007 17:10 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole, My turn to chip in :-) I think both approaches are valid and tackle two different goals. If I understand correctly, then the binding approach does not hand the responsibility for the OSGi bundles and services to SCA. So this is more of a peer-to-peer runtime view. I think this approach is appealing if you want to keep OSGi outside the SCA domain for either organizational reasons, or because you don't want to model some existing OSGi application in SCA. The implementation.osgi approach is trying to take an SCA assembly view of the problem where you want to describe and manage the assembly of the OSGi assets with other implementation technologies. Here SCA is responsible for managing the OSGi bundles (installation, activation), and ensuring their external dependencies are resolved. I've inlined some additional comments below. On 19/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: > Hi Rajini, > > I would prefer a solution where you declare explicitly the bindings, not an > implicit registration > of services. > > Please find below a snippet of the OSGi prototype provided by Joel some time > ago: > > <service name="RetailerService" target="RetailerComponent"> > <interface.java > interface="test.sca.osgi.binding.supplychain.Retailer"/> > <osgi:binding.osgi > service="test.sca.osgi.binding.supplychain.Retailer"/> > <reference>RetailerComponent</reference> > </service> > > <component name="RetailerComponent"> > <implementation.java > class="test.sca.osgi.binding.retailer_warehouse.impl.RetailerComponentImpl"/> > <reference name="warehouse" > target="WarehouseComponent">WarehouseComponent</reference> > </component> > > RetailerComponent will not be registered automatically (without a service). > The Service tag provides the > information via which binding the RetailerComponent will be accessible, in > this case via an OSGi Binding. > The SCA runtime detects the OSGi binding and registers the RetailerComponent > as OSGi service in the > OSGi registry. > > The Client uses a reference with OSGi binding to access the RetailerService: > <component name="CustomerComponent"> > <implementation.java > class="test.sca.osgi.binding.client.impl.CustomerComponentImpl"/> > <reference name="retailer" > target="RetailerService">RetailerService</reference> > </component> > > <reference name="RetailerService" override="may" multiplicity="0..n" > target="Nothing"> > <interface.java > interface="test.sca.osgi.binding.supplychain.Retailer"/> > <osgi:binding.osgi > service="test.sca.osgi.binding.supplychain.Retailer" > filter="(objectclass=test.sca.osgi.binding.supplychain.Retailer)" > immediate="false"/> > </reference> > > In this case the SCA runtime looks up the Retailer OSGi service in the > registry and injects it into > the CustomerComponent which is the client. > > From my point of view we need such an OSGi Binding for the communication of > SCA components running in > different implementation types. If we have only an OSGi implementation type I > would use instead of an OSGi > binding the OSGI R4 DS (Declarative Services) or Spring OSGi. > Both approaches allow OSGi bundles to talk to SCA components built using different implementation types. For the binding approach it's whatever the service with the OSGi binding is wired to in SCA. For the implementation.osgi approach, it's whatever the component reference is wired to. The runtime needs to make good on this relationship. So, an SCA component with an implementation type of OSGi can be directly wired to an SCA component with an implementation of Java, or BPEL, etc... > Questions/Remarks to you proposal: > >A proxy service is registered in the OSGi registry for the Retailer by the > >Tuscany OSGi implementation provider when CustomerComponent is processed. > From my point of view the provider (in this case Retailer) should decide how > it is > accessible, not the client. What happens if Retailer is not declared in the > same composite? > Are you going to search for matching components in the complete SCA domain? > I think this is another example of the two different scenarios. If you're an assembler who is assembling components which happen to be implemented using different technologies, then the implementation.osgi is appropriate. If, however, you're an assembler trying to integrate an SCA domain with OSGi assets outside your domain, then the binding is appropriate. It should not matter where the Retailer is declared. As long as they are in the same SCA domain, then the wiring will be respected. The wire can result in a remote communication between two components, without the need for a binding (provided the interface is remotable). > >The Customer bundle will lookup the OSGi registry for the retailer as if it > >were a normal OSGi service. > What about dependency injection? Will it also be supported? > Yes, dependency injection for declarative services is supported. > Looking forward to discussing these topics further with you :-) > > Best regards > Nicole > -----Ursprüngliche Nachricht----- > Von: Rajini Sivaram [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. Juni 2007 10:04 > An: tuscany-dev@ws.apache.org > Betreff: Re: Contribute to SCA-OSGi integration > > Nicole, > > Here is an example scenario, taken from the supplychain sample in Tuscany. > Customer and Warehouse are OSGi bundles, Retailer has a Java implementation. > A proxy service is registered in the OSGi registry for the Retailer by the > Tuscany OSGi implementation provider when CustomerComponent is processed. > The Customer bundle will lookup the OSGi registry for the retailer as if it > were a normal OSGi service. The Retailer Java component has its warehouse > reference injected by Tuscany with an instance of the Warehouse, which is > registered by the Warehouse bundle and looked up by the Tuscany OSGi > implementation provider in the OSGi registry. > > <component name="CustomerComponent" > <implementation.osgi > bundle="Customer" > bundleLocation="file:target/Customer.jar" /> > > <reference name="retailer" target="RetailerComponent"/> > </component> > > <component name="RetailerComponent"> > <implementation.java class=" > supplychain.retailer.JavaRetailerComponentImpl" /> > <reference name="warehouse" target="WarehouseComponent"/> > </component> > > <component name="WarehouseComponent"> > <implementation.osgi > bundle="Warehouse" > bundleLocation="file:target/Warehouse.jar" > /> > <reference name="shipper" target="ShipperComponent" /> > </component> > > > > Thank you... > > Regards, > > Rajini > On 6/19/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: > > > > Hi Graham, > > > > >OSGi SCA Component -- local wire --> non-OSGi SCA Component (e.g. POJO) > > I'm still not sure if I understand your scenario correctly. What do you > > mean with > > non-OSGi SCA Component, where will it be declared? My understanding is > > that the non-OSGi > > SCA Component will be deployed in another implementation type, e.g. in > > Java or Spring > > implementation type. To be able to wire the OSGi SCA Component with the > > non-OSGi SCA > > component you will need a binding. The other scenario I could imagine is > > that you are > > talking about a simple POJO or Spring Bean which will be injected via > > Dependency Injection, > > e.g. in the Spring implementation type or in the OSGi implementation type > > with Spring-OSGi > > support. Could you please describe what you have in mind, e.g. where you > > are planning to > > declare the non-OSGi SCA Component? > > > > Thanks > > Nicole > > > > > > -----Ursprüngliche Nachricht----- > > Von: Graham Charters [mailto:[EMAIL PROTECTED] > > Gesendet: Mittwoch, 13. Juni 2007 10:07 > > An: tuscany-dev@ws.apache.org > > Betreff: Re: Contribute to SCA-OSGi integration > > > > Hi Nicole/Rajini, > > > > I'm wondering if there is some confusion over terminology and the > > scenarios being discussed. I believe Rajini is only referring to OSGi > > bundles integrated into SCA through an <implementation.osgi />. So in > > these scenarios both components are SCA components. Perhaps for > > clarity we should refer to the ones implemented using OSGi bundles as > > OSGi SCA components. > > > > So, for scenario 1, I think we have: > > > > OSGi SCA Component -- local wire --> non-OSGi SCA Component (e.g. POJO) > > > > In this scenario the OSGi SCA Component implementation will look up > > and expect to find a service in the OSGi Registry. The SCA wiring > > states that that service is provided by the non-OSGi SCA Component and > > therefore Tuscany must register a proxy service (a proxy to the > > non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component > > implementation will be unaware that it is calling a non-OSGi SCA > > Component. > > > > For scenarios 2, I think we have: > > > > non-OSGi SCA Component (e.g. POJO) -- local wire --> OSGi SCA Component > > > > In this scenario, Tuscany knows that the target component is > > implemented by an OSGi bundle and it must look-up the target service > > in the OSGi Registry. > > > > Of course, it could easily be me that's confused, but I don't see > > where bindings come into these scenarios. I do think it would be good > > to expand the scenarios to include bindings thoughts, and perhaps, > > Nicole, you could elaborate on the scenarios you describe. For > > example, I'm not sure the OSGi components you refer to are SCA. I > > think you may be thinking of more a peer-to-peer view of OSGi and SCA. > > > > Regards, > > > > Graham. > > > > On 12/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: > > > Hi Rajini, > > > > > > good to hear that you're going to contribute to SCA-OSGi :-) > > > > > > We wrote a paper about the different possibilities of combining OSGi and > > > SCA for the SCA drumbeat end of march. You can find it on the OSOA > > > homepage: > > > http://www.osoa.org/display/Main/SCA+Resources. > > > The paper contains a high level description of the OSGi Binding, > > > implementation type > > > and OSGi host. Would be great to get some comments from you. > > > > > > >If there are references from the OSGi component to other non-OSGi SCA > > > >components, a proxy service is registered by the Tuscany runtime with > > > the > > > >OSGi registry so that the OSGi bundles can access these SCA services as > > > >normal OSGi services. > > > Well, this is one option, but not the only one. If for example the > > > non-OSGi SCA component > > > provides a SOAP service binding, a SOAP proxy will be injected. > > > > > > >References from non-OSGi components to OSGi components > > > >are resolved by looking up the OSGi registry. > > > Yes, if the non-OSGi SCA component has declared a reference with OSGi > > > binding. > > > If the OSGi component has declared a JMS service binding, the non-OSGi > > > SCA component > > > could use JMS instead of OSGi binding :-) > > > > > > Best regards > > > Nicole > > > > > > > > > > >Hello, > > > > > > > > >I would like to contribute to the SCA<->OSGi integration activities. > > > > > > > > >I have been looking at the existing OSGi binding implementation in > > > > Tuscany > > > > >which exposes SCA services as OSGi services. Even though this binding > > > > is no > > > > >longer working with the latest Tuscany builds, the samples were very > > > > useful > > > > >to understand the scenarios. I was also looking at the notes on the > > > > mailing > > > > >list (they are slightly old - dated Nov 2006) which talk about an > > > > OSGi host > > > > >and also an OSGi implementation type. Is there any ongoing work in > > > > these > > > > >areas? > > > > > > > > >Graham Charters and I have been investigating the use of an OSGi > > > > >implementation type which will enable existing OSGi bundles to be run > > > > as SCA > > > > >components under Tuscany. We are particulary interested in the > > > > scenario > > > > >where Tuscany is in control. If components of OSGi implementation > > > > type are > > > > >specified in the composite, Tuscany starts up an OSGi runtime and > > > > deploys > > > > >the OSGi bundles corresponding to the components into the OSGi > > > > runtime. If > > > > >there are references from the OSGi component to other non-OSGi SCA > > > > >components, a proxy service is registered by the Tuscany runtime with > > > > the > > > > >OSGi registry so that the OSGi bundles can access these SCA services > > > > as > > > > >normal OSGi services. References from non-OSGi components to OSGi > > > > components > > > > >are resolved by looking up the OSGi registry. > > > > > > > > >We would like to obtain feedback on using this approach and also > > > > would like > > > > >to get involved in the ongoing support for SCA<->OSGi integration. > > > > > > > > >Thank you... > > > > > > > > > > > > >Regards, > > > > > > > > >Rajini > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
