UA6 — Projeto de Serviços Web
Projetar serviços web vai além de escolher SOAP ou REST. É preciso definir camadas, contratos, mecanismos de descoberta e de comunicação — e entender o que fica 'por trás da interface' para garantir disponibilidade, segurança e escalabilidade.
Arquitetura em 4 Camadas
A estrutura clássica de uma aplicação de serviços web divide responsabilidades em quatro camadas:
| Camada | Responsabilidade | Tecnologias típicas |
|---|---|---|
| Cliente | Interface com o usuário; consome os serviços | Browser, app mobile, outro sistema |
| Web (Container Web) | Recebe requisições HTTP; delega para a camada de negócio | Servlets, JAX-RS, Spring MVC |
| Negócio (EJB / Business Tier) | Lógica de negócio, orquestração de serviços, transações | EJB, Spring, CDI |
| EIS (Enterprise Information Systems) | Acesso a dados, sistemas legados, bancos, filas | JPA, JDBC, JMS, conectores ERP |
O que fica por trás da interface
A interface exposta ao consumidor é apenas a ponta do iceberg. Por trás dela, a infraestrutura garante:
Disponibilidade e Redundância
Alta disponibilidade via balanceamento de carga e redundância de instâncias — o serviço continua mesmo se um nó cair.
Escalabilidade
Capacidade de atender mais requisições adicionando recursos horizontalmente (mais instâncias) ou verticalmente (mais hardware).
Segurança
Autenticação, autorização, criptografia de mensagens (WS-Security para SOAP; JWT/OAuth 2.0 para REST).
Interoperabilidade
Capacidade de se comunicar com sistemas escritos em qualquer linguagem via protocolo padronizado.
Orquestração
Coordenação de múltiplos serviços para compor um processo de negócio mais complexo.
Gerenciamento e Monitoramento
Rastreamento de chamadas, logs, métricas de performance, alertas de falha.
HTTPServlet — o padrão de tratamento de requisições
Na camada Web, cada requisição HTTP é tratada por um Servlet. O método a ser invocado depende do verbo HTTP:
| Método do Servlet | Verbo HTTP | Uso |
|---|---|---|
doGet() | GET | Leitura, busca de recurso |
doPost() | POST | Criação de recurso |
doPut() | PUT | Atualização completa |
doDelete() | DELETE | Remoção de recurso |
doHead() | HEAD | Verifica existência sem retornar corpo |
doOptions() | OPTIONS | Retorna métodos suportados (CORS preflight) |
doTrace() | TRACE | Diagnóstico — raramente usado |
SOAP — Estrutura da Mensagem
Toda mensagem SOAP segue uma estrutura rígida de três elementos:
| Elemento | Obrigatório? | Função |
|---|---|---|
| Envelope | Sim | Elemento raiz; define namespaces e estilo de codificação. É o “container” da mensagem. |
| Header | Não | Informações adicionais (autenticação, transação, rastreamento). Quando presente, deve ser o primeiro filho do Envelope. |
| Body | Sim | Contém o payload real da mensagem (a operação e seus parâmetros). Pode incluir o elemento Fault para reportar erros. |
<!-- Estrutura completa de uma mensagem SOAP -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<auth:token xmlns:auth="...">abc123</auth:token>
</soap:Header>
<soap:Body>
<calcularFrete>
<cep>88000000</cep>
<peso>2.5</peso>
</calcularFrete>
</soap:Body>
</soap:Envelope>WSDL — Descrevendo o Contrato
O WSDL (Web Services Description Language) é um documento XML que descreve completamente um serviço SOAP. Seus elementos principais:
| Elemento | Parte | O que descreve |
|---|---|---|
<types> | Abstrata | Tipos de dados usados nas mensagens (schemas XML) |
<message> | Abstrata | Parâmetros de entrada e saída de cada operação |
<portType> | Abstrata | Conjunto de operações disponíveis (como uma interface) |
<binding> | Concreta | Protocolo e formato de dados para as operações |
<operation> | Concreta | Define entrada, saída e falhas de cada operação |
<definitions> | Raiz | Elemento raiz; contém namespaces e todos os demais |
UDDI — As Três Páginas do Registro
O UDDI organiza as informações dos serviços em três categorias, analogia às antigas listas telefônicas:
Páginas Brancas
Informações gerais do provedor: nome da empresa, endereço, contatos, identificadores. “Quem é esse fornecedor?”
Páginas Verdes
Informações técnicas: endpoints de acesso, interfaces (WSDL), protocolos suportados. “Como acesso o serviço?”
Páginas Amarelas
Categorização por taxonomia de negócio (NAICS, UNSPSC). “Que tipo de serviço é esse?”
Paradigma Localizar–Vincular–Executar
O fluxo completo de uso de um serviço web SOAP com UDDI:
- Publicar: o provedor registra o serviço no UDDI com o link para o WSDL.
- Localizar: o consumidor consulta o UDDI e encontra o serviço adequado.
- Vincular: o consumidor lê o WSDL e gera um proxy (stub) para invocar o serviço.
- Executar: o consumidor invoca o serviço via SOAP (RPC encapsulado em XML sobre HTTP).
REST — Representational State Transfer
Proposto por Roy Fielding em sua dissertação (2000) como estilo arquitetural baseado nos princípios do HTTP. É stateless: cada requisição carrega tudo que o servidor precisa — sem sessão, sem contexto salvo no servidor. O uso de cache reduz latência e carga.
Verbos HTTP — mapeamento CRUD
| Verbo | Operação CRUD | Exemplo | Idempotente? |
|---|---|---|---|
| GET | Read | GET /pedidos/42 | Sim |
| POST | Create | POST /pedidos | Não |
| PUT | Update (total) | PUT /pedidos/42 | Sim |
| PATCH | Update (parcial) | PATCH /pedidos/42 | Não |
| DELETE | Delete | DELETE /pedidos/42 | Sim |
Códigos de Status HTTP
| Código | Significado |
|---|---|
| 200 OK | Sucesso |
| 201 Created | Recurso criado (resposta a POST bem-sucedido) |
| 400 Bad Request | Requisição inválida — erro do cliente |
| 401 Unauthorized | Não autenticado |
| 403 Forbidden | Autenticado mas sem permissão |
| 404 Not Found | Recurso não existe |
| 500 Internal Server Error | Erro no servidor |
Quando usar SOAP vs REST
| Aspecto | SOAP | REST |
|---|---|---|
| Protocolo | Próprio (sobre HTTP/SMTP) | HTTP nativo |
| Formato | XML obrigatório | JSON, XML, qualquer formato |
| Contrato | WSDL (obrigatório) | OpenAPI/Swagger (recomendado) |
| Segurança | WS-Security (robusto, verbose) | JWT, OAuth 2.0 |
| Complexidade | Alta — ferramentas de geração de código obrigatórias | Baixa — qualquer cliente HTTP funciona |
| Uso típico | Sistemas bancários, ERPs, integrações corporativas legadas | APIs mobile, SPAs, microsserviços, cloud |
Conteúdo histórico — Práticas Modernas
O material do curso tem foco em tecnologias Java/JEE do início dos anos 2000. O cenário atual é substancialmente diferente:
- UDDI foi abandonado. Os grandes registros públicos fecharam em 2005–2006. Hoje, a descoberta de serviços usa API Gateway (Kong, AWS API Gateway) com catálogos internos como Backstage (Spotify), ou service mesh com Consul/Kubernetes DNS.
- WSDL/SOAP perderam a hegemonia para REST+OpenAPI. A especificação OpenAPI 3.x substituiu o WSDL como contrato de API. Ferramentas como Swagger UI e Redoc geram documentação navegável automaticamente.
- gRPC como alternativa de alta performance. Para comunicação interna entre microsserviços onde performance importa, o gRPC (Protocol Buffers + HTTP/2) oferece serialização binária muito mais eficiente que SOAP/XML.
- Java EE virou Jakarta EE. O JEE foi doado à Eclipse Foundation e renomeado Jakarta EE. Na prática, Spring Boot domina o mercado; a maioria dos novos projetos não usa EJB.
- Microsserviços + Kubernetes substituem o ESB. Cada serviço expõe uma API REST; o API Gateway faz roteamento, autenticação e rate limiting. O sidecar pattern (Envoy/Istio) cuida de observabilidade e segurança.
Dicas para a Prova
- A arquitetura de serviços web tem 4 camadas: cliente → web (servlets) → negócio (EJB) → EIS.
- Páginas brancas = info geral; páginas verdes = info técnica de acesso; páginas amarelas = categorização por taxonomia.
- Envelope SOAP = apresentação XML; Header = inicializa informações adicionais; Body = dados encapsulados (payload).
- O consumidor precisa do UDDI (para encontrar) e do WSDL (para saber como usar) — os dois juntos permitem a integração.
- SOAP sobre HTTP é a base do RPC via serviços web — XML encapsula a chamada de procedimento remoto trafegando sobre HTTP.
Referências bibliográficas desta UA
- SOMMERVILLE, I. Engenharia de Software, 8ª ed., 2007.
- MENDES, A. Arquitetura de Software, 2002.
- FIELDING, R. Architectural Styles and the Design of Network-based Software Architectures, dissertação de doutorado, 2000.