Event Driven Architecture &Complex Event Processing
António Cruz, Software Architect
Agenda
• Orientação a Serviços• Orientação a Eventos• Benefícios e Problemas• Casos de Estudo• Conclusões
Orientação a Serviços
Benefícios
• Agilidade e flexibilidade dos processos de negócio através da composição de unidades funcionais reutilizáveis e interoperáveis, taxonomizadas num catálogo pesquisável
• Contribui para reduzir os custos, minimizar a redundância, optimizar a segurança, melhorar a satisfação dos clientes, etc.
• Pode revelar-se uma vantagem estratégica
Problemas
• O padrão de Request-Reply não é adequado a cenários que requerem:– Informação em tempo real– Transmissão de centenas de milhar ou milhões de
notificações por segundo– Que os produtores desconheçam os consumidores
Orientação a Eventos
Orientação a Eventos
• Um evento é uma alteração significativa de estado para o negócio:– Passagem do minuto 49 para o minuto 50– Bilhete que passa de Disponível para Vendido– Compra a Crédito cujo valor ultrapassa 1500€.
Orientação a Eventos
• Características:– Foca no comportamento dos processos de negócio– Ajusta-se à natureza de muitos aspectos do mundo
real– Baseia-se no padrão pub-sub: os eventos são
propagados– A comunicação é assíncrona– A granularidade dos eventos é fina
Publish-Subscribe
Tópico
Produtor
Consumidor
Mensagem A
Produtor
Mensagem B
Consumidor
Mensagem B
Mensagem A
Mensagem B
Mensagem A
Ponto-a-Ponto
Queue
Produtor
Consumidor
Mensagem A
Produtor
Mensagem B
Consumidor
Mensagem A Mensagem B
DEMOConsumo de Tópicos de Eventos
Estilos de Processamento de Eventos
• São normalmente usados em conjunto:– Simple Event Processing (um evento notável)– Stream Event Processing (vários eventos, notáveis e
ordinários)– CEP - Complex Event Processing (são feitas
correlações entre vários eventos notáveis e ordinários, em diferentes alturas no tempo e pontos do sistema, com vista à identificação de padrões que por sua vez vão gerar novos eventos)
Benefícios
• Extreme decoupling - os produtores não precisam de conhecer os consumidores e vice-versa
• Escalabilidade – A paralelização das entregas apresenta geralmente maior desempenho do que a arquitectura síncrona baseada no pedido-resposta
Problemas
• As mensagens podem não ser entregues ou não serem entregues na mesma ordem em que foram publicadas
• A extreme decoupling pode trazer problemas à SOA governance– O padrão pub-sub só por si não pressupôe a implementação
de mecanismos de segurança– É difícil fazer tracing das mensagens
• Podemos perder a escalabilidade em instalações com milhares de agentes
• Requer a instalação e uso de middleware específico
Event-Driven SOA
• A ocorrência de um evento pode despoletar a invocação de um ou mais serviços– Os eventos despoletam serviços
• Esses serviços podem desempenhar funções de negócio simples ou processos de negócio complexos
• A invocação dos serviços pode provocar a ocorrência de novos eventos– Os serviços despoletam eventos
#3 - Notificação de Ponto de Encomenda
EDA complementa SOA
CEP - Complex Event Processing• Um evento complexo é o resultado de uma inferência
sobre uma agregação de outros eventos• Os membros podem ocorrer em alturas distintas e em
componentes diferentes do sistema:– Detecção de uma tentativa de intrusão na rede– Decisão de encaminhamento de uma mensagem com base no
conteúdo de mensagens anteriores– Transportes, RFIDs e BAM são áreas emergentes– Poupança de energia (edifícios com sensores, etc.)
• Pode ser usado para evitar a recepção de múltiplas mensagens
Práticas Recomendadas
• Identificar bem as necessidades do negócio e um projecto-piloto com valor, mas que não seja crítico
• Perseguir sempre o Time-to-Value. Não basta dizer “trust me”, é preciso mostrar resultados
• Evitar “ter uma ou várias soluções à procura de um problema”• Elaborar schemas para todas as transferências de dados:
serviços, mensagens de notificação, transferências de dados, etc.
• Suportar o versionamento das mensagens– Uma alternativa é criar um novo tópico de subscrição
• Comunicar. Formar. Delegar. Cooperar.
Conclusões (I)• As notificações assíncronas de eventos não são
um substituto para as comunicações síncronas baseadas em pedidos-respostas
• SOA e EDA (aka “Advanced SOA”) são formas complementares de desenho da arquitectura que possibilita que a empresa tenha maior agilidade face à mudança constante de estados do negócio
Conclusões (II)
• SOA não é um produto nem uma questão essencialmente técnica. É algo que nós fazemos, é um estilo de desenho
• O middleware (ex. ESB) é apenas uma ferramenta para um fim e não o fim em si mesmo
• Em conjunto, a Orientação a Serviços e Eventos viabilizam empresas em tempo-real e são a fundação para o context-aware computing
Referências
• SOA Design Patterns – Thomas Erl• The Power Of Events – David Luckam• The Architecture Journal #17• Sapo Bus – codeplex.com/SapoBus• Sapo Broker – softwarelivre.sapo.pt/broker• MS PubSub – www.codeplex.com/PubSub