Parte 2. Hablemos un poco sobre la arquitectura de software

Este material forma parte de la serie "Introducción al desarrollo empresarial" . La primera parte, sobre networking, está aquí . La arquitectura de software se refiere a la estructura creada dentro de una aplicación, es decir, los módulos y componentes del programa completo y cómo interactúan. Los programadores han estado trabajando en buenas arquitecturas durante mucho tiempo, por lo que no sorprende que hayamos oído hablar de muchos patrones arquitectónicos. Debe comprenderlos: al escribir una aplicación web, es fundamental crear una buena arquitectura, porque una aplicación web tiene más componentes y módulos que una aplicación normal. Un patrón arquitectónicoes una forma inteligente de resolver algún problema de diseño de software. Probablemente haya encontrado patrones de diseño como el método de fábrica, la fábrica abstracta, el constructor, el prototipo, el singleton y posiblemente otros. Los usamos para escribir código, crear clases y planificar cómo interactuarán las clases. Los patrones arquitectónicos se utilizan en un nivel más alto de abstracción cuando se planifica la interacción del usuario con servidores, datos y otros componentes. Echemos un vistazo rápido a algunos patrones y cómo usarlos.

Arquitectura cliente-servidor

El nombre crea la impresión de que todo sobre este patrón es simple y claro. Pero aclaremos algunos puntos, para que cuando empieces a estudiar Spring entiendas de lo que estamos hablando. Supongamos que ha escrito una aplicación de chat y usted y un amigo comienzan a usarla. Podría adoptar un enfoque muy simple, enviándose mensajes directamente a través de Internet utilizando direcciones IP conocidas: Al principio, aparentemente todo funciona bien hasta que otro de tus amigos pide unirse al chat. Entonces, cuando decide agregar a su amigo mutuo al chat, enfrenta un problema de arquitectura: para cada participante del chat, debe proporcionar información actual sobre la cantidad de usuarios y la dirección IP de los nuevos usuarios. Y cuando se envía un mensaje, debe entregarse a todos los participantes. Estos son los problemas más obvios que surgirán. Otro montón de problemas estarán ocultos en el código mismo. Para evitarlos, necesitas usar un servidor., que almacenará toda la información sobre los usuarios, incluidas sus direcciones. Los mensajes solo necesitan ser enviados al servidor. Este, a su vez, envía mensajes a cada uno de los destinatarios. Cuando decide agregar una parte de servidor a su aplicación de chat, está comenzando a construir una arquitectura cliente-servidor.

Componentes de la arquitectura cliente-servidor

Veamos de qué se trata. Una arquitectura cliente-servidor es un patrón de diseño utilizado para crear aplicaciones web. Esta arquitectura consta de tres componentes:

1. Cliente: por su nombre, podemos decir que este componente utiliza algún servicio (la aplicación web), contactando a un servidor para solicitar información.

2. Servidor: aquí es donde se encuentra su aplicación web o la parte del servidor. Almacena la información necesaria del usuario o puede solicitarla. Además, cuando un cliente envía una solicitud, es el servidor el que devuelve la información solicitada.

3. Red: esta parte es simple. Facilita el intercambio de información entre el cliente y el servidor.

El servidor puede manejar una gran cantidad de solicitudes de diferentes usuarios. Esto significa que puede haber muchos clientes. Si necesitan intercambiar información entre ellos, esto tiene que suceder a través del servidor. Así, el servidor tiene otra función: el control del tráfico. En lo que respecta a nuestro programa de chat multiusuario, toda la aplicación constará de dos módulos:

• un módulo de cliente: contiene una interfaz gráfica para iniciar sesión y enviar/recibir mensajes

• un módulo de 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 buscar información útil (o no muy útil) en Internet, abrimos un navegador, ingresamos una consulta en la barra de búsqueda y obtenemos información del motor de búsqueda como respuesta. En esta cadena, el navegador es el 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 que el navegador (cliente) puede entender y los devuelve. Los servicios complejos como los motores de búsqueda pueden tener muchos servidores. Por ejemplo, un servidor de autorización, un servidor para encontrar información, un servidor para generar la respuesta, etc. Pero el cliente no es consciente de nada de esto y no le preocupa: para el cliente, el servidor es una entidad unificada. El cliente solo conoce el punto de entrada, es decir, la dirección del servidor al que se deben enviar las solicitudes. Recordemos la aplicación que examinamos enla parte anterior de esta serie . Era para monitorear la temperatura promedio del aire en todos los países en tiempo real. Su arquitectura se parece a esto: Nuestra aplicación está ubicada en el servidor. Digamos que cada cinco segundos envía solicitudes a servidores operados por estaciones meteorológicas locales, recibe información de temperatura para un país en particular de los servidores y almacena esta información. Cuando el cliente nos pide que "ver la temperatura del aire actual del mundo", devolvemos la información almacenada más recientemente, ordenada por país. Así, nuestra aplicación actúa tanto como servidor (cuando procesa las solicitudes de los usuarios) como cliente (cuando recibe información de otros servidores). Una arquitectura cliente-servidor simple se usa muy raramente y solo para aplicaciones muy simples. Para proyectos realmente grandes y complejos, utilizamos diferentes arquitecturas, que conocerá en el futuro. Ahora veamos un modelo que es muy similar a la arquitectura cliente-servidor.

Arquitectura de tres niveles

Este es un patrón arquitectónico que introduce un tercer módulo: almacenamiento de datos . En este patrón, los tres niveles suelen denominarse capas o gradas:

1. La capa de cliente es la interfaz de usuario, también llamada nivel de presentación. Puede ser un navegador web que recibe páginas HTML o una interfaz gráfica de usuario escrita con JavaFX. Lo principal es que esta capa le permite al usuario enviar solicitudes al servidor y procesar sus respuestas.

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

3. La capa de datos es el servidor de la base de datos: nuestro servidor interactúa con ella. Esta capa almacena toda la información necesaria para el funcionamiento de la aplicación.

Por lo tanto, nuestro servidor asume toda la responsabilidad del acceso a los datos y no permite que el usuario acceda directamente a ellos.

Ventajas de una arquitectura de tres niveles

Una arquitectura como esta nos brinda muchas ventajas, entre ellas:

1. La capacidad de proteger contra la inyección de SQL (este es un ataque a un servidor; implica el envío de código SQL que, cuando se ejecuta, permite que un atacante afecte nuestra base de datos).

2. Separación de los datos a los que queremos controlar el acceso de los usuarios.

3. La posibilidad de modificar los datos antes de enviarlos al cliente.

4. Escalabilidad (la capacidad de expandir nuestra aplicación a múltiples servidores que usarán la misma base de datos.

5. Requisitos menos estrictos sobre la calidad de las conexiones de los usuarios. Al generar una respuesta en el servidor, a menudo obtenemos mucha información diferente de una base de datos y la formateamos, dejando solo lo que el usuario necesita. Hacer esto reduce la cantidad de información que enviamos en nuestra respuesta al cliente.

¿Con qué frecuencia se deben utilizar los patrones arquitectónicos?

Si está familiarizado, por ejemplo, con el patrón de diseño del método de fábrica , probablemente se haya preguntado cuándo usarlo. A veces es difícil decidir qué hacer: crear un objeto usando el operador new o usando un método de fábrica. Pero con el tiempo, llega la comprensión. Las cosas son un poco diferentes cuando se trata de patrones arquitectónicos. Los marcos empresariales están diseñados para permitir que un programador cree un proyecto basado en algún patrón generalmente aceptado. En consecuencia, antes de aprender Spring Framework, definitivamente debe comprender la arquitectura cliente-servidor, la arquitectura de tres niveles y la arquitectura MVC. No te preocupes: aún hablaremos de la arquitectura MVC. Parte 3. HTTP/HTTPS Parte 4. Los conceptos básicos de Maven Parte 5. Servlets y la API de Java Servlet. Escribiendo una aplicación web simple Parte 6. Contenedores de Servlet Parte 7. Introducción al patrón MVC (Modelo-Vista-Controlador)