BPEL

(Web Services BPEL) Business Process Execution Language

(Lenguaje de Ejecución de Procesos de Negocio con Servicios Web), es un lenguaje estandarizado por OASIS para la composición de servicios web. Está desarrollado a partir de WSFL y XLANG, ambos lenguajes orientados a la descripción de servicios Web. Básicamente, consiste en un lenguaje basado en XML diseñado para el control centralizado de la invocación de diferentes servicios Web, con cierta lógica de negocio añadida que ayuda a la programación en gran escala (programming in the large). Antes de su estandarización se denominaba BPEL4WS.
La mayor diferencia entre ambos es el ámbito. Un modelo de orquestación provee un ámbito específicamente enfocado en la vista de un participante en particular (ej: un modelo par-a-par). En cambio, un modelo coreográfico abarca todos los participantes y sus interacciones asociadas, dando una vista global del sistema. Las diferencias entre orquestación y coreografía están basadas en analogías: la orquestación describe un control central del comportamiento como un director de orquesta, mientras que la coreografía trata sobre el control distribuido del comportamiento donde participantes individuales realizan procesos basados en eventos externos, como en una danza coreográfica donde los bailarines reaccionan a los comportamientos de sus pares.
A través de un documento XML BPEL, un analista de negocio es capaz de representar la lógica asociada y los elementos con los que se verá relacionado. Estos elementos serán servicios Web y la lógica el proceso BPEL.
Si imaginamos un flujo de negocio determinado, con una entrada A y una salida Z, este se podría componer de muchos procesos internos que se lanzarían dependiendo de valores y respuestas anteriores. BPEL sería el encargado de orquestar todo el proceso ordenando qué proceso ejecutar (servicio Web) y en qué momento.


Objetivos del Diseño BPEL 
  1. Definir procesos de negocio que interactúan con entidades externas mediante operaciones de un servicio Web definidas usando WSDL 1.1 y que se manifiestan a sí mismas como servicios Web.
  2. Definir procesos de negocio utilizando un lenguaje basado en XML. No definir una interpretación gráfica de procesos o proveer de una metodología de diseño en particular.
  3. Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio.
  4. Proveer sistemas de control jerárquicos y de estilo gráfico, que permitan que su uso sea lo más fusionado e inconsútil posible. Esto reduciría la fragmentación del espacio del modelado de procesos.
  5. Proveer funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control.
  6. Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. Los identificadores de instancias deben ser definidos por socios y pueden cambiar.
  7. Brindar la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida. Operaciones avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar" pueden agregarse en futuras versiones para mejorar el manejo del ciclo de vida.
  8. Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera a brindar recuperación a fallos para partes de procesos de negocios de largo plazo.
  9. Usar servicios Web como modelo para la descomposición y ensamblaje de procesos.
  10. Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y extensible.





¿Qué es un proceso BPEL Síncrono?

Utilizando la construcción <invoque> podemos invocar ambos tipos de operaciones: síncronas y asíncronas. Si invocamos una operación síncrona, el proceso de negocio se espera hasta recibir la respuesta (en este caso, tenemos que incluir el atributo con el mensaje de respuesta). No necesitamos utilizar una construcción especial para recuperar la respuesta.
Ejemplo de invocación síncrona:
1
2
3
4
5
6
<!--invocación SINCRONA sobre el servicio Employee Travel Status-->
<invoke partnerLink="employeeTravelStatus"
        portType="emp:EmployeeTravelStatusPT"
        operation="EmployeeTravelStatus"
        inputVariable="EmployeeTravelStatusRequest"
        outputVariable="EmployeeTravelStatusResponse" />


¿Qué es un proceso BPEL Asíncrono?


Con las operaciones asíncronas, la construcción <invoque> solamente realiza la primera parte de la llamada, la que invoca la operación. Para recibir un resultado (si es que se devuelve al cliente), necesitamos utilizar una construcción separada <receive>. Con <receive>, el proceso de negocio esperará la respuesta. Entre las operaciones <invoque> y <receive> podríamos realizar cualquier otro procesamiento en lugar de esperar la respuesta, tal y como ocurre en una invocación síncrona. El esquema para una invocación de una operación asíncrona es:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<!-- Invocación asíncrona -->
<process ...>
  ...
  <sequence>
     <!-- espera a una petición para comenzar el proceso -->
     <receive.../>
     <!-- invoca una operación asíncrona -->
     <invoque .../>
      
     <!-- hacer algo -->    
     <!-- esperar el Callback-->    
     <receive.../>
     ...
  </sequence>
</process>     







Enlaces a Sitios WEB
Enlace #1

Enlace #2

Comentarios

Publicar un comentario