2.2 System Architectures / 2.2.1 Centralized Architectures (distributed Systems)

Obviously, that:

Deciding on software components, their
interaction, and their placement leads an instance of a software architecture,
also called a system architecture (Bass et aI., 2003)

and

Despite the lack of consensus on many distributed systems issues, there is one
issue that many researchers and practitioners agree upon: thinking in terms of clients that request services from servers helps us understand and manage the complexity of distributed systems and that is a good thing

okay, let's go ahead talking about centralized architectures.

here a good picture

Nothing complicated, it's simple.

but, this is just a simple representation of the work between the client and the server, in complex systems, not everything is so clear.

The following key points should be highlighted from this text::

1. Connectionless vs. Connection-Oriented Protocols (Connectionless protocols and Connectionless Protocols):

• Connectionless: (e.g. UDP)
• Are simple and efficient, especially in reliable local area networks.
  • The client simply sends a message without first establishing a connection.
  • The server waits for incoming requests, processes them, and sends a response.
  • Reliability issues: Messages may get lost or corrupted.
  • Failure handling is non-trivial, and resending requests can lead to repeated operations (especially if the operation is not idempotent).
• Connection-Oriented: (e.g. TCP)
• More reliable, especially on unreliable networks (e.g. the Internet).
  • The client first establishes a connection to the server, sends a request and receives a response over the same connection, and then disconnects the connection.
  • Connection installation and disconnection require additional costs (especially for small requests/responses).

2. Idempotency:

• Definition: An operation is idempotent if it can be performed several times without undesirable side effects. Repeated execution of an idempotent operation leads to the same result as a single execution.
• Examples:
  • Idempotent: "tell me how much money I have left" (repeated request will not change the account balance).
  • Non-idempotent: "transfer $10,000 from my bank account" (a repeat transfer will withdraw another $10,000).
• Importance: Idempotence is important when handling network failures. If the operation is idempotent, you can safely repeat the request without fear of undesirable consequences.

3. Trade-offs (Compromises):

• The choice between connectionless and connection-oriented protocols depends on the specific situation and requirements.
• Connectionless protocols can be more effective in reliable networks, but require additional measures to handle failures.
• Connection-oriented protocols provide greater reliability, but have higher overhead costs.

4. Emphasis on the importance of reliability in distributed systems:

• In complex systems, especially WAN (Wide Area Network), communication reliability is critical.
• Simple solutions that work on local networks may not be applicable in more complex environments.
• Problems with message transmission and processing will be discussed in more detail in Chapter 8.

there is no universal solution for all tasks, and that the choice of communication protocol and fault management strategy depends on the specific requirements and characteristics of the system. Understanding the concept of idempotence is also very important for building reliable and sustainable systems.

Application Layering

1. The problem of a clear separation between client and server:

• The clear boundary between the client and the server is often blurred.
• The server can act as a client, redirecting requests to other servers.

2. Three-tier architecture (for database applications):

• User interface level:
• Provides user interaction (display, input).
  • Clients usually implement this layer.
  • Different in complexity: from simple text interfaces to complex graphical ones.
• Processing level:
• Contains application logic (core functionality).
  • Connects the user interface to the data layer.
• Data level:
• Manages the actual data (databases, file systems).

3. Development of user interfaces:

• From simple text interfaces (mainframe) to graphical interfaces (X-Windows, MS-DOS, Mac).
• Modern interfaces allow applications to exchange data through user actions (drag-and-drop).

4. An example of an Internet search engine as an example of a three-level architecture:

• User interface: Keyword input field and results display.
• Processing level: A program that converts keywords into database queries and ranks the results.
• Data level: A huge database of Web pages with indexes.

The key idea:

The text highlights that the traditional client-server model may be too simplistic for modern applications. The three-tier architecture offers a more structured approach, dividing responsibility between the user interface, processing logic, and data storage. This separation allows you to create more flexible and scalable applications.

1. Additional examples of three-tier architecture:

• Decision support system for a stock broker:
• User interface (front-end).
  • Financial data database (back-end).
  • Analysis programs (statistics, AI) at the processing level. It may require high-performance computers.
• Office suite (word processor, spreadsheet, communication tools):
• General user interface.
  • Many programs with simple processing capabilities (processing level).
  • User files (often on a remote server).

2. Data Level:

• Contains programs that manage the actual data.
• Important property: data is often persistent.
• Can be implemented as a file system or database.
• Responsible for maintaining data consistency between applications.
• Includes metadata storage (table descriptions, constraints).
• Can use triggers databases to perform tasks automatically.

3. Relational Databases:

• Commonly used in business-oriented environments.
• Data independence is important: changes in the organization of data should not affect applications, and vice versa. Relational databases help to separate the processing layer from the data layer.

4. Alternatives to relational databases:

Relational databases are not always ideal for complex data types.

• For working with complex data types such as polygons, circles, and aircraft structures (CAD), it may be more convenient to use object-oriented or object-relational databases.
• Object-relational databases combine the advantages of a relational model and an object-oriented approach.

5. Multilevel architectures (Multitiered Architectures):

• The division into three logical layers allows the application to be distributed among several physical machines.
• The simplest organization:
  • Client machine: User interface only.
  • Server machine: everything else (processing layer and data layer).
• The client becomes a "dumb terminal" with a beautiful graphical interface.
• There are other, more complex options.

Key ideas:

• The choice of database structure is an important aspect of system design and depends on the specifics of the data.
• Layered architectures allow flexible distribution of system components across different machines, which helps improve scalability and performance.
• The concept of data independence is important, which helps to maintain the flexibility of the application when changing the storage structure.

1. Options for the distribution of three-level architecture levels (UI, Processing, Data) between the client and the server (graphs 2-5 a-e are described):

• (a) Thin Client: Only the terminal-dependent part of the UI on the client. The application controls the data representation remotely.
• (b) UI on the client, the rest on the server: UI - graphical front-end, interacts with the server via the application-specific protocol. The client does not do any other processing other than presenting the interface.
• (c) Part of the processing on the client: UI + form validation on the client (for example, checking the data before submitting). Word processor: basic editing on the client (locally in cache or memory), advanced tools (spellcheck) on the server.
• (d) Most of the application is on the client: Applications run on a PC or workstation connected to a distributed file system or database. File operations/The databases go to the server. Banking application: preparing transactions on the client, sending transactions to the bank's database server.
• (e) Part of the data on the client: the client's local disk contains part of the data (Web browser cache).

2. The trend from "fat" to "thin" customers:

• Previously, there was a tendency to move more functionality to the client side ("fat clients", 2-5 d,e), now the trend is to return to "thin clients" (2-5 a-c).
• Reason: "fat" clients are more difficult to manage (more errors, dependence on the client's platform). Thin clients are simpler, albeit with less complex UI or performance perceived by the client.

3. The importance of distribution and multilevel:

• Thin clients do not mean that distributed systems are no longer needed.
• On the contrary, server solutions are becoming more and more distributed (one server is being replaced by many servers).
• Important: The server can act as a client (Figure 2-6), resulting in a (physically) three-tier architecture.

4. Three-tier architecture with a server acting as a client:

• Processing level programs are located on a separate server, but can be distributed between the client and the server.
• Examples:
  • Transaction Processing: Transaction Processing Monitor coordinates transactions between different data servers.
  • Websites: Web server (entry point) -> Application server (processing) -> Database server.

Key ideas:

• There are several ways to distribute application components between the client and the server.
• The choice of architecture depends on trade-offs between functionality, ease of management, performance and reliability. Modern systems often use layered architectures in which servers can act as clients, providing more complex and flexible interactions.
• The main trend is the desire for "thin" clients to simplify management, but while maintaining a distributed backend.

Here is a short summary in the form of a table:

The basic idea:

There is no universal solution — the choice of architecture depends on the requirements for reliability, performance and complexity of the data. The three-tier model improves scalability and flexibility.