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

Re: Fw: Naming a Web service resource

From: Fred Carter <fred.carter@amberpoint.com>
Date: Tue, 08 Jul 2003 10:18:31 -0700
Message-ID: <3F0AFCE7.5040401@amberpoint.com>
To: Anne Thomas Manes <anne@manes.net>
CC: "Www-Ws-Arch@W3. Org" <www-ws-arch@w3.org>, Paul Denning <pauld@mitre.org>

+1

To the "general public", all the UBR nodes are equivalent.  Yes, at 
times, there may be differences between the nodes due to latency, etc., 
but the same may be true for ATM's at your bank.  Nonetheless, under 
normal circumstances, they are viewed as interchangeable.

For certain special purpose operations where some 'more knowledgeable' 
entity interacting with the UBR, then that entity may make use of this 
deeper understanding of things. E.g. if I (assuming I'm a 'more 
knowledgeable entity' :-/ ) register some new service with the UBR, I 
may want to know the site at which I registered -- first, so I can check 
"immediately" afterwards to make sure it worked ('more knowledgeable, 
not more trusting) and second, so that after some prescribed latency 
period, I can check the 'others'.  But that's not a 'normal' thing. 
Most requests, assuming the UBR is worth having, will be lookups, and 
mere mortals will not tend to look everywhere and compare notes.

I rather like the comparison to namespaces -- it isn't a namespace /per 
se/, but it is a moniker which identifies the 'collected stuff' on which 
the service operates (desparately attempting to avoid the 'resource' 
word).  Whether it has a representation is a subject that can be left -- 
some sites may choose to materialize a description, free text, or some 
standard may be developed which gives some more formal meanting. 
Nonetheless, there's a way to link things together.

/fred

Thus quoth Anne Thomas Manes (~ 08-Jul-03 7:21 AM ~)...
> 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.:
> http://www.uddi.org/ubr
> http://www.uddi.org/ubr/ibm
> http://www.uddi.org/ubr/microsoft
> http://www.uddi.org/ubr/sap
> http://www.uddi.org/ubr/ntt
> 
> I'd say that the UBR presents a very interesting use case, and our
> requirements should address this use case.
> 
> Anne
> 
> ----- 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
> 
> that
> 
>>>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
>>
> 
> 


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301
Received on Tuesday, 8 July 2003 13:18:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:21 GMT