D사에서 JBoss Rules(Drools)를 소개하는 시간을 가졌습니다. 현재 진행되는 프로젝트에서는 상용 룰엔진을 사용할 예정이라고 하셨습니다. 상용 룰엔진 도입을 앞두고 있어서 그런지 많은 관심을 보여 주셨고 다양한 질문을 해 주셨습니다. 질문 내용을 간단히 정리하면 아래와 같습니다.
현업분들이 손쉽게 룰을 작성할 수 있는가?
룰과 연관된 비즈니스 클래스들의 조회가 가능한가?
등록된 룰에 대한 리포팅 기능을 제공하는가?
룰 변경 이력을 관리할 수 있는가?
등록된 룰이 많을 경우에 메모리 및 성능저하 문제가 발생하지 않는가?
질문의 대부분은 룰에 대한 개발 및 관리 편의성에 맞추어져 있는 것을 알 수 있었습니다. 룰엔진 관련 오픈소스 비즈니스 모델을 고민하던 차에 소중한 영감을 받았던 시간이었습니다. 그리고 룰엔진의 성공적인 적용을 위해서는 모델링 파워가 더욱 필요함을 느낄 수 있었습니다.
그래서 메뉴얼을 자세히 보았더니 아니나다를까 --; Rule Script를 web상에서 아이콘으로 콕콕 찍어서 만들어주는 application이더라구요. process에 관한 건 없구요..그리고 여러 사람들이 만들어진 Rule들을 조회하고 다운받아가는...이게바로 '룰의 자산화' 라는거죠.
그럼 BPMS란 무엇일까요? 예전에 U-engine에서도 보았듯이 Business Process를 management하는 시스템입니다. Drools에서는 이클립스 플러그인으로 Rule flow를 비주얼하게 그려주는걸 BPMS라고 생각했나봐요..
BPMS는 JCF에 남겨진 숙제인것 같습니다. JCF에서 한참 공부하고 있는 Flex 같은 UI Framework이 셋팅된다면 저희도 Drools BRMS에 기반한 멋진 BPMS를 만들 수 있지 않을까 생각해보았습니다...
Jboss Rules (Drools) 룰엔진을 사용하다보면 Rule flow가 Rule Script의 부가적인 기능정도로 생각할 수도 있다.왜냐하면 Rule Script 만으로도 룰엔진을 사용할 수 있기 때문이다. 하지만 자세히 보면 Rule flow와 Rule Script는 각자 다른 개념을 가지고 있다.
Rule flow와 Rule Script를 비교해보자면..
Rule flow(Process)
적용될 비지니스 룰의 프로세스를 기술
비주얼 하게 표현가능
업무 순서 및 절차를 쉽게 변경할 수 있음
프로세스는 적용되는 프로젝트마다 매번 변경됨
를과 룰사이의 관계를 표시하여 업무 프로세스를 만듦
Rule Script(Logic)
Rule의 세부기능이 코드형태로 표현
Rule과 Rule사이의 관계가 없음 => 표준 업무를 룰 Script로 표현함.
ex)국세청 소득공제 산식
해당 프로젝트의 프로세스는 표현할 수 없음.
Rule Scirpt 만으로도 Rule flow를 정의할 수 있다. 하지만 권장하지는 않는다.
정리하자면
Rule Script로 업무의 필요한 표준 규칙들을 표현하는데 사용하여 ,프로젝트와 상관없이 Reuse를 가능하게 할 수 있음.
Rule flow는 룰Script로 만들어진 표준 룰들을 가져다가 룰과 룰사이의 관계를 지어준다. 그러므로 적용되는 프로젝트의 프로세스마다 룰 플로우는 다르다.
룰엔진을 자산화 하려면, 업무 표준을 Rule Script로 변환하여 Repository에서 관리해야함.=>이것이 바로 BRMS이다.
따라서 Rule Script와 Rule flow를 필요한 곳에 적절히 사용하는 것이 룰엔진 활용의 핵심이라 할 수 있다.
JSR-94는 자바 기반 룰 엔진 구현을 위해 썬 마이크로 시스템에서 제안 한 표준 API이다. 여기서는 룰을 등록, 제거, 필터적용. 세션관리와 같은 표준을 제공하며, 다양한 벤더의 룰엔진과 연동이 가능하다. 룰엔진과 스프링 IOC의 결합은 spring Extensions(JSR-94)를 통해 연결할 수 있다.
JBoss Rules 란?
JBoss Rules은 drools 룰엔진으로 더욱 잘 알려져 있는 오픈소스 룰엔진이다. 이클립스 플러그인이 제공되어 자동화된 룰 파일 작성, 비주얼한 룰 플로우 작성 기능도 제공하고 있다. 충실한 매뉴얼을 제공하는 오픈소스 룰엔진이라는 점은 Jboss Rules의 최대 장점이다.
spring Extensions(JSR-94) Configuration
Spring Configuration에서는 <리스트1>과 같이 6개의 bean을 등록한다. rulServiceProvider bean에서는 적용하려고하는 룰엔진을 등록한다. 실행은 ruleRuntime bean에서 담당하고, ruleSource bean에서 사용자가 작성한 룰파일을 임포트한다. jsr94Template bean에서는 적용된 ruleSource를 비즈니스 로직에서 적용할 수 있는 Jsr94Template 클래스를 제공한다.
<리스트 1> spring Extensions(JSR-94)의 JbossRules configuration의 예
비즈니스 로직에서 룰엔진 불러오기
비즈니스 로직은 위에서 언급한 jsr94Template 클래스를 이용해서 룰 엔진을 실행한다. 이를 위해서는 서비스클래스가 선언된 bean에 jsr94template bean을 선언해주어야 한다.
비즈니스 로직에서는 룰엔진이 적용될 오브젝트를 선언하고, 룰엔진에 해당 오브젝트를 넣어주는 부분이 필요하다. jsr94Template은 적용대상 오브젝트를 List 타입으로 받는다. 이는 여러 개의 오브젝트를 대상으로 룰 파일을 작성하는 것이 가능함을 의미한다.
룰 세션 적용 방법(stateless, stateful)
JSR-94 API에서는 룰 세션을 적용할 때 두 종류의 적용방법을 제공한다.
첫째는 stateless 방식이다. 이는 말 그대로 룰세션을 유지하지 않겠다는 의미이다. 그러므로 룰엔진에 적용될 오브젝트가 생길 때마다 룰엔진 적용되었던 기존 오브젝트를 모두 넣어주어야 한다.
두 번째 방식은 stateful 방식이다. 이 방식에서는 룰세션이 유지되므로 룰엔진을 불러오는 로직에서는 룰을 적용할 대상 오브젝트를 추가해주기만 하면 된다. 한 어플리케이션에서 여러 개의 비즈니스 로직이 룰엔진을 사용할 경우 룰세션이 유지되는 stateful방식을 사용하는 것이 유리하다.
각 방식에 따라 비즈니스 로직에서 룰엔진을 불러오는 코드가 달라지는데 적용 예를 <리스트2> <리스트3>에서 볼 수 있다.
--
public Employee findEmployee(int employeeId ) throws Exception { final Employee employee = employeeDao.findEmployee(employeeId); getTemplate().executeStateless(EMPLOYEE_RULE_URI, null,new StatelessRuleSessionCallback() { public Object execute(StatelessRuleSession session) throws InvalidRuleSessionException,RemoteException { List employeeList = new ArrayList(); employeeList.add(employee); return (Employee)(session.executeRules(employeeList)).get(0);}}); return (Employee)employee; } <리스트 2> stateless 방식에서 룰엔진을 적용하는 예