any real-world components manage their own state internally. In these situations, you can use the classes provided by .NET to help manage state. In this column, I'll show you how to create a Web Service that uses the two main classes that represent Web state information: the Application object and the Session object (see the sidebar, "Understand Application and Session State"). The samples all use C#. However, any .NET language will do, as the topics covered are .NET library-specific, not C#-specific.

Technology Toolbox: C#, ASP.NET

Take a look at the general architecture of a Web Service and how communication works between a client and a Web Service. In the simplest level of communication between a Web client and a Web Service, the Web client sends an HTTP request using either a GET or a POST command (see Figure 1). The Web Service responds with an XML file that contains the requested data structure.

One of the most compelling advantages to Web Services for networked components is the simplicity of deployment: Web Services use common standard protocols. The requests and responses both use HTTP, and the Web Service encodes the data either as HTTP Request parameters or in an XML file. This reliance on HTTP is a great advantage because most firewalls are configured so HTTP traffic passes through them fairly easily. Other network programming protocols such as CORBA, Distributed COM (DCOM), and sockets involve compromising the firewall integrity to allow the requested traffic.

	Figure 1 | How Web Services Communication Works. Click here.

However, relying on HTTP also introduces some programmatic difficulty when it comes to implementing state with Web Services. HTTP is a stateless protocol. At HTTP's inception, its requests and responses didn't need to be concerned with the particular client at the other end. But as the Web got bigger and developers created more powerful applications for it, Web servers started adding features that made stateful Web applications easier to develop. Those same features enable you to create stateful Web Services using .NET.

Load and Call a Web Service
Revisit the simplified drawing in Figure 1. The Web server takes several steps to return that XML file. First, the Web server loads the requested ASMX file and parses the code-behind attribute. Then the Web server creates a new instance of the class described in the code-behind attribute. Next, the Web server invokes the requested method of the object to return the XML file. Finally, the Web server releases the object.

The key point is this: The Web server creates a new instance of the object for every request that comes in. You need to find a way to store state in some other form. You'll make a simple Web Service to demonstrate this fact by adding code to the Web Service to work with the other state information.

Start Visual Studio .NET and select File | New | Project. Select a C# Web Service and name the new service WebStates. Install it at http://localhost/WebStates, then make three quick changes to the code that AppWizard created. First, add a private static variable to keep track of how many copies of this class are created. Initialize it to zero:

private static int numCreated=0;

Next, increment this counter in the constructor for the Web Service:

public WebService1()
{
   InitializeComponent();
   ++numCreated;
}

Finally, add a Web method to retrieve the number of WebService1 objects that are created:

[WebMethod]
public int HowMany ()
{
   return numCreated;
}

Compile and run the application. Every time you invoke the HowMany Web method, the counter gets incrementedeven in the same session, from the same user, or from the same machine. However, if you run the application using the debugger, each debugging session starts a new version of the counter and the number created starts again at 1.

Figure 2 | Web Services State Architecture. Click here.

The Application object is a global object that every request in an ASP.NET application shares. There's one limitation: Application state isn't shared across Web farms (multiple Web servers hosting one application) or Web gardens (multiple processors in the same machine hosting one application).

Go back to the Web Services architecture one more time to understand how this works (see a simplified memory layout in Figure 2). Your Web Service runs as part of the Internet Information Server (IIS) process. Look at the Global.cs file that Visual Studio .NET creates; you see code to handle the start and end of the application context. You also see methods to handle the start and end of a session and a request. You might be tempted to add information here to manage state, but that's more work than you need to do.

IIS creates an application context the first time any user requests any pages from your Web application (either a Web Service or a Web forms app). This application context lives until you stop or restart IIS. Note that stopping the web isn't enough; you need to restart the entire IIS process. You can use IIS' collection of properties in the application context to add your own application-wide context.

Keep Track of Statistics

In this Article
Introduction	Increment the Number of Calls
Keep Track of Statistics