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

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

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

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

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

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

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

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

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

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