SOA를 실현하는 ESB
SW와 애플리케이션간의 연동을 위한 미들웨어 플랫폼ESB(Enterprise Service Bus)는 웹서비스(Web Service), 인텔리전스 라우팅(Intelligent routing), 트랜스포메이션(Transformation) 기술을 기반으로 SOA(Service Oriented Architecture)를 지원하는 미들웨어 플랫폼이다. ESB는 SW 서비스와 애플리케이션 컴포넌트간의 연동을 위해 경향화된 백본의 역할을 수행한다. ESB를 통해 분산된 서비스 컴포넌트를 쉽게 통합 연동이 가능하며, 신뢰성 있는 메시지 통신이 가능하다.
ESB를 통한 서비스 컴포넌트로는 웹서비스 컴포넌트뿐만 아니라 어댑터(Adap-ter) 기술을 활용한 ERP 등의 레거시 컴포넌트, B2B 컴포넌트, J2EE & .NET 컴포넌트가 있다. ESB는 Emerging Technology로써 가트너에 따르면 올해 가장 관심 높은 기술로써 보고되기도 했다.
ESB의 유형으로는 MQ방식과 Proxy 방식으로 나눌 수 있다. MQ방식은 EAI를 확장하여 메시지의 통로로써 역할을 수행하며, 자체 또는 외부의 프로세스 관리 기능을 활용하는 미들웨어 플랫폼이다. Proxy 방식의 ESB는 기본적인 메시지 라우팅 기능을 기반으로 개별적인 웹서비스를 중앙의 Proxy를 통해서 관리가 가능하도록 지원하는 플랫폼이다.
두 가지 방식의 차이는 해당 플랫폼의 활용 측면에서 차이가 난다. MQ 방식은 EAI 측면의 BPM 구축 시에 유용하며, Proxy 방식은 웹서비스 관리 솔루션에서 도입 활용되고 있다. 초기의 ESB의 시작은 MQ 방식의 ESB에서 시작되었으며, 최근에 웹서비스 관리 솔루션의 등장과 함께 Proxy 방식의 ESB에 대한 관심이 높아지고 있다.SOA에서의 ESB 역할
분산된 서비스 컴포넌트의 효율적인 통합을 위해서 ESB는 BPEL 혹은 솔루션 벤더의 자체적인 표준을 따르는 프로세스 매니저와 연동해 프로세스 기반의 통합을 지원한다. 기능적으로는 기존의 EAI와 같은 역할을 수행하며, 프로세스 기반의 통합 지원과 웹서비스 기반의 통합환경 등을 지원한다.
1. Service Component Integration
• XML 기반의 동기/비동기 SOAP 메시징: SOAP 표준에 기반한 메시지를 교환함으로써 이기종/분산 환경에서의 데이터 및 애플리케이션 연동이 가능하게 지원함. 궁극적으로 프로세스 연동을 지향함
• Secure and reliable messaging: MQ와 같은 MOM(Message Oriented Middleware)을 활용하여 메시지 전송의 안정성과 보안성을 지원함
• Intelligent routing and inter-mediaries: 메시지의 내용에 기반한 라우팅을 지원하고 메시지를 중개함
• Data transforming: XSLT, XQuery를 통한 데이터의 변환을 지원
• QoS: 정해진 시간에 일정한 메시지 전송 수를 보장되도록 조정하는 역할
• Legacy 통합: DB, ERP와 같은 자원과의 통합을 위한 어댑터를 제공하며, 어댑터를 통해서 애플리케이션 레벨의 통합이 가능하도록 지원
• 웹서비스 지원: 웹서비스 클라이언트 역할 수행이 가능하도록 자동화된 기능(WSDL 지원, 메시지 처리)을 제공한다.
• 프로세스 지원: 처리할 서비스 단위의 업무 처리를 제어할 수 있는 프로세스를 정의하고, 프로세스 기반 하에서 업무 처리가 가능하다.
• 메시지 표준: XML 기반의 표준화된 메시지 기반(주로 SOAP)으로 통신이 이루어진다. 경우에 따라서 ESB 내부적으로는 자체 표준으로 변환하여 사용하지만, ESB 외부로는 SOAP을 표준으로 사용한다.
• Work List: 사용자의 입력 또는 승인 처리를 지원하기 위한 비동기적(Asynchronous)인 입력 방식을 지원하여, 사용자의 입력을 기다리고, 사용자의 입력에 따른 처리를 진행할 수 있도록 지원
• B2B 프로토콜 지원: RossetaNet, ebXML과 같은 B2B 프로토콜을 지원하여, 글로벌한 전자상거래를 지원
4. Composite Component 여러 서비스와 연동되어 있는 ESB는 자체적으로 컴포넌트의 형태로 구성이 되며, 여러 단위 서비스가 프로세스 형태로 연결되어 있는 복합 서비스로 활용 가능하다.
개 별적인 컴포넌트를 기반으로 ‘Composite Component’로 구축되는 SOA 아키텍처의 모습은 다음과 같다. Atomic Service는 단위의 Service Component를 나타내고 있으며, ESB 기반 서비스 형태의 Composite Compo-nent를 구성하게 된다. 개별 애플리케이션은 이들 Composite Component를 사용하여 동작하게 되며, 결과적으로 프로세스 기반의 통합을 지원하는 형태가 된다.
ESB의 특징
SOA를 지원하기 위하여, ESB는 몇 가지 차별적인 특징을 가지고 있다. 메시지 기반의 Loosely Couple한 표준 인터페이스 기반의 통신을 지원하고 있으며, 표준적인 메시지 표준인 SOAP을 지원한다. 또한 BPM 기반에서 프로세스 레벨의 통합이 가능하도록 지원되고 있다.
• Loosely coupled: 표준 인터페이스(WSDL)를 준수하는 메시지 전송에 의해서 애플리케이션간의 연관성이 적은 형태에서 연동을 지원
• Highly distributed integration network: beyond hub-and-spoke EAI broker, centralizes control and distributes processing
• Event-driven: 독립적인 애플리케이션에 의한 프로세스의 시작이나 정지, 재시작 등의 조정이 가능한 형태
• Documents-oriented(Message Driven)
• Support for several standard interfaces: From a list including COM, CICS, .NET, JMS, JCA, JDBC, and Web Services - Broker를 중심으로 Legacy, Middleware, Database 간의 연동을 지원
1. Process
사용자가 정의한 Activity(Service) 단위로 수행이 가능하도록 수행 순서를 정의하고, 경우에 따라서 조건에 따른 콘텐츠 기반 라우팅이 가능하도록 지원한다. 메인 프로세스에 종속되는 서브 프로세스를 가질 수 있으며, 프로세스의 시작과 종료 시점까지 ESB를 통해서 실행이 진행되게 된다. ESB 내부에 프로세스 매니저가 존재하기도 하며, 별도의 프로세스 매니저(BPM)를 활용할 수도 있다.2. Service(Service Component)
프로세스 상에서 진행되는 모든 Activity를 서비스로 지칭할 수 있다. 서비스는 자체적으로 처리를 진행하거나(메시지 변환 등) 외부의 서비스 컴포넌트를 호출해 처리가 가능하다. 외부의 서비스 컴포넌트를 호출하여 처리하는 경우 ESB 내부의 서비스는 클라이언트의 역할을 수행한다.3. Adapter
레거시를 연동하거나 특정한 애플리케이션과의 통합이 필요한 경우 이를 가능하게 하는 역할을 수행한다. 주로 레거시 애플리케이션을 통합하는 경우에 사용하며, 메시지의 생성과 변환을 통해서 중계하는 역할을 수행한다.4. Messaging Layer
메시지가 신뢰성을 보장하면서 전송 되도록 지원하며, 메시지가 올바른 목적지에 전달 가능하도록 라우팅 기능을 제공. 메시지 전송 시에 Failure나 Reject와 같은 경우 재전송 및 처리가 가능하도록 특정 장소에 저장하여 보존한다. WS-Reli-ability 표준을 통한 신뢰성 보장이 목적이다.ESB Integrated Architecture
ESB의 목적은 자원을 부서별/업무별로 분산하여 처리가 가능하도록 분산 아키텍처를 지원하고 있다. 동일한 솔루션 ESB를 활용할 경우 통합처리 및 관리에 문제가 없으나, 이기종 간의 ESB를 통합 활용하게 될 경우 대부분의 ESB가 지원하는 웹서비스를 활용하여, 프로세스의 처리가 가능하지만, 솔루션의 차이에 따른 다음과 같은 문제점이 발생하게 된다.
• 연동되는 ESB안에 Asynchronous한 Component가 있을 경우 즉시적인 응답을 얻을 수가 없기 때문에 Call-Back URL을 활용하여 향후 결과를 반영 할 수 있다.
• 통합 모니터링이 지원되지 않으므로, 전체적인 프로세스 관리가 어렵다. 즉 프로세스의 실행에 따른 결과 트래킹이 어렵다.
• 하나의 프로세스를 다른 프로세스로의 이식이 어렵다. BPEL 표준을 활용하는 솔루션의 경우에도 표준 외에 부가적으로 사용하는 기능 때문에 호환성 문제가 발생 할 수 있다.
BPM에서의 ESB활용 방안
ESB는 자체 내장된 프로세스 매니저를 활용하거나 또는 외부의 프로세스 매니저와 함께 사용되어, BPM의 역할을 수행할 수 있으며, 이때 EAI형태의 BPM 솔루션과 같은 역할 수행이 가능하다. 거대 단위의 업무 기반에서 BPM 적용 시에 상위 비즈니스 프로세스를 주로 담당하는 상위 프로세스와 시스템 및 서비스 통합을 주로 담당하는 하위 프로세스를 나누어 계층화하여 구축하면 효율적인 BPM 구축이 가능하다.상위 프로세스 상에서 서비스 통합을 담당하는 하위 프로세스로 구성된 개별 Composite Component를 활용하는 형태이다. 상위 프로세스를 위한 워크플로우 형태의 BPM 솔루션과 시스템 및 서비스 통합에 해당하는 하위 프로세스를 처리하는 ESB 솔루션과 연동하여 전체적인 프로세스를 지원하는 효율적인 BPM 구축이 가능하다.
ESB를 활용하여 SOA 기반의 시스템 구축이 활성화되기에는 여러 비즈니스, 테크놀로지 측면의 이슈 사항이 존재한다. 이러한 이슈 사항을 해결하기 위해서 많은 노력이 진행 중이지만, 궁극적으로는 정보시스템 환경인 인프라와 기업의 업무 형태가 획기적으로 바뀌어야 하므로 시간이 소요 될 것으로 전망된다.SOA의 가치를 충분하게 보장할 수 있도록 시스템을 구축하기 위해서는 ESB를 활용한 아키텍처 구성 및 구축이 필수적이며, 이를 위한 솔루션의 검증 및 정보시스템 환경과 업무 요구사항에 알맞은 솔루션을 채택하고 그에 맞도록 아키텍처 구성을 필요로 한다. 기존의 정보 자원과 요구사항에 맞는 신규 자원의 구축 및 전체적인 프로세스 레벨의 통합을 통해서 SOA가 구성 될 수 있으며, 이를 위한 ESB의 역할이 점차 확대될 것이다.
현재의 ESB 솔루션은 계속해서 진화 발전하고 있으며, 서비스 컴포넌트의 확산과 함께 본격적으로 도입 및 활용될 것으로 전망된다.
