By deferring the endpoint resolution until the point of invocation it reduces the window of opportunity for the reference to lookup the endpoint prior to the service being started. It also always services to change endpoints (reregister) without the need for recycle the client.
Getting back to the original request, rather than decide on a specific implementation, I was looking for an adjustment in the model. At the root of this is the ability of a binding element such as binding.ws to be able to see the attributes of its parent the reference element. Of which target is an attribute. On 1/30/08, Simon Nash <[EMAIL PROTECTED]> wrote: > > > Simon Laws wrote: > > > On Jan 21, 2008 6:55 PM, Lou Amodeo <[EMAIL PROTECTED]> 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. > >> > > > > > > Hi Lou > > > > This is interesting as I've been thinking about this myself. We > currently > > take this approach in the Tuscany code base so let me give a bit a of a > > review of that and we can then discuss what is required. > > > > In the Tuscany code we have a 'Domain' service which acts as the > > manager/registry of all of the 'Nodes' that in turn run composites. > > > > Our domain level wiring support started out life in the default binding > > only, I.e. you could only wire between remote components using 'target=' > if > > the reference also used the default binding. The default binding has > some > > code in it that used the binding URI, which by default contains > information > > from target=, to ask the domain registry what the physical URI of the > target > > service is. > > > > Now to extend this support across different types of binding we started > to > > look at this in a slightly different way. Rather than embedding code in > each > > different type of binding we added some code at the Domain level that > looks > > across the whole domain model and matches references with services. > Where a > > match is found the reference URI is completed with URI information from > the > > service. The intention with this domain level processing is that we can > more > > easily handle binding selection, policy matching and autowiring at the > > domain level. The result of this processing is an amended composite that > can > > be sent to the node for execution. > > > > This all sounds great but its starting to get a little complicated. This > is > > because we are doing the processing dynamically. When a composite is > started > > it registers its available services. The result of this is that every > time a > > composite is started the domain changes and you get a ripple effect of > > composites being amended as references are updated to include new > service > > URIs. > > > > In your note its interesting that you say "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.". I've been mulling over an alternative approach. > What I > > mean is that I recognize the need for the location transparency but that > we > > could pre-process all of the domain's composites to take account of this > > location transparency before we try and run them. This would give rise > to a > > several, more deterministic, processing steps > > > > 1. Add all of the contributions to the domain > > 2. Assign composites to the nodes where they will run > > 3. Based on 2 perform domain level wiring > > 4. Re-write the composites to contain the updated reference information > > 5. "deploy" to the contributions/composites to their allotted nodes for > > execution > > > > I'd be interested to understand what steps in bringing up a system you > have > > in mind. If we can work toward agreement on the steps involved we can > decide > > how we should amend the Tuscany code. > > > I'm trying to understand the important differences between the approach > described by Lou and the approach described by Simon. Lou seems to have > in mind a scenario that defers resolution of the protocol endpoint of the > target to the point of actually making the invocation, whereas Simon seems > to be suggesting resolving it earlier as part of deployment. > > Is there a scenario (use case) that requires the invocation-time lookup > that Lou is describing and would not work if references were bound to > protocol endpoints as part of a deployment step? If we can identify this > scenario, I think it would help us to make progress. > > Simon > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
