khstar

ALSB소개 본문

BEA/ALSB

ALSB소개

khstar 2008. 1. 3. 19:50
반응형

전사 IT 환경을 위한 BEA의 ESB ALSB


조병욱, 김대중| BEA시스템즈코리아 기술 지원 파트


이 글에서는 BEA의 ESB 솔루션인 아쿠아로직 서비스 버스와 그 적용 사례에 대해 살펴볼 것이다. 아쿠아로직 서비스 버스는 ESB의 통합 기능을 단일 소프트웨어의 서비스 관리 기능과 결합함으로써 SOA 전반에 걸쳐 구성과 배치를 가속화하고 고유 서비스에 대한 관리를 간소화시켜 준다.


ESB와 SOA에서 공통적으로 언급되고 있는 서비스란 무엇인가? 서비스는 네트워크를 통해 이용 가능한 소프트웨어 자원이다. 서비스 제공자는 표준화된 메커니즘으로 서비스를 공개하고 제공하며 서비스 사용자는 네트워크상에서 표준화된 프로그램 방법으로 서비스를 사용한다. 즉, 서비스란 ‘네트워크화된 업무’ 또는 ‘네트워크를 통해 접근 가능한 업무 애플리케이션’이다. 여기서 주목할 것이 기존 애플리케이션의 네트워크화 또는 서비스화이다. 표준화된 메커니즘과 프로그램 방법이라는 것이 사실상 웹 서비스를 의미하는 것이다. 즉, 기존 애플리케이션의 핵심 로직은 그대로 재사용하면서도 업무 시스템 간 상호 유기적인 재사용을 위해 웹 서비스로 인터페이스화하는 것이 서비스화라고 할 것이다. 이러한 서비스의 전사적인 방법 또는 소프트웨어적인 디자인 패턴이 바로 SOA이다.


BEA의 경우 무엇보다 전사 업무 시스템의 유기적 결합과 재사용을 위한 서비스화(Service Enablement)에 초점을 맞추고 있다. 이러한 관점에서 BEA SOA 도메인 모델을 통해 전사 업무 시스템의 서비스화를 위한 구체적인 방법론을 제시하며, 아쿠아로직 서비스 버스(AquaLogic Service Bus, 이하 ALSB) 제품군을 통해 서비스 플랫폼을 제공하고 있다.


아쿠아로직 서비스 버스


BEA의 ESB 솔루션인 ALSB를 전체적으로 살펴보면 서비스 요청자와 서비스 제공자 사이에서 <그림 1>과 같은 역할을 한다.


ALSB 파이프라인 아키텍처


ALSB의 내부 메시지 처리 구성은 파이프라인 아키텍처를 이용한다. ALSB로 입력된 메시지는 파이프라인을 통해서 처리되는데 각각의 파이프라인은 스테이지로 구성이 된다. 각 스테이지는 액션으로 구성되고 이 스테이지의 개념은 로직이 복합되어 하나의 기능을 수행하는 일종의 C 함수와 같은 개념으로 생각하면 된다.


이 액션에 메시지에 대한 처리 로직을 사용자가 정의하게 된다. 이 로직에는 메시지의 변환, 메시지 경로의 변경, 타 서비스의 호출 등의 기능을 포함한다. ALSB는 하나의 메시지 처리를 위해 2개 또는 에러 처리를 위한 파이프라인을 포함하여 총 3개의 파이프라인을 구성한다. 클라이언트로부터 메시지를 받았을 때 이 메시지를 서비스로 보내기 전에 전처리를 하는 Request 파이프라인, 서비스에 메시지를 보낸 후 처리하여 받은 결과를 가공 처리하는 Response 파이프라인으로 구성되며, 옵션 사항으로 Error 파이프라인을 정의하여 에러 상황에 대한 처리할 수 있도록 한다.


<그림 1> BEA ALSB


<그림 2> ALSB 파이프라인 아키텍처



<화면 1> Xquery Mapper에 의한 작업 화면


ALSB의 메시지 변환


메시지 변환이란 ALSB로 입력된 XML, Non-XML 메시지의 내용과 포맷을 호출하고자 하는 서비스 형식에 맞게 변환하거나 서비스에서 리턴된 메시지를 리턴하기 전에 호출한 쪽의 포맷에 맞도록 변환해주는 것을 말한다. 예를 들어 CustInfo.xsd와 PO.xsd와 같은 포맷의 두 개의 메시지가 있다고 생각하자(‘이달의 디스켓’ 참조). 서비스 A를 호출하기 위해서는 POCustInfo.xsd와 같은 메시지 포맷을 활용한다고 가정했을 때 서로 메시지 포맷이 다르기 때문에 각 메시지 포맷 간에 맵핑이 필요하게 된다.


ALSB에서는 이 서로 다른 포맷간의 메시지에 대한 변환 작업을 수행해 주는데, 이 각 변환 작업은 XQuery 또는 XSL을 이용해서 두 개의 서로 상이한 메시지를 변환해준다. ALSB에서는 직접 XQuery나 XSL을 사용해도 되지만 좀 더 쉬운 작업을 위해 XQuery를 자동적으로 생성해주는 XQuery Mapper를 제공한다.


<화면 1>과 같이 Source 포맷에서 Destination 포맷으로 간략하게 화살표만 연결해주면 이 변환을 위한 Xquery를 자동으로 생성해주고, 바로 Xquery Mapper에서 해당 Xquery 문장을 테스트해볼 수 있다. 이렇게 생성된 XQuery문장을 ALSB에 입력만 하면 ALSB에서는 해당 메시지에 대한 변환 작업을 수행한다. 맵핑에 의한 단순한 변환 이외에도 ‘If~Then~Else’ 문장이나 FOR문과 같은 루프 문장과 함수 정의 등을 통해 복잡한 변환을 Xquery Mapper를 통해 쉽게 구현할 수 있다.


ALSB를 이용한 메시지 라우팅


메시지 라우팅이란 클라이언트가 ALSB의 특정 서비스를 호출하였을 때 특정 조건에 따라 호출할 대상에 연결해주는 기능이다. 외부에 여러 서비스가 있을 때 클라이언트에서 전달된 데이터 값에 따라서 특정 서비스를 호출하거나 또는 ALSB 내부의 서비스를 호출할 수 있도록 정의할 수 있다.


<화면 2>는 ALSB로 입력되는 메시지에서 body라는 필드의 값이 25000 이상일 경우에는managedLoanReviewService의 processLoanApp 서비스를 호출하도록 하고, 다른 경우에는 normalLoanProcessor의 processLoanApp 서비스를 호출하도록 ALSB에서 설정한 것이다.


ALSB와 서비스 연결


ALSB에서는 HTTP/SOAP으로 웹 서비스화되어 있는 시스템뿐만이 아니라 FTP, SMTP와 같은 여러 형태의 통신 프로토콜과 SOAP 뿐만이 아닌 일반 XML, MFL, TEXT, 바이너리와 같은 메시지 포맷을 지원한다. 즉 SOAP 메시지를 FTP로 전송하거나 일반 XML 기반의 메시지를 이메일로 전송하는 것과 같은 방법을 이용해서 서비스 연동이 가능하다. 또한 기존의 레거시 시스템(메인프레임, SAP, 시벨 등)과 연동할 수 있는 인터페이스를 제공함으로써 현존하는 모든 시스템과 연계하여 SOA 서비스를 구축할 수 있도록 해준다.



<화면 2> ALSB에서 라우팅 설정


지원 메시지 포맷 타입
ALSB를 호출하는 클라이언트나 ALSB에 의해 호출되는 서비스들은 일반적으로 다음과 같은 메시지 포맷을 이용해서 메시지를 전달할 수 있다. ALSB에서 제공하는 통신 프로토콜과 포맷을 정리해보면 다음과 같다.


◆ SOAP and SOAP with attachment
◆ XML and XML attachment
◆ Email with attachment or without attachment
◆ JMS(WebLogic JMS뿐 아니라 MQ, JMS/XA 지원 가능, 트렌잭션 보장)
◆ MFL(Message Format Language)
◆ RawData


지원 프로토콜
ALSB에서 호출하는 클라이언트나 호출되는 서비스들은 다음과 같은 프로토콜을 이용해서 서로 메시지를 주고받을 수 있다.


◆ 파일
◆ FTP
◆ HTTP/HTTPS
◆ JMS(MQ, JMS/XA, JMS)
◆ 이메일(POP/SMTP/IMAP)


웹 서비스화가 되어 있지 않거나 웹 인터페이스가 제공 불가능한 기존 시스템의 경우 이메일이나 FTP와 같은 전통적인 통신 프로토콜을 이용하여 연동이 가능하기 때문에 기존 시스템에 대한 연결성을 극대화할 수 있다.


레거시 시스템과 연동
ALSB는 이외에도 기존 시스템을 웹 서비스화 되지 않고 그대로 연결하고자 할 때 IBM CICS(Customer Information Control System : 고객 정보 관리 시스템), SAP, 시벨 등과 같은 레거시 시스템과 오라클, LDAP와 같은 데이터 소스들에 대한 연결 아키텍처를 제공한다. 기존 시스템들의 경우 J2CA 표준 기반으로 개발된 BEA I-way adapter를 통해 기존 시스템의 서비스들을 서비스화하여 ALSB에 바로 연결할 수 있으며, 오라클과 같은 데이터베이스나 LDAP과 같은 데이터 저장소의 경우에는 로직이 없는 단순 데이터 저장소이기 때문에 어떤 서비스의 형태를 지니지 않는다.


이런 데이터 저장소를 쉽게 서비스화하기 위해서는 BEA 아쿠아로직 데이터 서비스를 이용하면 이런 데이터들을 서비스화할 수 있다. 서로 다른 데이터 저장소들을 하나의 저장소처럼 묶어 처리가 가능하다(즉 오라클, 넷스케이프 LDAP, DB2 들의 데이터를 아쿠아로직 데이터 서비스를 통해 조인하여 마치 하나의 데이터 저장소처럼 select,update 등을 할 수 있고 이런 쿼리들을 마치 하나의 기능처럼 웹 서비스화 할 수 있다).


다시 설명하면 일반적인 ESB들은 ESB와 연결하기 위해서 웹 서비스 표준 규약인 HTTP/SOAP를 준수하여 서비스화가 되어 있어야 한다는 것을 전제로 했다. 그러나 기존 시스템들을 웹 서비스화 한다는 것은 많은 시간과 노력이 들어가는 작업이다. ALSB에서는 기존 시스템에 대한 별도의 변환이나 작업이 없이도 기존 시스템의 데이터 포맷과 통신 프로토콜에 상관없이 모든 시스템을 최소한의 노력으로 ESB와 연결하여 SOA 시스템을 구축할 수 있도록 해준다.


ALSB 메시징


ALSB의 메시지 전달 방식에는 동기, 비동기, 배포/구독 등 세 가지 방식이 있다.


동기 호출(Sync) : 클라이언트에서 ALSB를 호출한 후에 응답이 올 때까지 클라이언트가 대기하는 형태가 sync 방식으로 일반적인 서비스 호출이 이에 해당한다.

비동기 호출(Async) : 클라이언트에서 ALSB를 메시지를 전송한 후 클라이언트는 응답을 기다리지 않고 다른 작업을 수행하다가 ALSB에서 메시지 처리가 끝난 후 응답이 오면 이를 클라이언트가 다시 처리하는 방식이 이에 해당한다.

배포/구독(Publish/subscribe) : 클라이언트가 ALSB로 전송한 메시지를 여러 서비스에 전달하는 것이 가능하다. 배포/구독 서비스는 각 서비스를 구독자로 정의한 후에 클라이언트에서 전달된 메시지를 구독자에게 전달하는 것이 가능하며, 전달 후에 ALSB는 서비스로부터 응답을 기다리지 않을 수 있다(비동기식).


ALSB의 에러 처리와 로깅


ALSB에서는 각 스테이지별로 로깅과 에러 처리에 대한 기능을 제공한다. 에러 처리의 경우는 에러 처리에 대한 범위를 정의할 수 있다. 즉 전체 파이프라인에 대한 에러와 각각의 스테이지별로 발생하는 에러 또는 몇몇 스테이지를 묶어서 그 안에서 발생하는 에러에 대해서 특정 에러 핸들러를 호출할 수 있다. 호출된 에러 핸들러는 에러 처리에 대한 파이프라인 프로세스를 통해서 에러에 대한 처리를 수행한다. 그리고 ESB 애플리케이션 내의 각 스테이지 별로 필요한 경우 로깅(Logging)을 추가하여 디버깅과 현재 ESB 프로세스의 작동 상태를 저장하거나 모니터링하는 것이 가능하다


ALSB의 보안


ALSB는 안전한 서비스 통합을 위해 여러 보안 기능을 제공한다. 기본적으로 SSL을 이용한 HTTP와 JMS 통신의 transport 레벨의 통신 보안을 제공하고, 메시지 자체에 대해 WS-Security를 기반으로 한 암호화 기능을 제공함으로써 메시지와 통신 레벨의 보안 양쪽을 모두 지원한다. 그 외에도 SSL을 이용한 단방향, 양방향 인증과 HTTP Basic Authentication을 이용한 인증 기능을 제공한다.


ALSB 개발


ALSB에서 ESB 기능을 구현하기 위해서는 별도의 개발이 필요 없고 간단하게 ALSB 웹 브라우저 콘솔에서 설정 정보만 입력함으로써 각 서비스들을 연동시킬 수 있다.


버전과 변경 관리
ALSB는 웹 브라우저 기반이기 때문에 동시에 여러 명이 같은 작업을 했을 때 작업 내용이 겹치는 현상(Confliction)이 발생할 수 있는데 이를 방지하기 위해서 ALSB 콘솔에는 세션이라는 개념이 적용된다. 해당 사용자가 설정 정보를 변경하고자 할 때는 세션을 생성하고 원하는 내용을 수정한다. 수정한 후에 그 변경 내용을 반영하기 위해서는 세션을 해제하면서 active시켜야 하는데 만약 다른 세션의 변경 사항과 충돌되는 부분이 있을 때는 겹치는 부분을 알려줘서 여러 사용자간 작업 내용이 겹치지 않도록 방지해준다. 또한 각각의 변경 내용에 대한 정보는 히스토리로 기록되어 만약 잘못된 변경이 있을 경우 언제든지 예전 설정 내용으로 원상복귀 시킬 수 있다.


ESB 애플리케이션의 배포 방법
ALSB에서 개발된 ESB 애플리케이션을 운영환경으로 배포하는 과정은 매우 간단하다. ALSB 콘솔에서 export를 하면 해당 ESB의 구성 정보가 JAR 파일로 생성된다. 이 파일을 운영 환경의 ALSB 서버에서 import로 읽어들이기만 하면 운영 서버에 ESB 구성 정보가 바로 반영된다.


<그림 3> ALSB와 레거시 시스템 연동 개념도


ALSB 관리 기능


모니터링
ALSB의 서비스 상태와 서버의 상태 등에 대한 작동 상태 정보는 대시보드(Dashboard)라는 형태로 실시간으로 한눈에 모니터링할 수 있다. 대시보드를 통해 모니터링할 수 있는 내용은 요약해보면 다음과 같다.


평균 수행 시간 : ALSB에서 평균 메시지 처리 시간과 외부 시스템의 평균 응답시간
총 수행 메시지 : ALSB에서 처리된 총 메시지 수
에러가 발생한 메시지 : ALSB 내부에서 발생된 에러와 연동 시스템에서 발생된 에러의 수
에러율 : 전체 메시지 중에서 에러 발생 비율
보안 에러 : 보안에 정책에 위배된 메시지 전송에 대한 오류
Validation 에러 : 전달된 메시지가 포맷에 맞지 않을 때 발생된 에러의 수
서버 상태 : 웹로직 서버의 상태(쓰레드 수, 부하상황, 트렌잭션, 메모리 상황 등 종합적인 정보)



<그림 3> ALSB와 레거시 시스템 연동 개념도


<그림 4> ALSB 클리스터 구조


ALSB는 다른 ESB와는 달리 모니터링 기능에서 SLA(Service Level Agreement) 기능을 제공한다. 이는 모니터링이 가능한 필드에 임계 값을 지정해놓고 그 임계 값을 넘으면 어떤 동작을 취하도록 설정이 가능하다. 임계 값의 설정은 Rule이라는 형태로 지정이 되는데 서비스 동작 중 특정 Exception이 발생하거나 모니터링 항목 중 어떤 값에 대한 임계 값을 정하는 것 등인데 예를 들어 응답 시간이 몇 초 이하로 떨어지거나 에러 발생 비율이 몇 %를 넘었을 때 특정 동작을 취하게 할 수 있다. 여기서 이야기하는 특정 동작이란 다음과 같다.


◆ JMS로 메시지 전송
◆ 특정 웹 서비스 호출(SMS 등의 서비스 호출)
◆ 이메일 전송
◆ 웹로직 서버로 alert 전송


이런 동작 설정은 시간대별로 설정이 가능한데, 즉 근무시간에는 이메일로 장애 내용을 전송하게 했다가 근무시간 이후에는 SMS 웹 서비스를 호출하도록 지정할 수 있다.


UDDI 연동
ALSB에 등록된 각종 서비스들은 ALSB를 통해 웹 서비스 형태로 호출이 가능하기 때문에 UDDI에 등록되어 서비스될 수 있다. ALSB는 UDDI 버전 3와의 연동을 지원한다.


ALSB 클러스터 구성


ALSB를 구성할 때 있어 ALSB는 고가용성과 부하분산을 위한 클러스터링 기능을 제공한다. ALSB 클러스터는 관리 서버 1개와 여러 개의 작업 서버들로 구성되며, 모든 설정 정보는 중앙의 관리 서버에 의해 관리 유지된다. 각 설정 정보는 관리 서버에 의해 각 작업 서버로 배포 및 유지된다.


ALSB 서버는 각각의 작업 서버 인스턴스만 추가하게 되면 수평적으로 클러스터를 무제한적으로 확장할 수 있기 때문에, 처음에 작은 규모로 시스템을 구성하더라도 서비스 양에 따라서 쉽게 서버만 추가함으로써 시스템을 확장할 수 있다.


ALSB 클러스터는 JMS나 HTTP단의 부하 분산 기능을 제공하고 있으며, 각 서버 인스턴스가 장애시에 다른 서버가 그 요청을 받아서 처리하는 페일 오버(Fail over) 기능을 지원함으로써 무장애 서비스를 구현할 수 있도록 지원한다.


적용 사례, 주문형 웹 서비스 포탈


A사는 중소기업들이 IT 솔루션의 높은 초기 도입 비용과 지속적인 유지비용의 부담 때문에 제대로 된 정보화 환경을 혜택을 누리고 있지 못하고 있다고 판단했다. 따라서 IT 기술의 도입을 통하여 기업 경쟁력과 업무 효율성을 높일 수 있도록 하기 위해 임대 방식의 표준화된 솔루션을 제공하는 애플리케이션 서비스 제공자(Appli cation Service Provider, 이하 ASP) 사업을 하고 있으며 현재 ERP, CRM, 그룹웨어, SCM 등 30여개 애플리케이션을 제공 제공하고 있다. 이 과정에서 A사는 기존 단문 메시지 전송, 인터넷 팩스 등 단순 ASP 형태에서 서비스의 조합을 통한 새로운 부가 서비스의 요구에 빠르게 대응하기 위해 조합형 웹 서비스의 제공하게 되었으며 이를 위한 웹 서비스 기반의 주문형 서비스 시스템(Service On Demand)을 구축하게 되었다.


주문형 서비스는 고객이 원하는 기능과 관계된 서비스를 연계하여 새로운 부가가치 서비스를 제공을 목적으로 하고 있다. 이러한 주문형 서비스를 통해 다양한 서비스/컨텐츠 제공자의 웹 서비스를 결합하여 새로운 서비스를 제공하며, 필요로 하는 솔루션을 직접 개발 또는 구매시 발생할 수 있는 시간, 비용 및 위험성을 이미 검점된 서비스를 통해 위험 요소를 제거하며 서비스를 사용한 만큼만 지불할 수 있도록 하고 있다


<그림 5> A사의 조합 서비스 개념


<그림 6> A사 주문형 서비스 개념도


예를 들어, 고객은 CRM과 인터넷 팩스 서비스를 결합하여 CRM 시스템 상에서 쉽게 인터넷상에서 팩스 서비스를 사용할 수 있게 되었다. CRM 시스템의 입장에서는 기존 잘 개발된 팩스 시스템을 활용하여 웹 서비스로 서비스를 연동하고 관리하게 되면서 비용을 절감하면서도 CRM의 기능을 극대화 할 수 있게 되었다. 또한 A사는 CRM, 빌링 등의 핵심 시스템은 자사가 서비스하면서도 SMS, FAX 등 부가 서비스는 써드파티 솔루션을 적극적으로 통합함으로서 수준 높은 부가 서비스를 제공할 수 있게 되었다.


A사의 주문형 서비스 시스템은 다양한 사용자 단말 환경에 최적화된 컨텐츠를 제공하는 포탈 플랫폼, 전자상거래, 기업간 협업, 특화 시스템과의 연동을 위한 B2B 통합 허브 시스템과 빌링 시스템, CRM 시스템과의 통합을 위한 EAI 플랫폼을 기본으로 하며 웹 서비스 저장소(UDDI), 웹 서비스 모니터링, 웹 서비스 버스 및 기타 서비스의 웹 서비스화를 위한 플랫폼으로 구성되어 있다.


A사의 주문형 웹 서비스 플랫폼은 기존 CRM과 빌링 데이터 및 애플리케이션의 웹 서비스화를 위해 WLI(WebLogic Integration), 데이터 및 애플리케이션의 웹 서비스화를 위해 ALSDP(Aqua Logic Data Service Platform), 비즈니스 서비스의 저장소 기능을 위해 ALSR(AquaLogic Logic Service Registry), 고객, 서비스 제공자, 관리자 포탈을 위해 WLP(WebLogic Portal)를 사용하고 있으며, ALSB는 서비스의 라우팅, 메시지 변환, 데이커 검증, 모니터링, 버전 컨트롤, 연결 캐싱, 인가되지 않은 요청으로부터 서비스 보호의 역할을 수행한다.


전사 통합 IT를 위한 인프라


가트너 그룹에 따르면 2007년에는 모든 애플리케이션 개발 프로젝트의 1/3 이상이 ESB를 사용할 것이라고 한다. 또한 거의 모든 기업들이 당면 비즈니스 과제를 해결하기 위해 전사적인 SOA를 채택할 것이라고 한다. ESB와 SOA가 비즈니스 프로세스의 변화에 유연하고 신속하게 대응할 수 있는 IT 인프라를 구현하는 핵심 미들웨어 플랫폼으로 대두되고 있는 것이다.


앞선 A사의 사례와 같이 ESB는 이제까지의 애플리케이션 인프라를 통합하여 비즈니스 서비스로 전사 IT 환경을 점진적으로 개선해 나가고 있다. 이제 기업 환경은 단순히 서비스 버스를 위한 미들웨어만의 도입이 아닌 SOA 기반의 애플리케이션 아키텍처를 포함한 전사 통합 IT 인프라로 발전해가고 있는 것이다.

반응형
Comments