About a year and a half ago, I took a close look of how the then just announced Web Services Description Language (WSDL) could benefit from interacting with Web metadata format, RDF, either at the standards level, or at the level of individual developer effort. Since then, there has been a huge amount of activity in the Web services community and in the RDF (and Semantic web) community. Some of this has been very good, as dialog between these groups has taken root, and the technologies put forth by both groups have been improved. Some has also been bad, as the press has somehow conjured up a fantastical struggle between Web services camps and Semantic Web camps at the W3C, fighting for the resources of the consortium. All these developments are a great insight into the development and interaction of next-generation technologies, but in this article, I shall distill the most important developments of interest to developers.

Updates on the standard

A number of standards changes have come about in the past year. WSDL has been updated to Version 1.1 and published as a W3C note as a starting point for work of the new Web Services Description working group of the W3C (part of the W3C Web Services Activity). This working group has published draft requirements and Use-cases, among which one very interesting requirement DR070 labeled as a "MUST" stands out:

Charter: The Working Group will provide a mapping to RDF so that the information described can be easily merged with that of other applications. This mapping will be developed with the help of the RDF Interest Group.

This brings good news that there will one day be a normative mapping between WSDL and RDF. The technical changes in WSDL 1.1 are barely significant compared to the 1.0 document, mostly consisting of typo corrections and updates of the W3C XML Schema used to the latest version at the time.

However, there have been significant changes to RDF, as the W3C's Semantic Web activity has picked up steam. The recent RDF model theory and RDF/XML syntax specifications motivate some changes to the approach I have taken for mapping from WSDL to RDF. Other factors have also weighed in. In particular, Eric Prud'hommeaux has worked to improve on my approach by trying to make a mapping of the underlying intent behind the WSDL elements, rather than my own mechanical approach to the mapping. Certainly such a mapping would be more useful for general RDF integration, and one hopes that it is such a rich mapping that it will be accepted by the Web services description working group. I, however, also had a particular aim in my own approach: to provide a mapping straightforward enough to be palatable for non-RDF-types, and as close as possible to an identity transform from XML.

With the increasing cooperation between the Web services and RDF camps, such a mechanical mapping is no longer a great necessity, so I shall look a bit more at the big picture for developers.

Back to top

Is your map up to date?

Listing 1 is my update of Eric Prud'hommeaux's update of my mapping of the WSDL for the snowboarder endorsement Web service to RDF.

Listing 1: The snowboard endorsement service in updated RDF

The endorsement-services.rdf.

I have used XML general entities to make the code more concise. I've also omitted the SOAP fault message specifications for brevity, and modified some of the namespaces used, for instance, to update the XSD namespace, and for brevity. I use RDF types that correspond to the WSDL element names for each of the resources used in the description.

One of the problems to be solved by any mapping is WSDL's approach to naming. The names of WSDL features do not have be unique for the description; the name of a port type can be the same as that of a service. WSDL itself relies on context to disambiguate this, but this is confusing and error-prone. One of the nice things about RDF is that it forces one to think clearly about identification; in this mapping, the name is relegated to a convenient notation. Globally-unique URIs provide actual identification, and needn't be seen or considered by WSDL software, although they provide important anchors to RDF software. In fact, these identifiers can be generated by mapping software as universally-unique identifiers (UUIDs) based on random numbers.

One common problem in all sorts of modeling is how to address properties and classes which are used together, represented by the same general name. For instance, in the above WSDL mapping, the relationship between a message and its part is called, naturally enough, <wsdl:part>, and the class of the value of that property is called, again quite naturally,<wsdl:Part>. This is a bit unfortunate, because it relies on syntactic details (that is, that URIs can be distinguished only by the capitalization in RDF, and most languages) to remove ambiguities. But I think that in such cases, it's better to go with the natural naming than to concoct naming tricks to get around this problem.

There is one area where this mapping tweaks the naming for clarity: in the relationship between a binding and the binding details of its relevant operation, named <wsdl:operation>, and in the relationship between this detail, represented by an unnamed in-line resource, to the abstract operation definition (from the WSDL <operation> element). The latter is named <wsdl:abstractOperation> to underline the very different conceptual meaning between these. The rest of the statements of the WSDL binding do not follow the direct approach suggested by the syntax of the original WSDL, because I tried to examine the description of the binding element in the specification to find a representation that best captures the meaning behind the concepts there.

Finally, rather than breaking down the element schema definitions into low-level descriptions, which is an important task that deserves some effort, I captured the content models of each element as whole chunks of literal schema, encoded using <rdf:parseType=Literal>. This has traditionally been a hazardous practice, because of the very incomplete specification of literal content in RDF text objects in RDF 1.0, but the RDF core working group has done some very important work in sharpening this specification based on work by the XML canonicalization and infoset working groups.

Back to top

Putting this stuff to work

The ability to aggregate arbitrary numbers of such WSDL/RDF descriptions into a database, and do global queries is one immediate benefit of this RDF mapping for developers. As an example of this, I have placed in my on-line RDF query demonstration interface the RDF in Listing 1, as well as an WSDL/RDF description I made for the issue tracker Web service I discussed in my recent SOAP/RDF article. You can now experiment with queries and get plain triples or even graphs back. Let us look at some sample queries that a developer might find useful.

Message dispatch

You can actually use this RDF description to write a flexible driver for dispatch code. You add an RDF resource representing the abstraction of the Web service itself, then add statements relating this resource to its WSDL description and to the programming module that implements it. See Listing 2 for a snippet providing an example.

<wsdl:Service rdf:about="http://snowboard-info.com/EndorsementSearch">
  <wsdl:description rdf:resource="&sb;EndorsementSearchDef"/>
  <wsdl:implementation>
    com.snowboard-info.EndorsementSearch
  </wsdl:implementation>
</wsdl:Service>

This is an HTTP Web service, as specified in the WSDL, and might be one among many. When a message comes in to the server on which these are hosted, one can get the SOAP end-point and SOAPAction from the HTTP protocol implementation, and quickly grab details such as the root element namespace and local name. Then, to execute the request, you might load the right module with the following query:

Find the code module that implements the Web service whose description specifies SOAP action and endpoint http://snowboard-info.com/EndorsementSearch, document element namespace http://snowboard-info.com and name GetEndorsingBoarder.

This query can be implemented using Versa, an RDF query language, as in Listing 3.

 1  $port = filter(
 2    type(wsdl:Port),
 3    ".-soap:address->eq(@'http://snowboard-info.com/EndorsementSearch')",
 4    ".-wsdl:binding->*
 5      -wsdl:operation->*
 6      -wsdl:soapAction->eq(@'http://snowboard-info.com/EndorsementSearch')",
 7    ".-wsdl:binding->*
 8      -wsdl:operation->*
 9      -wsdl:abstractOperation->*
10      -wsdl:input->*
11      -wsdl:part->*
12      -wsdl:element->*
13      -xsd:name->eq('GetEndorsingBoarder')",
14    ".-wsdl:binding->*
15      -wsdl:operation->*
16      -wsdl:abstractOperation->*
17      -wsdl:input->*
18      -wsdl:part->*
19      -wsdl:element->*
20      -xsd:namespace->eq(@'http://snowboard-info.com')"
21  );
22  
23  ((($port<-wsdl:port-*)<-wsdl:service-*)<-wsdl:description-*)
24     -wsdl:implementation->*

This is a pretty hairy introduction to Versa, which is generally a very simple query language (see Resources for a link to a tutorial). I've numbered the lines to guide the explanation. Line 1 begins a variable assignment (which stretches to line 21). I use white-space liberally for readabality. The core of Versa is traversal expressions, which allows you to traverse the RDF graph.

$foo - a:predicate -> *

This is a forward traversal, which follows the predicate a:predicate from the given subject foo to retrieve all objects in the model that can be reached in this way. You can narrow the resulting objects even further by replacing the * character with a boolean expression such as eq("bar"), which will only match objects which are the bar string literal. You can then use resulting objects as the starting point for a chained traversal expression in the following way:

$start-wsdl:binding->*
      -wsdl:operation->*
      -wsdl:soapAction->eq(@'http://snowboard-info.com/EndorsementSearch')

This retrieves all the SOAP actions of the operations of the bindings of the starting resource, as long as those actions are resources with URL http://snowboard-info.com/EndorsementSearch. Resources in Versa can be written either as qualified names (<wsdl:binding>), or by placing the resource URI in quotes with a leading @ character (for example, @'http://schemas.xmlsoap.org/wsdl/').

You can also traverse in the opposite direction of predicates, that is, from subject to object, using a backward traversal:

$foo <- a:predicate - *

You can see in this action in line 23 of Listing 3 as you work backwards from the $port variable defined to the abstract Web service resource to which it's indirectly related. You then move forward from that resource to its implementation to get the code module name you're seeking.

The type() function retrieves a list of all resources of given <rdf:type>. The filter() function starts with a list and narrows it down according to a set of criteria. It only passes through list items which meet all the criteria. Line 2 is the first argument, giving the initial list, and lines 3, 4, 7, and 14 start the remaining 4 arguments, representing the conditions we have set (that the description has a specified SOAP action and endpoint, and document element name and namespace).

Back to top

Conclusion

As you can see, developments in Web services and RDF provide not only richer tools for developer looking to take advantage of both, but a greater spirit of cooperation between the two efforts. The RDF query of WSDL metadata that I demonstrated can easily enough be duplicated using SQL queries, or API calls against some data binding of WSDL, but the benefit of using RDF is that one can then mix WSDL with other important RDF-based metadata, including content description and syndication formats (for example, Prism and RSS), privacy profiles (for example, P3P), and other emerging RDF applications. The more generic the management of Web services information, the more readily productivity output can be enhanced by improved integration.

Resources

• Introduction to RDF, by Uche Ogbuji, provides a basic introduction to RDF and includes links to other useful resources.
  
  
• Supercharging WSDL with RDF: Managing structured Web service metadata, by Uche Ogbuji.
  
  
• Using RDF with SOAP, by Uche Ogbuji.
  
  

• WSDL and the Wild, Wild West , in Application Development Trends
  
  
• Powering Web Services Through Metadata, in Web Services Architect.
  
  

• WSDL 1.1 is now maintained as a W3C note.
  
  
• The Web Services Description Working Group , part of the W3C Web Services Activity is charged with developing a standard description language for Web services, for which WSDL 1.1 is the likely starting point.
  
  

• Read WSDL/RDF mapping, by Eric Prud'hommeaux, an exploration of mapping between the two technologies based on my earlier explorations on developerWorks. This is a refinement of ideas he put forth earlier in his previous page, Annotated RDF WSDL Examples.
  
  
• Eric also maintains a list of resources pertaining to the Semantic Web and Web services.
  
  
• The Related Technolologies section of the W3C Semantic Web activity home page for RDF includes a section on Web services and RDF, including my developerWorks articles on SOAP/RDF and WSDL/RDF.
  
  
• Dave Beckett's compendious RDF Resource Guide includes several relevant resources as well.
  
  

• For a gentle introduction to Versa, see my step-by-step tutorial: Versa by Example.
  
  
• Web Services Development and Deployment with IBM Tools and Technologies, by Greg Flurry, covers the use of various WebSphere components in Web services development, including creating WSDL descriptions.
  
  

About the author

Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management applications. Fourthought develops 4Suite, an 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 contact Mr. Ogbuji at uche@ogbuji.net.

Rate this article

Comments

Back to top

Table of contents

• Updates on the standard
• Is your map up to date?
• Putting this stuff to work
• Conclusion
• Resources
• About the author
• Comments

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

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