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. Regards Simon
