RE: UDDI's UUIDs issue

I agree with you and urge you to forward the results of this thread directly
to the UDDI TC for their response and commensurate action.  As you know UDDI
began discussing this late in the V3 dialogues (afaik all UDDI Keys from V3
and up are already modeled as URIs) and I agree that HTTP GET support should
be considered for UDDI V4 work.
Joel

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Wednesday, December 04, 2002 6:26 AM
To: Munter, Joel D; Paul Prescod
Cc: www-ws-arch@w3.org
Subject: 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 09:03:55 UTC