W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2003

Re: Counting noses on "is SOAP and/or WSDL intrinsic to the definition of Web service"

From: Assaf Arkin <arkin@intalio.com>
Date: Mon, 02 Jun 2003 11:07:12 -0700
Message-ID: <3EDB9250.1010109@intalio.com>
CC: www-ws-arch@w3.org

For the exact same reasons as stated by Ugo I would also vote +10.

However, I would like to see the definition be written in terms of -10 
first, and then some explanation to rationalize the +10.

arkin

> Ugo Corda wrote:
>
>> +10.
>>
>> The open ended nature of SOAP and WSDL bindings should provide plenty
>> of flexibility for alternatives other than the classical WSDL binding
>> to SOAP over HTTP.
>>
>> I also think that, using Mike's words, "there is not much difference
>> between the +5 and the +10 positions, because SOAP 1.2 and WSDL 1.2
>> are rich and extensible enough to encompass things like RESTful and
>> Semantic Web applications". In fact, SOAP 1.2 Web Method feature
>> supports a RESTful model, and the WSD group is discussing how to
>> integrate RDF in WSDL 1.2 as we speak.
>>
>> At this point in time, I believe any decision of extending WSA's
>> foundations beyond SOAP and WSDL would create confusion in the
>> industry and undermine the main reason for Web services existence,
>> i.e. interoperability.
>>
>> If at a certain point in the future it became evident that the
>> industry needed something more than SOAP and WSDL as WS foundation, I
>> would certainly be happy to contemplate a new version of WSA that
>> took that into account.
>>
>> Ugo
>>
>>
>>
>>> -----Original Message----- From: Champion, Mike
>>> [mailto:Mike.Champion@softwareag-usa.com] Sent: Sunday, June 01,
>>> 2003 9: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
>>>
>>>
>>
>>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.
Received on Monday, 2 June 2003 14:07:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:20 GMT