Previous Page
Next Page

Understanding the Internet as an Infrastructure

You have heard all the hype about the Internet, and so none of it will be repeated here. However, you should consider a few points. The Internet is a big network (alright—a really big network) and, as a result, the information and data that you can access over it can be quite remote. This should have an impact on the way you design your applications. For example, you might get away with locking data in a database while a user browses it in a small, local desktop application, but this strategy will not be feasible for an application accessed over the Internet. Resource use impacts scalability much more for the Internet than for local applications.

Network bandwidth itself is also a scarce resource that should be used sparingly. You might notice variations in the performance of your own local network according to the time of day (networks always seem to slow down on a Friday afternoon just when you are trying to get everything done before the weekend), the applications that users in your company are running, and many other factors. But, no matter how variable the performance of your own local network is, the Internet is far more unpredictable. You are dependent on any number of servers routing your requests from your Web browser to the site you are trying to access, and the replies can get passed back along an equally tortuous route. The network protocols and data presentation mechanisms that underpin the Internet reflect the fact that networks can be (and at times most certainly will be) unreliable and that an application running on a server can be accessed by a user running one of many different Web browsers on one of many different operating systems.

Understanding Web Server Requests and Responses

A user gaining access to an application over the Internet by using a Web browser uses the Hypertext Transfer Protocol (HTTP) to communicate with the application. Applications are usually hosted by some sort of Web server that reads HTTP requests and determines which application should be used to respond to the request. The term “application” in this sense is a very loose term—the Web server might invoke an executable program to perform an action, or it might process the request itself by using its own internal logic or other means. However the request is processed, the Web server will send a response to the client, again by using HTTP. The content of an HTTP response is usually presented as a Hypertext Markup Language (HTML) page; this is the language that most browsers understand and know how to display.

Applications run by users that access other applications over the Internet are often referred to as clients or client applications. The applications being accessed are usually called servers or server applications.
Managing State

HTTP is a connectionless protocol. This means that a request (or a response) is a stand-alone packet of data. A typical exchange between a client and an application running on a Web server might involve several requests. For example, the user can display a page, enter data, click some buttons, and expect the display to change as a result, allowing the user to enter more data, and so on. Each request sent by the client to the server is separate from any other requests sent both by this client and any other clients using the same server (and maybe running the same application) simultaneously. The problem is that a client request often requires some sort of context or state.

For example, consider the following common scenario. A Web application allows the user to browse goods for sale. The user might want to buy several items, placing each one in a virtual shopping cart. A useful feature of such an application is the ability to display the current contents of the shopping cart.

Where should the contents of the shopping cart (the client's state) be held? If this information is held on the Web server, the Web server must be able to piece together the different HTTP requests and determine which requests come from one client and which come from others. This is feasible, but might require additional processing to reconcile client requests against state information and, of course, it would require some sort of database to persist that state information between client requests. A complication with this technique is that the Web server has no guarantee; once the state information has been preserved, the client might submit another request that uses or removes the information. If the Web server saved every bit of state information for every client that used it, it could need a very big database indeed!

An alternative is to store state information on the client machine. The Cookie Protocol was developed to allow Web servers to cache information in cookies (small files) on the client computer. The disadvantages of this approach are that the application has to arrange for the data in the cookie to be transmitted over the Web as part of every HTTP request so that the Web server can access it. The application also has to ensure that cookies are of a limited size. Perhaps the most significant drawback of cookies is that users can disable them and prevent the Web browser from storing them on their computers, which will cause any attempt to save state information to fail.

Understanding ASP.NET

From the discussion in the previous section, you can see that a framework for building and running Web applications has a number of items that it should address. It must do the following:

Microsoft originally developed the Active Server Pages model in response to many of these issues. Active Server Pages allowed developers to embed application code in HTML pages. A Web server such as Internet Information Services (IIS) could execute the application code and use it to generate an HTML response. However, Active Server Pages did have its problems: you had to write a lot of application code to do relatively simple things, such as display a page of data from a database; mixing application code and HTML caused readability and maintenance issues; and performance was not always what it could be because Active Server Pages had to interpret application code in an HTML request every time the request was submitted, even if it was the same code each time.

With the advent of the .NET platform, Microsoft updated the Active Server Pages framework and created ASP.NET. The main features of ASP.NET include the following:

In the latest release of the .NET Framework supplied with Visual Studio 2005, Microsoft has further enhanced ASP.NET. A large number of improvements have been made to optimize throughput and Web site maintainability. Microsoft has also added the following features:

In the remainder of this chapter, you will learn more about the structure of an ASP.NET application.

Previous Page
Next Page