Oracle® Fusion Middleware
Part 32. Common Configuration

A Web Services Description Language (WSDL) file defines the interface to a Web Service, or list of services. It lists the operations exposed by the service, the wire format for operation requests, and the data types in the request body. It also specifies the location of the Web Service as a URL that clients can access to use the exposed operations. For example, the Policy Studio can extract this information from the WSDL file to generate the following filters, which can be incorporated into policies:

You can use WSDL files to register Web Services in the Web Services Repository and to add XML Schemas to the global Schema Cache. The 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 Web Service Repository. For details on how to publish WSDL files, see Publishing WSDL Files to a UDDI Registry.

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

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:

You can search the UDDI registry according to a whole range of search criteria, which is of key importance to the Policy Studio. You can search the registry 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, 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.

Because UDDI terminology is used in Policy Studio screens 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. tModels 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:

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:

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.

You first need to select the UDDI registry that you want 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 Connecting to a UDDI Registry.

Select Locale:

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

When you have configured a UDDI registry connection, you can search the registry using a variety of different search options on the Search tab. WSDL Search is the default option. This enables you to search for the UDDI entries that the WSDL file is mapped to. You can also do this using the Advanced Search option. The following different types of WSDL searches are available:

WSDL portType (UDDI tModel):

Searches for a uddi:tModel that corresponds to a wsdl:portType. You can enter optional search criteria for specific categories in the uddi:tModel (for example, Namespace of portType).

WSDL binding (UDDI tModel):

Searches for a uddi:tModel that corresponds to a wsdl:binding. You can enter optional search criteria for specific categories in the uddi:tModel (for example, Name of binding, or Binding Transport Type).

WSDL service (UDDI businessService):

Searches for a uddi:businessService that corresponds to a wsdl:service. You can enter optional search criteria for specific categories in the uddi:businessService (for example, Namespace of service).

WSDL port (UDDI bindingTemplate):

Searches for a uddi:bindingTemplate that corresponds to a wsdl:port. This search is more complex because a serviceKey is required to find a uddi:bindingTemplate. This means that at least two queries are carried out, first to find the uddi:businessService, and another to find the uddi:bindingTemplate.

For example, a bindingTemplate contains a reference to the tModel for the wsdl:portType. You can use the tModel key to find all implementations (bindingTemplates) for that wsdl:portType. The search looks for businessServices that have bindingTemplates that refer to the tModel for the wsdl:portType. Then with the serviceKey, you can find the bindingTemplate that refers to the tModel for the wsdl:portType.

In all cases, click Next to start the WSDL search. The Search Results tree shows the tModel URIs as top-level nodes. These URIs are all WSDL URIs, and you can use these to generate policies on import by selecting the URI, and clicking the Finish button.

You can click 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 depend on the type of the node that is selected. 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).

The Quick Search option enables you to search the UDDI registry for a specific tModel name or category.

tModel Name:

You can enter a tModel Name for a fine-grained search. This 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.

Categories:

You can select one of the following options to search by:

Click Next to start the search. The Search Results tree shows the tModel URIs as top-level nodes. These URIs are all WSDL URIs, and you can use these to generate policies on import by selecting the URI, and clicking the Finish button.

You can click 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 depend on the type of the node that is selected. 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).

The Name Search option enables you to search for a businessEntity, businessService or tModel by name. In the Select Registry Data Type, select one of the following UDDI entity levels to search for:

You can enter a name in the Name field to narrow the search. You can also use wildcards in the name. The name applies 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.

Click the Search button to start the search. The search results display the matching entities in the tree. For example, if you enter MyTestBusiness for Name, and select businessEntity, this searches for a businessEntity with the name MyTestBusiness. Child nodes of the matching businessEntity nodes are also shown. tModels are displayed in the results if any child nodes of the businessEntity refer to tModels. Only referred to tModels are displayed. The same applies if you search for a businessService. If you select tModel, and search for tModels, only tModels are displayed.

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).

UDDI v3 Name Searches

By default, a UDDI v3 name search is an exact match. To perform a search using wildcards (for example, %, _, and so on), you must select the approximateMatch find qualifier in the Advanced Options tab. This applies to anywhere you enter a name for search purposes (for example, Name Search, Quick Search, and Advanced Search).

The Advanced Search option enables you to search the UDDI registry using any combination of Names, Keys, tModels, Discovery URLs, Categories, and Identifiers. You can also specify the entity level to search for in the tree. All of these options combine to provide a very powerful search facility. You can specify search criteria for any of the categories listed above by right-clicking the folder node in the Enter Search Criteria tree, and selecting the Add menu option. You can enter more than one search criteria of the same type (for example, two Key search criteria).

The following options enable you 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 the folder node, and selecting the Add menu option.

Names:

Enter a name to be used in the search in the Name field in the Name Search Criterion dialog. For example, the name could be the businessEntity name. The name is a partial or full name pattern with wildcards allowed 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. A name search criterion can be used for businessEntity, businessService, and tModel level searches.

Keys:

In the Key Search Criterion dialog, you can specify a key to search the registry for in the Key field. The key value is a Universally Unique Identifier (UUID) value for a registry object. You can use the Key Search Criterion on all levels of searches. If one 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, instead of a find/search operation. For example, if you enter key1 and key2, and select the businessService entity type, the search retrieves the businessService object with key key1, and another businessService with key key2.

If you enter a key with other search criteria, a key criterion is interpreted as follows:

tModels:

You 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 you 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. You can use a Discovery URL search criterion for businessEntity level searches only.

Categories:

Select a previously configured categorization system from the Type drop-down list in the Category Search Criterion dialog. This pre-populated with a list of common categorization systems. You can add a new categorization system using the Add button.

In the Add/Edit Category dialog, enter a Name, Description, and UUID for the new category type in the fields provided. When the categorization system has been selected or added, enter a value to search for in the Value field. The Name field is optional.

Identifiers:

Select a previously configured identification system from the Type drop-down list in the Identifier Search Criterion dialog. This is pre-populated with well-known identification systems. To add a new identification system, click the Add button.

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

Select Registry Data Type:

Select one of the following UDDI entity levels to search for:

The search also displays child nodes of the matching nodes. tModels are also returned if they are referred to.

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

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. Adding a businessEntity

To add a business, perform the following steps:

Adding a tModel

To add a tModel, perform the following steps:

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 the UDDI Definitions section. For details on how to publish Web Services automatically using a wizard, see Publishing WSDL Files to a UDDI Registry.

For more details on UDDI entities such as businessEntity and tModel, see the UDDI Definitions section.