Se oggi avessi avviato un nuovo progetto Java EE che dovrebbe concludersi tra circa un anno, quale server delle applicazioni sceglieresti e perché?
Parte della tua risposta dovrebbe includere i tuoi argomenti per la tua decisione. E anche quanta esperienza hai con il server Java EE che scegli e con gli altri server disponibili sul mercato. Questi sono interessanti poiché tutti abbiamo un'idea delle indagini e abbiamo pensato che fosse stato inserito nella tua risposta.
Risposte:
Ho usato WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat e alcuni altri negli ultimi 10 anni. Quindi, se stavo prendendo in considerazione un nuovo progetto, mi farei prima alcune domande. Una cosa che non metterei più in discussione è che rifiuterei di usare i JSP se non fossi stato torturato fino a quando non avrei pianto per la mia mamma.
Devo essere compatibile / distribuire a un prodotto specifico a causa del mandato di qualcuno? Non c'è modo di ignorarli o convincerli altrimenti? Se è così, c'è la tua risposta.
Devo usare gli EJB? Veramente? Evitali, se possibile, sono davvero necessari solo per sistemi di grandi dimensioni di livello aziendale. Ricorda che sono solo strumenti e strumenti importanti (qualcuno può dire "Golden Sledgehammer"?). Sono pesantemente abusati, quindi chiedo davvero se ne hai bisogno. Se ne hai bisogno, ciò rimuove diverse opzioni tra cui la mia preferita, Jetty.
Devi usare una delle altre principali tecnologie J2EE come JMS, ESB, ecc.? Se è così, e non puoi davvero farne a meno, allora sei di nuovo vincolato a un contenitore J2EE completo. Pensa e indaga attentamente prima di impegnarti in BPM, ad esempio, ed evita AquaLogic BPM a (quasi) tutti i costi - è brutto all'estremo.
Se devi davvero utilizzare un contenitore J2EE completo, considera prima l'open-source perché è più robusto, meglio supportato e più economico. Hanno una base clienti più ampia e interazioni di supporto più aperte, quindi tendono a ottenere soluzioni migliori più velocemente. Tuttavia, la resina è immatura e la eviterei rispetto a GlassFish o JBoss - ho trovato problematico implementare e supportare. Preferirei JBoss a causa della sua più ampia base di clienti, maturità, ecc. GlassFish è più difficile da incorporare in un processo di compilazione / distribuzione automatizzato, ma potrebbe essere più bello per alcune delle sue caratteristiche specifiche (se ne hai bisogno).
Ho un motivo speciale per aver bisogno di Apache? Quindi inclinati verso Tomcat, forse più qualcosa.
Posso accontentarmi solo dei servlet? Quindi userei Jetty: è la soluzione più leggera, più veloce, più semplice e più flessibile. Se mi sto appoggiando a non poter usare Jetty, metterei in dubbio tutte le mie ipotesi sul perché. Si applica YAGNI.
La cosa migliore è usare StringTemplate / WebStringTemplate su Jetty: una soluzione pulita, robusta, veloce e gestibile senza costi di licenza, solida reputazione e supporto, ecc. È da qui che inizio oggi.
La maggior parte delle applicazioni / sistemi scelgono molte fantasiose funzionalità J2EE quando tutto ciò di cui hanno veramente bisogno sono servlet e JDBC con un'architettura / design decente. Domanda perché pensi di aver bisogno di più.
Tra i contenitori completi, eviterei WebLogic e WebSphere a meno che tu non stia supportando un sito Web pubblico MAJOR (il sito Web del mio attuale datore di lavoro è distribuito su WebLogic e ottiene undici + milioni di accessi al mese, altri sono stati comparabili). La vera pretesa di fama di WebLogic è il loro clustering relativamente semplice, ma evita le loro caratteristiche di blocco del fornitore proprietario a (quasi) tutti i costi. WebSphere è semplicemente un incubo che eviterei letteralmente a tutti i costi - mi rifiuto di fare progetti che coinvolgono WebSphere dopo aver fatto un paio in passato. Nessuno dei due prodotti vale le enormi spese di licenza, a meno che tu non abbia veramente un bisogno particolare che guida l'uso di una funzione proprietaria. In un decennio come architetto / ingegnere senior per molte aziende di Fortune 500, non ho ancora visto un tale bisogno. D'altro canto,
Anche per i siti Web pubblici molto grandi e ad alto traffico, i prodotti proprietari sono ancora discutibili. Preferirei spendere quel multimilionario di tasse di licenza su un buon hardware e un po 'di tempo di qualità da una manciata di consulenti davvero bravi per affrontare una semplice soluzione di scalabilità. I milioni in più all'anno potrebbero quindi essere utilizzati per produrre qualcosa degno di vendita su quel bel sito Web ...
EDIT: un altro pezzo da considerare ...
Di recente ho incontrato Terracotta . Sto ripensando a tutto e sto cercando di implementarlo presto in un sistema significativo. In particolare, Terracotta fa il clustering meglio di ogni altra cosa, quindi NON consiglierei MAI PIÙ WebLogic per il suo clustering.
Il termine "server applicazioni" è ambiguo. Con GlassFish v3, puoi iniziare con, ad esempio, un contenitore web tradizionale ed evolvere (usando OSGi e la semplice funzionalità "aggiungi contenitore") per aggiungere tutto ciò che desideri: JPA, JAX-RS, EJB, JTA, JMS, ESB , ecc ... Eppure è lo stesso prodotto, la stessa interfaccia di amministrazione, ecc. Questo si qualifica come un server delle applicazioni per te? -Alexis (Sun)
La prima domanda che mi pongo di solito è "Posso farlo con Tomcat?". Se la risposta è no perché ho bisogno di JMS o JTA, ricorrere a un server delle applicazioni.
Ho usato WebLogic 8 circa 3 anni fa soddisfatto della facilità d'uso di WebLogic e del modello di licenza / costo. Lo abbiamo usato per due progetti, uno era un servizio web e l'altro era un portale. Non abbiamo riscontrato problemi con WebLogic o WebLogic Portal in nessuno di questi progetti.
Negli ultimi due anni ho lavorato con WebSphere. Ogni volta che negoziavo con IBM finiva sempre per costare il doppio di un equivalente di WebLogic, ma doveva essere utilizzata la politica aziendale dettata da WebSphere. Ho trovato la curva di apprendimento su WebSphere molto più ripida di WebLogic e il nostro ciclo di vita di build / deploy / test ha richiesto così tanto tempo che abbiamo usato Tomcat nell'ambiente di sviluppo. Ma il problema più grande che ho avuto con WebSphere è stato quando abbiamo riscontrato un bug che ci ha costretto ad aggiornare alla prossima versione di patch solo per imbatterci in un nuovo problema durante l'analisi di web.xml. Ci è voluto un turno di 48 ore per risolvere tutto ciò.
Al momento però sto usando JBoss. Circa 3 mesi fa stavo per iniziare il mio nuovo progetto con Tomcat e Jetspeed 2, ma ho notato che Jetspeed 2 sembra un po 'stagnante in questo momento e JBoss Portal 2.7.0 è stato appena rilasciato con il supporto JSR 286 / Portlet 2.0. Ho dato a JBoss un giro e ho trovato molto facile da configurare e amministrare. Il ciclo di compilazione / distribuzione / test è molto rapido e raramente devo riavviare il server a meno che non abbia modificato un file XML Spring da qualche parte.
Uso jBoss da 3-4 anni.
Argomenti per jBoss:
Argomenti contro jBoss:
Acquista GlassFish 3.1! Basato sul kernel GlassFish v3 modulare basato su Java EE 6, la versione 3.1 offre clustering, amministrazione centralizzata e alta disponibilità.
Fare riferimento a http://blogs.oracle.com/nazrul/entry/glassfish_3_1 per maggiori dettagli.
Un altro punto che non è stato discusso qui è la prestazione. Se questo è un problema a causa del tipo di servizio o del numero di utenti, sarà applicabile quanto segue:
Si noti che G-WAN si basa solo sulla JVM: non utilizza ulteriori contenitori (se non specificato in modo esplicito), pertanto è possibile riservarlo a parti critiche in termini di prestazioni delle applicazioni Web.
Poiché G-WAN supporta altri linguaggi (C, C ++, C #, D, Objective-C), è anche possibile elaborare alcune parti delle applicazioni in C grezzo mantenendo Java per altre attività.
Potrei includere il tuo sistema operativo preferito come criterio decisionale. Dovrebbe essere più semplice supportare se si utilizza lo stesso fornitore per sistema operativo e app server. Se hai già una relazione con uno o entrambi i fornitori, considera se sono buoni da trattare.
Da un punto di vista tecnico sceglierei GlassFish perché supporta le innovazioni più recenti. Non penso che JBoss sia cattivo in ogni caso, semplicemente non è così aggiornato.
Gran parte della mia esperienza è su WebLogic ma ho usato JBoss e GlassFish. Ho appena pubblicato un nuovo sito su uno stack open source Sun completo (OpenSolaris, GlassFish, MySQL) ed è stata una bellissima esperienza con solo piccole frustrazioni.
Penso ancora che WebLogic sia il miglior server di app Java EE sul mercato. Penso che ne valga la pena se puoi permetterti quei costi di licenza.
Sono stato sorpreso di vedere quanto lontano puoi andare combinando Tomcat, OpenEJB e ActiveMQ. Mi sembrerebbe un'alternativa a basso costo.
Esaminerei anche il server Spring dm. È basato su Tomcat, ma penso che il pezzo OSGi che hanno aggiunto potrebbe essere ovunque in breve tempo. Se è fatto con la stessa qualità del framework Spring, sarà davvero molto buono.
Un'alternativa: non utilizzare affatto appserver.
Check-out http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .
Per i progetti Web, mantenere un contenitore Web leggero, se necessario, combinato con qualcosa come Wicket per evitare la complessità di JSP / JSF o puntoni.
HTH Guy