Tema 1: Introducción a los estándares de portales

Transcripción

1 Tema 1: Introducción a los estándares de portales

2 Portales de primera generación Papeles de un portal Integración de aplicaciones a nivel de interfaz de usuario Acceso personalizado De utilidad tanto en Internet como intranets Portales de primera generación Monolíticos Dificultad de desarrollo y mantenimiento

3 Portales de segunda generación (1)

4 Portales de segunda generación (2)

5 Portales de segunda generación (3) Permite que cada usuario disponga de una o varias páginas compuestas por portlets (componentes) Un portlet es una mini-aplicación Web interactiva que devuelve fragmentos de markup (HTML, WML, etc.) El portal construye cada página agregando las respuestas de los portlets que contiene Decora las respuestas de los portlets con una barra de título y un conjunto de botones (minimizar/maximizar, editar, etc.) Cada portlet es un componente que se puede instalar fácilmente en el portal Implementa un conjunto de interfaces

6 Portales de segunda generación (y 4) Surgieron hace tiempo en el contexto de Internet... my.yahoo.com, my.excite.com, etc... y ahora se hacen populares en las intranets Ofrecen una vista personalizada y restringida de la información interna de la empresa En los últimos años han surgido un gran número de servidores de portales ( portal servers ) Ejemplos: Oracle WebLogic Portal, IBM WebSphere Portal Server, GlassFish Web Space Server, Oracle Portal, Microsoft Office SharePoint Server, Liferay Portal, GateIn Portal (fusión de JBoss Portal y exo Portal), Jakarta Jetspeed, etc. Suelen proporcionar un portal pre-construido en el que es posible instalar ( deploy ) portlets

7 Por qué se necesitan estándares? Las primeras versiones de los servidores de portales presentan problemas de incompatibilidad Problema 1: un portal no puede consumir remotamente los portlets instalados en otro portal Problema 2: los portlets desarrollados con un determinado portal no se pueden instalar en otro portal Existen estándares que hacen frente a estos problemas La mayor parte de los fabricantes han adaptado sus servidores de portales para soportar estos estándares

8 Problema 1 (1) Arquitectura clásica de un portal basado en portlets Portlet BBC World News Portlet BBC Tech News Portlet Stock News Portlet Stock Quote Portlet My Bookmarks XML/HTTP XML/HTTP SOAP/HTTP SOAP/HTTP Servicio BBC World News ( Servicio BBC Tech News ( Servicio Stock News ( Servicio Stock Quote ( Portlet Tip Of The Day Portal

9 Problema 1 (y 2) Cada Portlet Es local al portal Proporciona interfaz gráfica Respuesta, asistente de personalización, información de ayuda, etc. Proporciona datos o es un proxy de un servicio externo al portal (que sólo ofrece datos) Consecuencias Cualquier portal que integre los servicios de la BBC o de Xignite => debe re-implementar la interfaz gráfica de los portlets, dado que los servicios sólo ofrecen datos Si se desea construir otro portal que use los portlets My Bookmarks y Tip Of The Day => es preciso volver a instalarlos en el nuevo portal (si está construido con el mismo servidor de portales) o desarrollarlos completamente (en otro caso) Este caso sería probable dentro de una gran corporación con distintos portales (e.g. uno para cada división) que desean compartir algunos portlets

10 Solución: portlets remotos (1) Productor BBC ( Productor Xignite ( Portlet BBC World News Portlet BBC Tech News Portlet Stock News Portlet Stock Quote Productor Portal 1 Portlet My Bookmarks Portlets locales Portlet Tip Of The Day Portal 1 Portal 2

11 Solución: portlets remotos (2) Cada productor de portlets implementa un servicio Web estándar (definido en WSDL) que permite que los consumidores (típicamente portales) interactúen con sus portlets Entre otras, el interfaz ofrece una operación que Recibe como parámetro los datos correspondientes a una interacción que realiza el usuario sobre un portlet (e.g. clic en un enlace) Devuelve el nuevo markup del portlet Si un portal desea exportar algunos de sus portlets locales, sólo necesita proporcionar un productor El administrador del portal puede añadir portlets remotos sin necesidad de programación Todos los productores implementan el mismo interfaz

12 Solución: portlets remotos (3) Diferencia entre un portlet local que consume datos de un servicio Web y un portlet remoto Productor ORCL IBM Servicio Web ORCL IBM Interfaz gráfica Interfaz gráfica (portlet local) Portlet remoto Symbol Last Change ORCL IBM Portal Portal

13 Solución: portlets remotos (y 4) En Septiembre del 2003, OASIS (Organization of the Advancement of Structured Information Standards) publicó la versión 1.0 del estándar WSRP (Web Services for Remote Portlets) tc_home.php?wg_abbrev=wsrp Especifica el conjunto de interfaces (definidos en WSDL) que debe implementar un productor de portlets Productor y consumidor pueden usar distintas tecnologías (J2EE,.NET, etc.) En Abril del 2008, OASIS publicó la versión 2.0 de WSRP

14 Problema 2 (1) Debería ser posible instalar los portlets desarrollados en un servidor de portales en otro diferente, siempre que usen la misma tecnología (e.g. J2EE) Evita dependencias con respecto al fabricante Se precisa un API estándar para cada lenguaje de programación El estándar WSRP no define este API WSRP define un API para exportar los portlets de un productor a aplicaciones remotas, y no para desarrollar portlets locales La mayor parte de los portlets de un portal serán locales (por eficiencia y porque muchos serán específicos al portal)

15 Problema 2 (y 2) Se precisa un API que permita desarrollar portlets locales con las mismas tecnologías que se usan para desarrollar aplicaciones Web (e.g. JSP o ASP.NET) En Octubre del 2003 se publicó la versión 1.0 de la especificación de portlets Java (JSR 168) Un portlet Java se puede instalar en cualquier contenedor de portlets estándar En consonancia con WSRP 1.0 En Junio del 2008 se publicó la versión 2.0 de la especificación de portlets Java (JSR 286) Extensión de JSR 168 y compatible hacia atrás En consonancia con WSRP 2.0 Microsoft SharePoint incluye soporte para la programación de Web Parts Equivalente al concepto de portlets Java Compatibilidad con WSRP

16 Arquitectura de un servidor de portales Java basado en estándares (1) Apl. portlet Navegador Otros portales Aplicación Web del portal Productor WSRP Contenedor de portlets Java [...] Apl. portlet Portlet consum. WSRP Internet/Intranet Productor WSRP Servidor de portales

17 Arquitectura de un servidor de portales Java basado en estándares (y 2) Productor WSRP (dentro del servidor de portales) Proporciona una implementación de los interfaces de WSRP, para que otros consumidores remotos puedan acceder a los portlets locales Java Portlet consumidor WSRP Actúa como un proxy de un productor WSRP, permitiendo que el portal pueda consumir portlets WSRP remotos como si fuesen portlets locales Java