This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. Please see the patterns & practices guidance for the most current information.
Your are implementing a distributed solution using the Tiered Distribution pattern.
How many tiers should you have, and what should be in each tier?
The forces discussed in Tiered Distribution, apply to this pattern as well. For a discussion of those general forces, see Tiered Distribution. The following forces apply specifically to the Three-Tiered Distribution pattern:
The load on your database is significant enough that you want to dedicate a server (or entire cluster) to the database.
Your security policy mandates that corporate databases must not be hosted on servers that are directly connected to the Internet.
You have a large number of users who have their own computer or device for accessing the solution. For example, you have a Web application with a large number of users accessing a common application.
You must be able to scale the client tier to handle a significant increase in the number of users.
Your clients need to execute transactions against a shared database, and you want to share business logic across solutions.
The scalability requirements of the clients, application logic, and databases are significantly different.
Structure your application around three physical tiers: client, application, and database. Figure 1 shows this three-tiered distribution.
Figure 1: Three-tiered distribution
The client tier interacts with the users of the solution. If your application conforms to Three-Layered Services Application, this tier hosts the presentation layer components.
For Web applications, the client tier consists of the user workstations, PDAs, and other devices that host a Web browser. For service-oriented solutions, this tier consists of the computers and devices that consume the service.
Computers in the client tier are independent of each other and should not have hard-coded references to application tier resources; instead, they should use naming services such as Domain Name System (DNS), Lightweight Directory Access Protocol (LDAP), or Universal Description, Discovery, and Integration (UDDI) to find servers and services.
The number of computers in this tier can be quite large. Web applications essentially have an infinite number of computers in this tier. Solutions often need to scale up to handle a large increase in the number of users and their associated computers. The client tier does not impose any limit on the number of computers it contains, or how fast you can add computers. However, all the computers in the client tier must eventually interact with the application tier. The scalability of the application tier ultimately constrains the ability of the client tier to handle new users or increased workload per user.
The operating system and solution software on the client tier is configured and optimized for responsive user interaction and must provide the following two services at a minimum:
A mechanism for presenting the solution's user interface. For Web applications, this mechanism is a Web browser. For rich clients, it may be a custom UI framework, or may even be provided by the operating system.
The software infrastructure required to communicate with other tiers. An example for rich clients would be TCP/IP sockets. HTTP would provide this service for Web applications.
The client tier quite often exists in a separate security context from that of the other tiers, and individual computers within the tier are often in their own context. Many solutions must be able to adapt the security context of the client tier to the application tier.
The network infrastructure for Web-based enterprise applications is often based on a perimeter network (also known as DMZ, demilitarized zone, and screened subnet). The client tier is, by definition, on the public side of the perimeter network.
The servers in the application tier are responsible for hosting the application's business components and, in the case of Web applications, the Web servers as well. If your application conforms to Three-Layered Services Application, this tier hosts the business layer.
The computers in the application tier are servers, the configuration of which must balance between the conflicting resource requirements of an application server and a Web server.
Because application tier servers are Web servers, this tier often must contain multiple servers configured as a Server Farm to meet scalability and fault-tolerance operational requirements. As you add users to the client tier and the performance of the solution diminishes beyond acceptable parameters, you must add servers to the farm. For details concerning scalability and fault-tolerance characteristics of server farms, see Server Farm.
The servers in the application tier have both Web server and application server software installed. The application server software provides the execution context for the application logic. For an overview of the application server concept, see Application Server. For an example of the software infrastructure that this tier requires, see Implementing Application Server Using Windows Server 2003.
If your solution is a Web application, the server must be optimized for security and network connectivity. Otherwise, the server configuration should reflect the resource requirements of your business components and application server. Avoid hard-coding references to specific databases in the application. Use a configuration file, registry, or naming service to option references to the proper databases.
The servers in this tier usually reside within the same security context. Therefore they can interact with each other using a common security infrastructure.
If a perimeter network is used, the combined application and Web server is usually deployed in there. This has the adverse affect of increasing the exposure of sensitive business logic to the public Internet. Consider the Four-Tiered Distribution pattern if your security requirements dictate that sensitive business logic must be kept on the corporate side of the perimeter network.
The servers in the data tier host the databases that the solution requires. If your application conforms to the Three-Layered Services Application pattern, this tier hosts the data layer.
The computers in the data tier are sized and configured as enterprise servers. The servers are optimized for I/O throughput and hard-disk utilization. If the scalability and fault-tolerance operational requirements dictate that you have multiple servers in this tier, they are almost always configured as a server cluster. A server cluster is typically used in this case, because all the servers must manipulate a shared state (for example, the database), and because server-class computers have a very high limit on disk space and disk I/O capacity. For details concerning scalability and fault-tolerance characteristics of server clusters, see Server Clustering.
Data tier servers host database management systems such as Microsoft SQL Server 2000. Usually, reporting and data analysis software is also deployed on this tier. Database software that is specifically tuned for use in a clustered environment is required to maximize the benefit from a clustered server environment.
Because of the need to protect corporate data assets, the data tier often has the most stringent security requirements of all the tiers. Typically, access to these servers is limited to the application servers and database administrator workstations. For solutions with stringent security requirements, the data tier may be deployed on its own subnet on the network.
If a perimeter network is used, the data tier is almost always on the corporate side of the perimeter network. Some very security-conscious solutions even have a second perimeter network between the application and data tiers.
The Three-Tiered Distribution pattern results in a number of benefits and liabilities.
Using this pattern results in the following benefits:
Scalability and fault tolerance are strongly supported by configuring the application tier as a server farm and the database tier as a server cluster.
Separating the client computer from the application logic supports the development and distribution of thin-client applications.
Each tier can operate within its own security context.
Having the Web server and business components on the same computer, and quite often in the same process, increases performance.
The following liabilities offset the benefits of using Three-Tiered Distribution:
Business logic is directly exposed to the client tier, which can be a significant security risk for Web applications.
Hardware for supporting a Web server is significantly cheaper than hardware for supporting both a Web server and an application server. Therefore, the incremental cost of adding a new user is usually higher for this solution than for a solution where the Web servers are separated from the application servers.
For more information, see the following related patterns:
[PnP02] patterns & practices, Microsoft Corporation. "Application Architecture for .NET: Designing Applications and Services." MSDN Library. Available at:https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp.