Em um Tribunal de Justiça, uma arquitetura de integração deve atender simultaneamente a: consultas sob demanda a autos
digitais, distribuição de mudanças de andamento processual a múltiplos consumidores independentes e padronização dos
contratos de integração. A solução deve permitir evolução independente entre produtores e consumidores, sem expor estruturas
internas de persistência. Nesse contexto, a abordagem adequada é

Question

Em um Tribunal de Justiça, uma arquitetura de integração deve atender simultaneamente a: consultas sob demanda a autos
digitais, distribuição de mudanças de andamento processual a múltiplos consumidores independentes e padronização dos
contratos de integração. A solução deve permitir evolução independente entre produtores e consumidores, sem expor estruturas
internas de persistência. Nesse contexto, a abordagem adequada é Alternativa A: expor o histórico interno de alterações do sistema processual como contrato público de integração, usando-o como API principal para consumidores externos. Ou Alternativa B: definir contratos OpenAPI para consultas síncronas e contratos AsyncAPI para eventos assíncronos de domínio, usando envelope padronizado, como CloudEvents. Ou Alternativa C: substituir as APIs de consulta por webhooks documentados na OpenAPI usando CloudEvents, uniformizando consultas e
notificações como chamadas HTTP iniciadas pelo Tribunal. Ou Alternativa D: representar alterações de andamento processual como recursos REST consultados pelos consumidores usando
CloudEvents, evitando infraestrutura de mensageria. Ou Alternativa E: documentar notificações assíncronas por callbacks OpenAPI e contratos SyncAPI associados às operações que possam alterar autos digitais.

Qconcursos · Accepted Answer

Alternativa [B] definir contratos OpenAPI para consultas síncronas e contratos AsyncAPI para eventos assíncronos de domínio, usando envelope padronizado, como CloudEvents. Gabarito: BFundamento decisivo: A decisão dependia de distinguir consulta sob demanda de distribuição assíncrona de mudanças, com contratos separados para cada tipo de interação, sem expor a persistência interna.Tema central: Contratos síncronos e assíncronosAnálise das alternativasAErradaEstá errada porque transforma o histórico interno de alterações do sistema em contrato público de integração. Isso contraria diretamente o requisito de não expor estruturas internas e compromete a evolução independente entre produtor e consumidores.BCertaA alternativa B é a única que combina consultas síncronas via OpenAPI, eventos assíncronos de domínio via AsyncAPI e envelope padronizado como CloudEvents. Essa combinação atende ao desacoplamento e à evolução independente entre produtores e consumidores, sem transformar estrutura interna de persistência em contrato público.CErradaEstá errada porque substitui APIs de consulta por webhooks. Webhook é mecanismo de notificação push iniciado pelo produtor e não atende, por si, à necessidade de consulta sob demanda iniciada pelo consumidor.DErradaEstá errada porque trata alterações de andamento como recursos REST a serem consultados pelos consumidores. Isso troca a disseminação assíncrona de mudanças para múltiplos consumidores por consulta/polling de recursos, o que não corresponde ao requisito arquitetural descrito.EErradaEstá errada porque não estrutura corretamente o componente assíncrono com uma especificação própria para eventos, como faz a AsyncAPI, e ainda introduz a nomenclatura 'SyncAPI', inadequada no contexto citado na base. Por isso, a alternativa não faz a separação contratual correta entre interação síncrona e assíncrona.Pegadinha da questãoA confusão real era trocar consulta sob demanda por mecanismo de notificação, além de tratar CloudEvents como substituto de API ou aceitar exposição de histórico interno como se fosse contrato externo adequado.Dica para questões semelhantesSe o requisito fala em consulta sob demanda, procure interface síncrona de API, não webhook ou callback.Se o requisito fala em distribuição de mudanças para múltiplos consumidores independentes, procure eventos assíncronos de domínio com contrato próprio.Use CloudEvents como padronização do envelope de eventos, não como substituto de API de consulta.Elimine alternativas que exponham histórico interno, log de alterações ou persistência como contrato público de integração.

🎯 Saiba o que estudar

🎯 Saiba o que estudar

Em um Tribunal de Justiça, uma arquitetura de integração dev...

Gabarito comentado

Gabarito: B

Clique para visualizar este gabarito

Comentários

Clique para visualizar este comentário

Questões de assuntos semelhantes

Provas relacionadas