Re: UDDI's UUIDs issue

Anne Thomas Manes wrote:

>  ...

>
> 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.

Yes.

> You have to compose a fairly complicated composed URL (e.g.,
> http://[server_name]/modelDetails.aspx/[uuid]) as decribed by Karsten 
> below.

Just to be clear: Any particular tModel should be fetchable on N 
different URIs, so there is no single point of failure. The "canonical" 
URI would be on the website of the organization that invented the 
tModel. Just as corporations publish WSDLs, they would publish tModels. 
Just as individuals publish vCards, home pages and FOAFs, they would 
publish tModels.

A UDDI registry would become a cache of these tModels. It could be 
constructed either by spidering the Web (as per Google) or through 
explicit contributions (as per Yahoo). The contributions service would 
of course be a web service. To fetch a tModel from its source, you would 
just do:

GET http://www.myUUDI_server/mytModel

Then, to fetch a cached tModel URI, you would do:

http://someUDDI_server/modelDetails.aspx?url=http://www.myUUDI_server/mytModel
http://anotherUDDI_server/modelDetails.aspx?url=http://www.myUUDI_server/mytModel

But you would only do this as a backup when the original site was down. 
Otherwise why wouldn't you get the information from the horse's mouth?

> 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.

How would it be easier to perform a GET on a "uddi:" URL than on an HTTP 
URL? There are already hundreds of toolkits out there that now how to do 
the HTTP URL fetch and 0 that know how to do the uddi URL fetch.

  Paul Prescod

Received on Wednesday, 4 December 2002 22:03:31 UTC