M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
1
INSTITUTO TECNOLÓGICO DE ORIZABA
DIVISIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
“DISEÑO Y CONSTRUCCIÓN
DE UN PORTAL EMPRESARIAL
UTILIZANDO LA TECNOLOGÍA DE PORTLETS“
TESIS
QUE PARA OBTENER EL GRADO DE:
MAESTRO EN CIENCIAS EN
CIENCIAS DE LA COMPUTACIÓN
PRESENTA
LIC. ENRIQUE RUIZ DÍAZ
DIRECTOR DE TESIS
DR. GINER ALOR HERNÁNDEZ
ORIZABA, VERACRUZ, MÉXICO. SEPTIEMBRE 2007
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
2
Índice
Índice ……………………………………………………………………………….. ii
Índice de figuras ……………………………………………………………………. vi
Índice de tablas ……………………………………………………………………... viii
Resumen ……………………………………………………………………………. ix
Introducción ………………………………………………………………………... xi
Capítulo I. Motivación …….....…………………………………………………… 1
1.1. Introducción …………………………………………………………………… 1
1.2. Antecedentes ………………………………………………………………….. 2
1.3. Evolución de las tecnologías de información ………………………………….. 5
1.3.1 Common Gateway Interface (CGI) ……………………………………… 5
1.3.2. PHP ……………………………………………………………………… 6
1.3.3. Active Server Pages (ASP) ……………………………………………... 7
1.3.4. Servlets ………………………………………………………………….. 8
1.3.5. JavaServer Pages (JSP) …………………………………………………. 8
1.3.6. Los Portlets ……………………………………………………………… 9
1.4. Planteamiento del problema …………………………………………………… 11
1.5 Estado del arte ………………………………………………………………….. 13
1.6 Propuesta de solución …………………………………………………………... 21
1.7. Resumen ……………………………………………………………………….. 22
Capítulo II: Tecnología de portlets ………………………………………………. 23
2.1 Introducción ……………………………………………………………………. 23
2.2 Estándares JSR 168 y WSRP …………………………………………………... 23
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
3
2.2.1 Estándar JSR 168 (The Java Portlet Specification, la especificación del
portlet de Java) ……………………………………………………………………...
24
2.2.2 Estándar WSRP (Web Services for Remote Portlets, servicios Web para
portlets remotos) …………………………………………………………………….
27
2.3. Ambientes de desarrollo con soporte para portlets ……………………………. 30
2.3.1. Java Sun Studio Creator ………………………………………………… 30
2.3.2 WebLogic Workshop ……………………………………………………. 30
2.3.3. IBM WebSphere Portlet Factory ……………………………………….. 31
2.3.4. Sun Java Studio Enterprise ……………………………………………… 31
2.3.5. Borland JBuilder 2005 y la edición de desarrollo de Borland del portal
de aplicación Vignette ………………………………………………………………
32
2.3.6. OracleAS Portal …………………………………………………………. 32
2.4 Resumen ……………………………………………………………………….. 33
Capítulo III. Componentes de la arquitectura del portal empresarial ………... 35
3.1. Introducción …………………………………………………………………… 35
3.2. Componentes de la arquitectura del portal empresarial ……………………….. 35
3.2.1 Modo portal de Internet ………………………………………………….. 37
3.2.2. Modo Proxy del portal …………………………………………………... 38
3.2.2.1. Relación entre servicios Web y portlets ………………………... 38
3.2.2.2. Descripción de los componentes ………………………………... 40
3.2.2.2.1. El analizador de mensajes SOAP …………………….. 41
3.2.2.2.2. El selector de servicio ………………………………… 41
3.2.2.2.3. El contenedor de portlets ……………………………... 41
3.2.2.2.4. El invocador ………………………………………….. 42
3.2.2.2.5. El analizador de respuesta ……………………………. 42
3.2.2.2.6. El constructor de respuestas ………………………….. 44
3.2.2.3. Funcionamiento de la arquitectura ……………………………….. 44
3.3. Resumen ………………………………………………………………………. 45
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
4
Capítulo IV. Prestaciones de servicios del portal empresarial ……..…………... 46
4.1. Introducción …………………………………………………………………... 46
4.2. Modo portal de Internet ………………………………………………………... 46
4.2.1. Interfaz gráfica del modo portal de Internet …………………………….. 46
4.2.2. Tecnología de desarrollo para el modo portal de Internet ………………. 47
4.2.3. Métodos del contenedor de portlets para el modo portal de Internet …… 47
4.3. Modo Proxy ……………………………………………………………………. 55
4.3.1. Servicio Proxy AmazonBox …………………………………………….. 56
4.3.2. Servicio Proxy Horoscope ………………………………………………. 60
4.3.3. Servicio Proxy Theaters ………………………………………………… 61
4.3.4. Servicio Proxy USAWeather …………………………………………… 63
4.3.5. Tecnología de desarrollo para el modo portal Proxy …………………… 65
4.4. Capas de prestaciones de servicios de la arquitectura del portal ………………. 65
4.4.1. Capa de presentación ……………………………………………………. 65
4.4.2. Capa de comunicación …………………………………………………... 66
4.4.3. Capa de descubrimiento ………………………………………………… 67
4.4.4. Capa de servicio ………………………………………………………… 68
4.4.5. Capa lógica ……………………………………………………………… 68
4.4.6. Capa de integración ……………………………………………………... 69
4.5. Resumen ……………………………………………………………………….. 70
Capítulo V. Casos de estudio ………..……………………………………………. 72
5.1. Introducción …………………………………………………………………… 72
5.2. Caso de estudio: una búsqueda de programación de cines …………………….. 72
5.3 Caso de estudio: ayuda en la toma de decisión para la asistencia al cine ……… 74
5.4. Fundamentos de la tecnología de portlets que explican sus ventajas en sus
servicios al usuario ………………………………………………………………….
77
5.5. Resumen ……………………………………………………………………….. 78
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
5
Capítulo VI. Conclusiones …………………..……………………………………. 80
6.1. Conclusiones generales ………………………………………………………... 80
6.2. Contribuciones de la tesis ……………………………………………………… 82
6.3. Trabajo futuro ………………………………………………………………….. 83
6.3.1. Caso de estudio propuesto en la implementación imperiosa de un portal
con un conjunto inicial de soluciones a través de una arquitectura basada en
portlets ………………………………………………………………………………
84
6.3.2. Caso de estudio propuesto para obtener noticias de Java en alguno de los
idiomas más importantes ……………………………………………………………
85
Glosario …………………………………………………………………………….. 87
Publicación …………………………………………………………………………. 90
Referencias …………………………………………………………………………. 91
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
6
Índice de figuras
Figura 1.1. Portlets locales que usan servicios Web remotos …………………...…. 11
Figura 1.2. Un portal que usa servicios Web de portlets remotos ………………….. 12
Figura 2.1. El portlet del clima ……………………………………………………... 25
Figura 2.2. Edición de preferencias ………………………………………………… 26
Figura 2.3. WSRP y estándares que se relacionan …………………………………. 28
Figura 3.1. Aspecto general de la arquitectura ……………………………………... 36
Figura 3.2. Portal empresarial en su modo portal de Internet ……………………… 37
Figura 3.3. Arquitectura del portal en modo Proxy ………………………………… 39
Figura 3.4. Documento WSDL del servicio Web ―Horoscope web Services‖, para
los clientes del portal en su modo Proxy ……………………………………………
40
Figura 3.5. Documento WSDL del servicio Web ―Horoscope web Services‖, del
proveedor externo del servicio para el portal en su modo Proxy …………………...
43
Figura 4.1. El modo portal de Internet con la opción activa ―All Portlets‖ ……….. 47
Figura 4.2 A. Representación en UML del contenedor de portlets ………………… 49
Figura 4.2 B. Representación en UML del contenedor de portlets ………………… 50
Figura 4.2 C. Representación en UML del contenedor de portlets ………………… 51
Figura 4.3. Métodos del contenedor de portlets, en la secuencia y con la estructura
condicional if-else que se requiere para generar un portlet …………………………
54
Figura 4.4. Representación en UML de la API del portal para su modo Proxy ……. 56
Figura 4.5. Ejemplificación, en caja negra, del empleo de los métodos del
documento WSDL para el servicio Proxy AmazonBox …………………………….
58
Figura 4.6. Ejemplo de invocación de un método, el método getBook, del servicio
Proxy AmazonBox ………………………………………………………………….
59
Figura 4.7. Ejemplo de ejecución de un método, el método getBook, del servicio
Proxy AmazonBox ………………………………………………………………….
59
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
7
Figura 4.8. Ejemplificación, en caja negra, del empleo del método getHoroscope
del documento WSDL para el servicio Proxy Horoscope …………………………..
60
Figura 4.9. Ejemplo de invocación del método del servicio Proxy Horoscope que
se denomina getHoroscope ………………………………………………………..
60
Figura 4.10. Ejemplo de ejecución del método del servicio Proxy Horoscope que
se denomina getHoroscope ………………………………………………………….
61
Figura 4.11. Ejemplificación, en caja negra, del empleo del método getShowTimes
del documento WSDL para el servicio Proxy Theaters …………………………….
62
Figura 4.12. Ejemplo de invocación del método del servicio Proxy Theaters que se
denomina getShowTimes …………………………………………………………...
62
Figura 4.13. Ejemplo de ejecución del método del servicio Proxy Theaters que se
denomina getShowTimes …………………………………………………………...
62
Figura 4.14. Ejemplificación, en caja negra, del empleo de los métodos del
documento WSDL para el servicio Proxy USAWeather …………………………...
63
Figura 4.15. Ejemplo de invocación de un método del servicio Proxy USAWeather
que se denomina getWeatherByZipCode …………………………………………...
64
Figura 4.16. Ejemplo de ejecución de un método del servicio Proxy USAWeather
que se denomina getWeatherByZipCode …………………………………………...
64
Figura 4.17. La arquitectura de portal en capas ……………………………………. 70
Figura 5.1. Portal con los primero cuatro portlets ………………………………….. 73
Figura 5.2. El portlet Theaters en presentación y en ejecución …………………….. 74
Figura 5.3. El portlet TheatersAndUSAWeather en su presentación inicial al
usuario ………………………………………………………………………………
75
Figura 5.4. El portlet TheatersAndUSAWeather en ejecución …………………….. 76
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
8
Índice de tablas
Tabla 1.1. Desventajas de las tecnologías de portales de la primera generación …... 10
Tabla 3.1. Descripción de los servicios Web del portal ……………………………. 36
Tabla 4.1. Métodos del servicio Proxy AmazonBox ……………………………….. 57
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
9
Resumen
Las tecnologías de portales de la primera generación tales como CGI, PHP, ASP,
Servlets, JSP, entre otros, presentaron desventajas para acceder a recursos e información
que provienen de terceras partes, porque éstos proceden de diferentes plataformas
operativas, lenguajes de programación y bases de datos. Para superar éstas limitaciones se
presentan las tecnologías de portlets. Estas tecnologías presentan un enfoque orientado a
componentes y se basan en estándares.
Esta tesis presenta el diseño y desarrollo de un portal empresarial usando las
tecnologías de portlets y se aborda el problema de integración de información. Dado que se
requiere una solución para la necesidad de encontrar un acceso consistente a fuentes de
datos heterogéneas y dispersas.
El enfoque de solución consiste en el desarrollo de una arquitectura de integración
de información usando portlets. Esta arquitectura presenta dos modos de operación, modo
portal de Internet y Proxy. Dicha arquitectura se prueba con una aplicación la cual se
enfoca hacia la industria del entretenimiento. Las principales contribuciones de este trabajo
son: 1) una arquitectura basada en portlets con diferentes niveles de prestación de servicios;
y 2) un conjunto de mecanismos que describen la funcionalidad de los servicios que se
representan como portlets. Finalmente, las ventajas de esta propuesta son: 1) capacidad de
acceso de una manera estable a diferentes fuentes de datos heterogéneas; y 2) adaptabilidad
de portlets en fase de diseño y para los usuarios finales.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
10
Abstract
Technologies from first generation portals such CGI, PHP, ASP, Servlets, JSP,
among others, have presented disadvantages to accede to resources and information
provided by third parts, because these coming from different operating platforms,
programming languages and data bases. In order to surpass these limitations the portlets
technologies are arisen. These technologies present a component–oriented and standard-
based approach.
This thesis presents the design and development of an enterprise portal by using
portlets technologies. In this thesis, the problem of information integration is addressed. A
solution for the necessity for finding a consistent access to heterogeneous and scattered data
sources is required.
The solution approach consists of the development of an information integration
architecture by using portlets. This architecture shows two ways of operation, both Internet
portal mode and Proxy mode. This architecture was tested with an application which is
focused towards the entertainment industry. The main contributions of this work are: 1) a
portlet-based architecture with different level services; and 2) a set of mechanisms which
describe the services functionality described as portlets. Finally, the advantages of this
proposal are: 1) able to access in stable way to different heterogeneous data sources; and 2)
ability to customize portlets in design phase and for end users.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
11
Introducción
Esta tesis presenta el desarrollo de una arquitectura de integración de información
basada en portlets para un portal de segunda generación. Para la validación de esta
arquitectura se exhibe el desarrollo de una aplicación. Dicha arquitectura emplea portlets y
servicios Web. Con ello, se adquiere las ventajas de la adaptabilidad y de un acceso
consistente a fuentes de información dispersas y de naturalezas diversas en la
infraestructura global de información. Esto es relevante porque se muestra que los portales
de primera generación basados en tecnologías tales como CGI, PHP, ASP, servlets, JSPs,
entre otros presentan una arquitectura monolítica que compromete el desarrollo y
mantenimiento. Estas desventajas se superan con la tecnología de portlets.
La arquitectura que se presenta posee dos modos de operación, modo portal de
Internet y Proxy. Ambos modos se enfocan a consumir servicios de la industria del
entretenimiento. Sin embargo, existe una diferencia importante en la forma de otorgar los
servicios de dichos modos. El modo portal de Internet otorga un servicio directo a usuarios
finales; mientras que, el modo Proxy ofrece sus servicios a aplicaciones Web a través de un
servicio de intermediación. El objetivo general que plantea esta tesis es el diseño y
construcción de un portal empresarial con base en el desarrollo de una aplicación basada en
componentes Web, que se gestione por un contenedor de portlets para procesar peticiones y
generar contenido dinámico. Los objetivos particulares son: (1) diseñar y construir la
arquitectura de integración para un portal empresarial a través de portlets; y (2) establecer
los mecanismos que permitan la personalización, la presentación y la gestión de seguridad a
través de portlets. A su vez, las aportaciones de la tesis se establecen de la siguiente
manera: (1) una arquitectura de integración bajo diferentes niveles de prestación de
servicios; y (2) un conjunto de mecanismos que definen la funcionalidad de los servicios
representados como portlets.
A continuación se presenta una breve descripción de la estructura de la tesis.
En el capítulo I se presenta la motivación de la tesis. Para este capítulo, se muestran
los antecedentes de Internet y se realiza una revisión de las tecnologías de los portales de
primera y segunda generación. También presenta: el problema que trata la tesis, la revisión
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
12
del estado del arte, en el cual se compara la arquitectura propuesta contra la de trabajos
semejantes y finalmente se explica la propuesta de solución.
En el capítulo II se presenta la tecnología de portlets. En este capítulo se lleva a
cabo una revisión del estándar JSR-168 para portlets locales y del estándar WSRP para
portlets remotos. Además, se muestra una revisión de los ambientes de desarrollo que
soportan portlets.
En el capítulo III se presentan los componentes de la arquitectura del portal
empresarial. Ésta se divide en dos partes: modo portal de Internet y modo Proxy. Se
muestra que ambos modos del portal se subdividen en componentes más específicos que se
describen con detalle.
En el capítulo IV se explican las prestaciones de servicios del portal empresarial
para los dos modos de operación del portal. Además, se presenta la representación en UML
del contenedor de portlets y del modo Proxy. Así también, se explican las capas de
servicios de la arquitectura del portal.
En el capítulo V se presentan dos casos de estudio que permiten observar las
ventajas de la arquitectura propuesta y se discuten los fundamentos tecnológicos que
permiten dichas ventajas.
Finalmente, en el capítulo VI se presentan las conclusiones, se muestran las
contribuciones de la tesis y se proponen trabajos futuros.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
13
Capítulo 1. Motivación
1.1. Introducción
Los portales son sitios basados en el protocolo HTTP que se alojan en un servidor
con un software especial de portal, el cual permite la agrupación de varios sistemas,
procesos o sitios para visualizarse en una sola página de portal. Los portales permiten
apoyar a las empresas. Con un portal empresarial, las empresas están en condiciones de
ofrecer a sus empleados, clientes y socios una manera segura de acceder a toda la
información y servicios necesarios para interactuar y colaborar con su organización.
La motivación de esta tesis está en potenciar el rol del portal empresarial a través
del desarrollo de un portal que acceda exitosamente a fuentes de datos dispersas y
heterogéneas. La obtención de este objetivo es difícil con las tecnologías para los portales
de primera generación dado que éstas presentan importantes desventajas. Estas consisten en
que los portales de primera generación requieren de enormes esfuerzos de programación e
inversión en tiempo para acceder a recursos e información provistos por terceras partes. En
consecuencia, surge la tecnología para portales de segunda generación basada en portlets.
Estos permiten acceder a información a través de integrar aplicaciones heterogéneas y
fuentes de datos consistentemente. Sin embargo, dado que los portlets son componentes,
surge la necesidad de una arquitectura que los sustente para maximizar los recursos
existentes. Por lo tanto, la tecnología de portlets con sustento en una arquitectura apropiada
permitirá el desarrollo de un portal empresarial que mejore en la empresa su interacción
inter-organización e intra-organizacional.
Este primer capítulo presenta una breve revisión de los antecedentes de Internet,
también se realiza una revisión de las tecnologías para portales de primera y segunda
generación. Además, se establece cuál es el planteamiento del problema a resolver y se
hace una revisión del estado del arte. Finalmente, se presenta una propuesta de solución
para integrar información a través del diseño y construcción de un portal empresarial
utilizando la tecnología de portlets.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
14
1.2. Antecedentes
El Internet es una red de redes a escala mundial compuesta por millones de
computadoras que se interconectan con un conjunto de protocolos, de los cuales el que más
se destaca es el TCP/IP (Transmission Control Protocol/Internet Protocol, protocolo de
control de transmisión / protocolo de Internet ). El nombre de Internet también se usa como
sustantivo común y por tanto en minúsculas para designar a cualquier red de redes que use
las mismas tecnologías que Internet, independientemente de su extensión o de que sea
pública o privada [1].
Cuando se dice red de redes se hace referencia a que es una red que se forma por la
interconexión de otras redes menores [1].
Al contrario de lo que se piensa comúnmente, Internet no es sinónimo de World
Wide Web. Ésta es parte de aquella, siendo la World Wide Web uno de los muchos servicios
que se ofertan en la red Internet. La Web es un sistema de información mucho más reciente
que emplea Internet como medio de transmisión [1].
Algunos de los servicios disponibles en Internet aparte de la Web son el acceso
remoto a otras máquinas tales como SSH (Secure SHel, programa de seguridad) y telnet
(protocolo de Internet para acceso remoto), transferencia de archivos tal como FTP (File
Transfer Protocol, protocolo de transferencia de archivos), el uso del protocolo SMTP
(Simple Mail Transfer Protocol, protocolo simple de transferencia de correo electrónico)
que se basa en texto y se utiliza para el intercambio de mensajes de correo electrónico entre
computadoras o distintos dispositivos como celulares, entre otros, boletines electrónicos
tales como news o grupos de noticias, conversaciones en línea tales como IRC (Internet
Relay Chat, protocolo de comunicación en tiempo real basado en texto) [1].
Por otra parte, en la historia de Internet se tiene que en 1972 se realizó la primera
demostración pública de ARPANET (Advanced Research Projects Agency Network,
agencia de red de proyectos de investigación avanzados), una nueva red de comunicaciones
que financió la DARPA (Defense Advanced Research Projects Agency, agencia de
investigación de proyectos avanzados de defensa) que funcionaba de forma distribuida
sobre la red telefónica conmutada. El éxito de esta nueva arquitectura sirvió para que en
1973, la DARPA iniciara un programa de investigación sobre posibles técnicas para
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
15
interconectar redes (éstas se enfocaron al tráfico de paquetes) de distintas clases. Para este
fin, se desarrollaron nuevos protocolos de comunicaciones que permitieron este
intercambio de información de forma "transparente" para las computadoras que se
conectaron. De la filosofía del proyecto surgió el nombre de "Internet", que se aplicó al
sistema de redes que se interconecta mediante los protocolos TCP e IP [1].
En 1983 el ARPANET cambió el protocolo NCP (Network Control Protocol,
protocolo de control de red) por TCP/IP. Ese mismo año, se creó el IAB (Internet
Architecture Board, consejo de la arquitectura de Internet) con el fin de estandarizar el
protocolo TCP/IP y de proporcionar recursos de investigación a Internet. Por otra parte, se
centró la función de asignación de identificadores en la IANA (Internet Assigned Numbers
Authority, agencia de asignación de números Internet), que posteriormente delegó parte de
sus funciones en el IR (Internet Registry, registro de Internet) que a su vez proporciona
servicios a los DNS (Domain Name System, sistema de nombres de dominio).
En 1986 la NSF (National Science Foundation, fundación nacional de ciencias)
comenzó el desarrollo de NSFNET (National Science Foundation's Network, red de la
fundación nacional de ciencias) que se convirtió en la principal red en árbol de Internet que
se complementó después con otras redes en los Estados Unidos de América. Paralelamente,
otras redes troncales en Europa, tanto públicas como comerciales, junto con las americanas
formaron el esqueleto básico ("backbone") de Internet.
En 1989 con la integración de los protocolos OSI (Open Systems Interconnection,
interconexión de sistemas abiertos) en la arquitectura de Internet, se inició la tendencia
actual de permitir no sólo la interconexión de redes de estructuras diferentes, sino también
la de facilitar el uso de distintos protocolos de comunicaciones.
En el CERN (en francés, Conseil Européen pour la Recherche Nucléaire, consejo
europeo para la investigación nuclear) de Ginebra, un grupo de físicos que encabezó Tim
Berners-Lee, crearon el lenguaje HTML (Hyper Text Markup Language, lenguaje de
marcado de hipertexto), que se basó en el SGML (Standard Generalized Markup
Language, estándar generalizado de lenguaje de marcado). En 1990 el mismo equipo
construyó el primer cliente Web que se llamó WorldWideWeb (WWW) y el primer servidor
Web [1].
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
16
Comúnmente las páginas Web mostraban información que no cambiaba. Esta forma
estática de mostrar información fue bastante eficiente puesto que la página se creaba una
vez y se presentaba. Cuando era necesario se hacían mínimos cambios y ya estaba lista otra
vez. Pero rápidamente surgió la necesidad de interactuar con el usuario y de adaptar la
información a sus necesidades, o mostrar información que se toma de bases de datos que
frecuentemente cambian. Con la forma que había de crear documentos HTML estáticos era
difícil mantener esas páginas si se querían construir con cierto dinamismo. Por ello
aparecieron las técnicas de generación dinámica de páginas. Estas técnicas permiten la
actualización de páginas aunque se muestra información que cambia frecuentemente y
también posibilitan formas de establecer comunicaciones que se personalizan con los
usuarios [2].
Además, anteriormente era difícil desarrollar un sitio Web que ofreciera a los
usuarios la posibilidad de acceder varios sistemas a partir de una sola página. Los sistemas
estaban drásticamente separados uno del otro y requerían de una gran inversión de tiempo y
trabajo para ponerlos a trabajar juntos en una única página Web. Por ello surgió la
necesidad del desarrollo de portales, los cuales se definen como un sitio con base en HTTP
(HyperText Transfer Protocol, protocolo de transferencia de hipertexto) que se hospeda con
un software especial de portal que permite la agrupación de varios sistemas, procesos o
sitios que se visualizan todos en una sola página de portal. Los portales pueden proveer
servicios adicionales, un ejemplo es la seguridad en una autenticación simple y la capacidad
de personalizar [3].
Un portal de Internet es un sitio que se enfoca en resolver necesidades específicas de
un grupo de personas. Un portal de Internet puede ser un centro de atención a los clientes y
prospectos de venta de su empresa, éstos se pueden complementar con herramientas que le
ayuden a levantar pedidos, atender los problemas de sus clientes, ofrecer cotizaciones,
brindar correos electrónicos, motores de búsqueda, evaluaciones en línea, dar capacitación
a distancia, entre otros [4].
Existen dos modalidades de portales: (1) portales horizontales, que también se
llaman portales masivos o de propósito general, se dirigen a una audiencia amplia, tratando
de llegar a toda la gente con muchas cosas. Como ejemplo de portales de esta categoría
están AOL, AltaVista, Lycos, Yahoo, MSN; y (2) portales verticales, se dirigen a usuarios
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
17
para ofrecer contenido y comercio dentro de un tema específico como puede ser un portal
de música, un portal de finanzas personales o de deportes. Como ejemplos de esta categoría
se encuentran CNET, SportsLine.com. [4]
Además, en [5] se establece que los portales varían de acuerdo a los usuarios que
sirven y los servicios que ofrecen: (1) portales públicos, tales como yahoo presentan
información de varias fuentes, aplicaciones, y gente, ofreciendo sitios Web que se
personalizan para usuarios arbitrarios, (2) portales empresariales, dan a los empleados
acceso a información específica de la organización y aplicaciones, (3) portales de mercado,
tales como eBay y ChemWeb negocian concentradores que conectan a vendedores y
compradores; y (4) portales que se especializan, tales como SAP ofrecen rutas de acceso a
aplicaciones específicas.
A continuación se presenta la evolución de las diversas tecnologías para portales.
1.3. Evolución de las tecnologías de información.
En esta sección se presentan las tecnologías para portales de la primera generación
hasta la tecnología para portales de la segunda generación. Esta última, basada en portlets.
Primeramente, se presenta la tecnología para portales más antigua, ésta es la
tecnología CGI. A continuación, se presentan las tecnologías que posteriormente surgieron
tales como PHP, ASP, Servlets, JSP y se concluye con la tecnología de portlets. En el
recuento de estas tecnologías se muestra una breve descripción de éstas, sus ventajas y
desventajas particulares.
1.3.1 Common Gateway Interface (CGI)
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 [2], estas interfaces se
denominaron CGI. Sin embargo, el gran inconveniente de la tecnología CGI es el
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
18
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 [6].
Para solucionar las deficiencias de la tecnología CGI aparecieron nuevas tecnologías
que proporcionan más beneficios.
1.3.2. PHP
PHP es un lenguaje de programación que se usa generalmente para la creación de
contenido para sitios Web. El nombre es el acrónimo recursivo de "PHP (Hypertext
Preprocessor, preprocesador de hipertexto)" inicialmente PHP Tools (herramientas PHP) o
Personal Home Page Tools (herramientas de página personal) y 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 [6]. PHP tiene las siguientes ventajas: (1) está
públicamente disponible, (2) es sencillo de aprender, (3) posee numerosas librerías de
funciones que permiten manejar múltiples bases de datos (MySQL, PostgreSQL, entre
otras), (4) utiliza funciones para protocolos de Internet (SMTP, POP3, IMAP, SNMP,
HTTP, entre otras), (5) es multiplataforma; y (6) existe una amplia comunidad de PHP con
una base de conocimientos amplia sobre el lenguaje [7]. Sin embargo, la Programación
Orientada a Objetos (POO) en versiones anteriores a la versión cinco de PHP, carecía de
potencia [8]. El mayor problema de la POO consistía en que cada vez que se asignaba una
variable que contenía un objeto a otra variable o se transmitía un objeto por parámetro en
una función, se realizaba una copia (un clon) de ese objeto y quedaba a disposición del
programa en la nueva variable o parámetro. Todo esto implica que el espacio en memoria
para guardar los dos objetos es el doble que si fuera un mismo objeto con dos nombres
distintos. No obstante, para solventar este problema en la versión actual de PHP (versión
cinco) se hace uso de los manejadores de objetos (Object handles), que son una especie de
dato de tipo puntero que señala hacia los espacios en memoria donde residen los objetos.
Cuando se asigna un manejador de objetos o se pasa como parámetro en una función, se
duplica el propio object handle y no el objeto en si [9].
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
19
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 (éste es un servidor Web). Cada método tiene sus ventajas y
desventajas. Si se instala PHP como un intérprete CGI ofrece la oportunidad de tener tantos
procesos ejecutándose como identificadores de usuarios diferentes bajo anfitriones
virtuales. Cuando PHP se instala como un módulo Apache se debe elegir si será un módulo
estático o dinámico. Un módulo estático es una compilación previa de PHP con Apache;
mientras que un módulo dinámico se caracteriza por cargarse sin necesidad de compilar
Apache. Un módulo estático tiene la ventaja de incrementar el desempeño, pero cuando se
desea actualizar se tiene que recompilar tanto al PHP como al Apache. Con un módulo
dinámico, se pierde desempeño. Sin embargo, las correcciones y actualización del PHP son
mucho más fáciles cuando se instala como un módulo dinámico [10].
1.3.3. Active Server Pages (ASP)
ASP es una tecnología que desarrolló Microsoft que aporta capacidad operativa a
las páginas Web, combinando HTML con un lenguaje de secuencia de comandos o
lenguaje script. Los lenguajes que más se usan actualmente para programar el código script
dentro de las páginas ASP son VBScript y JScript, aunque también se pueden utilizar otros
como Python. 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 una tecnología válida
para cualquier tipo de navegador. ASP utiliza la tecnología que se denomina ISAPI
(Internet Server Aplication Program Interface, interfaz de programa de aplicación de
servidor de Internet). Una aplicación ISAPI se basa en librerías de enlace dinámico que se
ejecutan en el mismo espacio de direcciones que el servidor Web, de manera que soportan
numerosas peticiones simultáneas con una sola imagen en memoria [6]. 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 [2].
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
20
1.3.4. Servlets
Los servlets son 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 servlets específicas para requerimientos HTTP
[11]. Sus ventajas consisten en que: (1) los servlets son independientes de la plataforma
(porque están escritos en Java), son independientes del servidor y además pueden acceder a
todos los APIs de Java, posibilitando el desarrollo de verdaderas aplicaciones en la Web; y
(2) la diferencia fundamental entre CGI y los servlets es la persistencia; esto quiere decir
que una vez que un servlet se desarrolló permanece en memoria y puede atender múltiples
peticiones de servicios, por esa razón esta alternativa es más rápida que el CGI tradicional
al no necesitar lanzar un nuevo proceso cada vez que se realiza una petición [12]. Sin
embargo, el enfoque que se basa en servlets tiene los siguientes inconvenientes: (1) se
necesita un conocimiento detallado del lenguaje Java para mantener todos los aspectos de la
aplicación ya que el código de procesamiento y los elementos de HTML están juntos, (2)
cambiar la apariencia de una aplicación o agregar soporte para nuevos tipos de cliente, por
ejemplo WML (Wireless Markup Language, lenguaje de marcado de dispositivos móviles)
requiere la actualización y recompilación del código del servlet; y (3) es difícil aprovechar
herramientas de desarrollo de páginas Web (editores de HTML) al diseñar la interfaz. Si
esas herramientas se utilizan para desarrollar la estructura del documento el código HTML
que se genera debe embeberse en el código del servlet. Este proceso consume mucho
tiempo, es propenso a errores y extremadamente tedioso [13].
1.3.5. JavaServer Pages (JSP)
La tecnología JSP 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 [12]. Los
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
21
elementos JSP se pueden usar para una gran variedad de propósitos como recuperar
información de una base de datos o registrar preferencias del usuario [13]. La ventaja de
JSP en comparación a los servlets es que es una extensión de la tecnología Java servlets;
mientras que estos últimos tienen que mantener plantillas de código HTML dentro del
programa, JSP contiene estas plantillas dentro de las propias páginas [14]. En comparación
con otras tecnologías, su ventaja es la independencia de la plataforma tanto cliente como
servidor. Por un lado, la utilización de código Java garantiza la portabilidad de la aplicación
para su ejecución en cualquier servidor que contenga una máquina virtual Java. Esta es una
ventaja sustancial frente a otras tecnologías similares, como por ejemplo Active Server
Pages (ASP). En el caso del cliente, al recibir sólo páginas HTML hace que sea compatible
con cualquier navegador. 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.
1.3.6. Los Portlets
La tecnología para portales de segunda generación se constituye por portlets. Éstos
son componentes Web que se controlan por un contenedor capaz de generar contenido
dinámico e interactuar con los usuarios a través del portal [15]. Un portlet provee
contenido a su contenedor de portal que lo invocó para efectos de despliegue de la
información en una página de portal. 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 [3]. Las ventajas que plantean estos elementos son: (1) su
versatilidad en el tiempo en que se desarrollan y despliegan porque los portlets pueden
generar distintos tipos de contenidos en función del mecanismo de acceso o a la
información a la que tienen acceso, (2) un portlet debe verse como un encapsulado de una
aplicación Web para poder utilizarse como un componente dentro de un portal [15]; y (3)
un contenedor de portlets maneja múltiples solicitudes a un portlet utilizando las mismas
instancias de una clase portlet, invocándolas en diferentes instancias de ejecución a través
de los mismos métodos [3], con la eficiencia y economía que ello implica. Sin embargo, en
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
22
[3] se hace notar que quedan pendientes tareas a resolver para versiones futuras de los
portlets.
Por otra parte, la ventaja de los portlets contra las tecnologías de los portales de
primera generación, tales como CGI, ASP, PHP, JSP, Servlets, entre otros, consiste en que
éstos encontraron problemas de compatibilidad para acceder a contenidos y aplicaciones de
proveedores de diversas tecnologías, es decir, son monolíticos. Mientras que los portlets
además de que constituyen componentes Web con las ventajas que esto implica, se basan
en las especificaciones JSR 168 (Java Specification Request, especificación de portlet de
Java) y WSRP (Web Services for Remote Portlets, servicios Web para portlets remotos) que
son de aceptación creciente entre los proveedores de contenidos y aplicaciones Web lo cual
permite apoyar a portales como intermediarios múltiples para alcanzar una cantidad
enorme de usuarios finales, que de otra manera no sería posible.
A continuación, en la tabla 1.1 se presenta una síntesis de las desventajas
particulares de las tecnologías para portales de primera generación.
Tecnología Desventaja particular
CGI Ejecuciones pesadas para el microprocesador. Cada petición al servidor se
traduce en una nueva copia del programa en la memoria de éste.
ASP Alcanza su mayor potencia con el uso de los objetos denominados Active-X,
los cuales están disponibles sólo en sistemas operativos Windows.
PHP Complejidad en sus métodos de instalación. Además, la programación
orientada a objetos en versiones anteriores (a la versión cinco) carecía de
potencia.
Servlets Requiere mantener plantillas de código HTML dentro del programa Java.
Esto hace a la tecnología compleja y difícil de entender.
JSP Como las demás tecnologías de portales de primera generación. JSP no
permite acceder a recursos e información provistos por terceras partes.
Tabla 1.1. Desventajas de las tecnologías de portales de la primera generación.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
23
1.4. Planteamiento del problema
El integrar recursos e información empresarial propia y de terceras partes en el
desarrollo de un portal de segunda generación requiere abordar un problema de integración
de información. Estos problemas consisten en la necesidad de encontrar compatibilidad al
acceder recursos que se encuentran en diferentes: (1) plataformas operativas, (2) bases de
datos; y (3) lenguajes de programación o modelos de programación, entre otros.
Considérese el siguiente ejemplo: un administrador de portal de empleado quiere
incluir un servicio de recursos humanos para calcular la variable pago para empleados y un
servicio de previsión del clima. Una solución para este escenario se describe en la figura
1.1: un portlet de recursos humanos y un portlet de previsión del tiempo que se ejecuta
localmente en el servidor del portal y con acceso a servicio Web remoto para obtener la
información requerida, es decir, el servicio Web provee datos y la capa de presentación se
implementa en portlets específicos [16].
Figura 1.1. Portlets locales que usan servicios Web remotos.
El portlet de recursos humanos usa un servicio Web de recursos humanos para
calcular la variable pago. Por consiguiente, despliega un formulario para consultar los datos
de entrada, por ejemplo, el identificador de empleado (id). Cuando el empleado provee los
datos para el portlet de recursos humanos, invoca el servicio Web de recursos humanos
para calcular la variable pago que se basa sobre esos datos. Recibe el resultado desde el
servicio Web y lo despliega como un fragmento de página. El portlet de previsión del
Portal del
empleado
Portlet
del clima
Portlet de
R. H.
Servicio Web del
clima
Servicio Web de
R. H.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
24
tiempo despliega la previsión del tiempo para ciudades configurables y permite al usuario
seleccionar las localidades en un modo edit (edición). Cuando el portlet de previsión del
tiempo se invoca durante la carga de la página, solicita la más reciente previsión del tiempo
para las localidades seleccionadas del servicio Web de previsión del tiempo y despliega un
fragmento de página con aquellas previsiones del tiempo.
Este enfoque solamente funciona si todos los portlets se instalan físicamente en el
portal del empleado. El proceso de hacer nuevos portlets disponibles es tedioso y caro; la
capa de presentación debe redesarrollarse para cada portal. Para integrar la información de
recursos humanos en el portal usando portlets locales, o el departamento de recursos
humanos podría implementar el portlet de recursos humanos y darlo a uno de los
administradores del portal de empleado para instalarlo, o un desarrollador del portal de
empleado podría implementar el portlet de recursos humanos de acuerdo a la descripción de
interfaz del servicio Web de recursos humanos, similar esfuerzo se requeriría para el portlet
de previsión del tiempo.
Obviamente, sería mucho más conveniente si los servicios Web de recursos
humanos y previsión del tiempo incluyen lógica de aplicación y presentación y ellos
mismos producen fragmentos de marcado que son fáciles para agregar al portal
consumidor, como se muestra en la figura 1.2 [16].
Figura 1.2. Un portal que usa servicios Web de portlets remotos
En vez de proveer sólo datos escuetos o funciones de negocios simples que todavía
requieren especial interpretación en el lado del portal, WSRP tiene orientación al usuario y
Portal del
empleado
Portlet
Proxy
Portlet
Proxy
Servicio
Web del
clima
Servicio
Web de
R. H.
Portlet
Clima
Portlet
R. H.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
25
son servicios Web interactivos que incluyen la presentación. Ellos son fáciles de agregar y
se invocan a través de una interfaz común usando un código Proxy de portlet genérico que
se construye en el portal. Ningún código de portlet especial necesita instalarse en todos los
portales y se evita la re-implementación de la capa de presentación en cada portal.
Los portlets remotos hacen la tarea más accesible porque dichos portlets pueden
añadirse dinámicamente al ambiente, y beneficiar a los usuarios a través de tener más
servicios disponibles de una manera oportuna. Se pueden agregar servicios de portlet
remotos en un portal usando su interfaz de usuario de administración de portal para
encontrarlos y unirlos con poco esfuerzo. Como resultado, el portal crea nuevos Proxis de
portlets genéricos que se unen a servicios Web de portlets remotos para que estén
disponibles a los usuarios en la misma manera que los portlets locales.
Sin embargo, aunque los portlets se basan en estándares que abordan el problema de
la arquitectura monolítica de los portales de la primera generación, el estudio del estado del
arte muestra la necesidad de esfuerzos para crear plataformas de integración de información
que satisfagan diversos sistemas de información y las tecnologías que apoyan estos
esfuerzos.
1.5 Estado del arte
Los portlets son componentes Web que constituyen la tecnología para el desarrollo
de los portales de la segunda generación. Los Portlets son elementos dinámicos de creación
de contenidos. Presentan y suman información de una o varias fuente de datos. Generan
html y xml (es decir, documentos digitales a través de estos lenguajes de marcado) en un
área que se muestra dentro de la página del portal. Son reutilizables y pueden
personalizarse. Para el desarrollo de portales empresariales actualmente existen algunos
trabajos que se orientan hacia la conformación y administración de catálogos de portlets.
Bellas [17] argumenta que los portales de primera generación tienden a presentar
una arquitectura monolítica de software que compromete el desarrollo y el mantenimiento
del portal. No obstante, dos estándares propuestos en otoño de 2003 – los servicios Web
para portlets remotos (WSRP) y la especificación java de portlets abordan estos problemas.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
26
En octubre de 2003, la comunidad Java desarrolló la primera versión de la especificación
java de portlets (JSR 168), estandarizando una API de Java para los portlets compatibles
WSRP que se pueden desplegar en cualquier contenedor estándar de portlet en Java. En
contraste a los portales de primera generación, los portales de segunda generación permiten
a los usuarios crear una o más páginas personales que se integran por portlets –
aplicaciones mini Web interactivas- locales o remotas al portal. Los portales de segunda
generación presentan una arquitectura que se orienta a componentes en la cual cada portlet
es un componente que se puede implementar en el portal mejorando así el desarrollo,
mantenimiento y reuso.
Wege [5] propone una descripción en detalle de tipos de portales y servicios. En
donde los portales varían de acuerdo a los usuarios que sirven y los servicios que ofrecen.
Dentro de esta descripción se encuentran: (1) portales públicos, (2) portales empresariales,
(3) portales de mercado; y (4) portales especializados. Un aspecto importante en el
desarrollo de estas aplicaciones es la tecnología de información que permite implementar
servicios comunes tales como: (1) la agregación de contenido que provee contenido de
diferentes fuentes para diferentes usuarios, (2) la agrupación de contenido que recolecta
contenido de diferentes fuentes, (3) la ayuda múltiple que provee contenido para diferentes
canales de interacción, (4) servicio único sign-on que permite recuperar información de
usuarios específicos sin requerir autentificación de usuario cada vez, (5) administración de
portal que determina cómo los usuarios ven el portal; y (6) los usuarios pueden típicamente
subscribirse ellos mismos a portales Web públicos.
Chihcheng et. al. [18] propone que es necesario crear una plataforma de integración
para sistemas de aprendizaje. Se destacan cuatro dificultades en los sistemas de aprendizaje
e-learning actuales. Estas dificultades son la raíz de la causa del actual desaprovechamiento
de sistemas de aprendizaje e-learning monolíticos; estas dificultades son: (1)
interoperabilidad de sistemas de aprendizaje e-learning, (2) colaboración de objetos de
aprendizaje, (3) nivel de presentación integración de objetos de aprendizaje e-learning; y
(4) acceso transparente de sistemas de aprendizaje e-learning. En el sistema propuesto se
emplean servicios WSRP para preservar la presentación de objetos compartidos e-learning
desde otros sistemas. También se propone a BPEL4WS (Business Process Execution
Language for Web Services, Lenguaje de ejecución de procesos de negocios para servicios
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
27
Web) para los flujos de trabajo de cursos que se basan en tareas que se orquestan entre
sistemas de aprendizaje compartidos. Se explican pasos claves en la preparación de curso y
la ejecución para proveer cuadros claros de cómo el sistema propuesto permite la
interoperabilidad de numerosos objetos / componentes / sistemas de aprendizaje.
Dahan et. al. [19] plantea que los portales Grid (portales que proveen salida a la
tecnología Grid, la cual es un tipo de sistema distribuido que permite compartir, seleccionar
y agregar recursos dispersos) que se sistematizan pueden servir como uno o múltiples
puntos de entrada a recursos de computación proporcionando acceso a herramientas grid y
servicios, lo que facilita la barrera de entrada a la computación que se basa en Grids para
conducir investigaciones científicas. Grid Portal Toolkit Versión 3.0 (GridPort) aborda este
problema proporcionando un conjunto de capacidades para usar recursos de computación a
través de una API para construir portales Grid y aplicaciones sobre la infraestructura Grid.
GridPort agrega servicios grid provistos por otro software grid, añade servicios grid
adicionales y presenta una API para desarrolladores. GridPort provee información y
servicios interactivos para portal y aplicaciones. Usa servicios informativos para
suministrar computación que se distribuye y que se relacionan de numerosas tecnologías
Grid. El repositorio de información GridPort (GPIR) almacena y archiva datos,
proporcionando la actualización y el historial de datos a través de servicios Web.
Galligan et. al. [20] expone que cierta organización adquirió una suite de portal
invirtiendo un alto costo y se propuso obtener un rápido retorno de inversión mientras el
desarrollo del portal estaba en curso. Para esto, se utilizó una metodología y modelo de
ciclo de vida para ayudar al proceso de desarrollo. El enfoque facilitó dos rutas de
tecnología. La primera fue para el área de integración de portal. Esta área involucró la
consolidación de aplicaciones distribuidas existentes con el propósito de mejorar
eficientemente a través de funcionalidades tales como flujos de trabajo que se organizaron
y procesos de negocios que se automatizaron. La segunda ruta se enfocó más sobre
aplicaciones externas que pudieran describirse como servicios que se entregan como
aplicaciones del nuevo portal. Por último, se propuso combinar metas de ambas rutas para
lograr bajos costos a través del desarrollo eficiente por medio de la entrega de servicios que
incrementaron el ingreso.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
28
Puschmann et. al. [21] plantea que los portales de proceso soportan redes de
negocios inter-organizacionales. Ellos definen la función y contenido sobre la base de
procesos de cliente y los hacen disponibles a través de un rol que se basa en una interfaz
que se personaliza. Sin embargo, a pesar de la creciente relevancia de portales de proceso,
su uso en la mayoría de negocios está todavía en comienzos. Se sugiere que una
arquitectura consistente y modelos de integración pueden ayudar a los negocios con la
introducción de portales de procesos. Los portales integran diferentes funciones,
mayormente aplicaciones heterogéneas y las sitúa en el contexto de procesos de negocios
específicos. En el futuro, una empresa proveerá a sus clientes todos los servicios que
ofrece. Estos servicios pueden estar disponibles interna o externamente a través de los
portales de: (1) empleado (B2E), (2) proveedor (B2B), (3) cliente (B2C); y (4) de
distribuidor (B2B).
Beeson et. al. [22] presenta un nuevo portal para ejecutar código numérico científico
sobre el Grid. Se hace particular énfasis en el re-empleo y la portabilidad en los portlets. Se
encontró que el estándar JSR 168 es adecuado para crear portlets portables. Para portales
que se forman de muchos portlets se presenta un sistema de comunicación portable. La
promesa de la computación que se basa en Grid ofrece a los investigadores acceso
transparente a recursos de computación en Internet. El desarrollo de portlets Grid es una
tarea desafiante porque la tecnología está cambiando rápidamente. Para que la
infraestructura Grid se explote, se considera la necesidad de crear interfaces fáciles de usar.
El re-uso es fundamental para satisfacer la necesidad de un rápido desarrollo en un
ambiente cambiante y las similitudes entre aplicaciones. Finalmente, se presenta un
conjunto para el re-uso de portlets con el fin de ejecutar programas que se basan en STRIP
sobre el Grid.
Novotny et. al. [23] menciona que el framework de portal GridSphere provee
estándares que se basan en portal para el fácil desarrollo de componentes Web que se
llaman portlets. Los portlets se definen por una API estándar y provee un modelo para
desarrollar nuevos componentes de portal que pueden compartirse e intercambiarse por
varios contenedores de portlets. GridSphere provee un contenedor de portlets, una
colección de portlets y una librería avanzada de interfaz de usuario que permite a los
desarrolladores de aplicaciones implementar fácilmente nuevos portlets. El framework
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
29
GridSphere provee un conjunto de portlets que ofrecen la funcionalidad básica requerida
para el re-uso. Algunos de los portlets provistos son: (1) login, (2) salir del sistema, (3)
determinar selección de idioma, (4) proveer una interfaz para un nuevo usuario de portal,
(5) la habilidad para asignar / revocar roles de usuarios, (6) administración de usuarios, (7)
proveer la habilidad a los usuarios de editar información personal; y (8) suscripción de
portlets.
Pierce et. al. [24] plantea que los portales Web se diseñaron para simplificar el
acceso a diversos conjuntos de recursos de computación de alto desempeño, típicamente a
través de herramientas Grid. Una limitación importante de estos portales es la falta de
servicios interoperables y reutilizables. Con base en esto, se presenta una descripción de
esfuerzos de investigación que se emprendieron para construir servicios interoperativos
alrededor de un modelo de servicios Web. Se presenta una arquitectura de portal
interoperable empezando con servicios de portal de base que se usa para construir
aplicaciones de servicios Web, las cuales se agregan y manejan a través de contenedores de
portlets. Tres tipos de servicios Web de portal se describen: (1) aplicaciones, (2) comandos
Shell de portal y, (3) servicios de contenido (información) que interactúa con objetos de
datos XML.
Weinreich et. al. [25] expone que los portales Web son un medio para la integración
del nivel de presentación de aplicaciones de empresa y servicios. Se describe un enfoque
para aumentar la integración del nivel de presentación en portales Web soportando
comunicación entre componentes del nivel de presentación. Este enfoque se basa en
estándares en esta área y permite el intercambio de datos XML que se estructuran entre
aplicaciones y servicios locales y remotos. Desde el enfoque que es principalmente
declarativo, puede también usarse para mejorar la integración de componentes existentes de
presentación. El enfoque de este trabajo se motivó por la integración de requerimientos que
relacionan instituciones financieras en Austria, quienes necesitaban integrar aplicaciones y
servicios que se ofrecía físicamente y organizacionalmente en separados centros de
cómputo con diferente infraestructura de servidor de hardware y software. El enfoque se
basa sobre la especificación de portlet y sobre la especificación WSRP. La especificación
de portlet define un componente de modelo de presentación (portlets) en Java. Un servidor
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
30
de portal manejable JSR 168 típicamente se implementa sobre la base de una Web
manejable J2EE o servidor de aplicación.
Díaz et. al. [26] plantea que la mayoría de los frameworks de portal soportan
actualmente los portlets. Sin embargo, no hay todavía una respuesta definitiva para la
interoperación del portlet con lo cual el flujo de datos desde un portlet a otro cercano. Se
discute que éstas limitaciones se pueden vencer a través de usar anotaciones técnicas
profundas. Proveyendo marcado adicional sobre servicios de fondo, esfuerzos de anotación
profunda para interactuar con estos servicios fundamentales. Se consideran anotaciones
profundas como validación particular para interoperación de portlet que se debe al ambiente
controlado y corporativo que caracteriza el ajuste del portal. Aumentar la experiencia del
usuario es uno de los distintivos de los portales. Esto implica para el usuario percibir los
distintos ofrecimientos de un portal como un área de trabajo que se integra en donde el flujo
de datos entre los distintos portlets está enmarcado por el portal. El ambiente controlado y
cooperativo que caracteriza al portal facilita el uso de anotaciones profundas para la
interoperación del portlet.
Diaz et. al. [27] argumenta que la variabilidad de demandas para portlets se
encamina a ser más severa que para otra clase de componentes de software que se debe
tanto al sensitivo tema que encapsulan (esto es la presentación) y la necesidad de
personalización que caracteriza uno de sus principales consumidores, esto es, aplicaciones
de portal. Este trabajo propone instrumentar portlets para variabilidad de usos. Apache
Cocoon es un framework de desarrollo Web que se construyó alrededor de los conceptos de
intereses y desarrollo Web que se basó en componentes y permiten una evolución paralela
de todos los aspectos de una aplicación Web mejorando pasos de desarrollo y reduciendo la
oportunidad de conflictos. Este enfoque es un paso en la misma dirección a la que se dirige
el trabajo de [27]. El cual se probó sobre una aplicación de franquicia de una gran
compañía de franquicia de cosméticos. Los portlets se usarán (como trabajo futuro) para
soportar el catálogo de cosméticos. Este catálogo se produjo por la compañía matriz y se
desplegó en los portales de los socios comerciales. Sin embargo, cada franquicia socia
necesitó añadir algunos datos que se personalizaron (por ejemplo, precios y
recomendaciones se fijaron de una manera que se apoyó en el socio comercial).
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
31
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 propuesta en este
trabajo, que más adelante se describe. En el análisis de estas diferencias, dado que el uso de
portlets y del servidor de portal son elementos típicos para la arquitectura propuesta y la de
estos trabajos relacionados no se hace énfasis en ello.
En [28] 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 [29] 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 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 [30] 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
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
32
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 [28],
una diferencia importante es el dominio de la aplicación.
En [31] 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 [32] 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 esta tesis.
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. El enfoque que presenta esta
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
33
tesis utiliza WSRP en combinación con JSP en vez de JSR 168. Finalmente, en la
propuesta de esta tesis no se utiliza una base de datos para la persistencia de la información.
1.6 Propuesta de solución
Las empresas buscan los beneficios de la distribución de información a través de
Internet. En este sentido, un portal empresarial aporta resultados como una herramienta
para hacer accesibles la venta de productos y/o servicios a los clientes, además de facilitar
la colaboración con los empleados y proveedores. En esta dirección, el problema a resolver
en esta tesis es la necesidad de integrar información y recursos empresariales propios y de
terceras partes en el desarrollo de un portal de segunda generación. Esta integración
requiere superar limitantes tales como la dependencia de la plataforma, modelos de
desarrollo y lenguajes de programación que se usen.
Con esta finalidad el objetivo general de este trabajo es desarrollar un portal
empresarial con base en el desarrollo de una aplicación basada en componentes Web que se
gestionen por un contenedor de portlets que procese peticiones y genere contenido
dinámico.
En consecuencia, la hipótesis establece que con la utilización de la tecnología de
información Open Source se llevará a cabo lo que determina el objetivo general y que el
uso de la tecnología Open Source dará al sistema a desarrollar la característica de la
portabilidad.
Asimismo se presenta una arquitectura que permite la integración de aplicaciones y
recursos a través de la tecnología de portlets. Esta arquitectura de integración se compone
por capas y plantea: (1) qué servicios provee cada capa, (2) cómo funcionan entre sí los
componentes de cada capa; y (3) cómo interactúan los componentes de una determinada
capa con los de otra capa. Recordando que la capa inferior ofrece servicios a la capa
inmediata superior.
En este trabajo se proponen los siguientes objetivos específicos: (1) desarrollar el
conjunto de portlets para la arquitectura de integración para el portal empresarial; y (2)
permitir la personalización, la presentación y la gestión de seguridad a través de los
portlets.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
34
Finalmente, las aportaciones originales del presente trabajo son: (1) una arquitectura
de integración bajo diferentes niveles de prestación de servicios; y (2) un conjunto de
mecanismos que definen la funcionalidad de los servicios que se representan como portlets.
1.7. Resumen
En este capítulo, se presentó una revisión breve de la historia de Internet y de las
tecnologías para portales de la primera generación. Se argumentó que las empresas
requieren ofertar sus productos y servicios a través de portales, y que para el desarrollo de
los portales de la primera generación se emplearon tecnologías tales como: CGI, PHP, ASP,
servlets, JSP, entre otras. Para cada una de estas tecnologías, se mostraron sus desventajas
particulares. Y se argumentó que todas las tecnologías para portales de primera generación
en su conjunto, tienen la desventaja de que crear portales monolíticos. Como consecuencia
a lo anterior, se presentó a la tecnología de portales de segunda generación, la cual se
compone por portlets.
Por lo tanto, se estableció el planteamiento del problema. En éste, se fundamenta
que el problema a resolver en la tesis es un problema de integración de información. Este
problema tiene importancia porque se trata de información que no tan solo proviene de la
misma organización en cuestión, sino de entidades que operan con tecnologías de diversas
naturalezas.
En el estado del arte, se mostraron trabajos de investigadores en relación a la
tecnología basada en portlets. Parte de estos trabajos se refieren a desarrollos de
arquitecturas basadas en portlets para atender necesidades particulares. En torno a esto
último, se argumentó, brevemente, las diferencias y similitudes de esas arquitecturas contra
la propuesta en esta tesis.
Finalmente, se presentó la propuesta de solución. En ésta, se incluyó respuestas a
cuestiones básicas de la tesis, tal como el objetivo general y los objetivos particulares de la
misma, la hipótesis y las contribuciones, entre otras.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
35
Capítulo 2: Tecnología de portlets
2.1 Introducción
Los portales usan portlets como componentes de interfaz de usuario que proveen de
una capa de presentación a los sistemas de información [33]. Los portlets se orientan al
usuario y son componentes de aplicaciones Web interactivas que se diseñan para agregarse
a través de un portal y comunicarse con usuarios a través de un servidor de portal huésped.
Los portlets son locales o remotos al portal servidor [16].
En este capítulo se estudian los estándares que constituyen la tecnología de los
portlets para el desarrollo de los portales de la segunda generación. Además, se hace una
revisión de los ambientes de desarrollo que soportan la tecnología de portlets.
2.2 Estándares JSR 168 y WSRP
El estándar JSR 168 define un API de portlet estándar que es específico para
portales que se basan en Java, el cual los desarrolladores utilizan para programar portlets
que se ejecutarán en un servidor de portal manejable; mientras que WSRP define un API
universal que permite a los portales de cualquier tipo consumir portlets de cualquier tipo.
De tal forma que, productores WSRP permiten a portlets JSR 168 estar disponibles para
consumidores remotos WSRP y permiten a los portales que se basan en Java consumir
portlets originarios de otros ambientes, por ejemplo .NET [34].
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
36
2.2.1 Estándar JSR 168 (The Java Portlet Specification, la especificación del portlet de
Java)
JSR 168 es una especificación de portlet del sistema de la comunidad Java [34].
Este estándar aborda la necesidad de permitir la interoperabilidad entre portales y portlets.
Ya que anteriormente era difícil hacer un sitio Web que le ofreciera a los usuarios la
posibilidad de acceder varios sistemas a partir de una sola página.
JSR 168 se enfoca a las siguientes temáticas: (1) el contrato del contenedor de
portlet y la administración del ciclo de vida, (2) la definición de los estados de ventana y los
modos del portlet, (3) administración de preferencias del portlet, (4) información del
usuario, (5) embalaje y despliegue, (6) seguridad; y (7) etiquetas JSP para ayudar al
desarrollo del portlet [35].
Los métodos del ciclo de vida que se invocan directamente por el contenedor son:
(1) init(), el cual se invoca cuando el portlet se concreta por el contenedor. Intenta contener
la lógica que prepara el portlet para atender solicitudes, (2) destroy (), el cual se invoca
cuando el contenedor destruye el portlet. Intenta contener la lógica que libera la memoria
cuando el portlet ya no se necesita o se apaga el servidor, (3) processAction(), el cual se
invoca después de que el usuario suministra cambios al portlet. Intenta procesar la entrada
desde una acción de usuario; y (4) render(), el cual se invoca siempre que el portlet se re-
invoca a través de la pantalla principal del sistema operativo.
Se puede extender una clase denominada GenericPortlet e implementar tantos de
estos métodos render() como sean necesarios para un portlet. Estos métodos son: (1)
doView(), el cual se invoca por render() cuando el portlet está en modo View. Intenta
contener la lógica que despliega la vista de la página del portlet, (2) doEdit(), el cual se
invoca por render() cuando el portlet está en modo Edit. Intenta contener la lógica que
despliega la página de edición para el portlet; y (3) doHelp(), el cual se invoca por render()
cuando el portlet está en modo Help. Intenta contener la lógica que despliega la página de
ayuda para el portlet.
Como indican los métodos que antes se mencionan, los modos que se definen en la
especificación del portlet son View, Edit y Help. En el modo View, el portlet debe
desplegar el contenido normal, que se basa en la funcionalidad que ofrece el portlet. En
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
37
modo Edit, el portlet debe presentar al usuario la posibilidad de personalizar cualquier cosa
que sea configurable para el portlet. El modo Help debe dar una descripción completa de
como el portlet se usa (explicando los modos Edit y View) o una ayuda sensitiva al
contexto explicando las características seleccionadas del portlet [3]. Por otra parte, los tres
estados de la ventana de cada portlet son: minimizado, maximizado o normal.
Los portlets a menudo se configuran para proveer una vista que se personaliza o
funciona para diferentes usuarios. En la especificación de portlet, su contenedor es
responsable de recuperar y almacenar estas preferencias a través de la interfaz
PortletPreferences.
La especificación portlet provee un mecanismo para acceder a la información de un
usuario – tales como nombre, correo electrónico, teléfono y dirección – en el descriptor que
se despliega de la aplicación del portlet
La especificación portlet describe el embalaje y despliegue de portlets como parte
del archivo de aplicación Web estándar (WAR) que permite contener otros componentes
Web, tales como JSPs y Servlets.
En la figura 2.1 se presenta un ejemplo de portlet, el cual permite apreciar una
visión general de los casos en que se invocan los métodos básicos de un portlet. Este portlet
es un portlet del clima para desplegar la temperatura sobre una página de portal.
Figura 2.1. El portlet del clima
El portlet del clima despliega información de temperatura para un código postal
dado. Se permite a los usuarios consultar la temperatura para códigos postales alternativos,
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
38
como se muestra en la figura 2.2. En dicha figura, se permite a los usuarios personalizar su
código postal y las unidades por omisión para desplegar la temperatura y en este ejemplo, el
portlet recupera la información del clima desde un servicio Web.
El primer método del portlet que se invoca es el método init(). El método init() se
invoca para inicializar el portlet antes de que el portal envíe alguna petición a él.
Figura 2.2. Edición de preferencias
En el método init(), el portlet del clima obtiene la URL del servicio Web del clima
desde un parámetro init e inicializa el objeto de servicio para él. Si el parámetro init está
ausente, o el servicio no puede inicializarse, el método lanza una excepción por
indisponibilidad y el portlet no está disponible para servir solicitudes.
Asumiendo que el portlet se inicializó correctamente, cuando los usuarios van al
portal y tienen el portlet del clima en su página, el método doView() se invoca para
interpretar el contenido del mismo. Este método se invoca cuando el portlet está en modo
view (vista).
Cuando los usuarios dan clic en el botón ―edit‖ de la barra de título del portlet, éste
cambia al modo Edit (edición) e invoca el método doEdit().
Cuando el usuario da clic en el botón ―help‖ sobre la barra de título del portlet, éste
cambia al modo HELP (ayuda) e invoca el método doHelp().
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
39
2.2.2 Estándar WSRP (Web Services for Remote Portlets, servicios Web para portlets
remotos)
Los servicios Web para portlets remotos (WSRP) son una especificación de OASIS
[34]. La especificación WSRP aborda el problema consistente en que la integración de
contenido y aplicaciones en portales requiere un significativo esfuerzo de programación.
Típicamente, los vendedores de portales u organizaciones que despliegan portales tienen
que escribir adaptadores especiales permitiendo a los portales comunicarse con proveedores
de aplicaciones y contenido adaptándose a una variedad de diferentes interfaces y
protocolos que usan los proveedores. El estándar WSRP de OASIS simplifica la integración
de aplicaciones y contenidos remotos en portales al grado que se permite a los
administradores de portal escoger desde una variedad de contenido y aplicaciones remotas e
integrarlas en su portal con poco esfuerzo de programación.
Las características de WSRP consisten en que: (1) estandariza los servicios Web en
la capa de presentación, (2) se sitúa en la pila de servicios Web existentes, según se muestra
en la figura 2.3, (3) construye sobre los estándares de servicios Web existentes; y (4) apoya
los esfuerzos de estándares de servicios Web adicionales, tal como esfuerzos de seguridad y
como ellos llegan a ser disponibles.
Las interfaces WSRP se definen en documentos WSDL (Web Services Description
Languaje, lenguaje de descripción de servicios Web). Además, WSRP define metadatos
para auto-descripción con el fin de publicar y encontrar servicios WSRP en registros (estos
constituyen un servicio de hospedaje que se ofrece por una compañía de tecnología de red,
por ejemplo Oracle, para registrar servicios WSRP de algún productor). Todos los servicios
WSRP requieren el uso de SOAP (Simple Object Access Protocol, protocolo de acceso de
objeto simple) para la invocación de servicios Web y opcionalmente soportan estándares
adicionales.
En relación a la importancia de la estandarización de los servicios Web en la capa
de presentación que hace WSRP hay que considerar que frecuentemente, el contenido se
obtiene de servicios externos y se despliegan en portlets locales específicos que se ejecutan
sobre el portal. Mientras este enfoque es factible para establecer la base funcional de un
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
40
portal, no conviene para la integración dinámica de fuentes de información y aplicaciones
de negocios en portales.
De acuerdo a la figura 2.3, WSRP se ajusta en un gran contexto de la pila de
estándares de servicios Web [16]. Para formalmente describir las interfaces de servicios
WSRP se utiliza WSDL; mientras que, para invocar los servicios WSRP puede usarse
SOAP. Además, WSRP se superpone con WSIA (Web Services for Interactive
Applications, servicios Web para aplicaciones interactivas) con quien comparte una base
común de interfaces y definición de protocolos.
Figura 2.3. WSRP y estándares que se relacionan
WSRP define la noción de fragmentos válidos de marcado que se basan en
lenguajes de marcado existentes tales como HTML, XHTML, VoiceXML, cHTML, entre
otros. Para lenguajes de marcado que soportan definiciones de estilos, WSRP también
define un conjunto de nombres estilo estándar permitiendo a los portlets generar el marcado
usando estilos que se proveen por portales manejables WSRP por lo que el marcado se
ajusta a la vista del usuario final del portal consumidor.
Una meta del estándar WSRP es implementar servicios que no solamente proveen
fragmentos de marcado, sino que también permiten servicios más complejos que requieran
(X)HTML WML Voz XML XHTML
Básico
…
WSRP WSIA WSRP/WSIA
Base común
WSDL
(Descripción)
SOAP
(Invocación)
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
41
registro del consumidor, soportar interacción de usuario compleja que se basa en estados
transitorios y persistentes [16]. Estos son: (1) servicio WSRP simple con vista solamente,
(2) servicios WSRP interactivos con estado conversacional transitorio, (3) servicios WSRP
interactivos con estado de entidad persistente, (4) servicio WSRP interactivo con estado de
entidad y estado de sesión; y (5) servicios WSRP con registro y revocación.
El servicio WSRP más simple posible provee una simple vista, sin alguna
interacción del usuario. Un ejemplo es un calendario o salidas de vuelo de un aeropuerto.
Los servicios WSRP interactivos con estado conversacional transitorio son un caso
más complejo con un servicio WSRP que soporta la interacción del usuario y mantiene el
estado conversacional reflejando la interacción del usuario. Un ejemplo es un servicio de
noticias que provee una descripción general de encabezados de los diferentes artículos de
noticias y permite a los usuarios dar clic sobre los encabezados para navegar al artículo
individual y sobre un vínculo de regreso.
Los servicios WSRP interactivos con estado de entidad persistente, en el mismo
nivel de complejidad del ejemplo anterior, son un servicio WSRP que mantiene un estado
persistente que se asocia con una instancia de portlet individual disponible desde el
productor WSRP. Un ejemplo para tal servicio es un servicio de cotización de acciones que
permite a usuarios individuales definir su portafolio personal. Este caso requiere el
concepto de múltiples entidades persistentes.
En los servicios WSRP interactivos con estado de entidad y estado de sesión, un
productor WSRP más complejo emplea tanto el estado de entidad persistente como el
estado de sesión transitorio. En un cierto tiempo, todas las sesiones WSRP se asocian con
una entidad persistente en un tiempo dado. Por ejemplo, muchas sesiones WSRP para la
misma entidad existen para un consumidor que es un portal con páginas que se comparten y
se usan concurrentemente por múltiples usuarios finales.
En los servicios WSRP con registro y revocación los proveedores de WSRP no
solamente soportan acceso para consumidores anónimos, sino que además, necesitan
implementar operaciones convenientes para registrar y borrar a consumidores.
Estos estándares los soportan determinados ambientes de desarrollo, entre ellos el de
Java Studio Creator que se seleccionó para el desarrollo de esta tesis.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
42
2.3. Ambientes de desarrollo con soporte para portlets
2.3.1. Java Sun Studio Creator
Es un ambiente de desarrollo Web visual para la plataforma Java. Se construyen
visualmente aplicaciones Web y portlets que se basan en estándares usando Java Server
Faces a través de una interfaz de usuario de drag and drop (arrastrar y soltar). Se simplifica
la integración con fuentes de datos heterogéneas tales como bases de datos relacionales,
JavaBeans Enterprice, servicios Web y también se incluyen otras características.
Las aplicaciones que se desarrollan con Java Studio Creator se despliegan en
contenedores J2EE estándares incluyendo el servidor de aplicaciones del sistema Java,
BEA WebLogic, IBM WebSphere, Tomcat entre otros [36].
2.3.2 WebLogic Workshop
En WebLogic Workshop, los portlets se editan visualmente en vista de diseño, y los
documentos JSPs se editan en vista de diseño y código fuente [37].
Opcionalmente, el portlet usa una página JSP, una página de flujo, o un archivo de
respaldo, y se construye conforme al estándar JSR 168 para garantizar la compatibilidad del
portlet. Los portlets consumen aplicaciones Web existentes y contenidos tales como:
páginas con tecnología ASP y JSP y documentos digitales de HTML o XML, entre otros
[37].
Se permite usar WebLogic Workshop para construir y mantener portlets remotos
manejables WSRP. WSRP es un estándar de servicio Web que permite ―enchufar y
ejecutar‖ servicios Web que se orientan visualmente al usuario con portales o aplicaciones
Web de otros intermediarios. Permite crear portlets que proveen contenido a otros portlets o
consumen contenido de otras fuentes [37].
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
43
2.3.3. IBM WebSphere Portlet Factory
IBM WebSphere Portlet Factory es un entorno que se especializa en el desarrollo de
portlets para crear, personalizar, desplegar y mantener con eficacia los portlets que
aprovechan las aplicaciones, bases de datos y otros recursos existentes [38].
WebSphere Portlet Factory permite a los desarrolladores crear rápidamente portlets
mediante la definición de una secuencia de componentes de software, reutilizables y
adaptables, denominados "Builders". Los Builders generan dinámicamente el código de la
aplicación, incluyendo Java Server Pages (JSP), clases Java y documentos XML, así como
todos los objetos de nivel inferior que componen la aplicación de portlet. De este modo, se
permite a los desarrolladores capturar y automatizar el proceso de creación de portlets
dinámicos, en lugar de codificar explícitamente cada portlet. Además, permite a los
desarrolladores crear con rapidez y facilidad varios portlets que se personalizan totalmente
a partir de una base de código, sin necesidad de realizar un nuevo despliegue o efectuar
cambios adicionales en el código [38].
2.3.4. Sun Java Studio Enterprise
Sun desarrolló Sun Java Studio Enterprise, la principal plataforma de desarrollo
empresarial y series de sistemas Java, la cual constituye la infraestructura para desplegar
servicios Web de arquitectura SOA (Service Oriented Architecture, arquitectura orientada a
servicio). Java Studio Enterprise permite desarrollar, depurar, probar y desplegar servicios
Web, y componentes de portal.
Java Studio Enterprise soporta la plataforma J2EE e integra el ambiente de
desarrollo (IDE) NetBeans. Java Studio Enterprise proporciona a través de NetBeans: (1)
modulación para integrarse con el lenguaje de modelado unificado (UML), (2) colaboración
instantánea del desarrollador, (3) un perfilador de aplicación empresarial, (4) constructor de
portlets, (5) kit de verificación de aplicación de Java, entre otros.
El Portlet Builder (constructor de portlets) permite: (1) crear portlets y proveedores
personalizados, (2) probar los canales en un ambiente integrado sin alguna configuración,
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
44
administración y requerimiento de autorización, (3) desarrollar con el servidor de portal
empresarial de Java Sun, lo cual significa elementos de portal empaquetados, tales como
portlets manejables JSR 168 de la petición de especificación Java, proveedores y canales; y
(4) crear, probar y empaquetar elementos de portal en el constructor de portlets, el cual se
permite desplegar sobre un servidor de portal local [39].
2.3.5. Borland JBuilder 2005 y la edición de desarrollo de Borland del portal de
aplicación Vignette
Borland y Vignette establecieron una solución combinada para ayudar a las
organizaciones a acelerar la creación de portlets con funcionalidad que se personaliza,
mejorando el diseño y calidad de las interfaces Web y consolidación de administración de
portlets funcionalmente dispares a través de la empresa.
La solución consiste en la creación de un portlet que se ―enchufa‖ en Borland
JBuilder 2005 y la edición de desarrollo de Borland del portal de aplicación Vignette. Esta
solución se diseñó para crear portlets que se personalizan y se basan sobre el estándar JSR
168 de Java proporcionando características de seguridad inherentes en el ambiente J2EE,
tiempo de desarrollo breve e incremento de la escalabilidad y el desempeño para
aplicaciones empresariales.
JBuilder 2005 y la edición de desarrollo de Borland de portal de aplicación Vignette
permite a los clientes mejorar la velocidad con la cual se desarrollan y despliegan portlets
de Java que se basan en estándares. Estos portlets tienen la opción de tomar ventaja de la
integración de servicios Web y de desplegarse para guiar servidores de aplicaciones J2EE
[40].
2.3.6. OracleAS Portal
OracleAS Portal es una aplicación Web que se utiliza para crear y desplegar
portales. Proporciona un entorno seguro y manejable para acceder e interactuar con
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
45
servicios de software de empresa y recursos informativos. Sus funciones clave son: (1) un
marco extensible que integra recursos que se basan en Web, 2) una interfaz que se
personaliza; y (3) funciones de publicación en autoservicio [41].
El marco extensible como páginas Web, aplicaciones, informes de inteligencia de
negocio y contenido de mediación dentro de componentes de información estándar
reutilizables se denominan portlets. Dentro de un portlet, estos recursos se personalizan y
gestionan como un servicio de OracleAS Portal. Se permite a las empresas crear sus
propios portlets para sus recursos Web y seleccionar portlets adicionales del catálogo cada
vez mayor de otros fabricantes proveedores de portlets. El marco del portal ofrece servicios
adicionales, como la conexión única, la clasificación de contenido, la búsqueda de empresa,
la integración de directorios y el control de acceso.
Finalmente, proporciona funciones de publicación en autoservicio que permiten a
los usuarios enviar y compartir cualquier tipo de documento o contenido Web con otros
usuarios [41].
2.4 Resumen
Los portlets son componentes Web que se basan en Java, que se gestionan por un
contenedor de portlets que procesa peticiones y genera contenido dinámico. Los portales
usan portlets como componentes de interfaz de usuario que proveen de una capa de
presentación a los sistemas de información. Los portlets son locales o remotos al portal
servidor.
Los portlets se basan en las especificaciones JSR 168 y WSRP. Estas
especificaciones son complementarias y actualmente tienden a adoptarse por proveedores y
consumidores de servicios Web gracias a estas ventajas: (1) JSR 168 define un API de
portlet estándar que es específico para portales que se basan en Java; y (2) WSRP define un
API universal que permite a los portales de cualquier tipo consumir portlets de cualquier
tipo.
Para el desarrollo de los portlets existen diversas IDEs, ejemplos de estas son: (1)
Java Sun Studio Creator, (2) IDE de WebLogic Workshop, (3) IBM WebSphere Portlet
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
46
Factory, (4) Sun Java Studio Enterprise, (5) Borland JBuilder 2005 y la edición de
desarrollo de Borland del portal de aplicación Vignette; y (6) OracleAS Portal.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
47
Capítulo 3. Componentes de la arquitectura del portal
empresarial
3.1. Introducción
Los portlets son componentes que permiten encapsular servicios Web y presentarlos
a los usuarios. Los portales de segunda generación se integran por portlets. Los portlets y
los servicios Web (servicios que se ofrecen mediante la Web, normalmente lo utilizan las
empresas) permiten integrar aplicaciones heterogéneas o fuentes de datos de una manera
consistente. Ambos proveen comunicación intra e inter-organizacional y un marco de
trabajo, que no obstante sus beneficios, requieren de una arquitectura que los integre
satisfactoriamente en un portal.
Las arquitecturas para portal producen beneficios potenciales a las empresas. Estos
son cuantitativos y cualitativos, y se reflejan, por ejemplo, en una mejor capacidad de
integración y en una reducción de costos de introducción para portales.
En este capítulo, se presentan los componentes de la arquitectura de portal
empresarial que aporta esta tesis.
3.2. Componentes de la arquitectura del portal empresarial
El portal que esta tesis presenta se enfoca hacia la industria del entretenimiento, por
lo que se ofrecen servicios Web de esta naturaleza. El portal presenta dos modos de
operación: el modo portal de Internet y el modo Proxy. El aspecto general de la arquitectura
se muestra en la figura 3.1.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
48
Figura 3.1. Aspecto general de la arquitectura
Los servicios Web que ofrece el portal son los que se describen en la tabla 3.1. El nombre
de éstos se refiere a su denominación en el sitio de Internet xmethods.net. Este sitio
presenta una lista de servicios Web públicamente disponibles.
Nombre del servicio Web Descripción
Ignyte's Retrieve Theaters and
Movie Showtimes.
Las películas que ofrecen los
cines para un determinado código
postal (USA).
USA Weather Forecast. La previsión del clima para un
determinado código postal o
ciudad (USA).
Horoscope web Services El horóscopo diario.
AmazonBox Búsqueda de productos en
Amazón.com.
Tabla 3.1. Descripción de los servicios Web del portal.
En el modo portal de Internet, a través de un navegador el cliente accede al portal,
en donde cada portlet ofrece un determinado servicio Web de entretenimiento. En el modo
Proxy se ofrece a los clientes un servicio de intermediario para determinados servicios
Web. En las siguientes secciones se describen, con más detalles, ambos modos.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
49
3.2.1 Modo portal de Internet
El portal empresarial, en su modo portal de Internet consta de determinados
componentes. Estos son: (1) el portal empresarial que se constituye por portlets, (2) el
contenedor de portlets; y (3) los proveedores de servicios Web. Además, existen entidades
externas al portal, estos son los clientes y los proveedores de servicios Web. Esto se ilustra
en la figura 3.2.
Figura 3.2. Portal empresarial en su modo portal de Internet
El portal recibe los portlets de un componente interno, que se denomina contenedor
de portlets. Este controla el ciclo de vida de los portlets y provee recursos e información
acerca de su ambiente. Estos portlets se despliegan, ordenadamente, en la página de portal
que se muestra al cliente.
El cliente, a través del navegador de su equipo de cómputo accede al portal en su
modo portal de Internet. Lo consulta, selecciona y solicita el consumo de un determinado
servicio Web que le presenta un determinado portlet. Ante ello, el portlet invoca al
correspondiente proveedor externo de dicho servicio. El proveedor externo recibe la
solicitud, la procesa, y envía la respuesta al portlet invocador. Este la presenta al cliente.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
50
3.2.2. Modo Proxy del portal.
Los portlets y los servicios Web tienen una estrecha relación para el portal, tanto en
su modo Proxy como en su modo portal de Internet. A causa de la importancia de los
servicios Web, primeramente se describe brevemente su marco teórico y relación con los
portlets. Con este conocimiento, se presenta la arquitectura del portal en su modo Proxy.
Para lo cual, se describe el desempeño individual e integral de sus componentes.
3.2.2.1. Relación entre servicios Web y portlets.
Con el fin de ofertar sus servicios a través de la Web, normalmente las empresas
utilizan los servicios Web. Existen empresas que son proveedoras y/o consumidoras de
estos. [42].
Un servicio Web es una clase cuya interfaz se hace pública en un servidor Web
mediante un lenguaje de descripción de interfaces (WSDL). Dicha interfaz ofrece un
conjunto de actividades que un cliente invoca. El cliente accede al servicio Web usando los
estándares de Internet [42], por ejemplo, HTTP.
Para acceder a un servicio Web se utilizan, opcionalmente, varios protocolos Web
estándar como HTTP GET o HTTP POST. Aunque se diseñó un protocolo específico para
ello: SOAP (Simple Object Access Protocol, Protocolo de acceso de objeto simple). Este
protocolo se basa en la utilización de HTTP para el transporte de mensajes y el lenguaje
XML para escribir el cuerpo de estos mensajes. Todo lo anterior permite a cualquier
aplicación generar e interpretar mensajes SOAP independientemente de la plataforma [42].
De tal forma que, los servicios Web, a través de sus protocolos y estándares: SOAP,
WSDL (Web Services Description Language, lenguaje de descripción de servicios Web) y,
también, UDDI (Universal Description, Discovery, and Integration, descripción,
descubrimiento, e integración universales), proveen un marco de trabajo inter-
organizacional. En síntesis, SOAP, WSDL y UDDI tienen funciones específicas que
ofrecen a los servicios Web: (1) SOAP para comunicarlos, (2) WSDL como un lenguaje de
descripción de interfaces; y (3) UDDI como un registro de especificaciones [43]. La
arquitectura del portal, en su modo Proxy, trabaja con los dos primeros.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
51
La relación entre los portlets y los servicios Web consiste en que 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 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, para portlets remotos, trabaja en este
sentido [21].
En relación al modo Proxy de la arquitectura de portal, ésta se ilustra en la figura
3.3.
Figura 3.3. Arquitectura del portal en modo Proxy
Para dicho modo, el cliente desarrolla una aplicación para consumir el servicio Web
que el portal le ofrece intermediariamente. En este caso, la intermediación tiene la ventaja
de otorgarle al cliente información con el formato de respuesta que se determinó como más
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
52
conveniente a sus necesidades. El cliente, de antemano, conoce dicho formato de respuesta
a través del documento WSDL que el portal, previamente, le proporcionó.
La aplicación que el cliente desarrolle, para el documento WSDL que tomó del
portal, le permitirá consumir el servicio Web del portal en modo Proxy.
3.2.2.2. Descripción de los componentes.
Tal como lo muestra la figura 3.3 los componentes de portal son los siguientes: (1)
el analizador de mensajes SOAP, (2) el selector de servicio, (3) el contenedor de portlets,
(4) el invocador, (5) el analizador de respuestas; y (6) el constructor de respuestas. Los
cuales se describen en esta sección.
Como sus nombres lo indican, el cliente y proveedor externo representan entidades
externas a la arquitectura del portal.
Figura 3.4. Documento WSDL del servicio Web ―Horoscope web Services‖, para los
clientes del portal en su modo Proxy.
<wsdl:message name="MessageRequest"> </wsdl:message>
…
<wsdl:message name="MessageResponse">
<wsdl:part name="Respuesta" type="xsd1:String"/>
</wsdl:message>
…
<wsdl:portType name="horoscopoPortType">
<wsdl:input message="tns:MessageRequest"/>
<wsdl:output message="tns:MessageResponse"/>
</wsdl:portType>
…
<wsdl:service name="horoscopo">
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
53
3.2.2.2.1. 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 la 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. Así, el analizador de mensajes SOAP centra su atención en la
etiqueta ―<wsdl:input message …‖ que pertenece a la etiqueta ―<wsdl:portType…‖.
En el ejemplo, que se muestra en la figura 3.4, el analizador de mensajes SOAP
determina que el método invocador, que se asignó para la aplicación del cliente, se llama
―MessageRequest‖ y no requiere argumento alguno.
3.2.2.2.2. El selector de servicio
Determina qué portlet implementa la funcionalidad que se demanda en la
comunicación que estableció el analizador de mensajes SOAP. Para ello, centra su atención
en el valor de ―name‖ de la etiqueta ―service‖.
En el ejemplo de la figura 3.4 la etiqueta ―service‖ presenta este contenido:
―<wsdl:service name=’horoscopo’>‖. De tal forma que el portlet que interesa es del
―horóscopo‖.
3.2.2.2.3. El contenedor de portlets
El contenedor de portlets proporciona un entorno de ejecución para los portlets. El
contenedor de portlets permite crear instancias de portlets y provee de medios para manejar
a éstos. Para los portales que se basan en Java este componente se basa en el estándar JSR
168. Éste estándar se concreta en Apache Pluto [44].
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
54
3.2.2.2.4. 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.
Así, el invocador centra su atención en la etiqueta ―<input message …‖ que, a su
vez, pertenece a la etiqueta ―<portType…‖ del documento WSDL.
En el ejemplo de la figura 3.5, el invocador determina que el método de invocación
se llama ―GetHoroscope‖ y éste no requiere argumento alguno.
3.2.2.2.5. 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 recoger la información de respuesta neta. Es decir, a la
información de respuesta se le extraen datos que ya no interesan, relativos al uso de los
estándares de servicios Web.
Por ello, el analizador de respuesta centra su atención en la etiqueta ―<output
message…‖ que, a su vez, pertenece a la etiqueta ―<portType…‖.
Para el ejemplo que se muestra en la figura 3.5, el analizador de respuesta determina
que el nombre del método, que el proveedor externo emplea para dar su respuesta, se llama
―GetHoroscopeResponse‖ y la respuesta es un dato de tipo String.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
55
Figura 3.5. Documento WSDL del servicio Web ―Horoscope web Services‖, del proveedor
externo del servicio para el portal en su modo Proxy.
<message name="GetHoroscopeSoapIn">
<part name="parameters" element="s0:GetHoroscope" />
</message>
…
<s:element name = "GetHoroscope">
<s:complexType />
</s:element>
…
<message name="GetHoroscopeSoapOut">
<part name="parameters" element="s0:GetHoroscopeResponse" />
</message>
…
<s:element name="GetHoroscopeResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetHoroscopeResult"
type="String " />
</s:sequence>
</s:complexType>
</s:element>
…
<portType name="HoroscopeSoap">
<operation name="GetHoroscope">
<input message="s0:GetHoroscopeSoapIn" />
<output message="s0:GetHoroscopeSoapOut" />
</operation>
</portType>
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
56
3.2.2.2.6. El constructor de respuestas
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ó. Para 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ó.
Con esta finalidad, centra su atención en la etiqueta ―<wsdl:output …‖ que, a su
vez, pertenece a la etiqueta ―<wsdl:portType …‖.
En el ejemplo que se muestra en la figura 3.4, el constructor de respuesta determina
que el método de respuesta al cliente se llama ―MessageResponse‖ y debe regresar un dato
de tipo String.
3.2.2.3. Funcionamiento de la arquitectura.
La forma de operar de los componentes de portal para satisfacer la meta del 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 están ejecutando en ambas partes.
Paso 2. Una vez que se establece la comunicación interviene el selector de servicio,
el cual analiza los parámetros de solicitud para determinar que portlet es el que implementa
la funcionalidad que se requiere y lo busca en el contenedor de portlets.
Paso 3. El contenedor de portlets provee el portlet correspondiente.
Paso 4. El portlet hace uso del 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, que análogamente al
analizador de mensaje, primeramente, requiere establecer la comunicación entre el
proveedor y el portal en modo Proxy, y cuya función principal es extraer los elementos de
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
57
respuesta que interesan, es decir, la información. Esta se pone a disposición del constructor
de respuesta.
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.
3.3. Resumen
Los portlets y los servicios Web son compatibles, ya que ambos comparten una base
común de estándares y protocolos, los cuales son de aceptación creciente entre proveedores
de contenidos y aplicaciones. Lo que permite apoyar a los portales como intermediarios
múltiples. Esencialmente, la diferencia entre los servicios Web y los portlets consiste en
que estos últimos agregan la capa de presentación a través de fragmento de marcado,
generalmente HTML. Ya que éste, es un estándar que se consolidó para los navegadores de
Internet.
En este capítulo se presentaron los componentes de la arquitectura del portal para
los dos modos de operación: modo portal de Internet y modo Proxy. Se presentó que para
ambos modos, los clientes y los proveedores de servicios son elementos externos. Además,
se observó que un elemento común para ambos modos es el contenedor de portlets, el cual
se encarga de gestionar el ciclo de vida de los portlets. En relación al modo Proxy, se
presentaron sus componentes: (1) analizador de mensajes SOAP, (2) selector de servicio,
(3) contenedor de portlets, (4) invocador, (5) analizador de respuestas; y (6) constructor de
respuestas.
Durante el la discusión de los componentes del portal, se observó que los
documentos WSDL son los contratos que especifican la forma de acceso de los clientes a
los servicios Web. En consecuencia, el portal para su modo Proxy entregó, a sus clientes,
los documentos WSDL que permiten a dichos clientes desarrollar las aplicaciones Web
respectivas. Mientras que el portal accede a los servicios Web, que requiere para sus modos
de operación, a través de los documentos WSDL que los proveedores externos entregaron
para este objetivo.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
58
Capítulo 4. Prestaciones de servicios del portal empresarial
4.1. Introducción
En este capítulo se describen los servicios que proporciona el portal en sus modos
portal de Internet y Proxy. Además, se presentan las tecnologías que permitieron el
desarrollo de ambos modos y se presentan las capas de prestaciones de servicios de la
arquitectura del portal que aporta esta tesis.
Para el modo portal de Internet, el cliente, a manera de usuario final, dispone de un
menú de opciones para acceder a los portlets del portal. Por otra parte, para el modo Proxy
del portal se presenta la API que permite consumir los servicios de este modo.
Finalmente, se describen las capas de prestación de servicios, las cuales son seis: (1)
presentación, (2) comunicación, (3) descubrimiento, (4) servicio, (5) lógica; e (6)
integración.
4.2. Modo portal de Internet
4.2.1. Interfaz gráfica del modo portal de Internet
En el modo portal de Internet, el cliente accede al portal a través de su navegador de
Internet. Una vez que el cliente realiza lo anterior, el portal presenta un menú de opciones
donde el cliente selecciona ya sea un determinado portlet o a todos ellos para mostrarse en
el portal.
El menú de opciones del portal consta de lo siguiente: (1) Portlet AmazonBox, (2)
Portlet USAWeather, (3) Portlet Horoscope, (4) Portlet Theaters, (5) Portlet
TheatersAndWeather; y (6) All portlets. Como su nombre lo indica, la opción que se
denomina ―All portlets‖ presenta a todos los portlets en el portal, como se ilustra en la
figura 4.1. Mientras que cualquiera de las otras opciones se restringe a presentar sólo al
portlet correspondiente a la opción.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
59
Figura 4.1. El modo portal de Internet con la opción activa ―All Portlets‖.
4.2.2. Tecnología de desarrollo para el modo portal de Internet
El portal se desarrolló con tecnología JSP que se complementa con lenguaje de
marcado HTML y requiere del contenedor de portlets. El portal se ejecuta en un servidor
con tecnología TomCat. Se opta por esta tecnología por las siguientes razones: (1) consume
pocos recursos del sistema en lo referente a memoria RAM, esto hace ágil al portal; y (2)
es open source. Emplear recursos con esta última característica es uno de los objetivos de
esta tesis. Por otra parte, TomCat realiza el soporte para portlets a través del compilador
que se denomina Jasper, que compila JSPs convirtiéndolas en servlets. (en términos
generales, los portlets son JSPs). Además, a causa de que Tomcat se programó en lenguaje
Java, funciona en cualquier sistema operativo que disponga de la máquina virtual Java[45].
4.2.3. Métodos del contenedor de portlets para el modo portal de Internet
La representación en UML del contenedor de portlets se muestra en la figura 4.2 A,
4.2 B y 42 C. Por otra parte, el empleo de los métodos del contenedor de portlets hacen
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
60
posible las formas de operación de los portlets. La utilización, por parte del usuario, de
dichas formas: minimizar, maximizar, normalizar, cerrar, modo edit y modo view se
informa a los respectivos métodos del contenedor de portlets. La tecnología JSP auxilia en
esta labor.
El contenedor de portlets controla el ciclo de vida de los portlets a través de
determinados métodos. Estos métodos se presentan y describen más abajo. El contenedor
de portlets se desarrolló en lenguaje Java y durante la invocación de sus métodos se apoya
de tecnología Java Server Pages. Debido a esto último, en la invocación de los métodos del
contenedor se observa el auxilio de instrucciones de dicha tecnología. Ello es necesario,
porque los métodos del contenedor de portlets requieren argumentos que recaban
información que procede de la capa de presentación, es decir, HTML. A través de HTML
se recaba información que se genera en las peticiones del usuario, cuando el usuario utiliza
las formas de operación del portlet.
En la práctica, el empleo de los métodos del contenedor de portlets requiere del
apoyo de una estructura condicional if-else. Se requiere la parte if para cubrir la acción de
concretar al objeto contenedor de portlets y a los portlets que éste hospeda. Entonces, la
parte if se ejecuta únicamente en la primera ocasión en que el usuario accede al portal, y en
las siguientes ocasiones se ejecuta la parte else. En esta parte else se recaba información
que se genera de la interacción de los usuarios con los portlets. En dicha parte, se
encuentran los métodos del contenedor de portlets que obtienen información actual del
estado de los portlets, lo cual es necesario al contenedor de portlets. Lo anterior ocurre cada
vez que el usuario utiliza las formas de operación del portlet y en consecuencia, re-invoca
la página del portal para el envío de información HTML. Finalmente, se coloca fuera tanto
de la parte if como de la parte else, a los métodos que proveen de fragmento de marcado
HTML a través de un dato de tipo String, el cual representa a los portlets para el usuario
final. Se ejemplifica el empleo de los métodos necesarios para un portlet en figura 4.3.
A continuación se presentan los métodos del contenedor de portlets en la secuencia
que se requiere y con una breve descripción de su funcionalidad.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
61
Figura 4.2 A. Representación en UML del contenedor de portlets.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
62
Figura 4.2 B. Representación en UML del contenedor de portlets.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
63
Figura 4.2 C. Representación en UML del contenedor de portlets.
ContenedorPortletsERD obj = new ContenedorPortletsERD("portal.jsp").- Se
emplea la clase ContenedorPortletsERD para crear un objeto de tipo contenedor de
portlets. Se requiere como argumento el nombre de la página JSP que hospeda al
portal en su modo portal de Internet.
obj.creaUnPortlet("AmazonBox","http://localhost:8080/AmazonBox", -
"myForm");.- Permite crear un portlet. Requiere como primer argumento el nombre
del portlet que se desea asignar, como segundo argumento la dirección del portlet en
su forma de archivo war y como tercer argumento el nombre del formulario que
emplea el portlet.
obj.setDimensionesdePortlet ("AmazonBox", "300", "500").- Establece las
dimensiones del portlet. El primer argumento se refiere al nombre del portlet y los
dos últimos argumentos se refieren al alto y ancho del portlet, respectivamente.
session.setAttribute("ProducePortlets", obj).- instrucción de tecnología JSP para
hospedar, en una variable de sesión, al objeto contenedor de portlets. El primer
argumento se refiere al nombre que se asigna a la variable de sesión que se crea, y el
segundo argumento es el objeto que se almacena en la variable de sesión.
ContenedorPortletsERD obj = (ContenedorPortletsERD)
session.getAttribute("ProducePortlets").- Igual que el caso inmediato anterior, se
trata de una instrucción de tecnología JSP. Solo que ahora con la finalidad de
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
64
recuperar al objeto contenedor de portlets que antes se almacenó en una variable de
sesión.
obj.setURL("AmazonBox", request.getParameter(obj.getArgumento("Amazon -
Box"))).- Tiene como finalidad informar al contenedor acerca de la URL actual de
un portlet determinado. Recibe como primer argumento el nombre del portlet, y el
segundo argumento se construye con apoyo de tecnología JSP. Para la construcción
del segundo argumento, la instrucción de tecnología JSP requiere, además, del
apoyo de un método que se denomina getArgumento, donde éste último requiere el
nombre del portlet.
obj.setEdosPortlets("AmazonBox",request.getParameterValues("AmazonBox")).
Informa al contenedor del portlets si el portlet en cuestión está minimizado,
normalizado, maximizado o cerrado. Requiere como primer argumento el nombre
del portlet, y para construir el segundo argumento requiere del apoyo de tecnología
JSP, donde ésta última requiere a su vez del nombre del portlet.
obj.setPropiedades(request.getParameterValues("ArgumentoEDIT")).- Informa al
contenedor si un portlet cualquiera ingresó al modo edit, y de ser así, recaba datos
tales como el nombre del portlet, el nuevo valor de alto, ancho y nueva URL.
Construye su argumento con apoyo de tecnología JSP, la cual a su vez requiere de la
expresión constante que se denomina "ArgumentoEDIT".
obj.setRestauraUnPortlet(request.getParameter("PortletSeleccionado")).- Informa
al contenedor de portlets, para un portlet que antes se cerró, que ahora el portlet se
restaura. Requiere construir su argumento con apoyo de tecnología JSP, la cual a su
vez, emplea una expresión constante que se denomina "PortletSeleccionado".
session.setAttribute("ProducePortlets", obj).- Después de que el contenedor de
portlets recibió información actual sobre los estados de los portlets, nuevamente,
requiere hospedarse en una variable de sesión JSP.
String[] ArgumentoEDIT = request.getParameterValues("ArgumentoEDIT").- El
arreglo de datos de tipo String que se denomina ArgumentoEDIT, recaba el nombre
del portlet que entró al modo de edición y los datos que se actualizan en este modo.
Para ello requiere de la instrucción
request.getParameterValues("ArgumentoEDIT"). Esta instrucción sólo puede
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
65
trabajar para un portlet a la vez, es decir, en un momento determinado, corresponde
sólo a un portlet ingresar al modo edit.
obj.setConservarValoresdeControlesHTML("AmazonBox", -
request.getParameter(obj.getArgumentoControlesHTML("AmazonBox"))); Este
método es necesario para conservar los datos de los controles del portlet, cuando
éste se minimiza, normaliza o maximiza. Necesita como primer argumento el
nombre del portlet y el segundo argumento se construye con apoyo de una
instrucción de tecnología JSP, la que a su vez, requiere del apoyo del método
getArgumentoControlesHTML que requiere como argumento el nombre del portlet.
ContenedorPortletsERD obj3 = (ContenedorPortletsERD)
session.getAttribute("ProducePortlets").- Se recupera el objeto contenedor de
portlets, desde un variable de sesión en la cual se almacenó previamente.
String ElementoForm = obj3.getElementoForm().-La variable de tipo String que se
denomina ElementoForm recaba un elemento propio de tecnología HTML
estrictamente necesario para el portal. Este elemento consiste de una etiqueta
“<form …”. Una vez que se consigue, es el primer elemento que necesariamente
requiere imprimirse en el portal.
String miopcionRecuperar = obj3.getOpcionRestaurarPortlet().- Permite obtener la
opción de restaurar a un portlet que previamente se cerró. Una vez que se obtiene la
variable que retorna este método, se procede a imprimir en el lugar que se considere
más conveniente.
String PortletAmazonBox = obj3.getUnPortlet("AmazonBox").- Obtiene el portlet
que se indica como argumento de este método. Luego, igual que en el caso
inmediato anterior, no existe restricción en relación al lugar que se elija para su
impresión.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
66
if (session.getAttribute("ProducePortlets")==null)
{
ContenedorPortletsERD obj = new ContenedorPortletsERD("portal.jsp");
obj.creaUnPortlet("AmazonBox", "http://localhost:8080/AmazonBox", "myForm");
obj.setDimensionesdePortlet ("Theaters", "300", "500");
session.setAttribute("ProducePortlets", obj);
}
else
{
ContenedorPortletsERD obj = (ContenedorPortletsERD) -
session.getAttribute("ProducePortlets");
obj.setURL("AmazonBox", -
request.getParameter(obj.getArgumento("AmazonBox")));
obj.setEdosPortlets("AmazonBox",request.getParameterValues("AmazonBox"));
obj.setPropiedades(request.getParameterValues("ArgumentoEDIT"));
obj.setRestauraUnPortlet(request.getParameter("PortletSeleccionado"));
session.setAttribute("ProducePortlets", obj);
String ArgumentoEDIT[];
ArgumentoEDIT = request.getParameterValues("ArgumentoEDIT");
obj.setConservarValoresdeControlesHTML("AmazonBox", -
request.getParameter(obj.getArgumentoControlesHTML("AmazonBox")));
}
session.setMaxInactiveInterval(86400);
ContenedorPortletsERD obj3 =
(ContenedorPortletsERD)session.getAttribute("ProducePortlets");
String ElementoForm = obj3.getElementoForm();
String PortletAmazonBox = obj3.getUnPortlet("AmazonBox");
String miopcionRecuperar = obj3.getOpcionRestaurarPortlet();
%><%= ElementoForm%> <!-- Es obligatorio imprimir primeramente -->
<%= PortletAmazonBox%> <%= miopcionRecuperar%>
Figura 4.3. Métodos del contenedor de portlets, en la secuencia y con la estructura
condicional if-else que se requiere para generar un portlet.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
67
4.3. Modo Proxy
Para que el portal ofrezca sus servicios de intermediación o servicio Proxy para
servicios Web de entretenimiento, requiere de una API. Una API (Application
Programming Interface, Interfaz de Programación de Aplicaciones) define los métodos a
través de los cuales un programador accede y controla un sistema determinado [46]. La
API del modo Proxy presenta los métodos que permiten otorgar los siguientes servicios de
entretenimiento: (1) AmazonBox, para buscar productos en la tienda virtual de
Amazon.com, (2) Horoscope web Services, proporciona el horóscopo de los doce signos
zodiacales, (3) Ignyte's Retrieve Theaters and Movie Showtimes, para la programación de
cines de un determinado lugar de los Estados Unidos de América; y (4) USA Weather
Forecast, para obtener la predicción del clima dado un código postal o lugar de los Estados
Unidos de América.
Como se muestra en la figura 4.4, la API Proxy se constituye de un paquete que se
denomina www.webservices. Este paquete contiene las clases: (1) AmazonBox, (2)
Horoscope, (3) Theaters; y (4) USAWeather. Dichas clases proveen, respectivamente, los
servicios de entretenimiento que se indican en el párrafo inmediato anterior.
En las secciones siguientes se presenta una visión general de la funcionalidad de los
documentos WSDL que se entregan a los clientes para que éstos desarrollen las
aplicaciones Web para consumo de los servicios Proxy y se muestran ejemplos de la
invocación y ejecución de estos servicios.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
68
Figura 4.4. Representación en UML de la API del portal para su modo Proxy
4.3.1. Servicio Proxy AmazonBox
El servicio Proxy de AmazonBox consiste en ofrecer intermediariamente el servicio
Web de AmazonBox. Este servicio, como ya se describió anteriormente, permite buscar
productos en Amazon.com en treinta líneas diferentes de estos.
Este servicio consta de treinta métodos. La descripción de estos métodos se presenta
en la tabla 4.1. Cada método busca un tipo determinado de producto. En la figura 4.5 se
presenta una ejemplificación, en caja negra, del funcionamiento general del documento
WSDL para los clientes del servicio Proxy AmazonBox.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
69
Método Producto a buscar
Por el método public String bookBox(String Keyword) Libros
public String babyBox(String Keyword) Para bebés
public String classicalMusicBox(String Keyword) De música clásica
public String dvdBox(String Keyword) DVD
public String electronicsBox(String Keyword) Electrónicos
public String gardenAndOutdoorLivingBox(String
Keyword)
Jardín y casa al aíre libre
public String kitchenAndHousewaresBox(String
Keyword)
Cocina y mercancías de la casa
public String magazinesBox(String Keyword) Revistas
public String popularMusicBox(String Keyword) Música popular
public String computerHardwareBox(String Keyword) Hardware de computadora
public String cameraAndPhotoBox(String Keyword) Cámara y fotos
public String computerSoftwareBox(String Keyword) Software de computadora
public String toysAndGamesBox(String Keyword) Juguetes y juegos
public String toolsAndHardwareBox(String Keyword) Herramientas y hardware
public String videoBox(String Keyword) Videos
public String computerAndVideoGamesBox(String
Keyword)
Computadora y video juegos
public String authorBox(String Keyword) Por autor
public String musicianPopularMusicBox(String
Keyword)
Música popular por músico
public String musicianClassicalMusicBox(String
Keyword)
Música clásica por músico
public String actorDvdBox(String Keyword) Por actor en DVD
public String actorVideoBox(String Keyword) Por actor en video
public String directorDvdBox(String Keyword) Por director en DVD
public String directorVideoBox(String Keyword) Por director en video
public String manufacturerElectronicsBox(String
Keyword)
Electrónicos por fabricante
public String
manufacturerKitchenAndHousewaresBox(String
Keyword)
Cocina y mercancías de la casa por
fabricante
public String
manufacturerComputerAndVideoGamesBox(String
Keyword)
Computadora y video juegos por
fabricante
public String
manufacturerComputerSoftwareBox(String Keyword)
Software de computadora por
fabricante
public String
manufacturerCameraAndPhotoBox(String Keyword)
Cámara y fotos por fabricante
public String
manufacturerComputerHardwareBox(String Keyword)
Hardware de computadora por
fabricante
public String similaritiesBox(String Keyword) Similares
Tabla 4.1. Métodos del servicio Proxy AmazonBox
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
70
Para cada método, se requiere proporcionar una palabra clave relacionada al tipo de
producto que se desea. Por otra parte, todos los métodos retornan la respuesta en un dato de
tipo String.
En consecuencia, el documento WSDL establece que los métodos del servicio
requieren como argumento de invocación una palabra clave relacionada al tipo de producto
a buscar. Por ello, para el argumento de invocación de cada método se tiene treinta
elementos diferentes cuyos nombres terminan con la palabra Keyword, todos de tipo String.
Estos almacenan la palabra clave del producto a buscar. Además, se establece que los
métodos tienen, para el retorno de la respuesta al cliente, un elemento que se denomina
―Response‖ de tipo String.
En la figura 4.6 se presenta un ejemplo de la invocación de un método de este
servicio Proxy. Dicho método se denomina ―getBook‖ y se usó la palabra clave ―Java‖. En
la figura 4.7 se presenta la ejecución de éste método.
Figura 4.5. Ejemplificación, en caja negra, del empleo de los métodos del documento
WSDL para el servicio Proxy AmazonBox
Métodos de
AmazonBox String KeyWord String Response
…
…
n
…
…
n
Clases en Java
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
71
Figura 4.6. Ejemplo de invocación de un método, el método getBook, del servicio Proxy
AmazonBox.
Figura 4.7. Ejemplo de ejecución de un método, el método getBook,
del servicio Proxy AmazonBox.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
72
4.3.2. Servicio Proxy Horoscope
El servicio Proxy Horoscope consiste en ofrecer intermediariamente el servicio Web
del mismo nombre. Este servicio, como ya se describió anteriormente, permite obtener la
predicción del horóscopo para los doce signos zodiacales.
En la figura 4.8 presenta una ejemplificación, en caja negra, del funcionamiento
general del documento WSDL del servicio Proxy Horoscope. Este servicio consta de un
único método y para su invocación no se requiere proporcionar argumento alguno. En el
documento WSDL se establece que el método del servicio regresa una respuesta de tipo
String. Para este objetivo se establece un elemento que se denomina ―Response‖ de tipo
String.
En la figura 4.9 se presenta un ejemplo de la invocación del método del modo Proxy
Horoscope. Para ello se ejecuta el método denominado getHoroscope sin argumento
alguno. En la figura 4.10 se presenta la ejecución de dicho método.
Figura 4.8. Ejemplificación, en caja negra, del empleo del método getHoroscope
del documento WSDL para el servicio Proxy Horoscope
Figura 4.9. Ejemplo de invocación del método del servicio Proxy Horoscope que se
denomina getHoroscope.
Método de la clase
Horoscope:
getHoroscope()
String Response
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
73
Figura 4.10. Ejemplo de ejecución del método del servicio Proxy Horoscope que se
denomina getHoroscope.
4.3.3. Servicio Proxy Theaters
El servicio Proxy Theaters consiste en ofrecer intermediariamente el servicio Web
que se denomina Ignyte's Retrieve Theaters and Movie Showtimes. Este servicio, como ya
se describió anteriormente, permite obtener la programación de cines para un determinado
código postal de los Estados Unidos de América.
En la figura 4.11 se presenta la funcionalidad general, en caja negra, del documento
WSDL del servicio Proxy Theaters. Este servicio se provee por medio de un único método.
Dicho método se denomina getShowTimes y para su invocación se requiere un argumento
de tipo String para enviar el código postal. Por otra parte, se establece que el método del
servicio retornará su respuesta en un dato de tipo String. En consecuencia, para la respuesta
se estableció un elemento que se denomina ―Response‖.
La clase Theaters presenta un único método para la invocación del servicio. Este
método se denomina getShowTimes. En la figura 4.12 se presenta un ejemplo de la
invocación del método y en la figura 4.13 se presenta su ejecución.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
74
Figura 4.11. Ejemplificación, en caja negra, del empleo del método getShowTimes del
documento WSDL para el servicio Proxy Theaters
Figura 4.12. Ejemplo de invocación del método del servicio Proxy Theaters que se
denomina getShowTimes.
Figura 4.13. Ejemplo de ejecución del método del servicio Proxy Theaters que se denomina
getShowTimes
Método de la clase
Theaters:
getShowTimes ()
String CodigoPostal String Respuesta
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
75
4.3.4. Servicio Proxy USAWeather.
El servicio Proxy USAWeather consiste en ofrecer intermediariamente el servicio
Web USA Weather Forecast. Este servicio, como ya se describió anteriormente, permite
obtener la predicción del clima para un determinado código postal o lugar de los Estados
Unidos de América.
En la figura 4.14 se presenta la ejemplificación, en caja negra, de la funcionalidad
general del documento WSDL del servicio Proxy USAWeather. Este servicio consta de dos
métodos para obtener la predicción del clima. Estos métodos se denominan:
getWeatherByZipCode y getWeatherByPlaceName. El primero de ellos requiere de un dato
de tipo String para enviar el código postal del lugar, de los Estados Unidos de América,
sobre el que se desea la predicción del clima. El segundo método, para el mismo objetivo,
requiere un dato de tipo String para el nombre del lugar.
En consecuencia, en el documento WSDL se establecen los elementos de nombres:
―ZipCode‖, ―PlaceName‖ y ―Response‖. Todos de tipo String. Los dos primeros elementos
se utilizan para proveer el código postal o el nombre del lugar, respectivamente. Mientras
que el elemento denominado ―Response‖ lo utilizan ambos métodos para entregar la
respuesta del servicio.
En la figura 4.15 se presenta la invocación de uno de los métodos del servicio y en
la figura 4.16 se presenta su ejecución.
Figura 4.14. Ejemplificación, en caja negra, del empleo de los métodos del documento
WSDL para el servicio Proxy USAWeather
Métodos de la
clase
USAWeather:
String ZipCode String Response
String PlaceName String Response
getWeather
ByZipCode ()
getWeather
ByPlace
Name()
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
76
Figura 4.15. Ejemplo de invocación de un método del servicio Proxy USAWeather que se
denomina getWeatherByZipCode.
Figura 4.16. Ejemplo de ejecución de un método del servicio Proxy USAWeather que se
denomina getWeatherByZipCode..
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
77
4.3.5. Tecnología de desarrollo para el modo portal Proxy
La construcción del modo Proxy requirió, primeramente, de la construcción de los
documentos WSDL para los servicios de este modo. Para ello, se empleó el programa que
se denomina SOA Editor. Una vez que se obtuvieron dichos documentos, se requirió del
ambiente de desarrollo integrado NetBeans 5.5 para tres fines principales: (1) obtener
clientes para el consumo de los servicios Web que proveen los proveedores externos al
portal. Esto, gracias a los documentos WSDL que dichos proveedores previamente
proporcionaron, (2) programar, en lenguaje Java, los diferentes servicios Web Proxy para
atender a los clientes del portal. Esto, gracias a los documentos WSDL que previamente se
construyeron para este objetivo; y (3) obtener el servidor para ofrecer el modo Proxy.
4.4. Capas de prestaciones de servicios de la arquitectura del portal.
La arquitectura que se propone se compone por seis capas, las cuales son: (1)
presentación, (2) comunicación, (3) descubrimiento, (4) servicio, (5) lógica; e (6)
integración. La arquitectura compuesta en capas se muestra en la figura 4.17.
Generalmente, estas capas proveen servicios a los dos modos de operación del portal. Sin
embargo, la capa de presentación es exclusiva al modo portal de Internet. A continuación,
se presenta los servicios que ofrece cada capa y en que consisten.
4.4.1. Capa de presentación
La capa de presentación ofrece el servicio de interfaz al usuario final para el modo
portal de Internet. Los servicios de la capa de presentación consisten en:
(1) reunir información del usuario final o cliente. Este objetivo se logra a través de
formularios HTML que el portlet presenta de acuerdo al tipo de servicio que atiende.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
78
(2) enviar dicha información a la capa de descubrimiento para que ésta determine el portlet
que se requiere. Se envía a través de HTTP cuando el portal recibe la orden por medio
de su menú.
(3) recibir información de respuesta desde la capa de integración. Esto se logra a través de
una instrucción output que permite a un programa en JSP transmitir información a
formato HTML y que se exterioriza en el navegador de Internet.
(4) presentar, la información del punto anterior, ordenadamente al usuario final. Este
objetivo se logra a través de elementos típicos de HTML, por ejemplo, tablas, listas de
selección, áreas de texto, entre otros.
4.4.2. Capa de comunicación
Para los clientes del modo portal de Internet la comunicación opera con el protocolo
HTTP; mientras que para el modo Proxy es el mensaje SOAP. Para los clientes del modo
Proxy, y del portal con los proveedores externos, se provee la comunicación a través de
mensajes SOAP. Los mensajes SOAP emplean HTTP como protocolo de transporte,
aunque también pueden emplear otros protocolos como SMTP (Simple Mail Transfer
Protocol, protocolo simple de transferencia de correo electrónico), FTP (File Transfer
Protocol, protocolo de transferencia de archivos), entre otros. SOAP utiliza generalmente
HTTP por ser éste un protocolo de amplia difusión y porque el puerto HTTP generalmente
no se protege (80 es su puerto por defecto). Por otra parte, los servicios de la capa de
comunicación consisten en:
(1) permitir la comunicación con el portal. En el caso del modo portal de Internet es a
través de HTTP y en el caso del modo Proxy es a través de un mensaje SOAP. En
esta última situación interviene el componente que se denomina analizador de
mensajes SOAP, el cual atiende a la aplicación del cliente que demanda el consumo
de un servicio. La aplicación del cliente está en condiciones de construir dicho
mensaje SOAP gracias a que, previamente, se proporcionó, al cliente, el documento
WSDL del servicio Web respectivo.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
79
(2) solicitar el servicio que se requiere al proveedor externo del portal. Esto a través de
un mensaje SOAP. Este se construye con los requerimientos que se indican en el
documento WSDL que el proveedor externo previamente suministró; y
(3) enviar a la aplicación del cliente la información de respuesta que provee el
componente que se denomina constructor de respuesta. La respuesta se envía a
través de un mensaje SOAP. Para el modo portal de Internet, la comunicación opera
con el protocolo HTTP.
En relación al mensaje SOAP, éste permite dirigir, generalmente a través de HTTP, un
mensaje de petición al servidor del servicio Web correspondiente, y ya en el servidor,
permite invocar un servicio específico proveyendo, además, los parámetros necesarios para
ello.
4.4.3. Capa de descubrimiento
La capa de descubrimiento ofrece el servicio de identificar al portlet que
implementa el servicio que demanda el cliente, ya sea para el modo portal de Internet o
para el modo Proxy. El servicio de descubrimiento consiste en:
(1) descubrir al portlet que se requiere. Ello se realiza a través de identificar al servicio
que se indica en el mensaje SOAP que recibió la capa de comunicación. Con el cual
se realiza una consulta y selección de servicio por nombre; y
(2) solicitar el portlet que se demanda desde el modo Proxy, según descripción del
punto anterior, o que se demanda desde el modo portal de Internet al componente
que se denomina contenedor de portlets. Esta solicitud se realiza a través del
nombre del portlet.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
80
4.4.4. Capa de servicio
La capa de servicio hospeda los diversos servicios que provee el portal. Esto lo
realiza a través del componente que se denomina contenedor de portlets. Los servicios de
esta capa consisten en:
(1) proporcionar al portlet con los recursos e información necesaria para que éstos
entreguen al portal información y contenidos dinámicos. Esto es posible gracias a
las formas de operación de los portlets. Estas formas de operación se ofrecen a los
usuarios a través de botones de los portlets. Éstos, al ser accionados por los usuarios
constituyen órdenes de formas de operación del portlet. Estas órdenes se crean,
primeramente, con tecnología HTML y que, inmediatamente, se recaban por
variables de JSP y se transmiten al contenedor de portlets a través de los métodos
correspondientes.
(2) proveer el portlet que solicita la capa de descubrimiento. El menú del portal permite
disponer de los portlets. Al elegir una opción en el menú se establece una orden,
primeramente, de tecnología HTML e inmediatamente sigue una situación análoga
a la que se describe en el punto inmediato anterior; y
(3) hospedar al componente que se denomina contenedor de portlets, el cual realiza los
dos objetivos anteriores.
4.4.5. Capa lógica
La capa lógica provee los mecanismos de control del sistema a través de los portlets.
Los servicios de esta capa consisten en:
(1) aplicar reglas de validación a datos que provienen de la interfaz de usuario. Esto se
refiere a validación de datos tal como que el dato que se provea sea un entero y no
otro, por citar un ejemplo.
(2) proveen los componentes que se denominan: analizador de respuestas y
constructor de respuestas, los cuales son necesarios para formulación de
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
81
respuestas. El constructor de respuesta se provee a través de un método el cual se
encarga de articular el dato de respuesta.
4.4.6. Capa de integración
La capa de integración provee el servicio de construcción de respuestas. Este
servicio se proporciona a través de los componentes: invocador, analizador de respuestas y
constructor de respuestas. Los servicios de la capa de integración consisten en:
(1) Invocar al proveedor externo el servicio que demanda el cliente. Esto se realiza a
través de un mensaje SOAP.
(2) extraer la información neta de respuesta desde la información que se recibe del
proveedor externo. Esta información neta se constituye o bien por algún tipo de
dato o por una estructura de datos compleja. Este resultado se obtiene a través del
analizador de repuestas, y éste transmite dicho resultado al constructor de
respuesta.
(3) construir la información de respuesta, a través del constructor de respuesta, de
acuerdo a especificación que se realizó al cliente en el documento WSDL que se le
entregó. Para los servicios del portal en su modo Proxy la información neta de
respuesta consiste en un dato de tipo String, el cual contiene a la respuesta y la
presenta con fragmento de marcado HTML. Para alcanzar este resultado, el
constructor de respuesta realiza su labor a partir de desarticular los datos que se
reciben del proveedor externo y con ello construir la respuesta. Lo anterior, se
logra, simplemente, con programación en código Java; y
(4) remitir a la capa de comunicación para que ésta la transmita al cliente respectivo,
tanto para el modo Proxy como el para el modo portal de Internet. En el primer
caso, se realiza a través de un mensaje SOAP y en el segundo caso, la clase java
provee la respuesta, primeramente, a un archivo JSP a través del retorno de
respuesta de un método del contenedor de portlets. A su vez, el archivo JSP genera
una salida (output) con fragmento de marcado HTML. Esta respuesta se recibe por
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
82
el usuario final gracias a su navegador con conexión a Internet, donde opera el
protocolo HTTP.
Figura 4.17. La arquitectura de portal en capas.
4.5. Resumen
Se presentaron las prestaciones de servicios del portal empresarial. Se mostró que
estas prestaciones consisten en dos modos de operación del portal: modo portal de Internet
y modo Proxy. Estos servicios se proveen a través de la arquitectura que se propone, la
cual se divide en capas.
Para que el cliente obtenga los servicios del portal en su modo portal de Internet
requiere acceder al portal a través de su navegador de Internet y elegir alguna opción que
presenta el menú de opciones del portal con el fin de disponer de algún portlet o de todos
ellos juntos. Por otra parte, para la labor de diseño del portal se presentaron los métodos
que gestionan el ciclo de vida de los portlets.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
83
En relación a los servicios Proxy, el cliente requiere recibir del portal los respectivos
documentos WSDL para acceder a estos servicios. Una vez hecho lo anterior, el cliente
requiere desarrollar las aplicaciones Web correspondientes. Estas aplicaciones disponen de
la API del modo Proxy, necesaria para el consumo de los servicios de éste modo.
Finalmente, se presentó una arquitectura bajo diferentes niveles de prestación de
servicios. La arquitectura propuesta presenta seis capas: (1) presentación, (2)
comunicación, (3) descubrimiento, (4) servicio, (5) lógica; e (6) integración.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
84
Capítulo 5. Casos de estudio
5.1. Introducción
En este capítulo se presentan casos de estudio que demuestran las ventajas que un
portal de segunda generación, que se constituye por portlets, ofrece al usuario. En general,
la tecnología de portlets evita, al usuario, la necesidad de visitar infinidad de sitios o
portales dispersos para recibir los servicios que el portal ofrece a través de sus portlets.
5.2. Caso de estudio: una búsqueda de programación de cines
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 la
arquitectura propuesta, 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 el portlet Theaters se tiene el caso de estudio con el siguiente escenario:
1. Un usuario desea conocer la programación de películas para un determinado lugar
de los Estados Unidos de América.
2. Existen varios sitios o portales dispersos que ofrecen la programación de
películas.
En este escenario, ¿cómo puede el usuario encontrar la programación de películas
sin visitar tantos sitios o portales dispersos?.
Para contestar la pregunta que se describe en el escenario, es necesario que el
usuario utilice el portal propuesto. En la Figura 5.1, se muestra una interfaz gráfica del
portal con sus primeros cuatro portlets. Este portal presenta un portlet denominado Theaters
(el cual se muestra en estado de presentación, en la figura 5.2a, y en estado de ejecución, en
la figura 5.2b y 5.2c). El portlet Theaters presenta el servicio de entretenimiento consistente
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
85
en la programación de películas que ofrecen los cines para un determinado código postal de
los Estados Unidos de América.
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 proporciona. Si
elije la primera opción, corresponde al usuario 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 elije la segunda opción, concierne al usuario seleccionar la
casilla ―By theater‖ y oprimir el botón ―get ShowTimes‖. Luego, el portlet despliega la
lista de cines. Entonces, atañe al usuario elegir un determinado cine y oprimir el botón
―Show‖. En seguida, el portlet despliega una tabla con la programación de películas del
cine que seleccionó. Si elije la tercera opción, incumbe al usuario seleccionar la casilla ―By
film‖ y oprimir el botón ―get Show Times‖. Inmediatamente, el portlet presenta al usuario
una lista con las películas. Entonces, concierne al usuario elegir una determinada película y
oprimir el botón ―Show‖. Enseguida, el portlet despliega al usuario una tabla con todos los
cines que ofrecen esa determinada película.
El portal es de gran ayuda al usuario, porque éste no necesita visitar infinidad de
sitios o portales para encontrar la programación de películas de interés.
Figura 5.1. Portal con los primero cuatro portlets
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
86
(a) En presentación. (b) En ejecución, primera parte.
(c) En ejecución, segunda parte
Figura 5.2. El portlet Theaters en presentación y en ejecución
5.3 Caso de estudio: ayuda en la toma de decisión para la asistencia al
cine.
El caso de estudio de la presente sección ayuda al usuario a tomar la decisión si
asiste o no al cine. Debido a que, además de la programación de cines para un determinado
lugar, también se muestra la previsión del clima para ese mismo lugar. El escenario es el
siguiente:
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
87
1. Un usuario desea conocer la programación de películas para un determinado lugar
de los Estados Unidos de América, y además, desea conocer la previsión del clima para el
mismo lugar para decidir si asiste no al cine.
2. Existen un grupos de sitios o portales dispersos que ofrecen la programación de
películas y la previsión del clima.
En este escenario, ¿cómo puede el usuario obtener la programación de cines y la
previsión del clima para con ello tomar la decisión si asiste o no?.
Para contestar la pregunta que se describe en el escenario, es necesario que el
usuario utilice nuestro portal, el cual presenta un portlet denominado
TheatersAndUSAWeather. Este portlet presenta el servicio de entretenimiento consistente
en la programación de películas que ofrecen los cines y la previsión del clima para un
determinado código postal de los Estados Unidos de América.
Este portlet, TheatersAndUSAWeather, se muestra en su estado de presentación
inicial al usuario en la figura 5.3, y en relación a su estado de ejecución, éste tiene el mismo
contenido al que se presentó, anteriormente, en la figura 5.2b y 5.2c para el portlet
Theaters. Sin embargo, la diferencia consiste en que al resultado final, el presente portlet
agrega una tabla con la previsión del clima tanto en grados centígrados como Fahrenheit
para el código postal que proporcionó el usuario como se muestra en la figura 5.4. El modo
de operar del portlet se describe a continuación.
Figura 5.3. El portlet TheatersAndUSAWeather en su presentación inicial al usuario.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
88
Para ofrecer sus servicios, el portlet TheatersAndUSAWeather primeramente
solicita, al usuario, que elija un estado de los Estados Unidos de América. Con esta
información, el portlet presenta una lista de las cinco principales ciudades de dicho estado.
A continuación, solicita, al usuario, que seleccione una determinada ciudad entre las que
presenta. Una vez que el usuario hace lo anterior, el portlet presenta una lista con los
códigos postales de dicha ciudad. Entonces, el portlet solicita al usuario que elija un
determinado código postal. Una vez que el usuario el selecciona el código postal, el portlet
solicita, al usuario, que seleccione un radio de acción (perímetro que cubre la búsqueda) y
que elija un tipo de consulta: (1) general, (2) por cine; y (3) por película. A continuación, el
portlet despliega la respuesta al usuario como se aprecia en la figura 5.4.
Figura 5.4. El portlet TheatersAndUSAWeather en ejecución.
A continuación se describen los argumentos de la tecnología de portlets que
permiten las ventajas al usuario que se mostraron en los casos de estudio.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
89
5.4. Fundamentos de la tecnología de portlets que explican sus ventajas en
sus servicios al usuario.
Los casos de estudio que se describieron demuestran ventajas características de los
servicios de los portlets. Porque el usuario no necesita saber qué empresas u organizaciones
proveen el servicio Web de entretenimiento que el portlet presenta. En este sentido, el
usuario delega al portal la tarea del consumo de dichos servicios Web a través del portlet.
El usuario solicita un servicio de entretenimiento a través de la interfaz que el portlet
presenta. El 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.
Por otra parte, el portal tiene la ventaja de ser adaptable y de presentar 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 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.
La capacidad de asignar a los portlets la distribución que se considere más
conveniente al portal asigna a éste la cualidad de adaptable. Ello es posible dada la
condición de los portlets de constituir componentes Web. Esta condición permite a los
portlets versatilidad para desarrollarse y desplegarse manejablemente. Además, dado que
un portlet es un componente, ello muestra a los portlets como un encapsulado de una
aplicación Web para utilizarse dentro de un portal.
Por otra parte, el portal es atractivo al usuario porque además de los portlets
comentados en los anteriores casos de estudio, el portal que se propone también presenta
otros portlets, tales como Amazon.com, USAWeather y Horoscope.
El portlet Amazon.com ofrece, en un contexto de comercio electrónico, la búsqueda
de productos en treinta líneas diferentes de éstos. Este servicio es del tipo B2C (Business to
Consumer) y sólo permite consultar los productos que se desean, no ofrece servicio de
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
90
carrito de compras. Para consumir los servicios de este portlet se requiere una palabra clave
con relación al producto de interés, y además, se requiere elegir un tipo de línea de
producto. De tal forma que, por ejemplo, si se desean libros de Java. Entonces la palabra
clave es ―Java‖ y la línea de producto a seleccionar es ―libros‖.
El portlet USAWeather ofrece la predicción del clima para los más importantes
códigos postales o ciudades de los Estados Unidos de América. Este servicio se presenta
con las opciones siguientes: (1) grados centígrados, (2) grados Fahrenheit; y (3) ambos. En
cualquiera de las tres opciones, el servicio presenta la predicción del clima para los siete
días de la semana, e indica la temperatura máxima y mínima tanto en grados centígrados
como en grados Fahrenheit. Para consumir los servicios de este portlet se requiere
proporcionar el código postal o el nombre de una ciudad. Además, se requiere elegir el tipo
de grado en que se desea la consulta.
El portlet Horoscope ofrece la predicción diaria del horóscopo para los doce signos
zodiacales. Todos los vaticinios se presentan en idioma inglés y para cada uno de éstos se
muestra una redacción de un párrafo con alrededor de diez líneas de contenido. El portlet
Horoscope ofrece dos tipos de consulta: (1) todos los signos; y (2) un signo en específico.
Si se opta por la primera opción se requiere seleccionar, de la lista que presenta el portlet, la
opción que se denomina ―All signs‖. En caso contrario, de la misma lista anterior, se
selecciona un signo zodiacal en concreto y se invoca el servicio.
5.5. Resumen
En este capítulo se presentaron dos casos de estudio. Ambos describen una
problemática a la que se enfrenta un cliente, el escenario que se presenta dicha
problemática y que el portal, a través de sus portlets, está en condiciones de resolver. En
consecuencia, en este capítulo, también se hizo énfasis en fundamentos tecnológicos que
permiten a los portlets ofrecer sus respectivas soluciones.
El primer caso de estudio se enfocó en describir la solución que un portlet ofrece a
un cliente que dispersa su tiempo al tener que buscar la programación de cines en múltiples
sitios. El segundo caso de estudio presentó, a otro portlet, con la misma solución a la
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
91
problemática anterior; pero que además, ayuda al cliente a decidir si asiste o no al cine dado
que agrega la predicción del clima.
Finalmente, en la sección de los fundamentos de la tecnología de portlets que
explican sus ventajas al usuario se realizó una discusión sobre las ventajas que implican los
mecanismos a los cuales acceden los portlets, es decir, los servicios Web. Además, se
mostró la cualidad de adaptabilidad de la arquitectura que se propone. Dicha cualidad
permite adecuar, en tiempo de diseño, la colocación de los portlets en el portal. Por otra
parte, la cualidad de adaptabilidad se presenta de los portlets hacia los clientes a través de
servicios que facilitan las experiencias de interacción de los clientes.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
92
Capítulo 6. Conclusiones
6.1. Conclusiones generales
Esta tesis cumplió con su objetivo general de presentar el diseño y construcción de
un portal empresarial utilizando la tecnología de portlets. En forma más detallada, el
objetivo general de la tesis consistió en el diseño y construcción de un portal empresarial
con base en el desarrollo de una aplicación Web, que se gestione por un contenedor de
portlets. El contenedor de portlets provee un entorno de ejecución para los portlets, ello
permite a los portlets generar, dinámicamente, fragmento de marcado HTML al portal. En
consecuencia, la hipótesis estableció que como apoyo a dicho objetivo se utilice tecnología
open source (código abierto), dado que ello otorga al sistema a desarrollar la característica
de la portabilidad.
El objetivo de esta tesis tuvo su correspondiente motivación. La razón de utilizar la
tecnología de portlets, para portales de segunda generación, consiste en superar
restricciones de los portales monolíticos de la primera generación. Restricciones que causan
dificultad de desarrollo y mantenimiento. Mientras que el enfoque orientado a componentes
basado en portlets, favorece el desarrollo, mantenimiento y re-uso. Por otra parte, el portal
se enfoca al entorno empresarial con la funcionalidad de la industria del entretenimiento.
Con ello, se desarrolla tecnología que es posible llevar a las empresas de la región, con el
fin de mejorar su productividad. Dicha productividad se observa en los siguientes aspectos:
(1) rendimiento en el proceso de desarrollo de los portlets; porque la independencia de los
portlets permite un proceso de desarrollo separado y paralelo, (2) favorece la experiencia
de los usuarios con el portal a causa de la adaptabilidad que los portlets otorgan; y (3) el
portal continúa funcional en el caso de falla de uno de sus portlets; porque dada la
independencia de éstos, dicha falla no se transmite al resto de ellos. Es obvio que las
ventajas que antes se citan serán poco observables para un portal con uno o dos portlets.
Por lo tanto, las empresas de la región que se favorecen del empleo de la tecnología de
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
93
portlets son aquellas empresas que requieren desarrollar portales para hospedar a un amplio
conjunto de portlets, donde cada portlet atiende su respectiva aplicación Web.
Tal como se mostró a lo largo de este documento, la tesis logró sus objetivos. La
realización de dichos objetivos implicó la necesidad de desarrollar una arquitectura. Dado
que el portal empresarial que se desarrolló se basa en portlets y los portales de segunda
generación usan a los portlets como componentes modulares para interfaz de usuario, en
consecuencia se desarrolló una arquitectura orientada a componentes. Como ya se presentó
anteriormente, esta arquitectura presenta dos elementos principales: el modo portal de
Internet y el modo Proxy o intermediario de servicios Web. Mientras el modo portal de
Internet ofrece un servicio directo al cliente, a través de las pequeñas ventanas de
información que presentan los portlets; el modo Proxy atiende, no a clientes como personas
físicas, sino a solicitudes de servicio que realizan aplicaciones Web de los clientes.
Los dos elementos principales de la arquitectura del portal se constituyen de
componentes más específicos. Sin embargo, se destaca que un componente fundamental de
ambos modos es el contenedor de portlets. El contenedor de portlets, en respuesta a
peticiones del usuario, genera y presenta contenidos dinámicos configurables para la
interfaz de usuario. Los portlets trabajan cooperativamente con los servicios de
entretenimiento que el portal obtiene a través del consumo de servicios Web. En
consecuencia, y dada la característica de interoperabilidad de los servicios Web, se logra
comprobar la hipótesis. La hipótesis indica que con el uso de la tecnología open source se
obtiene la característica de la portabilidad del portal a desarrollar.
Por otra parte, se señala que la principal dificultad en el desarrollo de esta tesis
consistió en la obtención de los portlets y de su integración. Dado que, inicialmente, se
empleó el ambiente de desarrollo integrado que se denomina Java Studio Creator 2; sin
embargo, este ambiente de desarrollo requiere demasiada memoria RAM de la
computadora personal. Por otra parte, la ejecución de un portlet con Java Studio Creator 2
presentó los siguientes inconvenientes: (1) ejecución muy lenta, ya que para ejecutar un
portlet tarda cerca de tres minutos, (2) el portlet es propenso a sufrir daño, el cual recibe el
calificativo de irremediable por el IDE Java Studio Creator 2. Cuya causa a veces se
atribuyó a algún error en el código y otras veces la causa del daño no fue identificable; y (3)
dado que este ambiente de desarrollo no permite integrar a los portlets, en consecuencia, se
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
94
pretendió ejecutar a los portlets en el servidor de aplicaciones que se denomina JBoss el
cual es open source y se tiene conocimiento que se desarrolló en lenguaje Java. Sin
embargo, este objetivo no se logró porque dicho servidor reportó problemas de
compatibilidad para este propósito. A consecuencia de la problemática anterior, se
desarrolló un contenedor de portlets propio, utilizando para ello tecnología open source
como el lenguaje de programación Java y se empleó al servidor de aplicaciones TomCat.
En consecuencia, los portlets desarrollados con Java Studio Creator 2 se desecharon y se
desarrollaron portlets cuya presentación utiliza tecnología JSP que se agregaron, con éxito,
al contenedor de portlets propio.
Por lo anterior, se agrega, a las conclusiones que esta sección presenta, que el
estudio del estándar JSR-168 resultó importante como base para el desarrollo de un
contenedor de portlets propio, que satisfizo exitosamente las necesidades que se planteó
esta tesis.
6.2. Contribuciones de la tesis.
Este trabajo contribuye con:
Una arquitectura de integración de información basada en portlets.
Un conjunto de mecanismos que definen la funcionalidad de los servicios
representados como portlets.
La arquitectura propuesta se validó con dos casos de estudio que permitieron
observar su utilidad. Concretamente se presentó un primer caso de estudio para la búsqueda
de la programación de cines dado un código postal y se presentó un segundo caso de
estudio para ayudar en la toma de decisión, acerca de si se asiste o no al cine, dada la
predicción del clima, además de la misma programación de cines. Ambos casos de estudio
permitieron demostrar que la arquitectura provee al portal con la característica de la
adaptabilidad y de presentar información consistentemente. Estas características
constituyen las ventajas de la arquitectura propuesta. En relación a la característica de la
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
95
adaptabilidad, ésta se presenta durante el diseño del portal porque los portlets se distribuyen
en el orden que se desee. Además, la adaptabilidad se otorga a los usuarios a través de las
varias formas de operación de los portlets. Se accede a las formas de operación de los
portlets a través de sus botones. En relación a la característica de acceso, con coherencia, a
fuentes de datos de diversas naturalezas en la infraestructura global de información, ésta se
obtiene a causa de los medios con que operan los servicios Web. Dichos medios permiten
independencia de lenguaje y plataforma para comunicación entre aplicaciones. Los
servicios Web logran este objetivo a través del empleo de los estándares: HTTP, XML,
SOAP y WSDL.
Por otra parte, considerando que un mecanismo es una técnica o tecnología
particular que proporciona una función. En este sentido, el conjunto de servicios Web son
los mecanismos a los cuales se accede a través de los portlets.
6.3. Trabajo futuro
Esta tesis logró sus objetivos y éstos son muy importantes. En este sentido, ya se
presentaron las ventajas de la arquitectura propuesta a través de casos de estudio. Sin
embargo, para aquellos que tengan interés en continuar trabajando sobre la línea de
investigación de esta tesis, para esto se propone el siguiente trabajo futuro:
Obtener una nueva valoración de la arquitectura propuesta a través de su
aplicación a un entorno real.
Desarrollar nuevos casos de estudio.
Sería conveniente validar a la arquitectura en un entorno real; no obstante que ésta
ya se validó exitosamente en el entorno académico. Esto permitiría una nueva valoración
del alcance de la propuesta. Por lo tanto, sería apropiado validar la arquitectura con otro
tipo de aplicaciones donde sea imperativo obtener las ventajas que ofrecen las arquitecturas
basadas en portlets. Como se recordará, estas ventajas consisten en: (1) la independencia de
los portlets permite que un equipo de desarrollo se distribuya el trabajo de implementación
de los portlets. Así, cada sub-grupo, del equipo de desarrollo, atiende el desarrollo de
determinados portlets. Donde la atención hacia un portlet no implica prestar atención hacia
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
96
algún otro. Ello, gracias a su característica de atómico, (2) la adaptabilidad que otorgan los
portlets permiten embeberlos al portal conforme los portlets se generan y su adaptabilidad
también se presentan hacia el usuario final. Lo anterior repercute en una productividad
inmediata; y (3) la alta individualidad de los portlets permite que el eventual fallo de un
portlet no repercuta en el desempeño de los demás. Entonces, la pregunta que se requiere
responder es: ¿Qué entorno de trabajo requiere apremiantemente de estas ventajas?. La
respuesta se aplica a todo departamento u organización de desarrollo de software que tiene
como encargo la responsabilidad de desarrollar un amplio conjunto de aplicaciones Web,
atómicas, y que requieren de una puesta en marcha veloz, con el conjunto de soluciones que
se van generando. En este sentido, se propone como trabajo futuro el caso de estudio que
abajo se presenta primeramente.
Por otra parte, esta tesis presentó un caso de estudio que trata de la composición de
portlets. Ello es necesario cuando el consumo de un solo servicio Web no es suficiente para
orquestar la solución al usuario. En relación al tema, se propone el caso de estudio que se
presenta a continuación en segundo término.
6.3.1. Caso de estudio propuesto en la implementación imperiosa de un portal con un
conjunto inicial de soluciones a través de una arquitectura basada en portlets.
Para este primer caso de estudio se propone el escenario de una organización de
desarrollo de software que desea una implementación rápida de un portal que presente
soluciones a ciertos problemas de investigación de operaciones. Una vez que se implementa
dicho portal, este se ofrecería a las industrias de la región susceptibles de interesarse en
soluciones a esta clase de problemas. Además, ante las industrias de la región, se
promocionaría la característica de adaptabilidad del portal. Dicha característica permite al
portal embeber a un número creciente e indefinido de nuevas soluciones, en este caso, a
problemas de investigación de operaciones.
Los problemas, de dicha área, que el portal resolvería en su etapa inicial son los
siguientes: (1) método de mínimos cuadrados para determinar la función de la demanda, (2)
control de inventarios, (3) sistema de líneas de espera, (4) sistema de optimización y
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
97
sistema de diagnóstico; y (5) toma de decisiones sin muestreo. En este escenario, surge la
pregunta:
¿Cómo requiere dicha organización de desarrollo de software implementar la
arquitectura basada en portlets para satisfacer las necesidades que antes se citan?
La implementación de este caso de estudio ofrecería nuevas experiencias acerca de
los beneficios de la arquitectura basada en portlets para un escenario de alta demanda de
aplicaciones Web independientes y que requieren de una integración rápida y productiva en
un portal. Dichas experiencias tienen importancia porque enriquecen el estado del arte.
6.3.2. Caso de estudio propuesto para obtener noticias de Java en alguno de los
idiomas más importantes.
El caso de estudio que a continuación se propone trata de la composición de portlets
para solicitar noticias del lenguaje Java en alguno de los idiomas más importantes a nivel
mundial. Esto, para dar solución a la problemática que presenta un usuario que requiere
obtener dichas noticias para alguno de los principales idiomas. En consecuencia, surge la
siguiente pregunta:
¿Cómo puede el usuario conseguir las noticias de Java sin tener que buscar en
multitud de sitios o portales dispersos y, además, eludiendo la necesidad de un servicio de
traducción, en caso de que las noticias no se encuentren en el idioma que desea?
Para contestar la pregunta que se describe en el escenario, se requiere de un portlet
que ofrezca el servicio completo y con ello, evitar al usuario su dispersión de tiempo. Para
implementar la solución, conviene considerar la composición de un portlet con dos
determinados servicios Web: JavaPortal News y Translation Engine. El primero de estos
servicios permite obtener, en idioma inglés, el número de noticias que se desea sobre Java;
mientras que el segundo servicio traduce de idioma inglés hacia alguno de los idiomas más
importantes. Los documentos WSDLs respectivos se ofrecen en el sitio de xmethods.com.
En consecuencia, la orquestación en el portlet de estos dos servicios ofrecería la solución
que demanda el usuario.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
98
Finalmente, esta tesis significó realizar investigación y contribuye al estado del arte.
Con ello, se aporta una fuente bibliográfica para trabajos futuros.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
99
Glosario
API.- (Application Programming Interface, interfaz de programación de la aplicación)
define los métodos a través de los cuales el programador accede y controla un sistema dado.
Arquitectura.- una descripción de un sistema, incluyendo a los componentes del sistema y
como ellos interactúan. También se dice que una arquitectura es una descripción de todas
las actividades funcionales que se realizarán para alcanzar la misión deseada, los elementos
que el sistema necesita para realizar sus funciones, y la designación de los niveles de
funcionamiento de dichos elementos.
Compatibilidad.- es la capacidad para trabajar con otro dispositivo o sistema sin
modificación. Existe compatibilidad de hardware y software.
Distribuido.- significa descentralizado, es decir, algo que se reparte en diferentes nodos.
HTTP.- (HyperText Transfer Protocol, protocolo de transferencia de hipertexto) es el
protocolo utilizado para el intercambio de los archivos de hipertexto (que se escriben en
HTML) a través de Internet, entre un software cliente y un servidor, operando ambos bajo
este protocolo. HTTP es el protocolo más importante utilizado en los servicios de la World
Wide Web (WWW).
Interoperabilidad.- es la condición mediante la cual sistemas heterogéneos pueden
intercambiar procesos o datos.
JSR 168.- (Java Specification Request, especificación Java Portlet) es un estándar que
permite la interoperabilidad de los portlets entre portales Web diferentes. Esta
especificación define una API para interacción entre el contenedor de portlets y el portlet
que se dirige hacia áreas de personalización, presentación y seguridad.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
100
Mecanismo.- una técnica o tecnología particular para proporcionar una función.
Open source.- (código abierto) cualidad del software de incluir el código fuente en la
distribución del programa. En general se usa para referirse al software libre.
Portabilidad.- característica por la cual un programa puede transportarse de un sistema
operativo a otro sin necesidad de cambiar su código fuente.
Portal.- Es un sitio Web que representa un punto de acceso a recursos e información de una
empresa u organización para sus empleados, clientes o proveedores.
Portlet.- son componentes Web gestionados por un contenedor de portlets que procesa
peticiones y genera contenido dinámico. Los portales usan portlets como componentes de
interfaz de usuario que proveen de una capa de presentación a los sistemas de información.
Proxy.- Servidor situado entre la máquina del usuario e Internet. En el contexto del trabajo
de la presente tesis se refiere a un servicio de intermediación en servicios Web.
Servicios Web.- Es una colección de protocolos y estándares que sirve para intercambiar
datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes y ejecutados sobre cualquier plataforma disponen de los servicios
Web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad
se consigue mediante la adopción de estándares abiertos: SOAP, WSDL y UDDI.
SOAP.- (Simple Object Access Protocol, protocolo simple de acceso a objetos) es un
protocolo para mensajes basados en XML. SOAP define cómo dos objetos en diferentes
procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de
los protocolos utilizados en los servicios Web.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
101
UDDI.- (Universal Description, Discovery and Integration, catálogo de negocios de
Internet) es un conjunto de especificaciones para crear directorios basados en XML de
servicios Web.
WSDL.- (Web Services Description Language, lenguaje de descripción de servicios Web)
es un formato estándar, entendible por la computadora, para describir un servicio Web. Una
definición WSDL describe como acceder a un servicio Web y que operaciones se
ejecutaran.
WSRP.- (Web Services for Remote Portlets, servicios Web para portlets remotos) es un
estándar para portales para acceder y desplegar portlets que se hospedan e un servidor
remoto.
WWW.- (World Wide Web, telaraña mundial) sistema de información basada en el
hipertexto que se comunica por Internet. WWW la parte de Internet a la que se accede a
través del protocolo HTTP y en consecuencia gracias a navegadores normalmente gráficos
como Explorer.
XML.- (Extensible Markup Language, lenguaje de marcas extensible) es un lenguaje
desarrollado por la institución que se denomina W3 Consortium. XML es un metalenguaje,
es decir, sirve para crear lenguajes más específicos y es la base tecnológica de los servicios
Web.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
102
Publicación
Enrique Ruiz Díaz, Giner Alor Hernández. ―Una arquitectura de integración de
información basada en portlets para un portal empresarial‖. Primer encuentro de
estudiantes en ciencia de la computación E2C2. ISBN-10:970-36-0404-8 e ISBN-
13:978-970-36-0404-3. Instituto Politécnico Nacional, México, D.F. 2007.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
103
Referencias
[1] Wikipedia, ―Internet‖ [en línea] <http://es.wikipedia.org/wiki/Internet> [Consulta: 28
junio 2006]
[2] Alfonso Cubero Moral, Sergio Luna García. ―Servlets y JSP‖ Departamento de
Informática y Automática Universidad de Salamanca. mayo 2003. pp: 2-17
[3] Kenneth Ramírez. ―Entendiendo Portales y Portlets: Parte 1 – Creando un portal
personalizado‖ Java Developer Journal Vol. 9 de 2004. pp: 1-9.
[4] Wikipedia, ―Portal‖ [en línea]
<http://es.wikipedia.org/wiki/Portal_%28internet%29> [Consulta: 28 junio 2006]
[5]Christian Wege. ―Portal Server Technology‖ IEEE Internet Computing. vol. 6, no. 3,
May/June 2002. pp 73-77.
[6] Fernando González, Moisés Cid, Pedro 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.
[7] José Antonio Guerra Pablos. ―PHP en el mundo real‖. Departamento de servicios Web e
Internet de la consultoría ICTI Consulting. Revista Mundo Linux Abril 2003. pp: 1-13.
[8] 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].
[9] Aplicaciones Web. ―Modelo de orientación a objetos en PHP 5‖. [en línea]
<http://www.aplicacionesweb.cl/content/view/32/2/> [Consulta: 28 Junio 2006].
[10] Security Linux Com. ―Securing PHP‖. [en línea] <
http://security.linux.com/security/04/08/05/203238.shtml> [Consulta: 28 Junio 2006].
[11] Darío Andrés Silva, Bárbara 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.
[12] Daniel Gayo Avello, Benjamín López Pérez, Luis Vinuesa Martínez, José E. Labra
Gayo, Juan M. Cueva Lovelle. ―Utilización de software libre como única tecnología para el
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
104
desarrollo de portales Web‖ Universidad de Oviedo, España. Departamento de
Informática. pp: 1-11.
[13] Andrés Vignaga, Daniel 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
[14] Pedro Cuesta Morales, Manuel J. Maña López, Carlos Cuervo Martínez. ―Aplicación
de Técnicas de Recuperación de Información a un Glosario de Términos de Internet
Desarrollado Utilizando Tecnología JSP‖ Departamento de Informática, Universidad de
Vigo. pp: 1-9
[15] César Colado Rodríguez. ―Diseño y desarrollo de aplicaciones Web multidispositivo‖
Germinus XXI, Febrero 2003. pp: 1-12.
[16] Thomas Schaeck. ―Web Services for Remote Portals (WSRP) Whitepaper‖. Oasis. pp:
1-18.
[17] Fernando Bellas. ―Standards for Second-Generation Portals‖. IEEE Internet
Computing. vol. 8, no. 2, March/April 2004. pp 54-60.
[18] Kevin Chihcheng Hsu & Fang-Chuan Ou Yang. ―OEPortal: an Open, Unified, and
Interoperable Presentation-Preserving e-Learning Portal‖. Proceedings of the Fifth IEEE
International Conference on Advanced Learning Technologies (ICALT’05). IEEE Press. pp
1-5.
[19] Maytal Dahan, Mary Thomas, Eric Roberts, Akhil Seth, Tomislav Urban, David
Walling, John R. Boisseau. ―Grid Portal Toolkit 3.0 (GridPort)‖. Proceedings of the 13th
IEEE International Symposium on High Performance Distributed Computing (HPDC’04).
IEEE Press. pp 272-273.
[20] Mr P.T. Galligan, Mr J.L. Hopkins, Prof. D.F. Kehoe.―An Approach to Deliver an
Early Return on Investment during the Development of a Corporate Web Portal‖
Proceedings of the 2005 IEEE International Conference on Services Computing (SCC’05).
IEEE Press. pp 1-8
[21] Thomas Puschmann, Rainer Alt. ―Process Portals – Architecture and Integration‖.
Proceedings of the 37th Hawaii International Conference on System Sciences – 2004. IEEE
Press. pp 1-10
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
105
[22] Brett Beeson, Ashley Wright. ―Developing Reusable Portals for Scripted Scientific
Codes‖. Proceedings of the First International Conference on e-Science and Grid
Computing (e-Science’05). IEEE Press. pp 1-6.
[23] Jason Novotny, Michael Russell, Oliver Wehrens.―GridSphere: An Advanced Portal
Framework‖. Proceedings of the 30th EUROMICRO Conference (EUROMICRO’04). IEEE
Press. pp 1-8.
[24] Marlon Pierce and Geoffrey Fox, Choonhan Youn, Steve Mock, Kurt Mueller, Ozgur
Balsoy. ―Interoperable Web Services for Computational Portals‖. Conference on High
Performance Networking and Computing. Proceedings of the 2002 ACM/IEEE conference
on Supercomputing. pp 1 - 12
[25] Rainer Weinreich, Thomas Ziebermayr. ―Enhancing Presentation Level Integration of
Remote Applications and Services in Web Portals‖. Proceedings of the 2005 IEEE
International Conference on Services Computing (SCC’05). IEEE Press. pp 1-8
[26] Oscar Díaz, Jon Iturrioz, Arantza Irastorza. ―Improving Portlet Interoperability
Through Deep Annotation‖. Proceedings of the 14th International World Wide Web
Conference. ACM Press. pp: 372-381
[27] Oscar Diaz. ―Portlet Syndication: Raising Variability Concerns‖. ACM Transactions
on Internet Technology, Vol. 5, No. 4, November 2005 pp 627–659.
[28] Mahesh Subramanian, Ali Shaikh, Omer Rana, Alex Hardisty y Edward 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]
[29] Deepti Kodeboyina y Beth 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]
[30] Henri Naccache, Gerald. C. Gannod, y Kevin 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.
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
106
[31] Sylvia C. Wrong, Richard M. Crowder, Nigel R. Shadbolt y Gary 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.
[32] Miguel Ángel Conde, Jorge Carabias, Rosa María Martín, Inmaculada González, y
Francisco José García. ―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]
[33] alzado.org, ―Servidores de portales: ¿usabilidad empaquetada?‖ [en línea]
<http://www.alzado.org/articulo.php?id_art=249> [Consulta: 1 julio 2006]
[34] Vignette Corporate. Frequently Asked Questions (FAQ). ―Support for WSRP and JSR
168‖. pp: 1-6.
[35] Sun Microsystems. ―Introduction to JSR 168—The Java Portlet Specification‖. pp: 1-
19.
[36] Sun Microsystems. ―Sun Java Studio Creator 2‖. [en línea].
<http://developers.sun.com/prodtech/javatools/jscreator/features/index.html> [Consulta: 25
julio 2006].
[37] BEA WebLogic. ―Building Portlets‖. [En línea].
<http://edocs.bea.com/workshop/docs81/doc/en/core/index.html>. [Consulta: 7 agosto
2006].
[38] IBM España. ―WebSphere Portlet Factory‖. [En línea]. <http://www-
306.ibm.com/software/info/ecatalog/es_ES/products/D558457Y86095X80.html?&S_TAC
T=none&S_CMP=none>. [Consulta: 7 agosto 2006].
[39] developers.sun. ―Article Overview of Sun Java Studio Enterprise 8‖. [En línea].
<http://developers.sun.com/prodtech/javatools/jsenterprise/reference/techart/jse8/jse8overvi
ew.html> [Consulta: 14 agosto 2006].
[40] Vignette. ―Borland JBuilder 2005 and Vignette Application Portal Leverage J2EE and
New Java Standards‖. [En línea].
M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación
107
<http://www.vignette.com/contentmanagement/0,2097,1-1-30-72-407-4596,00.html>
[Consulta: 14 agosto 2006].
[41] www3.imperial.ac.uk. ―¿Qué Es OracleAS Portal?‖. [En línea].
<http://www3.imperial.ac.uk/portalHelp2/ohw?navId=3&navSetId=_&locale=es&vtTopic
File=welchelp_hs_es/pbmwwdb.htm> [Consulta: 14 agosto 2006].
[42] Jennifer Pérez. ―Web Services‖. Departamento de Sistemas Informáticos y
Computación. Universidad Politécnica de Valencia. pp 1-15.
[43] Curbera Francisco, Duftler Matthew, Khalaf Rania, Nagy William, Mukhi Nirmal,
Weerawara Sanjiva. ―Unraveling the Web Services. An Introduction to SOAP, WSDL, and
UDDI.‖ March / April 2002. IEEE Internet Computing. pp 86-93.
[44] Apache Pluto. ―Welcome to Pluto‖. [en línea] <http://portals.apache.org/pluto/>
[Consulta: 10 enero 2007].
[45] Wikipedia. ―Tomcat‖. [En línea] <http://es.wikipedia.org/wiki/Tomcat> [Consulta: 12
Junio 2007]
[46] David Gould Studios. ―Definición de API‖. [En línea].
<http://www.davidgould.com/Glossary/Glossary.htm> [Consulta: 3 Junio 2007]