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]
