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.
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.
Listing 1: What the WSDL description of snow boarding endorsement search would have looked like in valid RDF syntax.
<?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
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.
types specification could still have been inserted wholly
into the RDF model by specifying the
but then we would have had all the problems that come with
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
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
Another change you'll notice is that all the previously un-prefixed attributes
now have had prefixes added. There is an RDF abbreviation
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
message/part element has property attributes but no
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
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
binding element to retain its original structure.
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
element is given the URI:
note the explicit drawing of
rdf:type properties, which in listing 1 were
implicit in the use of typed nodes rather than
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
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.
Listing 3. RDF Schema range constraint
<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 "
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.
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.
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
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
You might also be interested in using the RDF
schema visualization tool against Listing 2.
There are many SVG resources at the W3C's
- Except for the diagram generation, I used 4RDF
for working with and testing the RDF files and schemas for this article.
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 firstname.lastname@example.org.