Metodi preferiti per interagire con un motore di regole

Question

Sono in procinto di tuffarsi in un progetto orientato regole (usando ILOGs Regole per NET - ora IBM). E ho letto un paio di diversi punti di vista su come impostare il trattamento regole e come interagire con il motore delle regole.

I due pensieri principali che ho visto è di centralizzare il motore regola (nella propria azienda agricola di server) e il programma contro l'azienda agricola tramite un API servizio web (o in caso di ILOG via WCF). L'altro lato è quello di eseguire un'istanza del motore di regole su ciascuno dei server app e interagire con esso a livello locale con ogni istanza con la propria copia del regolamento.

Il lato fino alla centralizzazione è la facilità di implementazione delle regole per una posizione centralizzata. Le regole di scala come hanno bisogno di piuttosto che scalare ogni volta che si espande la configurazione del server di applicazione. Questo riduce i rifiuti da una prospettiva di licenza acquistata. Il lato negativo di questo set up è l'overhead aggiunto di effettuare chiamate di servizio, latenza di rete, ecc.

Il vantaggio / svantaggio di esecuzione localmente il motore di regole è l'esatto opposto della configurazione centralizzata del rialzo / ribasso. Nessuna chiamata lente di servizio (chiamate veloci API), problemi di rete, ogni server applicazione si basa su se stessa. Gestire l'implementazione di regole diventa più complessa. Ogni volta che si aggiunge un nodo per la vostra applicazione nuvola avrete bisogno di più licenze per i motori di regole.

Nel leggere libri bianchi Vedo che Amazon è in funzione il motore delle regole per la configurazione del server app. Essi sembrano fare un lento dispiegamento di regole e riconoscono che il ritardo nella regola di pubblicazione è "accettabile", anche se la logica di business è fuori di una sincronizzazione per un determinato periodo di tempo.

Domanda: dalle vostre esperienze, qual è il modo migliore per iniziare l'integrazione di regole in una web app basata .net per un negozio che non è ancora trascorso molto tempo a lavorare in un mondo guidato regole

Answer 1

Stiamo utilizzando ILOG Per DotNet e hanno un progetto pilota schierato.

Ecco un riassunto della nostra Architettura Regole immaturi:

1. Tutti i dati di accesso fatto al di fuori delle regole.
2. regole vengono distribuiti allo stesso modo di (controllo del codice sorgente, processo di rilascio, bla bla) codice.
3. Progetti (servizi) che le regole d'uso hanno un riferimento a ILOG.Rules.dll e nuovi-up RuleEngines tramite una classe pooling personalizzato. RuleEngines sono messe in comune, perché è costoso per associare un RuleSet ad un RuleEngine.
4. Quasi tutte le regole sono scritte aspettarsi oggetti Assert'd, piuttosto che parametri RuleFlow.
5. Dal momento che le regole vengono eseguite nello stesso spazio di memoria, istanze che vengono modificate dalle regole sono le stesse istanze nel programma -. Che è la propagazione immediata di Stato
6. Quasi tutte le regole vengono eseguite tramite RuleFlow (anche se si tratta di un singolo RuleStep nel RuleFlow).

Ecco RuleExecutionServer come piattaforma di hosting così come RuleTeamServerForSharePoint essere l'ospite per la sorgente regole. Alla fine, avremo regole schierate alla produzione al di fuori del processo di rilascio del codice.

L'ostacolo principale in tutti i nostri sforzi regola è il modello e regola di authoring qualifiche.

Answer 2

mi è mai piaciuto l'argomento centralizzazione. Significa che tutto è accoppiato nel motore regole, che diventa una discarica per tutte le regole nel sistema. Ben presto non si può cambiare nulla per paura dell'ignoto: "Cosa faremo rompere"

preferisco di gran lunga seguente idea di Amazon di servizi come isolati, componenti autonome. Interpreto che a dire che i servizi possiedono i loro dati e le loro regole .

Questo ha il vantaggio di partizionamento lo spazio regole. Un insieme di regole diventa più difficile da mantenere come cresce; meglio tenerli a una dimensione gestibile.

Se le parti del set di regole sono condivise, preferirei un approccio data-driven DI in cui un servizio può avere una propria istanza di un motore di regole e caricare le regole comuni da un database all'avvio. Questo potrebbe non essere fattibile se la licenza iLog rende più istanze costo proibitivo. Questo sarebbe un caso in cui prodotto che dovrebbe essere aiutare potrebbe effettivamente essere dettare scelte architettoniche che porterà dolore. Sarebbe un buon argomento per un'alternativa meno costosa (ad esempio, JBoss Rules in Java-terra).

Che dire di un approccio dell'albero decisionale basato sui dati? È un motore di regole di Rete davvero necessario, o è la decisione "strumento di impresa" guida la tua scelta?

mi piacerebbe provare a impostare il motore di regole così è stato come disaccoppiato dal resto dell'impresa possibile. Non vorrei farlo chiamando a banche dati o servizi, se potessi. Meglio fare che la responsabilità degli oggetti per chiedere una decisione. Lasciate che li chiamano ai servizi web necessari e banche dati per assemblare i dati necessari, passarlo al motore di regole, e lasciar fare la sua cosa. L'accoppiamento è il tuo nemico: Prova di progettare il sistema per ridurre al minimo. Mantenere motori di regole isolato è un buon modo per farlo.

Answer 3

Non ho molto da dire sulla questione "quale server", ma vi invito a sviluppare servizi decisionali - Servizi callable che utilizzano regole di prendere decisioni, ma che non cambiano lo stato del business. Lasciando l'chiamando applicazione / servizio / processo di decidere quali modifiche dei dati per fare come risultato della chiamata al servizio di decisione e avendo il componente che si chiama in realtà avviare l'azione (s) suggerito dal servizio di decisione rende più facile da utilizzare il servizio di decisione più e più volte ancora una volta (attraverso i canali, processi, ecc). Il più pulito e meno legata al resto dell'infrastruttura del servizio decisione più riutilizzabile e gestibile che sta per essere. La discussione qui ebizQ potrebbe essere la pena di leggere a questo proposito .

Answer 4

Nella mia esperienza con motori di regole, abbiamo applicato una serie piuttosto semplice di pratiche di governare l'interazione con il motore delle regole. Prima di tutto, questi sono sempre stati regole motori commerciali (ILOG, Corticon) e non open source (Drools), quindi distribuire a livello locale per ciascuno dei server app non è mai stata davvero una valida opzione a causa di costi di licenza. Quindi, abbiamo sempre andato con il modello centralizzato, anche se in due sapori primari:

• Esecuzione remota di servizio Web - Allo stesso modo si è specificato nella sua interrogazione, facciamo le chiamate ai servizi basati su SOAP fornite dal prodotto regole del motore. Nel regno servizio web, siamo venuti su diverse opzioni: (1) "Boxcar" le richieste, consentendo l'applicazione in fila regole elaborazione delle richieste e inviarle sopra in blocchi al contrario di una tantum messaggi; (2) Tune le opzioni di filettatura e di processo forniti dal venditore. Questo include permettendo servizi decisionali separano da funzioni e assegnando a ciascuno un W3WP e / o utilizzando giardini web. C'è un sacco di tweaking aweful si può fare con vagoni, thread e processi e ottenere il giusto mix è più un processo di tentativi ed errori (e conoscendo i vostri set di regole e dati) che una scienza esatta.
• in remoto Chiamare il motore di regole in Process - Un classico trucco stile batch per evitare il sovraccarico di serializzazione e deserializzazione. A distanza effettuare una chiamata che spara a una chiamata in-process per il motore delle regole. Questo può essere fatto sia programmata (ad esempio batch) o basata su richiesta (ovvero "vagoni" di domande). In entrambi i casi un sacco di spese generali delle chiamate di servizio può essere evitato interagendo direttamente con il processo e il database. Lato negativo di questo processo è che non avete IIS o il vostro contenitore EJB / Servlet gestire i thread per voi e dovete farlo da soli.