The Web Services Description Language (WSDL) (see Resources) specification provides a simple XML-based vocabulary for describing XML-based Web Services that are available over the network. The services themselves communicate using the Simple Object Access protocol (SOAP), HTTP, SMTP, or by some other means; WSDL, however, gives the user the meta-data required to set up the communications. WSDL itself says nothing about how to publish or publicize such service descriptions, leaving this to other specifications. Universal Description, Discovery and Integration (UDDI), an initiative for creating directories of Web Services, defines one framework for cataloging and dispatching WSDL descriptions, but it is just emerging and is quite complex.

UDDI does some hefty lifting for online contracts, and should certainly find its place soon in the distributed services arena. However, since the first likely WSDL deployments will be in tightly closed systems rather than over the open Web, there is probably a better alternative. There is a more natural early entry for WSDL cataloging and discovery in the form of the Resource Description Framework (RDF). RDF is the mechanism developed by the World Wide Web Consortium (W3C) to encode and manager Web metadata (see Resources). It provides simple methods to integrate large quantities of metadata in multiple domains.

To help provide a framework for this article, you may want to read my previous article, "Using WSDL with SOAP Applications" (see Resources), where I explore the function of a WSDL specification through a specific example that describes a service for snow boarding experts to offer endorsements to vendors in their industry. This article discusses ways of harnessing RDF's simplicity and power to augment WSDL's descriptive ability. To gain familiarity with RDF, RDF Schemas, and the basic XML representations of RDF, which will be important to understand the rest of this work, please review the RDF information links in the Resources section.

The could-have-been of RDF and WSDL

All that WSDL provides could really have been written in the RDF Serialized format. It is an odd choice by IBM, Microsoft, and Ariba not to consider this. Other somewhat similar standards, such as RDF Site Summary (RSS), show how XML resource description formats can be expressed as an XML serialization of RDF. This doesn't make sense for all standards -- one would hardly have expected the Scalable Vector Graphics (SVG) working group, for instance, to design SVG around RDF. However, when most of the information represents brief labels and relationships between resources, RDF makes a lot of sense due to its growing array of users and tools.

For example, I have modified the snow boarding example using a WSDL specification discussed above to use a RDF serialized format as seen in 1.

 <?xml version="1.0"?>
 <definitions name="EndorsementSearch"
   targetNamespace="http://namespaces.snowboard-info.com"
   xmlns:es="http://www.snowboard-info.com/EndorsementSearch.wsdl"
   xmlns:esxsd="http://schemas.snowboard-info.com/EndorsementSearch.xsd"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:w="http://schemas.xmlsoap.org/wsdl/"
   xmlns="http://schemas.xmlsoap.org/wsdl/">
   <types>
     <schema targetNamespace="http://namespaces.snowboard-info.com"
             xmlns="http://www.w3.org/1999/XMLSchema">
       <element name="GetEndorsingBoarder">
         <complexType>
           <sequence>
             <element name="manufacturer" type="string"/>
             <element name="model" type="string"/>
           </sequence>
         </complexType>
       </element>
       <element name="GetEndorsingBoarderResponse">
         <complexType>
           <all>
             <element name="endorsingBoarder" type="string"/>
           </all>
         </complexType>
       </element>
       <element name="GetEndorsingBoarderFault">
         <complexType>
           <all>
             <element name="errorMessage" type="string"/>
           </all>
         </complexType>
       </element>
     </schema>
   </types>
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
     <message w:name="GetEndorsingBoarderRequest"
              rdf:ID="GetEndorsingBoarderRequest">
       <part w:name="body" w:element="esxsd:GetEndorsingBoarder"/>
     </message>
     <message name="GetEndorsingBoarderResponse"
              rdf:ID="GetEndorsingBoarderResponse">
       <part w:name="body" w:element="esxsd:GetEndorsingBoarderResponse"/>
     </message>
     <portType w:name="GetEndorsingBoarderPortType"
               rdf:ID="GetEndorsingBoarderPortType">
       <operation w:name="GetEndorsingBoarder">
         <input rdf:resource="GetEndorsingBoarderRequest"/>
         <output rdf:resource="GetEndorsingBoarderResponse"/>
         <fault rdf:resource="GetEndorsingBoarderFault"/>
       </operation>
     </portType>
     
     <binding w:name="EndorsementSearchSoapBinding"
              w:type="es:GetEndorsingBoarderPortType"
              rdf:ID="EndorsementSearchSoapBinding">
       <soap:binding soap:style="document"
                     soap:transport="http://schemas.xmlsoap.org/soap/http"/>
       <operation rdf:about="GetEndorsingBoarder">
         <soap:operation
           soap:soapAction="http://www.snowboard-info.com/EndorsementSearch"/>
         <input>
           <soap:body soap:use="literal"
             soap:namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
         </input>
         <output>
           <soap:body soap:use="literal"
             soap:namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
         </output>
         <fault>
           <soap:body soap:use="literal"
             soap:namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
         </fault>
       </operation>
     </binding>
     
     <service w:name="EndorsementSearchService"
              rdf:ID="EndorsementSearchService">
       <documentation>snowboarding-info.com Endorsement Service</documentation> 
       <port rdf:about="GetEndorsingBoarderPort">
         <binding rdf:resource="EndorsementSearchSoapBinding"/>
         <soap:address soap:location="http://www.snowboard-info.com/EndorsementSearch"/>
       </port>
     </service>
   </rdf:RDF>
 </definitions>

These changes basically take a section of the description and encode it into RDF serialization. As required by the RDF Model and Syntax 1.0 Recommendation (RDF M&S) (see Resources), this section is enclosed in an rdf:RDF element. If you were to feed this into an RDF processor, you would get a huge wealth of information that neatly maps out the qualifications and relationships that make up the WSDL description. I used every RDF serialization trick available to minimize the changes from the original XML structure. It's a neat illustration of how hard the RDF working group must have worked on RDF M&S to allow existing XML formats to be shoe-horned into valid RDF form. Note that this is also a source of great controversy as the many tricks available lead to a certain brittleness about the translation from the various syntaxes and the resulting RDF abstract model.

I left the types element out of the RDF section. The main problem is that the contents of this section are really completely outside the domain of WSDL. The W3C or some other Web standards body might come up with a standard mapping from XML schemas to RDF, and other data-typing methodologies might do the same, but this is really an activity of a completely different scope. The types specification could still have been inserted wholly into the RDF model by specifying the parseType="Literal" attribute, but then we would have had all the problems that come with parseType="Literal": notably, that RDF M&S explicitly disavows definition of equivalence between literals containing markup (it could have said, for example, that two literals with markup are equivalent if their reduction to Canonical XML is identical). This would mean that we could never reliably compare what we stored in the RDF model with any other data. In practice, this makes parseType="Literal" quite useless and so I didn't bother.

In the section that was converted to RDF, the most noticeable change is the addition of rdf:ID attributes to the core WSDL elements. This is how RDF handles what the WSDL authors tried to do with qualified names in attributes: to establish relationships between abstract entities. You can see where the references to these identified resources are made by using the rdf:resource attribute.

Another change you'll notice is that all the previously un-prefixed attributes now have had prefixes added. There is an RDF abbreviation that allows namespace-resolved attribute names to be treated as property names. The attribute value then forms the literal value of a statement. I used this abbreviation heavily in Listing 1. Namespaces on property names are not strictly required for RDF, but are highly recommended as a way to disambiguate such names. If you were to put this WSDL meta-data in a model containing other information, there is a good chance that such a commonly-used label such as "name" would clash with another property representing, say, the name of a person or an organization. Since XML Namespaces 1.0 does not allow application of the default namespace to attributes, we must explicitly specify the prefix to disambiguate.

In some cases, such as message parts, I used anonymous resources. Note that the message/part element has property attributes but no rdf:ID or rdf:about attribute. I chose to do so because it seemed to me that one would rarely need to refer to a message part outside the context of its message, and that such an operation is the only reason not to make it anonymous. Otherwise I would have had to make up a unique ID (not as natural as for the top-level resources), used XPointer in an rdf:about attribute, or some other gimmick. I went with what feels most natural.

A few final notes. You can see that I used rdf:about in the service element to add a statement about the port I had previously described as its subject. This is another example of taking advantage of the flexibility of RDF syntax to minimize mutation from the original WSDL. Further, you can see how useful RDF's arbitrary nesting of descriptions is, allowing our version of the binding element to retain its original structure.

Back to top

WSDL in graphic detail, thanks to RDF

In the end, my above example is not valid WSDL according to the WSDL 1.0 specification that we have been examining. Luckily, it is simple enough to generate the RDF from the official syntax, either through automated processing from the same source that provides the data in the WSDL document, or after the fact using XSLT (an example of how to do this will be presented in my next article on WSDL). The RDF representation I give in this article is still useful because it provides one concrete RDF model of the meta-data encoded in WSDL. I believe that this comes quite close to capturing all the relevant and practical statements. Thus, it is a simple matter to use any particular RDF syntax extracted from the WSDL to construct the same model.

One nice benefit of the RDF model of WSDL is that it leads directly to a handy visualization of what a WSDL model specifies. By mapping the meta-data to RDF, I have conformed it to a formalization for which RDF M&S suggests a useful representation as a directed graph. To see this in action, go to Dan Brickley's brilliant RDF visualization tool (see Resources) and enter the following URL into the URL text box: http://www-4.ibm.com/software/developer/library/ws-rdf/endorse.rdf. I have placed a copy of the document for review in Listing 1.

Have a quick look at the resulting graph. If you are using the GIF output from the visualization tool, it does require a bit of squinting, so I recommend the SVG output if you have a viewer such as Adobe SVG Plug-in (see Resources). Additionally, you can also generate 2-D Virtual Reality Markup Language (VRML) from the visualizer site. Notice that the anonymous resources have been assigned a generated Uniform Resource Identifier (URI), which is usual for RDF tools, although it differs from the sample graphs given in RDF M&S, where anonymous resources are empty ovals. For instance, the anonymous port resource enclosed in the first message element is given the URI: http://www-4.ibm.com/software/developer/library/ws-rdf/endorse.rdf#genid3. Also note the explicit drawing of rdf:type properties, which in listing 1 were implicit in the use of typed nodes rather than rdf:description elements.

Back to top

An RDF Schema for WSDL?

The type properties exposed in the diagram suggest an RDF Schema for WSDL that could be used as a formal framework for translation into an RDF model. Again, the WSDL specification provides no RDF Schema, but in Listing 2 I provide my modest proposal to the cause. It is not a complete RDF Schema for WSDL; it only covers a subset of my example in Listing 1 that, in turn, uses only a subset of WSDL, but hopefully this can be the basis for further work.

Notice first that the capitalization does not match the convention used in the RDF Schemas Candidate Recommendation (RDF Schemas). This is to avoid mutating the element-type names used by WSDL. Other than that, it is a run-of-the mill schema. I use domain- and range- constraints wherever WSDL has corresponding restrictions of internal relationships between description elements. So, for instance, since the value of the message attribute in a WSDL input element must be the name of a message, the RDF Schema uses the equivalent range constraint in the snippet in Listing 3.

 <rdf:Property ID="input">
 <rdfs:range rdf:resource="message"/>
 <rdfs:domain rdf:resource="operation"/>
 </rdf:Property>

The domain constraint in the above makes sure that the input property can only be used from an operation element, a stipulation that also comes from WSDL.

Note, however, that many of these constraints are not as strong as they could be. For instance, the element property indicates the particular element in the types section that is used by a message part. The value of this property should really be a valid qname. We should not, for instance, be able to set the string "!!42xyz??" as the value of this property because it's not even a valid XML element type name, but since we use rdfs:Literal as the range of the property, an RDF processor would allow such an error. Unfortunately, RDF Schemas provides notoriously little support for data-typing, leaving this to a later version that can take advantage of the work of the XML Schemas group.

I strategically chose my subset to exlude the SOAP operations in order to keep things simple. In order to keep the SOAP-specific statements in their own namespace, there would most likely have to be another RDF Schema file for those classes and properties, and some help from the WSDL authors in publishing the schemas. But, then again, any use of RDF Schemas, with the framework I have set up in this article, would require some help from the WSDL authors who own the base "http://schemas.xmlsoap.org/wsdl" URL (see Resources). Most RDF processors, including 4RDF which I used for this article, can help dodge this problem by allowing developers to map and override base URIs. Possibly other RDF processors can do so as well.

Back to top

On to XSLT...

By mapping WSDL to RDF, as this article discusses, service descriptions could be automatically incorporated into RDF-aware search engines and classification systems. The W3C already uses its considerable clout to encourage vendors and webmasters to use RDF to categorize their content, which should boost the value of embedded service descriptions. If so, the white and yellow pages of the "services Web" (to steal a term from XML commentator Len Bullard) become as simple as an RDF search restrained to the WSDL schema. Much simpler than the titanic framework being assembled by the UDDI folks, but that's another story altogether.

Hopefully, this article has given you some insight into how you can experiment with WSDL using the existing tools available for RDF. We looked at the internal structure of metadata relationships encoded in WSDL, brought clearly to light by the RDF conversion. We have also looked at the general process of deriving RDF Schemas and instances from non-RDF XML vocabularies. In the next article, we shall see what another core W3C technology (that is, XSLT) can do for WSDL developers and users.

Resources

• My previous article, Using WSDL with SOAP Applications, explains how WSDL works and how it applies to SOAP-based application programming
  
  
• Review the Web Services Description Language (WSDL) specification.
  
  
• The W3C maintains an RDF information page that you can review for futher information.
  
  
• To further your RDF education, try this tutorial.
  
  
• I used Dan Brickley's amazing RDF visualizer to generate an image of the WSDL description we have been discussing, available in GIF (141 KB) or SVG (27 KB) format (Download the Adobe SVG plug-in to view this file. After you install the plug-in, open any RDF file, in the plug-in or in your Web browser, to view it graphically). The RDF source is Listing 1 from this article, of which I have also made a copy available.
  
  
• You might also be interested in using the RDF schema visualization tool against Listing 2.
  
  
• There are many SVG resources at the W3C's SVG page.
  
  
• Except for the diagram generation, I used 4RDF for working with and testing the RDF files and schemas for this article.
  
  

About the author

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, the open source platform for XML middleware. 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.

Rate this article

Comments

Back to top

Table of contents

• The could-have-been of RDF and WSDL
• WSDL in graphic detail, thanks to RDF
• An RDF Schema for WSDL?
• On to XSLT...
• Resources
• About the author
• Comments

Next steps from IBM

With the no-charge DB2 Express-C, pureXML and evolving your XML schemas you can easily increase development and application performance.

---

• Try: Download a free trial version of DB2 Express-C, which includes pureXML technology that is ideally suited for managing XML schema and relational data.
• Article: See how to use DB2's pureXML schema evolution capabilities, that evolve schemas without making any changes to your applications.
• Tutorial: This tutorial shows you how using a native DB2 XML database enables changes in an existing XML schema to also appear in your application code.
• Demo: This demo shows you how easy it is to create a DB2 database for storing XML data.
• Buy: DB2 9 for Linux, UNIX and Windows

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers