[TUSCANY-1940] Dynamic Wiring for implementation.osgi

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: Java-SCA-1.x
• Component/s: Java SCA OSGi Integration
• Patch Info: Patch Available
• Assignee: Unassigned
• Reporter: Rajini Sivaram
• Created: 19/Dec/07 09:59
• Updated: 17/Apr/10 21:20
• Resolved: 17/Apr/10 21:20

Description

This is a placeholder for the work required to support Distributed-OSGi using SCA metadata and the Tuscany runtime. This is not expected to be committed into Tuscany until the changes are discussed and finalized on the mailing list. Graham Charters will be following this up in the new year.

The attached patch supports the following scenarios (based on the BeerOrder example from RFC 119 for Distributed-OSGi):

<component name="BeerOrderComponent">
<implementation.osgi..../>
<reference name="warehouse" wiredByImpl="true" requires="integrity">
</component>

1) There are two Warehouse Services in the SCA domain. Proxies to both services are installed by Tuscany in the OSGi registry. One of the services is chosen by OSGi for BeerOrderComponent/warehouse. At the moment, OSGi properties of the service are not set on the proxy, but this will be added once the component description of the service component can be obtained from the SCA domain. Property matching will be done by OSGi.
2) The warehouse service that the BeerOrderComponent is wired to is removed from the SCA domain. The proxy corresponding to that warehouse service is removed from the OSGi registry. OSGi service listener will be used by the application to rewire to the other warehouse service.
3) The second warehouse service is also removed from the SCA domain. The second proxy is removed, and the OSGi application's service listener is notified. Any attempt to use cached proxies will throw an exception.
4) A new warehouse service is added to the SCA domain. A new proxy is installed in the OSGi registry, and the application's service listener can wire to this service.
5) Another warehouse service is added to the SCA domain. Another proxy is installed in the OSGi registry, and the application is notified. But the proxy to the previously installed service can be used without any disruption.

The changes to the Tuscany runtime to support these scenarios:
1) For references marked wiredByImpl inside a component using implementation.osgi, the implementation.osgi provider is notified whenever a matching service becomes available or unavailable. Proxies are registered/unregistered into the OSGi registry by implementation.osgi. Matching of interfaces/intents/policies is done by Tuscany, property matching using OSGi filters is done by OSGi. OSGi applications will be notified when matching services are available/removed.
2) If a service being used by an OSGi reference becomes unavailable, the OSGi application will be notified (as long the SCA domain knows about the change). It is upto the application to wire to a different service. implementation.osgi registers/unregisters all matching services for references in the service registry whenever the domain is updated. The rest is handled by OSGi. For OSGi procedural services, services provided by the bundle will not be affected if references are not satisfied. For OSGi declarative services, the component will be deactivated by OSGi if mandatory references are not satisfied.
3) If an additional matching service becomes available, references to other services should work without exception. And there should be no impact on services provided by the component. The bundle should not be restarted. Tuscany will add new wires to the new service, but the wires to previously installed services will not be modified. This is different from the way non-OSGi components are handled, where changes to domain cause whole components to be restarted (causing disruption as well as restarting the scope).