UNIVERSIDADE DE CAXIAS DO SUL ÁREA DO CONHECIMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS GUILHERME SIMIONI WASKIEVICZ CONSTRUÇÃO DE UMA ARQUITETURA PARA INTEGRAÇÃO E ESCALABILIDADE DO SISTEMA EDUCACIONAL WEBALGO EM UM AMBIENTE WEB BENTO GONÇALVES 2025 GUILHERME SIMIONI WASKIEVICZ CONSTRUÇÃO DE UMA ARQUITETURA PARA INTEGRAÇÃO E ESCALABILIDADE DO SISTEMA EDUCACIONAL WEBALGO EM UM AMBIENTE WEB Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do título de Bacharel em Ciência da Computação na Área do Conhecimento de Ciências Exatas e Engenharias da Universidade de Caxias do Sul. Orientador: Prof. Dr. Leonardo Pelliz- zoni BENTO GONÇALVES 2025 GUILHERME SIMIONI WASKIEVICZ CONSTRUÇÃO DE UMA ARQUITETURA PARA INTEGRAÇÃO E ESCALABILIDADE DO SISTEMA EDUCACIONAL WEBALGO EM UM AMBIENTE WEB Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do título de Bacharel em Ciência da Computação na Área do Conhecimento de Ciências Exatas e Engenharias da Universidade de Caxias do Sul. Aprovado em 25/11/2025 BANCA EXAMINADORA Prof. Dr. Leonardo Pellizzoni Universidade de Caxias do Sul - UCS Prof. Me. Alexandre Erasmo Krohn Nascimento Universidade de Caxias do Sul - UCS Prof. Dr. Ricardo Vargas Dorneles Universidade de Caxias do Sul - UCS AGRADECIMENTOS A realização deste Trabalho de Conclusão de Curso representa o encerramento de uma jornada de muito aprendizado, dedicação e crescimento pessoal e profissional. Nada disso seria possível sem o apoio e a presença de pessoas que caminharam ao meu lado ao longo deste percurso. Agradeço primeiramente aos meus pais, Jocemar e Elissandra, pelo amor incondi- cional, pelos ensinamentos e pela base sólida que sempre me ofereceram. São o exemplo de esforço, honestidade e perseverança que me inspira diariamente. À minha irmã, Manuela, por ser uma presença constante de alegria e ternura, lembrando-me, mesmo nos dias mais corridos, da importância das pequenas coisas. À minha namorada, Rafaela, pelo carinho, pela paciência e pelo incentivo constante, sua compreensão e apoio foram fundamentais para que eu seguisse firme até o fim desta etapa. Aos meus amigos, por cada palavra de encorajamento, pelas risadas e pela leveza que tornaram essa caminhada mais agradável. Expresso também minha gratidão aos professores que compuseram a banca avali- adora, Prof. Me. Alexandre Erasmo Krohn Nascimento e Prof. Dr. Ricardo Vargas Dorneles, pela disponibilidade, pelas observações criteriosas e pelas contribuições que enriqueceram este trabalho. Um agradecimento especial ao meu orientador, Prof. Dr. Leonardo Pellizzoni, pelos valiosos aconselhamentos, pela dedicação e pela confiança depositada em mim durante todo o processo. Agradeço, ainda, às turmas que participaram dos testes e contribuíram diretamente para a validação do projeto. A colaboração de cada participante foi essencial para que esta pesquisa se tornasse concreta e significativa. Por fim, deixo meu sincero agradecimento a todos que, de alguma forma, contri- buíram para esta conquista. Cada gesto de apoio e cada palavra de incentivo tiveram um papel importante na realização deste sonho. “A educação é a arma mais poderosa que você pode usar para mudar o mundo.” Paulo Freire RESUMO O constante avanço tecnológico e a crescente demanda por soluções flexíveis, acessíveis e ali- nhadas ao uso em plataformas web tem fortalecido a modernização de sistemas, principalmente os desenvolvidos em ambiente desktop. O presente trabalho propõe uma arquitetura que per- mite integrar um novo sistema web ao sistema backend do WebAlgo, utilizado no ensino de programação na Universidade de Caxias do Sul (UCS). A proposta busca viabilizar a comu- nicação entre a interface e o servidor consolidado, sem alterar a estrutura atual do servidor ou expor diretamente dados sensíveis. Dessa forma, a base da construção baseou-se na realização de pesquisas, levantamento de referências, análise de trabalhos similares e na definição de uma arquitetura composta por contêineres, utilizando Docker e NGINX, além da implementação do middleware responsável pela intermediação da comunicação entre o front-end e o servidor legado. Os testes realizados demonstraram que a arquitetura proposta apresentou desempenho estável, mantendo baixa latência, alta disponibilidade e comportamento consistente mesmo sob dife- rentes níveis de carga. Observou-se que o uso do NGINX como proxy reverso e balanceador de carga contribuiu para uma distribuição eficiente das requisições, enquanto o middleware mostrou-se resiliente e capaz de intermediar a comunicação de forma segura e padronizada. Nos cenários de uso real em sala de aula, a aplicação manteve funcionamento contínuo e res- ponsivo, evidenciando que a solução desenvolvida é adequada para o ambiente acadêmico e está preparada para ambientes locais e em nuvem. Palavras-chave: Integração.Middleware.Modernização.NGINX.Docker. ABSTRACT The constant technological evolution and the growing demand for flexible, accessible, and web- aligned solutions have reinforced the modernization of systems, especially those originally de- veloped for desktop environments. This work proposes an architecture that enables the integra- tion of a new web-based system with the WebAlgo backend, used in programming education at UCS. The solution aims to establish communication between the new interface and the con- solidated legacy server without modifying its structure or exposing sensitive data. The design was based on research, reference analysis, related work, and the definition of a container-based architecture using Docker and NGINX, in addition to implementing a middleware responsible for mediating communication between the front-end and the legacy system. The conducted tests demonstrated that the proposed architecture delivered stable performance, maintaining low latency, high availability, and consistent behavior under different load levels. The use of NGINX as a reverse proxy and load balancer enabled efficient request distribu- tion, while the middleware proved resilient and capable of securely and consistently handling communication. In real classroom scenarios, the application remained responsive and fully op- erational, indicating that the solution is suitable for academic environments and ready for both local and cloud deployments. Keywords: Integration.Middleware.Modernization.NGINX.Docker. LISTA DE FIGURAS Figura 1 – Visão geral do processo ICONIX . . . . . . . . . . . . . . . . . . . . . . . . . 18 Figura 2 – Exemplo de um proxy reverso . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figura 3 – Middleware que permite a integração entre os sistemas . . . . . . . . . . . 25 Figura 4 – Arquitetura do proxy reverso para a realização dos testes. O tempo é medido pelos timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figura 5 – Ilustração da reimplantação de servidores NCSLab . . . . . . . . . . . . . . 29 Figura 6 – Diagrama geral dos servições EAST . . . . . . . . . . . . . . . . . . . . . 30 Figura 7 – Arquitetura do portal Algo+ . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figura 8 – Arquitetura da solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figura 9 – Diagrama de caso de uso do sistema . . . . . . . . . . . . . . . . . . . . . 34 Figura 10 – Lado A: Tela de login. Lado B: Tela de cadastro . . . . . . . . . . . . . . . 35 Figura 11 – Diagrama de sequência do Login . . . . . . . . . . . . . . . . . . . . . . . 36 Figura 12 – Diagrama de sequência do cadastro . . . . . . . . . . . . . . . . . . . . . . 36 Figura 13 – Menu para busca de exercícios . . . . . . . . . . . . . . . . . . . . . . . . 39 Figura 14 – Diagrama de sequência para busca de exercícios . . . . . . . . . . . . . . . 40 Figura 15 – Diagrama de camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figura 16 – Visão geral da arquitetura desenvolvida. . . . . . . . . . . . . . . . . . . . 48 Figura 17 – Visão geral da arquitetura Hexagonal no middleware . . . . . . . . . . . . . 49 Figura 18 – Principais configurações do NGINX. . . . . . . . . . . . . . . . . . . . . . 51 Figura 19 – Visão geral do funcionamento do proxy reverso NGINX. . . . . . . . . . . . 52 Figura 20 – Painel de monitoramento no Grafana durante o teste de balanceamento de carga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figura 21 – CPU e memória dos containers durante o teste de balanceamento de carga. . 59 Figura 22 – Painel de monitoramento no Grafana durante o teste de falha. . . . . . . . . 60 Figura 23 – CPU e memória dos containers durante o teste de falha. . . . . . . . . . . . 60 Figura 24 – Painel de monitoramento no Grafana durante o teste de usuários simultâneos. 62 Figura 25 – Painel de monitoramento no Grafana durante o teste de capacidade máxima 65 Figura 26 – CPU e memória dos containers durante o teste de capacidade máxima. . . . 65 Figura 27 – Tentativa de requisição direta à API externa, evidenciando falha de conexão. 65 Figura 28 – Painel de monitoramento no Grafana ao final do teste combinado de carga e spike. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Figura 29 – CPU e memória dos containers durante o teste de carga e spike. . . . . . . . 67 Figura 30 – Tentativa de requisição direta à API externa, evidenciando falha de conexão durante os testes de carga. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Figura 31 – Custo acumulado da assinatura Azure durante o mês de outubro de 2025. . . 71 Figura 32 – Recursos associados ao grupo de recursos do App Service. . . . . . . . . . 72 Figura 33 – Custo acumulado dos recursos App Service. . . . . . . . . . . . . . . . . . 72 Figura 34 – Recursos associados ao grupo de recursos do AKS. . . . . . . . . . . . . . 73 Figura 35 – Custo acumulado dos recursos AKS. . . . . . . . . . . . . . . . . . . . . . 73 Figura 36 – Custos diários do serviço App Service. . . . . . . . . . . . . . . . . . . . . 74 Figura 37 – Custos diários do serviço AKS. . . . . . . . . . . . . . . . . . . . . . . . . 75 Figura 38 – Diretório web-algo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Figura 39 – AKS - Painel no Grafana durante o primeiro teste . . . . . . . . . . . . . . 86 Figura 40 – AKS - Painel no Azure durante o segundo teste . . . . . . . . . . . . . . . 87 Figura 41 – AKS - Parte 1: Painel no Grafana durante o segundo teste. . . . . . . . . . . 87 Figura 42 – AKS - Parte 2: Painel no Grafana durante o segundo teste. . . . . . . . . . . 88 Figura 43 – AKS - Painel no Azure durante o terceiro teste . . . . . . . . . . . . . . . . 89 Figura 44 – AKS - Parte 1: Painel no Grafana durante o terceiro teste. . . . . . . . . . . 90 Figura 45 – AKS - Parte 2: Painel no Grafana durante o terceiro teste. . . . . . . . . . . 90 Figura 46 – App Service - Painel no Azure durante o terceiro teste . . . . . . . . . . . . 91 Figura 47 – AKS - Parte 1: Painel no Azure durante o quarto teste. . . . . . . . . . . . . 92 Figura 48 – App Service - Parte 2: Painel no Azure durante o quarto teste. . . . . . . . . 93 Figura 49 – App Service - Parte 1: Painel no Azure durante o quinto teste. . . . . . . . . 94 Figura 50 – App Service - Parte 2: Painel no Azure durante o quinto teste. . . . . . . . . 95 Figura 51 – Pico repentino de CPU do App Service. . . . . . . . . . . . . . . . . . . . 96 LISTA DE TABELAS Tabela 1 – Artigos selecionados que de alguma forma se relacionam com o presente trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Tabela 2 – Métricas consolidadas dos testes de latência. . . . . . . . . . . . . . . . . . 57 Tabela 3 – Métricas consolidadas dos testes de balanceamento de carga . . . . . . . . . 58 Tabela 4 – Métricas consolidadas dos testes de falha . . . . . . . . . . . . . . . . . . . 60 Tabela 5 – Métricas consolidadas dos testes com usuários simultâneos. . . . . . . . . . 63 Tabela 6 – Métricas consolidadas dos três testes de capacidade máxima. . . . . . . . . 64 Tabela 7 – Métricas consolidadas dos três testes combinados de carga e spike. . . . . . 66 LISTA DE QUADROS Quadro 1 – UC-01 Realizar Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Quadro 2 – UC-02 Realizar cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Quadro 3 – UC-03 Buscar exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 LISTA DE ABREVIATURAS E SIGLAS ACR Registro de Contêiner do Azure ACI Azure Container Instances AKS Azure Kubernetes Service AWS Amazon Web Services C3E Código de Três Endereços CORS Cross-Origin Resource Sharing CORBA Arquitetura de Corretor de Objetos de Requisição Comum CPU Central Processing Unit CSS Folhas de Estilo em Cascata DMZ Zona Desmilitarizada EC2 Amazon Elastic Compute Cloud ECS Amazon Elastic Container Service GUI Interface Gráfica do Usuário HTML Linguagem de Marcação de Hipertexto HTTP Protocolo de Transferência de Hipertexto IaC Infraestrutura como Código IDE Ambiente de Desenvolvimento Integrado IDL Linguagem de Definição de Interface JSON Notação de Objetos JavaScript LIBRAS Língua Brasileira de Sinais LTS Long-Term Support MVC Modelo-Visão-Controlador OCI Oracle Cloud Infrastructure OKE Container Engine for Kubernetes SOAP Protocolo Simples de Acesso a Objetos SSL Secure Sockets Layer UCS Universidade de Caxias do Sul UML Linguagem de Modelagem Unificada URL Localizador Uniforme de Recursos XML Linguagem de Marcação Extensível OPC UA Open Platform Communications Unified Architecture CPS Sistemas Ciberfísicos VUs Usuários virtuais simultâneos SUMÁRIO 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.1 Questão da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 OBJETIVO GERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . 17 2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Modelo Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.1 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.2 Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.1 Proxy de Encaminhamento . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.2 Proxy Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3 TRABALHOS CORRELATOS . . . . . . . . . . . . . . . . . . . . . . . 23 3.1 Integração de Sistemas Legados . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 Mediador para integrações de sistemas heterogêneos . . . . . . . . . . . . . 27 3.3 Aplicações voltadas ao Ensino . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 PROPOSTA DE SOLUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.1 DETALHAMENTO DE CASOS DE USO . . . . . . . . . . . . . . . . . 34 4.1.1.1 Caso de Uso UC-01 realizar Login . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1.1.2 Caso de Uso UC-02 realizar cadastro . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1.1.3 Caso de Uso UC-03 buscar exercício . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2 Validação da Proposta de Arquitetura . . . . . . . . . . . . . . . . . . . . . 40 4.3 Análise da Solução Arquitetural . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.1 Arquitetura do Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.2 Virtualização por Containers . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.3 Distribuição e Gerenciamento de Requisições . . . . . . . . . . . . . . . 44 4.3.4 Infraestrutura para Disponibilidade . . . . . . . . . . . . . . . . . . . . 44 4.3.5 Gerenciamento e provisionamento da Infraestrutura . . . . . . . . . . . 45 4.3.6 Observabilidade e Monitoramento . . . . . . . . . . . . . . . . . . . . . 46 5 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1 Visão Geral da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2 Desenvolvimento do Middleware . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.1 Arquitetura Hexagonal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2.2 Comunicação com o Front-end . . . . . . . . . . . . . . . . . . . . . . . 50 5.3 Configuração do Proxy Reverso . . . . . . . . . . . . . . . . . . . . . . . . 50 5.4 Orquestração com Docker Compose . . . . . . . . . . . . . . . . . . . . . 52 5.5 Monitoramento e Observabilidade . . . . . . . . . . . . . . . . . . . . . . . 53 5.5.1 Coleta de Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.5.2 Visualização e Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.5.3 Centralização de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.5.4 Métricas do Host e Containers . . . . . . . . . . . . . . . . . . . . . . . . 55 5.5.5 Integração Geral e Benefícios . . . . . . . . . . . . . . . . . . . . . . . . 55 5.6 Testes de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.6.1 Teste de Latência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.6.2 Teste de Balanceamento de Carga . . . . . . . . . . . . . . . . . . . . . . 57 5.6.3 Teste de Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.6.4 Teste Funcional da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . 61 5.6.5 Teste de Usuários Simultâneos . . . . . . . . . . . . . . . . . . . . . . . . 61 5.6.6 Teste de Capacidade máxima . . . . . . . . . . . . . . . . . . . . . . . . 63 5.6.7 Teste de Carga e Spike . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.6.8 Considerações Gerais dos Testes . . . . . . . . . . . . . . . . . . . . . . 68 5.7 Deploy na Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.7.1 Azure App Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.7.2 Azure Kubernetes Service . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.7.3 Análise de Custos na Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.7.3.1 Custos diários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.7.4 Testes com usuários reais . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.7.4.1 Teste 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.7.4.2 Teste 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.7.4.3 Teste 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.7.4.4 Teste 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.7.4.5 Teste 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . 78 6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 APÊNDICE A – ESTRUTURA DO PROJETO . . . . . . . . . . . . . 82 APÊNDICE B – ESTRUTURA NGINX E FUNÇÕES PRINCIPAIS . . 84 APÊNDICE C – TESTES EM SALA DE AULA . . . . . . . . . . . . . 85 C.1 Teste 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 C.2 Teste 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 C.3 Teste 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 C.4 Teste 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 C.5 Teste 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 APÊNDICE D – ARQUIVOS DE CONFIGURAÇÃO . . . . . . . . . . 97 15 1 INTRODUÇÃO Um dos principais desafios para estudantes que estão ingressando em cursos de Com- putação é o aprendizado de programação. Para melhorar esse processo, é essencial identificar e corrigir equívocos comuns dos alunos, exigindo dos professores, abordagens didáticas efica- zes (QIAN; LEHMAN, 2017). Para auxiliar nesse processo, existem diversas plataformas, como o Beecrowd1, CodeHS2 e Codecademy3, onde os alunos podem praticar e aprimorar suas habili- dades de lógica e resolução de problemas (CRUZ, 2022; REIS et al., 2015). Ainda, destacam-se sistemas que atuam no auxílio dos alunos de instituições de ensino, oferecendo um ambiente adaptado às necessidades dos estudantes (LIMA et al., 2024; CAVALCANTE; SILVA; VITORINO, 2020; JARAMILLO-ALCAZAR et al., 2018). As disciplinas introdutórias de programação da Universidade de Caxias do Sul (UCS) utilizam o sistema Webalgo, desenvolvido por professores da universidade e amplamente em- pregado desde 2009. Essa ferramenta, originalmente desenvolvida para uso via web, utilizava a tecnologia Java Applet no cliente, a qual foi posteriormente descontinuada nos navegadores, preservando suas funcionalidades. Em razão dessa obsolescência, o sistema foi adaptado para o formato desktop. O WebAlgo permite que os alunos resolvam exercícios e compreendam con- ceitos fundamentais da linguagem C e português estruturado, oferecendo feedbacks relevantes durante a resolução das atividades (DORNELES; JR; ADAMI, 2010). O programa consolidou-se, ao longo do tempo, como um importante aliado no ensino dessas disciplinas. Todavia, à me- dida que os hábitos tecnológicos da população evoluíram, surgiram novos desafios. Segundo dados da PNAD Contínua (IBGE, 2023), o acesso à internet por dispositivos móveis tornou-se predominante no Brasil. Esse novo panorama, aliado à crescente expectativa por flexibilidade e acesso remoto, motivou a transição da versão desktop para uma interface web atualizada. No intuito de aprimorar a ferramenta, algumas melhorias foram implementadas, como o desenvolvimento de um compilador e uma máquina virtual para um subconjunto da linguagem Python (MIOTTO, 2019). Embora a ferramenta tenha estabelecido as bases técnicas, o sistema ainda permitia o aprimoramento da sua interação com o usuário. Para isso, foi desenvolvida uma nova interface web, proporcionando uma nova experiência aos usuários. Buscando modernizar a solução e torná-la mais acessível, um projeto recente reformu- lou a aplicação para um novo ambiente, preservando sua proposta educacional e introduzindo uma nova interface web, a qual não possui qualquer conexão com as APIs já existentes do We- bAlgo. A atualização da arquitetura trouxe amplo acesso via navegadores web, eliminando a necessidade de instalação ou configuração de ambientes locais. Nesse contexto, o desenvolvi- 1 2 3 https://beecrowd.com/ https://codehs.com/ https://www.codecademy.com/ mento do compilador abrangeu as três fases sequenciais de análise, a geração de código interme- diário no formato Código de Três Endereços (C3E), atuando como um bytecode, e a definição da máquina virtual responsável por sua execução (SUSIN, 2024). Atualmente, a versão desktop do WebAlgo realiza a comunicação com o servidor in- terno da UCS por meio de chamadas Protocolo de Transferência de Hipertexto (HTTP), através de um cliente HTTP utilizando Java, responsável pelo gerenciamento das sessões e requisições para ações de login, cadastro, criação e alteração de problemas, possibilitando a integração di- reta com as APIs do servidor. Dessa forma, torna-se viável a implementação de um middleware que viabilize a integração entre o novo sistema web e o servidor. Essa solução tem como finali- dade garantir a continuidade do uso da ferramenta, preservar os dados históricos e assegurar a compatibilidade entre as plataformas, proporcionando um fluxo de dados eficiente e uma tran- sição suave para o ambiente modernizado, a fim de otimizar a comunicação entre os sistemas sem expor os dados sensíveis do servidor interno da UCS. 1.1 QUESTÃO DA PESQUISA Como integrar uma interface web a um backend consolidado não expondo dados do servidor diretamente? 1.2 OBJETIVO GERAL Objetiva-se construir uma solução de integração entre um sistema backend consolidado e uma nova interface web, permitindo que ambos funcionem em conjunto, buscando estabele- cer um canal de comunicação, sem que as informações importantes do servidor sejam acessíveis diretamente pela camada de apresentação. Desta forma, será adotada uma abordagem que per- mita a mediação entre os sistemas, mantendo a autonomia do backend e filtrando as múltiplas requisições. 1.2.1 Objetivos Específicos 1. Preservar as funcionalidades da ferramenta. 2. Planejar a autenticação dos usuários na nova interface. 3. Adotar estratégias de integração seguras 4. Implementar um mecanismo de mediação que faça a ponte entre o sistema legado e a nova interface 16 1.3 ESTRUTURA DO TRABALHO O presente trabalho está organizado da seguinte forma: • Este capítulo apresentou uma introdução sobre o trabalho, incluindo seu cenário, motiva- ções, objetivo geral e objetivos específicos. • O Capítulo 2 tem por objetivo apresentar conceitos teóricos sobre o desenvolvimento client-server e o uso de proxy como forma de integração entre plataformas heterogêneas. • O Capítulo 3 apresenta uma pesquisa de revisão sistemática realizada para compreen- der o cenário do tema e quais os principais meios já utilizados para resolver problemas relacionados. • O Capítulo 4 apresenta a proposta de solução e aborda os testes realizados para validar o funcionamento e aderência aos requisitos da arquitetura. • O Capítulo 5 apresenta o desenvolvimento da solução proposta, descrevendo detalhada- mente a arquitetura implementada, as tecnologias utilizadas e as etapas do processo de construção do sistema. • O Capítulo 6 apresenta a conclusão do trabalho, destacando os resultados obtidos e pos- síveis direções para trabalhos futuros. 17 18 2 REFERENCIAL TEÓRICO Este capítulo apresentará uma descrição do modelo metodológico adotado e das prin- cipais tecnologias utilizadas ao longo do desenvolvimento do projeto. A apresentação desses elementos é utilizada para explicar as decisões técnicas e garantir o embasamento necessário para a compreensão do trabalho. 2.1 METODOLOGIA Considerando o que foi discutido, o trabalho tem como premissa desenvolver uma apli- cação mediadora, com o propósito de integrar uma nova interface de aprendizado de programa- ção ao banco de dados de uma aplicação existente. Com o objetivo de atingir esse propósito, a aplicação pretende empregar ferramentas associadas ao back-end. Nesse sentido, a lingua- gem Java e o uso de proxy, foram considerados como uma opção viável para a construção da aplicação. Serão adotadas como etapas metodológicas o modelo ICONIX, que auxilia nos proces- sos de modelagem e desenvolvimento do sistema. Esse modelo se divide em dois fluxos: estático e dinâmico. O fluxo estático é responsável por gerar artefatos ligados aos dados, como o mo- delo de domínio e o diagrama de classes. Por outro lado, o fluxo dinâmico foca na definição dos processos relacionados à interação dos usuários com o sistema, gerando os diagramas de casos de uso, robustez e sequência. Esses diagramas são representados por meio da Linguagem de Modelagem Unificada (UML) (ROSENBERG; STEPHENS, 2007). Por essa razão, o ICONIX foi escolhido, pois, além de gerar todos os artefatos necessários em cada fase da implementação, ele proporciona um processo iterativo e prático, o que facilita o trabalho do desenvolvedor. A Figura 1 ilustra o fluxo da metodologia ICONIX e os artefatos gerados. Figura 1 – Visão geral do processo ICONIX Fonte: (ROSENBERG; STEPHENS, 2007) 2.2 MODELO CLIENTE-SERVIDOR O termo cliente-servidor, no ambiente computacional, é um sistema no qual um cliente e um servidor interagem para viabilizar a comunicação entre si. Essa comunicação ocorre onde um agente, denominado cliente, realiza requisições para o outro agente, o servidor, este executa a demanda e retorna os resultados para o cliente (OLUWATOSIN, 2014). Esse padrão corresponde a uma arquitetura amplamente utilizada na web. No contexto web, o software cliente, geralmente um navegador, se torna responsável por requisitar os recursos necessários por meio de uma Localizador Uniforme de Recursos (URL), aguardando, portanto, a resposta para apresentá-la adequadamente ao usuário final. Esse soft- ware pode estar presente em dispositivos como notebooks e smartphones (CONNOLLY; HOAR, 2015). Já o servidor, por sua vez, pode ser visto como componente central do modelo, res- ponsável pelo armazenamento de dados e pela hospedagem de aplicações web, entre outras funções. No entanto, sua principal característica está no recebimento de requisições, no pro- cessamento dessas e no retorno ao requisitante com algum recurso, como, por exemplo, um arquivo Linguagem de Marcação de Hipertexto (HTML). Atualmente existem diversos tipos de servidores, web, de aplicação, de e-mail e de banco de dados (CONNOLLY; HOAR, 2015). Podemos dividir as ferramentas e necessidades do sistema em duas partes principais: front-end e back-end. O front-end corresponde ao Cliente, geralmente executado em um na- vegador web, enquanto o back-end está associado aos artefatos do Servidor. Na Seção 2.2.1 serão discutidas as características do back-end, enquanto na Seção 2.2.2 serão apresentados os aspectos relacionados ao front-end. 2.2.1 Back-end Segundo Adam et al. (2019), o back-end diz respeito a scripts e aplicações que operam diretamente nos servidores, de forma transparente ao usuário final. Ele tem a responsabilidade de processar, armazenar e entregar dados ou serviços requisitados pelas aplicações front-end, certificando que essa comunicação entre o usuário e o sistema aconteça de forma organizada e segura. Em resumo, o back-end trabalha como núcleo lógico dos softwares, englobando o acesso ao banco de dados, integração de dados, lógica de negócios e também da implementação de APIs. Sua principal função é receber as requisições do front-end, operar sobre elas conforme as regras específicas, interagir com serviços ou banco de dados, e enviar as respostas adequadas de volta à interface de usuário. Entretanto, é importante destacar que, o desenvolvimento back-end é composto por di- ferentes linguagens, como Java, PHP, Python, C++ e JavaScript, e os frameworks comumente utilizados como Express, Rails, Laravel, Django e Spring, que dão apoio às funcionalidades do sistema. É possível encontrar ampla variedade tecnológica para o desenvolvimento back-end, 19 evidenciando a complexidade e a abrangência no suporte à comunicação entre sistemas, suas interfaces e a manipulação de dados (DALMIA; CHOWDARY, 2020). Conforme discutido pelos autores, o back-end realiza um papel importante na constru- ção de sistemas, sendo responsável por comunicar com o banco de dados, servidores e pelo processamento da lógica de negócio e dados, sustentando de forma eficiente, segura e inte- gra às funcionalidades da aplicação para o usuário (ADAM; BESARI; BACHTIAR, 2019; DALMIA; CHOWDARY, 2020). 2.2.2 Front-End O desenvolvimento de interfaces web, chamado de front-End, corresponde à implemen- tação da camada iterativa e visual das aplicações web. Diferentemente do back-end, explicado na seção anterior, o front-end trata-se da parte do sistema na qual o usuário final interage di- retamente, incluindo design, estrutura, conteúdo, dados e funcionalidades. O front-end é res- ponsável por traduzir o projeto visual de uma página web ou aplicação para o ambiente digital, por meio de Interface Gráfica do Usuário (GUI) e comandos em linha, agregando textos, menus de navegação, imagens, vídeos e outros componentes importantes de uma interface (DALMIA; CHOWDARY, 2020). A criação de interfaces para usuários envolve o uso de diferentes linguagens, como HTML, Folhas de Estilo em Cascata (CSS) e JavaScript. Normalmente, trabalham junto de frameworks e bibliotecas que facilitam o desenvolvimento, melhorando a experiencia do de- senvolvedor e que aprimoram a do usuário final, alguns deles são: AngularJS, jQuery, ReactJS e SASS. Esses recursos disponibilizam para o desenvolvedor formas mais dinâmicas de cria- ção de páginas, melhorando a iteratividade e responsividade, propriedades fundamentais para atender as necessidades atuais dos usuários e dos dispositivos modernos (DALMIA; CHOWDARY, 2020). Assim, o front-end desempenha um papel fundamental no desenvolvimento de sites, focando na interação funcional e na apresentação visual que conecta o usuário final à interface de forma acessível, funcional e clara. 2.3 MIDDLEWARE O termo middleware é amplamente conhecido no desenvolvimento de sistemas, destacando- se como uma camada intermediaria dinâmica e versátil, capaz de resolver problemas heterogê- neos e que tenham uma baixa compatibilidade tecnológica (GAZIS; KATSIRI, 2022). Em essên- cia, trata-se de um software que atua como mediador entre as aplicações, garantindo a com- patibilidade entre as interfaces e descomplicando a integração de componentes. Além disso, o middleware assume tarefas críticas, como a abstração da comunicação entre aplicativos, redes, hardware e a gestão de recursos entre aplicações e sistemas operacionais (EMMERICH, 2000). 20 Ao centralizar essas operações, especialmente em sistemas distribuídos, esse desenvolvimento reduz a carga dos desenvolvedores, eliminando assim a necessidade de conexões complexas e necessárias no futuro (STEEN; TANENBAUM, 2023). 2.4 PROXY O proxy é um serviço que age como um intermediário entre um dispositivo de um usu- ário e um servidor. Ele atua roteando as solicitações e respostas, ocultando informações impor- tantes do usuário e oferecendo funcionalidades de segurança, filtragem de conteúdos e otimi- zação de desempenho. A Seção 2.4.1 e a Seção 2.4.2 apresentam dois dos principais tipos de proxy atualmente existentes. 2.4.1 Proxy de Encaminhamento O proxy de encaminhamento, comumente chamado apenas de proxy, está presente nor- malmente na grande maioria das redes domésticas e corporativas, sendo uma solução tradicional de segurança de rede atuando como intermediário entre os clientes e a internet. A sua principal função é representar o usuário diante dos servidores externos, proporcionando o controle de acesso a recursos e auxiliando na otimização de tráfego. Essa estratégia possibilita, por exem- plo, limitar o acesso a determinados conteúdos, esconder o endereço IP dos clientes e otimizar o desempenho da rede ao guardar respostas frequentes. Apesar de sua eficácia em ambientes de menor escala, o proxy de encaminhamento pode apresentar algumas limitações e baixa efi- ciência em ambientes com grande volume de tráfego e demandas mais complexas (KOVACS, 2024). 2.4.2 Proxy Reverso O proxy reverso pode ser considerado o oposto do proxy de encaminhamento, atuando como um servidor intermediário que recebe as solicitações dos clientes e as destina para os servidores internos, sem que o usuário perceba essa intermediação. Diferentemente do proxy de encaminhamento, que é configurado no navegador, o proxy reverso atua no lado do servidor de forma transparente, conforme ilustrado na Figura 2. O autor aborda três padrões principais para uso do proxy reverso: Protection Reverse Proxy, realiza a proteção dos servidores contra ataques de nível do protocolo da aplicação, isolando a infraestrutura em uma Zona Desmilitarizada (DMZ) e filtrando as requisições; Integration Reverse Proxy permite a integração de diversos servidores através de um único ponto de entrada, garantindo a estabilidade de URLs para os usuários e ocultando a estrutura interna do servidor; Front Door centraliza as autenticações dos usuários e atua no gerenciamento das sessões, permitindo login único para múltiplas aplicações. Destaca-se também outros benefícios que o proxy reverso pode oferecer, como flexibilidade na gestão da infraestrutura, aumento da segurança e redução de custos com certificados Secure 21 Sockets Layer (SSL). Em contrapartida, aponta desvantagens como a criação de um ponto único de falha, inclusão de latência e cuidados reforçados na configuração e manutenção do sistema (SOMMERLAD, 2003). Outra função importante que o proxy reverso pode desempenhar é na implementação de estratégias de balanceamento de carga entre múltiplos servidores back-end. A forma mais sim- ples de realizar o balanceamento é através do revezamento das requisições de maneira sequen- cial entre os servidores, abordagem conhecida como round robin. Estratégias mais aprimoradas podem contar com análises de estatísticas, como por exemplo a carga de processamento ou o tempo de resposta de cada servidor, para orquestrar de forma mais eficiente as requisições. O autor evidencia que, em aplicações que preservam as sessões de usuário, é importante garantir a nomeada "session stickiness", enviando todas as requisições de um mesmo usuário ao mesmo servidor, com a intenção de preservar a integridade da sessão. Deste modo, o proxy reverso além de integrar os sistemas, também contribui com a escalabilidade e a disponibilidade da infraestrutura (SOMMERLAD, 2003). Figura 2 – Exemplo de um proxy reverso Fonte: (SOMMERLAD, 2003) 22 23 3 TRABALHOS CORRELATOS Esta seção aborda trabalhos cujas problemáticas e soluções estejam relacionados com a proposta deste trabalho, ainda que aplicadas em domínios distintos do conhecimento. Foi realizada uma pesquisa bibliográfica sistemática com o objetivo de identificar tra- balhos relacionados à integração de sistemas legados ou ao desenvolvimento de aplicações para o ensino. A investigação priorizou trabalhos publicados nos últimos 5 anos, abrangendo as se- guintes bases de dados: Google Acadêmico, ResearchGate e ScienceDirect. Os termos de busca utilizados incluíram Legacy system, interoperability, integration, middleware, development of educational software, reverse proxy e load balance, visando recuperar artigos que abordassem tanto aspectos técnicos de interoperabilidade entre sistemas legados quanto soluções tecnológi- cas aplicadas ao contexto educacional. A Tabela 1 exibe a relação dos artigos selecionados, que serão abordados a seguir. Tabela 1 – Artigos selecionados que de alguma forma se relacionam com o presente trabalho Título Referência Fonte Seção A taxonomy of service identification approaches for legacy software systems modernization. (ABDELLATIF et al., 2021) ScienceDirect Seção 3.1 Upgrading of legacy systems to cyber- physical systems. (KUTSCHER et al., 2020) ResearchGate Seção 3.1 Integração de sistemas legados e atuais em instituição de registro público utili- zando um Gateway para comunicação de diferentes plataformas (OLIVEIRA et al., 2022) Brazilian Journal of Development Seção 3.1 Integração de Sistemas Legados para Aprendizado a Distância: Estudo de Caso em Planejamento de Sistemas Móveis Celulares. (MIRANDA, 2003) LEA UFPA Seção 3.1 Software modernization powered by dynamic language product lines (CAZZOLA; FAVALLI, 2024) ScienceDirect Seção 3.1 Evaluation of technical approaches for real-time data transfer from electronic health record systems. (KIRILOV; DUGAS, 2024) ScienceDirect Seção 3.2 Cost-effective server-side re- deployment for web-based online laboratories using nginx reverse proxy. (LEI et al., 2020) ScienceDirect Seção 3.2 A new remote web-based msplus data visualization system for east. (ZHANG et al., 2023) ResearchGate Seção 3.2 ALGO+ Uma ferramenta para o apoio ao ensino de Algoritmos e Programação para alunos iniciantes. (AMARAL et al., 2017) ScienceDirect Seção 3.3 LIBRAS Game: Trabalhando o ensino da matemática com alunos surdos dos anos iniciais através do uso de aplica- tivo educacional. (PRATES, 2018) Repositório UTFPR Seção 3.3 Fonte: O Autor (2025). A Seção 3.1 apresenta cinco estudos que exploram as abordagens existentes para a inte- gração de sistemas legados, com foco em estratégias que permitem a disponibilidade de sistemas antigos e novas soluções, garantindo a continuidade dos serviços e a evolução tecnológica. A Seção 3.2 contém três artigos, onde os autores apresentam soluções com a utilização de proxy reverso, permitindo o funcionamento simultâneo de diferentes versões, unificando o acesso, proporcionando segurança e escalabilidade. A Seção 3.3, por sua vez, possui dois estudos que trazem ferramentas desenvolvidas para auxiliar no processo de aprendizagem dos estudantes, demonstrando como a tecnologia é fundamental no processo de ensino, para torna-lo mais convidativo e eficiente. 3.1 INTEGRAÇÃO DE SISTEMAS LEGADOS De forma resumida, os artigos abordados nessa seção tiveram como objetivo apresentar estudos com foco na integração de sistemas já consolidados. Abdellatif et al (2021) desenvolve- ram uma revisão sistemática da literatura na qual analisaram primeiramente 3246 publicações e selecionaram 41 trabalhos mais relevantes, focadas em sistemas legados. Os autores criaram uma taxonomia multicamadas que realiza a classificação em quatro dimensões principais: grau de usabilidade, processos de identificação adotados, artefatos de entradas utilizados, como casos de uso, código fonte, banco de dados e etc, e os tipos de serviços gerados como saída. Alguns trabalhos analisados pelos autores apresentam estratégias de integração com sistemas existen- tes, analisando técnicas como a geração de interfaces REST, padrões de projetos wrappers e reutilização de código orientado a objeto, preservando a lógica de negócio testada e validada ao longo dos anos, evitando os riscos, esforços e custos da reescrita completa. Dessa forma, possi- bilitando que sistemas antigos continuem operando enquanto são progressivamente integrados a novas arquiteturas. O estudo realizado por Kutscher et al., (2020) propõe uma metodologia de cinco etapas para modernização de sistemas legados e validou essa proposta integrando um CNC laser plot- ter para um Sistemas Ciberfísicos (CPS) da Indústria 4.0. Na primeira etapa foi feita a análise do estado inicial, onde os autores começaram identificando a estrutura e os recursos da má- quina, por exemplo a máquina não possuía qualquer capacidade de comunicação, interação ou virtualização. Para o segundo passo foi realizada a identificação das necessidades de integração, para poder definir o que precisaria ser adicionado, como comunicação com outros sistemas, cri- ação de uma interface de acesso remoto e padronização dos dados da máquina. Já no terceiro passo constituiu a escolha da tecnologia, a escolhida foi o Open Platform Communications Unified Architecture (OPC UA), criando um servidor embarcado conectado à máquina para a comunicação e modelagem dos dados. No quarto passo aconteceu o desenvolvimento da inte- gração, onde os autores instalaram o servidor OPC UA em Python conectado a CNC, criando um modelo virtual da máquina no servidor, permitindo que os dados dos sensores e comandos da máquina fossem monitorados e passados para o cliente externo OPC UA. Posteriormente, no quinto e último passo, validou-se os resultados obtidos em um cenário real, com um destaque positivo. Após realizar todas as etapas da metodologia, o autor ressalta que a migração de sis- temas legados a CPS é eficaz e oferece um caminho prático e reutilizável, mantendo a estrutura 24 do sistema legado com a nova integração moderna. Oliveria et al. (2022) abordou um estudo sobre a integração entre sistemas legados e web modernos de uma instituição pública estadual. O objetivo do artigo foi realizar a aplicação de uma arquitetura baseada em gateway para garantir a interoperabilidade de plataformas hete- rogêneas, evitando a reescrita ou a necessidade de substituição completa do sistema antigo, por intermédio de um middleware, essa abordagem dialoga com a proposta do presente trabalho. O desenvolvimento foi composto por dois componentes principais, o módulo nomeado JS e o módulo CTG (CICS Transaction Gateway), fornecida pela IBM. O módulo JS é constitu- ído por duas camadas: uma em .NET(C#) e outra em Java, que se comunicavam através de web services com os dados em Linguagem de Marcação Extensível (XML). Essa comunicação é o elemento central da integração entre os sistemas, pois é por ela que os dados trafegam da nova interface web até o backend. A primeira camada da estrutura, em .NET(C#), fica responsável por receber os dados da aplicação web, padronizando-os e convertendo para o formato XML, após são transmitidos para a segunda camada do middleware em Java, sobre o servidor Jboss. Nesta etapa, os web services são importantes para garantir a interoperabilidade entre os dife- rentes ambientes e linguagens, realizando validações adicionais e delegando as chamadas para o CICS. As respostas obtidas por ele são convertidas novamente em XML e percorrem o cami- nho inverso, retornando por todas as camadas anteriores até alcançar a interface web, conforme exibido na Figura 3. Dessa maneira, os web services garantem a conexão entre as diferentes plataformas mantendo o isolamento das camadas, que favorece a manutenção, escalabilidade e segurança (OLIVEIRA et al., 2022). A relevância deste trabalho está na forma que o projeto lida com a integração dos sis- temas legados, funcionando paralelamente com os sistemas modernos. A ideia de preservar o sistema já consolidado e adicionar uma nova camada, por meio de um gateway de integração com web services, apresenta a viabilidade e os benefícios do modelo. Figura 3 – Middleware que permite a integração entre os sistemas Fonte: (OLIVEIRA et al., 2022) 25 Miranda (2003) visou unificar os quatro módulos do sistema CELLP, originalmente di- vididos em ambientes heterogêneos como Delphi (Windows) e Kylix (Linux), utilizando uma solução de middleware baseada na arquitetura Arquitetura de Corretor de Objetos de Requisição Comum (CORBA) para a integração dos sistemas. A estratégia constituiu no encapsulamento de cada módulo como um objeto distribuído, por meio de interfaces padronizadas chamadas Linguagem de Definição de Interface (IDL), responsáveis pela comunicação entre os módu- los, descrevendo os métodos e parâmetros necessários, independente da linguagem ou sistema operacional. Para tornar o sistema acessível via web, foi acrescentado ao middleware os web services baseados no protocolo Protocolo Simples de Acesso a Objetos (SOAP). Isso permitiu que as requisições HTTP, do navegador, fossem convertidas em chamadas CORBA e posteri- ormente direcionadas aos servidores, que após o processamento dos dados, respondiam através do formato XML, possibilitando assim a manipulação e visualização dos dados diretamente da nova interface web. O resultado dessa integração foi o WebCELLP, uma plataforma unifi- cada que auxiliou os alunos no aprendizado das disciplinas, passando a interagir com todos os módulos integrados a apenas uma interface web, executando projetos práticos de planejamento de redes celulares de forma semipresencial. A modernização realizada por Miranda manteve os sistemas legados em pleno funcionamento, enquanto adicionava uma camada intermediária para comunicação distribuída, preservando suas funcionalidades originais e garantindo a con- tinuidade do serviço durante a transição. A comunicação via XML poderia ser trocada pelo Notação de Objetos JavaScript (JSON), mais leve e muito utilizado atualmente. A arquitetura seguiu o padrão de desenvolvimento Modelo-Visão-Controlador (MVC), separando as camadas de apresentação, controle e negócios. Essa escolha facilitou a manutenção, a modularidade e a expansão do sistema. Ademais, Cazzola e Favalli (2024) propuseram a utilização de um método baseado em Dynamic Language Product Lines (DLPL), que sem interromper o funcionamento do sistema, permitiu a modernização progressiva do sistema legado. Utilizando uma ferramenta de desen- volvimento de linguagens, o compilador do sistema legado em COBOL foi reestruturado para micro-linguagens modulares, permitindo a construção de variantes que interpretavam o código antigo e o novo, essa estratégia criou três variantes: uma para o novo código Java, uma para o código legado e uma híbrida, responsável por permitir a interoperabilidade dos sistemas. Dessa forma, se tornou possível executar os trechos atualizados enquanto o restante do sistema conti- nuava operando. Alguns testes foram feitos para demonstrar que a transição entre as linguagens COBOL e Java ocorriam de maneira concisa, como por exemplo a implementação de múltiplas versões do sistema, cada uma com uma etapa da modernização, garantindo assim um processo de migração contínuo, seguro e sem a reescrita total do sistema. Os estudos apresentados nessa seção demonstram diferentes formas de realizar integra- ções e modernizações de sistemas legados, conservando suas funcionalidades essenciais en- quanto introduzem novas camadas de interoperabilidade e comunicação. Essa forma de evolu- ção, utilizando um middleware, web services ou gateways, interage diretamente com a proposta 26 do presente trabalho, que visa integrar dois sistemas heterogêneos, um legado de interface desk- top com uma nova interface web, preservando a operação contínua do ambiente existente. Dessa forma, como nos trabalhos analisados, os projetos buscam garantir a disponibilidade entre as plataformas heterogêneas, reduzindo riscos e custos de reconstrução, utilizando soluções de integração que permitem a convivência harmônica entre o antigo e as novas tecnologias do mercado. 3.2 MEDIADOR PARA INTEGRAÇÕES DE SISTEMAS HETEROGÊNEOS Sob distintas perspectivas, autores apresentam a reestruturação e modernização de sis- temas voltados a experimentos científicos, fazendo o uso de novas tecnologias como o servidor NGINX. Um estudo recente conduzido por Kirilov e Dugas (2024), realizou uma análise com- parativa para quatro métodos distintos de entrega de dados em tempo real (RTD) em sistemas de prontuário eletrônico (EHR): proxy reverso, WebSocket Notifications, REST Hooks e data- base triggers. O estudo possibilita uma avaliação técnica e detalhada sobre viabilidade de cada abordagem, por fornecer as implementações práticas e mensurações precisas dos desempenhos. O foco do presente trabalho recai sobre o uso de proxy reverso como uma camada in- termediária de comunicação entre o sistema legado e a nova interface web. O método testado pelo artigo demonstra que o proxy reverso viabiliza a comunicação entre sistemas de maneira transparente e também apresenta um considerável desempenho em termos de variabilidade e latência. Diante dos testes realizados nos quatro métodos, o proxy reverso teve latência média de 14,43 ms e um desvio padrão de apenas 4,58 ms, indicando um bom desempenho e estabilidade. Embora o método de database triggers tenha apresentado menor latência média (13,52 ms), o proxy reverso apresentou valores máximos mais baixos e menor variabilidade, mostrando que pode ser mais adequado em cenários que a previsibilidade e estabilidade são fatores tão im- portantes quanto velocidade. Ao simular com condições realistas o sistema de produção, com até 100 clientes simultâneos e crescente volume de dados, o uso do proxy reverso continuou oferecendo um comportamento firme. Nos cenários de pacotes com 160 recursos transferidos, a latência média foi de 268,04 ms, vencendo REST hooks (8172,83 ms) e WebSockets (388,96 ms) em confiabilidade e escalabilidade. O motivo desse desempenho pode estar lincado à capa- cidade do proxy em desacoplar a entrega de notificações em tempo real da lógica do servidor, permitindo otimizações como cache, balanceamento, segurança e distribuindo carga de maneira positiva (KIRILOV; DUGAS, 2024). Explorando a arquitetura, o proxy foi implementado utilizando a linguagem Golang, com a biblioteca httputil, fazendo papel de um middleware. Ele intercepta as requisições para o servidor FHIR, verifica as respostas e, ao identificar a criação ou alteração de dados, envia notificações ao sistema consumidor, conforme apresentado na Figura 4. Dessa forma, o mo- 27 delo garante que o sistema backend permaneça separado, evitando assim a exposição direta e simplificando a aplicação de políticas de autenticação, auditoria e filtragem (KIRILOV; DUGAS, 2024). Além da performance, o proxy reverso também apresenta alguns pontos positivos rela- cionados à segurança e manutenção, atuando como ponto de controle centralizado, limitando acessos a endpoints internos, realizando o balanceamento de carga do servidor, monitoramento de uso e isolamento de falhas, recursos que podem ser críticos em ambientes com vários siste- mas concorrendo por um mesmo acesso ao backend. Em conclusão, os experimentos práticos realizados por Kirilov e Dugas comprovam a eficiência e estabilidade que pode ser alcançada utilizando proxy reverso, e também o posicionam como uma alternativa viável equilibrada entre performance, segurança e escalabilidade para sistemas que exigem entrega para múltiplos con- sumidores. Devido ao contexto do seguinte trabalho, que aborda a integração entre um sistema legado e um novo sistema web, o uso do proxy reverso se mostra tecnicamente amparado e comprovadamente eficiente, sendo uma base firme para o uso em uma arquitetura de um mid- dleware. Figura 4 – Arquitetura do proxy reverso para a realização dos testes. O tempo é medido pelos timestamps Fonte: (KIRILOV; DUGAS, 2024) LEI et al. (2020) apresentam a reconstrução do servidor para o laboratório remoto NCS- Lab, unificando os dois sistemas existentes, o antigo sistema (YUI/Tomcat) era acessado através da url "/ncslab"e o novo desenvolvido (React/NGINX+PHP) com "/react". Estes domínios dis- tintos geravam alguns problemas operacionais, como duplicação de certificados HTTPS, maior exposição a ameaças de segurança e conflitos de recursos web. A solução apresentada utilizou NGINX como proxy reverso para realizar a unificação dos acessos através de um único domínio. Conforme apresentado na Figura 5, a arquitetura implementada ilustra como o NGINX atua como intermediário entre os usuários e o sistema backend consolidado, após a implemen- tação as requisições são direcionadas de forma transparente, delegando as chamadas de cada URL para seus respectivos servidores, simplificando a infraestrutura e auxiliando na redução de custos. Os resultados obtidos pelo autor, mostram que a utilização do proxy reverso é eficaz 28 para a unificação de sistemas, redução do tempo de implementação e de custos com infraes- trutura, mantendo a compatibilidade dos sistemas legados conforme as novas ferramentas vão evoluindo (LEI et al., 2020). Figura 5 – Ilustração da reimplantação de servidores NCSLab Fonte: (LEI et al., 2020) Ainda, ZHANG et al. (2023) discutem sobre a criação de um novo sistema web para leitura das informações do Tokamak EAST, projeto de fusão nuclear, que gera um grande volume de dados a cada disparo experimental. Objetivando promover uma interface moderna e acessível a qualquer dispositivo, visando superar as limitações de soluções anteriores, permitindo o acesso de múltiplos usuários simultaneamente e possibilitando a integração com novos componentes e tornando o projeto escalável. O início do processo envolve o armazenamento dos dados coletados no sistema MD5Plus, acessados através do protocolo MDSip pelo backend Java, que aproveita a tecnologia de multith- reading para garantir que as múltiplas requisições sejam tratadas corretamente, sem prejudicar o desempenho da ferramenta. O Java entrega o serviço de clusterização, disponibilizando várias instâncias de servidor, garantindo a escalabilidade necessária para suportar o grande número de requisições, que por sua vez são encaminhadas ao servidor correto através do proxy reverso (ZHANG et al., 2023). Atuando como proxy reverso, o NGINX trabalha de forma intermediária entre os usuá- rios e os servidores backend, permitindo que o balanceamento de carga ocorra através do algo- ritmo Weighted Round-Robin, no qual cada servidor recebeu um peso de acordo com a sua capa- 29 cidade de processamento, ilustrado na Figura 6. O NGINX distribuiu cada requisição de forma proporcional a esses pesos, priorizando os servidores mais potentes. Dessa forma, ocorreu uma distribuição equilibrada do tráfego, garantindo que nenhum servidor ficasse ocioso enquanto outros estivessem sobrecarregados. Alguns fatores importantes mencionados pelos autores no ponto de vista de segurança, dão conta que o NGINX foi utilizado também para realizar a se- paração de recursos estáticos e dinâmicos, possibilitando que os usuários acessem apenas os recursos públicos, atuou no encaminhamento de requisições controladas, evitando acessos não autorizados ou fora do escopo previsto, e na segregação das comunicações, permitindo que as requisições fossem feitas apenas por portas de rede confiáveis e seguras. A efetividade do estudo apresentado foi comprovada nos 21 sinais pulsados nos experimentos, onde o sistema eviden- ciou o baixo consumo de memória e uma alta taxa de resposta mesmo com um grande volume de dados, conseguindo exibir os sinais com menor latência, maior escalabilidade e eficiência (ZHANG et al., 2023). Figura 6 – Diagrama geral dos servições EAST Fonte: (ZHANG et al., 2023) Os trabalhos citados anteriormente dão conta que a utilização de um proxy reverso é uma solução eficaz, auxiliando no reforço da segurança dos sistemas e no controle das requisições. Pelos testes realizados, é interessante notar a capacidade positiva de centralizar o acesso por um único meio, controlando o fluxo dos dados e protegendo os servidores internos de acesso diretos não esperados, aspectos que se destacaram nas abordagens dos diferentes autores. Desta forma, é possível observar que adotar o uso de um proxy reverso faz sentido no desenvolvimento do presente trabalho, uma vez que é necessário manter dois sistemas rodando sobre um mesmo servidor, sem problemas operacionais. Além disso, a utilização de um proxy reverso permitirá ocultar as informações sensíveis do servidor, acrescentando uma camada a mais de proteção. 3.3 APLICAÇÕES VOLTADAS AO ENSINO Amaral et al. 2017 apresentam o desenvolvimento de um sistema web Algo+, focado em apoiar o processo de ensino e aprendizagem de lógica e programação. O principal objetivo foi 30 construir uma ferramenta que auxiliasse os alunos iniciantes a superar as tradicionais barreiras das disciplinas introdutórias da área da computação, diminuindo a alta taxa de evasão e repro- vação. Com esse objetivo, a construção foi fundamentada em teorias de aprendizagem, como por exemplo o Ciclo de Aprendizagem Experiencial de Kolb (KOLB, 2014), com a intenção de atender diferentes estilos cognitivos, com uma estrutura adaptativa, motivadora e clara. As etapas de desenvolvimento iniciaram com a definição do problema, seguido por uma revisão de literatura, responsável por sustentar a proposta. Em seguida, foi conduzida a escolha da tecnologia, o projeto, a implementação e a validação da ferramenta. O Algo+ foi desenvol- vido como um sistema web, disponível através do navegador, consequentemente eliminando a instalação de qualquer software pelo usuário. A ferramenta contempla duas interfaces princi- pais, uma destinada à administração e controle do ambiente e outra ao uso comum para alunos e professores (AMARAL et al., 2017). Ainda, a lista com as tecnologias utilizadas na implementação do portal e em seguida a Figura 7 ilustra a arquitetura projetada e desenvolvida. • HTML5 como base estrutural das páginas web. • CSS utilizado para definir estilos visuais da interface de usuário. • jQuery como framework JavaScript para manipulação dinâmica da interface e dos formu- lários. • PHP no lado do servidor, para realizar o processamento das informações, notas, atividades e controle de usuários. • MySQL foi utilizado como banco de dados para garantir o armazenamento das informa- ções de forma segura e eficiente. Para obter o melhor desempenho de aprendizagem, a organizações dos conteúdos apre- sentados pelo Algo+ foi estruturada em módulos, seguindo uma sequencia lógica e alinhada às etapas do ciclo de Kolb, que visam sentir, observar, pensar e fazer. Cada um dos módulos pos- suem o material teórico, atividades formativas, multimídia e avaliações automáticas, que permi- tem a construção do conhecimento dos alunos de maneira progressiva. Alguns paradigmas de programação foram implementados, como o desenvolvimento visual com Scratch, programação estruturada com a linguagem C e o desenvolvimento para dispositivos móveis com AppInventor (AMARAL et al., 2017). Já o processo de validação foi realizado por meio de experimentos com duas turmas das disciplinas de algoritmos e programação envolvendo 47 estudantes. Os resultados mostraram que o desempenho da nova ferramenta foi similar ao desempenho em exames presenciais, indi- cando a efetividade do ambiente no suporte ao aprendizado independente. Com isso, a aplicação 31 evidenciou seu potencial como uma solução híbrida, atuando no apoio de professores e no es- tudo autônomo dos alunos que desejam aprimorar suas habilidades em programação e lógica (AMARAL et al., 2017). Figura 7 – Arquitetura do portal Algo+ Fonte: (AMARAL et al., 2017) Outro trabalho que vale destacar é o LIBRAS Game, que teve como objetivo desenvol- ver um aplicativo mobile educacional que auxiliasse o ensino de números de 1 a 9, para crianças surdas dos anos iniciais. O projeto desenvolvido foi dividido em etapas, como levantamento de requisitos, projeto, implementação, testes e validação. O aplicativo busca facilitar a associação entre numerais, quantidades e sua representação em Língua Brasileira de Sinais (LIBRAS). O desenvolvimento utilizou a Ambiente de Desenvolvimento Integrado (IDE) do Android Stu- dio como ambiente principal, e fez uso do Java como linguagem de programação, XML para construção de interfaces e utilizado o software livre GIMP 2.8 para a criação e edição das ima- gens do app. Todos os testes do aplicativo foram realizados em um computador com sistema operacional Debian e um celular Samsung J5 utilizando Android. Ao realizar os testes com os usuários que não possuíam domínio da LIBRAS, o aplicativo demonstrou êxito, visto que os participantes conseguiram reconhecer os números no final das atividades (PRATES, 2018). Assim como o Algo+ e o LIBRAS Game, o presente trabalho busca atuar no processo de aprendizagem de alunos por meio de desenvolvimentos tecnológicos, propondo igualmente o uso de ferramentas digitais para tornar o ensino mais acessível, eficiente e motivador. Ambas iniciativas apresentam preocupação em reduzir as dificuldades padrões enfrentadas no processo de formação dos alunos, apenas diferenciam-se nos públicos alvo e nas áreas do conhecimento, porém evidencia como a integração entre a tecnologia e educação pode ser aplicada em diferen- tes contextos pedagógicos. 32 33 4 PROPOSTA DE SOLUÇÃO O objetivo deste trabalho foi propor e desenvolver uma solução para integrar uma apli- cação web a um sistema legado, de forma a permitir a comunicação entre a nova interface web e o backend já consolidado da ferramenta WebAlgo. Essa solução preservou a lógica de negócio do sistema de APIs existente, ao mesmo tempo em que proporcionou uma nova experiência de uso por meio da nova interface web. Optou-se por utilizar um middleware para realizar a integração, atuando como uma ponte entre o frontend e o backend, encapsulando a lógica de negócio. Dessa forma, a nova interface web não interagiu diretamente com o servidor, mas com o middleware, responsável por tratar e direcionar as requisições conforme necessário. Além disso, foi utilizado um proxy reverso como parte da arquitetura da solução, com papel fundamental na organização do tráfego entre os componentes, funcionando como ponto único e controlado de entrada para requisições externas. Com isso, foi possível ocultar detalhes da infraestrutura interna e proteger o backend de acessos diretos, além de viabilizar a configuração de um balanceador de carga para cenários com mais de um servidor interno. A Figura 8 ilustra a arquitetura implementada, evidenciando o papel do middleware na mediação entre os componentes da solução e o NGINX como proxy reverso, responsável também pelo balanceamento de cargas. Figura 8 – Arquitetura da solução Fonte: O Autor (2025) 4.1 DIAGRAMA DE CASOS DE USO Um caso de uso define como um ator interage com o sistema por meio de determinadas ações. Os atores são agentes externos, como pessoas ou outros sistemas, que interagem com o sistema executando um caso de uso (WIEGERS; BEATTY, 2013). Os diagramas são agrupadores de casos de uso, apresentando o título dos casos mapeados e sua relação com um ou mais atores (ROSENBERG; STEPHENS, 2007). Nesta seção, foram apresentados três casos de uso conforme previsto no processo ICO- NIX, a fim de exemplificar o funcionamento das APIs e demonstrar a integração entre a nova interface web moderna e o backend consolidado. Está presente no detalhamento de casos de uso apenas o viés do usuário, pois o serviço HTTP do backend consolidado não possuía uma distinção clara entre usuários administradores e alunos. O levantamento dos casos de uso apre- sentados na Figura 9 foi realizado com base na análise das funcionalidades disponíveis na nova interface web, em conjunto com as APIs existentes no servidor interno. Dessa maneira, as fun- cionalidades que não estavam presentes no diagrama refletiram a ausência de implementação na interface web naquele momento e, por esse motivo, não foram mapeadas como casos de uso neste contexto. Figura 9 – Diagrama de caso de uso do sistema Fonte: O Autor (2025) 4.1.1 DETALHAMENTO DE CASOS DE USO Nesta etapa, foram detalhados os casos de uso relacionados ao domínio de usuário, contemplando as funcionalidades essenciais para autenticação e gerenciamento de acessos. A Figura 10 apresenta os mockups das telas de login e cadastro de usuários, ilustrando a interface 34 inicial do sistema. As interações representadas refletiram os fluxos definidos nos casos de uso e serviram como base para a implementação efetiva da interface web. Figura 10 – Lado A: Tela de login. Lado B: Tela de cadastro Fonte: O Autor (2025) 4.1.1.1 Caso de Uso UC-01 realizar Login No lado A da Figura 10, encontra-se o modelo de interface gráfica referente ao caso de uso UC-01 – Realizar Login. O detalhamento deste caso de uso foi apresentado no Quadro 1 e a Figura 11 exibiu o respectivo diagrama de sequências. 4.1.1.2 Caso de Uso UC-02 realizar cadastro No lado B da Figura 10, encontra-se o modelo de interface gráfica referente ao caso de uso UC-02 – Realizar cadastro. O detalhamento deste caso de uso foi apresentado no Quadro 2 e a Figura 12 exibiu o seu diagrama de sequências. 35 Figura 11 – Diagrama de sequência do Login Fonte: O Autor (2025) Figura 12 – Diagrama de sequência do cadastro Fonte: O Autor (2025) 36 Quadro 1 – UC-01 Realizar Login Código e Descrição UC-01 Realizar Login Ator Usuário Descrição Permite que um usuário realize a autenticação no sis- tema por meio do envio de nome de usuário e senha. RF Associados RF-01 Pré-Condições O usuário deve estar previamente cadastrado no sis- tema. Pós-Condições Usuário autenticado, com sessionid e nome armazena- dos localmente. Fluxo principal 1. Usuário acessa a tela de login. 2. Usuário informa nome de usuário e senha. 3. Sistema envia requisição POST para o endpoint /logUsuario. 4. Sistema recebe a resposta do servidor. 5. Sistema armazena o cookie de sessão e extrai o ses- sionid. 6. Sistema autentica o usuário. Fluxos alternativos Falha na autenticação: 4.a) Servidor retorna erro de autenticação. - Sistema informa que os dados estão incorretos. Sem resposta do servidor: 4.b) Ocorre erro de comunicação (timeout ou falha HTTP). - Sistema informa falha de conexão. Cookies não recebidos: 4.c) Sistema não consegue recuperar Set-Cookie. - Usuário é informado sobre falha ao autenticar. Fonte: Autor (2025) 37 Quadro 2 – UC-02 Realizar cadastro Código e Descrição UC-02 Realizar Cadastro Ator Usuário Descrição Permite que um usuário realize o cadastro no sistema, for- necendo seus dados pessoais e de acesso. RF Associados RF-02 Pré-Condições O usuário não deve estar previamente cadastrado no sis- tema. Pós-Condições Usuário cadastrado, podendo realizar login com o usuário e senha informados. Fluxo principal 1. Usuário acessa a tela de cadastro. 2. Usuário preenche os campos: login, senha, nome, sobre- nome, e-mail, sexo, cidade, estado (UF) e observação. 3. Sistema envia requisição POST para o endpoint /cadUserp. 4. Sistema recebe a resposta do servidor. 5. Sistema informa ao usuário que o cadastro foi realizado com sucesso. Fluxos alternativos Falha no cadastro: 4.a) Servidor retorna erro. – Sistema informa o erro ao usuário (ex: login já existente ou dados inválidos). Sem resposta do servidor: 4.b) Ocorre erro de comunicação (timeout ou falha HTTP). – Sistema informa falha de conexão. Fonte: O Autor (2025) 38 4.1.1.3 Caso de Uso UC-03 buscar exercício A Figura 13 ilustra a interface gráfica referente ao caso de uso UC-03 – Buscar exercí- cio, responsável por permitir que os alunos localizassem os exercícios de algoritmos disponíveis para desenvolvimento. O detalhamento deste caso de uso foi apresentado no Quadro 3 e a Fi- gura 14 exibiu o respectivo diagrama de sequências. Quadro 3 – UC-03 Buscar exercícios Código e Descrição UC-03 Buscar exercícios Ator Usuário Descrição Permite selecionar um tipo de algoritmo e visualizar os problemas disponíveis, a fim de carregá-los na página. RF Associados RF-03 Pré-Condições Estar na interface de seleção de algoritmos. Pós-Condições Algoritmo selecionado carregado na página. Fluxo principal 1. Usuário acessa a interface de seleção. 2. Sistema exibe tipos de algoritmos. 3. Usuário seleciona o tipo. 4. Sistema envia POST para /buscaProblemasChave. 5. Recebe e exibe a lista de problemas. 6. Usuário escolhe um problema e clica em Carregar. 7. Sistema envia POST para /dadosProblema. 8. Sistema retorna os dados e carrega o algoritmo. Fluxos alternativos Erro ao buscar problemas: 4.a) Erro na busca – Sistema informa “Não foi possível carregar os problemas”. Falha de conexão: 4.b) Timeout ou erro HTTP – Sistema informa falha de conexão. Fonte: O Autor (2025) Figura 13 – Menu para busca de exercícios Fonte: O Autor (2025) 39 Figura 14 – Diagrama de sequência para busca de exercícios Fonte: O Autor (2025) 4.2 VALIDAÇÃO DA PROPOSTA DE ARQUITETURA Com a finalidade de avaliar o funcionamento das requisições HTTP do sistema de APIs existente e identificar possíveis problemas nas chamadas realizadas, foram conduzidos testes utilizando a ferramenta curl, que permite simular chamadas HTTP diretamente via terminal, acessando o endereço exposto endereco.com.br. O levantamento das chamadas foi realizado por meio da análise do código-fonte do WebAlgo, complementado pelas informações obtidas no trabalho desenvolvido por Adriano (MARGARIN, 2018). A seguir, são descritas as etapas executadas durante o experimento. Inicialmente, foi realizada uma requisição POST para o endpoint /logUsuario, contendo os parâmetros username e password no corpo da requisição. Também foram adicionados cabe- çalhos HTTP importantes para simular chamadas do tipo AJAX, como Content-Type, Referer e X-Requested-With, conforme apresentado no exemplo a seguir: curl -v --insecure \ -H "Referer: https://endereco.xx.xx/" \ -H "X-Requested-With: XMLHttpRequest" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "username=test&password=test" \ https://endereco.xx.xx/logUsuario 40 Como resposta, o servidor retornou o código HTTP/1.1 200 OK e o cabeçalho de res- posta contendo o cookie de sessão, denominado sessionId, evidenciando o sucesso na auten- ticação do login. Esse identificador foi utilizado para validar as requisições subsequentes do usuário, permitindo que ele permanecesse autenticado enquanto interagia com o sistema. No entanto, não foi possível constatar se o cookie possuía um tempo de expiração, permanecendo válido até que o usuário realizasse o logout ou ocorresse a reinicialização do servidor. Assim, para que a nova interface web mantivesse a sessão ativa, a solução implementada consistiu em armazenar temporariamente o sessionId no navegador, por meio do Session Storage, preser- vando os dados enquanto a aba permanecia aberta. Dessa forma, a cada requisição realizada ao servidor interno, o valor do cookie era recuperado do Session Storage e enviado no cabeçalho HTTP, garantindo que a comunicação permanecesse autenticada durante o uso da aplicação. Além do cookie de sessão, o retorno também continha um objeto JSON, responsável por iden- tificar o usuário ativo, conforme apresentado a seguir: Set-Cookie: sessionid=19f1f5065f8ec5cf1429a2d8797b9669; {"respostas": "test"} Os valores retornados, sessionId e a resposta com o user, foram posteriormente utiliza- dos para testar a finalização da sessão do usuário. A chamada HTTP de logout foi executada por meio de uma nova requisição curl, desta vez incluindo, no cabeçalho Cookie, os valores obtidos anteriormente durante o processo de autenticação: curl -v --insecure \ -H "Referer: https://endereco.xx.xx/" \ -H "X-Requested-With: XMLHttpRequest" \ -H "Content-Type: application/x-www-form-urlencoded" \ -H "Cookie: sessionid=19f1f5065f8ec5cf1429; name=test" \ -d "username=nada&password=nada" \ https://endereco.xx.xx/logoutPortal A resposta foi recebida com sucesso, apresentando novamente o código HTTP/1.1 200 OK e o objeto JSON no corpo da resposta, confirmando a finalização da sessão do usuário. {"logout": "test"} Além disso, foram realizados testes complementares utilizando a ferramenta Postman. Inicialmente, as chamadas não funcionaram devido a algumas configurações padrão da ferra- menta, como a omissão de certos cabeçalhos personalizados e a validação automática de certi- ficados SSL. Após os devidos ajustes, foi possível validar as requisições com sucesso, confir- mando que a autenticação e o encerramento da sessão também funcionaram corretamente por meio dessa interface. 41 Dessa forma, os testes confirmaram que o sistema manteve uma estrutura de autentica- ção baseada em sessões válidas por meio dos cabeçalhos HTTP, evidenciando que interações diretas com o servidor puderam ser realizadas por um agente externo — aspecto essencial para a validação técnica da camada de middleware implementada para integrar a nova interface web ao sistema existente. 4.3 ANÁLISE DA SOLUÇÃO ARQUITETURAL O middleware de teste foi construído utilizando Java 19 e o framework Spring Boot, sendo responsável por receber as chamadas da interface web. O NGINX desempenhou o pa- pel de proxy reverso e balanceador de carga, distribuindo as requisições do frontend entre as múltiplas instâncias do middleware. Por fim, o Docker foi empregado para empacotar todos os serviços, viabilizando sua execução de forma isolada e padronizada em qualquer ambiente com suporte a contêineres. Para testar a comunicação entre a nova interface web e o middleware, foi projetada uma estrutura baseada em contêineres utilizando o Docker. Essa abordagem, além de atender ao propósito dos testes, priorizou a facilidade de manutenção, escalabilidade e portabilidade do sistema. Ao virtualizar os serviços por meio de contêineres, foi possível observar o com- portamento da aplicação em um ambiente moderno, flexível e alinhado às práticas adotadas no mercado. Além disso, a estrutura desenvolvida contribuiu para aprimorar o desempenho, a organização dos ambientes e o isolamento dos serviços, garantindo que o sistema estivesse preparado para cenários de maior demanda, expansão de funcionalidades e implantação em ambientes de nuvem. Os testes foram compostos por três principais serviços executados nos contêineres: o frontend, o middleware e o NGINX, que atuou como proxy reverso e balanceador de carga. 4.3.1 Arquitetura do Middleware Para o presente trabalho, o middleware foi projetado adotando uma estrutura em cama- das, a fim de garantir separação de responsabilidades, organização, facilidade de manutenção e evolução da aplicação. Inicialmente sua principal função será como um redirecionador de chamadas vindas do front-end e repassando-as para um servidor interno por meio de chamadas HTTP. No entanto, com a arquitetura em camadas, o projeto poderá ser adaptado para atuar como servidor, visto que será possível realizar as consultas diretamente ao banco de dados, eli- minando a necessidade de intermediar outras APIs. Essa divisão segue os princípios das arqui- teturas limpas, como a arquitetura hexagonal (Ports and Adapters), possibilitando que a camada de services não dependam diretamente da forma como os dados serão buscados, ilustrado na Figura 15. O projeto foi organizado da seguinte forma: • Controller: Responsável por expor os endpoints REST. As requisições realizadas pelo 42 frontend são tratadas e reencaminhadas para o servidor interno e retornadas em forma de respostas HTTP. Esta camada não possui regras de negócio, apenas manipula o fluxo de requisições. • Service: Centralizador das regras de negócio e do processamento da aplicação. Esta ca- mada é responsável por coordenar as ações, aplicando decisões, lógicas e validações antes de acionar a última camada, que poderá ser uma nova integração ou acesso ao banco de dados. • Integration: Responsável pela comunicação externa por meio de chamadas HTTP para o servidor interno. Essa camada é isolada, pois encapsula todos os detalhes da comunicação externa, como URL, autenticação e tratamento das respostas. No cenário desenvolvido, a estrutura do middleware realizou as chamadas REST para o servidor existente. A comunicação com esse servidor ficou sob responsabilidade da camada integration, garantindo que quaisquer mudanças na origem dos dados não impactassem a ca- mada de negócios nem os endpoints expostos. Dessa forma, ao se tornar viável a integração direta com o banco de dados, a alteração será feita exclusivamente na camada integration, onde passará a implementar um repository. As demais camadas, controller e service, permaneceram intactas, mantendo o mesmo contrato de comunicação com o frontend e preservando as regras de negócio existentes. Uma aplicação projetada dessa forma, permite que a evolução seja feita de maneira controlada e incremental, sem que mudanças internas impactem os consumidores externos, além de contribuir para manutenções futuras e manter boas práticas no desenvolvimento de sistemas. Figura 15 – Diagrama de camadas Fonte: O Autor (2025) 4.3.2 Virtualização por Containers A estrutura de contêineres Docker foi composta por quatro serviços principais: o fron- tend, duas instâncias do middleware e um contêiner do NGINX atuando como balanceador de 43 carga e proxy reverso. O frontend foi disponibilizado como uma aplicação estática na porta 3000, enquanto o NGINX, exposto na porta 8088, recebeu as chamadas da interface e as di- recionou para uma das instâncias do middleware, que executavam a mesma aplicação Java. O balanceamento de carga foi realizado automaticamente por meio do mecanismo round-robin, definido nas configurações do NGINX, garantindo a distribuição uniforme das requisições en- tre os contêineres. Todos os serviços se comunicaram por meio de uma rede interna do Docker, assegurando integração controlada e isolamento entre os componentes da aplicação. 4.3.3 Distribuição e Gerenciamento de Requisições A configuração do NGINX estabeleceu dois papéis principais na arquitetura: disponibi- lizar os arquivos estáticos do frontend e atuar como proxy reverso para as requisições de API. Como proxy reverso, o NGINX funcionou como ponto de entrada para as requisições HTTP do frontend, reencaminhando as chamadas para os serviços internos conforme as regras definidas. O bloco upstream definiu um cluster de instâncias do middleware, agrupadas sob o nome backend_cluster. Todas as chamadas recebidas no caminho /api/ foram direcio- nadas a esse cluster por meio da diretiva proxy_pass, utilizando o balanceamento de carga round-robin para distribuir igualmente as requisições entre as instâncias disponíveis. Essa abor- dagem aumentou a tolerância a falhas do sistema e melhorou a escalabilidade. Já as chamadas que não eram destinadas ao caminho /api/ foram tratadas diretamente pelo NGINX, que ser- viu os arquivos estáticos da aplicação por meio da diretiva root, a partir do diretório padrão configurado. Além disso, o NGINX adicionou cabeçalhos Cross-Origin Resource Sharing (CORS) às respostas, permitindo que a aplicação fosse acessada por diferentes origens. Essa configuração foi essencial para o funcionamento adequado da comunicação entre o frontend e os serviços internos por meio do navegador, sem que o cliente precisasse conhecer diretamente as localiza- ções reais dos serviços. 4.3.4 Infraestrutura para Disponibilidade O uso de contêineres Docker permitiu que a aplicação fosse implementada de maneira escalável e simplificada em diversos ambientes. Ademais, destacaram-se três plataformas de computação em nuvem amplamente utilizadas, que ofereceram suporte completo a esse tipo de estrutura: • Amazon Web Services (AWS): A AWS disponibiliza diversos serviços de hospedagem para aplicações baseadas em contêineres. Por exemplo, a aplicação pode ser implantada no Amazon Elastic Compute Cloud (EC2), com instâncias virtuais ou soluções mais es- pecializadas, como o Amazon Elastic Container Service (ECS) e o AWS Fargate, que oferecem um serviço de mais alto nível para gerenciar contêineres. 44 • Oracle Cloud: A Oracle Cloud Infrastructure (OCI), permite a criação de máquinas vir- tuais, no serviço Always Free e também disponibiliza o Container Engine for Kuber- netes (OKE) e o Container Instances, estes permitem o deploy de aplicações de forma escalável, com integração nativa com outros serviços Oracle e com alta disponibilidade. • Microsoft Azure: A Azure Container Instances (ACI), permite executar contêineres dire- tamente na nuvem, sem a necessidade de gerenciar servidores. Além disso, para cenários que demandam maior controle, é possível utilizar o Azure Virtual Machines, criando uma infraestrutura sob demanda, ou ainda Azure Kubernetes Service (AKS) para a escalabili- dade e orquestração de múltiplos contêineres. Portanto, a utilização de contêineres proporcionou portabilidade à aplicação, viabili- zando sua execução em qualquer ambiente que oferecesse suporte adequado ao Docker, seja em serviços de nuvem ou em servidores locais. Somado a isso, é importante ressaltar que, para fortalecer ainda mais a escalabilidade e a padronização dos ambientes, prevê-se a possibilidade de adoção do conceito de Infraestrutura como Código (IaC). Com essa abordagem, toda a infraestrutura poderia ser descrita por meio de arquivos de configuração no formato YAML, abrangendo redes, máquinas virtuais, clusters Kubernetes, balanceadores e serviços. Dessa forma, seria possível que os arquivos organizados no projeto permitissem a criação automatizada e reprodutível dos ambientes em qualquer servi- dor local ou nuvem, reduzindo erros manuais e garantindo consistência na infraestrutura. Vale destacar que o uso de IaC foi planejado como uma etapa futura, independente da automação de deploy de código (CI/CD), que é responsável por construir, testar e entregar as aplicações. 4.3.5 Gerenciamento e provisionamento da Infraestrutura Uma maneira eficiente de facilitar a criação, manutenção e reprodução da infraestrutura planejada neste trabalho seria por meio do conceito de IaC. Essa abordagem possibilitaria des- crever toda a infraestrutura, incluindo redes, contêineres, balanceadores de carga e máquinas virtuais, em arquivos de configuração no formato YAML. Dessa forma, seria viável automati- zar o provisionamento e garantir a entrega de ambientes padronizados e reprodutíveis. Entre as ferramentas amplamente utilizadas, destaca-se o Terraform, por sua sintaxe declarativa e com- patibilidade com diversos serviços de nuvem, o que facilitaria a integração com práticas de DevOps (MORRIS, 2020). No contexto deste trabalho, o uso da infraestrutura como código foi considerado como uma etapa futura, visando permitir que a execução do sistema pudesse ser criada automatica- mente em qualquer ambiente. Essa abordagem poderia contribuir para melhorar a escalabili- dade, reduzir erros manuais e permitir a criação rápida de novos ambientes. Ademais, como mostra o estudo sistemático de Rahman et al. 2019, o IaC é um recurso importante para aumen- tar a confiabilidade de ambientes complexos e acelerar as entregas contínuas. Nesse sentido, 45 a utilização dessa ferramenta foi planejada como uma possibilidade de evolução do WebAlgo, preparando-o para integrações futuras com pipelines CI/CD e aprimorando o controle e a auto- mação da arquitetura. 4.3.6 Observabilidade e Monitoramento Para garantir a confiabilidade, o desempenho e a capacidade de diagnóstico da aplica- ção, foi essencial utilizar ferramentas de observabilidade, especialmente em arquiteturas distri- buídas que utilizam contêineres. Nesse sentido, foram empregadas as ferramentas Grafana, para visualização de métricas e criação de dashboards em tempo real (SALITURO, 2023), e OpenTe- lemetry, para coleta de logs e métricas (BOTEN; MAJORS, 2022). Essas ferramentas permitiram o monitoramento contínuo dos serviços, facilitando a detecção de falhas e o acompanhamento do comportamento do sistema em tempo real. De acordo com Beyer et al. 2016, a observabi- lidade é uma das práticas essenciais em sistemas modernos, permitindo maior controle sobre a operação de aplicações críticas em produção. No contexto do WebAlgo, a adoção de ferramentas de observabilidade como o Grafana e o OpenTelemetry mostrou-se fundamental, uma vez que a arquitetura envolveu diversas ca- madas e serviços interconectados. Com a instrumentação adequada, foi possível visualizar o comportamento do sistema em tempo real, detectar falhas em requisições, analisar a latência entre serviços e avaliar o uso de recursos de forma detalhada. 46 47 5 DESENVOLVIMENTO Este capítulo detalha o desenvolvimento da solução proposta, descrevendo as decisões arquiteturais, a estrutura dos componentes e as tecnologias empregadas. Apresentam-se o mid- dleware implementado, as integrações realizadas com o front-end já existente, bem como as estratégias de balanceamento de carga e o modelo de monitoramento adotado para garantir de- sempenho e disponibilidade. De forma interativa e incremental o desenvolvimento foi conduzido priorizando a mo- dularidade, a escalabilidade e a facilidade de manutenção. Para isso, adotou-se uma abordagem orientada a containers, com o uso do Docker, além da aplicação dos princípios da Arquite- tura Hexagonal (Ports and Adapters) na camada do middleware, que atua como ponto cen- tral de comunicação entre o front-end e as APIs externas, acessível em: . 5.1 VISÃO GERAL DA SOLUÇÃO A solução desenvolvida tem como objetivo modernizar o funcionamento da aplicação existente WebAlgo, proporcionando uma arquitetura flexível, escalável e compatível com ambi- entes locais e em nuvem. Para isso, foi criado um middleware para receber e tratar as requisições provenientes do front-end, redirecionando-as para as APIs do servidor existente do WebAlgo. Assim, o middleware atua como uma camada intermediária de abstração entre o cliente e os serviços de backend, permitindo a substituição futura do servidor legado sem a necessidade de alterações no front-end. O middleware foi implementado em Java 21, utilizando o Spring Boot como principal framework de desenvolvimento, possibilitando a criação de endpoints REST, a injeção de de- pendências e a configuração modular de forma simplificada. A escolha dessa tecnologia se deu pela maturidade do ecossistema Java, pela ampla documentação e pela compatibilidade com ferramentas modernas de monitoramento e deploy de containers. A Figura 16 apresenta uma visão geral da arquitetura proposta, ilustrando a interação entre os principais componentes do sistema. Nela, observa-se o fluxo de comunicação entre o navegador do usuário, o NGINX, as instâncias do middleware e o servidor WebAlgo. Além disso, o diagrama evidencia que o NGINX é responsável tanto por servir os arquivos estáticos da interface web quanto por realizar o roteamento e o balanceamento das requisições. Essa estrutura possibilita o desenvolvimento independente e o versionamento isolado de cada componente. Ademais, o uso do Docker como camada de empacotamento assegura que o ambiente de execução seja idêntico tanto em contextos locais quanto em ambientes de nuvem, como o Azure App Service e o Azure Kubernetes Service. https://github.com/GabrielMoscone/web-algo https://github.com/GabrielMoscone/web-algo Figura 16 – Visão geral da arquitetura desenvolvida. Fonte: O Autor (2025) A arquitetura adotada no middleware segue o modelo Hexagonal, que tem como ob- jetivo principal desacoplar o domínio central da aplicação das implementações externas. Com essa abordagem, as regras de negócio permanecem isoladas no centro da aplicação, enquanto os módulos externos (APIs, interfaces web e integrações futuras com banco de dados) são tra- tados como adaptadores conectados às ports. Essa estrutura garante que o middleware possa evoluir futuramente para um novo servidor, conectado diretamente ao banco de dados, sem a necessidade de grandes modificações. Toda a solução foi projetada para trabalhar em um ecossistema baseado em contai- ners Docker, facilitando a implementação e o gerenciamento padronizado dos serviços. O uso do Docker Compose permitiu a orquestração conjunta dos containers, incluindo o NGINX, as instâncias do middleware, e os componentes de monitoramento e observabilidade. A estrutura completa da solução está detalhada no Apêndice A, enquanto os arquivos de configuração do ambiente encontram-se reunidos no Apêndice D, permitindo uma compreensão mais aprofun- dada da implementação. 5.2 DESENVOLVIMENTO DO MIDDLEWARE Responsável por realizar a intermediação entre o front-end e o servidor, o middleware constitui o núcleo da solução desenvolvida. Sua função principal é receber as requisições prove- nientes da interface web, processar e validar os dados recebidos, redirecionar as chamadas para as APIs correspondentes e, por fim, retornar as respostas padronizadas ao cliente. Essa camada assegura o isolamento entre a aplicação de interface e as regras de comunicação com o servidor, proporcionando maior flexibilidade e manutenção independente. O middleware foi desenvolvido em Java 21, utilizando o framework Spring Boot, que oferece uma base consistente e simplificada para a criação de aplicações web. Embora a pro- posta de solução inicial previsse o uso do Java 19, optou-se pela versão 21 por se tratar de uma versão Long-Term Support (LTS), mais estável e com suporte estendido, garantindo lon- 48 gevidade ao projeto. O uso dessa tecnologia possibilitou a implementação de endpoints REST de forma estruturada, com suporte à injeção de dependências, ao controle de exceções e às configurações de ambiente. 5.2.1 Arquitetura Hexagonal A criação do middleware foi fundamentada na Arquitetura Hexagonal (Ports and Adap- ters), com o objetivo de desacoplar o núcleo de negócio (domínio) dos componentes externos, como APIs, bancos de dados e interfaces. Os controladores REST expõem os endpoints como adapters de entrada; a camada de aplicação define as portas (ports) e implementa os casos de uso e serviços; o domínio concentra os modelos e as exceções; e a infraestrutura configura a integração com serviços externos, conforme ilustrado na Figura 17. Essa abordagem facilita a manutenção, os testes e a evolução independente das integrações. Figura 17 – Visão geral da arquitetura Hexagonal no middleware Fonte: O Autor (2025) Cada uma dessas camadas possui responsabilidades bem definidas dentro da arquite- tura hexagonal. A camada Adapter representa os adaptadores de entrada e saída do sistema. Ela é responsável por expor os endpoints REST, receber as requisições externas e realizar a co- municação com serviços ou componentes externos, funcionando como a ponte entre o mundo externo e o núcleo da aplicação. A camada Application concentra a lógica de aplicação, sendo responsável pela orquestração dos casos de uso. Nela estão definidas as ports (interfaces) e suas respectivas implementações de serviço, que conectam o middleware às integrações externas e 49 coordenam o fluxo entre os adaptadores e o domínio. Por fim, a camada Domain reúne o nú- cleo conceitual da aplicação, contendo as entidades e exceções do sistema. No contexto deste projeto, contudo, essa camada não é utilizada de forma ativa, uma vez que o processamento das regras de negócio permanece no servidor legado do WebAlgo, cabendo ao middleware apenas intermediar a comunicação entre o novo front-end e o sistema existente. 5.2.2 Comunicação com o Front-end O front-end existente foi preservado, mas precisou ser ampliado para se comunicar ade- quadamente com o middleware por meio de requisições HTTP REST. Embora já houvesse uma estrutura inicial da interface, ela não continha diversas funcionalidades necessárias para uso completo do sistema. Dessa forma, novos endpoints foram criados seguindo convenções REST- ful, utilizando métodos como GET, POST, PUT e DELETE, de acordo com o tipo de operação executada. Cada endpoint recebe as requisições do front-end, realiza as validações necessárias e as encaminha para a API externa correspondente. Após o processamento, a resposta é con- vertida e devolvida ao front-end em formato JSON, facilitando a integração e o tratamento de dados na camada de interface. Durante o desenvolvimento, foi necessário estender o front-end já existente, implemen- tando funcionalidades que até então não haviam sido desenvolvidas e que eram indispensáveis para o funcionamento do sistema. Entre elas estão as telas de seleção de exercícios, login, re- cuperação de senha e cadastro de novos usuários. Além dessas telas, foram adicionados botões para salvar, criar e buscar problemas, permitindo que o usuário interaja dinamicamente com os recursos disponíveis. Sem essas implementações, o sistema não poderia ser utilizado de forma completa, pois a interface original não contemplava os fluxos necessários para comunicação com o middleware e para o uso real do WebAlgo na web. A camada intermediária também desempenha um papel fundamental na segurança e pa- dronização das respostas, impedindo que o front-end se comunique diretamente com os serviços externos. Dessa forma, eventuais alterações em endpoints internos ou em APIs externas podem ser absorvidas pelo middleware sem impactar a interface do usuário. 5.3 CONFIGURAÇÃO DO PROXY REVERSO O NGINX foi empregado como proxy reverso, desempenhando múltiplas funções den- tro da solução: disponibilizar os arquivos estáticos do front-end, redirecionar as requisições para o middleware e realizar o balanceamento de carga entre as instâncias em execução. A con- figuração foi definida no arquivo nginx.conf, localizado no diretório nginx/ do projeto, contendo todas as diretivas necessárias para o roteamento das requisições, tratamento de sessões e exposição de métricas. A configuração do NGINX foi estruturada de modo a combinar a entrega eficiente do 50 front-end com o proxy e o balanceamento de carga do middleware. O bloco upstream adota o algoritmo round-robin com conexões keep-alive e failover passivo, reduzindo o custo de co- nexão e garantindo a continuidade mesmo diante de falhas temporárias das instâncias. O bloco /api preserva os cabeçalhos de origem, aplica timeouts e buffers otimizados e habilita tentati- vas (retries) seletivas para erros transitórios. Paralelamente, o servidor fornece arquivos estáti- cos diretamente e expõe métricas via stub_status, integrando a camada de borda ao pipeline de observabilidade. Por fim, as regras de redirecionamento baseadas em cookies de sessão contro- lam o acesso ao conteúdo autenticado, mantendo a aplicação responsiva e segura. O uso do NGINX traz diversos benefícios ao ambiente da aplicação. O balanceamento de carga entre múltiplas instâncias contribui para a redução da latência e evita a sobrecarga de um único container, melhorando o desempenho e a escalabilidade horizontal, visto que novas instâncias podem ser adicionadas ao cluster com facilidade. Além disso, o NGINX atua como camada intermediária de segurança e isolamento, impedindo o acesso direto do front-end aos serviços internos. A escolha dessa tecnologia deve-se à sua leveza, estabilidade e eficiência em ambientes baseados em containers. Além de atuar como servidor HTTP, permite definir regras de roteamento, controle de acesso e monitoramento. A Figura 18 apresenta trechos representativos da configuração do NGINX, evidenci- ando os principais blocos que compõem a camada de borda da aplicação. O Lado A exibe o proxy reverso responsável pelo encaminhamento das requisições da API e pela preservação dos cabeçalhos de origem. O Lado B ilustra o balanceamento de carga entre as instâncias do mid- dleware, configurado com round-robin, failover e conexões keep-alive. O Lado C apresenta o controle de sessão por meio de cookies, com redirecionamento automático entre a página de login e a principal. Por fim, o Lado D mostra o endpoint de métricas internas, utilizado para o monitoramento via Prometheus e Grafana. Figura 18 – Principais configurações do NGINX. Fonte: O Autor (2025) A Figura 19 apresenta uma visão geral do funcionamento do proxy reverso, ilustrando 51 o fluxo das requisições entre o navegador do usuário, o NGINX e as instâncias do middleware. Figura 19 – Visão geral do funcionamento do proxy reverso NGINX. Fonte: O Autor (2025) A estrutura do NGINX e suas principais funções dentro da arquitetura proposta estão detalhadas no Apêndice B, complementando as informações apresentadas nesta seção. 5.4 ORQUESTRAÇÃO COM DOCKER COMPOSE Como forma de execução simultânea de todos os componentes do sistema, foi configu- rado o Docker Compose, responsável pela orquestração dos containers que compõem a solução. Dessa forma, é possível automatizar o processo de inicialização, interconexão e monitoramento dos serviços, tornando o ambiente de desenvolvimento e execução mais padronizado, portátil e reprodutível. O arquivo docker-compose.yml, localizado na raiz do projeto, define de forma declarativa todos os serviços necessários para o funcionamento do sistema, incluindo as duas instâncias do middleware, o NGINX e os módulos de monitoramento implementados. O uso do Docker Compose traz diversos benefícios ao processo de desenvolvimento e implantação. A padronização do ambiente assegura que o sistema seja executado de forma idêntica em diferentes contextos, eliminando discrepâncias entre os ambientes local e produtivo, simplificando o processo de deploy e facilitando a escalabilidade. No arquivo, cada serviço possui sua própria definição de imagem, variáveis de ambiente, portas expostas, dependências e configurações de rede. • nginx: atua como ponto de entrada da aplicação, servindo os arquivos estáticos do front- end e redirecionando as requisições para o middleware. • middleware1 e middleware2: repres