Modellazione di reti di event processing

Figura 3.4: Building blocks, elementi descrittivi di rete, istanze runtime e loro correlazione Per la modellazione di una rete di event processing si utilizzerà il linguaggio proposto dal libro, già più volte citato durante questa trattazione, Event Processing in Action di Eztion e

Niblett, grazie al quale è possibile descrivere una EPN come un insieme di elementi platform- independent[EN11]. Ogni elemento è un'istanza di uno dei sette building blocks base. Fino ad ora sono stati introdotti event processing agent, event producer, event consumer e canali di eventi; tutti questi sono da considerarsi building blocks del linguaggio di modellazione. L'a- strazione dei building blocks permette di concentrarsi sulle caratteristiche realmente importanti dell'applicazione, e non sui dettagli implementativi.

Un building block rappresenta un concetto di event processing ed è usato per rappresen- tare elementi platform-independent descrittivi della rete, i quali sono istanze non dipendenti dall'implementazione dello stesso building block. Quando un'applicazione viene sviluppata, gli elementi descrittivi della rete devono essere tradotti in uno o più artefatti platform-specic, vale a dire utilizzabili solo da una particolare piattaforma codicata tramite un particolare linguaggio di programmazione, usando gli strumenti messi a disposizione da essa. Una volta completata, l'applicazione sarà eseguita e verranno prodotte le istanza runtime di questi artefatti platform- specic. La Figura 3.4 mostra la relazione tra building blocks, elementi descrittivi della rete e istanze a runtime [EN11].

Nonostante esistano diverse tipologie di building blocks, esse hanno tutte una struttura simi- le. Ogni building block ha un nome, e questo determina il tipo di elementi descrittivi platform- independent che descrive. Inoltre, possiede un'icona che può essere usata per rappresentare questi elementi in rappresentazioni grache.

Per poter creare un elemento descrittivo a partire da un building block, è necessario fornire alcune informazioni. Il building block descrive quali informazioni bisogna fornire, come ad esempio i terminali di input e quelli di output, lo schema di instradamento o, anche, asserzioni sulla qualità del servizio nel caso si tratti di canali.

Questi building block forniscono i componenti essenziali, che messi insieme possono dar vita ad applicazioni event-driven. Come già anticipato, esistono sette tipi di building block ed è possibile vederli tutti in Figura 3.5 [EN11]. Alcuni di questi contengono riferimenti ad altri; queste relazioni sono identicate dalle frecce entranti e uscenti dai vari blocchi.

Ogni applicazione event-driven richiede uno o più tipi di evento e, come il nome suggerisce, il building block event type permette di descrivere tali tipi di eventi. Questo building block denisce la struttura di un evento, a volte anche detto schema di un evento, assieme ad un po' della sua semantica.

I building block event producer e event consumer sono utilizzati per rappresentare i concetti già associati a questi nomi precedentemente. Il primo denisce un'entità che genera eventi e li immette all'interno della EPN, mentre il secondo ragura un'entità che li riceve. Questi building blocks modellano solo quei bit relativi al comportamento dell'event producer e dell'event consumer che sono visibili agli altri componenti di una rete di event processing. Perciò il building block event producer non specica come un'istanza di event producer generi un evento, e il building block event consumer non specica quali azione compie un'istanza di event consumer quando riceve un evento.

L'elemento descrittivo di rete event producer o event consumer può rappresentare sia una singola istanza di produttore o consumatore di eventi, sia un'intera classe di tali istanze. In

Figura 3.5: I sette tipi fondamentali di building block

alcune applicazioni potrebbe bastare una sola istanza di event producer, come nel caso in cui il produttore di eventi sia un rewall che invia messaggi di allerta; in altri casi ci potrebbero essere più istanze, per esempio nel caso di rilevatori di fumo all'interno di un edicio.

Un elemento di tipo context riunisce un insieme di condizioni di varie tipologie (temporali, spaziali, segmentation-oriented e state-oriented), dando così la possibilità di dividere in categorie le istanze dei vari eventi e poterle più facilmente instradare verso le istanze di agent appropriate. Per esempio, è possibile utilizzare un context di tipo segmentation-oriented per far sì gli eventi relativi a diversi clienti vengano gestiti da diverse istanze di un event processing agent.

Un elemento di tipo global state si riferisce ai dati che sono disponibili per l'uso sia agli event processing agent sia ai vari elementi di contesto. Questi dati possono essere paragonati a variabili globali di sistema, usate per arricchire eventi vecchi e nuovi.

Le due tipologie di building block rimaste, event processing agent e event channel, richiedono una trattazione più articolata per via della loro complessità. Per questo motivo sono state volutamente tralasciate no a questo momento, nonostante i concetti da loro espressi siano già stati esposti nell'arco della trattazione precedente.

Il building block event processing agent rappresenta un pezzo di logica intermedia di event processing posta tra gli event producer e gli event consumer. Esistono molti tipi di event processing agent, e per questo esistono molte varianti di building block event processing agent, come si può vedere in Figura 3.6 [EN11]. Essa mostra la gerarchia di ereditarietà che esiste tra i vari EPA. Filtraggio, trasformazione, e rilevazione di schemi sono tutte specializzazioni degli event processing agent:

ˆ Agent di ltraggio - Sono usati per eliminare eventi non interessanti dal punto di vista degli event consumer. L'agent di ltraggio prende un oggetto evento in ingresso e applica

Figura 3.6: I diversi utilizzi di un event processing agent

un test per decidere se scartarlo o se inoltrarlo ad un agent seguente. Il test solitamente è stateless, in altre parole si basa solamente sul contenuto dell'istanza dell'evento. Un esempio potrebbe essere un test che scarta gli eventi in relazione a transazioni con un valore superiore a 100¿.

ˆ Agent di rilevazione di schemi - Questi accettano in ingresso insiemi di oggetti evento e li esaminano per vedere se è possibile riconoscere il vericarsi di un particolare schema. Per esempio, si può utilizzare un agent di rilevazione di schemi per scartare gli eventi relativi al primo caso di due logon consecutivi falliti, ma passare tutti i successivi. Questi agent possono generare eventi derivati che descrivono lo schema che hanno rilevato invece di passarlo assieme agli oggetti evento in ingresso.

ˆ Agent di trasformazione - Questi agent modicano il contenuto degli oggetti evento che ricevono.

Gli agent di trasformazione possono essere ulteriormente classicati basandosi sulla cardinalità dei loro ingressi e delle loro uscite:

ˆ Agent di traduzione - Essi prendono ogni oggetto evento in ingresso e operano su di esso, indipendentemente dagli eventi precedenti o successivi. Essi forniscono un'operazione di tipo single event in - single event out.

ˆ Agent di split - Gli agent di split prendono un singolo evento in ingresso e generano un usso di più oggetti in uscita, fornendo così un'operazione di tipo single event in - multiple event out.

ˆ Agent di aggregazione - Con questi agent un usso di oggetti evento in ingresso produce un evento di output che è funzione degli eventi in ingresso. In questo modo viene fornita un'operazione di tipo multiple event in - single event out.

ˆ Agent di composizione - Gli agent di composizione prendono due ussi di oggetti evento in ingresso per combinarli in un unico usso. Questa operazione è simile a quella di join dell'algebra relazionale, tranne per il fatto che tale operazione avviene su ussi di dati, invece che su tabelle di dati.

Due particolari tipi di traduzione appaiono abbastanza frequentemente per far sì che ad essi venga assegnato il proprio building block. Essi sono l'agent di arricchimento, il quale arricchi- sce, appunto, un evento oggetto con informazioni aggiuntive, come ad esempio, l'indirizzo di un cliente derivato dall'identicativo dello stesso presente nell'evento in ingresso, e l'agent di proiezione, il cui compito è quello di cancellare informazioni dall'evento in ingresso.

Figura 3.7: Esempio di un canale di eventi esplicitamente modellato

E' facile notare che queste descrizioni si riferiscono ad eventi in ingresso e si è spesso parlato di passare eventi ad agent successivi per ulteriori elaborazioni. Tutto ciò porta naturalmente a chiedersi come i vari event processing agent sono connessi tra di loro per formare applicazioni.

Il compito principale di un building block di tipo event channel è di guidare gli eventi nel percorso dagli event producer agli event consumer. Esso può essere lasciato in forma implicita, identicata da una semplice linea retta continua, quando il suo compito non è altro che quello di collegare un terminale di output con un terminale di input, ma può anche essere esplicitato tramite un componente a forma esagonale, così come è rappresentato in Figura 3.7, nel caso in

cui esso vada a migliorare l'architettura generale della rete, in termini di prestazioni, oppure nel caso in cui il canale richieda una particolare operazione al suo interno, quale ad esempio un'operazione di ltraggio [EN11].

In Figura 3.7 l'implementazione esplicita del canale si è resa necessaria per evitare di dover modellare molti più canali con capacità di relazione uno-a-uno. In questo modo è stata snellita la rappresentazione graca della rete di event processing. Inoltre, nel caso in cui venga succes- sivamente aggiunto un altro event consumer o event producer, l'implementazione esplicita del canale permette di aggiornare la complessità del diagramma di event processing in maniera mol- to semplice, aggiungendo banalmente un collegamento tra la nuova entità e il canale; la stessa operazione eettuata su una rete con canali impliciti sarebbe costata molto di più, poiché si sarebbero dovuti aggiungere n canali, dove n è il numero di event consumer presenti, nel caso in cui venga creato un event producer o m canali, dove m è il numero di event producer presenti, nel caso in cui sia stato creato un event consumer.