Monitoreo de procesos distribuidos en el cloud

Transcripción

1 Monitoreo de procesos distribuidos en el cloud Una propuesta arquitectónica José Martinez Garro Universidad Nacional de La Plata UNLP La Plata, Argentina Patricia Bazán LINTI Universidad Nacional de La Plata UNLP La Plata, Argentina Abstract El desembarco de BPM en el Cloud ha producido un cambio en la concepción tanto del diseño como de la ejecución de los procesos de negocio. Los entornos distribuidos en este contexto ofrecen posibilidades de cómputo que resultan ventajosas para los procesos, y las mismas resultan mayormente aprovechables al ser consideradas bajo un esquema de descomposición. Este concepto ha sido introducido en BPM permitiendo a los procesos de negocio ejecutarse tanto en un ambiente de cloud como en uno embebido, aprovechando así las ventajas de ambos esquemas bajo la consideración de criterios como sensibilidad en los datos, altas prestaciones de cómputo y la portabilidad de los sistemas intervinientes. Un aspecto aún inexplorado en la bibliografía actual es el monitoreo de los procesos que se ejecutan bajo un esquema de descomposición. En el presente artículo proponemos una arquitectura para un sistema de monitoreo de procesos distribuidos, considerando distintos factores de diseño, tales como la transparencia de localización y los datos necesarios para el rastreo de instancias en el sistema de cloud. Keywords BPM, Cloud Computing, Descomposición procesos, Monitoreo. I. INTRODUCCIÓN Business Process Management (BPM) constituye una metodología adoptada actualmente por muchas organizaciones para gestionar y optimizar sus procesos de negocio. Estos últimos pueden ser vistos como un conjunto de actividades realizadas coordinadamente, ya sea por humanos, por sistemas de información o por ambos, para alcanzar un objetivo de negocio. En este contexto, un BPMS es una herramienta que permite obtener versiones ejecutables de los procesos de negocio, favoreciendo su coordinación y monitoreo. Internamente estas herramientas contienen una máquina de ejecución que coordina y ejecuta los procesos de negocio paso a paso. Cada instancia de proceso es monitoreada por el BPMS y los usuarios participan de la ejecución de dichas instancias [6]. La adopción de un BPMS en una organización puede constituir un proyecto costoso tanto desde el punto de vista de la inversión que debe realizarse en software y en hardware, así como en los recursos humanos entrenados para desplegar y mantener la solución. Por otra parte, la escalabilidad puede ser un aspecto a considerar en estas compañías dado que el motor de procesos es capaz de atender simultáneamente una cantidad limitada de instancias de procesos [25]. de En este sentido, la necesidad de escalar y la naturaleza netamente colaborativa que subyace a la ejecución de procesos de negocio, ponen en juego la necesidad de contar con entornos descentralizados que permitan optimizar el uso de la tecnología y dar respuesta a la necesidad de crecimiento de las organizaciones. Es así que las arquitecturas basadas en cloud ofrecen una buena alternativa por su enfoque flexible y ágil. En particular, los procesos de negocio colaborativos en los cuales interactúan distintos sectores de una misma o de diferentes organizaciones, ofrecen un potencial de optimización a través de la combinación de técnicas de clouding y BPM. Para sacar provecho de esta arquitectura, surge la necesidad de dividir los procesos de negocios en procesos colaborativos individuales que puedan ejecutarse indistintamente de manera embebida o en el cloud. Esto es lo que se conoce como descomposición de procesos, siendo esta un área extensamente analizada en la literatura actual. Retomando la definición de BPMS observamos que, además de ejecutar instancias de procesos, los mismos juegan un papel muy importante en cuanto a control y monitoreo de las mismas. En un entorno tradicional, estas actividades son netamente centralizadas, lo cual comienza a flaquear al considerar la descomposición de procesos. El presente trabajo propone una arquitectura centralizada de procesos de negocio descompuestos a lo largo de una arquitectura cloud. Dicha aplicación de monitoreo debe proveer transparencia de la localización (la cual es variable por el efecto de la descomposición), así como deberá recuperar los rastros de ejecución de las instancias distribuidas para ofrecer técnicas de monitoreo comúnmente consideradas en los BPMS tradicionales. II. TRABAJOS RELACIONADOS En la bibliografía actual encontramos diferentes tendencias asociadas a los tópicos del presente artículo. Son numerosos los autores que ya han considerado la descomposición de procesos, proponiendo distintas metodologías para el particionamiento lógico y físico de los mismos, siguiendo criterios asociados a la privacidad de los datos, el costo de transferencia de los mismos a través de la red y la portabilidad de las aplicaciones relacionadas con las actividades del proceso. Detallamos a continuación algunos de ellos.

2 En [25] se propone un método para descomponer un proceso de negocio en múltiples procesos que se despliegan en las instalaciones propias y en la nube en función del rendimiento y requisitos de sensibilidad, expresándose los mismos como anotaciones sobre las actividades y los datos. Este modelo de distribución da cuenta de la factibilidad de contar con un modelo de distribución de procesos. Otro método para distribuir procesos es presentado en [29]. Por otra parte, [26] aborda la ejecución de procesos BPEL en diferentes modelos de entrega, de IaaS para SaaS, poniendo en evidencia las necesidades del middleware subyacente. El aporte de este trabajo valida la necesidad de contar con un monitoreo distribuido de procesos,al igual que [27] donde se describe un método general para el seguimiento de coreografía de procesos e incluso aborda las alternativas de monitoreo on line y off line. Asimismo en [20] se encuentra un buen análisis del concepto de cloud workflow, mostrando escenarios y casos de aplicación del mismo. Bajo este concepto aparece de planificación y monitoreo automático y las características más importantes del seguimiento de actividades de procesos en la nube. Por último en [28] se presenta una solución automatizada para planificar los pasos de un worklow sobre hosts subutilizados utilizando BPEL. Se presenta una implementación concreta sobre Amazon. Este análisis del estado del arte da cuenta que no se encuentra aún explorado el concepto de monitoreo sobre procesos descompuestos en forma práctica. Los antecedentes prestenados e incluso propuestas de nuestra misma autoría [30] desarrollan conceptos de implementación para aplicaciones que soporten procesos descompuestos en un entorno de cloud. Siguiendo dichos rastros es posible construir una aplicación centralizada que permita monitorear los procesos distribuidos en la red, brindando una visión unificada de los mismos que brinde transparencia de localización al usuario acerca de cada una de las instancias involucradas. III. BMP Y CLOUD Con el rápido desarrollo de IT en el contexto del lanzamiento y ejecución de arquitecturas basadas en cloud, las compañías se enfrentan con nuevos problemas. En particular, los procesos de negocio colaborativos ofrecen un potencial de optimización a través de la combinación de técnicas de clouding y BPM. Un factor común entre ambos conceptos es el enfoque flexible y ágil. El paradigma de computación en el cloud puede considerarse un facilitador de la combinación mejorada de arquitecturas orientadas a servicios, así como un procedimiento ágil con respecto a la gestión de procesos de negocio. Pero este potencial depende de las condiciones de los distintos frameworks, las cuales pueden ser apreciadas desde un aspecto técnico tanto como económico. A. Vista técnica Desde un punto de vista técnico se pueden identificar tres dimensiones para el diseño, implementación y operación exitosos de herramientas de BPM en un ambiente de cloud: programación, integración y seguridad. Programación: los sistemas complejos y distribuidos son altamente realizables en el campo de IT actual. En conexión con el objetivo de alcanzar una mayor usabilidad y flexibilidad, esta complejidad representa nuevos requerimientos para la Ingeniería de Software. Para resolver este problema es necesaria la adopción de nuevos lenguajes. Así, recayendo sobre nuevos conceptos y técnicas innovadoras, los esfuerzos invertidos en desarrollo han sido reducidos a convertir la complejidad de estos nuevos aspectos en algo manejable. Integración: la integración puede ser dividida en integración de datos, integración de funciones e integración de procesos. A la luz de los desafíos involucrados, el tópico de la integración juega un rol fundamental en distintos escenarios. Por ejemplo, un workflow basado en cloud puede controlar actividades variables distribuidas más allá de las fronteras de las compañías. Para una ejecución no problemática de varias instancias de proceso se necesitan interfaces de integración y métodos estructurados. Seguridad: la seguridad puede ser dividida en tres categorías: seguridad funcional, de la información y de los datos. Todas estas categorías tienen una relevancia significante para BPM, especialmente en cuanto a los grids de servidores de procesos de negocio. La seguridad funcional especifica como el estado actual se corresponde con el estado deseado de funcionalidad. La seguridad de información se enfoca en los cambios o extracciones de información no autorizados. La seguridad de los datos se encarga de los datos relacionados con el proceso. Bajo estos critrerios, desde un punto de vista técnico, se debe responder a la pregunta de qué procesos de negocio son más apropiados para ejecutar en una arquitectura basada en cloud. Posibles inconvenientes a este despliegue son la existencia de opciones insuficientes de integración, o interfaces de programación de aplicaciones que deban ser tomados en consideración [1] [2] [3]. B. Vista económica Se pueden listar dos dimensiones desde el punto de vista económico: Disponibilidad: los servicios que son provistos por una infraestructura de cloud pueden ser accedidos en cualquier momento. Basados en un alto nivel de abstracción, la personalización e instalación se vuelven significativamente más fáciles. En adición a esta simplificación, el usuario final es capaz de trabajar con el servicio en forma inmediata. Riesgo de inversión: en el contexto de los distintos modelos de facturación variable como el de pago por transacción, el sistema orientado a cloud resulta más accesible que un sistema de licenciamiento tradicional.

3 IV. BENEFICIOS E INCOVENIENTES BPM basada en cloud da a los usuarios la posibilidad de usar software de una manera de pago por uso, en lugar de forzarlos a emprender grandes inversiones en software de BPM, hardware y mantenimiento como se da en el caso de los sistemas de licenciamiento tradicional. Los sistemas pueden escalarse hacia arriba y abajo de acuerdo a las necesidades de los usuarios, lo cual significa que los mismos no deben preocuparse acerca del sobre o bajo aprovisionamiento de recursos, gracias a la alta adaptabilidad provista en la actualidad por los prestadores de servicios de cloud, tal como podemos ver en la Figura 1. El presente esquema, por otro lado, tiene varios puntos bajos. Al poner un BPMS en la nube, los usuarios pueden llegar a perder control sobre los datos sensibles. Este aspecto resulta no menor al considerar que los procesos de negocio dentro de una organización gestionan información de gran importancia para la misma y sus miembros. Por otro lado, la eficiencia y efectividad de las actividades que no son altamente computacionales pueden no incrementarse por ponerlas en el cloud, sino al contrario, estas actividades pueden volverse más costosas. Por ejemplo, una actividad que no es intensamente computacional podría necesitar procesar cierto monto de datos. La transferencia de los datos a la nube puede tomar más tiempo que transmitirlos a una versión embebida instalada localmente. Incluso la misma puede resultar aún mayor que la necesidad real de procesamiento. Además, los costos de la actividad pueden incrementarse debido a que la transferencia de datos es uno de los elementos de facturación en un sistema de cloud computing, debido a la alta disponibilidad de la conexión [1] [2] [5] [6]. cómputo intensivo, por otra parte, no siempre se benefician en este entorno. La performance de una actividad que está corriendo en un entorno embebido debería ser mayor que en la nube debido a la cantidad de datos que deben ser transferidos para poder ejecutar la misma. Estas actividades pueden a la vez resultar costosas al ser la transferencia uno de los criterios de facturación del cloud. Para analizar la combinación entre un esquema embebido y uno de cloud se plantean tres aspectos: arquitectura, control de flujo y optimización de la distribución. Arquitectura: en la mayoría de las soluciones BPM el motor de procesos, las actividades y los datos del proceso se localizan en el mismo lado, tanto en un sistema embebido como en el cloud. Existen escritos que introducen el modelo PAD (Proceso-Actividad- Datos) de la Figura 2 como una posibilidad de distribución de BPM en el cloud. En el mismo el motor de procesos, las actividades involucradas en el mismo y sus datos están separadamente distribuidos. El modelo PAD define cuatro posibilidades de distribución: 1) El primer patrón de solución es el enfoque tradicional de BPM donde todos los elementos están distribuidos en el usuario final. 2) El segundo patrón es útil cuando el usuario ya tiene un sistema BPM, pero las actividades con intensidad de cómputo se localizan en el cloud para incrementar su performance. 3) El tercer patrón es útil para los usuarios que aún no poseen un sistema BPM, así pueden usar el esquema de cloud de manera de pago por uso, y las actividades sin intensidad de cómputo y los datos sensibles se pueden localizar en el usuario final. 4) El cuarto patrón es el modelo basado en cloud donde todos los elementos se localizan en la nube. Figura 1: Esquemas de servicio en el Cloud V. COMBINACION CLOUD Y ON-PREMISE La protección de la privacidad es una de las barreras para ejecutar BPM en un ambiente de cloud. No todos los usuarios desean poner sus datos sensibles en la nube. Además es necesario observar la portabilidad de productos y versiones, y su disponibilidad en un esquema de cloud. Otro problema no menor es la eficiencia. Las actividades de cómputo intensivo se pueden beneficiar en la nube debido a la escalabilidad y a la alta disponibilidad de fuerza de cómputo. Las tareas que no sean de Figura 2. Esquema PAD de distribución [6]

4 Los procesos de negocio consisten de dos tipos de flujos: de control y de datos. Los flujos de control regulan las actividades que se ejecutan y la secuencia de las mismas, mientras que los flujos de datos determinan cómo estos se transfieren de una actividad a la otra dentro del proceso. Los motores de BPM deben lidiar con el control de ambos flujos. Un flujo de datos puede contener datos sensibles, por lo tanto, cuando se despliega un motor de BPM en el cloud, se debe proteger el contenido de los mismos. Un ejemplo de arquitectura propuesta sería aquella en que el motor del lado del cloud solo lidia con flujos de datos usando identificadores de referencia en vez de datos reales. Cuando una actividad necesita datos sensibles, la transferencia de los datos a la actividad se maneja bajo supervisión del usuario dentro de un túnel de encriptación. Los datos sensibles se almacenan en el lado del usuario final, y los datos no sensibles se almacenan en el cloud. Este esquema permite que los datos sensibles no viajen indiscriminadamente a través de la web. Distribución óptima: los costos de un sistema de cloud han sido propósito de estudio en diversos artículos. Existen distintas fórmulas para calcular la distribución óptima de las actividades, donde las mismas pueden ubicarse en la nube o en un sistema embebido. El cálculo toma en cuenta los costos de tiempo, los costos monetarios y los costos por el riesgo de privacidad. Mediante el uso de estas fórmulas los usuarios pueden hacer una estimación de los costos de desplegar partes de sus aplicaciones en un sistema embebido y en la nube. Debemos recordar que un criterio clave desde el punto de vista económico en un sistema de cloud es la tasa de transferencia de datos desde y hacia el servidor [2] [5] [6] [9]. VI. DESCOMPOSICION DE PROCESOS Es posible generalizar la distribución e identificar un quinto patrón en el cual el motor de procesos, las actividades y los datos se despliegan en la nube y en el usuario final. Esta solución presenta dos beneficios potenciales: 1) El motor de procesos regula el flujo de control y el flujo de datos. Una actividad recibe datos del motor de procesos y luego de su ejecución los datos que son producidos se pasan de nuevo al motor de procesos. Consideremos ahora que una secuencia de actividades se ubica en la nube, mientras que el motor de procesos se despliega en el usuario final. Cada actividad utiliza los datos de salida de la actividad previa como entrada. Los datos no se pasan directamente de una actividad a la otra sino que son enviados al motor de proceso primero. Debido a que la transferencia de datos es uno de los factores de facturación en el modelo en cuestión, estas situaciones pueden volverse más caras cuando se transfieren grandes cantidades de datos entre actividades. Para evitar este problema se puede agregar un motor de procesos al cloud, el cual regula el flujo de control y el flujo de datos entre las actividades situadas en él. Cuando una secuencia de actividades se localiza en el cloud, los datos se regulan por el motor de procesos en el cloud, lo cual reduce la cantidad de datos a ser transferidos entre este y el sistema embebido. 2) Cuando la nube no se encuentra accesible, los usuarios pueden ejecutar los procesos de negocio en forma completa en el sistema embebido hasta que el primero vuelva a estar disponible. Para poder correr un mismo proceso de negocio en dos motores de proceso separados, el mismo debe ser dividido en dos procesos individuales. Puede llegar a ser conveniente para los usuarios del BPMS tomar una lista de distribución del proceso de negocio y sus actividades, la cual puede ser automáticamente transformada en dos procesos de negocio, uno en el cloud y otro en el sistema embebido. La comunicación entre ambos sistemas puede ser descripta mediante un lenguaje de coreografías, como BPEL [18] [19]. El monitoreo del proceso de negocio es más complicado ahora, debido a que el mismo ha sido subdividido en dos partes. Como una solución, se puede desarrollar una herramienta de monitoreo para el proceso original, mediante la combinación de los detalles de monitoreo de los procesos individuales [11] [12] [14]. Una aproximación posible para manejar la descomposición del proceso es identificar la estructura y la semántica del mismo. Cuando se identifican las dependencias de control y de datos, se pueden investigar las consecuencias de mover ciertas actividades del sistema embebido al cloud y viceversa. Cuando se conocen las consecuencias de la distribución de actividades, se puede crear una transformación de modelo en la cual un proceso de negocio y una lista con marcas se usan para crear dos procesos individuales, uno para el cloud y otro para el usuario final. Además, se puede generar una descripción de la coreografía para describir la comunicación entre ambos procesos de negocio utilizando algún lenguaje estándar, como BPEL [4] [6] [10] [13]. VII. MONITOREO DE PROCESOS EN EL CLOUD El mayor de los problemas de poseer un esquema de procesos particionado es la recuperación y monitoreo de las distintas instancias distribuidas (ya sea en un sistema embebido o dentro del cloud), y a su vez lograr dar un esquema integrador de las mismas bajo la óptica del proceso original al cual pertenecen. Para enfrentar dicho inconveniente hemos diseñado una solución que comprende una arquitectura de componentes distribuidos e intercomunicados que se describe a continuación. En primer lugar será necesario asociar las distintas instancias de proceso iniciadas de manera encadenada, a los fines de poder recuperar

5 información sobre las mismas accediendo a los distintos servidores intervinientes. El esquema de ejecución de los procesos descompuestos consiste en encadenar el flujo de las instancias correspondientes a los subprocesos particionados. Así, al finalizar una instancia en un servidor, esta inicia automáticamente una nueva instancia de la partición de proceso siguiente, en el servidor que corresponda de acuerdo a la arquitectura de distribución. Para esto, cada nodo del esquema distribuido debe ser capaz de comunicarse con el nodo siguiente para poder iniciar instancias y recabar así información sobre las mismas. Es decir, dada una instancia iniciada en un servidor de la arquitectura, debemos ser capaces de obtener, no solo los datos propios de la misma, sino también de cualquier instancia que esta haya desencadenado en otro servidor [23] [24]. A. Bonita Open Solution: uso de API y conectores Existen distintas maneras de implementar el encadenamiento de instancias. En nuestro caso hemos optado por utilizar Bonita Open Solution como BPMS [30]. De esta manera, una vez realizado el esquema del particionamiento del proceso original en los distintos servidores intervinientes siguiendo criterios tales como el uso de datos sensibles, la transferencia de datos y la portabilidad de aplicaciones, hemos hecho uso de la API y los conectores que provee dicho BPMS para la creación de instancias y recuperación de su información utilizando clases Java. Estas clases hacen uso de la API de Bonita como librerías, permitiendo autenticarse contra el servidor de procesos, iniciar una instancia en el mismo, recuperar la información de dicha instancia, setear su información de contexto a través de las variables de proceso y desencadenar su ejecución. Dichas clases son invocadas dentro de la definición de proceso utilizando conectores. Se ha incluido en cada definición de proceso la información necesaria para poder comunicarse con otro servidor Bonita dentro de la arquitectura, y a través del uso de conectores poder iniciar instancias en dicho servidor. Así, todas las instancias al finalizar ejecutarán el conector que permite a través del uso de la API iniciar una instancia de la partición siguiente del proceso, encadenando así de manera automática la ejecución del flujo de proceso [27] [28] [29]. B. Front-end de visualización centralizada Ante este encadenamiento resulta fundamental que cada instancia sea capaz de almacenar, no solo su información propia, sino también la información de las instancias desencadenadas por ella en otros servidores. De esta manera, al acceder a la instancia inicial del proceso es posible recuperar la información de la instancia subsecuente, y así de manera continuada rastrear el flujo completo del proceso. Una vez recuperada toda la cadena de ejecución en los distintos servidores, se deberá proveer una aplicación de visualización que se encargue de reunir los datos obtenidos y mostrarlos de manera integrada. Lo más importante en este aspecto es poder lograr transparencia de monitoreo para el usuario, es decir, que el mismo no se vea forzado a distinguir el servidor en el cual se ejecutó cada actividad, sino que pueda poseer una visualización integrada de las distintas instancias y observarlas como una misma entidad. La implementación de la presente característica fue realizada mediante una aplicación web residente en el cloud. La misma fue localizada allí para poder acceder a cada uno de los servidores intervinientes, ya sean cloud o embebidos, y garantizar el acceso de los usuarios a la misma desde cualquier punto. Para ello es importante que la aplicación posea un catálogo de todos los servidores existentes en la arquitectura con su información de localización actualizada. Cada uno de los servidores intervinientes posee una copia de un servicio web (getinstanceservice), el cual recibe el identificador de una definición de proceso y retorna información de cada una de las instancias existentes en dicho servidor asociadas a la definición enviada como parámetro. La información retornada incluye identificación de la instancia, estado actual (en ejecución, completada, suspendida), actividad actual en caso de no finalización, fecha de inicio y fecha de finalización. De esta manera, la aplicación web residente en el cloud envía a cada uno de los servidores intervinientes una invocación del web service con la definición de proceso seleccionada como parámetro y recibe la información de las instancias asociadas. Luego esta información será visualizada en una interfaz web, donde el usuario puede seleccionar una instancia en particular y observar sus detalles. Para ello la aplicación consta de otro servicio web (getinstanceactivityservice) a través del cual le puede solicitar a cada servidor interviniente el detalle de las actividades asociadas a dicha instancia. La información retornada incluye el identificador de la actividad, participante asociado, fecha de inicio, estado actual y fecha de finalización. Una vez finalizada esta etapa de recolección, recordemos que cada instancia contiene a su vez la información de las instancias que ha desencadenado en otros servidores de la arquitectura. De esta manera, la aplicación web deberá concatenar la información recibida de las distintas instancias intervinientes y permitirá así al usuario observar los detalles de monitoreo de manera integrada y transparente, sin indicar al mismo la información del servidor donde se ejecutaron, logrando así transparencia en cuanto a su ubicación [6] [7] [8] [17] [18]. C. Arquitectura de la aplicación Observamos en la Figura 3 ([25] [26]) los distintos componentes distribuidos identificados en el diseño de la arquitectura, así como la relación interna entre los mismos y con el usuario. La solución se encuentra compuesta por tres nodos principales: el cloud, el sistema embebido o tradicional y la aplicación de monitoreo. El cloud funciona como contenedor principal del sistema BPM, de la aplicación de monitoreo, de la API Rest utilizada por los equipos de desarrolladores que necesitan integrar la aplicaciones con el motor de procesos y de un eventual servicio de geolocalización que permita asignar a los clientes móviles la versión del servicio más conveniente para su ejecución de acuerdo a la distancia en que se encuentran. Por otro lado encontramos los componentes de tipo embebidos, es decir, aplicaciones BPM tradicionales que

6 pertenecen a las organizaciones y que por distintas razones como sensibilidad en los datos o portabilidad de las aplicaciones puede decidirse no colocarlas en el cloud. Estos nodos a los fines funcionales cumplen una función equivalente al componente de tipo cloud, aunque poseen restricciones de acceso y fuerza de cómputo menor comparados con los primeros. El tercer componente es el relacionado con el monitoreo. Es utilizado por el portal o aplicación de monitoreo y se encarga de devolver información sobre instancias y actividades ejecutadas en cada uno de los nodos de la arquitectura distribuida. Los servicios getinstance y getinstanceactivity fueron construidos conjuntamente con la aplicación de monitoreo, y son ejecutados bajo demanda por esta última. Se comunican con los servidores de proceso correspondientes a través de la API (en nuestro caso, Bonita), y se encargan de retornar, en primer lugar, información sobre las instancias iniciadas en cada uno de los servidores, y una vez accedidas las mismas, retornar datos sobre las actividades que las componen. Figura 4: Diagrama de comunicación de aplicaciones Figura 3: Arquitectura de la aplicación y localización de usuario (TOGAF) D. Comunicación de componentes Así mismo, considerando cada uno de los componentes presentados en la arquitectura, hemos analizado la comunicación de cada uno de los mismos a través de un diagrama de comunicación de aplicaciones (Figura 4). En el mismo podemos observar las aplicaciones intervinientes más importantes, sus actores principales y la intervención de los diferentes componentes de software distribuidos [25] [26]. Podemos observar a su vez los distintos perfiles de usuario involucrados en la ejecución de los componentes de la arquitectura. Mientras que el rol preponderante en la ejecución de los procesos es el participante de las actividades, el sitio de monitoreo resulta importante para el analista de negocios, así como para los administradores de la arquitectura que puedan optimizar los servicios o componentes del proceso. Una característica en común entre la aplicación de ejecución de los procesos y la de monitoreo es la transparencia de localización. Los usuarios no deberían necesariamente ser notificados del cambio de entorno de ejecución, en caso que se trate de un proceso descompuesto cuyas actividades se encuentran en distintos servidores. Esto resulta útil a los fines de permitir a los mismos seguir poseyendo una visión unificada del proceso, más que una visión particionada cuya principal razón de existencia se deba al aprovechamiento de los recursos técnicos, razón muchas veces ajena al usuario promedio. También podemos visualizar en el gráfico como ambos componentes, tanto el de ejecución como el de monitoreo acceden indistintamente a los nodos embebidos o cloud, a los fines de recabar información sobre cada una de las instancias iniciadas en los servidores distribuidos.

7 VIII. CONCLUSIONES Como hemos podido observar BPM, así como muchas otras especialidades dentro de IT han sufrido variantes debido a los diferentes modelos de servicios disponibles en el cloud [15] [20] [21]. Esto ha obligado a los especialistas a considerar nuevas variantes de diseño e implementación de procesos que permitan hacer uso de las distintas ventajas que ofrece el citado paradigma. Ante la posibilidad de hacer uso de capacidad de cómputo ilimitada y alta disponibilidad, surgen esquemas de descomposición de procesos que permiten particionar un mismo proceso a lo largo de una arquitectura de servidores distribuidos. Si bien esta aproximación permite un uso eficiente de los recursos tecnológicos, así como la protección de los datos sensibles de la organización, no necesariamente resulta fácil de implementar, y muchas veces queda supeditada a la infraestructura de cloud subyacente y el servidor de procesos seleccionado. En el presente artículo hemos hecho uso de Bonita Open Solution por tratarse de un producto libre, y que posee una API de programación que permite, a través del uso de conectores, acceder a los distintos servidores de la arquitectura. Sin la presencia de este último componente resulta muy dificultoso pensar en iniciar instancias en distintos servidores y permitir así encadenar el flujo de ejecución de un proceso descompuesto y distribuido. Por otro lado, como hemos dicho con anterioridad, si bien la descomposición de procesos es un tema altamente explorado en la literatura actual, no ocurre lo mismo con el tópico referente al monitoreo de los procesos particionados. Dicho tema a simple vista no resulta de resolución trivial, ya que en un esquema de procesos de negocio tradicionales la fuente de información a monitorear se encuentra en el mismo nodo que ejecuta y monitorea los procesos, mientras que en un entorno distribuido las instancias se encuentran en distintos servidores. Por esta razón son necesarios mecanismos que permitan rastrear los datos de las instancias ejecutadas, así como encadenar las mismas para proveer una perspectiva de integración a la luz del proceso original descompuesto. En la actualidad nuestro interés de investigación está centrado en el perfeccionamiento de la aplicación de monitoreo, apuntando a que la misma permita distintos filtros de visualización a los usuarios de la misma. Esto apunta a poder monitorear de manera eficiente cada nodo de la arquitectura y optimizar eventualmente la ejecución del proceso sobre alguno de los mismos. Por otro lado también resulta de interés analizar distintas modificaciones a la notación BPMN existentes en la bibliografía actual que permitirían incluir en los modelos de proceso semántica relacionada con la descomposición, así como la interconexión entre servidores distribuidos [16] [17] [22]. REFERENCES [1] T. Kirkham, S. Winfield, T. Haberecht, J. Müller, G. De Angelis, "The Challenge of Dynamic Services in Business Process Management", University of Nottingham, United Kingdom, Springer, 2011 [2] M. Minor, R. Bergmann, S. Görg, "Adaptive Workflow Management in the Cloud Towards a Novel Platform as a Service", Business Information Systems II, University of Trier, Germany, 2012 [3] M Mevius, R. Stephan, P. Wiedmann, "Innovative Approach for Agile BPM", eknow 2013: The Fifth International Conference on Information, Process, and Knowledge Management, [4] Dr. Manuel Goetz, "Integration of Business Process Management and Complex Event Processing", Germany, [5] M. Gerhards, V. Sander, A. Belloum, "About the flexible Migration of Workflow Tasks to Clouds -Combining on and off premise Executions of Applications", CLOUD COMPUTING 2012: The Third International Conference on Cloud Computing, GRIDs, and Virtualization, [6] Evert Duipmans, Dr. Luis Ferreira Pires, "Business Process Management in the cloud: Business Process as a Service (BPaaS)", University of Twente, April, [7] S. Aleem, S. Molnar, and N. Mohamed, "Collaborative Business Process Modeling Approaches: A Review", In Proc. of the 2012 IEEE 21st International workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, pp , June [8] Dirk Fahland, Wil M.P. van der Aalst Eindhoven, "Simplifying Discovered Process Models in a Controlled Manner", University of Technology, The Netherlands, [9] Hubert Scheuerlein, Falk Rauchfuss, Yves Dittmar, Rüdiger Molle, Torsten Lehmann, Nicole Pienkos, Utz Settmacher, "New methods for clinical pathways Business Process Modeling Notation (BPMN) and Tangible Business Process Modeling (t.bpm)". Springer-Verlag [10] Marielba Zacarias, Paula Ventura Martins, "Collaborative methods for Business Process Discovery, Portugal, Springer-Verlag [11] Jiri Kolar, Tomas Pitner, "Agile BPM in the age of Cloud technologies, Scalable Computing: Practice and Experience, [12] Andreas Lehmann and Dirk Fahland, "Information Flow Security for Business Process Models - just one click away", University of Rostock, Germany, [13] Rafael Accorsi, Thomas Stocker, Günter Müller, "On the Exploitation of Process Mining for Security Audits: The Process Discovery Case", Department of Telematics, University of Freiburg, Germany, [14] Aleš Frece, Gregor Srdić, Matjaž B. Jurič, "BPM and ibpms in the Cloud", Proceedings of the 1st International Conference on Cloud Assisted ServiceS, Bled, 25 Octubre 2012 [15] Dr. Luis Ferreira Pires, "Business Process Management in the cloud: Business Process as a Service (BPaaS)", University of Twente, April, [16] S Balzert, P Fettke, P Loos, "A Framework for Reflective Business Process Management", 45th Hawaii International Conference on System Sciences, USA, [17] Marco Brambilla, Piero Fraternali, and Carmen Vaca, "BPMN and Design Patterns for Engineering Social BPM Solutions", Politecnico di Milano, Piazza L. da Vinci 32, Milano, Italy, 2012 [18] Marco Brambilla, Piero Fraternali, Carmen Vaca, Stefano Butti, "Combining Social Web and BPM for Improving Enterprise Performances: the BPM4People Approach to Social BPM", WWW 2012, European Projects Track, Abril 16 20, Lyon, France, [19] S. Balzert, P. Fettke, P. Loos, "Enhancement of traditional Business Process Management with reflection a new perspective for Organizational Learning", Institute for Information Systems (IWi) at German Research Center for Artificial Intelligence (DFKI), Germany, [20] Huang Hua, Zhang Yi-Lai, Zhang Min, "A Survey of Cloud Workflow", Jingdezhen Ceramic Institute, Jingdezhen, Jiangxi, , China, Proceedings of the 2nd International Conference On Systems Engineering and Modeling (ICSEM-13), [21] Toàn Nguyên, Jean-Antoine-Désidéri, "Resilience Issues for Application Workflows on Clouds", Project OPALE, INRIA Grenoble Rhône-Alpes, ICNS 2012: The Eighth International Conference on Networking and Services, Grenoble, France, [22] Markus D ohring and Birgit Zimmermann, "vbpmn: Event-Aware Workflow Variants by Weaving BPMN2 and Business Rules", SAP Research, Darmstadt, Germany, [23] Zhenyu Fang, Changqing Yin, "BPM Architecture Design Based on Cloud Computing", School of Software Engineering, Tongji University, Intelligent Information Management, Shanghai, China, 2010.

8 [24] Duipmans E Pires L. da Silva Santos L. Towards a BPM Cloud Architecture with Data and Activity Distribution 2012 IEEE 16th International Enterprise Distributed Object Computing Conference Workshops. ISBN /12 [25] T. Anstett, F. Leymann, R. Mietzner, and S. Strauch, Towards bpel in the cloud: Exploiting different delivery models for the execution of business processes, in Proceedings of the 2009 Congress on Services - I. Washington, DC, USA: IEEE Computer Society, 2009, pp [26] Roder, A.; Lehmann, M.; Kabitzsch, K., "Monitoring service choreographies," Industrial Informatics (INDIN), th IEEE International Conference on, vol., no., pp.142,147, July doi: /INDIN [27] T. Dornemann, E. Juhnke, and B. Freisleben, On demand resource provisioning for bpel workflows using amazon s elastic compute cloud, in Proceedings of the th IEEE/ACM International Symposium on Cluster Computing and the Grid, ser. CCGRID 09. Washington, DC, USA: IEEE Computer Society, 2009, pp [28] W. Fdhila, U. Yildiz, and C. Godart, A flexible approach for automatic process decentralization using dependency tables, in ICWS, 2009, pp [29] J.Martinez Garro, P.Bazan Constructing hybrid architectures and dynamic services in Cloud BPM Science and Information Conference 2013 October 7-9, 2013 London, UK (aceptado por el comité, aún en proceso de publicación al momento de indicar esta referencia). [30] Bonita Open Solution Agosto de 2013.