 | |
|
난이도 : 초급 Dr. Beth Hutchison, Senior Technical Staff Member, IBM
Marc-Thomas Schmidt, ESB Chief Architect, IBM
Dan Wolfson, CTO, Business Integration, IBM
Marcia Stockton, Senior Technical Staff Member, IBM
2005 년 7 월 26 일 엔터프라이즈 서비스 버스(ESB) 아키텍처 패턴은 서비스 지향 아키텍쳐에서의 서비스 인터랙션의 가상화와
관리를 지원한다. 서비스 공급자와 요청자들 간 인터랙션을 가능케 하고, 다양한 미들웨어 기술과 프로그래밍 모델을 사용하여
구현될 수 있다. 이 글에서는 이전 글에서 소개한 SOA 프로그래밍 모델 개념을 조금 더 확대시킨다.
머리말
SOA는 기존 애플리케이션을 확장 및 재사용 하거나, 새로운 애플리케이션을 구현하는데 있어 유연하고 확장성 있으며
구성력이 뛰어난 방식을 제공한다. 서비스는 스스로 구현한 인터페이스나 다른 서비스가 구현할 것으로 예상되는 인터페이스를
선언하고, 중요한 파트너 인터랙션을 총괄하는 정책들을 선언하여 그 기능들을 광고한다.
Web Services Description Language(WSDL)와 기타 웹 서비스 표준(WS-Policy)들은 이러한 선언을 위한 어휘를 제공한다.(참고자료)
SOA의 핵심 목표인 비즈니스 함수의 가상화는 서비스 정의와 사용을 서비스 구현으로부터 분리시킴으로서 실현된다.
서비스는 IBM WebSphere® MQ, IBM CICS®, IBM IMS™, Java™ 2 Platform,
Enterprise Edition(J2EE) Enterprise JavaBeans(EJB), Java classes, IBM DB2® Queries,
Java Message Services(JMS), Microsoft® .NET 등 다양한 기술들을 사용하여 구현된다.
서비스 요청자들은 서비스 공급자에게 요청을 보낸다. 서비스 공급자는 요청자가 원하는 기능을 제공하지만 그 구현에 대해서는
모르고 있다.
ESB는 참여자들 사이에서 발생하는 서비스 인터랙션의 관리와 가상화를 지원하는 아키텍쳐 패턴이다.
서비스 공급자와 요청자들 사이를 연결하고, 정확히 매치되지 않더라도 인터랙션을 가능케 한다.
이 패턴은 다양한 미들웨어 기술과 프로그래밍 모델을 사용하여 구현될 수 있다.
이 글에서는 ESB 패턴과 SOA 내에서의 이 패턴의 역할을 설명하고자 한다. 후속 기술자료에서는 사용 시나리오를 상세히 설명하고
요즘 사용되는 기술을 통해 ESB 패턴을 구현할 것이다.
ESB란 무엇인가?
ESB 패턴에서는 직접 인터랙팅 하기 보다는 SOA의 핵심 정의를 구현 및 확장하는 기능들의 가상화와 관리를
제공하는 버스를 통해 서비스 인터랙션에 참여한 사람들이 통신할 수 있다. IBM ESB 패턴은 다음과 같은 가상화를 제공한다.
- 위치와 정체성: 참여자들은 다른 참여자들의 위치와 정체성을 알 필요가 없다.
예를 들어, 요청자들은 자신들이 요청한 것이 어떤 서비스 공급자에 의해 제공되는지 알 필요가 없다.
서비스 공급자는 자유롭게 추가 및 제거될 수 있다.
- 인터랙션 프로토콜: 참여자들은 공통의 통신 프로토콜이나 인터랙션 스타일을 공유할 필요가 없다.
SOAP/HTTP를 통한 요청은 공급자가 Java Remote Method Invocation (RMI)만 이해해도 서비스를 제공할 수 있다.
- 인터페이스: 요청자와 공급자는 공통 인터페이스에 동의할 필요가 없다.
ESB는 요청 메시지를 공급자가 기대하는 형태로 변형하여 그러한 차이점들을 조정한다.
- (인터랙션) 서비스의 품질(QoS): 참여자들은 자신들의 QoS 요구사항 뿐만 아니라 퍼포먼스와 신뢰성,
요청 권한, 메시지 컨텐츠의 암호화/암호해독, 서비스 인터랙션의 자동 감시, 요청이 라우팅 되는 방식
(워크로드 분배 기준에 근거한 구현) 등을 선언한다. QoS 요구사항과 요청자와 공급자의 기능을 기술해 놓은 정책들은
서비스 자체로 수행되거나 미스매치를 보상하는 ESB에 의해 수행된다.
ESB 패턴은 요청자가 서비스 공급자의 물리적 구현에 대해 알 수 없도록 한다. 애플리케이션 개발자와 전개자의 관점에서 이 버스는
요청을 서비스 공급자에게 전달하는 책임이 있다. 공급자는 메시지의 기원을 알지 못한 채로 요청을 받게 된다.
ESB를 사용하는 서비스 요청자와 공급자는 ESB를 볼 수 없다. 애플리케이션 로직은 다양한 프로그래밍 모델과 기술을 사용하여
서비스를 호출 또는 제공할 수 있다. 직접 연결인지 아니면 ESB를 트래버스 하는지에 대해 알 필요가 없다.
ESB로의 연결은 전개 단계에서 결정된다. 애플리케이션 소스는 영향을 받지 않는다.
ESB는 일방향(one-way), 요청/응답, 비동기식, 동기식, 퍼블리시/등록(publish/subscribe) 등 많은 인터랙션 유형을 지원한다.
또한 복잡한 이벤트 프로세싱도 지원한다.
그림 1은 기본적인 ESB 패턴이다. 메시지들은 다양한 통신 참여자들은 서로 연결해주는 버스를 통해 흐른다.
어떤 참여자들은 다른 참여자가 제공하는 서비스를 호출한다. 또 어떤 참여자들은 정보를 관련 소비자들에게 공개한다.
엔드포인트가 ESB와 인터랙팅하는 사이트를 서비스 인터랙션 포인트(SIP)라고 한다. SIP는 웹 서비스 엔드포인트,
WebSphere MQ 큐, RMI 원격 객체용 프록시가 될 수 있다. 서비스 레지스트리는 SIP의 요구 사항과 기능(예를 들어, 제공되거나 요청된 인터페이스),
다른 SIP와 인터랙팅을 하는 방법(동기식, 비동기식, HTTP, JMS), QoS 요구사항(보안, 신뢰성, 인터랙션),
기타 SIP 정보 등을 설명하는 메타데이터를 파악한다.
그림 1. 기본적인 ESB 패턴
참여자들 사이에 버스를 개입시키면 중재(mediation)이라고 하는 논리적 구조체를 통해 인터랙션을 모듈화 할 수 있다.
중재는 요청자와 공급자간 메시지들을 연산한다. 복잡한 인터랙션의 경우 중재는 순차적으로 발생한다.
중재 패턴 섹션에서 가상화, QoS, 관리 개념을 구현하는 일반적인 중재 패턴을 설명하겠다.
ESB 패턴은 SOA에 유연하고 관리하기 편한 방식을 제공한다. 엔드포인트 간 투명하게 개입된 버스는 서비스의 품질을 높인다.
미스매치(mismatch) 프로토콜, 인터랙션 패턴, 서비스 기능에 관계 없이 요청자-공급자 인터랙션을 원활하게 수행할 수 있도록 한다.
또한 모니터링과 관리 기능도 수행한다.
SOA 사용자 역할과 태스크
SOA 솔루션을 구현하고 관리하는 사용자의 역할과 임무를 연구하면 ESB 패턴이 더 잘 이해될 것이다.
ESB 툴과 런타임은 SOA의 솔루션 수명 주기를 네 단계로 구분한다.
- 발견과 설명: ESB를 통해 서로 연결될 수 있는 SIP를 규명하고 설명한다. 여기에는 새로운 서비스의 생성,
기존 서비스의 발견, 인터페이스 설명, 요구사항과 기능 등이 포함된다.
- 모델링과 구현: 새로운 중재 또는 기존 중재를 통해 SIP를 연결하여 솔루션의 엔드투엔드 인터랙션을 설명한다.
- 설정과 전개: 특정 런타임 토폴로지에 대한 솔루션의 추상적 선언을 설정하고 이를 전개하여
필요한 런타임 객체들을 구현한다.
- 모니터링 및 관리: SIP와 중재 작동을 통해 솔루션을 감시 및 관리한다. 이 단계에서는 기구를 사용하고
ESB 런타임의 포인트들을 관리한다. 또한 메시지의 흐름을 관찰하고 영향을 미치는 중재 또한 관리한다.
ESB 미들웨어의 경우, 가장 중요한 SOA 솔루션 개발 역할은 통합 개발자와 솔루션 관리자이지만 비즈니스 분석가,
솔루션 아키텍트, 구현자, 어댑터 개발자, 운영자 등도 개입되어 있다. (이 역할들은 개념상의 역할일 뿐이다.
한 사람이 여러 역할들을 수행할 수 있다.) 그림 2는 이러한 역할들이 인터랙팅 하는 모습이다.
비즈니스 분석가는 비즈니스 요구 사항들을 파악하고 비즈니스 프로세스를 관찰한다. 이들은 솔루션의 목표,
개입된 비즈니스 프로세스, 솔루션의 현황을 감시하는 지표, IT 시스템이 제공해야 하는 비즈니스 서비스 유형 등을 정의한다.
솔루션 아키텍트는 기존 IT 자산들을 재사용, 변경, 결합하면 어떤 비즈니스 요구 사항들이 충족되는지,
그리고 어떤 새로운 IT 자산을 구현하고 구매해야 하는지를 결정한다. 이들은 메시지 컨텐츠 교환 같은 IT 자산들 간 인터랙션을 정의한다.
개발 작업은 세 가지 역할로 나뉜다. 구현자는 서비스 인터페이스를 통해 호출되는 새로운 애플리케이션 코드를 작성한다.
어댑터 개발자는 기존 애플리케이션이나 새롭게 구매한 애플리케이션과 패키지들을 래핑하여 다른 서비스들도
접근 할 수 있는 서비스들을 구현한다. 통합 개발자는 ESB 관련 툴과 기술을 통해 서비스들 사이에 요청들이 라우팅되는 방식을 관리한다.
그림 2. 사용자 역할
솔루션 관리자는 새로운 IT 자산을 전개하고 서비스 정의를 서비스 레지스트리로 반입시켜서 새로운 IT 자산들을 사용할 수 있도록
만든다. 솔루션이 제 위치를 찾으면 운영자는 이것의 실행을 감시하고 필요에 따라 IT 시스템을 시작 및 중지 시키고
솔루션 구성을 조정하는 솔루션 관리자들에게 권고한다.
ESB 패턴
통합 개발자와 솔루션 관리자들은 일정 패턴을 사용하여 SOA 솔루션을 설계하고 전개한다.
그림 3. 기본적인 ESB 패턴의 요소들
기본적인 ESB 패턴은 애플리케이션 컴포넌트들을 직접적인 점대점 통신이 아닌 버스를 통해 인터랙팅하는 서비스들로
분리한다. 서비스는 공급자가 될 수도 있고 요청자가 될 수도 있고 두 개 다 될 수 있다.
어떤 SOA 구현도 기본적인 가상화는 가능하며 종속되어 있는 요청자들에게 영향을 주지 않고
동등한 공급자 구현으로 대체할 수 있다. ESB 패턴은 요청자-공급자 인터랙션의 관리를 통해 기본적인 SOA 기능을 향상시킨다.
공급자는 요청자가 원하는 기능이 비슷하다면 또 다른 공급자로 대체될 수 있다. 이때 ESB가 중재한다.
ESB는 서비스가 버스에 메시지를 두거나 메시지를 없애는 곳에 인터랙션 포인트를 제공한다.
메시지에 중재를 적용하고 그렇게 관리되는 인터랙션에 QoS를 보장한다.
ESB의 관점에서 볼 때, 요청/이벤트를 보내거나 요청/이벤트를 처리한다는 점에서
모든 서비스 인터랙션 엔드포인트들은 비슷해 보인다. 여기에는 특정 QoS가 필요하다.
그리고 인터랙션 장치도 필요하다. ESB 패턴에서는 통합 개발자가 새로운 비즈니스 로직, 프로세스 구성 컴포넌트,
외부 웹 서비스와 같은 (서비스 중심적인) 방식으로 사람들과 인터랙팅하는 요청자나 공급자를 다룬다.
ESB 기반 솔루션을 구현하는 패턴은 다음과 같다.
- 인터랙션 패턴: 서비스 인터랙션 포인트들이 버스를 통해 메시지를 전달/수신할 수 있도록 한다.
- 중재 패턴: 메시지 교환을 조작한다.
- 개발 패턴: 연합 인프라로 솔루션을 전개한다.
인터랙션 패턴
ESB는 버스를 통해 인터랙션 모드에서 엔드포인트들이 인터랙팅 할 수 있도록 한다.
다양한 엔드포인트 프로토콜과 인터랙션 방식을 지원한다. 다음은 인터랙션 패턴의 예제이다.
- 요청/응답: 엔드포인트들간 요청/응답 방식의 인터랙션을 관리한다.
ESB는 메시징 모델 기반이기 때문에 요청/응답 인터랙션은 두 개의 일방향 메시지 흐름으로 처리된다.
하나는 요청에 쓰이고 다른 하나는 응답에 쓰인다.
- 요청/다중 응답: 위 패턴의 변종이라고 할 수 있다. 한 개 이상의 응답들이 보내질 수 있다.
- 이벤트 전파: 이벤트는 ESB에서 관리되는 관련 당사자들의 리스트로 무작위 배포된다.
서비스는 스스로를 이 리스트에 추가할 수 있다.
그림 4. 인터랙션 패턴
중재 패턴
중재 패턴은 (요청 또는 이벤트)버스상에서 메시지를 조작한다. 요청자가 발송한 메시지들은 잠재적 엔드포인트에서
선택된 호환성이 떨어지는 공급자들도 이해할 수 있는 메시지들로 변형된다.
중재 작동은 요청-응답 보다는 일방향 메시지에 적용된다. ESB가 중재 패턴의 상단에 인터랙션 패턴을
오버레이 하기 때문이다.
그림 5. 중재 패턴
여러 가지 중재 패턴들이 있다. 간단한 패턴들을 결합하면 더 많은 복합 패턴들이 구현될 수도 있다.
- 프로토콜 전환: 서비스 요청자가 SOAP/HTTP, JMS, MQ Integrator(MQI) 같은 다양한 인터랙션 프로토콜이나
API를 사용하여 메시지를 보낼 수 있도록 한다. 요청들을 목표 서비스 공급자 포맷으로 변경한다.
인터랙션의 끝, 양끝, 중간 어디에서나 요청자 또는 공급자에 적용될 수 있다.
- 변형: 요청자의 스키마에서 공급자의 스키마로 메시지 페이로드(컨텐트)를 변환한다.
인벨로프(enveloping), 인벨로프 해제(de-enveloping), 암호화 등이 여기에 속한다.
- 증가: 중재에 의해서나 데이터베이스 쿼리를 통해서 정의된 사용자화 매개변수 같은
외부 데이터 소스들에서 정보를 추가하여 메시지 페이로드를 증가시킨다.
- 라우트: 메시지의 라우트를 변경하여 요청 의도를 지원하는 서비스 공급자들을 선택한다.
선택 기준에는 메시지 컨텐트와 정황, 기능 등이 포함된다.
- 배포: 메시지를 관련 당사자들에게 배포하고 등록자가 관심을 보인 프로파일에 따라 배포된다.
- 모니터: 중재를 통해 전달되는 메시지들을 관찰한다. 서비스 레벨을 감시하는데 되고 문제 결정을 돕는다.
감사나 데이터 마이닝을 위해 메시지들을 기록하는데 사용된다.
- 코릴레이션: 메시지 또는 이벤트 스트림에서 복잡한 이벤트들을 찾아낸다.
이벤트 스트림을 실행하는 컨텐트에서 검색된 복잡한 이벤트를 생성하여, 패턴 규명에 대한 규칙과
패턴 발견에 작용하는 규칙을 포함시킨다.
중재는 솔루션에서 분명하게 설정된다. 예를 들어, 통합 개발자는 메시지 내용을 수정하는 증가 중재를 설정할 수 있다.
솔루션 관리자는 라우트 중재를 설정하여 서비스 공급자를 오프라인으로 변환할 수 있도록 한다.
다른 중재들은 ESB에 적용되어 서비스 요청자와 공급자의 QoS 요구 사항들을 만족시킨다.
예를 들어, 서비스 공급자의 보안 정책 선언에 암호화된 메시지가 필요하면 ESB는 암호화 중재를 자동으로 설정한다.
정책은 서비스의 애트리뷰트일 뿐만 아니라 솔루션 관리자가 인터랙션을 설정할 수도 있다.
예를 들어, 특정 외부 공급자로 가는 모든 메시지들을 기록하거나 트랜잭션을 사용하여 메시지를 기록하려면
100만 달러 이상의 가치가 있다. ESB는 이 경우 모니터 중재를 설정하여 정책을 구현한다.
복합 패턴
그림 6. 복합 패턴
중재와 인터랙션 패턴은 결합되어 보다 복잡한 패턴을 만든다.
예를 들어, 변형에 따른 프로토콜 전환은 표준 어댑터 패턴을 구현한다. 모든 당사자들이 사용하는 메시지와
비즈니스 객체들은 표준 포맷으로 규정된다. 표준 어댑터 패턴은 기존의 엔드포인트의 버스 부착 프로토콜을
표준 프로토콜로 변환시키고, 페이로드를 규정하며, 변형 방향을 바꾼다.
또 다른 일반적인 복합 중재는 변형, 로그, 라우트 패턴이다.
게이트웨이 패턴은 더욱 복잡한 프로토콜 전환 변종이다. 변형과 모니터 중재를 결합시켜 암호화와 로깅
또는 감시를 수행한다. 또한 메시지들을 일대다 관계로 집합 또는 해체한다. 서비스 포탈은 이러한 패턴을 유형화하여
다중 서비스를 위한 하나의 접촉 포인트를 제공하고 내부 서비스의 상세를 숨긴다.
개발 패턴
솔루션 관리자는 ESB 토폴로지에 대해 여러 가지 선택권이 있다. 일반적으로 다음과 같은 것이다.
- 글로벌 ESB: 모든 서비스들은 하나의 네임스페이스를 공유하고,
각 서비스 공급자는 이종의 중앙에서 관리되는 지리적으로 분산된 환경에 있는 모든 서비스 요청자들에게 보여진다.
부서나 작은 기업에서 사용되며, 모든 서비스들은 기업 내에서 적용될 수 있다.
- 직접 연결되는 ESB: 일반적인 서비스 레지스트리에서는
여러 독립적인 ESB에 존재하는 모든 서비스들을 볼 수 있다. 서비스는 비즈니스 라인에서 제공 및 관리되지만
기업 레벨에서는 사용될 수 없다.
- 브로커 ESB: 다른 분야에 있는 파트너들에게 요청자나 공급자를 선택적으로 노출하는 브릿지 서비스는
다중 ESB들간 공유를 관리한다. ESB들간 서비스 인터랙션은 브릿지 서비스를 구현하는 공용 브로커를 통해 관리된다.
서비스를 개발하여 관리하는 부서에서 사용되지만 몇 가지를 공유하거나 엔터프라이즈 레벨에서도 서비스에 선택적으로
액세스 할 수 있다.
- 연합 ESB: 여러 의존적인 ESB들은 하나의 마스터 ESB로 통합된다.
서비스 소비자와 공급자들은 이 마스터에 연결하거나 종속 ESB에 연결하여 네트워크를 통해 서비스에 액세스 한다.
감독 부서의 감시 하에 자치 부서들을 결합하기 원하는 기업에서 사용한다.
그림 7. ESB 개발 패턴
결론
ESB 패턴은 SOA의 가상화 기능을 확대한다. 중재는 기능의 표준 단위에서 구성되고
미스매치된 서비스 요청자와 공급자들간 인터랙션이 가능하도록 전개된다. ESB는 서비스의 전개, 관리, 감독을 위한
일반적인 모델을 제공한다. ESB 개념은 사용자 역할에 따라 영역을 분리하여 부담을 줄이고
아키텍쳐의 소비를 향상시킬 수 있도록 하는 것이다. ESB의 포괄적인 프로그래밍 모델, 컴포넌트로 된 툴,
인프라 지원은 SOA 원리의 실현을 촉진시킨다.
감사의 말
이 글에 도움을 준 Birgit Schmidt-Wesche, John Whitfield, Malcolm Ayres, Mandy Chessell, Peter Lambros,
Rick Robinson, Robert Berry 에게 감사의 말을 전한다.
참고자료 교육
토론
필자소개 | 
| | Dr. Beth Hutchison, Senior Technical Staff Member, IBM |
| 
| | Marc-Thomas Schmidt, ESB Chief Architect, IBM |
| 
| | Dan Wolfson, CTO, Business Integration, IBM |
| 
| | Marcia Stockton, Senior Technical Staff Member, IBM |
기사에 대한 평가
| |
