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

The main reasoning behind drawing the distinction between a Web service and the agent that executes is based on the fact that Web services specifications are all applications of XML.  XML is not executable, it's a markup language.  

Markup languages also distinguish between the content (i.e. the XML data or document instance) and the content model (i.e. the DTD/Schema or document type).  This distinction is based on the original SGML concept of separating the document format from the document text, so that the format could be changed independently of the text to support multiple output formats (letter, A4, online help, etc.) without needing to edit the text.

This concept is carried over into Web services because XML Schemas are associated with XML content, and it is possible to associate multiple schemas with the same content in order to map the same SOAP message to multiple executable agents (meaning different executable agents).

It's for these reasons that I think it's important to define Web services as entities separate from the agents that execute them. 

I also think the "mapping" or "transformation" layer (I'm not sure of the right term) is a significant aspect of Web services, which is something different in Web services compared to prior distributed computing architectures, and therefore important to preserve.

Eric

-----Original Message-----
From: Champion, Mike 
Sent: Wednesday, April 16, 2003 8:27 PM
To: www-ws-arch@w3.org
Subject: RE: Nailing down the definition of "Web services" and the scope
o f WS A for the document





> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Wednesday, April 16, 2003 5:37 PM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: Re: Nailing down the definition of "Web services" 
> and the scope
> of WS A for the document
> 
> 

> I would resist the temptation to define a service as an interface,
> because I think the default understanding is that services *have*
> interfaces, not that they *are* interfaces. 

Hmmm ... I think the way we (actually Eric) have recently defined it is
clearer.  The code that does something in the real world might be a
"service" (and for that matter, the humans that put the book in the box or
load the truck, etc. might be the ones who perform the "service"), but I
think it's useful to think of the *Web* service as the standard XML/URI
interface to the service.  That way the Web service can be neutral with
respect to whether the "service" involves bits, atoms, humans, or whatever
... it's all just about XML and URIs.

Maybe Eric could remind us  of the rest of his reasoning ....
>

Received on Wednesday, 16 April 2003 20:47:55 UTC