RE: RE : Is This a Web Service?

Perhaps that more accurately defines why I think this example should be considered a Web service.

By the way, I don't consider this conversation to be casual.  We never did really define Web services in a way that satisfied everyone.  I have a strong feeling that at some time along the process it's going to be pretty obvious, or at least relatively easy, to come up with a consensus definition.  I'm sort of testing the waters to see if we are close to that time.  Even if we are not, I personally would be a lot happier if we had a list of simple cases that we agree are and are not Web services -- and it seems to me that shouldn't be all that hard, particularly as I think most people expect US to answer such questions.  That is, I think that we are empowered, within reason, to decide as we see fit.

-----Original Message-----
From: JP Moresmau [mailto:jean-philippe.moresmau@soamai.com] 
Sent: Tuesday, April 15, 2003 5:27 AM
To: www-ws-arch@w3.org
Subject: RE : Is This a Web Service?



Hi, I'm usually only a lurker on the list (too much work!!), but I feel I have to jump in there. From my point of view, I fail to see why (in Roger's
example)

TCP-HTTP-SOAP-(PNG image encoded as Base 64)

Is more "interoperable" than

TCP-(HTTP with content type image/png)-(PNG image encoded as Base 64)

On the contrary, the second option works even if one of the participant doesn't know what XML is, or what SOAP is. You have less protocols in the stack, and in the end you still need to agree on the data format (image/png) whatever you use... 

For the man in the street, the second example is using the web technologies, it's performing a service remotely with a well defined interface: it's a Web Service! Why do I need an extra layer to qualify as the "real web service"?

Ah, well, maybe I'm just rambling, I'll get back in my box...

JP


 	 	 Soamaï	
 	 Jean-Philippe Moresmau - CTO-Directeur Technique	
 	 1025 rue Henri Becquerel - 34036 Montpellier cedex 01 - FRANCE	
 	 Tél : +33(0)4 99 52 65 43 - Mob : +33(0)6 72 75 21 27	
 	 Std : +33 (0)1 46 08 69 00 - Fax : +33(0) 67 65 56 20	
 	 www.soamai.com	


-----Message d'origine-----
De : www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] De la part de Ugo Corda Envoyé : mardi 15 avril 2003 00:22 À : James M Snell; Cutler, Roger (RogerCutler) Cc : www-ws-arch@w3.org; www-ws-arch-request@w3.org Objet : 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 Tuesday, 15 April 2003 11:25:39 UTC