Introduction

최첨단의 IT 통합은 웹 서비스 기술을 사용하는 서비스 지향 아키텍쳐(SOA)의 구현이고, 이들의 혜택과 기능들을 설명하는 많은 자료들이 있다. (참고자료) 최근에 Enterprise Service Bus(ESB)의 개념은 SOA 인프라의 핵심 컴포넌트로서 표현되고 있다. (참고자료) 하지만 ESB가 제품인지 기술인지 아니면 표준인지를 명확히 해 두는 것이 중요하다. 특히 ESB가 구현될 수도 있는 것이라면 어떻게 구현할 것인가?

이 글에서는 SOA를 가능하게 하는 미들웨어 기술로 구현된 인프라 기능으로서 ESB를 설명한다. ESB는 서비스, 메시지, 이벤트 기반 인터랙션을 이종의 환경에서 지원한다. 적절한 서비스 레벨이 구분되어 있고 관리도 쉽다. 여기에 필요한 다양한 기능들은 요약 및 범주화 되어있다.

이 글에서는 객체 지향 아키텍쳐(SOA)에 순응하면서 가장 기본적인 Enterprise Service Bus (ESB)의 필요를 충족시키는 최소한의 기능들을 규명할 것이다. 이를 규명함으로서 SOA를 지원하는 ESB를 구현하는데 기존의 어떤 기술들이 사용될 수 있는지를 파악할 수 있다. 특정 상황에서 필요한 부가 기능들을 정의하는 방식을 분석하여 상황에 가장 합당한 구현 기술을 선택할 수 있는 것이다.

이 글을 통해 ESB 또는 SOA 구현의 시작점을 잘 포착한 SOA의 ESB 시나리오를 정의할 것이다. 솔루션 패턴 적절한 구현 기술을 선택하는데 필요한 가이드를 제공한다.

ESB 솔루션이 진화하고 성숙해 갈수록 여기에 요구되는 기능들 역시 진화되고 있다. 마찬가지로 ESB 제품의 가용성과 기능 또한 발전하고 있다. 이 시리즈의 마지막 부분에서는 ESB 기능과 기술을 처음 사용하는 사람들을 위한 가이드를 마련해줄 것이고 점진적인 접근 방식도 설명하겠다.

위로

SOA에서의 ESB 역할

여기에서 SOA를 자세하게 다루지는 않겠지만(참고자료), 기본적인 원리를 다음과 같이 요약했다:

• 서비스를 정의하기 위해 구현과 독립된 인터페이스를 사용
• 위치 투명성과 상호운용성을 강조하는 통신 프로토콜 사용
• 재사용할 수 있는 비즈니스 함수를 캡슐화하는 서비스 정의

그림 1은 위 원리들을 설명한 것이다. 웹 서비스가 이 원리에 완벽하게 맞기는 하지만 유일한 기술은 아니다.

SOA를 구현하기 위해서는 애플리케이션과 인프라 모두 SOA 원리를 지원해야 한다. SOA용 애플리케이션을 실행하려면 직접 또는 어댑터를 사용하여 기존 함수 또는 새로운 함수에 대한 서비스 인터페이스를 생성해야 한다. 가장 기초적인 수준에서 인프라를 가동하려면 서비스 요청을 정확한 서비스 공급자에게 라우팅 및 전달하는 기능이 필요하다. 인프라가 서비스의 대체 구현을 클라이언트에 영향을 주지 않고 지원하는 것도 중요하다. 이는 그 서비스 인터페이스가 SOA 원리에 따라 지정되어야 할 뿐만 아니라 인프라에서도 클라이언트 코드가 서비스 위치와 통신 프로토콜과 독립적인 방식으로 서비스를 호출할 수 있어야 한다. 그와 같은 서비스 라우팅과 대체는 ESB의 많은 기능들 중 하나이다.

ESB는 서비스 인터랙션 기능을 지원하고 이를 실행할 통합된 통신, 메시징, 이벤트 인프라를 제공한다. 따라서 오늘날 사용되는 주요 엔터프라이즈 통합 패턴을 하나의 엔터티로 만든 것이다. ESB는 엔터프라이즈 필요에 맞게 SOA를 위한 인프라를 제공한다. 적절한 서비스 레벨과 관리 편의를 제공하고 이종 환경에서 작동할 수 있게 한다.

이 글의 나머지 부분은 SOA에서의 ESB 역할을 다루게 될 것이다. 기본적인 라우팅과 전송 그 이상의 기능들을 설명할 것이다.

ESB의 구조

ESB는 분산 인프라로 정의되고, 일반적으로 허브 앤 스포크(Hub-and-spoke)라 불리는 메시지 브로커링 기술 같은 솔루션들과 비교된다. 하지만 이것은 잘못된 구분이다. 제어의 중앙화와 인프라의 분산 이라는 두 가지 문제가 제기된다. ESB와 허브 앤 스포크 솔루션 모두, 서비스 인터랙션의 라우팅, 서비스 네이밍 등 설정의 제어를 중앙에 집중시킨다. 두 솔루션 모두 간단하게는 중앙화된 인프라에 전개되거나 좀더 복잡할 경우 분산 방식으로 전개된다.(그림 2)

물론 기술들 마다 각자가 지원하는 물리적 전개 양상에 다양한 제한이 있기 마련이다. 어떤 것이 광범위한 지역에 걸쳐 통합을 지원하는 광역 분산에 알맞고 반면 어떤 것은 높은 가용성과 확장성을 지원하는 분산화 된 클러스터에 전개되는 것이 더 알맞다. 이러한 후보 기능에 요구사항을 맞추는 것은 ESB 디자인에 있어 중요한 측면이다. 초기 전개를 점진적으로 확장하여 진화하는 요구사항을 반영하는 것과 인프라의 지역적 접근성을 확장하는 것 역시 중요하다.

또한, 다른 컴포넌트들(Service Directory, Business Service Choreography, Business-to-Business (B2B) Gateway 컴포넌트)과 관련하여 SOA 인프라에 ESB를 배치해야 한다. SOA 원리에는 이 컴포넌트들에 대한 필요를 직접 언급하지 않았기 때문에 여기에서는 선택적 컴포넌트로 취급하겠다. 그림 3은 이 컴포넌트들과 ESB의 관계를 보여주고 있다.

ESB는 서비스 요청을 라우팅하기 위해서 일정한 형식의 서비스 라우팅 디렉토리가 필요하다. 하지만 SOA는 개별 비즈니스 서비스 디렉토리를 가지고 있어 이것의 가장 기본적인 형식은 조직에서 개발 활동 시 서비스의 재사용을 위한 서비스 목록 된다. 웹 서비스의 계획은 비즈니스 서비스 디렉토리 역할과 서비스 라우팅 디렉토리 역할을 하도록 UDDI 디렉토리를 배치하여 동적 발견과 서비스 호출을 가능하게 하는 것이다. 이 디렉토리는 ESB의 일부로 볼 수도 있지만 솔루션이 일반화 되기까지 비즈니스 서비스 디렉토리는 ESB와 분리될 것이다.

Business Service Choreographer의 역할은 여러 비즈니스 서비스에서 비즈니스 프로세스들을 구성하는 것이다. 따라서 ESB를 통해 서비스를 호출할 것이고 그런 다음 비즈니스 프로세스를 서비스로서 클라이언트에 노출할 것이다. 이것 역시 ESB를 통해서이다. 하지만 비즈니스 프로세스와 서비스를 구성할 때의 역할은 Business Service Choreographer (비즈니스 워크플로우 기술)을 ESB에서 분리된 인프라 기술로 구분하는 것이다.

마지막으로, B2B Gateway 컴포넌트의 역할은 안전하고 제어된 방식으로 사용 가능한 두 개 이상의 조직을 서비스로 만드는 것이다. 그와 같은 서비스를 ESB의 일부가 아닌 ESB와 연결된 것으로 보는 것이 유용하다. B2B Gateway 컴포넌트와 ESB를 구현하는데 적합한 기능을 제공하는 게이트웨이 기술이 있지만 B2B Gateway 컴포넌트의 목적은 ESB에서 분리하는 것이다. 실제로 이를 위해서는 파트너 관계 관리 같은, ESB의 일부가 아니고 ESB의 지원을 받아야 할 필요도 없는 부가 기능이 필요하다.

ESB의 기능 모델

표 1은 기존에 정의된 ESB의 기능들을 요약 및 범주화 한 것이다. (참고자료) 어떤 것은 매우 기초적인 반면 자동 기능 또는 지능형 기능 같은 것은 온 디맨드 운영 환경으로의 중요한 단계 진입을 나타낸다. 현재 대부분의 ESB 시나리오가 이 목록의 하위 기능만을 요구한다는 것에 주목하라. ESB 구현에 필요한 최소한의 기능은 아래 SOA를 위한 최소한의 ESB 기능 구현 섹션을 참조하라.

표 1: 기존에 정의된 ESB 기능들

이 많은 기능들은 소유권이 있는 기술을 사용하거나 오픈 표준을 사용하여 구현될 수 있다. 하지만, ESB 구현을 위한 다양한 후보 기술은 퍼포먼스, 확장성, 가용성에 따라 매우 다양하다. 또한 ESB 기능과 지원되는 오픈 표준들도 다양하다. 관련 표준이 최신 것이거나 아직 부상하고 있기 때문에 ESB를 구현할 때에는 완숙한 소유권 기술과 덜 성숙한 오픈 표준 지원들 간 비교를 통해 신중하게 결정해야 한다.

여기에서는 이 목록의 기술들을 자세히 다루지는 않겠다. ESB를 채택 또는 구현하는 다양한 방식들 중에서 결정 방식에 초점을 맞추겠다. 특히 다음 섹션에서는 SOA를 지원하기 위해 ESB에 필요한 최소한의 기능에 대해 이야기하겠다.

SOA를 위한 최소한의 ESB 기능 구현

이전에 정의된 기능들의 작은 부분만이 대부분의 SOA 시나리오와 관련되어있다면 다음과 같은 질문을 할 수 있다: ESB를 구현하는데 필요한 최소한의 기능은 무엇인가? 다음은 일반적으로 합의된 ESB 요소들이다:

• ESB는 논리적인 아키텍쳐 컴포넌트로서 SOA의 원리를 따르는 통합 인프라를 제공한다.
• SOA 원리는 구현 독립의 인터페이스 사용, 위치 투명성과 상호운용성에 집중된 통신 프로토콜, 비교적 큰 단위의 서비스 정의를 요구하고 재사용 가능한 함수를 캡슐화한다.
• ESB는 분산된 이종 인프라로서 구현된다.
• ESB는 서비스 인프라를 관리하는 수단과 분산된 이종 환경에서 작동할 수 있는 기능을 제공한다.

표 2는 이와 같은 원리들에 따라 정의된 ESB의 최소 기능들이다.

표2: ESB의 최소 기능들

이러한 최소한의 기능들은 EAI middleware, 웹 서비스, J2EE, XML 같은 특정 기술을 사용할 것을 요구하지 않는다. 다만 요구사항에 잘 부합한다면 그러한 기술들의 사용이 권장되지만 의무적인 것은 아니다:

• URL 어드레싱과 기존 HTTP와 DNS 인프라는 라우팅 서비스와 위치 투명성을 겸비한 "버스" 인프라를 제공한다 .
• SOAP/HTTP는 요청-응답 메시징 패러다임을 지원한다.
• HTTP 전송 프로토콜은 광범위하게 사용될 수 있다.
• SOAP과 WSDL은 개방된, 구현 독립의 서비스 메시징과 인터페이스 모델이다.

SOAP/HTTP와 WSDL을 기본적인 사용은 그저 point-to-point 통합이며 ESB에 필요한 핵심 기능을 수행하지는 않는다:

• 서비스 어드레싱과 네이밍을 관리할 어떤 관리 기능도 없다. 서비스 이름은 각 어댑터로 개별적으로 관리되고 서비스 라우팅 제어는 서비스 클라이언트, HTTP 인프라, 어댑터에 할당된 서비스 이름에 의해 호출된 어드레스들 사이로 분산된다.
• 구현 상세에 의존하지만 이 방식은 서비스 구현의 대체를 이용하지 않는 듯 하다. 서비스 요청 코드(개발 툴로 생성)는 특정 주소로 특정 프로토콜을 통해 특정 서비스 공급자 구현으로 직접 바인딩된다. 하나의 서비스 구현을 다른 구현으로 대체할 때는 애플리케이션 코드의 변경과 재전개가 필요하다.

물론 대부분의 시나리오에는 더 많은 기능이 필요하다. 특히 다음과 같은 요구사항들로 인해 보다 복잡한 기술을 사용하게 될 것이다:

• 서비스의 품질(Quality of Service)과 서비스 레벨(Service Level) 기능
• 서비스 구성법, 디렉토리, 변형 등, 한 차원 더 높은 SOA 개념
• Management 및 Autonomic 기능과 인프라 지능형 기능 같은 온 디맨드 운영 환경 요구사항
• 다중 네트워크, 다중 프로토콜, 다중 도메인을 통한, 진정한 의미의 이종(異種) 운영

위로

ESB에 영향을 미치는 보안 문제들

여기에서 보안 요구사항을 직접 언급하지는 않겠다. 하지만 ESB 기술을 선택할 때 중요한 문제이기는 하다. 예를 들어 서비스 요청에 대한 인증 또는 권한이 필요 없다면 기술의 선택은 매우 광범위해질 수 있다. 특정 수준의 보안이 요구된다면 어떤 유형의 보안을 채택할지를 평가하는 것이 중요하다:

1. EAI 미들웨어 서버들 간 Secure Socket Layer 상호 인증의 사용 또는 HTTPS 프로토콜의 사용 시, 통신 인프라에 보안이 허용되는가?
2. 개별적인, point-to-point 보안이 참여 시스템 간 허용되는가, 또는 end-to-end 모델이 필요한가? 예를 들어, 브로커 같은 중개 시스템을 통해 클라이언트 ID를 서비스 구현의 최종 공급자에게 전달할 필요가 있는가?
3. 애플리케이션 레이어에 보안이 허용되는가? 예를 들어, 클라이언트 코드가 사용자 ID와 패스워드를 갖춘 기초적인 HTTP 인증을 수행할 수 있는가, 또는 그와 같은 정보를 애플리케이션 데이터로서 서비스에 전달할 수 있는가?
4. 보안이 Kerberos 또는 WS-Security 같은 보안 표준에 순응하는가?

이 모든 방식이 가능하지만 산업계의 방향은 인프라와 미들웨어의 지원을 받는 표준 순응의 보안 기능(예를 들어, WS-Security)으로 향하고 있다. 하지만 이 표준들이 비교적 최근의 것이고 이에 대한 제품 지원이 확립된 것이라기 보다는 계속 변하고 있다. 특히 상호운용성과 관련된 부분이 그렇다. 따라서 ESB 아키텍쳐는 가능한 빨리 보안 요구사항을 확립해야 한다. 이렇게 함으로서 구현 기술을 선택할 때 이것이 적용될 수 있는 것이다.

참고자료

• developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
  
  
• Web Service-Oriented Architecture - The Best Solution to Business Integration
  
  
  
  
• SOA - Save Our Assets
  
  
  
  
• Patterns: Service-oriented Architecture and Web Services
  
  
  
  
• "Migrating to a service-oriented architecture, Part 1" (developerWorks, December 2003), "Migrating to a service-oriented architecture, Part 2" (developerWorks, December 2003).
  
  
  
  
• LooselyCoupled.com
  
  
  
  
• Gartner
  
  
  
  
• IBM Patterns for e-business
  
  
  
  
• on demand business
  
  
  
  
• Patterns: Implementing an SOA using an Enterprise Service Bus
  
  
  
  
• developerWorks SOA and Web services technology zone.
  
  
  
  
• Developer Bookstore
  
  
  
  

필자소개

아티클 순위

의견

위로

목차

• Introduction
• SOA에서의 ESB 역할
• ESB에 영향을 미치는 보안 문제들
• 참고자료
• 필자소개
• 의견