Thanks for all the responses and good discussion.
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. 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 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>" 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. On 1/31/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > snip... > > > > > >>The value from the reference target is currently set to the target > when > > > the reference is matched to a target service. > > > > > I don't quite follow the above. Are you saying that the service URI > > is copied into the reference binding URI at the matching stage? Is this > > the fully resolved absolute service URI rather than the relative URI > > that a client target attribute would specify? > > > > Yes. It's the binding uri that the component service holds. For a local > SCA > binding this will be the same as the target name that the user entered > into > the composite file except where the shortened form of the service name is > used. > > In the case where a remote binding is in use it should be the fully > resolved > URI. The domain does this for us at the moment at run time. As I said > earlier in this thread there is a case for changing this calculation to > happen at deployment time so instead of the domain providing updates to > nodes telling the node when service URIs change the deployment stage would > be expected to provide a fully resolved composite at the point at which > the > composite is started. The result would though be the same in that the > binding URI would correctly represent the endpoint details of the > referenced > service. The point in time at which that information is know though is > different. > > Simon >
