SOAP Message Binding Style

A WSDL SOAP binding can be either a Remote Procedure Call (RPC) style binding or a Document style binding.

A SOAP binding can also have an encoded use or a literal use.

This gives us Five style/use models which we call as Message Exchange Format(MEF) or SOAP message binding style

1) RPC Literal

2) RPC Encoded

3) Document Literal

4) Document Encoded

5) Document Literal Wrapped

MEF: The format of the information which is exchanged between service provider and the consumer is called MEF.

Document style vs RPC style

The Style indicates how exactly the SOAP message body is structured.

The Document style indicates that the SOAP message body contains a XML document which can be validated against pre-defined XML schema document.

RPC style indicates that the SOAP message body contains an XML representation of a method call and uses the names of the method and its parameters to generate XML structures that represent a method’s call stack.

The 4th message exchange format in the above list which is Document Encoded is not recommended by WSI.

RPC-Encoded is the default MEF for the JAX-RPC and Document-Literal is the default MEF for the JAX-WS.

Encoded vs Literal

The WSDL service contract has to specify how the data types used in the implementation programming language are serialized to WSDL compliant types and how the WSDL-compliant types are de-serialized into client programming language types.

The setting use=”literal” in soap binding means that the service’s type definitions literally follow the WSDL documents XML Schema.

The setting use=”encoded” means that the services type definitions come from encoding rules, specifically the encoding rules of SOAP 1.1 spec.

Let’s try to understand each of the MEFs in details

Let’s say we have a method as below which we use for entire discussion

public void display(int x, float y,long z);

1) RPC Literal

As we understood ,RPC literal deals with XML representation of the SAOP body and the type definitions will be referring the WSDL document XML schema.

The WSDL for the same looks like below

<message name="displayRequest">
    <part name="x" type="xsd:int"/>
    <part name="y" type="xsd:float"/>
    <part name="z" type="xsd:long"/>
</message>
<message name="emptyMsg"/>
<portType name="myDisplayExample">
    <operation name="display">
        <input message=" displayRequest "/>
        <output message="emptyMsg"/>
    </operation>
</portType>
<! -- Further details on WSDL is omitted for the discussion -->

SOAP message for the same is as below

<soap:envelope>
    <soap:body>
        < display>
            <x>2</x>
            <y>2.0</y>
            <z>1234567</z>
        </ display >
    </soap:body>
</soap:envelope>

Strengths and weakness of RPC Literal

Strengths

WSDL is not too complex and it gives fair idea about the types and operation
SOAP message has the operation name defined in the WSDL
There is no types encoding information

Weakness

The SOAP body content is a mixture of both WSDL and XML schema, so it cannot be validated against the Schema.
Only the parameters x ,y and z and its types have come from Schema , rest of the SOAP body like operation name has come from the WSDL.

2) RPC Encoded

WSDL for the same is as below

<message name="displayRequest">
    <part name="x" type="xsd:int"/>
    <part name="y" type="xsd:float"/>
    <part name="z" type="xsd:long"/>
</message>
<message name="emptyMsg"/>
<portType name="myDisplayExample">
    <operation name="display">
        <input message=" displayRequest "/>
        <output message="emptyMsg"/>
    </operation>
</portType>
<! -- Further details on WSDL is omitted for the discussion -->

Now lets invoke the method with x=2,y=2.0 and z=1234567

SOAP message for the same is as below

<soap:envelope>
    <soap:body>
        < display >
            <x xsi:type="xsd:int">5</x>
            <y xsi:type="xsd:float">5.0</y>
            <z  xsi:type="xsd:long">1234567</y>
        </ display >
    </soap:body>
</soap:envelope>

Look at the SOAP message, it has types encoded information (xsi:type=”xsd:int”)

Strengths and weakness of RPC Encoded

Strengths

WSDL is not too complex and it gives fair idea about the types and operation
SOAP message has the operation name defined in the WSDL

Weakness

The SOAP body content is a mixture of both WSDL and XMl schema, so it cannot be validated against the Schema.
Only the parameters x ,y and z and its types have come from Schema , rest of the SOAP body like operation name has come from the WSDL.
The type encoding info (like xsi:type=”xsd:int”) is an extra overhead which degrades the performance.

3) Document Literal

WSDL for Document Literal is as below

<types>
    <schema>
        <element name="xElement" type="xsd:int"/>
        <element name="yElement" type="xsd:float"/>
       <element name="zElement" type="xsd:long"/>
    </schema>
</types>

<message name="displayRequest">
    <part name="x" element="xElement"/>
    <part name="y" element="yElement"/>
   <part name="z" element="zElement"/>
</message>
<message name="emptyMsg"/>

<portType name="myDisplayExample">
    <operation name="display">
        <input message="displayRequest"/>
        <output message=" emptyMsg "/>
    </operation>
</portType>

SOAP Message for the same is as below

<soap:envelope>
    <soap:body>
        <xElement>5</xElement>
        <yElement>5.0</yElement>
        <zElement>1234567</zElement>
    </soap:body>
</soap:envelope>

Strengths and weakness of Document Literal

Strengths

There is no type encoding information which will increase the prformance.
we can easily validate this message with any XML validator. Everything within the soap:body is defined in a schema.

Weakness

The WSDL is getting a bit more complicated as it involves Schema. However this is a very minor weakness, since WSDL is not meant to be read by humans.
The operation name in the SOAP message is not present. Without the operation name, dispatching can be difficult, and sometimes impossible.

4) Document Encoded

It is not WS-I compliant and hence we will not discuss it.

5) Document Literal Wrapped

This binding style is the most advantageous one as it has benefits of both Document and Literal binding style.
This will have a wrapper around the parameters in the WSDL

The WSDL for the same is as below

<types>
    <schema>
        <element name="display">
            <complexType>
                <sequence>
                    <element name="x" type="xsd:int"/>
                    <element name="y" type="xsd:float"/>
                    <element name="z" type="xsd:long"/>
                </sequence>
            </complexType>
        </element>
        <element name="displayResponse">
            <complexType/>
        </element>
    </schema>
</types>
<message name="displayRequest">
    <part name="parameters" element="display"/>
</message>
<message name="empty">
    <part name="parameters" element="displayResponse"/>
</message>

<portType name="myDsiplayExample">
    <operation name="display">
        <input message="displayRequest"/>
        <output message="empty"/>
    </operation>
</portType>

<binding .../>  
<! -- Further details on WSDL is omitted for the discussion -->

SOAP message for the same is as below

<soap:envelope>
    <soap:body>
        <display>
            <x>5</x>
            <y>5.0</y>
            <z>1234567</z>
        </display>
    </soap:body>
</soap:envelope>

SOAP message looks exactly like RPC Literal message with subtle difference

The difference is , in RPC Literal style display was referring to the operation name but here it refers to the name of the wrapper element
And name of the element should be same as name of the operation.

Strengths and weaknesses of Document Literal wrapped pattern

Strengths

There is no type encoding information.
Everything that appears in the < soap:body > is defined by the schema, and hence can be easily validated.
There is a method name in the SOAP message.

Weaknesses

The WSDL is even more complicated than Document Literal.
This weakness with the document/literal wrapped pattern is outweighed by the strengths.
So This Binding style can be preferred most of the times.

Raj

Founder of javainsimpleway.com
I love Java and open source technologies and very much passionate about software development.
I like to share my knowledge with others especially on technology 🙂
I have given all the examples as simple as possible to understand for the beginners.
All the code posted on my blog is developed,compiled and tested in my development environment.
If you find any mistakes or bugs, Please drop an email to kb.knowledge.sharing@gmail.com

Connect with me on Facebook for more updates