Estoy a punto de sumergirme en un proyecto orientado a las reglas (usando las reglas de ILOG para .NET - ahora IBM). Y he leído un par de perspectivas diferentes sobre cómo configurar el procesamiento de reglas y cómo interactuar con el motor de reglas.Métodos preferidos para interactuar con un motor de reglas
Las dos ideas principales que he visto es centralizar el motor de reglas (en su propia granja de servidores) y programar contra la granja mediante una API de servicio web (o en el caso de ILOG mediante WCF). El otro lado es ejecutar una instancia del motor de reglas en cada uno de los servidores de aplicaciones e interactuar con él localmente, y cada instancia tiene su propia copia de las reglas.
La ventaja de la centralización es la facilidad de implementación de las reglas en una ubicación centralizada. Las reglas se escalan según lo necesitan en lugar de escalar cada vez que expandes la configuración de tu servidor de aplicaciones. Esto reduce el desperdicio desde una perspectiva de licencia adquirida. El inconveniente de esta configuración es la sobrecarga adicional de realizar llamadas de servicio, latencia de red, etc.
El lado positivo/negativo para ejecutar localmente el motor de reglas es exactamente lo contrario del lado positivo/negativo de la configuración centralizada. Sin llamadas de servicio lento (llamadas API rápidas), sin problemas de red, cada servidor de aplicaciones se basa en sí mismo. La administración del despliegue de reglas se vuelve más compleja. Cada vez que agregue un nodo a la nube de su aplicación, necesitará más licencias para motores de reglas.
Al leer documentos técnicos, veo que Amazon ejecuta el motor de reglas por configuración de servidor de aplicaciones. Parece que hacen un despliegue lento de las reglas y reconocen que el retraso en la publicación de reglas es "aceptable", aunque la lógica empresarial no esté sincronizada durante un período de tiempo determinado.
Pregunta: Según sus experiencias, ¿cuál es la mejor manera de comenzar a integrar reglas en una aplicación web basada en .NET para una tienda que aún no ha dedicado mucho tiempo a trabajar en un mundo gobernado por reglas?
Los programadores deberían estar * escribiendo * reglas motores. Los analistas de negocios establecen reglas sobre el motor de reglas, y deben tener una interfaz GUI para la creación de reglas y guardarlas en XML o en una base de datos. De hecho, la mayoría de las máquinas de reglas no logran integrar una gestión de flujo de trabajo adecuada y solo manejan las reglas, de ahí las implementaciones de FCRE que comienzan a agregar complejidad excesiva para los analistas de negocios pobres, quienes luego comienzan a exigir que los programadores los ayuden. La implementación lenta de las reglas es inaceptable en un entorno comercial financiero, y, por lo tanto, presumiblemente en otros entornos. – JeeBee
Pero los programadores también necesitan exponer ganchos y puntos de datos a los motores de reglas para que los BA trabajen. Las aplicaciones que escribimos deben vincularse con el motor de reglas de alguna manera. –
Sí, sus aplicaciones colocan datos en el motor de reglas, el motor de reglas ejecuta reglas, cálculos, procesos personalizados (donde entran los programadores, por ejemplo, si necesita agregar una llamada de servicio web a mitad de su ejecución del flujo de trabajo) y contesta respuestas . La interfaz (servicio web, llamada directa al método) debe ser bastante genérica. Los BA definen los nombres de datos con los que trabajan, y eso es lo que se pasa. Por supuesto, estoy seguro de que los flujos de trabajo financieros difieren de otros flujos de trabajo/motores de reglas. Alojamos nuestros motores de reglas en Tomcat, y los llamamos a través de un servicio web (una pequeña sobrecarga sobre las reglas mismas). – JeeBee