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 Daz.
Maestro en Ciencias de la Computacin
INSTITUTO TECNOLGICO DE ORIZABA

DIVISIN DE ESTUDIOS DE POSGRADO E INVESTIGACIN
DISEO Y CONSTRUCCIN DE UN PORTAL EMPRESARIAL UTILIZANDO LA TECNOLOGA DE PORTLETS
TESIS
QUE PARA OBTENER EL GRADO DE:
MAESTRO EN CIENCIAS EN CIENCIAS DE LA COMPUTACIN
PRESENTA
LIC. ENRIQUE RUIZ DAZ
DIRECTOR DE TESIS
DR. GINER ALOR HERNNDEZ
ORIZABA, VERACRUZ, MXICO. SEPTIEMBRE 2007
ndice
ndice .. ndice de figuras . Resumen . Introduccin ... Captulo I. Motivacin ..... 1.1. Introduccin 1.2. Antecedentes .. 1.3.1 Common Gateway Interface (CGI) 1.3.3. Active Server Pages (ASP) ... 1.3.4. Servlets .. 1.3.5. JavaServer Pages (JSP) . 1.4. Planteamiento del problema 1.5 Estado del arte .. 1.7. Resumen ..
ii vi
ndice de tablas ... viii ix xi
1 1 2
1.3. Evolucin de las tecnologas de informacin .. 5 5 1.3.2. PHP 6 7 8 8
1.3.6. Los Portlets 9 11 13
1.6 Propuesta de solucin ... 21 22
Captulo II: Tecnologa de portlets . 23 2.1 Introduccin . 2.2 Estndares JSR 168 y WSRP ... 23 23
2.2.1 Estndar JSR 168 (The Java Portlet Specification, la especificacin del portlet de Java) ... 2.2.2 Estndar WSRP (Web Services for Remote Portlets, servicios Web para portlets remotos) . 27 2.3. Ambientes de desarrollo con soporte para portlets . 2.3.1. Java Sun Studio Creator 2.3.2 WebLogic Workshop . 30 30 30 24
2.3.3. IBM WebSphere Portlet Factory .. 31 2.3.4. Sun Java Studio Enterprise 31 2.3.5. Borland JBuilder 2005 y la edicin de desarrollo de Borland del portal 32 de aplicacin Vignette 2.3.6. OracleAS Portal . 32 2.4 Resumen .. Captulo III. Componentes de la arquitectura del portal empresarial ... 3.1. Introduccin 3.2. Componentes de la arquitectura del portal empresarial .. 33
35 35 35
3.2.1 Modo portal de Internet .. 37 3.2.2. Modo Proxy del portal ... 38 3.2.2.1. Relacin entre servicios Web y portlets ... 3.2.2.2. Descripcin de los componentes ... 3.2.2.2.1. El analizador de mensajes SOAP .. 38 40 41
3.2.2.2.2. El selector de servicio 41 3.2.2.2.3. El contenedor de portlets ... 41 3.2.2.2.4. El invocador .. 3.2.2.2.5. El analizador de respuesta . 3.2.2.2.6. El constructor de respuestas .. 3.2.2.3. Funcionamiento de la arquitectura .. 3.3. Resumen . 42 42 44 44 45
Captulo IV. Prestaciones de servicios del portal empresarial ..... 46 4.1. Introduccin ... 46 4.2. Modo portal de Internet ... 46 4.2.1. Interfaz grfica del modo portal de Internet .. 46 4.2.2. Tecnologa de desarrollo para el modo portal de Internet . 47 4.2.3. Mtodos del contenedor de portlets para el modo portal de Internet 47 4.3. Modo Proxy . 55 4.3.1. Servicio Proxy AmazonBox .. 56 4.3.2. Servicio Proxy Horoscope . 60 4.3.3. Servicio Proxy Theaters 4.3.4. Servicio Proxy USAWeather 4.3.5. Tecnologa de desarrollo para el modo portal Proxy 61 63 65
4.4. Capas de prestaciones de servicios de la arquitectura del portal . 65 4.4.1. Capa de presentacin . 65 4.4.2. Capa de comunicacin ... 66 4.4.3. Capa de descubrimiento 4.4.4. Capa de servicio 4.4.5. Capa lgica 4.4.6. Capa de integracin ... 4.5. Resumen .. Captulo V. Casos de estudio ... 5.1. Introduccin 5.3 Caso de estudio: ayuda en la toma de decisin para la asistencia al cine 5.4. Fundamentos de la tecnologa de portlets que explican sus ventajas en sus servicios al usuario . 5.5. Resumen .. 77 78 67 68 68 69 70
72 72
5.2. Caso de estudio: una bsqueda de programacin de cines .. 72 74
Maestro en Ciencias de la Computacin 80 80
Captulo VI. Conclusiones ... 6.1. Conclusiones generales ...
6.2. Contribuciones de la tesis 82 6.3. Trabajo futuro .. 83 6.3.1. Caso de estudio propuesto en la implementacin imperiosa de un portal con un conjunto inicial de soluciones a travs de una arquitectura basada en portlets 6.3.2. Caso de estudio propuesto para obtener noticias de Java en alguno de los idiomas ms importantes Glosario .. Publicacin . Referencias . 85 84
87 90 91
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. Edicin de preferencias 26 Figura 2.3. WSRP y estndares que se relacionan . Figura 3.2. Portal empresarial en su modo portal de Internet Figura 3.4. Documento WSDL del servicio Web Horoscope web Services, para los clientes del portal en su modo Proxy 40 Figura 3.5. Documento WSDL del servicio Web Horoscope web Services, del proveedor externo del servicio para el portal en su modo Proxy ... Figura 4.1. El modo portal de Internet con la opcin activa All Portlets .. Figura 4.2 B. Representacin en UML del contenedor de portlets Figura 4.2 C. Representacin en UML del contenedor de portlets Figura 4.3. Mtodos 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. Representacin en UML de la API del portal para su modo Proxy . 56 Figura 4.5. Ejemplificacin, en caja negra, del empleo de los mtodos del documento WSDL para el servicio Proxy AmazonBox . 58 Figura 4.6. Ejemplo de invocacin de un mtodo, el mtodo getBook, del servicio Proxy AmazonBox . Figura 4.7. Ejemplo de ejecucin de un mtodo, el mtodo getBook, del servicio Proxy AmazonBox . 59 59 43 47 28 Figura 3.1. Aspecto general de la arquitectura ... 36 37 Figura 3.3. Arquitectura del portal en modo Proxy 39
Figura 4.2 A. Representacin en UML del contenedor de portlets 49 50 51
Figura 4.8. Ejemplificacin, en caja negra, del empleo del mtodo getHoroscope del documento WSDL para el servicio Proxy Horoscope .. 60 Figura 4.9. Ejemplo de invocacin del mtodo del servicio Proxy Horoscope que se denomina getHoroscope .. Figura 4.10. Ejemplo de ejecucin del mtodo del servicio Proxy Horoscope que se denomina getHoroscope . 61 Figura 4.11. Ejemplificacin, en caja negra, del empleo del mtodo getShowTimes del documento WSDL para el servicio Proxy Theaters . Figura 4.12. Ejemplo de invocacin del mtodo del servicio Proxy Theaters que se denomina getShowTimes ... Figura 4.13. Ejemplo de ejecucin del mtodo del servicio Proxy Theaters que se denomina getShowTimes ... Figura 4.14. Ejemplificacin, en caja negra, del empleo de los mtodos del documento WSDL para el servicio Proxy USAWeather ... Figura 4.15. Ejemplo de invocacin de un mtodo del servicio Proxy USAWeather que se denomina getWeatherByZipCode ... Figura 4.16. Ejemplo de ejecucin de un mtodo del servicio Proxy USAWeather que se denomina getWeatherByZipCode ... Figura 4.17. La arquitectura de portal en capas . 64 70 64 63 62 62 62 60
Figura 5.1. Portal con los primero cuatro portlets .. 73 Figura 5.2. El portlet Theaters en presentacin y en ejecucin .. 74 Figura 5.3. El portlet TheatersAndUSAWeather en su presentacin inicial al usuario Figura 5.4. El portlet TheatersAndUSAWeather en ejecucin .. 75 76
ndice de tablas
Tabla 1.1. Desventajas de las tecnologas de portales de la primera generacin ... Tabla 3.1. Descripcin de los servicios Web del portal . 10 36
Tabla 4.1. Mtodos del servicio Proxy AmazonBox .. 57
Resumen
Las tecnologas de portales de la primera generacin tales como CGI, PHP, ASP, Servlets, JSP, entre otros, presentaron desventajas para acceder a recursos e informacin que provienen de terceras partes, porque stos proceden de diferentes plataformas operativas, lenguajes de programacin y bases de datos. Para superar stas limitaciones se presentan las tecnologas de portlets. Estas tecnologas presentan un enfoque orientado a componentes y se basan en estndares. Esta tesis presenta el diseo y desarrollo de un portal empresarial usando las tecnologas de portlets y se aborda el problema de integracin de informacin. Dado que se requiere una solucin para la necesidad de encontrar un acceso consistente a fuentes de datos heterogneas y dispersas. El enfoque de solucin consiste en el desarrollo de una arquitectura de integracin de informacin usando portlets. Esta arquitectura presenta dos modos de operacin, modo portal de Internet y Proxy. Dicha arquitectura se prueba con una aplicacin 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 prestacin 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 heterogneas; y 2) adaptabilidad de portlets en fase de diseo y para los usuarios finales.
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 componentoriented and standardbased approach. This thesis presents the design and development of an enterprise portal by using portlets technologies. In this thesis, the problem of information integration is addressed. A solution for the necessity for finding a consistent access to heterogeneous and scattered data sources is required. The solution approach consists of the development of an information integration architecture by using portlets. This architecture shows two ways of operation, both Internet portal mode and Proxy mode. This architecture was tested with an application which is focused towards the entertainment industry. The main contributions of this work are: 1) a portlet-based architecture with different level services; and 2) a set of mechanisms which describe the services functionality described as portlets. Finally, the advantages of this proposal are: 1) able to access in stable way to different heterogeneous data sources; and 2) ability to customize portlets in design phase and for end users.
10
Introduccin
Esta tesis presenta el desarrollo de una arquitectura de integracin de informacin basada en portlets para un portal de segunda generacin. Para la validacin de esta arquitectura se exhibe el desarrollo de una aplicacin. Dicha arquitectura emplea portlets y servicios Web. Con ello, se adquiere las ventajas de la adaptabilidad y de un acceso consistente a fuentes de informacin dispersas y de naturalezas diversas en la infraestructura global de informacin. Esto es relevante porque se muestra que los portales de primera generacin basados en tecnologas tales como CGI, PHP, ASP, servlets, JSPs, entre otros presentan una arquitectura monoltica que compromete el desarrollo y mantenimiento. Estas desventajas se superan con la tecnologa de portlets. La arquitectura que se presenta posee dos modos de operacin, 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 travs de un servicio de intermediacin. El objetivo general que plantea esta tesis es el diseo y construccin de un portal empresarial con base en el desarrollo de una aplicacin basada en componentes Web, que se gestione por un contenedor de portlets para procesar peticiones y generar contenido dinmico. Los objetivos particulares son: (1) disear y construir la arquitectura de integracin para un portal empresarial a travs de portlets; y (2) establecer los mecanismos que permitan la personalizacin, la presentacin y la gestin de seguridad a travs de portlets. A su vez, las aportaciones de la tesis se establecen de la siguiente manera: (1) una arquitectura de integracin bajo diferentes niveles de prestacin de servicios; y (2) un conjunto de mecanismos que definen la funcionalidad de los servicios representados como portlets. A continuacin se presenta una breve descripcin de la estructura de la tesis. En el captulo I se presenta la motivacin de la tesis. Para este captulo, se muestran los antecedentes de Internet y se realiza una revisin de las tecnologas de los portales de primera y segunda generacin. Tambin presenta: el problema que trata la tesis, la revisin 11
del estado del arte, en el cual se compara la arquitectura propuesta contra la de trabajos semejantes y finalmente se explica la propuesta de solucin. En el captulo II se presenta la tecnologa de portlets. En este captulo se lleva a cabo una revisin del estndar JSR-168 para portlets locales y del estndar WSRP para portlets remotos. Adems, se muestra una revisin de los ambientes de desarrollo que soportan portlets. En el captulo 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 ms especficos que se describen con detalle. En el captulo IV se explican las prestaciones de servicios del portal empresarial para los dos modos de operacin del portal. Adems, se presenta la representacin en UML del contenedor de portlets y del modo Proxy. As tambin, se explican las capas de servicios de la arquitectura del portal. En el captulo V se presentan dos casos de estudio que permiten observar las ventajas de la arquitectura propuesta y se discuten los fundamentos tecnolgicos que permiten dichas ventajas. Finalmente, en el captulo VI se presentan las conclusiones, se muestran las contribuciones de la tesis y se proponen trabajos futuros.
12
Captulo 1. Motivacin
1.1. Introduccin
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 agrupacin de varios sistemas, procesos o sitios para visualizarse en una sola pgina de portal. Los portales permiten apoyar a las empresas. Con un portal empresarial, las empresas estn en condiciones de ofrecer a sus empleados, clientes y socios una manera segura de acceder a toda la informacin y servicios necesarios para interactuar y colaborar con su organizacin. La motivacin de esta tesis est en potenciar el rol del portal empresarial a travs del desarrollo de un portal que acceda exitosamente a fuentes de datos dispersas y heterogneas. La obtencin de este objetivo es difcil con las tecnologas para los portales de primera generacin dado que stas presentan importantes desventajas. Estas consisten en que los portales de primera generacin requieren de enormes esfuerzos de programacin e inversin en tiempo para acceder a recursos e informacin provistos por terceras partes. En consecuencia, surge la tecnologa para portales de segunda generacin basada en portlets. Estos permiten acceder a informacin a travs de integrar aplicaciones heterogneas 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 tecnologa de portlets con sustento en una arquitectura apropiada permitir el desarrollo de un portal empresarial que mejore en la empresa su interaccin inter-organizacin e intra-organizacional. Este primer captulo presenta una breve revisin de los antecedentes de Internet, tambin se realiza una revisin de las tecnologas para portales de primera y segunda generacin. Adems, se establece cul es el planteamiento del problema a resolver y se hace una revisin del estado del arte. Finalmente, se presenta una propuesta de solucin para integrar informacin a travs del diseo y construccin de un portal empresarial utilizando la tecnologa de portlets.
13
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 ms se destaca es el TCP/IP (Transmission Control Protocol/Internet Protocol, protocolo de control de transmisin / protocolo de Internet ). El nombre de Internet tambin se usa como sustantivo comn y por tanto en minsculas para designar a cualquier red de redes que use las mismas tecnologas que Internet, independientemente de su extensin o de que sea pblica o privada [1]. Cuando se dice red de redes se hace referencia a que es una red que se forma por la interconexin de otras redes menores [1]. Al contrario de lo que se piensa comnmente, Internet no es sinnimo 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 informacin mucho ms reciente que emplea Internet como medio de transmisin [1]. Algunos de los servicios disponibles en Internet aparte de la Web son el acceso remoto a otras mquinas 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 electrnico) que se basa en texto y se utiliza para el intercambio de mensajes de correo electrnico entre computadoras o distintos dispositivos como celulares, entre otros, boletines electrnicos tales como news o grupos de noticias, conversaciones en lnea tales como IRC (Internet Relay Chat, protocolo de comunicacin en tiempo real basado en texto) [1]. Por otra parte, en la historia de Internet se tiene que en 1972 se realiz la primera demostracin pblica de ARPANET (Advanced Research Projects Agency Network, agencia de red de proyectos de investigacin avanzados), una nueva red de comunicaciones que financi la DARPA (Defense Advanced Research Projects Agency, agencia de investigacin de proyectos avanzados de defensa) que funcionaba de forma distribuida sobre la red telefnica conmutada. El xito de esta nueva arquitectura sirvi para que en 1973, la DARPA iniciara un programa de investigacin sobre posibles tcnicas para
14
interconectar redes (stas se enfocaron al trfico de paquetes) de distintas clases. Para este fin, se desarrollaron nuevos protocolos de comunicaciones que permitieron este intercambio de informacin de forma "transparente" para las computadoras que se conectaron. De la filosofa 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 ao, 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 investigacin a Internet. Por otra parte, se centr la funcin de asignacin de identificadores en la IANA (Internet Assigned Numbers Authority, agencia de asignacin de nmeros 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, fundacin nacional de ciencias) comenz el desarrollo de NSFNET (National Science Foundation's Network, red de la fundacin nacional de ciencias) que se convirti en la principal red en rbol de Internet que se complement despus con otras redes en los Estados Unidos de Amrica. Paralelamente, otras redes troncales en Europa, tanto pblicas como comerciales, junto con las americanas formaron el esqueleto bsico ("backbone") de Internet. En 1989 con la integracin de los protocolos OSI (Open Systems Interconnection, interconexin de sistemas abiertos) en la arquitectura de Internet, se inici la tendencia actual de permitir no slo la interconexin de redes de estructuras diferentes, sino tambin la de facilitar el uso de distintos protocolos de comunicaciones. En el CERN (en francs, Conseil Europen pour la Recherche Nuclaire, consejo europeo para la investigacin nuclear) de Ginebra, un grupo de fsicos 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, estndar generalizado de lenguaje de marcado). En 1990 el mismo equipo construy el primer cliente Web que se llam WorldWideWeb (WWW) y el primer servidor Web [1].
15
Comnmente las pginas Web mostraban informacin que no cambiaba. Esta forma esttica de mostrar informacin fue bastante eficiente puesto que la pgina se creaba una vez y se presentaba. Cuando era necesario se hacan mnimos cambios y ya estaba lista otra vez. Pero rpidamente surgi la necesidad de interactuar con el usuario y de adaptar la informacin a sus necesidades, o mostrar informacin que se toma de bases de datos que frecuentemente cambian. Con la forma que haba de crear documentos HTML estticos era difcil mantener esas pginas si se queran construir con cierto dinamismo. Por ello aparecieron las tcnicas de generacin dinmica de pginas. Estas tcnicas permiten la actualizacin de pginas aunque se muestra informacin que cambia frecuentemente y tambin posibilitan formas de establecer comunicaciones que se personalizan con los usuarios [2]. Adems, anteriormente era difcil desarrollar un sitio Web que ofreciera a los usuarios la posibilidad de acceder varios sistemas a partir de una sola pgina. Los sistemas estaban drsticamente separados uno del otro y requeran de una gran inversin de tiempo y trabajo para ponerlos a trabajar juntos en una nica pgina 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 agrupacin de varios sistemas, procesos o sitios que se visualizan todos en una sola pgina de portal. Los portales pueden proveer servicios adicionales, un ejemplo es la seguridad en una autenticacin simple y la capacidad de personalizar [3]. Un portal de Internet es un sitio que se enfoca en resolver necesidades especficas de un grupo de personas. Un portal de Internet puede ser un centro de atencin 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 electrnicos, motores de bsqueda, evaluaciones en lnea, dar capacitacin a distancia, entre otros [4]. Existen dos modalidades de portales: (1) portales horizontales, que tambin se llaman portales masivos o de propsito general, se dirigen a una audiencia amplia, tratando de llegar a toda la gente con muchas cosas. Como ejemplo de portales de esta categora estn AOL, AltaVista, Lycos, Yahoo, MSN; y (2) portales verticales, se dirigen a usuarios
16
para ofrecer contenido y comercio dentro de un tema especfico como puede ser un portal de msica, un portal de finanzas personales o de deportes. Como ejemplos de esta categora se encuentran CNET, SportsLine.com. [4] Adems, en [5] se establece que los portales varan de acuerdo a los usuarios que sirven y los servicios que ofrecen: (1) portales pblicos, tales como yahoo presentan informacin de varias fuentes, aplicaciones, y gente, ofreciendo sitios Web que se personalizan para usuarios arbitrarios, (2) portales empresariales, dan a los empleados acceso a informacin especfica de la organizacin 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 especficas. A continuacin se presenta la evolucin de las diversas tecnologas para portales.
1.3. Evolucin de las tecnologas de informacin.

En esta seccin se presentan las tecnologas para portales de la primera generacin hasta la tecnologa para portales de la segunda generacin. Esta ltima, basada en portlets. Primeramente, se presenta la tecnologa para portales ms antigua, sta es la tecnologa CGI. A continuacin, se presentan las tecnologas que posteriormente surgieron tales como PHP, ASP, Servlets, JSP y se concluye con la tecnologa de portlets. En el recuento de estas tecnologas se muestra una breve descripcin de stas, sus ventajas y desventajas particulares.
1.3.1 Common Gateway Interface (CGI)
Los primeros servidores HTTP no incluan ningn mecanismo para generar respuestas dinmicamente, 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 tecnologa CGI es el 17
rendimiento, ya que por cada peticin se crea una nueva copia del programa en la memoria del servidor. As, si acceden muchos usuarios de forma simultnea se produce una disminucin en la eficiencia de dicho servidor [6]. Para solucionar las deficiencias de la tecnologa CGI aparecieron nuevas tecnologas que proporcionan ms beneficios.
1.3.2. PHP
PHP es un lenguaje de programacin que se usa generalmente para la creacin de contenido para sitios Web. El nombre es el acrnimo recursivo de "PHP (Hypertext Preprocessor, preprocesador de hipertexto)" inicialmente PHP Tools (herramientas PHP) o Personal Home Page Tools (herramientas de pgina personal) y se trata de un lenguaje que se interpreta para usarse en la creacin de aplicaciones para servidores o creacin de contenido dinmico para sitios Web [6]. PHP tiene las siguientes ventajas: (1) est pblicamente disponible, (2) es sencillo de aprender, (3) posee numerosas libreras de funciones que permiten manejar mltiples 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 Programacin Orientada a Objetos (POO) en versiones anteriores a la versin cinco de PHP, careca de potencia [8]. El mayor problema de la POO consista en que cada vez que se asignaba una variable que contena un objeto a otra variable o se transmita un objeto por parmetro en una funcin, se realizaba una copia (un clon) de ese objeto y quedaba a disposicin del programa en la nueva variable o parmetro. 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 versin actual de PHP (versin cinco) se hace uso de los manejadores de objetos (Object handles), que son una especie de dato de tipo puntero que seala hacia los espacios en memoria donde residen los objetos. Cuando se asigna un manejador de objetos o se pasa como parmetro en una funcin, se duplica el propio object handle y no el objeto en si [9].
18
Otro inconveniente de PHP est en relacin a cierta complejidad en sus mtodos de instalacin ya que se puede instalar PHP sobre un servidor bien como un interprete CGI o como un mdulo de Apache (ste es un servidor Web). Cada mtodo tiene sus ventajas y desventajas. Si se instala PHP como un intrprete CGI ofrece la oportunidad de tener tantos procesos ejecutndose como identificadores de usuarios diferentes bajo anfitriones virtuales. Cuando PHP se instala como un mdulo Apache se debe elegir si ser un mdulo esttico o dinmico. Un mdulo esttico es una compilacin previa de PHP con Apache; mientras que un mdulo dinmico se caracteriza por cargarse sin necesidad de compilar Apache. Un mdulo esttico tiene la ventaja de incrementar el desempeo, pero cuando se desea actualizar se tiene que recompilar tanto al PHP como al Apache. Con un mdulo dinmico, se pierde desempeo. Sin embargo, las correcciones y actualizacin del PHP son mucho ms fciles cuando se instala como un mdulo dinmico [10].
1.3.3. Active Server Pages (ASP)
ASP es una tecnologa que desarroll Microsoft que aporta capacidad operativa a las pginas Web, combinando HTML con un lenguaje de secuencia de comandos o lenguaje script. Los lenguajes que ms se usan actualmente para programar el cdigo script dentro de las pginas ASP son VBScript y JScript, aunque tambin se pueden utilizar otros como Python. El cdigo contenido en estos scripts se ejecuta en el servidor y el navegador del cliente tan slo recibe pginas HTML, lo que convierte a ASP en una tecnologa vlida para cualquier tipo de navegador. ASP utiliza la tecnologa que se denomina ISAPI (Internet Server Aplication Program Interface, interfaz de programa de aplicacin de servidor de Internet). Una aplicacin ISAPI se basa en libreras de enlace dinmico que se ejecutan en el mismo espacio de direcciones que el servidor Web, de manera que soportan numerosas peticiones simultneas 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 slo estn disponibles para sistemas operativos Windows [2].
19
M.C. Enrique Ruiz Daz. 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 especficas para requerimientos HTTP [11]. Sus ventajas consisten en que: (1) los servlets son independientes de la plataforma (porque estn escritos en Java), son independientes del servidor y adems 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 mltiples peticiones de servicios, por esa razn esta alternativa es ms rpida que el CGI tradicional al no necesitar lanzar un nuevo proceso cada vez que se realiza una peticin [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 aplicacin ya que el cdigo de procesamiento y los elementos de HTML estn juntos, (2) cambiar la apariencia de una aplicacin o agregar soporte para nuevos tipos de cliente, por ejemplo WML (Wireless Markup Language, lenguaje de marcado de dispositivos mviles) requiere la actualizacin y recompilacin del cdigo del servlet; y (3) es difcil aprovechar herramientas de desarrollo de pginas Web (editores de HTML) al disear la interfaz. Si esas herramientas se utilizan para desarrollar la estructura del documento el cdigo HTML que se genera debe embeberse en el cdigo del servlet. Este proceso consume mucho tiempo, es propenso a errores y extremadamente tedioso [13].
1.3.5. JavaServer Pages (JSP)
La tecnologa JSP es una extensin de los servlets que desarroll Sun como alternativa a la tecnologa ASP de Microsoft; bsicamente, permite la introduccin de cdigo Java dentro del cdigo HTML, dicho cdigo Java puede llevar a cabo diversas tareas, como por ejemplo utilizar servicios que se proporcionan por servlets [12]. Los
20
elementos JSP se pueden usar para una gran variedad de propsitos como recuperar informacin de una base de datos o registrar preferencias del usuario [13]. La ventaja de JSP en comparacin a los servlets es que es una extensin de la tecnologa Java servlets; mientras que estos ltimos tienen que mantener plantillas de cdigo HTML dentro del programa, JSP contiene estas plantillas dentro de las propias pginas [14]. En comparacin con otras tecnologas, su ventaja es la independencia de la plataforma tanto cliente como servidor. Por un lado, la utilizacin de cdigo Java garantiza la portabilidad de la aplicacin para su ejecucin en cualquier servidor que contenga una mquina virtual Java. Esta es una ventaja sustancial frente a otras tecnologas similares, como por ejemplo Active Server Pages (ASP). En el caso del cliente, al recibir slo pginas HTML hace que sea compatible con cualquier navegador. Sin embargo, JSP no permite satisfacer el requerimiento de acceso a recursos e informacin que se proporcione por terceras partes, por ejemplo, de un proveedor de noticias.
1.3.6. Los Portlets
La tecnologa para portales de segunda generacin se constituye por portlets. stos son componentes Web que se controlan por un contenedor capaz de generar contenido dinmico e interactuar con los usuarios a travs del portal [15]. Un portlet provee
contenido a su contenedor de portal que lo invoc para efectos de despliegue de la informacin en una pgina de portal. El contenido que se genera por un portlet se conoce como fragmento o cdigo de fragmento. Este es el cdigo HTML que se gener a partir del cdigo 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 funcin del mecanismo de acceso o a la informacin a la que tienen acceso, (2) un portlet debe verse como un encapsulado de una aplicacin Web para poder utilizarse como un componente dentro de un portal [15]; y (3) un contenedor de portlets maneja mltiples solicitudes a un portlet utilizando las mismas instancias de una clase portlet, invocndolas en diferentes instancias de ejecucin a travs de los mismos mtodos [3], con la eficiencia y economa que ello implica. Sin embargo, en
21
[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 tecnologas de los portales de primera generacin, 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 tecnologas, es decir, son monolticos. Mientras que los portlets adems de que constituyen componentes Web con las ventajas que esto implica, se basan en las especificaciones JSR 168 (Java Specification Request, especificacin de portlet de Java) y WSRP (Web Services for Remote Portlets, servicios Web para portlets remotos) que son de aceptacin creciente entre los proveedores de contenidos y aplicaciones Web lo cual permite apoyar a portales como intermediarios mltiples para alcanzar una enorme de usuarios finales, que de otra manera no sera posible. A continuacin, en la tabla 1.1 se presenta una sntesis de las desventajas particulares de las tecnologas para portales de primera generacin. cantidad
Tecnologa CGI
Desventaja particular Ejecuciones pesadas para el microprocesador. Cada peticin 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 estn disponibles slo en sistemas operativos Windows.
PHP
Complejidad en sus mtodos de instalacin. Adems, la programacin orientada a objetos en versiones anteriores (a la versin cinco) careca de potencia.
Servlets
Requiere mantener plantillas de cdigo HTML dentro del programa Java. Esto hace a la tecnologa compleja y difcil de entender.
JSP
Como las dems tecnologas de portales de primera generacin. JSP no permite acceder a recursos e informacin provistos por terceras partes.
Tabla 1.1. Desventajas de las tecnologas de portales de la primera generacin.
22
1.4. Planteamiento del problema

El integrar recursos e informacin empresarial propia y de terceras partes en el desarrollo de un portal de segunda generacin requiere abordar un problema de integracin de informacin. 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 programacin o modelos de programacin, entre otros. Considrese 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 previsin del clima. Una solucin para este escenario se describe en la figura 1.1: un portlet de recursos humanos y un portlet de previsin del tiempo que se ejecuta localmente en el servidor del portal y con acceso a servicio Web remoto para obtener la informacin requerida, es decir, el servicio Web provee datos y la capa de presentacin se implementa en portlets especficos [16].
Portlet del clima Portal del empleado Portlet de R. H.
Servicio Web del clima Servicio Web de R. H.
Figura 1.1. Portlets locales que usan servicios Web remotos.
El portlet de recursos humanos usa un servicio Web de recursos humanos para calcular la variable pago. Por consiguiente, despliega un formulario para consultar los datos de entrada, por ejemplo, el identificador de empleado (id). Cuando el empleado provee los datos para el portlet de recursos humanos, invoca el servicio Web de recursos humanos para calcular la variable pago que se basa sobre esos datos. Recibe el resultado desde el servicio Web y lo despliega como un fragmento de pgina. El portlet de previsin del
23
tiempo despliega la previsin del tiempo para ciudades configurables y permite al usuario seleccionar las localidades en un modo edit (edicin). Cuando el portlet de previsin del tiempo se invoca durante la carga de la pgina, solicita la ms reciente previsin del tiempo para las localidades seleccionadas del servicio Web de previsin del tiempo y despliega un fragmento de pgina con aquellas previsiones del tiempo. Este enfoque solamente funciona si todos los portlets se instalan fsicamente en el portal del empleado. El proceso de hacer nuevos portlets disponibles es tedioso y caro; la capa de presentacin debe redesarrollarse para cada portal. Para integrar la informacin de recursos humanos en el portal usando portlets locales, o el departamento de recursos humanos podra 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 podra implementar el portlet de recursos humanos de acuerdo a la descripcin de interfaz del servicio Web de recursos humanos, similar esfuerzo se requerira para el portlet de previsin del tiempo. Obviamente, sera mucho ms conveniente si los servicios Web de recursos humanos y previsin del tiempo incluyen lgica de aplicacin y presentacin y ellos mismos producen fragmentos de marcado que son fciles para agregar al portal consumidor, como se muestra en la figura 1.2 [16].
Portlet Proxy Portal del empleado Portlet Proxy
Portlet Clima
Servicio Web del clima Servicio Web de R. H.
Portlet R. H.
Figura 1.2. Un portal que usa servicios Web de portlets remotos
En vez de proveer slo datos escuetos o funciones de negocios simples que todava requieren especial interpretacin en el lado del portal, WSRP tiene orientacin al usuario y
24
son servicios Web interactivos que incluyen la presentacin. Ellos son fciles de agregar y se invocan a travs de una interfaz comn usando un cdigo Proxy de portlet genrico que se construye en el portal. Ningn cdigo de portlet especial necesita instalarse en todos los portales y se evita la re-implementacin de la capa de presentacin en cada portal. Los portlets remotos hacen la tarea ms accesible porque dichos portlets pueden aadirse dinmicamente al ambiente, y beneficiar a los usuarios a travs de tener ms servicios disponibles de una manera oportuna. Se pueden agregar servicios de portlet remotos en un portal usando su interfaz de usuario de administracin de portal para encontrarlos y unirlos con poco esfuerzo. Como resultado, el portal crea nuevos Proxis de portlets genricos que se unen a servicios Web de portlets remotos para que estn disponibles a los usuarios en la misma manera que los portlets locales. Sin embargo, aunque los portlets se basan en estndares que abordan el problema de la arquitectura monoltica de los portales de la primera generacin, el estudio del estado del arte muestra la necesidad de esfuerzos para crear plataformas de integracin de informacin que satisfagan diversos sistemas de informacin y las tecnologas que apoyan estos esfuerzos.
1.5 Estado del arte

Los portlets son componentes Web que constituyen la tecnologa para el desarrollo de los portales de la segunda generacin. Los Portlets son elementos dinmicos de creacin de contenidos. Presentan y suman informacin de una o varias fuente de datos. Generan html y xml (es decir, documentos digitales a travs de estos lenguajes de marcado) en un rea que se muestra dentro de la pgina del portal. Son reutilizables y pueden personalizarse. Para el desarrollo de portales empresariales actualmente existen algunos trabajos que se orientan hacia la conformacin y administracin de catlogos de portlets. Bellas [17] argumenta que los portales de primera generacin tienden a presentar una arquitectura monoltica de software que compromete el desarrollo y el mantenimiento del portal. No obstante, dos estndares propuestos en otoo de 2003 los servicios Web para portlets remotos (WSRP) y la especificacin java de portlets abordan estos problemas. 25
En octubre de 2003, la comunidad Java desarroll la primera versin de la especificacin java de portlets (JSR 168), estandarizando una API de Java para los portlets compatibles WSRP que se pueden desplegar en cualquier contenedor estndar de portlet en Java. En contraste a los portales de primera generacin, los portales de segunda generacin permiten a los usuarios crear una o ms pginas personales que se integran por portlets aplicaciones mini Web interactivas- locales o remotas al portal. Los portales de segunda generacin 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 descripcin en detalle de tipos de portales y servicios. En donde los portales varan de acuerdo a los usuarios que sirven y los servicios que ofrecen. Dentro de esta descripcin se encuentran: (1) portales pblicos, (2) portales empresariales, (3) portales de mercado; y (4) portales especializados. Un aspecto importante en el desarrollo de estas aplicaciones es la tecnologa de informacin que permite implementar servicios comunes tales como: (1) la agregacin de contenido que provee contenido de diferentes fuentes para diferentes usuarios, (2) la agrupacin de contenido que recolecta contenido de diferentes fuentes, (3) la ayuda mltiple que provee contenido para diferentes canales de interaccin, (4) servicio nico sign-on que permite recuperar informacin de usuarios especficos sin requerir autentificacin de usuario cada vez, (5) administracin de portal que determina cmo los usuarios ven el portal; y (6) los usuarios pueden tpicamente subscribirse ellos mismos a portales Web pblicos. Chihcheng et. al. [18] propone que es necesario crear una plataforma de integracin para sistemas de aprendizaje. Se destacan cuatro dificultades en los sistemas de aprendizaje e-learning actuales. Estas dificultades son la raz de la causa del actual desaprovechamiento de sistemas de aprendizaje e-learning monolticos; estas dificultades son: (1) interoperabilidad de sistemas de aprendizaje e-learning, (2) colaboracin de objetos de aprendizaje, (3) nivel de presentacin integracin 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 presentacin de objetos compartidos e-learning desde otros sistemas. Tambin se propone a BPEL4WS (Business Process Execution Language for Web Services, Lenguaje de ejecucin de procesos de negocios para servicios
26
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 preparacin de curso y la ejecucin para proveer cuadros claros de cmo 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 tecnologa 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 mltiples puntos de entrada a recursos de computacin proporcionando acceso a herramientas grid y servicios, lo que facilita la barrera de entrada a la computacin que se basa en Grids para conducir investigaciones cientficas. Grid Portal Toolkit Versin 3.0 (GridPort) aborda este problema proporcionando un conjunto de capacidades para usar recursos de computacin a travs de una API para construir portales Grid y aplicaciones sobre la infraestructura Grid. GridPort agrega servicios grid provistos por otro software grid, aade servicios grid adicionales y presenta una API para desarrolladores. GridPort provee informacin y servicios interactivos para portal y aplicaciones. Usa servicios informativos para suministrar computacin que se distribuye y que se relacionan de numerosas tecnologas Grid. El repositorio de informacin GridPort (GPIR) almacena y archiva datos, proporcionando la actualizacin y el historial de datos a travs de servicios Web. Galligan et. al. [20] expone que cierta organizacin adquiri una suite de portal invirtiendo un alto costo y se propuso obtener un rpido retorno de inversin mientras el desarrollo del portal estaba en curso. Para esto, se utiliz una metodologa y modelo de ciclo de vida para ayudar al proceso de desarrollo. El enfoque facilit dos rutas de tecnologa. La primera fue para el rea de integracin de portal. Esta rea involucr la consolidacin de aplicaciones distribuidas existentes con el propsito de mejorar eficientemente a travs de funcionalidades tales como flujos de trabajo que se organizaron y procesos de negocios que se automatizaron. La segunda ruta se enfoc ms 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 travs del desarrollo eficiente por medio de la entrega de servicios que incrementaron el ingreso.
27
Puschmann et. al. [21] plantea que los portales de proceso soportan redes de negocios inter-organizacionales. Ellos definen la funcin y contenido sobre la base de procesos de cliente y los hacen disponibles a travs 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 mayora de negocios est todava en comienzos. Se sugiere que una arquitectura consistente y modelos de integracin pueden ayudar a los negocios con la introduccin de portales de procesos. Los portales integran diferentes funciones, mayormente aplicaciones heterogneas y las sita en el contexto de procesos de negocios especficos. En el futuro, una empresa proveer a sus clientes todos los servicios que ofrece. Estos servicios pueden estar disponibles interna o externamente a travs de los portales de: (1) empleado (B2E), (2) proveedor (B2B), (3) cliente (B2C); y distribuidor (B2B). Beeson et. al. [22] presenta un nuevo portal para ejecutar cdigo numrico cientfico sobre el Grid. Se hace particular nfasis en el re-empleo y la portabilidad en los portlets. Se encontr que el estndar JSR 168 es adecuado para crear portlets portables. Para portales que se forman de muchos portlets se presenta un sistema de comunicacin portable. La promesa de la computacin que se basa en Grid ofrece a los investigadores acceso transparente a recursos de computacin en Internet. El desarrollo de portlets Grid es una tarea desafiante porque la tecnologa est cambiando rpidamente. Para que la infraestructura Grid se explote, se considera la necesidad de crear interfaces fciles de usar. El re-uso es fundamental para satisfacer la necesidad de un rpido 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 estndares que se basan en portal para el fcil desarrollo de componentes Web que se llaman portlets. Los portlets se definen por una API estndar 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 coleccin de portlets y una librera avanzada de interfaz de usuario que permite a los desarrolladores de aplicaciones implementar fcilmente nuevos portlets. El framework (4) de
28
GridSphere provee un conjunto de portlets que ofrecen la funcionalidad bsica requerida para el re-uso. Algunos de los portlets provistos son: (1) login, (2) salir del sistema, (3) determinar seleccin de idioma, (4) proveer una interfaz para un nuevo usuario de portal, (5) la habilidad para asignar / revocar roles de usuarios, (6) administracin de usuarios, (7) proveer la habilidad a los usuarios de editar informacin personal; y (8) suscripcin de portlets. Pierce et. al. [24] plantea que los portales Web se disearon para simplificar el acceso a diversos conjuntos de recursos de computacin de alto desempeo, tpicamente a travs de herramientas Grid. Una limitacin importante de estos portales es la falta de servicios interoperables y reutilizables. Con base en esto, se presenta una descripcin de esfuerzos de investigacin 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 travs 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 (informacin) que interacta con objetos de datos XML. Weinreich et. al. [25] expone que los portales Web son un medio para la integracin del nivel de presentacin de aplicaciones de empresa y servicios. Se describe un enfoque para aumentar la integracin del nivel de presentacin en portales Web soportando comunicacin entre componentes del nivel de presentacin. Este enfoque se basa en estndares 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 tambin usarse para mejorar la integracin de componentes existentes de presentacin. El enfoque de este trabajo se motiv por la integracin de requerimientos que relacionan instituciones financieras en Austria, quienes necesitaban integrar aplicaciones y servicios que se ofreca fsicamente y organizacionalmente en separados centros de cmputo con diferente infraestructura de servidor de hardware y software. El enfoque se basa sobre la especificacin de portlet y sobre la especificacin WSRP. La especificacin de portlet define un componente de modelo de presentacin (portlets) en Java. Un servidor
29
M.C. Enrique Ruiz Daz. de portal manejable JSR 168
Maestro en Ciencias de la Computacin tpicamente se implementa sobre la base de una Web
manejable J2EE o servidor de aplicacin. Daz et. al. [26] plantea que la mayora de los frameworks de portal soportan actualmente los portlets. Sin embargo, no hay todava una respuesta definitiva para la interoperacin del portlet con lo cual el flujo de datos desde un portlet a otro cercano. Se discute que stas limitaciones se pueden vencer a travs de usar anotaciones tcnicas profundas. Proveyendo marcado adicional sobre servicios de fondo, esfuerzos de anotacin profunda para interactuar con estos servicios fundamentales. Se consideran anotaciones profundas como validacin particular para interoperacin 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 interoperacin del portlet. Diaz et. al. [27] argumenta que la variabilidad de demandas para portlets se encamina a ser ms severa que para otra clase de componentes de software que se debe tanto al sensitivo tema que encapsulan (esto es la presentacin) y la necesidad de personalizacin 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 evolucin paralela de todos los aspectos de una aplicacin Web mejorando pasos de desarrollo y reduciendo la oportunidad de conflictos. Este enfoque es un paso en la misma direccin a la que se dirige el trabajo de [27]. El cual se prob sobre una aplicacin de franquicia de una gran compaa de franquicia de cosmticos. Los portlets se usarn (como trabajo futuro) para soportar el catlogo de cosmticos. Este catlogo se produjo por la compaa matriz y se despleg en los portales de los socios comerciales. Sin embargo, cada franquicia socia necesit aadir algunos datos que se personalizaron (por ejemplo, precios y recomendaciones se fijaron de una manera que se apoy en el socio comercial).
30
A continuacin se presenta, brevemente, la problemtica que motiv el desarrollo de otras arquitecturas y una breve descripcin de estas arquitecturas. Adems, se analiza brevemente las diferencias de cada una de estas arquitecturas contra la propuesta en este trabajo, que ms adelante se describe. En el anlisis de estas diferencias, dado que el uso de portlets y del servidor de portal son elementos tpicos 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 investigacin que implementa un prototipo de entrada o salida de datos a travs de dispositivos mviles y/o servidores de red dedicados para uno o ms motores de anlisis de datos. Su arquitectura consta de un servidor de portal que provee una interfaz segura y adaptable entre el usuario final experimental (clnicas, 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. Adems, consta de un servidor de procesos y una base de datos para almacenar informacin del paciente en una localidad geogrfica particular. En nuestra propuesta, el dominio de aplicacin es diferente. Adems, nuestro enfoque no presente algn tipo de middleware. En [29] se presenta una experiencia en diseo y construccin 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 extensin para el marco de trabajo OGSA a travs de permitir el acceso y la integracin de datos que se controlan en fuentes de datos heterogneas. 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 implementacin 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 implementacin de referencia middleware permitiendo acceso y control para fuentes de datos externas, entre otros. Este trabajo se enfoca ms al rea de computacin grid que utiliza los servicios grid, mientras que nuestra propuesta se sita en el cmputo 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 nocin de servicios diferenciados (por ejemplo, servicios que proveen un
31
comportamiento comn con calidad de servicio variable) para sobrevivir a cargas de trfico inesperadas y disminucin 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 mquinas separadas. En su framework, el servidor de portal se crea de un sistema de hospedaje de portal, supervisin automtica 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 aplicacin. En [31] se indica la problemtica de una corporacin en la cual se acumula un largo nmero de documentos de inters 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 aplicacin. Su arquitectura emplea los estndares 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 autentificacin y flujos de trabajo. La interfaz de usuario la forman de una serie de portlets. Sus portlets acceden a uno o ms servicios Web. Este trabajo se sita ms en el uso de tcnicas de recuperacin de informacin 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 educacin 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 ms alto. Sus portlets engloban una serie de clases que cumplen con la especificacin JSR 168 y con un conjunto de elementos JSP. Estos elementos se gestionan por el contenedor de portlets. Los portlets de ClayNet tambin 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 estndares para portlets. El enfoque que presenta esta
32
Maestro en Ciencias de la Computacin en la
tesis utiliza WSRP en combinacin con JSP en vez de JSR 168. Finalmente,
propuesta de esta tesis no se utiliza una base de datos para la persistencia de la informacin.
1.6 Propuesta de solucin

Las empresas buscan los beneficios de la distribucin de informacin a travs 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, adems de facilitar la colaboracin con los empleados y proveedores. En esta direccin, el problema a resolver en esta tesis es la necesidad de integrar informacin y recursos empresariales propios y de terceras partes en el desarrollo de un portal de segunda generacin. Esta integracin requiere superar limitantes tales como la dependencia de la plataforma, modelos de desarrollo y lenguajes de programacin que se usen. Con esta finalidad el objetivo general de este trabajo es desarrollar un portal empresarial con base en el desarrollo de una aplicacin basada en componentes Web que se gestionen por un contenedor de portlets que procese peticiones y genere contenido dinmico. En consecuencia, la hiptesis establece que con la utilizacin de la tecnologa de informacin Open Source se llevar a cabo lo que determina el objetivo general y que el uso de la tecnologa Open Source dar al sistema a desarrollar la caracterstica de la portabilidad. Asimismo se presenta una arquitectura que permite la integracin de aplicaciones y recursos a travs de la tecnologa de portlets. Esta arquitectura de integracin se compone por capas y plantea: (1) qu servicios provee cada capa, (2) cmo funcionan entre s los componentes de cada capa; y (3) cmo interactan 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 especficos: (1) desarrollar el conjunto de portlets para la arquitectura de integracin para el portal empresarial; y (2) permitir la personalizacin, la presentacin y la gestin de seguridad a travs de los portlets. 33
Finalmente, las aportaciones originales del presente trabajo son: (1) una arquitectura de integracin bajo diferentes niveles de prestacin 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 captulo, se present una revisin breve de la historia de Internet y de las tecnologas para portales de la primera generacin. Se argument que las empresas requieren ofertar sus productos y servicios a travs de portales, y que para el desarrollo de los portales de la primera generacin se emplearon tecnologas tales como: CGI, PHP, ASP, servlets, JSP, entre otras. Para cada una de estas tecnologas, se mostraron sus desventajas particulares. Y se argument que todas las tecnologas para portales de primera generacin en su conjunto, tienen la desventaja de que crear portales monolticos. Como consecuencia a lo anterior, se present a la tecnologa de portales de segunda generacin, 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 integracin de informacin. Este problema tiene importancia porque se trata de informacin que no tan solo proviene de la misma organizacin en cuestin, sino de entidades que operan con tecnologas de diversas naturalezas. En el estado del arte, se mostraron trabajos de investigadores en relacin a la tecnologa 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 solucin. En sta, se incluy respuestas a cuestiones bsicas de la tesis, tal como el objetivo general y los objetivos particulares de la misma, la hiptesis y las contribuciones, entre otras.
34
Captulo 2: Tecnologa de portlets
2.1 Introduccin
Los portales usan portlets como componentes de interfaz de usuario que proveen de una capa de presentacin a los sistemas de informacin [33]. Los portlets se orientan al usuario y son componentes de aplicaciones Web interactivas que se disean para agregarse a travs de un portal y comunicarse con usuarios a travs de un servidor de portal husped. Los portlets son locales o remotos al portal servidor [16]. En este captulo se estudian los estndares que constituyen la tecnologa de los portlets para el desarrollo de los portales de la segunda generacin. Adems, se hace una revisin de los ambientes de desarrollo que soportan la tecnologa de portlets.
2.2 Estndares JSR 168 y WSRP

El estndar JSR 168 define un API de portlet estndar que es especfico para portales que se basan en Java, el cual los desarrolladores utilizan para programar portlets que se ejecutarn en un servidor de portal manejable; mientras que WSRP define un API universal que permite a los portales de cualquier tipo consumir portlets de cualquier tipo. De tal forma que, productores WSRP permiten a portlets JSR 168 estar disponibles para consumidores remotos WSRP y permiten a los portales que se basan en Java consumir portlets originarios de otros ambientes, por ejemplo .NET [34].
35
2.2.1 Estndar JSR 168 (The Java Portlet Specification, la especificacin del portlet de Java)
JSR 168 es una especificacin de portlet del sistema de la comunidad Java [34]. Este estndar aborda la necesidad de permitir la interoperabilidad entre portales y portlets. Ya que anteriormente era difcil hacer un sitio Web que le ofreciera a los usuarios la posibilidad de acceder varios sistemas a partir de una sola pgina. JSR 168 se enfoca a las siguientes temticas: (1) el contrato del contenedor de portlet y la administracin del ciclo de vida, (2) la definicin de los estados de ventana y los modos del portlet, (3) administracin de preferencias del portlet, (4) informacin del usuario, (5) embalaje y despliegue, (6) seguridad; y (7) etiquetas JSP para ayudar al desarrollo del portlet [35]. Los mtodos 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 lgica que prepara el portlet para atender solicitudes, (2) destroy (), el cual se invoca cuando el contenedor destruye el portlet. Intenta contener la lgica que libera la memoria cuando el portlet ya no se necesita o se apaga el servidor, (3) processAction(), el cual se invoca despus de que el usuario suministra cambios al portlet. Intenta procesar la entrada desde una accin de usuario; y (4) render(), el cual se invoca siempre que el portlet se reinvoca a travs de la pantalla principal del sistema operativo. Se puede extender una clase denominada GenericPortlet e implementar tantos de estos mtodos render() como sean necesarios para un portlet. Estos mtodos son: (1) doView(), el cual se invoca por render() cuando el portlet est en modo View. Intenta contener la lgica que despliega la vista de la pgina del portlet, (2) doEdit(), el cual se invoca por render() cuando el portlet est en modo Edit. Intenta contener la lgica que despliega la pgina de edicin para el portlet; y (3) doHelp(), el cual se invoca por render() cuando el portlet est en modo Help. Intenta contener la lgica que despliega la pgina de ayuda para el portlet. Como indican los mtodos que antes se mencionan, los modos que se definen en la especificacin del portlet son View, Edit y Help. En el modo View, el portlet debe desplegar el contenido normal, que se basa en la funcionalidad que ofrece el portlet. En
36
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 descripcin completa de como el portlet se usa (explicando los modos Edit y View) o una ayuda sensitiva al contexto explicando las caractersticas 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 especificacin de portlet, su contenedor es responsable de recuperar y almacenar estas preferencias a travs de la interfaz PortletPreferences. La especificacin portlet provee un mecanismo para acceder a la informacin de un usuario tales como nombre, correo electrnico, telfono y direccin en el descriptor que se despliega de la aplicacin del portlet La especificacin portlet describe el embalaje y despliegue de portlets como parte del archivo de aplicacin Web estndar (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 visin general de los casos en que se invocan los mtodos bsicos de un portlet. Este portlet es un portlet del clima para desplegar la temperatura sobre una pgina de portal.
Figura 2.1. El portlet del clima
El portlet del clima despliega informacin de temperatura para un cdigo postal dado. Se permite a los usuarios consultar la temperatura para cdigos postales alternativos,
37
como se muestra en la figura 2.2. En dicha figura, se permite a los usuarios personalizar su cdigo postal y las unidades por omisin para desplegar la temperatura y en este ejemplo, el portlet recupera la informacin del clima desde un servicio Web. El primer mtodo del portlet que se invoca es el mtodo init(). El mtodo init() se invoca para inicializar el portlet antes de que el portal enve alguna peticin a l.
Figura 2.2. Edicin de preferencias
En el mtodo init(), el portlet del clima obtiene la URL del servicio Web del clima desde un parmetro init e inicializa el objeto de servicio para l. Si el parmetro init est ausente, o el servicio no puede inicializarse, el mtodo lanza una excepcin 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 pgina, el mtodo doView() se invoca para interpretar el contenido del mismo. Este mtodo se invoca cuando el portlet est en modo view (vista). Cuando los usuarios dan clic en el botn edit de la barra de ttulo del portlet, ste cambia al modo Edit (edicin) e invoca el mtodo doEdit(). Cuando el usuario da clic en el botn help sobre la barra de ttulo del portlet, ste cambia al modo HELP (ayuda) e invoca el mtodo doHelp().
38
2.2.2 Estndar WSRP (Web Services for Remote Portlets, servicios Web para portlets remotos)
Los servicios Web para portlets remotos (WSRP) son una especificacin de OASIS [34]. La especificacin WSRP aborda el problema consistente en que la integracin de contenido y aplicaciones en portales requiere un significativo esfuerzo de programacin. Tpicamente, 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 adaptndose a una variedad de diferentes interfaces y protocolos que usan los proveedores. El estndar WSRP de OASIS simplifica la integracin 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 programacin. Las caractersticas de WSRP consisten en que: (1) estandariza los servicios Web en la capa de presentacin, (2) se sita en la pila de servicios Web existentes, segn se muestra en la figura 2.3, (3) construye sobre los estndares de servicios Web existentes; y (4) apoya los esfuerzos de estndares 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 descripcin de servicios Web). Adems, WSRP define metadatos para auto-descripcin con el fin de publicar y encontrar servicios WSRP en registros (estos constituyen un servicio de hospedaje que se ofrece por una compaa de tecnologa de red, por ejemplo Oracle, para registrar servicios WSRP de algn productor). Todos los servicios WSRP requieren el uso de SOAP (Simple Object Access Protocol, protocolo de acceso de objeto simple) para la invocacin de servicios Web y opcionalmente soportan estndares adicionales. En relacin a la importancia de la estandarizacin de los servicios Web en la capa de presentacin que hace WSRP hay que considerar que frecuentemente, el contenido se obtiene de servicios externos y se despliegan en portlets locales especficos que se ejecutan sobre el portal. Mientras este enfoque es factible para establecer la base funcional de un
39
portal, no conviene para la integracin dinmica de fuentes de informacin y aplicaciones de negocios en portales. De acuerdo a la figura 2.3, WSRP se ajusta en un gran contexto de la pila de estndares 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. Adems, WSRP se superpone con WSIA (Web Services for Interactive Applications, servicios Web para aplicaciones interactivas) con quien comparte una base comn de interfaces y definicin de protocolos.
(X)HTML
WML
Voz XML
XHTML Bsico
WSRP WSRP/WSIA
Base comn
WSIA
WSDL (Descripcin)
SOAP (Invocacin)
Figura 2.3. WSRP y estndares que se relacionan
WSRP define la nocin de fragmentos vlidos 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 tambin define un conjunto de nombres estilo estndar 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 estndar WSRP es implementar servicios que no solamente proveen fragmentos de marcado, sino que tambin permiten servicios ms complejos que requieran
40
registro del consumidor, soportar interaccin 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 sesin; y (5) servicios WSRP con registro y revocacin. El servicio WSRP ms simple posible provee una simple vista, sin alguna interaccin 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 ms complejo con un servicio WSRP que soporta la interaccin del usuario y mantiene el estado conversacional reflejando la interaccin del usuario. Un ejemplo es un servicio de noticias que provee una descripcin general de encabezados de los diferentes artculos de noticias y permite a los usuarios dar clic sobre los encabezados para navegar al artculo individual y sobre un vnculo 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 cotizacin de acciones que permite a usuarios individuales definir su portafolio personal. Este caso requiere el concepto de mltiples entidades persistentes. En los servicios WSRP interactivos con estado de entidad y estado de sesin, un productor WSRP ms complejo emplea tanto el estado de entidad persistente como el estado de sesin 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 pginas que se comparten y se usan concurrentemente por mltiples usuarios finales. En los servicios WSRP con registro y revocacin los proveedores de WSRP no solamente soportan acceso para consumidores annimos, sino que adems, implementar operaciones convenientes para registrar y borrar a consumidores. Estos estndares los soportan determinados ambientes de desarrollo, entre ellos el de Java Studio Creator que se seleccion para el desarrollo de esta tesis. necesitan
41
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 estndares usando Java Server Faces a travs de una interfaz de usuario de drag and drop (arrastrar y soltar). Se simplifica la integracin con fuentes de datos heterogneas tales como bases de datos relacionales, JavaBeans Enterprice, servicios Web y tambin se incluyen otras caractersticas. Las aplicaciones que se desarrollan con Java Studio Creator se despliegan en contenedores J2EE estndares 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 diseo, y los documentos JSPs se editan en vista de diseo y cdigo fuente [37]. Opcionalmente, el portlet usa una pgina JSP, una pgina de flujo, o un archivo de respaldo, y se construye conforme al estndar JSR 168 para garantizar la compatibilidad del portlet. Los portlets consumen aplicaciones Web existentes y contenidos tales como: pginas con tecnologa 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 estndar de servicio Web que permite enchufar y ejecutar servicios Web que se orientan visualmente al usuario con portales o aplicaciones Web de otros intermediarios. Permite crear portlets que proveen contenido a otros portlets o consumen contenido de otras fuentes [37].
42
M.C. Enrique Ruiz Daz. 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 rpidamente portlets mediante la definicin de una secuencia de componentes de software, reutilizables y adaptables, denominados "Builders". Los Builders generan dinmicamente el cdigo de la aplicacin, incluyendo Java Server Pages (JSP), clases Java y documentos XML, as como todos los objetos de nivel inferior que componen la aplicacin de portlet. De este modo, se permite a los desarrolladores capturar y automatizar el proceso de creacin de portlets dinmicos, en lugar de codificar explcitamente cada portlet. Adems, permite a los desarrolladores crear con rapidez y facilidad varios portlets que se personalizan totalmente a partir de una base de cdigo, sin necesidad de realizar un nuevo despliegue o efectuar cambios adicionales en el cdigo [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 travs de NetBeans: (1) modulacin para integrarse con el lenguaje de modelado unificado (UML), (2) colaboracin instantnea del desarrollador, (3) un perfilador de aplicacin empresarial, (4) constructor de portlets, (5) kit de verificacin de aplicacin 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 configuracin,
43
administracin y requerimiento de autorizacin, (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 peticin de especificacin 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 edicin de desarrollo de Borland del portal de aplicacin Vignette
Borland y Vignette establecieron una solucin combinada para ayudar a las organizaciones a acelerar la creacin de portlets con funcionalidad que se personaliza, mejorando el diseo y calidad de las interfaces Web y consolidacin de administracin de portlets funcionalmente dispares a travs de la empresa. La solucin consiste en la creacin de un portlet que se enchufa en Borland JBuilder 2005 y la edicin de desarrollo de Borland del portal de aplicacin Vignette. Esta solucin se dise para crear portlets que se personalizan y se basan sobre el estndar JSR 168 de Java proporcionando caractersticas de seguridad inherentes en el ambiente J2EE, tiempo de desarrollo breve e incremento de la escalabilidad y el desempeo para aplicaciones empresariales. JBuilder 2005 y la edicin de desarrollo de Borland de portal de aplicacin Vignette permite a los clientes mejorar la velocidad con la cual se desarrollan y despliegan portlets de Java que se basan en estndares. Estos portlets tienen la opcin de tomar ventaja de la integracin de servicios Web y de desplegarse para guiar servidores de aplicaciones J2EE [40].
2.3.6. OracleAS Portal
OracleAS Portal es una aplicacin Web que se utiliza para crear y desplegar portales. Proporciona un entorno seguro y manejable para acceder e interactuar con
44
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 publicacin en autoservicio [41]. El marco extensible como pginas Web, aplicaciones, informes de inteligencia de negocio y contenido de mediacin dentro de componentes de informacin estndar 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 catlogo cada vez mayor de otros fabricantes proveedores de portlets. El marco del portal ofrece servicios adicionales, como la conexin nica, la clasificacin de contenido, la bsqueda de empresa, la integracin de directorios y el control de acceso. Finalmente, proporciona funciones de publicacin 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 dinmico. Los portales usan portlets como componentes de interfaz de usuario que proveen de una capa de presentacin a los sistemas de informacin. 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 estndar que es especfico para portales que se basan en Java; y (2) WSRP define un API universal que permite a los portales de cualquier tipo consumir portlets de cualquier tipo. Para el desarrollo de los portlets existen diversas IDEs, ejemplos de estas son: (1) Java Sun Studio Creator, (2) IDE de WebLogic Workshop, (3) IBM WebSphere Portlet 45
Factory, (4) Sun Java Studio Enterprise, (5) Borland JBuilder 2005 y la edicin de desarrollo de Borland del portal de aplicacin Vignette; y (6) OracleAS Portal.
46
Captulo 3. Componentes de la arquitectura del portal empresarial
3.1. Introduccin
Los portlets son componentes que permiten encapsular servicios Web y presentarlos a los usuarios. Los portales de segunda generacin 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 heterogneas o fuentes de datos de una manera consistente. Ambos proveen comunicacin 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 integracin y en una reduccin de costos de introduccin para portales. En este captulo, 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 operacin: el modo portal de Internet y el modo Proxy. El aspecto general de la arquitectura se muestra en la figura 3.1.
47
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 denominacin en el sitio de Internet xmethods.net. Este sitio presenta una lista de servicios Web pblicamente disponibles.
Nombre del servicio Web
Descripcin
Ignyte's Retrieve Theaters and Las pelculas que ofrecen los Movie Showtimes. cines para un determinado cdigo postal (USA). USA Weather Forecast. La previsin del clima para un determinado ciudad (USA). Horoscope web Services AmazonBox El horscopo diario. Bsqueda de productos en cdigo postal o
Amazn.com.
Tabla 3.1. Descripcin de los servicios Web del portal.
En el modo portal de Internet, a travs 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 ms detalles, ambos modos.
48
M.C. Enrique Ruiz Daz. 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. Adems, 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 informacin acerca de su ambiente. Estos portlets se despliegan, ordenadamente, en la pgina de portal que se muestra al cliente. El cliente, a travs del navegador de su equipo de cmputo 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 enva la respuesta al portlet invocador. Este la presenta al cliente.
49
M.C. Enrique Ruiz Daz. 3.2.2. Modo Proxy del portal.
Los portlets y los servicios Web tienen una estrecha relacin 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 terico y relacin con los portlets. Con este conocimiento, se presenta la arquitectura del portal en su modo Proxy. Para lo cual, se describe el desempeo individual e integral de sus componentes.
3.2.2.1. Relacin entre servicios Web y portlets.
Con el fin de ofertar sus servicios a travs 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 pblica en un servidor Web mediante un lenguaje de descripcin de interfaces (WSDL). Dicha interfaz ofrece un conjunto de actividades que un cliente invoca. El cliente accede al servicio Web usando los estndares de Internet [42], por ejemplo, HTTP. Para acceder a un servicio Web se utilizan, opcionalmente, varios protocolos Web estndar como HTTP GET o HTTP POST. Aunque se dise un protocolo especfico para ello: SOAP (Simple Object Access Protocol, Protocolo de acceso de objeto simple). Este protocolo se basa en la utilizacin de HTTP para el transporte de mensajes y el lenguaje XML para escribir el cuerpo de estos mensajes. Todo lo anterior permite a cualquier aplicacin generar e interpretar mensajes SOAP independientemente de la plataforma [42]. De tal forma que, los servicios Web, a travs de sus protocolos y estndares: SOAP, WSDL (Web Services Description Language, lenguaje de descripcin de servicios Web) y, tambin, UDDI (Universal Description, Discovery, and Integration, descripcin, descubrimiento, e integracin universales), proveen un marco de trabajo inter-
organizacional. En sntesis, SOAP, WSDL y UDDI tienen funciones especficas que ofrecen a los servicios Web: (1) SOAP para comunicarlos, (2) WSDL como un lenguaje de descripcin de interfaces; y (3) UDDI como un registro de especificaciones [43]. La arquitectura del portal, en su modo Proxy, trabaja con los dos primeros.
50
La relacin entre los portlets y los servicios Web consiste en que en contraste a los portlets implementados localmente, los servicios Web representan portlets interorganizacionales. Sin embargo, los servicios Web no incorporan funciones de integracin de presentacin, las cuales son pertinentes a los portlets. En consecuencia, los servicios Web orientados a presentacin representan portlets remotos. Esto se da a travs de la inclusin de fragmentos de presentacin que ya se estandarizaron para asegurar un aspecto uniforme en el portal. De hecho, el estndar WSRP, para portlets remotos, trabaja en este sentido [21]. En relacin 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 aplicacin para consumir el servicio Web que el portal le ofrece intermediariamente. En este caso, la intermediacin tiene la ventaja de otorgarle al cliente informacin con el formato de respuesta que se determin como ms
51
conveniente a sus necesidades. El cliente, de antemano, conoce dicho formato de respuesta a travs del documento WSDL que el portal, previamente, le proporcion. La aplicacin 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. Descripcin 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 seccin. Como sus nombres lo indican, el cliente y proveedor externo representan entidades externas a la arquitectura del portal.
<wsdl:message name="MessageRequest"> </wsdl:message> <wsdl:message name="MessageResponse"> <wsdl:part name="Respuesta" type="xsd1:String"/> </wsdl:message> <wsdl:portType name="horoscopoPortType"> <wsdl:input message="tns:MessageRequest"/> <wsdl:output message="tns:MessageResponse"/> </wsdl:portType> <wsdl:service name="horoscopo">
Figura 3.4. Documento WSDL del servicio Web Horoscope web Services, para los clientes del portal en su modo Proxy.
52
M.C. Enrique Ruiz Daz. 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 basndose en dicho documento. La finalidad del analizador de mensajes SOAP es establecer la comunicacin entre la aplicacin del cliente y el portal en su modo Proxy. Y con ello, atender la solicitud del mtodo invocador de la aplicacin del cliente. Para ello, analiza dicho documento WSDL con la finalidad de determinar el mtodo invocador y sus argumentos. As, el analizador de mensajes SOAP centra su atencin 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 mtodo invocador, que se asign para la aplicacin 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 comunicacin que estableci el analizador de mensajes SOAP. Para ello, centra su atencin 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 horscopo.
3.2.2.2.3. El contenedor de portlets
El contenedor de portlets proporciona un entorno de ejecucin 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 estndar JSR 168. ste estndar se concreta en Apache Pluto [44].
53
M.C. Enrique Ruiz Daz. 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 basndose en dicho documento. La finalidad del invocador es establecer comunicacin, del portal, con el servicio Web del proveedor externo. Por ello, emplea el mtodo correspondiente con sus respectivos argumentos, si los tiene. As, el invocador centra su atencin 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 mtodo de invocacin se llama GetHoroscope y ste no requiere argumento alguno.
3.2.2.2.5. El analizador de respuesta
Este trabaja basndose 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 informacin de respuesta neta. Es decir, a la informacin de respuesta se le extraen datos que ya no interesan, relativos al uso de los estndares de servicios Web. Por ello, el analizador de respuesta centra su atencin 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 mtodo, que el proveedor externo emplea para dar su respuesta, se llama GetHoroscopeResponse y la respuesta es un dato de tipo String.
54
<message name="GetHoroscopeSoapIn"> <part name="parameters" element="s0:GetHoroscope" /> </message> <s:element name = "GetHoroscope"> <s:complexType /> </s:element> <message name="GetHoroscopeSoapOut"> <part name="parameters" element="s0:GetHoroscopeResponse" /> </message> <s:element name="GetHoroscopeResponse"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="GetHoroscopeResult" type="String " /> </s:sequence> </s:complexType> </s:element> <portType name="HoroscopeSoap"> <operation name="GetHoroscope"> <input message="s0:GetHoroscopeSoapIn" /> <output message="s0:GetHoroscopeSoapOut" /> </operation> </portType>
Figura 3.5. Documento WSDL del servicio Web Horoscope web Services, del proveedor externo del servicio para el portal en su modo Proxy.
55
M.C. Enrique Ruiz Daz. 3.2.2.2.6. El constructor de respuestas
Este enva la informacin de respuesta al cliente. Es decir, debe responder a la aplicacin 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) enva la respuesta al cliente a travs del mensaje SOAP que cre. Con esta finalidad, centra su atencin 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 mtodo 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 travs de un mensaje SOAP la aplicacin del cliente enva la solicitud. Esta se recibe por el analizador de mensaje SOAP del portal en modo Proxy. Cuya finalidad es comunicar los objetos que se estn ejecutando en ambas partes. Paso 2. Una vez que se establece la comunicacin interviene el selector de servicio, el cual analiza los parmetros 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 travs de un mensaje SOAP, enva la peticin de servicio al proveedor externo de servicio Web. Paso 5. Dicho proveedor recibe la solicitud, la procesa y a travs de un mensaje SOAP enva la respuesta al portal. Paso 6. Esta respuesta la recibe el analizador de respuesta, que anlogamente al analizador de mensaje, primeramente, requiere establecer la comunicacin entre el proveedor y el portal en modo Proxy, y cuya funcin principal es extraer los elementos de
56
respuesta que interesan, es decir, la informacin. Esta se pone a disposicin 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 continuacin, enva la informacin de respuesta a la aplicacin del cliente a travs de un mensaje SOAP.
3.3. Resumen
Los portlets y los servicios Web son compatibles, ya que ambos comparten una base comn de estndares y protocolos, los cuales son de aceptacin creciente entre proveedores de contenidos y aplicaciones. Lo que permite apoyar a los portales como intermediarios mltiples. Esencialmente, la diferencia entre los servicios Web y los portlets consiste en que estos ltimos agregan la capa de presentacin a travs de fragmento de marcado, generalmente HTML. Ya que ste, es un estndar que se consolid para los navegadores de Internet. En este captulo se presentaron los componentes de la arquitectura del portal para los dos modos de operacin: modo portal de Internet y modo Proxy. Se present que para ambos modos, los clientes y los proveedores de servicios son elementos externos. Adems, se observ que un elemento comn para ambos modos es el contenedor de portlets, el cual se encarga de gestionar el ciclo de vida de los portlets. En relacin 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 discusin 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 operacin, a travs de los documentos WSDL que los proveedores externos entregaron para este objetivo.
57
Captulo 4. Prestaciones de servicios del portal empresarial
4.1. Introduccin
En este captulo se describen los servicios que proporciona el portal en sus modos portal de Internet y Proxy. Adems, se presentan las tecnologas 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 prestacin de servicios, las cuales son seis: (1) presentacin, (2) comunicacin, (3) descubrimiento, (4) servicio, (5) lgica; e (6) integracin.
4.2. Modo portal de Internet

4.2.1. Interfaz grfica del modo portal de Internet En el modo portal de Internet, el cliente accede al portal a travs 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 opcin 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 slo al portlet correspondiente a la opcin.
58
Figura 4.1. El modo portal de Internet con la opcin activa All Portlets.
4.2.2. Tecnologa de desarrollo para el modo portal de Internet
El portal se desarroll con tecnologa JSP que se complementa con lenguaje de marcado HTML y requiere del contenedor de portlets. El portal se ejecuta en un servidor con tecnologa TomCat. Se opta por esta tecnologa 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 caracterstica es uno de los objetivos de esta tesis. Por otra parte, TomCat realiza el soporte para portlets a travs del compilador que se denomina Jasper, que compila JSPs convirtindolas en servlets. (en trminos generales, los portlets son JSPs). Adems, a causa de que Tomcat se program en lenguaje Java, funciona en cualquier sistema operativo que disponga de la mquina virtual Java[45].
4.2.3. Mtodos del contenedor de portlets para el modo portal de Internet
La representacin 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 mtodos del contenedor de portlets hacen 59
posible las formas de operacin de los portlets. La utilizacin, por parte del usuario, de dichas formas: minimizar, maximizar, normalizar, cerrar, modo edit y modo view se informa a los respectivos mtodos del contenedor de portlets. La tecnologa JSP auxilia en esta labor. El contenedor de portlets controla el ciclo de vida de los portlets a travs de determinados mtodos. Estos mtodos se presentan y describen ms abajo. El contenedor de portlets se desarroll en lenguaje Java y durante la invocacin de sus mtodos se apoya de tecnologa Java Server Pages. Debido a esto ltimo, en la invocacin de los mtodos del contenedor se observa el auxilio de instrucciones de dicha tecnologa. Ello es necesario, porque los mtodos del contenedor de portlets requieren argumentos que recaban informacin que procede de la capa de presentacin, es decir, HTML. A travs de HTML se recaba informacin que se genera en las peticiones del usuario, cuando el usuario utiliza las formas de operacin del portlet. En la prctica, el empleo de los mtodos del contenedor de portlets requiere del apoyo de una estructura condicional if-else. Se requiere la parte if para cubrir la accin de concretar al objeto contenedor de portlets y a los portlets que ste hospeda. Entonces, la parte if se ejecuta nicamente en la primera ocasin en que el usuario accede al portal, y en las siguientes ocasiones se ejecuta la parte else. En esta parte else se recaba informacin que se genera de la interaccin de los usuarios con los portlets. En dicha parte, se encuentran los mtodos del contenedor de portlets que obtienen informacin 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 operacin del portlet y en consecuencia, re-invoca la pgina del portal para el envo de informacin HTML. Finalmente, se coloca fuera tanto de la parte if como de la parte else, a los mtodos que proveen de fragmento de marcado HTML a travs de un dato de tipo String, el cual representa a los portlets para el usuario final. Se ejemplifica el empleo de los mtodos necesarios para un portlet en figura 4.3. A continuacin se presentan los mtodos del contenedor de portlets en la secuencia que se requiere y con una breve descripcin de su funcionalidad.
60
Figura 4.2 A. Representacin en UML del contenedor de portlets.
61
Figura 4.2 B. Representacin en UML del contenedor de portlets.
62
Figura 4.2 C. Representacin 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 pgina 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 direccin 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).- instruccin de tecnologa JSP para hospedar, en una variable de sesin, al objeto contenedor de portlets. El primer argumento se refiere al nombre que se asigna a la variable de sesin que se crea, y el segundo argumento es el objeto que se almacena en la variable de sesin. ContenedorPortletsERD obj = (ContenedorPortletsERD)
session.getAttribute("ProducePortlets").- Igual que el caso inmediato anterior, se trata de una instruccin de tecnologa JSP. Solo que ahora con la finalidad de
63
recuperar al objeto contenedor de portlets que antes se almacen en una variable de sesin. 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 tecnologa JSP. Para la construccin del segundo argumento, la instruccin de tecnologa JSP requiere, adems, del apoyo de un mtodo 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 cuestin est minimizado, normalizado, maximizado o cerrado. Requiere como primer argumento el nombre del portlet, y para construir el segundo argumento requiere del apoyo de tecnologa 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 tecnologa JSP, la cual a su vez requiere de la expresin 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 tecnologa JSP, la cual a su vez, emplea una expresin constante que se denomina "PortletSeleccionado". session.setAttribute("ProducePortlets", obj).- Despus de que el contenedor de portlets recibi informacin actual sobre los estados de los portlets, nuevamente, requiere hospedarse en una variable de sesin 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 edicin y los datos que se actualizan en este modo. Para ello requiere de la instruccin
request.getParameterValues("ArgumentoEDIT"). Esta instruccin slo puede
64
trabajar para un portlet a la vez, es decir, en un momento determinado, corresponde slo a un portlet ingresar al modo edit. obj.setConservarValoresdeControlesHTML("AmazonBox", request.getParameter(obj.getArgumentoControlesHTML("AmazonBox"))); Este
mtodo 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 instruccin de tecnologa JSP, la que a su vez, requiere del apoyo del mtodo 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 sesin en la cual se almacen previamente. String ElementoForm = obj3.getElementoForm().-La variable de tipo String que se denomina ElementoForm recaba un elemento propio de tecnologa 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 opcin de restaurar a un portlet que previamente se cerr. Una vez que se obtiene la variable que retorna este mtodo, se procede a imprimir en el lugar que se considere ms conveniente. String PortletAmazonBox = obj3.getUnPortlet("AmazonBox").- Obtiene el portlet que se indica como argumento de este mtodo. Luego, igual que en el caso inmediato anterior, no existe restriccin en relacin al lugar que se elija para su impresin.
65

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. Mtodos del contenedor de portlets, en la secuencia y con la estructura condicional if-else que se requiere para generar un portlet.
66
4.3. Modo Proxy

Para que el portal ofrezca sus servicios de intermediacin o servicio Proxy para servicios Web de entretenimiento, requiere de una API. Una API (Application Programming Interface, Interfaz de Programacin de Aplicaciones) define los mtodos a travs de los cuales un programador accede y controla un sistema determinado [46]. La API del modo Proxy presenta los mtodos 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 horscopo de los doce signos zodiacales, (3) Ignyte's Retrieve Theaters and Movie Showtimes, para la programacin de cines de un determinado lugar de los Estados Unidos de Amrica; y (4) USA Weather Forecast, para obtener la prediccin del clima dado un cdigo postal o lugar de los Estados Unidos de Amrica. 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 prrafo inmediato anterior. En las secciones siguientes se presenta una visin 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 invocacin y ejecucin de estos servicios.
67
Figura 4.4. Representacin 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 lneas diferentes de estos. Este servicio consta de treinta mtodos. La descripcin de estos mtodos se presenta en la tabla 4.1. Cada mtodo busca un tipo determinado de producto. En la figura 4.5 se presenta una ejemplificacin, en caja negra, del funcionamiento general del documento WSDL para los clientes del servicio Proxy AmazonBox.
68
M.C. Enrique Ruiz Daz. Mtodo

public String bookBox(String Keyword) public String babyBox(String Keyword) public String classicalMusicBox(String Keyword) public String dvdBox(String Keyword) public String electronicsBox(String Keyword) public String gardenAndOutdoorLivingBox(String Keyword) public String kitchenAndHousewaresBox(String Keyword) public String magazinesBox(String Keyword) public String popularMusicBox(String Keyword) public String computerHardwareBox(String Keyword) public String cameraAndPhotoBox(String Keyword) public String computerSoftwareBox(String Keyword) public String toysAndGamesBox(String Keyword) public String toolsAndHardwareBox(String Keyword) public String videoBox(String Keyword) public String computerAndVideoGamesBox(String Keyword) public String authorBox(String Keyword) public String musicianPopularMusicBox(String Keyword) public String musicianClassicalMusicBox(String Keyword) public String actorDvdBox(String Keyword) public String actorVideoBox(String Keyword) public String directorDvdBox(String Keyword) public String directorVideoBox(String Keyword) public String manufacturerElectronicsBox(String Keyword) public String manufacturerKitchenAndHousewaresBox(String Keyword) public String manufacturerComputerAndVideoGamesBox(String Keyword) public String manufacturerComputerSoftwareBox(String Keyword) public String manufacturerCameraAndPhotoBox(String Keyword) public String manufacturerComputerHardwareBox(String Keyword) public String similaritiesBox(String Keyword)
Maestro en Ciencias de la Computacin Producto a buscar Por el mtodo

Libros Para bebs De msica clsica DVD Electrnicos Jardn y casa al are libre Cocina y mercancas de la casa Revistas Msica popular Hardware de computadora Cmara y fotos Software de computadora Juguetes y juegos Herramientas y hardware Videos Computadora y video juegos Por autor Msica popular por msico Msica clsica por msico Por actor en DVD Por actor en video Por director en DVD Por director en video Electrnicos por fabricante Cocina y mercancas de la casa por fabricante Computadora y video juegos por fabricante Software de computadora fabricante Cmara y fotos por fabricante Hardware fabricante Similares de computadora por
por
Tabla 4.1. Mtodos del servicio Proxy AmazonBox
69
Para cada mtodo, se requiere proporcionar una palabra clave relacionada al tipo de producto que se desea. Por otra parte, todos los mtodos retornan la respuesta en un dato de tipo String. En consecuencia, el documento WSDL establece que los mtodos del servicio requieren como argumento de invocacin una palabra clave relacionada al tipo de producto a buscar. Por ello, para el argumento de invocacin de cada mtodo 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. Adems, se establece que los mtodos 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 invocacin de un mtodo de este servicio Proxy. Dicho mtodo se denomina getBook y se us la palabra clave Java. En la figura 4.7 se presenta la ejecucin de ste mtodo.
String KeyWord
Mtodos de AmazonBox
String Response
Clases en Java
Figura 4.5. Ejemplificacin, en caja negra, del empleo de los mtodos del documento WSDL para el servicio Proxy AmazonBox
70
Figura 4.6. Ejemplo de invocacin de un mtodo, el mtodo getBook, del servicio Proxy AmazonBox.
Figura 4.7. Ejemplo de ejecucin de un mtodo, el mtodo getBook, del servicio Proxy AmazonBox.
71
M.C. Enrique Ruiz Daz. 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 prediccin del horscopo para los doce signos zodiacales. En la figura 4.8 presenta una ejemplificacin, en caja negra, del funcionamiento general del documento WSDL del servicio Proxy Horoscope. Este servicio consta de un nico mtodo y para su invocacin no se requiere proporcionar argumento alguno. En el documento WSDL se establece que el mtodo 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 invocacin del mtodo del modo Proxy Horoscope. Para ello se ejecuta el mtodo denominado getHoroscope sin argumento alguno. En la figura 4.10 se presenta la ejecucin de dicho mtodo.
Mtodo de la clase Horoscope: getHoroscope()
String Response
Figura 4.8. Ejemplificacin, en caja negra, del empleo del mtodo getHoroscope del documento WSDL para el servicio Proxy Horoscope
Figura 4.9. Ejemplo de invocacin del mtodo del servicio Proxy Horoscope que se denomina getHoroscope. 72
Figura 4.10. Ejemplo de ejecucin del mtodo 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 programacin de cines para un determinado cdigo postal de los Estados Unidos de Amrica. 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 mtodo. Dicho mtodo se denomina getShowTimes y para su invocacin se requiere un argumento de tipo String para enviar el cdigo postal. Por otra parte, se establece que el mtodo 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 mtodo para la invocacin del servicio. Este mtodo se denomina getShowTimes. En la figura 4.12 se presenta un ejemplo de la invocacin del mtodo y en la figura 4.13 se presenta su ejecucin.
73
Maestro en Ciencias de la Computacin Mtodo de la clase Theaters: getShowTimes ()
String CodigoPostal
String Respuesta
Figura 4.11. Ejemplificacin, en caja negra, del empleo del mtodo getShowTimes del documento WSDL para el servicio Proxy Theaters
Figura 4.12. Ejemplo de invocacin del mtodo del servicio Proxy Theaters que se denomina getShowTimes.
Figura 4.13. Ejemplo de ejecucin del mtodo del servicio Proxy Theaters que se denomina getShowTimes
74
M.C. Enrique Ruiz Daz. 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 prediccin del clima para un determinado cdigo postal o lugar de los Estados Unidos de Amrica. En la figura 4.14 se presenta la ejemplificacin, en caja negra, de la funcionalidad general del documento WSDL del servicio Proxy USAWeather. Este servicio consta de dos mtodos para obtener la prediccin del clima. Estos mtodos se denominan: getWeatherByZipCode y getWeatherByPlaceName. El primero de ellos requiere de un dato de tipo String para enviar el cdigo postal del lugar, de los Estados Unidos de Amrica, sobre el que se desea la prediccin del clima. El segundo mtodo, 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 cdigo postal o el nombre del lugar, respectivamente. Mientras que el elemento denominado Response lo utilizan ambos mtodos para entregar la respuesta del servicio. En la figura 4.15 se presenta la invocacin de uno de los mtodos del servicio y en la figura 4.16 se presenta su ejecucin. Mtodos de la clase USAWeather: String ZipCode getWeather ByZipCode () getWeather ByPlace Name() String Response
String PlaceName
String Response
Figura 4.14. Ejemplificacin, en caja negra, del empleo de los mtodos del documento WSDL para el servicio Proxy USAWeather
75
Figura 4.15. Ejemplo de invocacin de un mtodo del servicio Proxy USAWeather que se denomina getWeatherByZipCode.
Figura 4.16. Ejemplo de ejecucin de un mtodo del servicio Proxy USAWeather que se denomina getWeatherByZipCode..
76
4.3.5. Tecnologa de desarrollo para el modo portal Proxy
La construccin del modo Proxy requiri, primeramente, de la construccin 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) presentacin, (2) comunicacin, (3) descubrimiento, (4) servicio, (5) lgica; e (6) integracin. La arquitectura compuesta en capas se muestra en la figura 4.17. Generalmente, estas capas proveen servicios a los dos modos de operacin del portal. Sin embargo, la capa de presentacin es exclusiva al modo portal de Internet. A continuacin, se presenta los servicios que ofrece cada capa y en que consisten.
4.4.1. Capa de presentacin
La capa de presentacin ofrece el servicio de interfaz al usuario final para el modo portal de Internet. Los servicios de la capa de presentacin consisten en: (1) reunir informacin del usuario final o cliente. Este objetivo se logra a travs de formularios HTML que el portlet presenta de acuerdo al tipo de servicio que atiende.
77
(2) enviar dicha informacin a la capa de descubrimiento para que sta determine el portlet que se requiere. Se enva a travs de HTTP cuando el portal recibe la orden por medio de su men. (3) recibir informacin de respuesta desde la capa de integracin. Esto se logra a travs de una instruccin output que permite a un programa en JSP transmitir informacin a formato HTML y que se exterioriza en el navegador de Internet. (4) presentar, la informacin del punto anterior, ordenadamente al usuario final. Este objetivo se logra a travs de elementos tpicos de HTML, por ejemplo, tablas, listas de seleccin, reas de texto, entre otros.
4.4.2. Capa de comunicacin
Para los clientes del modo portal de Internet la comunicacin 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 comunicacin a travs de mensajes SOAP. Los mensajes SOAP emplean HTTP como protocolo de transporte, aunque tambin pueden emplear otros protocolos como SMTP (Simple Mail Transfer Protocol, protocolo simple de transferencia de correo electrnico), FTP (File Transfer Protocol, protocolo de transferencia de archivos), entre otros. SOAP utiliza generalmente HTTP por ser ste un protocolo de amplia difusin y porque el puerto HTTP generalmente no se protege (80 es su puerto por defecto). Por otra parte, los servicios de la capa de comunicacin consisten en: (1) permitir la comunicacin con el portal. En el caso del modo portal de Internet es a travs de HTTP y en el caso del modo Proxy es a travs de un mensaje SOAP. En esta ltima situacin interviene el componente que se denomina analizador de mensajes SOAP, el cual atiende a la aplicacin del cliente que demanda el consumo de un servicio. La aplicacin del cliente est en condiciones de construir dicho mensaje SOAP gracias a que, previamente, se proporcion, al cliente, el documento WSDL del servicio Web respectivo.
78
(2) solicitar el servicio que se requiere al proveedor externo del portal. Esto a travs 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 aplicacin del cliente la informacin de respuesta que provee el componente que se denomina constructor de respuesta. La respuesta se enva a travs de un mensaje SOAP. Para el modo portal de Internet, la comunicacin opera con el protocolo HTTP. En relacin al mensaje SOAP, ste permite dirigir, generalmente a travs de HTTP, un mensaje de peticin al servidor del servicio Web correspondiente, y ya en el servidor, permite invocar un servicio especfico proveyendo, adems, los parmetros 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 travs de identificar al servicio que se indica en el mensaje SOAP que recibi la capa de comunicacin. Con el cual se realiza una consulta y seleccin de servicio por nombre; y (2) solicitar el portlet que se demanda desde el modo Proxy, segn descripcin 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 travs del nombre del portlet.
79
M.C. Enrique Ruiz Daz. 4.4.4. Capa de servicio
La capa de servicio hospeda los diversos servicios que provee el portal. Esto lo realiza a travs del componente que se denomina contenedor de portlets. Los servicios de esta capa consisten en: (1) proporcionar al portlet con los recursos e informacin necesaria para que stos entreguen al portal informacin y contenidos dinmicos. Esto es posible gracias a las formas de operacin de los portlets. Estas formas de operacin se ofrecen a los usuarios a travs de botones de los portlets. stos, al ser accionados por los usuarios constituyen rdenes de formas de operacin del portlet. Estas rdenes se crean, primeramente, con tecnologa HTML y que, inmediatamente, se recaban por variables de JSP y se transmiten al contenedor de portlets a travs de los mtodos correspondientes. (2) proveer el portlet que solicita la capa de descubrimiento. El men del portal permite disponer de los portlets. Al elegir una opcin en el men se establece una orden, primeramente, de tecnologa HTML e inmediatamente sigue una situacin anloga 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 lgica
La capa lgica provee los mecanismos de control del sistema a travs de los portlets. Los servicios de esta capa consisten en: (1) aplicar reglas de validacin a datos que provienen de la interfaz de usuario. Esto se refiere a validacin 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 formulacin de
80
respuestas. El constructor de respuesta se provee a travs de un mtodo el cual se encarga de articular el dato de respuesta.
4.4.6. Capa de integracin
La capa de integracin provee el servicio de construccin de respuestas. Este servicio se proporciona a travs de los componentes: invocador, analizador de respuestas y constructor de respuestas. Los servicios de la capa de integracin consisten en: (1) Invocar al proveedor externo el servicio que demanda el cliente. Esto se realiza a travs de un mensaje SOAP. (2) extraer la informacin neta de respuesta desde la informacin que se recibe del proveedor externo. Esta informacin neta se constituye o bien por algn tipo de dato o por una estructura de datos compleja. Este resultado se obtiene a travs del analizador de repuestas, y ste transmite dicho resultado al constructor de respuesta. (3) construir la informacin de respuesta, a travs del constructor de respuesta, de acuerdo a especificacin que se realiz al cliente en el documento WSDL que se le entreg. Para los servicios del portal en su modo Proxy la informacin 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 programacin en cdigo Java; y (4) remitir a la capa de comunicacin 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 travs de un mensaje SOAP y en el segundo caso, la clase java provee la respuesta, primeramente, a un archivo JSP a travs del retorno de respuesta de un mtodo del contenedor de portlets. A su vez, el archivo JSP genera una salida (output) con fragmento de marcado HTML. Esta respuesta se recibe por
81
el usuario final gracias a su navegador con conexin 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 operacin del portal: modo portal de Internet y modo Proxy. Estos servicios se proveen a travs 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 travs de su navegador de Internet y elegir alguna opcin que presenta el men de opciones del portal con el fin de disponer de algn portlet o de todos ellos juntos. Por otra parte, para la labor de diseo del portal se presentaron los mtodos que gestionan el ciclo de vida de los portlets.
82
En relacin 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 prestacin de servicios. La arquitectura propuesta presenta seis capas: (1) presentacin, (2) comunicacin, (3) descubrimiento, (4) servicio, (5) lgica; e (6) integracin.
83
Captulo 5. Casos de estudio
5.1. Introduccin
En este captulo se presentan casos de estudio que demuestran las ventajas que un portal de segunda generacin, que se constituye por portlets, ofrece al usuario. En general, la tecnologa de portlets evita, al usuario, la necesidad de visitar infinidad de sitios o portales dispersos para recibir los servicios que el portal ofrece a travs de sus portlets.
5.2. Caso de estudio: una bsqueda de programacin de cines

El caso de estudio describe cmo el portal de segunda generacin facilita el acceso a informacin proveniente de fuentes de datos heterogneas. Se hace mencin que la arquitectura propuesta, a travs de sus portlets, emplea servicios Web de entretenimiento, correspondiente a los Estados Unidos de Amrica porque en nuestro pas (Mxico) 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 programacin de pelculas para un determinado lugar de los Estados Unidos de Amrica. 2. Existen varios sitios o portales dispersos que ofrecen la programacin de pelculas. En este escenario, cmo puede el usuario encontrar la programacin de pelculas 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 grfica del portal con sus primeros cuatro portlets. Este portal presenta un portlet denominado Theaters (el cual se muestra en estado de presentacin, en la figura 5.2a, y en estado de ejecucin, en la figura 5.2b y 5.2c). El portlet Theaters presenta el servicio de entretenimiento consistente
84
en la programacin de pelculas que ofrecen los cines para un determinado cdigo postal de los Estados Unidos de Amrica. El portlet Theaters solicita, al usuario, el cdigo postal de los Estados Unidos de Amrica sobre el que interesa realizar la bsqueda y solicita que se seleccione un radio de accin (permetro que cubre la bsqueda). Despus, solicita que elija entre tres opciones de consulta: (1) general, (2) por cine; y (3) por pelcula. En cualquiera de las tres opciones, la bsqueda comprende al cdigo postal y al radio de accin que el usuario proporciona. Si elije la primera opcin, corresponde al usuario seleccionar la casilla Everything y oprimir el botn get ShowTimes. Inmediatamente, el portlet despliega una tabla con la programacin de pelculas. Si elije la segunda opcin, concierne al usuario seleccionar la casilla By theater y oprimir el botn get ShowTimes. Luego, el portlet despliega la lista de cines. Entonces, atae al usuario elegir un determinado cine y oprimir el botn Show. En seguida, el portlet despliega una tabla con la programacin de pelculas del cine que seleccion. Si elije la tercera opcin, incumbe al usuario seleccionar la casilla By film y oprimir el botn get Show Times. Inmediatamente, el portlet presenta al usuario una lista con las pelculas. Entonces, concierne al usuario elegir una determinada pelcula y oprimir el botn Show. Enseguida, el portlet despliega al usuario una tabla con todos los cines que ofrecen esa determinada pelcula. El portal es de gran ayuda al usuario, porque ste no necesita visitar infinidad de sitios o portales para encontrar la programacin de pelculas de inters.
Figura 5.1. Portal con los primero cuatro portlets
85
(a) En presentacin.
(b) En ejecucin, primera parte.
(c) En ejecucin, segunda parte

Figura 5.2. El portlet Theaters en presentacin y en ejecucin
5.3 Caso de estudio: ayuda en la toma de decisin para la asistencia al cine.

El caso de estudio de la presente seccin ayuda al usuario a tomar la decisin si asiste o no al cine. Debido a que, adems de la programacin de cines para un determinado lugar, tambin se muestra la previsin del clima para ese mismo lugar. El escenario es el siguiente:
86
1. Un usuario desea conocer la programacin de pelculas para un determinado lugar de los Estados Unidos de Amrica, y adems, desea conocer la previsin 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 programacin de pelculas y la previsin del clima. En este escenario, cmo puede el usuario obtener la programacin de cines y la previsin del clima para con ello tomar la decisin 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 programacin de pelculas que ofrecen los cines y la previsin del clima para un determinado cdigo postal de los Estados Unidos de Amrica. Este portlet, TheatersAndUSAWeather, se muestra en su estado de presentacin inicial al usuario en la figura 5.3, y en relacin a su estado de ejecucin, 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 previsin del clima tanto en grados centgrados como Fahrenheit para el cdigo postal que proporcion el usuario como se muestra en la figura 5.4. El modo de operar del portlet se describe a continuacin.
Figura 5.3. El portlet TheatersAndUSAWeather en su presentacin inicial al usuario.
87
Para ofrecer sus servicios, el portlet TheatersAndUSAWeather primeramente solicita, al usuario, que elija un estado de los Estados Unidos de Amrica. Con esta informacin, el portlet presenta una lista de las cinco principales ciudades de dicho estado. A continuacin, 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 cdigos postales de dicha ciudad. Entonces, el portlet solicita al usuario que elija un determinado cdigo postal. Una vez que el usuario el selecciona el cdigo postal, el portlet solicita, al usuario, que seleccione un radio de accin (permetro que cubre la bsqueda) y que elija un tipo de consulta: (1) general, (2) por cine; y (3) por pelcula. A continuacin, el portlet despliega la respuesta al usuario como se aprecia en la figura 5.4.
Figura 5.4. El portlet TheatersAndUSAWeather en ejecucin.
A continuacin se describen los argumentos de la tecnologa de portlets que permiten las ventajas al usuario que se mostraron en los casos de estudio.
88
5.4. Fundamentos de la tecnologa de portlets que explican sus ventajas en sus servicios al usuario.
Los casos de estudio que se describieron demuestran ventajas caractersticas 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 travs del portlet. El usuario solicita un servicio de entretenimiento a travs 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 informacin de respuesta, el portlet, ordenadamente, la presenta al usuario. Por otra parte, el portal tiene la ventaja de ser adaptable y de presentar informacin de fuentes de datos heterogneas consistentemente. Es adaptable porque, durante el diseo del portal, a los portlets se asigna la distribucin que se considere ms conveniente. Por otra parte, del lado del usuario, los portlets son adaptables porque cada portlet presenta varias formas de operacin: (1) minimizar, (2) normalizar, (3) maximizar; y (4) cerrar. Adems un botn para el modo edit (edicin) y para el modo view (vista). En el modo edit se tiene la opcin 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 distribucin que se considere ms conveniente al portal asigna a ste la cualidad de adaptable. Ello es posible dada la condicin de los portlets de constituir componentes Web. Esta condicin permite a los portlets versatilidad para desarrollarse y desplegarse manejablemente. Adems, dado que un portlet es un componente, ello muestra a los portlets como un encapsulado de una aplicacin Web para utilizarse dentro de un portal. Por otra parte, el portal es atractivo al usuario porque adems de los portlets comentados en los anteriores casos de estudio, el portal que se propone tambin presenta otros portlets, tales como Amazon.com, USAWeather y Horoscope. El portlet Amazon.com ofrece, en un contexto de comercio electrnico, la bsqueda de productos en treinta lneas diferentes de stos. Este servicio es del tipo B2C (Business to Consumer) y slo permite consultar los productos que se desean, no ofrece servicio de
89
carrito de compras. Para consumir los servicios de este portlet se requiere una palabra clave con relacin al producto de inters, y adems, se requiere elegir un tipo de lnea de producto. De tal forma que, por ejemplo, si se desean libros de Java. Entonces la palabra clave es Java y la lnea de producto a seleccionar es libros. El portlet USAWeather ofrece la prediccin del clima para los ms importantes cdigos postales o ciudades de los Estados Unidos de Amrica. Este servicio se presenta con las opciones siguientes: (1) grados centgrados, (2) grados Fahrenheit; y (3) ambos. En cualquiera de las tres opciones, el servicio presenta la prediccin del clima para los siete das de la semana, e indica la temperatura mxima y mnima tanto en grados centgrados como en grados Fahrenheit. Para consumir los servicios de este portlet se requiere proporcionar el cdigo postal o el nombre de una ciudad. Adems, se requiere elegir el tipo de grado en que se desea la consulta. El portlet Horoscope ofrece la prediccin diaria del horscopo para los doce signos zodiacales. Todos los vaticinios se presentan en idioma ingls y para cada uno de stos se muestra una redaccin de un prrafo con alrededor de diez lneas de contenido. El portlet Horoscope ofrece dos tipos de consulta: (1) todos los signos; y (2) un signo en especfico. Si se opta por la primera opcin se requiere seleccionar, de la lista que presenta el portlet, la opcin 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 captulo se presentaron dos casos de estudio. Ambos describen una problemtica a la que se enfrenta un cliente, el escenario que se presenta dicha problemtica y que el portal, a travs de sus portlets, est en condiciones de resolver. En consecuencia, en este captulo, tambin se hizo nfasis en fundamentos tecnolgicos que permiten a los portlets ofrecer sus respectivas soluciones. El primer caso de estudio se enfoc en describir la solucin que un portlet ofrece a un cliente que dispersa su tiempo al tener que buscar la programacin de cines en mltiples sitios. El segundo caso de estudio present, a otro portlet, con la misma solucin a la
90
problemtica anterior; pero que adems, ayuda al cliente a decidir si asiste o no al cine dado que agrega la prediccin del clima. Finalmente, en la seccin de los fundamentos de la tecnologa de portlets que explican sus ventajas al usuario se realiz una discusin sobre las ventajas que implican los mecanismos a los cuales acceden los portlets, es decir, los servicios Web. Adems, se mostr la cualidad de adaptabilidad de la arquitectura que se propone. Dicha cualidad permite adecuar, en tiempo de diseo, la colocacin de los portlets en el portal. Por otra parte, la cualidad de adaptabilidad se presenta de los portlets hacia los clientes a travs de servicios que facilitan las experiencias de interaccin de los clientes.
91
Captulo 6. Conclusiones
6.1. Conclusiones generales

Esta tesis cumpli con su objetivo general de presentar el diseo y construccin de un portal empresarial utilizando la tecnologa de portlets. En forma ms detallada, el objetivo general de la tesis consisti en el diseo y construccin de un portal empresarial con base en el desarrollo de una aplicacin Web, que se gestione por un contenedor de portlets. El contenedor de portlets provee un entorno de ejecucin para los portlets, ello permite a los portlets generar, dinmicamente, fragmento de marcado HTML al portal. En consecuencia, la hiptesis estableci que como apoyo a dicho objetivo se utilice tecnologa open source (cdigo abierto), dado que ello otorga al sistema a desarrollar la caracterstica de la portabilidad. El objetivo de esta tesis tuvo su correspondiente motivacin. La razn de utilizar la tecnologa de portlets, para portales de segunda generacin, consiste en superar restricciones de los portales monolticos de la primera generacin. 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 tecnologa que es posible llevar a las empresas de la regin, 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 contina 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 sern poco observables para un portal con uno o dos portlets. Por lo tanto, las empresas de la regin que se favorecen del empleo de la tecnologa de
92
portlets son aquellas empresas que requieren desarrollar portales para hospedar a un amplio conjunto de portlets, donde cada portlet atiende su respectiva aplicacin Web. Tal como se mostr a lo largo de este documento, la tesis logr sus objetivos. La realizacin 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 generacin 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 travs de las pequeas ventanas de informacin que presentan los portlets; el modo Proxy atiende, no a clientes como personas fsicas, 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 ms especficos. 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 dinmicos configurables para la interfaz de usuario. Los portlets trabajan cooperativamente con los servicios de entretenimiento que el portal obtiene a travs del consumo de servicios Web. En consecuencia, y dada la caracterstica de interoperabilidad de los servicios Web, se logra comprobar la hiptesis. La hiptesis indica que con el uso de la tecnologa open source se obtiene la caracterstica de la portabilidad del portal a desarrollar. Por otra parte, se seala que la principal dificultad en el desarrollo de esta tesis consisti en la obtencin de los portlets y de su integracin. 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 ejecucin de un portlet con Java Studio Creator 2 present los siguientes inconvenientes: (1) ejecucin muy lenta, ya que para ejecutar un portlet tarda cerca de tres minutos, (2) el portlet es propenso a sufrir dao, el cual recibe el calificativo de irremediable por el IDE Java Studio Creator 2. Cuya causa a veces se atribuy a algn error en el cdigo y otras veces la causa del dao no fue identificable; y (3) dado que este ambiente de desarrollo no permite integrar a los portlets, en consecuencia, se
93
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 propsito. A consecuencia de la problemtica anterior, se desarroll un contenedor de portlets propio, utilizando para ello tecnologa open source como el lenguaje de programacin 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 presentacin utiliza tecnologa JSP que se agregaron, con xito, al contenedor de portlets propio. Por lo anterior, se agrega, a las conclusiones que esta seccin presenta, que el estudio del estndar 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 integracin de informacin 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 bsqueda de la programacin de cines dado un cdigo postal y se present un segundo caso de estudio para ayudar en la toma de decisin, acerca de si se asiste o no al cine, dada la
prediccin del clima, adems de la misma programacin de cines. Ambos casos de estudio permitieron demostrar que la arquitectura provee al portal con la caracterstica de la adaptabilidad y de presentar informacin consistentemente. Estas caractersticas constituyen las ventajas de la arquitectura propuesta. En relacin a la caracterstica de la 94
adaptabilidad, sta se presenta durante el diseo del portal porque los portlets se distribuyen en el orden que se desee. Adems, la adaptabilidad se otorga a los usuarios a travs de las varias formas de operacin de los portlets. Se accede a las formas de operacin de los portlets a travs de sus botones. En relacin a la caracterstica de acceso, con coherencia, a fuentes de datos de diversas naturalezas en la infraestructura global de informacin, sta se obtiene a causa de los medios con que operan los servicios Web. Dichos medios permiten independencia de lenguaje y plataforma para comunicacin entre aplicaciones. Los servicios Web logran este objetivo a travs del empleo de los estndares: HTTP, XML, SOAP y WSDL. Por otra parte, considerando que un mecanismo es una tcnica o tecnologa
particular que proporciona una funcin. En este sentido, el conjunto de servicios Web son los mecanismos a los cuales se accede a travs 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 travs de casos de estudio. Sin embargo, para aquellos que tengan inters en continuar trabajando sobre la lnea de investigacin de esta tesis, para esto se propone el siguiente trabajo futuro: Obtener una nueva valoracin de la arquitectura propuesta a travs de su aplicacin a un entorno real. Desarrollar nuevos casos de estudio.
Sera conveniente validar a la arquitectura en un entorno real; no obstante que sta ya se valid exitosamente en el entorno acadmico. Esto permitira una nueva valoracin del alcance de la propuesta. Por lo tanto, sera 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 implementacin de los portlets. As, cada sub-grupo, del equipo de desarrollo, atiende el desarrollo de determinados portlets. Donde la atencin hacia un portlet no implica prestar atencin hacia
95
algn otro. Ello, gracias a su caracterstica de atmico, (2) la adaptabilidad que otorgan los portlets permiten embeberlos al portal conforme los portlets se generan y su adaptabilidad tambin 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 desempeo de los dems. 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 organizacin de desarrollo de software que tiene como encargo la responsabilidad de desarrollar un amplio conjunto de aplicaciones Web, atmicas, 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 composicin de portlets. Ello es necesario cuando el consumo de un solo servicio Web no es suficiente para orquestar la solucin al usuario. En relacin al tema, se propone el caso de estudio que se presenta a continuacin en segundo trmino.
6.3.1. Caso de estudio propuesto en la implementacin imperiosa de un portal con un conjunto inicial de soluciones a travs de una arquitectura basada en portlets.
Para este primer caso de estudio se propone el escenario de una organizacin de desarrollo de software que desea una implementacin rpida de un portal que presente soluciones a ciertos problemas de investigacin de operaciones. Una vez que se implementa dicho portal, este se ofrecera a las industrias de la regin susceptibles de interesarse en soluciones a esta clase de problemas. Adems, ante las industrias de la regin, se promocionara la caracterstica de adaptabilidad del portal. Dicha caracterstica permite al portal embeber a un nmero creciente e indefinido de nuevas soluciones, en este caso, a problemas de investigacin de operaciones. Los problemas, de dicha rea, que el portal resolvera en su etapa inicial son los siguientes: (1) mtodo de mnimos cuadrados para determinar la funcin de la demanda, (2) control de inventarios, (3) sistema de lneas de espera, (4) sistema de optimizacin y
96
sistema de diagnstico; y (5) toma de decisiones sin muestreo. En este escenario, surge la pregunta: Cmo requiere dicha organizacin de desarrollo de software implementar la arquitectura basada en portlets para satisfacer las necesidades que antes se citan? La implementacin de este caso de estudio ofrecera 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 integracin rpida 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 ms importantes.
El caso de estudio que a continuacin se propone trata de la composicin de portlets para solicitar noticias del lenguaje Java en alguno de los idiomas ms importantes a nivel mundial. Esto, para dar solucin a la problemtica que presenta un usuario que requiere obtener dichas noticias para alguno de los principales idiomas. En consecuencia, surge la siguiente pregunta: Cmo puede el usuario conseguir las noticias de Java sin tener que buscar en multitud de sitios o portales dispersos y, adems, eludiendo la necesidad de un servicio de traduccin, 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 dispersin de tiempo. Para implementar la solucin, conviene considerar la composicin de un portlet con dos determinados servicios Web: JavaPortal News y Translation Engine. El primero de estos servicios permite obtener, en idioma ingls, el nmero de noticias que se desea sobre Java; mientras que el segundo servicio traduce de idioma ingls hacia alguno de los idiomas ms importantes. Los documentos WSDLs respectivos se ofrecen en el sitio de xmethods.com. En consecuencia, la orquestacin en el portlet de estos dos servicios ofrecera la solucin que demanda el usuario.
97
Finalmente, esta tesis signific realizar investigacin y contribuye al estado del arte. Con ello, se aporta una fuente bibliogrfica para trabajos futuros.
98
Glosario
API.- (Application Programming Interface, interfaz de programacin de la aplicacin) define los mtodos a travs de los cuales el programador accede y controla un sistema dado.
Arquitectura.- una descripcin de un sistema, incluyendo a los componentes del sistema y como ellos interactan. Tambin se dice que una arquitectura es una descripcin de todas las actividades funcionales que se realizarn para alcanzar la misin deseada, los elementos que el sistema necesita para realizar sus funciones, y la designacin de los niveles de funcionamiento de dichos elementos.
Compatibilidad.- es la capacidad para trabajar con otro dispositivo o sistema sin modificacin. 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 travs de Internet, entre un software cliente y un servidor, operando ambos bajo este protocolo. HTTP es el protocolo ms importante utilizado en los servicios de la World Wide Web (WWW).
Interoperabilidad.- es la condicin mediante la cual sistemas heterogneos pueden intercambiar procesos o datos.
JSR 168.- (Java Specification Request, especificacin Java Portlet) es un estndar que permite la interoperabilidad de los portlets entre portales Web diferentes. Esta especificacin define una API para interaccin entre el contenedor de portlets y el portlet que se dirige hacia reas de personalizacin, presentacin y seguridad.
99
Mecanismo.- una tcnica o tecnologa particular para proporcionar una funcin.
Open source.- (cdigo abierto) cualidad del software de incluir el cdigo fuente en la distribucin del programa. En general se usa para referirse al software libre.
Portabilidad.- caracterstica por la cual un programa puede transportarse de un sistema operativo a otro sin necesidad de cambiar su cdigo fuente.
Portal.- Es un sitio Web que representa un punto de acceso a recursos e informacin de una empresa u organizacin para sus empleados, clientes o proveedores.
Portlet.- son componentes Web gestionados por un contenedor de portlets que procesa peticiones y genera contenido dinmico. Los portales usan portlets como componentes de interfaz de usuario que proveen de una capa de presentacin a los sistemas de informacin.
Proxy.- Servidor situado entre la mquina del usuario e Internet. En el contexto del trabajo de la presente tesis se refiere a un servicio de intermediacin en servicios Web.
Servicios Web.- Es una coleccin de protocolos y estndares que sirve para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programacin 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 adopcin de estndares 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 cmo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web.
100
UDDI.- (Universal Description, Discovery and Integration, catlogo 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 descripcin de servicios Web) es un formato estndar, entendible por la computadora, para describir un servicio Web. Una definicin 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 estndar para portales para acceder y desplegar portlets que se hospedan e un servidor remoto.
WWW.- (World Wide Web, telaraa mundial) sistema de informacin basada en el hipertexto que se comunica por Internet. WWW la parte de Internet a la que se accede a travs del protocolo HTTP y en consecuencia gracias a navegadores normalmente grficos como Explorer.
XML.- (Extensible Markup Language, lenguaje de marcas extensible) es un lenguaje desarrollado por la institucin que se denomina W3 Consortium. XML es un metalenguaje, es decir, sirve para crear lenguajes ms especficos y es la base tecnolgica de los servicios Web.
101
Publicacin
Enrique Ruiz Daz, Giner Alor Hernndez. Una arquitectura de integracin de informacin basada en portlets para un portal empresarial. Primer encuentro de estudiantes en ciencia de la computacin E2C2. ISBN-10:970-36-0404-8 e ISBN13:978-970-36-0404-3. Instituto Politcnico Nacional, Mxico, D.F. 2007.
102
Referencias
[1] Wikipedia, Internet [en lnea] <http://es.wikipedia.org/wiki/Internet> [Consulta: 28 junio 2006] [2] Alfonso Cubero Moral, Sergio Luna Garca. Servlets y JSP Departamento de Informtica y Automtica Universidad de Salamanca. mayo 2003. pp: 2-17 [3] Kenneth Ramrez. Entendiendo Portales y Portlets: Parte 1 Creando un portal personalizado Java Developer Journal Vol. 9 de 2004. pp: 1-9. [4] Wikipedia, Portal [en lnea] <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 Gonzlez, Moiss Cid, Pedro Cuesta. Desarrollo de aplicaciones Web utilizando ASP (Active Server Pages) Departamento de Lenguajes y Sistemas Informticos Universidad de Vigo. NOVATICA 36 Edicin 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 consultora ICTI Consulting. Revista Mundo Linux Abril 2003. pp: 1-13. [8] Aplicaciones Web. Modelo de orientacin a objetos de PHP 3 y 4. [en lnea] <http://www.aplicacionesweb.cl/content/view/31/2/> [Consulta: 28 Junio 2006]. [9] Aplicaciones Web. Modelo de orientacin a objetos en PHP 5. [en lnea] <http://www.aplicacionesweb.cl/content/view/32/2/> [Consulta: 28 Junio 2006]. [10] Security Linux Com. Securing PHP. [en lnea] <
http://security.linux.com/security/04/08/05/203238.shtml> [Consulta: 28 Junio 2006]. [11] Daro Andrs Silva, Brbara Mercerat. Construyendo aplicaciones Web con una metodologa de diseo orientada a objetos LIFIA, Laboratorio de Investigacin y Formacin en Informtica Avanzada. Facultad de Informtica, Universidad Nacional de La Plata, Buenos Aires, Repblica Argentina. Enero 2002. pp: 1-21. [12] Daniel Gayo Avello, Benjamn Lpez Prez, Luis Vinuesa Martnez, Jos E. Labra Gayo, Juan M. Cueva Lovelle. Utilizacin de software libre como nica tecnologa para el
103
desarrollo de portales Web Universidad de Oviedo, Espaa. Departamento de Informtica. pp: 1-11. [13] Andrs Vignaga, Daniel Perovich. Arquitecturas y tecnologas para el desarrollo de aplicaciones Web. Universidad de la Repblica, Facultad de Ingeniera, Instituto de Computacin Montevideo, Uruguay. pp: 1-51 [14] Pedro Cuesta Morales, Manuel J. Maa Lpez, Carlos Cuervo Martnez. Aplicacin de Tcnicas de Recuperacin de Informacin a un Glosario de Trminos de Internet Desarrollado Utilizando Tecnologa JSP Departamento de Informtica, Universidad de Vigo. pp: 1-9 [15] Csar Colado Rodrguez. Diseo 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 (ICALT05). 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 (HPDC04). 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 (SCC05). IEEE Press. pp 1-8 [21] Thomas Puschmann, Rainer Alt. Process Portals Architecture and Integration. Proceedings of the 37th Hawaii International Conference on System Sciences 2004. IEEE Press. pp 1-10
104
[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-Science05). IEEE Press. pp 1-6. [23] Jason Novotny, Michael Russell, Oliver Wehrens.GridSphere: An Advanced Portal Framework. Proceedings of the 30th EUROMICRO Conference (EUROMICRO04). 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 (SCC05). IEEE Press. pp 1-8 [26] Oscar Daz, 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 627659. [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 lnea] http://users.cs.cf.ac.uk/M.Subramanian/publications/Research_models.pdf. Enero 2007] [29] Deepti Kodeboyina y Beth Plale. Experiences with OGSA-DAI: Portlet Access and Benchmark. Computer Science Department Indiana University. pp: 1-6. [En lnea] [Consulta:
http://www-unix.mcs.anl.gov/~keahey/DBGS/DBGS_files/dbgs_papers/kodeboyina.pdf. [Consulta: Enero 2007] [30] Henri Naccache, Gerald. C. Gannod, y Kevin A. Gary. A Self-healing Web Server Using Differentiated Services. Dept. of Computer Science & Engineering, Arizona State University. Springer-Verlag Berlin Heidelber 2006. pp: 203-214.
105
[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 Mara Martn, Inmaculada Gonzlez, y Francisco Jos Garca. Portlet-based architecture for a LMS: CLAYNET 2.0. Departamento de I+D+i CLAY Formacin Internacional. Virtual Campus 2006 Postproceedings. Selected and Extended Papers. pp: 181-194 [En lnea]
http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-186/17.pdf. Enero 2007]
[Consulta:
[33] alzado.org, Servidores de portales: usabilidad empaquetada? [en lnea] <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 168The Java Portlet Specification. pp: 119. [36] Sun Microsystems. Sun Java Studio Creator 2. [en lnea]. <http://developers.sun.com/prodtech/javatools/jscreator/features/index.html> [Consulta: 25 julio 2006]. [37] BEA WebLogic. Building Portlets. [En [Consulta: 7 lnea]. agosto
<http://edocs.bea.com/workshop/docs81/doc/en/core/index.html>. 2006]. [38] IBM Espaa. WebSphere Portlet Factory. [En
lnea].
<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 lnea]. <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 lnea].
106
<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 lnea].
<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 Prez. Web Services. Departamento de Sistemas Informticos y Computacin. Universidad Politcnica 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 lnea] <http://portals.apache.org/pluto/> [Consulta: 10 enero 2007]. [45] Wikipedia. Tomcat. [En lnea] <http://es.wikipedia.org/wiki/Tomcat> [Consulta: 12 Junio 2007] [46] David Gould Studios. Definicin de API. [En lnea].
<http://www.davidgould.com/Glossary/Glossary.htm> [Consulta: 3 Junio 2007]
107

M.C. Enrique Ruiz Díaz - Diseño y Construcción de Un Portal Empresarial Utilizando La Tecnología de Portlets.

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

M.C. Enrique Ruiz Díaz - Diseño y Construcción de Un Portal Empresarial Utilizando La Tecnología de Portlets.

Uploaded by

Copyright:

Available Formats

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

INSTITUTO TECNOLGICO DE ORIZABA

DISEO Y CONSTRUCCIN DE UN PORTAL EMPRESARIAL UTILIZANDO LA TECNOLOGA DE PORTLETS

MAESTRO EN CIENCIAS EN CIENCIAS DE LA COMPUTACIN

LIC. ENRIQUE RUIZ DAZ

DR. GINER ALOR HERNNDEZ

ORIZABA, VERACRUZ, MXICO. SEPTIEMBRE 2007

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

ndice de tablas ... viii ix xi

1.3. Evolucin de las tecnologas de informacin .. 5 5 1.3.2. PHP 6 7 8 8

1.3.6. Los Portlets 9 11 13

1.6 Propuesta de solucin ... 21 22

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

5.2. Caso de estudio: una bsqueda de programacin de cines .. 72 74

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin 80 80

Captulo VI. Conclusiones ... 6.1. Conclusiones generales ...

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

Figura 4.2 A. Representacin en UML del contenedor de portlets 49 50 51

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

Tabla 4.1. Mtodos del servicio Proxy AmazonBox .. 57

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

1.3. Evolucin de las tecnologas de informacin.

1.3.1 Common Gateway Interface (CGI)

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

1.3.3. Active Server Pages (ASP)

M.C. Enrique Ruiz Daz. 1.3.4. Servlets

Maestro en Ciencias de la Computacin

1.3.5. JavaServer Pages (JSP)

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin

1.3.6. Los Portlets

M.C. Enrique Ruiz Daz.

Maestro en Ciencias de la Computacin