Availability
One of the reasons that you provide a Web Service is so that other applications can use it. If the Web Service has problems maintaining availability due to server failure, application crashes, network outages, or anything else, the usefulness of the Web Service will be greatly reduced. Your users want to be able to depend on the service being available when they need it. So, what are some of the things you can do to make the Web Service more available?
Clustered servers— Protect against power outages and server failure.
Multiple deployment locations— Allows the same Web Service to be accessed from multiple locations. This approach will also be discussed within the context of increasing performance.
Reporting— By providing reporting mechanisms through system counters, Web Service-specific reports, and other mechanisms, you can gauge how the Web Service is used. Knowing what is happening with the Web Service will let you know when you are approaching known limits.
Administrator communication— Make sure that you have installed software that will notify the system administrator of situations such as power failures, routing errors, and suspected attacks. Administrative software has become increasingly useful and should be used to keep tabs on your servers and other network equipment.
Let's dig a little deeper into each of these approaches.
Clustered Servers
Clustering on Windows involves taking at least two to four machines and setting them up so that one can take over the duties of another in case one machine fails for some reason. Most clusters contain two machines that are configured either as active-passive or active-active. An active-passive configuration contains one server that handles requests and another that does nothing. The passive server just monitors the active server, waiting for it to become unreachable. It might be unreachable for any number of reasons—power failure, a component stops working, or some other reason. When that happens, the passive server takes over. Networked users of the machine will not be able to tell what happened.
The other option is an active-active cluster. This allows you to use the two machines in the cluster for different purposes. If one machine fails, the working machine assumes the workload of the failed machine. This can result in performance degradation on the machine doing the work of the pair. The upside is that client applications will continue to function, albeit with a slower response time. This configuration has the advantage over an active-passive cluster that both machines are actually being used.
The clustering technology in Windows NT 4.0, and later, provides for the ability to keep both machines in the cluster in sync. For example, they can be set up to have the same specific files, applications, and database transactions on both the main machine and the backup. For information on how a specific product supports clustering, refer to its documentation. (Microsoft SQL Server is one product you will rely on that does support clustered servers.)
For a Web Service, you would most likely use clustering for any machines that the Web Service uses. You would not use clustering for the machines on which the Web Service lives. For example, if the Web Service uses a database, consider locating the database server on a clustered pair of servers. The Web Service itself could be placed in a Web farm where any request would be routed to one of many servers in the farm. You could use something like Windows Application Center Server to maintain all the machines in the Web farm. (Application Center has facilities that allow you to write a file to one server. Depending on how the server is configured, that change is replicated to other servers.)
Multiple Deployment Locations
If the Web Service is used by geographically dispersed locations and requirements for accessibility and redundancy are high, consider deploying the Web Service and related databases to more than one physical location. To keep the databases synchronized, you can use SQL Server's built-in replication and merge technologies. How would you write client applications to take advantage of this redundancy?
First off, you have to assume that the exact same setup will exist at each endpoint. The same Web Service is deployed at each location. Because of this, the same client code will be able to access any one of the endpoints. If the redundant endpoints were registered using either a private UDDI registry (such as what will be available with Windows .NET Server) or using one of the public registries, a client can locate an endpoint based on location. Private UDDI registries are typically hosted internally and are not accessible to external entities. Public registries, such as uddi.microsoft.com, allow you to make your endpoints known to the world.
UDDI allows you to categorize Web Services based on ISO 3166 Geographic Taxonomy and GeoWeb Geographic classification. Both methods let you specify the location using different granularity. To make use of this information, each client could be preloaded with a set of endpoints on a location-by-location basis. Individual clients could also be built to look for endpoints on a certain scale out basis. For example, a client could be told that it is in Spokane, Washington, United States, North America. To locate a preferred server, possibly at startup time, the client would look for Web Services located in Spokane. It would continue to increase the size of the geographical search until it located a working server.
In a best-case situation, the client would find the Web Service implementation closest to it. This provides for good response times. When the closest endpoint fails for whatever reasons, the client could contact UDDI and query for all tModels implementing the Web Service in Washington. The client would continue scaling out this way until it either found a functioning endpoint somewhere on the globe or all endpoints failed.
Multiple deployment locations facilitate availability by giving clients an alternative endpoint if a server or network link fails. If the link from the computer to the Internet is blocked, you are in trouble. However, if that link is functioning, the client should be able to find at least one endpoint that works. Multiple deployment locations also benefit performance by helping the client locate the closest endpoint. The less distance the message has to travel, the faster it will get from one end of the conversation to the other.
Reporting
Yes, reporting is a theme that you should be getting used to by now. Auditing has been discussed in Chapter 5, “Troubleshooting Web Services/Consumers” as a way to make your Web Service easier to debug and secure. Using that audit data, you can also collect information on how available the Web Service has been. This can help you decide how to make the Web Service more responsive.
For example, your test plan may have made sure that you can handle an average of five requests per second (that's 432,000 requests per day!). What do you do when you discover that that you are getting 200,000 requests per day but that 70 percent of the requests come through during a four hour period? That would translate into a rate of 9.7 requests per second—almost double what you tested for. Reporting would tell you one of two things: you did a really good job or that it is time to scale the system up. Reporting can also tell you what parts of the Web Service are the most popular. Optimizing those methods might allow you to service more users with less hardware, decreasing the chances that a user will have problems accessing the Web Service.
Administrator Communication
Again, you want to make sure that your administrators have ways of being notified when the Web Service and its hardware need attention. If the server hardware is monitored by software that can alert a person when something bad happens, you can respond to problems before your customers alert you. Servers can and do fail. By making it possible for administrators to respond in a timely manner, you reduce your downtime. Less downtime translates into better availability.