Archivo
Introducción básica a los servlets.
Vamos a comenzar estudiando la tecnología Java Servlets.
Como comentamos en la anterior entrada, dentro del mundo Java EE tenemos tres posibles tipos de aplicaciones, aplicaciones Web, objetos distribuidos EJBs y aplicaciones empresariales que no son más que un conjunto de las dos anteriores aplicaciones.
Podemos verlo así o podemos decir que una aplicación empresarial Java EE (archivo .ear) es un conjunto de módulos, siendo un módulo una aplicación Web completa (empaquetada en un archivo .war) o un conjunto de objetos distribuidos EJBs (empaquetados en un archivo .jar).
Visto como lo queramos ver, de una o otra forma, tenemos componentes web (servlets y páginas JSPs) por un lado y componentes EJBs por otro lado interactuando entre sí.
Vamos a dejar de lado todo lo demás y centrarnos en los servlets. Un servlet es un componente Web y se ejecuta en un contenedor Web. Los servlets son componentes que forman parte de una aplicación Web.
Por lo tanto, todos los ejemplos de servlets los desplegaremos sobre una aplicación web creada en Eclipse.
Lo que se suele recomendar cuando se es novato es no utilizar un IDE y construir a mano la jerarquía de directorios estándar de una aplicación web, pero es un poco coñazo, sobretodo configurar el classpath para que todo funcione perfectamente. Así que vamos a utilizar Eclipse para crear, compilar y desplegar aplicaciones web en Tomcat 7, eso sí, aprendiendo siempre lo que el IDE está realizando por debajo.
También veremos como crear, compilar y desplegar una aplicación web manualmente en Tomcat 7.
Crear un proyecto web en Tomcat 7 y desplegarlo desde Eclipse
Para crear un proyecto web vacío en Eclipse pinchamos en File –> New –> Project, desplegamos Web y seleccionamos Dynamic Web Project.
Le damos un nombre a nuestro proyecto, servlet por ejemplo y seleccionamos el servidor Apache Tomcat 7.0 que configuramos en la entrada anterior. Pulsamos en Finish y Eclipse nos creará un nuevo proyecto Web en nuestro workspace.
Si desplegamos el proyecto desde el explorador de proyectos, podemos ver la estructura por defecto que crea Eclipse para los proyectos Web de la plataforma Java EE.
- En la carpeta Java Resources:src guardaremos el código fuente de las clases Java empaquetadas en packages.
- En la carpeta WebContent guardaremos los archivos Web (HTML, JavaScript, CSS, JSP, imágenes, documentos, etc).
- En la carpeta WebContent/WEB-INF guardaremos el descriptor de despliegue web.xml.
- En la carpeta WebContent/WEB-INF/lib guardaremos las librerías externas que utilizemos en la aplicación Web Java.
En la carpeta Java Resources:src, dentro de Libraries, podemos encontrar las librerías de Apache Tomcat 7, donde se encuentra las librerías necesarias para desarrollar servlets, en concreto servlet-api.jar.
Como comentamos en la entrada anterior, la plataforma Java EE es un conjunto de especificaciones y la tecnología de los servlets es una tecnología que cuenta con su propia especificación, de tal forma que cualquier empresa pueda desarrollar un producto que las cumpla. Estamos en esa situación ya que la organización Apache ha desarrollado Tomcat 7, un contenedor Web que nos permite gestionar y ejecutar los componentes servlets, es decir, podemos utilizar ese archivo JAR para desarrollar componentes servlets y desplegarlos en el contenedor Tomcat 7.
Sino utilizaramos ningún IDE, tendríamos que configurar manualmente la variable de entorno CLASSPATH para que apunte al directorio donde se encuentran estas apis, dentro de la carpeta de instalación de Tomcat.
Si seguimos siendo curiosos podemos entrar dentro de la carpeta donde eclipse guarda todo el espacio de trabajo para ver que es lo que está creando por debajo de lo que nosotros estamos haciendo en el IDE. Podemos observar que crea una nueva carpeta por cada proyecto creado y dentro de ella almacena las carpetas src y WebContent comentadas anteriormente, además de una carpeta extra /build/classes, donde almacena las clases Java compiladas empaquetadas en sus respectivos paquetes.
Realmente esta estructura de directorios no es la estructura estándar de directorios de una aplicación web Java. Si seguimos curioseando podemos acceder a la carpeta workspace/.metadata/.plugins/ org.eclipse.wst.server.core/tmp0/wtpwebapps/ y encontraremos una carpeta llamada igual que el nombre de nuestro proyecto. Todos los directorios que conforman esta carpeta si que forman la estructura estándar de una aplicación web Java EE y es la carpeta real que es desplegada dentro del contenedor Tomcat 7.
Si copiaramos esta carpeta dentro del directorio tomcat_install_dir/web-apps/ estaríamos desplegando la aplicación en Tomcat manualmente.
Para desplegar nuestra aplicación web en Tomcat 7 desde Eclipse tenemos que pinchar con el botón derecho del ratón sobre el servidor Tomcat definido en la pestaña Servers, y seleccionar la opción Add and Remove.
Seleccionamos nuestro proyecto y pulsamos en el botón Add para añadirlo a Tomcat 7. Pulsamos Finish y ya tenemos nuestra aplicación web desplegada en Tomcat 7.
Podríamos iniciar Tomcat y probarla pero la aplicación de ejemplo aún está vacía, así que ese paso lo vamos a dejar para más adelante.
Crear un proyecto web y desplegarlo en Tomcat 7 manualmente
Es buena idea, aunque sea solo la primera vez, crear una aplicación manualmente y desplegarla en Tomcat. Una aplicación Web Java tiene una estructura estándar que no es la misma que utiliza Eclipse en su espacio de trabajo.
Lo primero es crear un directorio raíz con el nombre de nuestro proyecto donde colocaremos la aplicación web.
appName/ : El directorio raíz de nuestra aplicación puede contener los elementos típicos de un sitio web, es decir, documentos estáticos HTML, hojas de estilo CSS, archivos JavaScript, imágenes, documentos pdf, etc. En este directorio residen también las páginas JSPs de la aplicación, pero no los servlets.
appName/WEB-INF/web.xml : El descriptor de despliegue de nuestra aplicación. Podemos ignorar este archivo si utilizamos anotaciones en nuestros servlets. Esto es una de las nuevas características de la plataforma Java EE 6 y de la especificación 3.0 de los servlets. Si te has fijado Eclipse no crea un web.xml por defecto.
appName/WEB-INF/classes/ : Este directorio contiene las clases Java utilizadas dentro de la aplicación. En este directorio residen los servlets. Es una buena práctica empaquetar todas las clases en paquetes segun su función dentro de la aplicación.
appName/WEB-INF/lib/ : Este directorio contiene los archivos JAR que serán utilizados por la aplicación, como por ejemplo el conector utilizado para conectarse a una base de datos.
El siguiente paso es configurar la variable de entorno CLASSPATH para que el compilador encuentre el archivo JAR de los servlets. Establecer incorrectamente esta variable es lo que más problemas ocasiona. Introducimos el siguiente comando en la líena de comandos:
SET CLASSPATH = .;install_tomcat_dir\lib\servlet-api.jar;
Si estamos en Windows 7 podemos modificar el CLASSPATH desde Equipo, botón derecho, Configuración avanzada del sistema, Variables de entorno.
Para desplegar el proyecto en Tomcat 7 simplemente tenemos que copiar el directorio raíz al directorio de despliegue de Tomcat, el directorio install_tomcat_dir\webapps. Nuestra aplicación se autodesplegará automáticamente.
Veremos como compilar servlets manualmente y como deben organizarse más adelante.
¿Qué es un servlet?
Los servlets son programas Java que se ejecutan en un contenedor Web dentro de un servidor de aplicaciones y actúan como una capa intermedia entre la petición de un cliente y la aplicación del servidor o la base de datos.
Un servlet puede:
- Leer los datos explícitos enviados por el cliente. Suele ser información introducida en un formulario HTML.
- Leer los datos implícitos de la petición HTTP enviada por el navegador. La información HTTP incluye las cookies, y toda la información que se incluye dentro de la cabecera de una petición HTTP.
- Generar resultados. Este proceso puede requerir comunicarse con la base de datos, ejecutar una llamada RMI o CORBA, invocar un servicio Web o generar la respuesta directamente.
- Enviar datos explícitos al cliente. El documento puede ser enviado en una gran variedad de formatos, ya sea HTML o XML, imágenes GIF o JPG, archivos EXCEL, etc.
- Enviar datos ímplicitos en la respuesta HTTP al cliente. La información HTTP incluye el establecimiento de cookies y cualquier cabecera que pueda enviarse dentro de la respuesta HTTP, como el almacenamiento en caché, etc.
Podemos resumir que un servlet se dedica a responder peticiones HTTP de los navegadores clientes y a generar resultados dinámicos en respuesta a estas peticiones. Los servlets no solo se limitan a responder peticiones HTTP. Existen servlets que pueden ser embebidos en un servidor FTP o en servidores de correo, pero en la práctica solamente se utilizan los servlets que responden peticiones HTTP.
Estructura básica de un servlet
Los servlets normalmente extienden la clase HttpServlet y sobreescriben el método doPost o doGet, dependiendo de si los datos han sido enviados por el método POST o GET. Podemos realizar la misma acción tanto para peticiones GET y POST simplemente llamando a doGet desde doPost o viceversa.
Ambos métodos, doPost y doGet, toman dos argumentos, un objeto HttpServletRequest que encapsula la petición HTTP, y un objeto HttpServletResponse que encapsula la respuesta HTTP. El objeto HttpServletRequest nos permite acceder tanto a los datos como a las cabeceras de la petición HTTP. El objeto HttpServletResponse nos permite modificar la información de salida, como los códigos de estado HTTP o las cabeceras de respuesta.
Además podemos obtener un objeto PrintWriter sobre el que generar el contenido dinámico del documento al cliente.
Los métodos doGet y doPost pueden lanzar las excepciones ServletException y IOexception. Por último, se deben de importar los paquetes java.io (para el PrintWriter), javax.servlet (para el HttpServlet) y javax.servlet.http (para el HttpServletRequest y HttpServletResponse).
Vamos a ver una serie de ejemplos muy básicos de servlets.
Primer ejemplo: Un servlet que genera texto plano:
Vamos a ver como crear nuestro primer servlet. En este caso el servlet generará como salida texto plano con la cadena Hola Mundo!
import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HolaMundoServlet extends HttpServlet { @Override public void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) throws ServletException, IOException { PrintWriter salida = respuesta.getWriter(); salida.println("Hola Mundo!"); } }
Segundo ejemplo: Un servlet que genera HTML:
Para que el servlet genere HTML tendremos que decirle al navegador que le vamos a enviar texto HTML. Esto se consigue estableciendo la cabecera Content-Type a text/html. Generalmente modificamos las cabeceras HTTP desde el objeto HttpServletResponse utilizando el método setHeader pero como establecer el tipo de contenido es una tarea tan común en los servlets, existe el método setContentType. Utilizando este método podemos decirle al navegador el tipo de los datos que le estamos enviando. Por ejemplo si le estuvieramos enviando una imagen gif estableceríamos el Content-Type a image/gif. Al igual que sucede en PHP por ejemplo, las cabeceras HTTP de la respuesta deben enviarse antes del contenido generado.
import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HTMLServlet extends HttpServlet { @Override public void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) throws ServletException, IOException { respuesta.setContentType("text/html"); PrintWriter salida = respuesta.getWriter(); salida.println("<html>\n" + "<head><title>Hola Mundo!</title></head>\n" + "<body>\n" + "<h1>Hola Mundo!</h1>\n" + "</body></html>"); } }
Coñazo, ¿no? Generar contenido HTML desde un servlet no es una buena opción, imagínate tener que estar imprimiendo cada cadena que forma parte del contenido de una página web. Se hace realmente tedioso y difícil de mantener. Por eso surgió la tecnología JSP, para hacernos la vida más fácil. Hablaremos de ella más adelante.
Tercer ejemplo: Empaquetando servlets
Cuando desarrollamos servlets no es buena idea colocar todos en el mismo directorio dentro de la jerarquía de directorios de una aplicación Web. Es una buena práctica empaquetar los servlets en packages para evitar conflictos y poder gestionarlos más fácilmente.
Voy a explicar muy por encima que significa empaquetar los servlets en packages, porque sí has llegado hasta aquí se supone que tienes idea de Java y de lo que significa un package dentro de la jerga de Java.
Para empaquetar una clase a nivel de código fuente basta con utilizar la sentencia: package nombreDePackage; como primera línea del archivo.
Para empaquetar un servlet en una aplicación Web desde Eclipse basta con pinchar con el botón derecho del ratón sobre la carpeta Java Resources:src y elegir la opción New –> Package. Después situamos todas las clases de nuestros ejemplos en este paquete. El IDE Eclipse ya se encarga a la hora de compilar y desplegar de crear el directorio que representa ese paquete tanto en el código fuente como en la carpeta classes.
Si no estamos utilizando un IDE como Eclipse tendremos que crear a mano el directorio con el nombre del paquete dentro del directorio donde estemos desarrollando los ejemplos como en el directorio classes. Además recordar introducir la sentencia package dentro del código fuente de la clase del servlet.
package paquete; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HTMLServlet extends HttpServlet { @Override public void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) throws ServletException, IOException { respuesta.setContentType("text/html"); PrintWriter salida = respuesta.getWriter(); salida.println("<html>\n" + "<head><title>Hola Mundo!</title></head>\n" + "<body>\n" + "<h1>Hola Mundo!</h1>\n" + "</body></html>"); } }
Cuarto ejemplo: Un servlet que utiliza otras clases Java
Tal como sucede con los servlets, es una buena práctica empaquetar todas las clases Java de la aplicación, ya sean servlets, clases de ayuda, beans (los veremos más adelante), etc.
En este ejemplo vamos a crear una clase con un método estático que se encargue de generar el HTML del ejemplo anterior. Es un ejemplo muy básico y soso ya que no tiene mucha miga, pero basta para demostrar que podemos utilizar todo tipo de clases dentro de un servlet. Si la clase esta en otro paquete dentro de la aplicación deberemos importarlo con la sentencia import, de todas formas esto no hace falta que lo diga, porque vuelvo a repetir que eso tiene que estar muy masticado ya.
package paquete; public class GeneradorHTML { public static String generar() { return "<html>\n" + "<head><title>Hola Mundo!</title></head>\n" + "<body>\n" + "<h1>Hola Mundo!</h1>\n" + "</body></html>"; } }
package paquete; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HTMLServletConGenerador extends HttpServlet { @Override public void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) throws ServletException, IOException { respuesta.setContentType("text/html"); PrintWriter salida = respuesta.getWriter(); salida.println(GeneradorHTML.generar()); } }
Compilar los servlets y las clases Java que forman nuestra aplicación
Desde Eclipse no hace falta que compilemos ninguna clase, el IDE se encarga por si mismo de ir compilando al vuelo y notificándonos los errores de sintaxis o de programación que cometemos en el código fuente. Esta es una de las ventajas de utilizar un IDE.
Sino hemos utilizado un IDE mientras seguíamos los ejemplos tendremos que compilar todas las clases Java con el compilador javac mediante la línea de comandos para generar los .class que se situarán dentro de la carpeta WEB-INF\classes de la aplicación.
Voy a suponer que se tiene creada la estructura de directorios estándard de una aplicación web Java, y además está situada en el directorio donde se despliegan las aplicaciones en Tomcat.
Ya habíamos establecido la variable de entorno CLASSPATH para que apuntara al JAR del servlet. Quién no haya utilizado un IDE se habrá creado un directorio de trabajo donde desarrollar las clases Java de la aplicación. Este directorio al menos tiene que tener un directorio llamado paquete que contiene cuatro archivos .java con las clases que hemos desarrollado en los ejemplos.
Mediante la línea de comandos nos situamos en el directorio de trabajo que nos hayamos creado, es decir el directorio que contiene el package principal y compilamos todas las clases Java:
javac paquete\*.java
Si todo ha funcionado bien nos habrá creado cuatro archivos .class que hay que copiar dentro de la carpeta WEB-INF\classes de la aplicación en un directorio llamado paquete. Si nos ha dado algun error seguramente sea porque la variable CLASSPATH está mal configurada.
Como veis es un auténtico coñazo tener que compilar todo a mano mediante la línea de comandos, estar configurando a mano el CLASSPATH y tener que copiar archivos de un lado para otro. Sin mencionar la necesidad de ejecutar los .bat para iniciar y parar Tomcat 7.
Es bueno realizarlo la primera vez, más que nada para saber porque funciona todo, pero de ahora en adelante todos los ejemplos los crearemos en algún IDE como Eclipse o NetBeans.
El descriptor de despliegue
El descriptor de despliegue de una aplicación web (web.xml) es un archivo escrito en XML que describe diversas características de la aplicación web.
Vamos a ver como describir los servlets de la aplicación y poco más. Iremos viendo más adelante como configurar otras características de la aplicación en este archivo.
Si utilizamos un contendor de servlets que implemente la especificación 3.0 de los servlets no es necesario el uso del descriptor de despliegue. Podemo configurar los servlets mediante anotaciones en el propio código fuente.
Una plantilla para la versión 3.0 de la especificación puede ser la siguiente:
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"> <servlet> <servlet-name>Nombre del servlet</servlet-name> <servlet-class>Paquete del servlet.Clase del servlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>Nombre del servlet</servlet-name> <url-pattern>Patron de ruta del servlet</url-pattern> </servlet-mapping> </web-app>
El primer elemento <web-app> indica el inicio de la aplicación, es dentro de este elemento donde se definen todos los elementos restantes.
El elemento <servlet> define las características de un servlet y a su vez está compuesto por los elementos <servlet-name> y <servlet-class> que indican un nombre corto para el servlet así como el nombre de la clase Java que contiene el servlet, respectivamente. La clase Java se indica con la ruta completa de packages.
Posteriormente se define el elemento <servlet-mapping> para establecer la ubicación en términos de URL. Está compuesto por los elementos <servlet-name> y <url-pattern> que especifican el nombre del servlet que será accedido a través del un patrón URL .
Vamos a ver como definir el descriptor de despliegue para describir los servlets que hemos utilizado en nuestra aplicación de ejemplos. Creamos un archivo nuevo en WEB-INF llamado web.xml con el siguiente contenido, tanto si estamos realizando los ejemplos desde Eclipse como si lo estamos realizando manualmente:
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"> <servlet> <servlet-name>ServletEjemplo1</servlet-name> <servlet-class>paquete.HolaMundoServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>ServletEjemplo1</servlet-name> <url-pattern>/ejemplo1</url-pattern> </servlet-mapping> <servlet> <servlet-name>ServletEjemplo2</servlet-name> <servlet-class>paquete.HTMLServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>ServletEjemplo2</servlet-name> <url-pattern>/ejemplo2</url-pattern> </servlet-mapping> <servlet> <servlet-name>ServletEjemplo3</servlet-name> <servlet-class>paquete.HTMLServletConGenerador</servlet-class> </servlet> <servlet-mapping> <servlet-name>ServletEjemplo3</servlet-name> <url-pattern>/ejemplo3</url-pattern> </servlet-mapping> </web-app>
En él hemos definido los tres servlets que hemos explicado en los ejemplos y les hemos establecido la ruta URL de acceso.
El siguiente paso es desplegar la aplicación en Tomcat 7, iniciar Tomcat 7 y acceder a los servlets de ejemplos desde el navegador utilizando las rutas URLs que hemos definidio en el descriptor de despliegue.
Accedemos a los servlets desde el navegador utilizando las siguientes URLs:
http://localhost/servlet/ejemplo1
http://localhost/servlet/ejemplo2
http://localhost/servlet/ejemplo3
Podemos observar que la URL se conforma de la siguiente manera:
http://hostName/appName/servletPattern
También podemos describir los servlets utilizando anotaciones en la clase del servlet. Para poder utilizar las anotaciones debemos de utilizar un contenedor servlet que implemente la especificación 3.0, sino es así debemos de utilizar el descriptor de despliegue.
Para poder utilizar las anotaciones debemos de importar el paquete annotations y utilizar la anotación @WebServlet(“URL-Pattern”). Vamos a ver nuestros tres ejemplos utilizando las anotaciones:
package paquete; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.annotations.*; @WebServlet("/ejemplo1") public class HolaMundoServlet extends HttpServlet { public void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) throws ServletException, IOException { PrintWriter salida = respuesta.getWriter(); salida.println("Hola Mundo!"); } }
package paquete; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.annotations.*; @WebServlet("/ejemplo2") public class HTMLServlet extends HttpServlet { public void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) throws ServletException, IOException { respuesta.setContentType("text/html"); PrintWriter salida = respuesta.getWriter(); salida.println("<html>\n" + "<head><title>Hola Mundo!</title></head>\n" + "<body>\n" + "<h1>Hola Mundo!</h1>\n" + "</body></html>"); } }
package paquete; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.annotations.*; @WebServlet("/ejemplo3") public class HTMLServletConGenerador extends HttpServlet { public void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) throws ServletException, IOException { respuesta.setContentType("text/html"); PrintWriter salida = respuesta.getWriter(); salida.println(GeneradorHTML.generar()); } }
Conclusión
Hemos aprendido:
- que es un servlet
- cual es su estructura básica
- como podemos generar contenido dinámico HTML o texto plano desde un servlet
- como empaquetar servlets
- como acceder a clases Java desde un servlet
- cual es la estructura estandar de una aplicación web Java
- que es un descriptor de despliegue
- como describir los servlets en un descriptor de despliegue
- como describir los servlets mediante anotaciones
- como acceder a los servlets desde el navegador
Hemos aprendido a utilizar Eclipse para :
- crear un nuevo proyecto web vacío
- añadir algunos servlets y empaquetarlos en un paquete (package)
- desplegar una aplicación en Tomcat 7
Hemos aprendido manualmente :
- como configurar el CLASSPATH para utilizar el JAR de los servlets
- como compilar mediante el compilador javac los servlets de ejemplos
- como crear y desplegar manualmente una aplicación en Tomcat 7
En la siguiente entrada seguiremos estudiando los Java Servlets con más detalle. A partir de ahora contaré con que ya sabeis crear una aplicación y añadir servlets para probar los ejemplos que vayamos viendo.
Introducción a la plataforma Java EE
Ya tenemos configuradas algunas herramientas básicas que necesitaremos para el aprendizaje de la plataforma Java EE. Insisto en que son algunas herramientas básicas, que no todas las que vamos a necesitar conforme avanzemos en el aprendizaje de todas las características de esta plataforma.
¿Por dónde empezamos?
He ojeado varios libros sobre la plataforma Java EE y la mayoría de libros comienzan con una introducción bastante detallada sobre lo que es la plataforma Java EE y acto seguido con el uso de algunas tecnologías como JPA o JSF. En mi opinión, seguir uno de estos libros no es una buena curva de aprendizaje, dado que por ejemplo JSF es un framework MVC que utiliza JSP y servlets como base, y nosotros aún no tenemos ni puñetera idea de lo que es un servlet. Esto no quiere decir que sean libros malos, quiere decir que son libros escritos teniendo un poco en mente que los lectores ya han experimentado lo suficiente con versiones anteriores de la plataforma Java EE como para empezar dándole caña al asunto.
Nosotros vamos a utilizar un enfoque un poco distinto, vamos a empezar con una visión bastante detallada de la plataforma Java EE, como en todos los libros. Es decir, vamos a soltar un rollazo tremendo, vamos a contar que tecnologías intervienen, millones de siglas que nos van a asustar mucho pero que no les haremos caso, al menos de momento, ya que aún no estamos preparados para enfrentarnos a ellas.
Después no saltaremos a JSF ni a JPA, ni a nada que empieze por la J. Vamos a empezar por lo más básico de lo básico, los servlets, e iremos escalando poco a poco. Vamos a tardar bastante, mucho más que cualquiera que coja uno de esos libros y empieze directamente por JSF, sólo que a esos les costará bastante entenderlo y para nosotros cuando llegué ese momento, será pan comido.
Plataforma Java EE
Como decíamos en la primera entrada, la plataforma Java EE está destinada a desarrollar aplicaciones empresariales distribuidas, con una arquitectura multi-capa, escritas en el lenguaje de programación Java y que se ejecutan en un servidor de aplicaciones.
Esto es muy cierto, pero Java EE no es un producto de Sun (Oracle), es un conjunto de especificaciones que permiten soluciones para el desarrollo, despliegue y gestión de aplicaciones multicapa centradas en servidor.
¿Un conjunto de especificaciones? ¿Qué quiere decir esto? Esto quiere decir que cualquier fabricante puede coger estas especificaciones y desarrollar un producto final que las cumpla. Sun ha creado una implementación de todas estas especificaciones (Glassfish) pero no es la única empresa.
¿Que es una especificación?
Una especificación no es más que un papelito que detalla cada una de las tecnologías dentro de la plataforma Java EE. Un conjunto de reglas que dictan como debe desarrollarse ese producto de tal forma que se pueda garantizar que una aplicación desarrollada siguiendo las especificaciones de Java EE pueda desplegarse y ejecutarse.
Por ejemplo, los servlets son una tecnología de la plataforma Java EE y como tal, dispone de una especificación. Así, una empresa puede desarrollar un producto que implemente la especificación de los servlets, de tal forma, que ese producto pueda ejecutar servlets. Y así con todas las tecnologías que forman parte de la plataforma Java EE. Con producto nos referimos a un servidor de aplicaciones como Glassfish, o incluso un simple contendor de servlets como Apache Tomcat.
Tecnologías de la plataforma Java EE
- Enterprise JavaBeans (EJB).
- Java Servlet
- JavaServer Page (JSP)
- JavaServer Pages Standard Tag Library (JSTL).
- JavaServer Faces (JSF)
- Java Message Service (JMS).
- Java Transaction API (JTA).
- JavaMail API y JavaBeans Activation Framework (JAF).
- Tecnologías XML (JAXP, JAX-RPC, JAX-WS, JAXB, SAAJ, JAXR)
- JPA, JDBC API
- Java Naming and Directory Interface (JNDI)
- Java Authentication and Authorization Service (JAAS)
¿Cuántas siglas eh? No nos asustemos por ahora, no vamos ni a explicar brevemente en que consiste cada tecnología. Las iremos viendo poco a poco.
Aplicación multi-capa
Hemos dicho que la plataforma Java EE está destinada a desarrollar aplicaciones distribuidas con una arquitectura multi-capa. Esto quiere decir que podemos separar el desarrollo de la aplicación en diferentes capas según su función. Las aplicaciones Java EE suelen ser consideradas aplicaciones de tres capas porque se distribuyen en tres localizaciones, ordenadores clientes, el sistema donde se ejecuta el servidor de aplicaciones, y el sistema donde reside la base de datos.
- La capa del cliente (Client-tier) que es la capa destinada a mostrar la interfaz gráfica de usuario. Las aplicaciones Java EE pueden ser una aplicación Java Swing normal, o una aplicación Web renderizada en un navegador. Esta capa se ejecuta en el ordenador cliente.
- La capa de la lógica de negocio (Business-tier) y la capa de la lógica de presentación (Web-tier). Estas capas se ejecutan en el servidor de aplicaciones.
- La capa de los datos (Data-tier) que es la capa destinada a la gestión de los datos. Esta capa puede separarse a su vez en una o más capas.
Servidor de aplicaciones y contenedores
Como hemos dicho, las aplicaciones empresariales se ejecutan en un servidor de aplicaciones.
Una aplicación empresarial Java EE está formada por un conjunto de módulos donde cada módulo es un conjunto de uno o más componentes que se ejecutan en el mismo contenedor.
Un componente no es más que una unidad de software, puede ser un componente web como una página JSP o un servlet, un componente EJB, etc. Estos componentes se ejecutan dentro de sus correspondiente contenedor dentro del servidor de aplicaciones.
El contenedor no es más que un entorno de ejecución que gestiona los componentes, por eso, los componentes deben de cumplir el contrato que establece el contenedor. Ese contrato no es más que un conjunto de métodos que debe implementar el componente y que permite al contenedor interactuar con él.
Existen dos tipos de contenedores dentro de un servidor de aplicaciones:
- Contenedor WEB encargado de gestionar los componentes servlets y páginas JSP.
- Contenedor EJBs encargado de gestionar los componentes EJBs.
Además cada contenedor proporciona una serie de servicios que el componente puede utilizar. El contenedor es el encargado de gestionar el ciclo de vida de los componentes, realizar la reserva de recursos, etc. Algunos de estos servicios son servicios declarativos, esto quiere decir que algunos servicios se declaran en vez de programarse. La declaración se realiza mediante descriptores de despliegue. Cada módulo dispone de un descriptor de despliegue. El descriptor de despliegue no es más que un archivo XML que describe como se deben desplegar esos componentes en el contenedor del servidor de aplicaciones.
Los módulos que forman una aplicación empresarial pueden ser de tres tipos:
- Archivos JAR (Java Archive): Los archivos JAR permiten agrupar distintos archivos .java en uno solo. Es el empleado para empaquetar componentes EJBs.
- Archivos WAR (Web Application Archive): Los archivos WAR permiten empaquetar en una sola unidad aplicaciones web completas (servlets, páginas JSPs, contenido estático como imágenes y otros recursos Web).
- Archivos EAR (Enterprise Application Archive): Los archivos EAR son archivos desplegables en servidores de aplicaciones JEE. Contienen archivos WAR y EJBs empaquetos en ficheros JAR.
Por lo que podríamos decir que existen tres tipos de aplicaciones Java EE:
- Aplicaciones Web JAVA.
- Objetos distribuidos EJBs.
- Aplicaciones empresariales que engloba a las dos anteriores, aplicaciones web JAVA y objetos distribuidos EJBs.
Puede que todavía andemos un poco perdido sobre lo que es la plataforma Java EE, hemos visto muchos conceptos nuevos que asimilar, muchas tecnologías nuevas a las que enfrentarse, muchas herramientas de desarrollo con las que practicar, vamos, todo un mundo inmenso.
El siguiente paso es ir estudiando poco a poco cada una de las diferentes tecnologías que intervienen dentro de la plataforma Java EE. En la siguiente entrada empezaremos con los SERVLETS.
Instalación y configuración del software necesario para la primera toma de contacto con Java EE: JDK 1.6 de Java, Apache Tomcat 7 y Eclipse IDE.
Antes de comenzar a aprender sobre servlets y JSP (los componentes básicos y necesarios para introducirse en el mundo Java EE) tenemos que instalar y configurar el software necesario.
Pasos a seguir:
1. Descargar e instalar el JDK 1.6 de Java y configurar el PATH.
2. Descargar e instalar Apache Tomcat 7, la última versión disponible de Tomcat que implementa las especificaciones Sevlet 3.0 y JSP 2.2. Tomcat es un servidor web que dispone de un contenedor de servlets y JSP. Está escrito en Java. No es un servidor de aplicaciones empresariales.
3. Configurar el servidor. Este paso consiste en decirle al servidor donde está instalado el SDK, cambiar el puerto al puerto 80 y algunas cosas más.
4. Descargar e instalar Eclipse.
5. Configurar el servidor Tomcat en Eclipse.
PRIMER PASO: Descarga e instalación de Java.
Probablemente ya tengas instalado el JDK 1.6 de la plataforma Java Standard Edition. Sino es el caso:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Accede a la edición standard(Java SE), no a la edición enterprise(Java EE), y descarga el JDK 1.6 ya que es la mínima versión que requiere Apache Tomcat 7 para su funcionamiento.
Las versiones actuales de la API de Servlets y JSP requieren la plataforma Enterprise Edition. Pero como estamos empezando y no vamos a utilizar la mayoría de características de Java EE, como los Enterprise JavaBeans(EJBs) o algunas APIs como Java Messaging Service(JMS) no va a hacer falta descargar el SDK de la plataforma Java EE. El servidor Tomcat ya proporciona las clases necesarias para soportar el uso de servlets y JSP. Mucho más adelante, cuando entremos de lleno en características más avanzadas descargaremos el SDK de la plataforma Java EE y el servidor de aplicaciones GlassFish.
Una vez descargado e instalado el JDK, tendremos que configurar la variable de entorno PATH para que apunte al directorio que contiene el ejecutable de la máquina virtual y del compilador. La manera más rápida es acceder a la consola del sistema y teclear lo siguiente:
SET PATH = java_install_dir\bin;%PATH%
donde java_install_dir es el directorio donde hemos instalado Java.
SEGUNDO PASO: Descargar e instalar Apache Tomcat 7
La página web del servidor Tomcat es: http://tomcat.apache.org/
Accedemos a Downloads –> Tomcat 7.0 y nos descargamos la última versión disponible, a día de hoy, la versión 7.0.5 BETA. Podemos observar que hay muchas formas distintas de descargarse el servidor, pero nosotros nos descargaremos el zip para Windows. Una vez descargado, descomprimimos el zip y ya tenemos Apache Tomcat 7 en nuestro sistema.
TERCER PASO: Configurar Apache Tomcat 7
- Establecer la variable de entorno JAVA_HOME:
Lo primero que tenemos que hacer para configurar Apache Tomcat 7 es establecer la variable de entorno JAVA_HOME indicándole el directorio de instalación del SDK, no el subdirectorio bin. Podemos establece la variable de entorno JAVA_HOME desde la linea de comandos:
set JAVA_HOME=java_install_dir
O podemos editar el script de inicio de Tomcat y establecer allí la variable. Para ello, editamos el archivo catalina.bat situado en tomcat_install_dir\bin y añadimos la misma línea anterior después del primer conjunto de comentarios.
-Establecer el puerto del servidor:
El siguiente paso es especificar el puerto del servidor. En Tomcat, el puerto por defecto es el puerto 8080. Vamos a cambiarlo al puerto 80 por comodidad, así nos evitaremos indicarle al navegador el número del puerto cada vez que escribamos una URL. Para modificar el número de puerto editamos el archivo server.xml situado en tomcat_install_dir\conf. Tenemos que cambiar el atributo port del elemento Connector.
Cambiamos:
<Connector port=”8080″
por:
<Connector port=”80″
- Establecer la variable de entorno CATALINA_HOME:
Establecemos la variable de entorno CATALINA_HOME de la misma forma que hemos editado la variable de entorno JAVA_HOME. La variable de entorno CATALINA_HOME debe apuntar al directorio de installacion de Tomcat.
Ya hemos hecho alguna de las configuraciones necesarias para el funcionamiento correcto de Apache Tomcat 7 como servidor de desarrollo. Ahora podemos iniciar el servidor utilizando el archivo startup.bat situado en tomcat_install_dir\bin. Abrimos el navegador y accedemos a la URL localhost/ y se nos mostrará la página de bienvenidad de Tomcat 7 en la que se nos felicita por haber instalado todo correctamente. Para apagar el servidor utilizaremos el archivo shutdown.bat situado en el mismo directorio.
CUARTO PASO: Descargar e instalar Eclipse
Eclipse es un IDE open-source que nos va a facilitar la vida en muchas tareas tediosas. No es necesario utilizar un IDE para aprender, es más, muchos expertos recomiendan aprender haciéndolo todo a mano. Más tarde cuando ya tengas experiencia puedes empezar a utilizar un IDE.
Pero siendo sincero, es un poco coñazo tener que crear a mano la estructura de directorios de una aplicación, tener que compilar mediante la línea de comandos todas las clases Java que desarrollemos, contando con el infierno que es configurar la variable de entorno CLASSPATH para que todo funcione perfectamente.
En mi opinión un IDE ayuda mucho incluso al novato, o al menos al novato curioso que no se conforma solamente con aprender como funciona un IDE sino que tiene curiosidad de saber que es lo que está pasando a un nivel inferior.
Accede a http://www.eclipse.org/downloads/ y descárgate la versión Eclipse IDE for Java EE Developer.
Descomprímelo y abre eclipse.exe.
Como es la primera vez que se inicia, Eclipse te pedirá que selecciones un directorio de trabajo donde se guardarán todos los proyectos que creemos. Cuando se haya cargado completamente, haz click en el icono Workbench para abrir el espacio de trabajo.
Vale, no nos asustemos, parece una máquina espacial, tiene millones de opciones y no sabemos utilizar ninguna. Poco a poco iremos aprendiendo, sobre la marcha.
Por ahora, vamos a empezar configurando la versión de Java que utilizará Eclipse para todas las tareas. Pinchamos en Window –> Preferences –> Java –> Installed JREs –> Add, y añadimos el directorio donde tenemos instalado el JDK.
QUINTO PASO: Configurar el servidor Tomcat en Eclipse
Ahora vamos a configurar Eclipse para añadir el servidor Tomcat que hemos instalado y configurado. Click en la pestaña Servers, botón derecho sobre el espacio de trabajo de esa pestaña, New –> Server, desplegamos Apache y seleccionamos la opcion Tomcat v7.0, Next, navegamos al directorio donde tenemos instalado Tomcat y Finish.
Veremos como se ha añadido el nuevo servidor a la pestaña Server. Si clickamos con el botón derecho del ratón sobre el servidor se desplegará todas las opciones que tenemos, entre ellas, la opción Start, que como bien imaginaréis, sirve para iniciar el servidor.
Abrimos el navegador, accedemos a la URL localhost/ y ZASCA! nos devuelve un error 404. ¿Qué ha pasado aquí? El problema está en que Eclipse no ha desplegado la aplicación Web por defecto de Tomcat. Así que vamos a tomcat_install_dir\webapps y copiamos la carpeta ROOT en la carpeta temporal que utiliza Eclipse para desplegar las aplicaciones sobre Apache Tomcat.
Esta carpeta está situada dentro del directorio de trabajo que hemos establecido al iniciar Eclipse, en concreto la siguiente ruta, workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmpNUMERO\wtpwebapps, donde NUMERO en este caso será cero porque es el primer servidor que hemos configurado. Pegamos y sobreescribimos la carpeta ROOT dentro de ese directorio. Recargamos localhost\ y veremos la misma página de bienvenida que habíamos visto cuando iniciabamos el servidor directamente desde startup.bat.
Ya tenemos todas las herramientas configuradas para poder utilizarlas en nuestro aprendizaje. La plataforma Java EE es inmensa, cuenta con un gran conjunto de tecnologías utilizadas en cada capa. Nuestro aprendizaje está a punto de comenzar. Nos introduciremos de lleno en el mundo de los servlets. En la próxima entrada estudiaremos un vistazo general a la tecnología de los servlets.
El salto de Java SE a Java EE.
El salto de desarrollar aplicaciones Java utilizando la plataforma Java Standard Edition a desarrollar aplicaciones empresariales Java utilizando la plataforma Java Enterprise Edition puede ser un poco incierto.
El primer paso que solemos dar cuando nos decidimos por aprender una tecnología es recopilar información inicial sobre ella, ya sea buscando en foros, blogs, libros, tutoriales, etc. Por mi parte, suelo empezar intentando comprender una vistazo general de la tecnología en sí.
El problema que tiene Java EE es que es un mundo inmenso lleno de tecnologías que se complementan entre sí y que evolucionan bastante rápido. Además, en mi opinión, lo que es una bibliografía buena en castellano no existe. La mayoría de libros están bastante desactualizados, por no decir, que cuando empezé me recomendaron un libro de introducción a J2EE 1.3, y hoy en día, vamos por la versión Java EE 6, y con vistas de futuro en la versión 7.
La mayoría de documentación disponible y actualizada está escrita en inglés. Existe un tutorial de Sun MicroSystem muy bueno de introducción a la plataforma Java EE pero no me acaba de convencer, ya que lo primero que toca es JSF, un framework MVC de desarrollo de aplicaciones empresariales, y en mi opinión, es mejor establecer una buena base de los conceptos básicos antes de introducirse en el aprendizaje de framewors de desarrollo. Vamos, poco a poco, pero firmes.
Echándole un vistazo a la Wikipedia:
Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de programación—parte de la Plataforma Java—para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de N niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación. Similar a otras especificaciones del Java Community Process, Java EE es también considerada informalmente como un estándar debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a Java EE; estandarizado por The Java Community Process / JCP.
Java EE incluye varias especificaciones de API, tales como JDBC, RMI, e-mail, JMS, Servicios Web, XML, etc y define cómo coordinarlos. Java EE también configura algunas especificaciones únicas para Java EE para componentes. Estas incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), JavaServer Pages y varias tecnologías de servicios web. Esto permite al desarrollador crear una Aplicación de Empresa portable entre plataformas y escalable, a la vez que integrable con tecnologías anteriores. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel.
Asusta, ¿eh? Así, en plan general, podemos destacar que la plataforma Java EE está destinada a desarrollar aplicaciones empresariales distribuidas, con una arquitectura multi-capa, escritas en el lenguaje de programación Java y que se ejecutan en un servidor de aplicaciones. Esta definición podría ser la definición más breve y concisa que podemos dar. Por ahora no nos interesa mucho más, es imposible intentar comprender todo desde un primer momento.
¿Qué más cosas podemos destacar?
1. Estas aplicaciones están escritas en el lenguaje de programación Java, por lo que necesitaremos tener un buen nivel en Java, y eso implica, conocer la programación orientada a objetos, la sintaxis y las características básicas, etc. En definitiva, conocer medianamente la plataforma Java Standard Edition.
Si este no es tu caso no hace falta que sigas leyendo. Mejor pásate por aquí:
donde poco a poco continúa el curso que voy redactando para este blog, o hazte con un libro bueno.
2. No es totalmente necesario, pero es recomendable el uso de un IDE para facilitarnos la vida en algunas tareas tediosas. En la actualidad existen bastantes IDEs que podemos utilizar, NetBeans, Eclipse, JDeveloper, JBuilder, etc. En nuestro caso, de ahora en adelante, utilizaremos Eclipse, por ser un IDE open-source que cuenta con muchos plugins para realizar todo tipo de tareas.
3. Las aplicaciones empresariales se ejecutan en un servidor de aplicaciones. Por lo que vamos a necesitar instalar y configurar uno para el aprendizaje. Como en el caso de los IDEs, en la actualizad existen varios servidores de aplicaciones, podemos utilizar JBoss, GlassFish, etc. En nuestro caso, de ahora en adelante, utilizaremos Apache Tomcat, un servidor web con soporte de servlets y JSPs. Más adelante pasaremos a utilizar un servidor de aplicaciones como GlassFish, pero para el aprendizaje de los conceptos básicos podemos utilizar perfectamente Apache Tomcat.
4. No es la única opción, pero los clientes de esta aplicaciones empresariales suelen ser navegadores web, por lo que la presentación se suele realizar en HTML. Así que sería conveniente tener una idea básica de HTML, y a ser posible algo de CSS para darle algo de estilos a nuestras aplicaciones. También algo de JavaScript nunca viene mal, para cuando llegue el momento de darle un poco más de dinamismo a la aplicación.
5. Ganas de aprender y no desanirmarse por la aparente complejidad de estas aplicaciones. Poco a poco veremos que no es tan complejo como parece en un principio y no nos sentiremos tan abrumados por la cantidad de tecnologías a aprender.
Y esto es todo por hoy, en la siguiente entrada veremos como configurar todas las herramientas que necesitamos (JDK, Eclipse y Tomcat).
Instrucciones de ruptura break y continue en Java
La instrucción break provoca la salida forzada de las estructuras de control continuando la ejecución en la siguiente instrucción.
La instrucción continue provoca la salida forzada de la iteración actual. Si la utilizamos en la estructura de control while se vuelve a comprobar la condición, en cambio, si la utilizamos en la estructura de control for se ejecuta la instrucción de incremento y se vuelve a comprobar la condición.
Hay una segunda forma de utilizar estas instrucciones de rupturas con etiquetas pero no las vamos a explicar dado que suele ser una mala práctica de programación que sigue arrastrando la mítica instrucción goto de los lenguajes más antiguos.
Vamos a ver un ejemplo sencillo en el que utilizaremos estas dos etiquetas:
public class EjemploBreakContinue { public static void main(String[] args) { for(int i=1; i<11; i++){ System.out.println("Número: " + i); if(i == 5) { System.out.println("Saliendo del bucle."); break; } else continue; } } }
