Using XSLT for WSDL processing

The pattern development of the Web Services Description Language (WDSL), which IBM, Microsoft, and Ariba completed in September, is actually just the beginning of an attempt to enhance the Web services architecture. The common description, Discovery, and Integration (UDDI) initiatives of 130 companies, including the team behind WSDL, are a more fundamental part. As the situation progresses, it has been said that how these specifications will begin to produce the actual implementation-from IBM's broad alphaworks tools to the Microsoft.NET strategy. This batch of tools from company stakeholder in Web services will first appear in larger frameworks and are typically built tightly within those frameworks.

However, there is no need to wait for the integrated WSDL tool until the format adapts to the current application. WSDL can do a lot of things simply by extending the Stylesheet Transformation Language (XSLT) to the Universal toolset of the World Wide Web. XSLT is undoubtedly one of the most successful masterpieces of the consortium. It has more than 30 implementations that are independent and embedded in the product. When you read this article, you should be familiar with XSLT and the Resource Description Framework (RDF).

It only uses this new XML buzzword to try to make the Web more magical, deeply loved by users from experienced programmers to weary web administrators. But most importantly, it has been a pioneer tool for testing a large number of XML results. Prior to the ink of the specification, Eric van der Vlist used XSLT to insert the XML part into an imperceptible parser. Rick Jeliffe's XSLT-supported Schematron provides a way to identify many XML vocabularies that use namespaces, and the XML schema is still slow to evolve. In fact, it is extremely shameless to even have an XML schema of the Schematron confirmation. In this mood, we will use XSLT as a probe in this article to look at the actual WSDL.

Searching for data in WSDL

Developers of WEB services white pages and Yellow pages, as well as service providers themselves, are interested in displaying WSDL descriptions in various reports and catalog formats. XSLT is an excellent tool for this kind of data extraction and reporting.

In the first WSDL article (see Resources), we give an example of a service description that describes a professional skier who queries a specific product. The requests and responses in this service are transmitted using Simple Object Access Protocol (SOAP). Listing 1 is an XSLT transformation that shows the available services concise tables specified in the description. The delivery and location of these services are also extracted.

Even for such a simple purpose, transformations are quite complex. Part of the complexity is the way WSDL 1.0 handles content. For example, a relationship is specified using a property of a qualified name form from an XML namespace. However, XSLT 1.0 does not provide a tool for handling namespace extensions outside the scope of the XML namespace. This has actually been discussed in the XSLT world as an additional part of XSLT 1.1, because many specifications (WSDL, XML schema, and XSLT itself) use qualified names in the content. These facilities will make listing 1 much simpler.

Listing 1, template 1.1 simply sets the HTML template file. Next, there are some query tables that use keys. Not all keys are actually used in the list, but I show tables 1.1 through 1.4 in the list to demonstrate the basic pattern. The key gathers the element node representing the top-level WSDL component, which is retrieved by its name element.

Query Table 1.5 is more interesting. In the subsequent transformations, we will list the transfers specified during the binding of each port. The WSDL is specified in the element with the local name "binding". Query table 1.5 captures the element in each WSDL binding element.

Template 1.2 outputs a table for each WSDL service element. Most of them are ordinary XSLT. It uses the "pull" model (explicit looping and XPath values) instead of the "push" model (template matching) to cut the data of interest in a direct way. The central loop outputs one row for each port in the service element. After the label, the Location property is displayed from an element with the local name "address". Note that only local names are checked, because WSDL specifies two types of "address" elements: one for SOAP, the other for HTTP, and some extensions that are supported by our transformations.

The next step is to use the Binding-uri variable and use the Binding-local-name transfer in turn. Both of these variables are defined in Xsl:for-each. In the Binding-local-name definition, you can see what I mean by the qualified name in the attribute. To match the contents of the port binding property with the corresponding WSDL binding element, the namespace prefix must be dropped, as completed by the Substring-after () function.