The Evolution of J2EE Architecture
The client/server application architecture, which was a two-tier architecture, evolved over time to a multitier architecture. This natural progression occurred as additional tiers were introduced between the end-user clients and back-end systems. Although a multitier architecture brings greater flexibility of design, it also increases the complexity of building, testing, deploying, administering, and maintaining application components.
In the next few sections, we'll discuss the evolution of the multitier architecture.
Two-Tier Architecture
The two-tier architecture is also known as the client/server architecture. It consists mainly of two tiers: data and client (GUI). The application logic can be located in either the client tier, which results in a fat client, or located in the data tier, which results in a fat server (see Figure 15.1).
Figure 15.1. Two-tier architecture.
This type of architecture suffers from a lack of scalability because both the client and the server have limited resources, in addition to the negative effect of network traffic to transfer data to the fat client. Another issue is maintainability; you have to roll out the new system version to all system users.
Three-Tier Architecture
To address the issues of the two-tier architecture, the application logic will be placed in its own tier. Thus applications can be portioned into three tiers. The first tier is referred to as the presentation layer, and consists of the application GUI. The middle tier, or the business layer, consists of the business logic to retrieve data for the user requests. The back-end tier, or data layer, consists of the data needed by the application. Figure 15.2 illustrates the three-tier architecture.
Figure 15.2. Three-tier architecture.
The decoupling of application logic from either presentation or data increases the flexibility of the application design. Multiple views or a GUI can be added without changing the existing application logic. Similarly, multiple applications can be created using the same data model. Changing the components of one tier should not impact the other two tiers. For example, any change to the data or GUI will not affect the application logic.
Note
The three-tier architecture is the basis for J2EE applications, in which EJBs provide a mechanism to build application logic, while JSPs and servlets abstract the presentation layer and allow interaction with the business layer.
One important feature of the three-tier architecture is sharing system resources by all clients, which results in highly efficient, scalable, secure, and reliable applications.
Multitier J2EE Architecture
Multitier (or n-tier) architecture differs from the three-tier architecture in viewing each tier logically rather than physically. The application logic, for example, can be split into more than one layer; the business logic tier and the presentation logic tier. Similarly, the user interface is partitioned into the client tier and the presentation tier. A multitier architecture determines where the software components that make up a computing system are executed in relation to each other and to the hardware, network, and users.
J2EE is a multitier architecture, which partitions the application into client, presentation logic, business logic, and enterprise information tiers. Figure 15.3 depicts the J2EE as a multitier architecture.
Figure 15.3. Multitier J2EE architecture.
The following gives a brief summary of each tier of the J2EE architecture:
Client tier— This tier interacts with the user and displays information from the system to the user. J2EE supports different types of clients—both inside and outside enterprise firewalls—including Web clients (HTML and Java applets) and Java applications.
Web tier— This tier accepts user requests and generates responses using the presentation logic. In the J2EE platform, servlets and JSPs in a Web container implement this tier, as explained on Day 7, “Designing Web Applications.”
Business logic tier— This tier handles the core business logic of the application. The business components are typically implemented as EJB components with support from an EJB container, which provides the component life cycle and manages persistence, transactions, security, and resource allocation.
EIS tier— This tier is responsible for the enterprise information systems, including different database systems, transaction processing systems, legacy systems, message-oriented middleware, and enterprise resource planning systems (ERPs). The EIS tier is the point at which J2EE applications integrate with non-J2EE or legacy systems.
Note
The J2EE platform is designed not only to support a multitier architecture to partition applications, but also to provide infrastructure common services to reduce the complexity of developing and deploying these applications.
Other than multitier, the J2EE architecture provides the enterprise with common infrastructure services which help in developing and deploying portable, secure and transactional applications. The J2EE architecture partitions enterprise applications into three fundamental parts: components, containers, and connectors. Components are the key focus of application developers, whereas system vendors implement containers and connectors to hide complexity and enhance portability. Enterprise Java applications can run on any J2EE-compliant application server.
Note
Multitier distributed applications follow the Model-View-Controller (MVC) paradigm, discussed earlier on Days 1 and 7. This design pattern provides clean separation between tiers. Using this paradigm, the model (data tier) is separated from the view (client and presentation tiers). Similarly, the controller (the application logic tier) is separated from both the view and the model.
Containers transparently provide common services, including transaction, security, persistence, and resource pooling, to both clients and components. A container allows the configuration of applications and components at deployment, rather than hard-coding them in program code. Connectors extend the J2EE platform by defining a portable client service API to plug into existing enterprise vendor products. Connectors promote flexibility by enabling a variety of implementations of specific services.