객체 지향 및 컴포넌트 기반 개발 모두 공유 데이터베이스에 상주하는 지속적 엔티티를 나타내는 컴포넌트 세트를 갖는 것은 일반적인 사례입니다. 실제로, 엔터프라이즈에서 사용되는 모든 지속적 요소를 포함하는 단일
데이터베이스 스키마를 포함하는 것이 종종 많은 IT 조직의 비전이었습니다. 일부 조직의 경우 완전한 성공을 거두지는 못했지만 그 중 대부분은 공통 엔터프라이즈 스키마가 개발되지 않은 상태였습니다. 이러한 접근
방식이 실패하는 이유는 여러 가지이지만 상당수는 기술과 관련이 없으며 여러 응용프로그램과 관련이 있습니다. 동일한 공유 데이터에 대한 액세스, 잠금 및 변경은 여러 조직에 걸쳐서 해결하기에는 매우 어려운
문제입니다.
이 가이드라인에서는 서로 밀접한 관련이 있는 두 가지 관심사항에 대해 다룹니다. 즉, 서비스는 필요한 데이터의 완전한 캡슐화여야 하며 서비스 간 정보 공유는 메시지 교환을 통해서만 수행되어야 한다는 것입니다.
이 가이드라인은 데이터 구동 서비스 식별 주제에 대한 추가 세부사항을 제공합니다.
객체 지향 개발 개념을 설명할 때 가장 자주 사용되는 용어 중 하나가 캡슐화의 개념입니다. 캡슐화란 오브젝트가 해당 상태(개인용 데이터) 및 해당 구현 로직을 캡슐화해야 함을 의미합니다. 서비스 환경에서는
아티팩트: 서비스(구현) 개념을 해당 아티팩트: 서비스 스펙과 명확히 구분합니다. 이 섹션은 상태 캡슐화에 대한 요구를 다룹니다. 이 개념은 처음
[HELLAND]에 문서화되었으며 최근 [SESSIONS]에도 문서화되었습니다. 해당 내용은 자율성으로 인해 보다 쉽게 전개할 수 있는 시스템 개발에 초점을 맞춥니다.
일반적으로 사용되는 유추 방식 [HELLAND]는 새 보험에 가입하기 위해 에이전트를 사용하는 경우입니다. 에이전트는 신청서 양식 작성을 도와주며 이를 위해 일반적으로 보험 상품 및 보험료 유형에 대한 데이터에
액세스합니다. 보험 에이전트는 보험 회사의 활동 영역(fiefdom)을 대신하여 밀사(emissary) 역할을 수행합니다. 실제로 보험 회사는 공인 에이전트의 보험 가입 신청서만 승인할 수도 있습니다. 활동 영역은
최신 보험 상품, 보험료 및 양식 정보와 처리 신청서를 에이전트에게 배포합니다. 그러나 활동 영역이 에이전트에게 보험 상품 정보를 제공하고 활동 영역이 해당 에이전트를 인증한 경우라도 보험 회사는 신청서를 받은 후
우선 해당 내용이 유효한지 검증해야 합니다. 즉, 활동 영역은 아직 밀사를 신뢰하지 않는 것입니다.
다음 섹션은 두 기본 요소의 역할을 자세히 설명합니다. 이는 구체적인 패턴 또는 규정된 접근 방식은 아니지만 구현된 원칙은 서비스 지향 솔루션을 고려하는 데 있어 중요합니다.
활동 영역(fiefdom)의 역할
활동 영역(fiefdom)은 자율 서비스이며 메시지를 통한 통신만 허용합니다. 메시지는 일반적으로 이용자 역할을 대신하는 밀사(emissary)가 작성하는 것으로 가정됩니다. 활동 영역은 안전하고 자율적이며 데이터
경계를 완전하게 정의합니다. 활동 영역 간이나 활동 영역과 기타 소프트웨어 요소 간에는 데이터 소스 또는 기타 지속적 데이터를 공유하지 않습니다. 이제 단일 데이터베이스 서버가 여러 서비스의 지속성을 지원할 수
있지만 각 활동 영역마다 다른 테이블 공간 및 데이터베이스 컨테이너를 사용함으로써 데이터 무결성, 보안 등을 보장할 수 있습니다.
이 패턴의 또 다른 주요 측면은 밀사가 올바른 에이전트 역할을 수행할 수 있고 활동 영역과 필요한 최소 커뮤니케이션으로 이용자와 상호작용할 수 있으며 활동 영역이 특정 참조 데이터 사본을 밀사에게 배포한다는
것입니다. 밀사는 해당 사본을 로컬로 저장하고 사용합니다. 따라서 위의 보험 회사 예제에서는 사용 가능한 보험 상품, 해당 요구사항, 제한사항 및 보험료 카탈로그가 정기적으로 에이전트에게 배포됩니다. 물론
에이전트는 이 정보를 사용할 수 있으며 이 정보가 활동 영역이 사용하는 실제 데이터가 아닌 데이터 사본이므로 최신 정보가 아닐 수 있음을 이해합니다. 이 데이터는 일반적으로 월 단위로 갱신되며 내용이 갱신된 경우
밀사는 신규 신청서를 처리할 수 없거나 이전 데이터를 기반으로 처리할 수 있습니다.
위에서 언급한 대로, 밀사(emissary)가 활동 영역 역할을 대신 수행한다고 해서 두 관계자 간의 신뢰 관계가 구축됨을 의미하지는 않습니다. 밀사의 불법 행위를 예방하기 위해 모든 메시지는 구문, 시맨틱 및
보험 내용에 대한 유효성을 검증한 후 승인됩니다.
활동 영역(fiefdom)의 세부 책임은 다음과 같습니다.
-
참조 데이터를 관리하고 모든 밀사에게 배포하며 데이터의 유효 날짜를 명확하게 식별합니다.
-
트랜잭션 데이터의 상태를 관리합니다. 모든 트랜잭션은 내부에서만 관리됩니다.
-
밀사와의 모든 커뮤니케이션에 대한 유효성을 검증합니다.
밀사(emissary)의 역할
밀사는 에이전트 역할을 수행하며 이용자 관련 컴포넌트, 인터넷 기반 컴포넌트 또는 특별 배치된 컴포넌트로서 위치합니다. 그러나 밀사는 활동 영역 프로세스로 보낸 메시지를 작성하는 데 필요한 참조 데이터를 관리하는
특성을 갖고 있습니다. 밀사는 또한 트랜잭션 관련 메시지의 로컬 사본을 관리합니다. 따라서 예를 들어, 고객은 스스로 기존 보험 상품을 갖고 있는 것으로 식별할 수 있습니다. 이러한 정보는 밀사가 먼저 일부 정보로
양식을 미리 작성하기 위해 찾아볼 수 있으며 기존 보험 상품의 이 사본은 밀사가 신청 완료 트랜잭션의 지속 기간 동안 캐시할 수 있습니다.
일반적으로 밀사(emissary)는 활동 영역과 이용자 간 커뮤니케이션이 복잡한 요청 작성과 같이 보다 복잡한 트랜잭션을 나타낼 때 사용됩니다. 이제 밀사는 이러한 트랜잭션을 현재 예제와 같이 보다 효율적으로
관리할 수 있습니다. 이러한 패턴은 오늘날 주문을 처리하고 전달 스케줄을 관리하는 주문 이행 시스템이 오래된 기존 시스템과 동일한 많은 조직에서 나타납니다. 이러한 조직이 웹을 통한 상호작용 방식으로 제품을
판매하고 웹 응용프로그램이 밀사 역할을 수행하게 되면서 제품 카탈로그의 로컬 사본을 구비하고 고객의 주문을 돕고 있습니다. 물론 웹 응용프로그램이 주문을 처리하는 것은 아니며 기존 시스템으로 주문을 제출합니다.
밀사는 참조 데이터를 기반으로 이 주문을 완료하므로 올바른 주문은 거부되지 않습니다. 반대로 앞에서 설명한 것처럼 기존 주문 시스템은 주문을 승인하기 전에 먼저 유효성을 검증합니다.
밀사(emissary)의 세부 책임은 다음과 같습니다.
-
이용자를 대신하는 에이전트로서 메시지를 완성하고 활동 영역과 상호작용합니다.
-
필요한 경우 이용자를 대신하여 참조 데이터를 조회하고 메시지를 작성하며 정보를 제출하는 논리 트랜잭션을 관리합니다.
-
활동 영역의 조언에 따라 참조 데이터의 로컬 사본을 갱신하여 관리합니다.
-
시간에 민감하고 활동 영역이 식별한 데이터에 대한 캐싱 정책을 관리합니다.
일반적으로, 많은 응용프로그램은 수직 통합된 컴포넌트 세트로 개발됩니다(자세한 정보는 서비스 지향 아키텍처(SOA) 개념 참조). 이러한 경우 응용프로그램에 자연적인 통합 지점이 거의 없게 됩니다. 가장 일반적인 통합 접근 방식은
둘 이상의 응용프로그램이 공통 데이터 스토어를 공유하는 것으로서 쉬운 방식으로 인식되고 있습니다. 따라서 인벤토리 및 주문 서비스에서 "제품"의 개념을 공유하는 경우 데이터베이스의 동일한 테이블에 액세스합니다.
이러한 경우 여러 가지 잠재적인 동시성 및 성능 문제와 상호 관계가 발생합니다. 이러한 상호 관계에서는 개별 전개에 영향을 주는 이 응용프로그램과 비즈니스 기능을 결합시켜 특정 응용프로그램을 다시 호스트하거나 다시
개발하거나 변경합니다.
서비스 지향 솔루션의 개발을 위해서는 바인딩되고 일관된 특정 모델을 서비스로 관리하도록 권장합니다. 따라서 위에 표시된 두 응용프로그램의 사용법을 분석함으로써 응용프로그램의 데이터 사용법과, 두 가지 자율 서비스로
관리하기 위한 분리 방법을 식별해야 합니다. 그러나 데이터 모델이 분리되었다고 데이터 모델 간 상호 연결이 해제된 것은 아닙니다. 예를 들어, 인벤토리 및 주문 서비스 모두 제품 및 위치에 대한 공통 정의가
필요합니다. 이 위치는 인벤토리를 저장하고 주문 소스를 찾을 수 있는 위치입니다.
이와 관련된 접근 방식은 공유 개념에 대한 또 다른 서비스(이 경우 제품 카탈로그 서비스)를 작성하거나 새 서비스 중 한 서비스에서만 개념을 관리하는 것입니다. 예를 들어, 인벤토리로 위치를 논리적으로 관리할 수
있습니다. 이제 이러한 서비스 중 특정 서비스와 주고받는 메시지에는 공유 요소의 ID가 포함되어야 필요 시 조회 또는 검색할 수 있습니다. 예를 들어, 인벤토리의 경우 현재 위치에서 관리되는 제품을 조회하면 제품
ID 목록이 리턴됩니다(경우에 따라 현재 수량 포함). 제품 세부사항이 필요한 경우, 제품 카탈로그 서비스에서 검색됩니다.
데이터 경계 분석의 핵심 중간 산출물은 데이터
모델입니다. 기존 데이터베이스에 대한 데이터 모델을 작성해야 하며 해당 데이터 모델은 실제 데이터 모델 또는 논리 데이터 모델(권장)에서 주의해서 분리해야 합니다.
모든 데이터를 서비스에만 저장하고 서비스 외부로부터의 액세스는 모두 거부하는 경우, 모든 통신은 서비스 스펙에서 식별된 메시지를 통해 수행되어야 합니다. 그러나 이러한 메시지는 데이터베이스에서 이용자로의 데이터
조회 및 리턴을 나타내므로 특히 서비스에서 보관하는 데이터의 사본입니다. 따라서 실제로는 사용하지 않는 서비스 상태를 나타낼 수 있습니다. 예를 들어, 제품 "234"의 현재 수량을 조회하는 경우, 위치
"562"의 수량이 "12"임을 식별하는 메시지가 리턴됩니다. 그러나 다른 이용자가 재고에서 여덟 개의 항목을 가져가고 원래 이용자가 12개 항목을 획득하려고 시도하면 오퍼레이션이 실패합니다.
이는 결과적으로 디자인 및 전통적인 트랜잭션 관리의 문제입니다. 즉, 트랜잭션의 범위 및 경계를 관리함으로써 서비스 및 서비스 이용자의 느슨한 결합 특성으로 인해 좀더 복잡하거나 최소한 보다 가시적인 상태가
됩니다. 따라서 메시지는 데이터의 보기 및 데이터 사본으로 간주해야 합니다. 일부 안내는 SOA를 포함한 여러 위치에 작성되었습니다. 이는 메시지가 해당 수명 및 적용가능성을 식별할 수 있는 방법과 관련이 있습니다.
서비스 지향 솔루션의 고유한 메시지 전달 기반 접근 방식에 대한 이러한 변환에 따른 또 다른 효과는 이제 응용프로그램용 공통 데이터 모델 아이디어에 대한 초점을 통합용 공통 메시지 모델로 이동시킬 수 있다는
것입니다. 즉, 가능한 경우 서비스 스펙에 정의된 메시지는 공통 구조를 기반으로 하며, 서비스에서 재사용할 수 있는 결합 스키마로 분리할 수 있습니다. 이는 서비스 자체의 느슨한 결합 접근 방식과도 일치하므로 보다
유연한 통합 접근 방식입니다. 또한 서비스 구현에서 사용되는 대부분의 기술에는 메시지 스키마가 정확히 일치하지 않는 메시지-변환 기능을 제공하는 기술, 도구 또는 런타임이 포함됩니다.
특히 메시지 임대차 및 캐싱에 대한 자세한 정보는 타스크: 메시지
디자인을 참조하십시오.
[HELLAND] Fiefdoms and Emissaries, Pat Helland, Microsoft.
[SESSIONS] Software Fortresses: Modeling Enterprise Architectures, Roger Sessions, Addison Wesley, 2003.
|