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

Question

Я собираюсь погрузиться в проект, ориентированный на правила (с использованием правил ILOG для .NET — теперь IBM).И я прочитал пару разных точек зрения на то, как настроить обработку правил и как взаимодействовать с механизмом правил.

Две основные идеи, которые я увидел, - это централизовать механизм правил (в отдельную ферму серверов) и запрограммировать ферму через API веб-сервиса (или, в случае ILOG, через WCF).Другая сторона — запустить экземпляр механизма правил на каждом из ваших серверов приложений и взаимодействовать с ним локально, причем каждый экземпляр имеет свою собственную копию правил.

Плюсом централизации является простота развертывания правил в централизованном месте.Правила масштабируются по мере необходимости, а не масштабируются каждый раз, когда вы расширяете конфигурацию сервера приложений.Это уменьшает потери с точки зрения приобретенной лицензии.Обратной стороной этой настройки являются дополнительные накладные расходы на выполнение сервисных вызовов, задержку в сети и т. д.

Плюсы и минусы локального запуска механизма правил являются полной противоположностью плюсов и минусов централизованной конфигурации.Никаких медленных сервисных вызовов (быстрых вызовов API), никаких проблем с сетью, каждый сервер приложений полагается на себя.Управление развертыванием правил становится более сложным.Каждый раз, когда вы добавляете узел в облако приложений, вам потребуется больше лицензий для механизмов правил.

Читая официальные документы, я вижу, что Amazon использует механизм правил для каждой конфигурации сервера приложений.Похоже, они медленно развертывают правила и признают, что задержка в публикации правил «приемлема», даже если бизнес-логика не синхронизирована в течение определенного периода времени.

Вопрос: Исходя из вашего опыта, как лучше всего начать интеграцию правил в веб-приложение на базе .net для магазина, который еще не провел много времени, работая в мире, управляемом правилами?

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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