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]
