Document/litereal or RPC/Literal

I am very much confused why to use RPC/literal when we can use Document/literal.Is it that when we have complex inputs like xmls we should go for Document/literal,else RPC/Literal.What are the majaor differences between these techniques.Specially from the point of view of a developer who is using JAX RPC.

Secondly there are 2 types of encoding: literal and soap encoding.WS-I only supports literal.why?And what does this encoding exactly mean?

I am not sure but both the way they sends SOAP message is different. Literal is more preferable. For more info here

[ April 09, 2008: Message edited by: nitin pokhriyal ]
[ April 09, 2008: Message edited by: nitin pokhriyal ]

RPC/literal: Operation Name (as specified in the portType section of the WSDL) becomes the root element of the SOAP payload; the operation's parameters become direct children to the operation name root.

Document/literal: Drops the Operation Name entirely - i.e. it doesn't appear anywhere in the SOAP envelope. It is merely stated in the WSDL so that the client host language can assign a name to the method that submits the document. However conceptually that is irrelevant because you are submitting an XML document to the endpoint. Based on the document type or the contents of the document the endpoint has to decide what to do with it. There is no method name to give it a hint what it needs to do with the document. It also follows that each XML document type can only be used for one "operation" because the endpoint wouldn't be able to distinguish the resulting SOAP payloads of the two "operations" that use the same XML document type. In order to avoid having an XML fragment as the SOAP payload WS-I BP dictates that there can be only one document per SOAP envelope.

Wrapped Document/literal: Not a messaging mode like the previous two but a convention for using document/literal to fake RPC when you design the WSDL, sometimes also used by Code-to-WSDL and WSDL-to-Code code generation tools. The idea is that you want to submit more than one document (essentially parameters) at a time or you want to reuse the same document type in different submissions. To accomplish that you simply "wrap" the document(s) with a wrapping document type (essentially creating a new XML document type) that can embed multiple documents, or establish a differentiating context for the same embedded XML document type. The wrapping XML document type basically identifies an "operation". However essentially still being document/literal the operation name shown in the portType of the WSDL does not appear in the SOAP payload. So in RPC/literal the name of the root element used in the SOAP payload is implied by the operation name in the portType of the WSDL - with wrapped document/literal the root element of the SOAP payload comes from the WSDL types section or an XML Schema referenced therein.

literal: message payload is plain XML data adhering to WSDL/XML Schema rules, requiring no additional encoding/decoding (serialization/deserialization).

encoded: message payload is XML data (not necessarily conformant with an explicit XML Schema) that is the result of some encoding scheme, ultimately representing something else entirely (i.e. not XML data). The WSDL will identify the encoding but details of the encoding/decoding process are outside of the scope of the WSDL; that means there are no other hints to the structure of the XML data as that is defined by the encoding itself. RPC/encoded web services typically used Section 5 SOAP Encoding as an object (data) encoding protocol. SOAP encoding ultimately failed to be inter-operable; different SOAP stacks using the same host langauge would often generate different XML payloads for identical object graphs, while other SOAP stacks using different host languages would find themselves unable to reconstitute the object graphs (the host language might not even be object-oriented).

Which style of WSDL should I use?
The "wrapped" document/literal convention
[ April 09, 2008: Message edited by: Peer Reynders ]

thanks a lot Peer for such an informative post

Excellent Peer!

You have been providing great real time stuff on Webservices. I'm grateful to you.

Thanks and Regards,
Naren