On why services may not have URIs

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:03:03 UTC