Can anyone please tell me the exact difference between an rpc and document message style.
I found the RMH description a bit vague...
(Chapter 4. 4.5 SOAP Messaging Modes)
"..Document mode of messaging, a SOAP Body element contains an XML document fragment, a well-formed XML element that contains arbitrary application data (text and other elements)..."
by "arbitrary application data", what do we mean?
<po urchaseOrder orderDate="2003-09-22"
<po:title>J2EE Web Services</po:title>
"The RPC mode of messaging enables SOAP messages to model calls to procedures or method calls with parameters and return values. "
To argue, the Document mode definition applies for rpc mode as well.
Because according to the above defn, message in RPC mode is also an XML Document fragment, which is well-formed and hence the above RPC is also Document mode.
Although by "looking" at the two examples, I can make out the difference, but how exactly can you differentiate between the two.
Are there any specific rules for rpc which differentiate from document.
Originally posted by Vasim Patel:
Are there any specific rules for rpc which differentiate from document.
I have to admit I have yet to run into a clear-cut definition for the two. Seems most explanations are rather nebulous along the lines of "if it's not 'rpc' it's 'document'".
Also the explanation that the root element represents an operation with parameters for "rpc" while for "document" style the root is simply the root of an XML document seems a bit weak - both SOAP payloads are still "XML documents" (well, they have to be!).
For now I'm sticking with the following (very fuzzy) rule of thumb: if the SOAP payload is (primarily) data-oriented XML (i.e. fully hierarchical, elements contain elements, elements containing text don't contain any more elements) and the root element looks like an operation and the root's immediate children look like parameters its probably "rpc". If the SOAP payload looks like one big chunk of document-oriented XML (mixed content) its probably "document". ... however I could be entirely misguided which that notion.
I can think up a scenario where the parameter for an rpc-style call is a document-oriented XML document (hence the 'primarily' in parenthesis in the above statement). So really the 'rpc' messaging style could be viewed as an indication that the root element of the SOAP payload is an 'envelope' that identifies what needs to be done with the content of that 'envelope' (leading us back to the "operation with parameters" definition).
Which style of WSDL should I use?
rpc vs document was a bigger deal when it was still rpc/encoded vs document/literal.
On document vs. RPC style, why is it a big deal?
[ February 08, 2006: Message edited by: Peer Reynders ]
I did a little more reading in RMH, and got a little more clarity, though still not complete.
RMH : 188.8.131.52 The message Element for Document-Style Web Services
message part may declare either a type attribute or an element attribute, but not both. Which to use depends on the kind of messaging you're doing. If you're using RPC-style messaging, the part elements must use the type attribute; if you're using document-style messaging, the part elements must use the element attribute.BP
Here are some differences between rpc message vs document message.
1. RPC message part has type:
If you're using RPC-style messaging, the part elements must use the type attribute
<part name="typepart" type="xsd:int"/>
Document message part has element
if you're using document-style messaging, the part elements must use the element attribute
<part name="elementpart" element="ns:name"/>
2. RPC messages use types to define procedure calls. Each element represents type of parameter
Document messages exchange XML document fragments and refer to their global elements
take an example wsdl file which has both an rpc and a document style message.
Although this is not a good real life example, it might help understand the diff.
<!--types has a type 'PersonType' and a 'Person' element-->
<xsd:element name="Person" type="p ersonType"/>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="age" type="xsd:string" />
<!--rpcmessage is an rpc style message which has its part using 'type'-->
<part name="person" type="p ersonType"/>
<!--documentmessage is an document style message which has its part using 'element'-->
<part name="person" element="p erson"/>
Let me know if this is correct understanding.
Note that in this XML application the root (top-level) element of a valid XML Document has to be <apurchaseOrderDoc> - no other root element is valid.
In rpc style messaging you could do this:
In document style messaging you would do this:
Looking at it this way rpc style messaging is more flexible (less rigid) than document style messaging as rpc is not limited to the documents as allowed by the schema - it can use all of the schema's types.
I find the reference in 184.108.40.206 to "XML document fragments" a bit puzzling - unless it simply refers to the fact that a fragment is created by enclosing the XML Document in a message instance.
[ February 09, 2006: Message edited by: Peer Reynders ]
I have 2 questions related to this thread:
1) if I have a web service with 2 operations with different names. both of them use the document/literal style and use the same message as an input. then a soap message arrived to the web service as the following:
<!-- Any XML Document without an operation name -->
Is this case allowed in the BP. if yes How the JAX-RPC can map the message to the approperite method?
2) another question if I have a web service with 2 operations, both of them use the document/literal style. each of which uses a different message as input. How can this be defined in the WSDL?
As a countermeasure the document/literal wrapped pattern is suggested and outlined.
The WSDL is getting a bit more complicated. This is a very minor weakness, however, since WSDL is not meant to be read by humans. The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible. WS-I only allows one child of the soap:body in a SOAP message.
Scenario 2 shouldn't be a problem because both operations would use a different "message" which each refers to a different top-level element (XML document). The SOAP message payload would be a different type of XML document in either case.
The bottom-line is that in document/literal the XML document type implies the operation.
The document/literal wrapped pattern simply creates a new type of XML document that acts as an envelope a) to identify an operation and b) to carry multiple documents. The difference to rpc/literal is that the operations and parameters are now no longer part of the WSDL definition but part of your document XML schema.
Originally posted by Haitham Ismail:
so you mean the first scenario is allowed by the WS-I but we should not use it. right?
In my judgment the first scenario is not allowed by Basic Profile 1.0a. Look at this excerpt:
5.6.9 Child Element for Document-Literal Bindings
WSDL 1.1 is not completely clear what, in document-literal style bindings, the child element of soap:Body is.
R2712 A document-literal binding MUST be represented on the wire as a MESSAGE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part.
By saying that it�s the message that appears in the body it basically is acknowledging that the operation is meaningless in the document/literal context. So by extension having two operations with different names but the same messages/parts is equivalent to having two identical operation definitions which is clearly illegal.