Web services y arquitecturas orientadas al servicio

Pablo Rodríguez ArchillaTelefónica I+D

SOA y los servicios web• Conceptos relacionados, pero no pensemos que SOA

equivale a implementar sistemas usando servicios web:– SOA es un paradigma de arquitectura para sistemas de

información (SSII) que busca el mínimo acoplamiento entre sus componentes y que promueve su reutilización, favoreciendo la identificación de un conjunto de servicios en red y la definición de los procesos por los cuales interactúan

– Los servicios web (WS) son un caso particular de mecanismo estándar para implementar la interacción entre los componentes software, mediante la invocación de métodos remotos

• Los WS suponen una interconexión punto a punto que, por sí sola, no proporciona la capacidad de integración y flexibilidad frente cambios que se necesitan en los SSII de grandes organizaciones

Justificación de SOA• SOA aborda el problema de organizaciones cada vez

más dinámicas pero “inundadas” de sistemas de SSII que son:– Muy diversos– Monolíticos– Cerrados– No interoperables (conectores ad-hoc…)

• El conjunto de técnicas, recomendaciones y tecnologías que denominamos Service-Oriented Architecture (SOA) buscan que los nuevos SSII sean:– Modulares– Basados en componentes– Abiertos– Independientes de la tecnología de implementación

Servicios en red• Con SOA, toda la infraestructura de tecnologías de la

información (TI) presenta sus funcionalidades como servicios que ofrecen un claro valor de negocio

• Los usuarios dentro y fuera de la organización podrán usarlos (modularidad, reutilización...) con independencia de la tecnología del proveedor de los mismos y de la tecnología de sus consumidores

• Así, SOA puede ser una aproximación a la computación distribuida que utiliza recursos software dispersos como servicios disponibles en red

Convergencia en las TICs…• La convergencia facilitada por la banda ancha, la

movilidad y los estándares Internet están produciendo una transformación del negocio de las TICs

Convergencia de la informática y las comunicaciones

Interoperabilidad y agilidad entre empresas y aplicaciones

XML

XMLXML

Ubicación de la informática donde sea más eficiente para el negocio

Eficiencia por proximidad o agrupación y obtención de economías de escala

Convergencia de voz, datos, vídeo y fijo - móvil

Comunicación ágil de información multimedia

IP + Movilidad

+ Banda anchaPuestos de trabajo de

alto rendimiento e incorporación de nuevos dispositivos multimedia

Nuevas formas de trabajo

… hacia un mundo en red• Un mundo interconectado entre los ciudadanos, las

empresas y las administraciones:– Aumentará la eficiencia y agilizará procesos– Permitirá ser más competitivos, eliminando barreras de espacio

y tiempo

Red convergente de banda ancha

Contenidos

Servicios

• La red se convierte en activo clave de esa transformación:– Por su capacidad para poner en

contacto a individuos, negocios, empresas y administraciones

– Su capacidad para proporcionar acceso ubicuo a todo tipo de información, aplicaciones y servicios

Principios de SOA• La arquitectura que nos presenta SOA parte de las

necesidades del negocio o actividad de la organización, para después ir bajando hasta la solución tecnológica

• Para ello se basa en dos principios básicos:

– El negocio dirige los servicios y los servicios dirigen la tecnología (los servicios son una capa de abstracción entre el negocio y la tecnología)

– La agilidad del negocio es un requerimiento fundamental del propio negocio (la habilidad para responder a cambios en los requisitos en un requisito en sí mismo)

Roles implicados en SOA (I)• Distinguimos tres roles fundamentales:

Analista de negocioAnalista de TI / programadorArquitecto SOA

• El analista de negocio conoce el funcionamiento de la organización y sus necesidades de SSII. Su visión de éstos es a muy alto nivel: a partir de un “modelo de servicios” disponibles diseña composiciones y flujos (orquestaciones) entre los mismos para definir los procesos de negocio de la organización, los cuales dependen de los requisitos y sus variaciones

Roles implicados en SOA (II)• El analista de TI desarrolla los SSII. Es quien construye

y mantiene la capa de abstracción entre los servicios y la tecnología subyacente.

• El arquitecto SOA debe entender la relación dinámica entre las necesidades del negocio y los servicios disponibles, así como sus restricciones técnicas.Es el responsable de ese “modelo de servicios” que comparten analistas de negocio y programadores: se sitúa como interlocutor para servir de “puente” entre las visiones tan dispares que unos y otros tienen del negocio

Relación con otras metodologías• Toma prestados conceptos de MDA (Model-Driven

Architecture): modelo independiente de la plataforma (formalización servicios que satisfaga requerimientos de los analista de negocio) a partir del cual se puedan generar modelos dependientes de la plataforma (p.ej. modelo de datos) para la implementación del software

• Respecto a la metodología, SOA propone el empleo de metodologías ágiles (Scrum, XP…) por ser más adecuadas en entornos donde los requerimientos de negocio son desconocidos o cambiantes: el propio funcionamiento del negocio introduce cambios en el “modelo de servicios” que requiere una respuesta rápida por parte de los técnicos de TI

Procesos de negocio (I)• Un proceso es una colección de actividades dirigidas a

lograr un determinado objetivo• Hay muchas organizaciones con funcionamiento interno

basado en procesos, pero con SSII formados por varias aplicaciones centradas sólo en parcelas concretas:– Las aplicaciones no están alineadas con dichos procesos– Además, los procesos evolucionan (nuevas necesidades,

mejoras propuestas por los departamentos de calidad…)• Frente a esto, SOA organiza los SSII alrededor de

servicios, no aplicaciones (arquitectura desacoplada):– Automatiza los procesos en workflows mediante la composición

(orquestación, coreografía, …) de dichos servicios– Puede adaptar mejor los SSII a los procesos y evolucionar con

ellos

Procesos de negocio (II)• La implementación de procesos mediante SOA se apoya

fundamentalmente en 1) la definición de interfaces de servicios que actúan como contratos entre proveedor y consumidores; 2) el desarrollo iterativo con herramientas de apoyo:

– BPA (Business Process Analysis andModeling): análisis y modelado

– BPM (Business Process Management): diseño, desarrollo e implementación

– BAM (Business Activity Monitoring): monitorización

Procesos de negocio: modelado• Hay una notación gráfica estándar para modelar los

procesos: BPMN (Business Process Modeling Notation). Salvando las distancias, sería un UML para analistas de negocio)

Procesos de negocio: representación• Un diagrama de proceso se representa y almacena en

un formato de fichero para facilitar su manipulación con distintas herramientas de modelado

• Los principales formatos estándar son:– BPML (Business Process Modeling Language)– XPDL (XML Process Definition Language)

• En este punto, con la herramienta adecuada podríamos “trabajar” ya con los procesos: compartirlos, extenderlos, simplificarlos, combinarlos… incluso hacer simulaciones con ellos sin ni siquiera tener su implementación aún (muy útil para detectar a tiempo ineficiencias, cuellos de botella, etc.)

Procesos de negocio: implementación• La “implementación” de los procesos exige expresarlos

en un lenguaje de programación (con sus variables, sus operaciones…) que un motor de ejecución interprete:– Típicamente ese lenguaje es BPEL* (Business Process

Execution Language), que concretamente implementa los procesos como una orquestación de servicios

– Está especificado el paso directo BPMN→BPEL, pero hay casos en los que BPEL presenta algunas carencias, especialmente en las tareas de interacción con el usuario

– Los lenguajes de modelado, como XPDL, permiten añadir atributos y construcciones de tiempo de ejecución y no tienen esas carencias, por lo que algunos motores los interpretan directamente como si fueran también lenguajes de ejecución (e incluso está especificado el paso directo BPMN→XPDL)

* Hay multitud de variantes de BPEL: BPEL4WS, WS-BPEL, BPEL4People…

• Es la unidad básica de funcionalidad en la arquitectura SOA. Los elementos de que se compone son:

– Interfaz: contrato entre proveedor y consumidor. Define la forma y el procedimiento para acceder a su funcionalidad

– Lógica de negocio: implementación propiamente dicha– Canal de comunicación: el medio físico y el conjunto de

procedimientos parar poner en contacto (típicamente de forma remota) a los consumidores del servicio con su proveedor

• Un servicio es un conjunto coherente de funcionalidad, autocontenido, sin estado e independiente

Servicios: definición

Servicios: características• Componente software ≠ Servicio• No toda entidad que posea interfaz, lógica y ofrezca una

funcionalidad es un servicio:– Servicios manejan conceptos de negocio (↑ nivel abstracción,↓ granularidad)

– Servicios accesibles por protocolos abiertos e independientes dela implementación

– Servicios están menos acoplados que los componentes– Servicios con mayor grado de autonomía (tienen sentido incluso

de forma aislada)– Servicios tienen sus propias políticas de escalabilidad,

seguridad, tolerancia a fallos, etc.

Servicios: ciclo de vida• Este podría ser el ciclo de vida típico de un servicio:

• Principalmente, tres estándares definidos en la arquitectura SOA intervienen en este ciclo de vida:WSDL, UDDI y SOAP

Estándar WSDL (I)• Web Services Definition Language es un lenguaje XML

para describir los servicios en la arquitectura SOA• A grandes rasgos, permite caracterizar cuatros aspectos

fundamentales de todo servicio:– Conjunto de operaciones públicas que ofrece– Información sobre los tipos de datos empleados– Información sobre los protocolos de comunicación para acceso– Localización física del servicio

• Y todo esto, con el requisito de una total independencia y desacoplamiento entre las partes (lenguajes, sistema operativo, infraestructura de comunicaciones…)

Estándar WSDL (II)

Estándar UDDI (I)• Universal Description, Discovery and Integration define

los mecanismos para publicar (catalogar) servicios en un registro, y para que sus consumidores puedan buscarlos y encontrar su localización física

• La especificación UDDI define tres elementos:– Una especificación técnica para la construcción de un directorio

distribuido de servicios (el objetivo es la máxima reutilización: que sean accesibles para todos, y que todos puedan publicar)

– Un lenguaje XML para el almacenamiento de los datos– Un API estándar (basada en SOAP) para guardar y recuperar

información de los registros UDDI

Estándar UDDI (II)• Tipos de información en un registro UDDI:

– Páginas blancas: información general sobre la organización que publica los servicios (nombre, dirección, etc.)

– Páginas amarillas: información para clasificar la organización y los propios servicios según unos criterios (taxonomías) establecidos y aceptados internacionalmente

– Páginas verdes: información técnica sobre los servicios propiamente dichos (fundamentalmente, su URL y el documento WDSL con su interfaz)

Estándar SOAP (I)• Simple Object Access Protocol es un protocolo de

mensajería para el intercambio de información entre sistemas

• Aunque inicialmente concebido para utilizarlo sobre el protocolo de comunicaciones HTTP (de ahí viene la denominación “servicios web”), admite otros muchos protocolos sin las limitaciones de éste (JMS, SMTP, FTP, MQSeries, MSMQ, …)

• Esto posibilita diferentes paradigmas de comunicación más allá de la cliente-servidor síncrona

• A diferencia de otros estándares de comunicación por mensajes (CORBA, RMI) se basa en documentos XML, por lo que resulta independiente de la tecnología y la plataforma (lenguaje, sistema operativo) subyacente

Estándar SOAP (II)• En el estándar SOAP se identifican tres componentes:

– Especificación del sobre (envelope) SOAP y las reglas para encapsular la información intercambiada

– Las reglas para la codificación de los datos (típicamente se utilizan esquemas XSD)

– Las convenciones de RPC, que definen la forma de declarar el mecanismo de invocación remota (unidireccional, petición y respuesta, etc.)

Pila de estándares en SOA

Arquitectura de referencia (I)• Esta puede ser una arquitectura típica basada en SOA,

organizada en varios niveles:

Arquitectura de referencia (II)• Nivel de presentación:

– Punto de acceso único del usuario a las aplicaciones– Capa que hace de “portal” y recoge los aspectos de integración

de contenidos y pantallas, adaptación al canal, personalización del usuario y distribución de presentación

– Incluye: herramientas de gestión de contenidos y entornos de desarrollo de formularios, pantallas, etc. (modelo MVC)

• Nivel de procesos:– Formado por las herramientas para definir, gestionar y ejecutar

los procesos de negocio de la organización– Se apoya en el nivel inferior (servicios) para definir los flujos de

invocación a los mismos que implementan los procesos

Arquitectura de referencia (III)• Nivel de servicios:

– Es la capa donde reside la lógica de las aplicaciones y de los servicios que éstas ofrecen

– En este nivel se engloban las herramientas de desarrollo de dicha lógica

• Nivel de integración:– Canaliza las comunicaciones entre los servicios y con otras

aplicaciones “legacy” (p.ej. SAP, CRM…)– Típicamente esta función la desempeña un bus de mensajes

denominado ESB (Enterprise Service Bus)

Arquitectura de referencia (IV)• Nivel de seguridad:

– Capa transversal donde se define un esquema de autorización de ejecución de cada servicio, así como del acceso a la información

– Será responsable de validar en tiempo de ejecución los permisos de acceso, y de gestionar perfiles e identidades

• Nivel de gobernabilidad:– Monitoriza en tiempo real el uso de las infraestructuras, el uso

de los servicios y su estado de disponibilidad– Responsable de la monitorización de actividades de negocio

(BAM), con métricas sobre la ejecución de los procesos– Gestiona el ciclo de vida (versionado) de servicios y procesos,

las dependencias entre ellos y su despliegue en distintos entornos

Productos comerciales• Típicamente encontraremos “suites” que agrupan una

multitud de herramientas que, conjuntamente, cubren los distintos niveles de una arquitectura SOA

• La tecnología predominante en todas ellas es J2EE, por lo que la mayoría de esas suites tiene un servidor de aplicaciones como componente central

• Algunos ejemplos:– Oracle SOA Suite– IBM WebSphere Process Server– Jboss Enterprise Middleware– …

Ventajas de una arquitectura SOA• La adopción de la filosofía SOA en una organización

trae consigo una serie de beneficios, entre lo cuales se pueden mencionar:– Reducción del time-to-market y de los costes de desarrollo– Mayor agilidad, al simplificarse la adaptación de los SSII frente a

las nuevas necesidades que surjan– Mayor interoperabilidad de los distintos sistemas existentes

(legacy)– Reducción de los costes de integración, consecuencia del punto

anterior– Mejor alineación tecnología-negocio– Disminución de las ataduras tecnológicas (plataformas,

suministradores, etc.)

Críticas sobre SOA• La arquitectura SOA no está exenta de problemas:

– Mensajería: tiempos de invocación de los servicios, problemas en la red (propio de los sistemas distribuidos), …

– Uso extensivo de XML (ineficiente para gran volumen de datos)– Riesgo de llegar a una “explosión de servicios”: el desarrollo de

una batería inmanejable de servicios que se invocan unos a otros

– La integración resulta no ser tan simple (ver la pila de protocolos WS-* o echar un vistazo a un documento WSDL)

– Mal entendida, puede acabar siendo lo que se conoce por “YARPC” (Yet Another RPC), como tecnologías precedentes: COM, CORBA, RMI…

– Quizá se deja de lado al usuario final. Los servicios son algo más que invocaciones RPC: deben hacer algo útil que ofrezca un beneficio al usuario

Algunas referencias

– Etham Cerami. Web Services Essentials. O‘Reilly & associates– David A. Chappel, Tyler Jewel. Java Web Services. O‘Reilly &

associates– Eric Newcomer. Understanding Web Services: XML, WSDL,

SOAP and UDDI. Addison-Wesley– Dirk Krafzig, Karl Banke, Dirk Slama. Enterprise SOA: Service-

Oriented Architecture Best Practices, Prentice Hall