BPEL: Composición del servicio para SOA

BPEL (Business Process Execution Language) se ha convertido en una de las tecnologías más importantes de SOA (arquitectura orientada a servicios) y permite una composición fácil y flexible de servicios en procesos comerciales. BPEL es particularmente importante porque introduce un nuevo concepto en el desarrollo de aplicaciones: programación en general. Este concepto nos permite desarrollar procesos rápidamente al definir el orden en el que se invocarán los servicios. De esta manera, las aplicaciones (y los sistemas de información) se vuelven más flexibles y pueden adaptarse mejor a los cambios en los procesos comerciales.

Los procesos comerciales suelen ser de naturaleza dinámica. Las empresas tienen que mejorar y modificar, actuar de forma ágil, optimizar y adaptar procesos para mejorar la capacidad de respuesta de toda la empresa. Cada cambio y mejora en un proceso empresarial debe reflejarse en aplicaciones que les brinden soporte. Aunque este requisito puede no parecer muy difícil de cumplir, la situación del mundo real nos muestra una imagen diferente. Cambiar y modificar aplicaciones es a menudo un trabajo difícil que requiere tiempo. Por lo tanto, las aplicaciones no pueden reaccionar instantáneamente a los cambios en los procesos comerciales; más bien, requieren algo de tiempo para implementar, probar y desplegar las modificaciones.

Hacer que los sistemas de información sean más flexibles y adaptables a los cambios, y que estén mejor alineados con los procesos comerciales es la principal promesa de SOA. En este artículo, muestro por qué BPEL es tan importante y demuestro cómo desarrollar un proceso BPEL.

Enfoque orientado al servicio

El enfoque SOA para la automatización eficiente de los procesos comerciales requiere:

  • Manera estandarizada de exponer y acceder a la funcionalidad de aplicaciones como servicios
  • Infraestructura de bus empresarial para la comunicación y gestión de servicios, incluida la interceptación, enrutamiento, transformación de mensajes, etc.
  • Lenguaje especializado para la composición de funcionalidades expuestas de aplicaciones en procesos comerciales

El primer requisito lo cumple la última arquitectura distribuida: los servicios web. El segundo requisito lo cumple el ESB (bus de servicio empresarial), que proporciona soporte para la gestión centralizada, declarativa y bien coordinada de los servicios y sus comunicaciones. El tercer requisito, la composición de los servicios en procesos, lo cumple BPEL, el lenguaje especializado comúnmente aceptado para la definición y ejecución de procesos comerciales.

Un proceso empresarial, como lo ve BPEL, es una colección de invocaciones de servicios coordinados y actividades relacionadas que producen un resultado, ya sea dentro de una sola organización o en varias. Por ejemplo, un proceso empresarial para planificar viajes de negocios invocará varios servicios. En un escenario muy simplificado, el proceso comercial requerirá que especifiquemos el nombre del empleado, el destino, las fechas y otros detalles del viaje. Luego, el proceso invocará un servicio web para verificar el estado del empleado. Según el estado del empleado, seleccionará la clase de viaje adecuada. Luego invocará los servicios web de varias compañías aéreas (como American Airlines, Delta Airlines, etc.) para comprobar el precio de la tarifa aérea y comprar la que tenga el precio más bajo.

Para los clientes, el proceso BPEL expondrá su funcionalidad de la misma manera que cualquier otro servicio web. Desde la perspectiva del cliente, se verá exactamente como cualquier otro servicio web. Esto es importante y útil, ya que nos permite componer servicios en procesos simples, procesos simples en procesos más complejos, etc. Esto también significa que cada proceso BPEL se describirá con una descripción WSDL (Lenguaje de descripción de servicios web).

Conceptos básicos

BPEL es un lenguaje basado en XML. Un proceso BPEL consta de pasos. Cada paso se llama actividad. BPEL admite actividades primitivas y de estructura. Las actividades primitivas representan constructos básicos y se utilizan para tareas comunes, como las que se enumeran a continuación:

  • Invocar servicios web, usar
  • Esperando la solicitud, usando
  • Manipular variables de datos, usando
  • Indicación de fallas y excepciones, uso , etc.

Luego, podemos combinar estas actividades en algoritmos más complejos que especifican los pasos de un proceso comercial. Para combinar actividades primitivas, BPEL admite varias actividades de estructura. Los mas importantes son:

  • Sequence ( ) para definir un conjunto de actividades que se invocarán en una secuencia ordenada
  • Flow ( ) para definir un conjunto de actividades que se invocarán en paralelo
  • Construcción de cambio de caso ( ) para implementar ramas
  • Mientras ( ) para definir bucles, etc.

Como veremos, BPEL no es tan diferente de los lenguajes de programación, como Java. Pero veremos que BPEL se diferencia de Java y soporta las características de los procesos empresariales. BPEL también proporciona controladores de errores y compensación, controladores de eventos y conjuntos de correlación. Proporciona medios para expresar flujos paralelos complejos. También hace que sea relativamente fácil llamar a operaciones asincrónicas y esperar devoluciones de llamada.

Los procesos BPEL requieren un entorno de ejecución, un servidor BPEL, que nos brinda un buen control sobre su ejecución. Normalmente, los servidores BPEL proporcionan control sobre las instancias de proceso que se están ejecutando y las que han finalizado. Admiten procesos de larga duración y pueden deshidratar el estado del proceso para ahorrar recursos. Algunos servidores proporcionan control sobre las actividades del proceso y permiten su supervisión. Finalmente, utilizando un servidor BPEL, todos nuestros procesos se implementan de forma centralizada, lo que simplifica el mantenimiento. Todo esto hace que el servidor BPEL sea el entorno preferido para ejecutar y gestionar procesos.

Sin embargo, elegir el servidor BPEL correcto puede ser bastante difícil, ya que existen varias opciones. Algunos de los servidores BPEL más populares que se basan en Java EE (el nuevo nombre de Sun para J2EE) incluyen Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration y AquaLogic. También hay al menos cuatro servidores BPEL de código abierto disponibles: ActiveBPEL Engine, FiveSight PXE, bexee y Apache Agila.

Proceso de ejemplo

Veamos ahora un ejemplo de proceso BPEL para viajes de negocios que hemos descrito anteriormente. Desarrollaremos un proceso asincrónico que utilizará una llamada sincrónica para verificar el estado de viaje del empleado y dos llamadas asincrónicas para adquirir los precios de los boletos de avión. La siguiente figura muestra la estructura general de nuestro proceso. A la izquierda, vemos el cliente que invoca el proceso. El proceso primero llama al servicio web de estado de viaje del empleado. Luego, invoca los servicios web de ambas aerolíneas de forma simultánea y asincrónica. Esto significa que el proceso tendrá que implementar la operación de devolución de llamada (y un tipo de puerto), a través del cual las aerolíneas devolverán la confirmación del boleto de vuelo. Finalmente, el proceso devuelve al cliente la mejor oferta de pasaje aéreo. En este ejemplo, para mantener la simplicidad, no implementaremos ningún manejo de fallas,que es crucial en escenarios del mundo real.

Escribamos ahora el código BPEL. Comenzamos con la declaración del proceso, el elemento raíz, donde definimos el nombre del proceso y los espacios de nombres:

A continuación, tenemos que definir los enlaces de socios. Los enlaces de socios definen diferentes partes que interactúan con el proceso BPEL. Esto incluye todos los servicios web que se invocarán y el cliente del proceso. Cada enlace de socio especifica hasta dos atributos: myRoleque indica la función del proceso empresarial en sí y partnerRoleque indica la función del socio. En nuestro ejemplo, definimos cuatro enlaces de socios:

Para almacenar mensajes y reformatearlos y transformarlos, necesitamos variables. Usualmente usamos una variable para cada mensaje enviado a los servicios web y recibido de ellos. En nuestro ejemplo, necesitaremos algunas variables. Para cada variable, tenemos que especificar el tipo. Podemos utilizar un tipo de mensaje WSDL, un tipo simple de esquema XML o un elemento de esquema XML. En nuestro ejemplo, usamos tipos de mensajes WSDL para todas las variables:

Ahora estamos listos para escribir el cuerpo del proceso principal. Contiene solo una actividad de nivel superior. Por lo general, esta es una que nos permite definir varias actividades que se realizarán de forma secuencial. Dentro de la secuencia, primero especificamos el mensaje de entrada que inicia el proceso empresarial. Hacemos esto con la construcción, que espera el mensaje coincidente. En nuestro caso, este es el TravelRequestmensaje. Dentro de la construcción, no especificamos el mensaje directamente. Más bien, especificamos el enlace del socio, el tipo de puerto, el nombre de la operación y, opcionalmente, la variable que contiene el mensaje recibido para las operaciones consiguientes. Vinculamos la recepción del mensaje con el socio cliente y esperamos TravelApprovala que se invoque la operación en el tipo de puerto TravelApprovalPT. Almacenamos el mensaje recibido en elTravelRequest variable:

A continuación, debemos invocar el servicio web Employee Travel Status. Antes de esto, tenemos que preparar la entrada para este servicio web. Podemos construir tal mensaje copiando al empleado parte del mensaje que envió el cliente. Ahora podemos invocar el servicio web Employee Travel Status. Realizamos una invocación sincrónica, para lo cual utilizamos la actividad. Usamos el employeeTravelStatusenlace de socio e invocamos la EmployeeTravelStatusoperación en el EmployeeTravelStatusPTtipo de puerto. Hemos preparado el mensaje de entrada en la EmployeeTravelStatusRequestvariable. Debido a que es una invocación sincrónica, la llamada espera la respuesta y la almacena en la EmployeeTravelStatusResponsevariable:

El siguiente paso es invocar los servicios web de ambas aerolíneas. Nuevamente, primero preparamos el mensaje de entrada requerido (que es igual para ambos servicios web). Realizaremos invocaciones asincrónicas concurrentes. Para expresar concurrencia, BPEL proporciona la actividad. La invocación a cada servicio web constará de dos pasos:

  1. La actividad se utiliza para la invocación asincrónica.
  2. La actividad se utiliza para esperar la devolución de llamada.

Usamos para agrupar ambas actividades. Las dos invocaciones difieren solo en el nombre del enlace de socio. Usamos AmericanAirlinespara uno y DeltaAirlinespara otro:

...