Simon Laws wrote:
On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:
On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote:
I agree with Simon's emphases on the point of view. I understand
Tuscany may prefer one solution over the other. However from
extensibility perspective, there need some extension points to enable
Tuscany adapters to overwrite the default behavior. I think the thread
discussion on reference target and the comparing of 1 and 2 showcase
one of the extensibility area : how to resolve reference target for
different bindings.
I am actually looking beyond just reference target, I see the
extensibility in the following areas:
1. When/How to enable a binding to resolve the target endpoint . This
include the case to support reference target, and beyond, such as
supporting wireByImpl or autoWire. This also include distributed
support in case adapters have different ways to support distributed
contributions for a given virtual domain.
I understand Tuscany has workspace discussions. It may potentially be
a solution.I am still waiting to see how workspace is intending to
support distributed scenarios or how it can enable late binding on
resolving target endpoint. Regardless workspace is the solution or
not, we need the flexibility and extensibility to overwrite Tuscany's
default behavior on binding end point resolving.
2. When/How the binding resolvable is in used,
Some part of the Tuscany code is using binding resolved or not to have
different process (see point 3). I think if certain logic outside
binding needs to understand if a binding is resolvable, we should make
it clear which method achieve it so binding implementations know what
to expect.
I can see Tuscany code uses binding's URI and targetComponentService
today, I think it should be limited to one method only, I am not sure
overloading URI is good .
3. When/How to make binding selections on the reference side.
I can see Tuscany is trying to remove the unresolvable bindings first
from the reference side , then use some algorithm to either pick the
default binding if it exists or pick the first on the list.
I think we need some plug in point in Tuscany to enable different
algorithm from the above default behavior. And the plugin point need
to enable late binding so during reference's execution time we can
determine a binding is resolvable or not and then use some own
prioritizing rules to select the right bindings.
I would like to see these discussions concluded with a set of API and
some form of API interaction diagrams in the end.
Thanks.
Yang
I can see a couple of scenarios:
I thinkand binding selection that we need to enable some extension
points for others using other algorism or other
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I've been thinking about this issue for a few days on and off and it seems
to me that the key to this is in the way that we store bindings that have
been read in from a composite file.
The assembly model starts out with each reference holding all the bindings
it is configured with in the composite file.
During model build the set of bindings is matched with targets and the
resulting list represents the set of resolved bindings complete with URIs
identifying target services. These bindings represent the runtime
configuration and are used to generate wires.
To do late binding we have to maintain the original set of bindings as
well as any bindings that have been fully resolved. In this way the
reference can resolve targets at runtime with all the information that is
used to resolve them at build time.
During the first domain implementation I ran across this problem and
stored the original list of bindings on the dummy target service that is
created for each target. However this is less than satisfactory as this list
is not persisted by the processors should the composite be written out
again.
If we reorganize the bindings such that we have a notion of candidate
bindings and resolved bindings then candidate bindings can be used at a
later point to create resolved bindings.
Much of the builder processing can be done early to associate policy with
bindings etc. But the wiring processing needs a bit of thinking about.
Anyhow this is not a fully formed thought but I'm throwing this out there as
I want to spend some time on this over the next few days and welcome any
input.
Regards
Simon
I've given this some more thought. It's a long post, sorry about that, but
just diving in and changing code is going to complicate matters on this one.
Requirements
------------
A - late target service location
B - late binding selection
C - late autowire
A and B could be achieved at the time when a proxy is first called on the
understanding that an empty proxy can be first generated to represent these
unresolved wires.This is different from the case where no proxy is provided
for an unwired reference.
C is more difficult as it involves the injection of one or more new proxies
depending on what the autowire process discovers. I suggest
we defer this requirement.
Inputs and Outputs
------------------
Currently the list of bindings that remain on a reference after the assembly
model is "built" is what is used to drive the creation of the runtime. The
following is a little strange but what I'm trying to show is the general
configuration of a reference, e.g. "Target = set" means that the reference
has one or more targets and "binding uri = set" means that the reference has
bindings where the binding URI is set.
Input from .composite file:
Target = null, binding uri = null
Target = null, binding uri = set
Target = set, binding uri = null
Target = set, binding uri = set - this is an error case
Output from build phase
Target = null, binding uri = null - unwired reference, i.e. autowire hasn't
matched up the reference
Target = null, binding uri = set - the binding is used to generate a
provider and a wire
Target = set, binding uri = null - A candidate for late binding (this is
currently represented by storing bindings on the dummy target service)
Target = set, binding uri = set - this is an error case but interestingly
our workspace will generate these now
Current Binding Lifecycle
-------------------------
Binding lifecycles depending on input. Note. These stages are not
represented explicitly in the binding model.
Wired Reference (Target = set, binding uri = null)
Unresolved - not associated with service and a candidate for resolution
against a service binding
(All candiate/unresolved bindings are removed from the
reference.bindings list after the build phase)
Resolved - associated with service - make better use of the resolved flag
on binding
Activated - binding provider created
Started - wire created and provider started
Unwired reference (Target = null, binding uri = set)
Resolved - assumed resolved due to user input
Activated - binding provider created
Started - wire created and provider started
Unwired reference (Target = null, binding uri = null)
Unresolved - no proxy should be injected unless autowire matches them
Resolved - autowire has matched the reference
Activated - binding provider created
Started - wire created and provider started
Once past the resolved point point the final set of bindings are known (the
reference.bindings list) and the runtime is constructed from this list.
Suggested Changes
-----------------
Tidy the binding model
A) remove the concept of Optimizable binding
Bindings will not have access directly to the target service that they
refer to through this route
B) add a direct reference between a binding and the target service model
that the binding is configured to represent
We can tell which binding is related to which target
we can tell which bindings are candidate bindings as they are not
already associated with a target model
C) make clear use of the binding.unresolved flag to indicate true = not
pointing at a service in the domain
Maintain candidate bindings
D) retain the allocation of all bindings to unresolved services
These bindings should all be fully configured in terms of available
policy
There is potentially a gap here if we don't feel the full policy set is
available in the domain when these bindings are configured
OR (not sure which one is best without doing the code but the first is there
already)
E) retain all candidate bindings on the bindings list but with URI=null and
marked as unresolved
OR
F) create two lists, candidate and resolved
Propogate unresolved targets to later processing stages
G) Allow wires to be created for unresolved services (this is different from
unwired references)
This will allow proxies to be generated in this case
Proxies must have access to the unresolved binding list through the
dummy target service (or whatever storage is chosen for this)
Not clear how this will work but will have to allow it to happen
without selecting a binding
Late resolution
H) When the proxy is called.
If the wire target is unresolved then call out to a binding resolver,
which could be pluggable, in order to:
Find target service by look up in some registry, for example
Find a binding in common with the target service - as in builder
Configure the binding with the target URI and copy it into the
reference
Create a provide for the binding - as in activate
Create a wire for the binding - as in start
Start the binding provider
If successful send the message down the wire
If not successful throw a service not found exception
Any comments gratefully accepted
Simon
So if I understand correctly:
- You want your binding invoker code to resolve a target and pick a
suitable binding at invoke time, as for example that target was not
resolvable at build time.
- The composite builder currently keeps unresolved targets as Service
proxies in the reference.target list, with each proxy holding a list of
the candidate bindings initially specified on the reference
- But unresolved targets are not properly kept in the reference.bindings
list used by the composite activator and the binding providers at
runtime, making difficult to work with these unresolved targets then.
I'd like suggest the following, a simple non-breaking change:
- For each unresolved target, store an instance of SCABinding in the
reference.bindings list with targetComponentService pointing to the target.
- In your SCABinding invoker implementation, access the
targetComponentService, resolve its location using whatever smart
resolution mechanism you want to use, pick the candidate binding that
suits it, create that binding's invoker and dispatch to it.
Or with a twist, if you don't want to do that in SCABinding, create a
new SuperSmartBindingThatResolvesThingsAtInvocationTime to handle that
smart last-second resolution logic
Makes sense? Simple enough?
--
Jean-Sebastien
