Un sistema di controllo remoto di sistemi eterogenei

Si prevede che il sistema dovrà avere due interfacce per interagire con l’esterno.
- una per comunicare con l’esterno della rete, attraversata dai messaggi scambiati col sistema server richiedente; il formato dei messaggi sarà da stabilire.
Questa interfaccia deve inoltre provvedere alla sicurezza, per evitare attacchi e richieste non autorizzate. Si può pensare a un sistema di autenticazione, e anche alla cifratura dei messaggi trasferiti.
- una seconda interfaccia verso l’interno e cioè verso il componente da monitorare, con cui verranno scambiati i messaggi opportunamente tradotti , che possiamo suddividere in :
1)comandi runtime, ad esempio organizzati in script
2)comandi di sistema, che possono essere messaggi SNMP, API , o plugins esterni, creati da noi o reperiti altrove.

All’interno della “cellula” del sistema si possono progettare diversi moduli:
-uno per il logging delle operazioni effettuate,
-uno per il check del proprio stato,
-uno o più descrittori xml contenenti gli elenchi dei plugin che devono essere noti, l’elenco dei comandi, i loro parametri, ed altre informazioni (vedi paragrafo relativo)
-altri moduli per la gestione dei comandi SNMP
-moduli per la lettura dei log dei dispositivi che supportano questa modalità

Le nostre necessità di comunicazione con i dispositivi possono essere di tre tipi, poi riconducibili a due.
-OUT, quando un’informazione esce dal dispositivo e deve essere comunicata a chi lo controlla dall’esterno.
Il tipico caso del realizzarsi di un evento, in un momento non prestabilito. Può essere un allarme, una notifica di variazione di parametri e quant’altro non sia necessariamente una risposta ad una richiesta e non sia prevedibile nel tempo.
-IN-OUT scambio bidirezionale di informazioni, come una richiesta di lettura di un parametro o l’esecuzione di un comando con risposta.
-IN richiesta semplice. Può essere l’invio al dispositivo di un comando che non ritorna un valore o un messaggio. Questo caso è però riconducibile all’in-out, perché è comunque utile avere una minima risposta che confermi la ricezione del comando ed eventualmente la corretta esecuzione.