You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/04/11 11:08:24 UTC
[BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Lou Amodeo 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.
> >
> >
> After reading the whole thread I'm confused and would like to walk through
> a simple scenario with two composites A and B, A containing component
> references to components in B.
>
> Here are the steps I'm thinking about for A and B:
>
> A1. contribution A is installed in the domain.
> A2. deployable composite A is selected for deployment.
> A3. policy sets are configured and applied to elements of A.
> A4. A's references and dependencies are validated and satisfied.
> A5. composite A is deployed to SCA machine 1.
> A6. components in composite A are started.
> A7. a reference wired to a component in B is invoked.
>
> B1. contribution B is installed in the domain.
> B2. deployable composite B is selected for deployment.
> B3. policy sets are configured and applied to elements of A.
> B4. B's references and dependencies are validated and satisfied.
> B5. composite B is deployed to SCA machine 2.
> B6. components in composite B are started.
> B7. a reference wired to a component in B is invoked.
>
> By SCA machine I mean a logical processor responsible for instantiating
> components and executing their implementations (a server, a process, a node,
> a webapp, or whatever applies to your particular architecture).
>
> Would it be possible to describe the timing of the A steps function of the
> B steps, for example
> A1 < B1
> A2 < B1
> A3 < B1
> A4 > B5?
> etc?
>
> That will help me understand your requirement and what you're expecting of
> the various configuration and resolution steps.
>
> Thanks!
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Hi
This conversation proved inconclusive but has been dormant for a while so
I'm raising it again as there have been several emails recently that touch
on peoples different perceptions of how Tuscany could/should operate , e.g.
[1], . Maybe we shouldn't be debating the merits of early vs late binding of
reference targets in isolation but use this as very specific example of a
more general question.
How much flexibility of distributed operation does Tuscany allow for people
implementing extensions.
Going back to Lou's reference target question that started the referenced
thread. IIUC the two views stated are.
1 - Reference targets are resolved before composites are deployed and run
and in this way the assembly model is fully specified when
bindings/implementations are activated and started
2 - Reference targets are resolved when the first request is made and in
this way the assembly model remains incomplete in terms of runtime detail up
until the point when a binding is selected, configured and started.
Tuscany has taken both of these approaches and is now tending toward 1. It
would be useful to have some confirmation Lou's view with comments on
Sebastien's previously stated scenario.
Generally there are a number of points of interest (to me at least).
A - Access to model information. Bindings are not configured with
information about their intended target and I guess there could be other
information that bindings require for late resolution.
B - Open building phases that give extensions the opportunity to override
Tuscany logic, for example, binding matching and selection.
C - Recognition of the flexibility of extension operation, for example, in
this late resolution case [1] points out that functions like getService()
should cater for the case that a proxy may be requested for a reference that
is not yet resolved.
So should Tuscany mandate the mechanism for distributed operation or should
extension developer have the flexibility to influence it.
Thoughts?
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30309.htm
Re: [BRAINSTORM] Flexibility in distributed operation and extension
implementations - was: Re: Request to propogate the value of a references
target= attribute on its associated bindings model object
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Sat, May 3, 2008 at 11:10 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Jean-Sebastien Delfino wrote:
>>
>>> Anyhow if this code is doing what I think it's doing then maybe we should
>>>> move it to be a little earlier in the process and more general than the
>>>> sca
>>>> binding. We could take the checking code you have here and put it a
>>>> little
>>>> higher up where the reference targets are identified. If you are able to
>>>> check a test in the I could have a look at this if you like.
>>>>
>>>>
>>> OK, I'll post here as soon as the test is in. Thanks.
>>>
>>>
>> It's in now, I've added tutorial/store-client (a client for store-supplier)
>> and tutorial/store-test.
>>
>> Store-test starts the domain manager, the catalogs, store-supplier and
>> store-client nodes, then looks up the client service and invokes it. The
>> client service orders 5 oranges puts them in the shopping cart, the test
>> then checks that the total prices is as expected.
>>
>> The test looks pretty simple but actually exercises a lot of the SCA
>> domain, node, distributed wiring and configuration logic, Java components
>> with a Derby database integration as well as a mix of the WebService,
>> SCA-local and Atom bindings.
>>
>> Hope this helps.
>> --
>> Jean-Sebastien
>>
>
> Thanks for doing that Sebastien.
>
> In order to make this retrieval of the target name from the binding URI a
> little neater and to move a little closer toward a more coherent solution
> for this I'd like to make some more changes in conjunction with this...
>
> Currently the builders are responsible for reconstructing the reference
> binding list using some hidden (Target) structures and logic. In the
> fullness of time it feels like we need some endpoint structure to bring
> together target names and candidate bindings. I think we can move toward
> this by extending the solution discussed previously on this thread along the
> following lines.
>
> Instead of relying on the default SCA binding for late resolution processing
> create a new binding called Endpoint (in the future I would expect that this
> ceases to be derived from Binding but for now if we create it based on
> binding we can increment toward a more complete solution).
>
> The endpoint implementation clases would be replaceable in the same way that
> any other binding is replaceable.
>
> An Endpoint would be created by the builder code in the following situations
> User specified reference target name
> User specified target name in binding uri
> Autowire target identified
> Wire by impl is set on a reference
>
> The endpoint is given the same information as is kept in various places in
> unresolved reference bindings today, for example,
> target name
> candidate bindings
> target service
> chosen binding
>
> The endpoint is responsible for performing reference target resolution, i.e.
> make a resolver that has access to the builder code that does
> service/binding matching. We then plumb the binding that results from this
> resolution back into the current binding list so nothing that happens today
> changes. If the endpoint remains unresolved though it has the access to the
> same resolution functions at a later date and the Endpoint provider will be
> able to kick in at start () or message send to perform the resolution step.
>
> Another thought is that we still have the OptimizableBinding interface that
> some bindings implement. Previously I had been looking for an excuse to
> remove this as I don't know what it's for. Having looked at this area a bit
> now though it does seem useful in the case where the candidate binding
> itself wants to get involved in the resolution process. So maybe
> OptimizableBinding is not the right name for it (why is it called this?) but
> it does seem to have value.
>
> Simon
>
I agree that we need an Endpoint model object. The most obvious
requirement for this is references with multiplicity, where we have one
binding for several target (endpoints).
If we introduce such an Endpoint model, I'd prefer to do a clean cut:
- add that model
- populate it
- define new Provider SPIs that take an endpoint instead of a binding
as IMO morphing Binding into an Endpoint is just going to create more
confusion in an area that's already not so clear.
The two sets of SPIs could co-exist for a while with BindingProviders
working with bindings and ServiceProviders (I just made up that name)
with service endpoints.
--
Jean-Sebastien
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Sat, May 3, 2008 at 11:10 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
>
>> Anyhow if this code is doing what I think it's doing then maybe we should
>>> move it to be a little earlier in the process and more general than the
>>> sca
>>> binding. We could take the checking code you have here and put it a
>>> little
>>> higher up where the reference targets are identified. If you are able to
>>> check a test in the I could have a look at this if you like.
>>>
>>>
>> OK, I'll post here as soon as the test is in. Thanks.
>>
>>
> It's in now, I've added tutorial/store-client (a client for store-supplier)
> and tutorial/store-test.
>
> Store-test starts the domain manager, the catalogs, store-supplier and
> store-client nodes, then looks up the client service and invokes it. The
> client service orders 5 oranges puts them in the shopping cart, the test
> then checks that the total prices is as expected.
>
> The test looks pretty simple but actually exercises a lot of the SCA
> domain, node, distributed wiring and configuration logic, Java components
> with a Derby database integration as well as a mix of the WebService,
> SCA-local and Atom bindings.
>
> Hope this helps.
> --
> Jean-Sebastien
>
Thanks for doing that Sebastien.
In order to make this retrieval of the target name from the binding URI a
little neater and to move a little closer toward a more coherent solution
for this I'd like to make some more changes in conjunction with this...
Currently the builders are responsible for reconstructing the reference
binding list using some hidden (Target) structures and logic. In the
fullness of time it feels like we need some endpoint structure to bring
together target names and candidate bindings. I think we can move toward
this by extending the solution discussed previously on this thread along the
following lines.
Instead of relying on the default SCA binding for late resolution processing
create a new binding called Endpoint (in the future I would expect that this
ceases to be derived from Binding but for now if we create it based on
binding we can increment toward a more complete solution).
The endpoint implementation clases would be replaceable in the same way that
any other binding is replaceable.
An Endpoint would be created by the builder code in the following situations
User specified reference target name
User specified target name in binding uri
Autowire target identified
Wire by impl is set on a reference
The endpoint is given the same information as is kept in various places in
unresolved reference bindings today, for example,
target name
candidate bindings
target service
chosen binding
The endpoint is responsible for performing reference target resolution, i.e.
make a resolver that has access to the builder code that does
service/binding matching. We then plumb the binding that results from this
resolution back into the current binding list so nothing that happens today
changes. If the endpoint remains unresolved though it has the access to the
same resolution functions at a later date and the Endpoint provider will be
able to kick in at start () or message send to perform the resolution step.
Another thought is that we still have the OptimizableBinding interface that
some bindings implement. Previously I had been looking for an excuse to
remove this as I don't know what it's for. Having looked at this area a bit
now though it does seem useful in the case where the candidate binding
itself wants to get involved in the resolution process. So maybe
OptimizableBinding is not the right name for it (why is it called this?) but
it does seem to have value.
Simon
Re: [BRAINSTORM] Flexibility in distributed operation and extension
implementations - was: Re: Request to propogate the value of a references
target= attribute on its associated bindings model object
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
>> Anyhow if this code is doing what I think it's doing then maybe we should
>> move it to be a little earlier in the process and more general than
>> the sca
>> binding. We could take the checking code you have here and put it a
>> little
>> higher up where the reference targets are identified. If you are able to
>> check a test in the I could have a look at this if you like.
>>
>
> OK, I'll post here as soon as the test is in. Thanks.
>
It's in now, I've added tutorial/store-client (a client for
store-supplier) and tutorial/store-test.
Store-test starts the domain manager, the catalogs, store-supplier and
store-client nodes, then looks up the client service and invokes it. The
client service orders 5 oranges puts them in the shopping cart, the test
then checks that the total prices is as expected.
The test looks pretty simple but actually exercises a lot of the SCA
domain, node, distributed wiring and configuration logic, Java
components with a Derby database integration as well as a mix of the
WebService, SCA-local and Atom bindings.
Hope this helps.
--
Jean-Sebastien
Re: [BRAINSTORM] Flexibility in distributed operation and extension
implementations - was: Re: Request to propogate the value of a references
target= attribute on its associated bindings model object
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> Was just looking at the checkin. Thanks for making the fix. Now we don't
> generate invalid composite files when they get written out.
>
> Re. the second part dealing with URIs. It looks to me like this is picking
> up the case where the URI has been specified as the name of the target
> service. A feature which the spec call for. I have to admit that I can't
> recall a test for this now you mention it but are you saying this used to
> work at some point. I'd be a little surprised if we hadn't implemented that.
> But maybe I'm wrong.
My understanding is that the implementation was missing and there was no
test for it :)
>
> Anyhow if this code is doing what I think it's doing then maybe we should
> move it to be a little earlier in the process and more general than the sca
> binding. We could take the checking code you have here and put it a little
> higher up where the reference targets are identified. If you are able to
> check a test in the I could have a look at this if you like.
>
OK, I'll post here as soon as the test is in. Thanks.
> Simon
>
--
Jean-Sebastien
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 1, 2008 at 8:27 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Simon Laws wrote:
>
> > On Tue, Apr 22, 2008 at 10:42 PM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org> wrote:
> >
> > Simon Laws wrote:
> > >
> > > On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <
> > > > simonslaws@googlemail.com>
> > > > wrote:
> > > >
> > > >
> > > > On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <ge...@gmail.com>
> > > > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > > 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
> > >
> > >
> > Hi Sebastien
> >
> > Thanks for the thought. Sounds good to me. Simpler than my suggestion.
> > The
> > basis of this is actually what the code used to do in the old domain
> > implementation :-) So not difficult to move back to that. I like your
> > twist
> > that binding.sca has make use of the candidate binding list for binding
> > matching. Nice one. I'll give it a go and report back.
> >
> > Thanks for the input.
> >
> > Simon
> >
> >
> Simon, your changes under SVN r651490 to represent unresolved targets with
> bindings worked - almost - perfectly :) I only ran into a minor issue with
> tutorial/store-merger where the reference to the VegetablesCatalog was
> overriden by the default SCA binding that was created for that reference (as
> its target was remote).
>
> Unrelated to your changes but contributing to cause that bug - we were
> missing a little bit of code to deal with URIs on SCA bindings. I checked in
> a small fix to BaseWireBuilderImpl in SVN r652631.
>
> All the wiring works now, I'll add some tests to tutorial/domain to make
> sure it continues to work :)
>
> Thanks!
> --
> Jean-Sebastien
>
Hi Sebastien
Was just looking at the checkin. Thanks for making the fix. Now we don't
generate invalid composite files when they get written out.
Re. the second part dealing with URIs. It looks to me like this is picking
up the case where the URI has been specified as the name of the target
service. A feature which the spec call for. I have to admit that I can't
recall a test for this now you mention it but are you saying this used to
work at some point. I'd be a little surprised if we hadn't implemented that.
But maybe I'm wrong.
Anyhow if this code is doing what I think it's doing then maybe we should
move it to be a little earlier in the process and more general than the sca
binding. We could take the checking code you have here and put it a little
higher up where the reference targets are identified. If you are able to
check a test in the I could have a look at this if you like.
Simon
Re: [BRAINSTORM] Flexibility in distributed operation and extension
implementations - was: Re: Request to propogate the value of a references
target= attribute on its associated bindings model object
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Tue, Apr 22, 2008 at 10:42 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Simon Laws wrote:
>>
>>> On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>
>>>> On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <ge...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>> 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
>>
>
> Hi Sebastien
>
> Thanks for the thought. Sounds good to me. Simpler than my suggestion. The
> basis of this is actually what the code used to do in the old domain
> implementation :-) So not difficult to move back to that. I like your twist
> that binding.sca has make use of the candidate binding list for binding
> matching. Nice one. I'll give it a go and report back.
>
> Thanks for the input.
>
> Simon
>
Simon, your changes under SVN r651490 to represent unresolved targets
with bindings worked - almost - perfectly :) I only ran into a minor
issue with tutorial/store-merger where the reference to the
VegetablesCatalog was overriden by the default SCA binding that was
created for that reference (as its target was remote).
Unrelated to your changes but contributing to cause that bug - we were
missing a little bit of code to deal with URIs on SCA bindings. I
checked in a small fix to BaseWireBuilderImpl in SVN r652631.
All the wiring works now, I'll add some tests to tutorial/domain to make
sure it continues to work :)
Thanks!
--
Jean-Sebastien
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Apr 22, 2008 at 10:42 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Simon Laws wrote:
>
> > On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> >
> > > On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <ge...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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
>
Hi Sebastien
Thanks for the thought. Sounds good to me. Simpler than my suggestion. The
basis of this is actually what the code used to do in the old domain
implementation :-) So not difficult to move back to that. I like your twist
that binding.sca has make use of the candidate binding list for binding
matching. Nice one. I'll give it a go and report back.
Thanks for the input.
Simon
Re: [BRAINSTORM] Flexibility in distributed operation and extension
implementations - was: Re: Request to propogate the value of a references
target= attribute on its associated bindings model object
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
>>
>> On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <ge...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>> 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
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <si...@googlemail.com>
wrote:
>
>
> On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <ge...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> 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
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <ge...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
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
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Yang Lei <ge...@gmail.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Apr 15, 2008 at 9:35 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Comments inline.
>
>
> Simon Laws wrote:
>
> > On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org>
> > wrote:
> >
> > Lou Amodeo 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.
> > > >
> > > >
> > > > After reading the whole thread I'm confused and would like to walk
> > > through
> > > a simple scenario with two composites A and B, A containing component
> > > references to components in B.
> > >
> > > Here are the steps I'm thinking about for A and B:
> > >
> > > A1. contribution A is installed in the domain.
> > > A2. deployable composite A is selected for deployment.
> > > A3. policy sets are configured and applied to elements of A.
> > > A4. A's references and dependencies are validated and satisfied.
> > > A5. composite A is deployed to SCA machine 1.
> > > A6. components in composite A are started.
> > > A7. a reference wired to a component in B is invoked.
> > >
> > > B1. contribution B is installed in the domain.
> > > B2. deployable composite B is selected for deployment.
> > > B3. policy sets are configured and applied to elements of A.
> > > B4. B's references and dependencies are validated and satisfied.
> > > B5. composite B is deployed to SCA machine 2.
> > > B6. components in composite B are started.
> > > B7. a reference wired to a component in B is invoked.
> > >
> > > By SCA machine I mean a logical processor responsible for
> > > instantiating
> > > components and executing their implementations (a server, a process, a
> > > node,
> > > a webapp, or whatever applies to your particular architecture).
> > >
> > > Would it be possible to describe the timing of the A steps function of
> > > the
> > > B steps, for example
> > > A1 < B1
> > > A2 < B1
> > > A3 < B1
> > > A4 > B5?
> > > etc?
> > >
> > > That will help me understand your requirement and what you're
> > > expecting of
> > > the various configuration and resolution steps.
> > >
> > > Thanks!
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > Hi
> >
> > This conversation proved inconclusive but has been dormant for a while
> > so
> > I'm raising it again as there have been several emails recently that
> > touch
> > on peoples different perceptions of how Tuscany could/should operate ,
> > e.g.
> > [1], . Maybe we shouldn't be debating the merits of early vs late
> > binding of
> > reference targets in isolation but use this as very specific example of
> > a
> > more general question.
> >
> > How much flexibility of distributed operation does Tuscany allow for
> > people
> > implementing extensions.
> >
> > Going back to Lou's reference target question that started the
> > referenced
> > thread. IIUC the two views stated are.
> >
> > 1 - Reference targets are resolved before composites are deployed and
> > run
> > and in this way the assembly model is fully specified when
> > bindings/implementations are activated and started
> > 2 - Reference targets are resolved when the first request is made and in
> > this way the assembly model remains incomplete in terms of runtime
> > detail up
> > until the point when a binding is selected, configured and started.
> >
>
> (2) confuses me a little.
>
> The first part: "Reference targets are resolved when the first request is
> made" seems like what you wanted to say under (2).
>
> But then the second part "the assembly model remains incomplete in terms
> of runtime detail up until the point when a binding is selected, configured
> and started." sounds like (1) "the assembly model is fully specified when
> bindings/implementations are activated and started"
>
> Did I mis-understand what you meant in (2)?
>
>
> > Tuscany has taken both of these approaches and is now tending toward 1.
> > It
> > would be useful to have some confirmation Lou's view with comments on
> > Sebastien's previously stated scenario.
> >
> > Generally there are a number of points of interest (to me at least).
> >
> > A - Access to model information. Bindings are not configured with
> > information about their intended target and I guess there could be other
> > information that bindings require for late resolution.
> > B - Open building phases that give extensions the opportunity to
> > override
> > Tuscany logic, for example, binding matching and selection.
> > C - Recognition of the flexibility of extension operation, for example,
> > in
> > this late resolution case [1] points out that functions like
> > getService()
> > should cater for the case that a proxy may be requested for a reference
> > that
> > is not yet resolved.
> >
> > So should Tuscany mandate the mechanism for distributed operation or
> > should
> > extension developer have the flexibility to influence it.
> >
> > Thoughts?
> >
> > Simon
> >
> > [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30309.htm
> >
> >
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Hmmm, that could have been clearer. Let me try 2 again.
2) Reference targets are resolved when the first request is made through the
reference. The assembly model remains incomplete in terms of full runtime
detail for this reference right up to the point when a message passes
through a reference and a binding is selected, configured and started.
I was trying to emphasize that there is a point of view that says that
target resolution should be left until the latest possible moment, i.e. the
point at which a message is about to be sent to the target. The implications
of this, though, are more widespread that the binding implementation
itself.
Simon
Re: [BRAINSTORM] Flexibility in distributed operation and extension
implementations - was: Re: Request to propogate the value of a references
target= attribute on its associated bindings model object
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
Simon Laws wrote:
> On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
>> Lou Amodeo 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.
>>>
>>>
>> After reading the whole thread I'm confused and would like to walk through
>> a simple scenario with two composites A and B, A containing component
>> references to components in B.
>>
>> Here are the steps I'm thinking about for A and B:
>>
>> A1. contribution A is installed in the domain.
>> A2. deployable composite A is selected for deployment.
>> A3. policy sets are configured and applied to elements of A.
>> A4. A's references and dependencies are validated and satisfied.
>> A5. composite A is deployed to SCA machine 1.
>> A6. components in composite A are started.
>> A7. a reference wired to a component in B is invoked.
>>
>> B1. contribution B is installed in the domain.
>> B2. deployable composite B is selected for deployment.
>> B3. policy sets are configured and applied to elements of A.
>> B4. B's references and dependencies are validated and satisfied.
>> B5. composite B is deployed to SCA machine 2.
>> B6. components in composite B are started.
>> B7. a reference wired to a component in B is invoked.
>>
>> By SCA machine I mean a logical processor responsible for instantiating
>> components and executing their implementations (a server, a process, a node,
>> a webapp, or whatever applies to your particular architecture).
>>
>> Would it be possible to describe the timing of the A steps function of the
>> B steps, for example
>> A1 < B1
>> A2 < B1
>> A3 < B1
>> A4 > B5?
>> etc?
>>
>> That will help me understand your requirement and what you're expecting of
>> the various configuration and resolution steps.
>>
>> Thanks!
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
> Hi
>
> This conversation proved inconclusive but has been dormant for a while so
> I'm raising it again as there have been several emails recently that touch
> on peoples different perceptions of how Tuscany could/should operate , e.g.
> [1], . Maybe we shouldn't be debating the merits of early vs late binding of
> reference targets in isolation but use this as very specific example of a
> more general question.
>
> How much flexibility of distributed operation does Tuscany allow for people
> implementing extensions.
>
> Going back to Lou's reference target question that started the referenced
> thread. IIUC the two views stated are.
>
> 1 - Reference targets are resolved before composites are deployed and run
> and in this way the assembly model is fully specified when
> bindings/implementations are activated and started
> 2 - Reference targets are resolved when the first request is made and in
> this way the assembly model remains incomplete in terms of runtime detail up
> until the point when a binding is selected, configured and started.
(2) confuses me a little.
The first part: "Reference targets are resolved when the first request
is made" seems like what you wanted to say under (2).
But then the second part "the assembly model remains incomplete in terms
of runtime detail up until the point when a binding is selected,
configured and started." sounds like (1) "the assembly model is fully
specified when bindings/implementations are activated and started"
Did I mis-understand what you meant in (2)?
>
> Tuscany has taken both of these approaches and is now tending toward 1. It
> would be useful to have some confirmation Lou's view with comments on
> Sebastien's previously stated scenario.
>
> Generally there are a number of points of interest (to me at least).
>
> A - Access to model information. Bindings are not configured with
> information about their intended target and I guess there could be other
> information that bindings require for late resolution.
> B - Open building phases that give extensions the opportunity to override
> Tuscany logic, for example, binding matching and selection.
> C - Recognition of the flexibility of extension operation, for example, in
> this late resolution case [1] points out that functions like getService()
> should cater for the case that a proxy may be requested for a reference that
> is not yet resolved.
>
> So should Tuscany mandate the mechanism for distributed operation or should
> extension developer have the flexibility to influence it.
>
> Thoughts?
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30309.htm
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org