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
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
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 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
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 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
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 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
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 reference target= as a key to perform a service 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 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
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 reference target= as a key to perform a service 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 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
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]
[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 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 reference target= as a key to perform a service 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. 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
