![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The development of the schema for Web Services Description Language (WDSL), completed by IBM, Microsoft and Ariba in September, was really only the beginning of the efforts to enhance the infrastructure for Web Services. The Universal Description, Discovery and Integration (UDDI) initiative of 130 companies, including the teams behind WSDL, is another, even more fundamental piece. As the picture develops there is already word of how these specifications will begin to sprout practical implementations -- ranging from IBM's broad-ranging AlphaWorks tools to the Microsoft.NET gambit. This wave of tools from the corporate stakeholders in Web services will first of all find themselves in larger frameworks, typically built tightly into those frameworks.
But there is no need to wait for the integrated WSDL tools before beginning to fit the format into current applications. There is much that can be done with WSDL with no more than the World Wide Web Consortium's all-purpose toolkit: the Extensible Stylesheet Language for Transforms (XSLT). XSLT is without doubt one of the W3C's resounding successes. It has seen well over two dozen implementations, stand-alone and embedded in products. For this article, you should be familiar with XSLT and the Resource Description Framework (RDF).
IT has proven popular with users from seasoned programmers to harassed webmasters simply trying to make Web magic with this new XML buzzword. But most of all, it has been the vanguard tool for testing out the numerous spawn of XML. Eric van der Vlist used XSLT to shoehorn XML Inclusions into oblivious parsers before the ink was dry on the specification. Rick Jeliffe's Schematron, powered by XSLT, has provided a way to validate many XML vocabularies using namespaces, while XML Schemas continues its slow development. In fact, cheekily enough, there is even a Schematron validator for the XML Schema. In this spirit, we shall use XSLT as our probe for an early look at WSDL in practice, in this article.
Developers of Web service white and yellow pages, as well as the service providers themselves will be interested in displaying data from WSDL descriptions in various report and catalog formats. XSLT is an excellent tools for such data extraction and reporting.
In the first WSDL article (see Resources), we gave as an example a description of a service for querying professional snowboarders who endorse particular product. The request and response in this service are transmitted using Simple Object Access Protocol (SOAP). Listing 1 is an XSLT transform that presents a succinct table of the services available as specified in the description. The transport and location of these services are also extracted.
It is a rather complex transform even for such a simple purpose. Part of the complexity lies in the fact that WSDL 1.0 plays tricks with content. For example, relationships are specified in attributes using the qualified name form from XML Namespaces. However, XSLT 1.0 provides no tools for namespace expansion outside the scope of XML Namespaces. This is actually something that has been discussed in XSLT circles as a welcome addition to XSLT 1.1 since so many specifications, WSDL, XML schemas and XSLT itself, use qualified names in content. Such facilities would make Listing 1 much simpler.
Listing 1, template 1.1 simply sets up the HTML boilerplate. Next, there are a series of look-up tables using keys. Not all of the keys are actually used in the listing, but I show look-up tables 1.1 through 1.4 within Listing 1 to illustrate the basic pattern. The keys gather the element nodes representing the top-level WSDL components, indexed by their name elements.
Lookup table 1.5 is a more interesting beast. Later in the transform, we will list the transport specified during the binding of each port. WSDL specifies this in an element with the local name "binding". Lookup table 1.5 captures this element in each WSDL binding element.
Template 1.2 puts out a table for each WSDL service element. Most of
it is run-of-the-mill XSLT. It uses a "pull" model (explicit loops and
probing values with XPath) rather than a "push" model (template matches)
to cut to the data of interest in a straightforward manner. The central
loop puts out a row for each port in the service element. After the label
the location attribute is displayed from the element with local
name "address". Note that the local name alone is checked because WSDL
specifies two "address" element types: one for SOAP and one for HTTP; in
addition, extensions are allowed for which our transform would have some
support.
Next comes the transport that uses the
binding-uri
variable,
and that in turn uses binding-local-name. Both of these variables
are defined right inside the xsl:for-each. In the binding-local-name
definition you can see what I meant about the problem with qualified names
in the attribute. To match the contents of the port's binding attribute
against the corresponding WSDL binding element, we must strip away the
namespace prefix, as accomplished by the substring-after() function.
The binding-uri variable uses binding-local-name as an index into
lookup table 1.5, which if you recall maps the name of each binding to
the namespace URI of its transport-specific binding element. In our example,
binding-uri
works out to the SOAP URI: http://schemas.xmlsoap.org/wsdl/soap/.
Back in the third table cell, binding-uri is used as a index into
look-up table 6 which converts namespace URIs into descriptive strings
such as "SOAP".
Look-up table 1.6 is worth a close look because it uses an advanced
XSLT technique. It builds up the lookup-table right in the stylesheet,
using a distinct namespace. You can see the x:ns-to-binding elements
right below the key. If you are familiar with keys, you are aware that
they define indices that will be built on the nodes in the original source
document that match the pattern in the match attribute. What is
not as well known is that every time an additional source document is loaded
with the XSLT document() function, all keys are applied to it
as well. The xsl:variable just before the transform's end tag
uses a special form of document() call to load the stylesheet
itself as an additional source document. Thus the nodes in the stylesheet
that match the ns-to-binding are indexed. This is a very useful
technique for setting up a look-up table without having to hack at the
source document or depend on an additional file. You'll see it in use again
later in this article.
[uogbuji@borgia wsdlxslt]$ 4xslt http://uche.ogbuji.net/articles/wsdl/endorsementservice.xml http://uche.ogbuji.net/articles/wsdl/wsdlservicesummary.xslt |
As you can see I have made the original sample WSDL source and the listing 1 stylesheet available online. See the Resources section for more details. Figure 1 shows the resulting output of this transformation.
Figure 1. Browser view of the output from applying the stylesheet in listing 1
It should be straightforward to follow how this transform could be extended to extract additional information such as message parts from the WSDL source. In the next section we discuss a more involved and differently-focused use of XSLT transforms.
In the last article on WSDL, we discussed a likely RDF form for WSDL. WSDL is all about description, as is RDF, and so I noted that RDF would have been an ideal form for WSDL. Luckily, since RDF is so flexible, it was possible to come up with an RDF-compliant format not a great deal different from the WSDL original. Now we'll have a look at how the transformation could be automated.
The transform in Listing 2 can be used to convert our WSDL sample from the first article into the RDF version given as example in the second one.
The first thing to note is that while the transform in Listing 1 used
more of a "pull" model (based on the xsl:for-each instruction)
to render the various ports within a service, this stylesheet is almost
entirely based on "push" techniques. Templates with carefully-chosen matches
and appropriate modes set the execution path. Most beginning XSLT users are
more comfortable with pull techniques because they are more natural to
one familiar with the procedural model of, say ECMAScript. Thus, the above
transform might require a bit more digestion, but it is a good general
model for transforms that make non-structural adjustments from one XML
format to another.
Template 2.1 starts things off. xsl:copy is used to copy the
wsdl:description
element over. The first xsl:apply-templates copies over
its attributes.
The second xsl:apply-templates attempts to copy over the child
elements, but note carefully that it does not specify a mode. If you look
at the rest of the listing, you will you'll see that for the WSDL wsdl:types
this would be matched by template 2.7 that just recursively continues
the process of copying the sub-tree rooted at that element. As soon as
we get to the next child of wsdl:description, the story changes.
wsdl:message
elements match to template 2.4, which is an empty procedure. The effect so
far is that all WSDL element children except for wsdl:types are
suppressed.
The third xsl:apply-templates does the same thing, but specifies
the convert-to-rdf mode. The processor then encounters wsdl:types
once again, but this time matches template 2.6, which is another empty procedure.
All the other top-level WSDL elements, however, are handled by template
2.2 -- it begins the process of conversion to RDF format. Of course this
portion of the output is wrapped in an rdf:RDF element, as required.
The rest of the transform is mostly a continuation of these mechanics.
Remember from last article that conversion to RDF in the top-level children
is done by adding an rdf:ID attribute, taken from the original
name
attribute. This is done explicitly using xsl:attribute in template
2.2. Also note that we had to add an explicit namespace to each attribute
of the top-level WSDL elements. This is handled by template 2.5, which
matches attributes in the convert-to-rdf mode. Note that it uses
the lookup table that we set up and that this table employs the technique
of loading the stylesheet as source document. The lookup table maps namespace
URIs to prefixes used in output.
Children of top-level WSDL elements are treated somewhat differently,
as in templates 2.3 and 2.4. These different approaches correspond to simplifications
we chose in our RDF representation, such as leaving wsdl:message/wsdl:part
elements as anonymous resources and converting @message attributes
to rdf:resource attributes.
Using 4XSLT again, the output of this transform with the original WSDL source is similar to the RDF version in the last article. Even if you are not interested in WSDL in RDF format, the above stylesheet is a starting framework for many sorts of WSDL adjustments.
At its core, WSDL is very simple: no more than a description of online services. However, because of the cachet of its backers and the important groundwork laid by UDDI, it is bound to find its way into a wide variety of applications. The Rich Site Summary (RSS) system shows an example of how simple formats can have wide-ranging uses. The techniques introduced in this article illustrate several approaches to processing WSDL using XSLT transforms.
The pull approach in the Listing 1 is useful for simple online reporting and cataloging, especially when you need an easy tweak of the transform. In such cases the output rarely bears much structural resemblance to the input and it makes sense to just pick and choose the material for output. The pull approach in listing 2 is useful for transforms that operate within the same structural basis as WSDL. For instance, you might want to view a WSDL file with extensions removed or maybe extract WSDL documentation elements at all levels for an API summary. It might also be useful to re-cast the WSDL relationships as XLinks. Such links could be internal, or in the case where WSDL imports are used to break up the description, they may be external links. Going even further, as an extended facility, Links could be processed into external resources outside of WSDL's import facilities. Such a transform would not look too different from listing 2.
Hopefully this series of articles has given a useful introduction to WSDL and provided some tools for beginning to work with the format using currently available XML technologies. As WSDL, UDDI and other such technologies mature and converge, there will be an ever-improving core of applications and service-providers taking advantage of such applications. This may someday bring the dream of smooth integration of Web services a bit closer to reality.
-
Other examples of how XSLT is used to bootstrap XML technology implementations.
Eric van der Vlist explains in
this article how to use XSLT to process XML inclusions before parsers
can catch up. Rick Jeliffe's Schematron
in its XSLT incarnation is the ready tool to validate many XML vocabularies
unsuited for DTD.
- Luckily there are now several good resources for learning XSLT. Everyone
who has even thought about XSLT should have Michael Kay's brilliant book XSLT
Programmer's Reference, Wrox Press, Inc., January, 2000 (ISBN: 1861003129).
- Crane Softwrights Ltd. publishes an excellent
handbook on using XSLT: Practical
Transformation Using XSLT and XPath (Eighth Edition; ISBN: 1-894049-05-5).
- Also see Dr. Miloslav Nic's comprehensive online
tutorial.
- I used 4XSLT to test
and run the stylesheets in the listings.
Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a consulting firm specializing in XML solutions for enterprise knowledge management applications. Fourthought develops 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Mr. Ogbuji is a Computer Engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can reach him at uche@ogbuji.net.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
