Ambiente di esecuzione #
Una Cloudlet può essere avviata o arrestata, e allo stesso modo un plugin può essere installato, avviato, arrestato o rimosso da una Cloudlet indipendentemente dallo stato dell’esecuzione di questa. L’indipendenza a runtime è particolarmente utile quando la Cloudlet è in esecuzione: ad esempio, potremmo sostituire in tempo reale (hot swap) un plugin per la generazione di report con una sua versione aggiornata, il tutto senza dover arrestare la Cloudlet e quindi con impatto minimo sulla disponibilità dell’applicazione.
Tutto ciò è reso possibile dall’ambiente comune in cui Cloudlet e plugin vengono eseguiti: Apache Karaf, un framework che implementa lo standard OSGi.
Il framework OSGi #
OSGi definisce un framework Java orientato ai servizi che consente lo sviluppo di sistemi a componenti dinamici; in esso, le applicazioni sono realizzate interconnettendo bundle, ciascuno dei quali non è altro che un .jar il cui file manifest.mf include delle direttive proprie del framework atte alla configurazione del classpath e delle dipendenze del bundle stesso. Il bundle viene installato ed eseguito in un container OSGi, che si occupa di interconnetterlo con gli altri bundle presenti e di risolvere le dipendenze tra i package.
Un apposito livello del framework è dedicato alla gestione dei ciclo di vita del codice: i bundle possono infatti essere installati, avviati, arrestati e rimossi a runtime senza la necessità di dover riavviare l’intero sistema – la Cloudlet, nel nostro caso. La risoluzione delle dipendenze di un bundle avviene quindi automaticamente quando questo viene installato nel container.
Configurazione dei servizi #
Sebbene non richiediamo una conoscenza approfondita di OSGi, è importante chiarire il significato di Service in Service Handler. OSGi supporta l’astrazione dei servizi per realizzare l’interazione a runtime tra le classi: nel container è infatti presente un registro sul quale i bundle possono pubblicare e/o ricercare servizi specificandone le interfacce Java. L’istanziamento e la pubblicazione di un servizio avvengono quando il bundle viene avviato nel container e passa dallo stato resolved allo stato active.
Il meccanismo d’attivazione di un generico plugin si riassume nei seguenti punti:
- Un bundle contenente l’implementazione HandlerImpl di un Handler H viene installato e attivato;
- HandlerImpl viene istanziato e pubblicato sul registro dei servizi;
- Nell’applicazione si verifica un qualche evento per cui è richiesta l’invocazione di H. La Cloudlet ricerca quindi H sul registro dei servizi e trova HandlerImpl;
- Viene invocata HandlerImpl.
Esistono diversi modi per dichiarare e configurare un servizio OSGi, uno di questi è mediante i blueprint. Un blueprint è un file .xml che dichiara al container un servizio definendo il legame tra interfaccia e implementazione, configurando la dependency injection in maniera simile al framework Spring. Il bundle dovrà quindi contenere uno o più blueprint contenenti la dichiarazione degli Handler implementati.
Esempio di blueprint.xml della classe MyHandlerImpl che implementa il FormActionHandler “SayHello” sulla classe “Class1”
Ulteriori letture #
In questa guida abbiamo solamente accennato le caratteristiche principali di OSGi. Rimandiamo alle seguenti letture qualora fosse necessario configurare manualmente i bundle dei plugin:
Continua la lettura: Ciclo di sviluppo