RE: UDDI's UUIDs issue

So Joel, are you saying that there is no reason to create a uddi: scheme?

I don't think that Karsten's explanation really addresses the core issue.
The tModelKey is supposed to be a URI. The current tModelKey is a UUID.
Although it's a unique identifier, it doesn't give you the ability to GET it
using simply the ID.

I think Paul has proposed that we use an http:// URI rather than invent a
new uddi: scheme to identify a tModel. The point I was making is that you
cannot do an HTTP GET on http://[tmodelname] to retrieve the tModel details.
You have to compose a fairly complicated composed URL (e.g.,
http://[server_name]/modelDetails.aspx/[uuid]) as decribed by Karsten below.

If we create a uddi: scheme, I can see the UDDI TC developing a mechanism
that would allow you to perform a GET on a uddi: URL and retrieve the
resource.

Anne

> -----Original Message-----
> From: Munter, Joel D [mailto:joel.d.munter@intel.com]
> Sent: Wednesday, December 04, 2002 12:39 AM
> To: Paul Prescod; Anne Thomas Manes
> Cc: www-ws-arch@w3.org
> Subject: 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 08:23:06 UTC