RE: Is This a Web Service?

I think that interoperability was the primary reason for even starting
spending any time on all these "new" technologies. (As many people
already observed, the real novelty of these technologies - what sets
them apart from DCOM, CORBA, RMI, etc. - is their promise of
interoperability). 

So, in my mind, "Interoperable Web Service" should not be an item in a
Web services taxonomy, but should represent a property shared by all the
elements in the taxonomy. That does not mean, of course, that in the
future Web services should be limited to what is in WS-I BP 1.0 today.
It is an evolving body of technologies, an things like SOAP over JMS and
RESTfulness have to be properly taken into account.

But interoperability should be the dividing line (a moving line, as I
said) separating what is Web services from what is not.

Given the piles of hype already existing in the area of Web services,
relaxing the interoperability criterion would be a big mistake, prone to
creating a lot of confusion and offering open "creativity license" to
marketeers to classify anything they can think of as a Web service
(which in the end would make the whole concept useless).

Ugo

> -----Original Message-----
> From: James M Snell [mailto:jasnell@us.ibm.com]
> Sent: Monday, April 14, 2003 2:30 PM
> To: Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org; www-ws-arch-request@w3.org
> Subject: Re: Is This a Web Service?
> 
> 
> I have used the following terms to label a spectrum of Web 
> service types:
> 
> Custom Web Service: Uses an interface description (e.g. 
> WSDL), but all 
> other WS specs are optional (e.g. it doesn't have to use SOAP, HTTP , 
> etc... this could be nothing more than a WSDL description of 
> a Java RMI 
> interface, for instance).... some would hesitate to call this a Web 
> service (me included... but I've stuck to the use of the term "Web 
> service" here so that it fits in with existing nomenclature)
> 
> Internet Web Service: Uses an interface description (WSDL) + standard 
> internet protocols (e.g. HTTP).  All other things (e.g. SOAP) are 
> optional.
> 
> Interoperable Web Service: Uses an interface description 
> (WSDL) + standard 
> internet protoocls (e.g. HTTP) and SOAP.  Generally talking 
> about WS-I 
> basic profile conformance.
> 
> The point is, no, Web services should not be required to use 
> SOAP to be 
> considered Web services.  At a barest minimum, they should 
> require nothing 
> more than a WSDL service description.
> 
> - James M Snell
>   jasnell@us.ibm.com
>   http://www.ibm.com
>   (877) 511-5082 / Office
>   930-1979 / Tie Line
> 
> 
> 
> "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com> 
> Sent by: www-ws-arch-request@w3.org
> 04/14/2003 02:19 PM
> 
> To
> www-ws-arch@w3.org
> cc
> 
> Subject
> Is This a Web Service?
> 
> 
> 
> 
> 
> 
> The recent conversation has included the interesting idea of 
> looking at 
> Web services as SOAP services.  Are we really saying that 
> SOAP is integral 
> and required for ALL Web services?  For example (and this is a real 
> example), suppose there is a Web site on the internet that is 
> oriented 
> toward returning results to people on browsers, but if you set the 
> parameters of the GET in a particular manner it runs an 
> application that 
> generates an image (the nature of which depends on other 
> parameters) and 
> returns that image (and only the image) as an HTTP type 
> image/png.  I now 
> have an application that at some point wants to make such an 
> image with 
> the contents based, shall we say, on calculated values (in fact, this 
> determines text that is inside the image, if you must know) 
> -- and I do a 
> GET with the appropriate parameters, wait for the HTTP to 
> come back, write 
> the binary stream of the image somewhere and go about the 
> business of the 
> application which does something with the image.
> Now, I personally think that's a Web service, mostly because of the 
> application to application flavor.  I would not call it a "W3C Web 
> service", since it doesn't use WSDL and SOAP -- but it seems 
> pretty Web 
> service-ey to me.  I would personally call it an "ad hoc" Web 
> service -- 
> and I would make up another name for ebXML transactions that 
> use SOAP but 
> not WSDL, since it seems to me that those, too, are Web services that 
> handle the description differently. 
> But what do you folks think?  Does it absolutely have to use 
> SOAP to be a 
> Web service?  If so, that's an interesting and really useful thing to 
> know.  My personal opinion, for what it is worth, is that 
> simpler, ad hoc 
> things like the example above are, indeed, Web services, but 
> you quickly 
> start needing SOAP if you want to do anything other than the 
> most basic 
> operations, and so in practice most of the "interesting" Web 
> services use 
> SOAP.  I am certainly willing to agree that if a Web service uses ANY 
> enveloping mechanism that it should be SOAP, since there 
> don't seem to be 
> any other real popular candidates.  Is that a reasonable 
> point of view?
> 
>

Received on Monday, 14 April 2003 18:21:46 UTC