calmglow (최진호)

원래 펌은 거의 안하지만 심각하게 필받는 경우 블로그질이 떨어지더라도 펌질한다. 감히 존경합니다. 노무현. 임기 내내 절대권력에 맞서서 싸워야했던 그에게 경의를 표합니다.

오늘 일주일만에 촛불집회에 참여했습니다. 지난 주도 엄청나게 많았는데 오늘은 그 때보다도 1.5배는 많아진 느낌입니다. 그 거대한 촛불의 장관에 엄청 깜짝 놀랬습니다. 제 지인들은 한 분도 나오지 않았지만 외로움을 느낄 수가 없었던 가슴이 활짝 열리는 듯한 느낌을 받고 집에 돌아왔습니다. 사랑합니다. 대한민국.

---

조선 건국 이래 600년 동안 우리는, 권력에 맞서서 권력을 한 번도 바꿔보

지 못했습니다. 비록 그것이 정의라 할 지라도, 비록 그것이 진리라 할 지

라도, 권력이 싫어하는 말을 했던 사람은, 또는 진리를 내세워 권력에 저

항했던 사람은 전부 죽임을 당했습니다. 그 자손들까지 멸문지화를 당했

고 패가망신했습니다.

600년 동안 한국에서 부귀영화를 누리고자 하는 사람은 모두 권력에 줄

을 서서 손바닥을 비비고 머리를 조아려야 했습니다. 그저 밥이나 먹고

살고 싶으면, 세상에서 어떤 부정이 저질러지고 있어도, 어떤 불의가 눈

앞에서 저질러지고 있어도, 강자가 부당하게 약자를 짓밟고 있어도, 모

른 척하고 고개 숙이고 외면했어요. 눈 감고 귀를 막고, 비굴한 삶을 사

는 사람만이 목숨을 부지하면서 밥이라도 먹고 살 수 있던 우리 600년의

역사.

저희 어머니가 제게 남겨주었던 저희 가훈은 '야 이놈아, 모난 돌이 정 맞

는다. 계란으로 바위 치기다. 바람 부는 대로 물결 치는 대로 눈치 보며

살아라'. 80년대 시위하다 감옥 간 우리 정의롭고 혈기 넘치는 젊은 아이

들에게 그 어머니들이 간곡히 간곡히 타일렀던 그들의 가훈 역시, '야 이

놈아 계란으로 바위 치기다, 그만 둬라. 너는 뒤로 빠져라'.

이 비겁한 교훈을 가르쳐야 했던 우리 600년의 역사, 이 역사를 청산해야

합니다. 권력에 맞서서 당당하게, 권력을 쟁취하는 우리의 역사가 이루어

져야만, 이제 비로소 우리 젊은이들이 떳떳하게 정의를 얘기할 수 있고,

떳떳하게 불의에 맞설 수 있는 새로운 역사를 만들어낼 수 있다...."

ESB는 그것이 지향하는 유연한 연결을 위해 그 어떤 물리적인 것과의 관계도 미리 확정하거나 단정짓지 않는다. ESB는 누군가 호출하기 전까지는 자기 안에 존재하는 서비스의 실체가 어떤 것인지를 알지 못한다. 그것이 바로 ESB가 유연함을 보장하는 방법이다. 그렇다면 ESB는 대체 어떻게 다양한 물리적인 것과의 관계를 유연한 관계로 연결시켰을까?

그림 17. ESB내의 서비스는 Who, What, How에 대하여 독립적이다

ESB는 실제 비즈니스 의미를 담고있는 것 이외의 모든 기술적인 것들의 결정을 모두 유보한다. 유보하는 요소는 크게 3가지로 나뉜다.

• 누가?: 예를 들어 ‘예약서비스’를 누가 어떤 방식으로 호출할 지에 대해 추상화시킨다. 어떤 사용자는 동기적인 방식으로 호출할 것이다. 어떤 이는 비동기적인 방식으로 호출할 수도 있을 것이다. 또 어떤 사용자는 MQ나 소켓등의 legacy스타일로 호출하기를 원할 수도 있다. 어떤 사용자에게는 보다 보안적용을 확실히 적용해야할 필요도 있을 것이다. 이것들은 실제 비즈니스 의미를 담고있는 서비스와는 별개의 부차적인 문제이다. 언제든지 바뀔 수 있는 부분이지만 이것들이 바뀐다고 비즈니스 의미를 해치는 것은 아니다. 따라서 ESB는 서비스의 누가?의 영역이 어떻게 바뀌더라도 서비스가 영향을 받는 일을 최소화하는 책임을 가진다.
• 어떻게?: 앞서 결혼식을 컨설팅하는 서비스는 다음과 같은 프로세스를 거쳤다. 1000만원 이상 잔고가 있을 경우에는 고급 예식장을 선택하고 그 이하일 경우에는 일반 예식장을 선택한다. 이러한 해당 서비스의 비즈니스 프로세스는 다양한 방식으로 실행될 수 있다. 가장 일반적이게는 BPEL로 구현할 수도 있겠지만 자바로도 능히 구현할 수 있을 것이고 PHP나 C#등의 다른 언어구현으로도 가능할 것이다. 기업환경은 너무나 유동적이기 때문에 하나의 문제를 한가지 방식으로만 해결하기를 영원히 바랄 수가 없다. 그때가 언제이든지 정의해 둔 서비스의 구현은 다양한 방식으로 교체가 자유롭게 가능해야만 한다. 그것이 유연함이다.
• 무엇을?: 하나의 서비스는 또 다른 서비스나 또 다른 IT자원을 필요로 한다. 앞서 결혼식 프로세스에서도 ‘잔고 조회’서비스는 실제 물리적인 데이타베이스를 필요로 할 것이며 ‘고급 예식장’ 서비스는 실제 A 혹은 B예식장 서비스를 필요로한다. 즉, ESB는 해당 비즈니스 서비스가 실제로 참조하고 있는 외부 서비스 자원에 대해서도 독립적이어야만 한다. 만약 결혼식 프로세스가 ‘고급 예식장’을 B예식장이라고 미리 단정지어버린다면 나중에 B예식장이 더이상 고급 예식장이 아니었을 때 이러한 현실과의 괴리를 해결하기 위해 결혼식 프로세스 자체가 변경되어야만 하는 과도한 노력을 수행해야한다. 따라서 ESB는 ESB내의 서비스가 참조하는 대상에 대해서 느슨한 연결을 제공해야만 한다.

이렇게 3가지 요소에 대한 느슨한 연결 제공을 통해 ESB내의 모든 서비스는 느슨한 연결을 보장받을 수 있고 궁극에는 SOA전체가 유연한 연결을 지향할 수 있는 발판이 만들어지는 것이다. 결국 ESB는 Java EE 컨테이너가 Java Component의 lifecycle과 트랜잭션이나 보안등을 관리하듯이 ESB는 서비스 컴포넌트의 lifecycle과 그 외 서비스가 정말 비즈니스 의미만 담을 수 있도록 그 외의 것들을 관리해주는 컨테이너임을 알 수 있다. 그렇다. 결국 ESB는 서비스 컴포넌트의 컨테이너이다. 그런 의미에서 ESB에서는 서비스 컴포넌트라는 개념이 대두되었다.

서비스 컴포넌트, 서비스의 가장 작은 단위

IT분야 전공자로서 컴포넌트라는 말을 들어보지 못한 사람은 아마 없을 것이다. 좀 더 정확하게 말하자면 단순히 컴포넌트가 아니라 소프트웨어 컴포넌트가 맞을 것이다. 그런데 이번 장에서 주로 다루는 주제는 소프트웨어 컴포넌트가 아닌 서비스 컴포넌트 그리고 이 서비스 컴포넌트의 아키텍처이다. 따라서 과연 우리가 일반적으로 알고 있는 소프트웨어 컴포넌트와 서비스 컴포넌트의 차이점은 무엇인지에 대해 짚고 넘어가는 게 좋을 것 같다.

컴포넌트란?

먼저 컴포넌트의 기본 정의부터 짚어보자. 컴포넌트란 '기능별로 정리되어 있는 비교적 컴팩트하며 재사용 가능한 부품'이다. 정리하자면

• 기능별로 정리되어 있다.
• 비교적 컴팩트 하다.
• 재사용 가능하다.
• 어떤 더 큰 무언가를 위한 부품이다.

바로 우리는 레고를 떠올릴 수 밖에 없고 컴포넌트의 기본 개념도 레고와 다를 게 없다. 그렇다면 소프트웨어 컴포넌트는 위의 요소를 다 가지고 있으면서 마지막 특징인 '어떤 더 큰 무언가를 위한 부품'만 변경하면 된다. 소프트웨어 컴포넌트는 '소프트웨어를 만들기 위한 부품'이다. 아주 간단한 정의 그리고 이해가 쏙쏙 되는 정의가 아닐 수 없다.
소프트웨어 업계에 객체지향의 개념이 시대를 풍미하던 때, 이 객체지향만 가지고는 소프트웨어의 재사용성을 보장할 수 없었기 때문에 컴포넌트라는 개념이 CBD(Component Based Development)와 함께 소프트웨어 개발업계의 주류로 자리잡게 되었다.
이 소프트웨어의 컴포넌트는 결국 소프트웨어 내부에서 쓰이기 위한 용도로 만들어졌기 때문에 상당히 컴퓨터 환경에 종속적이다. 이를테면 각각의 컴포넌트는 주로 사용되어야 할 OS가 있고 네트워크 연결 방식이 있고 프로토콜 방식이 있고 프로그래밍 언어 방식이 있다. 또한 인터페이스 기술 방식도 정해져 있어야만 한다. 소프트웨어는 각 컴포넌트가 가지고 있는 핵심 기능 이외에 여러 가지 것들을 고려해서 그것들을 사용해야만 한다. 그리고 고려해야하는 그 여러가지 것들은 핵심 기능 이외의 것들이다. 그래서 소프트웨어가 이러한 컴포넌트를 보다 편하게 사용하기 위해 컨테이너라는 것을 만들었다. 말 그대로 여러 이질적이거나 서로 다른 요구사항을 가진 컴포넌트들을 컨테이너에 얹고 공통된 방식으로 엮어내어 소프트웨어를 만들어내는 방식이다. 최대한 소프트웨어를 개발하는 개발자가 컴포넌트의 편리함을 취하고 불편함을 덜어내어 사용하고자 컨테이너를 만들었으나 소프트웨어 컴포넌트 자체가 가진 이러한 컴퓨터틱한, IT틱한 냄새는 지우기 힘들다.

서비스 컴포넌트

그렇다면 서비스 컴포넌트는 무엇일까? 이전에 언급한 컴포넌트의 정의에 서비스만 얹으면 된다. 즉 서비스 컴포넌트란 '기능별로 정리되어 있는 비교적 컴팩트하며 재사용 가능한 서비스의 부품'이라고 할 수 있다. 가장 최소한의 서비스 덩어리 부품이라고 보면 된다.
서비스 컴포넌트는 어떤 필요에 의해서 나왔을까? 그것은 바로 소프트웨어 컴포넌트가 해결하지 못한 상호운영성과 비즈니스 추상화 문제 때문이다. 서비스라는 것은 상당히 비즈니스적인 용어이다. 서비스는 결국 행위적인 의미가 강한데 이를테면 편지를 쓴다, 전화를 한다, 돈을 인출한다, 출퇴근을 한다 등등의 것들이 서비스계에서 통할 수 있는 언어이다. 그런데 소프트웨어 컴포넌트의 세계에서 서비스를 이야기하면 서로 언어가 통할 수가 없다.

그림 18.소프트웨어를 이루고 있는 다양한 요소들

위의 그림에서 보는 바와 같이 서비스를 이야기하기에는 소프트웨어 컴포넌트의 세계는 너무 불필요한 것들이 많다. 서비스 컴포넌트는 위 그림에서 언급된 모든 것을 죄다 추상화 레벨로 끌어올렸다. 곰곰히 생각해보면 위의 것들은 '느슨한 연결'의 개념을 이용하면 몇가지 것들로 상당히 간단하게 추상화될 수 있는 부분인 것이다. 즉, 서비스를 사용하려는 측과 서비스를 실제로 제공하는 측 그리고 서비스가 어떻게 구성되는 지를 최대한 느슨하게 연결시켜버리면 위의 복잡한 종속성에서 해방될 수 있다.

그림 19.서비스 컴포넌트의 추상화 대상

앞서도 설명했지만 위의 그림에서 보는 바와 같이 서비스 컴포넌트는 기본적으로 누가 서비스를 사용할 지 어떻게 사용할 지에 대해 추상화시켜버렸다. 또한 그 서비스가 어떻게 구현될런지 조차도 추상화시켜버렸다. 그래서 자바로 구현되었건 C, PHP, 코볼 어떤 것으로 구현되었다해도 상관없게 해버렸다. 게다가 이 서비스 컴포넌트가 로직을 수행 중에 또 다시 어떤 다른 서비스나 컴포넌트등을 호출한다해도 그것의 인터페이스만 알고 있을 뿐 그것이 웹서비스인지 RMI인지 TCP/IP인지 모르게 추상화시켜버렸다. 아니 대체 프로토콜도 모르고 어떻게 구현되었는지도 모르고 아무것도 모르면 대체 서비스 컴포넌트에는 무엇이 남느냐고? 차, 포 다 떼고 대체 서비스 컴포넌트에 무엇이 남았는지 살펴보자.

그림 20. 서비스 컴포넌트의 요소

위의 그림은 차, 포 다 떼고 껍데기만 남은 서비스 컴포넌트의 모습이다.
먼저 컴포넌트(Component)의 구현(Implementation) 영역부터 보자. 이것이 서비스 컴포넌트의 주요 몸체이다. 몸체는 몸체인데 안이 텅 비어있는 몸체이다. 이 몸체 안에는 자바로 만든 POJO형식의 클래스가 들어올 수도 있고 BPEL형식의 프로세스 정의만 들어올 수도 있고 PHP형식의 스크립트 언어가 들어올 수도 있다. 그것이 어떤 형태의 구현이든 이 컴포넌트 안에는 어떤 것이든 들어올 수 있게 정의해놓았다. 때문에 인터페이스만 동일하다면 C로 실행시키던 구현부를 다른 것은 다 냅두고 JAVA나 PHP등의 구현으로 변경해서 동일한 것인양 실행시킬 수 있다. 이 서비스 컴포넌트를 실행하는 요청자는 서비스가 바뀌었는지 조차 알 지 못한다.

그 다음에 참조(references)를 보자. 이 참조는 프로그래밍을 할 때 클래스 객체와 비슷한 것으로서 이 컴포넌트가 외부적으로 참조해서 사용하게 될 또 다른 서비스, 컴포넌트의 선언이라고 할 수 있다. 그런데 이 참조 역시도 느슨한 연결 방식을 채택하고 있다. 원격의 참조 대상의 인터페이스만 정의되어 있을 뿐 구체적인 정보는 최대한 느슨하게 정의하였다. 때문에 Implementation과 마찬가지로 얼마든지 변경이 가능한 구조이다.

마지막으로 서비스(services)를 보자. 외부에서 이 컴포넌트가 어떻게 호출되는지 어떤 프로토콜 등을 사용하는 지에 대해서도 추상화시켰다. 인터페이스만 정의되어 있을 뿐 그 실체는 최대한 느슨한 연결을 사용한다.

이처럼 서비스 컴포넌트의 특징은 구현에서 완벽하게 인터페이스를 분리하여 인터페이스로만 바라볼 수 있게 하는 것이 가장 큰 특징이라고 할 수 있겠다. 그렇다면 이 서비스 컴포넌트는 어디에 유용하게 쓰일 수 있을까? 과연 이 서비스 컴포넌트는 개발 환경에 어떠한 영향을 끼칠 것인가?

서비스 컴포넌트를 구현하는 사람은 이제 개발자라 부르기가 민망해질 것이다. 그들은 직접 소스코드를 건드리지 않는다. 그들은 단지 메시지와 인터페이스 그 외 몇가지 속성만을 가지고 서비스를 조합해낼 것이다. 그들이 그림그리듯이 만들어낸 서비스 컴포넌트의 조합들은 개발자에게 넘겨져 개발되거나 기존에 있던 서비스를 재사용하여 서비스 환경에 맞는 런타임 환경에서 실행될 것이다.

앞서도 누누히 강조하지만 SOA가 제대로 정착되기 위해서는 모든 것을 재사용하려 하고 서비스로 바라보는 문화가 정착되어야 한다. 그러기 위한 새로운 개발단위와 환경이 요구되는 것은 당연지사. 이제 서비스 컴포넌트의 표준, 서비스 컴포넌트의 아키텍처, 새로운 SOA시대의 IT 아키텍처의 기본단위가 될 SCA (Service Component Architecture) 에 대해 알아보자.

Service Component Architecture

Service Component Architecture 줄여서 SCA는 ESB가 지향하는 세가지 요소에 대한 느슨한 연결을 지원하기 위해 고안된 SOA에서의 표준이다(혹은 표준으로 정착되어가고 있는 스펙이다). 앞서 설명한 서비스 컴포넌트의 개념을 수용하면서 이러한 서비스의 컴포넌트를 엮어서 자유롭게 비즈니스 애플리케이션을 만들 수 있는 아키텍처를 목적으로 한다.

SCA를 이루는 가장 작은 단위는 서비스 컴포넌트이다. 이 컴포넌트 안에는 구현(Implement)을 포함하고 있으며 이 구현은 외부 컴포넌트나 외부 사용자에게 서비스로 제공된다. 이 구현은 또 어떤 작업을 실제로 수행하기 위해서는 외부 컴포넌트나 외부 서비스를 필요로 할 것이다. 이것을 참조(reference)라고 한다. 이 컴포넌트는 내부적으로 실행에 영향을 줄 수 있는 속성(properties)이 있으며 구현은 외부 컴포넌트와의 참조를 통해 제공되는 서비스와의 조합과 내부 속성을 가지며 이를 통해 구성된 형태가 완전한 서비스 컴포넌트를 이룬다. (그림 19참조)

SCA에서 이 구현은 어떠한 것도 정의 가능하다. 전통적으로 쓰이는 자바나 C, C++뿐만 아니라 PHP, C#, 자바스크립트, BPEL, Xquery등 어떠한 것이든 SCA의 컴포넌트의 구현이 될 수 있다. SCA는 이 구현이 실제로 내부적으로 어떻게 실행되든 상관없이 앞서 정의한 참조와 속성, 서비스등만을 정의해준다면 아무런 제약을 두지 않는다.

이렇게 해서 만들어지는 서비스 컴포넌트들의 묶음을 모듈(Composite 혹은 Module)이라고 한다. 이 모듈안에는 컴포넌트와 서비스, 참조, 속성들이 선언되어있고 이에 더하여 다수의 컴포넌트들간의 연결(wire)을 포함하여 런타임에서 어떻게 메시지가 흘러가는 지를 선언하고 있다. SCA는 이러한 모듈들을 XML로 정의하고 있으며 SCA 런타임엔진은 이 XML파일을 바탕으로 서비스 컴포넌트의 특징을 읽어서 런타임에 반영하고 속성을 변경하면 동적으로 이러한 것이 엔진에 반영될 수 있다. 그림 21에서 보는 바와 같이 컴포넌트들은 하나의 모듈 내에서 다양한 로직과 바인딩 설정에 의해 서로 연관되며 이러한 모듈마저도 또 다른 모듈에 의해 사용될 수 있을 것이다.

그림 21.SCA모듈(Composite) 다이어그램

이렇게 관계맺어진 컴포넌트들은 하나의 서비스 모듈에 패키징이 되며 마치 자바 EE 환경에서 EAR 파일 내에 웹 애플리케이션과 EJB 애플리케이션 등을 패키징하듯 서비스 모듈을 통해 우리가 관계 맺어놓은 각각의 컴포넌트들을 표준화된 방식 즉 ZIP형태의 압축파일로 패키징할 수 있다. 이렇게 패키지화된 ZIP파일은 어떠한 SCA엔진에서도 읽혀질 수 있도록 표준화된 형식의 구조를 SCA표준에서는 정의하고 있다. 사실 서비스 모듈은 EAR과 크게 다르지 않다. 실제로 서비스 모듈 내에는 WAR파일이나 혹은 EAR파일도 패키징되어 포함될 수 있으며 JSP파일이나 그 외에 거의 모든 IT자원들의 컴포넌트들이 포함될 수가 있다.

SCA는 기업 내의 모든 비즈니스 로직들에 대한 추상화를 제공함으로써 그것이 자바로 만들어졌건 웹서비스이건 C로 만들어졌건 비즈니스 프로세스 이건간에 상관없이 동일한 서비스의 관점에서 엮을 수 있는 새로운 관점에서 프로그래밍 모델이다. 그런데 여기서 우리가 간과하고 있는 것이 있다. 데이타는 어떻게 할 것인가? 즉, SCA를 통해서 가시화된 컴포넌트들 간의 데이터 교환은 또 다른 추상화된 데이터 레이어를 필요로 함을 눈치채야한다. 각 서비스 컴포넌트들은 상대 컴포넌트가 내부적으로 어떠한 형태의 데이터 포맷을 필요로 하는지를 상관하지 않아야 하며 오로지 순수하게 모든 데이터를 데이터 자체로만 인식할 수 있는 표준이 필요함을 알 수 있다. 이를 해결해 줄 수 있는 것이 바로 SDO (Service Data Object)이다.

Service Data Object

SDO(Service Data Object)는 IBM과 BEA가 공동으로 참여한 JSR 235 표준으로서 그 뿌리는 CommonJ라 는 구현물에 있다. SDO는 IT업계에서 점차 그 중요함이 절실해지고 있는 서로 다른 데이터 소스에 대한 통합되고 단순화된 제어를 목적으로 만들어진 API이다. 데이터소스가 DB이건 웹서비스이건 LDAP이건 상관없이 단일화된 인터페이스를 통해서 개발 생산성을 높이자는 데 그 목적이 있다.

SOA는 유연성과 상호운영성을 바탕으로 하는 강력한 산업 표준 프레임워크이며 온디맨드 비즈니스의 모든 것이라 할 수 있다. 이미 많은 인프라스트럭쳐가 SOA 애플리케이션을 구현할 수 있도록 웹서비스 표준에 맞게 많은 서비스들이 개발되고 있으며 자바는 다양한 API와 기술을 바탕으로 웹서비스를 찾고 생산하고 사용할 수 있는 능력을 보유하고 있다.

그러나 문제는 애플리케이션에서 정보를 가져오는 표준화된 방법이 없다는 점이다. 물론 JAXB나 Castor, XMLBeans 혹은 다양한 바인딩 기술을 통하여 XML 혹은 여러 다른 형태의 데이터를 자바 객체로 불러들여 사용하는 것이 가능하지만 과연 이러한 다양한 기술과 프레임워크를 단일 애플리케이션 혹은 프로젝트에서 적용하길 원하는가?

이러한 점에서 SDO가 도움을 줄 수 있다. SDO는 모든 데이터에 대하여 표준화된 구조와 객체 형태를 제공한다. 더우기 수많은 데이터 소스와 서비스로 부터 표준화된 접근 방식을 제공한다. 이는 정보의 소스로부터 비즈니스 프로세스를 분리하여 데이터 중심적인 제어를 가능하게 한다.

SDO의 목적

SDO가 만들어지게 된 가장 주된 목적은 보다 단순한 데이터 제어에 있다. 즉, EIS (Enterprise Information Systems)의 다양한 데이터 제어 기술을 통합하자는 데 그 첫번째 목적이 있는 것이다. 따라서 SDO를 사용하게 되면 데이터 소스로부터 독립적인 데이터 표현 인터페이스를 구축할 수 있게 된다. 이러한 SDO의 설계 이면에는 Domain Store라 불리우는 J2EE 패턴이 자리잡고 있다. 이 패턴을 통해 SDO는 데이터 제어를 보다 쉽게 하고 서로 다른 계층간에 느슨한 연결을 보장하는 등의 여러 이점을 제공하고 있다. 특히 느슨한 연결이라는 특징은 SDO의 가장 눈여겨볼 만한 장점 중의 하나라고 볼 수 있다.

SDO의 구조

크게 보면 SDO는 데이터 객체(Data Object), 데이터 그래프(Data Graph) 그리고 DMS(Data Mediator Service)로 이루어져 있다.

데이터 객체와 데이터 객체 그래프

데이터 객체는 데이터를 담고 있는 컴포넌트이다. 이는 내부적으로 키/값 쌍으로 이루어져있다. 각각의 값들은 원시 데이터 이거나 혹은 또 다른 데이터 객체일 수 있으며 Serializable 객체이다. 즉 데이터 객체는 모든 데이터의 기본 데이타이며 이러한 데이터 객체가 모여서 이루는 계층적인 구조가 바로 데이터 그래프라고 할 수 있다.

레스토랑의 디저트에 관련된 정보를 표현할 필요가 있을 때 데이터 객체는 다음과 같은 값을 가질 수 있다.

  <ID, 123>

  <Description, "Chocolate Cake">

  <Price, 7>

JDBC의 java.sql.ResultSet 인터페이스의 개념처럼 SDO의 동적 API 모드에서도 이러한 값들을 그것들의 이름이나 인덱스를 통해 접근할 수 있다.

  // 그래프의 첫번째 요소를 가져온다.

  DataObject dessert = (DataObject) graph.get(0);

  // 디저트 이름과 그 가격을 가져온다.

  String dessertName = dessert.getString("Description");

  int dessertPrice = dessert.getInt("Price");

데이터 객체 그래프

데이터 객체 그래프는 데이터의 계층적인 구조를 표현한다. 이는 데이터 객체의 트리를 담고 있으며 Change Summary라고 하는 그래프 상의 모든 데이터 객체들의 변화된 정보를 담고 있다. Change Summary가 필요한 이유는 SDO가 기본적으로 데이터소스와 비연결의 특성을 가지고 있기 때문이다.

그림 22 데이타 객체 그래프의 예

DMS

앞서 언급한 것처럼 SDO는 기본적으로 데이터소스와 비연결의 특성을 지니고 있다. 따라서 한번 데이터 소스와 연결이 되면 DMS는 실제 데이터 소스와의 연결을 해제한다. 이러한 비연결성은 n-tier 웹 기반의 아키텍처에 매우 적합하다.

DMS는 데이터 소스로부터 데이터 그래프를 만들어내는 메소드를 제공하는 컴포넌트이다. 이는 데이터 소스에 변화를 기록한다. 다양한 데이터 소스 포맷(XML, JMS, JCA, JDBC 등등)에 따라 다수의 DMS가 존재할 수 있다. DMS는 실제 데이터 저장소의 특징적인 부분을 감추고 SDO와 EIS간에 추상적인 인터페이스를 두어 언제나 같은 포맷(데이터 그래프)의 정보를 반환하게 된다. 사실 이 DMS는 SDO 표준의 영역에 있지는 않지만 이 구현은 여러 다양한 데이터 소스에 따라서 제공되어야만 하는 필수적인 영역이다.

그림 23. DMS는 물리적인 데이타들을 추상화하고 관리한다

SDO의 데이터 그래프 사용하기

다음 시퀀스 다이어그램은 SDO 그래프를 요청하는 흐름을 표현하였다. SDO 클라이언트가 데이터 접근을 요청하면 DMS는 데이터 소스에 접근하여 얻은 정보를 바탕으로 그래프를 생성한다. 클라이언트는 비연결된 그래프로 작업을 수행한다. 데이터가 클라이언트에 의해 수정되면 클라이언트는 이 정보를 저장하려 할 것이며 이 수정된 정보는 DMS에게 전달되고 DMS가 실제 이 수정 정보를 데이터 소스에 반영한다.

그림 24.SDO 그래프를 요청하는 흐름을 나타낸 시퀀스 다이어그램

자 그럼 그래프의 데이터 객체를 어떻게 사용하는 지 간단한 예제를 통해 살펴보자. SDO의 중요한 특징 중의 하나는 데이터 제어가 매우 쉽다는 데 있다. 그래서 데이터 그래프가 한번 만들어지면 SDO API를 이용하여 각 요소들을 트리 구조에 맞게 추적하여 제어할 수 있다. SDO 표준 개발자는 SDO에서 각 요소를 탐색하는 데 있어 XPath 언어를 지원할 수 있도록 하였다.

레스토랑 메뉴가 있다. 이는 UML 다이어그램으로 다음과 같이 표현되었다.

‘

그림 25.레스토랑 메뉴를 나타내는 다이어그램

SDO 그래프의 특정 사용 예는 다음과 같다.

그림 26.레스토랑 메뉴

먼저 그래프의 루트 요소를 가져온다. 모든 것의 시작은 이것부터다.

  DataObject root = dataGraph.getRootObject();

메뉴 객체를 가져온다.

  DataObject menu = root.getDataObject("Menu");

메뉴에는 어떤 종류가 있을까?

  String menuType = menu.getString("Name");

dinner가 좋겠다. 그럼 이제 dinner의 메인은 어떻게 구성되어있을까?

  DataObject mainDish = menu.getDataObject("coursetype[Type='Main']");

T-Bone을 선택하기로 했다면 인덱스를 통해 그래프에 직접 접근할 수 있다.

  DataObject tBone = (DataObject) mainDish.get(0);

가격을 알아보자.

  int tBonePrice= tBone.getInt("Price");

아직 배고픈가? 디저트는 어떤가?

  DataObject dessert = menu.getDataObject("coursetype[Type='Dessert']");

  List dessertList = dessert.getList();

  DataObject cake = menu.getDataObject(coursetype.2/dishes.2);

SDO를 이용하여 간단한 예를 들어보았다.

현재 이 SDO는 BEA와 IBM등의 대형 벤더의 ESB 제품에서 핵심적으로 사용되고 있는 기본 데이터 모델이다. IBM의 경우 SOA core 로서 이 SDO가 거의 모든 컴포넌트들간의 정보 교환에 사용되고 있으며 BEA의 경우도 아쿠아로직 제품 중 데이터 서비스 제품에서 이 SDO가 핵심 데이터 처리 컴포넌트로 사용되고 있다. 또한 이클립스 EMF 프로젝트에서는 이미 오래 전부터 SDO의 구현물을 사용하여 이클립스 기반 프레임워크의 중요한 데이터 처리컴포넌트로 사용중에 있다. 따라서 아직 이 SDO가 산업 전반에 널리 사용되고 있는 것은 아니지만 SOA 환경이 점차 일반화되어 감에 따라 자바 기반의 미들웨어에서 제공하는 서비스 컴포넌트들 간에 메시지의 자유로운 교환과 변환에 가장 널리 사용될 기술이 될 것으로 보인다.

참고 자료

Open SOA Home page (http://www.osoa.org/display/Main/Home) : IBM, Bea, Oracle, Tibco등 17여개 벤더들이 참여하고 있는 SCA표준화 단체

Tuscany (http://incubator.apache.org/tuscany/): Apache에서 개발중인 SCA기반의 오픈소스 프로젝트. SCA, SDO, DAS(Data Access Service)등을 이용하여 자바 뿐만 아니라 C++, PHP 기반의 참조구현을 개발

DWs> Building SOA Solutions with the SCA part 1,2,3,4 (http://www.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_brent.html) : SCA기반의 SOA애플리케이션 개발에 관련된 개발 관련 자료.

지금 시간 새벽 2시를 넘어가네요.
청와대를 지척에 두고 경찰은 시민들을 향해 물대포를 쏘고 시간이 갈 수록 전경부대들은 시민들과의 대치에 과격함을 더해가는 와중에 감기몸살이 심하게 몰려와 아쉽게도 이렇게 집에 왔습니다. 아마도 뭔가 큰 일이 벌어질 것 같은데 이런 상황에서는 한명이라도 더 힘을 실어줘야하는데 먼저 집에 오게되어 남아있는 촛불들에게 미안하였습니다. 부모님이랑 같이 온 유치원,초등학교 아이들도 눈을 또랑또랑하게 뜨고 남아있는데 먼저 오다니... 창피하기 그지없네요.

앞서 설명한 바와 같이 단순히 미들웨어 관점에서만 보면 ESB의 특징은 EAI hub의 그것과 크게 다르지 않은 점을 발견할 수 있다. 그럼에도 불구하고 ESB가 다루는 영역은 애플리케이션간의 통합이 아니라 서비스간의 연계 영역에 있기 때문에 몇가지 구별되는 특징을 가지고 있다. 아래는 2008년 5월 3일 현재 Wikipedia에서 정의하고 있는 ESB의 특징이다. Wikipedia의 정의가 절대적인 것은 아니지만 ESB처럼 상호간에 다른 정의를 내리는 개념에 있어서는 절대 다수의 동의에 의해 만들어진 정의가 오히려 의미가 있다고 할 수 있겠다.

ESB는 서비스 제공자와 소비자 사이에 다음과 같은 역할을 담당한다.

• Invocation: 동기 및 비동기같은 다양한 전송 프로토콜을 지원한다.
• Routing: 정적인 라우팅 뿐만 아니라 메시지 내용 기반 동적인 라우팅, 룰 기반 라우팅, 정책 기반 라우팅과 같은 다양한 동적인 라우팅 기능을 제공
• Mediation: 서로 다른 프로토콜과 서로 다른 서비스 차이를 매개해주는 중개자 역할을 담당한다.
• Messaging: 메시지 변환이나 메시지 enhancement와 같은 고급수준의 메시지 처리 기능을 제공한다.
• Process choreography: 서비스들을 묶어내어 보다 복잡한 기업 비즈니스 프로세스를 처리할 수 있는 엔진을 제공한다.
• Service orchestration: 서비스들에 대한 조합 및 통합 기능을 제공하여 보다 추상화되고 보다 고급 비즈니스에 맞는 형태로 조율하는 기능을 제공한다.
• Quality of Service: 보안이나 전송 보장 기능 그리고 트랜잭션 관리 기능을 제공한다.
• Management: BAM이나 audit, logging 그리고 과금이나 관리기능등을 제공한다.

위의 기능들은 상당 부분 EAI hub의 기능과 유사한 반면 보다 자세히 살펴보면 EAI hub의 기능보다 보다 동적인 요구사항이 반영되어 있으며 그 외에도 다양한 비즈니스 요구사항을 만족시키기 위한 기능이 더 추가되어 있는 것을 확인할 수 있다. 이를테면 Process choreography 기능은 BPM엔진을 말하고 있는데, ESB를 통해 기업내에 통합된 View형태로 서비스들을 관리할 수 있기 때문에 ESB내에 BPM엔진을 연결시킨다면 얼마든지 전사적인 차원에서의 BPM 환경을 구축할 수 있게 될 것이다. 뿐만 아니라 BAM이나 과금과 같은 영역은 과거 EAI영역에서는 감히 다루지 못했던 상당히 고급 수준의 추상화된 비즈니스 영역의 요구사항이 반영된 결과라고 하겠다.

앞서 살펴본 ESB의 특징은 상당히 일반적인 수준에서의 ESB가 갖고 있어야할 것들이다. 여기서 우리는 ESB가 가져야할 보다 근본적인 특징 하나를 생각해보자.

Loosely coupling

ESB가 기존의 EAI hub에 비하여 갖고 있는 아키텍처적 관점에서의 강조된 특징은 결국 서비스의 ‘동적인 연결 지향’이라고 하겠다. ‘동적인 연결 지향’이란 것은 결국 물리적인 서비스와 논리적인 서비스간의 관계를 최대한 느슨하게 연결지음으로써 그 연결에 변화가 일어났을 경우 변화를 반영하는 데 걸리는 시간과 노력을 최소화하려는 의지라고 볼 수 있다.

그림 13.서비스와 긴밀하게 연결되어 있는 프로세스

그림 13은 만약 결혼 절차 프로세스상의 각각의 Activity가 실제 구현이 되어있는 실체가 있는 서비스와 긴밀하게 연결되어 있는 구조를 나타내고 있다. 1000만원 이상의 비용을 감당할 수 있다면 B예식장으로 선택하고 그 이하의 비용만을 감당할 수 있다면 A예식장으로 선택할 수 있게끔 프로세스가 설계되어있다. 이렇게 긴밀하게 연결(Tightly coupling)되어 있는 상황에서는 변화에 대응하는 것이 아무래도 버거워진다. A예식장이 고급화전략을 통해 1000만원 이하로는 도저히 타산을 맞출 수 없게 되었을 경우 결혼절차 프로세스상의 조건 activity를 수정해야하고 해당 activity와 연결된 A예식장 링크를 수정하거나 없애야하는 번거로운 절차가 끝난 후에라야 결혼 절차 프로세스는 서비스를 재가동 할 수 있을 것이다.

그림 14.실제 서비스와 느슨하게 연결되어 있는 프로세스

반면에 그림 14에서는 실제 서비스는 ESB에 의해 추상화되어 ‘고급 예식장’, ‘일반 예식장’이라는 개념으로 정의되어있고 프로세스상의 각 activity들은 실제 구현되어있는 서비스를 가리키고 있는 것이 아니라 ESB에서 정의되어 있는 추상화된 서비스들을 가리키고 있다. 이러한 느슨한 연결덕분에 고급 예식장의 정의가 변경되거나 조건이 변경되거나 개별 예식장들의 연결 환경이 변경되더라도 전체 시스템에 영향을 미치지 않고 바로 적응 가능한 아키텍처가 만들어진다.

따라서 ESB상에 존재하는 서비스는 크게 두가지로 나뉜다고 볼 수 있는데 첫번째는 논리적인 서비스 즉 인터페이스와 비즈니스 의미를 지닌 데이터로만 이루어진 실체가 없는 서비스, 두번째는 구현되어 실행가능한 서비스이다. 이 두가지의 서비스는 서로 느슨하게 연결되어 유연한 서비스 환경을 만들어가게 된다.

그림 15.느슨한 연결은 다양한 시각에서 서비스를 바라볼 수 있게한다

그림 15에서 보는 바와 같이 느슨한 연결은 ESB에 있어서 여러가지 장점을 기업 IT환경에 제공해준다. 첫번째는 서로 다른 Role을 가진 기업내의 사용자들이 자신들의 관점에 맞게 기업 IT환경을 바라볼 수 있게 해준다는 점이다. 비즈니스 전문가는 논리적인 서비스만 바라보고 그것들을 비즈니스 로직에 맞게 조합하고 변경할 수 있으며 운영자는 운영자의 관점에서 비즈니스 요구사항과 IT자산을 연결하는 작업을 ESB상에서 쉽게 시도할 수가 있다. 개발자 역시 자신이 맡은 애플리케이션과 그것의 서비스에만 관심을 기울이면 되는 것이다. 앞서도 언급했지만 이러한 느슨한 연결은 기업 IT환경을 보다 유연하게 하는 장점을 제공한다.

이렇게 느슨한 연결(Loosely coupling)은 기업 IT환경에 유연함이라는 선물을 제공해주는데 SOA 혹은 ESB이전에는 이러한 느슨한 연결이 없었을까? 아니다. 이러한 느슨한 연결은 IT환경이 그동안 발전해오면서 끊임없이 고민해왔던 주제이고 ESB는 이러한 느슨한 연결에 대한 시도끝에 나온 절묘한 대안이라고 할 수 있다. 앞서 설명했었던 A예식장의 IT서비스 시스템을 예로 들어보자.

그림 16.개별 애플리케이션은 컨테이너에 종속적이다.

A예식장의 예약 서비스 시스템을 보면 가장 맨 하단에 실제 물리적인 데이타베이스를 논리적인 부분으로 보다 느슨하게 연결한 DomainLogic 컴포넌트를 갖고있으며 이를 보다 추상화시켜 비즈니스 로직을 수행할 수 있는 비즈니스 로직 컴포넌트와 Presentation 로직 컴포넌트가 있다. 이렇게 이들은 충분히 컴포넌트화되어 독립적으로 수행될 수도 있는 단위로까지 설계했지만 그럼에도 불구하고 이들 컴포넌트들은 여전히 무언가에 독립적이지 못하다? 무엇에 독립적이지 못할까? 이들은 결국 Runtime을 위한 영역이기 때문에 컨테이너에 독립적일 수가 없다. 이들은 상당히 많은 부분을 보다 물리적이고 구체적인것들로부터 자유롭게 했지만 그럼에도 불구하고 여전히 컨테이너에 많은 빚을 지고 있다. 더욱이 이들을 외부에서 호출하기 위해서는 컨테이너만의 특성을 이해하고 컨테이너가 지시하는 대로 따라야만 한다. 이를테면 이 컨테이너가 JavaEE 컨테이너라면 RMI기반의 EJB호출 방식을 쓰거나 JMS 호출방식을 사용해야만 할 것이다. 설사 이들이 외부에 HTTP기반 웹서비스를 제공한다고 할지라도 여전히 이들 컴포넌트들은 웹서비스 프로토콜로 자신들을 호출하기를 강제하고 있다.

지금까지 ESB는 느슨한 연결을 극대화한 미들웨어임을 강조하였다. ESB의 수많은 특징에도 불구하고 이 느슨한 연결을 가장 첫번째로 뽑아서 강조한 이유는 이 느슨한 연결에 대한 ESB의 지향성이야말로 ESB를 다른 것들과 대비되게 하는 핵심 요소이기 때문이다. 대체 얼마나 여러가지 요소들을 추상화해놓고 아키텍처를 잡았길래 이러한 느슨한 연결의 미들웨어를 만들 수 있었을까? 느슨한 연결을 위해 탄생한 스펙이 있으니 그것이 바로 SCA(Service Component Architecture)이다. 다음 포스트에서는 이 SCA에 대해 집중적으로 알아보자.

참고자료

DWs> 대단위 (Coarse-Grained) 대 소단위 (fine-grained) ( http://www.ibm.com/developerworks/kr/library/ws-soa-granularity/) : Coarse-grained와 fine-grained에 대하여 자세하게 설명하고 있는 자료.

당신이 소위 인생컨설팅 회사의 사장의 입장이라고 하자. 누군가의 인생에 대해 조언을 하고 구체적인 조언을 하는 인생에 관련된 토탈 솔루션을 제공하는 회사의 사장이라고 할 때 당신은 일단 사람들의 인생의 중요한 순간을 나눠서 보다 세부적인 영역으로 구분하여 각각의 컨설턴트들을 배치할 것이다. 사람의 인생은 아마도 다음과 같이 보편적인 영역으로 나눌 수 있을 것이다.

그림 6. 인생의 Business Domain

이것이 바로 당신의 사업 영역이 되겠다. 이제 당신이 다시 결혼 부분에서의 전문 컨설턴트라고 해보자. 당신이 누군가의 결혼에 컨설팅을 하기 위해서는 어떠한 분야를 잘 알고 있어야 할까? 당신이 컨설팅해야할 보다 구체적인 영역을 나열해본다.

그림 7. 결혼분야 에서의 비즈니스 서비스

그림 7이 바로 컨설턴트인 당신이 실제로 고객에게 서비스해야 항목들이다. 상당히 추상적인 수준에서 그림 7까지 오는 동안 많은 부분이 구체화가 되었지만 아직까지도 실제로 각각의 서비스가 어떻게 고객에게 전달되는지에 대해 명확하지 않은 점이 있다. 여기서 다시 ‘결혼식’에 관련된 비즈니스 서비스 부분을 보다 구체화해서 세부적인 서비스 항목을 추출해보자.

그림 8.결혼식 비즈니스 서비스의 세부 서비스 컴포넌트

결혼식은 아무래도 당사자의 취향뿐만 아니라 가용한 금액에 따라 그 수준이 달라질 가능성이 있다. 따라서 컨설턴트는 고객의 잔고를 기반으로 하여 다양한 결혼 절차 프로세스를 미리 준비해야 하고 그에 따른 적절한 예식장을 선택하는 가이드를 제공해야한다. 이렇게 도출된 서비스들을 보다 세부적으로 그 기능별로 구분해보면 어떤 것이 서비스인지를 보다 명확하게 확인할 수 있을 것이다. 이 세가지 서비스를 기능별로 분류해보자.

그림 9.기능별 서비스 컴포넌트의 분류

당신은 지금까지 컨설팅회사 사장이 되어 때로는 컨설턴트가 되어 당신이 제공해야할 컨설팅 분야를 보다 세부적으로 분류하였고 결국 그림9에까지 와서 당신이 제공해야할 서비스를 더 쪼갤 수 없을 정도로 분류해내었다. 위로 갈수록 서비스는 보다 추상적이고 아래로 내려갈 수록 서비스는 보다 구체화되는 것도 인식할 수 있었을 것이다. 이렇게 서비스를 보다 잘게 잘게 쪼개어갈 수록 Granularity는 작아진다. Granularity란 우리나라 말로 ‘잘게 잘게 쪼개어진 정도’를 말한다. 이 granularity라는 개념은 상당히 다양한 용도로 쓰이고 있기 때문에 그것을 명확하게 무엇이다라고 설명하기란 쉬운 일이 아니다. 먼저 이것은 상당히 상대적인 개념이다. Granularity에는 Coarse-Grained와 Fine-Grained라는 개념이 있다. 이는 서로 반대되는 개념으로써 전자는 보다 더 뭉쳐져있는 정도를 말하고 후자는 보다 잘게 잘게 쪼개져있음을 의미한다.

당신이 컨설팅회사 사장이라면 당신이 주로 관심을 가지고 있어야할 부분은 그림 6과 그림 7정도의 수준일 것이다. 당신은 당신 회사가 집중해야할 사업 분야를 어떤 것을 해야할 지 그리고 각 사업분야에 최고의 컨설턴트들을 관리하는 것에 보다 관심을 기울일 것이다. 따라서 당신에게 필요한 Granularity는 상당히 추상화된, 상당히 Coarse-grained한 것들일 것이다. 반면에 컨설턴트는 그림 8이나 그림 9에 관련된 내용에 보다 집중하고 관심을 기울일 것이다. 그들은 실제로 고객에게 서비스를 제공해야하는 사람들이기 때문이다. 즉 컨설턴트들은 컨설팅 회사 사장의 View보다 더 Fine-grained하다는 것을 알 수 있다.

이렇게 Granularity라는 요소는 이것이 비즈니스인가 도메인인가 아니면 서비스인가를 판별하는 중요한 잣대가 된다. Granularity관점에서 보았을 때 비즈니스적으로 더이상 쪼갤 수 없을 만큼 쪼갠 상태의 것을 우리는 서비스 혹은 서비스의 컴포넌트라고 부른다. 위의 그림 9에서 당신은 여러 개의 서비스들을 찾아내었다. 결혼식 서비스에 포함되는 세부 서비스에는 크게 ‘결혼 절차’, ‘예식장 예약’, ‘잔고조회’ 서비스가 있으며 이것들은 각각 기능별로 서로 다른 특징을 가지고 있다. 먼저 ‘잔고 조회’ 서비스는 단순히 고객의 은행DB에서 고객이 소유하고 있는 잔고를 조회하는 단순한 조회성 업무이다. 이 서비스에는 별다른 로직도 들어가지 않고 그저 DB에 대한 내용을 투명성있게 응답해주는 기능만 있다. 주로 이러한 기능을 담당하는 것을 ‘데이타 서비스’라고 부른다. 반면에 ‘예식장 예약’서비스는 해당 서비스가 컨설턴트의 담당이 아니라 실제 특정 예식장과 연계되어 동작해야만 하는 서비스이다. 이렇게 외부 서비스와의 연계에 의한 서비스를 ‘Integration 서비스’라고 부른다. ‘결혼 절차’ 서비스는 이렇게 모여있는 서비스들을 묶어서 적절한 프로세스를 제공하는 서비스이다. 잔고가 500만원 이하라면 저렴한 예식장을 선택하고 그 이상이면 적절한 예식장을 선택하게 하는 프로세스를 생각해볼 수 있을 것이다. 이러한 비즈니스 프로세스가 제공되는 서비스를 ‘프로세스 서비스’라고 부른다. 그외에도 서비스에는 ‘기능(Function) 서비스’라는 것도 존재하며 이러한 기본적인 서비스들이 모여서 비즈니스적인 서비스들이 제공된다.

그렇다면 이렇게 비즈니스적인 부분에서만 서비스가 존재할까? 좀 더 구체적인 구현 수준으로 내려가면 어떨지를 살펴보자. 이번에는 당신은 A예식장의 담당자로서 A예식장의 온라인 예약시스템을 구현해야한다.

그림 10. A예식장의 예약시스템 구성도

그림 10은 A예식장 IT시스템 담당자인 당신이 구축한 시스템이다. Presentation layer에서는 예약에 필요한 사용자의 interaction을 처리할 것이고 Business Logic layer에서는 예약절차에 필요한 A예식장만의 비즈니스 로직을 처리하기 시작할 것이다. 더 밑으로 내려가서 Domain Logic layer에서는 보다 구체적이고 실제적인 데이타를 가지고 처리하는 컴포넌트가 들어있을 것이고 더 밑으로 내려가면 물리적인 데이타베이스가 존재한다. 여기서도 마찬가지로 Granularity는 위로 갈수록 Coarse-grained에 가깝고 아래로 내려갈 수록 Fine-Grained에 가까워진다. 즉 DomainLogic layer에서 다루는 것은 DB의 칼럼같은 보다 잘게 쪼개진 것들을 다루는 반면 Business Logic이나 Presentation layer에서는 예약이나 신용조회, 객석확인과 같은 보다 추상화된 부분들이 다뤄진다. 즉 그 잘게 잘게 쪼개어진 정도가 layer마다 다르다는 것을 알 수 있다.

그런데 아무리 이 시스템으로 Coarse-grained하게 추상화시켜본들 앞서 보았던 비즈니스 수준에서의 추상화 수준으로는 나아갈 수 없는 강한 결합적인 특성을 이 A예식장의 예약시스템에서는 발견할 수 있다. 즉 모든 컴포넌트들은 결국 Container에 종속되어 동작한다는 사실이다. 제 아무리 추상화된 예약이나 신용조회같은 프로세스도 결국은 그것을 실행하기 위한 Runtime에서의 Container나 프로토콜같은 물리적인 영역에 의해 종속된다는 것. 그것이 앞서 보았던 컨설턴트 회사의 시스템에 비교해서 보다 Fine-grained한 영역으로서의 특징을 보여준다고 할 수 있겠다.

그렇다면 Granularity를 결정하는 그 기준에는 무엇이 있을까?

그림 11.Granularity에 영향을 미치는 요소들

그림 11에서 보는 바와 같이 Granularity에 영향을 미치는 요소는 크게 추상화와 데이타 그리고 프로토콜 종속성, 컨테이너 종속성 정도로 볼 수 있다. 구현된 각 시스템들은 아무리 추상화수준이 높다하여도 컨테이너나 프로토콜 종속성 부분을 해결하지 못하기 때문에 비즈니스 서비스에 비하여 Service의 Granularity가 fine-grained한 특성을 가지고 있다.

그렇다면 어째서 Granularity를 이렇게 길게 설명하게 되었을까 되짚어보자. 앞서 ESB가 보다 높은 coarse-grained한 서비스를 위해 존재한다고 하였다. 즉 ESB는 개별 애플리케이션들의 직접적인 integration이 아니라 그보다 더 높은 수준에서의, 서비스 수준에서의 통합을 위해 만들어진 것이다. 그렇게 함으로써 그보다도 더 높은 비즈니스 수준에서의 요구사항에 보다 유연한 대처에 적합하게 만들어진 것이 ESB라고 할 수 있다.

그림 12.기업IT환경에서 ESB가 위치하는 곳

그림 12에서 보는 바와 같이 ESB는 위로는 Top-down방식으로 설계되어 만들어진 비즈니스 서비스를 담고 있으며 아래로는 상당히 물리적인 영역에서 부터 보다 추상화되어 bottom-up방식으로 끌어올려진 기술적인 function위주의 서비스들을 담고 있다. 이렇게 함으로써 ESB는 보다 추상화된 수준으로 IT자산들을 서비스위주로 관리할 수 있으며 위로부터의 변경된 비즈니스 요구사항을 보다 빠르게 조립하여 재구성하는 것이 가능해진다.

SOA는 결국 갈수록 변화에 대한 요구가 치열해지는 기업환경에서 기업의 비즈니스 전략의 변경이 실시간으로 IT에 전파되어 IT가 그 변화에 기민하게 반응할 수 있게 하는데 그 목표를 두고 있다. 때문에 비즈니스 관련자들 관점에서의 비즈니스 분석이 세부적으로 잘 모델링되어 있어야 하고 그것들이 결국 서비스로 도출되면 그 서비스와 실제 IT자산들이 유연하게 연결되어야만 가능하다. ESB는 결국 비즈니스와 IT를 유연하게 연결시켜줄 수 있는 대안으로 나온 것이라고 할 수 있겠다.

이제까지 ESB가 위치하고 있는 곳과 SOA 구현에 있어서 왜 꼭 필요한 것인지를 살펴보았다. 그렇다면 이제 보다 본격적으로 ESB가 갖고 있어야할 특징은 무엇인지 다음 포스트에서 살펴보자

이 블로그때문인지는 모르겠지만
갑자기 EDA와 CEP, BEP에 대한 고객들의 문의가 최근 들어 많이 들어온다.
그래서 몇번 내부 IBMer 및 외부 고객들을 대상으로 세미나를 했는데
반응이 너무 좋다. 내가 특별히 비즈니스 시나리오를 만들지 않아도 알아서 고객들이 스스로 그동안 속썩어왔던 문제들을 EDA에 적용하여 시나리오를 만든다.
그만큼 EDA는 의외로 접근이 쉽고 적용이 빠르다.
하반기에는 EDA로 인하여 많은 기회를 얻을 듯 하고 또 많은 열정이 필요할 것 같다.

아래 사진은 내가 처음 지름신을 영접하여 지르게 된 그 초발심의 증거이다. 1999년에 산 32M 대용량 메모리의 삼성 옙 MP3플레이어.

그 이후로 나는 수많은 전자기기에 탐을 내어 지름신의 계시에 따라 지름을 몸소 행하였으나 지금 남아있는 증거는 위의 기기 이외에는 없다. 왜 그럴까? 그것은 다름이 아니라 그 동안 지른 것들을 모두 다시 또 팔아버렸기 때문이다. 그냥 판 것도 아니다. 내가 샀을 때의 가격과 거의 동일한 가격으로 팔았던 거다. 때문에 나는 이러한 방식으로 수없이 많은 지름을 행하였음에도 불구하고 경제적인 곤란없이 지름신의 부름에 응하였으니 오늘은 대단치 않은 나의 비결을 늘어놀까 한다.

내가 행하였던 방법은 바로 커뮤니티 사이트의 중고시장을 이용하는 것이었으니 쉽게 신제품을 구매하지 않는 인내와 끈기가 필요한 방법이 되겠다.
대개 거의 모든 전자기기들의 중고가는 다음과 유사한 가격흐름을 따르게 된다.



처음 제품이 출시되고 약 한달가량까지는 신제품과 중고사이에 큰 가격차가 생기지 않는다. 물론 그 제품의 평이 극도로 나쁘거나물량이 제대로 시장에 풀리지 않았거나 국내 정식 출시되지 않은 등의 특수한 상황을 제외했을 때를 가정한다. 그러다가 한달에서 두달 혹은 몇 달 사이에 그 제품과 유사한 경쟁 제품이 출시되고 가격 경쟁이 붙으면 제품의 가격도 떨어지고 그와 유사한 경쟁제품도 가격이 떨어지면서 중고가가 서서히 내려가기 시작한다. 나는 이 시기가 지나기를 기다렸다가 중고 제품을 구매한다.

그것을 나는 중고가 정착 1기라고 부른다. 이 시기에는 경쟁 제품들의 가격도 어느 정도 안정화되면서 중고가가 조금씩 내려가기는하지만 어느 정도 지속적인 가격대를 유지하게 된다. 이 때가 바로 원했던 중고제품을 구매하기 좋은 기회인 것이다. 보통 이시기에 중고시장에 제품을 내놓는 사람들은 얼리 어댑터들이기 때문에 제품을 아주 깨끗하게 쓰기 마련이다. 그들은 이미 그것에싫증이 났거나 새로운 제품으로의 지름신 영접에 준비모드에 돌입하고 있다. 보통 제품에 메모리카드나 스킨같은 부가적이기는 하지만결국은 나중에 발품팔아 사게되는 악세사리들까지도 모두 준비가 되어있다. 더욱이 초기 불량으로 호소하는 게시판 글을 모아서 잘 준비만해놓는다면 중고시장에서 내놓아지는 물건들을 불량이 있는지 여부도 새 제품보다 훨씬 꼼꼼히 살펴볼 수 있는 기회가 구매자에게주어진다.

이렇게 해서 중고 제품을 구매했는데 사실 대부분의 전자기기들은 정말 필요한 이유에 의해 오래 쓰게 되는경우도 있지만 적지 않은 경우는 한달도 채 안가서 싫증이 나고 손이 안가게 되는 게 분명히 있다. 그런 것은 이 중고가 정착1기가 지나가기 전에 팔아버리는 신속함을 지녀야한다.

커뮤니티 글을 잘 읽다보면 언제쯤 신제품이 와르르쏟아져나올 지를 예측할 수 있다. 신제품이 막 나올 참이 되는 신제품 출시 한달전부터 중고가는 팍팍 떨어진다. 여기 저기중고장터에 매물이 쏟아져나온다. 정말 되팔지 않을 자신이 있고 오래 쓸 거라 확신한다면 이 때 물건을 산다. 즉 신제품 출시되고중고가가 떨어졌다가 정착이 되는 정착 2기에 중고를 사면 되는 것이다.

이렇게 해서 나는 수중에 정말 필요하다생각되는 전자제품 몇 개를 제외하고는 쓰지 않고 집안 창고에 내팽겨쳐져있는 것이 거의 없다. 물론 수도 없이 많은 전자제품을만져봤지만 금전적으로 손해본 적도 거의 없다. 이것이 바로 지름신을 영접하는 나만의 경제적인 비법이다.