Il nostro team costruisce e possiede un framework di servizi web. Altri team che effettivamente creano i servizi web utilizzano il nostro framework per alcune funzionalità comuni. Ci sono due opzioni per confezionare l'EAR. L'opzione 1 prevede che tutti i vasi framework siano integrati nell'AER. L'opzione 2 consiste nel configurare una libreria condivisa nel server delle applicazioni e fare in modo che tutte le applicazioni utilizzino la libreria. Abbiamo un potenziale di fino a 100 EARS distribuiti, che utilizzeranno questa struttura. Quali sono alcuni vantaggi e svantaggi di questo approccio in termini di costruzione, gestibilità e sviluppo. Stiamo usando websphere.Pro e contro dell'uso della libreria condivisa rispetto a EAR completamente incapsulata
risposta
Il compromesso di base è il consumo di memoria rispetto alla gestione della versione.
Se si raggruppano le librerie in un EAR, ciascuna applicazione creerà le proprie istanze di classe, consumando una certa quantità di permgen (o equivalente) e occupando spazio heap per i dati statici.
Se si memorizza una libreria nella directory lib dell'applicazione, quindi ci sarà solo un'istanza di ogni classe. Tuttavia, ciò significa che ciascuna delle applicazioni che utilizzano quella libreria deve utilizzare la stessa versione e (a meno che non sia assicurata la compatibilità con le versioni precedenti) deve essere aggiornata allo stesso tempo.
Dato che stai parlando di 100 EAR, il problema di gestione delle versioni probabilmente sarà grande. A meno che la tua libreria non sia assolutamente enorme (e presumo che tu stia girando su un server a 64 bit con molta memoria, quindi rendilo ENORME), o non cambierà mai (improbabile), suggerirei la confezione con l'EAR.
"libreria condivisa" non deve significare mettere nella directory lib dell'app, c'è anche la capacità libararia condivisa di WebSphere. Ciò consente di allocare diverse versioni della lib a diverse app – djna
Suggerirei anche l'imballaggio con l'EAR. Ad kdgregory ha sottolineato la gestione di centinaia di programmi e la quantità di test implicita dagli aggiornamenti diventa scoraggiante; inoltre è necessario utilizzare un sistema di controllo delle versioni per gestire le istanze dei file binari da utilizzare per i client.
Invece di inserire i comuni vasi in lib/app, è possibile utilizzare la funzione di libreria condivisa di WebSphere. Ciò consente di assegnare diverse versioni della stessa libreria condivisa a diverse applicazioni, consentendo quindi una certa flessibilità per le versioni di msnsging.
I vari approcci di condivisione tendono a condurre alcune complessità, è necessario studiare attentamente i partecipanti alla classe.
La mia preferenza sarebbe quella di stare in chiaro, vanigliare, impacchettare tutto nell'EAR. Questo è Java EE semplice e diretto. Ogni app può scegliere il proprio tasso di adozione della versione del framework.
Fare riferimento a Chiavi L'articolo di Botzum sulla confezione common code.
Un'altra cosa da notare è che se si desidera condividere istanze di oggetti tra EAR, ad es. usando il dynamics di websphere, le classi per questi oggetti dovranno essere caricate da librerie condivise. (altrimenti, anche se potrebbero essere della stessa classe/versione, saranno caricati da diversi classloader e non compatibili)
Di solito vado anche con l'approccio plain-vanilla "tutto in EAR", ma poi faccio eccezioni per cose che devono essere condivise, e mettere quelle classi in un JAR condiviso speciale.
Informazioni sulla condivisione di istanze di oggetti tra EAR: questo può essere aggirato memorizzando la rappresentazione di array di byte delle istanze su DynaCache, invece dell'istanza stessa. Non andrei lì se l'accesso a DynaCache è troppo frequente e gli oggetti sono troppo grandi, comunque. – Isaac
Sono d'accordo con (quasi) tutto ciò che è stato scritto su questo argomento prima: a meno che non si abbia una buona ragione per non andare avanti, impacchettare tutte le librerie nell'AER e godere del beneficio di EAR autonome e autonome.
Tuttavia,, notare che se la libreria di terze parti utilizza aree statiche per l'inizializzazione, allora si potrebbe desiderare di comprimerla in EAR dopo tutto. Un chiaro esempio è Log4J. Log4J si inizializza solo una volta per classloader. Pertanto, se desideri avere una configurazione Log4J diversa per EAR, non hai altra scelta che inserire il file JAR Log4J con ogni EAR. In caso contrario, il JAR Log4J verrà caricato con un classloader comune a tutti gli EAR, caricherà se stesso (e inizializzerà le proprie aree statiche) una volta e tale configurazione sarà effettiva per tutte le applicazioni che utilizzano Log4J.
Buona domanda. A volte, questa non è una questione di preferenza ma una questione di requisiti (ad esempio Log4J). Leggi la mia risposta per maggiori dettagli. – Isaac