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