RE: On why services may not have URIs

Frank is totally on the mark here.  We waffle on this.  To be very specific,
we can say things like "Web service endpoints have URIs", or "Web service
descriptions have URLs via namespace names" or "Web service description
services have QNames".  Imagine the case where a Web service has 2 endpoints
that are equivalent entry points, and they are different because of the need
for different bindings.  The web service, aka ultimatereceiver, does not
have it's own URI anywhere in WSD or SOAP.  The endpoints have URIs, the wsd
file has a namespace name,

What a muddle.  I want to be able to saying things about the equivalence of
endpoints, but that seems to drag us to talking about the web service behind
the endpoint.  Which leads to the agent/web service discussion.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Francis McCabe
> Sent: Tuesday, April 22, 2003 9:09 AM
> To: Daniel_Austin@grainger.com
> Cc: www-ws-arch@w3.org; www-ws-arch-request@w3.org
> Subject: 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 Thursday, 24 April 2003 14:33:47 UTC