uddi-dev message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [uddi-dev] Questions on V3 specification.
- From: "Munter, Joel D" <joel.d.munter@intel.com>
- To: Nobuyuki Tomizawa <n-tomizawa@ap.jp.nec.com>, uddi-dev@lists.oasis-open.org
- Date: Tue, 03 Dec 2002 06:09:10 -0800
Title: メッセージ
tomizawa-san,
as we were
writing the replication of the specification, we maintained an
informal policy of specify as little as we need to. much of the
processing of the replicationConfiguration element is wrapped into the the
actual implementation itself. as such, we intentionally did not specify
much of what you ask for below. we believed that this does not impact
interoperability within a registry. the handling of the
replicationConfiguration may very well be automated but that does not directly
imply that is needs to be specified.
with no
commmunicationGraph specified, any node MAY communicate any message with any
other node. this does not imply that there is no control. there are
suggestions that have been included within the specification that describe a use
of the communicationGraph that "orders" the minimum set of messages that we
believed eliminated some potential areas where interoperability issues might
occur.
when
setting up a multi-node registry, "communication" between node operators is
required. making simple decisions like the ones described in your
questions and luc's replies is a natural step in this
process.
modeling an "ack" as a change record made sense to us. again,
we believed that this would simplify the processing of "changeRecords." if
an "ack" is requested, it is required to propagate the "ack" to the
originator. there are many ways that this could occur. if the
communicationGraph is not constrained then the receiver MAY send a "ack"
directly back to the originator. or the "ack" could make its way back to
the originator via other means. we believed that it made more sense to
simply add this to the stream and process normally (that is according to a
directed and controlled communicationGraph). the other end of the spectrum
to this is to allow, plan, and test for communications between any node at any
time for any message.
i hope
that these (historical) thoughts help you.
joel
munter
intel
corporation
Thank you very much for your quick response, Luc san
!!
1) The acknowledgment of change
record is also represented as one of the ChangeRecord data. But, because
the ack should be propagated to the originated node, this means that topology
of the replication is something like cyclic (or, in another words, all nodes
are 'strongly connected' in graph theory jargon.). Is that what the spec
means (implicitly)?
[LC]
What controls the topology is the replicationConfiguration (see section 7.5.3
of http://uddi.org/pubs/uddi_v3.htm), and specifically,
the communicationGraph. It is used to control (or not) to which node
identified in the replicationConfiguration changeRecords are exchanged.
"In the absence of a communicationGraph element
from the Replication Configuration
Structure, all nodes listed in the node element MAY send any and all messages
to any other node of the registry".
What should nodes in a registry do with no
communicationGraph specified? It seems for
me that no control over communication structure in the registry
may break the assumption that all nodes in a registry have same
content even if all nodes behave in conformance with V3 spec (because what
nodes should do is NOT specified). If the spec requires implementation (of
nodes) to have same contents in one registry, I think the spec also should
show what should each node do.
Acknowledgments are
inserted into the replication stream like any other changeRecord by a node; as
such every other node will see all acks by virtue of consuming the replication
stream. When the originating node (the one that requested the ack) has
received an ack from each of the nodes identified in the
replicationConfiguration, then it can consider the changeRecord
acknowledged.
As such,
the ack is not propagated "to the originating node"; rather it is inserted
into the replication stream for the originating node (and any other) to
consume.
You mean that it's OK
(under the spec) if the topology is configured NOT to propagate acks back
to the originating nodes ?
I'm not sure, but I feel the
spec and some algorithms described in it require that acks come back
(eventually).
Are there any assurance that
the some properties described in the spec (like "all nodes in the registry have
same contents") is held?
2) Does only one node maintains
replication configuration, or a few of nodes can maintain it? XML Schema
chart of replicatonConfiguration shows that "replicatonConfiguration" element
can one or more "registryContact" elements. But maintaining replication
configuration by two or mode nodes seem to complicate the replication
protocol, because potentially two or more nodes try to change replication
topology at the same time.
[LC] How the replicationConfiguration is managed and
exchanged is outside of the spec. The use of a replicationConfiguration is
optional (from 7.5.1): ...
The (original) point I want to say
is:
How many nodes can maintain the
replicatonConfguration (if
used)?
I guess the registryContact element in the
repilcationConfiguration is used to specify who maintain the
replicationConfiguration.
The chart in P193 in v3 spec says maintaining node
could be one or more because registryContact element has "+" mark. But, in the
same page, the spec said "The registryContact identifies a party .." and
also, XML schema for replication says replicationConfiguration has just one
registryContact element. It seems
inconsistent.
Section
9.6.5 makes replication policy recommendations. That said, the serialNumber
element is used to control versioning of the configuration and a
digitalSignature used to protect against tampering.
As a practical
example, the UDDI Business Registry maintains the replicationConfiguration in
a file that is versionned control and mutually agreed to. Once a change is
made to the configuration, it is communicated to all operators and its
implementation is coordinated.
Is this process is
automated (fully or partially) between nodes in the UDDI Business
Registry?
If so, that is what I wanted
to see in the spec. If automation process differs in vendors or its
implementation, it difficult to make multi-vendor-nodes
registry.
3) How changes to
replication configuration are notified to the other nodes and propagated to
them? I could not found the explicit descriptions of means to notify and
propagate the change of replication configuration in V3 spec. (Also, "the
communication" in pp. 197 line 17 is not concrete, I think.)
Unfortunately, 'V2' specification said that was done by "an out-of-band means not
defined in this specification" (i.e. V2 Replication Specification). If
it's same in V3 spec, I think it hard to build multi-vendor/multi-nodes
registry. Is it out-of-scope of the specification?
[LC] As indicated above this is out-of-scope for the
specification given that the use of the replicationConfiguration is
optional.
So you mean that how the
changes notified and propagated to the other nodes in the
registry will NOT be specified in the spec even when the
replicationConfiguration is used? I hope even "recommended way" specified in the
spec gives great help for interoperability between nodes in a
registry.
I'd like to add that
should this need to be addressed, guidance could be provided in the form of a
Technical Note (http://www.oasis-open.org/committees/uddi-spec/tns.shtml)
Great. This will help all people, including me,
who interested in UDDI (especially in its replication), I
think.
-- Nobuyuki Tomizawa
P.S. Sorry if my English can not make my points
clear.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC