I problemi relativi alla localizzazione di oggetti e persone in movimento o statici, in ambienti Indoor o sulla superficie terrestre (Outdoor), coinvolgono tematiche riguardanti non solo il mondo delle telecomunicazioni, sono infatti molteplici le tecnologie utilizzate per questi scopi, dal GPS, dalle WLAN, il UWB al Bluetooth, e innumerevoli sono le soluzioni utilizzate per ridurre gli errori dovuti alla natura radio del loro segnale; ma senza ombra di dubbio le difficoltà maggiori sono da identificarsi nei metodi matematici per la soluzione delle equazioni che caratterizzano il problema.
Nell’ambito del progetto C4C è stato studiato e sviluppato un software per la progettazione assistita di reti di localizzazione, la cui utilità consiste nel fornire al personale tecnico impegnato nella progettazione delle reti di localizzazione tutte le indicazioni necessarie per il posizionamento dei rilevatori e della loro interazione con l’ambiente che li circonda.
Il software sviluppato è pensato per essere lo strumento utilizzato dal personale tecnico incaricato della realizzazione di una rete di localizzazione in ambienti indoor e outdoor. Lo strumento serve quindi da supporto a coloro che si devono occupare della scelta del posizionamento ottimale di sensori beacon all’interno di ambienti prestabiliti.
I sensori beacon hanno l’obiettivo di rilevare la presenza di dispositivi mobili con i quali connettersi e stabilire una comunicazione in grado di condividere materiali informativi, pertanto il software deve essere utile a chi è incaricato di progettare la rete di beaconper il rilevamento della presenza di visitatori sia in ambienti sia indoor che outdoor.
Lo strumento permette il caricamento delle rappresentazioni in pianta degli ambienti indoor e outdoor nei quali è prevista la rete di beacon. Una volta caricate le basi è possibile posizionare manualmente in pianta i sensori e verificare la copertura di tutta l’area nella quale è necessario rilevare i dispositivi mobili.
Sulla base degli algoritmi inseriti il software supporta il tecnico evidenziando la copertura di ogni sensore ed insieme le interazioni tra essi. All’interno del software è possibile costruire un elenco di sensori a disposizione individuando per ciascuno di essi le caratteristiche più importanti.
Una volta costruito l’elenco di dispositivi disponibili da parte del tecnico, è possibile, attraverso il software procedere al loro posizionamento. Ciascuno dei sensori inseriti in mappa avrà una propria e specifica area di copertura che sarà coerente con quanto inserito nella descrizione del software.
Contestualmente al posizionamento dei sensori in mappa, il software calcolerà la percentuale di superficie coperta dal segnale.
Al termine delle operazioni di posizionamento sensori, il software fornisce la possibilità di restituire un report utile a ricapitolare le informazioni del progetto, il posizionamento dei beacon scelto e le principali caratteristiche dei device utilizzati.
L’architettura a microservizi presuppone un software composto da servizi indipendenti di piccole dimensioni che comunicano tra loro tramite API ben definite e che sono controllati da piccoli team autonomi.
La scelta di utilizzare microservizi è stata determinata dalla possibilità di scalare e sviluppare applicazioni in modo rapido e semplice.
Ciascun microservizio esegue ciascun processo come un servizio ed ogni servizio esegue una sola funzione.
I microservizi comunicano tra di loro attraverso uno strato di messaggistica per il quale è stato scelto un protocollo standard ed uno strumento opensource che lo implementa.
Il software scelto per questa funzione è RabbitMQ, un broker di messaggistica che implementa il protocollo AMQP e si basa sul framework OTP per la gestione dei cluster e dei failover. Le librerie per interfacciarsi a questo broker sono disponibili in svariati linguaggi ed ambiente di programmazione e quindi è adatto alla implementazione di una architettura mista a microservizi.
Ogni servizio utilizzerà, se necessario, un database per la memorizzazione dei dati. Non è indispensabile che tutti i servizi utilizzino lo stesso database e la stessa tecnologia per la memorizzazione dei dati. Essendo la comunicazione tra servizi basata su messaggi e su API, nessun servizio accede ai dati di un altro servizio attraverso una connessione diretta al database.
I database scelti per la memorizzazione dei dati sono: MS SqlServer, Postgre SQL, Redis, MongoDB. I Database elencati coprono ampliamente le casistiche di memorizzazione di dati relazionali/non relazionali/documentali generalmente necessari allo sviluppo moderno delle applicazioni.
La parte client utilizza le moderne tecniche di rendering client side per sfruttare la massimo le caratteristiche dei browsers moderni. Anche il client, come il server, è strutturato in una architettura modulare, denominata micro frontend.
L’architettura dei server lato servizi quindi la parte back-end è realizzata a microservizi, come descritto nel paragrafo precedente. L’architettura segue un pattern CQRS ed eventi.
La caratteristica principale di CQRS è la separazione di responsabilità tra le query e i comandi. Nel modello CQRS infatti le operazioni di lettura sono separate dalle operazioni di aggiornamento dati. Il vantaggio di implementare un’architettura in CQRS è l’ottimizzazione delle prestazioni, la scalabilità e la sicurezza. Questo pattern infatti garantisce una elevata flessibilità che permette una migliore evoluzione nel tempo ed impedisce ai comandi di aggiornamento di causare conflitti di merge a livello di dominio.
Tradizionalmente viene utilizzato lo stesso modello dati per eseguire query su un database e per aggiornarlo. Questo in applicazioni semplici potrebbe essere mantenuto mentre per applicazioni complesse questo approccio potrebbe risultare meno conveniente e poco pratico.
Uno dei fattori che determina i vantaggi di questo approccio di separazione riguarda i diversi carichi di lavoro di lettura e scrittura. Spesso aventi proporzioni differenti, i carichi di lavoro di scrittura e i carichi di lavoro di lettura presentano requisiti di scalabilità e di prestazione diversi tra loro.
A partire da questa considerazione, esistono ulteriori caratteristiche che determinano gli enormi vantaggi della scelta di un patter CQRS. Tra queste la mancata corrispondenza che esiste tra le rappresentazioni in lettura e scrittura dei dati come potrebbe capitare per colonne o proprietà aggiuntive che seppur aggiornate correttamente non sono necessariamente parte di un’operazione. Esiste inoltre la possibilità di generazione di conflitti di dati che possono verificarsi quando le operazioni vengono eseguite in parallelo sullo stesso set. L’approccio tradizionale inoltre potrebbe influenzare negativamente sulle prestazioni a causa sia del carico sull’archivio dati e sul livello di accesso ai dati ma anche a causa dell’eventuale complessità delle query necessarie per recuperare le informazioni. Rimane inoltre di difficile gestione la sicurezza e le autorizzazioni poiché ogni entità è soggetta ad operazioni di lettura e scrittura che potrebbero esporre i dati nel contesto errato.
Alla luce di queste criticità che potrebbero manifestarsi, la realizzazione del software è stata effettuata abbandonando l’approccio tradizionale per seguire invece un modello a microservizi che segue il pattern CQRS.
Come accennato precedentemente, il pattern CQRS si basa sull’idea di separare le operazioni di scrittura dalle operazioni di lettura. Queste operazioni seguono modelli diversi e quindi comandi differenti che in un caso servono per aggiornare i dati e nell’altro consistono in query per leggere i dati.
Perché questa separazione avvenga in maniera corretta, sono necessarie alcune condizioni tra cui:
La separazione tra i modelli di query e i modelli di aggiornamento semplifica la progettazione e l’implementazione anche se genera anche uno svantaggio: il codice CQRS non può essere generato automaticamente da uno schema di database tramite meccanismi di scaffholding come gli strumenti ORM.
Al fine di garantire un isolamento maggiore è possibile separare anche fisicamente i dati di lettura da quelli di scrittura. Così facendo però il database di lettura potrebbe utilizzare il proprio schema di dati ottimizzati per le query. Potrebbero anche essere utilizzati tipi di archivio dati differenti.
Naturalmente, utilizzando database di lettura e scrittura separati sarà necessaria la sincronizzazione che potrebbe essere eseguita facendo in modo che il modello di scrittura pubblichi un evento ogni volta che viene aggiornato il database. In questo caso l’aggiornamento del database e la pubblicazione dell’evento devono essere eseguiti in un’unica transazione.
Nel software sviluppato si è scelto tuttavia di mantenere un database unico.
Il Framework utilizzato è Microsoft .Net Core Framework 5.0 e successivi.
Sono utilizzati all’interno del framework strumenti standard per permettere l’utilizzo delle funzionalità dei microservizi e per la gestione e la implementazione dei pattern scelti.
E’ utilizzato per gestire il pattern CQRS in-process e permette la corretta implementazione senza la necessità di avere un gestore degli eventi esterno, ma si occupa internamente di recapitare gli eventi in modo corretto agli handler selezionati.
RabbitMQ è utilizzato come dispatcher di messaggi per la implementazione del pattern CQRS con eventi asincroni.
L’attuale implementazione utilizza un helper per semplificare e standardizzare la gestione e la registrazione degli exchange e delle code.
Grazie a MediatR e RabbitMQ è possibile eseguire un disaccoppiamento completo tra i servizi esposti e la logica di business. Internamente alcuni Handlers si occupano gestire i messaggi recapitati attraverso le code di messaggi, e conseguentemente modificare il modello dati nel caso di Command, oppure preparare il dato per la lettura nel caso di Query.
I Dati sono memorizzati in Database specifici scelti in base alle caratteristiche del dato stesso. Tutti i dati complessi sono memorizzati in DB Relazionali, più in dettaglio i dati strutturati dei sensori, dei device e delle loro posizioni sono strutturati e memorizzati all’interno di un DB su MS SQL Server. I dati documentali strutturati e gli shapefiles, così come anche le immagini e gli allegati sono memorizzati in una struttura a filesystem, organizzati in modo automatico per dominio di appartenenza e tipo di formato. Un DB Redis è utilizzato inoltre, per indicizzare le informazioni memorizzate nel filesystem ed aggiungere metadati e legami trasversali con altre fonti dati.
L’architettura del software lato front-end è realizzata seguendo la logica dei micro-frontend quindi estendendo i concetti di microservizi anche al mondo front-end.
La tendenza attuale è quella di procedere verso una sempre maggiore ricchezza di funzionalità delle applicazioni broswer, note come app a pagina singola, e spesso sviluppate da un team separato rispetto al back end. Questo rende la manutenzione del monolite front-end sempre più complicata. Per questo motivo si è arrivati alla logica di intendere il sito web o l’app web come una composizione di funzionalità di proprietà di team differenti. Ogni team ha un’area di attività in cui è specializzato. Il team è interfuzionale e sviluppa le sue funzionalità end-to-end, dal database all’interfaccia utente.
Con questa struttura è stata sviluppato il software oggetto del presente documento. Di seguito approfondiamo i moduli base inseriti.
Esistono alcuni algoritmi di localizzazione che si basano sulla stima della potenza del segnale trasmesso. C4C utilizza la tecnica della triangolazione, altrimenti definita trilaterazione o multilateralizzazione. Questa tecnica permette, dati N riferimenti (beacon), di stimare la posizione del target basandosi sulle distanze rilevate.
Per marketing di prossimità si intende quel tipo di pubblicità, annunci o promozioni che l’utente riceve sul proprio dispositivo mobile in relazione alla propria posizione geografica, avendo così un riscontro diretto tra l’oggetto della pubblicità e la propria posizione.
©2021 Cloud4City | All Rights Reserved.