MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD Francisco Tous Llull, Antoni Reus Darder, Felip Salas Suau Fundació Illes Balears per la Innovació Tecnològica (IBIT) Parc BIT, edifici 17, planta 3, porta D-2, Palma de Mallorca {xisco,areus,fsalas}@ibit.org Miquel Ramis Amengual Ayuntamiento de Calvià C/ Julià Bujosa Sans, batle. nº 1, Calvià mramis@calvia.com RESUMEN Este artículo presenta un caso real de implantación de un sistema de egovernment en una administración local de las Islas Baleares. En el se abordan aspectos tecnológicos, funcionales y metodológicos. Al final se exponen las conclusiones a las que se ha llegado. PALABRAS CLAVES Integración sistemas, egovernment, servicios web, servidor de integración, trámites administrativos electrónicos. 1. INTRODUCCIÓN La administración pública en las Islas Baleares está estructurada en tres niveles: el autonómico, el insular y el local. Cada uno de estos niveles dispone de sus propios sistemas de información que en general se han desarrollado sin tener en cuenta las interacciones con los demás niveles. Por otra parte, cada una de las administraciones están fraccionadas en unidades administrativas. Muchas veces, los sistemas de información son específicos de determinadas unidades administrativas y no contemplan la interacción con los sistemas de información de las otras. No obstante, la implantación de sistemas de egovernment hacen que esta interacción sea cada día más necesaria, ya sea entre aplicaciones de una misma administración o entre aplicaciones de diferentes administraciones. Las diferentes aplicaciones que ya están implantadas en las administraciones están fuertemente acopladas a la organización, por lo que resulta muy difícil su substitución por otras que sean más adecuadas para un proyecto de egovernment. Este fuerte acoplamiento es debido a que estas aplicaciones mantienen gran cantidad de datos a veces difíciles de migrar, y que además, están fuertemente arraigadas entre el personal de la administración que se resiste al cambio. Además estas aplicaciones, al estar fabricadas por proveedores externos, no ofrecen muchas posibilidades de modificación. Ya sea por cuestión de costes, falta de disposición por parte del fabricante, plazos o temas de competencia entre proveedores. Por tanto, a la hora de abordar un proyecto de implantación de una plataforma de egovernment para una determinada administración, nos encontramos con: Unos sistemas de información muy dependientes de las estructuras organizativas. Que necesitan de grandes modificaciones funcionales para cumplir con los requisitos de interoperabilidad exigidos.
Que no admiten substitución y muchas veces, tampoco modificación. Con este escenario, la solución que se impone pasa por un modelo de integración de aplicaciones poco intervencionista con las aplicaciones existentes, muy flexible y con muchas facilidades de interconectividad. En este artículo hemos desarrollado un modelo de este estilo, basado en la utilización de un servidor de integración, que provee la interconexión entre las diferentes aplicaciones mediante la utilización de diferentes tipos de mecanismos. 2. METODOLOGÍA La implantación de un sistema de egovernment en una administración es un problema complejo y difícil de abordar. El gran número de aplicaciones a integrar que implica la construcción de un sistema de este tipo nos ha aconsejado abordar el problema por fases. En la primera fase se ha desarrollado un modelo teórico del sistema que nos ha permitido definir los requisitos, los módulos que formarán el sistema y la tecnología a utilizar para su implantación. En una segunda fase se ha construido un prototipo que se ha utilizado para implementar un número reducido de trámites, cada uno de ellos centrado en una funcionalidad concreta del sistema. Este prototipo nos ha permitido validar los requisitos y la viabilidad técnica de la implantación. Además nos ha permito definir nuevas funcionalidades a implementar en la siguiente fase. En una última fase se completa el sistema con la implementación de las funcionalidades detectadas en la fase anterior. 3. SISTEMA DE INFORMACIÓN DEL AYUNTAMIENTO DE CALVIÀ El Ayuntamiento de Calvià es la administración local en la cual se va ha implantar la plataforma de egovernment. Este es un ayuntamiento atípico por lo que respecta sus sistemas de información. El índice de penetración de las tecnologías de la información y las comunicaciones en este ayuntamiento es muy elevado si lo comparamos con el resto de ayuntamientos de las Islas Baleares. Además dispone de un departamento de informática que ha desarrollado gran parte de las aplicaciones que se utilizan. Antes de comenzar el proyecto y ateniéndonos a las aplicaciones que son objeto de nuestro estudio, el sistema de información del Ayuntamiento de Calvià está formado por: Sistema de tramitación. Se trata de un software de gestión de procesos de negocio muy orientado a la gestión de procedimientos administrativos. Este software es un desarrollo propio realizado en Java. Por lo tanto, admite modificaciones siempre y cuando sean transparentes para los usuarios. Las modificaciones que se plantean en este software van encaminadas a proveerle de mecanismos de conectividad con las demás aplicaciones a través de webservices. Gestor de contenidos. El gestor de contenidos es un portal web con un backoffice accesible por los usuarios del ayuntamiento donde se publica información de diferente índole: información corporativa, agenda, etc Este aplicativo, aunque de desarrollo propio realizado también en Java, adolece desde su diseño de una gestión amplia y exhaustiva para la publicación de los procedimientos administrativos, conformándose con un tratamiento sencillo muy cercano a la información de propósito general. Registro general. Esta aplicación gestiona el proceso de registro de entradas y salidas de documentos convencionales del ayuntamiento. En el nuevo contexto, esta aplicación también deberá gestionar las entradas y salidas de documentos electrónicos. Esta es una aplicación de desarrollo propio que admite todas las modificaciones que sean necesarias para poder gestionar las entradas y salidas de documentos electrónicos. Base de datos de información corporativa. Actualmente la base de datos corporativa contiene información de los ciudadanos que, en algunas ocasiones, se encuentra fragmentada entre los diferentes aplicativos que la gestionan. En el proyecto se pretende disponer de un servicio único de acceso a los datos independientemente de cual sea la aplicación que los mantiene.
4. MODIFICACIONES FUNCIONALES Además de los módulos que ya disponía el sistema de información del Ayuntamiento de Calvià se han tenido que añadir un conjunto de módulos. Mediante estos nuevos módulos se ha conseguido aumentar los servicios del sistema permitiendo completar el ciclo de egovernment con los ciudadanos. Al sistema se le han añadido dos tipologías de módulos. En primer lugar se encuentran los que tienen por objetivo dar información a los ciudadanos, así como ofrecer una interfaz para que el ciudadano pueda contactar con la administración: Sistema de información al ciudadano. La funcionalidad básica de este sistema cumple con el objetivo de informar a los ciudadanos acerca de la información que se posee de ellos y del estado de los trámites que tienen en curso. Es decir, en primer lugar, permite que el ciudadano consulte los datos que el Ayuntamiento tiene de él y en caso de que no fueran correctos permite modificarlos. En segundo lugar el ciudadano puede consultar en este sistema el estado en que se encuentran los trámites que tiene iniciados con el Ayuntamiento. Sistema de formularios. Cuando los ciudadanos se dirigen a la administración para realizar algún trámite generalmente lo hacen mediante formularios estándares. Por tanto, un bloque básico en un sistema de administración electrónica será el que permita crear, rellenar y enviar los formularios informáticamente. Algunos de los requisitos que debe cumplir este sistema son: facilidad de creación y gestión de los formularios por parte de los administradores del sistema; ofrecer ayuda a los ciudadanos para rellenar los formularios, indicando el contenido y el formato de los campos; posibilidad de imprimir el formulario rellenado con el formato estándar o enviar los datos electrónicamente; soporte para la firma electrónica. Gestor de contenidos orientado a procesos administrativos. Este sistema cumple la función básica de ofrecer información a los ciudadanos acerca de los procedimientos administrativos que tiene el Ayuntamiento. En concreto debe permitir exponer información acerca de los procedimientos administrativos así como los trámites, normativa,..., asociados a ellos. Este sistema se complementa con el gestor de contenidos con el objetivo de ofrecer información no sólo de los procedimientos sino de carácter más general. Sistema de notificaciones. Cuando un ciudadano ha iniciado un procedimiento administrativo o un trámite, la administración resuelve el expediente e informa al ciudadano del resultado. Para ello se va a necesitar un sistema de notificación al ciudadano. El flujo de información en este caso es de la administración al ciudadano. Este sistema también se puede utilizar por parte de la administración para iniciar una notificación sin necesidad de que el ciudadano haya iniciado un trámite anteriormente. En segundo lugar se encuentran un conjunto de módulos cuyo objetivo es dar servicios transversales a los otros módulos. Se detallan a continuación: Sistema de validación de firma electrónica. Este módulo permite comprobar la validez de las firmas electrónicas. Es deseable que permita validar firmas de diferentes autoridades de certificación. Para ello el sistema se ha construido con la arquitectura indicada en la figura 1, consistente en una interfaz genérica capaz de validar firmas realizadas con certificados digitales pertenecientes a distintas autoridades de certificación. Inicialmente validará certificados digitales de la FNMT (Fábrica Nacional de Moneda y Timbre) puesto que el Ayuntamiento de Calvià tiene un convenio con esta entidad. Posteriormente está previsto aceptar certificados de otras autoridades de certificación. Figura. 1. Arquitectura del validador de firma.
Sistema de sellado de tiempo. Este sistema permitirá a la plataforma de gobierno electrónico dar los servicios de sellado de tiempo a los sistemas que lo requieran. Entre los sistemas que lo necesitan están el registro general y el sistema de notificaciones. 5. ARQUITECTURA Como ya se ha señalado, una plataforma de administración digital está compuesta por una gran variedad de sistemas y repositorios de información, desarrollados con diferentes tecnologías y con diferentes capacidades de adaptación e interacción. Por ello se ha optado por una arquitectura basada en el intercambio de mensajes mediante un servidor de integración. La función del servidor de integración será la de recoger los mensajes de las diferentes aplicaciones, normalizarlos y entregarlos a la aplicación destino. Para ello el servidor de integración debe disponer de diferentes conectores que permitan la integración con las diferentes aplicaciones, los cuales permitan recoger un mensaje enviado mediante un protocolo y un formato determinado y transformarlo en un formato estándar (normalización), así como el paso contrarió, de transformar un mensaje en un formato estándar al formato específico de la aplicación (desnormalización) y enviarlo a la aplicación destino mediante un protocolo determinado. El servidor de integración también debe ser capaz de enrutar los mensajes, es decir, decidir un mensaje determinado a que aplicación va dirigida, según la información proporcionada por el emisor. En la figura 2 se ilustra la arquitectura general de la aplicación. Figura 2. Arquitectura del sistema. Las aplicaciones se han agrupado en tres bloques: Frontoffice: Aplicaciones que interactúan con los ciudadanos, proporcionando o recogiendo información. Sistemas internos: Sistemas que forman el núcleo interno para el funcionamiento de la administración, que no interactúan directamente con los ciudadanos si no con el personal de la administración. Servicios transversales: Aplicaciones que proporcionan servicios necesarios para el funcionamiento de las demás aplicaciones. A partir de este esquema el siguiente paso consiste en definir las interacciones, pero para ello se necesita llevar a cabo los siguientes pasos. Definir un modelo de referencia de datos que nos permita representar los datos que manejan las aplicaciones de una forma neutra y manejable. Por ejemplo definir la estructura de una dirección, los datos de una persona, de un edificio,
Definir los servicios que proporcionan cada una de las aplicaciones, su interfaz, usando para ello el modelo de referencia de datos. Pongamos por ejemplo una interfaz que dado el CIF de una empresa devuelva una dirección. Definir los mecanismos mediante los cuales se establecerá la comunicación entre cada aplicación y el servidor de integración (los conectores). Dependerá de las posibilidades de cada aplicación. Una vez, se han definido estos extremos, se puede empezar a implementar servicios como la composición de interacciones entre los diferentes componentes. 6. PROPUESTA TECNOLÓGICA Para implementar la arquitectura propuesta se han estudiado varios tecnologías y servidores de integración para llegar finalmente a esta propuesta que se está implementando: 6.1 Modelo de referencia de datos Para la representación del modelo de referencia de datos se ha optado por el uso de XML Schema [3] que nos permitirá definir una estructura XML para los mensajes que circularan en el sistema. XML Schema presenta diferentes ventajas frente al uso de otros sistemas como DTD. El documento XML Schema es un formato XML en si mismo por lo que existen multitud de herramientas para procesar este tipo de documentos. Permite utilizar una lista muy completa de tipos de datos y restricciones sobre los posibles valores. Son extensibles, mediante el uso de namespaces. Son muy utilizados dentro de los servicios web. De este manera el modelo de referencia de datos esta formado por un conjunto de XML Schema público para ser usado en los diferentes desarrollos e integraciones. 6.2 Descripción de los servicios Por lo que respecta a la definición de los servicios se ha optado por usar el lenguaje de descripción de servicios web (WSDL) 1.1. WSDL [2] es un formato XML que permite definir servicios, con dos partes diferenciadas: la parte abstracta define interfaces, con sus operaciones y mensajes, y la parte concreta que define los servicios que implementan las interfaces asignándoles unos determinados protocolos de red y puntos de entrada. Debido al auge de los servicios web, WSDL es un formato ampliamente usado para la definición de servicios, y permite el uso de XML Schema para definir la estructura de los mensajes y es también un formato extensible. 6.3 Servidor de integración Para la elección del servidor de integración se ha tenido en cuenta la importancia del uso de estándares y también el hecho de que el objetivo es desarrollar una plataforma idónea para cualquier administración local, eso supone que se debe evitar el uso de productos con costes de licencias por lo que su implantación sea difícil en administraciones con pocos recursos. Por ello se ha optado por el uso de un servidor de integración basado en Java Business Integration (JBI) [1], una nueva especificación promovida por el Java Comunity Process. JBI pretende crear una arquitectura estándar para soluciones de integración. Esta infraestructura permite el desarrollo de componentes de integración por parte de terceros, para su uso en cualquier plataforma basada en este estándar. Además JBI permite el uso de WSDL 2.0 y WSDL 1.1 para la definición de las interfaces de los componentes. Para el desarrollo de la plataforma se han iniciado pruebas con el servidor de integración ServiceMix, un servidor de código libre basado en JBI que ha sido adoptado por Apache. Servicemix, como otros servidores de integración, proporciona mecanismos de integración para interactuar con sistemas externos: sistema de mensajes JMS, integración con POP3/SMTP, servicios web
mediante HTTP/SOAP, acceso a FTP, a feeds RSS, sistema de ficheros, etc, además de permitir el uso de otros componentes o interacción con sistemas que soporten JBI. Para la integración de las diferentes aplicaciones se ha previsto el uso de servicios web mediante SOAP. Cada aplicación contará con la descripción de sus servicios mediante WSDL, que usará mensajes cuya estructura estará representada en el modelo de referencia de datos. Además el sistema también cuenta con un motor de transformación XSLT y un motor de BPEL. El primero permite la transformación de mensajes XML, permitiendo la conversión entre el modelo de referencia de datos y otros formatos usados por aplicaciones externas. El segundo permite la definición de nuevos servicios como la composición de invocaciones a otros servicios y motores, sean estos internos o externos. 7. CONCLUSIONES El alto grado de heterogeneidad de las aplicaciones que conviven en las diferentes administraciones públicas y la falta de orientación de estas a la interoperabilidad, hace que el uso de un servidor de integración sea una de las mejores opciones para abordar el reto de la integración. Mediante el uso de este tipo de aplicaciones se minimiza la intervención sobre las diferentes aplicaciones facilitando en gran medida el proceso de integración. Ante la gran envergadura, complejidad y variabilidad de este tipo de proyectos, nuestra experiencia nos demuestra que la mejor forma de abordarlos es a través de una metodología que contemple un desarrollo basado en prototipos, que permitan validar los requerimientos y funcionalidades a medida que avanza el proyecto. La utilidad de un modelo de referencia de datos común ha sido contrastada, sobre todo en lo hace referencia al diálogo con los distintos proveedores de las aplicaciones a integrar, de cara a definir las interfaces comunes. AGRADECIMIENTOS Este trabajo se ha desarrollado en el marco del proyecto Ciudades Digitales para las Islas Baleares. REFERENCIAS [1] Chappell, D., 2004. Enterprise Service Bus. O Reilly, Sebastopol, USA [2] Newcomer, E., 2002. Understanding Web Services: XML, Wsdl, Soap, and UDDI. Addison-Wesley Professional, Boston, USA [3] Vlist, E. V. D., 2002. XML Schema. O Reilly, Sebastopol, USA