| Similar in concept, yet far broader in scope and implication , is the Simple Object Access Protocol (SOAP), an emerging W3C standard for decentralized information exchange between peers in a networked environment. Designed specifically for information transfer between distributed applications and objects built on different platforms, and layered (like XML-RPC) on XML and HTTP, SOAP has the support of industry heavyweights such as Microsoft, IBM, HP, Ariba, Lotus, and SAP, and is expected to shortly reach W3C Recommendation status. SOAP is, fundamentally, a framework for stateless data exchange between systems. It is a specification for the creation of structured, typed data packets designed for easy transmission across a network. As of this writing, the SOAP specification addresses merely the structure of SOAP packets and the SOAP processing model, leaving items such as the mechanics of packet transmission and routing, packet integrity, and security to be handled at the application layer. It is not necessary that the data encoded using SOAP be an RPC request or response. SOAP can be used to transfer data of any kind ”RPC is just one example of its applications. A SOAP packet is a well- formed XML document consisting of the following three primary parts : -
The envelope that contains information on the encoding used for the SOAP packet. -
An optional header that can be used to transmit authentication information, transaction parameters, or trace data. -
The body that contains the actual data to be transmitted. In the context of this chapter, this data is either an RPC request or response (although SOAP can be used to transmit other kinds of data too). Take a look at Listing 6.4, which demonstrates the SOAP equivalent of the RPC request you saw in Listing 6.1. Listing 6.4 A SOAP Request POST /SOAPServer HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Host: some.quote.server Content-Type: text/xml Content-Length: 360 <?xml version="1.0" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://  www.w3.org/1999/XMLSchema" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/ "> <soap:Body> <getRandomQuote> <xsd:string>Shakespeare</xsd:string> </getRandomQuote> </soap:Body> </soap:Envelope> As you can see, an RPC request is encoded within the body of the SOAP packet as a series of nested elements, with the name of the first element in the body corresponding to the name of the remote procedure. Arguments to the remote procedure are specified as elements within this outermost element. Unlike XML-RPC, it is not necessary that a SOAP response return an HTTP status code of 200 OK ; rather, the SOAP specification suggests the use of standard HTTP error codes to identify whether the request was successfully received and processed . The results of a successful RPC invocation would resemble Listing 6.5 (note the Response suffix added to the element containing the return value). Listing 6.5 A SOAP Response to a Successful SOAP Request HTTP/1.0 200 OK Server: QuoteServer/SOAP Connection: close Content-Type: text/xml Content-Length: 435 <?xml version="1.0" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http:// www.w3.org/1999/XMLSchema" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Body> <getRandomQuoteResponse> <xsd:string>Good night, sweet prince, and flights of angels sing thee to thy rest.</xsd:string> </getRandomQuoteResponse> </soap:Body> </soap:Envelope> If an error occurs while processing the remote procedure, a fault is generated and returned to the client, with the fault information encoded within the body of the SOAP packet. Listing 6.6 demonstrates this with an example. Listing 6.6 A SOAP Response to an Unsuccessful SOAP Request HTTP/1.0 500 Internal Server Error Server: QuoteServer/SOAP Connection: close Content-Type: text/xml Content-Length: 545 <?xml version="1.0" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http:// www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema" soap: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Body> <soap:Fault> <faultstring xsi:type="xsd:string">Server error. Method not found. getRandomQuote</faultstring> <faultcode xsi:type="xsd:string">soap:Client</faultcode> </soap:Fault> </soap:Body> </soap:Envelope> For more information and examples, you should refer to the W3C's SOAP primer at http://www.w3.org/TR/soap12-part0/, which contains the official SOAP specification. (See the book's companion web site at http://www.xmlphp.com or http://www.newriders.com for more specific links.) You might also want to visit http://www.soapware.org/, a directory of SOAP implementations for numerous different languages and platforms. Simple Simon When it comes to data types, SOAP offers far greater flexibility than XML-RPC. This is because SOAP builds on the work done by the W3C's XML Schema Working Group, allowing developers to create and use their own named data types in their SOAP packets. The XML Schema specification defines two data types: simple and complex. Simple data types include string , int , boolean , decimal , float , double , duration , datetime , hexBinary , and base64Binary . These simple data types can be combined with each other to create new, complex data types that are customized to the specific requirements of the application. Consider Listing 6.7, which might make this clearer. Listing 6.7 Simple and Complex Data Types in an XML Schema <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <!-- a simple data type --> <xsd:element name="movie" type="xsd:string"/> <!-- a complex data type --> <xsd:element name="movie"> <xsd:complexType> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> <xsd:element name="director" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> Listing 6.7 contains two alternative definitions for the element movie . The first uses a simple data type ( string) to define the type of data expected for the movie element; the second uses a combination of two string data types to create a new more complex type definition for the same element. For more information on how XML Schema data types work, you should refer to the XML Schema specification, available on the web at http://www.w3.org/TR/xmlschema-0/. | So Many Choices . . . With so many similarities between WDDX, XML-RPC, and SOAP, you might be wondering which one to use, and when. Making the choice between these competing technologies becomes easier when you consider the problems they were originally designed to solve. WDDX was developed in order to provide a simple structured framework for typed data exchange over the web. If your application needs to exchange typed information in a client-server environment, and WDDX components are available for your platform, WDDX is usually a good bet. XML-RPC, on the other hand, is a specification focused solely on remote procedure invocation and response. As such, it is less versatile than WDDX when it comes to exchanging typed information between peers. This is not necessarily a bad thing ”if all you're interested in is RPC, XML-RPC provides you with everything you need to do your job efficiently , without bogging you down in unnecessary features or convoluted structures. SOAP, which includes ideas from both WDDX and XML-RPC, offers a more powerful and complete solution to the problem of data interchange between platforms and systems. As Eric Kidd succinctly puts it in his XML-RPC HOWTO, "If you like XML-RPC, but wish the protocol had more features, check out SOAP." [2] For a more detailed comparison of these and other XML-based protocols, take a look at the W3C's XML Protocol Matrix at http://www.w3.org/2000/03/29-XML-protocol-matrix. | [2] Kidd, Eric. "The XML-RPC HOWTO." SourceForge .Net (2001). Available from the Internet: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/ |
