EAR singolo? O più EAR?

Question

Siamo in procinto di sviluppare un'applicazione basata su JavaEE 6 da distribuire su JBoss EAP 6.1. L'app ha 2 meccanismi di presentazione principali: una console di amministrazione Web e un'API di servizio RESTful. Sul back-end, sia la console di amministrazione che l'API di servizio RESTful si basano su una serie di EJB per l'esecuzione di logiche di transazione e servizi POJO per il recupero dei dati.

È del tutto possibile che le prestazioni e le risorse necessarie per tutti questi diversi livelli possano essere diverse. I servizi RESTful sono piuttosto sottili e completamente privi di stato, mentre la console di amministrazione è di stato e ha più funzionalità interattive (e quindi richiede più memoria ed elaborazione). Dal momento che i nostri bean eseguono la nostra logica di business transazionale primaria, richiederebbero una maggiore potenza di elaborazione rispetto ai nostri servizi dati POJO che eseguono semplicemente query sul database.

Data tale impostazione, avrebbe più senso distribuire un singolo EAR (in più appserver in una configurazione cluster) con tutti questi componenti o suddividere i singoli componenti in EAR separati? Il mio modo di pensare con EAR separati è che potrei, ad esempio, distribuire più istanze dei servizi EJB se trovo che ci sono problemi di scalabilità con loro, anche se la console web (ad esempio) si sta adattando perfettamente.

Dato che la scalabilità di ogni livello/componente è diversa, quale approccio dovrei adottare? Il sovraccarico di dover effettuare chiamate EJB remote su EAR è troppo alto per considerare un tale modello? Qualche consiglio è GRANDE apprezzato!

Answer 1

Il modo "Java EE" sarebbe la distribuzione dell'applicazione come un singolo EAR sul cluster. Suppongo che tu stia utilizzando le chiamate di interfaccia locali da REST/admin console a EJB-s. La distribuzione sarebbe semplice, se non è necessaria la replica di sessione (è possibile utilizzare sessioni adesive), quindi la scalabilità sarà molto buona.

L'unico elemento aggiuntivo che è necessario è il bilanciamento del carico per le applicazioni Web (ad esempio il server Apache che si occuperà anche della decodifica SSL, delle risorse statiche e, eventualmente, delle richieste di memorizzazione nella cache che possono essere memorizzate nella cache).

L'unico problema con tale impostazione potrebbero derivare per carichi pesanti, per esempio EJB potrebbe mangiare un sacco di risorse del server, quindi il throughput delle applicazioni web sarà difficile da controllare e può essere gravemente colpiti da EJB. Se si utilizzano sessioni persistenti, l'utente viene sempre reindirizzato allo stesso server, quindi non vi è alcuna possibilità di spostare alcuni utenti sul server meno caricato finché dura la sessione utente.

Quindi, se si pianificano carichi elevati, sarebbe opportuno mantenere le applicazioni Web e gli EJB su box separati (o macchine virtuali), quindi è più facile identificare i colli di bottiglia e scalare più facilmente quel livello che ne ha bisogno.

La pena per questo sarebbe:

1. chiamate remote per EJB. Tuttavia, JBoss 6 ha una configurazione di pool di EJB piuttosto avanzata, quindi potrebbe non essere un problema così terribile.
2. traffico di rete causato da queste chiamate remote (quindi se si passano tra gli EJB e il web layer molti dati, potrebbe essere un problema).

Answer 2

A sostegno di grandi commenti di Piotr:

Bundle insieme ora, e dividere solo se una vera e propria esigenza nasce in futuro.

Considerate il First Law of Distributed Object Design: Don’t distribute your objects! di Martin Fowler come una buona linea guida - se avete intenzione di romperlo, almeno farlo consapevolmente e per reali esigenze aziendali.