In poche parole OSGi è uno standard utilizzato per creare applicazioni modulari. Aggiunge un nuovo livello di modularità: bundle (ovvero componenti, moduli). Ogni bundle contiene classi e interfacce e quello che è il più importante si deve esplicitamente indicare:
- che altri componenti o pacchetti Java utilizza,
- e quali pacchetti vuole esporre a essere utilizzato da altri componenti.
Dal punto di vista tecnico fasci sono file jar che hanno un po 'esteso META-INF/MANIFEST.MF file. Tutte le informazioni di cui sopra sono memorizzate nel file MANIFEST.MF.
Dal punto di vista pratico questo esplicito presentatore presenta vantaggi e svantaggi. Per me il più grande vantaggio è che sei costretto a pensare alla tua architettura, ai moduli e all'interazione tra loro più che nelle applicazioni standard. Questo può creare una migliore architettura in cui ogni modulo è responsabile di compiti ben definiti e moduli possono essere riutilizzati. Se si tratta di svantaggi, la creazione di molti moduli può essere talvolta dolorosa. È abbastanza facile avere molti moduli e se ne hai davvero molti potrebbe essere difficile mantenere tutte le dipendenze tra i moduli (i cicli di dipendenza sono piuttosto dolorosi).
OSGi non è solo uno standard di sole applicazioni modulari. Specifica anche l'ambiente in cui i bundle esistono e vengono eseguiti. Questo è qualcosa che dovresti sapere - quando usi OSGi devi avviare la tua applicazione in un ambiente speciale. Questo ambiente (ad esempio Eclipse Equinox) è responsabile dell'esecuzione dell'applicazione. Fornisce alcune possibilità di fantasia. Ad esempio è possibile aggiungere un pacchetto a un'applicazione già in esecuzione senza la necessità di interrompere questa applicazione - questo potrebbe essere un elemento molto importante in alcuni tipi di applicazioni (ma IMHO non ci sono molte applicazioni che avranno davvero bisogno di questo).
Ciò che è davvero molto importante è anche il fatto che alcune librerie open source potrebbero non essere completamente compatibili con l'infrastruttura OSGi e potrebbe essere difficile usarle fuori dagli schemi come nelle applicazioni Java standard (ricordate che in OSGi tutto dovrebbe essere un pacchetto). Tuttavia, molte librerie popolari sono state raggruppate in pacchetti, ad esempio Spring fornisce il suo bundles repository che contiene molte librerie popolari (ma non tutte).
OSGi è piuttosto complicato ed è difficile descriverlo e le sue possibilità in poche parole.Quello che ho scritto sono solo gli elementi più importanti (IMO) di OSGi. Ma OSGI è molto di più, ad es. i pacchetti possono inviare eventi a vicenda, possono fornire servizi a vicenda. Se sei interessato a maggiori dettagli ti suggerisco di passare attraverso un tutorial. Posso raccomandare this one in Java World. Dopo di che si può dare un'occhiata a this free e-book su OSGi (contiene molti dettagli). Tutti i dettagli su OSGi possono essere trovati nelle specifiche ufficiali ma non direi che sono facili da leggere (almeno all'inizio) - li puoi trovare here (prima di scaricare dovrai accettare la licenza e alcune note legali) .
Per riassumere, penso che OSGi sia utile per la creazione di applicazioni modulari, ma questo non è certo gratuito. È piuttosto uno standard pesante che potrebbe non consentirvi di fare alcune cose e costringerti a fare le cose in modo OSGi.
Alcune legate SO domande:
Grazie mille per la risposta dettagliata :) – Izza
ora con l'avvento di Microservices, in che modo microservizi diversi o migliori sono rispetto a OSGi? – yathirigan