Gestione dinamica delle risorse

L’obiettivo successivo è quello di poter aggiungere risorse in modo dinamico quando aggiungiamo un servizio.

È molto importante ad esempio quando abbiamo un nuovo sensore da voler esporre esternamente e vogliamo creare velocemente una risorsa CoAP all’interno del Service implementato in precedenza.

I passi che devono essere eseguiti per poter ottenere questo risultato sono:

1. Specificare all'interno della classe appena creata i metodi che servono per l’attivazione e la disattivazione del Service CoAP.

2. Per poter modellare correttamente la nostra risorsa possiamo aver bisogno di

specificare i metodi di callback relativi alle varie operazioni REST (GET, POST, PUT e DELETE). Viene presa in considerazione la classe principale di Californium relativa alle risorse (CoapResource). Una volta fatto l’override di tutti metodi che occorrono possiamo andare ad inserire all'interno dei metodi activate e deactivate le chiamate alle funzioni di aggiunta rimozione delle risorse relative al Service.

In questo modo riusciamo a mantenere aggiornata la lista delle risorse esposte dal Service in modo dinamico e senza doverlo riavviare.

Lo schema appena descritto può essere utilizzato anche in concomitanza con la Resource Directory per ottenere un supporto di CoAP scalabile, estendibile e sempre aggiornato. La gestione delle risorse locali e quelle esterne è diversa. Infatti quelle locali vengono gestite in maniera ottimizzata sulla stessa piattaforma senza quindi andare ad effettuare delle

richieste CoAP.

Quelle esterne invece dato che utilizzano la Resource Directory sono organizzate in modo diverso. L’ aggiunta e la rimozione (o anche l’aggiornamento) delle risorse sulla RD avviene attraverso le normali richieste REST.

Gli endpoint non sono memorizzati permanentemente nella RD ma vengono conservati per un periodo di tempo limitato.

Come descritto all'interno della RFC si può utilizzare un timer per ogni entry. Una volta scaduto ci permette di capire che dobbiamo eliminarla senza che l’endpoint debba effettuare una richiesta di DELETE.

Dato che comunque ci troviamo in un ambiente molto dinamico questo tipo di approccio è utile soprattutto quando un nodo cade e non ha la possibilità di de-registrarsi.

L'unico aspetto negativo è quello che l’endpoint entro un certo intervallo di tempo deve inviare una richiesta di tipo PUT per azzerare il countdown.

L'implementazione principale del server utilizza una delle funzionalità più importanti dei bundle OSGi: la fornitura di servizi con l'exporting dei package.

Lo sviluppo di una risorsa personalizzata con i vari metodi REST è molto semplice in quanto non dobbiamo fare altro che importare solo i package di Californium che ci servono

direttamente dal CoAP Service.

Il modo in cui i vari broker interagiscono nell'architettura è molto importante in quanto gestendo opportunamente lo scambio di messaggi e la propagazione degli aggiornamenti riusciamo ad ottimizzare le prestazioni del supporto.

Ogni nodo all'interno dell’architettura specifica il proprio dominio e il gruppo di

appartenenza. Questo permette di limitare l'interesse verso le risorse esterne da memorizzare all'interno della Resource Directory. Naturalmente se non viene specificato il gruppo, il numero di messaggi che il broker dovrebbe elaborare sarebbe maggiore.

Una prima ottimizzazione per quanto riguarda il servizio CoAPTreeHandler è che ogni volta che riceve una richiesta per il riferimento alla radice dell'albero aggiorna il proprio stato interno sul nodo che si è appena collegato ed ha inviato la richiesta.

L'aggiornamento della Resource Directory all’interno della root invece avviene, come da protocollo, solo tramite una richiesta REST.

Considerando l'inserimento di un nodo ad un livello gerarchico inferiore bisogna capire quali informazioni propagare verso l’alto fino ad un determinato livello:

1. Una prima soluzione sarebbe quella di inviare tutti i link delle risorse al livello superiore. L’aspetto negativo è che il nodo parent potrebbe avere un numero di figli

elevato e quindi la propria RD potrebbe contenere un numero troppo elevato di risorse.

2. Un'altra soluzione sarebbe quella di inviare solo il numero totale di risorse. In questo caso però ci sarebbe il problema di non essere a conoscenza del tipo di risorse presenti nel nodo figlio e quindi potremmo comunque avere dei problemi nel caso di richieste specifiche. Inoltre per ogni nuova risorsa collegata dobbiamo inviare gli

aggiornamenti ai nodi di livello superiore.

3. Una terza soluzione sarebbe quella di inviare solo le proprietà delle risorse

attualmente collegate. Rispetto alla soluzione precedente minimizziamo il numero di interazioni tra i broker dato che non inviamo tutti i link ma soltanto le informazioni utili ad un'eventuale ricerca. Un comportamento simile non è descritto all'interno del documento ufficiale della Resource Directory e quindi deve essere implementato a parte come caratteristica specifica del supporto.

Se avviamo un nuovo broker che presenta le stesse proprietà gerarchiche di altro nodo già presente bisogna che prima di entrare a far parte dell'albero ci sia l'intervento del

CoAPTreeHandler.

Prendiamo in considerazione i vari casi possibili:

1. Aggiunta di un nodo foglia con un percorso già esistente : viene comunque aggiunto alla stessa root del broker gemello.

2. Aggiunta di un nodo intermedio : viene aggiunto come discendente del nodo gemello 3. Aggiunta di un'altra root : se non specifichiamo il dominio ed eseguiamo una root

request ci viene restituito l'indirizzo della radice al quale collegarci. Eventuali

richieste da parte di altri nodi non verrebbero comunque redirette verso il nuovo nodo e potrebbe comunque essere utilizzato successivamente come nuova root nel caso cada quella precedente.