Event Driven Architecture (Parte 2)

Olá pessoal!

No post anterior vimos alguns conceitos de Event-Driven Architecture e como seria sua arquitetura de referência. Neste veremos as possíveis realizações de tal arquitetura de referência e também iremos conferir alguns princípios que devem ser levados em consideração ao se fazer o design deste tipo de arquitetura.

Vamos começar então pelas possíveis utilizações de uma Event-Driven Architecture. No livro Event Processing: Designing IT Systems for Agile Companies são relacionadas três principais cenários: Disseminação de Informação, Conhecimento de Situação e Integração de Aplicações. Cada possível utilização demanda uma forma distinta de implementação da arquitetura de referência vista. Vejamos cada uma delas a seguir.

Event-Driven Architecture para Disseminação de Informação

Disseminação de Informação

Quando o objetivo é apenas disseminar informações, visando manter consistência de dados entre diferentes aplicações, normalmente não há necessidade de utilização de um intermediário, de forma que apenas canais sejam suficientes. Isso por que para disseminar uma informação, em geral, não é necessário modificar o dado da origem antes que ele chegue ao seu destino.

Sob o ponto de vista físico, um canal pode ser, por exemplo, um servidor de mensagens, que recebe a denominação de Message Oriented Middleware (MOM). Um MOM funciona como um hub, onde mensagens são retransmitidas de um computador ou componente de software para outro. Os produtos Microsoft Message Queue, IBM MQ Series e similares de outros fornecedores são exemplos de produtos que seguem o conceito de middleware orientado a mensageria (MOM).

Exemplos de implementação com este objetivo incluem feeds RSS, e feeds de dados financeiros em mercados de capital aberto. Neste último caso o padrão publish-and-subscribe se encaixa perfeitamente, de forma que um produtor de informação possa fazer uma publicação apenas uma vez e uma cópia da informação possa ser entregue a milhares de consumidores. Veja como seria a arquitetura descrita no diagrama ao lado (direito).

Conhecimento de Situação

Já quando o objetivo é proporcionar conhecimento de situação, usualmente eventos de diferentes fontes são coletados, analisados para que então uma nova notificação seja gerada para um ou mais consumidores. Este cenário caracteriza o que é conhecido como processamento de eventos complexos (Complex Event Processing – CEP). Uma arquitetura que endereça este tipo de necessidade normalmente é composta de múltiplos cansais e ao menos um intermediário do tipo gerador de eventos (descrito no post anterior).

Event-Driven Architecture para Conhecimento de Situação

Sob o ponto de vista físico, intermediários de alto nível podem ser, por exemplo, um Enterprise Service Bus (ESB), um broker de integração, um motor de orquestração de processos, um agente de processamento de eventos complexos, uma aplicação customizada que faça o papel de uma das anteriores, ou uma combinação delas. Veja no diagrama ao lado (esquerdo), como se daria a realização de tal arquitetura, considerando o emprego de um Enterprise Service Bus como intermediário.

Integração de Aplicações

Quando o assunto é integração de aplicações, é sempre interessante considerar abordagens que proporcionem o mínimo de acoplamento entre as aplicações envolvidas. Uma arquitetura orientada a eventos proporciona tal desacoplamento através do emprego dos canais e intermediários vistos até então, que permitem que produtores sejam alterados sem que necessariamente consumidores sejam afetados, e vice-versa.

Agora que já entendemos as principais utilizações de uma arquitetura orientada a eventos, vamos aos princípios que você não pode deixar de lembrar ao estabelecer tal arquitetura.

Princípios de uma Arquitetura Orientada a Eventos

  • Reporta Eventos Correntes (Reports Current Events): Uma notificação sempre deve reportar uma ocorrência discreta uma vez que ela tenha ocorrido. Por exemplo, quando um leitor RFID detecta a presença de um tag RFID, ele envia uma mensagem de notificação que reporta tal evento. É importante considerar que não necessariamente é preciso transmitir notificações de forma independente, como por exemplo, uma requisição a um canal realizado como um web service para cada notificação gerada. É sempre importante avaliar o trade-off entre a latência na produção e atualização da informação contra o overhead do envio de cada ocorrência de forma independente. Em algumas situações você pode querer abrir mão da atualização da informação “just-in-time” por uma maior otimização da utilização de recursos de rede / banda, agrupando um conjunto de eventos para envio de uma só vez.
  • Envia Notificações (Pushes Notification): As notificações devem ser enviadas do produtor ao consumidor e não o contrário. O produtor deve decidir quando enviar a notificação, uma vez que ele sabe do evento antes do consumidor. É importante notar, porém, que a implementação física deste conceito pode variar. Um produtor sempre enviará o evento a um canal (fará um push do evento no canal). Já o canal poderá fazer um push da notificação ao consumidor ou o consumidor poderá fazer um poll no canal, em uma freqüência de tempo determinada pelo consumidor.
  • Responde imediatamente (Responds Immediately): O consumidor sempre deve fazer algo imediatamente após o reconhecimento do evento. Esse “fazer algo” pode significar avaliar e descartar o evento, caso este não seja aplicável ao seu domínio, ou ainda fazer cálculos, descartar a mensagem e salvar o objeto de evento para utilizações futuras, quando outras notificações chegarem, possibilitando fazer correlações entre os eventos recebidos, desta forma caracterizando um CEP (Complex Event Processing).
  • Comunica-se apenas em uma direção (Communicates On-Way): As notificações em uma arquitetura orientada a eventos seguem o estilo “fire-and-forget”, onde o produtor envia a notificação e logo em seguida fica livre para fazer outro trabalho, sem ter que aguardar o processamento / endereçamento de tal notificação pelo seu consumidor. Ou seja, o produtor envia uma notificação, porém, não aguarda uma resposta do consumidor. Neste contexto, geralmente surgem preocupações quanto à integridade da informação, no sentido de garantir que a informação chegue ao destinatário corretamente. Tal preocupação, porém, pode ser delegada ao canal onde a mensagem é colocada pelo provedor, de forma que o provedor apenas se responsabilize por garantir que a informação tenha chegado ao canal corretamente (este retorna um acknowledge informando o recebimento) e que tal canal implemente um mecanismo de garantia de entrega conhecido como reliable delivery ou guaranteed delivery.
  • É livre de comandos (Is free of commands): Uma notificação é um reporte que informa a ocorrência de um evento. Ela não deve prescrever a ação que o consumidor do evento deve tomar. Tal princípio tem como objetivo garantir o acoplamento mínimo entre provedor e consumidor de eventos, já que se o provedor prescrevesse o que o consumidor deveria fazer com a informação, ele seria impactado diretamente por mudanças em requisitos ou regras de negócios que afetem tais ações no provedor. No nível físico, um produtor de eventos apenas se comunica com o canal, de forma a emitir comandos como “abra o canal”, “envie a mensagem”, “feche o canal”, enquanto que o consumidor usa comandos semelhantes, como por exemplo, “leia o canal (poll)”, ou “abra / obtenha a mensagem” e “feche o canal”. Note que tais comandos acoplam provedor e consumidor de mensagens ao canal apenas, mas não um ao outro diretamente.

E assim ficamos por aqui. Até a próxima!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*