Arquitectura J2EE para el desarrollo ágil de aplicaciones webs

tamerunΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 10 μήνες)

3.537 εμφανίσεις


1




UNIVERSIDAD DE MÁLAGA




ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA




INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN




Arquitectura J2EE para el desarrollo ágil de aplicaciones webs



Realizado por

Javier Cisneros González



Dirigido por

Francisc
o Rus Mansilla

Francisco
Rom
á
n
Villatoro Machuca



Departamento

Lenguaje y Ciencias de la Comput
ación




UNIVERSIDAD DE MÁLAGA



MÁLAGA, Diciembre 2010


2




































3

UNIVERSIDAD DE MÁLAGA

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTI
CA


INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN


Reunido el tribunal examinador en el día 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º.

Javi
er Cisneros González


tutorizado

por Dº
.
Francisco Rus Mansilla y

Francisco Román Villatoro Machuca
,


y, en su caso, dirigido académicamente por


Dº/Dª.___________________________________________________________________________


________________________
________________________________________________________


ACORDÓ POR ______________________________________ OTORGAR LA CALIFICACIÓN

DE _____________________________________________________________________________

Y PARA QUE CONSTE, SE EXTIENDE FIRMADA POR
LOS COMPARECIENTES

D E L T R I B U N A L, L A P R E S E N T E D I L I G E N C I A.


Málaga a ____ de______________ del 2011










4


Agradecimientos




















































5

Índice




1.

Introducción

1.1.

Descripción del proyecto

1.2.

Antecedentes

1.3.

Objetivos

1.4.

Fases de tra
bajo

1.5.

Estructura de la memoria

1.6.

Requisitos


2.

Arquitectura en JAVA con Maven

2.1.

JAVA

2.1.1.

Framework

2.1.2.

POJO

2.1.3.

Bean

2.2.

Patrón de diseño

2.2.1.

Patrón MVC

2.2.2.

Patrones de diseño J2EE

2.2.3.

Patrón de inversión de contr
ol

2.2.4.

Patrón de inyección 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.

Definición de la arquitectura

4.1.

Capa Model

4.2.

Ca
pa 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.

Creación del arquetipo

5.1.

Infraestructura de desarrollo

5.1.1.

Google Code

5.2.

Definiendo el proyecto

Página


7

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


6

5.3.

Instalación de los frameworks y herramientas en la arquitectura

5.3.1.

JAVA

5.3.2.

Maven

5.3.3.

Framework
s 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.

Generación del arquetipo


6.

Trabajando con la arquitectura

6.1.

Preparación y descarga

6.2.

Utilización de la arquitectura

6.2.1.

Model

6.2.2.

Core

6.2.3.

Web


7.

Herramientas para el
uso de la arquitectura

7.1.

IDE

7.1.1.

Eclipse

7.1.2.

Netbeans

7.1.3.

Intellij IDEA

7.2.

Base de datos

7.2.1.

MySQL

7.2.2.

Postgresql

7.3.

Servidores de aplicaciones

7.3.1.

Apache Tomcat

7.3.2.

JBoss AS

7.3.3.

Jetty

7.4.

SVN

7.5.

Instalación 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.

Servi
dor de aplicaciones

7.5.3.1.

Apache Tomcat

7.5.3.2.

Jboss

7.5.3.3.

Jetty

7.5.4.

SVN


8.

Conclusiones


9.

Bibliografía y enlaces

9.1.

Índice de figuras

9.2.

Índice de tablas

80

84

85

85

85

86

87

88

89

92

94

95

96


97

97

98

99

102

108


117

117

117

118

120


121

122

122

123

123

124

126

127

128

128

128

128

129

129

129

130

130

130

131

131

132


134


135

136

136



7


1.

Introducción


JAVA es el lenguaje de programación más utili
zado y más 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.

Posteriormen
te fue


estandarizando en los llamados frameworks. Los frameworks revolucionaron
las aplicaciones web consiguiendo que el trabajo fuera más ágil. Contienen una gran cantidad de
funcionalidad y están mantenidos por una comunidad que intenta optimizar el cód
igo en la medida
de lo posible.

Uno de estos frameworks que deben de ser el referente en los próximos años es Java Server Faces 2,
Después del éxito cosechado por la primera versión y gracias a los esfuerzos de la comunidad
Apache, JSF debe de ser el fram
ework que más 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

ginas webs. Se integra con herramientas muy potentes como Spring y tecnologías como AJAX.

Otro framework que tenemos que hacer mención especial es Hibernate. Un ORM (Object Relational
Modeling) que simplifica la gestión con la base de datos haciéndola tan
sencilla que hace
n 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 más complejo. Sus proyectos son más difíciles de mantener y hace falta cada vez un
p
ersonal más cualificado para gestionar los proyectos.

Los proyectos conllevan un coste muy grande a la hora de iniciarse y de documentarse. Aún más
cuando hay incidenci
as en las APIs que se están utilizando y hay que actualizarlas.

Los clientes exigen las últimas tecnologías y los equipos de desarrollo tienen que esforzarse para
renovarse una y otra vez

Maven

vino a cubrir estos problemas que provenían del ciclo de vida
de un proyecto. La
construcción, la reutilización, la documentación, la variedad de entornos en los que se puede
desplegar.



1.1.

Descripción del proyecto


Este proyecto trata de crear una arquitectura que simplifique el trabajo en Java. Creando una
estructu
ra que aporte el mayor número de soluciones en el menor código posible.

Multitud

de proyectos los iniciados y creados a partir de cero, cuando se podía haber tenido una
base con la que haber aligerado meses y meses de trabajo.

En esencia se trata de dar e
l esqueleto de un código en JAVA que instale y configure el proyecto
con todos los frameworks y tecnologías

necesarias
. Se utiliza Maven para la instalación 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 empeza
r a trabajar.

Destaca también la aportación de Matt Raible por sus arquetipos creados en
Maven

y sus
arquitecturas para Ant creadas desde el año 2005 al 2009.


8



1.3.

Objetivos


El
principal objetivo es crear un arquetipo de
Maven
3 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
reúna

las tecnologías más vanguardistas. Buscando la sencillez, la
abstracción y
reduciendo

al
mínimo

el coste de inicio de un proyecto.

Hay que integrar todos los framaworks que
s
e necesiten para
crear una arquitectura del tipo MVC
(Modelo Vista Controlador)

y después
crea
r

un ejemplo de cada uno de ellos.

El arquetipo deberá de poder ser utilizado desde

un repositorio público de
Maven

y poder ser
descargado como un proyecto java para aquellos programadores que no tengan posibilidad

de
conectase a un servidor de
Maven
.

I
mplementar un sistema de testeo que le aporte a los futuros proyectos que utilicen est
a arquitectura
cierta calidad en el código. Se
deberá

de ofrecer un testeo para pruebas unitarias, pruebas de
integración y para pruebas de stress. Junit, Jmock y Jmeter son en principio las herramientas que
más potencial tienen para entrar en la arquitect
ura.

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 mantenim
iento para cubrir las posibles incidencias
que tengan nuestros usuarios.


1.4.

Fases de trabajo


Las fa
ses del proyecto se dividen en 6 partes
:




Análisis de requisitos y captación de documentación.



Documentar funciona
lmente cada parte del

proyecto.



Crear un a
rquetipo en
Maven

que solucione las carencias que ahora tenemos.



Desarrollar un ejemplo de cada tecnología para que los usuarios asimilen lo antes posible la
tecnología.



Transformar el proyecto en un arquetipo para
Maven
.



Documentación de la memoria.


1.5.

Est
ructura de la memoria


Inicialmente 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

concept
os, framework y componentes que

deber
ía 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 cómo instalarla y utilizarla.


Hay que señalar que la memoria
no sirve d
e guía de ninguna herramienta que
aquí

se explica. Hay
muchos manuales tanto impreso como por
Internet

que se puede consultar si se quiere profundizar
más en el tema. En el apartado de enlaces de esta memoria se puede
consultar los más importantes y
invest
igar a partir de ellos.


1.6.

Requisitos



9

Requisitos software
para el desarrollo del proyecto:



Windows XP y Linux en la distribución de
K
ubuntu.



JDK 1.6 de JAVA



Tortoise o plugin de eclipse 'subclipse' para la comunicación con el repositorio.



IDE Eclipse.

O N
etbeans



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






















10




























11

2.

Arquitectura

en JAVA
con Maven

La 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
J
AVA

y cual es la forma óptima de utilizarlo.


2.1.

Ja
va

Java es un lenguaje de programación orientado a objetos, basado en la sintaxis que definió el
lenguaje C. Actualmente Java es el máximo exponente de los lenguajes orientados a objetos, no por
su rendimiento frente a otros lenguajes sino por su movimient
o hacia el sector de Internet.

Fue creado por la empresa Sun Microsystems. En principio la principal motivación de la empresa
fue unificar en un lenguaje la multitud de arquitecturas incompatibles que estaban surgiendo.
Después el lenguaje tomo Internet co
mo campo de batalla para crecer y hacerse fuerte.

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

Las principales ventaj
as de java son:



Robusto



Dinámico



Multiflujo



Alto rendimiento



Interpretado



Portable



Seguro



Distribuido



Orientado a objetos



Dinámico



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 convirtiéndolos en ficheros *.class.

Hasta aquí todo es igual que el resto de los lenguajes de programación. Ahora es cuando entra en
juego la Máquina Virtual de Java.

El fichero *.class llega a la máqu
ina 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
dejándose esto en manos de la máquina virtual.

Los principales navegadores de Internet y a
lgunos sistemas operativos ya vienen con la máquina
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.es

Si JAVA esta instalado hay muchas formas de utilizarlo. Las más 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 líneas de comando o desde IDE especializ
ados (más adelante

12

se habla de los IDE y de su utilidad en la arquitectura).

Lanzándolo desde la línea de comando con la aplicación javac.


javac @options @classes

Hay una serie de conceptos de JAVA que hay que conocer a la hora
de trabajar con la arquitec
tura,
en especial los Beans, los POJOS y los Frameworks.

2.1.1.

Frameworks

La palabra inglesa "framework" define, en términos generales, un conjunto estandarizado de
conceptos, prácticas y criterios para enfocar un tipo de problemática 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 tecnológica de soporte
definida, normalmente con artefactos o módulos de software concretos, con base en la
cual otro
proyecto de software puede ser organizado y desarrollado. Típicamente, 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.

[4
0]



2.1.2.

POJO

Un POJO (acrónimo 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 framewor
k en especial. Este acrónimo surge como
una r
eacción en el mundo Java a los F
rameworks cada vez más complejos, y que requieren un
complicado andamiaje que esconde el problema que realmente se está modelando. En particular
surge en oposición al modelo plant
eado por los estándares EJB anteriores al 3.0, en los que los
"Enterprise JavaBeans" debían implementar interfaces especiales.

[4
1
]



2.1.3.

Beans

Un JavaBean

o Bean

es un objeto que sigue una serie de reglas que posibilitan su creación, manejo
y gestión en ento
rnos principalmente visuales. Estas reglas son:



Debe tener un constructor sin argumentos.



Sus propiedades se hacen accesibles mediante métodos get y set que siguen una
nomenclatura establecida: getPropieda
d() y setPropiedad(Tipo prop).



Debe ser
implementa
r la interfaz S
erializable.


2.2.

Patrón de diseño

Es importante conocerlos para entender porque se utiliza determinada estructura o determinado
framework en la arquitectura.

Se exponen la definición de los patr
ones

y luego los patrones que más
se utilizan en
JAVA, sobre todo para la versión J2EE, versión especializada en aplicaciones webs.


13

El concepto de "patrón de diseño" que tenemos en Ingeniería del Software se ha tomado prestado de
la arquitectura. En 1977 se publica el libro "A Pattern Language: Towns/Bui
lding/Construction", de
Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl
-
King y
Shlomo Angel, Oxford University Press. Contiene numerosos patrones con una notación específica
de Alexander.

Alexander comenta que “Cada
patrón describe un problema que ocurre una y otra vez en nuestro
entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa
solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos veces de la misma
fo
rma”. El patrón es un esquema de solución que se aplica a un tipo de problema, esta aplicación
del patrón no es mecánica, sino que requiere de adaptación y matices. Por ello, dice Alexander que
los numerosos usos de un patrón no se repiten dos veces de la
misma forma.

La idea de patrones de diseño estaba "en el aire", la prueba es que numerosos diseñadores se
dirigieron a aplicar las ideas de Alexander a su contexto. El catálogo más famoso de patrones se
encuentra en “Design Patterns: Elements of Reusable O
bject
-
Oriented Software”, de Erich Gamma,
Richard Helm, Ralph Johnson y John Vlissides, 1995, Addison
-
Wesley, también conocido como el
libro GOF (Gang
-
Of
-
Four).

[3
7
]


Siguiendo el libro de GOF los patrones se clasifican según el
propósito

para el que han s
ido
definidos

[37]
:




Patrones creacionales:

solucionan problemas de creación de instancias. Ayudan a encapsular
y abstraer dicha creación.

o

Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas
familias de manera que las familias n
o se mezclen entre sí y haciendo transparente el
tipo de familia concreta que se esté usando.

o

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

o

Factory Method (Método de fabr
icación): Centraliza en una clase constructora la
creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la
casuística para elegir el subtipo que crear.

o

Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya
exis
tente.

o

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




Patrones estructurales:

solucionan problemas de composición (agregación) de clases y
objetos
.

o

Adapter(Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase
que de otro modo no podría utilizarla.

o

Bridge(Puente): Desacopla una abstracción de su implementación.

o

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

o

Decorator(Envoltorio): Añade funcionalidad a una clase dinámicamente.

o

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

o

Flyweight(Peso ligero): Reduce
la redundancia cuando gran cantidad de objetos
poseen idéntica información.

o

Proxy: Mantiene un representante de un objeto




Patrones de comportamiento
:
soluciones respecto a la interacción y responsabilidades entre
clases y objetos, así como los algoritmos
que encapsulan.


14

o

Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que
deben llevar los mensajes para que los objetos realicen la tarea indicada.

o

Command(Orden): Encapsula una operación en un objeto, permitiendo ejecutar
dicha

operación sin necesidad de conocer el contenido de la misma.

o

Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje,
así como las herramientas necesarias para interpretarlo.

o

Iterator(Iterador): Permite realizar recorridos sob
re objetos compuestos
independientemente de la implementación de estos.

o

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

o

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

o

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

o

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

o

Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema
y elegir cuál utilizar en tiempo de ejecución.

o

Template Method (Método plantilla): Define en una

operación 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.

o

Visitor(Visitante): Permite definir nuevas operaciones sobre una jer
arquía de clases
sin modificar las clases sobre las que opera.


2.2.1.

Patr
ó
n MVC

Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de
una aplicación, la interfaz de usuario, y la lógica de control en tres componentes d
istintos.

F
ue descrito por primera vez en 1979 por Trygve Reenskaug, trabajador de Smalltalk, en unos
laboratorios de investigación de Xerox.

El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el
código que provee d
e datos dinámicos a la página, el modelo es el Sistema de Gestión de Base de
Datos y la Lógica 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

[3
9
]
:




El mod
elo es el responsable de:

o

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

o

Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla
puede ser: "Si la mercancí
a pedida no está en el almacén, consultar el tiempo de
entrega estándar del proveedor".

o

Lleva un registro de las vistas y controladores del sistema.

o

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 inserción, etc).




El controlador es responsable de:


15

o

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

o

Contiene reglas
de gestión de eventos, del tipo "SI Evento Z, entonces Acción W".
Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas
peticiones a las vistas puede ser una llamada al método "
Actualizar (
)". Una petición
al modelo puede ser "Obt
ener
_tiempo(nueva_orden
)".




Las vistas son responsables de:

o

Recibir datos del modelo y
mostrarlos

al usuario.

o

Tienen un registro de su controlador asociado (normalmente porque además lo
instancia).

o

Pueden dar el servicio de "
Actualización (
)", 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 patrón
MVC

mediante un
diagrama de secue
ncias:



Figura

X. Diagrama de secuencia del patrón MVC.

[3
9
]


Describiendo los pasos en el MVC
:




El usuario introduce el evento.



El
c
ontrolador recibe el evento y lo traduce en una petición al Modelo (aunque también puede
llamar directamente a la vista).



El modelo (si es necesario) llama a la vista para su actualización.



Para cumplir con la actualización la Vista puede solicitar datos al Modelo.



El Controlador recibe el control.


2.2.2.
Patrones J2EE

Con la aparición del J2EE, todo un nuevo catálogo de patrones
de diseño apareció. Desde que J2EE
es una arquitectura por si misma que involucra otras arquitecturas, incluyendo servlets, JavaServer
Pages, Enterprise JavaBeans, y más, merece su propio conjunto de patrones específicos para
diferentes aplicaciones empres
ariales.

[
42
]

De acuerdo al libro "J2EE PATTERNS Best Practices and Design Strategies", existen 5 capas en la
arquitectura J2EE:


16



Cliente



Presentación



Negocios



Integración



Recurso

El libro explica 15 patrones J2EE que están divididos en 3 de las capas: pres
entación, negocios e
integración.

Patrones de la capa de p
resentación
:

Decorating Filter /
Intercepting Filter

Un objeto que está entre el cliente y los componentes Web. Este procesa las
peticiones y las respuestas.

Front Controller/
Front Component

Un ob
jeto que acepta todos los requerimientos de un cliente y los direcciona
a manejadores apropiados. El patrón Front Controller podría dividir la
funcionalidad en 2 diferentes objetos: el Front Controller y el Dispatcher. En
ese caso, El Front Controller acep
ta todos los requerimientos de un cliente y
realiza la autenticación, y el Dispatcher direcciona los requerimientos a
manejadores apropiada.

View Helper

Un objeto helper que encapsula la lógica de acceso a datos en beneficio de
los componentes de la prese
ntación. Por ejemplo, los JavaBeans pueden ser
usados como patrón View Helper para las páginas JSP.

Composite view

Un objeto vista que está compuesto de otros objetos vista. Por ejemplo, una
página JSP que incluye otras páginas JSP y HTML usando la direct
iva
include o el action include es un patrón Composite View.

Service To Worker

Es como el patrón de diseño MVC con el Controlador actuando como Front
Controller pero con una cosa importante: aquí el Dispatcher (el cual es parte
del Front Controller) usa V
iew Helpers a gran escala y ayuda en el manejo
de la vista.

Dispatcher View

Es como el patrón de diseño 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 presentación
.


Patrones de la capa de negocios:


Business Delegate

Un objeto que r
eside en la capa de presentación y en beneficio de los otros
componentes de la capa de presentación llama a métodos remotos en los
objetos de la capa de negocios.

Value Object/ Data
Transfer Object/
Replicate Object

Un objeto serializable para la transfer
encia de datos sobre lar red.

Session Façade/
Session Entity
Façade/ Distributed
El uso de un bean de
sesión

como una fachada (facade) para encapsular la
complejidad de las interacciones entre los objetos de negocio y participantes
en un flujo de t
rabajo. El Session Façade maneja los objetos de negocio y

17

Façade

proporciona un servicio de acceso uniforme a los clientes.

Aggregate Entity

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

Value Object
Assembler

Un objeto que reside en

la capa de negocios y crea Value Objets cuando es
requerido.

Value List Handler/
Page
-
by
-
Page
Iterator/ Paged List

Es un objeto que maneja la ejecución de consultas SQL, caché y
procesamiento del resultado. Usualmente implementado como beans de
sesión.

Service Locator

Consiste en utilizar un objeto Service Locutor para abstraer toda la utilización
JNDI y para ocultar las complejidades de la creación del contexto inicial, de
búsqueda de objetos home EJB y recreación de objetos EJB. Varios clientes
pueden
reutilizar el objeto Service Locutor para reducir la complejidad del
código, proporcionando un punto de control.


Tabla X. Patrones de la capa de negocios.


Patrones de la capa de i
ntegración
:

Data Access
Object Service
Activator

Consiste en utilizar un
objeto de acceso a datos 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.

Service Activator

Se utiliza para recibir peticiones y mensajes asíncronos de los
clientes. Cuando
se recibe un mensaje, el Service Activator localiza e invoca a los métodos de los
componentes de negocio necesarios para cumplir la petición de forma asíncrona.


Tabla X. Patrones de la capa de integración.


2.2.3.

Patrón de inversión de contro
l

Inversión de control (Inversion of Control en inglés, IoC) es un método de programación en el que
el flujo de ejecución de un programa se invierte respecto a los métodos de programación
tradicionales, en los que la interacción se expresa de forma imperat
iva 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 inversión de control se especifican respuestas
deseadas a sucesos o solicitudes de datos concretas, dejando que algún tipo de entidad o
arquitectura externa lleve a cabo las acciones de control que se requieran en el orden necesario y
para el conju
nto de sucesos que tengan que ocurrir.

El flujo habitual se da cuando es el código del usuario quien invoca a un procedimiento de una
biblioteca. La inversión de control sucede cuando es la biblioteca la que invoca el código del
usuario.

La utilización de
interfaces y la aparición de los frameworks han popularizado este término. 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 lo
s objetos del

18

usuario. Por tanto las aplicaciones que utilicen el framework de Spring (no Spring propiamente
dicho) utilizarán Inversión de Control.

[44]




2.2.4.

Patrón de inyección de dependencias

En Informática, Inyección de Dependencias (en inglés Dependenc
y Injection, DI) es un patrón de
diseño orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia
clase quien cree el objeto. El término fue acuñado por primera vez por Martin Fowler.

Típicamente este contenedor es impleme
ntado por un framework externo a la aplicación (como
Spring o uno propietario), por lo cual en la aplicación también se utilizará Inversión de Control al
ser el contenedor (almacenado en una biblioteca) quien invoque el código de la aplicación. Ésta es
la
razón por la que los términos de Inversión de Control e Inyección de Dependencias se confunden
habitualmente entre sí.

[45]



2.3.

Maven


El arquetipo va a ser un proyecto en JAVA pero es un tipo de proyecto especial ya que sigue una
determinado estructura y c
aracterísticas que exige
Maven
. Se va a describir para que sirve y como
utilizar
Maven
.


Maven

es una herramienta para la gestión del ciclo de vida de las aplicaciones. Funciona como una
aplicación en Java y es un Opensource de la fundación Apache. Bajo un
a 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 descargárselo de algún repositorio, construirlo, definir las dependencias, integrar el
proyecto con los IDE's, com
pilación, empaquetado, pruebas unitarias, pruebas de estrés y
funcionalidad, calidad y documentación del código.

Maven

tiene su opositor en Ant también de Apache. Ant tiene menos funcionalidad que
Maven

es
ya que solo es un constructor de proyectos, una f
uncionalidad de las muchas que tiene
Maven
. Es
fácil pensar que
Maven

es un complemento de Ant, al tener más funcionalidad y por poder
invocarse desde
Maven
.

Las ventajas de
Maven

en la producción de proyectos software:




Hacer el proceso de construcción fá
cil.



Proveer un proceso de construcción uniforme.



Proveer una cantidad de información sobre el proyecto.



Servir como guía de buenas practicas de desarrollo de software.



Permitir una migración 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 automáticas. Tanto dependencias
primarias como transitivas.


19



Permite trabajar de una forma fácil con múltiples proyectos
al mismo tiempo.



Grande y creciente repositorio de librerías y metadatos externo a nuestro proyecto.
Liberando así el sistema de control de versiones de contener jar´s.



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



Acceso instantáneo a nueva funcionalidades con una mínima o ninguna configuración.



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



Maven

esta preparado para un gran número 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 documentación que se quiera. Ade
más de toda la información que
Maven

añade
como api, java doc, información sobre desarrolladores, informes de te
st, etc.



Manejo de release y publicación 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 incluyen
do dependencias y
documentación, o una distribución de fuentes.



Manager de dependencias:
Maven

impulsa el uso de un repositorio central de JAR´s y otras.


Los inconvenientes de
Maven

en la gestión de proyectos software:



Su curva de aprendizaje es muy pronu
nciada. Los informáticos que desarrollen el proyecto
deben de estar muy preparados en conocimientos de Java.


A continuación se van a describir unos conceptos importantes de
Maven
:




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



Artefacto: Es para
Maven

la unidad mínima con la que trabaja a la hora de gestionar sus
dependencias.



Coordenadas: S
istema con el
Maven

determina de forma única a cada uno de sus artefactos.



Goal: Son las unidades de mínimas de ejecución. Las tareas más simples.



Ciclo de vida: S
ecuencia de etapas que propone
Maven

para la gestión 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 construcción previa.



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



validate: valida
que el proyecto es correcto y tiene toda la información necesaria.



inicializate: Inicializa la construcción, modificando propiedades o creando directorios.



generate
-
sources: Genera algún código fuente para utilizarlo en la compilación.



process
-
sources: Pro
cesa el código 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 código fuente.



process
-
classes: Ejecuta unas tareas después

del la generación de los códigos compilados,
por ejemplo por si hubiera que cambiar el bytecode de las clases.



generate
-
test
-
sources: Genera algunos códigos fuentes de los test para la inclusión en la
compilación.



process
-
test
-
sources: Procesa el código f
uente de los test, por ejemplo filtrar algunas
variables.


20



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 código fuente de los

test dentro del directorio destino de los test.



process
-
test
-
classes: Hace un postprocesado de la generación de ficheros de la compilación
de los test. Por ejemplo se cambia el bytecode.



test: compila el código y ejecuta los unit test correspondientes. Si
n embargo no es requisito
para que el proyecto sea desplegado.



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



package: toma el código 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
integración.



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



post
-
integration
-
test: prepara algunas operaciones desp
ués que se ejecuten los test de
integración. Esto puede incluir la limpieza del entorno.



verify: ejecuta cualquier verificación para cumplir los parámetros de calidad.



install: instala el jar o war en el repositorio local para que otras aplicaciones locale
s 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 generación del site.



site: genera la documentación del site proyecto



post
-
sit
e: ejecuta los procesos necesarios al finalizar la documentación del site y prepara
para el despliegue.



site
-
deploy: despliega la generación del site al servidor especificado.



21



Figura X. Ciclo de vida de
Maven

3.

[46]


Estructura de directorios
: Propues
ta 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 estándar de un proyecto en
Maven

es:


Directorio


Descripción

/aplicacion/pom.xml


Fichero de configuración de
Maven

/aplicacion/src/


Código fuente

/aplicacion/src/main/java/


Código fuente de java

/a
plicacion/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 demás
contenidos de una aplicación 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 proyec
tos war tienen el contenido de la creación del war


Tabla X. Estructura de carpetas de un proyecto
Maven
.



22

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 parámetros los cuales son:




archetypeGroupId:
Identificador del grupo del archetipo.




groupId, es usado co
mo identificador del conjunto de librerías en este caso hemos usado
org.archetypeUma como nombre para nuestro paquete de librerías.




artifactId, es usado como identificador particular de una librería en particular.


Cuando se usan archetypes creados por un
o mismo se tiene que especificar los tres parámetros de
todo archetype (groupId, artifactId, version) de la siguiente manera.


mvn archetype:create
-
DarchetypeGroupId=<archetype
-
groupId>
-
DarchetypeArtifactId=<archetype
-
artifactId>
-
DarchetypeVersion=<ar
chetype
-
version>
-
Dgro
upId=<my.groupid>
-
DartifactId=<my
-
artifactId>


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 librerías necesarias para construir el

proyecto.

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


Finalizado el proceso de construcción del artefacto,
Maven

lo deposita en repositorios.




Repositorio: Estructura de directorios y archivos que usa
Maven

para almacenar, organiz
ar y
recuperar artefactos. Existen repositorios locales (file://) y remotos (http://)



Existen dos tipo de repositorios:

o

Repositorio local: situado en la máquina del desarrollador. Almacena artefactos
instalados (
Maven

install) y descargados de repositorios

remotos.

o

Repositorio remotos: repositorios accesibles a través de protocolos file:// y http://.



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



externos: repositorios públicos utilizados par
a 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 construcción.

En ciertos proyectos es importante trabajar con varias bases de datos, en varios entornos diferentes
o en varios servidores. Las librerías y las variables de configuración que se

necesitan para arrancar
en cada entorno son diferentes.
Maven

resuelve

esto mediante profiles:


<profiles>

<profile>

<id>mysql</id>

<activation>

<property>

<name>db</name>


23

<value>mysql</value>

</property>

</activation>

<properties>

<driver>org.mysql.Drive
r</driver>

</properties>

</profile>

<profile>

<id>postgresql</id>

<activation>

<property>

<name>db</name>

<value>postgresql</value>

</property>

</activation>

<properties>

<driver>org.postgresql.Driver</driver>

</properties>

</profile>

</profiles>


Basta co
n pasarle a
Maven

con que perfil quiere instalar.


mvn
-
Pmysql clean


Los perfiles en la versión 3 de
Maven

hay que meterlos en el fichero M2_HOME/conf/settings.xml,
antes
Maven

acostumbraba meterlos en un fichero profiles.xml que acompañaba al pom.xml
principal.


Los tag más importantes en el uso de
Maven

son:




<groupId>: El id del grupo al que pertenece el proyecto.



<artifactId>: El id del artifact o proyecto (en la mayoría de los casos el nombre del
proyecto).



<version>: La versión del artifact en el
grupo especificado.


<groupId>org.archetypeUma</groupId>

<artifactId>archetypeUma
-
model</artifactId>

<packaging>jar</packaging>

<version>1.0
-
SNAPSHOT</version>


Lo de
-
SNAPSHOT
en el nombre de la versión 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 versión de fecha más moderna. Si la hay, se la bajará. Por tanto, sue
le ser útil en un equipo de
trabajo mantener la "coletilla"
-
SNAPSHOT
en los jar que todavía están 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 ha
y versiones más modernas en los repositorios remotos.


24

En los poms se pueden definir muchos componentes. Se van a explicar los que han sido utilizados
para crear esta arquitectura y los más utilizados.

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

<developers>

<developer>

<id>jcisneros</id>

<name>Javier Cisneros González</name>

<email>javicisneros@gmail.es</email>

</developer>

</developers>


scm:

son las siglas de Source Code Management (G
estión de código fuente), es la revisión de
múltiples versiones de una misma unidad de información. Con el siguiente XML se especifica
donde esta el código del proyecto. Esto no es obligatorio pero si es muy guardarlo en el pom
principal del proyecto.


<sc
m>

<connection>scm:svn:https://archetypeuma.googlecode.com/svn/trunk/</connection>

<developerConnection>scm:svn:https://archetypeuma.googlecode.com/svn/trunk/

</developerConnection>

<url></url>

</scm>


licenses:

Las licencias del proyecto se marcan bajo la

etiqueta XML llamada licences. En las
siguientes líneas se especifica que el proyecto será de software libre bajo la licencia Apache
License 2.0 y European Union Public License.

<licenses>

<license>

<name>EUPL v1.0</name>

<url>http://ec.europa.eu/idabc/
eupl</url>

<comments>European Union Public License</comments>

</license>

<license>

<name>Apache License 2.0</name>

<url>http://www.apache.org/licenses/LICENSE
-
2.0</url>

<comments />

</license>

</licenses>


modules
: La etiqueta module asigna al pom los subm
odulos que se ejecutarán después de ejecutarse
el mismo. Es ideal para lanzar una construcción en varios modulos, ya que crearlo en uno solo
puede resultar muy engorroso.

<modules>

<module>model</module>

<module>core</module>

<module>web</module>

</modules
>



25

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 están los repositorios desde los que se
quiere descargar las dependencias del
proyecto.

En el siguiente ejemplo se utiliza el repositorio público de Jboss.

<repositories>

<repository>

<id>jboss</id>

<name>JBoss repository</name>

<url>http://repository.jboss.org/
Maven
2</url>

</repository>

</repos
itories>


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.

<pluginRepositories>

<pluginRepository>

<id>appfuse</id>

<url
>http://static.appfuse.org/repository</url>

</pluginRepository>


<pluginRepository>

<id>alfresco</id>

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

</pluginRepository>


<pluginRepository>

<id>
Maven
2
-
repository.dev.java.
net</id>

<name>Java.net Repository for
Maven
</name>

<url>http://download.java.net/
Maven
/2/</url>

<layout>default</layout>

</pluginRepository>


<pluginRepository>

<id>mc
-
release</id>

<name>Local
Maven

repository of releases</name>

<url>http://mc
-
repo.google
code.com/svn/
Maven
2/releases</url>

<snapshots>

<enabled>false</enabled>

</snapshots>

<releases>

<enabled>true</enabled>

</releases>

</pluginRepository>


<pluginRepository>

<id>repo1</id>

<name>Repo
-
1 for
Maven

2</name>

<url>http://repo1.
Maven
.org/
Maven
2/</
url>

<layout>default</layout>


26

</pluginRepository>

</pluginRepositories>


resources
: Se especifica los recursos que necesitarán las clases java para funcionar correctamente.
Aquí caben muchas posibilidades... plantillas, xml, ficheros estáticos. Se suele po
ner el fichero de
recursos de
Maven

src/main/resources. Al meterlo se empaquetaría en el jar, war o ear como un
fichero más.

<resources>

<resource>

<filtering>true</filtering>

<directory>src/main/resources</directory>

</resource>

</resources>


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

<testResources>

<testResource>

<filtering
>true</filtering>

<directory>src/test/resources</directory>

</testResource>

</testResources>


dependency
: Los proyectos en Java se han llenado de librerías que tienen que interactuar entre si
para formar los proyectos, lo más abstractos posibles. Solo hay
que especificar el groupId el
artifactId y la versión que se desea descargar.

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


<dependency>

<groupId>log4j</groupId>

<artifactId>log4j</artifactId>

<version>1.2.15</ver
sion>

</dependency>




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



artifactId: es usado como identificador particular de una librería en particular. Como log4j
s
olo tiene una coincide con el groupId pero esto no debe porque ser así.



version: Es la versión de la librería 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
s
eis ámbitos en los que una dependencia puede ser declarada limitando así su transitividad:


o

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

o

Provided, se espera que el JDK, la aplicación
o el contenedor provea la dependencia.

o

Runtime, la dependencia no es requerida en tiempo de compilación pero sí para la
ejecución.

o

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

o

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


27

o

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


<dependency
>

<groupId>javassist</groupId>

<artifactId>javassist</artifactId>

<version>3.9.0.GA</version>

<scope>runtime</scope>

</dependency>


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


<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.5</version>

<scope>test</scope>

</dependency>


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


packa
ge(jar, war, aer)

En un ejemplo

myfaces
-
core
-
2.0.0.jar


La versión corresponde a mayor


minor


parches en este caso 2.0.0 Segunda versión, aún 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.

<
plugi
n>

<groupId>org.apache.
Maven
.plugins</groupId>

<artifactId>
Maven
-
compiler
-
plugin</artifactId>

<version>2.0.2</version>

<configuration>

<source>1.5</source>

<target>1.5</target>

</configuration>

</plugin>


En la siguiente tabla se muestra una serie de plugi
ns muy utilizados en los proyectos que se están
utilizando hoy en día.



28

Pluguins más utilizados


Descripción


Maven
-
clean
-
plugin


Limpia el directorio de trabajo.


Maven
-
compiler
-
plugin


Compila el código fuente.


Maven
-
deploy
-
plugin


Despliega el artef
acto 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 te
st de Junit


Tabla X. Plugin más utilizados de
Maven
.


A continuación se describen las órdenes más importantes de
Maven

que todo aquel que trabaje con
esta herramienta debe de conocer:


Comando

Descripción

mvn

癥牳楯r
=
噥爠污⁶=牳槳渠摥=
䵡ven
.
=
浶渠捬man
=
i業灩慲=e氠摩牥c瑯物漠摥⁴牡扡橯⁤攠
ja癥n
=
摥⁵渠=牯óec瑯⁥猠獥nc楬汯⁳潬漠
桡óⁱ=e⁡ña摩爠d汥a渮⁅氠摩牥c瑯物漠摥⁴=a扡橯⁥猠污⁣a牰rta⁴慲来琮
=
浶渠桥汰
=
䵯獴牡爠污⁡ó畤a⁤==
䵡ven
=
c潮⁥氠捯la湤漮
=
浶渠
J
u
=
p椠桡ó⁡lg﩮⁰ú潢汥oa=ó=桡⁳=汩摯⁥氠le湳n橥j_r䥌䐠c
A䥌啒䔠獥⁰略de=
c潭灲潢o爠煵e⁨=⁰=sad漠⁥獣物扩r湤漠
J
堠u潮漠煵q⁳=⁶=渠污猠瑲aza猠s渠
浯摯⁄䕂啇.
=
浶渠me獴
=
䕪bc畴慲愠晡獥⁤e氠捩l汯l摥⁶楤愠摥=
䵡ven
=
牥晥ren瑥⁡潳⁴e獴⸠
=
浶渠灡m歡ge
=
䕭灡煵q瑡t=e渠畮慲ⰠIa爠漠畮⁥a爮⁎漠楮獴a污l猠s浰慱略瑡摯猠tn
=
e氠
牥灯獩瑯物漠t潣a氠湩⁲=浯m漮
=
浶渠m湳瑡汬
=
f湳瑡na爠r渠e氠牥灯獩瑯物漮⁃潭灩污⁥氠灲lóec瑯Ⱐ敪tc畴愠汯猠ue獴Ⱐ敭灡煵q瑡t
汯猠睡爠ó⁥a爠r⁩湳=a污le氠慲瑥tac瑯⁥渠e氠牥灯獩瑯物漠汯捡氠摥l
䵡癥n

⠥䴲归䕐伥F
=
浶渠摥灬mó
=
p椠á漠煵o⁳=⁰牥瑥湤t=e猠楮s瑡污爠r渠n
渠ne灯獩瑯物漠牥浯m漠o渠癥z⁤=⁥渠e氠
汯捡氮⁓e⁥橥j畴愠u渠摥灬oó⸠䕳瑯⁴e湤狭nⁱ=e⁨=ce牬漠畮⁳楳瑥浡⁤==
楮áegrac槳渠捯湴楮畡ác潭漠敳⁈畤獯渮
=
浶渠摥灥湤n湣ó㩴ree
=
佢瑥湥爠r氠á牢潬⁤r⁤e灥湤n湣楡猠ó灴=浩za牬r猠灡牡⁥ñc汵l爠污猠煵s漠=e=
湥ce獩se渮
=
浶渠摥
灥湤n湣ó㩲e獯汶s
=
䵵j獴牡⁵湡=獴慤漠摥⁴=摯猠d潳⁡牴r晡c瑯猠煵e⁨=渠獩摯⁲d獵s汴潳o
=
=
浶渠捬ma渠楮獴a汬=
J

=
J
a
䵡癥n
⹴敳琮獫.瀽瑲te
=
䕮⁵渠b煵楰漠摥⁤q獡牲潬汯a牤=渠淡猠畴n汩za摡⁥猠污⁣潭灩污l槳測á
e浰慱略瑡摯te⁩湳=a污l槳渮
=
=
C潮⁥氠慲g畭敮瑯u
J
漠獥汥ccá
潮o浯猠敬潤漠潦晬f湥⸠䅬.漠煵e⁳=rá⃺瑩氠敮l
e氠敱畩灯⁤l⁤=獡牲潬o漠oa摡⁶=zⁱ略⁳==c潭灩汥Ⱐlaⁱ=e漠獥⁰e牤r狡=
瑩e浰漠敮⁣潮oc瑡牳r⁣潮潳⁲=灯獩瑯物潳⁥t瑥t湯献
=
=
C潮⁥氠慲g畭敮瑯u
J
a
䵡癥n
⹴敳琮獫.瀽瑲略†
獡汴a
=
e渠n氠慬⁣楣汯⁤á⁶楤愠污=
晡獥⁤=⁴e獴só
=
灯爠瑡湴漠n潤潳潳⁰o畧楮猠慳潣楡摯á⁡⁥獴攠s楣汯⁤e⁶楤愮⁁氠
楧畡氠煵攠e氠慲g畭敮瑯ua湴敲楯爠á獴漠桡sáⁱ略⁳==c潭灩汥l猠狡灩摡浥湴攠
e氠灲lóec瑯t
=
浶渠捯浰楬e
=
C潭灩污潳⁦略湴敳⁤n氠灲lóec瑯t
=
浶渠⁥m汩灳é㩥:汩灳é
=
C牥a⁵渠灲oóec瑯⁥渠tc汩灳é⁡⁰=牴楲r
de⁵渠灲oóect漠
䵡癥n
.
=
浶渠m摥a㩩摥a
=
C牥a⁵渠灲oóec瑯⁥渠f湴e汬楪=f䑅䄠a⁰=牴楲⁤e⁵渠灲oóec瑯t
䵡癥n
.
=
=
=
呡扬愠b⸠.潭慮摯猠淡猠業灯牴é湴敳⁤n=
䵡癥n
.



29


3.

Frameworks necesarios en la arquitectura

3.1.


ORM

El mapeo objeto
-
relacional (más conocido por su nombre en i
nglés, Object
-
Relational mapping, o
sus siglas O/RM, ORM, y O/R mapping) es una técnica de programación para convertir datos entre
el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en
una base de datos relacion
al, utilizando un motor de persistencia. En la práctica esto crea una base
de datos orientada a objetos virtual, sobre la base de datos relacional. Esto posibilita el uso de las
características propias de la orientación a objetos (básicamente herencia y po
limorfismo). 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 más utiliza en la actualidad es Hibernate.


3.1.1.

Hibernate

H
ibernate es un ORM

para Java.
Es una capa de persistencia objeto/relacional y un generador de
sentencias sql. Permite diseñar objetos persistentes que podrán incluir polimorfismo, relaciones,
colecciones, y un gran número de tipos de datos. De una manera
muy rápida y optimizada puede
generar BBDD en cualqu
iera de los entornos soportados
: O
racle, DB2, MySql, Postgresql.

Es software libre y su código es abierto, bajo licencia LGPL. Actualmente el proyecto pertenece a
Red Hat pero esta cedido a la fundación
Apache.


Fue creado en 2001 por Gavin King.


Un ORM es una tecnología 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 me
jorando. La mejora más significativa la consiguió cuando cambio los
engorrosos XML por anotaciones, después de que saliera el estándar JPA.


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


Con el fin de mete
r al lector en conocimiento de la utilizad de
H
ibernate se va a exponer un ejemplo
de como se insertaba un usuario en base de datos antes de
H
ibernate y después de
H
ibernate.




Sin
H
ibernate:

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
H
ibernate y
S
pring:

User user = new User(“jcisneros”, “javier”);

userDao.save(user);


Hibernate funciona con dos tipos de anotaciones. Las suyas propias y las que provienen del estándar

30

JPA. Las del estándar son suficientes para la mayoría de las aplicacio
nes que se quieran producir y
las de
H
ibernate añaden funcionalidad para problemas más concretos.


El HQL (Hibernate Query Language) es un lenguaje de interrogación. En el mundo relacional

se
rige por el

SQL (Structured Query Language) que permite obtener
información 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 traduc
ir las consultas
desde las clases en HQL al l
enguaje de interrogación 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.


Además, Hibernate hace uso de APIs de Java, tales como JDBC, JTA (Java Transaction

Api)

y
JNDI (Java Naming Directory Interface).


Los objetos más importantes definidos en
H
ibernate son:




La interfaz Session es una de las interfaces primarias en cualquier aplicación Hibernate.

Una
instancia de Session es "poco pesada" y su creación y de
strucción es muy "barata".

Esto es
importante, ya que la aplicación necesitará crear y destruir sesiones todo el

tiempo, quizá en
cada petición. Puede ser útil pensar en una sesión como en una caché o

colección 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
debería compartirse entre
muchos hilos de ejecución. Típicamente hay una

única
S
essionFactory para toda la aplicación, creada durante la inicialización de la

misma. Sin
embargo, si la aplicación 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 aplicación

utiliza una instancia de Configuration para especificar la ubicación de los documentos

que
indican el mapeado de los objetos y propiedades específicas de Hibernate,

y a

continuación
crea la
s
essionFactory.



La interfaz Query permite realizar peticiones a la base de datos y controla cómo se

ejecuta
dicha petición (query). Las peticiones se escriben en HQL o en el dialecto SQL

nativo de la
base de datos que estemos util
izando. Una instancia Query se utiliza para

enlazar los
parámetros de la petición, limitar el número de resultados devueltos por la

petición, y para
ejecutar dicha petición.


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.



31



Figura

X. Ciclo de vida de
H
ibernate.

[50]


Los estados son Transient, Persistent y Detached y los procesos por los que cambia de estado un
objeto son esos métodos que se invocan desde el cód
igo y que hacen que el objeto cambie. El
estado más importante es el de Persistent al que se llega cuando se invoca un save sobre el objeto.


A conticuación se listan las anotaciones más utilizadas:


Anotación

Descripción

@Entity

Declara la entidad que se
rá persistida

@Table(name=”TABLE_USER”);
=
䅳楧湡=e氠湯l扲b⁤=a⁴慢污
=
@fd
=
oe灲é獥湴愠污=c污癥⁰物浡物r⁤=愠=a扬b
=
䁇e湥ra瑥摖a汵l
=
䝥湥rá愠=污le⁰物浡物aI⁥渠n獴愠潣a獩⁳e⁣reará⁵湡=
獥c略湣áaⰠ灥牯⁨楢e牮r瑥⁤=⁶=物r猠灯獩扩b楤慤á献
=
@i潢
=
C潲oe獰潮
摥渠n潳=ca浰潳⁤o氠l楰漠ái佂=ó⁃il_.
=
䁔@浰潲ml
=
䁔@浰潲m氨le浰潲m汔ó灥⹄.呅q⁤e晩湩摯⁰fra=e氠l楰漠
橡癡⹳煬⹄.瑥t
=
䁔@浰潲m氨le浰潲m汔ó灥⹔f䵅⤠摥晩湩摯⁰f牡=e氠l楰漠
橡癡⹳煬⹔業e.
=
䁔@浰潲m氨le浰潲m汔ó灥⹔f䵅j呁䵐F
=
摥晩湩摯⁰f牡=e氠l楰漠áa癡⹳煬⹔業e獴慭s
.
=
䁔@a湳楥湴
=
pe慲ca=a班⁵渠a瑲楢畴漠湯⁳o狡⁰=牳楳r楤漮
=
䁏湥呯q湥
=
䁍@nóq潏湥
=
䁏湥呯䵡nó
=
䁍@nóq潍onó
=
oe污l楯湥猠á湴ne⁴慢污献s䄠污⁩=煵楥q摡⁤=氠呯⁳攠e湴ne湤nⁱ略=e猠
e獡=獭愠s污獥=ó=a愠摥牥c桡a瑲==c污獥.
=
䁊潩湃o汵l渠⡍nnó呯佮lF
=
䁊潩湔o扬攠b䵡n
ó呯䵡nóF
=
f湤楣a⁣潭漠oe=牥污c楯湡渠污猠摯猠瑡扬n献
=
@f湨e物瑡湣e
=
=
䕸灲é獡⁨=牥nc楡Ⱐ獥⁰略摥⁵瑩汩za爠摥⁶=物r猠景sma猠獥g﩮愠
e獴牡瑥g楡⁰a牡=牥c異e牡爠汯猠摡瑯猺
=
獴牡瑥gó=f湨e物瑡湣eqóée⹔._ib彐䕒彃i䅓A
=
獴牡瑥gó=f湨e物瑡湣eqóée⹊lf久a
=
⡳瑲E瑥gó=f湨n物瑡
nceqóée⹓f乇i䕟呁_i䔩
=

32


Tabla X. Anotaciones más utilizadas en Hibernate.


Hay que tener en cuenta como hibernate recupera los elementos, para eso existen dos atributos en
las anotaciones:




FetchType.LAZY: recuperación tardía. Valor por defecto para:

o

OneTo
Many

o

ManyToMany



FetchType.EAGER: recuperación temprana. Valor por defecto para:

o

OneToOne

o

ManyToOne


Y se pueden utilizar los métodos para recuperarlos:



session.get() hace recuperación temprana.



session.load() hace recuperación tardía


Existen muchas formas

de interactuar con la base de datos por medio de
H
ibernate. Todas distintas
en esencia aunque la mayoría hacen lo mismo.




Criterias: Son unos objetos que definen búsquedas condicionales contra algunos objetos. Es
decir, si se esta buscando las vuelos con
salida de málaga y destino granada, en las que estas
son elegidas en combos, lo ideal sería ponerlo en este tipo de búsquedas.



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 interactúe con objetos y
no con tablas.



Query: son un tipo de búsqueda especial en hibernate, la cual se puede definir en una
anotación o ponerla directamente.


Lo que se pretende es hacer que búsqueda sea lo más fácil posible de c
rear y de entender, pero no
queremos confundir al lector, con los tres tipos de búsqueda se puede hacer las mismas búsquedas.


3.2.


JSF

2

JSF

2

es un frameworks web que facilita la construcción de aplicaciones web.

JSF
2
define tres características: una arqui
tectura de componentes, un conjunto estándar de UI
widgets, y una infraestructura de aplicación. La arquitectura de componentes JSF define una manera
común para construir UI widgets (botones, hyperlinks, checkboxes, cajas de texto, entre otros), pero
tambi
én 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
botón).


Faces puede automáticamente mantener tus componentes UI e
n sincronización con
los objetos
JAVA

que coleccionan los valores ingresados por el usuario y responder a eventos, los cuales

son
llamados Backing B
eans. Adicionalmente, también tiene un sistema poderoso de navegación y

soporte completo para múltiples leng
uajes.


JSF

2

se ejecuta en el Server, por ejemplo una aplicación Faces se ejecutara en un contenedor web

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


33

Cuando
se hace

un clic en un botón, Faces ejecuta un requ
est 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 lógica en el Server. Es responsable también de mostrar en el navegador cada
UI widget que hayamos d
efinido.


Los componentes más importantes de la especificación son:


Termino

Descripción

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, métodos y eventos. Ellos son

organizados en una vista, la cual es un árbol de

componentes usualmente mostrados como una

página.

Renderer

Responsable por mostrar un componente UI y

traducir la

entrada del usuario en un valor al

interior
del componente. Los Renderers pueden

ser diseñados para trabajar con uno o mas UI

components.

Validator

Responsa
ble por asegurarse que el valor
ingresado
por el usuario es aceptable. Uno o

mas validadores
puede
n ser asociados con un

simple UI component.

Backing Beans

Son JavaBeans especializados que coleccionan

valores desde los UI components e implementan

métodos relacionados a los eventos de los UI

components. Ellos también pueden almacenar

referencias a UI c
omponents.

Converter

Convierte el valor para y desde un componente

para
ser mostrado. Todos los UI components

pueden ser
asociados con un simple converter.

Events y Listeners

JSF usa el modelo event/listener (también usado

por Swing). UI components (y ot
ros objetos)

generan eventos, y los listeners pueden ser

registrados para manejar estos eventos.

Mensajes

Información que es muestra de regreso al

usuario.
Solo ciertas partes de la aplicación

(backing beans,
validators, converters) pueden

generar informa
ción
o mensajes de error que

pueden ser mostrados de
regreso al usuario.

Navigation

La habilidad para moverse de una pagina a otra.

JSF tiene un sistema poderoso de navegación

que esta integrado con event listeners

especializados.


Tabla X. Componentes d
e JSF 2.





34

3.2.1.

Myfaces

Myfaces en la versión 2.0 es una implementación de JSF 2. Sólo es un estándar, define un marco de
trabajo.

Lo mejor es empezar con una breve introducción de JSF y
M
yfaces para entender mejor Myfaces.


JSF es un estándar de programació
n 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 e
stos sean reproducibles en diferentes dispositivos no solo en el
HTML

típico de un explorador web. Siendo ampliable así a
PDA
, móviles y otros dispositivos.

El paso de transformación de un componente JSF en el elemento resultante, que puede ser otro
cualqu
iera 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 características de JSF son:



Permit
e modificar o incorporar componentes propios o de terceros.



Permite configurar y definir externamente el flujo de navegación entre las pantallas.



Aporta un ciclo de vida claro y estándar.



Incluye validadores, eventos, J
avabeans, conversores.


Como mejora i
mportante hay que incluir que myfaces 2.0 ya trae integrada la tecnología de facelets.
Ya que jsf es una tecnología orientada a componentes y las JSP es una tecnología orientada a
generar ser
v
lets. Pero al no coincidir había que hacer que alg
uien las casar
á. Es por lo que F
acelets,
una tecnología orientada a construir árboles de componentes en JSF era tan habitual en los
proyectos y por lo que ha sido inc
luida como estándar en M
yfaces2.0.


El ciclo de vida de JSF es el siguiente:





35

Figura X. Ciclo de vid
a de JSF 2. [47]


Entrando en más 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 petición hecha por el
usuario. Examina si FacesCont
ext tiene un UIViewRoot para asignarle un locale y para
recoger los valuebinding y asociarlo con el setValue(). Si la petición es por get y no contiene
parámetros 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 método processDecodes de todos los componentes.




Process validations: Se procesan las validaciones llamando a processValidators.




Update Model
Values: Ahora que están los datos y son válidos se llaman a los métodos que
modifican los valores del modelo. Esto se produce recursivamente en el método
processUpdates.




Invoke Application: La actualización del modelo ha sido completada, se llama al méto
do
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 método encode de cada
componente del árbol de renderizado.


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


<lifecycle>

<phase
-
listener>org.archetypeUma.listener.selection.PruebaPhaseListener</phase
-
listener>

</lifecycle>


El fichero de configuración 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 te
ner las propiedades y métodos que sean
necesaria para cumplir las necesidades del componente desde el que este siendo llamado.




Bundles: Declara los ficheros de internacionalización de la aplicación. Deben de estar en el
classpath de la aplicación y ser de
clarados 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 aplicación.




Co
nversores propios: Se puede disponer de conversores en algunos componentes para que
muestren determinado texto de otra forma dependiendo de algún valor. Es muy utilizado en
tema de horas, fechas y cosas por el estilo.


36




Reglas de navegación: Permite crear u
nas reglas de navegación a partir de una determinada
salida del Managed Bean. Es mejor verlo con un ejemplo:




Componentes propios:


El servlet de myfaces guarda toda la información relacionada con la petición en un objeto llamado

FacesContest. Las principa
les características de este objeto son:



Encapsula los posibles mensajes.



Permite acceder al singleton de la aplicación.



Encapsula al elemento raíz de la aplicación.



Contiene toda la información relativa al estado de la llamada y la renderización de la
resp
uesta.



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



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



Permite acceder al entorno de inf
ormación por medio del ExternalContext.


Si lo que se necesita es crear un componente propio. Hay 3 pasos mínimos que hay que seguir:




Declara el componente: Lleva la lógica del componente. Debe de heredar de la clase
UIComponentBase. Hay que asignarle el
renderer y el tag. Los métodos más importantes