RE: [uddi-spec] FW: UDDI's UUIDs issue

[Andrew Hately <hately@us.ibm.com>]

From Ugo's note:

>>>The number of unresolvable URIs
for the discovery data returned by search engines listed below are an example
of what happens when discovery is decentralized. 
>It does not seem that UDDI itself has
done much better so far. See for example [1].
 
>Ugo


It appears I used too brief an explanation.
 Perhaps I should avoid making the direct analogy between web page
search engines and search engines for discovery data.

My reference to unresolvable information
was intended to apply to the ability to resolve the UDDI discovery data
itself.  The challenge in distributing discovery information is that
it might not be possible to retrieve all of the relevant discovery meta-data
in the first place.  Consider the case where an interesting business
is discovered using UDDI businessEntity meta-data, but the technical tModel
meta-data resides on a different server that can be resolved.  It
is convenient to have access to a complete set of the UDDI meta-data  The
issue of resolving links within the UDDI meta-data itself is no different
in either scenario, distributed or centralized.

Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies 
Internet: hately@us.ibm.com

Andrew Hately/Austin/IBM@IBMUS

12/04/2002 03:30 PM

To	Ugo Corda <UCorda@SeeBeyond.com>
cc	Uddi-Spec <uddi-spec@lists.oasis-open.org>
Subject	RE: [uddi-spec] FW: UDDI's UUIDs issue

The idea that the registry presents a particular and complete and reliable
set of the data in response to find_** APIs makes it very difficult to
decentralize the UDDI data. 

The number of unresolvable URIs for the discovery data returned by search
engines listed below are an example of what happens when discovery is decentralized.
  An unreliable discovery system is, in my opinion, not suitable for
any machine processing. 

The third party aggregation model can still be built on a centralized system
to provide more efficient query capability than that provided by the UDDI
find_** APIs, but the intention is that the UDDI find_** API and subscription
API can help build those systems on a particular registry's or registries'
data set. 

Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies 

Internet: hately@us.ibm.com

Ugo Corda <UCorda@SeeBeyond.com>

12/04/2002 01:13 PM

To	Andrew Hately/Austin/IBM@IBMUS
cc	Uddi-Spec <uddi-spec@lists.oasis-open.org>
Subject	RE: [uddi-spec] FW: UDDI's UUIDs issue

Hi Andrew, 
  
Thank you for your extensive response. I still have the impression that
it does not completely address Paul's point: 
  
> UDDI ... 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. 
  
What exactly prevents the third party aggregation model proposed above
from being applied to UDDI? 
  
Thank you, 
Ugo