I've come across an interested collection of interconnected issues while looking at callbacks in the distributed domain (TUSCANY-3932). While we've done plenty of testing of this feature in the single node domain it's not had much exercise in the distributed domain. This is a little involved so bear with me.
When we detect that a reference is described by an interface with a callback we fluff up a service endpoint, at the component with the reference, in order to receive any callbacks. This endpoint is added to the registry like any other endpoint is and it's indistinguishable from any other endpoint (I think). For a wire where no callback binding is configured at the service or reference we assume that the callback adopts the binding from the forward wire. When binding.sca is used we delegate to a suitable remote binding in the distributed domain case. However we need to ensure that both the forward and callback endpoints can come up successfully on different nodes but potentially in the same JVM. Issue 1: To allow this to happen we have to be able to configure the default binding with a base URI as we do with any other binding. I've put in a fix for issue 1 which involved making a small fix to binding.hazelcast but apart from that was straightforward. The implication of this fix though is that binding.sca adopts an absolute binding URL when a remote delegate binding is in use. The forward call will transmit the URI of the callback endpoint binding in a protocol specific way. Before this change this was always the structural URI of the callback endpoint. The target service would then use this to lookup the endpoint in the registry so maintaining a certain symmetry of operation in the binding.sca case. Issue 2: The assumption that the target service can look up a callback endpoint in the registry based on the URI passed with the forward message is flawed now (and was probably before in the case of explicitly configured bindings). I have a partial fix for this which assumes that the callback endpoint is already resolved and fluffs up an endpoint with the appropriate binding and the URL it received on the forward call. This needs more work to make sure that policy is set correctly. Am leaving this until the other issues are solved. Issues 3: Given that callback endpoints are put into the registry there is a danger that they will be mistakenly matched for forward endpoint when just the component name is provided as input to the match. We should at least filter the endpoints put we currently can't identify the difference between forward and callback endpoints. I'm tempted to exclude callback endpoints from the registry altogether based on the solution to Issue 2 as I don't think they are used if we proceed with this approach. This is to TBD. Issue 4: IMO the target service side callback infrastructure is very confusing at the moment with number classes involved in the process (I'm sure I made some of this b.t.w). It needs simplifying to aid maintenance. Haven't done anything yet but I'd like to and this will have an impact on Issues 2 and 3. I've have fixes for the code to get distributed callback tests passing which I will check in so we can apply a test driven approach to solving these issues. I'll give a little time for comments and then raise JIRA as appropriate. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
