- Introduction
- Performance Summary for RPC-Style Web Service Exchange
- Performance Summary for Document-literal Web Service with Low Payload
- Performance Summary for Document-literal Web Service with Medium Payload
- Performance Summary for Document-Literal Web Service with High Payload
- Analysis
- Implementation Issues with Axis Document-Literal Messaging
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Implementation Issues with Axis Document-Literal Messaging
Attachments are yet another way to a document-literal style of exchange. Web services with attachments are published as a way to send binary files. We can use this technique to send XML documents. Even though we haven't discussed attachments so far, this style of web service has the same benefits as document-literal services. The only difference is that the attachments are received outside the SOAP message body, whereas in document-literal services they're inside the envelope. Now that your business module does the validation checking itself, it doesn't matter whether you use document-literal messaging in web services as part of the SOAP body or outside it.
The problem with attachments is that they may not yet be fully compatible with all web services engines. Hence, we don't recommend this style as of now. However, there is one major flaw in the Axis document-literal web services that might compel you to consider web services with attachments. The current implementation of document-literal web services with Axis always returns the DOM structure of the incoming message directly to the business module. There's no way to retrieve the message as a string and bypass the DOM creation.
Why is this important? If your document is large, the DOM structure uses up all the memory—with our project, we constantly get OutOfMemoryExceptions on both the client and the server with a relatively small set of data due to the DOM generation in RPC-style services and also with document-literal services (were we to not use our alternate solution). We believe that Axis should provide an option to not convert to DOM but instead receive the raw data for document-literal messaging. In the absence of this capability, for our tests we embedded the entire XML inside a CDATA element and transmitted that over the wire. Axis returned the entire CDATA element as one string, which was our unprocessed XML message. We could then pass the message "as is" to the business module. Alternatively, we could use web services with attachments to transmit the XML documents, if we could manage the incompatibility issues that come with this style.
Another suggestion would be to use an RPC-style service in which your business module has just one String parameter that takes in an XML document.
Performance numbers with all these hacks were very similar to those of document-literal web services, and hence not illustrated in this article.