On Dec 19, 2007 10:48 AM, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > Simon, > > I have opened a JIRA (https://issues.apache.org/jira/browse/TUSCANY-1940) > to > track this work. I will submit a patch which can be refined as the > requirements from Tuscany become clearer. wiredByImpl gives a temporary > solution which can be used to prototype Distributed-OSGi, and it can be > replaced later. The patch is not expected to be integrated until the final > > solution is agreed in the new year, and Graham will be following this up. > The only outstanding requirement I still have from Tuscany is access to > the > service component XML from implementation.osgi (which you described) to > set > properties for OSGi service proxies.
Ok, we need this piece of function too so I'll take a look when a bit of time. I would image that a method could be provided that takes a domain artifact URI (from the domain level composite down) and provides the XML for that SCA artifact, e.g. something like String getArtifactDefinition(String URI); The spec talks about getQNameDefinition which also takes a contribution URI as context and a symbol space to allow detailed information to be returned about an installed contribution. I exchanged notes with Raymond about this ( http://www.mail-archive.com/[email protected]/msg26069.html) but I'm still absolutely about the use case. Maybe we should take the first step and allow the SCA artifacts to be returned and worry about the rest of the contribution artifacts later as this first step would be relatively straightforward. > > > I agree that there needs to be more discussion around the level of > granularity of objects being started/stopped when changes are made to the > domain, though I can't see how restarting a component and its services and > restarting the scope as a result when it is not absolutely necessary can > be > right even for non-OSGi components. TUSCANY-1940 will add/remove wires > rather than restart components for implementation.osgi. I do understand > that > it may be too fine-grained and not the expected behaviour for other > component implementation types. When adding/removing wires do the proxies remain the same or do they have to be reinjected? > > > Thank you... > > Regards, > > Rajini > > > On 12/18/07, Simon Laws <[EMAIL PROTECTED] > wrote: > > > > 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 > > > > > > > > > > > > > > >
