Why 3-Tier?


Why 3-Tier (multi-Tier, n-Tier or enhanced client/server)? This question was mostly answered by the industry approximately 25-30 years ago. As the evolution of mission-critical mainframe systems progressed through the 1940's to the 1960's, some fundamental elements of a transaction-oriented architecture and application became axiomatic: (1) the resource manager (database), (2) transaction monitor with accompanying business logic algorithms (transactions) and (3) the algorithms for displaying to a user's screen or terminal. Although these basic components often resided on the same physical computer, a clear distinction had evolved among the three.

By the mid-to-late 1970's, the advent of the microprocessor made possible the ability for a complete computing system to reside on the desktop. This later become known as "the client." With this tremendous step forward, the "algorithms for displaying to a user's screen" as well as some of the "business logic algorithms," could find their way onto the desktop client. The Graphical User Interface (GUI) could now be used to beautify and make more user-friendly the appearance and interaction with mission-critical information systems. This was the birth of what we today call "Client/Server" and sometimes refer to as "2-Tier" or "conventional client/server."

The continuing evolution of information technology and client/server seemed as bright as could be. However, something very terrible happened. For the most part, as this evolution continued, the transaction processing (TP) monitor all but disappeared. Personal computers on the desktop were (and still are!) connecting, over networks, directly to the resource managers (databases). Often, the TP monitor, the shotgun and pinnacle of control for all of an information system's processing, was nowhere to be found. Furthermore, as organizations put their core business online, the networks of 2-Tier client/server architectures became saturated with the requests for raw data from desktop clients, which was then processed and made useful by algorithms functioning on the client. Some excellent client/server systems found some remedy in having been architected with their application logic and processing being performed on the server, where the resource manger (database) resides. These server-centric systems gave rise to and validated the use of stored procedure languages, provided by the database vendors. However, the majority of client/server systems were (and still are) without the fundamental TP monitor.

Why did this happen? Why was it allowed to happen? There are many arguments which attempt to answer these questions. However, Parabolic Technologies espouses the belief that client/server systems (like all information systems in general) are evolutionary and are never fully complete. Client/server is at a point now where it is growing up and maturing to meet the mission-critical needs that have long been met by legacy mainframe systems.

The fundamental architecture of a client/server system is fully capable of having the TP monitor and centralization of application algorithms/logic. Such products as Prolifics, from Prolifics, a JYACC Company and TUXEDO (Transactions for UNIX with Extended Distributed Options), from BEA Systems, make this next step in client/server evolution possible. (NOTE: TUXEDO is not just a product for the UNIX market as its name might suggest, but is available for and in use by many Windows NT systems.) In essence, client/server can have the three fundamental elements of a mission-critical, transaction-oriented architecture, thus the term "3-Tier" (or "multi-Tier," "n-Tier," and "enhanced client/server).

The implementation of a 3-Tier architecture also contains further possibilities, such as real-time transaction-oriented access between UNIX, NT and mainframe systems. A 3-Tier architecture provides the basis for integrating an organization's entire information systems into an all powerful Enterprise.

Below is a contrast between 2-Tier and 3-Tier client/server architectures:

2-Tier Paradigm 3-Tier Paradigm
Great number of concurrent connections to databases Multiplexing -- lesser number of concurrent connections to databases
No access to mainframe Can possibly utilize OpenOLTP and Gateways and other mainframe access software
Security Risk -- anyone can physically connect to database using ODBC and a userís ID All database access must go through the middleware. No client can connect to database directly.
Increased auditing capabilities.
Non-Transactional (conversational instead) Transaction-oriented system.
High throughput.
Supports synchronous communication only. Supports both synchronous and asynchronous communication.
Homogenous data management (Generally, 1 database vendor) Heterogeneous data management (Many database solutions/vendors)
Great for small scale applications. Necessary for large, mission critical Enterprise systems.

Other benefits of a 3-Tier architecture include:
  • Lower network traffic.
  • Easier migration to Internet/intranet solution.
  • Event brokering.
  • Queuing.
  • Greater fault tolerance.
  • Load Balancing (higher throughput, volume).

The challenge over the next 15 years is to upgrade and integrate the many fine client/server applications in existence into a 3-Tier architecture and the Enterprise.

More Information: info@parabolictech.com

Home Page

All Content ©1996-2005 Parabolic Technologies Incorporated.

BEA is a registered trademark of BEA Systems, Inc.