RE: UDDI's UUIDs issue

It's been a long time since I read the UDDI spec so forgive me if this
explanation is somewhat off.

From what I remember UDDI doesn't strive to make the tModel directly
accessible. Of course this could be a document that is accessible elsewhere
using a real URL, maybe a WSDL document or a PDF. But that's not a UDDI
issue.

As far as UDDI is concerned, it you think you need a tModel that is because
UDDI told you about the tModel when it returns information about the UDDI
entry. And that is exactly how you get the tModel, so for UDDI purposes it
doesn't need to be accessible using a URI. UDDI doesn't prevent it from
being accessible, it just doesn't require that functionality.

However, it is possible that two entities reference the same tModel. You can
determine that in two ways. You can do a contents comparison, but that's
impractical. Or you can look at their identifier and compare it. If the
tModel is accessible and its URL is persistent than you can use that URL.

But UDDI wants to give you a mechanism that does not depend on a persistent
URL for the contents of the tModel to exist. UUID is an excellent mechanism
for being able to unambiguously identify two different tModels (or anything
else for that matter), has a big enough key space to be universally unique
and is persistent.

arkin


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Hugo Haas
> Sent: Wednesday, December 04, 2002 8:21 AM
> To: www-ws-arch@w3.org
> Subject: Re: UDDI's UUIDs issue
>
>
>
> * Anne Thomas Manes <anne@manes.net> [2002-12-04 08:25-0500]
> > 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.
>
> Karsten Januszewski's showed that there is a way to get a tModel using
> the existing http: scheme. Therefore, there is no need for a uddi:
> scheme.
>
> > 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.
>
> Creating a new URI scheme is very costly and should only be a last
> resort solution. Creating a uddi: scheme as a level of indirection to
> do an HTTP GET doesn't seem like a last resort solution to me.
>
> Regards,
>
> Hugo
>
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>

Received on Wednesday, 4 December 2002 12:18:55 UTC