In addition to the link that was pointed out to you (now for the second time
), consider this:
Originally posted by Vasim Patel:
Is base 64 encoded MIME an example of encoded?
Definitely not. A
SOAP message can only have XML as a payload. MIME is not XML. MIME is used for attachments and because MIME is non-XML, SOAP-with-attachment is actually a multipart MIME document where the first part contains the SOAP message. So in fact, in SOAP-with-Attachments the "SOAP envelope" is inside an "MIME envelope", while the attachments are the 2nd, 3rd, etc. part. SOAP with attachments has got nothing to do with literal vs. encoded.
base64 encoded content can be part of any SOAP message, literal or encoded � simply because XML schema has a data type (
base64Binary) for it and even if it didn't you could still do it by sending plain text (
string)� which is the entire point of base64.
Originally posted by Vasim Patel:
If literal means any valid xml document, what does encoded style mean?
The service endpoint and the service client always
exchange SOAP only - which can only contain XML and it always has to be XML � unless we are using SOAP with attachments, in which case the SOAP message is contained by a MIME multipart document.
Literal vs. encode deals specifically with the interpretation of the XML payload within the SOAP message.
"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�s 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.
[ February 13, 2006: Message edited by: Peer Reynders ]
1
