Print
카테고리: [ Miscellaneous ]
조회수: 17513

1. SOA

SOA는 어떤 실체가 있다기 보다는 개념이다. 어떤 개념이냐면 비즈니스적인 의미를 가지는 컴포넌트를 기업내의 통합된 프로토콜로 서비스하여 제공하는 개념이다. 그래서 이 SOA는 BPM을 이용한 Composition이나 ESB를 이용한 유연성의 증대 등으로 구체화될 수 있다.

본격적으로 이야기를 풀어보려고 한다. 금융권의 채널이란 무엇인가?

우선 대내 채널과 대외 채널로 나눌 수 있다.

그런데 채널이 늘어나면서 관리, 통제가 어려워진다. 또한 서비스 중복에 따른 비용이 증가하고 있다. 일반적인 채널 구조의 문제점을 정리해보자.


2. MCI

대내 채널통합을 대내MCI가, 대외기관(금융결제원, 은행, VAN사 등) 채널통합은 대외MCI가 담당한다.

2.1. 장점

2.2. 기능

2.3. 구성 요소

2.4. 단점

2.5. 구축 시 고려사항

2.6. 응답 보장

2.6.1. 대내  

  1. 요청한 단말의 채널ID 및 세션 저장
  2. 요청 단말은 응답전문 대기
  3. 단말의 타임아웃 전문 수신시 해당 요청전문 오류 처리
  4. Back-end 지연 응답 전문 오류 처리 

2.6.2. 대외

  1. 전문별 타임아웃값 설정
  2. 타임아웃 처리방법 설정
    - 재전송 횟수
    - 오류 전송 

2.7. 제품

MCI 제품에는 티맥스의 AnyLink 등이 있다.


3. EAI

3.1. 설명

채널 내부로 들어온 데이터 중 필요한 정보를 전문 변환이나 라우팅으로 가공하여 새로운 데이터를 만들어내는 역할을 한다.

EAI를 MCI로 전환 시 장점은 다음과 같다.

종류는 Tibco, OSB, WebSphere Message Broker 등이 있다.


4. ESB(Enterprise Service Bus)

4.1. ESB란?

서두에 SOA에 대해 잠깐 언급한 바 있다.  ESB는 SOA를 지원하는 서비스와 응용 컴포넌트간의 연동을 지원한다. 즉, ESB는 SOA를 구현할 수 있게 해주는 실체로, Loosely coupled의 asynchronous 메세지 방식의 SOA를 위한 라우팅 알고리즘을 제공한다.

사실 EAI의 Hub & Spoke 방식의 한계로부터 발전했다. (하지만 EAI와 ESB는 서로 같은 형태로 수렴하고 있어 ESB는 벤더들의 마케팅 전술이라는 비판이 있다)

본격적으로 특징을 보자.

먼저 다양한 시스템과 연동을 위한 다양한 프로토콜을 제공한다. 웹 서비스나 XML이 그 예이다. 또한 변환이 가능하다. 예를 들어 XML와 JSON이 존재한다면 ESB 계층에서 JSON TO XML 변환을 수행할 수 있다. JMS TO HTTP도 가능하다.

그리고 위에서 말했지만 loosely coupled, 느슨한 결합이다. (클라우드의 추세이기도 하다)

BPM을 지원한다. 다음은 큰 SOA의 구조이다.

라우팅, 매우 중요한 부분이다. 일반적인 리버스 프록시보다 향상된 라우팅을 제공한다. 보통의 리버스 프록시는 HTTP 헤더 또는 URI 기반으로 라우팅을 하는데 반해 ESB는 메세지(헤더 혹은 본문)를 이용하여 라우팅할 수 있다. (Content-Based Rouing) 메세지의 내용에 따라 호출할 서비스를 결정하거나 특정한 로직을 처리하는 경우다. 정적 라우팅, 동적 라우팅 지원, 동적 라우팅은 메세지 내용 기반, 룰 기반, 정책 기반 등 다양한 라우팅을 제공한다.

SLA, QoS를 지원한다. 이는 전송 보장 기능, 트랜잭션 관리를 수행한다. SLA(Service Level Agreement) 관련해서는 만약 설정된 목표를 달성하지 못하면 알람을 보내기도 한다.

보안은 어떨까? WS-Security에서 정의하고 있는 인증, XML 기반 암호화, SSL 등을 지원한다. 보안 기능을 사용하고자 한다면 보안 수준과 여러 보안 정책(예: 인증서 관리 등)이 필요하다.

그리고 이벤트 지향적아고, 표준 지향적이며 플랫폼 독립적이다.

MCI와의 차이점은 무엇일까? MCI가 이기종간의 통신을 위해 전문 해석/변환을 통한 채널 관리/통합을 한다고 하면, ESB는 응용(애플리케이션) 간의 통합을 보장하는 개념이다.

한편 성능이 중요하다. bypass만 하느냐, 무언가 작업을 하느냐에 따라 다르긴 하지만 어쨌든 타임 오버헤드를 최소화해야 한다. 또 메세지 body까지 파싱하지 않도록 하는게 중요하다. (body까지 파싱다면 성능은 더욱 떨어진다)

이처럼 ESB는 차후 시스템에 변화가 있을 때 매우 도움이 된다. (초기에는 별 메리트가 없다. 초기에는 이미 요구사항대로 구현이 되어 있기 때문이다)

ESB 솔루션은 다음과 같이 구분할 수 있다.

1. 소규모 ESB 솔루션 제공 벤더

2. 통합 솔루션 제공 벤더

3. 플랫폼 벤더

ESB 제품의 종류에는 티맥스의 ProBus, Apache ServiceMix(http://servicemix.apache.org/) 등의 제품이 있다.

다음은 위키 백과에서 발췌한 ESB의 특성(기능) 정리이다.

4.2. Apache ServiceMix

그러면 오픈 소스 ESB 제품인 Apache ServiceMix에 대해 조금 더 자세히 알아보자.

Apache License 2.0에 의해 배포되는 ServiceMix는 JBI(Java Business Integration, JSR 208) 스펙을 만족하며 다음과 같은 구성 요소를 갖추고 있다.

JBoss에도 관련 제품군이 있다.


5. 결론

다시 간단히 MCI와 ESB를 비교해보자.

마지막으로..

계속해서 전문의 변환에 대한 이야기를 했다. 만약 레거시 시스템에 대한 통합을 수행한다면 레거시 메세지를 표준 전문으로 변환하는 작업이 필요하겠지만 애초에 SOA 프로젝트라면 설계 단계부터 표준 전문을 사용하기 때문에 전문 변환 작업은 발생할 일이 없다.