Desarrollo de un Traductor de BPEL4WS a YAWL
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Desarrollo de un Traductor de BPEL4WS a YAWL
Ingeniería de Software y Sistemas de Información
Gregorio López-López y Luciano García-Bañuelos
Universidad Autónoma de Tlaxcala
Departamento de Ciencias Básicas, Ingeniería y Tecnología
Calzada de Apizaquito s/n, Apizaco Tlaxcala, México.
lo_lo_gre@yahoo.com.mx lgarcia@ingenieria.uatx.mx
Resumen. BPEL4WS (o BPEL) es un lenguaje para la integración de
aplicaciones en el contexto de los Servicios Web. Resultado de la fusión de
XLang y WSFL, este carece sin embargo de fundamentos formales que
permitan el desarrollo de herramientas de verificación y simulación. Así, nos
interesamos en desarrollar un mecanismo sistematizado para traducir procesos
BPEL a YAWL. YAWL es un lenguaje derivado de Redes de Petri, con una
notación compacta y con operadores avanzados que lo hacen presumiblemente
más apropiado. En este artículo, presentamos un primer avance en el desarrollo
del mecanismo de traducción, en el que no se incluyen todas las características
de BPEL. Un prototipo nos ha permitido verificar la viabilidad de la traducción,
además de su utilidad.
Palabras clave: BPEL4WS, YAWL, Integración de aplicaciones, Workflow,
Redes de Petri.
1 Introducción
El uso de las tecnologías de Workflow en la integración de aplicaciones ha captado
gran interés en las comunidades industriales y académicas. Esto es evidente, de manera
particular, en el área de los Servicios Web con la aparición de lenguajes tales como
XLang [11] y WSFL [5] propuestos por Microsoft e IBM, respectivamente. La alianza
de estos dos industriales dio lugar a un nuevo lenguaje llamado BPEL4WS [1] (o
BPEL), que es resultado de una fusión de sus predecesores. Este lenguaje ha sido
aceptado como estándar de facto y sigue en este momento un proceso para su
estandarización formal por OASIS.
Uno de las deficiencias en el documento de la especificación de BPEL es la falta de
una descripción formal de su semántica. El documento sólo hace una descripción en
inglés, complementada por ejemplos. Se ha reconocido la expresividad de BPEL pero,
de igual manera, los problemas de ambigüedad en el lenguaje. Esto se atribuye a la
combinación de los dos lenguajes predecesores y particularmente a la
complementariedad de sus construcciones. Así, se ha demostrado que un mismo
problema puede ser escrito de múltiples maneras y la equivalencia no fácil de
evidenciar. La preocupación más importante es, sin embargo, la falta unaespecificación de la semántica operacional que permitiría el desarrollo de herramientas de verificación y simulación de procesos escritos en BPEL. Se han reportado ya algunos trabajos con una semántica operacional para BPEL. Nosotros apostamos al uso de YAWL, como lenguaje para el desarrollo de tal semántica operacional. YAWL [12] es un lenguaje basado en Redes de Petri que, sin embargo, tiene una notación compacta y construcciones avanzadas que la hacen más apropiada. En este artículo, presentamos el desarrollo del mecanismo de traducción de BPEL a YAWL, en el que no se incluyen todas las características de BPEL. Un prototipo nos ha permitido verificar la viabilidad de la traducción, además de su utilidad. El resto del documento está organizado de la siguiente manera. La sección 2 presenta algunos trabajos relacionados. Las secciones 3 y 4 describen brevemente los lenguajes BPEL y YAWL, respectivamente. La sección 5 da algunos ejemplos de equivalencias entre ambos lenguajes. La sección 6 describe brevemente nuestro método de traducción. La sección 7 describe la arquitectura y la implementación de un traductor y la sección 8 presenta algunas pruebas realizadas al mismo. La sección 9 concluye y esboza los trabajos futuros. 2 Trabajos relacionados Al momento, pocos han sido los trabajos que reportan algún mecanismo para la verificación de procesos descritos en BPEL. Christian Stahl [10] propone una semántica operacional para BPEL basada en redes de Petri [7], misma que permite traducir procesos BPEL a Redes de Petri siguiendo un conjunto de patrones. Los autores reportan en [9] un caso de estudio en el que un proceso de compras descrito en BPEL es transformado en una Red de Petri con 158 lugares y 259 transiciones. La red resultante fue pasada a una herramienta llamada LoLA [8] en la que los autores realizaron una verificación del proceso. Farahbod y col. [2] proponen usar las Máquinas de Estado Abstractas (ASM, del inglés Abstract State Machines) como formalismo para describir la semántica operacional de BPEL. Para su verificación, las máquinas ASM pueden ser traducidas a máquinas de estado finito que, a su vez, pueden ser verificadas y simuladas. El artículo [2] describe un ejercicio en el que los autores traducen un proceso BPEL en ASM y posteriormente la simulan en el ambiente ASML. Los autores no dan detalles sobre el proceso de traducción de los procesos BPEL a ASM. A partir de estas experiencias, nos interesamos en la definición e implementación de un traductor de procesos BPEL a YAWL. Consideramos que el uso de YAWL es conveniente, ya que su notación es compacta y el uso de la construcción “cancelación” de YAWL (que elimina los tokens en una subred de Petri) podría ofrecer una ventaja con respecto a las redes de Petri.
3 Lenguaje YAWL
YAWL [12] (del inglés Yet Another Workfow Languaje) es un lenguaje para la
definición de flujos de trabajo. YAWL es un lenguaje formal basado en redes de Petri.
En YAWL, toda definición de flujo de trabajo está compuesta de tareas y condiciones:
• Una tarea es una representación abstracta de un trabajo a realizar (e.g.
invocación de una operación de un servicio Web).
• Una condición es un requisito que se debe cumplir para poder continuar con el
flujo de trabajo (e.g. que una tarea previa se haya completado).
En la Tabla 1 se presentan algunos de los símbolos utilizados en YAWL para
modelar flujos de trabajo, con una breve descripción de ellos. Para una descripción
detallada se puede consultar [12].
Nombre y Símbolo Descripción
Condición de Entrada Marca el inicio de un flujo de trabajo.
Condición de Salida Marca el fin de un flujo de trabajo.
Tarea Atómica Representa una tarea.
Especifica que una vez completada la tarea todas las tareas
Tarea AND-Split
subsecuentes podrán ejecutarse.
Especifica que una vez completada la tarea sólo una tarea
Tarea XOR-Split
subsecuente podrá ejecutarse.
Especifica que una vez completada la tarea una o más
Tarea OR-Split
tareas subsecuente podrán ejecutarse.
Especifica que la tarea se ejecutará sólo cuando todas sus
Tarea AND-Join
tareas precedentes se hayan completado.
Especifica que la tarea se ejecutará una vez que una de las
Tarea XOR-Join
tareas precedentes se complete.
Especifica que la tarea se ejecutará sólo cuando todas las
Tarea OR-Join
tareas previamente activadas se completen.
Tabla 1. Elementos del lenguaje gráfico de YAWL.
4 Lenguaje BPEL4WS
BPEL4WS o simplemente BPEL [1] (del inglés Business Process Execution Lenguaje
for Web Services) es un lenguaje para la definición de procesos de negocios. BPEL es
un lenguaje basado en XML. En BPEL, un proceso está compuesto de un conjunto de
actividades básicas y/o estructuradas:
• Una actividad básica especifica una acción a realizar (e.g. invocar una
operación de un Servicio Web).• Una actividad estructurada establece el orden de ejecución de otras
actividades.
En la Tabla 2 se presentan las actividades básicas y en la Tabla 3 las actividades
estructuradas utilizadas en BPEL, así como una breve descripción de las mismas. Para
una descripción detallada se puede consultar [1].
Elemento XML Descripción
Recibe la invocación de una operación.
. Envía una respuesta a una invocación (i.e. recibida con .
Invoca una operación sobre algún Servicio Web.
Asigna valores a variables, o bien, copia valores de una variable a otra.
Lanza una falla o excepción.
Termina explícitamente un proceso.
Detiene el proceso durante un periodo de tiempo.
Actividad nula (no tiene ninguna efecto asociado).
Invoca la compensación de un ámbito.
Tabla 2. Actividades básicas de BPEL.
Elemento XML Descripción
Define un conjunto de actividades que se ejecutarán secuencialmente.
Define un conjunto de actividades que se ejecutarán en paralelo. Al
interior de esta construcción, es posible definir ligas (i.e. ). Las
ligas pueden especificar un flujo explícito de ejecución.
Selecciona una actividad entre varias posibles en base a una condición.
Ejecuta una actividad repetidas veces, mientras se cumpla una condición.
Ejecuta una actividad entre varias posibles después de la activación de
una alarma, o bien, de la recepción de un mensaje.
Define un ámbito. Este tiene asociado un conjunto de variables, de
manejadores de fallos y de compensación locales.
Tabla 3. Actividades estructuradas de BPEL.
5 Equivalencias entre BPEL y YAWL
Después de analizar brevemente ambos lenguajes, se hacen evidentes algunas
equivalencias. Por un lado, una actividad básica de BPEL puede ser representada con
una tarea de YAWL dado que una tarea de YAWL es una representación abstracta de
un trabajo a realizar. Por otro lado, las actividades estructuradas de BPEL se pueden
representar con ligas que unen tareas en YAWL. A continuación se presentan algunos
ejemplos de equivalencia.
Una secuencia de dos actividades BPEL se puede representar con dos tareas
conectadas en un flujo secuencial como es mostrado en la Fig. 1.Secuencia en BPEL Flujo de trabajo en YAWL
A B
Fig. 1. Flujo de Trabajo en YAWL equivalente a una actividad sequence de BPEL.
Una actividad flujo de BPEL, con dos actividades que deben ser ejecutadas en
paralelo se puede representar en YAWL con las tareas correspondientes entre tareas
AND-Split y AND-Join, como es mostrado en la Fig. 2.
Flujo en BPEL Flujo de trabajo en YAWL
A
B
Fig. 2. Flujo de Trabajo en YAWL equivalente a una actividad flow de BPEL.
Para mostrar la versatilidad de BPEL, en la Fig. 3 se muestra como el flujo inducido
por ligas explícitas en una actividad flow, lleva a un flujo secuencial. Es esta
versatilidad que hace difícil el análisis de procesos BPEL.
Secuencia en BPEL Flujo de trabajo en YAWL
A B
Fig. 3. Flujo de Trabajo en YAWL equivalente a una actividad flujo con ligas.
6 Método de Traducción
La traducción de actividades básicas BPEL a tareas YAWL se hace de manera directa,
estableciendo una correspondencia uno a uno. En cuanto a las actividades
estructuradas, se aplica de manera recursiva la traducción de cada actividad
estructurada siguiendo el orden impuesto por la anidación de las actividades
estructuradas.
Un aspecto crucial es el de determinar la conexión de las ligas de control de flujo en
YAWL. En el caso de una actividad BPEL SEQUENCE, las ligas se acomodan de
manera tal a forzar un flujo secuencial. Este caso es directo. En el caso de actividadesBPEL FLOW, sin embargo, la organización de las ligas de control de flujo se ve
afectado por el uso de ligas explícitas.
Para describir el proceso de traducción, tome como ejemplo el código BPEL en la
Fig. 4, describe la ejecución en paralelo de dos secuencias. Cada secuencia consta a su
vez de dos actividades. Además, una liga define un flujo explícito de control entre la
actividad “A” y la actividad “D”.
Fig. 4. Ejemplo de una actividad BPEL FLOW con ligas explícitas.
La traducción inicia agregando dos tareas: un AND-Split para marcar el inicio del
FLOW y otra AND-Join para marcar fin. Observe que las condiciones de entrada y de
salida están presentes y unidas a las tareas que acabamos de agregar, para completar la
definición del flujo de trabajo.
A C A C
B D B D
(a) (b) (c)
Fig. 5. Fases en la trasformación de un proceso BPEL a un flujo en YAWL.
A continuación, se construyen las dos secuencias. Iniciemos con la secuencia de
actividades “A” y “B”. En primer lugar, se agregan actividades para marcar el inicio y
fin de la secuencia (como para la actividad FLOW). A continuación, se agregan las
tareas atómicas asociadas cada las actividades BPEL “A” y “B”. Todas estas tareas se
unen para formar la secuencia. Este proceso se repite para la secuencia de “C” y “D”,
llegando así al flujo mostrado en la Fig. 5b.Posteriormente, las secuencias son conectadas a las tareas que marcan la entrada y
salida de la actividad FLOW. Finalmente, se agrega la arista que describe la liga de
control explícito. La Fig. 5c corresponde al resultado de la traducción a YAWL para el
ejemplo.
En esta sección, se ha esbozado el método de traducción de un proceso BPEL, a un
flujo en YAWL, mediante un par de ejemplos. En [6] se pueden encontrar la
descripción del método en mayor detalle.
7 Arquitectura e implementación del traductor
La traducción de un proceso en BPEL a un flujo de trabajo equivalente en YAWL se
puede hacer de manera sistematizada. La Fig. 6 muestra la arquitectura del traductor
que desarrollamos en el Lenguaje de programación Java para este propósito.
Proceso en Proceso en
BPEL YAWL
Representación
Árbol equivalente
DOM
Construcción de Generación
Construcción
la representación de código
del árbol
equivalente YAWL
DOM
Fig. 6. Arquitectura del sistema de traducción.
La arquitectura está compuesta de varios módulos. El módulo Construcción del
árbol DOM, toma como entrada un proceso en BPEL y genera una representación de
árbol DOM [4]. En la implementación, se utiliza Apache Xerces [13]. A partir del árbol
DOM, se obtiene la información necesaria para construir una representación
equivalente en YAWL (como descrito en la sección anterior). Tal es el propósito del
módulo Construcción de la representación equivalente. Finalmente, el módulo
Generación de código YAWL, genera el código YAWL en su forma textual XML. El
documento generado puede desplegarse en el motor de ejecución YAWL. La
generación del código es hecha con plantillas para Apache Velocity [3].
8 Evaluación cualitativa
Se hicieron varias pruebas con el traductor propuesto. Se tomaron varios procesos
descritos en BPEL, para cada proceso el traductor generó una representación textual de
un flujo de trabajo en YAWL.
Cada flujo de trabajo generado se desplegó en el motor de ejecución de YAWL y se
simularon algunos casos de prueba. Para todos ellos el comportamiento del proceso en
YAWL fue el esperado. Cabe mencionar que no existe una herramienta para la
generación automática de casos de prueba, lo que facilitaría la evaluación de los flujos
de trabajo generados.9 Conclusiones y Trabajo Futuro
Verificar la corrección de procesos antes de su implementación en un entorno real,
permite detectar y corregir errores. Aunque BPEL ha ganado aceptación, carece de
fundamentos formales que permitan tal verificación. El traductor propuesto representa
una etapa inicial en el desarrollo de un modelo que represente la semántica total de
BPEL. Así, la traducción de algunas características de BPEL, tales como los
manejadores de fallas y compensación, además del manejo de datos, aún no se han
definido.
9 Referencias
[1] F. Curbera y col. Business Process Execution Language for Web Services, version 1.1.
Reporte ténico IBM 2003. Disp. en http://www106.ibm.com/developerworks/library/ws-bpel
[2] R. Farahbod, y col. A Formal Semantics for the Business Process Execution Language for
Web Services. En Web Services and Model-Driven Enterprise Information Systems, pages
144-155, Portugal, May 2005. INSTICC Press.
[3] W. Glass-Husain y col. Apache Velocity template engine, version 1.4. A. S. Foundation, Abril
2004. Disp. en http://jakarta.apache.org/velocity/index.html.
[4] P. Le Hégaret y col. Document Object Model Level 3 Specification. W3C DOM working
group, Octubre 1998. Disp. en http://www.w3.org/DOM/DOMTR#dom3.
[5] F. Leymann y col. Web Services Flow Language (WSFL), version 1.0, Reporte técnico IBM
2001. Disp. en http://www306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.
[6] G. López-López. Desarrollo de un Traductor de BPEL4WS a YAWL. Tesis de Licenciatura.
Universidad Autónoma de Tlaxcala, Agosto 2005.
[7] C.A. Petri. Kommunikation mit Automaten. PhD thesis, Fakutat fur Mathematik und Physik,
Technische Hochschule Darmstadt, Darmstadt, Alemania, 1962.
[8] K. Schmidt. LoLA - A Low Level Analyser. En International Conference on Application and
Theory of Petri Nets, LNCS 1825, page 465 ff. Springer-Verlag, 2000.
[9] K. Schmidt y C. Stahl. A Petri net semantic for BPEL4WS - validation and application. En
Proceedings of the 11th Workshop on Algorithms and Tools for Petri Nets (AWPN'04).
Octubre 2004.
[10] C. Stahl. A Petri Net Semantics for BPEL. Reporte técnico HU-188, Universidad de
Humboldt en Berlin, Julio 2005.
[11] S. Thatte. XLANG: Web Services for Business Process Design. Reporte técnico Microsoft
2001. Disp. en http://www.gotdotnet.com/team/xml_Fwsspecs/xlang-Dc
[12] W.M.P. van der Aalst, A.H.M. ter Hofstede: YAWL: Yet Another Workflow Language,
Versión Revisada. Reporte Técnico FIT-TR-2003-04, Universidad Tecnológica de
Queensland, 2003.
[13] PMC. Apache Xerces XML parser versión 2.6.2. A. S. Foundation, Febrero 2004. Disp.en
http://xml.apache.org/xerces2-j/index.html.También puede leer
