Page #21 (Chapter 2 - IIS Applications)

	Chapter 2 - IIS Applications
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Web Applications vs. Client-Server Applications

	Now that you've seen the ASP objects, let's explore a typical Web request. Figure 2.2 shows the entire ASP request cycle from client to server and back.

	Note		I've left out some facts and processes showing how the browser finds the server's IP address and how the Web server and the ASP engine communicate because these processes don't have any immediate bearing on Web application development.

	The actions shown in Figure 2.2 occur every time the browser sends a request, so there's a lot of work going on behind the scenes. You need to keep the request cycle in mind because it has a direct effect on how well your applications will work and how much of a load you will place on the network and the server. For example, suppose you store 2KB of information in a cookie and update some part of that cookie for each request. Those 2,048 bytes must travel to the server and back for each subsequent request. If you have 10 clients connected, you are responsible for 40KB of network traffic above and beyond the page content, form content, or QueryString variables for each page those clients request. If you have 100 clients, you've increased network traffic by 4MB for each page.

	I'm not advocating that you never use cookies—the problem is just as acute if you use QueryString or Form variables to maintain state. The point is, you want to minimize your application's footprint on the network and the server so that your application will respond quickly, scale easily, and be a good Net citizen.

	Although the ASP request cycle in Figure 2.2 looks similar to a standard client-server application request cycle, it is different in several ways.

	First, you need to firmly grasp that the Web server knows nothing about the browser client at the beginning of the request. It has to have the SessionID cookie to be able to look up any information stored on the server for that particular client. The Web server immediately forgets about the client's identity when the request has completed. In a standard client-server application, the server knows when clients attach or detach from the application.

	The entire application runs as a series of pages. You can control which pages a client can see and you can control the order of those pages, but you can't control the scope of a client's requests. In a standard client-server application, the application runs as a single entity.

	Second, the Web server can't initiate any activity on or communication with the client—the client has to request a page before the server can do anything. In a standard client-server application, the server can initiate actions on the client by sending messages or raising events.

	A lot of normally invisible or barely visible information flows back and forth for each request: headers, server (HTTP) variables, form contents, URL or QueryString parameters and values, and cookie values. You can take advantage of these values if you're aware of them. There's no need for all this invisible information in a standard client-server application because the connection doesn't disappear; therefore, after either the client or the server transfers information, it's there for the duration of the session.

	Third, after completing a request, you never know if or when the client will return. If the client does return, you can't control which page it will request next. You can't guarantee that any IDs you send to the client will be valid the next time the client requests a page, because you have no control over the time between requests. In a standard client-server application, you have some control over what happens next. In any case, you will know if the client disconnects. Because the server portion of the application has only a few entrance and exit points, you don't have problems with the client suddenly requesting unexpected pages.

	The point of all this is that you have to plan Web applications differently than you plan standard applications, because you have such little control over the client portion of the application.

	As an example, suppose you have built a series of three form pages that a user must fill out to complete a job application. The user completes the first page and posts it to the server. You store the page and return the next page. The second page has a Cancel button, but the user clicks the browser's Back button instead. What should you do? Redisplay the first form empty? Redisplay the first form filled in? Are you going to allow changes on the first page? Suppose the client had completed the form, then clicked back? Would you then allow the client to make changes? Suppose the client bookmarks page 2 of your form, then uses the bookmark a week later. You don't want to display page 2 first. For your application to work correctly, you'll need to plan for and solve all these potential problems.

	In contrast, in a standard client-server application, such problems rarely arise because clients don't have a Back button or a bookmarking capability unless you give it to them.

	In the next chapter, you'll get a chance to use the ASP objects by building an ASP application.