A Multi-tier Architecture is a software architecture in which different software components, organized in tiers/layers, provide dedicated functionality. The most common occurrence of multi-tier architecture is a three-tier architecture consisting of a data management tier, an application tier sometime called business logic, and a client tier. Conceptually, a multi-tier architecture results from a repeated application of the client/server paradigm. A component in one of the middle tiers is a client to the next lower tier and at the same time acts as a server to the next higher tier.
In computing, a client is a piece of computer hardware or software that accesses a service made available by a server as part of the client/server model of computer networks. The server is often but not always on another computer system, in which case the client accesses the service by way of a network. A client can be any device like a computer, tablet, or mobile. Therefore, a Client-server denotes a relationship between cooperating programs in an application, composed of clients initiating requests for services and servers providing that function or service.
Early software systems were constructed in a monolithic manner. This indicates that a single specialized software component handles all the many processes necessary to implement a certain application and show the results to a user. Since client/server systems first appeared in the 1980s, many jobs have been able to be divided and possibly spread over network borders. In a client/server architecture, the client is in charge of providing the user with the program, and the server is in charge of managing data. There are now two options for the delivery of business logic. First, in so-called fat client/thin server systems, in addition to presentation and user interfaces, the client also supplies business logic. This can be accomplished by employing SQL against the underlying database server in the client application software, either by embedding SQL into a more complex programming language or by using the call-level interface of the database server (e.g., JDBC, ODBC).
The database server also provides business logic in thin client/fat server designs, whereas the client just concentrates on presentational issues. Using persistent stored modules or stored procedures on the database server, fat servers can be created. Despite being the most prevalent type of client/server system, fat client architectures provide several difficulties when it comes to distributing new client versions across big deployments in the context of growing business logic. A fat client architecture also frequently results in a high network load because all data processing occurs at the client. A single point of failure and potential performance bottleneck is imposed by fat servers, though. Thus, three-tier architectures represent the next development of client/server architectures where the burden of supplying business logic is removed from the client and database server. Between the client and database server, an application layer or business tier takes over this function. Additional tiers are incorporated in multi-tier designs, such as a web tier between the client and application layers.
The structure of a software application that is separated into several tiers is referred to as N-tier architecture. A layer is a division of the application that performs a certain set of functions, whereas a tier is a layer of the application that runs on its infrastructure or server. There is no restriction on the number of tiers that can be used in an N-tier architecture because the “N” in the name stands for an undefined number. Having said that, a software application frequently has three layers. The presentation layer, application layer, and data layer are some examples of these, though there may be fewer or more. Together, these layers create a finished application. However, each layer also works independently of the others in an N-tier application.
Infrastructure as a Service, or IaaS, is a type of cloud computing that provides computer resources and services via the internet on a pay-as-you-go basis. N-tier architecture is frequently the choice. IaaS models depend on customers having dependable access to servers, and N-tier design enables more dependable service availability. Because there is only one server, for instance, in a one-tier system, the program would become inoperable if the server failed. An N-tier system would still be working even with just one server failing because the other servers would still be running.
The architectural paradigm used by multi-tier systems is based on the separation of concerns. The architecture takes into account vertical functionality breakdown into a stack of specialized software layers. A client/server method of interaction is used between each pair of subsequent layers, where the lower layer serves the next higher layer. The data management, business, and client tiers are examples of typical layers in a three-tier design. Multi-tier architectures take into account extra layers, such as a web tier that sits between the client tier and application tier and houses servlet containers and a web server. Multi-tier designs frequently use horizontal distribution within tiers in addition to vertical breakdown and distribution across tiers. This permits the use of multiple distributed database servers for the data management tier. The business tier, which offers multiple application server instances, is where horizontal distribution is typically used. Each tier of multi-tier applications can be deployed on a variety of heterogeneous and distributed platforms, which is their main advantage. Distributing requests among the various application server instances enables load balancing within tiers, particularly for the application tier. A dispatcher that accepts calls from the layer above it and distributes them appropriately can carry out this. Multi-tier architectures must support transactional interactions when used in a business setting. Distributed transactions are required because software components are naturally distributed across layers and possibly even within layers. Typically, a two-phase commit protocol (2PC) is used to implement this. This can be accomplished, for example, through the CORBA OTS, the Java Transaction Service JTS, etc., depending on the application server and middleware being used. The layered architecture, where transactions at one layer are implemented by using services and operations of the next lower layer, is not taken into account by 2PC, even though it supports atomicity in distributed transactions. Transactions on multiple levels consider this structure. For instance, SAP ERP implements multi-level transactions by taking into account both the application server and data management tiers simultaneously. Message-oriented middleware (MOM) is necessary for asynchronous interactions between components in a multi-tier architecture. Persistent queues and queued transactions in this situation can support transactional semantics in ascending order such as replication, materialized views, etc. can be applied outside the DBMS.
Due to the proliferation of both commercial and open-source application servers, multi-tier architectures can be found in a very large variety of different domains. Applications include but are not limited to, distributed information systems, Web information systems, e-Commerce, etc.
The Transaction Processing Performance Council (TPC) has defined a benchmark, TPC-App, for evaluating the business tier and in particular the performance of application servers in a three- or multi-tier architecture. It includes Web Service interactions, distributed transactions, asynchronous interactions via message-oriented middleware reliable messaging, and persistent queues.
The multi-tier architecture is a widely used design pattern for building complex applications. It offers many benefits, including scalability, maintainability, and security. However, it also presents some challenges, such as complexity and performance issues. Developers must carefully consider the trade-offs and design an architecture that meets the specific needs of their application.
