Una Arquitectura de Integración de Información Basada en

Portlets para un Portal Empresarial

Enrique Ruiz Díaz, Giner Alor Hernández

División de Estudios de Posgrado e Investigación, Instituto Tecnológico de Orizaba.
Veracruz, México
eruiz99@yahoo.com.mx, galor@itorizaba.edu.mx

Resumen
Los portales de Internet de la primera generación presentaron dificultades para integrar
aplicaciones heterogéneas y/o fuentes de datos en una manera consistente. Para superar esta
limitante, surgieron los portales de segunda generación que se basan en estándares con
aceptación creciente entre proveedores de contenidos y aplicaciones. Los portales de
segunda generación se constituyen por portlets –mini-aplicaciones Web interactivas, locales
o remotas al portal. Sin embargo, se requiere de una arquitectura de integración de
información que permite aprovechar, plenamente, sus ventajas. En este sentido, este trabajo
presenta una arquitectura de integración de información basada en portlets para un portal
empresarial de segunda generación.

1. Introducción
Las tecnologías para los portales de primera generación presentaron importantes
desventajas ya que requerían de enormes esfuerzos de programación e inversión en tiempo
para acceder a recursos e información provistos por terceras partes [1]. Para superar estas
desventajas, surgieron los portales de segunda generación. Este tipo de portales se basan en
estándares con aceptación creciente entre proveedores de contenidos y aplicaciones para los
portales, lo cual permite apoyar a estos como intermediarios múltiples [2].
Entre las principales tecnologías para portales de primera generación están: CGI, PHP,
ASP, JSP, Servlets, por mencionar solo algunas. Los primeros servidores HTTP no incluían
ningún mecanismo para generar respuestas dinámicamente, por lo tanto se crearon interfaces
para comunicar el servidor con programas externos que implementaran dicha funcionalidad,
estas interfaces se denominaron CGI [3]. Sin embargo, el gran inconveniente de la tecnología
CGI es el rendimiento, ya que por cada petición se crea una nueva copia del programa en la
memoria del servidor. Así, si acceden muchos usuarios de forma simultánea se produce una
disminución en la eficiencia de dicho servidor [4].
La tecnología PHP se usa generalmente para la creación de contenido para sitios Web.
PHP se trata de un lenguaje que se interpreta para usarse en la creación de aplicaciones para
servidores o creación de contenido dinámico para sitios Web [4]. Sin embargo, la
programación orientada a objetos en versiones anteriores de PHP carecía de potencia [5].
Además, otro inconveniente de PHP está en relación a cierta complejidad en sus métodos de
instalación, ya que se puede instalar PHP sobre un servidor bien como un interprete CGI o
como un módulo de Apache [6].
La tecnología ASP (Active Server Pages) se desarrolló por Microsoft. Esta tecnología
aporta capacidad operativa a las páginas Web, combinando HTML con un lenguaje de
secuencia de comandos o lenguaje script. El código contenido en estos scripts se ejecuta en el
servidor y el navegador del cliente tan sólo recibe páginas HTML, lo que convierte a ASP en

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 una tecnología válida para cualquier tipo de navegador [4]. Sin embargo, aunque se
desarrollaron herramientas para portar ASP a otras plataformas, la potencia de ASP está en el
uso de objetos Active-X (VBScript incluye soporte para acceso a componentes Active-X), que
sólo están disponibles para sistemas operativos Windows [3].
La tecnología de servlets se constituye por clases Java, embebidas dentro del servidor Web
y que se utilizan para extender la capacidad del servidor. La API de servlets provee clases e
interfaces para responder a requerimientos; en particular para las aplicaciones que se ejecutan
en servidores Web. La API define clases de servlet específicas para requerimientos HTTP [7].
Sin embargo, dado que la tecnología de servlets deben mantener plantillas de código HTML
dentro del programa java, esto hace a la tecnología de servlets compleja de entender y
propensa a errores [8].
La tecnología JSP (Java Server Pages) es una extensión de los servlets que desarrolló Sun
como alternativa a la tecnología ASP de Microsoft; básicamente, permite la introducción de
código Java dentro del código HTML. Dicho código Java puede llevar a cabo diversas tareas,
como por ejemplo utilizar servicios que se proporcionan por servlets [9]. Los elementos JSP
se usan para una gran variedad de propósitos como recuperar información de una base de
datos o registrar preferencias del usuario [8]. Sin embargo, JSP no permite satisfacer el
requerimiento de acceso a recursos e información que se proporcione por terceras
partes, por ejemplo, de un proveedor de noticias.
Con el fin de superar las desventajas ofrecidas por las tecnologías de primera generación,
surgió la tecnología de portlets. Los portlets son la tecnología para portales de segunda
generación. Los portlets son componentes de software que proveen una completa interfaz de
usuario a través de la cual el portlet interactúa con el usuario y despliega contenido [2]. El
contenido que se genera por un portlet se conoce como fragmento o código de fragmento.
Este es el código HTML que se generó a partir del código de despliegue del portlet. El
usuario final visualiza el portal como una serie de portlets que se presentan en una sola
página, que se producen a partir de solicitudes hechas a un portal [10].
Los portlets se basan en estándares con aceptación creciente entre proveedores de
contenidos y aplicaciones; sin embargo, se requiere de una arquitectura de integración de
información que permite aprovechar plenamente las ventajas de los portlets. Por tanto, este
trabajo presenta una arquitectura propia de integración de información basada en portlets para
un portal de entretenimiento. Dicho portal ofrece dos modos de operación: un modo portal de
Internet y un modo Proxy.
A continuación, se presenta la arquitectura que aporta este trabajo.

2. Arquitectura basada en portlets y su funcionamiento

En nuestra arquitectura, los portlets y los servicios Web tienen una estrecha relación. Los
servicios Web, a través de sus protocolos y estándares: SOAP (Simple Object Access
Protocol, protocolo de acceso de objeto simple), WSDL (Web Services Description
Language, lenguaje de descripción de servicios Web) y UDDI (Universal Description,
Discovery, and Integration, descripción, descubrimiento e integración universal), proveen un
marco de trabajo inter-organizacional. SOAP, WSDL y UDDI tienen funciones específicas
que ofrecen a los servicios Web: (1) SOAP para comunicarlos, (2) WSDL para una formal y
entendible descripción para la computadora; y (3) UDDI como un registro de descripciones
[11]. La arquitectura que se propone trabaja con SOAP y WSDL.
En contraste a los portlets implementados localmente, los servicios Web representan
portlets inter-organizacionales. Sin embargo, los servicios Web no incorporan funciones de
integración de presentación, las cuales son pertinentes a los portlets. En consecuencia, los

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 servicios Web orientados a presentación representan portlets remotos. Esto se da a través de
la inclusión de fragmentos de presentación que ya se estandarizaron para asegurar un aspecto
uniforme en el portal. De hecho, el estándar WSRP (Web Services for Remote Portlets,
servicios Web para portlets remotos) trabaja en este sentido [12].
Basándose en los elementos anteriores se desarrolló una arquitectura propia para la
integración de información basada en portlets para un portal empresarial. Dicha arquitectura
es la principal contribución de este trabajo y se enfoca hacia la industria del entretenimiento,
por lo que se ofrecen servicios Web de esta naturaleza. La arquitectura tiene dos modos de
operación: 1) modo portal de Internet y, 2) modo Proxy, la visión global se muestra en la
figura 1.
En la figura 1 se presenta un enfoque a los componentes generales de nuestra arquitectura
de portal. En nuestra arquitectura los clientes y los proveedores de servicios son elementos
externos. Por una parte, los clientes que acceden al portal para consumir los servicios tanto
del modo Proxy como del modo portal de Internet y, por otra parte, los proveedores que
suministran los servicios para ambos modos. Además, se aprecia una relación entre los
componentes: modo portal de Internet y modo Proxy porque los servicios son los mismos en
ambos casos. Dada la complejidad del componente denominado modo Proxy, en la figura 2 se
presenta su arquitectura particular.

Figura 1. Aspecto general de la arquitectura

La inclusión de dos modos de operación a nuestro portal lo hace más atractivo al cliente.
Porque mientras que el modo portal de Internet otorga al cliente un rol de simple usuario
final, el modo Proxy convierte al portal en proveedor de servicios, por lo que otros sistemas
pueden utilizar los servicios Web provistos por el portal bajo esta modalidad.
La operación del modo portal de Internet ocurre a través de un navegador de Internet. El
cliente accede al portal y allí cada portlet presenta, al cliente, una interfaz de usuario para
ofrecer un determinado servicio Web de entretenimiento. El cliente usa los portlets como un
usuario final cualquiera.
En el modo Proxy se ofrece a los clientes un servicio de intermediario para los servicios
Web. El cliente desarrolla una aplicación Web cliente para consumir el servicio Web que el
portal ofrece. En este caso, la intermediación tiene la ventaja de otorgar al cliente información
con el formato de respuesta más conveniente a sus necesidades. El cliente conoce dicho
formato de respuesta a través del documento WSDL (el cual describe cómo interconectar con
servicios que se basan en lenguaje de marcado XML, es decir, un servicio Web) que el portal,
previamente proporcionó. La aplicación que el cliente desarrolle, para el documento WSDL
que obtuvo del portal, permite consumir el servicio Web del portal en modo Proxy. Esto se
ilustra en la Figura 2. Para lo cual, cada componente del modo Proxy, tiene una funcionalidad
específica que se describe a continuación.

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 • El analizador de mensajes SOAP: para su modo Proxy, el portal proporciona un
documento WSDL al cliente. El analizador de mensajes SOAP trabaja basándose en
dicho documento. La finalidad del analizador de mensajes SOAP es establecer
comunicación entre la aplicación del cliente y el portal en su modo Proxy. Y con ello,
atender la solicitud del método invocador de la aplicación del cliente. Para ello,
analiza dicho documento WSDL con la finalidad de determinar el método invocador
y sus argumentos.
• El selector de servicio: determina que portlet implementa la funcionalidad que
se demanda en la comunicación que estableció el analizador de mensajes SOAP.
• El contenedor de portlets: es un recipiente lógico que controla el ciclo de vida de
los portlets y provee, a éstos, con recursos e información acerca de su ambiente. Para
los portales que se basan en Java este componente se basa en el estándar JSR 168
(Java Specification Request, solicitud de especificación Java). El estándar JSR 168 se
concreta en Apache Pluto [13].
• El invocador: el proveedor externo del servicio Web proporcionó un documento
WSDL para el portal en su modo Proxy. El invocador trabaja basándose en dicho
documento. La finalidad del invocador es establecer comunicación, del portal, con el
servicio Web del proveedor externo. Por ello, emplea el método correspondiente con
sus respectivos argumentos, si los tiene.
• El analizador de respuesta: este trabaja basándose en el documento WSDL que
proporcionó el proveedor externo del servicio Web, al portal en su modo Proxy. Una
vez que se invoque dicho servicio Web, su finalidad es recolectar la información de
respuesta neta. Es decir, de la información de respuesta se extraen datos que ya no
interesan, relativos al uso de los estándares de servicios Web.
• El constructor de respuesta: Este envía la información de respuesta al cliente. Es
decir, debe responder a la aplicación del cliente para el portal, en su modo Proxy,
conforme al servicio Web que demandó. Por ello: (1) formatea el dato o datos que se
requieren como respuesta, (2) crea un mensaje SOAP; y (3) envía la respuesta al
cliente a través del mensaje SOAP que creó.
En la figura 2, se visualizan una serie de pasos que describe la interacción entre cada uno
de los componentes de la arquitectura. La forma de operar de estos componentes de portal en
su modo Proxy es la siguiente:
Paso 1. A través de un mensaje SOAP la aplicación del cliente envía la solicitud. Esta se
recibe por el analizador de mensaje SOAP del portal en modo Proxy. Cuya finalidad es
comunicar los objetos que se ejecutan en ambas partes.
Paso 2. Una vez que se establece la comunicación interviene el selector de servicio. Este
analiza los parámetros de solicitud para determinar qué portlet implementa la funcionalidad
requerida y lo busca en el contenedor de portlets.
Paso 3. El contenedor de portlets provee el portlet correspondiente.
Paso 4. El portlet usa el invocador, el cual a través de un mensaje SOAP envía la petición
de servicio al proveedor externo de servicio Web.
Paso 5. Dicho proveedor recibe la solicitud, la procesa y a través de un mensaje SOAP
envía la respuesta al portal.
Paso 6. Esta respuesta la recibe el analizador de respuesta. Éste, análogamente al
analizador de mensaje, requiere establecer la comunicación entre el proveedor y el portal en
modo Proxy. Posteriormente, el analizador de respuesta tiene como función principal extraer
los elementos de respuesta. Esta se pone a disposición del constructor de respuesta.

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 Paso 7. El constructor de respuesta procede a darle el formato que se especificó al cliente
en el documento WSDL. A continuación, envía la información de respuesta a la aplicación
del cliente a través de un mensaje SOAP.

Figura 2. Arquitectura del portal en modo proxy

A continuación, se presenta un caso de estudio para la búsqueda de programación de cines

y búsqueda de productos en Amazon.com. Este caso de estudio permite visualizar la
funcionalidad del portal desarrollado basado en portlets.

3. Caso de estudio

El caso de estudio describe cómo el portal de segunda generación facilita el acceso a

información proveniente de fuentes de datos heterogéneas. Se hace mención que nuestro
portal, a través de sus portlets, emplea servicios Web de entretenimiento, correspondiente a
los Estados Unidos de América porque en nuestro país (México) estos servicios no se
proporcionan.
Para este caso de estudio se describe el siguiente escenario:
1. Suponga que un usuario desea conocer la programación de películas para un
determinado lugar de los Estados Unidos de América y buscar información
referente a compra de películas en DVD’s.
2. Suponga que existen varios sitios o portales dispersos que ofrecen la
programación de películas. Así también, varios sitios o portales dispersos que
ofrecen información referente a compra de películas en DVD’s.
En este escenario, ¿cómo puede el usuario encontrar la programación de películas y a la vez
buscar dichos DVD’s sin visitar tantos sitios o portales dispersos?.

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 Para contestar la pregunta descrita en el escenario, es necesario que el usuario utilice
nuestro portal. En la Figura 3, se muestra una interfaz gráfica del portal. En este portal se
encuentran dos portlets, denominados: Theaters y Amazon.com. Por una parte, el portlet
Theaters (el cual se muestra en estado de presentación, en la figura 4a, y en estado de
ejecución, en la figura 4b y 4c) presenta el servicio de entretenimiento consistente en la
programación de películas que ofrecen los cines para un determinado código postal de los
Estados Unidos de América. Por otra parte, el portlet Amazon.com (este se muestra en la
figura 5 en estado de presentación y en estado de ejecución) busca productos en Amazon.com
en treinta líneas diferentes de productos.
El portlet Theaters solicita, al usuario, el código postal de los Estados Unidos de América
sobre el que interesa realizar la búsqueda y solicita que se seleccione un radio de acción
(perímetro que cubre la búsqueda). Después, solicita que elija entre tres opciones de consulta:
(1) general, (2) por cine; y (3) por película. En cualquiera de las tres opciones, la búsqueda
comprende al código postal y al radio de acción que el usuario proporcionó. Si elige la
primera opción, el usuario debe seleccionar la casilla “Everything” y oprimir el botón “get
ShowTimes”. Inmediatamente, el portlet despliega una tabla con la programación de
películas. Si elige la segunda opción, el usuario debe seleccionar la casilla “By theater” y
oprimir el botón “get ShowTimes”. Luego, se despliega la lista de cines. Entonces, el usuario
debe elegir un determinado cine y oprimir el botón “Show”. En seguida, se presenta una tabla
con la programación de películas del cine que seleccionó. Si elige la tercera opción, el
usuario debe seleccionar la casilla “By film” y oprimir el botón “get Show Times”.
Inmediatamente, el usuario visualiza una lista con las películas. Entonces, el usuario debe
elegir una determinada película y oprimir el botón “Show”. Enseguida, se despliega al usuario
una tabla con todos los cines que ofrecen esa determinada película.
El portlet Amazon.com solicita al usuario una palabra clave relacionada con la búsqueda
del producto que desea y solicita que selecciona una línea de productos. En este caso, si el
usuario desea DVD’s de la película “Matrix", debe escribir como palabra clave el nombre de
esta película, luego debe seleccionar la línea de producto “DVD”. Una vez hecho lo anterior,
el usuario debe oprimir el botón “Show Products”, entonces, se despliega una lista de
productos acordes.
El portal es de gran ayuda al usuario, porque éste no necesita visitar gran cantidad de sitios
o portales para encontrar la programación de películas de interés y búsqueda de productos en
Amazon.com. El usuario, tampoco necesita saber qué empresas u organizaciones proveen los
servicios Web que los portlets presentan. Así también, no necesita conocer las fuentes de
datos, posiblemente heterogéneas, que proveen a los servicios Web con la información
necesaria. En este sentido, el usuario delega al portal la tarea del consumo de dichos servicios
Web a través de los portlets. En este escenario, el usuario solicita un servicio de
entretenimiento a través de la interfaz que los portlets presentan. Cada portlet recibe la
solicitud e, internamente, ejecuta el consumo del servicio Web correspondiente. Cuando el
servicio Web provee al portlet con la información de respuesta, el portlet, ordenadamente, la
presenta al usuario.
Lo anterior es posible porque para cada portlet se implementó la aplicación Web para
consumir el servicio Web correspondiente. Esto gracias al documento WSDL que la empresa
proveedora del servicio Web proporciona para este objetivo. En el documento WSDL se
almacena información relativa al servicio Web, tal como los tipos de datos que se requieren y
la forma de proporcionarlos. El documento WSDL se escribe en lenguaje XML y especifica
al protocolo SOAP para la comunicación. SOAP permite que dos programas se comuniquen
de una manera similar, técnicamente, a la invocación de páginas Web.

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 Figura 3. Portal con cuatro portlets

(a) En presentación. (b) En ejecución, primera parte.

(c) En ejecución, segunda parte

Figura 4 El portlet Theaters en presentación y en ejecución

Por otra parte, el portal es adaptable y presenta información de fuentes de datos

heterogéneas consistentemente. Es adaptable porque, durante el diseño del portal, a los
portlets se asigna la distribución que se considere más conveniente. Por otra parte, del
lado del usuario, los portlets son adaptables porque cada portlet presenta varias formas
de operación: (1) minimizar, (2) normalizar, (3) maximizar; y (4) cerrar. Además un

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 botón para el modo edit (edición) y para el modo view (vista). En el modo edit se tiene
la opción de configurar el ancho y alto del portlet e incluso de modificar el tipo de
servicio actual del portlet por el de otro portlet. Además, el portlet tiene acceso a
fuentes de datos y lo hace de una forma consistente porque se basa en estándares:
WSDL y SOAP. Estos son de aceptación creciente entre proveedores de contenidos y
aplicaciones.

Figura 5. El portlet Amazon.com en presentación y en ejecución

En la siguiente sección, se presenta otros trabajos que utilizan portlets en sus arquitecturas.

4. Trabajos relacionados

A continuación se presenta, brevemente, la problemática que motivó el desarrollo de otras

arquitecturas y una breve descripción de estas arquitecturas. Además, se analiza brevemente
las diferencias de cada una de estas arquitecturas contra la nuestra. En el análisis de estas
diferencias, dado que el uso de portlets y del servidor de portal son elementos típicos para
nuestra arquitectura y la de estos trabajos relacionados no se hace énfasis en ello.
En [14] se expone que Healthcare@Home es un proyecto de investigación que implementa
un prototipo de entrada o salida de datos a través de dispositivos móviles y/o servidores de
red dedicados para uno o más motores de análisis de datos. Su arquitectura consta de un
servidor de portal que provee una interfaz segura y adaptable entre el usuario final
experimental (clínicas, pacientes e investigadores) y el middleware El proyecto creó varios
portlets para cada rol de usuario que identificó previamente, y los hospedó en el mismo
ambiente de servidor de portal. Además, consta de un servidor de procesos y una base de
datos para almacenar información del paciente en una localidad geográfica particular. En
nuestra propuesta, el dominio de aplicación es diferente. Además, nuestro enfoque no
presente algún tipo de middleware.
En [15] se presenta una experiencia en diseño y construcción de un portlet para OGSA-
DAI y en probar el acceso de servicio grid a base de datos relacionales por medio de un
resumido volumen de trabajo de bases de datos. OGSA-DAI provee una extensión para el
marco de trabajo OGSA a través de permitir el acceso y la integración de datos que se
controlan en fuentes de datos heterogéneas. Su arquitectura tiene elementos tales como: (1) un
contenedor de servlets, Tomcat, que sirve con un contenedor de hospedaje de servicio Web
tanto para OGSA-DAI y el portal Alliance, (2) una implementación de portal, Jetspeed, que
provee un API para desarrollar portlets, (3) el portal Alliance en el cual reside el portlet
OGSA-DAI; y (4) grid OGSA-DAI que permite implementación de referencia middleware

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 permitiendo acceso y control para fuentes de datos externas, entre otros. Este trabajo se
enfoca más al área de computación grid que utiliza los servicios grid, mientras que nuestra
propuesta se sitúa en el cómputo orientado a servicios que utiliza servicios Web.
En [16] se muestra un framework para desarrollar un sistema de portal de salud que
depende de la noción de servicios diferenciados (por ejemplo, servicios que proveen un
comportamiento común con calidad de servicio variable) para sobrevivir a cargas de tráfico
inesperadas y disminución en servicios Web fundamentales. Su arquitectura tiene como
objetivo manejar y supervisar el uso de varios servicios. Esta arquitectura presenta al centro al
servidor de portal, los clientes se presentan a la izquierda y a la derecha, se muestran los
servicios que se ejecutan en máquinas separadas. En su framework, el servidor de portal se
crea de un sistema de hospedaje de portal, supervisión automática y varias envolturas de
portlet de servicios de salud (un portlet interpreta uno por servicio). Al igual que en [14], una
diferencia importante es el dominio de la aplicación.
En [17] se indica la problemática de una corporación en la cual se acumula un largo
número de documentos de interés para sus ingenieros, lo que hace imposible, a éstos,
examinarlos a fondo. Este trabajo presenta un prototipo de repositorio de documentos basado
en conocimiento para una aplicación. Su arquitectura emplea los estándares Web existentes
tanto como es posible, para maximizar el re-uso de herramientas, compatibilidad y
portabilidad. Un portal Web provee una interfaz de usuario integrada, y manejadores de
autentificación y flujos de trabajo. La interfaz de usuario la forman de una serie de portlets.
Sus portlets acceden a uno o más servicios Web. Este trabajo se sitúa más en el uso de
técnicas de recuperación de información mediante el uso de servicios Web. Por el contrario,
nuestro trabajo se centra en la re-usabilidad de los servicios Web mediante el uso de portlets.
En [18] se enuncia que su producto, denominado ClayNet, es una plataforma que
contribuye a la funcionalidad que se desea para procesos e-learning (entorno de educación a
distancia online), se integra en un portal y se constituye por componentes ensamblados con
estructura independiente que se definen como portlets. Su arquitectura presenta al conjunto de
portlets en el nivel más alto. Sus portlets engloban una serie de clases que cumplen con la
especificación JSR 168 y con un conjunto de elementos JSP. Estos elementos se gestionan
por el contenedor de portlets. Los portlets de ClayNet también se apoyan en una base de
datos externa para realizar la persistencia de datos. El sistema gestor de base de datos que
utilizan es MySQL. Este es un trabajo similar al enfoque propuesto en este artículo. Existe
una similitud en el uso de un contenedor de portlets. Sin embargo, una diferencia importante
reside en el uso de los estándares para portlets. Nuestro enfoque utiliza WSRP en
combinación con JSP en vez de JSR 168. Finalmente, nuestra propuesta no utiliza una base de
datos para la persistencia de la información.

5. Conclusiones y trabajo a futuro

Este trabajo presenta y contribuye con una arquitectura de integración de información

basada en portlets para un portal empresarial de segunda generación con la funcionalidad de
la industria del entretenimiento. El portal de segunda generación ofrece dos modalidades de
operación: portal de Internet y modo Proxy. Mediante los portlets, es posible combinar
información proveniente de fuentes de datos dispersas y heterogéneas.
Actualmente, se están considerando otros casos de estudio para enfatizar la importancia de
una arquitectura basada en portlets. Finalmente, también se esta considerando establecer
mecanismos de composición de portlets con el fin de orquestar información provenientes de
dos o más portlets.

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.
 Referencias
[1] T. Schaeck. “Web Services for Remote Portals (WSRP) Whitepaper”. Oasis. September 2002. pp:
1-18.
[2] F. Bellas. “Standars for Second-Generation Portals”. IEEE Internet Computing. vol. 8, no. 2,
(2004). 54-60.
[3] A. Cubero, y S. Luna. “Servlets y JSP” Departamento de Informática y Automática Universidad de
Salamanca. mayo 2003. pp: 2-17
[4] F. González, M. Cid, y P. Cuesta. “Desarrollo de aplicaciones Web utilizando ASP (Active Server
Pages)” Departamento de Lenguajes y Sistemas Informáticos Universidad de Vigo. NOVATICA 36
Edición digital. jul./ago. 2000 No. 146. pp: 36-39.
[5] Aplicaciones Web. “Modelo de orientación a objetos de PHP 3 y 4”. [En línea]
http://www.aplicacionesweb.cl/content/view/31/2/ [Consulta: 28 Junio 2006].
[6] Security Linux Com. “Securing PHP”. [En línea]
http://security.linux.com/security/04/08/05/203238.shtml [Consulta: 28 Junio 2006].
[7] D. A, Silva, y B. Mercerat. “Construyendo aplicaciones Web con una metodología de diseño
orientada a objetos” LIFIA, Laboratorio de Investigación y Formación en Informática Avanzada.
Facultad de Informática, Universidad Nacional de La Plata, Buenos Aires, República Argentina. Enero
2002. pp: 1-21.
[8] A. Vignaga, y D. Perovich. “Arquitecturas y tecnologías para el desarrollo de aplicaciones Web”.
Universidad de la República, Facultad de Ingeniería, Instituto de Computación Montevideo, Uruguay.
pp: 1-51.
[9] D. Gayo, B. López, L. Vinuesa, J. E. Labra, y J. M. Cueva. “Utilización de software libre como
única tecnología para el desarrollo de portales Web” Universidad de Oviedo, España. Departamento de
Informática. pp: 1-11. [En línea] http://www.di.uniovi.es/~dani/publications/sisoft2001.PDF.
[Consulta: Octubre 2006]
[10] K. Ramírez. “Entendiendo Portales y Portlets: Parte 1 – Creando un portal personalizado” Java
Developer Journal Vol. 9 de 2004. pp: 1-9.
[11] F. Curbera, M. Duftler, and R. Khalaf. “Unraveling the Web Services Web”. IEEE Internet
Computing. (2002) pp: 86-93.
[12] T. Puschmann, and R. Alt. “Process Portals – Architecture and Integration”. Proceedings of the
37th Hawaii International Conference on System Sciences – 2004. IEEE Press. (2004) pp: 1-10.
[13] Apache Pluto. “Welcome to Pluto”. [En línea] http://portals.apache.org/pluto/. [Consulta: Enero
2007].
[14] M. Subramanian, A. Shaikh, O. Rana, A. Hardisty, and E. C. Conley. “Healthcare@Home:
Research Models for Patient-Centred Healthcare Services”. School of Computer Science and Welsh e-
Science Centre Cardiff University, UK. pp. 1-7. [En línea]
http://users.cs.cf.ac.uk/M.Subramanian/publications/Research_models.pdf. [Consulta: Enero 2007]
[15] D. Kodeboyina, and B. Plale. “Experiences with OGSA-DAI: Portlet Access and Benchmark”.
Computer Science Department Indiana University. pp: 1-6. [En línea] http://www-
unix.mcs.anl.gov/~keahey/DBGS/DBGS_files/dbgs_papers/kodeboyina.pdf. [Consulta: Enero 2007]
[16] H. Naccache, G. C. Gannod, and K. A. Gary. “A Self-healing Web Server Using Differentiated
Services”. Dept. of Computer Science & Engineering, Arizona State University. Springer-Verlag
Berlin Heidelber 2006. pp: 203-214.
[17] S. C. Wrong, R. M. Crowder, N. R. Shadbolt and G. B. Wills. “Knowledge Management for a
Large Service-Oriented Corporation”. School of Electronics and Computer Science, University of
Southampton, UK. In Proceedings of the 6th International Conference on Practical Aspects of
Knowledge Management (PAKM), Vienna, Austria, 30 Nov. 2006. pp: 1- 12.
[18] M. A. Conde, J. Carabias, R. M. Martin, I. González, and F. J. Garcia. “Portlet-based architecture
for a LMS: CLAYNET 2.0”. Departamento de I+D+i CLAY Formación Internacional. Virtual Campus
2006 Post-proceedings. Selected and Extended Papers. pp: 181-194 [En línea]
http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-186/17.pdf. [Consulta: Enero 2007]

Karinne Ramírez Amaro, Erik Vladimir Ortega González, Francisco Hiram Calvo Castro (Eds.);
E2C2 2007: Memorias del Primer Encuentro de Estudiantes en Ciencias de la Computación;
(c) Centro de Investigación en Computación del Instituto Politécnico Nacional, México, 2007.