Part 2. Let's talk a little about software architecture

This material is part of the “ Introduction to Enterprise Development ” series. The first part about the network is here . Software architecture is the structure on the basis of which an application is created and the modules and components of the entire program interact. Programmers have been trying to create good architecture for a very long time, so it is not surprising that we now know a lot of architectural patterns. You need to understand them: when you write a web application, the problem of architecture becomes acute, because there are more components and modules in it than in a regular application. An architectural pattern is an already thought-out way to solve some software design problem. You've probably already come across design patterns such as Factory Method, Abstract Factory, Builder, Prototype, Singleton, and perhaps others. They are used to simply write code, create classes, and plan how they interact. Architectural patterns are used at a higher level of abstraction - when planning the interaction of the application user with the server, data and other components of the project. Let's take a quick look at some templates and how to use them.

Client-server architecture

From the name one gets the impression that everything with this topic is simple and clear. But let’s clarify some points so that when you start studying the conditional Spring, you understand exactly what we are talking about. Let's say you wrote a chat, and you and your friend start using it. A simple option is possible here - you send a message to each other directly via the Internet using IP addresses that you know: At first, it may seem that everything is working fine, until another friend of yours appears with the question: “Why don’t you add me to your chat?” And when you decide to add a mutual friend to the chat, you are faced with an architectural problem: each chat user needs to update information about the number of users, add the IP address of the new user. And when sending a message, it must be delivered to all participants. These are the most obvious problems that will arise. A lot more problems will be hidden in the code itself. To avoid them, you need to use a server that will store all information about users and know their addresses. The message will only need to be sent to the server. And he, in turn, will send the message to all recipients. When you decide to add a server side to your chat, you will begin to build a client-server architecture.

Components of client-server architecture

Let's figure out what she is. Client-server architecture is a design pattern, the basis for creating web applications. This architecture consists of three components:

1. Client - from the name it becomes clear that this is a user of a service (web application) who contacts the server to obtain some information.

2. Server is the place where your web application or its server part is located. He owns the necessary information about users or can request it. Also, when a client contacts, the server returns the requested information.

3. The network is simple: it ensures the exchange of information between the client and the server.

The server can process a huge number of requests from different users. That is, there can be many clients, and if they need to exchange information with each other, this will have to be done through the server. Thus, the server receives one more additional function - traffic control. If we are talking about the multi-user chat we created, the entire program code will consist of two modules:

• client - contains a graphical interface for authorization, sending/receiving messages;

• server-side - a web application that is hosted on a server and receives messages from users, processes them, and then sends them to recipients.

When we want to look at useful (or not so useful) information on the Internet, we open a browser, enter a query in the search bar, and in response we receive information from the search engine. In this chain, the browser is our client. It sends a request with information about what we are looking for to the server. The server processes the request, finds the most relevant results, packages them into a format understandable to the browser (client) and sends them back. In such complex services as search engines there can be many servers. For example, an authorization server, a server for searching for information, a server for generating a response. But the client knows nothing about this: for him, the server is something unified. The client only knows about the entry point, that is, the address of the server to which it needs to send the request. Let's remember the application that we looked at in the previous part - for monitoring the average air temperature in all countries in real time. Its architecture will look something like this: Our application is located on a server. Let's say, every five seconds it sends requests to the servers of local hydrometeorological centers, receives information from them about the temperature in a particular country, and stores this information. When a client contacts us with a request to “see the current air temperature in the world,” we return the latest stored information, sorted by country. Thus, our application is both a server (when it processes user requests) and a client (when it receives information from other servers). A simple client-server architecture is used very rarely and only for very simple applications. For really large and complex projects, different types of architectures are used, which you will become more familiar with in the future. For now, let's look at a model that is very similar to a client-server model.

Three-tier architecture

This is an architectural pattern that introduces a third player: the data warehouse . When using this pattern, the three levels are usually called layers:

1. The client layer is the user interface. This could be a web browser to which the HTML pages are sent, or a GUI application written using JavaFX. The main thing is that with its help the user can send requests to the server and process its responses.

2. The logic layer is the server on which requests/responses are processed. It is often also called the server layer. All logical operations also take place here: mathematical calculations, data operations, calls to other services or data storage.

3. The data layer is the database server: our server accesses it. This layer stores all the necessary information that the application uses during operation.

Thus, our server assumes all obligations for accessing data, without allowing the user to access it directly.

Benefits of a three-tier architecture

Using such an architecture, we get many advantages, including:

1. The ability to build protection against SQL injections is an attack on the server in which SQL code is transmitted, and when this code is executed, the attacker can affect our database.

2. Delimitation of data to which we want to regulate user access.

3. Ability to modify data before sending it to the client.

4. Scalability - the ability to expand our application onto several servers that will use the same database.

5. Fewer requirements for the quality of the user's connection. When generating a response on the server, we often take a lot of different information from the database, format it, leaving only what the user needs. This way we reduce the amount of information that we send as a response to the client.

How often should you use architectural patterns?

If you're familiar with, say, the Factory Method design pattern , you've probably wondered when to use it. Sometimes it is difficult to decide what to do: create an object using the new operator or using a factory method. But over time, understanding comes. With architectural patterns, things are a little different. Enterprise frameworks are designed for the programmer to use them to create a project based on some generally accepted pattern. Therefore, before learning the Spring Framework, you definitely need to understand what client-server architecture, three-tier architecture and MVC architecture are. Don't worry: we'll talk about MVC architecture later. Part 1. What you need to know before learning Spring and JavaEE Part 3. HTTP/HTTPS protocols Part 4. Maven basics Part 5. Servlets. Writing a simple web application Part 6. Servlet containers Part 7. Introducing the MVC (Model-View-Controller) pattern Part 8. Writing a small spring-boot application