You are on page 1of 107

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

1

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

Índice

Índice ……………………………………………………………………………….. Índice de figuras ……………………………………………………………………. Resumen ……………………………………………………………………………. Introducción ………………………………………………………………………... Capítulo I. Motivación …….....…………………………………………………… 1.1. Introducción …………………………………………………………………… 1.2. Antecedentes ………………………………………………………………….. 1.3.1 Common Gateway Interface (CGI) ……………………………………… 1.3.3. Active Server Pages (ASP) ……………………………………………... 1.3.4. Servlets ………………………………………………………………….. 1.3.5. JavaServer Pages (JSP) …………………………………………………. 1.4. Planteamiento del problema …………………………………………………… 1.5 Estado del arte ………………………………………………………………….. 1.7. Resumen ………………………………………………………………………..

ii vi

Índice de tablas ……………………………………………………………………... viii ix xi

1 1 2

1.3. Evolución de las tecnologías de información ………………………………….. 5 5 1.3.2. PHP ……………………………………………………………………… 6 7 8 8

1.3.6. Los Portlets ……………………………………………………………… 9 11 13

1.6 Propuesta de solución …………………………………………………………... 21 22

Capítulo II: Tecnología de portlets ………………………………………………. 23 2.1 Introducción ……………………………………………………………………. 2.2 Estándares JSR 168 y WSRP …………………………………………………... 23 23

2

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

2.2.1 Estándar JSR 168 (The Java Portlet Specification, la especificación del portlet de Java) ……………………………………………………………………... 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 ……………………………. 2.3.1. Java Sun Studio Creator ………………………………………………… 2.3.2 WebLogic Workshop ……………………………………………………. 30 30 30 24

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 32 de aplicación Vignette ……………………………………………………………… 2.3.6. OracleAS Portal …………………………………………………………. 32 2.4 Resumen ……………………………………………………………………….. Capítulo III. Componentes de la arquitectura del portal empresarial ………... 3.1. Introducción …………………………………………………………………… 3.2. Componentes de la arquitectura del portal empresarial ……………………….. 33

35 35 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 ………………………... 3.2.2.2. Descripción de los componentes ………………………………... 3.2.2.2.1. El analizador de mensajes SOAP …………………….. 38 40 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 ………………………………………….. 3.2.2.2.5. El analizador de respuesta ……………………………. 3.2.2.2.6. El constructor de respuestas ………………………….. 3.2.2.3. Funcionamiento de la arquitectura ……………………………….. 3.3. Resumen ………………………………………………………………………. 42 42 44 44 45

3

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 ………………………………………………… 4.3.4. Servicio Proxy USAWeather …………………………………………… 4.3.5. Tecnología de desarrollo para el modo portal Proxy …………………… 61 63 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 ………………………………………………… 4.4.4. Capa de servicio ………………………………………………………… 4.4.5. Capa lógica ……………………………………………………………… 4.4.6. Capa de integración ……………………………………………………... 4.5. Resumen ……………………………………………………………………….. Capítulo V. Casos de estudio ………..……………………………………………. 5.1. Introducción …………………………………………………………………… 5.3 Caso de estudio: ayuda en la toma de decisión para la asistencia al cine ……… 5.4. Fundamentos de la tecnología de portlets que explican sus ventajas en sus servicios al usuario …………………………………………………………………. 5.5. Resumen ……………………………………………………………………….. 77 78 67 68 68 69 70

72 72

5.2. Caso de estudio: una búsqueda de programación de cines …………………….. 72 74

4

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación 80 80

Capítulo VI. Conclusiones …………………..……………………………………. 6.1. Conclusiones generales ………………………………………………………...

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 ……………………………………………………………………………… 6.3.2. Caso de estudio propuesto para obtener noticias de Java en alguno de los idiomas más importantes …………………………………………………………… Glosario …………………………………………………………………………….. Publicación …………………………………………………………………………. Referencias …………………………………………………………………………. 85 84

87 90 91

5

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

Í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 …………………………………. Figura 3.2. Portal empresarial en su modo portal de Internet ……………………… 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 …………………... Figura 4.1. El modo portal de Internet con la opción activa ―All Portlets‖ ……….. Figura 4.2 B. Representación en UML del contenedor de portlets ………………… Figura 4.2 C. Representación en UML del contenedor de portlets ………………… 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 …………………………………………………………………. Figura 4.7. Ejemplo de ejecución de un método, el método getBook, del servicio Proxy AmazonBox …………………………………………………………………. 59 59 43 47 28 Figura 3.1. Aspecto general de la arquitectura ……………………………………... 36 37 Figura 3.3. Arquitectura del portal en modo Proxy ………………………………… 39

Figura 4.2 A. Representación en UML del contenedor de portlets ………………… 49 50 51

6

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 ……………………………………………………….. 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 ……………………………. 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 …………………………………………………………... Figura 4.14. Ejemplificación, en caja negra, del empleo de los métodos del documento WSDL para el servicio Proxy USAWeather …………………………... 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 …………………………………………... Figura 4.17. La arquitectura de portal en capas ……………………………………. 64 70 64 63 62 62 62 60

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 ……………………………………………………………………………… Figura 5.4. El portlet TheatersAndUSAWeather en ejecución …………………….. 75 76

7

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

Índice de tablas
Tabla 1.1. Desventajas de las tecnologías de portales de la primera generación …... Tabla 3.1. Descripción de los servicios Web del portal ……………………………. 10 36

Tabla 4.1. Métodos del servicio Proxy AmazonBox ……………………………….. 57

8

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

9

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

10

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 11

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

12

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

13

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

14

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

15

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

16

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 17

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

18

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

19

M.C. Enrique Ruiz Díaz. 1.3.4. Servlets

Maestro en Ciencias de la Computación

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

20

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

21

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

[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 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. cantidad

Tecnología CGI

Desventaja particular 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.

22

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

Portlet del clima Portal del empleado Portlet de R. H.

Servicio Web del clima Servicio Web de R. H.

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

23

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

Portlet Proxy Portal del empleado Portlet Proxy

Portlet Clima

Servicio Web del clima Servicio Web de R. H.

Portlet R. H.

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

24

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

26

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

27

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 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 (4) de

28

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

29

M.C. Enrique Ruiz Díaz. de portal manejable JSR 168

Maestro en Ciencias de la Computación 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).

30

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

31

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

32

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación en la

tesis utiliza WSRP en combinación con JSP en vez de JSR 168. Finalmente,

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

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

34

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

35

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 reinvoca 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

36

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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,

37

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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().

38

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

39

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

(X)HTML

WML

Voz XML

XHTML Básico

WSRP WSRP/WSIA
Base común

WSIA

WSDL (Descripción)

SOAP (Invocación)

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

40

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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, 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. necesitan

41

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

42

M.C. Enrique Ruiz Díaz. 2.3.3. IBM WebSphere Portlet Factory

Maestro en Ciencias de la Computación

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,

43

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

44

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 45

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

46

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

47

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 Las películas que ofrecen los Movie Showtimes. cines para un determinado código postal (USA). USA Weather Forecast. La previsión del clima para un determinado ciudad (USA). Horoscope web Services AmazonBox El horóscopo diario. Búsqueda de productos en código postal o

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.

48

M.C. Enrique Ruiz Díaz. 3.2.1 Modo portal de Internet

Maestro en Ciencias de la Computación

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.

49

M.C. Enrique Ruiz Díaz. 3.2.2. Modo Proxy del portal.

Maestro en Ciencias de la Computación

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.

50

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

51

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

<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">

Figura 3.4. Documento WSDL del servicio Web ―Horoscope web Services‖, para los clientes del portal en su modo Proxy.

52

M.C. Enrique Ruiz Díaz. 3.2.2.2.1. El analizador de mensajes SOAP

Maestro en Ciencias de la Computación

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

53

M.C. Enrique Ruiz Díaz. 3.2.2.2.4. El invocador.

Maestro en Ciencias de la Computación

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.

54

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

Figura 3.5. Documento WSDL del servicio Web ―Horoscope web Services‖, del proveedor externo del servicio para el portal en su modo Proxy.

55

M.C. Enrique Ruiz Díaz. 3.2.2.2.6. El constructor de respuestas

Maestro en Ciencias de la Computación

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

56

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

57

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

58

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 59

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

60

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

Figura 4.2 A. Representación en UML del contenedor de portlets.

61

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

Figura 4.2 B. Representación en UML del contenedor de portlets.

62

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

63

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

64

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

65

M.C. Enrique Ruiz Díaz.
if (session.getAttribute("ProducePortlets")==null) {

Maestro en Ciencias de la Computación

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.

66

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

67

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

68

M.C. Enrique Ruiz Díaz. Método
public String bookBox(String Keyword) public String babyBox(String Keyword) public String classicalMusicBox(String Keyword) public String dvdBox(String Keyword) public String electronicsBox(String Keyword) public String gardenAndOutdoorLivingBox(String Keyword) public String kitchenAndHousewaresBox(String Keyword) public String magazinesBox(String Keyword) public String popularMusicBox(String Keyword) public String computerHardwareBox(String Keyword) public String cameraAndPhotoBox(String Keyword) public String computerSoftwareBox(String Keyword) public String toysAndGamesBox(String Keyword) public String toolsAndHardwareBox(String Keyword) public String videoBox(String Keyword) public String computerAndVideoGamesBox(String Keyword) public String authorBox(String Keyword) public String musicianPopularMusicBox(String Keyword) public String musicianClassicalMusicBox(String Keyword) public String actorDvdBox(String Keyword) public String actorVideoBox(String Keyword) public String directorDvdBox(String Keyword) public String directorVideoBox(String Keyword) public String manufacturerElectronicsBox(String Keyword) public String manufacturerKitchenAndHousewaresBox(String Keyword) public String manufacturerComputerAndVideoGamesBox(String Keyword) public String manufacturerComputerSoftwareBox(String Keyword) public String manufacturerCameraAndPhotoBox(String Keyword) public String manufacturerComputerHardwareBox(String Keyword) public String similaritiesBox(String Keyword)

Maestro en Ciencias de la Computación Producto a buscar Por el método
Libros Para bebés De música clásica DVD Electrónicos Jardín y casa al aíre libre Cocina y mercancías de la casa Revistas Música popular Hardware de computadora Cámara y fotos Software de computadora Juguetes y juegos Herramientas y hardware Videos Computadora y video juegos Por autor Música popular por músico Música clásica por músico Por actor en DVD Por actor en video Por director en DVD Por director en video Electrónicos por fabricante Cocina y mercancías de la casa por fabricante Computadora y video juegos por fabricante Software de computadora fabricante Cámara y fotos por fabricante Hardware fabricante Similares de computadora por

por

Tabla 4.1. Métodos del servicio Proxy AmazonBox

69

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

String KeyWord

Métodos de AmazonBox

String Response

… … n

Clases en Java

… … n

Figura 4.5. Ejemplificación, en caja negra, del empleo de los métodos del documento WSDL para el servicio Proxy AmazonBox

70

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

71

M.C. Enrique Ruiz Díaz. 4.3.2. Servicio Proxy Horoscope

Maestro en Ciencias de la Computación

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.

Método de la clase Horoscope: getHoroscope()

String Response

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

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

73

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación Método de la clase Theaters: getShowTimes ()

String CodigoPostal

String Respuesta

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

74

M.C. Enrique Ruiz Díaz. 4.3.4. Servicio Proxy USAWeather.

Maestro en Ciencias de la Computación

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. Métodos de la clase USAWeather: String ZipCode getWeather ByZipCode () getWeather ByPlace Name() String Response

String PlaceName

String Response

Figura 4.14. Ejemplificación, en caja negra, del empleo de los métodos del documento WSDL para el servicio Proxy USAWeather

75

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

76

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

77

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

78

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

79

M.C. Enrique Ruiz Díaz. 4.4.4. Capa de servicio

Maestro en Ciencias de la Computación

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

80

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

81

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

82

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

83

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

84

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

85

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

(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:

86

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

87

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

88

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

89

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

90

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

91

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

92

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

93

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 94

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

95

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

96

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

97

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

Finalmente, esta tesis significó realizar investigación y contribuye al estado del arte. Con ello, se aporta una fuente bibliográfica para trabajos futuros.

98

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

99

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

100

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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.

101

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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 ISBN13:978-970-36-0404-3. Instituto Politécnico Nacional, México, D.F. 2007.

102

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

103

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

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

104

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

[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. 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] [Consulta:

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.

105

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

[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 Postproceedings. Selected and Extended Papers. pp: 181-194 [En línea]

http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-186/17.pdf. Enero 2007]

[Consulta:

[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: 119. [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 [Consulta: 7 línea]. agosto

<http://edocs.bea.com/workshop/docs81/doc/en/core/index.html>. 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].

106

M.C. Enrique Ruiz Díaz.

Maestro en Ciencias de la Computación

<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]

107