Una propuesta usando Restricciones para la toma de decisiones en la tolerancia a fallos en procesos de negocio

Una propuesta usando Restricciones para la toma de decisiones en la tolerancia a fallos en procesos de negocio M. T G´omez-L´opez and Rafael Mart´ınez Gasca and Diana Borrego N´u˜nez Departamento de Lenguajes y Sistemas Inform´aticos, Escuela T´ecnica Superior de Ingenier´ıa Inform´atica, Universidad de Sevilla, Espa˜na, {maytegomez, gasca, dianabn}@us.es Resumen Cuando un proceso de negocio no obtiene el objetivo que se propone ser´a necesario realizar una diagnosis y detecci´on de errores, descubriendo qu´e servicios est´an funcionando de forma incorrecta para su sustituci´on. El objetivo de este art´ıculo es describir los pasos necesarios para buscar otro servicio o actividad que pueda sustituir al que est´a fallando de una forma eficiente. Para automatizar la b´usqueda y sustituci´on de servicios, es posible describir la funcionalidad de dichos procesos mediante restricciones, lo cual facilitar´ıa la identificaci´on de sus posibles sustitutos. Tambi´en se analiza en este art´ıculo c´omo adaptar el traspaso de informaci´on que se realiza entre los servicios mediante mensajes en XML, a la descripci´on del comportamiento de dichos servicios mediante restricciones. 1. Introduction Los procesos de negocio son un conjunto de actividades o servicios relacionados mediante un flujo de trabajo y/o datos para obtener un objetivo definido. Cuando un proceso de negocio se somete a una monitorizaci´on y diagnosis, pueden ser detectados errores en algunas de sus actividades. En este trabajo nos centraremos en los procesos de negocio que est´an formados por un conjunto de servicios web, donde uno de ellos falla para cualquier instancia de ejecuci´on, o su funcionamiento es defectuoso. La diagnosis de fallos ha sido una cuesti´on analizada en otros trabajos [1], ya que la conversi´on de las t´ecnicas de inteligencia artificial [2][3] al modelado mediante procesos de negocio no son autom´aticas. Uno de los mayores problemas de la diagnosis de procesos viene derivada de que el modelo est´a distribuido y no se tiene una visi´on ni conocimiento global de su comportamiento. M´as relacionado con la diagnosis de procesos de negocio existen trabajos relacionados con la detecci´on de conflictos (CDM - Conflict Detecting Mechanism), donde la especificaci´on de los servicios descrita en XML se utiliza para dise˜nar meta-procesos [4] para la detecci´on de inconsistencias en las actividades. En el ´ambito de CDM, los conflictos se definen como la causa que viola y modifica el comportamiento normal o esperado en un determinado estado de la ejecuci´on Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 62 del proceso de negocio. Para la detecci´on de estos errores, el ´area de procesos de negocio tambi´en se ayuda de la monitorizaci´on de procesos (BPMod-Business Process Monitoring), que es un lenguaje de consulta para la monitorizaci´on propuesto en [5]. Cuando los procesos de negocios est´an formados por servicios web, es muy utilizado el est´andar BPEL (Business Process Execution Language [6]), que provee de un lenguaje basado en XML, el cual describe tanto la interfaz del proceso como sus operaciones l´ogicas y su l´ınea de ejecuci´on. La utilizaci´on de este lenguaje tambi´en ha sido llevaba al campo de la tolerancia a fallos [7]. Una vez detectado el servicio que ha fallado, ser´a necesario decidir qu´e tareas se tendr´an que llevar a cabo dependiendo de qu´e servicio est´a fallando. Para sustituir un servicio, se tendr´a que encontrar otro que incluya su especificaci´on y preferiblemente en el menor tiempo posible. Para automatizar este proceso, es necesario conocer y tener especificado de una manera formal su comportamiento, junto a un repositorio de posibles servicios sustitutos. Una forma de describir dicho funcionamiento es mediante restricciones, que permiten la formalizaci´on de contratos y existen t´ecnicas para optimizar la b´usqueda de servicios consistentes con otros. La utilizaci´on de restricciones facilitar´ıa la toma de decisiones ante la b´usqueda de un sustituto, ya que existen t´ecnicas desarrolladas en este ´ambito [8][9] para optimizar la localizaci´on de restricciones mediante consultas a una Base de Datos de Restricciones. La b´usqueda de un nuevo servicio o un conjunto de ellos en una base de datos conlleva tres problemas fundamentales a solucionar: Representaci´on de los servicios mediante un lenguaje de especificaci´on cercano a las restricciones que pueda describir su comportamiento. Almacenamiento de dicha descripci´on en una base de datos para hacer la informaci´on persistente y facilitar una b´usqueda eficiente. B´usqueda eficiente del mejor servicio, o combinaci´on de ellos, para sustituir el detectado como incorrecto. A lo largo de este art´ıculo, vamos a analizar estas tres tareas y c´omo mejorarlas para que la combinaci´on de ellas ayuden a la toma de decisiones en la orquestaci´on de los procesos ante la detecci´on de errores. 2. Representaci´on de servicios web mediante restricciones El est´andar BPEL (Business Process Execution Language [6]) permite describir tanto la interfaz del proceso como sus operaciones l´ogica y su l´ınea de ejecuci´on. La notaci´on que describe BPEL se basa en la descripci´on del comportamiento espec´ıfico de procesos basados en servicios web, que se puede encontrar en la bibliograf´ıa como BPEL4WS. Los procesos en BPEL4WS exportan e importan funcionalidad usando exclusivamente las interfaces de los servicios web. Los procesos de negocio se pueden describir de dos formas: Modelos de procesos de negocio ejecutables con un determinado comportamiento. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 63 Protocolos de negocio, usando descripci´on de negocios que especifican el intercambio mutuo de mensajes sin revelar su comportamiento interno. La descripci´on de los protocolos de negocio se denomina descripci´on de procesos abstractos. El lenguaje BPEL4WS se puede usar para modelar tanto los procesos ejecutables como los abstractos, definiendo un lenguaje tanto para la especificaci´on formal como para el intercambio de mensajes para un protocolo determinado. Las siguientes especificaciones describen el espacio de los Servicios Web: SOAP,Web Services Description Language (WSDL), y Universal Description, Discovery, and Integration (UDDI). SOAP define un protocolo de mensajer´ıa en XML para la interacci´on entre servicios b´asicos. WSDL introduce una gram´atica para la descripci´on de servicios. UDDI provee de la infraestructura necesaria para publicar y descubrir servicios de una forma sistem´atica. Estas tres especificaciones combinadas permiten una funcionalidad completa en los servicios web con un modelo independiente de la plataforma. Cuando en este art´ıculo se hace referencia al t´ermino Restricci´on, nos referimos a un conjunto de variables definidas sobre un dominio y relacionadas entre s´ı. Donde dicha relaci´on entre variables se puede describir de una manera compacta mediante una combinaci´on con operadores l´ogicos de ecuaciones e inecuaciones. La implementaci´on Mde un servicio en un determinado proceso tiene que satisfacer un Contrato Cdescrito mediante una precondici´on y una postcondici´on, lo que se puede representar mediante restricciones que se deben cumplir al terminar el servicio. Tambi´en hay que tener en cuenta que dicho servicio tendr´a un conjunto de variables de conexi´on que ser´an p´ublicas y estar´an relacionadas con otros servicios mediante puertos, mientras que otro conjunto de variables ser´an privadas. Si Msatisface el contrato Cy est´an definidas sobre los mismos puertos, se dir´a que M⊆C. Para sustituir Mpor otro servicio, ser´a necesario encontrar otra restricci´on M0que est´a definida sobre los mismos puertos y que tambi´en satisfaga el aserto M0⊆C. Para mostrar un ejemplo de representaci´on de servicios web con restricciones utilizaremos el mostrado en la figura 1. Este ejemplo utiliza un conjunto de servicios que representan la obtenci´on de ganancias haciendo distintos tipos de inversiones. Partiendo de una cantidad determinada se utilizar´a un servicio (Divisi´on Capital en distintas Estrategias) que desglosar´a la cantidad disponible en distintas partidas. Las distintas estrategias son: Inversi´on en Bolsa,Inversi´on Inmobiliaria, e Inversi´on en empresas de I+D+I. Cada una de estos servicios obtendr´a unos beneficios en funci´on de la cantidad invertida y un margen de inversi´on a dicha cantidad. Esto significa que cada servicio recibir´a un par de valores <inversi´on,margen>, de forma que la inversi´on total en cada uno de los servicios ser´a de inversi´on±margen. Como variable de salida del servicio se obtendr´a una gananciaTotal. Si por ejemplo tras un proceso de diagnosis se detecta que el servicio Inversi´on en Bolsa no funciona de manera correcta, ser´a necesario buscar un nuevo servicio que haga las veces de ´este. Para esto es necesario tener la descripci´on de dicho servicio, de forma que sea posible la sustituci´on por otro. Un ejemplo de la descripci´on de la tarea Inversi´on en Bolsa es la sigu- Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 64 iente, donde se describen el precio de cada una de las acciones disponible en este servicio PA1,. . .,PAn, la cantidad disponibles de cada una de ellas C1, . . .,Cn, y el porcentaje de ganancia tras un determinado tiempo en cada una de ellas PG1. . . PGn. Toda esta informaci´on ser´a obtenida por el servicio de forma independiente. Para una cantidad de inversi´on dada y un determinado margen, se comprar´an un conjunto de acciones, tantas de cada tipo como se representan con las variables N1,. . .,Nn. La descripci´on del comportamiento del servicio ser´a: N1∗PG1+N2∗PG2+. . . Nn∗PGn=gananciaTotal ∧ PA1∗N1+PA2∗N2+. . . PAn∗Nn≤inversi´on +margen ∧ PA1∗N1+PA2∗N2+. . . PAn∗Nn≥inversi´on −margen ∧N1≤C1∧N2≤C2∧. . . ∧Nn≤Cn División Capital en distintas estrategias Inversión en Bolsa Inversión Inmobiliaria Inversión en I+D+I Información Inversores Figura 1. Ejemplo de Proceso de negocio La restricci´on que describe el funcionamiento del servicio Inversi´on en Bolsa define la postcondici´on de dicho servicio, mientras que la precondici´on tambi´en deber´a ser representada mediante una restricci´on. Como el intercambio de informaci´on entre los servicios web se realiza mediante un protocolo de mensajer´ıa, la informaci´on que se intercambia en dichos mensajes marcar´a qu´e variables son conocidas entre los diferentes procesos y cu´ales son privadas. En el ejemplo de la inversi´on en bolsa, existen dos tipos de mensajes, uno de recepci´on de datos y otro de env´ıo de resultados. En este caso son las variables inversi´on,margen ygananciaTotal, y los mensajes ser´an de la forma: Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 65 <message name="DatosInversionBolsa"> <part name="inversion"type="xsd:integer"/ > <part name="margen"type="xsd:integer"/ > < /message> <message name="SalidaInversionBolsa"> <part name="gananciaTotal"type="xsd:integer"/ > < /message> 3. Almacenamiento de especificaciones de servicios web en bases de datos Cuando un sistema combina diferentes servicios en un proceso para obtener un objetivo, es com´un que cada una de las fases de dicha producci´on trabaje con un conjunto de datos almacenados en diferentes estructuras de almacenamien- to y de diferente naturaleza. Como se ha analizado en la secci´on anterior, el comportamiento de los servicios puede ser mapeado a restricciones, por lo que la forma natural de almacenarlas ser´a en una Base de Datos de Restricciones (CDB - Constraint Database). Las Bases de Datos de Restricciones tuvieron su origen a principios de 1990 con el art´ıculo de Kanellakis, Kuper y Revesz [10], ampli´andose m´as tarde en los trabajos [11][12]. Originalmente, el objetivo de las CDBs fue definir una versi´on de bases de datos a la que se le a˜nadi´o funcionalidad relacionada con la Programaci´on L´ogica con Restricciones (Constraint Logic Programming - CLP). Las CDBs fueron definidas en base a la l´ogica y modelo de primer orden, tanto para la descripci´on de restricciones como para la evaluaci´on de las consultas. El fundamento de las CDBs se apoya en la dualidad de representar un conjunto de datos mediante una restricci´on (f´ormula) sobre un conjunto de variables libres x1,. . .,xm, junto a la utilizaci´on de atributos cl´asicos del ´algebra relacional a1, . . .,anque s´olo pueden tomar un valor en cada tupla. Esta ampliaci´on de las bases de datos de restricciones, desarrollada m´as ampliamente en [9], permite almacenar y consultar las restricciones como un dato cualquiera como los enteros, cadenas... Una k-tupla restricci´on con las variables x1, . . . , xkes una conjunci´on finita de la forma ϕ1∧. . . ∧ϕNdonde cada ϕi, para 1 ≤i≤N, es un Atributo Cl´asico o Univaluado o un Atributo Restricci´on. Un atributo univaluado es de la forma {xj=Constante}donde xj∈ {x1, . . . , xk}. Un atributo restricci´on es una relaci´on representada mediante una restricci´on entre las variables x1, . . . , xkno pertenecientes a un atributo univaluado. Una relaci´on restrictiva est´a definida como un conjunto de Atributos Univaluados y un conjunto de Atributos Restricci´on. Una relaci´on restrictiva de aridad k, es un conjunto finito r={ψ1, . . . , ψM}, donde cada ψjpara 1≤j≤Mes una k-tupla restricci´on sobre las variables x1, . . . , xktal como se muestra en la figura 2. La f´ormula correspondiente es la disjunci´on de Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 66 la forma ψ1∨. . . ∨ψM, tal que ψj=ϕ1∧. . . ∧ϕNdonde cada ϕipara 1≤i≤Nes una k-tupla restricci´on. Si existe en cada ψj∈runa ϕide la forma {x=Constante}, donde xsea la misma variable en todos los ϕi pertenecientes a distintos ψjyxno aparece en el resto de los ϕide una misma ψj, se dir´a que xes un atributo univaluado, mientas que el resto de variables formar´an parte en uno o varios Atributos Restricci´on. Relación Restrictiva m ψ ψ ψ ∨ ∨ ∨ ... 2 1 nmmm n n ϕϕϕ ϕϕϕ ϕ ϕ ϕ ∧∧∧ ∨ ∨ ∧∧∧ ∨ ∧ ∧ ∧ ... ... ... ... 21 22212 12111 k-tupla restricción Figura 2. Representaci´on de k-tuplas restricci´on y relaciones restrictivas Por lo tanto, una Base de Datos de Restricciones es una colecci´on finita de relaciones restrictivas formadas por atributos univaluados yatributos restricci´on. La idea es que se tendr´ıan todos los servicios definidos en una CDB mediante sus correspondientes contratos, precondici´on y postcondici´on, y cuando un servicio es detectado como err´oneo, se buscar´a en la o las bases de datos de restricciones pertinentes qu´e nuevo servicio podr´ıa sustituirlo porque tenga la misma especificaci´on. Esta dualidad permite almacenar los datos que describen el comportamiento de los servicios web como restricciones, y sus variables p´ublicas y puertos como atributos cl´asicos. Un ejemplo de representaci´on de los servicios descritos en la figura 1 es el mostrado en la figura 3. En este ejemplo aparece dos atributo cl´asico que ser´an el identificador del servicio web (IDSW) y la descripci´on textual (Descripci´on). Por otra parte tambi´en existen dos atributos restricci´on que definen el contrato de cada servicio, la precondici´on y la postcondici´on. Para conectar los distintos servicios, se utilizar´an las variables definidas como p´ublicas, al representar la informaci´on mediante restricciones es posible realizar operaciones de proyecci´on sobre ellas para modificar sus variables. Esto har´ıa posible que un mismo servicio mostrara diferentes precondiciones y postcondiciones en funci´on de las variables que hiciera p´ublicas en cada momento, o dependiendo del servicio con el que se relacionara. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 67 IDSW 2354 3487 5561 ... Precondición margen  inversión  1.000.000 inversión inversión        18.000 inversión inversión              ... Postcondición N1*PG1 + N2*PG2 +...Nn*PGn = gananciaTotal … Inversión*1,8-2.500=ganaciaTotal Inversion*1,4-gastoFijo=gananciaTotal ... Descripción Inversión en bonos Inversión Inmobiliaria Inversión en I+D+I ... ≥ ≥ ≥ ≥ ≥ ≥ ∧ ∧ ∧ ∧ ∧ ≥ ≥ Figura 3. Ejemplo de tuplas con Servicios Web Para que las consultas a la CDB sean m´as eficientes, cuando se crea una Base de Datos de Restricciones se crean tambi´en tres tablas (Restricciones,Variables y Restricciones/Variables) mostradas en la figura 4, que mantienen las relaciones entre las variables y las restricciones. Estas tablas disminuyen la complejidad computacional de las consultas ya que con una sola consulta se puede conocer qu´e restricciones tienen qu´e variables y viceversa. Estas tablas permiten identificar cada restricci´on (tabla Restricciones), cada variable (tabla Variables) y establecer la relaci´on entre ambas (tabla Restricciones/Variables), lo que ayuda a detectar las restricciones relacionadas con una consulta sin necesidad de tratarlas todas. Estas tablas no son visibles ni accesibles por el usuario de una forma directa, pero s´ı de una manera impl´ıcita cuando se a˜naden, modifican, borran o consultan restricciones de la base de datos. La tabla Restricciones almacena el idRestricci´on que corresponde al identificador del objeto (OID) generado por el sistema, y la Etiqueta acorde con el tipo de restricci´on que representa (Polin´omica, lineal, de igualdad o inecuaci´on). La tabla Variables almacena, para cada variable, su identificador, su nombre y el dominio (Natural, Entero o Flotante) al que pertenece. La tabla Restricciones/Variables almacena la relaci´on entre las variables y las restricciones, y sobre qu´e rango (Rango−Inicio,Rango−Fin) est´an definidas cada una de las variables para cada una de las restricciones en las que participan. Restricciones/Variables (k)IdRestricción: int (k)IdVariable: int Rango_Inicio: number Rango_Fin: number Variables (k)IdVariable: int Nombre: String Tipo: String Restricciones (k)IdRestricción: int Restricción: Object Etiqueta: String 1..1 1..n 1..n 1..1 Figura 4. Indexaci´on entre variables y restricciones 4. B´usqueda eficiente de Servicios Web sustitutos En la bibliograf´ıa hay trabajos que se han centrado en las consultas relacionadas con servicios web [13], [14]. M´as concretamente, La propuesta de este trabajo se centra en buscar de forma eficiente servicios que puedan sustituir a Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 68 uno dado, para ello debemos tener en cuenta como ya dijimos en la secci´on 2 que una implementaci´on Mde un servicio de un proceso satisface un contrato Csi satisface la postcondici´on, sujeto a una precondici´on dada. Sean SW(Pre) ySW(Post) la representaci´on de la precondici´on y la postcondici´on del contrato correspondiente a un servicio SWque implementa una actividad de un proceso de negocio. Para poder obtener otro servicio Sbque pueda sustituir el que trabaja de forma incorrecta Sa, ser´a necesario encontrar otro servicio que cumpla las siguientes asertos: Sb(Pre) ⊇Sa(Pre).Lo que significa que todos los posibles valores de entrada del servicio Saest´an recogidos en el nuevo servicio Sb. Sb(Post) ⊆Sa(Post).Lo que significa que los valores de salida que devuelva el servicio Sbson equivalentes o est´an incluidos en los valores de salida que devolv´ıa el servicio Sa. Nuestra propuesta define la implementaci´on de esta comprobaci´on mediante la construcci´on de Problemas de Satisfacci´on de Restricciones, m´as concretamente con el operador de Selecci´on de las CBDs. Un problema de satisfacci´on de restricciones (Constraint Satisfaction Problem - CSP) es una representaci´on de un conjunto de variables, dominios y restricciones, ligado a uno o varios esquema de razonamiento para resolverlo. Formalmente, est´a definido por la tripleta <X, D, C>donde, X = {x1,x2,. . .,xn} es un conjunto finito de variables, D = {d(x1), d(x2), ...,d(xn)}es el conjunto de dominios de cada una de las variables, y C = {C1, C2,. . ., Cm}un conjunto de restricciones. Cada restricci´on Ciest´a definida como una relaci´on R de un conjunto de variables V = {xi,xj,. . .,xk}a lo que se denomina ´ambito de la restricci´on. Para hacer m´as eficiente la b´usqueda de servicios, la implementaci´on de CDBs que se propone utilizar es la descrita en [15]. Esta propuesta busca la eficiencia, por lo que intenta evitar la construcci´on y resoluci´on de CSPs en la medida de lo posible. Para ello hacemos un an´alisis de los rangos de las variables, que se almacenar´an tal como se ha descrito en la secci´on anterior. Existen casos donde el an´alisis de dichos rangos evita la construcci´on de CSPs. Analizando el m´ınimo y m´aximo valor que puede tomar una variable, es posible inferir si las restricciones involucradas en la comparaci´on cumplen o no una condici´on. Por ejemplo si se comparan dos restricciones CxyCy, ambas definidas sobre las variables v1ev2, donde los rangos son Cx(v1:[5..15], v2:[20..30]) y Cy(v1:[20..25], v2:[40..55]). En este caso, el predicado fuera Cx⊆Cyseguro que no se cumple, y el servicio no servir´ıa como sustituto. Volviendo al ejemplo anterior, si los dominios de las variables fueran Cx(v1:[5..15], v2:[20..30]) y Cy(v1:[2..25], v2:[10..55]), y el predicado Cx⊆Cy, pese a que los dominios de las variables en Cxest´an incluidas en los dominio de las variables en Cy, no se puede asegurar que se cumple el predicado para las restricciones. Un ejemplo donde los rangos de las variables est´an incluidos dentro de otra, pero no sus soluciones, es el mostrado en la figura 5. Para cada una de las variables de las restricciones de los servicios que se quieren analizar, existen diferentes posibilidades entre los rangos de las variables, Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 69 Cy v1 v2 Cx Figura 5. Ejemplo de Cx * Cy mostradas en la figura 6. En funci´on de cada una de las relaciones entre los rangos y la resoluci´on de CSP, se puede concluir que: Cx Cy Cx Cy Cx Cy Cx Cy (a) (b) (c) (d) Cy (e) Cx Figura 6. Tipos de relaciones entre los rangos de las variables de dos restricciones (a): Cx⊆Cyes falso (b): Cx⊆Cyes falso (c): Cx⊆Cyes falso (d): Cx⊆Cyes necesario crear un CSP para saber si es cierto o falso (a): Cx⊆Cyes necesario crear un CSP para saber si es cierto o falso La creaci´on del CSP se basa en que Cx⊆Cyser´a cierto si todas las soluciones de Cxlo son tambi´en de Cy. Para la inclusi´on, es necesario que las restricciones est´en definidas sobre las mismas variables, de forma que sean CxyCydos restricciones donde X={x1,x2,. . .,xn}son las variables de CxyCy,Cx⊆Cyes igual que la implicaci´on (Cx→Cy) [16]. Esta operaci´on determina si todas las soluciones de Cxson tambi´en soluciones de Cy, aunque es posible que Cytenga soluciones que no pertenezcan a Cx. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 1, 2009 ISSN 1988–3455 SISTEDES, 2009 70