Problem solve Get help with specific problems with your technologies, process and projects.

Document vs. RPC style--why is it a big deal?

On document vs. RPC style, why is it a big deal? I'm not sure I would characterize it as a big deal. It's just...

that there are two ways to structure a SOAP message. In the early versions of SOAP (before it was publicly published), SOAP was designed to support only RPC style. By the time the SOAP 1.0 spec was published, it was expanded to support both RPCs and unstructured messages (document). When using Document style, you can structure the contents of the SOAP Body any way you like. When using RPC style, the contents of the SOAP Body must conform to a structure that indicates the method name and contains a set of parameters. It looks like this:

 <env:Body> <m:&methodName xmlns:m="someURI"> <m:&param1>...</m:&param1> <m:&param2>...</m:&param2> ... </m:&methodName> </env:Body>

The response message has a similar structure containing the return value and any output parameters. Your parameters can be as complex as you like, so there's really not a huge amount of difference in what you can pass. For example, you can pass a purchase order as a document or as a parameter in a method called placeOrder. It's your choice:

Document style:

 <env:Body> <m:purchaseOrder xmlns:m="someURI"> ... </m:purchaseOrder> </env:Body>

RPC style:

 <env:Body> <m:placeOrder xmlns:m="someURI"> <m:purchaseOrder> ... </m:purchaseOrder> </m:placeOrder> </env:Body>

The bigger difference is how you encode the message. In most circumstances, you use literal encoding with Document style and SOAP encoding with RPC style. Literal encoding means that the Body contents conform to a specific XML Schema. SOAP encoding uses a set of rules based on the XML Schema datatypes to encode the data, but the message doesn't conform to a particular schema. SOAP encoding is particularly useful is you're passing cyclic object graphs. For example, if you have an element which is referenced repeatedly within the object graph, when using SOAP encoding, you would specify the element once and then reference the element as needed. When using literal encoding, you would have to repeat this element each time it's referenced. So obviously it sounds like a good idea to use SOAP encoding -- but, if you do, then you can't validate the message with an XML Schema, and you can't transform the message using XSLT.

So that's the deal from a technical point of view. Let's look at it from a practical point of view. Microsoft MS SOAP Toolkit and .NET support RPC style, but they use Document style by default. Many of the early Java implementations used RPC style by default, and, in fact, most early Java implementations didn't automate the generation of Document style messages -- so you would need to use a low-level API to marshal the messages. Now most of the Java implementations provide much better support for Document style, although some implementations style require you to marshal the messages yourself. (look for full support for Document style when selecting a SOAP implementation)


This was last published in October 2002

Dig Deeper on Service-oriented architecture (SOA)



Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.