Arquitetura orientada a serviços (SOA) e o barramento de serviços corporativo (ESB)

A arquitetura orientada a serviços (SOA, de service-oriented architecture) foi a resposta corporativa a um problema que continua existindo: dezenas de aplicações, cada uma construída para um departamento, cada uma com sua própria cópia dos dados de clientes, ligadas por centenas de transferências de arquivos e links entre bancos de dados sem documentação. A SOA propunha expor as capacidades de cada aplicação como serviços definidos a partir do contrato, rotear as chamadas por uma infraestrutura compartilhada e compor os processos de negócio a partir desses serviços. O estilo atingiu seu auge nos anos 2000, foi muitas vezes superdimensionado e depois se tornou, discretamente, a base sobre a qual os microsserviços e as plataformas de APIs foram construídos. Entendê-lo explica muito sobre os sistemas que você vai herdar e sobre o vocabulário dos seus arquitetos.

O problema: silos e espaguete

Empresas crescem aplicação por aplicação. Vendas ganha um CRM, o financeiro ganha um ERP, operações constrói um sistema de agendamento sob medida, e cada um guarda "o" cadastro do cliente. Quando um processo atravessa departamentos — do pedido ao recebimento, do sinistro ao pagamento — os dados precisam circular entre esses silos, e o jeito mais barato na hora é um link ponto a ponto: uma extração noturna, uma view no banco, uma chamada direta de API.

Com n aplicações, a integração ponto a ponto tende a n(n−1)/2 interfaces. Cada uma é construída uma vez, raramente documentada e fica sem dono depois que o autor vai embora. As consequências são previsíveis:

• Dados redundantes e inconsistentes. Três cadastros mestres de clientes que discordam sobre um endereço.
• Acoplamento forte. Mudar uma tabela no CRM quebra um relatório do financeiro que ninguém sabia que a lia.
• Nenhum reúso. A análise de crédito é reimplementada no sistema de empréstimos, no de cartões e no de leasing.
• Processos rígidos. Um novo canal de distribuição (mobile, um portal de parceiros) significa reconstruir todas as integrações.
• Qualidade de serviço impossível de medir. Ninguém consegue dizer qual é a disponibilidade ou o tempo de resposta de "buscar cliente", porque isso não existe — só existem quinze jeitos de ler a tabela.

A premissa da SOA é que esses são problemas de arquitetura, não de projeto, e que a solução é introduzir uma camada de serviços com contratos explícitos entre os processos que precisam de capacidades e as aplicações que as fornecem.

O que faz de algo um serviço

As definições variam, mas as propriedades que importam na prática são as mesmas em todas elas.

Um serviço expõe um contrato e esconde sua implementação. Os consumidores enxergam uma interface — operações, formatos de mensagem, termos de qualidade de serviço — e nada mais. O consumidor não deve saber nem se importar se o serviço é sustentado por um mainframe, uma aplicação Java ou uma macro de planilha.

As fronteiras são explícitas. Chamar um serviço é trocar mensagens através de uma fronteira, com a latência e os modos de falha que isso implica. É diferente de chamar um método de um componente no mesmo processo, e designs que fingem o contrário (serviços de granularidade fina e tagarelas) fracassam.

Os serviços são autônomos. Cada um pode ser implantado, versionado e operado de forma independente, e é dono dos dados de que precisa para cumprir seu contrato. Bancos de dados compartilhados entre serviços violam esse princípio e foram a forma mais comum de os programas de SOA sabotarem a si mesmos.

A compatibilidade se baseia em políticas, não em código. Se um consumidor pode ou não chamar um serviço é decidido por requisitos declarados — segurança, transporte, confiabilidade — e não pelo compartilhamento de bibliotecas.

Outros dois atributos de design decidem se um serviço é de fato reutilizável. A granularidade deve servir ao consumidor: um serviço que devolve a ficha completa do cliente quando quem chama precisa de um CEP é um desperdício; um que exige doze chamadas para montar um endereço é tagarela. A ausência de estado (statelessness) — nenhum estado de conversa mantido entre chamadas — torna os serviços mais fáceis de escalar e de substituir, por isso é o padrão, e os processos de longa duração ficam a cargo de uma camada de processos explícita, e não de estado de sessão dentro do serviço.

Serviços versus componentes

Um componente é uma unidade de implantação dentro de uma aplicação: tem interfaces fornecidas e requeridas, propriedades de configuração e um ciclo de vida gerenciado por um contêiner. Um serviço é uma unidade de capacidade de negócio oferecida a várias aplicações. A especificação Service Component Architecture (SCA) tentou unificar os dois — montar composites de componentes e expô-los como serviços por meio de bindings configuráveis (SOAP, JMS, RMI) — e é um modelo mental útil mesmo que você nunca use um runtime SCA: componentes são como você constrói um serviço; serviços são o que você expõe.

A pilha de web services

SOA é um estilo; web services SOAP foram sua implementação dominante por uma década. Três especificações carregam a maior parte do peso.

SOAP (originalmente Simple Object Access Protocol; a sigla foi abandonada na versão 1.2) define um envelope XML com um cabeçalho para metadados — tokens de segurança, endereçamento, contexto transacional — e um corpo que transporta o payload. Ele é independente de transporte, embora HTTP seja usado quase sempre.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <!-- WS-Security, WS-Addressing and similar headers go here -->
  </soap:Header>
  <soap:Body>
    <getBalance xmlns="urn:example:accounts">
      <accountNumber>FR7630006000011234567890189</accountNumber>
    </getBalance>
  </soap:Body>
</soap:Envelope>

WSDL (Web Services Description Language) é o contrato legível por máquina. Um documento WSDL 1.1 declara os types de XML Schema usados, as estruturas message, um portType que lista as operações, um binding que diz como essas operações são mapeadas para um protocolo (normalmente SOAP sobre HTTP) e um service com o endereço do endpoint. O ferramental gera stubs de cliente e esqueletos de servidor a partir dele, e é por isso que o desenvolvimento contract-first era natural nesse mundo: escrever o WSDL e o schema, gerar o código e depois implementar.

<definitions name="Accounts" targetNamespace="urn:example:accounts"
             xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types><!-- XML Schema for request/response elements --></types>
  <message name="getBalanceRequest"><part name="body" element="tns:getBalance"/></message>
  <message name="getBalanceResponse"><part name="body" element="tns:getBalanceResponse"/></message>
  <portType name="AccountsPort">
    <operation name="getBalance">
      <input message="tns:getBalanceRequest"/>
      <output message="tns:getBalanceResponse"/>
    </operation>
  </portType>
  <binding name="AccountsSoap" type="tns:AccountsPort"><!-- SOAP/HTTP details --></binding>
  <service name="AccountsService">
    <port name="AccountsSoap" binding="tns:AccountsSoap">
      <soap:address location="https://api.example.com/accounts"/>
    </port>
  </service>
</definitions>

UDDI (Universal Description, Discovery and Integration) era o registro onde os serviços deveriam ser publicados e descobertos. Os registros UDDI públicos foram desativados há anos; os privados sobreviveram como o componente "registry and repository" das ferramentas de governança, e a ideia reaparece hoje na forma de catálogos de APIs e portais de desenvolvedores.

Em volta disso ficavam as especificações WS-*: WS-Security para assinar e criptografar mensagens, WS-ReliableMessaging para entrega garantida, WS-Addressing para roteamento, WS-AtomicTransaction para commit em duas fases entre serviços. Elas resolviam problemas reais e também foram o motivo da fama de complexidade do SOAP: a interoperabilidade entre as pilhas de fornecedores diferentes era frágil, e poucos times precisavam de algo além da segurança.

REST sobre HTTP com JSON tomou o lugar do SOAP na maioria das interfaces novas porque não exige ferramental especial, se encaixa naturalmente na infraestrutura de cache e segurança da web e permite escrever um cliente em uma tarde. A contrapartida é que REST não tem uma linguagem de contrato padrão com rigor equivalente, lacuna que o OpenAPI preencheu depois. O guia de design de APIs REST cobre esse estilo em profundidade; ainda vale a pena ler SOAP com fluência, porque muitos sistemas corporativos centrais continuam falando essa língua.

O barramento de serviços corporativo

Um barramento de serviços corporativo (ESB) é um middleware que fica entre consumidores e provedores de serviços e realiza a mediação. Suas responsabilidades típicas são:

Os padrões de design que um ESB implementa — content-based router, message translator, splitter, aggregator, dead-letter channel — estão catalogados na literatura de Enterprise Integration Patterns e são igualmente relevantes quando você constrói a mesma coisa com um broker e alguns serviços.

Um conceito que costuma acompanhá-lo é o modelo de dados canônico: um único schema corporativo para "cliente", "pedido" e assim por diante, para o qual o formato de cada aplicação é traduzido. Ele reduz o número de transformações de n² para 2n, mas tende a virar um schema gigantesco de mínimo denominador comum que todos os times precisam alterar juntos. Designs modernos mantêm os formatos locais a cada bounded context e traduzem na fronteira, ponto desenvolvido no guia de domain-driven design.

Onde o barramento deu errado

O modo de falha do ESB é que é conveniente colocar lógica nele. Uma regra de roteamento vira uma validação, uma validação vira uma chamada de enriquecimento, e em poucos anos o barramento contém as regras de negócio mais importantes da empresa, nas mãos de um time central de integração atrás do qual todo projeto fica na fila. Os deploys do barramento viram eventos de alto risco, porque tudo passa por ele. Os fornecedores venderam suítes cada vez maiores — barramento, motor de processos, motor de regras, registro, monitoramento — e o custo de licenças e de profissionais especializados empurrou as organizações para uma única instância compartilhada, o que maximizou o acoplamento.

A lição que os microsserviços tiraram disso foi "smart endpoints, dumb pipes" (pontas inteligentes, canos burros): manter a transformação e as regras dentro dos serviços que são donos dos dados e usar a infraestrutura apenas para transportar mensagens. A lógica de integração não desapareceu; ela se mudou para onde está o conhecimento do domínio.

Processos, orquestração e coreografia

Os serviços ganham valor quando são compostos em processos de negócio. Existem dois modelos.

A orquestração coloca um maestro central no comando — um motor de processos que executa um modelo escrito em BPMN (Business Process Model and Notation) ou, historicamente, em BPEL. O motor chama os serviços em ordem, espera respostas ou tarefas humanas, trata prazos e escalonamentos e registra o estado de cada instância em andamento. Analistas de negócio conseguem ler o modelo; a operação consegue ver onde cada instância está parada. O motor também é o ponto único onde todo o processo fica acoplado.

A coreografia não tem maestro. Cada serviço reage a eventos publicados pelos outros: quando um pedido é feito, o estoque reserva os itens e publica "estoque reservado", o faturamento cobra o cartão ao receber esse evento, a expedição despacha ao receber "pagamento capturado". O acoplamento é mínimo e cada time é dono da sua etapa, mas ninguém tem a visão de ponta a ponta, e responder "onde está o pedido 4711?" exige correlacionar eventos entre serviços.

O guia de transações distribuídas volta a essa escolha no contexto de sagas; o mesmo trade-off vale em qualquer escala.

Ao lado dos motores de processos ficam os motores de regras de negócio, que tiram a lógica de decisão — elegibilidade, precificação, scoring — do código e a colocam em tabelas de regras que o negócio consegue manter. Eram vendidos como parte da suíte SOA e são úteis justamente quando as regras mudam com mais frequência que o software ao redor; tornam-se contraproducentes quando viram uma segunda linguagem de programação que ninguém testa.

Governança e método

A SOA vive ou morre pela governança, porque o reúso só acontece se os serviços forem encontráveis, confiáveis e estáveis.

• Portfólio de serviços e responsáveis. Cada serviço tem um responsável nomeado, um estado de ciclo de vida (planejado, ativo, descontinuado, aposentado) e uma política de versionamento. Versões descontinuadas rodam em paralelo, com uma data de desativação publicada.
• Contratos e qualidade de serviço. O contrato inclui termos não funcionais: tempo de resposta por operação, disponibilidade, atualidade dos dados (tempo real ou batch noturno), limites de vazão. Sem eles, o consumidor não consegue decidir se um serviço atende à sua necessidade.
• Padrões de design. Nomenclatura, convenções de schema, tratamento de erros e perfis de segurança são acordados uma única vez, para que os consumidores não precisem aprender um dialeto novo a cada serviço.
• Registro. Um catálogo onde serviços, contratos, responsáveis e consumidores ficam registrados. Seu descendente moderno é o portal de desenvolvedores de uma plataforma de gestão de APIs.

O método de design clássico vai de cima para baixo, do processo de negócio ao serviço: modelar os processos, identificar as entidades de negócio e as atividades que atuam sobre elas, agrupar as atividades em serviços candidatos por coesão e reúso, mapear cada candidato para aplicações existentes ou para um desenvolvimento novo e, então, definir os contratos. Abordagens de baixo para cima — encapsular o que existe e expor — entregam mais rápido, mas reproduzem o formato dos silos. A maioria dos programas precisa das duas: de baixo para cima no primeiro ano, para provar valor, e de cima para baixo para moldar o que vem a seguir.

SOA comparada com microsserviços

Os dois estilos compartilham princípios e diferem em escopo, granularidade e infraestrutura.

Trate a comparação como um espectro, não como um veredito. Uma organização com duzentas aplicações de pacote ainda precisa de arquitetura de integração em escala corporativa, e as lições da governança SOA se aplicam diretamente; um único time de produto quebrando um monólito precisa do manual de microsserviços. O erro é aplicar qualquer um dos dois na escala errada.

Erros comuns

Serviços que expõem o banco de dados. Um "serviço de clientes" com as operações getCustomerRow e updateCustomerRow é uma tabela remota, não um serviço; todo consumidor continua dependendo do schema. Correção: operações em termos de negócio (openAccount, changeAddress), com o schema escondido.

Interfaces de granularidade fina e tagarelas. Projetar operações SOAP como métodos locais produz dez idas e voltas por tela. Correção: operações de granularidade grossa que devolvem em uma única chamada o que um caso de uso precisa.

Tudo pelo barramento. Dois serviços do mesmo time chamando um ao outro pelo ESB central acrescentam latência, uma dependência de deploy e uma fila de tickets. Correção: usar o barramento para integração entre domínios e com sistemas legados; deixar serviços muito próximos conversarem diretamente.

Modelo canônico como monólito. Um único schema corporativo que todo projeto precisa estender. Correção: formatos canônicos por domínio de negócio, com tradução nas fronteiras.

Governança sem automação. Comitês de revisão que aprovam cada contrato à mão viram o gargalo e acabam sendo contornados. Correção: codificar os padrões como linters, testes de contrato e verificações no pipeline; reservar a revisão humana para decisões de design.

Ignorar a qualidade de serviço. Publicar um serviço sem declarar seu tempo de resposta ou sua disponibilidade. Correção: todo contrato declara termos mensuráveis, e o monitoramento comprova que eles são cumpridos.

Principais pontos

• A SOA atacou problemas reais — silos, espaguete ponto a ponto, dados e lógica duplicados — introduzindo serviços definidos a partir do contrato, com fronteiras explícitas.
• Um serviço esconde sua implementação, é dono dos seus dados, é autônomo e sem estado por padrão e é projetado com uma granularidade que atende aos seus consumidores.
• SOAP, WSDL e as especificações WS-* implementaram a SOA nos anos 2000; REST e OpenAPI os substituíram nas interfaces novas, mas sistemas SOAP continuam por toda parte.
• O ESB oferece roteamento, transformação, ponte entre protocolos e orquestração; seu modo de falha é absorver lógica de negócio e virar um gargalo central.
• A orquestração dá visibilidade e controle ao custo de um acoplamento central; a coreografia dá autonomia ao custo da visão de ponta a ponta.
• A governança — responsáveis, contratos com termos de qualidade de serviço, padrões, um registro — é o que torna o reúso real, e só funciona quando é automatizada.
• Os microsserviços mantêm os princípios da SOA e rejeitam sua infraestrutura e sua centralização; escolha pela escala, não pela moda.