Applicazione Web Java in un contenitore Servlet rispetto a standalone

Question

Quali sono i vantaggi della creazione di una piccola app Web Java da eseguire in un contenitore Servlet (come Tomcat) rispetto alla creazione di un'app Java autonoma con un server Web incorporato e in esecuzione dietro un proxy inverso?

Ho giocato con Java per circa un anno. Ho notato che il lancio di Tomcat richiede tempo e non è sempre possibile eseguire un hot-redeploy a causa di problemi con il programma di caricamento classi. L'API Servlet mi sembra piuttosto complicata, specialmente dal punto di vista della configurazione e del design RESTful (che non supporta completamente).

D'altra parte, ho notato che il mio IDE può compilare ed eseguire un'app standalone alla velocità della luce. Configurare Apache per il reverse-proxying è un gioco da ragazzi, e il Jetty incorporato sembra gestire tutto ciò che posso lanciarci. Non ho bisogno di Servlet quando posso usare Restlet, Wicket, ecc. Essere in grado di sapere meglio come funziona la mia app (perché non è integrata con un enorme server di app) ci dà potere. Le tracce dello stack sono più corte. La dimensione del download è più piccola. La configurazione dell'utente finale è più semplice. Immagino che le prestazioni siano probabilmente migliori perché ci sono meno livelli di software coinvolti.

Tuttavia, mi viene in mente il detto che ciò che sembra troppo bello per essere vero di solito è. Quindi la mia domanda è: perché non dovrei fare le mie app web standalone? Cosa fornisce a me e/o ai miei utenti finali un contenitore Servlet di cui abbiamo davvero bisogno ma che non conosciamo?

Answer 1

Ci sono 2 domande separate in qui:

1. Dovrei usare un server incorporato , o di distribuire in un contenitore?

   Non penso che dovresti vedere una grande differenza in un modo o nell'altro. C'è un po 'più codice per avvio di un server Jetty a livello di programmazione, e la configurazione è più facile da fare a livello di programmazione. Anche se il supporto IDE per web app configurazione e la distribuzione è sempre meglio, è ancora peggio che per applicazioni stand-alone (questo è un pò da definizioni, poiché c'è un superset di cose da supporto).

   D'altra parte, i server app danno alcuni bei vantaggi come built-in gestione, built-in capacità di funzionare come un servizio, ecc

   Si potrebbe anche usare un ibrido approccio: utilizzare un server incorporato per lo sviluppo localmente, quindi distribuire in un contenitore in produzione.Ma questo è un po 'strano: se si passa attraverso il problema di creare un file WAR corretto, gli IDE dovrebbero essere in grado di gestire la distribuzione in un contenitore in modo adeguato.

   BTW, è strano che si siano verificati problemi con hot-redeploy; Tomcat non dovrebbe essere avere problemi con esso a meno che non si sta eseguendo in qualche strano caso angolo ...

2. Dovrei usare Servlet API?

   Questo è ortogonale dal numero 1. È possibile che l' incorpori molto bene Jetty e implementa servlet. È inoltre possibile utilizzare utilizzando l'API Restlet all'interno di Tomcat tramite un ServerServlet http://www.restlet.org/documentation/1.0/faq#02.

   Personalmente trovo l'API Servlet per essere abbastanza straight-forward.You ottenere belle cose come concorrenza e gestione dello stato. Io non so bene cosa significa che il design RESTful non è supportato, ma se Restlets affrontare meglio le vostre esigenze, quindi utilizzare tale ...

Answer 2

I contenitori di servlet forniscono spesso una serie di elementi utili come la gestione automatica delle sessioni, la distribuzione a caldo, i framework per il failover e il clustering e così via. Dipende dal contenitore, ovviamente, ma a volte questi sono strumenti molto utili. A volte non lo sono.

EDIT: Ho appena notato il tuo commento su hot-redeploy. Sì, a volte i contenitori sono buggati e un dolore con cui lavorare, e tutti tendono ad avere le loro stranezze. Tuttavia, a volte forniscono alcune cose davvero buone.

Answer 3

Un Jetty incorporato è anche un servlet container. Presumo che la tua applicazione includa un web.xml dove si definiscono un filtro/servlet wicket, il servlet RESTlet e le loro mappature (almeno). Quindi non è possibile sbarazzarsi dell'API Servlet (o di un contenitore di servlet, anche se lo si incorpora), ma è possibile nasconderlo nel modo migliore possibile sotto i propri framework e in qualche metodo main(). RESTlet (o Jersey o qualsiasi implementazione JAX-RS) e Spring MVC sono tutti basati su servlet, quindi l'API Servlet supporta abbastanza bene REST, direi.

P.S. I due approcci non si escludono a vicenda. Puoi benissimo lavorare con Jetty durante lo sviluppo e poi distribuire la tua guerra in un contenitore (non integrato) per il controllo qualità/produzione. Oppure ... attaccare con Jetty per la produzione, se questo si adatta alle tue esigenze.

Answer 4

Il molo incorporato può essere una buona scelta se non è necessario lo stack completo del servlet. A differenza di Tomcat, Jetty semplifica la rimozione delle parti che non stai utilizzando (JSP, JNDI, qualsiasi altra cosa).

Scrivere il proprio server HTTP, d'altra parte, è una pessima idea. Certo, è facile scrivere qualcosa che gestisca le richieste di base. Ma presto scoprirai che alcuni client hanno problemi con questo perché non supporta le specifiche complete del protocollo; o che si blocca quando ci sono più di poche centinaia di utenti; o che esiste una vulnerabilità che consente ad alcuni bambini in Malesia di far saltare in aria la stampante. Quindi non reinventare la ruota.

Per quanto riguarda il tuo reclamo secondo cui l'API Servlet non supporta la progettazione RESTful - ti manca il punto, non è stato concepito per farlo. Ma ci sono un sacco di librerie REST che eseguono in cima a l'API Servlet.

Answer 5

I contenitori di servlet in-process sono i contenitori che funzionano all'interno della JVM del server Web, che offrono buone prestazioni ma scarsità di scalabilità.

I contenitori fuori processo sono i contenitori che funzionano nella JVM all'esterno del server Web.prestazioni scadenti ma migliori in termini di scalabilità Nel caso di contenitori out-of-process, il server Web e il contenitore dialogano tra loro utilizzando un meccanismo standard come IPC.

Oltre a questi tipi di contenitori, esiste un terzo tipo che è un container servlet indipendente. Questi sono parte integrante del web server.

Answer 6

se si verificano problemi con la distribuzione a caldo, molto probabilmente non si puliscono le connessioni esterne o altre risorse. Per gestirlo, in genere si desidera implementare un listener che ti consenta di sapere quando qualcosa viene avviato o interrotto.

probabilmente si dovrebbe nelle vostre guerre implementare qualcosa di simile (Tomcat 6):

public class MyTomcatInitCleanupListener implements ServletContextListener 
{ 
    @Override 
    public void contextInitialized(ServletContextEvent arg0) 
    { 
     super.contextInitialized(arg0); 
    } 

    @Override 
    public void contextDestroyed(ServletContextEvent arg0) 
    { 
     super.contextDestroyed(arg0); 
    } 
} 

per Tomcat 7+, è possibile google "Tomcat ciclo di vita ascoltatore"