On 8/14/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Comments inline. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Simon Laws" <[EMAIL PROTECTED]> > To: "tuscany-dev" <[email protected]> > Sent: Tuesday, August 14, 2007 12:37 AM > Subject: Late resolution of reference targets - was:Accessing global > domain > information > > > > Currently in CompositeWireBuilderImpl.connectComponentReference all > > targets > > are converted to bindings on a reference and the targets are > > removed. During this process the source and target bindings are compared > > until matching wireable bindings are found. > > > > This is not always possible because some of the targets are not resolvable > at this point.
Precisely:-) > Currently only the sca binding implements WireableBinding. I've opened > > https://issues.apache.org/jira/browse/TUSCANY-1534 about this. > > > > If the domain is distributed then at the build stage some of the targets > > will remain unresolved. For the new sca binding I have made the > assumption > > here that unresolved targets take a copy of the bindings they may be > > resolved against at a later date and that the targets are maintained on > > the > > reference after the build stage. I still assume that the SCA binding is > > the > > only valid wireable binding at present. > > > > I start to look into this area too from a different perspetive. Please see > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References. Cool. Let me think about this a little and I'll add notes. I know Simon N did some work in this are recently and there have been a thread about cross JVM lookups recently specifically focusing on service references/callable references. So there are a few interested parties. > So I'm proposing that > > > > 1. The builder should retain the list of unresolved targets for use > after > > the build stage > > 2. The list of bindings that might be used to resolve a target at a > later > > date are associated with each target > > > > +1. What will the data structure look like? There are some cases that > mixed > styles are used to define the binding endpoint if the reference > multiplicity > is greater than 1 and promotion is used. For example, we can have the > following: > > InnerComposite: > <composite name="InnerComposite" ..> > <component name="C1 ...> > <reference name="myRef" target="C2/S1 C3/S1"> > <binding.sca/> > <binding.x/> > </reference> > </component> > > <component name="C2 ...> > ... > </component> > > <component name="C3 ...> > ... > </component> > > <reference name="myOuterRef" promote="C1/myRef"> > <binding.y> > </reference> > </composite> > > <composite name="OuterComposite" ...> > <component name="C4" implementation.composite="ns1:InnerComposite"> > <reference name="myOuterRef" target="C5/S1"/> > </component> > ... > <component name="C5 ...> > ... > </component> > </composite> > > Then the effective wires for myRef will be: > > C2/S1 (binding.sca/binidng.x), C3/S1 (binding.sca/binding.x), C5/S1 > (binidng.y) Do you know off the top of your head where the bindings for the promoted reference live in the model before build time? At build time do they get resolved back into the original reference bindings list? > Come wire creation time care must be take to create remote wires for > > unresolved targets. What I do at the moment is: > > > > CompositeActivatorImpl.addReferenceBindingProviders > > As before, create providers for all bindings that represent > > resolved > > targets > > > > For all unresolved targets > > If support is enabled create a cloned SCA binding and add it > to > > the reference binding list (so that a wire will be created). > > This is pretty much what goes on in the > > CompositeWireBuilder > > but I've delayed it until here in the expectation that we will do remote > > binding matching one wireable support is fixed > > Create an SCA binding provider which will look up the remote > > endpoint at start() time. > > > > Thoughts? > > > > Regards > > > > Simon > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
