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 17:24:48 UTC