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. Thank you... Regards, Rajini
