CAPÍTULO II ARQUITECTURA PARA EL DESARROLLO DE UN GEOPORTAL 2.0,
2.4 Integración de las plataformas de software, definición de una arquitectura de
2.4.1 Mecanismo de notificación de cambios en los datos en Geoliferay
En el entorno distribuido de aplicaciones que componen Geoliferay es fundamental mantener una actualización constante de los cambios que ocurren en los datos gestionados por los usuarios en las diferentes aplicaciones que hacen uso de los mismos como Geoserver y Geonetwork.
La interfaz Interceptor de Hibernate brinda llamadas de retorno desde la sesión de una aplicación, que permiten a la aplicación inspeccionar y / o manipular las propiedades de un objeto persistente antes de que se guarde, actualice, elimine o sea cargado. Hibernate plantea dos tipos de Interceptores: Session-scoped and SessionFactory- scoped (Hibernate, 2004).
Se agregó al SDK de Tocororo la implementación de un interceptor en el ámbito de la SessionFactory nombrado CRUDInterceptor, este interceptor mediante el uso de SPI50 obtiene todos las clases que implementen la interfaz TocororoCRUDListenerProvider y
50
Service Provider Interfaces http://docs.oracle.com/javase/tutorial/sound/SPI-intro.html
Portlets GeoLiferay
Geonetwork Geoserver Tocororo
Publica contenido(REST) Publica metadatos (CSW) Gestiona contenido de Tocororo vía panel de control Realiza búsquedas en Geonetwork (CSW) Consume datos CAS Autentica Liferay Autentica Consume servicios OGC (WMS,WFS) GEOLIFERAY Valida credenciales
[48]
que observan los eventos del interceptor (
onSave, onUpdate, onDelete
). De esta forma invoca los métodos de las clases obtenidas en el momento que se captura el evento correspondiente a la operación realizada.Sobre esta filosofía se desarrollaron dos clases que implementan la interfaz
TocororoCRUDListenerProvider, una clase encargada de la gestión de los metadatos
en Geonetwork y otra clase para la gestión de las capas de mapas en Geoserver. Con esto se garantizó la sincronización de la información en el entorno de la plataforma durante la gestión de la misma por parte de los usuarios.
Tocororo-Geoserver
Como se explicó anteriormente, se hizo uso del interceptor de Hibernate, desarrollándose la clase TocororoGeoserverInterceptor. Los métodos de esta clase son invocados cada vez que se realiza una inserción, actualización o eliminación de los objetos de Fuente de Datos y Espacio de Datos de Tocororo, garantizando la publicación de los servicios de mapas en Geoserver referentes a los contenidos de Tocororo. Para ello se utilizaron los servicios REST de Geoserver, mediante la biblioteca Geoserver-manager, biblioteca de código abierto provista por la empresa italiana Geosolutions51.
Por otra parte, el acceso a la estructura y datos de Tocororo se realizó mediante el desarrollo de una biblioteca, que utilizando el SDK de Tocororo accede a los servicios que proporcionan el contenido geoespacial de Tocororo (Espacios y Fuentes de Datos). La biblioteca se llamó gt-data-tocororo y su objetivo es hacer de Tocororo un proveedor de datos heredado de Geotools y por ende disponible para Geoserver (Ver Figura 15).
51
[49]
Figura 15: Clases implementadas en compatibilidad con Geotools.
Al poner la biblioteca dentro de Geoserver los Espacios de Datos y las Fuentes de Datos de Tocororo aparecen como tipos de datos disponibles a ser publicados. De esta forma se hacen disponibles a los datos de Tocororo una multiplicidad de facilidades de Geoserver, entre ellas se pueden mencionar las siguientes.
1. El acceso a los datos de Tocororo utilizando Interfaces estándares definidas por OGC como WMS y WFS.
2. La utilización de la tecnología WPS (Web Processing Service) para procesar los datos de Tocororo.
3. La utilización de extensiones desarrolladas por la comunidad de Geoserver en la interpretación de los datos como lo es la extensión para la generación de estilos con Gráficos.
La Figura 16 muestra la forma en que aparece Tocororo como un origen de datos de Geoserver junto a las otras fuentes de datos vectoriales que este posee.
[50]
Figura 16 Tocororo como un origen de datos de Geoserver.
Las capas de Tocororo relacionadas con los espacios de datos aparecen con un nombre que incluye al nombre del usuario, el carácter guión bajo (“_”) y el nombre del espacio de datos. En el caso de las fuentes de datos aparecen además concatenadas con el nombre de la fuente de datos (Ver Figura 17).
Figura 17: Capas de Tocororo disponibles en Geoserver.
Una vez publicadas las capas, están disponibles para ser accedidos por las interfaces estándares implementadas en Geoserver. De esta forma cada usuario puede tener sus datos publicados con una perspectiva de servicios de IDE por medio de las interfaces estándares, cumpliendo lo planteado en los aspectos de un Geoportal 2.0:
[51]
“En cuanto a la disponibilidad de datos, que los datos proporcionados por los usuarios estén disponibles en diferentes formatos (WMS, WFS, WCS, GeoRSS, KML, 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… “ Tocororo-Geonetwork
Se desarrolló la clase TocororoGeonetworkInterceptor que hace uso del interceptor de Hibernate mediante la implementación de la interfaz TocororoCRUDListenerProvider, al igual que para el caso de Geoserver visto previamente. Los métodos de esta clase son invocados cada vez que se realiza una inserción, actualización o eliminación de los objetos de Fuente de Datos y Espacio de Datos de Tocororo, garantizando la gestión de los metadatos en Geonetwork referente al contenido modificado.
Para ello se desarrolló una librería csw-transaction, que contiene las operaciones de inserción, actualización y eliminación de metadatos vía servicio CSW a la instancia de Geonetwork, que forma parte del geoportal. Esta librería fue incluida en el SDK de Tocororo, permitiendo la gestión de los metadatos de manera implícita a las operaciones de los usuarios sobre sus datos en Tocororo. Para la creación del metadato se hizo uso de la clase DefaultMetadata de la librería de java Geotoolkit52 y de su módulo geotk-metadata. Este módulo contiene el núcleo de las clases de metadatos. La implementación de geotk-metadata se enfoca en ISO 19115 ( ISO 19115, 2003), incluyendo su propia extensión de esta norma. El estándar ISO 19139 (ISO, 2007) define como el metadata ISO 19115 será representado en XML. La librería Geotk soporta la transformación a XML mediante las anotaciones JAXB53 .
De esta forma se gestionan los metadatos en Geonetwork de forma implícita a partir de los datos y las cartografías que han sido importados por los usuarios en el momento de crear un nuevo Espacio de Datos o Fuente de Datos en la plataforma de Tocororo, dando cumplimiento a otro de los aspectos del Geoportal 2.0:
52
Geotoolkit.org http://www.geotoolkit.org/ 53
Java Architecture for XML Binding , JAXB Reference Implementation https://jaxb.java.net/ https://jaxb.java.net/
[52]
“Para contribuir con datos SIG, que de forma simple se pueda cargar un archivo shape, que no sean obligatorios los metadatos aunque sí algunos campos fáciles de llenar…”
“Los metadatos no deben ser obligatorios para usar la infraestructura, estos deben derivarse de las acciones activas y pasivas del usuario….”