W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2003

Re: Fw: Naming a Web service resource

From: Anne Thomas Manes <anne@manes.net>
Date: Tue, 8 Jul 2003 10:21:32 -0400
Message-ID: <001401c3455c$57e689e0$f602a8c0@TPX21>
To: "Ugo Corda" <UCorda@SeeBeyond.com>, "Www-Ws-Arch@W3. Org" <www-ws-arch@w3.org>, "Paul Denning" <pauld@mitre.org>

While I agree that you need a mechanism to distinguish the various nodes of
the UBR, don't you think it's also useful to be able to refer to the
multi-node service as a single entity? I'd say that each of these entities
(the collective entity and each node) requires it own name, e.g.:

I'd say that the UBR presents a very interesting use case, and our
requirements should address this use case.


----- Original Message -----
From: "Ugo Corda" <UCorda@SeeBeyond.com>
To: "Anne Thomas Manes" <anne@manes.net>; "Www-Ws-Arch@W3. Org"
<www-ws-arch@w3.org>; "Paul Denning" <pauld@mitre.org>
Sent: Monday, July 07, 2003 9:12 PM
Subject: RE: Fw: Naming a Web service resource

> > So let's look at Paul's example: What is the URI that repesents the UDDI
> > Business Registry (UBR)? The UBR is a Web service. It just so happens
> > there are four nodes in this Web service, but regardless which node you
> > access, you will always get the same response from any one of these four
> > nodes. So the four nodes do in fact represent a single Web service.
> The UBR example is interesting because the four nodes do not always
represent the same information, because of replication latency. So there are
some times (during a latency period) when the same request gets different
responses when applied to different nodes, revealing an internal behavior
not fully expressed by the simple service URI.
> So I find Frank's approach more satisfying in that respect, because it
would allow me to describe this particular semantics in a way that cannot be
fully accounted for by the service URI.
> I suspect there are many Web services that might first look easily
describable via a service URI but, when examined more carefully, reveal
special application-specific semantics that cannot be adequately captured by
the concept of service URI.
> Ugo
Received on Tuesday, 8 July 2003 10:22:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC