Re: XML and SOAP constraints? (was RE: WSA constraints)

"Champion, Mike" <Mike.Champion@SoftwareAG-USA.com> writes:
>
> As much as I shudder at the prospect of re-opening the "what is a
> web service" discussion, I think we are going to have to take a
> definitive stand on the role of XML and SOAP in the WSA.  Our working
> definition talks about "interfaces and bindings ... capable of being
> defined, described, and discovered as XML artifacts."  As I recall, we
mean
> "XML" (as does SOAP 1.2, explicitly) to mean the Infoset, not the
> serialization syntax.  Clearly a module that takes a binary representation
> of a SOAP message, parses it into an XML infoset representation, processes
> it according to the SOAP model, and passes it along in XML 1.0
serialization
> syntax is a "SOAP processor".

Understood - I'm also not interested in reopening that discussion.
It is however interesting to note that SOAP lets you take the
SOAP infoset, serialize it using something other than an XML
infoset and then read it back into a SOAP infoset and execute
(via an XML infoset or not). That is surely a Web service
invocation .. even if the on-the-wire serialization is IIOP.

> FWIW, I was originally inclined to think of an HTML page for something
like
> a stock quote or online catalog with a well-documented format that a
program
> could easily work with (e.g., "id" attributes that would point to specific

WSDL 1.1 (and likely 1.2) has HTTP GET and HTTP POST bindings which
allow one to use a on-the-wire serialization other than XML. Are
those no longer Web services??

> bits of information), that was invoked with a well-documented URI format,
as
> a "web service" even though it didn't use XML, SOAP, or WSDL.  I wouldn't
> defend that position now, at least in terms of the WSA -- a "WSA-compliant
> web service" needs to be grounded in *something* so that additional
features
> (choreography, security, reliable transport, etc.) can be layered on it.

BPEL4WS layers on WSDL without assuming specific bindings (SOAP or
XML for that matter) and provides a composition (choreography) model
that works just fine. The on-the-wire stuff for BPEL can be anything ..
and our implementation (on alphaWorks) supports SOAP, Java method
calls and RMI/IIOP as "on-the-wire" serializations.

> Hmm, I guess the WS Description folks are talking about being able to
> describe non-XML content, so if they do that, perhaps my example *would*
be
> compliant.  Or for that matter, if browsers reliably parse HTML into an
> infoset so that a portable DOM program can extract the information in a
WSDL
> description, I guess it could be an  "XML" web service as far as we're
> concerned.


The WS-Desc WG agreed at the last F2F to not preclude non-XML
bindings. However, we are not planning on doing any non-XML bindings
on our own.

> On the other hand, the path of least resistance and most interoperability
> might be to accept that a "W3C WSA-compliant XML web service" *must* use
> SOAP and be capable of being described with WSDL.  (Mind you, I think this
> is totally orthogonal to the issue of REST vs something else ... the
> SOAP-format resource could be accessed via the HTTP methods  and
identified
> by a URI).  Do we need to do that to keep the WSA reasonably focussed?
Will
> we get major pushback from anyone if we go that direction?

I'm sorry for opening a can of worms.

Sanjiva.

Received on Monday, 23 September 2002 16:21:19 UTC