Chapter 3: ASP.NET


Interdependence absolute, foreseen, ordained, decreed,
To work, Ye’ll note, at any tilt an’ every rate o’ speed.
Fra skylight-lift to furnace-bars, backed, bolted, braced an’ stayed,
An’ singin’ like the Mornin’ Stars for joy that they are made;

—Rudyard Kipling, writing on interoperation
and scalability, “McAndrew’s Hymn,” 1894.

Problem Background

The Web was first used to deliver static pages of text and pictures. Programming a server to do this was relatively easy—just accept the URL identifying the file, fetch the file that it names from the server’s disk, and write that file back to the client, as shown in Figure 3-1. You can do a lot with just this simple architecture. For example, my local art cinema has a small Web site that I can browse to see what’s playing tonight (for example, Happy, Texas, in which two escaped convicts are mistaken for beauty pageant organizers in a small Texas town), learn about coming attractions, and follow links to trailers and reviews. They’re using the Web like a paper brochure, except with richer content, faster delivery, and lower marginal cost—in a word, lower friction. (OK, two words, I was off by one.)[1]

The Web was initially used for viewing static pages, which was relatively easy to program.

click to expand
Figure 3-1: Server delivering static Web pages.

This approach worked well in the prehistoric days when all data on the Web was static (rendering the author’s content verbatim, with no user input or programming logic) and public (available to anyone who knew or could find the magic address). But customers soon started asking, “If I can see what movie’s playing tonight, why can’t I see my current bank balance?” which the static page approach can’t handle. A bank can’t create a new page every day for every possible view of every account—there are far too many of them. Instead, the user needs to provide input such as the account number, and the bank’s computer needs to create on demand an HTML page showing the user’s account balance, as shown in Figure 3-2. This data is neither static nor public, which raises thorny new design problems

Web programmers today need to dynamically generate HTML pages in response to input received from the user, which poses new problems.

click to expand
Figure 3-2: Server dynamically generating Web pages based on client input.

A Web server application that dynamically generates pages for a client needs several things. First, it needs a way of associating some sort of program logic with a page request. When a user requests a page, the server doesn’t simply fetch the page from the disk; the page doesn’t exist before the request. Instead, the server executes program logic that generates the page. In the bank example, we probably need to do a database lookup in the bank’s central ledger to find out the customer’s current balance and recent transactions. We’d like to be able to write this logic quickly and easily, using languages and tools with which we are already familiar. And we’d like it to run as quickly and efficiently as possible in production.

Our Web server application requires program logic that generates pages.

Second, our Web server needs a way to get input from the user into the server-side program logic and output from that program logic back to the user. The user’s browser submits to the server an HTML form, whose input controls specify the data that he’d like to see on his page—for example, his account number and the range of dates for which he wants to see transactions. Parsing the interesting data values from this HTML is tedious and highly repetitive, so we’d like a prefabricated way of doing it that’s quick and easy for us to program. Think how much easier the text box (edit control for you C++ geeks) makes reading character input in a Windows user interface compared to assembling character strings yourself from individual keystrokes. We’d also like a similar level of prefabrication in assembling the HTML page for output to the user. Raw HTML is difficult and tedious to write. Think how much easier the label control makes output in a Windows user interface compared to writing all the GDI calls needed to set font, color, text, and so on. We’d like something similar for the HTML output that a browser requires.

Our Web server needs a convenient way of receiving input from and writing output to the user’s browser.

Third, since at least some of our data is now private, our Web server needs to ensure that we know who a user is and that we only allow the user to see and do the things that he’s allowed to. You’d like to see your bank account, but you really don’t want your disgruntled former spouse looking at it, or, far worse, moving money out of it. This type of code is notoriously difficult and expensive to write—and proving to your wary customers that you’ve made the code bulletproof, so that they have the confidence to use it, is equally difficult and expensive. We need a prefabricated infrastructure that provides these security services to us.

Our Web server needs security services to keep unauthorized users from seeing or doing things that they shouldn’t.

Finally, our Web server needs a mechanism for managing user sessions. A user doesn’t think of her interaction with a Web site in terms of individual page requests. Instead, she thinks of it in terms of a conversation, a “session,” that takes place with multiple pages on your site over some reasonable amount of time. She expects the Web site to be able to remember things that she’s told it a few minutes previously. For example, a user expects to be able to place items in an e commerce site’s shopping cart and have the cart remember these items until check out. Individual page requests don’t inherently do this; we have to write the code ourselves to make it happen. Again, it’s an integral part of most Web applications, so we’d like a prefabricated implementation of it that’s easy to use. Ideally, it would work correctly in a multi-server environment and survive crashes.

Our Web server needs a way to manage user sessions.

In short, our Web server needs a run-time environment that provides prefabricated solutions to the programming problems common to all Web servers. We’d like it to be easy to program as well as to administer and deploy. We’d like it to scale to at least a few servers, ideally more. And we don’t want to pay a lot for it. Not asking for much, are we?

We need an entire Web server programming and run-time environment.

[1]One of the smartest, albeit geekiest, guys I know once said that there’s only one bug in all of com puting, and it’s being “off by one.” “Can’t you be off by 25,000?” I asked him. “You’ve got to be off by one first,” he replied.




Introducing Microsoft. NET
Introducing Microsoft .NET (Pro-Developer)
ISBN: 0735619182
EAN: 2147483647
Year: 2003
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net