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


Archive»


 

'테크놀러지'에 해당되는 글 3

  1. 2008.11.13 Composition 과 Mashup의 차이
  2. 2008.11.12 SCA 소개 자료
  3. 2008.11.12 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

SCA 소개 자료

아키텍쳐 /SCA | 2008.11.12 15:06 | Posted by 조대협
SCA (Service Composition Architecture)가 1~2년전에 나타났다가 요즘 잠잠하더니.. Oracle Product에 다시금 나타났다. ESB, Repository 등등 모든 제품들이 SCA를 지원하고 나섰는데..
SCA 개념 자체가 좋은 개념이기 때문에 구현만 잘된다면 새로운 Composition (또는 Orchestration 아키텍쳐)로 사용되기 충분할듯 하다.

작년에 정리해놨던 SCA 소개 자료를 첨부한다.

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

SCA 소개 자료  (0) 2008.11.12
Fabric3  (0) 2008.02.20
Introducing SCA  (0) 2007.12.03

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