Retrieving WSDL Files from a UDDI Directory

Contents

Overview

A WSDL (Web Services Description Language) file defines the interface to a Web Service, or list of services. It lists the operations exposed by the service, the wire format for requests for these operations, and the data types of any elements that appear within the body of the requests. It also gives the location of the Web Service in terms of a URL that clients can access in order to use the exposed operations.

The Policy Studio can extract this information from the WSDL file to generate the following filters, which can then be incorporated into one or more policies:

  • Relative Path Resolver
  • SOAPAction Resolver
  • SOAP Operation Resolver
  • Connection Handler
  • Static Router
  • Schema Validation

WSDL files are used to create Web Services in the Web Services Repository and also when adding XML Schemas to the global Schema Cache. In both cases, a WSDL file can be retrieved from the file system, from a URL, or from a UDDI registry. The remainder of this help page explains how to retrieve a WSDL from a UDDI registry.

UDDI: A Brief Introduction

UDDI (Universal Description, Discovery and Integration) is an OASIS-led initiative that allows businesses to publish and discover services on the public Internet. A business publishes services that it provides to a global XML-based registry in such a way that other businesses can dynamically look up the registry and discover these services. Enough information is published to the registry to allow other businesses to find services and communicate with them.

There are 3 aspects to a business registration in a UDDI registry:

  • 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

Of key importance to the Policy Studio is that the UDDI registry can be searched according to a whole range of search criteria. The object of this exercise is to retrieve the WSDL file for a particular service. The Policy Studio can then use this WSDL file to create a policy for the service and/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, the reader is advised to consult the UDDI specification. In the meantime, the next section gives some high-level definitions of some of the terms that appear in the Policy Studio interface.

UDDI Definitions

Since UDDI terminology is used throughout the screens that comprise the Load WSDL wizard (and therefore, throughout this help page), the following list of definitions explain some common UDDI terms. For more detailed explanations of these terms, please refer to the UDDI specification.

businessEntity:
This represents all known information about a business, such as name, description, contact information, and so on. A businessEntity may have an identifierBag, which is a list of name-value pairs used to hold identifiers, such as DUNS (Data Universal Numbering System) 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 taxonomy/classification information such as industry, product,or geographic codes. Furthermore, a businessEntity may contain a number of businessService entities.

businessService:
A businessService represents a single logical service classification. It is used to describe a service provided by a business. It contains descriptive information in business terms outlining the type of technical services found within each businessService element. A businessService may have a categoryBag and may contain a number of bindingTemplate entities.

bindingTemplate:
A bindingTemplate contains pointers to the technical descriptions and the access point URL of the service, but does not contain the details of the service's specification. A businessService may contain references to a number of tModel entities.

tModel:
A tModel is keyed metadata that is used in UDDI as a keyed namespace reference. A tModel consists of a key, a name, a description, and a URL. tModels are referred to by other entities in the registry. The tModel's primary role is to represent a technical specification. A specification designer can establish a unique technical identity within 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 within identifierBag and categoryBag structures to define organizational identity and various classifications. Used in this context, the tModel reference represents a relationship between the keyed name-value pairs to the super-name, or namespace within which the name-value pairs are meaningful. A tModel may have an identifierBag and a categoryBag.

Identification:
The purpose of identifiers in a UDDI registry is to allow 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:

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

Categorization:
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 have a name, value, and tModel key.

The following are categorization systems used commonly in UDDI registries:-

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

Registry Configuration

We first need to select the UDDI registry that we want to search for WSDL files. Complete the following fields to select or add a UDDI registry:

Registry:
Select an existing UDDI registry to browse for WSDL files from the Registry dropdown. To configure the location of a new UDDI registry, click the Add button. Similarly, to edit an existing UDDI registry location click the Edit button. The Registry Connection Details dialog is displayed. Complete the following fields:

Registry Name:
Enter display name for the UDDI registry in this field.

Inquiry URL:
Enter the Inquiry URL of the UDDI registry.

Registry Authentication Type:
This field is optional. The only supported authentication type is "UDDI_GET_AUTHTOKEN".

Username:
Enter the username required to authenticate to the registry, if required.

Password:
Enter the password for this user, if required.

Proxy Host:
If the UDDI registry location entered above requires a connection to be made through an HTTP proxy enter the host name of the proxy here.

Proxy Port:
If a proxy is required enter the port on which the proxy server is listening.

Username:
If the proxy has been configured to only accept authenticated requests, the Policy Studio will send this username and password to the proxy using HTTP basic authentication.

Password:
Enter the password to use along with the username specified in the field above.

SSL Proxy Host:
If the Inquiry URL specified above uses the HTTPS protocol, the SSL proxy host entered here will be used instead of the HTTP proxy entered above. In this case the proxy settings entered above will not be used.

SSL Proxy Port:
Enter the port that the SSL proxy is listening on.

Quick Search

The Quick Search facility allows you to search the UDDI registry for all tModels that have been categorized according to the uddi-org:types categorization system as "wsdlSpec". The user may optionally enter a tModel name in the Name field in order to fine-grain the search.

The name entered is a partial or full name pattern with wildcard searching as specified by the SQL-92 LIKE specification . The wildcard characters are percent '%', and underscore '_', where an underscore matches any single character and a percent matches zero or more characters.

Click the Search button to initiate the search. The Search Results tree shows the tModel URIs as top-level nodes. These URIs are all WSDL URIs and can be used to generate policies by selecting the URI and clicking the Next button.

The user may click on any of the nodes in the tree to display detailed properties about that node in the table below the Search Results tree. The properties listed will depend on the type of the node that is selected.

Search by Name

The Name Search allows you to search for tModels by name, but also to specify what entity level in the tree to start the search from. The user must select one of the following entity levels to start the search from:

  • businessEntity
  • businessService
  • tModel

Click the Search button to start the name search. The search results will display the matching entities from the starting level down to the tModel level. For example, if the user selects the businessService option, the search results will show businessServices as top level nodes, then bindingTemplates, then tModels.

The user may optionally enter a name in the Name field in order to narrow the search. Wildcards may be used for the name. The name will apply to a businessEntity, businessService, or tModel depending on which registry entity type has been selected. If no name is entered, all entities of the selected type are retrieved.

It is important to note that the tModel URIs shown in the resulting tree may not all be categorized as "wsdlSpec" according to the uddi-org:types categorization system. The user may choose to load any of these URIs as a WSDL file, but they will be warned if it is not categorized as "wsdlSpec".

As before, the user may click on any node in the results tree to display properties about that node in the table.

Advanced Search

With the Advanced Search tab, the user can search the UDDI registry using any combination of Names, Keys, tModels, Discovery URLs, Categories, and Identifiers. Furthermore, it is also possible to specify the entity level in the tree to start searching from. All of these options combine to provide a very powerful search facility.

It is possible to specify search criteria for any of the categories listed above by right-clicking on the folder node in the Enter Search Criteria tree and selecting the Add menu option. It is possible to enter more than 1 search criteria of the same type, e.g. 2 search criteria of type Keys.

It is important to note that the tModel URIs shown in the resulting tree may not all be categorized as "wsdlSpec" according to the uddi-org:types categorization system. The user may choose to load any of these URIs as a WSDL file, but they will be warned if it is not categorized as "wsdlSpec".

The following list explains how to add a search criteria for each of the types listed in the Enter Search Criteria tree. All search criteria are configured by right-clicking on the folder node and selecting the Add menu option.

Names:
Simply enter a name to be used in the search in the Name field on the Name Search Criterion dialog. For example, the name could be the name of a businessEntity.

As with all name searches, the name is a partial or full name pattern with wildcards allowed as specified by the SQL-92 LIKE specification. The wild-card characters are percent '%', and underscore '_', where an underscore matches any single character and a percent matches zero or more characters.

A name search criterion may be used for businessEntity, businessService, and tModel level searches.

Keys:
On the Key Search Criterion dialog, you can specify a key to search the registry for in the Key field. The key value is a UUID (Universally Unique Identifier) value for a registry object. The Key Search Criterion can be used on all levels of searches.

If 1 or more keys are specified with no other search criteria, the keys are interpreted as the keys of the selected type of registry object and used for a direct lookup, as opposed to a find/search operation. For example, if the user enters "key1" and "key2" and selects the businessService entity type, the search will retrieve the businessService object with key "key1", and another businessService with key "key2".

If a key is entered with other search criteria, then a key criterion will be interpreted as follows:

  • For a businessService entity lookup, the key will be the businessKey of the services
  • For a bindingTemplate entity lookup, the key will be the serviceKey of the binding templates
  • Not applicable for any other object type

tModels:
The user can enter a key in the tModel Key field on the tModel Search Criterion screen. The key entered should correspond to the UUID of the tModel associated with the type of object we are searching for.

A tModel search criterion may be used for businessEntity, businessService, and bindingTemplate level searches.

Discovery URLs:
Enter a URL in the Discovery URL field on the Discovery URL Search Criterion dialog. The Use Type field is optional, but can be used to further fine-grain the search by type.

A Discovery URL search criterion may be used for businessEntity level searches only.

Categories:
The user must select a previously configured categorization system from the Type dropdown on the Category Search Criterion dialog. The dropdown is pre-populated with a list of common categorization systems. A new categorization system can be added by clicking the Add button.

On the Add/Edit Category dialog, enter a Name, Description, and UUID for the new category type in the fields provided.

Once the categorization system has been selected or added, the user must enter a value to search for in the Value field. The Name field is optional.

Identifiers:
A previously configured identification system must be selected from the Type dropdown on the Identifier Search Criterion dialog. The content of this dropdown is pre-populated with well-known identification systems. To add a new identification system, click the Add button.

On the Add/Edit Identifier dialog, enter a Name, Description, and UUID for the new identifier in the fields provided.

Options

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

Exact Match:
If this checkbox is checked, the name entered as part of the search criteria must exactly match the name specified in the UDDI registry.

Case Sensitive:
Determines whether the name entered by the user must match the case of that stored in the registry.

Sort by Ascending Name:
Sorts the results alphabetically in order of ascending name.

Sort by Descending Name:
Sorts the results alphabetically in order of descending name.

AND all Keys:
Identifier search criteria will be ORed together by default. This setting will ensure they are ANDed instead.

OR all Keys:
tModel and category search criteria are ANDed by default. The selection of this setting will OR these criteria instead.

OR like Keys:
When a bag container contains multiple keyedReference elements (i.e., categoryBag or identifierBag), any keyedReference filters that come from the same namespace (e.g. have the same tModelKey value) are ORed together rather than ANDed. This allows one to say, "any of these four values from this namespace, and any of these two values from this namespace".

Combine Category Bags:
This qualifier makes the categoryBag entries of a businessEntity behave as though all categoryBags found at the businessEntity level and in all contained or referenced businessServices were combined. Searching for a category will yield a positive match on a registered business if any of the categoryBags contained within a businessEntity (including the categoryBags within contained or referenced businessServices) contains the filter criteria.

Service Subset:
This qualifier causes the component of the search that involves categorization to use only the categoryBags from directly contained or referenced businessServices within the registered data. The search results will return only those businesses that matched based on this modified behavior, in conjunction with any other search arguments provided.