Arquitectura SOA y Composición de Servicios

El enorme crecimiento de las tecnologías y aplicación de las TIC ha generado en los últimos años en un sinfín de aplicaciones. En muchas ocasiones, aplicaciones distintas pero con funciones comunes, agrupadas en bibliotecas que se compilaban en un todo. La heterogeneidad y el acoplamiento entre funcionalidades que podrían ser reutilizables ha forzado el estudio de nuevas estrategias de diseño. La forma de ver estas funciones como servicios comunes a distintos propósitos ha concluido en un nuevo paradigma de diseño arquitectónico denominado Arquitectura SOA.

La arquitectura SOA proporciona flexibilidad, reducción de costes y reutilización de componentes y procesos de negocio. Aún está adquiriendo madurez en su proceso de implantación en la industria, pero ya tiene una gran aceptación.

No es un concepto nuevo, sino que comenzó a tomar forma ya a mediados de los años 80, con la computación distribuida y las llamadas a procedimientos remotos. Pero estas arquitecturas distribuidas de los 90, como OSF, OMG o CORBA, no llegan a tener el impacto esperado en el mercado.

Esto fue formando la base de un paradigma de arquitectura que Gartner describirá en 1996 ya con el nombre de SOA. Sin embargo, no será hasta 2003, con el desarrollo de los servicios web, cuando irrumpa en el mercado, convirtiéndose en una disrupción tecnológica que a día de hoy está transformando el mundo empresarial.

¿Qué es SOA?

SOA son las siglas en inglés de «Service Oriented Architecture» que significa Arquitectura Orientada a Servicios. Este paradigma defiende un concepto de diseño de software que promueve la utilización de servicios como soporte de las reglas de negocio. Se trata, por tanto de la atomicidad y reutilización de estos servicios, que permitan componer distintas aplicaciones con las mismas piezas.

Cuando hablamos de atomicidad a lo que nos referimos es a la indivisibilidad del servicio, a la complejidad mínima. Es decir, si un servicio se puede descomponer en otros servicios, no es atómico.

De esta manera, un diseño arquitectónico basado en servicios se centra en la integración, interoperabilidad, modularidad, reutilización y composición a un nivel funcional de granularidad elevada. Todo ello sujeto a la conformidad con estándares.

El nivel de granularidad se podría definir como el nivel de detalle de una especificación funcional. En otros términos, la amplitud de la descripción del comportamiento esperado para el software en una especificación funcional.

Principios SOA

Este paradigma arquitectónico se basa en unos principios que deben servir de guía para definir las reglas de diseño:

• Encapsulación: Los servicios ocultan su lógica de negocio, y exponen un interfaz público para interactuar con el consumidor.
• Contrato: Los servicios están adscritos a un acuerdo definido en el documento de descripción del servicio.
• Servicios autocontenidos, con la lógica que encapsulan controlada.
• Débil acoplamiento y cohesión elevada, minimizando las interdependencias entre los propios servicios.
• Abstracción: Los servicios ocultan la lógica al exterior, haciendo de «caja negra» para el consumidor, que permite una mayor abstracción del sistema.
• Reutilización: La división del negocio en componentes promueve la capacidad de utilizarse en distintas funcionalidades, o composiciones de lo mismos.
• Composición: Al objeto de reutilización se añade la necesidad de ensamblarse unos servicios con otros. Componerse en niveles superiores que permitan realizar funcionalidades de menor granularidad.
• Descubrimiento: El diseño debe ser descriptivo y localizable mediante mecanismo de descubrimiento.

Esto resume los principios descritos en el manifiesto SOA. En este texto, elaborado por algunos de los mayores expertos en orientación a servicios, se propone los valores y principios rectores a seguir.

Componentes Arquitectónicos de SOA

Un diseño arquitectónico SOA constituye así un sistema distribuido, donde los componentes desplegados son servicios, abstraídos como componentes autónomos, débilmente acoplados, dentro de la red formada por proveedores y consumidores. De esta manera, el despliegue distribuido, permite la deslocalización de los servicios, que pueden estar también físicamente distribuidos.

Dentro de un concepto de arquitectura SOA hay que diferenciar los siguientes elementos:

• Roles: Cada entidad de la red de componentes puede desempeñar un papel en la misma, que en relación a la función que desempeñan puede ser:
  • Proveedor: Cuando la entidad publica sus servicios en el registro para que puedan ser descubiertos, y ofrece cierta funcionalidad para demanda de los consumidores.
  • Consumidor: Aquella entidad de la red de componentes en la arquitectura SOA que demanda funcionalidad proporcionada por un servicio.
  • Registro: Es una entidad responsable de la publicación y descubrimiento de servicios disponibles en la red, así como de los interfaces de los mismos.
• Operaciones: Una entidad puede desempeñar las siguientes operaciones en la red de componentes:
  • Publicar: El proveedor de servicios realiza la publicación de uno de ellos para los consumidores puedan descubrirlos y usarlos.
  • Descubrir: Un consumidor localizará un servicio que cumpla con un cierto criterio funcional mediante la consulta al registro de servicios.
  • Invocar o Usar: Una vez descubierto un servicio que satisface la necesidad funcional, el consumidor usará dicho servicio para ejecutar una pieza funcional teniendo en cuenta la descripción del mismo.
• Artefactos: Los artefactos en una arquitectura SOA pueden ser:
  • Servicio: Es el componente que realiza una función sin estado, autocontenida, y pública a través de su interfaz de descripción de servicio.
  • Descripción de servicio: Información del servicio descriptiva de la forma en la que el consumidor podrá interactuar con el proveedor, incluyendo las precondiciones, post-condiciones y/o niveles de calidad de servicio (QoS).

Componentes arquitectónicos

Una arquitectura SOA está caracterizada básicamente por tres componentes arquitectónicos principales:

• En primer lugar el Servicio software, que provee una funcionalidad relevante, reutilizable y expuesta a otros sistemas a través de las interfaces basadas en estándares.
• Consumidor del Servicio: El cliente software que utilizará la funcionalidad provista por el Servicio.
• Una infraestructura de comunicaciones que conecta a los dos anteriores, y que incluye un mecanismo de publicación y descubrimiento del Servicio.

Patrón de interacción SOA

El patrón de interacción SOA entre estos tres componentes, teniendo en cuenta los elementos descritos anteriormente será así:

Beneficios de una arquitectura SOA

En el ámbito empresarial es esencial poderse adaptar a los cambios con agilidad, a la vez de reducir los costes a niveles que se puedan asumir. Ahí es donde muestra la potencia el diseño arquitectónico orientado a servicios, ofreciendo una agilidad, flexibilidad y adaptabilidad a cambios que otros diseños mas rígidos y monolíticos no pueden ofrecer.

De esta manera, las principales ventajas que ofrece SOA serán:

• Composición e Integración de procesos: La arquitectura SOA proporciona un nivel de abstracción a través de los servicios autocontenidos, con reglas de negocio encapsuladas que permite componer nuevos procesos de negocio a partir de servicios existentes. Esto a su vez facilita la integración.
• Flexibilidad y adaptabilidad: Una arquitectura SOA crea sistemas altamente escalables. La capacidad de generar nuevos procesos de negocio a partir de la composición de otros existentes otorga gran flexibilidad de la arquitectura, y adaptabilidad a cambios. Esto genera a su vez ventajas evidentes:
  • Reutilización de activos existentes.
  • Costes reducidos.
  • Reducción del tiempo de respuesta frente a un cambio.
• Mejora de la Interoperabilidad entre plataformas y lenguajes: El nivel de abstracción de la arquitectura permite la independización de lenguajes y plataformas. El punto de integración es la especificación del servicio, no la implementación. Esto mejora la interoperabilidad con otras plataformas y lenguajes a través del intercambio mediante los estándares definidos.

Es importante reseñar que la encapsulación de servicios a través de interfaces permite que su invocación sea transparente, usando protocolos interoperables. Realmente esto es lo que proporciona una mayor flexibilidad y reutilización en el uso de una arquitectura de servicios.

Con todo esto resulta evidente que en el centro del enfoque de una arquitectura orientada a servicios está el servicio. Todo gira entorno al servicio en SOA, por lo que debemos tener claro en qué consiste.

Definición de Servicio

Desde el punto de vista del patrón de Arquitectura SOA un servicio es una funcionalidad empaquetada como componente distribuido, auto-contenido y reutilizable, con una definición de su interfaz accesible, explícita y pública.

Esto viene a decir que un servicio es un recurso con la capacidad de realizar alguna tarea concreta y proporcionar una funcionalidad a otras entidades solicitantes.

Así mismo, se puede abstraer un servicio como un componente débilmente acoplado en una red de proveedores y consumidores siguiendo el patrón de interacción descrito anteriormente.

Si vemos una arquitectura de componentes como un puzzle, un servicio sería una pieza software de las que lo componen y que proporciona una utilidad. El puzzle completo no sería otra cosa que una composición de servicios, una composición de piezas, con un objetivo concreto y una cohesión evidente.

En el concepto SOA de Servicio se tienen los siguientes aspectos que debe cumplir:

• Un servicio encapsula funciones de negocio con un objetivo evidente de ser reutilizadas.
• Un servicio debe definir una interfaz explícita.
• Para su invocación se utilizan protocolos de comunicación enfocados en la interoperabilidad y transparencia en cuanto a su localización.

Para poder consumir la funcionalidad que proporciona un servicio, es evidente que tiene que existir un interfaz que las entidades solicitantes puedan utilizar. Esto se denomina «contrato».

Una de las bazas mas importantes de la arquitectura SOA es precisamente la capacidad de interoperar servicios distribuidos. Estos servicios no tienen porqué estar construidos en la misma tecnología o lenguaje, sólo permitir la interacción en algún protocolo a través de contrato. Es decir, una arquitectura SOA puede estar compuesta de servicios desarrollados en .NET, Java, o Python, conectados a través de Soap, por ejemplo.

Diseño orientado a Servicios

En esencia una arquitectura orientada a servicios constituye un sistema distribuido, donde los componentes distribuidos son servicios independientes, abstraídos como unidades autónomas en una red de proveedores y consumidores.

Atendiendo a esta perspectiva, y teniendo en cuenta los principios SOA vistos, podremos introducir el proceso de diseño de servicios en SOA a través de tres etapas:

Identificación de Servicios

El primer paso en el diseño en una arquitectura SOA es la identificación de funcionalidades que puedan ser expuestas como servicios. Para ello es importante detectar las funcionalidades de granularidad alta que cumplan los criterios para ser candidatas:

1. Fácilmente independizables y que permitan un bajo acoplamiento.
2. Alto potencial de reutilización.

Existen dos enfoques principales para abordar esta difícil e importantísima tarea de identificación de los servicios útiles, mediante una aproximación ascendente (Bottom-Up) y aproximación descendente (Top-Down).

Aproximación Ascendente Bottom-Up

A partir de aplicaciones o sistemas legacy, heredadas o ya existentes en la organización, se analizan las funcionalidades candidatas a ser expuestas como servicios.

La principal ventaja de esta aproximación es la obtención rápida de servicios de negocio, a partir de los ya existentes. Por otro lado, los detractores de esta aproximación avisan del riesgo de llegar a una situación denominada ABOS (a buch of services). Esto es, un montón de servicios sin orden ni concierto, y con un gran número de servicios duplicados, que no se corresponde con una arquitectura SOA.

Aproximación Descendente Top-Down

En este caso el enfoque está en un análisis de los procesos de negocio, descomponiendo el requisito de negocio en los elementos del nivel mas bajo de granularidad. Es decir, desde el proceso de negocio, hasta llegar a procesos, subprocesos y tareas.

Por lo general, esta aproximación parte de los casos de uso como candidatos a servicios de negocio para la exposición de funcionalidad en la plataforma SOA.

Bottom-Up vs Top-Down

Existe un activo debate entre cual de estas dos aproximaciones es la más óptima, o la mas correcta. Por un lado, la aproximación Bottom-Up puede ser la más ágil, mientras que Top-Down debería ser la mas fiel a los principios de SOA. Entre los detractores de Bottom-Up se dice que, si se comienza a construir un servicio a partir de lo que ya tiene, se tiene un alto riesgo de acabar con lo que ya tiene, en lugar de lo que los consumidores necesitan. Por otro lado, entre los detractores de Top-Down, se dice que requiere una amplia planificación y estricto cumplimiento de las políticas, por lo que lleva un tiempo mucho mayor para conseguir resultados.

Finalmente, un enfoque mixto, que utilice ambas aproximaciones, parece ser lo que mas adeptos ha llegado a tener.

El método SOMA (Service Oriented Modeling and Architecture) de IBM, por ejemplo, incluye el enfoque «Meet in the middle«, que se basa en la descomposición del proceso empresarial en elementos granulares para su correlación con las aplicaciones existentes.

También es frecuente el llamado enfoque «Middle out» que combina simultáneamente los enfoques Top-Down y Bottom-Up. Esto es, definir los procesos de negocio respondiendo a los requisitos de negocio, a la vez que se definen servicios que aprovechan los sistemas existentes.

La principal tendencia actual se basa en el uso de ambas, con una primera fase Bottom-Up que aflore y exponga los servicios existentes, para pasar a una fase posterior de Top-Down, donde se analicen los procesos de negocio, y se asegure su alineación con la estrategia de la organización.

Una vez identificados, tanto los servicios existentes como los nuevos servicios que respondan a los procesos de negocio, se confecciona un inventario de servicios. En él se indicarán las relaciones entre servicios y objetivos de la empresa, evitando la duplicidad o inconsistencia en los nuevos servicios.

Diseño del Servicio

Una vez identificados los servicios, se realizarán las tareas de la fase de diseño, donde:

• Definir los contratos de cada servicio, incluyendo:
  • La interfaz y parámetros.
  • Descripción de la funcionalidad.
  • Políticas.
  • Restricciones.
• Clasificar y Categorizar en función de su naturaleza. Por ejemplo en servicios estratégicos para la empresa, servicios básicos, servicios de soporte, etc.
• Diseño arquitectónico del sistema que permita satisfacer los requisitos, y establecer la estructura mas adecuada a nivel lógico y físico, evitando confundir capas y niveles:
  • Una arquitectura monolítica.
  • O bien arquitectura Cliente/Servidor.
  • Arquitectura en tres capas.

Implementación

Finalmente, se selecciona la tecnología mas adecuada que permita la implementación y despliegue de la funcionalidad identificada como servicio. Esta etapa lleva a cabo la construcción o suscripción, adaptación o integración de una funcionalidad existente a la arquitectura tecnológica seleccionada.

Durante todo el proceso es evidente que se deben respetar los principios SOA, y hacer efectivo en el diseño y la implementación los criterios de bajo nivel de acoplamiento, independencia y reutilización. Uno de los objetivos de SOA es aislar al servicio de la plataforma, sistema operativo, hardware, lenguaje, protocolo, localización, etc. En resumen, minimizar el acoplamiento de la uniadad funcional.

Servicios web y Arquitectura SOA

Hay una confusión bastante frecuente entre WebServices y SOA. Se tiende a asemejar ambos conceptos que, no son lo mismo, debido a que, frecuentemente, se utilizan Web Services para la implementación SOA. Pero SOA no involucra a una tecnología concreta. Es decir, no tiene porqué implementarse sobre WebServices, y un sistema implementado con Web Services no tiene por qué ser una arquitectura SOA.

SOA es un estilo arquitectónico, un paradigma de diseño, mientras que Web Service es una tecnología. Por tanto, es posible que una implementación con servicios web dé soporte tecnológico a una arquitectura SOA. Sin embargo, podríamos tener una arquitectura SOA sin que exista ni un solo servicio web.

Composición de Servicios

La composición de servicios es uno de los principios de diseño en arquitectura SOA. De hecho, es lo que da sentido a una arquitectura orientada a servicios. Viene a ser, la construcción de funcionalidades complejas, en un nivel de abstracción menor, a partir de elementos atómicos de un nivel de abstracción mayor.

Como piezas LEGO, y esto inspira la imagen de portada, construir un nuevo proceso como la composición de servicios existentes.

En el diseño de un nivel de funcionalidad es posible que exista alguna agregación de servicios existentes para constituir un proceso de negocio de mayor envergadura (agregado).

La composición de servicios permite agregar servicios de un nivel de abstracción menor, o integrar servicios existentes, para el desarrollo de nuevos procesos de negocio.

Es frecuente que un nuevo proceso de negocio se pueda descomponer en etapas o una serie de actividades. Dichas actividades podrían realizarse a través de servicios ya existentes.

El ejemplo más fácil lo podemos tener en un buscador de viajes que ofrece la posibilidad de contratar un paquete integral. Dicho buscador puede ofrecer la reserva de vuelo, hotel y transporte local. El proceso viene a descomponerse en distintos servicios, y la secuencia de subprocesos, en este caso servicios, que describen el proceso mayor se denomina workflow.

WorkFlow

El workflow o flujo de proceso es un modelo de proceso empresarial representado con diagramas UML, o con la notación BPMN (Business Process Modeling Notation). Es el estudio de lo relativo a las operaciones que se desarrollan en una actividad o proceso. Estas operaciones pueden incluir, por ejemplo, sincronización de tareas, el orden de las mismas, la forma en que se realizan o cómo fluye la información a lo largo del proceso.

Se trata por tanto de la descripción de un trabajo colaborativo.

En un workflow se distinguen tres tipos de actividades diferentes:

1. Colaborativas: En aquellas donde un conjunto de entidades trabajan sobre el mismo repositorio de datos para obtener un resultado común. El trabajo de cada una de ellas tiene entidad en sí mismo.
2. Cooperativas: En este caso, cada entidad trabaja sobre su propio conjunto de datos particular, y se establece un mecanismo de cooperación entre ellos. El trabajo de ninguna una de ellas tiene entidad, salvo desde el punto de vista del resultado final.
3. Actividades de coordinación: Donde distintas entidades se coordinan entre sí para realizar un determinado trabajo.

Tipos de coordinación en la composición de servicios

La composición de servicios no es una tarea simple, ya que, en la ejecución del workflow de un proceso compuesto se puede requerir interacciones intermedias. Estas interacciones entre servicios pueden contemplar manejo de excepciones, errores, flujos condicionales o bifurcaciones, lo que puede complicar el flujo.

Para el proceso de composición de servicios se deben establecer los requisitos de composición, y la identificación, selección y creación de procesos. Para ello se utiliza un lenguaje de composición que permita especificar todos los aspectos de la misma.

Además, un punto determinante en la composición está relacionado con el tipo de coordinación de los servicios para llegar a formar un proceso de negocio. En este aspecto podemos encontrar dos enfoques: Orquestación y Coreografía.

Orquestación

El concepto de orquestación de servicios tiene mucha relación con el concepto que tenemos de una orquesta musical. En una orquesta existe un director, y un conjunto de instrumentos. Todos los instrumentos participan de alguna manera en la música, de forma coordinada, y es el director quien coordina.

En una orquestación de servicios, existe un proceso central que lleva el control del resto de servicios implicados en la realización de una tarea. Coordina la el flujo de ejecución de las diferentes operaciones.

Los servicios orquestados no conocen su implicación en un proceso de composición de una tarea de nivel superior. No saben que están siendo coordinados como pieza de una tarea de nivel mas alto. Únicamente el coordinador es quien conoce el objetivo a obtener, y por tanto la orquestación está centralizada en operaciones, y en el orden en que invocar los servicios ¿Recuerdas la película Cube…?

Lenguaje de modelado de procesos BPEL

WS-BPEL 2.0, conocido como BPEL (Business Process Execution Language) es un lenguaje de orquestación de servicios basado en XML. Soporta las principales tecnologías de servicios Web, tales como SOAP, WSDL, UDDI, WS-Reliable messaging, WS-Addressing, WS-Transaction y WS-Coordination.

BPEL se mantiene por OASIS desde el 2004, con un fuerte apoyo de la industria. Ser una confluencia de dos lenguajes de workflow anteriores: WSFL, de IBM, y XLANG, de Microsoft, proporciona dicho apoyo. Sin embargo, BPEL está diseñado específicamente como lenguaje para la definición de procesos de negocio, soportando dos tipos:

• Procesos de negocio ejecutables: Especifican todos los detalles de los procesos de negocio implicados.
• Procesos abstractos de negocio: Solo especifican el intercambio de mensajes públicos entre las partes implicadas.

Un proceso BPEL está compuesto por actividades. El lenguaje define dos tipos de actividades para la composición de servicios: primitivas y estructuradas.

Primitivas

Las primitivas son actividades básicas para la construcción de una composición, y podemos encontrar tareas como:

• Invocación (Invoke): Permite invocar a un servicio web, tanto de forma síncrona (request-response) como asíncrona (one-way)
• Recepción (Receive): Permite bloquear un proceso mientras espera la llegada de un mensaje.
• Respuesta (Response): Se utiliza para enviar una respuesta a una solicitud o mensaje previo.
• Espera (Wait): Para forzar una espera en un proceso, durante un tiempo determinado.
• Asignación (Assign): Permite asignar un valor a una variable.
• Lanzamiento (Throw): Como en otros lenguajes, permite arrojar una excepción.
• Finalización (End): Finalización de la orquestación en curso.

Estructuradas

Las actividades estructuradas combinan varias de las anteriores, y permiten un control del flujo mas detallado. Por ejemplo, tenemos:

• Sequence: Definir un conjunto de actividades que se realizarán de forma ordenada y secuencial.
• Swtich: Para incluir bifurcaciones del flujo.
• While: Permite definir bucles, repitiendo un grupo de tareas hasta cumplir la condición de salida.
• Flow: Para la paralelización de tareas.
• Pick: Permite la selección de actividades a realizar de forma condicionada, según la llegada de un mensaje, por ejemplo.

Realmente el lenguaje BPEL está basado en WSDL, de manera que, un proceso WS-BPEL puede ser expuesto e invocado a través de su propio WSDL.

Estructura de un documento BPEL

La estructura básica de un documento donde se define el proceso BPEL está compuesta de tres secciones, además de la principal que define el proceso:

<partnerLinks>

PartnerLinks es la sección donde se definen los agentes que interaccionan en el proceso BPEL. Cada agente lleva un PartnerLink, y está definido por un parterLinkType, además del rol.

El partnerLinkType especifica la relación entre dos servicios, definiendo el portType donde cada servicio va a recibir los mensajes.

<variables>

En el identificativo variables se declaran las variables que se utilizarán para almacenar y transformar mensajes del proceso BPEL. Es decir, las variables se utilizarán para el envío y recepción de mensajes a partners.

BPEL define tres tipos de variables:

• WSDL Message Type: Indicado con el atributo messageType.
• XML Schema Type: Con el atributo type.
• XML Schema Element: Reflejado con el atributo element.

Cada variable se declarará en un <scope> donde tendrá visibilidad como global o local. Deberán ser inicializadas antes de utilizarse, y para hacerlo podremos utilizar la actividad <assign> para asignarle un mensaje.

<sequence>

Dentro de esta etiqueta contendrá las actividades que conforman el proceso BPEL.

<process name="nameProcess">
    <partnerLinks>
    <!-- Declaración de partner links -->
    </partnerLinks>
    <variables>
    <!-- Declaración de variables -->
    </variables>
    <sequence>
    <!-- Cuerpo principal del proceso BPEL -->
    </sequence>
</process>

Aunque BPEL no tiene una notación gráfica estándar, se utiliza BPMN para su especificación, con traducción a BPEL.

Coreografía

En la coreografía podríamos asimilar el concepto que tenemos de una coreografía de bailarines, donde no existe un líder, no hay un coordinador. Un grupo de danza donde todos se mueven de forma coordinada, conociendo la “coreografía”.

De igual manera, una coreografía de servicios no está coordinada por un proceso central, sino que cada servicio implicado conoce el plan, el objetivo a conseguir, y el papel que le corresponde. Cada servicio sabe cuando debe ejecutar sus operaciones y con qué otro servicio debe interactuar.

Se trata de un trabajo colaborativo enfocado en el intercambio de mensajes en los procesos de negocio. Los servicios forman parte de un proceso de negocio, conocido por todos ellos.

Lenguaje de modelado de procesos CDL

WS-CDL (Web Services Choreography Description Languaje) ha sido el lenguaje basado en XML utilizado para la definición de servicios en composición por coreografía.

Este lenguaje describe la colaboración entre los servicios que conforman la composición coreográfica, en el conjunto. Es decir, bajo un punto de vista global y común de la composición.

WS-CDL no define procesos ejecutables, se trata de un lenguaje de definición, sino que permite definir las interacciones entre los participantes.

Antes de WS-CDL se utilizaba WSDL para describir los comportamientos «observables» de los servicios, pero WS-CDL vino a cubrir algunas carencias. Entre ellas, permitir la descripción de elementos «no observables» como la integración entre dos servicios en el marco del objetivo funcional propuesto.

El desarrollo de WS-CDL, que estuvo mantenido por la W3C, fue abandonado tras cerrar el grupo de trabajo de la W3C Web Services Choreography Working Group en el 10 de Julio de 2009.

Orquestación vs Coreografía

Como hemos visto, la orquestación de servicios y la coreografía son dos tipos de coordinación diferentes en una composición de servicios. El enfoque de coordinación con orquestación se ha impuesto por diversas razones:

• La orquestación es mas flexible, al estar coordinados por un coordinador central los servicios son mas fácilmente modificables, sustituibles y reutilizables.
• Los servicios se pueden incorporar a la composición sin ser conscientes de ello, sin sufrir cambios.
• Es más ágil crear escenarios alternativos en caso de cambio o fallo.
• Para un enfoque Bottom-Up sólo es posible una composición con orquestación, que permite incluso orquestar servicios legacy.