SOA Resumen de lo más importante sobre las arquitecturas orientadas a servicios.

El paradigma SOA es muy general y de carácter muy abstracto, sin que establezca una tecnología específica de imple-mentación del mismo.

Una de las tecnologías más destacadas y que con más éxito está llevando a la práctica el paradigma conceptual de SOA son los Web Services.

Arquitectura de servicios web

Para el caso de un Servicio Web (Web Service), el organismo W3C, nos facilita una definición más específica:



“Un servicio web es un sistema software diseñado para soportar la interacción máquina-a-máquina a través de una red y de forma interoperable”



Un servicio web cuenta con una interfaz descrita en un formato procesable por un equipo informático (específicamente en WSDL), a través de la que es posible interactuar con el mismo mediante el intercambio de mensajes SOAP, típicamente transmitidos usando serialización XML sobre HTTP conjuntamente con otros estándares web.

Para conocer el formato, el solicitante consulta a un intermediador, un registro de servicios, donde los proveedores de servicios web publican sus formatos y a los solicitantes se les ofrece un servicio de consulta similar a unas “páginas amarillas”.

W3C ha trabajado en la definición de una arquitectura conceptual de servicios web (http://www.w3.org/TR/ws-arch/) que proporciona un modelo conceptual y un contexto para entender qué se esconde detrás del concepto de Web Service.

Define modelos con-ceptuales que ilustran las principales dimensiones a considerar (mensajería, recursos, servicios y políticas) y conforma los principales aspectos a considerar a la hora de utilizar Web Services (interoperabilidad, fiabilidad, integración, seguridad, transaccionalidad, extensibilidad, gestión y provisión).

Web Services como alternativa para implementar arquitecturas SOA

Los Web Services/Servicios Web NO son SOA.

La diferencia entre ambos términos es conceptual: mientras que SOA define el qué, los Servicios Web definen el cómo. O dicho de otro modo, al igual que es posible aplicar el paradigma de orientación a objetos con Java o C++, el paradigma de orientación a servicios no es exclusivo de los servicios web.



El paradigma de diseño establecido por la “orientación a servicios” pretende ser agnóstico respecto a la implementación.



El concepto de “servicio” en SOA se basa en que los servicios desarrollados son “Servicios de Negocio”, sean desarrollados mediante una tecnología como “servicios web” o bien en otras tecnologías disponibles para ello. En una arquitectura SOA, el foco de interés se pone en el modelado de procesos a partir de piezas reutilizables que configu-ran servicios de negocio, abstrayéndose de la tecnología y forma en la que esos servicios son implementados.



Uno de los principios de SOA vistos anteriormente es la reusabilidad, ¿cómo se logra si no se utilizan servicios web? Se logra no por la posibilidad de reutilizar los componentes software que implementan dichos servicios sino en la medida en que los Servicios de Negocio son involucrados en nuevos y más procesos.



Lo anterior indica que todo nuevo servicio de negocio desarrollado, debe ser puesto a disposición y en conocimiento de las áreas de diseño de procesos. Puesto que el servicio de negocio esta definido en términos del negocio y no de tecno-logía, es fácil hacer referencia e incorporarlo a sus diseños para las áreas de negocio.

Aclarada la diferencia entre los servicios web y las arquitecturas SOA, no obstante hay que dejar claro que los servicios web, por sus especiales características de interoperabilidad, reutilización, modularidad, etc., se ajustan perfectamente a las necesidades y principios de las arquitecturas SOA, lo que, añadido a la universalización de los web services, implementados por la mayoría de empresas de software para un enorme espectro de plataformas y sistemas operativos, lo han convertido en la aproximación más extendida de implementar arquitecturas SOA.

Estándares y protocolos de Web Services en las arquitecturas SOA

Según la definición de Arquitectura de Web Services del W3C (http://www.w3.org/TR/ws-arch/), la lista de estándares y protocolos básicos es la que se muestra en la siguiente figura.

 XML (eXtensible Markup Language), estándar de W3C (http://www.w3.org/xml/) actualmente en su versión 1.1, es un lenguaje de marcado que permite describir información o contenido de forma completamente sepa-rada de su presentación o formato. Junto a él, hay un amplio conjunto de estándares para la definición de len-guajes y validación de documentos (DTD, XSD) y para la transformación y presentación de los mismos (XSL-FO, XSLT).



 SOAP (Simple Object Access Protocol), estándar del W3C (http://www.w3.org/TR/soap/) actualmente en su versión 1.2, que define una gramática XML que describe el formato de los documentos XML a intercambiar entre el solicitante y el proveedor del servicio, en concreto, el formato en el que se “ensobran” las peticiones y res-puestas entre solicitante y proveedor.



 WSDL (Web Services Description Language), actualmente en su versión 2.0 y también estándar del W3C (), que define una gramática XML que permite describir la interfaz de un servicio web, es decir, las funciones y parámetros de entrada y salida necesarios para la invocación de los servicios.



 UDDI (Universal Description Discovery and Integration), en su versión 3.0 y perteneciente a OASIS (http://www.uddi.org), que configura un servicio de registro o servicio de directorio donde llos proveedores de servicios publican sus servicios web y los solicitantes de servicios buscan y encuentran los servicios web acordes a sus necesidades, de forma parecida a como funciona un servicio de “páginas amarillas”.



Junto a los anteriores estándares básicos, es interesante considerar el papel de los perfiles de WS-Interoperability (WS-I), cuyo propósito es promover la interoperabilidad de los servicios web entre plataformas, sistemas operativos y lenguajes de programación.



La organización WS-I centra su labor en la integración de especificaciones, proporcionar aplicaciones de ejemplo, guías y mejores prácticas recomendadas así como recursos de apoyo y herramientas, trabajo cuyos resultados organiza en torno al concepto de “perfiles”. Actualmente se encuentran a disposición los siguientes perfiles:



 WS-I Basic Profile, convenciones sobre mensajería, descripción, descubrimiento y seguridad en los servicios web, introduciendo restricciones y aclaraciones y guías de utilización conjunta de los estándares SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, XML Schema y HTTP 1.1.

 WS-I Basic Security Profile (BSP), extensión del Basic Profile que cubre la interoperabilidad en términos de seguridad, en la capa de transporte (HTTP sobre TLS), seguridad en la mensajería SOAP y estándar WS-Security.



 WS-I Reliable Secure Profile, relacionado con la interoperabilidad de las especificaciones WS-Reliable Mes-saging, WS-Reliable Exchange y WS-Secure Conversation.

Innumerables estándares vinculados a los web services, siempre en continuo crecimiento:

Considerando los estándares y protocolos anteriores, una arquitectura SOA conformada mediante Servicios Web contará con el siguiente aspecto.

La elección entre las diferentes alternativas tecnológicas a los mismos así como la posible utilización de otros estándares, será objeto de la definición de la arquitectura de referencia de nuestra implementación de arquitectura SOA.

 

Definición de Servicio

“Un recurso que representa una capacidad de realizar tareas y una funcionalidad coherente desde el pun-to de vista de las entidades proveedoras y solicitantes del mismo”



En términos más informáticos, podemos decir que existe una lógica, una pieza de software, que hace algo de utilidad y que es invocada por otra pieza de software que se constituye en el consumidor.

Para dicha invocación, debe existir un mecanismo o tecnología de invocación y un contrato que defina el proceso, tal y como representamos en la siguiente figura.

En general, además, se aportan unos datos de entrada y la lógica devuelve algún tipo de resultado al consumidor y, normalmente, unos datos de salida. Estos datos de entrada y salida se adhieren a un modelo de información, ya sea implícito o explícito, que define una sintaxis y semántica comprensible tanto por el consumidor como por la lógica invo-cada.

Pues bien, la unidad mínima de lógica invocable y que hace algo útil es lo que denominaremos operación. En general, en una cierta área de trabajo, existen una serie de operaciones que forman un conjunto coherente y autocontenido.Esas agrupaciones coherentes es lo que denominaremos servicio.

Un servicio es:

“Conjunto coherente de funcionalidad, constituido por una o más operaciones, autocontenido e indepen-diente, que acepta llamadas y devuelve respuestas mediante un contrato definido de forma inequívoca”.

Un servicio en el marco de una arquitectura SOA, es:

“Una funcionalidad empaquetada como un componente reutilizable para su utilización en un proceso de negocio”



Su propósito es proporcionar información o facilitar el cambio de una información de negocio de un estado coherente a otro. Lo importante para el modelo SOA no es la tecnología usada para implementar el servicio, sino que responda a las peticiones que se le realizan y ofrezca la calidad del servicio necesaria según el contrato que ofrece.



Sin embargo, la implementación del servicio puede en realidad conllevar diferentes pasos ejecutados en diferentes equipos, y ser en sí mismo un proceso de negocio.

Un servicio puede o puede no ser un componente en el sentido software de encapsulación de funcionalidad.

Concepto de orientación a servicios

La orientación a servicios ha emergido como paradigma de diseño que fomenta la creación de lógica de negocio y de lógica de operación en forma de servicios.

La orientación a servicios ofrece un modo de conseguir la llamada “separación de conceptos” (separation of concerns), mediante la que problemas de gran tamaño se descomponen en una serie de problemas individualmente identificables que son llamados “conceptos”.

La orientación a servicios le debe su existencia a la orientación a objetos.

Las arquitecturas SOA están basadas en un modelo en el que la lógica de la solución se encuentra distribuida, y por tanto, como ocurre con la orientación a objetos, conceptos como la encapsulación, abstracción, y reutilización son fundamentales para el diseño de unidades de lógica distribuida.

De esta forma, podemos decir que el paradigma de la orientación a servicios es una evolución de anteriores aproximaciones, aumentado y extendido para soportar las características y objetivos perseguidos con las arquitecturas SOA.

El modesto ámbito inicial de la orientación a servicios, con un conjunto de principios en torno a un modelo de arquitectu-ra enfocado en distinguir servicios como recursos reutilizables, ha cambiado por el efecto del impulso tecnológico y la tendencia a la automatización de los procesos de negocio, y extendiéndose a nivel de toda la organización como solución de interoperabilidad y como herramienta para la independencia de proveedores.

Análisis, diseño y desarrollo orientado a servicios

La metodología de modelado para aplicaciones SOA se conoce como análisis y diseño orientado a servicios, y esta-blece tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implantación.

Para que un proyecto SOA tenga éxito, los desarrolladores de software deben orientarse ellos mismos a la mentalidad de crear servicios comunes que son orquestados a través de un middleware para implementar los procesos de negocio.



La implementación ideal de un servicio exige resolver algunos incon-venientes técnicos inherentes a su modelo:

o Los tiempos de invocación no son despreciables, debido a los retardos de la comunicación en red, tamaño de los mensajes, etc. Esto necesariamente implica la utilización de mensajería confiable.



o La respuesta del servicio está afectada directamente por aspectos externos como problemas en la red, configu-ración, etc. Estos deben ser tenidos en cuenta en el diseño, desarrollándose los mecanismos de contingencia que eviten la parálisis de las aplicaciones y servicios que dependen de él.



o Comunicaciones no confiables, mensajes impredecibles, reintentos, mensajes fuera de secuencia, etc.

A su vez, cuando se usan múltiples servicios para implementar un sistema, la comunicación entre estos dificulta el con-trol.

En un sistema grande, si no se cuenta con una estrategia adecuada, se puede llegar a una implementación donde exista una explosión de dependencias entre los diferentes servicios.

Será, por tanto, una decisión de diseño la elección de cubrir la lógica de un proceso de negocio mediante varios servicios de grano fino interrelacionados entre sí o mediante un servicio que centralice la definición de todo el proceso.

La relación entre lógica de procesos de negocio y servicios ha potenciado la sinergia entre la Gestión de Procesos de Negocio (BPM) y las arquitecturas SOA.

Centrándonos en el proceso de diseño y desarrollo orientado a servicios destacan los siguientes pasos fundamentales:

 Identificación de Servicios

1. Enfoque top-down

En el enfoque top-down, un diagrama de los casos de uso de negocio proporciona la especificación para definir los servicios de negocio. De esta forma, se abstraen las áreas funcionales y subsistemas presentes en el dominio de negocio, pudiendo bajar de nivel hasta alcanzar la descomposición en flu-jos, procesos, subprocesos, etc.

Los casos de uso a menudo son magníficos candidatos para los servicios de negocio que se ex-pondrán en la plataforma SOA para la organización.



2. Enfoque bottom-up

En el enfoque bottom-up, los sistemas y aplicaciones preexistentes de la organización son analizados, y como resultado del análisis, aquellos que sean considerados candidatos viables para proporcionar la implementación de la funcionalidad de los servicios que compondrán el proceso de negocio, son se-leccionados.

En este proceso, las aplicaciones empaquetadas y heredadas tienden a verse como un todo, aunque en ocasiones es necesario remodularizarlas para ofrecer la funcionalidad de servicio necesaria.



3. Enfoque middle-out

Finalmente, el enfoque middle-out consiste en modelar y definir aquellos servicios no identificados mediante los dos enfoques anteriores

 Clasificación o categorización de servicios

Cada servicio tiene diferentes usos y propósitos, de forma que podemos distinguir entre servicios básicos de ne-gocio, servicios de infraestructura software, servicios sectoriales de negocio, etc.

A partir de ellos, considerados como servicios atómicos, es posible componer y orquestar otros servicios de más alto nivel, de forma que algunos servicios se componen de servicios y componentes de grano más fino.

 Análisis de subsistemas

Dentro de la primera fase de identificación de servicios, se alcanza una descomposición en subsistemas al aplicar el enfoque top-down.

El análisis de subsistemas consiste en crear modelos de objetos para representar el funciona-miento interno de los subsistemas y el diseño de los servicios que se exponen que llevarán a efecto dicho fun-cionamiento.

 Especificación de componentes

En esta actividad se especifican los componentes que implementan los servicios y sus detalles:

o Información

o Reglas de negocio

o Servicios que implementa

o Perfil configurable

Las especificaciones sobre los eventos y el intercambio de mensajes y la gestión de los componentes también se realizan en esta fase.

 Asignación de servicios

La asignación de servicios consiste en vincular los servicios a los subsistemas previamente identificados, vincu-lando los servicios y componentes que los implementan.

 Implementación del servicio

Finalmente, esta fase reconoce que el software que implementa un servicio dado deberá ser seleccionado o bien construido a medida. Las opciones de implementación de un servicio incluyen la integración, transformación o suscripción de funcionalidades implementadas bajo diferentes tecnologías, paradigmas y/o sistemas

Se toma la decisión de qué sistema heredado será utilizado para dar un servicio dado, qué servicios serán implementados “desde cero”, qué aspectos de seguridad deberán tenerse en cuenta, etc.

Se aprovechan de nuevo aquí los esfuerzos realizados en la primera fase de identificación de servicios, sacando provecho de las descomposiciones top-down y bottom-up realizadas, de forma que se alinean los servicios con su funcionalidad de negocio.

Definición

Por la propia traducción del término anglosajón SOA:

“Un paradigma de arquitectura software que cuenta con la orientación a servicios como su principio fun-damental de diseño”

El elemento a destacar es la característica de “orientación a servicios” que es la que conforma una arquitectura que utiliza servicios débilmente acoplados para cubrir los requisitos de procesos de negocio y requisitos de usuario.

SOA significa diferentes cosas para diferentes personas, según el perfil profesional que se esté ejerciendo en el contexto de una organización.

Así, para un arquitecto de desarrollo de proyectos TIC, SOA significa la definición de la arquitectura corporativa
los procesos que permiten a los Sistemas de Información desarrollar y desplegar funcionalidades de negocio rápidamente.

Para los responsables de la explotación de los Sistemas de Información de una línea de actividad, SOA aporta la gober-nabilidad, la organización y el proceso para la gestión de aplicaciones así como “bloques de negocio constitu-yentes”, para su reutilización en otros proyectos con el fin de reducir costes.

A otro nivel de carácter más estratégico, las arquitecturas SOA se han convertido en una estrategia de negocio para mejorar los flujos de información y alcanzar los objetivos de la organización, en términos de incremento de los ingresos, mejorar la satisfacción del cliente, mejora la calidad de los productos, potenciar la agilidad, etc.

La relación entre los flujos de negocio y las arquitecturas SOA es uno de los aspectos que más están influyendo en su aceptación, y que veremos más adelante al comentar la relación entre BPM y SOA.

Principios de SOA

Los siguientes principios guía definen las reglas básicas para el desarrollo, mantenimiento y uso de las arquitecturas SOA:

 Reutilización

 Interoperabilidad

 Granularidad

 Modularidad

 Composición

 Componentización

 Conformidad con estándares (tanto de ámbito común como específicos de la industria).

 Identificación de servicios, categorización, provisión y entrega, y monitorización y traza.

Los siguientes principios arquitectónicos de diseño se derivan de la definición y diseño de servicios, y son intrínse-camente aplicables a las arquitecturas SOA por su carácter de “orientación a servicios”:

 Encapsulación: los servicios ocultan el código y la forma en la que implementan las funcionalidades que ofrecen hacia fuera, exponiendo una interfaz con dicha funcionalidad accesible.

 Débil acoplamiento: los servicios mantienen una relación entre sí que minimiza las dependencias entre ambos.

 Contrato: los servicios se adscriben a un acuerdo de comunicaciones, definido colectivamente por uno o más documentos de descripción del servicio.

 Abstracción: al margen de lo descrito en el contrato de servicio, los servicios ocultan la lógica al exterior.

 Reutilización: la lógica se divide en servicios con la intención de promover la reutilización.

 Composición: un conjunto de servicios puede ensamblarse y coordinarse para conformar servicios compuestos.

 Autonomía: los servicios tienen control sobre la lógica que encapsulan

 Optimización: en igualdad de circunstancias, los servicios de mayor calidad se consideran preferibles sobre los de baja calidad.

 Descubrimiento: los servicios se diseñan para ser descriptivos “hacia afuera” de forma que puedan ser localizados y accedidos a través de mecanismos de descubrimiento.

Finalmente, a la hora de considerar la implementación de una arquitectura SOA, deberán tenerse en cuenta los siguientes aspectos:

 Arquitectura de referencia SOA, que proporcione diagramas detallados de la arquitectura, requisitos detallados, patrones de diseño, opciones tecnológicas y opiniones sobre los estándares utilizados, etc.

 Gestión del Ciclo de Vida en SOA, que describe el ciclo de vida completo de los servicios y proporciona un proceso detallado de gestión de los mismos desde su creación a su retirada/eliminación o su reposición por nuevas versiones.

 Grado y Modelo de Madurez, cuyo objetivo es acelerar la adopción y disminuir el riesgo de implantar arquitecturas SOA en una empresa u organización, modelando para ello el nivel de madurez de la arquitectura de Tecnologías de la Información de la empresa u organización.

Beneficios de SOA

En el contexto empresarial, el cambio es esencial para adaptarse a factores internos como adquisiciones o reestructura-ciones, o externos como fuerzas competitivas o requisitos de cliente.

Para ello, la infraestructura de los Sistemas de Información que dan el soporte de las actividades de las organizaciones debe ser eficiente en costes, y es ahí donde las arquitecturas SOA ofrecen varios beneficios a considerar en el dinámico entorno en el que nos movemos.

Los principales beneficios que ofrece SOA son:

 Permite potenciar los activos preexistentes

Las arquitecturas SOA proporcionan un nivel de abstracción que permite a una organización potenciar la inver-sión realizada en Tecnologías de la Información y las Comunicaciones, ofreciendo sus activos como servicios que proporcionan funcionalidades de negocio. De esta forma, las organizaciones pueden potencialmente conti-nuar obteniendo valor de los recursos existentes.



 Facilita la integración

El punto de integración en las arquitecturas SOA es la especificación del servicio, no su implementación. De es-ta forma, se proporciona transparencia de la implementación y de la tecnología subyacente, y se minimiza el impacto de los cambios. La integración se simplifica y la complejidad se gestiona mejor, aislando los posibles problemas de la cadena de valor.

 Mayor capacidad de respuesta

La habilidad de componer nuevos servicios a partir de servicios existentes proporciona una ventaja significativa que permite a una organización ser más ágil a la hora de responder a las demandas de las necesidades de ne-gocio y de sus clientes.



 Reducir costes e incrementar la reutilización

Al disponer de los servicios básicos de negocio expuestos de forma que se promueve el débil acoplamiento, es posible la combinación y utilización de los mismos para cubrir las diferentes necesidades de negocio que van surgiendo, lo que supone a su vez menor duplicación de recursos, mayor potencial de reutilización y menor coste.



Es importante apuntar, no obstante, que las arquitecturas SOA no son el “santo grial” que solventa todos los problemas, y además la migración a una arquitectura SOA es una tarea muy compleja y comprometida, no exenta de riesgos.

Es preferible, por ello, migrar un conjunto parcial de funcionalidades de negocio de carácter sectorial en lugar de toda la infraestructura TI de la organización, y de forma paulatina ir incrementando dichas funcionalidades conforme surgen nuevas necesidades de negocio.

 

Arquitecturas orientadas a servicios --> flexibilidad y gran ahorro de costes en las cuantiosas inversiones realizadas en Tecnologías de la Información y las Comunicaciones.

Metodología para la definición y reutilización de componentes software y procesos de negocio, que en la mayoría de los casos se encuentran ya desarrollados e implementados mediante Tec-nologías de la Información en las organizaciones.

Los retos principales que debe afrontar la tecnología SOA debido a su inmadurez comprenden:

 Todos los principales proveedores del mercado afirman haber adoptado el paradigma SOA y publican y promue-ven su propia visión y referencia. Sin embargo, muchos grandes proveedores en realidad lo que han realizado es absorber a pequeñas y volátiles empresas con incipientes iniciativas SOA exitosas.

 Las arquitecturas SOA vinculan el “mundo TIC” con la “visión de negocio”, dos perspectivas que no se comuni-can de forma efectiva en muchas ocasiones y que a menudo tienen objetivos y motivaciones contrapuestas (coste reducido, énfasis en calidad, mayor agilidad, mantenibilidad, etc.)

 Existen diversos cuerpos de estandarización y organismos detrás de la definición y las líneas guía de las arqui-tecturas SOA, lo que añade una mayor confusión, problemas de interoperabilidad, y adopción más lenta de las mismas.

 Las actuales metodologías de desarrollo más extendidas (por ejemplo, la orientación a objetos) carecen del en-foque necesario para la definición de los elementos clave en las arquitecturas SOA: servicios, flujos de negocio y componentes que implementan servicios.

 La recurrente falta de un vocabulario común e interpretaciones incorrectas sobre lo que las arquitecturas SOA significan. Como veremos más adelante, es corriente asociar unívocamente los Web Services con las arquitectu-ras SOA, fuente común de confusión.