RE: /service/@targetResource ?

Does the value of wsdl:definitions/wsdl:service/@targetResource relate
to the SOAP 1.2 @role?

 

________________________________

From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
Sent: Wednesday, May 14, 2003 3:37 PM
To: Arthur Ryman; www-ws-desc@w3.org
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