appwebjavaee

7/31/2019 AppWebJavaEE

1/98

DESARROLLO DE APLICACIONES WEBCON JAVA ENTERPRISE EDITION

Junta de Comunidades de Castilla-La Mancha

Consejera de Educacin, Cultura y Deportes

Sergio Tendero Zapero


2/98

Desarrollo de aplicaciones web con Java Enterprise Edition

ndice de contenido1. 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.....................................................................................................363.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

2


3/98


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

3


4/98


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


5/98


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


6/98


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.

6


7/98


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


8/98


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


9/98


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.

9


10/98


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 laedicin 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


11/98


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


12/98


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


13/98


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


14/98


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 laspginas 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


15/98


16/98


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


17/98


(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


18/98


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 sinnecesidad 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


19/98


20/98


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 deempaquetamiento 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


21/98


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


22/98


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


23/98


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 desdehttp://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 afectaa 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
http://www.eclipse.org/downloads/http://www.eclipse.org/downloads/http://www.eclipse.org/downloads/


24/98


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


25/98


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


26/98


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 comoServlets 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


27/98


28/98


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


29/98


30/98


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


31/98


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

HttpServletque proporciona mtodos como doGeto doPostpara 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 mtodoservice 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 initde la interfaz Servlet, sabiendo que este mtodo ser invocado

en la inicializacin.

31


32/98


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

HTTPServletRequestque 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


33/98


34/98


Sesin javax.servlet.http.HttpSession Componentes web manejando una peticin que pertenece a la

sesin

Peticin Subtipo de

javax.servlet.ServletRequest

Componentes web manejando la peticin

Pgina javax.servlet.jsp.JspContext Pgina JSP que crea el objeto

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 unarespuesta, 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


35/98


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 doFilteren 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 enla 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


36/98


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 objetoRequestDispatcher.

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


37/98


38/98


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


39/98


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 mtodoservice 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


40/98


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 realizaautomticamente.

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


41/98


Los elementos jsp:[include|forward] se convierten en invocaciones a la API de Java

Servlet.

El elementojsp:plugin se convierte en lenguaje de marcado especfico del navegador para laactivacin 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: . 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


42/98


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:

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 formaanloga 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


43/98


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 elementoscripting-invaliden 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


44/98


45/98


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:

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.

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

body


46/98


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.

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

${!empty param.username}

${pageContext.request.contextPath}

${sessionScope.cart.numberOfItems}


47/98


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:

Se debe definir un constructor sin parmetros.

Para indicar que la pgina va a utilizar un componente JavaBean se debe utilizar un

elementojsp:useBean como sigue:

Se debe indicar el alcance del objeto que puede ser: application,session, requestopage, 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:

47

PropertyClass getProperty() { ... }

setProperty(PropertyClass pc) { ... }


48/98


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:

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


49/98


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:

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 elementojsp: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.

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


50/98


51/98


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 unproblema 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


52/98


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-Vista-

Controlador, en realidad se aproxima mucho a esta arquitectura. De hecho, en muchos mbitos, se

52


53/98


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


54/98


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.

Ver ejemplo: modelo2

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


55/98


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-Vista-

Controlador 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-Vista-

55


56/98


57/98


(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:

: contiene la definicin de los beans de formulario (ActionForm) que podrn

ser instanciados en la aplicacin.

: 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.

: 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


58/98


(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 deActionForm 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 delActionMappingde la accin. Cuando el flujo de control pase

a la accin, sta tendr disponible una instancia delActionForm 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 claseActionForm 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 deActionErrors en caso de que se encuentren problemas.

58


59/98


Una aproximacin comn es realizar validaciones iniciales usando el mtodo validate, y

luego manejar la validacin de la lgica de negocio desde el objetoAction.

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 claseAction 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 objetoActionForm con la informacin de los parmetros pasados por el

usuario y el objetoActionMappingque 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


60/98


61/98


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-Contr

appwebjavaee

Documents