Geoliferay: plataforma para la gestión de IDEs colaborativas dirigidas al usuario

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas. Facultad Matemática, Física y Computación Departamento de Ciencia de la Computación. Tesis presentada en opción al grado académico de Máster en Ciencia de la Computación. Geoliferay: Plataforma para la gestión de IDEs colaborativas dirigidas al usuario Autor: ING. IRADIEL FERNÁNDEZ DELGADO Tutor: DR. CARLOS PÉREZ RISQUET Cotutor: DR. JOSÉ L. CAPOTE FERNÁNDEZ. Santa Clara 2015 “Año 57 de la Revolución”.

(2) AGRADECIMIENTOS.

(3) DEDICATORIA.

(4) ABSTRACT RESUMEN Los portales web son la vía de entrada a una Infraestructura de Datos Espaciales (IDE). Administrar una IDE implica gestionar diferentes servicios en pos de satisfacer tecnológicamente los requerimientos de la misma y presentar la información geoespacial deseada. La Web 2.0 es la representación de la evolución de las aplicaciones tradicionales hacia aplicaciones web orientadas al usuario final. Este nuevo enfoque ha impactado positivamente en las áreas de la información donde se ha aplicado. La participación de los usuarios en la generación de contenidos en los modelos actuales de IDE, y específicamente en la Infraestructura de Datos Espaciales de la República de Cuba (IDERC) es casi nula, en gran medida debido a la complejidad de su administración. Aunque existen definiciones de los requerimientos que debería tener una solución de IDE colaborativa desde una perspectiva de usuario, no existe un modelo o metodología que guíe su desarrollo. Este trabajo expone el diseño e implementación de una plataforma que permita la construcción de portales web espaciales que soporten la gestión de IDEs colaborativas dirigidas al usuario basada en estándares abiertos. Se define una arquitectura que integra varios proyectos líderes del software libre y el contexto geoespacial, logrando una interacción y relación entre ellos tributando a la filosofía de arquitectura participativa. La solución tiene como resultado práctico la implementación y soporte del Portal Nacional de la IDERC, estableciéndose como un punto de acceso a la información espacial basado en la participación y contribución de los usuarios..

(5) TABLA DE CONTENIDOS. TABLA DE CONTENIDO ÍNDICE DE FIGURAS ..................................................................................................... 7 ÍNDICE DE TABLAS ..................................................................................................... 10 INTRODUCCIÓN ............................................................................................................ 1 CAPÍTULO I PORTALES WEB GEOESPACIALES DIRIGIDOS AL USUARIO: BASES CONCEPTUALES ........................................................................................................... 8 1.1. Infraestructuras de Datos Espaciales. ........................................................................ 8. 1.2. Modelos actuales de Infraestructura de Datos Espaciales. ......................................... 8. 1.3. Portal Web.................................................................................................................11. 1.4. Portal web geoespacial..............................................................................................12. 1.5. Arquitectura de Referencia de Portales Geoespaciales OGC ....................................13. 1.6. Web 2.0 .....................................................................................................................14. 1.7. Desafíos y riesgos de las IDEs 2.0 apoyadas en la Web 2.0 .....................................16. 1.8. Principios que caracterizan a las aplicaciones IDE 2.0 ..............................................17. 1.9. Geoportal 2.0 .............................................................................................................18. 1.10. Conclusiones del Capítulo I .......................................................................................19. CAPÍTULO II ARQUITECTURA PARA EL DESARROLLO DE UN GEOPORTAL 2.0, PROYECTO GEOLIFERAY .......................................................................................... 21 2.1. Introducción ...............................................................................................................21. 2.2. Liferay como plataforma de desarrollo del proyecto Geoliferay ..................................21. 2.2.1. Entorno de desarrollo y extensión de Liferay .......................................................................................24. 2.2.2. Interacción entre portlets ....................................................................................................................32. 2.3 2.3.1. Componentes necesarios para la construcción del geoportal ....................................34 Software seleccionados para la construcción del geoportal ................................................................36. Tocororo ...............................................................................................................................43 2.4. Integración de las plataformas de software, definición de una arquitectura de. integración de Geoliferay ......................................................................................................45 2.4.1. Mecanismo de notificación de cambios en los datos en Geoliferay ....................................................47. 2.4.2. Integración de Liferay y Tocororo con el mecanismo de autenticación común: CAS ...........................52. 2.5. Conclusiones del Capítulo II ......................................................................................54.

(6) TABLA DE CONTENIDOS CAPÍTULO III IMPLEMENTACIÓN DE LAS APLICACIONES DE LA PLATAFORMA GEOLIFERAY ............................................................................................................... 55 3.1. Implementación de portlets geoespaciales ................................................................55. 3.1.1. Portlet Visor Genérico de Mapas .........................................................................................................56. 3.1.2. Portlet de Rutas ...................................................................................................................................61. 3.1.3. Portlet Buscador de Direcciones Postales ............................................................................................65. 3.1.4. Portlet Buscador de Nombres Geográficos ..........................................................................................68. 3.1.5. Portlet Buscador de Puntos de Interés .................................................................................................70. 3.1.6. Portlet Cliente Servicio de Catálogos ...................................................................................................75. 3.1.7. Portlets de Tocororo.............................................................................................................................79. 3.2. Caso de Estudio Portal Geoespacial Nacional de la Infraestructura de Datos. Espaciales de la República de Cuba .....................................................................................91 3.3. Conclusiones del Capítulo III .....................................................................................97. CONCLUSIONES.......................................................................................................... 98 RECOMENDACIONES ............................................................................................... 100 REFERENCIAS BIBLIOGRÁFICAS ............................................................................ 101 ANEXOS ..................................................................................................................... 108.

(7) ÍNDICE DE FIGURAS. ÍNDICE DE FIGURAS Figura 1: Arquitectura conceptual de una IDE. Fuente: (Gould, 2008) ............................ 9 Figura 2: Arquitectura de servicios web. Fuente: (Delgado Fernández T. , Infraestructuras de Datos Espaciales en países de bajo desarrollo tecnológico. Implementación en Cuba. s.l. : Tesis presentada en opción al grado científico de Doctor en Ciencias Técnicas, 2005) ......................................................................................... 10 Figura 3: Arquitectura de Referencia de Portales Geoespaciales. Fuente: (Open Geospatial Consortium Inc, 2004) ................................................................................. 14 Figura 4: Cuadrante Mágico de Gartner de Portales Horizontales. Fuente: (Gartner, 2014) ............................................................................................................................. 22 Figura 5: Nueva perspectiva que forma parte de Liferay IDE. Fuente: (Richard Sezov J. , 2012) ........................................................................................................................... 25 Figura 6: Distribución de portlets en una página. .......................................................... 26 Figura 7: Estructura de carpeta de un proyecto portlet. Fuente: (Richard Sezov J. , 2012) ............................................................................................................................. 28 Figura 8: Service Builder, en la parte superior de Hibernate y Spring generando el código y las configuraciones necesarias. Fuente: (Richard Sezov J. , 2012). ............... 30 Figura 9: Diseño de AlloyUI. (Richard Sezov J. , 2012) ................................................ 32 Figura 10: Esquema de un geoportal incluyendo los servicios OGC necesarios y servicios. de. catálogos. que. conforman. su. arquitectura.. Fuente:. (Landmap. Geoknowledge) ............................................................................................................. 35 Figura 11: Central Authentication Security. Fuente: (JASIG, 2009) .............................. 42 Figura 12: Arquitectura del SDK de Tocororo ............................................................... 45 Figura 13: Distribución de los componentes de software en la arquitectura del geoportal. ...................................................................................................................... 46.

(8) ÍNDICE DE FIGURAS Figura 14: Arquitectura de Geoliferay, que soporta los requerimientos de un Geoportal 2.0. ................................................................................................................................ 47 Figura 15: Clases implementadas en compatibilidad con Geotools. ............................. 49 Figura 16 Tocororo como un origen de datos de Geoserver. ........................................ 50 Figura 17: Capas de Tocororo disponibles en Geoserver. ............................................ 50 Figura 18: Características de las aplicaciones del geoportal. ....................................... 56 Figura 19: Portlet Visor Genérico de Mapas. ................................................................ 57 Figura 21: Portlet de Rutas, Interacción con el portlet Visor Genérico de Mapas. ........ 64 Figura 22: Vista Rutas Salvadas mostrando las rutas almacenadas del usuario. ......... 65 Figura 23: Portlet Buscador de Direcciones Postales. .................................................. 65 Figura 24: Portlet Buscador de Direcciones mostrando resultados de una búsqueda. . 67 Figura 25: Visualización de resultados sobre el portlet Visor Genérico de Mapas. ....... 68 Figura 26: Portlet Buscador de Nombres Geográficos, mostrando el resultado de una búsqueda. ..................................................................................................................... 69 Figura 27: Ficha técnica de un nombre geográfico específico. ..................................... 69 Figura 28: Diagrama Entidad-Relación del portlet Punto de Interés. ............................ 71 Figura 29: Vistas del portlet Buscador de Puntos de Interés. ........................................ 71 Figura 30: Categorías para filtrar las búsquedas. ......................................................... 72 Figura 31: Búsqueda por posición. ................................................................................ 73 Figura 32: Resultados búsqueda por localidad y por posición. ..................................... 74 Figura 33: Información detallada de un lugar de interés. .............................................. 74 Figura 34: Lugar de interés visualizado en el Portlet Visor Genérico de Mapas. .......... 75 Figura 35: Portlet Cliente Servicio de Catálogos. .......................................................... 76 Figura 36: Detalles del metadato. ................................................................................. 77 Figura 37: Diagrama de clases del Portlet Cliente Servicio de Catálogos. .................... 78.

(9) ÍNDICE DE FIGURAS Figura 38: Portlet Panel de Control de Tocororo. .......................................................... 80 Figura 39: Vista Principal del Portlet Búsqueda de Contenido. ..................................... 81 Figura 40: Vista Configuración del Portlet Búsqueda de Contenido. ............................. 82 Figura 41: Vista Configuración del Portlet Visualizador de Contenido. ......................... 84 Figura 42: Portlet Visualizador de Contenido, mostrando un contenido de tipo mapa. . 85 Figura 43: Portlet Visualizador de Contenido, mostrando un contenido de tipo fuente de datos. ............................................................................................................................ 85 Figura 44: Portlet Visualizador de Contenido, mostrando un contenido de tipo gráfico. 86 Figura 45: Portlet Visualizador de Contenido, mostrando una lista de contenidos de tipo de mapa, el portlet está configurado para mostrar contenido de tipo mapa y recibió un evento con un tipo de contenido distinto, gráfico o fuente de datos. ............................. 87 Figura 46: Tablas adicionadas a la base de datos de Tocororo para persistir la clasificación de los contenidos. ..................................................................................... 88 Figura 47: Portlet Visualizador de Contenido, habilitado para que el usuario puede emitir su clasificación por el contenido visualizado. ...................................................... 90 Figura 48: Página de Inicio del Geoportal de la IDERC. ............................................... 92 Figura 49: Página de Inicio del Geoportal de la IDERC. ............................................... 93 Figura 50: Portlets de Geoliferay que conforman el Callejero de IDERC. ..................... 93 Figura 51: Aplicación Callejero de Cuba. ...................................................................... 94 Figura 52: Aplicación Visor Genérico. ........................................................................... 95 Figura 53: Aplicación Catálogo de Metadato................................................................. 96 Figura 54: Aplicación Diccionario de Nombres Geográficos. ........................................ 97.

(10) ÍNDICE DE TABLAS. ÍNDICE DE TABLAS Tabla 1: Comparación IDE 1.0 vs IDE 2.0. Fuentes: (Maguire D. , 2008) (Maguire D. , 2006) ............................................................................................................................. 18 Tabla 2: Descripción de las carpetas de un portlet. Fuente (Richard Sezov J. , 2012) . 28 Tabla 3: Ficheros de configuración específicos de los proyectos portlets de Liferay. Fuente: (Richard Sezov J. , 2012) ................................................................................. 28 Tabla 4 Tabla ratings, almacena la cantidad de votos por cada tipo de clasificación emitidas sobre un contenido específico, así como el promedio ponderado de las clasificaciones. .............................................................................................................. 88 Tabla 5 Descripción de la Tabla rating_user. ................................................................ 89.

(11) INTRODUCCIÓN. INTRODUCCIÓN En la sociedad actual el incremento en los niveles de información es un aspecto que enriquece y a su vez complejiza los procesos relacionados con la toma de decisiones. Por otra parte un elevado por ciento de la información tratada por instituciones y empresas tiene en alguna medida relación con algún contexto espacial. De ahí que la información geográfica sea vital para la toma de decisiones acertadas a escala local, regional y global. Son muchas las áreas de la sociedad que se benefician de este tipo de información, de conjunto con las infraestructuras asociadas que sustentan el descubrimiento, acceso y uso de esta información (Nebert, 2004) . Una Infraestructura de Datos Espaciales (IDE) abarca las políticas, tecnologías, estándares. y. recursos. humanos. necesarios. para. la. efectiva. recolección,. administración, acceso, entrega y utilización de los datos espaciales a diferentes niveles en función de la toma de decisiones económicas, políticas y sociales, y del desarrollo sostenible (Delgado T. C., 2007), (Delgado Fernández T, 2009), (Rajabifard & Willianson, 2001). Desde su surgimiento, se ha propuesto a la IDE como un medio para promover el uso de la información geográfica (IG). La idea consistía en que a través de la coordinación y documentación, la IDE haría más fácil el acceso a la IG, tanto a los profesionales como a los ciudadanos comunes. Sin embargo, los datos geoespaciales son todavía intrínsecamente difíciles de compartir y visualizar para quien no posee entrenamiento en Sistemas de Información Geográfica (SIG) (Hudson-Smith, 2008) . El modelo actual de IDEs contempla organizaciones formales encargadas de producir y proveer la información geoespacial, mientras que los usuarios son receptores pasivos de información. La Web 2.0 es la representación de la evolución de las aplicaciones tradicionales hacia aplicaciones web enfocadas al usuario final. Según (O'Reilly & Battelle, 2009), es una actitud y no precisamente una tecnología. Esta cultura se ha ido diversificando en productos centrados en el usuario, que son cada vez más populares (Wikis, YouTube, Flickr, Blogs, BitTorrent) y en los últimos años han surgido aplicaciones que acercan varias de las funcionalidades de los SIG a millones de [1].

(12) INTRODUCCIÓN nuevos usuarios, elevando la conciencia de la importancia de la localización y la geografía en todos los aspectos de nuestra vida (Google Earth1, Google Maps2, OpenStreetMap3), (Lemmens & Deng, 2008), (Lake, 2009), (Maguire D. , 2008). Las primeras etapas de la evolución de las IDEs han sido más bien “empujadas” por las Tecnologías de la Información y las Comunicaciones que “haladas” por la demanda de los usuarios. El paso de las IDEs centradas en datos a aquellas más orientadas a los usuarios es una necesidad cada vez más aceptada. (Delgado Fernández & Castellanos Abella, 2006), (Delgado & Capote, Semántica Geoespacial y descubrimiento de conocimiento para Desarrollo Sostenible, 2009), (Goodchild, 2007). La Infraestructura de Datos Espaciales de la República de Cuba (IDERC), desde su surgimiento estuvo orientada a centros de datos, según el Modelo Integrado de IDE basada en Centros de Datos (MI-IDE-CD) (Delgado & Cruz Iglesias, Construyendo Infraestructuras de Datos Espaciales a nivel local, 2009), (Delgado Fernández T. , Infraestructuras de Datos Espaciales en países de bajo desarrollo tecnológico. Implementación en Cuba. s.l. : Tesis presentada en opción al grado científico de Doctor en Ciencias Técnicas, 2005). Este modelo está soportado sobre los principios de Procesamiento Abierto Distribuido (ODP) del estándar ISO/IEC 10746, el modelo de referencia de la serie ISO 19100 para la Información Geográfica y la Geomática (ISO/FDIS 19101, 2001) y otros elementos de estándares desarrollados por el consorcio OGC4. Uno de los principios básicos de este modelo es el enfoque de búsqueda centralizada con administración distribuida validado para escenarios caracterizados por bajas infraestructuras tecnológicas y de conectividad Web, poca dispersión de proveedores, y bajos recursos financieros. A partir de analizar el índice de alistamiento de diferentes países en pos del gobierno electrónico se evidencia para. 1. http://www.google.com/earth/. 2. http://maps.google.com/. 3. http://www.openstreetmap.com. 4. Open GeoSpatial Consortium http://www.opengeospatial. org. [2].

(13) INTRODUCCIÓN el caso de Cuba un elevado índice de capital humano (0.90) contra bajos índices de infraestructura de telecomunicaciones (0.051) y de conectividad Web (0.166) (Delgado Fernández T. , Infraestructuras de Datos Espaciales en países de bajo desarrollo tecnológico. Implementación en Cuba. s.l. : Tesis presentada en opción al grado científico de Doctor en Ciencias Técnicas, 2005). Los avances en las tecnologías de la información han tenido un impacto en las IDEs. En la Tesis de Doctorado “Modelo de Infraestructura de Datos Espaciales basada en Computación en la Nube (IDEaaS)” (Cruz Iglesias, 2011) se propone un nuevo enfoque a la perspectiva de ingeniería de una IDE, donde se modifica la distribución de los servicios tradicionales y se integra a las capas del modelo de servicios de la Nube, con lo que se logra una arquitectura escalable y de alto rendimiento. Se destaca la capa de plataforma como servicio (PaaS), que facilita la provisión de datos espaciales mediante servicios web, ya que los proveedores no tienen que asimilar ni implementar ningún software, mejorando así la disponibilidad de la información necesaria para la toma de decisiones a todos los niveles. En esta investigación el experimento se desarrolló orientado a la aplicación MovilWeb del Sistema de Gestión y Control de Flotas, quedando como recomendación realizar el despliegue total de la IDERC en la Nube basado en el modelo IDEaaS, así como continuar extendiendo la plataforma IDEaaS para incorporar la creación de otros tipos de servicios (servicios de catálogos y servicios de geoprocesamiento), debido a la factibilidad comprobada que representa el despliegue de los servicios de mapas en la Nube al lograrse buenos parámetros de calidad de los servicios. Por otra parte, la IDERC y sus aplicaciones han comenzado a disparar la demanda de la Información Geográfica para la sociedad (Delgado & Cruz Iglesias, Construyendo Infraestructuras de Datos Espaciales a nivel local, 2009). Sin embargo, la respuesta de las entidades encargadas de proveer dicha información no tiene la capacidad para enfrentar esta demanda en los tiempos que se exigen. A nivel local, se necesita proveer recursos a la sociedad, que permitan la inclusión de cada vez más usuarios en el proceso de la informatización de la propia sociedad y en ese contexto es necesario estimular el sector de la geoinformación. [3].

(14) INTRODUCCIÓN En la actualidad los portales web son la más popular y extensiva tecnología usada para implementar las IDEs a los distintos niveles: local, regional, nacional e internacional (Halil Akinci, 2009). Uno de los aspectos poco desarrollados en las soluciones de geoportales actuales y específicamente en el portal de la IDERC es la interacción directa con la información que producen los usuarios, incorporando la filosofía de la Web 2.0. De ahí que se plantee la necesidad de un geoportal, que contribuya a acercar a los actores que forman la comunidad de la IDERC y a fortalecer esa comunidad desde la implementación de una nueva oferta de posibilidades tecnológicas, que la aglutine y le permita desempeñar un papel más activo en este campo. Esta investigación se desarrolla en la Agencia GeoMIX de la empresa Cartografía y Soluciones Geomáticas, GeoSí. Esta empresa desde el surgimiento de la IDERC ha sido la responsable de los servicios que provee la misma, de ahí que este trabajo está orientado a lograr un producto que permita mejorar la gestión de la IDERC, en pos de satisfacer a sus usuarios. En la actualidad los servicios de la IDERC se encuentran en proceso de despliegue hacia la Nube de TRANSNET, la red del Ministerio de Transporte, garantizando un grado superior de escalabilidad de infraestructura física. En este entorno se hace necesario el desarrollo de una plataforma de IDE, que pudiera constituir en sí misma un servicio a los usuarios de la IDERC, que permita el desarrollo futuro de nuevas IDEs escalables, basadas en el modelo de computación en la nube, con herramientas que permitan la administración de los contenidos, datos, metadatos y aplicaciones. Esta plataforma debe desarrollarse bajo los principios de la Web 2.0, potenciando el papel del usuario como uno de los actores fundamentales. Para ello se revisaron tres cuerpos teóricos, partiendo de los fundamentos expresados en la Tesis Modelo de Infraestructura de Datos Espaciales basada en Computación en la Nube, en el que se enmarca este trabajo. Se revisaron los conceptos de IDE, teniendo en cuenta los estándares que sirven para la interoperabilidad de los datos y servicios y se revisó la especificación de Geoportal de forma que se garantizaran los requerimientos que la misma define y buscando resaltar el papel del usuario y un acercamiento a algunas características de lo que sería un Geoportal 2.0 evolucionando hacia la Web 2.0. [4].

(15) INTRODUCCIÓN De la situación antes descrita surge el siguiente problema científico: En el modelo de IDE basado en centros de datos utilizado en la IDERC se requiere de una adecuada gestión de la colaboración entre los diferentes proveedores de datos y servicios, acorde a la evolución de la Web hacia la versión 2.0, donde los usuarios de cualquier nivel puedan tomar decisiones con un creciente protagonismo. Aunque existen definiciones de los requerimientos que debería tener un Geoportal de esas características, o Geoportal 2.0, no existe un modelo o metodología que guíe su desarrollo. Por lo tanto, se hace necesario definir una plataforma, que integre los diferentes. componentes. que. satisfagan. estos. requerimientos,. así. como. su. implementación para ser utilizada como soporte al portal de la IDERC. El objeto de investigación se enmarca en los portales web geoespaciales basados en estándares de IDE, siendo el campo de acción los portales web geoespaciales dirigidos al usuario. El objetivo general de la investigación consiste en desarrollar una plataforma para la construcción de portales espaciales, que soporten la gestión de IDEs colaborativas dirigidas al usuario basada en estándares abiertos. De este objetivo se derivan los siguientes objetivos específicos: . Determinar los fundamentos teóricos y prácticos referentes a las Infraestructuras de Datos Espaciales y a los portales web geoespaciales dirigidos al usuario.. . Definir las tecnologías de software libre que permitan la construcción de un portal web geoespacial.. . Diseñar e implementar una arquitectura de integración de las tecnologías que garanticen la construcción de un Geoportal 2.0 dirigido al usuario.. . Implementar los componentes de la plataforma que brinden a los usuarios las funcionalidades para la interacción y gestión de la información espacial.. . Validar la solución propuesta mediante el caso de estudio del portal de la IDERC.. Las preguntas científicas que guiarán el desarrollo de la investigación, son:. [5].

(16) INTRODUCCIÓN . ¿Cuáles. son. los. fundamentos. teóricos. y. prácticos. referentes. a. las. Infraestructuras de Datos Espaciales y a los portales web geoespaciales dirigidos al usuario? . ¿Cuáles son las tecnologías de software libre que permitan la construcción de un portal web geoespacial?. . ¿Cómo diseñar e implementar una arquitectura de integración de las tecnologías que garanticen la construcción de un Geoportal 2.0 dirigido al usuario?. . ¿Cómo implementar los componentes de la plataforma que brinden a los usuarios las funcionalidades para la interacción y gestión de la información espacial?. El valor práctico de la investigación radica en la implementación de una plataforma para el soporte de IDEs colaborativas, específicamente como solución del Portal Nacional de la Infraestructura de Datos Espaciales de la República de Cuba, mientras que la definición de una arquitectura de plataforma basada en los principios participativos de la Web 2.0 constituye el valor teórico del trabajo. El documento está estructurado en tres capítulos, los cuales se describen a continuación: Capítulo. 1. “Portales. Web. Geoespaciales. dirigidos. al. usuario:. Bases. Conceptuales”: analiza los conceptos teóricos relacionados con el objeto de investigación, así como los estándares internacionales asociados a los mismos y las últimas tendencias tecnológicas de la Web, que propician su evolución. Se realiza un análisis del enfoque tradicional de las Infraestructuras de Datos Espaciales y de la definición de Geoportal 2.0. Capítulo 2 “Arquitectura para el desarrollo de un Geoportal 2.0, proyecto Geoliferay”: describe los tipos de tecnologías y componentes necesarios para la construcción de un portal espacial y define una arquitectura de la plataforma propuesta, que soporta los principales conceptos de un Geoportal 2.0. Capítulo 3 “Implementación de las aplicaciones de la plataforma Geoliferay”: expone las implementaciones de las distintas aplicaciones que forman parte de la [6].

(17) INTRODUCCIÓN plataforma y que constituyen la interfaz del geoportal con la que interactúa el usuario, ofreciendo las funcionalidades que garantizan el acceso a los datos mediante los servicios estándares OGC. Describe la implementación del caso de estudio del Portal Nacional. de. la. [7]. IDERC..

(18) CAPÍTULO I. CAPÍTULO I PORTALES WEB GEOESPACIALES DIRIGIDOS AL USUARIO: BASES CONCEPTUALES Este capítulo tiene como propósito exponer críticamente el estado del arte de las tecnologías relacionadas con el objeto de investigación: los portales web geoespaciales dirigidos al usuario. Muestra, además, los estándares internacionales asociados a los mismos y las últimas tendencias tecnológicas de la Web que propician su evolución. Se hace también un análisis crítico del enfoque tradicional de las Infraestructuras de Datos Espaciales, poniendo al descubierto las actuales carencias o insuficiencias del mismo. Este capítulo constituye la base sobre la que se sustentan las propuestas del Capítulo II. 1.1 Infraestructuras de Datos Espaciales. Una IDE incluye, "datos y atributos geográficos, documentación suficiente (metadatos), un medio para la búsqueda, visualización, y evaluación de los datos (catálogos y visores web), y algunos métodos para proveer acceso a los datos geográficos. Además, incluye servicios adicionales o software para apoyar aplicaciones de los datos. Para que una IDE sea funcional, tiene que incluir los acuerdos organizativos necesarios para coordinarla y administrarla en una escala local, regional, nacional y/o transnacional" (Nebert, 2004). En la actualidad existen iniciativas de infraestructuras globales, internacionales, nacionales y regionales para la colección y la diseminación de datos geográficos. Una IDE apunta a lograr interoperabilidad de datos y servicios geoespaciales en la Web. 1.2 Modelos actuales de Infraestructura de Datos Espaciales. Una Infraestructura de Datos Espaciales es un tipo particular de Infraestructura de Información para el dominio de la información geoespacial (Delgado T. C., 2007) (Delgado Fernández & Castellanos Abella, 2006) (Delgado Fernández T. , Infraestructuras de Datos Espaciales en países de bajo desarrollo tecnológico. Implementación en Cuba. s.l. : Tesis presentada en opción al grado científico de Doctor [8].

(19) CAPÍTULO I en Ciencias Técnicas, 2005). Es una iniciativa que pretende crear un ambiente en el cual todos los actores pueden cooperar entre sí e interactuar con la tecnología, para alcanzar mejor sus objetivos en diferentes niveles político-administrativos. (Williamson, 2002) En la arquitectura conceptual de la Figura 1Figura 1 se describen los servicios, datos, y tecnologías que conforman el entorno actual de las IDEs, aceptados por las principales organizaciones de estándares geoespaciales, Open Geospatial Consortium (OGC) y el Comité Técnico 211 de la ISO5.. Figura 1: Arquitectura conceptual de una IDE. Fuente: (Gould, 2008). Esta arquitectura puede interpretarse tradicionalmente en tres capas, “cliente - capa media - servidor”, donde las aplicaciones clientes buscan y localizan datos espaciales que pueden transformarse o procesarse por servicios intermedios antes de su presentación al cliente. Puede interpretarse también usando el modelo triangular de servicios web (ver Figura 2) donde los servicios de catálogo (OGC, 2006) publican el contenido de los datos espaciales (metadatos) ( ISO 19115, 2003), estos se buscan y se encuentran. 5. International Standard Organization, http://www.iso.org. [9].

(20) CAPÍTULO I posteriormente por servicios que por último se enlazan y ejecutan ( ISO 19119, 2003) (DOYLE A., 2001).. Figura 2: Arquitectura de servicios web. Fuente: (Delgado Fernández T. , Infraestructuras de Datos Espaciales en países de bajo desarrollo tecnológico. Implementación en Cuba. s.l. : Tesis presentada en opción al grado científico de Doctor en Ciencias Técnicas, 2005). Los servicios involucrados permiten publicar los datos como mapas/imágenes (usando WMS6) ( ISO 19128, 2005), como datos en bruto (usando WFS7 y WCS8), o como resultado de un geoprocesamiento (WPS9), además los usuarios pueden actualizar, eliminar e insertar elementos geográficos usando WFS-Transaccional. La información geoespacial se puede compartir de forma fácil e interoperable (OGC, 2003) (OGC, 2003) (ISO, 2002) (OGC, 1999) . Las características de los modelos actuales pueden resumirse como: . Arquitectura estable, no escalable.. 6. Web Map Service (OGC, 2009). 7. Web Feature Service (OGC, 2005). 8. Web Coverage Service (OGC, 2005). 9. Web Processing Service (OGC, 2007). [10].

(21) CAPÍTULO I . Gestión “arriba-abajo”.. . Plataforma para distribuir datos geoespaciales y servicios relacionados.. . Basada en normas internacionales.. . Tolerancia, hasta cierto punto, a la diversidad e innovación (alternativas de implementación) a través de normas de interfaz.. 1.3 Portal Web El término "portal" proviene de la palabra en latín porta y significa punto de entrada. Los portales son sitios web que actúan como una puerta o pasarela a una colección de recursos de información incluyendo conjuntos de datos, servicios, noticias, tutoriales, herramientas y una colección organizadas de vínculos a otros sitios usualmente a través de catálogos. Un portal es un ambiente web que permite a una organización o una comunidad de información de usuarios y proveedores agregar y compartir contenido (Maguire & Longley, 2004). Los portales son ambientes basados en la Web en los que se pueden ejecutar las aplicaciones de los usuarios, estas aplicaciones son integradas de conjunto de una forma consistente y sistemática. (Richard Sezov J. , 2012) Desde el punto de vista funcional, se puede decir que un portal atiende a las necesidades en tres áreas principales: . Agregación de aplicaciones: El portal puede jugar un papel importante a la hora de integrar las aplicaciones de una empresa proporcionando a través de una única interfaz de usuario (personalizable) el acceso a los servicios de múltiples fuentes de información.. . Gestión de los contenidos: La funcionalidad de gestión de contenidos se define con el nombre de CMS, Content Management System. Una plataforma de gestión de portales no es solo un CMS,. pero en general ofrece las. funcionalidades típicas de un CMS como la elaboración de contenidos de acuerdo con plantillas personalizables, edición de contenido, definición de flujo de trabajo para el proceso de edición, gestión de categoría y etiquetas para los [11].

(22) CAPÍTULO I contenidos, gestión del contenidos en varios idiomas y optimización para los motores de búsqueda. . Herramientas de colaboración: El portal puede ser utilizado como una herramienta para la colaboración de un equipo de trabajo en una intranet o para la creación de comunidades de usuarios en la Web, por lo que es una herramienta que permite la creación de „Redes Sociales‟ tan de moda hoy en día. Una plataforma sólida para la creación de portales, tiene que ofrecer las herramientas de colaboración típicos como blogs, wikis, foros, mensajería instantánea, correo electrónico y calendario compartido.. 1.4 Portal web geoespacial En la actualidad los portales web son la más popular y extensiva tecnología usada para implementar las IDEs a los distintos niveles, local, regional, nacional e internacional (Halil Akinci, 2009). “Un geoportal es un sitio web que presenta un punto de entrada a contenido geográfico en la web o, más simple, un sitio web donde la información geográfica puede ser descubierta” (Tait, 2004). ESRI10 define un portal geoespacial como “un simple punto de acceso a la información espacial, independientemente de su localización, formato o estructura” (ESRI, 2009). OGC define un geoportal como “una interfaz humana para una colección en línea de recursos de información geoespacial, incluyendo conjuntos de datos y servicios” (Open Geospatial Consortium Inc, 2004). Maguire y Longley definen un geoportal como “una forma de acceso web que organiza contenido y servicios como directorios, herramientas de búsqueda, información de comunidades, recursos de soporte, datos y aplicaciones” (Maguire & Longley, 2004). Los geoportales que se encuentran asociados a una IDE son a menudo llamados portales de catálogo, ya que estos gestionan índices o catálogos de metadatos que describen la naturaleza y localización de los recursos en una IDE. En adición a las herramientas de búsqueda genérica de catálogos, las aplicaciones de un geoportal. 10. Enviromental Systems Research Institute, http://www.esri.com. [12].

(23) CAPÍTULO I proveen herramientas de mapeo en la web que permiten a los usuarios ver y trabajar con la información encontrada, por ejemplo herramientas de geoprocesamiento como: enrutamiento, geocodificación, impresión y consultas complejas. (Halil Akinci, 2009) 1.5 Arquitectura de Referencia de Portales Geoespaciales OGC Open Geospatial Consortium OGC comenzó la identificación de una plataforma de arquitectura de un geoportal en 2002 (OGC Geospatial One-StopPortal Initiative, 2002). Después del inicio de GOS11, una iniciativa de portal de US e-government, OGC publicó el documento “GOS-Portal Implementation Architecture” (OGC, 2003). Un año más tarde publicó su documento para definir la arquitectura de referencia de un portal geoespacial (Open Geospatial Consortium Inc, 2004). Este documento tiene como meta hacer más fácil, más rápido y menos costoso para cualquier organización que desee implementar su aplicación de portal geoespacial basado en estándares. El principal objetivo de la arquitectura de referencia, es definir los requerimientos de una plataforma de arquitectura, que pueda ser usada como guía para la implementación de un geoportal operacional que provea acceso a contenido geoespacial, mapas y metadatos. La arquitectura de referencia específica el alcance, los objetivos y el comportamiento de un portal e identifica sus componentes funcionales. Define cuatro clases de servicios que soportan todos los requerimientos de un portal geoespacial (ver Figura 3). . Servicios de portal: Proveen un simple punto de acceso a la información geoespacial en un portal. En adición, estos servicios proveen la gestión y administración del portal.. . Servicios de catálogos: Usados para localizar información y servicios geoespaciales.. . Servicios de dibujo: Usados para procesar la información geoespacial y prepararla para su presentación al usuario.. 11. Geospatial One-StopPortal Initiative. [13].

(24) CAPÍTULO I . Servicios de datos: Usados para proveer contenido geoespacial y procesamiento de datos.. Figura 3: Arquitectura de Referencia de Portales Geoespaciales. Fuente: (Open Geospatial Consortium Inc, 2004). 1.6 Web 2.0 Término utilizado para referirse a una supuesta segunda generación de servicios web como sitios de redes sociales, wikis, herramientas de comunicación y folksonomías 12, que enfatiza la colaboración en línea y la distribución de la información (Asúnsolo, 2009) (Freire, 2008.) (Pérez, 2006) (Wikilibros, 2009). Se trata más bien de un concepto de Internet colaborativa que de una nueva generación de software. La Web 2.0 representa la evolución de las aplicaciones tradicionales hacia aplicaciones web. 12. Neologismo que combina en este caso folk (gente) con taxonomía. Metodología de clasificación en la que los propios usuarios emplean etiquetas de modo descentralizado sobre objetos diversos tales como fotografías, páginas, vídeos o textos.. [14].

(25) CAPÍTULO I enfocadas al usuario final. Es una actitud y no precisamente una tecnología (O'Reilly & Battelle, 2009) (Williamson, 2002) (Codina, 2009). Principios claves que caracterizan a las aplicaciones Web 2.0 Según Van Der Henst (Van Der Henst, 2007). y Méndez (Méndez, 2007) existen. principios claves que caracterizan a las aplicaciones Web 2.0:  La Web como plataforma: muchos servicios dejan de ser aplicaciones encerradas en el ordenador personal, para estar disponibles y ser usados “vía web” desde cualquier lugar. Se ve a la Web como un conjunto de servicios disponibles para la creación de nuevas aplicaciones.  La información es lo que mueve al Internet: el contenido es lo más importante, porque existen nuevas posibilidades de compartirlo, llevarlo de un lado a otro, hacer remezclas, etiquetarlo y encontrarlo. El poder está en los datos más que en las aplicaciones.  Efectos de red conducidos por una “arquitectura de participación”: se manifiestan de tres formas diferentes, el efecto directo se experimenta cuándo el valor de un bien aumenta con el número de nodos con los que es posible establecer comunicación; el efecto indirecto cuando al incrementarse el número de usuarios de una red bajan los precios en los productos (economías de escala) y de aprendizaje cuando al aumentar el tamaño de la red, se incrementa el número de usuarios con conocimientos específicos sobre la tecnología asociada, que al poner a disposición de otros individuos sus conocimientos, favorecen la expansión de la red, de modo que un nuevo usuario logrará un mejor servicio post venta además del consejo de otros usuarios experimentados (Ugarte, 2009) (Yarmosh, 2005).  Innovación distribuida o inteligencia colectiva: la innovación surge de características [15].

(26) CAPÍTULO I distribuidas por desarrolladores independientes, ciertas estructuras sociales autorreguladas pueden mostrar comportamientos inteligentes en sí mismas, siendo más eficientes que sus miembros individualmente. Se aprovecha el contenido que genera el usuario.  El fin del círculo de adopción de software pues los servicios están en beta perpetuo: el software deja de ser un producto para convertirse en servicios en constante mejoramiento, con actualizaciones nuevas, incluso diariamente. 1.7 Desafíos y riesgos de las IDEs 2.0 apoyadas en la Web 2.0 Al aplicar los conceptos de la Web 2.0 al ámbito de las Infraestructuras de Datos Espaciales se puede hablar de una IDE 2.0 como próximo paso evolutivo de la IDE 1.0, en la que los nuevos proyectos van más allá de la simple visualización de cartografía, integrando los datos aportados por los usuarios en su nuevo papel de usuariosproveedores (Rodríguez, y otros, 2008) (Álvarez, Delgado, & Cruz, Social Networks and Web 2.0 Tools as a Good Complement to the Local SDI‟s, 2010) (Álvarez, Delgado, & Cruz, Social SDI's: a Challenge for Land Surveyors, 2010). Debido al empuje de la Web 2.0, la IDE se ha ido desplazando desde una visión centrada en el proveedor a otra centrada en el usuario, lo que contribuye a una mejor apreciación de la Información Geográfica por el gran público, emergiendo términos relacionados con la profesión geográfica tales como información geográfica voluntaria (VGI por sus siglas en inglés), subcontratación voluntaria o tercerización masiva (crowdsourcing), neogeografía y ciencia ciudadana (Goodchild, 2007) (Gould, 2008) (Wikilibros, 2009) (Bordignon, 2009) (Coleman, 2009) . En estos momentos en que la sociedad requiere de más cartografía, los usuarios aparecen como una opción interesante a la hora de añadir información sobre el fondo cartográfico básico, teniendo en cuenta que hay que separar ambos tipos de información, la de referencia, fiable y exacta dentro de sus límites y la añadida, sin garantías formales pero muy útil en la mayoría de las ocasiones. No resulta absurdo que, sobre el mapa topográfico de una ciudad, los ciudadanos vayan cargando la [16].

(27) CAPÍTULO I ubicación de bares, restaurantes, farmacias, cines, bibliotecas,…en función de sus intereses y aficiones; mientras etiquetan el mundo en una folksonomía al efecto (Rodríguez, y otros, 2008) (Parson, Junio 2009) (Dehaes, 2008). La IDE 2.0 debe estar abierta a la colaboración de los datos de los usuarios, facilitándole mecanismos y herramientas para que puedan publicar su cartografía mediante servicios interoperables (Rodríguez, y otros, 2008). Se concibe como una “Arquitectura de Participación” (O´Reilly, 2004) que es tanto social como técnica. En ella se busca impulsar las habilidades y la energía de los usuarios tanto como sea posible para cooperar en la construcción de algo más grande que lo que cualquier persona u organización podrían realizar solas (Goodchild, 2007) (Parson, Junio 2009) (Holmes, 2009). 1.8 Principios que caracterizan a las aplicaciones IDE 2.0 Algunos autores (Maguire D. , 2008) (Gould, 2008) (Maguire D. , 2006) describen las características de la IDE 1.0 y la IDE 2.0 asociadas a los términos Paleogeografía y Neogeografía respectivamente (Tabla 1). La Paleogeografía aporta mapas estáticos proveídos oficialmente, con una actualización regular pero con poca frecuencia, mientras que en la Neogeografía los mapas contienen geoinformación más diversificada (mashups). Los proveedores oficiales y no oficiales (público) garantizan una actualización continua, al estilo Wikipedia (Méndez, 2007) (Bordignon, 2009) (Ter Haar, 2009) .. [17].

(28) CAPÍTULO I Tabla 1: Comparación IDE 1.0 vs IDE 2.0. Fuentes: (Maguire D. , 2008) (Maguire D. , 2006) IDE 1.0. IDE 2.0. (Paleogeografía). (Neogeografía). Sitios con Mapas 2D estáticos. Mapas 2D dinámicos, coberturas globales. Publicación. Participación. Centrada en el productor. Centrada en el usuario. Centralizada. Distribuida. Acoplada (protocolos propietarios). Desacoplada (protocolos estándares). Interfaz básica. Interfaz “rica”. 1.9 Geoportal 2.0 Se plantea, para la IDE 2.0, la construcción de un Geoportal 2.0 basado en la participación, que proporcione el valor real a los usuarios, recompensándolos por usar y contribuir (Rodríguez A. F., 2009). Debe construirse iterativamente y ser útil en todo momento (Holmes, 2009), teniendo en cuenta los siguientes aspectos: . Para evaluar los datos se deben ofrecer estadísticas y calificaciones del nivel de acceso a una capa, habilitar comentarios, calificaciones, etiquetas y reseñas por los usuarios, filtrado colaborativo basado en el perfil de usuario.. . Al visualizar datos, que sea fácil adicionar varias capas y formar una “vista”, guardar las vistas favoritas, evaluar y comentar las vistas, cargar una vista de otro usuario, cambiar su estilo y adicionar datos.. . Para contribuir con datos SIG, que de forma simple se pueda cargar un archivo shape13, que no sean obligatorios los metadatos aunque sí algunos campos fáciles de llenar, establecer los permisos de quién puede ver y actualizar, y establecer. 13. ESRI Shapefile (ESRI, 1998). [18].

(29) CAPÍTULO I estilos en línea a la vista por defecto o que sea fácil importar un SLD 14 u otro archivo de estilo. . En cuanto a la disponibilidad de datos, que los datos proporcionados por los usuarios estén disponibles en diferentes formatos (WMS, WFS, WCS, GML15, teselas raster, shape), para que puedan usarse desde SIG de escritorio y basados en web, fáciles de empotrar en blogs y páginas web.. . El registro de servicios debe ser un proceso fácil, los servicios deben tener caché de la información que brindan.. . Los metadatos no deben ser obligatorios para usar la infraestructura, estos deben derivarse de las acciones activas y pasivas del usuario, permitir la edición al estilo wiki, hacer de la edición un juego en el que se reconozca a los usuarios que mejor participan.. . Los proveedores de datos oficiales deberían usar la misma infraestructura que los usuarios aficionados, aunque se pudieran limitar los permisos a un área controlada durante la edición, antes de la publicación oficial; se pueden deshabilitar los comentarios y evaluaciones.. . Respecto a la tecnología, el futuro está en los usuarios, debe basarse en código abierto, estándares abiertos y datos abiertos. La tecnología y la comunidad siempre estarán interrelacionadas.. 1.10. Conclusiones del Capítulo I. Al analizar los modelos de referencia de IDEs se comprobó que en la mayoría no aparece el uso de la información geográfica generada por los usuarios, que posibilite el desarrollo de IDEs colaborativas. La evolución de las Infraestructuras de Datos Espaciales ha estado muy relacionada con la propia evolución de la Web. La Web 2.0 está marcando una nueva era donde todo se ofrece como un servicio, permitiendo que. 14. Styled Layer Descriptor (Open Geospatial Consortium Inc, 2007). 15. Geography Markup Language (OGC, 2003). [19].

(30) CAPÍTULO I los usuarios se conviertan en proveedores (principio básico de la Web 2.0 y las redes sociales). De ahí que el paso de las IDEs más orientadas a los usuarios es una necesidad cada vez más aceptada, siendo los portales web la tecnología más usada en el soporte de IDE a todas las escalas, por lo que la adopción de los principios de la Web 2.0 potenciaría el papel del usuario como uno de los actores fundamentales, proporcionándole un mayor valor real. Se identificaron los principales requerimientos que debe tener un Geoportal 2.0 para facilitar los mecanismos que permitan a los usuarios publicar su cartografía mediante servicios interoperables.. [20].

(31) CAPÍTULO II. CAPÍTULO II ARQUITECTURA PARA EL DESARROLLO DE UN GEOPORTAL 2.0, PROYECTO GEOLIFERAY 2.1. Introducción. La Agencia GeoMIX, perteneciente a la empresa Cartografía y Soluciones Geomáticas, es la responsable del desarrollo del Portal de la Infraestructura de Datos Espaciales de la República de Cuba (IDERC). En cumplimiento a esta responsabilidad la Agencia ha llevado a cabo un proyecto de desarrollo, Geoliferay, orientado a obtener una plataforma que facilite la creación de un geoportal basado en estándares de IDE. Para la construcción de un geoportal resultan evidentes dos tipos de tecnologías enmarcadas en la misma composición de la palabra “geo-portal”, por una parte el componente “geo” y por otra el componente “portal”. De ahí que el proyecto necesite en su constitución la mezcla de estas dos aristas. En este capítulo se definen las herramientas de software libre que permiten la construcción de un geoportal y se analizan las potencialidades y características de cada una de ellas.. Se describen los mecanismos para la integración de las. herramientas en el entorno de Geoliferay, definiéndose una arquitectura que soporte la construcción de un Geoportal 2.0. 2.2. Liferay como plataforma de desarrollo del proyecto Geoliferay. Liferay es una de las mejores plataformas para el desarrollo de portales y aplicaciones web disponibles en la actualidad en el mundo del código abierto. En Octubre de 2014 Gartner (Gartner, 2014) anunció a Liferay Inc como líder en el Cuadrante Mágico de Portales Horizontales por cinco años consecutivos como muestra la Figura 4, posicionándolo como uno de los mayores competidores en el mercado de los portales. En ese artículo se hace una comparación con productos similares en base a dos criterios fundamentales: la integridad de la visión y la capacidad para ejecutarla, el reporte muestra a Liferay mejorando en ambos en la visión y en la ejecución de la misma. Lo anterior justifica la selección de esta plataforma para el desarrollo del [21].

(32) CAPÍTULO II proyecto Geoliferay, adicionándole el hecho decisivo de ser una plataforma de código abierto con una versión libre sin costo alguno.. Figura 4: Cuadrante Mágico de Gartner de Portales Horizontales. Fuente: (Gartner, 2014). Características de Liferay El portal de Liferay utiliza las últimas tecnologías Java y Web 2.0. Está pensado principalmente para el entorno empresarial, proporciona un portal donde se puede centralizar, compartir y colaborar en tareas. La interfaz de usuario es bastante fácil de manejar, incluso para los usuarios menos familiarizados con la tecnología. Es un producto muy completo, que cuenta con más de 60 portlets que están listos para [22].

(33) CAPÍTULO II realizar todas las tareas comunes de un portal moderno a nivel de empresa (Yuan, 2012). Liferay es entonces una plataforma para el desarrollo, la integración y la colaboración basada en los principios de los servicios de arquitectura (SOA). Tiene todas las características necesarias para la creación de un portal web, tales como publicación web, gestión de contenidos, colaboración empresarial y la creación de redes sociales, todo ello soportado sobre una plataforma de código abierto, construida de acuerdo a los estándares abiertos. Entre las principales características de Liferay se pueden mencionar las siguientes: . Es compatible con la mayoría de los servidores de aplicaciones, contenedores de servlets, bases de datos y sistemas operativos.. . Compatible con JSR-28616.. . Incluye más de 60 portlets pre-instalados.. . Está construido en el Sistema de Gestión de Contenidos (CMS) y la Suite de Colaboración.. . Los usuarios pueden personalizar sus propias páginas.. Las principales ventajas que ofrece: . Fácil personalización.. . Es posible cambiar el tema de la página web desde la interfaz gráfica sin tener que escribir o modificar nada de código.. . Posibilidad de utilizar el tema o plantilla que se desee.. . Ofrece un portlet de flujo de trabajo.. . Organización dinámica y flexible del contenido en cada página.. . Posibilidad de definir roles dentro de la empresa y de los usuarios externos, para una mayor seguridad.. 16. JSR 286: Portlet Specification 2.0: es la segunda versión de la especificación para portlets, desarrollada para cumplir con las especificaciones de servicios web para portlets remotos. https://jcp.org/en/jsr/detail?id=286. [23].

(34) CAPÍTULO II . La interfaz de usuario de Liferay es muy intuitiva y no es necesario mucho tiempo para familiarizarse con ella.. . Liferay Portal cumple con los estándares, lo que facilita la integración con otras tecnologías.. . El catálogo de plugins de Liferay es muy extenso. Una de las características es que mantiene un registro de las nuevas versiones del software y actualiza instantáneamente la tecnología sin necesidad de reiniciar el portal.. . Ofrece una interfaz de usuario para la configuración de diferentes componentes como el correo electrónico o la instalación de nuevos portlets o aplicaciones.. . El API17 que ofrece para el desarrollo de aplicaciones es bastante completo, a la vez que simple en su utilización.. 2.2.1 Entorno de desarrollo y extensión de Liferay Liferay comenzó a contener un gran volumen a partir del 2010 y este proceso solo se ha acelerado desde entonces. Debido a esto y a la gran popularidad alcanzada por el producto surge la aparición del entorno de desarrollo de Liferay con el objetivo de ayudar y facilitar el trabajo de los desarrolladores, y nada mejor para esto que la plataforma Eclipse18 (Ver Figura 5), diseñada desde un principio para ser extendida. (Richard Sezov J. , 2012). 17. Application Programming Interface, es el conjunto de funciones que provee alguna aplicación o biblioteca para ser utilizada o extendida por otros sistemas o aplicaciones. 18. Java Integrated Development Environment https://eclipse.org/. [24].

(35) CAPÍTULO II. Figura 5: Nueva perspectiva que forma parte de Liferay IDE19. Fuente: (Richard Sezov J. , 2012). El IDE de Liferay tiene soporte directo para el SDK20 de los plugins, lo que significa que se pueden crear proyectos o importar proyectos existentes directamente desde el IDE. Cuando se desarrollan sistemas, el patrón Modelo Vista Controlador es una de las expresiones que más está de moda, y fue bien acogido en la plataforma de Liferay. El modelo maneja el comportamiento y los datos del dominio del portal, respondiendo a las peticiones de información sobre el estado de la vista y respondiendo a las instrucciones de cambios de estados desde el controlador. (Yuan, 2012) En Liferay se utiliza un concepto llamado plugin, el cual es un fichero de extensión war, que puede ser desplegado en el servidor en tiempo de ejecución. Estos plugins se. 19. Integrated Development Environment, entorno de desarrollo integrado, es un entorno de programación que ha sido empaquetado como un programa de aplicación. 20. Software Development Kit, generalmente un conjunto de herramientas de desarrollo de software que permiten crear aplicaciones para un sistema concreto.. [25].

(36) CAPÍTULO II encuentran categorizados en portlets, themes, layout templates, hooks, y webs, y son desarrollados usando el SDK de Plugins. Portlets Los portlets son aplicaciones web que se ejecutan en una porción de página web (ver Figura 6). El corazón de cualquier implementación de portal son sus portlets, debido a que en ellos reside la funcionalidad del portal (Richard Sezov J. , 2007). Son componentes web gestionados por un contenedor, que tras la petición de un usuario generan y presentan contenidos dinámicos. El portlet permite la personalización, la presentación, y la gestión de la seguridad. El contenido generado por los portlets se denomina fragmento. Los fragmentos agregados resultantes de la operación de varios portlets constituyen un documento que se traduce en la interfaz del portal. Estos elementos se disponen a través de una retícula o rejilla en el portal.. Portlet 1. Portlet 2. Portlet 3. Portlet 4. Portlet 5. Figura 6: Distribución de portlets en una página.. Un portlet puede instanciarse o definirse varias veces en un portal web en la posición que más se desee. Por este motivo cada portlet dispone de sus propias preferencias, lo [26].

(37) CAPÍTULO II que permite la posibilidad de configurar el mismo portlet de varias maneras diferentes, sin necesidad de programarlo de forma distinta. De ahí que se puedan definir múltiples preferencias para un portlet determinado. Esta funcionalidad permite definirle configuraciones a los portlets en tiempo de ejecución. Estos componentes tienen tres modos de visualización: . View: es el modo del portlet en el que muestra al usuario la información dinámica correspondiente a sus funcionalidades.. . Edit: es el modo de portlet donde se accede a la configuración del portlet. Accesible solo para determinados usuarios en un contexto general.. . Help: modo a través del cual se muestra la información necesaria sobre el funcionamiento correcto del portlet en cuestión, llamado normalmente ayuda.. Un portlet tiene varias fases: . Fase de Dibujo (Render phase): Se ejecuta cada vez que el portlet necesita redibujarse en la página.. . Fase de acción (Action phase): Invocada como resultado de la ejecución de una ActionURL. Esta permite al portlet realizar algún procesamiento para cambiar su estado, el cual es reflejado cuando el portlet es dibujado otra vez.. . Fase de evento (Event phase): Invocada como resultado del lanzamiento de un evento. Los eventos pueden ser lanzados desde la fase de acción de un portlet y procesados durante la fase de eventos.. Anatomía de un proyecto portlet Un proyecto portlet se compone de tres elementos fundamentales: . Fuentes del código java.. . Ficheros de configuración.. . Ficheros del lado del cliente (*.css,*.js, etc.).. Estos ficheros son almacenados en una estructura estándar de directorio, como muestra la Figura 7:. [27].

(38) CAPÍTULO II. Figura 7: Estructura de carpeta de un proyecto portlet. Fuente: (Richard Sezov J. , 2012). Los ficheros y carpetas tienen diferentes funciones como se muestra en la Tabla 2 y Tabla 3. Tabla 2: Descripción de las carpetas de un portlet. Fuente (Richard Sezov J. , 2012) Carpeta. Descripción. docroot. El directorio raíz de la aplicación que contiene otras carpetas. WEB-INF. La carpeta estándar WEB-INF de los módulos web. Debido a que los portlets son también módulos web, aquí estarán los ficheros de configuración.. WEB-INF/src. El código fuente del portlet. build.xml. El script de construcción usado para compilar y desplegar el portlet.. Tabla 3: Ficheros de configuración específicos de los proyectos portlets de Liferay. Fuente: (Richard Sezov J. , 2012) [28].

(39) CAPÍTULO II Fichero de. Propósito. Configuración liferay-display.xml. Describe para Liferay la categoría bajo la cual el portlet aparecerá en el menú Adicionar  Más. liferay-portlet.xml. Describe mejoras específicas de Liferay para los portlets estándares de java, que son instalados en un servidor de Liferay Portal. Por ejemplo, se puede especificar cuando un portlet es instanciable, lo que significa que se puede agregar más de una instancia en una página.. liferay-plugin-. Describe el plugin para el despliegue en caliente de Liferay.. package.properties. En este fichero se pueden configurar las dependencias de los ficheros .jar. Si un portlet depende de algún fichero .jar de los que utiliza Liferay se puede especificar esa dependencia en este fichero y el en el momento del despliegue se copiarán esos jar dentro del portlet.. Service Builder El ambiente de desarrollo de Liferay proporciona la herramienta Service-Builder para generar código de persistencia y de la capa de servicios desde la lectura de un fichero XML21, y no requiere la escritura de una gran cantidad de código, ya que este es generado por la herramienta, siendo muy útil para automatizar la creación de interfaces y clases que son usadas dentro de un portal o portlet (Ver Figura 8).. Además,. construye los servicios java que pueden ser accedidos en una gran variedad de formas, incluyendo acceso local desde código, como acceso remoto usando servicios web, y suministrando el código necesario para persistir las entidades en la base de datos (Yuan, 2012).. 21. Xtensible Markup Language, es un lenguaje basado en etiquetas.. [29].

(40) CAPÍTULO II En un sentido más amplio Service-Buidler es una herramienta que genera códigos: • Java Beans (SUN Microsystem Inc, 1997). • SQL scripts para la creación de tablas. • Configuración de Hibernate 22 . • Configuración de Spring23 . • Servicios Web. • JSON24 JavaScript Interface.. Figura 8: Service Builder, en la parte superior de Hibernate y Spring generando el código y las configuraciones necesarias. Fuente: (Richard Sezov J. , 2012).. AlloyUI, plataforma de interfaz de usuario. 22. Hibernate. Everything data http://hibernate.org/. 23. Spring Security - Projects http://projects.spring.io/spring-security/. 24. JavaScript Object Notation, Notación para Objetos en JavaScript, es un formato ligero para el intercambio de datos. Es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML.. [30].

(41) CAPÍTULO II AlloyUI25 es una plataforma de interfaz de usuario construida sobre la librería de javascript de Yahoo YUI3, brinda una API consistente y sencilla para crear aplicaciones web en los tres niveles del navegador: estructura, estilo y comportamiento. Incorpora tres lenguajes de diseño: HTML26, CSS27 y JavaScript (Ver Figura 9). Es ampliamente utilizada en muchos de los proyectos de Liferay Open Source, como Liferay Portal, Liferay Social Office, y muchos más. Los componentes de Alloy UI son soportados completamente en Javascript, complementándolo con su propia API documentada. El Javascript es basado en YUI3, la cual es bien conocida en el mundo del Javascript, al estar distribuida a través del espectro de navegadores y ambientes, siendo bien probada y evaluada su fortaleza (Richard Sezov J. , 2012). Esta carga de Javascript hace que la página sea pesada o sobrecargada, en cambio AlloyUI ha sido construido soportando la carga tardía, lo que significa que los componentes no serán cargados hasta que sean necesarios. Si se tiene un portlet en una página usando algunos de los componentes de AlloyUI, pero el usuario está interactuando con otro portlet, Liferay no gastará tiempo cargando los recursos de los portlets que no se están usando, estos solos serán cargados cuando se inicie la interacción con los mismos.. 25. ALLOYUI http://alloyui.com/. 26. HyperText Markup Language, es un lenguaje de marcado muy utilizado para la creación de páginas web. 27. Cascading Style Sheets, usado para definir la presentación de un documento estructurado escrito en HTML o XML.. [31].

(42) CAPÍTULO II. Figura 9: Diseño de AlloyUI. (Richard Sezov J. , 2012). A continuación un listado de algunos de los tipos de componentes de Alloy UI: ■ Autocompletamiento. ■ Paginador. ■ Gráficos. ■ Árboles. ■ Calendarios. ■ Barra de herramientas. ■ Celdas de datos. ■ Deslizadores. ■ Pestañas. ■ Paneles, diálogos. ■ Menú La última versión, AlloyUI 2.0, incorpora una tonelada de nuevas características y el proyecto ha sido rediseñado desde cero, mientras que provee soporte a las versiones anteriores. 2.2.2 Interacción entre portlets Una de las fortalezas de construir aplicaciones tipo portlets es la posibilidad de poder desarrollarlas desde una perspectiva modular y más extensible, contribuyendo en gran medida con la reutilización de código. La comunicación entre portlets es uno de los temas más actuales del desarrollo de aplicaciones de portal. Al permitir la comunicación entre portlets, se pueden mostrar los cambios en un portlet basados en interacciones del usuario con otro portlet. En el presente trabajo se hizo uso de dos [32].

(43) CAPÍTULO II mecanismos que permiten esta interacción entre portlets: Inter Portlet Communication (IPC) y PageBus28. Inter Portlet Communication (IPC) El estándar de portlets JSR-286 (portlets 2.0) proporciona un mecanismo para hacer la comunicación entre portlets (IPC). En realidad, tiene dos formas: un método simple basado en parámetros compartidos, y un enfoque basado en eventos más complejos. Los parámetros compartidos permiten a los portlets establecer parámetros que pueden ser leídos por otros portlets. Este mecanismo es bastante simple pero a veces las necesidades de comunicación son más complejas. En el caso de los eventos es muy útil para escenarios complejos. La principal ventaja de este segundo método es que permite una comunicación totalmente desacoplada. Un portlet emite un evento y no tiene que preocuparse si hay alguien escuchando ese evento. Los eventos de portlets son enviados por el portlet que está configurado para enviar el evento. Sólo los portlets que están configurados para detectar el evento son capaces de recibirlos. Tibco PageBus En la actualidad los componentes javascript son parte esencial en la mayoría de las aplicaciones web, y cada día se incrementa el número de estos componentes en una página web, por lo que lograr la interacción entre este tipo de componentes resulta cada vez más difícil. Existe una forma de simplificar este problema: los eventos. TIBCO PageBus es un bus de mensajes en JavaScript que se ejecuta en el navegador web. Permite a componentes web que se ejecutan en un navegador comunicarse entre sí a través de publicación y suscripción de eventos de forma desacoplada. Esta comunicación se produce enteramente dentro del navegador web. TIBCO PageBus es gratuita y está disponible como código abierto.. 28. TIBCO PageBus™ 2.0 https://docs.tibco.com/products/tibco-pagebus-2-0. [33].

(44) CAPÍTULO II Para definir un evento: . Se selecciona un nombre para el evento, se recomienda un nombre que identifique la organización, evitando así que entre en colisiones en un ambiente donde existan otras aplicaciones que tengan sus propios eventos, por ejemplo "org.example.portfolio.select"..  Se especifica el contenido del evento, en este caso un objeto JavaScript, que contenga los datos. Publicar un evento con PageBus resulta muy sencillo: var myEventDataObject = { text: "hello world!" }; PageBus.publish("my.subject.name", myEventDataObject);. Al igual que suscribirse a los eventos: myOnDataFunction = function(subject, eventDataObject, subscriberData) { alert(eventDataObject.text); } PageBus.subscribe("my.subject.name", null, myOnDataFunction, mySubscriberData);. 2.3. Componentes necesarios para la construcción del geoportal. Un geoportal, como se señaló en el capítulo anterior, es la plataforma que proporciona a los proveedores de información geoespacial los mecanismos para permitir a sus usuarios la búsqueda, descubrimiento, acceso, visualización y actualización de los datos geoespaciales. Estas operaciones se realizan mediante servicios en línea, vía interfaces web o aplicaciones. Los componentes necesarios para construir un geoportal se encuentran disponibles a través de un número de servicios estándares geoespaciales de OGC que garantizan la interoperabilidad. Usando como ejemplo la Figura 10 se puede apreciar la distribución de estos servicios en un geoportal.. [34].