본인이 점점 나이를 먹어서인지도 모르겠지만 옛날에는 IT 세계가 참 단순했다.
대기업이 시장을 지배할 당시 IT 부서가 개발한 애플리케이션들은 대부분 단일한 데이터 소스를 공유했으며 애플리케이션 클라이언트 같은 경우도 동일한 기반 코드와 플랫폼을 공유했다. 데이터는 쉽게 접근되는 파일이나 메인프레임 테이블에 존재했기 때문에 배치 문제도 없었고 애플리케이션 간 데이터 공유도 쉬웠다.
한 시대를 풍미한 클라이언트/서버(C/S) 컴퓨팅에서도 역시 파워빌더나 비주얼 베이직으로 개발된 덩치 큰 윈도우 애플리케이션 클라이언트는 ‘엔터프라이즈 데이터 모델’로 불리는 단일한 관계형 데이터베이스를 공유했다. 이를 가능케 하는 서비스 데스크톱도 회사 내에 위치해 있었다.
이 아키텍처는 애플리케이션들이 트랜잭션을 통해 다른 애플리케이션의 데이터를 업데이트하는 방식으로 데이터 공유를 허용했다.
그러나 세계는 변화하고 있다. 모든 것이 연결된 세계에서 ▲기업내 혹은 기업간 데이터 공유에 대한 필요성 ▲범용 하드웨어에 애플리케이션을 확장해야하는 필요성 ▲윈도우 데스크톱 PC에서 다른 웹사이트나 PDA, 태블릿 PC에 걸친 다양한 클라이언트를 지원할 필요성 등으로 한때 간단했던 그림이 지금은 매우 복잡해진 상태다.
과연 애플리케이션들을 이 화려한 신세계로 어떻게 가지고 나올 수 있을까? 정답은 바로 서비스 지향 아키텍처(SOA)다.
가장 단순하게 분류해보면 별도의 애플리케이션들이 각각 수행하던 기능은 SOA에서 비즈니스 서비스 집합으로 나눠지게 된다. 이 서비스들은 ‘X를 알고 싶다’와 같은 서비스 요청 메시지를 수신하고 ‘Y는 여기 있다’라는 서비스 응답 메시지를 송신함으로써 고객, 그리고 내/외부의 서비스와 서로 통신을 주고 받는다. 이런 메시지들이 플랫폼, 장비에 독립적이려면 XML과 SOAP으로 표현, 전달되야 한다는 것은 매우 당연한 사실이다.
그러나 아키텍트, 개발자들이 SOA 설계와 구현에 대해 실제적으로 생각하면서 문제가 발생한다. 여기에는 어떤 데이터 서비스를 공유하고 데이터 접근과 관리는 어떻게 할지, 데이터를 어떻게 표현할 지와 같은 것들이 있다.
이 기사에서는 SOA에 사용되는 데이터의 유형들을 살펴보고 서비스 내/외부에 존재하는 데이터의 표현 방법을 알아볼 것이다. 아래 기술되는 내용은 SOA를 고려하기 시작한 바로 그 시점에 당신의 생각을 명확히 하는데 도움이 될 것이다.
어떤 데이터를 표현해야 하나?
SOA를 구축할 때에는 4가지 데이터 유형을 우선 고려해야 한다. 이들은 서비스 외부에서 내부로 들어가는 순서에 따라 메시지 데이터, 조사 데이터, 프로세스 데이터, 비즈니스 데이터로 나눠진다. 이제 각 데이터들의 유형과 특징을 정의하고 데이터를 다룰 때 필요한 정보가 뭔지 살펴보자.
메시지 데이터
서비스 사이를 흘러 다니는 데이터를 메시지 데이터라고 한다. 이 데이터는 서비스 사용자가 원하는 업무나 동작인 ‘요청’과 그 결과로 고객이 받는 ‘응답’을 정의해준다.
서비스와 서비스 사이에는 이 데이터만이 송수신될 수 있다. 따라서 메시지 데이터는 서비스의 개방형 인터페이스를 표상하는 역할도 함께 담당한다. 이로 인해 SOA는 플랫폼 독립적인 성격을 갖게 된다.
정의에 따르면 메시지 데이터는 사용자가 요청을 구성하고 응답을 처리하는 방법을 발견할 수 있도록 하는 개방형 스키마(schema)를 요구한다. 따라서 ‘서비스에 의해 노출되는 동작’이라는 정의에 비춰볼 때 메시지 데이터는 비교적 정적인 성격을 갖는다.
그러나 변화가 생기면 분명히 버전을 명시해 관리해야 한다. 또한 메시지 데이터는 한번 작성되면 바꿀 수 없으며 변경 자체가 불가능하다.
서비스들은 생성시각, 버전 id, 대화 id, 대화 내부의 일련번호 뿐 아니라 각 메시지별로 유일 식별자를 생성해 메시지 데이터를 다룬다. 물론 보안 토큰도 여기에 포함된다.
이렇게 추가 정보를 이용하면 서비스는 생성시각을 참조해 제때 도착하지 않은 메시지를 버리는 등 메시지들을 적절한 순서로 한번만 처리할 수 있다. 또한 서비스는 여러번 도착한 메시지에 대해 이전에 만들어 캐시해놓은 응답을 보내 해결하기 위해 요청과 응답을 저장해놓는다. 이런 과정은 성능도 향상시킨다. 메시지 데이터는 조사 데이터를 이동시키는데 자주 사용된다.
조사 데이터
서비스에서 다뤄지는 두번째 데이터는 조사 데이터다. 이 유형의 데이터는 서비스 요청 동작의 일환으로 매개변수를 전달하거나 서비스 응답에서 온 데이터를 해석하는데 사용된다. 이 과정 이후 사용자는 조사 데이터를 요청하게 되며 이후 요청 메시지를 구성하기 위해 조사 데이터를 사용하게 된다.
예를 들어 기술 교육 제공 업체는 교육 장소와 업체들로 구성된 조사 데이터를 발행할 수 있다. 따라서 사용자들은 수업 스케줄을 요청할 때 유효한 값들을 전달할 수 있다.
예상하겠지만 조사 데이터도 비교적 정적이다. 그러나 변화가 있을 때는 버전 관리를 해야 한다. 즉 각 버전의 조사 데이터끼리는 변화가 없는 것이다. 메시지 데이터처럼 조사 데이터도 서비스 외부에서 사용되며 개방형 스키마를 요구한다.
서비스는 조사 데이터를 다룰 때 각 항목에 유일한 버전 id를 부여한다. 예를 들면 ‘퀼로지-위치코드-v012004’와 같은 식이다. 이 방식대로라면 사용자는 요청 작업을 수행할 때 참조 데이터 버전을 전달하기 때문에 서비스가 적절한 응답을 만들어낼 수 있다.
결국 조사 데이터는 일반적으로 정기적인 갱신 작업을 요구하게 된다. 따라서 서비스는 이메일, HTTP, 심지어 DVD까지도 사용하는 푸시(push) 방식이나 HTTP, FTP, 이메일을 이용한 풀(pull) 방식을 사용해 새로운 버전을 관심있는 가입자들에게 전달한다.
프로세스 데이터
서비스 내부에서 최초로 다뤄지는 데이터가 바로 프로세스 데이터다. 메시지나 조사 데이터와는 달리 프로세스 데이터는 각 서비스마다 고유하며 내부에 감춰지기 때문에 개방형 스키마가 필요없다.
프로세스 데이터는 서비스가 수행하는 비즈니스 절차나 기능 등을 표현한다. 대개 이 데이터들은 장기적인 동작 과정을 거쳐 완성된다. 이의 예로는 쇼핑 바구니, 구매 명령, 송장 등이 있다.
프로세스 데이터는 클라이언트나 대화에 의존적이며 단일 클라이언트에 의해 순차적으로 접근되기 때문에 병행성에 대한 요구가 낮다. 조사 데이터와 달리 동작 중에도 업데이트할 수 있으며 동작이 완료되면 일반적으로 읽기만 가능한 상태가 된다. 따라서 시간이 갈수록 참조 회수도 작아진다.
서비스 프로세스는 메시지를 요구하고 서로 대화하기 위해 서비스 사이에 프로세스 데이터를 구축하게 된다. 따라서 이들은 대화 인식자를 이용해 프로세스 데이터와 상관관계를 유지해야 한다.
서비스는 프로세스 데이터를 조작하는 다양한 기법을 사용할 수 있다. 예를 들면 프로세스가 활성화된 시간 동안 서비스는 프로세스 데이터를 객체에 캡슐화해 메모리에 캐시할 수 있다. 또한 서비스는 종료되거나 포기된 프로세스를 깨끗하게 제거할 수 있어야 한다.
비즈니스 데이터
SOA에서 사용되는 데이터의 마지막 유형은 비즈니스 데이터다. 이 유형은 고객 정보, 제품 재고, 은행 계좌들처럼 사람들이 애플리케이션을 생각할 때 떠올리는 바로 그것들이 대부분이다.
프로세스 데이터처럼 비즈니스 데이터도 각 서비스마다 고유하며 개방형 스키마를 필요로 하지 않는다. 그러나 프로세스 데이터와 달리 단일한 장기적 동작보다는 그 수명이 길며 여러 동작에 의해 동시에 변경될 수 있기 때문에 병행성에 대한 요구가 높다. 결과적으로 비즈니스 데이터는 휘발성이 강하며 본질적으로 유동적인 자료의 형태에 가깝다.
서비스가 비즈니스 데이터와 상호작용할 때 가장 중요한 부분은 단일 소유주의 원칙에 충실해야 하는 것일 것이다. 즉 서비스는 기업의 일부 데이터에 대해 소유 권한을 가져야 한다.
예를 들어 한 서비스는 고객 데이터를, 다른 서비스는 직원 데이터를 가질 수 있다. 데이터 공유가 필요한 경우 각 서비스는 변경사항을 다른 서비스에 공개하고 다른 서비스들은 내부에서 사용하기 위해 이것을 캐시한다.
따라서 서비스 데이터의 공개는 늘어나는 각 식별자들과 함께 버전이 관리돼야 한다. 서비스의 소유자만이 데이터를 업데이트 해야 하며 소유자가 아닌 사용자에 의한 변화 요청이 제기될 경우 소유권을 가진 서비스는 변경 작업을 진행한 이후 관심있는 가입자에게 해당 데이터를 재공개하는 절차를 밟아야 한다.
데이터 유형을 다루고 저장하는 방법은?
데이터 유형이 정의되면 이것을 처리하고 저장하기 위해 어떤 기술을 사용해야 할지 궁금할 것이다. 바로 XML, 객체, SQL이 기술의 핵심을 이룬다.
메시지 데이터
메시지 데이터는 개방형 스키마과 이질성을 요구하므로 SOAP을 이용한 모델이 가장 적합하다. 따라서 WSDL을 이용한 메시지 스키마를 발행할 수 있다. 또한 생성시각과 보안과 같이 구현하고자 하는 메시지 데이터 기능의 일부는 WS-*와 같은 SOAP 표준이나 MS의 웹서비스 인핸스먼트(WSE) 2.0과 같은 툴킷으로 구현할 수 있다.
서비스 내부에서는 동일성을 구현하기 위해 관계형 데이터 내부에서 인식 속성이 메시지 데이터에 XML 형태로 저장될 수 있다. 속성에 질의문이 주어질 가능성이 크기 때문에 이 방식이 권장될 수 있긴 하지만 불변성 측면에서 볼 때 메시지 내용을 자주 읽고 파싱(parsing)하는 것은 좋지 않다.
또한 메시지를 저장하면 감사, 그리고 향후 진행될 분석이 가능해진다. 그러나 유형 정의에 비춰볼 때 메시지 데이터는 가장 생명이 짧다. 또한 분석에 사용되지 않는다면 더 쉽게 저장될 수 있다.
메시지 데이터에 대한 또다른 측면은 서비스 간 메시지 송신이 이뤄질 때 어떤 일이 발생하는가에 관한 것이다. 독립적으로 전개되는 다중 서비스에 메시지 구조가 사용되는 조직 환경에서는 메시지가 서비스에 의해 소비되기 이전에 표준 스키마로 변환되도록 조치하는 것이 좋다. 이는 조사, 비즈니스 데이터를 각 서비스가 다른 형태로 표현할 때 일어날 수 있는 문제점들을 미연에 방지해주며 데이터 변환의 횟수를 획기적으로 줄일 수 있다.
조사 데이터
조사 데이터는 공개적이며 개방형 스키마를 요구하기 때문에 XML로 모델링돼야 한다. 즉 버전 정보를 표시하면서 조사 데이터의 스키마를 WSDL로 나타내는 방식이 좋다. 데이터베이스 측면에서 볼 때 조사 데이터는 한번만 기록되고 XML에 의해 직접 추출될 수 있기 때문에 성능 증가의 목적으로 관계형 테이블의 XML로 저장될 수 있다.
또한 관계형 테이블에 조사 데이터를 저장함으로써 버전 관리도 쉬워진다. 서비스는 내부적으로 메모리에 현 조사 데이터를 캐시할 수 있다. 이렇게 되면 사용자가 조사 데이터를 요청할 때 응답시간을 단축할 수 있다.
프로세스 데이터
프로세스 데이터는 서비스에 고유하기 때문에 XSD로 발행되거나 XML로 표시될 필요가 없다. 따라서 대개 표준화된 관계형 데이터베이스 테이블로 저장되며 예를 들면 비쥬얼 스튜디어 닷넷 ‘위드비(Whidbey)’와 함께 출하될 오브젝트스페이스(ObjectSpaces)와 같은 객체 보존 계층을 사용해 서비스 내부에 캡슐화된다.
이와 같은 방식으로 서비스는 메모리에서 프로세스 데이터를 완전한 객체로 처리하고 ASP.NET 캐싱 엔진과 같은 캐시 기술을 활용할 수 있다. 프로세스가 완료되거나 대기 상태에 들어가면 객체는 객체보존 계층을 이용해 데이터베이스에 차례로 나열된다.
프로세스 데이터는 단일 대화 내부에서 순차적으로 업데이트되기 때문에 병행성에 대해 낙관적일 수 있다. 분석을 위해 중요한 프로세스 데이터를 저장하는 것도 필요하다. 그러나 만들어진지 오래될수록 데이터들은 아카이브 형태로 보존될 것이다.
비즈니스 데이터
프로세스 데이터처럼 비즈니스 데이터는 서비스에 고유하며 XML로 표현되지 않는다. 물론 일부가 응답 메시지로 보내지는 경우는 예외다. 이런 경우 정형화된 XSD가 생성돼 다른 서비스들이 이 데이터를 해석할 수 있다.
따라서 비즈니스 데이터는 표준화된 관계형 테이블에 저장되며 COM+와 같은 트랜잭션 관리자에 의해 관리되는 구성요소를 통해 캡슐화된다. 이것은 트랜잭션 과정에서 병행성을 비관적으로 만들어 잠금을 보장하기 위한 것이다.
구성요소 자체는 데이터에 상태와 상관없는 접근을 제공하는데 이것은 높은 휘발성과 병행성 때문이다. 비즈니스 데이터는 프로세스 데이터와 결합돼 분석에 사용된다.
모델 산출
아래 그림에는 여기서 논의된 4가지 데이터 유형이 요약돼 있다. SOA를 개발할 때 독자들이 소속된 기업의 데이터를 위치시킬 수 있는 그림을 그리는데 도움이 됐으면 한다. 여기에는 SOA에서 사용되는 4가지 데이터를 강조하고 있으며 이들이 어떻게 표현되고 처리되는지 보여주고 있다. @
http://images.zdnet.co.kr/images/2004/06/69587-1.jpg
SOA 개념상 모델
대기업이 시장을 지배할 당시 IT 부서가 개발한 애플리케이션들은 대부분 단일한 데이터 소스를 공유했으며 애플리케이션 클라이언트 같은 경우도 동일한 기반 코드와 플랫폼을 공유했다. 데이터는 쉽게 접근되는 파일이나 메인프레임 테이블에 존재했기 때문에 배치 문제도 없었고 애플리케이션 간 데이터 공유도 쉬웠다.
한 시대를 풍미한 클라이언트/서버(C/S) 컴퓨팅에서도 역시 파워빌더나 비주얼 베이직으로 개발된 덩치 큰 윈도우 애플리케이션 클라이언트는 ‘엔터프라이즈 데이터 모델’로 불리는 단일한 관계형 데이터베이스를 공유했다. 이를 가능케 하는 서비스 데스크톱도 회사 내에 위치해 있었다.
이 아키텍처는 애플리케이션들이 트랜잭션을 통해 다른 애플리케이션의 데이터를 업데이트하는 방식으로 데이터 공유를 허용했다.
그러나 세계는 변화하고 있다. 모든 것이 연결된 세계에서 ▲기업내 혹은 기업간 데이터 공유에 대한 필요성 ▲범용 하드웨어에 애플리케이션을 확장해야하는 필요성 ▲윈도우 데스크톱 PC에서 다른 웹사이트나 PDA, 태블릿 PC에 걸친 다양한 클라이언트를 지원할 필요성 등으로 한때 간단했던 그림이 지금은 매우 복잡해진 상태다.
과연 애플리케이션들을 이 화려한 신세계로 어떻게 가지고 나올 수 있을까? 정답은 바로 서비스 지향 아키텍처(SOA)다.
가장 단순하게 분류해보면 별도의 애플리케이션들이 각각 수행하던 기능은 SOA에서 비즈니스 서비스 집합으로 나눠지게 된다. 이 서비스들은 ‘X를 알고 싶다’와 같은 서비스 요청 메시지를 수신하고 ‘Y는 여기 있다’라는 서비스 응답 메시지를 송신함으로써 고객, 그리고 내/외부의 서비스와 서로 통신을 주고 받는다. 이런 메시지들이 플랫폼, 장비에 독립적이려면 XML과 SOAP으로 표현, 전달되야 한다는 것은 매우 당연한 사실이다.
그러나 아키텍트, 개발자들이 SOA 설계와 구현에 대해 실제적으로 생각하면서 문제가 발생한다. 여기에는 어떤 데이터 서비스를 공유하고 데이터 접근과 관리는 어떻게 할지, 데이터를 어떻게 표현할 지와 같은 것들이 있다.
이 기사에서는 SOA에 사용되는 데이터의 유형들을 살펴보고 서비스 내/외부에 존재하는 데이터의 표현 방법을 알아볼 것이다. 아래 기술되는 내용은 SOA를 고려하기 시작한 바로 그 시점에 당신의 생각을 명확히 하는데 도움이 될 것이다.
어떤 데이터를 표현해야 하나?
SOA를 구축할 때에는 4가지 데이터 유형을 우선 고려해야 한다. 이들은 서비스 외부에서 내부로 들어가는 순서에 따라 메시지 데이터, 조사 데이터, 프로세스 데이터, 비즈니스 데이터로 나눠진다. 이제 각 데이터들의 유형과 특징을 정의하고 데이터를 다룰 때 필요한 정보가 뭔지 살펴보자.
메시지 데이터
서비스 사이를 흘러 다니는 데이터를 메시지 데이터라고 한다. 이 데이터는 서비스 사용자가 원하는 업무나 동작인 ‘요청’과 그 결과로 고객이 받는 ‘응답’을 정의해준다.
서비스와 서비스 사이에는 이 데이터만이 송수신될 수 있다. 따라서 메시지 데이터는 서비스의 개방형 인터페이스를 표상하는 역할도 함께 담당한다. 이로 인해 SOA는 플랫폼 독립적인 성격을 갖게 된다.
정의에 따르면 메시지 데이터는 사용자가 요청을 구성하고 응답을 처리하는 방법을 발견할 수 있도록 하는 개방형 스키마(schema)를 요구한다. 따라서 ‘서비스에 의해 노출되는 동작’이라는 정의에 비춰볼 때 메시지 데이터는 비교적 정적인 성격을 갖는다.
그러나 변화가 생기면 분명히 버전을 명시해 관리해야 한다. 또한 메시지 데이터는 한번 작성되면 바꿀 수 없으며 변경 자체가 불가능하다.
서비스들은 생성시각, 버전 id, 대화 id, 대화 내부의 일련번호 뿐 아니라 각 메시지별로 유일 식별자를 생성해 메시지 데이터를 다룬다. 물론 보안 토큰도 여기에 포함된다.
이렇게 추가 정보를 이용하면 서비스는 생성시각을 참조해 제때 도착하지 않은 메시지를 버리는 등 메시지들을 적절한 순서로 한번만 처리할 수 있다. 또한 서비스는 여러번 도착한 메시지에 대해 이전에 만들어 캐시해놓은 응답을 보내 해결하기 위해 요청과 응답을 저장해놓는다. 이런 과정은 성능도 향상시킨다. 메시지 데이터는 조사 데이터를 이동시키는데 자주 사용된다.
조사 데이터
서비스에서 다뤄지는 두번째 데이터는 조사 데이터다. 이 유형의 데이터는 서비스 요청 동작의 일환으로 매개변수를 전달하거나 서비스 응답에서 온 데이터를 해석하는데 사용된다. 이 과정 이후 사용자는 조사 데이터를 요청하게 되며 이후 요청 메시지를 구성하기 위해 조사 데이터를 사용하게 된다.
예를 들어 기술 교육 제공 업체는 교육 장소와 업체들로 구성된 조사 데이터를 발행할 수 있다. 따라서 사용자들은 수업 스케줄을 요청할 때 유효한 값들을 전달할 수 있다.
예상하겠지만 조사 데이터도 비교적 정적이다. 그러나 변화가 있을 때는 버전 관리를 해야 한다. 즉 각 버전의 조사 데이터끼리는 변화가 없는 것이다. 메시지 데이터처럼 조사 데이터도 서비스 외부에서 사용되며 개방형 스키마를 요구한다.
서비스는 조사 데이터를 다룰 때 각 항목에 유일한 버전 id를 부여한다. 예를 들면 ‘퀼로지-위치코드-v012004’와 같은 식이다. 이 방식대로라면 사용자는 요청 작업을 수행할 때 참조 데이터 버전을 전달하기 때문에 서비스가 적절한 응답을 만들어낼 수 있다.
결국 조사 데이터는 일반적으로 정기적인 갱신 작업을 요구하게 된다. 따라서 서비스는 이메일, HTTP, 심지어 DVD까지도 사용하는 푸시(push) 방식이나 HTTP, FTP, 이메일을 이용한 풀(pull) 방식을 사용해 새로운 버전을 관심있는 가입자들에게 전달한다.
프로세스 데이터
서비스 내부에서 최초로 다뤄지는 데이터가 바로 프로세스 데이터다. 메시지나 조사 데이터와는 달리 프로세스 데이터는 각 서비스마다 고유하며 내부에 감춰지기 때문에 개방형 스키마가 필요없다.
프로세스 데이터는 서비스가 수행하는 비즈니스 절차나 기능 등을 표현한다. 대개 이 데이터들은 장기적인 동작 과정을 거쳐 완성된다. 이의 예로는 쇼핑 바구니, 구매 명령, 송장 등이 있다.
프로세스 데이터는 클라이언트나 대화에 의존적이며 단일 클라이언트에 의해 순차적으로 접근되기 때문에 병행성에 대한 요구가 낮다. 조사 데이터와 달리 동작 중에도 업데이트할 수 있으며 동작이 완료되면 일반적으로 읽기만 가능한 상태가 된다. 따라서 시간이 갈수록 참조 회수도 작아진다.
서비스 프로세스는 메시지를 요구하고 서로 대화하기 위해 서비스 사이에 프로세스 데이터를 구축하게 된다. 따라서 이들은 대화 인식자를 이용해 프로세스 데이터와 상관관계를 유지해야 한다.
서비스는 프로세스 데이터를 조작하는 다양한 기법을 사용할 수 있다. 예를 들면 프로세스가 활성화된 시간 동안 서비스는 프로세스 데이터를 객체에 캡슐화해 메모리에 캐시할 수 있다. 또한 서비스는 종료되거나 포기된 프로세스를 깨끗하게 제거할 수 있어야 한다.
비즈니스 데이터
SOA에서 사용되는 데이터의 마지막 유형은 비즈니스 데이터다. 이 유형은 고객 정보, 제품 재고, 은행 계좌들처럼 사람들이 애플리케이션을 생각할 때 떠올리는 바로 그것들이 대부분이다.
프로세스 데이터처럼 비즈니스 데이터도 각 서비스마다 고유하며 개방형 스키마를 필요로 하지 않는다. 그러나 프로세스 데이터와 달리 단일한 장기적 동작보다는 그 수명이 길며 여러 동작에 의해 동시에 변경될 수 있기 때문에 병행성에 대한 요구가 높다. 결과적으로 비즈니스 데이터는 휘발성이 강하며 본질적으로 유동적인 자료의 형태에 가깝다.
서비스가 비즈니스 데이터와 상호작용할 때 가장 중요한 부분은 단일 소유주의 원칙에 충실해야 하는 것일 것이다. 즉 서비스는 기업의 일부 데이터에 대해 소유 권한을 가져야 한다.
예를 들어 한 서비스는 고객 데이터를, 다른 서비스는 직원 데이터를 가질 수 있다. 데이터 공유가 필요한 경우 각 서비스는 변경사항을 다른 서비스에 공개하고 다른 서비스들은 내부에서 사용하기 위해 이것을 캐시한다.
따라서 서비스 데이터의 공개는 늘어나는 각 식별자들과 함께 버전이 관리돼야 한다. 서비스의 소유자만이 데이터를 업데이트 해야 하며 소유자가 아닌 사용자에 의한 변화 요청이 제기될 경우 소유권을 가진 서비스는 변경 작업을 진행한 이후 관심있는 가입자에게 해당 데이터를 재공개하는 절차를 밟아야 한다.
데이터 유형을 다루고 저장하는 방법은?
데이터 유형이 정의되면 이것을 처리하고 저장하기 위해 어떤 기술을 사용해야 할지 궁금할 것이다. 바로 XML, 객체, SQL이 기술의 핵심을 이룬다.
메시지 데이터
메시지 데이터는 개방형 스키마과 이질성을 요구하므로 SOAP을 이용한 모델이 가장 적합하다. 따라서 WSDL을 이용한 메시지 스키마를 발행할 수 있다. 또한 생성시각과 보안과 같이 구현하고자 하는 메시지 데이터 기능의 일부는 WS-*와 같은 SOAP 표준이나 MS의 웹서비스 인핸스먼트(WSE) 2.0과 같은 툴킷으로 구현할 수 있다.
서비스 내부에서는 동일성을 구현하기 위해 관계형 데이터 내부에서 인식 속성이 메시지 데이터에 XML 형태로 저장될 수 있다. 속성에 질의문이 주어질 가능성이 크기 때문에 이 방식이 권장될 수 있긴 하지만 불변성 측면에서 볼 때 메시지 내용을 자주 읽고 파싱(parsing)하는 것은 좋지 않다.
또한 메시지를 저장하면 감사, 그리고 향후 진행될 분석이 가능해진다. 그러나 유형 정의에 비춰볼 때 메시지 데이터는 가장 생명이 짧다. 또한 분석에 사용되지 않는다면 더 쉽게 저장될 수 있다.
메시지 데이터에 대한 또다른 측면은 서비스 간 메시지 송신이 이뤄질 때 어떤 일이 발생하는가에 관한 것이다. 독립적으로 전개되는 다중 서비스에 메시지 구조가 사용되는 조직 환경에서는 메시지가 서비스에 의해 소비되기 이전에 표준 스키마로 변환되도록 조치하는 것이 좋다. 이는 조사, 비즈니스 데이터를 각 서비스가 다른 형태로 표현할 때 일어날 수 있는 문제점들을 미연에 방지해주며 데이터 변환의 횟수를 획기적으로 줄일 수 있다.
조사 데이터
조사 데이터는 공개적이며 개방형 스키마를 요구하기 때문에 XML로 모델링돼야 한다. 즉 버전 정보를 표시하면서 조사 데이터의 스키마를 WSDL로 나타내는 방식이 좋다. 데이터베이스 측면에서 볼 때 조사 데이터는 한번만 기록되고 XML에 의해 직접 추출될 수 있기 때문에 성능 증가의 목적으로 관계형 테이블의 XML로 저장될 수 있다.
또한 관계형 테이블에 조사 데이터를 저장함으로써 버전 관리도 쉬워진다. 서비스는 내부적으로 메모리에 현 조사 데이터를 캐시할 수 있다. 이렇게 되면 사용자가 조사 데이터를 요청할 때 응답시간을 단축할 수 있다.
프로세스 데이터
프로세스 데이터는 서비스에 고유하기 때문에 XSD로 발행되거나 XML로 표시될 필요가 없다. 따라서 대개 표준화된 관계형 데이터베이스 테이블로 저장되며 예를 들면 비쥬얼 스튜디어 닷넷 ‘위드비(Whidbey)’와 함께 출하될 오브젝트스페이스(ObjectSpaces)와 같은 객체 보존 계층을 사용해 서비스 내부에 캡슐화된다.
이와 같은 방식으로 서비스는 메모리에서 프로세스 데이터를 완전한 객체로 처리하고 ASP.NET 캐싱 엔진과 같은 캐시 기술을 활용할 수 있다. 프로세스가 완료되거나 대기 상태에 들어가면 객체는 객체보존 계층을 이용해 데이터베이스에 차례로 나열된다.
프로세스 데이터는 단일 대화 내부에서 순차적으로 업데이트되기 때문에 병행성에 대해 낙관적일 수 있다. 분석을 위해 중요한 프로세스 데이터를 저장하는 것도 필요하다. 그러나 만들어진지 오래될수록 데이터들은 아카이브 형태로 보존될 것이다.
비즈니스 데이터
프로세스 데이터처럼 비즈니스 데이터는 서비스에 고유하며 XML로 표현되지 않는다. 물론 일부가 응답 메시지로 보내지는 경우는 예외다. 이런 경우 정형화된 XSD가 생성돼 다른 서비스들이 이 데이터를 해석할 수 있다.
따라서 비즈니스 데이터는 표준화된 관계형 테이블에 저장되며 COM+와 같은 트랜잭션 관리자에 의해 관리되는 구성요소를 통해 캡슐화된다. 이것은 트랜잭션 과정에서 병행성을 비관적으로 만들어 잠금을 보장하기 위한 것이다.
구성요소 자체는 데이터에 상태와 상관없는 접근을 제공하는데 이것은 높은 휘발성과 병행성 때문이다. 비즈니스 데이터는 프로세스 데이터와 결합돼 분석에 사용된다.
모델 산출
아래 그림에는 여기서 논의된 4가지 데이터 유형이 요약돼 있다. SOA를 개발할 때 독자들이 소속된 기업의 데이터를 위치시킬 수 있는 그림을 그리는데 도움이 됐으면 한다. 여기에는 SOA에서 사용되는 4가지 데이터를 강조하고 있으며 이들이 어떻게 표현되고 처리되는지 보여주고 있다. @
http://images.zdnet.co.kr/images/2004/06/69587-1.jpg
SOA 개념상 모델
