 |
| Bellacosa Mainframe como um aplicativo moderno conversa com um mainframe ibm z |
☕ Um Café no Bellacosa Mainframe
Como um Aplicativo Moderno Conversa com um Mainframe IBM Z?
Do Terminal Verde ao Smartphone.
O Mainframe Mudou Menos do que Você Imagina. O Mundo ao Redor Mudou Muito.
Existe uma pergunta que acompanha praticamente todo desenvolvedor que chega ao universo IBM Z:
"Se o mainframe é tão antigo, como um aplicativo Android consegue conversar com ele?"
Ou então:
"Como um site feito em HTML, CSS e JavaScript consegue consultar o saldo da minha conta que está em um programa COBOL escrito há trinta anos?"
A resposta é uma das histórias mais fascinantes da engenharia de software.
Porque, ao contrário do que muita gente imagina, o COBOL nunca aprendeu HTML.
O CICS nunca aprendeu JavaScript.
O DB2 nunca começou a falar React.
Quem evoluiu foi toda a infraestrutura em volta deles.
E essa talvez seja a maior lição que o IBM Z ensina.
Os sistemas realmente importantes não são reescritos toda vez que aparece uma tecnologia nova.
Eles aprendem novas formas de conversar.
Primeiro precisamos esquecer uma ideia errada.
Quando você abre um aplicativo do banco no Android, provavelmente imagina algo parecido com isto:
Android
↓
COBOL
Não.
Quase nunca.
Na realidade existem diversas camadas entre eles.
Hoje uma simples consulta de saldo pode atravessar meia dúzia de tecnologias antes de chegar ao programa COBOL.
Algo muito mais parecido com isto.
Android
↓
Internet
↓
API Gateway
↓
Servidor Java
↓
Middleware
↓
CICS
↓
Programa COBOL
↓
DB2
E cada uma dessas camadas existe por um motivo.
Nenhuma delas apareceu por acaso.
 |
| Bellacosa Mainframe fluxo teorico em 1980 |
Vamos voltar quarenta anos.
Imagine um banco em 1985.
Não existia internet.
Não existia smartphone.
Não existia navegador.
O usuário estava diante de um terminal 3270.
Usuário
↓
Terminal IBM 3270
↓
Controladora
↓
Mainframe
↓
CICS
↓
COBOL
O terminal era extremamente simples.
Ele praticamente desenhava caracteres na tela.
Nada de janelas.
Nada de mouse.
Nada de ícones.
Nada de JavaScript.
O CICS enviava uma tela.
O usuário digitava.
A tela inteira voltava.
O COBOL processava.
Outra tela era enviada.
Era um diálogo baseado em telas.
Hoje chamamos isso de arquitetura orientada a transações.
Na época era simplesmente computação.
 |
| Bellacosa Mainframe e o fluxo moderno |
Como funcionava o login?
O operador digitava:
Usuário
Senha
A tela era enviada inteira para o CICS.
O CICS chamava um programa COBOL.
O COBOL verificava:
usuário
senha
permissões
Depois consultava RACF.
Ou outro sistema de segurança.
Se estivesse tudo correto...
Outra tela aparecia.
Observe uma coisa interessante.
Mesmo naquela época já existia autenticação centralizada.
Já existia controle de acesso.
Já existia auditoria.
Muito antes da internet existir.
 |
| Bellacosa Mainframe e o fluxo teorico em 1990 |
Então chegou a arquitetura Cliente-Servidor.
Década de 90.
Agora surgiu o Windows.
Visual Basic.
PowerBuilder.
Delphi.
C++.
Os usuários queriam janelas bonitas.
Botões.
Menus.
Mouse.
Mas...
O COBOL continuava funcionando perfeitamente.
Então nasceu uma ideia simples.
Criar uma camada intermediária.
Windows
↓
Servidor
↓
CICS
↓
COBOL
O Windows deixou de conversar diretamente com o CICS.
Agora existia um servidor traduzindo tudo.
Era o nascimento do middleware moderno.
Depois chegou a Internet.
Essa mudou tudo.
Agora qualquer navegador precisava conversar com o banco.
Mas HTML não entende COBOL.
JavaScript não conhece CICS.
Foi necessário criar outra ponte.
Browser
↓
Apache
↓
Java
↓
CICS
↓
COBOL
Observe.
O COBOL continuava igual.
Quem mudou foi o tradutor.
 |
| Bellacosa Mainframe e o fluxo teorico em 2000 |
O nascimento dos Application Servers
Na década de 2000 apareceram servidores como:
IBM WebSphere
JBoss
WebLogic
Tomcat
Agora um servlet Java recebia a requisição.
Esse servlet chamava:
CICS
MQ
IMS
DB2
O navegador nunca falava diretamente com o mainframe.
Ele conversava com Java.
Java conversava com o IBM Z.
E onde entra o MQ?
Imagine um restaurante.
Você faz um pedido.
A cozinha está ocupada.
O garçom não fica parado esperando.
Ele coloca o pedido na fila.
Depois entrega quando estiver pronto.
MQ faz exatamente isso.
Aplicação
↓
Fila
↓
MQ
↓
COBOL
É comunicação assíncrona.
Muito mais segura.
Muito mais confiável.
Se o programa estiver indisponível por alguns segundos...
A mensagem continua esperando.
Nada é perdido.
Depois vieram os Web Services.
Agora o mundo falava XML.
Surgiram SOAP.
WSDL.
XSD.
O fluxo ficou parecido com isto.
HTML
↓
SOAP
↓
Application Server
↓
CICS
↓
COBOL
O COBOL ainda não entendia XML.
Mas havia componentes convertendo XML em estruturas COBOL.
Era tradução.
Sempre tradução.
 |
| Bellacosa Mainframe e o fluxo teorico em 2010 |
REST mudou novamente o cenário.
Agora quase tudo conversa usando HTTP.
GET
POST
PUT
DELETE
E normalmente JSON.
{
"conta":12345
}
O navegador envia JSON.
O COBOL continua trabalhando com COPYBOOK.
Alguém precisa converter.
Quem faz isso?
Hoje normalmente:
z/OS Connect
CICS Web Services
Java
API Gateway
O nascimento do z/OS Connect
Essa talvez tenha sido uma das maiores evoluções do IBM Z.
Agora o fluxo pode ser assim.
React
↓
REST
↓
JSON
↓
z/OS Connect
↓
CICS
↓
COBOL
O desenvolvedor React acredita que está falando com uma API qualquer.
Na realidade...
Existe um programa COBOL do outro lado.
Sem ele perceber.
Vamos acompanhar uma consulta de saldo.
Você toca no botão.
Consultar Saldo
O aplicativo cria um JSON.
{
conta:1234
}
Esse JSON segue pela internet.
HTTPS.
TLS.
Chega ao API Gateway.
O Gateway verifica:
certificado
autenticação
limite
token
autorização
Se tudo estiver correto...
Encaminha ao z/OS Connect.
O que faz o z/OS Connect?
Ele transforma isto:
JSON
naquilo:
COPYBOOK COBOL
Por exemplo.
JSON.
{
cliente:100
}
vira
01 CLIENTE.
05 CODIGO PIC 9(5).
Nenhum COBOL precisou ser alterado.
Ele continua recebendo estruturas COBOL.
Como sempre recebeu.
Agora entra o CICS.
O CICS recebe a requisição.
Seleciona uma Task.
Reserva memória.
Cria o ambiente.
Chama o programa COBOL.
Tudo isso acontece em poucos milissegundos.
O COBOL faz exatamente o que fazia em 1992.
Consulta DB2.
Ou VSAM.
Ou IMS.
Calcula saldo.
Verifica limites.
Executa regras de negócio.
Nada mudou.
As regras continuam ali.
Testadas durante décadas.
O retorno começa.
O COBOL devolve uma estrutura.
01 SALDO.
05 VALOR PIC S9(9)V99.
O CICS devolve ao z/OS Connect.
O z/OS Connect transforma.
COPYBOOK
↓
JSON
Agora temos.
{
"saldo":2450.80
}
O aplicativo Android recebe.
Atualiza a tela.
O usuário acredita que tudo aconteceu diretamente.
Na verdade dezenas de componentes participaram.
E onde entra Java?
Em muitos lugares.
Pode existir:
Android
↓
REST
↓
Spring Boot
↓
MQ
↓
COBOL
Ou
Angular
↓
Spring
↓
CICS TG
↓
COBOL
Ou
React
↓
Java
↓
IMS
↓
DB2
Java normalmente funciona como uma camada de negócios moderna.
E Node.js?
Também.
React
↓
Node.js
↓
REST
↓
z/OS Connect
↓
COBOL
Nada impede.
O IBM Z conversa com praticamente qualquer linguagem moderna.
E Python?
Também.
Python pode consumir APIs REST normalmente.
Python
↓
HTTPS
↓
JSON
↓
API
↓
Mainframe
O Python não sabe que existe um COBOL atrás da API.
Nem precisa saber.
E C#?
Exatamente igual.
C#
↓
REST
↓
Gateway
↓
Mainframe
E Go?
Também.
Rust?
Também.
Kotlin?
Também.
Flutter?
Também.
React Native?
Também.
 |
| Bellacosa Mainframe e o fluxo teorico em 2020 |
O protocolo mudou.
O conceito permaneceu.
Essa talvez seja a maior descoberta para um Padawan.
Muitos acreditam que aprender IBM Z significa abandonar tudo que conhecem.
Na verdade...
Você continua trabalhando com exatamente os mesmos conceitos.
Existe uma requisição.
Existe uma resposta.
Existe autenticação.
Existe autorização.
Existe uma camada de negócio.
Existe persistência.
Existe tratamento de erro.
Existe auditoria.
Existe segurança.
Esses conceitos nunca mudaram.
Mudaram apenas os protocolos.
O login moderno
Hoje um login costuma seguir aproximadamente este caminho.
Usuário
↓
Aplicativo
↓
HTTPS
↓
API Gateway
↓
OAuth2
↓
OpenID Connect
↓
JWT
↓
Servidor
↓
Mainframe
Depois do login o aplicativo recebe um Token.
JWT
Nas próximas chamadas ele envia apenas o Token.
O Gateway valida.
Se estiver correto...
A requisição segue.
O COBOL nem precisa conhecer JWT.
Alguém já validou antes.
O que continua exatamente igual?
Muito mais do que você imagina.
Ainda existem:
transações
commits
rollback
controle de concorrência
integridade
logs
auditoria
segurança
alta disponibilidade
recuperação
controle de acesso
regras de negócio
Esses pilares continuam praticamente idênticos há décadas.
O que realmente mudou?
Mudou quase tudo ao redor.
Antes:
3270
Hoje:
Android
iPhone
React
Angular
Vue
Windows
Electron
Flutter
Antes:
SNA
Hoje:
TCP/IP
HTTPS
REST
gRPC
Antes:
Tela 3270
Hoje:
JSON
Antes:
Terminal
Hoje:
API
Antes:
Monolito fechado
Hoje:
Microserviços consumindo APIs
Antes:
Operador interno
Hoje:
Milhões de usuários simultâneos
Mas o coração permanece surpreendentemente parecido.
O segredo do IBM Z
Existe uma frase que gosto de repetir aos meus alunos.
O mundo moderno não substituiu o mainframe. Aprendeu a conversar com ele.
Quando você abre um aplicativo de banco no celular, dificilmente imagina que aquela animação elegante, construída em Kotlin, Swift ou Flutter, pode terminar em um programa COBOL executando dentro de um CICS no IBM Z. No entanto, é exatamente isso que acontece milhões de vezes por dia.
O desenvolvedor do aplicativo pensa em telas, componentes, animações e experiência do usuário. O desenvolvedor de APIs pensa em REST, JSON, OAuth e microsserviços. O arquiteto de integração pensa em API Gateway, mensageria, balanceamento e observabilidade. E, no centro desse ecossistema, o COBOL continua fazendo o que sempre fez com excelência: aplicar regras de negócio, proteger dados e garantir que uma transferência de dinheiro, uma compra com cartão ou o pagamento de um benefício aconteçam com precisão absoluta.
Essa é a verdadeira evolução do software. Não jogar fora décadas de conhecimento, mas construir novas camadas sobre uma base sólida.
A Última Xícara de Café
Padawan, quando alguém disser que "o aplicativo conversa diretamente com o banco", lembre-se desta jornada invisível.
Um simples toque na tela percorre redes, protocolos, gateways, autenticação, criptografia, APIs, conversores de JSON para COPYBOOK, gerenciadores de transações, filas de mensagens, programas COBOL e bancos de dados, antes de retornar como um número exibido em poucos milissegundos.
A tela mudou.
A linguagem mudou.
Os protocolos mudaram.
As ferramentas mudaram.
Mas a essência continua a mesma desde os primeiros dias da computação corporativa: receber uma solicitação, validar quem a fez, executar regras de negócio com segurança, acessar dados de forma íntegra e devolver uma resposta confiável.
É por isso que o IBM Z continua relevante. Não porque resiste ao novo, mas porque se adapta a ele sem abrir mão daquilo que realmente importa: confiabilidade, disponibilidade, segurança e consistência.
No fim das contas, Android, Windows, HTML, JavaScript, Java, Node.js, Python, Go ou Rust não competem com o mainframe. Eles são apenas novos idiomas para conversar com um dos computadores mais confiáveis já construídos.
E talvez essa seja a maior lição desta conversa: a tecnologia muda; a boa engenharia permanece.
