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

RE: On why services may not have URIs

From: Dave Hollander <dmh@contivo.com>
Date: Mon, 21 Apr 2003 16:10:50 -0700
Message-ID: <BD52C6379806D51188DD00508BEEC96C012A0F2F@mail.contivo.com>
To: Walden Mathews <waldenm@optonline.net>, Francis McCabe <fgm@fla.fujitsu.com>, www-ws-arch@w3.org


You claim:
> An agent is not a service.  

How can you support that? Is that said in our document or a cited reference?
Last I read, the relationship between agent->service->resource was still


-----Original Message-----
From: Walden Mathews [mailto:waldenm@optonline.net]
Sent: Monday, April 21, 2003 3:25 PM
To: Francis McCabe; www-ws-arch@w3.org
Subject: Re: On why services may not have URIs

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

Maybe the requestor's view is all that matters.

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

An agent is not a service.  The requirement is that each service be
bound to an identifier.  How is that broken?

> 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 19:17:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:06 UTC