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

Received on Monday, 25 November 2002 18:39:41 UTC