Je suis sur le point de plonger dans un projet orienté des règles (en utilisant des règles ILOGS pour .NET - NOW IBM). Et j'ai lu quelques perspectives différentes quant à la manière de configurer le traitement des règles et comment interagir avec le moteur de la règle.
Les deux pensées principales que j'ai vues sont de centraliser le moteur de la règle (dans sa propre ferme de serveurs) et de programmer la ferme via une API de service Web (ou dans le cas de l'ILOG via WCF). L'autre côté consiste à exécuter une instance du moteur de la règle sur chacun de vos serveurs d'applications et d'interagir avec elle localement avec chaque instance ayant sa propre copie des règles.
Le côté de la centralisation est la facilité de déploiement des règles à un emplacement centralisé. L'échelle des règles au fur et à mesure que nécessaire, plutôt que de réduire chaque fois que vous élargissez votre configuration de serveur d'applications. Cela réduit les déchets d'une perspective de licence achetée. Le côté bas à cette installation est le surcharge supplémentaire de faire des appels de service, de la latence de réseau, etc.
L'avantage / inconvénient à exécuter localement le moteur de la règle est l'opposé exactement de la boutique / inconvénient de la configuration centralisée. Aucun appels de service SLOW (appels d'API rapides), pas de problèmes de réseau, chaque serveur d'applications se veut sur soi-même. La gestion du déploiement de règles devient plus complexe. Chaque fois que vous ajoutez un nœud à votre cloud de votre application, vous aurez besoin de plus de licences pour les moteurs de règles.
En lecture de papiers blancs, je vois que Amazon exécute le moteur de la règle par configuration du serveur App. Ils semblent faire un lent déploiement de règles et reconnaître que le retard dans la publication de règles est "acceptable" même si la logique commerciale est hors d'une synchronisation pendant une période donnée.
Question: de vos expériences, quelle est la meilleure façon de commencer à intégrer des règles dans une application Web basée sur la liste .NET pour un magasin qui n'a pas encore passé beaucoup de temps à travailler dans un monde dirigé? < / p>
4 Réponses :
Je n'ai jamais aimé l'argument de centralisation. Cela signifie que tout est couplé dans le moteur de règles, qui devient un terrain de dumping pour toutes les règles du système. Très bientôt, vous ne pouvez rien changer de peur de l'inconnu: "Que va-t-on casser?"
Je préfère de loin après l'idée d'Amazon des services comme composants isolés et autonomes. J'interprète cela signifie que les services possèdent leurs données et leurs règles .
Cela a l'avantage supplémentaire de partitionnement de l'espace des règles. Un ensemble de règles devient plus difficile à maintenir au fur et à mesure qu'il s'agrit; Mieux vaut les garder à une taille gérable.
Si des parties du jeu de règles sont partagées, je préférerais une approche DI entraînée par des données lorsqu'un service peut avoir sa propre instance d'un moteur de règles et charger les règles communes d'une base de données au démarrage. Cela pourrait ne pas être réalisable si votre licence d'ILOG réalise plusieurs instances coûtant prohibitif. Ce serait un cas où le produit censé aider pourrait réellement dicter des choix architecturaux qui apporteront du chagrin. Ce serait un bon argument pour une alternative moins coûteuse (par exemple, des règles JBoss en Java-Land).
Qu'en est-il d'une approche d'arbre de décision axée sur les données? Un moteur Règles à dos est-il vraiment nécessaire, o est la décision "Outil d'entreprise", conduisant votre choix?
J'essaierais de configurer le moteur de règles afin qu'il soit aussi découplé du reste de l'entreprise que possible. Je ne serais pas appelé aux bases de données ou aux services si je le pouvais. Mieux vaut que la responsabilité des objets demandant une décision. Laissez-les appeler les services Web et les bases de données nécessaires pour assembler les données nécessaires, transmettez-la au moteur de règles et laissez-la faire sa chose. Le couplage est votre ennemi: essayez de concevoir votre système pour le minimiser. Garder les moteurs de règles isolés est un bon moyen de le faire.
Dans mon expérience avec les moteurs de règles, nous avons appliqué un ensemble de pratiques assez fondamentales pour régir l'interaction avec le moteur de règles. Tout d'abord, ceux-ci ont toujours été des moteurs de règles commerciales (ILOG, CORTICON) et non open source (beools), donc déployez localement à chacun des serveurs d'applications n'a jamais été une option viable en raison de frais de licence. Par conséquent, nous sommes toujours allés avec le modèle centralisé, bien que deux saveurs primaires:
Je n'ai pas grand chose à dire sur la question "de quel serveur", mais je vous exhorte à développer des services de décision - services appelables qui utilisent des règles pour prendre des décisions, mais qui ne changent pas l'état de l'entreprise. Laisser la demande d'appel / service / processus / processus décider quelles sont les modifications de données à prendre à la suite de l'appelant le service de décision et de disposer de la composante appelante initier le (s) action (s) suggéré (s) que le service de décision facilite l'utilisation du service de décision sur à nouveau (à travers les canaux, les processus, etc.). Le nettoyant et moins attaché au reste de l'infrastructure le service de décision plus réutilisable et gérable. La discussion ici sur EBIZQ pourrait être de la lecture à cet égard .
Voici un résumé de notre architecture de règles immatures:
Nous examinons Dueeexecesserver en tant que plate-forme d'hébergement ainsi que RuleAppserverforsharePoint pour être l'hôte de la source de règles. Finalement, nous aurons des règles déployées sur la production en dehors du processus de libération de code.
L'obstacle principal de toutes nos règles de la règle est la modélisation et la règle des compétences à la création de règles.
ILOG.RULES.DLL et NOUVEAU UP RUETENGINES via une classe de regroupement personnalisée. Les Rueengines sont regroupées car il est coûteux de lier un peu de règles à une règle.
Les programmeurs doivent être écrire les moteurs de règles. Analystes d'entreprise Configurez des règles sur le moteur de règles et doit avoir une interface d'interface graphique pour la création de règles et enregistrer sur XML ou une base de données. En effet, la plupart des moteurs de règles échouent à ne pas intégrer la gestion correcte des flux de travail et ne gèrent que des règles, d'où la mise en œuvre de FCRE qui commencent à ajouter une complexité excessive des analystes métier pauvres, qui commencent ensuite à obliger les programmeurs à les aider. Le déploiement lent des règles est inacceptable dans un environnement commercial financier et donc probablement dans d'autres environnements.
Mais les programmeurs doivent également exposer des crochets et des daproints aux moteurs de règles pour travailler avec les BA. Les applications que nous écrivons doivent attacher en quelque sorte dans le moteur de la règle.
Oui, vos applications mettent des données dans le moteur de la règle, le moteur de la règle exécute des règles, des calculs, des processus personnalisés (où les programmeurs sont entrés, par exemple, si vous devez ajouter un appel WebService à mi-parcours de votre exécution de flux de travail) et épendez des réponses. L'interface (service Web, appel de méthode directe) doit être assez générique. Le BAS définit les noms de données qu'ils travaillent, et c'est ce que vous passez. Bien sûr, je suis sûr que les flux de travail financiers diffèrent des autres flux de travail / moteurs de règles. Nous accueillons nos moteurs de règles à Tomcat et les appelons via un service Web (infrastructures minuscules sur les règles elles-mêmes).
WOW. Vous dites que pour injecter un service Web au milieu d'un flux de règles à l'intérieur du moteur de règle est une pratique acceptable? Je pense actuellement que je ne ferai aucun accès de données à l'intérieur du moteur de la règle, mais j'attends plutôt que toutes les données que j'ai besoin pour travailler avec moi seront transmises à moi. Est-ce une sortie de la "Norme acceptée"? Avez-vous des liens vers des ressources avec les meilleures pratiques de développement des règles?
Je pense que nous travaillons de différentes idées ici. Un moteur de règle fait partie d'un flux de travail, un type d'activité pouvant être intégré. Les analystes d'entreprise créent des flux de décisions d'entreprise, qui incluent des règles de règles. Nous devons appeler des services Web externes (par exemple, des contrôles de crédit) dans le flux de travail. Cela pourrait être que nos besoins sont très différents (et c'est pourquoi je n'ai pas fait de commentaire).
"... Les programmeurs devraient être en train d'écrire des moteurs de règles ..." - S'ils veulent apprendre la manière dont les réglementations ont fait fonctionner ou si le budget ne permet pas d'en acheter un. Sinon, achetez-en un.
@Jeebee - # 1 règle de programmation: n'écrivez jamais ce que vous pouvez acheter, emprunter ou voler.