Grupo de apoyo a la preparación de la XXII convocatoria de oposiciones al Cuerpo Superior de Sistemas y Tecnologías de la Información de la Administración del Estado
INTEGRACIÓN APLICACIONES
DE
COMPONENTES,
SERVICIOS
Y
El objetivo de esta guía es enumerar las diferentes opciones que tenemos a la hora de conseguir que varias aplicaciones trabajen de forma conjunta, sin entrar a describir en profundidad las diversas tecnologías. Se consideran las situaciones en las que puede ser conveniente emplear cada tecnología, así como los escenarios de uso habituales.
Servicios Web (WS) Actualmente es la tecnología por excelencia para integrar aplicaciones. Es la primera opción que debemos contemplar, salvo que se den circunstancias que desaconsejen su uso. Existen multitud de especificaciones en torno a los servicios web, mayoritariamente emitidas por los consorcios W3C y OASIS. En la mayoría de los casos, es suficiente con emplear el conjunto de protocolos incluidos en el WS-I Basic Profile (perfil básico definido por la Organización para la Interoperabilidad de Servicios Web): SOAP para describir el formato de los mensajes y WSDL como descriptor de los servicios son los protocolos principales. Los WS son neutrales desde el punto de vista del lenguaje de programación y las plataformas de ejecución. Existen implementaciones certificadas en el perfil básico WS-I para múltiples plataformas y lenguajes: Zend Framework para PHP, gSOAP para C/C++, ASP.Net 2.0 o WCF para la plataforma .Net, etc. En el entorno JavaEE, las implementaciones de la API JAX-WS (JSR 224) son conformes al perfil básico WS-I. Apache Axis 2 es una implementación bastante popular de la JSR 224, distribuida bajo licencia libre Apache Software Foundation. SOAP es independiente del transporte. Lo que se entiende normalmente al hablar de WS es SOAP sobre HTTP o HTTPS, pero también sería válido el intercambio de mensajes SOAP sobre FTP, SMTP, directamente sobre conexiones TCP/UDP, etc. La principal ventaja de SOAP sobre HTTP es que no presenta problemas para atravesar los firewalls, ya que estos se configuran habitualmente para dejar pasar el tráfico HTTP. REST nace como una alternativa para simplificar la comunicación entre procesos. Está basado en un esquema cliente-servidor, y utiliza el protocolo HTTP como modelo central de comunicación. Mientras que trabajar con SOAP en JavaScript, por ejemplo, implicar escribir una importante cantidad de código porque la estructura XML debe ser creada cada vez, REST resuelve este conflicto basándose en simples direcciones URL. En casi todas las situaciones los servicios se comunicarán via URL, a través de comandos GET, POST, PUT y DELETE. Esta notable sencillez es el gran punto fuerte de REST. Prácticamente no tiene costos de aprendizaje, y de manera directa se pueden desarrollar servicios web sin la necesidad de pesados protocoles de comunicación. Comparación SOAP - REST Si bien ambos proveen la misma funcionalidad (comunicar dos servicios web), sus raíces son distintas. REST está basado en un esquema cliente-servidor, mientras que SOAP es un protocolo dedicado al intercambio de datos entre dos puntos dedicados. Esto ya saca a relucir una diferencia importante desde el punto de vista arquitectónico. Con respecto a seguridad, ninguno es particularmente más “seguro” que el otro, aunque SOAP cuenta con extensiones que garantizan seguridad punto a punto. Si tiene ventajas SOAP desde el punto de vista de transacciones, contemplando nociones como Two-Phase commit, y otros enfoques para el manejo de transacciones
1
Grupo de apoyo a la preparación de la XXII convocatoria de oposiciones al Cuerpo Superior de Sistemas y Tecnologías de la Información de la Administración del Estado distribuidas. REST, priorizando un protocolo simple y ligero, adolece de este tipo de cuestiones. En cuanto a la posibilidad de adaptarse a diferentes plataformas, si bien REST depende del protocolo HTTP, SOAP ofrece muchas extensiones, con sutiles diferencias entre sí, y comunicarlas a todas en un lenguaje común no es tan simple en muchas ocasiones. Luego, REST parece salir mejor parado de esta situación, teniendo como única precondición la comunicación via URLs. REST permite inúmeros formatos de datos, dando por ejemplo al desarrollador la posibilidad de utilizar JSON que normalmente es más rápido y como permite la utilización de JSON, permite también un mejor soporte a los clientes del explorador. SOAP solamente permite XML. Lo más habitual al hablar de WS es considerar un modelo petición-respuesta síncrono, pero las especificaciones son suficientemente flexibles para permitir otros modelos: petición-respuesta asíncrona, notificación en un solo sentido (sin respuesta del servidor), etc.
Mecanismos de integración de aplicaciones tradicionales Deben ser tenidos en cuenta como posible alternativa al uso de WS. Los principales son los siguientes: Envío de ficheros.- Es el mecanismo de integración más primitivo, en el que una aplicación genera un fichero con un formato preestablecido y lo deposita en una ruta determinada (posiblemente mediante envío FTP a un servidor remoto); otra aplicación lee este fichero y lo procesa, y genera ficheros de respuesta que luego pueden ser recogidos por la primera aplicación. Aunque presenta desventajas evidentes que lo hacen poco mantenible (falta de formatos estandarizados, alto grado de acoplamiento entre las aplicaciones,...), puede ser una buena solución cuando se requiere una transmisión y procesado de grandes volumenes de datos, especialmente en entornos de comunicación cerrados (en los que las aplicaciones que van a generar y consumir la información se conocen de antemano). En el ámbito tributario y de la Seguridad Social, todavía existen mecanismos de este tipo para la consulta y/o envío masivo de información, utilizados frecuentemente por empresas y otros organsimos públicos. Base de datos compartida.- Supone una mejor respecto al envío de ficheros. Múltiples aplicaciones comparten un esquema de datos sobre una misma base de datos física. Evita duplicidad en el almacenamiento y la transferencia de datos entre aplicaciones. El empleo de vistas lógicas permite cierto grado de aislamiento entre las aplicaciones. Es una buena solución para compartir información e integrar aplicaciones dentro de la propia organización. Es complicado implementar un patrón de interacción del tipo petición-respuesta. Remote Procedure Call (RPC).- Nombre genérico para todos los mecanismos en los que un programa es capaz de llamar a una rutina de otro programa que se está ejecutando en una máquina remota y obtener una respuesta. En su día fueron populares los estándares DCOM o CORBA. SOAP es un tipo de mecanismo RPC; de hecho, es la evolución del antiguo estandar XML-RPC. La única ventaja que pueden presentar estos mecanismos clásicos respecto a los servicios web es que introducen menos sobrecarga de información (las cabeceras SOAP y la serialización XML no resulta óptima para transmitir grandes volumenes de información). No obstante, no hay demasiados motivos para considerar este tipo de integración, salvo que haya que dar soporte a la integración de aplicaciones heredadas (legacy) que no permitan otro tipo de interacción.
Middleware de integración de aplicaciones Son productos software cuya finalidad es facilitar la integración de aplicaciones heterogéneas. Son características habituales de este tipo de productos: Independencia del fabricante, la plataforma o el lenguaje de programación de las aplicaciones, ofreciendo adaptadores para múltiples transportes y protocolos (HTTP, FTP, REST, SOAP, SAP RFC, DCOM, CORBA, objetos Java simples,...) Mapeo entre productores y consumidores de información y enrutado de mensajes dinámico y basado en reglas. 2
Grupo de apoyo a la preparación de la XXII convocatoria de oposiciones al Cuerpo Superior de Sistemas y Tecnologías de la Información de la Administración del Estado
Encolado y priorización de mensajes. Orquestación de servicios. Calidad de servicio: validación de mensajes, seguridad (autenticación, encriptación), entrega confiable, gestión de transacciones,etc. Herramientas de gestión: monitorización, métricas, auditoría, registro de eventos,etc.
Básicamente, los productos que se definen como middleware de integración caen en una de las siguientes categorías: Buses de Servicios Empresariales (Enterprise Service Bus o ESB) o Colas/Brokers de Mensajería Asíncrona (Message Queues o MQ). Los primeros están más orientados al paradigma petición/respuesta, mientras que los segundos se orientan hacia el paradigma publicación/subscripción. Para una descripción más detallada de los ESB, véase la guía “Módulos Software > Herramientas ESB”. El cuadrante mágico de Gartner para herramientas de integración de aplicaciones publicado en junio de 2013 sitúa como líderes del mercado a los fabricantes Software AG (webMethods), IBM (WebSphere MQ, WebSphere Registry and Repository), Oracle (Oracle SOA Suite), Tibco Software (ActiveMatrix ESB, ActiveMatrix BusinessWorks, Business Connect) y Microsoft (BizTalk Server).
Escenarios habituales de integración de aplicaciones Servicios comunes dentro de la Organización.- En los sistemas de información de todos los organismos administrativos existen aplicaciones horizontales cuya finalidad es ofrecer un determinado servicio a otro conjunto de aplicaciones internas. Ejemplos de este tipo de servicios son el registro electrónico, el gestor documental/archivo de expedientes, el portafirmas electrónico, servicios de autenticación mediante certificado electrónico, servicio de notificaciones electrónicas, plataforma de envío de SMS, etc. Es recomendable que todos estos componentes de servicio horizontales implementen una interfaz WS, de forma que se consiga maximizar la interoperabilidad con distintas plataformas y lenguajes de programación y minimizar la dependencia con las aplicaciones consumidoras. En el caso concreto de los gestores de contenidos, es habitual usar el estándar CMIS (Content Management Interoperability Services), que es una extensión de SOAP. Servicios compartidos entre Administraciones.- La mayor parte de servicios reutilizables de las Administraciones Públicas accesibles a través de la red SARA implementan una interfaz de servicios web para su utilización, permitiendo que cada organismo integre estos servicios en sus propias aplicaciones de tramitación. Algunos de estos servicios transversales de uso muy común y que cuentan con una interfaz WS son: el servicio Valide para verificación de validez de certificados y firmas electrónicas, los servicios de la plataforma de sellado de tiempo TS@, la pasarela de pago telemático, la consulta del punto general de entrada de facturas electrónicas (FACE), los servicios de publicación de licitaciones y adjudicaciones en la Plataforma de Contratación del Estado (PLACE),etc. Puede consultarse más información sobre servicios compartidos en la sección “Transversal > Servicios Red SARA”. Plataforma de Intermediación.- Como caso particular de servicio horizontal accesible a través de la Red SARA, la Plataforma de Intermediación se utiliza para recabar, previa autorización, determinada información sobre ciudadanos que obra en poder de otros organismos: datos fiscales y de la seguridad social, titulaciones académicas oficiales, datos catastrales,... La obtención de datos se realiza mediante llamadas a WS síncronas o asíncronas. El proveedor de información debe publicar también sus propios WS para que la Plataforma de Intermediación los invoque cuando sea necesario. Obligaciones de suministro de información.- Determinados organismos públicos ejercen una función de control o fiscalizadora sobre otros organismos, por ejemplo, en los ámbitos de la contratación pública, la ejecución del presupuesto o la concesión de ayudas y subvenciones. Los sistemas informáticos que mantienen estos órganos de control para la remisión de información, además de tener una interfaz web de consulta y envío, suelen incorporar diversos mecanismos de integración (tales como interfaces WS o procesamiento masivo de ficheros), con el fin de que los
3
Grupo de apoyo a la preparación de la XXII convocatoria de oposiciones al Cuerpo Superior de Sistemas y Tecnologías de la Información de la Administración del Estado organismos obligados al suministro de información incorporándolos a sus propios sistemas de tramitación.
puedan
automatizar
estos
procesos
Federación de sistemas de información.- Puede aparecer también el caso de una Administración que tenga que compartir determinados registros o catálogos de información con otras administraciones de ámbito nacional o internacional, con el fin de crear un registro o catálogo federado: catálogos de biblioteca, historial sanitario, registros policiales, catálogo de bienes protegidos, etc. En estos escenários, cada administración mantiene su propio sistema, pero debe habilitar mecanismos de integración que permitan al resto de administraciones extender sus servicios de búsqueda y consulta. Lo habitual es que se defina una interfaz y un formato de intercambio normalizados, y puede haber un organismo que haga de intermediario o pasarela de consultas.
4