RE: On why services may not have URIs

Indeed, in reading the latest draft [1] there is an interesing
oversight and circular definitions. I think the note in 2.2.4
that says we need to resolve "agent -> resource -> service" 
almost become urgent to resolve.

daveh

2.2.9.2 on the relationship to identifier to other elements says 
"may be realized as a URI" 

	In 2.2.9.3 says "In the architecture we use Uniform Resource
	Identifiers to identify resources."

	BUT, the definition is circular-
		2.2.21 - "A resource is defined by [RFC2396] to be anything 
		that has an identifier.

should a web service defined to be a resource?

	BUT: section 5.2: is the lead paragraph normative? 

"The Web services architecture builds directly upon the Web Architecture
[7]. As such, the Web services architecture directly leverages the
definition of, and architectural constraints placed on, identifiers from the
Architecture Principles of the Web[7].

If so, should normatively reference external docs like architectural
principles?

Further is says "URIs MUST be used to identify all conceptual elements of
the system 
	(see Web Services Architecture Requirements: AR009.3)."
	Is the service itself a conceptual element of the system? If so, as
Francis
	asks, what it the element? The port, description or something else?




[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.htm
l

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
Sent: Monday, April 21, 2003 3:03 PM
To: www-ws-arch@w3.org
Subject: 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 18:02:43 UTC