Servizi di secondo livello e architettura dati

Componentistica · 1 messaggi · primo messaggio 14/02/2018 08:09

luca

14/02/2018 08:09 · messaggio #9

Ormai la maggior parte dei sistemi sono orientati all' interoperabilità quindi oltre che un accesso da portale o applicazione legacy forniscono servizi web e microservizi.
La distinzione tra i due è puramente pratica perchè i servizi web generano transazioni generalmente appoggiate sul linguaggio SQL (gestito tramite Java o PHP) mentre i microservizi utilizzano le API. Nel nostro caso poi occore non trascurare altri servizi web e precisamente quelli geografici (Wms e Wfs) che generano flussi dati secondo un loro standard e i servizi di file server che danno accesso a file immagine o multimediali.
Non tutti i sistemi coinvolti in formaromae sono attrezzati per fornire servizi web e che io sappia nessuno fornisce microservizi, potrebbe sembrare che sviluppandoli adeguatamente in modo che eroghino tutti servizi e microservizi lo scopo del progetto sia sostanzialmente raggiunto.
Ebbene non è affatto così perchè Formaromae non dovrà essere un ammodernamento di vecchi sistemi, ma un nuovo sistema di AI che fornirà servizi di secondo livello.
Dovrà agire, sfruttando appunto i metadati, come un omogeneizzatore di architetture diverse che ricostituisce una unica base dati secondo una architettura dati unitaria che va progettata. Ribadisco i 3 tempi fondamentali su cui si basa il suo motore:
E) estrazione dei dati dai sistemi in uso
T) Filtraggio, correzione automatica, transcodifica, disambiguazione, offuscamento, identificazione univoca
L) caricamento del risultato in una nuova base dati temporanea secondo una nuova architettura
Il lavoro del nostro sistema però non si esaurisce qui perchè una volta ottenuta questa nuova base dati su di essa saranno poggiati vari componenti.
Il primo (e più ovvio) è un portale web con una componente webgis, ma anche dei servizi e microservizi (che ho definito appunto di secondo livello) che saranno assolutamente diversi da quelli delle basi originarie e che non potranno essere semplicementa la somma o il rilancio di servizi già esistenti se non altro per il fatto che la loro base dati avrà una architettura diversa da quella dei servizi di origine. Per completezza elenco anche gli altri due componenti anche se probabilmente meritano una riflessione separata: il server degli opendata (che non è un servizio perchè non opera on demand, ma in modailtà batch) e l'analisi di big data che rappresenta il momento di massima valorizzazione del patrimonio di conoscenza.
Tornando ai nostri servizi di secondo livello la riflessione fatta mi sembra risolva definitivamente i problemi di rapporto con le piattaforme madri (NIC compresa) perchè è chiaro che dovremo disegnare noi i nuovi servizi, profilare gli utenti ecc e quindi avere ad esempio un nostro geoserver, una nostra struttura di HA ecc... Per fare questo dobbiamo considerare anche la possibilità che sia più pratico andare a prelevare i dati alla fonte senza passare necessariamente per altri servizi web, ma con un accesso diretto in lettura ai database, geodatabase e file immagine e multimediali delle banche dati madri.

← Torna all’indice