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

I am basically of similar mind, although perhaps not exactly specifically
agreeing.  There was another thread a bit earlier talking, yet again, about
whether web services were restricted to XML/SOAP/WSDL.  I think it makes
sense to define a web services architecture that is specific in this way.
That doesn't mean there aren't other useful things out there -- just that
they don't happen to fit into this particular architecture.  The strength of
doing this, it seems to me, is that one then has something pretty specific
to hang one's hat on -- but NOT a mandate, either explicit or implied, that
everything in the world has to fit into this mold.

I think other people in the thread probably said it better, but I thought
I'd express my general support for that type of approach rather than the
alternative of trying to define something broad enough to catch everything
of interest in the net.

-----Original Message-----
From: Heather Kreger [mailto:kreger@us.ibm.com] 
Sent: Monday, September 23, 2002 9:12 PM
To: Anne Thomas Manes
Cc: www-ws-arch@w3.org
Subject: 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 Tuesday, 24 September 2002 11:35:11 UTC