+1
-Eric.
On 05/26/2010 02:04 AM, Simon Holdsworth wrote:
OF04CA4BB8.332C25A5-ON8025772F.00300092-8025772F.003122F1@uk.ibm.com"
type="cite">
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
|