Uma instituição de ensino superior tem um sistema de re...

A alternativa correta para a questão apresentada é a E - publish/subscribe.

A arquitetura publish/subscribe é a mais apropriada para resolver a demanda citada na questão. Vamos entender por que isso acontece e discutir as outras alternativas oferecidas.

Publish/Subscribe é um padrão de arquitetura de software onde os sistemas que publicam informações (publishers) e os sistemas que desejam receber essas informações (subscribers) são desacoplados. Isso significa que um sistema pode enviar uma mensagem ou notificação sem precisar saber quem vai recebê-la, e vice-versa. No contexto da questão, quando o sistema de resultados escolares registra a conclusão de um curso, ele age como um publisher e envia uma mensagem de conclusão. Os sistemas de apoio à colocação profissional, pós-graduação e controle de egressos, que são subscribers, recebem essa notificação de forma assíncrona.

Agora, vejamos por que as outras alternativas não são adequadas:

A - Microsserviços: Embora a arquitetura de microsserviços ofereça modularidade e escalabilidade ao sistema, ela não resolve diretamente o problema de notificação assíncrona entre sistemas desacoplados. A comunicação entre microsserviços pode ser síncrona ou assíncrona, mas não é um requisito intrínseco da arquitetura.

B - Peer-to-Peer: A arquitetura peer-to-peer é usada principalmente para sistemas distribuídos onde todos os nós têm responsabilidades iguais e podem atuar tanto como clientes quanto como servidores. Não é adequada para o cenário de notificação de eventos entre sistemas corporativos, que requer uma abordagem mais centralizada e estruturada como a publish/subscribe.

C - Monolítica: A arquitetura monolítica centraliza todos os componentes de um sistema em uma única aplicação ou código base. Embora possa ser mais simples em termos de implementação inicial, não oferece a flexibilidade necessária para a notificação assíncrona entre diferentes sistemas desacoplados. A escala e manutenção seriam dificultadas nesse cenário.

D - MVC (Model-View-Controller): O padrão MVC é utilizado para organizar a estrutura interna de uma aplicação, separando as responsabilidades de modelagem de dados, visualização e controle. Ele não é adequado para resolver a comunicação e notificação entre diferentes sistemas independentes. É mais voltado para a organização interna de uma única aplicação.

Com isso, fica evidente que a alternativa E - publish/subscribe é a mais adequada para o cenário descrito na questão, uma vez que ela permite a notificação assíncrona e desacoplada entre os sistemas envolvidos, atendendo perfeitamente à demanda descrita.

Introduza um subsistema assíncrono de mensagens que inclua o seguinte:

Um canal de entrada de mensagens usado pelo remetente. O remetente insere os eventos nas mensagens, usando um formato de mensagem conhecido, e envia essas mensagens por meio do canal de entrada. O remetente nesse padrão também é chamado de publicador.

Um canal de saída de mensagens por consumidor. Os consumidores são conhecidos como assinantes.

Fonte: https://learn.microsoft.com/pt-br/azure/architecture/patterns/publisher-subscriber

GAB E)

Essa é a famosa arquitretura baseada em eventos. Quando se fala em notificação e assíncrona pense logo em:

1. Publish: faz o papel do produtor na mensagem no broker, ou seja, no tópico.
2. Subscribe: faz o papel do consumidor daquela mensagem.

Exemplos:

• Kafka
• RabbitMQ
• Apache Pulsar
• Amazon Kinesis
• Redis Streams
• Apache ActiveMQ
• Apache RocketMQ
• NATS Streaming
• IBM MQ
• Google Cloud Pub/Sub