OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[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"

Hi all,


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,
Philipp Konradi

Siemens AG
Corporate Technology
Otto-Hahn-Ring 6
81739 Munich, Germany
Tel.: +49 (89) 636-53802


From: Jim Marino [mailto:jim.marino@gmail.com]
Sent: Tuesday, October 20, 2009 3:29 PM
To: Patil, Sanjay
Cc: OASIS Bindings
Subject: Re: [sca-bindings] Response to: "Microsoft technical comment: Develop interoperable approach notspecific to SCA for callbacks"



On Oct 16, 2009, at 10:31 AM, Patil, Sanjay wrote:


Hi Jim,


I have some questions on your following comment: <Jim>Even in the hypothetical case where the SCA approach is adopted wholesale by other platforms, the namespaces and way of representing callbacks would need to be changed to fit into a more general approach. If the current approach is adopted, there is the real potential that an interoperable approach will be needed later that is incompatible with the former. <Jim>


What do we mean by a  more general approach here? I thought that SCA approach is intended to be the more general and standardized approach and if there are any technical issues in that we should identify and address them. If the callback functionality from the SCA WS binding specification were made available in a modular manner so that it can be used independently in a standalone manner (without requiring the use of the entire SCA WS binding spec), would that be the solution here? As far as the namespace (for the callback functionality) is concerned, whether it is defined by a SCA TC or some other new TC, how does it matter? Namespaces are supposed to be opaque anyways! Or am I missing something? It has become hard (for me) to sort out the dialogue in the below email thread.




Hi Sanjay,


The current SCA approach is very specific to SCA as is tied to the SCA notion of callbacks and not a generic representation of bidirectional communications. Consequently, it is not interoperable. I don't think separating out the protocol into a separate *SCA* spec would be the solution either, since that would not address the fundamental interoperability problem. The best solution in my opinion would be to remove it from the SCA binding specification and create another TC whose charter is to define an interoperable protocol based on WS-* for bidirectional communications. Also, changing the namespace won't be sufficient since the problem is that the protocol is tied to the SCA representation of callbacks as opposed to a more generic one that can be repurposed for other programming models such as WCF and JAX-WS. . 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]