OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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.


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


_____________________________________________
From:  Nobuyuki Tomizawa [mailto:n-tomizawa@ap.jp.nec.com]
Sent: Monday, December 02, 2002 05:04
To: uddi-dev@lists.oasis-open.org

Dear list:

I have a few of questions about UDDI V3 specification.

My personal interest is interoperability, especially in multi-nodes registry and registry affiliation.  The V3 specification is so thick that I spent long time (and also much paper to print it out :-) since it was out in this summer.  But I have found a few ambiguities mainly in replication specification in last weeks:

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".

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.

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 replication of UDDI data within a registry SHOULD be governed by information maintained within a Replication Configuration Structure. This structure MAY be contained within a Replication Configuration File.  The structure includes sufficient information to uniquely identify each node within the UDDI registry.  If used, each node within the registry MUST specify at least one contact as described below".  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.

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.

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)

Please clarify these my questions if someone knows details of the v3 specification.

Thanks in advance,

-- Nobuyuki Tomizawa



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC