Yes, I have googled around and there are sites that explain the differences between RPC Encoded, RPC Literal, and Document Literal, but to a beginner the differences described are often difficult to grasp and even more difficult to grasp is the benefits of using one type over another.
I've currently installed JAX-WS on
JBoss(4.0.5) and apparently this sets up the default behavior of deployed web services to be Document/Literal.
This site below does a good job explaining the differences between the types, but I'm still left scratching my head after reading it:
http://www.eherenow.com/soapfight.htm I guess to be more specific, I'm still a bit confused on the particular advantages to using Document/Literal. According to the site above the strengths are:
No type encoding information in the SOAP message. (Smaller footprint)You can always validate the message with a XML Schema. Since everything within the SOAP body is defined in the schema.The rules are less rigid and many enhancements and changes can be made to the XML schema without breaking the interface. As far as point one goes I guess that's an ok strength. So the document is a bit smaller without definitions like xsi:type="xsd:string". Doesn't seem that big of deal to me, but I guess with large documents every reduction in size counts.
Point two above - ok that is nice, but I must be missing something as to why you couldn't validate RPC style with a schema if you really wanted. I understand that the type info is embedded in the RPC style which would make validation more difficult I suppose.
In regard to the last point, this is also brought up as the weakness of RPC/Literal: "Any changes to the interface would break the contract between the service and the client since there is a tight coupling between service provider and client."
This last part above is the one I really would like some clarification on. I still don't see how you could make too many changes to the schema and not break the interface (and vice versa). I would really like to see a concrete example of this flexibility in action because I must be missing something obvious. Say your back-end method later needs two
String parameters and not just one - wouldn't the wsdl change? In my EJB3 environment my wsdl is even auto-generated so as soon as I were to change my webservice class, a new wsdl would be created matching the new contract. This I'm assuming would break any clients relying on older client stubs generated from the older wsdl. I seem to be missing how coupling is greatly reduced using Document/Literal over RPC.
Thanks for any clarification.