Proyecto de Impulso del Urbanismo en Red Informe de Arquitectura

Transcripción

1 Proyecto de Impulso del Urbanismo en Red Informe de Arquitectura ED-URBR-01_Informe de Arquitectura_final 1

2 Comité de Expertos Marta Rodríguez-Gironés, Técnico del área de Urbanismo y Vivienda de la FEMP Emilio López Romero, Consejero técnico de la Dirección General de Urbanismo y Política de Suelo del Ministerio de Vivienda. Miguel Baiget Llompart, Consejero técnico de la Dirección General de Urbanismo y Política de Suelo del Ministerio de Vivienda. Francisco Ortiz Fernández, Coordinador de Programas de la Federación de Municipios de Castilla la Mancha. Lluis Sanz Marco, Subdirector del Instituto Municipal de Informática del Ayuntamiento de Barcelona. Rogelio Canedo Lamela, Jefe de Servicio de Cartografía del Ayuntamiento de Santiago de Compostela. Fernando Tricas Lamana, Director Técnico de Geopista. Fernando Serrano Martínez, Subdirector General de Estudios y Sistemas de la Información de la Dirección General del Catastro. Carmen Conejo Fernández, Subdirectora General Adjunta de Estudios y Sistemas de la Información de la Dirección General del Catastro. José Alfonso Solórzano Martín, Gerente Regional de Castilla la Mancha. Dirección General Catastro. ED-URBR-01_Informe de Arquitectura_final 2

3 Control Documental Proyecto: Titulo: Versión: Urbanismo en Red Informe de Arquitectura Final Fecha edición: 17/10/2007 Fichero: Autor(es): Resumen: ED-URBR-01_Informe de Arquitectura_final Comité de Expertos; Red.es; Urbimática Este documento presenta la arquitectura de sistemas para el proyecto de Impulso del Urbanismo en Red ED-URBR-01_Informe de Arquitectura_final 3

4 Índice 1. OBJETIVOS 5 2. ARQUITECTURA DEL SISTEMA PROPUESTA Arquitectura SOA Servicios WEB IDE Infraestructura de Datos Espaciales Arquitectura SOA GIS Dimensionamiento Comunicaciones Periféricos Tecnologías de Almacenamiento Seguridad Bases de Datos Espaciales Distribución/Particionamiento de Bases de Datos Espaciales Alta Disponibilidad y Garantías de Servicio exigibles Metadatos Espaciales Capa de Servicios Interoperables (OGIS) Capa de Servicios GIS básicos (geoprocessing, localización, generación de mapas y fichas) Capa de Publicación de Servicios de Metadatos Aseguramiento de la Escalabilidad del Sistema 65 ED-URBR-01_Informe de Arquitectura_final 4

5 1. OBJETIVOS El objetivo del presente documento es mostrar las posibles arquitecturas técnicas para llevar a cabo la implantación de la propuesta de solución definida por el grupo de trabajo para la publicación de la información urbanística (etapa de Planeamiento) en la red. El objetivo es plantear diferentes alternativas buscando siempre la interoperabilidad y transaccionalidad entre las diferentes soluciones posibles (presentadas en el Informe de Estado del Arte). ED-URBR-01_Informe de Arquitectura_final 5

6 2. ARQUITECTURA DEL SISTEMA PROPUESTA Arquitectura SOA Una Service-Oriented Architecture es una estrategia tecnológica por la cual las aplicaciones hacen uso de (o más precisamente, confían en) los servicios disponibles en una red. Las arquitecturas SOA son las que conforman el estándar actual de desarrollo: Una Arquitectura Orientada a Servicios (SOA) es una arquitectura que define cómo interoperan funciones de negocio independientes implementadas por sistemas autónomos para ejecutar un proceso de negocio. Implementar una arquitectura orientada a servicio comprende el desarrollo de aplicaciones que usen los servicios, aplicaciones disponibles como servicios para otras o ambas situaciones. ED-URBR-01_Informe de Arquitectura_final 6

7 Un servicio en SOA es una función de aplicación empaquetada como un componente reutilizable para ser usado en un proceso de negocio. El servicio proporciona información o facilita el cambio de datos de negocio de un estado válido y consistente a otro. Un servicio SOA es autocontenido y sin estado. La implementación concreta de un Servicio SOA no es importante. A través de protocolos de comunicación bien definidos, los servicios pueden ser invocados de manera que se hace hincapié en la interoperabilidad y en la transparencia de localización. El concepto de SOA no es nuevo. Las arquitecturas orientadas a Servicios han sido usadas durante años. La característica principal de SOA es que es una arquitectura con acoplamiento débil. Acoplamiento débil significa que el cliente de un servicio es esencialmente independiente de la construcción de ese servicio. Lo que es relativamente nuevo es la implementación de SOAs basadas en Web Services. Un Web Service es un servicio que se comunica con los clientes a través de un conjunto estándar de protocolos y tecnologías. Estos estándares están implementados en las plataformas y productos de los principales proveedores de software, lo que hace de los Web Services la principal opción para la construcción de arquitecturas SOA. Existen varias razones para que una empresa adopte un enfoque SOA, y más concretamente un enfoque SOA basado en Web Services: Reutilización: El factor fundamental en el cambio a SOA es la reutilización de los servicios de negocio. Las funciones de negocio, dentro de una empresa y con los business partners (por ejemplo los equipos redactores), pueden ser expuestos como web services y ser reutilizadas para cubrir nuevas necesidades de negocio. Interoperabilidad: El objetivo de una arquitectura débilmente acoplada es que los clientes y servicios se comuniquen independientemente de la plataforma en que residan. Los protocolos de comunicación con Web services son independientes de la plataforma, lenguaje de codificación y sistema operativo por lo que facilitan la comunicación con todos los actores involucrados en el proceso de planemiento. Escalabilidad: Como los servicios de SOA están débilmente acoplados, las aplicaciones que usan esos servicios escalan fácilmente. Esto es debido a que existe muy poca dependencia entre las aplicaciones clientes y los servicios que usan. Flexibilidad: Es otra de las características que proporciona el acoplamiento débil entre los servicios. Cualquier cambio en la implementación de uno de ellos no afectaría al resto siempre que se mantenga la interfaz. ED-URBR-01_Informe de Arquitectura_final 7

8 SOA permite una nueva forma de desarrollar capacidades de negocios a través de soluciones compuestas de manera flexible y estandarizada. Permite la combinación de servicios para dar soporte a los procesos de negocios. Eficiencia de coste: Las arquitecturas SOA se basan en la exposición de servicios ya existentes para ser reutilizados. Al usar Servicios Web para exponer estos servicios, se reutilizan la infraestructura Web existente en virtualmente todas las organizaciones por lo que se limita considerablemente el coste. Reduce los altos costos de soportar y mantener una lógica duplicada. Reduce, además, las inconsistencias entre los canales y las investigaciones manuales costosas. Alineación de la tecnología y los procesos Una SOA bien diseñada requiere una amplia participación del área de negocios que, en última instancia, permite a IT proporcionar servicios con mayor rapidez y brindar soluciones de negocios versus la mera implementación de una funcionalidad de la aplicación. Experiencia del cliente superior Reduce el tiempo de llegada al mercado de nuevas capacidades. Es consistente respecto de los datos sin importar el canal utilizado (por ejemplo, teléfono, representantes de servicio al cliente, Web) Reutilización de los activos y servicios existentes Una arquitectura basada en los servicios se focaliza en la reutilización de los activos existentes por medio de la creación de servicios de negocios. SOA permite agrupar a los servicios de negocios para soportar uno o más procesos de negocios y evitar aplicaciones autónomas o en silos. Enfoque basado en estándares A diferencia de las tecnologías de integración propietarias, la compatibilidad basada en estándares reduce la complejidad. Permite a las soluciones futuras conectarse a los servicios existentes y estándar. Las Claves diferenciadoras de SOA son: Fijar la atención en mostrar los procesos de negocio. Los servicios ejecutan transacciones de negocio completas, más que funciones de aplicaciones. La atención está en los servicios a proveer más que en su propia implementación Potenciar la interoperabilidad A través del ensamblaje o la encapsulación de las funciones de negocio A través de SLA s o una operación de servicio correctamente definida ED-URBR-01_Informe de Arquitectura_final 8

9 Transparencia en la localización de los servicios (Separación de servicios de clientes y proveedores) Implementación de estándares a través de Web Services La intersección de SOA con la integración de aplicaciones y el modelado de procesos de negocio, dan lugar a un nuevo producto denominado Enterprise Service Bus (ESB). El ESB permite la integración de aplicaciones de forma rápida, directa y basada en estándares. El Enterprise Service Bus es una suite de productos independientes de la infraestructura que facilita el procesado, la transformación de datos, el enrutamiento y la orquestación de procesos usando Web Services. El ESB puede hacer uso de la infraestructura existente de servidores de aplicaciones, transportes, aplicaciones y datos por lo que típicamente resulta en un ROI de un orden de magnitud mejor que los enfoques tradicionales de integración de aplicaciones Servicios WEB Un Servicio Web: es una aplicación accesible vía Internet, mediante mensajes, que comprenden: Datos en XML Comunicación HTTP-Get, HTTP-Post, SOAP Descripción SDL, WSDL Combina desarrollos basados en componentes con desarrollos Web. ED-URBR-01_Informe de Arquitectura_final 9

10 El interfaz se define en términos de los mensajes que acepta y genera. Los consumidores de un Servicio Web pueden estar implementados en cualquier lenguaje y plataforma, el único requerimiento que necesitan es crear y consumir los mensajes que define el interfaz del Servicio Web. Un diagrama de contexto para los actores de Planeamiento sería: Qué no son los servicios WEB? NO solucionan todos los problemas de integración NO son siempre la mejor opción NO son estrictamente necesarios en todas las aplicaciones Web NO tienen impacto cero en la aplicación que los publica NO invalidan el resto de accesos Web a mi organización (portal corporativo, de empleado, B2Cs, ) NO son la única aplicabilidad del XML NO son el único camino: a la hora de intercambiar información entre aplicaciones internas, de mi propia organización, donde tengo acceso a todos los recursos, deben valorarse otras opciones ED-URBR-01_Informe de Arquitectura_final 10

11 Para la total implementación de un Servicio Web, no sólo es necesario desarrollar la lógica de negocio y gestionar el intercambio de mensajes SOAP, también hay que proporcionar una definición SDL, WSDL del servicio y anunciarlo vía UDDI. Qué es SOAP? Simple Object Access Protocol (SOAP) es un protocolo basado en XML para el intercambio de información tipada y estructurada en un entorno descentralizado y distribuido. El objetivo de SOAP es permitir el desarrollo de Servicios Web basados en la infraestructura que ofrece Internet (programar la Web). SOAP utiliza HTTP para intercambiar mensajes formados en XML. Ofrece un protocolo estándar, para la invocación de objetos, construido a partir de los estándares de Internet, utilizando HTTP como transporte y XML como contenedor de los datos. Crea un protocolo extensible que puede evolucionar fácilmente. Antes de acceder a un Servicio Web, es necesario conocer la definición formal del servicio, esta definición se puede encontrar en dos formatos distintos: En un único fichero XML: Service Description Language (SDL) describe el formato de los mensajes SOAP y los protocolos que los soportan. En dos ficheros XML: Web Services Description Language (WSDL) describe el servicio, sus operaciones asociadas y el formato de los mensajes SOAP. Web Services Meta Language (WSML) proporciona la información necesaria para mapear las operaciones de un servicio descritas en el fichero WSDL a métodos específicos del objeto COM. ED-URBR-01_Informe de Arquitectura_final 11

12 La estrategia de seguridad para los Web Services que se impone es la misma que en cualquier otra aplicación web: Acceso público a través de Internet Certificación. Autentificación. Encriptación. Verificación de la integridad de los mensajes. Elementos de seguridad perimetral e interna (Firewall y Proxies). Acceso sólo a través de la Intranet. Dependerá de las necesidades de seguridad a implementar. Pueden llegar a ser los mismos que el anterior. Este esquema es enormemente flexible, dado que la implementación física de dicho bus de interoperabilidad se puede implementar en algunos casos con herramientas comerciales y en otros casos con herramientas libres o de bajo coste. El esquema típico de la arquitectura basada en Web Services sería: IDE Infraestructura de Datos Espaciales Una IDE (Infraestructura de Datos Espaciales) es un sistema informático integrado por un conjunto de recursos (catálogos, servidores, programas, datos, aplicaciones, páginas ED-URBR-01_Informe de Arquitectura_final 12

13 Web, ) dedicados a gestionar Información Geográfica (mapas, ortofotos, imágenes de satélite, topónimos, ), disponibles en Internet, que cumplen una serie de condiciones de interoperabilidad (normas, especificaciones, protocolos, interfaces, ) que permiten que un usuario, utilizando un simple navegador, pueda utilizarlos y combinarlos según sus necesidades. El establecimiento de una IDE, a nivel local, regional, estatal o global, requiere del acuerdo de los productores, integradores y usuarios de datos espaciales del ámbito territorial en el que se establece. Este acuerdo debe considerar también las IDE definidas, o en definición, en otros ámbitos territoriales superiores, hacia las cuales deberá converger. La justificación del establecimiento de una IDE, esta ligada a dos ideas fundamentales: La necesidad de manera fácil, cómoda y eficaz de los datos geográficos existentes. La Información Geográfica ha sido hasta ahora un recurso de costosa producción y difícil acceso por varios motivos: formatos, modelos, políticas de distribución, falta de información, La oportunidad de reutilizar la Información Geográfica generada en un proyecto para otras finalidades diferentes, dado el alto coste de su producción. Si se lleva a la práctica este tipo de arquitectura para el proyecto de Impulso del Urbanismo en la Red, una primera aproximación sería la creación de un conjunto de IDEs (Infraestructuras de Datos Espaciales) para cada uno de los Centros Gestores de Planeamiento. Hay que recordar también que todas las iniciativas para el establecimiento de una IDE incluyen unos principios comunes ( Marco Institucional: el establecimiento de acuerdos entre los productores de información geográfica, especialmente entre los productores oficiales, al objeto de generar y mantener los datos espaciales fundamentales («Framework data») para la mayoría de las aplicaciones basadas en sistemas de información geográfica. Estándares: el establecimiento de normas a las que deberá ajustarse la información geográfica, los intercambios de esta y la interoperación de los sistemas que la manejan. Tecnología: el establecimiento de la red y mecanismos informáticos que permitan: buscar, consultar, encontrar, acceder, suministrar y usar los datos espaciales o geográficos. Como por ejemplo permitir incorporar los metadatos organizados en catálogos y ofrecerlos en la red a través de servidores. Política de datos: El establecimiento de las políticas, alianzas y acuerdos de colaboración necesarios para aumentar la disponibilidad de datos espaciales y compartir los desarrollos tecnológicos. ED-URBR-01_Informe de Arquitectura_final 13

14 Los componentes de una IDE son: Datos En la actualidad existe un consenso internacional que clasifica los datos espaciales que pueden manejar las IDEs en: Datos de referencia Son aquellos datos georreferenciados fundamentales que sirven de esqueleto para construir o referenciar cualquier otro dato fundamental o temático. Constituyen el marco de referencia que proporciona el contexto geográfico a cualquier aplicación. Cumplen la función de ser la Información Geográfica de referencia utilizada como base común que permite mezclar e integrar datos de aplicaciones de todo tipo al ser el vínculo o nexo de unión. La iniciativa europea INSPIRE ha definido los temas que deben ser considerados como Datos de Referencia, en los Anexos I y II en la Propuesta de Directiva por la que se establece una Infraestructura de Información Espacial de la Comunidad (INSPIRE): Sistema de Coordenadas. Cuadrículas Geográficas. Nombres geográficos. Unidades Administrativas. Redes de Transporte. Hidrografía. Lugares Protegidos. Elevación. Identificadores de Propiedad. Parcelas Catastrales. Cubierta Terrestre. Ortoimágenes. Datos temáticos Son los datos propios de aplicaciones específicas que explotan la Información Geográfica con una finalidad concreta. Incluyen valores cualitativos y cuantitativos ED-URBR-01_Informe de Arquitectura_final 14

15 que se corresponden con atributos asociados a los datos de referencia como por ejemplo: vegetación, geología, clima, tráfico, contaminación, etc. Metadatos La estructura y el contenido de los metadatos deben estar basados en una norma aceptada y ampliamente utilizada. Uno de los beneficios de las normas es que son fruto de la experiencia y del consenso, ya que han sido desarrolladas y revisadas por un grupo internacional de expertos que han aportado una considerable diversidad cultural y social. En particular, las normas ISO19100 relativas a Información Geográfica proporcionan una base desde la que pueden desarrollarse perfiles, o particularizaciones de la norma, nacionales y sectoriales. En la actualidad existen diferentes normas y perfiles dentro del campo de los metadatos que es interesante mencionar: ISO Geographic information Metadata Norma Internacional de metadatos perteneciente a la familia ISO desarrollada por el Comité Técnico 211, perteneciente a la Organización de Estandarización Internacional (ISO) que proporciona un modelo de metadatos y establece un conjunto común de terminología, definiciones y procedimientos de ampliación para metadatos. Ha sido adoptada como Norma Europea por el CEN/TC287 y como Una Norma Española por AEN/CTN148 Información Geográfica, por lo que está disponible en español. Núcleo Español de Metadatos NEM Recomendación definida por el Grupo de Trabajo de la IDEE, establecida en forma de perfil de ISO Es un conjunto mínimo de elementos de metadatos recomendados en España para su utilización a la hora de describir recursos relacionados con la información geográfica. Está formado por la ampliación del Núcleo (Core) de la Norma ISO de Metadatos, con los ítems de ISO19115 necesarios para incluir los elementos del Dublín Core Metadata, la descripción de la Calidad y los elementos requeridos por la Directiva Marco del Agua. Dublín Core Metadata Iniciativa La iniciativa Dublín Core Metadata es un foro abierto dedicado al desarrollo de estándares en la línea de los metadatos. Tiene como actividades principales: la formación de grupos de trabajo, conferencias globales y talleres y desarrollo de prácticas en el campo de los metadatos. Esta iniciativa definió 15 elementos básicos y esenciales para describir un recurso cualquiera (fichero, mapa, libro,..) y en la actualidad es la iniciativa de metadatos más utilizada. Para más información consultar la página Web: Servicios ED-URBR-01_Informe de Arquitectura_final 15

16 Mucho más adecuado que concebir una IDE como algo basado en los datos geográficos disponibles, es pensar que una IDE es en realidad un conjunto de servicios, que ofrecen una serie de funcionalidades que resultan útiles e interesantes a una comunidad de usuarios. De forma que el énfasis se pone en los servicios, en la utilidad. Se establece un juego nuevo con reglas nuevas; desde el punto de vista de las IDEs, al usuario no le interesa ya tanto descargarse los datos en su sistema, sino obtener directamente las respuestas que necesita y que un servicio le ofrece. Los servicios IDE ofrecen funcionalidades accesibles vía Internet con un simple navegador o browser, sin necesidad de disponer de otro software específico para ello. Servicio de Mapas en Web (WMS) Su objetivo es poder visualizar Información Geográfica. Proporciona una representación, una imagen del mundo real para un área requerida. Esta representación puede provenir de un fichero de datos de un SIG, un mapa digital, una ortofoto, una imagen de satélite, Está organizada en una o más capas, que pueden visualizarse u ocultarse una a una. Se puede consultar cierta información disponible y las características de la imagen del mapa. Una especificación del Open Geospatial Consortium (OGC) establece cómo debe ser un WMS estándar e interoperable, que permita superponer visualmente datos vectoriales, ráster, en diferente formato, con distinto Sistema de Referencia y Coordenadas y en distintos servidores. Servicio de Fenómenos en Web (WFS) Ofrece el poder acceder y consultar todos los atributos de un fenómeno (feature) geográfico como un río, una ciudad o un lago, representado en modo vectorial, con una geometría descrita por un conjunto de coordenadas. Habitualmente los datos proporcionados están en formato GML, pero cualquier otro formato vectorial puede ser válido. Un WFS permite no solo visualizar la información tal y como permite un WMS, sino también consultarla libremente.. Una especificación Open Geospatial Consortium establece cómo debe ser un WFS estándar e interoperable. Servicio de Coberturas en Web (WCS) Es el servicio análogo a un WFS para datos ráster. Permite no solo visualizar información ráster, como ofrece un WMS, sino además consultar el valor del atributos o atributos almacenados en cada píxel. Una especificación Open Geospatial Consortium establece cómo debe ser un WCS estándar e interoperable Servicio de Nomenclátor (Gazetteer) Ofrece la posibilidad de localizar un fenómeno geográfico de un determinado nombre. Se define como un servicio que admite como entrada el nombre de un fenómeno, con las posibilidades habituales de nombre exacto, comenzando por, nombre incluido, y devuelve la localización, mediante unas coordenadas, del fenómeno en cuestión. Adicionalmente, la consulta por nombre permite fijar otros ED-URBR-01_Informe de Arquitectura_final 16

17 criterios como la extensión espacial en que se desea buscar o el tipo de fenómeno dentro de una lista disponible (río, montaña, población, ). Si hay varios que cumplen la condición de búsqueda, el servicio presenta una lista de los nombres encontrados con algún atributo adicional para que el usuario pueda elegir el que desea. Evidentemente este servicio necesita disponer de un conjunto de nombres con coordenadas. Una especificación Open Geospatial Consortium establece cómo debe ser un Servicio de Nomenclátor estándar e interoperable. Servicio de Geoparser Un Servicio de Geoparser analiza palabra por palabra un texto digital dado, efectúa comparaciones con un conjunto de nombres geográficos dado y crea los vínculos o enlaces necesarios para que exista una referencia permanente en el texto original a los fenómenos geográficos aludidos. Transforma el texto original en un hipertexto con vínculos geográficos. Este servicio se basa y utiliza un Servicio de Nomenclátor. Servicio de Catálogo (CSW) Un Servicio de Catálogo permite la publicación y búsqueda de información (metadatos) que describe datos, servicios, aplicaciones y en general todo tipo de recursos. Los servicios de catálogo son necesarios para proporcionar capacidades de búsqueda e invocación sobre los recursos registrados dentro de una IDEs. Una especificación Open Geospatial Consortium establece cómo debe ser un Servicio de Catálogo estándar e interoperable. Descriptor de Estilo de Capas (SLD) Esta especificación de la OGC describe un conjunto de reglas de codificación que permite al usuario definir estilos de simbolización de las entidades personalizados. Es recomendable leer esta recomendación junto con la última versión de la especificación WMS. Los servicios OGC pueden ser encadenados y combinados en un Geoportal, ofreciendo por ejemplo la posibilidad de: buscar un fenómeno por nombre (Nomenclátor) y visualizar el resultado sobre unos datos de referencia (WMS); localizar un producto seleccionando algunas características (Catálogo) y visualizarlo en pantalla (WMS o WCS). También es posible basarse en un servicio OGC para implementar servicios que ofrezcan funcionalidad adicional, por ejemplo desarrollar un servicio de camino mínimo por carretera basado en un WFS que acceda a todos los atributos de un conjunto de datos de poblaciones y carreteras. ED-URBR-01_Informe de Arquitectura_final 17

18 Arquitectura SOA GIS Los Organismos Públicos están encontrando progresivamente nuevas necesidades de utilización de información y servicios espaciales. Estudios recientes han llegado a establecer que más del 90% de la información con la que trabaja la Administración Pública puede ser georreferenciada. La tecnología GIS se comienza a valorar como un elemento importante para la toma de decisiones y el trabajo colaborativo, estableciendo un marco común para todos los elementos: el territorio. Durante mucho tiempo ha sido importante suministrar información geoespacial de forma eficiente. Sin embargo, ahora se hace necesario, además de suministrar este tipo de información, ofrecer servicios que permitan integrar datos y funcionalidad GIS en cualquier entorno corporativo, interoperando con otros servicios como ERP, CRM, etc. Técnicamente, los servicios WEB son aplicaciones modulares que se pueden identificar con funciones de negocio y que pueden ser utilizados mediante un conjunto de protocolos o estándares, que permiten que éstos sean creados, publicados y descubiertos. A nivel organizativo, los Servicios WEB son los elementos tecnológicos que permiten crear estrategias de integración global a nivel corporativo entre todos los sistemas de una organización o administración. Los servicios web son la base tecnológica que permite la integración entre entornos heterogéneos creando una arquitectura denominada SOA (Service Oriented Architecture). En el entorno GIS esto ha supuesto extender las tecnologías existentes de entornos desktop hacia soluciones GIS corporativas que ofrecen sus capacidades mediante Servicios WEB, a esta evolución se la denomina GeoSpatial SOA (Arquitectura Orientada a Servicios Geoespaciales. Construir una arquitectura orientada a servicios espaciales (Geospatial SOA) es un proceso que requiere a partes iguales el conocimiento del funcionamiento interno de la organización (sus procesos de negocio, su organización funcional, su organización estructural, etc) y de las capacidades de la plataforma GIS seleccionada para llevarlo a cabo. La puesta en marcha de esta infraestructura espacial en una organización es un proceso que requiere en primer lugar la identificación de todos los procesos internos para generar un catálogo de funciones geoespaciales comunes identificables. Todas estas funciones comunes identificables se analizarán y diseñarán para construir los servicios WEB sobre la tecnología seleccionada para proveer a la organización de un conjunto de operaciones fiables, accesibles y sobre todo que generan realmente un ahorro de costes importante (frente a la tradicional implementación de GIS departamentales). Lo más importante a tener en cuenta es que estos procesos no tienen por qué ser revolucionarios, sino más bien deben ser evolucionarios. Esto se debe a que no se trata sino de ampliar, mediante las herramientas que ofrece la tecnología SOA, las ED-URBR-01_Informe de Arquitectura_final 18

19 posibilidades de los sistemas existentes dotándoles de mecanismos de integración y facilitando su difusión (plataforma de integración). Una Geospatial SOA se sustenta en el trabajo GIS de profesionales que conforman un backoffice de modelos, datos, procesos y aplicaciones. Todo este contenido se publica mediante servicios a través de un conjunto de servicios. Lo importante es que no exista límite teórico de la plataforma para la generación desde servicios sencillos hasta la más compleja suite de herramientas de geoprocesamiento (Server-side). La escalabilidad de la plataforma, su estabilidad y su rendimiento serán características importantes para la selección de la plataforma. Una vez publicados los servicios se consumirán por un conjunto de aplicaciones cliente (por ejemplo, visores WEB ligeros, clientes móviles, aplicaciones GIS desktop, otras aplicaciones corporativas, etc). Es importante que la plataforma garantice el uso de los servicios por cualquier cliente y que soporte todos los estándares de interoperabilidad (OpenGIS Consortium), para garantizar que son accesibles desde cualquier aplicación comercial o no. Los servicios deben poder integrarse con otros entornos corporativos (Sistemas Workflow, ERP, CRM, CIS, etc) en cualquier proceso operativo interno (o externo). Integración de servicios espaciales (SOA) con SAP ERP. Para la construcción del sistema, dado que estamos hablando de los procesos críticos es fundamental elegir de forma acertada la plataforma (por criterios de seguridad, escalabilidad y rendimiento). Evidentemente existen en la actualidad grandes Ayuntamientos con enormes infraestructuras GIS y plataformas definidas, mientras que otros se han decidido por esquemas opensource que permitan evitar los altos costes de adquisición y mantenimiento del software comercial. La capa de Servicios WEB y la infraestructura de Registros y Repositorios (BBDD/Metadatos) es necesario crearla para acomodar todos los niveles indicados. Dicha ED-URBR-01_Informe de Arquitectura_final 19