Architectural partitioning is the process of breaking the system down into layers of technology and responsibility. Each domain partition is unique; some are back office functions, while some are widely distributed or departmental. There are a variety of techniques for partitioning your architecture. Each has specific consequences for your application. For each domain partition you will need to define an architecture.
Architecture before Design:
It is critical that architectural partitioning come before object design. The low-level design must support the architectural partitioning. Different architectures result in different design requirements. Issues such as latency, memory management, and communication change with each architectural choice. A two-tier design does not directly map to a three- or n-tier design. Each change in the architecture changes the requirements for the low-level design.
Architecture dictates Technology Requirements:
The architecture level choices also constrain the technological options that influence the low-level design.
For instance, a decision to use Java on a server and Visual Basic on the client eliminates the option of Java RMI and leads you toward something like CORBA.
Likewise, the selection of an object database removes the need for object to relational mapping.
After completing this module, you will be able to:
Explain the purpose and function of architectural partitioning
Create architectural partitions and define their behaviors
Specify how responsibilities are distributed in two-tier, three-tier, and n-tier architectures
Apply the deployment diagram to model the system architecture
There are many ways in which the application logic can be partitioned between the client and the server. The arrangement in Figure 5-1 is a common configuration. In this case, the server is responsible for the data and the client is responsible for the application and presentation. This is called a two-tiered architecture because it uses only two sets of computers consisting of clients and servers.
Figure 5-1: Two-Tiered Client - Server Architecture
A three-tiered architecture uses three sets of computers, as shown in Figure 5-2.
Figure 5-2: Three-Tiered Client–Server Architecture
In this case, the software on the client computer is responsible for presentation logic, an application server(s) is responsible for the application logic, and a separate database server(s) is responsible for the data access logic and data storage. Typically, the user interface runs on a desktop PC or workstation and uses a standard graphical user interface. The application logic may consist of one or more separate modules running on a workstation or application server. Finally, a relational
DBMS running on a database server contains the data access logic and data storage. The middle tier may be divided into tiers itself, resulting in an overall architecture called an "n-tier architecture". An n-tiered architecture distributes the work of the application (the middle tier) among multiple layers of more specialized server computers. This type of architecture is common in today’s Web-based e-commerce systems. The browser software on client computers makes HTTP requests to view pages from the Web server(s), and the Web server(s) enable the user to view merchandise for sale by responding with HTML documents. As the user shops, components on the application server(s) are called as needed to allow
the user
1) to put items in a shopping cart; 2) determine item pricing and availability; 3) compute purchase costs, sales tax, and shipping costs;
4) authorize payments. These elements of business logic, or detailed processing, are stored on the application server(s) and are accessible to any application. For example, the cash register application that needs item price look-ups could use the same price determination business logic that is used by the e-commerce Web site. The modular business logic can be used by multiple, independent applications that need that particular business logic. The database server(s) manage the data components of the system. Each of these four components is separate, which makes it easy to spread the different components on different servers and to partition the application logic on a web server.
