2012-12-11 4 views
9

우리 프로젝트에서는 특정 객체를 일부 동작에 매핑하는 것과 관련된 비즈니스 로직을 구현해야합니다. 특정 작업이 최종적으로 해결되기 전에 확인해야 할 특정 유형의 개체에 대한 일련의 조건이 있습니다. 즉, 7 가지 유형의 객체에 대해 우리는 일련의 동작을 수행 할 수 있습니다 (거의 45 개의 동작 중에서).Drools는 비즈니스 규칙/논리를 매핑하는 가장 효율적인 방법입니까?

우리는 앞서 언급 한 규칙을 적어두기 위해 Drools를 사용하려고 생각했습니다. 효율성면에서 Drools 사용에 대한 긍정적/부정적 경험이 있습니까? 또한 사용할 수있는 jBPM 프레임 워크가 있습니다 (내가 Drools를 사용하는 것으로 잘못 생각하지 않는다면 누구나 해당 프레임 워크에 익숙합니까?). 문제를 해결하는 방법에 대한 다른 아이디어가 있습니까?

답변

7

효율면에서 Drools에는 전혀 문제가 없어야합니다. 그것은 나에게 아주 작은 사실들과 규칙들처럼 들린다. 그것이 기반으로하는 Rete 엔진은 if-then-else 문장의 더미보다 의사 결정을 할 때 거의 빠릅니다. 그리고 제가 발견 한 특별한 이점은 응답 시간이 매우 예측 가능하다는 것입니다.

분명히 모든 사실 모델과 규칙은 다릅니다. 예를 들어, 제가 현재 만들고있는 응용 프로그램은 언제든지 작업 메모리에서 수백 가지 사실과 1000 가지 이상의 규칙을 가지고 있습니다. 들어오는 요청에 대해 약 20 밀리 초 내에 결정을 내릴 수 있습니다.

전체 jBPM 프레임 워크는 사용자의 설명에 필요하지 않습니다. 그러나 그것이하는 일에 능숙합니다. 예를 들어, 워크 플로우를 설계하려는 경우 GUI를 모델링하는 프로세스가 있으며 기술 팀이 DSL 작성 및 의사 결정 테이블 작성에 대한 선행 노력을 기울이는 경우 Guvnor는 비 기술적 인 규칙 작성자에게 유용 할 수 있습니다.

완벽을 기하기 위해 주요 경쟁 업체는 FICO Blaze Adviser 또는 IBM ILog JRules입니다. 일반적으로 벤치 마크에서 Drools보다 약간 앞서가는 경향이 있지만 비용이 많이 듭니다. 물론 JBoss/RedHat 서비스 계약에 대한 비용을 지불하기로 결정한 경우에는별로 다르지 않지만 Drools에 대한 커뮤니티 지원을 기꺼이 받아 들일 수 있다면 무료입니다!

+0

답변 해 주셔서 감사합니다. 우리는 프로젝트에서 Drools를 사용하기로 결정했으며 우리는 그것에 만족합니다. 아주 좋은 점은 우리 규칙을 DRL 파일에 보관하고 매번 응용 프로그램을 다시 배포 할 필요가 없다는 것입니다. –

4

Drools에 대한 유일한 우려는 비 IT 비즈니스 사람들이 실제로 사용할 수있는 적절한 GUI가 없다는 것입니다. 많은 제품들이 그러한 UI를 제공한다고 주장하지만 항상 사실이 아님이 밝혀졌습니다. 따라서 개발 팀이 의사 결정 테이블이나 다른 형식을 기반으로 모든 규칙을 작성하고 테스트하게 될 것이라는 사실을 받아 들여야합니다.

Drools는 정부, 은행 및 대기업에서 사용하는 훌륭한 BRE입니다.

+1

100 % true. 그러나 그가주는 설명에 따르면, 아마도 의사 결정 테이블이 좋은 후보자가 될 수 있습니다. 그렇다면 적은 수의 통증이있는 ​​IT 직원이 없어도 규칙을 관리 할 수 ​​있습니다. –

+3

@EstebanAliverti 이론적으로 당신은 절대적으로 옳습니다. 의사 결정 테이블의 전제는 비즈니스에서 IT를 추상화하는 것이 었습니다. 실제로 이것은 결코 작동하지 않습니다. 나는 15 년 동안 BREs를 다뤄 왔으며, 모든 큰 것들을 경험했습니다. 비즈니스맨이 도움이되지 않는 테이블을 만들고 편집하는 프로젝트를 본 적이 없습니다. IT의 도움. 형식/행동/조건이 항상 바뀌고 새로운 비즈니스 사람들이 들어오는 등 등 – Kizz

+1

답장을 보내 주셔서 감사합니다! 우리는 프로젝트에서 Drools를 사용하기로 결정했으며 우리는 그것에 만족합니다. 물론 GUI에는 문제가 있지만 스프레드 시트의 의사 결정 테이블을 사용하여 무시할 수 있습니다. 내 블로그에 게시물이 있습니다. [link] (http://toomuchcoding.blogspot.com/2013/02/drools-dec-tables-with-camel-and.html) –

1

Drools는 매우 효율적이고 빠릅니다. 그러나 어떤 기술의 경우처럼 & 프레임 워크는 프로젝트에 통합하기위한 투자가 필요하며 그것은 마법의 총알이 아닙니다. 다음을 고려해야합니다.

  • 얼마나 많은 규칙을 갖게됩니까? 규칙이 20 개 미만인 경우 어떤 규칙 엔진도 권장하지 않습니다. 7 개의 객체와 45 개의 액션에 대해 규칙 엔진을 추가하는 데 드는 노력을 정당화 할 수 없습니다.
  • DSL (도메인 특정 언어) 기능이 필요합니까? 예. 비 기술적 인 사람들이 규칙을 쓸 것인가? IMHO 이것은 Drools에서 예를 들어 비교할 때별로 유용하지 않습니다. 오라클 OPA. 그러나 나는 아직 규칙 시스템으로 안전하게 기술자가 아닌 사람을 보지 못했다. 의사 결정 테이블에서 값을 변경하는 것 외에도.
  • 얼마나 자주 규칙이 변경됩니까? Drools Guvnor는 규칙을 관리, 버전 화, 패키지화 및 테스트하기위한 중앙 집중식 시스템이 필요한 경우 매우 유능한 제품입니다.
1

jBPM은 규칙 엔진이 아니며 워크 플로 엔진입니다. Drools는 규칙 엔진입니다. Drools가 당신이 찾고있는 것입니다.

Drools와 jBPM은 함께 제공되는 프로젝트입니다. 규칙을 사용하여 워크 플로가 필요한 경우 정말 멋지게 통합됩니다.

JBPM은 다른 BPMN 엔진과 비교하여 JBPM이 약간 복잡합니다. 액티 티티 (Activiti)에 대한 제안은 조금 더 쉽고 통합에있어 Spring, LDAP 등을 말하기 때문에 좋습니다. Activiti는 더 쉽습니다. 또한 Drools와 Activiti를 통합 할 수 있습니다. Activiti를 aworkflow 엔진으로, Drools를 규칙 엔진으로 사용하십시오.