Some more comments inline ....
> > Lets see if I can articulate this a little better. My thinking is that > taget= represents a binding independent way to resolve an endpoint. It > doesnt necessarily specify the contents of the effective URI that is > used to address an endpoint. +1 > In the context of a WS binding for instance it > doesnt specify the value or any part of the value of the actual URL used > to > invoke the service. The binding URI attribute does represent all of or a > part of the URI used to invoke a service. The binding URI should (according to lines 2305-2307 of the assembly spec) define the target URI of the reference (either the component/service for a wire to an endpoint within the SCA domain or the accessible address of some endpoint outside the SCA domain) I think we are bending this a bit when we try and wire a remote binding, e,g, binding.ws, inside the domain and add the full URL information to the reference binding uri. Maybe need another look. > The use case I have in mind is the > ability to use target= to specify a logical representation of a URI that > can > be used by all binding types as a "key" to lookup / resolve the binding's > specific physical endpoint to be used to invoke the service. In the case > of > binding.ws for example I envision a mapping as follows : > > target = "C1/S1" binding.ws URI = "http://<someServer>/<someService>" > We have a mapping very similar to this in the domain code currently > binding.jms URI = some binding appropriate URI > > binding.sca URI = some binding appropriate URI > > In this instance only a logical value of C1/S1 needs to be specified on > the > reference target=. Each service can then register itself and all > appropriate > binding specific URI's. > > The reference can then simply specify which binding type to use and the > logical target name of C1/S1 and the binding can then "resolve" the target > to the binding specific URI. > > The binding however needs to know the value of target= to know 1) when > this > logical to physical name resolution needs to occur and 2) what key to use > to > perform the lookup. > > There is no doubt that this mapping should take place. So it comes down to whether the binding implementation should be responsible for initiating this mapping or if the mapping should take place in order that the bindings are fully configured when they are created. There are two reasons I might use to justify initiating this mapping in the binding. 1. To handle changes in the SCA model during runtime, e.g. someone adds or modifies a wire and you need a component reference to take account of this. I think there is debate in OASIS at the moment about what the shape of this capability should be. While I can't predict what the result of the Oasis discussion will be I can say that Tuscany set off looking at this but there are many complications, not least that references need to be matched with services taking into account available bindings, interface descriptions and policy intents so a much more capable domain level query is required to effect this mapping properly. 2. To handle service resilience issues, e.g. you know which service you want to talk to and have chosen a binding at the domain level but you want to take account of a service being moved deliberately or failing and being restarted. The question here is whether it is the responsibility of Tuscany to manage this, e.g. The responsibility could be devolved to the system administrator who could be expected to deploy services into some kind of cluster if there is a requirement to provide a level of abstraction between the URL that a reference targets and the location of a given service. Are there scenarios that I'm missing here? I'm really trying to understand what, on the face of it, is a very simple request (to provide more information in the binding model) as it has implication for where Tuscany users see the boundary of responsibility for an SCA application running in Tuscany. Regards Simon
