N-Tier Architecture

In this model, all of the business logic is extracted out of the application running at the desktop. The application at the desktop is responsible for presenting the user interface to the end user and for communicating to the business logic tier. It is no longer responsible for enforcing business rules or accessing databases. Its job is solely as the presentation layer.


Typically, in a deployed application, the business logic tier executes on a server apart from the workstation (you’ll see shortly that this isn’t absolutely required, though). The business logic tier provides the logical glue to bind the presentation to the database. Since it’s running on a server, it’s accessible to any number of users on the network running applications that take advantage of its business rules. As the number of users demanding those services increases, and the business logic becomes increasingly complex and processor-intensive, the server canbe scaled up or more servers can be added. Scaling a single server is a lot easier and cheaper than upgrading everyone’s workstations.

One of the really great things that this architecture makes possible is the ability to start to build application models where the classes defined in the business logic tier are taken directly from the application domain. The code in the business logic layer can work with classes that model things in the real world (like a Customers class) rather than working with complex SQL statements. By pushing implementation details into the appropriate layer, and designing applications that work with classes modeled from the real world, applications become much easier to understand and extend.

It’s possible to continue the process of partitioning the application functionality into increasingly thin functional layers, as illustrated in Figure 1-5. There are some very effective application architectures based on n-tier architecture. The application architect is free to partition the application into as many layers as appropriate, based on the capabilities of the computing and network hardware on which the system is deployed. However, you do need to be careful about reaching a point of diminishing returns, since the performance penalty for the network communication between the layers can start to outweigh any gains in performance.


In summary, n-tier application architecture is intended to address a number of problems, including the following:

• The high cost of maintenance when business rules change. N-tier applications have improved maintainability.
• Inconsistent business rule implementation between applications. N-tier applications provide consistency.
• Inability to share data or business rules between applications. N-tier applications offer interoperability.
• Inability to provide web-based front ends to line-of-business applications. N-tier applications are flexible.
• Poor performance and inability to scale applications to meet increased user load. N-tier applications are scalable.
• Inadequate or inconsistent security across applications. N-tier applications can be designed to be secure.

The Java EE architecture is based on the notion of n-tier applications. Java EE makes it very easy to build industrial-strength applications based on two, three, or more application layers, and provides all of the plumbing and wiring to make that possible.

Note that n-tier architecture does not demand that each of the application layers run on a separate machine. It’s certainly possible to write n-tier applications that execute on a standalone machine, as you’ll see. The merit of the application design is that the layers can be split apart and deployed on separate machines, as the application requires.