Los servlets no son más que objetos Java que se adaptan a una interfaz específica para poder ser ejecutados por un lado en un servidor que soporte servlets y poder comunicarse con las peticiones que le lleguen desde un cliente Web. Los servlets son a la capa servidora de aplicaciones lo que los applets son a la capa del cliente, pero se diferencian de estos en que los servlets no son elementos gráficos.
La ejecución de un servlet es menos costosa que la de un CGI, ya que se basan en el modelo de ejecución de threads en lugar de procesos. Cuando ejecutamos un CGI un proceso completo de sistema operativo se crea cada vez que ejecutamos ese CGI, mientras que con servlets lo que se crean son threads, es decir, la primera vez se crea un proceso completo, pero las siguientes veces que se da servicio a ese mismo servlet se crea un thread que es menos costoso de crear para el sistema operativo una vez cargado en memoria por primera vez comparte ciertos datos como código, variables globales, etc.
Pueden mantener ciertos objetos activos entre distintas peticiones, que sean útiles para posteriores ejecuciones, como por ejemplo pueden mantener un pool de conexiones con base de datos, con lo cual su ejecución es más rápida por no tener que crear conexiones con base de datos cada vez que se ejecuten.
Los servidores pueden protegerse de
servlets escritos con propósitos dañinos mediante el uso
del Java Security Manager, que evite ataques como por ejemplo al sistema
de ficheros del servidor.
Al ser ejecutados totalmente en el
servidor por tanto para su uso no es necesario que en el navegador se habilite
el uso de Java, ya que pueden enviar respuestas exclusivamente con HTML,
pero también pueden hacer uso de applets, JavaBeans, o cualquier
otra tecnología en el cliente si se desea.
Pueden ser independientes del protocolo de comunicación que utilicemos, aunque también hay servlets específicos para el protocolo HTTP que es el más implantado en el Web y por tanto su uso ha sido el más extendido. Si queremos hacer un servlet que sea independiente del protocolo deberemos extender a la clase GenericServlet, mientras que si queremos hacer un servlet específico para comunicación mediante el protocolo HTTP deberemos usar la clase javax.servlet.http.HttpServlet, que en realidad es una clase que contiene toda la funcionalidad de GenericServlet extendiéndola con funcionalidad específica del protocolo HTTP.
Son clases Java normales que contienen dos objetos javax.servlet.http.HttpServletRequest (se usa para recoger la petición desde el cliente, es decir desde el navegador Web, parámetros que recibe, cabeceras HTTP, etc.) y javax.servlet.http.HttpServletResponse (para enviarle la respuesta tras gestionar la petición de su servicio, ponerle cabeceras, etc.), y métodos especiales para recepcionar llamadas desde un navegador Web u otro cliente.
La llamada desde un cliente Web es en forma de URL:
protocolo://servidor:puerto/path_servlet/prog_servlet?params
ej:http://www.sqa.es:8080/servlets/MiServlet?p1=v1&p2=v2&...
Los servlets implementan un mecanismo de control de sesión sobre el protocolo HTTP ya que como sabemos este protocolo no es orientado a la sesión y funciona de forma que gestiona peticiones-respuesta de una manera asíncrona. El mecanismo de sesión de los servlets posibilita el establecimiento de ciertas variables de sesión que el servidor habilita para un determinado cliente. Mediante los servlets podemos acceder y modificar el contenido de estas variables de sesión que serán mantenidas desde que el cliente realiza la primera petición con su navegador hasta que cierra la sesión de su navegador. Esto se consigue mediante el establecimiento de una cookie identificativa de sesión en el navegador por parte del servidor Web, o bien con la inclusión de información en la cabecera de las peticiones/respuesta HTTP, y la asociación de un espacio de memoria en el servidor a este identificativo de sesión en el cual se mantendrán ciertas variables relativas al cliente como pueden ser nombre, preferencias, etc. Ver la clase javax.servlet.http.HttpSession.
Veamos ahora el flujo interno de acciones
que se origina cuando un cliente invoca a un servlet.
Cuando el servidor Web recibe una petición
desde el navegador Web de un cliente, lo primero que hace es ver si el
servlet solicitado está ya cargado en el entorno de ejecución
de servlets del citado servidor. En caso de no estar cargado, lo que sucede
la primera vez que realizamos la petición, el servidor Web utiliza
el cargador de servlets para cargar el servlet deseado desde el dispositivo
de almacenamiento en el que se encuentre, base de datos, disco, etc. Y
posteriormente pasa nuevamente el control al servicio HTTP. Este cargador
de servlets suele ser otro servlet en algunos servidores.
Sin embargo si el servlet hubiese sido
invocado ya en alguna ocasión anterior, el servidor no tendría
nada más que pasarle los parámetros al servlet que queremos
ejecutar, éste procesaría la petición, y devolvería
una respuesta al servicio HTTP, que sería remitida al cliente mediante
el protocolo HTTP.
http://localhost:8080/servlet/ServletEjemplo
El archivo fuente es:
\Curso Java\Java\ejemplos\curso2\ServletEjemplo.java
http://localhost:8080/servlet/ServletEjemplo2?NOMBRE=JUAN&APELLIDO1=LOPEZ&APELLIDO2=
SANCHEZ
El archivo fuente es:
\Curso Java\Java\ejemplos\curso2\ServletEjemplo2.java
http://localhost:8080/servlet/ServletEjemplo3
El archivo fuente es:
\Curso Java\Java\ejemplos\curso2\ServletEjemplo3.java
http://localhost:8080/servlet/ServletPlantilla?NOMBRE=JUAN&APELLIDO1=LOPEZ&APELLIDO2=
SANCHEZ
El archivo fuente es:
\Curso Java\Java\ejemplos\curso2\ServletEjemplo.java
Por útlimo echémosle un vistazo a las clases contenidas en el paquete javax.servlet.http.