"The replication model
first assumes that all nodes are equal and have a complete replica of the
whole data set. The alternative to complete replication is a partioning
of the data across nodes, which is typically hieararchical. One assumption
in applying this a hiearchical model is that a root was agreed to and recognized
by nodes or registries in all of the branches. A second assumption
is that data can be scoped globally and that there is a sensible way to
seperate the data across registries according to a criteria that complements
the global scoping. While this type of heirarchical model has been
applied successfully to a data model with fixed data relationships such
as a key and a value with a self-regulating root used for partitioning.
DNS as illustrated below is a succesful example of this. I
would assert that the lack of a globally accepted root for directories
suchs as LDAP would indicate to me that it becomes more challenging to
apply it to a data model that allows for composite or complex queries.
Within an enterprise, ! it is often possible to establish such a
root, but deterministic query results (latency aside) accross the enterprise
becomes a significant technical challenge, as does establishing a sensible
data partition that will persist over time.
Since it is possible to inspect UDDI data along many facets, it seems a
difficult task to seperate a data set along one criteria, such as geographic
location of the servers. While this may be relevant to organizational
constraints, or relevant to a particular inquiry, it may not always be
relevant to a query based solely on technical criteria, such as implementation
of a particular Web service interface. Another illustration of this
is that a particular use of the data in UDDI might take advantage of a
particular taxonomy for discovery, such as geographic constraints, and
another use of data discovery may be business function related, and a third
type of discovery may be related to technical specifications and limitations.
It is further possible to combine several criteria which may typically
be independent of how data may be partitioned accross a hiearchical federate
registry or set of registries.
It has also been recognized that there still exists a need for several
different registries serving different purposes for discovery. As
an example, the UDDI Business Registry is an example of a registry that
could be considered a public "root", but it is not, obviously,
appropriate for discovery of internal enterprise services. This alone
means that it will be typical for at least two UDDI registries to be used
in discovery. It has been further recognized that in some cases the
data listed in a public registry could be the same data listed in an enterprise
registry. I would assert that it is not widely believed that service
discovery at the enterprise level should automatically federate results
from a global "root", at least in the public case.
Another consideration that fed into the V2 specification development was
the challenge in federating results according to different query criteria,
which may not map to the data partitioning criteria, and produce a complete
response in a timely manner. This was one of the primary design points
for designing a replication model for UDDI instead of a federated, or distributed
query model. A similar benefit of the replicated data model is that
read access to discovery data is redundant and available at all nodes should
a node become unavailable for a period of time.
For UDDI V1 and V2, the above assumptions
resulted in a decision to not pursue a model that required hierarchical
partitioning of the data. Going
forward, pushing all of the burden to a client to query multiple registries
in all cases has also been recognized as an issue that needed to be addressed.
There are certainly use cases where the V1 and V2 single registry
scoping of the data presents a significant burden for UDDI clients. Some
of this is addressed in V3 using registry affiliation where the administrators
of a given set of registries and the publishers of data in each of those
registries can use key partitions and certain keying policies to propogate
discovery data to other registries with a different scope of inquirers. |
|