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:

As you upgrade and evolve your Web services systems, you'll need to maintain backward or forward compatibility between clients and Web services. In general, this will involve a transformation.

Say, for example, you're upgrading a placeOrder service from version 1 to version 2, and the XML for placeOrder1 looks like that shown in Listing 2. With the upgrade to placeOrder2, the affected XML element is:

<placeOrder2 xmlns="http://acme.com/placeOrderService">
...
</placeOrder2>

The transform shown in Listing 3 will change a Web service call on the operation "PlaceOrder1" to "PlaceOrder2".

Managing Service Levels
You'll need to ensure that you're setting and maintaining appropriate services levels (availability, response times, etc.) for different consumers – customers, partners, and other departments within your company. Advanced capabilities in this area include service-level baselining, trend analysis, historical reporting, and prioritized service delivery.

Real-time Business Insight
Thanks to their rich information payloads, SOAP messages foster unprecedented levels of business insight. The key is to leverage that data to create additional business value. For example, a business manager might want to know the total number of orders for part XYZ that have passed through the system in the past 24 hours. Or you might want to alert that business manager any time there's an order for more than $1 million. You'll also want to log useful business data into customizable reports so business managers can analyze trends and you can allocate appropriate IT resources to each business service.

No Time Like the Present
As you evolve your Web services from pilots to early production and, eventually, to composite applications, you will have a corresponding increase in management requirements. That's not to say, however, that the role of managing your Web services is any less important at the outset. In fact, the sooner you start managing your Web services the better. Getting up to speed on Web services management early on will help you build more robust Web services and will establish an effective framework for future development. Additionally, you'll have logged some quality time in meeting production requirements, so that both your team and your Web services will be ready for the enterprise.