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:
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.
Originally posted by Rick Reumann: I still don't see how you could make too many changes to the schema and not break the interface (and vice versa).
You can add new, optional elements to a schema definition to your heart's content without breaking any backward compatibilty with older documents.
posted 13 years ago
Originally posted by Peer Reynders: You can add new, optional elements to a schema definition to your heart's content without breaking any backward compatibilty with older documents.
I guess I'm just being dense but when you say "schema definition" I'm assuming you mean a schema that represents a wsdl? So lets assume my service layer adds another method exposed as a webservice. I deploy (or the container deploys) a new wsdl. Older clients still using the older wsdl definition won't be affected by this change assuming the older web services methods still exist? Am I too assume this wouldn't work with an RPC style service? With an RPC service I couldn't expose a new web service method on the server and have older clients NOT break (without them using the new wsdl) whereas a Doc/Literal service wouldn't break the older clients? Just trying to clarify that I have the advantage down correctly. Thanks.
posted 13 years ago
Originally posted by Rick Reumann: when you say "schema definition" I'm assuming you mean a schema that represents a wsdl?
In the case of a document-oriented web service the WSDL is likely to reference an external schema (see WSDL file imports) that defines the documents that are being exchanged - those are the schemas I was referring to. By keeping the new elements in the document optional, older clients can still use "the old way" while newer clients can take advantage of any additions. (Now granted WSDL and Schema version control can become a headache unless handled very carefully).
Theoretically you should still be able to use older operation definitions with older clients with the RPC-style as long as you do not change the operations and the input, output and fault messages they use. That approach however can lead to a proliferation of messages that vary only slightly (i.e. duplication) and to some bizarre and cumbersome operation names especially as WSDL 2.0 disallows operation overloading (WSDL 1.1 allowed it which lead to problems as some implementing platforms do not natively support overloading).
For a primer on document based web services see: Patterns and Strategies for Building Document-Based Web Services).