Re: Late resolution of reference targets - was:Accessing global domain information
On 8/15/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > 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" > > > 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: > > > > > > > > > > > > > > > > > > > > > > > > > > >... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >... > > > > > > > > > > Where HelloWorldService does not appear in the loaded contributions. > > Simon > Hi, as an alternative to this is there a way that we can just create all the bindings/wires for the unresolved targets and then select the correct wire either when the invocation handler is created or even as late as when the first call is made through a reference. I've been thinking about this because it is clear that we don't know how long in the future it will be before a target is available to be resolved. In this case of references that cross node boundaries it can be any time from when the composite is loaded through to the point a which the first call is made, i.e. we don;t want to prevent the composite from starting up. Regards Simon
Re: Late resolution of reference targets - was:Accessing global domain information
On 8/14/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Comments inline. > > Thanks, > Raymond > > - Original Message - > From: "Simon Laws" <[EMAIL PROTECTED]> > To: "tuscany-dev" > 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: > > > > > > > > > ... > > > > > > > > > > > > ... >
Re: Late resolution of reference targets - was:Accessing global domain information
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" > > 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: > > > > > > > > > > > > > > > > > >... > > > > > > > > > > > > > > > > > > > > > > > >... > > Where HelloWorldService does not appear in the loaded contributions. Simon
Re: Late resolution of reference targets - was:Accessing global domain information
Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" 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: ... ... 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]
Re: Late resolution of reference targets - was:Accessing global domain information
Comments inline. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" 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: ... ... 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]
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. 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. 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 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
