JBoss vs Tomcat di nuovo [chiuso]


138

Questa sembrerà essere la domanda secolare (che è :)) quale server sia migliore tra Tomcat e JBoss, ma non ho ancora trovato una risposta abbastanza valida per risolvere il mio problema.

So che Tomcat è solo un motore servlet e JBoss offre molte più funzionalità predefinite, ma ciò che non riesco a capire è perché Tomcat è meglio usare in alcune situazioni rispetto a jboss. Ho letto da qualche parte che JBoss ha un'architettura collegabile e, se necessario, è possibile scollegare le funzionalità da JBoss per renderlo essenzialmente un contenitore servlet Tomcat. In tal caso, non è meglio farlo invece di utilizzare Tomcat, al fine di lasciare spazio per ricollegare le cose.

Un'altra spiegazione che trovo a favore di Tomcat è che è leggera, significa meno requisiti di memoria o consente anche una risposta più rapida. Ancora una volta, devo sapere che jboss non caricherà i componenti secondo i requisiti, ad esempio se sto usando solo servlet, non salterò il resto delle funzionalità e diventerà leggero automaticamente.

Fondamentalmente, la mia applicazione non ha alcuna funzionalità Java EE, ma gli argomenti 'leggeri' a favore di Tomcat non sembrano abbastanza convincenti a causa delle ragioni sopra menzionate.

Per favore aiuto.

Modifica: Finalmente avevamo deciso di usare Tomcat e lo usiamo da più di 6 mesi con grande facilità d'uso. Infatti abbiamo trovato un uso pratico in cui avremmo potuto facilmente eseguire più istanze tomcat sulla stessa macchina server per diversi sviluppatori, lo stesso avrebbe potuto essere molto difficile con jboss.

Ho trovato tomcat senza problemi per il nostro lavoro e quindi potrebbe essere la scelta giusta quando non si utilizzano molte delle funzionalità Java EE. PS: Tieni presente che utilizziamo ancora Spring e Hibernate con Tomcat


1
Uhh JBoss non si integra con Tomcat?
Navi,

4
@Navi: Non proprio. Contiene la versione biforcuta della base di codici Tomcat, ma è leggermente divergente.
Skaffman,

1
Una semplice app Web, senza funzionalità j2ee, dovrebbe essere distribuita facilmente su qualsiasi contenitore servlet conforme. Detto questo, non dovrebbe importare troppo quale si usa in anticipo. Comincerei con il più semplice da implementare (Tomcat e Jetty mi hanno entrambi servito bene in passato).
Gioele,

3
Cordiali saluti, alla fine del 2011 Tomcat è stato certificato JavaEE 6 come TomEE per rispondere a questa domanda secolare.
David Blevins,

1
domande chiuse con circa 150.000 visualizzazioni, 125 voti positivi e 0 voti negativi? !! So che queste sono le regole, ma devo dire che tali regole devono essere leggermente modificate.
Muhammed Refaat,

Risposte:


132

Innanzitutto i fatti, nessuno dei due è migliore . Come già accennato, Tomcat fornisce un contenitore servlet che supporta le specifiche Servlet (Tomcat 7 supporta Servlet 3.0). JBoss AS, un server delle applicazioni "completo" supporta Java EE 6 (incluso Servlet 3.0) nella sua versione corrente.

Tomcat è abbastanza leggero e nel caso in cui siano necessarie determinate funzionalità Java EE oltre l'API Servlet, è possibile migliorare facilmente Tomcat fornendo le librerie richieste come parte dell'applicazione. Ad esempio, se hai bisogno di funzionalità JPA puoi includere Hibernate o OpenEJB e JPA funziona quasi immediatamente .

Come decidere se utilizzare Tomcat o un Java EEserver applicazioni full stack :

Quando inizi il tuo progetto dovresti avere un'idea di cosa richiede. Se ti trovi in ​​un ambiente aziendale di grandi dimensioni, JBoss (o qualsiasi altro server Java EE) potrebbe essere la scelta giusta in quanto fornisce supporto integrato, ad esempio:

  1. Messaggistica JMS per l'integrazione asincrona
  2. Motore di servizi Web (JAX-WS e / o JAX-RS)
  3. Funzionalità di gestione come JMX e un'interfaccia di amministrazione con script
  4. Sicurezza avanzata, ad es. Integrazione immediata con directory di terze parti
  5. File EAR anziché "solo" supporto per file WAR
  6. tutte le altre "fantastiche" funzionalità Java EE che non ricordo :-)

A mio avviso, Tomcat si adatta molto bene se si tratta di applicazioni web-centric rivolte all'utente. Se entra in gioco l'integrazione back-end, è necessario (almeno) considerare un server delle applicazioni Java EE. Ultimo ma non meno importante, la migrazione di una WAR sviluppata per Tomcat su JBoss dovrebbe essere un esercizio di 1 giorno.

In secondo luogo, dovresti anche tenere conto dell'utilizzo all'interno del tuo ambiente. Nel caso in cui la tua organizzazione esegua già 1.000 istanze di JBoss, potresti sempre andare avanti con quello indipendentemente dai tuoi requisiti concreti (considera aspetti come il costo per le operazioni o l'upskilling). Naturalmente, questo vale viceversa.

il mio 2 cent


13

Dai un'occhiata a TOMEE

Ha tutte le funzionalità necessarie per creare un'app Java EE completa.


7

Darei sicuramente un'occhiata a TomEE poiché l'idea alla base è di mantenere Tomcat portando per difetto tutta l'integrazione JavaEE 6. È una specie di ottimo compromesso


6

In senso stretto; Senza funzionalità Java EE, la tua app non ha quasi bisogno di un appserver ;-)

Come altri hanno sottolineato, JBoss ha uno stack EE Java (più o meno) completo mentre Tomcat è solo un webcontainer. JBoss può essere configurato per funzionare solo come un webcontainer, quindi sarebbe solo un sottile wrapper attorno al webcontainer tomcat incluso. In questo modo potresti avere un JBoss quasi altrettanto leggero, che in realtà sarebbe solo un sottile "involucro" attorno a Tomcat. Sarebbe quasi altrettanto leggero.

Se non avrai bisogno di nessuno degli extra che JBoss ha da offrire, scegli quello con cui ti senti più a tuo agio. Qual è la più semplice da configurare e gestire per te?


1
quanto è difficile usare i servizi web e jmx con tomcat, puoi fornire qualche buon riferimento / link
Ashish,

2

Ho anche letto che per alcuni server, ad esempio, è necessario solo annotare i contesti di persistenza, ma in alcuni server l'iniezione deve essere eseguita manualmente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.