Les méthodes préférées pour interagir avec un moteur de règles

Question

Je suis sur le point de plonger dans un projet axé sur les règles (en utilisant iLogs règles pour .NET - maintenant IBM). Et je l'ai lu quelques points de vue différents sur la façon de mettre en place le traitement des règles et la façon d'interagir avec le moteur de règle.

Les deux principales réflexions que j'ai vu est de centraliser le moteur de règles (dans sa propre ferme de serveurs) et le programme contre la ferme via une API de service Web (ou dans le cas d'ILOG via WCF). L'autre côté est d'exécuter une instance du moteur de règle sur chacun de vos serveurs d'applications et d'interagir avec localement chaque instance ayant sa propre copie des règles.

Le côté à la centralisation est la facilité de déploiement des règles à un emplacement centralisé. Les règles échelle car ils doivent plutôt que de mise à l'échelle à chaque fois que vous développez votre configuration du serveur d'applications. Cela réduit les déchets dans une perspective de licence achetée. L'inconvénient de ce jeu est de jusqu'à la surcharge supplémentaire de faire des appels de service, la latence du réseau, etc.

L'avantage / inconvénient de courir localement le moteur de règles est l'exact opposé de l'envers / l'inconvénient de la configuration centralisée. Aucun appel de service lent (appels API rapide), pas de problèmes de réseau, chaque serveur d'applications repose sur elle-même. Gestion du déploiement de règles devient plus complexe. Chaque fois que vous ajoutez un nœud à votre application cloud vous aurez besoin de plus de licences pour les moteurs de règle.

En lisant des livres blancs, je vois que Amazon fonctionne le moteur de règles par configuration de serveur d'applications. Ils semblent faire un lent déploiement de règles et reconnaissent que le retard dans la publication de la règle est « acceptable », même si la logique métier est hors d'une synchronisation pendant une période de temps donnée.

Question: De vos expériences, quelle est la meilleure façon de commencer à intégrer des règles dans une application basée sur le Web .net pour un magasin qui n'a pas encore passé beaucoup de temps à travailler dans un règlement monde axé sur

Answer 1

Nous utilisons ILOG Pour DotNet et un projet pilote déployé.

Voici un résumé de nos règles immatures Architecture:

1. Toutes les données d'accès fait en dehors des règles.
2. Les règles sont déployées de la même manière que le code (commande de la source, le processus de libération, bla bla).
3. Projets (services) informatiques Les règles d'utilisation ont une référence à ILOG.Rules.dll et RuleEngines nouveaux-via une classe de mise en commun personnalisée. RuleEngines sont mis en commun car il est coûteux de se lier à un RuleSet un RuleEngine.
4. Presque toutes les règles sont écrites à attendre des objets Assert'd, plutôt que des paramètres RuleFlow.
5. Étant donné que les règles gérées dans le même espace mémoire, les instances qui sont modifiées par les règles sont les mêmes instances dans le programme -. Qui est la propagation immédiate de l'état
6. Presque toutes les règles sont gérées par RuleFlow (même si elle est un RuleStep dans le RuleFlow).

Nous examinons RuleExecutionServer comme une plate-forme d'hébergement, ainsi que RuleTeamServerForSharePoint d'être l'hôte pour la source de règles. Par la suite, nous avons des règles déployées à la production en dehors du processus de libération de code.

Le principal obstacle dans tous nos efforts de règle est skillsets de modélisation et de la règle Création.

Answer 2

J'ai jamais aimé l'argument de la centralisation. Cela signifie que tout est couplé au moteur de règles, qui devient un dépotoir pour toutes les règles du système. vous pouvez très bientôt ne change rien par peur de l'inconnu: « Que ferons-nous briser »

Je préfère beaucoup suivant l'idée d'Amazon des services isolés, des composants autonomes. J'interprète que cela signifie que les services sont propriétaires de leurs données et leurs règles .

Ceci a l'avantage de diviser l'espace des règles. Un ensemble de règles devient plus difficile à maintenir car il se développe; mieux les garder à une taille gérable.

Si certaines parties de l'ensemble de règles sont partagées, je préfère une approche, DI axée sur les données où un service peut avoir sa propre instance d'un moteur de règles et de charger les règles communes à partir d'une base de données au démarrage. Cela pourrait ne pas être possible si votre licence iLog fait plusieurs instances coût prohibitif. Ce serait un cas où le produit qui est censé aider pourrait effectivement dicter des choix architecturaux qui apporteront la douleur. Ce serait un bon argument pour une alternative moins coûteuse (par exemple, les règles JBoss en Java terre).

Qu'en est-il une approche de l'arbre de décision axée sur les données? Est un moteur de règles Rete vraiment nécessaire, o est la décision de conduire « outil d'entreprise » votre choix?

Je vais essayer de mettre en place le moteur de règles il était aussi découplée du reste de l'entreprise que possible. Je ne l'aurais pas d'appeler vers des bases de données ou de services si je pouvais. Il vaut mieux faire que la responsabilité des objets demandant une décision. Laissez-les appeler aux services Web et bases de données nécessaires pour rassembler les données nécessaires, transmettre au moteur de règles, et le laisser faire sa chose. Le couplage est votre ennemi: Essayez de concevoir votre système pour minimiser. Maintenir des moteurs de règles isolées est une bonne façon de le faire.

Answer 3

Je n'ai pas grand chose à dire sur la question « quel serveur » mais je vous invite à développer des services de décision - services appelables qui utilisent des règles pour prendre des décisions, mais qui ne change pas l'état de l'entreprise. Laisser le résultat d'une application d'appels / services / processus décident quels sont les changements de données pour faire en appelant le service de décision et ayant le composant appelant réellement lancer l'action (s) proposé par le service de décision rend plus facile d'utiliser le service de décision à plusieurs reprises à nouveau (à travers les canaux, les processus, etc.). Le plus propre et moins attaché au reste plus réutilisable et facile à gérer, il va être de l'infrastructure du service de décision. La discussion ici sur ebizQ pourrait être utile de lire à cet égard .

Answer 4

Dans mon expérience avec des moteurs de règles, nous avons appliqué un ensemble assez basique des pratiques régissant l'interaction avec le moteur de règles. Tout d'abord, ceux-ci ont toujours été des règles commerciales moteurs (Ilog, Corticon) et non open source (Drools), déployer localement donc à chacun des serveurs d'application n'a jamais vraiment été une option viable en raison des coûts de licence. Par conséquent, nous avons toujours allé avec le modèle centralisé, mais en deux saveurs primaires:

• exécution à distance de service Web - De la même façon que vous avez indiqué dans votre question, nous faisons des appels aux services SOAP fournis par le produit du moteur de règles. Dans le domaine des services web, nous avons à plusieurs options: (1) les demandes « Boxcar », permettant l'application de la queue de traitement des demandes et des règles les envoyer en morceaux, par opposition à un arrêt des messages; (2) les options Tune de filetage et de processus fournis par le vendeur. Cela consiste notamment à permettre la séparation des services de décision par la fonction et l'attribution d'un chacun W3WP et / ou en utilisant des jardins Web. Il y a un grand nombre d'entre vous aweful peaufinage pouvez faire avec les fils, les wagons couverts et les processus et d'obtenir la bonne combinaison est plus un processus d'essais et d'erreurs (et connaître vos données) Rulesets et d'une science exacte.
• Appel Remotely le moteur de règles dans le processus - Un truc de style classique par lot pour éviter la surcharge de sérialisation et désérialisation. Faire un appel à distance qui se déclenche d'un appel au moteur de règles en cours. Cela peut être fait soit prévue (par exemple lot) ou fonction de la demande (à savoir « » des demandes wagons couverts). De toute façon beaucoup de frais généraux des appels de service peut être évité en interaction directe avec le processus et la base de données. Le seul inconvénient de ce processus est que vous n'avez pas IIS ou votre EJB / conteneur Servlet gestion des threads pour vous et vous devez le faire vous-même.