Questão de Arquitetura de Software — SOA (Service-oriented architecture) — FGV 2024
Arquitetura de Software›SOA (Service-oriented architecture)
Código
fg079716
Banca
FGV
Órgão
DATAPREV
Ano
2024
Nível
Superior
Cargo
ATI - Desenvolvimento de Software
Uma empresa de comércio eletrônico decidiu integrar seus sistemas de pagamento usando uma arquitetura orientada a serviços e web services como a tecnologia de integração. A ação correta na implementação dessa solução para garantir baixo acoplamento e alta interoperabilidade entre os sistemas seria
Ausar RESTful Web Services, que permitem a comunicação entre os sistemas de forma leve e independente de plataforma, promovendo maior flexibilidade e baixo acoplamento entre os serviços.
Bimplementar serviços SOAP sem definição de contratos formais para aumentar a flexibilidade da comunicação entre o sistema de pagamento e os provedores.
Cutilizar interoperabilidade de rede entre os serviços de pagamento e os provedores, pois isso assegura baixo acoplamento e que as mudanças em um dos serviços se reflitam diretamente no outro, evitando inconsistências
Ddefinir um modelo de arquitetura monolítica com todos os provedores de pagamento integrados diretamente ao sistema, eliminando a necessidade de comunicação via Web Services e, assim, melhorando o desempenho.
Eempregar Web Services com RPC (Remote Procedure Call) e WDSL para garantir que a chamada dos métodos seja feita diretamente entre o sistema de pagamento e os provedores, simplificando a integração.
Revelar gabarito e comentário▾
GabaritoA — usar RESTful Web Services, que permitem a comunicação entre os sistemas de forma leve e independente de plataforma, promovendo maior flexibilidade e baixo acoplamento entre os serviços.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
SOA e Web Services: baixo acoplamento e interoperabilidade
Gabarito: letra A. RESTful Web Services são a escolha mais alinhada aos princípios de baixo acoplamento e alta interoperabilidade em uma Arquitetura Orientada a Serviços (SOA), pois utilizam protocolo HTTP de forma leve, são independentes de plataforma e não exigem contratos rígidos.
A banca testa o conhecimento das características de REST e SOAP no contexto de SOA. Enquanto REST promove acoplamento fraco e flexibilidade, SOAP é mais pesado e depende de contratos formais (WSDL). A alternativa A descreve exatamente os benefícios do REST.
Alternativa
Descrição
Característica Principal
Alinhamento com SOA (Baixo Acoplamento e Alta Interoperabilidade)
A (Gabarito)
RESTful Web Services
Comunicação leve, independente de plataforma, sem estado (stateless), usando HTTP e formatos como JSON/XML.
✅ Correta. Promove baixo acoplamento e alta interoperabilidade, conforme os princípios da SOA.
B
SOAP sem contratos formais
Implementação de SOAP sem definição de WSDL.
❌ Incorreta. A ausência de contratos formais quebra a padronização e compromete a interoperabilidade.
C
Interoperabilidade de rede
Conceito vago que sugere que mudanças em um serviço se reflitam diretamente em outro.
❌ Incorreta. Indica alto acoplamento, oposto ao desejado em SOA.
D
Arquitetura monolítica
Todos os provedores integrados em um único bloco, sem uso de Web Services.
❌ Incorreta. Contraria o princípio de baixo acoplamento e a independência entre serviços.
E
RPC com WSDL
Chamada direta de métodos remotos usando RPC e descrição WSDL.
❌ Incorreta. RPC tende a criar maior acoplamento, e a descrição WSDL, embora padronizada, não garante por si só baixo acoplamento.
SOA e Web Services
1Baixo acoplamento
REST (leve, stateless, JSON/XML)
SOAP (contrato rígido WSDL)
2Interoperabilidade
REST (independe de plataforma)
Monolito (alto acoplamento)
3Práticas incorretas
SOAP sem contrato
RPC com WSDL
Interoperabilidade de rede vaga
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
RESTful Web Services utilizam recursos identificados por URIs, operações padronizadas (GET, POST, PUT, DELETE) e representações em formatos como JSON ou XML. Essa abordagem é leve, sem estado (stateless) e independe de plataforma, o que garante baixo acoplamento e alta interoperabilidade — conforme os objetivos da SOA.
Alternativa B — ❌ Incorreta
Serviços SOAP exigem contratos formais definidos em WSDL (Web Services Description Language) para descrever interfaces, mensagens e protocolos. Implementar SOAP sem contratos formais quebra a padronização e compromete a interoperabilidade esperada, além de aumentar o acoplamento. A afirmativa, portanto, contradiz a necessidade de definição de contratos em SOAP.
Alternativa C — ❌ Incorreta
"Interoperabilidade de rede" é um conceito vago e não garante, por si só, baixo acoplamento. A frase "mudanças em um dos serviços se reflitam diretamente no outro" indica alto acoplamento, o oposto do desejado. Em SOA, os serviços devem ser independentes; mudanças em um não devem impactar diretamente os consumidores.
Alternativa D — ❌ Incorreta
Arquitetura monolítica integra todos os componentes em um único bloco, o que contraria frontalmente o princípio de baixo acoplamento e a própria ideia de serviços independentes. Embora o desempenho possa ser melhor em alguns cenários, a manutenção e a escalabilidade são prejudicadas, e a interoperabilidade entre sistemas distintos fica comprometida.
Alternativa E — ❌ Incorreta
RPC (Remote Procedure Call) com WSDL (a questão escreve "WDSL", provável erro de digitação) é uma abordagem típica de SOAP, não de REST. A chamada direta de métodos entre sistemas aumenta o acoplamento, pois expõe detalhes da implementação. REST, ao contrário, expõe recursos e não métodos, promovendo menor acoplamento.
PEGA ESSA DICA!
Na prova, lembre-se: REST = leve, stateless, sem contrato rígido, ideal para baixo acoplamento. SOAP = pesado, exige WSDL, maior acoplamento. Para integrações modernas e flexíveis, REST é a escolha mais comum em SOA.