Download - M.C. Enrique Ruiz Díaz - Diseño y Construcción de un Portal Empresarial utilizando la Tecnología de Portlets.

M.C. Enrique Ruiz Díaz. Maestro en Ciencias de la Computación

1

INSTITUTO TECNOLÓGICO DE ORIZABA

DIVISIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN

“DISEÑO Y CONSTRUCCIÓN

DE UN PORTAL EMPRESARIAL

UTILIZANDO LA TECNOLOGÍA DE PORTLETS“

TESIS

QUE PARA OBTENER EL GRADO DE:

MAESTRO EN CIENCIAS EN

CIENCIAS DE LA COMPUTACIÓN

PRESENTA

LIC. ENRIQUE RUIZ DÍAZ

DIRECTOR DE TESIS

DR. GINER ALOR HERNÁNDEZ

ORIZABA, VERACRUZ, MÉXICO. SEPTIEMBRE 2007


2

Índice

Índice ……………………………………………………………………………….. ii

Índice de figuras ……………………………………………………………………. vi

Índice de tablas ……………………………………………………………………... viii

Resumen ……………………………………………………………………………. ix

Introducción ………………………………………………………………………... xi

Capítulo I. Motivación …….....…………………………………………………… 1

1.1. Introducción …………………………………………………………………… 1

1.2. Antecedentes ………………………………………………………………….. 2

1.3. Evolución de las tecnologías de información ………………………………….. 5

1.3.1 Common Gateway Interface (CGI) ……………………………………… 5

1.3.2. PHP ……………………………………………………………………… 6

1.3.3. Active Server Pages (ASP) ……………………………………………... 7

1.3.4. Servlets ………………………………………………………………….. 8

1.3.5. JavaServer Pages (JSP) …………………………………………………. 8

1.3.6. Los Portlets ……………………………………………………………… 9

1.4. Planteamiento del problema …………………………………………………… 11

1.5 Estado del arte ………………………………………………………………….. 13

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

1.7. Resumen ……………………………………………………………………….. 22

Capítulo II: Tecnología de portlets ………………………………………………. 23

2.1 Introducción ……………………………………………………………………. 23

2.2 Estándares JSR 168 y WSRP …………………………………………………... 23


3

2.2.1 Estándar JSR 168 (The Java Portlet Specification, la especificación del

portlet de Java) ……………………………………………………………………...

24

2.2.2 Estándar WSRP (Web Services for Remote Portlets, servicios Web para

portlets remotos) …………………………………………………………………….

27

2.3. Ambientes de desarrollo con soporte para portlets ……………………………. 30

2.3.1. Java Sun Studio Creator ………………………………………………… 30

2.3.2 WebLogic Workshop ……………………………………………………. 30

2.3.3. IBM WebSphere Portlet Factory ……………………………………….. 31

2.3.4. Sun Java Studio Enterprise ……………………………………………… 31

2.3.5. Borland JBuilder 2005 y la edición de desarrollo de Borland del portal

de aplicación Vignette ………………………………………………………………

32

2.3.6. OracleAS Portal …………………………………………………………. 32

2.4 Resumen ……………………………………………………………………….. 33

Capítulo III. Componentes de la arquitectura del portal empresarial ………... 35

3.1. Introducción …………………………………………………………………… 35

3.2. Componentes de la arquitectura del portal empresarial ……………………….. 35

3.2.1 Modo portal de Internet ………………………………………………….. 37

3.2.2. Modo Proxy del portal …………………………………………………... 38

3.2.2.1. Relación entre servicios Web y portlets ………………………... 38

3.2.2.2. Descripción de los componentes ………………………………... 40

3.2.2.2.1. El analizador de mensajes SOAP …………………….. 41

3.2.2.2.2. El selector de servicio ………………………………… 41

3.2.2.2.3. El contenedor de portlets ……………………………... 41

3.2.2.2.4. El invocador ………………………………………….. 42

3.2.2.2.5. El analizador de respuesta ……………………………. 42

3.2.2.2.6. El constructor de respuestas ………………………….. 44

3.2.2.3. Funcionamiento de la arquitectura ……………………………….. 44

3.3. Resumen ………………………………………………………………………. 45


4

Capítulo IV. Prestaciones de servicios del portal empresarial ……..…………... 46

4.1. Introducción …………………………………………………………………... 46

4.2. Modo portal de Internet ………………………………………………………... 46

4.2.1. Interfaz gráfica del modo portal de Internet …………………………….. 46

4.2.2. Tecnología de desarrollo para el modo portal de Internet ………………. 47

4.2.3. Métodos del contenedor de portlets para el modo portal de Internet …… 47

4.3. Modo Proxy ……………………………………………………………………. 55

4.3.1. Servicio Proxy AmazonBox …………………………………………….. 56

4.3.2. Servicio Proxy Horoscope ………………………………………………. 60

4.3.3. Servicio Proxy Theaters ………………………………………………… 61

4.3.4. Servicio Proxy USAWeather …………………………………………… 63

4.3.5. Tecnología de desarrollo para el modo portal Proxy …………………… 65

4.4. Capas de prestaciones de servicios de la arquitectura del portal ………………. 65

4.4.1. Capa de presentación ……………………………………………………. 65

4.4.2. Capa de comunicación …………………………………………………... 66

4.4.3. Capa de descubrimiento ………………………………………………… 67

4.4.4. Capa de servicio ………………………………………………………… 68

4.4.5. Capa lógica ……………………………………………………………… 68

4.4.6. Capa de integración ……………………………………………………... 69

4.5. Resumen ……………………………………………………………………….. 70

Capítulo V. Casos de estudio ………..……………………………………………. 72

5.1. Introducción …………………………………………………………………… 72

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

5.3 Caso de estudio: ayuda en la toma de decisión para la asistencia al cine ……… 74

5.4. Fundamentos de la tecnología de portlets que explican sus ventajas en sus

servicios al usuario ………………………………………………………………….

77

5.5. Resumen ……………………………………………………………………….. 78


5

Capítulo VI. Conclusiones …………………..……………………………………. 80

6.1. Conclusiones generales ………………………………………………………... 80

6.2. Contribuciones de la tesis ……………………………………………………… 82

6.3. Trabajo futuro ………………………………………………………………….. 83

6.3.1. Caso de estudio propuesto en la implementación imperiosa de un portal

con un conjunto inicial de soluciones a través de una arquitectura basada en

portlets ………………………………………………………………………………

84

6.3.2. Caso de estudio propuesto para obtener noticias de Java en alguno de los

idiomas más importantes ……………………………………………………………

85

Glosario …………………………………………………………………………….. 87

Publicación …………………………………………………………………………. 90

Referencias …………………………………………………………………………. 91


6

Índice de figuras

Figura 1.1. Portlets locales que usan servicios Web remotos …………………...…. 11

Figura 1.2. Un portal que usa servicios Web de portlets remotos ………………….. 12

Figura 2.1. El portlet del clima ……………………………………………………... 25

Figura 2.2. Edición de preferencias ………………………………………………… 26

Figura 2.3. WSRP y estándares que se relacionan …………………………………. 28

Figura 3.1. Aspecto general de la arquitectura ……………………………………... 36

Figura 3.2. Portal empresarial en su modo portal de Internet ……………………… 37

Figura 3.3. Arquitectura del portal en modo Proxy ………………………………… 39

Figura 3.4. Documento WSDL del servicio Web ―Horoscope web Services‖, para

los clientes del portal en su modo Proxy ……………………………………………

40

Figura 3.5. Documento WSDL del servicio Web ―Horoscope web Services‖, del

proveedor externo del servicio para el portal en su modo Proxy …………………...

43

Figura 4.1. El modo portal de Internet con la opción activa ―All Portlets‖ ……….. 47

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

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

Figura 4.2 C. Representación en UML del contenedor de portlets ………………… 51

Figura 4.3. Métodos del contenedor de portlets, en la secuencia y con la estructura

condicional if-else que se requiere para generar un portlet …………………………

54

Figura 4.4. Representación en UML de la API del portal para su modo Proxy ……. 56

Figura 4.5. Ejemplificación, en caja negra, del empleo de los métodos del

documento WSDL para el servicio Proxy AmazonBox …………………………….

58

Figura 4.6. Ejemplo de invocación de un método, el método getBook, del servicio

Proxy AmazonBox ………………………………………………………………….

59

Figura 4.7. Ejemplo de ejecución de un método, el método getBook, del servicio

Proxy AmazonBox ………………………………………………………………….

59


7

Figura 4.8. Ejemplificación, en caja negra, del empleo del método getHoroscope

del documento WSDL para el servicio Proxy Horoscope …………………………..

60

Figura 4.9. Ejemplo de invocación del método del servicio Proxy Horoscope que

se denomina getHoroscope ………………………………………………………..

60

Figura 4.10. Ejemplo de ejecución del método del servicio Proxy Horoscope que

se denomina getHoroscope ………………………………………………………….

61

Figura 4.11. Ejemplificación, en caja negra, del empleo del método getShowTimes

del documento WSDL para el servicio Proxy Theaters …………………………….

62

Figura 4.12. Ejemplo de invocación del método del servicio Proxy Theaters que se

denomina getShowTimes …………………………………………………………...

62

Figura 4.13. Ejemplo de ejecución del método del servicio Proxy Theaters que se

denomina getShowTimes …………………………………………………………...

62

Figura 4.14. Ejemplificación, en caja negra, del empleo de los métodos del

documento WSDL para el servicio Proxy USAWeather …………………………...

63

Figura 4.15. Ejemplo de invocación de un método del servicio Proxy USAWeather

que se denomina getWeatherByZipCode …………………………………………...

64

Figura 4.16. Ejemplo de ejecución de un método del servicio Proxy USAWeather

que se denomina getWeatherByZipCode …………………………………………...

64

Figura 4.17. La arquitectura de portal en capas ……………………………………. 70

Figura 5.1. Portal con los primero cuatro portlets ………………………………….. 73

Figura 5.2. El portlet Theaters en presentación y en ejecución …………………….. 74

Figura 5.3. El portlet TheatersAndUSAWeather en su presentación inicial al

usuario ………………………………………………………………………………

75

Figura 5.4. El portlet TheatersAndUSAWeather en ejecución …………………….. 76


8

Índice de tablas

Tabla 1.1. Desventajas de las tecnologías de portales de la primera generación …... 10

Tabla 3.1. Descripción de los servicios Web del portal ……………………………. 36

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


9

Resumen

Las tecnologías de portales de la primera generación tales como CGI, PHP, ASP,

Servlets, JSP, entre otros, presentaron desventajas para acceder a recursos e información

que provienen de terceras partes, porque éstos proceden de diferentes plataformas

operativas, lenguajes de programación y bases de datos. Para superar éstas limitaciones se

presentan las tecnologías de portlets. Estas tecnologías presentan un enfoque orientado a

componentes y se basan en estándares.

Esta tesis presenta el diseño y desarrollo de un portal empresarial usando las

tecnologías de portlets y se aborda el problema de integración de información. Dado que se

requiere una solución para la necesidad de encontrar un acceso consistente a fuentes de

datos heterogéneas y dispersas.

El enfoque de solución consiste en el desarrollo de una arquitectura de integración

de información usando portlets. Esta arquitectura presenta dos modos de operación, modo

portal de Internet y Proxy. Dicha arquitectura se prueba con una aplicación la cual se

enfoca hacia la industria del entretenimiento. Las principales contribuciones de este trabajo

son: 1) una arquitectura basada en portlets con diferentes niveles de prestación de servicios;

y 2) un conjunto de mecanismos que describen la funcionalidad de los servicios que se

representan como portlets. Finalmente, las ventajas de esta propuesta son: 1) capacidad de

acceso de una manera estable a diferentes fuentes de datos heterogéneas; y 2) adaptabilidad

de portlets en fase de diseño y para los usuarios finales.


10

Abstract

Technologies from first generation portals such CGI, PHP, ASP, Servlets, JSP,

among others, have presented disadvantages to accede to resources and information

provided by third parts, because these coming from different operating platforms,

programming languages and data bases. In order to surpass these limitations the portlets

technologies are arisen. These technologies present a component–oriented and standard-

based approach.

This thesis presents the design and development of an enterprise portal by using

portlets technologies. In this thesis, the problem of information integration is addressed. A

solution for the necessity for finding a consistent access to heterogeneous and scattered data

sources is required.

The solution approach consists of the development of an information integration

architecture by using portlets. This architecture shows two ways of operation, both Internet

portal mode and Proxy mode. This architecture was tested with an application which is

focused towards the entertainment industry. The main contributions of this work are: 1) a

portlet-based architecture with different level services; and 2) a set of mechanisms which

describe the services functionality described as portlets. Finally, the advantages of this

proposal are: 1) able to access in stable way to different heterogeneous data sources; and 2)

ability to customize portlets in design phase and for end users.


11

Introducción

Esta tesis presenta el desarrollo de una arquitectura de integración de información

basada en portlets para un portal de segunda generación. Para la validación de esta

arquitectura se exhibe el desarrollo de una aplicación. Dicha arquitectura emplea portlets y

servicios Web. Con ello, se adquiere las ventajas de la adaptabilidad y de un acceso

consistente a fuentes de información dispersas y de naturalezas diversas en la

infraestructura global de información. Esto es relevante porque se muestra que los portales

de primera generación basados en tecnologías tales como CGI, PHP, ASP, servlets, JSPs,

entre otros presentan una arquitectura monolítica que compromete el desarrollo y

mantenimiento. Estas desventajas se superan con la tecnología de portlets.

La arquitectura que se presenta posee dos modos de operación, modo portal de

Internet y Proxy. Ambos modos se enfocan a consumir servicios de la industria del

entretenimiento. Sin embargo, existe una diferencia importante en la forma de otorgar los

servicios de dichos modos. El modo portal de Internet otorga un servicio directo a usuarios

finales; mientras que, el modo Proxy ofrece sus servicios a aplicaciones Web a través de un

servicio de intermediación. El objetivo general que plantea esta tesis es el diseño y

construcción de un portal empresarial con base en el desarrollo de una aplicación basada en

componentes Web, que se gestione por un contenedor de portlets para procesar peticiones y

generar contenido dinámico. Los objetivos particulares son: (1) diseñar y construir la

arquitectura de integración para un portal empresarial a través de portlets; y (2) establecer

los mecanismos que permitan la personalización, la presentación y la gestión de seguridad a

través de portlets. A su vez, las aportaciones de la tesis se establecen de la siguiente

manera: (1) una arquitectura de integración bajo diferentes niveles de prestación de

servicios; y (2) un conjunto de mecanismos que definen la funcionalidad de los servicios

representados como portlets.

A continuación se presenta una breve descripción de la estructura de la tesis.

En el capítulo I se presenta la motivación de la tesis. Para este capítulo, se muestran

los antecedentes de Internet y se realiza una revisión de las tecnologías de los portales de

primera y segunda generación. También presenta: el problema que trata la tesis, la revisión


12

del estado del arte, en el cual se compara la arquitectura propuesta contra la de trabajos

semejantes y finalmente se explica la propuesta de solución.

En el capítulo II se presenta la tecnología de portlets. En este capítulo se lleva a

cabo una revisión del estándar JSR-168 para portlets locales y del estándar WSRP para

portlets remotos. Además, se muestra una revisión de los ambientes de desarrollo que

soportan portlets.

En el capítulo III se presentan los componentes de la arquitectura del portal

empresarial. Ésta se divide en dos partes: modo portal de Internet y modo Proxy. Se

muestra que ambos modos del portal se subdividen en componentes más específicos que se

describen con detalle.

En el capítulo IV se explican las prestaciones de servicios del portal empresarial

para los dos modos de operación del portal. Además, se presenta la representación en UML

del contenedor de portlets y del modo Proxy. Así también, se explican las capas de

servicios de la arquitectura del portal.

En el capítulo V se presentan dos casos de estudio que permiten observar las

ventajas de la arquitectura propuesta y se discuten los fundamentos tecnológicos que

permiten dichas ventajas.

Finalmente, en el capítulo VI se presentan las conclusiones, se muestran las

contribuciones de la tesis y se proponen trabajos futuros.


13

Capítulo 1. Motivación

1.1. Introducción

Los portales son sitios basados en el protocolo HTTP que se alojan en un servidor

con un software especial de portal, el cual permite la agrupación de varios sistemas,

procesos o sitios para visualizarse en una sola página de portal. Los portales permiten

apoyar a las empresas. Con un portal empresarial, las empresas están en condiciones de

ofrecer a sus empleados, clientes y socios una manera segura de acceder a toda la

información y servicios necesarios para interactuar y colaborar con su organización.

La motivación de esta tesis está en potenciar el rol del portal empresarial a través

del desarrollo de un portal que acceda exitosamente a fuentes de datos dispersas y

heterogéneas. La obtención de este objetivo es difícil con las tecnologías para los portales

de primera generación dado que éstas presentan importantes desventajas. Estas consisten en

que los portales de primera generación requieren de enormes esfuerzos de programación e

inversión en tiempo para acceder a recursos e información provistos por terceras partes. En

consecuencia, surge la tecnología para portales de segunda generación basada en portlets.

Estos permiten acceder a información a través de integrar aplicaciones heterogéneas y

fuentes de datos consistentemente. Sin embargo, dado que los portlets son componentes,

surge la necesidad de una arquitectura que los sustente para maximizar los recursos

existentes. Por lo tanto, la tecnología de portlets con sustento en una arquitectura apropiada

permitirá el desarrollo de un portal empresarial que mejore en la empresa su interacción

inter-organización e intra-organizacional.

Este primer capítulo presenta una breve revisión de los antecedentes de Internet,

también se realiza una revisión de las tecnologías para portales de primera y segunda

generación. Además, se establece cuál es el planteamiento del problema a resolver y se

hace una revisión del estado del arte. Finalmente, se presenta una propuesta de solución

para integrar información a través del diseño y construcción de un portal empresarial

utilizando la tecnología de portlets.


14

1.2. Antecedentes

El Internet es una red de redes a escala mundial compuesta por millones de

computadoras que se interconectan con un conjunto de protocolos, de los cuales el que más

se destaca es el TCP/IP (Transmission Control Protocol/Internet Protocol, protocolo de

control de transmisión / protocolo de Internet ). El nombre de Internet también se usa como

sustantivo común y por tanto en minúsculas para designar a cualquier red de redes que use

las mismas tecnologías que Internet, independientemente de su extensión o de que sea

pública o privada [1].

Cuando se dice red de redes se hace referencia a que es una red que se forma por la

interconexión de otras redes menores [1].

Al contrario de lo que se piensa comúnmente, Internet no es sinónimo de World

Wide Web. Ésta es parte de aquella, siendo la World Wide Web uno de los muchos servicios

que se ofertan en la red Internet. La Web es un sistema de información mucho más reciente

que emplea Internet como medio de transmisión [1].

Algunos de los servicios disponibles en Internet aparte de la Web son el acceso

remoto a otras máquinas tales como SSH (Secure SHel, programa de seguridad) y telnet

(protocolo de Internet para acceso remoto), transferencia de archivos tal como FTP (File

Transfer Protocol, protocolo de transferencia de archivos), el uso del protocolo SMTP

(Simple Mail Transfer Protocol, protocolo simple de transferencia de correo electrónico)

que se basa en texto y se utiliza para el intercambio de mensajes de correo electrónico entre

computadoras o distintos dispositivos como celulares, entre otros, boletines electrónicos

tales como news o grupos de noticias, conversaciones en línea tales como IRC (Internet

Relay Chat, protocolo de comunicación en tiempo real basado en texto) [1].

Por otra parte, en la historia de Internet se tiene que en 1972 se realizó la primera

demostración pública de ARPANET (Advanced Research Projects Agency Network,

agencia de red de proyectos de investigación avanzados), una nueva red de comunicaciones

que financió la DARPA (Defense Advanced Research Projects Agency, agencia de

investigación de proyectos avanzados de defensa) que funcionaba de forma distribuida

sobre la red telefónica conmutada. El éxito de esta nueva arquitectura sirvió para que en

1973, la DARPA iniciara un programa de investigación sobre posibles técnicas para


15

interconectar redes (éstas se enfocaron al tráfico de paquetes) de distintas clases. Para este

fin, se desarrollaron nuevos protocolos de comunicaciones que permitieron este

intercambio de información de forma "transparente" para las computadoras que se

conectaron. De la filosofía del proyecto surgió el nombre de "Internet", que se aplicó al

sistema de redes que se interconecta mediante los protocolos TCP e IP [1].

En 1983 el ARPANET cambió el protocolo NCP (Network Control Protocol,

protocolo de control de red) por TCP/IP. Ese mismo año, se creó el IAB (Internet

Architecture Board, consejo de la arquitectura de Internet) con el fin de estandarizar el

protocolo TCP/IP y de proporcionar recursos de investigación a Internet. Por otra parte, se

centró la función de asignación de identificadores en la IANA (Internet Assigned Numbers

Authority, agencia de asignación de números Internet), que posteriormente delegó parte de

sus funciones en el IR (Internet Registry, registro de Internet) que a su vez proporciona

servicios a los DNS (Domain Name System, sistema de nombres de dominio).

En 1986 la NSF (National Science Foundation, fundación nacional de ciencias)

comenzó el desarrollo de NSFNET (National Science Foundation's Network, red de la

fundación nacional de ciencias) que se convirtió en la principal red en árbol de Internet que

se complementó después con otras redes en los Estados Unidos de América. Paralelamente,

otras redes troncales en Europa, tanto públicas como comerciales, junto con las americanas

formaron el esqueleto básico ("backbone") de Internet.

En 1989 con la integración de los protocolos OSI (Open Systems Interconnection,

interconexión de sistemas abiertos) en la arquitectura de Internet, se inició la tendencia

actual de permitir no sólo la interconexión de redes de estructuras diferentes, sino también

la de facilitar el uso de distintos protocolos de comunicaciones.

En el CERN (en francés, Conseil Européen pour la Recherche Nucléaire, consejo

europeo para la investigación nuclear) de Ginebra, un grupo de físicos que encabezó Tim

Berners-Lee, crearon el lenguaje HTML (Hyper Text Markup Language, lenguaje de

marcado de hipertexto), que se basó en el SGML (Standard Generalized Markup

Language, estándar generalizado de lenguaje de marcado). En 1990 el mismo equipo

construyó el primer cliente Web que se llamó WorldWideWeb (WWW) y el primer servidor

Web [1].


16

Comúnmente las páginas Web mostraban información que no cambiaba. Esta forma

estática de mostrar información fue bastante eficiente puesto que la página se creaba una

vez y se presentaba. Cuando era necesario se hacían mínimos cambios y ya estaba lista otra

vez. Pero rápidamente surgió la necesidad de interactuar con el usuario y de adaptar la

información a sus necesidades, o mostrar información que se toma de bases de datos que

frecuentemente cambian. Con la forma que había de crear documentos HTML estáticos era

difícil mantener esas páginas si se querían construir con cierto dinamismo. Por ello

aparecieron las técnicas de generación dinámica de páginas. Estas técnicas permiten la

actualización de páginas aunque se muestra información que cambia frecuentemente y

también posibilitan formas de establecer comunicaciones que se personalizan con los

usuarios [2].

Además, anteriormente era difícil desarrollar un sitio Web que ofreciera a los

usuarios la posibilidad de acceder varios sistemas a partir de una sola página. Los sistemas

estaban drásticamente separados uno del otro y requerían de una gran inversión de tiempo y

trabajo para ponerlos a trabajar juntos en una única página Web. Por ello surgió la

necesidad del desarrollo de portales, los cuales se definen como un sitio con base en HTTP

(HyperText Transfer Protocol, protocolo de transferencia de hipertexto) que se hospeda con

un software especial de portal que permite la agrupación de varios sistemas, procesos o

sitios que se visualizan todos en una sola página de portal. Los portales pueden proveer

servicios adicionales, un ejemplo es la seguridad en una autenticación simple y la capacidad

de personalizar [3].

Un portal de Internet es un sitio que se enfoca en resolver necesidades específicas de

un grupo de personas. Un portal de Internet puede ser un centro de atención a los clientes y

prospectos de venta de su empresa, éstos se pueden complementar con herramientas que le

ayuden a levantar pedidos, atender los problemas de sus clientes, ofrecer cotizaciones,

brindar correos electrónicos, motores de búsqueda, evaluaciones en línea, dar capacitación

a distancia, entre otros [4].

Existen dos modalidades de portales: (1) portales horizontales, que también se

llaman portales masivos o de propósito general, se dirigen a una audiencia amplia, tratando

de llegar a toda la gente con muchas cosas. Como ejemplo de portales de esta categoría

están AOL, AltaVista, Lycos, Yahoo, MSN; y (2) portales verticales, se dirigen a usuarios


17

para ofrecer contenido y comercio dentro de un tema específico como puede ser un portal

de música, un portal de finanzas personales o de deportes. Como ejemplos de esta categoría

se encuentran CNET, SportsLine.com. [4]

Además, en [5] se establece que los portales varían de acuerdo a los usuarios que

sirven y los servicios que ofrecen: (1) portales públicos, tales como yahoo presentan

información de varias fuentes, aplicaciones, y gente, ofreciendo sitios Web que se

personalizan para usuarios arbitrarios, (2) portales empresariales, dan a los empleados

acceso a información específica de la organización y aplicaciones, (3) portales de mercado,

tales como eBay y ChemWeb negocian concentradores que conectan a vendedores y

compradores; y (4) portales que se especializan, tales como SAP ofrecen rutas de acceso a

aplicaciones específicas.

A continuación se presenta la evolución de las diversas tecnologías para portales.

1.3. Evolución de las tecnologías de información.

En esta sección se presentan las tecnologías para portales de la primera generación

hasta la tecnología para portales de la segunda generación. Esta última, basada en portlets.

Primeramente, se presenta la tecnología para portales más antigua, ésta es la

tecnología CGI. A continuación, se presentan las tecnologías que posteriormente surgieron

tales como PHP, ASP, Servlets, JSP y se concluye con la tecnología de portlets. En el

recuento de estas tecnologías se muestra una breve descripción de éstas, sus ventajas y

desventajas particulares.

1.3.1 Common Gateway Interface (CGI)

Los primeros servidores HTTP no incluían ningún mecanismo para generar

respuestas dinámicamente, por lo tanto se crearon interfaces para comunicar el servidor con

programas externos que implementaran dicha funcionalidad [2], estas interfaces se

denominaron CGI. Sin embargo, el gran inconveniente de la tecnología CGI es el


18

rendimiento, ya que por cada petición se crea una nueva copia del programa en la memoria

del servidor. Así, si acceden muchos usuarios de forma simultánea se produce una

disminución en la eficiencia de dicho servidor [6].

Para solucionar las deficiencias de la tecnología CGI aparecieron nuevas tecnologías

que proporcionan más beneficios.

1.3.2. PHP

PHP es un lenguaje de programación que se usa generalmente para la creación de

contenido para sitios Web. El nombre es el acrónimo recursivo de "PHP (Hypertext

Preprocessor, preprocesador de hipertexto)" inicialmente PHP Tools (herramientas PHP) o

Personal Home Page Tools (herramientas de página personal) y se trata de un lenguaje que

se interpreta para usarse en la creación de aplicaciones para servidores o creación de

contenido dinámico para sitios Web [6]. PHP tiene las siguientes ventajas: (1) está

públicamente disponible, (2) es sencillo de aprender, (3) posee numerosas librerías de

funciones que permiten manejar múltiples bases de datos (MySQL, PostgreSQL, entre

otras), (4) utiliza funciones para protocolos de Internet (SMTP, POP3, IMAP, SNMP,

HTTP, entre otras), (5) es multiplataforma; y (6) existe una amplia comunidad de PHP con

una base de conocimientos amplia sobre el lenguaje [7]. Sin embargo, la Programación

Orientada a Objetos (POO) en versiones anteriores a la versión cinco de PHP, carecía de

potencia [8]. El mayor problema de la POO consistía en que cada vez que se asignaba una

variable que contenía un objeto a otra variable o se transmitía un objeto por parámetro en

una función, se realizaba una copia (un clon) de ese objeto y quedaba a disposición del

programa en la nueva variable o parámetro. Todo esto implica que el espacio en memoria

para guardar los dos objetos es el doble que si fuera un mismo objeto con dos nombres

distintos. No obstante, para solventar este problema en la versión actual de PHP (versión

cinco) se hace uso de los manejadores de objetos (Object handles), que son una especie de

dato de tipo puntero que señala hacia los espacios en memoria donde residen los objetos.

Cuando se asigna un manejador de objetos o se pasa como parámetro en una función, se

duplica el propio object handle y no el objeto en si [9].


19

Otro inconveniente de PHP está en relación a cierta complejidad en sus métodos de

instalación ya que se puede instalar PHP sobre un servidor bien como un interprete CGI o

como un módulo de Apache (éste es un servidor Web). Cada método tiene sus ventajas y

desventajas. Si se instala PHP como un intérprete CGI ofrece la oportunidad de tener tantos

procesos ejecutándose como identificadores de usuarios diferentes bajo anfitriones

virtuales. Cuando PHP se instala como un módulo Apache se debe elegir si será un módulo

estático o dinámico. Un módulo estático es una compilación previa de PHP con Apache;

mientras que un módulo dinámico se caracteriza por cargarse sin necesidad de compilar

Apache. Un módulo estático tiene la ventaja de incrementar el desempeño, pero cuando se

desea actualizar se tiene que recompilar tanto al PHP como al Apache. Con un módulo

dinámico, se pierde desempeño. Sin embargo, las correcciones y actualización del PHP son

mucho más fáciles cuando se instala como un módulo dinámico [10].

1.3.3. Active Server Pages (ASP)

ASP es una tecnología que desarrolló Microsoft que aporta capacidad operativa a

las páginas Web, combinando HTML con un lenguaje de secuencia de comandos o

lenguaje script. Los lenguajes que más se usan actualmente para programar el código script

dentro de las páginas ASP son VBScript y JScript, aunque también se pueden utilizar otros

como Python. El código contenido en estos scripts se ejecuta en el servidor y el navegador

del cliente tan sólo recibe páginas HTML, lo que convierte a ASP en una tecnología válida

para cualquier tipo de navegador. ASP utiliza la tecnología que se denomina ISAPI

(Internet Server Aplication Program Interface, interfaz de programa de aplicación de

servidor de Internet). Una aplicación ISAPI se basa en librerías de enlace dinámico que se

ejecutan en el mismo espacio de direcciones que el servidor Web, de manera que soportan

numerosas peticiones simultáneas con una sola imagen en memoria [6]. Sin embargo,

aunque se desarrollaron herramientas para portar ASP a otras plataformas, la potencia de

ASP está en el uso de objetos Active-X (VBScript incluye soporte para acceso a

componentes Active-X), que sólo están disponibles para sistemas operativos Windows [2].


20

1.3.4. Servlets

Los servlets son clases Java, embebidas dentro del servidor Web y que se utilizan

para extender la capacidad del servidor. La API de servlets provee clases e interfaces para

responder a requerimientos; en particular para las aplicaciones que se ejecutan en

servidores Web. La API define clases de servlets específicas para requerimientos HTTP

[11]. Sus ventajas consisten en que: (1) los servlets son independientes de la plataforma

(porque están escritos en Java), son independientes del servidor y además pueden acceder a

todos los APIs de Java, posibilitando el desarrollo de verdaderas aplicaciones en la Web; y

(2) la diferencia fundamental entre CGI y los servlets es la persistencia; esto quiere decir

que una vez que un servlet se desarrolló permanece en memoria y puede atender múltiples

peticiones de servicios, por esa razón esta alternativa es más rápida que el CGI tradicional

al no necesitar lanzar un nuevo proceso cada vez que se realiza una petición [12]. Sin

embargo, el enfoque que se basa en servlets tiene los siguientes inconvenientes: (1) se

necesita un conocimiento detallado del lenguaje Java para mantener todos los aspectos de la

aplicación ya que el código de procesamiento y los elementos de HTML están juntos, (2)

cambiar la apariencia de una aplicación o agregar soporte para nuevos tipos de cliente, por

ejemplo WML (Wireless Markup Language, lenguaje de marcado de dispositivos móviles)

requiere la actualización y recompilación del código del servlet; y (3) es difícil aprovechar

herramientas de desarrollo de páginas Web (editores de HTML) al diseñar la interfaz. Si

esas herramientas se utilizan para desarrollar la estructura del documento el código HTML

que se genera debe embeberse en el código del servlet. Este proceso consume mucho

tiempo, es propenso a errores y extremadamente tedioso [13].

1.3.5. JavaServer Pages (JSP)

La tecnología JSP es una extensión de los servlets que desarrolló Sun como

alternativa a la tecnología ASP de Microsoft; básicamente, permite la introducción de

código Java dentro del código HTML, dicho código Java puede llevar a cabo diversas

tareas, como por ejemplo utilizar servicios que se proporcionan por servlets [12]. Los


21

elementos JSP se pueden usar para una gran variedad de propósitos como recuperar

información de una base de datos o registrar preferencias del usuario [13]. La ventaja de

JSP en comparación a los servlets es que es una extensión de la tecnología Java servlets;

mientras que estos últimos tienen que mantener plantillas de código HTML dentro del

programa, JSP contiene estas plantillas dentro de las propias páginas [14]. En comparación

con otras tecnologías, su ventaja es la independencia de la plataforma tanto cliente como

servidor. Por un lado, la utilización de código Java garantiza la portabilidad de la aplicación

para su ejecución en cualquier servidor que contenga una máquina virtual Java. Esta es una

ventaja sustancial frente a otras tecnologías similares, como por ejemplo Active Server

Pages (ASP). En el caso del cliente, al recibir sólo páginas HTML hace que sea compatible

con cualquier navegador. Sin embargo, JSP no permite satisfacer el requerimiento de

acceso a recursos e información que se proporcione por terceras partes, por ejemplo, de un

proveedor de noticias.

1.3.6. Los Portlets

La tecnología para portales de segunda generación se constituye por portlets. Éstos

son componentes Web que se controlan por un contenedor capaz de generar contenido

dinámico e interactuar con los usuarios a través del portal [15]. Un portlet provee

contenido a su contenedor de portal que lo invocó para efectos de despliegue de la

información en una página de portal. El contenido que se genera por un portlet se conoce

como fragmento o código de fragmento. Este es el código HTML que se generó a partir del

código de despliegue del portlet [3]. Las ventajas que plantean estos elementos son: (1) su

versatilidad en el tiempo en que se desarrollan y despliegan porque los portlets pueden

generar distintos tipos de contenidos en función del mecanismo de acceso o a la

información a la que tienen acceso, (2) un portlet debe verse como un encapsulado de una

aplicación Web para poder utilizarse como un componente dentro de un portal [15]; y (3)

un contenedor de portlets maneja múltiples solicitudes a un portlet utilizando las mismas

instancias de una clase portlet, invocándolas en diferentes instancias de ejecución a través

de los mismos métodos [3], con la eficiencia y economía que ello implica. Sin embargo, en


22

[3] se hace notar que quedan pendientes tareas a resolver para versiones futuras de los

portlets.

Por otra parte, la ventaja de los portlets contra las tecnologías de los portales de

primera generación, tales como CGI, ASP, PHP, JSP, Servlets, entre otros, consiste en que

éstos encontraron problemas de compatibilidad para acceder a contenidos y aplicaciones de

proveedores de diversas tecnologías, es decir, son monolíticos. Mientras que los portlets

además de que constituyen componentes Web con las ventajas que esto implica, se basan

en las especificaciones JSR 168 (Java Specification Request, especificación de portlet de

Java) y WSRP (Web Services for Remote Portlets, servicios Web para portlets remotos) que

son de aceptación creciente entre los proveedores de contenidos y aplicaciones Web lo cual

permite apoyar a portales como intermediarios múltiples para alcanzar una cantidad

enorme de usuarios finales, que de otra manera no sería posible.

A continuación, en la tabla 1.1 se presenta una síntesis de las desventajas

particulares de las tecnologías para portales de primera generación.

Tecnología Desventaja particular

CGI Ejecuciones pesadas para el microprocesador. Cada petición al servidor se

traduce en una nueva copia del programa en la memoria de éste.

ASP Alcanza su mayor potencia con el uso de los objetos denominados Active-X,

los cuales están disponibles sólo en sistemas operativos Windows.

PHP Complejidad en sus métodos de instalación. Además, la programación

orientada a objetos en versiones anteriores (a la versión cinco) carecía de

potencia.

Servlets Requiere mantener plantillas de código HTML dentro del programa Java.

Esto hace a la tecnología compleja y difícil de entender.

JSP Como las demás tecnologías de portales de primera generación. JSP no

permite acceder a recursos e información provistos por terceras partes.

Tabla 1.1. Desventajas de las tecnologías de portales de la primera generación.


23

1.4. Planteamiento del problema

El integrar recursos e información empresarial propia y de terceras partes en el

desarrollo de un portal de segunda generación requiere abordar un problema de integración

de información. Estos problemas consisten en la necesidad de encontrar compatibilidad al

acceder recursos que se encuentran en diferentes: (1) plataformas operativas, (2) bases de

datos; y (3) lenguajes de programación o modelos de programación, entre otros.

Considérese el siguiente ejemplo: un administrador de portal de empleado quiere

incluir un servicio de recursos humanos para calcular la variable pago para empleados y un

servicio de previsión del clima. Una solución para este escenario se describe en la figura

1.1: un portlet de recursos humanos y un portlet de previsión del tiempo que se ejecuta

localmente en el servidor del portal y con acceso a servicio Web remoto para obtener la

información requerida, es decir, el servicio Web provee datos y la capa de presentación se

implementa en portlets específicos [16].

Figura 1.1. Portlets locales que usan servicios Web remotos.

El portlet de recursos humanos usa un servicio Web de recursos humanos para

calcular la variable pago. Por consiguiente, despliega un formulario para consultar los datos

de entrada, por ejemplo, el identificador de empleado (id). Cuando el empleado provee los

datos para el portlet de recursos humanos, invoca el servicio Web de recursos humanos

para calcular la variable pago que se basa sobre esos datos. Recibe el resultado desde el

servicio Web y lo despliega como un fragmento de página. El portlet de previsión del

Portal del

empleado

Portlet

del clima

Portlet de

R. H.

Servicio Web del

clima

Servicio Web de

R. H.


24

tiempo despliega la previsión del tiempo para ciudades configurables y permite al usuario

seleccionar las localidades en un modo edit (edición). Cuando el portlet de previsión del

tiempo se invoca durante la carga de la página, solicita la más reciente previsión del tiempo

para las localidades seleccionadas del servicio Web de previsión del tiempo y despliega un

fragmento de página con aquellas previsiones del tiempo.

Este enfoque solamente funciona si todos los portlets se instalan físicamente en el

portal del empleado. El proceso de hacer nuevos portlets disponibles es tedioso y caro; la

capa de presentación debe redesarrollarse para cada portal. Para integrar la información de

recursos humanos en el portal usando portlets locales, o el departamento de recursos

humanos podría implementar el portlet de recursos humanos y darlo a uno de los

administradores del portal de empleado para instalarlo, o un desarrollador del portal de

empleado podría implementar el portlet de recursos humanos de acuerdo a la descripción de

interfaz del servicio Web de recursos humanos, similar esfuerzo se requeriría para el portlet

de previsión del tiempo.

Obviamente, sería mucho más conveniente si los servicios Web de recursos

humanos y previsión del tiempo incluyen lógica de aplicación y presentación y ellos

mismos producen fragmentos de marcado que son fáciles para agregar al portal

consumidor, como se muestra en la figura 1.2 [16].

Figura 1.2. Un portal que usa servicios Web de portlets remotos

En vez de proveer sólo datos escuetos o funciones de negocios simples que todavía

requieren especial interpretación en el lado del portal, WSRP tiene orientación al usuario y

Portal del

empleado

Portlet

Proxy

Portlet

Proxy

Servicio

Web del

clima

Servicio

Web de

R. H.

Portlet

Clima

Portlet

R. H.


25

son servicios Web interactivos que incluyen la presentación. Ellos son fáciles de agregar y

se invocan a través de una interfaz común usando un código Proxy de portlet genérico que

se construye en el portal. Ningún código de portlet especial necesita instalarse en todos los

portales y se evita la re-implementación de la capa de presentación en cada portal.

Los portlets remotos hacen la tarea más accesible porque dichos portlets pueden

añadirse dinámicamente al ambiente, y beneficiar a los usuarios a través de tener más

servicios disponibles de una manera oportuna. Se pueden agregar servicios de portlet

remotos en un portal usando su interfaz de usuario de administración de portal para

encontrarlos y unirlos con poco esfuerzo. Como resultado, el portal crea nuevos Proxis de

portlets genéricos que se unen a servicios Web de portlets remotos para que estén

disponibles a los usuarios en la misma manera que los portlets locales.

Sin embargo, aunque los portlets se basan en estándares que abordan el problema de

la arquitectura monolítica de los portales de la primera generación, el estudio del estado del

arte muestra la necesidad de esfuerzos para crear plataformas de integración de información

que satisfagan diversos sistemas de información y las tecnologías que apoyan estos

esfuerzos.

1.5 Estado del arte

Los portlets son componentes Web que constituyen la tecnología para el desarrollo

de los portales de la segunda generación. Los Portlets son elementos dinámicos de creación

de contenidos. Presentan y suman información de una o varias fuente de datos. Generan

html y xml (es decir, documentos digitales a través de estos lenguajes de marcado) en un

área que se muestra dentro de la página del portal. Son reutilizables y pueden

personalizarse. Para el desarrollo de portales empresariales actualmente existen algunos

trabajos que se orientan hacia la conformación y administración de catálogos de portlets.

Bellas [17] argumenta que los portales de primera generación tienden a presentar

una arquitectura monolítica de software que compromete el desarrollo y el mantenimiento

del portal. No obstante, dos estándares propuestos en otoño de 2003 – los servicios Web

para portlets remotos (WSRP) y la especificación java de portlets abordan estos problemas.


26

En octubre de 2003, la comunidad Java desarrolló la primera versión de la especificación

java de portlets (JSR 168), estandarizando una API de Java para los portlets compatibles

WSRP que se pueden desplegar en cualquier contenedor estándar de portlet en Java. En

contraste a los portales de primera generación, los portales de segunda generación permiten

a los usuarios crear una o más páginas personales que se integran por portlets –

aplicaciones mini Web interactivas- locales o remotas al portal. Los portales de segunda

generación presentan una arquitectura que se orienta a componentes en la cual cada portlet

es un componente que se puede implementar en el portal mejorando así el desarrollo,

mantenimiento y reuso.

Wege [5] propone una descripción en detalle de tipos de portales y servicios. En

donde los portales varían de acuerdo a los usuarios que sirven y los servicios que ofrecen.

Dentro de esta descripción se encuentran: (1) portales públicos, (2) portales empresariales,

(3) portales de mercado; y (4) portales especializados. Un aspecto importante en el

desarrollo de estas aplicaciones es la tecnología de información que permite implementar

servicios comunes tales como: (1) la agregación de contenido que provee contenido de

diferentes fuentes para diferentes usuarios, (2) la agrupación de contenido que recolecta

contenido de diferentes fuentes, (3) la ayuda múltiple que provee contenido para diferentes

canales de interacción, (4) servicio único sign-on que permite recuperar información de

usuarios específicos sin requerir autentificación de usuario cada vez, (5) administración de

portal que determina cómo los usuarios ven el portal; y (6) los usuarios pueden típicamente

subscribirse ellos mismos a portales Web públicos.

Chihcheng et. al. [18] propone que es necesario crear una plataforma de integración

para sistemas de aprendizaje. Se destacan cuatro dificultades en los sistemas de aprendizaje

e-learning actuales. Estas dificultades son la raíz de la causa del actual desaprovechamiento

de sistemas de aprendizaje e-learning monolíticos; estas dificultades son: (1)

interoperabilidad de sistemas de aprendizaje e-learning, (2) colaboración de objetos de

aprendizaje, (3) nivel de presentación integración de objetos de aprendizaje e-learning; y

(4) acceso transparente de sistemas de aprendizaje e-learning. En el sistema propuesto se

emplean servicios WSRP para preservar la presentación de objetos compartidos e-learning

desde otros sistemas. También se propone a BPEL4WS (Business Process Execution

Language for Web Services, Lenguaje de ejecución de procesos de negocios para servicios


27

Web) para los flujos de trabajo de cursos que se basan en tareas que se orquestan entre

sistemas de aprendizaje compartidos. Se explican pasos claves en la preparación de curso y

la ejecución para proveer cuadros claros de cómo el sistema propuesto permite la

interoperabilidad de numerosos objetos / componentes / sistemas de aprendizaje.

Dahan et. al. [19] plantea que los portales Grid (portales que proveen salida a la

tecnología Grid, la cual es un tipo de sistema distribuido que permite compartir, seleccionar

y agregar recursos dispersos) que se sistematizan pueden servir como uno o múltiples

puntos de entrada a recursos de computación proporcionando acceso a herramientas grid y

servicios, lo que facilita la barrera de entrada a la computación que se basa en Grids para

conducir investigaciones científicas. Grid Portal Toolkit Versión 3.0 (GridPort) aborda este

problema proporcionando un conjunto de capacidades para usar recursos de computación a

través de una API para construir portales Grid y aplicaciones sobre la infraestructura Grid.

GridPort agrega servicios grid provistos por otro software grid, añade servicios grid

adicionales y presenta una API para desarrolladores. GridPort provee información y

servicios interactivos para portal y aplicaciones. Usa servicios informativos para

suministrar computación que se distribuye y que se relacionan de numerosas tecnologías

Grid. El repositorio de información GridPort (GPIR) almacena y archiva datos,

proporcionando la actualización y el historial de datos a través de servicios Web.

Galligan et. al. [20] expone que cierta organización adquirió una suite de portal

invirtiendo un alto costo y se propuso obtener un rápido retorno de inversión mientras el

desarrollo del portal estaba en curso. Para esto, se utilizó una metodología y modelo de

ciclo de vida para ayudar al proceso de desarrollo. El enfoque facilitó dos rutas de

tecnología. La primera fue para el área de integración de portal. Esta área involucró la

consolidación de aplicaciones distribuidas existentes con el propósito de mejorar

eficientemente a través de funcionalidades tales como flujos de trabajo que se organizaron

y procesos de negocios que se automatizaron. La segunda ruta se enfocó más sobre

aplicaciones externas que pudieran describirse como servicios que se entregan como

aplicaciones del nuevo portal. Por último, se propuso combinar metas de ambas rutas para

lograr bajos costos a través del desarrollo eficiente por medio de la entrega de servicios que

incrementaron el ingreso.


28

Puschmann et. al. [21] plantea que los portales de proceso soportan redes de

negocios inter-organizacionales. Ellos definen la función y contenido sobre la base de

procesos de cliente y los hacen disponibles a través de un rol que se basa en una interfaz

que se personaliza. Sin embargo, a pesar de la creciente relevancia de portales de proceso,

su uso en la mayoría de negocios está todavía en comienzos. Se sugiere que una

arquitectura consistente y modelos de integración pueden ayudar a los negocios con la

introducción de portales de procesos. Los portales integran diferentes funciones,

mayormente aplicaciones heterogéneas y las sitúa en el contexto de procesos de negocios

específicos. En el futuro, una empresa proveerá a sus clientes todos los servicios que

ofrece. Estos servicios pueden estar disponibles interna o externamente a través de los

portales de: (1) empleado (B2E), (2) proveedor (B2B), (3) cliente (B2C); y (4) de

distribuidor (B2B).

Beeson et. al. [22] presenta un nuevo portal para ejecutar código numérico científico

sobre el Grid. Se hace particular énfasis en el re-empleo y la portabilidad en los portlets. Se

encontró que el estándar JSR 168 es adecuado para crear portlets portables. Para portales

que se forman de muchos portlets se presenta un sistema de comunicación portable. La

promesa de la computación que se basa en Grid ofrece a los investigadores acceso

transparente a recursos de computación en Internet. El desarrollo de portlets Grid es una

tarea desafiante porque la tecnología está cambiando rápidamente. Para que la

infraestructura Grid se explote, se considera la necesidad de crear interfaces fáciles de usar.

El re-uso es fundamental para satisfacer la necesidad de un rápido desarrollo en un

ambiente cambiante y las similitudes entre aplicaciones. Finalmente, se presenta un

conjunto para el re-uso de portlets con el fin de ejecutar programas que se basan en STRIP

sobre el Grid.

Novotny et. al. [23] menciona que el framework de portal GridSphere provee

estándares que se basan en portal para el fácil desarrollo de componentes Web que se

llaman portlets. Los portlets se definen por una API estándar y provee un modelo para

desarrollar nuevos componentes de portal que pueden compartirse e intercambiarse por

varios contenedores de portlets. GridSphere provee un contenedor de portlets, una

colección de portlets y una librería avanzada de interfaz de usuario que permite a los

desarrolladores de aplicaciones implementar fácilmente nuevos portlets. El framework


29

GridSphere provee un conjunto de portlets que ofrecen la funcionalidad básica requerida

para el re-uso. Algunos de los portlets provistos son: (1) login, (2) salir del sistema, (3)

determinar selección de idioma, (4) proveer una interfaz para un nuevo usuario de portal,

(5) la habilidad para asignar / revocar roles de usuarios, (6) administración de usuarios, (7)

proveer la habilidad a los usuarios de editar información personal; y (8) suscripción de

portlets.

Pierce et. al. [24] plantea que los portales Web se diseñaron para simplificar el

acceso a diversos conjuntos de recursos de computación de alto desempeño, típicamente a

través de herramientas Grid. Una limitación importante de estos portales es la falta de

servicios interoperables y reutilizables. Con base en esto, se presenta una descripción de

esfuerzos de investigación que se emprendieron para construir servicios interoperativos

alrededor de un modelo de servicios Web. Se presenta una arquitectura de portal

interoperable empezando con servicios de portal de base que se usa para construir

aplicaciones de servicios Web, las cuales se agregan y manejan a través de contenedores de

portlets. Tres tipos de servicios Web de portal se describen: (1) aplicaciones, (2) comandos

Shell de portal y, (3) servicios de contenido (información) que interactúa con objetos de

datos XML.

Weinreich et. al. [25] expone que los portales Web son un medio para la integración

del nivel de presentación de aplicaciones de empresa y servicios. Se describe un enfoque

para aumentar la integración del nivel de presentación en portales Web soportando

comunicación entre componentes del nivel de presentación. Este enfoque se basa en

estándares en esta área y permite el intercambio de datos XML que se estructuran entre

aplicaciones y servicios locales y remotos. Desde el enfoque que es principalmente

declarativo, puede también usarse para mejorar la integración de componentes existentes de

presentación. El enfoque de este trabajo se motivó por la integración de requerimientos que

relacionan instituciones financieras en Austria, quienes necesitaban integrar aplicaciones y

servicios que se ofrecía físicamente y organizacionalmente en separados centros de

cómputo con diferente infraestructura de servidor de hardware y software. El enfoque se

basa sobre la especificación de portlet y sobre la especificación WSRP. La especificación

de portlet define un componente de modelo de presentación (portlets) en Java. Un servidor


30

de portal manejable JSR 168 típicamente se implementa sobre la base de una Web

manejable J2EE o servidor de aplicación.

Díaz et. al. [26] plantea que la mayoría de los frameworks de portal soportan

actualmente los portlets. Sin embargo, no hay todavía una respuesta definitiva para la

interoperación del portlet con lo cual el flujo de datos desde un portlet a otro cercano. Se

discute que éstas limitaciones se pueden vencer a través de usar anotaciones técnicas

profundas. Proveyendo marcado adicional sobre servicios de fondo, esfuerzos de anotación

profunda para interactuar con estos servicios fundamentales. Se consideran anotaciones

profundas como validación particular para interoperación de portlet que se debe al ambiente

controlado y corporativo que caracteriza el ajuste del portal. Aumentar la experiencia del

usuario es uno de los distintivos de los portales. Esto implica para el usuario percibir los

distintos ofrecimientos de un portal como un área de trabajo que se integra en donde el flujo

de datos entre los distintos portlets está enmarcado por el portal. El ambiente controlado y

cooperativo que caracteriza al portal facilita el uso de anotaciones profundas para la

interoperación del portlet.

Diaz et. al. [27] argumenta que la variabilidad de demandas para portlets se

encamina a ser más severa que para otra clase de componentes de software que se debe

tanto al sensitivo tema que encapsulan (esto es la presentación) y la necesidad de

personalización que caracteriza uno de sus principales consumidores, esto es, aplicaciones

de portal. Este trabajo propone instrumentar portlets para variabilidad de usos. Apache

Cocoon es un framework de desarrollo Web que se construyó alrededor de los conceptos de

intereses y desarrollo Web que se basó en componentes y permiten una evolución paralela

de todos los aspectos de una aplicación Web mejorando pasos de desarrollo y reduciendo la

oportunidad de conflictos. Este enfoque es un paso en la misma dirección a la que se dirige

el trabajo de [27]. El cual se probó sobre una aplicación de franquicia de una gran

compañía de franquicia de cosméticos. Los portlets se usarán (como trabajo futuro) para

soportar el catálogo de cosméticos. Este catálogo se produjo por la compañía matriz y se

desplegó en los portales de los socios comerciales. Sin embargo, cada franquicia socia

necesitó añadir algunos datos que se personalizaron (por ejemplo, precios y

recomendaciones se fijaron de una manera que se apoyó en el socio comercial).


31

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

otras arquitecturas y una breve descripción de estas arquitecturas. Además, se analiza

brevemente las diferencias de cada una de estas arquitecturas contra la propuesta en este

trabajo, que más adelante se describe. En el análisis de estas diferencias, dado que el uso de

portlets y del servidor de portal son elementos típicos para la arquitectura propuesta y la de

estos trabajos relacionados no se hace énfasis en ello.

En [28] se expone que Healthcare@Home es un proyecto de investigación que

implementa un prototipo de entrada o salida de datos a través de dispositivos móviles y/o

servidores de red dedicados para uno o más motores de análisis de datos. Su arquitectura

consta de un servidor de portal que provee una interfaz segura y adaptable entre el usuario

final experimental (clínicas, pacientes e investigadores) y el middleware El proyecto creó

varios portlets para cada rol de usuario que identificó previamente, y los hospedó en el

mismo ambiente de servidor de portal. Además, consta de un servidor de procesos y una

base de datos para almacenar información del paciente en una localidad geográfica

particular. En nuestra propuesta, el dominio de aplicación es diferente. Además, nuestro

enfoque no presente algún tipo de middleware.

En [29] se presenta una experiencia en diseño y construcción de un portlet para

OGSA-DAI y en probar el acceso de servicio grid a base de datos relacionales por medio

de un resumido volumen de trabajo de bases de datos. OGSA-DAI provee una extensión

para el marco de trabajo OGSA a través de permitir el acceso y la integración de datos que

se controlan en fuentes de datos heterogéneas. Su arquitectura tiene elementos tales como:

(1) un contenedor de servlets, Tomcat, que sirve con un contenedor de hospedaje de

servicio Web tanto para OGSA-DAI y el portal Alliance, (2) una implementación de portal,

Jetspeed, que provee un API para desarrollar portlets, (3) el portal Alliance en el cual reside

el portlet OGSA-DAI; y (4) grid OGSA-DAI que permite implementación de referencia

middleware permitiendo acceso y control para fuentes de datos externas, entre otros. Este

trabajo se enfoca más al área de computación grid que utiliza los servicios grid, mientras

que nuestra propuesta se sitúa en el cómputo orientado a servicios que utiliza servicios

Web.

En [30] se muestra un framework para desarrollar un sistema de portal de salud que

depende de la noción de servicios diferenciados (por ejemplo, servicios que proveen un


32

comportamiento común con calidad de servicio variable) para sobrevivir a cargas de tráfico

inesperadas y disminución en servicios Web fundamentales. Su arquitectura tiene como

objetivo manejar y supervisar el uso de varios servicios. Esta arquitectura presenta al centro

al servidor de portal, los clientes se presentan a la izquierda y a la derecha, se muestran los

servicios que se ejecutan en máquinas separadas. En su framework, el servidor de portal se

crea de un sistema de hospedaje de portal, supervisión automática y varias envolturas de

portlet de servicios de salud (un portlet interpreta uno por servicio). Al igual que en [28],

una diferencia importante es el dominio de la aplicación.

En [31] se indica la problemática de una corporación en la cual se acumula un largo

número de documentos de interés para sus ingenieros, lo que hace imposible, a éstos,

examinarlos a fondo. Este trabajo presenta un prototipo de repositorio de documentos

basado en conocimiento para una aplicación. Su arquitectura emplea los estándares Web

existentes tanto como es posible, para maximizar el re-uso de herramientas, compatibilidad

y portabilidad. Un portal Web provee una interfaz de usuario integrada, y manejadores de

autentificación y flujos de trabajo. La interfaz de usuario la forman de una serie de portlets.

Sus portlets acceden a uno o más servicios Web. Este trabajo se sitúa más en el uso de

técnicas de recuperación de información mediante el uso de servicios Web. Por el contrario,

nuestro trabajo se centra en la re-usabilidad de los servicios Web mediante el uso de

portlets.

En [32] se enuncia que su producto, denominado ClayNet, es una plataforma que

contribuye a la funcionalidad que se desea para procesos e-learning (entorno de educación a

distancia online), se integra en un portal y se constituye por componentes ensamblados con

estructura independiente que se definen como portlets. Su arquitectura presenta al conjunto

de portlets en el nivel más alto. Sus portlets engloban una serie de clases que cumplen con

la especificación JSR 168 y con un conjunto de elementos JSP. Estos elementos se

gestionan por el contenedor de portlets. Los portlets de ClayNet también se apoyan en una

base de datos externa para realizar la persistencia de datos. El sistema gestor de base de

datos que utilizan es MySQL. Este es un trabajo similar al enfoque propuesto en esta tesis.

Existe una similitud en el uso de un contenedor de portlets. Sin embargo, una diferencia

importante reside en el uso de los estándares para portlets. El enfoque que presenta esta


33

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

propuesta de esta tesis no se utiliza una base de datos para la persistencia de la información.

1.6 Propuesta de solución

Las empresas buscan los beneficios de la distribución de información a través de

Internet. En este sentido, un portal empresarial aporta resultados como una herramienta

para hacer accesibles la venta de productos y/o servicios a los clientes, además de facilitar

la colaboración con los empleados y proveedores. En esta dirección, el problema a resolver

en esta tesis es la necesidad de integrar información y recursos empresariales propios y de

terceras partes en el desarrollo de un portal de segunda generación. Esta integración

requiere superar limitantes tales como la dependencia de la plataforma, modelos de

desarrollo y lenguajes de programación que se usen.

Con esta finalidad el objetivo general de este trabajo es desarrollar un portal

empresarial con base en el desarrollo de una aplicación basada en componentes Web que se

gestionen por un contenedor de portlets que procese peticiones y genere contenido

dinámico.

En consecuencia, la hipótesis establece que con la utilización de la tecnología de

información Open Source se llevará a cabo lo que determina el objetivo general y que el

uso de la tecnología Open Source dará al sistema a desarrollar la característica de la

portabilidad.

Asimismo se presenta una arquitectura que permite la integración de aplicaciones y

recursos a través de la tecnología de portlets. Esta arquitectura de integración se compone

por capas y plantea: (1) qué servicios provee cada capa, (2) cómo funcionan entre sí los

componentes de cada capa; y (3) cómo interactúan los componentes de una determinada

capa con los de otra capa. Recordando que la capa inferior ofrece servicios a la capa

inmediata superior.

En este trabajo se proponen los siguientes objetivos específicos: (1) desarrollar el

conjunto de portlets para la arquitectura de integración para el portal empresarial; y (2)

permitir la personalización, la presentación y la gestión de seguridad a través de los

portlets.


34

Finalmente, las aportaciones originales del presente trabajo son: (1) una arquitectura

de integración bajo diferentes niveles de prestación de servicios; y (2) un conjunto de

mecanismos que definen la funcionalidad de los servicios que se representan como portlets.

1.7. Resumen

En este capítulo, se presentó una revisión breve de la historia de Internet y de las

tecnologías para portales de la primera generación. Se argumentó que las empresas

requieren ofertar sus productos y servicios a través de portales, y que para el desarrollo de

los portales de la primera generación se emplearon tecnologías tales como: CGI, PHP, ASP,

servlets, JSP, entre otras. Para cada una de estas tecnologías, se mostraron sus desventajas

particulares. Y se argumentó que todas las tecnologías para portales de primera generación

en su conjunto, tienen la desventaja de que crear portales monolíticos. Como consecuencia

a lo anterior, se presentó a la tecnología de portales de segunda generación, la cual se

compone por portlets.

Por lo tanto, se estableció el planteamiento del problema. En éste, se fundamenta

que el problema a resolver en la tesis es un problema de integración de información. Este

problema tiene importancia porque se trata de información que no tan solo proviene de la

misma organización en cuestión, sino de entidades que operan con tecnologías de diversas

naturalezas.

En el estado del arte, se mostraron trabajos de investigadores en relación a la

tecnología basada en portlets. Parte de estos trabajos se refieren a desarrollos de

arquitecturas basadas en portlets para atender necesidades particulares. En torno a esto

último, se argumentó, brevemente, las diferencias y similitudes de esas arquitecturas contra

la propuesta en esta tesis.

Finalmente, se presentó la propuesta de solución. En ésta, se incluyó respuestas a

cuestiones básicas de la tesis, tal como el objetivo general y los objetivos particulares de la

misma, la hipótesis y las contribuciones, entre otras.


35

Capítulo 2: Tecnología de portlets

2.1 Introducción

Los portales usan portlets como componentes de interfaz de usuario que proveen de

una capa de presentación a los sistemas de información [33]. Los portlets se orientan al

usuario y son componentes de aplicaciones Web interactivas que se diseñan para agregarse

a través de un portal y comunicarse con usuarios a través de un servidor de portal huésped.

Los portlets son locales o remotos al portal servidor [16].

En este capítulo se estudian los estándares que constituyen la tecnología de los

portlets para el desarrollo de los portales de la segunda generación. Además, se hace una

revisión de los ambientes de desarrollo que soportan la tecnología de portlets.

2.2 Estándares JSR 168 y WSRP

El estándar JSR 168 define un API de portlet estándar que es específico para

portales que se basan en Java, el cual los desarrolladores utilizan para programar portlets

que se ejecutarán en un servidor de portal manejable; mientras que WSRP define un API

universal que permite a los portales de cualquier tipo consumir portlets de cualquier tipo.

De tal forma que, productores WSRP permiten a portlets JSR 168 estar disponibles para

consumidores remotos WSRP y permiten a los portales que se basan en Java consumir

portlets originarios de otros ambientes, por ejemplo .NET [34].


36

2.2.1 Estándar JSR 168 (The Java Portlet Specification, la especificación del portlet de

Java)

JSR 168 es una especificación de portlet del sistema de la comunidad Java [34].

Este estándar aborda la necesidad de permitir la interoperabilidad entre portales y portlets.

Ya que anteriormente era difícil hacer un sitio Web que le ofreciera a los usuarios la

posibilidad de acceder varios sistemas a partir de una sola página.

JSR 168 se enfoca a las siguientes temáticas: (1) el contrato del contenedor de

portlet y la administración del ciclo de vida, (2) la definición de los estados de ventana y los

modos del portlet, (3) administración de preferencias del portlet, (4) información del

usuario, (5) embalaje y despliegue, (6) seguridad; y (7) etiquetas JSP para ayudar al

desarrollo del portlet [35].

Los métodos del ciclo de vida que se invocan directamente por el contenedor son:

(1) init(), el cual se invoca cuando el portlet se concreta por el contenedor. Intenta contener

la lógica que prepara el portlet para atender solicitudes, (2) destroy (), el cual se invoca

cuando el contenedor destruye el portlet. Intenta contener la lógica que libera la memoria

cuando el portlet ya no se necesita o se apaga el servidor, (3) processAction(), el cual se

invoca después de que el usuario suministra cambios al portlet. Intenta procesar la entrada

desde una acción de usuario; y (4) render(), el cual se invoca siempre que el portlet se re-

invoca a través de la pantalla principal del sistema operativo.

Se puede extender una clase denominada GenericPortlet e implementar tantos de

estos métodos render() como sean necesarios para un portlet. Estos métodos son: (1)

doView(), el cual se invoca por render() cuando el portlet está en modo View. Intenta

contener la lógica que despliega la vista de la página del portlet, (2) doEdit(), el cual se

invoca por render() cuando el portlet está en modo Edit. Intenta contener la lógica que

despliega la página de edición para el portlet; y (3) doHelp(), el cual se invoca por render()

cuando el portlet está en modo Help. Intenta contener la lógica que despliega la página de

ayuda para el portlet.

Como indican los métodos que antes se mencionan, los modos que se definen en la

especificación del portlet son View, Edit y Help. En el modo View, el portlet debe

desplegar el contenido normal, que se basa en la funcionalidad que ofrece el portlet. En


37

modo Edit, el portlet debe presentar al usuario la posibilidad de personalizar cualquier cosa

que sea configurable para el portlet. El modo Help debe dar una descripción completa de

como el portlet se usa (explicando los modos Edit y View) o una ayuda sensitiva al

contexto explicando las características seleccionadas del portlet [3]. Por otra parte, los tres

estados de la ventana de cada portlet son: minimizado, maximizado o normal.

Los portlets a menudo se configuran para proveer una vista que se personaliza o

funciona para diferentes usuarios. En la especificación de portlet, su contenedor es

responsable de recuperar y almacenar estas preferencias a través de la interfaz

PortletPreferences.

La especificación portlet provee un mecanismo para acceder a la información de un

usuario – tales como nombre, correo electrónico, teléfono y dirección – en el descriptor que

se despliega de la aplicación del portlet

La especificación portlet describe el embalaje y despliegue de portlets como parte

del archivo de aplicación Web estándar (WAR) que permite contener otros componentes

Web, tales como JSPs y Servlets.

En la figura 2.1 se presenta un ejemplo de portlet, el cual permite apreciar una

visión general de los casos en que se invocan los métodos básicos de un portlet. Este portlet

es un portlet del clima para desplegar la temperatura sobre una página de portal.

Figura 2.1. El portlet del clima

El portlet del clima despliega información de temperatura para un código postal

dado. Se permite a los usuarios consultar la temperatura para códigos postales alternativos,


38

como se muestra en la figura 2.2. En dicha figura, se permite a los usuarios personalizar su

código postal y las unidades por omisión para desplegar la temperatura y en este ejemplo, el

portlet recupera la información del clima desde un servicio Web.

El primer método del portlet que se invoca es el método init(). El método init() se

invoca para inicializar el portlet antes de que el portal envíe alguna petición a él.

Figura 2.2. Edición de preferencias

En el método init(), el portlet del clima obtiene la URL del servicio Web del clima

desde un parámetro init e inicializa el objeto de servicio para él. Si el parámetro init está

ausente, o el servicio no puede inicializarse, el método lanza una excepción por

indisponibilidad y el portlet no está disponible para servir solicitudes.

Asumiendo que el portlet se inicializó correctamente, cuando los usuarios van al

portal y tienen el portlet del clima en su página, el método doView() se invoca para

interpretar el contenido del mismo. Este método se invoca cuando el portlet está en modo

view (vista).

Cuando los usuarios dan clic en el botón ―edit‖ de la barra de título del portlet, éste

cambia al modo Edit (edición) e invoca el método doEdit().

Cuando el usuario da clic en el botón ―help‖ sobre la barra de título del portlet, éste

cambia al modo HELP (ayuda) e invoca el método doHelp().


39

2.2.2 Estándar WSRP (Web Services for Remote Portlets, servicios Web para portlets

remotos)

Los servicios Web para portlets remotos (WSRP) son una especificación de OASIS

[34]. La especificación WSRP aborda el problema consistente en que la integración de

contenido y aplicaciones en portales requiere un significativo esfuerzo de programación.

Típicamente, los vendedores de portales u organizaciones que despliegan portales tienen

que escribir adaptadores especiales permitiendo a los portales comunicarse con proveedores

de aplicaciones y contenido adaptándose a una variedad de diferentes interfaces y

protocolos que usan los proveedores. El estándar WSRP de OASIS simplifica la integración

de aplicaciones y contenidos remotos en portales al grado que se permite a los

administradores de portal escoger desde una variedad de contenido y aplicaciones remotas e

integrarlas en su portal con poco esfuerzo de programación.

Las características de WSRP consisten en que: (1) estandariza los servicios Web en

la capa de presentación, (2) se sitúa en la pila de servicios Web existentes, según se muestra

en la figura 2.3, (3) construye sobre los estándares de servicios Web existentes; y (4) apoya

los esfuerzos de estándares de servicios Web adicionales, tal como esfuerzos de seguridad y

como ellos llegan a ser disponibles.

Las interfaces WSRP se definen en documentos WSDL (Web Services Description

Languaje, lenguaje de descripción de servicios Web). Además, WSRP define metadatos

para auto-descripción con el fin de publicar y encontrar servicios WSRP en registros (estos

constituyen un servicio de hospedaje que se ofrece por una compañía de tecnología de red,

por ejemplo Oracle, para registrar servicios WSRP de algún productor). Todos los servicios

WSRP requieren el uso de SOAP (Simple Object Access Protocol, protocolo de acceso de

objeto simple) para la invocación de servicios Web y opcionalmente soportan estándares

adicionales.

En relación a la importancia de la estandarización de los servicios Web en la capa

de presentación que hace WSRP hay que considerar que frecuentemente, el contenido se

obtiene de servicios externos y se despliegan en portlets locales específicos que se ejecutan

sobre el portal. Mientras este enfoque es factible para establecer la base funcional de un


40

portal, no conviene para la integración dinámica de fuentes de información y aplicaciones

de negocios en portales.

De acuerdo a la figura 2.3, WSRP se ajusta en un gran contexto de la pila de

estándares de servicios Web [16]. Para formalmente describir las interfaces de servicios

WSRP se utiliza WSDL; mientras que, para invocar los servicios WSRP puede usarse

SOAP. Además, WSRP se superpone con WSIA (Web Services for Interactive

Applications, servicios Web para aplicaciones interactivas) con quien comparte una base

común de interfaces y definición de protocolos.

Figura 2.3. WSRP y estándares que se relacionan

WSRP define la noción de fragmentos válidos de marcado que se basan en

lenguajes de marcado existentes tales como HTML, XHTML, VoiceXML, cHTML, entre

otros. Para lenguajes de marcado que soportan definiciones de estilos, WSRP también

define un conjunto de nombres estilo estándar permitiendo a los portlets generar el marcado

usando estilos que se proveen por portales manejables WSRP por lo que el marcado se

ajusta a la vista del usuario final del portal consumidor.

Una meta del estándar WSRP es implementar servicios que no solamente proveen

fragmentos de marcado, sino que también permiten servicios más complejos que requieran

(X)HTML WML Voz XML XHTML

Básico

…

WSRP WSIA WSRP/WSIA

Base común

WSDL

(Descripción)

SOAP

(Invocación)


41

registro del consumidor, soportar interacción de usuario compleja que se basa en estados

transitorios y persistentes [16]. Estos son: (1) servicio WSRP simple con vista solamente,

(2) servicios WSRP interactivos con estado conversacional transitorio, (3) servicios WSRP

interactivos con estado de entidad persistente, (4) servicio WSRP interactivo con estado de

entidad y estado de sesión; y (5) servicios WSRP con registro y revocación.

El servicio WSRP más simple posible provee una simple vista, sin alguna

interacción del usuario. Un ejemplo es un calendario o salidas de vuelo de un aeropuerto.

Los servicios WSRP interactivos con estado conversacional transitorio son un caso

más complejo con un servicio WSRP que soporta la interacción del usuario y mantiene el

estado conversacional reflejando la interacción del usuario. Un ejemplo es un servicio de

noticias que provee una descripción general de encabezados de los diferentes artículos de

noticias y permite a los usuarios dar clic sobre los encabezados para navegar al artículo

individual y sobre un vínculo de regreso.

Los servicios WSRP interactivos con estado de entidad persistente, en el mismo

nivel de complejidad del ejemplo anterior, son un servicio WSRP que mantiene un estado

persistente que se asocia con una instancia de portlet individual disponible desde el

productor WSRP. Un ejemplo para tal servicio es un servicio de cotización de acciones que

permite a usuarios individuales definir su portafolio personal. Este caso requiere el

concepto de múltiples entidades persistentes.

En los servicios WSRP interactivos con estado de entidad y estado de sesión, un

productor WSRP más complejo emplea tanto el estado de entidad persistente como el

estado de sesión transitorio. En un cierto tiempo, todas las sesiones WSRP se asocian con

una entidad persistente en un tiempo dado. Por ejemplo, muchas sesiones WSRP para la

misma entidad existen para un consumidor que es un portal con páginas que se comparten y

se usan concurrentemente por múltiples usuarios finales.

En los servicios WSRP con registro y revocación los proveedores de WSRP no

solamente soportan acceso para consumidores anónimos, sino que además, necesitan

implementar operaciones convenientes para registrar y borrar a consumidores.

Estos estándares los soportan determinados ambientes de desarrollo, entre ellos el de

Java Studio Creator que se seleccionó para el desarrollo de esta tesis.


42

2.3. Ambientes de desarrollo con soporte para portlets

2.3.1. Java Sun Studio Creator

Es un ambiente de desarrollo Web visual para la plataforma Java. Se construyen

visualmente aplicaciones Web y portlets que se basan en estándares usando Java Server

Faces a través de una interfaz de usuario de drag and drop (arrastrar y soltar). Se simplifica

la integración con fuentes de datos heterogéneas tales como bases de datos relacionales,

JavaBeans Enterprice, servicios Web y también se incluyen otras características.

Las aplicaciones que se desarrollan con Java Studio Creator se despliegan en

contenedores J2EE estándares incluyendo el servidor de aplicaciones del sistema Java,

BEA WebLogic, IBM WebSphere, Tomcat entre otros [36].

2.3.2 WebLogic Workshop

En WebLogic Workshop, los portlets se editan visualmente en vista de diseño, y los

documentos JSPs se editan en vista de diseño y código fuente [37].

Opcionalmente, el portlet usa una página JSP, una página de flujo, o un archivo de

respaldo, y se construye conforme al estándar JSR 168 para garantizar la compatibilidad del

portlet. Los portlets consumen aplicaciones Web existentes y contenidos tales como:

páginas con tecnología ASP y JSP y documentos digitales de HTML o XML, entre otros

[37].

Se permite usar WebLogic Workshop para construir y mantener portlets remotos

manejables WSRP. WSRP es un estándar de servicio Web que permite ―enchufar y

ejecutar‖ servicios Web que se orientan visualmente al usuario con portales o aplicaciones

Web de otros intermediarios. Permite crear portlets que proveen contenido a otros portlets o

consumen contenido de otras fuentes [37].


43

2.3.3. IBM WebSphere Portlet Factory

IBM WebSphere Portlet Factory es un entorno que se especializa en el desarrollo de

portlets para crear, personalizar, desplegar y mantener con eficacia los portlets que

aprovechan las aplicaciones, bases de datos y otros recursos existentes [38].

WebSphere Portlet Factory permite a los desarrolladores crear rápidamente portlets

mediante la definición de una secuencia de componentes de software, reutilizables y

adaptables, denominados "Builders". Los Builders generan dinámicamente el código de la

aplicación, incluyendo Java Server Pages (JSP), clases Java y documentos XML, así como

todos los objetos de nivel inferior que componen la aplicación de portlet. De este modo, se

permite a los desarrolladores capturar y automatizar el proceso de creación de portlets

dinámicos, en lugar de codificar explícitamente cada portlet. Además, permite a los

desarrolladores crear con rapidez y facilidad varios portlets que se personalizan totalmente

a partir de una base de código, sin necesidad de realizar un nuevo despliegue o efectuar

cambios adicionales en el código [38].

2.3.4. Sun Java Studio Enterprise

Sun desarrolló Sun Java Studio Enterprise, la principal plataforma de desarrollo

empresarial y series de sistemas Java, la cual constituye la infraestructura para desplegar

servicios Web de arquitectura SOA (Service Oriented Architecture, arquitectura orientada a

servicio). Java Studio Enterprise permite desarrollar, depurar, probar y desplegar servicios

Web, y componentes de portal.

Java Studio Enterprise soporta la plataforma J2EE e integra el ambiente de

desarrollo (IDE) NetBeans. Java Studio Enterprise proporciona a través de NetBeans: (1)

modulación para integrarse con el lenguaje de modelado unificado (UML), (2) colaboración

instantánea del desarrollador, (3) un perfilador de aplicación empresarial, (4) constructor de

portlets, (5) kit de verificación de aplicación de Java, entre otros.

El Portlet Builder (constructor de portlets) permite: (1) crear portlets y proveedores

personalizados, (2) probar los canales en un ambiente integrado sin alguna configuración,


44

administración y requerimiento de autorización, (3) desarrollar con el servidor de portal

empresarial de Java Sun, lo cual significa elementos de portal empaquetados, tales como

portlets manejables JSR 168 de la petición de especificación Java, proveedores y canales; y

(4) crear, probar y empaquetar elementos de portal en el constructor de portlets, el cual se

permite desplegar sobre un servidor de portal local [39].

2.3.5. Borland JBuilder 2005 y la edición de desarrollo de Borland del portal de

aplicación Vignette

Borland y Vignette establecieron una solución combinada para ayudar a las

organizaciones a acelerar la creación de portlets con funcionalidad que se personaliza,

mejorando el diseño y calidad de las interfaces Web y consolidación de administración de

portlets funcionalmente dispares a través de la empresa.

La solución consiste en la creación de un portlet que se ―enchufa‖ en Borland

JBuilder 2005 y la edición de desarrollo de Borland del portal de aplicación Vignette. Esta

solución se diseñó para crear portlets que se personalizan y se basan sobre el estándar JSR

168 de Java proporcionando características de seguridad inherentes en el ambiente J2EE,

tiempo de desarrollo breve e incremento de la escalabilidad y el desempeño para

aplicaciones empresariales.

JBuilder 2005 y la edición de desarrollo de Borland de portal de aplicación Vignette

permite a los clientes mejorar la velocidad con la cual se desarrollan y despliegan portlets

de Java que se basan en estándares. Estos portlets tienen la opción de tomar ventaja de la

integración de servicios Web y de desplegarse para guiar servidores de aplicaciones J2EE

[40].

2.3.6. OracleAS Portal

OracleAS Portal es una aplicación Web que se utiliza para crear y desplegar

portales. Proporciona un entorno seguro y manejable para acceder e interactuar con


45

servicios de software de empresa y recursos informativos. Sus funciones clave son: (1) un

marco extensible que integra recursos que se basan en Web, 2) una interfaz que se

personaliza; y (3) funciones de publicación en autoservicio [41].

El marco extensible como páginas Web, aplicaciones, informes de inteligencia de

negocio y contenido de mediación dentro de componentes de información estándar

reutilizables se denominan portlets. Dentro de un portlet, estos recursos se personalizan y

gestionan como un servicio de OracleAS Portal. Se permite a las empresas crear sus

propios portlets para sus recursos Web y seleccionar portlets adicionales del catálogo cada

vez mayor de otros fabricantes proveedores de portlets. El marco del portal ofrece servicios

adicionales, como la conexión única, la clasificación de contenido, la búsqueda de empresa,

la integración de directorios y el control de acceso.

Finalmente, proporciona funciones de publicación en autoservicio que permiten a

los usuarios enviar y compartir cualquier tipo de documento o contenido Web con otros

usuarios [41].

2.4 Resumen

Los portlets son componentes Web que se basan en Java, que se gestionan por un

contenedor de portlets que procesa peticiones y genera contenido dinámico. Los portales

usan portlets como componentes de interfaz de usuario que proveen de una capa de

presentación a los sistemas de información. Los portlets son locales o remotos al portal

servidor.

Los portlets se basan en las especificaciones JSR 168 y WSRP. Estas

especificaciones son complementarias y actualmente tienden a adoptarse por proveedores y

consumidores de servicios Web gracias a estas ventajas: (1) JSR 168 define un API de

portlet estándar que es específico para portales que se basan en Java; y (2) WSRP define un

API universal que permite a los portales de cualquier tipo consumir portlets de cualquier

tipo.

Para el desarrollo de los portlets existen diversas IDEs, ejemplos de estas son: (1)

Java Sun Studio Creator, (2) IDE de WebLogic Workshop, (3) IBM WebSphere Portlet


46

Factory, (4) Sun Java Studio Enterprise, (5) Borland JBuilder 2005 y la edición de

desarrollo de Borland del portal de aplicación Vignette; y (6) OracleAS Portal.


47

Capítulo 3. Componentes de la arquitectura del portal

empresarial

3.1. Introducción

Los portlets son componentes que permiten encapsular servicios Web y presentarlos

a los usuarios. Los portales de segunda generación se integran por portlets. Los portlets y

los servicios Web (servicios que se ofrecen mediante la Web, normalmente lo utilizan las

empresas) permiten integrar aplicaciones heterogéneas o fuentes de datos de una manera

consistente. Ambos proveen comunicación intra e inter-organizacional y un marco de

trabajo, que no obstante sus beneficios, requieren de una arquitectura que los integre

satisfactoriamente en un portal.

Las arquitecturas para portal producen beneficios potenciales a las empresas. Estos

son cuantitativos y cualitativos, y se reflejan, por ejemplo, en una mejor capacidad de

integración y en una reducción de costos de introducción para portales.

En este capítulo, se presentan los componentes de la arquitectura de portal

empresarial que aporta esta tesis.

3.2. Componentes de la arquitectura del portal empresarial

El portal que esta tesis presenta se enfoca hacia la industria del entretenimiento, por

lo que se ofrecen servicios Web de esta naturaleza. El portal presenta dos modos de

operación: el modo portal de Internet y el modo Proxy. El aspecto general de la arquitectura

se muestra en la figura 3.1.


48

Figura 3.1. Aspecto general de la arquitectura

Los servicios Web que ofrece el portal son los que se describen en la tabla 3.1. El nombre

de éstos se refiere a su denominación en el sitio de Internet xmethods.net. Este sitio

presenta una lista de servicios Web públicamente disponibles.

Nombre del servicio Web Descripción

Ignyte's Retrieve Theaters and

Movie Showtimes.

Las películas que ofrecen los

cines para un determinado código

postal (USA).

USA Weather Forecast. La previsión del clima para un

determinado código postal o

ciudad (USA).

Horoscope web Services El horóscopo diario.

AmazonBox Búsqueda de productos en

Amazón.com.

Tabla 3.1. Descripción de los servicios Web del portal.

En el modo portal de Internet, a través de un navegador el cliente accede al portal,

en donde cada portlet ofrece un determinado servicio Web de entretenimiento. En el modo

Proxy se ofrece a los clientes un servicio de intermediario para determinados servicios

Web. En las siguientes secciones se describen, con más detalles, ambos modos.


49

3.2.1 Modo portal de Internet

El portal empresarial, en su modo portal de Internet consta de determinados

componentes. Estos son: (1) el portal empresarial que se constituye por portlets, (2) el

contenedor de portlets; y (3) los proveedores de servicios Web. Además, existen entidades

externas al portal, estos son los clientes y los proveedores de servicios Web. Esto se ilustra

en la figura 3.2.

Figura 3.2. Portal empresarial en su modo portal de Internet

El portal recibe los portlets de un componente interno, que se denomina contenedor

de portlets. Este controla el ciclo de vida de los portlets y provee recursos e información

acerca de su ambiente. Estos portlets se despliegan, ordenadamente, en la página de portal

que se muestra al cliente.

El cliente, a través del navegador de su equipo de cómputo accede al portal en su

modo portal de Internet. Lo consulta, selecciona y solicita el consumo de un determinado

servicio Web que le presenta un determinado portlet. Ante ello, el portlet invoca al

correspondiente proveedor externo de dicho servicio. El proveedor externo recibe la

solicitud, la procesa, y envía la respuesta al portlet invocador. Este la presenta al cliente.


50

3.2.2. Modo Proxy del portal.

Los portlets y los servicios Web tienen una estrecha relación para el portal, tanto en

su modo Proxy como en su modo portal de Internet. A causa de la importancia de los

servicios Web, primeramente se describe brevemente su marco teórico y relación con los

portlets. Con este conocimiento, se presenta la arquitectura del portal en su modo Proxy.

Para lo cual, se describe el desempeño individual e integral de sus componentes.

3.2.2.1. Relación entre servicios Web y portlets.

Con el fin de ofertar sus servicios a través de la Web, normalmente las empresas

utilizan los servicios Web. Existen empresas que son proveedoras y/o consumidoras de

estos. [42].

Un servicio Web es una clase cuya interfaz se hace pública en un servidor Web

mediante un lenguaje de descripción de interfaces (WSDL). Dicha interfaz ofrece un

conjunto de actividades que un cliente invoca. El cliente accede al servicio Web usando los

estándares de Internet [42], por ejemplo, HTTP.

Para acceder a un servicio Web se utilizan, opcionalmente, varios protocolos Web

estándar como HTTP GET o HTTP POST. Aunque se diseñó un protocolo específico para

ello: SOAP (Simple Object Access Protocol, Protocolo de acceso de objeto simple). Este

protocolo se basa en la utilización de HTTP para el transporte de mensajes y el lenguaje

XML para escribir el cuerpo de estos mensajes. Todo lo anterior permite a cualquier

aplicación generar e interpretar mensajes SOAP independientemente de la plataforma [42].

De tal forma que, los servicios Web, a través de sus protocolos y estándares: SOAP,

WSDL (Web Services Description Language, lenguaje de descripción de servicios Web) y,

también, UDDI (Universal Description, Discovery, and Integration, descripción,

descubrimiento, e integración universales), proveen un marco de trabajo inter-

organizacional. En síntesis, SOAP, WSDL y UDDI tienen funciones específicas que

ofrecen a los servicios Web: (1) SOAP para comunicarlos, (2) WSDL como un lenguaje de

descripción de interfaces; y (3) UDDI como un registro de especificaciones [43]. La

arquitectura del portal, en su modo Proxy, trabaja con los dos primeros.


51

La relación entre los portlets y los servicios Web consiste en que en contraste a los

portlets implementados localmente, los servicios Web representan portlets inter-

organizacionales. Sin embargo, los servicios Web no incorporan funciones de integración

de presentación, las cuales son pertinentes a los portlets. En consecuencia, los servicios

Web orientados a presentación representan portlets remotos. Esto se da a través de la

inclusión de fragmentos de presentación que ya se estandarizaron para asegurar un aspecto

uniforme en el portal. De hecho, el estándar WSRP, para portlets remotos, trabaja en este

sentido [21].

En relación al modo Proxy de la arquitectura de portal, ésta se ilustra en la figura

3.3.

Figura 3.3. Arquitectura del portal en modo Proxy

Para dicho modo, el cliente desarrolla una aplicación para consumir el servicio Web

que el portal le ofrece intermediariamente. En este caso, la intermediación tiene la ventaja

de otorgarle al cliente información con el formato de respuesta que se determinó como más


52

conveniente a sus necesidades. El cliente, de antemano, conoce dicho formato de respuesta

a través del documento WSDL que el portal, previamente, le proporcionó.

La aplicación que el cliente desarrolle, para el documento WSDL que tomó del

portal, le permitirá consumir el servicio Web del portal en modo Proxy.

3.2.2.2. Descripción de los componentes.

Tal como lo muestra la figura 3.3 los componentes de portal son los siguientes: (1)

el analizador de mensajes SOAP, (2) el selector de servicio, (3) el contenedor de portlets,

(4) el invocador, (5) el analizador de respuestas; y (6) el constructor de respuestas. Los

cuales se describen en esta sección.

Como sus nombres lo indican, el cliente y proveedor externo representan entidades

externas a la arquitectura del portal.

Figura 3.4. Documento WSDL del servicio Web ―Horoscope web Services‖, para los

clientes del portal en su modo Proxy.

<wsdl:message name="MessageRequest"> </wsdl:message>

…

<wsdl:message name="MessageResponse">

<wsdl:part name="Respuesta" type="xsd1:String"/>

</wsdl:message>

…

<wsdl:portType name="horoscopoPortType">

<wsdl:input message="tns:MessageRequest"/>

<wsdl:output message="tns:MessageResponse"/>

</wsdl:portType>

…

<wsdl:service name="horoscopo">


53

3.2.2.2.1. El analizador de mensajes SOAP

Para su modo Proxy, el portal proporciona un documento WSDL al cliente. El

analizador de mensajes SOAP trabaja basándose en dicho documento. La finalidad del

analizador de mensajes SOAP es establecer la comunicación entre la aplicación del cliente

y el portal en su modo Proxy. Y con ello, atender la solicitud del método invocador de la

aplicación del cliente.

Para ello, analiza dicho documento WSDL con la finalidad de determinar el método

invocador y sus argumentos. Así, el analizador de mensajes SOAP centra su atención en la

etiqueta ―<wsdl:input message …‖ que pertenece a la etiqueta ―<wsdl:portType…‖.

En el ejemplo, que se muestra en la figura 3.4, el analizador de mensajes SOAP

determina que el método invocador, que se asignó para la aplicación del cliente, se llama

―MessageRequest‖ y no requiere argumento alguno.

3.2.2.2.2. El selector de servicio

Determina qué portlet implementa la funcionalidad que se demanda en la

comunicación que estableció el analizador de mensajes SOAP. Para ello, centra su atención

en el valor de ―name‖ de la etiqueta ―service‖.

En el ejemplo de la figura 3.4 la etiqueta ―service‖ presenta este contenido:

―<wsdl:service name=’horoscopo’>‖. De tal forma que el portlet que interesa es del

―horóscopo‖.

3.2.2.2.3. El contenedor de portlets

El contenedor de portlets proporciona un entorno de ejecución para los portlets. El

contenedor de portlets permite crear instancias de portlets y provee de medios para manejar

a éstos. Para los portales que se basan en Java este componente se basa en el estándar JSR

168. Éste estándar se concreta en Apache Pluto [44].


54

3.2.2.2.4. El invocador.

El proveedor externo del servicio Web proporcionó un documento WSDL para el

portal en su modo Proxy. El invocador trabaja basándose en dicho documento. La finalidad

del invocador es establecer comunicación, del portal, con el servicio Web del proveedor

externo. Por ello, emplea el método correspondiente con sus respectivos argumentos, si los

tiene.

Así, el invocador centra su atención en la etiqueta ―<input message …‖ que, a su

vez, pertenece a la etiqueta ―<portType…‖ del documento WSDL.

En el ejemplo de la figura 3.5, el invocador determina que el método de invocación

se llama ―GetHoroscope‖ y éste no requiere argumento alguno.

3.2.2.2.5. El analizador de respuesta

Este trabaja basándose en el documento WSDL que proporcionó el proveedor

externo del servicio Web al portal en su modo Proxy. Una vez que se invoque dicho

servicio Web, su finalidad es recoger la información de respuesta neta. Es decir, a la

información de respuesta se le extraen datos que ya no interesan, relativos al uso de los

estándares de servicios Web.

Por ello, el analizador de respuesta centra su atención en la etiqueta ―<output

message…‖ que, a su vez, pertenece a la etiqueta ―<portType…‖.

Para el ejemplo que se muestra en la figura 3.5, el analizador de respuesta determina

que el nombre del método, que el proveedor externo emplea para dar su respuesta, se llama

―GetHoroscopeResponse‖ y la respuesta es un dato de tipo String.


55

Figura 3.5. Documento WSDL del servicio Web ―Horoscope web Services‖, del proveedor

externo del servicio para el portal en su modo Proxy.

<message name="GetHoroscopeSoapIn">

<part name="parameters" element="s0:GetHoroscope" />

</message>

…

<s:element name = "GetHoroscope">

<s:complexType />

</s:element>

…

<message name="GetHoroscopeSoapOut">

<part name="parameters" element="s0:GetHoroscopeResponse" />

</message>

…

<s:element name="GetHoroscopeResponse">

<s:complexType>

<s:sequence>

<s:element minOccurs="0" maxOccurs="1" name="GetHoroscopeResult"

type="String " />

</s:sequence>

</s:complexType>

</s:element>

…

<portType name="HoroscopeSoap">

<operation name="GetHoroscope">

<input message="s0:GetHoroscopeSoapIn" />

<output message="s0:GetHoroscopeSoapOut" />

</operation>

</portType>


56

3.2.2.2.6. El constructor de respuestas

Este envía la información de respuesta al cliente. Es decir, debe responder a la

aplicación del cliente para el portal, en su modo Proxy, conforme al servicio Web que

demandó. Para ello: (1) formatea el dato o datos que se requieren como respuesta, (2) crea

un mensaje SOAP; y (3) envía la respuesta al cliente a través del mensaje SOAP que creó.

Con esta finalidad, centra su atención en la etiqueta ―<wsdl:output …‖ que, a su

vez, pertenece a la etiqueta ―<wsdl:portType …‖.

En el ejemplo que se muestra en la figura 3.4, el constructor de respuesta determina

que el método de respuesta al cliente se llama ―MessageResponse‖ y debe regresar un dato

de tipo String.

3.2.2.3. Funcionamiento de la arquitectura.

La forma de operar de los componentes de portal para satisfacer la meta del portal

en su modo Proxy es la siguiente:

Paso 1. A través de un mensaje SOAP la aplicación del cliente envía la solicitud.

Esta se recibe por el analizador de mensaje SOAP del portal en modo Proxy. Cuya finalidad

es comunicar los objetos que se están ejecutando en ambas partes.

Paso 2. Una vez que se establece la comunicación interviene el selector de servicio,

el cual analiza los parámetros de solicitud para determinar que portlet es el que implementa

la funcionalidad que se requiere y lo busca en el contenedor de portlets.

Paso 3. El contenedor de portlets provee el portlet correspondiente.

Paso 4. El portlet hace uso del invocador. El cual, a través de un mensaje SOAP,

envía la petición de servicio al proveedor externo de servicio Web.

Paso 5. Dicho proveedor recibe la solicitud, la procesa y a través de un mensaje

SOAP envía la respuesta al portal.

Paso 6. Esta respuesta la recibe el analizador de respuesta, que análogamente al

analizador de mensaje, primeramente, requiere establecer la comunicación entre el

proveedor y el portal en modo Proxy, y cuya función principal es extraer los elementos de


57

respuesta que interesan, es decir, la información. Esta se pone a disposición del constructor

de respuesta.

Paso 7. El constructor de respuesta procede a darle el formato que se especificó al

cliente en el documento WSDL. A continuación, envía la información de respuesta a la

aplicación del cliente a través de un mensaje SOAP.

3.3. Resumen

Los portlets y los servicios Web son compatibles, ya que ambos comparten una base

común de estándares y protocolos, los cuales son de aceptación creciente entre proveedores

de contenidos y aplicaciones. Lo que permite apoyar a los portales como intermediarios

múltiples. Esencialmente, la diferencia entre los servicios Web y los portlets consiste en

que estos últimos agregan la capa de presentación a través de fragmento de marcado,

generalmente HTML. Ya que éste, es un estándar que se consolidó para los navegadores de

Internet.

En este capítulo se presentaron los componentes de la arquitectura del portal para

los dos modos de operación: modo portal de Internet y modo Proxy. Se presentó que para

ambos modos, los clientes y los proveedores de servicios son elementos externos. Además,

se observó que un elemento común para ambos modos es el contenedor de portlets, el cual

se encarga de gestionar el ciclo de vida de los portlets. En relación al modo Proxy, se

presentaron sus componentes: (1) analizador de mensajes SOAP, (2) selector de servicio,

(3) contenedor de portlets, (4) invocador, (5) analizador de respuestas; y (6) constructor de

respuestas.

Durante el la discusión de los componentes del portal, se observó que los

documentos WSDL son los contratos que especifican la forma de acceso de los clientes a

los servicios Web. En consecuencia, el portal para su modo Proxy entregó, a sus clientes,

los documentos WSDL que permiten a dichos clientes desarrollar las aplicaciones Web

respectivas. Mientras que el portal accede a los servicios Web, que requiere para sus modos

de operación, a través de los documentos WSDL que los proveedores externos entregaron

para este objetivo.


58

Capítulo 4. Prestaciones de servicios del portal empresarial

4.1. Introducción

En este capítulo se describen los servicios que proporciona el portal en sus modos

portal de Internet y Proxy. Además, se presentan las tecnologías que permitieron el

desarrollo de ambos modos y se presentan las capas de prestaciones de servicios de la

arquitectura del portal que aporta esta tesis.

Para el modo portal de Internet, el cliente, a manera de usuario final, dispone de un

menú de opciones para acceder a los portlets del portal. Por otra parte, para el modo Proxy

del portal se presenta la API que permite consumir los servicios de este modo.

Finalmente, se describen las capas de prestación de servicios, las cuales son seis: (1)

presentación, (2) comunicación, (3) descubrimiento, (4) servicio, (5) lógica; e (6)

integración.

4.2. Modo portal de Internet

4.2.1. Interfaz gráfica del modo portal de Internet

En el modo portal de Internet, el cliente accede al portal a través de su navegador de

Internet. Una vez que el cliente realiza lo anterior, el portal presenta un menú de opciones

donde el cliente selecciona ya sea un determinado portlet o a todos ellos para mostrarse en

el portal.

El menú de opciones del portal consta de lo siguiente: (1) Portlet AmazonBox, (2)

Portlet USAWeather, (3) Portlet Horoscope, (4) Portlet Theaters, (5) Portlet

TheatersAndWeather; y (6) All portlets. Como su nombre lo indica, la opción que se

denomina ―All portlets‖ presenta a todos los portlets en el portal, como se ilustra en la

figura 4.1. Mientras que cualquiera de las otras opciones se restringe a presentar sólo al

portlet correspondiente a la opción.


59

Figura 4.1. El modo portal de Internet con la opción activa ―All Portlets‖.

4.2.2. Tecnología de desarrollo para el modo portal de Internet

El portal se desarrolló con tecnología JSP que se complementa con lenguaje de

marcado HTML y requiere del contenedor de portlets. El portal se ejecuta en un servidor

con tecnología TomCat. Se opta por esta tecnología por las siguientes razones: (1) consume

pocos recursos del sistema en lo referente a memoria RAM, esto hace ágil al portal; y (2)

es open source. Emplear recursos con esta última característica es uno de los objetivos de

esta tesis. Por otra parte, TomCat realiza el soporte para portlets a través del compilador

que se denomina Jasper, que compila JSPs convirtiéndolas en servlets. (en términos

generales, los portlets son JSPs). Además, a causa de que Tomcat se programó en lenguaje

Java, funciona en cualquier sistema operativo que disponga de la máquina virtual Java[45].

4.2.3. Métodos del contenedor de portlets para el modo portal de Internet

La representación en UML del contenedor de portlets se muestra en la figura 4.2 A,

4.2 B y 42 C. Por otra parte, el empleo de los métodos del contenedor de portlets hacen


60

posible las formas de operación de los portlets. La utilización, por parte del usuario, de

dichas formas: minimizar, maximizar, normalizar, cerrar, modo edit y modo view se

informa a los respectivos métodos del contenedor de portlets. La tecnología JSP auxilia en

esta labor.

El contenedor de portlets controla el ciclo de vida de los portlets a través de

determinados métodos. Estos métodos se presentan y describen más abajo. El contenedor

de portlets se desarrolló en lenguaje Java y durante la invocación de sus métodos se apoya

de tecnología Java Server Pages. Debido a esto último, en la invocación de los métodos del

contenedor se observa el auxilio de instrucciones de dicha tecnología. Ello es necesario,

porque los métodos del contenedor de portlets requieren argumentos que recaban

información que procede de la capa de presentación, es decir, HTML. A través de HTML

se recaba información que se genera en las peticiones del usuario, cuando el usuario utiliza

las formas de operación del portlet.

En la práctica, el empleo de los métodos del contenedor de portlets requiere del

apoyo de una estructura condicional if-else. Se requiere la parte if para cubrir la acción de

concretar al objeto contenedor de portlets y a los portlets que éste hospeda. Entonces, la

parte if se ejecuta únicamente en la primera ocasión en que el usuario accede al portal, y en

las siguientes ocasiones se ejecuta la parte else. En esta parte else se recaba información

que se genera de la interacción de los usuarios con los portlets. En dicha parte, se

encuentran los métodos del contenedor de portlets que obtienen información actual del

estado de los portlets, lo cual es necesario al contenedor de portlets. Lo anterior ocurre cada

vez que el usuario utiliza las formas de operación del portlet y en consecuencia, re-invoca

la página del portal para el envío de información HTML. Finalmente, se coloca fuera tanto

de la parte if como de la parte else, a los métodos que proveen de fragmento de marcado

HTML a través de un dato de tipo String, el cual representa a los portlets para el usuario

final. Se ejemplifica el empleo de los métodos necesarios para un portlet en figura 4.3.

A continuación se presentan los métodos del contenedor de portlets en la secuencia

que se requiere y con una breve descripción de su funcionalidad.


61

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


62

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


63

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

ContenedorPortletsERD obj = new ContenedorPortletsERD("portal.jsp").- Se

emplea la clase ContenedorPortletsERD para crear un objeto de tipo contenedor de

portlets. Se requiere como argumento el nombre de la página JSP que hospeda al

portal en su modo portal de Internet.

obj.creaUnPortlet("AmazonBox","http://localhost:8080/AmazonBox", -

"myForm");.- Permite crear un portlet. Requiere como primer argumento el nombre

del portlet que se desea asignar, como segundo argumento la dirección del portlet en

su forma de archivo war y como tercer argumento el nombre del formulario que

emplea el portlet.

obj.setDimensionesdePortlet ("AmazonBox", "300", "500").- Establece las

dimensiones del portlet. El primer argumento se refiere al nombre del portlet y los

dos últimos argumentos se refieren al alto y ancho del portlet, respectivamente.

session.setAttribute("ProducePortlets", obj).- instrucción de tecnología JSP para

hospedar, en una variable de sesión, al objeto contenedor de portlets. El primer

argumento se refiere al nombre que se asigna a la variable de sesión que se crea, y el

segundo argumento es el objeto que se almacena en la variable de sesión.

ContenedorPortletsERD obj = (ContenedorPortletsERD)

session.getAttribute("ProducePortlets").- Igual que el caso inmediato anterior, se

trata de una instrucción de tecnología JSP. Solo que ahora con la finalidad de


64

recuperar al objeto contenedor de portlets que antes se almacenó en una variable de

sesión.

obj.setURL("AmazonBox", request.getParameter(obj.getArgumento("Amazon -

Box"))).- Tiene como finalidad informar al contenedor acerca de la URL actual de

un portlet determinado. Recibe como primer argumento el nombre del portlet, y el

segundo argumento se construye con apoyo de tecnología JSP. Para la construcción

del segundo argumento, la instrucción de tecnología JSP requiere, además, del

apoyo de un método que se denomina getArgumento, donde éste último requiere el

nombre del portlet.

obj.setEdosPortlets("AmazonBox",request.getParameterValues("AmazonBox")).

Informa al contenedor del portlets si el portlet en cuestión está minimizado,

normalizado, maximizado o cerrado. Requiere como primer argumento el nombre

del portlet, y para construir el segundo argumento requiere del apoyo de tecnología

JSP, donde ésta última requiere a su vez del nombre del portlet.

obj.setPropiedades(request.getParameterValues("ArgumentoEDIT")).- Informa al

contenedor si un portlet cualquiera ingresó al modo edit, y de ser así, recaba datos

tales como el nombre del portlet, el nuevo valor de alto, ancho y nueva URL.

Construye su argumento con apoyo de tecnología JSP, la cual a su vez requiere de la

expresión constante que se denomina "ArgumentoEDIT".

obj.setRestauraUnPortlet(request.getParameter("PortletSeleccionado")).- Informa

al contenedor de portlets, para un portlet que antes se cerró, que ahora el portlet se

restaura. Requiere construir su argumento con apoyo de tecnología JSP, la cual a su

vez, emplea una expresión constante que se denomina "PortletSeleccionado".

session.setAttribute("ProducePortlets", obj).- Después de que el contenedor de

portlets recibió información actual sobre los estados de los portlets, nuevamente,

requiere hospedarse en una variable de sesión JSP.

String[] ArgumentoEDIT = request.getParameterValues("ArgumentoEDIT").- El

arreglo de datos de tipo String que se denomina ArgumentoEDIT, recaba el nombre

del portlet que entró al modo de edición y los datos que se actualizan en este modo.

Para ello requiere de la instrucción

request.getParameterValues("ArgumentoEDIT"). Esta instrucción sólo puede


65

trabajar para un portlet a la vez, es decir, en un momento determinado, corresponde

sólo a un portlet ingresar al modo edit.

obj.setConservarValoresdeControlesHTML("AmazonBox", -

request.getParameter(obj.getArgumentoControlesHTML("AmazonBox"))); Este

método es necesario para conservar los datos de los controles del portlet, cuando

éste se minimiza, normaliza o maximiza. Necesita como primer argumento el

nombre del portlet y el segundo argumento se construye con apoyo de una

instrucción de tecnología JSP, la que a su vez, requiere del apoyo del método

getArgumentoControlesHTML que requiere como argumento el nombre del portlet.

ContenedorPortletsERD obj3 = (ContenedorPortletsERD)

session.getAttribute("ProducePortlets").- Se recupera el objeto contenedor de

portlets, desde un variable de sesión en la cual se almacenó previamente.

String ElementoForm = obj3.getElementoForm().-La variable de tipo String que se

denomina ElementoForm recaba un elemento propio de tecnología HTML

estrictamente necesario para el portal. Este elemento consiste de una etiqueta

“<form …”. Una vez que se consigue, es el primer elemento que necesariamente

requiere imprimirse en el portal.

String miopcionRecuperar = obj3.getOpcionRestaurarPortlet().- Permite obtener la

opción de restaurar a un portlet que previamente se cerró. Una vez que se obtiene la

variable que retorna este método, se procede a imprimir en el lugar que se considere

más conveniente.

String PortletAmazonBox = obj3.getUnPortlet("AmazonBox").- Obtiene el portlet

que se indica como argumento de este método. Luego, igual que en el caso

inmediato anterior, no existe restricción en relación al lugar que se elija para su

impresión.

66

if (session.getAttribute("ProducePortlets")==null)

{

ContenedorPortletsERD obj = new ContenedorPortletsERD("portal.jsp");

obj.creaUnPortlet("AmazonBox", "http://localhost:8080/AmazonBox", "myForm");

obj.setDimensionesdePortlet ("Theaters", "300", "500");

session.setAttribute("ProducePortlets", obj);

}

else

{

ContenedorPortletsERD obj = (ContenedorPortletsERD) -

session.getAttribute("ProducePortlets");

obj.setURL("AmazonBox", -

request.getParameter(obj.getArgumento("AmazonBox")));

obj.setEdosPortlets("AmazonBox",request.getParameterValues("AmazonBox"));

obj.setPropiedades(request.getParameterValues("ArgumentoEDIT"));

obj.setRestauraUnPortlet(request.getParameter("PortletSeleccionado"));

session.setAttribute("ProducePortlets", obj);

String ArgumentoEDIT[];

ArgumentoEDIT = request.getParameterValues("ArgumentoEDIT");

obj.setConservarValoresdeControlesHTML("AmazonBox", -

request.getParameter(obj.getArgumentoControlesHTML("AmazonBox")));

}

session.setMaxInactiveInterval(86400);

ContenedorPortletsERD obj3 =

(ContenedorPortletsERD)session.getAttribute("ProducePortlets");

String ElementoForm = obj3.getElementoForm();

String PortletAmazonBox = obj3.getUnPortlet("AmazonBox");

String miopcionRecuperar = obj3.getOpcionRestaurarPortlet();

%><%= ElementoForm%> 

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


67

4.3. Modo Proxy

Para que el portal ofrezca sus servicios de intermediación o servicio Proxy para

servicios Web de entretenimiento, requiere de una API. Una API (Application

Programming Interface, Interfaz de Programación de Aplicaciones) define los métodos a

través de los cuales un programador accede y controla un sistema determinado [46]. La

API del modo Proxy presenta los métodos que permiten otorgar los siguientes servicios de

entretenimiento: (1) AmazonBox, para buscar productos en la tienda virtual de

Amazon.com, (2) Horoscope web Services, proporciona el horóscopo de los doce signos

zodiacales, (3) Ignyte's Retrieve Theaters and Movie Showtimes, para la programación de

cines de un determinado lugar de los Estados Unidos de América; y (4) USA Weather

Forecast, para obtener la predicción del clima dado un código postal o lugar de los Estados

Unidos de América.

Como se muestra en la figura 4.4, la API Proxy se constituye de un paquete que se

denomina www.webservices. Este paquete contiene las clases: (1) AmazonBox, (2)

Horoscope, (3) Theaters; y (4) USAWeather. Dichas clases proveen, respectivamente, los

servicios de entretenimiento que se indican en el párrafo inmediato anterior.

En las secciones siguientes se presenta una visión general de la funcionalidad de los

documentos WSDL que se entregan a los clientes para que éstos desarrollen las

aplicaciones Web para consumo de los servicios Proxy y se muestran ejemplos de la

invocación y ejecución de estos servicios.


68

Figura 4.4. Representación en UML de la API del portal para su modo Proxy

4.3.1. Servicio Proxy AmazonBox

El servicio Proxy de AmazonBox consiste en ofrecer intermediariamente el servicio

Web de AmazonBox. Este servicio, como ya se describió anteriormente, permite buscar

productos en Amazon.com en treinta líneas diferentes de estos.

Este servicio consta de treinta métodos. La descripción de estos métodos se presenta

en la tabla 4.1. Cada método busca un tipo determinado de producto. En la figura 4.5 se

presenta una ejemplificación, en caja negra, del funcionamiento general del documento

WSDL para los clientes del servicio Proxy AmazonBox.


69

Método Producto a buscar

Por el método public String bookBox(String Keyword) Libros

public String babyBox(String Keyword) Para bebés

public String classicalMusicBox(String Keyword) De música clásica

public String dvdBox(String Keyword) DVD

public String electronicsBox(String Keyword) Electrónicos

public String gardenAndOutdoorLivingBox(String

Keyword)

Jardín y casa al aíre libre

public String kitchenAndHousewaresBox(String

Keyword)

Cocina y mercancías de la casa

public String magazinesBox(String Keyword) Revistas

public String popularMusicBox(String Keyword) Música popular

public String computerHardwareBox(String Keyword) Hardware de computadora

public String cameraAndPhotoBox(String Keyword) Cámara y fotos

public String computerSoftwareBox(String Keyword) Software de computadora

public String toysAndGamesBox(String Keyword) Juguetes y juegos

public String toolsAndHardwareBox(String Keyword) Herramientas y hardware

public String videoBox(String Keyword) Videos

public String computerAndVideoGamesBox(String

Keyword)

Computadora y video juegos

public String authorBox(String Keyword) Por autor

public String musicianPopularMusicBox(String

Keyword)

Música popular por músico

public String musicianClassicalMusicBox(String

Keyword)

Música clásica por músico

public String actorDvdBox(String Keyword) Por actor en DVD

public String actorVideoBox(String Keyword) Por actor en video

public String directorDvdBox(String Keyword) Por director en DVD

public String directorVideoBox(String Keyword) Por director en video

public String manufacturerElectronicsBox(String

Keyword)

Electrónicos por fabricante

public String

manufacturerKitchenAndHousewaresBox(String

Keyword)

Cocina y mercancías de la casa por

fabricante

public String

manufacturerComputerAndVideoGamesBox(String

Keyword)

Computadora y video juegos por

fabricante

public String

manufacturerComputerSoftwareBox(String Keyword)

Software de computadora por

fabricante

public String

manufacturerCameraAndPhotoBox(String Keyword)

Cámara y fotos por fabricante

public String

manufacturerComputerHardwareBox(String Keyword)

Hardware de computadora por

fabricante

public String similaritiesBox(String Keyword) Similares

Tabla 4.1. Métodos del servicio Proxy AmazonBox


70

Para cada método, se requiere proporcionar una palabra clave relacionada al tipo de

producto que se desea. Por otra parte, todos los métodos retornan la respuesta en un dato de

tipo String.

En consecuencia, el documento WSDL establece que los métodos del servicio

requieren como argumento de invocación una palabra clave relacionada al tipo de producto

a buscar. Por ello, para el argumento de invocación de cada método se tiene treinta

elementos diferentes cuyos nombres terminan con la palabra Keyword, todos de tipo String.

Estos almacenan la palabra clave del producto a buscar. Además, se establece que los

métodos tienen, para el retorno de la respuesta al cliente, un elemento que se denomina

―Response‖ de tipo String.

En la figura 4.6 se presenta un ejemplo de la invocación de un método de este

servicio Proxy. Dicho método se denomina ―getBook‖ y se usó la palabra clave ―Java‖. En

la figura 4.7 se presenta la ejecución de éste método.

Figura 4.5. Ejemplificación, en caja negra, del empleo de los métodos del documento

WSDL para el servicio Proxy AmazonBox

Métodos de

AmazonBox String KeyWord String Response

…

…

n

…

…

n

Clases en Java


71

Figura 4.6. Ejemplo de invocación de un método, el método getBook, del servicio Proxy

AmazonBox.

Figura 4.7. Ejemplo de ejecución de un método, el método getBook,

del servicio Proxy AmazonBox.


72

4.3.2. Servicio Proxy Horoscope

El servicio Proxy Horoscope consiste en ofrecer intermediariamente el servicio Web

del mismo nombre. Este servicio, como ya se describió anteriormente, permite obtener la

predicción del horóscopo para los doce signos zodiacales.

En la figura 4.8 presenta una ejemplificación, en caja negra, del funcionamiento

general del documento WSDL del servicio Proxy Horoscope. Este servicio consta de un

único método y para su invocación no se requiere proporcionar argumento alguno. En el

documento WSDL se establece que el método del servicio regresa una respuesta de tipo

String. Para este objetivo se establece un elemento que se denomina ―Response‖ de tipo

String.

En la figura 4.9 se presenta un ejemplo de la invocación del método del modo Proxy

Horoscope. Para ello se ejecuta el método denominado getHoroscope sin argumento

alguno. En la figura 4.10 se presenta la ejecución de dicho método.

Figura 4.8. Ejemplificación, en caja negra, del empleo del método getHoroscope

del documento WSDL para el servicio Proxy Horoscope

Figura 4.9. Ejemplo de invocación del método del servicio Proxy Horoscope que se

denomina getHoroscope.

Método de la clase

Horoscope:

getHoroscope()

String Response


73

Figura 4.10. Ejemplo de ejecución del método del servicio Proxy Horoscope que se

denomina getHoroscope.

4.3.3. Servicio Proxy Theaters

El servicio Proxy Theaters consiste en ofrecer intermediariamente el servicio Web

que se denomina Ignyte's Retrieve Theaters and Movie Showtimes. Este servicio, como ya

se describió anteriormente, permite obtener la programación de cines para un determinado

código postal de los Estados Unidos de América.

En la figura 4.11 se presenta la funcionalidad general, en caja negra, del documento

WSDL del servicio Proxy Theaters. Este servicio se provee por medio de un único método.

Dicho método se denomina getShowTimes y para su invocación se requiere un argumento

de tipo String para enviar el código postal. Por otra parte, se establece que el método del

servicio retornará su respuesta en un dato de tipo String. En consecuencia, para la respuesta

se estableció un elemento que se denomina ―Response‖.

La clase Theaters presenta un único método para la invocación del servicio. Este

método se denomina getShowTimes. En la figura 4.12 se presenta un ejemplo de la

invocación del método y en la figura 4.13 se presenta su ejecución.


74

Figura 4.11. Ejemplificación, en caja negra, del empleo del método getShowTimes del

documento WSDL para el servicio Proxy Theaters

Figura 4.12. Ejemplo de invocación del método del servicio Proxy Theaters que se

denomina getShowTimes.

Figura 4.13. Ejemplo de ejecución del método del servicio Proxy Theaters que se denomina

getShowTimes

Método de la clase

Theaters:

getShowTimes ()

String CodigoPostal String Respuesta


75

4.3.4. Servicio Proxy USAWeather.

El servicio Proxy USAWeather consiste en ofrecer intermediariamente el servicio

Web USA Weather Forecast. Este servicio, como ya se describió anteriormente, permite

obtener la predicción del clima para un determinado código postal o lugar de los Estados

Unidos de América.

En la figura 4.14 se presenta la ejemplificación, en caja negra, de la funcionalidad

general del documento WSDL del servicio Proxy USAWeather. Este servicio consta de dos

métodos para obtener la predicción del clima. Estos métodos se denominan:

getWeatherByZipCode y getWeatherByPlaceName. El primero de ellos requiere de un dato

de tipo String para enviar el código postal del lugar, de los Estados Unidos de América,

sobre el que se desea la predicción del clima. El segundo método, para el mismo objetivo,

requiere un dato de tipo String para el nombre del lugar.

En consecuencia, en el documento WSDL se establecen los elementos de nombres:

―ZipCode‖, ―PlaceName‖ y ―Response‖. Todos de tipo String. Los dos primeros elementos

se utilizan para proveer el código postal o el nombre del lugar, respectivamente. Mientras

que el elemento denominado ―Response‖ lo utilizan ambos métodos para entregar la

respuesta del servicio.

En la figura 4.15 se presenta la invocación de uno de los métodos del servicio y en

la figura 4.16 se presenta su ejecución.

Figura 4.14. Ejemplificación, en caja negra, del empleo de los métodos del documento

WSDL para el servicio Proxy USAWeather

Métodos de la

clase

USAWeather:

String ZipCode String Response

String PlaceName String Response

getWeather

ByZipCode ()

getWeather

ByPlace

Name()


76

Figura 4.15. Ejemplo de invocación de un método del servicio Proxy USAWeather que se

denomina getWeatherByZipCode.

Figura 4.16. Ejemplo de ejecución de un método del servicio Proxy USAWeather que se

denomina getWeatherByZipCode..


77

4.3.5. Tecnología de desarrollo para el modo portal Proxy

La construcción del modo Proxy requirió, primeramente, de la construcción de los

documentos WSDL para los servicios de este modo. Para ello, se empleó el programa que

se denomina SOA Editor. Una vez que se obtuvieron dichos documentos, se requirió del

ambiente de desarrollo integrado NetBeans 5.5 para tres fines principales: (1) obtener

clientes para el consumo de los servicios Web que proveen los proveedores externos al

portal. Esto, gracias a los documentos WSDL que dichos proveedores previamente

proporcionaron, (2) programar, en lenguaje Java, los diferentes servicios Web Proxy para

atender a los clientes del portal. Esto, gracias a los documentos WSDL que previamente se

construyeron para este objetivo; y (3) obtener el servidor para ofrecer el modo Proxy.

4.4. Capas de prestaciones de servicios de la arquitectura del portal.

La arquitectura que se propone se compone por seis capas, las cuales son: (1)

presentación, (2) comunicación, (3) descubrimiento, (4) servicio, (5) lógica; e (6)

integración. La arquitectura compuesta en capas se muestra en la figura 4.17.

Generalmente, estas capas proveen servicios a los dos modos de operación del portal. Sin

embargo, la capa de presentación es exclusiva al modo portal de Internet. A continuación,

se presenta los servicios que ofrece cada capa y en que consisten.

4.4.1. Capa de presentación

La capa de presentación ofrece el servicio de interfaz al usuario final para el modo

portal de Internet. Los servicios de la capa de presentación consisten en:

(1) reunir información del usuario final o cliente. Este objetivo se logra a través de

formularios HTML que el portlet presenta de acuerdo al tipo de servicio que atiende.


78

(2) enviar dicha información a la capa de descubrimiento para que ésta determine el portlet

que se requiere. Se envía a través de HTTP cuando el portal recibe la orden por medio

de su menú.

(3) recibir información de respuesta desde la capa de integración. Esto se logra a través de

una instrucción output que permite a un programa en JSP transmitir información a

formato HTML y que se exterioriza en el navegador de Internet.

(4) presentar, la información del punto anterior, ordenadamente al usuario final. Este

objetivo se logra a través de elementos típicos de HTML, por ejemplo, tablas, listas de

selección, áreas de texto, entre otros.

4.4.2. Capa de comunicación

Para los clientes del modo portal de Internet la comunicación opera con el protocolo

HTTP; mientras que para el modo Proxy es el mensaje SOAP. Para los clientes del modo

Proxy, y del portal con los proveedores externos, se provee la comunicación a través de

mensajes SOAP. Los mensajes SOAP emplean HTTP como protocolo de transporte,

aunque también pueden emplear otros protocolos como SMTP (Simple Mail Transfer

Protocol, protocolo simple de transferencia de correo electrónico), FTP (File Transfer

Protocol, protocolo de transferencia de archivos), entre otros. SOAP utiliza generalmente

HTTP por ser éste un protocolo de amplia difusión y porque el puerto HTTP generalmente

no se protege (80 es su puerto por defecto). Por otra parte, los servicios de la capa de

comunicación consisten en:

(1) permitir la comunicación con el portal. En el caso del modo portal de Internet es a

través de HTTP y en el caso del modo Proxy es a través de un mensaje SOAP. En

esta última situación interviene el componente que se denomina analizador de

mensajes SOAP, el cual atiende a la aplicación del cliente que demanda el consumo

de un servicio. La aplicación del cliente está en condiciones de construir dicho

mensaje SOAP gracias a que, previamente, se proporcionó, al cliente, el documento

WSDL del servicio Web respectivo.


79

(2) solicitar el servicio que se requiere al proveedor externo del portal. Esto a través de

un mensaje SOAP. Este se construye con los requerimientos que se indican en el

documento WSDL que el proveedor externo previamente suministró; y

(3) enviar a la aplicación del cliente la información de respuesta que provee el

componente que se denomina constructor de respuesta. La respuesta se envía a

través de un mensaje SOAP. Para el modo portal de Internet, la comunicación opera

con el protocolo HTTP.

En relación al mensaje SOAP, éste permite dirigir, generalmente a través de HTTP, un

mensaje de petición al servidor del servicio Web correspondiente, y ya en el servidor,

permite invocar un servicio específico proveyendo, además, los parámetros necesarios para

ello.

4.4.3. Capa de descubrimiento

La capa de descubrimiento ofrece el servicio de identificar al portlet que

implementa el servicio que demanda el cliente, ya sea para el modo portal de Internet o

para el modo Proxy. El servicio de descubrimiento consiste en:

(1) descubrir al portlet que se requiere. Ello se realiza a través de identificar al servicio

que se indica en el mensaje SOAP que recibió la capa de comunicación. Con el cual

se realiza una consulta y selección de servicio por nombre; y

(2) solicitar el portlet que se demanda desde el modo Proxy, según descripción del

punto anterior, o que se demanda desde el modo portal de Internet al componente

que se denomina contenedor de portlets. Esta solicitud se realiza a través del

nombre del portlet.


80

4.4.4. Capa de servicio

La capa de servicio hospeda los diversos servicios que provee el portal. Esto lo

realiza a través del componente que se denomina contenedor de portlets. Los servicios de

esta capa consisten en:

(1) proporcionar al portlet con los recursos e información necesaria para que éstos

entreguen al portal información y contenidos dinámicos. Esto es posible gracias a

las formas de operación de los portlets. Estas formas de operación se ofrecen a los

usuarios a través de botones de los portlets. Éstos, al ser accionados por los usuarios

constituyen órdenes de formas de operación del portlet. Estas órdenes se crean,

primeramente, con tecnología HTML y que, inmediatamente, se recaban por

variables de JSP y se transmiten al contenedor de portlets a través de los métodos

correspondientes.

(2) proveer el portlet que solicita la capa de descubrimiento. El menú del portal permite

disponer de los portlets. Al elegir una opción en el menú se establece una orden,

primeramente, de tecnología HTML e inmediatamente sigue una situación análoga

a la que se describe en el punto inmediato anterior; y

(3) hospedar al componente que se denomina contenedor de portlets, el cual realiza los

dos objetivos anteriores.

4.4.5. Capa lógica

La capa lógica provee los mecanismos de control del sistema a través de los portlets.

Los servicios de esta capa consisten en:

(1) aplicar reglas de validación a datos que provienen de la interfaz de usuario. Esto se

refiere a validación de datos tal como que el dato que se provea sea un entero y no

otro, por citar un ejemplo.

(2) proveen los componentes que se denominan: analizador de respuestas y

constructor de respuestas, los cuales son necesarios para formulación de


81

respuestas. El constructor de respuesta se provee a través de un método el cual se

encarga de articular el dato de respuesta.

4.4.6. Capa de integración

La capa de integración provee el servicio de construcción de respuestas. Este

servicio se proporciona a través de los componentes: invocador, analizador de respuestas y

constructor de respuestas. Los servicios de la capa de integración consisten en:

(1) Invocar al proveedor externo el servicio que demanda el cliente. Esto se realiza a

través de un mensaje SOAP.

(2) extraer la información neta de respuesta desde la información que se recibe del

proveedor externo. Esta información neta se constituye o bien por algún tipo de

dato o por una estructura de datos compleja. Este resultado se obtiene a través del

analizador de repuestas, y éste transmite dicho resultado al constructor de

respuesta.

(3) construir la información de respuesta, a través del constructor de respuesta, de

acuerdo a especificación que se realizó al cliente en el documento WSDL que se le

entregó. Para los servicios del portal en su modo Proxy la información neta de

respuesta consiste en un dato de tipo String, el cual contiene a la respuesta y la

presenta con fragmento de marcado HTML. Para alcanzar este resultado, el

constructor de respuesta realiza su labor a partir de desarticular los datos que se

reciben del proveedor externo y con ello construir la respuesta. Lo anterior, se

logra, simplemente, con programación en código Java; y

(4) remitir a la capa de comunicación para que ésta la transmita al cliente respectivo,

tanto para el modo Proxy como el para el modo portal de Internet. En el primer

caso, se realiza a través de un mensaje SOAP y en el segundo caso, la clase java

provee la respuesta, primeramente, a un archivo JSP a través del retorno de

respuesta de un método del contenedor de portlets. A su vez, el archivo JSP genera

una salida (output) con fragmento de marcado HTML. Esta respuesta se recibe por


82

el usuario final gracias a su navegador con conexión a Internet, donde opera el

protocolo HTTP.

Figura 4.17. La arquitectura de portal en capas.

4.5. Resumen

Se presentaron las prestaciones de servicios del portal empresarial. Se mostró que

estas prestaciones consisten en dos modos de operación del portal: modo portal de Internet

y modo Proxy. Estos servicios se proveen a través de la arquitectura que se propone, la

cual se divide en capas.

Para que el cliente obtenga los servicios del portal en su modo portal de Internet

requiere acceder al portal a través de su navegador de Internet y elegir alguna opción que

presenta el menú de opciones del portal con el fin de disponer de algún portlet o de todos

ellos juntos. Por otra parte, para la labor de diseño del portal se presentaron los métodos

que gestionan el ciclo de vida de los portlets.


83

En relación a los servicios Proxy, el cliente requiere recibir del portal los respectivos

documentos WSDL para acceder a estos servicios. Una vez hecho lo anterior, el cliente

requiere desarrollar las aplicaciones Web correspondientes. Estas aplicaciones disponen de

la API del modo Proxy, necesaria para el consumo de los servicios de éste modo.

Finalmente, se presentó una arquitectura bajo diferentes niveles de prestación de

servicios. La arquitectura propuesta presenta seis capas: (1) presentación, (2)

comunicación, (3) descubrimiento, (4) servicio, (5) lógica; e (6) integración.


84

Capítulo 5. Casos de estudio

5.1. Introducción

En este capítulo se presentan casos de estudio que demuestran las ventajas que un

portal de segunda generación, que se constituye por portlets, ofrece al usuario. En general,

la tecnología de portlets evita, al usuario, la necesidad de visitar infinidad de sitios o

portales dispersos para recibir los servicios que el portal ofrece a través de sus portlets.

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

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

información proveniente de fuentes de datos heterogéneas. Se hace mención que la

arquitectura propuesta, a través de sus portlets, emplea servicios Web de entretenimiento,

correspondiente a los Estados Unidos de América porque en nuestro país (México) estos

servicios no se proporcionan.

Para el portlet Theaters se tiene el caso de estudio con el siguiente escenario:

1. Un usuario desea conocer la programación de películas para un determinado lugar

de los Estados Unidos de América.

2. Existen varios sitios o portales dispersos que ofrecen la programación de

películas.

En este escenario, ¿cómo puede el usuario encontrar la programación de películas

sin visitar tantos sitios o portales dispersos?.

Para contestar la pregunta que se describe en el escenario, es necesario que el

usuario utilice el portal propuesto. En la Figura 5.1, se muestra una interfaz gráfica del

portal con sus primeros cuatro portlets. Este portal presenta un portlet denominado Theaters

(el cual se muestra en estado de presentación, en la figura 5.2a, y en estado de ejecución, en

la figura 5.2b y 5.2c). El portlet Theaters presenta el servicio de entretenimiento consistente


85

en la programación de películas que ofrecen los cines para un determinado código postal de

los Estados Unidos de América.

El portlet Theaters solicita, al usuario, el código postal de los Estados Unidos de

América sobre el que interesa realizar la búsqueda y solicita que se seleccione un radio de

acción (perímetro que cubre la búsqueda). Después, solicita que elija entre tres opciones de

consulta: (1) general, (2) por cine; y (3) por película. En cualquiera de las tres opciones, la

búsqueda comprende al código postal y al radio de acción que el usuario proporciona. Si

elije la primera opción, corresponde al usuario seleccionar la casilla ―Everything‖ y oprimir

el botón ―get ShowTimes‖. Inmediatamente, el portlet despliega una tabla con la

programación de películas. Si elije la segunda opción, concierne al usuario seleccionar la

casilla ―By theater‖ y oprimir el botón ―get ShowTimes‖. Luego, el portlet despliega la

lista de cines. Entonces, atañe al usuario elegir un determinado cine y oprimir el botón

―Show‖. En seguida, el portlet despliega una tabla con la programación de películas del

cine que seleccionó. Si elije la tercera opción, incumbe al usuario seleccionar la casilla ―By

film‖ y oprimir el botón ―get Show Times‖. Inmediatamente, el portlet presenta al usuario

una lista con las películas. Entonces, concierne al usuario elegir una determinada película y

oprimir el botón ―Show‖. Enseguida, el portlet despliega al usuario una tabla con todos los

cines que ofrecen esa determinada película.

El portal es de gran ayuda al usuario, porque éste no necesita visitar infinidad de

sitios o portales para encontrar la programación de películas de interés.

Figura 5.1. Portal con los primero cuatro portlets


86

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

(c) En ejecución, segunda parte

Figura 5.2. El portlet Theaters en presentación y en ejecución

5.3 Caso de estudio: ayuda en la toma de decisión para la asistencia al

cine.

El caso de estudio de la presente sección ayuda al usuario a tomar la decisión si

asiste o no al cine. Debido a que, además de la programación de cines para un determinado

lugar, también se muestra la previsión del clima para ese mismo lugar. El escenario es el

siguiente:


87

1. Un usuario desea conocer la programación de películas para un determinado lugar

de los Estados Unidos de América, y además, desea conocer la previsión del clima para el

mismo lugar para decidir si asiste no al cine.

2. Existen un grupos de sitios o portales dispersos que ofrecen la programación de

películas y la previsión del clima.

En este escenario, ¿cómo puede el usuario obtener la programación de cines y la

previsión del clima para con ello tomar la decisión si asiste o no?.

Para contestar la pregunta que se describe en el escenario, es necesario que el

usuario utilice nuestro portal, el cual presenta un portlet denominado

TheatersAndUSAWeather. Este portlet presenta el servicio de entretenimiento consistente

en la programación de películas que ofrecen los cines y la previsión del clima para un

determinado código postal de los Estados Unidos de América.

Este portlet, TheatersAndUSAWeather, se muestra en su estado de presentación

inicial al usuario en la figura 5.3, y en relación a su estado de ejecución, éste tiene el mismo

contenido al que se presentó, anteriormente, en la figura 5.2b y 5.2c para el portlet

Theaters. Sin embargo, la diferencia consiste en que al resultado final, el presente portlet

agrega una tabla con la previsión del clima tanto en grados centígrados como Fahrenheit

para el código postal que proporcionó el usuario como se muestra en la figura 5.4. El modo

de operar del portlet se describe a continuación.

Figura 5.3. El portlet TheatersAndUSAWeather en su presentación inicial al usuario.


88

Para ofrecer sus servicios, el portlet TheatersAndUSAWeather primeramente

solicita, al usuario, que elija un estado de los Estados Unidos de América. Con esta

información, el portlet presenta una lista de las cinco principales ciudades de dicho estado.

A continuación, solicita, al usuario, que seleccione una determinada ciudad entre las que

presenta. Una vez que el usuario hace lo anterior, el portlet presenta una lista con los

códigos postales de dicha ciudad. Entonces, el portlet solicita al usuario que elija un

determinado código postal. Una vez que el usuario el selecciona el código postal, el portlet

solicita, al usuario, que seleccione un radio de acción (perímetro que cubre la búsqueda) y

que elija un tipo de consulta: (1) general, (2) por cine; y (3) por película. A continuación, el

portlet despliega la respuesta al usuario como se aprecia en la figura 5.4.

Figura 5.4. El portlet TheatersAndUSAWeather en ejecución.

A continuación se describen los argumentos de la tecnología de portlets que

permiten las ventajas al usuario que se mostraron en los casos de estudio.


89

5.4. Fundamentos de la tecnología de portlets que explican sus ventajas en

sus servicios al usuario.

Los casos de estudio que se describieron demuestran ventajas características de los

servicios de los portlets. Porque el usuario no necesita saber qué empresas u organizaciones

proveen el servicio Web de entretenimiento que el portlet presenta. En este sentido, el

usuario delega al portal la tarea del consumo de dichos servicios Web a través del portlet.

El usuario solicita un servicio de entretenimiento a través de la interfaz que el portlet

presenta. El portlet recibe la solicitud e, internamente, ejecuta el consumo del servicio Web

correspondiente. Cuando el servicio Web provee al portlet con la información de respuesta,

el portlet, ordenadamente, la presenta al usuario.

Por otra parte, el portal tiene la ventaja de ser adaptable y de presentar información

de fuentes de datos heterogéneas consistentemente. Es adaptable porque, durante el diseño

del portal, a los portlets se asigna la distribución que se considere más conveniente. Por

otra parte, del lado del usuario, los portlets son adaptables porque cada portlet presenta

varias formas de operación: (1) minimizar, (2) normalizar, (3) maximizar; y (4) cerrar.

Además un botón para el modo edit (edición) y para el modo view (vista). En el modo edit

se tiene la opción de configurar el ancho y alto del portlet e incluso de modificar el tipo de

servicio actual del portlet por el de otro portlet.

La capacidad de asignar a los portlets la distribución que se considere más

conveniente al portal asigna a éste la cualidad de adaptable. Ello es posible dada la

condición de los portlets de constituir componentes Web. Esta condición permite a los

portlets versatilidad para desarrollarse y desplegarse manejablemente. Además, dado que

un portlet es un componente, ello muestra a los portlets como un encapsulado de una

aplicación Web para utilizarse dentro de un portal.

Por otra parte, el portal es atractivo al usuario porque además de los portlets

comentados en los anteriores casos de estudio, el portal que se propone también presenta

otros portlets, tales como Amazon.com, USAWeather y Horoscope.

El portlet Amazon.com ofrece, en un contexto de comercio electrónico, la búsqueda

de productos en treinta líneas diferentes de éstos. Este servicio es del tipo B2C (Business to

Consumer) y sólo permite consultar los productos que se desean, no ofrece servicio de


90

carrito de compras. Para consumir los servicios de este portlet se requiere una palabra clave

con relación al producto de interés, y además, se requiere elegir un tipo de línea de

producto. De tal forma que, por ejemplo, si se desean libros de Java. Entonces la palabra

clave es ―Java‖ y la línea de producto a seleccionar es ―libros‖.

El portlet USAWeather ofrece la predicción del clima para los más importantes

códigos postales o ciudades de los Estados Unidos de América. Este servicio se presenta

con las opciones siguientes: (1) grados centígrados, (2) grados Fahrenheit; y (3) ambos. En

cualquiera de las tres opciones, el servicio presenta la predicción del clima para los siete

días de la semana, e indica la temperatura máxima y mínima tanto en grados centígrados

como en grados Fahrenheit. Para consumir los servicios de este portlet se requiere

proporcionar el código postal o el nombre de una ciudad. Además, se requiere elegir el tipo

de grado en que se desea la consulta.

El portlet Horoscope ofrece la predicción diaria del horóscopo para los doce signos

zodiacales. Todos los vaticinios se presentan en idioma inglés y para cada uno de éstos se

muestra una redacción de un párrafo con alrededor de diez líneas de contenido. El portlet

Horoscope ofrece dos tipos de consulta: (1) todos los signos; y (2) un signo en específico.

Si se opta por la primera opción se requiere seleccionar, de la lista que presenta el portlet, la

opción que se denomina ―All signs‖. En caso contrario, de la misma lista anterior, se

selecciona un signo zodiacal en concreto y se invoca el servicio.

5.5. Resumen

En este capítulo se presentaron dos casos de estudio. Ambos describen una

problemática a la que se enfrenta un cliente, el escenario que se presenta dicha

problemática y que el portal, a través de sus portlets, está en condiciones de resolver. En

consecuencia, en este capítulo, también se hizo énfasis en fundamentos tecnológicos que

permiten a los portlets ofrecer sus respectivas soluciones.

El primer caso de estudio se enfocó en describir la solución que un portlet ofrece a

un cliente que dispersa su tiempo al tener que buscar la programación de cines en múltiples

sitios. El segundo caso de estudio presentó, a otro portlet, con la misma solución a la


91

problemática anterior; pero que además, ayuda al cliente a decidir si asiste o no al cine dado

que agrega la predicción del clima.

Finalmente, en la sección de los fundamentos de la tecnología de portlets que

explican sus ventajas al usuario se realizó una discusión sobre las ventajas que implican los

mecanismos a los cuales acceden los portlets, es decir, los servicios Web. Además, se

mostró la cualidad de adaptabilidad de la arquitectura que se propone. Dicha cualidad

permite adecuar, en tiempo de diseño, la colocación de los portlets en el portal. Por otra

parte, la cualidad de adaptabilidad se presenta de los portlets hacia los clientes a través de

servicios que facilitan las experiencias de interacción de los clientes.


92

Capítulo 6. Conclusiones

6.1. Conclusiones generales

Esta tesis cumplió con su objetivo general de presentar el diseño y construcción de

un portal empresarial utilizando la tecnología de portlets. En forma más detallada, el

objetivo general de la tesis consistió en el diseño y construcción de un portal empresarial

con base en el desarrollo de una aplicación Web, que se gestione por un contenedor de

portlets. El contenedor de portlets provee un entorno de ejecución para los portlets, ello

permite a los portlets generar, dinámicamente, fragmento de marcado HTML al portal. En

consecuencia, la hipótesis estableció que como apoyo a dicho objetivo se utilice tecnología

open source (código abierto), dado que ello otorga al sistema a desarrollar la característica

de la portabilidad.

El objetivo de esta tesis tuvo su correspondiente motivación. La razón de utilizar la

tecnología de portlets, para portales de segunda generación, consiste en superar

restricciones de los portales monolíticos de la primera generación. Restricciones que causan

dificultad de desarrollo y mantenimiento. Mientras que el enfoque orientado a componentes

basado en portlets, favorece el desarrollo, mantenimiento y re-uso. Por otra parte, el portal

se enfoca al entorno empresarial con la funcionalidad de la industria del entretenimiento.

Con ello, se desarrolla tecnología que es posible llevar a las empresas de la región, con el

fin de mejorar su productividad. Dicha productividad se observa en los siguientes aspectos:

(1) rendimiento en el proceso de desarrollo de los portlets; porque la independencia de los

portlets permite un proceso de desarrollo separado y paralelo, (2) favorece la experiencia

de los usuarios con el portal a causa de la adaptabilidad que los portlets otorgan; y (3) el

portal continúa funcional en el caso de falla de uno de sus portlets; porque dada la

independencia de éstos, dicha falla no se transmite al resto de ellos. Es obvio que las

ventajas que antes se citan serán poco observables para un portal con uno o dos portlets.

Por lo tanto, las empresas de la región que se favorecen del empleo de la tecnología de


93

portlets son aquellas empresas que requieren desarrollar portales para hospedar a un amplio

conjunto de portlets, donde cada portlet atiende su respectiva aplicación Web.

Tal como se mostró a lo largo de este documento, la tesis logró sus objetivos. La

realización de dichos objetivos implicó la necesidad de desarrollar una arquitectura. Dado

que el portal empresarial que se desarrolló se basa en portlets y los portales de segunda

generación usan a los portlets como componentes modulares para interfaz de usuario, en

consecuencia se desarrolló una arquitectura orientada a componentes. Como ya se presentó

anteriormente, esta arquitectura presenta dos elementos principales: el modo portal de

Internet y el modo Proxy o intermediario de servicios Web. Mientras el modo portal de

Internet ofrece un servicio directo al cliente, a través de las pequeñas ventanas de

información que presentan los portlets; el modo Proxy atiende, no a clientes como personas

físicas, sino a solicitudes de servicio que realizan aplicaciones Web de los clientes.

Los dos elementos principales de la arquitectura del portal se constituyen de

componentes más específicos. Sin embargo, se destaca que un componente fundamental de

ambos modos es el contenedor de portlets. El contenedor de portlets, en respuesta a

peticiones del usuario, genera y presenta contenidos dinámicos configurables para la

interfaz de usuario. Los portlets trabajan cooperativamente con los servicios de

entretenimiento que el portal obtiene a través del consumo de servicios Web. En

consecuencia, y dada la característica de interoperabilidad de los servicios Web, se logra

comprobar la hipótesis. La hipótesis indica que con el uso de la tecnología open source se

obtiene la característica de la portabilidad del portal a desarrollar.

Por otra parte, se señala que la principal dificultad en el desarrollo de esta tesis

consistió en la obtención de los portlets y de su integración. Dado que, inicialmente, se

empleó el ambiente de desarrollo integrado que se denomina Java Studio Creator 2; sin

embargo, este ambiente de desarrollo requiere demasiada memoria RAM de la

computadora personal. Por otra parte, la ejecución de un portlet con Java Studio Creator 2

presentó los siguientes inconvenientes: (1) ejecución muy lenta, ya que para ejecutar un

portlet tarda cerca de tres minutos, (2) el portlet es propenso a sufrir daño, el cual recibe el

calificativo de irremediable por el IDE Java Studio Creator 2. Cuya causa a veces se

atribuyó a algún error en el código y otras veces la causa del daño no fue identificable; y (3)

dado que este ambiente de desarrollo no permite integrar a los portlets, en consecuencia, se


94

pretendió ejecutar a los portlets en el servidor de aplicaciones que se denomina JBoss el

cual es open source y se tiene conocimiento que se desarrolló en lenguaje Java. Sin

embargo, este objetivo no se logró porque dicho servidor reportó problemas de

compatibilidad para este propósito. A consecuencia de la problemática anterior, se

desarrolló un contenedor de portlets propio, utilizando para ello tecnología open source

como el lenguaje de programación Java y se empleó al servidor de aplicaciones TomCat.

En consecuencia, los portlets desarrollados con Java Studio Creator 2 se desecharon y se

desarrollaron portlets cuya presentación utiliza tecnología JSP que se agregaron, con éxito,

al contenedor de portlets propio.

Por lo anterior, se agrega, a las conclusiones que esta sección presenta, que el

estudio del estándar JSR-168 resultó importante como base para el desarrollo de un

contenedor de portlets propio, que satisfizo exitosamente las necesidades que se planteó

esta tesis.

6.2. Contribuciones de la tesis.

Este trabajo contribuye con:

Una arquitectura de integración de información basada en portlets.

Un conjunto de mecanismos que definen la funcionalidad de los servicios

representados como portlets.

La arquitectura propuesta se validó con dos casos de estudio que permitieron

observar su utilidad. Concretamente se presentó un primer caso de estudio para la búsqueda

de la programación de cines dado un código postal y se presentó un segundo caso de

estudio para ayudar en la toma de decisión, acerca de si se asiste o no al cine, dada la

predicción del clima, además de la misma programación de cines. Ambos casos de estudio

permitieron demostrar que la arquitectura provee al portal con la característica de la

adaptabilidad y de presentar información consistentemente. Estas características

constituyen las ventajas de la arquitectura propuesta. En relación a la característica de la


95

adaptabilidad, ésta se presenta durante el diseño del portal porque los portlets se distribuyen

en el orden que se desee. Además, la adaptabilidad se otorga a los usuarios a través de las

varias formas de operación de los portlets. Se accede a las formas de operación de los

portlets a través de sus botones. En relación a la característica de acceso, con coherencia, a

fuentes de datos de diversas naturalezas en la infraestructura global de información, ésta se

obtiene a causa de los medios con que operan los servicios Web. Dichos medios permiten

independencia de lenguaje y plataforma para comunicación entre aplicaciones. Los

servicios Web logran este objetivo a través del empleo de los estándares: HTTP, XML,

SOAP y WSDL.

Por otra parte, considerando que un mecanismo es una técnica o tecnología

particular que proporciona una función. En este sentido, el conjunto de servicios Web son

los mecanismos a los cuales se accede a través de los portlets.

6.3. Trabajo futuro

Esta tesis logró sus objetivos y éstos son muy importantes. En este sentido, ya se

presentaron las ventajas de la arquitectura propuesta a través de casos de estudio. Sin

embargo, para aquellos que tengan interés en continuar trabajando sobre la línea de

investigación de esta tesis, para esto se propone el siguiente trabajo futuro:

Obtener una nueva valoración de la arquitectura propuesta a través de su

aplicación a un entorno real.

Desarrollar nuevos casos de estudio.

Sería conveniente validar a la arquitectura en un entorno real; no obstante que ésta

ya se validó exitosamente en el entorno académico. Esto permitiría una nueva valoración

del alcance de la propuesta. Por lo tanto, sería apropiado validar la arquitectura con otro

tipo de aplicaciones donde sea imperativo obtener las ventajas que ofrecen las arquitecturas

basadas en portlets. Como se recordará, estas ventajas consisten en: (1) la independencia de

los portlets permite que un equipo de desarrollo se distribuya el trabajo de implementación

de los portlets. Así, cada sub-grupo, del equipo de desarrollo, atiende el desarrollo de

determinados portlets. Donde la atención hacia un portlet no implica prestar atención hacia


96

algún otro. Ello, gracias a su característica de atómico, (2) la adaptabilidad que otorgan los

portlets permiten embeberlos al portal conforme los portlets se generan y su adaptabilidad

también se presentan hacia el usuario final. Lo anterior repercute en una productividad

inmediata; y (3) la alta individualidad de los portlets permite que el eventual fallo de un

portlet no repercuta en el desempeño de los demás. Entonces, la pregunta que se requiere

responder es: ¿Qué entorno de trabajo requiere apremiantemente de estas ventajas?. La

respuesta se aplica a todo departamento u organización de desarrollo de software que tiene

como encargo la responsabilidad de desarrollar un amplio conjunto de aplicaciones Web,

atómicas, y que requieren de una puesta en marcha veloz, con el conjunto de soluciones que

se van generando. En este sentido, se propone como trabajo futuro el caso de estudio que

abajo se presenta primeramente.

Por otra parte, esta tesis presentó un caso de estudio que trata de la composición de

portlets. Ello es necesario cuando el consumo de un solo servicio Web no es suficiente para

orquestar la solución al usuario. En relación al tema, se propone el caso de estudio que se

presenta a continuación en segundo término.

6.3.1. Caso de estudio propuesto en la implementación imperiosa de un portal con un

conjunto inicial de soluciones a través de una arquitectura basada en portlets.

Para este primer caso de estudio se propone el escenario de una organización de

desarrollo de software que desea una implementación rápida de un portal que presente

soluciones a ciertos problemas de investigación de operaciones. Una vez que se implementa

dicho portal, este se ofrecería a las industrias de la región susceptibles de interesarse en

soluciones a esta clase de problemas. Además, ante las industrias de la región, se

promocionaría la característica de adaptabilidad del portal. Dicha característica permite al

portal embeber a un número creciente e indefinido de nuevas soluciones, en este caso, a

problemas de investigación de operaciones.

Los problemas, de dicha área, que el portal resolvería en su etapa inicial son los

siguientes: (1) método de mínimos cuadrados para determinar la función de la demanda, (2)

control de inventarios, (3) sistema de líneas de espera, (4) sistema de optimización y


97

sistema de diagnóstico; y (5) toma de decisiones sin muestreo. En este escenario, surge la

pregunta:

¿Cómo requiere dicha organización de desarrollo de software implementar la

arquitectura basada en portlets para satisfacer las necesidades que antes se citan?

La implementación de este caso de estudio ofrecería nuevas experiencias acerca de

los beneficios de la arquitectura basada en portlets para un escenario de alta demanda de

aplicaciones Web independientes y que requieren de una integración rápida y productiva en

un portal. Dichas experiencias tienen importancia porque enriquecen el estado del arte.

6.3.2. Caso de estudio propuesto para obtener noticias de Java en alguno de los

idiomas más importantes.

El caso de estudio que a continuación se propone trata de la composición de portlets

para solicitar noticias del lenguaje Java en alguno de los idiomas más importantes a nivel

mundial. Esto, para dar solución a la problemática que presenta un usuario que requiere

obtener dichas noticias para alguno de los principales idiomas. En consecuencia, surge la

siguiente pregunta:

¿Cómo puede el usuario conseguir las noticias de Java sin tener que buscar en

multitud de sitios o portales dispersos y, además, eludiendo la necesidad de un servicio de

traducción, en caso de que las noticias no se encuentren en el idioma que desea?

Para contestar la pregunta que se describe en el escenario, se requiere de un portlet

que ofrezca el servicio completo y con ello, evitar al usuario su dispersión de tiempo. Para

implementar la solución, conviene considerar la composición de un portlet con dos

determinados servicios Web: JavaPortal News y Translation Engine. El primero de estos

servicios permite obtener, en idioma inglés, el número de noticias que se desea sobre Java;

mientras que el segundo servicio traduce de idioma inglés hacia alguno de los idiomas más

importantes. Los documentos WSDLs respectivos se ofrecen en el sitio de xmethods.com.

En consecuencia, la orquestación en el portlet de estos dos servicios ofrecería la solución

que demanda el usuario.


98

Finalmente, esta tesis significó realizar investigación y contribuye al estado del arte.

Con ello, se aporta una fuente bibliográfica para trabajos futuros.


99

Glosario

API.- (Application Programming Interface, interfaz de programación de la aplicación)

define los métodos a través de los cuales el programador accede y controla un sistema dado.

Arquitectura.- una descripción de un sistema, incluyendo a los componentes del sistema y

como ellos interactúan. También se dice que una arquitectura es una descripción de todas

las actividades funcionales que se realizarán para alcanzar la misión deseada, los elementos

que el sistema necesita para realizar sus funciones, y la designación de los niveles de

funcionamiento de dichos elementos.

Compatibilidad.- es la capacidad para trabajar con otro dispositivo o sistema sin

modificación. Existe compatibilidad de hardware y software.

Distribuido.- significa descentralizado, es decir, algo que se reparte en diferentes nodos.

HTTP.- (HyperText Transfer Protocol, protocolo de transferencia de hipertexto) es el

protocolo utilizado para el intercambio de los archivos de hipertexto (que se escriben en

HTML) a través de Internet, entre un software cliente y un servidor, operando ambos bajo

este protocolo. HTTP es el protocolo más importante utilizado en los servicios de la World

Wide Web (WWW).

Interoperabilidad.- es la condición mediante la cual sistemas heterogéneos pueden

intercambiar procesos o datos.

JSR 168.- (Java Specification Request, especificación Java Portlet) es un estándar que

permite la interoperabilidad de los portlets entre portales Web diferentes. Esta

especificación define una API para interacción entre el contenedor de portlets y el portlet

que se dirige hacia áreas de personalización, presentación y seguridad.


100

Mecanismo.- una técnica o tecnología particular para proporcionar una función.

Open source.- (código abierto) cualidad del software de incluir el código fuente en la

distribución del programa. En general se usa para referirse al software libre.

Portabilidad.- característica por la cual un programa puede transportarse de un sistema

operativo a otro sin necesidad de cambiar su código fuente.

Portal.- Es un sitio Web que representa un punto de acceso a recursos e información de una

empresa u organización para sus empleados, clientes o proveedores.

Portlet.- son componentes Web gestionados por un contenedor de portlets que procesa

peticiones y genera contenido dinámico. Los portales usan portlets como componentes de

interfaz de usuario que proveen de una capa de presentación a los sistemas de información.

Proxy.- Servidor situado entre la máquina del usuario e Internet. En el contexto del trabajo

de la presente tesis se refiere a un servicio de intermediación en servicios Web.

Servicios Web.- Es una colección de protocolos y estándares que sirve para intercambiar

datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de

programación diferentes y ejecutados sobre cualquier plataforma disponen de los servicios

Web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad

se consigue mediante la adopción de estándares abiertos: SOAP, WSDL y UDDI.

SOAP.- (Simple Object Access Protocol, protocolo simple de acceso a objetos) es un

protocolo para mensajes basados en XML. SOAP define cómo dos objetos en diferentes

procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de

los protocolos utilizados en los servicios Web.


101

UDDI.- (Universal Description, Discovery and Integration, catálogo de negocios de

Internet) es un conjunto de especificaciones para crear directorios basados en XML de

servicios Web.

WSDL.- (Web Services Description Language, lenguaje de descripción de servicios Web)

es un formato estándar, entendible por la computadora, para describir un servicio Web. Una

definición WSDL describe como acceder a un servicio Web y que operaciones se

ejecutaran.

WSRP.- (Web Services for Remote Portlets, servicios Web para portlets remotos) es un

estándar para portales para acceder y desplegar portlets que se hospedan e un servidor

remoto.

WWW.- (World Wide Web, telaraña mundial) sistema de información basada en el

hipertexto que se comunica por Internet. WWW la parte de Internet a la que se accede a

través del protocolo HTTP y en consecuencia gracias a navegadores normalmente gráficos

como Explorer.

XML.- (Extensible Markup Language, lenguaje de marcas extensible) es un lenguaje

desarrollado por la institución que se denomina W3 Consortium. XML es un metalenguaje,

es decir, sirve para crear lenguajes más específicos y es la base tecnológica de los servicios

Web.


102

Publicación

Enrique Ruiz Díaz, Giner Alor Hernández. ―Una arquitectura de integración de

información basada en portlets para un portal empresarial‖. Primer encuentro de

estudiantes en ciencia de la computación E2C2. ISBN-10:970-36-0404-8 e ISBN-

13:978-970-36-0404-3. Instituto Politécnico Nacional, México, D.F. 2007.


103

Referencias

[1] Wikipedia, ―Internet‖ [en línea] <http://es.wikipedia.org/wiki/Internet> [Consulta: 28

junio 2006]

[2] Alfonso Cubero Moral, Sergio Luna García. ―Servlets y JSP‖ Departamento de

Informática y Automática Universidad de Salamanca. mayo 2003. pp: 2-17

[3] Kenneth Ramírez. ―Entendiendo Portales y Portlets: Parte 1 – Creando un portal

personalizado‖ Java Developer Journal Vol. 9 de 2004. pp: 1-9.

[4] Wikipedia, ―Portal‖ [en línea]

<http://es.wikipedia.org/wiki/Portal_%28internet%29> [Consulta: 28 junio 2006]

[5]Christian Wege. ―Portal Server Technology‖ IEEE Internet Computing. vol. 6, no. 3,

May/June 2002. pp 73-77.

[6] Fernando González, Moisés Cid, Pedro Cuesta. ―Desarrollo de aplicaciones Web

utilizando ASP (Active Server Pages)‖ Departamento de Lenguajes y Sistemas

Informáticos Universidad de Vigo. NOVATICA 36 Edición digital. jul./ago. 2000 No. 146.

pp: 36-39.

[7] José Antonio Guerra Pablos. ―PHP en el mundo real‖. Departamento de servicios Web e

Internet de la consultoría ICTI Consulting. Revista Mundo Linux Abril 2003. pp: 1-13.

[8] Aplicaciones Web. ―Modelo de orientación a objetos de PHP 3 y 4‖. [en línea]

<http://www.aplicacionesweb.cl/content/view/31/2/> [Consulta: 28 Junio 2006].

[9] Aplicaciones Web. ―Modelo de orientación a objetos en PHP 5‖. [en línea]

<http://www.aplicacionesweb.cl/content/view/32/2/> [Consulta: 28 Junio 2006].

[10] Security Linux Com. ―Securing PHP‖. [en línea] <

http://security.linux.com/security/04/08/05/203238.shtml> [Consulta: 28 Junio 2006].

[11] Darío Andrés Silva, Bárbara Mercerat. ―Construyendo aplicaciones Web con una

metodología de diseño orientada a objetos‖ LIFIA, Laboratorio de Investigación y

Formación en Informática Avanzada. Facultad de Informática, Universidad Nacional de

La Plata, Buenos Aires, República Argentina. Enero 2002. pp: 1-21.

[12] Daniel Gayo Avello, Benjamín López Pérez, Luis Vinuesa Martínez, José E. Labra

Gayo, Juan M. Cueva Lovelle. ―Utilización de software libre como única tecnología para el


104

desarrollo de portales Web‖ Universidad de Oviedo, España. Departamento de

Informática. pp: 1-11.

[13] Andrés Vignaga, Daniel Perovich. ―Arquitecturas y tecnologías para el desarrollo de

aplicaciones Web‖. Universidad de la República, Facultad de Ingeniería, Instituto de

Computación Montevideo, Uruguay. pp: 1-51

[14] Pedro Cuesta Morales, Manuel J. Maña López, Carlos Cuervo Martínez. ―Aplicación

de Técnicas de Recuperación de Información a un Glosario de Términos de Internet

Desarrollado Utilizando Tecnología JSP‖ Departamento de Informática, Universidad de

Vigo. pp: 1-9

[15] César Colado Rodríguez. ―Diseño y desarrollo de aplicaciones Web multidispositivo‖

Germinus XXI, Febrero 2003. pp: 1-12.

[16] Thomas Schaeck. ―Web Services for Remote Portals (WSRP) Whitepaper‖. Oasis. pp:

1-18.

[17] Fernando Bellas. ―Standards for Second-Generation Portals‖. IEEE Internet

Computing. vol. 8, no. 2, March/April 2004. pp 54-60.

[18] Kevin Chihcheng Hsu & Fang-Chuan Ou Yang. ―OEPortal: an Open, Unified, and

Interoperable Presentation-Preserving e-Learning Portal‖. Proceedings of the Fifth IEEE

International Conference on Advanced Learning Technologies (ICALT’05). IEEE Press. pp

1-5.

[19] Maytal Dahan, Mary Thomas, Eric Roberts, Akhil Seth, Tomislav Urban, David

Walling, John R. Boisseau. ―Grid Portal Toolkit 3.0 (GridPort)‖. Proceedings of the 13th

IEEE International Symposium on High Performance Distributed Computing (HPDC’04).

IEEE Press. pp 272-273.

[20] Mr P.T. Galligan, Mr J.L. Hopkins, Prof. D.F. Kehoe.―An Approach to Deliver an

Early Return on Investment during the Development of a Corporate Web Portal‖

Proceedings of the 2005 IEEE International Conference on Services Computing (SCC’05).

IEEE Press. pp 1-8

[21] Thomas Puschmann, Rainer Alt. ―Process Portals – Architecture and Integration‖.

Proceedings of the 37th Hawaii International Conference on System Sciences – 2004. IEEE

Press. pp 1-10


105

[22] Brett Beeson, Ashley Wright. ―Developing Reusable Portals for Scripted Scientific

Codes‖. Proceedings of the First International Conference on e-Science and Grid

Computing (e-Science’05). IEEE Press. pp 1-6.

[23] Jason Novotny, Michael Russell, Oliver Wehrens.―GridSphere: An Advanced Portal

Framework‖. Proceedings of the 30th EUROMICRO Conference (EUROMICRO’04). IEEE

Press. pp 1-8.

[24] Marlon Pierce and Geoffrey Fox, Choonhan Youn, Steve Mock, Kurt Mueller, Ozgur

Balsoy. ―Interoperable Web Services for Computational Portals‖. Conference on High

Performance Networking and Computing. Proceedings of the 2002 ACM/IEEE conference

on Supercomputing. pp 1 - 12

[25] Rainer Weinreich, Thomas Ziebermayr. ―Enhancing Presentation Level Integration of

Remote Applications and Services in Web Portals‖. Proceedings of the 2005 IEEE

International Conference on Services Computing (SCC’05). IEEE Press. pp 1-8

[26] Oscar Díaz, Jon Iturrioz, Arantza Irastorza. ―Improving Portlet Interoperability

Through Deep Annotation‖. Proceedings of the 14th International World Wide Web

Conference. ACM Press. pp: 372-381

[27] Oscar Diaz. ―Portlet Syndication: Raising Variability Concerns‖. ACM Transactions

on Internet Technology, Vol. 5, No. 4, November 2005 pp 627–659.

[28] Mahesh Subramanian, Ali Shaikh, Omer Rana, Alex Hardisty y Edward C. Conley.

―Healthcare@Home: Research Models for Patient-Centred Healthcare Services‖. School of

Computer Science and Welsh e-Science Centre Cardiff University, UK. pp. 1-7. [En línea]

http://users.cs.cf.ac.uk/M.Subramanian/publications/Research_models.pdf. [Consulta:

Enero 2007]

[29] Deepti Kodeboyina y Beth Plale. ―Experiences with OGSA-DAI: Portlet Access and

Benchmark‖. Computer Science Department Indiana University. pp: 1-6. [En línea]

http://www-unix.mcs.anl.gov/~keahey/DBGS/DBGS_files/dbgs_papers/kodeboyina.pdf.

[Consulta: Enero 2007]

[30] Henri Naccache, Gerald. C. Gannod, y Kevin A. Gary. ―A Self-healing Web Server

Using Differentiated Services‖. Dept. of Computer Science & Engineering, Arizona State

University. Springer-Verlag Berlin Heidelber 2006. pp: 203-214.


106

[31] Sylvia C. Wrong, Richard M. Crowder, Nigel R. Shadbolt y Gary B. Wills.

―Knowledge Management for a Large Service-Oriented Corporation‖. School of

Electronics and Computer Science, University of Southampton, UK. In Proceedings of the

6th International Conference on Practical Aspects of Knowledge Management (PAKM),

Vienna, Austria, 30 Nov. 2006. pp: 1- 12.

[32] Miguel Ángel Conde, Jorge Carabias, Rosa María Martín, Inmaculada González, y

Francisco José García. ―Portlet-based architecture for a LMS: CLAYNET 2.0‖.

Departamento de I+D+i CLAY Formación Internacional. Virtual Campus 2006 Post-

proceedings. Selected and Extended Papers. pp: 181-194 [En línea]

http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-186/17.pdf. [Consulta:

Enero 2007]

[33] alzado.org, ―Servidores de portales: ¿usabilidad empaquetada?‖ [en línea]

<http://www.alzado.org/articulo.php?id_art=249> [Consulta: 1 julio 2006]

[34] Vignette Corporate. Frequently Asked Questions (FAQ). ―Support for WSRP and JSR

168‖. pp: 1-6.

[35] Sun Microsystems. ―Introduction to JSR 168—The Java Portlet Specification‖. pp: 1-

19.

[36] Sun Microsystems. ―Sun Java Studio Creator 2‖. [en línea].

<http://developers.sun.com/prodtech/javatools/jscreator/features/index.html> [Consulta: 25

julio 2006].

[37] BEA WebLogic. ―Building Portlets‖. [En línea].

<http://edocs.bea.com/workshop/docs81/doc/en/core/index.html>. [Consulta: 7 agosto

2006].

[38] IBM España. ―WebSphere Portlet Factory‖. [En línea]. <http://www-

306.ibm.com/software/info/ecatalog/es_ES/products/D558457Y86095X80.html?&S_TAC

T=none&S_CMP=none>. [Consulta: 7 agosto 2006].

[39] developers.sun. ―Article Overview of Sun Java Studio Enterprise 8‖. [En línea].

<http://developers.sun.com/prodtech/javatools/jsenterprise/reference/techart/jse8/jse8overvi

ew.html> [Consulta: 14 agosto 2006].

[40] Vignette. ―Borland JBuilder 2005 and Vignette Application Portal Leverage J2EE and

New Java Standards‖. [En línea].


107

<http://www.vignette.com/contentmanagement/0,2097,1-1-30-72-407-4596,00.html>

[Consulta: 14 agosto 2006].

[41] www3.imperial.ac.uk. ―¿Qué Es OracleAS Portal?‖. [En línea].

<http://www3.imperial.ac.uk/portalHelp2/ohw?navId=3&navSetId=_&locale=es&vtTopic

File=welchelp_hs_es/pbmwwdb.htm> [Consulta: 14 agosto 2006].

[42] Jennifer Pérez. ―Web Services‖. Departamento de Sistemas Informáticos y

Computación. Universidad Politécnica de Valencia. pp 1-15.

[43] Curbera Francisco, Duftler Matthew, Khalaf Rania, Nagy William, Mukhi Nirmal,

Weerawara Sanjiva. ―Unraveling the Web Services. An Introduction to SOAP, WSDL, and

UDDI.‖ March / April 2002. IEEE Internet Computing. pp 86-93.

[44] Apache Pluto. ―Welcome to Pluto‖. [en línea] <http://portals.apache.org/pluto/>

[Consulta: 10 enero 2007].

[45] Wikipedia. ―Tomcat‖. [En línea] <http://es.wikipedia.org/wiki/Tomcat> [Consulta: 12

Junio 2007]

[46] David Gould Studios. ―Definición de API‖. [En línea].

<http://www.davidgould.com/Glossary/Glossary.htm> [Consulta: 3 Junio 2007]