UNIVERSIDAD DE MLAGAESCUELA TCNICA SUPERIOR DE INGENIERA INFORMTICAINGENIERO TCNICO EN INFORMTICA DE GESTINArquitectura J2EE para el desarrollo gil de aplicaciones websRealizado porJavier Cisneros GonzlezDirigido porFrancisco Rus MansillaFrancisco Romn Villatoro MachucaDepartamentoLenguaje y Ciencias de la ComputacinUNIVERSIDAD DE MLAGAMLAGA, Diciembre 2010UNIVERSIDAD DE MLAGAESCUELA TCNICA SUPERIOR DE INGENIERA INFORMTICAINGENIERO TCNICO EN INFORMTICA DE GESTINReunido el tribunal examinador en el da de la fecha, constituido por:

Presidente/a D/D. ________________________________________________________________

Secretario/a D/D. ________________________________________________________________

Vocal D/D. _____________________________________________________________________

para juzgar el proyecto Fin de Carrera titulado: Arquitectura J2EE para el desarrollo gil de aplicaciones webs

realizado por D. Javier Cisneros Gonzlez

tutorizado por D. Francisco Rus Mansilla y D Francisco Romn Villatoro Machuca,

y, en su caso, dirigido acadmicamente por

D/D.___________________________________________________________________________

________________________________________________________________________________

ACORD POR ______________________________________ OTORGAR LA CALIFICACINDE _____________________________________________________________________________Y PARA QUE CONSTE, SE EXTIENDE FIRMADA POR LOS COMPARECIENTESDEL TRIBUNAL, LA PRESENTE DILIGENCIA.Mlaga a ____ de______________ del 2011Agradecimientosndice

1. Introduccin

1.1. Descripcin del proyecto

1.2. Antecedentes

1.3. Objetivos

1.4. Fases de trabajo

1.5. Estructura de la memoria1.6. Requisitos2. Arquitectura en JAVA con Maven2.1. JAVA

2.1.1. Framework

2.1.2. POJO

2.1.3. Bean

2.2. Patrn de diseo

2.2.1. Patrn MVC

2.2.2. Patrones de diseo J2EE

2.2.3. Patrn de inversin de control

2.2.4. Patrn de inyeccin de dependencias

2.3. Maven

3. Frameworks necesarios en la arquitectura

3.1. ORM

3.1.1. Hibernate

3.2. JSF

3.2.1. Myfaces

3.2.2. Tomahawk

3.2.3. Primefaces

3.3. Spring Security

3.4. Herramientas de test

3.4.1. JUnit

3.4.2. JMock

3.4.3. JMeter

3.5. Spring Framework

3.6. Log4j

4. Definicin de la arquitectura

4.1. Capa Model

4.2. Capa Core

4.2.1. Capa DAO

4.2.2. Capa Services

4.3. Capa Web

4.3.1. Capa Vista

4.3.2. Capa Action

4.4. Convenio de nombres

5. Creacin del arquetipo

5.1. Infraestructura de desarrollo

5.1.1. Google Code

5.2. Definiendo el proyecto

5.3. Instalacin de los frameworks y herramientas en la arquitectura

5.3.1. JAVA

5.3.2. Maven

5.3.3. Frameworks JAVA

5.3.3.1. Myfaces

5.3.3.2. Primefaces

5.3.3.3. Tomahawk

5.3.4. Spring Framework

5.3.5. Hibernate

5.3.6. Spring Security

5.3.7. Log4j

5.3.8. Framework para los test

5.4. Generacin del arquetipo

6. Trabajando con la arquitectura6.1. Preparacin y descarga

6.2. Utilizacin de la arquitectura6.2.1. Model

6.2.2. Core

6.2.3. Web7. Herramientas para el uso de la arquitectura7.1. IDE7.1.1. Eclipse7.1.2. Netbeans7.1.3. Intellij IDEA7.2. Base de datos7.2.1. MySQL7.2.2. Postgresql7.3. Servidores de aplicaciones7.3.1. Apache Tomcat

7.3.2. JBoss AS

7.3.3. Jetty

7.4. SVN

7.5. Instalacin de las herramientas

7.5.1. Bases de datos

7.5.1.1. MySQL

7.5.1.2. PostgreSql

7.5.2. IDE

7.5.2.1. Eclipse

7.5.2.2. Netbeans

7.5.2.3. Intellij IDEA

7.5.3. Servidor de aplicaciones

7.5.3.1. Apache Tomcat

7.5.3.2. Jboss

7.5.3.3. Jetty

7.5.4. SVN

8. Conclusiones9. Bibliografa y enlaces9.1. ndice de figuras9.2. ndice de tablasPgina7

7

7

8

8

8

9

11

11

12

12

12

12

14

14

17

18

18

29

29

29

32

34

36

37

38

42

42

43

44

46

50

53

55

56

58

59

61

61

63

68

71

71

71

74

80

84

85

85

85

86

87

88

89

92

94

95

96

97

97

98

99

102

108117117117118120

121122122123123124126127128128128128129129129130130130131131132134135

136

136

1. Introduccin

JAVA es el lenguaje de programacin ms utilizado y ms famoso del mundo. Sin duda ha contribuido a su xito ese desplazamiento al sector de las aplicaciones web que lleva sufriendo desde la llegada de Internet.

La forma de resolver JAVA el paradigma web fue mediante sus servlets y jsp. Posteriormente fue estandarizando en los llamados frameworks. Los frameworks revolucionaron las aplicaciones web consiguiendo que el trabajo fuera ms gil. Contienen una gran cantidad de funcionalidad y estn mantenidos por una comunidad que intenta optimizar el cdigo en la medida de lo posible.

Uno de estos frameworks que deben de ser el referente en los prximos aos es Java Server Faces 2, Despus del xito cosechado por la primera versin y gracias a los esfuerzos de la comunidad Apache, JSF debe de ser el framework que ms utilizaran los programadores de aplicaciones web. Hay varias implementaciones de JSF 2 entre las que destaca Myfaces 2.0. Myfaces tiene muchos componentes que hacen que no se tenga que estar programando una y otra vez algunas partes de las pginas webs. Se integra con herramientas muy potentes como Spring y tecnologas como AJAX.

Otro framework que tenemos que hacer mencin especial es Hibernate. Un ORM (Object Relational Modeling) que simplifica la gestin con la base de datos hacindola tan sencilla que hacen olvidar que exista una base de datos relacional y hace creer de que se trabaje directamente con objetos de un lenguaje orientado a objetos

Pero si todo funciona tan bien en JAVA cual es el problema? El problema es que JAVA se hace cada vez ms complejo. Sus proyectos son ms difciles de mantener y hace falta cada vez un personal ms cualificado para gestionar los proyectos.

Los proyectos conllevan un coste muy grande a la hora de iniciarse y de documentarse. An ms cuando hay incidencias en las APIs que se estn utilizando y hay que actualizarlas.

Los clientes exigen las ltimas tecnologas y los equipos de desarrollo tienen que esforzarse para renovarse una y otra vez

Maven vino a cubrir estos problemas que provenan del ciclo de vida de un proyecto. La construccin, la reutilizacin, la documentacin, la variedad de entornos en los que se puede desplegar. 1.1. Descripcin del proyectoEste proyecto trata de crear una arquitectura que simplifique el trabajo en Java. Creando una estructura que aporte el mayor nmero de soluciones en el menor cdigo posible. Multitud de proyectos los iniciados y creados a partir de cero, cuando se poda haber tenido una base con la que haber aligerado meses y meses de trabajo.En esencia se trata de dar el esqueleto de un cdigo en JAVA que instale y configure el proyecto con todos los frameworks y tecnologas necesarias. Se utiliza Maven para la instalacin y posterior mantenimiento del ciclo de vida de los proyectos que se creen con esta arquitectura.1.2. Antecedentes

Varias soluciones han sido expuestas desde diferentes sectores de la comunidad JAVA. Destacan soluciones como las de Netbeans o Eclipse, que intentan crear proyectos de determinado tipo desde su entorno con los que sus usuarios pueden empezar a trabajar.

Destaca tambin la aportacin de Matt Raible por sus arquetipos creados en Maven y sus arquitecturas para Ant creadas desde el ao 2005 al 2009.

1.3. ObjetivosEl principal objetivo es crear un arquetipo de Maven3 que integre una arquitectura innovadora y eficiente que ayude a la comunidad de programadores a iniciar y gestionar sus proyectos sin tanto esfuerzo.Se propone una arquitectura que rena las tecnologas ms vanguardistas. Buscando la sencillez, la abstraccin y reduciendo al mnimo el coste de inicio de un proyecto. Hay que integrar todos los framaworks que se necesiten para crear una arquitectura del tipo MVC (Modelo Vista Controlador) y despus crear un ejemplo de cada uno de ellos.El arquetipo deber de poder ser utilizado desde un repositorio pblico de Maven y poder ser descargado como un proyecto java para aquellos programadores que no tengan posibilidad de conectase a un servidor de Maven.Implementar un sistema de testeo que le aporte a los futuros proyectos que utilicen esta arquitectura cierta calidad en el cdigo. Se deber de ofrecer un testeo para pruebas unitarias, pruebas de integracin y para pruebas de stress. Junit, Jmock y Jmeter son en principio las herramientas que ms potencial tienen para entrar en la arquitectura.Todo el proyecto estar documentado en una wiki con acceso de cualquier usuario de Internet. La wiki servir para exponer el proyecto ante los desarrolladores y como manual de ayuda de nuestra arquitectura. Esto obligara a hacer un trabajo de mantenimiento para cubrir las posibles incidencias que tengan nuestros usuarios.1.4. Fases de trabajoLas fases del proyecto se dividen en 6 partes: Anlisis de requisitos y captacin de documentacin. Documentar funcionalmente cada parte del proyecto. Crear un arquetipo en Maven que solucione las carencias que ahora tenemos. Desarrollar un ejemplo de cada tecnologa para que los usuarios asimilen lo antes posible la tecnologa. Transformar el proyecto en un arquetipo para Maven. Documentacin de la memoria.1.5. Estructura de la memoriaInicialmente se explica que es un proyecto en el lenguaje JAVA y construido con la herramienta Maven para que el lector entienda los fundamentos del proyecto. Se continuar exponiendo los conceptos, framework y componentes que debera de conocer para utilizar de forma eficaz la arquitectura. Cuando se han aprendido todos los conceptos previos se puede presentar la arquitectura y seguir con un caso de ejemplo de cmo instalarla y utilizarla.

Hay que sealar que la memoria no sirve de gua de ninguna herramienta que aqu se explica. Hay muchos manuales tanto impreso como por Internet que se puede consultar si se quiere profundizar ms en el tema. En el apartado de enlaces de esta memoria se puede consultar los ms importantes y investigar a partir de ellos.1.6. Requisitos

Requisitos software para el desarrollo del proyecto: Windows XP y Linux en la distribucin de Kubuntu. JDK 1.6 de JAVA Tortoise o plugin de eclipse 'subclipse' para la comunicacin con el repositorio. IDE Eclipse. O Netbeans Maven 3.0 Alta en el proyecto Google Code. Base de datos Mysql y Posgresql. Servidor de aplicaciones Jboss 6.0 Contenedor de serlets y jsp Apache Tomcat 7.0 Servidor Http Jetty 7.02. Arquitectura en JAVA con MavenLa finalidad del proyecto es crear un arquetipo que aporte al usuario una arquitectura con la que empezar a trabajar. Un arquetipo es un proyecto de JAVA, as que se va a empezar a definir que es JAVA y cual es la forma ptima de utilizarlo.2.1. JavaJava es un lenguaje de programacin orientado a objetos, basado en la sintaxis que defini el lenguaje C. Actualmente Java es el mximo exponente de los lenguajes orientados a objetos, no por su rendimiento frente a otros lenguajes sino por su movimiento hacia el sector de Internet.

Fue creado por la empresa Sun Microsystems. En principio la principal motivacin de la empresa fue unificar en un lenguaje la multitud de arquitecturas incompatibles que estaban surgiendo. Despus el lenguaje tomo Internet como campo de batalla para crecer y hacerse fuerte.

Java se cre originalmente como una herramienta de programacin para un proyecto set-top-box conocido como *7. Fue realizado por un equipo de 13 personas, dirigidas por James Gosling.

Las principales ventajas de java son:

Robusto

Dinmico

Multiflujo

Alto rendimiento

Interpretado

Portable

Seguro

Distribuido

Orientado a objetos

Dinmico

No dependiente de la arquitectura

El programador escribe los ficheros de fuente java en un editor de texto y los guarda como ficheros *.java. El compilador de java los compila convirtindolos en ficheros *.class.

Hasta aqu todo es igual que el resto de los lenguajes de programacin. Ahora es cuando entra en juego la Mquina Virtual de Java.

El fichero *.class llega a la mquina virtual de java que se encarga de interpretar el programa y lo ejecuta. As se consigue que el programa se abstraiga de la arquitectura en la que est implantado dejndose esto en manos de la mquina virtual.Los principales navegadores de Internet y algunos sistemas operativos ya vienen con la mquina virtual de java instalados. Aunque siempre se le ofrece paquetes, a los usuarios de programas Java, que son accesibles desde la red y puede bajarse en http://sun.java.esSi JAVA esta instalado hay muchas formas de utilizarlo. Las ms comunes son por applets que se ejecutan en un navegador, ejecutar un jar o ejecutar directamente una clase java.

Las clases java se ejecutan desde las lneas de comando o desde IDE especializados (ms adelante se habla de los IDE y de su utilidad en la arquitectura).

Lanzndolo desde la lnea de comando con la aplicacin javac.

javac @options @classesHay una serie de conceptos de JAVA que hay que conocer a la hora de trabajar con la arquitectura, en especial los Beans, los POJOS y los Frameworks.2.1.1. FrameworksLa palabra inglesa "framework" define, en trminos generales, un conjunto estandarizado de conceptos, prcticas y criterios para enfocar un tipo de problemtica particular, que sirve como referencia para enfrentar y resolver nuevos problemas de ndole similar.

En el desarrollo de software, un framework es una estructura conceptual y tecnolgica de soporte definida, normalmente con artefactos o mdulos de software concretos, con base en la cual otro proyecto de software puede ser organizado y desarrollado. Tpicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto. [40]2.1.2. POJOUn POJO (acrnimo de Plain Old Java Object) es una sigla creada por Martin Fowler, Rebecca Parsons y Josh MacKenzie en septiembre de 2000 y utilizada por programadores Java para enfatizar el uso de clases simples y que no dependen de un framework en especial. Este acrnimo surge como una reaccin en el mundo Java a los Frameworks cada vez ms complejos, y que requieren un complicado andamiaje que esconde el problema que realmente se est modelando. En particular surge en oposicin al modelo planteado por los estndares EJB anteriores al 3.0, en los que los "Enterprise JavaBeans" deban implementar interfaces especiales. [41]2.1.3. BeansUn JavaBean o Bean es un objeto que sigue una serie de reglas que posibilitan su creacin, manejo y gestin en entornos principalmente visuales. Estas reglas son:

Debe tener un constructor sin argumentos.

Sus propiedades se hacen accesibles mediante mtodos get y set que siguen una nomenclatura establecida: getPropiedad() y setPropiedad(Tipo prop). Debe ser implementar la interfaz Serializable.2.2. Patrn de diseoEs importante conocerlos para entender porque se utiliza determinada estructura o determinado framework en la arquitectura. Se exponen la definicin de los patrones y luego los patrones que ms se utilizan en JAVA, sobre todo para la versin J2EE, versin especializada en aplicaciones webs.El concepto de "patrn de diseo" que tenemos en Ingeniera del Software se ha tomado prestado de la arquitectura. En 1977 se publica el libro "A Pattern Language: Towns/Building/Construction", de Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King y Shlomo Angel, Oxford University Press. Contiene numerosos patrones con una notacin especfica de Alexander.Alexander comenta que Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, para describir despus el ncleo de la solucin a ese problema, de tal manera que esa solucin pueda ser usada ms de un milln de veces sin hacerlo siquiera dos veces de la misma forma. El patrn es un esquema de solucin que se aplica a un tipo de problema, esta aplicacin del patrn no es mecnica, sino que requiere de adaptacin y matices. Por ello, dice Alexander que los numerosos usos de un patrn no se repiten dos veces de la misma forma.

La idea de patrones de diseo estaba "en el aire", la prueba es que numerosos diseadores se dirigieron a aplicar las ideas de Alexander a su contexto. El catlogo ms famoso de patrones se encuentra en Design Patterns: Elements of Reusable Object-Oriented Software, de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, 1995, Addison-Wesley, tambin conocido como el libro GOF (Gang-Of-Four). [37]Siguiendo el libro de GOF los patrones se clasifican segn el propsito para el que han sido definidos [37]:

Patrones creacionales: solucionan problemas de creacin de instancias. Ayudan a encapsular y abstraer dicha creacin. Abstract Factory (Fbrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre s y haciendo transparente el tipo de familia concreta que se est usando.

Builder (Constructor virtual): Abstrae el proceso de creacin de un objeto complejo, centralizando dicho proceso en un nico punto.

Factory Method (Mtodo de fabricacin): Centraliza en una clase constructora la creacin de objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica para elegir el subtipo que crear.

Prototype (Prototipo): Crea nuevos objetos clonndolos de una instancia ya existente.

Singleton (Instancia nica): Garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso global a dicha instancia

Patrones estructurales: solucionan problemas de composicin (agregacin) de clases y objetos. Adapter(Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podra utilizarla.

Bridge(Puente): Desacopla una abstraccin de su implementacin.

Composite(Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.

Decorator(Envoltorio): Aade funcionalidad a una clase dinmicamente.

Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.

Flyweight(Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idntica informacin.

Proxy: Mantiene un representante de un objeto

Patrones de comportamiento: soluciones respecto a la interaccin y responsabilidades entre clases y objetos, as como los algoritmos que encapsulan. Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada.

Command(Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma.

Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas necesarias para interpretarlo.

Iterator(Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementacin de estos.

Mediator (Mediador): Define un objeto que coordine la comunicacin entre objetos de distintas clases, pero que funcionan como un conjunto.

Memento(Recuerdo): Permite volver a estados anteriores del sistema.

Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automticamente todos los objetos que dependen de l.

State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.

Strategy (Estrategia): Permite disponer de varios mtodos para resolver un problema y elegir cul utilizar en tiempo de ejecucin.

Template Method (Mtodo plantilla): Define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.

Visitor(Visitante): Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar las clases sobre las que opera.

2.2.1. Patrn MVC

Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en tres componentes distintos. Fue descrito por primera vez en 1979 por Trygve Reenskaug, trabajador de Smalltalk, en unos laboratorios de investigacin de Xerox.

El patrn MVC se ve frecuentemente en aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina, el modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista [38]Las funcionalidades de las diferentes capas son [39]: El modelo es el responsable de:

Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.

Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercanca pedida no est en el almacn, consultar el tiempo de entrega estndar del proveedor".

Lleva un registro de las vistas y controladores del sistema.

Si estamos ante un modelo activo, notificar a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que desencadena una insercin, etc).

El controlador es responsable de:

Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).

Contiene reglas de gestin de eventos, del tipo "SI Evento Z, entonces Accin W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al mtodo "Actualizar ()". Una peticin al modelo puede ser "Obtener_tiempo(nueva_orden)".

Las vistas son responsables de:

Recibir datos del modelo y mostrarlos al usuario.

Tienen un registro de su controlador asociado (normalmente porque adems lo instancia).

Pueden dar el servicio de "Actualizacin ()", para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).

Se puede ver mejor el comportamiento de un sistema que utilice el patrn MVC mediante un diagrama de secuencias:

Figura X. Diagrama de secuencia del patrn MVC. [39]Describiendo los pasos en el MVC:

El usuario introduce el evento.

El controlador recibe el evento y lo traduce en una peticin al Modelo (aunque tambin puede llamar directamente a la vista).

El modelo (si es necesario) llama a la vista para su actualizacin.

Para cumplir con la actualizacin la Vista puede solicitar datos al Modelo.

El Controlador recibe el control.

2.2.2. Patrones J2EE

Con la aparicin del J2EE, todo un nuevo catlogo de patrones de diseo apareci. Desde que J2EE es una arquitectura por si misma que involucra otras arquitecturas, incluyendo servlets, JavaServer Pages, Enterprise JavaBeans, y ms, merece su propio conjunto de patrones especficos para diferentes aplicaciones empresariales. [42]De acuerdo al libro "J2EE PATTERNS Best Practices and Design Strategies", existen 5 capas en la arquitectura J2EE:

Cliente

Presentacin

Negocios

Integracin

Recurso

El libro explica 15 patrones J2EE que estn divididos en 3 de las capas: presentacin, negocios e integracin.

Patrones de la capa de presentacin:Decorating Filter / Intercepting FilterUn objeto que est entre el cliente y los componentes Web. Este procesa las peticiones y las respuestas.

Front Controller/ Front ComponentUn objeto que acepta todos los requerimientos de un cliente y los direcciona a manejadores apropiados. El patrn Front Controller podra dividir la funcionalidad en 2 diferentes objetos: el Front Controller y el Dispatcher. En ese caso, El Front Controller acepta todos los requerimientos de un cliente y realiza la autenticacin, y el Dispatcher direcciona los requerimientos a manejadores apropiada.

View HelperUn objeto helper que encapsula la lgica de acceso a datos en beneficio de los componentes de la presentacin. Por ejemplo, los JavaBeans pueden ser usados como patrn View Helper para las pginas JSP.

Composite viewUn objeto vista que est compuesto de otros objetos vista. Por ejemplo, una pgina JSP que incluye otras pginas JSP y HTML usando la directiva include o el action include es un patrn Composite View.

Service To WorkerEs como el patrn de diseo MVC con el Controlador actuando como Front Controller pero con una cosa importante: aqu el Dispatcher (el cual es parte del Front Controller) usa View Helpers a gran escala y ayuda en el manejo de la vista.

Dispatcher ViewEs como el patrn de diseo MVC con el controlador actuando como Front Controller pero con un asunto importante: aqu el Dispatcher (el cual es parte del Front Controller) no usa View Helpers y realiza muy poco trabajo en el manejo de la vista. El manejo de la vista es manejado por los mismos componentes de la Vista.

Tabla X. Patrones de la capa de presentacin.Patrones de la capa de negocios:Business DelegateUn objeto que reside en la capa de presentacin y en beneficio de los otros componentes de la capa de presentacin llama a mtodos remotos en los objetos de la capa de negocios.

Value Object/ Data Transfer Object/ Replicate ObjectUn objeto serializable para la transferencia de datos sobre lar red.

Session Faade/ Session Entity Faade/ Distributed FaadeEl uso de un bean de sesin como una fachada (facade) para encapsular la complejidad de las interacciones entre los objetos de negocio y participantes en un flujo de trabajo. El Session Faade maneja los objetos de negocio y proporciona un servicio de acceso uniforme a los clientes.

Aggregate EntityUn bean entidad que es construido o es agregado a otros beans de entidad.

Value Object AssemblerUn objeto que reside en la capa de negocios y crea Value Objets cuando es requerido.

Value List Handler/ Page-by-Page Iterator/ Paged ListEs un objeto que maneja la ejecucin de consultas SQL, cach y procesamiento del resultado. Usualmente implementado como beans de sesin.

Service LocatorConsiste en utilizar un objeto Service Locutor para abstraer toda la utilizacin JNDI y para ocultar las complejidades de la creacin del contexto inicial, de bsqueda de objetos home EJB y recreacin de objetos EJB. Varios clientes pueden reutilizar el objeto Service Locutor para reducir la complejidad del cdigo, proporcionando un punto de control.

Tabla X. Patrones de la capa de negocios.

Patrones de la capa de integracin:Data Access Object Service ActivatorConsiste en utilizar un objeto de acceso a datos para abstraer y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexin con la fuente de datos para obtener y almacenar datos.

Service ActivatorSe utiliza para recibir peticiones y mensajes asncronos de los clientes. Cuando se recibe un mensaje, el Service Activator localiza e invoca a los mtodos de los componentes de negocio necesarios para cumplir la peticin de forma asncrona.

Tabla X. Patrones de la capa de integracin.

2.2.3. Patrn de inversin de controlInversin de control (Inversion of Control en ingls, IoC) es un mtodo de programacin en el que el flujo de ejecucin de un programa se invierte respecto a los mtodos de programacin tradicionales, en los que la interaccin se expresa de forma imperativa haciendo llamadas a procedimientos (procedure calls) o funciones. Tradicionalmente el programador especifica la secuencia de decisiones y procedimientos que pueden darse durante el ciclo de vida de un programa mediante llamadas a funciones. En su lugar, en la inversin de control se especifican respuestas deseadas a sucesos o solicitudes de datos concretas, dejando que algn tipo de entidad o arquitectura externa lleve a cabo las acciones de control que se requieran en el orden necesario y para el conjunto de sucesos que tengan que ocurrir.El flujo habitual se da cuando es el cdigo del usuario quien invoca a un procedimiento de una biblioteca. La inversin de control sucede cuando es la biblioteca la que invoca el cdigo del usuario.

La utilizacin de interfaces y la aparicin de los frameworks han popularizado este trmino. De hecho es el concepto central del Framework de Spring, ya que implementa un "Contenedor" que se encarga de gestionar las instancias (as como sus creaciones y destrucciones) de los objetos del usuario. Por tanto las aplicaciones que utilicen el framework de Spring (no Spring propiamente dicho) utilizarn Inversin de Control. [44]2.2.4. Patrn de inyeccin de dependenciasEn Informtica, Inyeccin de Dependencias (en ingls Dependency Injection, DI) es un patrn de diseo orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto. El trmino fue acuado por primera vez por Martin Fowler.Tpicamente este contenedor es implementado por un framework externo a la aplicacin (como Spring o uno propietario), por lo cual en la aplicacin tambin se utilizar Inversin de Control al ser el contenedor (almacenado en una biblioteca) quien invoque el cdigo de la aplicacin. sta es la razn por la que los trminos de Inversin de Control e Inyeccin de Dependencias se confunden habitualmente entre s. [45]2.3. MavenEl arquetipo va a ser un proyecto en JAVA pero es un tipo de proyecto especial ya que sigue una determinado estructura y caractersticas que exige Maven. Se va a describir para que sirve y como utilizar Maven.

Maven es una herramienta para la gestin del ciclo de vida de las aplicaciones. Funciona como una aplicacin en Java y es un Opensource de la fundacin Apache. Bajo una licencia Apache Licence 2.0.

Pero que es gestionar el ciclo de vida de un software? Maven tiene las virtudes de poder crear un proyecto o descargrselo de algn repositorio, construirlo, definir las dependencias, integrar el proyecto con los IDE's, compilacin, empaquetado, pruebas unitarias, pruebas de estrs y funcionalidad, calidad y documentacin del cdigo.

Maven tiene su opositor en Ant tambin de Apache. Ant tiene menos funcionalidad que Maven es ya que solo es un constructor de proyectos, una funcionalidad de las muchas que tiene Maven. Es fcil pensar que Maven es un complemento de Ant, al tener ms funcionalidad y por poder invocarse desde Maven.

Las ventajas de Maven en la produccin de proyectos software:

Hacer el proceso de construccin fcil.

Proveer un proceso de construccin uniforme.

Proveer una cantidad de informacin sobre el proyecto.

Servir como gua de buenas practicas de desarrollo de software.

Permitir una migracin transparente a nuevas funcionalidades.

Setup simple de proyectos siguiendo buenas practicas de software. Generar un proyecto nuevo en pocos segundos.

Manejo de dependencias incluyendo actualizaciones automticas. Tanto dependencias primarias como transitivas.

Permite trabajar de una forma fcil con mltiples proyectos al mismo tiempo.

Grande y creciente repositorio de libreras y metadatos externo a nuestro proyecto. Liberando as el sistema de control de versiones de contener jars.

Es extensible. Haciendo uso de sus sistema de plugins en java o en lenguajes de scripts.

Acceso instantneo a nueva funcionalidades con una mnima o ninguna configuracin.

Posibilidad del uso de tareas ant para manejar dependencias y despliegue fuera de Maven.

Maven esta preparado para un gran nmero de builds para proyectos, ya sea tipo jar, war, ear.

Usando los metadatos asociados al proyecto, Maven es genera un sitio web o pdf incluyendo cualquier documentacin que se quiera. Adems de toda la informacin que Maven aade como api, java doc, informacin sobre desarrolladores, informes de test, etc.

Manejo de release y publicacin de distribuciones. Maven pude ser integrado con el sistema de control de versiones y manejar las releases de un proyecto en un tag concreto. Maven puede publicar distribuciones basadas en jar, en un archivo incluyendo dependencias y documentacin, o una distribucin de fuentes.

Manager de dependencias: Maven impulsa el uso de un repositorio central de JARs y otras.

Los inconvenientes de Maven en la gestin de proyectos software:

Su curva de aprendizaje es muy pronunciada. Los informticos que desarrollen el proyecto deben de estar muy preparados en conocimientos de Java.

A continuacin se van a describir unos conceptos importantes de Maven:

Los ficheros POM (Project Object Model) son ficheros en formato XML obligatorio en todo proyecto Maven, donde se incluye la informacin (meta-datos) necesaria para que ste pueda construir y gestionar el proyecto.

Artefacto: Es para Maven la unidad mnima con la que trabaja a la hora de gestionar sus dependencias.

Coordenadas: Sistema con el Maven determina de forma nica a cada uno de sus artefactos.

Goal: Son las unidades de mnimas de ejecucin. Las tareas ms simples.

Ciclo de vida: Secuencia de etapas que propone Maven para la gestin de un proyecto.

Las fases del ciclo de vida de Maven son [8]:

pre-clean: ejecuta los procesos necesarios para la limpieza.

clean: elimina todos los ficheros generados en la construccin previa.

post-clean: ejecuta los procesos necesarios al finalizar la limpieza del proyecto.

validate: valida que el proyecto es correcto y tiene toda la informacin necesaria.

inicializate: Inicializa la construccin, modificando propiedades o creando directorios.

generate-sources: Genera algn cdigo fuente para utilizarlo en la compilacin.

process-sources: Procesa el cdigo fuente anterior.

generate-resources: Genera los recursos para incluirlos en el paquete.

process-resources: Copia y procesa los recursos al directorio de trabajo.

compile: Compila el cdigo fuente.

process-classes: Ejecuta unas tareas despus del la generacin de los cdigos compilados, por ejemplo por si hubiera que cambiar el bytecode de las clases.

generate-test-sources: Genera algunos cdigos fuentes de los test para la inclusin en la compilacin.

process-test-sources: Procesa el cdigo fuente de los test, por ejemplo filtrar algunas variables.

generate-test-resources: Crea los recursos para el test.

process-test-resources: Copia y procesa los recursos dentro del directorio destino de los test.

test-compile: Compila el cdigo fuente de los test dentro del directorio destino de los test.

process-test-classes: Hace un postprocesado de la generacin de ficheros de la compilacin de los test. Por ejemplo se cambia el bytecode.

test: compila el cdigo y ejecuta los unit test correspondientes. Sin embargo no es requisito para que el proyecto sea desplegado.

prepare-package: Prepara algunas operaciones necesarias antes del empaquetado.

package: toma el cdigo compilado y lo empaqueta en un formato distribuible como JAR o WAR.

pre-integration-test: prepara algunas operaciones antes que se ejecuten los test de integracin.

integration-test: Despliega el proyecto si es necesario en ambiente de pruebas donde se puedan correr pruebas de integracin.

post-integration-test: prepara algunas operaciones despus que se ejecuten los test de integracin. Esto puede incluir la limpieza del entorno.

verify: ejecuta cualquier verificacin para cumplir los parmetros de calidad.

install: instala el jar o war en el repositorio local para que otras aplicaciones locales la puedan usar.

deploy: copia el jar o war a un repositorio remoto para que pueda ser usado por otro desarrollador o proyecto.

pre-site: ejecuta los procesos necesarios para la generacin del site.

site: genera la documentacin del site proyecto

post-site: ejecuta los procesos necesarios al finalizar la documentacin del site y prepara para el despliegue.

site-deploy: despliega la generacin del site al servidor especificado.

Figura X. Ciclo de vida de Maven 3. [46]Estructura de directorios: Propuesta que realiza Maven para organizar los distintos archivos que conforman un proyecto.

Los proyectos en Maven siempre marcan una determinada estructura, esto simplifica el trabajo a la hora de migrar un equipo de desarrollo a otro proyecto de Maven, ya que todos mantienen las mismas pautas.

La estructura estndar de un proyecto en Maven es:

Directorio Descripcin

/aplicacion/pom.xml Fichero de configuracin de Maven

/aplicacion/src/ Cdigo fuente

/aplicacion/src/main/java/ Cdigo fuente de java

/aplicacion/src/test/java/ Test de JUnits

/aplicacion/src/main/resources/ Recursos necesarios en el classpath

/aplicacion/src/test/resources/ Recursos necesarios en el classpath para los test

/aplicacion/src/main/webapp Contiene los html, jsp y dems contenidos de una aplicacin web

/aplicacion/target/classes/ Clases ya compiladas

/aplicacion/target/test-classes/ Las clases de los test ya compiladas

/aplicacion/target/dots Otras salidas de documentos

/aplicacion/target/{#filename} En los proyectos war tienen el contenido de la creacin del war

Tabla X. Estructura de carpetas de un proyecto Maven.

Archetype: Son plantillas con las definir la base de proyectos tipo con el fin de reutilizarlas.

Los archetype son simples plugins de Maven, uno de ellos es el archetype create, el cual permite crear un proyecto base al proporcionar la plantilla del mismo.

El archetype create recibe una serie de parmetros los cuales son:

archetypeGroupId: Identificador del grupo del archetipo. groupId, es usado como identificador del conjunto de libreras en este caso hemos usado org.archetypeUma como nombre para nuestro paquete de libreras.

artifactId, es usado como identificador particular de una librera en particular.

Cuando se usan archetypes creados por uno mismo se tiene que especificar los tres parmetros de todo archetype (groupId, artifactId, version) de la siguiente manera.

mvn archetype:create -DarchetypeGroupId= -DarchetypeArtifactId= -DarchetypeVersion= -DgroupId= -DartifactId=

Si es la primera vez que se ejecuta un comando Maven ste tomar algo de tiempo pues Maven crear el repositorio inicial .m2 y descargar todas las libreras necesarias para construir el proyecto.

En este caso el archetype contiene la plantilla de un proyecto web.

Finalizado el proceso de construccin del artefacto, Maven lo deposita en repositorios.

Repositorio: Estructura de directorios y archivos que usa Maven para almacenar, organizar y recuperar artefactos. Existen repositorios locales (file://) y remotos (http://)

Existen dos tipo de repositorios:

Repositorio local: situado en la mquina del desarrollador. Almacena artefactos instalados (Maven install) y descargados de repositorios remotos.

Repositorio remotos: repositorios accesibles a travs de protocolos file:// y http://.

internos: utilizados por las empresas para almacenar sus artefactos que son compartidos por los desarrolladores.

externos: repositorios pblicos utilizados para almacenar artefactos de terceros.

Hay varias herramientas que permiten gestionar un repositorio. Si el lector esta interesado en profundizar en el tema le aconsejamos que siga por Archiva o Artefactory, que son software libre muy utilizado.

Profiles: Son un mecanismo (no alternativa) de configurar el proceso de construccin.

En ciertos proyectos es importante trabajar con varias bases de datos, en varios entornos diferentes o en varios servidores. Las libreras y las variables de configuracin que se necesitan para arrancar en cada entorno son diferentes. Maven resuelve esto mediante profiles:

mysql

db

mysql

org.mysql.Driver

postgresql

db

postgresql

org.postgresql.Driver

Basta con pasarle a Maven con que perfil quiere instalar.

mvn -Pmysql clean

Los perfiles en la versin 3 de Maven hay que meterlos en el fichero M2_HOME/conf/settings.xml, antes Maven acostumbraba meterlos en un fichero profiles.xml que acompaaba al pom.xml principal.Los tag ms importantes en el uso de Maven son:

: El id del grupo al que pertenece el proyecto.

: El id del artifact o proyecto (en la mayora de los casos el nombre del proyecto).

: La versin del artifact en el grupo especificado.

org.archetypeUma

archetypeUma-model

jar

1.0-SNAPSHOT

Lo de -SNAPSHOT en el nombre de la versin hay que explicarlo detalladamente. Si dependemos de un jar que tenga -SNAPSHOT, cada vez que compilemos, aunque ese jar est en nuestro repositorio local, Maven ira a buscarlos a los repositorios comunes o de Internet, para ver si hay una versin de fecha ms moderna. Si la hay, se la bajar. Por tanto, suele ser til en un equipo de trabajo mantener la "coletilla" -SNAPSHOT en los jar que todava estn en desarrollo y sufren cambios frecuentes.Si no ponemos -SNAPSHOT, una vez bajado el jar a nuestro repositorio local, Maven NO se preocupar de buscar si hay versiones ms modernas en los repositorios remotos.En los poms se pueden definir muchos componentes. Se van a explicar los que han sido utilizados para crear esta arquitectura y los ms utilizados.

Empezando por developers, sirve para especificar los desarrolladores y el equipo que ha intervenido en el proyecto.

jcisneros

Javier Cisneros Gonzlez

javicisneros@gmail.es

scm: son las siglas de Source Code Management (Gestin de cdigo fuente), es la revisin de mltiples versiones de una misma unidad de informacin. Con el siguiente XML se especifica donde esta el cdigo del proyecto. Esto no es obligatorio pero si es muy guardarlo en el pom principal del proyecto.

scm:svn:https://archetypeuma.googlecode.com/svn/trunk/

scm:svn:https://archetypeuma.googlecode.com/svn/trunk/

licenses: Las licencias del proyecto se marcan bajo la etiqueta XML llamada licences. En las siguientes lneas se especifica que el proyecto ser de software libre bajo la licencia Apache License 2.0 y European Union Public License.

EUPL v1.0

http://ec.europa.eu/idabc/eupl

European Union Public License

Apache License 2.0

http://www.apache.org/licenses/LICENSE-2.0

modules: La etiqueta module asigna al pom los submodulos que se ejecutarn despus de ejecutarse el mismo. Es ideal para lanzar una construccin en varios modulos, ya que crearlo en uno solo puede resultar muy engorroso.

model

core

web

repositories: Maven se baja las dependencias de los servidores que sirven de repositorios. Esos repositorios pueden estar en cualquier sitio de Internet o de una red local. Hay que especificarle al proyecto donde estn los repositorios desde los que se quiere descargar las dependencias del proyecto.

En el siguiente ejemplo se utiliza el repositorio pblico de Jboss.

jboss

JBoss repository

http://repository.jboss.org/Maven2

pluginRepositories: Al igual que el caso anterior, Maven busca los plugins en los repositorios remotos, en lugar de apuntar con la etiqueta repositories, se utiliza pluginRepositories.

appfuse

http://static.appfuse.org/repository

alfresco

http://Maven.alfresco.com/nexus/content/repositories/sourcesense-public

Maven2-repository.dev.java.net

Java.net Repository for Maven

http://download.java.net/Maven/2/

default

mc-release

Local Maven repository of releases

http://mc-repo.googlecode.com/svn/Maven2/releases

false

true

repo1

Repo-1 for Maven 2

http://repo1.Maven.org/Maven2/

default

resources: Se especifica los recursos que necesitarn las clases java para funcionar correctamente. Aqu caben muchas posibilidades... plantillas, xml, ficheros estticos. Se suele poner el fichero de recursos de Maven src/main/resources. Al meterlo se empaquetara en el jar, war o ear como un fichero ms.

true

src/main/resources

testResources: Se especifica con testResources cual ser el directorio de recursos para los test. Es decir, que si un test necesita determinado fichero para utilizar, por ejemplo un xml, este se buscar en estos directorios.

true

src/test/resources

dependency: Los proyectos en Java se han llenado de libreras que tienen que interactuar entre si para formar los proyectos, lo ms abstractos posibles. Solo hay que especificar el groupId el artifactId y la versin que se desea descargar.

Este es un ejemplo de como aadir una dependencia a un pom.xml en un proyecto de Maven.

log4j

log4j

1.2.15

groupId: es usado como identificador del conjunto de libreras en este caso se ha usado log4j como nombre para nuestro paquete de libreras.

artifactId: es usado como identificador particular de una librera en particular. Como log4j solo tiene una coincide con el groupId pero esto no debe porque ser as.

version: Es la versin de la librera que se desea meter como dependencia en el proyecto.

scope: es la fase del ciclo de vida de Maven a la que se le asociar la dependencia. Existen seis mbitos en los que una dependencia puede ser declarada limitando as su transitividad:

Compile, es el mbito por defecto. Las dependencias estn disponibles en el proyecto y en sus proyectos dependientes.

Provided, se espera que el JDK, la aplicacin o el contenedor provea la dependencia.

Runtime, la dependencia no es requerida en tiempo de compilacin pero s para la ejecucin.

Test, son dependencias que son requeridas solo cuando se compila y ejecuta los test.

System, similar a provided pero se le debe indicar el jar que contiene la dependencia

Import, (a partir a la version 2.0.9) solo es usado en una dependencia del tipo POM en la seccin . Indica que el POM utilizado debe ser remplazado con las dependencias que ste tenga en su seccin

javassist

javassist

3.9.0.GA

runtime

En el scope se aade runtime para que la dependencia este presente solo en el empaquetado final del proyecto. Ya que no es necesaria ni a la hora de compilar, ni para los test ni en el resto de fases del ciclo de vida de Maven.

junit

junit

4.5

test

En este scope le pasamos como argumento test, ya que solo ser necesario en la fase de test y este jar no deber de estar presente en el empaquetado final del proyecto, ni en el war ni en el ear.

La nomenclatura de las dependencias es la siguiente:

artetifacId version package(jar, war, aer)

En un ejemplo

myfaces-core-2.0.0.jar

La versin corresponde a mayor minor parches en este caso 2.0.0 Segunda versin, an sin cambios y sin parches arreglados.

Un plugin es un programa que se ejecuta en Maven. Partiendo del ejemplo de compilar, solo es necesario tener el plugin de Maven-compiler-plugin en el pom.xml para que se compilara el proyecto. Hay muchos tipos de plugins y es perfectamente ampliable por cada usuario que necesite alguna funcionalidad que no este creada.

org.apache.Maven.plugins

Maven-compiler-plugin

2.0.2

1.5

1.5

En la siguiente tabla se muestra una serie de plugins muy utilizados en los proyectos que se estn utilizando hoy en da.

Pluguins ms utilizados Descripcin

Maven-clean-plugin Limpia el directorio de trabajo.

Maven-compiler-plugin Compila el cdigo fuente.

Maven-deploy-plugin Despliega el artefacto en un servidor remoto.

Maven-install-plugin Instala el artefacto en el repositorio local.

Maven-resources-plugin Copia los recursos al directorio de salida.

Maven-site-plugin Genera el site del proyecto

Maven-surefire-plugin Ejecuta los test de Junit

Tabla X. Plugin ms utilizados de Maven.

A continuacin se describen las rdenes ms importantes de Maven que todo aquel que trabaje con esta herramienta debe de conocer:

ComandoDescripcin

mvn versionVer la versin de Maven.

mvn cleanLimpiar el directorio de trabajo de Maven de un proyecto es sencillo solo hay que aadir clean. El directorio de trabajo es la carpeta target.

mvn helpMostrar la ayuda de Maven con el comando.

mvn -XSi hay algn problema y ha salido el mensaje BUILD FAILURE se puede comprobar que ha pasado escribiendo -X con lo que se ven las trazas en modo DEBUG.

mvn testEjecutar la fase del ciclo de vida de Maven referente a los test.

mvn packageEmpaquetar en un jar, war o un ear. No instala los empaquetados en el repositorio local ni remoto.

mvn installInstalar en el repositorio. Compila el proyecto, ejecuta los test, empaqueta los war y ear e instala el artefacto en el repositorio local de Maven. (%M2_REPO%)

mvn deploySi lo que se pretende es instalar en un repositorio remoto en vez de en el local. Se ejecuta un deploy. Esto tendra que hacerlo un sistema de integracin continua como es Hudson.

mvn dependency:treeObtener el rbol de dependencias y optimizarlas para excluir las que no se necesiten.

mvn dependency:resolveMuestra una listado de todos los artefactos que han sido resueltos.

mvn clean install -o

-DMaven.test.skip=trueEn un equipo de desarrollo la orden ms utilizada es la compilacin, empaquetado e instalacin.

Con el argumento -o seleccionamos el modo offline. Algo que ser til en el equipo de desarrollo cada vez que se compile, ya que no se perder tiempo en conectarse con los repositorios externos.

Con el argumento -DMaven.test.skip=true salta en el al ciclo de vida la fase de test y por tanto todos los plugins asociados a este ciclo de vida. Al igual que el argumento anterior esto har que se compile ms rpidamente el proyecto.

mvn compileCompila los fuentes del proyecto.

mvn eclipse:eclipseCrea un proyecto en eclipse a partir de un proyecto Maven.

mvn idea:ideaCrea un proyecto en Intellij IDEA a partir de un proyecto Maven.

Tabla X. Comandos ms importantes de Maven. 3. Frameworks necesarios en la arquitectura

3.1. ORMEl mapeo objeto-relacional (ms conocido por su nombre en ingls, Object-Relational mapping, o sus siglas O/RM, ORM, y O/R mapping) es una tcnica de programacin para convertir datos entre el sistema de tipos utilizado en un lenguaje de programacin orientado a objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia. En la prctica esto crea una base de datos orientada a objetos virtual, sobre la base de datos relacional. Esto posibilita el uso de las caractersticas propias de la orientacin a objetos (bsicamente herencia y polimorfismo). Hay paquetes comerciales y de uso libre disponibles que desarrollan el mapeo relacional de objetos, aunque algunos programadores prefieren crear sus propias herramientas ORM. [48]

El ORM ms utiliza en la actualidad es Hibernate.

3.1.1. Hibernate

Hibernate es un ORM para Java. Es una capa de persistencia objeto/relacional y un generador de sentencias sql. Permite disear objetos persistentes que podrn incluir polimorfismo, relaciones, colecciones, y un gran nmero de tipos de datos. De una manera muy rpida y optimizada puede generar BBDD en cualquiera de los entornos soportados: Oracle, DB2, MySql, Postgresql.Es software libre y su cdigo es abierto, bajo licencia LGPL. Actualmente el proyecto pertenece a Red Hat pero esta cedido a la fundacin Apache.

Fue creado en 2001 por Gavin King.

Un ORM es una tecnologa capaz de entender que una clase de Java se corresponde con una tabla de la base de datos y que un objeto de Java se corresponde con una tupla de la base de datos.

Hibernate ha estado mejorando. La mejora ms significativa la consigui cuando cambio los engorrosos XML por anotaciones, despus de que saliera el estndar JPA.

El estndar JPA (Java Persistence API) fue descrito en la Java Specification Request (JSR) 220.

Con el fin de meter al lector en conocimiento de la utilizad de Hibernate se va a exponer un ejemplo de como se insertaba un usuario en base de datos antes de Hibernate y despus de Hibernate.

Sin Hibernate:

Class.forName(org.hsqldb.jdbcDriver);

String url = jdbc:hsqldb:./Databases/ejemplo;

Connection connection = DriverManager.getConnection(url, root, pass);

String ins = INSERT INTO TABLE_USER VALUES(jcisneros, javier);

Statement stmt = null;

stmt = connection.createStatement();

stmt.executeUpdate(ins);

Con Hibernate y Spring:

User user = new User(jcisneros, javier);

userDao.save(user);

Hibernate funciona con dos tipos de anotaciones. Las suyas propias y las que provienen del estndar JPA. Las del estndar son suficientes para la mayora de las aplicaciones que se quieran producir y las de Hibernate aaden funcionalidad para problemas ms concretos.

El HQL (Hibernate Query Language) es un lenguaje de interrogacin. En el mundo relacional se rige por el SQL (Structured Query Language) que permite obtener informacin haciendo preguntas basadas en las tablas y sus columnas. El equivalente en el mundo actual es el HQL, que permite hacer preguntas basadas en los objetos y sus propiedades.

Hibernate se encarga traducir las consultas desde las clases en HQL al lenguaje de interrogacin de la base de datos relacional, el SQL, y transforma los resultados obtenidos en la base de datos relacional (filas y columnas) en objetos de Java.

Adems, Hibernate hace uso de APIs de Java, tales como JDBC, JTA (Java Transaction Api) y JNDI (Java Naming Directory Interface).

Los objetos ms importantes definidos en Hibernate son:

La interfaz Session es una de las interfaces primarias en cualquier aplicacin Hibernate. Una instancia de Session es "poco pesada" y su creacin y destruccin es muy "barata". Esto es importante, ya que la aplicacin necesitar crear y destruir sesiones todo el tiempo, quiz en cada peticin. Puede ser til pensar en una sesin como en una cach o coleccin de objetos cargados (desde una base de datos) relacionados con una nica unidad de trabajo. Hibernate puede detectar cambios en los objetos pertenecientes a una unidad de trabajo.

La interfaz SessionFactory permite obtener instancias Session. Esta interfaz no es "ligera", y debera compartirse entre muchos hilos de ejecucin. Tpicamente hay una nica SessionFactory para toda la aplicacin, creada durante la inicializacin de la misma. Sin embargo, si la aplicacin accede a varias bases de datos se necesitar una SessionFactory por cada base de datos.

La interfaz Configuration se utiliza para configurar y "arrancar" Hibernate. La aplicacin utiliza una instancia de Configuration para especificar la ubicacin de los documentos que indican el mapeado de los objetos y propiedades especficas de Hibernate, y a continuacin crea la sessionFactory.

La interfaz Query permite realizar peticiones a la base de datos y controla cmo se ejecuta dicha peticin (query). Las peticiones se escriben en HQL o en el dialecto SQL nativo de la base de datos que estemos utilizando. Una instancia Query se utiliza para enlazar los parmetros de la peticin, limitar el nmero de resultados devueltos por la peticin, y para ejecutar dicha peticin.

Si se quiere llegar a entender el funcionamiento de hibernate hay que empezar por comprender el ciclo de vida que sigue un objeto que es manipulado por hibernate.

Figura X. Ciclo de vida de Hibernate. [50]Los estados son Transient, Persistent y Detached y los procesos por los que cambia de estado un objeto son esos mtodos que se invocan desde el cdigo y que hacen que el objeto cambie. El estado ms importante es el de Persistent al que se llega cuando se invoca un save sobre el objeto.

A conticuacin se listan las anotaciones ms utilizadas:

AnotacinDescripcin

@EntityDeclara la entidad que ser persistida

@Table(name=TABLE_USER);Asigna el nombre de la tabla

@IdRepresenta la clave primaria de la tabla

@GeneratedValueGener la clave primaria, en esta ocasin se crear una secuencia, pero hibernate da varias posibilidades.

@LobCorresponden a los campos del tipo BLOB y CLOB.

@Temporal@Temporal(TemporalType.DATE) definido para el tipo java.sql.Date.

@Temporal(TemporalType.TIME) definido para el tipo java.sql.Time.

@Temporal(TemporalType.TIMESTAMP)

definido para el tipo java.sql.Timestamp.

@TransientSe marca as un atributo no ser persistido.

@OneToOne

@ManyToOne

@OneToMany

@ManyToManyRelaciones entre tablas. A la izquierda del To se entiende que es esa misma clase y a la derecha la otra clase.

@JoinColumn (ManyToOne)

@JoinTable (ManyToMany)Indica como se relacionan las dos tablas.

@Inheritance

Expresa herencia, se puede utilizar de varias formas segn la estrategia para recuperar los datos:

strategy=InheritanceType.TABLE_PER_CLASS

strategy=InheritanceType.JOINED

(strategy=InheritanceType.SINGLE_TABLE)

Tabla X. Anotaciones ms utilizadas en Hibernate.Hay que tener en cuenta como hibernate recupera los elementos, para eso existen dos atributos en las anotaciones:

FetchType.LAZY: recuperacin tarda. Valor por defecto para:

OneToMany

ManyToMany

FetchType.EAGER: recuperacin temprana. Valor por defecto para:

OneToOne

ManyToOne

Y se pueden utilizar los mtodos para recuperarlos:

session.get() hace recuperacin temprana.

session.load() hace recuperacin tarda

Existen muchas formas de interactuar con la base de datos por medio de Hibernate. Todas distintas en esencia aunque la mayora hacen lo mismo.

Criterias: Son unos objetos que definen bsquedas condicionales contra algunos objetos. Es decir, si se esta buscando las vuelos con salida de mlaga y destino granada, en las que estas son elegidas en combos, lo ideal sera ponerlo en este tipo de bsquedas.

HQL: Es un lenguaje creado para ser utilizado desde hibernate. Tiene una nomenclatura sencilla y parecida al sql pero con algunas diferencias para que se interacte con objetos y no con tablas.

Query: son un tipo de bsqueda especial en hibernate, la cual se puede definir en una anotacin o ponerla directamente.

Lo que se pretende es hacer que bsqueda sea lo ms fcil posible de crear y de entender, pero no queremos confundir al lector, con los tres tipos de bsqueda se puede hacer las mismas bsquedas.3.2. JSF 2

JSF 2 es un frameworks web que facilita la construccin de aplicaciones web.

JSF 2 define tres caractersticas: una arquitectura de componentes, un conjunto estndar de UI widgets, y una infraestructura de aplicacin. La arquitectura de componentes JSF define una manera comn para construir UI widgets (botones, hyperlinks, checkboxes, cajas de texto, entre otros), pero tambin establece las pautas para componentes de terceros. Estos componentes con orientados a eventos y JSF permite manejar eventos del cliente (cambiar el valor de un textbox o hacer clic en un botn).

Faces puede automticamente mantener tus componentes UI en sincronizacin con los objetos JAVA que coleccionan los valores ingresados por el usuario y responder a eventos, los cuales son llamados Backing Beans. Adicionalmente, tambin tiene un sistema poderoso de navegacin y soporte completo para mltiples lenguajes.

JSF 2 se ejecuta en el Server, por ejemplo una aplicacin Faces se ejecutara en un contenedor web

como Tomcat, Oracle Application Server o Jboss, y mostrar HTML u otras marcas en el cliente.

Cuando se hace un clic en un botn, Faces ejecuta un request que es enviado desde nuestro web browser hacia el Server. Faces es responsable por trasladar ese request hacia el evento que ser procesado por nuestra lgica en el Server. Es responsable tambin de mostrar en el navegador cada UI widget que hayamos definido.

Los componentes ms importantes de la especificacin son:

TerminoDescripcin

UI Component (componente de usuario o

simplemente denominado componente)Un objeto mantenido en el server, que provee

funcionalidad especifica para interactuar con el

usuario final. Los UI components son JavaBeans

con properties, mtodos y eventos. Ellos son

organizados en una vista, la cual es un rbol de

componentes usualmente mostrados como una pgina.

RendererResponsable por mostrar un componente UI y traducir la entrada del usuario en un valor al interior del componente. Los Renderers pueden

ser diseados para trabajar con uno o mas UI components.

ValidatorResponsable por asegurarse que el valor ingresado por el usuario es aceptable. Uno o mas validadores pueden ser asociados con un

simple UI component.

Backing BeansSon JavaBeans especializados que coleccionan valores desde los UI components e implementan

mtodos relacionados a los eventos de los UI

components. Ellos tambin pueden almacenar referencias a UI components.

ConverterConvierte el valor para y desde un componente para ser mostrado. Todos los UI components pueden ser asociados con un simple converter.

Events y ListenersJSF usa el modelo event/listener (tambin usado

por Swing). UI components (y otros objetos) generan eventos, y los listeners pueden ser registrados para manejar estos eventos.

MensajesInformacin que es muestra de regreso al usuario. Solo ciertas partes de la aplicacin (backing beans, validators, converters) pueden generar informacin o mensajes de error que pueden ser mostrados de regreso al usuario.

NavigationLa habilidad para moverse de una pagina a otra.

JSF tiene un sistema poderoso de navegacin

que esta integrado con event listeners especializados.

Tabla X. Componentes de JSF 2.3.2.1. Myfaces

Myfaces en la versin 2.0 es una implementacin de JSF 2. Slo es un estndar, define un marco de trabajo.

Lo mejor es empezar con una breve introduccin de JSF y Myfaces para entender mejor Myfaces.

JSF es un estndar de programacin web basado en eventos. Es decir, intenta aplicar el modelo tradicional de eventos, tan utilizados en Delphi y VisualBasic, al entorno web.

JSF abre a la web el modelo tradicional de componentes. Aprovechando que debe de crear estos componentes hace que estos sean reproducibles en diferentes dispositivos no solo en el HTML tpico de un explorador web. Siendo ampliable as a PDA, mviles y otros dispositivos.

El paso de transformacin de un componente JSF en el elemento resultante, que puede ser otro cualquiera pero que en este proyecto ser el HTML, se hace a partir de un proceso que se conoce como renderizado.

JSF separa el renderizado del componente para poder adaptarlo a cualquier dispositivo de salida.

Las principales caractersticas de JSF son:

Permite modificar o incorporar componentes propios o de terceros.

Permite configurar y definir externamente el flujo de navegacin entre las pantallas.

Aporta un ciclo de vida claro y estndar.

Incluye validadores, eventos, Javabeans, conversores.

Como mejora importante hay que incluir que myfaces 2.0 ya trae integrada la tecnologa de facelets. Ya que jsf es una tecnologa orientada a componentes y las JSP es una tecnologa orientada a generar servlets. Pero al no coincidir haba que hacer que alguien las casar. Es por lo que Facelets, una tecnologa orientada a construir rboles de componentes en JSF era tan habitual en los proyectos y por lo que ha sido incluida como estndar en Myfaces2.0.

El ciclo de vida de JSF es el siguiente:

Figura X. Ciclo de vida de JSF 2. [47]

Entrando en ms detalle:

Restore View :El servidor recibe una llamada y recompone los objetos de la vista en el servidor. Su principal objetivo es encontrar que vista esta asociada a la peticin hecha por el usuario. Examina si FacesContext tiene un UIViewRoot para asignarle un locale y para recoger los valuebinding y asociarlo con el setValue(). Si la peticin es por get y no contiene parmetros por la url puede pasar al ltimo paso del ciclo de vida, si lo necesita pasar al siguiente.

Apply Request Values: Deja que los componentes actualicen los valores que le vienen por la request. Se llama al mtodo processDecodes de todos los componentes.

Process validations: Se procesan las validaciones llamando a processValidators.

Update Model Values: Ahora que estn los datos y son vlidos se llaman a los mtodos que modifican los valores del modelo. Esto se produce recursivamente en el mtodo processUpdates.

Invoke Application: La actualizacin del modelo ha sido completada, se llama al mtodo processApplication de UIViewRoot. Se llama a todos los eventos encolaos con phaseId.INVOKE_APPLICATION.

Render Response: Se renderiza la respuesta al cliente. Se invoca al mtodo encode de cada componente del rbol de renderizado.

Los listeners son clases que se instancia entre los diferentes ciclos de vida de JSF2. Se declaran de la siguiente forma:

org.archetypeUma.listener.selection.PruebaPhaseListener

El fichero de configuracin de myfaces es faces-config.xml, aunque se puede cambiar el nombre no es necesario.

En el se pueden incluir las configuraciones de:

Managed Beans o Backend Beans: es un bean como los de spring que ser instanciado desde un componente de JSF. Estas clases deben de tener las propiedades y mtodos que sean necesaria para cumplir las necesidades del componente desde el que este siendo llamado.

Bundles: Declara los ficheros de internacionalizacin de la aplicacin. Deben de estar en el classpath de la aplicacin y ser declarados con el mismo nombre aqu. El idioma lo coger directamente del idioma en el que este instalado el navegador.

Validadores propios: Son validadores del formulario. Se crear una clase para este fin y luego se aprovechara por toda la aplicacin. Conversores propios: Se puede disponer de conversores en algunos componentes para que muestren determinado texto de otra forma dependiendo de algn valor. Es muy utilizado en tema de horas, fechas y cosas por el estilo. Reglas de navegacin: Permite crear unas reglas de navegacin a partir de una determinada salida del Managed Bean. Es mejor verlo con un ejemplo:

Componentes propios:

El servlet de myfaces guarda toda la informacin relacionada con la peticin en un objeto llamadoFacesContest. Las principales caractersticas de este objeto son:

Encapsula los posibles mensajes.

Permite acceder al singleton de la aplicacin.

Encapsula al elemento raz de la aplicacin.

Contiene toda la informacin relativa al estado de la llamada y la renderizacin de la respuesta.

Solo debe de existir durante la llamada y hasta que se invoque a su mtodo release.

Encapsula ResponseWriter, salida de caracteres, y RespondeStream, salida binaria, como flujos de escritura para los renderizadores.

Permite acceder al entorno de informacin por medio del ExternalContext.

Si lo que se necesita es crear un componente propio. Hay 3 pasos mnimos que hay que seguir: Declara el componente: Lleva la lgica del componente. Debe de heredar de la clase UIComponentBase. Hay que asignarle el renderer y el tag. Los mtodos ms importantes son:

setRenderType: en el constructor para asignar el render.

getFamily: devuelve el tipo del componte.

object getBean: devuelve el objeto para obtener los valores a pintar.

restoreState y saveState: mantienen los valores al recomponer el rbol de componentes.

processUpdates: Actualizacin del BackBean.

Declarar el tag: Extiende de UIComponentTag. Los mtodos ms importantes que hay que implementar son:

getComponentType: tipo de componente.

getRendererType: tipo de render que lo pinta.

Declarar el render: Recupera los parmetros de la request y se los pasa al componente. Existe la posibilidad de tener distintos RenderKits en funcin de la salida. Debe de heredar de la clase Renderer. Los mtodos ms importantes que debe de implementar al heredar de esta clase son: decode: extrae los parmetros de la request.

EncodeBegin, encodeEnd, encodeChildren: pintan las etiquetas inicial, final y anidadas, respectivamente.

3.2.2. Tomahawk

Tomahawk es una librera de componentes para JSF 2. Esta basado en Tomahwh 1.2 la galera de componentes para la versin 1.2 de JSF.Para utilizar cualquier componente de Tomahawk basta con declarar en la cabecera de la pgina que se va a utilizar Tomahawk y meter la etiqueta XML que se desee.

En la cabecera de la pgina:

xmlns:t=http://myfaces.apache.org/tomahawkUtilizacin de un componente de Tomahawk:

Este es un ejemplo de componente de Tomahawk que crea una tabla con los elementos que tenga la lista users declarada en el Action userListAction.

3.2.3. Primefaces

Primefaces es una galera de componentes JSF 2. Ha tenido una gran aceptacin en su primera versin cuando funcionaba bajo JSF 1.2. Ahora han sido los primeros en adaptar sus componentes a JSF 2.0. Lo que les da cierta ventaja en pruebas y optimizacin que el resto de libreras de uso similar.

Es desarrollado por una empresa Turca, denominada Prime Technology, que ofrece su software como cdigo abierto y software libre.

Primefaces esta compuesto de 3 mdulos [21]:

Figura X: Divisin de los 3 mdulos de Primefaces. [21] UiComponents: es el mdulo que contiene los componentes JSF.

Optimus: en este mdulo se aglutinan un conjunto de utilidades que optimizan el rendimiento del proyecto en JSF2.

FacesTrace: Aporta un sistema detallado para las trazas que se pueden requerir de JSF.

Primefaces tiene definido en la librera UIComponents muchos componentes, los cuales se pueden utilizar. Por ejemplo esta el componente:

org.primefaces.component.Menu

org.primefaces.component.menu.Menu

En la cabecera de cada pgina donde se quiera utilizar este componente hay que establecer que se va a utilizar esta librera de primefaces.

xmlns:p="http://primefaces.prime.com.tr/ui"

Ahora se puede utilizar el componente:

Pintara un men parecido a este en la pgina:

Figura X. Representacin del componente Men de Primefaces.

El uso es muy extenso lo mejor es que si se esta utilizando la arquitectura y se necesita algo, se abra la documentacin de Primefaces que se encuentra en los downloads de este proyecto y se obtenga la documentacin que se necesite, o bien en la documentacin de Primefaces.

3.3. Spring SecurityEn una aplicacin web es importante que el usuario confirme quien es (autentificacin) y que dependen de algunos permisos (autorizacin). Spring Security es un framework que aporta un mecanismo de gestin de la seguridad a determinados recursos a partir de los permisos del usuario. Esta basado en programacin orientado a aspectos. Se apoya en el framework spring para crear beans que gestionan la seguridad de la aplicacin.

La seguridad de la aplicacin es de obligado funcionamiento en toda aplicacin. Aunque en ocasiones no se implementa.

El proyecto fue creado en sus inicios por Ben Alex y permanece fuera del proyecto Spring como aadido. Antes era conocido por Acegi Security y fue con la segunda versin cuando paso a conocerse como Spring Security.

Spring comprueba todas las peticiones que se hacen sobre el servidor y comprueba que el usuario este autentificado.

Si no lo esta: Se crea un objeto Authentication en el SecurityContex, un contexto especial que crea spring security el cual se en sesin del usuario. Este objeto esta compuesto de los detalles del usuario y de un conjunto de permisos. Como an no se ha identificado el usuario se crea con las credenciales con un rol especial llamado annonymous.

Si esta identificado: Se comprueba que los recursos a los que esta intentando acceder no tengan permisos asociados y si los tiene se le exige al usuario que contenga el permiso.

Si el usuario tiene el permiso: Se le deja continuar con la actividad que estaba realizando.

Si el usuario no tienen el permiso: Se le expulsa a determinada localizacin donde se le expone que no tiene un determinado permiso.

Desglosando el objeto Authentication:

Principal: es el nombre del usuario. Credentials: es la contrasea del usuario o algn tipo de informacin que identifique el usuario, como el certificado digital. Authorities: Array con la lista de privilegios que tiene el usuario.Al hacer la importacin al proyecto de spring security se trae un gran nmero de libreras. Se van a definir aqu para que el lector conozca su funcionamiento:

Spring-core: Contiene el ncleo de la de autentificacin y acceso a control a clases e interfaces.

Spring-security-web: Contiene los filtro y la infraestructura para contener spring securtiy en un entorno web.

Spring-security-config: Contiene el espacio de nombres de spring security. Esto es necesario para spring security funcione.

Spring-ldap: Provee a spring security de autentificacin contra un LDAP.

Spring-lcd: Se utiliza si se quiere proveer a la aplicacin de seguridad en los dominios.

Spring-security-openid: da sopote para autentificacin OpenId.

Spring-security-cas-client: se utiliza si la autentificacin es contra un sistema cas.

Los antiguos beans FilterChainProxy y dems han sido sustituidos por etiquetas que los crean automticamente y que Spring Security conoce.

An as se ha mantenido la flexibilidad de Spring y se pueden insertar los conocidos como Provider. Cada Provider permite una funcionalidad diferente para Spring security.

Hay una serie de etiquetas xml que hay que conocer para saber utilizar Spring Security, se van a describir las ms frecuentes.

Con la etiqueta http auto-config se puede especificar que permisos necesita para entrar en cada url.

En el ejemplo se le obliga al usuario a tener el rol ROLE_USER para entrar en cualquier url de la aplicacin. Si no lo tiene ser enviado a la url que se designe para ser la pantalla de autentificacin.

Ntese que se puede jugar con las url as se podra poner por ejemplo

Slo los administradores podran entrar en la carpeta de security. Pero todos necesitan autentificarse y tener el rol de ROLE_USER.

Los usuarios se pueden buscar en varios sitios. Por ejemplo puede estar en el mismo XML definido con las etiquetas:

El usuario jcisneros tendra definido los privilegios ROLE_ADMIN y ROLE_USER mientras que el usuario ncisneros solo tendra acceso a las pginas marcadas con el privilegio ROL_USER.

Con la etiqueta password-encoder se declara la codificacin que tendr las claves almacenadas.

La aplicacin deber tener una pantalla de autentificacin si se quiere hacer que sea lo ms segura posible. Hay que tener en cuenta que un usuario que no tiene ningn rol y entra por primera vez a una aplicacin que tiene spring security como mdulo de seguridad. Tiene un privilegio de ANONYMOUSLY creado por cortesa de spring security. Por tanto, se puede jugar con ese privilegio si es necesario.

En este ejemplo un usuario que entrara sin estar autentificado tendra el privilegio ANONYMOUSLY y se le enviara a la pgina de login.jsp. Por qu se le deja entrar a esta pantalla? Porque esta vez si se declara que a los usuarios se les deje entrar a la pantalla de login si tiene el privilegio ANONYMOUSLY.

El usuario se logara y se le metera el privilegio ROLE_USER por lo que podra tener acceso a toda la aplicacin.

Con el atributo filter a none se puede hacer que no se auditen ciertos recursos, por ejemplo:

Todos los ficheros de estilos se quedan fuera del sistema de seguridad. Esto aporta gran velocidad a la aplicacin. Sino se estara llamando al filtro de spring security demasiadas veces para recursos que no van a aportar nada a la seguridad del sistema.

Si se quiere mantener a los usuarios en la base de datos hay que declarar una conexin con la base de datos con la etiqueta jdbc-user-service:

Faltara declarar el securityDataSource al que se hace referencia, como argumento se aade el bean que declara la base de datos:

Se puede declarar una pgina como expiracin de la sesin con la etiqueta:

Spring security provee anotaciones para declarar en los mtodos de la aplicacin, hay que insertar esta etiqueta en el fichero de configuracin de spring security para poder utilizarlas:

Si se quiere hacer que el mtodo salvar tenga roles de administrador es necesario:

@Secured ({"ROLE_ADMIN"})

public void save(User user);

Si no se quiere poner nada se mantendr el mtodo como annimo.

@Secured("IS_AUTHENTICATED_ANONYMOUSLY")

public List getUsers();

De esta forma se pueden declarar que todos los mtodos del tipo save necesiten el privilegio de ROLE_ADMIN:

Desde el cdigo JAVA se puede acceder al usuario que crea spring security con el cdigo:

Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();

El objeto principal contiene el nombre, el password y los privilegios del usuario logado.

Spring security recorre uno tras otro todos los filtros que tiene declarado en su configuracin.

Cabe destacar que cuando pasa por ExceptionTranslationFilter, si no existe el privilegio tiene que tomar decisiones. Si se quiere cambiar estas decisiones se debe de cambiar las pginas que controlan la aplicacin.

3.4. Herramientas de testLos patrones de calidad exigen varios niveles de pruebas para las aplicaciones webs. Una breve descripcin de cada una de ellas:

Pruebas unitarias: para cada mtodo hay que llevar a cabo una prueba en la que se confirme que el mtodo hace para lo que se haba creado.

Pruebas funcionales: La funcionalidad que debe de detener las diferentes partes de la aplicacin tienen que estar cubiertas.

Pruebas de rendimiento: las aplicaciones deben de dar un rendimiento ptimo, son conocidos como test de estrs, hay que probar diferentes partes de la aplicacin buscando los cuellos de botella para que el equipo de desarrollo pueda mejorarlos.

3.4.1. JUnit

Junit es un frameworks para automatizar las pruebas unitarias de aplicaciones Java. Es un software de cdigo abierto. Fue creado por Erich Gamma y Kent Beck.

Consta de un conjunto de clases que el programador puede utilizar para construir sus casos de prueba y ejecutarlos automticamente.

Los casos de prueba son realmente programas Java. Quedan archivados y pueden ser reejecutados tantas veces como sea necesario.

Es adecuado para el desarrollo dirigido por las pruebas. Test-driven develoment, tecnologa planteada hace poco aos que sostiene que no hay que programar y luego hacer un test que lo pruebe, sino que hay que hacer un test que tenga las entradas y las salidas que se deseen y luego implementar el cdigo que se necesite para solucionarlo.Los test de Junit se ejecutan como una clase Java normal, aunque tienen una clase de inyecciones y anotaciones que lo hacen un poco especial. Por lo tanto la mejor manera de ejecutar estos test es por medio de otra aplicacin que sea capaz de interpretarlos de la mejor manera. La forma ms utilizada es por maven, ant o por algn IDE que ya tenga bien integradas las pruebas unitarias dentro de sus caractersticas.

Junit proporciona una Api para la ejecucin de los test. Tiene una serie de clases y objetos que facilitan el testeo.

Todos los test en Junit tienen que llevar la anotacin:

@RunWith(SpringJUnit4ClassRunner.class)

Esta anotacin expresa que vamos a realizar un test en Junit utilizando Spring.

La siguiente anotacin:

@ContextConfiguration(locations = {

"classpath:/spring/applicationContext-resources.xml",

"classpath:/spring/applicationContext-dao.xml",

"classpath:/spring/applicationContext-service.xml" })

Se usa para especificar el contexto de Spring que es necesario para que el test se ejecute correctamente.

Cada mtodo que sirva de test de otro mtodo de la aplicacin hay que catalogarlos con la anotacin

@Test

3.4.2. JMock

JMock es una API para las pruebas unitarias de sistema en Java. Utiliza Junit para algunas operaciones.

JMock permite la creacin de test unitarios exhibiendo determinados componentes y sustituyndolos por sus 'Mocks'. Mocks es una expresin que representa una burla. Esa es la principal ventaja de los Mocks, no hace falta probar que hace un objeto que tiene el programa si se esta seguro que el programa funciona. Lo mejor es crear un objeto Mockery que sustituya a toda esa funcionalidad y que hagamos el test dependiendo de lo que devuelvan.

Los test de JMock se apoyan en Junit4 por lo que hay que declarar en la cabecera la anotacin:

@RunWith(JMock.class)

Cada test tiene que ir acompaado de la anotacin:@testAl programar una prueba en Jmock hay que tener en cuenta varios factores que son muy importantes:

El nmero de invocaciones a un Mock.

MtodoDescripcin

oneOfLa invocacin ha este mtodo se ha producido una sola vez.

exactly(n).ofLa invocacin es esperada n veces.

atLeast(n).ofLa invocacin es esperada hasta n veces.

atMost(n).ofLa invocacin es esperada al menos n veces.

between(min, max).ofLa invocacin se espera entre un intervalo.

allowingLa invocacin es permitida algn nmero de veces pero no tiene porque suceder.

ignoringSimilar a la de permitir.

neverLa invocacin a este mock no se debera de producir.

Tabla X. Nmero de invocaciones a los Mock.

Comprobacin de argumentos. Se comprueba que los argumentos que entran a un mtodo son los esperados:

MtodoDescripcin

equal(n)Los argumentos son iguales que n.

same(o)Los argumentos son un objeto como o.

any(Class type)El argumento es alguna instancia del tipo que se establezca en type.

a(Class type)El argumento es una instancia del tipo o de una subclase.

an(Class type)El argumento es una instancia del tipo o de una subclase.

aNull(Class type)El argumento es null.

aNonNull(Class type)El argumento no es null.

not(m)Los argumentos no son m.

anyOf(m1, m2, ..., mn)Los argumentos se encuentrar entre m1 y mn.

allOf(m1, m2, ..., mn)Los argumentos son los que se encuentra entre m1 y mn.

Tabla X. Argumentos a los objetos Mock.

Acciones. Se puede especificar que devuelve cada Mock, los mtodos que lo consiguen son:

MtodoDescripcin

will(returnValue(v))Devuelve el objeto c al ser llamado.

will(returnIterator(c))Devuelve un nuevo Iterador sobre la coleccin c para cada invocacin.

will(returnIterator(v1, v2, ..., vn))Devuelve un nuevo iterador para cada elemento invocacin, desde v1 hasta vn.

will(throwException(e))Devuelve una excepcin.

will(doAll(a1, a2, ..., an))Hace muchas acciones sobre una invocacin.

Tabla X. Mtodos que representan las devoluciones de objetos Mock.

3.4.3. JMeter

Jmeter es una aplicacin standalone que prueba las aplicaciones webs por medio de peticiones HTTP. Esta escrito en Java y es cdigo abierto. Originalmente desarrollado por Stefano Mazzocchi.

Jmeter puede ser utilizado para las pruebas de rendimiento o para las pruebas funcionales o para las pruebas de integracin.

Jmeter soporta HTTP, JDBC, SOAP, XML-RPC, FTP, SMTP, LDAP, JUnit y ms.

La forma de guardar y cargar los ficheros de pruebas es por medio de XML. Esto es una gran ventaja ya que es un formato muy utilizado en el sector de la informtica y puede ser manipulado con facilidad.

Jmeter tiene un sistema de documentacin capaz de mostrar grficas para los rendimientos de la cpu, de la memoria, del recolector de basura de Java, del los hilos utilizado y del uso de las conexiones. Trabajando con esta herramienta es fcil encontrar cuellos de botella.La estructura de carpetas del proyecto Jmeter una vez instalado en el equipo quedara de la siguiente manera:

bin contiene los .bat y .sh ficheros para arrancar Jmeter. Tambin contiene ApacheJMeter.jar y otras ficheros de propiedades. docs este directorio contiene la documentacin de JMeter. extras ficheros extras del constructor ANT lib contiene las libreras que necesita JMeter. src contiene subdirectorios por cada protocolo y componente. test directorio de test. xdocs XML para la documentacin.Hay unos conceptos que hay que tener en cuenta para trabajar con Jmeter:

Thread: Un hilo representa un usuario. Cuando se ejecuta un hilo es como si un usuario entrar en la aplicacin e hiciera una determinada prueba. Thread Group: Un grupo de hilos es un escenario de trabajo que se va a crear para unos usuarios. Es decir si un usuario entra, se registra, ejecuta una bsqueda y se sale. Se crear un grupo de trabajo para ese escenario. Test plan: es uno o varios grupos de hilos. Sampler: Un sampler es algo que enva peticiones al servidor, Listener: Un listener escucha las respuestas generada por los samplers. Los listeners son utilizados para ejecutar los resultados de las peticiones al servidor. Assertion: Un assertion es utilizado para especificar que una respuesta debera de tener un determinado contenido. Hay varios tipos de assertions dependiendo de lo que se necesita y de lo que se quiera comprobar. Se puede comprobar por ejemplo que la peticin tiene como cabecera. ttulo. Logic Controller: aporta un mecanismo para controlar el flujo de Thread Group. Aade sentencias del tipo if-then or do- para hacer un programa lgico. Workbench: El Workbench es el rea de trabajo. Es el lugar donde JMeter ejecuta los test y crea los reporting. Timers: Introduce tiempos cronometrados en los test.Para empezar a trabajar con JMeter hay que grabar el circuito que hace la prueba:

Se crea un fichero nuevo de JMeter. Inicialmente se crean dos apartados, un Plan de pruebas y un Banco de Trabajo.En el Plan de pruebas se crea un Grupo de Hilos.

Figura X. Insercin en JMeter de un Grupo de Hilos.

Se aade un Ver rbol de Resultados y Ver Resultados en rbol en el Banco de Trabajo:

Figura X. Insercin en JMeter de un Ver Resultados en rbol.

Segundo probamos el circuito desde Jmeter. Hay que darle al botn Lanzar y ejecutar el test.

Tercero integramos un plugin de JMeter en Maven para que cuando ejecute la fase del ciclo de vida de test se ejecuten los test de JMeter. Pero este plugin an esta en fase de desarrollo, se ha probado en este proyecto y no ha funcionado correctamente. Ser suficiente con probar el test en JMeter aunque no este presente en el ciclo de vida de Maven.

3.5. Spring FrameworkSpring es un framework de software libre para el desarrollo de aplicaciones. Nace en el J2EE Design & Development de Rod Johnson. Su primera versin es del 2003 escrita por el mismo Rod Johnson con licencia Apache 2.0. El framework se ha popularizado por sus fciles soluciones a problemas complejos como la transaccionalidad, los aspectos y la inversin de control.

Una de las traducciones de Spring es engranage y esa es la principal utilidad de Spring intenta unir los diferentes frameworks que se utilizan en una aplicacin.

En las ltimas versiones Spring se ha aprovechado de las anotaciones para quitarse de encima tanta configuracin en XML como tena acostumbrado. Sobre todo con la llegada de la versin 3 a finales del 2009.

Spring ha sido muy apoyado por la comunidad de programadores de software libre por lo que ha sido ampliado a gran velocidad abarcando una gran cantidad de reas. Hay que destacar en este proyecto Spring Security ya que se va a utilizar como capa de seguridad en la arquitectura.

Spring facilita el Test Driven Development y los EJB.

Con la librera spring-test se puede utilizar las funcionalidades de las libreras JUnit y JMock. Esto se explica ms en profundidad en sus apartados.

Spring brinda soporte a las siguientes tecnologas de persistencia de objetos:

DAO

JDBC

ORM

Hbenate

JDO

Oracle TolLink

iBatis SQL Maps

JPA

Spring es un conjunto de libreras que se pueden dividir en 6 mdulos [51]:

Spring Core: Es la parte fundamental del framework. Proporciona funcionalidades de inyeccin de dependencias y de gestin como contenedor de beans, as como un patrn de acceso a beans estilo factora. El contenedor gestiona las instancias de los beans configurados en el framework. Spring Context: Suministra la manera de acceder a los beans, es decir, las diversas formas para cargar el contexto de la aplicacin, principalmente a travs del contenedor de