As described earlier, a BIS service program describes its API using a 01-level group item named SOAP-Request-Response. This data item has specific naming conventions that describe input and output parameters for each method within the web service. The XSLT that describes the transformation from the basic XML document that is exported from SOAP-Request-Response to the WSDL XML document that is returned to the web client is named cobol_to_wsdl.xsl.
cobol_to_wsdl.xsl differs somewhat from other 'normal' XSLT used with XML Extensions. While most XSLT are focused on rearranging data being exported from or imported to the COBOL program, cobol_to_wsdl.xsl instead uses the metadata in the XML document being exported from the COBOL web service program to create another metadata document, the WSDL. The metadata used consists of the values of some parameters, the element names (resulting from the naming conventions used), and information exported due to the use of XML ENABLE ATTRIBUTES.
Let's have a brief review of the naming conventions found in SOAP‑Request‑Response. Each method in the web service is defined by a group item immediately subordinate to SOAP‑Request‑Response with the name methodname ‑‑method‑parameters (note the two hyphens after methodname), where methodname is the name of the method being defined. Within each of these groups, one to three group items, named input‑parameters, output‑parameters and/or input‑output‑parameters, may be defined. The first use of this naming convention can be seen at the beginning of the first <xsl:template>, where a variable named $methods is created and contains all the elements whose names end in ‑‑method‑parameters. The $methods variable is then used throughout the rest of the template to iterate over all methods.
Let's look at the major sections of cobol_to_wsdl.xsl, which correspond to the four sections of a WSDL.
The internal schema, which contains most of the complexity of a WSDL, is created inside the <wsdl:types> element. While there is a fairly large amount of code involved, this essentially involves iterating over all the methods and creating XML Schema descriptions of each of the request and response parameters. Special attention is paid to arrays (OCCURS) and to structures (COBOL group items). In particular, arrays must be named in a manner such that the arrays can be identified by the naming convention in an incoming SOAP request where the metadata of the COBOL structure is not available to assist interpretation. 'Wrapper' request and response elements are also created which conform to the requirements of document/literal wrapped SOAP requests.
Next, the <wsdl:message> elements are created for each method, followed by the <wsdl:operation> elements (within the <wsdl:portType> element). These elements are relatively simple in document/literal wrapped SOAP requests.
Finally, the <wsdl:operation> elements for each method are generated within the <wsdl:binding> element. The WSDL is then completed with the <wsdl:service> element creation.