Aplicación web Java en un contenedor Servlet vs. versión independiente

Question

¿Cuáles son las ventajas de crear una pequeña aplicación web Java para que se ejecute en un contenedor Servlet (como Tomcat) o crear una aplicación Java independiente con un servidor web integrado y en ejecución? ¿Está detrás de un proxy inverso?

He estado jugando con Java durante aproximadamente un año. Me di cuenta de que lanzar Tomcat lleva tiempo, y no siempre es posible realizar una reimplantación en caliente debido a problemas con el cargador de clases. La API de Servlet me parece algo intrincada, especialmente desde la perspectiva de la configuración y del diseño REST (que en realidad no es totalmente compatible).

Por otro lado, he notado que mi IDE puede compilar y ejecutar una aplicación independiente a la velocidad del rayo. Configurar Apache para proxies inversos es pan comido, y Jetty integrado parece manejar todo lo que puedo lanzar. No necesito Servlets cuando puedo usar Restlet, Wicket, etc. Ser capaz de saber mejor cómo funciona mi aplicación (porque no está integrado con un gran servidor de aplicaciones) se siente habilitante. Los rastros de pila son más cortos. El tamaño de descarga es más pequeño. La configuración del usuario final es más fácil. Supongo que es probable que el rendimiento sea mejor porque hay menos capas de software involucradas.

Sin embargo, me recuerda el dicho de que suena demasiado bueno para ser verdad. Entonces mi pregunta es, ¿por qué no quiero hacer que mis aplicaciones web sean independientes? ¿Qué me proporciona un contenedor Servlet y/o mis usuarios finales que realmente necesitamos pero que desconocemos?

Answer 1

Hay 2 preguntas separadas en aquí:

1. ¿Debo utilizar un servidor incorporado, o se despliegan en un contenedor?

   No creo que deba ver una gran diferencia en un sentido u otro. Hay un poco más de código en que inicia un servidor Jetty mediante programación, y la configuración es más fácil de realizar mediante programación. A pesar de que soporte IDE para la configuración de aplicación web y el despliegue es cada vez mejor, sigue siendo peor que para aplicaciones independientes (esto es un poco por las definiciones, ya que hay un superconjunto de las cosas a soporte).

   Por otro lado, los servidores de aplicaciones dan que algunos beneficios agradables como una función de gestión , una función de capacidad de ejecutar como un servicio, etc.

   Incluso se puede utilizar un enfoque híbrido : utilice un servidor incrustado en desarrolle localmente, luego impleméntelo en un contenedor en producción.Pero eso es un poco raro: si pasa por el problema de hacer un archivo WAR adecuado, IDEs realmente debería ser capaz de manejar el despliegue en un contenedor adecuadamente.

   Por cierto, es raro que tenga problemas con la redistribución en caliente; Tomcat no debe estar teniendo problemas con él a menos que estés que desembocan en algún caso esquina extraña ...

2. ¿Debería utilizar la API de Servlet?

   Esto es ortogonal desde # 1. Usted podría incrustar muy bien Jetty y implementar Servlets. También puede utilizar la API de Restlet dentro de Tomcat a través de ServerServlet http://www.restlet.org/documentation/1.0/faq#02.

   Personalmente considero que la API Servlet a ser bastante straight-forward.You obtener cosas agradables como la concurrencia y la administración del estado. No sé muy bien lo que significa que el diseño REST no es compatible, pero si Restlets atender mejor a sus necesidades, luego usar ese ...

Answer 2

Los contenedores de servlets a menudo proporcionan un montón de cosas útiles, como administración automática de sesiones, implementación en caliente, marcos para failover y clustering, y más. Depende del contenedor, por supuesto, pero a veces estas son herramientas muy útiles. A veces no lo son.

EDIT: Acaba de notar su comentario sobre hot-redesplegar. Sí, a veces los contenedores tienen errores y es un dolor trabajar con ellos, y todos tienden a tener sus propias peculiaridades. Sin embargo, a veces proporcionan algo realmente bueno.

Answer 3

Un embarcadero incorporado es también un contenedor de servlets. Supongo que su aplicación incluye un web.xml donde se define un wicket filter/servlet, el servlet RESTlet y sus asignaciones (al menos). Por lo tanto, no puede deshacerse de la API de Servlet (o de un contenedor de servlets, incluso si la integra), pero puede ocultarla lo mejor posible debajo de sus marcos y en algún método main() propio. RESTlet (o Jersey o cualquier implementación de JAX-RS) así como Spring MVC están todos basados ​​en servlets, por lo que la API de Servlet soporta bastante bien REST, diría yo.

P.S. Los dos enfoques no se excluyen entre sí. Puede trabajar muy bien con Jetty durante el desarrollo y luego implementar su guerra en algún contenedor (no embebido) para control de calidad/producción. O ... quédese con Jetty para producción, si eso realmente se adapta a sus necesidades.

Answer 4

Embedded Jetty puede ser una buena opción si no necesita la pila completa de Servlets. A diferencia de Tomcat, Jetty hace que sea fácil deshacerse de las partes que no está utilizando (JSP, JNDI, lo que sea).

Escribir su propio servidor HTTP, por otro lado, es una idea terrible. Claro, es fácil escribir algo que maneje solicitudes básicas. Pero pronto descubrirá que algunos clientes tienen problemas porque no es compatible con las especificaciones de protocolo completo; o que se cuelga cuando hay más de unos cientos de usuarios; o que existe una vulnerabilidad que permite que un niño en Malasia explote su impresora. Entonces no reinvente la rueda.

En cuanto a su queja de que la API de Servlet no es compatible con el diseño REST-se está perdiendo el sentido, nunca fue la intención de hacer eso. Pero hay muchas bibliotecas REST que ejecutan en la parte superior de API del servlet.

Answer 5

Los contenedores de servlets en proceso son los contenedores que funcionan dentro de la JVM del servidor web, estos proporcionan un buen rendimiento pero de escasa escalabilidad.

Los contenedores fuera de proceso son los contenedores que funcionan en la JVM fuera del servidor web.pobre en el rendimiento pero mejor en la escalabilidad En el caso de los contenedores fuera de proceso, el servidor web y el contenedor se comunican usando algún mecanismo estándar como el IPC.

Además de estos tipos de contenedores, hay un tercer tipo que es contenedores de servlet independientes. Estas son una parte integral del servidor web.

Answer 6

si tiene problemas con su implementación en caliente, lo más probable es que no esté limpiando sus conexiones externas u otros recursos. Para manejar esto, generalmente quiere implementar un oyente que le avisará cuando algo se inicia o detiene.

debe probablemente en sus guerras implementar algo como esto (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); 
    } 
} 

para Tomcat 7+, puede google "Tomcat ciclo de vida del oyente"