Métodos preferidos para interactuar con un motor de reglas

Question

Estoy a punto de sumergirme en un proyecto orientado a reglas (usando reglas 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.

Las dos ideas principales que he visto son centralizar el motor de reglas (en su propia granja de servidores) y programar contra la granja a través de una API de servicio web (o en el caso de ILOG a través de WCF).El otro lado es ejecutar una instancia del motor de reglas en cada uno de sus 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 sea necesario en lugar de escalar cada vez que expande la configuración del servidor de aplicaciones.Esto reduce el desperdicio desde la perspectiva de la licencia adquirida.La desventaja de esta configuración es la sobrecarga adicional que supone realizar llamadas de servicio, latencia de red, etc.

Las ventajas y desventajas de ejecutar localmente el motor de reglas son exactamente lo opuesto a las ventajas y desventajas de la configuración centralizada.Sin llamadas de servicio lentas (llamadas API rápidas), sin problemas de red, cada servidor de aplicaciones depende de sí mismo.La gestión del despliegue de reglas se vuelve más compleja.Cada vez que agregue un nodo a su nube de aplicaciones, necesitará más licencias para motores de reglas.

Al leer los documentos técnicos, veo que Amazon está ejecutando el motor de reglas por configuración del servidor de aplicaciones.Parecen implementar reglas lentamente y reconocen que el retraso en la publicación de reglas es "aceptable" incluso aunque la lógica empresarial no esté sincronizada durante un período de tiempo determinado.

Pregunta: Según su experiencia, ¿cuál es la mejor manera de empezar a integrar reglas en una aplicación web basada en .net para una tienda que aún no ha pasado mucho tiempo trabajando en un mundo impulsado por reglas?

Answer 1

Estamos utilizando ILOG Para DotNet y tienen un proyecto piloto implementado.

Aquí está un resumen de las Reglas inmaduros Arquitectura:

1. Todos los datos de acceso a cabo fuera de las normas.
2. Reglas se despliegan de la misma manera como (control de origen, proceso de liberación, yada yada) código.
3. Proyectos (servicios) que las reglas de uso tienen una referencia a ILOG.Rules.dll y RuleEngines nuevos en marcha a través de una puesta en común de clase personalizado. RuleEngines se agrupan porque es caro para unirse a un conjunto de reglas a un RuleEngine.
4. Casi todas las reglas están escritas esperar objetos Assert'd, en lugar de los parámetros RuleFlow.
5. Dado que las reglas se ejecutan en el mismo espacio de memoria, instancias que son modificados por las reglas son las mismas casos en el programa -., Que es la propagación inmediata de estado
6. Casi todas las reglas se ejecutan a través de RuleFlow (incluso si se trata de una sola RuleStep en el RuleFlow).

Estamos pensando en RuleExecutionServer como una plataforma de alojamiento, así como RuleTeamServerForSharePoint a ser el anfitrión para la fuente de reglas. Con el tiempo, tendremos reglas desplegadas para la producción fuera del proceso de liberación de código.

El obstáculo principal en todos nuestros esfuerzos regla es modelado y la Regla de creación de habilidades.

Answer 2

Nunca me ha gustado el argumento de la centralización. Esto significa que todo lo que está acoplado al motor de reglas, que se convierte en un vertedero de todas las reglas en el sistema. Muy pronto no se puede cambiar nada por temor a lo desconocido: "¿Qué vamos a romper"

Yo prefiero siguiente idea de Amazon de los servicios como aislados, componentes autónomos. Interpreto que eso significa que los servicios son dueños de sus datos y sus reglas .

Esto tiene la ventaja añadida de compartimentar el espacio de reglas. Un conjunto de reglas hace más difícil mantener a medida que crece; mejor mantenerlos a un tamaño manejable.

Si se comparten partes del conjunto de reglas, preferiría un enfoque DI impulsado por los datos que un servicio puede tener su propia instancia de un motor de reglas y cargar las reglas comunes de una base de datos en el arranque. Esto podría no ser factible si su licencia iLog hace varias instancias costo prohibitivo. Eso sería un caso en el que el producto que se supone que estar ayudando en realidad podría estar dictando elecciones arquitectónicas que traerán dolor. Sería un buen argumento para una alternativa menos costosa (por ejemplo, JBoss Rules en Java-tierra).

¿Qué pasa con un árbol de decisiones basada en datos? Es un motor de reglas Rete realmente necesario, o es la decisión "herramienta de la empresa" conduciendo su elección?

Me gustaría probar para configurar el motor de reglas por lo que fue como desacoplado del resto de la empresa como sea posible. No tendría que llamar a las bases de datos o servicios si pudiera. Mejor hacer que la responsabilidad de los objetos para solicitar una decisión. Dejar que ellos llaman a los servicios web y bases de datos necesarias para reunir los datos necesarios, pasarlo al motor de reglas, y dejar que haga su cosa. El acoplamiento es tu enemigo: tratar de diseñar su sistema para minimizarlo. Mantener los motores de reglas aislado es una buena manera de hacerlo.

Answer 3

No tengo mucho que decir sobre la cuestión "qué servidor", pero yo le pido a desarrollar servicios de decisión - Servicios desembolsadas que utilizan reglas para tomar decisiones, pero que no cambian el estado del negocio. Dejando que el / servicio / proceso de solicitud llamando a decidir qué cambios de datos para hacer como resultado de llamar al servicio de decisiones y que tiene el componente llamar realmente iniciar la acción (s) sugerido por el servicio de decisiones hace que sea más fácil de usar el servicio de decisiones una y otra de nuevo (en todos los canales, procesa etc). El más limpio y menos atados al resto de la infraestructura del servicio decisión más reutilizable y manejable que va a ser. La discusión aquí en ebizQ valdría la pena leer a este respecto .

Answer 4

En mi experiencia con motores de reglas, hemos aplicado un conjunto de prácticas bastante básico para gobernar la interacción con el motor de reglas.En primer lugar, estos siempre han sido motores de reglas comerciales (iLog, Corticon) y no de código abierto (Drools), por lo que la implementación local en cada uno de los servidores de aplicaciones nunca ha sido realmente una opción viable debido a los costos de licencia.Por lo tanto, siempre hemos optado por el modelo centralizado, aunque en dos versiones principales:

• Ejecución remota del servicio web - De la misma manera que especificaste en tu pregunta, realizamos llamadas a servicios basados ​​en SOAP proporcionados por el producto del motor de reglas.Dentro del ámbito de los servicios web, nos hemos topado con varias opciones:(1) "Boxcar" las solicitudes, lo que permite a la aplicación poner en cola las solicitudes de procesamiento de reglas y enviarlas en fragmentos en lugar de mensajes únicos;(2) Ajuste las opciones de proceso y subprocesos proporcionadas por el proveedor.Esto incluye permitir separar los servicios de decisión por función y asignar a cada uno un W3WP y/o utilizar jardines web.Hay muchísimos ajustes que puedes hacer con furgones, subprocesos y procesos, y obtener la combinación correcta es más un proceso de prueba y error (y conocer tus conjuntos de reglas y datos) que una ciencia exacta.
• Llamar remotamente al motor de reglas en proceso - Un truco clásico de estilo por lotes para evitar la sobrecarga de serialización y deserialización.Realice de forma remota una llamada que active una llamada en proceso al motor de reglas.Esto se puede hacer de forma programada (p. ej.lote) o según la demanda (es decir,"furgones" de solicitudes).De cualquier manera, se puede evitar gran parte de la sobrecarga de las llamadas al servicio interactuando directamente con el proceso y la base de datos.La desventaja de este proceso es que no tiene IIS o su contenedor EJB/Servlet administrando los subprocesos por usted y tiene que hacerlo usted mismo.