Re: On why services may not have URIs

Dave,

I think when I wrote that, I had misread Francis to be
equating agents with services, and my comment was intended
to clarify that the architecture doesn't make that equation.

But now I re-read Francis and I see he's got a one-to-many
relationship between agents and services, so in that model
obviously they are not the same.

I still don't get it, though.  Who would be requiring that different
services be map to different transport end-points?  (How did
transport end-points get in there, anyhow?)  And how does that
adversely affect customers w.r.t. requirements?

I think you could look at any deployed architecture and find
constraints that "don't necessarily reflect the customer's
requirements", at least the customer's functional requirements.
For example, what customer requires stateless interactions?
So, I'm not sure that's as bad as it sounds.

Walden
----- Original Message -----
From: "Dave Hollander" <dmh@contivo.com>
To: "Walden Mathews" <waldenm@optonline.net>; "Francis McCabe"
<fgm@fla.fujitsu.com>; <www-ws-arch@w3.org>
Sent: Monday, April 21, 2003 7:10 PM
Subject: RE: On why services may not have URIs


> Walden,
>
> You claim:
> > An agent is not a service.
>
> How can you support that? Is that said in our document or a cited
reference?
> Last I read, the relationship between agent->service->resource was still
> undefined.
>
> DaveH
>
> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Monday, April 21, 2003 3:25 PM
> To: Francis McCabe; www-ws-arch@w3.org
> Subject: Re: On why services may not have URIs
>
>
>
> > 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.
>
> Maybe the requestor's view is all that matters.
>
> >
> > 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.
>
> An agent is not a service.  The requirement is that each service be
> bound to an identifier.  How is that broken?
>
> >
> > 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 22:34:47 UTC