Herramienta para la generación y despliegue de composiciones de servicios Web mediante modelos BPMN

Tesina de máster: Herramienta para la generación y despliegue de composiciones de servicios Web mediante modelos BPMN Javier De La Fuente Sales Julio de 2012, valencia Máster en Ingeniería del Software, Métodos Formales y Sistemas de la Información Director: Vicente Pelechano Ferragud Subdirector: Germán Harvey Alférez Salinas Tabla de contenidos Capítulo 1 Introducción ......................................................................................................... 1 1.1. Motivación................................................................................................................... 2 1.2. Objetivos ..................................................................................................................... 3 1.3. Problemática ............................................................................................................... 4 1.4. Solución propuesta...................................................................................................... 4 1.5. Estructura de la memoria ............................................................................................ 5 Capítulo 2 Visión general de la propuesta ............................................................................ 6 2.1. Conceptos básicos ....................................................................................................... 6 2.1.1. Desarrollo dirigido por modelos .......................................................................... 6 2.1.2. Arquitectura orientada a servicios (SOA) ............................................................ 7 2.1.3. Servicios Web ....................................................................................................... 9 2.1.4. Business Process Modeling Language (BPMN) .................................................. 14 2.1.5. Business Process Execution Language (WS-BPEL) ............................................. 18 2.2. Desarrollo de la propuesta ........................................................................................ 28 2.3. Tecnologías utilizadas................................................................................................ 29 2.3.1. Java ..................................................................................................................... 29 2.3.2. Eclipse ................................................................................................................ 29 2.3.3. JDOM .................................................................................................................. 30 2.3.4. XPATH ................................................................................................................. 30 2.3.5. STP BPMN........................................................................................................... 31 2.3.6. BPEL Designer Project ........................................................................................ 32 2.3.7. Apache ODE ....................................................................................................... 33 2.3.8. EMF project ........................................................................................................ 34 2.3.9. FMF .................................................................................................................... 34 2.3.10. BABEL Tool ...................................................................................................... 35 2.3.11. Axis2 ............................................................................................................... 35 2.3.12. Apache Tomcat ............................................................................................... 36 2.3.13. Hibernate ........................................................................................................ 36 2.3.14. MySQL ............................................................................................................ 36 2.3.15. MySQL Workbench ......................................................................................... 37 Capítulo 3 Generación dirigida por modelos y despliegue en caliente de procesos WSBPEL………………………………………………………………………………………………………………………………….. 38 3.1. Descripción del proceso de transformación de BPMN a WS-BPEL ........................... 38 3.2. Trasformación de BPMN a un WS-BPEL inicial mediante BABEL .............................. 40 3.3. Generación del proceso WS-BPEL completo ............................................................. 42 3.3.1. Metamodelo intermedio ................................................................................... 42 3.3.2. Transformación del WS-BPEL inicial en un modelo intermedio ........................ 48 3.3.3. Edición del modelo intermedio mediante una interfaz ..................................... 49 3.3.4. Transformación del modelo intermedio al WS-BPEL final ................................. 54 3.3.5. Transformación del modelo intermedio al WSDL del proceso .......................... 56 3.3.6. Transformación del modelo intermedio al Deploy.xml ..................................... 59 3.4. Despliegue en caliente .............................................................................................. 61 Capítulo 4 Caso de estudio .................................................................................................. 62 4.1. Descripción General del Caso de Estudio .................................................................. 62 4.2. Requisitos .................................................................................................................. 62 4.3. Modelo BPMN de la agencia de viajes ...................................................................... 64 4.4. Implementación de la propuesta .............................................................................. 68 4.4.1. Servicios Web ..................................................................................................... 69 4.4.2. Composición de servicios Web .......................................................................... 70 4.4.3. Servicio Web de la venta de paquetes de viajes ............................................... 70 4.5. Arquitectura de la propuesta .................................................................................... 71 Capítulo 5 Trabajos relacionados ........................................................................................ 73 5.1. Proyectos para la generación de WS-BPEL parcial a partir de modelos BPMN ........ 73 5.2. Extensión para Eclipse BPEL Designer ....................................................................... 75 5.3. BPELscript .................................................................................................................. 76 5.4. BPM Petals ................................................................................................................ 77 5.5. Conclusiones.............................................................................................................. 78 Capítulo 6 Conclusión y trabajos futuros ............................................................................ 79 6.1. Conclusión ................................................................................................................. 79 6.2. Trabajos futuros ........................................................................................................ 79 6.3. Información adicional ................................................................................................ 81 Bibliografía ............................................................................................................................... 82 Índice de Figuras Figura 1: Model Driven Architecture ____________________________________________________________ 7 Figura 2: Arquitectura Orientada a Servicios (SOA) ________________________________________________ 9 Figura 3: Pila de protocolos básica de los servicios Web ___________________________________________ 10 Figura 4: Estructura del documento WSDL ______________________________________________________ 11 Figura 5: Servicios Web como implementación de SOA ____________________________________________ 13 Figura 6: Diagrama BPMN que describe los pagos internos en una agencia de viajes ____________________ 14 Figura 7: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado del elemento piscina ___________________________________________________________________________ 15 Figura 8: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de los elementos evento __________________________________________________________________________ 15 Figura 9: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de las actividades ________________________________________________________________________________ 16 Figura 10: Diagrama BPMN que describe los dos estados posibles de un elemento de tipo subproceso ______ 16 Figura 11: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de las compuertas exclusivas ______________________________________________________________________ 17 Figura 12: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de las compuertas paralelas _______________________________________________________________________ 17 Figura 13: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de los flujos de secuencia _________________________________________________________________________ 18 Figura 14: Proceso de búsqueda de seguros de viaje ______________________________________________ 19 Figura 15: Código del proceso de búsqueda de seguros de viaje en WS-BPEL ___________________________ 21 Figura 16: WSDL del proceso inicial ____________________________________________________________ 24 Figura 17: Actividades en WS-BPEL ____________________________________________________________ 24 Figura 18: Sintaxis formal de la actividad Wait en WS-BPEL ________________________________________ 26 Figura 19: Sintaxis formal de la actividad Flow en WS-BPEL ________________________________________ 27 Figura 20: Sintaxis formal de la actividad IF en WS-BPEL ___________________________________________ 27 Figura 21: Sintaxis formal de la actividad Switch en WS-BPEL _______________________________________ 27 Figura 22: Sintaxis formal de la actividad RepeatUntil en WS-BPEL __________________________________ 28 Figura 23: Sintaxis formal de la actividad Pick en WS-BPEL _________________________________________ 28 Figura 24: Editor de Diagramas BPMN en STP BPMN ______________________________________________ 31 Figura 25: Editor de procesos BPEL en BPEL Designer _____________________________________________ 32 Figura 26: Arquitectura de Apache ODE ________________________________________________________ 33 Figura 27: Implementación interna de la herramienta BABEL _______________________________________ 35 Figura 28: Proceso de transformación del modelo BPMN al proceso WS-BPEL que se despliega en caliente __ 39 Figura 29: Reserva de actividades en BPMN _____________________________________________________ 40 Figura 30: Transformación BABEL _____________________________________________________________ 40 Figura 31: Reserva de actividades en BPMN con equivalencias en WS-BPEL ____________________________ 41 Figura 32: WS-BPEL inicial de la reserva de actividades ____________________________________________ 42 Figura 33: Metamodelo intermedio ____________________________________________________________ 43 Figura 34: Diagrama EMF del modelo intermedio en la reserva de actividades _________________________ 49 Figura 35: Formulario para manejar los ParnerLinks ______________________________________________ 50 Figura 36: Formulario para administrar el Process ________________________________________________ 50 Figura 37: Formulario para administrar los Imports _______________________________________________ 51 Figura 38: Formulario para administrar los ParnerLinks remarcando los pasos de creación de un nuevo ParnerLink ________________________________________________________________________________ 52 Figura 39: Formulario para administrar los Invokes _______________________________________________ 52 Figura 40: Modelo intermedio completado para la reserva de actividades _____________________________ 53 Figura 41: Diagrama BPMN de la transformación del modelo intermedio al WS-BPEL Final _______________ 54 Figura 42: Sección del Invoke Reservar Actividad en el WS-BPEL inicial________________________________ 55 Figura 43: Formulario de edición de Invokes con la información del Invoke Reservar Actividad ____________ 55 Figura 44: Sección del Invoke Reservar Actividad en el WS-BPEL completo _____________________________ 56 Figura 45: Diagrama BPMN de la transformación del modelo intermedio al WSDL del proceso WS-BPEL ____ 56 Figura 46: Documento WSDL del proceso WS-BPEL para la reserva de actividades ______________________ 58 Figura 47: Formulario de edición del proceso con la información del proceso de reserva de actividades _____ 58 Figura 48: Diagrama BPMN de la transformación del modelo intermedio al deploy.xml __________________ 59 Figura 49: Formulario de edición de un ParnerLink con la información de ParnerLink Reserva de Actividad___ 60 Figura 50: Documento deploy.xml asociado al proceso de la reserva de actividades _____________________ 61 Figura 51: Proceso de negocio simplificado para la venta de paquetes turísticos ________________________ 63 Figura 52: Composición de servicios para la venta de paquetes turísticos _____________________________ 65 Figura 53: Arquitectura de los servicios Web propios ______________________________________________ 69 Figura 54: Cliente SOAP de Eclipse _____________________________________________________________ 70 Figura 55: Diagrama UML de despliegue de la agencia de viajes ____________________________________ 71 Figura 56: Notación BPMN para Eclipse BPEL Designer ____________________________________________ 75 Figura 57: Comparación entre los lenguajes WS-BPEL y BPELscript __________________________________ 77 Índice de Tablas Tabla 1: Especificación de las metaclases de metamodelo intermedio ................................................................ 47 Tabla 2: Actividades del proceso de negocio para la venta de paquetes turísticos .............................................. 68 Tabla 3: Lista de proyectos para la generación de WS-BPEL parcial .................................................................... 73 1 Capítulo 1 Introducción Actualmente, se está viendo un gran crecimiento en el uso, tanto de la ServiceOriented Architecture (SOA) [1], como de servicios Web. De hecho, el 62% de las empresas están utilizando o quieren utilizar SOA en un futuro próximo [2]. SOA representa un modelo de arquitectura que tiene como objetivo mejorar la agilidad y la rentabilidad de una empresa. Esta propuesta es atractiva para las empresas, pues éstas pueden conectar nuevos servicios o mejorar los existentes haciendo frente a los nuevos requerimientos del negocio en un ambiente cambiante. Los servicios Web son la implementación más frecuente de SOA [3]. Éstos proporcionan una base técnica adecuada para la comunicación de los procesos de negocio, dentro y fuera de la empresa. Sin embargo, para apoyar adecuadamente los procesos de negocio y su gestión, es necesario un mecanismo para describir como estos servicios Web van a ser utilizados [4]. Es en este contexto surgió el Business Process Execution Language (WS-BPEL) [5], el cual es uno de los lenguajes más utilizados para la definición de procesos basados en servicios Web a nivel empresarial actualmente [6]. Una de las pruebas de ello, es la gran cantidad de herramientas desarrolladas para dar soporte en el desarrollo y ejecución de procesos WS-BPEL [7]. No obstante, el principal problema de WS-BPEL para la definición de procesos de negocio, es que éste es un lenguaje complejo, que requiere de personal con un amplio conocimiento de programación. Esto es totalmente opuesto a la gestión tradicional empresarial de los procesos de negocio, la cual es llevada a cabo por administradores de negocio, que carecen generalmente de conocimientos de programación. Además, los procesos de negocio deberían ser fácilmente entendibles por los clientes involucrados en éstos. Asimismo, para mantener la competitividad de la empresa con respecto a sus competidores, sus procesos de negocio deben estar totalmente operativos en todo momento y en constante mejora. Esto implica una gran cantidad de cambios en el proceso WS-BPEL. Debido a sus características técnicas, hacer estos continuos cambios en WS-BPEL requiere tiempo, lo cual en muchas ocasiones, marca la diferencia entre el éxito y el fracaso. Además la realización de estos cambios y la inclusión de nuevos procesos no deben afectar a los procesos que ya están en funcionamiento y que no se pueden parar. Por los motivos mencionados anteriormente, se propone aplicar a la definición de proceso en WS-BPEL, el desarrollo dirigido por modelos (MDD) [8]. MDD es un paradigma de desarrollo software, que usa modelos como principal elemento del desarrollo. Este hecho facilita el desarrollo, reusabilidad y mantenibilidad del software enormemente. 2 Concretamente, para la implementación de la propuesta se ha utilizado un modelo principal basado en el Business Process Execution Language (BPMN) [9] como modelo principal. BPMN proporciona una notación gráfica para la definición de procesos de negocio, la cual es fácilmente entendible sin necesidad de conocimientos de programación. Con ello se consigue elevar el nivel de abstracción y mejorar la rapidez con la que se pueden enfrentar los cambios en los procesos de negocio. Las principales aportaciones de la propuesta, dentro del marco explicado, son: 1) Generación de procesos WS-BPEL totalmente operativo mediante una aproximación basada en modelos. Con ello se consigue tener procesos de negocio implementados sobre el lenguaje WS-BPEL. 2) Despliegue del proceso WS-BPEL generado en caliente sin necesidad de reiniciar el servidor. Con esto se consigue que la modificación de un proceso no afecte al resto de procesos en ejecución y por tanto se evitan interrupciones innecesarias de los servicios de la empresa. 3) Herramienta para la definición de procesos WS-BPEL basada en modelos BPMN. Esta herramienta permite al usuario la introducción de la información especifica de los servicios de una formal fácil e intuitiva. Además de las principales aportaciones comentadas, la tesina ha sido desarrollada como futura extensión para le herramienta Moskitt [10]. Esta herramienta se centra principalmente en el desarrollo de software dirigido por modelos. Moskitt está apoyada por la Consellería de Infraestructuras, Territorio y Medio Ambiente (actualmente se esta preparando su uso en el resto de Consellerías del Gobierno Valenciano). A continuación se presentan: 1) la motivación que ha llevado a la realización de esta propuesta; 2) los principales objetivos que se han querido conseguir con la elaboración de la propuesta; 3) la problemática que se ha querido solventar con la implementación de la propuesta; 4) la solución implementada; y 5) se explica la estructura que sigue la memoria. 1.1. Motivación Muchos motivos han animado el desarrollo de esta propuesta: la gran cantidad de motores y herramientas para el desarrollo y ejecución de procesos basados en WS-BPEL (Apache ODE [11], Oracle BPEL [12], Microsoft Biztalk [13], etc.), las ventajas de WS-BPEL sobre lenguajes clásicos como Java o C#, la abundancia de investigaciones y propuestas entorno a la generación de procesos WS-BPEL a partir de modelos BPMN [14,15] y la existencia de BPMN y las ventajas que aporta el uso de una notación gráfica (tales como, abstracción, sencillez, facilidad de entendimiento). No obstante, los motivos principales han sido cuatro: 9 busquen estas descripciones. En otras palabras, un repositorio UDDI es un repositorio de servicios. Las acciones, que pueden realizar cada uno de los roles, son:  Enlazar: Crear la relación cliente-servidor, entre el solicitante del servicio y el proveedor del servicio. Puede ser dinámica, mediante el uso de un proxy o estática hecha a mano.  Publicar: Publicación/registro del servicio en un repositorio.  Buscar: Búsqueda por parte del consumidor de un servicio deseado dada una serie de criterios. El sistema de búsqueda es dependiente del repositorio. Figura 2: Arquitectura Orientada a Servicios (SOA) [20] 2.1.3. Servicios Web Existen numerosas definiciones de lo que es un servicio Web [21,22,23], lo que muestra su complejidad a la hora de dar una definición que englobe todo lo que implica. Una de las más completas es la del W3C: “Un servicio Web es un sistema software diseñado para soportar a la interoperabilidad máquina-máquina sobre la red. Este tiene una interfaz descrita en un formato procesable por una máquina (específicamente WSDL). Otros sistemas interactúan con el servicio Web de la manera especificada por su descripción utilizando mensajes SOAP, 10 por lo general transmitidos a través de HTTP con una serilización XML y unión con otros estándares relacionados con la Web” [18]. Conceptos base Todas las definiciones que tratan de especificar qué es y de que está formado un servicio Web, tienen los siguientes conceptos básicos en común:  Un servicio Web expone funcionalidad a un consumidor (una aplicación, persona o sistema que utilice el servicio Web) a través de la Web.  Están basados en estándares de la Web, tales como HTTP, XML, SOAP, WSDL, UDDI, etc.  Pueden implementarse bajo cualquier lenguaje y plataforma.  Se pueden ver como cajas negras. Es decir, el sistema puede ser visto como un conjunto de entradas y salidas sin importancia de su funcionamiento interno.  Permiten interconectar compañías, aplicaciones, dispositivos, etc.  Distribuyen e integran la lógica de una aplicación.  Están débilmente acoplados. Es decir, los servicios Web tienen una comunicación reducida entre ellos. Esta es una de las principales ventajas, que aportan los servicios Web, ya que permiten la reutilización de éstos en otros sistemas. Protocolos y estándares En la Figura 3 se muestra la pila de protocolos básica de los servicios Web. Figura 3: Pila de protocolos básica de los servicios Web [24] A continuación, se explica cada uno de los protocolos. 11 Universal Description, Discovery and Integration (UDDI) UDDI [25] es un registro público diseñado para almacenar, de forma estructurada, información sobre empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir información de una empresa y sus servicios Web. Lo más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de una empresa (WSDLs). A través de un conjunto de llamadas a APIs XML basadas en SOAP, se puede interactuar con UDDI, tanto en tiempo de diseño, como de ejecución, para descubrir datos técnicos de los servicios, que permitan invocar y utilizar los servicios Web. De este modo, UDDI sirve como infraestructura para una colección de software basado en servicios Web. Web Services Description Language (WSDL) WSDL es un lenguaje basado en XML para la descripción de servicios Web [26]. Éste permite describir la interfaz pública de los servicios Web, es decir, detalla los protocolos y los formatos de los mensajes necesarios para interactuar con el servicio Web que describe. En cuanto a la estructura de un documento WSDL, la cual se muestra en la Figura 4, se pueden diferenciar dos partes: la parte abstracta del documento (independiente de la aplicación), y la parte concreta, que define los enlaces a protocolos y los puntos finales de acceso al servicio. Figura 4: Estructura del documento WSDL La parte abstracta consta de los siguientes elementos: 12  Tipos de datos <types>: Proporciona las definiciones de tipos de datos utilizados para describir los mensajes intercambiados.  Mensaje <message>: Es la definición abstracta de los datos que se transmiten. Un mensaje se compone de partes lógicas, cada uno de los cuales está asociado con una definición dentro de algún tipo de sistema.  Operación <operation>: Descripción abstracta de una operación soportada por el servicio. Define un intercambio simple de mensajes. Al igual que en un lenguaje de programación común, una operación abstracta, consiste en la definición del nombre, las entradas, y la salida de la operación, sin especificar su lógica interna.  Tipo de puerto <portType>: Conjunto de operaciones abstractas. La parte concreta consta de los siguientes elementos:  Ligadura <binding>: Especifica los protocolos de comunicación usados.  Servicio <service>: Define un conjunto de puertos relacionados.  Puerto <port>: Define el punto de conexión a un servicio Web. Simple Object Access Protocol (SOAP) SOAP es un protocolo estándar, que define cómo dos componentes en diferentes procesos pueden comunicarse por medio del intercambio de datos XML [27]. SOAP fue creado por Microsoft, IBM y otros, y está actualmente bajo el auspicio del W3C. Éste es el protocolo para el intercambio de información utilizado por los servicios Web. eXtensible Markup Languageble Markup Language (XML) XML es un estándar utilizado para normalizar el intercambio de datos entre participantes, proporcionando un medio excelente para codificar y formatear datos [28]. Los elementos y atributos de XML, definen tipos y estructuras de información para los datos que llevan, incluyendo la capacidad de modelar datos y estructuras específicas a un dominio del sistema. La sintaxis de XML usada en las tecnologías de los servicios Web es utilizada para representar los datos (WSDL), definir cómo y con qué calidad se transmiten los datos (SOAP) y detallar cómo se publican y descubren los servicios (UDDI). Hypertext Transfer Protocol (HTTP) HTTP es el protocolo más común para el intercambio de información en la Web [29]. La principal característica de HTTP es la tipificación y la negociación de la 13 representación de datos, permitiendo la construcción de los sistemas, de forma independiente de los datos que se transfieren. Servicios Web como implementación de SOA Aunque los servicios Web no necesariamente significan SOA, y no todas las SOAs están basadas en servicios Web, la relación entre las dos tendencias es importante, y se potencian mutuamente: el interés por los servicios Web lleva hacia SOA, y las ventajas de la arquitectura SOA ayudan a que las iniciativas de servicios Web tengan éxito [30]. Algunas de las ventajas que aportan los servicios Web son: 1) al contrario que CORBA [31] y DCE [32], los estándares de servicios Web no tienen detractores entre los fabricantes; 2) la flexibilidad de los Servicios Web para soportar aplicaciones multicanal; 3) la capacidad de SOAP de pasar por los firewalls, aprovechando la ubicuidad del HTTP; y 4) el soporte de servicios Web en servidores de aplicaciones que albergan lógica empresarial. La arquitectura SOA, implementada con los estándares de los servicios Web, se ve en la Figura 5. En ella se puede observar como los diferentes roles y actividades, de los cuales se ha hablado en el apartado 2.1.2, son implementados por los estándares de los servicios Web. Figura 5: Servicios Web como implementación de SOA [33] Utilizar los servicios Web como implementación para SOA significa utilizar SOAP como lenguaje de intercambio, WSDL como lenguaje para la descripción de los servicios y UDDI para la publicación o registro de los mismos. La secuencia de ejecución es la siguiente: 1) el proveedor del servicio da de alta el servicio Web en el registro. Con este fin, el proveedor almacena en el registro el documento de descripción de éste (WSDL); 2) el solicitante del servicio busca en el registro un servicio Web que pueda adaptarse a sus necesidades; 3) una vez seleccionado el servicio, el solicitante lo invoca mediante el envío de un mensaje SOAP, en el cual se indica la acción a realizar y los datos de entrada; y 4) el servicio Web recibe la petición y ejecuta la funcionalidad. Para finalizar, el servicio Web envía un mensaje SOAP al solicitante con los resultados obtenidos [33]. 14 2.1.4. Business Process Modeling Language (BPMN) Business Process Model and Notation (BPMN) es un estándar desarrollado por el Object Management Group (OMG), cuyo principal objetivo es proveer una notación estándar que sea fácilmente legible y entendible por parte de todos los involucrados e interesados del negocio [9,34]. Elementos de un diagrama BPMN Los elementos que forman un diagrama BPMN se pueden clasificar en cuatro categorías principales, que son: Objetos de Flujo, Objetos de Conexión, Carriles de Piscina y Artefactos. Para simplificar, sólo se hablará de los elementos relevantes para el completo entendimiento de la propuesta. En la Figura 6, se puede ver un diagrama BPMN de ejemplo. Éste expresa la lógica asociada al pago interno realizado por una agencia de viajes a sus proveedores. Este diagrama es utilizado como base para la explicación de las categorías del diagrama BPMN usadas en este estudio. Figura 6: Diagrama BPMN que describe los pagos internos en una agencia de viajes Carriles de nado Los Carriles de Nado son un mecanismo visual de actividades organizadas y categorizadas. Éstos constan de dos elementos: Piscina y Carril. La Piscina contiene al resto de elementos del diagrama, la cual se puede ver remarcada en la Figura 7. Ésta representa los participantes principales de un proceso, por lo general, separados por las diferentes organizaciones. Una Piscina puede contener uno o más carriles. No obstante, la transformación que realiza BABEL sólo soporta el uso de un Carril. 15 Figura 7: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado del elemento piscina Objetos de flujo Los Objetos de Flujo son los elementos principales descritos dentro de BPMN y constan de tres elementos principales: Eventos, Actividades y Compuertas. Los Eventos, son los encargados de describir lo que sucede dentro del proceso. Éstos se pueden clasificar en tres grupos según su posición dentro del proceso: Iniciales, Intermedios y Finales. Los eventos soportados por la transformación BABEL son: 1) Evento Inicial Vacío: son utilizados para marcar el inicio del proceso; 2) Evento Intermedio Temporizador: permite iniciar la espera de un cierto tiempo antes de continuar con la ejecución del proceso; y 3) Evento Final Vacío: marca el final del proceso. En la Figura 8 se muestra el uso de estos eventos. Figura 8: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de los elementos evento Las Actividades se encargan de describir el tipo de trabajo realizado. En esta categoría existen dos elementos relevantes para la propuesta: 1) Tarea simple: su función es representar una sola unidad de trabajo que no se puede dividir en un mayor nivel de detalle. En la Figura 9 se muestran los elementos de tipo actividad utilizados para el pago interno; y 2) Subproceso: se utiliza para ocultar o mostrar otros niveles de detalle de los procesos de negocio. Cuando se minimiza un subproceso se indica con un signo más. 16 Cuando se expande el rectángulo redondeado se muestra todos los objetos de flujo, los objetos de conexión, y artefactos. Además, un Subproceso tiene sus propios eventos de inicio y fin. Asimismo, los flujos de proceso del proceso padre no deben cruzar la frontera. En la Figura 10 se puede ver una imagen que ilustra la utilidad y los dos posibles estados de este elemento. Figura 9: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de las actividades Figura 10: Diagrama BPMN que describe los dos estados posibles de un elemento de tipo subproceso Las Compuertas están representadas por una figura de diamante y determinan, si se bifurcan o se combinan las rutas, dependiendo de las condiciones expresadas. Los elementos soportados de este tipo son: 1) Compuertas Exclusivas: permiten partir y unir caminos. Sólo uno de los diferentes caminos puede ser escogido (ver Figura 11); y 2) Compuertas Paralelas: puede utilizarse tanto para crear flujos paralelos, como para sincronizar diferentes flujos dentro de un proceso. Su significado depende de si se utiliza para partir un proceso en varios flujos o para juntarlos (ver Figura 12). 17 Figura 11: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de las compuertas exclusivas Por ejemplo, en la Figura 12, la Compuerta Paralela más a la izquierda indica que se puede seguir cualquiera de los tres caminos. La que está más a la derecha indica que hasta que no se ejecuten los tres caminos no se puede avanzar. Figura 12: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de las compuertas paralelas Objetos de conexión Los Objetos de Conexión permiten conectar cada uno de los objetos de conexión. Podemos encontrarlos de tres tipos: Secuencias, Mensajes y Asociaciones. De estos tres, el único soportado por la transformación BABEL es el de secuencia. El Flujo de secuencia está representado por una línea simple continua y flechada y muestra el orden en que las actividades se llevarán a cabo, tal como se puede ver en la Figura 13. 18 Figura 13: Diagrama BPMN que describe los pagos internos en una agencia de viajes con el remarcado de los flujos de secuencia 2.1.5. Business Process Execution Language (WS-BPEL) El Web Service Business Process Execution Language (WS-BPEL) es un estándar de OASIS, el cual se desarrolló a partir de WSFL y XLANG, ambos lenguajes basados en XML y orientado a la descripción de servicios Web. Básicamente, WS-BPEL 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 ayudan a la programación a gran escala. Tecnologías WS-BPEL incluye en su especificación referencias a numerosos estándares de servicios Web y XML. Algunos de los más importantes son:  WSDL es el más importante de estos estándares porque WS-BPEL describe los procesos de negocios como conversaciones entre servicios Web, los cuales se describen en WSDLs. Además, los procesos WS-BPEL son servicios Web, por lo que también utilizan WSDL para describir su interfaz abstracta y la forma en la que el cliente se comunicará con el proceso para consumirlo.  XML Schema es un lenguaje de esquema utilizado para describir la estructura y las restricciones de los contenidos de los documentos XML de una forma muy precisa, más allá de las normas sintácticas impuestas por el propio lenguaje XML. Se consigue así una percepción del tipo de documento con un nivel alto de abstracción. XML Schema es utilizado para especificar tipos (por ejemplo, int, doublé, datosDelVuelo) dentro del proceso WS-BPEL.  XPath (XML Path Language) es un lenguaje que permite construir expresiones que recorren y procesan un documento XML. XPATH proporciona al proceso WS-BPEL una forma de manejar sus datos. 25 Receive Esta actividad espera por un mensaje que llegue de un cliente que pretende hacer uso del proceso WS-BPEL. Debe especificar el nombre del PartnerLink del cual espera que llegue el mensaje, el PortType y la operación que desea invocar. Adicionalmente puede especificarse la variable por la cual recibirá el mensaje. Entre las líneas 37-39 en el ejemplo de la Figura 15 se puede ver un ejemplo de uso del Receive. Éste es utilizado para recibir los parámetros necesarios para la ejecución de la búsqueda de seguros. Estos parámetros son almacenados en la variable especificada y posteriormente son utilizados para la invocación del servicio Web de la búsqueda de seguros. Reply Esta actividad permite enviar un mensaje en respuesta a otro mensaje recibido a través de una actividad Receive. Al igual que la actividad Receive, debe especificar el PartnerLink, PortType y Operation, al cual hace referencia. En el ejemplo de la Figura 15 entre las líneas 106-108, se puede ver un ejemplo de uso del Reply. Éste retorna el resultado de la ejecución del proceso y lo finaliza. Invoke Esta actividad permite invocar a un servicio Web. Al igual que con la actividad de tipo Reply y Receive, se deben especificar el PartnerLink, PortType y Operation del servicio Web que se desea invocar. Adicionalmente se puede indicar la variable que se le pasa como entrada al servicio Web y la variable donde se almacenará el mensaje de respuesta. En el ejemplo de la Figura 15 entre las líneas 59-62, se puede ver un ejemplo de uso del Invoke. Éste es utilizado para la invocación del servicio Web de la búsqueda de seguros. Para su invocación se utilizan dos variables, las cuales están definidas entre las líneas 28-32, que permiten especificar los datos de entrada y almacenar el resultado de la invocación. Assign Esta actividad es el principal elemento para la manipulación de datos en WS-BPEL y toma como base el lenguaje XPath estándar, a través de sus consultas, expresiones y funciones. Además, es posible usar XQuery, XSLT o Java para manipulaciones o transformaciones más complejas de datos. En el ejemplo de la Figura 15 , se han utilizado tres actividades de este tipo. 1) Dos de ellas, las cuales se encuentran entre las líneas 40-55 y 72-105, tienen la función de mapear la variable de entrada del proceso con la variable de entrada a la 26 invocación del servicio Web y la variable de salida de la invocación con la variable de salida del proceso respectivamente. 2) El Assign restante, que se encuentra entre las líneas 63-69, se utiliza para dar valor a la variable de nombre “error” que es utilizada como condición del bucle. En general, como se ha podido ver en los ejemplos, toda actividad Assign está formada por dos componentes From y To, los cuales son utilizados para indicar el origen y el destino del mapeo. Wait Esta actividad permite esperar un cierto periodo de tiempo. La manera de especificar las expresiones asociadas a los atributos for y until se logran mediante expresiones en XPath 1.0. Su sintaxis formal se puede observar en la Figura 18. 1 2 <wait (for="duration-expr" | until="deadline-expr") > </wait> Figura 18: Sintaxis formal de la actividad Wait en WS-BPEL Sequence Una Sequence contiene una o más actividades que se ejecutan secuencialmente en el orden en que fueron listadas. Esta actividad finaliza cuando termina la última actividad de la misma. En el ejemplo de la Figura 15, se han utilizado dos actividades de este tipo. 1) La primera, que se encuentra entre las líneas 36-109, engloba a todo el resto de actividades, y como se ha explicado, indica que las actividades que contiene se ejecutarán de manera secuencial. 2) La segunda, que se encuentra entre las línea 58-70, engloba todas las actividades dentro de la actividad While. Al igual que en el caso anterior, marca la ejecución secuencial de las actividades que contiene. En general, el uso de la actividad Sequence, al igual que la actividad Flow está marcado por restricciones de otras actividades. Por ejemplo, el cuerpo de un proceso sólo puede estar formado por una actividad, por lo que ésta deberá ser una actividad que pueda englobar al resto. Lo mismo ocurre en el caso del While. Flow Esta estructura permite que dos o más actividades sean ejecutadas concurrentemente y concluye cuando todas las actividades que engloba hayan finalizado. Su sintaxis formal se puede observar en la Figura 19. 27 1 2 3 <flow> Activity* </flow> Figura 19: Sintaxis formal de la actividad Flow en WS-BPEL If Esta actividad proporciona un comportamiento condicional al proceso (al estilo de un if en Java). La actividad consiste en una lista de una o más condiciones (en forma de expresiones Xpath), que permite seleccionar una rama de ejecución entre varias. Su sintaxis formal se puede observar en la Figura 20. 1 2 3 4 5 6 7 8 9 10 11 <if> <condition>bool-expr</condition> activity <elseif>+ <condition>bool-expr</condition> activity </elseif> <else>? activity </else> </if> Figura 20: Sintaxis formal de la actividad IF en WS-BPEL Switch Este tipo de actividad cumple la función de una estructura de selección múltiple (al estilo del case de Java) en donde es posible introducir condiciones (en forma de expresiones XPath) que permitan seleccionar una rama de ejecución entre varias. Su sintaxis formal se puede observar en la Figura 21. 1 2 3 4 5 6 7 8 <switch> <case condition="bool-expr">+ activity </case> <otherwise>? activity </otherwise> </switch> Figura 21: Sintaxis formal de la actividad Switch en WS-BPEL While El While permite especificar que una actividad se ejecutará hasta que se alcance cierta condición. En las líneas 56-71 de la Figura 15 se puede ver un ejemplo de uso del While. Éste se encarga de repetir la invocación del servicio Web de búsqueda de seguros mientras el resultado contenga algún error. 28 RepeatUntil El comportamiento del RepeatUntil es muy similar al While, con la diferencia que la actividad que contiene se ejecutará como mínimo una vez. Su sintaxis formal se puede observar en la Figura 22. 1 2 3 4 <repeatUntil > activity <condition> bool-expr</condition> </repeatUntil> Figura 22: Sintaxis formal de la actividad RepeatUntil en WS-BPEL Pick La actividad Pick está formada por un conjunto de ramas de la forma evento/actividad. Estas ramas pueden ser de dos tipos:  onAlarm: sigue un comportamiento idéntico al de una actividad Wait, indicando mediante una expresión Xpath cuando se activará.  onMessage: sigue un comportamiento idéntico al de una actividad Receive. Esta rama se activará cuando llegue el mensaje esperado. Cuando ocurre alguno de estos desencadenadores, se ejecuta la actividad asociada a cada uno de ellos. Cada actividad Pick debe incluir por lo menos un desencadenador onMessage. La sintaxis formal se puede observar en la Figura 23. 1 2 3 4 5 6 7 8 9 <pick createInstance="yes|no"? > <onMessage partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?>+ activity </onMessage> <onAlarm (for="duration-expr" | until="deadline-expr")>* activity </onAlarm> </pick> Figura 23: Sintaxis formal de la actividad Pick en WS-BPEL 2.2. Desarrollo de la propuesta Dada la complejidad y amplitud de WS-BPEL, y debido a las necesidades específicas de los procesos de negocio y de las empresas actuales, se hace necesario el desarrollo de una herramienta eficiente para el desarrollo y mantenimiento de los procesos de negocio. Como se ha comentado en el Capítulo 2, para la implementación de esta herramienta, se propone la implementación de la transformación de BPMN a WS-BPEL, y la construcción de una interfaz gráfica, que permita completar el WS-BPEL haciéndolo 29 totalmente operativo. La herramienta propuesta es atractiva, sencilla para los usuarios, y altamente abstracta gracias a su orientación basada en modelos. 2.3. Tecnologías utilizadas En este apartado se tratan las distintas tecnologías que se han utilizado para el desarrollo de la propuesta. Ésta ha sido desarrollada exclusivamente con software libre, tratando de aprovechar al máximo la gran cantidad de herramientas disponibles. 2.3.1. Java Java es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria [35]. Las características principales de Java son las siguientes:  La orientación a objetos se basa en diseñar el software de forma que los distintos tipos de datos que usen estén unidos a sus operaciones. Así, los datos y el código (funciones o métodos) se combinan en entidades llamadas objetos. Un objeto puede verse como un paquete que contiene el “comportamiento” (el código) y el “estado” (datos). El principio es separar aquello que cambia de las cosas que permanecen inalterables  La independencia de plataforma permite que programas escritos en el lenguaje Java puedan ejecutarse igualmente en cualquier tipo de hardware.  El recolector de basura simplifica la tarea del programador. El programador determina cuándo se crean los objetos y es el entorno en tiempo de ejecución el responsable de gestionar el ciclo de vida de los objetos. El programa u otros objetos pueden tener localizado un objeto mediante una referencia a éste. Cuando no quedan referencias a un objeto, el recolector de basura de Java borra el objeto. 2.3.2. Eclipse Eclipse es un entorno de desarrollo integrado (IDE, Integrated Development Environment) de código abierto, multiplataforma para desarrollar software [36]. Eclipse fue diseñado para facilitar la edición, compilación y ejecución de programas, durante la fase de desarrollo. Eclipse es una aplicación gratuita y de código abierto disponible en la red para su descarga [37]. Para la implementación de la propuesta se ha utilizado la versión de Eclipse Indigo 3.7.3. 30 2.3.3. JDOM En el campo de la manipulación de documentos XML, se pueden encontrar numerosas alternativas compatibles con Java, tales como XAM, DOM, JDOM y XOM. A la vista de una gran cantidad de alternativas, se evaluaron las diferentes posibilidades, buscando la simplicidad de la implementación y la eficiencia (tiempo usado para la ejecución de la transformación). Algunos de los motivos que nos han hecho elegir JDOM [38], en lugar de las otras alternativas, han sido: 1) permite realizar las operaciones sobre el XML de una manera simple e intuitiva; 2) mayor integración con XPATH. En la propia API se proporcionan mecanismos para la ejecución de sentencias XPATH; y 3) a diferencia de DOM, JDOM ha sido creado y optimizado específicamente para Java. Esto hace que sea una API más eficiente y más natural de usar para el desarrollador Java y por lo tanto requiere un menor coste de aprendizaje. JDOM es una API desarrollada específicamente para Java que da soporte al tratamiento de XML: parseo, búsquedas, modificación, generación y serialización. Éste es un modelo similar a DOM, pero no está creado ni modelado sobre DOM. Se trata de un modelo alternativo [38]. Concretamente, se ha utilizado la versión de JDOM 2.0.1 que ha sido significativamente restructurada con respecto a su anterior versión mediante el uso de genéricos y otras características introducidas en la versión de java 5. Esta API junto al lenguaje XPATH, del cual se habla en el siguiente apartado, han sido los componentes claves para la implementación de las transformaciones de BPMN a WS-BPEL. 2.3.4. XPATH XPath (XML Path Language) es un lenguaje que permite construir expresiones que recorren y procesan un documento XML. La idea es parecida a las expresiones regulares para seleccionar partes de un texto sin atributos (plain text) [39]. XPath proporciona el dinamismo que se requería para la propuesta, y es el elemento principal responsable de la recuperación y filtrado de información de los documentos XML. A continuación, se muestra un ejemplo de la sintaxis de XPath, en donde se puede ver este dinamismo: “//invoke[@name=’Buscar_seguros_de_viaje’]”. Esta sentencia retorna todos los nodos de un documento XML con nombre “invoke” y con un atributo “name” igual a “Buscar_seguros_de_viaje”. Una operación tan sencilla como esta, que consta de una línea de código con XPath, implica sin XPath, una gran cantidad de líneas de código. Esto se debe principalmente al tipo de documento con el que estamos trabajando. El XML que representa un proceso WS-BPEL organiza sus elementos en función de su posición dentro del proceso (no por tipo del 31 elemento). Por lo que un Invoke puede estar dentro de diferentes elementos, por ejemplo un While, un Sequence entre otros. Es por esto que recorrer de forma secuencial el documento buscando un elemento sin XPath es muy costoso y engorroso. Además, utilizar este tipo de búsqueda relativa permite un resultado mas robusto frente a modificaciones en la organización del documento, haciendo así, una solución mas perdurable en el tiempo. 2.3.5. STP BPMN STP BPMN es un subproyecto de SOA Tools Platform en Eclipse [40]. Su principal objetivo es la construcción de un marco de trabajo y un conjunto de herramientas extensibles, que permiten el diseño, configuración, montaje, despliegue, monitorización y gestión del software, diseñado alrededor de una SOA. Dentro de este marco, SOA Tools Platform está formado por diversos subproyectos. STP BPMN es uno de sus subproyectos activos actualmente, el cual, ha sido usado para la elaboración de la presente propuesta. STP BPMN proporciona un editor y un conjunto de herramientas para la creación de diagramas de procesos de negocio basados en la notación BPMN (ver sección 3.2.1). La Figura 24 muestra el editor proporcionado por el proyecto STP BPMN. En éste se diferencian claramente dos secciones: en la sección A se modela el proceso y se insertan los diferentes elementos que contiene un diagrama BPMN. En la sección B se muestra la paleta del editor, la cual permite ver y seleccionar todos los elementos BPMN soportados por la herramienta. Figura 24: Editor de Diagramas BPMN en STP BPMN 32 2.3.6. BPEL Designer Project BPEL Designer Project es un proyecto de Eclipse que proporciona soporte completo para la definición, creación, edición, implementación, pruebas y depuración de procesos WS-BPEL bajo el estándar WS-BPEL 2.0 [5,41]. Esta herramienta se puede extender por terceros y permite la manipulación de procesos BPEL de una manera gráfica intuitiva. BPEL Designer ha desarrollado su propia representación gráfica de los diferentes elementos que componen un proceso WS-BPEL. Figura 25: Editor de procesos BPEL en BPEL Designer La Figura 25 muestra el editor visual que proporciona BPEL Designer. En él, se pueden diferenciar las siguientes secciones: A) es la paleta del editor, en ella aparecen todos los elementos BPEL disponibles para insertar en el proceso; B) es la sección principal del editor que permite la edición del proceso mediante la inserción de nuevos elementos y mediante la especificación del orden de estos elementos; C) muestra los elementos inherentes al proceso principal, los cuales no tienen representación visual; D) muestra las propiedades del elemento seleccionado actualmente; y E) permite ver el proceso en forma de workflow. 33 2.3.7. Apache ODE Apache ODE (Orchestration Director Engine) es una herramienta desarrollada por Apache Software Fundation bajo la licencia Apache, que permite la ejecución de procesos de negocio ejecutables basados en el estándar WS-BPEL 2.0 [5,11]. Sus características principales son: 1) soporte del estándar WS-BPEL 2.0 de OASIS y el BPEL4WS 1.1; 2) soporte de ejecución bajo diferentes entornos; 3) soporte para HTTP WSDL Binding; 4) proporciona una API de alto nivel para acceso al motor que permite la integración del núcleo, con múltiples capas de comunicación e incluso su uso de manera independiente desde una aplicación; 5) la compilación de WS-BPEL provee de análisis detallados y validación desde la línea de comandos o durante el despliegue; y 6) interfaz para la gestión de procesos, instancias y mensajes. La arquitectura de Apache ODE está dividida en diversos componentes, facilitando su reutilización. A continuación se muestran sus diferentes componentes: Figura 26: Arquitectura de Apache ODE [11] En la Figura 26, se pueden ver los diferentes componentes que conforman la arquitectura de Apache ODE. A continuación se explican los más importantes:  ODE BPEL Compiler: Es el componente encargado de la compilación de proceso WSBPEL. Tiene como entrada el documento del proceso WS-BPEL, junto con sus 34 documentos asociados (WSDL, Schemas, etc.). Como salida, el proceso WS-BPEL compilado.  ODE BPEL Runtime: Es el componente encargado de la ejecución del proceso WSBPEL compilado.  ODE Integration Layer: Permite al componente ODE BPEL Runtime comunicarse con el mundo exterior. Para el desarrollo de la propuesta se ha utilizado Apache ODE 1.3.5 desplegado como un WAR en un servidor de aplicaciones Tomcat 6.0. Aunque actualmente ya está disponible la versión 7.0, ésta aun no era estable al inicio del desarrollo de la propuesta. 2.3.8. EMF project EMF (Eclipse Modeling Framework) es un marco de trabajo de modelado y de generación de código para construir herramientas y otras aplicaciones basadas en un modelo de datos estructurado. Desde una especificación del modelo descrito en XMI, EMF suministra herramientas y soporte en tiempo de ejecución para producir un conjunto de clases Java para el modelo, un conjunto de clases Adapter que permiten la visualización y edición con base en comandos del modelo, y un editor básico [42]. Los modelos pueden ser especificados usando anotaciones en Java, documentos XML, o herramientas de modelado como Rational Rose [43], y después ser importados a EMF. Lo más importante es que EMF suministra las bases para el desarrollo dirigido por modelos. 2.3.9. FMF FMF (Forms Modeling Framework) es un marco de trabajo que tiene como objetivo facilitar el desarrollo de editores Eclipse basados en formularios que manipulan modelos definidos mediante metamodelos Ecore [44,45]. Habitualmente, los modelos se editan mediante editores gráficos donde los elementos se representan en diagramas que utilizan figuras relacionadas entre ellas (como los modelos UML, BPMN, etc.). Trabajando sobre la plataforma Eclipse se puede utilizar el Graphical Modeling Framework (GMF) para desarrollar este tipo de editores. No obstante, en ocasiones estas metáforas gráficas no son las más adecuadas y resulta más sencillo e intuitivo editar el contenido de un modelo utilizando formularios (tablas, campos de texto, formularios maestro-detalle, etc.). Utilizando FMF, se ha desarrollado una herramienta gráfica la cual permite al usuario modificar e introducir la información necesaria para la generación de un archivo WS-BPEL totalmente operativo. 41 finales, así como la definición de las variables utilizadas en el WS-BPEL y los mapeos entres las diferentes variables y servicios que se invocan. Ejemplo Continuando con el ejemplo mostrado en el apartado 3.1, se ejecuta la transformación teniendo como entrada el BPMN mostrado en la Figura 29. Esta transformación convierte cada Actividad en el modelo BPMN en al menos en un Invoke, crea un Receive para iniciar el proceso y buscará estructuras de tipo Switch o de tipo While formadas por los Puertas de Conexión. En la Figura 31 se pueden ver los diferentes elementos de WS-BPEL encontrados en el diagrama BPMN. Figura 31: Reserva de actividades en BPMN con equivalencias en WS-BPEL El código WS-BPEL que se obtiene después de la ejecución de la transformación BABEL se puede ver en la Figura 32. En ella, no están definidos los Partner Links, las Variables, los Assigns, etc. Este código es completado en las siguientes fases del proceso. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <?xml version="1.0" encoding="UTF-8"?> <process xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/abstract" name="BABEL_BookActivities" targetNamespace="http://samples.org//workspaceTransformation/STPbpmnTObabelBP MN/models/BABEL_BookActivitiesBPMN.bpmn"> <!--bpmn2bpel Version 1.0--> <partnerLinks>partnerLinks> <variables><!--List variables used in this BPEL process--></variables> <sequence name="sequenceComponent_2"> <receive name="ProcessInstantiation" partnerLink="client" portType="localPT" operation="localPT" variable="client_data" createInstance="yes" /> <sequence> <invoke name="Reservar Actividad" partnerLink="local" portType="localPT" operation="Reservar Actividad" inputVariable="Reservar Actividad_data_in" outputVariable="Reservar Actividad_data_out" /> <while condition=""> <invoke name="Reservar Actividad" partnerLink="local" portType="localPT" operation="Reservar Actividad" inputVariable="Reservar Actividad_data_in" outputVariable="Reservar Actividad_data_out" /> </while> 42 22 23 24 25 26 27 28 29 </sequence> <while condition="si"> <invoke name="Cancelar Actividad" partnerLink="local" portType="localPT" operation="Cancelar Actividad" inputVariable="Cancelar Actividad_data_in" outputVariable="Cancelar Actividad_data_out" /> </while> </sequence> </process> Figura 32: WS-BPEL inicial de la reserva de actividades 3.3. Generación del proceso WS-BPEL completo El WS-BPEL generado por BABEL a partir del modelo BPMN es incompleto. Se necesita información adicional del usuario para poder completarlo y que este pueda ser desplegado en el servidor y consumido por otras aplicaciones. Para ello, se ha implementado una herramienta gráfica basada en formularios que permite al usuario introducir la información faltante de una forma sencilla e intuitiva. Además se han generado una serie de transformaciones para: 1) adaptar el resultado de BABEL a la herramienta gráfica implementada; 2) completar el WS-BPEL generado por BABEL; y 3) generar los artefactos esenciales asociados al proceso. Este apartado esta formado por seis secciones: 1) la primera de ellas explica el metamodelo implementado para la propuesta, especificando las decisiones tomadas en su implementación y los diferentes elementos que lo componen; 2) en segundo lugar, se explica la transformación automática del WS-BPEL inicial al modelo intermedio; 3) en tercer lugar, se explica la herramienta para completar la información del modelo intermedio con la información del usuario; 4) en cuarto lugar, se describe como se completa el WS-BPEL inicial con la información del modelo intermedio; 5) en quinto lugar, se explica la generación de WSDL del proceso a partir del modelo intermedio; y 6) por último, se describe la generación del fichero deploy.xml a partir del modelo intermedio. El fichero deploy.xml será necesario para el correcto despliegue de la composición de servicios en el servidor. 3.3.1. Metamodelo intermedio Para permitir al usuario completar la información del WS-BPEL generado por BABEL, se ha implementado un metamodelo intermedio cuya función es almacenar la información del WS-BPEL inicial de forma que sea fácilmente modificable por el usuario. El metamodelo intermedio se puede ver en la Figura 33. Éste ha sido definido de manera que no almacena toda la información de un proceso WS-BPEL, solo almacena la información necesaria para que el usuario pueda completar el WS-BPEL inicial usando la herramienta gráfica. El resto de la información permanece en el WS-BPEL inicial. Posteriormente, el WS-BPEL inicial es completado con la información contenida en el modelo intermedio ya refinado por el usuario. 43 Figura 33: Metamodelo intermedio 44 En la Tabla 1 se explican las diferentes metaclases que conforman el metamodelo y las relaciones entre ellas. BPELProcess Ésta es la metaclase principal. Representa al elemento proceso de WS-BPEL y contiene al resto de metaclases. Atributos Nombre (Name): Permite especificar el nombre del proceso principal. Nombre de operación (OperationName): Permite especificar el nombre que se le asigna a la operación que realiza el proceso. Este nombre se define en el WSDL del proceso WSBPEL. Relaciones* Variable de entrada (InputVariable): Especifica la variable de entrada del proceso. Variable de salida (OutputVariable): Especifica la variable de salida del proceso. Assign de salida (OutputAssign): Permite manipular los datos y dar el valor deseado a la variable de salida del proceso. *El resto de relaciones tienen la única función de englobar al resto de metaclases. Other Ésta es la metaclase padre de las metaclases While y Switch, permite agrupar los atributos y relaciones comunes entre ambos hijos. Atributos Nombre: Especifica el nombre del elemento. Relaciones Condiciones (Conditions): Permite especificar la expresión XPATH que define el comportamiento de este tipo de elementos. Assign antes del elemento (AssignBeforeElement): Permite especificar un Assign antes del elemento para manipular los datos que posteriormente son utilizados por el elemento. While Metaclase encargada de representar al elemento While de WS-BPEL. Relaciones Assign antes de terminar (AssignBeforeEnd): Permite especificar un Assign, el cual es ejecutado una vez por cada iteración. Switch Metaclase encargada de representar el elemento Switch de WS-BPEL Condition Metaclase utilizada para especificar el comportamiento de las condiciones que contienen los elementos While y Switch en WS-BPEL. Atributos Id: Permite identificar una condición de forma inequívoca. Valor (Value): Expresión XPATH que especifica su comportamiento. Assign Metaclase que representa al elemento Assign de WS-BPEL Atributos Nombre (Name): Permite especificar el nombre del Assign. 45 Relaciones Expresiones (Expressions): Permite especificar las expresiones asociadas al elemento Assign, las cuales permitirán manipular los datos y dar valor a las variables del proceso. Expression Metaclase encargada de especificar los diversos comportamientos que puede tener un Assign. Atributos Desde (From): Permite especificar y manipular los datos que serán copiados en la variable especificada en el atributo To. Hacia (To): Permite especificar la variable a la cual se le copiaran los datos especificados en el From. Desde literal (From_Literal): Atributo booleano que especifica si el From es literal, es decir, si éste debe tomarse como texto plano o como una expresión. Hacia literal (To_Literal): Atributo booleano que especifica si el To es literal, es decir, si éste debe tomarse como texto plano o como una expresión. Timer Metaclase que representa al elemento Wait de WS-BPEL. Atributos Nombre (Name): Permite especificar el nombre del elemento. Fecha (Date): Permite especificar una fecha hasta la cual el elemento tiene que esperar. Año (Year): Permite especificar el número de años que el elemento tiene que esperar. Mes (Month): Permite especificar el número de meses que el elemento tiene que esperar Días (Day): Permite especificar el número de días que el elemento tiene que esperar. Horas (Hours): Permite especificar el número de horas que el elemento tiene que esperar o la hora hasta la que tiene que esperar. Minutos (Minutes): Permite especificar el número de minutos que el elemento tiene que esperar o el minuto hasta el que tiene que esperar. Segundos (Seconds): Permite especificar el número de segundos que el elemento tiene que esperar o el segundo hasta el que tiene que esperar. Tipo (Type): Este atributo es un elemento de tipo enumeración, el cual puede tener dos valores: 1) DateCond: El elemento espera hasta un fecha concreta; y 2) TimeCond: El elemento espera una cantidad de tiempo determinada. Variable Metaclase que representa al elemento Variable de WS-BPEL. Atributos Nombre (Name): Permite especificar el nombre de la variable. Relaciones* Tipo (Type): Permite especificar el tipo de la variable. Elemento (Element): Permite especificar el tipo de elemento que contiene una variable. Tipo de mensaje (MessageType): Permite especificar el tipo de mensaje de la variable. *Una variable solo puede tener un tipo, un elemento o un tipo de mensaje. Type Metaclase que representa un tipo de datos simple que define una variable. Atributos Nombre (Name): Permite especificar el nombre del tipo. 46 Element Metaclase que representa el elemento que define una variable. Atributos Nombre (Name): Permite especificar el nombre del elemento. MessageType Metaclase que presenta un tipo de mensaje que define una variable Atributos Nombre (Name): Permite especificar el nombre del tipo de mensaje. Import Metaclase padre que engloba a las metaclases XSD y WSDL. Atributos Archivo (File): Especifica la ruta donde se encuentra el archivo importado. Relaciones Espacio de nombre (Namespace): Especifica el Namespace asociado al archivo importado. XSD Metaclase que representa los XSDs importados en el proceso. Relaciones Tipos (Types): Permite especificar los elementos de tipo Type que son especificados en el XSD. Elementos (Elements): Permite especificar los elementos de tipo Element que son especificados en el XSD. WSDL Metaclase que representa los WSDLs importados en el proceso. Relaciones Tipo de mensajes (MessageTypes): Permite especificar los tipos de mensaje definidos en el WSDL. Tipos de puerto (PortTypes): Permite especificar los PortTypes definidos en el WSDL. Ligaduras (Bindings): Permite especificar los Bindings definidos en el WSDL. Servicios (Services): Permite especificar los Services definidos en el WSDL. Namespace Metaclase que representa al tipo de elemento Namespace dentro del proceso WS-BPEL. Atributos Abreviatura (Abrev): Permite especificar la abreviatura que permite hacer referencia al Namespace. Valor (Value): Permite especificar el Namespace completo. PortType Metaclase que representa los tipos de puerto de un WSDL. Atributos Nombre (Name): Permite especificar el nombre del tipo de puerto. Relaciones Operaciones (Operations): Permite especificar las operaciones contenidas en el PortType. Binding Metaclase que representa las ligaduras definidas en un WSDL. 47 Atributos Nombre (Name): Permite especificar el nombre de la ligadura. Port Metaclase que representa los puertos definidos en un WSDL. Atributos Nombre (Name): Permite especificar el nombre del puerto. Relaciones Ligadura (Binding): Permite especificar la ligadura asociada a un puerto. Service Metaclase que representa los servicios definidos en un WSDL. Atributos Nombre (Name): Permite especificar el nombre del servicio. Relaciones Puertos (Ports): Permite especificar los puertos asociados a un servicio. Operation Metaclase que representa las operaciones definidas en un WSDL. Atributos Nombre (Name): Permite especificar el nombre de la operación. Relaciones Tipo de mensaje de entrada (InputMessageType): Permite especificar el tipo de mensaje de entrada de la operación. Tipo de mensaje de salida (OutputMessageType): Permite especificar el tipo de mensaje de salida de la operación. Invoke Metaclase que representa el elemento Invoke de WS-BPEL. Atributos Nombre (Name): Permite especificar el nombre del Invoke. Relaciones ParnerLink: Permite especificar el ParnerLink asociado a un Invoke. Operación (Operaction): Permite especificar la operación que realiza un Invoke. Variable de entrada (IputVariable): Permite especificar la variable de entrada de un Invoke. Variable de salida (OutputVariable): Permite especificar la variable de salida de un Invoke. ParnerLink Metaclase que representa el ParnerLink de un WS-BPEL. Atributos Nombre (Name): Permite especificar el nombre del ParnerLink. Nombre del PLT (PLTName): Permite especificar el nombre del tipo de ParnerLink, Nombre del role (RoleName): Permite especificar el nombre del role. Relaciones Tipo de puerto (PortType): Permite especificar el tipo de puerto asociado al ParnerLink Puerto (Port): Permite especificar el tipo de puerto asociado al ParnerLink. Tabla 1: Especificación de las metaclases de metamodelo intermedio 48 3.3.2. Transformación del WS-BPEL inicial en un modelo intermedio El objetivo de la transformación automática del WS-BPEL inicial en un modelo intermedio es transformar el resultado de la transformación BABEL explicada en el apartado 3.2, en un modelo entendible por la herramienta gráfica basada en FMF, la cual es utilizada por el usuario, para la introducción de la información restante. El modelo resultante de esta transformación es una instancia del metamodelo explicado en el apartado 3.3.1, sobre el cual trabaja la herramienta. Para la implementación de esta transformación, se ha utilizado como lenguaje Java, utilizando las librerías de JDOM y el lenguaje XPATH los cuales facilitan en gran medida la manipulación de documentos XML (tales como, WS-BPEL, WSDL, XMI). Ejemplo Continuando con el ejemplo mostrado en el apartado 3.1, se ejecuta la transformación del WS-BPEL inicial mostrado en la Figura 32 en el modelo intermedio. Esta transformación recorre el WS-BPEL inicial convirtiendo cada uno de sus elementos en su equivalente en el metamodelo. Además, crea varios elementos por defecto que facilitan al usuario final la tarea de completar el proceso. Estos elementos son: 1) las variables de salida y de entrada del proceso principal; 2) el WSDL del proceso; 3) un XSD con todos los elementos habituales utilizados en un proceso WS-BPEL; y 4) los Namespace que hacen referencia al WSDL y al XSD generados. En la Figura 34 se puede ver el resultado de la transformación. El resultado se muestra mediante la representación visual que proporciona el proyecto EMF por defecto para facilitar la lectura y edición de los modelos. En el modelo resultante de la transformación se pueden diferenciar cinco grupos de elementos: 1) en primer lugar, los elementos de tipo Invoke obtenidos mediante la transformación de cada aparición del elemento <invoke> en el WS-BPEL inicial; 2) en segundo lugar, se hallan dos elementos de tipo Import, concretamente uno de tipo WSDL y otro de tipo XSD. Como se ha mencionado, éstos son generados automáticamente para facilitar la introducción de información por parte del usuario; 3) en tercer lugar, dos elementos de tipo Other, concretamente de tipo While, que son el resultado de la transformación de cada aparición del elemento <while> en el WS-BPEL inicial; 4) en cuarto lugar, se encuentran la dos variables utilizadas para indicar la entrada y salida del proceso, respectivamente. Al igual que los elementos WSDL y XSD, éstas son generadas automáticamente; 5) por último, se encuentran los dos elementos de tipo Namespace generados automáticamente, permitiendo referenciar a los elementos WSDL y XSD mencionados anteriormente. 49 Figura 34: Diagrama EMF del modelo intermedio en la reserva de actividades 3.3.3. Edición del modelo intermedio mediante una interfaz En esta fase, el usuario introduce la información necesaria para completar el WSBPEL inicial con ayuda de la herramienta gráfica implementada basada FMF. Se ha decido utilizar una herramienta gráfica basada en formularios, principalmente porque ésta ofrece un mecanismo sencillo para añadir información. Esto hace que la propuesta pueda ser mas fácilmente introducida dentro de un entorno industrial, y que la curva de aprendizaje del usuario sea mas baja. Además, gracias al potente framework FMF, se han desarrollado los formularios que forman la herramienta, de una manera sencilla, rápida y muy eficiente. La información que el usuario debe introducir para completar el proceso es: 1) información referente a los servicios Web tales como Partner links, Port Type, variables de entrada, variables de salida, WSDLs y XSDs; 2) información para la manipulación de los datos, es decir, la especificación de los Assigns; y 3) la especificación de la expresiones que definen el comportamiento de los elementos de tipo While, Switch y Timer. El patrón que se utiliza para la gran mayoría de pestaña a excepción del que se utiliza para representar la información del proceso principal, divide la pantalla en dos secciones: 1) la “sección A” muestra una lista con todos los elementos de un tipo concreto y en los casos necesarios incluye botones para la creación y eliminación de elementos de la lista; y 2) la “sección C” muestra los atributos asociados al elemento seleccionado en la “sección lista”, cuyo valor puede ser modificado por el usuario. Además, en la parte inferior de ésta se pueden ver nueve pestañas, las cuales representan los elementos principales del proceso y permiten el acceso a sus respectivos formularios. Por ejemplo, en la pestaña Process se encuentra el formulario asociado a un 50 elemento de tipo Process, mostrado en la Figura 36. A diferencia de lo que se ha comentado hasta el momento, éste es el único formulario que sigue una estructura diferente. Esto se debe a que solo puede existir un elemento de tipo Process, por lo que la “sección C” con la lista es suprimida y solo se muestra la sección de detalle con sus respectivos atributos y la “sección B” que permite navegar entre las diferentes pestañas. Figura 35: Formulario para manejar los ParnerLinks Figura 36: Formulario para administrar el Process 57 que describen la operación implementada por el proceso WS-BPEL; 4) la herramienta añade la definición del PortType y la operación asociada al PortType, especificando los mensajes de entrada y de salida de la operación; 5) se definen los ParnerLink Types utilizados durante el proceso, incluido el del propio proceso; y 6) por último, se genera el Binding y el Service a partir de los elementos introducidos anteriormente. Ejemplo Continuando con el ejemplo de la reserva de actividades, dado el modelo intermedio completado con la información del usuario, la herramienta genera el documento WSDL referente al proceso WS-BPEL. El código resultante de la transformación del modelo intermedio se puede ver en la Figura 46. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:p="http://www.w3.org/2001/XMLSchema" xmlns:plnk="http://docs.oasisopen.org/wsbpel/2.0/plnktype" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://BABEL_BookActivitiesBPMN" xmlns:wsdl1="http://www.example.org/Hotelbooking/" xmlns:xsd1="http://www.example.org/XMLSchemaTravelAgency" xmlns:xsd2="http://www.example.org/HotelXMLSchema" name="BABEL_BookActivitiesBPMN" targetNamespace="http://BABEL_BookActivitiesBPMN"> <wsdl:import location="Hotelbooking.wsdl" namespace="http://www.example.org/Hotelbooking/" /> <wsdl:types> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import schemaLocation="XMLSchemaTravelAgency.xsd" namespace="http://www.example.org/XMLSchemaTravelAgency" /> </xsd:schema> </wsdl:types> <wsdl:message name="BABEL_BookActivitiesBPMNOutputMessage"> <wsdl:part element="xsd1:ResponseBookAct" name="parameters" /> </wsdl:message> <wsdl:message name="BABEL_BookActivitiesBPMNInputMessage"> <wsdl:part element="xsd1:RequestBookActivity" name="parameters" /> </wsdl:message> <wsdl:portType name="BABEL_BookActivitiesBPMN"> <wsdl:operation name="BookActivity"> <wsdl:input message="tns:BABEL_BookActivitiesBPMNInputMessage" /> <wsdl:output message="tns:BABEL_BookActivitiesBPMNOutputMessage" /> </wsdl:operation> </wsdl:portType> <plnk:partnerLinkType name="PLTHotelBooking"> <plnk:role name="RoleHotelBooking" portType="wsdl1:Hotelbooking" /> </plnk:partnerLinkType> <plnk:partnerLinkType name="BABEL_BookActivitiesBPMN"> <plnk:role name="BABEL_BookActivitiesBPMNProvider" portType="tns:BABEL_BookActivitiesBPMN" /> 58 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 </plnk:partnerLinkType> <wsdl:binding name="BABEL_BookActivitiesBPMNBinding" type="tns:BABEL_BookActivitiesBPMN"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="BookActivity"> <soap:operation soapAction="http://BABEL_BookActivitiesBPMN/BookActivity" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output><soap:body use="literal" /></wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="BABEL_BookActivitiesBPMN"> <wsdl:port name="BABEL_BookActivitiesBPMNPort" binding="tns:BABEL_BookActivitiesBPMNBinding"> <soap:address location="http://localhost:8081/ode/processes/BABEL_BookActivitiesBPMN" /> </wsdl:port> </wsdl:service> </wsdl:definitions> Figura 46: Documento WSDL del proceso WS-BPEL para la reserva de actividades A continuación se describen algunos de los elementos más relevantes del modelo intermedio, mostrando como éstos han influido en la generación del documento WSDL de la Figura 46 . Por ejemplo, uno de los elementos fundamentales para la generación del WSDL, es el BPELProcess. En este elemento se definen los mensajes, el tipo de elemento que define cada uno de los mensajes y el nombre de la operación. En la Figura 47 se puede ver la información en este ejemplo concreto. Figura 47: Formulario de edición del proceso con la información del proceso de reserva de actividades 59 A partir de esta información se generan: 1) los mensajes y la operación que utiliza estos mensajes. Esto se puede ver en la Figura 46, entre la líneas 25-30 y 32-37 respectivamente; y 2) la importación del o los XSDs que definen el tipo de elemento utilizado por los mensajes. Concretamente, en este caso es un único XSD que se puede ver entre las líneas 16-21 de la Figura 46. Además de la información proporcionada por el elemento BPELProcess, se genera un ParnerLink Type por cada elemento ParnerLink del modelo intermedio y uno generado automáticamente para representar al propio proceso. En este caso, existen dos definiciones, una por el ParnerLink que permite la invocación de los servicios Web de reserva y cancelación de actividades y otro por el proceso de reserva de actividades. Ambos pueden ser vistos entre las líneas 37-43 de la Figura 46. Finalmente, el resto de elementos tales como el Binding y el Service son generados automáticamente utilizando como única información la que contiene el propio WSDL. 3.3.6. Transformación del modelo intermedio al Deploy.xml Al igual que las dos últimas transformaciones, esta transformación es ejecutada una vez que el usuario ha terminado de introducir la información al modelo intermedio. Esta transformación recolecta la información del modelo intermedio generando un documento XML llamado “deploy” el cual permite desplegar el proceso WS-BPEL en el servidor. En la Figura 48 se puede ver el diagrama BPMN que representa esta transformación. Figura 48: Diagrama BPMN de la transformación del modelo intermedio al deploy.xml Básicamente se genera una sección de código en el fichero deploy.xml por cada uno de los ParnerLinks definidos en el modelo intermedio. En esta sección de código se especifica el Port concreto que utiliza el ParnerLink dentro del fichero WS-BPEL. Esta información es necesaria ya que para un mismo servicio Web pueden existir diferentes puertos, por lo que es necesario especificar el puerto usado para el proceso concreto. 60 Ejemplo En el proceso definido para la implementación de la reserva de actividades existen únicamente dos ParnerLinks: 1) el definido para el proceso principal; y 2) el utilizado para hacer las llamadas a los servicios Web de cancelar y reservar actividades. En el primer caso, el puerto es generado automáticamente por la transformación encargada de la generación del WSDL. Como la generación del WSDL no tiene por qué ser ejecutada antes de esta transformación, se ha decidido que el nombre del puerto generado siempre siga la siguiente estructura: “Nombre del proceso + Puerto”. Con ello se consigue que independientemente del orden de las transformaciones, siempre se tenga el nombre del puerto del proceso principal, permitiendo completar la generación del deploy.xml. En el segundo caso, es necesario recolectar la información del modelo intermedio. Como se puede ver en la Figura 49, esta información es introducida por el usuario cuando se crea un nuevo elemento de tipo ParnerLink. Figura 49: Formulario de edición de un ParnerLink con la información de ParnerLink Reserva de Actividad Dada la información explicada se genera el deploy.xml, cuyo código se puede ver en la Figura 50. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <?xml version="1.0" encoding="UTF-8"?> <deploy:deploy xmlns:deploy="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:tns="http://BABEL_BookActivitiesBPMN" xmlns:wsdl1="http://www.example.org/Hotelbooking/"> <deploy:process name="tns:BABEL_BookActivitiesBPMN"> <deploy:active>true</deploy:active> <deploy:retired>false</deploy:retired> <deploy:process-events generate="all" /> <deploy:provide partnerLink="client"> <deploy:service name="tns:BABEL_BookActivitiesBPMN" port="BABEL_BookActivitiesBPMNPort" /> </deploy:provide> <deploy:invoke partnerLink="ActivityBook"> <deploy:service name="wsdl1:Hotelbooking" 61 19 20 21 22 23 port="HotelbookingSOAP" /> </deploy:invoke> </deploy:process> </deploy:deploy> Figura 50: Documento deploy.xml asociado al proceso de la reserva de actividades 3.4. Despliegue en caliente El despliegue en caliente es una de las características más importantes de la herramienta, ya que es fundamental que cuando se cree un nuevo proceso o se modifique uno existente, el resto de procesos no se vean afectados y se mantengan operativos en todo momento. Para realizar el despliegue en caliente se realizan tres operaciones: 1) crear un fichero en el servidor que almacena todos los documentos relevantes para el completo despliegue del proceso; 2) copiar en el fichero creado todos los WSDLs y XSDs utilizados por los servicios Web que son invocados en el proceso; y 3) copiar el documento WS-BPEL que define el proceso, el WSDL asociado a éste y el fichero deploy.xml. Además, se ha implementado un mecanismo de versionado, que permita que el despliegue de un proceso no borre las versiones anteriores de este proceso. Para ello, cada vez que se despliega un proceso, se crea una carpeta con un número de versión ascendente con el fin de no afectar las instancias de los procesos que actualmente se están ejecutando. En el video de demostración que se encuentra en el DVD se puede encontrar un ejemplo de cómo se realiza el versionado. Una vez terminado este último paso, el proceso queda totalmente operativo y disponible para su consumo desde cualquier cliente. 62 Capítulo 4 Caso de estudio En este capítulo se describe el caso de estudio. Este caso demuestra la utilidad y eficiencia de la herramienta para la transformación de un modelo BPMN a un proceso WSBPEL que se muestra en el Capítulo 3. 4.1. Descripción General del Caso de Estudio El caso de estudio elegido consiste en la implementación de una composición de servicios que ofrezca a los usuarios la posibilidad de comprar un paquete de viajes en el que se incluyen vuelos, hoteles, actividades (por ejemplo, buceo, paracaidismo, etc.), coche de alquiler y seguro de viajes. El principal motivo para elegir este caso ha sido la intensa comunicación que se produce entre las empresas del sector de viajes. En este sector es habitual ver a empresas ofreciendo sus productos a través de otras aplicaciones las cuales pertenecen a terceros, consiguiendo que sus productos puedan llegar a mucha más gente. Otra característica importante del sector de viajes, es que los procesos requieren cambios continuamente (por ejemplo, cambio de leyes, nuevos servicios, cambios de tendencias, etc.) y estos cambios tienen que poder ser realizados sin parar sus procesos de negocio en ningún momento. Además, debido a los continuos cambios en el negocio, se necesita una manera de poder reflejar estos cambios de forma fácil en la composición de servicios. Además, es deseable contar con un alto nivel de abstracción para realizar las modificaciones incluso cuando faltan conocimientos de programación. Como consecuencia de estas necesidades, la venta de paquetes de viajes es un buen caso para poner a prueba la herramienta propuesta. 4.2. Requisitos En esta sección se explican los requisitos del sistema para la venta de paquetes de viajes. Para guiar la explicación se utiliza un diagrama BPMN que representa de forma simplificada el proceso seguido por el sistema. El modelo simplificado se puede ver en la Figura 51. 63 Figura 51: Proceso de negocio simplificado para la venta de paquetes turísticos A continuación se explican cada una de las actividades del diagrama y su funcionalidad dentro del sistema de venta de paquetes: Reservar vuelo: El usuario puede buscar los vuelos disponibles en función de la fecha de llegada, la fecha de salida, el lugar de salida y el destino. Una vez que el usuario ha seleccionado un vuelo, se hace la reserva de ese vuelo. Gestión de hotel Esta actividad está formada por varias sub-actividades: 1) Reservar Hotel: permite al usuario la búsqueda de hoteles dado el lugar y la fechas de entrada y salida, y la realización de la reserva del hotel una vez que el usuario lo ha seleccionado. Esta actividad siempre es ejecutada; y 2) Reservar actividad: permite la búsqueda y reserva de actividades dado un hotel. Una actividad puede ser la práctica de algún deporte, visitas turísticas, etc. Las actividades consisten en servicios extra proporcionados por el hotel reservado. La reserva de actividades no siempre está disponible y por lo tanto no siempre se ejecuta. Alquilar coche Esta actividad proporciona la capacidad de realizar búsquedas de coches de alquiler dado el lugar y las fechas deseadas, y una vez seleccionado el vehículo, se realiza la reserva. Seleccionar seguro Esta actividad muestra al usuario los seguros disponibles para el paquete de viajes, permitiendo seleccionar el que más le convenga. 64 Gestión de usuarios Para poder finalizar la compra del paquete de viajes, el usuario debe registrarse. En caso de ya estar registrado, tiene que identificarse con sus datos para poder finalizar la compra. Pagar paquete de viajes Cuando ya se han realizado las reservas de los diferentes productos, se ha seleccionado el seguro deseado, y el usuario se ha registrado o identificado, el usuario realiza el pago del paquete de viajes. Para ello el sistema proporciona al usuario la posibilidad de pagar mediante tarjeta de crédito (VISA y MasterCard). 4.3. Modelo BPMN de la agencia de viajes El diagrama BPMN mostrado en la Figura 52 muestra el proceso final seguido por la agencia de viajes. Debido a su tamaño, se ha mostrado con todos sus componentes comprimidos. Éstos se pueden ver desplegados en el DVD anexo a este documento en la carpeta de información adicional. En general, cada una de las actividades compuestas (por ejemplo, ReltalStar, KingInsurance, etc.) representa la invocación de un servicio Web diferente, y dentro de cada una de ellas se invoca a las operaciones que contiene el servicio Web. No obstante, las actividades encargadas del pago del paquete de viajes (tales como, Payment_KI, Payment_RS) sólo están compuestas de la llamada a la operación de pago de los servicios Web previamente involucrados (no representa a un nuevo servicio Web). La única actividad simple del proceso que es invocada en todos los caminos del proceso es “Show_total_price”. Una actividad simple, a diferencia de las actividades compuestas, implementa una única operación. Además la operación “Show_total_price” es implementada por el propio proceso WS-BPEL, es decir, no invoca a un servicio Web externo. 65 Figura 52: Composición de servicios para la venta de paquetes turísticos A continuación, en la Tabla 2 se explica cada uno de los servicios compuestos mostrados en la Figura 52. En el DVD anexo a este documento, en la carpeta de información adicional, se encuentra la especificación completa de los servicios Web y sus operaciones. 66 KingFlight Esta actividad se encarga de realizar la búsqueda de los vuelos disponibles dados los parámetros introducidos por el usuario y una vez seleccionado, realiza la reserva del mismo. Operaciones Search_Flight: Busca vuelos. Book_Flight: Reserva un vuelo. Payment_KF Esta actividad se encarga de realizar el pago de la reserva de un vuelo. Sólo es invocada si previamente ha sido utilizado el servicio Web KingFlight para realizar la reserva de un vuelo. Operaciones Do_payment: Realiza el pago de la reserva del vuelo. FlightBooking Esta actividad se encarga de realizar la búsqueda de los vuelos disponibles dado los parámetros introducidos por el usuario y una vez seleccionado, realiza la reserva del mismo. Operaciones Look_for_flight: Busca vuelos. Flight_booking: Reserva un vuelo. Payment_FB Esta actividad se encarga de realizar el pago de la reserva de un vuelo. Solo es invocada si previamente ha sido utilizado el servicio Web FlightBooking para realizar la reserva de un vuelo. Operaciones Do_Payment: Realiza el pago de la reserva del vuelo. HotelBooking Esta actividad se encarga de realizar la búsqueda de los hoteles disponibles dado los parámetros introducidos por el usuario y una vez seleccionado, realiza la reserva del mismo. Operaciones Searching_Hotel: Busca hoteles. Hotel_Booking: Reserva un hotel. HotelBookingActivity Esta actividad se encarga de realizar la búsqueda de las actividades disponibles en un hotel y una vez seleccionadas, realiza la reserva de las mismas. Operaciones Search_Activities: Busca actividades. Book_Activities: Reserva actividades. Payment_HB Esta actividad se encarga de realizar el pago de la reserva de un hotel. Sólo es invocada si previamente ha sido utilizado el servicio Web HotelBooking para realizar la reserva de un 73 Capítulo 5 Trabajos relacionados En esta sección se describen los proyectos, herramientas e investigaciones relacionadas con la propuesta que se ha implementado. Esta sección esta dividida en varias partes: 1) en primer lugar se explican y clasifican los proyectos que han implementado algún tipo de transformación parcial entre un modelo BPMN y un proceso WS-BPEL; 2) en segundo lugar se explica un proyecto [56] que propone una extensión para BPELDesigner basada en BPMN; 3) en tercer lugar se explica una extensión [57] sobre el propio lenguaje WS-BPEL para facilitar el completado del WS-BPEL generado a partir de un modelo BPMN; y 4) en último lugar, se habla de la herramienta BPM Petals [58] y de su mecanismo para generar código WS-BPEL completo a partir de un modelo BPMN 2.0. 5.1. Proyectos para la generación de WS-BPEL parcial a partir de modelos BPMN La generación parcial de código WS-BPEL a partir de modelos BPMN es un tema muy trabajado. Muestra de ello es la cantidad de proyecto realizados en este ámbito (ver Tabla 3). Titulo Año A Method of Transition from BPMN to BPEL [14] 2011 Constructing a bidirectional transformation between BPMN and BPEL with a functional logic programming language [59] 2011 Interaction Mismatch Discovery Based Transformation from BPMN to BPEL [60] 2009 Token analysis of graph-oriented process models [61] 2009 Transforming BPMN to BPEL using parsing and attribute evaluation with respect to a hypergraph grammar [62] 2009 A Flexible Transformation Scheme between the 'OR' of BPMN and 'Link' of BPEL [63] 2008 From business process models to process-oriented software systems [46] 2006 Tabla 3: Lista de proyectos para la generación de WS-BPEL parcial Las transformaciones implementadas por estos proyectos se pueden clasificar en función de tres aspectos: objetivo, implementación de la transformación y restricciones que imponen al usuario con respecto al modelado BPMN. A continuación se explica cada una de estas categorías. Objetivo Muchos de [56] los proyectos se centran en proporcionar una solución general a la transformación de un modelo BPMN en un proceso WS-BPEL, como es el caso de BABEL y 74 otros proyectos tales como [14] y [59]. No obstante, estos proyectos solamente soportan un número limitado de elementos BPMN, imponiendo restricciones al usuario en la manera y en los elementos que puede utilizar para modelar el proceso BPMN. En cambio, otros proyectos se centran en aspectos muy específicos. Por ejemplo, el proyecto en [63] proporciona una solución para poder transformar los Gateways OR, o [60] que implementa una transformación que permite como entrada varios modelos BPMN que interactúan entre ellos. Implementación de la transformación Cada aproximación realiza la transformación del modelo BPMN a código WS-BPEL de manera diferente. No obstante, estas aproximaciones se pueden agrupar en dos bloques: 1) las que utilizan un lenguaje formal o matemático intermedio; y 2) aquellas que utilizan una transformación directa, basada en reglas o en reconocimiento de patrones. Un ejemplo del uso de lenguajes formales es el proyecto BABEL [15], el cual implementa una transformación intermedia del modelo BPMN a Redes de Petri [47] antes de generar el código WS-BPEL. Otro ejemplo de ello, es el proyecto [62], que transforma un modelo BPMN en un Hypergraph [64] para transformarlo posteriormente en el WS-BPEL. En general el uso de una capa intermedia formal permite evitar ambigüedades intrínsecas en BPMN con respecto a WS-BPEL y permite aplicar algoritmos de verificación y de optimización. Otros proyectos se centran en implementar soluciones lo más sencillas posibles, tratando de realizar el menor número de transformaciones posibles. Con ello se consiguen soluciones más fácilmente modificables. Un ejemplo de este tipo de solución se puede encontrar en el proyecto [14] que implementa una transformación basada en patrones. Básicamente, en [14] se recorre el modelo BPMN buscando patrones y cada uno de los patrones es transformado dada una serie de reglas en estructuras WS-BPEL. Restricciones en el modelo BPMN Muchos de los proyectos ya mencionados establecen restricciones para el usuario que le indican cómo debe modelar el proceso BPMN y qué elementos BPMN puede utilizar. La restricción más habitual está relacionada con el uso de la Gateways. Específicamente, muchos proyectos obligan al usuario a que cada Gateway que funciona como separador de caminos (“split”), tenga sus correspondiente Gateway de unión de caminos (“join”). Este tipo de restricción se puede ver en el proyecto BABEL y en otros proyectos [62,59]. En cambio, otros proyectos se centran en soportar la mayor cantidad de modelos BPMN, como es el caso del proyecto [46], cuyo principal objetivo es solventar el problema de la mayoría de herramientas que limitan la construcción de modelos BPMN mediante restricciones. Con esto se consigue una solución flexible para el usuario. 75 Para concluir, todos los proyectos explicados hasta el momento, solo soportan la generación de WS-BPEL parcial. Es en este punto es donde nuestra herramienta supera al resto. Específicamente, nuestra herramienta propone una manera para completar el WSBPEL parcial a partir de una herramienta gráfica basada en formularios. No solo eso, sino que además de completarlo lo despliega en el servidor en caliente y utiliza un control de versiones para garantizar la operatividad de cada proceso. 5.2. Extensión para Eclipse BPEL Designer En [56] se plantea una solución” para la creación de procesos WS-BPEL completos utilizando la notación BPMN. Esta solución a diferencia del resto de proyectos mostrados hasta el momento, no implementa transformaciones. Ésta implementa una representación gráfica para el metamodelo de WS-BPEL basada en BPMN, por lo que cada elemento de WSBPEL es representado mediante la notación BPMN. Con ello se consigue evitar las diferencias entre la orientación a grafo de BPMN y la orientación estructurada de WS-BPEL. Para la implementación de esta propuesta, se crea un “plugin” sobre Eclipse BPEL Designer que proporciona una nueva notación gráfica BPMN para representar los procesos WS-BPEL. En la Figura 56 se muestra esta notación gráfica con un ejemplo. Figura 56: Notación BPMN para Eclipse BPEL Designer [56] 76 No obstante, aunque esta solución permite la creación de procesos WS-BPEL completos, la notación gráfica utilizada no es completamente fiel al estándar BPMN. Esto hace que se pierdan las ventajas inherentes al uso del estándar, y que el usuario tenga que familiarizarse con los nuevos elementos. Por lo que, a pesar de ser una solución ingeniosa para la generación de WS-BPEL completo, no deja de ser similar al propio lenguaje gráfico proporcionado por BPEL Designer. A diferencia de esta solución, nuestra herramienta mantiene la notación estándar proporcionada por BPMN mediante el uso de una herramienta gráfica basada en formularios independiente del modelo BPMN. 5.3. BPELscript En [57] se presenta una solución para la creación de procesos WS-BPEL completos, basada en la generación parcial de código WS-BPEL a partir de modelos BPMN y en el uso de un nuevo lenguaje BPELscript, para completar el código generado. El proceso consta de los siguientes pasos: 1) se define el modelo BPMN que representa el proceso a generar; 2) se genera la estructura WS-BPEL básica a partir del modelo BPMN; 3) se transforma el código WS-BPEL generado en código BPELscript; 4) el usuario completa los detalles del proceso utilizando BPELscript; y 5) se transforma el código BPELscript en código WS-BPEL. El principal aporte de esta propuesta es el lenguaje BPELscript, que al ser más similar a un lenguaje de programación clásico, permite al usuario (habitualmente programador) completar el proceso de una manera más sencilla. En la Figura 57 se muestra en el lado izquierdo el proceso WS-BPEL y en el lado izquierdo el equivalente proceso en el lenguaje BPELScript. Por ejemplo, el control de excepciones en el proceso WS-BPEL se hace mediante la estructura “<catch> </catch>” al principio del documento. Esto es muy distinto de como se haría en un lenguaje de programación clásico. Es por ello que en BPELScript esto es transformado en la estructura clásica “try{} catch()” que todo programador conoce. Con ello se quiere conseguir acercar la definición de procesos WS-BPEL a la orientación clásica seguida por los lenguajes de programación tales como Java. Para concluir, aunque la idea de BPELScript puede facilitar la tarea al programador, no supone una gran ventaja para usuarios con pocos conocimientos de programación. Además, es necesario que el usuario aprenda un nuevo lenguaje. Por lo tanto, esta solución esta orientada a un menor grupo de persona que la herramienta explicada en este documento. 77 Figura 57: Comparación entre los lenguajes WS-BPEL y BPELscript [57] 5.4. BPM Petals BPM Petals es una herramienta en proceso de desarrollo bajo licencia AGPL (Affero General Public License) para el modelado en BPMN 2.0. Ésta proporciona un mecanismo para la generación de procesos WS-BPEL completos a partir de modelos BPMN 2.0 [58]. Este proyecto es uno de los más similares a la herramienta para la generación y despliegue de procesos WS-BPEL a partir de modelos BPMN presentada en este documento. Es por ello que se ha decidido hacer una comparación directa entre ambas propuestas:  Ambas propuestas generan código completo y ejecutable. No obstante nuestra propuesta despliega el proceso WS-BPEL directamente en el servidor y establece mecanismos de versionado para garantizar que los procesos se mantengan 100% operativos en todo momento. 78  Petals proporciona los mecanismos para la introducción de la información necesaria para generar un WS-BPEL completo durante la propia definición del BPMN. En cambio nuestra propuesta utiliza una herramienta independiente al modelado BPMN para la introducción de la información faltante. Utilizar una herramienta independiente permite conserva el modelo BPMN intacto (la información de los servicios que implementa el proceso definido en BPMN se encuentra en un modelo independiente). Además la inclusión de información específica del WS-BPEL final mientras se modela el modelo BPMN puede resultar al usuario confuso en comparación a la utilización de formularios proporcionada por nuestra herramienta.  Petals proporciona soporte para BPMN 2.0 mientras que nuestra propuesta utiliza la versión 1.0 de BPMN. En la actualidad hay muchas empresas que utilizan WS-BPEL para ejecutar sus composiciones de servicios Web. Un salto a BPMN 2.0 les sería costoso y en algunos casos aún impensable. Nuestra propuesta podría apoyar a las empresas que utilizan y seguirán utilizando WS-BPEL. 5.5. Conclusiones Si bien se ha visto que hay una gran cantidad de herramientas, investigaciones y artículos en el ámbito de la generación de código WS-BPEL a partir de modelo BPMN, pocos se han centrado en el desarrollo de WS-BPEL completo y ejecutable. Las conclusiones obtenidas han sido las siguientes:  No todo modelo BPMN puede ser transformado en un proceso WS-BPEL ya que la orientación utilizada por BPMN difiere sustancialmente de la utilizada por WS-BPEL. Al no existir una transformación definitiva actualmente o ampliamente aceptada, nuestra herramienta ha sido desarrollada de forma que puede ser utilizada en unión a cualquier transformación de BPMN a WS-BPEL. Esto resulta en reusabilidad y adaptabilidad.  La no modificación de la notación BPMN es clave si se quieren mantener las ventajas inherentes al estándar. Es por ello que la herramienta se ha implementado separando el modelo BPMN y la información faltante para completar el WS-BPEL. Con ello se consigue una mayor abstracción. Además, tener la información de los servicios Web finales en un modelo independiente permite la rápida generación de diferentes versiones de un mismo proceso BPMN. 79 Capítulo 6 Conclusión y trabajos futuros En este capítulo se resumen los aspectos fundamentales de la propuesta, y se muestran los posibles trabajos futuros. 6.1. Conclusión Mediante la presente investigación se ha dado un paso adelante en la especificación y generación automática de procesos WS-BPEL sobre motores de procesos usando modelos y cumplido los objetivos planteados al principio de este documento. En primer lugar, se desarrolló una herramienta que transforma un modelo BPMN en código WS-BPEL completo. Esta herramienta se creó mediante: 1) la utilización del proyecto BABEL que genera código WS-BPEL incompleto; 2) creación de una herramienta gráfica que permite al usuario introducir toda la información faltante en el WS-BPEL generado por BABEL en un modelo intermedio; y 3) generación y despliegue de los documentos necesarios para completar el código WS-BPEL a partir del modelo intermedio. Con ello, se ha conseguido elevar el nivel de abstracción en la creación de procesos de negocio basados en WS-BPEL, solventando la complejidad inherente en WS-BPEL y consiguiendo procesos fácilmente modificables y por lo tanto con mayor escalabilidad. En segundo lugar, se consiguió el despliegue en caliente de un proceso WS-BPEL en el servidor mediante: 1) la incorporación en la herramienta de un sistema de versionado que genera una carpeta diferente cada vez que se despliegue el proceso; y 2) copiando todos los documentos generados en la carpeta generada por el sistema de versionado. Gracias al despliegue en caliente y al versionado de los procesos se ha conseguido que éstos estén operativos en todo momento, que el servidor no tenga que ser reiniciado cada vez que se genera un nuevo proceso y que las modificaciones de un proceso no afecten a los clientes que estén utilizando el proceso en ese mismo momento. En tercer lugar, para garantizar su futura inclusión en Moskitt y su validez a lo largo del tiempo, se ha construido una herramienta fácilmente adaptable, la cual puede ser añadida a Moskitt y utilizada en unión al resto de extensiones utilizadas por éste. Por último, se creó y utilizó un caso de estudio realista para demostrar la utilidad de la propuesta. 6.2. Trabajos futuros Aunque como se ha podido ver, la propuesta ha conseguido solucionar todos los problemas que nos habíamos planteado y cumplir con todos los objetivos, aún quedan muchas cosas que se podrían hacer. 80 En primer lugar, como ya se ha comentado a lo largo de este documento, la propuesta aquí mostrada ha sido desarrollada con el objetivo de incorporarse como extensión a Moskitt en unión a otras propuestas que se están desarrollando ahora en el grupo PROS. Por ejemplo, hay una propuesta que está trabajando Pedro J. Santana que permitirá a partir de modelos BPMN extendidos generar las interfaces de usuario de aplicación Web que den soporte a los procesos de negocio especificados. Con este tipo de extensiones y herramientas se pretende complementar la herramienta MOSKitt para dar un completo soporte a la especificación e implementación de procesos de negocio complejos. Por ello, el siguiente paso de esta propuesta será la incorporación de ésta sobre la herramienta Moskitt y la optimización de la comunicación entre la propuesta y las extensiones que se tienen actualmente o que están siendo incorporadas en Moskitt en este mismo ámbito. En segundo lugar, la utilización de BPMN 2.0 [65] para la creación y ejecución de procesos de negocio, en lugar de WS-BPEL es un tema muy discutido actualmente en la Web [66,67]. Como se ha visto en la memoria, el lenguaje BPMN aporta grandes ventajas tales como que el usuario definir procesos de negocio de forma gráfica e intuitiva. No obstante, conseguir que un modelo BPMN pueda ser directamente ejecutable sin necesidad de otros lenguajes, ha obligado a aumentar el número de elementos necesarios para la definición de los procesos de negocio en BPMN 2.0. Esto hace que el nuevo estándar BPMN 2.0 sea más complejo que su predecesor y que definir un proceso en BPMN 2.0 directamente ejecutable, tenga una complejidad similar o mayor que definirlo sobre WS-BPEL. Sin embargo, los nuevos elementos definidos en el estándar BPMN 2.0 pueden resultar interesantes en unión a la herramienta que aquí se ha implementado. Mediante la utilización de BPMN 2.0 se podrían simplificar las transformaciones y reducir aún más la complejidad con la que el usuario introduce la información faltante a través de la herramienta. Por ejemplo, han surgido nuevos elementos que especializan al tipo tarea (tales como, Receive Task, Send Task, Service Task) que permiten diferenciar cuando una tarea de BPMN representa una entrada de información, una invocación a un servicio o una salida de información respectivamente. En tercer lugar, se propone una ampliación a la herramienta implementada. Ésta consiste en la implementación de una “Time Machine” es decir una herramienta para el control de las diferentes versiones de un proceso de negocio. Ésta permitirá al usuario gestionar las diferentes versiones de un mismo proceso, permitiéndole: 1) seleccionar la versión actual de ejecución; 2) volver a anteriores versiones y 3) llevar un historial de qué versión está en ejecución en cada momento y cuáles procesos están actualmente operativos. Para la implementación de la “Time machine”, se propone el desarrollo de un “Plugin” para eclipse, incorporado a la herramienta aquí presentada, que lleve un historial 81 con todos los procesos generados a partir de la herramienta, y las versiones de cada proceso. La unión de la “Time Machine” con la herramienta implementada debe ser invisible para el usuario, facilitando al usuario la gestión de los procesos y versiones generadas. Siguiendo con la idea de la “Time Machine” se podría añadir cierta inteligencia a ésta para que en función del estado de los servicios (por ejemplo, si está en funcionamiento, no está en funcionamiento, o está saturado con demasiadas llamadas) escogiese la versión más optima. Esta herramienta será un sistema inteligente para la selección de la mejor versión en todo momento. Esto se podría realizar mediante la incorporación de reglas, que dotarán a la “Time Machine” de la capacidad de decidir qué versión elegir, es decir, cómo comportarse en cada situación. Por último, para dar más valor a la propuesta que se ha mostrado a lo largo de este documento, se podrían realizar pruebas con usuarios para medir el desempeño de ellos usando la herramienta. Con este fin, se medirá el tiempo necesario para la implementación de un proceso WS-BPEL con y sin la herramienta. Esto además de proporcionar validez a la herramienta aquí presentada, permitirá mejorarla, y adaptarla en función de las necesidades de los usuarios. 6.3. Información adicional Se ha adjuntado a este documento un DVD con información referenciada a lo largo de toda la memoria. Este DVD contiene: 1) el código fuente de la herramienta; 2) un manual de usuario que explica como utilizar y configurar la herramienta; 3) un video en el que se muestra la herramienta en ejecución; 4) la especificación completa de los servicios Web propios utilizados para construir el caso de estudio y 4) varios diagramas e información adicional. 82 Bibliografía [1] OASIS. (2006) Reference Model for Service Oriented Architecture 1.0. [Online]. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html [2] R. Heffner, L. Fulton, M. Gilpin, H. Peyret, K. Vollmer, and J. Stone, "Topic Overview: ServiceOriented Architecture," Forrester, June, vol. 8, p. 4, 2007. [3] G. H. Alférez, and V. Pelechano, "Context-Aware Autonomous Web Services in Software Product Lines," in Proceedings of the 2011 15th International Software Product Line Conference.: IEEE Computer Society, 2011, pp. 100-109. [4] F. Leymann, D. Roller, and M. T. Schmidt, "Web services and business process management," IBM Systems Journal, vol. 41, no. 2, pp. 198 -211, 2002. [5] OASIS. (2007) Web Services Business Process Execution Language Version 2.0. [Online]. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html [6] InfoWorld. BPEL: estandarización de la gestión de procesos. [Online]. http://www.iworld.com.mx/iw_SpecialReport_read.asp?iwid=4135&back=2&HistoryParam= [7] A. Lapadula, R. Pugliese, and F. Tiezzi, "A formal account of WS-BPEL," in Coordination Models and Languages.: Springer, 2008, pp. 199-215. [8] J. Malek, M. Laroussi, A. Derycke, and H. B. Ghezala, "Model-driven development of contextaware adaptive learning systems," in Advanced Learning Technologies (ICALT), 2010 IEEE 10th International Conference on.: IEEE, 2010, pp. 432-434. [9] OMG. (2008) Business Process Model And Notation (BPMN) 1.1. [Online]. http://www.omg.org/spec/BPMN/1.1/PDF/ [10] Consellería de Infraestructura, Territorio y Medio Ambiente. Moskitt. [Online]. http://www.moskitt.org/moskitt/ [11] Apache Software Foundation. Apache ODE. [Online]. http://ode.apache.org/ [12] Oracle. Oracle BPEL. [Online]. http://www.microsoft.com/biztalk/en/us/default.aspx [13] Microsoft. Microsoft Biztalk. [Online]. http://www.microsoft.com/biztalk/en/us/default.aspx [14] M. Lu, Q. Cai, and H. Li, "A method of transition from BPMN to BPEL," in Advanced Intelligence and Awareness Internet (AIAI 2011), 2011 International Conference on., 2011,