At this point, a question remains: How does the client application identify and understand how to invoke the methods and procedures of a particular Web service? This is the function of WSDL, the XML-based industry standard that describes the content and format of SOAP messages used to interact with a particular Web service.

The developer of a Web service typically has design and development tools to automatically generate WSDL files. Thus, they can design and generate a WSDL file that defines the Web service interface to the business logic they have written (or will write) for an application server. The typical developer of a client application also has code generators that can read this WSDL file and automatically generate the code required to construct and parse SOAP messages to access the Web service from within their client application.

Because the WSDL files used to define Web services conform to industry standards, the Web services development platform used to make the application server accessible as a Web service is completely independent from the Web service client development platform. Each platform can thus be provided by different vendors as long as they both generate conforming SOAP messages. This means that if the client developer knows how to read WSDL and the Web service developer knows how to write WSDL, and both have the understanding to generate and interpret compatible SOAP messages, they can each manually write all their own code to (respectively) invoke Web service operations and serve Web service clients. However, as for most programming languages and Internet standards, many available client and Web service development platforms provide tools and code libraries to make Web services programming much more productive.