Tài liệu Understanding the Internet as an Infrastructure docx

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. NOTE 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: • Support the standard HTTP • Manage client state efficiently • Provide tools allowing for the easy development of Web applications • Generate applications that can be accessed from any browser that supports HTML • Be responsive and scalable 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: • A rationalized program model using Web forms that contain presentation logic and code files that separate out the business logic. You can write code in any of the supported .NET languages, including C#. ASP.NET Web forms are compiled and cached on the Web server to improve performance. • Server controls that support server-side events but are rendered as HTML to allow them to operate correctly in any HTML-compliant browser. Microsoft has also extended many of the standard HTML controls as well, allowing you to manipulate them in your code. • Powerful Data controls for displaying, editing, and maintaining data from a database. • Options for caching client state using cookies on the client's computer, in a special service (the ASP.NET State service) on the Web server, or in a Microsoft SQL Server database. The cache is easily programmable by using code. 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: • Enhanced page design and layout using Master Pages, Themes, and Web Parts. You can use Master Pages to quickly provide a common layout for all Web pages in an application. Themes help you implement a consistent look and feel across the Web site, ensuring that all controls appear in the same way if required. Web Parts enable you to create modular Web pages that users can customize to their own requirements. You will use Themes later in this chapter. Using Master Pages and Web Parts are outside the scope of this book, however. • New data source controls for binding data to Web pages. These new controls allow you to build applications that can display and edit data quickly and easily. The data source controls can operate with a variety of data sources, such as Microsoft SQL Server, Microsoft Access, XML files, Web services, and business objects that can return data sets. Using the data source controls provides you with a consistent mechanism for working with data, independent from the source of that data. You will make use of the data source controls in Chapter 27, “Securing a Web Site and Accessing Data with Web Forms.” • New and updated controls. For displaying and editing data Microsoft now provides the GridView, DetailsView, and FormView controls. You can use the TreeView control to display hierarchical data, and you can use the SiteMapPath and Menu controls to assist in user navigation through your Web application. You will use the GridView control in Chapter 27. • Enhanced security features with built-in support for authenticating and authorizing users. You can easily grant permissions to users to allow them to access your Web application, validate users when they attempt to log in, and query user information so you know who is accessing your Web site. You can use the Login control to prompt the user for their credentials and validate them, and the PasswordRecovery control for helping users remember or reset their password. You will use these security controls in Chapter 27. • Improved Web site configuration and management using the ASP.NET Web Site Administration Tool. This tool provides wizards for configuring and securing ASP.NET Web applications. You will use the ASP.NET Web Site Administration Tool in Chapter 27. In the remainder of this chapter, you will learn more about the structure of an ASP.NET application.   . Understanding the Internet as an Infrastructure You have heard all the hype about the Internet, and so none of it will be repeated. 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