Re: [sca-bindings] Response to: "Microsoft technical comment: Developinteroperable approach notspecific to SCA for callbacks"

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Few comments:

1) What the bindings TC is trying to do is define how callbacks (as 
defined by SCA assembly) would work when using WS-*. The TC's response 
that stated that "... defines an *SCA* Web service callback protocol 
standard" was meant to convey that this TC is trying to define a 
protocol for callbacks, as defined by SCA assembly. As one can imagine 
there can be several different definitions of what callbacks entail 
(semantics). This TC is chartered to define a protocol that would work 
for SCA callbacks in the WS-* world and not boil the ocean on figuring 
out what semantics a callback should have. Wrt this TC the semantics are 
already defined for us (by the assembly TC).

2) Interop is pretty important for WS-* and we should make it easy for 
other stacks like JAX-WS/WCF to implement SCA callback protocol (more on 
this later). Since the protocol uses extension points in 
SOAP/WSDL/Policy, I can't see any reason that one can't implement the 
protocol in any WS-* stack/api/toolkit, unless the stack prevents one 
from leveraging WS-* extensibility. That, IMHO, would be a deficiency in 
the stack.

3) It would be nice if the world came together and defined one WS-* 
callback wire-level protocol (with agreed upon semantics). That would be 
ideal and would result in true interop -- not because various stacks 
would allow you to implement it, but because everyone would use the same 
callback semantics. But I don't think it is in the scope of this TC to 
figure this out. And I don't see any such effort anywhere out there in 
any SDO-land. Furthermore, if such an effort did exist and it ended with 
callback semantics that are different than the one defined for SCA 
assembly it would be a problem because we would have to change the 
assembly spec (not in our scope).

4) I do believe that we should make it as easy as possible for any old 
WS-* stack to implement the SCA callback protocol. SCA's answer to the 
question of interoping outside the SCA domain is WS-* and therefore it 
makes sense for this TC to create a spec that is completely independent 
of SCA-isms, WS-* user-friendly with clear conformance criteria for just 
the protocol. I have argued before (and will continue to do so) that 
separating the protocol out of the SCA binding.ws spec and making it a 
stand-alone spec makes the most sense. This is merely a structural issue 
and doesn't change anything wrt semantics (or syntax). But it will make 
a huge difference to someone who wants to implement the protocol (and 
interop with SCA services) and the related WSDL extensions/policy 
assertions, but does not want to implement the binding.ws spec (or any 
other SCA spec).

To see how the refactored specs would look like, and to see how 
difficult/easy/ugly it would be, I went ahead and used cd03 of 
binding.ws and cd03-rev2 of assembly and created three refactored specs 
(binding.ws, assembly, and callback). The three files are attached.

The file sca-wscallback-1.1-spec-ed01.doc includes section 5 of WS 
binding, related example appendix and schema. It also includes the 
@callback attribute extension from assembly along with a schema for that 
attribute. The only new stuff is introduction and conformance section.

I did make a few ed changes and also marked (using word comments) a few 
bugs that are applicable to the spec(s) regardless of any refactoring. 
There were some issues that I saw with the spec, but did not fix it (for 
example, there is a security section for the policy assertion but not 
for the protocol) -- as I tried to keep the changes to a minimum and as 
far as possible only to those related to refactoring.

The sca-wsbinding-1.1-spec-cd03-refactored.doc changes are mostly 
deletions and associated changes to references, and conformance section etc.

The sca-assembly-1.1-spec-cd03-rev2-refactored.doc are also mostly 
deletions and associated changes to references.

There are a few ways to do this refactoring (eg: produce multiple 
documents, one for the wsdl extension, one for policy assertion, and one 
for the protocol a la WS-RX TC). I decided to keep it simple and create 
a single document that can be used independent of an SCA runtime by a 
pure WS client to interoperate with a service deployed using SCA.

This is the first attempt, so I'm sure I missed a few things, but I 
tried to be thorough and made all the necessary changes including 
conformance section, conformance items, bookmarks/cross-refs etc.

I hope this provides a clear idea of how the refactored specs would look 
like.

Comments?

-Anish
--


On 10/21/2009 2:44 PM, Konradi, Philipp wrote:
> 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.
> 
>  
> 
> Regards,
> 
> Philipp
> 
>  
> 
>  
> 
> With best regards,
> Philipp Konradi
> 
> Siemens AG
> Corporate Technology
> CT SE 2
> Otto-Hahn-Ring 6
> 81739 Munich, Germany
> Tel.: +49 (89) 636-53802
> mailto:philipp.konradi@siemens.com
> 
>  
> 
> *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.
> 
>  
> 
> 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
> 
>  
>

sca-wscallback-1.1-spec-ed01.doc

sca-wsbinding-1.1-spec-cd03-refactored.doc

sca-assembly-1.1-spec-cd03-rev2-refactored.doc