tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject 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
Date Sun, 11 May 2008 18:17:24 GMT
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.

View raw message