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]
