Tipi di sistemi intermedi

Come è già stato più volte ripetuto, una delle caratteristiche più importanti dell'event processing è l'astrazione, o separazione, della logica dell'event processing dalla logica applicativa, in modo tale che essa possa essere posizionata tra gli event producer e gli event consumer, invece di essere incorporata in essi; in questa sezione verrà presentata un'idea di rete di event processing contenente degli event processing agent con il preciso compito di implementare tale livello di astrazione.

La più semplice forma di event processing prende gli eventi dagli event producer e li distri- buisce agli event consumer. Ciò include spesso operazioni di ltraggio di eventi, poiché non tutti gli eventi sono rilevanti per un specico event consumer, oppure perché potrebbero esserci eventi

contenenti dati sensibili che un certo event consumer non è autorizzato a ricevere. Il ltraggio e l'instradamento sono garantiti dalla stessa infrastruttura che provvede alla distribuzione degli eventi, specialmente se tale infrastruttura ha capacità di publish/subscribe17_{. Accanto a queste}

semplici operazioni, l'elaborazione intermedia potrebbe includere la registrazione di eventi per scopi di verica. Filtraggio, instradamento e registrazione sono tutti esempi di event processing di tipo stateless.

Un event processing agent, quindi, si denisce stateless se il modo in cui elabora un evento non inuenza il modo in cui elaborerà ogni evento successivo [EN11].

Guardando a strutture più complesse, il processing intermedio potrebbe essere in grado di tradurre gli eventi, sia cambiando la loro rappresentazione sia aggiungendo informazioni, arric- chendoli quindi, oppure rimuovendone, operazione spesso identicata con il termine proiezione. Le tecniche qui elencate sono simili a quelle utilizzate per l'integrazione di applicazioni d'impresa e possono essere sviluppate usando approcci e strumenti simili.

Le operazioni di cui si è appena discusso prendono un evento in ingresso e restituiscono un evento in uscita, ma è anche possibile avere event processing agent che accettano in ingresso insiemi di eventi o creano uno o più eventi come output:

ˆ Un evento in ingresso può essere diviso in più eventi, ognuno contenente un sottoinsieme delle informazioni dell'evento originale.

ˆ Un usso di più eventi in ingresso può essere aggregato per produrre un usso di eventi derivati in output. Gli eventi derivati sono tipicamente il risultato di più eventi del usso di input: ad esempio, un evento di output può contenere il totale aggiornato di alcuni valori contenuti negli eventi di input.

ˆ Due ussi di eventi in ingresso possono essere accorpati per produrre un unico usso di eventi derivati in uscita.

Come si può facilmente capire, in questi esempi è stato introdotto un nuovo concetto, quello di usso di eventi.

Un usso di eventi si denisce come un insieme di eventi associati. Esso risulta essere spesso un insieme totalmente ordinato a livello temporale, il che signica che esiste un ordinamento basato su timestamp ben deniti. Un usso in cui tutti gli eventi appartengono alla stessa tipologia si denisce usso omogeneo di eventi; al contrario, un usso in cui gli eventi sono di tipi diversi viene denito usso eterogeneo di eventi [EN11].

I ussi di eventi possono essere un utile strumento per pensare e modellare un'applicazione di event processing. Alcuni sistemi di event processing fanno dei ussi la loro massima forma di astrazione: risulta, infatti, più naturale pensare ad un event processing agent come operante su un intero usso di eventi, piuttosto che su un singolo evento alla volta. Il concetto di usso è particolarmente utile in applicazioni che coinvolgono serie temporali di eventi, come la lettura periodica di un sensore.

17_{L'espressione publish/subscribe si riferisce a un design pattern, o stile architetturale, utilizzato per la}

Agent che aggregano o compongono ussi di eventi fanno event processing di tipo stateful. Perciò, un event processing agent è detto stateful se il modo in cui elabora eventi è inuenzato da più di un evento in input [EN11].

Come esempio, si supponga di avere un'applicazione che riceve un evento ogniqualvolta una certa quantità di un dato prodotto viene venduta, e si è interessati a sapere la quantità totale che è stata venduta. E' possibile usare un event processing agent per calcolare il totale corrente. Ogni volta che si riceve un evento di acquisto, l'agent emette un nuovo evento contenente il totale aggiornato.

Questo incontra la denizione precedente di event processing agent di tipo stateful, dato che ogni evento emesso da un agent dipende da tutti gli altri eventi prima ricevuti. Si noti che un agent stateful non emette necessariamente un evento derivato ogni volta che riceve un evento in input. Si supponga, ad esempio, che il volume di acquisto sia elevato. Si potrebbe decidere di non emettere un evento quando un ordine di acquisto viene completato, ma di emetterne uno al raggiungimento di una certa soglia di volume di prodotto venduta o, al raggiungimento di un certo numero di ordini di acquisto. Si potrebbe, inoltre, essere interessati a calcolare una media corrente degli ultimi dieci o cento ordini di acquisto in termini di merce venduta. Per permettere ciò, gli agent di tipo stateful devono operare solo su un sottoinsieme ridotto di tutti gli ordini di acquisto, spesso identicato dal termine nestra [EN11].