Lenguaje de ejecución de procesos de negocio

Este artículo tiene varios problemas. Ayúdenos a mejorarlo o a discutir estos problemas en la página de discusión . ( Aprenda cómo y cuándo eliminar estos mensajes ) This article may require cleanup to meet Wikipedia's quality standards. The specific problem is: reihbase on refs, other issues tagged. Please help improve this article if you can. (July 2016) (Learn how and when to remove this message) This article relies excessively on references to primary sources. Please improve this article by adding secondary or tertiary sources. Find sources: "Business Process Execution Language" – news · newspapers · books · scholar · JSTOR (October 2012) (Learn how and when to remove this message) (Learn how and when to remove this message)

El lenguaje de ejecución de procesos de negocio de servicios web ( WS-BPEL ), comúnmente conocido como BPEL ( Business Process Execution Language ), es un lenguaje ejecutable estándar de OASIS ^[1] para especificar acciones dentro de procesos de negocio con servicios web . Los procesos en BPEL exportan e importan información utilizando exclusivamente interfaces de servicios web.

Las interacciones de servicios web se pueden describir de dos maneras: como procesos de negocio ejecutables y como procesos de negocio abstractos.

1. Un proceso empresarial ejecutable : modela el comportamiento real de un participante en una interacción empresarial.
2. Un proceso empresarial abstracto es un proceso parcialmente especificado que no está destinado a ser ejecutado. A diferencia de los procesos ejecutables, un proceso abstracto puede ocultar algunos de los detalles operativos concretos requeridos. Los procesos abstractos cumplen una función descriptiva, con más de un posible caso de uso , incluido el comportamiento observable y/o la plantilla de proceso .

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 ejecutables y abstractos. De esta manera, extiende el modelo de interacción de los servicios web y le permite dar soporte a las 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 de las empresas como entre ellas. Su desarrollo surgió de la noción ^[3] de que la programación a gran escala y la programación a pequeña escala requerían diferentes tipos de lenguajes.

Como tal, se serializa en XML y tiene como objetivo permitir la programación a gran escala.

Los conceptos de programación a lo grande y programación a lo pequeño distinguen dos aspectos de la escritura del tipo de procesos asincrónicos de larga ejecución que uno suele ver en los procesos de negocios:

1. La programación a gran escala generalmente se refiere a las interacciones de transición de estado de alto nivel de un proceso. BPEL se refiere a este concepto como un proceso abstracto. Un proceso abstracto BPEL representa un conjunto de comportamientos observables públicamente de manera estandarizada. Un proceso abstracto incluye información como cuándo esperar mensajes , cuándo enviar mensajes, cuándo compensar transacciones fallidas, etc.
2. La programación a pequeña escala , por el contrario, se ocupa de un comportamiento programático de corta duración, a menudo ejecutado como una sola transacción e involucra acceso a lógica y recursos locales como archivos , bases de datos , etcétera.

Los orígenes de WS-BPEL se remontan a Web Services Flow Language (WSFL) y Xlang .

En 2001, IBM y Microsoft definieron sus propios lenguajes de programación bastante similares, "a lo grande ": WSFL ^[4] ( Web Services Flow Language ) y Xlang [ ^5] , respectivamente. Microsoft incluso siguió adelante y creó una variante de scripting llamada XLANG/s que luego serviría como base para sus servicios de orquestación dentro de su servidor BizTalk. Documentaron específicamente que este lenguaje "es propietario y no está completamente documentado". ^[6]

Con la llegada y 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 WS-BPEL de OASIS 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 nombres 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). Si no se habla de una versión específica, el apodo BPEL se usa comúnmente ^{[ cita requerida ]} .

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 requerida ]}

Había diez objetivos de diseño originales asociados con BPEL:

1. Define procesos de negocio que interactúan con entidades externas a través de operaciones de servicios web definidas mediante el lenguaje de descripción de servicios web (WSDL) 1.1 y que se manifiestan como servicios web definidos mediante WSDL 1.1. Las interacciones son "abstractas" en el sentido de que la dependencia se basa en definiciones de portType, no en definiciones de puerto.
2. Defina los procesos de negocio utilizando un lenguaje basado en XML. No defina una representación gráfica de los procesos ni proporcione ninguna metodología de diseño particular para los mismos. ^[9]
3. Defina un conjunto de conceptos de orquestación de servicios web que se supone que deben ser utilizados tanto por las vistas externas (abstractas) como internas (ejecutables) de un proceso de negocios. Un proceso de negocios de este tipo define el comportamiento de una única entidad autónoma, que normalmente opera en interacción con otras entidades similares. Se reconoce que cada patrón de uso (es decir, vista abstracta y vista ejecutable) requerirá algunas extensiones especializadas, pero estas extensiones deben mantenerse al mínimo y probarse en relación con requisitos como la importación/exportación y la comprobación de conformidad que vinculan los dos patrones de uso.
4. Proporcionar regímenes de control tanto jerárquicos como de tipo gráfico, y permitir que su uso se combine de la forma más fluida posible. Esto debería reducir la fragmentación del espacio de modelado de procesos.
5. Proporcionar funciones de manipulación de datos para la manipulación simple de datos necesarios para definir datos de proceso y controlar el flujo.
6. Admitir un mecanismo de identificación para instancias de proceso que permita la definición de identificadores de instancia en el nivel de mensaje de la aplicación. Los identificadores de instancia deben ser definidos por los socios y pueden cambiar.
7. Admite la creación y finalización implícitas de instancias de procesos como mecanismo básico del ciclo de vida. Es posible que en futuras versiones se agreguen operaciones avanzadas del ciclo de vida, como "suspender" y "reanudar", para mejorar la gestión del ciclo de vida.
8. Definir un modelo de transacciones de larga duración que se base en técnicas probadas, como acciones de compensación y alcance, para respaldar la recuperación de fallas en partes de procesos comerciales de larga duración.
9. Utilice servicios web como modelo para la descomposición y ensamblaje de procesos.
10. Desarrollar estándares de servicios web (aprobados y propuestos) tanto como sea posible de manera componible y modular.

BPEL es un lenguaje de orquestación , no 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). Una coreografía se puede realizar escribiendo una orquestación (por ejemplo, en forma de un proceso BPEL) para cada par 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 formada por muchos intérpretes), mientras que la coreografía se refiere a un sistema distribuido (el equipo de baile) que funciona según reglas (la coreografía) pero sin control centralizado.

El enfoque de BPEL en los procesos de negocios modernos, junto con las historias de WSFL y XLANG, llevaron a BPEL a adoptar los servicios web como su mecanismo de comunicación externo. 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 facilidades para enviar y recibir mensajes, el lenguaje de programación BPEL también admite:

• Un mecanismo de correlación de mensajes basado en propiedades
• Variables tipificadas en XML y WSDL
• Un modelo de complemento de lenguaje extensible que permite escribir expresiones y consultas en varios idiomas: BPEL admite XPath 1.0 de forma predeterminada
• Construcciones de programación estructurada que incluyen if-then-elseif-else, while, secuencia (para permitir la ejecución de comandos en orden) y flujo (para permitir la ejecución de comandos en paralelo)
• Un sistema de alcance que permite la encapsulación de la lógica con variables locales , controladores de fallas , controladores de compensación y controladores de eventos.
• Ámbitos serializados para controlar el acceso concurrente a las variables .

No existe una notación gráfica estándar para WS-BPEL, ya que el comité técnico de OASIS decidió que esto estaba fuera del 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 (por ejemplo, secuencia, mientras, selección, alcance, etcétera). Esta característica permite una representación visual directa de las descripciones de procesos de BPEL en forma de estructogramas , en un estilo que recuerda a un diagrama de Nassi-Shneiderman .

Otros han propuesto utilizar un lenguaje de modelado de procesos de negocio sustancialmente diferente, a saber, Business Process Model and Notation (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 para 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 a uno se propaga al otro. ^{[ cita requerida ]}

Las estructuras de control de BPEL, como 'if-then-elseif-else' y 'while', así como sus facilidades de manipulación de variables, dependen del uso de lenguajes de 'programación en pequeño' para proporcionar lógica. Todas las implementaciones de BPEL deben soportar XPath 1.0 como lenguaje predeterminado. Pero el diseño de BPEL prevé la extensibilidad para que los desarrolladores de sistemas también puedan usar 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 importante para muchos procesos comerciales del mundo real.

Para llenar este vacío, BPEL4People extendió BPEL desde 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

• Apoya la interacción de las personas basada en roles
• Proporciona medios para asignar a los usuarios roles humanos genéricos.
• se encarga de delegar la propiedad de una tarea a una sola persona
• apoya el escenario como
  • escenario de cuatro ojos
  • nominación
  • escalada
  • ejecución encadenada

ampliando BPEL con sintaxis y semántica independientes adicionales.

La especificación WS-HumanTask introduce la definición de tareas y notificaciones humanas, 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 para servicios de manera interoperable.

La especificación BPEL4People introduce una extensión WS-BPEL para abordar las interacciones humanas en WS-BPEL como ciudadanos de primera clase . Define un nuevo tipo de actividad básica que utiliza tareas humanas como implementación y permite especificar tareas locales a 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:

• Nuevos tipos de actividad: repeatUntil, validar, forEach (paralelo y secuencial), rethrow, extensionActivity, compensationScope
• Actividades renombradas: switch/case renombrado a if/else, ends renombrado a exit
• Se agregó un controlador de terminación a las actividades del ámbito para proporcionar un comportamiento explícito para la terminación
• Inicialización de variables
• XSLT para transformaciones de variables (Nueva función de extensión XPath bpws:doXslTransform)
• Acceso XPath a datos variables (sintaxis de variable XPath $variable[.part]/location)
• Variables de esquema XML en actividades de servicios web (para interacciones de servicios de estilo WS-I doc/lit)
• MessageExchange declarado localmente (correlación interna de las actividades de recepción y respuesta)
• Clarificación de procesos abstractos (sintaxis y semántica)
• Habilitar anulaciones del lenguaje de expresión en cada actividad

• BPEL4Personas
• Script BPEL
• Modelo y notación de procesos de negocio
• Modelado de procesos de negocio
• Lista de motores BPEL
• Lenguaje de conversación de servicios web
• Flujo de trabajo
• Licencia de conducir comercial de Washington
• Lenguaje de definición de procesos XML
• Otro lenguaje de flujo de trabajo

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Business Process Execution Language" – news · newspapers · books · scholar · JSTOR (October 2008) (Learn how and when to remove this message)

Libros sobre BPEL 2.0

• SOA para desarrolladores de negocios: conceptos, BPEL y SCA . ISBN 978-1-58347-065-7