Quanto dovrebbe essere grande il bundle OSGi?

Question

Quanto dovrebbe essere grande il bundle OSGi?

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

7

O più completamente "Quali sono i trade-off e le domande che dovrebbero essere sollevate quando si tenta di decidere la struttura del bundle di un'applicazione OSGi?"

I nostri bundle OSGi esistenti tendevano a essere piuttosto grassi: fondamentalmente un bundle API e un bundle di implementazione, ma con molte funzionalità. Ciò ha dei vantaggi in termini di complessità del progetto e di costruzione, ma forse non ci dà tutta la riusabilità e la flessibilità che desideriamo.

Quindi, in un recente progetto, abbiamo intenzionalmente creato fasci piuttosto sottili. Abbiamo fatto una panoramica su questo AM e ci siamo chiesti se fossimo andati troppo oltre. In questo servizio abbastanza piccolo avevamo 7 bundle, molti dei quali avevano solo 1 dominio. La domanda sollevata era "Questo è quasi come se stessimo guidando verso un pacchetto per pacchetto, ma noi abbiamo classi e pacchetti già nella lingua, stiamo andando troppo oltre con la nostra granularità del bundle?"

Per renderlo concreto, questo è un servizio Web che esegue un calcolo sui risultati aggregati di altre query Web (in particolare, eseguiamo query su una serie di database astronomici per oggetti in una determinata area e quindi filtriamo i risultati in base alle nostre i propri criteri e quindi stimiamo una probabilità di un'osservazione adeguata in base ai risultati filtrati). Abbiamo finito con 7 bundle, che sembrano molto per quello che è essenzialmente "un servlet che esegue un calcolo."

Tale granularità è molto buona (molta flessibilità in fase di esecuzione) o cattiva (eccessivamente complicata)? Come possiamo sviluppare la nostra intuizione sulla granularità "giusta" dei nostri bundle OSGi?

design architecture

posta Larry OBrien 09.01.2012 - 22:52

fonte

3 risposte

Leggi altre domande sui tag design architecture

Perché le classi wrapper non sono adatte all'uso nei framework di callback? Dove dovremmo inserire le librerie esterne nel nostro SVN?

score 3 · Answer 1

Dato che finora non c'è stata alcuna risposta, lasciatemi solo darti un'idea di come mi avvicino di solito a questa questione. Per me, i bundle OSGi corrispondono approssimativamente ai componenti dell'architettura software e il fattore più importante nel trasformare o meno qualcosa nel proprio bundle è il valore di poterlo scambiare.

Ogni volta che puoi immaginare che una versione futura del tuo prodotto possa fare affidamento su un componente diverso che esegue le stesse attività (cioè la stessa interfaccia), ma lo fa in un modo diverso, trasformarlo in un pacchetto OSGi non è certamente 'il modo peggiore.

Un altro (anche se ovvio) punto è quando scrivi software che può essere esteso da altri aggiungendo i propri bundle.

Poiché tutto ciò suona piuttosto astratto, rendiamolo più concreto sulla base del tuo esempio:

si aggregano i risultati delle query Web. Non mi dispiacerebbe aggregare aggregatori per ogni database. Le probabilità sono che potrebbe essere necessario aggiungere in un altro database in qualche modo in fondo alla strada e si dovrebbe essere in grado di delegare facilmente tale attività ad altri dando loro un pacchetto esistente per un altro database e chiedere loro di aggiungerne uno nuovo nella scimmia scimmia-vedi -do modo.
filtri i risultati. I filtri sono una delle cose che tendono a cambiare molto spesso e, quindi, sono una scelta naturale per il raggruppamento in modo da poterli scambiare facilmente.

Per quanto riguarda i calcoli non ne so abbastanza, ma in generale non penso che 7 pacchetti siano troppo per quello che stai descrivendo.

C'è una cosa da tenere a mente: lo sforzo di creare così tanti pacchetti paga davvero solo quando si ha un prodotto su cui si lavora continuamente. Se nelle settimane successive / mesi / anni si aggiungeranno nuovi pacchetti dappertutto, una granularità fine faciliterà l'adattamento delle nuove funzionalità e la sostituzione di quelle vecchie.

Se invece dovresti riscrivere quasi tutto, perché il tuo prodotto riceve sempre aggiornamenti importanti che sembrano nuovi prodotti, quindi non guadagni comunque molto.

score 1 · Answer 2

Mantieni il più semplice possibile finché non hai bisogno della complessità. Ad esempio: non progettare i fasci finché non c'è un chiaro valore per averli. Il più semplice possibile ma non più semplice.

È improbabile che tu possa prevedere esattamente dove i tuoi bundle dovrebbero essere divisi in futuro e dove vorresti estendere ora. Sovraccoppiando, stai creando un mal di testa per la manutenzione per il futuro, una volta che hai un requisito per lo scambio di pacchetti.

score 1 · Answer 3

Uno dei maggiori vantaggi di OSGi è la creazione di dipendenze molto lente tra i tuoi componenti o servizi. Ciò ti consente di eseguire l'implementazione a caldo negli ambienti di produzione. Se si considera questo come un motivo chiave per l'utilizzo di OSGi, è opportuno raggruppare pacchetti che si ritiene debbano cambiare insieme. Se può essere modificato indipendentemente dal resto dell'applicazione, dovresti probabilmente inserirlo nel suo bundle. Il sovraccarico di creazione di un nuovo bundle è ragionevolmente basso, quindi non dovresti preoccuparti troppo di complicare eccessivamente il tuo sistema con più bundle.