[지디넷코리아]필자가 나이가 들어가는 것인지 모르지만, 한 때 IT 세계는 지금보다는 훨씬 단순했다.

메인프레임 시절 IT가 개발했던 애플리케이션은 단일 데이터 소스를 공유했으며, 이런 애플리케이션의 클라이언트도 동일한 코드 기반과 플랫폼을 공유했다.

'배치(deployment)'와 관련한 문제는 없었으며, 데이터는 접근이 용이한 파일이나 메인프레임 기반의 테이블 내에 존재했기 때문에 애플리케이션 사이에 데이터를 공유하는 것은 쉬운 작업이었다.

클라이언트-서버 시대에도, 파워빌더나 비주얼 베이직을 이용해 IT 전문가들이 만들어낸 팻(fat) 클라이언트 윈도우 애플리케이션은 단일의 관계형 데이터베이스를 데스크톱들과 함께 공유했다.

이러한 아키텍처에서는 애플리케이션이 다른 애플리케이션의 데이터를 업데이트하는 트랜잭션 과정을 통해 데이터를 공유하는 것이 가능했다.

하지만 세상은 바뀌고 있다. 연결성이 보다 강화된 현재 시대에 조직 내부와 조직 사이의 데이터 공유와, 일상적인 하드웨어를 기반으로 애플리케이션의 범주를 정하는 것, 윈도우 데스크톱을 비롯해 기타 웹 사이트, PDA, 태블릿 PC 등 다양한 클라이언트로 지원 범위가 확대된 것과 같은 요소는 과거 한때의 단순한 그림에 반기를 들고 있다.

그렇다면 애플리케이션을 어떻게 이러한 새로운 환경에 적용시킬 것인가?

서비스 지향 아키텍처(SOA)의 세계로 들어가보자.

가장 단순한 형태로, SOA는 일련의 비즈니스 서비스에 중요 요소로 작용할 '조직의 기능성'을 요구한다. 이러한 기능성은 지금까지 개별 애플리케이션에 포함돼 왔던 것이다.

이러한 서비스는 “나는 X를 알고 싶다(I want to know X)”라는 서비스 요청 메시지를 받거나 “여기 해답 Y가 있다(Here is the answer Y)”란 서비스 응답 메시지를 보냄으로써, 소비자 및 기타 내외부 서비스와 커뮤니케이션한다.

이러한 메시지들이 플랫폼이나 장치에 관계 없이 전달되기 위해서 XML, SOAP를 이용해야 하는 것은 당연한 일이다.

설계자나 개발자가 SOA 디자인 및 실행에 관한 고민을 시작할 때 맞부딪치게 되는 문제는 각 서비스들이 공유해야 하는 데이터가 무엇인지와, 이러한 데이터에 대한 접근 및 유지법, 이들을 표현하는 방법 등이다.

여기서는 하나의 SOA 솔루션이 사용하게 될 데이터 유형과, 서비스 내외부 모두에서 이러한 데이터들이 어떻게 표현될 것인가 하는 방법론에 대한 시각을 제시할 것이다.

SOA를 구축할 때 반드시 고려해야 할 4가지 데이터 유형이 있다.

서비스의 외적 요소에서 내적 요소 순으로 살펴 볼 때, 메시지 데이터, 탐색(lookup) 데이터, 프로세스 데이터, 그리고 비즈니스 데이터다.
이러한 데이터의 유형과 특징 등을 정의하고, 이러한 데이터를 처리할 때 필요한 중요 요소들을 살펴보자.

메시지 데이터
서비스 사이를 흘러 다니는 데이터를 메시지 데이터라 한다. 이 데이터는 서비스 요청자가 수행하길 원하는 작업과 소비자가 서비스로부터 받는 결과를 정의한다.

메시지 데이터는 서비스 사이를 흘러 다니는 유일한 데이터이며, 따라서 서비스의 퍼블릭 인터페이스를 표현한다. 이는 SOA를 플랫폼 독립적으로 만드는 요소이기도 하다.

따라서 메시지 데이터는 사용자가 요청을 공식화하고 응답 부분을 처리할 수 있도록 오픈 스키마를 요구한다. 메시지 데이터는 서비스에 의해 노출되는 동작 정의에 있어서 상대적으로 안정적이다. 하지만 변화가 있을 경우 반드시 버전 작업이 적용돼야 한다.

메시지 데이터는 일단 메시지가 쓰여지고 나면 변경할 수 없는 것으로, 절대 수정될 수 없다. 메시지 데이터는 탐색 데이터를 이동시키는 데 흔히 사용된다.

탐색 데이터
서비스가 처리하는 두번째 데이터 유형은 탐색 데이터다.

탐색 데이터는 서비스 요청에서 동작 파라메터를 전달하는데 이용되거나, 서비스 응답을 통해 회신된 데이터를 해석하는 데 사용된다. 서비스 사용자는 탐색 데이터를 요청해 이후 요청 메시지를 형식화하는데 이를 활용할 수 있다.

예를 들어, 기술 교육 서비스를 제공하는 회사는 소비자가 교육 일정을 요청할 때 서비스에 유효한 값을 전달할 수 있도록 교육 장소 및 공급업체 등을 담은 탐색 데이터를 제공할 수 있다.

탐색 데이터는 비교적 정적이지만 변화가 일어날 때에는 반드시 버전 과정을 거쳐야 하며, 이렇게 변형된 탐색 데이터는 바꿀 수 없게 된다. 메시지 데이터와 마찬가지로 탐색 데이터도 서비스에 대해 외적 요소로 활용되며, 따라서 오픈 스키마를 요구한다.

서비스들은 각 아이템을 정의하고, 정의된 아이템을 버전 식별기로 찍는 과정에서 탐색 데이터를 취급한다. 예를 들어 큐일로지의 로케이션코드 v012004가 이에 해당한다.

이러한 방법을 통해 소비자의 요청에 대해 레퍼런스 데이터의 버전을 전달, 서비스가 적절한 응답을 생성할 수 있도록 하는 것이다.

프로세스 데이터
서비스 내에서 사용자가 가장 먼저 대하는 데이터 유형이 바로 프로세스 데이터다.

메시지 및 탐색 데이터와 달리 프로세스 데이터는 해당 서비스에만 공개된 것으로 완전히 서비스 내부에서만 활동한다. 따라서 오픈 스키마를 요구하지 않는다. 프로세스 데이터는 해당 서비스가 실행하고 있는 비즈니스 프로세스나 기능을 표현한다.

전형적으로, 이러한 프로세스나 기능은 장기간에 걸친 동작(궁극적으로는 종료되는)이라 할 수 있다. 예로는 쇼핑몰의 쇼핑 바구니, 구매 내역, 그리고 송장(invoice) 등이 있다.

프로세스 데이터는 클라이언트 독립적이며, 하나의 클라이언트에 의해서만 접속된다. 탐색 데이터와 달리 작업이 이뤄지는 동안 업데이트도 가능하지만, 일단 작업이 완료되면 읽기만 가능하다. 따라서 프로세스 데이터는 시간이 지날수록 참조가 현저히 줄어든다.

서비스 프로세스는 메시지를 요청하고, 해당 대화의 서비스 내에서 프로세스 데이터를 구축하는 작업에 착수한다. 따라서 해당 대화 인식기 내부에서 프로세스 데이터는 상호 관련돼야 한다.

서비스 내에서 프로세스 데이터를 다루는 방법은 다양하다. 예를 들어 프로세스가 활성화된 시점에는 프로세스 데이터를 객체 내에서 캡슐화해 메모리에 캐시 로 보존할 수 있다.

서비스 내부의 폐기되거나 버려진 프로세스는 말끔히 정리돼야 한다.

비즈니스 데이터
SOA에서 사용하는 데이터 유형 중 마지막이 바로 비즈니스 데이터다.

대부분의 사람들이 고객 정보, 제품 인벤토리, 은행 계좌와 같은 애플리케이션에 대해 생각할 때 떠올리는 데이터가 바로 비즈니스 데이터다.

프로세스 데이터와 마찬가지로 비즈니스 데이터 또한 특정 서비스에 종속적이며 오픈 스키마를 필요로 하지 않는다.

하지만 프로세스 데이터와는 달리 비즈니스 데이터는 단독으로 장기간 운영되는 동작보다는 수명이 길다고 할 수 있으며, 동시에 수행되는 여러 가지 작업에 의해 변경될 수도 있으므로 동시성에 대한 요구 수준이 높은 편이다.

그 결과, 비즈니스 데이터는 본질적으로 휘발성이 강한 특징을 지닌다.

서비스가 비즈니스 데이터와 상호 작용하는 가장 중요한 방법은 '단독 소유자의 원칙'에 충실한 방법이다. 다시 말해서, 각 서비스는 조직 내에서 특정 부분의 데이터를 소유하고 있다고 할 수 있다. 예를 들어 직원 데이터를 갖고 있는 서비스가 있고, 고객 데이터를 갖는 서비스가 있다.

데이터 공유가 필요할 경우 각 서비스는 다른 서비스에 변경 사항을 알리게 되며, 이는 캐시로 저장된다.

데이터 업데이트는 해당 서비스의 소유자만 할 수 있다. 즉 만약 소유자가 아닌 사람이 변경을 요청하게 되면, 서비스는 변경을 적용해 해당 작업자에게 데이터를 발행하게 된다.

다음 글에서는 각 데이터 유형의 처리방법에 대해 알아보겠다. @