On Thu, Aug 25, 2011 at 5:50 PM, Simon Laws <[email protected]> wrote: >>> >> >> A lot of the these other issues follow on from this issue so I'd like > > I think we need to solve the other issues regardless of issues1 as > it's possible to use interoperable bindings in both the forward and > callback wires. > >> to understand if this is really the case, so could you explain what >> you mean in more detail, perhaps showing some message flows to >> illustrate? >> >> I'm asking because isn't the point of binding.sca that it doesn't need >> a base or absolute URI > > Not from a user point of view but from an infrastructure point of view > we need to be able to configure the delegate bindings in a suitable > way. When we use an interoperable binding such as binding.ws to > support remote calls over the default binding then we have, to date, > adopted the web services approach for passing callback information. > This is convenient as we don't have to create a special case for any > bindings that we happen to choose to underpin binding.sca. The > drawback is the issue that I've presented in that interoperable > bindings tend to deal in absolute URLs as network protocols don't tend > to know anything about SCA structural URIs. We could try passing the > callback structural URI in a Tuscany specific header so it can be > pulled out and used as appropriate. I'm more than happy to take a look > at that. We do though still need to ask appropriate questions at the > service about whether that is available and treat non default bindings > in an appropriate way. > > it just has the service structural URI, and its >> down to the runtime infrastructure to use that uri to work out how to >> find the service. I'm wondering if it might be better to have the >> runtime able to find the base uri for remote nodes and use that with >> the service structural uri might be a better approach and that if we >> use an absolute URI then we might lose flexibility in a dynamic >> environment. i think thats how the hazelcast sca binding was intended >> to work, i know you said it didn't work with callbacks but that was >> just due to the callback headers not being flowed and if that was >> fixed it would have worked ok wouldn't it? > > Right, hazelcast binding lack of callback support is unrelated. I'm > using the web services delegate for testing. >> >> ...ant >> > > > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
I've been thinking about this overnight and a drawback of changing the default binding URI is that the built composite can't be re-written maintaining it's original form. We could hold a deployedURI field (or similar) on the default binding for this purpose and allow this to be passed down to the delegate binding. It's still the case though that.. - the ERP structural URI should be the source of the reference URI for matching purposed. The default binding URI feeds into this in the case that no reference target is specified. - the delegate binding protocol header will need to be extended to carry the structural URI in an SCA specific way to allow for callback reference matching Also - to maintain the callback endpoint in the registry for matching purposes we'll have to add some meta-data to allow use to differentiate if from forward endpoints to solve issue 3 Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
