Wherefore art thou, WSDL document?

After reading and re-reading Erl's sections on WSDL [1, p?-?] and UDDI [1, p?-?], I find that I understand why WSDL is useful, but that I don't understand how a web services architect or developer actually uses a WSDL record in a practical sense.

So I had two questions: where does a WSDL document live, and how is it used? Is the WSDL record processed by a tool automatically, or do humans simply read the record and use it to guide code development? Do web services themselves access WSDL records -- is there machine to machine communication and automatic setup of interfaces going on with WSDL at the center?

Where the WSDL document lives: UDDI Registry

Finding the interface to a web service is part of a process called service discovery: where is the service, and how do I talk to it?

One way to publish WSDL records is using a UDDI registry: users look in the registry for the service they want, and retrieve the WSDL record from the UDDI registry [1]. The abstract portion of the WSDL service description is published in the registry as a UDDI businessService, while the concrete prortion of it is published as a UDDI tModel [2]. Both the businessService and tModel entities are configured to refer to a URL which points at the relevant part of the WSDL document.

Here's an example tModel section of a UDDI record which refers to a specific binding (SingleSymbolBinding) in a WSDL document referenced as a URI (this code lifted verbatim from [2]):

<?xml version="1.0"?>
<tModel tModelKey="">
  <name>http://www.getquote.com/StockQuoteService-interface</name>

  <description xml:lang="en">
    Standard service interface definition for a stock quote service.
  </description>

  <overviewDoc>
    <description xml:lang="en">
      WSDL Service Interface Document
    </description>
    <overviewURL>
      http://www.getquote.com/services/SQS-interface.wsdl#SingleSymbolBinding
    </overviewURL>
  </overviewDoc>

  <categoryBag>
    <keyedReference tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"
                    keyName="uddi-org:types" keyValue="wsdlSpec"/>
    <keyedReference tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384" 
                    keyName="Stock market trading services" 
                    keyValue="84121801"/>
  </categoryBag>
</tModel>

And here (also lifted verbatim from [2]) is an example businessService section describing the interface that uses that binding. Note that the bindingTemplate refers to the tModel entry from above, and that it also references a URI for the abstract portion of the WSDL document:

  <businessService businessKey="..." serviceKey="...">
  <name>StockQuoteService</name>

  <description xml:lang="en">
    Stock Quote Service
  </description>

  <bindingTemplates>
    <bindingTemplate bindingKey="..." serviceKey="...">
      <description>
        Single Symbol Stock Quote Service
      </description>
      <accesssPoint URLType="http">
        http://www.getquote.com/singlestockquote
      </accessPoint>
      <tModelInstanceDetails>
        <tModelInstanceInfo tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384">
          <instanceDetails>
            <overviewURL>
              http://www.getquote.com/services/SQS.wsdl
            </overviewURL>
          </instanceDetails>
        </tModelInstanceInfo>
      </tModelInstanceDetails>
    </bindingTemplate>
  </bindingTemplates>

  <categoryBag>
    <keyedReference tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384" 
                    keyName="Stock market trading services" 
                    keyValue="84121801"/>
  </categoryBag>
</businessService>

Where the WSDL document lives: no UDDI Registry

Without a UDDI registry, a WSDL record may simply live on the Internet on a URI, or even in the local filesystem. Pilgrim says, "A WSDL file is just that: a file. More specifically, it's an XML file. It usually lives on the same server you use to access the SOAP web services it describes, although there's nothing special about it" [3]. Presumably the developer who is writing code to interact with the service described a WSDL document so located must locate the WSDL document manually.

Using the WSDL document

It seems like developers who are writing code to interface with a web service download the WSDL document and either generate code from it manually, use a tool to generate it stub code which can be later fleshed out by the developer. Examples of such code generators are WSD2Java from the AXIS, the Apache web services project, wsdl2py from the Zolera Soap Infrastructure for python, or the wsdl.exe generator for C# from microsoft.com.