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

8

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

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

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

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

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

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

задан Andrew Siemer 28.07.2009 в 01:25
источник

4 ответа

2

Мы используем 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 - это узел для источника правил. В конце концов, у нас будут правила, развернутые для производства вне процесса выпуска кода.

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

    
ответ дан Amy B 29.07.2009 в 23:07
3

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

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

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

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

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

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

    
ответ дан duffymo 28.07.2009 в 03:22
2

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

    
ответ дан James Taylor 29.07.2009 в 22:51
0

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

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