RE: Is This a Web Service?

So I infer that you don't think the HTTP GET I described is a Web
service.  I'm OK with that if it seems to be the consensus, but I am
pretty suspicious of your insistence that a Web service must be
"discoverable".  Of course, I'm also a little hazy what that means.  If
by that you include those of David Booth's scenarios where the
"discovery" of the Web service occurs by what he calls "semantics"
(which might be a telephone call or an email in natural language), then
I'm OK.  If you are insisting that it's only a Web service if it's late
bound I am violently, unalterably opposed.
 
-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
Sent: Tuesday, April 15, 2003 1:03 PM
To: Walden Mathews; Champion, Mike; Www-Ws-Arch@W3. Org
Subject: RE: Is This a Web Service?


Hi,
 
I'd like to propose a definition I worked up recently:
 
"A Web service is an XML interface to an executable software agent that
is accessible using Web technologies.  A Web service has a description,
identified and published using a URI.  The agent has a network address,
also identified and published using a URI.  A Web service description
defines the set of one or more XML messages that can be sent to and/or
received from a Web service.   A Web service description may be
discovered using a registry, directory, or other mechanism that
associates human readable keywords with descriptions."
 
In particular, I've been trying to establish the separation between the
applications of XML that Web services consist of (i.e. the set of
schemas, DTDs, etc.) and the executable environments onto which they are
mapped or transformed.  For one thing, Web services specifications
define XML "representations" of things and while they often include
processing model information, the artifacts are nonetheless distinct.
The same Web service can be executed in disparate software environments,
meaning the "XML layer" needs to be distinct from the software agents
that execute the services.  
 
So I think it's really important to include in the definition at least
this distinction.  For example, to clarify the fact that the Web
services description or interface is a separate Web resource.  It could
live at the same URI as the executable agent, and many implementations
do in fact work this way (dereferencing the URI gets you the WSDL file
that describes the executable service accessible at the same endpoint
address).  
 
I think the fact that a description also is discoverable is part of the
definition of a Web service.
 
Eric 
 
 

	-----Original Message-----
	From: Walden Mathews [mailto:waldenm@optonline.net]
	Sent: Tuesday, April 15, 2003 1:45 PM
	To: Champion, Mike; Www-Ws-Arch@W3. Org
	Subject: Re: Is This a Web Service?
	
	
	Mike,
	 
	I disagree about the "how to construct the URL" part -- that's
brittle at best.  The
	handling of forms should be considered in the set of "generic
web protocols".   And I'm
	not clear on your requirements about the format.  Are you saying
that if the service
	just says "responses are in XHTML" that would be good enough?
	 
	Anyway, Anne's proposal was only a SHOULD w.r.t. interface
description at that
	level, and so if that's valid, then going without should also
work.  Just testing the
	[pond] waters...
	 
	Walden
	 
	 
	----- Original Message ----- 

		From: Champion, Mike
<mailto:Mike.Champion@SoftwareAG-USA.com>  
		To: Www-Ws-Arch@W3. Org 
		Sent: Tuesday, April 15, 2003 1:25 PM
		Subject: RE: Is This a Web Service?

		 

			-----Original Message-----
			From: Walden Mathews
[mailto:waldenm@optonline.net]
			Sent: Tuesday, April 15, 2003 1:16 PM
			To: Anne Thomas Manes; Www-Ws-Arch@W3. Org
			Subject: Re: Is This a Web Service?
			
			
			 
			How about leaving off the "should" on the first
one, or amending that sentence to read "The service
			should provide some type of description of its
interface, or restrict itself to a generic web interface." 
			 

		I have a hard time with this.  "Generic web interface"
in the REST sense says nothing about the rules for generating the URI or
the format of the data to be retrieved.
		 
		Think of Google (the "classic" HTTP/HTML version) ... it
might be thought of as a Web service *if* they described the rules for
generating a query (apparently pretty simple, just concatenate the
search terms together with a "+"), and if they described the format
(XHTML  is OK) of the result.  But it's not a "Web service" just by
virtue of having a "generic web interface" -- people can use the HTML
form on www.google.com and make sense of the result, but machines can't.