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.
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?
>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?
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]
