wsdl:binding "style", "use", and message format


by Arun Gupta
Aug 2004

WSDL bindings define the message format and protocol details for a web service. WSDL 1.1 [1] defines SOAP binding in section 3.2 using the WSDL extensibility mechanism. This article discusses the various combinations for SOAP binding and their impact on generated method signatures and the corresponding SOAP request, response, and fault messages.

1.0 Introduction
2.0 style attribute
3.0 use attribute
4.0 document/literal WSDL
    4.1 document/literal with wrapper
        4.1.1 Generated method signature
        4.1.2 Request message
        4.1.3 Response message
        4.1.4 Fault message
    4.2 document/literal non-wrapper
        4.2.1 Generated method signature
        4.2.2 Request message
        4.2.3 Response message
        4.2.4 Fault message
5.0 rpc/literal WSDL
    5.1 Generated method signature
    5.2 Request message
    5.3 Response message
    5.4 Fault message
6.0 rpc/encoded WSDL
    6.1 Generated method signature
    6.2 Request message
    6.3 Response message
    6.4 Fault message
7.0 References

1.0 Introduction

This document uses a simple web service that adds two numbers to provide an illustration of the various binding combinations defined in WSDL 1.1. All the method signatures and SOAP request,  response, and fault messages are generated using the JAX-RPC 1.1.2 Standard Implementation available in Java Web Services Developer Pack 1.4.

[2] defines how the SOAP binding extends WSDL. It defines the schema of the extension elements used within wsdl:binding section to specify SOAP binding.

Here is the list of namespace prefixes and their associated namespace URIs used in the WSDL fragments below.

Prefix Namespace URI Definition
wsdl http://schemas.xmlsoap.org/wsdl/ WSDL namespace for WSDL framework
soap http://schemas.xmlsoap.org/wsdl/soap/ WSDL namespace for WSDL SOAP binding
env http://schemas.xmlsoap.org/soap/envelope/ Envelope namespace as defined by SOAP 1.1
xsd http://www.w3.org/2000/10/XMLSchema Schema namespace as defined by XSD
xsi http://www.w3.org/2000/10/XMLSchema-instance Instance namespace as defined by XSD
tns http://wombat.org The “this namespace” (tns) prefix is used as a convention to refer to the current document
ns0 http://wombat.org Target namespace for wsdl:definitions of a WSDL
ns1 http://wombat.org/types Target namespace for wsdl:types of a WSDL

Table 1: List of the namespaces used in the examples

This table will translate to the following wsdl:definitions element for the WSDL fragments below:

<definitions
    targetNamespace="http://wombat.org"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
    xmlns:tns="http://wombat.org"
    xmlns:ns0="http://wombat.org/types"
    xmlns:ns1="http://wombat.org"
    xmlns="http://schemas.xmlsoap.org/wsdl/">

... WSDL fragment

<service>
    <port name="AddNumbersPort" binding="tns:AddNumbersBinding">
        <soap:address location="REPLACE_WITH_YOUR_URL"/>
    </port>
</service>

</definitions>

 

2.0 style attribute

The style attribute indicates whether the operation is RPC-oriented (messages containing parameters and return values) or document-oriented (message containing document(s)). This information defines the way in which the body of the SOAP message is constructed, as explained below. It may also be used to select an appropriate programming model. 

<definitions .... >
    <binding .... >
        <soap:binding transport="uri"? style="rpc|document"?/>
    </binding>
</definitions>

If the style attribute is not specified for a wsdl:operation element, it defaults to the value specified in the soap:binding element. If the soap:binding element does not specify a style, it is assumed to be "document". The value of the style attribute in the soap:binding element is the default for the style attribute for each contained operation. If the style attribute is omitted, it is assumed to be "document". If a different style attribute is specified on the contained operation, then that is used for that particular operation.

style="rpc": Each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call unless specified differently by parameterOrder.

style="document": There are no additional wrappers, and the message parts appear directly under the SOAP Body element.

3.0 use attribute

The required use attribute indicates whether the message parts are encoded using some encoding rules (use="encoded") or whether the parts define the concrete schema of the message (use="literal").

<definitions .... >
    <binding .... >
        <operation .... >
            <input>
                <soap:body parts="nmtokens"? use="literal|encoded"?
                                   encodingStyle="uri-list" namespace="uri"?/>
            </input>
            <output>
                <soap:body parts="nmtokens"? use="literal|encoded"?
                                   encodingStyle="uri-list" namespace="uri"?/>
            </output>
        </operation>
    </binding>
</definitions>

use="encoded": Each message part references an abstract type using the type attribute. These abstract types are used to produce a concrete message by applying an encoding specified by the encodingStyle attribute. The part names, types, and value of the namespace attribute are all inputs to the encoding, although the namespace attribute only applies to content not explicitly defined by the abstract types.

use="literal": Each part references a concrete schema definition using either the element or type attribute. If element is used, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). If type is used, the type referenced by the part becomes the schema type of the enclosing element (part accessor element for rpc style).

A combination of style and use provides 4 valid combinations:

style use common name
rpc encoded rpc/enc
rpc literal rpc/lit
document encoded doc/enc
document literal doc/lit

Table 2: "style" and "use" combinations

doc/enc combination is not used in practice anywhere and thus is considered out of scope for this article. rpc/encoded is essentially deprecated in the web services community, but is still explained for completeness.

Consider a web service which adds two non-negative numbers and throws a fault if one of the numbers is negative, otherwise returns the result. Following are the illustrative WSDL fragments for the prominent style/use combinations and their associated generated signatures, SOAP request, response, and fault messages.

 

4.0 document/literal WSDL

This section provides an illustrative WSDL with style="document" and use="literal" and explains the "wrapper" (section 4.1) and "non-wrapper" (section 4.2) styles. The main feature of document/literal is that each part of the message that binds to soap:body references a concrete schema definition using the element attribute defined in the schema element in wsdl:types. This is required by Basic Profile 1.0 R2204 [3]. This means that env:Body can be described completely using the schema element declaration without any additional rules. This is not possible with rpc/literal.

Each section also shows a sample request message, response message, and fault message using SOAP binding.

4.1 document/literal with wrapper

Following is a sample document/literal WSDL fragment with "wrapper" style. This style is used when each parameter of the operation needs to be passed individually in the method signature. 


<types>
    <schema
        targetNamespace="http://wombat.org/types"
        xmlns="http://www.w3.org/2001/XMLSchema">
        <element name="addNumbers">
            <xsd:complexType>
                <sequence>
                    <element name="number1" type="xsd:int"/>
                    <element name="number2" type="xsd:int"/>
                </sequence>
            </xsd:complexType>
        </element>
        <element name="addNumbersResponse">
            <xsd:complexType>
                <xsd:sequence>
                    <element name="result" type="xsd:int"/>
                </xsd:sequence>
            </xsd:complexType>
        </element>
        <element name="addNumbersFault">
            <xsd:complexType>
                <xsd:sequence>
                    <element name="message" type="xsd:string"/>
                </xsd:sequence>
            </xsd:complexType>
        </element>
    </schema>
</types>
<message name="addNumbersRequest">
    <part name="param" element="ns1:addNumbers"/>
</message>
<message name="addNumbersResponse">
    <part name="return" element="ns1:addNumbersResponse"/>
</message>
<message name="addNumbersFault">
    <part name="reason" element="ns1:addNumbersFault"/>
</message>
<portType name="AddNumbersPortType">
    <operation name="addNumbers" parameterOrder="param">
        <input message="tns:addNumbersRequest"/>
        <output message="tns:addNumbersResponse"/>
        <fault name="error" message="tns:addNumbersFault"/>
    </operation>
</portType>
<binding name="AddNumbersBinding" type="tns:AddNumbersPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="addNumbers">
        <input>
            <soap:body use="literal"/>
        </input>
        <output>
            <soap:body use="literal"/>
        </output>
        <fault name="error">
            <soap:fault name="error" use="literal"/>
        </fault>
    </operation>
</binding>

In order to qualify as using the "wrapper" style, section 6.4.1 of JAX-RPC 1.1 specification [6] defines the following conditions that need to be fulfilled by an operation:

Thus the operation addNumbers qualifies as a "wrapper" and only serves to indicate the correct operation. In this case, implementations must discard the wrapper elements and treat their children as the actual parameters of the operation. The generated method signature is shown in section 4.1.1.

4.1.1 Generated method signature (document/literal with wrapper)

public int addNumbers(int number1, int number2) throws AddNumbersFault, java.rmi.RemoteException;

 

4.1.2 Request message (document/literal with wrapper)

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types">
    <env:Body>
        <ns0:addNumbers>
            <number1>1</number1>
            <number2>2</number2>
        </ns0:addNumbers>
    </env:Body>
</env:Envelope>

There are no wrapper elements, but the wsdl:message part param from addNumbersRequest message appears directly under the SOAP body element. And the schema of this element is defined by the element referred by the part, ns0:addNumbers in this case.

 

4.1.3 Response message (document/literal with wrapper)

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types">
    <env:Body>
        <ns0:addNumbersResponse>
            <result>3</result>
        </ns0:addNumbersResponse>
    </env:Body>
</env:Envelope>

There are no wrapper elements, but the wsdl:message part return from addNumbersResponse message appears directly under the SOAP body element. And the schema of this element is defined by the element referred by the part, ns0:addNumbersResponse in this case.

 

4.1.4 Fault message (document/literal with wrapper)

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types">
    <env:Body>
        <env:Fault xsi:type="env:Fault">
            <faultcode>env:Server</faultcode>
            <faultstring>doc.NumberFault</faultstring>
            <detail>
                <ns0:addNumbersFault>
                    <message>invalid numbers</message>
                </ns0:addNumbersFault>
            </detail>
        </env:Fault>
    </env:Body>
</env:Envelope>

The schema of the detail element in the env:fault element is defined by the schema of the element referred in the message part, in this case it is the element referred by the reason part of the addNumbersFault message of the WSDL.

 

4.2 document/literal non-wrapper

Following is a sample document/literal WSDL fragment using "non-wrapper" style. This style is used when an entire document needs to be passed in the method signature. 

<types>
    <schema
        targetNamespace="http://wombat.org/types"
        xmlns="http://www.w3.org/2001/XMLSchema">
        <element name="request">
            <xsd:complexType>
                <sequence>
                    <element name="number1" type="xsd:int"/>
                    <element name="number2" type="xsd:int"/>
                </sequence>
            </xsd:complexType>
        </element>
        <element name="response">
            <xsd:complexType>
                <xsd:sequence>
                    <element name="result" type="xsd:int"/>
                </xsd:sequence>
            </xsd:complexType>
        </element>
        <element name="addNumbersFault">
            <xsd:complexType>
                <xsd:sequence>
                    <element name="message" type="xsd:string"/>
                </xsd:sequence>
            </xsd:complexType>
        </element>
    </schema>
</types>
<message name="request">
    <part name="param" element="ns0:request"/>
</message>
<message name="response">
    <part name="return" element="ns0:response"/>
</message>
<message name="addNumbersFault">
    <part name="reason" element="ns0:addNumbersFault"/>
</message>
<portType name="AddNumbersPortType">
    <operation name="addNumbers" parameterOrder="param">
        <input message="tns:request"/>
        <output message="tns:response"/>
        <fault name="error" message="tns:addNumbersFault"/>
    </operation>
</portType>
<binding name="AddNumbersBinding" type="tns:AddNumbersPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="addNumbers">
        <input>
            <soap:body use="literal"/>
        </input>
        <output>
            <soap:body use="literal"/>
        </output>
        <fault name="error">
            <soap:fault name="error" use="literal"/>
        </fault>
    </operation>
</binding>

The operation addNumbers does not qualify as a "wrapper" because the conditions specified in section 4.1 are not met. In this case, implementations must wrap the elements into a value type and treat that value type as the only parameter of the operation. This mapping style is defined in section 6.4.1 of JAX-RPC 1.1 [6].  The generated method signature is shown in section 4.2.1.

 

4.2.1 Generated method signature (document/literal non-wrapper)

public Response addNumbers(Request param) throws AddNumbersFault, java.rmi.RemoteException;

public class Request {
    protected int number1;
    protected int number2;

    // getters and setters for number1 and number2
}

public class Response {
    protected int result;

    // getter and setter for result
}

Request and Response are the value types used for the parameter and return types of the operation addNumbers.

 

4.2.2 Request message (document/literal non-wrapper)

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types">
    <env:Body>
        <ns0:request>
            <number1>1</number1>
            <number2>2</number2>
        </ns0:request>
    </env:Body>
</env:Envelope>

Request message looks similar to the "wrapper" case. The only difference is the name of the top-level element in env:Body

4.2.3 Response message (document/literal non-wrapper)

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types">
    <env:Body>
        <ns0:response>
            <result>3</result>
        </ns0:response>
    </env:Body>
</env:Envelope>

Response message looks similar to the "wrapper" case. The only difference is the name of the top-level element in env:Body

 

4.2.4 Fault message (document/literal non-wrapper)

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types">
    <env:Body>
        <env:Fault xsi:type="env:Fault">
            <faultcode>env:Server</faultcode>
            <faultstring>doc.NumberFault</faultstring>
            <detail>
                <ns0:addNumbersFault>
                    <message>invalid numbers</message>
                </ns0:addNumbersFault>
            </detail>
        </env:Fault>
    </env:Body>
</env:Envelope>

Fault message looks exactly similar to the "wrapper" case.

 

5.0 rpc/literal WSDL

This section provides an illustrative WSDL with style="rpc" and use="literal". The main feature of rpc/literal is that each part of the message that binds to soap:body references a wsdl:part on the wsdl:message that have been defined using the type attribute. This is required by Basic Profile 1.0 R2203 [3]. However the message part of the fault message, addNumbersFault, may contain wsdl:parts that use the element attribute. This is permitted by Basic Profile 1.0 R2207 [3]. This means that env:Body for an rpc/literal WSDL can be described using schema along with other RPC rules defined in the WSDL specification [1].

It also shows a sample request message, response message, and fault message using SOAP binding.

Following is a sample rpc/literal WSDL fragment:

<types>
    <schema
        targetNamespace="http://wombat.org/types"
        xmlns="http://www.w3.org/2001/XMLSchema">
        <element name="addNumbersFault">
            <complexType>
                <sequence>
                    <element name="message" type="xsd:string"/>
                </sequence>
            </complexType>
        </element>
    </schema>
</types>
<message name="addNumbersRequest">
    <part name="number1" type="xsd:int"/>
    <part name="number2" type="xsd:int"/>
</message>
<message name="addNumbersResponse">
    <part name="return" type="xsd:int"/>
</message>
<message name="addNumbersFault">
    <part name="reason" element="ns1:addNumbersFault"/>
</message>
<portType name="AddNumbersPortType">
    <operation name="addNumbers" parameterOrder="number1 number2">
        <input message="tns:addNumbersRequest"/>
        <output message="tns:addNumbersResponse"/>
        <fault name="error" message="tns:addNumbersFault"/>
    </operation>
</portType>
<binding name="AddNumbersBinding" type="tns:AddNumbersPortType">
    <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="addNumbers">
        <input>
            <soap:body use="literal" namespace="http://wombat.org/"/>
        </input>
        <output>
            <soap:body use="literal" namespace="http://wombat.org/"/>
        </output>
        <fault name="error">
            <soap:fault name="error" use="literal"/>
        </fault>
    </operation>
</binding>

 

5.1 Generated method signature (rpc/literal)

public int addNumbers(int number1, int number2) throws AddNumbersFault, java.rmi.RemoteException;

The ordering of the parameters in the method signature is specified by the parameterOrder attribute on wsdl:operation [5]

 

5.2 Request message (rpc/literal)

<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types"
    xmlns:ns1="http://wombat.org/">
    <env:Body>
        <ns1:addNumbers>
            <number1>1</number1>
            <number1>2</number1>
        </ns1:addNumbers>
    </env:Body>
<env:Envelope>

env:Body contains an element (addNumbers) with the name of the operation being invoked. This is identical to the operation name specified in wsdl:operation in wsdl:portType.  This is as per the 2nd bullet in section 7.1 of SOAP 1.1 [4]. This element (addNumbers) in turn contains an element for each parameter of that operation, number1 and number2 in this case, in the same order as specified by the parameterOrder on wsdl:operation [5].

 

5.3 Response message (rpc/literal)

<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types"
    xmlns:ns1="http://wombat.org/">
    <env:Body>
        <ns1:addNumbersResponse>
            <return>3</return>
        </ns1:addNumbersResponse>
    </env:Body>
<env:Envelope>

env:Body contains an element (addNumbersResponse) that is named after the message name in wsdl:operation in wsdl:portType, with the string "Response" appended. This is as per the 6th bullet in section 7.1 of SOAP 1.1 [4].

 

5.4 Fault message (rpc/literal)

<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types"
    xmlns:ns1="http://wombat.org/">
    <env:Body>
        <env:Fault>
            <faultcode>env:Server</faultcode>
            <faultstring>AddNumbersFault</faultstring>
            <detail>
                <ns0:addNumbersFault>
                    <message>invalid numbers</message>
                </ns0:addNumbersFault>
            </detail>
        </env:Fault>
    </env:Body>
<env:Envelope>

The encoding of the Fault element is as per the 7th bullet in section 7.1 of SOAP 1.1 [4].

 

6.0 rpc/encoded WSDL

This section provides an illustrative WSDL with style="rpc" and use="encoded". The main feature of rpc/encoded is that section 5 from SOAP 1.1 provides an encoding model which does not have any dependency on XML Schema.

It also shows a sample request message, response message and a fault message using SOAP binding.

Note: Basic Profile 1.0 [3], R2706, explicitly prohibits the use of different encodings, including the SOAP encoding.

Following is a sample rpc/encoded WSDL fragment:

<message name="addNumbersRequest">
    <part name="number1" type="xsd:int"/>
    <part name="number2" type="xsd:int"/>
</message>
<message name="addNumbersResponse">
    <part name="return" type="xsd:int"/>
</message>
<message name="addNumbersFault">
    <part name="message" type="xsd:string"/>
</message>
<portType name="AddNumbersPortType">
    <operation name="addNumbers" parameterOrder="number1 number2">
        <input message="tns:addNumbersRequest"/>
        <output message="tns:addNumbersResponse"/>
        <fault name="error" message="tns:addNumbersFault"/>
    </operation>
</portType>
<binding name="AddNumbersBinding" type="tns:AddNumbersPortType">
    <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="addNumbers">
        <input>
            <soap:body use="encoded" namespace="http://wombat.org/"
                               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
        </input>
        <output>
            <soap:body use="encoded" namespace="http://wombat.org/"
                               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
        </output>
        <fault name="error">
            <soap:fault use="encoded" name="error" namespace="http://wombat.org/"
                               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
        </fault>
    </operation>
</binding>

6.1 Generated method signature (rpc/encoded)

public int addNumbers(int number1, int number2) throws AddNumbersFault, java.rmi.RemoteException;

The ordering of the parameters in the method signature is specified by the parameterOrder attribute on wsdl:operation [5]

 

6.2 Request message (rpc/encoded)

<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/types"
    env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <env:Body>
        <ns0:addNumbers>
            <number1 xsi:type="xsd:int">1</number1>
            <number1 xsi:type="xsd:int">2</number1>
        </ns0:addNumbers>
    </env:Body>
<env:Envelope>

The wrapper element in the Body (addNumbers) is named identical to the operation name specified in wsdl:operation in wsdl:portType.  This is as per the 2nd bullet in section 7.1 of SOAP 1.1 [4]. The child elements of  the addNumbers element are number1 and number2, in the same order as specified by the parameterOrder on wsdl:operation [5].

 

6.3 Response message (rpc/encoded)

<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/"
    env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <env:Body>
        <ns0:addNumbersResponse>
            <return xsi:type="xsd:int">3</return>
        </ns0:addNumbersResponse>
    </env:Body>
<env:Envelope>

The wrapper element in the Body (addNumbersResponse) is named after the method name in wsdl:operation in wsdl:portType, with the string Response appended. This is as per the 6th bullet in section 7.1 of SOAP 1.1 [4].

 

6.4 Fault message (rpc/encoded)

<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://wombat.org/"
    env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <env:Body>
        <env:Fault xsi:type="env:Fault">
            <faultcode>env:Server</faultcode>
            <faultstring>AddNumbersFault</faultstring>
            <detail>
                <ns0:message xsi:type="xsd:string">invalid numbers</ns0:message>
            </detail>
        </env:Fault>
    </env:Body>
<env:Envelope>

The encoding of the Fault element is as per the 7th bullet in section 7.1 of SOAP 1.1 [4].

 

7.0 References

[1] http://www.w3.org/TR/wsdl
[2]http://www.w3.org/TR/wsdl#_how-s
[3]Basic Profile 1.0
[4] SOAP 1.1
[5] Parameter order within an operation
[6] JAX-RPC 1.1

 


About the author

Arun Gupta is a Staff Engineer in the Java APIs for XML-based RPC (JAX-RPC) development team at Sun Microsystems. Arun has over eight years of experience in the software industry, working in various distributed computing technologies, JavaTM platform, C++, and various web-related technologies. In his current role, Arun is part of the JAX-RPC development team and represents Sun in WS-I Sample Application Working Group. He has been with the JAX-RPC group since its inception and has been a significant contributor in evolving the technology.

Bobby Bissett and Rama Pulavarthi at Sun Microsystems has provided invaluable input to this article.

Send feedback to users@jax-rpc.dev.java.net.