Esper

Fra i numerosi sistemi sviluppati si è deciso di proporre al progetto BRIDGe una soluzione che adottasse Esper. La decisione è stata influenzata da due aspetti: innanzitutto lo scopo della tesi e poi le valutazioni attribuite al software da altri studiosi che lo hanno scelto per lavorare in situazioni analoghe.

La tesi presente si prefigge di identificare degli indicatori quantitativi per la caratterizzazione del comportamento abitudinario di una persona monitorata: questo obbiettivo rende Esper uno strumento adatto. Un indicatore, una volta formulato a livello teorico ed adeguatamente progettato, non è altro che un‟interrogazione EPL: esso applica operazioni logiche, algebriche o quantitative su un insieme di dati selezionati ed aggiornati in tempo reale. In questo modo Esper ed EPL permettono di costruire un sistema che, in base agli eventi verificati in un flusso in ingresso, genera degli eventi complessi che rappresentino tali indicatori implementando le operazioni precedenti in maniera flessibile, senza significative limitazioni, né dal punto di vista modellistico/architetturale, né dal punto di vista implementativo (essendo basato su Java). Per quanto concerne le esperienze di altri studiosi o ricercatori che hanno adottato questo strumento, Dekkers et al. [34] riconosce ad Esper un grado di maturità maggiore rispetto agli altri motori perché questo presenta un buon livello di integrazione fra l‟elaborazione di flussi di eventi e quella degli eventi complessi. Inoltre gli autori si soffermano su una valutazione positiva sia del linguaggio EPL definito breve ed intuitivo sia delle performance che questo può raggiungere anche su dispositivi non di ultima generazione. Secondo Romero et al. [69] Esper viene scelto rispetto ad altri strumenti perché definito stabile, efficace e semplice da utilizzare per la gestione di eventi e per prendere decisioni. Foley [41] preferisce Esper per la sua estesa documentazione e la garanzia di supporto offerta dalla vasta comunità online.

42 Materiali e metodi

3.1.3.1 La sintassi EPL

Come è stato affermato precedentemente Esper è una soluzione software integrata in Java che, adottata dalla tesi presente, permette di impiegare il linguaggio EPL allo scopo di operare in tempo reale sugli eventi in ingresso al sistema per costruire eventi complessi che rappresentino gli indicatori ricercati per descrivere la routine della persona monitorata. In questa sezione viene illustrata la sintassi del linguaggio EPL e come essa operi sugli eventi selezionati attraverso la costruzione di interrogazioni.

La struttura sintattica di EPL presenta una forte somiglianza con SQL, esso è costruito utilizzando una serie di clausole, molte delle quali con lo stesso funzionamento:

[insert into insert_into_def] select select_list

from stream_def [as name] [, stream_def [as name]] [, …] [where search_conditions] [group by grouping_expression_list] [having grouping_search_conditions] [output output_specification] [order by order_by_expression_list] [limit num_rows]

Come per SQL, in EPL le uniche due clausole obbligatorie per una regola sono ―select‖ e

―from‖, poiché estraggono un‟informazione e ritornano il dato voluto. Le restanti

clausole sono tutte facoltative, tra queste ―output‖ e “limit‖ entrambe per la gestione dei risultati. La clausola ―output‖ viene impiegata per il controllo della frequenza con cui sono restituiti i risultati; a questo scopo la condizione output_specification può impiegare la sintassi seguente:

output_specification: [all|first|last|snapshot] every output_rate [seconds|events]

Così sono restituiti tutti, il primo oppure l‟ultimo dei risultati calcolati per ogni secondo di analisi oppure per ogni evento. La clausola ―limit‖ viene utilizzata per limitare con

3.1 Event Processing 43 Una differenza netta rispetto a SQL è la possibilità di introdurre nella clausola ―from‖ una sintassi che permetta l‟estrazione di un pattern (una singola sequenza di eventi) verificando che questo soddisfi condizioni di ricerca e di interazione fra di essi.

from pattern

[[every|every_distinct|until] stream_def [as name] (search

conditions)

[[and|or|not|followed_by] stream_def [as name] (search

conditions)[…]]

[where [timer:within|timer:withinmax](timer_rate)]]

Per individuare pattern si possono usare diversi operatori. ―Every‖ è un‟istruzione per attivare l‟estrazione ogni volta che un pattern verifica una condizione specificata. Fra le condizioni vi sono anche gli operatori logici and, or, not e temporali followed by (->) impiegati per verificare relazioni fra pattern. Vi è infine la possibilità di controllare le sottoespressioni impiegando le condizioni temporali timer:within o timer:withinmax, interne alla clausola ―from‖ in un‟apposita ―where‖ che vincoli temporalmente l‟esecuzione dell‟analisi.

3.1.3.2 Le finestre

Esper permette di applicare delle finestre sui flussi di dati per eseguire analisi sugli eventi. Questa soluzione può agire su come venga valutata l‟interrogazione in questo modo:

 Con l‟opzione length(size) viene fissato dall‟utente il numero massimo di eventi che possono essere considerati contemporaneamente dal flusso per l‟analisi.

 time(time_period) indica, invece, il tempo che la finestra mantiene gli eventi giunti al sistema. Questi verranno raccolti man mano che arrivano e quando sarà passato il tempo time_period, verranno rilasciati.

Oltre a queste due, sono impiegabili molte altre tipologie di finestre in grado di rispondere a diverse caratteristiche sia del flusso che degli eventi stessi. Questa ricchezza è uno degli aspetti che permette ad Esper di emergere fra le altre soluzione di event processing.

44 Materiali e metodi

3.1.3.3 L’architettura

Utilizzando la sintassi presentata nelle sezioni precedenti si possono costruire delle interrogazioni che vengono collezionate all‟interno del motore Esper e da questo impiegate per gestire ed analizzare in tempo reale i dati proventi dai flussi. Queste interrogazioni sono atemporali, ossia continue: esse vengono applicate ogni volta che un nuovo evento del flusso entra nel sistema. L‟applicazione delle interrogazioni avviene in maniera “inversa” rispetto a quanto succede con le basi di dati. Se nelle basi di dati infatti una diversa interrogazione era applicata di volta in volta sui dati, in questo modello ad ogni istante in cui sopraggiungono nuovi dati, su di essi vengono effettuate le interrogazioni, in modo che siano filtrati per verificare se soddisfino le condizioni richieste dalle regole. Facendo un paragone: i flussi sostituiscono le tabelle e gli eventi le tuple. Alle interrogazioni può essere associato un oggetto Java (POJO, Plain Ordinary Java Object) appartenente ad una classe speciale detta “listener” che esegue, solo nel caso in cui sia verificata l‟interrogazione, l‟azione richiesta dall‟evenienza (per esempio una notificazione, una scrittura su file, il calcolo di un‟operazione, etc) [41]. L‟architettura appena introdotta è illustrata nella Figura 3.2.

Figura 3.2: Architettura Esper.