Explain four additional types of partitioning in an n-tier approach.
Additional n-tier Architectures
In the two- and three-tier architectures it was easy to see that there could be many client applications. We assumed that the middle and bottom tiers were centralized. But could not these tiers be as diverse as the client applications? For example, if you have a nationwide company divided into regions, it is very likely that the data for each region is in a different location.
If so, then the bottom tier is actually a collection of partitions with similar responsibilities but different content.
Not only do you separate the bottom layer, but you must also provide a new interface between the middle tier and the new set of data partitions.
Three-tier with distributed data layer: 1) Presentation, 2) Logic, 3) Distributed Data Access
The image illustrates an expanded three-tier architecture that integrates a distributed data layer:
Presentation Tier (Green): This layer deals with the user interface and presentation logic, allowing users to interact with the system.
Interface Layers (Yellow): These are positioned between each major tier, facilitating communication and data exchange. They define the protocols or methods through which different system layers interact, ensuring separation and modular design.
Logic Tier (Yellow): It handles the business logic and decision-making processes of the application, translating user actions from the presentation layer into operations that can be applied to the data.
Distributed Data Access Tier (Blue): This bottom tier is segmented into different functional areas such as Marketing, Receivables, Payables, and Sales, each representing a part of the data layer that specializes in handling specific types of data or business processes.
This architecture allows for high modularity, easier scalability, and improved fault isolation by distributing the data access across different domains within the same layer. Each segment of the data layer can be independently managed and scaled according to the needs of its respective domain, enhancing the overall robustness and efficiency of the system.
Multiple transaction servers
Consider departmental systems where different servers handle different types of transactions. Order processing handles order fulfillment, while transactions and accounts receivable handles billing and payment transactions.
The middle tier, too, is divided into numerous partitions.
The image outlines a three-tier architecture with a specialized focus on a "Distributed Transaction Layer" within the middle tier:
Presentation Tier (Green): This top layer is focused on user interaction, where the user interface components reside. It is responsible for collecting user inputs and presenting data.
Distributed Transaction Layer (White with Subdivisions): Positioned as the middle tier, this layer is segmented into four specific domains: Marketing, Receivables, Payables, and Sales. Each segment handles different aspects of business logic and transactions related to its domain, facilitating specific business operations and processing.
Data Tier (Blue): The bottom layer serves as the repository for storing and retrieving data. It works in conjunction with the middle layer to ensure that data integrity and transactions are maintained across different functional areas.
The architecture displayed in the image emphasizes a modular approach by incorporating a distributed transaction layer that allows for separation of concerns within the business logic tier. This setup can enhance scalability, maintainability, and performance by enabling each business domain to operate semi-independently within a coherent overall system structure.
Specialization
In some environments there are specialized processes for special cases. Preferred customers may have their orders and their billing handled differently. In this case there may be a layering within the transaction tier itself.
Changing Design
Remember how I said that architecture establishes new requirements for design? Here is a good example.
Would you use the same interface design for a central middle tier that you would use for a distributed middle tier?
Answer: This is very unlikely.
In fact, one reason the CORBA standard was developed was to address the need for an architecture that supports distributed processing on the middle and lower tiers.
(CORBA) Common Object Request Broker Architecture is an open, vendor-independent specification for an architecture and infrastructure that allows applications to communicate over networks. The core features of CORBA are:
A high-level Interface Definition Language (IDL), allowing applications to specify their distributed communication in an object-oriented fashion.
Standardised protocols, GIOP and IIOP, for on-the-wire CORBA communication.
A set of programming APIs to address the middleware needs of client to server connectivity.
These features allow all CORBA-based programs to interoperate, even though they may be written in almost any programming language, and running on almost any operating system or network.
What the system does and what event occurs: activities and interactions (use case)
Traditional structured approach to representing activities and interactions
Diagrams and other models of the traditional approach
RMO customer support system example shows how each model is related
How traditional and IE approaches and models can be used together to describe system
Specialization of the middle tier
The uploaded image represents a three-tier architecture with a specialized middle tier focusing on sales transactions:
Presentation Tier (Green): This layer handles the user interface and interaction. It is where users interact with the system through graphical elements and controls.
Application Logic Tier (Yellow): This tier includes:
Sales Transaction Logic: Specifically designed to handle the logic associated with sales transactions. This specialization is broken down further into:
Regular Customer Processing: Dedicated to managing transactions for regular customers.
Preferred Customer Processing: Tailored to handle transactions for preferred or VIP customers, likely offering different workflows or privileges.
Data Tier (Blue): This bottom tier is responsible for data management, including storage, retrieval, and integrity of data used and generated by the upper layers.
The architecture depicted emphasizes a finely tuned division within the middle tier, showcasing a scenario where business logic is not only separated from presentation and data concerns but is also differentiated internally to cater to distinct customer segments. This structure enables targeted improvements and optimizations in processing sales transactions for different types of customers.
Thin clients
The advent of the Web has driven the need for very small client applications. What Web applications really require is to separate the interface (the screen presentation) from the logic that governs the behavior of the interface. This setup allows much smaller client
applications, faster downloads, and better access to services in the lower tiers. This type of partitioning has led to technologies like Web servers and Java servlet applications.
