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

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.