UDDI

Configure UDDI Services Security

You can configure UDDI Services security options by using the UDDI Services snap-in. You can change the default authentication, encryption, and cryptography settings for a UDDI Services site.

Authentication

UDDI Services supports two basic types of authentication: UDDI publisher authentication and Windows authentication. Understanding the differences between these modes of authentication is an important part of determining which method to use for a specific UDDI Services deployment.

• UDDI Publisher Authentication: Supports authenticated publications using UDDI Publisher authentication, as defined in section 5.3 of the UDDI v3 Specification. All interaction with UDDI Services that uses this style of authentication occurs under the http://<server name>/uddipublic or https://<server name>/uddipublic virtual directory in IIS. The UDDI Services ASP.NET user interface supports only anonymous searching with this authentication mode.
• Windows Authentication: Supports authenticated publications using Windows Integrated Authentication. In this mode, any message passed to UDDI Services is authenticated based on the security context of the user that is generated by Windows at login. All interaction with UDDI Services that uses this type of authentication occurs under the http://<server name>/uddi or https://<servername>/uddi virtual directory in IIS. The UDDI Services ASP.NET user interface supports all functions with this authentication mode including searching, publishing, subscribing, and coordination.

To configure the authentication setting for a site, select one of the following:

• Windows Integrated and UDDI publisher authentication: Supports both Windows Integrated Authentication and UDDI Publisher authentication for publications. This is the default selection. Publication SOAP requests sent to http://<servername>/uddi or https://<servername>/uddi should use Windows Integrated Authentication and publication SOAP requests sent to http://<servername>/uddipublic or https://<servername>/uddipublic should use UDDI Publisher Authentication.
• UDDI publisher authentication: Supports UDDI Publisher authentication only for publications. If this option is selected, publication SOAP requests should be sent to http://<servername>/uddipublic or https://<servername>/uddipublic.
• Windows Integrated publisher authentication: Supports Windows Integrated Authentication only for publications. If this option is selected, publication SOAP requests should be sent to http://<servername>/uddi or https://<servername>/uddi.
  
  
  • Authentication for read (inquiry) access: If this option is selected, this UDDI Services site mandates the use of Windows Integrated Authentication for UDDI Inquiry API requests into this site.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure.

To select an authentication type

1. Click Start, point to All Programs, point to Microsoft UDDI Services, and then click UDDI Services Management Console.
2. In the console tree, click the UDDI Services site that you want to configure.
3. On the Action menu, click Properties.
4. Click the Security tab.
5. Under Authenticated access, select the authentication type that you want to use, and then click OK.

Encryption

The use of Secure Sockets Layer (SSL) for publishing updates to the UDDI Services site is automatically selected during UDDI Services Basic configuration. SSL encryption provides increased security for communication between client computers and the UDDI Services Web Application. If you do not want to use SSL encryption, you can use Custom configuration to clear the Require SSL for publication to this UDDI Services site option on the Configure UDDI Services Database Component page. When using SSL encryption with UDDI Services, you must configure a server certificate for the Internet Information Services (IIS) service that hosts the UDDI Services Web Application and then create an HTTPS binding for the Web site. For more information about configuring server certificates on a Web server, see Configuring Server Certificates in IIS 7.0 at http://go.microsoft.com/fwlink/?LinkID=64327 . After the UDDI Services are configured, you can still enable or disable the SSL option by using the UDDI Services snap-in.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure.

To enable or disable SSL

1. Click Start, point to All Programs, point to Microsoft UDDI Services, and then click UDDI Services Management Console.
2. In the console tree, click the UDDI Services site that you want to configure.
3. On the Action menu, click Properties.
4. Click the Security tab.
5. Under Secure Communications, select or clear the Require SSL for publication requests to this site check box.
6. Click OK.

Cryptography

You can change the default key settings that are used for UDDI publisher authentication. Cryptography settings include the following:

• SOAP authentication token expiration: SOAP authentication tokens communicate publisher credentials for UDDI publisher authenticated publications.
• Cryptography key time-out: The cryptography key is used to generate SOAP authentication tokens.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure.

To change cryptography settings

1. Click Start, point to All Programs, point to Microsoft UDDI Services, and then click UDDI Services Management Console.
2. In the console tree, click the UDDI Services site that you want to configure.
3. On the Action menu, click Properties.
4. Under Cryptography, click Change, and then modify one of the following:
   1. SOAP Authentication Token Expiration:
      
      Use the up or down arrow to change the time, in minutes, after which tokens that are issued for publication will expire.
   2. Cryptography Key Timeout:
      
      To reset the cryptography key that is used to encrypt SOAP authentication tokens now, click Reset Now.
      
      To automatically reset the cryptography key after a certain number of days, select the Automatically reset cryptography key check box, and then specify the number of days by using the up or down arrow.
5. Click OK twice.

UDDI Web Service

UDDI WEB SERVICES

Important Points

• The UDDI data model defines a generic structure for storing information about a business and the Web services it publishes. The UDDI data model is completely extensible, including several repeating sequence structures of information.
• However, WSDL is used to describe the interface of a web service. WSDL is fairly straightforward to use with UDDI.
  
• WSDL is represented in UDDI using a combination of businessService, bindingTemplate, and tModel information.
  
• As with any service registered in UDDI, generic information about the service is stored in the businessService data structure, and information specific to how and where the service is accessed is stored in one or more associated bindingTemplate structures. Each bindingTemplate structure includes an element that contains the network address of the service and has associated with it one or more tModel structures that describe and uniquely identify the service.
  
• When UDDI is used to store WSDL information, or pointers to WSDL files, the tModel should be referred to by convention as type wsdlSpec, meaning that the overviewDoc element is clearly identified as pointing to a WSDL service interface definition.
  
• For UDDI, WSDL contents are split into two major elements the interface file and the implementation file.
  

The Hertz reservation system web service provides a concrete example of how UDDI and WSDL work together. Here is the <tModel> for this web service:

<tModel authorizedName="..." operator="..." tModelKey="..."> <name>HertzReserveService</name> <description xml:lang="en"> WSDL description of the Hertz reservation service interface </description> <overviewDoc> <description xml:lang="en"> WSDL source document. </description> <overviewURL> http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" keyName="uddi-org:types" keyValue="wsdlSpec"/> </categoryBag> </tModel>

Key Points:

• The overviewURL element gives the URL to where the service interface definition WSDL file can be found. This allows humans and UDDI/WSDLaware tooling to locate the service interface definition.
• The purpose of the keyedReference element in the categoryBag is to make sure that this tModel is categorized as a WSDL specification document.

UDDI WEB SERVICES

UDDI  WEB SERVICES

Consider a company XYZ wants to register its contact information, service description, and online service access information with UDDI. The following steps are necessary:

1. Choose an operator with which to work. Each operator has different terms and conditions for authorizing access to its replica of the registry.
2. Build or otherwise obtain a UDDI client, such as those provided by the operators.
3. Obtain an authentication token from the operator.
4. Register information about the business. Include as much information as might be helpful to those searching for matches.
5. Release the authentication token.
6. Use the inquiry APIs to test the retrieval of the information, including binding template information, to ensure that someone who obtains it can use it successfully to interact with your service.
7. Fill in the tModel information in case someone wants to search for a given service and find your business as one of the service providers.
8. Update the information as necessary to reflect changing business contact information and new service details, obtaining and releasing a new authentication token from the operator each time. Whenever you need to update or to modify the data you've registered, you have to go back to the operator with which you entered the data.

The following examples how the XYZ Company would register its information and how a distributor interested in carrying the XYZ's product line might find information about how to contact the company and place an order, using the XYZ.com Web services.

Creating Registry:

After obtaining an authentication token from one of the operators-Microsoft, for example-the XYZ.com developers decide what information to publish to the registry and use one of the UDDI tools provided by Microsoft. If necessary, the developers can also write a Java, C#, or VB.NET program to generate the appropriate SOAP messages. Here is an example.

POST /save_business HTTP/1.1 Host: www.XYZ.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "save_business" <?xml version="1.0" encoding="UTF-8" ?> <Envelope xmlns="http://schemas/xmlsoap.org/soap/envelope/"> <Body> <save_business generic="2.0" xmlns="urn:uddi-org:api_v2"> <businessKey=""> </businessKey> <name> XYZ, Pvt Ltd. </name> <description> Company is involved in giving Stat-of-the-art.... </description> <identifierBag> ... </identifierBag> ... </save_business> </Body> </Envelope>

This example illustrates a SOAP message requesting to register a UDDI business entity for SXYZ Company. The key element is blank because the operator automatically generates the UUID key for the data structure. Most fields are omitted for the sake of showing a simple example.
Company XYZ can always execute another save_business operation to add to the basic information required to create a business entity.

Retrieving Information:

After XYZ Company has updated its UDDI entry with the relevant information, companies that want to become XYZ distributors can look up contact information in the UDDI registry and obtain the service descriptions and the access points for the two Web services that XYZ.com publishes for online order entry: preseason bulk orders and in-season restocking orders.
This example illustrates a sample SOAP request to obtain business detail information about the XYZ Company. Once you know the UUID, or key, for the specific business that's been registered, you can use it in the get_businessDetail API to return specific information about that business.

POST /get_businessDetail HTTP/1.1 Host: www.XYZ.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "get_businessDetail" <?xml version="1.0" encoding="UTF-8" ?> <Envelope xmlns="http://schemas/xmlsoap.org/soap/envelope/"> <Body> <get_businessDetail generic="2.0" xmlns="urn:uddi-org:api_v2"> <businessKey="C90D731D-772HSH-4130-9DE3-5303371170C2"> </businessKey> </get_businessDetail> </Body> </Envelope>

UDDI Interface

UDDI INTERFACE

A registry is no use without some way to access it. The UDDI standard version 2.0 specifies two interfaces for service consumers and service providers to interact with the registry.
Service consumers use Inquiry Interface to find a service, and service providers use Publisher Interface to list a service.
The core of the UDDI interfaces is the UDDI XML Schema definitions.These define the fundamental UDDI data types through which all the information flows.

The Publisher Interface:

The Publisher interface defines sixteen operations for a service provider managing its entries in the UDDI registry:

• get_authToken: Retrieves an authorization token.All of the Publisher interface operations require that a valid authorization token be submitted with the request.
• discard_authToken: Tells the UDDI registry to no longer accept a given authorization token. This step is equivalent to logging out of the system.
• save_business: Creates or updates a business entity's information contained in the UDDI registry.
• save_service: Creates or updates information about the web services that a business entity provides.
• save_binding: Creates or updates the technical information about a web service's implementation.
• save_tModel: Creates or updates the registration of abstract concepts managed by the UDDI registry.
• delete_business: Removes the given business entities from the UDDI registry completely.
• delete_service: Removes the given web services from the UDDI registry completely.
• delete_binding: Removes the given web service technical details from the UDDI registry.
• delete_tModel: Removes the specified tModels from the UDDI registry.
• get_registeredInfo: Returns a summary of everything the UDDI registry is currently keeping track of for the user, including all businesses, all services, and all tModels.
• set_publisherAssertions: Manages all of the tracked relationship assertions associated with an individual publisher account.
• add_publisherAssertions: Causes one or more publisherAssertions to be added to an individual publisher's assertion collection.
• delete_publisherAssertions: Causes one or more publisherAssertion elements to be removed from a publisher's assertion collection.
• get_assertionStatusReport: Provides administrative support for determining the status of current and outstanding publisher assertions that involve any of the business registrations managed by the individual publisher account.
• get_publisherAssertions: Obtains the full set of publisher assertions that is associated with an individual publisher account.

The Inquiry Interface:

The inquiry interface defines ten operations for searching the UDDI registry and retrieving details about specific registrations:

• find_binding: Returns a list of web services that match a particular set of criteria based on the technical binding information.
• find_business: Returns a list of business entities that match a particular set of criteria.
• find_ltservice: Returns a list of web services that match a particular set of criteria.
  
• find_tModel: Returns a list of tModels that match a particular set of criteria.
• get_bindingDetail: Returns the complete registration information for a particular web service binding template.
• get_businessDetail: Returns the registration information for a business entity, including all services that entity provides.
• get_businessDetailExt: Returns the complete registration information for a business entity.
• get_serviceDetail: Returns the complete registration information for a web service.
• get_tModelDetail: Returns the complete registration information for a tModel.
• find_relatedBusinesses: Discovers businesses that have been related via the uddi-org:relationships model.

UDDI xml schema

UDDI XML SCHEMA UDDI includes an XML Schema that describes four five data structures: businessEntity businessService bindingTemplate tModel publisherAssertion businessEntity data structure: The business entity structure represents the provider of web services. Within the UDDI registry, this structure contains information about the company itself, including contact information, industry categories, business identifiers, and a list of services provided. Here is an example of a fictitious business's UDDI registry entry: <businessEntity businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40" operator="http://www.ibm.com" authorizedName="John Doe"> <name>Acme Company</name> <description> We create cool Web services </description> <contacts> <contact useType="general info"> <description>General Information</description> <personName>John Doe</personName> <phone>(123) 123-1234</phone> <email>jdoe@acme.com</email> </contact> </contacts> <businessServices> ... </businessServices> <identifierBag> <keyedReference tModelKey="UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823" name="D-U-N-S" value="123456789" /> </identifierBag> <categoryBag> <keyedReference tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" name="NAICS" value="111336" /> </categoryBag> </businessEntity> businessService data structure: The business service structure represents an individual web service provided by the business entity. Its description includes information on how to bind to the web service, what type of web service it is, and what taxonomical categories it belongs to: Here is an example of a business service structure for the Hello World web service <businessService serviceKey="uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A" businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"> <name>Hello World Web Service</name> <description>A friendly Web service</description> <bindingTemplates> ... </bindingTemplates> <categoryBag /> </businessService Notice the use of the Universally Unique Identifiers (UUIDs) in the businessKey and serviceKey attributes. Every business entity and business service is uniquely identified in all UDDI registries through the UUID assigned by the registry when the information is first entered. bindingTemplate data structure: Binding templates are the technical descriptions of the web services represented by the business service structure. A single business service may have multiple binding templates. The binding template represents the actual implementation of the web service. Here is an example of a binding template for Hello World <bindingTemplate serviceKey="uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A" bindingKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"> <description>Hello World SOAP Binding</description> <accessPoint URLType="http"> http://localhost:8080 </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="uuid:EB1B645F-CF2F-491f-811A-4868705F5904"> <instanceDetails> <overviewDoc> <description> references the description of the WSDL service definition </description> <overviewURL> http://localhost/helloworld.wsdl </overviewURL> </overviewDoc> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate> Because a business service may have multiple binding templates, the service may specify different implementations of the same service, each bound to a different set of protocols or a different network address. tModel data structure: The tModel is the last core data type, but potentially the most difficult to grasp. tModel stands for technical model. A tModel is a way of describing the various business, service, and template structures stored within the UDDI registry. Any abstract concept can be registered within UDDI as a tModel. For instance, if you define a new WSDL port type, you can define a tModel that represents that port type within UDDI. Then, you can specify that a given business service implements that port type by associating the tModel with one of that business service's binding templates. Here is an example of A tModel representing the HelloWorldInterface port type <tModel tModelKey="uuid:xyz987..." operator="http://www.ibm.com" authorizedName="John Doe"> <name>HelloWorldInterface Port Type</name> <description> An interface for a friendly Web service </description> <overviewDoc> <overviewURL> http://localhost/helloworld.wsdl </overviewURL> </overviewDoc> </tModel> publisherAssertion data structure: This is a relationship structure putting into association two or more businessEntity structures according to a specific type of relationship, such as subsidiary or department. The publisherAssertion structure consists of the three elements fromKey (the first businessKey), toKey (the second businessKey) and keyedReference. The keyedReference designates the asserted relationship type in terms of a keyName keyValue pair within a tModel, uniquely referenced by a tModelKey. <element name="publisherAssertion" type="uddi:publisherAssertion" /> <complexType name="publisherAssertion"> <sequence> <element ref="uddi:fromKey" /> <element ref="uddi:toKey" /> <element ref="uddi:keyedReference" /> </sequence> </complexType>

THREE ELEMENTS OF UDDI

THREE ELEMENTS OF UDDI A business or company can register three types of information into a UDDI registry. This information is contained into three elements of UDDI. These three elements are : (1) White pages: This category contains: Basic information about the Company and its business. Basic contact information including business name, address, contact phone number etc. A unique identifiers for the company tax IDs. This information allows others to discover your web service based upon your business identification. (2) Yellow pages: This category contains: This has more details about the company, and includes descriptions of the kind of electronic capabilities the company can offer to anyone who wants to do business with it. It uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes and the like to make it easier for companies to search through the listings and find exactly what they want. (3) Green pages: This category contains technical information about a web service. This is what allows someone to bind to a Web service after it's been found. This includes: The various interfaces The URL locations Discovery information and similar data required to find and run the Web service. NOTE: UDDI is not restricted to describing web services based on SOAP. Rather, UDDI can be used to describe any service, from a single web page or email address all the way up to SOAP, CORBA, and Java RMI services.

UDDI INFORMATION

UDDI INFORMATION:

What is UDDI?

UDDI is an XML-based standard for describing, publishing, and finding Web services.

• UDDI stands for Universal Description, Discovery and Integration.
• UDDI is a specification for a distributed registry of Web services.
• UDDI is platform independent, open framework.
• UDDI can communicate via SOAP, CORBA, Java RMI Protocol.
• UDDI uses WSDL to describe interfaces to web services.
• UDDI is seen with SOAP and WSDL as one of the three foundation standards of web services.
• UDDI is an open industry initiative enabling businesses to discover each other and define how they interact over the Internet.

UDDI has two parts:

• A registry of all a web service's metadata including a pointer to the WSDL description of a service
• A set of WSDL port type definitions for manipulating and searching that registry

---

History of UDDI

• UDDI 1.0 was originally announced by Microsoft, IBM, and Ariba in September 2000.
• Since the initial announcement, the UDDI initiative has grown to include more than 300 companies inclduing Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, and Sun.
• May 2001, Microsoft and IBM launched the first UDDI operator sites and turned the UDDI registry live.
• June 2001, UDDI announced Version 2.0.
• As of this writing, the Microsoft and IBM sites implement the 1.0 specification and plan 2.0 support in the near future
• Currently UDDI is sponsored by OASIS

---

Partner Interface Processes - PIPs

Partner Interface Processes (PIPs) are XMLbased interfaces that enable two trading partners to exchange data. Dozens of PIPs already exist. Few are listed here:

• PIP2A2 : Enables a partner to query another for product information.
• PIP3A2 : Enables a partner to query the price and availability of specific products.
• PIP3A4 : Enables a partner to submit an electronic purchase order and receive acknowledgment of the order
• PIP3A3 : Enables a partner to transfer the contents of an electronic shopping cart.
• PIP3B4 : Enables a partner to query status on a specific shipment.

---

Private UDDI Registries

As an alternative to using the public federated network of UDDI registries available on the Internet, companies or industry groups may choose to implement their own private UDDI registries.
These exclusive services would be designed for the sole purpose of allowing members of the company or of the industry group to share and advertise services amongst themselves.

However, whether the UDDI registry is part of the global federated network or a privately owned and operated registry, the one thing that ties it all together is a common web services API for publishing and locating businesses and services advertised within the UDDI registry.

UDDI

What is UDDI?
UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web services protocol stack.UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.

First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.

Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services.

The data captured within UDDI is divided into three main categories:

White Pages:
                         This includes general information about a specific company. For example, business name, business description, and address.
Yellow Pages: 
                          This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.
Green Pages:           
                           This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.
You can view the Microsoft UDDI site, or the IBM UDDI site. The complete UDDI specification is available at uddi.org.

How do I get started with Web Services?

The easiest way to get started with Web services is to learn XML-RPC. Check out the XML-RPC specification or read my book, Web Services Essentials. O'Reilly has also recently released a book on Programming Web Services with XML-RPC by Simon St.Laurent, Joe Johnston, and Edd Dumbill.
Once you have learned the basics of XML-RPC, move onto SOAP, WSDL, and UDDI. 

Does the W3C support any Web service standards?
The World Wide Web Consortium (W3C) is actively pursuing standardization of Web service protocols. In September 2000, the W3C established an XML Protocol Activity. The goal of the group is to establish a formal standard for SOAP. A draft version of SOAP 1.2 is currently under review, and progressing through the official W3C recommendation process.

On January 25, 2002, the W3C also announced the formation of a Web Service Activity. This new activity will include the current SOAP work as well as two new groups. The first new group is the Web Services Description Working Group, which will take up work on WSDL. The second new group is the Web Services Architecture Working Group, which will attempt to create a cohesive framework for Web service protocols.

UDDI AND WSDL

Relationship between UDDI and WSDL

The Universal Description, Discovery, and Integration (UDDI) specification defines a way to publish and discover information about Web services. UDDI has two functions: (1) it is a SOAP-based protocol that defines how UDDI clients communicate with registries, and (2) it is a particular set of globally replicated registries.
Registering a service involves four core data structure types:

• The businessEntity data type contains information about the business that has a published service.
• The businessService data type is a description of a Web service.
• The bindingTemplate data type contains technical information for determining the entry point and construction specifications for invoking a Web service.
• The tModel data type provides a reference system to assist in the discovery of Web services and acts as a technical specification for a Web service.

For more information on the UDDI data types, refer to the related reference topics at the end of this topic.
Web Services Description Language (WSDL) is an XML-based standard specification for describing Web services. WSDL defines an XML format for describing network services as a set of endpoints that operate on messages that contain either document-oriented or procedure-oriented information.
The WSDL service description can be structured in many ways. However, to assist with publishing and finding WSDL service descriptions in a UDDI registry, WSDL documents consist of two main parts:

• The service interface definition describes the abstract type interface and its protocol binding, known as the WSDL binding document
• The service implementation definition describes the service access location information, known as the WSDL service document

When creating Web services with the Apache Axis run-time environment, the Web services tools create a single WSDL document when generating Web services from Java™ beans or EJBs. This WSDL document contains both the service interface and implementation documents.
A service interface is described by a WSDL document that contains the types, import, message, portType, and binding elements. A service interface contains the WSDL service definition that will be used to implement one or more services. It is an abstract definition of a Web service, and is used to describe a specific type of service. This document can reference another service interface document using an import element. The Web services tools in this product generate a service interface document that contains only the message and portType elements that are referenced by the binding document that contains only bindings for the portType.
The service implementation document contains the service elements. A service implementation document contains a description of a service that implements a service interface. At least one of the import elements will contain a reference to the WSDL service interface document; however monolithic WSDL such as that created using the Axis run-time environment does not have imports. A service implementation document can contain references to more than one service interface document.
A service provider hosts a Web service and makes it accessible using protocols such as SOAP/HTTP and SOAP/JMS. The Web service is described by the WSDL documents that are stored on the provider's server or in a special repository. The WSDL documents are referenced by UDDI business services (service documents) and tModels (binding documents). These pointers enable discovery of a Web service by a service requestor.
Figure 1. Relationship between UDDI and WSDL.

Figure 1 illustrates the relationship between UDDI and WSDL. The WSDL service element references the WSDL binding element. The URL of the document containing the WSDL binding element is published to the UDDI business registry as a tModel. The URL of the document containing the WSDL service element is published to the UDDI business registry as a businessService and contains information about the bindingTemplate. For more information on UDDI registry data structure types, refer to the related reference section at the end of this document. Note that the import portion of the diagram is optional depending on the run-time environment; monolithic WSDL such as that created using the Axis run-time environment does not have imports.
The service implementation describes an instance of a service. The instance is defined using a WSDL service element. The service element in a service implementation document is used to publish a UDDI businessService. When publishing a WSDL service description, a service interface must be published as a tModel before a service implementation is published as a businessService.
A service implementation is published in a UDDI registry as part of a businessService with one or more bindingTemplate elements. The businessService is published by the service provider. A new businessService is created for a service element that is defined in the service implementation document. A new bindingTemplate element is created within a businessService for each port element that is defined within a service element.