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

 
-----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 ...