On Dec 12, 2007 1:34 PM, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > Simon, > > Comments inline... > > Thank you... > > Regards, > > Rajini > > > On 12/12/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > 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"? > > > Yes, I meant domain-level autowiring with no OSGi specific wiring code. > implementation.osgi might still be used to interact with the > Distributed-OSGi discovery service, but the services or reference targets > discovered will be contributed to the SCA domain, and the wiring will be > done at the domain-level without further involvement from > implementation.osgi (this does require support for property matching in > SCA).
Ok, sounds like the right thing to do. If we can avoid writing specific code for specific bindings then that seems good to me. We don't have property matching yet though. > > > > > > > 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? > > > When a component reference target is resolved outside of the SCA domain > using an OSGi discovery service, a domain-level reference that promotes > the > component reference is added to represent this in the domain. Can other > references which match the remote service then be promoted to this > domain-level reference, in the same way as autowiring would wire to a > service? Is this part of the process driven by OSGi and are these references ever used outside of OSGi. I guess I'm still struggling a bit with the scenario in this particular case as I don't see what value SCA is adding. Unless you are saying that these discovered service must be available for use by any SCA reference. > > > > > > > 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. > > > At some point, I would like to understand better how disruptive this > process > is. Does a proxy need to wait/retry when a wiring is being altered? OSGi > applications can use service trackers to be notified of services being > registered and unregistered. We are hoping that the SCA proxies will > enable > rewiring without requiring any application involvement, but I am not > entirely sure if that is true at the moment. There is a fundamental question about how dynamic running SCA applications should be in terms of taking note of any changes that may occur in the domain. There is a continuum from "not at all" through to "must be able to update a single artifact in the SCA model". I'm not sure what the final answer will be on this and it needs a separate thread. However I can say that the proxies don't currently support rewiring unless you at least stop and start the component having reset the reference bindings in between. If we want to add finer granularity of control we will have to dive in and fix up the logic in and around the composite activator and the assembly builders. I think we should refrain from making any changed here until we have had the higher level discussion about what the more generally the right answer to maintaining the SCA domain. > > > > > > > > > 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? > > > We dont need property matching to start with, but it would be good to have > somewhere to insert the matching later on. The implementation of > domain-level autowiring where the targets are chosen by SCA, and > wiredByImpl > where the matching candidates are chosen by SCA, but the final target is > chosen by OSGi (implementation.osgi) should be mostly common code. At the > moment, I think wiredByImpl gives us maximum flexibility to build a > prototype without impacting the rest of Tuscany since wiredByImpl is not > used in Tuscany. To get properties we will have to provide a facility on the domain to allow the details of named artifacts to be retrieved. In fact the assembly spec calls for such a feature "getQnameDefinition" but it's not implemented yet. We need to add something like this in. > > > > > > > > > > > > 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 > > > > > >
