Web services y arquitecturas orientadas al servicio

Pablo Rodrguez Archilla Telefnica 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 informacin (SSII) que busca el mnimo acoplamiento entre sus componentes y que promueve su reutilizacin, favoreciendo la identificacin de un conjunto de servicios en red y la definicin de los procesos por los cuales interactan Los servicios web (WS) son un caso particular de mecanismo estndar para implementar la interaccin entre los componentes software, mediante la invocacin de mtodos remotos

Los WS suponen una interconexin punto a punto que, por s sola, no proporciona la capacidad de integracin y flexibilidad frente cambios que se necesitan en los SSII de grandes organizaciones

Justificacin de SOA
SOA aborda el problema de organizaciones cada vez ms dinmicas pero inundadas de sistemas de SSII que son:
Muy diversos Monolticos Cerrados No interoperables (conectores ad-hoc)

El conjunto de tcnicas, recomendaciones y tecnologas que denominamos Service-Oriented Architecture (SOA) buscan que los nuevos SSII sean:
Modulares Basados en componentes Abiertos Independientes de la tecnologa de implementacin

Servicios en red
Con SOA, toda la infraestructura de tecnologas de la informacin (TI) presenta sus funcionalidades como servicios que ofrecen un claro valor de negocio Los usuarios dentro y fuera de la organizacin podrn usarlos (modularidad, reutilizacin...) con independencia de la tecnologa del proveedor de los mismos y de la tecnologa de sus consumidores As, SOA puede ser una aproximacin a la computacin 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 estndares Internet estn produciendo una transformacin del negocio de las TICs

Convergencia de voz, datos, vdeo y fijo - mvil Comunicacin gil de informacin multimedia
XML

XML

Puestos de trabajo de alto rendimiento e incorporacin de nuevos dispositivos multimedia Nuevas formas de trabajo

IP + Movilidad + Banda ancha

XML

Convergencia de la informtica y las comunicaciones Interoperabilidad y agilidad entre empresas y aplicaciones

Ubicacin de la informtica donde sea ms eficiente para el negocio Eficiencia por proximidad o agrupacin y obtencin de economas de escala

 hacia un mundo en red

Un mundo interconectado entre los ciudadanos, las empresas y las administraciones:
Aumentar la eficiencia y agilizar procesos Permitir ser ms competitivos, eliminando barreras de espacio y tiempo

La red se convierte en activo clave de esa transformacin:

Servicios

Red convergente de banda ancha Contenidos

Por su capacidad para poner en contacto a individuos, negocios, empresas y administraciones Su capacidad para proporcionar acceso ubicuo a todo tipo de informacin, aplicaciones y servicios

Principios de SOA
La arquitectura que nos presenta SOA parte de las necesidades del negocio o actividad de la organizacin, para despus ir bajando hasta la solucin tecnolgica Para ello se basa en dos principios bsicos:
El negocio dirige los servicios y los servicios dirigen la tecnologa (los servicios son una capa de abstraccin entre el negocio y la tecnologa) 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 negocio Analista de TI / programador Arquitecto SOA

El analista de negocio conoce el funcionamiento de la organizacin y sus necesidades de SSII. Su visin de stos es a muy alto nivel: a partir de un modelo de servicios disponibles disea composiciones y flujos (orquestaciones) entre los mismos para definir los procesos de negocio de la organizacin, 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 abstraccin entre los servicios y la tecnologa subyacente. El arquitecto SOA debe entender la relacin dinmica entre las necesidades del negocio y los servicios disponibles, as como sus restricciones tcnicas. Es el responsable de ese modelo de servicios que comparten analistas de negocio y programadores: se sita como interlocutor para servir de puente entre las visiones tan dispares que unos y otros tienen del negocio

Relacin con otras metodologas

Toma prestados conceptos de MDA (Model-Driven Architecture): modelo independiente de la plataforma (formalizacin 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 implementacin del software Respecto a la metodologa, SOA propone el empleo de metodologas giles (Scrum, XP) por ser ms 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 rpida por parte de los tcnicos de TI

Procesos de negocio (I)

Un proceso es una coleccin 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 slo en parcelas concretas:
Las aplicaciones no estn alineadas con dichos procesos Adems, 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 composicin (orquestacin, coreografa, ) de dichos servicios Puede adaptar mejor los SSII a los procesos y evolucionar con ellos

Procesos de negocio (II)

La implementacin de procesos mediante SOA se apoya fundamentalmente en 1) la definicin de interfaces de servicios que actan como contratos entre proveedor y consumidores; 2) el desarrollo iterativo con herramientas de apoyo:
BPA (Business Process Analysis and Modeling): anlisis y modelado BPM (Business Process Management): diseo, desarrollo e implementacin BAM (Business Activity Monitoring): monitorizacin

Procesos de negocio: modelado

Hay una notacin grfica estndar para modelar los procesos: BPMN (Business Process Modeling Notation). Salvando las distancias, sera un UML para analistas de negocio)

Procesos de negocio: representacin

Un diagrama de proceso se representa y almacena en un formato de fichero para facilitar su manipulacin con distintas herramientas de modelado Los principales formatos estndar son:
BPML (Business Process Modeling Language) XPDL (XML Process Definition Language)

En este punto, con la herramienta adecuada podramos trabajar ya con los procesos: compartirlos, extenderlos, simplificarlos, combinarlos incluso hacer simulaciones con ellos sin ni siquiera tener su implementacin an (muy til para detectar a tiempo ineficiencias, cuellos de botella, etc.)

Procesos de negocio: implementacin

La implementacin de los procesos exige expresarlos en un lenguaje de programacin (con sus variables, sus operaciones) que un motor de ejecucin interprete:
Tpicamente ese lenguaje es BPEL* (Business Process Execution Language), que concretamente implementa los procesos como una orquestacin de servicios Est especificado el paso directo BPMNBPEL, pero hay casos en los que BPEL presenta algunas carencias, especialmente en las tareas de interaccin con el usuario Los lenguajes de modelado, como XPDL, permiten aadir atributos y construcciones de tiempo de ejecucin y no tienen esas carencias, por lo que algunos motores los interpretan directamente como si fueran tambin lenguajes de ejecucin (e incluso est especificado el paso directo BPMNXPDL)
* Hay multitud de variantes de BPEL: BPEL4WS, WS-BPEL, BPEL4People

Servicios: definicin
Es la unidad bsica 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 Lgica de negocio: implementacin propiamente dicha Canal de comunicacin: el medio fsico y el conjunto de procedimientos parar poner en contacto (tpicamente 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: caractersticas
Componente software Servicio No toda entidad que posea interfaz, lgica y ofrezca una funcionalidad es un servicio:
Servicios manejan conceptos de negocio ( nivel abstraccin, granularidad) Servicios accesibles por protocolos abiertos e independientes de la implementacin Servicios estn menos acoplados que los componentes Servicios con mayor grado de autonoma (tienen sentido incluso de forma aislada) Servicios tienen sus propias polticas de escalabilidad, seguridad, tolerancia a fallos, etc.

Servicios: ciclo de vida

Este podra ser el ciclo de vida tpico de un servicio:

Principalmente, tres estndares definidos en la arquitectura SOA intervienen en este ciclo de vida: WSDL, UDDI y SOAP

Estndar 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 pblicas que ofrece Informacin sobre los tipos de datos empleados Informacin sobre los protocolos de comunicacin para acceso Localizacin fsica del servicio

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

Estndar WSDL (II)

Estndar 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 localizacin fsica La especificacin UDDI define tres elementos:
Una especificacin tcnica para la construccin de un directorio distribuido de servicios (el objetivo es la mxima reutilizacin: que sean accesibles para todos, y que todos puedan publicar) Un lenguaje XML para el almacenamiento de los datos Un API estndar (basada en SOAP) para guardar y recuperar informacin de los registros UDDI

Estndar UDDI (II)

Tipos de informacin en un registro UDDI:
Pginas blancas: informacin general sobre la organizacin que publica los servicios (nombre, direccin, etc.) Pginas amarillas: informacin para clasificar la organizacin y los propios servicios segn unos criterios (taxonomas) establecidos y aceptados internacionalmente Pginas verdes: informacin tcnica sobre los servicios propiamente dichos (fundamentalmente, su URL y el documento WDSL con su interfaz)

Estndar SOAP (I)

Simple Object Access Protocol es un protocolo de mensajera para el intercambio de informacin entre sistemas Aunque inicialmente concebido para utilizarlo sobre el protocolo de comunicaciones HTTP (de ah viene la denominacin servicios web), admite otros muchos protocolos sin las limitaciones de ste (JMS, SMTP, FTP, MQSeries, MSMQ, ) Esto posibilita diferentes paradigmas de comunicacin ms all de la cliente-servidor sncrona A diferencia de otros estndares de comunicacin por mensajes (CORBA, RMI) se basa en documentos XML, por lo que resulta independiente de la tecnologa y la plataforma (lenguaje, sistema operativo) subyacente

Estndar SOAP (II)

En el estndar SOAP se identifican tres componentes:
Especificacin del sobre (envelope) SOAP y las reglas para encapsular la informacin intercambiada

Las reglas para la codificacin de los datos (tpicamente se utilizan esquemas XSD) Las convenciones de RPC, que definen la forma de declarar el mecanismo de invocacin remota (unidireccional, peticin y respuesta, etc.)

Pila de estndares en SOA

Arquitectura de referencia (I)

Esta puede ser una arquitectura tpica basada en SOA, organizada en varios niveles:

Arquitectura de referencia (II)

Nivel de presentacin:
Punto de acceso nico del usuario a las aplicaciones Capa que hace de portal y recoge los aspectos de integracin de contenidos y pantallas, adaptacin al canal, personalizacin del usuario y distribucin de presentacin Incluye: herramientas de gestin 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 organizacin Se apoya en el nivel inferior (servicios) para definir los flujos de invocacin a los mismos que implementan los procesos

Arquitectura de referencia (III)

Nivel de servicios:
Es la capa donde reside la lgica de las aplicaciones y de los servicios que stas ofrecen En este nivel se engloban las herramientas de desarrollo de dicha lgica

Nivel de integracin:
Canaliza las comunicaciones entre los servicios y con otras aplicaciones legacy (p.ej. SAP, CRM) Tpicamente esta funcin la desempea un bus de mensajes denominado ESB (Enterprise Service Bus)

Arquitectura de referencia (IV)

Nivel de seguridad:
Capa transversal donde se define un esquema de autorizacin de ejecucin de cada servicio, as como del acceso a la informacin Ser responsable de validar en tiempo de ejecucin 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 monitorizacin de actividades de negocio (BAM), con mtricas sobre la ejecucin 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
Tpicamente encontraremos suites que agrupan una multitud de herramientas que, conjuntamente, cubren los distintos niveles de una arquitectura SOA La tecnologa predominante en todas ellas es J2EE, por lo que la mayora 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 adopcin de la filosofa SOA en una organizacin trae consigo una serie de beneficios, entre lo cuales se pueden mencionar:
Reduccin del time-to-market y de los costes de desarrollo Mayor agilidad, al simplificarse la adaptacin de los SSII frente a las nuevas necesidades que surjan Mayor interoperabilidad de los distintos sistemas existentes (legacy) Reduccin de los costes de integracin, consecuencia del punto anterior Mejor alineacin tecnologa-negocio Disminucin de las ataduras tecnolgicas (plataformas, suministradores, etc.)

Crticas sobre SOA

La arquitectura SOA no est exenta de problemas:
Mensajera: tiempos de invocacin 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 explosin de servicios: el desarrollo de una batera inmanejable de servicios que se invocan unos a otros La integracin 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 tecnologas precedentes: COM, CORBA, RMI Quiz se deja de lado al usuario final. Los servicios son algo ms que invocaciones RPC: deben hacer algo til que ofrezca un beneficio al usuario

Algunas referencias
Etham Cerami. Web Services Essentials. OReilly & associates David A. Chappel, Tyler Jewel. Java Web Services. OReilly & associates Eric Newcomer. Understanding Web Services: XML, WSDL, SOAP and UDDI. Addison-Wesley Dirk Krafzig, Karl Banke, Dirk Slama. Enterprise SOA: ServiceOriented Architecture Best Practices, Prentice Hall