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

I am in the +5 camp too. Architectures are generally free of implementation 
assertions or assignments. The concepts of WSDL must be captured. But other 
service descriptions for semantics, policy, should not be precluded.

MikeM


>-----Original Message-----
>From: ext Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
>Sent: June 01, 2003 12:04 PM
>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
>
>

Received on Monday, 2 June 2003 10:43:51 UTC