Parte 2. Hablemos un poco de arquitectura de software.

Este material es parte de la serie “ Introducción al desarrollo empresarial ”. La primera parte sobre la red está aquí . La arquitectura de software es la estructura a partir de la cual se crea una aplicación y los módulos y componentes de todo el programa interactúan. Los programadores han estado intentando crear una buena arquitectura durante mucho tiempo, por lo que no es sorprendente que ahora conozcamos muchos patrones arquitectónicos. Debe comprenderlos: cuando escribe una aplicación web, el problema de la arquitectura se vuelve grave, porque contiene más componentes y módulos que en una aplicación normal. Un patrón arquitectónico es una forma ya pensada de resolver algún problema de diseño de software. Probablemente ya te hayas encontrado con patrones de diseño como Factory Method, Abstract Factory, Builder, Prototype, Singleton y quizás otros. Se utilizan para simplemente escribir código, crear clases y planificar cómo interactúan. Los patrones arquitectónicos se utilizan en un nivel superior de abstracción: al planificar la interacción del usuario de la aplicación con el servidor, los datos y otros componentes del proyecto. Echemos un vistazo rápido a algunas plantillas y cómo usarlas.

Arquitectura cliente-servidor

Por el nombre da la impresión de que todo en este tema es sencillo y claro. Pero aclaremos algunos puntos para que cuando empieces a estudiar el Spring condicional, entiendas exactamente de qué estamos hablando. Digamos que escribiste un chat y tú y tu amigo comienzan a usarlo. Aquí es posible una opción sencilla: se envían mensajes directamente a través de Internet utilizando direcciones IP que conocen: al principio puede parecer que todo funciona bien, hasta que aparece otro amigo suyo con la pregunta: “¿Por qué no ¿No me agregas a tu chat? Y cuando decide agregar un amigo en común al chat, se enfrenta a un problema arquitectónico: cada usuario del chat necesita actualizar la información sobre el número de usuarios y agregar la dirección IP del nuevo usuario. Y al enviar un mensaje, éste debe entregarse a todos los participantes. Estos son los problemas más obvios que surgirán. Muchos más problemas estarán ocultos en el propio código. Para evitarlos, es necesario utilizar un servidor que almacene toda la información sobre los usuarios y conozca sus direcciones. Sólo será necesario enviar el mensaje al servidor. Y él, a su vez, enviará el mensaje a todos los destinatarios. Cuando decida agregar un lado del servidor a su chat, comenzará a construir una arquitectura cliente-servidor.

Componentes de la arquitectura cliente-servidor.

Averigüemos qué es ella. La arquitectura cliente-servidor es un patrón de diseño, la base para la creación de aplicaciones web. Esta arquitectura consta de tres componentes:

1. Cliente: por el nombre queda claro que se trata de un usuario de un servicio (aplicación web) que se comunica con el servidor para obtener cierta información.

2. El servidor es el lugar donde se encuentra su aplicación web o su parte del servidor. Posee la información necesaria sobre los usuarios o puede solicitarla. Además, cuando un cliente contacta, el servidor devuelve la información solicitada.

3. La red es simple: asegura el intercambio de información entre el cliente y el servidor.

El servidor puede procesar una gran cantidad de solicitudes de diferentes usuarios. Es decir, puede haber muchos clientes, y si necesitan intercambiar información entre ellos, habrá que hacerlo a través del servidor. De este modo, el servidor recibe otra función adicional: el control del tráfico. Si hablamos del chat multiusuario que creamos, todo el código del programa constará de dos módulos:

• cliente: contiene una interfaz gráfica para autorización, envío/recepción de mensajes;

• Del lado del servidor: una aplicación web que está alojada en un servidor y recibe mensajes de los usuarios, los procesa y luego los envía a los destinatarios.

Cuando queremos ver información útil (o no tan útil) en Internet, abrimos un navegador, ingresamos una consulta en la barra de búsqueda y, como respuesta, recibimos información del motor de búsqueda. En esta cadena, el navegador es nuestro cliente. Envía una solicitud con información sobre lo que estamos buscando al servidor. El servidor procesa la solicitud, encuentra los resultados más relevantes, los empaqueta en un formato comprensible para el navegador (cliente) y los devuelve. En servicios tan complejos como los motores de búsqueda puede haber muchos servidores. Por ejemplo, un servidor de autorización, un servidor para buscar información, un servidor para generar una respuesta. Pero el cliente no sabe nada de esto: para él, el servidor es algo unificado. El cliente sólo conoce el punto de entrada, es decir, la dirección del servidor al que necesita enviar la solicitud. Recordemos la aplicación que vimos en la parte anterior : para monitorear la temperatura promedio del aire en todos los países en tiempo real. Su arquitectura se verá así: Nuestra aplicación está ubicada en un servidor. Digamos que cada cinco segundos envía solicitudes a los servidores de los centros hidrometeorológicos locales, recibe de ellos información sobre la temperatura en un país en particular y almacena esta información. Cuando un cliente nos contacta con una solicitud para "ver la temperatura actual del aire en el mundo", le devolvemos la información almacenada más reciente, ordenada por país. Por lo tanto, nuestra aplicación es al mismo tiempo un servidor (cuando procesa las solicitudes de los usuarios) y un cliente (cuando recibe información de otros servidores). Una arquitectura cliente-servidor simple se utiliza muy raramente y sólo para aplicaciones muy simples. Para proyectos realmente grandes y complejos, se utilizan diferentes tipos de arquitecturas, con las que se familiarizará más en el futuro. Ahora veamos un modelo que es muy similar al modelo cliente-servidor.

Arquitectura de tres niveles

Este es un patrón arquitectónico que introduce un tercer actor: el almacén de datos . Cuando se utiliza este patrón, los tres niveles suelen denominarse capas:

1. La capa de cliente es la interfaz de usuario. Podría ser un navegador web al que se envían las páginas HTML o una aplicación GUI escrita con JavaFX. Lo principal es que con su ayuda el usuario puede enviar solicitudes al servidor y procesar sus respuestas.

2. La capa lógica es el servidor en el que se procesan las solicitudes/respuestas. A menudo también se le llama capa de servidor. Aquí también tienen lugar todas las operaciones lógicas: cálculos matemáticos, operaciones de datos, llamadas a otros servicios o almacenamiento de datos.

3. La capa de datos es el servidor de la base de datos: nuestro servidor accede a ella. Esta capa almacena toda la información necesaria que utiliza la aplicación durante su funcionamiento.

Así, nuestro servidor asume todas las obligaciones de acceso a los datos, sin permitir al usuario acceder a ellos directamente.

Beneficios de una arquitectura de tres niveles

Al utilizar dicha arquitectura, obtenemos muchas ventajas, que incluyen:

1. La capacidad de crear protección contra inyecciones SQL es un ataque al servidor en el que se transmite el código SQL, y cuando se ejecuta este código, el atacante puede afectar nuestra base de datos.

2. Delimitación de datos sobre los que queremos regular el acceso de los usuarios.

3. Posibilidad de modificar datos antes de enviarlos al cliente.

4. Escalabilidad: la capacidad de expandir nuestra aplicación a varios servidores que utilizarán la misma base de datos.

5. Menos requisitos para la calidad de la conexión del usuario. Al generar una respuesta en el servidor, a menudo tomamos mucha información diferente de la base de datos, la formateamos y dejamos solo lo que el usuario necesita. De esta forma reducimos la cantidad de información que enviamos como respuesta al cliente.

¿Con qué frecuencia debería utilizar patrones arquitectónicos?

Si está familiarizado, por ejemplo, con el patrón de diseño Factory Method , probablemente se habrá preguntado cuándo usarlo. A veces es difícil decidir qué hacer: crear un objeto usando el nuevo operador o usando un método de fábrica. Pero con el tiempo llega la comprensión. Con los patrones arquitectónicos, las cosas son un poco diferentes. Los marcos empresariales están diseñados para que el programador los utilice para crear un proyecto basado en algún patrón generalmente aceptado. Por lo tanto, antes de aprender Spring Framework, definitivamente necesita comprender qué son la arquitectura cliente-servidor, la arquitectura de tres niveles y la arquitectura MVC. No te preocupes: hablaremos de la arquitectura MVC más adelante. Parte 1. Lo que necesita saber antes de aprender Spring y JavaEE Parte 3. Protocolos HTTP/HTTPS Parte 4. Conceptos básicos de Maven Parte 5. Servlets. Escribir una aplicación web sencilla Parte 6. Contenedores de servlets Parte 7. Introducción del patrón MVC (Modelo-Vista-Controlador) Parte 8. Escribir una pequeña aplicación Spring-boot