On document vs. RPC style, why is it a big deal?
<env:Body> <m:&methodName xmlns:m="someURI"> <m:¶m1>...</m:¶m1> <m:¶m2>...</m:¶m2> ... </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:
<env:Body> <m:purchaseOrder xmlns:m="someURI"> ... </m:purchaseOrder> </env:Body>
<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 first published in October 2002