Avoid Constant Recoding
Whether you build your own Web services management system or purchase one, you'll want to give careful consideration to the underlying mechanisms used to provide management capabilities. One method is to hard-code the appropriate logic into the Web services themselves. The challenge there is implementing and maintaining your management capabilities as your Web services evolve from early pilots to production systems and beyond. Another approach is to have the Web services and clients embed proprietary headers into SOAP requests and responses, which limits your management capabilities to only those Web services over which you have direct control.

A much better approach is to use Web service intermediaries that intercept traffic in order to provide the necessary management capabilities (see Figure 1). With this approach, all the management policies reside in the intermediaries, enabling your Web services environment to grow naturally and without added development-time constraints.

Figure 1

Intermediaries may be HTTP modules that enable you to intercept, participate in, or modify each individual request. Adding an HTTP module is straightforward, requiring only small configuration changes to your service's configurator. Modules implement the IHttpModule interface, which is located in the System.Web namespace. To add an HTTP module:

<configuration>
<system.web>
<httpModules>
<add name="MyModule"
type="MyModule.SyncModule, MyModule" />
</httpModules>
</system.web>
</configuration>

There are a number of solutions for managing your Web services. Before evaluating these options, you'll want to take a close look at your requirements. Your management needs will vary with the complexity of your Web services system, so let's look at management requirements at the various stages of Web services development – from pilot to production to extra-enterprise business system.

Getting Started: Web Services Pilots
IT departments usually start by building a few request/responseoriented Web services. These are typically stand-alone components, each of which is consumed by a client application built solely for the purpose of testing. Here, your primary goals will be fine-tuning your Web services for performance and establishing the framework for production Web services. To accomplish these goals, you'll need to monitor the operational characteristics of your Web services, including:

You'll also need to log Web service requests and responses to aid in debugging and error tracking, including:

Additionally, you'll want a tool for quickly and easily creating different types of messages from the schema and sending them to the target Web service. Such a utility will greatly improve your productivity, especially when fixing and testing Web services.

When testing the functionality of a client, it's better to send requests to a simulated Web service, rather than the actual endpoint, especially when the Web service is capable of performing a write operation. This avoids the need to clean up backend transactions generated during testing. The simulated Web service sends a canned response based on the attributes of the request. A simulated Web service also helps in generating random responses for testing the resilience of the client.

Fine-tuning your Web services pilot calls for constant iterations. That means you'll need to reconfigure your management system without requiring a system shutdown. Users must be able to grind through the cycle of modifying their Web services, deploying them and monitoring them again as easily as possible.

Taking It Live: Production Web Services
As Development hands over the Web services system to Operations, the primary concern becomes the general manageability of the system when it's not being monitored by its team of developers. Your Operations team will want assurance that the Web services will survive the production environment and that they can monitor the system for runtime errors, performance degradation, and outages.

Some key issues include:

Monitoring Availability
You'll need to continually check your Web services to see if they're alive and kicking. You can ping a Web service by sending either valid or invalid SOAP messages and then looking for appropriate responses. Or you might send a network-level ping to the container to see if it's alive. Another approach is to inspect all Web service responses for SOAP faults or network errors. You might discover a particular type of SOAP fault that indicates a critical error. For example, with this approach your Web services management intermediary can immediately detect the message failure in the XML document shown in Listing 1. Upon detection of the messaging failure, the management system would redirect requests to a backup Web service.

Security Enforcement
Given the readability of XMLbased messages and the vulnerability of Internet-based networks, security becomes a greater priority for Web services. You'll want to apply your existing security measures as well as message-level security. Additional security options include:

Active Alerting
Your management solution should serve as a command-andcontrol center for your Operations staff. It should create and deliver important messages (e-mail, pager, log files, etc.) regarding the system's operational health, including the following capabilities:

Web Service Failover
Backup instances of your Web services will improve the robustness and reliability of the endpoint. However, you'll need capabilities beyond traditional means of failover. For example:

Metering and Monitoring
Operations wants to monitor the consumption of the Web services. This includes capturing timestamps, transport-level headers (such as client IP address), and username for each Web services request. Furthermore, they must be able to report each request as an event to third-party billing or metering systems.

Blocking Traffic
As you roll out your Web services, there will often be maintenance periods when back-end databases or other resources are updated. In such situations, you'll need to block all inbound Web services requests. Doing this gracefully means that your operations staff must be able to set up a custom SOAP fault message for consumers of the Web service.

Composite Applications and Beyond
As you start churning out more and more Web services in each development cycle, you'll soon have dozens of Web services that need to be managed. Likely, you will have glued Web services together in the form of assemblies or orchestrations to create higherlevel business services. The stakes are higher here. Unlike in your pilot or early production stages, now your Web services will be used for mainstream business applications that directly impact your bottom line.

Most Web services management issues stem from the increased number of moving parts in your IT mix. Your business applications depend on multiple Web services. Your Web services have multiple clients. And your business systems interact with Web services that you don't own or control. This significantly raises the chaos factor in your environment. Remember, a distributed system composed of twelve components, each of which has 99% availability, is only 89% available.

You'll need to address these growing pains. Key management issues at this stage of Web services include the following.

Online Upgrades and Redirects
As you develop more Web services and patch old versions, it will sometimes be necessary to enforce backward compatibility with consumers. At other times, you'll need to host multiple versions of a Web service simultaneously, each satisfying a different set of consumers. In either situation, it's critical to introduce new Web services seamlessly, without requiring a change to the client code or a shutdown of existing clients or services. The key requirements here are: