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

Chris,
 
Yes, I agree that the same agent can have multiple definitions.  But I also think the same Web service description can be mapped to multiple different types of agents.
 
I do think XSLT is an execution environment, but I do not think that is the same as saying that XML is complied and executed.   I also agree that a processing model is required to implement the mediation layer between the Web service and its (one or more) executable agent(s).  
 
But I also think a Web service exists without either of those things, and can exist *without* an executable agent.  Web services do not exist until and unless the mediation layer transforms or interprets the XML into something executable.  To say that the executable agent onto which the Web service is transformed, or into which it's interpreted, omits the mediation layer from the definition and I think that's wrong.  It's like equating Web services and application servers or .NET or any other specific technology, when what they really represent is an abstraction layer above any of those things.  That layer is what we need to be defining, and the processing model of the mediation or transformation layer, not the executable agent (which can be anything).
 
Eric

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, April 17, 2003 7:55 AM
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



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