h1

Portales, portlets y su implementación

01/15/2010

Wizdoc [Icon By Buuf]  Tips & Tricks.
En estas semanas el equipo ha tenido como misión la actualización tecnológica del sitio web para uno de nuestros clientes. Dicha actualización incluye la instalación de un portal y un gestor de contenidos o CMS, siendo Liferay y Alfresco las opciones de producto que fueron seleccionadas porque son opensource, ambos componentes tienen la capacidad de integrarse mutuamente y porque Liferay puede desplegar las páginas que almacena en formato para dispositivos móviles.

Al desarrollar este proyecto, hemos notado que los clientes no siempre tienen claro qué es un portal, para qué sirve y qué se supone que debe hacer. Por ello este post, donde explico un poco la temática.

Un portal: qué es y para qué sirve

De inicio, un home page no es lo mismo que un portal. Normalmente se asocia un portal a una página central con ligas a otras páginas o sitios web, pero eso sólo es una estructura de documentos HTML que cualquiera puede lograr. La verdadera naturaleza de un portal consiste en tres cosas:

• Contenidos agregados. Es decir, que más de una persona pueda buscar, usar o añadir páginas web, imágenes y otros tipos de contenido al portal principal y las páginas que lo componen, de acuerdo a las necesidades de la organización que hostea el portal.

• Acceso a contenido de acuerdo a pertenencia. Si un usuario forma parte de una comunidad, categoría o perfil de usuarios determinada, solo podrá ver los contenidos permitidos de acuerdo a su perfil.

• Integración de servicios. Es decir, no sólo agregar textos o imágenes, sino también aplicaciones o servicios para ser utilizados dentro del dominio del problema. Un ejemplo sería una aplicación en el portal que realiza consultas a una base de datos y con los resultados de dicha consulta se alimenta otra aplicación que realiza un análisis estadístico.

Entonces, un portal es un sitio que de acuerdo a las necesidades de la comunidad que lo conforma, permite a los usuarios la búsqueda, uso e integración de aplicaciones, servicios y contenidos en un solo punto, bajo un esquema de acceso de acuerdo a perfiles y roles.

Un caso de estudio y algunos tips a considerar

El área de Comunicación Interna de una compañía se ha percatado que cada departamento tiene su propio sitio con información y aplicaciones web. Así, el área de Recursos Humanos posee una pequeña intranet con una aplicación de gestión de candidatos y una página donde publica manuales con políticas de contratación. El área de Gestión de Calidad tiene otro sitio con un foro de discusión donde tratan temas como mejores prácticas y certificaciones black-belt… y así sucesivamente. Entonces, estamos hablando de un portal. Sin embargo, siempre hay que considerar tres factores al definir la estrategia de implementación y tiempos para un proyecto de este tipo:

• Primero, hay que realizar un análisis de todos y cada uno de los sitios individuales que van a agregarse al portal: conocer en qué están hechos y qué tan factibles son de ser integrados a un gestor de contenidos. Esto porque sitios con contenido estático como HTML son fácilmente integrables, mientras que sitios con contenido dinámico (JSPs, ASPs o cualquier otro framework) no lo son.

• Segundo, es indispensable conocer cómo se manejan los usuarios, perfiles y roles en estos sitios y cuál es la posibilidad de migrarlos a un repositorio único. Aquí existen dos opciones: integrar todo o dejar que cada uno maneje su propia seguridad. Si optamos por integrar todo – término denominado como Single-Sign-On o SSO – debemos asegurarnos que entendemos cómo funciona la seguridad en cada aplicación para no afectar su funcionalidad. Por otro lado, en caso de optar por un manejo compartamentalizado de logins y passwords, disminuimos nuestra carga de trabajo pero arriesgamos la usabilidad del portal debido a múltiples logins.

• Finalmente, debemos verificar si se necesita una comunicación entre las diferentes aplicaciones y hasta qué grado debe llegar, ya que durante el delivery podemos toparnos con situaciones que pueden sacarnos canas verdes. Explico un poco al respecto en las siguientes secciones.

Portlets y las JSR 168 y 286

Empecemos por definir el término portlet. Todas las páginas de un portal están compuestas por portlets, que son componentes de software – clases de Java o Web Parts de .NET – que "renderizan" fragmentos de lenguaje de marcado como HTML o XML que se van agregando a la página, y que en el navegador aparecen como si fueran pequeñas ventanas o frames con vista a diferentes aplicaciones y contenidos. Por ejemplo, en un portlet podemos renderizar únicamente texto, mientras que en otro podemos mostrar una imagen y en otro más podemos publicar una aplicación:

Cómo se renderiza o despliega una página en un portal, mostrando contenidos y aplicaciones de diferentes tipos. En la página mostrada existen seis portlets: un cliente de Alfresco para gestión de contenidos, un portlet para soporte multi-lenguaje, un diccionario, un workflow, un calendario y un widget para foros de discusión. (Fuente: Intalioworks)

Los portlets se ejecutan dentro de un contenedor que gestiona su ciclo de vida, realizando llamadas a métodos equivalentes a render() o destroy(). Finalmente, este contenedor puede formar parte de un software de portales empresarial, como Liferay, Oracle Weblogic Portal o IBM Websphere Portal.

Ahora bien, originalmente cada proveedor de software de portales como IBM, BEA u Oracle, realizaba su propia implementación de portlets como Dios les daba a entender, haciendo de estos componentes poco portables. Sin embargo, en 2003 varios de estos proveedores publicaron conjuntamente una especificación para la implementación de portlets en el lenguaje de programación Java. Dicha especificación, denominada JSR-168, determinaba la estructura y comportamiento que debía poseer un portlet. De esta manera se generó la primera versión del Portlet API y la subsecuente implementación de referencia, reflejada en el Pluto Portlet Container. Dicho contenedor es actualmente un elemento central de software de Portales como Apache Jetspeed o JBoss Portal.

Más tarde, dándose cuenta que la JSR-168 no resolvía ciertos problemas como la comunicación entre portlets o soporte a J2EE 1.4, en 2008 se publicó una especificación un poco más completa, denominada JSR-286 o Portlet 2.0 que aborda estos temas.

Construyendo un portal en la vida real

Hasta aquí hemos visto que un portal es una excelente idea sobre el papel y con la ayuda de portal software podemos realizar maravillas en forma de sitios eCommerce e Intranets corporativas. Sin embargo, la implementación siempre tendrá sus detalles y debemos cuidarnos de identificar los posibles riesgos antes de quedar atrapados en situaciones complicadas. Algo que nos ha ayudado muchísimo en este proyecto ha sido desarrollar desde el principio pruebas de concepto donde verificamos que algo se puede hacer antes de lanzarnos de lleno al ruedo. Describo algunos ejemplos:

• De primera instancia, si necesitamos integrar aplicaciones de manera que exista una comunicación entre ellas a través del portal, debemos asegurarnos de utilizar un servidor que sea Portlet 2.0 o JSR-286 compliant. Conforme madure la tecnología, más y más portales comerciales u opensource soportarán esta especificación, pero de momento, es necesario verificarlos.

• Es bastante probable que se requiera una customización e incluso creación de nuevos portlets que utilicen el core API del contenedor. En el caso específico de Liferay, esto se logra a través del ambiente extendido (extension environment o ext). La pésima documentación – sobre todo para las últimas versiones del producto – ha sido un obstáculo que sólo a base de prueba y error hemos resuelto.

• Hablando de creación de portlets, hay otro detalle: El IDE. Tanto Netbeans como Eclipse tienen plugins para desarrollar dichos componentes. Sin embargo, los plugins de Netbeans son mejores, a menos que estemos dispuestos a adquirir licencias de MyEclipse.

Y bueno, así hay infinidad de casos, incluyendo layouts, temas, el motor de búsquedas (estilo Google Site Search) y otros tantos detalles que es necesario cubrir en un proyecto de este tipo.

Conclusiones y un poco de reflexión

Habiendo realizado pruebas de concepto y algunos pininos de portlets en mi máquina, me entra la duda si realmente los portlets y portales son una buena idea. Después de todo, el portlet API impone muchas restricciones en su desarrollo, por no decir que es un show echarlos a andar; si lo que queremos es integrar aplicaciones, ¿no sería mejor desarrollar un SOA? si lo que buscamos es la gestión de documentos, seguramente podremos integrar un API externalizado por parte de un gestor documental a simples servlets o JSPs – por ejemplo, Alfresco tiene un API para este fin – sin meternos en tantos rollos de implementación. Como menciona Eric Spiegelberg en su artículo JSR-286: Al filo de la irrelevancia:

[Mi] Experiencia profesional … me ha llevado a la conclusión que la arquitectura de portales carece de las suficientes ventajas técnicas y características distintivas que garanticen un aumento en su aceptación. En la práctica, pocas aplicaciones pueden contenerse a sí mismas en la aislada y disparatada funcionalidad de los portlets; la renuncia a este grado de control arquitectónico es poco realista en software de nivel empresarial.

Entonces, si la idea de un portal sale del usuario, adelante. Pero debemos advertirle qué representa realmente un portal y cuáles son los riesgos asociados a su implementación, pues la mayoría de las veces ni el cliente ni el mismo consultor saben a ciencia cierta qué es o para qué sirve. Y si la decisión recae en nosotros, debemos saber de lo que estamos hablando antes de hacernos un "candadito" a nosotros mismos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: