Предпочтительные методы взаимодействия с механизмом правил

Мы используем ILOG для DotNet и уже развернули пилотный проект.

Вот краткое изложение нашей незрелой архитектуры правил:

1. Весь доступ к данным осуществляется вне правил.
2. Правила развертываются так же, как и код (контроль версий, процесс выпуска, yada yada).
3. Проекты (службы), использующие правила, имеют ссылку на ILOG.Rules.dll и новые механизмы RuleEngines через настраиваемый класс объединения. RuleEngines объединены в пул, потому что привязать RuleSet к RuleEngine дорого.
4. Почти все правила написаны для ожидания объектов Assert'd, а не параметров RuleFlow.
5. Поскольку правила выполняются в одном и том же пространстве памяти, экземпляры, измененные правилами, являются такими же экземплярами в программе, что является немедленным распространением состояния.
6. Почти все правила выполняются через RuleFlow (даже если это единственный RuleStep в RuleFlow).

Мы рассматриваем RuleExecutionServer как платформу хостинга, а также RuleTeamServerForSharePoint как хост для источника правил. В конце концов, правила будут развернуты в производственной среде вне процесса выпуска кода.

Основным препятствием во всех наших усилиях по разработке правил являются наборы навыков моделирования и разработки правил.

Мне никогда не нравился аргумент централизации. Это означает, что все объединено в механизм правил, который становится свалкой для всех правил в системе. Довольно скоро вы не сможете ничего изменить из-за страха перед неизвестным: «Что мы сломаем?»

Я предпочитаю следовать идее Amazon об услугах как об изолированных автономных компонентах. Я интерпретирую это как то, что сервисы владеют их данными и своими правилами.

Это дает дополнительное преимущество в виде разделения пространства правил. По мере роста набора правил становится все труднее поддерживать; лучше держать их в приемлемом размере.

Если части набора правил являются общими, я бы предпочел управляемый данными подход DI, когда служба может иметь собственный экземпляр механизма правил и загружать общие правила из базы данных при запуске. Это может оказаться невозможным, если ваша лицензия iLog делает несколько экземпляров слишком дорогими. Это будет тот случай, когда продукт, который должен помочь, на самом деле может диктовать архитектурный выбор, который принесет горе. Это был бы хороший аргумент в пользу менее дорогой альтернативы (например, JBoss Rules в Java-land).

А как насчет подхода дерева решений, основанного на данных? Действительно ли необходим механизм правил Rete, или решение о «корпоративном инструменте» влияет на ваш выбор?

Я бы попытался настроить механизм правил так, чтобы он был максимально изолирован от остальной части предприятия. Если бы я мог, он бы не обращался к базам данных или службам. Лучше возложить ответственность на объекты, требующие решения. Позвольте им вызвать необходимые веб-службы и базы данных для сбора необходимых данных, передать их механизму правил и позволить ему делать свое дело. Сцепление - ваш враг: постарайтесь спроектировать свою систему так, чтобы его минимизировать. Изолирование механизмов правил - хороший способ сделать это.

Мне нечего сказать по вопросу «какой сервер», но я бы посоветовал вам разработать службы принятия решений - вызываемые службы, которые используют правила для принятия решений, но не меняют состояние бизнеса. Позволяя вызывающему приложению / службе / процессу решать, какие изменения данных вносить в результате вызова службы принятия решений и когда вызывающий компонент фактически инициирует действие (я), предложенное службой принятия решений, упрощает многократное использование службы принятия решений. снова (по каналам, процессам и т. д.). Чем чище и менее привязан к остальной инфраструктуре служба принятия решений, тем более многоразовой и управляемой она будет. В этой связи, возможно, стоит прочитать обсуждение здесь, на ebizQ. .

По моему опыту работы с механизмами правил, мы применили довольно простой набор практик для управления взаимодействием с механизмом правил. Прежде всего, это всегда были коммерческие механизмы правил (iLog, Corticon), а не с открытым исходным кодом (Drools), поэтому локальное развертывание на каждом из серверов приложений никогда не было жизнеспособным вариантом из-за затрат на лицензирование. Следовательно, мы всегда использовали централизованную модель, хотя и в двух основных вариантах:

• Удаленное выполнение веб-службы. Таким же образом, как вы указали в своем вопросе, мы обращаемся к службам на основе SOAP, предоставляемым продуктом механизма правил. В области веб-сервисов мы столкнулись с несколькими вариантами: (1) «Boxcar» запросы, позволяющие приложению ставить в очередь запросы обработки правил и отправлять их частями, а не разовыми сообщениями; (2) Настройте параметры потоков и обработки, предоставленные поставщиком. Это включает в себя возможность разделения служб принятия решений по функциям и выделение каждой W3WP и / или использование веб-садов. Существует огромное количество настроек, которые вы можете сделать с товарными вагонами, потоками и процессами, и получение правильного сочетания - это скорее процесс проб и ошибок (и знание ваших наборов правил и данных), чем точная наука.
• Удаленный вызов обрабатываемой системы правил - классический прием пакетного стиля, позволяющий избежать накладных расходов на сериализацию и десериализацию. Выполнение удаленного вызова, инициирующего внутрипроцессный вызов механизма правил. Это может быть выполнено либо по расписанию (например, партиями), либо по запросу (например, «товарные вагоны» запросов). В любом случае можно избежать значительных накладных расходов на вызовы сервисов, напрямую взаимодействуя с процессом и базой данных. Обратной стороной этого процесса является то, что у вас нет IIS или контейнера EJB / сервлета, управляющего потоками за вас, и вам придется делать это самостоятельно.