1. II Curso Online JAVA-J2EE
TEMA 7
J2EE avanzado
Autor: PCYTA / Centro de Excelencia de Software Libre de Castilla-La Mancha
Versión: 1.0
Fecha: Revisado 07-02-2008 11:46
Licencia: CC-by-sa 2.5

2. 0 Licencia
Usted es libre de:
Copiar, distribuir y comunicar públicamente la obra
Hacer obras derivadas
Bajo las condiciones siguientes:
Reconocimiento. Debe reconocer los créditos de la obra de la manera especificada por el
autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el
uso que hace de su obra).
Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra
derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.
• Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia
de esta obra.
• Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de
los derechos de autor
• Nada en esta licencia menoscaba o restringe los derechos morales del autor.
Para ver la licencia visite:
http://creativecommons.org/licenses/by-sa/2.5/es/legalcode.es
6 de febrero de 2008 Tema 7 2

3. UNIDAD VII. J2EE AVANZADO
0 Licencia...........................................................................................................................................2
1 Seguridad en las aplicaciones Web...............................................................................................4
1.1 Introducción a la seguridad en las aplicaciones Web...............................................................4
1.2 Métodos de autenticación web.................................................................................................4
2 Patrones de diseño J2EE...............................................................................................................7
2.1 Introducción a los patrones J2EE.............................................................................................7
2.2 Resumen patrones J2EE...........................................................................................................9
3 Otros Web Frameworks..............................................................................................................11
3.1 JSF, Spring MVC, Stripes, Structs 2, Tapestry, Ticket...........................................................12
6 de febrero de 2008 Tema 7 3

4. 1 Seguridad en las aplicaciones Web
1.1 Introducción a la seguridad en las aplicaciones Web
Cuando desarrollamos o desplegamos una aplicación en un entorno de producción es probable que
tengamos que tener en cuenta ciertas cuestiones relativas a la seguridad.
Primero, es posible que nuestra aplicación solicite al usuario que pruebe su identidad, esto se
denomina autenticación. Normalmente, se suele realizar mediante la introducción por parte del
usuario de su identificador (usuario) y una clave asociada (contraseña). Mediante la autenticación
nos aseguramos de que el usuario es quien dice ser.
Una vez autenticado un usuario, el siguiente paso es la autorización. Mediante la autorización
nos vamos a asegurar de que un usuario determinado sólo tiene acceso a los recursos a los que
se le quiera dar acceso. Normalmente, esto se consigue manteniendo unas tablas que nos indican
que acciones puede realizar un usuario determinado.
Por último, tenemos que tener en cuenta la confidencialidad de los datos, es decir, que los datos
únicamente tendrían que ser accesibles por la persona/s adecuadas.
Una vez definidos los conceptos de autenticación, autorización y confidencialidad de los datos,
vamos a ver como podemos conseguir estos requisitos de seguridad en la capa web.
En primer lugar necesitamos proporcionar un método para recoger la identidad de los usuarios o lo
que es lo mismo un mecanismo de login. La forma más famosa de login en las aplicaciones web es
la utilización de la pareja usuario/contraseña, pero podrían utilizarse también certificados para
realizar la autenticación.
Una vez que la información para autenticarse es aportada por el usuario necesitamos enviarla desde
el navegador al servidor. En este paso estamos hablando de confidencialidad, y la forma de realizar
el transporte de forma segura es mediante SSL.
Cuando el servidor reciba esta información (usuario/contraseña) necesita verificarla contra un
repositorio (base de datos, fichero plano, servidor LDAP, etc.). Este repositorio se denomina realm.
Un realm se encarga de mantener la información relacionada con los usuarios, contraseñas y
roles.
Además, es recomendable que los servidores también mantengan la información relacionada con el
control de acceso a los recursos (autorización), deben permitir la definición de que tipo de usuarios
(roles) pueden acceder a que recursos.
1.2 Métodos de autenticación web
En este apartado vamos a resumir los dos esquemas de seguridad web más importantes:
Autenticación Básica (BASIC) y Autenticación basado en Formulario (FORM).La diferencia
entre estos dos métodos básicamente está en la forma en que el navegador recoge la identificación
del usuario. En el método Basic el navegador utiliza una ventana de diálogo propia y en el método
Form la pantalla de autenticación es un fichero (HTML o JSP) que tiene un formulario con unos
campos predefinidos.
Autenticación Básica (BASIC).
Los pasos para securizar una aplicación web con este método son los siguientes:
6 de febrero de 2008 Tema 7 4

5. 1. Definir los usuarios, contraseñas y roles (realms).
La definición de los realms son específicos de cada servidor (Tomcat, Weblogic, etc) y
pueden definirse realms en ficheros planos, bases de datos o servidores LDAP.
Para Tomcat, el realm por defecto es un fichero que se denomina tomcat-users.xml y que se
encuentra en el directorio conf. A continuación hay un ejemplo del contenido de este fichero:
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users>
<role rolename="Administrador"/>
<role rolename="Usuario"/>
<user username="admin" password="admin" roles="Administrador,Usuario"/>
<user username="juan" password="juan" roles="Usuario"/>
</tomcat-users>
2. Especificar los recursos (URLs) que tienen restricciones de acceso.
Los parámetros de securización en la aplicación web se definen dentro del fichero web.xml.
Para establecer la autenticación Básica se utilizan las siguientes etiquetas:
<security-constraint>
<web-resource-collection>
<web-resource-name>Admin</web-resource-name>
<url-pattern>/HolaAdministrador</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Administrador</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
La etiqueta <transport-guarantee> cuando tiene el valor CONFIDENTIAL sirve para
definir que las URLs protegidas serán accesibles a través de SSL, con NONE se hace todo
sin SSL.
3. Parametrizar la aplicación web para que utilice la autenticación Basica.
Al igual que antes, esta definición se realiza también en el fichero web.xml:
<web-app>
...
<security-constraint>...</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
...
</web-app>
6 de febrero de 2008 Tema 7 5

6. Autenticación basada en Formulario (FORM).
Los pasos 1 y 2 anteriores también se tienen que realizar para éste método, además tenemos que
realizar:
1. Parametrizar la aplicación web para que utilice la autenticación basada en FORM.
Los parámetros de securización en la aplicación web se definen dentro del fichero web.xml.
Para establecer este método se utilizan las siguientes etiquetas:
<web-app>
...
<security-constraint>...</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>default</realm-name>
</login-config>
...
</web-app>
2. Crear los ficheros necesarios para la página de login y la página de error.
La página de login puede ser un fichero HTML o JSP que contiene el siguiente formulario:
<FORM ACTION="j_security_check" METHOD="POST">
<INPUT TYPE="TEXT" NAME="j_username">
<INPUT TYPE="PASSWORD" NAME="j_password">
</FORM>
La página de error también es un fichero HTML o JSP cuyo contenido no está prefijado.
6 de febrero de 2008 Tema 7 6

7. 2 Patrones de diseño J2EE
2.1 Introducción a los patrones J2EE
Tal y como vimos en el Tema 1 un patrón de diseño define una forma de resolver un problema
que se presenta en un contexto determinado.
En esta lección vamos a ver algunos de los patrones J2EE que se definen en el libro 'Core J2EE
Patterns: Best Practices and Design Strategies' escrito por arquitectos del Sun Java Center
(http://java.sun.com/blueprints/corej2eepatterns/index.html).
En este libro se realiza una clasificación de patrones atendiendo al modelo de arquitectura en capas,
distinguiendo entre capa de presentación, capa de negocio y capa de integración. Se incluyen 15
patrones en el catálogo que se agrupan de la siguiente forma:
Capa de Presentación Intercepting Filter; Front Controller; View Helper; Composite
View; Service to Worker; Dispatcher View.
Capa de Negocio Business Delegate; Value Object; Session Facade; Composite
Entity; Value Object Assembler, Value List Handler; Service
Locator.
Capa de Integración Data Access Object; Service Activator
En la capa de presentación se encuentran los patrones relacionados con la tecnología JSP/Servlets,
la capa de negocio contiene los patrones relacionados con la tecnología EJB y en la capa de
integración contiene la tecnología relacionada con JDBC y JMS.
En la siguiente imagen podemos ver como se interrelacionan los patrones J2EE:
6 de febrero de 2008 Tema 7 7

8. 6 de febrero de 2008 Tema 7 8

9. 2.2 Resumen patrones J2EE
En este apartado simplemente os voy a hacer un pequeño resumen de los patrones J2EE que
considero más importantes.
Intercepting Filter
Se utiliza para ‘interceptar’ peticiones (request) y respuestas (response) y aplicarles un filtro
determinado, por ejemplo, añadir logging, trazas de depuración, etc. Estos filtros pueden ser
añadidos o eliminados de forma declarativa, pudiendo aplicarse más de un filtro de forma
correlativa a la declaración realizada.
Front Controller
Proporciona un control centralizado para gestionar las peticiones que se realizan en la capa de
presentación. El controlador se encarga de recibir y gestionar las peticiones, centralizando la
invocación de los servicios de seguridad, delegando el procesamiento de la lógica de negocio,
controlando la elección de una vista apropiada, el manejo de errores y el control de la selección de
estrategias de creación del contenido de respuesta.
View Helper
Éste patrón enfatiza en la separación entre el código para la vista y el código de la lógica de
negocio. Se sugiere utilizar Helper para encapsular la lógica relacionada con la recogida de
parámetros, validaciones y adaptación de los datos enviados al modelo. Este componente
normalmente delega la lógica de negocio utilizando un patrón Business Delegate mientras que la
vista puede encontrarse compuesta de múltiples subcomponentes.
Composite View
Propone utilizar vistas compuestas que se componen de varias subvistas atómicas. Cada
componente de la plantilla se podría incluir dinámicamente dentro del total y la distribución de la
página se maneja independientemente del contenido.
Business Delegate
Reduce el acoplamiento entre capas y proporciona un punto de entrada único para acceder a los
servicios que ofrece la capa de negocio. Este patrón podría también implementar el cacheo de
consultas comunes para mejorar el rendimiento. Un Business Delegate normalmente utiliza un
patrón Service Locator que se va a encargar de los objetos del servicio, como EJBS y JMS.
Session Façade
Este patrón recomienda usar un bean de sesión como una fachada (facade) para encapsular la
complejidad de las interacciones entre los objetos de negocio participantes en un flujo de trabajo. El
Session Facade maneja los objetos de negocio y proporciona un servicio de acceso uniforme a los
clientes.
Value Object
El patrón Value Object proporciona las mejores técnicas y estrategias para intercambiar datos entre
las diferentes capas. Este patrón intenta reducir el número de llamadas remotas y evitar la
sobrecarga asociada que produce obtener datos de la capa de negocio.
Value List Handler
Se puede utilizar un Value List Handler para controlar las búsquedas, hacer un caché con los
6 de febrero de 2008 Tema 7 9

10. resultados, y proporcionar los resultados al cliente en una hoja de resultados cuyo tamaño y
desplazamiento cumpla los requerimientos del cliente.
DAO (Data Access Object)
Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de
datos. El DAO maneja la conexión con la fuente de datos para obtener y almacenar datos.
Para estudiar en detalle cada uno de ellos (contexto, problema, estrategias de solución y las
consecuencias) podéis ir pinchando sobre el nombre de cada patrón en la siguiente imagen
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html.
La versión en castellano de dicha documentación la podéis encontrar en la página de Java en
castellano(http://www.programacion.com/java/tutorial/patrones/ y
http://www.programacion.com/java/tutorial/patrones2/).
6 de febrero de 2008 Tema 7 10

11. 3 Otros Web Frameworks
La cantidad de web frameworks para J2EE que nos podemos encontrar actualmente en el mercado
empieza a ser tan numerosa que podemos llegar a perdernos en el momento de tener que elegir cual
debemos utilizar.
Como ejemplo, os envío el link de un post donde Matt Raible intenta dar su opinión sobre que web
framework se debe utilizar a lo que recibe una serie de respuestas donde cada uno de los
programadores expone que es mejor la que él utiliza
(http://raibledesigns.com/rd/entry/re_what_web_application_framework).
En este foro os puedo enumerar que se comentan los siguiente frameworks:
1. Struts, http://struts.apache.org/.
2. JSF, http://java.sun.com/javaee/javaserverfaces/.
3. Spring – Spring MVC, http://www.springframework.org/.
4. Shale, http://shale.apache.org/.
5. WebWork, http://sf.net/projects/opensymphony/.
6. Struts 2 (Struts/WebWork), http://struts.apache.org/2.0.9/index.html.
7. Tapestry, http://tapestry.apache.org/.
8. Click. http://click.sourceforge.net/.
9. Stripes, http://mc4j.org/confluence/display/stripes/Home.
10.Wicket, http://wicket.apache.org/.
11.Echo2, http://www.nextapp.com/platform/echo2/echo/.
12.Thinwire, http://www.thinwire.com/.
Como podéis ver, son bastante como para dejarte en la duda de cual utilizar e, incluso, llegar a
decidir continuar con el que ya tienes que al menos lo controlas.
En el siguiente apartado, os voy a presentar las ventajas e inconvenientes de unos cuantos de éstos
frameworks, información que he extraído de un documento de Matt Raible donde los compara
(ComparingJavaWebFrameworks.pdf).
6 de febrero de 2008 Tema 7 11

12. 3.1 JSF, Spring MVC, Stripes, Structs 2, Tapestry, Ticket
FRAMEWORK VENTAJAS INCONVENIENTES
- Es parte del estándar J2EE. - Los JSPs terminan siendo una ‘sopa’
- Permite realizar desarrollos de forma de etiquetas.
rápida y sencilla. - No funciona bien con restricciones de
JSF
- Existen multitud de librerías de seguridad.
componentes desarrollados. - No existe una única implementación
única.
- Facilidades para realizar - Multitud de XML para realizar la
validaciones, binding entre vista y configuración.
modelo, etc. - Se diría que es incluso demasiado
- Integración con múltiple vistas flexible.
Spring MVC
JSP/JSTL, Tiles, Velocity, etc. - No tiene soporte para Ajax
- Mediante el patrón IoC (Inversion of predefinido.
Control) que utiliza Spring se facilitan
las pruebas.
- No utiliza XML para la configuración - La comunidad ‘stripe’ es pequeña.
sino un convenio para el nombrado de - Este framework no tiene un desarrollo
clases. tan activo como otros.
Stripes
- Existe buena documentación. - Las direcciones URLs se encuentran
- Una comunidad de desarrollo ‘hard-coded’ en los ActionBeans, es
entusiasta. decir, directamente escritas dentro del
código de los ActionBeans.
- Arquitectura sencilla y fácilmente - La documentación se encuentra mal
extensible. organizada.
- La librería de etiquetas se pueden - Se tiene una concentración excesiva
Struts 2 personalizar con FreeMarker o en la nuevas funcionalidades.
Velocity. - Las búsquedas de documentación te
- Se puede definir la navegación remiten a la versión 1.x.
basada en Controladores o basada en
páginas.
- Es un framework muy productivo una - La documentación es más conceptual
vez que se aprende. que pragmática.
- Las plantillas son HTML, lo que es - La curva de aprendizaje es alta.
Tapestry muy conveniente si se trabaja - Los ciclos definidos para lanzar
conjuntamente con diseñadores nuevas versiones son excesivamente
gráficos. largos.
- En cada nueva versión se aportan
gran cantidad de innovaciones.
- Recomendado para desarrolladores - Las plantillas HTML se mezclan con
Java, no para desarrolladores web. el código Java.
Wicket - Las páginas y las vistas se encuentran - Se necesita tener un buen nivel de
altamente enlazadas. programación orientada a objetos.
- Participa una comunidad muy activa - Todo se hace en Java (Ticket Way).
en dicho framework.
6 de febrero de 2008 Tema 7 12

13. 6 de febrero de 2008 Tema 7 13