Status

Note

Purpose and Origin

The three tier architecture is used when an effective distributed client/server design is needed that provides (when compared to the two tier) increased performance, flexibility, maintainability, reusability, and scalability, while hiding the complexity of distributed processing from the user. These characteristics have made three layer architectures a popular choice for Internet applications and net-centric information systems.

Technical Detail

Figure 28: Three tier distributed client/server architecture depiction [Louis 95]

The third tier provides database management functionality and is dedicated to data and file services that can be optimized without using any proprietary database management system languages. The data management component ensures that the data is consistent throughout the distributed environment through the use of features such as data locking, consistency, and replication. It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services.

The middle tier provides process management services (such as process development, process enactment, process monitoring, and process resourcing) that are shared by multiple applications.

The middle tier server (also referred to as the application server) improves performance, flexibility, maintainability, reusability, and scalability by centralizing process logic. Centralized process logic makes administration and change management easier by localizing system functionality so that changes must only be written once and placed on the middle tier server to be available throughout the systems. With other architectural designs, a change to a function (service) would need to be written into every application [Eckerson 95].

In addition, the middle process management tier controls transactions and asynchronous queuing to ensure reliable completion of transactions [Schussel 96]. The middle tier manages distributed database integrity by the two phase commit process (see Database Two Phase Commit). It provides access to resources based on names instead of locations, and thereby improves scalability and flexibility as system components are added or moved [Edelstein 95].

Sometimes, the middle tier is divided in two or more unit with different functions, in these cases the architecture is often referred as multi layer. This is the case, for example, of some Internet applications. These applications typically have light clients written in HTML and application servers written in C++ or Java, the gap between these two layers is too big to link them together. Instead, there is an intermediate layer (web server) implemented in a scripting language. This layer receives requests from the Internet clients and generates html using the services provided by the business layer. This additional layer provides further isolation between the application layout and the application logic.

It should be noted that recently, mainframes have been combined as servers in distributed architectures to provide massive storage and improve security (see Distributed/Collaborative Enterprise Architectures).

Usage Considerations

Three tier architectures facilitate software development because each tier can be built and executed on a separate platform, thus making it easier to organize the implementation. Also, three tier architectures readily allow different tiers to be developed in different languages, such as a graphical user interface language or light internet clients (HTML, applets) for the top tier; C, C++, SmallTalk, Basic, Ada 83, or Ada 95 for the middle tier; and SQL for much of the database tier [Edelstein 95].

Migrating a legacy system to a three tier architecture can be done in a manner that is low-risk and cost-effective. This is done by maintaining the old database and process management rules so that the old and new systems will run side by side until each application and data element or object is moved to the new design. This migration might require rebuilding legacy applications with new sets of tools and purchasing additional server platforms and service tools, such as transaction monitors (see Transaction Processing Monitor Technology) and Message-Oriented Middleware. The benefit is that three tier architectures hide the complexity of deploying and supporting underlying services and network communications.

Maturity

Costs and Limitations

A potential problem in designing three tier architectures is that separation of user interface logic, process management logic, and data logic is not always obvious. Some process management logic may appear on all three tiers. The placement of a particular function on a tier should be based on criteria such as the following [Edelstein 95]:

• ease of development and testing
• ease of administration
• scalability of servers
• performance (including both processing and network load)

Dependencies

Alternatives

• when the number of users is expect to be less than 100
• for non-real-time information processing in non-complex systems that requires minimal operator intervention

Distributed/collaborative enterprise computing (see Distributed/Collaborative Enterprise Architectures) is seen as a viable alternative, particularly if object-oriented technology on an enterprise-wide scale is desired. An enterprise-wide design is comprised of numerous smaller systems or subsystems.

Although three tier architecture has proven sound, the supporting products implementing the architecture are not as mature as other competing technologies. Transaction Monitors (TM) are a valid alternative when reliability and scalability requirements can not be fulfilled with existing multi layer technology. Although TMs don't support modern development paradigms like Object Orientation (OO) they are still quite useful when massive scalability and robustness is needed.

Complementary Technologies

For communication between potentially distributed layers some middleware is needed. This middleware can be a Remote Procedure Call (RPC) mechanism or a Message-Oriented Middleware (MOM), depending on whether synchronous or asynchronous communication is preferred.

The middle tier encapsulates business logic. Some of this logic is application specific but a significant percentage is organization or even domain wide. Domain Engineering and Domain Analysis can be used to capture this inter-application commonality and create a set of assets that can be effectively reused in different application.

It should be noted that recently, mainframes have been combined as servers in distributed architectures to provide massive storage and improve security (see Distributed/Collaborative Enterprise Architectures).

Index Categories

Name of technology	Three Tier Software Architectures
Application category	Client/Server (AP.2.1.2.1)
Quality measures category	Maintainability (QM.3.1) Scalability (QM.4.3) Reusability (QM.4.4) Reliability (QM.2.1.2)
Computing reviews category	Distributed Systems (C.2.4) Software Engineering Design (D.2.10)

References and Information Sources

Current Author/Maintainer

External Reviewers

Modifications

10 Jan 1997 (original)