Questão de Arquitetura de Software — SOA (Service-oriented architecture) — FCC 2019
Arquitetura de Software›SOA (Service-oriented architecture)
Código
fc056726
Banca
FCC
Órgão
SEFAZ-BA
Ano
2019
Cargo
Auditor Fiscal - Tecnologia da Informação - Prova II
Um Auditor Fiscal da área de Tecnologia da Informação observou que na organização onde trabalha há uma grande quantidade de softwares que necessitam validar e inserir informações de contribuintes na base de dados. Cada um destes softwares é mantido por um prestador de serviços diferente e foi escrito em linguagens de programação distintas. Pensando em uma arquitetura voltada a serviços, o Auditor recomendou corretamente a criação de um
AEnterprise Java Bean para incluir os dados dos contribuintes usando um serviço CORBA para validar os dados de entrada.
Bmétodo para validar e incluir contribuintes em cada aplicação, usando a mesma lógica de validação e inclusão de dados.
Cserviço RESTful usando o protocolo SOAP para manter informações de estado nas chamadas ao serviço, permitindo, assim, a consistência de estado na validação dos dados de entrada do contribuinte.
Dportlet para que cada software possa converter os dados dos contribuintes para um formato XML padrão e validá-los com base na mesma lógica centralizada.
Eweb service para validar e incluir contribuintes, de forma que os demais softwares possam simplesmente consumir esse serviço de maneira adequada.
Revelar gabarito e comentário▾
GabaritoE — web service para validar e incluir contribuintes, de forma que os demais softwares possam simplesmente consumir esse serviço de maneira adequada.
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”.
Arquitetura orientada a serviços (SOA) e integração de sistemas heterogêneos
Gabarito: letra E. A necessidade de integrar softwares de diferentes linguagens e mantidos por prestadores distintos é resolvida por um web service, que oferece um ponto único de acesso, interoperabilidade e reuso — exatamente o que a arquitetura SOA prega.
O problema central da questão é a heterogeneidade (linguagens diferentes, fornecedores distintos) e a repetição de lógica (validação e inclusão de contribuintes). A arquitetura orientada a serviços (SOA) propõe a criação de serviços fracamente acoplados, reutilizáveis e independentes de plataforma. Dentre as opções, a que melhor atende é a criação de um web service, que pode ser implementado com SOAP ou REST, e que permite que qualquer aplicação cliente, independentemente de sua tecnologia, consuma a funcionalidade de forma padronizada.
Alternativa
Descrição
Correta?
Motivo da correção/incorreção
A
Enterprise Java Bean + CORBA
❌
Amarra a solução à plataforma Java, não resolve heterogeneidade; CORBA é legado e complexo.
B
Método replicado em cada aplicação
❌
Viola reuso e baixo acoplamento da SOA; aumenta manutenção e inconsistências.
C
Serviço RESTful usando SOAP
❌
REST não usa SOAP; REST é stateless, não mantém estado.
D
Portlet + XML centralizado
❌
Portlet é tecnologia de portal, não resolve integração heterogênea de forma adequada.
E
Web service para validar e incluir contribuintes
✅
Oferece interoperabilidade, reuso e ponto único de acesso, alinhado à SOA.
Alternativa A — ❌ Incorreta
"Enterprise Java Bean para incluir os dados dos contribuintes usando um serviço CORBA para validar os dados de entrada." Embora EJB e CORBA sejam tecnologias de componentes distribuídos, amarrar a solução a EJB (específico da plataforma Java) não resolve a heterogeneidade das linguagens (softwares escritos em diferentes linguagens). Além disso, CORBA é um padrão mais legado e complexo, não sendo a recomendação mais moderna para o cenário descrito.
Alternativa B — ❌ Incorreta
"método para validar e incluir contribuintes em cada aplicação, usando a mesma lógica de validação e inclusão de dados." Essa alternativa propõe replicar a lógica em cada software, o que contraria o princípio de reuso e baixo acoplamento da SOA, além de aumentar o custo de manutenção e a possibilidade de inconsistências.
Alternativa C — ❌ Incorreta
"serviço RESTful usando o protocolo SOAP para manter informações de estado nas chamadas ao serviço." Dois erros graves: RESTful não usa o protocolo SOAP — são abordagens distintas (REST é um estilo arquitetural que geralmente usa HTTP e JSON; SOAP é um protocolo baseado em XML). Além disso, serviços RESTful são projetados para ser stateless (sem estado), o que contrasta com a afirmação de "manter informações de estado".
Alternativa D — ❌ Incorreta
"portlet para que cada software possa converter os dados dos contribuintes para um formato XML padrão e validá-los com base na mesma lógica centralizada." Portlets são componentes de interface de usuário em portais web, não são adequados como serviços de backend para integração entre sistemas. A recomendação de um portlet para centralizar lógica de validação é incomum e não atende ao requisito de interoperabilidade entre sistemas heterogêneos.
Alternativa E — ✅ Correta ⟵ GABARITO
"web service para validar e incluir contribuintes, de forma que os demais softwares possam simplesmente consumir esse serviço de maneira adequada." Web services (sejam SOAP ou REST) são independentes de linguagem e plataforma, permitem reuso e baixo acoplamento. Cada software consumidor pode chamar o mesmo serviço, centralizando a lógica de validação e inclusão. É a solução mais alinhada com os princípios de SOA apresentados no contexto.
NÃO CAIA NESSA!
A banca explora a confusão entre tecnologias: misturar REST com SOAP, sugerir EJB para múltiplas linguagens, ou usar portlets para backend. A pegadinha principal está na alternativa C, que tenta combinar RESTful (stateless) com SOAP (protocolo) e afirma que mantém estado — tudo errado. Fique atento aos conceitos básicos de cada tecnologia.
PEGA ESSA DICA!
Em questões de integração de sistemas heterogêneos, a primeira alternativa a considerar é sempre um web service (ou uma API). Lembre-se: web services são caracterizados por interoperabilidade, reuso e baixo acoplamento. Sempre desconfie de alternativas que amarram a solução a uma linguagem específica ou que misturam padrões incompatíveis.