RE: Is This a Web Service?

May I suggest that it may be premature to argue about how to define Web
services if we do not agree, in specific cases, whether something is a
Web service or not?  I guess I tend to an inductive approach, but I
would really like to get a laundry list together of things we think are
Web services and things we think are not, in order to test a proposed
definition against that list.
 
Along the latter lines, how about this?  Suppose an application does a
GET on a Web page that is designed for human consumption, let's say in
XHTML, and then scrapes some information off that page.  Say the number
at the end of the third <p> block.  Maybe that page was itself created
by some sort of application, or is the result of some sort of form that
runs an application -- but that page was designed for people.  Is that a
Web service?  Note that the information is coming as XML.
 
I say "No", and I kind of hope everyone says the same.  But WHY "no"?
Well, I tend to be focussed on the app-to-app aspect of the situation,
so the fact that the source page was not intended for application
consumption seems important to me.  But perhaps it is close to the same
thing to say that the source is not providing a well-defined interface,
in the sense that it contracts always to have the same information in
the third <p> block.
 
Assuming that people agree with me about this one, however, I still
would like to get some sense of whether we can agree about the HTTP GET
of an image.  It seems to me that we may be split between "yes" and
"no", with more "yes" than "no" but nonetheless significant numbers of
"no".  Many of the people who say "no" seem to be bothered by the fact
that it does not have an XML description.  Could we gain agreement on
"yes" by calling it something insulting like a "primitive Web service",
or "lousy Web service" -- well, you get the idea -- I'm not real good at
coming up with labels -- to make it clear that it may be a Web service
but it is one with very limited function and applicability?  Other
people seem to think that it is not "interoperable" -- but I really
don't understand that so I can't suggest a fix.  It seems to me that it
is obviously interoperable by my standards of interoperability.  I can
do that GET from Java, .Net, a mainframe or the London Zoo and I'll get
the same PNG file back.  What's not to be interoperable?  GET is about
as interoperable as it GET's, isn't it?
 
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: Tuesday, April 15, 2003 2:27 PM
To: 'Newcomer, Eric'; Walden Mathews; Champion, Mike; Www-Ws-Arch@W3.
Org
Subject: RE: Is This a Web Service?


Eric
 
In many ways I like your definition except that it does not mention ANY
of the well known "web services standards" such as SOAP, WSDL and UDDI.
This makes me think that perhaps there are two steps to defining a web
serivice ...
 
1. Define a web service in a standards neutral way - along the lines of
your definition or some variant. This defines WHAT a web service is
2. Define sets of standards that can implement a Web Service. This
defines HOW you implement a web service
 
Drawing an analogy to creating a building, the first is like the
architects drawing of the end result. The second is the result of the
architect and the quantity survey coming up with detailed plans of how
the building will be built. They are both valid "architectural"
activities.
 
I also think that agreeing on the first step might make it easier to
come up with the second. However it also raises the issue of how you use
standards together which WS-I is doing, should this be our perogative?
 
David

	-----Original Message-----
	From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
	Sent: Tuesday, April 15, 2003 11:03 AM
	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.