RE: Counting noses on "is SOAP and/or WSDL intrinsic to the defin ition of Web service"

I vote for -5.

I don't object to using SOAP/WSDL but our architecture should be able to
handle "naked" XML flawlessly.  Such a usage actually has been used by many
companies. If we want our architecture to be used by more people, we MUST
support such use cases. In fact, supporting such use cases can be good for
SOAP/WSDL because it provides a natural transition to SOAP/WSDL, when their
benefits become obvious.  

I feel strongly that the current architecture document does NOT provide
enough technical justification for SOAP/WSDL.  For most architects working
on real-life projects, the first questions they likly to ask about any
technology are "Why should I use it? What benefits does it provide? Can I
not to use it?"  Our architecture document will do a big favor to those
architects if we answer those questions clearly. 

Hao

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Monday, June 02, 2003 2:04 AM
To: www-ws-arch@w3.org
Subject: Counting noses on "is SOAP and/or WSDL intrinsic to the
definitio n of Web service" 





Chris said (and Ugo +1'd)

> And, for the record, I am still very much opposed to any effort
> to generalize "Web service" for purposes of this architecture document 
> that does not have SOAP and WSDL at its core. IMO, interoperability is why
> we are doing Web services in the first place, and you cannot achieve
> interop if there are thirty one flavors of Web service technology stacks.


Since we're proposing text for section 1.5 of the document, and we're doing
triage on issues to see how close we are to consensus, let's see where we
stand on this one.  I'd appreciate hearing from everyone who cares about
this (and if you want to debate someone else's position, please change the
subject line).

Heres's what I would consider to be the range of plausible opinions: (the
ordering of some of the options is a bit arbitrary, but try to get into the
spirit of the thing here ...)

-10 Neither are necessary; if two machines can agree on how to
provide/consume services over the Web, they are doing "Web services."

-5 Neither are necessary, but XML is. It's XML that provides the secret
sauce that allows machines to communicate in a standards-based but loosely
coupled way over the Web

0  SOAP or WSDL is necessary, it depends on the details of the application

+1 WSDL is necessary, but not SOAP

+2 SOAP is necessary, but not WSDL

+5 Both are necessary "conceptually" but not literally. 

+10 Both are necessary, at least as far as the scope of the WSA document is
concerned.

"Mu" [1] would also be an acceptable vote; that would indicate your sense
that this scale is meaningless, or orthogonal to your conception of what is
important.  I would imagine that Mark B. would be in the "mu" position, but
I could be wrong :-)

A few scenarios that might help:

Would something like photos.yahoo.com be a "web service"  if they documented
their URLs and POST formats well enough for programmers to use the service?
Such a service would allow one to use HTTP POST to put images in a gallery
and then, depending on the query parameters in the URI, get them back in
difference sizes, formats, orientations, etc.   If you think this is a Web
service, I think you would vote -10.

Would something like photos.yahoo.com that only worked with SVG images and
used XQuery (extended with operations to store data as well as query it) be
a "Web service?"  If so, would would probably vote -5

Would the "photos" service sketched out above be a Web service if they ....

- Published either a SOAP or a WSDL interface description?  Vote 0
- Published a WSDL description of how to access the service (with or without
SOAP)? Vote +1
- Defined a SOAP interface and documented it with example code? Vote +2
- Published a DAML-S description (or some other formal language description)
of both the data formats and protocols needed to access the service?  Vote
+5
- Defined a SOAP interface *and* published a WSDL description of the
interface?  Vote +10


[1]"mu means 'no thing'. Like 'quality' it points outside the process of
dualistic 
discrimination. mu simply says, 'no class; not one, not zero, not yes, not
no'. 
It states that the context of the question is such that a yes or no answer
is in 
error and should not be given. 'Unask the question' is what it says." 
- Robert M. Pirsig from Zen and the Art of Motorcycle 
Maintenance. http://www.amazon.com/exec/obidos/tg/detail/-/0553277472