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.