In an attempt to add precision to our discussion of "what is a web service", this is a listing of example services based on Mike C's posting [1] and constraints taken from the current architecture document[2] and Mike's posting.

Example Services

1. The "service" is an ordinary HTML Web page whose structure appears to follow a predictable pattern but the underlying code/stylesheets are not publicly available; a client agent "screen scrapes" the HTML to extract information into a data structure for further processing.
2. The "service" is some executable software accessed by a CGI script that processes the information defined by an HTML FORM; the client agent generates the GET or POST that would be submitted by a browser after a human fills out the form.
3. The "service" is a RESTful hypermedia application (e.g. an online travel agency) designed to be used by either human agents or software agents and the returned data is XHTML; the client agent was programmed after consultation with the "service" developers to simulate the sequence of GETs and POSTS -- checking the HTTP return codes and parsing the result data to find the appropriate URI to go to the next state.
4. Same as RESTful but there is no human-usability requirement and the syntax of the returned data is XML that conforms to an agreed upon schema and the rules for interpreting the results and moving to the next state are well-defined in an XML-based format.
5. The "service" is some executable software accessed by a SOAP interface whose only description is the Java code that actually implements it; the client agent is hand-coded after a telephone conversation with the developer of the "service."
6. A "semantic web" application in which agents interact via HTTP (without SOAP) based on a formal description of what is to be done that doesn't involve WSDL, but does involve RDF/OWL.

Constraints

1. Identifiers (see 2.2.9 for definition, 5.2 for constraints)
   1. Service must use URIs for identifiers.
   2. Identifiers must be opaque { Identifiers must permit multiple references to a resource to be viewed as equivalent. [ section 2.2.9.3 ]}
2. XML
   1. public interfaces and bindings, if defined and described, must be in XML. [ 1.5.1 ]
   2. XML must be used for communications between service and client agent { from Mike C's email - suggested alternate wording: Message content [ 2.2.13] must be XML. }
3. Communication/transport/xxx
   1. Message envelopes, encoding rules, call and response representation and rules for using HTTP must conform with SOAP specifications.
   2. {SOAP Should be used for messages [ 5.3.3 ] {therefore no constraint related to SOAP}
   3. {there should be more, broken down in the 4 functions soap performs} SOAP consists of four fundamental components: an envelope that defines a framework for describing message structure, a set of encoding rules for expressing instances of application-defined data types, a convention for representing remote procedure calls (RPC) and responses, and a set of rules for using SOAP with HTTP. SOAP can be used in combination with a variety of network protocols; such as HTTP, SMTP, FTP, RMI/IIOP, or a proprietary messaging protocol
4. Description
   1. Description of service interfaces, binding and related information must be a valid instance of WSDL.
   2. Description of service interfaces, binding and related information must be in machine processable form.
   3. {There should be constraints on how alternative descriptions such as DAML are added to the overall description. }

Analysis

KEY:

• 0 = Does not conform
• 1 = Conforms to some portion of the constraint
• 2 = Fully conformant