The loosely coupled architecture of XML-based Web services is the centerpiece of Microsoft's .NET platform. In the .NET world, applications consist of linked tiers of SOAP-accessible services. Some systems will publish Web services, while others consume them. In fact, many servers may be simultaneously publishing and subscribing to Web services, as XML-formatted data and SOAP requests form the backbone of widely distributed applications. Over time, an enterprise's computing infrastructure may evolve into a complex mesh of systems, each communicating via Web services—and increasingly relying upon the availability of those Web services publishers.

This is a tremendous vision, and it offers developers much greater simplicity and flexibility during the development process than other distributed architectures that use dedicated message queues, middleware buses, or application connectors. But in today's early incarnation of Web services, what's missing is the high availability that the message queues and legacy middleware systems offered. With Web services and .NET, communication is essentially between one SOAP requestor and one SOAP listener, typically over an IP network.

That's fine, when everything works correctly. But what if everything's not working right?

For example, under ordinary circumstances, there is no guaranteed delivery of SOAP messages or guaranteed response time to a Web services request. If the SOAP listener isn't listening (due to a hardware, software or network malfunction), or if it is overloaded and cannot respond to a request in a timely manner, the requestor's application might fail or experience unacceptable performance degradation. While a "404 Not Found" might be annoying for a consumer browsing a favorite news site, the Web services equivalent could have severe repercussions for enterprise infrastructure applications.

That's the bad news. The good news is that developers and systems administrators can add high-availability features, including fail-over and load balancing, to Web Services-oriented .NET applications, or choose messaging methods that offer more reliability than SOAP for mission-critical Web services.

Some of those approaches, such as clustering and network load balancing, improve the reliability of a system through redundancy. Others, such as Microsoft's new Global XML Web Services Architecture (GXA) and Microsoft Message Queuing (MSMQ), improve application availability through a robust middleware implementation. Let's start by looking at the network-oriented techniques.

Server Clustering: Improving Reliability
One of the most significant aspects of .NET's XML-based Web services is its reliance upon standard networking technologies, particularly IP and HTTP. Specifically, in most cases a SOAP query is made against a machine residing at a specific IP address or fully qualified domain address. The Web service request isn't sent to a specific server identified by its MAC address, NetBEUI names, or unique identity in ActiveDirectory. In that respect, Web services are just like HTTP-based browser services over TCP/IP Port 80. The benefit: Web services can be clustered for high availability, just like any other Port-80 application, such as HTML serving.

A server cluster consists of two or more independent servers, physically networked together, that appear to be a single server. Each server understands the application state of the other servers in the cluster. When one server fails, the workload is automatically shifted to another server in the cluster, with minimal downtime. The individual machines in a server cluster might be set up within a single machine room, to accommodate a software crash, or geographically dispersed as part of a disaster recovery and survivability scenario. Servers in a cluster might also be strategically located within a multi-site enterprise to improve application response time.

Microsoft Cluster Service connects two or more servers, such as those at the bottom of the figure, to improve reliability. The cluster uses shared storage for common data and to maintain application state. Source: Microsoft Corp.

Perhaps the easiest solution for clustering under Windows and .NET is through the use of Microsoft Cluster Server. Currently, this solution is only available for Windows 2000 Advanced Server (allowing two servers per cluster) and Windows 2000 Datacenter Server (allowing up to four servers per cluster). The forthcoming Windows .NET Server, currently expected to be available by the end of 2002, will offer equivalent functionality. For more details, see http://www.microsoft.com/windows2000/technologies/clustering/ for an overview of Windows Cluster Server, and http://www.microsoft.com/windows.netserver/evaluation/overview/technologies/clustering.mspx for a look at what's coming in Windows .NET Server in this regard.

Network Load Balancing: Improving Some Reliability, Plus Scalability
When the absolute fail-over considerations of a server cluster are not required, network load balancing can be a simpler solution to implement. A network load balancer not only improves application reliability, but also can drastically improve scalability, because as many as 32 servers can be involved in a single Windows-based load-balanced scenario.

Microsoft's network load balancing software, which is part of the TCP/IP stack within Windows 2000 Advanced Server and Windows 2000 Datacenter Server, assigns each server a private IP address; the entire load-balanced solution shares a common virtual IP address—thus, the entire solution appears to clients as a single virtual server that receives and replies to SOAP queries or other network requests.

A four-server cluster works as a single virtual server. Each of the load-balanced servers communicates with the others via TCP/IP. Source: Microsoft Corp.

How does network load balancing work? One server in the load-balanced system acts as the host: it listens for service requests sent to that common virtual IP address, and assigns them to other members of the network load-balanced solution based on policies set by the systems administrator. This arrangement provides the scalability. High availability is gained because if the load-balancer host detects that another load-balanced server has failed, it simply stops directing traffic to it, at least until the misbehaving server goes back on-line. Also, if the host itself stops running, another server in the load-balancing solution takes over its duties. This ensures that there's no single point of failure.

Anyone using or considering the use of clustering or network load balancing should consider the use of Microsoft's Application Center 2000 administrative console. Unlike Microsoft Management Console, built into Windows 2000 Server, AppCenter provides tools for deploying and managing applications across multiple servers, and can vastly simplify the task of creating the cluster or load-balanced solution, as well as keeping the servers' software in sync. It also has the tools needed to monitor the system's health. Currently, Microsoft has priced AppCenter at US$2,999 per processor, and a license must cover every server in the cluster or network load-balanced solution. Learn more here.

While network load balancing may sound very similar to the clustering solution, there are two main differences. First, there is no fail-over of any in-process transactions between servers in a network load-balanced configuration. So, if one server crashes or becomes unavailable due to a network fault, its transactions won't be completed—they will have to be resubmitted by client applications across the network.

Second, there is no direct sharing of information between the load-balanced servers, or persistent connections between the servers and their clients. Therefore, server applications, such as .NET-based Web services, must truly adhere to the loosely coupled philosophy of SOAP, WSDL, and XML. Of course, if the Web services are hard-wired to rely upon application data or software installed on only one server, it is impossible to set up a load-balanced solution. Similarly, if the Web service is involved in multi-stage transactions, some care must be given to ensure that application information is not resident within only a single server. Instead, there should be a separate repository, such as a machine running Microsoft's SQL Server.

In other words, design for network load balancing must be taken into account during the application and Web services architecture stage.

Network load balancing is built into Windows 2000 Advanced Server and Windows 2000 Datacenter Server, and will also be available in Windows .NET Server. For more information, see http://www.microsoft.com/windows2000/techinfo/howitworks/cluster/nlb.asp.

The Developer's Angle: Developing for High Availability
Assuming that an application is properly architected, both clustering and network load balancing are straightforward technologies that administrators can use to improve application availability. However, not all application deployments lend themselves to these solutions. And even when those technologies are in use, it's still important to develop .NET applications that are intrinsically stable and secure.

As mentioned previously, SOAP-based XML Web services generally use IP and HTTP as the transport protocol. Unfortunately, IP and HTTP are not always reliable, and delivery is non-deterministic. There's no guaranteed message delivery, or even a return-receipt mechanism that a client application can use to test for delivery. All that client applications can do is send out the SOAP message or other request for service and hope for the best. More specifically, if the SOAP request is not answered in an appropriate amount of time, the application needs to realize that the server is down and take appropriate action, such as canceling the current operation (better than crashing, but definitely a sub-optimal solution), waiting some interval before retrying (the most common approach) or finding a second source for the Web service (assuming one exists in the UDDI registry).

Microsoft is trying to come up with better answers, and its latest idea is called GXA, or Global XML Web Services Architecture. (See "Web Services Specifications".) GXA extends XML, SOAP and WSDL. For the most part, these extensions were jointly developed by Microsoft in conjunction with IBM.

Arguably the most important component within GXA is the WS-Routing specification, which is an extension to SOAP that enables messages to include a request/response mechanism. While WS-Routing doesn't solve the whole problem of reliable messaging, it makes it easier for developers to build home-grown message-reliability features into their applications. Anyone building XML-based Web services today on .NET should investigate this protocol extension.

Recently, Microsoft released a developer's kit that provides an implementation of WS-Routing, as well as other SOAP extensions for security and binary attachments. Learn more about the Web Services Development Kit for .NET at http://msdn.microsoft.com/webservices/building/wsdk/default.asp.

Message Queuing Instead of Soap
In cases where messaging reliability is paramount, a solution might be to use message queuing infrastructure, such as MSMQ (Microsoft Message Queuing) instead of SOAP. MSMQ presents a more tightly coupled middleware infrastructure, which can be accessed via COM and COM+ components. MSMQ goes far beyond SOAP, or even WS-Routing, by providing applications with message journaling, delivery notification, process notification, built-in data integrity, data encryption, and a mechanism for specifying message priority. MSMQ also supports one-to-many message broadcasting.

All versions of Windows 2000 include MSMQ 2.0. Windows XP and Windows .NET Server include MSMQ 3.0, which allows XML-formatted messages using SRMP, or the SOAP Reliable Messaging Protocol—so far, this Microsoft-specific extension to SOAP is only available through MSMQ. You can access MSMQ functionality through Visual Studio .NET, IIS, and ASP/ASP.NET. Microsoft has a white paper on MSMQ 3.0 that is downloadable from the home page for MSMQ.

It's All in the Design
Applications built with .NET can be made reliable and robust through good programming practices as well as through the use of server technologies such as clustering and network load balancing. While XML-based Web services, as seen in .NET, currently lack high-availability features through the HTTP transport and SOAP protocol, there are techniques that developers can use—such as using WS-Routing or MSMQ—to improve the reliability of messaging within a .NET system.

For more ideas about good software design for .NET, see Microsoft's .NET Architecture Center, at http://msdn.microsoft.com/architecture/.