MODELOS DE

PROGRAMACIÓN II
Pedro Julián González

EJE 2
Analicemos la situación

Fuente: Shutterstock/510212359
 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Framework y el modelo MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Tipos de frameworks web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

JavaServer Faces: tecnología de interfaz de usuario . . . . . . . . . . . . . . . . . . 7

Frameworks tipo RIA con base en el servidor . . . . . . . . . . . . . . . . . . . . . . . 8

Atributos de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

JavaServer Faces: beneficios tecnológicos . . . . . . . . . . . . . . . . . . . . . . . . . 15

Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Creación de proyectos con JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Creación de servicios web SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Servicios web desde la vista del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Modelo de programación JAX-WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ÍNDICE
 Introducción

La industria del software se ha convertido en uno de los pilares para la

economía latinoamericana y en general del mundo entero. Solamente en
Colombia, para junio de 2016, el desarrollo de software ya representaba un
poco más del 1 % del PIB. Esto se traduce en que cada día más personas,
tanto independientes como grupos de desarrolladores, están invirtiendo
INTRODUCCIÓN

tiempo y dinero en pro de expandir la generación de aplicaciones que ayuden

a la solución de problemas al interior de las organizaciones y sobre todo a la
optimización y mejora de los procesos que allí se encuentran.

De allí la importancia de conocer más a fondo los elementos que com-

ponen las aplicaciones y sobre todo aquellas que están orientadas a la web,
teniendo en cuenta que gracias a la constante evolución y mejora de los dis-
positivos informáticos y la relevancia que internet ha sumado allí, hoy en día
la información puede analizarse, procesarse y apropiarse casi de inmediato.
Framework
 El término framework se utiliza en dife-
rentes escenarios del desarrollo de sistemas
de software, y no es exclusivo al de las apli-
caciones orientadas a la web. Se pueden
encontrar frameworks para la generación
de soluciones, por ejemplo, de tipo médico,
de visión por computador, para videojuegos
y en general para cualquier contexto que se
quiera pensar. En general, framework hace
referencia a un componente de software,
compuesto de elementos intercambiables y
configurables que es utilizado puntualmente
en la generación de soluciones de software.
Dicho de otra forma, un framework se con-
sidera como un programa incompleto de
índole genérico y altamente parametrizable
al que se le pueden ir añadiendo distintos
elementos para generar un producto total-
mente terminado.
Un framework tiene como objetivos prin-
cipales la aceleración del proceso de desa-
rrollo de software, la reutilización de código
existente y la promoción de prácticas ópti-
mas de desarrollo, cabe mencionar, por
ejemplo, la definición y el uso de patrones.
Por tanto, un framework puede definirse
como el conjunto de componentes (cla-
ses en java o cualquier otro lenguaje de
programación, archivos y descriptores de
parametrización en XML) que construyen
eficientemente un diseño reutilizable que
agiliza y, por ende, facilita el desarrollo de
soluciones de software orientados a la web.
Framework y el modelo MVC
MVC hace referencia a una guía bas-
tante relevante, enfocada en el diseño de
arquitecturas de soluciones de software
que permiten ofrecer una interactividad
constante con usuarios. Dicho patrón es
Modelos de Programación II - eje 2 analicemos la situación
capaz de organizar la aplicación en tres
modelos definidos y separados. En pri-
mera instancia se encuentra un modelo
que muestra los datos de la solución y los
correspondientes protocolos de negocio, de
igual forma hace referencia al conjunto de
vistas utilizadas para la representación de
los formularios para la respectiva entrada
y salida de información, por último, se
encuentra el tercer modelo, el cual es un
conjunto de componentes de tipo contro-
lador, que logran procesar las solicitudes de
los usuarios además de controlar el flujo de
ejecución del sistema.
Los frameworks para web, en su mayo-
ría, implementan dicho patrón. Utilizar
MVC en entornos Java orientados a la web
se denomina comúnmente como arqui-
tectura modelo 2. Esta arquitectura hace
referencia a la definición y uso de servlets
orientados al procesamiento de peticiones
y páginas JSP, utilizadas para visualizar la
interfaz de usuario, implementando la el
modelo a través de JavaBeans, también
conocidos como POJO.
POJO
Son las iniciales de “Plain Old Java Object”, que puede inter-
pretarse como “un objeto Java plano y antiguo”. Un POJO es
una instancia de una clase que no extiende ni implementa
nada en especial. Para los programadores Java sirve para
enfatizar el uso de clases simples y que no dependen de un
framework en especial. Este concepto surge en oposición al
modelo planteado por los estándares EJB anteriores al 3.0, en
los que los Enterprise JavaBeans (EJB) debían implementar
interfaces especiales (Pesquera, 2014).
5
 Tipos de frameworks web

En el mundo del desarrollo, pueden encontrarse varios tipos de frameworks: aquellos

que son enmarcados en la interfaz de usuario, tales como Java Server Faces, los que están
orientados a aplicaciones para la publicación de documentos, como Cocoon, también
los Struts, los cuales se orientan al control de eventos y otros que pueden incluir varios
elementos como Tapestry. Por lo general, los frameworks se han de encargar del ofreci-
miento de una capa propia de controladores teniendo en cuenta MVC o el modelo donde
incluye JSP y servlets, brindando distintos mecanismos que faciliten integrarse con otras
herramientas definidas para la implementación de las respectivas capas de presentación
y negocio.

Características

En el siguiente cuadro, se enuncian un conjunto de atributos que pueden encontrarse

en la mayoría de los frameworks que existen en la actualidad.

Abstracción de sesiones No se hace necesario manipular las sesiones y las URL de forma
y URL directa, ya que el framework es quien se encarga de realizar esa tarea.
Incluye las interfaces y las herramientas necesarias para integrarse
Acceso a datos
con herramientas para el acceso a datos en XML, BBDD, entre otros.
Los frameworks, en su mayoría, implementan un conjunto de con-
troladores para la administración de eventos, la entrada de datos a
Controladores través de formularios o el acceso a una determinada página. Dichos
controladores se adaptan de manera fácil a las necesidades de un
proyecto en específico.
Integran mecanismos para la identificación de usuarios, a través de
Control y autenticación un login, password, los cuales permiten la restricción del acceso a
ciertas páginas a algunos usuarios.

View components Controller components

Struts configuration
File
(struts-config.xml)

View component Action

Request class
(HTML/JSP)
Struts
Action
Controller
class
View component Forward Servlet
(JSP) Action
class

Figura 1. Descripción del funcionamiento de un framework

Fuente: http://blog.burakkutbay.com/spring-mvc-dersleri-nedir.html/

Modelos de Programación II - eje 2 analicemos la situación 6

 Se ha tomado como referencia el framework open-source
Struts, el cual está desarrollado en Java haciendo uso de ser- Open-source
vlets y se basa en el modelo 2, una variación de MVC. Es una expresión de la len-
gua inglesa que pertenece al
ámbito de la informática. Es
A diferencia de otros frameworks, Struts brinda su propio importante distinguir entre el
software open-source, que dis-
controlador y ofrece gran integración con otras tecnologías pone de la mencionada carac-
para la implementación del modelo, a través de tecnologías de terística de presentar su código
abierto, y el software libre (que
acceso a datos como Hibernate o JDBC y la vista, por medio puede descargarse y distribuir-
de JSP, XSLT o Velocity. Struts ofrece un sistema que permite de se de manera gratuita) (Defini-
ción.de, s.f.).
forma eficiente la comunicación entre las vistas que ofrecen
los datos y el modelo que los contiene.

Instrucción
Lo invitamos a la página principal del eje para ver
las videopreguntas.

JavaServer Faces: tecnología de interfaz de usuario

JavaServer Faces es un framework de interfaz de componentes de usuarios que se

ubica del lado del servidor para aplicaciones orientadas a la web, las cuales se basan en
Java. La tecnología JSF está compuesta principalmente por los siguientes componentes:

• Una API para la presentación de componentes de interfaz de usuario (UI) y admi-

nistrar su correspondiente estado.

• Utilización de eventos, validación en el servidor y la conversión de datos.

• Definición de parámetros para la correcta navegación de páginas y sitios.

• Soporte de accesibilidad e internacionalización.

• Uso de librerías de marcas JSP configurables para la muestra de distintos ele-

mentos en un sitio JSP y la generación de enlaces de componentes a objetos del
respectivo servidor.

Al definir correctamente las librerías de etiquetas y el modelo de programación, se

facilita la correspondiente construcción y mantenimiento de los programas con interfaces
de usuario de servidor. De igual manera, también es posible:

• Poner distintos componentes en una página a través del uso de etiquetas.

Modelos de Programación II - eje 2 analicemos la situación 7

 • Enlazar directamente en el servidor eventos que se generan por componentes que
incluyen la programación de la aplicación.

• Lograr relacionar elementos de la interfaz de usuario en una página haciendo uso

de los datos del servidor.

• Desarrollar una interfaz de usuario compuesto por componentes extensibles y re-

utilizables.

• Guardar y restaurar los estados de la interfaz de usuario más allá de la duración

de las solicitudes.

Lectura recomendada
Lo invitamos a la página principal del eje
para realizar la lectura complementaria:

Introduction to JavaServer Faces (JSF)

Development

Elena Lowery, IBM Corporation

Frameworks tipo RIA con base en el servidor

Desde hace varios años se han vuelto populares las aplicaciones orientadas a la web
que manejan una única página, diferenciándose de las soluciones de software tradi-
cionales que se basan en la navegación de múltiples páginas. Las primeras intentan
simular el comportamiento del software de escritorio y se denominan RIA (Rich Internet
Applications).

Entre los pioneros en la promoción de este tipo de soluciones se encuentra Google,

con ejemplos puntuales como lo es Google Maps. Esa aplicación hace uso de JavaScript
intensivamente para seleccionar opciones como imprimir, enviar, o simplemente para
interactuar con el mapa. Dichas acciones, en su totalidad, se llevan a cabo en un sitio
único del navegador. Normalmente en los programas tradicionales, las solicitudes que
se hacen al servidor permiten la generación de un nuevo archivo HTML. A continuación,
en la parte izquierda, se describe el modelo.

Modelos de Programación II - eje 2 analicemos la situación 8

 Figura 2. Descripción del funcionamiento de las aplicaciones RIA
Fuente: http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion01-apuntes.html

Posteriormente al servidor se le continúan realizando solicitudes de tipo HTTP, pero

el navegador no es quien realiza directamente esta tarea, sino conjuntos de funciones
JavaScript que residen en la página. Esas funciones hacen el envío de la solicitud y sus
correspondientes valores al servidor. Este retorna estos datos en un formato específico
(XML, JSON o un texto). Las funciones tipo JavaScript formatean estos datos en el nave-
gador y plasman en la pantalla los valores, modificando el debido árbol de naturaleza
DOM. Por ende, el servidor tiende a que no se genere un nuevo archivo de página, sola-
mente los datos. Al enfoque se le denomina asynchronous JavaScript and XML (Ajax).

Entre los frameworks tipo JavaScript más conocidos está jQuery, el cual facilita la
tarea ardua de hacer la correspondiente definición de la interfaz de usuario del software.
Sin embargo, el testeo y mantenimiento del código tiende a hacerse complicado. Aquí
participan varios componentes: en primera instancia las páginas con contenido HTML
en las que se encuentra inmerso el código JavaScript y la comunicación con el servidor.
También suele hacerse complicado reciclar y por ende compartir la programación que ha
sido escrita en JavaScript con diferentes sitios y comunidades de desarrolladores.

Modelos de Programación II - eje 2 analicemos la situación 9

 Una opción eficiente a la generación de código en JavaScript son los llamados frameworks
RIA, los cuales se basan en el servidor y por tanto los desarrolladores no requieren escribir
directamente código JavaScript, ya que hacen uso de elementos de altísimo nivel (como
menús desplegables, paneles y combos), en los cuales el servidor incluye en los sitios resul-
tantes. Esos atributos son los componentes tipo framework, para el caso GWT (Google Web
Toolkit), JSF (JavaServer Faces) o ZK.

Es aquí entonces donde el desarrollador genera una interfaz de usuario haciendo uso de
un lenguaje de elementos específicos. El resultado se almacena en el servidor como una
página de texto. En el momento en el que el servidor recibe una solicitud, debe procesar la
página y generar otra que contenga aquellos componentes de la interfaz usando un formato
JavaScript y HTML, este es enviado al navegador como respuesta a la solicitud inicial.

Para que JSF2 defina la correspondiente interfaz, debe hacerlo con archivos de página
que tengan formato XHTML con diferentes tipos de marcas o etiquetas. Esas páginas son
denominadas sitios JSF o páginas. La siguiente figura muestra con simplicidad, como fun-
ciona JSF en la generación de un sitio o página por vez primera.

Figura 3. Descripción del funcionamiento de las peticiones en aplicaciones tipo RIA

Fuente: http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion01-apuntes.html

Modelos de Programación II - eje 2 analicemos la situación 10

 El navegador lleva a cabo una solicitud a
una URL específica, en la cual se encuentra
el sitio JSF que desea mostrarse. Un archivo
tipo servlet denominado motor de JSF y que
se encuentra en el servidor, es el que logra
recibir la petición para encargase de cons-
truir un árbol de componentes teniendo
como referencia el archivo JSF que es soli-
citado. Dicho árbol es capaz de replicar la
correspondiente composición del sitio JSF
original, representando la estructura propia
del sitio que deberá retornarse al navega-
dor, haciendo uso de Java Object. En caso
de definirse un componente de tipo menú
en la página JSF con la correspondiente
etiqueta <h:selectOneMenu>. Al interior del
árbol deberá construirse un componente
tipo Java de la respectiva clase javax.faces.
component.html.HtmlSelectOneMenu.
¡Recordemos que!
Al construirse dicho árbol, el código Java
debe ejecutarse en el servidor y de esta
manera completar los elementos del
árbol de componentes con los respecti-
vos valores de la solución. Finalmente, es
generada la página HTML que es enviada
nuevamente al navegador.
una clase de Java, de esta manera se define
lo que comúnmente se conoce como bean
gestionado.
En el momento en que el documento es
mostrado en el navegador, los usuarios tra-
bajan con ella (para el caso, escribiendo en
un campo el tipo texto, pulsando un botón,
o seleccionando una opción de un menú
desplegable). Aquí es el momento de uti-
lizar el enfoque de Ajax. Sus componentes
están construidos con código JavaScript
que tiene como tarea administrar toda
la interacción y enviar al servidor espe-
cíficamente las solicitudes. Las solicitudes
no deben generar una página nueva. En
varias ocasiones basta con cambiar algún
componente del DOM de la actual página,
manteniendo un enfoque parecido al de
Ajax. A continuación, se muestra, la des-
cripción de cómo se lleva a cabo la actua-
lización de un sitio tipo JSF.

Los componentes deberían recoger y

mostrar datos obtenidos y enviados a la
aplicación. A este proceso se le conoce
como data binding o ligado de datos. En los
frameworks que se basan en el servidor, el
ligado es bastante sencillo ya que los datos
y la respectiva definición de la interfaz de
usuario se encuentran en un solo sitio.

Para JSF2 la manera de ligar datos aso-

ciada a la interfaz es por medio del uso de
la anotación @ManagedBean al interior de

Modelos de Programación II - eje 2 analicemos la situación 11

 Figura 4. Actualización de un sitio tipo JSF
Fuente: http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion01-apuntes.html

El servidor se encarga de recoger la petición, procesarla y recuperar el árbol de compo-

nentes del sitio. Además, debe generar unos valores formateados en XML que son devuel-
tos al usuario (cliente). Ya en este punto, el código JavaScript es capaz de procesarlos para
posteriormente actualizar el DOM de la página. Algunas ventajas de este desarrollo, que
se basa en el servidor frente a la generación de código directo en JavaScript, se puede
destacar de la siguiente forma:

• Asume atributos de portabilidad para hacerse compatible de forma sencilla con

diferentes navegadores y plataformas (móviles).

• Más simple al utilizarse: es bastante sencillo acceder a los objetos de los datos y
negocio a partir de la presentación.

• Amplia seguridad y robustez.

• Al momento de realizar mantenimientos, pruebas o modificaciones se realizan de

manera más fácil.

Atributos de JSF

Es claro que JSF está dentro del marco de los framework MVC, el cual se basa en el
API de servlets y brinda distintos elementos en forma de marcas definidas al interior de
páginas con formato XHTML a través del framework Facelets. Este último se ha definido en
la especificación 2 de JSF como el componente principal que brinda atributos de plantillas
y de igual forma de creación de componentes más elaborados o compuestos. Antes de

Modelos de Programación II - eje 2 analicemos la situación 12

la especificación actual, era común utilizar
JSP para estructurar las páginas JSF.
JSF hace uso de las Facelets Page como
objetos tipo JavaBean, modelos, vistas y
también métodos de tipo controladores. Un
Faces Servlet se encarga de realizar todo el
procesamiento de solicitudes HTTP, recibir
los valores de entrada, verificarlos, trans-
formarlos, ubicarlos en objetos del modelo
y llamar a las acciones que el controlador
posee, así como también definir y mostrar
la respectiva respuesta generada haciendo
uso del árbol de componentes.
JSF brinda las características descritas a
continuación:
• Definición de todo el conjunto de in-
terfaces de usuario a través del uso
de vistas que asocian distintos ele-
mentos visuales.
• Conexión de los respectivos elemen-
tos gráficos junto con los valores o
datos de la solución a través de los
cada vez más usados beans de tipo
gestionado.
• Validación automática de la entrada
del usuario, así como la conversión
de datos.
• Interoperabilidad entre diferentes
vistas.
• La internacionalización.
• Desde la especificación 2.0 existe
una estructura básica o modelo de
intercomunicación Ajax entre el ser-
vidor y las vistas.
Como se ha mencionado, JSF debe eje-
cutarse sobre entornos dispuestos bajo la
Modelos de Programación II - eje 2 analicemos la situación
filosofía de servlets y no necesita de servi-
cios adicionales, entonces para la correcta
ejecución de soluciones JSF solo es nece-
sario un contenedor de servlets tipo Jetty
o Tomcat.
Comprender la forma como funciona JSF
es bastante relevante ya que debe compa-
rarse con JSP. Es importante recordar que
los archivos de tipo JSP incluyen senten-
cias HTML que poseen marcas especiales
al igual que sentencias propias de Java. La
página es procesada en un solo paso de
arriba hacia abajo y de esta forma logra
transformase en un servlet. Los componen-
tes JSP van procesándose a medida que van
apareciendo convirtiéndose en código Java,
el cual está incluido en el servlet. Posterior
a la ejecución de la conversión, las solici-
tudes a la página por parte de los usuarios
generan la respectiva ejecución del servlet.
Servlets
Son pequeños programas escritos en Java que admiten
peticiones a través del protocolo HTTP. Los servlets reci-
ben peticiones desde un navegador web, las procesan
y devuelven una respuesta al navegador, normalmente
en HTML. Para realizar estas tareas podrán utilizar las
clases incluidas en el lenguaje Java. Estos programas
son los intermediarios entre el cliente (casi siempre
navegador web) y los datos (BBDD) (Medium, 2017).
JSP
Es un acrónimo de Java Server Pages, que en castellano
vendría a ser algo como páginas del servidor Java. Es,
pues, una tecnología orientada a crear páginas web
con programación en Java (desarrolloweb.com, 2002).
El funcionamiento en JSF es diferente. Un
archivo de este tipo (JSF), de igual forma
contiene un código HTML y marcas espe-
ciales, sin embargo, su procesamiento se
hace más complicado. Una marcada dife-
rencia con JSP son los valores resultantes
de todo el procesamiento al interior del
servidor del sitio cuando se lleva a cabo la
solicitud. JSP colabora para que el sitio sea
procesado y transformado en un servlet. Sin
13
embargo, en JSF el proceso resultante es un tornado al navegador como el ele-
árbol que contiene Java Object que luego mento resultante de la solicitud.
se encarga de generar el respectivo HTML.
• El árbol de elementos JSF es guarda-
HTML do en un buffer, con el objetivo de
Es un lenguaje de programación que se utiliza para el que, en posteriores solicitudes a la
desarrollo de páginas de internet. Se trata de las siglas página, no haya necesidad de gene-
que corresponden a Hyper Text Markup Language, es
decir, lenguaje de marcas de hipertexto (códigofacilito. rarlo nuevamente, sino que se pueda
com, s.f.). utilizar el que ya existe.

En JSP el servlet es el encargado de gene-

En el momento en que el usuario lleva
rar el HTML a través de sentencias incrus-
a cabo la respectiva petición al sitio JSF,
tadas en su código, las cuales se encargan
se llevan a cabo las acciones descritas a
de escribir en el stream de salida. Para JSF,
continuación, teniendo en cuenta el orden
el documento HTML es generado como el
establecido:
resultante de las llamadas a métodos que
realiza el árbol. Una gran ventaja en el
En un modelo cliente-servidor, una petición
es un requerimiento o solicitud que le hace enfoque JSF es que el respectivo proceso
un cliente a un servidor. de renderización de la interfaz de usuario es
Por ejemplo, un servidor web se encarga de
mantener online un sitio web. Un cliente (el
mucho más flexible, ya que también existe
visitante a través de su navegador) solicita la posibilidad de generar con el mismo JSF
que dicho servidor le dé una página web
determinada. Esa solicitud es una peti-
diferentes sentencias de programación
ción (específicamente una petición HTTP) para varios dispositivos. Para el caso, se
(alegsa.com.ar, s.f.).
podría utilizar una misma aplicación JSF
que permita servir archivos de página a
dispositivos móviles y navegadores web.
• El sitio es procesado de arriba hacia
abajo y es generado el respectivo
árbol de elementos JSF que forma
objetos que se programan a partir
del uso de clases del correspondiente
framework.

• Se pueden obtener los datos que in-

trodujo el usuario y de igual manera
es posible modificar los beans que
han sido administrados con ellos.

• Se modifican los elementos con los

datos que provienen de los atributos
de los beans administrados.

• Se solicita a los elementos que sean

renderizados, generando el corres-
pondiente código HTML, que es re-

Modelos de Programación II - eje 2 analicemos la situación 14

 JavaServer Faces: beneficios tecnológicos

Diversas ventajas hacen que JSF sea una tecnología que se ajusta al marco del desa-
rrollo de aplicaciones orientadas a la web, entre ellas pueden mencionarse:

Ofrece una muy bien definida separación entre la presentación

y el comportamiento. El software orientado a la web es construido HTTP
a partir del uso de tecnología JSP. Este consigue en cierta medida Facilita la definición de la
sintaxis y semántica que uti-
la separación. Aun así, una solución JSP no puede mapear solici- lizan los distintos softwares
tudes HTTP, manejar eventos puntuales de elementos o gestionar web (tanto clientes, como
servidores y proxis) para in-
componentes de tipo UI como objetos que tienen un estado al teractuar entre sí.
interior del servidor. Este protocolo opera por
petición y respuesta entre el
cliente y el servidor. A menu-
La separación que se da entre la presentación y la lógica tam- do las peticiones tienen que
bién le permite a cada desarrollador que hace parte del equipo de ver con archivos, ejecución
de un programa, consulta a
trabajo de un proyecto web enfocarse en su parte del proceso, y una base de datos, traduc-
brinda un modelo simple de desarrollo que facilite de manera fácil ción y otras funcionalidades.
Toda la información que
entrelazar las respectivas piezas. Para el caso, los autores de pági- opera en la web mediante
nas que no tienen gran experticia en programación pueden hacer este protocolo es identifi-
cada mediante el URL o di-
uso de las marcas de componentes UI que tiene la tecnología rección (definicionabc.com,
JavaServer Faces, lo cual ayuda a asociar el código de la aplicación s.f.).

desde el interior de la página sin tener que escribir script alguno.

¡Recordemos que!
Una meta clara de JavaServer Faces es la de mejorar los conceptos
familiares capa-web y disadvantage de componente-UI, sin limitar
a una tecnología particular de script o un lenguaje de etiquetas.
Aunque dicha tecnología incluye una librería de etiquetas o mar-
cas JSP personalizadas para representar elementos en un sitio JSP,
los correspondientes API de la tecnología JavaServer Faces se han
construido directamente sobre el API JavaServlet. Esto ayuda en la
realización de algunas cosas como usar una tecnología diferente
en el ámbito de presentación junto a JSP, generar componentes
propios y personalizados, desde las clases de componentes y, de
esta forma, generar salida para distintos dispositivos tipo cliente.
De esta forma, se podrán encapsular muchas otras tecnologías
como Ajax en componentes JSF, haciendo que su uso sea más
productivo y sencillo, ya que el programador ha sido aislado de
ellas (Junta de Andalucía, s.f.).

Modelos de Programación II - eje 2 analicemos la situación 15

 JavaServer Faces brinda una gran varie-
dad de componentes de tipo open-source
para diferentes funcionalidades que se
lleguen a necesitar. Tomahawk de MyFa-
ces y ADF Faces de Oracle son un ejemplo
de dichos componentes. De igual forma,
también existe una cantidad amplia de
herramientas para el desarrollo IDE en JSF,
esto debido a que tiene el estándar de Java.
JavaServer Faces brinda una enriquecida
arquitectura enfocada a la administración
del estado de los elementos que lo com-
ponen, el proceso de los datos, manejar
eventos y validar la entrada del usuario.
IDE
Es un entorno de programación
que ha sido empaquetado como
un programa de aplicación, o sea,
consiste en un editor de código,
un compilador, un depurador y un
constructor de interfaz gráfica.
Los IDE pueden ser aplicaciones
por sí solas o pueden ser parte de
aplicaciones existentes (Ecured,
s.f.).
De igual forma, ofrece una adaptación
eficiente para desarrolladores que estén
hasta ahora incursionando en el mundo
de la programación. No obstante, usar
JavaServer Faces también genera una gran
desventaja: su naturaleza como estándar
hace que JSF no evolucione de manera
rápida como suele suceder en otros entor-
nos como Wicket, WebWork o Spring.
Ciclo de vida
En JSF se le conoce como ciclo de vida al
conjunto secuencial de fases a través de las
cuales debe pasar una solicitud JSF, desde
el momento en que se recibe en el servidor
hasta que es generado el documento HTML
en forma de página.
El servlet implementado por el fra-
mework recibe la solicitud y se encarga del
Modelos de Programación II - eje 2 analicemos la situación
correspondiente ciclo, generando y usando
los objetos Java que representan los respec-
tivos componentes JSF y, de igual forma, los
beans administrados. Existe una marcada
relación entre la generación de sentencias
HTML y estos objetos, la cual es dada a par-
tir del árbol y se constituyen en la base del
funcionamiento eficiente del framework.
A continuación, se describen las fases del
ciclo de vida:
1. Restaurar la vista (restore view). Aquí
se obtiene el árbol que corresponde
a la vista JSF de la solicitud. Si ya se
ha podido generar con anterioridad,
es posible que se recupere, pero si el
usuario está visitando por primera
vez la página, se genera teniendo en
cuenta la descripción dada en JSF.
2. Añadir los datos de la solicitud (apply
request values). Posterior a la obten-
ción del árbol de componentes, de-
ben procesarse todos los valores que
están asociados. Los datos de la soli-
citud son convertidos a tipos de da-
tos Java; sin embargo, para los ele-
mentos que tienen el atributo true,
se validan, pasando a la siguiente
fase.
3. Procesar las validaciones (process
validations). Deben validarse todos
los datos. Si existiesen errores, debe
ponerse un mensaje de error y debe
terminarse el ciclo de vida, pasando
a la renderización de la respectiva
respuesta.
4. Actualizar los valores del modelo
(update model values). Al llegar a
esta etapa, los valores ya se han de-
bido procesar y de igual manera han
debido validarse. Los atributos se ac-
16
 tualizan de los beans administrados que se encuentran en asocio con los compo-
nentes.

5. Invocar a la aplicación (invoke application). En esta fase, los atributos de los beans
que se encuentran asociados a componentes de entrada (input) ya han debido
actualizarse. Se hace un llamado a la acción que ha seleccionado el usuario.

6. Renderizar la respuesta (render response).

Figura 5
Fuente: http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion03-apuntes.html

Al culminar una a una las fases, se debe comprobar si existe cualquier evento que
deba procesarse en esa fase y deberá llamarse a su correspondiente administrador; son
llamados los manejadores de los eventos, quienes deben ser procesados en cualquier
fase. De igual manera, los manejadores pueden pasar a la última fase del ciclo. Esto
con el objetivo de renderizar de forma eficiente el árbol de componentes, haciendo un
llamado al método Render Response que hace parte del FacesContext. También puede
renderizarse el componente que está asociado con el evento y establecer una llamada al
método Response del FacesContext y de esta forma culminar el ciclo de vida.

JSF genera un evento (PhaseListener) al principio y al finalizar cada etapa del ciclo de
vida de la solicitud. Si lo que se busca es capturar el evento, debe definirse la clase que
logre implementar la interfaz PhaseListener y los correspondientes métodos afterPhase
y beforePhase.

Modelos de Programación II - eje 2 analicemos la situación 17


Instrucción
Lo invitamos a la página principal del
eje para observar la infografía.
Creación de proyectos con JSF
Las soluciones de software de tipo JSF
hacen uso de servlets que pueden ejecu-
tarse, por lo general, en un contenedor de
aplicaciones web sin importar su natura-
leza. Puede mencionarse como de los más
conocidos el Tomcat 6.0.x, por ejemplo. No
hace falta un servidor de aplicaciones que
sea compatible con toda la definición Java
EE 5 o 6.
Una aplicación web JSF debe contener
los siguientes elementos:
• Librerías de implementación de JSF.
• Páginas JSF.
• Directivas en el fichero web.xml.
• Fichero de faces-config.xml.
• Clases de Java con los beans gestio-
nados.
Modelos de Programación II - eje 2 analicemos la situación
Creación de servicios web SOAP
Pueden crearse servicios web que
ofrezcan un conjunto de métodos a los
que puedan llamarse a través de RPC, es
decir, desde cualquier lugar que tenga un
acceso a internet haciendo uso de proto-
colos estándar (conocidos como mensajes
SOAP).
Por esto se debe estar en capacidad de
interpretar las aplicaciones en donde se
desarrollen los mensajes SOAP entrantes
ya que de esta forma facilitará el correcto
uso de un método. Luego, deberá utilizarse
el método que se solicitó, y con el respec-
tivo resultado que sea retornado, se deberá
establecer un mensaje tipo SOAP de res-
puesta para asimismo retornarlo al cliente.
¡Recordemos que!
Si el desarrollador tuviese que incluir el código
para la interpretación de los mensajes de
entrada, y tener que generar manualmente
los mensajes de respuesta, la tarea de desa-
rrollo de servicios web no sería una actividad
asequible.
En este punto, si se tuviera que forzar al
desarrollador a construir el mensaje SOAP
de forma manual cada vez que elabore
un servicio web, probablemente cometerá
algún error y no podrá respetar con preci-
sión el estándar SOAP. Aquí, este aspecto se
volvería un gran problema para las tareas
de interoperación de los respectivos servi-
cios web, siendo uno de los atributos que
se persiguen con el uso de esta tecnología.
18
 Para no incurrir en problemas de este
tipo, deben usarse librerías que faciliten
la lectura y/o la generación de mensajes
SOAP para el llamado de métodos de tipo
remoto, para este caso puede usarse la API
JAX-WS.
Si lo que se busca es simplificar la acti-
vidad de desarrollo de servicios orientados
a la web, se cuenta con múltiples herra-
mientas que a partir de la generación de
las clases implementan un servicio que
automáticamente despliega todo el código
necesario para la lectura del mensaje SOAP
de entrada, para luego llevar a cabo la
invocación del método, posteriormente
lograr escribir el mensaje SOAP de salida y
retornarlo al cliente.
Por esto el desarrollador debe siempre
centrarse exclusivamente en si se quiere
denominar “tedioso” el trabajo de pro-
gramar las funcionalidades que involucran
los servicios, olvidando los mecanismos de
estos.
JAX-WS es la librería basada en un pro-
tocolo de Sun Microsystems, sin embargo,
no todos los servidores de aplicaciones
hacen uso de este recurso para la gestión
de los correspondientes servicios web. Para
el caso de Weblogic, que se encuentra defi-
nido a partir de JAX-WS, logra mantener
varias extensiones de tipo propietario sobre
esta API. Es importante entonces centrarse
en el desarrollo de servicios con Glassfish y
Netbeans, siendo el primero el que incor-
pora las versiones más actualizadas de las
librerías estándar.
Modelos de Programación II - eje 2 analicemos la situación
Lectura recomendada
Lo invitamos a la página principal del eje
para realizar la lectura:
Web 2.0: Arquitectura orientada a servicios
en Java (pp. 69-78)
Pablo García, Miguel López, Pedro Castillo,
Jesús González y María García
Servicios web desde la vista del
servidor
Como ya se ha revisado, un elemento
WSDL establece las operaciones al interior
de los servicios web y establece compo-
nentes alrededor del formato de los datos
y requerimientos de transporte haciendo
uso de la red. Por lo general un WSDL no
impone requerimiento alguno alrededor
del modelo de programación del servidor y
mucho menos del cliente.
La definición de servicios web por ejem-
plo para Java EE (JSR-109) establece tres
diferentes maneras de implementar la
correspondiente lógica de negocio de un
servicio web:
• Como un bean de sesión sin esta-
do: al implementar un servicio web
(componente port) debe hacerse a
través de la creación de un bean de
sesión que no posea estado, el cual
incluye los métodos del SEI (Service
Endpoint Interface) de la misma for-
ma como está descrito en la especi-
ficación de EJB 3.0.
• Como una clase Java: para esta si-
tuación debe implementarse el port
como un servlet JAX-WS.
19
 • Como un Singleton Session Bean: aquí debe crearse un Singleton Session Bean el
cual implementa todos los métodos de un SEI teniendo en cuenta lo especificado
en EJB 3.1.

Los componentes de tipo port establecen la vista del servidor de un servicio web. El
port brinda un servicio, el cual está asignado a una dirección física particular establecida
por las características tipo address de la definición <port> de un WSDL.

Un componente Port genera una solicitud de operación establecida en un <portType>

de un WSDL. La correcta implementación del servicio (Service Implementation Bean)
dependerá del repositorio donde se encuentre el componente port, sin embargo, debe
tenerse en cuenta que es una clase Java que logra implementar las correspondientes ope-
raciones o métodos que han sido definidos al interior del SEI (Service Endpoint Interface).

SEI, puede definirse como el mapeado java del <portType> y <binding>, el cual se ha
asociado a un <port> de un WSDL. Los servicios web pueden definirse como el conjunto
de elementos tipo Port que se distinguen particularmente por su dirección física, los
cuales deben mapear en componentes port de manera separada, cada uno con sus
atributos exclusivos, aunque probablemente compartidos, entre estos se encuentra el
Service Implementation Bean. A continuación, se puede ver una vista del servidor el cual
se hace partícipe de un servicio web.

Container

Port Port

Service Service
Endpoint Service Endpoint Service
Interface Impl Interface Impl

Port

Service
Endpoint Service
Interface Impl

Figura 6. Vista del servidor que se hace partícipe de un servicio web

Fuente: propia

Modelos de Programación II - eje 2 analicemos la situación 20

 Un port y propiamente su ciclo de vida
se controla en completitud por el conte- Instrucción
nedor, sin embargo, mantiene el mismo
ciclo que el contenedor tiene. Los ports se Lo invitamos a la página principal del
crean e inicializan a través del contenedor eje para revisar la nube de palabras.
previo a que la llamada inicial, sea reci-
bida en la dirección del <port> del WSDL.
Los ports se destruyen en el momento en
que el contenedor asume que es necesario
Modelo de programación JAX-WS
realizarlo, por ejemplo, si el mismo conte-
nedor es apagado. Implementar un servicio
Construir la correcta implementación
Web JAX-WS se basa principalmente en un
de uno o varios servicios web (web service
contenedor tipo Web, y por tanto deberá
endpoint) dependerá del punto de partida
poder desplegarse al interior de un servi-
el cual podrá definirse por dos puntos de
dor de aplicaciones o en un servidor Web,
inicio: una clase de Java que logra imple-
mientras que las implementaciones EJB,
mentar el servicio web o simplemente un
residen en un objeto EJB y podrá generarse
fichero de tipo WSDL. Al iniciar con una
el respectivo despliegue únicamente en ser-
clase Java, deberán utilizarse herramien-
vidores de aplicaciones.
tas para la generación de los artefactos
necesarios, entre ellos el WSDL del servicio.
Los componentes port establecen aso-
Ahora, si el punto de partida es un fichero
ciaciones a una dirección de puerto (port
WSDL, deberán utilizarse diversas herra-
address por lo general de un WSDL) a través
mientas que permitan generar el SEI (Ser-
de la implementación del servicio (Service
vice Endpoint Interface)
Implementation Bean). Por lo general, el
insumo port “pospone” el establecimiento
Si se inicia con una clase de Java, habrá
de aquellos requerimientos que tiene el
tranquilidad de que la clase que está imple-
contenedor del servicio y que lleva a la fase
mentando el servicio posee los tipos de
de despliegue, logrando indicar los reque-
datos que se requieren. Aun así, el desa-
rimientos en el descriptor del respectivo
rrollador posee menos control sobre la
componente. Un contenedor brinda un
estructura XML que se genera. Si se inicia
objeto de escucha (listener), en la dirección
por WSDL y el uso de esquemas, el desa-
del puerto (port address de un WSDL) y una
rrollador mantiene un total control sobre el
tarea que le permita “enviar” la solicitud
esquema que se está usando, sin embargo,
a la implementación del correspondiente
tendrá menos control sobre el end-point del
servicio web. El contenedor debe propor-
servicio que se ha generado y por ende de
cionar servicios en el mismo instante en
las clases que se utilizan.
que son ejecutados, ya sean mapeados de
referencias lógicas a referencias de índole
Cuando el punto de partida es una clase
físicas de objetos distribuidos y recursos y
de Java, deben tenerse en cuenta cier-
restricciones de seguridad.
tas restricciones en el momento en que
se implemente un servicio. Una correcta
implementación de un servicio web, hace
referencia a una clase java que tiene en
cuenta las siguientes limitaciones:

Modelos de Programación II - eje 2 analicemos la situación 21

 • La clase deberá estar escrita con javax.jws.Webservice.

• Los métodos pueden anotarse con javax.jws.WebMethod.

• Todos los métodos pueden lanzar excepciones de tipo java.rmi.RemoteException

adicional a las excepciones propias del servicio.

• Los parámetros y atributos de los métodos y tipos de retorno deben ser compati-
bles con JAXB.

• Los parámetros o tipos de retorno deben implementar la interfaz java.rmi.Remote

ni indirecta y mucho menos directamente.

Hasta aquí es importante recordar que la generación de aplicaciones en Java es una

tarea que obliga al desarrollador no solo a entender el lenguaje en sí, sino a atender
otros criterios de la tecnología y la informática. Es importante siempre tener presente el
concepto de integralidad y ver las aplicaciones como un conjunto de componentes que
se desarrollan con el propósito de suplir una necesidad o minimizar el impacto de ciertas
situaciones adversas al interior de las organizaciones.

Instrucción

Finalmente, lo invitamos a la página principal del

eje para ver el videorresumen y realizar la prueba
objetiva.

Modelos de Programación II - eje 2 analicemos la situación 22

 Bibliografía

Azpitarte, R., et ál. (2009). Introducción a la Programación Orientada

a Objetos con Java. Departamento de Sistemas Informáticos y
Computación. Valencia: España: Universidad Politécnica de Valencia.

Carcedo, C. (2013). Tutorial de instalación y configuración de

NetBeans. Recuperado de http://www.migadepan.es/wp-content/
uploads/2012/09/Tutorial_PROGRAMACION01.pdf

Deitel, P., y Deitel., H. (2008). Java. Cómo programar. Recuperado de

BIBLIOGRAFÍA

https://docs.google.com/file/d/0B1znxPN5ACgSbHhVU1RaVFh0cVU/
edit

Junta de Andalucía. (s.f.). JavaServer Faces(JSF). Recuperado de http://

www.juntadeandalucia.es/servicios/madeja/contenido/recurso/101

Polo, M., y Villafranca, D. (2015). Introducción a las aplicaciones web

con Java. Recuperado de http://www.inf-cr.uclm.es/www/mpolo/
asig/0708/tutorJavaWeb.pdf

Universidad de Alicante. (2014). Título de Experto Universitario en Desarrollo

de Aplicaciones y Servicios con Java EE. Recuperado de http://www.
jtech.ua.es/j2ee/publico/jsf-2012-13/sesion01-apuntes.html