Raccolta remota e condivisione

[schumi]

avevo buone speranze sul progetto SQLDBRestBridge ma non mi pare stia procedendo.
Sono interessato anch'io all'evoluzione del tuo progetto, quella della raccolta e smistamento dati è una situazione molto frequente nel mio mondo.

ciao

[DragoRosso]

Diversamente da quando stà facendo @nomorelogic che ha probabilmente dei vincoli e degli obiettivi ben precisi legati specificatamente all'attività che la sua azienda svolge, io stò sviluppando una soluzione che verso il campo sia la più semplice, sicura e praticabile possibile.

Nel "campo" ho degli oggetti che tendo a rendere o molto "stupidi" (quelli di cui ho parlato in questo topic) o superelaborativi (tipo blackbox).

Facendo capo a quelli "stupidi" stò verificando qual'è il modo migliore, tenendo conto dei fattori già indicati, per trasmettere i dati ad un collettore centrale. Di base questo lo faccio già, e con impianti sparsi in giro per il mondo ... e se ci fosse qualcosa che non và .... sarei già morto. Solo che sono sistemi che comunicano con protocolli abbatsanza complessi con database remoti ridondati localmente.

Inoltre stò cercando di capire quale collettore è il più flessibile e abbordabile, tenendo conto sopratutto che si dovrà interfacciare con sensori "stupidi". Parlare di SSL, criptatura asimmetrica, SFTP o quant'altro potrebbe risultare complesso. Idem per quanto riguarda REST.

Questo riguarda però l'invio dei dati dal campo verso il collettore, problema abbastanza relativo visto che i dati dovranno comunque essere poi validati. Anche un trasferimento TCP in formato Encode64 potrebbe andare bene .... anche tenendo conto che non sono dati sensibili (almeno così sono i miei, altrimenti passiamo al capitolo blackbox "superelaborativi").

Quello che secondo mè è più interessante è capire il collettore che tecnologia dovrà usare in toto, a partire dalla sua struttura e presentazione (ad esempio un virtual server, un file server, un object container o un web server).

Da qui poi si parte per la sezione più adattabile, ossia la presentazione dei dati verso i client ... qui la tecnologia può essere usata in abbondanza, tenendo conto che tendenzialmente parliamo di PC (per svariati motivi).

E forse questa è la parte più critica, in quanto abbiamo un accesso ai dati e ciò rappresenta un potenziale problema.

Come dicevo, per adesso mi sono portato nella situazione più generale e flessibile usando un Virtual Server in CLOUD che mi consente di fare tutto, poi in base a ciò che verrà costruito si potrà valutare la migliore soluzione con valutazione anche economica della cosa.

Se postate le vostre esigenze e idee, posso vedere di tenerne conto e di pensare a qualcosa che le ricomprenda e sia il più generico possibile. Parlare di ETL ora .... per questo progetto siamo lontanucci, sia in termini di risorse che in termini di obiettivi (almeno per quel che mi riguarda).

Ciao.

P.S.: ovviamente poi verrà pubblicamente postato il progetto.

[nomorelogic]

@schumi
probabilmente, lavoriamo in situazioni simili, io nella fattispecie in ambito gestionale/erp
vi terrò aggiornati anche perché avrei intenzione di realizzare uno strumento abbastanza orizzontale e sono interessato a coprire, nei limiti del possibile, più problematiche possibili
quindi idee e suggerimenti sono graditissime

@DragoRosso
è chiaro che capire la natura del collettore è indispensabile ma tra file server, object container e web server, penso che per prendere la decisione devi  pensare al tipo di dato e dopo il tipo di collettore la vedo una conseguenza

un suggerimento che posso dare è che con un web server, in  teoria, ci copri tutte le esigenze e se in futuro ti interessa SSL non dovrai far altro che mettere il certificato
fai conto che per comunicare con il web server lo puoi fare anche con curl....

riguardo ETL, forse ho usato un parolone ma quello dovrà essere il risultato finale
quello che bolle in pentola è effettivamente raccolta e smistamento dati
non è che sia poi tanto diverso da quello che ti serve


per quanto riguarda linux che non ti piace più di tanto...
il tempo è galantuomo 

[schumi]

probabilmente, lavoriamo in situazioni simili, io nella fattispecie in ambito gestionale/erp

gestionale e vari applicativi in ambito retail food