 | Level: Introductory Uche Ogbuji (uche@ogbuji.net), Principal Consultant, Fourthought, Inc.
01 Nov 2000 The Resource Description Framework is the World Wide Web Consortium's official format for defining the metadata of XML objects. Conceptually, it is similar to Web Services Description Language, which is a collection of metadata about XML-based services. This article focuses on building a bridge between the two specifications. It provides an example of what a Web service description might look like as an RDF file. It then goes on to discuss how to take advantage of an RDF visualization tool to generate a graph of the WSDL data. Finally, it presents a portion of a possible RDF Schema for WSDL.
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.
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 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. |
XML's many faces
To mount the preacher's pulpit for just a moment, this is exactly what
makes XML and its related technologies so exciting. The grizzled data processing
professional will recognize little of the breathtaking insight and originality
in WSDL, RDF, and other such technologies, and rightly so. What is revolutionary
is not the data format, the abstract model, or anything in between, but
the power of collaboration between the various congruous systems that
has led so many people to rally behind XML's data-processing banner.
This means that I, a self-proclaimed lazy programmer, can gain
some brief familiarity with a new services description language, WSDL, and rapidly tweak it into a formalism in RDF. In some cases, such as RSS, this
is already done for me. Using a readily available tool, I can create a
comprehensive visualization of the abstractions originally being described.
There is some controversy about RDF and the W3C's claims for it, but
our dissection of WSDL should provide some statement that regardless of
what you think of RDF, and its well-known imperfections, it is a great
round table to have available for meta-data conversations to begin properly.
The one thing that the XML community
does seem to be first to come
to in a significant way is a commitment to extensibility across the board,
which makes such collaboration much more realistic. Well, off the pulpit
and back to work.
|
|
 |
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.
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.
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 "!!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.
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 page
| |
