Gestione dello stato delle applicazioni a 3 livelli

Puoi avere diverse posizioni di archiviazione a seconda della tua architettura.

1. È possibile memorizzare tutti i dati su ciascuno dei sensori stessi e il server li richiede (e li memorizza nella cache) regolarmente. Di conseguenza, i dati definitivi risiedono su ciascun sensore.

2. I dati vengono inviati al server che li memorizza. I sensori conservano solo i dati per un breve periodo, bufferizzati fino a quando non possono essere inviati (a causa di interruzioni di rete o limiti di larghezza di banda) o lo stato più recente viene inviato al server non appena è pronto.

L'interfaccia utente non dovrebbe contenere lo stato, richiedere i dati necessari al server per la visualizzazione.

È davvero facile mettere i dati sul server e assumerne lo stato definitivo, ed è buono come è necessario. Se un sensore non è in linea, devono essere registrate anche le informazioni (ovvero l'ultima volta in cui i dati sono stati ricevuti). Quindi i sensori possono essere apolidi e devi solo codificare la complessità della gestione dei dati nel server.

Non si dovrebbe mai duplicare lo stato, tuttavia, i dati vengono salvati per l'uso o in transito verso il negozio. Se si sceglie l'opzione 1 per la propria architettura, il server diventa semplicemente una cache per i dati che legge dai sensori. È possibile spegnere il server e perdere tutti i dati e sarà OK, poiché al riavvio ripopolerà la cache. ma se i sensori inviano solo irregolarmente, allora ci saranno degli spazi vuoti fino a quando non invieranno, quindi l'opzione 2 potrebbe essere migliore in quanto l'ultimo stato verrà letto da un database persistente su cui il server memorizza i dati.

Devi considerare i tuoi casi d'uso più ampi.

• Che cosa vuoi che succeda se un sensore o un controller sono offline?

  • Vuoi essere in grado di mostrare i valori più recenti indicati dal sensore?
  • Vuoi essere in grado di prendere comandi, che avranno effetto quando ritorna online?
  • Vuoi essere in grado di mostrare (ad altre interfacce utente) il comando / stato che verrà inviato quando tornerai online.

• Che cosa vuoi fare per l'aggiornamento o il riavvio del server? Dovrebbe riscoprire i sensori e i loro valori, o portare avanti alcune nozioni sul server precedente?

In un ambiente client-server, le informazioni vengono inviate a un'interfaccia utente. Se tali informazioni possono cambiare (ad esempio, da un'altra interfaccia utente che invia comandi al server, o un processo in background / batch o nel caso da un sensore), ciò che l'interfaccia utente visualizza all'utente è, in un certo senso, sempre stantio!

Quindi, dovremmo tenerne conto nella progettazione delle API (server) in modo che siano in grado di realizzare scenari significativi.

In alcuni domini significa fornire API che aumentano o diminuiscono invece di impostare valori assoluti (e in altri, viceversa).

A volte forniremo protezioni nell'API, come "cambia qualche elemento in quel valore" ma solo se ha ancora questo valore (un confronto e uno swap), o forse solo se non è stato altrimenti aggiornato da qualche tempo (o indicatore di versione). Possiamo anche fornire timestamp o contatori insieme ai valori, che mostrano quanto siano aggiornati i valori.

The question is where to store current state of equipments. Do I need to duplicate state in all programs or just to store data at the server?

Considera i tuoi casi d'uso più ampi. Inoltre, differenzia diversi tipi di stato, ad es. misurazioni rispetto ai log della cronologia, rispetto alle impostazioni.

How to deal with data synchronization between the programs?

Per prima cosa, dovremmo fornire API che soddisfino le esigenze dei tuoi scenari di sincronizzazione. Un'API eccessivamente semplice può essere soggetta a condizioni di competizione, problemi di stasi o problemi di atomicità.

Per un altro, dovremmo avere un'idea definitiva di chi possiede quale stato. I sensori possiedono probabilmente le misurazioni in tempo reale e il server forse possiede i registri. Controller e amp; gli attuatori probabilmente possiedono alcuni stati per il loro funzionamento ma potrebbero essere duplicati sul server, che potremmo effettivamente considerare autorevoli (nel caso in cui un controller debba essere sostituito, in modo che possa essere riprogrammato dal server).

Inoltre, esistono numerosi metodi che è possibile utilizzare per aggiornare gli UI quando vengono rilevate modifiche (in generale, ad esempio il polling o la notifica). Se le tue interfacce utente sono basate su browser, esegui l'analisi dei framework (ad esempio Angular o React).

In breve, usa una combinazione di comprensione di chi è autorevole per quali dati, API che sono amichevoli e amp; capace (dato che nei sistemi distribuiti possono essere applicate informazioni potenzialmente obsolete), indicazioni che confermano come sono aggiornate le informazioni e notifica tempestiva delle modifiche.