Response to: "Microsoft technical comment: Develop interoperable approachnot specific to SCA for callbacks"

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

This is a formal response of the OASIS
SCA Bindings technical committee to the "Response to: "Microsoft
technical comment: Develop interoperable approach not specific to SCA for
callbacks" which was sent to the SCA Bindings public comments list.
 This is the agreed response
of the technical committee as a whole and was approved unanimously at the
meeting of the
TC which took place on May 27th 2010. 

------------------------ 

On 10/7/2009 9:12 AM, Michael Champion
wrote: 
> Thank you for considering Microsoft's suggestion for improving the
SCA 
> Web Services Binding spec's interoperability 
> (http://www.osoa.org/jira/browse/BINDINGS-87).

The TC greatly appreciate Microsoft's comments and the ongoing dialog.
 It would be even better, from an interoperability and adoption perspective,
if Microsoft were to participate in the SCA bindings TC and participate/contribute
to the TC's work. 

> We suggested that Web Services callbacks in the SCA Web Services Binding
> 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.

There is perhaps a misunderstanding about the SCA Web Services Callback
Protocol. There is *nothing* in the protocol that impedes wire-level interoperability
with frameworks such as JAX-WS and WCF. The protocol (and the associated
WSDL extension, WS-Policy assertion) uses the well know and well adopted
WS-* architecture of composable specifications. It uses SOAP/WSDL/WS-Policy
extensibility/architecture to implement the callback functionality. Any
WS-* stack that allows one to handle extensibility/composable specification
should be able to handle the protocol.  Indeed the testcase suite
is designed to use JAXWS components to check the conformance of an SCA
runtime to the binding.ws specification. 

Perhaps you mean "out-of-the-box" interoperability from JAX-WS/WCF.
If so, then that is the decision the implementers/creators of JAX-WS/WCF
have to make. It is not within the scope of this TC. Since Microsoft owns
WCF, it would be up to Microsoft to provide such an "out-of-the-box"
interoperability, and this TC would urge Microsoft to do so.  To that
end, the TC has created separate conformance targets/sections that allows
for entities that want to conform to the protocol, but not necessarily
implement an SCA runtime. See resolution of issue 124 [.1]

[.1] http://osoa.org/jira/browse/BINDINGS-124

> 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 is incorrect. Interoperability is orthogonal from defining a protocol
that satisfies *every* possible callback use case.  As mentioned above,
SCA Web Services Callback Protocol is interoperable with non-SCA runtimes
as long as they implement the protocol as specified.

To clarify what we said previously: 

The TC is not interested in boiling the ocean to satisfy every callback
scenario and every possible callback definition. Microsoft's comment was
interpreted by the TC as suggesting that all the callback-related discussion
need to be re-discussed in a separate TC and that we need to start from
scratch. We believe that the SCA callback definition satisfies the needs
of SCA. Furthermore the SCA callback definition is general enough to satisfy
other needs as well. Doing so is well within the scope of this TC and we
believe it is interoperable on the wire. 

This is very similar to what the WS-RX TC [.2] did when it created a polling
specification [.3]. Polling is necessary to implement reliable messaging
when one of the interacting entities is behind a firewall.
They created a specification that
is useful for WS-ReliableMessaging as well as other WS-* implementation
that have a need for polling and choose to use WS-MakeConnection for that
purpose. 

[.2] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx
[.3] http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html

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

To clarify our previous response: 

We believe that we have defined an interoperable callback protocol. It
works for SCA and we believe it works for other architectures and programming
models (SCA is designed ground-up for a multiple programming model environments).
 If Microsoft believes that the SCA callback definition does not fit
their architecture/programming model, then we respectfully request (and
per our understanding certain members of the TC have in the past) Microsoft
to participate in the TC. No one, including Microsoft, has brought forward
any *specific* architectural or interoperability issues with the callback
protocol definition. 

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

Again, we would welcome Microsoft's participating in this TC. 

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

The specification has been changed to
provide specific conformance statements that provide a definition of what
any runtime, including non-SCA runtimes, would need to do to conform to
the protocol and to interoperate on the wire. See resolution of issue 124
[.4] that makes those changes.

[.4] http://osoa.org/jira/browse/BINDINGS-124

------------------------


Simon Holdsworth