Problems with SOAP

Initially and sometimes still defined as "simple" and "lightweight" [Gudgin at al, 2003], SOAP turns out to be neither. It needs XML parsers on client and server, and the overheads of using it can hardly be described as lightweight: examples of such overheads were illustrated in Section 2.4.2.5.1, and the following SOAP message contains a payload of a mere 24 bytes (in bold below) in a declared message-content total of 756 bytes.

POST /axis/services/DictServiceImpl HTTP/1.0 Content-Type: text/xml; charset=utf-8

Accept: application/soap+xml, application/dime, multipart/related, text/*

User-Agent: Axis/1.2RC3 Host: 127.0.0.1:1234 Cache-Control: no-cache

Pragma: no-cache SOAPAction: ""

Content-Length: 756

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<ns1:storeEntryInDB

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:ns1="dct">

Although the declared encoding for the XML is UTF-8, the message given above has been sent in that encoding only because the declared HTTP character set has been set to utf-8: the SOAP 1.1 content-type of ^text/xml causes the XML document encoding to be ignored, for reasons that were explained on page 45. Complexities of character encoding thus further detract from the so-called simplicity of SOAP.

With this example, the source of the problem is that the version of SOAP supported in the release of Axis that was used for the service is still 1.1. Axis 1.3 has more support for SOAP 1.2²⁴, which requires the content-type to be more specifically application/soap+xml as a means of avoiding the confusion of a SOAP message with any other type of XML content. Because even Axis 1.3 is still an implementation of JAX-RPC 1.1, and defaults still to SOAP 1.1, it uses HTTP

POST for nearly all its SOAP requests, despite the inclusion in version 1.2 of the safer,

idempotent HTTP GET. (Section 7.2.1, however, contains a simple example of the way in which it is possible to use HTTP GET with Axis 1.2.)

24 The API in Axis 1.3 offers more opportunities to choose SOAP 1.2, although there is virtually nothing in the documentation, most of which has not been upgraded from Axis 1.2.

The standard language bindings for SOAP 1.2 are for XML Schema data types but, where more complex data types are involved, the situation becomes correspondingly more complicated, even with the use of standard JavaBean representations. There are considerable differences between simple JavaBean classes that a programmer might write to represent a complex type, and those generated from a schema referenced in a WSDL by, for example, Apache Axis. (WebLogic generated JavaBean classes are actually simpler.) The Axis-generated beans contain methods for serialization and deserialization as well as for complex type descriptions using the XML Schema QName data type, which refers to a namespace-qualified name required in WSDL. The

following example was generated from a hand-written WSDL for a web service:

static {

typeDesc.setXmlType(new javax.xml.namespace.QName("urn:dct", "DictEntry"));

org.apache.axis.description.ElementDesc elemField = new org.apache.axis.description.ElementDesc();

elemField = new org.apache.axis.description.ElementDesc();

elemField.setFieldName("plural");

elemField.setXmlName(new javax.xml.namespace.QName("urn:dct", "plural"));

elemField.setXmlType(new

javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "string"));

elemField.setNillable(true);

typeDesc.addFieldDesc(elemField);

elemField = new org.apache.axis.description.ElementDesc();

elemField.setFieldName("pos");

elemField.setXmlName(new javax.xml.namespace.QName("urn:dct", "pos"));

elemField.setXmlType(new

The level of complexity can be appreciated by a comparison between the JavaBean, partially rendered above, and the simpler schema construct below, from which it was generated:

<xs:complexType name="DictType">

<xs:sequence>

<xs:element name="headword" type="xs:string" nillable="true"/>

<xs:element name="plural" type="xs:string" nillable="true"/>

<xs:element name="pos" nillable="true">

<xs:simpleType>

Levels of code complexity vary with WSDL code-generators. It could be argued that potential code complexity is one more reason for starting a web service with a WSDL and a schema, rather than with interface and implementation classes. This issue is discussed at greater length in section 4.3.3.

Although SOAP has been widely adopted in industry applications and especially in vendor toolkits, not all SOAP implementations are created equal, not least in which version of SOAP they support, although that problem should be resolved as newer toolkit versions are released and more vendors scramble to comply with the Basic Profile. Even when the versioning is taken care of, there could still be interoperability problems if vendors were to insert proprietary details that would lock customers in to their product. The SOAP header inside the SOAP envelope, for example, is an extensibility element capable of modifying the message in many implementation-dependent ways. The standards compliance of implementations tested (see Chapter 7) suggests that most vendors are currently anxious to conform to the requirements of the Basic Profile and to be seen to be interoperable.

A source of confusion is that rules for SOAP messages are distributed across both WSDL and SOAP specifications. SOAP messaging styles, for instance, rely on protocol bindings which are usually given as SOAP extensibility elements in WSDL documents, for example:

<wsdlsoap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="tns.storeEntry">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="tns.storeEntryRequest">

<wsdlsoap:body use="literal"/>

</wsdl:input>

where the ^wsdlsoap elements are the commonly used extensibility elements for SOAP.

A further interoperability problem that neither SOAP nor WSDL addresses is occasioned by the lack of granularity in message sequencing that does not extend beyond single message pairs. Zur Muehlen, Nickerson and Swenson point out that "complex business scenarios that require the sequencing of several message pairs cannot be described sufficiently using SOAP and WSDL, but an additional standard is needed". They suggest that:

an information system needs to keep track not only of the individual request–response or notify–response message pairs, but it also needs to correlate the different message pairs to an overall context, so that it can identify messages that are duplicates or out of sync. In essence, the description of the overall interaction requires a process model [2004].