Re: Reference and Service properties for SCA-OSGi implementation
Ant, We will implement this as part of implementation.osgi/ for now, so that Tuscany core doesn't have to be modified before OSGi implementation code is committed. So both service and reference properties will be specified in the implementation.osgi/ element as you described. Graham and I were discussing this today, and we are not convinced that OSGi service and reference properties really belong to implementation.osgi/. The right place for these properties is really the component type file since these properties describe the implementation rather than a configured instance of the implementation (ie. component). Once coded in an OSGi implementation, these properties are no longer configurable without modifying the OSGi bundle. When there are multiple uses of an implementation, specifying the implementation properties in the component will result in duplicating the information. Since the component type file describes an implementation, there should really be some way for additional attributes or elements specific to the type of implementation to be added to the component type file. At the moment, we have only come across properties, but there may be other implementation-specific information which belong to the component type file which come up in future. Ideally we would like to specify the OSGi service and reference properties the service/ and reference/ elements in the component type file, and have the OSGi implementation processor process this somehow: componentType service name=RetailerService property name=retailerName type=xsd:stringamazon.com /property /service /componentType componentType reference name=retailer1 property name=retailerName type=xsd:stringamazon.com /property /reference /componentType Presumably this cannot be done using the SCA specification as it stands. But I would appreciate any feedback on whether other implementations have had similar requirements in the past and whether this is a sensible approach for the future (especially if we encounter more implementation-specific information which refer to an implementation rather than its configured instance). Thank you... Regards, Rajini On 6/11/07, ant elder [EMAIL PROTECTED] wrote: 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
Reference and Service properties for SCA-OSGi implementation
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:stringamazon.com/property /service reference name=retailer1 target=RetailerComponent1 property name=retailerName type=xsd:stringamazon.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
Re: Reference and Service properties for SCA-OSGi implementation
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:stringamazon.com/property /service reference name=retailer1 target=RetailerComponent1 property name=retailerName type=xsd:stringamazon.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
