Some notes on Web Services performance
rpc/encodedstyle SOAP encoding. Now this is probably the most developer-friendly of the 3 encoding styles --
document/literal-- but not the most efficient. It brings to mind a couple excellent articles, one by Frank Cohen (Discover SOAP encoding's impact on Web Service performance) and another by Dennis M. Sosnoski (Cleaning up SOAP Web Services::Test Results) on the topic. The rationale is really simple.
rpc/encodedmodel, you call a remote object and pass requisite parameters. It is the SOAP stack's responsibility to serialize your request parameters into XML format and to de-serialize them into objects from the response XML. One can imagine that for complex objects and large payloads, this can have an impact on performance.
rpc/literalis a slight variation on the above. You can send raw XML data as a request parameter. The SOAP stack serializes this single XML data parameter, binding the request to the remote object. Unlike the
rpc/encodedmodel, the overhead here is just of serializing and de-serializing a single parameter.
Now in the
document/literalmodel, your request is actually an XML document. So is the response. The onus is on you to write the logic to extract the SOAP envelope's body element and parse the XML response.
So why do we choose development-time ease at the price of runtime penalties on scalability and performance? My opinion is this may be due to lack of awareness, not lack of diligence. That tools like Apache Axis (which is by no means the only one to do this) default to
rpc/encodedas the out-of-the-box encoding style only exacerbates the problem. I think Microsoft may have got it right in this case. The .NET implementations default to
I realize that Axis has a 1.2 beta out but do not know if any significant performance gains can be achieved with that. Going to production with a 'beta' version of an important cog in the wheel scares most decision makers.