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.

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Show/Hide comments

Show/Hide comment form