Integración de procesos de negocio de alto nivel con soluciones EAI

Transcripción

1 Integración de procesos de negocio de alto nivel con soluciones EAI Gustavo Álvarez, Estudiante de Maestría Universidad de los Andes Resumen. En la actualidad las organizaciones están orientadas a procesos de negocios que atraviesan distintas unidades funcionales. Usualmente, cuentan con aplicaciones que dan soporte, de manera puntual, a sus diferentes áreas. Cuando los procesos de negocio son modelados y ejecutados sobre máquinas de workflow, existe la necesidad de integrar esta ejecución automatizada con las aplicaciones. Esta integración exige un manejo de las diferentes instancias del proceso, administración de los datos del proceso y de las aplicaciones y consistencia entre el proceso y las aplicaciones. En este artículo presentamos una propuesta para lograr esta integración. La propuesta se basa en la definición de un lenguaje de dominio específico que permite describir la interacción entre el proceso y las aplicaciones. La integración expresada utilizando nuestro lenguaje es transformada a elementos de ejecución sobre un motor de workflow y una solución EAI. Palabras Claves. Procesos de negocio, workflow, integración de aplicaciones empresariales, Lenguajes de dominio específico. 1. INTRODUCCIÓN Hoy día las organizaciones basan su estrategia en los procesos de negocio [1]. Con la definición explicita y el seguimiento de la ejecución de los procesos se busca obtener resultados que puedan llegar a ser medibles y mejorables de manera constante. El modelamiento es la herramienta para describir un proceso. En el modelo se definen las actividades, el flujo de control entre ellas, la información de interés así como también, los participantes en la ejecución del proceso. El modelo permite un entendimiento a todos los participantes directos o indirectos del proceso, por ejemplo, tanto para quien modela el

2 2 Gustavo Álvarez proceso, como usuarios finales ó para quienes desarrollan aplicaciones que permiten ejecutar un proceso de manera automatizada. Por otro lado, las organizaciones también poseen un conjunto de aplicaciones empresariales. Estas aplicaciones están orientadas a apoyar funciones específicas de un área de la organización. Un ejemplo es una aplicación para el área financiera, otra para el área de recursos humanos y así en otras áreas. De igual forma, existen herramientas que permiten la automatización en la ejecución de los procesos. Estas herramientas son llamadas workflows. Los workflows permiten la ejecución controlada y coordinada de un conjunto de actividades de forma semi-automática o automática [2]. En las actividades existe la posibilidad del intercambio de información ya sea dentro del proceso o hacia el exterior. En estos motores, los participantes de un proceso pueden ser usuarios finales como también aplicaciones. Los motores ejecutan procesos definidos en un lenguaje particular que permite definir el flujo de información, la secuencia de actividades y sus condiciones de ejecución. Integrar los procesos de negocio de las organizaciones con aplicaciones empresariales partiendo de un modelo de alto nivel, requiere la participación de elementos tecnológicos y de negocio. Desde el punto de vista tecnológico significa llevar el proceso a un motor de ejecución de workflow, comunicarlo con aplicaciones de diferentes tecnologías y ubicar instancias del proceso. En la perspectiva de negocio, implica establecer en que actividades y de qué forma participa una aplicación y mantener consistencia en la información tanto del proceso como de las aplicaciones. En este artículo presentamos una propuesta para definir la integración de los procesos de negocio con aplicaciones empresariales. Los procesos son expresados en un lenguaje de alto nivel como BPMN [3]. Se complementa la relación entre el proceso y las aplicaciones utilizando nuestro lenguaje Process Integration Language (PIL). Tanto el proceso BPMN como lo expresado en PIL son transformados a un ambiente ejecutable. En nuestro caso realizamos una transformación a WS-BPEL[4] como lenguaje ejecutable de procesos y a Eleggua[5] como infraestructura de integración de aplicaciones. Ilustramos esta propuesta con un ejemplo de un proceso de negocio en el contexto de una empresa desarrolladora de software. El resto del artículo está organizado como sigue. La sección 2 presenta el contexto global del trabajo. La sección 3 se describe el problema en la integración entre la ejecución de procesos de negocio y aplicaciones empresariales. De igual forma, se ilustra un caso de estudio en el contexto de un proceso de desarrollo de software. La sección 4 presentamos la estrategia del trabajo. En la sección 5 presentamos el lenguaje de dominio específico PIL como solución a la integración de procesos de negocio con soluciones EAI, sus requerimientos, el porqué es una solución al problema y una breve descripción de su

3 3 Gustavo Álvarez sintaxis. En la sección 6 se explica las transformaciones para un motor WS-BPEL y una solución de integración de aplicaciones Eleggua. Finalmente en la sección 7 explicamos la implementación y la arquitectura general de la solución para el caso de estudio. Finalmente, se discuten conclusiones sobre el trabajo presentado y los resultados parciales del trabajo. 2. CONTEXTO DEL TRABAJO ELEGGUA: Infraestructura para la integración de aplicaciones Eleggua es una infraestructura para la integración de aplicaciones basada en eventos asíncronos que permite automatizar la interacción entre las aplicaciones según reglas de cooperación. Esta infraestructura recurre al uso de eventos distribuidos y servicios Web como mecanismos de comunicación [6]; permite lograr la integración de una manera centralizada con bajo acoplamiento y sin intervenir en la ejecución o implementación de las aplicaciones a integrar. Eleggua apoya la integración de aplicaciones con procesos de negocio, sin convertirse en una maquina de ejecución de procesos. Con Eleggua, se pueden integrar aplicaciones heterogéneas, ya que transforma los datos de las aplicaciones para ser comprendidos por otras aplicaciones. Existe un modelo de integración que se basa en un sistema de notificación de eventos y delegados de las aplicaciones a integrar. Este sistema de notificación es el encargado de recibir los eventos de las aplicaciones para luego direccionarlos a las otras aplicaciones interesadas. Los delegados se encuentran en cada aplicación, son los intermediarios entre una aplicación y el SNE y además poseen la información de las reglas para la integración. Las reglas de cooperación se componen de observaciones, eventos lógicos y reglas evento condición-acción (ECA) que se definen a través de diagramas de actividad. Partiendo de la aplicación origen se describe que funcionalidad va a generar un evento y con qué características. Luego, en la aplicación destino se describe con que funcionalidad reacciona al momento de recibir el evento.

4 4 Gustavo Álvarez Figura 1. Componentes de la infraestructura ELEGGUA El modelo general de una solución con la infraestructura Eleggua se encuentra en la Fig. 2. El Distributed Event Middleware (DEM) es el sistema de notificación de eventos y los delegados de las aplicaciones son Cooperation Proxy. CELINIHEL: Cumbia Eleggua Infrastructure Implementation Helper CELINIHEL [7] es una herramienta que facilita la implementación para que procesos de negocio se integren a soluciones EAI. Funciona como una asistente, el cual requiere de unos insumos para generar los componentes requeridos para la integración. Adicionalmente solo aplica para la integración entre una máquina de workflow CUMBIA [8] y la solución EAI Eleggua. El proceso no se modela a través de herramientas de alto nivel como BPMN y se pasa directamente al lenguaje propio de ejecución del motor CUMBIA. CELINIHEL es una herramienta que aplica como solución solo para un motor CUMBIA y la infraestructura Eleggua [9]. Esto se debe porque solo recibe la definición del proceso en el lenguaje de ejecución de CUMBIA y además los componentes de integración son una extensión a componentes del motor de CUMBIA. En este caso las organizaciones tienen que adaptarse a la tecnología y no la tecnología al negocio como debe ser. De igual forma, la ubicación de las instancias depende de la información almacenada por Eleggua en cuyo caso no es responsabilidad de este. Finalmente, la forma de controlar las actividades del proceso implica conocer a fondo CUMBIA ya que se deben extender ciertos componentes que son propios de esta herramienta. La propuesta de nuestro trabajo aborda los problemas de CELINIHEL de forma más genérica. Así mismo, nuestra propuesta y CELINIHEL se encuentran dentro de la misma línea de investigación del grupo. WS-BPEL: Web Services Business Process Execution Language Web Service Business Process Execution Language (WS-BPEL). WS-BPEL es un estándar para la ejecución de procesos [10]. Se pueden ejecutar procesos internos o intercambiar mensajes para procesos externos. Para el caso de los procesos internos se permite ejecutar de manera ordenada actividades del proceso. Es un lenguaje de orquestación, lo que quiere decir, que describe el mecanismo para administrar y automatizar la coordinación de sistemas complejos como aplicaciones, servicios o middleware. Con WS-BPEL solo se puede comunicar a través de Servicios Web y por ello es un lenguaje de orquestación. Por lo tanto, no está pensado para integrarse con recursos como sistemas legados. Esto es un inconveniente porque algunas las aplicaciones de las organizaciones son sistemas legados. Esto limita el uso de WS-BPEL porque existe una

5 5 Gustavo Álvarez gran variedad de tecnologías que utilizan las aplicaciones para su comunicación que no se deben desechar. Otro inconveniente, es que no existe interacción para múltiples servicios vistos como un todo. Esto sucede, cuando una actividad de un proceso la cual es vista como un todo, involucra la participación de varias aplicaciones, por lo tanto, WS-BPEL no puede en una sola actividad involucrar la participación de más de una aplicación. Por otro lado, los procesos ejecutados en WS-BPEL no reflejan lo que se modela en notaciones de alto nivel de un proceso de negocio. 3. PROBLEMA Basado en lo anterior el problema es integrar en la ejecución de procesos de negocio las aplicaciones de la organización. La integración entre la ejecución del proceso y las aplicaciones tiene retos tanto de negocio como de tecnología. Desde el punto de vista de negocio se refiere a la administración de la información del proceso y control en la ejecución de las actividades. En el caso tecnológico, se refiere a cómo una aplicación va a comunicarse con el proceso, por ejemplo, si la comunicación va a ser a través de los Servicios Web u otros elementos de comunicación. Desde el punto de vista de negocio la administración de la información del proceso se divide en dos elementos. El primero es identificar que información es de interés para el proceso y que proviene de las aplicaciones. El problema es que la información está dispersa en las aplicaciones y que no toda es de interés para el proceso. Por lo tanto se debe definir qué información tienen las aplicaciones que es de interés en un actividad específica. Por lo cual una actividad en particular requiere de conceptos específicos que maneja una aplicación de un área, pero otra actividad puede requerir otros conceptos diferentes que así mismo provengan de otras aplicaciones. El otro elemento de la administración es la consistencia de la información entre el proceso y las aplicaciones. Con el constante intercambio de información entre el proceso y las aplicaciones es importante mantener una consistencia de la misma en ambas partes. Esta consistencia mantiene y da sentido de negocio tanto al proceso como a las áreas de la organización. Si el proceso dentro de su información establece que un concepto ha cambiado, pero la aplicación de interés no sabe de ese cambio, se van presentar errores en la ejecución del proceso o en las aplicaciones. Por lo tanto se debe describir que hacer en las actividades con la información para mantener esa consistencia entre el proceso y las aplicaciones.

6 6 Gustavo Álvarez Otro elemento desde el punto de vista de negocio, es el control de las aplicaciones en la ejecución del proceso. El control no se refiere al orden en que se ejecutan las actividades sino a controlar en que actividad participa una aplicación y de qué forma. Se debe establecer en qué actividades del proceso intervienen las aplicaciones. Es posible que en una actividad intervenga una aplicación, pero en otra actividad otra aplicación. Esta interacción varía, porque en una actividad una aplicación está en capacidad de ejecutar esa labor, pero en otra actividad quizás ésta no tenga la capacidad. Así mismo, es importante establecer cómo se da la comunicación entre el proceso y las aplicaciones. En unas actividades el proceso puede invocar el llamado a una aplicación para realizar una actividad desde un punto de vista funcional. Como también, una aplicación puede invocar al proceso para informar que algo ya se realizó o simplemente enviarle información para ser evaluada y así poder mantener consistencia en la información. Para el caso tecnológico son tres elementos que se deben tener en cuenta al momento de la integración. El primero, es el tipo de comunicación que se da entre las aplicaciones y el motor de ejecución del proceso. Para el caso de un motor WS-BPEL esto debe realizarse a través de Servicios Web. De igual forma hay comunicación entre las aplicaciones, las cuales son sistemas heterogéneos. Por lo tanto debe existir un elemento que permita no solo la comunicación entre el proceso y las aplicaciones sino también entre las mismas aplicaciones. Por el mismo hecho de ser sistemas heterogéneos se requiere una transformación a los datos que maneja cada aplicación, con el fin de ser entendidos tanto por las aplicaciones como por el motor de procesos. Este es la segunda característica a tener en cuenta tecnológicamente. Finalmente, se requiere localizar las instancias del proceso cuando una aplicación interactué con el proceso. Esto se debe a que las aplicaciones no manejan el concepto de instancias de proceso. La identificación de las instancias se debe hacer a través de la información de las aplicaciones, pero el mecanismo de localización depende del motor de workflow. Por ejemplo para el caso de WS-BPEL una alternativa para ubicar la instancia puede ser a través de los Correlations Sets. Caso de Estudio Para el modelo de los procesos utilizamos Business Process Management Notation (BPMN). BPMN es una notación estándar para modelar a alto nivel los procesos de negocio de una organización [11]. La Fig. 1 presenta el diagrama BPMN para el proceso de creación de Releases. Describe la generación de una nueva versión de una aplicación de software partiendo de un grupo de

7 7 Gustavo Álvarez solicitudes de cambio. Las solicitudes de cambio son especificaciones detalladas por parte del cliente, donde solicita mejora, ajuste o modificación a un requerimiento de una aplicación. Figura 2. Modelamiento BPMN del Proceso de Releases. Este proceso inicia cuando se quiere crear una nueva versión la cual contiene un conjunto de solicitudes de cambio a ser atendidas. Enseguida, el líder de planeación debe evaluar las solicitudes de cambio para determinar cuáles solicitudes de las iniciales entran en la nueva versión. Para cada solicitud que entra en la nueva versión se asigna la implementación a un desarrollador. Al finalizar la asignación de las solicitudes el líder de planeación se debe finaliza la planeación. Para cada desarrollador que le fue asignada la solicitud debe realizar la implementación correspondiente según su planeación. Ya con todas las solicitudes atendidas, se debe generar la nueva versión del producto por parte del líder de configuración. En nuestro ejemplo, durante las actividades del proceso de Releases los usuarios utilizan dos aplicaciones existentes. La primera se llama DotProject [12] que se encarga de dar soporte sobre la administración de proyectos. En esta aplicación a los usuarios crean y cierras tareas. La otra se llama ChangeSet [13], la cual es una herramienta para administración de configuraciones. En esta aplicación, los usuarios pueden realizar la administración de las solicitudes de cambio. 4. ESTRATEGIA Con el objetivo de integrar las aplicaciones existentes en la ejecución de procesos de la organización, planteamos: - Complementar la información provista en el modelo del proceso con información relacionada a la integración en un lenguaje de dominio específico (DSL) [14]. Un lenguaje de dominio específico permite describir conceptos específicos de un problema específico como lo es esta integración.

8 8 Gustavo Álvarez - Transformar el proceso de negocio de alto nivel y la integración expresada en el lenguaje de integración en elementos ejecutables sobre una plataforma de workflow y de EAI específicas. El arquitecto debe definir en el lenguaje de dominio específico los datos del proceso, en qué actividad se ejecuta una funcionalidad de una aplicación y en qué sentido se da la comunicación, es decir del proceso a la aplicación o al revés. También debe establecer cómo los datos del proceso son afectados al intercambiar información entre la aplicación y el proceso. Partiendo del modelo del proceso en BPMN y nuestro lenguaje de dominio específico se definimos unas reglas de transformación que traduzca a un lenguaje de ejecución de procesos y los componentes necesarios para que las aplicaciones se comuniquen con el proceso a través de la solución EAI. Para este trabajo, el resultado está orientado hacia Web Service Business Process Execution Language (WS-BPEL) como lenguaje de ejecución de procesos y Eleggua como herramienta para la integración entre las aplicaciones y el proceso. El motor de workflow de WS-BPEL va a permitir que el modelo de alto nivel en BPMN sea ejecutado. Eleggua por ser una solución EAI va a permitir comunicar diferentes aplicaciones de diferentes tecnologías. Con Eleggua se resuelve el problema de comunicación y tipos de datos de las aplicaciones y el proceso. La razón es porque el motor de workflow va a ser visto como una aplicación más por Eleggua. 5. PROCESS INTEGRATION LANGUAGE (PIL) PIL se caracteriza por ser independiente de cualquier tecnología, sólo hace referencia a un proceso definido en BPMN. La sintaxis de PIL es muy similar a la de JAVA [15] en cuanto a elementos de asignación, operaciones básicas, constructores y comentarios y referencia ísi mismo de un proceso con la palabra reservada this. Existen en PIL conjunto de bloques de programación principales para definir cómo las aplicaciones interactúan con el proceso. Definición del Proceso El bloque process es la unidad principal del lenguaje. Define todo el comportamiento entre un proceso de negocio y las aplicaciones. La definición para un proceso comprende los atributos del proceso con su nombre y tipos de dato, las actividades que van a interactuar con las aplicaciones y finalmente los eventos que son la representación de la interacción con las aplicaciones. En la Fig. 3 se presenta la definición del bloque.

9 9 Gustavo Álvarez Figura 3. Bloque process para el Proceso de Releases según PIL. Atributos Este bloque permite la definición de tipos de datos complejos, es decir caracterizar atributos que se conforman a partir de otros atributos. Para el caso del proceso se llaman atributos del proceso, en las actividades se llaman variables locales y en la definición de un tipo de dato complejo son características del tipo de dato complejo. En cualquiera de los tres casos estos atributos pueden ser de tipo primitivo como numéricos o cadenas de caracteres o también complejos que se definen con el bloque data. Dentro del proceso de Release existe un atributo que es el proyecto. Este atributo indica a quien corresponde la nueva versión del producto. El atributo proyecto está compuesto por un identificador, nombre y una descripción. En la Fig. 4 se muestra como son las características de un tipo de dato complejo en PIL a través del bloque data. Figura 4. Definición del tipo de dato complejo Proyecto a través del bloque data. De la misma forma en que se describen las características para un dato complejo como proyecto, así mismo, se definen los atributos del proceso y las variables locales de las actividades. En la Fig. 5 se muestra la declaración de un atributo del proceso llamado numerosolicitudes.

10 10 Gustavo Álvarez Figura 5. Definición del tipo de dato complejo Proyecto. Constructores Los constructores son sentencias que permiten indicar con cuáles parámetros se inicia un proceso y qué hacer cuando se instancie un proceso. En un proceso pueden existir varios constructores. Los constructores se identifican por ser un bloque con sentencias agrupadas y donde su nombre es el mismo que el nombre del proceso. En el caso del proceso de Release se envían unos datos iniciales para el proceso, los cuales están encapsulados dentro del tipo de dato complejo Release que se encuentra definido en la Fig. 6. Esta información inicial es: el líder de planeación y de configuración, las solicitudes iniciales para la nueva versión y la información del proyecto. En la Fig. 6 se encuentra el constructor del proceso de Release. Eventos Figura 6. Constructor del proceso de Release. Un evento es el medio de interacción entre el proceso y las aplicaciones. El evento representa los mensajes que recibe o envía el proceso con respecto a la solución EAI. La declaración se define con un nombre y una lista de parámetros que es la información a ser intercambiada. Al igual que el bloque data esta declaración tiene que ir dentro del bloque process. En el proceso de Releases debe generarse desde el proceso un evento a DotProject de crear la tarea de planeación. En esta actividad se debe enviar el nombre, la descripción y el

11 11 Gustavo Álvarez identificador del proyecto y el identificador del líder de planeación. En la Fig. 7 se encuentra la declaración de eventos del proceso de Releases. Figura 7. Declaración de eventos en PIL. Actividades Las actividades definen lo que se debe realizar con respecto a las aplicaciones. Dentro del bloque se pueden declarar variables locales, operaciones de asignación y generación ó recepción de eventos del proceso con respecto a las aplicaciones. Con lo anterior se controla en que actividad participa una aplicación y como se mantiene la consistencia entre la información del proceso y las aplicaciones. Una actividad puede definir actividades más específicas, como es el caso del proceso de Releases con la actividad Asignar Solicitudes de Cambio. Toda actividad tiene que estar dentro del bloque process o dentro de otra actividad. Para explicar mejor se muestra la actividad de Crear Tarea de Planeación del proceso de Releases. La declaración del evento se encuentra en la Fig. 7. En la Fig. 8. se encuentra la actividad de crear tarea de planeación. Nótese que en la actividad se declaran variables locales y se les asigna el valor muy similar a la sintaxis del lenguaje JAVA. Así mismo, se genera el evento createplanningtask cuyos parámetros son el nombre, la descripción del proyecto y el identificador del líder de planeación. Figura 8. Definición de una actividad cuando genera un evento. Otro caso, es cuando el proceso de Release espera que se haya asignado una solicitud de cambio a un desarrollador. La declaración del evento se encuentra en la Fig. 7. En la Fig. 9 se encuentra la definición de la actividad. Nótese que se declaran variables locales, pero a unas no se les asigna valor hasta cuando el evento sea recibido por el proceso, para

12 12 Gustavo Álvarez mantener consistencia en la información. De igual forma, se recibe el evento assignchangerequest cuyos parámetros son el identificador del desarrollador, la descripción, el nombre y el identificador de la solicitud de cambio. Figura 9. Definición de una actividad cuando recibe un evento. 6. TRANSFORMACIONES PARA LA EJECUCIÓN DEL PROCESO DE NEGOCIO Las transformaciones están orientadas hacia WS-BPEL y ELEGGUA. Los elementos de entrada para las transformaciones son el modelo BPMN y la descripción del proceso en el PIL. Con el modelo de alto nivel, se genera un proceso en WS-BPEL preliminar que contiene elementos básicos del proceso. Es decir, la definición de las actividades, pero sin comportamiento definido, sin involucrar los datos del proceso ni tampoco los servicios que se invocan o reciben de la solución EAI. Esta transformación no hace parte del trabajo, ya que existen herramientas que realizan esto y porque este trabajo no es una transformación de BPMN a WS-BPEL. Las transformaciones de PIL se orientan hacia cuatro elementos y se muestra en la Fig 10 y que se explica a continuación. El primero, es la definición de comportamiento de cada actividad en lenguaje orientado a aspectos [16] para WS-BPEL. Se crea un aspecto por cada actividad descrita en PIL. Con los aspectos, se modulariza el comportamiento de cada actividad. Es una ventaja porque es sencillo evaluar e identificar claramente cada comportamiento de una actividad de un proceso. Así mismo, este alcance hace que exista relación con respecto a lo definido en PIL y lo que se agrega en cada aspecto. Es más mantenible transformar de PIL a aspectos para luego ser entretejidos, que de PIL directamente al WS-BPEL Preliminar. Esto porque, los resultados son granulares y así se puede enfocar en una actividad específica y no en todo el proceso. Finalmente no se convierte en una transformación intrusiva con el BPEL Preliminar. Es decir, la forma de

13 13 Gustavo Álvarez generar un proceso de negocio no es modificar todo el BPEL Preliminar sino complementarse a través de los aspectos. Figura 10. Esquema general de las transformaciones. El segundo elemento es la definición de las WSDL [17]. Estas WSDL van a ser usadas tanto por el WS-BPEL como también por el componente BPEL-Finder que se explica más adelante. Toda aquella relación del proceso con el exterior debe ser descrita en WSDL. Es decir, los eventos declarados en PIL son lo que determinan el contenido de las WSDL para interactuar con la Eleggua. El siguiente elemento son los XSD [18] de los datos complejos. Los XSD definen la estructura y restricciones en documentos XML[19] para tipos de datos que no están definidos por la W3C [20]. Por lo tanto estos tipos de datos complejos definidos en PIL y que son propios del proceso de negocio deben ser descritos para ser usados tanto por el WS-BPEL como por las WSDL. Finalmente un componente intermediario entre el motor WS-BPEL y la solución Eleggua. El componente se llama BPEL-Finder. Entre sus responsabilidades el componente resuelve el problema de comunicación entre las aplicaciones y el proceso de negocio. La solución EAI se comunica sólo con el BPEL-Finder para el envío o recepción de eventos. Así mismo, se encarga de asignar un identificador único en el momento de iniciar una nueva instancia de proceso que permita identificar y localizar una instancia. El mecanismo para que este componente ubique las instancias es a través de los correlations set [4] en WS-BPEL. En cada envío de un evento del EAI al proceso se debe buscar a partir de la

14 14 Gustavo Álvarez información del evento a que instancia del proceso corresponde esta información. Esta relación no es trivial porque puede depender de la cantidad de datos y el valor de esos datos para diferentes eventos. Por ello, el desarrollador debe complementar la implementación de cada evento que recibe el proceso donde relacione los datos del evento con el identificador de la instancia correspondiente. Los componentes propios de Eleggua que permiten que tanto las aplicaciones como el BPEL-Finder puedan comunicarse, se generan a partir de otro trabajo llamado EAI-Rules [21]. EAI-Rules es una herramienta que permite definir las reglas de cooperación en las aplicaciones usando diagramas de actividad en UML [22]. Estos diagramas especifican quien genera el evento, a quien le interesa y que se debe hacer cuando se reciba un evento. Con EAI-Rules esta interacción se lleva a un nivel más alto y pueden hacerse transformaciones de forma automática para que las aplicaciones se integren a Eleggua. 7. IMPLEMENTACION En términos de implementación, los aspectos que genera PIL se hacen en lenguaje de PADUS [23] y luego son entretejidos con el WS-BPEL preliminar para obtener generar el WS-BPEL final donde se describe el comportamiento de las actividades y los datos del proceso. PADUS es una extensión para WS-BPEL orientado a aspectos que permite la composición de procesos de negocio más modulares. Permite adicionar comportamiento sobre un WS- BPEL existente de manera modular. Esta adición de comportamiento puede hacerse en puntos específicos usando un logic pointcut language. El lenguaje se describe a través de: El modelo de joinpoint, los lenguajes de advice y pointcut, los módulos de aspectos y el lenguaje de despliegue del aspecto. Los joinpoints son puntos bien definidos para un WS-BPEL donde una funcionalidad va a ser agregada. Estos pueden definirse para actividades de comportamiento p.e <invoke> como estructurales p.e <while>. Un pointcut especifica el conjunto de joinpoints. Estos pueden ser usados para especificar los joinpoints donde el comportamiento adicional va a ser agregado. El advice es utilizado para especificar el comportamiento a ser agregado según los joinpoints que se define en un pointcut y se realiza a través de XML. Los módulos del aspecto especifican donde un advice debe ser agregado e información global a ser usada por el aspecto. Un advice se puede agregar antes (before), despues (after) o en el momento (around). El lenguaje de despliegue del aspecto especifica como el aspecto se debe aplicar sobre el WS-BPEL a ser entretejido y consiste de instanciación y composición. El primero se refiere aplicar un aspecto a un proceso en concreto y el segundo

15 15 Gustavo Álvarez es responsable de especificar la precedencia en caso que múltiples aspectos aplique sobre un mismo joinpoint. Con la generación de los aspectos, el paso siguiente es entretejerlos con el BPEL- Preliminar para obtener nuestro proceso ejecutable. Ya entretejido y con los componentes adicionales puede desplegarse el proceso en el motor de workflow y conectar el BPEL- Finder con la solución Eleggua. En la Fig 11 se describe la arquitectura general de la solución a partir del caso de estudio. Nótese que se encuentra el proceso de negocio el cual se despliegue en un motor de workflow. A dicho proceso se conecta el intermediario entre el proceso y la solución Eleggua el cual es el BPEL-Finder. Eleggua es mediador entre las aplicaciones y el BPEL- Finder para que estos se puedan comunicar. Finalmente encontramos los usuarios quienes son aquellos que hacen uso de las aplicaciones de la organización. Figura 11. Arquitectura general de la solución para el proceso de releases. 8. CONCLUSIONES Este artículo propusimos un alcance para la integración de procesos de negocio de alto nivel con soluciones EAI. Nuestra estrategia se dividió en dos partes que son: el DSL y las transformaciones. Esta integración es de alto nivel porque se parte del modelo del proceso en BPMN. Nuestro lenguaje de dominio especifico denominado Process Integration Language. PIL es un lenguaje independiente de cualquier tecnología, por lo cual puede aplicarse para otros motores de workflow y soluciones EAI. PIL Permite complementar comportamientos que no se definen en el modelo de alto nivel del proceso. Así mismo, es un lenguaje para facilitar la labor del arquitecto de software en el momento de integrar procesos de negocio y aplicaciones empresariales. PIL permite:

16 16 Gustavo Álvarez - La administración de la información del proceso a través de la declaración de tipos de datos que pueden ser usados como atributos del proceso, variables locales o mensajes entre aplicaciones. - Integración entre el proceso y las aplicaciones por medio de la declaración de eventos. Los eventos definen que información es la que se debe enviar o recibir. - Definir el comportamiento de una actividad. Este comportamiento puede ser modificar los datos del proceso como también generar o recibir eventos en el proceso de negocio para lograr consistencia entre de información tanto del proceso como las aplicaciones. Las transformaciones generan aspectos en PADUS para WS-BPEL. Estos aspectos modularizan el comportamiento de las actividades de un proceso lo que conlleva a mantenibilidad y separación de comportamientos un proceso. Adicionalmente, se generan componentes a lado del proceso para el envío y recepción de eventos sin olvidar la instancia a la que corresponde dicho evento. Hasta el momento hemos generado los aspectos definiendo su joinpoint y pointcut. Estamos trabajando sobre la generación del contenido de los advice el cual es lenguaje WS-BPEL. Para la definición de la gramática del lenguaje y transformaciones estamos utilizando y específicamente Xtext [25] y Xpand [25] respectivamente. REFERENCIAS [1] Smith, Howard y Fingar, Peter. Business Process Management (BPM): The Third Wave. Tampa: Meghan-Kiffer Press, [2] Coalition, The Workflow Management. WFMC. [En línea] [3] Group, OMG Object Management. Object Management Group/ Business Process Modeling Notation Specification [En línea] [4] TC, OASIS Web Services Business Process Execution Language (WS-BPEL). [En línea] Oasis, [5] López Giraldo, Nicolás. Infraestructura de eventos para cooperación de aplicaciones. Bogota: Universidad de los Andes, [6] Rubby Casallas, Nicolás López, Darío Correal. Eleggua: An Event Infrastructure for Application Cooperation. Presented at the COEA 2005 (Component Oriented Enterprise Applications) workshop, part of the NODE conference in Erfurt, Germany, September GI Edition Lecture Notes in Informatics, ISSN [7] Zambrano, Eduard. Potenciando la unión entre Workflows y soluciones EAI. Bogotá: Universidad de los Andes, 2007.

17 17 Gustavo Álvarez [8] M. Sánchez, E. Zambrano, O. González, N. López. Potenciando la Unión entre Workflows y Soluciones EAI, 2º Congreso Colombiano de Computación, Bogotá D.C., April, [9] Sánchez M., Villalobos J. A Flexible Architecture to Build Workflows Using Aspect- Oriented Concepts. Proceedings of the 12th International Workshop on Aspect-Oriented Modeling, Brussels, Belgium, [10] BPEL [11] BPMN [12] DotProject, The Open Source Project Management tool. Documentación disponible en [13] Grupo Qualdev. Proyecto Changeset. Tomado de [14] Domain-Specific Languages: An Annotated Bibliography. Deursen, Arie van, Klint, Paul y Visser, Joost. Amsterdam : Centrum voor Wiskunde en Informatica (CWI), [15] Sun Microsystems, Inc. JAVA PROGRAMMING LANGUAGE. Tomado de [16] AOSD. Aosd glossary. Web Site, [17] World Wide Web Consortium (W3C), Web Service Description languege Version 1.1. Tomado [18] World Wide Web Consortium (W3C), XML Schema 1.1. Tomado [19] World Wide Web Consortium (W3C), Extensible Markup Language (XML). Tomado [20] World Wide Web Consortium (W3C). Tomado [21] xeai-rules: executable models to simulate enterprise application cooperation. In Proceedings to the 2006 ACM symposium on Applied computing, Dijon, France, April ISBN: Rubby Casallas, Milen Vela, Catalina Acero, Nicolás López [22] UML, Unified Modeling Language, Tomado [23] Isolating Process-Level Concerns using Padus. Braem, Verlaenen, Joncheere y Vanderperren [24] Sven Effinge. Xtext reference documentation. Technical report, OpenArchitectureWare.org, [25] Kadura C. Effinge, S. Openarchitectureware 4.3 xpand language reference. Technical report, OpenArchitectureWare.org, 2008