Web Services Monitoring and Performance Management

It's critical that service-oriented architecture (SOA)-based Web services solutions provide high-performance, reliable, extensible, scalable, and open standards-based communication and integration for both internal and external applications that can be easily monitored. To meet these goals, it's imperative that companies design their Web services correctly, check service quality, conduct active performance management, and continuously monitor the end-point integrity of Web services. This article discusses monitoring and optimizing the design and runtime performance of Web services.

Essential Traits of Web Services
Web services is just another distributed-computing technology for revealing the business services of applications on the Internet or intranet using open and standards-based XML protocols and formats, but some essential traits make performance management and monitoring of Web services both different and necessary.

Simple Object Access Protocol (SOAP) is the wire protocol for Web services. SOAP HTTP calls cost in terms of network traffic and latency, CPU cycles at the SOAP server, and possibly SQL latency at the database server. SOAP overhead includes extracting the SOAP envelope and parsing the contained XML information. Further, XML data cannot be optimized much. Other essential traits include:

The overhead of encrypting and decrypting data
The overhead of using Universal Description, Discovery, and Integration (UDDI) for dynamic binding
Dependence on the quality and service-level agreements (SLAs) of external Web services
Latency of dynamic binding
Monitoring of end-point integrity

The core intent of Web services is to loosely couple disparate applications and platforms using standard interfaces and protocols. This is also its weakest link as far as predictability and runtime behavior are concerned and makes monitoring and performance management even more important.

The Current State of Monitoring
Before we look at Web service monitoring, it's important to understand the current state of application monitoring methodology and know the tools used within companies. The current state can be summarized as follows:

End-to-end monitoring and performance- management tools and technology are still evolving.
A proactive strategy is desired, as opposed to reactive monitoring and performance management.
Usage and existence of "island or silo management" and summing up, i.e., monitoring the individual components of an application and summing them up for the end result.

Typical reactions to production problems vary from "it's their system/API/Web service... not ours!" to "the database is extremely slow" to "the network is congested" to "everything is fine, just reboot your machine." Bottom line: in the absence of an end-to-end monitoring tool, no group is willing to take responsibility.

Monitoring Web Services
Both network and systems management monitoring are critical for Web services operations. In lieu of this, testing can be used to monitor Web services - some of the tests mentioned below have to be performed in all three application environments (development, quality assurance, and production):

Availability test: Checks whether a Web service is present and ready for immediate use.

Performance test: Measures the throughput (how many requests can be served in a given time frame) and latency (how much time elapses between the request and the response). This test is useful in evaluating performance in terms of how long it takes to service clients' requests.

Stress test: Determines and monitors the breaking point of a Web service based on load and permits only that level of load.

Reliability test: Determines how capable a Web service is of maintaining the SLA and service quality.

Scalability test: Checks whether a Web service is vertically and horizontally scalable.

Failover or high-availability test: Ensures that the failover solution for a Web service is working correctly and that Web services clients aren't affected by the failover.

Integrity test: Determines the correctness in execution of Web service transactions.

Corrective measures monitoring: Checks the health of the Web services provider application for features such as deadlock, process being hung, and time-out periods. If the provider application is supposed to take corrective measures, its behavior should be monitored.

There's no doubt that Web services will be only one of several technologies to play a role in both enterprise application integration (EAI) and business-to-business (B2B) integration. For end-to-end application monitoring, which may be supported by one or many Web services, all the supporting application and platform components (such as messaging and databases) must be monitored as a single unit.

Performance Management of Web Services
Performance management of Web services should be discussed and tackled from two different perspectives: design and runtime. They're equally critical. Let's start with good design considerations that will impact the performance of a Web service.

Web services invocation operations are expensive. It's preferable to use them in macro rather than micro cases, i.e., where a lot of work is to be done and a lot of information has to be returned.

Depending on the nature of the Web service, asynchronous messaging can improve throughput. This, however, will come at the cost of latency.

The design of a Web service should be such that there is very loose coupling between the presentation-tier clients and business services.

"Business delegate" design patterns should be used whenever possible. This will hide implementation, lookup, invocation, and caching details from the client application. The business delegate will convert all infrastructure-related exceptions into business exceptions, shielding Web services clients from knowledge of the underlying implementation specifics.

Whenever possible, implement a caching mechanism for business service information. This will speed up the application and reduce network traffic between the client and the provider.

Avoid aggregating the data from data-supplying Web services in real time on demand. Instead, create a data-aggregating Web service that aggregates the data in a batch mode.

Several XML parsers perform expensive operations (type checking and conversion, checking for the correct format) that make performance slower than optimal. Consider using a stripped-down XML parser that performs only essential parsing.

Problem Resolution
To achieve runtime performance management for Web services, the monitoring tool must be able to collect specified, defined measurement data; analyze it; and check for exception conditions. If any exception condition has been met, as defined in the configuration, the monitoring tool should alarm the operators and/or take corrective measures. Exception conditions can be based on an individual parameter or a combination of parameters and can be defined using both thresholds and duration. This will allow for proactive detection of problems. For example, to deliver good SLAs, exception conditions can be set on the latency of Web services calls and throughputs, which will be monitored in real time by the monitoring tools.

To achieve sophisticated runtime performance management of Web services, the tool should not only detect exceptions and take corrective measures, it should also be able to re-create the exceptions. Re-creation of exceptions will help eliminate performance bottlenecks by diagnosing the cause. Further, end-to-end reporting of all activities involved in a Web service operation will help the application developers and managers discover what's going on in operational Web services- based applications and, if required, take corrective measures. Finally, we can't stress enough that runtime performance management may require considerable storage and even processing overhead. Application-specific policies concerning the extent of Web services monitoring and the length of data-retention periods may need to be developed. If the duration of data retention is long, you may need to develop data compression techniques. But the monitoring tools should provide all these features.

Web Services Monitoring and Performance Management
Here are the key factors for monitoring Web services, based on our experience:

Use design patterns to alleviate performance bottlenecks.

Monitor the whole transaction as a single unit.

Make SLAs part of your application review process.

Monitor the SLAs and take corrective measures.

Ensure that Web services supporting mission-critical applications are monitored in real time with very little latency.

Make sure that there's a single interface for monitoring, analyzing, and forecasting resource utilization for Web services.

Define the exception conditions for performance management of both the threshold and the duration for proactive problem detection and resolution.

Last, avoid chaining of Web services if possible, as it will make their monitoring even more complex. (Note: a Web service can be implemented as its own business process, or a business process can be composed of any number of Web services, which themselves can aggregate other Web services to provide a higher-level set of features. This results in chaining of Web services.)

Internal First, External Later
Monitoring and performance management of external Web services is much harder than that of internal Web services, since the user may have no control over the quality of the Web service provided. In order for companies to start embracing Web services technology, it's crucial to start using Web services for private processes or internal applications before using them for public processes or external applications. Public processes and external applications pose greater risks as far as security, transaction management, auditing, and persistence are concerned - and monitoring them is even harder.

Author Bios
Gunjan Samtani is divisional vice president, information technology, at UBS PaineWebber, one of the world's leading financial services firms. He has several years of experience in the management, design, architecture, and implementation of large-scale EAI and B2B integration projects. Gunjan is the primary author of B2B Integration: A Practical Guide to Collaborative E-Commerce (Imperial College Press) and Web Services Architectures and Business Strategies (Wrox Press). gsamtani@ubspw.com

Dimple Sadhwani is a senior software engineer at Island ECN based in New York. She has many years of experience working for financial and telecommunication companies on large-scale trading systems, CRM applications, Internet/intranet portals, and client/server applications. Dimple is the coauthor of B2B Integration: A Practical Guide to Collaborative E-Commerce (Imperial College Press) and Web Services Architectures and Business Strategies (Wrox Press). dsadhwani@island.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.