[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bindings] Response to: "Microsoft technical comment: Develop interoperable approach notspecific to SCA for callbacks"
IMHO SCA is about components, services, an assembly model allowing to use any implementation technology and communication protocol but it’s NOT about creating own protocol or protocol extensions.
That’s why I think defining an SCA-specific protocol for callbacks in WS is wrong by its nature. It’s like building huge walls around the SCA world, preventing interop with the outside!
This is especially true for WS binding, which is the standard solution when it comes to integration.
I agree of course that the absence of an WS callback protocol is an issue we need somehow to find a solution for.
It seems to me that there is also no disagreement that the best solution and the way to go is creation of a new TC, expert group (in OASIS, W3C, whatever) standardizing a mechanism for callback in WS, covering statefull as well as stateless communication. I’m also pretty optimistic that some members of this TC as well as external parties like Microsoft, providers of WS-Stacks, consumer companies would be willing to participate and to contribute in this new body.
Sooner or later this is going to happen, I’m pretty sure.
The question to me is what to do for the next two years while such a standard doesn’t exist?!
Burning a callback protocol into SCA specs is in my eyes the worst option we could take. This will stick to SCA and be a hurdle for the longest time possible.
Better option IMO would be to be silent about callback protocol in the spec and provide separately a document defining WS callbacks for the time of standard absence. Though this won’t solve the interop problem, it will allow to switch to the new callback standard ASAP without waiting for WS Binding 3.0 to change the text of the spec (BTW this option shouldn’t make proving compliance more complex IMO).
The other option of being completely silent on callbacks will ensure fastest adoption of new standard as soon as it’s out but will limit compatibility of SCA runtimes in between. Being optimistic that it won’t take long for a mature draft of the new callback standard to be released, this option seems also fine to me.
Thinking loud another idea just came into my mind: why not make callback mechanisms configurable through SCA intents and policies? They proved themselves when it comes to define the protocol details for a service binding e.g. when it comes to authentication or encryption. By saying callback.sca, callback.wcf, callback.foo the user can define which callback mechanisms should be used for a particular service or reference. Not sure whether it’s feasible, but seems worth to be discussed and who knows maybe we find some more solutions when starting looking at it from another perspective.
With best regards,