Three Tier Software Architectures

In this tutorial, you will learn about three tire software architectures, purpose, history, technical details, three tier architecture usage considerations, maturity, costs and alternatives. 

The concept of Three Tier and multi tier architectures originated with the idea of Rational Software. Three Tier software is defined as client server architecture that feature the user interface, data storage, data access, and functional process logic maintained and developed as independent modules. Usually they are also located on different platforms. This architectural model is considered as both software design pattern and software architecture.

Besides the advantages that typically come with modular software with well defined interfaces, Three Tier systems are designed to allow any of its tiers to be upgraded or replaced without interfering with the other tiers or requiring a major change in technology. For instance, if one were to change their operating system to UNIX from Microsoft Windows, only the user interface code would be affected.

The user interface generally runs on a desktop computer, usually a PC, or a work station. It utilizes a normal graphical user interface. Its functional process logic might consist of one or several different modules running on a single application server or workstation. An RDBMS on a database server will contain the data storage logic. The center tier may itself be multi tiered – if this is the case, then the architecture is referred to as n-tier architecture.

Three Tier Architecture contains the following tiers or levels:

1. Presentation
2. Application/Logic/Business Logic/Transaction
3. Data

In the field of Web development, Three Tier is often employed in reference to web sites. In particular, Electronic commerce web sites are used in this system. This type of web site is usually built utilizing the following Three Tiers:

1. A front end web server, which serves static content
2. The middle level is typically an Application server. It might use, for example, a Java EE platform.
3. A back end Database, which will contain both the Database management system and the Data sets. This manages the data and provides access to it.

Three Tier Software Architectures Purpose and History

Three Tier Architecture emerged in the last decade as a means of overcoming two tier architecture limitations. The third tier was added as a middle tier between the data management server and the user interface.  This middle tier is a provider of process management. This is where business rules and logic are typically executed. Several hundred users can be accommodated under a Three Tier model, whereas in a two tier model only about a hundred users could be accommodated. Three Tier Architecture accomplishes this through such convenient functions as application execution, queuing, and database staging.

Three Tier Architecture is typically employed when a distributed client server design is necessary that will provide an increase in performance, scalability, flexibility, reusability, and maintainability. At the same time, the complexity of the distributed processing is concealed from the end user. As a result of these optimizations, Three Tier Architectures have been found to be convenient models for Internet applications, as well as information systems that rely on the World Wide Web in some way.

Three Tier Architecture Technical Details

In the diagram below, we can see a model of Three Tier client server architecture. As you can see, it contains a user system on the top tier. This is where such user services as text input, session, display management, and dialog are located.

• User System Interface
• Process Management
• Database management

 

The third tier contains database management functions. Its purpose is to optimize data and file services without having to result to the usage of proprietary database management system languages. This component makes sure that the data is consistent throughout the environment. In order to do so, it utilizes such features as data locking, replication, and consistency. The connectivity among tiers can be changed dynamically, but of course this depends on the user’s request for services and data.

The middle tier on the above model provides process management services which will be shared by multiple applications. These services may include process enactment, process resourcing, process development, and process monitoring. This tier also serves so as to improve performance. It is also called the application server. It improves scalability, reusability, flexibility, and maintainability via the centralization of process logic. This centralization makes change management and administration a lot simpler by localizing the functionality of the system so that changes only have to be written one time. They are then placed on the central tier and made available throughout the systems. With other architectural designs, it would be necessary to write the change in to each and every application.

The central process management tier also serves as a controller of asynchronous queuing and transactions. This thus ensures that transactions will be completed in a reliable fashion. The middle tier successfully manages to distribute database integrity through a commit process that occurs in two phases. Access to resources based on names, rather than locations, are provided. Thus, an improvement of flexibility and scalability results as the components of a system are either moved or added.

It sometimes happens that the central tier will be divided up in to several different units, each serving a different function. When this occurs, then the architecture will be referred to as multi layer. Many Internet applications operate in this fashion. When this occurs, the applications contain light clients that are written in HTML as well as application servers that are composed in either Java or C++. The gap between these two layers is too large for them to be linked together. So instead, an intermediate layer – or a web server – will then be implemented in to the scripting language. Requests from Internet clients are received on this layer, and HTML is subsequently generated utilizing the services situated on the business layer. The additional layer provides an additional level of isolation between the application logic and its layout.

Three Tier Architecture usage considerations

Three Tier Architectures tend to be employed in military and commercially distributed client server environments that necessitate the use of shared resources like processing rules and heterogeneous databases. Hundreds of users are supported by Three Tier Architecture, which makes it a lot more scalable than the two tiered architecture.

Since Three Tier Architecture systems help the development of software, as each tier is capable of being built and executed on different platforms, this make it a lot easier for the implementation to be organized. Three Tier Architectures also allow for several different tiers to be developed in a multitude of languages.

It is possible to migrate legacy system to Three Tier Architecture in a low risk and cost effective fashion. This is accomplished via the maintenance of the old database and process management rules, allowing both the new and old systems to be run side by side until each application and data object has been moved to the new design. Such a process of migration may well necessitate the rebuilding of legacy applications with new tools and buying additional service tools and server platforms. The benefit of such a move, however, is that Three Tier Architectures can hide the complexity of supporting and deploying network communications as well as underlying services.

Maturity, Costs and Alternatives

Throughout the early half of the ‘90s, Three Tier Architecture systems have been utilized successfully on thousands of systems. They were used by the Department of Defense, as well as in the business sector, where distributed information computing is necessary in a heterogeneous environment.

The construction of a Three Tier Architecture model can be quite a lot of work. The fact is, we are still not at the point where the programming tools that support the deployment and design of such architectures are able to provide all of the services that are required to support a distributed computing atmosphere.

One problem in the design of Three Tier Architecture systems is that it is not always clear that the process management logic, data logic, and interface logic are separate entities. Occasionally, process management logic can appear on all of the tiers. Thus, it is necessary to base placement of a particular function on a tier on the following criteria: the ease of testing and development; the scalability of the servers; the ease of administration; and the performance – this includes both network load and processing.

Sometimes, Three Tier Software Architecture will not be necessary. There are instances in which a two tier client server system will be okay. That situation is typically when the number of users will be less than one hundred or for the purpose of non real time info processing in a non complex system that does not require a huge amount of operation intervention.

Another viable alternative to Three Tier software architecture is distributed / collaborative enterprise computing. This alternative is deemed appropriated if object oriented technology on an enterprise wide scale is the end goal. Such enterprise wide designs typically consist of several smaller systems or subsystems.

While Three Tier Architecture is definitely sound, it has been found that the products supporting the implementation of the architecture are not always as well developed as technologies in competing fields. When it is not possible to fulfill one’s needs with the existing multi layer technology, Transaction Monitors have been recommended. While it is true that Transaction Monitors are not able to support such modern development paradigms as Objection Orientation, they can still be used when the desired end goal is robustness and scalability on a massive scale.

Three Tier technologies also have a lot of complimentary technologies, such as Object Oriented Design, which is used to implement decomposable applications. Other technologies include Database Two Phase Commit processing and Three Tier client server architecture tools. Useful middleware includes Message Oriented Middleware and Remote Procedure Call.