RE: On why services may not have URIs

WG, can you please put responses in terms of either
illustrating the current architecture document or suggesting
alternative wording?

Thanks
DaveH

-----Original Message-----
From: Daniel_Austin@grainger.com [mailto:Daniel_Austin@grainger.com]
Sent: Monday, April 21, 2003 3:48 PM
To: fgm@fla.fujitsu.com
Cc: www-ws-arch@w3.org; www-ws-arch-request@w3.org
Subject: Re: On why services may not have URIs




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 19:16:59 UTC