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:string">amazon.com
</property>
</service>
</componentType>
<componentType>
<reference name="retailer1" >
<property name="retailerName" type="xsd:string">amazon.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
> 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
--
