UDDI Spec TC

UDDI Version 2.03 Replication Specification

UDDI Committee Specification, 19 July 2002

Document identifier:

Replication_v2

Location:

http://uddi.org/pubs/Replication-V2.03-Published-20020719.htm

Latest version:

http://uddi.org/pubs/Replication_v2.htm

Editors:

Luc Clément, Microsoft

Contributors:

Robert Atkinson, Microsoft

Rainer Brendle, SAP

Pat Conley, Verisign

Shel Finkelstein, Sun

Tom Glover, IBM

Dan Guinan, Verisign

Andrew Hately, IBM

Yin Leng Husband, HP

Alan Karp, HP

Wooyoung Kim, HP

Christopher Kurt, Microsoft

Nicolai Jordt, SAP

Barbara McKee, IBM

Joel Munter, Intel

Andrew Nielsen, HP

Christian R Thomas, Intel

Acknowledgements:

The UDDI Spec TC recognizes the contributions of other participants from the UDDI.org Working Group:

Srikrishna Guttikonda, Ariba

UDDI Business Registry Operators Council

Abstract:

This document describes the data replication process and programmatic interface required to achieve complete data replication between UDDI Operators.

Status:

This specification has attained the status of OASIS Standard.

Committee members should send comments on this Committee Specification to the uddi-spec@lists.oasis-open.org list. Others should subscribe to and send comments to the uddi-spec-comment@lists.oasis-open.org list. To subscribe, send an email message to uddi-spec-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.

For information on whether any intellectual property claims have been disclosed that may be essential to implementing this Committee Specification, and any offers of licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (http://www.oasis-open.org/committees/uddi-spec/).

Copyrights

Copyright © 2001-2002 by Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved.

Contents

1 Introduction. 2

2 Concepts and Definitions. 2

2.1 Nodes, the Operator Cloud, and the UDDI Service. 2

2.2 Data Custody. 2

2.3 Update Sequence Numbers. 2

2.4 Change Records. 2

2.5 Change Record Journal 2

2.6 High Water Mark Vector 2

2.7 Time-based Elements. 2

3 Replication Configuration. 2

3.1 Replication Configuration File. 2

3.2 Configuration of Each Operator 2

3.2.1 SOAP Configuration. 2

3.2.2 Security Configuration. 2

3.2.3 Examples. 2

3.3 Control of the Node-to-node Communication Graph. 2

4 Replication Processing. 2

4.1 Replication Messages. 2

4.1.1 notify_changeRecordsAvailable Message. 2

4.1.2 get_changeRecords Message. 2

4.1.3 do_ping Message. 2

4.1.4 get_HighWaterMarks Message. 2

4.2 Bug detection and Processing. 2

4.2.1 Case 1: Invalid record validation. 2

4.2.2 Case 2: Invalid interim representation. 2

4.2.3 Case 3: Invalid generation. 2

4.3 Change Records. 2

4.3.1 ChangeRecordNull 2

4.3.2 changeRecordNewData. 2

4.3.3 changeRecordHide. 2

4.3.4 changeRecordDelete. 2

4.3.5 changeRecordPublisherAssertion. 2

4.3.6 changeRecordDeleteAssertion. 2

4.3.7 changeRecordCustodyTransfer 2

4.3.8 changeRecordAcknowledgment 2

4.3.9 changeRecordCorrection. 2

5 Bringing New UDDI Operators Online. 2

6 Checking and Validation of Replicated Data. 2

6.1 Data Validity. 2

6.2 Validity Checking and Enforcement 2

7 Auditing and Logging. 2

8 Resignation of Operators. 2

9 Reference Materials. 2

9.1.1 UDDI Specifications and documents. 2

9.1.2 Standards and other Specifications. 2

Appendix A: Miscellaneous Replication Example. 2

Appendix B: Miscellaneous Replication Configuration Example. 2

Appendix C: Non-normative – Cycle of Cycles Topology. 2

Appendix D: Notices. 2

1 Introduction

This document is one piece of the set of specifications that support the Universal Description, Discovery and Integration (UDDI) specifications. This document describes the data replication process and programmatic interface required to achieve complete data replication between UDDI Operators. The replication process makes use of Extensible Markup Language (XML) and a related technology called Simple Object Access Protocol (SOAP). SOAP is a specification for using XML in simple message-based exchanges.

The UDDI Version 2.0 Programmer’s Reference Specification provides a short introduction to the project and describes the public UDDI interfaces. This specification describes the interfaces required to perform all of the UDDI Operator to UDDI Operator communications.

The primary audiences for this specification are:

· Existing UDDI Business Registry Operators

· Prospective UDDI Business Registry Operators

· Prospective Private UDDI Operators that are interested in a replication protocol

Implementers will find information in this document that defines the required replication process protocol and recommended and required behaviors all UDDI Node Operators must implement as a part of their UDDI Services. The goal of these policies and behaviors is to ensure that the UDDI Service works smoothly, both for the user community as a whole, and for the individual operators.

The UDDI Version 2.0 Programmer's API Specification defines approximately 40 API messages that are used to perform inquiry and publishing functions against any UDDI-compliant Business Registry. This Replication Specification document also describes a set of API messages that must be supported by all UDDI Operators in addition to those messages specified within the API Specification. This document is also complementary to the UDDI Operators Specification.

Note: This document is a co-requisite to the UDDI XML Schema and to the UDDI Replication XML Schema document.

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119.

2 Concepts and Definitions

This section outlines the key concepts and includes in-depth technical descriptions involved within replication.

2.1 Nodes, the Operator Cloud, and the UDDI Service

There is an identified set of (operator) nodes involved in the operation of the UDDI Service. To the outside world, the cloud of Operator nodes should appear and act as a single service. Each Operator node within the UDDI Service will be identified within a Replication Configuration File. The contents and format of this configuration file are described later in this document.

An individual Operator node may be comprised of several physical computers but will be represented by one unique ID of type Universal Unique Identifier (UUID). Details specifying the format of the UUID can be found in the UUID Algorithm section in the UDDI Operators Specification. As is shown in the Replication Configuration file, one unique URL is specified to represent the replication point, soapReplicationURL for each Operator node.

A goal of UDDI replication is to ensure that, all nodes see all the changes that have originated at individual Operator nodes. An additional goal is that registry inquiries made at any Operator node within the UDDI Service yield results consistent to those made at any other Operator node within the UDDI Service. The response should be complete and sent to the caller as quickly as possible. This consistency is defined as a response comprised of the same businessEntities, businessServices, tModels, bindingTemplates, and publisherAssertions, sorted the same way. The consistency of the results is subject to any replication latencies.

Throughout this specification, when we are referring to aspects of the UDDI Service, we may refer to it as the UDDI Operator Cloud. This can be thought of as the collection of UDDI capabilities and services supported collectively by this set of Operators.

2.2 Data Custody

Each node has custody of a certain portion of the aggregate data managed by the UDDI Service. Each datum is in the custody of exactly one such Operator node. A datum can be a business entity, a business service, a binding template, a tModel, or an assertion within a business relationship. Changes to a datum in the UDDI Service can only be made at the node in whose custody the datum resides. Although Publishers initiate the changes by their inserts, updates, or deletes of the actual data, Operator nodes are said to “originate changes” for such data into the Replication stream.

The Operator node that is the custodian of a datum can be changed. The Change of Custody process utilizes a multi-step process and utilizes “replication” to accomplish the final steps within this process. The complete Change of Custody Process is defined within the UDDI Operators Specification.

2.3 Update Sequence Numbers

Each node shall maintain a strictly increasing register known as its Update Sequence Number (USN). The USN register must never decrease in value, even in the face of system crashes and restarts. The register must be sufficiently large such that register rollover is not a concern. For all Operator node to Operator node communications, Operators must implement a USN exactly 63 bits in size. Operator nodes must not rely on a USN value always increasing by exactly one. Gaps in an Operator node's USN sequence are explicitly permitted and are likely to occur in the face of system crashes and restarts.

While processing changes to the Registry all data must be ‘tagged’ with a unique USN register value. It is recommended that within an implementation, an Operator node would tag the new or updated record and then increment its USN register. This process would assure that the USN values remain unique.

Note that it is semantically meaningless to compare USNs that have been generated on different Operator nodes; only USNs generated on the same Operator node may be meaningfully compared to each other.

2.4 Change Records

When a publisher changes a specific datum at an Operator node, the Operator node will create a change record that describes the details of the change.[1] A datum can be a business entity, a business service, a binding template, a tModel, or a publisher assertion within a business relationship.

Each change record contains the following information:

· The UUID of the originating node on which the change record was initially created.

· An originating USN, with which the change record is tagged at its creation by its originating Operator node.

· A payload of data that conveys the semantics of the change in question. These shall be elaborated and fully specified later in this specification.

As a part of the replication process defined within this specification, change records are transmitted between Operator nodes. Each step of replication involves the transmission of such records from one Operator node to one other Operator node, say from Operator node M to Operator node N. As Operator node N receives change records from Operator node M, Operator node N tags each incoming record with a fourth piece of (Operator node-N-generated) information:

· A local USN.

Should the Operator node N elect to record its own change records within its Change Record Journal, the local USN and the originating USN values on the records are set to an identical USN value. Thus, all change records ever seen by a node can be time-ordered by sorting on their local USN.

As we shall see later, change records are always replicated to other nodes strictly in increasing order of the local USN of the node providing the changes. This property, together with the rules under which local USNs are assigned, provides the following guarantee: Suppose a publisher, whose data is held at node N, (that is, Node N is the custodian of that data) changes its data. Node N originates a change record c. Then it is guaranteed that any other node which receives change c will have previously received all changes which on node N had a local USN less than the local (and originating) USN of c. This, however, is true only of changes c that N originates. This is not true of arbitrary changes that N has seen from others.

This important cause and effect relationship is relied upon in several places in the design elaborated below, notably the algorithm by which information is ultimately deleted from the Service, and the algorithm by which custody of data is transferred from one operator to another.

2.5 Change Record Journal

Accurate replication of data throughout the UDDI Service relies on accurate and faithful creation, transmission, and retransmission of change records between all nodes of the UDDI Service. A change record originated by an Operator node is the authoritative document for information propagation. It is critical that change records are not inadvertently altered as they are conveyed from the originating Operator node through intermediate Operator nodes to reach other Operator nodes in the UDDI Service.

To that end, each Operator node should create and maintain as part of their internal implementation a change record journal that explicitly records verbatim the XML text of change records as they are received from other Operator nodes. This journaling may be performed before or after standard XML parsing of the change record. It is understood that standard XML parsing may remove leading and trailing white space. It is believed that this journaling will significantly enhance the overall quality of the UDDI Service.

Implementers may find it convenient to also place their own change records in their change record journal.

2.6 High Water Mark Vector

Each node maintains state information as a high water mark vector that contains the USN of the most recent change record that has been successfully processed from each operator. This vector has one entry for each node in the replication graph. Each entry contains the following information

· operatorNodeID, which contains the UUID of a node in the replication graph, and

· originatingUSN, which contains the operatorNodeID-specific USN of the most recent change that originated on operatorNodeID and which node N has successfully consumed. Since changes originating on a given node are always consumed in order, this will necessarily be the largest USN of any M-originating change that N has successfully consumed.

2.7 Time-based Elements

Instants of time are referenced throughout UDDI replication and within the Auditing process. These time stamps ensure that time changes were recorded consistently and are in the XML timeInstant format. See http://www.w3.org/TR/xmlschema-2 for the definition.

References to these time instants are found within the Replication Configuration File as well as many of the Audit requirements. The sections describing these data will detail more specific uses for the time instants they contain.

3 Replication Configuration

The replication of UDDI data is governed by information maintained within a UDDI Replication Configuration file. This file includes sufficient information to uniquely identify each Operator node within the UDDI Service. The custodian of the Replication Configuration File is the UDDI Operators Council. Each Operator must specify at least one contact as described below.

3.1 Replication Configuration File

The replication configuration of the UDDI Service is specified by an XML file kept at the location

https://www.uddi.org/operator/ReplicationConfiguration.xml

The XML schema definition describing the replicationConfiguration element is shown below. The root element of an instance document of this XML schema must be a replicationConfiguration element as defined in the UDDI v2 replication schema:[2]

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

A replicationConfiguration contains a serialNumber which is increased by at least one each time the published configuration is updated or changed. For the convenience of human users, the timeOfConfigurationUpdate identifies the time of the last update. The formatting of the timeOfConfigurationUpdate element is described later in this document. The councilContact identifies a party in the UDDI Operators Council who maintains and updates the Replication Configuration File.

Two new elements have been introduced in Version 2. The first new element, maximumTimeToSyncUBR, allows for the specification of when (in hours) a change made at any single node in the UDDI Business Registry is expected to be visible at all nodes within the UDDI Business registry. The second new element, maximumTimeToGetChanges, allows for the specification of the maximum amount of time (in hours) that an individual node may wait to request changes.

The Management of the Replication Configuration file is completely specified within the UDDI Operators Specification document. Members of the Operators Council must manage any and all changes to the contents of the Replication Configuration File.

The remaining elements in a replicationConfiguration are a list of the operators and established paths of communication between the Operator nodes. The communication paths and general replication topology considerations are discussed later in this document.

When the master configuration file is updated, existing operators are informed of the update by an out-of-band means not defined in this specification.

3.2 Configuration of Each Operator

Each current UDDI operator within the Service is identified with an operator element in the replicationConfiguration:

</sequence>

</complexType>

</element>

<documentation>For use in ‘operator’ attributes of businessEntities, etc.</documentation>

</annotation>

</simpleType>

<documentation>A UDDI Service-Level Operator Readiness state value</documentation

</annotation>

</restriction>

</simpleType>

<documentation>A UUID in DCE String Format</documentation>

</annotation>

</restriction>

</simpleType>

The operatorNodeID contains a UUID that is used to uniquely identify this operator throughout the UDDI Service. The contact or contacts listed provide information about humans who should be contacted in the face of administrative and technical situations of various sorts. The operatorCustodyName is the name used for the operator in ‘operator’ attributes of businessEntitys, tModels, and the like.

3.2.1 SOAP Configuration

In UDDI v2, node-to-node replication communication is carried out by means of SOAP messages and responses. The soapReplicationURL indicated in the operator element indicates where such messages should be sent to communicate with a given operator node. Specifically, in order to carry out a message invocation of type X with a given operator, a message is POST’ed to the URL documented within the Replication Configuration file. The type of message is indicated on the POST line. It is required (see below) that an operator’s soapReplicationURL indicate a secure HTTP connection.

For example, in order to invoke the message notify_changeRecordsAvailable to the operator whose soapReplicationURL is https://uddi.microsoft.com/SOAP/, an HTTPS POST beginning with the following should be made:

POST /SOAP HTTP/1.1

Host: uddi.microsoft.com

Content-Type: text/xml; charset=”utf-8”

Content-Length: nnnn

SOAPAction: “”

<?xml verson=”1.0” encoding=”UTF-8” ?>

<Body>

<notify_changeRecordsAvailable>

…

For more information regarding the use of SOAP within API messaging in UDDI, please refer to the UDDI Version 2.0 Programmer’s Reference Specification.

3.2.2 Security Configuration

Authentication of replication communication between nodes is carried out just as was done in UDDI v1.[3] Specifically, each node is required to be able to operate as both a Transport Layer Security (TLS) 1.0[4] client and a TLS 1.0 server with at least the following set of cipher suites:

· RC4 with 40-bit encryption and MD5 message authentication

· RC2 with 40-bit encryption and MD5 message authentication.

To effect this authentication, each operator is required to obtain an X.509v3 certificate. Full details of this certificate and the Certificate Authorities (CAs) can be found within the UDDI Operators Specification.

Operators must identify in their operator element the certificate they obtain from one of these CAs. Specifically, they must list the contents of the so-called ‘issuer name’ and ‘subject name’ attributes of the certificate in the (respectively) certIssuerName and certSubjectName elements of their operator element. If they wish, operators may place the full X.509v3 certificate they have obtained in a certificate element of their operator; this provides a handy and convenient place by which certificates can be (manually) located as new operators are brought online.

When communicating with another operator, each operator must validate the replication communications against this operator authentication identification found in the master configuration file. Certificate credentials presented over TLS must be validly used cryptographically, and, in addition, must match the (certIssuerName, certSubjectName) pair of one of the configured operators.

3.2.3 Examples

The following are examples of valid operator elements:

This first example shows an operator, “Microsoft Corporation,” with four separate Contacts.

<operator>

<operatorNodeID>3bbef815-df6a-484a-9d9f-afe470913566</operatorNodeID>

<operatorStatus>normal<operatorStatus>

<api_v2:contact useType="Customer Support">

<api_v2:personName>Microsoft UDDI Customer Support</api_v2:personName>

<api_v2:email>uddiExample@microsoft.com</api_v2:email>

</api_v2:contact>

<api_v2:contact useType="Operations Partner Support">

<api_v2:personName>Operations and Partner Support</api_v2:personName>

<api_v2:phone useType="Voice">800.555.8352 pin 1845992</api_v2:phone>

<api_v2:email>uddiOpsExample@microsoft.com</api_v2:email>

</api_v2:contact>

<api_v2:contact useType="Primary Contact for Critical Issues and Operations Management">

<api_v2:personName>Angela Mills</api_v2:personName>

<api_v2:phone useType="Voice">425.555.3447</api_v2:phone>

<api_v2:phone useType="Cellular">425.555.7048</api_v2:phone>

<api_v2:email>uddiAngela@microsoft.com</api_v2:email>

</api_v2:contact>

<api_v2:contact useType="Primary Contact for Critical Replication Issues">

<api_v2:personName>Joe Admin</api_v2:personName>

<api_v2:phone useType="Voice">425.555.3447</api_v2:phone>

<api_v2:phone useType="Cellular">425.555.7048</api_v2:phone>

<api_v2:email>uddiReplication@microsoft.com</api_v2:email>

</api_v2:contact>

<api_v2:contact useType="Secondary Contact for non-operational issues">

<api_v2:personName>Chris Kurt</api_v2:personName>

<api_v2:phone useType="Voice">425.555.5589</api_v2:phone>

<api_v2:phone useType="Cellular">630.555.8170</api_v2:phone>

<api_v2:email>uddiChris@microsoft.com</api_v2:email>

</api_v2:contact>

<operatorCustodyName>Microsoft Corporation</operatorCustodyName>

<soapReplicationURL>https://uddi.microsoft.com/SOAP/</soapReplicationURL>

<certIssuerName>OU=Secure Server Certification Authority, O=RSA Data Security, Inc., C=US</certIssuerName>

<certSubjectName>CN=UDDI.MICROSOFT.COM, OU=UDDI production site, O=Microsoft, L=Redmond, S=Washington, C=US</certSubjectName>

</operator>

This example describes an operator, “www.ibm.com/services/uddi,” with one valid Contact.

<operator>

<operatorNodeID>1b51ffea-9101-43d0-bab9-4c5791e102b1</operatorNodeID>

<operatorStatus>normal<operatorStatus>

<api_v2:contact useType="Operator Contact">

<api_v2:personName>Tom Glover</api_v2:personName>

<api_v2:phone useType="Voice">416.555.4220</api_v2:phone>

<api_v2:phone useType="Fax">416.555.4414</api_v2:phone>

<api_v2:email>uddiTom@us.ibm.com</api_v2:email>

</api_v2:contact>

<operatorCustodyName>www.ibm.com/services/uddi</operatorCustodyName>

<soapReplicationURL>https://www-300.ibm.com/services/uddi/replication/</soapReplicationURL>

<certIssuerName>CN=Equifax Secure E-Business CA-2, O=Equifax Secure Inc, C=US</certIssuerName>

<certSubjectName>EmailAddress=ibmuddi@us.ibm.com, CN=www.ibm.com/services/uddi, OU=IBM Global Services-Boulder, O=IBM Global Services, C=US</certSubjectName>

</operator>

This example describes an operator, “ariba,” with one valid Contact.

<operator>

<operatorNodeID>3d0bd27e-3df3-42d6-98ec-75a7a409bcaf </operatorNodeID>

<operatorStatus>normal<operatorStatus>

<api_v2:contact useType="Operator Contact">

<api_v2:personName>Ariba Network Operations</api_v2:personName>

<api_v2:phone useType="Voice">650-555-6200</api_v2:phone>

<api_v2:email>uddiOpsExampple@ariba.com</api_v2:email>

</api_v2:contact>

<operatorCustodyName>ariba</operatorCustodyName>

<soapReplicationURL>https://service.ariba.com/UDDIProcessor.aw/ad/</soapReplicationURL>

<certIssuerName>OU=Secure Server Certification Authority, O=RSA Data Security, Inc., C=US</certIssuerName>

<certSubjectName>CN=service.ariba.com, OU=Terms of use at www.verisign.com/RPA (c)99, OU=Ariba.com Network, O=Ariba Technologies, L=Sunnyvale, S=California, C=US</certSubjectName>

</operator>

3.3 Control of the Node-to-node Communication Graph

The master configuration file provides an optional means by which the inter-node replication traffic can be controlled and administered. This is done with the use of a communicationGraph element:

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

The communicationGraph element begins by explicitly listing the ID’s of the nodes currently involved in the overall replication communication. Each listed node ID must be operatorNodeID of some configured operator. At first glance, this listing of nodes might appear redundant with the prior listing of the operator elements; however, its presence carefully separates the control of communication with a node from other aspects of its configuration, such as the provision and dissemination of its security credentials.

Following the listing of nodes is the set of messages that this communication graph is intended to administer the control of. If a message element name is listed here, then such messages shall only be sent between nodes that are listed in the subsequent edges of the graph. In contrast, no communication restrictions are imposed on “replication protocol” message names not listed here.

After the nodes involved in replication communication are identified, the graph edges imposed on those nodes are listed. All node id’s listed in an edge must have been previously listed as valid in a node. Each edge in the graph is a directed edge, and indicates that only messages of the type explicitly listed as a valid message for the edge may be sent from the indicated messageSender to the messageReceiver. Restricted two-way communication between nodes must, if desired, be listed as a pair of edges with opposing directionality. A given directed edge may be listed at most once: for each edge, the pairing (messageSender, messageReceiver) must be unique over the entire set of edges of the graph.

For each directed edge, an ordered sequence of zero or more alternate, backup edges may be listed. Should a communications failure prevent message communication over the indicated primary edge, the backup edges may be tried in order until communication succeeds.

In the absence of a communicationGraph element from the replication Configuration file (recall that it is optional), all listed operator nodes may send any and all messages to any other listed operator.

The following is an example of a simple communicationGraph that restricts the invocation of get_changeRecords messages to a unidirectional-ring amongst a set of four nodes. In operational practice, it is expected that this get_changeRecords message will typically be the only UDDI replication message where communication restrictions are imposed. The introduction of communication restrictions on the notify_changeRecordsAvailable messages between operating nodes is not expected to be commonplace.

The communication graph described in the following example represents a spanning cycle topology. This is one of many possible topologies supported within this replication framework.

<communicationGraph>

<node>3bbef815-df6a-484a-9d9f-afe470913566</node>

<node>1b51ffea-9101-43d0-bab9-4c5791e102b1</node>

<node>3d0bd27e-3df3-42d6-98ec-75a7a409bcaf</node>

<node>3bbef815-df6a-484a-9d9f-afe470910320</node>

<controlledMessage>get_changeRecords</controlledMessage>

<edge>

<message>get_changeRecords</message>

<messageSender>3bbef815-df6a-484a-9d9f-afe470913566</messageSender>

<messageReceiver>1b51ffea-9101-43d0-bab9-4c5791e102b1</messageReceiver>

</edge>

<edge>

<message>get_changeRecords</message>

<messageSender>1b51ffea-9101-43d0-bab9-4c5791e102b1</messageSender>

<messageReceiver>3d0bd27e-3df3-42d6-98ec-75a7a409bcaf </messageReceiver>

</edge>

<edge>

<message>get_changeRecords</message>

<messageSender>3d0bd27e-3df3-42d6-98ec-75a7a409bcaf </messageSender>

<messageReceiver>3bbef815-df6a-484a-9d9f-afe470910320</messageReceiver>

</edge>

<edge>

<message>get_changeRecords</message>

<messageReceiver>3bbef815-df6a-484a-9d9f-afe470910320</messageReceiver>

<messageReceiver>3bbef815-df6a-484a-9d9f-afe470913566</messageReceiver>

</edge>

</communicationGraph>

4 Replication Processing

Replication processing consists of the Notification of changes that are available and then the subsequent “pulling” of changes from one of the Operator nodes within the Service. To improve the process of Replication as compared with Version 1, an Operator node can advertise that changes are available at that node. The advertisement of changes available includes sufficient information so that another Operator node within the Service can determine if and when it should pull the changes from the offering Operator node to itself for replication processing.

Replication should be configured so that in the absence of failures, changes propagate throughout the UDDI Service within a set amount of time. This requirement means that get_changeRecords requests may have to be sent in some scheduled manner.

For example, assume that the Communications Graph is a cycle of 4 operator nodes (A, B, C, and D) such that D places get_changeRecords request to C (D>C), C>B, B>A, and then finally A>D.

In this example, A starts the Replication process. Periodically, A generates a timer event and notifies B of its highWaterMark vector; if necessary, B issues a get_changeRecords request to A, and then sends C its highWaterMark vector. This continues around the cycle (B>A, C>B, D>C, A>D), but doesn't stop there. B has not received any changes from C or D for the current period, and C has not received any changes from D.

So A continues this algorithm around the cycle again (B>A, C>B, D>C). At this point, all changes that existed when A handled its timer event have been circulated to all nodes. (Subsequent changes may have also been propagated, which is okay.)

Please refer to Appendix C for a non-normative discussion about a variation on the topology just discussed.

Operators may find it advantageous to do local optimizations of changes prior to replicating the changes throughout the UDDI Service. Any local optimizations performed must be invisible to other operator nodes.

4.1 Replication Messages

As was previously mentioned UDDI Version 2 replication is carried out solely through the exchange of SOAP messages between nodes rather than the maintenance and transfer of files as was done in UDDI Version 1; these messages are specified below. Various details of several aspects of SOAP usage are the same as those discussed in the UDDI Version 2.0 Programmer’s Reference Specification, Appendix B.

Processing an inbound replication message may fail due to a server internal error. The common behavior for all error cases is to return an ‘E_fatalError’ error code. Error reporting SHALL be that specified by Section 5.1.2 Error reporting with the dispositionReport element of the UDDI Programmer’s API Reference specification as follows:

<?xml version="1.0" encoding="UTF-8" ?>

<Body>

<Fault>

<faultcode>Server</faultcode>

<faultstring>Server Error</faultstring>

<errInfo errCode=“E_fatalError">The changeRecord type

is not unrecognized: XYZ</errInfo>

</result>

</dispositionReport>

</detail>

</Fault>

</Body>

</Envelope>

4.1.1 notify_changeRecordsAvailable Message

A means is provided by which nodes can inform other nodes that they have more change records newly available for consumption by replication. This provides a non-polling means by which replication can be initiated, potentially reducing the latency of the dissemination of changes throughout the set of UDDI operators.

At an interval deemed appropriate by the operator after the origination of new change records within its node, it should invoke this message on each of the other nodes with which it may legally communicate this message according to the currently configured communicationGraph.

</sequence>

</complexType>

</element>

A node MUST respond with a disposition report with the E_success error code when a valid notify_changeRecordsAvailable message is received. Success reporting SHALL be that specified by Section 5.1.2 Error reporting with the dispositionReport element of the UDDI Programmer’s API Reference as follows:

<?xml version="1.0" encoding="UTF-8" ?>

<Body>

</result>

</dispositionReport>

</Body>

</Envelope>

The parameter to the notify_changeRecordsAvailable message indicates that the notifyingNode has available the indicated set of changes for request via get_changeRecords. When sending this message, a node shall provide a high-water mark vector identifying what changes it knows to exist both locally and on other nodes with which it might have had communications. This get_changeRecords message, like the other messages described herein, is subject to communication restrictions imposed by the configured communicationGraph. Typically, no such restrictions are present for the notify_changeRecordsAvailable message.

</sequence>

</complexType>

</sequence>

</complexType>

Operators must perform a get_changeRecords replication message within the time frame defined by the value of the maximumTimeToGetChanges element defined within the Replication Configuration File. Thus, change data can always be propagated throughout the UDDI Service within a finite amount of time, while at the same time changes will often propagate quickly.

The following is an example of a notify_changeRecordsAvailable message:

<notify_changeRecordsAvailable>

<notifyingNode>1b51ffea-9101-43d0-bab9-4c5791e102b1</notifyingNode>

<changesAvailable>

<highWaterMark>

<nodeID>1b51ffea-9101-43d0-bab9-4c5791e102b1</nodeID>

<originatingUSN>123</originatingUSN>

</highWaterMark>

<highWaterMark>

<nodeID>3bbef815-df6a-484a-9d9f-afe470913566</nodeID>

<originatingUSN>241</originatingUSN>

</highWaterMark>

<highWaterMark>

<nodeID>3d0bd27e-3df3-42d6-98ec-75a7a409bcaf</nodeID>

<originatingUSN>193</originatingUSN>

</highWaterMark>

</changesAvailable>

</notify_changeRecordsAvailable>

4.1.2 get_changeRecords Message

The get_changeRecords message is used to initiate the replication of change records from one node to another. The caller, who wishes to receive new change records, provides as part of the message his current high water mark vector. This is used by the data source Operator node to determine what change records satisfy the caller’s request.

<element