in

Introducción práctica a BPEL

116739

Antecedentes de BPEL

Primero, algunos antecedentes. BPEL se basa en la base de XML y servicios web; utiliza un lenguaje basado en XML que admite la pila de tecnología de servicios web, incluidos SOAP, WSDL, UDDI, WS-Reliable Messaging, WS-Addressing, WS-Coordination y WS-Transaction.

BPEL representa una convergencia de dos lenguajes de flujo de trabajo tempranos; Lenguaje de flujo de servicios web (WSFL) y XLANG. WSFL fue diseñado por IBM y se basa en el concepto de gráficos dirigidos. XLANG, un lenguaje estructurado en bloques, fue diseñado por Microsoft. BPEL combina ambos enfoques y proporciona un vocabulario rico para la descripción de procesos comerciales.

La primera versión de BPEL se desarrolló en agosto de 2002. Desde entonces, muchos proveedores importantes se han unido (incluido Oracle), lo que resultó en varias modificaciones y mejoras, y la adopción de la versión 1.1 en marzo de 2003. En abril de 2003, BPEL se presentó a la Organización para el Avance de Estándares de Información Estructurada (OASIS) con fines de estandarización, y el Comité Técnico del Lenguaje de Ejecución de Procesos de Negocios de Servicios Web ( WSBPEL TC) fue formado. Este esfuerzo ha dado lugar a una aceptación aún mayor en la industria.

Dentro de la empresa, BPEL se utiliza para estandarizar la integración de aplicaciones empresariales, así como para extender la integración a sistemas previamente aislados. Entre empresas, BPEL permite una integración más fácil y eficaz con socios comerciales. BPEL estimula a las empresas a definir aún más sus procesos comerciales, lo que a su vez conduce a la optimización, reingeniería y selección de los procesos más apropiados, optimizando aún más la organización. Las definiciones de procesos comerciales descritas en BPEL no afectan los sistemas existentes, lo que estimula las actualizaciones. BPEL es la tecnología clave en entornos donde las funcionalidades ya están o estarán expuestas a través de servicios web. Con los aumentos en el uso de servicios web, la importancia de BPEL también aumentará.

Orquestación versus coreografía

Los servicios web suelen exponer las operaciones de determinadas aplicaciones o sistemas de información. En consecuencia, combinar varios servicios web en realidad implica la integración de las aplicaciones subyacentes y sus funcionalidades.

Los servicios web se pueden combinar de dos formas:

  • Orquestación
  • Coreografía

En la orquestación, que se utiliza habitualmente en procesos empresariales privados, un proceso central (que puede ser otro servicio web) toma el control de los servicios web implicados y coordina la ejecución de diferentes operaciones en los servicios web implicados en la operación. Los servicios web involucrados no «saben» (y no necesitan saber) que están involucrados en un proceso de composición y que están participando en un proceso de negocios de nivel superior. Solo el coordinador central de la orquestación es consciente de este objetivo, por lo que la orquestación se centraliza con definiciones explícitas de operaciones y el orden de invocación de los servicios web. (Ver figura 1)

116739

Figura 1: Composición de servicios web con orquestación

La coreografía, por el contrario, no depende de un coordinador central. Más bien, cada servicio web involucrado en la coreografía sabe exactamente cuándo ejecutar sus operaciones y con quién interactuar. La coreografía es un esfuerzo colaborativo que se centra en el intercambio de mensajes en los procesos comerciales públicos. Todos los participantes en la coreografía deben conocer el proceso de negocio, las operaciones a ejecutar, los mensajes a intercambiar y la sincronización de los intercambios de mensajes. (Ver Figura 2.)

106635

Figura 2: Composición de servicios web con coreografía

Desde la perspectiva de componer servicios web para ejecutar procesos comerciales, la orquestación es un paradigma más flexible y tiene las siguientes ventajas sobre la coreografía:

  • La coordinación de los procesos componentes está gestionada de forma centralizada por un coordinador conocido.
  • Los servicios web pueden incorporarse sin que sepan que están participando en un proceso empresarial más amplio.
  • Se pueden implementar escenarios alternativos en caso de que ocurran fallas.

BPEL admite dos formas diferentes de describir los procesos comerciales que respaldan la orquestación y la coreografía:

  • Procesos ejecutables le permiten especificar los detalles exactos de los procesos comerciales. Siguen el paradigma de orquestación y pueden ser ejecutados por un motor de orquestación.
  • Protocolos comerciales abstractos permitir la especificación del intercambio de mensajes públicos entre partes únicamente. No incluyen los detalles internos de los flujos de proceso y no son ejecutables. Siguen el paradigma de la coreografía.

Ahora, veamos la creación de un proceso de negocio BPEL ejecutable; el código se puede descargar e implementar en oracleBPEL Process Manager. Supondremos que oracleBPEL Process Manager se ha instalado correctamente de acuerdo con las instrucciones de instalación y que utiliza el puerto predeterminado 9700. Si se ha seleccionado otro puerto durante la instalación, los ejemplos deben modificarse en consecuencia.

Construyendo un proceso empresarial

Un proceso BPEL especifica el orden exacto en el que se deben invocar los servicios web participantes, ya sea secuencialmente o en paralelo. Con BPEL, puede expresar comportamientos condicionales. Por ejemplo, una invocación de un servicio web puede depender del valor de una invocación anterior. También puede construir bucles, declarar variables, copiar y asignar valores, definir controladores de fallas, etc. Al combinar todas estas construcciones, puede definir procesos comerciales complejos de manera algorítmica. De hecho, debido a que los procesos de negocios son esencialmente gráficos de actividades, podría ser útil expresarlos usando diagramas de actividad del Lenguaje de modelado unificado (UML).

En un escenario típico, el proceso de negocio BPEL recibe una solicitud. Para cumplirlo, el proceso invoca los servicios web involucrados y luego responde al llamador original. Dado que el proceso BPEL se comunica con otros servicios web, se basa en gran medida en la descripción WSDL de los servicios web invocados por el servicio web compuesto.

Pongamos un ejemplo. Un proceso BPEL consta de pasos; cada paso se denomina «actividad». BPEL admite actividades primitivas y de estructura. Primitivo Las actividades representan constructos básicos y se utilizan para tareas comunes, como las siguientes:

  • Invocar otros servicios web, usar <invoke>
  • Esperando a que el cliente invoque el proceso empresarial enviando un mensaje, utilizando <receive> (recibiendo una solicitud)
  • Generando una respuesta para operaciones síncronas, usando <reply>
  • Manipular variables de datos, usando<assign>
  • Indicar fallas y excepciones, usando <throw>
  • Esperando un tiempo, usando <wait>
  • Terminando todo el proceso, usando <terminate>

Luego, podemos combinar estas y otras actividades primitivas para definir algoritmos complejos que especifiquen exactamente los pasos de los procesos comerciales. Para combinar actividades primitivas, BPEL admite varias estructura ocupaciones. Los mas importantes son

  • Secuencia( <sequence>), que nos permite definir un conjunto de actividades que serán invocadas en una secuencia ordenada
  • Fluir ( <flow>) para definir un conjunto de actividades que se invocarán en paralelo
  • Construcción de cambio de caso( <switch>) para implementar sucursales
  • Tiempo ( <while>) para definir bucles
  • La capacidad de seleccionar una de varias rutas alternativas, utilizando <pick>

Cada proceso BPEL también definirá enlaces de socios, usando , y declarará variables, usando .

Para comprender cómo se describen los procesos comerciales con BPEL, definirá un proceso comercial simplificado en exceso para los arreglos de viaje de los empleados: el cliente invoca el proceso comercial, especificando el nombre del empleado, el destino, la fecha de salida y la fecha de regreso. El proceso comercial de BPEL primero verifica el estado de viaje del empleado, asumiendo que existe un servicio web a través del cual se pueden realizar dichas verificaciones. Luego, el proceso BPEL verificará el precio del boleto aéreo con dos aerolíneas: American Airlines y Delta Airlines. Una vez más, suponga que ambas compañías aéreas ofrecen un servicio web a través del cual se pueden realizar dichas comprobaciones. Finalmente, el proceso BPEL seleccionará el precio más bajo y devolverá el plan de viaje al cliente.

Luego, construiremos un proceso BPEL asincrónico. Asumiremos que el servicio web para verificar el estado de viaje de los empleados es sincrónico. Esto es razonable porque estos datos pueden obtenerse inmediatamente y devolverse a la persona que llama. Para adquirir los precios de los billetes de avión utilizamos invocaciones asincrónicas. Nuevamente, este es un enfoque razonable, porque podría tomar un poco más de tiempo confirmar el horario de viaje en avión. Suponemos que ambas aerolíneas ofrecen un servicio web y que ambos servicios web son idénticos (es decir, proporcionan tipos de puertos y operaciones iguales) para simplificar nuestro ejemplo.

En escenarios del mundo real, normalmente no tendrá la opción de elegir los servicios web, pero tendrá que utilizar los servicios que le proporcionen sus socios. Si tiene el lujo de diseñar los servicios web y el proceso BPEL al mismo tiempo, querrá considerar qué interfaz es mejor. Por lo general, utilizará servicios asincrónicos para operaciones de larga duración y servicios síncronos para operaciones que devuelven un resultado en un tiempo relativamente corto. Si utiliza servicios web asincrónicos, el proceso BPEL también suele ser asincrónico.

Cuando define un proceso empresarial en BPEL, básicamente define un nuevo servicio web que es un compuesto de servicios existentes. La interfaz del nuevo servicio web compuesto BPEL utiliza un conjunto de tipos de puertos a través de los cuales proporciona operaciones como cualquier otro servicio web. Para invocar un proceso empresarial descrito en BPEL, debe invocar el servicio web compuesto resultante. La figura 3 muestra una vista esquemática de nuestro proceso.

127166

Figura 3: Ejemplo de proceso BPEL para arreglos de viaje

Al desarrollar el proceso BPEL de muestra, pasará por los siguientes pasos:

  • Familiarícese con los servicios web involucrados
  • Definir el WSDL para el proceso BPEL
  • Definir tipos de enlaces de socios
  • Desarrollar el proceso BPEL:
    • Definir enlaces de socios
    • Declarar variables
    • Escriba la definición de la lógica del proceso.

Paso 1: Inventario de los servicios web involucrados

Antes de que pueda comenzar a escribir la definición del proceso BPEL, debe familiarizarse con los servicios web invocados desde nuestro proceso comercial. Estos servicios se llaman servicios web asociados. Este ejemplo tiene el servicio web Employee Travel Status y el servicio web American y Delta Airlines, que tienen descripciones WSDL idénticas. (Nuevamente, los servicios web utilizados en este ejemplo son ficticios).

Servicio web de estado de viaje de empleados. El servicio web Employee Travel Status proporciona la EmployeeTravelStatusPTtipo de puerto a través del cual se puede verificar el estado de viaje del empleado con el EmployeeTravelStatus operation . La operación devolverá la clase de viaje que puede usar un empleado, que puede ser económica, ejecutiva o primera. (Ver Figura 4.)

106665

Figura 4: El servicio web Employee Travel Status

Servicio web de aerolínea. El servicio Web de la aerolínea es asíncrono; por lo tanto, especifica dos tipos de puertos: el primero,
FlightAvailabilityPT, se utiliza para comprobar la disponibilidad de vuelos mediante el FlightAvailability operación. Para devolver el resultado, el servicio web especifica el segundo tipo de puerto, FlightCallbackPT. Este tipo de puerto especifica el FlightTicketCallback operación.

Aunque el servicio web de la aerolínea define dos tipos de puertos, solo implementa el FlightAvailabilityPT. FlightCallbackPT es implementado por el proceso BPEL, que es el cliente del servicio web. La arquitectura de la Web …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

1VBzHyEfBO4qbicARe MKAA

Un consejo importante sobre la trama de Seaborn que desearía haber aprendido antes

Método JavaScript String indexOf ()