On Jan 30, 2008 8:06 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > See inline. > > Simon > > Lou Amodeo wrote: > > > 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.wsto > > be able to see the attributes of its parent the reference element. > > Of which target is an attribute. > > > In general elements don't know about their parent, only about their > children. They only know about their parent or its attributes if the > parent has passed that information down to them. Maybe others can > explain the reason for this. > > The reference target is supposed to be exactly equivalent to the > binding URI. (It's not legal to specify both.) If the value from > the reference target were set into the binding URI, would that give > you what you need? > > Simon > > > > > > > > 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] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > The value from the reference target is currently set to the target when the reference is matched to a target service. I guess that could be brought forward and have the target copied into the reference binding URI prior to the matching stage. It will only help though if, at deployment time, you are preprocessing the SCA composites to match reference binding to service binding and choose the binding you expect to be active at runtime. Otherwise the runtime won't know which binding invoker to choose.
Is this the direction you are thinking of? Simon
