4.2 Data Analysis
4.2.2 Cognitive Knowledge: Linguistic Competence
Con el auge de la tecnología de gestión de reglas han surgido un buen número de SGRNs, comerciales o no, que incorporan distintos motores de reglas basados en diversos algoritmos. Esta variedad de productos ha conducido a la definición de estándares que proporcionan a los usuarios independencia frente al producto seleccionado para soportar reglas de negocio. Esta independencia incluye dos vertientes: la primera, dedicada a proporcionar independencia de integración en las aplicaciones y la segunda centrada en la independencia respecto a la representación de reglas de negocio. El siguiente
Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio
apartado se centra en la descripción de la interfaz estándar definida por la Java Community Process10 (JCP) para la interacción con motores de reglas empleando Java como lenguaje de programación. Por otro lado, el apartado II.4.2 muestra una relación detallada de los lenguajes de representación de reglas de negocio existentes hasta el momento.
II.4.1. Java Rule Engine, interfaz estándar para interacción con motores
de reglas
Este es el nombre dado a la comunidad que se dedica al estudio y desarrollo de los sistemas de gestión de reglas de negocio basados en reglas. En este marco se desarrollan las actividades de estandarización de una interfaz común para motores de reglas. Esta especificación se denomina JSR‐ 94 (Selman,2002) y es la que se describe en esta sección. Antes de entrar en detalle se van a proporcionar algunas definiciones, tal como figuran en el estándar.
II.4.1.1. Definiciones Motor de reglas
La tecnología clave que está detrás del estándar JSR‐94 es el motor de reglas, Un motor de reglas puede verse como un sofisticado intérprete de sentencias del tipo 'si‐entonces'. Las sentencias 'si/entonces' a interpretar se denominan reglas. Las partes 'si' de las reglas contienen condiciones como 'carroCompra.cantidadTotal > $100'. La parte 'entonces' de las reglas contiene acciones como 'descuentoRecomendado(5%)'. Las entradas al motor de reglas son un conjunto reglas a ejecutar y algunos objetos de datos. Las salidas vienen determinadas por las entradas y pueden incluir los datos de entrada originales con posibles modificaciones, nuevos objetos de datos y efectos colaterales como 'enviarMail("Gracias por su compra")'. Existen muchas diferencias entre los motores de reglas y el término se emplea con mucha ligereza en la industria del software. Las características comunes a todos los motores son: Promueven la programación declarativa exteriorizando la lógica de negocio o de aplicación. Incluyen un formato de fichero documentado o las herramientas necesarias para crear reglas y conjuntos de reglas externos a la aplicación. Permiten actuar sobre los objetos de entrada para producir objetos de salida. A los objetos de entrada se les denomina con frecuencia con el término hechos y son una representación del estado del dominio de aplicación. A los objetos de salida se les denomina con frecuencia conclusiones o inferencias y están circunscritos al dominio de aplicación concreto.
El motor de reglas puede ejecutar acciones directamente, lo que afecta al dominio de aplicación, a los objetos de entrada y/o al ciclo de ejecución.
El motor de reglas puede crear únicamente objetos de salida, delegando la interpretación y ejecución de los objetos de salida a la aplicación que lo llama.
Una de las clases más comunes de motores de reglas es la de los motores de reglas con encadenamiento hacia adelante. Este tipo de motores implementa un ciclo de ejecución que permite que la acción de una regla cause que se verifique la condición de otra regla. De esta forma, con cada ejecución de la acción de una regla puede producirse en cascada la activación de otras. Los motores de regla con encadenamiento hacia adelante son adecuados para problemas que requieren la
Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio
obtención de conclusiones de alto nivel a partir de hechos de entrada muy simples. Este tipo de motores se implementa a menudo empleando alguna variante del algoritmo RETE (Forgy,1982). Entre estas variantes se encuentran: algoritmos lineales, como LFA (Fletcher&Amir,1994) y los algoritmos TREAT (Chen& Wilamowski,2002) o LEAPS (Batory,1994).
Mientras que la especificación reconoce la importancia de los motores de reglas con encadenamiento hacia delante, no establece un ciclo de ejecución concreto o la semántica de la ejecución de un conjunto de reglas. La especificación define una interfaz de programación ligera que podría implementarse con una amplia variedad de motores de reglas y de algoritmos. Se espera y se desea que otros motores que no incluyan encadenamiento hacia adelante implementen también la interfaz definida en esta especificación. Regla Una regla presenta, típicamente, dos componentes: una condición y una acción. Cuando se satisface la condición, se ejecuta la acción. Esta especificación no tiene en cuenta la estructura de las reglas, puesto que existen importantes diferencias entre fabricantes, y estas diferencias tienen que ver, con frecuencia, con los requisitos que imponen los distintos tipos de motores de reglas y algoritmos de ejecución. Para los fines de esta especificación, una regla únicamente presenta metadatos básicos, como un nombre y una descripción.
Conjunto de reglas a ejecutar
Un conjunto de reglas a ejecutar no es más que una colección de reglas. La especificación no define la estructura que deben tener estos conjuntos aparte de que se componen de una colección de reglas. Además, un conjunto de reglas a ejecutar presenta también metadatos básicos como un nombre y una descripción. Sesión de reglas Una sesión de reglas es una conexión en tiempo de ejecución entre un cliente y un motor de reglas. Se asocia a un único conjunto de reglas a ejecutar. Una sesión de reglas puede consumir recursos del motor de reglas y debe ser expresamente cerrada cuando el cliente deje de necesitarla. Sesión de reglas con estado
Una sesión de reglas con estado permite a un cliente tener una interacción prolongada con un conjunto de reglas a ejecutar. Los objetos de entrada pueden ser añadidos progresivamente a la sesión y los objetos de salida pueden ser solicitados repetidamente.
Sesión de reglas sin estado
Una sesión de reglas sin estado es aquella que proporciona una interfaz de programación, (en inglés Application Programming Interface (API)), simple y de alto rendimiento que ejecuta un conjunto de reglas a partir de una lista de objetos de entrada. Los métodos de las sesiones de reglas sin estado son idempotentes, es decir, la información sobre los objetos de entrada ni sobre los de salida no perdura entre llamadas a los métodos.
Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio
II.4.1.2.
Objetivos y generalidades sobre la especificación
La API definida en la especificación para la plataforma J2SE (Java 2 Standard Edition) prescribe un conjunto de operaciones fundamentales que debe proporcionar un motor de reglas, que se basa en la asunción de que la mayoría de los clientes necesita poder ejecutar un ciclo básico del motor de reglas compuesto por múltiples pasos. Este ciclo consiste en analizar las reglas, añadir objetos al motor, disparar reglas y obtener los objetos resultantes del motor.
El elemento básico que actúa como entrada para un motor de reglas es un conjunto de reglas, denominado conjunto de reglas a ejecutar. Las reglas incluidas en este conjunto están expresadas en un lenguaje de reglas. Esta especificación no fija ningún lenguaje de reglas concreto pero se centra en facilitar la interoperabilidad en tiempo de ejecución entre motores de reglas. Se da preferencia a la simplicidad y la generalización sobre la exigencia de metodologías de implementación, distribución o gestión específicas. Además, da soporte tanto a motores de reglas que se ejecutan completamente sobre la máquina virtual de Java como a aquellos motores que actúan como proxies para peticiones a máquinas virtuales remotas.
Los autores de la especificación reconocen que definir una interfaz tan genérica penaliza la interoperabilidad semántica entre implementaciones y se espera que futuras revisiones impongan requisitos semánticos adicionales para diferentes clases de motores de reglas. Este enfoque imita el de la especificación JCA (Java Connector Architecture), donde la compatibilidad en tiempo de compilación no supone necesariamente un comportamiento similar en tiempo de ejecución para las implementaciones de los fabricantes de Adaptadores de Recursos.
Por otro lado, la especificación tiene en cuenta la necesidad común de reducir tanto el coste asociado a la incorporación de lógica de negocio en las aplicaciones como el asociado a la implementación de herramientas y servicios de lógica de negocio al nivel de plataforma.
Existen especificaciones de interfaces propias de cada fabricante que son diferentes entre sí. Sin embargo, las diferencias son lo suficientemente significativas como para suponer dificultades costosas para los constructores de aplicaciones, fabricantes de plataformas y arquitectos de software.
Entre los objetivos perseguidos por esta especificación se encuentran:
Facilitar la inclusión de tecnología de motores de reglas en aplicaciones Java
Incrementar la comunicación y la estandarización entre fabricantes de motores de reglas Promover la creación de un mercado de fabricantes de herramientas y aplicaciones de
terceros a través de una API estándar para motores de reglas Promover la independencia del código cliente en el entorno J2SE Incrementar la portabilidad de las aplicaciones Java permitiendo la integración de motores de reglas de distintos fabricantes. Proporcionar unos patrones para la implementación de aplicaciones basadas en reglas para la plataforma J2SE
Dar soporte a los fabricantes de motores de reglas ofreciendo una API armonizada que satisfaga las necesidades de los clientes existentes y que sea de implementación sencilla
II.4.1.3.
Productos compatibles con JSR94
Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio
Blaze Advisor JBoss Rules ‐ Drools ILOG JRules Jess rules4j Pegarules Yasu QuickRules
II.4.2. Lenguajes de representación de reglas de negocio
La variedad de lenguajes de representación de reglas de negocio es tanta como SGRN se han construido. Prácticamente cada sistema define su propia representación para sus reglas, dificultando el intercambio de las mismas entre distintos SGRN. Esta diversidad de lenguajes ha conducido a diversos esfuerzos de estandarización, dirigidos a establecer lenguajes comunes que permitan la definición de reglas de negocio válidas para cualquier motor de reglas. Tal vez los comienzos puedan encontrarse en la iniciativa de IBM, CommonRules11, donde ya se hablaba de definir una plataforma para aplicaciones basadas en reglas que maximizase la independencia de la lógica de negocio de los datos, persiguiendo, además, la interoperabilidad entre las reglas. El lenguaje Business Rule Markup Language (BRML) (BRML,2002) fue uno de los sucesores de CommonRules y, aproximadamente en las mismas fechas, en torno a 1999, ILOG lanza la iniciativa Simple Rule Markup Language (SRML) (Thorpe&Ke,2001), que también busca definir un lenguaje común para motores de reglas con algoritmos de encadenamiento hacia adelante y que fue sustituida por las iniciativas de estandarización iniciadas por el consorcio W3C12. En los apartados que siguen se van a describir distintos estándares existentes para facilitar la definición y el intercambio entre sistemas de reglas de negocio.
II.4.2.1.
RuleML
RuleML es un lenguaje de marcado para la publicación y acceso compartido a bases de reglas en web. Se ha convertido en un estándar de facto para el intercambio de reglas de negocio, por lo que ha servido de base para la definición de los nuevos estándares desarrollados por el W3C, como RIF (ver apartado II.4.2.4). El lenguaje RuleML es en realidad un árbol de sublenguajes (que tienen como base XML, RDF, XSLT y OWL), cuya raíz permite utilizar el lenguaje como un todo y cuyos nodos permiten identificar subconjuntos adaptados del lenguaje. El sublenguaje fundamental en RuleML se llama Kernel Datalog, descrito en el siguiente apartado.