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. Sanjay
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. .
Jim
|