Universidad Austral de Chile

Transcripción

1 Universidad Austral de Chile Facultad de Ciencias de la Ingeniería Escuela de Ingeniería Civil en Informática DESARROLLO DE UN SISTEMA PORTAL PARA EL MANEJO DE CONTENIDO Tesis para optar al Título de: Ingeniero Civil en Informática Profesor Patrocinante: Sr. Erick Araya Araya. Ingeniero de Ejecución Electrónico. Magíster en Ingeniería Electrónica Profesor Co-Patrocinante: Sra. Gladys Mujica Arredondo. Máster en Comunicación Social y Relaciones Públicas. Licenciada en Estudios Interdisciplinarios Profesor Informante: Sr. Jorge Morales Vilugron Ingeniero Electrónico Diplomado en Ciencias de la Ingeniería Magíster en Administración de Empresas ANDRÉS JAVIER ZÁRATE MEDEL VALDIVIA - CHILE 2011

2

3

4

5 ÍNDICE DE CONTENIDOS Índice de contenidos...2 Índice de tablas....4 Índice de figuras....4 Resumen....6 Abstract INTRODUCCION Antecedentes Generales Contribución del Proyecto Impactos Objetivo General Objetivos Específicos TECNOLOGIAS ASOCIADAS A LOS PERIODICOS ONLINE Sistemas Manejadores de Contenido Sistemas de Portales Web Sistemas de periódicos online en Chile EL ESTANDAR JSR Definiciones Arquitectura y funcionamiento de un portal Elementos de las páginas de portal Relación del estándar JSR 268 con el proyecto CICLO DE VIDA DEL DESARROLLO Introducción Elección del ciclo de vida del desarrollo PROPUESTA DE SISTEMA REQUISITOS Y ANÁLISIS DEL SISTEMA Requisitos del sistema Análisis de requisitos Plan de fases RUP Análisis del Sistema DISEÑO DEL SISTEMA Diseño del Servidor de Aplicaciones

6 7.1.1 Servidor de Aplicaciones Administrativas Servidor de Aplicaciones Web de Invitados Diseño de SAS Módulos de SAS Diseño de SIMANU Módulos de Artículos Noticiosos Módulos de Apoyo Diseño de Módulos Web de Invitados Interfaces de MWI Plantillas de MWI Documentos CSS y JavaScript Otros recursos CONSTRUCCIÓN DEL SISTEMA Herramientas utilizadas y metodología de trabajo Resumen del proceso de construcción del sistema IMPLEMENTACIÓN DEL SISTEMA Migración de datos Capacitación del personal Otras tareas CONCLUSIONES REFERENCIAS

7 ÍNDICE DE TABLAS Tabla nº 1 Indicadores de codificación del sistema ÍNDICE DE FIGURAS Figura nº 1 Un típico editor HTML WYSIWYG Figura nº 2 Aplicación web de tres niveles Figura nº 3 Arquitectura web de tres niveles Figura nº 4 Arquitectura multinivel de un CMS Figura nº 5 Ejemplos de Portlets integrados a una página web Figura nº 6 Diagrama funcional de Prontus Figura nº 7 Diagrama funcional extendido de Prontus Figura nº 8 Arquitectura de un servidor portal basado en JSR Figura nº 9 Arquitectura de un servidor portal basado en JSR 268 (perspectiva de la aplicación) Figura nº 10 Arquitectura de un servidor portal basado en JSR Figura nº 11 Estructura de una página de portal Figura nº 12 Casos de uso de alto nivel Figura nº 13 Modelo de Dominio Figura nº 14 Arquitectura del sistema Figura nº 15 Arquitectura del sistema (perspectiva de la aplicación) Figura nº 16 Diagrama de secuencia del proceso de generación de la página web de cliente principal Figura nº 17 Estructura de áreas target de la página web cliente principal Figura nº 18 Composición de la página web cliente principal Figura nº 19 Diagrama de actividad del proceso de redefinición de los eventos click de las etiquetas <a> de la función capturar_eventos() Figura nº 20 Diagrama de actividad del proceso de redefinición de los eventos submit de los <form> de la función capturar_eventos() Figura nº 21 Diagrama de actividad de Control de Acceso y Validación de URLs de aplicaciones de invitado para una solicitud a la raíz del sitio

8 Figura nº 22 Diagrama de actividad de Control de Acceso y Validación de URLs de aplicaciones de invitado para una solicitud a una página concreta Figura nº 23 Estructura de contenedores de la página web de invitado multimediaexterna Figura nº 24 Diagrama de secuencia: Construcción página web de cliente genérica Figura nº 25 Objeto de diseño Agente Figura nº 26 Tablas involucradas en el proceso de registro de visitas de invitados Figura nº 27 Objetos involucrados en el proceso de administración de menús del sistema Figura nº 28 Estructura de las tablas involucradas en el proceso de administración de menús del sistema Figura nº 29 Diagrama de secuencia Editar Menú Figura nº 30 Diagrama de secuencia Ingresar Menú de Módulo Figura nº 31 Artefacto de diseño AdministradorPermisos Figura nº 32 Diagrama de clases del módulo Administrador de Permisos Figura nº 33 Estructura de las tablas involucradas en el módulo Administrador de Permisos Figura nº 34 Diagrama de secuencia Ingresar Usuario Figura nº 35 Diagrama de secuencia Editar Rol Figura nº 36 Diagrama de secuencia Inicio Proceso de Logueo Figura nº 37 Diagrama de secuencia Ingreso Sistema Administrativo Figura nº 38 Diagrama de secuencia Registro Módulo de Aplicación Web de Invitado Figura nº 39 Composición de la página de modo de diseño Figura nº 40 Panel de control general del modo de diseño Figura nº 41 Cuadros de control de módulos del modo de diseño Figura nº 42 Características del contenedor de diseño Figura nº 43 Diagrama de secuencia Creación de Página Web de Invitado Figura nº 44 Artefacto de diseño AdministradorSitios Figura nº 45 Objetos vinculados a la administración de sitios Figura nº 46 Estructura de las tablas involucradas en el módulo Administrador de Sitios Figura nº 47 Objetos de la lógica de negocios utilizados por el módulo de noticias Figura nº 48 Visión general del rendimiento del sistema

9 RESUMEN El siguiente trabajo de título propone una alternativa a los sistemas portales que integran manejadores de contenido, donde su principal valor radica en la implementación sobre tecnologías libres y ampliamente difundidas. Este sistema se diseñó y construyó para soportar el periódico online de la Universidad Austral de Chile, sin embargo por su versatilidad puede ser aplicado a otra problemática. Por ende se refiere a un sistema tipo portal que integra un manejador de contenidos de cualquier índole. Para concebir el diseño se requirió del estudio de la arquitectura de sistemas que implementan el estándar JSR 268 (Java Portlet Specifications), por lo que gran parte del trabajo se sustenta en dicho estándar. En cuanto a las funcionalidades provistas para el manejo de contenido, se indagó acerca de diseño de otros manejadores de contenido, y en los procesos productivos de los medios de prensa local, en particular refiriéndose al Departamento de Prensa y Medios de la UACh y al Diario Austral de los Ríos. Como resultado se plantea una visión de alto nivel de un sistema formado por dos subsistemas, un administrador de sitios web y un manejador de contenidos para ellos, donde el diseño es modular y orientado a objetos, por lo que es escalable y mantenible. 6

10 ABSTRACT The thesis project proposes an alternative to systems that integrate web content management, where their main value lies in the implementation of free and widely available technologies. This system was designed and built to withstand the online newspaper of the Universidad Austral de Chile, and based on it's versatility can be applied to other problems. Therefore relates to a portal like system that integrates a content management system of any kind. To conceive the design of the study, it was required the system architecture that implements the JSR 268 standard (Java Portlet Specifications), so much of the work is based on that standard. In terms of functionality provided for managing content, design inquired about other content management and production processes of local media, in particular referring to the Department of Press and Media UACh and The Journal, Austral de los Ríos. As a result it presents a high-level view of a system consisting of two subsystems, a web site administrator and content manager for them, where the design is modular, object-oriented, so it is scalable and maintainable. 7

11 1 INTRODUCCION 1.1 Antecedentes Generales Este proyecto de título consiste en construir un sistema web que cumpla con dos propósitos: brindar una estructura de soporte para la creación y administración de contenidos web, por parte de los usuarios administradores del contenido, y gestionar la estructura de páginas y archivos que las componen, de manera de facilitar el trabajo de los encargados del soporte técnico y minimizar la necesidad de realizar modificaciones profundas en su codificación. El sistema se desarrolló para soportar el diario online de la Universidad Austral de Chile (UACh), por lo que su diseño respondió a las necesidades puntuales de dicho proyecto, sin embargo a lo largo de este documento se planteará una solución genérica que permita adecuarse a cualquier otro propósito que involucre el manejo de contenido web. La contraparte de este proyecto es la Unidad de Relaciones Públicas de la Universidad; específicamente el Área de Prensa y Medios; quienes tienen a cargo la administración y soporte del diario online UACh. Este medio creado el 2002, ha sido fundamental desde entonces para los objetivos de esta unidad, ya que permite integrar y vincular a la Corporación con todos los estamentos de la Universidad y el entorno, a través de un sólo canal informativo. En la medida que los escenarios tecnológicos y culturales han evolucionado, el periódico online se ha adecuado para cumplir con su labor, por lo que desde su puesta en marcha se han desarrollado dos versiones y muchas modificaciones, donde la última intervención de consideración se realizó el año En ese entonces la mayoría de los desarrollos web en la región gozaban de gran estética, pero baja interactividad con el usuario [Bae03], ya que su estructura era estática (la interfaz de usuario se imprime una sola vez al cargar la página, no pudiendo adaptarse a nuevos requerimientos del usuario sin llevarlo a otra página diseñada para ese objetivo puntual). Ese es también el caso del diario online de la UACh, cuya tecnología sólo se constituye de bases de datos y servidores web que implementan PHP, 8

12 y despliegan contenido dinámico rescatado desde las base de datos y registrado desde un sistema administrador que permite actualizarlo, pero no permite configurar su presentación o interactuar con los visitantes del sitio. En cuanto a la estructura web, ésta se basa en una serie de plantillas que permiten homogenizar la presentación de la información. Lamentablemente se ha incurrido en una gran cantidad de parches, malas prácticas, duplicidad de códigos y falta de estructuración de los mismos, debido a la rotación del personal. Esto, sumado a la falta de documentación hace ya insostenible la mantención del sistema. Así, las plantillas surten efecto en etapa de diseño, pero muchas modificaciones al código se han realizado sobre el servidor operativo, y ya no existe conexión entre las páginas y sus plantillas. De este modo la actualización de la estructura web implica cambiar el código de todos los archivos en forma manual. Lo anterior empeora con muchas web desactualizadas o que ya no están en línea (pero permanecen en el servidor) y al no existir un árbol de navegación que grafique la vinculación entre las páginas, debe hacerse una búsqueda en el código de las mismas para identificar las estructura del sitio. La orientación que la unidad de Relaciones Públicas quiso dar al diario online pretende maximizar la entrega de contenido informativo propietario y generado por las otras unidades. Esta orientación exige modificaciones profundas que no pudieron ser efectuadas sobre el sistema anterior, por lo que apremiaba un nuevo desarrollo que cumpla con las expectativas y no contenga los vicios mencionados, que además se componga de una estructura base que no necesite mayores cambios para responder a las eventuales necesidades y que permita integrar nuevos desarrollos. Existen algunas consideraciones importantes que rigieron el desarrollo de proyecto. Al momento de esta publicación no existía personal de planta en la unidad, dispuesto al desarrollo o mantención del diario online, dichas tareas son encargadas a estudiantes de nivel avanzado, con conocimiento en desarrollo web. Tampoco existen políticas para el desarrollo de tecnologías de la información, sólo algunas normas provenientes de la dirección del Centro Informático de la UACh. En consecuencia, las tecnologías y herramientas utilizadas han sido determinadas de antemano por la Plataforma Internet de la UACh, con el fin de asegurar el mantenimiento del sistema que se construyó. Estas tecnologías son un servidor con CentOS 5.2 de sistema operativo, un Apache HTTP Server como motor web y una base de datos MySql 5.1, mientras que el lenguaje 9

13 a utilizar será PHP 5.3, sin desmedro de la utilización de cualquier librería en versión estable desarrollada bajo este lenguaje. 1.2 Contribución del Proyecto La realización de este trabajo de título responde específicamente a la problemática en cuestión, ya que factores como requisitos de tecnología y la inestabilidad del personal de soporte, no permiten implementar otras soluciones prediseñadas en forma íntegra. Así mismo, existen otras instituciones que comparten inconvenientes como no contar con un presupuesto específico para el desarrollo de tecnologías web (a pesar de la alta valoración con que las califican), o para su mantención. Por ende muchos de sus desarrollos son encargados a externos, que generalmente puntualizan en el problema y no visualizan o no se comprometen a dar una solución integral (obvian el hecho de que sus clientes muchas veces no saben especificar sus requisitos, o no interpretan sus problemas desde una perspectiva informática), persistente en el tiempo y coherente con el grado de informatización de la institución. Finalmente, es la naturaleza de este trabajo soslayar los inconvenientes mencionados proveyendo al Departamento de Prensa de la UACh de un sistema web que les permita cumplir con su labor a lo largo del tiempo, y no preocuparse del sistema en sí, más que para nuevos desarrollos que se incluirían en forma de módulos al sistema. 1.3 Impactos Considerando que el sistema, en esencia, puede sostener un desarrollo con una orientación distinta al del periódico online, la principal ventaja del sistema es que puede ser reutilizado en cualquier otro proyecto, en el cual si bien deberá diseñarse y codificarse otro contenido, brindará valor agregado en la forma de mantención y disminución en codificación, que se traducen en ahorro de tiempo y presupuesto. Otra gran ventaja es que a partir de la implementación con su pertinente capacitación, el Departamento de Prensa de la UACh podrá prescindir de personal altamente calificado, pues existen actualmente personas competentes en el área web, que siendo de planta podrán sostener el sistema por sí solos. 10

14 1.4 Objetivo General Construir e implementar el periódico online de la UACh a través de un portal web para el manejo del contenido. 1.5 Objetivos Específicos 1 Identificar y describir los paradigmas y las tecnologías asociadas a los sistemas de portales web y manejadores de contenido para periódicos online. 2 Seleccionar tecnologías para la realización del proyecto según los requisitos del Departamento de Prensa y de los estándares de la UACh. 3 Diseñar la arquitectura del sistema y la arquitectura de la información acorde a los objetivos y orientación periodística del Departamento de Prensa de la UACh. 4 Construir el sistema web tipo portal y el manejador de contenido para la publicación de la información del periódico online de la UACh. 5 Implementar y evaluar del sistema. 11

15 2 TECNOLOGIAS ASOCIADAS A LOS PERIODICOS ONLINE 2.1 Sistemas Manejadores de Contenido (CMS) Un sistema manejador de contenidos es un programa que permite crear una estructura de soporte para la creación y administración de contenidos por parte de los usuarios, aplicados principalmente en páginas web [Rob03]. Consiste en una interfaz que controla una o varias bases de datos donde se aloja el contenido del sitio. El sistema permite manejar (crear, editar, gestionar y publicar) de manera independiente el contenido y el diseño. Así, es posible darle en cualquier momento un diseño distinto al sitio, sin tener que formatear nuevamente el contenido, además de permitir la fácil y controlada publicación en el sitio a varios usuarios. Se define contenido como el texto, gráficas, videos, audios, etc., en general, todo lo que en esencia es la información a un sitio web [Fer07]. El contenido es embebido en las páginas web a través de un proceso de formateo que lo añade a una estructura previamente diagramada, dándole una tipografía y coherencia acorde al objetivo de un sitio web. Lo anterior, llamado diseño, se refiere a la estructura y lógica necesaria para permutar los elementos de una página web y que ayuda al usuario a comprender el contenido con una presentación cómoda, eficaz y atractiva Funcionalidades de un CMS James Robertson [Gar04] propone una división de la funcionalidad de los sistemas de gestión de contenidos en cuatro categorías: creación de contenido, gestión de contenido, publicación y presentación. Creación de contenido: Un CMS aporta herramientas para que los creadores sin conocimientos técnicos en tecnología web puedan concentrarse en el contenido. Lo más habitual es proporcionar un editor de texto WYSIWYG 1, en el que el usuario ve el resultado final mientras escribe. 1 WYSIWYG es el acrónimo de What You See Is What You Get (en inglés, "lo que ves es lo que obtienes"). Se aplica a los procesadores de texto y otros editores de texto con formato (como los editores de HTML) que permiten escribir un documento viendo directamente el resultado final. 12

16 Existen otras herramientas, como la edición de los documentos en XML 2, utilización de aplicaciones ofimáticas con las que se integra el CMS, importación de documentos existentes y editores que permiten añadir marcas (habitualmente HTML 3 ), para indicar el formato y estructura de un documento. Un CMS puede incorporar una o varias de estas herramientas, pero siempre tendría que proporcionar un editor WYSIWYG (ver figura nº 1) por su facilidad de uso y la comodidad de acceso desde cualquier ordenador con un navegador y acceso a Internet. Figura nº 1 Un típico editor HTML WYSIWYG Para la creación del sitio propiamente tal, los CMS aportan herramientas para definir la estructura, el formato de las páginas, el aspecto visual, uso de patrones, y un sistema modular que permite incluir funciones no previstas originalmente. Gestión de contenido: Los documentos creados se depositan en una base de datos central, donde también se guardan otros datos del sitio, cómo son los datos relativos a los documentos (versiones, autor, fecha de publicación y caducidad, etc.), datos y preferencias de los usuarios, la estructura de la web, etc. 2 XML, siglas en inglés de Extensible Markup Language (lenguaje de marcas extensible), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). 3 HTML, siglas de HyperText Markup Language (Lenguaje de Marcas de Hipertexto), es el lenguaje de marcado predominante para la construcción de páginas web. 13

17 La estructura de la web se puede configurar con una herramienta, que habitualmente presenta una visión jerárquica del sitio y permite modificaciones. Mediante esta estructura se puede asignar un grupo a cada área, con responsables, editores, autores y usuarios con diferentes permisos. Eso es imprescindible para facilitar el trabajo con un circuito de edición que va desde el autor hasta el responsable final de la publicación. El CMS permite la comunicación entre los miembros del grupo y hace un seguimiento del estado de cada paso del ciclo de trabajo. Publicación: Un documento aprobado se publica automáticamente cuando llega la fecha de publicación, y cuando caduca se archiva para futuras referencias. En su publicación se aplica el patrón definido para todo el sitio o para la sección concreta donde está situada, de forma que el resultado final es un sitio web con un aspecto visual consistente en todas sus páginas. La separación entre contenido y forma permite que se pueda modificar el aspecto visual de un sitio web sin afectar a los documentos ya creados, además de liberar a los autores de la preocupación por el diseño de sus páginas. Presentación: Un CMS puede gestionar automáticamente la accesibilidad del sitio, con soporte de normas internacionales de accesibilidad como WAI 4, y adaptarse a las preferencias o necesidades de cada usuario. También puede proporcionar compatibilidad con los diferentes navegadores disponibles en todas las plataformas (Windows, Linux, Mac, Palm, etc.) y su capacidad de internacionalización le permite adaptarse al idioma, sistema de medidas y cultura del visitante. El sistema se encarga de gestionar muchos otros aspectos, como son los menús de navegación o la jerarquía de una página dentro de la web, añadiendo enlaces de forma automática. También gestiona todos los módulos, internos o externos, que se incorporen al sistema. Todo eso con los enlaces correspondientes y siguiendo el patrón de diseño Administración de usuarios En la actualidad, los usuarios de un CSM pueden clasificarse en tres grandes grupos [Wcs]: 4 La Web Accessibility Initiative (WAI) o Iniciativa para la Accesibilidad Web es una rama del World Wide Web Consortium que vela por la accesibilidad de la Web. 14

18 Invitados: Son todos aquellos usuarios que acceden al contenido de un sitio a través de un navegador web y no poseen ningún tipo de permiso especial, sólo visualizan las páginas del sitio que no se encuentren restringidas. Por lo general y, en consideración de la naturaleza de un sitio web, éstos pueden tener ciertas libertades que le permiten acceder o no a ciertos contenidos, realizar algunas acciones administrativas como agregar contenido, gestionar comentarios en foros, etc. Estos privilegios suelen darse en caso que los usuarios se encuentren registrados en un sitio web y hayan sido dados de alta por otro usuario con las autorizaciones pertinentes. Usuarios Administrativos (Editores): Los editores de un CMS son usuarios que forman parte de la comunidad propietaria del sitio. Poseen autorización para crear o subir, editar y eliminar contenido del sitio. En algunos casos, también pueden gestionar a otras cuentas de usuarios, pero esta tarea suele ser atribuida a Administradores. Administradores: Son usuarios que poseen autorización para administrar íntegramente el contenido del sitio web, gestionar las cuentas de otros usuarios de menor o igual jerarquía, y administrar algunas propiedades del sitio referentes al diseño. Éstos pueden administrar la totalidad del sistema, pudiendo además de administrar el contenido y gestionar a los usuarios, configurar el sitio y sus propiedades, añadir y quitar nuevos diseños gráficos y módulos del sistema. En particular, los sistemas CMS destinados al manejo de diarios online agrupan a los usuarios en roles. Un rol es un conjunto de permisos que puede asignarse a un usuario; por su parte, un permiso es un parámetro que especifica si su poseedor dispone de acceso a una determinada función del sistema o a una parte de la interfaz de usuario del sistema. Normalmente, los roles se definen de modo que incluyan permisos que guarden cierta relación y suelen corresponderse con algún rol de la vida real [Nav01]. 15

19 Los roles que habitualmente son asignados en un CMS para diarios online, en orden jerárquico creciente son [Dia98]: Autores, Editores, Supervisores, Managers o Gestores, Administradores y SuperAdministradores Arquitectura La arquitectura típica de un CMS se desarrolla bajo la lógica de aplicaciones multinivel [Wika]. Este tipo de aplicaciones corresponden a la evolución de la arquitectura cliente/servidor 5 (también conocida como en dos niveles), en las que paulatinamente se agregaron nuevos niveles con el objetivo de separar las capas en interfaz de presentación, lógica de la aplicación y de datos (ver figura nº 2). La capa intermedia de lógica de aplicación, es el código que el usuario invoca para recuperar los datos deseados. La capa de interfaz de presentación recibe los datos y los formatea para mostrarlos adecuadamente. La división entre estas dos capas permite una gran flexibilidad a la hora de construir aplicaciones, ya que se pueden tener múltiples interfaces sin cambiar la lógica de la aplicación. La tercera capa consiste en los datos que gestiona la aplicación. Estos datos pueden ser cualquier fuente de información como una base de datos o documentos XML. Figura nº 2 Aplicación web de tres niveles 5 La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes. 16

20 La arquitectura de las aplicaciones Web suelen presentar un esquema de tres niveles (ver figura nº 3) [Veg02]. El primer nivel consiste en la capa de presentación que incluye no sólo el navegador, sino también el servidor web que es el responsable de dar a los datos un formato adecuado. El segundo nivel se refiere a algún tipo de programa o script. Finalmente, el tercer nivel proporciona al segundo los datos necesarios para su ejecución. Una aplicación Web típica recogerá datos del usuario (primer nivel), los enviará al servidor, que ejecutará un programa (segundo y tercer nivel) y cuyo resultado será formateado y presentado al usuario en el navegador (primer nivel nuevamente). Figura nº 3 Arquitectura web de tres niveles 6 La arquitectura multinivel de un CMS (ver figura nº 4) divide el segundo nivel en capas de servicios que permiten integrar distintas prestaciones en forma eficiente y confiable. 6 Tomada de 17

21 Figura nº 4 Arquitectura multinivel de un CMS Capa 1 Repositorio de Datos El repositorio de datos de un CMS es la capa que almacena toda la información de sitio, tanto el contenido a publicar en las páginas como los datos de configuración y administración. Se compone generalmente de alguno o la combinación de tres sistemas: base de datos (MySql, Postgres, etc.), documentos XML y sistema de archivos. Usualmente en las bases de datos (que pueden ser locales al servidor o remotas) se almacena la información propiamente tal [Bae08], que se publica en las páginas del sitio, mientras que una colección organizada de documentos XML almacena toda la información de configuración de las mismas (plantillas de diseño), y datos de configuración del sitio. Por su parte un sistema de archivos guarda directamente como archivos todo el contenido que no es del tipo texto (imágenes, animaciones Flash, archivos adjuntos y multimedia), en su forma original. Eventualmente, algunos sistemas almacenan este tipo de contenidos en bases de datos como formato binario. Capa 2 Edición Las funciones básicas de ingreso, edición y administración de contenidos se realizan a través de servicios web integrados al servidor. A través de ellos se generan archivos de texto plano basados en plantillas que pueden ser páginas HTML planas, páginas XHTML, o páginas dinámicas PHP, ASP, JSP, etc. En estos archivos, los contenidos son insertados tal como deben ser desplegados en el navegador, e integrados a servicios de la capa de presentación. 18

22 Capa 3 Presentación La capa de presentación es la encargada de integrar cualquier servicio dinámico tal como foros, encuestas, personalización de contenidos o de datos. Estos servicios pueden ser externos o internos, pudiendo incluso en algunos casos, integrarse a otros CMS. Capa 4 Navegador y Aplicaciones (App) La capa navegador aloja todas las aplicaciones destinadas a ser ejecutadas en el navegador del visitante, las cuales incluyen aplicaciones JavaScript, animaciones FLASH y Applets, entre otras. Mientras que a la capa de aplicaciones pertenecen todas las aplicaciones externas que se alimentan de datos generados por el sistema, como por ejemplo lectores RSS. Las aplicaciones externas pueden ser de muy variada concepción y cumplir objetivos muy diversos, teniendo en común sólo el alimentarse de datos a través del protocolo HTTP. 2.2 Sistemas de Portales Web El término Portal tiene como significado puerta grande, y su nombre hace referencia a su función u objetivo. Un portal web es un sitio web cuyo objetivo es ofrecer al usuario, de forma fácil e integrada, el acceso a una serie de recursos y de servicios, entre los que suelen encontrarse buscadores, foros, documentos, aplicaciones, compra electrónica, etc. Están dirigidos a resolver necesidades específicas de un grupo de personas o de acceso a la información y servicios de una institución pública o privada. En general aportan a la categorización de los datos diseminados en páginas web, para clasificarlos y agruparlos, haciendo converger la información implícita en ellos [Wikb]. Si bien el término se acuño sólo como una denominación para un sitio web que brinda distintos tipos de servicio, actualmente los portales web involucran tecnologías para soportar la integración de aplicaciones a nivel de interfaz de usuario tanto para sitios de Internet como de Intranet. Permitien el acceso a contenido y configuración personalizada de la interfaz de usuario. Tienen sus orígenes en portales tipo My Yahoo [Jpoa], que permiten que cada usuario disponga de una o varias páginas compuestas por portlets personalizables. 19

23 Los portlets son componentes modulares de interfaz de usuario gestionados y visualizados en un portal web. Los portlets producen fragmentos de código de marcado llamados markup que se agregan en una página de un portal [Wik08]. Siguiendo la metáfora de escritorio, una página de un portal se visualiza como una colección de ventanas de portlets que no se solapan, donde cada una muestra un portlet (ver figura nº 5). Por lo tanto un portlet (o colección de portlets ) se asemeja a una aplicación web que está hospedada en un portal. Como por ejemplo, un portlets de aplicación puede ser para el correo, la información meteorológica de un lugar que el usuario defina, un foro, noticias, etc. Figura nº 5 Ejemplos de Portlets integrados a una página web 7 La ventaja de este tipo de tecnología es su enfoque orientado a componentes, que favorece el desarrollo, el mantenimiento y la reusabilidad, ya que cada portlets es un desarrollo completamente diferente y aislado de otro. Un portlets debe ser almacenado en un servidor web especial [Jpob], que soporte la implementación de este tipo de tecnología. En los últimos años han surgido un gran número de servidores de portales que suelen proporcionar un portal pre-construido en el que es posible instalar portlets. Algunos ejemplos de estos servidores son BEA WebLogic Portal, IBM WebSphere Portal, Sun One Portal Server, Oracle Application Portal Server, SAP Portal, Vignette Application Portal, Microsoft SharePoint Portal Server, Red Hat Enterprise Portal, Jakarta Jeetspeed, exo Platform, entre otros. 7 Tomada de: 20

24 Actualmente los portlets son capaces de consumir información brindada por otras fuentes que implementen servicios web 8, realizando peticiones en forma de XML bajo protocolos SOAP 9 y recibiendo trozos de código en lenguaje de marcado como HTML o XML [Rui08]. Para ello fue necesaria la creación de estándares para lograr que los servidores de portales puedan compartir información. El último y más difundido de estos estándares es el JSR 268 publicado por la JAVA Fundation en su fase final el año Sistemas de periódicos online en Chile En cuanto a los periódicos online de Chile, en gran medida éstos utilizan un CMS chileno llamado Prontus [StE09], personalizado en muchos casos por la empresa Altavoz; quienes mantienen a diarios como Radio Cooperativa, La Nación, Los Mercurios de Valparaíso, Calama y Antofagasta, y la cadena de Diarios Australes, entre otros. También destaca Pandora, utilizado por emol, la versión electrónica de El Mercurio. El caso particular de Prontus se basa en sólo dos componentes constructivos; los artículos como unidades de información y las portadas como los contenedores donde esta información se publica para hacerla accesible desde la web. Prontus combina estos dos elementos con prestaciones internas y externas en la forma de portlets, que construyen la estructura visible del sitio web, la que será desplegada a los visitantes y utilizada por los operadores (responsables por la publicación del sitio web) para la edición de contenidos. Los operadores (como son llamados por sus desarrolladores) o roles de usuario utilizados por este CMS se organizan en tres niveles [Alta]: Administrador. Responsable por la estructura general y la organización de los operadores. Editor. Responsable de las portadas y tipos de artículo delegados en él, y de aprobar el trabajo de los periodistas (redactores) a su cargo. 8 Un servicio web (en inglés, Web service) es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones, generalmente, almacenadas en distintos servidores. 9 SOAP (signasen inglés de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. 21

25 Redactor. Responsable de los tipos de artículo delegados en él. Puede ingresar contenidos, pero no puede publicarlos, ya que esa tarea le corresponde al Editor. La información manejada por Prontus incluye texto con y sin formato, imágenes en todos los formatos, archivos descargables, animaciones Flash, y sonido y video Windows Media o Real Media. La combinación de estos tipos de contenido en artículos permite crear los elementos básicos que forman el sitio web. Estos elementos o tipos de artículo son, por ejemplo: Artículo General. Utilizado para publicar noticias, reportajes o información en general. Un artículo general suele contener varios campos de texto y varias imágenes. Rótulos. Usados para titular secciones en una portada. Menús. Usados para dirigir la navegación a otras portadas y construir así un árbol de contenidos. Vínculos. Links usados para dirigir al visitante hacia otro lugar del sitio web. Botones. Sinopsis de información presentada de manera atractiva. Banners. Elementos gráficos, generalmente animados, que llevan al usuario a otro URL. Galerías de fotos. Artículos con muchas fotografías. Fotografías animadas. Animación flash que despliega secuencialmente en una portada varias fotografías de un mismo artículo. Por último, el funcionamiento de Prontus se grafica la figura nº 6. Figura nº 6 Diagrama funcional de Prontus Tomada de: 22

26 Los contenidos ingresados en un formulario de ingreso de datos dan origen a una página de artículo, la cual es vinculada en una portada. La creación de ambas páginas web se basa en plantillas [Altb], dentro de las cuales el desarrollador define marcas o tags que serán interpretadas por Prontus para generar la visualización del contenido. Como repositorios de información se utiliza la base de datos (MySQL o SQLite) y archivos XML. Sobre este esquema básico de funcionamiento se agregan muchas otras prestaciones, las cuales son consistentes con la arquitectura, por ejemplo: Multiplantillas. Capacidad para escoger una plantilla diferente para artículos y portadas. Salidas RSS por portada, con parte o la totalidad del contenido publicado. Multivistas. Formatos distintos de salida orientados a dispositivos diferentes, tamaños de pantalla distintos, múltiples idiomas, etc. Postprocesos. Capacidad de extender las funcionalidades de Prontus cada vez que se guarda un artículo o una portada. Además, existen prestaciones que extienden las funcionalidades de Prontus sin intervenir su estructura. Estas prestaciones extra se realizan en la forma de portlets. Considerando estás funcionalidades, la figura nº 7 extiende el diagrama funcional de Prontus. Figura nº 7 Diagrama funcional extendido de Prontus Tomada de: 23

27 3 EL ESTANDAR JSR 268 Este capítulo esta basado completamente en el estándar JSR 268, extrayendo las principales características que competen al proyecto. Puede obtenerse en la dirección: Definiciones Definición de Portal: Un portal es una aplicación web que comúnmente ofrece personalización, inicio de sesión único, la integración de contenidos de diferentes fuentes en la página web y de la capa de presentación de sistemas de información de distintos servidores. Un portal puede tener características de personalización sofisticados para proporcionar contenido personalizado para los usuarios. Las páginas del portal pueden tener simultáneamente diferentes portlets para la creación de contenido para diferentes usuarios. Definición de Portlet: Un portlet es un componente de la tecnología Java para la web, gestionada por un contenedor de portlet, que procesa las peticiones y genera contenido dinámico. Los portlets son utilizados por los portales como componentes integrables de interfaz de usuario que proporcionan una capa de presentación a los sistemas de información. El contenido generado por un portlet se llama fragmento. Un fragmento es una pieza de marcado (como HTML, XHTML, WML) adherida a ciertas reglas y se puede sumar a otros fragmentos para formar un documento completo. El contenido de un portlet suele sumarse con el contenido de otros portlets para formar la página del portal. El ciclo de vida de un portlet es gestionado por el contenedor de portlet. Los clientes web interactúan con los portlets a través de solicitudes y consiguientes respuestas por parte del portal. Normalmente, los usuarios interactúan con el contenido producido por los portlets, por ejemplo, siguiendo los enlaces o entregando formularios, dando lugar a acciones portlet, que de ser recibidas por el portal, producen una respuesta que se transmite al portlet para las respectivas interacciones con el usuario. 24

28 El contenido generado por un portlet puede variar de un usuario a otro dependiendo de la configuración de usuario para el portlet. Definición de Contenedor de Portlet: Un contenedor de portlet inicia portlets y les proporciona el entorno de ejecución necesario. Un contenedor de portlet contiene portlets y gestiona su ciclo de vida. También proporciona almacenamiento persistente para las preferencias del portlet. Un contenedor de portlets recibe peticiones desde el portal para ejecutar las solicitudes de los portlets gestionados por él. Un contenedor de portlet no es responsable de la agregación de los contenidos producidos por los portlets. Es responsabilidad del portal manejar la agregación. Un portal y un contenedor de portlet pueden construirse juntos como un sólo componente de un conjunto de aplicaciones o como dos componentes separados de una aplicación de portal. 3.2 Arquitectura y funcionamiento de un portal La figura nº 8 grafica la arquitectura de un servidor portal basado en el estándar JSR 268. A partir de ella se ilustrará el funcionamiento del sistema portal. Figura nº 8 Arquitectura de un servidor portal basado en JSR

29 El servidor del portal (1) utiliza portlets para generar las páginas del portal a partir del fragmento de marcado que cada uno produce. Todos los fragmentos de la página se agregan para formar la página final del portal. Los portlets son cargados en un contenedor de portlets (2). El contenedor de portlet s es responsable de la gestión del ciclo de vida de los portlets cargados y define el contexto de cada portlet. Las solicitudes del cliente son recibidas por el servidor del portal a través del contenedor de portlets, y se envían a un portlet de destino, dependiendo de la configuración de la página del portal. Portlets remotos son accedidos a través de un proxy de portlets (3), que actúa como consumidor WSRP 12. Las solicitudes al Proxy son reenviadas al portlet remoto mediante llamadas WSRP. El servidor del portal remoto tiene que actuar como productor WSRP (4), delegando la elaboración de la respuesta al portlet remoto solicitado (5). La figura nº 9 muestra la arquitectura de servidor del portal desde el punto de vista de las aplicaciones web. El estándar JSR 268 define que los servidores de portales deben ser compatibles con J2EE, servidor que permite el despliegue de aplicaciones web en un contenedor de servlets. Una aplicación web define un contexto de aplicación en tiempo de ejecución para los servlets solicitados, que puede ser compartida por ellos, al igual que las sesiones de usuario. El servidor del portal se ejecuta como una aplicación web especial (1), definiendo un despachador central de servlets (2), que entrega las páginas solicitadas a un navegador en el cliente (3). La estructura y estilo gráfico de una página del portal, y los portlets incluidos en ella, se configuran en el descriptor de páginas del portal (4). Las aplicaciones web de una página se constituyen a partir de portlets locales (5) y portlets remotos (6). Sólo los portlets de una misma aplicación web comparten el contexto de ejecución y sesiones de usuario. La figura nº 10 muestra la estructura de un servidor de portal desde la perspectiva de intercambio de datos. En ella es posible ver como portlets de apoyo para el intercambio de datos se instalan como cualquier portlet, y como éstos son gestionados por el contenedor de portlets. 12 Web Services for Remote Portlets (WSRP) es un protocolo estándar diseñado para la comunicación con portlets remotos. 26

30 Figura nº 9 Arquitectura de un servidor portal basado en JSR 268 (perspectiva de la aplicación) Figura nº 10 Arquitectura de un servidor portal basado en JSR

31 Los portlets instancian a portlets de apoyo para accesar los puertos de salida de datos de recursos, permitiendo a los primeros generar fragmentos de marcado que son incrustados en páginas HTML (4). Un puerto de salida de datos tiene un nombre, un tipo de dato y contiene los datos que están disponibles en un recurso (como una base de datos) para este puerto. Un portlet incorpora referencias de URL al portlet apoyo que solicitó y al archivo de datos que éste último obtuvo del puerto de salida de datos (7). El proceso se inicia con un navegador (1) que solicita al servidor del portal una página web con información agregada de varios portlets. La solicitud será procesada por el servidor portal de aplicaciones web (2), que utiliza al descriptor de páginas de portal predefinido (3) para determinar los portlets y portlets de apoyo que necesita para construir la página solicitada. Cada portlet devuelve un fragmento de página HTML, que se agregará a la página web, mientras que los portlets de apoyo entregarán los fragmentos de marcado solicitados por los portlets de la página web que los requieran. Antes de que la página construida se devuelva al cliente web, es transformada por el filtro de intercambio de datos (5), que se implementa como parte del servidor portal de aplicaciones web. El filtro extrae la descripción del puerto de salida y lo reemplaza con un hipervínculo que se rige por la lógica de intercambio de datos de aplicación. El enlace permite que el cliente envíe datos al puerto de salida accesado por el portlet de apoyo. Una cuestión importante para el intercambio de datos, es el registro de todos los portlets de apoyo con los puertos de salida específicos que accederá. El registro (6) se encuentra en el servidor portal de aplicaciones web. El registro también mantiene información sobre las fuentes de datos, que se utilizan para definir el contacto permanente entre portlets. Cada portlet se registra la primera vez que se muestra en la página, y a través del filtro de intercambio de datos, que extrae la información necesaria de la página web del portal recién construida. 3.3 Elementos de las páginas de portal Un portlet genera fragmentos de marcado (por lo general HTML). Un portal puede añadir un título, botones de control y otros componentes al fragmento de marcado 28

32 generado por el portlet, este nuevo fragmento se denomina ventana de portlet. Entonces, el portal puede agregar diferentes ventanas portlet a un documento hasta formar una página del portal. La estructura de una página de portal se ejemplifica en la figura nº 11. Figura nº 11 Estructura de una página de portal 13 La página de portal que se grafica, se compone de diferentes fragmentos de marcado, generados por distintos portlets (eventualmente, un mismo portlets puede aportar con varios fragmentos de marcado para una misma página de portal), dichos trozos de marcado deben coexistir sin problemas y no deben interactuar entre ellos. Cualquier interacción necesaria entre portlets se realiza en el sistema portal y a través del contenedor de portlets, nunca en la interfaz de usuario. 3.4 Relación del estándar JSR 268 con el proyecto El estándar JSR 268 fue el principal referente al momento de diseñar el sistema portal a construir. Si bien la tecnología seleccionada no permite implementar a cabalidad el estándar, los puntos que se han mencionado; -estructura de una página de portal; - arquitectura y funcionamiento de un portal; - ciclo de vida de un portlets -; son un modelo para el diseño de un portal constituido por módulos alojados en el servidor, y que se comporten como aplicaciones web independientes para el cliente. 13 Adaptada de: 29

33 4 CICLO DE VIDA DEL DESARROLLO 4.1 Introducción El Área de Prensa y Medios de la UACh (APYM) tiene por tarea fundamental reportear, generar, archivar y dar a conocer toda la información de carácter noticiosa que emana del acontecer y propio quehacer de la Universidad. Para ello cuenta con un equipo de profesionales, que además de generar las noticias, administra la información noticiosa suministrada por las diferentes unidades que componen a la Universidad, que a su vez son también concebidas por periodistas externos. Estos profesionales trabajan para las respectivas Facultades que los contratan, brindando apoyo al APYM en la generación de noticias de carácter corporativa. En general, toda la información que puede considerarse de interés general (que es de incumbencia del público en general, y no sólo de la comunidad universitaria), es archivada en el APYM para su edición y publicación a través de los medios de comunicación que maneja el área, los cuales típicamente han sido el periódico online y la Revista Actualidad. Sin embargo, mucha de esa información no es finalmente publicada por no ser apropiada para el público externo (según las autoridades universitarias), pero que si debería ser conocida por la comunidad universitaria. En consecuencia, era necesaria la creación de un medio que albergara información que concerniera exclusivamente al público universitario. Por otra parte, algunos de los hechos e información contingente (festival de cine en Valdivia, reacreditación institucional, etc.) merecían un trato especial, lo que daba origen a muchos especiales de prensa, publicados en medios web dispuestos especialmente para dicho cometido, e involucrando nuevos desarrollos. En este contexto, cada sitio (especial de prensa) debía manejar su propio contenido, por lo que una misma nota de prensa que atañía a varios sitios, debía crearse independientemente en cada uno, con los costos que ello significaba, la pérdida de tiempo y espacio de almacenamiento. 4.2 Elección del ciclo de vida del desarrollo La situación anterior da cuenta de dos problemas fundamentales, la necesidad de un sistema que permita construir y administrar distintos sitios web (desde ahora SAS, 30

34 Sistema Administrador de Sitios Web), y un sistema que permita manejar contenido por parte de los periodistas externos y del APYM (desde ahora SIMANU, Sistema Manejador de Noticias UACh), para su publicación en uno o más sitios. A contar de reuniones preliminares, y debido a lo ya establecido, se solicitó el desarrollo de dos sistemas que pudiesen en conjunto dar solución a la problemática. Lo descrito, sugirió utilizar el Proceso Unificado de Rational 14 (Rational Unified Process en inglés, habitualmente resumido como RUP), el cual es un proceso de desarrollo de software que junto con el Lenguaje Unificado de Modelado UML, constituye una metodología estándar para el análisis, implementación y documentación de sistemas orientados a objetos. RUP divide el proceso en cuatro fases; Iniciación, Elaboración, Construcción y Transición; dentro de las cuales se realizan diversas iteraciones, que se componen de etapas de modelado del negocio, toma de requisitos, análisis y diseño, implementación, pruebas y despliegue, según lo amerite el proyecto. Este ciclo de vida es pertinente al proyecto, ya que luego de la fase de iniciación (en la cual se concentra y analiza el problema), permite determinar en la fase de elaboración la línea base de arquitectura que regirá la estructura, comportamiento e interacción entre SAS y SIMANU, y así abocarse posteriormente a varios ciclos de construcción para ambos sistemas y otros módulos complementarios, que requerirán nuevos análisis y diseños. Al fin de cada ciclo de construcción se entregará un prototipo funcional que permitirá poner en funcionamiento el sistema, para finalizar con la etapa de transición que perfeccionará el sistema en su conjunto. Por último, mencionar que acorde a la metodología RUP, se utilizó para el diseño del sistema la herramienta Racional Rose Enterprise Edition, incorporando la extensión WAE, desarrollada por Jim Conallen en 1998 (desarrollador de Rational Software), para la diagramación de UML enfocada en orientación a objetos para web. 14 Rational Software es actualmente conocida como una familia de software de IBM para el despliegue, diseño, construcción, pruebas y administración de proyectos en el proceso desarrollo de software. 31