Happy Halloween, and welcome to the final installment of changes to Universal Description, Discovery, and Integration (UDDI) 3.0. To finish our examination of the specification, let's look at three areas in which UDDI 3.0 is improving UDDI registry management: by changing custodianship and ownership of a registry, by supporting caching of credentials used for external validation, and by various changes to the registry replication schema.
Typically, a publisher who creates an entity in the UDDI registry is the owner of that entity and controls it. The node in which the publisher creates an entity is the custodian of that entity. Custodian nodes are responsible for a registry's integrity and thus regulate who's allowed to change entities in a registry. If multiple nodes house a registry, all the nodes can share one set of security policies; alternatively, each node might use its own security policies to control registration, authentication, and authorization. Which option a node uses depends on the registry's security policies. If all nodes share a common security policy, then each will see a publisher who authenticates with the same credentials as the same person, regardless of which node that publisher first registers with. If the nodes don't share a common security policy, then a publisher will need to register separately with each node that he or she wants to publish entities on and won't be seen as the same person by all the nodes, even though he or she is registering with the same registry. For a variety of reasons (e.g., business mergers wherein responsibility for the registry is consolidated, hardware problems that make a node unreliable), changing an entity's ownership, moving an element of a business entity to a different entity, or making a new node the custodian of a registry might be necessary. UDDI 3.0 includes APIs that you can use to transfer an entity's ownership or put the entity into a different node's custody. Typically, when you transfer an entity to a different node or change an entity's ownership, the change applies to all elements within that entity, but you can use save operations to move specific elements to different entities.
A node's security policies might require that the registry check the tModels for integrity before saving them. UDDI 3.0 lets third parties register value sets for the tModels and even cache these value sets if the node's required security policy allows such caching. (The node security policy can also specify the way in which a value set can be validated, including whether or not the registry should use Single Object Access Protocol—SOAP—to check the value set, as it would for any other Web service.) These value sets don't have to be stored with the registry but can reside in a separate location. To save time, UDDI 3.0 permits caching of value sets stored in separate locations, either by periodically pulling all valid values from that location, or by caching the values on the node as it successfully validates them.
Finally, UDDI 3.0 modifies some parts of the replication APIs and adds support for replicating digital-signature information. If you're interested in more details about these updates, you'll find them online at
http://www.uddi.org/pubs/uddi_v3_features.htm
End of Article
Register
