[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Response to: "Microsoft technical comment: Developinteroperable approach notspecific to SCA for callbacks"
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:email@example.com > > > > *From:* Jim Marino [mailto:firstname.lastname@example.org] > *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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]