Критерии оценки механизмов бизнес-правил

Drools (раньше было Drools, затем JBoss Rules, затем снова Drools) - очень хороший движок правил с открытым исходным кодом. и обязательно стоит посмотреть.

На мой взгляд, лучшими критериями для оценки движка правил являются:

• Настраивается ли он (иначе вы бы просто написали код вместо этого)
• Это работоспособно.
• Насколько легко нетехническим людям изменить правила
• Насколько легко развертывать новые наборы правил (и отменять развертывание старых).

Некоторые механизмы правил имеют системы управления бизнес-правилами (BRMS), и Drools не является исключением. Это значительно упрощает развертывание для нетехнических специалистов.

Существует хорошая поддержка Drools в виде документации и руководств в Интернете и даже через канал IRC.

Я также использовал Rules Engine, который поставляется с IBM Websphere Process Server, и обнаружил, что он тоже неплохой (хотя и дорогой).

Я работал консультантом в ведущей системе правил в отрасли около трех лет. Вы заплатите МНОГО денег за коммерческий механизм правил, и вам нужно будет решить, стоят ли возможности и поддержка, которые вы потенциально получаете, своей цены. Все поставщики механизмов правил будут утверждать, что у них лучшие руки вниз; лучший совет, который я могу вам дать, - это создать прототип с каждым рассматриваемым вами механизмом правил, который имеет ограниченный объем, но представляет необходимые вам функции. НЕ позволяйте продавцам просто показывать вам модную демонстрацию; ВЫ должны активно строить прототип. Я видел, как слишком много людей покупают систему правил, не имея ни малейшего представления о том, что они покупают. Лично я бы выбрал один из движков правил с открытым исходным кодом (кто-то уже упоминал Drools), если вы настроены на движок правил. Однако я бы серьезно рассмотрел наряду с механизмами правил возможность отказа от механизма правил. Вы можете сначала сэкономить время с помощью механизма правил (игнорируя кривую обучения), но индивидуальное решение, вероятно, будет лучше в долгосрочной перспективе, чтобы удовлетворить ваши конкретные потребности.

Вот пара ссылок с веб-сайта Мартина Фаулера, которые имеют отношение к вашему вопросу:

• http://www.martinfowler.com/bliki/RulesEngine.html
• http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

Я работаю со многими коммерческими поставщиками и, в отличие от Мартина, общаюсь со многими их клиентами. Реальность такова, что системы управления бизнес-правилами действительно работают и окупают инвестиции в кривую обучения и т. Д. В первом проекте задолго до того, как начнут действовать преимущества сокращения обслуживания и увеличения числа бизнес-пользователей. Drools отлично подходит как решение с открытым исходным кодом и является ведущим коммерческими продуктами являются: Правила IBM / ILOG (.Net, Java и COBOL) FICO Blaze Advisor (.Net, Java и COBOL) InRule Technology (.Net) Программное обеспечение для инноваций (Java) Oracle и SAP имеют на своих платформах механизмы правил, которые все больше и больше. Я просматриваю множество новых выпусков, а также продукты меньшинств на http://jtonedm.com/category/product-news/

У Forrester есть хороший волновой отчет о бизнес-правилах, который я рекомендую, и на моем сайте есть сообщение с его обсуждением (на которое я бы поставил ссылку, но stackoverflow пока не позволяет мне добавить вторую ссылку) - свяжитесь со мной, если вам нужны ответы.

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

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

Это позволяет вашим бизнес-аналитикам реализовывать весь процесс, а не просто выполнять простые правила if-then-else (ха-ха, некоторые коммерческие механизмы правил не могут делать ничего другого! См. Комментарий об оценке вариантов перед принятием решения), будь то простые последовательные rules или FCIRE (механизм правил вывода с прямым выводом). Большинству бизнес-аналитиков легче думать о простых последовательных наборах правил. Это необходимо делать на уровне рабочего процесса, потому что третьи стороны, которых бизнес-аналитики интерпретируют в правила, имеют тенденцию изменять все свои процессы принятия решений / принятия / отклонения / внутренней политики с очень небольшим уведомлением.