WSJ Management
Web Services: Monitoring and Management for Reliability
Do you need them?
Oct. 28, 2004 12:00 AM
Organizations looking to reduce integration costs are increasingly adopting a service-oriented architecture (SOA) to maximize their IT investment.
The preeminence of Web services as a tool that can support a wide range of dynamic business processes has made it the SOA tool of choice. Web services are easy to build but difficult and expensive to maintain. Monitoring and management costs weigh heavily on the ROI calculator, and in order to maximize ROI enterprises need to keep a keen eye on the support and reliability meter.
In the Web services world, an application is typically a chain of services, or "links," woven together in some sequence with a Web services front end. The chain itself is weaker than the weakest link in the chain. For example, if an application consists of three service calls, each with a reliability of 0.99, 0.96, 0.97 respectively, the overall application reliability according to the laws of probability and statistics is
Application Reliability = 0.99*0.96*0.97=0.92
The multiplicative effect of individual services tends to steeply reduce overall application reliability as the number of links in the chain increases.
Some of the biggest strengths of Web services, the HTTP and SOAP protocols, are also its weaknesses. HTTP is a stateless protocol that does not guarantee delivery of all the packets to the destination. Nor does it guarantee the order of the arriving packets. This makes HTTP an unreliable protocol incapable of meeting the delivery requirement of "Exactly once". If there is no bandwidth, the packages are discarded. SOAP is the wire protocol for Web services and has some inherent performance problems. Extracting the SOAP body from the SOAP envelope is time-consuming. Parsing megabytes of XML data with a lot of type information is slow and intensive. To increase the reliability of Web services and measure up to the more mature and robust middleware messaging standards, we need to fortify the managing and monitoring of Web services and enhance the reliability of the underlying protocols.
Monitoring and management are the two pillars of reliability. They are related in that the overall goal is to ensure that the QoS objectives are met. Monitoring is a "fault detection" mechanism that checks the health of a service in real time and tries to reduce application downtimes by detecting signs of failure. It ensures that the service is available, accessible, and capable of meeting the throughput and latency requirements. Management is a "fault avoidance" mechanism that lays down rules and policies that makes the service more reliable, usable, and robust. Management ensures that the services can be deployed in a consistent manner, configured from an easy-to-use user interface and meet the overall security and auditing requirements. Within an IT department, usually different groups are responsible for these two functions, so a degree of separation between them is desirable.
Monitoring: The Pulse of Web Services
Monitoring is essential to ensure the required QoS (Quality of Service). It tracks availability, accessibility, and performance of the Web service.
- Availability: Availability determines if the Web service is up and running. It can be determined by some sort of a "ping" mechanism that periodically executes a dummy request or some kind of a "push" mechanism built into the service that periodically generates heartbeats that can be monitored. Asynchronous push mechanisms work better in general as the system can be designed to perform a "health check" before publishing the heartbeat.
- Accessibility: Just because a Web service is "available" does not mean it is "accessible." The lack of accessibility may be due to reasons like an insufficient number of worker threads to handle the request under high load conditions, unavailable dependencies like a database, or other callable services. The "ping" mechanism works better to determine system accessibility. If the system is designed to perform a full periodic diagnostic of all system resources and dependencies, a push mechanism based on heartbeats may work, but the push mechanism cannot account for unforeseen exigencies.
- Performance: Performance profiles the execution of a Web service call and provides operational statistics. Its numbers measure both throughput and latency. Throughput measures the extent of usage of the Web service and determines scalability requirements. Latency is a measure of the round-trip time and can help identify bottleneck subcomponents or resources.
A Web service must be "coded" for monitoring during development if the Web service development toolkit does not support these monitoring options. Nearly all the big Web service providers - like IBM, TIBCO, BEA, and Microsoft - either have built-in support for availability and performance or are planning it in the next release.
Management: The Nerve of Web Services
Managing Web services is a much more involved activity than monitoring. It deals with the following tasks:
- Deployment: Manages a multitude of Web services from a centralized console in a consistent manner throughout the enterprise. Managing deployment includes the task of configuring the service, deploying the service to a server, and displaying the status of all the services on all the servers.
- Versioning: Ensures backward compatibility by ensuring that the older versions of client requests are served by the older versions of the service instance. It allows rollout of newer tested versions to a limited user group before a full-blown release, reducing the overall risk of exposure to a new version.
- Security: Deals with encryption and decryption of messages and authentication and authorization of the Web service clients. Authentication and authorization typically involve some sort of identity management as well.
- Scalability: The ability of a system to meet performance requirements by optimizing its use of software and hardware resources. Managing scalability can be extremely complex and typically requires policies that look at the execution profile and determine if the throughput and latency requirements are being met and issue an alert if the performance metrics are not being met.
- Logging and auditing: Trace the life cycle of the Web service call. Logging and auditing require disk I/O and are expensive tasks. Web services should be able to perform role-based logging "on-demand" or "on-error". "On-demand" logging is the ability to turn logging on or off from a management console without the need to restart the service. "On-error" logging is a feature by which the application logs only the errors in a very descriptive mode.
Web services need to be "instrumented" for management if the service provider does not support some of the vital management functions. The management objective is the one in which the Web service providers need to catch up. Most support deployment from a centralized console. Some of them support versioning directly; most support it indirectly through namespaces. None of them support the entire spectrum of security requirements and most of them do not support management policies. This has led to the growth of a unique class of middleware in the Web services world called Web Services Intermediaries (WSI). These intermediaries (like Oblix, Actional, AmberPoint and Ensemble) specialize in monitoring and management activities.
Management Brokers
WSIs (Web Service Intermediaries) provide all the features required for management and monitoring of Web services. There are a number of different tools out in the market. The tools differ significantly in how they approach the issue of monitoring and management but they all work in a similar manner to achieve their purpose. In spite of seeming differences, all the WSI products share some common design features. They all consist of an administrative GUI that serves as the monitoring and management console. Management is usually by way of policies that define which management tasks need to be performed and whether they need to be performed conditionally. The actual task of monitoring and management is achieved by either agents embedded in the Web services server or a proxy outside the server that interacts with the server in lieu of the client. In the proxy-type architecture, one endpoint of the intermediary is configured as a proxy for the provider and the other endpoint is defined for the consumer and a pipeline of activities are performed whenever a message is moved from the consumer to the provider (see Figure 1). The major players in the WSI world are Oblix, Actional, AmberPoint, and Infravio.
- Oblix offers COREsv as a comprehensive management product for Web services. The key components of COREsv are a policy manager, policy gateways, policy agents, and a policy dashboard. The policy manager of COREsv extends the identity management process of user-to-application interaction to application-to-application interaction and provides graphical tools to build security in these interactions. Policy gateways act as proxies that intercept inbound requests and implement policy steps in a non-intrusive manner. The policy agents plug directly into a Web service providers toolkit providing a more fine grained control over an application's operations than a gateway. The monitoring dashboard is a graphical tool that collects and displays data from the agents and gateways and executes rules that notify or correct problems based on the data. Oblix provides a custom built agent for TIBCO's Web service tool, BusinessWorks.
- Actional's Web services management product is "Looking Glass." Its essential components are an enterprise management console, an SOA planner (for analysis and planning) a customizable portal for service and SLA monitoring, and a management and policy server. Looking Glass provides "Service Stabilizers" that can be configured to define compensatory actions in case of failures so that the anticipated or known problems can be automatically handled. A root-cause analysis mechanism in Looking Glass provides a more comprehensive insight into failures and obviates the need to mine log files. Looking Glass excels in both monitoring and management.
- AmberPoint's AmberPoint Express provides logging, auditing, testing, exceptional handling, and a security mechanism for managing the Web services. Defining service-level objectives is the key to configuring the Web services for monitoring and management by Express. Analogous to the service stabilizers in Looking Glass, the product provides the capability to define compensatory transactions for service level agreement violations.
- Ensemble by Infravio uses contracts as the metaphor for defining relationships between the SOA provider and consumer. All the monitoring and management actions in the pipeline are terms in the contract. The product provides most of the management functions like logging, reporting, load balancing, versioning, fail over, authentication, and authorization. Ensemble is a management-heavy tool.
It is expected that some of the WSIs will be overtaken by the Web service development toolkit providers like IBM, TIBCO, BEA, and Microsoft in the future as these vendors reinforce their offering of Web services development tools with a management and monitoring stack.
Standards to the Rescue
A number of standards are emerging aimed at improving the manageability and reliability of Web services. These standards address some of the problems intrinsic to the HTTP protocol that make Web services unreliable.
WSDM and WS-Security are the two key protocols that will influence how we manage Web services in the future. WS Reliability is an effort to boost the reliability of the Web service by defining the QoS in the service call. The underlying protocol should be able to handle the QoS reliability requirements.
Build or Buy?
Chances are that most organizations won't need a comprehensive management solution to Web services. If your deployment hits critical mass (more than 20-30 Web services), you need to evaluate using a monitoring and management solution. The choice is between supplementing what the development toolkits offer with a planned and consistent code base that lays the foundation for management and monitoring or using one of the WS's. Using WSIs can cause some performance degradation in high volume, small message size situations. With larger message sizes, the compression feature offered by WSIs reduces the latency. The graphical nature of WSIs, drag-and-drop tools, and intuitive thinking to configuring contracts or service levels makes the task of monitoring and management easier.
A number of technical committees have been formed to address the deficiencies in monitoring and managing Web services. The future looks much better, especially with the Web service providers planning support for what the technical committees recommend. The monitoring and management services that a Web service provider will offer will serve to differentiate its product from competitors' products.
About Rajiv TotlaniRajiv Totlani is an enterprise integration architect with TIBCO Software. He has designed EAI systems using TIBCO?s Messaging, Web Services and J2EE Connector architecture for many of TIBCO's fortune 500 clients. Prior to joining TIBCO, he worked for SABRE in the Airline Software Solutions group where he was responsible for managing their Day-Of-Operations software products.