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

Were I given the decision to make? Then...

nope.

If we're going to get some interoperability we're gonna have to pick one.
We (IBM) pick WSDL.

Given my way, the others will have to convert, I don't believe its possible
to do conversion/normalization of the semantic programmatically from one
description language to another. (personal belief... another IBMer may beg
to differ).

While all things Web services are SOA, not all things SOA are Web services.

Ok, flaming and outrage may begin.

Heather Kreger
Web Services Lead Architect
STSM, SWG Emerging Technology
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572


"Anne Thomas Manes" <anne@manes.net> on 09/23/2002 07:10:35 PM

To:    Heather Kreger/Raleigh/IBM@IBMUS, "Www-Ws-Arch@W3. Org"
       <www-ws-arch@w3.org>
cc:
Subject:    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 22:12:04 UTC