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


Archive»


 
 

EAI, ESB, API 게이트 웨이,서비스 매쉬

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


서비스간의 연동은 작게 보면 마이크로 서비스 아키텍쳐로 인한 문제 같지만, 서비스간의 연동은 마이크로 서비스 아키텍쳐 이전에도 자주 있어왔던 전통적인 문제이다. 이러한 문제를 소프트웨어 개발 프레임웍이 아니라, 솔루션 차원에서 풀기 위한 여러가지 노력들이 있었다.


시스템 통합 문제

메인 프레임 시대에서 유닉스 시스템으로 내려오면서 부터 시스템들은 업무 단위로 분리가 되기 시작했다. ERP,CRM 등과 같은 시스템으로, 은행은 대내,대외,정보계와 같이 시스템으로 잘게 잘게 나눠지기 시작했는데, 당연히 이렇게 나눠진 시스템 사이에는 통신이 필요하게 되었고, 시스템이 거대화 되가면서, 시스템간에 직접 P2P로 통신하는 구조는 한계에 다다르기 시작하였다.  



시스템이 서로 얽히고 어느 시스템이 어떤 시스템과 통신하는지 통제가 어렵게 되는 상황이 되었다.

EAI (Enterprise Application Integration)

이러한 시스템간의 문제를 해결하기 위해서 등장한 솔루션이 EAI인데, 통합을 원하는 시스템을 기존에는 직접 1:1로 붙였다면, EAI는 EAI가 중앙에 허브 역할을 하면서, 모든 통신을 EAI를 거치도록 하였다.



EAI의 가장 큰 특징은 표준화 되지 않은 이기종 시스템간의 연동을 가능하게 해준다는 것이다. 메인프레임 → Unix ERP 시스템으로 데이타를 전송하게 한다던지 Oracle → CRM 시스템으로 데이타를 전송해주는 것과 같은 시스템 통합을 지원했는데, 이는 이기종간에 통신 프로토콜이나 통합 방식을 변경할 수 있는 아답터를 제공하기 때문이다. EAI는 복잡한 메세지 처리나 변동, 라우팅같은 다양한 기능을 가지고 있었지만, 주로 이 기종간의 메세지 변환이 가장 많이 사용되었다.

어쨌거나 이런 EAI는 중앙 통제를 통해서 1:1 / 다:다로 통신되는 복잡한 토폴로지를 통합하는 의미가 있다.


EAI 시스템이 점점 더 많아지자. 시스템 통합 아키텍쳐도 패턴화 되었다. EIP (Enterprise Integration Pattern)이라는 형태로 정리되었는데, 아직도 참고할만한 구조가 많으니 관심이 있으면 참고하기 바란다.

https://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html

SOA / ESB

이 기종간의 통합이 많아지고, 시스템이 점점 분리되다 보니, 아예 이를 표준화하고자 하는 작업이 진행되었는데, 이것이 바로 SOA (Service Oriented Archtiecture / 서비스 지향 아키텍쳐) 이다.

SOA 아키텍쳐의 컨셉 자체는 MSA와 유사하지만, XML 기반의 웹서비스와 맞춰져서 웹서비스를 대표하는 아키텍쳐가 되어버렸다.

(사실 SOA는 아키텍쳐 구현 컨셉이지 XML/HTTP를 대표하는 것이 아니지만, 시대적으로 벤더들에 의해 웹서비스로 포장되었다. SOA는 시스템을 서비스로 나눈 다음 표준화된 인터페이스로 통신한다는 컨셉으로, 요즘의 MSA도 이 SOA의 부분 집합이라고 할 수 있다. )


웹서비스 기반으로 통신이 표준화되었기 때문에 서비스간의 통신은 EAI처럼 별도의 아답터가 필요없어졌다. 대신 서비스간의 통신을 서비스 버스라는 통신 백본을 이용하여 통신을 하는 구조가 되었다.




이론적으로는 매우 좋은 구조지만 웹서비스 자체가 스펙이 너무 복잡했고, 그 당시의 컴퓨팅 파워가 복잡한 XML을 파싱하기에는 충분하지 않았기 때문에 그다지 성공하지는 못한 아키텍쳐가 되었다.

특히나 ESB내에서 서비스간의 통신시에, 복잡한 XML 변환등을 사용하다가 ESB에 부하가 걸리게 되고, 제대로된 성능을 내지 못하는 결과를 낳게 되었다.

API Gateway

엔터프라이즈에 의해서 IT가 주도되는 시대가 끝나고 웹과 서비스의 시대가 오면서 개방형 API 즉, 오픈 API가 각광 받는 시대가 오면서 시스템 내부간의 통합도 중요했지만 외부로 API를 서비스 하는 클라이언트 대 서버간의 통합 그리고 외부 서버와 내부 서버와의 통합이 중요한 요건으로 대두되었다.

웹 기반의 서비스들은 복잡한 형태의 메세징을 필요로하지 않았기 때문에 XML을 버리고 상대적으로 간단한 JSON이 메인으로 사용되었고, 이를 HTTP 통신에 사용하면서 HTTP/JSON 기반의 REST 아키텍쳐가 유행하기 시작했다.

그래서  API 게이트 웨이가 외부로 서비스를 제공하기 위한 솔루션으로 제공되고, 시스템 내부간의 통합도 HTTP REST 를 이용하여 마치 ESB처럼 내부 버스로써 내부 시스템 통합을 지원하였다.



그러나 API 게이트웨이의 주요 목적은 앞에서 언급한 시스템간의 통합보다는, 클라이언트와 서버 중간에서 API에 대한 라우팅이나 인증 처리와 같이 내부 API를 외부 서비스로 제공하는데 촛점이 맞추어졌다.

물론 API에 대한 중간 통로 역할을 한다는 의미에서 ESB의 대안 모델로 사용이 가능하기 때문에, API 게이트웨이를 내부 서비스간 통신용으로 위치시키는 아키텍쳐도 있지만,  원래 목적 자체가 API를 외부에 서비스 하기 위한 목적으로 디자인된 아키텍쳐이기 때문에 여러모로 맞지 않는 부분이 있다.

특히나 대부분의 API 게이트 웨이는 게이트 웨이 인스턴스(클러스터)를 포진 시키는 방식이라서 서비스간의 통합 포인트가 많아서 복잡도가 올라가는 경우 API 게이트 웨이에 많은 부하가 걸려서 성능 저하가 발생하고, API 게이트 웨이가 장애가 날 경우 전체 서비스에 영향을 주는 (SPOF : Single Point of Failure) 가 된다는 단점이 있다.  

Service Mesh

이런 단점을 보안한 아키텍쳐가 서비스 매쉬 아키텍쳐이다.

  • API 게이트웨이와는 달리 외부로 서비스를 노출하기 보다는 내부 서비스간의 통신을 조율에 중점을 둔다.

  • 구조적으로 중앙 집중화 구조를 벗어나서, 분산형 아키텍쳐를 취하는 구조이다. 그래서 SPOF를 생성하지 않고 스케일한 서비스를 지원하기 좋다.


그래서 근래의 마이크로 서비스 아키텍쳐에서 안정적인 구조는 외부 서비스는 API 게이트 웨이를 통해서 노출하고, 내부 서비스는 서비스 매쉬를 통해서 통제하는 구조가 된다.



서비스 매쉬의 개념은 다음과 같다.

서비스가 서비스를 호출 하는 구조가 있을때


위의 그림과 같이 서비스가 서비스를 바로 직접 호출 하는 것이 아니라, 아래 그림과 같이 프록시를 둬서, 프록시를 통해서 호출을 하게 하는 구조이다.


이러한 구조를 가지게 되면, 네트워크 트래픽을 컨트롤 하는 것을 서비스의 소스 코드 변경없이도 가능하다. 예를 들어 서비스가 다른 대상 서비스를 호출할때 아래 그림과 같이, HTTP 헤더에서, 클라이언트의 종류에 따라 트래픽을 안드로이드용 서비스나 IOS용 서비스로 라우팅을 할 수 있다.


이러한 구조의 장점은 서비스를 호출하는 쪽이나 호출 받는 쪽이나 소스 코드 변환이 필요 없이 가능하다는 것이다.

서비스 매쉬의 가장 대표적인 솔루션은 istio 라는 솔루션으로 다음 글에서는 Istio에 대해서 설명하도록 하겠다.




Microservice architecture note

아키텍쳐 /SOA | 2014.08.20 16:37 | Posted by 조대협

MSA (Microservice Architecture) 

자료 수집


참고 자료

Ebay 아키텍쳐 : http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Netflix 아키텍쳐 : http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

infoQ Microservice Architecture : http://www.infoq.com/articles/microservices-intro

MicroService 개념 http://microservices.io/patterns/microservices.html

Martin folwer : http://martinfowler.com/articles/microservices.html

Dzone microservice architecture : http://java.dzone.com/articles/microservice-architecture

Thought works의 PPT : http://www.infoq.com/presentations/Micro-Services

node.js로 apigateway 만들기 : 정리 잘되어 있음. http://plainoldobjects.com/presentations/nodejs-the-good-parts-a-skeptics-view/


Conway's 법칙에 연관됨

You build, You run - Devops, Amazon

De-Centralized governance - 기술 표준화 보다는 다양한 기술을 허가. Microserice들을 스크립트 언어로 빠르게 만들어 버림. 

Cross platform, Self organized team 모델 지향 - Align 되기전에 Self organized로 이동되면. 망함. 

운영이 HELL이다. 높은 운영 능력, 장애 처리, Devops 필요.



==> 공감 x 100배 (나만 겪는 문제가 아니구만..)

ESB (Enterprise Night Bus.. ) 


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

Microservice architecture note  (0) 2014.08.20
Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29

대용량 분산 시스템 아키텍쳐 디자인


대용량 분산 시스템에 대한 아키텍쳐 설계에 대한 내용을 공유합니다. 아직 많이 부족합니다. 많은 피드백 부탁드립니다.


1. 아키텍쳐 설계 프로세스


2. 대용량 분산 시스템 아키텍쳐


3. 대용량 분산 시스템 아키텍쳐 디자인 패턴


4. 레퍼런스 아키텍쳐 - SOA 


5. 레퍼런스 아키텍쳐 - REST


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를 중앙에서 집중 관리할 수 있는 장점이 생긴다.

 

WCF가 몬가 했더니..

프로그래밍/C# & .NET | 2010.06.25 11:52 | Posted by 조대협
간단하게 튜토리얼 보고 테스트 프로그램 하나 짜서 송수신 전문을 봤더니...

송신 전문
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://tempuri.org/IEvalService/GetEvals</a:Action>
    <a:MessageID>urn:uuid:489b8c48-e094-418e-8f6b-60321ffc9d38</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
  </s:Header>
  <s:Body>
    <GetEvals xmlns="http://tempuri.org/" />
  </s:Body>
</s:Envelope>

수신 전문
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1" u:Id="_2">http://tempuri.org/IEvalService/GetEvalsResponse</a:Action>
    <a:RelatesTo u:Id="_3">urn:uuid:dfac6ed4-fbcc-46d6-9fd8-38ed4604aa4c</a:RelatesTo>
    <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <u:Timestamp u:Id="uuid-20a62935-2716-472d-ba79-1581763744f3-17">
        <u:Created>2010-06-25T02:50:53.419Z</u:Created>
        <u:Expires>2010-06-25T02:55:53.419Z</u:Expires>
      </u:Timestamp>
      <c:DerivedKeyToken u:Id="uuid-20a62935-2716-472d-ba79-1581763744f3-7" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
        <o:SecurityTokenReference>
          <o:Reference URI="urn:uuid:9ab8a01d-b2fb-40b4-bcee-e057f49e1a93" ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" />
        </o:SecurityTokenReference>
        <c:Offset>0</c:Offset>
        <c:Length>24</c:Length>
        <c:Nonce>pxd/ozyLoq7PsUk2mw2X2A==</c:Nonce>
      </c:DerivedKeyToken>
      <c:DerivedKeyToken u:Id="uuid-20a62935-2716-472d-ba79-1581763744f3-8" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
        <o:SecurityTokenReference>
          <o:Reference URI="urn:uuid:9ab8a01d-b2fb-40b4-bcee-e057f49e1a93" ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" />
        </o:SecurityTokenReference>
        <c:Nonce>3eijqwLZYaqrBjcduAkjow==</c:Nonce>
      </c:DerivedKeyToken>
      <e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:DataReference URI="#_1" />
        <e:DataReference URI="#_4" />
      </e:ReferenceList>
      <e:EncryptedData Id="_4" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <o:SecurityTokenReference>
            <o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk" URI="#uuid-20a62935-2716-472d-ba79-1581763744f3-8" />
          </o:SecurityTokenReference>
        </KeyInfo>
        <e:CipherData>
          <e:CipherValue>OHkE4mba4bbl+afwbRxjKTDQfRazYw+KiMLjCYX/FpgZ3nKmgUbLlZGWe3Q6Z6x1zvIX5WstoP2Cy9U49LgoGkNvGqbaAqKkZBYmjuyWbrcNXnNwLVWo5OMxhSUOT0Kr9lwRTSUw/g1c83EnkD69tM0jsuYWlKiIVRjOJ5zcpIH86LHWXMlwcgpP1gdP1eX+XePKHG59vtl6B7XOVOQW7DSTdUIeIi/y0YxMWRKc0p5Tfv6J4/gfGGlgv1B/j8lMq5Ar+4mif0M1hOeHuwPhXw2a2lciDk4BGFjJ9jD+3nZdbsaN63oJzBuxDygE8FArrp1ue7jYP6QjslKB5I73/CBlY01Y7lpvLhiL/8uf2V22Wfojey3WfBMeuDumOu5qZtVFaXAlHR7GaEE9eufuuRMbMvhc0xiSGgqLb9jiHpuqZgUAYdXY0cHu54QDMyc6jla37JMoUanHBQ662hQQhh05lRIX9FrThS5cn96duIJMQr8UggDLNYix7fv+OiADqZiJ+HgInNNJtW8wC11CDYc7IgDHVZIpQHG/apHtjvG3Qqx2LRMNTKCfuQY2O5Dp7hwmQuO9vZyUfdSn1PpK/llCuRBvoYX0ZnAk7KokctwE1lNKGmR9gCslGPLNBlo47m8VbMHE3m0wCW9T6MJilz2/PKqFV4tay3yiRcO3WCMlQ2ilHsaet4m3287CgtOz9IV+1ZlA6Dj1ZefWC9cPJuWIvDjf9dnuYt7yBrhGenmpGObTGVkgKOZx1MyxAZs80oD/9m9NRuu0xrUpMR+6gZNmfdB8XnMZTiiK7cngqURrQDDGOEZR3Jr8eKd/hdLdRbJ/j0RvoIAfk5zTzjZdiJRaxMfQatUbQqsfeOJ8ykjcriSYQJmQs8HpFnC6ReDh6QTTroW1RAyi2uTJH57CgpxteXnsKASYJ9KVYQiSacgRC/2idAm6NL8NS78QuwHjx99wxFfy8PSWAXkGcPpIgWA0DDgAS3mfbMTgfLZMw6BUTufAja5ti2JgwSDMe/MkwRiG3K/D1XWf1TzV+74xfvytg2b9p4Q4/7MDXb9Q+quXFD+PL0HmnKmBce6Q21F0HvSmefQC40I4VmjbFDmZ1dyXAog1uAwlyECTfRIejDkUfWM/S2epTtcpnFk0sAoa+DU1CSP1g8EEGhKf0jrezECaVdKSJemvyIqJ00RbLoKyioUnnM4loBN21gbpL9xs63OAEfy3v0n+/zXsDfMk9XrulwqFvcQ7/DtpwjmDzL9K7pEBpOCbVUSW0mvnWy9zZpO3l3miqJ49IFbFJ/mUuQnCH/Hbcyl4FLP7WDtibD5iK1IfT84taSgzXNsn/PnBaI2hcmO76wSqIxKntsmyZwDvIHh139x2dXUsPDJoQEBwNDPSvue2xGFgsxjOw/8l+z/83TNSInwscDtxOsuUSaF/Yi/EsKRljfi/whDgz85eWvZpdw4gDVxGFEKvJzMfre1G47WQQCC52rAMEtw7aHrFS2AdHbzXGZmLHX336MmHxE09eAiwB2jkjoGdlPPuqlhxY65ZEiq2neALmtsCjXpv1ALll1YOqJve8bqZMO9g0prB++TFovGSNFa2EfGcVhKNA89Xh40BRqrNRA/eDdJDa3vC1kyI1JbyF/kPHiyJo7rqcWI+vNW5smflOprb1UGApqKYrDeKRJzFw9kVrxY17qXxWAQFnK6F3toK4yqGkwp1AwpVFTAS7W2tkuLujMtmwTX9TWXdIwWjEf+2VB1c2yEEuW9YJUMYztim+wEbCAUy/CFZJaugScDtWm+cbLersOq4Iq9xLua3uixxogPFxNGj4/Ha9prrmtAJdm+mzqPu5m92Wnb9wcAevw/nvqqc8AcFybDCdHPMtfbRsbnU1oaCGJRVPC1TK01Obsj8s6SWMLv3P5ygZZoUm7Bp7xirsP3LhFT4L+6/rqy9syMHAhyKjbv6o0EgRpKqPQbKz8nZk9QpzGKWnln23X/NfRDInwJODvIVBWP2txSW24WVzlXplcmdxmYiVcm1JTjeNREu5DruFYgVuoYwnfgRvWaN35X87kLs06Zl8Ryga8SO1D9BNkv5fCNV3W9xjubKGusuNHsbObkL/LwSGEonc0bkk+F+4HgTAdpVIQkMmu2ta5WC5YWpqeJVoj8F9RmmitF8rbzlBFJ2noptLAoy</e:CipherValue>
        </e:CipherData>
      </e:EncryptedData>
    </o:Security>
  </s:Header>
  <s:Body u:Id="_0">
    <GetEvalsResponse xmlns="http://tempuri.org/">
      <GetEvalsResult xmlns:a="http://schemas.datacontract.org/2004/07/EvalServiceLibrary" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <a:Eval>
          <a:Comments>Test Comment</a:Comments>
          <a:Id>7c88a50c-cb86-4a94-934a-8552532bc2db</a:Id>
          <a:Submitter>bycho</a:Submitter>
          <a:TimeSubmitted>2010-06-25T11:48:00</a:TimeSubmitted>
        </a:Eval>
      </GetEvalsResult>
    </GetEvalsResponse>
  </s:Body>
</s:Envelope>

웹서비스다... 설마 이게 다는 아니겄지... REST 구현 함 찾아봐야 쓰겄다.

SDP (Service Delivery Platform)

아키텍쳐 /SOA | 2009.09.15 17:24 | Posted by 조대협

Byungwook.Cho
Principal Consultant/Oracle Korea

Initiative

요즘 통신 업계의 트렌드 중의 하나가 SDP(Service Delivery Platform)이다.

현재 통신 업계는 크게 두가지 도전과제를 안고 있는데, 급격한 비즈니스 환경 변화와 기술적인 변화이다. 통신 업계는 현재 매우 빠른 속도로 변화하고 있다.

 구글의 안드로이드,애플의 IPHONE,심비안,림의 블랙베리,윈도우 WM등 수많은 플랫폼들이 쏟아져 나오고 있고 AppStore와 같은 오픈 마켓을 통해서 모바일 기반 애플리케이션들이 판매되고 있다. 또한 단순한 전화통화와 SMS 메세징에서부터 글로벌 로밍,영상통화,VoIP,모바일 인터넷까지 모바일 시장 초반에는 상상할 수 없을 정도로 빠른 속도로 비즈니스와 기술적인 변화를 겪고 있다. 이런 변화를 수용하기 위해서 통신 업체는 많은 silo (다른 시스템과 독립된) 시스템들을 개발해왔고, 또한 시스템간의 통합(Integration)을 해왔다. 그러나 시스템들이 많아지면서 통합해야 할 대상은 더욱더 많아지고 통합에 요구되는 시간도 짧아짐에 따라 더 이상 현재의 방식대로 Ad-Hoc방식의 통합이나 개발이 어려워 지게 되었다.

 이런 이유로 통합된 하나의 통신 플랫폼이 필요하게 되었는데 이것이 SDP (Service Delivery Platform)이다.

 기존의 나뉘어져 있던 모든 통신 애플리케이션을 하나의 통일된 형태의 프로토콜과 표준으로 통합하여 플랫폼으로 구축하여 시스템간의 통합을 신속하고 자유롭게 하고, 비즈니스의 변화에 유연하고 빠르게 대응하기 위함이다

SDP SOA Telco 버전

사실 SDP의 개념 자체는 매우 단순하다. 한마디로 이야기 하면 “Telco 버전의 SOA”로 정리된다. 기존의 전통적인 SOA아키텍쳐를 보면, 레거시 시스템을 통합하기 위해서 JCA아답터들을 사용하였다. 이 아답터들은 Legacy 프로토콜 (MQ, SAP, PeopleSoft etc)를 이용하여 Legacy 시스템과 통신하여 그 기능을 SOA 인프라쪽으로 enablement 해주는 역할을 하였다. 이런 아답터를 이용함으로써 여러 종류의 Legacy 시스템을 하나의 통일된 서비스 표준으로 운영할 수 있었던 것이다. SDP역시 그 원리는 똑같다. 기존 SOA가 아답터를 통해서 Legacy 시스템을 통합했다면, SDP는 아답터를 통해서 Legacy Network Application을 통합한다. Telco 시스템에는 SIP,VoIP,Paray,SMSC등의 다양한 프로토콜에 종속된 애플리케이션들이 존재한다. 이러한 애플리케이션들을 네트워크 아답터를 이용하여 통합된 메시지 형태를 사용하도록 하고 SOA 사상위에 통합함으로써, SDP의 목적을 달성할 수 있는 것이다

 전통적인 SOA 시스템과의 또 다른 차이점은 SDP는 기본적으로 B2C 서비스 시스템이라는 것이다. 전통적인 SOA가 기업의 내부 업무를 위해서 주로 디자인 되었다면, SDP는 사용자와 Interaction하는 업무를 중심으로 디자인된다. 이는 좀더 많은 사용자를 커버해야 하고, 빠른 사용자 응답 시간을 요구하고 아키텍쳐의 단순성을 요구한다는 의미이다

일반적인 SDP 아키텍쳐

SDP는 다음과 같이 크게 3가지 계층으로 나뉘어 진다.

 

Service Enablement

이 계층의 역할은 다양한 기술 플랫폼과 통신 프로토콜을 사용하는 기존의 시스템들을 SDP의 표준 컴포넌트 형태로 변환해주는 역할을 한다. 크게 두가지 관점으로 생각할 수 있는데, 첫번째는 Network Abstraction이다.

 다양한 Telco의 네트워크 프로토콜(SMSC, SIP etc)를 추상화 하여 SDP내부의 공용 프로토콜로 추상화 하여 제공한다.

 두번째는 기존의 비즈니스 애플리케이션 (과금, 파트너 관리)의 기능을 통합할 수 있게 공통된 서비스 형태로 Expose하여 SDP에 연결하는 기능을 제공한다. 예를 들어 과금 기능이 사내 ERP의 재무 모듈과 연동할 수 있게해주는 연결고리 역시 SDP의 기능이다

Service Component

 서비스 컴포넌트는 SDP의 고유한 기능을 제공하는 컴포넌트이다.특히 Telco쪽에 특화된 기능을 제공하는데, 대표적인 기능으로는 Billing,Charging,파트너 관리, 컨텐츠 관리, 사용자 프로필 관리,Location Based Service등이 된다.

 이러한 컴포넌트들은 Telco 솔루션 기반으로 제작되거나 Telco 내부에서 Inhouse로 개발되는데, 이 컴포넌트들은 Service Component라는 형태로 Abstract되어서 SDP 내부에 존재하게 된다.

 Service Exposure

 Service Component에 의해서 제공되는 기능들은 Service Exposure 계층을 통해서 외부로 서비스 된다. 이 계층에서는 컴포넌트에 Cross Cutting Concerns(공통 기능)을 가미하고, (빌링,Authentication/Authorization, SLA 관리, Logging/Audit) 하부 컴포넌트를 묶어서 (Orchestrate)해서 새로운 기능으로 Expose하는 기능을 수행한다.

 이 계층은 전통적인 SOA 사상으로 구성된다. ESB를 통한 단일 Access point를 제공하며, BPM을 통한 Long-running process에 대한 Orchestration등을 제공하게 된다.  기존의 SOA Reference Architecture와 큰 차이가 없기 때문에 이 부분에 대한 설명은 생략한다.

 

결론

SDP는 크게 보면 Telco 에 전문화된 SOA 플랫폼이다. Telco의 많은 통신 프로토콜을 Abstract하여 통일된 형태로 관리하여 통합을 자유롭게 하고 이로 인해서 비즈니스에 대한 빠른 적응을 가능하게 해준다. 또한 빌링이나 사용자 관리와 같은 공용 비즈니스 컴포넌트를 내재하여 중복 개발을 방지하고 시스템의 재사용성을 극대화 하며, 기존의 비즈니스 시스템 (ERP, CRM)과 연결할 수 있는 연계점을 제공하여 Telco의 전반적인 Infrastructure로 자리 잡을 수 있다.

 

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

Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29
SOA를 공부하세요. 최고입니다.  (4) 2009.07.04

EAI관점에서 본 SOA

아키텍쳐 /SOA | 2009.07.29 23:16 | Posted by 조대협

EAI관점에서 본 SOA

 

2009-07-29

Oracle Korea/Principal Consultant

Byungwook.Cho (byungwook.cho 골뱅이 oracle.com)

 

SOA(Service Oriented Architecture) 에 대한 접근 방법은 BPM을 이용한 비즈니스의 민첩성 확보나 비즈니스의 서비스화를 통한 재 사용성등에 초점이 맞추어져왔다.

 BPM을 통한 민첩성 확보등은 실제 비즈니스에서 그만큼 변화가 다양한 업무 요건을 필요로하고 BPM으로 구현할 만큼 긴 프로세스가 정리되어 구현될 프로세스가 많지 않다. [ 사실 BPM으로 전체 프로세스를 시스템화 한다는 것은 상당히 힘든일이다. 그만큼 변화나 융통성이 많이 필요하기 때문인데, “일례로 XX과장님 무슨 업무 처리 부탁드립니다.” 와 같은 이메일이나 업무 협조 요청등을 통해서 일어나는 정형화되지 않은 프로세스도 있기 때문에 업무 절차에 대한 정리가 선행되야 BPM 도입시 효과를 볼 수 있다. ]

또한 재사용에 대한 문제 역시, 소프트웨어 공학론에서 수십년 전에서부터 언급되어 온 만큼 쉬운일이 아니다. 인터페이스를 통일하고 비즈니스 단위로 서비스를 만들어서 재사용을 하려면 상당히 고도화된 수준의 디자인 노하우가 필요하다.

그렇다면 SOA를 도입하는 데 있어서 다른 장점은 없을까? 그 중 하나가 통일된 인터페이스를 이용한 애플리케이션간의 통합을 SOA를 통해서 구축할 수 있다.

 

EAI (Enterprise Application Integration)

먼저 전통적인 애플리케이션간의 통합 방식인 EAI에 대해서 살펴보도록 하자.

1990년대에 인터넷의 활성화와 비즈니스의 IT 시스템의 도입이 가속화되면서 기업의 업무들은 급속하게 IT 시스템으로 구축되었다. ERP,CRP,PLM 등등 업무 부서별로 또는 비즈니스 영역별로 시스템들이 구축되었다.

 구축이 완료되고 시스템이 운영되기 시작하면서 문제가 발생되기 시작했다. 업무 시스템들이 서로 분리가 되어 있고, 업무에 대한 데이터가 서로 다른 시스템에 분리되서 관리되었던 것이다.

 물류 와 구매시스템에서 발생한 회사의 수입과 지출 내역이 회사의 회계 시스템과 분리되서 관리되었고 이로 인해서 각 시스템간의 데이터를 맞추는 작업이 수작업이나 또는 기타 원시적인 방법으로 진행되었다. 그러한 과정에서 실수도 발생을 하고 효율과 경영 여건에 대한 민첩성도 떨어지게 되었다.

업무간의 연계를 위해서 각각의 업무시스템을 P2P 형식으로 연결하기 시작했지만, 방대한 데이터에 대한 안정성,성능 그리고 모니터링등 여러가지 문제가 발생하였고, 이러한 애플리케이션간의 연동만을 전문으로 하는 아키텍쳐와 솔루션이 필요하게 되었는데 그것이 바로 EAI이다.

분리된 각각의 IT 시스템을 연결할 수 있는 인프라를 제공함으로써 전체 IT 시스템들의 유기적인 결합을 가능하게 하는 개념이다.

 

EAI의 통합상 문제점

그런데 이러한 전통적인 방식의 EAI는 통합 방식에 있어서 몇가지 문제를 가지고 있다.

그 중 하나가 통합 인터페이스의 문제이다. 통합하고자 하는 애플리케이션의 인터페이스를 이용하기 때문에, 통합이 발생할 때 마다 별도의 통합 프로그램을 구축해야 한다.


예를 들어 3개의 시스템을 서로 통합하고자 할 때, 각 업무 시스템별로 하나의 인터페이스만을 가지고 통합한다고 해도, 시스템의 인터페이스 방식이 틀리기 때문에 총 3개의 연결이 필요하다. 업무가 4개로 늘어나면 6개의 형태의 인터페이스 타입이 5개로 늘어나면 10개로 업무 시스템의 개수가 늘어나고 통합하고자 하는 기능의 수가 늘어날수록 통합 프로그램의 수는 급격하게 증가하게 된다.

 이는 통합 프로그램의 구현에 드는 자원과 이에 따른 관리 문제를 만들게 되고 특히 업무시스템 담당 부서간의 커뮤니케이션에 드는 노력을 급격하게 증가 시킨다.

 EAI 프로젝트의 경우 통합 하고자 하는 양쪽의 시스템의 현업 담당자들이 서로 인터페이스를 협의하고 메시지 타입을 협의하고, 연동할 인터페이스를 구현해야 하며 이에 대한 테스트를 수행해야 한다. 이 과정은 송신 시스템,EAI 시스템,수신 시스템 3개의 업무 부서가 관여하기 때문에, 커뮤니케이션에 소요되는 시간과 비용이 통상적으로 예상할 수 있는 범위를 넘어선다.

 

또한 기존 시스템들이 교체 되었을 때, 교체된 시스템의 인터페이스를 전면 교체해야 하는 작업이 발생한다. 그리고 EAI 시스템은 별도의 시스템들을 Native 인터페이스를 이용해서 연결하는 것이기 때문에, 각 시스템에 대한 전문 지식과, 타 업무 부서와 일하기 위한 프로세스, 그리고 연동 프로그래밍에 대한 능력등을 갖춘 개발자가 필요하다. 즉 인력이 교체될 때 높은 Learning Curve 와 Education Cost가 필요하게 된다는 것이다.

 

 

이러한 EAI의 문제는 각 시스템간의 인터페이스가 통일되어 있지 않고 호환되지 않기 때문에 발생하게 되는 것이다.

 

SOA를 이용한 통합

 

그러면 전통적인 EAI가 가지고 있는 문제를 해결하자면 어떻게 해야할까? 앞에서도 언급했듯이 이런 문제는 인터페이스의 비호환성에서부터 발생한다. 즉 해결 방식은 인터페이스 방식을 통합하는 것이다.

 

웹서비스나 CORBA등의 통합된 인터페이스 방식을 이용해서 모든 시스템들이 통신하게 되면 시스템이 바뀌었을때도 동일한 형태의 인터페이스를 노출해주면 되고, 중간에서 연동을 하는 입장에서도 여러 플랫폼에 대한 기술을 이해할 필요없이 하나의 표준 인터페이스 기술을 사용하면 되기 때문에 인력 운용면이나 Learning Curve 면에서도 여러가지 장점을 가질 수 있게 된다.

 

SOA와 EAI의 융합

그러면 EAI 는 더 이상 쓸모가 없는 것 일까? EAI는 통합에 있어서 SOA와 다른 관점을 가지는 만큼 다른 장점 또한 제공한다.

 

Tightly Coupled 통합

EAI는 통합 대상이 되는 애플리케이션에 대한 Native 인터페이스를 이용하기 때문에, Tightly Coupled 된 통합이 가능하다. 이 말은 애플리케이션간의 분산 트렌젝션과 같은 저수준의 통합을 가능하게 해준다는 것이다.

 특히 여러 개의 애플리케이션을 묶어서 하나의 서비스 기능으로 도출하고자 할 때, EAI내의 work flow 기능들을 이용하여 대상 애플리케이션들을 composite 하고 이를 서비스 형태로 expose (노출) 시키면 애플리케이션간의 분산 트렌젝션이 연계된 형태의 서비스를 노출 시킬 수 있다.

 즉 SOA에서 EAI는 저 수준의 시스템간의 통합을 담당하고 이를 서비스로 노출 시키는 역할을 한다.

 이렇게 기존의 Legacy 시스템들을 표준화된 인터페이스로 expose 해주는 계층을 SOA에서는 Service Enablement Layer라고 하고, EAI는 그 중에서 단일 시스템에 대한 expose 보다 하나 이상의 Legacy를 통합하여 expose 하는 composite 기반의 Service Enablement 를 수행한다.

 

기존 업무 조직에 대한 기술적 차이에 대한 중계

SOA 프로젝트에서 문제점중의 하나가 기존의 기술 조직의 서비스 구축에 대한 기술적인 차이이다.

예를 들어 ‘A사의 ERP 솔루션을 이용해서 ERP를 구축한 회사가 있다고 하자. 이 회사는 SOA로 아키텍쳐를 전환하기로 결정했고, ERP 팀에 회사 표준 인터페이스 기반으로 서비스를 Expose 하도록 지시했다고 가정하자.

그런데 이 ERP 팀의 개발자들은 오직 ERP 시스템에서 사용된 언어만을 안다. 설사 웹서비스와 같은 기술이 제공되더라도 XML도 모르고, 웹서비스를 공부할만한 시간도 의지도 없다. 결국에는 재사용이 가능한 높은 수준의 서비스가 아니라 간신히 구현한 서비스가 나오거나 또는 업무팀의 반발로 데이터 베이스간의 연동으로 통합을 하게 되고, SOA에서 추구하고자 하는 원래의 목적은 허물어져 간다.’

이런 시나리오는 실제 SOA 프로젝트에서 발생하는 시나리오이다. 처음부터 전체 시스템을 다시 구축하는 회사면 모르겠지만 새로 세운 회사가 아닌 이상, Legacy 시스템은 존재한다. 또한 하나의 솔루션에 전문화되어 있는 현업 인력에게 웹서비스라는 새로운 기술을 들이 민다는 것도 쉬운일이 아니다.

 여기서 EAI가 사용될 수 있는데, 업무팀은 현재 사용하고 있는 솔루션의 기술을 이용하여 비즈니스 서비스를 구축하면 EAI에서 해당 솔루션에 대한 아답터를 이용하여 연결하고 웹서비스로 외부에 Expose 해주는 기능을 수행한다.

 EAI의 인터페이스 변환은 단순하게 프로토콜이나 사용기술의 변화뿐만 아니라 조직간의 기술 차이에 대한 중재 역할까지 수행하게 된다.

 

결과적으로 EAI를 SOA에 적용하면 Service Enablement Layer로써 다음과 같은 계층 구조를 가지게 된다.

 

결론

지금까지 간단하게나마 기업의 애플리케이션의 통합의 필요성과 EAI를 통한 통합 그리고 SOA에서 애플리케이션의 통합 방법에 대해서 알아보았다. Application Integration은 현재의 Enterprise Architecture에서 반드시 필요한 요구사항이다. EAI가 되었건, SOA가 되었건 어떤 방식이던지 통합이 필수적인 요건이다. 어떤 방식으로 구현하느냐는 해당 기업의 시스템의 아키텍쳐와 요구사항에 따라 틀릴 것이고 SOA를 이용한 통합 방식이 전통적인 EAI방식보다 몇몇 장점이 있다는 것을 살펴보았다.

 

사실 본 문서에서 언급한 인터페이스 통일을 통한 시스템의 통합 방식은 SOA의 발전 모델중의 첫번째 모델인 통합 중심의 Fundamental SOA에 해당한다. (참고 : http://www.slideshare.net/Byungwook/soa-overview )

 

그러나 SOA가 반드시 모든 통합에 적합한 것은 아니다. EAI방식의 통합이 적절할때가 있고 SOA방식이 적절할때가 있기 때문에 SOA중심의 통합은 EAI 를 흡수하는 형태로 상호 보완적인 통합이 되어야 한다.

그리고 SOA의 목적 자체가 통합 하나만이 되서는 곤란하다. 여러 목적 중의 하나가 통합이고 그외에 서비스의 재사용, 시스템의 유연성과 민첩성등이 반영되어야 진정한 SOA 라고 이야기 할 수 있다.

 

 


SOA를 공부하세요. 최고입니다.

아키텍쳐 /SOA | 2009.07.04 22:41 | Posted by 조대협
오늘도 타이트한 하루가 끝나갑니다.
오전일 끝내고, 와이프와 딸을 데리고 집에서 한시간정도 거리에 있는 용인 한택 식물원에 다녀왔습니다. 오프로드를 유모차를 끌고 올라가는게 상당히 운동이 되더군요. 우리딸은 물만 보면 사죽을 못쓰는지라, 계곡에서 그리고 분수대에서 계속 있을려고 해서.. 데리고 나오느냐고 미안했습니다.

 SOA에 대해서 왜 이런 이야기를 하느냐 하면,
현존하는 아키텍쳐중에서 가장 범위가 넓고 가장 발전한 아키텍쳐중의 하나이기 때문입니다.
DDD의 글을 쓰다가 생각이 난 내용인데, SOA는 기본적으로 서비스를 비지니스적인 의미로 정의를 합니다. 비지니스와 IT조직간에 같은 Context를 사용한다는 겁니다. 그리고 전체 기업을 대상으로 하기 때문에 이 Context의 전파가 중요한 요건이 됩니다.

또한 애자일 사상에서 이야기 하는 Iteration의 개념역시 SOA에서 Vertical Slising과, Short Release의 개념으로 이미 녹아나 있습니다.

 팀조직과 협업 그리고 정치에 대한 부분역시 Governance에 대한 부분에 설명이되어 있고, 비지니스 아키텍쳐(사업의 비젼, 비용 관리등)에 대한 내용 역시 SOA의 비지니스 아키텍쳐에 설명이 되어있습니다.

SOA가 성공한 아키텍쳐네, 벤더들의 마케팅 수단이네 말은 많지만 SOA 자체는 훌륭한 아키텍쳐임에는 틀림이 없습니다. 적용하기가 힘들고, 현실화 시키기 위한 기술이 만만하지 않을뿐이지요.

 SOA를 공부하면 Enterprise System의 전체를 볼 수 있어서 아키텍쳐에 관심이 있으신분들은 꼭 공부해보시기를 추천합니다.

 항상 생각하는건데, 기술을 고민하는 사람들의 고민점과 해답은 시간이 지날수록 점점 비슷한 곳으로 모아지는 것 같습니다.

개인적으로 SOA에 관련해서 읽었던 책중 최고 명서는 http://www.amazon.com/Enterprise-SOA-Service-Oriented-Architecture-Practices/dp/0131465759/ref=sr_1_9?ie=UTF8&s=books&qid=1246714242&sr=8-9 이 아닌가 싶습니다. (Enterprise SOA)
2004년에 작성된 책이고, 웹서비스가 없었을때임에도 불구하고, SOA의 개념과 구현 방법,개념, 조직 구조등에 대해서 아주 잘 설명하고 있습니다. 군더더기가 없는 책이지요. 2004년에 이런 생각을 해낼 수 있다니 놀라울 따름입니다. 번역서도 있는 것으로 알고 있는데, 꼭 추천합니다.

다음으로는 Applied SOA입니다.
http://www.amazon.com/Applied-SOA-Service-Oriented-Architecture-Strategies/dp/0470223650/ref=sr_1_1?ie=UTF8&s=books&qid=1246714619&sr=1-1#
버릴것이 하나 없는 책입니다. 앞의 책보다 깊이가 좀더 있고, 특히 Governance와, Business Architecture 에 대한 부분이 보강이 되는 부분입니다. 작년에 출판사의 번역 여부 조언으로 받아서 읽었는데, 사실 읽을때 마다 새롭습니다. :(

마지막으로 SOA Design Pattern 입니다.
http://www.amazon.com/Design-Patterns-Prentice-Service-Oriented-Computing/dp/0136135161/ref=sr_1_1?ie=UTF8&s=books&qid=1246714775&sr=1-1
아마 SOA에 대한 책을 가장 많이 쓴 사람이 Thomas Erl 일겁니다. 그의 SOA에 대한 초기 두권의 저서가 시기를 잘 탔기 때문에 유명세를 탔다고 생각하는데요. 그 두권의 책의 내용은 사실 매우 별로 였습니다. 파란표지 책은 그나마 서비스 분석과 디자인 방법에 대해서 소프웨어 공학론적인 접근을 하고 있어서 참고할만 하지만, 그 내용을 수백페이지에 다뤄야 하나 하는 의문이 생깁니다.
 SOA Design Pattern은 Thomas Erl 의 이런 기존서적에 대한 비평을 조금이나마 덜어줄 수 있는 책이 아닌가 싶습니다.  역시나 이번책에도 다소 군더더기가 많아 보이기는 합니다만, 책의 질이 좋아서 들고 다니면 폼은납니다. :)
 이번 책에서는 SOA를 몇가지 관점으로 나눠서 정의하는데, 이 접근 방법이 매우 흥미롭습니다.
Service 자체에 대한 디자인 패턴, Composition 패턴, 그리고 기억이 가물가물한테 Service Infra에 대한 패턴 그리고 마지막으로 Service Inventory 패턴입니다.
 패턴 내용 자체보다는 제 경우 4가지 패턴으로 나누었다는 접근 방식 자체가 흥미롭습니다. 실제 설계해도 이렇게 해야 겠다는 생각이 들더군요.
 가장 주목할만한 점은 Service Inventory Pattern 입니다. 이 패턴은 흔히 이야기 하는 Service Repository 입니다. 기존에는  Service Repository를 단순히 UDDI 정도로 접근하는 개념이 많았지만 UDDI는 Runtime 에서 사용되는 서비스의 DNS? 정도입니다. (물론 부가기능은 더 있겠지만요.)
 그러나 SOA 가 성숙되어감에 따라 이 서비스를 어떻게 관리할것인가 (카달로그 또는 Repository 라고 합니다. )에 대한 의문이 생기는데, 이것이 Thomas Erl이 언급한 Inventory 입니다.
 Thomas Erl 아저씨의 특성상 책이 읽기가 어려워서 읽어도 잘 진도가 안나가서 고전을하고 있지만
 접근 방식에 대해서는 충분히 연구를 해볼만한 가치가 있습니다.

쭈욱 적어내려갔는데... 써놓고 보니 또 어렵습니다. :(
 그래도 SOA를 다른분들도 공부해서 많은 것을 얻어가실 수 있지 않을까 하는 생각에 정리해봤습니다.

의견이나 토론은 항상 환영합니다.



SOA Design Patterns by Thomas Erl

사는 이야기/책 | 2009.06.19 09:39 | Posted by 조대협

우연한 기회가 되서 신생출판사인 비제이퍼블릭의 지원으로 Thomas Erl의 SOA Design Pattern 책을 온라인으로나마 볼 수 있는 기회가 생겼습니다.

SOA를 하는 사람이면 누구나 한번쯤은 들어봤을 이름이 Thomas Erl인데, 두권의 SOA 관련 서적은 판매량과 명성에 비해서 내용은 정말 실망 스러웠지요. 그래서 개인적으로 Thomas Erl이 입만 살은 사람이 아닌가 하는 혹평을 내리고도 싶었지만, 이번에 SOA Design Patterns라는 책이 출간되고, Grady Booch가 감수를 했다는 말에 많이 궁금해오고 있었습니다.

한마디로 Thomas Erl이 공부해나가고 발전해나가고 있는 모습을 보여주는 책이라고나 할까요? 제 책꽂이에 꼽아놓고 싶은 책중의 하나입니다.

기존의 SOA 서적들이 SOA 아키텍쳐 특히 서비스 정의와 Composition등에 대해서만 언급하고 있다면 이 책은 크게 4가지 관점에서 SOA를 조명합니다.

Service Architecture
서비스 자체의 구현 방법에 대해서 설명합니다. 예전의 고리타분한 서비스의 개념뿐만 아니라 실제 어떻게 데이타를 다루고 비지니스 로직을 설계할것인지에 대한 내용이 나옵니다.
Service Composition
아직 자세히는 안 읽어봤으니 PASS
Service Inventory 
이 부분이 흥미로운데, 개발된 서비스들을 Asset으로 관리하는 관점에 대해서 많은 부분을 할애했습니다. 사실 서비스의 재 사용성은 개발된 서비스들을 어떻게 관리하느냐 인데, 보통 SOA에서 이야기 할때는 UDDI정도 언급하는 것으로 넘어갔지요. 그런데 이 챕터에서는 좀더 구체적인 서비스 관리 방안에 대해서 설명합니다.
Service Oriented Enterprise Architecture
엔터프라이즈 아키텍쳐에서 SOA관점에서 이야기 합니다. 아직 자세하게 안읽어봤기 때문에 역시 PASS

SOA를 하는 사람이라면 한번쯤 꼭 읽어볼만한 책이긴 한데..

1. 이 책을 읽고 이해하고 공감할 수 있는 사람이 국내에 얼마나 있을지..
2. 그리고 이책이 번역될것으로 알고 있는데, 제대로 번역할 사람이 있을지.. 의문입니다.


== 덧붙임 ==
약간 집중해서 Service Inventory 부분을 읽어봤는데.. 역시 Thomas Erl의 예전 책처럼 상당히 이론적이네요.


'사는 이야기 > ' 카테고리의 다른 글

사서 봐야 할책  (2) 2009.08.03
[서적 소개] Measuring User Experience  (0) 2009.07.20
SOA Design Patterns by Thomas Erl  (0) 2009.06.19
The Art of project management  (0) 2009.02.06
Enterprise Integration Patterns  (2) 2009.01.30
SOA Design Pattern  (2) 2009.01.19

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

Soap Handler

프로그래밍/XML 관련 | 2009.04.17 10:42 | Posted by 조대협

SOA 아키텍쳐중에 요건중의 하나가 웹서비스로 들어오고 나가는 데이타에 대한 Transformation과 Filtering이 문제인데, 일반적으로 ESB에서 이를 구현하고 결과적으로 과도한 XQuery로 성능저하로 아주 많은 문제를 일으키는 경우가 있는데, 이에 대한 대응 아키텍쳐로 SoapHandler를 사용해 보는 방법을 고려해볼 수 있다.

WebService는 일반적인 형태로 개발하고, Filtering이 필요할 경우 앞에 Filter의 기능에 따라서 SoapHandler를 붙이고 다른 endpoint를 부여 하는 방식을 사용할 수 있다.
자세한 내용은 여기에..


조만간 Reference implementation을 만들어봐야 겠다.

'프로그래밍 > XML 관련' 카테고리의 다른 글

XML 변환 성능  (0) 2009.04.17
Soap Handler  (0) 2009.04.17
WebLogic Workshop을 이용한 웹서비스 프로그래밍  (0) 2009.04.17
XMLBean  (3) 2008.12.22
JAX-WS를 이용한 쉬운 웹서비스 개발 방법  (0) 2008.12.12
XML에서 Namespace 제거하는 XSLT  (0) 2008.12.10

괜찮은 SOA 테스팅 툴 발견

아키텍쳐 /SOA | 2009.03.16 11:23 | Posted by 조대협
http://www.crosschecknet.com/

SOA 구현시 테스팅이 문제인데, 기존에 SOAP UI만 사용하다가 좋은 툴을 발견
HP TC와 연동도 되고, JUnit형태로도 뽑아져서 Regression(회귀) 테스트에도 반영 가능하단다.
InforWorld에서 SOA 테스팅 툴 부분에서 가장 좋은 점수를 받은 툴

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

OMG released SOAML draft

아키텍쳐 /SOA | 2009.01.16 15:52 | Posted by 조대협
OMG에서 SOA를 디자인할 수 있는 UML의 확장판인 SOAML을 발표했습니다.
http://www.omg.org/docs/ad/08-08-04.pdf

SOA 시스템 디자인하기에 편하겠네요.

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

괜찮은 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
관심이 가는 오라클 제품들  (0) 2008.10.15
TAG OMG, soa, SOAML, UML

2009년 기술 전망

엔터프라이즈 솔루션 | 2009.01.06 09:42 | Posted by 조대협

1. Cloud and grid computing

클라우드 컴퓨팅과 이를 구현하기 위한 솔루션인 그리드 컴퓨팅은 금년에도 이슈가 될것같다.

구글이나 야후, 아마존들을 중심으로 한 글로벌 서비스 기업들이 그리드와 클라우드 컴퓨팅에 선두가 되고 있지만

정작, 기업에 있어서 클라우드 컴퓨팅이나 그리드 컴퓨팅의 도입은 소극적이다. 특히 클라우드 컴퓨팅의 경우

보안이나 성능상의 이슈로 기업에 도입이 될지 않될지는 지켜봐야 할것 같지만

그리드 컴퓨팅의 경우 Coherence와 같은 Data Grid제품이나, Hadoop과 같은 File grid, grid dbms등은 기업에도 충분히 사용이 가능한 솔루션이다. 얼마나 기업 고객들이 이 개념들을 이해하고 적응하느냐가 관건일테고, 다른 한축으로는 대부분의 그리드 솔루션이 오픈 소스로 구축 된 경우가 많기 때문에 기업의 오픈 소스에 대한 반감을 어떻게 풀어내느냐도 하나의 숙제가 될것이다.

 

2. Virtualization

여기서 언급하고자 하는 가상화는 특히 서버의 자원 가상화이다. 여러개의 CPU와 메모리가 있는 장비를 Partition해서 사용함으로써 자원의 효율성을 극대화 시키는 기술인데.

예를 들면 이전에 2 CPU 서버 3대로 3개의 업무를 하고 있다고 했을때, 1서버의 평균 CPU 사용률이 1.2 2서버 1.5, 3서버 1.5라고 했을때 이렇게 되면 총 6개의 CPU가 있지만, 사용되는 CPU수는 실제로는 4.2이다. 가상화를 사용하게 되면, 하나의 큰 서버에 CPU 사용률을 상황에 따라서 배정할 수 있기 때문에 초기에 5장의 CPU로도 충분히 운영이 가능하게 된다 또한, 갑자기 부하량이 늘어나는 경우에는 여분의 CPU를 해당 업무에 할당 할 수 있기 때문에 자원활용의 유연성을 더할 수 있다.

 

가상화의 다른 특징중의 하나는 가상화된 환경과 애플리케이션을 이미지로 관리하기 때문에, 쉽게 다른 하드웨어 환경으로 배포가 가능하다는 것이다. 이는 SM관점에서 많은 장점을 가질 수 있게 된다.

 

3. Saas,Pass,Iass

Saas (Software as a service)는 이미들 많이 사용되는 컨셉이고 내년에는 Iaas와 Pass가 화두가 되지 않을까?

Iaas(Infrastructure as a service)는 OS,CPU,메모리,디스크와 같은 자원을 서비스로 제공하는 형태이다. 이미 아마존이 Message Q, OS,Disk,DBMS등에 대해서 E3라는 형태의 서비스로 Iaas 서비스를 제공하고 있다. 단기적으로 컴퓨팅 파워가 필요한 캠페인이나, CPU가 많이 필요한 3D 렌더링 작업들에는 매우 유용하게 사용될 수 있고, IDC 센터가 세계에 나눠져 있기 때문에, 여러 위치에서 테스트가 필요한 경우 유용하게 사용할 수 있다.

이미 아마존 E3 서비스에서는 OS별로 이미지를 만들어서 업로드하면 수행할 수 있도록 되어 있다.

다음으로는 Pass (Platform as a service)가 있는데, 플랫폼을 서비스로 제공하는 것이다. Open API도 일종의 Pass가 될 수 있고, Google의 Android 플랫폼 (OS+Open API환경,애플리케이션 Store)나 Apple의 AppStore도 일종의 Pass가 될 수 있다. 이러한 Paas가 Iaas와 결합하면서, 무제한적인 자원(Iass)을 유연성있게 제공받을 수 있으며, 그위에 Pass를 구현함으로써 개발자들에게 Application을 개발할 수 있는 플랫폼을 제공한다. 이 Pass를 이용하여 소프트웨어가 개발되고 일반 사용자에게 서비스되는 형태가 Saas로 될 수 있다.

사실 한국에서는 이 3가지에 대해서 움직임이 매우 늦은게 사실이다. 이 3가지 기술들은 주로 Google,Amazon과 같은 서비스 업체들의 주도로 시장이 움직여가고 있는데, 우리나라의 N이나, D사의 경우 이 부분에 있어서 아주 초보적인 단계에 밖에 이르지 못했다.

 

국내에서도 Service Platform이라는 형태로 기업 내부의 유용한 자원을 Open API화하여 밖으로 서비스하려는 움직임이 있는데, 이런 움직임이 Pass와 같은 서비스 형태로 구현되었으면 한다.

 

4. REST

작년의 하나의 화두중에 하나가 REST였다. Roy Fielding의 논문에서 소개된 아키텍쳐 스타일로 웹의 장점과 인프라를 최대한 활용한다는 개념에서 출발하였다.

 

문제는 REST는 사실상의 표준이 없다. Google이나 Amazon이 주도하는 Defactor 표준 (암묵적인 표준)은 있지만 Spec과 같은 표준이 없기 때문에, 기업에서 사용할 경우 관리(Gorverning)이 어렵다. Google이나 Amazon의 경우 자체 개발 조직과 관리 조직을 가지고 있기 때문에, 잘 관리된 형태로 REST 서비스를 제공 및 사용하고 있지만, 기업내에서 REST가 얼마나 힘을 발휘할 수 있을지 미지수다. WebService를 사용해보고 REST도 모두 사용해봤지만 개발 관점에서 드는 Burden은 REST라고 결코 낮지는 않다. WebService의 경우 이미 Infra가 잘되어 있고 개발툴이나 자동화 스크립트가 많기 때문에 실제로 JAX-WS와 같은 개발 표준을 따를 경우 개발 공수가 사실 매우 낮은 것이 사실이다.

 

국내 상황을 보면 아쉽게도, Open API를 서비스 하는 포탈에도 REST를 지원하는 업체는 없는 것으로 안다. 또한 REST의 이해도 자체도 상당히 떨어지는데 HTTP + POX (Plain Old XML)은 REST가 아니다. 대부분 XML-RPC형태를 띄는데, REST는 Resource를 정의하고, Resource 지향적인 아키텍쳐로 설계되어야 하며, 사람이 직관적으로 이해하고 쉽고, Link등을 통해서 Resource간의 관계를 정의하고 Resource의 다음 상태 전이에 대한 정의 능력등이 있어야 한다.

국내 BLOG에 올라오는 글들을 보면 Jersey나 Apache CXF등을 이용하여 REST를 구현하는 샘플이나 예제는 종종 올라오지만, REST를 아키텍쳐 관점에서 접근하는 글은 매우 드문 것 같다. (아직까지는 못봤다.)

 

어쨌거나, REST가 JAX-RS로 JSR311 표준으로 등록되었고, WSDL 2.0에도 REST가 반영되었기 때문에, REST의 영향력이 커진 것은 기정사실이고, Amazon도 기존의 Open API를 서서히 REST형식으로 바꾸겠다니 Service World에서는 대세인 것은 분명하나 기업 아키텍쳐에서 얼마나 힘을 발휘할지는 지켜봐야할 사항이다.

 

5. SOA Governance

SOA는 어떻게 보면 양극화가 발생하는 듯한 인상인데, 이미 SOA에 적응한 기업은 SOA에 대한 성숙도를 높이기 위한 해가 될테이고 아직도 SOA를 시작하지 못한 기업은 이미 어느정도 성숙된 SOA 플랫폼과 개념을 바탕으로 SOA를 시작할것이다.

공통점은 이미 여러 SOA 프로젝트를 통해서 거버넌스의 중요성이 인식되었기 때문에 무엇보다 거버넌스에 많은 집중을 할 해가 될것이라고 생각되며 REST의 영향을 받아서 Restful webservice 기반의 SOA가 시험될 해라고 생각된다.

 

6. Mobile platform

모바일 플랫폼에 대해서는 더 이상 말할 필요가 없을 것 같다. Google의 Android, Apple의 AppStore, Nokia의 모바일 플랫폼에 이어서 MS나 기타 모바일 업체도 일반 개발자들에게 개발 환경을 오픈함으로써 User created contents(application)을 생산하게 하고 이 과정에서 수익을 창출하는 비즈니스 모델이 유행이 될것이다. 아마 금년은 이 모바일 플랫폼의 최고 격전의 해가 되지 않을까?

 

7. Collaboration

협업에 대해서는 ALM과 Agile 방법론이 금년에도 작년에 이어서 크게 유행할것이고 좀더 실용적이고 실질적인 개발 및 협업 프로세스의 발전과 이를 구현하는 도구들이 사용될 것이다. 작년에 비해서 크게 변화한 점이 있기 보다는 좀더 성숙된 형태로 발전하는 해가 되지 않을까 싶다.

 

'엔터프라이즈 솔루션' 카테고리의 다른 글

Apache Camel note  (0) 2013.02.12
아키텍쳐에 있어서 레퍼런스의 중요성  (2) 2009.10.20
2009년 기술 전망  (2) 2009.01.06
문제는 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가 그리워~~

간만에 코딩..

사는 이야기 | 2008.11.28 17:48 | Posted by 조대협
간만에 파워포인트와 MS-WORD를 놓고 이클립스를 열었는데..
하루종일
xsd,x query,x path,wsdl과 싸움... 오랜만에 머리 쥐나는 느낌...
SOA도 생각보다 신경써야 할 부분이 많다~~

'사는 이야기' 카테고리의 다른 글

JCO 컨퍼런스 강의 프리뷰.  (2) 2009.02.27
엊그제 무슨일이 있었을까요?  (0) 2009.01.23
간만에 코딩..  (0) 2008.11.28
휴대용 유모차  (0) 2008.10.29
01  (0) 2008.10.23
웹세미나 주제 추천 받습니다.  (5) 2008.10.20
TAG soa, 잡담

Composition 과 Mashup의 차이

아키텍쳐 /SOA | 2008.11.13 19:01 | Posted by 조대협
SOA 프로젝트를 하다보면 Mash up과 Composition를 혼용해서 쓰는 사람들이 종종있다.
먼저 유래부터 살펴보면 SOA 사상이 먼저 나온후에, 
WEB 2.0 이란 사상이 대두 되고, SOA의 무거운 부분과 복잡성을 제외하고, 단순성과 편의성을 위주로 OPEN API라는 개념이 나왔다.
SOA에서 통상적으로 웹서비스로 구현되는 서비스를 JSON이나 PLAIN OLD XML등과 같이 경량의 사용하기 쉬운 메세지 포맷을 이용해서 OPEN API라는 것이 개발되었고, 이 오픈 API를 조합하여 새로운 기능을 만들어 내는것을 MASH UP이라고 한다.
   SOA  WEB 2.0
 컴포넌트 개념  웹서비스 기반의 서비스  경량 기반의 서비스
 서비스 조합  Composition (Orchestration)  Mash up

그러면 차이가 무엇일까?
다시 족보부터 따져 보자면 SOA는 기업을 위한 아키텍쳐에서 부터 출발했고 WEB 2.0은 서비스 애플리케이션에서부터 시작되었다.
IBM,BEA,ORACLE등을 선두로 하는 벤더에서 주창되는 아키텍쳐가 SOA이고, 구글이나 아마존, 야후와 같은 서비스 기업에 의해서 주창되는것이 WEB 2.0 사상이다.

사상 처럼 SOA의 서비스는 대부분이 비지니스적인 의미를 갖는다. 대부분의 서비스가 UI를 가지기보다는 비지니스 컴포넌트로써의 의미를 가지고, WEB 2.0의 서비스는 맵이나, 뉴스, 가젯 등등과 같이 UI 성격을 갖는 서비스가 대다수이다.

SOA에서의 Composition은 서비스들을 조합하여 새로운 서비스를 만들어 내는 것으로, 이 새로운 서비스는 재 사용이 가능하고 다시 Composition이 가능하다. 반면 Mash up은 한번 조합이 되서 새롭게 구성된 서비스는 다시금 조합이 어렵다. (물론 아닌 경우도 있지만....) Mash up은 기존 서비스를 조합하여 새로운 화면을 만들어서 자신의 서비스 사이트에 나타내기 위한것이기 때문에, 근본적으로 재활용성에 큰 비중을 둔것이 아니다.
반면 SOA는 컴포넌트 조합을 통해서 다시금 재 사용을 하는 것을 전제로 하기 때문에 재 사용성의 여부에서 Mashup과 Composition의 차이를 볼 수 있다.


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

SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10

SOA 가 어려운 이유..

아키텍쳐 /SOA | 2008.11.12 15:00 | Posted by 조대협
SOA가 나온지도 오래되었고 개념이 좋다는 것은 다들 인정하고 있지만 쉽게 확산 되지 않는 이유가 무엇일까?
결과부터 따져보자면

성공적인 SOA<-- 성공적인 거버넌스 <-- 강력한 파워와 조직

SOA는 기업의 모든 업무를 서비스화하여 재 사용하고자 하는 아키텍쳐이다. 단순한 프로젝트처럼 단기간에 끝낼 수 있는 것도 아니고, 한팀이나 TF형식으로 만들고 끝날 수 있는 것이 아니라. 장기적인 관점에서 소프트웨어 컴포넌트를 서비스화하여 자산화 하고, 이 자산을 재 사용해야 한다.

그러기 위해서 가장 중요한 것이 장기적인 계획을 세우고 각 비니지스 업무 부서를 조율하여 서비스를 생성 및 관리하고 조합하여 업무에 반영 하는 역할을 할 수 있는 것!!이 필요하다.
이 "것" 이 거버넌스 인데. 거버넌스는 전체 SOA를 통제할 수 있는 조직과, 프로세스, 그리고 이것을 뒷받침해줄 플랫폼이 포함된다. 물론 여기에 돈이나 시간도 들어가겠지만 가장 중요한것은 이 3가지인데...
대부분의 실패한 SOA의 문제점을 이 거버넌스에서 생각해볼 수 있다.

  • 거버넌스 조직 구성 부터 생각해보면, 거버넌스 조직은 SOA를 수행할 만한 기술과 업무에 대한 전문적인 지식과 함께, 각 비지니스 부서를 통제할 수 있는 POWER가 있어야 한다. 거버넌스의 실무 인원들이 그런 POWER를 가지기는  불가능하고, 거버넌스 조직의 LEADER가 결국 그 힘을 주는 것인데.. SOA 거버넌스 모델에서는 그런 사람을 BACKER라고 한다. 한국말로 하면 빽..!! 거버넌스 조직이 실력과 이만한 파워를 갖춰야 각 업무 부서를 통제하고 서비스를 착착 만들어 나갈텐데.. 이것이 안되니 SOA가 제대로 될리가 있나?? 보통 이런 조직은 기업에서는 CIO 산하의 정보전략이 리딩을 하는게 하는것이 맞는데.. 정보전략이 그만한 힘이 없거나 또는 그만한 전문성이 없거나 단기적인 프로젝트에 집중할때 문제가 생긴다.
SOA 프로젝트가 다른 프로젝트와 틀린것은 기존 프로젝트는 하나의 비지니스 업무에 대해서 한 LOB에서 단기간에 시스템을 구축하면 끝났지만, SOA는 전사적으로 아키텍쳐가 설정되어야 하고 거버넌스 조직에 의한 전략에 따라서 LOB 간의 협업이 중요한데.. 사람이 하는일이니 쉽지 않은가 보다.
  • 프로세스 측면에서는, 프로세스가 현실과 동떨어져 있는 경우가 많다. RUP가 거버넌스 프로세스는 아니지만 예를 들어보면 좋은 방법론과 프로세스임에는 확실하지만 무겁고 이해하기가 어렵다. LOB별이나 직원별의 기술 수준이 다르기 때문에 프로세스에 대한 적응도가 떨어질 수 밖에 없고 있는 거버넌스의 실패 그리고 통제의 실패와 프로젝트의 실패로 연결이 된다. 그러면 어떻게 해야 하나? 프로세스는 가볍고 이해하기 편해야 한다. 커뮤니케이션 파이프라인은 되도록이면 짧아야 한다. 내 경우에는 감히 "하향 평준화"를 하라고 이야기 하고 싶다.
  • 시스템 관점에서 보면, 거버넌스 시스템의 예로 PPMS(프로젝트 관리도구), SCM(형상 관리 도구) 등이 있지만!! 실제 프로젝트를 보면 툴 따로 실제 업무 따로인경우가 많다. 툴은 업무를 돕는것이지 툴에 업무를 맞추는게 아니다. 물론 툴이 무지 좋다면 그것도 방법은 되겠지만...
사실 거버넌스의 실패가 SOA에만 해당되는 이야기는 아니다. 일반 프로젝트도 거버넌스의 실패가 대부분의 실패 요인이 되니까는 그럼에도 불구하고 SOA에서 거버넌스의 중요성을 언급한것은 위에서도 이야기 했지만, SOA는 장기적이고 여러 부서에 걸쳐 있는 프로젝트이기 때문에 무엇보다도 통제가 중요하기 때문이다..

이글을 썼다가 날라가서 다시썼는데.. 내용이 좀 꼬이는듯 하네..

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

OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21

Web Oriented Architecture (WOA)

분류없음 | 2008.10.13 16:52 | Posted by 조대협
오늘 WOA에 대해서 듣게 되었는데.
역시나 생각들은 비슷한가보다.

SOA로 대표되는 아키텍쳐는 기본적으로 엔터프라이즈 시스템을 위해 고안되었고 그로 인해서 기업의 업무를 충실히 지원하기 위해서 많은 기능들을 제공한다.
그로 인한 문제가 복잡도가 많이 올라갔다는 것인데...
WEB 2.0 사상이 나오면서 REST,JSON,POX(Plain Old XML)등과 같이 이른바 OPEN API로 지칭되는 서비스들에서 사용되기 위한 경량의 프로토콜과 메세지 포맷, 네트워크 아키텍쳐들이 많이 소개 되었다.
WOA는 SOA의 사상과 같이 서비스 중심의 아키텍쳐 이면서 서비스를 제공하지만
SOA와 같은 강력한 기능 (트렌젝션, 여러 메세징 방법과 프로토콜)을 지원하지 않지만 최소한의 기능을 최대한 쉽게 지원하는데 목적이 맞춰져 있다.
이른바 REST와 POX,JSON으로 대표되는 아키텍쳐이다.
이 아키텍쳐는 WEB의 환경을 그래도 상속 받아서 사용하기 때문에 WEB이 가지고 있는 특성을 그대로 사용할 수 있는 장점을 가지고 있다.
  • URI 기반의 리소스 정의 : RESTFul과 같이 URI자체가 Method의 의미를 가지기 때문에 이해하기가 쉽고 HTTP method (GET,CREATE,PUT,DELETE) 를 사용하기 때문에 매우 직관적이다.
  • WEB 관련 인프라 사용 : 기존의 웹 캐슁, Proxy, Load Balancer등의 인프라를 그대로 재활용할 수 있으며 80 포트를 사용하기 때문에 상대적으로 Firewall에 자유롭다
따로 고안된 아키텍쳐라 보기보다는 SOA가 나오면서 서비스 진영에서 시작된 OPEN API의 사상이 다시 기업에 적절한 아키텍쳐로 정리가 된 수준으로 생각하면 될 듯...

역시 먼저 숟가락 꼽고.. 잘 정리하면 그것이 아키텍쳐가 되는것 같다.