Let's continue the discussion we began in the August 8, 2002, .NET UPDATE of Universal Description, Discovery, and Integration (UDDI) 3.0 by looking at how the specification supports policies. Not all UDDI registries operate under the same conditions. Some registries will support only users who have access to a closed intranet, some will support only users who have access to a public Web site, and some will support both categories of users (and might need to provide varying degrees of access for each kind of user). Even within a single deployment model, registries might need to operate under different rules during the various stages of deployment (i.e., development, testing, and production). Because UDDI 3.0 supports registry interaction, wherein people or applications might access multiple registries (rather than one big registry), supporting the various rules by which registries operate is especially important.
To cover all the different conditions under which a UDDI registry might present its contents, UDDI 3.0 supports policies. Included in that support are a new policy schema to represent policy decisions and changes to UDDI, and a policy guide that helps users make a registry operate according to rules that are appropriate to the circumstances under which client applications access the registry or information is published to it. Aspects of UDDI that the version 3 specification has identified as policy decisions include authorization models, data custody and confidentiality, key generation, subscription, user publication limits, and audit policy (the specification includes a complete list). Some policies, such as those for key generation and key format (mechanisms that are necessary to permit administrators to import and export keys among nodes) are required, and others, such as those that define the mechanisms through which a particular user can publish information to the registry, are optional.
How do UDDI registries know about policies? XML documents can define policies, or (more rarely) UDDI elements can directly model policies--the UDDI 3.0 specification lists the available policies and suggests how best to apply each one. When a policy is defined in an XML document, the document should be a human-readable and Web-accessible document with its URL included in the registry. The UDDI 3.0 specification recommends that policy documents that define node or registry policy be listed as business services.
A UDDI registry can exist on one node or can be distributed across several nodes, and this distributed model affects the way policies work. If you're familiar with how policies operate in Active Directory (AD), you won't find policies in UDDI too difficult to grasp because the models are similar. Each UDDI registry defines broad registry policies, one of which is whether the individual nodes within the registry can define policies. If a registry lets a node specify policies, the registry is "delegating" the policy expression to the node. Therefore, UDDI can define policies either for a single node that supports a registry or for a registry that's distributed among multiple nodes, so long as the node-level rules are consistent with the policies defined for the entire registry. For security, policies can include digital signatures, such as those we discussed in the August 22, 2002, .NET UPDATE.
The bottom line is that different UDDI implementations can use policies to mold a particular registry in ways appropriate to the framework within which the registry offers resources. For more details, check out Chapter 9 of the UDDI 3.0 specification at http://uddi.org/pubs/uddi_v3.htm
