Hello Jim,
Thanks for explaining some of the issues which were totally esoteric to me. Off late, I have been into lot of tutorials and low-level details
which forced me to develop this notion. Can you please clarify me on the following issue.
My pleasure - as much as I can.
http://www-106.ibm.com/developerworks/webservices/library/ws-docstyle.html
Do you think that memory processing would be an overhead for RPC styled web service due to (un)marshalling of parameters?
Well it really depends on the size of your request data. Nobody would care if we were only talking about a few short strings, ints and floats. You get into trouble when you have say > 1MB messages and you have significant load.
Also, I don't think its really *rpc* that he is/should be referring to but rather *encoded*. As in rpc/encoded versus doc/literal.
SOAP encoding has rules for (de)serializing elements, references to elements, typing and arrays that make processing feasible only when you have the entire DOM (or equivalent) in memory. The SOAP encoding rules make it difficult to stream the XML since you may have to look ahead or cache large hunks of the stream to follow ids/refs. Not to mention the fact that its hard to write int he first place so typical implementations grab a request as a DOM and can traverse it at will doing all the SOAP "decoding".
For literal messages you can theoretically stream the request in and process it as you go. This gets around the need to actually hold the entire message contents in memory at one time. Which in terms of perf for large messages is the most critical factor. Theoretically you could you a stream XPath processor to select out the data you want and build a response stream as you go.
One rarely mentioned little piece of nastiness is this. You have to consume the entire request before you can legally return the response. Because how do you know you received an entirely valid XML document until you read the last tag?! When you do receive malformed XML you are obligated to return a fault - NOT a soap response Body. So this kinda makes the whole thing a little more complicated.
To make a long story short - don't make an rpc vs. literal decision based on perf! They are completely different worlds.
Jim Murphy Mindreef, Inc.
