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

Eric,

Comments below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 04/16/2003 08:47:41 PM:

> 
> 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. 

Hmmm... I think I understand where you are coming from here, but I also 
think that this
characterization has some drawbacks. First off, simply because XML is not 
executable, does
not mean that my application/agent might not be processing XML directly. 
The first SOAP processor
I ever wrote was an XSLT Stylesheet. You might characterize an XSLT 
stylesheet as being
non-executable, but I'm not sure that I would agree with that 
characterization. It is little
different in my mind than Java code that is compiled and executed in a 
JVM.

Secondly, I think that it is useful to include the fact that the same 
agent can be exposed
using multiple interfaces and multiple bindings to those interfaces. The 
definition you propose
does not capture that.

> 
> 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. 

Again, I am not sure that I would agree with the reasoning, at least as 
far as it concludes that
you want to define Web services as separate from the agents that execute 
them. While it is 
most certainly true that I can have a Web service description implemented 
sixteen ways to Sunday,
a description by itself is not the service. I still maintain that a Web 
service "has an" interface.

> 
> 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.

This layer is often referred to as the "mediation" layer.

> 
> 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 ....
> > 
> 
>