The Move into the Second Tier
The move towards 2-tier systems was born from the desire to share data between multiple applications installed on different machines. To do this, a separate database server machine was required. Figure 1.2 shows how this is achieved. The application now consists of presentation and business logic. Data is accessed by connecting to a database on another machine. Any changes to the Data Access logic should not affect the Presentation or Business logic in the application.
Figure 1.2. 2-tier scenario.
As indicated by Figure 1.2, splitting out Data Access Logic into a second tier keeps the data access independent and can deliver a certain amount of scalability and flexibility within the system.
The advantage of having the Data Access Logic split into a separate physical environment means that not only can data be shared, but any changes to the data access logic are localized in that second tier. In fact, the whole of the second tier could be replaced with a different database and different code as long as the interface between the two tiers remained the same.
This provides an alternative way of looking at the program logic. Each part of the logic from the monolithic system could be regarded as a separate layer.
The logical division into layers of functionality can be based on the different responsibilities of parts of the code, namely,
Presentation Logic— This dictates how the user interacts with the application and how information is presented.
Business Logic— This houses the core of the application, namely the rules governing the business process (or any other functionality) embedded in the application.
Data Access Logic— This governs the connection to any datasources used by the application (typically databases) and the provision of data from those datasources to the business logic.
So, we have two tiers in Figure 1.2 with two logical layers. The Presentation and Business Logic layers are still lumped together as one piece of potentially monolithic code.
Consequences of the 2-Tier Design
One of the central problems faced by application developers using the type of architecture shown in Figure 1.2 was that the client is still full of business code and it still needs to know details about the location of its data sources. Because there is such a concentration of functionality on the client, this type of client is generally termed a thick client. Thick clients usually need to be updated whenever the application changes.
Because the users of a thick client application have much of the application code installed on their local systems, there is a need to install fresh copies of the updated application when changes are made. This presents a serious manageability issue in terms of roll out and version control. Also, it is not always practical to use a thick client, because the application user may not want to install code on his or her machine to use a particular application. Similarly, the application provider may not want to provide code containing its business logic to relatively unknown third parties, even if it is pre-compiled.
Another issue with the use of thick clients relates to data access. The need to provide access to the back-end data for all clients of the application severely limits the reach and scalability of the application.
In addition to these inherent problems, many applications written with tools aimed at the two-tier environment still had all of their code in a single executable module. This increased maintenance headaches because there was a need to update the program design and implementation if any changes are required to any part of the system. With the advent of the Internet, there was a movement to separate Business logic from the user interface. Internet users, or more precisely Web users, need to access applications without installing new code on their machines. In fact, they want to be able to use the same client application—a Web browser—to access all of the different applications they encounter on the Web. Because the application logic associated with a thick client is no longer resident on the user's machine, this type of client is known as a thin client. The implication is that all of the “bulk” of the application has been moved into another tier. When a Web browser is used as a thin client, the application code will be run on the Web servers with which the browser communicates (or on other machines with which the Web servers communicate). The presentation tier logic for such an application must generate Hypertext Markup Language (HTML) rather than manipulate graphical elements on a GUI screen.
All of this has a serious implication for 2-tier systems. If a 2-tier system is to be adapted for use on the Internet, the thick client part that contains the business logic and the presentation logic must be re-written to run on a Web server. This will then mean that there are two copies of the business logic—one housed in the original thick client and the other housed in the Web-based version of the application. This is a nightmare in maintenance terms because any changes or updates must be made in both places. More decoupling is required to improve the manageability and maintainability of the application.
The decoupling of application logic by introducing additional tiers, as started with the two-tier system shown in Figure 1.2, can be continued with the separation of the Business and Presentation Logic. By housing the separated Business Logic in another tier, the thick client suddenly becomes thinner, as Figure 1.3 shows.
Figure 1.3. 3-tier scenario.
The Presentation Logic is now separated into its own layer in its own tier. This means that different types of Presentation Logic, such as HTML-based and GUI-based user interface code, can all access the same Business Logic on the middle tier.
This 3-tier model has become the de-facto architecture for Web-based business systems. The separation into layers makes systems more flexible so that parts can be changed independently. An example of this would be creating a presentation layer specifically targeted at mobile devices. Given the separation of business and presentation functionality, this should not require any changes to the business of Data Access logic. The separation into separate physical tiers provides the opportunity to inject enhanced scalability and availability by replicating machines and software at the different tiers.
With the logic now separated into layers, it is far easier to write code that is tailored to its particular task. For example, because the Presentation logic is now housed in its own physical and logical layer, such code can be written by a developer who is skilled in this particular area. Developers who are skilled in the use of Java Web components, such as servlets (see Day 12, “Servlets”) and Java Server Pages (JSPs) (see Day 13, “JavaServer Pages”) can write the code for this layer. These developers do not need to know about the technologies used in the business or data access code.