OSGi vs jboss hot deploy

Question

Da quanto ho capito, in OSGi è possibile aggiornare i file jar in fase di runtime senza riavviare il server. Ma jboss ha anche una distribuzione a caldo in cui l'orecchio intero viene aggiornato e il server è ancora in esecuzione.

Quindi quali sarebbero i vantaggi di OSGi in un progetto java aziendale in jboss?

Answer 1

Credo che la risposta sia la stessa di ogni caso d'uso OSGi: modularità e granularità di aggiornamento più fine.

OSGi è molto più che aggiornare i vasi in fase di esecuzione senza riavviare il server. Dal punto di vista della tua domanda, sta aggiornando i file in fase di runtime senza riavviare l'applicazione .

Ammetto che non conosco la particolare implementazione della distribuzione a caldo di EAR in JBoss AS, ma in ogni caso l'aggiornamento EAR non può essere progettato in modo tale da preservare l'intero stato dell'applicazione. Il server è ancora in esecuzione, ma in pratica si riavvia l'applicazione al momento dell'aggiornamento. Il grado di tale perdita di stato dipende in realtà da come si progetta la propria applicazione, ma rimane il fatto che si stanno facendo cose in modo monolitico.

Con OSGi questo non è il caso: l'applicazione è composta da un ampio set di pacchetti, ognuno dei quali è progettato per gestire una parte separata della funzionalità. Questo approccio abilita la distribuzione a caldo all'interno dell'applicazione, poiché il framework è progettato per considerare l'effetto che il riavvio di un singolo jar porta all'applicazione nel suo complesso e consentire agli altri vasi di reagire in modo appropriato. Ciò offre la possibilità di preservare il più possibile lo stato dell'applicazione.

Quindi i vantaggi di un design OSGi nel caso Enterprise sono la vivacità dell'applicazione. Non c'è bisogno di sottolineare l'importanza di ciò. Veramente, ci sono casi d'uso in cui l'applicazione può essere riavviata in sicurezza. Ma OSGi, a mio parere, è l'unica scelta realmente scalabile e gestibile per Java EE al giorno d'oggi. Il fatto che i server applicativi più importanti siano stati spostati (o stanno andando) su un runtime OSGi (e di conseguenza il supporto dell'applicazione OSGi) ne è la prova.

Answer 2

l10i ha scritto: Con OSGi questo non è il caso: l'applicazione è composta da una vasta serie di pacchetti, ognuno dei quali è stato progettato per gestire una parte separata della funzionalità. Questo approccio abilita la distribuzione a caldo all'interno dell'applicazione, poiché il framework è progettato per considerare l'effetto che il riavvio di un singolo jar porta all'applicazione nel suo complesso e consentire agli altri vasi di reagire in modo appropriato. Ciò offre la possibilità di preservare il più possibile lo stato dell'applicazione.

Solo per approfondire ulteriormente, le migliori applicazioni OSGi sono applicazioni orientate ai servizi che si integrano tramite il registro dei servizi OSGi. Questo registro di servizio è dinamico, i servizi possono andare e venire in qualsiasi momento e i clienti dei servizi OSGi reagiscono in modo appropriato a questa dinamica. Quindi supponiamo che la tua applicazione sia composta da un numero di pacchetti, incluso un pacchetto che utilizza un servizio di pagamento (ad esempio per gestire i pagamenti con carta di credito) e un altro pacchetto che fornisce tale servizio di pagamento. Se ti trovi in ​​una situazione in cui il servizio di pagamento deve essere aggiornato (perché hai una soluzione critica o forse hai trovato un fornitore più economico, ecc.) Puoi aggiornare questo servizio di pagamento senza nemmeno togliere gli utenti di questo servizio. Per raggiungere questo obiettivo, è possibile aggiornare il pacchetto di servizi di pagamento stesso, ma ciò che vorrei raccomandare in questo caso è installare la nuova versione del pacchetto di servizi di pagamento accanto alla versione precedente della. Questo è possibile perché OSGi consente di coesistere più versioni dello stesso pacchetto. Quindi, una volta che il nuovo bundle è attivo e funzionante, è possibile rimuovere il vecchio pacchetto di servizi di pagamento, a quel punto i consumatori si gireranno automaticamente per utilizzare quelli nuovi, per gentile concessione del registro dei servizi OSGi.

Un'architettura simile all'esempio precedente è davvero potente e ottima per garantire che le applicazioni aziendali rimangano attive, e può essere realizzata utilizzando i servizi OSGi combinati con la possibilità di installare, disinstallare o aggiornare in modo dinamico i bundle OSGi.

BTW c'è un po 'più di dettaglio nell'esempio sopra in quanto i pacchetti possono anche essere scritti per utilizzare tutti i servizi di un tipo particolare - ciò che è meglio per voi dipende dalla vostra situazione.

Esistono diversi modi per utilizzare il registro del servizio OSGi, che è possibile utilizzare con lo ServiceTracker API, che è piuttosto di basso livello. Nella maggior parte dei casi è preferibile utilizzare un framework per questo come OSGi Declarative Services (DS), OSGi Blueprint o altri framework. Nella maggior parte dei casi questi framework funzionano tramite l'iniezione e gestiscono la dinamica del registro dei servizi OSGi. Per informazioni su DS o Blueprint, vedere OSGi 4.2 Enterprise Specification.