[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]Re: UDDI (was Re: Our blindspot)

From: John
Subject: [DotGNU]Re: UDDI (was Re: Our blindspot)
Date: Wed, 13 Feb 2002 14:20:16 -0600

Norbert Bollow wrote:
>I'm not sure that UDDI will
> take off in the first place (who would want to use it, and
> why?), and it if starts getting popular, what prevents us from
> using the existing free UDDI implementation to create an
> alternive, free-software-only registry?

If I can draw a parallel; .Net is a component model for the web. Each
"web application" is a component. Each communicates with other
components on other machines. Component models require a "registry" in
some shape or form. UDDI is the language in which the web registry is
written, and the UDDI server is the registry itself. I don't necessarily
say we need a our own registry language, but we do definitely need to
provide a non-centralized registry server of our own.

Technically, the reason is obvious. Windows registry: centralized, one
file; bad, unstable, single point of failure. Unix "registry": multiple
decentralized files; good, one bad file doesn't bring down anything but
the one subsystem associated with it. The same can be extended to web
components: a centralized registry is bad, a distributed one is good.

The issue of Freedom also figures into the call for development of an
UDDI server. Without a registry, one web component does not know how to
"talk" to another, or even where the "other" can be found. Suppose that
the UDDI partners were able to ban services written under DotGNU from
registering in the current central UDDI registry? They'd be able to
prevent interoperation, since other company's customer's web components
could never find our customer's web components. With no-one to talk to
our web components, we die.

Does any of this make sense?

John Le'Brecage

reply via email to

[Prev in Thread] Current Thread [Next in Thread]