Ho letto su Wikipedia e altri siti su OSGi , ma non vedo davvero il quadro generale. Dice che è una piattaforma basata su componenti e che è possibile ricaricare i moduli in fase di esecuzione. Anche l '"esempio pratico" fornito dappertutto è il Eclipse Plugin Framework.

Le mie domande sono:

1. Qual è la definizione chiara e semplice di OSGi?

2. Quali problemi comuni risolve?

Per "problemi comuni" intendo problemi che affrontiamo ogni giorno, come "Cosa può fare OSGi per rendere i nostri lavori più efficienti / divertenti / semplici?"

quali vantaggi offre il sistema di componenti OSGi?
Bene, ecco un bel elenco:

Complessità ridotta - Sviluppare con la tecnologia OSGi significa sviluppare bundle: i componenti OSGi. I pacchetti sono moduli. Nascondono i loro interni da altri gruppi e comunicano attraverso servizi ben definiti. Nascondere gli interni significa più libertà di cambiare in seguito. Ciò non solo riduce il numero di bug, ma semplifica anche lo sviluppo di bundle perché bundle di dimensioni corrette implementano una funzionalità attraverso interfacce ben definite. C'è un blog interessante che descrive cosa ha fatto la tecnologia OSGi per il suo processo di sviluppo.

Riutilizzo: il modello dei componenti OSGi semplifica l'utilizzo di numerosi componenti di terze parti in un'applicazione. Un numero crescente di progetti open source fornisce i propri JAR pronti per OSGi. Tuttavia, le librerie commerciali stanno diventando disponibili anche come pacchetti già pronti.

Mondo reale -Il framework OSGi è dinamico. Può aggiornare i bundle al volo e i servizi possono andare e venire. Gli sviluppatori abituati a Java più tradizionali vedono questa come una caratteristica molto problematica e non vedono il vantaggio. Tuttavia, si scopre che il mondo reale è altamente dinamico e con servizi dinamici che possono andare e venire, i servizi si abbinano perfettamente a molti scenari del mondo reale. Ad esempio, un servizio potrebbe modellare un dispositivo nella rete. Se viene rilevato il dispositivo, il servizio è registrato. Se il dispositivo scompare, il servizio non è registrato. Ci sono un numero sorprendente di scenari del mondo reale che corrispondono a questo modello di servizio dinamico. Le applicazioni possono quindi riutilizzare le potenti primitive del registro dei servizi (registrarsi, ottenere, elencare con un linguaggio di filtro espressivo e attendere che i servizi appaiano e scompaiano) nel proprio dominio. Ciò non solo consente di risparmiare la scrittura del codice, ma fornisce anche visibilità globale, strumenti di debug e più funzionalità di quelle che sarebbero state implementate per una soluzione dedicata. Scrivere codice in un ambiente così dinamico sembra un incubo, ma fortunatamente ci sono classi di supporto e framework che eliminano la maggior parte, se non tutta, del dolore.

Facile implementazione - La tecnologia OSGi non è solo uno standard per i componenti. Specifica inoltre come vengono installati e gestiti i componenti. Questa API è stata utilizzata da molti bundle per fornire un agente di gestione. Questo agente di gestione può essere semplice come una shell dei comandi, un driver di protocollo di gestione TR-69, un driver di protocollo OMA DM, un'interfaccia di cloud computing per EC2 di Amazon o un sistema di gestione IBM Tivoli. L'API di gestione standardizzata semplifica l'integrazione della tecnologia OSGi nei sistemi esistenti e futuri.

Aggiornamenti dinamici : il modello di componente OSGi è un modello dinamico. I pacchetti possono essere installati, avviati, arrestati, aggiornati e disinstallati senza arrestare l'intero sistema. Molti sviluppatori Java non credono che ciò possa essere fatto in modo affidabile e quindi inizialmente non lo usano nella produzione. Tuttavia, dopo averlo usato nello sviluppo per un po 'di tempo, la maggior parte inizia a capire che funziona davvero e riduce significativamente i tempi di implementazione.

Adattivo: il modello di componente OSGi è progettato da zero per consentire la miscelazione e l'abbinamento dei componenti. Ciò richiede che le dipendenze dei componenti debbano essere specificate e che i componenti vivano in un ambiente in cui le loro dipendenze opzionali non sono sempre disponibili. Il registro dei servizi OSGi è un registro dinamico in cui i bundle possono registrare, ottenere e ascoltare i servizi. Questo modello di servizio dinamico consente ai bundle di scoprire quali funzionalità sono disponibili sul sistema e di adattare la funzionalità che possono fornire. Questo rende il codice più flessibile e resistente alle modifiche.

Trasparenza: pacchetti e servizi sono cittadini di prima classe nell'ambiente OSGi. L'API di gestione fornisce l'accesso allo stato interno di un pacchetto e al modo in cui è collegato ad altri pacchetti. Ad esempio, la maggior parte dei framework fornisce una shell dei comandi che mostra questo stato interno. Alcune parti delle applicazioni possono essere arrestate per eseguire il debug di un determinato problema, oppure possono essere inseriti bundle diagnostici. Invece di fissare milioni di righe di output di registrazione e lunghi tempi di riavvio, le applicazioni OSGi possono spesso essere sottoposte a debug con una shell dei comandi live.

Controllo delle versioni: la tecnologia OSGi risolve l'inferno JAR. JAR inferno è il problema che la libreria A funziona con la libreria B; versione = 2, ma la libreria C può funzionare solo con B; versione = 3. In Java standard, sei sfortunato. Nell'ambiente OSGi, tutti i bundle sono attentamente controllati e solo i bundle che possono collaborare sono collegati nello stesso spazio di classe. Ciò consente a entrambi i bundle A e C di funzionare con la propria libreria. Sebbene non sia consigliabile progettare sistemi con questo problema di versione, in alcuni casi può essere un salvavita.

Semplice: l'API OSGi è sorprendentemente semplice. L'API principale è solo un pacchetto e meno di 30 classi / interfacce. Questa API principale è sufficiente per scrivere bundle, installarli, avviarli, arrestarli, aggiornarli e disinstallarli e include tutti i listener e le classi di sicurezza. Esistono pochissime API che offrono così tante funzionalità per così poche API.

Piccolo: OSGi Release 4 Framework può essere implementato in un file JAR di circa 300 KB. Questo è un piccolo sovraccarico per la quantità di funzionalità che viene aggiunta a un'applicazione includendo OSGi. OSGi funziona quindi su una vasta gamma di dispositivi: da molto piccoli, a piccoli, ai mainframe. Richiede solo l'esecuzione di una VM Java minima e aggiunge molto poco.

Veloce : una delle responsabilità principali del framework OSGi è il caricamento delle classi dai bundle. Nella Java tradizionale, i JAR sono completamente visibili e inseriti in un elenco lineare. La ricerca di una classe richiede la ricerca in questo elenco (spesso molto lungo, 150 non è insolito). Al contrario, OSGi precabla i bundle e conosce esattamente per ciascun bundle quale bundle fornisce la classe. Questa mancanza di ricerca è un fattore di accelerazione significativo all'avvio.

Lazy - Lazy in software è buono e la tecnologia OSGi ha molti meccanismi in atto per fare le cose solo quando sono realmente necessarie. Ad esempio, i bundle possono essere avviati con entusiasmo, ma possono anche essere configurati per avviarsi solo quando altri bundle li utilizzano. I servizi possono essere registrati, ma creati solo quando vengono utilizzati. Le specifiche sono state ottimizzate più volte per consentire questo tipo di scenari pigri che possono far risparmiare enormi costi di runtime.

Sicuro: Java ha un potente modello di sicurezza a grana fine nella parte inferiore, ma in pratica si è rivelato molto difficile da configurare. Il risultato è che la maggior parte delle applicazioni Java sicure sono in esecuzione con una scelta binaria: nessuna sicurezza o funzionalità molto limitate. Il modello di sicurezza OSGi sfrutta il modello di sicurezza a grana fine ma migliora l'usabilità (oltre a rafforzare il modello originale) facendo in modo che lo sviluppatore del bundle specifichi i dettagli di sicurezza richiesti in una forma facilmente verificabile mentre l'operatore dell'ambiente rimane pienamente responsabile. Nel complesso, OSGi fornisce probabilmente uno degli ambienti applicativi più sicuri che è ancora utilizzabile a corto di piattaforme informatiche protette dall'hardware.

Non intrusivo: le applicazioni (bundle) in un ambiente OSGi sono lasciate a se stesse. Possono utilizzare praticamente qualsiasi struttura della VM senza che OSGi le limiti. La migliore pratica in OSGi è scrivere oggetti Java vecchi semplici e per questo motivo non è necessaria un'interfaccia speciale per i servizi OSGi, anche un oggetto String Java può fungere da servizio OSGi. Questa strategia semplifica il porting del codice dell'applicazione in un altro ambiente.

Corre ovunque - Beh, dipende. L'obiettivo originale di Java era correre ovunque. Ovviamente, non è possibile eseguire tutto il codice ovunque perché le capacità delle VM Java sono diverse. Una VM in un telefono cellulare probabilmente non supporterà le stesse librerie di un mainframe IBM che esegue un'applicazione bancaria. Ci sono due problemi da affrontare. Innanzitutto, le API OSGi non devono utilizzare classi che non sono disponibili in tutti gli ambienti. In secondo luogo, un pacchetto non dovrebbe iniziare se contiene codice che non è disponibile nell'ambiente di esecuzione. Entrambi questi problemi sono stati risolti nelle specifiche OSGi.

Fonte: www.osgi.org/Technology/WhyOSGi

Ho riscontrato i seguenti vantaggi da OSGi:

• Ogni plug-in è un artefatto con versione che ha il proprio classloader.
• Ogni plug-in dipende da entrambi i barattoli specifici che contiene e anche da altri plug-in con versione specifica.
• A causa del versioning e dei classloader isolati, è possibile caricare contemporaneamente versioni diverse dello stesso artefatto. Se un componente dell'applicazione si basa su una versione di un plug-in e un altro dipende da un'altra versione, è possibile caricarli entrambi contemporaneamente.

Con questo, puoi strutturare la tua applicazione come un insieme di artefatti plug-in con versione caricati su richiesta. Ogni plugin è un componente autonomo. Proprio come Maven ti aiuta a strutturare la tua build in modo che sia ripetibile e definita da una serie di versioni specifiche di artefatti da cui è stata creata, OSGi ti aiuta a farlo in fase di esecuzione.

Non mi interessa troppo della hot plug dei moduli OSGi (almeno al momento). È più la modularità forzata. Non avere milioni di classi "pubbliche" disponibili sul percorso di classe in qualsiasi momento protegge bene dalle dipendenze circolari: devi davvero pensare alle tue interfacce pubbliche - non solo in termini di costrutto del linguaggio java "pubblico", ma in termini di libreria / module: quali (esattamente) sono i componenti che vuoi rendere disponibili per gli altri? Quali (esattamente) sono le interfacce (di altri moduli) di cui hai veramente bisogno per implementare la tua funzionalità?

È bello, questo hotplug lo accompagna, ma preferirei riavviare le mie solite applicazioni piuttosto che testare tutte le combinazioni di hotplugability ...

• Analogamente, puoi cambiare il motore della tua auto senza spegnerlo.
• È possibile personalizzare sistemi complessi per i clienti. Guarda il potere di Eclipse.
• È possibile riutilizzare interi componenti. Meglio dei semplici oggetti.
• Si utilizza una piattaforma stabile per sviluppare applicazioni basate su componenti. I vantaggi di questo sono enormi.
• È possibile creare componenti con il concetto di scatola nera. Altri componenti non hanno bisogno di conoscere le interfacce nascoste, vedono solo le interfacce pubblicate.
• È possibile utilizzare nello stesso sistema più componenti uguali, ma in versioni diverse, senza compromettere l'applicazione. OSGi risolve il problema di Jar Hell.
• Con OSGi sviluppi il pensiero di progettare sistemi con CBD

Ci sono molti vantaggi (ho ricordato solo questi ora), disponibili per tutti coloro che usano Java.

modificato per chiarezza. La pagina OSGi ha dato una risposta semplice migliore della mia

Una risposta semplice: una piattaforma di servizio OSGi fornisce un ambiente di elaborazione standardizzato e orientato ai componenti per i servizi di rete cooperanti. Questa architettura riduce significativamente la complessità complessiva della costruzione, della manutenzione e della distribuzione di applicazioni. La piattaforma di servizio OSGi fornisce le funzioni per modificare dinamicamente la composizione sul dispositivo di una varietà di reti, senza richiedere il riavvio.

In una singola struttura di applicazione, ad esempio l'IDE Eclipse, non è un grosso problema riavviare quando si installa un nuovo plugin. Utilizzando completamente l'implementazione di OSGi, dovresti essere in grado di aggiungere plug-in in fase di esecuzione, ottenere le nuove funzionalità, ma non è necessario riavviare eclissi.

Ancora una volta, non è un grosso problema per tutti i giorni, l'uso di piccole applicazioni.

Ma quando inizi a guardare i framework di applicazioni distribuite multi-computer, è lì che inizia a diventare interessante. Quando devi avere il 100% di uptime per i sistemi critici, è utile la capacità di sostituire i componenti o aggiungere nuove funzionalità in fase di runtime. Certo, ci sono capacità per farlo ora per la maggior parte, ma OSGi sta cercando di raggruppare tutto in un piccolo framework piacevole con interfacce comuni.

OSGi risolve i problemi più comuni, non ne sono sicuro. Voglio dire, può, ma il sovraccarico potrebbe non valerne la pena per problemi più semplici. Ma è qualcosa da considerare quando si inizia a gestire applicazioni più grandi, collegate in rete.

Alcune cose che mi fanno impazzire su OSGi:

1) Le protesi e i loro caricatori di contesto hanno molte stranezze e possono essere in qualche modo asincroni (usiamo felix all'interno della confluenza). Rispetto a una molla pura (senza DM) in cui [main] sta praticamente attraversando tutto sincronizzato.

2) Le classi non sono uguali dopo un carico caldo. Supponiamo, ad esempio, che tu abbia uno strato di cache tangosol in ibernazione. È riempito con Fork.class, al di fuori dell'ambito OSGi. Carichi un nuovo barattolo e Fork non è cambiato. Class [Fork]! = Class [Fork]. Appare anche durante la serializzazione, per le stesse cause sottostanti.

3) Clustering.

Puoi aggirare queste cose, ma è un grande dolore e rende la tua architettura difettosa.

E a quelli di voi che pubblicizzano il hotplugging. Il client n. 1 di OSGi? Eclisse. Cosa fa Eclipse dopo aver caricato il bundle?

Si riavvia.

OSGi lancia il tuo codice NoClassDefFoundErrore ClassNotFoundExceptionsenza motivo apparente (molto probabilmente perché hai dimenticato di esportare un pacchetto nel file di configurazione di OSGi); dal momento che ha ClassLoaders, è possibile che la classe com.example.Foonon riesca a essere lanciata com.example.Foopoiché in realtà sono due classi diverse caricate da due diversi programmi di caricamento classi. Può eseguire l'avvio Eclipse in una console OSGi dopo l'installazione di un plug-in Eclipse.

Per me, OSGi ha solo aggiunto complessità (perché ha aggiunto un altro modello mentale per me al grok), ha aggiunto fastidi a causa delle eccezioni; Non ho mai avuto davvero bisogno della dinamicità che "offre". Era invadente poiché richiedeva la configurazione del bundle OSGi per tutti i moduli; non era assolutamente semplice (in un progetto più ampio).

A causa della mia brutta esperienza, tendo a stare lontano da quel mostro, grazie mille. Preferirei soffrire dell'inferno della dipendenza da barattolo, dal momento che è molto più facilmente comprensibile dell'inferno OSGi di Classloader.

Devo ancora essere un "fan" di OSGi ...

Ho lavorato con un'applicazione enterprise presso aziende Fortune 100. Di recente, il prodotto che utilizziamo è "aggiornato" a un'implementazione OSGi.

avvio della distribuzione cba locale ... [18/02/14 8: 47: 23: 727 EST] 00000347 CheckForOasis

infine distribuito e "i seguenti bundle verranno sospesi e quindi riavviati" [18/02/14 9: 38: 33: 108 EST] 00000143 AriesApplicat I CWSAI0054I: Come parte di un'operazione di aggiornamento per l'applicazione

51 minuti ... ogni volta che il codice cambia ... La versione precedente (non OSGi) verrebbe distribuita in meno di 5 minuti su macchine di sviluppo meno recenti.

su una macchina con 16 gig ram e 40 gig gig disk gratuiti e CPU Intel i5-3437U da 1,9 GHz

Il "vantaggio" di questo aggiornamento è stato venduto come implementazioni migliorative (di produzione), un'attività che facciamo circa 4 volte l'anno con forse 2-4 implementazioni di piccole correzioni all'anno. Aggiungendo 45 minuti al giorno a 15 persone (QA e sviluppatori) non riesco a immaginare di essere mai giustificato. Nelle grandi applicazioni aziendali, se la tua applicazione è un'applicazione di base, allora cambiarla è, giustamente (piccoli cambiamenti hanno un potenziale di impatto di vasta portata - devono essere comunicati e pianificati con i consumatori di tutta l'azienda), un'attività monumentale - architettura sbagliata per OSGi. Se la tua applicazione non è un'applicazione aziendale, vale a dire che ogni consumatore può avere il proprio modulo su misura probabilmente colpendo il proprio silo di dati nel proprio database di silo e in esecuzione su un server che ospita molte applicazioni, quindi forse guardare OSGi. Almeno,

Se un'applicazione basata su Java richiede l'aggiunta o la rimozione di moduli (estensione della funzionalità di base dell'applicazione), senza arrestare la JVM, è possibile utilizzare OSGI. Di solito, se il costo della chiusura di JVM è maggiore, solo per aggiornare o migliorare la funzionalità.

Esempi :

1. Eclipse : fornisce la piattaforma per l'installazione, la disinstallazione, l'aggiornamento e l'inter-dipendenza dei plug-in.
2. AEM : applicazione WCM, in cui il cambiamento di funzionalità sarà guidato dal business, che non può permettersi tempi di inattività per la manutenzione.

Nota : il framework Spring ha smesso di supportare i bundle di primavera OSGI, considerandolo una complessità non necessaria per le applicazioni basate sulle transazioni o per qualche punto in queste righe. Personalmente non considero OSGI a meno che non sia assolutamente necessario, in qualcosa di grande come la costruzione di una piattaforma.

Lavoro con OSGi da circa 8 anni e devo dire che dovresti prendere in considerazione OSGi solo se hai bisogno di aggiornare, rimuovere, installare o sostituire un componente in fase di esecuzione. Questo significa anche che dovresti avere una mentalità modulare e capire cosa significa modularità. Ci sono alcuni argomenti secondo cui OSGi è leggero: sì, è vero, ma ci sono anche altri framework leggeri, facili da gestire e sviluppare. Lo stesso vale per garantire java blah blah.

OSGi richiede che un'architettura solida sia utilizzata correttamente ed è abbastanza facile creare un sistema OSGi che potrebbe essere altrettanto facilmente un vaso eseguibile autonomo senza che OSGi sia coinvolto.

OSGi offre i seguenti vantaggi:

■ Un ambiente di esecuzione portatile e sicuro basato su Java

■ Un sistema di gestione dei servizi, che può essere utilizzato per registrare e condividere servizi tra bundle e separare i fornitori di servizi dai consumatori di servizi

■ Un sistema di moduli dinamici, che può essere utilizzato per installare e disinstallare dinamicamente i moduli Java, che OSGi chiama bundle

■ Una soluzione leggera e scalabile

Viene anche utilizzato per offrire ulteriore portabilità di middleware e applicazioni sul lato mobile. Il lato mobile è disponibile ad esempio per WinMo, Symbian, Android. Non appena si verifica l'integrazione con le funzionalità del dispositivo, può essere frammentato.

Per lo meno, OSGi ti PENSA sulla modularità, il riutilizzo del codice, il controllo delle versioni e in generale l'impianto idraulico di un progetto.

Altri hanno già delineato i vantaggi in dettaglio, con la presente spiego i casi d'uso pratici che ho visto o utilizzato OSGi.

1. In una delle nostre applicazioni, abbiamo un flusso basato sugli eventi e il flusso è definito nei plugin basati sulla piattaforma OSGi, quindi domani se un client desidera un flusso diverso / aggiuntivo, deve solo distribuire un altro plug-in, configurarlo dalla nostra console e il gioco è fatto .
2. Viene utilizzato per distribuire diversi connettori Store, ad esempio supponiamo che abbiamo già un connettore Oracle DB e che domani sia necessario connettere mongodb, quindi scrivere un nuovo connettore e distribuirlo e configurare i dettagli tramite console e ancora una volta fatto. la distribuzione dei connnettori è gestita dal framework dei plugin OSGi.

C'è già una dichiarazione abbastanza convincente nel suo sito ufficiale, posso citare come

Il motivo principale per cui la tecnologia OSGi ha così tanto successo è che fornisce un sistema di componenti molto maturo che funziona effettivamente in un numero sorprendente di ambienti. Il sistema di componenti OSGi viene effettivamente utilizzato per creare applicazioni altamente complesse come IDE (Eclipse), server applicazioni (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), framework applicativi (Spring, Guice), automazione industriale, gateway residenziali, telefoni e molto altro ancora.

Per quanto riguarda i vantaggi per gli sviluppatori?

SVILUPPATORI: OSGi riduce la complessità fornendo un'architettura modulare per i sistemi distribuiti su larga scala odierni nonché per le piccole applicazioni integrate. La creazione di sistemi da moduli interni e standard riduce significativamente la complessità e quindi le spese di sviluppo e manutenzione. Il modello di programmazione OSGi mantiene la promessa di sistemi basati su componenti.

Si prega di controllare i dettagli in Vantaggi dell'utilizzo di OSGi .