1. O modelo de mensageria assíncrona
Na comunicação síncrona (chamada direta, REST, RPC), o chamador espera o processamento terminar antes de continuar. Na comunicação assíncrona via mensagens, o remetente coloca a mensagem em uma fila e segue em frente — o receptor processa quando disponível.
🦕 Analogia — fila de banco vs atendimento presencial
Comunicação síncrona é como atendimento presencial: você chega, espera a atendente ficar disponível, explica o que precisa e aguarda ela resolver antes de sair. Comunicação assíncrona via MQ é como deixar uma solicitação na caixa de entrada: você coloca o pedido, vai embora, e a resposta estará na sua caixa de saída quando voltar. Nenhum dos dois precisa estar disponível ao mesmo tempo.
As vantagens do modelo assíncrono em sistemas críticos:
- Desacoplamento — produtor e consumidor não precisam estar no ar ao mesmo tempo
- Resiliência — mensagens persistidas na fila sobrevivem a reinicializações de sistema
- Balanceamento — múltiplos consumidores processam a fila em paralelo
- Garantia de entrega — o MQ garante que cada mensagem é processada exatamente uma vez
2. Arquitetura do IBM MQ
Os componentes centrais do IBM MQ:
| Componente | Função |
|---|---|
| Queue Manager (QM) | O servidor MQ — gerencia filas, processa mensagens, controla persistência e segurança |
| Queue (Fila) | Repositório onde mensagens ficam armazenadas aguardando processamento |
| Message | O dado transmitido — composto de cabeçalho (MQMD) e corpo (payload) |
| Channel | Conexão lógica entre Queue Managers — transporta mensagens entre sistemas |
| Listener | Processo que escuta conexões TCP/IP de entrada para o Queue Manager |
| Application | Produtor (PUT) ou consumidor (GET) de mensagens via API MQ |
3. IBM MQ no z/OS
No z/OS, o IBM MQ roda como um conjunto de address spaces (processos do sistema operacional). O Queue Manager principal é chamado de subsistema MQ e tem um nome de até 4 caracteres (ex: CSQ1, MQ01).
| Address Space | Função |
|---|---|
CSQ1MSTR | Master address space — coordena todos os outros |
CSQ1CHIN | Channel Initiator — gerencia canais e listeners TCP/IP |
CSQ1OPER | Operations and Control — interface com o operador |
O MQ no z/OS usa o Coupling Facility do Sysplex para alta disponibilidade — filas compartilhadas (Shared Queues) permitem que múltiplos Queue Managers no mesmo Sysplex acessem as mesmas mensagens, garantindo continuidade mesmo se um QM falhar.
💡 MQSC — a linguagem de administração do MQ
O MQ é administrado via comandos MQSC (MQ Script Commands) — uma linguagem própria executada no console do z/OS, no TSO (via CSQUTIL) ou no MQ Explorer. Os principais verbos são: DEFINE, ALTER, DELETE, DISPLAY, START e STOP. Nos próximos artigos usaremos MQSC extensivamente.
4. Casos de uso em bancos
Em ambientes bancários, o IBM MQ está presente em praticamente todas as integrações críticas:
| Cenário | Como o MQ atua |
|---|---|
| PIX e TED | Mensagens de instrução de pagamento entre o sistema do banco (COBOL/CICS) e o SPI do BACEN |
| Core banking → Internet Banking | Saldo e extrato do mainframe publicados em fila — consumidos pela camada web em tempo quase-real |
| Integração com seguradoras | Proposta de seguro gerada no mainframe → fila MQ → sistema de precificação externo → resposta na fila de retorno |
| Processamento de lote assíncrono | Batch COBOL envia notificações de processamento para fila MQ → sistema de notificação distribui por SMS/email |
5. MQ vs outras formas de integração
| Mecanismo | Tipo | Quando usar |
|---|---|---|
| IBM MQ | Assíncrono, persistente | Integração entre sistemas heterogêneos, garantia de entrega, processamento desacoplado |
| CICS Web Services | Síncrono | Consultas em tempo real que precisam de resposta imediata |
| Shared Datasets | Batch | Transferência de grandes volumes de dados entre sistemas no mesmo datacenter |
| Kafka | Assíncrono, streaming | Streaming de eventos em alta frequência — complementar ao MQ em arquiteturas modernas |
IBM MQ e Kafka não são excludentes — muitas arquiteturas usam MQ para integração com o mainframe e Kafka para streaming entre microsserviços, com um conector MQ-Kafka fazendo a ponte.