RE: /service/@targetResource ?

Arthur,
 
Yes, I realize the conflict.  We've had many discussions on the WSA list about it.  In my view the "tunneling" of method names within the message violates REST principles but provides practical advantages for Web services.  I agree uniform interfaces are a great thing for browsers.  For Web services, however, it helps in mapping to existing and new programs and objects to include the abstraction of a service name in addition to data type and structure information.  
 
I also realize that the use of specific methods names does not scale as well as the use of uniform interfaces.  To me it's a question of where the architecture places the burden of mapping to the executable agents, and how much.  In the case of Web services, I also do not believe that the use cases are the same as for browsers -- especially in the use of Web services as a business communication tool, since businesses will want to communicate most often with other businesses they already know.
 
In the case of WSDL, I view WSDL as containing semantic information associated with the SOAP message.  In markup language terms, the SOAP message represents the XML document instance while WSDL represents the document content model.  What I'd like to see is a reference to the content model separated from the reference to the endpoint to which the message is sent, although many Web services toolkits allow you to use the same URI for both.
 
I think it's very important for WSA to distinguish clearly between the exectuable agent and its description because Web services are applications of XML that are mapped out of and onto executable agents.  The agents can be any program or object, and Web services specifications do not define the executable agent beyond its processing model requirements.  I think this is as important to preserve as the distinction between HTML and Web servers and browsers, meaning any HTML file can be served by any Web server, and any HTML file can be displayed by any browser (delta variations in implementation of course, but it largely works).
 
Some would argue that this is already possible simply by substituting XML for HTML, but the purposes of Web services are  differ from the purposes of the hypertext Web, although there is overlap.  Web services go beyond the hypertext Web by including information that's understandable to executable agents, in particular a service name that maps to a program name,  object method, or data queue, and to transform XML data types and structures into an executable language's data types and structures. 
 
If a Web service is a resource plus an interface, I'd say WSA is looking to assign identity to each separately (although the resulting URI could be shared).
 
Eric
 
-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com]
Sent: Friday, May 23, 2003 10:01 AM
To: www-ws-desc@w3.org
Subject: RE: /service/@targetResource ?




Eric, 

Yes, Web services are in conflict with at least one REST principle, namely Uniform Interface. REST says that all resource response to a uniform interface, e.g. GET, POST, PUT, etc. That's a great thing for enabling Web browsers. A Web browser can always try to do a GET and receive some reasonable representation of the resource. Web services can be viewed as taking a more strongly typed view of interfaces. In fact, WSDL is essentially an interface definition language. Web services allows you to define strongly typed interfaces to access resources. Furthermore, a resource may implement one or more interfaces. A Web service is really a resource plus an interface. Since a Web service is a concept, it also can be assigned a URI, but that URI is not necessarily the same as the resource the service acts on. In WSDL, we can assign a URI to a service based on the targetnamespace-URI of the WSDL document, which is in general different from the URI of! the resource that the service acts on (which we refer to as the endpoint). 

The intent of the Description group is to use whatever definitions the Architecture group establishes. The current discussion is really based on reverse engineering concepts from WSDL 1.1. We felt it was useful to tighten up the definition of the <service> element of WSDL 1.1.

Arthur Ryman 



	"Newcomer, Eric" <Eric.Newcomer@iona.com> 


05/14/2003 06:37 PM 


        
        To:        Arthur Ryman/Toronto/IBM@IBMCA, <www-ws-desc@w3.org> 
        cc:         
        Subject:        RE: /service/@targetResource ? 

       


Arthur, 
  
First, it's important to stress that there still isn't consensus on this.  So I'm giving you my take, not the group view. 
  
Web services specifications are applications of XML.  Meaning SOAP, WSDL, etc. are defined using XML schemas, and use XML instances to carry data, etc. as everyone knows.  So there is a distinction in Web services between the XML applications and the underlying execution environment responsible for implementing the processing model.  The execution environment is not defined beyond stating processing model requirements.  One of the great benefits of Web services therefore is the capability of mapping them to virtually any execution environment. 
  
I like to draw the analogy with HTML, especially since XML is its sibling and a descendant of SGML.  In the HTML world a distinction is drawn between the document and the agent responsible for serving it.  I make the same argument for Web services, that the WSDL schema and corresponding XML document comprising the SOAP message are distinct from the agents responsible for generating/parsing/executing them. 
  
Many Web services toolkits implement the convention that the URI for the Web service points to the WSDL file.  Once the WSDL file is downloaded, you get within it the URI which is the network address at which the executable agent can be found, and often these are the same. 
  
I realize Web services break or distort many of the conventions and practices in the hypertext Web, but I believe it's important to draw the distinction between the XML documents that comprise Web services, and the agents that execute them, just as it's important to distinguish between HTML pages and Web servers. 
  
I also realize that Web services are inconsistent with some REST principles, and this underlies much of the debate and highlights the difficulties in coming to consensus.  In my view Web services extend beyond the Web since they are mapped to executable programs that are not part of Web infrastructure per se, and follow different and distinct use cases from REST.  Therefore there are good reasons for Web services to be inconsistent with REST, since the two are aimed at fulfilling different goals.  But you will no doubt get a debate about that as well...;-) 
  
Hope this helps clarify the thinking a bit. 
  
Eric 
-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com]
Sent: Wednesday, May 14, 2003 11:11 AM
To: www-ws-desc@w3.org
Subject: /service/@targetResource ?


In the discussion with the architecture group today, there seemed to be confusion between a service and the resource is acts on. The architecture group defines a Web service to have something that has a URI, but that URI is not the same as the resource that the Web service acts on. 

For example, a bank might have a personal banking Web service. The account Web service acts on the bank. 

We can build a URI from the QName of the personal banking Web service, e.g. http://xml.fredsbank.com#service(PersonalBanking). The bank itself might have the URI http://fredsbank.com. 

We agreed to add an optional @resource attribute to <service>. I suggest it would be clearer to rename that attribute to @targetResource to make it clear that the service acts on that resource as opposed to it being the URI of the Web service. 

Arthur Ryman