Para isso, implementaremos todas as partes relevantes de uma arquitetura completa de integração, incluindo componentes que compõem a Arquitetura Orientada Serviços (SOA). Em seguida, complementaremos nosso estudo abordando algumas ferramentas que ajudam a conceber a EDA (Event Driven Architecture).
Portanto, este artigo é útil para profissionais envolvidos em ambientes nos quais há necessidade de comunicação entre os participantes (sistemas e componentes) que formam todo o conjunto de sistemas de software da empresa.
Uma das maneiras de tentar estabelecer uma comunicação organizada e controlada entre os componentes que formam o conjunto de sistemas de uma empresa/departamento seria utilizar a ocorrência de um fato, ou seja, um evento, pois desta forma teríamos a comunicação entre as partes mantida com um baixo acoplamento, onde emissores e assinantes estariam ligados apenas pela criação destes eventos.
Além dos eventos definirem o momento em que a integração pode ocorrer, possuem as informações necessárias que serão trocadas entre as peças, efetivando as integrações.
No acontecimento de um evento, ações podem ser tomadas pelos interessados sem a necessidade de qualquer tipo de atuação por parte do gerador do evento.
Mas dentro do nosso contexto de tecnologia: o que são estes eventos? A resposta é: depende! Apesar de a resposta parecer uma tentativa de ludibriar alguém que você gostaria de convencer, ela realmente depende do contexto envolvido, ou seja, do modelo do domínio de negócio que estamos nos referindo.
O evento é algo relevante para o negócio da empresa, podendo ser: a ocorrência de uma venda, o cadastro de um novo cliente, a desistência de uma assinatura de revista, saques em locais geograficamente distantes do mesmo correntista, ou o valor acumulado de pedidos realizados dentro de um período.
A definição do que pode ser considerado um evento está muito mais orientada ao negócio da empresa do que a decisões técnicas. É claro que é possível também estabelecer eventos de natureza técnica como, por exemplo: o tempo médio da execução de transações ou a quantidade de execuções de um serviço no mês.
Porém, na maioria dos cenários, ao estabelecer uma arquitetura orientada a eventos, a prioridade fica para a definição e captura de eventos do negócio em questão, para que a empresa tenha mais benefícios sobre o orçamento investido em tecnologia.
Os eventos de natureza técnica (como tempo de resposta) ganham maior prioridade quando afetam diretamente os negócios da empresa.
Em uma arquitetura orientada a eventos, colocamos obviamente como ator principal o evento, estabelecendo assim o elo que causará a integração entre os sistemas e componentes. Vale ressaltar ainda que um evento é autocontido, isto é, carrega consigo a informação de quando está preparado para ser disparado e quais informações deve conter.
O que de fato a Arquitetura Orientada a Eventos (EDA – Event Driven Architecture) deve promover é uma estrutura que possa estabelecer o alicerce de apoio à integração entre os sistemas e/ou componentes do ambiente – usufruindo da ocorrência de evento –, de forma que ainda se mantenha um baixo acoplamento entre os participantes.
Obviamente, assim como a definição de um modelo de domínio para a criação de uma aplicação, a modelagem de quais eventos serão tratados deve fazer parte da análise da solução.
Principalmente porque estes eventos serão utilizados por vários sistemas distintos da corporação, o que sugere colocá-los como parte do modelo canônico, junto com as entidades de negócio e mensagens comuns utilizadas pelos diferentes sistemas da empresa.
Dentro do ambiente de uma empresa com vários sistemas distintos, existem potenciais emissores e assinantes destes eventos. Neste cenário, os emissores de eventos possuem as informações e o contexto associado ao disparo, fazendo o evento existir de forma consistente e válida para consumo por todos os interessados.
A complexidade para a definição de uma estrutura que possa auxiliar o controle e organização entre emissores e assinantes de eventos, estabelecendo uma Arquitetura Orientada a Eventos, vai depender da maturidade de integração existente na empresa.
É nesse momento que a adoção e estabelecimento de uma Arquitetura Orientada a Serviços mostra suas vantagens. Ao temos um mediador responsável por tratar as integrações, que centraliza os serviços existentes no ambiente, criar uma arquitetura para eventos se torna mais fácil.
Pelo barramento de serviços podemos identificar os serviços expostos de sistemas que são potenciais emissores (origem de eventos), deixando a responsabilidade de gerenciamento dos eventos ao barramento de serviços. É possível até ir além.
Ao realizar o cruzamento de eventos de um ou mais sistemas, pode-se estabelecer a criação de eventos mais complexos, que são derivados do cruzamento de informações de outros, realizando o conceito de processamento de eventos complexos (CEP) – vide BOX 1.
Conceito que consiste na captura de informações no formato de eventos significativos que acontecem na organização. Possibilita a realização de ações em tempo real como, por exemplo, identificar possíveis fraudes em andamento durante transações financeiras.
Os eventos são identificados e disparados durante a análise da “corrente” (stream) de informações que trafega no barramento durante as execuções de serviços que ocorrem nas transações de negócio da empresa.
Neste cenário de integrações é fácil perceber a simplificação que se obtém possuindo um ambiente SOA bem organizado, pois o controle das integrações já deve existir.
O que falta é aproveitar a oportunidade deste fluxo de informações para identificar, criar e disparar eventos.
Por outro lado, em um ambiente onde as integrações entre sistemas não possuem um controle consistente e o desenho destas integrações é normalmente definido em salas de reuniões em que apenas duas partes estão presentes, aumenta a complexidade para estabelecer uma arquitetura orientada a eventos.
O descontrole sobre a integração acaba se espalhando, resultando em: eventos duplicados, eventos específicos por sistema, desconhecimento de assinantes e acoplamento mais alto entre as partes.
Na Figura 1 podemos analisar uma ilustração de como seria um ambiente previamente concebido estabelecendo uma arquitetura orientada a eventos sem nenhuma organização e controle sobre as integrações.
Figura 1. Integração entre sistemas utilizando eventos sem o apoio do barramento de serviços.
Observe que os eventos são emitidos diretamente entre os sistemas do ambiente por causa da falta de um mediador que tenha o conhecimento e controle de todos que necessitam se integrar no ambiente. Mesmo ainda sendo possível, o esforço será maior para estabelecer e gerenciar este cenário.
Já na Figura 2 podemos observar uma ilustração de uma Arquitetura Orientada a Eventos funcionando com o apoio de um barramento de serviços de uma arquitetura SOA. Neste cenário, o barramento é responsável por centralizar a emissão dos eventos do ambiente, realizando a inspeção do fluxo de informações que está trafegando durante a execução dos serviços expostos pelos sistemas.
Assim que identificado e criado um evento pelo barramento, os assinantes podem, em seguida, recebê-lo.
Figura 2. Integração entre sistemas utilizando eventos com o apoio de um barramento de serviços (SOA).
A forma como o barramento de serviços analisa os streams de informação, identifica e lança os eventos, é uma definição associada ao desenho da Arquitetura Orientada a Eventos.
Apesar de facilitar, não é obrigatório possuir já estabelecida uma arquitetura orientada a serviços para concretizar a arquitetura orientada a eventos.
As duas arquiteturas podem se complementar. Portanto, se o SOA já estiver presente, é possível evoluir sua arquitetura de integração de serviços para se beneficiar dos eventos.
Enfim, SOA e EDA podem coexistir, mas não é necessário possuir SOA para implantar EDA, e vice-versa.
A característica comum de um ambiente SOA é a existência de consumidores e provedores, ao passo que em EDA possuímos assinantes e emissores. Como um diferencial, na arquitetura EDA os emissores não sabem quem são os seus assinantes, viabilizando assim uma integração de acoplamento baixo.
Na implementação de uma Arquitetura Orientada a Eventos, uma das opções mais simples seria utilizar filas de mensagerias (normalmente disponíveis em ferramentas ESB), através de tópicos, colocando em ação o padrão de comunicação editor/assinante (publish/subscriber). A outra opção seria utilizar ferramentas especializadas no gerenciamento e tratamento de eventos, como o Esper, que iremos analisar em seguida no nosso cenário de exemplo.
Arquitetura Orientada a Eventos na prática
O nosso exemplo de Arquitetura Orientada a Eventos provém de um cenário simples de e-commerce, onde uma loja on-line fornece seus produtos. Apesar de ser um cenário simples de compras via internet, implementamos o fluxo de integração das informações desde o início do cenário transacional, passando pelo sistema de vendas, barramento de serviços, processamento de eventos, chegando até a visualização do monitoramento das atividades de negócio. Desta maneira, podemos ter uma melhor demonstração prática do papel dos eventos dentro desta arquitetura.
A visão lógica e completa da arquitetura implementada nesta solução pode ser observada na Figura 3.
Figura 3. Visão holística da arquitetura lógica da solução de vendas on-line.
Nesta solução temos os clientes realizando os pedidos no site da empresa ou com representantes de vendas via telefone, o que é ilustrado nos quadros número um e dois. As compras são registradas através do serviço Registar Pedido, que está exposto no Barramento de Serviços Corporativos (ESB) da empresa (vide quadro número três).
O barramento realiza o roteamento do request para o sistema atual, responsável na empresa por manusear e gerenciar as transações de vendas (vide quadro número quatro).
Até este momento observamos que não temos nada ...
