W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2003

Re: On why services may not have URIs

From: Jon Dart <jdart@tibco.com>
Date: Mon, 21 Apr 2003 14:58:31 -0700
Message-ID: <3EA46987.8020505@tibco.com>
To: Francis McCabe <fgm@fla.fujitsu.com>
CC: www-ws-arch@w3.org

I would add that trying to coerce non-HTTP address information into the 
format of a URI is often not easy.

The WSIF WSDL extension to support JMS
(http://ws.apache.org/wsif/providers/wsdl_extensions/jms_extension.html#N10017)
uses a complex jms:address element to represent an address.

You could munge this into a single URI somehow if you really wanted to, 
but it wouldn't be pretty.

--Jon

Francis McCabe wrote:
> 
> Just to throw more petrol on the fire, I need to bring the group's 
> attention to another issue.
> 
> A core principle seems to have always been that Web services are 
> identified by URIs. So, one question that may be asked is
> 
> "What resource is identified by this URI?"
> 
> A simple answer might be the software agent that provides the service. 
> Another possible answer includes the document describing the service.
> 
> The utility of the first would be that the transport end-point for a 
> message could be identified with the service being offered by the 
> computational process lurking behind it.
> 
> However, in the case of a composite service, there may not be a single 
> transport end-point associated with it. Consider the 
> Request/Subscribe/Publish model in which separate entities manage the 
> subscriptions from the publications. It is all one service (from the POV 
> of a requestor) but not from the provider's POV.
> 
> In addition, a given agent may be offering several services; and 
> requiring that the agent map those into different transport end-points 
> imposes an architectural constraint on the implementation that doesn't 
> necessarily reflect the customers requirements.
> 
> The other possible answer is that the service URI points to the 
> description of the service. However, we have always said that service 
> descriptions MAY be formally expressed, not MUST be. I.e., there may not 
> be anything to GET at the end of the service URI.
> 
> In effect, we can say nothing about the resource identified by the URI. 
> This is reminiscent of the XML namespace URI.
> 
> Comments?
> 
> 
> 
Received on Monday, 21 April 2003 17:58:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:18 GMT