 |
|
난이도 : 초급 Mark Linehan, Senior Technical Staff Member, IBM
2005 년 11 월 29 일 비즈니스 규칙이 컴포넌트 유형으로서 IBM 서비스 지향 아키텍처와 통합되어 비즈니스 기민성을 높이고, 다른 컴포넌트 유형의 기능을 보완하는 실행 모델을 어떻게 대체하는지를 이 글을 통해 설명한다. 세 가지 일반적인 규칙인 순차 규칙, 이벤트 상관관계 규칙, 추론 규칙도 배운다.
머리말
SOA는 다양한 컴포넌트 구현 유형을 적용한다. 평이한 자바 객체(POJO), Business Process Execution Language(BPEL) 프로세스, 비즈니스 상태 머신 등이 있다. 본 시리즈의 Part 1에서는 SOA 개념을 소개했고, Part 6에서는 컴포넌트를 SOA의 핵심 요소로서 소개했다.
개발자들은 다양한 소프트웨어 기술이나 컴포넌트 유형을 사용하여 서비스 컴포넌트를 구현한다. 몇몇 서비스들은 비즈니스 규칙 컴포넌트 유형을 사용함으로서 혜택을 누리기도 한다. 규칙이 유용한 솔루션 기능을 제공하기 때문이다. 이 글에서는 다양한 비즈니스 규칙의 목록들을 요약하고 IBM SOA와 다양한 규칙들을 통합하는 방식을 설명한다.
규칙을 포함하여 모든 컴포넌트 유형들은 하나의 솔루션 합성 모델인 SOA와 맞는다. SOA의 큰 장점 중 하나는 비즈니스 통합자들은 한 개의 컴포넌트 구현을 다른 구현으로 대체할 수 있다는 점이다. 나머지 비즈니스 솔루션에는 어떤 영향도 미치지 않고 말이다. 이 글의 두 번째 목적은 비즈니스 규칙이 SOA에 따라 구현될 때 이 비즈니스 규칙이 그 효용성을 어떻게 달성하는지를 보는 것이다.
SOA에서 서비스들은 요청 메시지들만 가지고, 또는 요청 메시지와 응답 메시지를 가지고 동기식 또는 비동기식으로 서로 인터랙팅한다. 이 글에서는 다양한 규칙 목록들이 다양한 서비스 인터랙션 스타일과 어떻게 작동하는지를 설명한다.
비즈니스 규칙
비즈니스 규칙은 세 가지 일반적인 카테고리로 나뉘어진다.
- 순차적 규칙은 순차적으로 실행되는 선언적 규칙을 제공한다. 이 규칙은 비 전문 프로그래머들도 규칙을 관리할 수 있기 때문에 비즈니스 기민성에 기여한다.
이 카테고리에는 if-then문과 결정 테이블이 포함된다.
그림 1. If-then 규칙
이름에서 함축하듯, 각 if-then 규칙은 then 구문에서 정의된 한 개 또는 다중 액션들을 실행할지의 여부를 결정하는 부울 식으로 구성된다. 이 액션들은 규칙 결과를 계산하거나 값을 할당하거나 다른 서비스들을 호출한다. 그림 1에서 if-then 규칙은 1 파운드에서 5파운드 패키지와 9 입방 피트(cubic feet) 미만의 패키지에 대한 비용을 5 달러로 할당한다.
그림 2. 결정 테이블
결정 테이블에서는 여러 가지 조건들을 한 눈에 볼 수 있다. 그림 2는 다양한 패키지 무게와 부피의 결합별 선적 및 처리비용을 할당하는 결정 테이블이다. 선적과 처리 비용은 9 보다 큰 볼륨을 가진 모든 패키지와 5 이상의 무게를 가진 패키지에 대해서는 7 달러이다. 9 보다 작은 볼륨의 패키지 비용은 2 달러이다. 무게가 1 보다 적을 때에는 2 달러가 부과되고, 무게가 5 미만일 때는 5 달러가 부과된다.
순차적 규칙의 가장 기본적인 장점은 비즈니스 분석가나 비 전문 프로그래머들도 이 규칙을 관리할 수 있다는 점이다. 규칙 관리를 간소화하는 툴도 이러한 순차 규칙을 보완한다.
또 하나의 장점은 SOA에서 개별 서비스 컴포넌트로서 규칙을 구현할 때 그 빛을 발한다. 규칙과 다른 서비스들이 분리되기 때문에 서비스들에 영향을 미치지 않고 규칙들이 업데이트 될 수 있다. 대부분의 규칙 구현들은 동적 업데이트가 가능하기 때문에, 다른 컴포넌트 유형에 필요한 개발과 전개 사이클을 생략할 수 있다. 이러한 장점들 덕택에 비즈니스 규칙 구현이 놀랍게 빨라지고 IT 제약조건에 영향을 덜 받으면서 진화될 수 있는 것이다.
IBM WebSphere® Process Server와 IBM WebSphere Integration Developer는 if-then 규칙과 결정 테이블을 지원하여 사용자들이 SOA에서 이를 활용할 수 있도록 하고 있다.
- 이벤트 상관관계 규칙은 시간이 흐르면서 발생하는 여러 이벤트들간 관계를 인식한다. 이 규칙은 일정 시간적 틀 내에서 일반적으로 메시지들을 유형과 조건 별로 필터링 한 다음 사전에 정의된 다양한 패턴들에 따라 상황을 탐지한다. 이벤트 상관관계 규칙들은 IT나 비즈니스 이벤트 상황을 메시지나 이벤트의 순서를 기반으로 인식하는데 사용된다. 예,
produce an alert if "check customer rating" service generates more than 10 SOAP faults within 1 minute.
IBM Tivoli® Enterprise Console은 이벤트 상관관계 규칙을 사용하여, 주어진 시간 동안 여러 소스들로부터 발생된 이벤트의 패턴들을 인식한다. 이 규칙을 사용하면 IT나 비즈니스 모니터링에서 문제가 되는 상황을 쉽게 규명할 수 있고 매우 간단한 규칙 문장을 직접 프로그래밍 하는 수고를 줄여준다.
- 추론은 정방향 추론(forward inferencing), 역방향 추론(backward chaining), Prolog-style 통합, 기타 인공지능(AI)-스타일 규칙 등을 구현한다. 상호 의존적인 많은 규칙들의 실행 순서가 사전에 결정된 것이 아닌 데이터에 의존해야 하는 경우에 매우 유용하게 쓰인다. 리소스 선택, 최적화, 문제 진단, 플래닝 문제들은 종종 추론이 필요하다.
 |
|
규칙 세트
대부분의 규칙 시스템 그룹은 툴에서 정의되거나 런타임 시 동적으로 구성된 규칙 세트에서 관리된다. 규칙 세트에는 규칙들의 리스트가 포함된다. 몇 가지 인풋을 공동으로 평가하고 한 개 이상의 결과를 만들어 낸다. 결정 트리는 순차적 if-then 규칙세트의 대안 표현을 제공한다.
그림 3. 규칙 세트
그림 3은 두 개의 if-then 규칙이 있는 규칙 세트 모습이다. 인터페이스 섹션은 규칙 세트의 인풋과 아웃풋을 문서화한다. 첫 번째 규칙은 1파운드 미만의 패키지와 9 입방피트 미만의 패키지에 2 달러를 부과한다. 두 번째 규칙은 1에서 5 파운드의 패키지와 볼륨이 9 미만인 패키지에 5 달러를 부과한다.
각 규칙 세트는 하나의 인터페이스의 작동을 구현하면서(연산 또는 메소드 이름별) 연산의 목적과 서명(매개변수와 결과)을 실현한다. 따라서 각 규칙 세트는 SOA에서의 개별적인 연산 역할을 수행한다.
다음은 이러한 접근 방식의 다양한 이점들이다.
- 클라이언트 서비스는 서비스가 구현되는 방법에 대해 모른다. 규칙이나 구현 기술에 대해 모른다는 의미이다. 또한 어떤 규칙 목록이 사용되고 언제 선택되는지에 대해서도 모른다. 따라서 클라이언트는 대안 서비스 컴포넌트로 연결될 수 있다.
- 서비스 컨트랙트를 통해 안정성을 보장 받을 수 있다.
- 단순한 프로그래밍 모델-규칙을 호출 할 때 특별한 API가 없다.
- 프로세스 구성 엔진은 다른 서비스들 처럼 규칙들을 호출할 수 있다. 엔진은 특정 연산들이 규칙들을 사용하여 구현되는지에 대해 알 필요가 없다.
- 접근 제어와 트랜잭션 관리 같은 기존 컨테이너 기능들의 재사용. 솔루션 디자인의 경우,
getDiscount 연산이 나머지 클라이언트 애플리케이션과 같은 데이터베이스 트랜잭션에 참여하는 것이 중요하다. 다른 서비스들과 비슷하게 규칙을 호출하면 규칙들에 컨테이너 기능들을 적용할 수 있다.
비즈니스 규칙 그룹
그림 4. 규칙 세트(들)과 규칙들로 구성된 비즈니스 규칙 그룹
그림 4에 묘사되어 있는 것처럼 서비스들은 여러 연산들을 제공하는 반면, 규칙 세트는 하나의 연산만 수행한다. 비즈니스 규칙 그룹은 서비스의 모든 연산들을 합동으로 구현하는 다중의 규칙 세트들을 패키징한다. 서비스 연결이라는 관점에서, 비즈니스 규칙 그룹은 애플리케이션으로 “연결된” 컴포넌트이다. 따라서 비즈니스 규칙 그룹은 여러 규칙 세트들을 서비스로 묶어서 다른 서비스들이 참조할 수 있도록 인터페이스로 반출한다.
예를 들어, 비즈니스 규칙 그룹은 calculate discount와 calculate shipping 연산들과 이에 대한 규칙세트가 포함되어있는 Customer Relationship Management(CRM) 인터페이스를 구현한다. 서비스 클라이언트가 그림 5의 규칙 세트를 사용하는 비즈니스 규칙 그룹으로 연결되어 있다면, 클라이언트가 calculate shipping 연산을 호출할 때 규칙이 실행된다.
그림 5. 비즈니스 규칙 그룹 쉘은 SOA 서비스와 규칙 엔진을 연결한다.
각 비즈니스 규칙 그룹은 제공된 인터페이스에서 정의된 연산 서명을 통해 보안성을 확보한다. 일반적으로 툴은 비즈니스 규칙 그룹을 쉘 코드로서 생성한다. 쉘 코드는 연산 서명을 구현하고, 인커밍 매개변수를 포착하고, 이들을 규칙 엔진으로 전달한다. 쉘 코드는 애플리케이션 스팩의 연산 서명과 많은 규칙 엔진의 애플리케이션 독립의 인터페이스들 간 미스매치를 해결한다. 그림 5는 쉘 코드가 클라이언트와 규칙 엔진을 연결하는 모습이다. 클라이언트는 서비스로서 규칙을 호출할 수 있고 규칙 엔진은 SOA에 참여할 수 있다.
규칙에서 다른 서비스 호출하기
비즈니스 규칙은 테스트 조건들의 일부로서("'if moon.getStatus() == "Full" …') 다른 서비스들을 호출하거나, 이메일 보내기 같이 액션을 호출하는데 사용된다. 우리는 이것을 두 부분으로 모델링 한다.
- 각 비즈니스 규칙 그룹은 SOA에 따라 서비스 레퍼런스를 정의한다. 이 서비스 레퍼런스는 필요한 서비스 스팩을 지정한다.
- 그림 4에서, 규칙들은 규칙 세트에 속해있다. 이 규칙 세트는 규칙 그룹에 속해있다. 규칙은 간접적으로 규칙을 소유하고 있는 비즈니스 규칙 그룹으로부터 참조되는 서비스를 호출 할 것이다.
이러한 방식을 사용하는 개발 환경에서는 규칙 그룹들과 다른 서비스들간 관계가 실제 규칙세트와 규칙 보다 먼저 정의된다. 구현 또는 전개 시 애플리케이션은 정의 및 연결되는 반면, 규칙들은 실행 시스템에서 관리된다.
예를 들어, 어떤 비즈니스 규칙 그룹이 서비스 A, B, C를 참조한다고 하자. 어떤 시점에서 규칙 그룹 내에 있는 규칙들은 실제로 서비스 A를 호출하고 또 다른 시점에 서비스 B를 호출할 수 있다. 이 규칙은 서비스 Z는 호출할 수 없다. 이 서비스는 비즈니스 규칙 그룹에서 참조될 수 없기 때문이다.
호출 스타일
서비스들은 두 가지 주요한 방식으로 인터랙팅 한다. 이 두 방식 모두 규칙들에도 적용된다.
- 요청-응답 스타일 -- 클라이언트 서비스에 의한 동기식 호출. 클라이언트는 동기식 결과를 만들어 내는 서비스를 호출한다.
- 이벤트 핸들링 스타일 -- IBM WebSphere Enterprise Service Bus의 비동기식 메시지 프로세싱. 클라이언트는 "fire-and-forget" 방식으로 서비스에 메시지를 보낸다. 서비스는 또 다른 비동기식 메시지를 통해 클라이언트로 응답을 전달한다.
요청-응답 스타일을 먼저 설명하겠다. 이벤트 핸들링 스타일은 요청-응답 스타일을 기반으로 하기 때문이다.
요청-응답 스타일
요청-응답 호출 스타일에서, 클라이언트 서비스는 규칙으로 구현된 연산을 호출한다. 여기에서의 규칙은 클라이언트에서 전달된 인자, 규칙에 접근할 수 있는 정적 데이터 또는 서비스, 규칙 내에서 관리되는 상태 등이다. 여느 연산과 마찬가지로 규칙들은 연산을 수행하고 결과를 클라이언트에 보낸다. 규칙은 또한 다른 서비스들을 호출하여 몇 가지 액션 또는 기타 부작용 등을 발생시킨다.
SOA에서 모든 연산 신호는 전적으로 용도에 의존한다. 인풋, 결과, 디스카운트를 계산하는 연산의 이름은 운전자의 보험을 확인하는 연산과는 전적으로 다르기 때문이다. 각 애플리케이션의 디자이너는 규칙으로 전달된 인풋을 지정하고 규칙에서 기대되는 결과를 지정한다. 규칙을 호출하는데 사용되는 특별한 API는 없다.
이벤트 핸들링 스타일
이벤트 핸들링 스타일에서 규칙 세트는 메시지 흐름을 비동기식으로 처리한다.(그림 6) 규칙 세트는 각 메시지를 하나씩 검사하고 (또 다른 서비스를 호출하여) 액션을 취하거나 아웃바운드 메시지를 생성한다. 전형적인 애플리케이션에는 비즈니스 상황에 반응하고, 예외적 조건에 대한 비즈니스 이벤트를 검사하고, 문제에 대한 IT 이벤트를 모니터링 한다. 규칙 기술은 사용자가 별다른 프로그래밍 없이도 메시지 프로세싱을 쉽게 정의할 수 있기 때문에 애플리케이션을 단순화 시킨다.
그림 6. 비즈니스 규칙과 이벤트 핸들링 스타일
이벤트 핸들링 스타일은 앞서 언급했듯이 요청-응답 스타일을 기반으로 한다. 비즈니스 규칙 그룹은 각 인커밍 메시지를 받고 규칙 세트를 호출한다. 일반적으로 규칙 세트는 인자로서 인커밍 메시지를 받고 어떤 결과도 리턴하지 않는다. (비동기식 프로세싱 환경이기 때문이다.) 결과 세트는 또 다른 서비스를 호출하여 아웃풋을 만들어 낸다. 이는 다른 메시지 소스들과 연관 될 수도 있고 아닐 수도 있다. 따라서 규칙 기술의 관점에서 볼 때, 이벤트 핸들링과 요청-응답 스타일의 차이점은 환경에 기인한다고 볼 수 있다. 이 두 가지 스타일의 규칙 실행 모델은 다르지 않다. 유일한 차이라면 규칙 세트를 실행하는 데 사용되는 인터페이스 서명과 규칙 세트와 클라이언트 애플리케이션들간 인터랙션을 들 수 있다.
STATELESS 대 STATEFUL 규칙
여타의 서비스 구현 유형과 마찬가지로 비즈니스 규칙도 STATELESS 또는 STATEFUL로 나뉘어 진다. 다시 말해서, 여러 호출들을 통해 내부 데이터 기록들을 관리한다는 의미가 된다. 규칙들은 상태를 유지하여 호출의 역사에 걸친 정황을 확장하면서 현재 호출에 전달된 인자 이상을 고려하는 결정이나 전산을 실행한다. STATEFUL 규칙의 예제에는 대부분의 이벤트 상관관계 규칙과 추론 규칙이 포함된다.
비즈니스 규칙 내에서 관리되는 상태 데이터와 클라이언트 서비스간 관계는 애플리케이션 레벨의 문제이다. 아키텍처의 문제가 아니다. 일반적으로 규칙들은 한 개 이상의 호출 인자를 사용하여 내부 상태에 접근한다.
규칙 내에서 관리되는 모든 상태는 일관성 있게 유지되어서 클러스터링 구성과 고 가용성 요구 사항들을 지원해야 한다. 규칙의 유연성과 확장성, 탄력성 유지하는 것이 큰 문제이다.
전형적인 사용 패턴들
지금까지는 두 개의 기본적인 호출 스타일(동기식 요청-응답 스타일과 비동기식 이벤트 핸들링 스타일)을 간략하게 설명했고 STATELESS 프로세싱 대 STATEFUL 프로세싱을 구별했다. 규칙 유형들은 STATEFUL 호출 스타일과 STATELESS 호출 스타일을 결합하여 네 가지로 유형화 된다. 다음 표는 네 가지 전형적인 사용 패턴들이다.
표 1. 비즈니스 규칙의 전형적인 사용 패턴들
| 요청-응답 스타일 | 이벤트 핸들링 스타일 |
|---|
| Stateless | 순차적 규칙 또는 추론 규칙 | 이벤트 상관관계 규칙 (단순 패턴) | | Stateful | 추론 규칙 | 이벤트 상관관계 규칙 (복합 패턴) |
이 테이블은 각 규칙 유형의 기능에 따른 가장 합리적인 결합 유형을 보여주고 있다. 다른 유형도 가능하다. 예를 들어, 순차 규칙이나 추론 규칙을 STATELESS 이벤트 핸들링으로 대체하면 가장 단순한 이벤트 상관관계 규칙 유형과 같아지지만 이 규칙을 진정한 멀티 이벤트 상관관계로 확장 시킬 수 없게 된다. 또 다른 예제로서 STATEFUL 이벤트 핸들링에 추론 규칙을 적용하여 메시지 순서를 추론할 수 있다. 애플리케이션 요구 사항들과 툴 기능은 각 상황에서 최고의 선택을 결정한다.
요약
이 글에서 세 가지 일반적인 규칙 범주를 요약하고 이들이 SOA와 어떻게 통합될 수 있는지 설명했다. 단 다음의 내용은 배제시켰다.
- 규칙이 STATELESS 인지 STATEFUL 인지의 여부.
- 호출 스타일이 동기식 요청 응답인지 비동기식 메시지 기반인지의 여부.
이 글에서 설명한 통합 방식은 규칙을 일급 서비스 컴포넌트 유형으로서 취급한다. 평이한 자바 코드, 비즈니스 프로세스, 상태 머신 같은 기술들에 이를 포함시킨 것이다. 서비스 클라이언트 개발자는 규칙을 다른 서비스들 처럼 호출할 수 있다. 특별한 API를 고려하지 않아도 된다. 전체 솔루션 개발자는 규칙들과 다른 구현 유형들 혼합하여 전체 솔루션에서 각 컴포넌트에 가장 적합한 기술을 사용할 수 있다.
참고자료 교육
토론
필자소개 | 
| | Mark Linehan, Senior Technical Staff Member, IBM |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
