App Web Java EE

DESARROLLO DE APLICACIONES WEB CON JAVA ENTERPRISE EDITION
Junta de Comunidades de Castilla-La Mancha Consejera de Educacin, Cultura y Deportes Sergio Tendero Zapero
Desarrollo de aplicaciones web con Java Enterprise Edition
ndice de contenido
1. Arquitectura Java EE....................................................................................................................................4 1.1. La plataforma Java................................................................................................................................4 1.1.1. El lenguaje Java............................................................................................................................4 1.1.2. Herramientas de desarrollo y ejecucin........................................................................................8 1.2. Ediciones..............................................................................................................................................9 1.3. Java Enterprise Edition.......................................................................................................................11 1.3.1. Modelo de aplicacin..................................................................................................................11 1.3.2. Capas en la arquitectura Java EE................................................................................................14 1.3.3. Contenedores Java EE................................................................................................................17 1.3.4. Empaquetando aplicaciones........................................................................................................20 1.3.5. Java EE API................................................................................................................................22 2. Entorno de desarrollo..................................................................................................................................22 3. Capa Web....................................................................................................................................................25 3.1. Aplicaciones web en Java EE.............................................................................................................25 3.1.1. Introduccin................................................................................................................................25 3.1.2. Ciclo de vida de una aplicacin web...........................................................................................27 3.1.3. Mdulos web..............................................................................................................................27 3.1.4. Configurando aplicaciones web..................................................................................................29 3.2. Tecnologa Java Servlets.....................................................................................................................30 3.2.1. Qu es un Servlet?....................................................................................................................30 3.2.2. Ciclo de vida de un Servlet.........................................................................................................31 3.2.3. Inicializacin de un Servlet.........................................................................................................31 3.2.4. Escribiendo mtodos de servicio.................................................................................................32 3.2.5. Compartiendo informacin.........................................................................................................33 3.2.6. Filtrando peticiones y respuestas................................................................................................34 3.2.7. Invocando otros recursos web.....................................................................................................36 3.2.8. Manteniendo el estado del cliente...............................................................................................37 3.2.9. Finalizando un Servlet................................................................................................................38 3.3. Tecnologa JavaServer Pages..............................................................................................................39 3.3.1. Qu es una pgina JSP?............................................................................................................39 3.3.2. Ciclo de vida de una pgina JSP.................................................................................................40 3.3.3. Creando contenido esttico.........................................................................................................42 3.3.4. Creando contenido dinmico......................................................................................................42 3.3.5. Usando scripting en pginas JSP................................................................................................43
3.3.6. Usando etiquetas en JSP.............................................................................................................44 3.3.7. El lenguaje de expresiones unificado..........................................................................................45 3.3.8. Componentes JavaBeans.............................................................................................................46 3.3.9. Reutilizacin de contenido en pginas JSP.................................................................................49 3.3.10. Transfiriendo el control a otro componente web.......................................................................49 3.4. Arquitectura de la capa web................................................................................................................50 3.4.1. Introduccin................................................................................................................................50 3.4.2. JSP: Modelo 1.............................................................................................................................51 3.4.3. JSP: Modelo 2.............................................................................................................................52 3.4.4. Apache Struts..............................................................................................................................55 3.5. Ajax en Java EE..................................................................................................................................64 3.5.1. Introduccin................................................................................................................................64 3.5.2. Ajax y tecnologas en el lado del servidor Java EE.....................................................................67 4. Capa de negocio..........................................................................................................................................68 4.1. Introduccin........................................................................................................................................68 4.2. Tecnologas y estrategias....................................................................................................................69 4.2.1. Aproximacin POJO JavaBeans..............................................................................................69 4.2.2. Aproximacin EJB......................................................................................................................71 5. Capa de persistencia...................................................................................................................................77 5.1. Introduccin........................................................................................................................................77 5.2. Modelos clsicos de persistencia........................................................................................................77 5.2.1. Persistencia en las clases del modelo..........................................................................................78 5.2.2. Persistencia en clases auxiliares..................................................................................................78 5.3. Mecanismos y tecnologas de persistencia..........................................................................................81 5.3.1. Java Database Connectivity (JDBC)...........................................................................................81 5.3.2. Mapeo Objeto-Relacional. Java Persistence API........................................................................83 6. Comunicacin entre capas y aplicaciones...................................................................................................90 6.1. Introduccin........................................................................................................................................90 6.2. RMI EJBs........................................................................................................................................90 6.3. Servicios Web.....................................................................................................................................92 6.3.1. Introduccin................................................................................................................................93 6.3.2. Axis ............................................................................................................................................95 6.3.3. JAX-WS.....................................................................................................................................96 7. Bibliografa y referencias............................................................................................................................97
Objetivo del curso

Sentar las bases para el desarrollo de aplicaciones web multicapa con la tecnologa Java Enterprise Edition, viendo qu componentes y servicios proporciona la plataforma en cada una de las capas.
1. Arquitectura Java EE
1.1. La plataforma Java
La plataforma Java est conformada por un conjunto de productos y especificaciones software de Oracle Corporation que componen un entorno para el desarrollo y despliegue de aplicaciones software.
1.1.1.
El lenguaje Java
Java es un lenguaje de programacin de propsito general, originalmente desarrollado por James Gosling para la empresa Sun Microsystems y liberado en 1995 como el componente central de la plataforma Java.
La sintaxis del lenguaje deriva de C y C++, pero dispone de un modelo de objetos ms simple y elimina herramientas de bajo nivel, que suelen inducir a numerosos errores, como la manipulacin directa de punteros o memoria.
La implementacin original y de referencia del compilador, la mquina virtual y las bibliotecas de clases de Java han sido desarrolladas por Sun Microsystems desde su aparicin, y 4
continuadas tras su adquisicin por parte de Oracle Corporation. Para ello, en 1998 se cre el Java Community Process (JCP) como proceso formalizado que permite a las diferentes partes interesadas involucrarse en la definicin de nuevas versiones y caractersticas de la plataforma Java. El proceso de definicin est basado en el uso de los Java Specification Request (JSR), que son documentos formales que describen las especificaciones y tecnologas propuestas para que sean aadidas a la plataforma Java.
A nivel de licencias, se han liberado la gran mayora de las tecnologas Java bajo la Licencia Pblica General de GNU (GNU GPL).
Los objetivos de diseo del lenguaje de programacin Java estn dirigidos por la naturaleza de los entornos de trabajo en los que el software debe ser desplegado. En particular, el gran crecimiento de Internet y la World-Wide Web, junto con el comercio electrnico, ha provocado la necesidad de desarrollar aplicaciones seguras, robustas, con un alto rendimiento y con la capacidad de ejecutarse en mltiples plataformas sobre redes distribuidas y heterogneas.
De esta manera, entre los principios de diseo del lenguaje Java podemos destacar: Simple y orientado a objetos: las caractersticas del lenguaje lo hacen fcil de aprender, permitiendo a los programadores comenzar a utilizarlo rpidamente. Adems es orientado a objetos, para aprovecharse de las ms modernas metodologas de desarrollo software y para permitir su uso en aplicaciones distribuidas de tipo cliente-servidor, cuyas necesidades coinciden con los paradigmas de encapsulacin y el paso de mensajes tpicos del software orientado a objetos. Robusto y seguro: uno de los aspectos ms importantes es la alta fiabilidad del software, para lo que se proporcionan comprobaciones en tiempo de compilacin as como en tiempo de ejecucin. Se dispone de un modelo de gestin de memoria muy sencillo, en el cual el programador es el que decide el momento en el que se crea un objeto, y por tanto se ocupa la memoria, mientras que es el entorno de ejecucin, mediante el recolector de basura, el que decide cuando la memoria debe ser liberada. Al estar dirigida a operar bajo entornos distribuidos, la tecnologa Java dispone de una serie de caractersticas de seguridad tanto en 5
el lenguaje como en el entorno de ejecucin que permite construir aplicaciones seguras frente a intrusiones de cdigo malicioso. Portable y arquitectnicamente neutral: al estar dirigido a un entorno eminentemente heterogneo, es necesario que el software se acomode a diversos sistemas operativos, plataformas y que sea capaz de interoperar con mltiples interfaces de programacin; para ello, el compilador de java genera bytecode, que es un formato intermedio que permite transportar cdigo eficientemente sobre mltiples plataformas hardware y software. Este cdigo intermedio podr ser ejecutado en una plataforma especfica a travs de una mquina virtual de Java o Java Virtual Machine (JVM), que interpreta y ejecuta las instrucciones reflejadas en el bytecode segn la plataforma concreta, existiendo as diferentes mquinas virtuales para las diversas arquitecturas. Alto rendimiento: se dispone de diferentes mecanismos que permiten lograr este objetivo, entre ellos destaca la posibilidad de ejecutar mltiples hilos (threads) simultneos, de manera que cada uno de ellos puede realizar una tarea de forma paralela (descargar un fichero, interaccionar con el usuario, etc.); adems de ste, en la interpretacin del cdigo no es necesario volver a comprobar el entorno de ejecucin, el recolector de basura se ejecuta en un hilo de baja prioridad, etc. Interpretado y dinmico: como se coment anteriormente, Java utiliza una ejecucin basada en la interpretacin de un cdigo intermedio (bytecode); esto conlleva algunos beneficios asociados como una mejora en la fase de enlazado del programa, que tiene un carcter dinmico, enlazando slo las clases que se necesitan.
A la vista de estos principios, un ciclo de desarrollo y ejecucin simple en Java implicara escribir el cdigo fuente del programa en ficheros con extensin .java, compilarlos, obteniendo as una serie de ficheros .class que contienen el bytecode o cdigo intermedio y ejecutarlos en una instancia de una mquina virtual.
Como se dijo anteriormente, es posible implementar mquinas virtuales de Java para las diferentes plataformas existentes, permitiendo as ejecutar el mismo bytecode sobre diferentes sistemas operativos, y alcanzado as uno de los objetivos de Java, el write once, run anywhere, es decir, se puede escribir un programa y ejecutarlo en cualquier dispositivo para el que se haya implementado una mquina virtual.
Desafortunadamente, no todo son ventajas, y la interpretacin del cdigo intermedio provoca un rendimiento en ejecucin inferior a los programas que se ejecutan a travs de cdigo nativo. Para minimizar este impacto en el rendimiento se han introducido tcnicas como la compilacin en tiempo de ejecucin o Just-in-time compilation (JIT), que convierte el cdigo intermedio en cdigo nativo durante su ejecucin. Esta tcnica suele estar incluida en las ltimas mquinas virtuales disponibles.
A nivel general, puede decirse que los programas escritos en Java y ejecutados con tcnicas JIT son ms lentos que los generados con lenguajes que utilizan compilacin nativa, como C o C++, de un orden similar a otros que tambin usan tcnicas JIT, como C# u otros de la plataforma .NET, 7
y ms rpidos que los lenguajes que no utilizan compiladores nativos como PHP, Perl, Ruby o Phyton.
1.1.2.
Herramientas de desarrollo y ejecucin
Dos de los principales productos de la plataforma son el Java Development Kit (JDK) y el Java Runtime Environment (JRE).
El JDK es la parte de la plataforma dirigida a los desarrolladores, por lo que incluye tanto el propio lenguaje de programacin Java, como un conjunto de herramientas de desarrollo: el intrprete (java), el compilador (javac), el empaquetador (jar), el depurador (jdb), el generador de documentacin (javadoc), etc. Adems de todas estas herramientas, una distribucin del JDK incluye el conjunto de componentes del JRE.
El JRE proporciona el entorno de ejecucin de aplicaciones Java, para lo cual cuenta con una implementacin del conjunto de libreras estndar (Java API), y la mquina virtual de Java o Java Virtual Machine (JVM), adems de otros componentes adicionales.
De forma anloga a otras plataformas de programacin, el conjunto de libreras estndar proporciona un conjunto de funciones y servicios al programador para la realizacin de tareas comunes: manejo de datos, seguridad, acceso a bases de datos, creacin de interfaces de usuario, etc. Las clases se organizan en la API en paquetes, conteniendo cada paquete un conjunto de interfaces, clases y excepciones. La definicin de la API est controlada por Oracle a travs del programa Java Community Process.
Por su parte, la JVM, es el ente que permite la ejecucin del cdigo intermedio generado por el compilador de Java, obteniendo as la independencia de la plataforma, que es uno de los principales objetivos de esta tecnologa. 8
A continuacin, se muestra un diagrama de la plataforma Java:
1.2. Ediciones
La plataforma Java est dividida actualmente en ediciones, estando cada una de ellas dirigida a un entorno diferente de aplicaciones y contando con un conjunto de libreras estndar que pueden variar en mayor o menor medida.
Java Card: es la edicin dirigida a la ejecucin de aplicaciones Java (applets) en tarjetas inteligentes o 'smart cards' y otros dispositivos similares, siendo los principales objetivos de la tecnologa la portabilidad y seguridad. Tiene su propia definicin de bytecode y de su mquina virtual (Java Card Virtual Machine), as como un conjunto mnimo de libreras, todo ello optimizado para el entorno al que va dirigido. Su uso es frecuente en tarjetas tipo SIM.
Java Micro Edition (Java ME): diseada para su uso en dispositivos mviles como telfonos o PDAs. Se caracteriza por disponer de un conjunto reducido de las libreras de clases de Java que permiten el desarrollo de aplicaciones para estos dispositivos de recursos reducidos. Actualmente se dispone de dos configuraciones, entendidas como un conjunto de libreras bsicas y una serie de capacidades de la mquina virtual. La Conected Limited Device Configuration (CLDC) para dispositivos pequeos y la configuracin Conected Device Configuration (CDC) para dispositivos con unas capacidades superiores. La primera de ellas es la utilizada como estndar de facto para el desarrollo de juegos para mvil. Java Standard Edition (Java SE): es la edicin central de la tecnologa, en la que se fundamentan las dems, y que posibilita el desarrollo de aplicaciones de propsito general, ejecutables en ordenadores personales, servidores y dispositivos similares, ya sea en forma de applets, aplicaciones de escritorio o de consola. Define un conjunto de libreras que conforman su API y que dan servicios de carcter general a las aplicaciones (uso de sistemas de archivos, redes, interfaces grficas, etc.). Java Enterprise Edition (Java EE): se trata de la edicin dirigida al desarrollo de aplicaciones empresariales, multicapa y distribuidas. Para ello se basa en la API de la edicin estndar a la que aade un conjunto de libreras, tales como JDBC, RMI, e-mail, JMS, web services, XML, etc; as como una serie de especificaciones para componentes de la arquitectura Java EE, como Enterprise Java Beans, Connectors, servlets, portlets, Java Server Pages, etc. Por ltimo, aparece el concepto de servidor de aplicaciones Java EE, como una entidad software con capacidad de manejar las transacciones, la seguridad, la escalabilidad, la concurrencia y la gestin de los componentes de la arquitectura que se despliegan sobre l, permitiendo as que el desarrollador se concentre en la implementacin de la lgica de negocio en lugar de la infraestructura o las tareas de integracin.
10
JavaFX: es la edicin ms reciente, estando dirigida al desarrollo de aplicaciones del lado cliente o RIA (rich Internet applications). Dispone de un SDK propio en el que se incluyen herramientas para la compilacin y ejecucin, y una API con soporte para manipulacin de contenidos multimedia, componentes de interfaz de usuario, etc.
1.3. Java Enterprise Edition
La edicin empresarial de Java o Java EE, est dirigida al desarrollo de aplicaciones empresariales, multicapa y distribuidas. Proporciona a los desarrolladores un conjunto potente componentes y servicios que les permite reducir el tiempo de desarrollo, la complejidad de las aplicaciones y mejorar el rendimiento de dichas aplicaciones.
1.3.1.
Modelo de aplicacin
11
Java EE propone un modelo de aplicacin que parte del lenguaje Java y del concepto de mquina virtual que proporcionan la portabilidad y la seguridad.
El modelo est diseado para soportar aplicaciones que implementen los servicios empresariales para clientes, empleados, proveedores, u otros que realicen peticiones o contribuciones a la empresa, siendo por tanto dichas aplicaciones inherentemente complejas en su lgica, con necesidad de acceder a mltiples fuentes de datos y de ser distribuidas a una gran variedad de clientes. Para responder a estos servicios y requerimientos, Java EE define una arquitectura multicapa que proporciona la escalabilidad, accesibilidad y gestin que este tipo de aplicaciones empresariales necesita.
Este modelo divide el trabajo para implementar los servicios empresariales requeridos en dos partes: la lgica de negocio y presentacin, que deber implementar el desarrollador y los servicios estndares del sistema que son proporcionados por la propia plataforma, aportando as al desarrollador soluciones para los problemas de nivel de sistema que implica un servicio implementado bajo una arquitectura multicapa.
En este modelo multicapa y distribuido, la lgica de la aplicacin est dividida en componentes, que realizan diferentes funciones y que pueden estar desplegados en diferentes mquinas dependiendo de la capa a la que el componente pertenezca, es decir, la plataforma Java EE define una arquitectura con una separacin de capas, cada una de ellas con un conjunto de responsabilidades y unos componentes asociados puestos a disposicin del desarrollador para implementar las funcionalidades de cada capa especfica.
12
Un componente Java EE es una unidad funcional de software autocontenida, que se ensambla dentro de una aplicacin con sus clases y ficheros asociados. La especificacin de Java EE define los siguientes componentes: Aplicaciones cliente y applets que se ejecutan en el cliente, perteneciendo as a la capa cliente. Java Servlet, JavaServer Faces y JavaServer Pages (JSP) son componentes web que se ejecutan en el servidor (capa web). Enterprise JavaBeans (EJB) son componentes de la capa de negocio que se ejecutan en el servidor.
Los componentes Java EE estn escritos en lenguaje Java y se compilan de la misma manera que cualquier programa del lenguaje. La diferencia entre las clases Java estndares y los componentes radica en que estos ltimos deben cumplir su correspondiente especificacin, lo cual garantiza su correcta ejecucin y gestin en los servidores Java EE.
13
1.3.2.
Capas en la arquitectura Java EE
El modelo de aplicacin de la plataforma Java EE define una arquitectura multicapa. A continuacin se exponen las responsabilidades y componentes ms importantes asociados a cada capa.
(i)
Capa cliente.
En la capa cliente estn los componentes que interactan directamente con el usuario, permitindole introducir los datos y enviar peticiones. Proporcionan la interfaz grfica de presentacin al usuario y tambin pueden incluir mecanismos de validacin de los datos introducidos por el usuario mediante lenguajes de script. Existen dos tipos de componentes: Clientes web: consisten en dos partes diferenciadas, las pginas web dinmicas que contienen diferentes tipos de lenguaje de marcado y que se generan a travs de los componentes web que se ejecutan en la capa web, y el navegador web, que renderiza las pginas recibidas del servidor. A este tipo de clientes se le suele denominar 'clientes ligeros', ya que la carga de operacin se realiza en el servidor, mientras que el cliente se limita a presentar los contenidos. En ocasiones, una pgina web recibida de la capa web puede incluir un applet, que es una pequea aplicacin cliente escrita en el lenguaje de programacin Java y que se ejecuta en la mquina virtual del cliente. Aplicaciones cliente: se denomina as a las aplicaciones que se ejecutan en la mquina cliente y que permiten disponer de una interfaz ms rica que la que proporcionan los lenguajes de marcado. Adems, estas aplicaciones tienen la posibilidad de acceder directamente a la capa de negocio y pueden implicar procesamiento de datos, por tanto se les suele denominar de tipo 'cliente pesado', estando normalmente basadas en la plataforma Java SE.
14
A la hora de elegir un tipo de cliente u otro, se debe considerar la posibilidad de mantener ms funcionalidad en la parte del cliente (cliente pesado) o concentrarla ms en el servidor (cliente ligero). Mantener ms funcionalidad en el servidor facilitar la distribucin, despligue y gestin de la aplicacin, sin embargo, mantenerla en el cliente permitir mejorar la experiencia del usuario.
(ii)
Capa web
La capa web se encarga de recibir y procesar las peticiones que provienen de la capa cliente, generando contenido dinmico que puede requerir de la interaccin con la capa de negocio, interconectando, por tanto, la capa cliente con la lgica de la aplicacin. Los componentes y tecnologas ms importantes de esta capa son: Servlets: son clases programadas en lenguaje Java y que son capaces de procesar dinmicamente peticiones y construir las respuestas. Se basan en el modelo request response del protocolo HTTP, disponiendo de todo el poder de la API de Java. Pginas JSP: son documentos que se ejecutan como servlets pero que permiten una aproximacin ms natural a la hora de crear contenido esttico, ya que permiten intercalar cdigo Java y JSP con lenguajes de marcado. 15
JavaServer Faces: es una tecnologa que proporciona un framework de componentes de interfaz de usuario a las aplicaciones web.
Al igual que en la capa de cliente, se pueden incluir componentes JavaBeans para gestionar la entrada del usuario y enviar esa entrada a los componentes que se ejecutan en la capa de negocio para su procesamiento.
(iii)
Capa de negocio
Se ocupa de implementar la lgica de negocio necesaria para dar respuesta a los requisitos del dominio de la aplicacin, lo que incluye recibir los datos de la capa cliente y la capa web y procesarlos, emitiendo as los resultados adecuados, y gestionando, si es necesario, la persistencia de la informacin, comunicndose con la capa de sistemas de informacin empresarial.
16
(iv)
Capa de sistemas de informacin empresarial.
Esta capa permite la conexin de la arquitectura Java EE con los recursos empresariales como sistemas ERP, sistemas transaccionales, sistemas de base de datos, u otros sistemas de informacin heredados, con los que la aplicacin necesita comunicarse, por ejemplo para proporcionar conectividad con bases de datos.
1.3.3.
Contenedores Java EE
En las aplicaciones multicapa de cliente ligero clsicas se requieren muchas lneas de cdigo para la gestin de las transacciones, del estado, de la ejecucin multihilo, del pool de recursos y de otros detalles de bajo nivel. Java EE proporciona una serie de servicios subyacentes en forma de contenedor para cada tipo de componente, de manera que el desarrollador puede utilizarlos y centrarse en la resolucin del problema de negocio concreto.
17
Un contenedor es la interfaz entre un componente y la funcionalidad de bajo nivel especfica de la plataforma que soporta el componente. Antes de poder ejecutar un componente deber ser ensamblado en un mdulo Java EE y desplegado en el contenedor correspondiente.
El proceso de ensamblado implica especificar una serie de parmetros del contenedor para los componentes de la aplicacin Java y para la aplicacin en s misma, de manera que dichos parmetros permiten configurar el soporte subyacente aportado por el servidor Java EE, incluyendo servicios como la seguridad, la gestin de las transacciones, el servicio de bsqueda Java Naming and Directory Interface (JNDI), la conectividad remota, etc. Es decir, en funcin de los parmetros especificados al ensamblar la aplicacin, podemos hacer que sta vare su comportamiento sin necesidad de cambiar el cdigo de los componentes. Aparte de estos servicios configurables, los contenedores tambin proporcionan servicios no configurables como la gestin del ciclo de vida de los EJBs y Servlets, la gestin del pool de conexiones a base de datos, la persistencia de datos y el acceso a la API de la plataforma.
La plataforma Java EE define cinco tipos de contenedores: Contenedor de applets: gestiona la ejecucin de los applets. Consiste en un navegador web y un plug-in de Java ejecutndose juntos en el cliente. Contenedor de aplicacin cliente: gestiona la ejecucin de los componentes de la aplicacin cliente. Tanto el contenedor como la aplicacin se ejecutan en cliente. Contenedor web: gestiona la ejecucin de las pginas JSP y los servlets de las aplicaciones Java EE, controlando el ciclo de vida de los servlets y el mapeo entre una URL y un servlet determinado, garantizando que la peticin dispone de los derechos de acceso adecuados. Tambin permiten gestionar algunos componentes EJB para aplicaciones Java EE. Los componentes web y su contenedor se ejecutan en el servidor Java EE. Contenedor de Enterprise Java Beans (EJB): gestiona la ejecucin de los EJBs en las aplicaciones Java EE. Al igual que los componentes web, se ejecutan en el servidor Java EE. Servidor Java EE: es la parte de ejecucin de un producto Java EE, proporcionando contenedores de EJB y web.
18
Estos tipos de contenedores son implementados por diferentes fabricantes, de manera que garanticen la compatibilidad con la tecnologa que implementan. Esto implica que deben ser capaces de proporcionar los servicios asociados al contenedor y a los componentes que ste soporta.
Las implementaciones de servidores totalmente compatibles con Java EE 6, pueden consultarse en: http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html Entre ellos se incluyen: Oracle GlassFish Server 3.x Oracle WebLogic Server 12 JBoss Application Server 7.x Apache Geronimo 3.0-beta-1
Estos servidores de aplicaciones Java EE disponen de contenedores de EJBs y web, pero
19
tambin se pueden encontrar servidores web que nicamente disponen del contenedor web, como por ejemplo Apache Tomcat, que es un contenedor web que implementa las especificaciones de Java Servlets y JSP para generar un servidor web HTTP para Java.
1.3.4.
Empaquetando aplicaciones
Normalmente, el desarrollador no maneja directamente el servidor que se va a utilizar en produccin, por lo que, una vez que se disponga de una versin de la aplicacin estable, sta debera publicarse en el servidor correspondiente. Para ello, Java EE dispone de los mecanismos de empaquetamiento y despliegue, que nos permiten garantizar una correcta publicacin en los servidores de produccin. Una aplicacin Java EE se entrega a travs de un Enterprise Archive (EAR), que es un Java Archive (JAR) estndar con la extensin .ear. Un fichero JAR supone la agregacin de muchos ficheros en uno. Se utiliza para distribuir aplicaciones Java o libreras, incluyendo las clases, los metadatos y los recursos asociados. Para crear el archivo JAR se utiliza el comando jar, incluido en el JDK, que genera un archivo que usa el formato ZIP. Un fichero EAR contiene mdulos Java EE y descriptores de despliegue. Un descriptor de despliegue es un documento XML con extensin .xml que describe los parmetros de despliegue de una aplicacin, mdulo o componente. La informacin del descriptor es declarativa, pudiendo ser cambiada sin necesidad de modificar el cdigo fuente. En tiempo de ejecucin, el servidor Java EE lee el descriptor de despliegue y acta sobre la aplicacin, mdulo o componente en consecuencia, por tanto permite variar el comportamiento de la aplicacin sin variar su cdigo. Se pueden diferenciar dos tipos de descriptores de despliegue, los que se definen a travs de la especificacin Java EE, que permiten la configuracin de cualquier implementacin que cumpla 20
con dicha especificacin; y los dependientes del del entorno de ejecucin, que permiten configurar parmetros especficos de la implementacin Java EE que da el servidor de aplicaciones utilizado. Por ejemplo puede permitir configurar el 'context root' de la aplicacin, el mapeo entre los nombres portables de los recursos de la aplicacin y los recursos del servidor, as como otros parmetros especficos del servidor de aplicaciones como las directivas de cacheo. Los descriptores se incluyen en el directorio META-INF del empaquetado. Un mdulo Java EE consiste en uno o ms componentes Java EE para el mismo tipo de contenedor y un descriptor de despliegue asociado. La especificacin define cuatro tipos de mdulos: Mdulos EJB, que contienen ficheros de clases (.class) de EJBs y el descriptor correspondiente, en el que se pueden incluir aspectos como los atributos de seguridad y transaccin para los beans. Se empaquetan en ficheros JAR con la extensin .jar. Mdulos web, que contienen ficheros de clases de Servlets, ficheros JSP, otras clases de soporte, ficheros HTML, otros recursos estticos, y un descriptor de despliegue de aplicacin web. Los mdulos web se empaquetan con la extensin .war (Web ARchive). Mdulos de aplicaciones cliente, que contienen ficheros de clases y un descriptor de despliegue de la aplicacin cliente. Se empaquetan con la extensin .jar. Mdulos adaptadores de recursos, que contienen todas las interfaces, clases, libreras y documentacin, junto con el descriptor de despliegue del adaptador del recurso, implementando as la arquitectura de conector para un EIS particular. Se empaquetan como ficheros JAR con la extensin .rar (resource adapter archive).
21
1.3.5.
Java EE API
El ltimo componente clave de la plataforma Java EE es la API, ya que, como se coment anteriormente, incluye todas las bibliotecas de Java SE ms algunas adicionales que permiten proporcionar los servicios requeridos por las aplicaciones Java EE.
Veamos una ilustracin con las APIs ms importantes y su relacin con los contenedores:
2. Entorno de desarrollo
El entorno de desarrollo de aplicaciones Java EE tiene dos elementos principales, una herramienta IDE (Integration Development Environment) para el desarrollo y un servidor Java EE 22
para el despliegue y ejecucin. Bsicamente, un IDE es una aplicacin software que proporciona utilidades a los desarrolladores para la construccin de aplicaciones, tales como, editores de cdigo fuente, compiladores, depuradores, herramientas de construccin automticas (build), diagramas de clases, etc. Adems suelen incluir la posibilidad de aumentar sus prestaciones a travs de plug-ins u otros mecanismos de extensin. Para la plataforma Java EE, los IDEs ms conocidos son NetBeans y Eclipse, siendo este ltimo es el que se utilizar en el curso en su versin 'Eclipse IDE for Java EE Developers', que se puede descargar desde http://www.eclipse.org/downloads/ Eclipse es un IDE escrito principalmente en Java, lo que implica que para ejecutarse necesitar tener acceso a un JRE, esto permite que la herramienta sea independiente de la plataforma en la que se ejecuta. Al ser una herramienta de desarrollo, necesita proveer de una serie de utilidades como compilador, depurador, etc. lo cual podra hacerse enlazando con el JDK oficial. Sin embargo, Eclipse incluye el Java Development Tools (JDT) que proporciona una serie de utilidades entre las que destaca: Un compilador incremental de Java, que implementa la especificacin del lenguaje Java. El hecho de ser incremental permite que una vez realizada la primera construccin en las siguientes slo se reconstruye la parte que ha cambiado. El compilador clasifica los problemas encontrados en errores y advertencias. La existencia de una advertencia no afecta a la ejecucin y depuracin del programa. Los errores de compilacin respecto a la especificacin del lenguaje Java siempre se reportan como errores, mientras que para el resto de problemas el desarrollador puede especificar si desea que se reporten como advertencias, errores o que directamente se ignoren. Un asistente de cdigo. Una infraestructura de bsqueda indexada que se usa en la bsqueda, asistencia de cdigo y refactorizacin. 23
Formateador de cdigo fuente.
El compilador de Java de Eclipse cumple con las especificaciones de los distintos JDK disponibles. El desarrollador deber seleccionar para cada aplicacin el nivel de conformidad desea utilizar. Esto provocar que las clases generadas por el compilador debern ser ejecutadas por un JRE del mismo o superior nivel.
Si se desea compilar en Eclipse utilizando el compilador oficial, se podra hacer a travs de la herramienta Ant.
Un servidor Java EE es aquel que es compatible con alguna de las especificaciones de Java EE. En este curso se va a utilizar el Apache Tomcat 7.0.x como servidor web Java EE y JBoss Application Server 7.1.x como servidor de aplicaciones Java EE.
24
Apache Tomcat es un servidor web HTTP de cdigo abierto que implementa las especificaciones de Java Servlet y JavaServer Pages (JSP), por tanto se le puede considerar un contenedor web Java EE. En su versin 7.0.x soporta las especificaciones Servlet 3.0, JSP 2.2 y EL 2.2, por tanto es un contenedor web Java EE 6. JBoss Aplication Server o JBoss AS es un servidor de aplicaciones Java EE de tipo open source desarrollado por JBoss, que es una divisin de Red Hat. Implementa las especificaciones y servicios de un servidor de aplicaciones Java EE completo: EJB, JPA, JAAS, JMS, JNDI, JTA, etc., disponiendo de JBossWeb como contenedor web, estando ste basado en Apache Tomcat. JBoss AS en su versin 7.1.x ha sido certificado como implementacin completa de Java EE 6.
3. Capa Web
3.1. Aplicaciones web en Java EE
3.1.1.
Introduccin
En la arquitectura Java EE, la capa web se encarga de recibir y procesar las peticiones que provienen de la capa cliente, generando contenido dinmico que puede requerir de la interaccin con la capa de negocio, interconectando, por tanto, la capa cliente con la lgica de la aplicacin.
Tpicamente, el cliente enva una peticin HTTP al servidor web, que en el caso de la plataforma Java EE dispondr de un contenedor web. El servidor web se encarga de convertir la peticin a un objeto HTTPServletRequest, que contendr toda la informacin de la peticin, y pasarlo al componente web responsable de tratarla, por ejemplo un servlet o una pgina JSP. El componente web puede generar un objeto HTTPServletResponse o pasarle la peticin a otro componente web. En cualquier caso se generar dicho objeto, que ser convertido por el servidor 25
web en la respuesta HTTP que se devuelve al cliente.
Entre los componentes web nos encontramos a los Servlets y las pginas JSP. Los Servlets son clases del lenguaje de programacin Java que dinmicamente procesan peticiones y generan respuestas; por su parte, las pginas JSP son documentos basados en texto que se ejecutan como Servlets pero con una aproximacin ms natural para crear contenido esttico. Aunque servlets y pginas JSP pueden utilizarse de forma intercambiable, cada tipo de componente tiene sus ventajas. Los Servlets se acomodan mejor a las aplicaciones orientadas a servicios, por ejemplo los puntos de acceso o 'endpoints' de los servicios web se pueden implementar como servlets, y a las funciones de control de una aplicacin orientada a la presentacin. Los JSP son ms adecuados para la generacin de contenido basado en lenguajes de marcado como HTML o XML.
La ltima tecnologa de componentes web incluida en la especificacin de Java EE son los JavaServer Faces, cuyo propsito es el de construir aplicaciones altamente interactivas y orientadas a la presentacin, para lo que generan contenido basado en lenguajes de marcado como XHTML.
Los componentes web son soportados por los servicios del contenedor web, como gestin de las peticiones, concurrencia, seguridad, y gestin del ciclo de vida.
26
3.1.2.
Ciclo de vida de una aplicacin web
Una aplicacin web consta de componentes web, ficheros de recursos estticos (como imgenes), clases de ayuda y libreras. El contenedor web proporciona servicios de soporte que mejoran las capacidades de los componentes web y facilitan su desarrollo. Sin embargo, para poder obtener estos servicios, el proceso de creacin y ejecucin de una aplicacin web vara de otras aplicaciones con clases convencionales.
El proceso de creacin, despliegue y ejecucin de una aplicacin web puede resumirse de la siguiente manera: 1. Desarrollar el cdigo de los componentes web 2. Desarrollar el descriptor de despliegue de la aplicacin web. 3. Compilar los componentes web y las clases de soporte referenciadas por los componentes. 4. Opcionalmente: empaquetar la aplicacin en una unidad desplegable. 5. Desplegar la aplicacin en un contenedor web. 6. Acceder a la URL que referencia la aplicacin web.
3.1.3.
Mdulos web
En la arquitectura Java EE, los componentes web y los contenidos web estticos como imgenes se denominan recursos web. Un mdulo web es la unidad ms pequea de despliegue para recursos web. Un mdulo web Java EE se corresponde con una aplicacin web tal como se define en la especificacin de Java Servlet.
Adems de los componentes web y los recursos web, un mdulo web puede contener otros 27
ficheros: Clases de utilidad que se ejecutan en server-side: para acceso a base de datos, conformes a la arquitectura de componentes JavaBeans, etc. Clases de client-side: applets y otras clases de utilidad.
Un mdulo web tiene una estructura especfica. El directorio raz se denomina 'document root', en l es donde se sitan las pginas JSP, las clases de client-side, los recursos web estticos, etc.
El directorio raz contiene un subdirectorio llamado web-inf, en el se pueden encontrar los siguientes ficheros y directorios: classes: es el directorio que contiene las clases de server-side: servlets, clases de utilidad y JavaBeans. tags: un directorio que contiene ficheros de tag, que son la implementacin de las libreras de tags. lib: el directorio que contiene los archivos JAR con las libreras invocadas desde las clases de server-side. Descriptores de despliegue, como el web.xml, que es el descriptor de despliegue de la aplicacin web, u otros descriptores propios de tecnologas o servidores.
A continuacin se muestra una ilustracin con la estructura de un mdulo web:
28
Si el mdulo web no contiene ni servlets, ni filtros ni compontentes tipo 'listener', entonces no es necesario un descriptor de despliegue de la aplicacin. Es decir, si el mdulo web slo contiene pginas JSP y ficheros estticos no ser necesario incluir un fichero web.xml.
Un mdulo web puede ser desplegado como una estructura de ficheros sin empaquetar, lo que es conocido como un 'exploded archive', o empaquetarse en un fichero JAR conocido como fichero WAR (Web ARchive) utilizando la extensin .war. El mdulo web descrito es portable, pudiendo ser desplegado en cualquier contenedor conforme a la especificacin de Java Servlet.
3.1.4.
Configurando aplicaciones web
Las aplicaciones web se configuran a travs de anotaciones y de los elementos definidos en el descriptor de despliegue de la aplicacin. A continuacin se exponen algunos de las principales tareas a realizar al configurar la aplicacin:
Mapear las URLs a componentes web: dada una peticin recibida por el contenedor web, 29
indicar que componente web debe manejar la peticin. Declarar los ficheros de bienvenida: son los ficheros a utilizar en caso de que una peticin no mapee directamente a un componente web. Si no se especifica nada, se utilizar el index.xxx como pgina de bienvenida por defecto. Configurar parmetros de inicializacin: se pueden configurar parmetros a compartir entre todos los componentes web a travs de un objeto que representa el contexto de la aplicacin. Tambin se pueden indicar parmetros para un componente web especfico. Mapear errores a pginas de error: Se puede especificar un mapeo entre el cdigo de estado devuelto por una respuesta HTTP (p.ej:error 500), o una excepcin del lenguaje java a cualquier componente web. Las pginas JSP tambin permiten especificar una pgina en caso de error. Si se ha definido tanto en el web.xml como en la jsp, esta ltima tiene precedencia. Declarar referencias a recursos: si un componente web usa objetos como enterprise beans, data sources o web services, se pueden utilizar las anotaciones de Java EE para inyectar esos recursos en la aplicacin.
Ver ejemplo: hola
3.2. Tecnologa Java Servlets
3.2.1.
Qu es un Servlet?
La tecnologa Java Servlets supone la respuesta de la plataforma Java a la necesidad de generar contenido dinmico en el servidor ante una peticin de un cliente. Un Servlet es una clase del lenguaje de programacin Java que extiende las capacidades de los servidores que hospedan aplicaciones accedidas por medio del modelo de programacin 30
peticin-respuesta. Aunque los servlets pueden responder a cualquier tipo de respuesta, normalmente se usan para las aplicaciones ubicadas en servidores web. Para estas aplicaciones la tecnologa Java Servlet define una clases servlets especificas para HTTP. Los paquetes javax.servlet y javax.servlet.http proporcionan las interfaces y clases para escribir servlets. Todos los servlets deben implementar la interfaz Servlet que define los mtodos del ciclo de vida. Para implementar servicios genricos se puede usar o extender la clase GenericServlet, mientras que para servicios especficos de tipo HTTP se puede utilizar la clase HttpServlet que proporciona mtodos como doGet o doPost para manejar las peticiones HTTP.
3.2.2.
Ciclo de vida de un Servlet
El ciclo de vida de un servlet es controlado por el contenedor, de manera que cuando una peticin se mapea a un servlet, el contenedor realiza los siguientes pasos: 1. Si no existe una instancia del servlet, entonces carga la clase del servlet, crea una instancia e inicializa el servlet llamando al mtodo init. 2. Invoca el mtodo service pasndole los objetos de peticin y respuesta.
Si el contenedor necesita eliminar el servlet lo finalizar invocando al mtodo destroy.
3.2.3.
Inicializacin de un Servlet
Despus de que el contenedor web cargue y cree la instancia de la clase del servlet, y antes de que comience a atender peticiones, es necesario inicializarlo. En la inicializacin se suelen leer datos de configuracin persistentes, se inicializan recursos, o realizan actividades iniciales; para ello se puede sobreescribir el mtodo init de la interfaz Servlet, sabiendo que este mtodo ser invocado en la inicializacin.
31
3.2.4.
Escribiendo mtodos de servicio
Los servicios proporcionados por un Servlet se implementan a travs del mtodo service de la clase GenericServlet o los mtodo tipo do (doGet, doPost, etc.) de la clase HttpServlet, u otras especficas de otros protocolos.
El patrn general de un mtodo de servicio es extraer la informacin de la peticin, acceder a los recursos y lgica externa y componer la respuesta en base a la informacin obtenida.
(i)
Obteniendo informacin de las peticiones
Una peticin contiene datos pasados entre un cliente y el servlet. Todas las peticiones implementan la interfaz ServletRequest, en particular, las peticiones HTTP implementan la interfaz HTTPServletRequest que extiende a la anterior. Estas interfaces definen mtodos para acceder a la siguiente informacin: Parmetros: se usan para transmitir informacin entre clientes y servlets. Atributos de tipo objeto: se utilizan para pasar informacin entre el contenedor de servlets y un servlet o entre servlets que colaboran. Informacin sobre el protocolo utilizado para comunicar la peticin y sobre el cliente y servidor involucrados en la peticin. Informacin sobre localizacin.
Tambin se puede obtener el flujo de entrada (input stream) de la peticin y obtener los datos manualmente.
En una peticin HTTP se pueden obtener las cabeceras, la consulta realizada, etc.
32
(ii)
Construyendo respuestas
Una respuesta contiene los datos pasados del servidor al cliente. Las respuestas implementan la interfaz ServletResponse que define mtodos que permiten: Utilizar un flujo de salida (output stream) en el que enviar los datos al cliente, ya sean caracteres o datos binarios. Indicar el tipo de contenido devuelto. Por ejemplo: setContentType(text/html). Gestionar el buffer de respuesta al cliente. Indicar informacin de localizacin como por ejemplo la codificacin de caracteres.
Las respuestas a peticiones HTTP usan el objeto HTTPServletResponse que dispone de campos para representar cabeceras como el cdigo de estado (para indicar la razn de una peticin no satisfecha o redirigida) o las cookies, que se utilizan para almacenar informacin en el cliente, como el identificador de cliente que permite el seguimiento de su sesin.
Ver ejemplo: hola
3.2.5.
Compartiendo informacin
Los componentes web a veces necesitan compartir informacin para realizar sus tareas. Para ello, la tecnologa Java Servlets dispone de cuatro objetos de diferente alcance:
Alcance Contexto Web
Clase javax.servlet.ServletContext
Accesible desde Componentes web dentro del contexto web
33
Desarrollo de aplicaciones web con Java Enterprise Edition Sesin Peticin Pgina javax.servlet.http.HttpSession Subtipo de javax.servlet.ServletRequest javax.servlet.jsp.JspContext Pgina JSP que crea el objeto Componentes web manejando una peticin que pertenece a la sesin Componentes web manejando la peticin
Como cualquier otro objeto o recurso compartido es necesario controlar el acceso a estos objetos, ms an al encontrarnos en un entorno multihilo, ya que, normalmente, un contenedor web crea un hilo para manejar cada peticin. Si se quiere garantizar que cada instancia de un Servlet maneja una nica peticin cada vez, este Servlet debera implementar la interfaz SingleThreadModel, asegurando as un acceso exclusivo a los miembros de la instancia. Esta solucin puede tener un aspecto negativo en el rendimiento, ya que las peticiones que gestionase una misma instancia se procesaran secuencialmente; adems la especificacin de Sevlet 2.4 marca esta interfaz como 'deprecated'.
Si realmente se necesita gestionar el acceso concurrente a los recursos, sean o no miembros de un Servlet, lo mejor es utilizar las tcnicas generales de sincronizacin del lenguaje Java, o la gestin de transacciones para datos alojados en sistemas gestores de bases de datos.
3.2.6.
Filtrando peticiones y respuestas
Un filtro es un objeto que puede transformar la cabecera y el contenido de una peticin o una respuesta. Los filtros difieren de los componentes web en que stos normalmente no crear una respuesta, sino que proporcionan una funcionalidad que se puede aadir a cualquier tipo de recurso web. De esta manera, un filtro no debera tener dependencias de ningn recurso web para el cual est actuando como filtro. Las principales tareas que puede realizar un filtro son: Consultar la peticin y actuar en consecuencia. Bloquear el par peticin-respuesta. Modificar las cabeceras y datos de la peticin y/o la respuesta. Para ello proporciona una
34
versin personalizada de la peticin o la respuesta. Interactuar con recursos externos.
Las aplicaciones de los filtros incluyen: autenticacin, logging, conversin de imgenes, compresin de datos, encriptacin, transformacin de XML, etc.
Se puede configurar un recurso web para ser filtrado por una cadena de cero, uno o ms filtros en un orden especfico. Esta cadena se especifica cuando la aplicacin se despliega y se instancia cuando el contenedor carga el componente.
Las tareas involucradas para el uso de filtros son: Programar el filtro: un filtro es una clase que implementa la interfaz Filter, cuyo mtodo principal es doFilter en el que se deben ejecutar las tareas del filtro. Programar la peticin o respuesta personalizada: existen muchas formas de modificar una peticin o una respuesta, por ejemplo aadiendo atributos a la peticin o insertando datos en la respuesta. Para modificar los flujos de entrada o salida, se suele utilizar un objeto tipo 'wrapper' o envoltorio siguiendo el patrn 'Wrapper' o el 'Decorator'. Especificar la cadena de filtros para cada recurso web: un contenedor web utiliza el mapeo de filtros para decidir qu filtros aplicar a cada recurso web, para lo que puede utilizar un nombre o un patrn URL. Los filtros se invocan en el orden en el que el mapeo aparece en la lista de mapeos del WAR, dentro del descriptor del despliegue. Adems, es necesario especificar cmo se aplica a las peticiones: slo cuando viene de una peticin directa, slo cuando proviene de un 'forward', slo cuando se utiliza un 'include', o slo cuando se est utilizando un mecanismo de error, pudiendo indicarse varios tipos de aplicacin al mismo filtro.
Ver ejemplo: holaFiltros
35
3.2.7.
Invocando otros recursos web
Un componente web puede invocar otros recursos web de dos formas: directa e indirectamente. Un componente web invoca a otro indirectamente cuando incluye su URL dentro de la respuesta devuelta al cliente.
La invocacin directa se produce mientras que el componente web se est ejecutando, existiendo dos posibilidades, que el componente web incluya el contenido del otro recurso, o que le transmita el flujo e informacin de la peticin.
Para invocar a otro recurso disponible en el servidor primero se debe obtener un objeto RequestDispatcher, ya sea de la peticin o del contexto web. Dependiendo de donde se haya obtenido ser necesario indicar el camino de acceso al recurso de forma relativa (si se obtiene de la peticin) o de forma absoluta (si se obtiene del contexto web).
(i)
Incluyendo otros recursos en la respuesta
Habitualmente es til incluir otro recurso web en la respuesta, por ejemplo partes estticas a incluir como un anuncio, informacin de copyright, etc. Para ello es necesario invocar al mtodo include (request, response) del objeto RequestDispatcher.
Si el recurso es un componente web, el efecto de la inclusin es enviar la peticin al componente y ejecutarlo, permitiendo que escriba informacin en el cuerpo de la respuesta, pero no que cambie informacin referente a las cabeceras.
36
(ii)
Transfiriendo el control a otro componente web
En algunas aplicaciones es necesario procesar una peticin en ms de un paso, de manera que un componente puede hacer un procesamiento preliminar y otro subsiguiente para generar la respuesta, cuya invocacin puede depender de ese procesamiento preliminar.
Para transferir el control a otro componente web se debe invocar el mtodo forward (request, response) del RequestDispatcher. Es necesario resear que al hacer esto, la URL de la peticin cambiar a la del recurso invocado. Adems este tipo de transferencia solo puede hacerse si no se ha accedido previamente a los objetos ServletOutputStream o PrintWriter, es decir, si no se a empezado a componer una respuesta, ya que esta debera ser construida por el componente al que se transfiere.
Ver ejemplo: holaServlets
3.2.8.
Manteniendo el estado del cliente
Muchas aplicaciones requieren que una serie de peticiones de un cliente estn asociadas entre s, de manera que exista un estado asociado al cliente, que se denomina sesin. Debido a que, normalmente, las peticiones utilizan el protocolo HTTP, que no mantiene informacin de la sesin, la tecnologas Java Servlet ha tenido que proporcionar una API para gestionar las sesiones y mecanismos para implementarlas.
Las sesiones se representan por el objeto HttpSession, que est accesible mediante el mtodo getSession de un objeto peticin. Este mtodo permite acceder a la sesin asociada a la peticin o sino crea una nueva.
37
Una vez que se dispone de la sesin, se le pueden asociar atributos de tipo objeto por nombre, de manera que se harn accesibles a todos los componentes web que accedan a esa sesin, ya sea en la misma peticin o en peticiones sucesivas dentro de la misma sesin.
Debido a que no hay manera de que un cliente indique por HTTP que no necesita ms la sesin, cada sesin tendr un tiempo de vida asociado (timeout) que puede ser accedido y configurado en el propio objeto o tambin a travs del descriptor de despliegue para indicar un tiempo por defecto. Tambin se dispone de un mtodo invalidate que permite terminar la sesin liberando cualquier dato asociado.
Un contenedor web puede utilizar diferentes mecanismos para asociar una sesin con un usuario. Todos ellos se basan en pasar un identificador entre el cliente y el servidor. Este identificador puede estar mantenido en el cliente como cookie o puede ser incluido por el componente web en cada URL que se devuelve al cliente (reescritura de URL).
Ver ejemplo: holaSesion
3.2.9.
Finalizando un Servlet
Cuando un contenedor de servlet determina que un servlet debe ser eliminado (por ejemplo cuando el contenedor requiere memoria o se est apagando), el contenedor invoca el mtodo destroy de la interfaz Servlet. En ese mtodo el programador deber liberar los recursos asociados al servlet y dar persistencia a cualquier dato que se requiera.
En principio, la invocacin a destroy debera hacerse cuando todas las peticiones de servicio se hayan completado, pero podra haber circunstancias en las que esto podra no cumplirse (por ejemplo, por requerir un tiempo superior al esperado o 'de gracia'), en ese caso es necesario 38
asegurarse que todos los hilos que todava estn manejando peticiones se completen, disponindose de diferentes mecanismos para asegurarlo: Mantener un registro de los hilos que estn ejecutando el mtodo service en cada momento. Proporcionar un shutdown limpio, para lo que se deber notificar a los mtodos de larga duracin el shutdown y esperar a que terminen. Tener un pool de mtodos de larga duracin, que pregunten por el shutdown y si es necesario paren y terminen.
3.3. Tecnologa JavaServer Pages
La tecnologa JavaServer Pages (JSP) permite crear contenido web, tanto con componentes estticos como dinmicos, de una manera sencilla. Para ello, esta tecnologa pone a disposicin del desarrollador todas las capacidades de la tecnologa Java Servlet pero proporcionando una aproximacin ms natural para crear el contenido esttico.
Las principales caractersticas de esta tecnologa son: Un lenguaje para desarrollar pginas JSP, que son documentos de texto que describen cmo procesar una peticin y construir una respuesta. Un lenguaje de expresiones para acceder a objetos del lado del servidor. Mecanismos para definir extensiones al lenguaje JSP.
3.3.1.
Qu es una pgina JSP?
Una pgina JSP es un documento que contiene dos tipos de texto: datos estticos, que pueden ser expresados en cualquier formato basado en texto (HTML, SVG, WML y XML), y elementos JSP que permiten construir el contenido dinmico. 39
La extensin recomendada para un fichero de una pgina JSP es .jsp. La pgina puede estar compuesta de un fichero que incluya otros ficheros que pueden contener una pgina JSP completa o un fragmento de una pgina JSP. La extensin recomendada para un fichero de un fragmento es .jspf.
3.3.2.
Ciclo de vida de una pgina JSP
Una pgina JSP atiende peticiones como un servlet, por tanto, el ciclo de vida y muchas de las capacidades estn determinadas por la tecnologa Java Servlet.
Cuando una peticin se mapea a una pgina JSP, el contenedor web comprueba si el servlet de la pgina JSP est obsoleto respecto a la pgina JSP. En caso afirmativo, el contenedor traduce la pgina JSP a una clase Servlet y compila la clase. Por tanto, una de las ventajas de las pginas JSP sobre los servlets es que, durante el proceso de desarrollo, el proceso de construccin se realiza automticamente.
Durante la fase de traduccin, cada tipo de dato de la pgina JSP se trata de forma diferente. Los datos estticos se traducen en cdigo que permite incluir los datos en el flujo de respuesta, mientras que los elementos JSP se tratan de la siguiente manera: Las directivas se utilizan para controlar como el contenedor web traduce y ejecuta la pgina JSP. Los elementos de scripting se insertan en la clase servlet de la pgina JSP. Si se utiliza el lenguaje de expresiones se generan los parmetros para llamar al evaluador de expresiones JSP. Los elementos tipo jsp:[set|get]Property se convierten en llamadas a mtodos de los componentes JavaBeans.
40
Los elementos jsp:[include|forward] se convierten en invocaciones a la API de Servlet.
Java
El elemento jsp:plugin se convierte en lenguaje de marcado especfico del navegador para la activacin de un applet. Las etiquetas personalizadas se convierten en llamadas al manejador de etiquetas que implemente cada etiqueta.
Las fases de traduccin y compilacin pueden producir errores que se observan slo cuando la pgina es solicitada la primera vez, en este caso, el servidor devolver una JasperException y un mensaje de la pgina JSP y la lnea en la que ocurri el error.
Una vez que la pgina ha sido traducida y compilada, el servlet generado sigue el ciclo de vida normal de esta tecnologa: 1. Si no existe una instancia del servlet de la pgina JSP, el contenedor carga la clase, crea una instancia y la inicializa llamando al mtodo jspInit. 2. Se invoca el mtodo _jspService, al que se le pasan los objetos de peticin y respuesta.
Se pueden controlar diferentes parmetros en la ejecucin de una pgina JSP utilizando las directivas de pgina, como las de control del buffer de salida o el manejo de los errores. Este control de errores tiene precedencia sobre el indicado en el descriptor de despliegue de la aplicacin y permite indicar una pgina de error a la que redirigir en caso de ocurra una excepcin durante la ejecucin.
En las pginas utilizadas como pginas de error es habitual incluir la directiva: <%@ page isErrorPage="true" %>. Que hace disponible un objeto de tipo javax.servlet.jsp.ErrorData a la pgina de manera que se pueda obtener y mostrar informacin sobre el error ocurrido.
41
3.3.3.
Creando contenido esttico
Crear contenido esttico en una pgina JSP es tan simple como escribirlo en una pgina que consistiese nicamente en ese tipo de contenido. Este contenido esttico puede ser expresado en cualquier formato de texto: HTML, WML y XML. Al principio de la pgina se incluye una directiva con el atributo contentType para indicar al navegador el tipo de contenido esttico que debe interpretar. Tambin se puede indicar la codificacin de la respuesta haciendo uso de esa misma directiva:
<%@ page contentType="text/html; charset=UTF-8" %>
3.3.4.
Creando contenido dinmico
Se puede crear contenido dinmico accediendo a las propiedades de los objetos. Estos objetos pueden ser: Implcitos: son los que crea el contenedor web y contienen informacin sobre la peticin, pgina, sesin o aplicacin. Especficos de la aplicacin: en muchas ocasiones, el comportamiento de la aplicacin se encapsula en objetos de negocio. Estos objetos pueden ser accedidos mediante etiquetas estndar de JSP o haciendo uso de scriptlets incrustados en la pgina JSP. Compartidos: debido a que las pginas JSP se ejecutan como servlets en multihilo, es necesario garantizar un acceso concurrente correcto a los objetos compartidos, de forma anloga a como se indic con los propios servlets. La directiva isThreadSafe permite indicar si las peticiones a un mismo jsp pueden atenderse de forma concurrente (valor true, que es el comportamiento por defecto) o secuencial (valor false, que implicara generar un servlet que implementase la interfaz SingleThreadModel).
El siguiente diagrama indica los distintos alcances que pueden ser aplicados a cualquier objeto creado: 42
En los siguientes apartados de esta seccin se vern los diferentes mecanismos para acceder a los objetos y componentes, generando as el contenido dinmico.
3.3.5.
Usando scripting en pginas JSP
Los elementos de scripting permiten utilizar sentencias del lenguaje de programacin Java en las pginas JSP. Por tanto, se podrn realizar tareas como acceder a objetos, definir mtodos y gestionar el flujo de control de la manera convencional en el lenguaje Java.
En teora, el uso de scripting en las pginas JSP debera ser sustituido por el uso de etiquetas de libreras, en particular la JSTL, pero en ocasiones se hace necesario utilizar esta alternativa. An as, se proporciona un mecanismo que prohbe el uso de scripting en un grupo de JSP a travs de la inclusin de un elemento scripting-invalid en el descriptor de despligue.
El lenguaje de scripting por defecto es Java; an as se podra utilizar otro lenguaje, para lo cual habra que incluir una directiva informando de esta circunstancia: 43

<%@ page language="scripting-language" %>
Debido a que los elementos de scripting implican el uso de sentencias Java, puede ser necesario importar clases y paquetes usados en la pgina. Para ello se dispone de una directiva de importacin:
<%@ page import="fully-qualified-classname, packagename.*" %>
Se pueden incluir tres bloques o elementos para el uso de scripting: Declaraciones JSP: se usan para declarar variables y mtodos. Estas declaraciones se incluirn en la clase servlet generada a partir de la pgina JSP, permitiendo, por ejemplo, sobreescribir los mtodos jspInit y jspDestroy. Su sintaxis es:
<%! scripting-language-declaration %>
Scriptlets JSP: permiten incluir cualquier fragmento de cdigo con sentencias Java vlidas, que sern insertadas en el mtodo del servicio en el servlet de la pgina JSP, segn la ubicacin en la que se hayan definido en la propia pgina. Su sintaxis es:
<% scripting-language-expression %>
Expresiones JSP: se utilizan para insertar el valor de una expresin basada en el lenguaje de scripting en el flujo de datos que se devuelve al cliente, para lo que el valor de la expresin se convierte a String. Su sintaxis es:
<%= scripting-language-expression %>
3.3.6.
Usando etiquetas en JSP
Las etiquetas son elementos que pueden incrustarse en una pgina JSP y que permiten encapsular tareas recurrentes de todo tipo. Estas etiquetas estn agrupadas en libreras que pueden ser definidas por el usuario.
44
JavaServer Pages Standard Tag Library (JSTL) es un conjunto de libreras que incluyen funcionalidades comunes a muchas aplicaciones JSP. JSTL incluye etiquetas para iteracin, condicionales para manejar el flujo de control, manipulacin de documentos XML, internacionalizacin, acceso a bases de datos usando SQL y otras funciones comunes.
Las etiquetas pueden tener dos formatos distintos:
<prefix:tag attr1="value" ... attrN="value" />
<prefix:tag attr1="value" ... attrN="value" > body </prefix:tag>
Antes de utilizar un conjunto de etiquetas es necesario indicar en la pgina JSP que se va a utilizar una librera de etiquetas a travs de la directiva correspondiente.
<%@ taglib prefix="tt" [tagdir=/WEB-INF/tags/dir | uri=URI ] %>
Si se utiliza una URI absoluta no ser necesario incluir un elemento taglib en el web.xml. Esto, por ejemplo, se suele hacer con las JSTL estndares. Adems, es necesario hacer accesibles a la aplicacin web las clases que implementan la librera determinada. Esto puede hacerse incluyndolas en el WAR o estando disponibles en un directorio comn del servidor de aplicaciones en el que se desplegar la aplicacin. En el caso de las libreras JSTL suelen estar presentes en el servidor.
3.3.7.
El lenguaje de expresiones unificado
A partir de la especificacin de JSP 2.1 se dispone del lenguaje de expresiones unificado,
45
que representa la unin del lenguaje de expresiones ofrecido por JSP 2.0 y el creado para la tecnologa JavaServer Faces.
Este lenguaje permite incluir expresiones que se evalan de forma inmediata o aplazada, acceder a objetos implcitos que mapean los distintos alcances de una aplicacin web, utilizar operadores y palabras reservadas para definir el valor de la expresin, etc.
Estas expresiones pueden utilizarse directamente en el cuerpo del documento o en tags que acepten expresiones en sus atributos.
${!empty param.username} ${pageContext.request.contextPath} ${sessionScope.cart.numberOfItems}
Ver ejemplo: holaJSP
3.3.8.
Componentes JavaBeans
Los componentes JavaBeans son clases Java que pueden ser fcilmente reutilizadas entre aplicaciones. Cualquier clase Java que siga unas ciertas convenciones de diseo ser un componente JavaBean.
La tecnologas JSP soporta directamente este tipo de componentes a travs de sus elementos del lenguaje, permitiendo acceder a los beans definidos a travs de estas clases de una manera sencilla.
Las convenciones de diseo implican que: 46
Las propiedades pueden ser de lectura y escritura, de slo lectura o de slo escritura. Pueden ser simples, es decir, contienen un valor simple, o indexadas, representando un array de valores. Las propiedades deben ser accesibles a travs de unos mtodos de acceso con la siguiente sintaxis:
PropertyClass getProperty() { ... } setProperty(PropertyClass pc) { ... }
Se debe definir un constructor sin parmetros.
Para indicar que la pgina va a utilizar un componente JavaBean se debe utilizar un elemento jsp:useBean como sigue:
<jsp:useBean id="beanName" class="fully-qualified-classname" scope="scope"/>
Se debe indicar el alcance del objeto que puede ser: application, session, request o page, si no existiese el bean se creara.
Una vez instanciado el bean, se puede acceder a sus propiedades utilizando el elemento jsp:setProperty para asignarles valor y jsp:getProperty para consultarlo. Para consultar tambin es posible utilizar una expresin EL.
Cuando se estn desarrollando beans para procesar datos de un formulario, se puede seguir un patrn de diseo haciendo coincidir los nombres de las propiedades de los beans y de los elementos input del formulario. Esto permite que el motor de JSP asigne todos los valores entrantes del formulario que son parte del objeto de la peticin, a las propiedades correspondientes en el bean simplemente incluyendo una sentencia del tipo:
<jsp:setProperty name="user" property="*"/>
47
Esto se consigue gracias a un proceso denominado introspeccin, que permite a una clase exponer sus propiedades bajo peticin. Esta introspeccin es gestionada por el motor de JSP y se implementa a travs del mecanismo de reflexin de Java. Si no existiese una correspondencia de nombres, se podra conseguir el mapeo indicando individualmente cada propiedad:
<jsp:setProperty name="user" property="address" param="parameterName" />
Esta caracterstica de creacin de beans por introspeccin puede ser muy til a la hora de procesar formularios HTML:
La pgina JSP inicial permite crear un bean a partir de un formulario, en ocasiones se les suele denominar 'FormBean', y lo coloca en la peticin, que es enviada a un servlet, este ltimo puede recuperar el bean y por tanto la informacin del formulario de una manera ms sencilla.
El servlet, dentro de sus responsabilidades de procesamiento, puede modificar las propiedades del bean y crear otros beans adicionales. Todos ellos podran ser pasados a una pgina JSP a la que se redirige el flujo y que permite obtener la respuesta devuelta al cliente. 48
Ver ejemplo: holaUsandoBeans
3.3.9.
Reutilizacin de contenido en pginas JSP
Existen diferentes mecanismos para reutilizar contenido JSP en una pgina: La directiva include: es procesada cuando la pgina JSP se traduce al servlet, por lo que su efecto es insertar el texto contenido en otro fichero, ya sea esttico o dinmico, en la pgina JSP con el include. La sintaxis de la directiva es:
<%@ include file="filename" %>
Definir includes en el descriptor de despliegue para un grupo de pginas JSP. Slo pueden colocarse al principio de la pgina include-prelude o al final include-coda.
Utilizar el elemento jsp:include, el cual es procesado cuando la pgina se ejecuta. Si incluye un recurso esttico, simplemente se inserta su contenido en la pgina JSP llamante, mientras que si es dinmico, la peticin se enva al recurso incluido que se ejecuta, siendo el resultado incluido en la respuesta de la pgina llamante.
<jsp:include page="includedPage" />
3.3.10.
Transfiriendo el control a otro componente web
Al igual que en los servlets, tambin se permite transferir el control a otro componente a
49
travs del elemento: jsp:forward. Es necesario que no se haya enviado ningn dato al cliente antes del forward, ya que de otro modo se obtendr una excepcin.
<jsp:forward page="/main.jsp" />
Tanto en el caso de usar jsp:forward, como jsp:include, el contenido de la peticin se pasa al jsp al que se redirige. Adems es posible pasar nuevos parmetros utilizando el elemento jsp:param.
Ver ejemplo: holaJSP
3.4. Arquitectura de la capa web
3.4.1.
Introduccin
Una vez vistas las principales caractersticas de las tecnologas Java Servlets y JavaServer Pages, se est en disposicin de plantear la arquitectura correspondiente a la capa web dentro de una aplicacin web completa.
En los comienzos de la plataforma Java EE, al slo disponer de la tecnologa Servlet, era a travs de esta tecnologa con la que se definan los servlets capaces de atender las peticiones llegadas desde la capa cliente. Al aparecer JSP, esta tecnologa se convirti en la predominante a la hora de implementar la capa web, principalmente, por el hecho de proporcionar un enfoque ms natural para la creacin del contenido devuelto al cliente.
Las arquitecturas basadas en la tecnologa JSP pueden dividirse en dos aproximaciones, 50
llamadas arquitectura JSP Modelo 1 y Modelo 2, que difieren esencialmente en el lugar donde se realiza la mayor parte del procesamiento de las peticiones.
3.4.2.
JSP: Modelo 1
En la arquitectura Modelo 1, la pgina JSP por s sola, es responsable de procesar las peticiones entrantes y responder al cliente. Todava existe separacin entre la presentacin y el contenido, porque todos los accesos a los datos son llevados a cabo mediante Java Beans.
Aunque el Modelo 1 debera ser perfectamente apropiado para aplicaciones simples, puede que no sea deseable para aplicaciones complejas. El uso indiscriminado de esta arquitectura normalmente dirige al programador a escribir una cantidad muy importante de scriptlets de JSP de cdigo Java dentro de las pginas JSP, especialmente si hay una cantidad significante de procesamiento de peticiones dentro de la implementacin. A pesar de que esto no podra parecer un problema para los desarrolladores Java, es realmente un aspecto importante si las pginas JSP son creadas y mantenidas por diseadores (lo cual es lo normal en grandes proyectos).
Ver ejemplo: modelo1
51
3.4.3.
JSP: Modelo 2
La arquitectura Modelo 2 es una aproximacin hbrida para servir contenido dinmico, ya que combina el uso tanto de JSP como de servlets. Por lo tanto, coge las ventajas de ambas tecnologas, usando JSP para generar la capa de presentacin y los servlets para llevar a cabo las tareas de procesamiento. En esta arquitectura, el servlet acta como controlador y est encargado del procesamiento de las peticiones y la creacin de los beans u objetos usados por el JSP, as como de tomar las decisiones acerca de la prxima pgina JSP que se va a mostrar.
Es importante darse cuenta de que no existe procesamiento en las pginas JSP. Ellas slo son responsables de extraer los objetos o los beans que deberan haber sido previamente creados por el servlet, y de extraer la informacin dinmica que estos objetos traen e insertarla en sus plantillas estticas. Esta aproximacin realiza una separacin ms limpia entre la presentacin y el contenido, delimitando los roles y las responsabilidades de los desarrolladores y de los diseadores Web.
Otra de las ventajas de esta aproximacin es que la capa de control presenta un punto de entrada nico a la aplicacin, permitiendo una gestin del estado, seguridad y presentacin ms uniforme y fcil de mantener.
Aunque el Modelo 2 no nombra explcitamente los elementos del Modelo-VistaControlador, en realidad se aproxima mucho a esta arquitectura. De hecho, en muchos mbitos, se
52
usa MVC o Modelo 2 indistintamente.
Desde un punto de vista terico, la arquitectura Modelo-Vista-Controlador (MVC) se basa en aislar la lgica de dominio de la entrada y la presentacin. Para conseguir esto la aplicacin se divide en tres capas, cada una con unas responsabilidades y tareas especficas: El modelo representa los datos de negocio, con la lgica de negocio u operaciones que gestionan el acceso y la modificacin de estos datos de negocio. El modelo notifica a los visores cuando cambia y permite a estos visores consultar el estado del modelo. Adems, permite al controlador acceder a la funcionalidad de la aplicacin encapsulada en el modelo. La vista presenta el contenido del modelo. Obtiene datos del modelo y especifica como se presentan los datos. Actualiza la presentacin de los datos cuando cambia el modelo. Una vista puede transmitir la entrada de un usuario al controlador. El controlador define el comportamiento de la aplicacin. Atiende las peticiones de usuario y selecciona las vistas para la presentacin. Interpreta las entradas del usuario y las mapea en acciones a ser realizadas por el modelo. En una aplicacin web, las entradas del usuario son peticiones HTTP GET y POST. Un controlador selecciona la vista a mostrar basado en las interacciones del usuario y el resultado de las operaciones del modelo.
(i)
Implementando el controlador
En la plataforma Java EE, el controlador suele implementarse a travs de un clase servlet. Este servlet puede ser nico, de manera que se define un punto de entrada comn para todas las peticiones de la aplicacin, siguiendo as el patrn Front Controller.
Este enfoque permite concentrar la gestin de la seguridad, los errores y la asignacin de recursos a las peticiones (por ejemplo, conexiones a bases de datos), sin embargo, concentrar todas las peticiones en una nica clase implica incluir una gran cantidad de procesamiento dependiente de la peticin a tratar, generndose un cdigo con una baja cohesin y poco escalable y mantenible.
53
Para evitar estos problemas, pueden adoptarse diferentes soluciones que mejoran la calidad del controlador.
1)
Switch - case
Si se tiene un nmero de tipos de peticiones relativamente bajo, cuatro o cinco, es posible implementar el controlador con una nica clase que dispone de un bloque switch-case en el que en funcin de un valor, se selecciona el tipo de peticin a tratar.
El valor que identifica la peticin puede ser pasado como parmetro a travs de un campo oculto del formulario que genera la peticin, o puede venir codificado en la propia url de la peticin.
En cualquier caso, se podr obtener un valor que indique el bloque case a ejecutar que no debera implicar una gran cantidad de lgica.
2)
Patrn Comando
Si el nmero de tipos de peticiones es alto o requieren de una gran cantidad de lgica, se suele utilizar el patrn Comando. Este patrn implica la definicin de una clase especfica para cada peticin o accin, que presenta una interfaz uniforme a travs de la implementacin de un mtodo cuya invocacin da como resultado la ejecucin de la lgica de negocio, y cuyo resultado determina el componente de la vista a cargar.
54
Al igual que en el enfoque switch-case, es necesario indicar al controlador que comando es el que debe ejecutarse a consecuencia de una peticin determinada. Para ello, siguen siendo vlidos los mecanismos de paso de parmetros o codificacin en la url de la peticin. En funcin del valor de la accin a realizar, se instanciar la clase del comando a ejecutar, normalmente haciendo uso de una Fbrica.
La siguiente ilustracin muestra un resumen de la arquitectura Modelo 2 / Modelo-VistaControlador enriquecida con el uso de los patrones de diseo Front Controller y Command.
3.4.4.
Apache Struts
Apache Struts es un framework de cdigo abierto para el desarrollo de aplicaciones web Java EE.
Su objetivo es crear un entorno de desarrollo de aplicaciones con un alto grado de escalabilidad y mantenibilidad. Para ello, implementa el patrn de diseo Modelo-Vista55
Controlador a travs del uso de tecnologas estndar, como Servlets, JavaBeans, ResourceBundles, XML, libreras de etiquetas, entre otras, proporcionando al desarrollador un marco de trabajo con un conjunto de clases y utilidades que permiten y facilitan la creacin de aplicaciones web.
A continuacin se vern los aspectos y componentes ms importantes que aporta Struts. Con fines didcticos se ha utilizado la versin Struts 1.3 como base de la explicacin.
(i)
ActionServlet
Struts proporciona un controlador a travs de la clase ActionServlet, que hereda de HttpServlet. Esta clase se instancia al iniciar la aplicacin y carga toda la informacin sobre los mapeos (ActionMapping) que determinan el control de flujo. De esta manera, todas las peticiones que llegan desde el cliente son recibidas por el controlador ActionServlet, y en base a la informacin de mapeos realiza una serie de actividades pasando el flujo de control al componente adecuado (normalmente un Action).
56
(ii)
ActionMapping
La informacin sobre el mapeo o control de flujo est representada a travs de la clase ActionMapping. Esta clase encapsula informacin de configuracin que normalmente es obtenida a travs del procesamiento de un XML.
Los elementos ms importantes que se incluyen en el archivo de configuracin son: <form-beans>: contiene la definicin de los beans de formulario (ActionForm) que podrn ser instanciados en la aplicacin. <global-forwards>: define instancias de la clase ActionForward que pueden utilizarse a nivel global para dirigir el flujo de la aplicacin, identificndolas a travs de un nombre lgico. <action-mappings>: permite definir las acciones del sistema en base a un conjunto de propiedades: type: nombre completo de la clase que implementa la accin. name: nombre del bean de formulario que se va a usar en esta accin. path: define la ruta de la peticin que implica ejecutar la accin. validate: permite indicar si se deben realizar las validaciones previas a la ejecucin. forward: para cada accin se pueden definir posibles caminos de flujo.
Simplemente se han descrito las propiedades ms relevantes. Para la relacin completa, se puede consultar el DTD que debe cumplir el archivo de configuracin.
El archivo XML suele llamarse struts-config.xml, aunque es posible utilizar varios, que pueden definir mdulos o dominios distintos dentro de la aplicacin.
57
(iii)
ActionForm
Una de las principales tareas en el desarrollo de una aplicacin web es ser capaz de gestionar la entrada del usuario, hecha normalmente utilizando etiquetas de formularios HTML. Struts proporciona la clase ActionForm como mecanismo de captura y validacin de la entrada, representando cada clase que extienda de ActionForm un formulario de una o ms pginas.
Las clases ActionForm no requieren de la implementacin de ningn mtodo especfico, pero suelen seguir las convenciones de codificacin de los componentes JavaBeans, es decir, definen propiedades y sus mtodos de acceso. De esta manera, el framework de Struts es capaz de asignar los parmetros de la peticin a las propiedades del bean de formulario, a travs de introspeccin, validarlos y si todo es correcto, pasarlos a la accin (clase Action) que debe tratar la peticin.
Un ActionForm puede ser utilizado por una o ms acciones. Para ello, simplemente es necesario indicarlo en la definicin del ActionMapping de la accin. Cuando el flujo de control pase a la accin, sta tendr disponible una instancia del ActionForm indicado con la informacin de los parmetros introducida por el usuario. La accin puede recuperar esta informacin para interaccionar con el modelo e incluso puede modificarla como consecuencia de su ejecucin, ya que, al seguir normalmente las convenciones JavaBeans, el ActionForm puede ser utilizado para pasar informacin a la vista, la cual acceder a travs de los mecanismos y etiquetas habituales de los beans.
En cuanto a la validacin, la clase ActionForm incluye el mtodo validate, que es invocado por el controlador despus de que se hayan rellenado las propiedades del bean y antes de pasar el flujo de control a la accin. Este mtodo tiene una implementacin por defecto que devuelve null, que indica que no se han producido errores de validacin y que se puede invocar a la accin; el desarrollador puede sobreescribirlo realizando las validaciones que considere apropiadas y devolviendo un listado de ActionErrors en caso de que se encuentren problemas.
58
Una aproximacin comn es realizar validaciones iniciales usando el mtodo validate, y luego manejar la validacin de la lgica de negocio desde el objeto Action.
Struts proporciona el plug-in Struts Validator que contiene un conjunto de reglas de validacin bsicas y que puede ser ampliadas con facilidad.
(iv)
Action
La clase Action es la encargada de procesar las solicitudes. El controlador deber evaluar la informacin sobre la peticin y en base a la informacin sobre los mapeos, decidir qu clase Action es la que debe tratarla, invocando al mtodo execute de la clase. Este mtodo recibe tanto los objetos que representan la peticin y la respuesta (HttpServletRequest y HttpServletResponse para una peticin http), como un objeto ActionForm con la informacin de los parmetros pasados por el usuario y el objeto ActionMapping que le facilitar la tarea de reenvo del control a otra accin o a un componente de la vista.
Tpicamente, en el mtodo execute se realizan las siguientes tareas: Se valida el estado actual de la sesin del usuario, comprobando si se ha autenticado correctamente; sino, podra redirigirse a una pgina que le permita introducir sus credenciales u otra informacin de autenticacin. Esto podra ocurrir porque un usuario intente entrar "en el medio" de una aplicacin, o porque la sesin ha expirado y el contenedor de servlet cre una nueva. En otras ocasiones, la responsabilidad sobre la autenticacin y autorizacin de la aplicacin se lleva a cabo mediante filtros (interfaz javax.servlet.Filter) que pueden apoyarse en alguna API o framework de seguridad. Se pueden realizar validaciones sobre la informacin que viene en la peticin, ya sean complementarias o no a las que se hacen a travs del ActionForm. Si se encuentra un problema, se pueden almacenar las claves de los mensajes de error apropiados como un atributo de la peticin, y reenvar el control de vuelta al formulario de entrada para que se puedan corregir los errores. 59
Una vez hechas todas la validaciones, se realiza el procesamiento requerido por la accin, lo cual suele implicar comunicarse con la capa de modelo que implementa la lgica de la aplicacin. A partir de la informacin recuperada del modelo, se pueden actualizar los objetos, normalmente de tipo JavaBean, que sern utilizados por el componente de la vista para mostrar el resultado al usuario. Estos objetos pueden tener un mbito de solicitud o de sesin, dependiendo de cunto tiempo se necesite mantener estos tems disponibles. Finalmente, y tambin en base al resultado obtenido en el procesamiento, la accin devuelve un objeto ActionForward que identifica el componente de la vista al que se le debe pasar el control. Para facilitar la determinacin del ActionForward a devolver se puede hacer uso de la informacin de mapeo disponible en el ActionMapping pasado al mtodo execute.
Es necesario tener en cuenta algunas consideraciones a la hora de codificar clases de accin: El servlet controlador crea un slo ejemplar de cada clase Action, y la usa para todas las solicitudes. Por tanto, deber estar codificada para operar correctamente en un entorno multi-thread (multihilo), al igual que si se estuviese codificando un servlet. Hay dos principios fundamentales: Utilizar solamente variables locales a los mtodos, y no variables de instancia en la clase Action, ya que las variables locales se crean en una pila que es asignada por la JVM a cada hilo individual (hay un hilo por cada peticin). Si es necesario pasar informacin entre los mtodos de la clase, se deberan pasar cmo parmetros. Si se utilizan variables de instancia habr que prever un posible acceso concurrente. Como regla general, asignar recursos (como las conexiones a una base de datos) y mantenerlos a travs de las solicitudes del mismo usuario (guardndolos en la sesin) puede causar problemas de escalabilidad. Es conveniente liberar esos recursos antes de reenviar el control al componente de la vista apropiado y si vuelven a ser necesarios, se reasignarn en la siguiente solicitud. Durante las tareas realizadas en la accin se pueden obtener excepciones; es importante capturarlas y tratarlas adecuadamente, ya que si se lanzasen podran llegarle al usuario de la
60
aplicacin directamente. Adems, en el tratamiento es importante liberar cualquier recurso que pueda haber quedado asignado.
(v)
Aportaciones a la vista
El framework de Struts utiliza las tecnologas bsicas de Java EE para la vista, tanto JavaServer Pages como libreras de etiquetas, a las que aade un conjunto de utilidades y componentes que van dirigidos a facilitar el desarrollo de esta capa, entre los que destacan: Mensajes internacionalizados: tomando como base las clases de internacionalizacin y localizacin de la plataforma Java (Locale, ResourceBundle, PropertyResourceBundle, MessageResource), Struts permite definir archivos de mensajes pueden ser utilizados desde los componentes de la vista para mostrar al usuario la informacin en el lenguaje escogido. Librera de etiquetas: Struts incluye un conjunto de etiquetas personalizadas para JSP que ayudan a los desarrolladores tanto en la gestin y acceso a los beans (incluyendo los ActionForms), la creacin de formularios basados en etiquetas HTML o XHTML (en los que se pueden incluir mensajes internacionalizados), y la gestin del flujo a travs de etiquetas de lgica e iteracin. Composicin de pginas con Tiles: Struts proporciona un sistema de plantillas que permite construir la vista combinando varios elementos o 'tiles'.
(vi)
Request Processor
Para finalizar, es conveniente recordar el flujo de control que implica el uso del patrn Modelo-Vista-Controlador y su implementacin mediante Struts. Para ello, la mejor manera es presentando el componente Request Processor.
El Request Processor se encarga de controlar los pasos de procesamiento que atraviesa una 61
peticin entrante. Para ello sigue el patrn de diseo Chain of Responsability que le da una gran flexibilidad y capacidad de ser personalizado, aadiendo nuevos pasos, y eliminando o modificando el orden de los existentes. A continuacin, se muestra la secuencia de pasos por defecto (en la que se han excluido algunos para simplificar la exposicin): Seleccionar la informacin sobre localizacin de la peticin. Almacenar la URI de la peticin. Incluir cabeceras en la respuesta (pragma, cache-control, expires, etc.). Seleccionar el tipo de contenido y la codificacin de la respuesta (content-type, characterencoding). Determinar el ActionMapping asociado con la ruta de la peticin. Si el mapeo tiene informacin de roles que lo pueden ejecutar, comprobar que el usuario actual dispone de esos roles. Instanciar o recuperar el ActionForm asociado a la accin seleccionada. Rellenar las propiedades del ActionForm con los parmetros que vienen en la peticin. Realizar la validacin del ActionForm. Si la validacin falla, se vuelve a la pgina de entrada informada en el mapeo. Instanciar la clase de la accin e invocar su mtodo de ejecucin, pasando la informacin de peticin y respuesta, ActionForm y mapeo (ActionMapping). La accin devuelve un ActionForward que permite al RequetProcessor redirigir el flujo al componente adecuado, normalmente de la vista.
Un posible paso a aadir sera el procesador de Tiles, que es necesario ejecutar si estamos utilizando este componente en nuestra aplicacin.
(vii)
Descriptor de despliegue de la aplicacin
62
En los archivos de configuracin tipo struts-config.xml se le indica al controlador de Struts cmo debe procesar cada una de las peticiones que le llegan. Para definir qu peticiones le van a llegar al controlador es necesario incluir en el descriptor de despliegue de la aplicacin (web.xml) su declaracin como servlet.
En la declaracin se indica la clase que implementa el controlador de Struts (ActionServlet) y los ficheros de configuracin; adems, se indica que este servlet debe cargarse al iniciar la aplicacin, momento en el que recupera toda la informacin del mapeo de dichos ficheros.
En cuanto a las peticiones que sern procesadas por el controlador de Struts, se incluye una declaracin con el patrn de urls a asignar, tpicamente *.do, aunque podra ser cualquier otro.
Ver ejemplo: struts
(viii)
Struts 2
Struts 1 consigui convertirse en el estndar de facto para el desarrollo de aplicaciones web Java EE, sin embargo, con el tiempo surgi la necesidad de crear una nueva generacin del framework cuyo principal objetivo era mejorar su facilidad de uso. As, a partir del proyecto WebWork junto con la versin inicial del framework se desarrolla Struts 2, que sigue las directrices bsicas de Struts 1, mejorando su implementacin del patrn MVC.
Entre las caractersticas ms novedosas destacan las mejoras en el diseo con el objetivo de que las clases desarrolladas sean lo ms independientes posibles tanto del propio framework de Struts como de la API de Servlet. Esto se traduce a que, por ejemplo, las clases de accin ya no estn obligadas a heredar de Action, ni tampoco deben incluir un mtodo execute que reciba la informacin de la peticin y la respuesta http, ni un ActionForm, ya que la captura de la entrada puede hacerse a travs de las propiedades de la propia clase que acta como accin; por tanto, 63
cualquier mtodo incluido en la accin puede actuar como manejador de la peticin, aunque habitualmente se incluye un execute sin parmetros. Adems, para el intercambio de informacin con la vista, en lugar de los habituales espacios de objetos de la API Servlet (application, session, request, page), Struts 2 recomienda el uso de ValueStack para independizar as las acciones de la tecnologas Servlet y facilitar el acceso a la informacin; en cualquier caso, los alcances habituales siguen estando disponibles para su uso en el contexto de la accin (ActionContext).
Otras aspectos a resear son la inclusin del lenguaje de expresiones "Object Graph Notation Language" (OGNL), con el propsito de facilitar el acceso a la informacin desde la vista, as como la conversin de tipos, o un nuevo framework de validacin Xwork, aunque se sigue conservando la posibilidad de hacer una validacin tradicional a travs de la implementacin de un mtodo validate en la accin.
Para ver una lista completa de mejoras y diferencias con struts 1 puede consultarse el enlace oficial: http://struts.apache.org/2.1.6/docs/comparing-struts-1-and-2.html
Ver ejemplo: struts2
3.5. Ajax en Java EE
3.5.1.
Introduccin
Ajax es el acrnimo de Asynchronous JavaScript And XML, constituyendo una tcnica o
modelo interaccin que emplea diferentes tecnologas de la Web con el objetivo de mejorar la interactividad y usabilidad de las aplicaciones.
Ajax permite realizar una peticin desde el navegador al servidor en segundo plano, es decir,
64
de forma asncrona y sin interferir en la visualizacin y el comportamiento de la pgina que se est mostrando. Esta peticin normalmente implica un intercambio de datos con el servidor, cuya respuesta recibida en el navegador suele causar cambios en la informacin mostrada al usuario. Por tanto, una accin en el cliente provoca una comunicacin con el servidor, transparente al usuario, que tendr como resultado una modificacin en el estado del cliente.
A continuacin se indican las tecnologas que habitualmente se utilizan para implementar la tcnica Ajax: Lenguajes de marcado como HTML o XHTML, y CSS para la presentacin de la informacin. El Document Object Model (DOM) accedido mediante el lenguaje de scripting para mostrar e interactuar dinmicamente con la informacin presentada. Un objeto XMLHttpObject como vehculo de la comunicacin entre cliente y servidor. XML o JSON (JavaScript Object Notation) como estndar para el intercambio de datos. JavaScript como lenguaje de scripting que permite la colaboracin del resto de las tecnologas utilizadas.
El XMLHttpObject es uno de los elementos clave en Ajax, siendo una interfaz que permite la realizacin de peticiones HTTP desde un navegador. Esta interfaz es implementada de forma integrada por los principales navegadores del mercado, pero, aunque se ha desarrollado una especificacin estndar, pueden existir diferencias en la implementacin concreta de cada uno.
La clase que implementa XMLHttpObject contiene un conjunto de atributos, mtodos y eventos que permiten gestionar el dilogo con el servidor; dando soporte a la creacin y envo de la peticin, al seguimiento de su estado y a la recuperacin del resultado devuelto.
La siguiente ilustracin muestra un clsico escenario de interaccin mediante Ajax:
65
1. Un usuario genera un evento en el cliente, provocando la invocacin de una funcin Javascript. 2. La funcin Javascript crea y configura un objeto XMLHttpRequest, especificando la funcin que recoger el resultado (callback). 3. Se realiza una peticin asncrona al servidor a travs del objeto XMLHttpRequest. 4. El servidor web procesa la peticin y devuelve el resultado, en este caso en XML. 5. Al recibir la respuesta, el objeto XMLHttpRequest invoca a la funcin Javascript encargada de procesar el resultado. 6. La funcin de procesamiento analiza la respuesta recibida y normalmente modifica la informacin mostrada al usuario a travs del DOM.
Entre los posibles usos de Ajax se pueden citar: la validacin de datos en servidor en tiempo real, el autocompletado de campos, la carga de datos bajo demanda, la recarga automtica de informacin de la pgina, etc.
66
3.5.2.
Ajax y tecnologas en el lado del servidor Java EE.
Segn lo visto hasta el momento, todas las tecnologas que utiliza Ajax pertenecen al lado cliente o son formatos de intercambio de informacin entre cliente y servidor. Sin embargo, queda claro que uno de los aspectos ms importantes es el procesamiento en servidor de la peticin HTTP que se genera a travs del objeto XMLHttpRequest. Para un servidor, el manejo de una peticin Ajax no es diferente al de cualquier otra peticin. Por tanto, en un entorno Java EE se pueden utilizar las tecnologas de procesamiento de peticiones convencionales, como son Java Servlets, JavaServer Pages o JavaServer Faces. A partir del uso de las tecnologas de servidor Java EE disponibles, pueden identificarse diferentes estrategias de diseo puestas a disposicin del desarrollador, de manera que pueda elegir la que considere ms adecuada. A continuacin se exponen tres de las ms habituales: Tecnologas base: en la que el desarrollador utiliza directamente las tecnologas de Ajax, encargndose de la codificacin de las funciones Javascript, el manejo del objeto XMLHttpRequest, teniendo en cuenta sus peculiaridades en funcin del navegador, y los aspectos de presentacin de la informacin, accediendo al DOM. En el lado servidor, codifica el componente web, que habitualmente ser un Servlet, para que reciba la peticin y genere la respuesta. Uso de una biblioteca Javascript: en lugar de escribir todo el cdigo del lado cliente, es posible apoyarse en alguna biblioteca Javascript como jQuery, Prototype o Yahoo! User Interface Library (YUI), que permiten liberar al desarrollador de las tareas de bajo nivel, como la gestin del objeto XMLHttpRequest y su compatibilidad con el navegador, o el procesamiento de la respuesta recibida, reduciendo as el cdigo necesario para implementar una funcionalidad Ajax en la aplicacin. Uso de un framework de componentes preparados para Ajax: en particular, en la plataforma Java EE se dispone de la tecnologa de componentes JavaServer Faces, que puede ser extendida de manera que se creen componentes que incluyan funcionalidades Ajax, como los que proporciona el framework ICEfaces o el RichFaces. Estos componentes Ajaxenabled incluyen todo el cdigo necesario para implementar la funcionalidad Ajax, presentando una interfaz limpia y reutilizable al desarrollador final que puede usarlos sin necesidad de conocer los detalles.
Ver ejemplo: strutsAjax
67
4. Capa de negocio
4.1. Introduccin
En la capa de negocio o modelo se encuentran los componentes que proporcionan la lgica de negocio de la aplicacin. Esta lgica de negocio es la que representa la funcionalidad especfica de un dominio particular, como un sistema bancario, un sitio de comercio electrnico, un gestor de inventario y fabricacin, etc. Por tanto, supone la capa ms especfica del sistema a desarrollar. La lgica de negocio debe permitir representar tanto el estado del sistema como su comportamiento. As, en las metodologas de anlisis y diseo orientado a objetos el sistema se modela a travs de un conjunto de objetos que interaccionan entre s y que se caracterizan por su clase, su estado (elementos de datos) y su comportamiento. Aunque el paradigma de orientacin a objetos aboga por encapsular en la misma entidad o clase tanto el estado como el comportamiento, es habitual que al modelar un sistema existan unos objetos ms enfocados a representar el estado de la aplicacin y otros que se encarguen de la lgica o comportamiento del mismo. Estado del sistema: normalmente se utilizan un conjunto de clases y sus propiedades, de manera que los valores de las propiedades son los que representan el estado del sistema en un momento dado. Por ejemplo, en un sistema de compra por internet, el estado se podra representar por un carro de la compra con unos artculos, unas cantidades y unos precios en un determinado momento. Mientras que puede existir informacin de estado que no es necesario que se mantenga por un periodo de tiempo largo, es habitual encontrar sistemas que necesitan hacer persistente esta informacin; en este ltimo caso, ser necesario comunicar los objetos de estado con el sistema de almacenamiento a travs de la capa de persistencia. Comportamiento del sistema: la lgica funcional y las reglas de negocio del sistema se representan a travs de invocaciones a mtodos, que pueden ubicarse en las mismas clases utilizadas para representar el estado del sistema, o como se indic anteriormente, en un 68
conjunto de clases dedicadas a realizar esta lgica. En este ltimo caso, suele ser necesario pasar los objetos de estado del sistema, que van a manipularse en los mtodos de la lgica de negocio, como argumentos de dichos mtodos. Los objetos de estado contendrn una mayor o menor cantidad de lgica dependiendo del dominio y alcance del sistema especfico.
La misma lgica de negocio debe poder ser utilizada con independencia de que la capa de presentacin se base en un cliente ligero (navegador) o pesado (aplicacin de escritorio), o del sistema o tecnologa que proporcione la persistencia. Por tanto, debe ser diseada siguiendo criterios de alta cohesin y bajo acoplamiento respecto del resto de capas de la aplicacin. Adems, suele ser habitual encontrar sistemas cuya lgica de negocio puede requerir de cierta flexibilidad en su configuracin o la capacidad de ser ampliados sin perder sus calidades de servicio (escalabilidad). Para cumplir estas posibles expectativas, se suele hacer uso de los patrones de diseo, tanto en la capa de modelo como en el resto de capas de la aplicacin. Uno de los patrones utilizados ms habitualmente en la implementacin de la lgica de negocio es el Service Layer o capa de servicio. Este patrn implica el establecimiento de una capa de negocio que presenta el conjunto de operaciones disponibles en la aplicacin, coordinando su respuesta y comportamiento transaccional; actuando as como una interfaz de acceso a las funcionalidades de la aplicacin con independencia del cliente. La capa de servicio suele estar compuesta por Application Services o servicios de aplicacin, que son componentes que encapsulan en sus operaciones la lgica de negocio de la aplicacin. Estos componentes interaccionarn con el resto de componentes de la capa de negocio para implementar la funcionalidad requerida.
4.2. Tecnologas y estrategias
4.2.1.
Aproximacin POJO JavaBeans
69
POJO es el acrnimo de Plain Old Java Object. Este nombre se utiliza para enfatizar que se trata de un objeto Java ordinario, es decir, no est ligado a dependencias de ningn framework o componente determinado, especialmente, no es un Enterprise JavaBean.
Por tanto, en su cdigo no nos encontraremos:
public class ClasePOJO extends javax.servlet.http.HttpServlet { public class ClasePOJO implements javax.ejb.EntityBean {
Un JavaBean es un POJO que sigue una serie de convenciones de codificacin, ya explicadas al exponer la arquitectura de componentes JavaBeans, y que son: Disponer de un constructor pblico por defecto, que facilita la instanciacin del objeto. Contener propiedades que deben ser accesibles a travs de mtodos de lectura y escritura, y que siguen una estndar de nombrado. Deben ser serializables.
Estas convenciones hacen que los JavaBeans tengan una serie de caractersticas esperables, pero no los hacen dependientes de ningn framework o tecnologa especfica.
En consecuencia, se trata de clases que presentan una codificacin sencilla y un alto grado de reutilizacin, ya que no dependen de frameworks especficos. Adems, permiten acceder a la lgica de negocio de la aplicacin en un entorno local y con un alto rendimiento de ejecucin, ya que se consideran objetos ligeros, por no implicar su procesamiento la necesidad de ejecutar servicios adicionales.
Una vez expuestos ambos conceptos, es el momento de definir cmo se puede implementar la capa de modelo de un sistema siguiendo la aproximacin de POJO JavaBeans.
70
A partir de la definicin de estado del sistema, expuesta en la introduccin, es fcil inferir que la arquitectura de componentes JavaBeans es una clara candidata a representarlo, pues se basa en objetos con un conjunto de propiedades y sus mtodos de acceso (lectura y modificacin). Por su parte, la lgica de negocio podr alojarse bien junto con la informacin del estado en los JavaBeans, o tambin en clases POJO adicionales. Estar en uno u otro lado dependiendo en gran medida del dominio especfico del problema. Por ejemplo, si es una lgica que tiene que ver directamente con la naturaleza de una entidad o bean, estar en el propio JavaBean que lo implemente, mientras que si afecta a ms de un objeto de estado o no es intrnseca a la naturaleza de un bean sino ms bien a la aplicacin o funcionalidad general, se encontrar en una clase POJO normal. Si la aplicacin utiliza el patrn Service Layer los componentes de la capa de servicio sern normalmente clases POJO, cuyos mtodos representarn las operaciones del sistema.
Ver ejemplo: strutsService
4.2.2.
Aproximacin EJB
Un Enterprise bean o bean empresarial es un componente Java EE que implementa la tecnologa Enterprise JavaBeans (EJB). Estos beans se despliegan en el contenedor de EJB, dentro del servidor empresarial, que proporciona servicios a nivel de sistema, como seguridad y transacciones a estos beans, facilitando su rpida construccin y despliegue.
Estos beans son componentes de la capa de negocio, por tanto en su codificacin, hecha en lenguaje Java, encapsulan la lgica de negocio de la aplicacin.
Lo que diferencia a esta aproximacin de la POJO-JavaBeans, es el conjunto de servicios que aporta el contenedor EJB, que facilitan que el desarrollador se centre en la implementacin de 71
la lgica de negocio dejando otras cuestiones horizontales al contenedor, y sobre todo, proporcionan un mecanismo de acceso remoto a la lgica de negocio.
A pesar de estas ventajas a la hora de desarrollar la lgica de negocio con esta aproximacin, el uso de la tecnologa EJB puede tener efectos negativos en el rendimiento respecto a la basada en POJO-JavaBeans, ya que estos ltimos se consideran componentes ms ligeros en su ejecucin. Por tanto, es necesario especificar una serie de necesidades o motivos que pueden llevar al desarrollador a optar por esta aproximacin: La aplicacin debe ser escalable. La tecnologa EJB permite la distribucin de sus componentes en mltiples mquinas de forma transparente al usuario, por lo que si se incrementa el nmero de componentes o de usuarios es factible incrementar el nmero de servidores utilizados. La lgica de negocio debe poder ser accesible desde mltiples ubicaciones remotas y garantizando la seguridad y transaccionalidad de las operaciones.
Por tanto, la tecnologa EJB permite compartir la lgica de negocio de forma remota, segura y con independencia del nmero y tipo de usuarios o clientes.
(i)
Tipos de Enterprise Beans (EJB 3.1)
1)
Session Bean
Un Session Bean o bean de sesin encapsula lgica de negocio que puede ser utilizada por un cliente a travs de la invocacin de los mtodos del bean, a los que tendr acceso a travs de una referencia local o remota, o por medio de un servicio web.
Existen tres tipos de beans de sesin: 72
Stateful Session Beans: son beans de sesin con estado, siendo este estado el conjunto de valores de las variables de la instancia utilizada. El estado est asociado a un nico cliente, es decir, por cada cliente que acceda a un bean de sesin con estado se tendr una instancia dedicada, por lo que a veces se le denomina estado conversacional. Cuando el cliente termina su sesin, el bean termina su asociacin y se libera la informacin de sesin. Mantener el estado conversacional permite que un bean de sesin se pueda utilizar para realizar un flujo de trabajo o escenario. Stateless Session Beans: un bean de sesin sin estado no mantiene un estado conversacional con el cliente, por tanto, cuando se invoca un mtodo la informacin del cliente especfico slo se mantiene durante dicha invocacin. Las instancias de beans de sesin sin estado pueden ser utilizadas por mltiples clientes, por lo que presentan una mejor escalabilidad cuando se incrementa el nmero de usuarios. Adems, al ser sin estado pueden implementar un servicio web, lo cual no es posible en un bean con estado. Singleton Session Beans: este tipo de beans de sesin implementan el patrn Singleton, lo que significa que slo se instancian una vez por aplicacin. Es decir, es similar a un bean sin estado, pero en lugar de existir varias instancias, probablemente en un pool, que atienden a los clientes, en este caso existe una nica instancia para todos los clientes, cuyo estado es mantenido entre las invocaciones de sus mtodos, por lo que es compartido por todos. Se crear la instancia al iniciarse la aplicacin y se eliminar cuando sta termine, por lo que puede ser utilizado para realizar tareas de inicializacin y finalizacin de la aplicacin. Al igual que los bean sin estado, puede implementar un servicio web.
En cualquier caso, un bean de sesin no es persistente, es decir, sus datos no se almacenan en una base de datos.
2)
Message-Driven Bean
Un bean dirigido por mensajes permite a las aplicaciones Java EE procesar mensajes de forma asncrona. Para ello, acta como un 'listener' de mensajes tipo Java Message Service (JMS). 73
Estos mensajes pueden ser enviados desde cualquier componente Java EE: una aplicacin cliente, otro enterprise bean, un componente web, etc., o tambin desde un sistema que genere mensajes JMS u otro tipo de mensajes.
Un bean dirigido por mensajes es muy similar a un bean de sesin sin estado, aunque se diferencian en la forma en la que son accedidos, ya que un bean de sesin es accedido a travs de sus interfaces, mientras que a un bean dirigido por mensajes se le enva un mensaje a un cola mantenida en el servidor. Adems, los bean de sesin reparten la lgica de negocio en un conjunto de mtodos que se pueden invocar individualmente, mientras que los bean dirigidos por mensajes reciben los mensajes de la cola en un nico punto de entrada, que se encarga de procesarlos en base a la lgica implementada.
(ii)
Accediendo a los Enterprise Beans
En esta seccin nicamente se mostrar la forma de acceder a los beans de sesin, ya que los bean dirigidos por mensaje no definen interfaces ni vistas sin interfaz para el acceso de los clientes.
Como se mencion anteriormente, la lgica de negocio est disponible a travs de los mtodos del bean. Estos mtodos se publican al cliente a travs de una vista sin interfaz, que publica todos los mtodos pblicos de la clase que implementa el bean, o a travs de una interfaz de negocio, que publica un conjunto de mtodos determinados. En cualquier caso, ambos mecanismos permiten definir la visin que tiene el cliente de un bean.
Para hacer uso de los mtodos de negocio de un bean, el cliente debe previamente obtener una referencia al mismo, lo que puede conseguir haciendo uso de la inyeccin de dependencias (a travs de anotaciones) o de bsquedas JNDI.
A la hora de implementar un bean, es necesario indicar el tipo de acceso permitido, que 74
puede ser local, remoto o a travs de un servicio web.
1)
Acceso Local
Si el bean puede ser utilizado por otro bean o componente que se encuentra en la misma aplicacin que el accedido, ser necesario proveer de acceso local. Esto puede hacerse mediante la vista sin interfaz del bean, o proporcionando una interfaz de negocio que contenga los mtodos de negocio y del ciclo de vida del bean, y marcndola como local @Local, ya que una interfaz de negocio puede ser local o remota.
El cliente podr acceder a la vista sin interfaz o a la interfaz de negocio local por inyeccin de dependencias o por JNDI.
2)
Acceso Remoto
Si el cliente se ejecuta en otra mquina y con una mquina virtual diferente al bean accedido, es necesario disponer de un acceso remoto. En este caso no es posible hacer uso de una vista sin interfaz, sino que debe utilizarse una interfaz de negocio remota @Remote, en la que, de manera anloga al acceso local, puede obtenerse una referencia a travs de inyeccin de dependencias o JNDI.
3)
Acceso con Servicio Web
En ocasiones es necesario que la lgica de negocio est disponible remotamente, con independencia del tipo de cliente utilizado. En este caso, es necesario utilizar los Servicios web. Un bean de sesin sin estado puede ser utilizado como servicio web, de forma que sus mtodos de negocio sern utilizados como puntos de acceso o 'endpoints' del servicio. El cliente utilizar el 75
servicio web sin necesidad de conocer si est implementado a travs de un bean de sesin sin estado, o de otras opciones como servicios web con JAX-WS, con el framework Axis, etc.
(iii)
Empaquetado de un Enterprise Bean
Un bean empresarial estar formado por un clase que implementa los mtodos de negocio as como los del ciclo de vida del bean, unas posibles interfaces de negocio que definen los mtodos de negocio accesibles, y opcionalmente un conjunto de clases de apoyo.
El bean podr empaquetarse y distribuirse de dos formas: A travs de un fichero EJB JAR: presenta una unidad de encapsulamiento autocontenida, que permite utilizar el bean para componer diferentes aplicaciones, por ejemplo incluyndolo en un fichero EAR. El archivo incluir las clases del bean, y un posible ejbjar.xml en el directorio meta-inf. Incluido en un mdulo WAR: si la lgica de una aplicacin web se modela con beans empresariales, se pueden incluir sus clases en las ubicaciones habituales para las clases del mdulo (web-inf/classes o en web-inf/lib como un fichero JAR) y el fichero ejb-jar.xml en el mismo directorio que los descriptores de despliegue de la aplicacin web.
Ver ejemplo: codigoEJB
Ver ejemplo: strutsEJB
76
5. Capa de persistencia.
5.1. Introduccin
Una de las posibles necesidades de la lgica de negocio es que determinada informacin del estado del sistema sea persistente. Para ello, se utiliza la capa de persistencia o de datos, que gestiona la persistencia de los beans de estado de la capa de dominio. Las clases cuyas instancias se guardan en algn sistema de almacenamiento persistente se denominan clases persistentes. Por lo general, lo mnimo que se har con las clases persistentes de la capa de dominio ser: (Create) crear instancias nuevas y guardarlas en disco; (Read) leer instancias del disco; (Update) modificar el estado de las instancias y actualizarlo en disco; y (Delete) eliminar instancias del disco. Este conjunto mnimo de operaciones se conoce como operaciones CRUD, por las siglas de Create, Read, Update y Delete. En el contexto de un SGBD relacional, la operacin Create corresponder a una operacin Insert de SQL, la operacin Read a un Select de SQL, mientras que Update y Delete se correspondern con las operaciones del mismo nombre en SQL. Por tanto, la capa de persistencia tiene como principales responsabilidades y objetivos: Implementar las operaciones de persistencia (CRUD). Aislar a la lgica de negocio de la tecnologa de almacenamiento (normalmente un SGBD). Presentar una interfaz comn de acceso a datos.
5.2. Modelos clsicos de persistencia
Existen mltiples formas de gestionar la persistencia. A continuacin, se expondrn algunos patrones clsicos: 77
5.2.1.
Persistencia en las clases del modelo
Una posibilidad es que las propias clases del modelo, que sern beans de estado, sean las que gestionen su propia persistencia. Por tanto, debern implementar, adems de sus mtodos de negocio, los correspondientes a las operaciones CRUD. Esta solucin se considera problemtica, ya que hace a la capa de dominio demasiado dependiente del mecanismo de almacenamiento de las instancias.
5.2.2.
Persistencia en clases auxiliares
Otra posibilidad es dar la implementacin a las operaciones CRUD en clases asociadas que se encarguen nicamente de gestionar la persistencia de las instancias de las clases de dominio. De este modo, las clases de dominio se olvidan de las responsabilidades de persistencia y se centran en implementar la resolucin del problema. Un cambio en el mecanismo o tecnologa de almacenamiento no afectara a las clases de dominio.
(i)
Patrn Fabricacin Pura
78
El patrn fabricacin pura implica la creacin de una clase auxiliar a la que la clase principal delega las operaciones que no son de negocio. En este caso, lo que se delega es la responsabilidad de implementar las operaciones de persistencia.
Bsicamente, se crear una clase totalmente dependiente de la clase del modelo que sabe como dar persistencia a dicha clase y que incluye el cdigo dependiente de la tecnologa de almacenamiento. Cuando la clase del modelo necesite una operacin de persistencia har uso de su correspondiente clase auxiliar.
Existen diferentes posibilidades a la hora de implementar el patrn fabricacin pura para la persistencia, variando en la forma en la que se relaciona la clase de dominio con la clase auxiliar, en todo caso, la clase de dominio tiene los mtodos CRUD, pero en su cuerpo lo que se hace es llamar directamente a la clase auxiliar que implementa dicho mtodo:
public void insert() throws Exception { PersistEmpleado.insert(this); }
En los mtodos de la clase auxiliar es en los que se encontrar el cdigo dependiente del sistema de almacenamiento, por ejemplo, si se trata de una base de datos relacional, se tendra la gestin de la conexin y las sentencias SQL.
79
(ii)
Patrn Data Access Object (DAO)
El patrn DAO proporciona una solucin muy similar a la anterior, ya que define una clase DAO encargada de abstraer y encapsular el acceso a la fuente de datos.
La principal diferencia es que la clase que necesita persistencia puede no tener ninguna relacin con la clase DAO, con lo que se incrementa el grado de independencia. De esta manera, ser una tercera clase la encargada de gestionar las operaciones de persistencia.
El cliente puede ser una clase de negocio, como un bean de sesin, o una clase 'Helper', que permitan implementar una funcionalidad que demanda el acceso a los datos.
El objeto de transferencia de datos <<TransferObject>> podra ser un bean de estado, aunque tambin podran definirse objetos especficos para la comunicacin de datos entre capas.
El objeto DAO implementa las operaciones de persistencia, utilizando un objeto de transferencia para devolver los datos al cliente en caso de lecturas y recibindolo para el caso de escrituras. Se comunica con una fuente de datos para realizar las operaciones. 80
5.3. Mecanismos y tecnologas de persistencia
5.3.1.
Java Database Connectivity (JDBC)
(i)
Introduccin
Java Database Connectiviy (JDBC) es la API que ofrece la plataforma Java en su edicin estndar, y por tanto tambin disponible desde las aplicaciones empresariales, para el acceso a datos desde aplicaciones Java. Est dirigida al acceso a bases de datos relacionales basadas en SQL, aunque tambin permite acceder a otras fuentes de datos. Desde el punto de vista del desarrollador de aplicaciones, el uso de JDBC implica tres operaciones bsicas: establecer una conexin con una fuente de datos, enviar sentencias SQL y procesar los resultados devueltos. Para dar soporte a estas operaciones es necesario disponer de un Driver JDBC, que es un componente software que permite interaccionar a la aplicacin Java con la base de datos, traduciendo las llamadas a la API JDBC a comandos entendibles por Sistema Gestor de Base de Datos, de manera que se haga posible el intercambio de informacin. El establecimiento de la conexin requiere que est disponible el Driver de la base de datos que se va a utilizar, de forma que el DriverManager pueda obtener una conexin indicando la URL asociada a dicha base de datos. Una vez establecida la conexin (Connection), se puede comenzar a crear y ejecutar sentencias que permitan implementar las operaciones de persistencia requeridas, para lo que puede hacerse uso de las interfaces Statement, PreparedStatement y CallableStatement, esta ltima permite la invocacin de procedimientos almacenados en la base de datos. La ejecucin de las sentencias provocar la devolucin de unos resultados a procesar, especficamente en el caso de las consultas se suele obtener un conjunto de registros con la informacin devuelta, encapsulados en un objeto ResultSet que permite recorrer los datos devueltos y acceder a los metadatos asociados, como por ejemplo el nmero de registros obtenidos y sus tipos de datos. Es importante gestionar el ciclo de vida tanto de las conexiones como de otros recursos utilizados en el acceso a datos, de forma que una vez que se hayan terminado las operaciones a realizar se liberen estos recursos. Adems, tambin es necesario realizar un tratamiento de las 81
posibles excepciones que se puedan producir, como la SQLException, de la que es complicado recuperarse, por lo que se recomienda traducirla a una excepcin de tipo unchecked que provoque deshacer las posibles operaciones realizadas (roolback) y la notificacin al usuario.
(ii)
Datasources
En el apartado anterior se expuso la manera convencional de establecer una conexin JDBC a travs del uso del DriverManager. Sin embargo, desde Java 1.4, el mecanismo recomendado para gestionar las conexiones en JDBC es el uso de la interfaz Datasource. La interfaz Datasource representa una factora de conexiones a una fuente de datos previamente configurada. Existe diferentes implementaciones de la interfaz: de proveedores de bases de datos, de servidores Java o de bibliotecas de terceros, como c3p0 o DBCP de Apache. En cualquier caso, el uso de Datasource permite aislar los aspectos de configuracin de la conexin del cdigo que la utiliza, por lo que se obtiene un cdigo ms portable y fcil de mantener. Adems, habilita la realizacin de transacciones distribuidas y el uso de un pool de conexiones, que permite la gestin de la conexiones activas haciendo posible su reutilizacin, mejorando as el rendimiento y la seguridad de la aplicacin.
(iii)
TheadLocal en JDBC
La clase ThreadLocal permite la definicin de variables locales a un hilo de ejecucin. En el mbito de las aplicaciones web Java EE toma especialmente relevancia su uso, ya que, al estar cada peticin asociada a un hilo de ejecucin, esta clase proporciona un mecanismo para compartir variables entre todos los componentes y clases que intervienen en el procesamiento de una peticin. En el caso de la persistencia con JDBC, se puede utilizar ThreadLocal para almacenar la instancia de la conexin asociada a la peticin, de manera que ya no ser necesario pasarla como argumento a cada uno de los mtodos utilizados. Hay que tener especial cuidado al utilizar la clase ThreadLocal ya que puede provocar un incremento del acoplamiento en el diseo de la aplicacin. 82
Ver ejemplo: strutsServiceTL
5.3.2.
Mapeo Objeto-Relacional. Java Persistence API
(i)
Introduccin
El mapeo objeto-relacional es una tcnica de programacin que se basa en convertir datos entre el sistema de tipos utilizado en un lenguaje de programacin orientado a objetos y el utilizado en una base de datos relacional. En la prctica, esto se traduce a definir un conjunto de relaciones o mapeos entre los objetos de negocio y las tablas de base de datos que permiten su persistencia.
Existen multitud de frameworks y herramientas que implementan el mapeo objetorelacional, que suelen variar en el lenguaje de orientacin a objetos al que estn dirigidas, en la forma en la que se definen las asociaciones o mapeos (con ficheros de configuracin, anotaciones, etc.), en el lenguaje de consultas definido, etc.
Dentro de los frameworks de mapeo, el ms extendido ha sido el de Hibernate, disponible tanto para la plataforma Java como para .Net. A partir de Hibernate, Java EE ha definido una especificacin, denominada JPA o Java Persistence API, que estandariza la API y los metadatos necesarios para implementar un mecanismo de persistencia objeto-relacional.
(ii)
Java Persistence API.
La Java Persistence API o JPA proporciona una utilidad de mapeo objeto-relacional para la gestin de datos relacionales en aplicaciones Java. La especificacin JPA puede dividirse en tres
83
reas principales: La API de persistencia. El lenguaje de consultas. La API Criteria. Los metadatos de mapeo objeto-relacional.
1)
Entidades
Una entidad es un objeto de dominio persistente, que tpicamente representa una tabla en una base de datos relacional. De esta forma, cada instancia de la entidad se corresponde con un registro de la tabla.
Una clase de entidad debe cumplir los siguientes requisitos: Debe estar anotada con @Entity. Debe tener un constructor sin argumentos pblico o protegido. No puede ser declarada como final, ni tampoco sus variables o mtodos marcados como persistentes. Si sus instancias van a ser pasadas como valor, por ejemplo a travs de la interfaz remota de un bean de sesin, debern implementar la interfaz Serializable. Las variables de instancia persistentes deben ser declaradas como protegidas o privadas y slo pueden ser accedidas por sus mtodos de la clase.
Para indicar los datos que deben ser persistentes se pueden utilizar los campos de la clase o los mtodos de acceso, si es que se han seguido las convenciones JavaBean para definicin de propiedades. En cualquier caso, sern persistentes salvo que se indique explcitamente que deben considerarse transitorios @Transient.
84
Cada entidad debe tener un identificador nico de objeto o clave principal, que permitir identificar el objeto, pudiendo ser simple o compuesta. Si es simple se utilizar la anotacin @Id, mientras que si es compuesta se deber definir en una clase de clave primaria.
Las entidades pueden estar relacionadas entre s a travs de cuatro tipos de relaciones: uno a uno, uno a muchos, muchos a uno y muchos a muchos, teniendo cada tipo de multiplicidad su anotacin correspondiente. Las relaciones pueden ser unidireccionales o bidireccionales. En este ltimo caso habr que indicar que parte de la relacin es la esclava en la anotacin (se correspondera semnticamente con la clave ajena), a lo que adems se puede aadir si la relacin implica dependencia en existencia, pudiendo provocar un borrado en cascada.
El lenguaje de consultas de JPA a menudo navega entre relaciones, por lo que si la relacin es bidireccional podr navegar en los dos sentidos, mientras que si es unidireccional lo har en uno slo.
Las entidades soportan herencia de clases, asociaciones polimrficas y consultas polimrficas. Pueden extender de clases que sean o no de entidad, y cada clase de entidad puede ser concreta o abstracta. Por tanto, es posible establecer mltiples tipos de jerarquas de herencia con entidades, que podrn ser implementadas a travs de tres estrategias bsicas: una nica tabla para toda la jerarqua de clases, una tabla para la raz y otra para cada subclase con una clave ajena a la raz, y por ltimo, una tabla para cada clase concreta.
2)
Gestionando Entidades
La especificacin JPA define la interfaz EntityManager para gestionar las entidades. Cada instancia del gestor de entidades est asociada a un contexto de persistencia, que define el conjunto particular de entidades gestionadas y el alcance bajo el que las instancias de una entidad particular son creadas, guardadas y eliminadas. 85
La interfaz EntityManager define los mtodos que interactan con el contexto de persistencia para llevar a cabo las operaciones de creacin y eliminacin de instancias de entidades, la bsquedas de entidades y otras posibles consultas personalizadas.
Por tanto, el gestor EntityManager tendr asociadas, a travs del contexto de persistencia, un conjunto de instancias de las entidades que representan los objetos de negocio del sistema, sobre los que ejecutar operaciones de persistencia.
Existen dos tipos de gestores de entidades: Gestionados por el contenedor: en este caso, es el contenedor el responsable de la gestin del ciclo de vida del EntityManager, ocupndose de abrir y cerrar el gestor. El contexto de persistencia se propaga automticamente a todos los componentes que utilizan la instancia del EntityManager dentro de una transaccin Java Transaction Architecture (JTA), con lo que no es necesario pasar una referencia de la instancia entre los componentes. Gestionados por la aplicacin: el ciclo de vida del gestor se debe manejar manualmente en el cdigo de la aplicacin. El contexto de persistencia no se propaga de forma automtica entre componentes, por lo que si se quiere utilizar en varios se deber pasar manualmente. Para obtener una instancia de EntityManager gestionado por la aplicacin es necesario hacer uso de EntityManagerFactory, que permitir obtener gestores asociados a una unidad de persistencia.
Otro de los componentes clave dentro de la arquitectura de persistencia de JPA son las unidades de persistencia (Persistence Unit), que definen un conjunto de tipos de entidades que pueden ser manejados por un EntityManager. La informacin de una unidad de persistencia se refleja en el archivo persistence.xml, en el que adems se incluye informacin sobre el tipo de transaccin a utilizar, la fuente de datos, el proveedor que implementa JPA, y otros parmetros especficos del proveedor.
86
Las transacciones definen cuando se sincronizan las entidades con la base de datos. JPA soporta dos tipos de gestin de las transacciones: JTA y Resource-Local. Los EntityManager gestionados por el contenedor utilizan siempre JTA, mientras que los gestionados por la aplicacin pueden utilizar ambas. El tipo de transaccin utilizada se define en el fichero persistence.xml para cada unidad de persistencia. JTA: el ciclo de vida de la transaccin est controlado por el contenedor que puede compartirla entre componentes. Resource-local: son las transacciones nativas de los drivers JDBC que se referencian en las unidades de persistencia. Por tanto, el control del ciclo de vida se har explcitamente en la aplicacin a travs de la API de EntityTransaction.
Como se indic inicialmente, JPA es una especificacin que proporciona una interfaz para la implementacin del mecanismo de persistencia objeto-relacional en Java EE. En tiempo de ejecucin, ser necesario un proveedor de persistencia que proporcione dicha implementacin.
La mayora de los frameworks de persistencia ya proporcionan una implementacin para JPA, algunos de ellos con una alta integracin con los servidores Java EE en los que se despliegan las aplicaciones que requieren de la persistencia. A continuacin, se muestra una tabla con informacin referente a productos de persistencia:
87
3)
Operaciones de persistencia
Las operaciones de persistencia se realizan a travs del EntityManager sobre las instancias del contexto de persistencia asociado.
Cada operacin CRUD se realiza a travs de un mtodo del EntityManager:
Create: Read: Update: Delete:
entityManager.persist (Object entity) entityManager.find (Entity.Class, Object primaryKey) entityManager.merge (Object entity) entityManager.remove (Object entity)
Adems de las operaciones bsicas, JPA proporciona dos mecanismos para la consulta de entidades: el lenguaje de consultas JPQL (Java Persistence query languaje) y ms recientemente la API Criteria. A continuacin se expondr brevemente JPQL.
El lenguaje de consultas JPQL es un lenguaje basado en cadenas de texto similar a SQL, pero orientado a la consulta de entidades y sus relaciones. Por tanto, permite la definicin de consultas personalizadas pero en lugar de utilizar tablas y sus columnas utiliza las entidades, sus propiedades y las relaciones entre entidades.
Estas consultas pueden ser dinmicas, si se definen directamente dentro de la lgica de negocio de la aplicacin, utilizando el mtodo createQuery:
public List findWithName(String name) { return em.createQuery( "SELECT c FROM Customer c WHERE c.name LIKE :custName") .setParameter("custName", name) .setMaxResults(10) .getResultList(); }
O estticas, para lo que se usa el mtodo createNamedQuery. En este caso, la consulta se 88
define a travs de metadatos.
@NamedQuery( name="findAllCustomersWithName", query="SELECT c FROM Customer c WHERE c.name LIKE :custName" ) ___________________________________________________________________ customers = em.createNamedQuery("findAllCustomersWithName") .setParameter("custName", "Smith") .getResultList();
Ambos tipos de consultas admiten incluir parmetros, tanto por nombre como por posicin:
em.createQuery( "SELECT c FROM Customer c WHERE c.name LIKE :custName") .setParameter("custName", name) .getResultList(); ___________________________________________________________________ em.createQuery( SELECT c FROM Customer c WHERE c.name LIKE ?1) .setParameter(1, name) .getResultList();
Ver ejemplo: strutsJPA
Ver ejemplo: strutsJPA2
89
6. Comunicacin entre capas y aplicaciones.
6.1. Introduccin
La arquitectura Java EE permite el desarrollo de aplicaciones multicapa distribuidas. Por tanto, sern necesarios mecanismos y tecnologas para realizar la comunicacin entre capas, y tambin con otras aplicaciones.
En realidad, de lo que se dispone es de un conjunto de tecnologas y especificaciones para proveer acceso remoto a los componentes u objetos de la arquitectura Java EE, principalmente de la capa de negocio, ya que para acceder a la capa web se suele utilizar el protocolo estndar HTTP.
6.2. RMI EJBs
La tecnologa Java Remote Method Invocation o Java RMI es una interfaz de programacin que permite la comunicacin entre aplicaciones Java SE de una forma similar a las llamadas a procedimientos remotos.
RMI se basa en que un objeto A, para comunicarse con otro B, necesita conocer nicamente un subconjunto del conjunto de operaciones pblicas de B. As, B recoge este subconjunto de operaciones en una interfaz, que ofrece de forma remota. De este modo, la interfaz remota ser una especializacin de la interfaz java.rmi.Remote, que no define ningn mtodo y que es, por tanto, una interfaz de nombrado; la clase que implementa la interfaz remota ser una especializacin de alguna de las clases diseadas especficamente para este tipo de comunicaciones, como java.rmi.server.UnicastRemoteObject.
90
La aplicacin cliente deber obtener una referencia a la interfaz remota. Para ello, previamente deber haberse publicado en algn puerto de la mquina de la aplicacin servidora, utilizando un servidor RMI.
Un objeto remoto se publica utilizando el mtodo bind(String, Remote) de la clase java.rmi.Naming: el primer parmetro es la URL en la que se publica el objeto, al que adems se asigna un nombre; el segundo representa la instancia del objeto remoto que se publica.
Naming.bind("rmi://127.0.0.1:2006/servidorejemplo", instanciaServidor);
Previamente, habr sido preciso lanzar el servidor RMI:
LocateRegistry.createRegistry(2006);
La clase que desee acceder de forma remota al objeto publicado debe localizarlo, lo que consigue utilizando el mtodo Naming.lookup(String), que devuelve una referencia a un objeto Remote y al que debe hacerse un cast para transformarlo al objeto deseado, que debe estar en la forma de una interfaz remota. Es decir:
91
IServidor servidor=(IServidor) Naming.lookup("rmi:// 127.0.0.1:2006/servidorejemplo");
Una vez obtenida la referencia, se pueden realizar las llamadas que se deseen a las operaciones ofrecidas en la interfaz remota, como si se tratara de un objeto local.
RMI es una interfaz para comunicaciones remotas, que requiere de un protocolo de transporte subyacente. Existen dos opciones principales: Java Remote Method Protocol (JRMP): es el protocolo especfico de Java para buscar y referenciar objetos remotos. Consigue una alta eficiencia ya que la comunicacin se hace a nivel de mquinas virtuales de Java (JVM), lo que implica que tanto el cliente como el servidor deben ser aplicaciones Java. RMI-IIOP: El protocolo RMI sobre IIOP surge con el objetivo de integrar la comunicacin RMI de Java con la arquitectura CORBA (Common Object Request Broker Architecture), permitiendo as la comunicacin con otras aplicaciones que no sean Java pero que admitan esta arquitectura.
La tecnologa EJB permite acceder a la lgica de negocio de forma remota, a partir de una arquitectura de componentes de servidor. El servidor dispone de un contenedor de EJB y utiliza RMI como base para proporcionar el acceso a los componentes desde las aplicaciones cliente, en particular a travs de RMI-IIOP. Por tanto, RMI permite la comunicacin con objetos remotos distribuidos que podran ser componentes EJB.
Ver ejemplo: rmiServer / rmiClient
6.3. Servicios Web
92
6.3.1.
Introduccin
Los servicios web proporcionan una manera estndar de interoperar entre diferentes aplicaciones software, ejecutndose en una variedad de plataformas y frameworks. Estn caracterizados por su gran interoperabilidad y extensibilidad, as como por su descripcin independiente de la mquina gracias al uso de XML. Los servicios web ofrecen un mecanismo de bajo acoplamiento que permite a las aplicaciones interaccionar entre s para ofrecer servicios sofisticados de valor aadido.
A nivel conceptual, un servicio es un componente software proporcionado a travs de un punto de acceso o 'endpoint' disponible a travs de red. El cliente del servicio y el proveedor utilizan mensajes para intercambiar peticiones y respuestas. Estos mensajes son autocontenidos y hacen pocas asunciones sobre las capacidades tecnolgicas de ambos extremos.
A nivel tcnico, los servicios web pueden implementarse de diferentes maneras. Los dos tipos principales son los Servicios Web XML y los Servicios Web RESTful. Se describir en detalle el primero por ser el ms extendido, para a continuacin mostrar dos alternativas de implementacin.
Los Servicios Web XML utilizan mensajes basados en este lenguaje de marcado que siguen el estndar Simple Object Access Protocol (SOAP), un lenguaje XML que define una arquitectura y formato de mensajes. Las operaciones ofrecidas por el servicio estn descritas en el lenguaje Web Services Description Languaje (WSDL), que tambin es un lenguaje XML, en este caso para la definicin de interfaces de servicios web. Adems de las operaciones, un documento WSDL suele incluir los tipos de datos intercambiados, los mensajes, los puntos de acceso y el protocolo de comunicacin utilizado. En principio, los mensajes SOAP pueden ser intercambiados a travs de cualquier protocolo estndar, pero lo ms habitual es el uso de HTTP.
La siguiente figura representa un posible esquema de funcionamiento de un Servicio Web 93
XML:
Una aplicacin Java puede actuar como cliente o como proveedora del servicio. A continuacin, se muestran los principales requisitos o tareas a implementar, segn el rol:
Como Proveedor: Es necesario habilitar un punto de acceso o 'endpoint' que sea capaz de aceptar peticiones HTTP. Dentro de la tecnologa Java, los Java Servlets permiten recibir y procesar peticiones de este tipo. Los mensajes SOAP incluyen la informacin de la operacin con los datos asociados, que suelen estar definidos con XML Schema. Las aplicaciones Java solo pueden trabajar con datos en forma de objetos Java, por lo que ser necesario un mecanismo de transformacin entre tipos Java y XML Schema. Las operaciones ofrecidas debern tener una implementacin. En principio, cualquier clase Java puede contener mtodos que implementen las operaciones de un Servicio Web. Particularmente, un EJB de sesin sin estado puede publicar sus mtodos de negocio a travs de un Servicio Web. Debe generar el documento WSDL que acta como interfaz y contrato del Servicio Web ofrecido. Por tanto, una aplicacin Java que acte como proveedora de un servicio web deber 94
aceptar peticiones HTTP, procesar su contenido siendo capaz de transformar los datos a objetos Java y generar la invocacin al mtodo que implementa la operacin. El mtodo devolver un valor de un tipo Java que deber transformarse en su correspondiente XML Schema y ser incluido en un mensaje SOAP que se devolver a travs de una respuesta HTTP.
Como Cliente: De forma anloga al servidor, necesitar una traduccin entre los tipos XML Schema, definidos en el documento WSDL generado por el servidor, y los tipos de Java que son los que manejar el cliente para hacer la invocacin. Deber generar un peticin HTTP con el mensaje SOAP que define la invocacin del servicio. Adems, recibir la correspondiente respuesta HTTP que puede contener un valor de retorno en un tipo XML Schema a transformar. Para llamar al servicio web, normalmente se invoca un mtodo definido en alguna clase de tipo 'Stub' que suelen generarse a partir del WSDL. Por tanto, la aplicacin cliente simplemente deber realizar la llamada al mtodo utilizando los tipos adecuados para los argumentos y recogiendo la respuesta si es necesario.
La plataforma Java dispone de frameworks y especificaciones que se ocupan de las tareas ms tediosas a la hora de crear servicios web, permitiendo que el desarrollador se centre en la implementacin de la lgica del servicio web o de la llamada al mismo. A continuacin se expondrn las ms relevantes.
6.3.2.
Axis
Apache Axis es un framework de tipo open source que constituye el estndar de facto para el uso de Servicios Web XML en Java. Axis implementa un servidor SOAP para el procesamiento de mensajes, as como un conjunto de utilidades y APIs para la generacin y despliegue de 95
aplicaciones con Servicios Web.
Axis permite la definicin de servicios a travs de un mtodo nativo que requiere el uso del contenedor Apache Tomcat o con un mtodo general independiente del contenedor. En cualquier caso, provoca la configuracin de un Servlet que captura la peticin y la procesa, generando la invocacin a la clase Java que mantiene el mtodo que implementa la operacin del servicio. Adems, permite generar el documento WSDL asociado al servicio web.
Desde el punto de vista del cliente, Axis permite, a partir de un documento WSDL, generar las clases 'Stub' para la invocacin del servicio web.
Est disponible la versin Axis2 que supone un rediseo completo del framework, y que adems proporciona la capacidad de actuar como una aplicacin servidora de sus propios servicios web.
Axis dispone de una arquitectura modular que le permite aadir funcionalidades y capas a los servicios web desplegados. Destaca especialmente el mdulo Apache Rampart que aade caractersticas de seguridad conformes a la especificacin WS-Security.
Ver ejemplo: webServiceAxis2 / strutsAxis2
6.3.3.
JAX-WS
JAX-WS o Java API for XML Web Services es la especificacin de la plataforma Java EE para la construccin de servicios web y clientes que se comunican utilizando XML. JAX-WS utiliza anotaciones para establecer las clases que implementan el servicio web 96
@WebService, as como los mtodos que representan las operaciones @WebMethod. Adems, se define la especificacin de un entorno de ejecucin que pueden implementar los servidores Java EE, ocupndose de la generacin y tratamiento de los mensajes SOAP a partir de la informacin expresada con las anotaciones. El servidor JBoss AS implementa la especificacin JAX-WS ofreciendo utilidades para la generacin de servicios web a partir de unas clases con las anotaciones correspondientes, y tambin la generacin de las clases 'Stub' del cliente a partir de un documento WSDL.
Ver ejemplo: webServiceJAXWS / strutsJAXWS
7. Bibliografa y referencias
Apache Software Foundation (2008). Struts User Guide. Accesible en http://struts.apache.org/1.x/userGuide/index.html
Apache Software Foundation (2012). Apache Axis2 User's Guide. Accesible en http://axis.apache.org/axis2/java/core/docs/userguide.html
JBoss Community (2012). JBossAS 7. Getting Started Guide. Accesible en https://docs.jboss.org/author/display/AS7/Getting+Started+Guide
Oracle Corporation (2006). Ajax Design Strategies. Accesible en http://java.sun.com/developer/technicalArticles/J2EE/AJAX/DesignStrategies/index.html
Oracle Corporation (2010). Core J2EE Patterns - Front Controller. Accesible en
97
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html.
Oracle Corporation (2010). Core J2EE Patterns - Data Access Object. Accesible en http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.
Oracle Corporation (2010). The Java EE 5 Tutorial. Accesible en http://docs.oracle.com/javaee/5/tutorial/doc/
Oracle Corporation (2012). The Java EE 6 Tutorial. Accesible en http://docs.oracle.com/javaee/6/tutorial/doc/
Oracle Corporation (2012). Java EE Compatibility. Accesible en http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html
Prez, J.M. (2008). Curso de herramientas de desarrollo web actualizado.
Prez, J.M. (2009). Desarrollo de aplicaciones con tecnologa Java.
Polo, M. (2007). Apuntes de Ingeniera de Software II. Accesible en http://www.infcr.uclm.es/www/mpolo/asig/0708/iso5.html.
Red Hat Inc. (2005). Introducing JPA Persistence. Accesible en http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html/pr01.html.
Wikibooks (2010). Java Persistence/Persistence Products. Accesible en http://en.wikibooks.org/wiki/Java_Persistence/Persistence_Products.
98

App Web Java EE

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

App Web Java EE

Uploaded by

Copyright:

Available Formats

DESARROLLO DE APLICACIONES WEB CON JAVA ENTERPRISE EDITION

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Objetivo del curso

1.1. La plataforma Java

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Herramientas de desarrollo y ejecucin

Desarrollo de aplicaciones web con Java Enterprise Edition

A continuacin, se muestra un diagrama de la plataforma Java:

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

1.3. Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Capas en la arquitectura Java EE

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Capa de sistemas de informacin empresarial.

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Estos servidores de aplicaciones Java EE disponen de contenedores de EJBs y web, pero

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Formateador de cdigo fuente.

Desarrollo de aplicaciones web con Java Enterprise Edition

3.1. Aplicaciones web en Java EE

Desarrollo de aplicaciones web con Java Enterprise Edition

web en la respuesta HTTP que se devuelve al cliente.

Desarrollo de aplicaciones web con Java Enterprise Edition

Ciclo de vida de una aplicacin web

Desarrollo de aplicaciones web con Java Enterprise Edition

A continuacin se muestra una ilustracin con la estructura de un mdulo web:

Desarrollo de aplicaciones web con Java Enterprise Edition

Configurando aplicaciones web

Desarrollo de aplicaciones web con Java Enterprise Edition

Ver ejemplo: hola

3.2. Tecnologa Java Servlets

Desarrollo de aplicaciones web con Java Enterprise Edition

Ciclo de vida de un Servlet

Si el contenedor necesita eliminar el servlet lo finalizar invocando al mtodo destroy.

Desarrollo de aplicaciones web con Java Enterprise Edition

Escribiendo mtodos de servicio

Obteniendo informacin de las peticiones

Desarrollo de aplicaciones web con Java Enterprise Edition

Ver ejemplo: hola

Alcance Contexto Web

Accesible desde Componentes web dentro del contexto web

Filtrando peticiones y respuestas

Desarrollo de aplicaciones web con Java Enterprise Edition

versin personalizada de la peticin o la respuesta. Interactuar con recursos externos.

Ver ejemplo: holaFiltros

Desarrollo de aplicaciones web con Java Enterprise Edition

Invocando otros recursos web

Incluyendo otros recursos en la respuesta