Download Principales variantes tecnológicas del entorno Java para el

Principales variantes tecnológicas del entorno Java
para el desarrollo de aplicaciones en la capa Cliente
Ing. Daniel Pagés Chacón, Dr. Julio Pablo Martínez Prieto
Resumen. La plataforma Java se ha convertido en uno de los
principales entornos para la construcción de software en la
actualidad. Siendo plataforma libre, brinda un sin número de
posibilidades que la ubican en lugares cimeros en cuanto a
preferencia de los desarrolladores a nivel mundial. En el ámbito
del diseño de software moderno, los sistemas son concebidos
generalmente con una estructura dividida en capas. Entre estas
capas se encuentra la nombrada capa Cliente o Vista, la cual
juega el importante roll de garantizar la interacción con los
usuarios. En el presente se muestran las principales variantes
tecnológicas brindadas para la construcción de aplicaciones
clientes en el entorno de la plataforma Java.
Palabras Claves. Java. Capa Cliente. Desarrollo de software.
I. INTRODUCCIÓN
En la actualidad, existe la necesidad constante de
aplicaciones a gran escala que brinden grandes prestaciones a
los usuarios finales y capaces de interactuar con otros
sistemas. Con esto se está refiriendo a grandes sistemas de
software cuyo proceso de desarrollo se convierte en algo
realmente complicado donde cada elemento debe ser muy bien
concebido por el bien de todo el producto final. Con todo lo
anterior puede comprenderse que este proceso no solo no es
trivial, sino que además su costo en tiempo es bastante
elevado.
Por estos motivos en el amplio mundo del desarrollo de
software se han creado numerosas técnicas, patrones a seguir,
estándares, marcos de trabajo o frameworks y herramientas
que buscan, sobre todo, el aumento de la eficiencia y la
productividad a la hora de implementar aplicaciones de
software.
Entre las tendencias más practicadas se encuentra
concepción de los sistemas divididos en capas. Normalmente
en Capa Cliente, Capa de Lógica de Negocio y Capa de
acceso a datos. Esto trae muchos beneficios para los
desarrolladores de los sistemas y para el funcionamiento de
los mismos. Entre los beneficios más notables se encuentra el
hecho de que el trabajo en una de las capas concebidas no
afecta a las otras, evitando así que pequeñas variaciones o
cambios específicos provoquen modificaciones en toda la
aplicación.
Para la mayoría de los sistemas de software interactivos la
sección más expuesta a cambios es, sin dudas, la interfaz de
usurario, en términos más generales, la Capa Cliente. Esto se
debe a que es con ella que los usuarios finales interactúan
directamente y se comunican con el software. Además de los
habituales cambios en cuanto a requerimientos funcionales de
las aplicaciones, los desarrolladores a menudo se ven
enfrentados a requerimientos no funcionales como el soporte
para varios sistemas operativos que exigen diferencias en
cuanto a entornos gráficos (look and feel), y soporte para
diferentes idiomas por solo citar dos ejemplos. Para
aplicaciones de poca envergadura esto no constituye un
problema de mayor importancia, pero cuando se trata de
grandes sistemas la situación se torna diferente. Para la
solución de esta problemática se han creado patrones y se han
desarrollado marcos de trabajo que persiguen como objetivo,
entre otras cosas, hacer más sencillo el proceso de
construcción de software en las capas del lado del cliente.
En el mundo del la elaboración de sistemas de software se
hace importante la presencia de la plataforma Java. Esta
brinda muchas ventajas y elementos que la hacen
indiscutiblemente presente a la hora de buscar variantes para
los desarrolladores de software.
En el entorno de Java se pueden encontrar variantes, como
frameworks, librerías y herramientas que están encaminadas a
brindar la posibilidad de crear aplicaciones visuales, tanto en
ambiente desktop como Web. Estos no solo existen, sino que
evolucionan en aras de encontrar soluciones que permitan
mejores y más robustas implementaciones para los productos
finales. Esta evolución permite crear sistemas empleando de la
mejor forma posible determinados patrones y nuevas variantes
para hacer los grandes sistemas más sostenibles cada vez.
Sin dudas, Java se convierte actualmente en una de las
principales variantes para la construcción de software.
CCIA’2008
II. PATRONES DE DISEÑO
Muchos expertos han definido a un patrón como una
solución recurrente a un problema determinado en un contexto
particular [1].
Siguiendo este pensamiento, cuando se habla a de patrones
de diseño en términos de desarrollo de software, esto se
refiere a determinada forma que se ha establecido para abordar
problemas conocidos de manera más provechosa. A
continuación se exponen algunos de los patrones más
importantes que intervienen en el desarrollo de software
actual, específicamente en el ámbito de las aplicaciones de
presentación.
A. Model-View-Controler (MVC)
Como se ha mencionado anteriormente, en la mayoría de los
sistemas de software interactivos la sección más expuesta a
cambios es la interfaz de usuario [4]. “Estudios de analistas
han arrojado que las compañías emplean aproximadamente el
33% de sus presupuestos en el desarrollo de interefaces” [7].
En softwares monocapas, la realización de pequeños cambios
puede tornarse muy complicada para los desarrolladores, ya
que los mismos se propagan a través de todo el sistema. En
estos casos, frecuentemente los requerimientos de los usuarios
obligan a mantener versiones o variantes separadas de la
misma aplicación cuando un grupo de usuarios tiene
requerimientos de presentación suficientemente diferentes de
otros. Todo esto incrementa considerablemente la complejidad
del sistema en su conjunto [4].
Considerando esta problemática, en aras de hacer el
desarrollo de los sistemas de software más eficiente, ha
surgido un patrón denominado Model View Controller (MVC)
que tiene la intención de particionar las aplicaciones
interactivas en tres componentes independientes. Tal como su
nombre lo indican estos son: Modelo o Model, Vista o View, y
Controlador o Controler. El primero de estos elementos
representa el modelo de datos de la aplicación, la estructura de
los mismos y la lógica de acceso a ellos. El segundo se refiere
a la capa de presentación donde serán mostrados los datos de
una o varias maneras con sus correspondientes
comportamientos visuales, y a través de la cual se interactúa
con la aplicación para acceder a la información. Por su parte,
el último de estos elementos se encarga de contener y procesar
la lógica que debe seguirse en la aplicación. Aquí se procesan
los eventos manipulados por los usuarios, los cuales pueden
desencadenar actualizaciones de los datos o una manipulación
directa de estos en la vista. Controla la interacción entre la
Vista y el Modelo y las secuencias de peticiones con sus
respectivas respuestas [8] [18] [4] [12].
Este patrón propone una comunicación entre estos tres
elementos o partes del sistema a través de interfaces que son
brindadas por cada uno, de manera que se mantenga un alto
desacoplamiento entre ellos, pudiéndose realizar variaciones
en cualquiera, sin que el resto de la aplicación se vea afectada.
Esta interacción se produce como se explica a continuación:
Cuando un usuario interactúa con los componentes de la
interfaz de usuario en la vista, se disparan eventos hacia uno o
2
más controladores para realizar su procesamiento. Si estos
eventos requieren cambios en el Modelo, el Controlador
invoca estos cambios en el Modelo o invoca operaciones
específicas de la aplicación que conducen a dichos cambios.
Si los eventos requieren cambios en los componentes de la
Vista, el controlador los manipula directamente adicionando o
eliminando elementos que luego serán mostrados en la Vista
[4]. El manejo de eventos es un elemento de vital importancia
para la comunicación entre cada una de las capas.
A continuación se muestra la estructura del patrón MVC en
la Figura 1.
Figura 1. Estructura del patrón MVC. Tomado de [4]
Con MVC se hacen palpables beneficios tales como [8] [18]
[4] [9]:
• Se hace más eficiente la construcción de aplicaciones que
requieren diferentes representaciones de una misma
información dado que permite simplemente construir vistas
distintas que interactúen con el mismo controlador y la misma
estructura o modelo de datos.
• De la misma forma pueden ser representadas diferentes
interfaces condicionadas por distintos look and feel, a su vez
establecidos por la necesidad de un desarrollo necesario para
diferentes Sistemas Operativos (SO), o sea multiplataforma.
• Se hace palpable la reusabilidad de componentes de
interfaz ya que estos no se encuentran integrados con ninguna
información de lógica de negocio o de acceso a datos.
• El desacoplamiento con el modelo y el controlador
permite que los cambios realizados en estas capas no afecten a
las restantes, lo cual permite mayor eficiencia en el desarrollo
y mantenimiento, dado que ya no se emplea tiempo ni
esfuerzo en realizar cambios en toda la aplicación por el hecho
de que sus partes se encuentren con un alto grado de
acoplamiento.
B. Model-2 MVC
En el caso de las aplicaciones Web, el hecho de que estas
dependan del protocolo HyperText Transfer Protocol (HTTP)
altera la manera en que implementan el patrón MVC. De esta
forma se puede comprender el término Model-2 como una
adaptación de MVC para Web [4] [12].
CCIA’2008
Tal como se muestra en la Figura 2, con Model-2 los
usuarios interactúan con una interfaz Web a través de un
navegador y las peticiones son enviadas al servidor. En dicho
servidor se encuentra un servlet controlador que se encuentra
a la escucha de peticiones con determinadas direcciones URL.
Este servlet, al recibir las peticiones, se encarga de interactuar
con el Modelo y luego de esto determinar a cuales
componentes de la Vista se le dará el control para generar la
respuesta. Como parte del proceso de generación de respuesta,
los componentes de la vista pueden realizar consultas al
modelo [18] [17] [4].
3
brindar a los desarrolladores la posibilidad de crear Interfaces
gráficas de usuario y pintar gráficos e imágenes. Este conjunto
de clases vienen a conformar un paquete de componentes
visuales de interfaz de usuario que se puede observar en la
Figura 3 [15] [5] [6].
Figura 3. Componentes visuales de AWT. Tomado de [15]
Figura 2. Estructura de Model-2. Tomado de [17]
C. Composite View
En cuanto a concepción de interfaces de usuario gráficas se
cuenta con un importante patrón conocido como Composite
View [1]. Este patrón permite tratar un conjunto de objetos
como un todo único. Consiste en formar interfaces de usuario
a partir jerarquías de componentes con complejidad arbitraria,
donde existen componentes contenedores y primitivos con
comportamientos propios y que son tratados de forma
individual, pero que en su conjunto y con la interacción entre
ellos forman interfaces uniformes [1] [4] [14].
Este patrón posibilita y promueve la reutilización de
componentes y la combinación de ellos para la creación de
interfaces de diferentes formas. Posibilita la creación de
interfaces a partir de plantillas en las que pueden ubicarse los
componentes de distintas maneras [1].
D. Observer Patern
Para el manejo de ellos, existe un patrón conocido como
Observer Pattern. Este patrón persigue el objetivo de notificar
automáticamente a objetos dependientes sobre el estado de
aquellos objetos que son de su interés. Esto propicia que, al
ser detectadas las variaciones o eventos emitidos por los
objetos, estos desencadenen las acciones y procesamientos
pertinentes que deben ocurrir en cada uno de los niveles de la
aplicación.
III. ABSTRACT WINDOWS TOOLKIT (AWT) Y SWING
AWT es un paquete brindado por la plataforma Java 2 que
está formado por un conjunto de clases diseñadas con el fin de
La librería Java Fundation Clases (JFC), creada para Java
por Sun Microsystems, Netscape Comunications entre otros
integrantes [19], consta de seis partes importantes: AWT,
Swing, Accessibility, Java 2D, y Drag and Drop. Java 2D se
ha convertido en una parte integral de AWT, Swing toma
lugar a partir de AWT y Accessibility se encuentra dentro de
Swing. De esta manera puede comprenderse que AWT se
encuentra en el centro de JFC y constituye una de las librerías
más importantes de Java 2 en general [15].
Los componentes de AWT, original versión de Java para
elementos de interfaz de usuario, resultaron insuficientes para
la representación del mundo real a través de aplicaciones
basadas en formularios. Todos los elementos básicos se
encuentran en esta librería pero el conjunto de componentes es
muy reducido y estos resultan muy restrictivos. Por ejemplo:
no se puede ubicar una imagen dentro de un botón. Es por esto
esencialmente que se produce el surgimiento de la librería
Swing [19].
Swing consiste en un extenso conjunto de componentes de
interfaz que heredan de las clases definidas en AWT. Es por
esto que, como se mencionó en la sección de AWT, Swing
está concebido a partir de la estructura de esta librería [15] [5]
[6].
La gran mayoría de los componentes AWT encuentran su
análogo en los de Swing -usualmente nombrados de igual
manera pero con el prefijo “J”-, y en este último existe una
buena cantidad de componentes nuevos como se muestra en la
Figura 4 [15] [19]. Obviamente, de esta manera puede tenerse
una idea de cuánto más rico se presenta Swing en cuanto a
componentes se refiere.
CCIA’2008
Figura 4. Componentes visuales del paquete Swing. Tomado de [15]
A continuación, en la Figura 5 se muestra una pequeña
representación de la estructura de clases de donde provienen
todos los componentes de Swing:
Figura 5. Estructura de clases que de donde descienden los componentes de
Swing. Tomado de [4].
Todos los componentes provienen primeramente de la clase
Component de AWT que posee las propiedades y servicios
básicos para cualquier componente como el manejo de
eventos y su posicionamiento por ejemplo. La clase
Container, también de AWT le da a los componentes la
posibilidad de contener otros componentes dentro de sí. En
ella se incluye una lista donde se agrupan y ordenan sus
componentes hijos. Así mismo posee la posibilidad de
establecer un esquema en el componente, conocido como
4
Layout, dentro del cual se ubicarán los componentes hijos para
ser mostrados organizadamente dentro de si [4] [19].
Con el uso de esta estructura de componentes de interfaz,
Swing implementa típicamente el patrón Composite
mencionado anteriormente. Propone interfaces de usuario con
una estructura formada por una jerarquía de componentes en
la que aparecen contenedores de alto nivel y una serie de
componentes hijos asociados a estos. Esta jerarquía permite
formar cada interfaz a partir de estos componentes contenidos
unos dentro de otros formando un todo único funcional [4].
Los contenedores de alto nivel pueden ser JFrame,
JDialogs o JApplets, y son las ventanas dentro de las cuales
pueden ser representados el resto de los componentes. Los
demás componentes, derivados de JComponent, al provenir de
la clase Container, pueden ser a su vez contenedores e incluir
dentro e si otros componentes, o simplemente pueden no
actuar como contenedores y realizar determinadas funciones
útiles para el usuario que interactúa con la aplicación a través
de ellos [15] [4].
Un elemento de relevante importancia de Swing es el hecho
de que sus componentes están creados 100% en Java. De esta
manera, a diferencia de AWT, los mismos no necesitan
mostrarse como los componentes análogos presentados por las
diferentes plataformas, lo cual le confiere a Swing un
marcado carácter multiplataforma ya que sus componentes
pueden ser mostrados idénticamente en Macintosh, Solaris,
Linux, o Windows [15].
Swing no está estrictamente basado en la forma tradicional
propuesta por el patrón MVC. En sus componentes se
encuentran unidas las capas Vista y Controlador en lo que se
denomina UI Delegate [15] [19].
En las aplicaciones Swing, dada la riqueza de componentes
que permite una gran diversidad de formas para mostrar la
información y el manejo de la misma, en ocasiones se cuenta
con que un mismo componente posee más de un modelo de
datos, o por el contrario, un mismo modelo puede ser
representado por diferentes componentes con los
comportamientos propios de cada uno. Por todo esto se busca
una menor complejidad en la interacción entre las capas Vista
y Controlador dado que sus funcionalidades ocurren juntas
dentro de dichos componentes. De esta forma cada
componente, empaqueta su vista y controlador en un único
objeto denominado UI Delegate que se encarga de las dos
labores, la representación visual y el manejo de eventos
provocados por el usuario [15].
En relación con el manejo de eventos, puede decirse que
Swing hace uso del patrón Observer descrito anteriormente
para dar a sus componentes la posibilidad de dar respuesta a
los eventos manejados por los usuarios. Teniendo en cuenta
este patrón, a los componentes de Swing se les pueden
registrar oyentes, o Listener, de manera que siempre se
encuentren detectando la ocurrencia de algún evento esperado
en componentes de interés para el correspondiente
procesamiento [15] [19].
CCIA’2008
IV. SERVLET Y JAVASERVER PAGES (JSP)
Servlet es una de las tecnologías más importantes de la
plataforma Java. Ella constituye la fundación del desarrollo de
aplicaciones Web utilizando el lenguaje de programación Java
y constituye la base sobre la cual se soporta posteriormente
JSP. Los Servlet son clases Java que proporcionan
comportamiento dinámico a una aplicación Web. Con ellas se
construyen páginas Web en respuesta a las peticiones del
cliente a partir de código Java. Estas clases son cargadas y
ejecutadas por un servidor Web especial que se ha decidido
nombrar Servlet Container o Servlet Engine en sus inicios. La
interacción entre los servlets y los clientes se produce a través
de ciclos petición-respuesta basados en el protocolo HTTP
[11].
En su modo de funcionamiento, un Servlet es cargado por el
Servlet Container la primera vez que es necesitado para el
procesamiento de una petición. Seguidamente el contenedor le
reenvía dicha petición, esta es procesada y la respuesta
generada es retornada al Servlet Container, quien finalmente
se encarga de enviarla al cliente. Luego de terminada esta
secuencia el Servlet se mantiene cargado de manera que puede
ser utilizado para responder a próximas peticiones. Por otro
lado, la clase del Servlet guarda una marca de tiempo que
refleja la última vez que fue actualizado. Esta marca es
encuestada en todo momento por el contenedor. Cuando se
detecta que la misma es más reciente que la última vez de
encuesta, el Servlet vuelve a ser cargado en memoria
manteniéndose siempre actualizado el Servlet Container [11].
En la programación con Servlet las páginas HTML o XML
deben ser generadas a partir de la programación en Java. Un
ejemplo se muestra a continuación tomado de [11].
5
En el momento en que los Servlet fueron ganando
popularidad, para dar solución a esta problemática surgió la
tecnología JSP. Esta no constituye una sustitución de la
tecnología Servlet existente, sino que se convierte en una
extensión de la misma [11].
JSP es una tecnología basada en plataforma Java para la
construcción de aplicaciones Web. Se basa en incluir tags
dentro del código de las páginas html y salvar las mismas con
extención .jsp. Dentro de estos tags (<% ... %>) se incluye
código Java que es ejecutado del lado del servidor. Esto
permite combinar plantillas estáticas con contenido dinámico
para la conformación de una respuesta, y así generar
dinámicamente solo aquellos elementos que requieren este
comportamiento [13]. Un ejemplo de una página jsp tomado
de [8] se muestra a continuación.
JSP está diseñada sobre la base de la tecnología Servlet y
necesita de ella para su funcionamiento. En aplicaciones JSP,
el Servlet Container es sustituido por un JSP Container y
ambos son referidos como Web Container o Servlet/JSP
Container. Dentro del JSP Container se encuentra un servlet
especial llamado page compiler. Al recibir peticiones HTTP
que coinciden con la extención .jsp, el contenedor las envía a
este servlet específicamente. Al recibir estas peticiones el
page compiler las traduce en una clase servlet para ser
procesadas y emitir la respuesta.Una vez compilado este jsp
servlet, el mismo es guardado en memoria para futuras
peticiones.
JSP finalmente se convierte en un paso de avance para el
desarrollo de aplicaciones Web de manera más eficiente.
Resuelve el problema fundamental de lo arduo que resulta con
Servlet el mantenimiento de grandes volúmenes de código
final generado a partir de código Java estructurados en clases.
V. STRUTS
Struts es un framework creado específicamente para
aplicaciones Web. De este modo, su arquitectura se ha
diseñado de siguiendo en el patrón Model 2 MVC tal como lo
muestra la Figura 6 [8] [18] [4] [9].
Esta tarea, así como el mantenimiento de las aplicaciones,
se convierte en algo realmente tedioso si se tiene en cuenta
que todo el código HTML o XML será generado
dinámicamente a partir de las clases Java.
CCIA’2008
6
contener el modelo de datos, usualmente son representados
por Java Beans Empresariales o Enterprise Java Beans (EJB),
Java Data Objects (JDO o frameworks de persistencia como
Hibernate), o Java Beans planos que acceden a bases de datos
a través de JDBC [1].
Figura 6. Estrutura de la arquitectura de presentada por Struts. Tomado de
[4]
A. Controlador (Controller)
La esencia del controlador en Struts consiste en un servlet
que se denomina ActionServlet [1]. Este es el responsable de
recepcionar las peticiones provenientes de un cliente
(típicamente un navegador Web), realizar el correspondiente
procesamiento para generar y emitir una respuesta. Otros
elementos importantes que toman parte en el lado del
controlador son los Actions y los ActionsMappings.
Los Action son básicamente determinados JavaBeans cuya
función radica en analizar la información contenida en la
petición, procesar las operaciones requeridas, opcionalmente
llenar los datos que serán mostrados en la presentación y
notificar cuando el control debe volver a pasar al
ActionServlet. Struts posee un importantísimo fichero de
configuración Extensible Markup Languaje (XML),
normalmente llamado struts_config, en el cual se encuentran
contenidas
secciones
específicas
denominadas
ActionMappings. Estas se encargan de realizar el mapeo de las
peticiones provenientes del cliente con el correspondiente
Action. En el momento de iniciar la aplicación, el
ActionServlet carga el contenido del struts_config en el cual se
encuentran los ActionMappings. Luego, en el momento en que
se recibe una petición desde el cliente, utiliza el contenido de
estas secciones para determinar que acción debe ser tomada o
a que Action debe ser pasado el control en dependencia de la
dirección URL de la petición. Finalmente, cuando un Action
termina su ejecución, accede al ActionMapping para
determinar qué dirección o JSP se enviará como respuesta y
pasar el control nuevamente al ActionServlet [8] [18] [4] [9].
B. Modelo (Model)
El modelo de dominio de los datos no es exactamente
objeto de implementación del espacio de trabajo de Struts.
Consiste en objetos de negocio de la aplicación, encargados de
C. Vista (View)
La capa de la vista en Struts está formada por páginas JSP
nutridas de tags personalizados brindados por librerías de tags
que el framework provee. La manera de llevar la información
a la vista ocurre a través de unos JavaBeans denominados
ActionForms. Estos elementos representan la información que
se mostrará o provendrá de las paginas JSP a través de sus
propiedades que coinciden con los componentes presentados
por los tags. El mapeados con cada uno de los JSP se registra
en el fichero de configuración struts_config [8] [18] [4] [9].
En el momento en que se reciben las peticiones, el
ActionServlet, luego de hacer el mapeo correspondiente, carga
en el ActionsForm adecuado todos los parámetros
provenientes del cliente y es aquí donde se producen las
validaciones pertinentes. Luego de esto es que es invocado el
Action respectivo [8] [18] [4] [9].
Tiles
Entre las librerías brindadas en el framework de Struts se
encuentra una que provee elementos de relevante importancia
para la construcción de interfaces. Estos elementos son
denominados Tiles y le dan una composición a la Vista
siguiendo el patrón Composite.
Las construcciones con Tiles en las páginas JSP permiten
ensamblar páginas de presentación formadas por partes
componentes. Cada parte, o Tile, representa una porción del
conjunto total y puede ser rehusado siempre que sea necesario
dentro de la aplicación. Esto lógicamente reduce el número de
páginas a mantener dentro de los sistemas y facilita los
cambios de look and feel [10].
Un componente o Tile consiste en un Definition o una
página. Un Definition no es más que un XML que define una
plantilla parametrizada que propone una estructura de página.
Este permite contener dentro de su esquema a otros Definition
o páginas [4] [18].
D. Eventos
En cuanto al manejo de eventos, Struts realiza esta tarea a
través de lo que se llama Eventos de Aplicación. En esencia
esto se trata de realizar submit a los formularios o activar
hipervínculos. Puede notarse como estas acciones
desencadenan el flujo que se realiza alrededor del
ActrionServlet, el cual se encarga de manipular la petición que
proviene producto de estos eventos y activar el
correspondiente Action. En este sentido, a diferencia de
Swing, donde a cada componente se le puede asignar varios
Oyentes para monitorizar varios tipos de eventos, cada
componente puede ser declarativamente manejador de un solo
evento [4].
CCIA’2008
VI. JAVASERVER FACES (JSF)
En la medida en que las aplicaciones Web han ganado en
complejidad, se ha hecho inminente, en aras de facilitar su
concepción y confección, la aparición de variantes que
conlleven a una división lógica de los elementos de una
página. Por ejemplo ocurre que los sistemas poseen múltiples
formularios y diferentes elementos personalizados que
confluyen en una misma página, todos los cuales procesan
lógicas particulares en su funcionamiento. En este sentido se
busca lograr interfaces Web más cercanas a las Desktop en
cuanto a riqueza de componentes y posibilidades para la
interacción de los usuarios [16].
Para administrar de una mejor manera dicha complejidad,
han surgido y se han hecho populares los frameworks basados
en componentes. Dichos marcos de trabajo brindan un
acercamiento entre los componentes de interfaz y clases que
los representan, y además manejan sus propios eventos. Esto
proporciona un mayor comportamiento orientado a objeto a
las aplicaciones Web que los frameworks basados en acciones
como Struts. Por otro lado, los basados en componentes han
elevado aun más la reutilización de componentes permitiendo
esto incluso a través de múltiples aplicaciones Web [16].
Figura 7. Arquitectura de JSF. Tomado de [4].
JSF, al igual que Struts está concebido para aplicaciones
Web en Java, pero se encuentra mucho más cercano a Swing
en cuanto a su implementación, estructura de componentes de
interfaz y reusabilidad de los mismos [4]. JSF es un
framework que trata de proveer componentes similares a los
de Swing, es decir, componentes manejados por eventos e
interfaces componibles a partir de ellos y que pueden cambiar
fácilmente su apariencia para ser ajustados a look and feel
7
determinados, pero para aplicaciones Web. Es un framework
que hace uso de la arquitectura Model-2 dado el hecho que
está enfocado para aplicaciones de este tipo. A semejanza de
Struts, posee una noción bien definida del Modelo, la Vista y
el Controlador. Pero como diferencia más sustancial se tiene
que la Vista con JSF está compuesta por un árbol de
componentes mientras que Struts se encuentra muy centrado
en las páginas a mostrar [4] [12]. En la Figura 7 se muestra un
esquema de la arquitectura de JSF.
A. Controlador (Controller)
El Controller está formado primeramente por un Servlet
controlador llamado FacesServlet, uno o varios ficheros de
configuración y un conjunto de manejadores de acciones. El
primero de estos elementos tiene la responsabilidad de recibir
las peticiones enviadas desde el cliente Web y, transitando por
una serie de pasos, preparar y enviar una respuesta [4] [12]
[2]. Los pasos que se siguen en este procedimiento son los
siguientes.
• Recuperar la Vista (Restore View): Este es
en esencia el proceso de creación de un árbol de
componentes asociado a la página de la petición
enviada.
• Aplicar Valores de la Petición (Apply
Request Values): Una vez conformado el árbol de
componentes, este es actualizado con la
información contenida en la
petición. Esto
incluye no solo los campos establecidos sino
también los eventos de los componentes de
interfaz que deben ser procesados en próximas
etapas.
• Procesar
Validaciones
(Process
Validations): En esta etapa se produce el chequeo
de las validaciones para los componentes de
interfaz.
• Actualizar Valores del Modelo (Update
Model Values): Aquí se produce la actualización
de los elementos del modelo que se refieren en los
componentes de interfaz.
• Invocar Aplicación (Invoke Aplication): En
esta fase son ejecutados todos los eventos
(ActionEvents) que ejecutan una funcionalidad
dada. Normalmente aquí en estos eventos se
interactúa con objetos de negocio.
• Emitir Respuesta (Render Response): Una
vez realizado el procesamiento de la petición con
todo lo anterior, cualquier respuesta se generará a
partir del actual árbol de componentes,
incluyendo las modificaciones realizadas, o a
partir de un nuevo árbol. Siempre que se usen
páginas JSP para la Vista, cada árbol de
componentes estará asociado a una de estas en
particular.
B. Modelo (Model)
El Modelo, por su concepto, consiste en la parte de la
aplicación que se encarga de contener los datos y la lógica de
negocio asociada a ellos. En JSF, consiste en JavaBeans o
CCIA’2008
clases planas cuyo objetivo es respaldar los datos de los
componentes de interfaz y contener la lógica de manipulación
y acceso a los mismos. Algo similar a lo que se conoce en
Struts como ActionForm [4] [12].
C. Vista (View)
En JSF, la Vista está concebida siguiendo el patrón
Composite Patern [14] [4]. Teniendo en cuenta este patrón,
JSF consiste esencialmente en el árbol de componentes. Lo
cual representa la jerarquía de componentes JSF que van a
conformar la interfaz de usuario. Esto le confiere la
característica de poder representar la información de distintas
maneras de acuerdo con la interfaz requerida en un momento
dado, ya que los componentes de interfaz pueden ser
mostrados de manera diferente para soportar distintos tipos de
interfaces. Ellos son llevados a las páginas JSP a partir de
etiquetas predefinidas que determinan su representación en la
interfaz Web [4] [2] [12].
Otro elemento importante es que los componentes de
interfaces confieren a las aplicaciones Web un mayor
comportamiento manejado por eventos. En la interacción del
usuario con el cliente Web, por ejemplo al marcar un check
box, se pueden disparar eventos que se asocian a estos
componentes. Estas acciones pueden desencadenar
procedimientos o cambios en la apariencia del propio
componente o de otros en el árbol [4]. Con esto se amplían las
posibilidades de disparar eventos desde las acciones
ejecutadas por los usuarios a nivel de interfaz en la Web,
semejándose de esta forma un poco más a lo que ocurre en
aplicaciones desktop desarrolladas, por ejemplo, con Swing.
D. Eventos
Como se mencionó anteriormente, los eventos son
elementos importantes dentro de una arquitectura MVC. JSF,
por su parte, hace uso de Observer Pattern para realizar el
manejo de eventos y la comunicación entre Vista, el
Controlador y el Modelo. Este framework posee dos tipos de
eventos, los conocidos como Value Changed y los Actions.
Los primeros son utilizados para observar los cambios
ocurridos en las propiedades de de los componentes de
interfaz de usuario, por ejemplo la expansión de un nodo en
un árbol o el cambio del texto en un campo de texto. Los
Actions tienen que ver con la activación de componentes de
interfaz de usuario como hipervínculos y botones [4].
JSF provee interfaces oyentes que, al ser implementadas por
los componentes donde se desea recibir un evento, les
permiten el chequeo automático de la ocurrencia del mismo.
Estas interfaces son, en correspondencia con los tipos de
eventos antes mencionados, ValueChangeListener y
ActionListener. Cuando se implementan estas interfaces deben
ser adicionados métodos en los cuales se implementa el
código que debe ser ejecutado en dicho evento
(processValueChange(…)
o
processAction(…)
).
Lógicamente, estos métodos son invocados por los oyentes
cuando estos son notificados de la ocurrencia de un evento [4]
[12].
8
VII. STRUTS 2
Struts 2 no constituye una nueva versión del framework
Struts. En realidad se trata de uno completamente nuevo.
Struts 2 es un framework destinado a aplicaciones Web que
igualmente implementa el patrón MVC en su variante Model 2
o Front Controller. Pero a diferencia de Struts incluye nuevos
recursos en su arquitectura que lo hacen más flexible y menos
complejo en su accionar. Estos nuevos elementos son los
interceptores (interceptors), el uso de configuraciones basadas
en anotaciones para disminuir o eliminar las configuraciones
por XML, el Object-Graph Navigation Languaje (OGNL) y
los ValueStack [3]. Más adelante se mostrará lo que esto
significa y cómo se inserta en el flujo de trabajo propuesto por
Struts 2.
Algo muy importante que se debe destacar en cuanto a
Struts 2 es que este sigue siendo un marco de trabajo centrado
en ‘acciones’ al igual que Struts. [16]. La Figura 1.9 muestra
la implementación del patrón MVC por Struts 2.
Figura 8. Implementación de MVC por Struts 2.
A. Controlador (Controller)
El controlador es presentado por un servlet llamado
FilterDispatcher. Este se encarga de realizar, el mapeo de las
peticiones provenientes del cliente a las diferentes Acciones
que se deben invocar. Su trabajo, al igual que en los
frameworks anteriores es meramente administrativo, no
encierra en modo alguno lógica de negocio asociada a la
aplicación en particular y es manipulado por la
implementación del framework. El mapeo necesario entre las
URL y las acciones se realiza a través de ficheros de
configuración XML o de ‘anotaciones Java’ [3].
B. Modelo-Acción (Model)
En Struts 2, el modelo se encuentra implementado por los
propios componentes de acciones ‘Actions’. El modelo
representa un estado interno de la aplicación. Dicho estado
está constituido por dos partes importantes: el modelo de datos
y la lógica de negocio asociada a ellos [3].
Luego de recibir las peticiones, el controlador consulta los
ficheros de mapeo para encontrar la acción correspondiente
CCIA’2008
que debe ser invocada. En este momento se preparan los datos
provenientes de la petición y se ejecuta la lógica necesaria por
parte del componente de acción. Finalmente el control es
pasado a los componentes de la vista, en los cuales se
mostrará la información resultante.
C. View-Result (Vista)
La vista consiste específicamente en páginas JSP u otras
tecnologías de presentación. Las paginas resultantes son la
expresión al usuario del estado de la aplicación. Al finalizar la
ejecución de una acción la vista-resultado es la representación
del estado final de la aplicación luego del proceso realizado, y
es responsabilidad del Action decidir cual resultado mostrar al
finalizar su labor [3].
D. Nuevos elementos en el flujo de trabajo de Struts 2
(Interceptors, OGNL y ValueStack)
La Figura 1.10 muestra el ciclo de trabajo que define Struts
2.
acción que se invoque, teniendo en cuenta que esto no forma
parte del las tareas propias de la acción. El uso de un
interceptor permite, definiendo en él proceso de loggeo
necesario, que este pueda ser invocado al inicio de la
ejecución de cada acción. Otras utilidades muy comunes son
la validación de datos, la conversión y la subida de ficheros al
servidor.
ValueStack: Estos elementos constituyen áreas en donde se
almacenan los datos asociados al procesamiento de las
peticiones. Dicha información se almacena en los ValueStack
en el momento de preparación de los datos para el
procesamiento de las peticiones, es utilizada durante la
ejecución de las acciones y es leída de dichos elementos para
conformar la respuesta. Los ValueStack son manipulados a
través del lenguaje de expresiones OGNL.
VIII. RESULTADOS
La realización de este estudio sobre las principales variantes
para el desarrollo de aplicaciones clientes en entorno Java, ha
permitido al autor de este trabajo y un conjunto de Ingenieros
y profesores del grupo de investigación GISTI de la CUJAE
tener una mayor visión en cuanto a tecnologías y opciones
para el desarrollo de su trabajo. En este aspecto ha tenido un
relevante aporte en las decisiones que se están valorando para
la concepción de una nueva versión del Sistema de Gestión de
la Nueva Universidad SIGENU. Así mismo ha sido de gran
utilidad como parte de la investigación que realiza el autor de
este trabajo en aras de buscar variantes para mejorar la
eficiencia en el desarrollo de aplicaciones del lado del cliente.
A modo de conclusión final, el equipo de desarrollo de
SIGENU decidió la utilización de JSF. Esto se debió a que el
mismo es un framework que brinda muchas bondades dado su
comportamiento mucho más orientado a objeto, a la riqueza
de sus componentes y, lógicamente, a que se desea realizar el
trabajo en plataforma Web.
REFERENCIAS
Figura9. Flujo de trabajo de Struts 2.
Según lo visto anteriormente puede comprenderse
fácilmente el flujo que se ha descrito. En él la petición llega
proveniente del cliente, el controlador selecciona la acción
correspondiente y le pasa el control. Se guardan los datos que
conforman el modelo en el componente de acción y se ejecuta
la lógica contenida en el mismo. Finalmente este pasa
determina la respuesta que se emitirá y pasa el control a las
páginas que serán mostradas. Pero en la arquitectura definida
por este framework aparecen nuevos elementos (Interceptors,
OGNL y ValueStack) que resultan importantes y le han dado la
pincelada característica y novedosa que posee este marco de
trabajo.
Interceptores: “Son componentes que se ejecutan antes y
después del procesamiento de las peticiones y pueden ser
reutilizados en diferentes contextos.” [3]
Para una mejor comprensión se cita un ejemplo que ilustra
muy bien la utilidad de un interceptor: Este es el caso de un
proceso de logging que debe ser ejecutado al inicio de cada
9
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
Alur DC, John; Malks. Dan. Core J2EE Patterns: Best Practices and
Design Strategies, 2a Edición ed., 2003.
Bergsten H. JavaServer Faces O'Reilly Media, Inc, 2004.
Brown DD, Chad Michael; Stanlick, Scott. Struts 2 in Action Manning
Publications Co, 2008.
Dudney B, Lehr J, Willis B, Mattingly L. Mastering JavaServer Faces
Willey Publishing Inc, 2004.
Eckel B. Thinking in Java, 2a Edición ed., 2000.
Eckel B. Thinking in Java, 3a Edición ed., 2002.
Erickson R. Service Oriented Architecture. Successful SOA
Implementation, 2004.
Goodwill J. Mastering Jakarta Struts Wiley Publishing, Inc, 2002.
Hightower R. Jakarta Struts Live SourceBeat, LLC, 2004.
Husted TB, Ed; McClanahan, Craig R. Struts User Guide, 2003.
Kurniawan B. Java for the Web with Servlets, JSP, and EJB: A
Developer's Guide to J2EE Solutions New Riders Publishing, 2002.
Mann KD. JavaServer Faces In Action Manning Publication Co, 2005.
Pekowsky L. JavaServer Pages, 2a Edición ed. Addison Wesley, 2003.
Richardson WC, Avondolio D, Schrager S, Mitchell MW, Scanlon J.
Professional Java JDK 6 Edition Wiley Publishing, Inc, 2007.
Robinson MV, Pavel. Swing, 2a Edición ed. Manning Publications Co,
2003.
Roughley I. Starting Struts2 C4Media Inc, 2006.
CCIA’2008 10
[17]
[18]
[19]
Shenoy SM, Nithin. Struts Survival Guide-Basics to Best Practices
ObjectSource LLC, 2004.
Spieldman S. The Struts Framework - Practical Guide for Java
Programmers Morgan Kaufmann Publishers, 2003.
Zukowski J. The Definitive Guide To Java Swing, 3a Edición ed.
Apress, 2005.