On 8/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Raymond Feng wrote:
> > Comments inline.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message ----- From: "Simon Laws"
> > <[EMAIL PROTECTED]>
> > To: "tuscany-dev" <tuscany-dev@ws.apache.org>
> > 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.
> >
> >> 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.
> >
> >
> >> 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)
> >
> >
> >> 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
> >>
> >
>
> Sorry, but I'm having trouble understanding all this, it's starting to
> get a little complicated for me... Could somebody please give a *short*
> summary of the scenario that this is attempting to cover? Thanks.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Raymond is coming at the problem from a different direction to me so I'll
let him give examples. For me the scenario is
<composite ... name="HelloWorld">
<component name="HelloWorldClient">
<implementation.java class="HelloWorldClient" />
<reference name="helloWorldService" target="HelloWorldService" />
</component>
</composite>
Where HelloWorldService does not appear in the loaded contributions.
Simon
