22
Event Driven Architecture & Complex Event Processing António Cruz, Software Architect

Event Driven Architecture & Complex Event Processing

  • Upload
    logus2k

  • View
    1.577

  • Download
    0

Embed Size (px)

DESCRIPTION

Presented to The Portuguese Group of Software Architects in 2009-04-14

Citation preview

Page 1: Event Driven Architecture & Complex Event Processing

Event Driven Architecture &Complex Event Processing

António Cruz, Software Architect

Page 2: Event Driven Architecture & Complex Event Processing

Agenda

• Orientação a Serviços• Orientação a Eventos• Benefícios e Problemas• Casos de Estudo• Conclusões

Page 3: Event Driven Architecture & Complex Event Processing

Orientação a Serviços

Page 4: Event Driven Architecture & Complex Event Processing

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

Page 5: Event Driven Architecture & Complex Event Processing

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

Page 6: Event Driven Architecture & Complex Event Processing

Orientação a Eventos

Page 7: Event Driven Architecture & Complex Event Processing

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€.

Page 8: Event Driven Architecture & Complex Event Processing

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

Page 9: Event Driven Architecture & Complex Event Processing

Publish-Subscribe

Tópico

Produtor

Consumidor

Mensagem A

Produtor

Mensagem B

Consumidor

Mensagem B

Mensagem A

Mensagem B

Mensagem A

Page 10: Event Driven Architecture & Complex Event Processing

Ponto-a-Ponto

Queue

Produtor

Consumidor

Mensagem A

Produtor

Mensagem B

Consumidor

Mensagem A Mensagem B

Page 11: Event Driven Architecture & Complex Event Processing

DEMOConsumo de Tópicos de Eventos

Page 12: Event Driven Architecture & Complex Event Processing

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)

Page 13: Event Driven Architecture & Complex Event Processing

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

Page 14: Event Driven Architecture & Complex Event Processing

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

Page 15: Event Driven Architecture & Complex Event Processing

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

Page 16: Event Driven Architecture & Complex Event Processing

#3 - Notificação de Ponto de Encomenda

Page 17: Event Driven Architecture & Complex Event Processing

EDA complementa SOA

Page 18: Event Driven Architecture & Complex Event Processing

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

Page 19: Event Driven Architecture & Complex Event Processing

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.

Page 20: Event Driven Architecture & Complex Event Processing

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

Page 21: Event Driven Architecture & Complex Event Processing

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

Page 22: Event Driven Architecture & Complex Event Processing

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