Web Services Best Practices
Use WAS 5.0.2 Web Services Instead of SOAP
WAS 5.0.2 introduces a better-performing Web services implementation than the SOAP implementation based on Apache SOAP in WAS 4.0 and iWAS 5.0. However, WAS 5.0.2 still includes support for the WAS 4.0 Apache SOAP implementation for legacy Web services applications. Figure 2 shows the difference in performance between the Apache SOAP and the newer Web services support in WAS 5.0.2. Figure 2 also shows performance with the same object payloads for the Web Services Technical Preview that was in WAS 5.0 and WAS 5.0.1.

 

Figure 3 shows how performance improved from WAS 4.0 SOAP, to the WAS 5.0-5.01 Web Services Tech Preview to WAS 5.0.2. The performance improvements were largely due to the reduction of parsing and XML-to-object deserialization.

 

Keep XML Payloads Small and Simple
This is the main Web services best practice. The performance of your Web service is directly related to the size and complexity of the XML payload transferred. Some of the Web services best practices that follow expand upon this one. Refer again to Figure 2, which shows the performance impact of the input payload's size and complexity in terms of the number of XML elements. Recall the three performance components or pressure points of Web services shown in Figure 1: Parsing, XML-to-object deserialization, and object-to-XML serialization. As input documents increase in size and/or number of elements, they require more processing for both parsing and deserialization. As output documents increase in size and/or number of elements, they require more processing for serialization. As I will explain in the next best practice, you shouldn't reduce the size and complexity of the XML payload by transferring smaller but more frequent payloads.

Avoid Fine-Grained Messaging
Every Web services request by definition is a remote request, typically involving the Web container or JMS plus the XML overhead of parsing and deserialization. Figure 4 shows the performance implications of fine-grained messaging. If you need to send or retrieve a 50K object that has 10 properties, each 5K long, you can retrieve all 50K as one Web service request, as 50 requests for 1K or some other combination, such as 10 requests for 5K each. Figure 4 shows the performance implications and comparisons. Transferring the 50K in one single Web services request is the best-performing alternative. Transferring 1K, 50 times is the worst-performing alternative. The overhead cost of latency is the major factor.

 

Avoid Deep Nesting of XML Payloads
I previously discussed the first two dimensions of performance:
1.  Length of data elements
2.  Number of elements or complexity

This best practice adds an important third dimension, level of nesting, which translates to objects defined within other objects and collections of objects defined within other objects. Increasing the level of object nesting translates to an increase in the number of objects that are deserialized and created coming in from the input Web services XML. An object of a certain size that is composed only of primitive types, strings, etc., will yield better Web services performance than a similar size object composed of deeply nested Java objects. Web services deserialization is the differentiator. Figure 5 compares the performance effect of the first two dimensions, size and complexity, with the third dimension, nesting. The chart shows that an object that is 18K in length with 500 complex objects but that is deeply nested will perform worse than an object that - although 50K in length - is comprised solely of 500 strings of Java primitive data types.

 

Use WAS Custom Serializers
The WAS 5.0.2 Web services engine provides business object-specific serialization/deserialization assistance that improves runtime performance. For each business object, these custom serializer/deserializer helpers assist the Web services engine by specifically describing the object's properties. This improves performance by reducing the Web services runtime use of introspection to obtain business object-specific information.

The business object-specific custom serialization/deserialization routines are a by-product of WSDL definition during the Web services deployment process. Using these object-specific performance aids is a best practice. In various lab experiments I have seen anywhere from a 5% to 10% improvement in performance by including the custom serializers/deserializers in the packaged client and server implementations.

Favor Literal Over SOAP Encoding
Use literal encoding instead of SOAP encoding. Literal and SOAP encoding are alternate forms for encoding Web services requests and responses. SOAP encoding is the older and now less commonly used form of Web services encoding. Each element in the SOAP body includes the XML Schema definition type of the data element. SOAP encoding was needed to make the message self-defining. SOAP encoding with the embedded data types increases the amount of data transferred in the Web services request. We previously established the performance impact of XML message length. Figure 6 shows a comparison of data lengths for SOAP encoding versus document/literal for a typical workload.

 

Use Descriptive But Short Property Names
There is a long-standing and fundamental best practice that recommends using long and descriptive property and variable names to make programs more readable and self-documenting. This presents a performance issue when applied to XML-based Web services. This best practice for long and descriptive property and variable names is based on a bytecode binary protocol that uses symbols and other identifiers for variables and properties. Web services is an XML text-based exchange protocol; names of variables and properties are included in the XML for the SOAP body portion of the message. Keep in mind the best practice I discussed earlier - keeping XML payloads small and simple; be aware of the effect that message and SOAP body length have on Web services performance. Use descriptive names for variables and properties but be aware of the impact on message length, and in turn, the impact of message length on performance.

Performance Consideration:
Favor JavaBean over EJB for Provider Type
J2EE Web services has two server or provider types: JavaBean and EJB session bean. There is a natural inclination to use EJB session beans as Web services. EJB session beans provide well-defined interfaces that characterize a distributed service endpoint. However, there is extra overhead associated with using an EJB session bean.

Consider using a JavaBean instead of an EJB as the Web services provider. This is not a best practice because there are often application factors that require EJB services for security and transactions. These factors outweigh the performance benefit of a JavaBean provider. If transactions and/or security are not needed for your Web service, then using a JavaBean provider might be the correct and better-performing option for your application.

Figure 7 shows the performance comparison of a JavaBean provider with an EJB provider. The overhead difference has a bigger impact on simpler messages and higher volumes. The performance difference tends to dilute as message size, complexity, and nesting increase.

 

Use 'Pass by Reference'
If you choose to use the EJB provider for your Web service, make sure that you use the WAS EJB/IIOP "Pass by Reference" optimization, "No Local Copies". The Web services EJB provider is conceptually nothing more than an XML message sent to a servlet that makes an EJB call. Because all of the artifacts are in the same JVM, there can be a performance boost for using "Pass by Reference" call semantics. Figure 8 shows the performance improvement for using Web services with an EJB provider with the WAS Server Properties for the ORB Properties set to "Pass by Reference".

 

Conclusions
WAS 5.0.2 provides a significant Web services performance enhancement. Using the performance best practices discussed in this article, and based on WAS 5.0.2, you can write new applications or leverage existing application artifacts without fear of a Web services performance penalty.

Acknowledgments
The author would like to acknowledge: