Soap Fight: RPC vs. Document
By Charles Skinner
Bixby Consulting Inc.
The line has been drawn and both camps are playing for keeps. This is sure to be a good fight with one winner becoming the VHS of our time and other suffering the fate of BETAMAX. Who it will be? Let’s have a little ring side analysis.
Most people are lead to believe that there are only two implementations, Document or RPC. As in everything, there are more choices that need to be made. In reality, the choices are between what combo of Style and Use to implement: RPC/ENCODING. RPC/LITERAL and DOCUMENT/LITERAL. When people refer to RPC this usually indicates style: RPC and use: ENCODE. On the other hand Document usually refers to style: Document and use: Literal.
The fighters have STYLE:
-
RPC Style
- The RPC style specifies that the <soap:body> contains an element with the name of the Web method being invoked. This element in turn contains an entry for each parameter and the return value of this method.
-
Document Style
- The message parts appear directly under the <soap:body> element. There are no SOAP formatting rules for what the <soap:body> contains. The server application is responsible for mapping the server objects (parameters, method calls, and so forth) and the values of the XML documents.
What they are USEing:
-
Encoding
- Each message part references an abstract type using the type attribute instead of a schema. Applications using SOAP encoding are focused on remote procedure calls and will likely use the RPC message style.
-
Literal
o
Each part references a concrete schema definition using either
the element or type attribute; in other words, data is serialized according to
a given schema.
Contender 1: RPC/Encoded
In RPC style Web Services, the complete method is specified in the WSDL file and in the SOAP body. This includes the sent parameters and the return values. So, you have a rather tight coupling with this style. The Encoded- USE indicates that the SOAP message will contain the encoded type information such as xsi:type="xsd:int", xsi:type="xsd:string", xsi:type="xsd:double".
Strengths:
· The definition of the WSDL file formatted in a well-known remote-procedure-call style.
· The operation name appears in the message, so that the receiver has an easy time dispatching the message to its implementation.
· If you are using data graphs or polymorphism in your service, this is the only possible style that can be used for the types described in this article.
· Most early Java implementations only use this method.
Weaknesses:
- The SOAP message includes the type encoding information such as xsi:type="xsd:int", xsi:type="xsd:string", xsi:type="xsd:double", which is an overhead.
- You will not be able to validate using a schema because the type information is I stored in the message not a schema. This will make validation more difficult.
- Any changes to the interface would break the contract between the service and the client since there is a tight coupling between service provider and client.
- Is not supported by the WSI conformance standard.
Sample Soap Message
========================Request Sample ===========================
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://eherenow.com/RPC" xmlns:types="http://eherenow.com/RPC/encodedTypes" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<q1:GetUserName xmlns:q1="http://www.eherenow.com">
<Where xsi:type="xsd:string">string</Where>
</q1:GetUserName>
</soap:Body>
</soap:Envelope>
========================Response Sample ===========================
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://eherenow.com/RPC" xmlns:types="http://eherenow.com/RPC/encodedTypes" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<q2:GetUserNameResponse xmlns:q2="http://www.eherenow.com">
<GetUserNameResult href="#id1" />
</q2:GetUserNameResponse>
<types:UserName id="id1" xsi:type="types:UserName">
<Name xsi:type="xsd:string">string</Name>
<Domain xsi:type="xsd:string">string</Domain>
</types:UserName>
</soap:Body>
</soap:Envelope>
Contender 2: RPC/Literal Style
The style will remain RPC but the WSDL will now have the 'use' setting changed from 'encoded' to 'literal' in the soap:body. Which means the data is serialized according to the given schema.
Strengths:
- The WSDL is still about as straightforward as with the RPC/Encoded style
- The operation name still appears in the SOAP message
- Higher throughput performance since the type encoding is removed from the message.
Weaknesses:
· Any changes to the interface would break the contract between the service and the client because there is a tight coupling between the service provider and the client.
- The schema describing an RPC/Literal message is not sufficient to validate that message.
- Is not supported by the WSI conformance standard.
Contender 3:
Document/Literal
In Document style Web Services, the client sends standard XML document to the server. The server application is responsible for mapping the server objects (parameters, method calls, and so forth) and the values in XML documents. The protocol places no constraint on how the document needs to be structured.
As described before the 'use' setting is set to 'literal' in the soap:body. Which means the data is serialized according to the given schema.
Strengths:
- No type encoding information in the SOAP message. (Smaller footprint)
- You can always validate the message with a XML Schema. Since everything within the SOAP body is defined in the schema.
- The rules are less rigid and many enhancements and changes can be made to the XML schema without breaking the interface.
Weaknesses:
- The operation name in the SOAP message is lost. Without the name, dispatching can be difficult.
Sample Soap Message
========================Request Sample ===========================
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Where xmlns="http://www.eherenow.com">string</Where>
</soap:Body>
</soap:Envelope>
========================Response Sample ==========================
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetUserNameResult xmlns="http://www.eherenow.com">
<Name>string</Name>
<Domain>string</Domain>
</GetUserNameResult>
</soap:Body>
</soap:Envelope>
Contender 4:
Document/Literal
MICROSOFT PROPOSAL
How many Microsoft
programmers does it take to change a light bulb . . . NONE – they will make
darkness a standard.
I thought I should mention this new contender because when an elephant walks the ground moves. Microsoft suggested this style to fix the “drawbacks” from the standard Document/Literal style. It is exactly the same as Contender 3 except for one difference; the message is wrapped by an element that describes the method name.
Even though there is no specification in the WSDL 1.1 standard for this style, many current SOAP toolkits support it.
Strengths:
- Contains all the strengths of Document/Literal style.
- The method name appears in the SOAP message.
Weaknesses:
-
If you have overloaded operations in your Web Service, you cannot use this
style because WSDL requires an element to have the same name as the operation.
Sample Soap Message
=========================Request Sample =======================
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetUserName xmlns="http://www.eherenow.com">
<Where>string</Where>
</GetUserName>
</soap:Body>
</soap:Envelope>
======================= Response Sample ========================
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetUserNameResponse xmlns="http://www.eherenow.com">
<GetUserNameResult>
<Name>string</Name>
<Domain>string</Domain>
</GetUserNameResult>
</GetUserNameResponse>
</soap:Body>
</soap:Envelope>
Conclusion
Well sport fans, we have sized up the contenders for you and it appears that in a toe to toe match document style usually wins. In fact, the WS-I Basic profile 1.1 discourages the use of RPC/Encoded approach and motivates Document/Literal and RPC/Literal as the only allowed style/use combination. Rumor has it that RPC/Literal would go away with a future version of the WSI profile. So it appears, unless you are interfacing to a legacy RPC style, Document/Literal will be a sure bet every time.
Sample Links