Table of Contents
Contains 6 titles:
TCP/IP Core Networking Guide
Deployment Planning Guide
Distributed Systems Guide
Internetworking Guide
Internet Information Services Resource Guide
Internet Explorer Resource Kit
Read an Excerpt
Chapter 6: Developing Web Applications from the Internet Information Services Resource Guide
The adoption of Internet standards coupled with the immense popularity of the Web have changed the architecture of distributed computing. The multilayered nature of the Web is an ideal environment for the development of component-based applications. They can be developed and customized quickly, with advanced system services such as database access and transaction processing. System resources can be managed and administered remotely. Moreover, new applications are available immediately, without requiring anything more than a browser on the user's system.
This section examines the opportunities that the Web provides for distributed application development, and demonstrates how to use Internet Information Services (IIS) 5.0 to develop the n-tier (also called multitier) Web applications of the future. In the process, the section will introduce client-based and server-based technologies that Microsoft has developed to implement this new breed of Web applications. The section assumes the reader is familiar with software development concepts.
Building on Client/Server
Market analysts have noticed a trend toward developing multitier applications that are distributed over Internet-standard networks, and predict rapid growth in these distributed systems in the coming years. Some predict that, by 2005, the familiar architecture of client/server applications will be replaced by "super-suites" of interconnected components, operating in frameworks of widely-available distributed systems. In other words, applications will be assembled from reusable building blocks, by using a variety of cooperating subsystems.
Before delving into the implementation details of building Web applications, it might be helpful to take a brief look at the architecture of the Web from a historical perspective, beginning with the traditional client/server architecture.
Client/Server Revisited
Cooperating and communicating applications have typically been categorized as either client or server applications. While the client application requests services using Microsoftr Distributed Component Object Model (DCOM) or remote procedure calls (RPCs), the server application responds to client requests. Traditional client/server interactions, shown in the figure below, are often data-centric and combine most (if not all) of the processing (or business) logic and user interface within the client application. The server's task is simply to process requests for data storage and retrieval.
Client/server (two-tier) applications have usually performed many of the functions of stand-alone systems; that is, they present a user interface, gather and process user input, perform the requested processing, and report the status of the request. Because servers only provide access to the data, the client uses its local resources to process it. Out of necessity, the client application can tell where the data resides and how it is laid out in the database. Once the server transmits the data, the client is responsible for formatting and displaying it to the user.
The primary advantage of two-tier applications over monolithic, single-tier applications is that they give multiple users access to the same data simultaneously, thereby creating a kind of interprocess communication. Updates from one computer are instantly available to all computers that have access to the server.
However, the server must trust clients to modify data appropriately—unless data integrity rules are used, there is no protection against errors in client logic. Furthermore, client/server connections are hard to manage—the server is forced to open one connection per client. Finally, because much of the business logic is spread throughout a suite of client applications, changes in business processes usually lead to expensive and time-consuming alterations to source code.
Although two-tier design still continues to drive many small-scale business applications, an increasing need for faster and more reliable data access, coupled with decreasing development time lines, has persuaded system developers to seek out a new distributed application design.
Multi-Tier Design
The new system design logically divides computing tasks across the application. Viewed from a purely functional standpoint, most applications perform the following three main tasks: gathering user input, storing the input as data, and manipulating the data as dictated by established operational procedures. These tasks can be grouped into three or more tiers, which is why the new system design provides for three-tier, or multitier applications. The application tiers, shown in the figure below, are:
- Client Tier The user interface or presentation layer. Through this topmost layer, the user can input data, view the results of requests, and interact with the underlying system. On the Web, the browser performs these user interface functions. In nonWebbased applications, the client tier is a stand-alone, compiled front-end application.
- Middle Tier Components that encapsulate an organization’s business logic. These processing rules closely mimic everyday business tasks, and can be single-task-oriented, or part of a more elaborate series of tasks in a business workflow. In a Web application, the middle tier might consist of Microsoft® Component Object Model (COM) components registered as part of a transactional application or instantiated by a script in Active Server Pages (ASP).
- Third Tier A database management system (DBMS) such as a Microsoft® SQL Server™ database, an unstructured data store such as Microsoft® Exchange, or a transaction-processing mechanism such as Transaction Services or Message Queuing. A single application can enlist the services of one or more of these data providers...
Loading...