RE: [uddi-dev] Questions on V3 specification.

[Nobuyuki Tomizawa <n-tomizawa@ap.jp.nec.com>]

Title: メッセージ

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.