These two examples comparing RPC/Lit vs Document/Lit have me a bit confused

[Rick Reumann]

I'm trying to understand the difference between RPC vs Document styles (with encoding Literal.) Been googling and looking at various posts on the subject. This one site http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/#1
shows sample differences in the xml of the wsdl and xml requests. The xml request for RPC looks practically identical to the Document style request. Am I to assume the difference between the two is something that happens 'behind the scenes' that I'm not aware of? I'm really confused on this :confused

The two examples they show look like:

Code Sample 3-c: SOAP Request for RPC-Literal Formatting
 
<?xml version="1.0" encoding="UTF-8"?>
<env:envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:ns0="http://www.examples.com/wsdl/StringService">
<env:body>
<ns0:sayxmlhello>
<string_1>Hello World</string_1>
</ns0:sayxmlhello>
</env:body>
</env:envelope>
 

 
Code Sample 3-e: SOAP Request for Document-Literal Formatting
 
<?xml version="1.0" encoding="UTF-8"?>
<env:envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:ns0="http://www.examples.com/types">
<env:body>
<ns0:sayxmlhello>
<string_1>Hello World</string_1>
</ns0:sayxmlhello>
</env:body>
</env:envelope>

Another site mentioned a destinction between the two...

"Document" implies that the messages contain a
document (such as a purchase order), while "RPC" implies that the
messages contain parameters and return values (think of a
request/response query-type operation).

I guess I'm really confused because I don't see where the definitions I'm seeing for RPC and Document styles fit in with what the actual SOAP requests look like. I'd appreciate someone helping to clarify this.

[Nitesh Kant]

This is a nice article explaining all the ws message styles.
Looks like the example you have shown is of a document literal wrapped rather than document literal alone.

[Peer Reynders]

That's because the XML for Code Sample 3-e: SOAP Request for Document-Literal Formatting is incorrect. First clue: Document/literal has no reason to reference "http://schemas.xmlsoap.org/soap/encoding/" � it's "literal" not "encoded". Second: in the document/literal messaging style the operation name specified in the WSDL would never appear in the SOAP request. The operation is implied by the document being submitted. So the request should look more like this:

<?xml version="1.0" encoding="UTF-8"?>
<env:envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ns0="http://www.examples.com/types">
    <env:body>
        <ns0:string_1>Hello World</ns0:string_1>
    </env:body>
</env:envelope>

As pointed out by the previous poster Which style of WSDL should I use? is worthwhile to understand. However it presents

<soap:envelope>
    <soap:body>
        <xElement>5</xElement>
        <yElement>5.0</yElement>
    </soap:body>
</soap:envelope>

as an example of a document/literal request. While this is an implementation of a "legal" WSDL, this type of messaging is not permitted by the Basic Profile which basically requires that no more than one document appears within the SOAP body. It is this restriction that gives rise to the "Document/literal wrapped" pattern where you create a new document type to carry (wrap) other documents so that you can submit more than one document (type) at a time. So with a BP-compliant document/literal web service there is exactly one process that is applied to each top-level element (document) that can appear as the direct child of the SOAP body element (i.e. no "operations" necessary).

Why is that a good thing? This loosens the coupling between the client and the server. As the domain (business) logic evolves, the processing of particular documents may change - so rather than exposing a fine-grained operation-based interface, a document-oriented web service interface will be coarse-grained and simply specify what document-types it accepts (the WSDL operation names are primarily a "documentation" feature). So for practical reasons no real document-oriented service would simply accept a single little string - it probably wouldn't have enough information in it to define a coarse grained business process around it. A document oriented web service would more likely consume a full-blown document like a purchase order with multiple order items, billing address, shipping address and all the other gory details in one fell swoop.

[Rick Reumann]

First off thanks for all your help with this...

as an example of a document/literal request. While this is an implementation of a "legal" WSDL, this type of messaging is not permitted by the Basic Profile which basically requires that no more than one document appears within the SOAP body. It is this restriction that gives rise to the "Document/literal wrapped" pattern where you create a new document type to carry (wrap) other documents so that you can submit more than one document (type) at a time. So with a BP-compliant document/literal web service there is exactly one process that is applied to each top-level element (document) that can appear as the direct child of the SOAP body element (i.e. no "operations" necessary).

I'm still a bit cofused about what your describing above. (I tried searching around for soap:body in that document link above and wasn't sure what section was saying that it wasn't legal to have more than one document appear within the SOAP body.) I'm unclear as to what you are saying was 'illegal' by the Basic Profile rules which later became addressed with Document/Literal Wrapped? If you get a chance can you briefly show (or point me to a link that shows) a code snippet of a BP-compliant SOAP body and then a similar doc/literal wrapped version and what the latter addresses that the first one had problems with?

Why is that a good thing? This loosens the coupling between the client and the server. As the domain (business) logic evolves, the processing of particular documents may change - so rather than exposing a fine-grained operation-based interface, a document-oriented web service interface will be coarse-grained and simply specify what document-types it accepts (the WSDL operation names are primarily a "documentation" feature). So for practical reasons no real document-oriented service would simply accept a single little string - it probably wouldn't have enough information in it to define a coarse grained business process around it. A document oriented web service would more likely consume a full-blown document like a purchase order with multiple order items, billing address, shipping address and all the other gory details in one fell swoop.

It sounds like you are you saying you typically wouldn't actually provide the operation names in a document-oriented service? Or are you saying you'd simply provide a much more course grained operation name (ie 'dealWithPurchaseOrder') and then make sure to dump the full-blown purchase order in the document, and thus the business layer can handle that purchase order in different ways over time and not break the contract with the client (since there are no fine grained operations)? You still need to provide some operation names though don't you? From my very limited (obviously use of web services (messing around with Axis2 and exposing EJB3 beans as webservices), you need the operation name so that the clients could build their stubs from the exposed wsdl.

Sorry I'm such a newb with this stuff. I need to purchase a good book on this, because just when I think I 'might' understand what someone is talking about, I end up more confused.