RE: Nailing down the definition of "Web services" and the scope of WS A for the document

I personally prefer to stay as much as possible away from the word
"client" unless one is specifically talking about a client-server
relationship.  Although a bit unfamiliar, I think "agent" is much better
in that it is more neutral in this regard.

-----Original Message-----
From: John Crupi [mailto:John.Crupi@sun.com] 
Sent: Wednesday, April 16, 2003 9:05 PM
To: Champion, Mike
Cc: www-ws-arch@w3.org
Subject: Re: Nailing down the definition of "Web services" and the scope
of WS A for the document



Since you asked...

I know I'm late to jump in, but a few comments:

1. "A Web service is an interface to an executable software agent..."
    >> I think the 'software agent' concept will confuse many.

2. "A Web service is an interface to an executable software agent..."
    >> Are we saying a web service is not a service, but is an 
interface. Isn't a web service a service with an exposed interface?

3. "...designed to be used by another software agent."
    >>Why not say 'client' instead of agent and give examples of a 
client. Or maybe the fact that the interface is exposed implies that is 
can be used by others.

4. Also, why have a "web service" and an "XML web service" definition. 
What is wrong with taking the XML web service definition and making it 
the "WSA-compliant Web service" definition.

Just some thoughts...

jc

-- 
John Crupi
Distinguished Engineer/Chief Java Architect
Sun Software Services
Sun Microsystems, Inc.
john.crupi@sun.com
Cell: 301-526-7890
AIM: JohnCrupi



Champion, Mike wrote:

>The chairs, editors, and team contacts have spent a couple hours today 
>discussing how to incorporate the good ideas that have come up while we

>splashed around in the "what is a Web service" trout pond ... without 
>getting bogged down in the mud.  Here is my understanding of the 
>consensus, for discussion by the larger group.  The over-riding 
>intention is to push the WSA document ahead as efficiently as possible.
>
>First, it probably makes sense to distinguish the generic term "Web 
>service" from the definition of the scope of the WSA.  To pick up a 
>point that Assaf
>made: "How would you define the first few services put in place before
there
>
>was reason to exchange WSDL definitions?"  We want to be able to say 
>that a relatively broad set of things can be considered "Web services" 
>but that the WSA is going to focus on a more restrictive set.
>
>Here's a proposed defintion of the more general term:
>"A Web service is an interface to an executable software agent that is 
>designed to be used by another software agent.  A Web service is 
>identified by a URI, and has a definition in a language sufficient to 
>describe the interface to developers of client agents. A software agent

>interacts with a Web service in the manner prescribed by the formal 
>definition, using standard protocols."
>
>A couple of clarifications:  first, this doesn't exclude RESTful, 
>information-exchange services; the "executable software agent" could be

>an HTTP server.  Second, note the phrase "designed to be used by 
>another software agent."  We don't want to accept "screen-scraping" as 
>even a generic Web service technology; ANYTHING is a Web service under 
>such a defintion.
>
>I (we?) think that this generic definition includes most of what 
>reasonable people would consider to be Web services without being 
>uselessly broad.  On the other hand, it's still probably too broad to 
>be the scope of the WSA effort -- it doesn't require SOAP, WSDL, or 
>even XML. Let's define a more restrictive subset, which we'll call "XML

>Web services" [or perhaps "WSA-compliant Web services, although the 
>word "compliant" stocks a trout pond or two], upon which the WSA will 
>focus:
>
>"An XML Web service is an interface to an executable software agent 
>that is designed to be used by another software agent.  An XML Web 
>service is identified by a URI, and [CAN | MUST] have a formal 
>definition in a language that employs URI and XML. WSDL 1.2 is the 
>"reference" specification for an XML-based description language, but 
>others are possible.  A software agent interacts with an  Web service 
>in the manner prescribed by the formal definition, using XML based 
>messages conveyed by standard protocols. SOAP 1.2 is the "reference" 
>specification for an XML-based web service protocol, and the higher 
>layers of the WSA model will assume that it or an equivalent protocol
are employed."
>
>One clarification: I stuck in the references to SOAP and WSDL after the

>discussions with the other editors, and would be glad to remove them 
>... but I do think we need to make some reference to the centrality of 
>SOAP and WSDL in the WSA.
>
>There is one issue that the editors did not come to consensus on, and 
>for which we need input from the entire WG:  Is it sufficient to say 
>that the interface to an "XML Web service" CAN be described (or "is 
>capable of being
>described") using a formal description language, or is it better to say
that
>it MUST be described in a machine-processable description language?  
>
>So, is this at least a good starting point for a consensus on how to 
>define "Web service" and "XML/WSA-compliant Web service" in the WSA 
>document?  Who on the WG can't live with it?  Who outside the WG wishes

>to strenuously object? And what should the scope of the WSA require 
>...interfaces that CAN be described in a machine-processable language 
>or interfaces that MUST be described in a machine-processable 
>description language?  What other wordsmithing would anyone propose?
>
>
>
>  
>

Received on Thursday, 17 April 2003 08:48:31 UTC