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

Does it have to be described by WSDL?
Couldn't it be described by a CPP/CPA/BPSS?
or a RosettaNet PIP? or WSCL? or FixML? or LegalXML?
or any of a host of other systems?

(I'm playing devil's advocate)

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Heather Kreger
> Sent: Monday, September 23, 2002 5:52 PM
> To: www-ws-arch@w3.org; mike.champion@softwareag-usa.com; Sanjiva
> Weerawarana
> Subject: Re: XML and SOAP constraints? (was RE: WSA constraints)
>
>
>
>
>
>
>
> Hi Mike,
> Will you receive pushback for going in this MUST BE SOAP and MUST
> BE XML on
> the wire direction?
>
> Here's some.
>
> XML was meant to mean the XML Infoset... not a hard nosed 'if it
> not xml on
> the wire its not a web service'.
>
> I certainly think that we must support other 'on the wire' formats and
> non-SOAP messages, just as WSDL supports their binding. To not do
> so limits
> the viability of this architecture in the short and long term. If anyone
> wants to do EXACTLY the same work, but over a different transport
> they will
> have to build a parallel architecture - SOA using
> my-favorite-binary-format
> - that adds no other value.
>
> I think our focus here should be the DESCRIPTION of the  Web service and
> what that enables... the SOA, and then
> the additional, business critical layers, like security, work flow,
> management.
>
> If the service is described by WSDL, its a Web service.  So, if you can
> define your web page in WSDL and it works, it
> qualifies.
>
> If WSDL supports it, we should support it.
>
> So, a constraint I would propose is : Described by  a WSDL document.
>
> Heather Kreger
> Web Services Lead Architect
> STSM, SWG Emerging Technology
> kreger@us.ibm.com
> 919-543-3211 (t/l 441)  cell:919-496-9572
>
>
> "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>@w3.org on 09/23/2002
> 04:19:40 PM
>
> Sent by:    www-ws-arch-request@w3.org
>
>
> To:    <www-ws-arch@w3.org>
> cc:
> Subject:    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 19:10:04 UTC