|
Rocket ahead with UDDI V3 [Be02]
|
- The V3 specification presents a unified, organized document that eliminates redundancy and conflicts that were present in the prior documentation. The new documentation also has significant explanatory and descriptive information in a set of appendices that covers the use of key features.
- New or advanced Features:
-
Multi-registry environments
- support for visibility-differentiation (public registry, semi-private registry or private registry);
solving problems when private registries go public, because in v2 transferring registry information on existing businesses and their services from one isolated registry to another, in a way that fully preserves the keys used to uniquely identify these entities, has not been possible
- V3 introduces the concepts of root and affiliate registries:
A root registry acts as the authority for key spaces. Such registries are used to delegate key partitions so that other registries can rely upon the root registry to verify and maintain the uniqueness of such key partitions. The UBR (UDDI Business Registry often termed public registry) is a good example of a root registry, which the image below illustrates (adopted from the UDDI V3 specifications).
Affiliate registries interact with a root registry. These affiliates rely upon the root registry for delegating unique key partitions. Afterwards, data can be shared between and among the root and affiliate registries with the assurance that each given key partition is unique.
-
Publisher specified keys
- prior to V3 the uuid (universal unique identifier) was generated by the registry itself (random hexadecimal string in a defined format that serves no purpose beyond that of ensuring uniqueness -> difficult to manage, remember, and use)
- v3 allows the publishers to specify their own key values when they create new entities (provides the ability to save the same entity with the same key value in more than one registry)
-
Vanity keys (maybe enabled in V3, depending upon the policy of the particular registry) allow publishers to specify a meaningful name for a key as an alternative to having a uuid-based key assigned automatically by the registry
V3 specification establishes some rules on how this is done:
- keys are now Universal Resource Identifiers (URI) instead of simple uuids. Each key in V3 is now known as a uddiKey.
- uddiKey can be either a uuidKey, a domainKey, or a derivedKey
-
uuidKey: essentially the V3 equivalent of a uuid-based key, in the form "uddi:" uuid
-
domainKey: takes the form "uddi:" domain, where the domain is based upon an established DNS record
-
derivedKey: has the form uddiKey ":" KSS, where the key specific string (KSS) is composed of upper and lowercase characters, numbers, and other symbols permitted in a URI. Given the number of us, ds, and is in this clinical explanation, a few uddiKey examples might help:
- Here is an example of a typical uuidKey: uddi:2AB7E4BF-887B-923A-9936-443EAAC8AE23. Essentially, this is the familiar and sometimes despised pre-V3 uuid entity key, converted into a uuidKey by prefixing "uddi:" to it.
- Here are some domainKey examples: uddi:mydomain.com and uddi:yourdomain.com. In each case, mydomain.com and yourdomain.com are the respective domains.
- Finally, a few derivedKey examples are useful: uddi:2AB7E4BF-887B-923A-9936443EAAC8AE23:derivedPartGoesHere and uddi:mydomain.com:myProduct:browsingService. The derivedPartGoesHere and myProduct:browsingService are the KSS part of the derivedKey.
- For registries that use the V3 recommended key policy, there are also some rules for using keys that are derived from a domainKey. You must acquire a license to publish such keys. This entails creating a special tModel known as a domain keyGenerator. These tModels establish a key partition from which uddiKeys can be derived and used in other entities, which are created and controlled by the publisher. The tModelKey for these tModels must be in the form of a domain_key and must end with the term keyGenerator. The publisher must categorize the tModel using a value of keyGenerator from the uddi-org:types value set. Depending upon registry policy, the publisher may need to sign these tModels. Publishers may then create derived keys based upon the domain identified by a keyGeneratortModel that they own.
-
Subscription
- enables you to track changes in the content of a UDDI registry through either synchronous requests for this information or through asynchronous notifications made by a registry node to the requestor, as illustrated in the image below.
as a non-normative part of the V3 specification, it fills a key role in enabling registry affiliation. In scenarios where one or more affiliated registries rely upon a root registry to manage key spaces, an affiliated registry may want to be aware of changes of interest in the root registry and then reflect copies of those entries into the affiliate.
- The subscriber may establish multiple subscriptions, if additional criteria need to be used.
- Subscribers also register a number of other preferences when saving a subscription request, such as how they want to receive the results of activity matching their subscription criteria (Email, SOAP messages to a Service). A bindingKey corresponding to a bindingTemplate with a valid endpoint is required in the subscription to use this feature.
-
Policy
- Policies describe the specific behavior of a registry or of a node within a registry, insofar as the UDDI specification permits such variances. In earlier versions, the UDDI specification mixed policy issues with UBR implementation concerns. V3 separates these and expands the role of policy by prescribing a set of policies that registries must address. The UDDI specification addresses issues of policy using several terms:
-
Policy abstractions. Describes various types of high-level policies and provides broad definitions of high-level information management policies.
-
Policy rule. The basic building block of any policy-based system. It defines the metrics of a set of actions mapped against a set of conditions.
-
Policy decision. Involves the evaluation of a policy rule's conditions.
-
Policy decision point (PDP). The logical entity where policies are decided. In UDDI, this will be either the registry or the nodes within the registry.
-
Policy enforcement point (PEP). The point at which policies are enforced. In UDDI, this will be at either the registry or node level.
-
Hierarchical policy relationships in UDDI:
Registries may delegate certain PDPs and PEPs to their constituent nodes. The image above illustrates these relationships. The specification groups policies into several categories, including:
-
Policy delegation. Covers policies for determining which sets of polices may be delegated to nodes.
-
Keying. Defines policies on key format, generation, and so on.
-
Information access and control. Defines policies on registration and authorization of users, privacy, and more.
-
APIs. Defines policies on data confidentiality for each API set (Inquiry, Publication, Subscription, Custody, and others).
-
User policies. Describes policies on user publication limits and ownership transfer.
-
Data custody. Determines whether custody transfer is permitted.
-
Replication. Determines whether replication is supported.
-
Subscription. Determines whether subscription is supported and other related policies affecting the behavior and capabilities provided in subscription, such as the duration of a subscription.
-
Value sets. Defines policies dealing with management of external validation and related caching behavior.
-
Security
- The UDDI security model is defined by the set of registry and node policies and their implementations.
- V3 adds support for digital signing of all core data types to address issues of data integrity and authenticity not previously available in UDDI. -> TRUST
- Inquirers can now also issue inquiries that only return results pertaining to signed data.
- Given the multi-registry environment enabled in V3, the reliability of data becomes even more important. When signed data is copied between registries, you can guarantee its integrity by simply validating the signature.
- To support digital signatures, both publishers and registry implementations must support normalization and canonicalization.In normalization, the registry must reduce each of the characters that make up the SOAP message to a single standard representation. This is necessary because in UTF-8, it is often possible to represent the same character with multiple encodings.
Canonicalization creates a standard representation of XML, addressing issues like the tag representation, attribute ordering, namespace declaration, expansion and ordering, and white space handling. Ensuring consistent behavior is critical. Registries must save and retrieve data in a well-defined way so that a digital signature is not broken. This also places a burden on the publisher, who must similarly process the data before signing it so that the registry will not modify it further during these steps so that the signature is not broken.
-
Enhanced inquiry
- V3 adds support for
- new find qualifiers
- find qualifier extensibility
- compound queries
- management of large result sets
-
New find qualifiers:
- Recall that find qualifiers are essentially flags that alter the behavior of searching in UDDI, such as how results are sorted or matching is performed. The new find qualifiers provide enhanced selection options in the area of internationalization, but also formalize and expand some older capabilities as well. Those related to internationalization include:
-
case Insensitive Match.
-
case Insensitive Sort.
-
case Sensitive Sort.
-
diacritic Insensitive Match. Matches without regard to diacritic markings (for example, accents).
-
diacritic Sensitive Match.
-
UTS-10. Sorts based on the Unicode Collation Algorithm on elements normalized, according to Unicode Normalization Form C.
Other new find qualifiers include:
-
approximate Match. UDDI now has standardized wildcard matching based on an SQL LIKE syntax.
-
binary Sort. Causes a binary sort by name.
-
exact Match. Matches based on exact criteria supplied. This is the new default.
-
signature Present. Returns only results that contain a signature.
-
Find qualifier extensibility and compound queries:
- The set of defined find qualifiers may be more easily extended by registries because now they may be either tModelKeys or can be represented by their short names. Compound queries were added to several of the inquiry APIs to facilitate common tooling idioms. In particular:
-
find_binding. Permits the discovery of binding Templates across businessService elements, as well as the embedded use of the find_tModel API. The tModel results of this inner find_tModel API are added to any that were supplied in the tModelBag provided with the find_binding API call.
-
find_business. Permits the embedded use of the find_relatedBusinesses and find_tModel APIs. When an inquirer includes the find_relatedBusinesses API here, this causes the results returned by find_business to be an intersection of the businesses returned by the find_relatedBusinesses query and those returned based upon the other criteria supplied in the find_business query. Use of find_tModel behaves similarly to that described previously.
-
find_service. Permits the embedded use of the find_tModel API, with similar behavior as described previously.
-
Management of large result sets
- V3 now supports large result sets, enabling inquirers to retrieve results in a quasi-chunked fashion. This is not a true cursor-like behavior because, while the registry allows chunked retrieval of results, these results do not represent a frozen snapshot in time. Data in the registry could change during the retrieval process (adds or deletes), which could affect the overall results.
|
Universal Description, Discovery and Integration
to each of them a client is a separate identity)
