Three-tier architectures
WebSphere Application Server provides the application logic layer in a three-tier architecture, enabling client components to interact with data resources and legacy applications.
Collectively, three-tier architectures are programming models that enable the distribution of application functionality across three independent systems, typically:
- Client components running on local workstations (tier one)
- Processes running on remote servers (tier two)
- A discrete collection of databases, resource managers, and mainframe applications (tier three)
The following diagram outlines the three tier levels. The tiers are logical . They might or might not be running on the same physical server.
- First tier
Responsibility for presentation and user interaction resides with the first-tier components. These client components enable the user to interact with the second-tier processes in a secure and intuitive manner. WAS supports several client types. Clients do not access the third-tier services directly. For example, a client component provides a form on which a customer orders products. The client component submits this order to the second-tier processes, which check the product databases and perform tasks needed for billing and shipping.
- Second tier.
The second-tier processes are commonly referred to as the "application logic layer". These processes manage the business logic of the application, and are permitted access to the third-tier services. The application logic layer is where most of the processing work occurs. Multiple client components can access the second-tier processes simultaneously, so this application logic layer must manage its own transactions.
In the previous example, if several customers attempt to place an order for the same item, of which only one remains, the application logic layer must determine who has the right to that item, update the database to reflect the purchase, and inform the other customers that the item is no longer available. Without an application logic layer, client components access the product database directly. The database is required to manage its own connections, typically locking out a record being used accessed. A lock can occur when an item is placed into a shopping cart, preventing other customers from considering it for purchase. Separating the second and third tiers reduces the load on the third-tier services, supports more effective connection management, and can improve overall network performance.
- Third tier.
The third-tier services are protected from direct access by the client components residing within a secure network. Interaction must occur through the second-tier processes.
(ZOS) The advantage on z/OS is the ability to collapse the second and third tiers into one physical z/OS environment, while preserving the security and logical advantages of unique tier systems.
Communication among tiers.
All three tiers must communicate with each other. Open, standard protocols and exposed APIs simplify this communication. We can write client components in any programming language, such as Java or C++. These clients run on any operating system, by speaking with the application logic layer. Databases in the third tier can be of any design, if the application layer can query and manipulate them. The key to this architecture is the application logic layer.
How requests traverse topologies
Request metrics, which are primarily a set of timing agents, can track a request as it navigates the components of the application server. A key differentiation of request metrics is that they are measured at the request level. The focus of a request metric is to record the time spent by individual requests in different components of the application and at the end of the request provide a record of where time was spent in the request.
Related: