RE: Is This a Web Service?

+1. Well said! - Edwin

> 
> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Ugo Corda
> Sent: Monday, April 14, 2003 3:22 PM
> To: James M Snell; Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org; www-ws-arch-request@w3.org
> 
> 
> 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:49:34 UTC