La OSGi Alliance (conosciuta come Open Service Gateway initiative), è un'organizzazione fondata nel 1999 da Ericsson, IBM, Oracle e altri.[1] In seguito altri membri sono entrati a farne parte.[2]
Il nucleo delle specifiche è un framework che definisce la gestione del modello del ciclo di vita del software, i moduli (chiamati bundle), un service registry e un ambiente di esecuzione. Partendo da questo Framework sono stati definiti un certo numero di OSGi Layer (strati), API e servizi.
L'aumento della complessità in un prodotto software, sia esso embedded, client o server, richiede codice modulare ma anche sistemi che siano estensibili dinamicamente. Il framework OSGi si propone di implementare un modello a componenti completo e dinamico cioè quello che manca all'ambiente Java.
In realtà il linguaggio Java prevede alcuni meccanismi che consentono di realizzare un modello a componenti, ma si tratta comunque di soluzioni di basso livello con conseguente rischio di introdurre errori nel codice oltre a diventare una soluzione ad-hoc.
OSGi risolve molti dei problemi legati allo scarso supporto di Java nella modularità e nel dinamismo attraverso alcuni concetti fondamentali:
- Definizione del concetto di modulo (bundle)
- Gestione automatica delle dipendenze
- Gestione del ciclo di vita del codice (configurazione e distribuzione dinamica)
In sintesi è possibile vedere la tecnologia OSGi come:
- Un sistema modulare per la piattaforma Java
- Un sistema dinamico, che consente l'installazione, l'avvio, lo stop e la rimozione dei moduli a runtime, senza quindi necessitare di riavvii.
- Orientato ai servizi, i quali possono essere dinamicamente registrati ed utilizzati nella macchina virtuale Java.
Il Framework OSGi è distribuito su quattro layer:
- L0: Execution Environment (ambiente di esecuzione): è la specificazione dell'ambiente Java (J2SE, CDC, CLDC, MIDP, ecc.).
- L1: Modules: realizza il concetto di moduli (bundle) e controlla il collegamento tra di loro.
- L2: Life Cycle Management (Gestione del ciclo di vita): gestisce il ciclo di vita di un bundle senza richiedere il riavvio della VM.
- L3: Service Registry: fornisce un modello di cooperazione per i bundle.
- OSGi Release 1 (R1): maggio 2000
- OSGi Release 2 (R2): ottobre 2001
- OSGi Release 3 (R3): marzo 2003
- OSGi Release 4 (R4): ottobre 2005 / settembre 2006
- Core Specification (R4 Core): ottobre 2005
- Mobile Specification (R4 Mobile / JSR-232): settembre 2006
- OSGi Release 4.1 (R4.1): maggio 2007 (AKA JSR-291)
- OSGi Release 4.2 (R4.2): settembre 2009 (AKA JSR-119)
- Enterprise Specification (R4.2): Marzo 2010
- OSGi Release 4.3 (R4.3): Aprile 2011
- Core: Aprile 2011
- Compendium and Residential: Maggio 2012
- OSGi Release 5 (R5): Giugno 2012
- Core and Enterprise: Giugno 2012
- OSGi Release 6 (R6): Giugno 2015
- OSGi Release 7 (R7): Aprile 2018
- Core and Compendium: Aprile 2018
- OSGi Release 8 (R8): Dicembre 2020[3]
Esistono diversi gruppi responsabili della definizione delle specifiche:
- Core Platform Expert Group (CPEG)
- Mobile Expert Group (MEG)
- Vehicle Expert Group (VEG)
- Enterprise Expert Group (EEG)
Esistono diverse soluzioni software, alcune commerciali, altre Open source che implementano le specifiche OSGi, tra le più conosciute:
- Equinox (utilizzato da Eclipse)
- Knopflerfish
- Apache Felix
- Apache Karaf
- Spagic 3 (open source SOA Universal Middleware)
Tutte implementano la versione 4 delle specifiche e sono Open source.
Tra le implementazioni commerciali spicca quella della ProSyst.
- (EN) Sito ufficiale, su osgi.org.
- Domande frequenti, su www2.osgi.org. URL consultato il 12 maggio 2008 (archiviato dall'url originale l'8 maggio 2008).
- Specifiche OSGi, su osgi.org. URL consultato il 12 maggio 2008 (archiviato dall'url originale il 22 ottobre 2015).
- OSGi Specification License, su osgi.org. URL consultato il 12 maggio 2008 (archiviato dall'url originale il 1º maggio 2008).