Re: Request to propogate the value of a references target= attribute on its associated bindings model object

[Simon Nash]

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.ws to
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]