Retrieve WSDL files from a UDDI registry

Overview

You can use WSDL files to register web services in the Web Service Repository and to add WSDL documents and XML schemas to the global cache. Policy Studio can retrieve a WSDL file from the file system, from a URL, or from a UDDI registry. This topic explains how to retrieve a WSDL file from a UDDI registry. For details on how to register WSDL files, see Manage web services. For details on how to publish WSDL files, see Publish WSDL files to a UDDI registry.

You can also browse a UDDI registry in Policy Studio directly without registering a WSDL file. Under the APIs node in the tree, right-click the Web Service Repository node, and select Browse UDDI Registry.

UDDI concepts

Universal Description, Discovery and Integration (UDDI) is an OASIS-led initiative that enables businesses to publish and discover web services on the Internet. A business publishes services that it provides to a public XML-based registry so that other businesses can dynamically look up the registry and discover these services. Enough information is published to the registry to enable other businesses to find services and communicate with them. In addition, businesses can also publish services to a private or semi-private registry for internal use.

A business registration in a UDDI registry includes the following components:

  • Green Pages:
    Contains technical information about the services exposed by the business
  • Yellow Pages:
    Categorizes the services according to standard taxonomies and categorization systems
  • White Pages:
    Gives general information about the business, such as name, address, and contact information

You can search the UDDI registry according to a whole range of search criteria, which is of key importance to Policy Studio. You can search the registry to retrieve the WSDL file for a particular service. Policy Studio can then use this WSDL file to create a policy for the service, or to extract a schema from the WSDL to check the format of messages attempting to use the operations exposed by the Web service.

For a more detailed description of UDDI, see the UDDI specification. In the meantime, the next section gives high-level definitions of some of the terms displayed in the Policy Studio interface.

UDDI definitions

Because UDDI terminology is used in Policy Studio windows, such as the Import WSDL wizard, the following list of definitions explains some common UDDI terms. For more detailed explanations, see the UDDI specification.

businessEntity
This represents all known information about a particular business (for example, name, description, and contact information). A businessEntity can contain a number of businessService entities. A businessEntity may have an identifierBag, which is a list of name-value pairs for identifiers, such as Data Universal Numbering System (DUNS) numbers or taxonomy identifiers. A businessEntity may also have a categoryBag, which is a list of name-value pairs used to tag the businessEntity with classification information such as industry, product, or geographic codes. There is no mapping for a WSDL item to a businessEntity. When a WSDL file is published, you must specify a businessEntity for the businessService.

businessService
A businessService represents a logical service classification, and is used to describe a web service provided by a business. It contains descriptive information in business terms outlining the type of technical services found in each businessService element. A businessService may have a categoryBag, and may contain a number of bindingTemplate entities. In the WSDL to UDDI mapping, a businessService represents a wsdl:service. A businessService has a businessEntity as its parent in the UDDI registry.

bindingTemplate
A bindingTemplate contains pointers to the technical descriptions and the access point URL of the web service, but does not contain the details of the service specification. A bindingTemplate may contain references to a number of tModel entities, which do include details of the service specification. In the WSDL to UDDI mapping, a bindingTemplate represents a wsdl:port.

tModel
A tModel is a web service type definition, which is used to categorize a service type. A tModel consists of a key, a name, a description, and a URL. tModel s are referred to by other entities in the registry. The primary role of the tModel is to represent a technical specification (for example, WSDL file). A specification designer can establish a unique technical identity in a UDDI registry by registering information about the specification in a tModel. Other parties can express the availability of web services that are compliant with a specification by including a reference to the tModel in their bindingTemplate data.

This approach facilitates searching for registered web services that are compatible with a particular specification. tModels are also used in identifierBag and categoryBag structures to define organizational identity and various classifications. In this way, a tModel reference represents a relationship between the keyed name-value pairs to the super-name, or namespace in which the name-value pairs are meaningful. A tModel may have an identifierBag and a categoryBag. In the WSDL to UDDI mapping, a tModel represents a wsdl:binding or wsdl:portType.

Identifier
The purpose of identifiers in a UDDI registry is to enable others to find the published information using more formal identifiers such as DUNS numbers, Global Location Numbers (GLN), tax identifiers, or any other kind of organizational identifiers, regardless of whether these are private or shared.

The following are identification systems used commonly in UDDI registries:

Identification System Name tModel Key
Dun and Bradstreet D-U-N-S Number dnb-com:D-U-N-S uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823
Thomas Registry Suppliers thomasregister-com:supplierID uuid:B1B1BAF5-2329-43E6-AE13-BA8E97195039

Category
Entities in the registry may be categorized according to categorization system defined in a tModel (for example, geographical region). The businessEntity, businessService, and tModel types have an optional categoryBag. This is a collection of categories, each of which has a name, value, and tModel key.

The following are categorization systems used commonly in UDDI registries:

Categorization System Name tModel Key
UDDI Type Taxonomy uddi-org:types uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4
North American Industry Classification System (NAICS) 1997 Release ntis-gov:naics:1997 uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2

Example tModel mapping for WSDL portType

The following shows an example tModel mapped for a WSDL portType:

<tModel tModelKey="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3">
  <name>
    StockQuotePortType
  </name>
  <overviewDoc>
    <overviewURL>
      http://location/sample.wsdl
    </overviewURL>
  </overviewDoc>
  <categoryBag>
    <keyedReference tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824" keyName="portType namespace"
      keyValue="http://example.com/stockquote/" />
    <keyedReference tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457" keyName="WSDL type"
      keyValue="portType" />
  </categoryBag>
</tModel>

In this example, the tModel name is the same as the local name of the WSDL portType (in this case, StockQuotePortType), and the overviewURL links to the WSDL file. The categoryBag specifies the WSDL namespace, and shows that the tModel is for a portType.

Configure a registry connection

You first need to select the UDDI registry to search for WSDL files. Complete the following fields to select or add a UDDI registry:

Select Registry:
Select an existing UDDI registry to browse for WSDL files from the Registry drop-down list. To configure the location of a new UDDI registry, click Add. Similarly, to edit an existing UDDI registry location, click Edit. Then configure the fields in the Registry Connection Details dialog. For more details, see Connect to a UDDI registry.

Select Locale:
You can select an optional language locale from this list. The default is No Locale.

Advanced options

This tab enables you to configure various aspects of the search conditions specified on the previous tabs. The following options are available:

UDDI Find Qualifier Description
andAllKeys By default, identifier search criteria are ORed together. This setting ensures that they are ANDed instead. This is already the default for categoryBag and tModelBag.
approximateMatch (v3) This applies to a UDDI v3 registry only. Specifies wildcard searching as defined by the uddi-org:approximatematch:SQL99 tModel, which means approximate matching where percent sign (%) indicates any number of characters, and underscore (_) indicates any single character. The backslash character (\) is an escape character for the percent sign, underscore and backslash characters. This option adjusts the matching behavior for name, keyValue, and keyName (where applicable).
binarySort (v3) This applies to a UDDI v3 registry only. Enables greater speed in sorting, and causes a binary sort by name, as represented in Unicode codepoints.
bindingSubset (v3) This applies to a UDDI v3 registry only. Specifies that the search uses only categoryBag elements from contained bindingTemplate elements in the registered data, and ignores any entries found in the categoryBag that are not direct descendents of registered businessEntity or businessService elements.
caseInsensitiveMatch (v3) This applies to a UDDI v3 registry only. Specifies that that the matching for name, keyValue, and keyName (where applicable) should be performed without regard to case.
caseInsensitiveSort (v3) This applies to a UDDI v3 registry only. Specifies that the result set should be sorted without regard to case. This overrides the default case sensitive sorting behavior.
caseSensitiveMatch (v3) This applies to a UDDI v3 registry only. Specifies that that the matching for name, keyValue, and keyName (where applicable) should be case sensitive. This is the default behavior.
caseSensitiveSort (v3) This applies to a UDDI v3 registry only. Specifies that the result set should be sorted with regard to case. This is the default behavior.
combineCategoryBags Makes the categoryBag entries of a businessEntity behave as if all categoryBag s found at the businessEntity level and in all contained or referenced businessService s are combined. Searching for a category yields a positive match on a registered business if any of the categoryBags contained in a businessEntity (including the categoryBags in contained or referenced businessServices) contain the filter criteria.
diacriticInsensitiveMatch (v3) This applies to a UDDI v3 registry only. Specifies that matching for name, keyValue, and keyName (where applicable) should be performed without regard to diacritics. Support for this qualifier by nodes is optional.
diacriticSensitiveMatch (v3) This applies to a UDDI v3 registry only. Specifies that matching for name, keyValue, and keyName (where applicable) should be performed with regard to diacritics. This is the default behavior.
exactMatch (v3) This applies to a UDDI v3 registry only. Specifies that only entries with name, keyValue, and keyName (where applicable) that exactly match the name argument passed in, after normalization, are returned. This qualifier is sensitive to case and diacritics where applicable. This is the default behavior.
exactNameMatch (v2) This applies to a UDDI v2 registry only. Specifies that the name entered as part of the search criteria must exactly match the name specified in the UDDI registry.
orAllKeys By default, tModel and category search criteria are ANDed. This setting ORs these criteria instead.
orLikeKeys When a bag container contains multiple keyedReference elements (categoryBag or identifierBag), any keyedReference filters from the same namespace (for example, with the same tModelKey value) are ORed together rather than ANDed. For example, this enables you to search for any of these four values from this namespace, and any of these two values from this namespace.
serviceSubset Causes the component of the search that involves categorization to use only the categoryBags from directly contained or referenced businessServices in the registered data. The search results return only those businesses that match based on this modified behavior, in conjunction with any other search arguments provided.
signaturePresent (v3) This applies to a UDDI v3 registry only. This restricts the result to entities that contain, or are contained in, an XML Digital Signature element. The Signature element should be verified by the client. This option, or the presence of a Signature element, should only be used to refine a search result, and should not be used as a verification mechanism by UDDI clients.
sortByDateAsc (v3) This applies to a UDDI v3 registry only. Sorts the results alphabetically in order of ascending date.
sortByDateDsc (v3) This applies to a UDDI v3 registry only. Sorts the results alphabetically in order of descending date.
sortByNameAsc Sorts the results alphabetically in order of ascending name.
sortByNameDsc Sorts the results alphabetically in order of descending name.
suppressProjectedServices (v3) This applies to a UDDI v3 registry only. Specifies that service projections must not be returned when searching for services or businesses. This option is enabled by default when searching for a service without a businessKey.
UTS-10 (v3) This applies to a UDDI v3 registry only. Specifies sorting of results based on the Unicode Collation Algorithm on elements normalized according to Unicode Normalization Form C. A sort is performed according to the Unicode Collation Element Table in conjunction with the Unicode Collation Algorithm on the name field, and normalized using Unicode Normalization Form C. Support for this qualifier by nodes is optional.

Publish

Click the Publish radio button to view the Published UDDI Entities Tree View. This enables you to manually publish UDDI entities to the specified UDDI registry (for example, businessEntity, businessService, bindingTemplate, and tModel entities). You must already have the appropriate permissions to write to the UDDI registry.

Add a businessEntity

To add a business, perform the following steps:

  1. Right-click the tree view, and select Add businessEntity.
  2. In the Business dialog, enter a Name and Description for the business. Click OK.
  3. You can right-click the new businessEntity node to add child UDDI entities in the tree (for example, businessService, Category, and Identifier entities).

Add a tModel

To add a tModel , perform the following steps:

  1. Right-click the tree view, and select Add tModel.
  2. In the tModel dialog, enter a Name, Description, and Overview URL for the tModel . For example, you can use the Overview URL to specify the location of a WSDL file. Click OK.
  3. You can right-click the new tModel node to add child UDDI entities in the tree (for example, Category and Identifier entities).

As before, you can click any node in the results tree to display properties about that node in the table. You can also right-click a node to edit it (for example, add a description, add a category or identifier node, or delete a duplicate node). At any stage, you can click the Clear button on the right to clear the entire contents of the tree. This does not delete the contents of the registry.

For more details on UDDI entities such as businessEntity and tModel, see UDDI definitions. For details on how to publish web services automatically using a wizard, see Publish WSDL files to a UDDI registry.

Related Links