Following on from the thread forwarded below i've been looking at whats presently supported for callbacks and adding some tests in the callback-two-nodes itest and from that have some questions we need to answer to decide what should be supported. The spec defines how you can configure a callback binding on both a reference and a service. The spec says nothing about how the service and reference config should match or what to do if they don't, and this means in theory you may have different binding types used for the request and callbacks, and that you could define some config on the service callback and also define some different possibly conflicting config on the reference callback.
So the first question is: 1) Supporting different binding types for the request and callback messages is currently not supported by Tuscany, should it be? Not supporting this makes things much simpler so unless there is a compelling use case for needing mixed bindings I'd like to say mixing binding types is not supported. ...ant ---------- Forwarded message ---------- From: Simon Laws <simonsl...@googlemail.com> Date: Thu, Aug 25, 2011 at 3:50 PM Subject: Callback endpoints in the distributed domain To: tuscany-dev <dev@tuscany.apache.org> 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
