Orquestación (Web Service Orchestration) y Coreografía (Web Services Choreography) se suelen ver como dos aproximaciones para la Composición de Servicios Web, pero tienen matices (la principal diferencia entre orquestación y coreografía es el alcance):

Si buscaramos la definición de Orquestación y Coreografía en un diccionario obtendríamos algo tal que así:

• La Orquestación es el estudio y práctica de ordenar la música para una orquesta. Es decir, consiste en decidir que instrumentos deben tocar qué notas en una pieza de música.
• La Coreografía es la ordenación y movimiento de los bailarines en el escenario. Es decir, consiste en decidir como debe ser el movimiento de los bailarines en el escenario al ritmo de la música.

Después de estas "definiciones" podríamos hablar de similitudes entre orquestación y música; al igual que de coreografía y danza (o bailarines). El problema es que esto no termina de dejar claro las similitudes y diferencias entre Orquestación y Coreografía aplicadas a los Servicios Web.

Cuando hablamos de Orquestación, debemos hablar de WS-BPEL y por tanto de procesos ejecutables. Es decir, la Orquestación podría verse como la ejecución de un proceso de negocio definido en WS-BPEL y que puede ser ejecutado por un motor BPEL.
Cuando hablamos de Coreografía, debemos hablar de WS-CDL (Web Services Choreography Description Language) y por tanto de colaboración entre actores; es decir, de interacciones entre servicios web.
Hay que verlo desde una perspectiva distinta, WS-BPEL (Orquestación) es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). Y WS-CDL (Coreografía) es una visión más abstracta y descriptiva de los actores que intercambian mensajes para ejecutar varios proceso particulares (varios flujos de control).

WS-CDL tiene como propósito definir la interoperabilidad necesaria para crear un sistema compuesto por servicios web. La Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores. Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio (por ejemplo, BPSS – Business Process Specification Schema)) de diversos servicios web.
Por el contrario, WS-BPEL se centra en la composición de nuevos servicios a partir de otros ya existentes. BPEL nos proporciona una manera de describir el comportamiento interno de qué necesitan los servicios para trabajar conjuntamente y así poder crear otro servicio como composición de los primeros.

No se si queda claro o simplemente genera más confusión. ¿Que opinais al respecto?

Links interesantes:

Web Services Orchestration Using BPEL
Service Orchestration vs. Service Choreography by John Reynolds
What is… choreography? What is… orchestration? on Digital Walkabout
OASIS Web Services Business Process Execution Language (WSBPEL)
WS-Choreography Definition Language (WS-CDL)

La especificación BPEL4People fue creada para modelar a gente dentro de la definición de procesos BPEL. Específicamente, podrá visualizarse una actividad denominada "Actividad de Persona"; igual que una estándar de invocación de servicio web; pero con un contexto adicional asociado.

Por su parte, WS-HumanTask suministra el API y el motor de ejecución para BPEL4People. Se encargará de definir cómo debe ser la tarea, la manera de crearla y de dar un conjunto de API’s para su interacción.

El estándar BPEL no incluye definiciones para incorporar tareas humanas. No obstante, todos los proveedores de herramientas BPM que soportan BPEL; incorporan desarrollos propios que soportan las interacciones humanas (normalmente como "worklists" que permiten reclamar, reasignar o ejecutar tareas por medio de personas). El problema es que dichos desarrollos son propietarios y en ningún caso estandarizados; por lo que aparece un problema de portabilidad entre fabricantes; dificilmente salvable sin una estandarización como la que

BPEL4People propone un patrón de interacción de 5 tareas de proceso distintas:

En el primer patrón, la tarea se especifica dentro de la actividad humana. En el segundo, se especifica dentro del Proceso BPEL, por lo que puede ser reutilizada por numerosas actividades dentro de dicho proceso.
En el tercer patrón, la tarea es externa al proceso BPEL, por lo que puede ser llamada por varios procesos. Este modelo permite que una tarea pueda ser llamada por varios motores de procesos, incluso de diversos fabricantes (por lo que se da solución al problema de la portabilidad).
El patrón cuatro, es como el tercero, salvo porque la exposición de la tarea se define a través de un interfaz WSDL (de esta manera, implementaciones tales como la transaccionalidad, requerirán de implementaciones estandarizadas como WS-Transaction; mientras que en el anterior patrón, dichas características quedan a merced de la implementación que haga cada propietario).
Por último, el patrón quinto, es como el cuarto, salvo porque la tarea es llamada desde una Actividad de Invocación estándar, en lugar de una actividad humana

Links interesantes:

WS-BPEL Extension for People
Proyecto BPEL4People en SourceForge.net

BPEL es un lenguaje ejecutable con sus variables y operaciones. Las operaciones permiten enviar y recibir mensajes SOAP y tiene un gran soporte para XML y transformaciones XML. Además, permite de manera fácil invocar múltiples servicios web al mismo tiempo y sincronizar los resultados.
BPEL no tiene soporte gráfico; es decir, no especifica como deben ser los diagramas interpretativos de los procesos que define.
El objetivo de BPEL es ofrecer una forma de orquestar servicios web, la secuencia de interacciones subyacente y el flujo de datos punto a punto.

XPDL, por su lado, especifica un formato de diseño de los procesos. Permite una representación gráfica de los procesos incluyendo coordenadas X e Y para cada nodo implementado. Además, los nodos pueden especificar atributos tales como roles, descripción de actividades, timers, llamadas a servicios web, etc… Suele ser preferido cuando se trata de implementar procesos o workflows con interacciones humanas, ya que en esto supera a BPEL (para soportar interacciones humanas, BPEL necesita de añadidos a la especificación, lo cual dificulta su portabilidad ya que suelen ser implementaciones propietarias de cada proveedor).
El objetivo de XPDL es almacenar y permitir el intercambio de diagramas de procesos. Intenta ofrecer una manera estándar para representar procesos de tal manera que puedan ser importados/exportados por cualquier editor que implemente el estándar.
XPDL 2.0 tiene extensiones que permite representar todos los aspectos de BPMN.

A veces, el intercambio de procesos BPEL entre distintas herramientas no es todo lo satisfactorio que se desearía (ya que cada proveedor implemente BPEL “a su manera”; incluso cuando el objetivo inicial de la especificación era la unificación en la forma de implementarlo).
Por el contrario, XPDL en su representación de BPMN si es transportable de una herramienta a otra (ya que luego cada proveedor realiza su conversión de XPDL a BPEL según necesite; o incluso ejecuta XPDL de forma nativa). Por eso, XPDL se puede establecer como un formato ideal para intercambio de procesos entre distintos proveedores que transformarán los desarrollos al formato BPEL adecuado a sus necesidades.

BPEL y XPDL no son competidores entre sí, ya que pueden ser complementarios según el uso que se haga de ellos. De hecho, a partir de un modelo BPMN podemos pasar a un proceso BPEL ejecutable por un motor de una herramienta.
Igualmente a partir de un proceso BPMN podemos obtener una implementacion XPDL (de hecho, desde la versión XPDL 2.0 esto es inmediato en ambos sentidos) que puede ser ejecutada por algunos motores de forma nativa. La desventaja del paso de BPMN a BPEL es que no siempre se puede hacer el camino inverso (lo que dificulta la exportación/importación entre herramientas). Pero tampoco hay una necesidad imperiosa de ello: BPEL y XPDL están pensados para cosas distintas; pero pueden ser complementarias si se utilizan de esa manera.

Es interesante la aproximación a la cadena de valor BPMN-XPDL-BPEL que se detalla en el artículo “Understanding the BPMN-XPDL-BPEL Value Chain” de Nathaniel Palmer:

1. El usuario genera un diagrama con notación BPMN del proceso que quiere construir.
2. Se guardan los diagramas parciales como XPDL durante el desarrollo. En el caso de XPDL 2.0 esto es inmediato.
3. Finalmente se traducen ciertas partes a BPEL (básicamente en lo que a intercambio de datos se refiere, no a interacciones humanas donde BPEL no es adecuado ya que necesita de modulos específicos que son diferentes en su implementación por los distintos fabricantes).

¿Qué creeis? ¿Habéis utilizado alguna vez alguno de estos estándares?

Espero que cuando menos se hallan disipado alguna de las dudas acerca de las tres implementaciones más conocidas de que disponemos para crear Procesos de Negocio.

Links interesantes:

The BPMN-XPDL-BPEL value chain (Go Flow)
Recursos XPDL (WFMC)
Recursos BPMN (OMG)
Recursos BPEL (OASIS)

WS-BPEL (también conocido como BPEL4WS o simplemente BPEL) es un lenguaje de composición de Servicios Web Orientado a Procesos. Se basa en los WSDL (Web Service Definition Language) y de hecho un proceso WS-BPEL puede ser expuesto a través de su propio WSDL y por tanto ser invocado como cualquier otro Servicio Web (permitiendo la reutilización de los mismos).

Nació como combinación de WSFL (Web Service Flow Language de IBM, orientado a grafos y basado en el control de los links entre tareas) y XLANG (Web Services for Business Process Design de Microsoft, basado en un control de flujos con secuencias, condiciones, bucles, etc…) y ha evolucionado adquiriendo lo mejor de cada uno e intentando evitar las malas prácticas de los mismos (debido a que el paradigma de utilización de ambos es distinto y a veces de lugar a situaciones de construcción sobrelapadas).

WS-BPEL define un conjunto de tareas básicas para la Composición de Servicios Web:

• Tareas de Invocación (Invoke): Invocación de operaciones one-way o request-response en un servicio web.
• Tareas de Recepción (Receive): Permite el bloqueo de un proceso a la espera de llegada de un mensaje.
• Tareas de Respuesta (Response): Permite enviar un mensaje en respuesta a un mensaje recibido previamente.
• Tareas de Espera (Wait): Permite la espera durante un tiempo del proceso.
• Tareas de Asignación (Assign): Permite copiar datos de un lugar a otro.
• Tareas de Lanzamiento (Throw): Permite indicar que ha ocurrido un error.
• Tareas de Finalización (End): Permite finalizar la orquestación de la instancia en curso.

Además, las tareas estructuradas son utilizadas para combinar las primitivas en otras más complejas:

• Tareas secuenciales (sequence): Define un orden secuencial de tareas.
• Tareas de decisión (switch): Permite seleccionar un camino en particular en base a una condición.
• Tareas de elección: Permite bloquear y esperar la llegada de un mensaje o establecer un tiempo límite de espera (timeout). Cuando uno de los eventos ocurre, se ejecutan las tareas designadas.
• Tarea repetitiva (While): Permite repetir un grupo de tareas mientras se cumpla una determinada condición.
• Tareas paralelas: Permite paralelizar la ejecución de cierto grupo de tareas.

WS-BPEL trata todos los estados como una colección de tipos de mensajes WSDL. Esa colección de mensajes que constituyen un estado es lo que se llama contenedor. Los mensajes de un contenedor pueden ser los enviados o recibidos con clientes o servicios externos; incluso los utilizados internamente por el proceso para computación temporal de los mismos. Asimismo, la comunicación se define a través de los PortType de los WSDL.

WS-BPEL sostiene la idea de un contenedor para cada tarea en el flujo definido, cada uno de los cuales tiene una definición de esquema. Así, un mensaje se corresponde a un contenedor, que básicamente es un servicio web con información adicional sobre como procesarlo, posibles pre-condiciones y post-condiciones.

De modo gráfico, un proceso definido en WS-BPEL tendría la siguiente forma:

Todos los accesos a datos y manejos de los mismos en WS-BPEL es definido utilizando estándares como XPath y XSLT, además de basarse en los contratos de servicios establecidos por medio de los WSDL.

Durante la ejecución de un proceso se pueden establecer más de una conversación con servicios externos, por lo que es necesario establecer mecanismos a nivel de aplicación para corresponder los mensajes y conversaciones con las instancias de procesos que sean objetos de los mismos. Para ello, WS-BPEL ofrece lo que se conoce como “Correlation Sets” o Grupos de Correlaciones. Estos son conjuntos de propiedades, que juntos sirven para definir una conversación a nivel de aplicación dentro de una instancia de proceso. Básicamente son identificadores únicos de instancias de proceso, que permite saber en todo momento que instancia corresponde a qué mensaje recibido o enviado a través del mismo.

WS-BPEL puede ser utilizado tanto para orquestación de servicios (llamadas a procesos ejecutables; entendiendo como tal las llamadas a servicios y la especificación de como se llevan a cabo) como para coreografía de servicios(llamadas a procesos abstractos; entendiendo como tal los mensajes públicos a intercambiar entre dos o más partes).

Por lo general, la implementación de WS-BPEL varia según el fabricante y de hecho algunos lo interpretan como un Script XML que puede ser ejecutado con un motor específico; mientras que otros lo interpretan como un lenguaje de intercambio. La última especificación, la 2.0 incluye nuevas características como inicialización de variables, transformación XSLT de variables, acceso XPath a datos de variables, etc… No obstante, la especificación 1.1 es la más estable y en uso todavía por la mayoría de los fabricantes, ya que la 2.0 ha sido recientemente aprobada el 31/01/2007 por OASIS y todavía está siendo preparada para su publicación definitiva.