On Sat, May 3, 2008 at 11:10 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> 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
