These dynamic find and bind operations are the foundation of the loosely-coupled nature of Web services. The application is then free to invoke any or all of the Web services found. Because they all implement the same tModel, and the tModel refers to a WSDL service interface definition, the application can use a single service proxy as a front-end to the RFQ Web service of any business partner selected by the find operation. Due to the possible volume of data and the replication semantics imposed by the operator-agreement, operator cloud nodes must be designed to optimize data throughput. Private nodes are free from this restriction, but the intended use of private nodes encourages other design tradeoffs.
Private nodes have several distinguishing characteristics.
They can be lighter weight, they do not have to implement the replication API, and their transaction volumes are significantly less than operator nodes. Some large organizations may choose to implement private nodes as a federation of nodes, in which case a replication model may be required. The UDDI spec was written to support use-cases related to the single UDDI operator cloud. When we introduce additional species of UDDI, all which are private nodes that do not collaborate using the replication agreement, we must clarify how information can be shared between private nodes. Additional UDDI functionality This article proposes an additional set of functions based on the standard UDDI APIs that address the management of collaborations among private UDDI nodes, and between private UDDI nodes and the UDDI Business Registry.