Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Simon Laws wrote: On Sat, May 3, 2008 at 11:10 PM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: Jean-Sebastien Delfino wrote: Anyhow if this code is doing what I think it's doing then maybe we should move it to be a little earlier in the process and more general than the sca binding. We could take the checking code you have here and put it a little higher up where the reference targets are identified. If you are able to check a test in the I could have a look at this if you like. OK, I'll post here as soon as the test is in. Thanks. It's in now, I've added tutorial/store-client (a client for store-supplier) and tutorial/store-test. Store-test starts the domain manager, the catalogs, store-supplier and store-client nodes, then looks up the client service and invokes it. The client service orders 5 oranges puts them in the shopping cart, the test then checks that the total prices is as expected. The test looks pretty simple but actually exercises a lot of the SCA domain, node, distributed wiring and configuration logic, Java components with a Derby database integration as well as a mix of the WebService, SCA-local and Atom bindings. Hope this helps. -- Jean-Sebastien Thanks for doing that Sebastien. In order to make this retrieval of the target name from the binding URI a little neater and to move a little closer toward a more coherent solution for this I'd like to make some more changes in conjunction with this... Currently the builders are responsible for reconstructing the reference binding list using some hidden (Target) structures and logic. In the fullness of time it feels like we need some endpoint structure to bring together target names and candidate bindings. I think we can move toward this by extending the solution discussed previously on this thread along the following lines. Instead of relying on the default SCA binding for late resolution processing create a new binding called Endpoint (in the future I would expect that this ceases to be derived from Binding but for now if we create it based on binding we can increment toward a more complete solution). The endpoint implementation clases would be replaceable in the same way that any other binding is replaceable. An Endpoint would be created by the builder code in the following situations User specified reference target name User specified target name in binding uri Autowire target identified Wire by impl is set on a reference The endpoint is given the same information as is kept in various places in unresolved reference bindings today, for example, target name candidate bindings target service chosen binding The endpoint is responsible for performing reference target resolution, i.e. make a resolver that has access to the builder code that does service/binding matching. We then plumb the binding that results from this resolution back into the current binding list so nothing that happens today changes. If the endpoint remains unresolved though it has the access to the same resolution functions at a later date and the Endpoint provider will be able to kick in at start () or message send to perform the resolution step. Another thought is that we still have the OptimizableBinding interface that some bindings implement. Previously I had been looking for an excuse to remove this as I don't know what it's for. Having looked at this area a bit now though it does seem useful in the case where the candidate binding itself wants to get involved in the resolution process. So maybe OptimizableBinding is not the right name for it (why is it called this?) but it does seem to have value. Simon I agree that we need an Endpoint model object. The most obvious requirement for this is references with multiplicity, where we have one binding for several target (endpoints). If we introduce such an Endpoint model, I'd prefer to do a clean cut: - add that model - populate it - define new Provider SPIs that take an endpoint instead of a binding as IMO morphing Binding into an Endpoint is just going to create more confusion in an area that's already not so clear. The two sets of SPIs could co-exist for a while with BindingProviders working with bindings and ServiceProviders (I just made up that name) with service endpoints. -- Jean-Sebastien
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Sat, May 3, 2008 at 11:10 PM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Jean-Sebastien Delfino wrote: > >> Anyhow if this code is doing what I think it's doing then maybe we should >>> move it to be a little earlier in the process and more general than the >>> sca >>> binding. We could take the checking code you have here and put it a >>> little >>> higher up where the reference targets are identified. If you are able to >>> check a test in the I could have a look at this if you like. >>> >>> >> OK, I'll post here as soon as the test is in. Thanks. >> >> > It's in now, I've added tutorial/store-client (a client for store-supplier) > and tutorial/store-test. > > Store-test starts the domain manager, the catalogs, store-supplier and > store-client nodes, then looks up the client service and invokes it. The > client service orders 5 oranges puts them in the shopping cart, the test > then checks that the total prices is as expected. > > The test looks pretty simple but actually exercises a lot of the SCA > domain, node, distributed wiring and configuration logic, Java components > with a Derby database integration as well as a mix of the WebService, > SCA-local and Atom bindings. > > Hope this helps. > -- > Jean-Sebastien > Thanks for doing that Sebastien. In order to make this retrieval of the target name from the binding URI a little neater and to move a little closer toward a more coherent solution for this I'd like to make some more changes in conjunction with this... Currently the builders are responsible for reconstructing the reference binding list using some hidden (Target) structures and logic. In the fullness of time it feels like we need some endpoint structure to bring together target names and candidate bindings. I think we can move toward this by extending the solution discussed previously on this thread along the following lines. Instead of relying on the default SCA binding for late resolution processing create a new binding called Endpoint (in the future I would expect that this ceases to be derived from Binding but for now if we create it based on binding we can increment toward a more complete solution). The endpoint implementation clases would be replaceable in the same way that any other binding is replaceable. An Endpoint would be created by the builder code in the following situations User specified reference target name User specified target name in binding uri Autowire target identified Wire by impl is set on a reference The endpoint is given the same information as is kept in various places in unresolved reference bindings today, for example, target name candidate bindings target service chosen binding The endpoint is responsible for performing reference target resolution, i.e. make a resolver that has access to the builder code that does service/binding matching. We then plumb the binding that results from this resolution back into the current binding list so nothing that happens today changes. If the endpoint remains unresolved though it has the access to the same resolution functions at a later date and the Endpoint provider will be able to kick in at start () or message send to perform the resolution step. Another thought is that we still have the OptimizableBinding interface that some bindings implement. Previously I had been looking for an excuse to remove this as I don't know what it's for. Having looked at this area a bit now though it does seem useful in the case where the candidate binding itself wants to get involved in the resolution process. So maybe OptimizableBinding is not the right name for it (why is it called this?) but it does seem to have value. Simon
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Jean-Sebastien Delfino wrote: Anyhow if this code is doing what I think it's doing then maybe we should move it to be a little earlier in the process and more general than the sca binding. We could take the checking code you have here and put it a little higher up where the reference targets are identified. If you are able to check a test in the I could have a look at this if you like. OK, I'll post here as soon as the test is in. Thanks. It's in now, I've added tutorial/store-client (a client for store-supplier) and tutorial/store-test. Store-test starts the domain manager, the catalogs, store-supplier and store-client nodes, then looks up the client service and invokes it. The client service orders 5 oranges puts them in the shopping cart, the test then checks that the total prices is as expected. The test looks pretty simple but actually exercises a lot of the SCA domain, node, distributed wiring and configuration logic, Java components with a Derby database integration as well as a mix of the WebService, SCA-local and Atom bindings. Hope this helps. -- Jean-Sebastien
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Simon Laws wrote: Was just looking at the checkin. Thanks for making the fix. Now we don't generate invalid composite files when they get written out. Re. the second part dealing with URIs. It looks to me like this is picking up the case where the URI has been specified as the name of the target service. A feature which the spec call for. I have to admit that I can't recall a test for this now you mention it but are you saying this used to work at some point. I'd be a little surprised if we hadn't implemented that. But maybe I'm wrong. My understanding is that the implementation was missing and there was no test for it :) Anyhow if this code is doing what I think it's doing then maybe we should move it to be a little earlier in the process and more general than the sca binding. We could take the checking code you have here and put it a little higher up where the reference targets are identified. If you are able to check a test in the I could have a look at this if you like. OK, I'll post here as soon as the test is in. Thanks. Simon -- Jean-Sebastien
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Thu, May 1, 2008 at 8:27 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Simon Laws wrote: > > > On Tue, Apr 22, 2008 at 10:42 PM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> wrote: > > > > Simon Laws wrote: > > > > > > On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws < > > > > [EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > > > I agree with Simon's emphases on the point of view. I understand > > > > > > > > > > > Tuscany may prefer one solution over the other. However from > > > > > > extensibility perspective, there need some extension points to > > > > > > enable > > > > > > Tuscany adapters to overwrite the default behavior. I think the > > > > > > thread > > > > > > discussion on reference target and the comparing of 1 and 2 > > > > > > showcase > > > > > > one of the extensibility area : how to resolve reference target > > > > > > for > > > > > > different bindings. > > > > > > > > > > > > I am actually looking beyond just reference target, I see the > > > > > > extensibility in the following areas: > > > > > > > > > > > > 1. When/How to enable a binding to resolve the target endpoint . > > > > > > This > > > > > > include the case to support reference target, and beyond, such > > > > > > as > > > > > > supporting wireByImpl or autoWire. This also include distributed > > > > > > support in case adapters have different ways to support > > > > > > distributed > > > > > > contributions for a given virtual domain. > > > > > > > > > > > > I understand Tuscany has workspace discussions. It may > > > > > > potentially > > > > > > be > > > > > > a solution.I am still waiting to see how workspace is intending > > > > > > to > > > > > > support distributed scenarios or how it can enable late binding > > > > > > on > > > > > > resolving target endpoint. Regardless workspace is the solution > > > > > > or > > > > > > not, we need the flexibility and extensibility to overwrite > > > > > > Tuscany's > > > > > > default behavior on binding end point resolving. > > > > > > > > > > > > 2. When/How the binding resolvable is in used, > > > > > > > > > > > > Some part of the Tuscany code is using binding resolved or not > > > > > > to > > > > > > have > > > > > > different process (see point 3). I think if certain logic > > > > > > outside > > > > > > binding needs to understand if a binding is resolvable, we > > > > > > should > > > > > > make > > > > > > it clear which method achieve it so binding implementations know > > > > > > what > > > > > > to expect. > > > > > > > > > > > > I can see Tuscany code uses binding's URI and > > > > > > targetComponentService > > > > > > today, I think it should be limited to one method only, I am not > > > > > > sure > > > > > > overloading URI is good . > > > > > > > > > > > > 3. When/How to make binding selections on the reference side. > > > > > > > > > > > > I can see Tuscany is trying to remove the unresolvable bindings > > > > > > first > > > > > > from the reference side , then use some algorithm to either pick > > > > > > the > > > > > > default binding if it exists or pick the first on the list. > > > > > > > > > > > > I think we need some plug in point in Tuscany to enable > > > > > > different > > > > > > algorithm from the above default behavior. And the plugin point > > > > > > need > > > > > > to enable late binding so during reference's execution time we > > > > > > can > > > > > > determine a binding is resolvable or not and then use some own > > > > > > prioritizing rules to select the right bindings. > > > > > > > > > > > > > > > > > > I would like to see these discussions concluded with a set of > > > > > > API > > > > > > and > > > > > > some form of API interaction diagrams in the end. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Yang > > > > > > > > > > > > > > > > > > > > > > > > I can see a couple of scenarios: > > > > > > > > > > > > > > > > > > > > > > > > I thinkand binding selection that we need to enable some > > > > > > extension > > > > > > points for others using other algorism or other > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > I've been thinking about this issue for a few days on and off > > > > > > and > > > > > > > > > > > it seems > > > > > to me that the key to this is in the way that we store bindings > > > > > that > > > > > have > > > > > been read in from a composite file. > > > > > > > > > > The assembly model starts out with each reference holding all the > > > > > bindings > > > > > it is configured with in the composite file. > > > > > > > > > > During model build the set of bindings is matched with targets and > > > > > the > > > > > resulting list represents the set of resolved b
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Simon Laws wrote: On Tue, Apr 22, 2008 at 10:42 PM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: Simon Laws wrote: On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <[EMAIL PROTECTED]> wrote: On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote: I agree with Simon's emphases on the point of view. I understand Tuscany may prefer one solution over the other. However from extensibility perspective, there need some extension points to enable Tuscany adapters to overwrite the default behavior. I think the thread discussion on reference target and the comparing of 1 and 2 showcase one of the extensibility area : how to resolve reference target for different bindings. I am actually looking beyond just reference target, I see the extensibility in the following areas: 1. When/How to enable a binding to resolve the target endpoint . This include the case to support reference target, and beyond, such as supporting wireByImpl or autoWire. This also include distributed support in case adapters have different ways to support distributed contributions for a given virtual domain. I understand Tuscany has workspace discussions. It may potentially be a solution.I am still waiting to see how workspace is intending to support distributed scenarios or how it can enable late binding on resolving target endpoint. Regardless workspace is the solution or not, we need the flexibility and extensibility to overwrite Tuscany's default behavior on binding end point resolving. 2. When/How the binding resolvable is in used, Some part of the Tuscany code is using binding resolved or not to have different process (see point 3). I think if certain logic outside binding needs to understand if a binding is resolvable, we should make it clear which method achieve it so binding implementations know what to expect. I can see Tuscany code uses binding's URI and targetComponentService today, I think it should be limited to one method only, I am not sure overloading URI is good . 3. When/How to make binding selections on the reference side. I can see Tuscany is trying to remove the unresolvable bindings first from the reference side , then use some algorithm to either pick the default binding if it exists or pick the first on the list. I think we need some plug in point in Tuscany to enable different algorithm from the above default behavior. And the plugin point need to enable late binding so during reference's execution time we can determine a binding is resolvable or not and then use some own prioritizing rules to select the right bindings. I would like to see these discussions concluded with a set of API and some form of API interaction diagrams in the end. Thanks. Yang I can see a couple of scenarios: I thinkand binding selection that we need to enable some extension points for others using other algorism or other - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I've been thinking about this issue for a few days on and off and it seems to me that the key to this is in the way that we store bindings that have been read in from a composite file. The assembly model starts out with each reference holding all the bindings it is configured with in the composite file. During model build the set of bindings is matched with targets and the resulting list represents the set of resolved bindings complete with URIs identifying target services. These bindings represent the runtime configuration and are used to generate wires. To do late binding we have to maintain the original set of bindings as well as any bindings that have been fully resolved. In this way the reference can resolve targets at runtime with all the information that is used to resolve them at build time. During the first domain implementation I ran across this problem and stored the original list of bindings on the dummy target service that is created for each target. However this is less than satisfactory as this list is not persisted by the processors should the composite be written out again. If we reorganize the bindings such that we have a notion of candidate bindings and resolved bindings then candidate bindings can be used at a later point to create resolved bindings. Much of the builder processing can be done early to associate policy with bindings etc. But the wiring processing needs a bit of thinking about. Anyhow this is not a fully formed thought but I'm throwing this out there as I want to spend some time on this over the next few days and welcome any input. Regards Simon I've given this some more thought. It's a long post, sorry about that, but just diving in and changing code is going to complicate matters on this one. Requirements A - late target service location B - late binding selection C - late autowire A and B could be achieved at the time when a proxy is first called on the u
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Tue, Apr 22, 2008 at 10:42 PM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Simon Laws wrote: > > > On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <[EMAIL PROTECTED]> > > wrote: > > > > > > > On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote: > > > > > > I agree with Simon's emphases on the point of view. I understand > > > > Tuscany may prefer one solution over the other. However from > > > > extensibility perspective, there need some extension points to > > > > enable > > > > Tuscany adapters to overwrite the default behavior. I think the > > > > thread > > > > discussion on reference target and the comparing of 1 and 2 showcase > > > > one of the extensibility area : how to resolve reference target for > > > > different bindings. > > > > > > > > I am actually looking beyond just reference target, I see the > > > > extensibility in the following areas: > > > > > > > > 1. When/How to enable a binding to resolve the target endpoint . > > > > This > > > > include the case to support reference target, and beyond, such as > > > > supporting wireByImpl or autoWire. This also include distributed > > > > support in case adapters have different ways to support distributed > > > > contributions for a given virtual domain. > > > > > > > > I understand Tuscany has workspace discussions. It may potentially > > > > be > > > > a solution.I am still waiting to see how workspace is intending to > > > > support distributed scenarios or how it can enable late binding on > > > > resolving target endpoint. Regardless workspace is the solution or > > > > not, we need the flexibility and extensibility to overwrite > > > > Tuscany's > > > > default behavior on binding end point resolving. > > > > > > > > 2. When/How the binding resolvable is in used, > > > > > > > > Some part of the Tuscany code is using binding resolved or not to > > > > have > > > > different process (see point 3). I think if certain logic outside > > > > binding needs to understand if a binding is resolvable, we should > > > > make > > > > it clear which method achieve it so binding implementations know > > > > what > > > > to expect. > > > > > > > > I can see Tuscany code uses binding's URI and targetComponentService > > > > today, I think it should be limited to one method only, I am not > > > > sure > > > > overloading URI is good . > > > > > > > > 3. When/How to make binding selections on the reference side. > > > > > > > > I can see Tuscany is trying to remove the unresolvable bindings > > > > first > > > > from the reference side , then use some algorithm to either pick the > > > > default binding if it exists or pick the first on the list. > > > > > > > > I think we need some plug in point in Tuscany to enable different > > > > algorithm from the above default behavior. And the plugin point need > > > > to enable late binding so during reference's execution time we can > > > > determine a binding is resolvable or not and then use some own > > > > prioritizing rules to select the right bindings. > > > > > > > > > > > > I would like to see these discussions concluded with a set of API > > > > and > > > > some form of API interaction diagrams in the end. > > > > > > > > Thanks. > > > > > > > > Yang > > > > > > > > > > > > > > > > I can see a couple of scenarios: > > > > > > > > > > > > > > > > I thinkand binding selection that we need to enable some extension > > > > points for others using other algorism or other > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > I've been thinking about this issue for a few days on and off and > > > it seems > > > to me that the key to this is in the way that we store bindings that > > > have > > > been read in from a composite file. > > > > > > The assembly model starts out with each reference holding all the > > > bindings > > > it is configured with in the composite file. > > > > > > During model build the set of bindings is matched with targets and the > > > resulting list represents the set of resolved bindings complete with > > > URIs > > > identifying target services. These bindings represent the runtime > > > configuration and are used to generate wires. > > > > > > To do late binding we have to maintain the original set of bindings as > > > well as any bindings that have been fully resolved. In this way the > > > reference can resolve targets at runtime with all the information that > > > is > > > used to resolve them at build time. > > > > > > During the first domain implementation I ran across this problem and > > > stored the original list of bindings on the dummy target service that > > > is > > > created for each target. However this is less than satisfactory as > > > this list > > > is not persisted by the processors should the composite be written out > > > again. > > > > > > If we reorganize the bi
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Simon Laws wrote: On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <[EMAIL PROTECTED]> wrote: On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote: I agree with Simon's emphases on the point of view. I understand Tuscany may prefer one solution over the other. However from extensibility perspective, there need some extension points to enable Tuscany adapters to overwrite the default behavior. I think the thread discussion on reference target and the comparing of 1 and 2 showcase one of the extensibility area : how to resolve reference target for different bindings. I am actually looking beyond just reference target, I see the extensibility in the following areas: 1. When/How to enable a binding to resolve the target endpoint . This include the case to support reference target, and beyond, such as supporting wireByImpl or autoWire. This also include distributed support in case adapters have different ways to support distributed contributions for a given virtual domain. I understand Tuscany has workspace discussions. It may potentially be a solution.I am still waiting to see how workspace is intending to support distributed scenarios or how it can enable late binding on resolving target endpoint. Regardless workspace is the solution or not, we need the flexibility and extensibility to overwrite Tuscany's default behavior on binding end point resolving. 2. When/How the binding resolvable is in used, Some part of the Tuscany code is using binding resolved or not to have different process (see point 3). I think if certain logic outside binding needs to understand if a binding is resolvable, we should make it clear which method achieve it so binding implementations know what to expect. I can see Tuscany code uses binding's URI and targetComponentService today, I think it should be limited to one method only, I am not sure overloading URI is good . 3. When/How to make binding selections on the reference side. I can see Tuscany is trying to remove the unresolvable bindings first from the reference side , then use some algorithm to either pick the default binding if it exists or pick the first on the list. I think we need some plug in point in Tuscany to enable different algorithm from the above default behavior. And the plugin point need to enable late binding so during reference's execution time we can determine a binding is resolvable or not and then use some own prioritizing rules to select the right bindings. I would like to see these discussions concluded with a set of API and some form of API interaction diagrams in the end. Thanks. Yang I can see a couple of scenarios: I thinkand binding selection that we need to enable some extension points for others using other algorism or other - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I've been thinking about this issue for a few days on and off and it seems to me that the key to this is in the way that we store bindings that have been read in from a composite file. The assembly model starts out with each reference holding all the bindings it is configured with in the composite file. During model build the set of bindings is matched with targets and the resulting list represents the set of resolved bindings complete with URIs identifying target services. These bindings represent the runtime configuration and are used to generate wires. To do late binding we have to maintain the original set of bindings as well as any bindings that have been fully resolved. In this way the reference can resolve targets at runtime with all the information that is used to resolve them at build time. During the first domain implementation I ran across this problem and stored the original list of bindings on the dummy target service that is created for each target. However this is less than satisfactory as this list is not persisted by the processors should the composite be written out again. If we reorganize the bindings such that we have a notion of candidate bindings and resolved bindings then candidate bindings can be used at a later point to create resolved bindings. Much of the builder processing can be done early to associate policy with bindings etc. But the wiring processing needs a bit of thinking about. Anyhow this is not a fully formed thought but I'm throwing this out there as I want to spend some time on this over the next few days and welcome any input. Regards Simon I've given this some more thought. It's a long post, sorry about that, but just diving in and changing code is going to complicate matters on this one. Requirements A - late target service location B - late binding selection C - late autowire A and B could be achieved at the time when a proxy is first called on the understanding that an empty proxy can be first generated to represent these unresolved wires.This is different
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote: > > > I agree with Simon's emphases on the point of view. I understand > > Tuscany may prefer one solution over the other. However from > > extensibility perspective, there need some extension points to enable > > Tuscany adapters to overwrite the default behavior. I think the thread > > discussion on reference target and the comparing of 1 and 2 showcase > > one of the extensibility area : how to resolve reference target for > > different bindings. > > > > I am actually looking beyond just reference target, I see the > > extensibility in the following areas: > > > > 1. When/How to enable a binding to resolve the target endpoint . This > > include the case to support reference target, and beyond, such as > > supporting wireByImpl or autoWire. This also include distributed > > support in case adapters have different ways to support distributed > > contributions for a given virtual domain. > > > > I understand Tuscany has workspace discussions. It may potentially be > > a solution.I am still waiting to see how workspace is intending to > > support distributed scenarios or how it can enable late binding on > > resolving target endpoint. Regardless workspace is the solution or > > not, we need the flexibility and extensibility to overwrite Tuscany's > > default behavior on binding end point resolving. > > > > 2. When/How the binding resolvable is in used, > > > > Some part of the Tuscany code is using binding resolved or not to have > > different process (see point 3). I think if certain logic outside > > binding needs to understand if a binding is resolvable, we should make > > it clear which method achieve it so binding implementations know what > > to expect. > > > > I can see Tuscany code uses binding's URI and targetComponentService > > today, I think it should be limited to one method only, I am not sure > > overloading URI is good . > > > > 3. When/How to make binding selections on the reference side. > > > > I can see Tuscany is trying to remove the unresolvable bindings first > > from the reference side , then use some algorithm to either pick the > > default binding if it exists or pick the first on the list. > > > > I think we need some plug in point in Tuscany to enable different > > algorithm from the above default behavior. And the plugin point need > > to enable late binding so during reference's execution time we can > > determine a binding is resolvable or not and then use some own > > prioritizing rules to select the right bindings. > > > > > > I would like to see these discussions concluded with a set of API and > > some form of API interaction diagrams in the end. > > > > Thanks. > > > > Yang > > > > > > > > I can see a couple of scenarios: > > > > > > > > I thinkand binding selection that we need to enable some extension > > points for others using other algorism or other > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > I've been thinking about this issue for a few days on and off and it seems > to me that the key to this is in the way that we store bindings that have > been read in from a composite file. > > The assembly model starts out with each reference holding all the bindings > it is configured with in the composite file. > > During model build the set of bindings is matched with targets and the > resulting list represents the set of resolved bindings complete with URIs > identifying target services. These bindings represent the runtime > configuration and are used to generate wires. > > To do late binding we have to maintain the original set of bindings as > well as any bindings that have been fully resolved. In this way the > reference can resolve targets at runtime with all the information that is > used to resolve them at build time. > > During the first domain implementation I ran across this problem and > stored the original list of bindings on the dummy target service that is > created for each target. However this is less than satisfactory as this list > is not persisted by the processors should the composite be written out > again. > > If we reorganize the bindings such that we have a notion of candidate > bindings and resolved bindings then candidate bindings can be used at a > later point to create resolved bindings. > > Much of the builder processing can be done early to associate policy with > bindings etc. But the wiring processing needs a bit of thinking about. > Anyhow this is not a fully formed thought but I'm throwing this out there as > I want to spend some time on this over the next few days and welcome any > input. > > Regards > > Simon > I've given this some more thought. It's a long post, sorry about that, but just diving in and changing code is going to complicate matters o
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote: > I agree with Simon's emphases on the point of view. I understand > Tuscany may prefer one solution over the other. However from > extensibility perspective, there need some extension points to enable > Tuscany adapters to overwrite the default behavior. I think the thread > discussion on reference target and the comparing of 1 and 2 showcase > one of the extensibility area : how to resolve reference target for > different bindings. > > I am actually looking beyond just reference target, I see the > extensibility in the following areas: > > 1. When/How to enable a binding to resolve the target endpoint . This > include the case to support reference target, and beyond, such as > supporting wireByImpl or autoWire. This also include distributed > support in case adapters have different ways to support distributed > contributions for a given virtual domain. > > I understand Tuscany has workspace discussions. It may potentially be > a solution.I am still waiting to see how workspace is intending to > support distributed scenarios or how it can enable late binding on > resolving target endpoint. Regardless workspace is the solution or > not, we need the flexibility and extensibility to overwrite Tuscany's > default behavior on binding end point resolving. > > 2. When/How the binding resolvable is in used, > > Some part of the Tuscany code is using binding resolved or not to have > different process (see point 3). I think if certain logic outside > binding needs to understand if a binding is resolvable, we should make > it clear which method achieve it so binding implementations know what > to expect. > > I can see Tuscany code uses binding's URI and targetComponentService > today, I think it should be limited to one method only, I am not sure > overloading URI is good . > > 3. When/How to make binding selections on the reference side. > > I can see Tuscany is trying to remove the unresolvable bindings first > from the reference side , then use some algorithm to either pick the > default binding if it exists or pick the first on the list. > > I think we need some plug in point in Tuscany to enable different > algorithm from the above default behavior. And the plugin point need > to enable late binding so during reference's execution time we can > determine a binding is resolvable or not and then use some own > prioritizing rules to select the right bindings. > > > I would like to see these discussions concluded with a set of API and > some form of API interaction diagrams in the end. > > Thanks. > > Yang > > > > I can see a couple of scenarios: > > > > I thinkand binding selection that we need to enable some extension > points for others using other algorism or other > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > I've been thinking about this issue for a few days on and off and it seems to me that the key to this is in the way that we store bindings that have been read in from a composite file. The assembly model starts out with each reference holding all the bindings it is configured with in the composite file. During model build the set of bindings is matched with targets and the resulting list represents the set of resolved bindings complete with URIs identifying target services. These bindings represent the runtime configuration and are used to generate wires. To do late binding we have to maintain the original set of bindings as well as any bindings that have been fully resolved. In this way the reference can resolve targets at runtime with all the information that is used to resolve them at build time. During the first domain implementation I ran across this problem and stored the original list of bindings on the dummy target service that is created for each target. However this is less than satisfactory as this list is not persisted by the processors should the composite be written out again. If we reorganize the bindings such that we have a notion of candidate bindings and resolved bindings then candidate bindings can be used at a later point to create resolved bindings. Much of the builder processing can be done early to associate policy with bindings etc. But the wiring processing needs a bit of thinking about. Anyhow this is not a fully formed thought but I'm throwing this out there as I want to spend some time on this over the next few days and welcome any input. Regards Simon
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
I agree with Simon's emphases on the point of view. I understand Tuscany may prefer one solution over the other. However from extensibility perspective, there need some extension points to enable Tuscany adapters to overwrite the default behavior. I think the thread discussion on reference target and the comparing of 1 and 2 showcase one of the extensibility area : how to resolve reference target for different bindings. I am actually looking beyond just reference target, I see the extensibility in the following areas: 1. When/How to enable a binding to resolve the target endpoint . This include the case to support reference target, and beyond, such as supporting wireByImpl or autoWire. This also include distributed support in case adapters have different ways to support distributed contributions for a given virtual domain. I understand Tuscany has workspace discussions. It may potentially be a solution.I am still waiting to see how workspace is intending to support distributed scenarios or how it can enable late binding on resolving target endpoint. Regardless workspace is the solution or not, we need the flexibility and extensibility to overwrite Tuscany's default behavior on binding end point resolving. 2. When/How the binding resolvable is in used, Some part of the Tuscany code is using binding resolved or not to have different process (see point 3). I think if certain logic outside binding needs to understand if a binding is resolvable, we should make it clear which method achieve it so binding implementations know what to expect. I can see Tuscany code uses binding's URI and targetComponentService today, I think it should be limited to one method only, I am not sure overloading URI is good . 3. When/How to make binding selections on the reference side. I can see Tuscany is trying to remove the unresolvable bindings first from the reference side , then use some algorithm to either pick the default binding if it exists or pick the first on the list. I think we need some plug in point in Tuscany to enable different algorithm from the above default behavior. And the plugin point need to enable late binding so during reference's execution time we can determine a binding is resolvable or not and then use some own prioritizing rules to select the right bindings. I would like to see these discussions concluded with a set of API and some form of API interaction diagrams in the end. Thanks. Yang I can see a couple of scenarios: I thinkand binding selection that we need to enable some extension points for others using other algorism or other - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Tue, Apr 15, 2008 at 9:35 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Comments inline. > > > Simon Laws wrote: > > > On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> > > wrote: > > > > Lou Amodeo wrote: > > > > > > This is a request to propogate the value of a references target= > > > > attribute > > > > as a first class attribute on its associated bindings model object. > > > > This request is based on a requirement to provide support to > > > > implement a > > > > late-endpoint resolution capability for service references when a > > > > reference > > > > specifies the target= attribute. This value in conjunction with a > > > > domain > > > > wide services registry allows the binding invokers to use the value > > > > specified for > > > lookup > > > > to > > > > obtain the services endpoint URI dynamically during the invocation > > > > of > > > > the > > > > service rather than during compositie startup. The primary benefits > > > > of > > > > this > > > > approach are to provide a degree of location transparency for > > > > services > > > > and > > > > remove the requirement of the client from knowing the services > > > > endpoint > > > > at > > > > installation time. This would only apply to clients that are running > > > > in > > > > the > > > > same domain as the services they reference. > > > > > > > > > > > > After reading the whole thread I'm confused and would like to walk > > > through > > > a simple scenario with two composites A and B, A containing component > > > references to components in B. > > > > > > Here are the steps I'm thinking about for A and B: > > > > > > A1. contribution A is installed in the domain. > > > A2. deployable composite A is selected for deployment. > > > A3. policy sets are configured and applied to elements of A. > > > A4. A's references and dependencies are validated and satisfied. > > > A5. composite A is deployed to SCA machine 1. > > > A6. components in composite A are started. > > > A7. a reference wired to a component in B is invoked. > > > > > > B1. contribution B is installed in the domain. > > > B2. deployable composite B is selected for deployment. > > > B3. policy sets are configured and applied to elements of A. > > > B4. B's references and dependencies are validated and satisfied. > > > B5. composite B is deployed to SCA machine 2. > > > B6. components in composite B are started. > > > B7. a reference wired to a component in B is invoked. > > > > > > By SCA machine I mean a logical processor responsible for > > > instantiating > > > components and executing their implementations (a server, a process, a > > > node, > > > a webapp, or whatever applies to your particular architecture). > > > > > > Would it be possible to describe the timing of the A steps function of > > > the > > > B steps, for example > > > A1 < B1 > > > A2 < B1 > > > A3 < B1 > > > A4 > B5? > > > etc? > > > > > > That will help me understand your requirement and what you're > > > expecting of > > > the various configuration and resolution steps. > > > > > > Thanks! > > > -- > > > Jean-Sebastien > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > Hi > > > > This conversation proved inconclusive but has been dormant for a while > > so > > I'm raising it again as there have been several emails recently that > > touch > > on peoples different perceptions of how Tuscany could/should operate , > > e.g. > > [1], . Maybe we shouldn't be debating the merits of early vs late > > binding of > > reference targets in isolation but use this as very specific example of > > a > > more general question. > > > > How much flexibility of distributed operation does Tuscany allow for > > people > > implementing extensions. > > > > Going back to Lou's reference target question that started the > > referenced > > thread. IIUC the two views stated are. > > > > 1 - Reference targets are resolved before composites are deployed and > > run > > and in this way the assembly model is fully specified when > > bindings/implementations are activated and started > > 2 - Reference targets are resolved when the first request is made and in > > this way the assembly model remains incomplete in terms of runtime > > detail up > > until the point when a binding is selected, configured and started. > > > > (2) confuses me a little. > > The first part: "Reference targets are resolved when the first request is > made" seems like what you wanted to say under (2). > > But then the second part "the assembly model remains incomplete in terms > of runtime detail up until the point when a binding is selected, configured > and started." sounds like (1) "the assembly model is fully specified when > bindings/implementations are activated and started" > > Did I mis-understand what you meant in (2)? > > > > Tuscany has taken both of th
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Comments inline. Simon Laws wrote: On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Lou Amodeo wrote: This is a request to propogate the value of a references target= attribute as a first class attribute on its associated bindings model object. This request is based on a requirement to provide support to implement a late-endpoint resolution capability for service references when a reference specifies the target= attribute. This value in conjunction with a domain wide services registry allows the binding invokers to use the value specified for After reading the whole thread I'm confused and would like to walk through a simple scenario with two composites A and B, A containing component references to components in B. Here are the steps I'm thinking about for A and B: A1. contribution A is installed in the domain. A2. deployable composite A is selected for deployment. A3. policy sets are configured and applied to elements of A. A4. A's references and dependencies are validated and satisfied. A5. composite A is deployed to SCA machine 1. A6. components in composite A are started. A7. a reference wired to a component in B is invoked. B1. contribution B is installed in the domain. B2. deployable composite B is selected for deployment. B3. policy sets are configured and applied to elements of A. B4. B's references and dependencies are validated and satisfied. B5. composite B is deployed to SCA machine 2. B6. components in composite B are started. B7. a reference wired to a component in B is invoked. By SCA machine I mean a logical processor responsible for instantiating components and executing their implementations (a server, a process, a node, a webapp, or whatever applies to your particular architecture). Would it be possible to describe the timing of the A steps function of the B steps, for example A1 < B1 A2 < B1 A3 < B1 A4 > B5? etc? That will help me understand your requirement and what you're expecting of the various configuration and resolution steps. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi This conversation proved inconclusive but has been dormant for a while so I'm raising it again as there have been several emails recently that touch on peoples different perceptions of how Tuscany could/should operate , e.g. [1], . Maybe we shouldn't be debating the merits of early vs late binding of reference targets in isolation but use this as very specific example of a more general question. How much flexibility of distributed operation does Tuscany allow for people implementing extensions. Going back to Lou's reference target question that started the referenced thread. IIUC the two views stated are. 1 - Reference targets are resolved before composites are deployed and run and in this way the assembly model is fully specified when bindings/implementations are activated and started 2 - Reference targets are resolved when the first request is made and in this way the assembly model remains incomplete in terms of runtime detail up until the point when a binding is selected, configured and started. (2) confuses me a little. The first part: "Reference targets are resolved when the first request is made" seems like what you wanted to say under (2). But then the second part "the assembly model remains incomplete in terms of runtime detail up until the point when a binding is selected, configured and started." sounds like (1) "the assembly model is fully specified when bindings/implementations are activated and started" Did I mis-understand what you meant in (2)? Tuscany has taken both of these approaches and is now tending toward 1. It would be useful to have some confirmation Lou's view with comments on Sebastien's previously stated scenario. Generally there are a number of points of interest (to me at least). A - Access to model information. Bindings are not configured with information about their intended target and I guess there could be other information that bindings require for late resolution. B - Open building phases that give extensions the opportunity to override Tuscany logic, for example, binding matching and selection. C - Recognition of the flexibility of extension operation, for example, in this late resolution case [1] points out that functions like getService() should cater for the case that a proxy may be requested for a reference that is not yet resolved. So should Tuscany mandate the mechanism for distributed operation or should extension developer have the flexibility to influence it. Thoughts? Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30309.htm -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
