Sin patetismo. Hablemos de Java EE, servlets y sus contenedores

En este tema, me gustaría hablar con franqueza sobre mi comprensión de los servlets, qué son los contenedores de servlets, qué son la mayoría, si no todos, los frameworks front-end web, y también tocar el tema de cómo se relacionan los contenedores de servlets y los servidores de aplicaciones. entre sí, y contenedores de servlets y servidores web. Antes de iniciar la conversación, quiero señalar que realmente espero que haya una discusión, porque... Aquí no quiero dar ni un solo fragmento de código, solo quiero tocar la esencia, que siempre se puede expresar con palabras. Intentaré resumir todos aquellos puntos que no me quedaron claros cuando comencé. Cuando hice preguntas en varios foros sobre el tema de en qué se diferencia el contenedor de servlets Tomcat de cualquier servidor de aplicaciones, digamos WebSphere o Geronimo, los únicos que se atrevieron a responder fueron imbéciles que no podían decir nada más que "mira Wikipedia" o " Es difícil decirlo, las aplicaciones de servidor son una infraestructura compleja para aplicaciones corporativas, que..." bla, bla, bla. No soporto a la gente así y supongo que la mayoría de ustedes tampoco. Corregiremos la injusticia histórica. Ir…

servlets

No importa lo que digan, un servlet es una página web escrita en Java. Algunos dirán que estoy equivocado y que un servlet es una aplicación web y que hay una diferencia en estos conceptos, pero no es así. Ahora no hay diferencia, y los sitios escritos en PHP también pueden denominarse aplicaciones web de forma segura. Ahora bien, esto es completamente natural, porque... php es totalmente compatible con la programación orientada a objetos y los CMS como Joomla lo utilizan activamente. ¿Qué es un servlet a nivel de código? Esta es una clase que tiene varios métodos que duermen y ven si alguien accede a ellos mediante solicitudes GET o POST HTTP. Aquellos. Escribimos alguna solicitud GET en el navegador, el método correspondiente de la clase de servlet la acepta y luego genera una respuesta en forma de página HTML. En el sentido clásico de servlet, tal como lo concibió Sun, esta página se enviaba al cliente línea por línea, comenzando con la línea <!DOCTYPE htm>> y terminando con la línea </html>. Entonces, en Java hay una clase de servlet básica llamada Servlet. Además, hay muchas otras clases que heredan de esta clase base y, por lo tanto, amplían su funcionalidad. Eso es lo que es un servlet, nada más. Es simplemente un análogo Java del código PHP, que también se ejecuta en el servidor, y solo se envía al cliente la respuesta a la solicitud del navegador web en forma de página web. Todo.

Marcos de interfaz web

El subtítulo es complicado y, por lo general, simplemente escriben framework front-end o incluso web bozzle , pero decidí enfatizar aquí que cuando hablamos de frameworks front-end, estamos hablando de una GUI para trabajar con Java a través de un navegador web. Aquellos. Aquí nuevamente estamos hablando de sitios web en Java, es decir. sobre servlets. ¿Qué es casi cualquier marco de front-end, por ejemplo, Apache Struts? Es simplemente un conjunto de clases que amplían la clase base Servlet. Nada mas. Aquellos. es simplemente una forma diferente de crear el mismo servlet normal. Es solo que los desarrolladores de este framework (o en otras palabras, los desarrolladores de esta tecnología) consideraron que agregar la clase base Servletcon algunos métodos sería más conveniente para el programador que la escasa funcionalidad que ofrece el servlet clásico de Sun/Oracle. tiene.

páginas JSP

Casi de inmediato, a los desarrolladores del concepto de servlet Java se les ocurrió otra idea. Dado que estamos escribiendo un servlet, cuya tarea es enviar una página html al cliente, entonces podría ser más correcto escribir inmediatamente esta página html, y si necesita algún tipo de lógica en Java, simplemente insértela directamente en el html. Si no queda más claro, entonces la frase puede ayudar: una página jsp es análoga a una página php. ¿Difícil? Luego te lo explicaré de nuevo. ¿Qué hacemos al escribir una página en PHP? Tenemos HTML estático y cuando necesitamos insertar alguna lógica en PHP, como bucles y condiciones, la insertamos en el cuerpo de la etiqueta <?php … ?>. Con jsp todo es igual, solo la lógica está escrita en Java puro, cuyo código se inserta en el cuerpo de la etiqueta <% … %>. Volvamos una vez más al concepto de servlet. En esencia, una página JSP es un servlet, pero escrito de forma ligeramente diferente. En un servlet normal, escribimos un método que realiza cierta lógica y, en función de sus resultados, genera una página HTML para el cliente. Es solo que después de un tiempo, los desarrolladores de servlets comenzaron a pensar: ¿y si prácticamente no hay lógica en el método y casi solo ocurre la formación de una página html, entonces no sería más fácil escribir inmediatamente una página html en ¿Cuál hacer inserciones mínimas de código Java? Bueno, una última cosa sobre las páginas jsp. La primera vez que se accede a una página de este tipo, se compila en un servlet y luego se ejecuta. Las solicitudes posteriores a esta página jsp serán más rápidas porque ya estará compilado y sólo será necesario ejecutarlo.

Contenedor de servlets

Entonces escribimos una clase de servlet o una página JSP. ¿Que sigue? ¿Cómo insertarlos en un servidor web, digamos Apache, para que pueda enviarlos al navegador web del usuario? El servidor web solo puede enviar html, y si nuestra página tiene, digamos, código php, entonces el servidor web primero pasa la página a través de un intérprete que traduce php a html, y solo entonces el resultado se envía al cliente. Casi lo mismo sucede con los servlets: antes de enviarlos, deben ejecutarse para que se genere la página HTML, y el contenedor de servlets es exactamente el responsable de ejecutar los servlets y el código de la página jsp. Aquellos. Un contenedor de servlets para Java es un análogo del módulo intérprete de PHP en un servidor web. Así, cuando el usuario ingresa una dirección en el navegador web, la solicitud se envía al servidor web, el servidor web entiende que se está solicitando un servlet y pasa la solicitud al contenedor de servlets. Después de esto, el contenedor de servlets ejecuta el servlet, envía la página HTML resultante al servidor web, que, a su vez, la devuelve al cliente. ¿Puede un contenedor de servlets ejecutarse por sí solo, es decir? sin servidor web? Algo como Tomcat definitivamente puede hacerlo. Y si queremos crear un sitio que no tenga otras páginas html excepto las basadas en servlets, entonces un contenedor de servlets es suficiente para nosotros. Pero si queremos combinar un sitio a partir de servlets y, digamos, páginas PHP, entonces tendremos que instalar un servidor web. Además, no todos los servidores web tienen un contenedor de servlets incluido por defecto, pero casi todos permiten instalarlo como complemento. Por tanto, si queremos ejecutar nuestro sitio web en algún hosting de Internet donde probablemente se ejecute Apache, tendremos que preguntar al proveedor si el contenedor de servlets está conectado.

JavaEE

Existe el llamado JavaSE (Java Standard Edition). Este concepto incluye todas las clases java, para cuyo uso solo necesitamos importarlas (por ejemplo, java.util.Date) o incluso no necesitamos hacerlo (por ejemplo, Stringya que se encuentra en el paquete java.lang). Y está Java EE (Java Enterprise Edition). Estas clases también pertenecen a Sun/Oracle, pero la única diferencia es que son más difíciles de empezar a usar en un proyecto. Una simple línea import…no será suficiente, porque... el proyecto no se compilará. Para corregir la situación, necesitará encontrar el archivo de la biblioteca javaee.jar e incluirlo en el proyecto. Esto se puede hacer a través de las propiedades del proyecto en el entorno de desarrollo. A menudo se dice que este proceso de conexión se llama: registrar un apodo jar en la ruta de compilación o classpath del proyecto.

Servidor de aplicaciones

Ahora imagine que hemos compilado nuestro proyecto de servlet que utiliza Java EE. Todo está genial, pero ahora necesitamos colocar nuestras clases compiladas en un contenedor de servlets. Digamos que lo hicieron. ¿Funcionará nuestra aplicación? La respuesta es no. Al acceder al servlet, se lanzarán excepciones indicando que no se encontraron algunas clases. ¿Por qué? Porque "engañamos" al compilador al deslizarnos javaee.jar в classpath, es decir el compilador vio que las clases de Java EE estaban en su lugar y se calmó, pero el contenedor de servlets no ve estas clases, pero ve enlaces a ellas desde nuestro servlet. ¿Se puede resolver esta situación dentro de un contenedor de servlets? Por supuesto que sí, solo necesita agregar el archivo de la biblioteca javaee.jar a la carpeta con nuestro servlet en el contenedor de servlets . Ahora imagine que habrá muchos proyectos de este tipo y que todos se ejecutarán en un contenedor de servlets Tomcat. Esto significa que tendrás que copiar este archivo jar a la carpeta de cada servlet. Esto es inconveniente y está mal. La situación se resolvió introduciendo el concepto de servidor de aplicaciones, en el que este archivo ha estado durante mucho tiempo en una sola copia y todos los servlets pueden acceder a él y no tener su propia copia. En mi opinión, es muy conveniente y lógico. Naturalmente, todo este alboroto no se debe a un solo archivo jar (lo di como ejemplo): hay muchos archivos de este tipo. Pero eso no es todo lo que nos brindan los servidores de aplicaciones. Los propios servidores de aplicaciones pueden mantener conexiones con muchos recursos, por ejemplo, una base de datos. En este caso, es posible que nuestro servlet no abra dicha conexión por sí solo, sino que simplemente la tome del servidor de aplicaciones. En un contenedor de servlets, esto es imposible, porque... un contenedor es, hasta cierto punto, un servidor de aplicaciones simplificado. En un contenedor, un servlet siempre debe crear conexiones con la propia base de datos. Algo como esto... archivo-guerra ¿Qué es un archivo-guerra? WAR es un archivo web. De hecho, es sólo un archivo zip, como cualquier jar. Básicamente, esto es sólo una forma de agrupar nuestro sitio web, que consta de muchas páginas web, páginas jsp y clases de servlet, en un solo archivo zip. web.xml web.xml es el llamado descriptor de implementación. Este es un archivo que describe estúpidamente qué línea de solicitud del navegador web enviar a qué clase de servlet para su procesamiento, para que el contenedor de servlets no se confunda, qué servlet es responsable de qué. En general, en Java está muy de moda describir configuraciones en todo tipo de archivos xml, pero recientemente ha habido una tendencia a alejarse de esta tradición. ¿Cómo, preguntas? Y mediante anotaciones. Las clases de anotación en sí mismas no hacen nada; fueron creadas solo para describir todo tipo de configuraciones (metadatos) no en un archivo xml separado, sino directamente en el código. Muy cómodamente. Sin embargo, ahora hay una cierta etapa intermedia, cuando algunas de las configuraciones se especifican mediante anotaciones y otras mediante xml, y esto puede resultar confuso porque Miras el xml y ves una configuración, pero según las anotaciones hay otra. ¿Cuál tiene la mayor prioridad? Quién sabe…

Conclusión

Habiendo escrito esto, pensé que una reseña tan rápida no ayudaría a nadie, porque... No contiene detalles ni ejemplos, pero por otro lado, no borres lo que está escrito, que así sea.