| Hi,
Comments inline...
Jim On Oct 7, 2009, at 7:42 PM, Eric Johnson wrote: Here are my immediate thoughts, in response, for the TC's consumption: Michael Champion wrote: We suggested that Web Services callbacks in the SCA Web Services Binging spec should interoperate with comparable frameworks such as JAX-WS and WCF, and not be limited to various implementations of SCA. This would promote the original goals of the Web Services standards to achieve wire-level interoperability among diverse run-times and platforms.
I'm unaware of anything in JAX-WS that addresses callbacks, so I don't understand that point, or how it is comparable. Nor am I aware of anything that we've specified that prevents a vendor from using JAX-WS to implement callbacks support within the SCA environment. Presumably implementation experience will reveal details here?
I have run into a number of difficulties trying to integrate SCA callbacks with WCF services (specifically, duplex services, see next comment) for a client. Basically, the way SCA represents callbacks at the protocol level (in WSDL and on the wire) is not interoperable with WCF. The only way to make these types of interactions work is to introduce proprietary behavior in an SCA runtime to support WCF's protocols.
With respect to WCF, I'm not aware of its capabilities, and whether or not it provides anything equivalent to the callback functionality of SCA. Does anyone else on the TC have insight into this?
The analog of SCA callbacks in WCF is duplex services, which provide bidirectional communication. One difference between WCF duplex services and SCA callbacks are the former are stateful. That is, the WCF client instance originating the forward call will receive callbacks. Prior to the deferral of conversational services, SCA conversational callbacks could be used to model this functionality.
At the protocol level, duplex services (which use the WCF duplex binding) rely on WS-RM and sequence ids for correlation. In WSDL, WCF represents duplex services as a a form of solicit-response with an output/input sequence. At the wire level, what we've describe remains interoperable and compatible. Seems to me like the actual issue is at the protocol level.
At the wire level, things as they currently stand are not strictly interoperable because SCA callbacks are stateless and WCF duplex services are stateful.
The SCA Binding TC responded by saying that the SCA Web Services binding protocol "defines an *SCA* Web service callback protocol standard” and that it "is not meant to satisfy general purpose callback requirements with a broadest scope possible". In other works, the TC believes that the SCA Web Services callbacks will NOT be interoperable with non-SCA implementations
That sounds incorrect to me. Seems like it is completely out of scope for an SCA TC to dictate how or if any standard outside of SCA reaches compatibility with something inside of SCA. Nothing prevents other implementations (Mike Champion's word choice) from achieving interoperability.
The TC's response goes on to say that "This TC does believe that it should define an interoperable Web services protocol that implements SCA callback and it has done that. It does not believe that it is in the scope or interest of this TC to define a callback protocol for all architectures and programming models." We respectfully find this statement contradictory, unless the TC defines the term "interoperability" in its narrowest form: SCA implementations will only be interoperable amongst themselves, and not with other frameworks and runtimes. We would find this unfortunate, as OASIS is committed to broad interoperability, especially when it comes to use of Web Service wire protocols. It would be better to standardize a Web Services callback in a separate spec, with the participation of all vendors who build platforms and products that support Web Services wire protocols.
Yes, we define interoperability amongst SCA runtimes (including from different vendors), since that's within the scope of our charter. The "narrowest" sense would be only interoperability among a single vendor (see JMS itself, the "binding.sca" binding, and various Microsoft networking protocols, at some point in time.). So I disagree with the characterization of this as the "narrowest" possible form of interoperability. Further, we don't deny the utility of a broad specification, and yes, we believe interoperability at a larger scale would be useful. It just isn't in our charter. Is Microsoft explicitly requesting a change in charter? If so, they should explicitly state that.
It is clear from [1] that the TC is aware that interoperability with non-SCA runtimes is an issue. The TC discussed the idea of moving the callback portion of the protocol into its own document in order to address "the use case of non-SCA clients does walk into the more general territory alluded to by MS." We highly recommend that the Binding and Assembly TCs work together to design a Web Services Binding spec that is interoperable with non-SCA technologies. Without interoperability, software developers and users will find it difficult to use SCA in the heterogeneous, multi-vendor environments that all our customers live in.
Absolutely nothing here prevents vendors from building compatible systems with both SCA and non-SCA parts that interact. In fact, we expect it. Further, when bridging from a non-SCA environment to an SCA environment, a vendor such as Microsoft should only have to implement compatibility with the SCA WS Callbacks mechanism once, and it should work with all vendors providing SCA environments. If they believe this last point is incorrect, it would be enormously useful for Microsoft to identify the specific oversights of the currently specified approach. -Eric.
These last statements seem a bit odd. I thought one of the purposes of the web services binding was to provide interoperability into and out of a domain. For example, I think the requirement to integrate with WCF and non-SCA software will be much more common than integration between different SCA vendor runtimes. Of course, other systems could integrate with SCA by implementing support for proprietary SCA protocols but that kind of defeats the purpose of interoperability (a general integration mechanism).
It seems that Microsoft is proposing the SCA TCs not define a callback mechanism and instead work jointly in some other TC to define an interoperable protocol for bidirectional communication. If this is the case, such an approach would provide a lot more value to end-users than a proprietary SCA mechanism since it would allow SCA, WCF, JAX-WS, etc. to interoperate at a much deeper level. Maybe this is something we should ask Microsoft if they would be interested in pursuing?
Jim
|