On 6/11/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:
Hello,
I am working on an OSGi implementation type for Tuscany, and would like to
figure out the best way of mapping properties of OSGi services onto SCA.
This is specifically an issue in the bottom-up scenario where existing
OSGi
bundles are assembled using SCA (In the top-down scenario where SCA is in
charge, services will be looked up using component and service names
rather
than OSGi properties).
In OSGi, services are registered in the OSGi registry with a set of
properties.
BundleContext.registerService(java.lang.String clazz,
java.lang.Object service,
java.util.Dictionary properties);
The service is looked up from the OSGi registry using a property filter.
BundleContext.getServiceReferences(java.lang.String clazz,
java.lang.String filter);
In SCA, since properties are currently associated only with components
rather than services or references, there is no easy way to specify the
properties required to register or lookup OSGi services.
As an example, I would like to specify a property named retailerName for
the
retailer service in the supplychain sample. The sample uses a customer
component with a reference to a retailer component.
Scenario 1: Customer is an OSGi component and the Retailer is a Java
component. An existing OSGi customer bundle uses the retailer name as the
filter to lookup the retailer service. A proxy service is registered for
the
Java component by the Tuscany OSGi implementation provider, and this
service
needs to be registered with the properties that the referring OSGi
component
uses to lookup the service. Hence we need a way to specify properties in
the
component reference definition.
Scenario 2: Customer and Retailer are OSGi components. If there are
multiple
retailer services in the composite with different properties, the Tuscany
OSGi implementation provider registers a proxy service (with maximum
ranking) with the service properties specified to guarantee the wiring
specified in the SCA composite. In this case the proxy service needs to be
registered with the properties of the original OSGi service to ensure that
OSGi references to the service use the proxy. Hence we need a way to
specify
properties in the component service definition.
The possible options for adding this information to the SCA composite are:
1. Add property definitions to ComponentService and ComponentReference.
These will need to be processed by the Tuscany core and made available in
some format through the interfaces for ComponentService and
ComponentReference. Having the service and reference properties in an
identical format should simplify both the implementation and the use of
properties. This is slightly different from OSGi declarative services
where
service properties are specified in a property element, and reference
properties are specified as a filter - eg. target="(retailerName=
amazon.com)"
.
<service name="RetailerService">
<property name="retailerName" type="xsd:string">amazon.com</property>
</service>
<reference name="retailer1" target="RetailerComponent1">
<property name="retailerName" type="xsd:string">amazon.com</property>
</reference>
This option ensures that these additional OSGi-related properties are only
specified for components using OSGi implementation type.
2. Specify properties only in the service, and not in the reference. Use
the
target service to determine the properties of the reference. This reduces
the amount of information that needs to be added when both source and
target
are OSGi components. But it requires service properties to be specified in
non-OSGi components (eg. when Retailer is a Java component, it needs to
specify service properties for the RetailerService if there are OSGi
references to the service).
3. Specify reference properties in the target URI.
eg. <reference name="retailer1"
target="RetailerComponent1/RetailerService?retailerName=amazon.com" />
This simplifies the reference definition, but the code which parses the
target is common code in Tuscany, and OSGi specific URI properties will
need
to be handled in the common code. Since service name in the <service/>
element is not an URI, service properties will have to be specified in a
different format.
4. Specify properties as attributes to the reference and service elements.
eg. <reference name="retailer1" target="RetailerComponent1"
retailerName="amazon.com" />
This simplifies the parsing of properties, but restricts the names of
properties (eg. Cannot have a property "name" since that refers to the
reference name).
I look forward to any feedback on the best way to proceed.
Seems like quite a big thing to be changing the Tuscany core code for this
so would it be possible to get it working without any changes outside of the
OSGi implementation SCDL? For example with Scenario 1 something like provide
a list of properties within the implementation.osgi element that are
associated with the reference (i.e the properties name attribute is the same
as the reference name attribute):
<component name="CustomerComponent">
<implementation.osgi serviceName="OSGICustomerService">
<properties name=retailer>
<property name="retailerName>amazon.com</property>
</properties>
</implementation.osgi>
<reference name="retailer" target="RetailerComponent" />
</component>
...ant
