⚔️ MITSUHA YAMANO E A DUNGEON DOS SETE PROTOCOLOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE REST NÃO ERA O ÚNICO PORTAL

 

Bellacosa Mainframe e os 7 protocolos nas APIs

☕ Um Café no Bellacosa Mainframe

⚔️ MITSUHA YAMANO E A DUNGEON DOS SETE PROTOCOLOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE REST NÃO ERA O ÚNICO PORTAL

REST, GraphQL, gRPC, WebSockets, Webhooks, SSE, MQTT, mensageria, eventos, idempotência, sistemas distribuídos — e o dia em que Mitsuha descobriu que uma API mal escolhida pode custar muito mais que 80.000 moedas de ouro.

---

🎬 PRÓLOGO — MITSUHA ENCONTROU SETE PORTAIS

Mitsuha Yamano olhou para o quadro.

Havia sete portais desenhados diante dela:

REST
GraphQL
gRPC
WebSocket
Webhook
SSE
MQTT

Ao lado estava um jovem programador COBOL.

Ele conhecia algumas coisas.

Sabia que:

MOVE 100 TO WS-QUANTIDADE.

IF WS-SALDO >= WS-VALOR
    PERFORM PROCESSA-PAGAMENTO
END-IF.

Sabia alguma coisa sobre arquivos, JCL e talvez estivesse começando a descobrir CICS, Db2 e VSAM.

Mas aquela sopa de siglas modernas parecia magia.

Mitsuha olhou para ele.

— Qual você escolheria?

— REST.

— Por quê?

— Porque todo mundo usa REST.

Mitsuha suspirou.

Era exatamente assim que se perdia uma fortuna em outro mundo.

Porque a primeira lição desta aventura é:

Tecnologia não deve ser escolhida porque está na moda. Ela deve ser escolhida porque resolve adequadamente um problema.

E REST, GraphQL, gRPC, WebSocket, Webhooks, SSE e MQTT não são simplesmente sete concorrentes tentando conquistar o mesmo reino.

Eles resolvem tipos diferentes de conversa entre sistemas.

Prepare o café.

Nossa dungeon começa aqui.

---

🏰 CAPÍTULO 1 — ANTES DA API EXISTIA A CONVERSA

Antes de falarmos sobre REST, precisamos entender algo muito mais básico.

Computadores precisam conversar.

Imagine dois programas:

PROGRAMA A

     precisa de uma informação

          ↓

PROGRAMA B

Se os dois estão dentro do mesmo processo, a comunicação pode ser relativamente simples.

No COBOL podemos ter:

CALL 'CALCJURO'
    USING WS-VALOR
          WS-TAXA
          WS-RESULTADO.

O programa chama outro programa.

Mas imagine que CALCJURO não está na mesma máquina.

Ele está em outro servidor.

Talvez em outro datacenter.

Talvez em outro país.

Agora temos:

Programa A
    |
    | REDE
    |
    v
Programa B

Acabamos de entrar no mundo dos sistemas distribuídos.

E a rede acrescentou vários monstros à dungeon:

latência
timeout
queda de conexão
mensagem duplicada
mensagem perdida
servidor indisponível
autenticação
autorização
criptografia
ordenação
retry

Quando tudo acontece dentro de um programa COBOL, podemos pensar:

PERFORM A
PERFORM B
PERFORM C

Quando distribuímos isso pela rede, precisamos começar a pensar:

Enviei A.

Será que chegou?

Se chegou, será que processou?

Se processou, por que não respondeu?

Posso enviar novamente?

Se enviar novamente, será executado duas vezes?

Bem-vindo à arquitetura distribuída.

---

🌐 CAPÍTULO 2 — O PRIMEIRO PORTAL CHAMA-SE REST

REST significa:

Representational State Transfer.

O termo ficou conhecido a partir do trabalho acadêmico de Roy Fielding no início dos anos 2000.

Mas cuidado com uma simplificação muito comum:

REST não significa simplesmente “JSON trafegando por HTTP”.

REST é um estilo arquitetural.

Uma das ideias mais importantes é trabalhar com recursos.

Imagine um banco.

Existem:

CLIENTE
CONTA
CARTÃO
PAGAMENTO
EMPRÉSTIMO

Podemos representar esses recursos por endereços:

/customers/12345

/accounts/98765

/cards/45678

E utilizar métodos HTTP.

Por exemplo:

GET /customers/12345

significa aproximadamente:

Quero consultar o cliente 12345.

Enquanto:

POST /payments

poderia significar:

Quero criar um novo pagamento.

Temos métodos conhecidos como:

GET
POST
PUT
PATCH
DELETE

Uma associação didática comum seria:

GET       consultar
POST      criar/processar
PUT       substituir/atualizar
PATCH     alterar parcialmente
DELETE    remover

Mas não transforme isso numa religião. A semântica real da API precisa ser bem projetada.

---

🧙 CAPÍTULO 3 — MITSUHA COLOCA CICS ATRÁS DO PORTAL

Agora nosso COBOLzeiro pergunta:

— Preciso jogar meu COBOL fora para criar APIs?

Mitsuha quase derrubou o café.

Não.

Esse é justamente um dos pontos mais interessantes da modernização de mainframe.

Imagine um programa COBOL executado por CICS contendo uma regra de negócio importantíssima:

Aplicativo Mobile
       |
       | HTTPS / REST
       v
    API Layer
       |
       v
 z/OS Connect
       |
       v
     CICS
       |
       v
     COBOL
       |
   +---+---+
   |       |
  Db2     VSAM

O aplicativo moderno não precisa necessariamente conhecer detalhes internos do COBOL.

Ele pode pedir:

GET /accounts/12345/balance

Uma camada de integração transforma essa requisição em algo compreensível pelo ambiente existente.

O COBOL executa sua lógica.

O resultado volta.

Talvez como:

{
  "account": "12345",
  "balance": 8750.42,
  "currency": "BRL"
}

Observe o detalhe.

O COBOL pode continuar fazendo aquilo que faz bem:

regra de negócio
transação
processamento
acesso aos dados

A API torna essa capacidade acessível ao restante do ecossistema.

Modernização não significa obrigatoriamente:

destruir o sistema antigo.

Às vezes significa:

construir uma porta moderna para um sistema extremamente valioso.

---

🧬 CAPÍTULO 4 — GRAPHQL ENTRA NA LOJA DE MITSUHA

Agora imagine que Mitsuha abriu sua loja.

Na tela inicial ela precisa mostrar:

Nome
Saldo
Últimas compras
Cartões
Limite
Notificações

Com determinadas APIs REST, poderíamos acabar fazendo:

GET /customer/123
GET /customer/123/accounts
GET /customer/123/cards
GET /customer/123/orders
GET /customer/123/notifications

Cinco requisições.

Outra API poderia responder tudo em uma chamada, mas devolver 80 campos quando a tela utiliza apenas 7.

Temos dois problemas clássicos.

Over-fetching

Você pede pouca coisa e recebe uma carroça inteira.

PRECISO:

nome
saldo


RECEBO:

nome
saldo
endereço
telefone
data nascimento
histórico
cartões
preferências
...

Under-fetching

Você recebe tão pouco que precisa continuar perguntando:

cliente?

agora cartões?

agora pedidos?

agora itens?

agora endereço?

GraphQL oferece outra abordagem.

O cliente pode declarar os campos desejados:

query {
  customer(id: 123) {
    name
    accounts {
      balance
    }
  }
}

Isso é poderoso especialmente em interfaces com necessidades de dados complexas.

Mas Mitsuha levanta o dedo:

— Não existe magia grátis.

GraphQL também traz desafios:

schemas
resolvers
cache
autorização
complexidade das consultas
observabilidade
N+1 queries
limitação de profundidade
controle de custo

Uma consulta aparentemente inocente pode gerar enorme trabalho internamente se a arquitetura estiver mal implementada.

Portanto:

GraphQL não é REST melhorado.

São modelos diferentes.

---

⚡ CAPÍTULO 5 — gRPC PARECE ESTRANHAMENTE FAMILIAR AO COBOLZEIRO

Mitsuha escreve:

CALL 'AUTORIZA'
    USING WS-CARTAO
          WS-VALOR
          WS-RETURN-CODE.

O programador sorri.

Finalmente alguma coisa familiar.

Então ela desenha:

SERVIÇO A

   chama

SERVIÇO B

RPC significa Remote Procedure Call.

A ideia geral é fazer uma operação localizada em outro processo ou máquina parecer, conceitualmente, uma chamada de procedimento.

gRPC é uma tecnologia moderna muito utilizada nesse universo.

Normalmente os contratos são definidos com Protocol Buffers.

Por exemplo:

service PaymentService {

    rpc Authorize(PaymentRequest)
        returns (PaymentResponse);

}

Temos um contrato bem definido.

Uma vantagem importante é a possibilidade de geração de código para diferentes linguagens.

Podemos ter:

Java
   |
  gRPC
   |
   v
Go Service

ou:

Python
   |
  gRPC
   |
   v
Java

Protocol Buffers utiliza representação binária compacta, diferentemente do JSON textual tão associado às APIs REST.

Isso torna gRPC particularmente interessante em muitos cenários de comunicação interna entre serviços.

Easter egg COBOL

O veterano olha para aquilo e comenta:

— Então inventaram CALL USING pela rede?

Não exatamente.

Mas como modelo mental inicial para nosso Padawan COBOL?

Funciona maravilhosamente bem.

---

🔥 CAPÍTULO 6 — WEBSOCKET MANTÉM O PORTAL ABERTO

Agora Mitsuha pergunta:

— Como você descobriria se apareceu uma nova mensagem?

O aprendiz responde:

— Perguntaria.

Tem mensagem?

Tem mensagem?

Tem mensagem?

Tem mensagem?

Tem mensagem?

Parabéns.

Você acabou de descobrir o polling.

Dependendo do problema, polling é perfeitamente aceitável.

O problema aparece quando milhares de clientes perguntam repetidamente:

mudou?

mudou?

mudou?

mudou?

mesmo quando nada mudou.

WebSocket permite manter uma conexão de comunicação bidirecional.

CLIENTE <====================> SERVIDOR

Depois de estabelecida a comunicação, ambos podem transmitir informações.

Isso é extremamente útil em:

chat
jogos multiplayer
dashboards
colaboração
telemetria
atualizações interativas

Imagine nossa War Room Mainframe:

           IBM Z
             |
       SMF / MONITOR
             |
             v
          Backend
             |
        WebSocket
             |
             v
+---------------------------+
|    WAR ROOM MAINFRAME     |
+---------------------------+
| CPU                 73%   |
| CICS RESPONSE       0.2s  |
| MQ DEPTH            173   |
| DB2                 OK    |
| BATCH               OK    |
+---------------------------+

Se algum indicador muda, o backend pode enviar imediatamente uma atualização.

---

📡 CAPÍTULO 7 — SSE: MITSUHA LIGA A ESTAÇÃO DE RÁDIO

Nem sempre precisamos de comunicação nos dois sentidos.

Às vezes queremos principalmente:

SERVIDOR
   |
   |
   |
   v
CLIENTE

É aqui que entram Server-Sent Events, ou SSE.

O cliente estabelece uma conexão HTTP e o servidor pode continuar enviando eventos.

Pense numa estação transmitindo:

evento 1
evento 2
evento 3
evento 4

Isso combina muito bem com:

notificações
feeds
status
progresso
logs
streaming de respostas

Um exemplo moderno está nas aplicações de IA.

Imagine esperar 40 segundos para receber:

RESPOSTA COMPLETA

Podemos, em vez disso, transmitir progressivamente:

COBOL

COBOL foi

COBOL foi criado

COBOL foi criado no...

A experiência percebida pelo usuário melhora muito.

WebSocket versus SSE

Guarde este desenho:

WebSocket

CLIENTE <==========> SERVIDOR


SSE

CLIENTE <----------- SERVIDOR

Precisa de conversa contínua nos dois sentidos?

WebSocket pode fazer sentido.

O servidor precisa principalmente transmitir atualizações ao cliente?

SSE pode ser uma solução mais simples.

---

🔔 CAPÍTULO 8 — WEBHOOK: “MITSUHA, EU TE AVISO”

Agora chegamos a um dos conceitos mais elegantes.

Imagine Mitsuha esperando um pagamento.

Uma estratégia seria:

Pagamento chegou?

Pagamento chegou?

Pagamento chegou?

Pagamento chegou?

Polling novamente.

Mas podemos inverter.

Mitsuha informa:

Quando acontecer,
mande a informação para cá.

Ela registra um endpoint:

https://loja.example/events/payment

Quando o pagamento acontece:

Sistema de pagamento
        |
        | HTTP POST
        v
Webhook Mitsuha
        |
        v
Processamento

Simples.

Até chegar a produção.

Porque o endpoint pode estar indisponível.

Então precisamos pensar em:

retry
timeout
backoff
assinatura
segurança
logs
monitoramento
duplicidade
idempotência

E aqui aparece um monstro fantástico.

---

👹 CAPÍTULO 9 — O DEMÔNIO DA DUPLICIDADE

Imagine:

Mitsuha envia pagamento de 100 moedas.

O servidor recebe.

Processa.

Debita.

Mas quando vai responder:

HTTP 200 OK

a conexão cai.

Para Mitsuha:

?????????

Ela não sabe se o pagamento aconteceu.

Então tenta novamente.

Se o sistema simplesmente processar outra vez:

100 moedas
+
100 moedas
=
200 moedas

Temos um problema sério.

Por isso sistemas de pagamento frequentemente trabalham com conceitos de idempotência.

Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indevidos para a mesma intenção.

Podemos associar à operação uma chave:

IDEMPOTENCY-KEY:
PAY-20260925-000317

O servidor registra:

PAY-20260925-000317 = PROCESSADO

Se receber novamente:

PAY-20260925-000317

ele consegue reconhecer:

Eu já processei esta intenção.

Isso é extremamente importante em sistemas distribuídos.

E nosso easter egg apareceu:

03:17

Veteranos da War Room Bellacosa sabem que incidentes gostam de acontecer justamente quando ninguém gostaria de estar acordado.

---

📻 CAPÍTULO 10 — MQTT E O EXÉRCITO DE PEQUENOS DISPOSITIVOS

Mitsuha agora possui:

10 sensores

Depois:

1.000 sensores

Depois:

100.000 sensores

Cada um precisa transmitir pequenas informações.

Temperatura:

27.3

Pressão:

1012

Estado:

ON

MQTT foi projetado pensando em comunicação leve e funciona muito bem em cenários envolvendo IoT, dispositivos e redes com restrições.

Seu modelo clássico envolve:

PUBLISHER
    |
    v
  BROKER
    |
 +--+--+
 |  |  |
 v  v  v
S1 S2 S3

O produtor publica em um tópico:

factory/machine17/temperature

Os interessados assinam tópicos.

A máquina 17 não precisa conhecer todos os consumidores.

Ela apenas publica.

Isso produz uma propriedade arquitetural valiosíssima:

desacoplamento.

O produtor não precisa saber necessariamente quem consumirá aquela informação.

---

📨 CAPÍTULO 11 — O COBOLZEIRO RECONHECE IBM MQ NA TAVERNA

Nesse momento nosso aprendiz interrompe:

— Espera. Publisher, consumidor, mensagens, filas, desacoplamento... isso parece mensageria.

EXATAMENTE.

Agora estamos chegando a uma ponte maravilhosa entre arquitetura moderna e mainframe.

Imagine:

COBOL
   |
   v
IBM MQ
   |
   +------> SISTEMA A
   |
   +------> SISTEMA B
   |
   +------> INTEGRAÇÃO

O universo corporativo trabalha há décadas com conceitos como:

filas
mensagens
persistência
transações
assincronicidade
store-and-forward
publish/subscribe

Por isso um profissional mainframe experiente frequentemente encontra conceitos supostamente “moderníssimos” e pensa:

Já enfrentei esse monstro antes.

Mudaram as ferramentas.

Mudaram os nomes.

Mudaram as abstrações.

O problema fundamental continua reconhecível.

---

🧠 CAPÍTULO 12 — NÃO SÃO REALMENTE “SETE PROTOCOLOS IGUAIS”

Existe uma correção conceitual importante na imagem que iniciou nossa aventura.

Colocar tudo sob o título “7 API Protocols” facilita a comunicação, mas tecnicamente mistura categorias diferentes.

REST é essencialmente um estilo arquitetural.

GraphQL envolve linguagem de consulta, sistema de tipos e runtime.

gRPC é um framework/sistema de RPC.

WebSocket é efetivamente um protocolo.

MQTT também é protocolo.

Webhooks representam principalmente um padrão de integração orientado a eventos.

SSE é um mecanismo padronizado para eventos enviados pelo servidor sobre HTTP.

Portanto, imagine a placa:

7 FORMAS IMPORTANTES
DE SISTEMAS CONVERSAREM

Ela seria menos sexy para LinkedIn.

Mas pedagogicamente seria mais segura. 😄

---

🧙‍♀️ CAPÍTULO 13 — MITSUHA DESCOBRE QUE FALTAVAM PORTAIS

Nossa lista também não contém todo o universo.

Precisamos conhecer pelo menos conceitualmente outros habitantes dessa dungeon.

SOAP

Foi extremamente importante na história dos Web Services empresariais.

Normalmente associado a XML e contratos formais, apareceu intensamente em integrações corporativas.

Ainda existem muitos sistemas utilizando SOAP.

AMQP

Importante no universo de mensageria.

Kafka

Apache Kafka popularizou arquiteturas baseadas em event streaming em enorme escala.

O modelo mental começa a ficar diferente de simplesmente:

manda mensagem
recebe mensagem
acabou

Eventos podem formar um registro persistente que consumidores processam conforme suas necessidades.

IBM MQ

Para o COBOLzeiro e para ambientes empresariais críticos, seria impossível discutir seriamente integração sem mencionar MQ.

Especialmente quando começamos a conversar sobre confiabilidade.

---

🏦 CAPÍTULO 14 — UMA ARQUITETURA REAL USA VÁRIOS PORTAIS

Agora Mitsuha finalmente constrói seu império financeiro.

O aplicativo utiliza REST:

MOBILE
   |
 REST
   |
API GATEWAY

Internamente alguns microsserviços conversam via gRPC:

SERVICE A
   |
 gRPC
   |
SERVICE B

O mainframe continua responsável por determinadas regras:

API
 |
 v
z/OS Connect
 |
 v
CICS
 |
 v
COBOL
 |
 +---- Db2
 |
 +---- VSAM

Eventos importantes passam por mensageria:

COBOL
 |
 v
 MQ
 |
 +------> Fraud
 |
 +------> Settlement
 |
 +------> Notification

O parceiro externo recebe:

WEBHOOK

O dashboard recebe:

SSE

O chat utiliza:

WebSocket

Sensores de algum equipamento poderiam utilizar:

MQTT

Veja o ponto fundamental.

Não escolhemos:

REST OU gRPC OU MQ OU WebSocket

Podemos escolher:

REST
+
gRPC
+
MQ
+
Webhook
+
SSE

porque cada tecnologia ocupa uma posição diferente na arquitetura.

---

⚔️ CAPÍTULO 15 — O VERDADEIRO CHEFÃO É O SISTEMA DISTRIBUÍDO

Nosso aprendiz agora conhece sete tecnologias.

Ele está feliz.

Mitsuha, porém, abre a última porta.

Atrás dela existe um monstro gigantesco chamado:

DISTRIBUTED SYSTEM

Porque aprender sintaxe é relativamente fácil.

O difícil é responder perguntas como:

E se a rede cair?

E se a mensagem chegar duas vezes?

E se não chegar?

E se chegar fora de ordem?

E se o servidor processar,
mas não conseguir responder?

E se o consumidor ficar offline?

E se eu tiver 10.000 consumidores?

E se uma operação demorar 40 segundos?

E se ocorrer timeout?

Posso tentar novamente?

Como sei o que aconteceu?

É aqui que entram conceitos fundamentais:

timeout
retry
backoff
idempotência
circuit breaker
dead-letter queue
observabilidade
correlation ID
tracing
autenticação
autorização
rate limiting

---

🔍 CAPÍTULO 16 — OBSERVABILIDADE: QUEM NÃO ENXERGA NÃO INVESTIGA

Imagine uma transação:

Mobile
  |
API
  |
Service A
  |
MQ
  |
COBOL
  |
Db2

O cliente reclama:

Meu pagamento desapareceu.

Onde?

Precisamos seguir a transação.

Um identificador de correlação pode ajudar:

CORRELATION-ID

TX-20260925-00042

Então conseguimos procurar:

API
TX-20260925-00042

SERVICE
TX-20260925-00042

MQ
TX-20260925-00042

COBOL
TX-20260925-00042

Agora a investigação deixa de ser:

Acho que o problema está no mainframe.

E passa a ser:

14:31:02.103 API recebeu
14:31:02.121 API publicou
14:31:02.135 MQ recebeu
14:31:02.148 COBOL iniciou
14:31:02.172 Db2 COMMIT
14:31:02.181 resposta publicada

Isso é ouro operacional.

Em ambientes modernos distribuídos, observabilidade não deveria ser decoração.

É parte da arquitetura.

---

🗺️ CAPÍTULO 17 — O MAPA DE DECISÃO DE MITSUHA

Quando precisar escolher uma abordagem, não comece pela tecnologia.

Faça perguntas.

Passo 1 — Quem inicia a conversa?

Cliente?

Servidor?

Dispositivo?

Outro sistema?

Passo 2 — Preciso de resposta imediata?

Se sim, um modelo síncrono pode ser apropriado.

Se não, mensageria assíncrona pode oferecer vantagens.

Passo 3 — Preciso manter conexão aberta?

Se não:

REST
GraphQL
Webhook

podem aparecer entre as possibilidades, dependendo do problema.

Se sim:

WebSocket
SSE
gRPC streaming

podem entrar na análise.

Passo 4 — A comunicação é bidirecional?

Se for:

WebSocket

merece investigação.

Se for predominantemente servidor → cliente:

SSE

pode ser suficiente.

Passo 5 — Tenho muitos produtores e consumidores desacoplados?

Pense em:

MQ
MQTT
Kafka
event-driven architecture

Passo 6 — Posso perder uma mensagem?

Essa pergunta muda tudo.

Pergunte também:

Posso duplicar?

Preciso manter ordem?

Preciso fazer replay?

Por quanto tempo?

Preciso comprovar processamento?

Agora estamos fazendo arquitetura.

---

💰 CAPÍTULO 18 — MITSUHA ENSINA A REGRA DAS 80.000 MOEDAS

Existe uma armadilha recorrente em tecnologia:

“X é moderno.”

Logo:

“Vamos usar X.”

Não.

Imagine usar WebSocket para uma operação executada uma vez por mês.

Ou GraphQL para uma API trivial com três campos.

Ou introduzir Kafka onde uma fila simples resolveria perfeitamente.

Ou fazer polling a cada segundo quando um webhook resolveria o problema.

Complexidade também custa dinheiro.

Ela produz:

infraestrutura
monitoramento
treinamento
suporte
incidentes
dependências
documentação
segurança
manutenção

Mitsuha não ficaria rica gastando 80.000 moedas para resolver um problema de 8 moedas.

Arquitetura madura procura a solução adequada, não a solução com maior quantidade de siglas.

---

🏛️ CAPÍTULO 19 — A CATEDRAL MAINFRAME JÁ CONHECIA MUITOS DESSES MONSTROS

Existe uma deliciosa ironia histórica aqui.

Hoje falamos constantemente em:

mensageria
eventos
transações
filas
RPC
assíncrono
publish/subscribe
observabilidade
alta disponibilidade
processamento distribuído

Muitos desses problemas são antigos.

Mainframes empresariais enfrentam há décadas desafios relacionados a:

milhares de transações
concorrência
integridade
recuperação
auditoria
segurança
mensageria
disponibilidade

CICS, IMS, Db2, MQ e outras tecnologias nasceram e evoluíram dentro dessa realidade.

Isso não significa que:

“Mainframe já inventou tudo.”

Seria exagero.

Significa algo muito mais interessante:

Os problemas fundamentais da computação sobrevivem às gerações de tecnologia.

As abstrações mudam.

Os protocolos evoluem.

As interfaces ficam mais elegantes.

Mas continuamos perguntando:

Quem envia?

Quem recebe?

Quando?

Em qual ordem?

Quantas vezes?

O que acontece se falhar?

---

🥚 EASTER EGG — A TRANSAÇÃO FANTASMA DAS 03:17

Às 03:17 da manhã, Mitsuha recebe uma ligação.

— Produção caiu!

Ela abre o dashboard.

REST funcionando.

CICS funcionando.

Db2 funcionando.

MQ funcionando.

Tudo verde.

Mesmo assim, pagamentos estão sendo duplicados.

Depois de duas horas investigando, encontra:

Webhook
   |
timeout
   |
retry
   |
processamento novamente

A aplicação consumidora não implementava idempotência corretamente.

O mesmo evento havia sido processado várias vezes.

Mitsuha olha para o aprendiz.

— Qual protocolo falhou?

Ele pensa.

— Nenhum.

Exatamente.

O erro estava no desenho do sistema.

Essa talvez seja a lição mais importante desta dungeon.

---

☕ EPÍLOGO — O COBOLZEIRO ATRAVESSOU OS SETE PORTAIS

Nosso jovem programador começou acreditando que precisava decorar:

REST
GraphQL
gRPC
WebSocket
Webhook
SSE
MQTT

Terminou entendendo algo muito maior.

Essas tecnologias representam diferentes maneiras de sistemas trocarem informações.

REST ensina a pensar em recursos e interfaces HTTP.

GraphQL permite ao consumidor declarar dados de que necessita.

gRPC aproxima sistemas distribuídos de um modelo de chamada remota baseado em contratos fortemente definidos.

WebSocket mantém um canal bidirecional.

SSE permite ao servidor transmitir eventos continuamente ao cliente.

Webhooks invertem o polling:

não fique perguntando; eu aviso quando acontecer.

MQTT apresenta um modelo leve de publish/subscribe extremamente útil para dispositivos e IoT.

E mensageria empresarial, MQ, event streaming e tecnologias relacionadas expandem ainda mais essa dungeon.

Mas Mitsuha ensinou algo que nenhuma tabela comparativa consegue ensinar:

Antes de escolher o protocolo, descubra a natureza da conversa.

Pergunte:

Quem fala?

Quem escuta?

Quem começa?

Precisa responder?

Precisa esperar?

Pode repetir?

Pode perder?

Precisa preservar ordem?

O receptor pode estar offline?

Quantos participantes existem?

Como descubro que falhou?

Como recupero?

Como provo o que aconteceu?

Quando um programador começa a fazer essas perguntas, alguma coisa muda.

Ele deixa de pensar somente:

COMO IMPLEMENTO ESTA API?

e começa a perguntar:

COMO ESTE SISTEMA DEVE SE COMPORTAR?

Essa é uma mudança gigantesca.

É a passagem da programação para a engenharia de sistemas.

E talvez seja justamente por isso que um programador COBOL possui uma vantagem inesperada nessa aventura.

Ele vem de um universo no qual palavras como:

transação
commit
rollback
fila
batch
online
integridade
recuperação
auditoria
disponibilidade

nunca foram apenas buzzwords.

Quando um pagamento envolve dinheiro verdadeiro, não basta desenhar uma seta bonita entre dois quadradinhos num PowerPoint.

A transação precisa chegar.

Precisa ser processada corretamente.

Precisa sobreviver a falhas.

Precisa poder ser investigada.

E, às 03:17 da madrugada, alguém precisa conseguir descobrir exatamente o que aconteceu.

Mitsuha fecha o mapa dos sete portais, guarda algumas moedas e olha para nosso Padawan COBOL:

— Então, qual é o melhor protocolo?

Ele finalmente aprendeu.

— Depende da conversa que os sistemas precisam ter.

Mitsuha sorri.

A primeira dungeon estava concluída.

A próxima porta tinha uma placa ainda mais assustadora:

                 EVENT-DRIVEN ARCHITECTURE

                          |
             +------------+------------+
             |                         |
          IBM MQ                     Kafka
             |                         |
       Queues / Topics            Event Streams
             |                         |
             +------------+------------+
                          |
                    COBOL PROGRAM

E alguém havia escrito em letras pequenas no canto:

ATENÇÃO:

“EXACTLY ONCE”
PODE CONTER MAGIA,
MARKETING
E MUITAS LETRAS MIÚDAS.

Mitsuha pegou novamente sua calculadora.

O COBOLzeiro preparou outro café.

E os dois entraram.

 

Bellacosa Mainframe e o uso de APIs em Mainframe

☕🔥 APIs NO IBM MAINFRAME — O MUNDO MODERNO DESCOBRIU AGORA O QUE O z/OS JÁ FAZIA HÁ DÉCADAS

Hoje o mercado fala sem parar sobre:

• APIs

• REST

• GraphQL

• gRPC

• Event Streaming

• Webhooks

• Tempo real

• Microsserviços

E muita gente imagina que isso nasceu:

• na nuvem

• no Kubernetes

• no Node.js

• no mundo cloud-native

Mas existe uma realidade histórica quase escondida:

O Mainframe sempre foi uma máquina de integração.

Muito antes do termo “API Economy” virar moda…

o IBM Mainframe já fazia:

• comunicação distribuída

• transações remotas

• integração entre sistemas

• troca de mensagens

• processamento assíncrono

• request/reply

• eventos

• streaming de dados

E talvez essa seja a parte mais impressionante:

🔥 O z/OS não apenas sobreviveu à era das APIs…
ele virou um dos pilares dela.

---

☕ O QUE MUITA GENTE NÃO ENTENDE SOBRE APIs

API não é “modinha web”.

API é:

contrato de comunicação.

O formato muda.

A tecnologia muda.

Mas a ideia é a mesma desde os anos 70:

• um sistema solicita algo

• outro sistema responde

• existe um protocolo

• existe um padrão

• existe governança

E o Mainframe foi pioneiro nisso.

---

☕🔥 GRAPHQL NO MAINFRAME — A VOLTA DO “PEDIR SOMENTE O NECESSÁRIO”

GraphQL virou tendência porque resolve um problema clássico:

👉 excesso de dados.

O cliente pede exatamente o que quer.

---

☕ Mas olha a ironia…

O Mainframe já tinha essa mentalidade há décadas.

---

Exemplo clássico no CICS + COBOL

Uma transação antiga:

EXEC CICS LINK
     PROGRAM('CLI0001')
     COMMAREA(WS-AREA)
END-EXEC

A COMMAREA levava apenas:

• campos específicos

• estruturas necessárias

• dados filtrados

Não havia desperdício.

---

☕ GraphQL + z/OS Connect

Hoje o Mainframe moderno usa:

• z/OS Connect

• API Connect

• Db2 REST Services

para expor:

• COBOL

• CICS

• IMS

• DB2

como APIs modernas.

---

Exemplo real

Um app mobile pode pedir:

cliente {
  nome
  saldo
}

E o Mainframe responde apenas isso.

Sem payload gigante.

---

☕🔥 gRPC — O “NOVO RPC” QUE O MAINFRAME JÁ CONHECIA

Quando o mercado descobriu gRPC…

o profissional mainframe veterano provavelmente sorriu.

Porque:

👉 gRPC é basicamente a evolução moderna do RPC.

E RPC já existia no universo IBM há MUITO tempo.

---

☕ O que é gRPC?

Comunicação:

• rápida

• binária

• eficiente

• orientada a contratos

usando Protocol Buffers.

---

☕ O Mainframe fazia isso como?

APPC/LU6.2

Comunicação transacional remota.

---

DPL (Distributed Program Link)

Programa chama outro remotamente:

EXEC CICS LINK
     SYSID('PRD1')
END-EXEC

Isso é praticamente:

🔥 “gRPC raiz”.

---

☕ MQ também antecipou isso

Mensagens compactas.

Baixa latência.

Integração confiável.

Comunicação assíncrona.

---

☕🔥 SOAP — O REINADO ABSOLUTO DO MAINFRAME CORPORATIVO

Antes do REST dominar o mundo…

SOAP era rei absoluto.

E o Mainframe foi um dos maiores ambientes SOAP do planeta.

---

☕ Por quê?

Porque SOAP entrega algo que o mundo financeiro AMA:

• contratos rígidos

• padronização

• WS-Security

• governança

• transações confiáveis

• XML estruturado

---

☕ CICS Web Services

O CICS consegue expor programas COBOL como SOAP services.

---

Fluxo clássico

SOAP Request
     ↓
CICS Pipeline
     ↓
COBOL
     ↓
DB2 / VSAM
     ↓
SOAP Response

---

☕ O que pouca gente sabe

Grande parte:

• bancos

• seguradoras

• governos

AINDA usam SOAP no Mainframe.

E sinceramente?

🔥 Em sistemas críticos, SOAP ainda é extremamente poderoso.

---

☕🔥 REST — O MAINFRAME APRENDEU A FALAR “INTERNET”

REST virou padrão porque simplifica integração.

HTTP + JSON.

Simples.

Leve.

Universal.

---

☕ E o Mainframe?

O Mainframe se reinventou brutalmente aqui.

---

☕ Hoje temos:

z/OS Connect

Transforma:

• COBOL

• IMS

• CICS

em APIs REST modernas.

---

☕ Exemplo

Aplicação mobile faz:

GET /clientes/1001

E no backend:

• COBOL executa

• DB2 consulta

• CICS processa

O usuário nem percebe que existe um z/OS por trás.

---

☕ O REST ajudou o Mainframe a sobreviver

Essa talvez seja uma das maiores viradas históricas do IBM Z.

REST permitiu:

• integração com cloud

• apps mobile

• fintechs

• Open Banking

• microsserviços

• APIs públicas

---

☕🔥 WEBHOOKS — O MAINFRAME SEMPRE VIVEU DE EVENTOS

Webhook é:

“me avise quando algo acontecer”.

---

☕ Parece moderno…

Mas o Mainframe já vivia disso.

---

☕ Exemplos clássicos

WTO/WTOR

Mensagens do sistema disparam ações.

---

Automation

NetView e System Automation executam workflows baseados em eventos.

---

MQ Triggering

Fila recebe mensagem → programa inicia automaticamente.

Isso é Webhook conceitualmente.

---

☕ Exemplo real

Pagamento aprovado:

MQ Message
   ↓
Trigger
   ↓
COBOL Batch
   ↓
Atualização DB2
   ↓
Notificação externa

Event-driven desde antes do termo existir.

---

☕🔥 SSE (SERVER-SENT EVENTS) — O MAINFRAME SEMPRE AMOU STREAMING

SSE mantém conexão aberta enviando eventos contínuos.

Hoje isso aparece em:

• dashboards

• monitoring

• fintechs

• trading

• observabilidade

---

☕ Mas o Mainframe já fazia streaming há décadas

SMF

Fluxo contínuo de eventos do sistema.

---

RMF

Monitoramento em tempo real.

---

OMEGAMON

Streaming operacional contínuo.

---

☕ Ambientes financeiros usam isso intensamente

Bolsa de valores.

Cartões.

PIX.

Fraude.

Monitoramento de transações.

Tudo depende de fluxo contínuo.

---

☕🔥 O GRANDE CHOQUE CULTURAL

O mercado moderno acha que inventou:

• integração

• APIs

• eventos

• streaming

• observabilidade

Mas o Mainframe já enfrentava esses problemas:

• nos anos 70

• nos anos 80

• nos anos 90

em escala absurda.

---

☕ O QUE MUDA É O FORMATO

Ontem:

• SNA

• APPC

• MQ

• CICS LINK

• COMMAREA

Hoje:

• REST

• GraphQL

• gRPC

• Kafka

• Webhooks

Mas a essência continua a mesma:

🔥 sistemas precisam conversar de forma confiável.

---

☕🔥 O MAIOR MITO SOBRE O MAINFRAME

“Mainframe não conversa com sistemas modernos.”

Isso está completamente errado.

Hoje o IBM Z conversa com:

• AWS

• Azure

• Kubernetes

• OpenShift

• APIs REST

• Kafka

• aplicações mobile

• IA generativa

E faz isso mantendo:

• segurança absurda

• disponibilidade 24x7

• integridade transacional

• throughput gigantesco

---

☕🔥 A VERDADE QUE O MERCADO COMEÇA A REDESCOBRIR

Quanto mais o mundo moderno cresce…

mais ele percebe a importância de:

• resiliência

• observabilidade

• governança

• transação confiável

• mensageria robusta

• integração desacoplada

E adivinha?

👉 Esses sempre foram pilares do Mainframe.

---

☕🔥 CONCLUSÃO — O MAINFRAME NÃO FICOU PARA TRÁS

Ele apenas:

evoluiu antes dos outros.

REST, GraphQL, gRPC e Webhooks não substituíram o Mainframe.

Eles se conectaram a ele.

Porque no fim das contas…

🔥 quase todo sistema moderno ainda acaba conversando com um IBM Z em algum momento da vida.