블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

API 플랫폼에 대한 소개

아키텍쳐 /대용량 아키텍쳐 | 2013.10.30 01:02 | Posted by 조대협

API Platform

조대협


근래에 들어서 모바일 애플리케이션의 발전과 SNS의 발전과 더불어서 Open API 에 대한 관심도가 급격하게 높아졌다. Open API, API를 내부 사용자뿐만 아니라 외부 개발자에게까지 공개해서, 외부 개발자가 API를 이용해서 새로운 서비스를 만들도록 하는 모델이다. 근래에 들어서는 API만 전문적으로 개발 및 서비스를 해서 이를 통해서 수익을 창줄하는 비지니스 모델까지 생겨나고 있다. 이런 배경으로 API 관리에 대한 중요성이 대두되었는데, API에 대한 쉬운 관리, 모니터링 및 유료화 그리고, API에 대한 편리한 사용법, 샘플 코드 및 메뉴얼 제공하는 시나리오가 필요하게 되었는데, 이를 하나의 플랫폼 형태로 묶어 놓은 것을 API 플랫폼이라고 한다.

API 플랫폼은 크게, API에 대한 단일 진입 포인트 역할을 하는 게이트 웨이와, API 문서나 샘플 코드들을 제공하는 API 포탈, 그리고 API 서비스 상황을 모니터링할 수 있는 관리 모니터링 기능으로 분리된다.

제품군으로는 크게 두 가지 종류로 나뉘어 지는데, 예전 SOA(Service Oriented Architecture) ESB (Enterprise Service Bus) 를 게이트웨이로 사용하면서 발전해온 SOA 진영쪽 제품과, 처음부터 API 플랫폼으로 디자인되서 서비스되는 이 양쪽으로 나뉘어 진다. 전자의 경우에는 MuleSoft WSO2 API 플랫폼이 대표적인 예이고, 후자의 경우에는 apigee,3scale,Mashery,Layer 7(CA) 등이 있다. 전자의 경우에는 ESB를 기반으로 하기 때문에, API에 대한 워크 플로우 기능이 매우 강력하다. 워크플로우 기능이란, 메세지를 변경하거나 라우팅 또는 다른 기능을 추가하는 부분이 매우 강력하다.반면 포탈이나 모니터링 기능들은 후자에 비해서 약하다. 후자의 경우에는 워크 플로우 기능은 약한 반면, 유료화 모델이나 다양한 사용자 계층 지원 그리고 무엇보다 포탈이 매우 강력하다.

Apigee Mashery 같은 경우는 설치형이 아니라 클라우드 형으로 서비스를 제공하는데, 개발사나 개발자가 API를 개발하고, API 서비스는 클라우드에 설치된 이 API 플랫폼을 통해서 하면, 이 플랫폼이 중간에 Gateway 역할로써 API에 대한 워크플로우 기능 및 모니터링 기능등을 제공하면서 함께, 포탈등의 부가 기능을 제공한다.

예전에 미국 캘리포니아 실리콘 밸리에 있는 apigee 를 방문할 일이 있었다. 긴 시간은 아니었지만, 서비스와 인력들에 대해서 이야기를 나눌 기회가 있었는데, 재미있는 점은 인력 구성원의 많은 인원들이 기존의 SOA 회사 출신(BEA)으로 이루어져 있다는 것이다. API 서비스의 근간은 SOA를 기반으로 하고 있으며, 기술 역시 SOA ESB와 연관된 기술을 많이 사용함으로 이해할 수 있었다. 회사의 분위기는 여타 실리콘 밸리의 회사와 같이 매우 젊고 활기에 차있었다.

API 플랫폼을 서비스로 제공하는 만큼 운영에 대해서 많이 신경을 쓰고 있었는데, 실제로 플랫폼을 서비스로 제공하면서 얻는 노하우는 대단하리라고 본다.

 

주요 기능



API 인증

먼저 API를 사용하려면, API를 호출하는 클라이언트가 인증이 된 사용자인지 아닌지를 구분할 수 있는 인증 Authentication 기능이 필요하다. 앞에서 REST API 보안에서 설명한것 처럼, API Key를 발급하거나 OAuth 기반의 인증을 제공할 필요가 있다. 근래의 API Platform OAuth 기반 인증을 제공하는 것이 일반적인 흐름이다.

사용자 인증

사용자 인증은 API 인증을 받기 위한 Key OAuth 인증을 받거나, 또는 API 포탈에 접속해서 메뉴얼을 보거나 Admin 으로써, API에 대한 모니터링을 하기 위해서 필요한 시나리오이다. 사용자를 API를 사용하는 일반 사용자, 내부 관리자 또는 일반 사용자/Silver/Gold 등의 레벨로 나눠서 서비스를 하는 등의 다양한 서비스 시나리오에 대한 사용자 관리 기능을 제공한다.

SLA management

SLA Service Level Agreement의 약자로, 서비스에 대해서 약속한 수준의 비기능 요건을 만족해주는 것을 이야기 한다. 쉽게 이야기 해서, API 제공자별로 하루에 5000건의 call을 제공하기로 했으면, 5000건 까지만 제공한다던지, API 사용자별로 하루에 1000건의 call을 제공한다던지의 계약 레벨별로 서비스 수준을 조정해줄 수 있는 기능을 제공한다.

Mediation

Mediation은 들어온 API 호출에 대해서 변형을 가하는 것이다.예를 들어 원래 API가 주문 API였다면, 나중에, 주문 API에 포인트 적립 API를 추가해준다거나 API version에 따라서 라우팅을 해주거나 하는 등의 기능을 한다. 이렇게 원래 호출 내용에 대해서 변경을 가하는 것을 Mediation이라고 한다. 그러면 몇가지 Mediation 패턴에 대해서 소개한다. 이런 Mediation 패턴은 앞서 설명한 Workflow 기능에서 제공되며, 이 챕터의 뒤에서 소개할 SOA 아키텍쳐의 ESB의 부분을 참고하면 좋다.

아래는apigee 플랫폼에서 workflow를 적용하는 UI 화면의 일부이다. 보통 workflow IDE같은 개발환경에서 순서도 같은 흐름에 노드를 추가하는 환경으로 적용한다.



출처 : https://blog.apigee.com/detail/api_platform_update_api_proxy_editor_traffic_composition_reports_updated_policies

 

Routing

들어온 메세지에 대해서 라우팅 작업을 한다. 예를 들어서 결재 시나리오에서 API request 필드에 국가 필드가 나뉘어져 있으면, 국가 필드에 따라서 API를 그 국가의 서버로 라우팅을 하거나, 헤더에 정의된 API버전에 따라서 구 API서버나 새로운 버전의 API서버로 라우팅 하는 시나리오를 예로 들 수 있ㄷ.

Function adding

이 기능은 기존에 있던 API 기능에 새로운 기능을 추가하는 것이다. 예를 들어 기존 구매 프로세스에서 포인트 적립 기능을 추가해주는 것등을 할 수 있다. 기존의 클라이언트나 서버의 구현의 변동없이 새로운 기능을 추가할 수 있다.

Message Transformation

메세지 변경은 들어온 메세지를 다른 포맷으로 변경해주는 것이다. 단순하게는 JSON XML로 변경해준다거나 필드가 틀린것을 맵핑 해준다거나 두 필드를 한필드로 합친다거나 반대로 한필드를 여러 필드로 나눈다거나 하는 등의 기능을 제공 한다.

Monitoring

모니터링은 API 서비스 사업자로써 아주 중요한 위치를 차지하는데, API의 사용량, 어떤 API가 많이 사용되는지, 국가별, APP별 통계량이나 평균 응답 시간등에 대한 리포트는 서비스의 정상적인 상태 체크 뿐만 아니라 향후 API 서비스 개발에 유용하게 사용될 수 있다. 아래는 apigee에서 제공하는 API Traffic 모니터링 화면이다.



출처 : http://apigee.com/docs/enterprise/content/monitor-performance-your-api

 

Monetization

Monetization은 쉽게 이야기 해서 유료화 모델이다. API의 과금 정책 월단위, 사용자 단위, 호출 단말건,호출 건수별 등 다양한 정책을 적용할 수 있다. 이에 더해서 이벤트 가격 적용, 또는 사용자 수나, API 호출 수를 구간 별로 나눠서 금액을 책정하는 등의 다양한 가격 정책을 적용할 수 있는데, 이를 Charging이라고 하며, Charging을 하기 위해서는 누가? 어떤 디바이스가 언제? 어떤 API를 호출했는지 등의 Charging을 하기 위한 기초 로그 데이타를 수집하고, Charging이 끝난후에, 신용카드등을 통해서 Payment를 하게 되면, 서비스 국가에 따라서 세금을 내는 Taxation 그리고 세금을 땐 수익을 다시 API 제공자에게 분배 하는 정산 (Pay out)등의 인프라를 제공한다.

Portal

포탈은 API 사용자가 로그인을 한 후, API에 대한 사용법이나 샘플 또는 테스트 등을 할 수 있는 기능등을 제공한다. API를 만드는 것도 중요하지만 편이성을 제공해서 API사용자가 잘 사용할 수 있데 하는 것이 중요하다.

단순하게 메뉴얼 뿐만 아니라 API사용자 입장에서 얼마나 API를 사용했는지 어떤 API가 많이 호출되었는지등의 자료는 API 사용자 입장에서도 과금에 관련되고 또 향후 서비스 개선을 위한 중요한 자료이기 때문에, API 포탈의 기능은 매우 중요하다.

외부 API 사용자를 위한 기능도 있지만, API를 판매하지 않고, 내부에서 다른 부서에 API를 제공하기 위해서도, 쉽게 API를 사용할 수 있게 함으로써 개발 생산성을 높일 수 있다.

만약에 API 메뉴얼 또는 테스트 사이트를 제공하고 싶은 경우에는 Swagger 라는 오픈소스를 참고해보기를 권장한다. https://github.com/wordnik/swagger-core

Swagger API에 대한 메뉴얼 자동 생성 및 테스트 사이트 생성 기능을 제공한다. 아래는 Swagger에 의해서 생성된 API 메뉴얼 사이트 인데, API에 대한 사용법 및 샘플 데이타를 제공하고, 무엇보다 테스트 호출을 날려볼 수 있는 기능을 제공한다.



출처 : http://swagger.wordnik.com

API Governance

이런 API Platform을 사용함으로써 얻게 되는 부가적인 이득은 API 에 대한 관리이다.

내부적으로 API를 사용하면 가장 크게 문제가 되는 것은 API에 대한 관리인데, 여러 부서가 일을하는 경우, API 의 메세지 포맷이나 API URL Naming convention이 다른 일이 발생한다. 특히 SOA 시절의 WSDL 기반의 WebService를 사용하면 최소한의 표준 준수가 가능했으나 (WebService 자체가 표준이다.) REST/JSON의 경우 WSDL과 같은 메세지 포맷에 대한 표준 자체가 없기 때문에 자유도가 증가하여 표준화가 매우 어렵다.

예를 들어 A부서는 version URI에 넣어서 http://myapi/adduser/version3 와 같은 식으로 서비스하거나, B부서는 version HTTP header에 넣어서 http://myapi/addorder URI로 제공하고http headerx-myapi-version:3 식으로 넣어서 같은 회사인데도 API 메세지 포맷에 대한 통일 성을 읽어 버릴 수 있다.

API플랫폼을 사용하면, 서비스 되는 API는 모두 API 플랫폼을 통해야 함으로 API 플랫폼 관리 조직이 API가 표준에 맞지 않으면 API 플랫폼을 통해서 서비스 하는 것을 거부할 수 있으므로, API 표준 준수를 강요할 수 있는 강제성을 통한 통제성을 확보함으로써 API를 중앙에서 집중 관리할 수 있는 장점이 생긴다.

 

Apache Camel Overview

아키텍쳐 /EAI | 2013.02.17 00:43 | Posted by 조대협

조대협 (http://bcho.tistory.com)

서문

예전 BEA나 오라클 시절에, EAI, ESB 등을 가지고 시스템간의 연계 업무를 많이 해왔던 나로써는 오픈 소스 기반의 EAI 프레임웍인 Apache Camel의 경우 상당히 흥미로운 주제였다. 과연 상용 제품 대비 얼마나 현실성있는 integration 기능을 제공할 것인가? 가 가장 큰 궁금증이었다.

BEA WebLogic EAI, Oracle Service Bus, AIA 등 여러 제품을 이용해서 직접 시스템간의 연계 시나리오도 구현해보고, BMT에서 타의 솔루션을 테스트도 해봤지만, 먼저 상용 솔루션의 약점은, 솔루션에서 제공하는 시스템간의 연계에 있어서 성능적인 제약이 매우 많이 따른 다는 것이다. 대부분 Message Queue 구조의 비동기 구조를 통해서, 양단간에 데이타 연계를 하는 시나리오가 많은데, 이 경우 비주얼하게 각 단계에 대해서 모니터링은 가능 하지만, 대규모 처리에 있어서 비동기의 약점 때문에 성능적인 제약이 따르고 특히 대규모 메세지 처리에 있어서 그리 매끄럽지 못했던 경험이 있다. BPEL과 같은 제품의 경우 양단간의 연동 시나리오중, 개개별 메세지를 콘솔을 통해서 트레이스할 수 있는데, 하루에 수백,수천건을 연계하는 거래의 경우에는 GUI 콘솔을 통해서 메세지를 전달 내용이나 에러 내용을 추적한다는 것은 애초 부터 불가능한 일이다.

 그래서 실제 프로젝트 때에는 송수신 시스템을 연동하는 양쪽의 아답터 (JMS, 메인프레임, TP 모니터, ERP, CRM 등 다양한 시스템과 연동이 필요하기 때문에, 상용 제품에서 지원되는 아답터는 매우 중요하다)와 기본적인 메세지 플로우 이외의 부분은 대부분 직접 구현하였다. 그래서, EAI와 같은 제품에서 필요한 구조와 이런 것을 요구 사항에 맞게 빠르게 만들었으면 하는 프레임웍이 있었으면 했는데, Apache Camel을 보니, EAI와 같은 연계 업무성 프레임웍으로 적합해 보인다.

Apache Camel의 특징을 보면

Message Integration Framework

Camel은 기본적으로 Message Integration Framework이다. Framework임을 강조하는 것은, ESB EAI 제품과 같은 솔루션이라기 보다는 이를 개발하기 위한 Framework으로 보는 것이 적절하다고 판단된다.

이유는 ESB EAI는 메세지 연동 기능을 수행하기 위한 컨테이너가 있다. (즉 서버가 있다) 아무런 연동 인터페이스가 없더라도, 연동 인터페이스를 수용할 수 있는 컨테이너가 있고, 이 컨테이너들은 모니터링, 로깅등의 관리 기능을 제공한다. 그러나 CamelLibrary이다. 자체적으로 Container를 가지고 있지 않다. 다만, OSGI 컨테이너나 WAS, Spring등에 탑재 되서 돌아갈 수 있다. 쉽게 이야기 하면, EAI ESB와 같은 솔루션 제품은 서버를 설치해야 하고, 서버 관리를 위한 관리 콘솔 UI를 제공한다. Camel Jar로 된 라이브러리 이다.

상용 제품 연계에는 적절하지 않다.

Camel을 보면, 타 솔루션을 연동하기 위한 아답터, (Camel에서는 Component라고 부른다)가 있다. 50여개의 아답터가 있기는 하지만, 기업에서 많이 사용되는 솔루션의 아답터는 턱없이 부족하다. 예를 들어 SAP ERP, Sieble CRM, Tuxedo, AS/400 과 같은 애플리케이션에 대한 아답터 지원이 없다. 상용 제품의 경우 이런 아답터 지원이 강력하다.

반면, DB,FTP,HTTP,JMS와 같이 일반적인 애플리케이션 개발에 사용되는 기술에 대한 아답터는 많이 제공된다.

Apache Camel의 컨셉

Apache Camel의 컨셉을 대략적으로 도식화 해보면 다음과 같다.


Route

먼저 Route 라는 개념을 이해해야 하는데, Route하나의 시스템간의 연동 인터페이스를 정의한다. 예를 들어 시스템 A에서 B로 웹서비스를 이용해서 연동을 했다면 이것이 하나의 Route가 된다. Route 1:1 관계뿐만 아니라 1:N의 관계도 지원 하는데, A 시스템에서 B 시스템으로 JMS로 메세지를 보내고, 그후에 C 시스템으로 FTP 파일 전송하는 인터페이스가 있다면, 이 역시 하나의 Route로 정의할 수 있다.

Component

Route는 크게 Component Processor로 정의 된다. 연계 하고자 하는 송신 시스템과 수신 시스템이 있을때, 각 송신,수신 시스템의 주소(IP) end point라고 정의하며, Component는 일종의 아답터의 개념으로, 송수신 시스템의 프로토콜에 맞는 컴포넌트를 선택해야 한다. 예를 들어 송신 시스템을 FTP로 연동하고 싶다면, FTP 컴포넌트를 , JDBC로 연동하고 싶다면, JDBC 컴포넌트를 사용해야 한다. 컴포넌트는 송신 시스템으로 부터 메세지를 읽어드리고, 수신 시스템으로 메세지를 전송하는 역할을 한다.

Processor

메세지를 읽고 그냥 보내기만 한다면 별 문제가 없겠지만, 시스템간의 연동에는 메세지를 받은 후에 수신 시스템으로 보내기전에 하다못해 로깅을 남기더라도 무엇인가 항상 처리를 한다. 이렇게 송신 시스템으로 부터 받은 메세지를 수신 시스템에 보내기전에 무엇인가 처리를 하는 부분을 Processor라고 하는데, Processor는 그 특징에 따라서 몇가지로 나뉘어 질 수 있다.

1. Message Transformation

Message Format Transformation

메세지의 포맷을 변경하는 작업을 수행한다. 예를 들어 JSON으로 들어온 데이타를 XML로 변경하는 것들이 이에 해당한다.

Message Type Transformation

메세지의 데이타 타입을 변경한다. String으로 들어온 메세지를 jms:TextMessageType으로 변경하는 등의 작업을 수행한다.

이러한 메세지 변환은 Java Class를 정의해서할 수 있으며, 이외에도 Camel에서 미리 제공되는 Converter, XSLT를 이용한 변환 Apache Velocity의 같은 Template 엔진등 다양한 방법을 이용해서 변환이 가능하다.

2. Routing

메세지 라우팅은 들어온 메세지를 다수의 수신 시스템에 조건에 따라서 라우팅할 수 있는 기능이다.


Processor 단계는 쉽게 생각하면, 메세지를 받은 후, 보내기전에 무엇인가.. 를 하는 곳이다. 앞서 설명한것처럼, 메세지를 변환하거나, 라우팅할 수 도 있고, 로깅을 할 수도 있다. 들어온 메세지에 대해서 유효성 검증을 할 수 도 있다. 이러한 Processor는 자주 사용되는 메세지 변환등의 패턴은 Camel에 의해서 제공되지만, Java 클래스를 구현하면, 무엇이든지 가능하기 때문에 메세지에 대한 거의 모든 처리를 구현할 수 있는 단계이다.

 

이렇게, “송신 Component à Processor à 수신 Component”로 하나의 Route가 정의되는데, 이렇게 Route를 정의하여 객체화 시키는 것이 RouteBuilder이다. 이렇게 RouteBuilder에 의해서 생성된 Route CamelContext에 바인딩이 된다. CamelContext SpringContext와 유사한 개념으로 생각하면 된다. Route에 대한 집합이며, Route에 대한 라이플 사이클 (Start up,Stop)등을 관리한다.

간단한 개발 예제

이쯤에서 간단한 예제를 하나 보자. 다음은 FTP로 원격지 디렉토리의 파일을 읽어서 Local Directory에 쓰는 Camel Application이다.

먼저 Maven을 이용해서 다음과 같이 Camel Project를 만든 후에,

mvn archetype:create -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-java -DarchetypeVersion=2.5.0 -DgroupId=camelinaction -DartifactId=order-router

다음과 같은 코드를 구현한다.

public class MyRouteBuilder extends RouteBuilder {

    public static void main(String... args) throws Exception {

        Main.main(args);

    }



    public void configure() {

        from("ftp://userid@168.1.2.3/camel/src/?password=password&stepwise=false")

         .to("file:c:/temp/");

 

    }

}

위의 코드는 RouteBuilder를 구현한 코드로 configure 메서드에서 FTP로 파일을 읽어와서 Local에 저장하는 route를 정의한 예이다.

DSL

눈치가 빠른 사람이라면, 위의 코드가 몬가 이상하다는 것을 느꼈을지도 모르겠다. configure 메서드안에 from(“….”).to(“….”).??

함수().함수() 호출? Java에서 이런 문법이 있었던가?

정확히 이야기 하면 이건 일반적인 Java Coding이 아니라 DSL (Domain Specific Language)이다. DSL은 특수목적으로 정의된 언어를 이야기 하는데, 여기서 사용된 Java DSL Route를 효율적으로 정의하기 위해서 Camel에 정의된 내장 스크립트 언어이다.

JavaDSL을 이용하면 상당히 쉽게 Route를 구성할 수 있는데, Camel은 이 Java DSL 뿐만 아니라, 다음과 같이 상당히 다양한 DSL을 제공한다.

Ÿ   Spring XML : XML 기반으로 정의된 DSL , Spring xml configuration 파일에 정의

Ÿ   Groovy,Scala DSL : Groovy 언어, Scala 언어 기반의 DSL

Ÿ   Annotation DSL : Java Annotation 기반의 DSL

Ÿ   기타 (Kotlin DSL, Bluprint XML etc)

(참고: http://camel.apache.org/dsl.html)

DSL Route Processor 부분을 정의하는데 주로 사용되는데, 송수신, Component만 정의되면, 사실상 시스템 연계에서 구현해야 되는 부분은 거의 Processor이며, Processor의 로직 대부분은 메세지 처리, 변환,라우팅에 해당하는 내용이기 때문에 특수목적의 DSL을 사용할 수 있으며, 또한 DSL 사용을 통해서 개발 생산성이나 코드양을 획기적으로 줄일 수 있다.

예를 메세지를 스트링으로 받아서 reverse하여, 화면에 출력하는 경우 Java DSL을 이용하면

from("direct:test")

      .transform(new Expression() {

         @Override

         public Object evaluate(Exchange e) {

            return new StringBuffer(e.getIn().getBody().toString()).reverse().toString();

         }

      })

      .process(new Processor() {

         @Override

         public void process(Exchange e) {

           System.out.println(e.getIn().getBody());

         }

      });

인데 반해서, Groovy DSL을 사용하면

from('direct:test')

      .transform { it.in.body.reverse() }

      .process { println it.in.body }

같이 단지 3줄이면 간단하게 끝난다.

Camel EIP

시스템 연동에는 사실 많은 패턴들이 있다. 메세지 변환, 라우팅, 로그 추적을 위한 글로벌 트렌젝션 ID, 장애시 재처리등등 여러가지 방법이 있는데, 이를 패턴화 시켜놓은 것이 Enterprise Integration Pattern (EIP)이다. EIP


책에 잘 정의 되어 있으니 참고하기 바란다.

사실 Camel에서 반영 및 설계되어 있는 EIP도 이 책에 있는 내용을 대부분 바탕으로 하여 구현되어 있다. (Camel을 쓸려면 이책은 꼭 한번 읽어봐야 하지 않을까 싶다.)

 

참고 : http://camel.apache.org/enterprise-integration-patterns.html 에 간단하게 대표적인 EIP 들이 정리되어 있다.

상용 지원

오픈소스가 무료이라서 저 비용의 장점을 가지고 있지만, 반대로, 오픈소스는 기술지원이나 교육 부분에서 매우 취약하다. 그래서 RedHat과 같이 오픈소스 제품에 대해서 subscription base로 기술 지원이나 교육 및 컨설팅을 제공하는 회사들이 존재하는데, Apache Camel 역시 http://fusesource.com/ 는 곳에서 상용 기술 지원을 받을 수 있다. (얼마전에 Redhat에 인수되었다.) Fuse Source의 경우, Camel을 이용하여 제품을 만들어서 판매하고 있으며, Camel 프로젝트에 참여하고 있는 Commiter 들을 많이 보유하고 있다고 한다.

http://fusesource.com/products/enterprise-camel/ 들어가면 Fuse Source에서 개발 및 판매하는 상용 Camel을 다운로드 받을 수 있으며, 개발 관련 및 트레이닝 자료들을 살펴볼 수 있다.

결론

짧은 시간내에 살펴본 제품이라서 아직 완벽한 특성은 파악하지는 못했다. 그러나 EAI, ESB와 같이 메세지 기반의 연동 처리를 하기 위한 시스템을 개발한다면, 개발 프레임웍으로 충분히 활용할만 하다. 특히 엔터프라이즈의 특정 애플리케이션 (ERP,CRM)등이 아니라 일반적인 프로토콜 (HTTP,JMS,TCP)등을 사용하여 그리 복잡하지 않으면서 고속의 연동 처리를 필요로 한다면 아주 유용하게 사용할 수 있을 것이라 판단된다.

시간 관계상 에러처리, 모니터링, 배포 및 확장성등 운영 관점에 대한 부분은 깊게 살펴보지 못했지만, 그냥 개발 프레임웍으로 본다면, 어짜피 운영 관련 부분은 직접 구현해야 하니까는 괜찮지 않을까 싶다.

다만 단순히 프레임웍이기 때문에, 클러스터링 기반의 HA나 부하 분산등의 기능을 제공하지 않는 것이 아쉬운 점이다.

시스템간의 연동의 중요성과 편이성을 경험한 나한테는, Apache Camel물건은 물건이다.” 라는 결론이 적절하다고나 할까?

 

ErrorHandling - http://bcho.tistory.com/716


참고:ErrorHandling에 대한 관련글 -

http://www.consulting-notes.com/2010/08/camel-exception-handling-overview.html 

정리가 잘되어 있네...

 

'아키텍쳐  > EAI' 카테고리의 다른 글

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (1) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21

Oracle Coherence나 Open source memcached와 같은 메모리 그리드 솔루션은 아키텍쳐를 그리는 데 상당한 효과를 발휘한다. 메모리 그리드랑, 간단하게 이야기 하면 Java의 HashTable이 무제한 용량으로 확대 가능하고, 어느 server instance에서도 접근이 가능하며, 장애시 Fail over를 통해서 고가용 서비스가 가능한 솔루션을 이야기 한다.
물론 Oracle Coherence가 .NET도 지원하기는 하는데, 이왕이면 MS도 이런게 있었으면 했는데, 새 윈도우즈 Server에 나왔다.
AppFabric이라는 일종의 윈도우즈 미들웨어인데, 일단  데이타 그리드의 성격을 가지고 무제한 클러스터링이 가능하다.. (물론 열어봐야 알겠지만..)

데이타 그리드로써도 의미가 있지만, ASP.NET은 기본적으로 Http Session Clustering을 지원하지 않았기 때문에, 이 Data Grid를 이용하면 WebLogic이나 WebSphere와 같은 Session Clustering을 지원할 수 있다. (그것들 보다 지능적이게 만들려면 개발은 좀 들어가겠지만...)

아울러 AppFabric은 ESB Feature를 제공하는데, WCF (Windows Communication Foundation - 일종의 통신 Framework)과 WF (Workflow Foundation - 워크 플로우)를 통해서 비지니스 프로세스를 그리고 배포할 수 있다.  WF와 WCF 기반의 코딩이 들어가야 하는 미들웨어성에 가까운데, 대신 코딩을 하는 만큼 오히려 성능이나 아키텍쳐 구성에는 유리한면이 있을듯 하다.
Oracle Service Bus가 높은 가격과 고수준의 XQuery/XSL 기술이 있어야 한다면, 상대적으로 좀더 Flexible하게 고성능 ESB를 디자인할 수 있을듯.
기본적으로 IIS는 Java의 WAS처럼 Thread Base 모델이 아니라 Process Base 모델이기 때문에, Hot Deploy나, 장애 전파 영향도는 낮을 듯 하다.

AppFabric이 나오면서 기존의 ESB 역할을 해주던, BizTalk의 Postion이 애매해지는데, David Chappel의 AppFabric WhitePaper를 보면

As the figure shows, an activity in the workflow service can issue a request to BizTalk Server. This might be done using a Web service or in some other way; BizTalk Server provides adapters for several different communication styles. However it’s accomplished, the request can then be handled by business logic running in BizTalk Server. This logic is implemented as an orchestration, and it knows how to carry out the next step in this process. Here, for instance, the orchestration uses another BizTalk adapter to communicate directly with the ERP application. Any response can be sent back through the same components.

출처 : http://download.microsoft.com/download/7/F/8/7F8BD8A0-EB05-4DB5-A5A4-DD1D3C909A0A/Introducing_Windows_Server_AppFabric.pdf


AppFabric이 전통적인 ESB 역할을 하면서 Service Orchestration등을, BizTalk는 EAI 또는 SOA에서 Service Enablement Layer처럼, Legacy 시스템들을 Itnegration해서 Expose하는 역할로 포지셔닝이 된다. (참고 : http://wm.microsoft.com/ms/msdn/windowsserver/WFDemoFinalHighRes.wmv )


일단 1 core에 몇천만원이나 하는 Service Bus보다, MS의 AppFabric은 단돈 몇백만원에 OS에 포함되어 있고, 개발 용이성도 높으니, REST와 함께해서 아키텍쳐를 한번 조합해봤으면 좋겠는데..

혹시.. 사이트에 좀 불러주실분...??? 손!! :)

OO 차세대 시스템

WAS Architecture Blue Print (DRAFT)  

2009-06-28

Oracle Korea Consulting

Principal Consultant

Byungwook Cho (byungwook.cho@oracle.com)

 

 

Overview

본 아키텍쳐는 OO 차세대 시스템을 위한 웹로직 구성 아키텍쳐이다. OO 아키텍쳐 요구 사항에 따라서 구성한 아키텍쳐로 다음과 같은 전제 조건을 기반으로 한다. Ÿ          웹로직을 중심으로 설계할것           클라이언트는 웹이 아닌 윈도우 애플리케이션을 사용한다.

    100개의 웹로직 인스턴스가 동시 운영 될것으로 예측된다.         총 업무는 A업무 (4개), B관리 (4개), C관리 (4개) 로 구성된다.Ÿ          하드웨어는 IBM P6 시리즈를 사용하며, 총 예상 CPU수는 52장이며, 하드웨어 가상화 기능을 제공한다. 

Architecture Principals

본 아키텍쳐의 설계 기본 원칙은 다음과 같다.

1. 안정성

장애가 발생하였을 때도 장애 업무 이외의 업무는 정상적인 수행이 가능해야 하며 타 업무로 그 영향을 전파해서는 안된다.

2. 확장성

비즈니스 상황에 따라서, 전체 시스템의 용량 (동시 사용자수)나 기능 (서비스 수)를 아키텍쳐의 변화 없이 쉽게 확장할 수 있어야 한다.

3.유연성

비즈니스 변화에 대해서 유연하게 대처할 수 있어야 한다.

 

Conceptual Architecture

위의 세가지 Principal을 기반으로 설계된 Conceptual Architecture는 다음과 같다.


Application Grid

애플리케이션 그리드의 개념은 여러 개의 하드웨어를 모아서 비즈니스 로직을 제공하는 단일된 형태의 애플리케이션 집합체이다. 외부에서 보기에는 하나의 애플리케이션 집합체로 보이며 단일 접속점 (End Point)을 가지지만 실제로 내부에는 여러 개의 애플리케이션이 분리된 하드웨어에 분리된 형태로 배포되어 있다.

 하드웨어 가상화 개념을 응용하여 그리드 내부에서 업무의 비중과 중요도에 따라서 하드웨어 자원을 동적으로 재 배정하여 자원 사용의 효율성을 극대화 한다.

 새로운 기능이 추가될 때 마다 컴포넌트를 애플리케이션 그리드에 꼽는 (PLUG IN)하는 개념으로 비즈니스 컴포넌트를 추가할 수 있으며, 애플리케이션 그리드의 Infrastructure에는 그리드를 관리하기 위한 운영,관리,모니터링 기능(이하 OAM) 이 구현되어 있기 때문에, 개발자는 비즈니스 로직에만 집중하여 개발한후 그리드에 배포하면 OAM은 Infrastructure에 의해서 관리된다.

 

애플리케이션 그리드 아키텍쳐는 계층에 따라서 하드웨어/미들웨어(웹로직)/웹서버 3개의 계층으로 나뉘어서 분리된다.

 

(1)   하드웨어 아키텍쳐

하드웨어는 IBM AIX 중에 가상화를 지원하는 하드웨어를 사용한다. 가상화는 하나의 하드웨어내에 있는 여러개의 CPU와 메모리를 분할하여 사용할 수 있는 기능이다. 즉 하나의 하드웨어 자원을 조각으로 나누어서 업무별로 할당이 가능하다.

 

하드웨어 아키텍쳐 구성시에, 작은 하드웨어 여러 개를 사용하는 것보다, 가상화가 가능한 큰 하드웨어를 사용하는 것이 유리하다. 일반적인 국내 차세대 시스템의 경우 오픈후에, 안정화 기간을 거치면 통상적으로 CPU 평균 사용률이 40% 이하로 제대로 구성된 아키텍쳐에서는 20~30%대로 사용되는 경우가 많다. 반대로 부하가 몰리는 서버의 경우 CPU 사용률이 70~80%까지 육박하는 경우도 있다. 이러한 경우, CPU나 메모리 자원에 대한 효율적인 분할을 하기 위해서는 하드웨어를 물리적으로 옮겨서 새로 소프트웨어 시스템을 설치해야 하는데, 이 과정은 많은 시간과 검증 작업을 요구하며 또한 소프트웨어 라이센스 측면에서 문제를 유발할 수 있다. (하드웨어 추가는 소프트웨어 라이센스의 추가 구매를 의미한다.)

 이런 비효율성은 반대로 가상화를 지원하는 하드웨어를 사용했을 때 쉽게 해결된다.  업무의 부하량에 따라서 동적으로 CPU 자원을 재할당 하여 업무 부하에 적절하게 대응할 수 있고 CPU 재할당의 경우에도 별도의 하드웨어 작업(CPU를 빼서 다른 서버에 옮기는등의)이 없이 소프트웨어적인 설정만으로도 가능하기 때문에, 변경에 대한 영향도를 최소화 할 수 있다.

 

(2)   웹로직 구성 아키텍쳐

웹로직 구성상에 있어서는 다음과 같은 원칙을 따른다.

업무당 하나의 웹로직 도메인을 사용하며,하나의 도메인은 여러 개의 클러스터를 가질 수 있으며, 각 클러스터는 여러 개의 Managed Server로 구성된다. 각 Managed Server에는 1개 이상의 업무 애플리케이션이 배포될 수 있다.

 

1) 서버 분리를 통한 장애 전파성 제거

자바 기반의 장애 특성은 턱시도와 같은 TP Monitor와 다르게 모든 업무가 하나의 프로세스에서 돌아가는 특징을 가지고 있다. 이로 인해서 장애가 발생할 경우, 같은 프로세스에서 돌고 있는 다른 업무에도 영향을 줄 수 있다. (TP Monitor의 경우 업무별-SERVER로 프로세스가 나뉘어져서 기동되기 때문에 장애가 다른 업무에 전파되지 않고 국지화될 수 있는 장점을 가지고 있다.) 이와 같은 문제를 해결하기 위해서 WAS에서 여러가지 Work Manager나 Thread Pool 분리와 같은 여러가지 기능을 제공하는데, 이 역시도, 메모리 과사용이나 CPU 과 사용등에 대한 문제에서는 자유로울 수 없다.

 

가장 올바른 아키텍쳐 설계 방안은 TP Monitor와 같은 원리로, 업무별로 Manager Server를 분리하여 장애시 타 업무에 대한 장애 전파성을 제거하는 것이다.

 

2) 관리 포인트 증가에 대한 해결 방법

Managed Server를 업무별로 분할하여 운영할 경우, 그 만큼 많은 Managed Server가 운영되게 되고, 이는 관리 포인트의 증가로 귀결된다. 이런 관리상의 문제점을 해결하기 위해서, 웹로직을 클러스터링 기능을 사용할 수 있다. 클러스터링에서는 여러 개의 Managed Server가 있더라도 클러스터 단위로 configuration을 반영할 수 있는 기능이 있기 때문에, Managed Server의 수가 증가하더라도 실제로는 클러스터의 단위로 관리를 할 수 있기 때문에 관리에서 오는 복잡도를 감소 시킬 수 있다.

 

3) 클라이언트를 통한 상태 관리

업무별로 Managed Server를 나누는 경우 발생하는 문제점중의 하나가 Managed Server간에 Session이나 상태 정보가 공유가 안되는 문제점을 가지고 있다. 그러나 고객의 아키텍쳐 설계의 Assumption은 윈도우 클라이언트 기반의 Rich Client를 사용하기 때문에, 상태나 사용자 정보를 클라이언트에서 관리하도록 설계하여 서버간의 정보 공유를 서버에서 클라이언트로 이관함으로써 이를 극복할 수 있다.

 

(3)   웹서버 아키텍쳐

1) Endpoint에 대한 Location Transparency 의 제공

본 아키텍쳐에서 웹서버는 Application Grid로의 End point를 단일화 시켜주는 중요한 역할을 한다. Grid내의 여러 개의 Managed Server의 주소로 클라이언트가 직접 접근하는 것이 아니라 업무별로 배정된, 웹서버라는 단일 접속점을 통해서 Grid내의 Managed Server로 접근할 수 있게 해준다. (이는 Grid내의 Managed Server의 수가 증가하거나 감소하더라도, 접속점에 대한 변경을 없게 하여 Location Transparency를 보장할 수 있게 한다.)

 

2) 유연한 배포 구조의 제공

본 아키텍쳐에서의 웹서버 구성은 하나의 업무에 대해서 두 이상의 웹서버와 하나의 L4를 사용하도록 구성되어 있는데, 이는 애플리케이션의 배포의 용이성을 제공하기 위해서이다.

WAS의 기능에 상관없이 애플리케이션 개발과정상의 실수에 의해서 REDEPLOY 과정에 많은 문제를 일으킬 수 있는데, 이로 인해서 가장 좋은 REDEPLOY 방법은 DEPLOY후 RESTART하는 것이 가장 좋은 방법이다. 그러나 이 경우 해당 업무가 일시적으로 정지될 수 있는 위험도를 가지고 있기 때문에, 이 다운 타임을 최소화할 수 있는 아키텍쳐 설계가 필요하다.

2개의 웹서버중 하나의 웹서버를 다운 시키면 L4에 의해서 반대쪽 웹서버로만 부하가 가게 되고, 웹서버가 다운 되었기 때문에, 그에 연결된 Managed Server들은 사용자로부터 REQUEST를 받지 않는 상태가 된다. 이 상태에서 애플리케이션을 재배포한후 서버들을 재기동 시킨후, 반대족 웹서버도 번갈아서 같은 방식으로 재기동을 하게 되면 운영중에도 가장 안전한 방법으로 업무에 대한 정지 없이 재배포가 가능하게 된다.

 

Application Grid OAM (Operation, Administration, Monitoring)

OAM 기능은 애플리케이션 그리드에 대한 운영,관리, 모니터링 기능을 제공하는 인프라이다. 비록 고객의 요구 사항에서는 웹로직만으로 구성하는 것을 요청했으나, 아키텍쳐의 완성도를 위해서 OAM 모듈에 대한 기능을 추가하였다.

 

Configuration 관리

고객의 요구사항중의 하나는 100개이상의 웹로직 인스턴스를 운영 및 관리해야 한다. 비록 클러스터링을 통해서 관리 포인트를 줄일 수 있는 형태로 설계했지만, 많은 인스턴스에 대한 Configuration 관리는 매우 도전적인 과제중의 하나이다.

Oracle 제품중에 ACC (Application Configuration Console)은 단일 Console을 통해서 여러 Managed 서버와 도메인 그리고 클러스터에 대한 관리를 가능하게 해주며, Configuration에 대한 이력관리등을 통해서 애플리케이션 그리드에 대한 하나의 관리 기능을 제공한다.

 

시스템 상태 모니터링

전체 그리드에서 시스템의 상태를 일목요연하게 볼 수 있는 기능이 필요하다. CPU 사용률, 애플리케이션 관점에서의 병목 구간, Thread 상태, 응답 시간등에 대한 모니터링 기능이 필요한데, 이는 APM (Application Performance Monitoring)을 통해서 가능하다.

 

업무별 상태 모니터링

시스템 상태 모니터링이 애플리케이션 관점(기술 관점)이라면 업무별 상태 모니터링은 비즈니스 관점에서 애플리케이션 그리드를 모니터링 하는 것이다.

 업무별 응답시간, 사용률, 장애율등을 Oracle BAM (Business Activity Monitoring)을 이용하여 그래프로 가시화 하여, 업무의 운용 상황을 한눈에 파악할 수 있도록 한다.

 

Features

Application Grid 아키텍쳐의 특징을 다시한번 정리해보면 다음과 같다.

 

장애 전파 방지 

Ÿ          Managed Server 분리를 통한 장애 전파 방지

업무별로 Managed Server를 분리하여, Dead Lock이나 Lock 경합으로 인한 장애 전파 또는 메모리 과사용으로 인하여 다른 업무에 영향을 주는 요인을 제거하였다.

Ÿ          하드웨어 자원 분리를 통한 장애 전파 방지

기존 WAS 아키텍쳐에서는 JAVA 프로세스를 분리하더라도, 실제 CPU나 메모리등의 하드웨어 자원을 공유해왔기 때문에, 한 프로세스가 CPU를 과점유하기 시작하면 정상적인 다른 프로세스에게도 영향을 줬다.

그러나 이 아키텍쳐에서는 업무에 따라서 하드웨어 자원을 분리하여 할당하기 때문에,특정 업무가 CPU를 과점유한다하더라도, 다른 업무용으로 배정된 CPU 자원을 사용할 수 없기 때문에, 하드웨어 자원 점유에 의한 장애 전파를 방지한다.

유연하고 최적화된 하드웨어 리소스 운영

Ÿ          Managed Server의 수 조정을 통한 자원 배분

시스템의 사용량이 늘어날 때, 사용량이 늘어난 업무에만 Managed Server의 수를 늘려서 하드웨어 자원의 사용을 최적화 할 수 있다. 반대로 사용량이 적은 업무의 경우 Managed Server의 수를 줄여서 잉여된 자원을 다른 업무에 배정하여 전체 Application Grid의 하드웨어 사용 효율성을 극대화 한다.

Ÿ          가상화를 통한 CPU 및 메모리에 대한 유연한 배분

해당 업무에 메모리 사용량이 높거나 CPU 사용량이 높을때는 하드웨어 가상화 기능을 통해서

메모리 크기 한계 극복

Ÿ          업무별 분리를 통한 메모리 사용성의 극대화

자바 애플리케이션은 구조상의 한계상 통상적으로 1.5GB의 메모리만이 사용가능하다. (최대 3G). 그래서 사용자 수가 늘어나는 경우에는 전체 부하를 여러 개의 인스턴스로 분산 시켜서 메모리 사용량을 낮추어야 하는데, 이 아키텍쳐에서는 간단하게 Managed Server의 수만 늘려주는 것만으로 메모리에 대한 부하를 손쉽게 분산 시킨다.

       참고 : Managed Server 분리에도 불구하고, 더 많은 양의 메모리가 필요한 경우에는 Coherence Data Grid를 이용하여, 메모리 확장을 고려할 수 있다.

 

확장성 

Ÿ          웹서버를 이용한 Location Transparency의 제공

업무의 종류나 부하량 또는 사용자가 증가하는 것에 상관없이, 새로운 업무는 Application Grid에 추가로 배포될 수 있으며, 시스템의 용량도 하드웨어 증설만으로 큰 설정 변경 없이 손쉽게 증설이 가능하다. 시스템이 확장되더라도 Grid 밖에서 보기에는 동일한 End Point를 통해서 접근하는 것이기 때문에, 확장이 기존의 애플리케이션에 영향을 주지 않는다.

애플리케이션 배포의 유연성 

Ÿ          웹서버와 L4를 이용한 무정지 Clean redeploy 제공

앞서 설명한 바와 같이 L4와 2개 이상의 웹서버 구성을 통해서 가장 안전한 방법 (RESTART)으로 운영중 무정지 재배포를 지원한다.

 

REST Overview (Draft)

아키텍쳐 /WEB 2.0 | 2009.07.01 16:10 | Posted by 조대협
REST에 대한 기본적인 설명 PPT입니다.
REST에 대한 개념 설명, 향상된 REST의 특징 설명, Jersey를 이용한 REST 실제 구현 방법
그리고 REST를 사용하기 위한 ESB 아키텍쳐와 REST의 약점중 하나인 Client STUB을 자동으로 생성하는 방법에 대해서 설명되어 있습니다.
 실제 프로젝트 경험을 통해서 처음 정리한 내용입니다. 아직 DRAFT 버전이라서 내용이 다소 거칠고 논리전개가 미숙한 부분도 있습니다. 의견 주시면 내용을 수정하는데 큰 도움 되겠습니다.



REST Ovewview
View more documents from Byungwook.

JEE enterprise Application Grid Architecture

아키텍쳐 /SOA | 2009.06.12 14:56 | Posted by 조대협

JEE Application Grid Architecture

 

한국 오라클 컨설팅
Principal Consultant
조병욱(byungwook.cho골뱅이oracle.com)

 

사상 (Architecture Principals)

애플리케이션 그리드 아키텍쳐 사상은 다음과 같다.

비즈니스 로직을 가진 업무 컴포넌트가 무제한적으로 그리드에 추가될 수 있으며, 호출하는 클라이언트 입장에서는 각각의 업무나 업무 컴포넌트를 분리된 형태가 아닌 하나의 진입점을 통해서 호출하도록 하고, 각 업무의 부하에 따라서 업무 시스템에 하드웨어 자원(CPU,MEMORY)를 탄력적으로 배분함으로써 최적화된 성능을 유지하고, 업무 또는 업무 컴포넌트에 장애가 발생하였을때에도 해당 장애가 다른 업무에 영향을 주지 않도록 하는 아키텍쳐이다.

 리소스 배분에 대한 구현

본 아키텍쳐의 특징중의 하나는 업무의 부하량에 따라서 하드웨어 자원을 자유롭게 배분하는 것이다. 이는 하드웨어에서 제공하는 가상화 기능을 이용하여 구축이 가능한데, 업무의 부하량에 따라서 WAS 인스턴스의 수를 탄력적으로 조정하고, 해당 업무를 담당하는 WAS INSTANCE그룹에 CPU와 메모리를 동적으로 배분함으로써 효율적인 자원 활용이 가능하다.

 바꿔 이야기 하면 오픈 당시에 예측했던 용량에 비해서 부하가 적은 업무에는 CPU를 빼고, 부하가 높은 업무에 CPU를 부여함으로써 자원 활용의 효율성과 확장성을 고려하는 것이다.

 장애 전파 방지

다른 특징은 장애 전파의 방지인데, 여러 업무 애플리케이션이 하나의 WAS INSTANCE에 배포되어 있는 경우, 한 업무가 장애가 나서 CPU과 사용등의 현상이 생기거나 THREAD를 과점유할 때, 같은 INSTANCE에 돌고 있는 다른 업무 역시 정상적인 수행이 불가능해진다. 이를 방지하기 위해서 업무별로 WAS INSTANCE를 나눠서 배포함으로써, 장애 전파 가능성을 제거할 수 있다.

 통상적으로 여러 업무를 하나의 WAS INSTANCE에 배포하는 주요한 이유중의 하나는 공유 데이터 (HTTP SESSION이나, 사용자 공유정보)를 하나의 INSTANCE내에서만 공유할 수 있기 때문인데 이 문제는 Oracle Coherence를 이용함으로써 INSTANCE간 메모리 공유를 통해서 해결할 수 있다.

 개발 생산성 증가

비즈니스 컴포넌트를 개발하는 입장에서 생산성에 문제를 일으키는 요인중의 하나가 공통 모듈 (Cross Cutting Concern)의 중복 개발이다. 인증,인가,로깅,Throwtling등의 공통 모듈 역시 JEE 아키텍쳐에서는 공통 라이브러리를 사용하건 말건간에, 비즈니스 컴포넌트에 붙여서 개발이 되어야 했다. 이는 개발자가 비즈니스 로직뿐만이 아니라 공통 모듈 개발에도 어느정도의 노력을 사용하도록 해왔고, 또한 공통 모듈의 변화는 개발 내용 전체에 영향을 줄 수 있어서 생산성에 영향을 줘왔던 것이 사실이다.

이러한 공통 모듈을 ESB 계층으로 모두 옮겨서, 비즈니스 컴포넌트에는 순수한 비즈니스 로직만이 들어가도록 하고, 공통 모듈은 ESB에 구현함으로써 비즈니스 로직 개발자가 순수 로직 개발에만 집중하도록 하여 개발의 생산성을 극대화 할 수 있다.

 시스템 유연성의 증가

IT 시스템은 비즈니스 요건에 따라서 변경 요건이 필수적으로 발생하는데, 본 아키텍쳐는 변경에 대한 요건을 ESB를 통해서 소화함으로써 시스템의 요건 변경에 대한 유연성을 극대화 한다.

 ESB는 자체적으로 Request/Response에 대해서 기능을 추가하거나 변경할 수 있는 Mediation의 개념을 가지고 있기 때문에, 업무 요건 변경으로 인한 기능 추가, 전문이나 데이터의 변경등을 비즈니스 컴포넌트의 변형 없이 ESB Mediation Logic을 추가함으로써 손쉽게 반영할 수 있다.

 무제한 확장 가능한 그리드  아키텍쳐

이 아키텍쳐의 가장 큰 특징중의 하나가 확장성이다. 새로운 비즈니스 로직이나 업무가 추가된다면, WAS INSTANCE를 추가하고 비즈니스 컴포넌트만 추가 배포하면 된다. (PLUG IN하듯이.) 비즈니스 로직을 호출하는 클라이언트 입장에서는 변화된 내용이 없으며 예전과 동일하게 하나의 접속점을 통해서 기존과 새로운 비즈니스 컴포넌트를 호출하면 되고, 하드웨어 용량 증설역시 횡적으로 확장해나가면서 비즈니스 로직을 추가할 수 있다.

 결론

기본 아키텍쳐 설계의 내용자체를 보면 복잡도는 크게 높지는 않다. “Simple is Best!”라는 원칙도 있듯이, 아키텍쳐는 단순성이 높을 수 록 성능과 그 신뢰성이 높아진다. 본 아키텍쳐는 엔터프라이즈 시스템에서 필수로 요구되는 확장성,유연성,신뢰성을 골고루 갖추고 있다.

참고

Coherence OSB를 이용한 아키텍쳐의 개념은 다음 문서를 참고하기 바란다.

 

 

'아키텍쳐  > SOA' 카테고리의 다른 글

EAI관점에서 본 SOA  (6) 2009.07.29
SOA를 공부하세요. 최고입니다.  (4) 2009.07.04
JEE enterprise Application Grid Architecture  (0) 2009.06.12
괜찮은 SOA 테스팅 툴 발견  (0) 2009.03.16
SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16

Enterprise Service Bus(ESB)를 이용한

차세대 JEE 아키텍쳐의 확장

 

한국 오라클 컨설팅
Principal Consultant
조병욱(byungwook.cho골뱅이oracle.com)

 

서론

근래의 JEE애플리케이션 아키텍쳐를 보면 전통적인 JSP/Servlet과 같은 HTML방식의 UI에서 AJAX/FLASH같은 X-Internet 솔루션을 사용하는 경우가 많다. 그래서 애플리케이션 아키텍쳐 역시 비즈니스 모듈이 XML+HTTP 형태로 기능을 제공하고, XML 데이터를 X-Internet 솔루션에서 처리하는 경우가 통상적이다. (국내의 가우스 플랫폼등)


기존의 아키텍쳐에서는 UI에서 BIZ LOGIC으로의 호출이 Java Language에 의존적인 형태의 호출로 이루어져 왔다. 단순하게 Java Method Invoke하는 형태 였는데, X-Internet 솔루션의 도입후의 아키텍쳐는 아래 그림과 같이


클라이언트에서 BIZ LOGIC까지 HTTP등의 프로토콜을 이용한 Remote 호출형태로 변화되었다.

 

전통적인 X-Intenet 기반의 JEE 아키텍쳐의 문제점

비표준 전문 형태 사용

 X-Internet 플랫폼 특히, 국내에서 개발된 X-Internet 플랫폼의 문제는 그 프로토콜이 어떤 표준을 따르지 않는다는 것이다. SOAP을 기반으로한 웹서비스나 REST 스타일이 아닌 단순하게, HTTP XML을 실어 보내는 형태의 XML-RPC 형태로 그 X-Internet 플랫폼에 특화된 프로토콜을 정의하여 사용하는 경우가 많다.

 그래서 이 프로토콜에 맞춰서 개발된 시스템들의 경우 제공되는 서비스는 오로지 그 X-Internet 플랫폼에서만 호출하여 사용할 수 있고, 다른 애플리케이션에서 호출하고자 할때는 별도의 인터페이스를 개발해야 하는 일이 발생한다. 또한 프로토콜의 SPEC 자체가 조악하거나 기능이 매우 빈약하여 추후 유지 보수나 관리 관점에서 많은 문제를 유발한다.

     실예로, 모 통신회사의  X-Internet 클라이언트 형태가 이러하다.

중복된 Cross cutting concern의 개발

HTTP 형태로 컴포넌트 기능을 제공하는 아키텍쳐의 공통적인 문제점중 하나는 Cross Cutting Concern (공통 기능)이 각각의 컴포넌트에서 구현이 된다는 것이다.

 인증과 인가, 로깅과 같은 공통적인 처리 요건이 각각의 컴포넌트 모듈에서 중복되서 개발이 된다. 이로 인해서, 같은 코드를 반복해서 개발해서 생산성이 떨어지고, 또한 만약 이러한 공통 처리 요건이 변경되었을 때, 전체 시스템의 코드를 변경해야 하는 문제가 발생한다.


 Oracle Service Bus를 이용한 아키텍쳐 개선

이러한 문제는 HTTP 기반의 컴포넌트 모델을 지원할 수 있는 유연한 인프라를 가지지 못해서 발생하는 것인데, Oracle Service Bus(이하 OSB-Oracle에서 판매하는 Enterprise Service Bus)로 이러한 문제를 해결할 수 있다. 특히 OSB의 장점중의 하나는 SOAP 기반의 WebService만을 지원하는 것이 아니라 AnySOAP, AnyXML,Text 등과 같은 다양한 형태의 Message Format을 지원하기 때문에, 단순히 웹서비스 기반의 플랫폼뿐만이 아니라 자체 표준을 사용하는 다양한 형태의 비즈니스 애플리케이션에도 적용이 가능하다

1)    다양한 프로토콜을 지원

WEB 2.0이 도래하면서 HTTP 기반의 프로토콜이 웹서비스뿐만 아니라 용도에 따라 REST with XML이나 REST with JSON, XML RPC등 여러가지 형태의 프로토콜을 사용하고 있다. 이러한 프로토콜을 각각의 업무 비즈니스에서 지원하려면 중복된 개발이 필요하고, 컴포넌트 개발자가 비즈니스 로직뿐만 아니라 프로토콜 변환에도 상당한 노력을 들여야 한다.


OSB를 사용함으로써 얻을 수 있는 장점중의 하나가 Entry Point OSB로 단일화 함으로써, IN/OUT 프로토콜에 대한 변환 지원이 가능하며 이는 OSB에서 중앙 집중화된 형태로 처리가 가능하기 때문에, 업무 개발자의 노력을 경감시켜서 개발 생산성의 향상을 이끌어 올 수 있고, 추가적인 프로토콜 변화 요청에 대해서 유연하게 대응할 수 있다

또한 내부의 컴포넌트 프로토콜을 하나의 표준 프로토콜로 단일화 할 수 있어서, 아키텍쳐의 단순성과 함께 표준화를 통한 관리의 용이성을 얻을 수 있다.  

2)    Cross Cutting Concern(공통모듈) 처리의 단일화

위에서도 언급했듯이, 컴포넌트 개발에 있어서 문제점중의 하나가 공통 모듈에 대한 중복 개발 문제이다. 이는 중복적인 개발로 인하여 개발의 생산성을 떨어뜨리고 또한 공통 모듈의 변화는 전체 프로그램의 수정을 일으켜서 아키텍쳐의 유연성과 생산성을 급격하게 감소 시키는 문제점을 야기 하였다.

이러한 공통 모듈 (Cross cutting concern) OSB에 중앙 집중화 시킴으로써, 컴포넌트 개발자가 비즈니스 업무 로직 개발에 집중하도록 하고, 변경시에서도 OSB 단일 지점만 변경하도록 하여 유연하고 생산성이 높은 아키텍쳐를 구축할 수 있다.

 

3)    Mediation을 통한 비즈니스 변화에 대한 적응

아키텍쳐 설계에 있어서 중요한 점 중의 하나는 비즈니스 변화에 대한 대응 능력이다.

예를 들면

Ÿ  Function Adding

기존 기능에 대해서 새로운 기능이 더해진 경우. 예를 들어결재 서비스에 캐쉬백 기능이나 포인트 적립이 추가되는 경우

Ÿ  Data Transformation

입력이나 출력 받는 데이터의 형식이 바뀐 경우. 예를 들어 게시판에 글을 올리는데 기존에는 사용자 ID만 필요했는데, 실명제로 인해서 주민등록 번호를 조회해야 하는 경우 입력값이 사용자 ID만에서 사용자 ID와 주민등록 번호를 받는 입력형태로 변경되고, 기존의 글 올리기 서비스는 변경이 없고 입력 받은 주민등록 번호로 실명 인증하는 기능을 추가하는 경우

Ÿ  Routing

어떤 조건에 따라서 호출되는 서비스가 달라지는 경우. 예를 들어 신용카드 서비스 정책이 일반 회원만 있다가 플레티넘 회원에 대한 서비스와 포인트 적립 방식이 달라지는 경우 회원 등급에 따라서 호출해야 하는 서비스가 달라진다.

이러한 시나리오는 비즈니스 요구사항 변화에 따라서 발생을 하고, 이는 실제 비즈니스 컴포넌트에 변경 요건을 준다. 특히 해당 비즈니스 컴포넌트가 여러곳에서 사용되고 있을 경우(의존성을 갖는 경우) 이에 대한 변경 여파가 매우 크다.

 위와 같이 기존의 비즈니스 로직에 변화를 줘서 동작 방식을 바꾸거나 개선하는 것을 Mediation이라고 하는데, OSB에서 이 Mediation 계층을 추가하여 비즈니스 요건이 변경되었을 경우 비즈니스 컴포넌트에 대한 변경이 없이 이를 OSB내에서 반영하여 업무 요구 사항에 대한 변화에 쉽고 빠르게 대응할 수 있다

4)    모니터링과 서비스 통제 (SLA/Throttling )

마지막으로 서비스에 대한 통제와 모니터링 기능을 꼽을 수 있는데, 특정 서비스의 사용률이나 응답시간등의 모니터링을 통해서 비즈니스 컴포넌트의 건강성과 재사용률을 파악할 수 있다.

그리고 비즈니스 컴포넌트에 문제가 있을 때 빠르게 검출 및 대응을 할 수 있다. (응답시간이 5초내로 떨어지는등 현상),  무엇보다 통제 기능을 부여할 수 있는게 큰 장점중의 하나이다. 해당 비즈니스 컴포넌트의 TPS 100이상을 넘으면 더 이상 요청을 받지 않고 에러 처리를 해서 시스템을 보호한다거나 관리자에게 알려서 용량 증설등의 조치를 할 취할 수 있게 한다.

 이런한 모니터링 및 관제 기능을 별도로 비즈니스 컴포넌트단에서 구현하기 위해서는 별도의 아키텍쳐 설계와 함께, 공통 모듈의 개발과 테스트를 거쳐야 하는데, 이런 과정이 패키지화 되어 있기 때문에, 이 과정에 소요 되는 많은 리소스들을 절약할 수 있다

4가지 주요 기능을 정리해서 보면 다음과 같은 그림으로 나타낼 수 있다.

 

아키텍쳐 구현시 주의 사항

 

OSB ESB를 이용한 아키텍쳐 구현에서 있어서 가장 흔하게 발생하면서 가장 치명적인 실수중의 하나가 Mediation Orchestration에 대한 잘못된 이해이다.

 Mediation은 기존의 비즈니스 기능에 추가로 기능을 덧붙여서 비즈니스에 기능을 추가 (정확히 말하면 enrich)하는 것이다. Orchestration은 하나 이상의 비즈니스 컴포넌트를 묶어서 새로운 기능을 구현해 내는 것이다.

 언뜻 보면 비슷할 수 도 있지만, 결정적인 차이는 추가되는 양에 있다. 예를 들면 Mediation이 자동차를 튜닝하여 자동차의 기능을 개선하는 것이라면, Orchestration LCD 생산 라인과 전화기 생산라인을 연계해서 컬러 LCD 전화기를 만들어내는것과 같다고 할까? (예를 들기가 참 어렵군요)

그래서 전통적으로 Orchestration Volume이 비슷한 2개 이상의 비즈니스 컴포넌트가 묶여져서 하나의 새로운 비즈니스 기능을 만들어내고, 많게는 10여개 이상의 비즈니스 컴포넌트가 로직에 따라서 흐름을 이어가는 경우가 많다. 종종 이 과정에서는 stateful 하거나 long running한 프로세스가 구현되기도 하는데, 이런 Orchestration 요건은 BPM과 같은 솔루션을 이용해서 구현되는 것이 바람직하고, ESB는 비즈니스 컴포넌트를 하나의 BUS라는 Entry point (진입점)을 통해서 외부에 서비스 하면서, 비즈니스의 변화에 유연하게 대응할 수 있도록 Mediation을 하는 기능을 갖추어야 한다.

ESB 단에서 종종 Orchestration이 발생하는 경우를 봤는데. (기능상으로는 BPM이나 ESB Workflow를 구현할 수 있는 기능이 있기 때문에 언뜻보면 비슷하다.) 성능상으로 엄청난 부하를 유발해서 프로젝트 후반에는 잘못된 아키텍쳐로 엄청난 하드웨어 증설이 필요한 경우를 종종 봤다

결론

웹애플리케이션의 트렌드가 Servlet/JSP 처럼 비즈니스 로직과 같이 패키징 되는 형태에서 UI X-Internet 클라이언트 형식으로 구현되고, HTTP를 통해서 서버에 있는 비즈니스 로직을 호출하는 형태로 변화되고 있다.

 이런 시스템 환경 변화에서 비즈니스 로직 개발자에게는 좀더 비즈니스 로직 자체 개발에만 집중하고 기타 Cross Cutting Concern에 대해서는 공통된 BUS에서 처리하도록하고, 또한 비즈니스비 변화에 대한 유연한 대응성과, 통제(SLA) 및 모니터링을 ESB를 통해서 현실화 할 수 있다

 또한, 클라이언트 입장에서는 비즈니스 로직이 어떤 형태로 구현이 되었던간에, ESB 라는 단일 포인트를 통해서 통신하게 되고, 비즈니스 로직은 추가되는데로 ESB PLUG IN어 무제한적인 확장이 가능한 GRID 아키텍쳐를 구현할 수 있다

참고

본 문서에서는 ESB를 통한 JEE 아키텍쳐에 대한 확장 개념만을 간략하게 설명하였고, 구현 아키텍쳐에 대한 자세한 내용은 Generic Proxy Pattern 문서를 참고하기 바란다.



(FML인 경우)
1. Tuxedo에서 도메인 Config 설정을 한다.
2. FML 파일을 java weblogic.wtc.jatmi.mkfldclass fmldata 로 해서 JAVA 클래스를 생성한다.
3. WLS에서 WTC 설정을 하고 Resource 탭에서 위에서 설정한 JAVA 클래스를 적는다.
4. 2에서 작성한 클래스를 JAR로 묶어서 클래스 패스에 추가한다.
== 여기까지가 WLS의 WTC설정
5. SB에서 AnyXML로 비지니스 서비스를 만들고
6. JAR를 SB 프로젝트에 추가한후, CLASS에서 해당 JAR를 고른다.
7. 비지니스 서비스를 완성한후 테스트시에

FML이 다음과 같을때
#name           number          type    flags   comments
ACCOUNT_ID      10              long    -       -
ACC_TYPE        11              char    -       -
ADDRESS         12              string  -       -
AMOUNT          13              float   -       -

Input XML은 다음과 같아진다.
<FML>
  <ACCOUNT_ID>10</ACCOUNT_ID>
  <ACC_TYPE>10</ACC_TYPE>
  <ADDRESS>10</ADDRESS>
  <AMOUNT>10</AMOUNT>
</FML>


루트 엘리먼트가 <FML>이 된다.
만약 FML32를 사용할 경우에는 <FML32>로 명시하면 된다.

SOA 시스템 설계에서 가장 큰 실수

아키텍쳐 /SOA | 2009.03.16 10:31 | Posted by 조대협
SOA 시스템에 대한 컨설팅 (설계나 Code Inspection)을 다니다 보면,
Goverance나 프로젝트 관리상에서도 문제가 많이 나타나지만, 설계상에서 근본적인 문제로 나타나는 패턴들이 있다.

SOA의 근본적인 정의를 다시 내려보면, "비지니스적인 의미를 가지는 컴포넌트를 기업내의 통합된 프로토콜로 서비스하여 제공한다." 이다.
BPM을 이용한 Composition이나 ESB를 이용한 유연성의 증대도 SOA 에서 큰 의미를 차지하지만, 일단 시작은 SOA를 통해서 제공되는 컴포넌트의 형태이다.

즉 기본이 되는 SOA 서비스와 그 인터페이스에 대한 정의와 구현이 제대로 되어야 하는데
통상적으로 SOA 시스템을 설계하고 구현하는데 있어서 발견되는 실수는 다음과 같다.

1. 표준 전문의 미사용
서비스의 전문 형태는 해당 시스템에서 어느정도 통합된 형태를 가져야 한다. 웹서비스를 사용하더라도, 프로토콜 측면이 아니라 비지니스 측면에서도 통합된 전문 형태가 요구 된다. 메세지 헤더, Message PayLoad의 형태등 표준화된 메세지 포맷은 전문의 가독성을 높여주고 아키텍쳐의 일관성을 가지고 가도록 해준다.

Legacy 시스템에 대한 통합 요건이 있을 경우에는 Legacy 시스템으로부터의 메세지를 표준 전문으로 변환하는 작업이 필요하겠지만, 처음부터 시작하는 SOA 프로젝트는 설계 단계에서부터 표준 전문을 사용하기 때문에, 표준 전문으로의 변환 요건이 나올 수 가 없다. 오직 잘못된 설계에서만 처음 시작하는 SOA (Build from scratch)에서 표준 전문 변환 구현이 추가된다.

2. 헤더의 Message Payload를 분리하지 않음
헤더와 Message Payload는 당연히 다른 의미르 갖는다. 헤더는 공통적으로 사용되는 부분이며 비지니스적 로직 처리 보다는 인증,인가와 같은 보안에 관련된 부분, 거래 추적을 위한 메세지 ID, Call back등의 Message Exchange Pattern(MEP)를 위한 Correation ID와 같이 공통적인 부분과 아키텍쳐에 대한 부분을 처리하도록 설계된다.

그런데, 이 헤더가 Message Payload (메세지 본문)에 포함되어 설계되는 경우가 종종 있다.
웹서비스로 이야기 하면 SOAP Body에 Header 정보가 들어가는 경우인데, SOA 시스템의 전제중의 하나는 "서비스들이 조합되어 비지니스 로직을 구현한다" 이다. 즉 전문은 여러 과정을 거쳐서 긴 여행후에 비지니스 로직을 처리한후 그 값을 리턴한다는 이야기이고, 그 과정에서 로깅이나 라우팅, 인증등의 로직을 수행할 수 있다.
그런데, 문제는 라우팅을 위해서는 헤더내의 특정 필드만이 필요한데 이런 경우에는 Message Payload를 전체를 Parsing해야 그 값을 얻어낼 수 있고, 이는 심각한 성능 저하를 유발하게 된다.
웹서비스의 경우 SOAP Header라는 필드가 있고, 이 Header에 Header값들을 넣게 되면 Header가 필요한 경우에는 (예를 들어 인증의 경우 Header 내용만 파싱해서 체크하고 뒤의 비지니스 로직으로 메세지를 포워딩 하면 된다.) Header만 파싱해서 핸들링하고 Body는 파싱을 하지 않아도 되기 때문에 성능상의 장점을 가지고 갈 수 있다.

REST의 경우에도 SOA와 유사하게 Resource를 기반으로 아키텍쳐가 구성되고 여러 Backend단을 거쳐야 하기 때문에 같은 원리로  HTTP-Header를 사용하며 Header를 전송할 필요가 있다.

3. 벌크 데이타의 전송
SOA나 EAI와 같은 연계(통합)이 필요한 시스템의 경우에는 메세지의 전달 패턴 (Message Exchange Pattern)에 따라서 그 연계 방식이 다르게 정의되어야 한다. 일반적인 Sync나 ASync는 많이들 고려하여 설계가 되고 있지만 벌크 데이타에 대한 전송이나 대용량의 Binary Attach의 경우에는 제대로 아키텍쳐상에 반영되지 않는 경우가 많다
특히 File Attach의 경우 웹서비스 상에 주석 <!-- CDATA로 전송하거나 Base64 encoding등을 이용하여 XML 엘리먼트로 전송하는 경우가 많은데, 이런 경우에는 메세지 전송 자체에 부하를 초래할 수 있기 때문에,
Swa (SOAP with Attachment)등을 이용하는 것이 바람직하고, 대용량 레코드의 경우에는 Batch를 이용한 전송이나 비동기식으로 (near realtime)형태로 리스트를 전송하는 아키텍쳐를 고려하는 것이 바람직하다.

4. Fine grainned 메세지
SOA는 기본적으로 서비스의 재사용을 전제로 한다. 서비스가 재사용될만큼 비지니스적인 의미를 가지고 Coarse grainned되어야 하는데, 일선의 개발 현장을 보면 SQL하나 보내는 것과 같이 작은 단위의 서비스가 많이 존재하는 것을 종종 볼 수 있다. 이는 기존의 CBD와 같은 개발 사상에서 벗어나지 못한 상태에서 설계를 하면 Fine grainned된 서비스들이 난무하고 전체적으로 서비스개수가 올라가고 관리 포인트가 증가하는 형태의 시스템이 만들어지고, 또한 각각의 Fine grainned된 서비스들을 호출하여 네트워크 부하를 늘리는 요인이 될 수 가 있다.

5. 불필요한 필드의 사용
메세지를 리턴할때 Consumer 쪽에서 사용하는 내용만을 리턴하는 것이 바람직하다.
Consumer 쪽에서는 사용하지도 않는 필드가 주렁주렁 매달려 있거나, 추후를 위해서 예약해놓는 다는 필드들이 주렁주렁 매달려 있는 경우는 전체적인 XML 메세지의 크기를 증가 시켜 성능을 저하 시킨다.
최적화된 메세지를 사용하는 것이 성능과 가독성에 큰 영향을 준다.

6. 불필요한 메세지 변환 사용
많이 있는 문제중의 하나인데, ESB의 경우 강력한 메세지 변환 기능이 있기 때문에 이를 남용하는 사례이다.
메세지 변환이 필요한 경우도 있지만.
예를 들어
1) 데이타의 내용은 바뀌지 않는데, UI에서 보여주기 편하게 하기 위해서 변환을 수행한다.
2) 데이타에서 불필요한 내용을 제거하기 위해서 변환을 수행한다.
와 같은 경우는 정말 금지해야하는 사례이다.
보여주기 위한 데이타나, 재사용되기 위한 데이타의 정재는 Consumer side에서 이루어지는 것이 맞으며, 데이타의 비지니스적인 의미 자체만 제대로 전달된다면 변환을 수행할 필요가 없다.

ESB는 SOA 시스템에 대한 유연성을 부여해주기 위함이고, 유연성을 제공하기 위해서 XQuery,XPath와 같은 엔진을 제공한다. 유연성을 제공하는 만큼 이 XML관련 연산은 CPU등을 SAX나 DOMParser와 같은 Pure XML 처리 방식보다 많이 사용하게 되는 것이다.
 이것이 실제 Code로 작성하는 것보다 비용이 높은지 낮은지에 대한 ROI관점에서 ESB에 로직이 들어가야 되느냐 말아야 되느냐를 결정해야 한다.

 갑자기 SOA 시스템 설계에서 문제점이 생각이 나서 정리를 해봐서인지.. 깔끔하게 정리는 되지 않았는데 혹시 의견이나 토론할 거리가 있으면 환영합니다.

참고 문서 : http://www.infoq.com/news/2009/03/threecommon


'아키텍쳐  > SOA' 카테고리의 다른 글

JEE enterprise Application Grid Architecture  (0) 2009.06.12
괜찮은 SOA 테스팅 툴 발견  (0) 2009.03.16
SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
문제는 JMS Proxy에서는 Transaction start를 지원하지만
가장 많이 사용하는 WebService Proxy는 Global Transaction을 start하지 않기 때문에
Transactional EJB를 Composition하는 경우 분산 트렌젝션에 대한 구현 문제가 생긴다.

방법은 두가지 인데.
1) 단순하게 EJB를 하나 만들어서 ALSB(OSB)에 배포하여 Code로 Tx를 composition한후, 이 EJB를 Biz Service로 등록하고 WebService로 Expose하는 방법
2) 좀더 OSB 다운 방법은

WebService Proxy에서 JMS Q로 callout한후 JMS Proxy에서 읽어서 Tx 처리하고나서 Recv Q에 return하면 WebService Proxy에서 blocked wait하다가 response 받아서 처리하는 방식...
성능이 다소 떨어질테고, 클러스터에 고려해야할점도 있을테고, JMS Q를 관리해야 하는점, Tx Fail시 Hop이 늘어나는 점등이 풀어야할 문제이기는 한데, reference 아키텍쳐만 단단하게 만들어놓는 다면 가능할듯...

이럴때 그냥 WLI로 Service Enablement 시키고 Biz Service로 등록하면 얼마나 좋아.. ALINT가 그리워~~

1. OSB 설치시 Default로 하면 Eclipse를 인스톨 하기를 요청하기 때문에 Custom으로 선택하고 Workshop에서 Eclipse 모듈을 제외하고 설치할것.
2. Managed Server을 추가로 추가하기가 복잡하기 때문에, 아예 설치시부터 Managed Server를 추가하는 것이 좋다.
3. DBMS를 사용하기 때문에, 초반에 DB 설정을 해놓고 인스톨하는 것이 좋다.