sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Updated response to PR comment in issue BINDINGS-87
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Wed, 26 May 2010 10:04:04 +0100
Folks,
I realised that the response has not
been sent to the originator of the public review comment recorded in BINDINGS-87.
There was an email exchange, with Anish's suggestion, and Mike's
edits, of which Anish and I expressed our approval. Here's the updated
text based on Anish's original with Mike's comments; I've also folded in
the conditional text that depended on the resolution to BINDINGS-124 (which
I suspect is why this didn't get sent at the time).
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
implementors/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. Not defining a protocol
that satisfies *every* possible callback definition and interoperability
are orthogonal. 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 [.1] did when it created a polling specification [.2]. 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.
[.1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx
[.2] 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 extended
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.
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]