Quando Spring + Tomcat non è abbastanza potente?

Question

Ultimamente ho letto/apprendo di più su Spring e su come utilizzare Spring in combinazione con altri strumenti open source come Tomcat e Hibernate. Sto valutando se Spring MVC potrebbe essere una possibile tecnologia sostitutiva per il progetto su cui lavoro, che utilizza WebLogic e un sacco di codice Java EE personalizzato. Il fatto è che ho sempre sospettato che la nostra soluzione fosse eccessivamente ingegnerizzata e MODA più complessa di quanto dovrebbe essere. Sorprendentemente, è il 2009, eppure, stiamo scrivendo le nostre classi di gestione delle transazioni e di condivisione dei thread. E non è che siamo Amazon, eBay o Google, se sai cosa intendo. Quindi, sto studiando un'opzione "più semplice è meglio".

Quindi, ecco la mia domanda: mi piacerebbe sentire le opinioni su come si prende la decisione che è necessario un application server Java EE completo, oppure no. Come si "misura" la dimensione/carico/domanda su un'app Java EE? Numero di utenti concorrenti? Totale transazioni giornaliere? Quanto "pesante" deve avere un'app prima di alzare le mani in segno di resa e dire "OK, Tomcat non lo sta tagliando, abbiamo bisogno di JBoss/WebLogic/WebSphere"?

Answer 1

Non credo che la decisione di utilizzare un server Java EE completo o meno debba essere basata sul numero di utenti o transazioni. Piuttosto dovrebbe essere basato sul fatto che sia necessaria la funzionalità.

Nel mio progetto attuale ci stiamo effettivamente spostando da JBoss a Vanilla Tomcat perché ci siamo resi conto che non stavamo utilizzando nessuna delle funzionalità Java EE oltre ai servlet di base. Tuttavia, stiamo usando Spring. Tra la gestione degli oggetti di base di Spring, la gestione delle transazioni e le funzionalità JDBC, non stiamo assistendo a una necessità impellente per EJB. Al momento utilizziamo Struts 2 piuttosto che MVC di Spring, ma ho sentito grandi cose a riguardo. In ogni caso, Spring si integra bene con una serie di framework web Java.

Answer 2

Google apre molto del loro codice. Se stai scrivendo cose di basso livello, invece di implementare codice già scritto, stai spesso pensando troppo al problema.

Torna alla domanda attuale, Walmart.com, etrade.com, The Weather Channel e quite a few others basta usare Tomcat. I ragazzi di marketing e vendite di IBM ti faranno credere, forse, in modo diverso, ma non c'è un limite massimo per Tomcat.

Fatta eccezione per EJB, non sono sicuro di ciò che manca a Tomcat e non sono un fan di EJB.

Answer 3

Spring non tenta di sostituire alcune parti avanzate delle specifiche JavaEE, come JMS e JTA. Invece, si basa su quelli, rendendoli coerenti con il "modo primaverile", e generalmente rendendoli più facili da usare.

Se l'applicazione richiede la potenza di JMS e JTA, è possibile utilizzarli facilmente tramite Spring. Non è un problema con quello.

Answer 4

Ciò che Tomcat non offre a parte gli elementi più esotici di Java EE sono i bean di sessione (noti anche come EJB). I bean di sessione consentono di isolare l'elaborazione in modo efficiente. Quindi potresti avere una casella per il front-end, un'altra per i bean di sessione (business logic) e un'altra per il database.

Si consiglia di fare questo per almeno 2 motivi:

1. prestazioni; Stai scoprendo che una scatola per gestire tutto sta caricando troppo la scatola. Separare i diversi livelli su diverse scatole ti permetterebbe di scalare. I bean di sessione sono anche in grado di bilanciare il carico a un livello più fine. Tomcat e altri servizi Web di questo tipo non dispongono di cluster fuori dalla scatola.
2. Flessibilità; Ora che hai spostato la tua logica aziendale nel suo ambiente, potresti sviluppare un front-end alternativo che usava lo stesso livello, ma per esempio, era un front-end spesso client. O forse altri contesti vorrebbero utilizzare i bean di sessione.

Anche se probabilmente dovrei sottolineare che se si utilizzano i servizi Web per comunicare con quel livello intermedio, potrebbe anche essere su tomcat!

Answer 5

Forse questo può essere di interesse:

http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html

HTH

Answer 6

L'unico motivo per utilizzare un server Java EE in piena regola è se avete bisogno di transazioni distribuite XA, se non è necessario Transazioni XA quindi puoi utilizzare Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java Mail.

Anche un server Java EE deve implementare JMS, ma non ha senso eseguire il server JMS nella stessa VM del resto del server delle app, quindi se avete bisogno di JMS dovreste avere un server JMS separato.

Answer 7

Sono fortemente in disaccordo con tutte le risposte fornite qui.

Tutto può essere aggiunto a Tomcat, tra cui EJB, CDI, JTA, Bean Validation, JAX-RS, ecc

La domanda è: vuoi questo? Vuoi assemblare tutte quelle dipendenze nelle giuste versioni e testare che tutto funzioni insieme, quando altri lo hanno già fatto?

Siamo chiari: nessuno usa solo Tomcat! Tutti aggiungono sempre un framework web, un contenitore di ioc, un orm, un gestore di transazioni, servizi web, ecc.

I server Java EE leggeri come TomEE includono già tutto questo e rendono l'esperienza di stack completo di avere tutte queste cose integrate molto meglio