Section 8.3. Architectural Concepts
|
8.3. Architectural ConceptsThis section describes the concepts in the UDDI V3 architecture. 8.3.1. UDDI V3 Data ModelFollowing are the main elements of the UDDI data model:
Each of these is described in a section that follows, following a description of categorization. CategorizationCategorization is one of the most important aspects of UDDI. Categorization is represented in the UDDI data model by the categoryBag element. This element can contain multiple keyedReferences, with each keyedReference indicating one categorization from a particular category system. A tModel represents each category system, and one element of a keyedReference is the key of the tModel that represents the category system. The keyedReference can contain two other pieces of information. The first is a keyName, which for most category systems is for documentation purposes only; it is not used in queries other than with one predefined category system. The second is a keyValue, which is the particular value to be used for this instance of the category system. As an example, one of the category systems described in the UDDI specification is the ISO 3166 geographical category system. The key of the tModel that represents this category system is uddi:uddi.org:ubr:categorization:iso3166. If a business wants to indicate that it operates in the state of California in the U.S., it includes a keyedReference with this tModelKey and a keyValue of "US-CA." If a client wants to search for a business in California, it includes the same keyedReference in its search request. When matching a keyedReference such as this, the default is to do a case-sensitive exact match. However, one also has the option of performing a case-insensitive match (on "us-ca"), or an approximate match using wildcards, for example "US-%" to match against any U.S. state. businessEntityA businessEntity represents any provider of a service, not just a business. Other examples include departments and project teams. A businessEntity contains information about the service provider as a whole, including names and descriptions, in multiple languages if desired, and specific contact information for the service provider. A businessEntity can be categorized with multiple keyedReferences. A businessEntity contains zero or more businessServices. A businessEntity might have zero or more digital signatures. As described later, a businessEntity can be related to another businessEntity through a publisherAssertion. businessServiceA businessService represents a single service or set of related operations that can be invoked in different ways. A businessService is owned or contained by a single businessEntity but can be projected to more than one additional businessEntity if one service provider wants to offer a service owned by a different service provider. A businessService can have multiple names and descriptions, in different languages if required. A businessService can be categorized with multiple keyedReferences. A businessService has no contact information; only a businessEntity has contact information. The businessService contains the key of its parent businessEntity so that it can retrieve the contact information if necessary. A businessService contains zero or more bindingTemplates. If a businessService has more than one bindingTemplate, each one represents an alternative means of invoking the service, within the scope of the single provider of the service. Different providers of the same service are represented by different businessService entities. A businessService might have one or more digital signatures. Alternatively, the businessService might be included in the digital signature of its parent businessEntity. bindingTemplateA bindingTemplate represents a deployed implementation of a service or part of a service. It includes the URL that is the network endpoint that a client uses to communicate with the service. A bindingTemplate is contained by a single businessService. A bindingTemplate might have multiple descriptions, in different languages if desired, but it does not have a name. New in UDDI V3 is the addition of a categoryBag to the bindingTemplate structure so that one can categorize a bindingTemplate in the same way that one can categorize a businessEntity or businessService. Also new in UDDI V3 is the provision for a bindingTemplate to have zero or more digital signatures, if separate signatures are required specifically for the bindingTemplate, rather than including the bindingTemplate in the digital signature(s) of its parent businessService. A bindingTemplate might also include multiple instances of a tModelInstanceInfo structure, each of which represents some element of the technical information that is relevant to the deployed instance of the service or part of the service. A tModelInstanceInfo element consists of a tModel key, zero or more descriptions, and an instanceDetails element, if detailed information such as parameter settings is required. The collection of tModelInstanceInfo elements is known as the "technical fingerprint" of the bindingTemplate, and the tModel keys can be used in queries to search for bindingTemplates that contain at least one tModelInstanceInfo that refers to a particular tModel. tModelThe tModel is used for a wide range of purposes in UDDI. In the UDDI specification, it is used for the following:
tModel also represents any concept that is not better represented by one of the other UDDI data structures. A tModel must have a single name, which should be in the form of a URI, and it can have zero or more descriptions, in multiple languages if desired. A tModel can have multiple overviewDoc elements, each of which can refer to a detailed description of the tModel and its uses. Such descriptions are stored outside of UDDI. A tModel can be, and usually is, categorized with multiple keyedReferences in a categoryBag. A tModel might have zero or more digital signatures. Because a tModel is outside the containment hierarchy of the other main elements described so far, no parent entity can contain the signature of a tModel. publisherAssertionA publisherAssertion represents an association between two businessEntities. The owner of each businessEntity involved must assert the publisherAssertion before it is considered valid. A publisherAssertion consists of the two keys of the relevant businessEntity elements, a keyedReference representing the relationship between the two businessEntity instances, and zero or more digital signatures. Several relationships are defined in the UDDI specifications. One example is a parent-child relationship; therefore, if one businessEntity represents the parent business of another business represented by a second businessEntity, this relationship can be expressed in UDDI. One can query UDDI for related businesses. 8.3.2. UDDI and WSDLThe OASIS UDDI Specification Technical Committee (TC) has published a "V2 Technical Note" [UDDIWSDLTN] on using UDDI and WSDL that is intended to replace the existing V1 Best Practice [UDDIWSDLBP]. A Technical Note is a document produced by the TC that represents the consensus view of the TC on a topic for which there is insufficient implementation experience to publish a "Best Practice." The intention is that after sufficient implementation experience is obtained with the approach described in the technical note, it will become the new Best Practice specification for using WSDL and UDDI. The V1 Best Practice captured little information from the WSDL; it required that a tModel be produced for all of the WSDL bindings in a particular file, or one per binding. The overview URL of the tModel contained the URL of the WSDL file, with a fragment identifier representing a particular binding if the tModel represented a single binding. These tModels were categorized as relating to WSDL, but no other information from the WSDL was captured. The V2 Technical Note requires that every portType and binding have its own tModel. It extends the normative mapping to include WSDL services and ports. This section describes the architecture of the mapping between WSDL 1.1 and UDDI described in the UDDI/WSDL Technical Note. The mapping to UDDI is intended to support both UDDI V2 and V3 clients. No use is mandated of the new features in UDDI V3, because such features are generally invisible to UDDI V2 clients. For example, the mapping doesn't require the use of the categoryBag on a bindingTemplate, which is new in UDDI V3. That's because if information were represented only in the categoryBag, it would not be visible to V2 clients, and it would be inefficient to duplicate the same information in two different ways to support both V2 and V3 clients. If one knows that only V3 clients will publish to and inquire from the UDDI registry, one can use these new features of V3. The Technical Note introduces several new tModels, which are expected to be supported by any UDDI implementation that supports the approach described in the Technical Note. One of the new tModels represents a new category system, known as the WSDL Entity Type category system that categorizes the UDDI elements in terms of the WSDL element they represent. This allows searches for businessServices, for example, to be restricted to those businessServices that correspond to a WSDL service, because not all businessServices in a UDDI registry necessarily relate to a service that has a WSDL description. The mapping is summarized in Table 8-1.
The details of the mapping for each of the WSDL entities are described in the following sections. Mapping of WSDL portType ElementA WSDL portType is represented in UDDI as a tModel that is categorized as a portType in the WSDL Entity Type category system. The name of the tModel is taken from the local name of the portType. If a targetNamespace is associated with the portType, an additional keyedReference is added to the categoryBag of the tModel, with a keyValue that is the value of the targetNamespace. The tModelKey is the key of another of the new category systems that the Technical Note introduced: the XML namespace category system. The location of the WSDL document that contains the definition of the portType is stored as the value of the overviewURL within the overviewDoc of the tModel. The V1 Best Practice for UDDI and WSDL allows a fragment identifier to refer to an individual binding within a WSDL document, but no definitive standard for fragment identifiers with WSDL 1.1 has emerged. Therefore, the V2 Technical Note does not rely on fragment identifiers, and the URL that is stored is the base URL of the WSDL document. Sufficient information is captured in the UDDI model to allow the particular portType within the document to be identified. This mapping allows tModels that represent portTypes to be queried based solely on the fact that they correspond to a WSDL portType, or based on any combination of namespace name and local name. Mapping of WSDL Binding ElementThe mapping of a WSDL binding is similar to, but more complex than, the mapping of a portType. A WSDL binding is represented by a tModel that is categorized as a WSDL binding using the WSDL Entity Type category system. For compatibility with the V1 Best Practice, the tModel is also categorized with the wsdlSpec value using the standard UDDI types category system. As with the portType, the name of the tModel is taken from the name of the binding. If a targetNamespace is associated with the binding, a keyedReference is added for that in the same way as for a portType. The location of the WSDL document that describes the binding is again stored in the overviewURL of the overviewDoc of the tModel. The relationship between the WSDL binding and the portType it is a binding of is captured with another keyedReference in the categoryBag of the tModel corresponding to the binding. The tModelKey in this keyedReference is the key of another of the new tModels introduced in the Technical Note: the portType reference category system. The keyValue in the keyedReference is the key of the tModel that corresponds to the portType. This allows all tModels that represent bindings of the particular tModel to be queried using a standard find_tModel call, after the key(s) of the tModel(s) corresponding to the portType are known. The protocol that the binding supports, such as SOAP, is represented by another keyedReference in the categoryBag of the tModel, referring to yet another new category system introduced by the Technical Note: the Protocol Categorization category system. The keyValue of the keyedReference is the key of a tModel that represents the protocol. This allows a query for bindings of a particular portType to be restricted to those that support a particular protocol. Finally, if the binding supports a particular transport, such as HTTP, that information is modeled using yet another keyedReference, this time relating to the Transport Categorization category system introduced in the Technical Note. This allows a query for a binding tModel to be restricted to those that support a particular transport. When used in combination with the other keyedReferences in the categoryBag, this allows for bindings of a particular portType that support a particular protocol and transport to be found. Mapping of WSDL Service ElementA UDDI businessService represents a WSDL service. One can use an existing businessService if a WSDL description is being defined for an existing service, or create a new one. The name of a newly created businessService should be easy to read. It does not have to have the name of the WSDL service, but the WSDL service name becomes the default if no other name is supplied. A UDDI businessService might represent only one WSDL service. The businessService is categorized as a service using the WSDL Entity Type category system. The WSDL service name is modeled definitively using a keyedReference in the categoryBag of the businessService referencing the XML Local Name category system that the Technical Note defines. The keyValue of the keyedReference is the local name of the WSDL service. When querying for a service by name, one must specify that name in a keyedReference in the categoryBag of the query. Again, the name of the businessService name is not necessarily the same as the WSDL service name. The businessService's category bag contains a keyedReference that models the targetNamespace of the WSDL service, if one appears in the corresponding WSDL document. Mapping of WSDL Port ElementThe ports of a WSDL service are represented by a UDDI bindingTemplates inside the services's businessService. The WSDL binding of the port is modeled as a tModelInstanceInfo in the bindingTemplate for the port; the tModelKey is the key of the tModel that represents that WSDL binding. The local name of the port is modeled as the value of the instanceParms of this tModelInstanceInfo. As an optimization, another tModelInstanceInfo is added with the tModelKey of the portType that the binding relates to. This allows a more efficient query of all implementations of a particular portType, rather than requiring multiple calls to find all bindings of the portType and then all implementations of any of those bindings. UDDI and WSDL at Development TimeIf a developer chooses a service that has a WSDL description, she imports the WSDL service definition or generates it directly from the information held in UDDI if that is sufficient. Then she generates whatever code artifacts needed to access the service. When a developer knows some information about the WSDL description of the required service, she can issue queries to UDDI that are focused on WSDL elements of the service description, such as the namespace or the local name. She can also issue queries relating to the WSDL portType that is desired, or a particular binding of that portType. UDDI and WSDL at RuntimeThe modeling approach presented in the UDDI/WSDL Technical Note is sufficient to allow all implementations of a portType to be retrieved. This is appropriate if the environment that is hosting the client is flexible enough to be able to use any protocol and transport to invoke the service. If a particular protocol, such as SOAP, is required, a more precise query can be used, which will return only implementations that support that particular protocol. Finally, if there is a requirement to use a particular binding of a portType, perhaps because the use of some particular headers is required, one may query the implementations of that particular binding directly. 8.3.3. UDDI and WS-PolicyThe WS-PolicyAttachment Specification [WS-Policy Attachment] describes how to attach policies to the following UDDI entities:
Two approaches are described in the WS-PolicyAttachment specification. The first is to reference remotely accessible policy expressions directly from the UDDI entities. This approach is convenient when the policy expression is referenced by only one UDDI entity. The second is to create a tModel to represent a policy expression and then to reference the tModel from a UDDI entities. This approach should be used when multiple UDDI entities reference the same policy expression. Referencing Remote Policy Expressions DirectlyThe WS-PolicyAttachment specification defines a tModel to represent a category system called the Remote Policy Reference category system. The valid values of this category system are URIs that identify remote policy expressions. In UDDI V3, the policy expression is associated with aUDDI entity. It includes a keyedReference in the categoryBag of the entity with a tModelKey value that is the key of the tModel representing this category system and a keyValue value that is the URI of the remote policy expression. A different approach for a bindingTemplate is required for UDDI V2, because in the UDDI V2 data model, a bindingTemplate does not have a categoryBag. Referencing Remote Policy Expressions IndirectlyTo support the publication of tModels to represent individual remote policy expressions, the WS-PolicyAttachment Specification defines another tModel to represent a different category system: the WS-Policy Types category system. One must categorize a tModel that represents an individual remote policy expression with the WS-Policy Types category system. This category system has a single valid value of "policy." The URI that identifies the policy expression serves as the overviewURL of the tModel and as a direct reference to the policy expression, using the first approach. A UDDI entity associates itself with the tModel for a policy expression using a third category system, the Local Policy Reference. The valid values of this category system are keys of tModels that are categorized using the WS-Policy Types category system. To make the association one simply adds a keyedReference to the categoryBag of the UDDI entity with a tModelKey value of the key of the tModel representing the Local Policy Reference category system and a keyValue value of the key of the tModel representing the individual remote Policy Expression. Querying UDDI Using Policy ExpressionsQueries to a UDDI registry can use the policy expression's URI to retrieve UDDI entities associated with that policy. If the association is direct, the query includes a keyedReference in the categoryBag, with a tModelKey value of the tModel representing the Remote Policy Reference category system and a keyValue value of the URI of the policy expression. If the association is indirect, the one needs to retrieve the tModel that represents the policy expression before the actual query for UDDI entities. The query must include a keyedReference in the categoryBag, with a tModelKey value representing the Local Policy Reference category system and a keyValue returned by the first query. 8.3.4. UDDI V3 Architecture and APIsThe UDDI V3 architecture is made up of the following components:
The client interacts with the UDDI registry using SOAP/HTTP requests and responses in a document/literal style, with the APIs defined in the UDDI specification. One can combine multiple UDDI nodes to form a single UDDI registry, as long as the nodes have compatible policy definitions and they replicate data with each other to ensure that, after a replication cycle has completed, all nodes in the registry have the same data. The nodes communicate with each other using SOAP/HTTP to replicate the data. If one issues the same query to different nodes in the registry, the same information is returned. Each piece of data in a registry belongs to a single publisher; likewise, a single node has the custody of each individual piece of data in the resgitry. The data can only be updated or deleted by the publisher sending a request to the node that has custody of the data. Although the nodes are equivalent for reading from the registry, they are different when it comes to writing to the registry. If a request to a node requires the use of a taxonomy that an external server provides, the node might make a SOAP/HTTP call to that server to validate the use of the taxonomy. An UDDI node might also cache taxonomy information from a remote server to avoid further remote calls to the taxonomy server. Several APIs/portTypes are defined in the UDDI specification. They can be divided into the following groups:
Each of these groups is described in more detail in the following sections. Client to Node OperationsThe following portTypes are available so that clients can invoke operations against an UDDI node:
The UDDI_Inquiry_PortType has two kinds of operations: find operations and get operations. The find operations issue queries to the UDDI registry; the get operations retrieve full details of one or more entities of a particular type. All of the "find" operations take a findQualifiers element. This element modifies which entities match the query and how they are sorted. The "find" operations return abbreviated information about the matching entities, typically the key of each entity and the name(s) and description(s) of the entity as appropriate. In UDDI V3, when too many results match a single call, only part of them are returned and one can use a mechanism called a listDescription to page through the results. Another new feature in UDDI V3 is that some of the find operations can take a nested query as an argument, which can result in much more efficient queries. For example, the find_business operation can take a find_tModel query as an argument in addition to a find_relatedBusinesses query. These inner or nested queries are issued first by the UDDI registry that processes the find_business operation. The results of these nested queries are used to alter the original find_business operation. One can achieve the same effect by issuing the find_tModel or find_relatedBusinesses queries separately and then building up a more complex find_business query. However, this requires at least three calls to the UDDI registry if both nested queries are used, whereas being able to nest them within the find_business query means that only one call to the UDDI registry is required. Each of the get operations takes one or more keys as input, typically from the result of one or more find operations, and returns the full information about each entity. The UDDI_Publication_PortType contains all of the operations that add content to, update content in, or remove content from an UDDI registry. It also contains several specialized get operations. A businessService can be added to a businessEntity either by being included in the definition of the businessEntity supplied in a save_business call or by being included in a save_service call. If a save_business call updates a businessEntity, any services that were part of the businessEntity but are not included in the updated definition of the businessEntity are implicitly deleted. One must be careful when adding or updating a businessService that is owned by a businessEntity that has at least one digital signature because the signature(s) can be invalidated by the change. Similar considerations apply to adding or updating a bindingTemplate within a businessService. The function of delete_tModel is unique in that it does not completely remove a tModel; it only marks it as hidden. A find_tModel call does not return a hidden tModel, but a get_tModelDetail call can still retrieve its details. One can even publish new references to the tModel, although this practice is discouraged because the tModel is presumably not intended to be used for new publications. The reason for this design is that tModels are intended to represent stable concepts and standards that should continue to have value even when new versions become available. Such new versions are represented by new tModels. The UDDI_Security_PortType portType defines the discard_authToken and get_authToken operations that are used if the authentication mechanism that UDDI defines is supported. The UDDI_CustodyTransfer_PortType portType defines operations that allow for the custody or ownership of one or more businessEntity elements (and the associated businessService elements) and one or more tModel entities to be transferred to another node or owner. The UDDI_Subscription_PortType portType defines operations that allow a user to register an interest in entities in an UDDI node that matches the information in the subscription request, and to retrieve details of events that involve those entities. Support for subscription is new in UDDI version 3 and is described in more detail in a later section. Node to Client OperationsOnly one portType is defined for nodes to invoke operations against an UDDI client: the UDDI_SubscriptionListener_PortType portType. A single operation is defined in this portType: notify_subscriptionListener. If a client wants to receive asynchronous notifications when an event that matches a subscription request occurs, it can deploy a Web service that implements this portType and register that fact in the UDDI registry by creating a bindingTemplate for it. The key of this bindingTemplate is then supplied in the subscription request to indicate that this style of receiving notifications is required. Node to Node OperationsOnly one portType is defined for nodes to invoke operations against another node: the UDDI_Replication_PortType portType. The operations that are defined in this portType allow multiple nodes to operate together as part of a multinode registry. Node to Taxonomy Server OperationsThe following portTypes are available for a node to invoke operations against a taxonomy server:
Each of these portTypes defines a single operation. The operation in the UDDI_ValueSetCaching_PortType portType is get_allValidValues. When an UDDI node invokes get_allValidValues against a value set server, the value set server returns the entire set of valid values in a single response. The operation in the UDDI_ValueSetValidation_PortType portType is validate_values. When an entity such as a businessEntity is published to an UDDI node, and it references a value set that is externally verified, the UDDI node invokes the validate_values operation against the appropriate value set server, passing it the entire businessEntity element. The value set server checks that the uses of the value sets it provides are correct. 8.3.5. New Features in UDDI V3The following are the main features that were added to UDDI with the V3 specification:
For full details, see the UDDI Version 3 Features List [UDDIV3Features]. Publisher-Assigned KeysPrior to UDDI V3, UDDI entities had keys that were Universal Unique Identifiers (UUIDs). The UDDI registry assigned these keys when it first saved the entity. This meant that it was not possible using just the UDDI API to save the same entity to two different registries and have the same key be assigned to the entity in both registries. This made it difficult to move information between a test and production registry, for instance, without changing the keys used for the entities. With UDDI V3, a publisher can assign a key to an entity when it is first saved, and these keys can be based on a domain name, making them more meaningful. Taking one of the tModels defined in the V3 specification as an example, its V3 key is uddi:uddi.org:specification:v3_policy, whereas the corresponding V2 key (UUID) is uuid:d52ce89c-01f8-3b53-a25e-89cfa5bbad17. This ability to specify the key when the entity is saved means that one can use the standard UDDI API to republish the same entity into a production UDDI registry, keeping the same key that the entity had in a test registry. A key in UDDI V3 must begin with "uddi:" and its total length must be no longer than 255 characters. When using publisher-assigned keys, one needs to understand the concepts of key generators and key partitions. UDDI V3 keys are divided into nonKeyGeneratorKey and keyGeneratorKey keys. A nonKeyGeneratorKey can be one of three types:
A keyGeneratorKey is a nonKeyGeneratorKey with ":keygenerator" (or ":keyGenerator") appended. An example of a keyGeneratorKey is uddi:tempuri.com:keygenerator. The nonKeyGeneratorKey that this keyGenerator is based on is uddi:tempuri.com. To establish a key partition, one must save a tModel categorized as a keyGenerator tModel. It must also have a publisher-assigned key that is a keyGeneratorKey. The partition associated with the tModel is named after the nonKeyGeneratorKey that is the basis of the keyGeneratorKey of the tModel. In the previous example, the tModel with key "uddi:tempuri.com:keygenerator" defines a partition named "uddi:tempuri.com." After the tModel is saved only its owner can propose keys such as "uddi:tempuri.com:fishbuyingservice," because this key is in the "uddi:tempuri.com" partition. To allow multiple publishers to be able to propose keys, one can divide a partition into subpartitions. Continuing the tempuri.com example, the publisher that owns the tModel with key "uddi:tempuri.com:keygenerator" can publish another keyGenerator tModel with the key "uddi:tempuri.com:fish:keygenerator" to establish a "fish" subpartition of the "uddi:tempuri.com" partition. One may transfer ownership of this second tModel to another publisher, who can then assign keys only in this new subpartition, such as "uddi:tempuri.com:fish:buyingservice." Note that the original publisher cannot assign keys in this subpartition because the ownership of the tModel was transferred. A partition or subpartition can have only a single owner; therefore, only one publisher at a time can publish entities that have keys assigned from a partition. If multiple registries have appropriate policies, they can form a group known as an affiliation, which enables UDDI entities to be copied between registries. An enterprise might establish an affiliation between a test or staging registry and a production registry so that data can be copied easily from the test or staging registry to the production registry. The main function of the affiliation is to ensure that keys used in one registry in the affiliation can safely be used by the same publisher in all other registries in the affiliation. One can use a designated registry as a root registry, guaranteeing uniqueness of key partitions across all other registries that are affiliated to the root registry. A company such as tempuri.com can publish a keyGenerator tModel with the key uddi:tempuri.com:keygenerator in the root registry and then republish the same tModel into its own top-level internal UDDI registry and be sure that the same tModel cannot be claimed by any other business that uses the same root registry in the same way. By doing this, tempuri.com can be assured that any keys it generates internally can be used with any affiliated registry without risk of collision. Support for Digital SignaturesTo improve the trust in the quality and provenance of the data in an UDDI registry, UDDI V3 added the capability for publishers to digitally sign the information that they publish. The following entities might have a digital signature associated with them:
One must be careful with businessEntity and businessService because they can have child elements (businessService and bindingTemplate) added separately, which might invalidate the original digital signature of the parent entity. For example, perhaps the businessEntity is saved with three child businessService elements, and the businessEntity is signed. If another businessService is added to the businessEntity later with a save_service call, the businessEntity would have four businessService elements, and the original digital signature would no longer be valid. The support for digital signatures in UDDI V3 requires a particular canonicalization scheme known as Schema Centric XML Canonicalization. [SCC14N] UDDI V3 queries can specify that results should be restricted to only those entities that have a digital signature. Clients that use either the UDDI V1 API or the UDDI V2 API cannot assign a digital signature when publishing or see a digital signature when querying an UDDI V3 registry. If an entity to be signed has a publisher-assigned key, it is possible to save the signed entity in a single call. If, however, the entity has a registry-assigned key, two calls are necessary. The purpose of the first call is to allow the registry to assign the key to the entity; only a limited amount of information needs to be sent with the first call. The second call updates the entity with the full information and includes the digital signature. UDDI PolicyAnother major new feature in UDDI V3 is the use of policy definitions to control the behavior of a UDDI node or registry and to communicate these behaviors to clients and potential registry users. One can define a policy for an individual node or for a registry in the case of a multinode registry. The UDDI V3 specification defines two types of policies:
UDDI data structures should be used to represent policies that affect a UDDI client so the client can retrieve them using the normal UDDI inquiry API. Following are examples of this type of policy:
Policies that are more concerned with the administration of a node or the registry are more likely to be represented in an XML document. Following are examples of this type of policy:
Subscription APIThe subscription API allows clients to register an interest in UDDI entities that meet certain criteria and, optionally, be notified when new entities are published that meet the criteria or when existing entities that meet the criteria are altered or deleted. Support for the subscription API is optional. The following types of entities can be used with subscription:
A subscriber can be notified of changes either synchronously or asynchronously, depending on the capabilities of the node. If a subscriber wants to be notified asynchronously, he either must have an e-mail address to which the information is mailed, or he must implement the UDDI_SubscriptionListener_PortType and define a bindingTemplate in the registry with the endpoint of the service that implements this portType. The criteria that the subscriber is interested in are defined by a combination of standard inquiry APIs, both find and get requests. Registering an interest in new entities requires the use of a find request. One can use either type of request to register an interest in an existing entity. The subscription API enables automatic copying of data between registries. When an event matching the subscription criteria takes place at the registry that owns the data, the registry sends a notification to the subscriber (another registry). The notification allows the subscriber to automatically update its copy of the data to match the original. Categorization EnhancementsFollowing are the enhancements in UDDI V3 that relate to categorization:
The keyedReferenceGroup element allows one to group multiple keyedReferences together and consider them a single complex categorization, identified by an additional tModel for the group as a whole, separate from the tModel indicated in each keyedReference. For example, one could describe the geographic location of an entity using the World Geodetic System 1984 (WGS 84). The keyedReferenceGroup will contain the key of the tModel representing the WGS 84 category system and the following keyedReferences:
When a query includes a keyedReferenceGroup an entity matches the query with a keyedReferenceGroup if the tModel keys for the two groups are identical and the keyedReferences within the group in the query are a subset of the keyedReferences within the group in the entity. Changes in AuthenticationThe UDDI V2 specifications required authentication for the publish API but did not allow authentication for the inquiry API. Authentication information was carried in the publish API explicitly in the form of an UDDI authentication token (the authToken element). The publish API also contained calls to acquire an authentication token, given a userid and password, and to discard an authentication token. Although the V2 specifications allowed an authentication token to be obtained other than through the UDDI authentication calls, the token still had to be passed explicitly to publish calls and could not be passed to inquiry calls. In the UDDI V3 specification, the UDDI authentication token is optional on every call in the inquiry, publication, custody transfer, and subscription APIs. The mechanisms for authentication and identification are now part of the policy definitions of the registry and the particular node. The UDDI V3 specification allows the use of transport-level authentication as an alternative to explicit tokens carried in the UDDI request messages. |
|
![Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More](/icons/blank_book.jpg "Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More"){kind=icon}
EAN: N/A
Pages: 176