That's mostly because the
SOAP spec if fuzzy about encoding. So each implementation can have its own way to represent, code and decode data.
This can lead to serious interoperability problems.
Let's take a simple example : a
String parameter.
The SOAP spec allows different representations of a String object (both are correct):
* SOAP-ENC:string
* xsd:string
So imagine you're consuming a service to obtain the name of the best
java website
( btw, the response is like : <BestJavaWebSite>www.javaranch.com</BestJavaWebSite> )
Due to your SOAP implementation, you are waiting for a response like
but because the .Net provider of the service has chosen another representation of the String datatype, you receive :
Then you've got an interoperability problem your SOAP engine will not be able to resolve.
If such a problem can arise with a simple datatype like String, imagine the trouble with more complex elements !!!
That's why WS-I decided to discourage ENCODED style. (And
J2EE 1.4 adopted WS-I basic profile.)
Moreover, even if RPC-encoded sounds very simple to use, many tests have pinpointed scalability problems with the encoded style. So a professional web service will be far more efficient if it is designed using the LITERAL style.
[ December 15, 2004: Message edited by: Jean-Louis Marechaux ]