Middleware é a camada de software que medeia a comunicação entre sistemas, APIs e serviços. Sua arquitetura deve prever contratos, segurança, tratamento de falhas e recuperação para manter a interoperabilidade.
Confira!
Middleware é uma camada de software utilizada para mediar a comunicação entre sistemas, aplicar regras de roteamento, transformação, segurança e tratamento de falhas. Em arquiteturas corporativas, pode coordenar APIs, mensageria e conectores para que ERP, CRM, aplicações operacionais e plataformas analíticas compartilhem informações sem reproduzir lógica de integração em todos os consumidores. Middleware não é sinônimo de API Gateway, ESB ou Broker: essas são categorias de componentes com responsabilidades e garantias distintas. A escolha depende da topologia, do volume, da necessidade de processamento síncrono ou assíncrono e da capacidade de operação. Este artigo explica a função do middleware na arquitetura corporativa, sem repetir o comparativo geral de padrões de Integração de Sistemas.
O papel do middleware entre aplicações corporativas
Mediação, conectividade e contrato de negócio
Quando um ERP precisa disponibilizar informações para diversas aplicações, cada conexão direta pode implementar autenticação, transformação e política de retry de maneira diferente. Um middleware pode centralizar determinadas funções transversais, oferecendo pontos de integração documentados e mecanismos de observabilidade compartilhados. O benefício não está apenas na redução de conexões físicas; está em permitir controlar contratos e evidências de processamento, de forma que uma mudança no produtor não exija alterações improvisadas em dezenas de consumidores. O desenho precisa distinguir transformação técnica de dados e decisão de negócio: a camada intermediária não deve inventar o significado de uma fatura ou de uma ordem de manutenção sem aprovação do responsável.
A mediação é útil quando há protocolos e formatos heterogêneos, mas não elimina o dever de reconhecer cada sistema de origem. Um registro de venda extraído do ERP e um evento de circulação extraído de vídeo representam fenômenos distintos. Transformá-los no middleware para o mesmo campo de valor sem preservar origem, finalidade e granularidade pode criar indicadores incorretos. A arquitetura precisa definir contratos semânticos, versionamento e responsáveis. O middleware pode operar como infraestrutura compartilhada ou como conjunto de serviços delimitados por domínio; nenhuma dessas opções assegura boa governança se os fluxos não tiverem objetivos e testes claros.
Diferença entre middleware, broker, ESB e API Gateway
Middleware é um termo amplo que descreve componentes de integração e mediação. API Gateway administra a exposição e políticas de APIs, como autenticação, roteamento e limites de requisição. Message Broker transporta mensagens e pode manter filas, tópicos e mecanismos de entrega conforme implementação. ESB, ou Enterprise Service Bus, é um estilo de integração que pode combinar mediação central, transformação e serviços compartilhados. iPaaS representa uma plataforma de integração disponibilizada como serviço. Esses componentes podem coexistir, e as fronteiras variam por produto; escolher pelo nome comercial não demonstra adequação.
Um API Gateway não substitui automaticamente armazenamento durável de eventos; um Broker não é necessariamente o local correto para transformar regras financeiras; um ESB não deve tornar-se proprietário de todos os cadastros do negócio. A seleção exige identificar operações síncronas, processamento assíncrono, volume e disponibilidade. A equipe deve avaliar o que acontece quando a origem para, o consumidor demora ou o contrato muda. Centralizar regras sem ownership pode transformar o middleware em um monólito de integração cuja manutenção fica tão difícil quanto a dos sistemas que pretendia desacoplar.
Quando evitar uma camada adicional
Middleware acrescenta infraestrutura, credenciais, monitoramento, capacidade computacional e dependência operacional. Em uma integração simples, com contrato estável e poucos sistemas, uma conexão direta por API pode ser suficiente. Acrescentar uma plataforma corporativa pode elevar custo e criar um novo ponto de falha sem benefício verificável. É necessário comparar o esforço de implantação com a redução esperada de duplicações, com a manutenção de contratos e com a gestão de incidentes. A decisão deve considerar o número de consumidores e a frequência real de alteração das interfaces, não apenas a promessa de reuso.
Também é arriscado usar a camada intermediária para compensar continuamente problemas de cadastro e regras que deveriam ser corrigidos na fonte. Quando a aplicação produtora não identifica exclusões ou envia dados inconsistentes, um conector pode aplicar controles compensatórios, mas a limitação precisa permanecer visível. A arquitetura deve indicar se o middleware preserva histórico, transforma formatos ou apenas repassa mensagens, e como cada comportamento será testado. Caso a decisão seja manter integrações específicas, a organização ainda precisa documentar e monitorar contratos, autorizações e recuperação.
A mediação de mensagens entre plataformas só pode ser considerada confiável quando as interfaces preservam estados, identidade e condições de recuperação. A implementação deve demonstrar que a origem e os consumidores conseguem reconciliar os resultados, inclusive quando há falhas.
Padrões de roteamento, transformação e orquestração
Enterprise Integration Patterns e pipelines de mensagens
Enterprise Integration Patterns descreve soluções recorrentes para problemas de troca de mensagens, incluindo Message Router, Pipes and Filters, Message Translator e Dead Letter Channel. Projetos como Apache Camel disponibilizam componentes para implementar esses padrões. Sua utilidade é tornar explícita a função de cada etapa: validar conteúdo, filtrar mensagens, converter formatos e encaminhar ao destino apropriado. Porém, os padrões precisam ser aplicados a contratos reais. Um Message Translator pode converter XML para JSON, mas não deve converter silenciosamente um evento de pedido em faturamento reconhecido.
Em um fluxo de faturamento, a mensagem pode ser recebida, validada quanto ao schema, transformada para modelo canônico e encaminhada a consumidores autorizados. Cada etapa deve registrar um identificador que permita reconstruir a trajetória e diferenciar rejeição de conteúdo, indisponibilidade do destino e falha de autorização. Um padrão de roteamento que envia mensagens a vários consumidores precisa definir se todos devem concluir para considerar o processo aprovado. A arquitetura de logs deve preservar informação útil à investigação sem expor dados pessoais ou credenciais.
Orquestração versus coreografia de eventos
Na orquestração, um componente controla a sequência de tarefas e estados de um processo. Na coreografia, componentes reagem a eventos e mantêm responsabilidades distribuídas. As duas abordagens podem ser utilizadas com middleware, mas possuem consequências diferentes de observabilidade e mudança. Um processo de aprovação contratual pode exigir uma instância explícita que demonstre etapa, responsável e decisão. Um evento de alteração de cadastro pode ser distribuído a vários consumidores sem controlar uma sequência única de negócio. Não é adequado escolher uma abordagem universal antes de especificar os estados necessários.
Fluxos longos entre sistemas podem demandar compensação quando uma etapa falha após outras já terem sido concluídas. Uma compensação não equivale necessariamente a rollback, especialmente se houve entrega física, movimentação financeira ou comunicação a terceiros. O desenho precisa declarar irreversibilidade e quem pode autorizar correção. Um middleware não transforma automaticamente serviços independentes em transação distribuída única. É necessário definir identidade de processo, timeouts, registro de resultados, tratamento de repetição e reconciliação com os sistemas que controlam cada fato de negócio.
Mensagens rejeitadas e Dead Letter Channel
Uma mensagem inválida pode resultar de schema incompatível, campo obrigatório ausente, estado desconhecido ou regra que não permite processamento. Repetir indefinidamente a mesma mensagem não corrige o defeito e pode bloquear filas ou consumir capacidade. Um Dead Letter Channel, quando implementado, permite segregar ocorrências para análise e tratamento. A arquitetura define que dados podem ser preservados, quem acessa as rejeições e como executar replay após correção. Uma mensagem rejeitada não deve ser apagada silenciosamente quando possui significado contratual ou financeiro.
É necessário diferenciar falha transitória de falha permanente. Timeout momentâneo pode admitir retry com backoff; schema quebrado pode exigir intervenção humana; credencial revogada exige correção de autorização. A fila de exceções precisa manter motivo, versão, origem, destino e status do tratamento. O retorno ao fluxo normal só é aceito após reconciliação, evitando processamento duplicado. Ao especificar um middleware, a equipe deve conferir se as funções de retry e Dead Letter presentes no produto atendem ao contrato e ao volume esperado, e não inferir confiabilidade apenas da existência do recurso.
APIs, segurança e dados para Business Intelligence
Gateway de APIs e políticas de autorização
Um Gateway pode concentrar TLS, autenticação, limitação de chamadas e roteamento, mas a autorização precisa ser avaliada no contexto dos objetos e propriedades acessados. Um token válido não significa acesso irrestrito a todas as unidades ou campos de ERP. Os contratos devem definir consumidores autorizados, finalidades, quotas, versionamento e comportamento após expiração da credencial. O risco de acesso indevido aumenta quando uma mesma conta técnica atende aplicações distintas; o princípio do menor privilégio precisa limitar interfaces e ações. Logs não devem incluir tokens, segredos ou cópias integrais desnecessárias de dados sensíveis.
A análise de segurança utiliza cenários negativos: um serviço tenta consultar objeto de outra unidade, um campo protegido é incluído por engano na resposta, um token é revogado durante carga e uma API passa a retornar conteúdo inesperado. O middleware pode bloquear ou limitar certas ações, mas não substitui políticas implementadas na origem. Em integrações TI/OT, os caminhos de leitura da automação precisam respeitar zonas e responsabilidades, sem criar via de comando aos controladores pelo ambiente analítico. A governança estabelece quem autoriza novas interfaces e como seus acessos serão revistos.
Contratos, schemas e evolução sem quebra
Uma API ou mensagem pode mudar de versão sem alterar seu endpoint ou tópico. Campos novos, enumerações e regras semânticas afetam consumidores de modos diferentes. A arquitetura deve versionar contratos e manter inventário de dependências, testes de compatibilidade e política de descontinuação. OpenAPI pode descrever APIs HTTP e CloudEvents padroniza metadados de eventos, mas nenhuma dessas especificações define por conta própria a regra de negócio. O Data Owner continua responsável por aprovar o significado de um campo e os períodos de transição.
Um Schema Registry pode auxiliar na gestão de schemas de mensagens quando a tecnologia adotada oferece esse recurso, mas a compatibilidade depende de políticas, formatos e versão de clientes e brokers. Um consumidor pode aceitar estrutura nova e interpretar incorretamente um status alterado; por isso, testes precisam verificar valores e comportamento. A integração deve preservar contexto de origem, identificador e timestamp de evento. Ao criar um contrato corporativo, não se deve impor o mesmo schema a domínios com conceitos diferentes apenas para reduzir número de adaptações.
Alimentação analítica e efeito no modelo de dados
Middleware pode transportar dados de ERP, CRM, manutenção, sensores e plataformas de vídeo para camadas analíticas, mas não é Business Intelligence por si só. A cadeia precisa distinguir ingestão, preparação e aprovação da medida. Uma notificação de pedido alterado pode disparar atualização, mas o consumidor precisa consultar ou receber os dados que realmente representam o fato de negócio. Um evento de porta não é uma pessoa única, e um estado de ordem de manutenção não demonstra automaticamente a disponibilidade física do ativo. Essas diferenças precisam ser preservadas no Data Contract e no modelo semântico.
Quando há muitos consumidores, a mediação pode reduzir chamadas repetidas à origem e coordenar distribuição, desde que a solução mantenha qualidade, atualização e rastreabilidade. Uma extração bem-sucedida não garante que todos os registros esperados foram obtidos; a engenharia precisa reconciliar população e totais. O usuário de dashboard deve reconhecer dados provisórios, atrasados e não disponíveis. A camada intermediária deve fornecer sinais para observar a cadeia e encaminhar erros aos responsáveis, sem apresentar conectividade como garantia da decisão analítica.
A escolha entre API Gateway, Broker, ESB ou iPaaS precisa ser sustentada por critérios de custo, segurança, dependência e continuidade. Uma avaliação técnica ajuda a comparar alternativas sem confundir número de conectores com interoperabilidade efetiva.
Dimensionamento, continuidade e operação
Latência, throughput e cargas de pico
O dimensionamento considera requisições por segundo, taxa de mensagens, tamanho de payload, chamadas a sistemas produtores, retenção e tempo de transformação. Uma arquitetura capaz de atender carga média pode falhar durante reconexão de unidades ou recuperação de backlog. O teste deve representar picos, mensagens grandes e consumidores lentos, medindo throughput, atraso, erros e impacto sobre as origens. A escolha entre fluxo síncrono e assíncrono depende do tempo útil à decisão e das garantias necessárias, não de uma preferência tecnológica. A latência do middleware representa apenas parte da cadeia.
Filas podem absorver variação de carga, mas exigem limite, retenção, alerta e plano para escoar backlog. API Gateway pode limitar solicitações, mas o consumidor precisa saber se houve rejeição, processamento posterior ou erro irreversível. Se uma integração serve a relatórios mensais e alertas operacionais, os compromissos podem ser diferentes. O projeto deve declarar prioridades e evitar que um fluxo não crítico comprometa tráfego prioritário. Estimativas de capacidade precisam ser testadas com dados representativos, incluindo falhas e recuperação.
Alta disponibilidade e modos degradados
Redundância de instâncias pode aumentar disponibilidade da plataforma, mas não evita indisponibilidade do ERP, falha de regra compartilhada ou expiração de credenciais. O plano de continuidade considera armazenamento de estado, filas, configurações, catálogo de rotas, segredos e mecanismos de recuperação. Uma atualização que introduz transformação incorreta pode afetar todos os nós; o versionamento e o rollback são necessários independentemente da infraestrutura. O procedimento deve distinguir operação normal, degradada e indisponível, indicando quais consumidores continuam recebendo informação confiável.
Uma falha entre envio e confirmação pode gerar retransmissão. É necessário manter chaves de idempotência e consulta de estado para evitar efeitos duplicados quando o destino já executou a ação. Não se deve prometer exactly once de ponta a ponta apenas porque o Broker oferece determinada garantia interna. Serviços externos e efeitos transacionais exigem coordenação própria. A recuperação precisa confirmar o resultado de negócio, e não somente a saída da mensagem da fila. O runbook estabelece quando bloquear processamento, reprocessar ou comunicar uma ressalva.
Observabilidade, contratos e evidências de aceite
Um fluxo de middleware deve ser observável por identificador de correlação, origem, destino, versão de contrato, tempo de processamento, rejeições e estado de entrega. Logs precisam ser protegidos e preservar informações suficientes para auditoria. Um HTTP 200 não prova que o pedido foi aplicado corretamente no sistema de destino; a reconciliação exige consulta ao registro de negócio ou outra evidência acordada. Os alertas devem indicar o responsável pela origem, rota ou consumidor, para reduzir repasses de incidentes entre fornecedores.
O pacote de entrega inclui mapa de interfaces, regras de roteamento, contratos, matriz de permissões, testes de carga, falhas, mensagens duplicadas, rejeições e procedimentos de continuidade. A verificação de uma rota deve abranger tanto casos bem-sucedidos quanto erro de schema, timeout e mudança tardia. A documentação precisa permitir que equipe diferente reconstrua o fluxo e compreenda por que um evento foi aceito ou rejeitado. A continuidade do serviço depende desse conjunto, não apenas de uma plataforma com interface gráfica de monitoramento.
| Componente | Responsabilidade predominante | Limitação relevante |
|---|---|---|
| API Gateway | Exposição, políticas e roteamento HTTP | Não substitui por si só uma fila durável |
| Message Broker | Transporte e distribuição de mensagens | Não define semântica de negócio |
| Middleware de mediação | Transformação e composição de interfaces | Pode concentrar complexidade e falhas |
| ESB | Padrões e serviços comuns de integração | Centralização pode ampliar acoplamento |
| iPaaS | Conectores e fluxos gerenciados | Licenciamento e dependência de plataforma |
| Data Pipeline | Preparação e publicação analítica | Não executa necessariamente processos transacionais |
Exemplo corporativo de integração e homologação
ERP, CRM e dados de manutenção
Considere uma empresa com ERP, CRM e CMMS que deseja consolidar indicadores de contratos e ativos. A camada de mediação recebe alterações de cadastro, atualizações comerciais e estados administrativos. O ERP continua responsável pelo faturamento e o CMMS pelas ordens. O middleware converte formatos e encaminha eventos ou consultas de acordo com contratos definidos. Não pode considerar um pedido aprovado como faturamento concluído nem marcar equipamento disponível apenas porque sua ordem foi encerrada. Os testes devem refletir essas distinções e associar cada informação ao domínio produtor.
Um ensaio usa pedido com itens parciais, cancelamento posterior e alteração de unidade. São registrados identificadores, estados e timestamps esperados. A integração deve preservar a identidade do registro ao enviar para o destino e manter versões suficientes para investigação. Se houver correção retroativa, o consumidor deve reconhecer que um valor histórico pode mudar e aplicar política de republicação. A equipe compara o resultado com as fontes para verificar que transformações e filtros não suprimiram registros sem autorização. O valor do middleware está em tornar esse fluxo reutilizável e verificável.
Falhas controladas e retomada do processamento
O ensaio interrompe o consumidor após a origem confirmar envio e antes de o middleware registrar sucesso de entrega. A arquitetura deve determinar como identificar a tentativa anterior, consultar estado e executar retry sem produzir duplicação. Em uma segunda situação, uma mensagem com schema inválido é encaminhada ao canal de rejeição com motivo e referência de origem. A correção precisa permitir replay controlado, preservando a trilha do incidente. Esse teste distingue falha transitória de erro estrutural e prova que a operação sabe decidir quando reprocessar.
Na terceira situação, a origem fica indisponível enquanto outros consumidores continuam operando. O middleware pode manter fila ou oferecer estado degradado, mas precisa informar atraso e eventuais limites de retenção. Um dashboard que depende de dados do ERP não deve exibir o último valor como atual. O monitoramento deve demonstrar qual etapa está atrasada e quais consumidores são afetados. O aceite verifica que a recuperação recompleta a janela e reconcilia quantidades, não apenas que a conexão foi restabelecida. É importante também observar se a tentativa de recuperação sobrecarrega o sistema produtor.
Critérios de escolha e relacionamento com serviços
A avaliação técnica deve comparar conexão direta, API Gateway, Broker, iPaaS e ESB segundo número de integrações, requisitos não funcionais, capacidade de operação e custo. Um produto com centenas de conectores prontos pode exigir grande esforço para governança de versões e segurança; outro pode ser simples, mas não sustentar volume e recuperação. A decisão precisa registrar alternativas e limites, incluindo dependência de fornecedor. A arquitetura não deve replicar todo o processo empresarial no middleware apenas porque a ferramenta permite criar workflows.
Erros recorrentes de cadastro e definições contraditórias nem sempre são problemas de transporte de dados. Investigar os processos de origem ajuda a identificar o que deve ser corrigido antes de automatizar rotas e regras de integração.
Quando o objetivo é contratar implantação, o escopo deve migrar do entendimento conceitual para interfaces, infraestrutura, testes e transferência de conhecimento. O Serviço de Integração de Sistemas contempla execução e comissionamento de integrações específicas. O artigo sobre padrões de Integração de Sistemas aprofunda alternativas arquiteturais em geral; este texto concentra-se nas funções e limites de uma camada de middleware corporativo. A diferenciação impede que múltiplas URLs concorram pelo mesmo conteúdo e orienta a jornada do leitor para a especialidade adequada.
A análise de Integração de Sistemas apresenta a escolha entre padrões de integração; a Solução de Integração de Sistemas e APIs e o Serviço de Integração de Sistemas tratam do escopo de implantação.
Ensaios de carga, compatibilidade e recuperação
Um ensaio representativo começa por uma integração que transporta documentos do ERP para dois consumidores, um analítico e outro operacional. A equipe registra a versão do contrato, os identificadores dos documentos, seus estados e os destinos autorizados. No primeiro teste, o middleware recebe alteração de documento já processado e deve aplicar política de versão, evitando contar atualização como nova operação. O processo compara o dado recebido com a origem, considerando cancelamentos e movimentos compensatórios. A demonstração precisa distinguir sucesso de transporte de resultado de negócio. O recebimento de HTTP 200 ou de confirmação do Broker comprova apenas parte do caminho; a integridade final depende do que o consumidor registrou e de como a aplicação interpreta aquela atualização.
O segundo ensaio provoca timeout após o envio de mensagem e antes da confirmação do destino. O middleware deve conservar correlação, consultar ou reconstruir o estado e aplicar retry sem efeito duplicado. Caso a mensagem contenha erro de schema, a política de Dead Letter Channel precisa registrá-la para análise, informando versão, motivo e responsável. Mensagens inválidas não devem ser descartadas para melhorar artificialmente taxa de sucesso. O runbook deve explicar como corrigir contrato, validar o novo payload e executar replay controlado. A equipe verifica se o reprocessamento mantém os resultados esperados e não altera períodos que já haviam sido encerrados sem política de revisão.
Um terceiro cenário aumenta o volume de mensagens enquanto o ERP apresenta lentidão. A arquitetura deve respeitar rate limits da origem, impedir propagação descontrolada de timeout e medir backlog e duração do processamento. A função de buffering não significa que o consumidor receberá dados dentro do prazo acordado: a organização precisa monitorar atraso efetivo e informar estados degradados quando necessário. Quando a origem retorna ao funcionamento, a recuperação não deve consumir toda sua capacidade e prejudicar operações comerciais. O teste compara throughput, falhas, recuperação e totalização dos documentos, registrando o comportamento de cada camada. Os requisitos de desempenho devem representar dias de pico, não somente a média mensal.
A implantação também exige testes de autorização por objeto, segregação de credenciais e compatibilidade entre versões. Uma conta técnica com permissão para receber valores de uma unidade não deveria consultar documentos de outra, mesmo que compartilhem o mesmo Gateway. O contrato deve restringir propriedades sensíveis e documentar o que pode ser transformado em cada etapa. Uma mudança de enumeração ou de interpretação de campo pode atravessar todos os componentes sem falha sintática, causando resultado incorreto no consumidor. O pacote final de aceite reúne interfaces, testes, logs de correlação, métricas, runbooks e responsabilidades para garantir que a mediação possa ser sustentada sem depender do desenvolvedor inicial.
O dimensionamento da camada intermediária deve contemplar custos de manutenção e dependência de fornecedor, além das métricas de tráfego. Em empresas com várias unidades, uma mesma plataforma pode executar fluxos financeiros, administrativos e operacionais. Uma alteração compartilhada pode produzir efeito amplo, por isso é necessário separar ambientes, configurações, limites de recursos e responsabilidades de suporte. A arquitetura também precisa estabelecer quando um fluxo pode ser implantado de modo independente e quando exige regressão de outros consumidores. A prova de capacidade deve mostrar que uma fila acumulada ou um destino indisponível não compromete interfaces mais críticas. Esse desenho evita transformar a tentativa de desacoplamento em um ponto central de risco sistêmico.
Outro cuidado consiste em manter contratos de observabilidade compatíveis com a política de segurança. Um identificador de correlação ajuda a seguir mensagens, mas os registros não devem expor credenciais, conteúdo financeiro completo ou dados pessoais desnecessários. O plano deve definir prazo e acesso aos logs segundo a finalidade e as obrigações aplicáveis. Quando a organização utiliza um fornecedor de iPaaS, precisa verificar quais evidências podem ser exportadas para investigação e transferência futura do serviço. Uma integração contratada sem documentação e capacidade de diagnóstico pode funcionar durante meses e tornar-se difícil de recuperar após mudança de equipe ou de licença.
Considerações finais
Middleware pode oferecer mediação, padronização de rotas e capacidade operacional quando existem múltiplos produtores e consumidores com contratos e necessidades distintas. A escolha entre API Gateway, Broker, ESB, iPaaS ou integração direta deve decorrer dos requisitos de negócio, segurança, volume, latência e tratamento de falhas. Centralizar componentes não significa centralizar a propriedade do dado nem resolve automaticamente incompatibilidades semânticas. Transformações, autorizações e modos degradados exigem definição, documentação e testes.
Um projeto confiável deve demonstrar processamento de mensagens válidas e inválidas, controle de duplicações, alteração de schema, recuperação, monitoramento e impacto nos sistemas de origem. O middleware é um componente de integração; Business Intelligence depende também de qualidade, modelo de indicadores e governança dos consumidores. O resultado de engenharia é um conjunto de interfaces sustentável, observável e verificável por equipes diferentes, evitando que a plataforma intermediária se torne nova fonte de dependências ocultas.
Referências técnicas
[1] APACHE SOFTWARE FOUNDATION. Apache Camel User Manual. Disponível em: https://camel.apache.org/manual/
[2] APACHE SOFTWARE FOUNDATION. Enterprise Integration Patterns. Disponível em: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=104862
[3] OPENAPI INITIATIVE. OpenAPI Specification. Disponível em: https://spec.openapis.org/
[4] CLOUD NATIVE COMPUTING FOUNDATION. CloudEvents Specification. Disponível em: https://github.com/cloudevents/spec
[5] OWASP FOUNDATION. API Security Top 10 2023. Disponível em: https://owasp.org/API-Security/editions/2023/en/0x11-t10/
Perguntas frequentes
É uma camada que pode mediar protocolos, dados, rotas e políticas entre sistemas diferentes.
Não. API Gateway concentra funções de exposição e controle de APIs; middleware pode ter escopo de mediação mais amplo.
Componente para transportar e distribuir mensagens conforme mecanismos de fila, tópicos e políticas de entrega.
Pode fazer, se serviços compartilhados e mediação central atenderem necessidades reais sem criar acoplamento excessivo.
Integration Platform as a Service é uma plataforma gerenciada que oferece conectores e fluxos de integração.
Não. Qualidade, modelo semântico e reconciliação continuam necessários.
Quando há poucos sistemas, contratos estáveis, risco controlado e ganho insuficiente para justificar camada adicional.
Mecanismo para segregar mensagens não processadas, mantendo evidência para correção e replay.
Não unilateralmente. Regras de negócio precisam de aprovação pelos respectivos responsáveis.
Com identidade de operação, idempotência, controle de estado e reconciliação de efeitos no destino.
Volume de pico, timeout, mudanças de contrato, autorização, rejeição de mensagens e recuperação.
Middleware pode transportar e mediar dados; a análise exige camadas próprias de qualidade, modelagem e governança.
