Distributed Registry Proposal Approach

[Mike Rawlins <rawlins@metronet.com>]

I sometimes feel a bit silly and pedantic for always getting back to
basics.  However, even more than that I am amazed how often it seems
appropriate.  I'm sure that you all have much more experience and
expertise in the registry area than I.   However, I nonetheless offer a
few observations and suggestions before I leave this problem in your
capable hands.

Observation 1:  This is not a new problem.  The distributed registry
problem is essentially a special case of the well-known distributed
database problem.

Suggestion 1:  Don't reinvent the wheel.  Several proven approaches
already exist.  Pick one.

Observation 2:  Without a set of constraints (non-functional
requirements) and their relative priorities there is no basis for
picking one approach over another.

Suggestion 2:  Achieve consensus on constraints before even considering
an approach.  None of your documents to date address constraints and
relative importance such as response time, integrity, etc.  A few have
been mentioned in this discussion, and there are several in the ebXML
Requirements Spec.  Decide *what* you need first, then decide *how* to
do it.

Observation 3:  You need to do no homework to know that your highest
priority constraint now is time.  [Scott, you want to remind your team
what the drop dead date is?]   Opinion:  You have barely enough time to
agree on an overall approach for a fully distributed, transparent
network of registries, not to mention fully flesh it out.

Suggestion 3:  Go for a two phase approach:  Phase one as a
registry/directory/list of registries using best available technology,
completed within the time constraints;  Phase two as the fully
distributed network of registries.

Proposal:  For phase 1 use UDDI as the registry of registries (I am even
more amazed to find myself agreeing with Klaus!).   This, to me, has the
best chance of satisfying your highest priority constraint.  It also has
marketing/mindshare advantages which, while they aren't strictly
speaking technical constraints, certainly are important.

Y'all have fun.

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/