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

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

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

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

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

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