Re: On why services may not have URIs

Daniel:
   In my understanding, how a service is implemented is none of our 
business. That means that any service can act as a front-end to other 
services. However, that isn't the same as a composite service.

   The upshot is that we need significant clarity about what the name of 
a service actually is. A composite service may have any number of 
`entry points', any of which may be realized by different `component 
services'. Also, a key point here is that a requester may get a reply 
from a different source than where it made its request: and this should 
not have to come as a surprise to the service requester.

   It has been suggested to me that the resource identified by a 
service's URI could be its description. I am a little uncomfortable 
with that; it strikes me as being a little `cute'; certainly until we 
have sufficient specs in place so we can describe services properly.

Frank

On Monday, April 21, 2003, at 02:48  PM, Daniel_Austin@grainger.com 
wrote:

>
>
> 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 Tuesday, 22 April 2003 12:11:24 UTC