N-Tiered Architectures

Another classification that architectures fall into is the number of different layers , or tiers, the architecture has. A tier is a grouping of software and possibly hardware, components, and services. This grouping can be both logical and physical. The purpose of using tiers is to enable the software components and services to be distributed across multiple computers for scalability and security. For example, as you'll see in Chapter 19, "Building a Presentation Tier for EJB," the Web server components and services are sometimes distributed in a different tier than the application services. This adds security to the application because more of the application can be located deeper in a protected network. The three most common architectures that you will hear about are

• Two-tier

• Three-tier

• The ubiquitous n-tier

Note

The n-tier name is referred to here as ubiquitous because this term is used to describe many different types of enterprise application architectures.

The n refers to how many tiers the architecture has, from 1 to some number (n). In most cases, n is usually 3, 4, or more. Most often, developers use the term "n-tiered" to refer to a three-tiered architecture. Let's take a quick look at a few of the typical architectures and how they are used today.

Two-Tier Component Architectures

No technical book would be worth its weight in salt if it didn't at least mention the two-tiered client/server architecture. It's often said, "Those who forget the mistakes of the past are doomed to repeat them." The two-tier or client/server application-programming model was very big up through the early 1990s. In fact, it's still a very popular architecture for certain types of applications. The problem is that it just doesn't scale when many users are using the system at the same time. I'm sure there are many of you screaming right now because you found a way to make it scale, but generally speaking it doesn't scale very well when the number of concurrent users starts to climb. This typically is due to the inability of the database to handle large numbers of client connections.

The two-tier architecture had other problems as well. To distribute a new version of the software, all clients had to be updated with the new client software, which contained all the business logic, database logic, and everything else. This also meant that very complex code, such as security and database interaction, was done in every client. This added overhead to the client application and increased the network traffic. The process of distribution became easier with Java applets, but the applet still contained some logic that could be better located elsewhere. With some of the security restrictions that were placed on the applet, this particular technology still does not work for all applications.

This architecture is usually referred to in a negative way as a fat client because it contains virtually all the components within this one tier. The second tier was usually a database of some type, most often a relational database. Figure 1.3 illustrates a typical two-tiered client/server architecture.

Figure 1.3. An example of a typical client/server architecture.

During the late '80s and early '90s, many development organizations started to replace the two-tier model with a three-tier model. Basically what the developers and architects did was to add a new tier between the previous two, and some of the software components were installed or deployed into this tier rather than the client tier. Most of the components and services that were moved to this new tier were the ones responsible for the business logic of the application.

N-Tier Component Architectures

This new middle tier could be installed somewhere on the network and it could be shared with many different clients, rather than belonging on the client machine. It also helped because the size and complexity of the client application was reduced, which was good because, compared to the typical middle-tier server, the client machines were usually smaller in processing power and less capable of handling the application.

So with all these benefits, surely there are some negatives with an n-tiered architecture. The answer is, yes, there are. The negatives are associated with the distributed nature of the application. When the middle tier was created, it added complexity because the application now needed to handle things such as security, concurrent access, multi-threading issues, how the client locates the middle tier and other things that the client/server model didn't necessarily have to deal with. Of course, the 2-tier model had to deal with things such as security, but because each client was self-contained, these things were easier to deal with. One of the most obvious complexities that must be dealt with for the multi-tier architectures is the necessity for network computing between the first and middle tiers. Figure 1.4 illustrates a typical multi-tier architecture.

Figure 1.4. An example of a multi-tier architecture.

You must be asking yourself whether using a distributed component architecture is really so great. With all the pieces and technologies to learn, do you really get a return on your investment? In short, the answer is absolutely yes. And hopefully, the rest of the book will show that, by separating a system into pieces where each piece has a single or small set of responsibilities, each piece is able to concentrate on the work it was designed to do. This also enables developers or vendors to optimize a component for exactly what it should do best. Other justifications, such as having thinner clients and the ability to swap out the UI without worry about porting business logic, are beneficial as well. Not to mention that by having a physically distributed application, you are better able to take advantage of clustering techniques. We'll discuss clustering concepts in Chapter 22, "EJB Clustering Concepts."

By isolating the tiers, organizations are able to buy and install third-party complex software components into their architecture and spend more of their time solving the core business problem.