RE: UDDI's UUIDs issue

A tModel's key should be unique across all UDDI registries. The main reason
that UDDI used UUIDs as tModel keys was to ensure that each tModel does have
a unique key. So I do think that at some point (perhaps as early as V4) we
will devise a federated model, and you should to be able to perform a GET on
a uddi: scheme, without specifying the registry node, and manage to retrieve
the tModel.

Anne

> -----Original Message-----
> From: Paul Prescod [mailto:[email protected]]
> Sent: Monday, November 25, 2002 6:39 PM
> To: Anne Thomas Manes
> Cc: [email protected]
> Subject: Re: UDDI's UUIDs issue
>
>
> Anne Thomas Manes wrote:
>
> > Well for one thing, an http: URI lends the impression that you might
> > be able to perform an HTTP GET to get the resource identified by the
> > URI. But you can't do an HTTP GET on, say for example, a tModelKey.
>
> If you could do an HTTP GET on a tModelKey that would imply that every
> organization owned their own tModelKeys and that the system had no
> single point of failure. If you "discover" a tModelKey in some data, you
> could resolve it without trying to determine WHICH of the UDDI servers
> might be able to give you information about that UDDI.
>
> In other words, UDDI as it exist is designed to be a centralized system
> with hierarchical control when it should be a decentralized system where
> everybody controls their own information and anybody can become an
> aggregator of the information. examples of Web data aggregators include
> AltaVista, Google, Meerkat and Yahoo. So I'm not against
> registries/repositories. But they should
>
> The centralized model is architecturally unsound. And as far as I know,
> has no advantages whatsoever. (I'm open to arguments on that
> point, however)
>
> I'm sorry to venture towards conspiracy theories but I have to say that
> as far as I can see, the only reason someone would come up with such an
> architecture is because in the back of their mind they see UDDI as being
> analogous to DNS and they wish to be the NetSol or ICANN of UDDI. This
> will not work because it will not scale as well as the decentralized
> solution.
>
> > Currently, the only way to get the resource identified by a uddi:
> > scheme is to issue the proper UDDI Inquiry API (e.g.,
> get_tModelDetails).
>
> Not only issue the proper query, but to the proper UDDI server (or one
> in its federation. Given only a UUID or UDDI URI, you cannot know
> whether to use it inside the firewall or outside. (and which inside or
> outside).
>
> >  At some point in the future (maybe UDDI V4) the API might be extended
> > to allow you to do something like
>
> > a UDDI GET.
>
> IMHO, moving to a decentralized (not federated, but truly decentralized)
> model should be the highest priority of the UDDI V4 project. But it is
> your standard, not mine.
>
>   Paul Prescod
>