Pular para o conteúdo principal

Questão de Arquitetura de Software — SOA (Service-oriented architecture) — FCC 2026

Arquitetura de SoftwareSOA (Service-oriented architecture)
Código
gp045407
Banca
FCC
Órgão
MPE-AL
Ano
2026
Cargo
Analista do Ministério Público - Especialidade: Desenvolvimento de Sistemas
Uma equipe de desenvolvimento de sistemas de um órgão público pretende modernizar seu ambiente sistêmico, atualmente baseado em uma estrutura cliente-servidor saturada. A nova solução deve permitir o desacoplamento de funcionalidades críticas, facilitar a integração com órgãos externos via protocolos padronizados e garantir que falhas em módulos específicos não paralisem o sistema por completo, prevendo ainda estratégia técnica que atenda aos requisitos de escalabilidade e integração institucional, por é:
  1. AEvolução para uma arquitetura de microsserviços com bancos de dados independentes, utilizando princípios de SOA para interoperabilidade com sistemas externos e mantendo camadas lógicas para a organização dos serviços internos.
  2. BManutenção da arquitetura cliente-servidor para os sistemas legados e adoção de multicamadas para os novos módulos, centralizando a orquestração de processos no servidor de aplicação para minimizar a latência de rede entre as unidades.
  3. CTransição para arquitetura multicamadas com foco na separação lógica entre apresentação e persistência, utilizando o modelo SOA para gerenciar a comunicação síncrona entre os módulos internos via barramento de serviços centralizado.
  4. DImplementação de uma arquitetura orientada a serviços para substituir o modelo cliente-servidor, mantendo a lógica de negócio concentrada em um único repositório de dados para evitar a fragmentação da integridade referencial.
  5. EMigração da estrutura cliente-servidor para um modelo de microsserviços onde cada componente compartilha a camada de persistência, garantindo a uniformidade dos dados sem necessidade de sincronização ou replicação.
Revelar gabarito e comentário

GabaritoA — Evolução para uma arquitetura de microsserviços com bancos de dados independentes, utilizando princípios de SOA para interoperabilidade com sistemas externos e mantendo camadas lógicas para a organização dos serviços internos.

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”.

Modernização de Sistemas: SOA e Microsserviços

Gabarito: letra A. A alternativa combina microsserviços com bancos de dados independentes, aplicando princípios SOA para interoperabilidade e mantendo camadas lógicas. Isso atende aos requisitos de desacoplamento, falhas isoladas, escalabilidade e integração com órgãos externos. As demais alternativas falham em um ou mais aspectos: manutenção de legado, centralização excessiva, base única de dados ou persistência compartilhada.

A banca testa a compreensão de que SOA é um modelo arquitetural focado em baixo acoplamento e reuso, e que microsserviços são uma implementação moderna que respeita esses princípios, especialmente com bancos de dados independentes.

Alternativa A — ✅ Correta ⟵ GABARITO

A evolução para microsserviços com bancos de dados independentes promove desacoplamento total entre funcionalidades críticas. A utilização de princípios SOA garante interoperabilidade com sistemas externos via protocolos padronizados (como SOAP ou REST). Falhas em um microsserviço não afetam os demais, e a arquitetura permite escalabilidade horizontal. A manutenção de camadas lógicas organiza os serviços internos sem comprometer o desacoplamento.

Alternativa B — ❌ Incorreta

Manter a arquitetura cliente-servidor para legados e adotar multicamadas para novos módulos não resolve o desacoplamento desejado. A centralização da orquestração no servidor de aplicação cria um ponto único de falha e não isola módulos críticos. Além disso, a latência de rede não é o foco principal; a arquitetura não atende à tolerância a falhas e escalabilidade.

Alternativa C — ❌ Incorreta

A transição para multicamadas com separação lógica entre apresentação e persistência é insuficiente para o desacoplamento de funcionalidades. Utilizar SOA com comunicação síncrona via barramento centralizado (ESB) introduz um ponto único de falha e dependência. A comunicação síncrona também pode prejudicar o desempenho e a resiliência, contrariando os requisitos de falhas isoladas.

Alternativa D — ❌ Incorreta

Implementar SOA mas concentrar a lógica de negócio em um único repositório de dados viola o princípio de baixo acoplamento, criando dependências entre serviços. Isso impede a escalabilidade independente e torna o sistema vulnerável a falhas no banco de dados, contrariando os objetivos de desacoplamento e tolerância a falhas.

Alternativa E — ❌ Incorreta

Migrar para microsserviços mas compartilhar a camada de persistência contradiz a essência do modelo. Microsserviços devem ter bancos de dados próprios para garantir independência. O compartilhamento cria acoplamento forte, e a afirmação de que não há necessidade de sincronização é falsa, pois mudanças em um serviço podem impactar os outros.

PEGA ESSA DICA!

Lembre-se: SOA é baseado em baixo acoplamento, reuso e interoperabilidade. Microsserviços são uma forma de implementar SOA, e uma prática essencial é cada serviço possuir seu próprio banco de dados (database per service), garantindo independência e escalabilidade.

Gabarito: letra A.

Link permanente: /questoes/gp045407