Pro/contro a varie strategie di packaging Java

Question

Diciamo che sto scrivendo un backend Java per alcuni strumenti GUI (Swing) front-end. Questo back-end consisterà in molti tipi diversi di EJB per la logica middleware/business, nonché alcuni servizi Web che filtrano le richieste di inoltro su tali EJB da parte di &.

Per quanto riguarda l'imballaggio & distribuzione va, abbiamo diverse diverse strategie possibili:

• 1 monolitico EAR/1 appserver - pacchetto tutti gli EJB in barattoli, e servizi web in una guerra, ed il pacchetto tutti questi all'interno di 1 EAR monolitico; l'EAR viene quindi distribuito su un server di app (ad esempio GlassFish)
• Molte EAR minuscole/1 appserver - pacchetto di ciascun componente (ogni EJB e ogni servizio Web) nel proprio JAR/WAR e quindi ogni JAR/WAR in proprio EAR; quindi esiste un rapporto 1: 1 tra componente ed EAR; ogni orecchio viene poi distribuito al stessa applicazione server di
• Molte orecchie molto piccole/Molti appservers - come sopra, tranne che ogni orecchio "piccolo" viene distribuito al proprio application server; quindi non v'è un 1: correlazione 1 tra il server di componenti e applicazioni
• orecchie/Molti appservers - come sopra, tranne rimuovere il "intermediari" orecchie e basta distribuire ogni confezionato JAR/WAR alla propria appserver

Quali sono i pro/contro di ciascuna di queste 4 strategie? Sono un po 'più sicuri? Performante? Più favorevole per clustering/replicazione? Alcune di queste strategie sono semplicemente sciocche?!?

Grazie in anticipo!

Answer 1

Le applicazioni di imballaggio non hanno alcun impatto sulla sicurezza. Il numero di servizi esposti, i singoli server, gli endpoint di richiesta, ecc., Nonché il modo in cui i servizi accedono alle risorse che devono essere protette sono ciò che riguarda la sicurezza, non come qualcosa è pacchettizzato.

Detto questo, il problema principale che si sta esaminando qui è monolitico rispetto a modulare. Una volta compreso che è il problema principale, , tutta la letteratura esistente sui compromessi coinvolti è pertinente.

In particolare, si cercherà in:

1. Scalabilità - tanti piccoli pezzi sono più flessibili in scala, dal momento che è possibile scalare ogni pezzo su di essa la propria
2. Complessità - wireing insieme piccoli servizi consente di mantenere i singoli servizi molto meno complessi, dal momento che devono preoccuparsi di un minor numero di cose