El lenguaje de ejecución de procesos de negocios de servicios web ( WS-BPEL ), comúnmente conocido como BPEL ( lenguaje de ejecución de procesos de negocios ), es un lenguaje ejecutable estándar de OASIS [1] para especificar acciones dentro de procesos de negocios con servicios web . Los procesos en BPEL exportan e importan información utilizando exclusivamente interfaces de servicios web.
Se pueden describir las interacciones entre servicios web de dos maneras: como procesos de negocio ejecutables y como procesos de negocio abstractos.
WS-BPEL tiene como objetivo modelar el comportamiento de los procesos, [2] a través de un lenguaje para la especificación de procesos de negocio tanto ejecutables como abstractos. Al hacerlo, amplía el modelo de interacción de los servicios web y le permite soportar transacciones comerciales. También define un modelo de integración interoperable que debería facilitar la expansión de la integración de procesos automatizados tanto dentro como entre empresas. Su desarrollo surgió de la noción [3] de que la programación en grande y la programación en pequeño requerían diferentes tipos de lenguajes.
Como tal, está serializado en XML y tiene como objetivo permitir la programación a gran escala.
Los conceptos de programación en grande y programación en pequeña distinguen entre dos aspectos de la escritura del tipo de procesos asincrónicos de larga duración que normalmente se ven en los procesos de negocios:
Los orígenes de WS-BPEL se remontan a Web Services Flow Language (WSFL) y Xlang .
En 2001, IBM y Microsoft habían definido cada uno sus propios lenguajes de " programación en los grandes " bastante similares: WSFL [4] ( Web Services Flow Language ) y Xlang , [5] respectivamente. Microsoft incluso siguió adelante y creó una variante de secuencia de comandos llamada XLANG/s que luego serviría como base para sus servicios de orquestaciones dentro de su BizTalk Server. Documentaron específicamente que este lenguaje "es propietario y no está completamente documentado". [6]
Con el advenimiento y la popularidad de BPML , y el creciente éxito de BPMI.org y el movimiento BPMS abierto liderado por JBoss e Intalio Inc., IBM y Microsoft decidieron combinar estos lenguajes en un nuevo lenguaje, BPEL4WS. En abril de 2003, BEA Systems , IBM, Microsoft, SAP y Siebel Systems presentaron BPEL4WS 1.1 a OASIS para su estandarización a través del Comité Técnico de Servicios Web BPEL. [7] Aunque BPEL4WS apareció como versión 1.0 y 1.1, el comité técnico de OASIS WS-BPEL votó [8] el 14 de septiembre de 2004 para nombrar su especificación "WS-BPEL 2.0". (Este cambio de nombre alineó a BPEL con otras convenciones de nomenclatura estándar de servicios web que comienzan con "WS-" (similar a WS-Security) y tuvo en cuenta las mejoras significativas realizadas entre BPEL4WS 1.1 y WS-BPEL 2.0). En una versión específica, el apodo BPEL se usa comúnmente [ cita necesaria ] .
En junio de 2007, Active Endpoints, Adobe Systems , BEA, IBM, Oracle y SAP publicaron las especificaciones BPEL4People y WS-HumanTask, que describen cómo se puede implementar la interacción humana en los procesos BPEL. [ cita necesaria ]
Había diez objetivos de diseño originales asociados con BPEL:
BPEL es un lenguaje de orquestación y no un lenguaje de coreografía . La principal diferencia entre orquestación y coreografía es la ejecutabilidad y el control. Una orquestación especifica un proceso ejecutable que implica intercambios de mensajes con otros sistemas, de modo que las secuencias de intercambio de mensajes están controladas por el diseñador de la orquestación. Una coreografía especifica un protocolo para interacciones entre pares, definiendo, por ejemplo, las secuencias legales de mensajes intercambiados con el fin de garantizar la interoperabilidad. Un protocolo de este tipo no es directamente ejecutable, ya que permite muchas realizaciones diferentes (procesos que lo cumplen). Se puede realizar una coreografía escribiendo una orquestación (por ejemplo, en forma de proceso BPEL) para cada compañero involucrado en ella. Las distinciones entre orquestación y coreografía se basan en analogías: la orquestación se refiere al control central (por parte del director) del comportamiento de un sistema distribuido (la orquesta compuesta por muchos músicos), mientras que la coreografía se refiere a un sistema distribuido (el equipo de baile). que opera según reglas (la coreografía) pero sin control centralizado.
El enfoque de BPEL en los procesos comerciales modernos, además de las historias de WSFL y XLANG, llevaron a BPEL a adoptar servicios web como mecanismo de comunicación externa. Por lo tanto, las funciones de mensajería de BPEL dependen del uso del lenguaje de descripción de servicios web (WSDL) 1.1 para describir los mensajes entrantes y salientes.
Además de proporcionar funciones para permitir el envío y la recepción de mensajes, el lenguaje de programación BPEL también admite:
No existe una notación gráfica estándar para WS-BPEL, ya que el comité técnico de OASIS decidió que estaba fuera de alcance. Algunos proveedores han inventado sus propias notaciones. Estas notaciones aprovechan el hecho de que la mayoría de las construcciones en BPEL están estructuradas en bloques (p. ej., secuencia, while, selección, alcance, etc.). Esta característica permite una representación visual directa de las descripciones de procesos BPEL en forma de estructuragramas , en un estilo que recuerda a un diagrama de Nassi-Sneiderman .
Otros han propuesto utilizar un lenguaje de modelado de procesos de negocio sustancialmente diferente, a saber, Notación y Modelo de Procesos de Negocio (BPMN), como interfaz gráfica para capturar descripciones de procesos BPEL. Como ilustración de la viabilidad de este enfoque, la especificación BPMN incluye un mapeo informal y parcial [10] de BPMN a BPEL 1.1. Se ha implementado un mapeo más detallado de BPMN a BPEL en varias herramientas, incluida una herramienta de código abierto conocida como BPMN2BPEL. [11] Sin embargo, el desarrollo de estas herramientas ha expuesto diferencias fundamentales entre BPMN y BPEL, que hacen que sea muy difícil, y en algunos casos imposible, generar código BPEL legible por humanos a partir de modelos BPMN. Aún más difícil es el problema de la ingeniería de ida y vuelta de BPMN a BPEL : generar código BPEL a partir de diagramas BPMN y mantener sincronizados el modelo BPMN original y el código BPEL generado, en el sentido de que cualquier modificación en uno se propaga al otro. [ cita necesaria ]
Las estructuras de control de BPEL, como 'si-entonces-elseif-else' y 'mientras', así como sus funciones de manipulación de variables, dependen del uso de 'programación en lenguajes pequeños' para proporcionar lógica. Todas las implementaciones de BPEL deben admitir XPath 1.0 como idioma predeterminado. Pero el diseño de BPEL prevé la extensibilidad para que los creadores de sistemas puedan utilizar también otros lenguajes. BPELJ [12] es un esfuerzo relacionado con JSR 207 [13] que puede permitir que Java funcione como un lenguaje de 'programación en pequeño' dentro de BPEL.
A pesar de la amplia aceptación de los servicios web en aplicaciones comerciales distribuidas, la ausencia de interacciones humanas fue una brecha significativa para muchos procesos comerciales del mundo real.
Para llenar este vacío, BPEL4People amplió BPEL de la orquestación de servicios web únicamente a la orquestación de actividades humanas basadas en roles también.
En el contexto de un proceso de negocio BPEL4People
ampliando BPEL con sintaxis y semántica independientes adicionales.
La especificación WS-HumanTask introduce la definición de tareas humanas y notificaciones, incluidas sus propiedades, comportamiento y un conjunto de operaciones utilizadas para manipular tareas humanas. Se introduce un protocolo de coordinación para controlar la autonomía y el ciclo de vida de las tareas humanas habilitadas por servicios de manera interoperable.
La especificación BPEL4People introduce una extensión WS-BPEL para abordar las interacciones humanas en WS-BPEL como ciudadano de primera clase . Define un nuevo tipo de actividad básica que utiliza tareas humanas como implementación y permite especificar tareas locales para un proceso o utilizar tareas definidas fuera de la definición del proceso. Esta extensión se basa en la especificación WS-HumanTask.
La versión 2.0 introdujo algunos cambios y nuevas características:
{{cite journal}}
: Citar diario requiere |journal=
( ayuda ){{cite web}}
: CS1 maint: archived copy as title (link)