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.

• Figure 1