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:¶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:
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)
|
