SOAP Binding - RPC Style vs Document style

	RPC Literal (Wrapped)	Document Literal	Document Wrapped
Request Message	The operation name appears immediately after the soap:body. The operation name is specified by the binding:operation element in the binding section of the WSDL. The name attribute of the message:part follows immediately. It is not qualified by a namespace Thereafter the names of the elements in the types section of the WSDL are specified.	The operation name is not specified in the request. The value specified by the element attribute of message:part is the first line following the soap:body. It is qualified by a namespace. Note that this value of the element attribute is actually the value of the name attribute of the schema element in the types section. Thereafter it is similar to RPC Literal in the way that the names of the elements in the types section of the WSDL are specified.	It is similar to "Document Literal Bare" style with one exception => the value of the "element" attribute in the message:part is defined to be the name of the operation. Therefore the name of the operation is part of the request. The operation name appears immediately after the soap:body. Thereafter it is similar to RPC Literal.
WS-I BP 1.1 Compliance	It is WS-I BP 1.1 compliant even though there are many parts in the input message. This is because the first element after the soap:body is the name of the operation and that encapsulates it all.	Since it can have multiple parts immediately following the soap:body, it is not WS-I BP 1.1 compliant. Therefore to make it compliant, a wrapper needs to be defined and this implies that the web method can only have one argument. You could circumvent this requirement by defining the arguments to be part of the SOAP header instead of the body.	It is WS-I BP 1.1 compliant.
WSDL	There could be many parts in the input message. The parts are always specified with a "type" attribute.	There could be many parts in the input message The parts are always specified with an "element" attribute	There is only one part in the input message. The part is always specified by an "element" attribute. This part is the entire message payload and is completely defined in the types section.