RE: UDDI's UUIDs issue

At Microsoft's implementation, you can do a poor man's UDDI GET today.  As
this behavior is not strictly specified, anyone could do this as well.  Here
are the relevant details found at the 5 Aug 2002 submission to Karsten's
blog  (http://www.gotdotnet.com/team/karstenj/blog.aspx)

	2002-08-05 - Providing Links to UDDI Entries
	Often times, it is quite handy to provide a link for your 
	UDDI entry to someone else. "Check out my tModel at http://..." 
	With the new user interface both on the Microsoft public node and 
	on the UDDI Services in Windows .NET Server, this ability has been 
	complicated by the use of frames. 

	However, one can still achieve this behavior of providing a link to 
	a graphic rendering of your UDDI entry. The following patterns can 
	be used for the different entities: in UDDI: 

	Business Key:
http://uddi.microsoft.com/details/businessdetail.aspx?key=ProviderGUID 

	Service Key:
http://uddi.microsoft.com/details/servicedetail.aspx?key=ServiceGUID 

	Binding Key:
http://uddi.microsoft.com/details/bindingdetail.aspx?key=BindingGUID 

	tModel Key:
http://uddi.microsoft.com/details/modeldetail.aspx?key=tModelGUID 

	In UDDI Services, the pattern holds true, but you would use 
	http://[server name]/uddi or http://[server name]/uddipublic as the
root, 
	depending on whether you were using Windows authentication or not.

	However, users following these links will lose the ability to
navigate, 
	as the navigation frames will be lost.

	Of course, to provide an XML representation of the entity, you can
use the 
	discoveryURL. The pattern for that syntax is as follows:

	http://uddi.microsoft.com/discovery.ashx?businessKey=ProviderGUID

	or for UDDI Services

	http://[server
name]/uddipublic/discovery.ashx?businessKey=ProviderGUID 

I also reference you to section 11.3.3 in the UDDI V3 spec where there is
some relevant discussion related to a specific tModel for the registration
of services that are to be accessed through HTTP GET.

Joel Munter
Intel

-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Monday, November 25, 2002 4: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 Wednesday, 4 December 2002 00:40:40 UTC