Re: What does "Web service" mean [please don't run away screaming] ( was RE: Is This a Web Service?)

I think that Mike raises some important issues here, that the group 
does eventually need to get clarity on.

For what it is worth I propose the following:

There is a general notion of web service (note the case) which, 
according to the requirements have the properties:

> - A Web service has a unique identity, thus can/should be given a URI.
> - The Web services messages and descriptions can/should be represented 
> using XML
> - Web services messages can/should be conveyed by Internet protocols.


However, this is a W3C group. And I, for one, feel a little 
uncomfortable relegating core W3C specifications (SOAP, WSDL, WSCHOR 
etc) to the bin of `possible implementation technologies'. I don't 
think that that is what is expected.

On the other hand, it is also true that the above mentioned specs `do 
not cover the space'.

Ultimately, we need a framework in which the appropriate technologies 
can be related (the Architecture) and a specific set of recommendations 
that meet the goals (Web services).

Frank



On Tuesday, April 15, 2003, at 09:56  AM, Champion, Mike wrote:

>  
> -----Original Message-----
> From: Champion, Mike
> Sent: Tuesday, April 15, 2003 12:24 PM
> To: 'Cutler, Roger (RogerCutler)'; Walden Mathews; Champion, Mike
> Subject: What does "Web service" mean [please don't run away 
> screaming] (was RE: Is This a Web Service?)
>
>  
>
> -----Original Message-----
> From: Cutler, Roger (RogerCutler) 
> [mailto:RogerCutler@ChevronTexaco.com]
> Sent: Tuesday, April 15, 2003 11:49 AM
> To: Walden Mathews; mike.champion@softwareag-usa.com
> Subject: RE: Is This a Web Service?
>
> Historically, I think the current definition was more the result of 
> exhaustion than consensus.   Sooner or later I think we will need to 
> revisit it, and I am sort of testing the waters.  We had to start out 
> somewhere, but at the time we didn't have enough specifics in hand to 
> get any kind of real consensus so we just stopped at a point that 
> everyone agreed was not really satisfactory.  As an architecture 
> progresses I think it should become increasingly apparent what we are 
> really talking about.
>  
> These issues HAVE to be addressed sooner or later.  They can't just 
> remain vague forever if we are to have a meaningful architecture.  And 
> I believe that the answers to my initial posting do indicate that the 
> current understanding is pretty vague. 
>  
>
> I tend to agree with Roger.  We "trout-ponded" on this a year ago, and 
> more or less just agreed to set it aside with the definition in the 
> Requirements doc, IIRC.  We can't face the world if we can't define 
> what *we* mean by "Web services".  On the other hand, I agree 
> with [someone] who argued that the best way forward is to come up with 
> various *qualified* definitions rather than the One True definition.
>  
> In the Requirements definition, I think there were basically three 
> components
>  
> - A Web service has a unique identity, thus can/should be given a URI.
> - The Web services messages and descriptions can/should be represented 
> using XML
> - Web services messages can/should be conveyed by Internet protocols.
>  
>   
> This does dovetail with the TAG's definition [well, my rephrasing of 
> my understanding of] the three pillars of Web architecture:
> - The Web consists of "resources" identified by URIs
> - The Web operates by the exchange of resource representations in a 
> open-ended set of formats (identified by MIME type)
> - These representations are exchanged via a limited set of protocols 
> that understand URIs, especially HTTP/HTTPS and FTP.
>  
> On the other hand, our "classic" definition  doesn't really capture 
> the essence of what people actually DO with Web services, i.e. one 
> software agent invoking other software agents to exchange information 
> and optionally invoke a real-world service.  Also, we have to take 
> into account the [painful to some] fact that some "Web" services don't 
> necessarily involve internet protocols, unless we somehow consider JMS 
> implementations, MQ-variants, etc. "internet" protocols.   I thought 
> that Noah M.'s presentation at the Plenary did a very nice job of 
> illustrating the different senses in which we can consider WS to be 
> "on the Web" - There's the "Web of URIs", the "Web of widely deployed 
> URI schemes", the "Web of widely deployed media types", etc.
>  
> I won't propose the text of a definition, but I think it must address 
> the points that a) Web services are *essentially* about machines 
> communicating with machines using standardized protocols and data 
> formats, b) some machine-processable description (WSDL, RDF+ontology, 
> or whatever) is necessary IN PRINCIPLE to get the machines to agree on 
> what they are doing (although in practice this can be done by 
> programmers talking to programmers); c) some conception of "the Web" 
> -- at least the "Web of URIs" -- is presumed as the domain in which 
> the services operate; and d) XML is usually, if not always, the 
> preferred data format for descriptions, invocation messages, and 
> result messages.
>  
> So:
>  
> - WSDL is not absolutely necessary, but *some* standardized, machine 
> processable definition of the "interface" between WS producers and 
> consumers is necessary for reliable machine-machine communication, and 
> WSDL is the currently dominant way to do this.
>  
> - SOAP is not absolutely necessary, but provides an extremely useful 
> and extensible framework for Web services messaging because it allows 
> important services such as routing, filtering, encryption/signing, and 
> multi-message synchronization [I'm thinking of reliable messaging, 
> choregraphy, transactions, etc.].
>  
> Perhaps we do want some sort of taxonomy ... just throwing out some 
> terms without reviewing the other proposals previously in this thread:
>  
> "ad hoc" Web services are those such as Roger's example where machines 
> are communicating over the internet and exchaning standard data 
> formats, but the "interface description" is implicitly understood by 
> the programmers rather than explicitly defined in a WSDL document or 
> RDF-based something or other.
>  
> "formalized" Web services are the SOAP/WSDL things that most people 
> think of ...
>  
> "WSA-compliant Web services" are those that follow the guidelines we 
> eventually come up with???
>  
> Sorry to blather on for so long ...

Received on Thursday, 17 April 2003 14:52:19 UTC