calmglow (최진호)

앞서 설명한 바와 같이 단순히 미들웨어 관점에서만 보면 ESB의 특징은 EAI hub의 그것과 크게 다르지 않은 점을 발견할 수 있다. 그럼에도 불구하고 ESB가 다루는 영역은 애플리케이션간의 통합이 아니라 서비스간의 연계 영역에 있기 때문에 몇가지 구별되는 특징을 가지고 있다. 아래는 2008년 5월 3일 현재 Wikipedia에서 정의하고 있는 ESB의 특징이다. Wikipedia의 정의가 절대적인 것은 아니지만 ESB처럼 상호간에 다른 정의를 내리는 개념에 있어서는 절대 다수의 동의에 의해 만들어진 정의가 오히려 의미가 있다고 할 수 있겠다.

ESB는 서비스 제공자와 소비자 사이에 다음과 같은 역할을 담당한다.

• Invocation: 동기 및 비동기같은 다양한 전송 프로토콜을 지원한다.
• Routing: 정적인 라우팅 뿐만 아니라 메시지 내용 기반 동적인 라우팅, 룰 기반 라우팅, 정책 기반 라우팅과 같은 다양한 동적인 라우팅 기능을 제공
• Mediation: 서로 다른 프로토콜과 서로 다른 서비스 차이를 매개해주는 중개자 역할을 담당한다.
• Messaging: 메시지 변환이나 메시지 enhancement와 같은 고급수준의 메시지 처리 기능을 제공한다.
• Process choreography: 서비스들을 묶어내어 보다 복잡한 기업 비즈니스 프로세스를 처리할 수 있는 엔진을 제공한다.
• Service orchestration: 서비스들에 대한 조합 및 통합 기능을 제공하여 보다 추상화되고 보다 고급 비즈니스에 맞는 형태로 조율하는 기능을 제공한다.
• Quality of Service: 보안이나 전송 보장 기능 그리고 트랜잭션 관리 기능을 제공한다.
• Management: BAM이나 audit, logging 그리고 과금이나 관리기능등을 제공한다.

위의 기능들은 상당 부분 EAI hub의 기능과 유사한 반면 보다 자세히 살펴보면 EAI hub의 기능보다 보다 동적인 요구사항이 반영되어 있으며 그 외에도 다양한 비즈니스 요구사항을 만족시키기 위한 기능이 더 추가되어 있는 것을 확인할 수 있다. 이를테면 Process choreography 기능은 BPM엔진을 말하고 있는데, ESB를 통해 기업내에 통합된 View형태로 서비스들을 관리할 수 있기 때문에 ESB내에 BPM엔진을 연결시킨다면 얼마든지 전사적인 차원에서의 BPM 환경을 구축할 수 있게 될 것이다. 뿐만 아니라 BAM이나 과금과 같은 영역은 과거 EAI영역에서는 감히 다루지 못했던 상당히 고급 수준의 추상화된 비즈니스 영역의 요구사항이 반영된 결과라고 하겠다.

앞서 살펴본 ESB의 특징은 상당히 일반적인 수준에서의 ESB가 갖고 있어야할 것들이다. 여기서 우리는 ESB가 가져야할 보다 근본적인 특징 하나를 생각해보자.

Loosely coupling

ESB가 기존의 EAI hub에 비하여 갖고 있는 아키텍처적 관점에서의 강조된 특징은 결국 서비스의 ‘동적인 연결 지향’이라고 하겠다. ‘동적인 연결 지향’이란 것은 결국 물리적인 서비스와 논리적인 서비스간의 관계를 최대한 느슨하게 연결지음으로써 그 연결에 변화가 일어났을 경우 변화를 반영하는 데 걸리는 시간과 노력을 최소화하려는 의지라고 볼 수 있다.

그림 13.서비스와 긴밀하게 연결되어 있는 프로세스

그림 13은 만약 결혼 절차 프로세스상의 각각의 Activity가 실제 구현이 되어있는 실체가 있는 서비스와 긴밀하게 연결되어 있는 구조를 나타내고 있다. 1000만원 이상의 비용을 감당할 수 있다면 B예식장으로 선택하고 그 이하의 비용만을 감당할 수 있다면 A예식장으로 선택할 수 있게끔 프로세스가 설계되어있다. 이렇게 긴밀하게 연결(Tightly coupling)되어 있는 상황에서는 변화에 대응하는 것이 아무래도 버거워진다. A예식장이 고급화전략을 통해 1000만원 이하로는 도저히 타산을 맞출 수 없게 되었을 경우 결혼절차 프로세스상의 조건 activity를 수정해야하고 해당 activity와 연결된 A예식장 링크를 수정하거나 없애야하는 번거로운 절차가 끝난 후에라야 결혼 절차 프로세스는 서비스를 재가동 할 수 있을 것이다.

그림 14.실제 서비스와 느슨하게 연결되어 있는 프로세스

반면에 그림 14에서는 실제 서비스는 ESB에 의해 추상화되어 ‘고급 예식장’, ‘일반 예식장’이라는 개념으로 정의되어있고 프로세스상의 각 activity들은 실제 구현되어있는 서비스를 가리키고 있는 것이 아니라 ESB에서 정의되어 있는 추상화된 서비스들을 가리키고 있다. 이러한 느슨한 연결덕분에 고급 예식장의 정의가 변경되거나 조건이 변경되거나 개별 예식장들의 연결 환경이 변경되더라도 전체 시스템에 영향을 미치지 않고 바로 적응 가능한 아키텍처가 만들어진다.

따라서 ESB상에 존재하는 서비스는 크게 두가지로 나뉜다고 볼 수 있는데 첫번째는 논리적인 서비스 즉 인터페이스와 비즈니스 의미를 지닌 데이터로만 이루어진 실체가 없는 서비스, 두번째는 구현되어 실행가능한 서비스이다. 이 두가지의 서비스는 서로 느슨하게 연결되어 유연한 서비스 환경을 만들어가게 된다.

그림 15.느슨한 연결은 다양한 시각에서 서비스를 바라볼 수 있게한다

그림 15에서 보는 바와 같이 느슨한 연결은 ESB에 있어서 여러가지 장점을 기업 IT환경에 제공해준다. 첫번째는 서로 다른 Role을 가진 기업내의 사용자들이 자신들의 관점에 맞게 기업 IT환경을 바라볼 수 있게 해준다는 점이다. 비즈니스 전문가는 논리적인 서비스만 바라보고 그것들을 비즈니스 로직에 맞게 조합하고 변경할 수 있으며 운영자는 운영자의 관점에서 비즈니스 요구사항과 IT자산을 연결하는 작업을 ESB상에서 쉽게 시도할 수가 있다. 개발자 역시 자신이 맡은 애플리케이션과 그것의 서비스에만 관심을 기울이면 되는 것이다. 앞서도 언급했지만 이러한 느슨한 연결은 기업 IT환경을 보다 유연하게 하는 장점을 제공한다.

이렇게 느슨한 연결(Loosely coupling)은 기업 IT환경에 유연함이라는 선물을 제공해주는데 SOA 혹은 ESB이전에는 이러한 느슨한 연결이 없었을까? 아니다. 이러한 느슨한 연결은 IT환경이 그동안 발전해오면서 끊임없이 고민해왔던 주제이고 ESB는 이러한 느슨한 연결에 대한 시도끝에 나온 절묘한 대안이라고 할 수 있다. 앞서 설명했었던 A예식장의 IT서비스 시스템을 예로 들어보자.

그림 16.개별 애플리케이션은 컨테이너에 종속적이다.

A예식장의 예약 서비스 시스템을 보면 가장 맨 하단에 실제 물리적인 데이타베이스를 논리적인 부분으로 보다 느슨하게 연결한 DomainLogic 컴포넌트를 갖고있으며 이를 보다 추상화시켜 비즈니스 로직을 수행할 수 있는 비즈니스 로직 컴포넌트와 Presentation 로직 컴포넌트가 있다. 이렇게 이들은 충분히 컴포넌트화되어 독립적으로 수행될 수도 있는 단위로까지 설계했지만 그럼에도 불구하고 이들 컴포넌트들은 여전히 무언가에 독립적이지 못하다? 무엇에 독립적이지 못할까? 이들은 결국 Runtime을 위한 영역이기 때문에 컨테이너에 독립적일 수가 없다. 이들은 상당히 많은 부분을 보다 물리적이고 구체적인것들로부터 자유롭게 했지만 그럼에도 불구하고 여전히 컨테이너에 많은 빚을 지고 있다. 더욱이 이들을 외부에서 호출하기 위해서는 컨테이너만의 특성을 이해하고 컨테이너가 지시하는 대로 따라야만 한다. 이를테면 이 컨테이너가 JavaEE 컨테이너라면 RMI기반의 EJB호출 방식을 쓰거나 JMS 호출방식을 사용해야만 할 것이다. 설사 이들이 외부에 HTTP기반 웹서비스를 제공한다고 할지라도 여전히 이들 컴포넌트들은 웹서비스 프로토콜로 자신들을 호출하기를 강제하고 있다.

지금까지 ESB는 느슨한 연결을 극대화한 미들웨어임을 강조하였다. ESB의 수많은 특징에도 불구하고 이 느슨한 연결을 가장 첫번째로 뽑아서 강조한 이유는 이 느슨한 연결에 대한 ESB의 지향성이야말로 ESB를 다른 것들과 대비되게 하는 핵심 요소이기 때문이다. 대체 얼마나 여러가지 요소들을 추상화해놓고 아키텍처를 잡았길래 이러한 느슨한 연결의 미들웨어를 만들 수 있었을까? 느슨한 연결을 위해 탄생한 스펙이 있으니 그것이 바로 SCA(Service Component Architecture)이다. 다음 포스트에서는 이 SCA에 대해 집중적으로 알아보자.

참고자료

DWs> 대단위 (Coarse-Grained) 대 소단위 (fine-grained) ( http://www.ibm.com/developerworks/kr/library/ws-soa-granularity/) : Coarse-grained와 fine-grained에 대하여 자세하게 설명하고 있는 자료.