- From: Anne Thomas Manes <anne@manes.net>
- Date: Mon, 25 Nov 2002 18:55:46 -0500
- To: "Paul Prescod" <paul@prescod.net>
- Cc: <www-ws-arch@w3.org>
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:paul@prescod.net] > Sent: Monday, November 25, 2002 6:39 PM > To: Anne Thomas Manes > Cc: www-ws-arch@w3.org > 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 >
Received on Monday, 25 November 2002 18:53:24 UTC