Può OSGi aiuto ridurre la complessità?

Question

Ho visto un sacco di presentazioni su OSGi e penso che sembra promettente per far rispettare meglio modularizzazione. A quanto pare "hot deployment" e "in esecuzione diverse versioni di x in parallelo" sono sindaco punti di vendita anche.

Mi chiedo se ciò che OSGi promette di risolvere è nemmeno un problema ...? Mi ha ricordato i primi giorni di OO quando crediti analoghi sono stati cameriera:

Quando OO era nuovo, il grande argomento era riutilizzabilità. E 'stato ampiamente sostenuto che quando si utilizza OO, si dovrebbe solo "write once" e potrebbe quindi "usare ovunque".

In pratica ho visto solo questo lavoro per alcuni esempi piuttosto basso livello. Penso che la ragione di questo è che la scrittura di codice riutilizzabile è difficile. Non tecnicamente ma da un punto di vista della progettazione dell'interfaccia. Bisogna prevedere come futuri clienti vorranno utilizzare le classi e prendere le giuste scelte in attacco. Questo è difficile, per definizione, e quindi il potenziale beneficio riusabilità spesso non è riuscita a fornire.

Con OSGi , ho il sospetto che qui potremmo cadere per le promesse, potenziali soluzioni per problemi che in realtà non hanno. O se li abbiamo, noi non li hanno in una grande quantità e la gravità tale da giustificare comprare in OSGi per chiedere aiuto a sufficienza. "Hot deployment" per esempio di un sottoinsieme di moduli è sicuramente una grande idea, ma come spesso ci si davvero di lavoro? Quante volte non perché si è scoperto che hai sbagliato la modularizzazione per il rilascio particolare? Che ne dite di entità del modello che sono condivisi tra più moduli? Fare questi tutti i moduli devono essere sostituiti, allo stesso tempo? O ti appiattire l'oggetti primitivi e utilizzare solo quelli in comunicazione tra moduli, in modo da essere in grado di mantenere i contratti di interfaccia?

Il problema più difficile Quando si applica OSGi è, vorrei presumere, per ottenere la modularizzazione "giusto" . Simile a ottenere le interfacce delle classi proprio in OO, con OSGi, i soggiorni problema lo stesso, su una scala più grande questa volta, il pacchetto o livello di servizio ancora.

Come si può immaginare, Attualmente sto cercando di valutare OSGi per l'utilizzo in un progetto. Il problema principale che abbiamo, aumenta la complessità come la base di codice cresce e desidero rompere il sistema in moduli più piccoli che sono meno interazioni e più definite.

• Dato alcun quadro potrà mai aiuto per decidere cosa per rendere modulare, è OSGi mai pagato fuori per voi?
• Ha ha reso la vita più facile quando si lavora in team?
• Ha ha contribuito a ridurre il numero di bug?
• Hai mai successo "hotdeploy" componenti principali?
• non OSGi aiuto per ridurre la complessità nel corso del tempo?
• Ha OSGi a mantenere le sue promesse?
• Ha fatto soddisfare le vostre aspettative?

Grazie!

Answer 1

OSGi paga perché impone modularizzazione in fase di esecuzione, cosa che in precedenza non aveva, causando spesso il disegno su carta e la realizzazione di allontanarsi. Questo può essere una grande vittoria durante lo sviluppo.

E 'sicuramente aiuta a rendere più facile il lavoro in team, se si lascia che le squadre si concentrano su un singolo modulo (possibilmente un insieme di fasci), e se si ottiene il vostro diritto modularizzazione. Si potrebbe sostenere che si può fare la stessa cosa con un tool di creazione come Ant + Ivy o Maven e le dipendenze, la granularità delle dipendenze che OSGi utilizza è a mio parere di gran lunga superiore, non provocando il tipico "trascinando in ogni cosa più il lavello della cucina" che le dipendenze di livello JAR causa.

Codice modulare con meno dipendenze tende a portare a più pulito e meno codice, a sua volta, portando a meno bug che sono più facili da testare e risolvere. Promuove anche progettare componenti come semplice e diretto possibile, mentre allo stesso tempo avere l'opzione di presa in implementazioni più complicate, o aggiungendo aspetti come la cache come componenti separati.

distribuzione calda, anche se non ne fanno uso in fase di esecuzione, è un ottimo test per convalidare se modulare correttamente la vostra applicazione. Se non è possibile avviare i vostri pacchi in un ordine casuale a tutti, si dovrebbe indagare il perché. Inoltre, può rendere il vostro ciclo di sviluppo molto più veloce se si può aggiornare un pacchetto arbitrario.

Fino a quando è possibile gestire i moduli e le dipendenze, grandi progetti rimanere gestibile e può essere facilmente evoluti (risparmiando dal discutibilmente cattivo "completa riscrittura").

Il lato negativo di OSGi? E 'un quadro di livello molto basso, e mentre risolve i problemi è destinato abbastanza bene, ci sono cose che hai ancora bisogno di risolvere da soli. Soprattutto se si proviene da un ambiente Java EE, dove si ottiene gratuitamente thread-sicurezza e alcuni altri concetti che possono essere molto utili se ne avete bisogno, è necessario trovare soluzioni per questi in OSGi te stesso.

Un errore comune è di non usare astrazioni in cima OSGi per rendere questo più facile per lo sviluppatore medio. Mai e poi mai far loro pasticciare con ServiceListeners o ServiceTrackers manualmente. considerare con attenzione ciò fasci sono e non sono autorizzati a fare:. Siete disposti a fornire agli sviluppatori l'accesso alla BundleContext o ti nascondi tutto questo da loro utilizzando una qualche forma di modello dichiarativo

Answer 2

Ho lavorato con OSGi da alcuni anni (anche se nel contesto di un progetto Eclipse, non in un progetto web). E 'chiaro che il quadro non ti libera dalla pensare a come rendere modulare. Ma consente di definire le regole.

Se si utilizzano pacchetti e definisce (In un documento di progettazione? Verbale?) Che alcuni pacchetti potrebbero non classi di accesso in altri pacchetti, senza un controllo dell'applicazione del presente vincolo, sarà rotto. Se assumete nuovi sviluppatori non conoscono le regole. Saranno rompere le regole. Con OSGi è possibile definire le regole in codice. Per noi questa è stata una grande vittoria, perché ci ha aiutato a mantenere l'architettura del nostro sistema.

OSGi non riduce la complessità. Ma sicuramente aiuta a gestire la cosa.

Answer 3

Sto usando OSGI per oltre 8 anni, e ogni volta che mi tuffo in un progetto non-OSGI ho la sensazione sopra fuorigiri senza cintura di sicurezza su. OSGI rende la configurazione di progetto e la distribuzione di più, e ti costringe a pensare a modularizzazione in anticipo, ma ti dà la facilità d'animo di far rispettare le norme in fase di esecuzione. Prendere Maven apache cammello come esempio. Quando si crea un nuovo progetto Maven e aggiungere apache cammello come una dipendenza, le applicazioni sembra avere tutte le sue dipendenze, e si noterà solo i ClassNotFoundExceptions in fase di esecuzione, che è male. Quando si esegue in un contenitore OSGi e caricare il apache cammello moduli, i moduli con dipendenze non soddisfatte non sono iniziate, e si sa in anticipo quale sia il problema.

Ho anche utilizzare la vasca-distribuzione per tutto il tempo, e le parti aggiornamento della mia applicazione al volo, senza la necessità di un riavvio.

Answer 4

Ho usato OSGi in un progetto (lo ammetto - non molto). Esso fornisce buone promesse, ma come ha detto @Arne, è ancora bisogno di pensare da soli a come rendere modulare.

OSGI ha di aiuto il nostro progetto perché ha fatto l'architettura più stabile. Rompere il modularizzazione è più "difficile", così le decisioni che abbiamo fatto per quanto riguarda come rendere modulare rimase valido per un tempo più lungo.
Per dirla diversamente -., Senza OSGi, e sotto pressione di tempo per trasportare, a volte voi oi vostri membri del team di fare compromessi, scorciatoie e altri hack, e l'intento originale dell'architettura si perde

Quindi OSGI non ha ridotto la complessità di per sé, ma protetto dal crescere inutilmente nel corso del tempo. Credo che sia una buona cosa:)

Non ho usato la funzione di distribuzione caldo, quindi non posso commentare su questo.

Per rispondere alla tua ultimo punto, che ha soddisfatto le mie aspettative, ma è necessaria una curva di apprendimento e un po 'adattamento, e la vincita è solo per a lungo termine.

(come nota a margine, la sua domanda mi ricorda un po 'l'adagio che "Maven è l'AWT di sistemi di compilazione")

Answer 5

OSGi non paga. Il fatto è OSGi non è facile da usare e alla fine della giornata o l'anno a seconda di quanto tempo ci vuole per ottenere le cose di lavoro, non aggiunge valore:

• L'applicazione non sarà più modulare complesso, al contrario, finisce di essere più esposto e non isolata dalle altre applicazioni in quanto si tratta di una quota di tutto ciò, invece di arco quota di nulla.
• Versioning è spinto più in basso nello stack, è lottare con Maven transitiva dipendenze solo per fare ancora una volta che in fase di esecuzione in OSGi.
• La maggior parte delle librerie sono progettati per lavorare come biblioteche del classloader dell'applicazione non come bundle con un proprio programma di caricamento classe.
• Forse appropriato per plug-architetture per le quali devono essere sandbox sviluppatori di terze parti o forse è solo EJB2.0 tutto da capo.

ho aggiunto le seguenti diapositive e sarà la volta di codice di esempio per dimostrare come lavorare con successo con OSGi se è costretto su di voi. http://www.slideshare.net/ielian/tdd-on-osgi

Answer 6

No, OSGI vi farà grigio presto.