3-Tier Architecture

3-Tier Architecture Screen Shot1

ADL applications utilize the 3-Tier Architecture model.

Three-tier Architecture is a client–server architecture where the user interface, functional process logic (“business rules”), computer data storage and data access are developed and maintained as independent modules.

Improving on the usual advantages of modular software, Three-Tier architecture  allows any of the three tiers to be upgraded or replaced independently in response to changes in requirements or technology. For example, changing the operating system in the Presentation Tier would only affect the user interface code.

Three-tier architecture has the following three tiers:

Presentation Tier

This is the topmost level of the application. The Presentation Tier displays information related to such services as Order Entry and Accounting applications. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network. (In simple terms it’s a layer which users can access directly via a mechanism such as a web page, or an operating systems GUI.)

Application or Logical Tier

The Application Tier (middle tier) controls the business logic and  processes based on Service calls from the Presentation Tier (User Interface).

The Application Tier is separate from the presentation tier and, as its own layer, controls an application’s functionality by performing detailed processing.

Database Access Tier

This tier consists of database servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers and business logic. Giving data its own tier also improves scalability and performance.

3 Tier Architecture Rules

The code for each layer must be contained with separate files which can be maintained separately.
Each layer may only contain code which belongs in that layer. Thus business logic can only reside in the Business layer, presentation logic in the Presentation layer, and data access logic in the Data Access layer.

Each layer should be totally unaware of the inner workings of the other layers. The Business layer, for example, must be database-agnostic and not know or care about the inner workings of the Data Access layer. It must also be presentation-agnostic and not know or care how its data will be handled. It should not process its data differently based on what the receiving component will do with that data. The presentation layer may take the data and construct an HTML document, a PDF document, a CSV file, or process it in some other way, but that should be totally irrelevant to the Business layer.

The Presentation layer can only receive requests from, and return responses to, an outside agent. This is usually a person, but may be another piece of software.

The Presentation layer can only send requests to, and receive responses from, the Business layer. It cannot have direct access to either the database or the Data Access layer.
The Business layer can only receive requests from, and return response to, the Presentation layer.

The Business layer can only send requests to, and receive responses from, the Data Access layer. It cannot access the database directly.

The Data Access layer can only receive requests from, and return responses to, the Business layer. It cannot issue requests to anything other than the DBMS which it supports.

Benefits
  • Client-Server Model
  • Database-Centric Architecture
  • Front-end and Back-end
  • Hierarchical Internetworking Model
  • Open Services Architecture
  • Rich Internet Application
  • Service Layer
  • Web Application
  • Load Balancing (Computing)
  • Multilayered Architecture