- From: <Daniel_Austin@grainger.com>
- Date: Mon, 21 Apr 2003 16:48:18 -0500
- To: fgm@fla.fujitsu.com
- Cc: www-ws-arch@w3.org, www-ws-arch-request@w3.org
Hi Frank, You are certainly correct in your statements (to the best o my own understanding) but it seems also to be true that while a composite service may have multiple URIs associated with it, it *must* have at least one that is specified as the "entry point" for the service. Multiple entry points may be present, but no less than one. Under that assumption, each service would have at least one URI associated with its entry point. Another related issue is that some services that form parts of composites may be behind a firewall or otherwise directly inaccessible, with the only entry point that of the composite. In this case, the "interior" services may very well not have a URI, or need of one. As for what's at the end of the URI: we can't leave this blank as the namespaces effort did. The service entry point(s) must have a well-defined interface, otherwise all is lost. Regards, D- "Francis McCabe" <fgm@fla.fujitsu. To: www-ws-arch@w3.org com> cc: Sent by: Subject: On why services may not have URIs www-ws-arch-reque st@w3.org 04/21/2003 04:02 PM 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:48:18 UTC