After reading this article I understood that each style has advantage and disadvantage.
Which factor drive towards the WSDL Style? Meaning, Is architect/developer drives the decision to choose which one to use based advantages and disadvantages? How is this going to work in production environment.
I am so sorry if this is stupid question?
vishnu moorthy wrote:Is architect/developer drives the decision to choose which one to use based advantages and disadvantages?
Currently there is actually less choice than the article suggests.
Most current generation SOAP web service stacks don't even support the rpc/encoded messaging mode anymore - so if you have to consume to an existing rpc/encoded SOAP web service you usually have to employ a previous generation SOAP client web service stack and pray that it interoperates with the existing web service.
rpc/literal was popular for a while because it is more interoperable but generally has fallen out of favor because only the parameters can be validated using standard XML schema tools (e.g. a validating parser) - if you want to validate the entire SOAP body your tools would have to be WSDL aware.
document/literal is the "de facto" standard for a modern SOAP web service. You send a single "document" to the endpoint and the endpoint routes the "document" to the "web method" (operation) that is responsible for processing that "type of document" (i.e. no operation overloading, as the name of the operation is irrelevant to the consumer-provider interaction). If the operation uses an in-out (request-response) message exchangepattern (MEP) you get a single response document back. The SOAP body can be fully validated with a standard validating XML parser.
Because some people simply cannot let go of the RPC paradigm (and to accomodate tools that generate the web service contract (WSDL) from code - which is considered by some an anti-pattern) there is the wrapped document/literal convention which basically replaces of the rpc messaging style while using the document messaging style.