Web Service Performance Considerations

Web Service is getting pervasive, it is hard to find a project without web services nowadays. When the SOA maturity level is "entry level", Web services are extensively used as an integration mechanism. In the higher maturity levels of SOA, applications are assembled out of Web services called SOBA or Service Oriented Business Applications. SOA itself is in the native stage of the Adoption curve.
Two key challenges of adoption are the performance and security of web services. Better performance is a catalyst for successful design deployment of web services.

This volume addresses the various performance considerations for the design of web services.

Web Service Performance Considerations

The focus of this article will be on performance considerations for Web services-based solutions. The value proposition of Web services is its enablement of interoperability, flexibility, reuse of assets, reduction in development and operational costs, and better relationships with business partners and customers.

The three most common web service performance bottlenecks are:
Parsing SOAP messages
Marshalling and un-marshalling of Objects to XML and vice versa
Providing security to the data


To improve Web Services, the following set of practices are used to direct the design to optimize performance:

1. Payload size versus payload complexity - It is always good to have simple and small messages as payload in any of the web services. Based on the business needs, occasionally it is needed to process complex XML. Larger messages result in longer parsing times while complex XML structures with nested elements result in longer times for the marshalling and un-marshalling of Objects and XML elements. The goal is here to reduce the payload size of complexity of the XML data document. It is good to choose to support a single invocation that includes a larger and more complex message versus supporting separate individual message transactions. Persistent connections are good for performance in case of a large number of messages of small payload size. In case of large payload Streaming connections are good for performance.

2. Document/Literal versus RPC/SOAP encoding - With Document/Literal approach there is no type encoding information. It is easy to validate the message as everything appears in soap:body message schema. The method names are available in the SOAP message and it is WS-I compliant. With RPC/SOAP the WSDL is as straightforward as it's possible for WSDL to be. It is easy for the receiver to dispatch the message to the implementation of operation as the operation names appear on the message. But the disadvantage is the type encoding info is usually an overhead, it cannot be easily validated and it is not WS-I compliant.

3. Parsing of SOAP messages - Minimize parsing XML data - Often a business function needs to be exposed as an XML service that leverages SOAP for both internal and external consumption by business partners minimizing parsing of the SOAP messages. In such cases, it is good to leverage on partially parse SOAP messages to minimize their impact on performance. While comparing DOM and SAX it is good to parse the messages with SAX but we have STAX parser developed for Java community which reduces the time to parse the XML messages. Other practices like zipping the message and binary encoding of message will help to improve the performance. It is recommended not to enable message validation through the parser if performance is a high priority. STAX gives a precise control over XML document processing with simple iterator base API and an underlying stream of events or cursor style object API. As distinct from other event-based approaches STAX allows to stop processing of the document, skip ahead to sections of the document, or get subsections of the document.

4. Marshalling and un-marshalling - It is good to design/define the message architecture to maximize the size of information that will be exchanged over the net. Messages with many elements and attributes and little data are part of any complex XML schema. Parsing SOAP messages is viewed as the biggest contributor to the performance issue. However, a complex message structure can also result in more than 50% of the processing time being associated with marshalling and un-marshalling of Objects and XML elements.

5. Security approach - Security has performance costs; the key information is secured and also makes sure that you are not securing the data which may not be secured over the network. WS-Security technologies are costlier than in terms of performance comparing with traditional SSL with HTTP. Best practice is to combine the two approaches, SSL for encryption and XML digital certificates (signatures) for authentication.

6. Web Service design - Design Web service interface to minimize the network traffic by defining a 'coarse-grained' API. With this design the number of requests from client service to server service will be minimized.

7. JavaBean versus EJB components - If the solution doesn't require the J2EE runtime support for transaction, security, and management that's enabled through the use of EJB components and the EJB container, then JavaBeans will suffice and will provide better performance. If the solution is using EJB components and deploying them locally within the same JVM as the SOAP engine, then ensure to deploy them in such way that they are called using pass by reference. By enabling pass by reference, the parameters of the method are not copied to the stack with every remote call, which can be expensive. Enabling pass by reference can improve performance up to 50%, when the SOAP engine (EJB client) and the Web service provider (EJB Server) are installed in the same application server instance and remote interfaces are used.

8. Optimizing performance using cache - For Web services that support HTTP, cache the results of their processing for use on future requests. And it is useful in the read-only type of web services.

9. Retrieval of service bindings from a UDDI registry - UDDI registries are used to publish Web services information for dynamic discovery. On client's service invocation, the UDDI registry returns access point of the service. It can be achieved with front-end the local service proxy created from the service provider's WSDL with a general proxy that queries the UDDI registry and caches the access points for a given period of time. The client application calls the general proxy that calls the service proxy to invoke the service provider.