- 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
Analysis
We've identified three aspects that affect web services engine performance (specifically Axis) and give some insight into why document-literal web services provide such excellent results.
These three areas seem to be the major sources of performance bottlenecks in the web services infrastructure layers:
Java reflection
DOM objects
Parsers
We'll discuss each area in detail.
Java Reflection
For some Axis developers and users, Java reflection could have a serious impact on the performance of the engine. Java reflection is a technique that allows the web services engine to receive the SOAP message and use generic serializers to convert them to Java objects (RPC-style service). This is a dynamic conversion done at runtime on every request—without any knowledge about the incoming message or the object signatures. Reflection is an expensive operation; you should weigh the convenience of letting Axis do the mapping for you transparently. In certain conditions—for example, for large amounts of data—it may be optimal to process data directly or use custom serializers to directly map the incoming XML into your objects.
Another option is to process the data directly in XML (document-literal), avoiding this mapping entirely and gaining significant performance. With document-literal services, even if you don't process the data directly in XML but convert it to Java objects first, because you have knowledge of the incoming message and your object signatures at development time you don't have to rely on Reflection to do the mapping.
Using a SAX parser and populating your data objects during the XML parsing performs significantly better than having Axis performing a dynamic binding for you at runtime. In our tests for document-literal services, we didn't process the XML messages exchanged, as that now falls under the domain of the business module with an XML interface. Avoid the Java reflection to bind data to objects was the major contributor to the excellent performance of document-literal web services.
DOM Objects
Creating DOM objects generates a large memory footprint. When Axis does the dynamic binding of the SOAP message to the Java objects, it has to create the entire DOM of the message in memory. There might be better ways to process incoming messages—using SAX processors, pull processors, attachment techniques, etc.—to avoid this inflated memory requirement. These alternate strategies can increase the transaction load and the payload size that your service/infrastructure can handle.
Document-literal web services don't have to create DOM objects. They can parse all incoming messages using SAX parsers and validation turned on in the same step. Also, if the business module manipulates data directly without converting to Java objects, we skip the step to serialize the message into data objects, giving an additional performance boost. No DOM creation in document-literal web services reduces the constraint for system resources, thus gaining the advantage of processing successful transactions for a large user base without any errors.
Parsers
Certain web services engines such as GLUE use custom XML parsers instead of Xerces. They claim to get significant performance gains through this setup. Considering that SOAP is XML-based, it could reduce web services engine overhead significantly. For Axis, this may just be the normal evolutionary path to resolve this issue as the parser implementations improve.