Literal vs Encoded

"Literal" means "what you see is what you get"- this is just plain XML data. However that does not stop tools like java2wsdl and wsdl2java from doing any Java-to-XML or XML-to-Java conversion as specified in the JAX-RPC specification (Chapter 5: Java to XML/WSDL Mapping; Chapter 4: WSDL/XML to Java Mapping)  but that is JAX-RPC's business; WSDL has got no idea that of any of this going on. "literal" implies that you should need nothing more other than the WSDL to establish communication with the web service endpoint. "literal" is also the only messaging mode that is endorsed by the WS-I Basic Profile.

"Encoded" means that there is an additional set of rules outside of WSDL that imbue the XML data with some meaning. These rules specify how "something" is encoded/serialized to XML and then later decoded/de-serialized from XML back to "something". This set of rules (encoding) is identified by the encodingStyle attribute. If you do not know the encoding you cannot communicate with the web service endpoint. The encoding can be any set of rules. however most of the time you will see encodingStyle="http://schemas.xmlsoap.org/soap/encoding" which refers to the dreaded Section 5: SOAP Encoding. That encoding was originally designed to help in the serialization and de-serialization of data structures used in most programming languages even of entire object graphs (something not supported under XML Schema). However it was ambiguous enough so that two separate vendor implementations of the encoding may not work together. As a result, if for example you run an Axis web service endpoint with an RPC service style (rpc/encoded messaging mode) other SOAP stacks (like .NET) may not be able to interact with it perfectly because of a slight difference in interpretation of the SOAP encoding. The situation is exacerbated if you exchange custom objects you have to write custom serializer/de-serializers which the web service client has to have access to (or write their own) to use your web service. So in the case of the "encoded" messaging it is not sufficient for the web service client to have access to WSDL; they also have to have access to an independent encoding/decoding mechanism. In the case of SOAP encoding, use of certain data-types in your service endpoint interface could limit your interaction to a certain SOAP stack (e.g. only Axis to Axis, .NET to ASP.NET, etc. works) and possibly limit your client platform (Java , .NET, etc.), which is made worse if you exchange custom data-types requiring custom serialization and de-serialization. For obvious reasons "encoded" is not endorsed by the WS-I Basic Profile.

To Be Short -

Literal - Data in SOAP Body is an instance of the XML Schema defined in WSDL types

Encoded - Data in SOAP Body is an instance of a certain XML encoding rule (e.g. SOAP Encoding) but not the XML Schema defined in WSDL types. However these encoding rules express the same validation result as the XML Schema. The data in SOAP Body is not the direct instance of the XML Schema.

http://msdn.microsoft.com/en-us/library/ms996486.aspx#understand_topic6

http://msdn.microsoft.com/en-us/library/ms996466.aspx

http://msdn.microsoft.com/en-us/library/ms995710.aspx