SERVICIOS WEB. UNA VISIÓN PRÁCTICA. 13 de noviembre de 2010

Transcripción

1 SERVICIOS WEB. UNA VISIÓN PRÁCTICA 13 de noviembre de

2 Índice de contenidos 1. SOA 1.1. Características 1.2. Beneficios e inconveniente 1.3. Una posible implementación SOA: los servicios web 2. Modelos de referencia 2.1. La arquitectura de referencia SOA 2.2. GPSCM (Generic Public Services Conceptual Model) 2

3 Índice de contenidos 3. El servicio web de estar al corriente de pago de las obligaciones de la Seguridad Social 4. Los servicios web de la Seguridad Social y su adaptación a la plataforma de intermediación 5. El proyecto EESSI (Electronic Exchange of Social Security Information) 3

4 1. SOA Son las siglas de Service Oriented Architecture (Arquitectura Orientada a Servicios) Es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, brindando una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros. 4

5 1.1. Características Es la respuesta a la interoperabilidad Organiza funciones de negocio como servicios interoperables Está basada en estándares Es independiente de los fabricantes Es débilmente acoplada Permite reusabilidad 5

6 1.2. Beneficios e inconveniente Beneficios Mejora en los tiempos de realización de cambios en procesos (time to market y reducción de costes) Facilidad para abordar modelos de negocios basados en colaboración con otros entes Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio Facilidad para la integración de tecnologías disímiles Inconveniente Dependencia de otros servicios web (para mitigar este riesgo se deben establecer acuerdos de nivel de servicio) 6

7 1.3. Una posible implementación SOA: los servicios web 7

8 2. Modelos de referencia La arquitectura de referencia SOA - Fuente: Reference Model for Service Oriented Architecture 1.0 (estándar OASIS) GPSCM (Generic Public Services Conceptual Model) - Fuente: borrador del EIF 2.0 (European Interoperability Framework 2.0) 8

9 2.1. Arquitectura de referencia SOA Presentación, Seguridad y Acceso Directorio de Servicios Monitorización Gestión de Procesos de Negocio Enterprise Service Bus Gobierno Servicios de Aplicación y Datos 9

10 2.1. Arquitectura de referencia SOA Los servicios de aplicaciones y datos son los repositorios de datos y sistemas legados (legacy systems) tales como Host, CRM (Customer Relationship Management) o bases de datos que tienen la información corporativa que se quiere exponer e intercambiar con el exterior. El ESB (que a continuación se ve) ha de tener conectores o una API (Application Programming Interface) que permita conectarlo con una múltiple variedad de sistemas. 10

11 2.1. Arquitectura de referencia SOA Es el auténtico cerebro de la arquitectura. Es una infraestructura y un sistema de eventos que permiten conectar cualquier recurso de TI sin importar la tecnología que utiliza el recurso. Permite administrar los cambios en los requerimientos sin causar problemas a los servicios ya instalados. La función de un ESB es proporcionar una comunicación fiable entre los distintos recursos tecnológicos tales como aplicaciones, plataformas y servicios, que están distribuidos en múltiples sistemas. Además, permite establecer diferentes end-points de ejecución por un mismo servicio web, según quién y cómo se acceda a él. 11

12 2.1. Arquitectura de referencia SOA Funcionalidades: 1) Transparencia de ubicación 2) Conversión de protocolo de transporte 3) Transformación de mensajes 4) Enrutamiento de mensajes 5) Mejora del mensaje 12

13 2.1. Arquitectura de referencia SOA Conocida como BPM (Business Process Management), su funcionalidad es mayor que la de un ESB. Permite alinear la tecnología con los procesos de negocio de la organización, y diseñar éstos a través de su motor de workflow. Además de manejar tareas automatizadas como un ESB también es capaz de integrar actividades humanas. 13

14 2.1. Arquitectura de referencia SOA Ofrece las funcionalidades de registro y repositorio de los servicios. Como registro representa el lugar donde se guardan los metadatos de cada servicio (nombre, descripción, forma de invocarlo, ), y como repositorio es el lugar donde se guardan los servicios y se gestiona su ciclo de vida. Por tanto, es el elemento central para garantizar el principio de la reusabilidad. Es recomendable que siga el estándar UDDI 3.0 (Universal Description, Discover, and Integration). 14

15 2.1. Arquitectura de referencia SOA En el caso de aplicaciones compuestas incrustadas en portales, esta capa se ocupa de ofrecer las funciones de presentación de la información. Pero su principal función es proveer funciones de seguridad y acceso para limitar el acceso a los servicios sólo a los usuarios autorizados. Debe proporcionar al menos autenticación, autorización, y funcionalidad de encriptación para asegurar los mensajes entrantes e igualmente estas funcionalidades se aplican a mensajes salientes para satisfacer requerimientos de seguridad del proveedor del servicio a consumir. 15

16 2.1. Arquitectura de referencia SOA Un ambiente de monitorización es fundamental para que la plataforma sea confiable y tenga un alto rendimiento. Permite al mismo tiempo monitorizar la ejecución de los mensajes y su flujo, y en caso de que haya algún problema alertar sobre éste a los administradores de la plataforma. Hoy en día se suele integrar con herramientas de BAM (Business Activity Monitoring). 16

17 2.1. Arquitectura de referencia SOA Aunque alguna de sus funciones se solapan con las del ESB, la capa de gobierno ha de ser, por ejemplo, capaz de encaminar los mensajes a uno u otro end-point en función de la carga del sistema o del tipo de usuario con el que se esté interaccionando. Pero su principal función es definir y verificar el cumplimiento de los acuerdos de nivel de servicio (SLA ó Service Level Agreement) que se han negociado con los usuarios del sistema. 17

18 2.2. GPSCM 18

19 2.2. GPSCM La capa de las funciones públicas básicas (The Basic Public Functions) -Base registries: representan las fuentes confiables de información (datos de ciudadanos, vehículos, licencias, ) Estos registros se encuentran bajo el control de las Administraciones Públicas y son mantenidas por ellas, y éstas pretenden exponer esta información para reusarla pero con las adecuadas medidas de privacidad y seguridad. Normalmente estos registros de bases están implementados bajo la forma de sistemas legados (legacy systems) y sus repositorios de datos subyacentes que suelen representar una limitación para la reusabilidad. - Interoperability facilitators: proporcionan servicios tales como la traducción entre protocolos, formatos, lenguajes o estándares. - External services: son los servicios ofrecidos por entidades externas como las pasarelas bancarias de los bancos, o los servicios de conectividad proporcionados por los operadores de telecomunicaciones. 19

20 2.2. GPSCM La capa de intercambio seguro de información (The Secure Data Exchange Layer) La información intercambiada tiene un carácter oficial, y por ello debe ir: Firmada y certificada. Tanto emisor como receptor se deben identificar con un certificado digital, y tanto la solicitud de la información como la información devuelta deben ir firmadas electrónicamente para asegurar la integridad (es decir, que la información no haya sido modificada por un tercero). Encriptada. El objeto de este mecanismo es asegurar la confidencialidad de la información intercambiada. Auditoría. Tanto la petición de información como la información devuelta debe ser registrada por si es necesaria una posterior auditoría. Todas estas funciones y otras (como el sellado en el tiempo time-stamping-) son realizadas por el módulo de intercambio seguro de información. El módulo de gestión de las comunicaciones seguras se encarga de verificar que todas las funciones realizadas por el módulo anterior se han llevado a cabo correctamente. 20

21 2.2. GPSCM La capa de agregación de servicios (The Aggregate Services Layer) La agregación o composición de servicios tiene como objeto presentar como un único servicio a los usuarios (administraciones, empresas o ciudadanos) las funciones básicas públicas securizadas de las capas inferiores. Esta agregación se puede lograr de múltiples formas tales como la orquestación de servicios o a través de motores de flujo de trabajo (workflow engines). 21

22 3. El servicio web de estar al corriente de pago de las obligaciones de la Seguridad Social Objeto del servicio: Permitir que otros departamentos ministeriales o entes de la administración puedan obtener información sobre si una determinada persona física o jurídica está al corriente de paso de sus obligaciones con la Seguridad Social. 22

23 3. El servicio web de estar al corriente de pago de las obligaciones de la Seguridad Social Modos de funcionamiento: - Síncrono: permite que los organismos requirentes obtener la respuesta de la Tesorería General de la Seguridad Social (TGSS) de manera on-line, pero para una única persona física o jurídica. - Asíncrono: permite la solicitud del certificado de estar al corriente de pago para varias personas físicas o jurídicas, pero como su nombre indica la información no se obtiene inmediatamente. El sistema almacena las peticiones a la espera de que un proceso batch las trate. Posteriormente el requirente podrá solicitar las respuestas. Si todavía no hubieran sido procesadas, el sistema le informará y le pedirá que lo intente más tarde. 23

24 3. El servicio web de estar al corriente de pago de las obligaciones de la Seguridad Social Funcionamiento - El Organismo Requirente envía a través de la red SARA a la TGSS (Organismo Emisor) un mensaje SOAP de petición previo establecimiento de un canal SSL (con o sin identificación de cliente). El mensaje incluirá en su Cabecera, la firma digital XMLdSig del Cuerpo del mensaje. Dicha firma se realizará con la clave privada del certificado digital del Organismo Requirente. El Cuerpo del mensaje tiene una parte genérica (común a todos los certificados en papel que se sustituyen siguiendo las especificaciones SCSPv2 del Ministerio de Política Territorial y Administración Pública), y una parte específica relativa al certificado de estar al corriente de pago. - Cuando los mensajes SOAP de petición llegan a TGSS, ésta comprueba la validez de la firma, la autorización del Organismo Requirente para acceder al servicio, y que el mensaje SOAP de petición cumple con los esquemas definidos (tanto el genérico como el específico). 24

25 3. El servicio web de estar al corriente de pago de las obligaciones de la Seguridad Social Funcionamiento - Si todas las validaciones son correctas, se iniciará el proceso de emisión del certificado telemático. Si no hay ningún error, se responderá con un mensaje SOAP de respuesta que, al igual que en la petición, incluirá en su Cabecera, la firma digital XMLdSig del Cuerpo del Mensaje. En este caso, la firma se realizará con la clave privada del Organismo Emisor (TGSS). 25

26 3. El servicio web de estar al corriente de pago de las obligaciones de la Seguridad Social Arquitectura del sistema Plataforma de servicios de seguridad Organismo requirente SARA https Firewall XML Herramienta de gobierno Motor de servicios web Servidor de aplicaciones Mainframe Repositorio de servicios web La arquitectura se caracteriza por estar dispuesta en alta disponibilidad y ser escalable. También se dispone de una herramienta de monitorización, pero no de un registro de servicios (uno de los componentes del directorio de servicios) Bases de datos de auditoría y seguimiento 26

27 4. Los servicios web de la Seguridad Social y su adaptación a la plataforma de intermediación Objetivo de la Plataforma de Intermediación (o Servicio de Verificación de Datos): Facilitar a las administraciones el cumplimiento del artículo 6.2.b de la ley 11/2007: A no aportar los datos y documentos que obren en poder de las Administraciones Públicas, las cuales utilizarán medios electrónicos para recabar dicha información siempre que, en el caso de datos de carácter personal, se cuente con el consentimiento de los interesados en los términos establecidos por la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal, o una norma con rango de Ley así lo determine, salvo que existan restricciones conforme a la normativa de aplicación a los datos y documentos recabados. El citado consentimiento podrá emitirse y recabarse por medios electrónicos. 27

28 4. Los servicios web de la Seguridad Social y su adaptación a la plataforma de intermediación Arquitectura (con un único nodo de intermediación) Organismo Requirente Autorizaciones AYTO Organismo Requirente DP Organismo Requirente CCAA SSL SIN Identificación de Cliente Plataforma de Intermediación MPT y AP SSL CON Identificación de Cliente Organismo Emisor AGE Organismo Requirente AGE 28

29 4. Los servicios web de la Seguridad Social y su adaptación a la plataforma de intermediación Implicaciones - Hasta ahora muchos organismos (INE, AEAT, TGSS, DGP, Ministerio de Educación, ) ya estaban cumpliendo con el artículo 6.2 b, pero las peticiones procedían directamente de los organismos requirentes lo que implica un laborioso proceso de gestión para autorizarlos en cada uno de los organismos emisores. Ahora todos los organismos emisores reciben directamente las peticiones de la plataforma de intermediación delegando en ésta toda la cuestión de autorizaciones. -Es necesario adaptar los servicios web ya proporcionados, debido a que los servicios intermediados siguen las especificaciones SCSPv3. Como novedades principales están el uso de WS-Security o XaDES para firmar las respuestas, el posible cifrado de la parte de datos específicos de la respuesta con la clave pública del organismo requirente, la introducción de nuevos campos en la parte de datos genéricos, o como la necesidad de SSL con identificación de cliente entre la plataforma de intermediación y el servicio web del organismo emisor. 29

30 5. El proyecto EESSI (Electronic Exchange of Social Security Information) Antecedentes - El Reglamento 883/2004 del Parlamento Europeo y del Consejo tiene por objeto simplificar y clarificar las normas comunitarias relativas a la coordinación de los sistemas de Seguridad Social de los Estados miembros. - Entró en vigor en Mayo de 2010 y proporciona 24 meses, desde la entrada en vigor del nuevo reglamento, para implantar el Intercambio Electrónico (periodo transitorio desde Mayo 2010 a Mayo 2012) - Establece la obligatoriedad del intercambio electrónico de datos entre las administraciones de los Estados miembros. 30

31 5. El proyecto EESSI (Electronic Exchange of Social Security Information) Objetivo Mejorar la protección de los derechos del ciudadano (sobre todo de los trabajadores migrantes) informatizando la aplicación de la normativa europea de coordinación de la Seguridad Social. Gracias al intercambio informático: - Se facilitarán y agilizarán las decisiones de cálculo y pago de las prestaciones de la Seguridad Social - La comprobación de datos será más eficaz - Habrá una interfaz más cómoda y flexible entre los distintos sistemas - Se ofrecerá una recopilación detallada de datos estadísticos sobre intercambios europeos. De aquí al 1 de mayo de 2012, toda la información que hasta ahora se venía intercambiando mediante un centenar de impresos E casi 2000 impresos en total teniendo en cuenta las distintas lenguas debe procesarse electrónicamente. 31

32 5. El proyecto EESSI (Electronic Exchange of Social Security Information) Características Para cumplir con el objetivo anteriormente descrito, la materia de Seguridad Social se estructura en 6 sectores: enfermedad, pensiones, desempleo, prestaciones familiares, legislación aplicable, y enfermedades profesionales y accidentes de trabajo. Los formularios E se sustituyen por mensajes XML denominados SED (Structured Electronic Document) 32

33 5. El proyecto EESSI (Electronic Exchange of Social Security Information) Arquitectura de alto nivel 33

34 5. El proyecto EESSI (Electronic Exchange of Social Security Information) El nodo de coordinación -Alberga el directorio maestro de instituciones - Coordina y centraliza el intercambio de los SED, así como su almacenamiento - En él se encuentra la monitorización y administración del sistema 34

35 5. El proyecto EESSI (Electronic Exchange of Social Security Information) El punto de acceso - Envía los mensajes entre las CI y el CN - Para ello tiene un software denominado IR (Implementación de referencia). La integración con CN es vía web services, y la integración con las aplicaciones nacionales (que residen en las CI) puede ser vía web services, fichero de texto, JDBC ó JMS entre otras posibilidades. - Mantiene una copia del directorio maestro 35

36 5. El proyecto EESSI (Electronic Exchange of Social Security Information) El aplicativo WebIC (Web Interface for Clerks) -Solución que dota a las Instituciones Competentes (IC), que no tengan aplicativos actuales o no puedan/quieran integrarlos, de los medios para enviar/recibir mensajes -Se puede optar por una arquitectura centralizada con WebIC en el punto de acceso; en local de cada institución competente (gestionaría ella las autorizaciones de sus usuarios); o ciertas instituciones en local con WebIC y otras en local con sus aplicaciones nacionales que se conectan vía adaptador desarrollado ad-hoc (opción mixta presentada en la figura). 36

37 Enlaces de interés Informe de Forrester sobre posicionamiento de los proveedores software en el mundo SOA: The Forrester Wave: Enterprise Service Buses, Q (es necesario registrarse) Plataforma de intermediación II/Panel%20la%20supresi%C3%B3n%20del%20papel%20en%20la%20JA/PLATAFORMA%20DE%20INTERMEDIACION%20Servicios%20de%20Verificaci% C3%B3n%20de%20Datos.pdf Centro de Transferencia de Tecnologías - Sustitución de certificados en soporte papel Sustitución de certificados en soporte papel v3 (SCSPv3) n%20soporte%20papel%20v3.doc EESSI

38 MUCHAS GRACIAS! Y MUCHA SUERTE!