Software Design

UA5 — Arquitetura Orientada a Serviços (SOA)

SOA organiza o sistema como uma coleção de serviços de negócio reutilizáveis e interoperáveis. Cada serviço é autônomo, com responsabilidade clara e interface bem definida — como departamentos de uma empresa que se comunicam por canais padronizados.

Por que SOA surgiu? — A evolução dos paradigmas

Antes de SOA, os sistemas eram fortemente acoplados: um banco de dados era compartilhado, alterações em uma área quebravam outra, e integrar sistemas de fornecedores diferentes era um pesadelo. O modelo de TI era reativo — esperava o problema surgir para resolver.

Custo de adotar SOA

A adoção de SOA é custosa e nem sempre justificável por duas razões principais:

Mudança cara nos modelos existentes

Transformar sistemas legados em serviços exige redesenhar interfaces, banco de dados e processos. O custo é alto e o risco de regressão é real.

Sistemas que funcionam não precisam de SOA

Se um sistema já atende ao negócio, forçar a migração para SOA pode não trazer ganho proporcional ao investimento. A decisão exige análise custo-benefício.

ESB — o coração do SOA

O Enterprise Service Bus (ESB) é o barramento central que interconecta todos os serviços. Ele funciona como um repositório intermediário inteligente: roteia mensagens, transforma formatos, aplica segurança (via XML Encryption) e monitora o tráfego.

Sem o ESB, cada serviço precisaria se conectar diretamente a todos os outros — criando uma malha de dependências insuportável (o problema de integração ponto-a-ponto). Com o ESB, todos falam com o barramento; o barramento fala com todos.

Os três pilares técnicos do SOA

UDDI — Descoberta

Universal Description, Discovery and Integration. Registro centralizado onde serviços se publicam e consumidores os encontram. Funciona como um “catálogo de serviços” da organização.

WSDL — Interface

Web Services Description Language. Descreve o contrato do serviço em XML: quais operações oferece, que parâmetros aceita, que tipo de dados retorna. É o “manual de uso” do serviço.

SOAP — Comunicação

Simple Object Access Protocol. Protocolo de troca de mensagens baseado em XML. Garante que cliente e servidor se comuniquem de forma padronizada, independente de linguagem ou plataforma.

Como tudo se encaixa — Localizar, Consolidar, Registrar

O paradigma SOA funciona em três fases:

1. Registrar: o provedor publica o serviço no UDDI com o contrato WSDL.
2. Localizar: o consumidor consulta o UDDI para encontrar o serviço que precisa.
3. Consolidar (executar): o consumidor usa o WSDL para montar a chamada SOAP e se comunicar com o serviço via ESB.

BPEL — Orquestração de Processos

O Business Process Execution Language (BPEL) permite descrever um processo de negócio como uma sequência de chamadas a serviços. Em vez de código procedural, o fluxo é definido em XML: “chame o serviço A, depois o B, se falhar chame o C”. O BPM (Business Process Management) é a notação visual usada para modelar esses processos antes de codificá-los em BPEL.

Princípios SOA

Baixo Acoplamento

Serviços independentes — a implementação interna pode mudar sem afetar os consumidores. Essa é a característica central: SOA opera no nível lógico de dependência mais baixo possível.

Abstração

O consumidor vê apenas a interface (WSDL), não a implementação. Java, .NET, Python — tanto faz.

Reutilização

A mesma lógica de negócio exposta como serviço pode ser consumida por múltiplas aplicações simultâneas.

Composição

Serviços simples se combinam via BPEL para construir processos de negócio complexos.

Autonomia

Cada serviço controla sua própria lógica, dados e ciclo de vida.

Stateless

Serviços não guardam estado entre chamadas — escala horizontal sem complicação.

SOA vs. Microsserviços

Microsserviços são frequentemente descritos como “SOA feito certo”. A diferença principal está na granularidade e na forma de orquestração:

Referências bibliográficas desta UA

• SOMMERVILLE, I. Engenharia de Software, 8ª ed., 2007.
• MENDES, A. Arquitetura de Software, 2002.