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

Hmmm....

I've always thought of the exchange of RosettaNet messages as Web servicey.
I also view XML-RPC as Web servicey. I definitely view ebXML as Web
servicey. Do we want to say that RosettaNet isn't Web services unless the
messages are relayed using SOAP and the interfaces are described using WSDL?
Do we want to say that XML-RPC is right out? ebXML is kinda based on SOAP,
but definitely not on WSDL. I feel a little uncomfortable making a statement
that these systems aren't Web services.

My view of architecture is that it describes the system in terms of its
functional components and how these functional components interrelate. e.g.:
We need a mechanism to transfer messages between applications. Constraints
on this functional component are: 1) it must be independent of platform,
language, and application/network protocol; 2) .... We need a mechanism to
describe the way an application interacts with another application.
Constraints on this functional component are: 1) it must be machine
readable, 2) .... The transfer component and the description component
interact at these points....

I think that if we create an architecture that depends on specific
technologies (specifically specific versions of technologies) then we will
unduely constrain the future possibilities of this architecture. I raised
this issue at the first F2F (in the context of the "reliability of the
architecture" discussion), but I'm not sure that we ever drilled down into
this issue.

I prefer not to define a functional architecture that says you must use SOAP
1.2 and WSDL 1.2. I suppose we could define two architectures: a functional
architecture and a reference architecture. The functional architecture
defines the basic functional components, and the reference architecture says
here's how we suggest you implement the functional architecture for maximum
interoperability (or whatever). But I don't think we can define a reference
architecture without first defining a functional architecture.

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Monday, September 23, 2002 3:18 PM
> To: www-ws-arch@w3.org
> Subject: XML and SOAP constraints? (was RE: WSA constraints)
>
>
>
>
>
> > -----Original Message-----
> > From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> > Sent: Monday, September 23, 2002 2:40 PM
> > To: Anne Thomas Manes; Mark Baker; www-ws-arch@w3.org
> > Cc: mark.baker@sympatico.ca
> > Subject: Re: WSA constraints
> >
> >
> >
> > I'm confused by the strong need to stick to XML as a constraint.
> > To me, Web services are about service-oriented architectures and
> > that does not necessarily imply the use of XML on the wire.
>
> > XML is just one (really good) technology. However, its not the
> > only technology available to serialize some typed information.
>
> [not speaking as a co-chair, just thinking out loud]
>
> 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".
>
> I think we should clarify this somewhere, perhaps along the lines of
> Sanjiva's explanation above.   Would you disagree, Anne? If so,
> what can we
> say about non-XML web services in the architecture?
>
> 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
> 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.
> 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.
>
> 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?
>

Received on Monday, 23 September 2002 16:42:35 UTC