비즈니스 규칙 엔진

Business rules engine

비즈니스 규칙 엔진은 런타임 프로덕션 환경에서 하나 이상의 비즈니스 규칙을 실행하는 소프트웨어 시스템이다. 이 규칙은 법적 규제("직원은 어떠한 이유나 이유 없이 해고될 수 있지만 불법적인 이유 없이 해고될 수 있다"), 회사 정책("한 번에 100달러 이상을 지출하는 모든 고객은 10%의 할인을 받을 것이다") 또는 기타 출처에서 나올 수 있다. 비즈니스 규칙 시스템은 이러한 회사 정책 및 기타 운영 결정을 애플리케이션 코드와 별도로 정의, 테스트, 실행 및 유지하도록 한다.

규칙 엔진은 일반적으로 규칙, 사실, 우선 순위(점수), 상호 배제, 전제 조건 및 기타 기능을 지원한다.

규칙 엔진 소프트웨어 일반적으로, 이는 기능 중, 레지스터:기 위한 기능을 제공하는 업무 규칙 관리 시스템을 구성 요소를 구분하고, 모든 규칙을 관리, 규칙 정의의 일관성을 확인할 때 발주량>("Gold-level 고객들은 무료 배송비를 받을 수 있는 대상을 정의하라 10초나``최대 주문 quant 제공된다.무효 Silver 레벨 고객 = 15" )의 경우, 서로 다른 규칙 간의 관계를 정의하고, 이러한 규칙의 일부를 영향을 받거나 하나 이상의 규칙을 시행해야 하는 IT 애플리케이션과 연관시킨다.

IT 사용

어떤 IT 애플리케이션에서도, 비즈니스 규칙은 애플리케이션 코드의 다른 부분보다 더 자주 변경될 수 있다. 규칙 엔진 또는 추론 엔진은 비즈니스 규칙 접근방식이 외부화되거나 애플리케이션 코드에서 분리된 비즈니스 규칙을 실행하는 플러그형 소프트웨어 구성요소 역할을 한다. 이러한 외부화 또는 분리를 통해 비즈니스 사용자는 IT 개입 없이도 규칙을 수정할 수 있다. 시스템 전체가 그러한 외부 비즈니스 규칙으로 더 쉽게 적응할 수 있게 되지만, 이는 QA 및 기타 테스트의 일반적인 요구사항을 배제하지는 않는다.

역사

컴퓨터월드의 한 기사는 1990년대 초까지의 규칙 엔진과 페어 아이작 사와 ILOG와 같은 종류의 제품들을 추적한다.[1]

설계 전략

많은 조직의 규칙 노력은 일반적으로 워크플로우 설계로 간주되는 측면과 전통적인 규칙 설계를 결합한다. 이러한 두 접근방식을 분리하지 못하면 비즈니스 규칙과 워크플로우를 모두 재사용하고 제어할 수 있는 능력에 문제가 발생할 수 있다. 이러한 난관을 피할 수 있는 설계 방식은 다음과 같이 비즈니스 규칙과 워크플로우의 역할을 분리한다.[2]

  • 비즈니스 규칙은 지식을 생산한다.
  • 워크플로우는 비즈니스 작업을 수행한다.

구체적으로, 이는 사업 규칙이 사업 상황이 발생했음을 감지하고 사업 이벤트를 발생시키거나(일반적으로 메시징 인프라를 통해 운반됨) 더 높은 수준의 사업 지식을 창출할 수 있다는 것을 의미한다(예: 대출이 충족되는지 여부에 관한 일련의 조직, 제품 및 규제 기반 규칙 평가).s에 따라 작성 기준). 반면에, 워크플로우는 일련의 활동을 개시하여 라우팅 지점의 과부하와 같은 것을 나타내는 이벤트에 응답한다.

이러한 분리는 많은 다른 워크플로우에 의해 동일한 비즈니스 판단(모기지금이 과부하 기준을 충족) 또는 비즈니스 이벤트(라우터 과부하)가 대응될 수 있기 때문에 중요하다. 규칙 중심의 지식 창출에 대응하여 수행한 작업을 규칙 자체에 포함시키면 업무 흐름을 구체화하므로 조직 전체에 걸쳐 비즈니스 규칙이 재사용될 수 있는 능력이 크게 감소한다.

비즈니스 규칙 엔진을 채택한 아키텍처를 구축하려면 이벤트에 대응하거나 비즈니스 규칙에 의해 정의된 비즈니스 판단을 검토하는 프로세스를 기반으로 하는 BPM(비즈니스 프로세스 관리)과 BRM(비즈니스 규칙 관리) 플랫폼 간의 통합을 구축하는 것이 필수적이다. 시장에는 이러한 통합을 기본적으로 제공하는 몇 가지 제품이 있다. 다른 상황에서는 이러한 유형의 추상화와 통합이 특정 프로젝트 또는 조직 내에서 개발되어야 할 것이다.

대부분의 자바 기반 규칙 엔진은 다른 애플리케이션과의 통합을 위해 JSR-94 API(응용프로그램 프로그래밍 인터페이스) 표준에 근거한 기술 콜 레벨 인터페이스를 제공하며, 많은 규칙 엔진은 WSDL, SOAP와 같은 웹 기반 표준을 통한 서비스 지향 통합을 허용한다.

대부분의 규칙 엔진은 비즈니스 실체를 나타내는 데이터 추상화 개발 능력과 규칙이 작성되어야 하는 관계를 제공한다. 이 사업체 모델은 일반적으로 XML, POJO, 플랫 파일 등을 포함한 다양한 소스에서 채워질 수 있다. 규칙 자체를 쓰는 데는 표준어가 없다. 많은 엔진들이 자바와 같은 구문을 사용하는 반면, 일부는 맞춤형 비즈니스 친화적인 언어의 정의를 허용한다.

대부분의 규칙 엔진은 호출 가능한 라이브러리로서 기능한다. 하지만, RDBMS가 행동하는 방식과 유사한 일반적인 프로세스로 운영되는 것이 더 인기를 끌고 있다. 실제로 전체 규칙 실행 인스턴스에 대한 코드 생성기가 있고 사용자가 선택할 수 있도록 허용하는 엔진도 있지만 대부분의 엔진은 규칙을 프로세스 인스턴스에 로드할 구성으로 취급한다.

규칙 엔진 유형

많은 다른 종류의 규칙 엔진들이 있다. 이러한 유형(일반적으로)은 규칙의 실행 스케줄에 따라 다르다.

기업이 사용하는 대부분의 규칙 엔진은 전진 체인으로, 더 나아가 다음 두 가지 등급으로 나눌 수 있다.

  • 제1종류는 소위 생산/추론 규칙을 처리한다. 이러한 유형의 규칙은 IF 조건 DEN 조치 유형의 동작을 나타내기 위해 사용된다. 예를 들어, 그러한 규칙은 "양식의 규칙을 실행함으로써 "이 고객은 담보 대출을 허용해야 하는가?"라는 질문에 대답할 수 있다.만약 어떤 조건이 있다면, 고객에게 돈을 빌려주도록 하라.
  • 다른 유형의 규칙 엔진은 소위 대응/이벤트 조건 작업 규칙을 처리한다. 반응형 규칙 엔진은 들어오는 이벤트를 감지하고 반응하며 이벤트 패턴을 처리한다. 예를 들어, 반응형 규칙 엔진을 사용하여 특정 품목의 재고가 없을 때 관리자에게 경고할 수 있다.

이러한 유형의 가장 큰 차이점은 생산 규칙 엔진은 사용자나 애플리케이션이 보통 상태 비저장 방식으로 이를 호출할 때 실행된다는 점이다. 반응형 규칙 엔진은 이벤트가 발생할 때 자동으로 반응하며, 보통 상태 저장 방식으로 반응한다. 많은 (실제로 대부분의) 인기 있는 상업용 규칙 엔진은 생산과 반응 규칙의 기능을 모두 갖추고 있지만, 다른 클래스보다 한 클래스를 더 강조할 수도 있다. 예를 들어, 대부분의 비즈니스 규칙 엔진은 주로 생산 규칙 엔진인 반면, 복잡한 이벤트 처리 규칙 엔진은 대응 규칙을 강조한다.

또한 일부 규칙 엔진은 역방향 체인을 지원한다. 이 경우 규칙 엔진은 특정 목표에 맞게 사실을 해결하려고 한다. 현존하는 정보를 바탕으로 어떤 것이 존재하는지 판단하려고 하기 때문에 흔히 목표를 지향한다고 한다.

또 다른 종류의 규칙 엔진은 추리 실행 중에 자동으로 여러 번 뒤로 체인과 앞으로 체인을 전환하는데, 예를 들어, 웹을 검색하면 찾을 수 있는 인터넷 비즈니스 로직 시스템이다.

네 번째 등급의 규칙 엔진은 결정론적 엔진이라고 불릴 수 있다. 이러한 규칙 엔진은 전방 체인과 후방 체인을 둘 다 포기할 수 있으며, 대신 정책을 더 잘 설명하기 위해 도메인별 언어 접근법을 활용한다. 이 접근방식은 종종 구현과 유지보수가 용이하며, 전진 또는 후진 체인 시스템에 비해 성능상의 이점을 제공한다.

퍼지 로직 기반 추론이 부울 규칙보다 규칙 처리에 사용되는 경우, 퍼지 로직 기반 추론이 부울 규칙보다 규칙 처리에 사용된다. 예를 들어 고객 분류, 누락된 데이터 추론, 고객 가치 계산 등이 포함될 수 있다. DARL 언어와[3] 관련 추론 엔진 및 편집자는 이 접근법의 한 예다.

액세스 제어/승인 규칙 엔진

규칙 엔진의 일반적인 사용 사례는 애플리케이션에 대한 표준화된 접근 제어다. OASIS는 XACML(eXtensible Access Control Markup Language)이라는 액세스 제어 전용의 규칙 엔진 아키텍처와 표준을 정의한다. XACML 규칙 엔진과 비즈니스 규칙 엔진의 한 가지 중요한 차이점은 XACML 규칙 엔진이 상태 비저장 상태여서 데이터의 상태를 변경할 수 없다는 사실이다. 정책 결정 지점(Policy Decision Point, PDP)이라고 불리는 XACML 규칙 엔진은 "앨리스가 문서 D를 볼 수 있는가?"와 같은 2진수 예/아니오 질문을 예상하고 결정을 반환한다. 허용/거부.

참고 항목

참조

  1. ^ "Do you know where all of your company's business rules are?". Computerworld. IDG Enterprise (published 2005-05-23). 39 (21): 25. 23 May 2005. ISSN 0010-4841. Retrieved 2014-02-02. Rules engines have been around since the early 1990s when companies such as Pegasystems Inc. in Cambridge, Mass., Fair Isaac Corp. in Minneapolis and ILOG in Mountain View, Calif., sold them. They were typically used in rules-heavy industries such as finance and insurance. Over the past few years, however, many vendors have entered the market, and more companies are looking at rules engines as a way to gain greater flexibility in business operations.
  2. ^ 귀사의 규칙 엔진은 이벤트 중심인가? http://www.sapiens-tech.com/iDuneDownload.dll?GetFile?AppId=225&FileID=216581&Anchor=&ext=.pdf Wayback Machine에 보관된 2018-09-30에서 검색.
  3. ^ https://darl.ai/home/darl

참고 문헌 목록

외부 링크