SOA

Service Oriented Architecture

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

우선 금융권의 채널이란 무엇인가?
금융권의 채널은 대내 채널과 대외 채널로 나눌 수 있다.

• 대내 채널 : 각 영업점의 단말(창구), ATM, 인터넷, 콜센터 등의 고객 접점 (증권사의 경우라면 각 영업점의 단말, HTS, WTS, MTS 등이 있다)

• 대외 채널 : 금융결제원, 제휴기관, 은행공동망, VAN사

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

• 업무의 채널 종속성 : 시스템을 개발할 때 모든 채널을 고려하여 구현해야 한다. 채널을 변경하거나 추가한다면 역시 응용의 변경이 필요하다.

• 중복 업무 개발 : 개발 기능이 중복된다. 만약 업무가 변경되면 다른 채널을 모두 변경해야 한다.

• 중복 인터페이스 개발 : 각각의 채널은 모든 타 업무에 대한 인터페이스를 중복하여 개발한다. 게다가 업무가 추가되면 채널 인터페이스를 또 개발해야 한다.

• 일관성 부재 : 전 채널을 대상으로 하는 인프라 부재로 인해 일관성 있는 정보 제공이 어렵다.

MCI

Multi Channel Integration

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

장점

• 비용 감소 : 채널 증가와 기존 채널의 관리에 따른 비용이 줄어든다.

• 전략적 프로젝트 가능 : 맞춤형 서비스와 복합 상품 판매와 같은 상품 및 서비스 체계 구현이 가능해진다.

기능

• 전문 변환 : 외부 시스템의 전문을 내부 시스템의 전문과 매핑

• 다양한 통신 방식 지원 : P2P, Request/Reply, Store/Forward, Publish/Subscribe 등

• 다양한 프로토콜 지원 : 일반적으로 Socket 통신, TCP/IP, X.25, FTP, HTTP, SOAP등

• Load Balancing, Failover, Flow Control

• 배치잡 처리 및 스케쥴러

• 보안 : 암호화/복호화를 통한 데이터 보안

구성 요소

• 채널 어댑터 : 통신 프로토콜, 비즈니스 프로토콜의 인터페이스 담당

• 매핑 엔진 : 외부 전문을 내부 전문(해당 업무)으로 변환

• 매핑 DB : 전문 매핑 테이블

• Developer Studio : 전문, 매핑 룰 정의

• Admin Tool : 시스템 관리 도구 (모니터링, Failover)

단점

• 통합이 발생할 때마다 별도의 통합 프로그램을 구축해야 한다. 즉, 통합하고자하는 기능이 늘어날 수록 통합 프로그램 수가 계속 늘어난다는 것이다.

• 또 시스템이 교체된다면 교체된 시스템의 인터페이스를 바꿔야 한다. EAI는 서로 다른 시스템들을 Native 인터페이스를 통해 연결하는 것이기 때문에 각 시스템에 대한 전문지식, 타부서와의 연계 프로세스, 인터페이스 프로그래밍에 대한 지식을 갖추고 있어야 한다.

구축 시 고려사항

• 성능 : 모든 채널이 집중된다. 따라서 성능 이슈가 발생할 수 있다. 성능 확보 방안이 필요하다.

• 가용성 : MCI의 장애는 시스템 전체 장애로 이어진다. 따라서 장애 대응 방안이 필요하다.

응답 보장

대내 MCI

• 요청한 단말의 채널ID 및 세션 저장

• 요청 단말은 응답전문 대기

• 단말의 타임아웃 전문 수신시 해당 요청전문 오류 처리

• Back-end 지연 응답 전문 오류 처리

대외 MCI

• 전문별 타임아웃값 설정

• 타임아웃 처리방법 설정
  = 재전송 횟수
  = 오류 전송
  

제품

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

EAI

Enterprise Application Integration

이미지 출처

설명

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

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

• 대내전문 표준화에 따른 서비스 확장시 유연성 제공

• 다양한 OS, 프로토콜에 대응하기 위한 어댑터 제공

• 프로세스 통합에 따른 데이터 정합성 유지

• 거래추적 및 오류 발생에 대한 채널 간 통합 모니터링 환경 제공

• 비즈니스 로직과 기술 표준을 분리함에 따른 관리 효율화

• 장애 및 구현에 필요한 Effort 절감으로 운영 효율화

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

ESB

Enterprise Service Bus

이미지 출처

서두에 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의 구조이다.

• 서비스 구현 레이어 : 프레임웍이나 응용으로 구현

• 서비스 오케스트레이션 레이어 : ESB로 구현

• 비즈니스 프로세스 레이어 : BPM으로 구현

라우팅

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

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

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

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

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

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

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

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

• 소규모 ESB 솔루션 제공 벤더
  = 업무 복잡도가 낮은 회사에 적합
  = 저가
  
• 통합 솔루션 제공 벤더
  = EAI에서 ESB로 확장하고 있는 벤더
  = ESB 단독 제품은 아니지만 EAI 기반으로 ESB로 나아가고 있음
  
• 플랫폼 벤더
  = 애플리케이션 플랫폼 혹은 엔터프라이즈 애플리케이션 영역에서 출발한 벤더
  = 자사 솔루션 내에 ESB를 포함하고 있거나, 독립적인 ESB 제품을 제공
  

기능

• Invocation

• Routing

• Messaging

• Service Orchestration

• Complex Event Processing

• Message Exchange Pattern

• Governance

MCI와 ESB 비교

MCI : Hub를 이용하여 비즈니스 로직을 중심으로 기업의 애플리케이션 통합, tightly coupled, 속도 빠르다.

ESB : Bus를 이용하여 서비스 중심으로 시스템 간 유기적 연계, loosely coupled, 속도 느리다. (표준 준수)

참고 출처