Three-tiers for client-server. (three-tiered client-server architecture)

Three-tiered architecture is one of the most important new trends in corporate application development today. If you've heard of it, it's probably been only within the last year or so. If you haven't heard of it, you're in for a treat. It's a very intriguing concept, and many products are now coming to market to make it a reality.

This article starts at the beginning, explaining what three-tiered architecture is and the benefits it offers. Then it provides an overview of some of the available products to support three-tiered application development.

Three-tiered vs. two-tiered

It's easiest to define three-tiered architecture by contrasting it with two-tiered architecture. Two-tiered architecture is the traditional client-server environment. An application is divided into two segments (tiers): the client or front end, which is the user-interface part of the application, and the server or back end, which manages the database (figure 1). In a typical configuration, the division of the two tiers is both a hardware and a software separation. The client is typically a workstation sitting on a user's desk, running user interface software, developed using a front-end development tool such as PowerBuilder, SQLWindows, Visual Basic, Delphi, or any number of other products. The server is a server computer that's located elsewhere on the network running database server software such as Sybase or Oracle.

Three-tiered architecture adds a third component to the picture, as shown in figure 2. The middle tier, the "business process server," is a separate piece of software--typically running on a separate piece of hardware--that performs most of the application logic, such as enforcing business rules and performing complex processing. From the client's point of view, the business process server is the server. From the database server's point of view, the business process server is the client. A typical business process server might be a UNIX machine running C programming.

As an example of how three-tiered architecture works, consider a sales-order application. In a three-tiered environment, the client running on a workstation presents a sales-order screen to users and accepts new sales orders as they're typed in. The middle tier performs all the processing on the new order: confirming that inventory is available, calculating discounts, checking the customer's credit, and so forth. If the order isn't acceptable, the middle tier sends a message back to the client. If the order is acceptable, the middle tier sends it to the database server, which inserts it into the database.

In a two-tiered, client-server environment, the sales-order system looks the same to users, and the data is stored the same by the server. But where would the business processing take place? Either on the client, as part of the front-end programming, or on the server, as stored procedures. In the two-tiered scenario, the processing tends to bog down whichever computer does the processing, especially if there's a lot of it. So one of the potential benefits of the three-tiered architecture is performance: Off-loading the processing to a separate business process server allows faster throughput.

My first reaction to three-tiered architecture was, "What a great new idea!" My second reaction was, "But this is something I've done, or thought about doing, for years!" So I've reached the conclusion that this concept is something old and something new. I suppose that for as long as …