Documento Técnico: Definición de la Arquitectura de la Plataforma

Autores

PhD. Miguel Enrique Iglesias Martínez. Director de transferencia de conocimiento y tecnología del Proyecto Hub Ambiental del Caribe – ENERGESIS.

Mg. Cesar Enrique Polo Castro. Líder de desarrollo de software del Proyecto Hub Ambiental del Caribe – Universidad del Magdalena.

Mg. Luis José Castrillo Fernández. Asesor técnico en desarrollo de software del Proyecto Hub Ambiental del Caribe – Universidad del Magdalena.

Revisado por:

PhD. John Alexander Taborda Giraldo. Director del Proyecto Hub Ambiental del Caribe – Universidad del Magdalena.

PhD. Luis Leonardo Camargo Ariza. Docente tiempo completo – Universidad del Magdalena.

📌 Edición Preprint – 27 de febrero de 2025 Este documento ha sido publicado en formato preprint como parte de la iniciativa de Ciencia Abierta del Hub Ambiental del Caribe.

💡 Licencia Creative Commons

Este LIDIMEDIA está licenciado bajo una Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0). Esto significa que:

✅ Puede ser compartido (copiado y redistribuido en cualquier medio o formato).

✅ Puede ser adaptado (remezclado, transformado y construido a partir del material).

❌ No se permite su uso comercial.

🔗 Las obras derivadas deben mantenerse bajo la misma licencia.

Al utilizar este documento, se debe otorgar el crédito correspondiente a los autores y al Hub Ambiental del Caribe, incluyendo un enlace a esta licencia e indicando si se han realizado cambios.

📍 Publicación desarrollada por la Universidad del Magdalena en el marco del proyecto financiado por el Fondo CTeI del Sistema General de Regalías, identificado con el BPIN 2023000100072 – HUB AMBIENTAL DEL CARIBE “Implementación de una plataforma de datos abiertos basada en AIoT para el análisis y gestión de riesgos ambientales y climáticos en el corredor minero de los municipios La Jagua de Ibirico, Albania, Algarrobo”.

📌 Más información sobre esta licencia en:

🔗 https://creativecommons.org/licenses/by-nc-sa/4.0/deed.es

📧 Contacto: hac@unimagdalena.edu.co

🌍 Web: https://hubambientaldelcaribe.co/

📍 Santa Marta, Colombia – 2025

Definición de la Arquitectura de la Plataforma

En el marco del proyecto “Implementación de una plataforma de datos abiertos basado en AIoT para el análisis y la gestión de riesgos ambientales y climáticos en el corredor minero de los municipios de la Jagua de Ibirico, Albania, Algarrobo”, más conocido como HUB Ambiental del Caribe, identificado con el BPIN 2023000100072, se realizó la construcción del documento técnico definición de la arquitectura de la plataforma.

Este documento define los patrones que darán el marco de referencia necesario para guiar la construcción de la arquitectura de la plataforma, en atención a las especificaciones técnicas y funcionales que se han trabajado en los documentos técnicos “Requisitos del software” e “Interfaces de la plataforma”, de manera que se logre el cumplimiento al alcance establecido por el proyecto y a las necesidades identificadas por cada una de las partes interesadas.

De acuerdo con lo anterior se presenta la propuesta de la visión general en la arquitectura de la plataforma y sus características, así como las líneas de trabajo para cumplir con todos los objetivos y restricciones.

Arquitectura de la plataforma de datos abiertos basado en AIoT para el análisis y la gestión de riesgos ambientales y climáticos

Patrones arquitectónicos

El sistema actual, diseñado bajo una arquitectura monolítica con servicios REST, muestra un enfoque inicial de integración entre sus diferentes capas principales. Aunque funcional, esta arquitectura refleja un avance parcial y se encuentra en proceso de evolución hacia una solución más escalable y robusta. A continuación, se detalla en profundidad la estructura, los componentes principales y los patrones arquitectónicos implementados:

1. Arquitectura General

Backend Monolítico

El backend centraliza la lógica de negocio de la plataforma, siendo el núcleo principal del sistema. Este componente incluye las siguientes características:

• Framework: Desarrollado en Laravel, un framework de PHP que permite la construcción rápida y estructurada de aplicaciones web.
• Exposición de Servicios RESTful:
  • Define endpoints para gestionar las solicitudes provenientes del frontend, facilitando la interacción con el sistema.
  • Incluye operaciones CRUD básicas para consultar y administrar datos almacenados en la base de datos PostgreSQL.
• Gestión de Lógica de Negocio:
  • Control centralizado de validaciones y reglas del sistema.
  • Módulos para procesar datos enviados por el frontend o integraciones externas.
• Limitaciones Actuales:
  • Dependencia del enfoque monolítico, que puede dificultar la escalabilidad y mantenimiento a medida que el sistema crece.
  • Falta de separación modular para manejar funcionalidades críticas, como la integración con Thingsboard y análisis avanzado.

Frontend Separado

El frontend se encarga de la interacción con los usuarios y la representación visual de los datos.

• Framework: Implementado con Angular, una plataforma moderna basada en TypeScript para construir interfaces web dinámicas.
• Consumo de Servicios REST:
  • Realiza llamadas HTTP al backend Laravel para obtener y mostrar información.
  • Maneja la autenticación y el manejo de errores en la interacción con los endpoints RESTful.
• Visualización Interactiva:
  • Google Maps API: Integrada para mostrar información geoespacial. Esto permite a los usuarios visualizar datos de estaciones AIoT en un mapa, como ubicaciones, registros ambientales y variables en tiempo real.
• Limitaciones Actuales:
  • Funcionalidades limitadas a visualización básica y consultas simples.
  • Dependencia total del backend para procesar datos, limitando la capacidad de realizar operaciones avanzadas directamente desde el frontend.

Base de Datos

El sistema utiliza PostgreSQL como motor principal de almacenamiento de datos:

• Gestión de Datos:
  • Manejo de datos estructurados relacionados con estaciones AIoT, variables ambientales y registros históricos.
  • Almacenamiento optimizado para consultas básicas.
• Consultas Avanzadas:
  • Aunque funcional, las consultas complejas, como análisis de tendencias o predicciones basadas en datos históricos, aún no están implementadas.
  • La estructura de índices y optimización para grandes volúmenes de datos está en desarrollo.

Thingsboard (IoT)

Thingsboard es el módulo IoT que gestiona la recepción y visualización inicial de datos provenientes de dispositivos conectados:

• Flujo de Datos:
  • Las estaciones AIoT transmiten datos a través de conexiones Wi-Fi, LTE o LoRa hacia Thingsboard.
  • Thingsboard actúa como un intermediario, procesando y mostrando la información de las estaciones en tiempo real.
• Almacenamiento Parcial:
  • Thingsboard almacena temporalmente los datos antes de que sean integrados completamente con el backend.
• Integración en Proceso:
  • Actualmente, la comunicación directa entre Thingsboard y el backend Laravel está en fase de desarrollo. Esto incluirá sincronización bidireccional y procesamiento avanzado.

2. Flujo de Comunicación

El flujo de comunicación del sistema sigue un esquema simplificado que conecta el frontend, backend y el módulo IoT:

1. Frontend:
   • Angular envía solicitudes HTTP al backend utilizando servicios REST.
   • Consume los datos recibidos del backend para actualizar las vistas de usuario.
2. Backend:
   • Laravel recibe las solicitudes, procesa la lógica de negocio y realiza consultas a PostgreSQL.
   • Devuelve las respuestas al frontend, incluidas las visualizaciones de datos geoespaciales.
3. Thingsboard:
   • Recibe datos de las estaciones AIoT a través de tecnologías de conectividad (Wi-Fi, LTE o LoRa).
   • Permite una visualización preliminar de los datos antes de que sean procesados por el backend.
   • Almacena datos parcialmente en su base interna.

3. Patrones Arquitectónicos Implementados

El sistema emplea varios patrones arquitectónicos fundamentales para su funcionamiento:

a. IoT Básico

• Descripción: Configuración inicial para recopilar y transmitir datos de estaciones AIoT hacia Thingsboard.
• Flujo:
  • Las estaciones AIoT están equipadas con sensores que capturan datos ambientales y climáticos.
  • Los datos se transmiten a través de Gateways configurados en Thingsboard.
• Limitaciones:
  • Actualmente, Thingsboard opera de manera aislada del backend principal, lo que limita la centralización y procesamiento avanzado de los datos.

b. Arquitectura Monolítica

• Backend: El enfoque monolítico centraliza toda la lógica de negocio, simplificando la implementación inicial, pero limitando la escalabilidad.
• Patrones Aplicados:
  • Modelo-Vista-Controlador (MVC): Laravel organiza el código en modelos (para la lógica de datos), vistas (interfaces de usuario) y controladores (lógica de procesamiento).
  • RESTful API: Permite que el backend exponga servicios para ser consumidos por el frontend.
• Consideraciones Futuras:
  • Migrar hacia una arquitectura basada en microservicios para mejorar la modularidad y escalabilidad.

c. Integración Geoespacial

• Google Maps API:
  • Permite la visualización de ubicaciones en tiempo real.
  • Muestra datos dinámicos de sensores IoT, como variables ambientales por ubicación.
• Arquitectura de Frontend:
  • Diseño modular en Angular, compatible con múltiples vistas y flujos de trabajo.

4. Limitaciones y Futuro Desarrollo

Aunque el sistema tiene un diseño funcional, existen áreas clave que requieren mejoras:

1. Integración Completa con Thingsboard:
   • Conectar el backend directamente a Thingsboard para procesar y centralizar todos los datos IoT.
   • Implementar pipelines de datos para analizar y predecir patrones en tiempo real.
2. Optimización de Consultas en PostgreSQL:
   • Desarrollar consultas avanzadas e índices que permitan análisis más eficientes de grandes volúmenes de datos.
3. Escalabilidad:
   • Adoptar una arquitectura de microservicios para distribuir la carga entre componentes, facilitando la adición de nuevas funcionalidades.

Blackboard

El modelo Blackboard, un enfoque arquitectónico que funciona como un hub central de información, ha sido implementado parcialmente en la plataforma como base para la integración, procesamiento y análisis de datos provenientes de múltiples fuentes. Este modelo centraliza los datos IoT, permitiendo que diferentes componentes del sistema interactúen con una fuente de verdad compartida, promoviendo la coherencia y eficiencia en el análisis de riesgos ambientales y climáticos. A continuación, se describe con detalle su funcionamiento, el estado actual y los planes de evolución

1. Concepto del Modelo Blackboard

El modelo Blackboard es un patrón arquitectónico diseñado para gestionar sistemas complejos en los que múltiples módulos contribuyen al procesamiento de datos en un espacio compartido:

• Función Principal: Actuar como un repositorio central donde se consolidan los datos provenientes de diversas fuentes, permitiendo que otros componentes accedan, analicen y realicen acciones basadas en esta información.
• Interoperabilidad: Sirve como intermediario para integrar dispositivos AIoT, gateways, bases de datos y módulos de análisis en tiempo real.

En esta plataforma, Thingsboard es el componente principal que implementa el modelo Blackboard, al menos en su etapa inicial.

2. Rol de Thingsboard en el Modelo Blackboard

Thingsboard se configura como el punto central del modelo Blackboard, desempeñando funciones clave para el procesamiento y visualización preliminar de datos IoT.

a. Fuentes de Datos Conectadas a Thingsboard

• Dispositivos IoT:
  • Sensores individuales que capturan variables ambientales y climáticas como temperatura, humedad, presión atmosférica y calidad del aire.
  • Conexiones:
    • Wi-Fi: Para áreas urbanas o semiurbanas con infraestructura disponible.
    • LTE: Utilizado en áreas donde la cobertura móvil es consistente.
    • LoRa: Ideal para regiones remotas, dada su capacidad para transmitir datos a larga distancia con bajo consumo energético.
• Gateways:
  • Consolidan datos de múltiples estaciones AIoT.
  • Actúan como intermediarios que procesan y envían datos al servidor Thingsboard, asegurando la continuidad y eficiencia en la transmisión.

b. Flujo Actual de Datos

• Los datos recopilados por Thingsboard están disponibles parcialmente para ser visualizados en su interfaz nativa.
• Estado de Procesamiento:
  • Thingsboard organiza y almacena los datos, pero aún no realiza análisis avanzados ni proporciona acceso total al backend (Laravel) para su exposición completa.
  • La información disponible es básica y no está completamente integrada en el sistema de análisis principal.

3. Flujo de Datos Actual del Modelo Blackboard

El modelo Blackboard sigue un flujo simplificado en su etapa inicial:

1. Captura de Datos:
   • Los dispositivos IoT y gateways envían información directamente a Thingsboard.
   • Las conexiones Wi-Fi, LTE y LoRa aseguran la transmisión desde áreas diversas.
2. Procesamiento en Thingsboard:
   • Los datos se organizan y son accesibles a través de su interfaz gráfica para una visualización preliminar.
3. Pendiente de Integración:
   • Aún no se ha completado la integración bidireccional entre Thingsboard y el backend Laravel.
   • Los datos procesados por Thingsboard no están disponibles para análisis avanzado o visualización en el frontend (Angular).

4. Estado Actual del Modelo Blackboard

El modelo Blackboard se encuentra en una etapa inicial con las siguientes características:

• Capacidades Actuales:
  • Consolidación básica de datos IoT en un único repositorio (Thingsboard).
  • Visualización parcial de información a través de Thingsboard.
• Limitaciones:
  • Falta de integración directa con el backend Laravel, lo que limita la exposición completa de datos al sistema.
  • No se han implementado mecanismos de análisis avanzado ni correlación de datos en el hub central.

Modelo entre Capas

El modelo entre capas organiza la arquitectura del sistema en tres niveles claramente definidos: Capa de Presentación, Capa de Lógica de Negocio y Capa de Datos. Este diseño asegura una separación de responsabilidades que mejora la modularidad, escalabilidad y mantenibilidad del sistema, permitiendo una evolución controlada y eficiente. A continuación, se detalla cada una de las capas y su interacción.

1. Capa de Presentación (Frontend – Angular)

La capa de presentación es la interfaz visible y accesible para los usuarios finales. Está diseñada para ofrecer una experiencia intuitiva y eficiente, permitiendo la interacción directa con las funcionalidades del sistema.

Características Principales:

• Framework Utilizado: Angular, una plataforma basada en TypeScript que facilita el desarrollo de aplicaciones web dinámicas y escalables.
• Funciones Clave:
  • Interfaz de Usuario (UI):
    • Diseño interactivo y responsivo que permite a los usuarios acceder al sistema desde dispositivos móviles, tablets o escritorios.
    • Tableros de control que muestran gráficos, tablas y mapas con datos en tiempo real.
  • Consumo de Servicios REST:
    • Realiza solicitudes HTTP al backend (Laravel) para obtener datos y enviar actualizaciones.
    • Maneja respuestas JSON para mostrar información procesada.
  • Integración Geoespacial:
    • Uso de Google Maps API para visualizar datos geoespaciales, como la ubicación de estaciones AIoT y sus variables ambientales asociadas.
• Gestión de Estado:
  • Implementación de servicios y componentes en Angular para gestionar el estado de la aplicación y minimizar redundancias en el manejo de datos.

Flujo de Trabajo:

1. El usuario realiza acciones en la interfaz, como consultar datos, generar reportes o visualizar mapas.
2. Angular envía solicitudes HTTP al backend.
3. Una vez que el backend responde, Angular actualiza dinámicamente la interfaz para reflejar los cambios.

Ventajas:

• Independencia respecto al backend, permitiendo que el frontend pueda evolucionar sin afectar la lógica central del sistema.
• Capacidad para interactuar con múltiples fuentes de datos mediante APIs RESTful.

2. Capa de Lógica de Negocio (Backend – Laravel)

La capa de lógica de negocio es el núcleo del sistema, encargada de procesar, gestionar y coordinar todas las operaciones entre la capa de presentación y la capa de datos.

Características Principales:

• Framework Utilizado: Laravel, un framework de PHP conocido por su simplicidad, seguridad y flexibilidad.
• Funciones Clave:
  • Gestión de Lógica de Negocio:
    • Implementa reglas y validaciones que garantizan la consistencia y coherencia de los datos procesados.
    • Coordina flujos de trabajo, como la integración de datos IoT desde Thingsboard.
  • Exposición de Servicios RESTful:
    • Define una serie de endpoints API que permiten a la capa de presentación interactuar con la base de datos y otras funcionalidades.
    • Maneja operaciones CRUD para consultas y actualizaciones de datos.
  • Procesamiento de Datos:
    • Transforma los datos recibidos de Thingsboard o PostgreSQL en formatos comprensibles y útiles para el frontend.
    • Implementación de funciones básicas de análisis, como agregación de datos y cálculo de estadísticas.
  • Integración con Thingsboard:
    • Comunicación con el sistema IoT para recibir y sincronizar datos en tiempo real.

Flujo de Trabajo:

1. Recibe solicitudes del frontend a través de servicios REST.
2. Procesa la solicitud, aplica la lógica de negocio y consulta actualiza la base de datos.
3. Devuelve una respuesta estructurada al frontend.

Ventajas:

• Centralización de la lógica del sistema en un único lugar, facilitando el mantenimiento.
• Modularidad que permite integrar nuevas funcionalidades sin afectar componentes existentes.

3. Capa de Datos (PostgreSQL)

La capa de datos es el sistema de almacenamiento del modelo, encargado de gestionar de manera eficiente los datos estructurados y semiestructurados del sistema.

Características Principales:

• Sistema de Gestión de Bases de Datos: PostgreSQL, una base de datos relacional robusta y de código abierto.
• Funciones Clave:
  • Almacenamiento de Datos Estructurados:
    • Registros de estaciones AIoT, como ubicación, variables ambientales y métricas recolectadas.
    • Información histórica que permite análisis de tendencias y predicciones.
  • Consultas SQL:
    • Soporte para consultas complejas, incluyendo agregaciones, uniones y subconsultas.
  • Optimización:
    • Uso de índices para mejorar el rendimiento en consultas frecuentes.
    • Capacidad para manejar grandes volúmenes de datos sin comprometer la velocidad o estabilidad.
• Seguridad:
  • Control de acceso mediante autenticación y privilegios específicos para proteger los datos sensibles.

Flujo de Trabajo:

1. El backend realiza consultas a PostgreSQL para recuperar o almacenar datos.
2. PostgreSQL procesa las consultas y devuelve los resultados al backend.
3. Los datos son procesados por Laravel antes de ser enviados al frontend.

Ventajas:

• Escalabilidad para manejar el crecimiento en el volumen de datos.
• Compatibilidad con integraciones avanzadas, como análisis de datos IoT en tiempo real.

4. Integración entre las Capas

La interacción entre las tres capas sigue un flujo estructurado que garantiza una comunicación eficiente y consistente:

1. Capa de Presentación:
   • Inicia la comunicación con el backend mediante solicitudes HTTP, enviando datos o solicitando información.
2. Capa de Lógica de Negocio:
   • Procesa las solicitudes recibidas, aplicando validaciones y transformaciones necesarias.
   • Consulta la capa de datos para obtener información o almacenar nuevos registros.
3. Capa de Datos:
   • Responde a las consultas del backend con datos estructurados que luego son procesados y enviados al frontend.

Interprete

El concepto de intérprete dentro de esta arquitectura es clave para transformar datos brutos en información estructurada, comprensible y visualmente útil para los usuarios. Este proceso se lleva a cabo en tres niveles principales, cada uno de los cuales cumple un papel específico: Thingsboard como intérprete IoT, Backend Laravel como intérprete secundario, y Frontend Angular como intérprete de visualización. A continuación, se detallan sus funciones y contribuciones en el flujo de datos.

1. Thingsboard como Intérprete IoT

Thingsboard actúa como el primer nivel del intérprete, procesando los datos directamente desde las estaciones AIoT y convirtiéndolos en información preliminar que puede ser visualizada y utilizada.

a. Recopilación de Datos.

• Orígenes de los Datos:
  • Estaciones AIoT equipadas con sensores para capturar variables ambientales clave como temperatura, humedad relativa, presión atmosférica y calidad del aire.
• Conexiones Utilizadas:
  • Wi-Fi: Adecuado para áreas con infraestructura disponible.
  • LTE: Garantiza la conectividad en regiones con buena cobertura de redes móviles.
  • LoRa: Optimizado para zonas remotas o de difícil acceso, gracias a su bajo consumo energético y largo alcance.
• Gateways:
  • Actúan como intermediarios para consolidar y transmitir datos desde múltiples estaciones hacia Thingsboard.

b. Procesamiento Inicial

• Organización y Estructuración:
  • Thingsboard clasifica y almacena los datos recibidos en un formato estructurado, permitiendo consultas y análisis preliminares.
• Visualización en Tiempo Real:
  • Dashboards integrados muestran los datos de manera interactiva, lo que permite a los usuarios monitorear variables en tiempo real.
• Conversión de Datos Brutos:
  • Los valores capturados por los sensores son procesados para convertirlos en información comprensible. Por ejemplo:
    • Valores numéricos de temperatura se convierten en gráficos de tendencias.
    • Registros de calidad del aire se presentan con indicadores de estado (bueno, moderado, malo).

c. Limitaciones Actuales

• Aunque Thingsboard organiza y presenta datos de manera básica, carece de la capacidad para realizar análisis avanzados o integrar datos históricos, lo que requiere intervención del backend.

2. Backend Laravel como Intérprete Secundario

El backend desarrollado en Laravel asume un rol crítico como intérprete secundario, al realizar procesos más complejos sobre los datos integrados desde Thingsboard y combinarlos con otras fuentes.

a. Integración de Datos desde Thingsboard

• Importación de Datos:
  • Laravel se conecta a Thingsboard para recuperar los datos procesados inicialmente.
• Complementación con Información Adicional:
  • El backend consulta la base de datos PostgreSQL para añadir contexto, como datos históricos, configuraciones específicas o variables ambientales adicionales.

b. Procesamiento Avanzado

• Lógica de Negocio:
  • Aplicación de cálculos específicos requeridos para generar indicadores de riesgo ambiental.
  • Implementación de filtros para segmentar datos por región, fecha o tipo de variable.
• Generación de Reportes:
  • Creación de informes consolidados que combinan datos en tiempo real y análisis históricos.
  • Automatización de procesos para producir resúmenes periódicos (diarios, semanales, mensuales).
• Análisis Avanzado:
  • Uso de algoritmos básicos para detectar patrones o tendencias iniciales que puedan ser utilizados para alertas o predicciones.

c. Exposición de Resultados

• Servicios RESTful:
  • Los resultados procesados se exponen mediante endpoints API, que pueden ser consumidos por el frontend para su visualización.
• Formato Estandarizado:
  • Laravel transforma los datos en formatos compatibles con el frontend (JSON, XML) para garantizar la interoperabilidad.

3. Frontend Angular como Intérprete de Visualización

El frontend, implementado en Angular, actúa como el último nivel del intérprete, transformando los datos procesados en representaciones visuales que los usuarios pueden comprender fácilmente y utilizar para tomar decisiones informadas.

a. Consumo de Servicios RESTful

• Recepción de Datos:
  • Angular realiza solicitudes al backend para obtener datos procesados y listos para su representación.
• Actualización Dinámica:
  • Los datos recibidos son utilizados para actualizar la interfaz en tiempo real, sin necesidad de recargar la página.

b. Visualización de Datos

• Gráficos Interactivos:
  • Angular utiliza bibliotecas gráficas (como Chart.js o D3.js) para generar gráficos de tendencias, barras o dispersión que representan las variables monitoreadas.
• Mapas Dinámicos:
  • Google Maps API permite la visualización geoespacial de los datos, como la ubicación de estaciones AIoT, áreas de riesgo o zonas de impacto.
  • Representaciones en tiempo real de indicadores como calidad del aire, precipitaciones o temperaturas, utilizando colores e iconografía intuitiva.
• Vistas Amigables:
  • Tableros de control personalizados que resumen información clave para diferentes tipos de usuarios (técnicos, gestores o público general).

c. Interactividad

• Filtros y Personalización:
  • Los usuarios pueden aplicar filtros para visualizar datos específicos (por ejemplo, por fecha, región o tipo de variable).
• Alertas Visuales:
  • Indicadores en tiempo real para notificar condiciones críticas, como altos niveles de contaminación o riesgos climáticos inminentes.

4. Flujo General del Proceso de Interpretación

El proceso de interpretación sigue una secuencia fluida a través de las tres capas:

1. Thingsboard: Recopila y organiza datos brutos, presentándolos de forma básica y en tiempo real.
2. Laravel: Complementa los datos con información adicional, aplica lógica de negocio avanzada y expone los resultados mediante APIs RESTful.
3. Angular: Representa la información procesada en vistas dinámicas, interactivas y geoespaciales para el usuario final.

5. Beneficios del Enfoque de Interpretación Multinivel

• Transformación Completa de Datos:
  • Desde datos brutos capturados por sensores hasta representaciones visuales útiles y accesibles.
• Modularidad:
  • Cada nivel del intérprete se especializa en funciones específicas, lo que mejora la flexibilidad y mantenibilidad del sistema.
• Escalabilidad:
  • La estructura permite la integración de nuevos sensores, módulos de backend o mejoras en la interfaz de usuario sin alterar significativamente el flujo existente.
• Interoperabilidad:
  • Los datos estructurados en cada nivel pueden ser reutilizados o compartidos fácilmente con otros sistemas.

Orientado a servicios

La arquitectura del sistema implementa principios de orientación a servicios (SOA), donde los servicios RESTful actúan como el núcleo de la comunicación y la integración entre componentes. Este enfoque promueve la separación de responsabilidades, el desacoplamiento de los módulos y la interoperabilidad, facilitando el mantenimiento, la escalabilidad y la evolución del sistema. A continuación, se describe en detalle la implementación y ventajas de este modelo arquitectónico.

1. Servicios RESTful

Los servicios RESTful son fundamentales para permitir que los diferentes componentes del sistema (frontend, backend, Thingsboard y dispositivos AIoT) se comuniquen entre sí de manera eficiente y estructurada. Estos servicios son gestionados principalmente por el backend desarrollado en Laravel y son consumidos por otros módulos.

a. Funciones Clave de los Servicios RESTful

1. Consultas y Operaciones sobre la Base de Datos PostgreSQL:
   • Los endpoints permiten realizar operaciones CRUD (Create, Read, Update, Delete) sobre las tablas gestionadas en PostgreSQL.
   • Ejemplos:
     • Consultar datos históricos de variables ambientales.
     • Insertar nuevos registros de eventos climáticos.
     • Actualizar configuraciones de estaciones IoT.
     • Eliminar datos obsoletos o duplicados.
2. Provisión de Datos Ambientales y Climáticos:
   • Los servicios RESTful proporcionan acceso a datos en tiempo real y agregados, como:
     • Mediciones actuales de sensores (temperatura, humedad, presión, calidad del aire).
     • Análisis históricos y tendencias climáticas.
     • Alertas generadas a partir de datos IoT.
3. Integración con Thingsboard:
   • Laravel expone endpoints que actúan como intermediarios para consultar y procesar datos provenientes de Thingsboard.
   • Funciones soportadas:
     • Acceso a datos IoT recopilados en Thingsboard.
     • Sincronización de información entre Thingsboard y la base de datos PostgreSQL.
     • Procesamiento adicional sobre los datos recopilados.

b. Diseño de Endpoints RESTful

• Estructura de URLs:
  • Segura y predecible, basada en recursos.
  • Ejemplos:
    • GET /api/sensors – Obtener la lista de sensores disponibles.
    • POST /api/sensors/data – Subir datos de sensores.
    • GET /api/analytics/climate – Recuperar análisis climáticos.
    • DELETE /api/sensors/{id} – Eliminar un sensor específico.
• Estándares de Respuesta:
  • Formato JSON para asegurar interoperabilidad.
  • Estructura consistente con códigos de estado HTTP:
    • 200: Éxito.
    • 404: Recurso no encontrado.
    • 500: Error interno del servidor.

c. Seguridad en los Servicios RESTful

• Autenticación y Autorización:
  • Uso de tokens JWT (JSON Web Tokens) para autenticar las solicitudes.
  • Control de acceso basado en roles (por ejemplo, administrador, usuario general).
• Cifrado de Datos:
  • HTTPS asegura la transmisión segura entre componentes.

2. Desacoplamiento del Sistema

El uso de servicios RESTful promueve un desacoplamiento fuerte entre los módulos del sistema, permitiendo que cada componente opere de manera independiente y se comunique mediante APIs. Esto mejora la flexibilidad y facilita la integración de nuevos módulos en el futuro.

a. Interacción entre Componentes

1. Frontend (Angular):
   • Angular consume los endpoints expuestos por el backend para obtener y enviar datos. Ejemplo:
     • Solicitar datos ambientales para mostrarlos en gráficos y mapas.
     • Enviar configuraciones del usuario, como filtros o preferencias de visualización.
   • Beneficios:
     • El frontend no necesita acceso directo a la base de datos ni a Thingsboard, lo que mejora la seguridad y simplifica su diseño.
2. Thingsboard:
   • Thingsboard funciona como un productor de datos IoT, integrándose con el backend mediante servicios REST o a través de la sincronización directa.
   • El backend procesa y organiza la información de Thingsboard antes de exponerla al frontend.
3. Dispositivos IoT:
   • Los dispositivos IoT envían datos a Thingsboard, que los almacena y procesa parcialmente antes de compartirlos con el backend para análisis avanzado.

3. Flujo de Comunicación

La comunicación entre los componentes del sistema sigue un flujo bien definido:

1. Desde los Dispositivos IoT:
   • Los sensores capturan datos ambientales y los transmiten a Thingsboard mediante tecnologías como Wi-Fi, LTE o LoRa.
   • Thingsboard organiza y visualiza estos datos en tiempo real.
2. Desde Thingsboard al Backend:
   • Laravel consume los datos de Thingsboard mediante APIs RESTful para realizar cálculos adicionales y almacenarlos en PostgreSQL.
   • El backend expone estos datos procesados como servicios para el frontend.
3. Desde el Backend al Frontend:
   • Angular solicita datos mediante servicios RESTful, que son presentados en forma de gráficos, mapas y vistas dinámicas.

4. Ventajas de la Arquitectura SOA Basada en RESTful

a. Escalabilidad

• La separación de responsabilidades permite agregar nuevos servicios o módulos sin impactar negativamente los existentes.
• Ejemplo: Añadir un nuevo módulo de análisis predictivo que consuma los datos del backend.

b. Flexibilidad

• Los servicios RESTful pueden ser consumidos no solo por el frontend, sino también por otros sistemas externos o integraciones de terceros.

c. Mantenibilidad

• Los cambios en un módulo (como el backend) no afectan directamente a otros componentes, gracias al desacoplamiento.

d. Reutilización

• Los servicios RESTful expuestos por el backend pueden ser reutilizados para diferentes propósitos, como:
  • Generación de reportes automáticos.
  • Acceso por aplicaciones móviles.

e. Interoperabilidad

• El uso de estándares abiertos como JSON y HTTPS asegura que los componentes del sistema puedan integrarse fácilmente con tecnologías heterogéneas.

5. Proyecciones Futuras

El sistema tiene potencial para expandirse y mejorar la arquitectura RESTful en las siguientes áreas:

1. Microservicios:
   • Migrar componentes clave del backend hacia una arquitectura de microservicios, mejorando la escalabilidad.
2. API Gateway:
   • Implementar un Gateway para gestionar todas las solicitudes RESTful, proporcionando balanceo de carga, autenticación centralizada y análisis de tráfico.
3. Mejoras en Seguridad:
   • Adopción de estándares avanzados como OAuth 2.0 para control de acceso.
4. Optimización de Endpoints:
   • Incorporar paginación, filtros y ordenamiento para optimizar la transferencia de datos en grandes volúmenes.

La arquitectura del sistema basada en servicios RESTful proporciona una solución robusta y flexible para la integración y comunicación entre componentes. Al desacoplar el frontend, backend y Thingsboard, el sistema se beneficia de una estructura modular, escalable y fácilmente mantenible, adecuada para la gestión de riesgos ambientales y climáticos en tiempo real. Esta base ofrece un camino claro para futuras expansiones y mejoras tecnológicas.

Cliente – Servidor

El modelo cliente-servidor es la base de la arquitectura del sistema, permitiendo una comunicación eficiente y estructurada entre el frontend (cliente) y el backend (servidor). Este paradigma organiza el flujo de datos y las operaciones del sistema en dos roles diferenciados: el cliente, que solicita recursos y servicios, y el servidor, que responde a esas solicitudes procesando la lógica de negocio y accediendo a la base de datos o sistemas integrados. A continuación, se detalla cómo opera este modelo en el contexto del sistema.

1. Comunicación Funcional Mediante HTTP

El Hypertext Transfer Protocol (HTTP) actúa como el protocolo de comunicación estándar entre el cliente (frontend) y el servidor (backend). La interacción entre ambos componentes sigue un patrón de solicitud y respuesta:

a. Solicitudes desde el Cliente (Frontend – Angular)

1. Métodos HTTP Utilizados:
   • GET: Solicita datos del servidor, como información climática, variables ambientales o configuraciones del sistema.
   • POST: Envía datos al servidor para su procesamiento, como formularios, configuraciones del usuario o registros de eventos.
   • PUT/PATCH: Actualiza recursos existentes, como modificaciones en configuraciones de sensores.
   • DELETE: Elimina recursos específicos, como datos obsoletos o registros innecesarios.
2. Estructura de Solicitudes:
   • Encabezados (Headers):
     • Información sobre el tipo de contenido (Content-Type: application/json).
     • Tokens de autenticación para verificar permisos del usuario.
   • Cuerpo (Body): Contiene los datos que el cliente envía al servidor, generalmente en formato JSON.

b. Respuestas desde el Servidor (Backend – Laravel)

1. Códigos de Estado HTTP:
   • 200 OK: La solicitud se procesó correctamente.
   • 201 Created: Un nuevo recurso se creó con éxito.
   • 400 Bad Request: La solicitud contiene errores o está mal formada.
   • 401 Unauthorized: El usuario no está autenticado.
   • 404 Not Found: El recurso solicitado no existe.
   • 500 Internal Server Error: Ocurrió un error en el servidor.
2. Formato de Respuesta:
   • Los datos son enviados al cliente en formato JSON, asegurando la interoperabilidad y facilidad de procesamiento.

2. Roles en el Modelo Cliente-Servidor

a. Cliente (Frontend – Angular)

El cliente es el punto de interacción del usuario final con el sistema. Realiza solicitudes HTTP al backend para obtener datos, ejecutar operaciones y enviar información.

• Responsabilidades:
  • Presentar una interfaz gráfica (UI) intuitiva y amigable.
  • Solicitar datos al servidor y procesar las respuestas para mostrarlas al usuario.
  • Enviar solicitudes al backend basadas en acciones del usuario, como configuraciones de filtros o generación de reportes.
• Ejemplo de Comunicación:
  • El usuario solicita ver un gráfico de temperatura en una región específica.
  • Angular realiza una solicitud GET al endpoint https://api.example.com/temperature?region=norte.
  • Recibe los datos en JSON y genera un gráfico dinámico.

b. Servidor (Backend – Laravel)

El servidor procesa las solicitudes del cliente, aplica la lógica de negocio y accede a la base de datos o sistemas externos para generar las respuestas.

• Responsabilidades:
  • Procesar solicitudes HTTP recibidas del cliente.
  • Ejecutar operaciones en la base de datos PostgreSQL.
  • Integrarse con Thingsboard para obtener datos IoT en tiempo real.
  • Devolver respuestas estructuradas y procesadas al cliente.
• Ejemplo de Operación:
  • El servidor recibe una solicitud para obtener datos climáticos históricos.
  • Consulta la base de datos PostgreSQL, filtra los datos según la solicitud y los devuelve al cliente en JSON.

3. Flujo de Comunicación Cliente-Servidor

El flujo de comunicación sigue estos pasos:

1. Solicitud del Cliente:
   • Angular envía una solicitud HTTP al backend para obtener datos o ejecutar operaciones.
2. Procesamiento en el Servidor:
   • Laravel procesa la solicitud:
     • Valida los datos enviados.
     • Ejecuta la lógica de negocio asociada.
     • Realiza consultas o actualizaciones en PostgreSQL o se integra con Thingsboard.
   • Genera una respuesta en formato JSON.
3. Respuesta al Cliente:
   • Laravel envía la respuesta al cliente con los datos o el resultado de la operación.
4. Visualización de la Información:
   • Angular utiliza los datos recibidos para actualizar la interfaz de usuario de manera dinámica.

4. Beneficios del Modelo Cliente-Servidor

a. Separación de Responsabilidades

• El frontend se especializa en la presentación y experiencia de usuario.
• El backend se enfoca en la lógica de negocio, gestión de datos y seguridad.

b. Escalabilidad

• Cada componente (cliente y servidor) puede evolucionar o escalarse de manera independiente, por ejemplo:
  • Añadiendo nuevos endpoints en el backend.
  • Mejorando la interfaz gráfica en el frontend.

c. Interoperabilidad

• El uso de servicios RESTful y formato JSON permite que el backend pueda ser consumido no solo por el frontend Angular, sino también por aplicaciones móviles, sistemas de terceros o herramientas de análisis.

d. Seguridad Mejorada

• La autenticación y autorización se manejan en el backend, protegiendo los recursos del sistema.
• El frontend no interactúa directamente con la base de datos, lo que reduce riesgos.

5. Consideraciones para Optimizar el Modelo Cliente-Servidor

a. Optimización del Rendimiento

• Uso de mecanismos de caché para reducir la latencia en solicitudes frecuentes.
• Compresión de datos en las respuestas HTTP para minimizar el tamaño de la carga útil.

b. Mejoras en la Seguridad

• Implementar HTTPS para proteger la transmisión de datos entre cliente y servidor.
• Validación rigurosa de datos entrantes en el backend para evitar ataques como inyección SQL o cross-site scripting (XSS).

c. Experiencia del Usuario

• Reducir tiempos de carga mediante solicitudes asíncronas y procesamiento en segundo plano.
• Utilizar WebSockets para actualizar datos en tiempo real sin necesidad de recargar la página.

d. Actualización del Frontend

• Angular procesa la respuesta y genera un gráfico interactivo con los datos recibidos.

El modelo cliente-servidor con comunicación mediante HTTP proporciona una estructura sólida, flexible y escalable para el sistema. Su implementación con Angular como cliente y Laravel como servidor asegura una separación clara de responsabilidades, optimiza la experiencia del usuario y facilita la integración de futuras mejoras y módulos adicionales.

Arquitectura de la Plataforma Hub Ambiental del Caribe

La arquitectura de la plataforma del proyecto Hub Ambiental del Caribe está diseñada para ser resiliente, escalable y orientada al análisis avanzado de datos ambientales y climáticos. Este sistema combina múltiples capas, cada una con funciones específicas que trabajan en conjunto para garantizar la disponibilidad, el procesamiento de datos y la experiencia del usuario. En la base del sistema se encuentra la infraestructura on-premise, que utiliza tres servidores principales: uno dedicado a manejar las solicitudes del backend, otro como respaldo en caso de fallos, y un tercero para el balanceo de carga y la supervisión en tiempo real. Estas capas están unidas por un esquema de alta disponibilidad, que asegura la continuidad del servicio a través de réplicas de base de datos y mecanismos automáticos de failover.

En el nivel de integración y procesamiento, el sistema se apoya en una arquitectura orientada a servicios. El backend, desarrollado en tecnologías modernas, expone servicios RESTful para manejar la lógica del negocio y procesar datos provenientes de estaciones IoT. La base de datos PostgreSQL almacena los datos climáticos e históricos, con capacidades geoespaciales avanzadas que permiten realizar consultas complejas y servir de base para los modelos predictivos de inteligencia artificial. Los modelos de IA son implementados para evaluar riesgos y generar predicciones en tiempo real, lo que habilita una toma de decisiones más informada frente a riesgos ambientales y climáticos.

Finalmente, en el nivel de interacción con el usuario, el frontend desarrollado en Angular actúa como el puente entre los usuarios y la lógica interna del sistema. Este módulo no solo facilita la visualización de datos a través de gráficos y mapas interactivos (integrando Google Maps API), sino que también permite a los usuarios realizar consultas específicas y personalizar el análisis según sus necesidades. El balanceador de carga garantiza que las solicitudes lleguen al servidor adecuado, mientras que el monitoreo supervisa constantemente la salud del sistema para minimizar interrupciones. En conjunto, esta arquitectura no solo centraliza y procesa grandes volúmenes de datos, sino que también ofrece una experiencia accesible y confiable para los usuarios finales. En la Figura 1 se presenta la arquitectura de la plataforma Hub Ambiental del Caribe, diseñado para recopilar, procesar y presentar información ambiental proveniente de estaciones IoT.

Figura 1. Diagrama de la Arquitectura de la plataforma Hub Ambiental del Caribe

1. Capa de Monitoreo y Balanceador de Carga

La capa de monitoreo y balanceador de carga es el núcleo que garantiza la disponibilidad y estabilidad del sistema en todo momento. El balanceador de carga, implementado con herramientas como HAProxy o NGINX, actúa como intermediario entre los usuarios y los servidores backend, distribuyendo las solicitudes de manera eficiente. Por defecto, el balanceador dirige el tráfico al servidor principal, pero si detecta una falla en este mediante mecanismos de Health Checks, redirige automáticamente las solicitudes al servidor secundario, garantizando la continuidad operativa sin que el usuario perciba interrupciones. Este diseño asegura que, incluso ante caídas del servidor principal, el sistema permanezca funcional y accesible.

En paralelo, el sistema de monitoreo supervisa constantemente el estado de todos los componentes críticos del sistema, como los servidores backend, la base de datos y el balanceador de carga. Este monitoreo, realizado con herramientas como Prometheus y visualizado mediante Grafana, permite detectar problemas en tiempo real, como sobrecarga, fallos de hardware o interrupciones en la red. Además de emitir alertas tempranas, el monitoreo también genera métricas clave sobre el rendimiento del sistema, lo que permite al equipo técnico ajustar configuraciones y optimizar recursos según la carga de trabajo. En conjunto, esta capa no solo garantiza un funcionamiento ininterrumpido, sino que también mejora la eficiencia y la capacidad de respuesta del sistema frente a eventos inesperados.

Plantilla para el Despliegue Automático de la Infraestructura

El despliegue automático de la infraestructura de HubAmbiental está basado en el uso de contenedores Docker y la orquestación mediante Docker Compose, lo que permite una configuración ágil y repetible en cualquier entorno. La plantilla define todos los servicios del sistema, como el backend, la base de datos y las herramientas de monitoreo, en archivos de configuración estandarizados (docker-compose.yml). Esto asegura que la infraestructura pueda ser levantada y configurada automáticamente, sin importar el servidor o la nube donde se despliegue. Además, cada servicio está contenido en su propio entorno aislado, lo que elimina problemas de dependencias y facilita la escalabilidad del sistema.

Para que esta plantilla funcione correctamente, se requiere cumplir con ciertos requisitos previos. Entre ellos, tener Docker y Docker Compose instalados en el entorno local o en un servidor dedicado.

1. Requisitos Previos

• Docker y Docker Compose instalados en el entorno local o en un servidor.
• Estructura de directorios organizada:

/project-root
    /laravel
        Dockerfile.laravel
        nginx.conf
/angular-app
    Dockerfile.angular
docker-compose.yml

2. Docker Compose del Sistema

El archivo docker-compose.yml coordina los servicios necesarios para ejecutar la aplicación:

version: '3.8'

services:
    laravel-app:
        build:
            context: ./laravel
            dockerfile: Dockerfile.laravel
        container_name: laravel_app
        restart: unless-stopped
        working_dir: /var/www/html
        volumes:
            - ./laravel:/var/www/html
        ports:
            - "8000:8000"
        environment:
            APP_ENV: local
            APP_DEBUG: true
            APP_KEY: base64:<<your_laravel_key_here>>
            DB_CONNECTION: pgsql
            DB_HOST: postgres
            DB_PORT: 5432
            DB_DATABASE: laravel_db
            DB_USERNAME: laravel_user
            DB_PASSWORD: laravel_pass
        depends_on:
            - postgres

    postgres:
        image: postgres:15
        container_name: postgres
        restart: unless-stopped
        volumes:
            - postgres-data:/var/lib/postgresql/data
            - ./postgres/init.sql:/docker-entrypoint-initdb.d/init.sql
        environment:
            POSTGRES_USER: laravel_user
            POSTGRES_PASSWORD: laravel_pass
            POSTGRES_DB: laravel_db
        ports:
            - "5432:5432"

    angular-app:
        build:
            context: ./angular-app
            dockerfile: Dockerfile.angular
        container_name: angular_app
        restart: unless-stopped
        volumes:
            - ./angular-app:/usr/share/nginx/html
        ports:
            - "4200:80"
        depends_on:
            - laravel-app

volumes:
postgres-data:

3. Dockerfile para Laravel

El archivo Dockerfile.laravel instala Laravel y sus dependencias:

FROM php:8.2-fpm

# Instalación de dependencias
RUN apt-get update && apt-get install -y \
    curl \
    zip \
    unzip \
    git \
    libpq-dev \
    libzip-dev \
    && docker-php-ext-install pdo_pgsql zip

# Instalación de Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Configuración del directorio de trabajo
WORKDIR /var/www/html

# Copia del código fuente
COPY . /var/www/html
RUN composer install

# Configuración de permisos
RUN chown -R www-data:www-data /var/www/html \
    && chmod -R 775 /var/www/html/storage /var/www/html/bootstrap/cache

# Exposición de puertos
EXPOSE 8000
CMD php artisan serve --host=0.0.0.0 --port=8000

4. Dockerfile para Angular

El archivo Dockerfile.angular genera y sirve la aplicación Angular:

FROM node:18 AS build-stage

WORKDIR /app

COPY package*.json ./
RUN npm install
COPY . .

RUN npm run build --prod

FROM nginx:stable-alpine

COPY --from=build-stage /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

5. Configuración de Nginx

El archivo nginx.conf define las reglas para servir Angular y redirigir las peticiones API:

server {
    listen 80;

    server_name localhost;

    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files \$uri /index.html;
    }

    location /api/ {
        proxy_pass http://laravel_app:8000/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

6. Comandos de Despliegue

1. Levantar los servicios:

docker-compose up -d --build

2. Acceso a las aplicaciones:
   • Laravel: http://localhost:8000
   • Angular: http://localhost:4200

Arquitectura y Protocolos de Seguridad de la Información

La arquitectura del sistema Hub Ambiental ha sido diseñada con un enfoque prioritario en la seguridad de la información, garantizando la protección de los datos sensibles relacionados con variables ambientales y climáticas. Cada capa del sistema, desde el frontend hasta la base de datos, está protegida mediante una combinación de medidas de seguridad activas y pasivas. A nivel de red, se emplean firewalls y reglas de acceso restringido para controlar las comunicaciones entre los componentes del sistema. Además, todo el tráfico entre el frontend, el balanceador de carga y los servidores backend está cifrado utilizando el protocolo HTTPS/TLS, asegurando la confidencialidad de las comunicaciones y evitando que los datos sean interceptados durante su transmisión.

En la capa de almacenamiento, la base de datos PostgreSQL está configurada con políticas de acceso restringido, permitiendo únicamente conexiones autenticadas y cifradas. Estas medidas minimizan el riesgo de filtraciones o accesos indebidos a los datos más críticos del sistema.

Por último, se emplean prácticas de seguridad proactiva, como auditorías regulares de seguridad, pruebas de penetración y monitoreo continuo de posibles vulnerabilidades. El sistema de monitoreo no solo supervisa el rendimiento del sistema, sino que también detecta y reporta actividades sospechosas o intentos de acceso no autorizado en tiempo real. Adicionalmente, se han establecido políticas de control de acceso basado en roles (RBAC), asegurando que cada usuario solo pueda acceder a la información y funcionalidades que le corresponden según su rol en el sistema. Esta arquitectura de seguridad, combinada con protocolos avanzados, proporciona un entorno confiable y robusto para la gestión y análisis de datos ambientales.

Implementación y Configuración de TLS en la Arquitectura

El protocolo TLS (Transport Layer Security) es fundamental en la arquitectura de HubAmbiental para garantizar la confidencialidad, integridad y autenticidad de las comunicaciones en toda la infraestructura. TLS protege los datos transmitidos entre los diferentes componentes del sistema, como el frontend, el balanceador de carga, los servidores backend y los servicios externos como Google Maps API. La implementación de TLS asegura que cualquier información sensible, como credenciales, datos climáticos o resultados de análisis predictivos, no pueda ser interceptada o manipulada por actores no autorizados.

En el balanceador de carga, herramientas como HAProxy o NGINX se configuran para gestionar certificados TLS, actuando como el primer punto de entrada para cifrar las conexiones. Los certificados se generan y gestionan utilizando soluciones confiables, como Let’s Encrypt para entornos públicos o certificados de una autoridad certificadora interna (CA) para despliegues privados. Esto permite establecer conexiones seguras entre el cliente (frontend) y el balanceador de carga, asegurando que todas las solicitudes entrantes estén cifradas antes de llegar al backend.

Además, en las comunicaciones internas entre los servidores (por ejemplo, entre el backend y la base de datos PostgreSQL), también se habilita TLS. PostgreSQL se configura con soporte para conexiones cifradas mediante certificados X.509, lo que evita que los datos sean visibles en la red incluso dentro de la infraestructura on-premise. Para garantizar la autenticidad de las conexiones, se utiliza un mecanismo de doble autenticación en el que tanto el cliente como el servidor validan los certificados mutuos antes de establecer la conexión. Esto protege contra ataques como el man-in-the-middle (MITM) y asegura que solo los componentes autorizados puedan comunicarse entre sí.

Bibliografía

1. ACIBEIRO, María. Diferencia entre HTTP y HTTPS: seguridad y rendimiento en la web. GoDaddy Resources – Spain [página web]. (27, diciembre, 2023). [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://www.godaddy.com/resources/es/seguridad/diferencia-entre-http-y-https
2. ANW. WebSockets, ¿Qué son y Cómo Funcionan? ANW Hosting para Web’s & Aplicaciones [página web]. [Consultado el 8, enero, 2025]. Disponible en Internet: https://www.anw.es/servidores/websockets-que-son-y-como-funcionan.html>.
3. AUTH0. ¿Qué es OAuth 2.0 y para qué sirve? Auth0 [página web]. [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://auth0.com/es/intro-to-iam/what-is-oauth-2.
4. AWS. ¿Cuál es la diferencia entre el front end y back end en el desarrollo de aplicaciones? Amazon Web Services, Inc. [página web]. [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://aws.amazon.com/es/compare/the-difference-between-frontend-and-backend/.
5. AWS. ¿Qué es una API de RESTful? Amazon Web Services, Inc. [página web]. [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://aws.amazon.com/es/what-is/restful-api/.
6. BÁEZ, Jorge. Qué es un ataque de XSS o Cross-Site Scripting. Welivesecurity By ESET [página web]. (28, septiembre, 2021). [Consultado el 14, enero, 2025]. Disponible en Internet: https://www.welivesecurity.com/la-es/2021/09/28/que-es-ataque-xss-cross-site-scripting/.
7. BEECEPTOR. Web Data Serialization: JSON, XML, YAML & More Explained. Beeceptor [página web]. [Consultado el 16, diciembre, 2024]. Disponible en Internet: https://beeceptor.com/docs/concepts/data-exchange-formats/.
8. CLOUDFLARE. ¿Qué es TLS (Transport Layer Security)? Cloudflare [página web]. [Consultado el 14, enero, 2025]. Disponible en Internet: https://www.cloudflare.com/es-es/learning/ssl/transport-layer-security-tls/.
9. CURATE PARTNERS. The Blackboard Architectural Pattern: A Collaborative Approach to Complex Problem-Solving. Curate Partners [página web]. [Consultado el 20, noviembre, 2024]. Disponible en Internet: https://curatepartners.com/blogs/skills-tools-platforms/understanding-the-blackboard-architectural-pattern-collaborative-problem-solving-for-complex-systems-curate-partners/.
10. FORTINET. ¿Qué es un firewall? Definición y tipos de firewall. Fortinet [página web]. [Consultado el 14, enero, 2025]. Disponible en Internet: https://www.fortinet.com/lat/resources/cyberglossary/firewall.
11. GARCÍA DE ZÚÑIGA, Fernán. Arquitectura cliente servidor: qué es, tipos y ejemplos. Arsys [página web]. (17, octubre, 2024). [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://www.arsys.es/blog/todo-sobre-la-arquitectura-cliente-servidor.
12. GONÇALVES, Manuel José. ¿Qué es Angular y para qué sirve? Hiberus blog [página web]. (13, octubre, 2021). [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://www.hiberus.com/crecemos-contigo/que-es-angular-y-para-que-sirve/.
13. HARRIS, Chandler. Comparación entre la arquitectura monolítica y la arquitectura de microservicios. Atlassian [página web]. [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://www.atlassian.com/es/microservices/microservices-architecture/microservices-vs-monolith.
14. IBM. ¿Qué es PostgreSQL? IBM – United States [página web]. [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://www.ibm.com/es-es/topics/postgresql.
15. LATAM TECH. Qué es la arquitectura en capas: descubre sus ventajas y ejemplos. Latam Tech – Transformación digital [página web]. [Consultado el 20, noviembre, 2024]. Disponible en Internet: https://latamtech-sac.com/que-es-la-arquitectura-en-capas-descubre-sus-ventajas-y-ejemplos/.
16. LINDEMULDER, Gregg y KOSINSKI, Matt. ¿Qué es el control de acceso basado en roles (RBAC)? IBM – United States [página web]. (20, agosto, 2024). [Consultado el 14, enero, 2025]. Disponible en Internet: https://www.ibm.com/mx-es/think/topics/rbac.
17. LÓPEZ MAGAÑA, Luis Miguel. Qué es Json Web Token y cómo funciona. OpenWebinars.net [página web]. (17, enero, 2020). [Consultado el 16, diciembre, 2024]. Disponible en Internet: https://openwebinars.net/blog/que-es-json-web-token-y-como-funciona/.
18. MDN. Códigos de estado de respuesta HTTP – HTTP. MDN Web Docs [página web]. [Consultado el 2, noviembre, 2024]. Disponible en Internet: https://developer.mozilla.org/es/docs/Web/HTTP/Status.
19. MICROSOFT. Protocolos y tecnologías de IoT. Microsoft Azure [página web]. [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://azure.microsoft.com/es-mx/solutions/iot/iot-technology-protocols.
20. MITTON, Leanne. CRUD Operations Explained. Splunk [página web]. (13, agosto, 2024). [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://www.splunk.com/en_us/blog/learn/crud-operations.html.
21. PAHN, Aleksander. NGINX vs. HAProxy: Comparing Features and Use Cases. OpenLogic by Perforce [página web]. (30, octubre, 2024). [Consultado el 14, enero, 2025]. Disponible en Internet: https://www.openlogic.com/blog/nginx-vs-haproxy.
22. RED HAT. ¿Qué es la arquitectura orientada a los servicios (SOA)? Red Hat [página web]. (4, agosto, 2023). [Consultado el 16, diciembre, 2024]. Disponible en Internet: https://www.redhat.com/es/topics/cloud-native-apps/what-is-service-oriented-architecture.
23. SERVINFORMACIÓN. API de Google Maps: ¿Qué son y para qué sirven? Servinformación [página web]. [Consultado el 8, enero, 2025]. Disponible en Internet: https://servinformacion.com/api-de-google-maps-que-son-y-para-que-sirven/geolocalizacion/localizacion-inteligente/.
24. THINGSBOARD. What is ThingsBoard? ThingsBoard [página web]. [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://thingsboard.io/docs/getting-started-guides/what-is-thingsboard/.
25. UNIR. Framework: Qué es, para qué sirve y algunos ejemplos [Anónimo]. UNIR Formación Profesional [página web]. (22, septiembre, 2022). [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://unirfp.unir.net/revista/ingenieria-y-tecnologia/framework/.
26. VERA, Rafael Altube. Qué es Laravel: Características y ventajas. OpenWebinars.net [página web]. (31, marzo, 2021). [Consultado el 9, noviembre, 2024]. Disponible en Internet: https://openwebinars.net/blog/que-es-laravel-caracteristicas-y-ventajas/.