Three Tier Software Architectures

Note

Purpose and Origin

The three tier software architecture (a.k.a. three layer architectures) emerged in the 1990s to overcome the limitations of the two tier architecture (see Two Tier Software Architectures). The third tier (middle tier server) is between the user interface (client) and the data management (server) components. This middle tier provides process management where business logic and rules are executed and can accommodate hundreds of users (as compared to only 100 users with the two tier architecture) by providing functions such as queuing, application execution, and database staging. 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. For detailed information on three tier architectures see Schussel and Eckerson. Schussel provides a graphical history of the evolution of client/server architectures.

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

A three tier distributed client/server architecture (as shown in Figure ) includes a user system interface top tier where user services (such as session, text input, dialog, and display management) reside.

Figure : Three tier distributed client/server architecture depiction

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.

In addition, the middle process management tier controls transactions and asynchronous queuing to ensure reliable completion of transactions. 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.

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.

Usage Considerations

Three tier architectures are used in commercial and military distributed client/server environments in which shared resources, such as heterogeneous databases and processing rules, are required. The three tier architecture will support hundreds of users, making it more scalable than the two tier architecture (see Two Tier Software Architectures).

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.

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 and Message-Oriented Middleware. The benefit is that three tier architectures hide the complexity of deploying and supporting underlying services and network communications.

Maturity

Three tier architectures have been used successfully since the early 1990s on thousands of systems of various types throughout the Department of Defense (DoD) and in commercial industry, where distributed information computing in a heterogeneous environment is required. An Air Force system that is evolving from a legacy architecture to a three tier architecture is Theater Battle Management Core System (TBMCS). Multi tier architectures have been widely and successfully applied in some of the biggest Internet servers.

Costs and Limitations

Building three tier architectures is complex work. Programming tools that support the design and deployment of three tier architectures do not yet provide all of the desired services needed to support a distributed computing environment.

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 :

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

Dependencies

Database management systems must conform to X/Open systems standards and XA Transaction protocols to ensure distributed database integrity when implementing a heterogeneous database two phase commit.

Alternatives

Two tier client server architectures (see Two Tier Software Architectures) are appropriate alternatives to the three tier architectures under the following circumstances:

• 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 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

Complementary technologies to three tier architectures are Object-Oriented Design (to implement decomposable applications), three tier client/server architecture tools, and Database Two Phase Commit processing.

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.