SOAP is a transport protocol for carrying XML payloads over lower level Internet protocols. Specifications of the transport prior to 1.2 built in a suggested encoding of XML that is geared towards the serialization of programming language constructs. Such encodings are the staple of what is known as remote procedure call (RPC) systems, which have the common aim of making requests to remote computers look just like local procedure invokations. Other examples of RPC encodings are External Data Representation (XDR), from "classic" RPC (and defined in RFC 1014), and Common Data Representation (CDR) from CORBA. As a result of bundling an encoding with such relatives, SOAP took on a decidedly application-programming feel, and its usefulness for general data exchange seemed suspect.

These early flavors of SOAP generated much controversy. Firstly, mixing transport and data encoding specifications seems to be a very messy approach to communications, and seems to fly in the face of layered protocols that have been the practice in networking for decades. After all, the specification for HTML mark-up is not embedded into the HTTP specification. Secondly, choosing an RPC-like encoding for pre-eminence puts SOAP in an odd spot; it has little more expressive power than pre-XML RPC mechanisms, yet it is practically guaranteed to be less efficient because of XML's verbosity and the more generic architectures of HTTP, SMTP, and the like. It would seem that the only advantage SOAP brought as a next-generation RPC was to unify the Microsoft and CORBA camps; this is important, but certainly not what SOAP appeared to be promising.

One important down-side consequence of SOAP-as-RPC is that such a system is completely unsuitable for the next-generation-EDI ambitions of Web services in general. If Web services are to become the new way businesses communicate over networks, they would seem to need a transport mechanism that communicates at the level of business and legal requests, rather than at the level of programming language APIs. And surely enough, the ebXML initiative, whose ambition is to use XML to craft a system for international electronic business communication, originally balked at using SOAP, as did a few other influential organizations.

Things have settled down a bit since then. SOAP 1.2 has somewhat relaxed the dependence on the special encoding (relegating it to a separate "adjuncts" section), and most players are now on board with SOAP, including ebXML. Most SOAP implementations still use the special SOAP encoding exclusively, but there are signs that this state of affairs will open up more, with plug-in architectures for wider choice of encodings, addressing a greater set of communication problems. One such problem is the exchange of metadata, including metadata that helps determine the semantics used in other XML documents transmitted using SOAP.

Resource Description Framework (RDF) is a modeling system with some facilities for addressing just such metadata exchange. This article will look at how RDF can be used with SOAP for the encoding of such metadata, or even at how data instances encoded in RDF can be directly transmitted without a translation to the SOAP encoding. Familiarity with SOAP and RDF are required. See Resources for more on these topics. Also, see the Thinking XML column in the IBM developerWorks XML zone for on-going discussion of RDF and other XML technologies related to knowledge management.

The good ship RDF

First of all, I'll show what you can do if you have RDF to ship from one system to another care of SOAP. I'll take an example from the on-going issue-tracker project discussed in my Thinking XML column on XML zone (see Resources). Let's say that we want to exchange details of an issue that has been added to a system to a remote machine. This might be the basis for a decentralized, distributed issue tracker. An example of what an issue looks like in RDF serialization is shown in Listing 1.

<?xml version="1.0"?>
<rdf:RDF xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
         xmlns:dc="http://purl.org/dc/elements/1.1#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xml:base="http://rdfinference.org/versa/issues">
  <it:issue rdf:ID="0101">
    <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/>
    <dc:identifier>0101</dc:identifier>
    <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/>
    <dc:date>2002-01-27</dc:date>
    <dc:title>Data type conversions</dc:title>
    <dc:description>Not all the data type conversions listed make sense.  
	In particular the question of how to convert numeric types to resources 
	and vice versa require much thought.</dc:description>
  </it:issue>
</rdf:RDF>

This is an example issue raised against a Web resource. The issue itself is identified by the URI http://rdfinference.org/versa/issues#0101. This is determined by taking the base URI of the document and adding a fragment as given by the rdf:ID attribute on the typed node representing the issue. The base URI of the document (or to be precise, of the document element, and therefore of the typed node element itself) is given as http://rdfinference.org/versa/issues using an xml:base attribute. You then make several statements about the issue itself, most importantly giving the resource to which the issue refers using the dc:relation metadata tag from Dublin Core. You also provide an identifier, which is just an abbreviation of the full URI of the issue for friendly display, the creator of the issue, date submitted, brief title, and verbose description.

Remember that this is RDF, and thus the XML serialization is not the most important matter, but rather how this translates to an abstract RDF model. For instance, Figure 1, generated by Triclops, an RDF visualization tool that comes with 4Suite 0.12.0 alpha 1 or more recent (warning: this generates a pretty wide image). You can also generate a similar graph using Dan Brickley's on-line RDF visualizer.

Now I'll look at two ways of transmitting this model in a SOAP message; first of all by translation to the SOAP encoding, and then directly, encoding in RDF.

Using the SOAP encoding

First of all, you must come up with a method for the transmission. The RDF you have defined is a bundle of data, and the idea is to pass along this bundle of data in a message, which you name according to what we expect the recipient to do with the data. In this case, you are notifying the remote server that there is a new issue to track. Therefore I have called the method newIssue. Note that since for now, you are using the SOAP encoding, you might as well keep your method names suitable for the programming languages that have SOAP bindings for RPC.

You then have to find a way to transmit the new issue object. You do so by transmitting the ID of the new object, and its properties. Basically, you peel off each property of the new issue object and convert to a message parameter. Because the SOAP encoding is heavy on type information, you must decorate each parameter with a type (see Listing 2).

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
   <itsoap:newIssue 
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap"
     xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
     xmlns:dc="http://purl.org/dc/elements/1.1#"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:xs="http://www.w3.org/2001/XMLSchema">
     <dc:identifier xsi:type="xs:nonNegativeInteger">0101</dc:identifier>
     <dc:relation xsi:type="xs:anyURI">http://rdfinference.org/versa/0/2</dc:relation>
     <dc:creator xsi:type="xs:anyURI">mailto:uche.ogbuji@fourthought.com</dc:creator>
     <dc:date xsi:type="xs:date">2002-01-27</dc:date>
     <dc:title xsi:type="xs:string">Data type conversions</dc:title>
     <dc:description xsi:type="xs:string">Not all the data type conversions listed 
	make sense.  	In particular the question of how to convert numeric types to 
	resources and vice versa require much thought.</dc:description>
   </itsoap:newIssue >
 </env:Body>
</env:Envelope>

All values are placed in the contents of elements, as required by the SOAP encoding rules, this includes values that were marked as resources in the RDF, and are thus given the data type anyURI. Note that this allows values that are URI references as well as full URIs (that is, relative URIs and fragments are allowed). If you say that all such messages will have this format, you can avoid having to reiterate the data types each time by defining an XML schema definition for the message element, which can then be placed in a Web Services Description Language (WSDL) element or communicated in some other out-of-band manner. Listings 3 and Listing 4 are fragments (with root elements and namespace declarations elided) from such schemata (given separately because they would occupy different target namespaces).

<!-- with target namespace = http://rdfinference.org/schemata/issue-tracker/soap -->
<xsd:element name="newIssue">
  <xsd:complexType>
    <xsd:all>
      <xsd:element ref="dc:identifier"/>
      <xsd:element ref="dc:relation"/>
      <xsd:element ref="dc:creator"/>
      <xsd:element ref="dc:date"/>
      <xsd:element ref="dc:title"/>
      <xsd:element ref="dc:description"/>
    </xsd:all>
  </xsd:complexType>
</xsd:element>

<!-- with target namespace = http://purl.org/dc/elements/1.1# -->
<xsd:element name="identifier" type="xsd:nonNegativeInteger"/>
<xsd:element name="relation" type="xsd:anyURI"/>
<xsd:element name="creator" type="xsd:anyURI"/>
<xsd:element name="date" type="xsd:string"/>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="description" type="xsd:string"/>

These would allow the SOAP message to be simplified as in Listing 5.

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
   <itsoap:newIssue 
     env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap"
     xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
     xmlns:dc="http://purl.org/dc/elements/1.1#"
   >
     <dc:identifier>0101</dc:identifier>
     <dc:relation>http://rdfinference.org/versa/0/2</dc:relation>
     <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator>
     <dc:date>2002-01-27</dc:date>
     <dc:title>Data type conversions</dc:title>
     <dc:description>Not all the data type conversions listed make sense.  
	In particular the question of how to convert numeric types to resources 
	and vice versa require much thought.</dc:description>
   </itsoap:newIssue >
 </env:Body>
</env:Envelope>

Sending raw RDF

As I argued at the beginning of this article, there is no reason you should have to mutate our SOAP message into RPC form in order to use SOAP. If you are not locked in by the need for RPC integration into other systems, you can take the more natural course, the declarative approach of sending the data and leaving the remote system free to process it as seen fit. There is no official RDF encoding for SOAP yet, but this discussion is based on the conventions and prescriptions of RDF and SOAP.

The simplest approach is simply to make the rdf:RDF element the single top-level element of the SOAP body, as illustrated in Listing 6.

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
<rdf:RDF env:encodingStyle="http://rdfinference.org/rdfws/soap-encoding"
         xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
         xmlns:dc="http://purl.org/dc/elements/1.1#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
>
  <it:issue rdf:about="http://rdfinference.org/versa/issues#0101">
    <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/>
    <dc:identifier>0101</dc:identifier>
    <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/>
    <dc:date>2002-01-27</dc:date>
    <dc:title>Data type conversions</dc:title>
    <dc:description>Not all the data type conversions listed make sense.  
	In particular the question of how to convert numeric types to resources 
	and vice versa require much thought.</dc:description>
  </it:issue>
</rdf:RDF>
 </env:Body>
</env:Envelope>

The encoding ID used, http://rdfinference.org/rdfws/soap-encoding is non-normative, and basically codifies the enbedding of RDF/XML directly into the body of a SOAP message. One key difference between the message form and the plain form is that rdf:about is used to identify the issue resource, however, it is not declared in-line using an ID. This is an important principle for serializing RDF models for SOAP transmission: to avoid in-line declarations. Given that we could fix the base location for the ID using xml:base, such a principle might seem unnecessary, but it is hard to imagine any clear semantics for the life-cycle and ownership of in-line transmitted resources. Note that they cannot be avoided in all cases. For instance, anonymous resources (AKA blank nodes) may need to be transmitted as part of descriptions, and by definition they have no proper identifier.

Back to top

Conclusion

There are other approaches and ideas when it comes to how SOAP and RDF can inter-operate, and indeed it is a topic of constant interest as RDF users discover Web services and vice versa. References to some of this discussion are provided in the Resources section. Certainly more generic systems for serializing XML-based data will only enrich the world Web services.

Resources

• Introduction to RDF, by Uche Ogbuji, provides a basic introduction to RDF and includes links to other useful resources.
  
  
• The Dublin Core metadata initiative maintains a vocabulary for describing library-like metadata on the Web.
  
  
• The Web services (r)evolution, Part 3: How SOAP Works by Graham Glass takes a close look at SOAP (an older variation).
  
  
• SOAP Version 1.2 Part 0: Primer, one of the W3C working drafts for SOAP. This is an excellent introduction to SOAP 1.2.
  
  
• Uche Ogbuji's Thinking XML column.
  
  

• Examples of how RDF models might be serialized in SOAP, by Henrik Frystyk Nielsen.
  
  

• 4Suite, a suite of XML and RDF tools co-developed by Uche Ogbuji.
  
  
• Dan Brickley's RDF visualizer is handy for generating RDF graphs, if you already have the serialized XML available on the Web.
  
  

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.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The good ship RDF
• 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

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers