On Dec 11, 2007 2:23 PM, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > Hello, > > We are looking at implementing a reference implementation for > Distributed-OSGi based on SCA metadata using Tuscany. In the long term, > this > support is expected to be based on pure SCA dynamic wiring at the domain
Do you mean autowiring at the domain level when you say "pure SCA dynamic wiring"? > > level. But since this support requires changes to SCA to enable property > matching for wires, auto-promotion and domain-level autowiring which are What is auto promotion? > > being debated at the moment, we would like to propose a temporary solution > based on wiredByImpl where the wiring is done by implementation.osgi. > This is a tactical solution which will be eventually replaced by proper > SCA > wiring, and as far as possible, we will try to minimize SPI changes > required > to implement this. > > Here is an example of what we would like to get working for the SCA-based > reference implementation of RFC-119 (based on the example from RFC 119 for > Distributed-OSGi). > > > <composite ... targetNamespace="http://beer.org"; > name="BeerOrderComposite"> > > <component name="BeerOrderComponent"> > <tuscany:implementation.osgi bundleSymbolicName=" > org.beer.BeerOrderComponent" > > <properties reference="warehouse"> > <property name="location">London</property> > </properties> > </tuscany:implementation.osgi> > <service name="BeerOrderService" /> > <reference name="warehouse" wiredByImpl="true" > requires="authentication"> > <binding.ws/> > </reference> > </component> > > </composite> > <composite ... targetNamespace="http://beer.org"; > name="BeerWarehouseComposite"> > <component name="BeerWarehouseComponent"> > <tuscany:implementation.osgi bundleSymbolicName=" > org.beer.BeerWarehouseComponent"> > <properties service="BeerWarehouseService"> > <property name="location">London</property> > </properties> > </tuscany:implementation.osgi> > <service name="BeerWarehouseService" requires="authentication"> > <binding.ws/> > </service> > </component> > </composite> > > > The reference BeerOrderComponent/warehouse is autowired to > BeerWarehouseService when the BeerWarehouseComposite is contributed to the > domain. But rather than use domain level autowiring, we would like to > implement this initially by wiring this from implementation.osgi. The > reference is marked wiredByImpl to avoid SCA wiring. The wires are > recalculated by implementation.osgi whenever there are changes to matching > services for references marked wiredByImpl. > > wiredByImpl in implementation.osgi enables > > 1. Property matching for wires using OSGi properties which dont > currently have an equivalent in SCA > 2. Domain-level autowiring required for Distributed-OSGi, but still > being debated for SCA This debate seems to have dried up. I'll give it another kick. > > 3. The use of a RFC 119 compatible discovery service for OSGi services > which are outside of an SCA domain. This can be prototyped inside > implementation.osgi without impacting the rest of SCA. > 4. Rewireable proxies required for Distributed-OSGi can be prototyped > inside implementation.osgi > > > The implementation of wiredByImpl requires > > 1. implementation.osgi provider to be notified whenever matching > services for a wiredByImpl reference are added or removed from the SCA > domain. This could be done by the node by starting and stopping the > component. Ok that would fit into the way that references are currently notified of change. I.e. when a reference is wired in a composite is wired as a result of the domain changing the node running the composite is notified of the new composite and the changed reference is stopped, updated and restarted. > > 2. implementation.osgi needs to find a list of matching target > services in the domain. Since this matching includes > interface/binding/policy matching, it is best for Simon's > new DomainWireBuilder to do the matching. The code could then be reused > for > autowiring.The easiest way for implementation.osgi to obtain the list > of matching services would be using the target field of the reference. > So > the domain would fill in the list of matching services in the target > field, > and implementation.osgi would choose from the matching services taking > into account OSGi-specific properties. There is discussion on another thread about how precisely the domain model is built but none the less it is the responsibility of the domain to consider all of the reference and service pairs as candidates for wiring at the domain level. On this basis it would be straightforward to determine a list of candidate services for your wireByImpl process based on the usual process of matching interfaces, bindings and policies. The hard part is how to subsequently tell implementation.osgi about the list. It's certainly attractive to use the targets list but this may provide a model that is inconsistent with respect to the multiplicity defined on the reference. It's also the case that autowire at the composite level doesn't complete the targets list with the results of the autowire process so it would be inconsistent with that. I would like the target list to be completed in this case however so maybe that's not a show stopper. I'm wondering if we can go ahead and make enough of your demo work using domain level autowiring if we were to implement that. This wouldn't match on properties of course but would that be enough to show what you need to show or do you need to do the property matching now? > > > At the moment, the primary purpose of this work is to produce a > proof-of-concept SCA-based solution for Distributed-OSGi and in particular > to demonstrate that this solution will interoperate with non-SCA based > Distributed-OSGi software based on RFC 119. It will be our goal to > refactor > most of this into core Tuscany once the requirements are clearer. > > Suggestions? Objections? > > > Thank you... > > Regards, > > Rajini >
