KR101224670B1 - 데이터 관리를 용이하게 해주는 시스템 및 방법 - Google Patents

Abstract

공통 데이터 스토어와, 다수의 개별적인 어플리케이션 프레임워크의 다수의 어플리케이션 간의 데이터 관리가 제공된다. 데이터의 저장을 용이하게 해주는 데이터 저장 컴포넌트가 제공되며, 이 데이터는 구조화된 데이터, 반구조화된 데이터 및 비구조화된 데이터를 포함한다. 공통 데이터 플랫폼은 복수의 개별적인 어플리케이션 프레임워크에 의해 액세스가능한 데이터 서비스를 제공하기 위해 데이터 저장 컴포넌트에 인터페이스하며, 이 데이터 서비스는 서로 다른 프레임워크들의 대응하는 어플리케이션이 그 데이터를 액세스할 수 있도록 해준다.

공통 데이터 플랫폼, 데이터 스토어, 어플리케이션 프레임워크

Description

데이터 관리를 용이하게 해주는 시스템 및 방법{PLATFORM FOR DATA SERVICES ACROSS DISPARATE APPLICATION FRAMEWORKS}

도 1은 본 발명의 아키텍처에 따른 공통 데이터 플랫폼(CDP)을 이용하는 시스템을 나타낸 도면.

도 2는 개시된 아키텍처에 따른 보다 상세한 CDP 시스템을 나타낸 도면.

도 3은 데이터의 관리를 용이하게 해주는 공통 데이터 플랫폼을 구현하는 방법을 나타낸 도면.

도 4는 본 발명의 아키텍처와 관련한 CDP 컴포넌트의 개략도.

도 5는 CDP의 여러가지 컴포넌트 내에서의 데이터 흐름을 나타낸 도면.

도 6은 CDP로 구현될 수 있는 여러가지 프레임워크를 나타낸 도면.

도 7은 다수의 어플리케이션이 데이터를 공유할 수 있게 해주는 공통 데이터베이스 기반 파일 저장 시스템 시나리오를 나타낸 도면.

도 8은 단일 어플리케이션이 CDP 및 연관된 아키텍처에 따른 다수의 프레임워크를 이용하는 것을 나타낸 도면.

도 9는 CDP가 복수의 개별적인 프레임워크와 연관된 다수의 어플리케이션과 데이터를 공유하는 것을 나타낸 도면.

도 10은 데이터 관리를 용이하게 해주는 CDP의 2-계층 배치를 나타낸 도면.

도 11은 데이터 관리를 용이하게 해주는, 공유 데이터를 갖는 2-계층 배치를 나타낸 도면.

도 12는 한 어플리케이션이 다른 어플리케이션들이 보는 것 및/또는 이용하는 것을 원하지 않는 전용 데이터를 갖도록 되어 있는 제2 구성을 나타낸 도면.

도 13은 다른 어플리케이션이 스토어에 직접 액세스하도록 되어 있는 관심의 제3 구성을 나타낸 도면.

도 14는 CDP 컴포넌트의 3-계층 배치 구성을 나타낸 도면.

도 15는 CDP 컴포넌트의 3-계층 배치 구성을 나타낸 도면.

도 16은 어플리케이션 로직이 클라이언트 계층 및 중간 계층(middle tier) 양쪽 상에서 실행되고 있는 것을 나타낸 도면.

도 17은 어플리케이션 로직이 클라이언트 계층 및 중간 계층 양쪽 상에서 실행되고 있는 것을 나타낸 도면.

도 18은 적어도 하나의 개체를 이용하는 아이템을 모델링하는 것을 나타낸 도면.

도 19는 CDP 상부에 UAF를 포함시킴으로써 여러가지 기능을 구현하는 확장가능 메커니즘을 나타낸 도면.

도 20은 LOB 어플리케이션이 CDP 상부에 구현되어 있는 것의 예를 나타낸 도면.

도 21은 CDP의 여러가지 컴포넌트 내에서의 데이터 흐름을 관리하는 것을 용이하게 해주는 방법을 나타낸 도면.

도 22는 다수의 개별적인 프레임워크 - 개별적인 어플리케이션이 각각의 프레임워크와 관련될 수 있음 - 에 걸쳐 CDP를 배치하는 것을 용이하게 해주는 방법을 나타낸 도면.

도 23은 개시된 아키텍처를 실행하는 동작을 하는 컴퓨터의 블록도.

도 24는 본 발명에 따른 예시적인 컴퓨팅 환경의 개략 블록도.

<도면의 주요 부분에 대한 부호의 설명>

102: 공통 데이터 플랫폼(CDP)

104: 어플리케이션 및 어플리케이션 프레임워크

106: 데이터 스토어

108: API

110: 런타임

112: 제약/보안

<관련 출원에 대한 상호 참조>

본 출원은 2005년 2월 28일자로 출원된 발명의 명칭이 "개별적인 어플리케이션 프레임워크에 걸친 데이터 서비스를 위한 플랫폼(PLATFORM FOR DATA SERVICES ACROSS DISPARATE APPLICATION FRAMEWORKS)"인 미국 가특허출원 제60/657,556호를 우선권 주장한다. 본 출원은 2005년 2월 28일자로 출원된 발명의 명칭이 "개별적 인 어플리케이션 프레임워크에 걸친 데이터 서비스를 위한 플랫폼(PLATFORM FOR DATA SERVICES ACROSS DISPARATE APPLICATION FRAMEWORKS)"인 미국 가특허출원 제60/657,556호, 2005년 2월 28일자로 출원된 발명의 명칭이 "객체-관계형 데이터에 대한 데이터 모델(DATA MODEL FOR OBJECT-RELATIONAL DATA)"인 미국 가특허출원 제60/657,295호, 및 일자로 출원된 발명의 명칭이 "객체-관계형 데이터에 대한 데이터 모델(DATA MODEL FOR OBJECT-RELATIONAL DATA)"인 미국 특허출원 제 호, 2005년 2월 28일자로 출원된 발명의 명칭이 "공통 데이터 플랫폼에 대한 스토리지 API(STORAGE API FOR A COMMON DATA PLATFORM)"인 미국 가특허출원 제60/657,522호, 및 자로 출원된 발명의 명칭이 "공통 데이터 플랫폼에 대한 스토리지 API(STORAGE API FOR A COMMON DATA PLATFORM)"인 미국 특허출원 제 호에 관한 것이다. 이들 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.

제품을 브라우징하고 주문을 발생하는 데 이용되는 LOB(Line-of-Business) 어플리케이션 프레임워크든 사람들 간의 만남을 스케쥴링하는 데 사용되는 PIM(Personal Information Management) 어플리케이션이든지 간에, 데이터는 거의 모든 어플리케이션에 있어서 중요한 자산이 되었다. 어플리케이션은 어플리케이션 데이터에 대해 데이터 액세스/처리 및 데이터 관리 동작 둘다를 수행한다. 일반적인 어플리케이션 동작은 데이터 컬렉션에 쿼리를 행하고, 결과 세트(result set)를 페치(fetch)하며, 데이터의 상태를 변경시키는 어떤 어플리케이션 로직을 실행하고 또 마지막으로 데이터를 저장 매체에 영구 보존한다.

전통적으로, 클라이언트/서버 어플리케이션은 쿼리(query) 및 영구 보존(persistence) 동작을, 데이터 계층에 배치되어 있는 데이터베이스 관리 시스템(DBMS)에 맡겨 왔다. 데이터 중심 로직(data-centric logic)이 있는 경우, 이는 데이터베이스 시스템에서 저장 프로시저(stored procedure)로서 코딩된다. 데이터베이스 시스템은 테이블 및 행의 관점에서 데이터를 처리하였고, 어플리케이션은 어플리케이션 계층에서, 프로그래밍 언어 객체(예를 들어, Class 및 Struct)의 관점에서 데이터를 처리하였다. 어플리케이션 및 데이터 계층에서의 데이터 처리 서비스(및 메커니즘)의 불일치는 클라이언트/서버 시스템에서 허용되었다. 그렇지만, 웹 기술(및 서비스 지향 아키텍처(Service Oriented Architecture))의 등장으로 또 어플리케이션 서버의 더욱 광범위한 채택으로, 어플리케이션은 다중-계층(multi-tier)으로 되고 있으며, 보다 중요한 것은 데이터가 현재 모든 계층에 존재한다는 것이다.

이러한 계층화된 어플리케이션 아키텍처에서, 데이터는 다수의 계층에서 처리된다. 게다가, 주소 지정 능력(addressability) 및 대용량 메모리에 있어서의 하드웨어 진보에 따라, 더 많은 데이터가 메모리에 상주(memory resident)하게 되고 있다. 어플리케이션은 또한 예를 들어 객체, 파일, 및 XML(eXtensible Markup Language) 데이터 등의 서로 다른 유형의 데이터를 처리하고 있다.

하드웨어 및 소프트웨어 환경에서, 프로그래밍 환경과 잘 통합된, 풍부한 데이터 액세스 및 처리 서비스의 필요성이 증가하고 있다. 상기한 문제점을 해소하기 위해 도입된 한가지 종래의 구현이 데이터 플랫폼이다. 데이터 플랫폼은 어플리케이션 프로그래밍 환경과 잘 통합되어 있는, 어플리케이션이 데이터에 대한 액세스, 처리 및 관리를 행하기 위한 서비스(메커니즘)들의 컬렉션을 제공한다. 그렇지만, 이러한 종래의 아키텍처는 많은 점에서 부족하다. 이러한 데이터 플랫폼에 대한 어떤 주된 요건은 복잡한 객체 모델링, 풍부한 관계, 논리적 및 물리적 데이터 추상화의 분리, 리치 데이터 쿼리 모델(query rich data model) 개념, 적극적 통지(active notification), 중간-계층 기반구조(middle-tier infrastructure)와의 더 나은 통합을 포함한다.

이하에서는 본 발명의 어떤 측면들의 기본적인 이해를 제공하기 위해 본 발명의 간략화된 요약을 제공한다. 이 요약은 이 아키텍처의 전반적인 개요가 아니다. 이 요약은 본 발명의 주요/중요한 구성요소를 확인하거나 본 발명의 범위를 한정하기 위한 것이 아니다. 그의 유일한 목적은 이후에 제공되는 보다 상세한 설명에 대한 전제로서 본 발명의 어떤 개념들을 간략화된 형태로 제공하는 데 있다.

본 명세서에 개시되고 청구된 본 발명은, 그의 한 측면에서, 공통 데이터 스토어와 다수의 개별적인 어플리케이션 프레임워크의 다수의 어플리케이션 간의 데이터 관리를 용이하게 해주는 아키텍처를 포함한다. 이는 테이블을 객체에 매핑하기 위해 어플리케이션으로부터 멀리 떨어져 매핑 계층을 형식화한다. 이 아키텍처는 어플리케이션이 테이블이 아닌 어플리케이션 객체의 레벨에서 데이터를 처리할 수 있게 해주기 위해, 데스크톱 어플리케이션과 LOB(Line-of-Business) 어플리케이 션 프레임워크 간의 격차를 메운다. 게다가, 이 아키텍처는 최종 사용자 어플리케이션에 의해 정의된 데이터 개체가 LOB 어플리케이션에 의해 사용될 수 있도록 또 그 역도 마찬가지이도록 모든 프레임워크에 걸쳐 이 데이터를 공유할 수 있게 해준다.

이 아키텍처는 데이터의 저장을 용이하게 해주는 데이터 저장 컴포넌트를 포함하며, 이 데이터는 구조화된(structured), 반구조화된(semi-structured) 및 비구조화된(unstructured) 데이터를 포함한다. 공통 데이터 플랫폼은 복수의 개별적인 어플리케이션 프레임워크에 의해 액세스가능한 데이터 서비스를 제공하기 위해 데이터 저장 컴포넌트와 인터페이스하며, 이 데이터 서비스는 서로 다른 프레임워크의 대응하는 어플리케이션이 데이터에 액세스할 수 있게 해준다. 이 데이터 플랫폼은 또한 API(Application Program Interface, 어플리케이션 프로그램 인터페이스)와 인터페이스하고 객체 관계형 매핑, 쿼리 매핑을 제공하며 또 제약을 시행하는 런타임 컴포넌트, 및 제약의 선언적 작성(declarative authoring)을 용이하게 해주고 데이터 플랫폼의 개체에의 액세스를 제어하는 제약/보안 엔진을, 공개 클래스, 인터페이스 및 정적 헬퍼 함수(static helper function) 형태로 어플리케이션에 전달하는 것을 용이하게 해주는 API를 포함한다.

본 발명의 다른 측면에서, 공통 데이터 플랫폼(common data platform, CDP)은 다양한 최종 사용자 어플리케이션 프레임워크(예를 들어, PIM(Personal Information Manager) 프레임워크에서 LOB(Line-of-Business) 어플리케이션 프레임워크까지)에 걸쳐 공통인 데이터 서비스를 제공한다. 어플리케이션의 범위는 탐색 기(Explorer), 메일(Mail) 및 미디어(Media) 어플리케이션 등의 최종 사용자 어플리케이션, 문서 관리(Document Management) 및 협업(Collaboration) 어플리케이션 등의 지식 근로자(Knowledge Worker) 어플리케이션, ERP(Enterprise Resource Planning, 전사적 자원 관리) 및 CRM(Customer Relationship Management, 고객 관계 관리) 등의 LOB 어플리케이션, 웹 어플리케이션 및 시스템 관리 어플리케이션을 포함한다.

본 발명의 또다른 측면에서, CDP는 다중 계층 환경에서, 구조화된, 반구조화된 및 비구조화된 데이터를 모델링 및 저장하는 기능을 제공하는 리치 스토어(rich store), 유연성있는 조직화(organization), 리치 쿼리/검색, 리치 거동, 유연성 있는 관리, 데이터 동기화, 공유, 스키마, 및 유연성 있는 배치를 포함하는 이점들을 어플리케이션에 제공한다.

상기한 목적 및 관련 목적을 달성하기 위해, 이 아키텍처의 어떤 예시적인 측면이 이하의 설명 및 첨부 도면과 관련하여 본 명세서에 기술되어 있다. 그렇지만, 이들 측면은 이 아키텍처의 원리들이 이용될 수 있는 여러가지 방법 중 단지 몇 개를 나타낸 것에 불과하며, 본 발명은 이러한 측면들 및 그의 등가물 모두를 포함하는 것으로 보아야 한다. 이 아키텍처의 다른 이점 및 새로운 특징은 도면과 관련하여 살펴볼 때 본 발명의 이하의 상세한 설명으로부터 명백하게 될 것이다.

이제부터, 그 전체에 걸쳐 유사한 참조 번호가 유사한 구성요소를 언급하는 데 사용되는 도면을 참조하여, 이 아키텍처에 대해 기술한다. 이하의 설명에서, 설명의 목적상, 본 발명에 대한 철저한 이해를 제공하기 위해 여러가지 구체적인 상세가 기술된다. 그렇지만, 이 아키텍처가 이들 구체적인 상세 없이도 실시될 수 있음은 명백할 수 있다. 다른 경우에, 이 아키텍처의 설명을 용이하게 해주기 위해 공지의 구조 및 장치가 블록도 형태로 도시되어 있다.

본 출원에서 사용되는 바와 같이, 용어 "컴포넌트" 및 "시스템"은 컴퓨터 관련 개체, 즉 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행중인 소프트웨어를 언급하기 위한 것이다. 예를 들어, 컴포넌트는 프로세서상에서 실행 중인 프로세스, 프로세서, 객체, 실행 파일, 실행 스레드, 프로그램 및/또는 컴퓨터일 수 있지만, 이에 한정되는 것은 아니다. 예로서, 서버상에서 실행 중인 어플리케이션 및 서버는 컴포넌트일 수 있다. 프로세스 및/또는 실행 스레드 내에 하나 이상의 컴포넌트가 존재할 수 있고, 컴포넌트는 하나의 컴퓨터상에 로컬화 및/또는 2개 이상의 컴퓨터 간에 분산되어 있을 수 있다.

데이터 플랫폼은 어플리케이션 프로그래밍 환경과 잘 통합되어 있는, 어플리케이션이 데이터에 대한 액세스, 처리 및 관리를 행하기 위한 서비스(메커니즘)들의 컬렉션을 제공하는 플랫폼이다. 본 발명은 종래의 데이터 플랫폼에 대한 개선이다. 이 아키텍처는 다양한 어플리케이션 프레임워크(예를 들어, PIM(Personal Information Manager) 프레임워크 및 LOB(Line-of-Business) 프레임워크)에 걸쳐 공통인 데이터 서비스를 제공하는 공통 데이터 플랫폼(common data platform, CDP)이다. 어플리케이션의 범위는 탐색기(Explorer), 메일(Mail) 및 미디어(Media) 어플리케이션 등의 최종 사용자 어플리케이션, 문서 관리(Document Management) 및 협업(Collaboration) 어플리케이션 등의 지식 근로자(Knowledge Worker) 어플리케 이션, ERP(Enterprise Resource Planning, 전사적 자원 관리) 및 CRM(Customer Relationship Management, 고객 관계 관리) 등의 LOB 어플리케이션, 웹 어플리케이션 및 시스템 관리 어플리케이션을 포함한다.

CDP는 어플리케이션들에 적어도 이하의 이점을 제공한다.

1. 리치 스토어 - 모든 유형의 데이터(구조화된, 반구조화된 및 비구조화된 데이터)를 모델링 및 저장하는 기능.

a. 관계형 데이터 모델링 및 액세스

b. 리치 객체 추상화 및 프로그래밍 환경

c. XML 저장 및 쿼리를 통한 반구조화된 데이터 모델링

d. 파일로서의 비구조화된 데이터

2. 유연성있는 조직화 - 객체들의 임의적인 컬렉션을 테이블로서 구성하는 기능(정적으로 구성하지 않음).

a. 파일 시스템 네임스페이스 및 조직화를 지원함

3. 리치 쿼리/검색 - 모든 데이터를 질의하는 기능.

a. 리치 쿼리(예를 들어, SQL, OSQL(object-oriented SQL), XML 쿼리, C# 시퀀스)를 지원함. OSQL은 SQL의 수퍼셋(superset)인 함수 언어(functional language)이다.

4. 리치 거동 - 리치 데이터 거동을 지원함. 이것은 어플리케이션/비지니스 프로세스 로직에 대한 대용물이 아니다.

5. 유연성있는 관리 - 서로 다른 입도에서의 관리(예를 들어, 복사, 이동 및 직렬화 등의 아이템 레벨 동작).

6. 데이터 동기화 - 데이터의 임의적인 컬렉션의 피어-투-피어 및 마스터-슬레이브 동기화.

7. 공유 -다수의 어플리케이션 및 다수의 어플리케이션 프레임워크에 걸쳐 데이터를 공유하는 기능. 예를 들어, 아웃룩(Outlook) 및 CRM 어플리케이션에 걸쳐 연락처(Contact)를 공유하는 것.

8. 스키마 - 사용자 및 ISV(Independent Support Vendor) 어플리케이션이 서로 협업하는 것을 용이하게 해주는 풍부한 초기 설정(out-of-the-box) 스키마.

9. 유연성있는 배치 - 2-계층 및 3-계층 환경에 배치가능.

CDP 및 연관된 아키텍처는 상기한 이점 모두를 가능하게 해준다. 주요 특징은 계층화된 아키텍처, 다수의 어플리케이션 프레임워크에 걸쳐 공통인 모델링 개념들을 뽑아내는 공통 데이터 모델, 및 CDP 컴포넌트 (기능상) 아키텍처를 포함한다.

먼저, 도면들을 참조하면, 도 1은 CDP(102)를 이용하는 시스템(100)을 나타낸 것이다. CDP(102)는 데이터 어플리케이션 및 어플리케이션 프레임워크(104)와 데이터 스토어(106) 상의 데이터 간의 데이터 관리를 제공하는 데 이용된다. 데이터 스토어(106)는 예를 들어 구조화된, 반구조화된 및 비구조화된 데이터 유형을 저장할 수 있다. 전술한 바와 같이, CDP(102)는 어플리케이션 프레임워크 및 이와 연관된 최종 사용자 어플리케이션에 걸쳐 공통인 데이터 서비스를 제공한다. CDP(102)는 또한 어플리케이션 및 어플리케이션 프레임워크(104)와의 인터페이스를 용이하게 해주는 API(108), 런타임 컴포넌트(110), 및 제약/보안 엔진 컴포넌트(112)를 포함한다. API(108)는 공개 클래스, 인터페이스 및 정적 헬퍼 함수 형태로 CDP를 사용하는 어플리케이션을 위한 프로그래밍 인터페이스를 제공한다. 예로는 StorageContext, StorageSearcher, Entity, TableSet, Table, EntityReference, 및 TableReference가 있다. 데이터베이스 프로그래밍 언어 통합(예를 들어, C# 시퀀스 연산자)이 API(108)의 일부일 수 있음을 잘 알 것이다.

CDP 런타임 컴포넌트(110)는 공개 API 계층(108)에 노출된 여러가지 특징을 구현하는 계층이다. 이는 객체 관계형 매핑 및 쿼리 매핑을 제공함으로써, 데이터 모델 제약을 시행함으로써, 기타 등등에 의해 공통 데이터 모델을 구현한다. 보다 구체적으로는, CDP 런타임(110)은 공통 데이터 모델 컴포넌트 구현, 쿼리 프로세서 컴포넌트 세션 및 트랜잭션 컴포넌트, 세션 캐시 및 명시적 캐시(explicit cache)를 포함할 수 있는 객체 캐시, 변동 추적·충돌 검출 및 이벤팅(eventing)을 포함하는 서비스 컴포넌트, 커서 및 규칙(rule) 컴포넌트, 비지니스 로직 호스팅 컴포넌트, 및 코어 영속성(core persistence) 및 쿼리 서비스를 제공하는 영속성 및 쿼리 엔진을 포함한다. 영속성 및 쿼리 서비스 내부에는 쿼리/업데이트 매핑을 비롯한 객체 관계형 매핑이 있다. CDP(102)는 또한 데이터 스토어(106)에 대해 제약을 적용하는 것 및 보안 정책, 예를 들어 규칙 기반 보안을 적용하는 것을 제공하는 제약/보안 엔진(112)을 포함한다.

도 2는 별도의 데이터 스토어(도시 생략)의 스토어 관리 컴포넌트(202)와 인터페이스하는, CDP(102)를 포함할 수 있는 보다 상세한 CDP 시스템(200)을 나타낸 것이다. 다른 대안으로서, 스토어 관리 컴포넌트(202)는 SQL 서버 구현과 연관될 수 있는 데이터 스토어 등의 데이터 스토어를 포함할 수 있다. 데이터 스토어가 구조화된, 반구조화된 및 비구조화된 데이터 유형을 저장할 수 있음을 잘 알 것이다.

CDP의 목표는 다양한 어플리케이션 프레임워크(204)(AF₁, AF₂, ..., AF_Z로 표기함)에 대한 지원을 가능하게 해줌으로써 신속한 어플리케이션 개발을 지원하는 것이다. 이 프레임워크(204)는 예를 들어 LOB, 최종 사용자 및 시스템 관리 어플리케이션 프레임워크를 포함할 수 있다. 어플리케이션 프레임워크(204)(각각 AF₁, AF₂, ..., AF_Z)와 연관된 어플리케이션(206)(APP₁, ..., APP_S; APP₁, ..., APP_T)은 풍부한 어플리케이션을 개발하기 위해 각자의 어플리케이션 프레임워크(204), CDP(102), 및 하부의 스토어(202)를 이용할 수 있다. 계층화된 방법의 이점에 대해 이하에서 기술한다.

스토어 관리 계층(202)은 코어 데이터 관리 기능(예를 들어, 확장성, 용량, 이용가능성 및 보안)에 대한 지원을 제공하고, CDP 계층(102)은 어플리케이션 프레임워크(204)에 대한 리치 데이터 모델, 매핑, 쿼리 및 데이터 액세스 메커니즘을 지원한다. CDP 메커니즘은 다수의 어플리케이션 프레임워크(204)가 데이터 플랫폼상에 구축될 수 있도록 확장가능하다. 어플리케이션 프레임워크(204)는 어플리케이션 도메인(예를 들어, 최종 사용자 어플리케이션 및 LOB 어플리케이션)에 고유한 부가의 모델 및 메커니즘이다. 계층화된 아키텍처 방식은 몇 가지 이점을 갖는다. 이는 각각의 계층이 독립적이고 신속하게 혁신 및 배치될 수 있게 해준다. CDP 계층(102)은 보다 민첩할 수 있고, 혁신을 위한 더 많은 자유를 가질 수 있으며 또 스토어 계층(202)보다 더 빈번하게 혁신할 수 있다. 계층화된 방식은 CDP 계층(102)을 회사 전략에 맞춰 정렬시킨다. 마지막으로, 스토어 계층(202)은 이 전략에 부합하는 코어 데이터 관리 기능에 중점을 둘 수 있다.

이제 도 3을 참조하면, 공통 데이터 플랫폼을 구현하는 방법이 도시되어 있다. 설명의 간략함을 위해, 예를 들어 흐름도 형태로 본 명세서에 도시된 하나 이상의 방법이 일련의 단계들로서 도시되고 기술되어 있지만, 본 발명의 아키텍처가 단계들의 순서에 의해 제한되지 않는데, 그 이유는 본 발명에 따라 본 명세서에 도시되고 기술되어 있는 것과 다른 순서로 및/또는 다른 단계들과 동시에 행해질 수 있기 때문이라는 것을 잘 알 것이다. 예를 들어, 당업자라면 방법이 다른 대안으로서 상태도에서와 같이 일련의 상호 관련된 상태 또는 이벤트로서 표현될 수 있음을 잘 알 것이다. 게다가, 예시된 모든 단계들이 본 아키텍처에 따라 방법을 구현해야만 하는 것은 아닐 수 있다.

단계(300)에서, 구조화된, 반구조화된 및 비구조화된 데이터 유형을 모델링 및 데이터 스토어에 저장하는 코어 데이터 관리 계층이 제공된다. 단계(302)에서, CDP(110) 계층이 어플리케이션 프레임워크에 대한 리치 데이터 모델, 매핑, 쿼리 및 데이터 액세스 메커니즘을 지원하는 데이터 서비스를 제공하기 위해 코어 데이터 관리 계층 상부에 제공된다. 단계(304)에서, 하나 이상의 어플리케이션 프레임워크가 CDP를 오버레이한다. 단계(306)에서, CDP에 의해 제공된 데이터 서비스를 통해 이제 데이터 스토어의 데이터에 액세스할 수 있는 하나 이상의 어플리케이션이 각각의 어플리케이션 프레임워크 내에 제공된다.

도 4는 본 발명의 아키텍처의 CDP 컴포넌트의 개략도를 나타낸 것이다. 이 개략도에서 임의의 컴포넌트 및/또는 박스의 배치는 프로세스/기계 경계에 걸쳐 임의의 구체적인 배치를 암시하는 것이 아님(또는 꼭 그 배치를 못 하게 하는 것은 아님)을 잘 알 것이다. 변동이 저장되어야 하는데 다른 변경이 이미 하부의 데이터에 행해진 경우 충돌 검출이 어플리케이션 고유의 방식으로 이것을 해결하도록, CDP는 최적의 동시성 모델을 이용한다. 효과적인 데이터 플랫폼이 되기 위해서, CDP는 프로그래밍 언어 통합, 리치 데이터 모델링, 영속성 프레임워크, 서비스 및 기타 등등의 특징을 포함한다. API(108)는 CDP 런타임(110)을 통해 스토어(220)에 대한 어플리케이션(400)에 의한 데이터 액세스 및 언어 통합을 용이하게 해준다. 도메인 독립적(domain agnostic)이라는 것은 CDP가 데이터의 속성 및 형태 및 그에 요구되는 시맨틱 제약에 관하여 극히 최소한의 가정만을 한다는 것을 의미한다. 이를 위해, CDP는 이하의 특징(이하에서 보다 상세히 기술됨)을 제공한다.

공통 데이터 모델(Common Data Model, CDM): CDP 런타임(110)의 중심에 CDM(402)이 있다. CDM(402)의 목표는 다수의 어플리케이션 도메인에 걸쳐 공통인, 즉 사용자 데이터(PIM, 문서 등)를 주로 처리하는 어플리케이션에서부터 LOB 및 기업 데이터에 걸쳐 공통인 모델링 개념을 뽑아내는 것이다. 리치 객체 및 관계 추상화를 제공하는 것 이외에, CDM(402)은 구조화된, 비구조화된 및 반구조화된 데이터에 대한 지원도 제공한다.

행/개체 데이터(row/entity data) - CDM(402)은 구조화된 데이터(예를 들어, 비지니스 데이터)의 구조 및 거동을 포착하기 위해 리치 개체-관계 모델(Entity-Relationship model)을 지원한다. CDM(402)은 리치 객체 추상화 및 관계 모델링(예를 들어, 문서와 연락처 간의 저작자 관계, 구입 주문과 주문 상품(Order Line) 간의 라인 관계)을 위한 확장을 갖는, 코어 관계형 모델의 수퍼셋이다.

파일 데이터 - CDM(402)은 비구조화된 (파일) 데이터를 저장 및 처리하기 위해 "파일 스트림" 데이터 유형을 지원한다. 파일 스트림 데이터 유형은 데이터를 파일로서 저장할 수 있고, 파일 액세스 API를 지원한다. 파일 스트림 데이터 유형은 본질적으로 SQL 서버에서 지원되고, NTFS 파일 스트림으로 매핑되며, 파일 핸들(file handle)/스트림 기반 동작 모두를 지원한다. 개체 유형을 사용하여 CDM(402)에서 비구조화된 콘텐츠를 파일 스트림으로서 모델링하는 것 이외에, 유용한 콘텐츠가 구조화된 속성으로서 승격(promote)될 수 있다. 데이터베이스 기반 파일 저장 시스템은 비구조화된 콘텐츠의 파일 스트림과 함께 구조화된 속성을 모델링하는 개체인, 파일 배킹된 아이템(file backed item)의 개념을 정의한다. 파일 배킹된 아이템은 연관된 파일 스트림에 대한 스트림 기반 동작과 함께 리치 쿼리를 제공한다.

XML 데이터 - XML 문서는 CDM(402)에서 2가지 주요 방식으로 모델링될 수 있다. 즉, (1) XML 문서를 XML 데이터 유형으로서 저장하고, (2) XML 문서를 하나 이상의 개체로 매핑한다(예를 들어, 데이터 계약(data contract)과 유사함). CDM(402)은 SQL 서버에서 지원되는 XML 데이터 유형을 지원한다. XML 데이터 유형은 임의의 개체 속성의 유형일 수 있다. 즉, XML 데이터 유형은 유형 미지정(untyped) 또는 유형 지정(typed) XML 문서가 저장될 수 있게 해준다. 하나 이상의 XML 스키마를 XML 문서 속성과 연관시킴으로써 강한 유형 지정(strong typing)이 제공된다.

API(108)에서의 쿼리를 비롯한 프로그래밍 언어 통합: 코어 CDP 특징 컴포넌트-세션 및 트랜잭션(404), 쿼리(406), 영속성(408), 커서(410), 서비스(412), 객체 캐시(414) 및 비지니스 로직 호스팅(416)은 CDP API(108)에서 이용가능한 몇 가지 "런타임" 클래스(예를 들어, StorageContext)에 캡슐화되어 있다. CDM(402)에서 작성된 유형에 기초하여, CDP 설계시 도구는 강 자료형(strongly typed) CLR(Common Language Runtime, 공통 언어 런타임) 클래스를 발생한다. CDP는 CDM(402)에 의해 정의되는 유형 체계(type system)에 대한 쿼리 언어를 필요로 한다. CDP는 C# 시퀀스 연산자 및 OPATH를 그의 쿼리 언어로서 지원할 수 있다. 본 출원의 목적상, CDP에 의해 지원되는 쿼리 언어는 일반적으로 공통 쿼리 언어(Common Query Language, CQL)라고 말한다. CQL은 코어 관계형 대수(예를 들어, select, join 및 project 연산자)를 포함할 것으로 생각된다. 신택스가 SQL과 동일하지 않을 수 있지만, CQL은 간단하게 SQL로 매핑될 수 있다. CQL은 프로그래머가 처리하는 객체 구조에 대한 리치 쿼리를 가능하게 해준다. 목표는 C# 그룹에 의해 행해지고 있는 시퀀스 연산자 작업에 맞춰 CQL을 정렬하는 것이다. 이 특징은 관계형 데이터베이스 관리 시스템(RDBMS)(또는 임의의 다른 CDP 지원 스토어)에 저장된 데이터에 대한 강 자료형의 객체 기반 추상화를 효과적으로 제공한다. 게다가, CDP의 영속성 프레임워크는 POCO(Plain Old CLR Object)에 대한 영구 보존 및 쿼리를 하는 데 사용될 수 있다.

영속성 엔진(Persistence Engine) - 영속성 엔진은 관계형 스토어로부터 오는 컴포넌트 부품(component piece)으로부터 어떻게 객체가 조립되는지를 정확하게 기술하는 선언적 매핑 정의를 제공한다. 이 엔진은 객체 쿼리 표현식(object query expression)으로서 쿼리 프로세서에 의해 정의된 표현식을 취하고 이어서 이를 선언적 매핑과 결합시키는 쿼리 발생 컴포넌트(도시 생략)를 포함한다. 이것은 데이터베이스에서의 하부의 테이블에 액세스하는 동등한 쿼리 표현식으로 변환된다. 업데이트 발생 컴포넌트(도시 생략)는 변동 추적 서비스를 주시하고 있다가 매핑 메타데이터의 도움으로 객체의 세계에서의 이들 변동을 테이블의 세계에서의 변동으로 어떻게 변환시켜야 하는지를 기술한다.

파일 및 XML 데이터의 쿼리/검색 - 앞서 설명한 바와 같이, CDM(402)은 비구조화된 및 반구조화된 데이터를, 파일 스트림 및 XML 데이터 유형을 각각 사용하여 저장한다. CQL은 이들 데이터 유형을 쿼리할 수 있다. 구조화된 개체로 승격된 파일 콘텐츠의 경우(예를 들어, WinFS 파일 배킹된 아이템의 경우), CQL의 관계형 연산자는 이들 개체를 쿼리할 수 있다. 파일 스트림으로서 저장되어 있는 비구조화된 데이터는 전문 검색(full-text search)을 사용하여 쿼리될 수 있다. XML 콘텐츠는 XPath 또는 XQuery를 사용하여 쿼리될 수 있다.

객체-관계형 매핑(Object-Relational Mapping) - CDP가 관계형 (테이블) 스 토리지 상부에 객체 기반 추상화를 제공하기 때문에, 이는 O-R 매핑 컴포넌트를 제공할 필요가 있다. CDP는 규범적 매핑(prescriptive mapping)(CDP가 매핑이 어떻게 행해지는지를 결정함) 및 비규범적 매핑(non-prescriptive mapping)(유형 설계자가 매핑을 지정함에 있어서 얼마간의 유연성을 가짐) 둘다를 지원한다. 유의할 점은 데이터베이스 기반 파일 저장 시스템 구현이 현재 규범적 매핑을 사용하고 있지만 보다 일반적인 O-R 영속성 프레임워크가 비규범적 매핑을 필요로 한다는 것이다.

캐싱 - CDP 런타임은 쿼리 결과(예를 들어, 커서) 및 커밋되지 않은 업데이트의 캐시를 유지한다. 이것은 세션 캐시(session cache)라고 한다. CDP는 또한 어플리케이션이 분리 모드(disconnected mode)에서 동작할 수 있게 해주는 명시적 캐시(explicit cache)를 제공한다. CDP는 명시적 캐시 내의 데이터에 대한 여러가지 영속성 보증을 제공한다. 이 캐시는 데이터의 온-디스크 식별자(on-disk identity)를 인-메모리 객체(in-memory object)와 상관시킴으로써 식별자 관리를 수행한다.

쿼리 프로세서 - 스토어에 대해 쿼리를 행할 때, CQL 쿼리는 SQL로 매핑된다. 그렇지만, 명시적 캐시에 대한 것인 경우, CQL 쿼리는 QP 컴포넌트에 의해 처리된다. 데이터베이스 액세스는 쿼리 프로세서를 통한다. 쿼리 프로세서는 표현된 다음에 내부의 표준 포맷(canonical format)으로 매핑될 다수의 쿼리 언어를 다수의 프론트엔드(frontend)가 처리할 수 있게 해준다. 이것은 쿼리 프로세서가 동작하고 있는 어플리케이션의 도메인 모델 및 객체의 관점에서 행해진다. 이어서, 쿼리는 파이프라인인 프로세서로 전달되고 이어서 백엔드 관련 쿼리(backend-specific query)로 변환된다.

커서: CDP는 전방 전용(forward-only) 및 스크롤가능(scrollable) 커서 둘다를 제공한다. 커서는 통지, 확장/축소 상태를 갖는 다중 레벨 그룹화, 동적 정렬 및 필터링을 지원한다.

비지니스 로직 호스트: CDP는 유형/인스턴스 및 동작에 관한 데이터 중심 로직을 호스팅하는 런타임 환경을 제공한다. 이러한 데이터 중심 비지니스 로직은 어플리케이션 서버에서 호스팅될 수 있는 어플리케이션/비지니스 프로세스 로직과 다르다. 객체가 데이터베이스 내의 행만은 아니다. 객체가 메모리에서 구체화(materialize)될 때, 이들은 실제로 거동을 갖는, 어플리케이션이 호출할 수 있는 객체이다. 런타임 시에 모두가 주로 CDP를 확장시키는 동작을 하는 이벤트 및 콜백인 시스템 내의 확장 포인트가 있다. 이들 객체는 단지 객체가 아니라 CLR 객체, 즉 .NET 객체 등등이다. CDP는 이들 객체에서의 속성 또는 메소드 호출을 가로채기하는 기능을 허용한다. 어플리케이션은 이들 객체의 거동을 맞춤화할 수 있다.

서비스: CDP는 모든 CDP 클라이언트가 이용가능한 코어 서비스 세트를 제공한다. 이들 서비스는 규칙, 변동 추적, 충돌 검출, 이벤팅 및 통지를 포함한다. 이벤팅은 부가의 거동을 추가하기 위해 프레임워크 레벨 서비스로부터의 CDP 런타임(110) 또는 어플리케이션에 대한 CDP 런타임(110)을 확장하며, 또한 사용자 인터페이스에서 데이터 바인딩을 위해 사용된다.

제약: CDP는 적어도 유형 설계자가 제약을 선언적으로 작성할 수 있도록 해주기 위해 제약/보안 컴포넌트(112)를 제공한다. 이들 제약은 스토어에서 실행된다. 일반적으로, CDP 제약의 범위는 길이(length), 정밀도(precision), 스케일(scale), 디폴트(default), 검사(check), 기타 등등의 개념을 포괄한다. 이들 제약은 런타임 시에 CDP 제약 엔진에 의해 시행된다.

보안: CDP는 규칙 기반 보안 모델을 제공한다 - 사용자의 증명서(credential)가 그의 "역할"(관리자, 파워 사용자(power user), 승인자(approver), 기타 등등)을 결정한다. 각각의 역할은 일련의 접근 퍼미션(access permission)을 할당받는다. CDP의 보안 엔진은 이들 보안 정책을 시행한다. 게다가, CDP는 CDP 내의 개체에 대한 액세스를 제어하기 위한 보안 모델을 제공한다. 이 보안 모델은 오퍼레이팅 시스템 사용자의 인증, 개체의 권한 레벨(예를 들어, 읽기 및 업데이트에 대해 개별적인 퍼미션을 가짐), 기타 등등을 지원할 수 있다.

제약/보안 컴포넌트(112)가 CDP 런타임 컴포넌트(110)와 분리되어 도시되어 있는 것에 유의하며, 그 이유는 제약/보안 컴포넌트(112)가 그와 별도의 개체로서 동작할 수 있기 때문이다. 다른 대안으로서, 제약/보안 컴포넌트(112)가 데이터베이스 시스템일 수 있는 스토어 컴포넌트(202)와 결합되는 것이 아마도 보다 효율적이다.

모두 합하여, 이들 특징은 서로 다른 계층에 걸쳐 유연성있게 배치될 수 있는 데이터 중심 어플리케이션 및 로직을 개발하기 위한 강력한 플랫폼을 제공한다. 유의할 점은 동 도면에서의 런타임 컴포넌트(또는 박스)의 배치가 프로세스/기계 경계에 걸쳐 임의의 구체적인 배치를 암시하는 것이 아니라는(또는 꼭 그 배치를 못 하게 하는 것은 아니라는) 것이다. 이는 기능적 컴포넌트를 나타내는 데 사용되는 개략도이다.

CDP 아키텍처의 주요 이점 중 하나는 구현에 있어서 유연성을 제공한다는 것이다. 이는 2가지를 의미한다.

1) 도 4에 도시된 컴포넌트 중 어떤 것은 서로 다른 프로세서/계층에서 동작할 수 있다는 의미에서 "모바일"이다. 구체적으로는, 제약/보안 엔진(112)은 일반적으로 도 2의 스토어 프로세스(202)에서 동작한다.

2) 도 4에 도시된 모든 컴포넌트가 완전히 기능하는 데이터 플랫폼을 갖도록 구현될 필요는 없다. 구체적으로는, 객체 캐시(414)는 세션 캐시만으로 이루어질 수 있다. 다른 구현에서, 캐시(414)는 스토어와 동기화되어질 명시적 캐시를 포함할 수 있다. 쿼리 프로세서(406)는 객체 캐시(414) 내의 객체들에 대해 동작한다.

CDP의 몇 가지 특징 및/또는 컴포넌트에 대해 이후에 보다 상세히 기술한다. 전술한 바와 같이, CDP의 중심에 공통 데이터 모델(CDM)(402)이 있으며, 여기서 CDM(402)의 목표는 다수의 어플리케이션 도메인에 걸쳐, 즉 사용자 데이터를 주로 처리하는 어플리케이션(예를 들어, PIM, 문서, 기타 등등)에서부터 LOB 및 기업 데이터에까지 걸쳐 공통인 모델링 개념을 뽑아내는 것이다. 일반적으로, 이러한 기능을 구현하는 데 이용될 수 있는 2가지 가능한 기술이 있다. 1) 모든 생각할 수 있는 도메인(또는 생각할 수 있는 중요한 도메인)에 고유한 모델 개념. 예를 들어, "고객"이 의미하는 것 및 "사람"이 (사용자 도메인으로부터) 의미하는 것, 및 기타 등등을 정확히 정의한다. 2) 어플리케이션 설계자가 그 자신의 도메인 특유 유형, 제약, 관계를 생성할 수 있는 유연성있는 기초(flexible base)를 제공한다. CDM(402)은 기본적인 유형의 세트를 제공하고 또 새로운 유형을 작성하기 위한 유연성있는 프레임워크를 정의하도록 두번째 방식을 이용한다. 이 점에서, CDM(402)은 데이터 모델(예를 들어, 어떤 유형 및 그의 시맨틱을 실제로 정의함)도 될 수 있고 데이터 메타-모델(예를 들어, 다른 모델의 명세를 허용함)도 될 수 있다.

CDM(402)의 특징 중 어떤 것에 대해 이하에서 설명하지만 이를 본 출원에 대한 제한으로서 보아서는 안 된다. 데이터 모델은 관계형 데이터 모델을 포함할 수 있다. 환언하면, 테이블, 행, 쿼리 및 테이블에 관한 업데이트의 개념은 CDM(402)에 의해 노출된다. CDM(402)은 테이블 및 행보다 데이터에 대해 더 리치 객체 추상화를 정의할 수 있다. 상세하게는, CDM(402)은 개체, 개체들 간의 관계, 상속(inheritance), 포함(containment) 및 이러한 것의 컬렉션 등의 개념을 사용하여 실세계 인공물의 모델링을 가능하게 해준다. 게다가, CDM(402)은 프로그래밍 언어 유형 체계를 그 안에서 모델링된 어플리케이션 추상화에 맞춰 정확하게 정렬함으로써 어플리케이션 구조와 스토리지 구조 간의 임피던스 불일치(impedance mismatch)를 최소화할 수 있다. 게다가, 어플리케이션 거동(예를 들어, 메소드, 함수) 및 2-계층 및 다중-계층 어플리케이션을 가능하게 해주기 위한 거동의 유연성있는 배치에 대한 지원이 제공될 수 있다. CDM(402)은 또한 하부의 물리적 스토어와 독립적으로 영속성 시맨틱스를 포착할 수 있으며, 그에 따라 CDM(402)의 지원(enablement)이 광범위한 스토어에 걸쳐 구현될 수 있게 해준다.

CDM(402)은 복수의 개념을 호출할 수 있다. 도메인 관련 데이터 모델을 설계하도록 구현되기 위해 이하의 개념이 메타-모델에 의해 이용될 수 있다. 상세하게는, 이하의 개념이 CDM(402)의 코어로 생각될 수 있다. 1) 개체 유형(entity type)은 속성(property) 및 메소드(method)의 그룹에 대한 어플리케이션 설계자의 명세일 수 있으며, 여기서 개체는 개체 유형의 인스턴스이다. 개체 유형이 상속 계층구조(inheritance hierarchy)를 통해 구성될 수 있음을 잘 알 것이다. 2) 테이블은 다른 개체의 속성일 수 있는 개체들의 컬렉션이다. 개체, 상속 및 테이블을 사용하여, 어플리케이션은 재귀적으로 데이터 계층구조를 정의할 수 있다. 주어진 테이블이 주어진 유형 또는 그의 서브유형의 개체만을 포함할 수 있다는 의미에서 테이블은 강 자료형(strongly typed)일 수 있다. 3) 테이블 세트는 속성이 테이블인 개체일 수 있다. 이것은 테이블 및 개체를 사용하여 정의된 재귀적 데이터 계층구조에 대한 기본 경우이다. 이는 실질적으로 데이터베이스의 개념과 유사할 수 있다. 4) 관계는 개체들 간의 시맨틱 연결을 표현할 수 있다. 관계가 동료(associate), 포함(containment), 기타 등등을 정의하기 위해 확장될 수 있음을 잘 알 것이다.

개체, 관계 및/또는 테이블 세트 정의는 예를 들어 스키마의 관점에서 행해질 수 있다. 본 출원의 목적상, 스키마의 주된 목적은 스키마에 정의된 요소의 이름을 범위화(scoping)하기 위한 네임스페이스를 정의하는 데 있다. 테이블 세트는 CDM(402)의 "최상위 레벨"을 형성할 수 있다. 스토리지는 테이블 세트를 생성함으로써 직접적으로 및/또는 간접적으로 할당될 수 있다. 예를 들어, 이하의 의사 코 드는 테이블 세트의 예를 나타낸 것이다.

개체(Entity) 유형은 그와 연관된 속성 및 메소드를 가질 수 있다. 속성, 메소드 파라미터 및 메소드 반환값에 대한 유형을 지정하기 위해, CDM(402)은 몇 가지 내장된 유형(built-in type), 1) 단순 유형: Int32, string, 다른 CLR 값 유형, 2) 열거 유형: CLR enum과 동등함, 3) 참조 유형(이하에서 기술함) 및 4) 어레이 유형: 인라인 유형의 순서화된 컬렉션(이하에서 기술함)을 제공한다. 이들 내장된 유형의 속성은 Inline Type을 형성하기 위해 서로 그룹화될 수 있으며, 여기서 인라인 유형은 다른 인라인 유형의 멤버를 가질 수 있다. 이하는 상기한 것의 예이다.

개체는 내장된 유형 및/또는 인라인 유형을 이용하여 작성될 수 있다. 예를 들어, 이하의 의사 코드는 개체를 설명한다.

테이블 세트가 최상위 레벨 조직화 단위(organizational unit)이고 또 테이블 세트가 테이블들로 이루어져 있기 때문에, 개체(테이블 세트는 제외)는 적어도 부분적으로 테이블 내에 포함될 수 있다. 테이블 스코프 내에서, 각각의 개체는 고유의 키 값을 가질 수 있다. 스토어 전체의 스코프에서, 각각의 개체는 고유의 식별자를 가질 수 있으며, 그의 키 값은 재귀적으로 그의 테이블의 식별자와 연결(concatenate)되어 있다. 개체는 키 및/또는 식별자에 의해 참조가능한 CDM(402) 내의 가장 작은 단위일 수 있다. 스토리지 동작은 개체를 대상으로 할 수 있으며, 여기서 이 동작은 영구 보존(persist), 저장(store), 이동, 복사, 삭제, 이름변경(rename), 백업, 복원, 기타 등등일 수 있지만, 이에 한정되는 것은 아니다. 인라인 유형 인스턴스는 내포 개체(containing entity)와 관련하여 사용될 수 있다. CDM(402)은 CLR에서의 추상 클래스(abstract class)와 실질적으로 유사한 추상 개체 유형(abstract entity type)의 개념을 정의할 수 있다. 환언하면, 이들은 직접 인스턴스화될 수 없으며, 다른 인스턴스화가능 유형(instantiable type)을 생성하기 위해 파생될 수 있을 뿐이다.

개체 참조(entity reference)는 개체에 대한 지속성있고 영속적인 참조로서 정의될 수 있다. 참조 값의 범위는 개체 식별자들에 걸쳐 있다. 개체의 간접화(indirecting)가 그의 참조를 생성하며, 참조의 역참조화(dereferencing)가 개체 인스턴스를 생성한다. 참조의 주목적은 개체 공유(entity sharing)를 가능하게 해주는 것이다. 예를 들어, 동일한 고객에 대한 모든 주문은 Ref(Customer) 속성에 대해 실질적으로 유사한 값을 갖게 되며, 따라서 주문 개체는 고객 개체를 공유한다고 말해진다(예를 들어, 이하의 코드 샘플에서 6번째 코드 라인이 한 예이다).

CDM(402)과 연관된 데이터는 그의 구성 부분들 간에 관계를 갖는다. 관계형 모델은 관계를 명시적으로 지원하지 않으며, PK/FK/참조 무결성(Referential Integrity)은 제한된 방식으로 관계를 구현하는 도구를 제공한다. 그렇지만, CDM(402)은 연관(association) 및 합성(composition)을 사용하여 관계의 명시적 개념 모델링(explicit conceptual modeling)을 지원한다. 이하의 예는 연관 및 합성의 기능을 이해하기 위해 예시된 것이다.

연관은 개체들 간의 피어-투-피어 관계(peer-to-peer relationship)를 표현 할 수 있다. 상기 예에서, 주문은 연관을 통해 고객과 관련되어 있다. 상기 코드 샘플에서, 라인 6은 주문이 연관된 고객(이는 참조 속성 Customer에 의해 지정됨)을 가짐을 보여준다. 연관의 특성은 라인 12-15에 정의되어 있으며, OrderCustomer 연관이 Order로부터 Customer로 되어 있고(라인 15), 또한 각각의 Customer(라인 14 상의 Multiplicity = "1")에 대해, 다수의 Order가 있을 수 있다(라인 13 상의 Multiplicity = "*"). 상기 나타낸 연관의 유형은 참조 연관(reference association)이라고 할 수 있다.

CDM(402)은 2가지 다른 유형의 연관, 즉 값 연관(Value Association) 및 연관별 개체(Association by Association Entity)를 정의한다. 값 연관은 식별자 참조(identity reference)를 통해서만이 아니라 임의의 속성을 통해 관계의 표현을 가능하게 해준다(예를 들어, Document.Author 속성은 등식 조건(equality condition)을 통해 Contact.Name과 관련되어 있다). 연관 개체는 관계의 모델링을 가능하게 해주며, 여기서 관계 자체는 어떤 데이터를 전달한다(예를 들어, 회사와 사람 간의 고용 관계는 고용 기간 또는 회사 내에서의 그 사람의 직급 및 호칭 등의 속성을 전달할 수 있다).

합성은 부모-자식 관계 및/또는 포함 관계를 표현할 수 있다. 주문(Order) 및 주문 상품(OrderLine)을 생각해보자(예를 들어, Order는 여러분이 웹 사이트에서 장바구니에 넣은 것의 총계이고, OrderLine은 장바구니에 있는 각각의 개별적인 물품 - 책, DVD, 기타 등등 -이다.). 각각의 OrderLine은 Order와 관련해서만 의미가 있다. OrderLine은 내포 Order의 외부에 독립적으로 존재할 수 없다. 환언 하면, OrderLine은 Order 내에 포함되어 있으며, 그의 수명은 Order의 수명에 의해 결정된다.

상기 예시된 관계는 합성(Composition)을 사용하여 모델링될 수 있다. 라인 8은 합성의 예를 나타낸 것이다. Lines 속성 및 OrderOrderLines 합성(라인 18-22)은 주문이 주문 상품을 제어하고 주문 상품은 이 주문 상품을 포함하는 주문에 의존함을 표현한다. 주문이 부모이고 주문 상품이 자식임을 잘 알 것이다. 합성과 인라인 유형 간의 주된 차이점은 합성이 개체를 수반한다는 것이다. 환언하면, OrderLine이 참조의 대상(target)이 되는 것이 가능하지만, 상기 예에서 인라인 유형은 그럴 수 없다.

CDM(402) 및 그의 명시적 관계 모델링의 한 이점은 쿼리를 위한 메타데이터 지원을 제공한다는 것이다. 업스트림 쿼리(upstream query)도 역시 이용될 수 있다. 예를 들어, 고객이 주어지면, CDM(402) 내에서 NavigationProperty을 구현함으로써 모든 주문을 찾음(find all the orders)(명시적인 백포인터(explicit backpointer)를 저장할 필요없음)이 호출될 수 있다. 이것은 위에서 보여준 코드 단편의 라인 28에 나타내어져 있으며 편의상 이하에 다시 나타내었다.

영속성 엔진(408)은 객체 관계형 매핑을 포함할 수 있다. 환언하면, CDP에 의해 제공되는 모델링, 액세스 및 쿼리 추상화는 개체 기반이다. CDP에 의해 이용 되는 주된 스토리지 기술은 관계형 기반이다(예를 들어, SQL 2000). 영속성 엔진(408)은 객체 관계형 매핑("O-R 매핑"이라고도 함)을 이용하며, 여기서 영속성 엔진(408)은 언어 클래스를 하부의 테이블 표현으로 매핑할 수 있다.

영속성 엔진(408)은 O-R 매핑을 고려할 때 2가지 경우, 1) 규범적 O-R 매핑(prescriptive O-R mapping), 및 2) 비규범적 O-R 매핑(non-prescriptive O-R mapping)을 제공할 수 있다. 규범적 O-R 매핑은 CDP 유형들 간의 매핑을 말하며, 이들의 관계 표현은 CDP에 하드 코딩될 수 있다. 유형 설계자는 하부의 테이블의 레이아웃을 선택함에 있어서 유연성을 거의 및/또는 전혀 갖지 않는다. 이것의 예가 데이터베이스 기반 파일 저장 시스템일 수 있다. 비규범적 O-R 매핑은 CLR 클래스가 하부의 스토리지 구조에 어떻게 매핑되는지를 선택하기 위해 개발자가 가변적인 유연성 정도를 갖는 경우를 말한다. 고려될 수 있는 2가지 세부 경우가 있다. 1) 기존의 관계형 스키마의 객체로서의 노출. 유형 설계자는 CDM 유형을 설계하기 위해 고레벨 명세 언어를 사용하고, 그 유형에 기초하여 클래스를 발생하기 위해 도구를 사용하며, 유형이 테이블에 어떻게 매핑되는지를 지정하기 위해 유연성을 사용한다. 이 시나리오는 CDP 어플리케이션이 기존의 관계형 어플리케이션과 나란히(실질적으로 유사한 데이터를 사용한다는 점에서) 배치될 때 일어난다. 예를 들어, 자동차 회사의 IT 부서는 LOB 어플리케이션을 가지고 있을 수 있으며, 이 경우 그 부서는 (아마도 단계별 마이그레이션 전략의 일부로서) 동일한 데이터에 대해 동작하는 CDP 어플리케이션을 작성하기를 원한다. 그렇지만, 요구사항은 LOB 어플리케이션 및 새로운 CDP 어플리케이션이 모두 동일한 데이터에 대해 실행되어 야 한다는 것이다. 2) 클래스들의 컬렉션의 관계형 스키마로의 영구 보존. 개발자는 생성된 클래스를 사용하지 않으며, 오히려 그 자신의 설계의 클래스를 이용한다. 개발자는 이들 클래스를 관계형 스키마로 매핑하기를 원한다. 이러한 요구사항을 야기시키는 많은 서로 다른 시나리오가 있음을 잘 알 것이다.

CDP는 설계 동안에 이용될 수 있는 프로그래밍 표면(programming surface)(도시 생략)을 더 포함할 수 있다. 프로그래밍 표면은 CDP 어플리케이션 설계자(들) 및/또는 프로그래머(들)가 이용가능하도록 될 수 있다. 프로그래밍 표면은 3개의 일반 영역, 1) 설계시 프로그래밍 도구(예를 들어, 유형 설계자가 CDM 유형 및 그의 제약을 작성할 수 있게 해주는 도구), 2) API(예를 들어, CDP 어플리케이션을 작성하기 위한 클래스 및 메소드), 및 3) 쿼리(예를 들어, 개체 인스턴스 등의 CDM 객체를 쿼리하기 위한 언어)로 분류될 수 있다. 프로그래밍 표면의 이들 컴포넌트는 하부의 스토어 데이터에 대한 강 자료형 객체 기반 추상화를 제공하기 위해 상승적으로 동작한다.

CDP는 개체 유형, 개체 테이블, 개체 유형들 간의 관계 및 제약을 정의하기 위한, SQL의 데이터 정의 언어 또는 C# 클래스 정의와 유사한, 선언적 공통 스키마 정의 언어(Common Schema Definition Language, CSDL)를 제공한다. 3가지 주요 설계시 컴포넌트가 있다.

1. API 생성기. 어플리케이션 설계자는 CSDL을 사용하여 CDM 유형 및 관계를 설계하고, 이들 유형 및 관계에 대응하는 부분(partial) CLR 클래스를 생성하는 APIG(에이-피그라고 발음함)라고 하는 설계시 CDP 도구를 사용한다. APIG-생성된 클래스는 어플리케이션 프로그래머가 어셈블리로서 이용가능하며, C# using 절을 사용하여 그의 어플리케이션 프로그램에 의해 참조될 수 있다. APIG에 의해 생성된 클래스는 어떤 의미에서 표준형 클래스이고, 이들은 어플리케이션 프로그램 내의 CDM 유형의 직접적인 표현일 수 있다. 한 예에서, 어플리케이션 클래스는 그의 정의에 있어서 제약이 있을 수 있다 - 예를 들어 어플리케이션이 사전 작성된 클래스 라이브러리(그래픽 패키지, 수학 패키지, 기타 등등)로부터의 클래스를 사용하고 있을 때 등 -. 어플리케이션은 이들 클래스의 인스턴스를 스토어에 지속적으로 영구 보존하고 그에 대해 쿼리를 하기 위해 CDP의 객체 영속성 프레임워크를 사용할 수 있다. 이러한 객체는 POCO(Plain Old CLR Object)라고 할 수 있다. CDP는 POCO 시나리오도 역시 지원한다.

2. 객체-관계형 모델링. CSDL의 이 컴포넌트는 어플리케이션 설계자가 테이블 및 뷰 등의 스토어 개념들과 CLR 클래스들 간의 구체적이고 비규범적인 매핑을 선언하는 것을 돕는다. 이는 또한 CDM(402)의 관점에서 정의된 제약이 어떻게 SQL 선언적 제약, 즉 트리거 또는 저장 프로시저에 매핑될 수 있는지 지정할 수 있다.

3. 거동. CSDL은 어플리케이션 설계자가 비지니스 로직의 어느 부분이 인스턴스 메소드로서, 정적 함수로서, 저장 프로시저로서 구현되는지를 결정할 수 있게 해준다. 이는 또한 그 로직이 실행될 수 있는 계층을 결정한다(예를 들어, CDP 런타임 대 스토어).

프로그래밍 표면은 CDP API를 더 포함할 수 있으며, 여기서 프로그래밍 표면 어플리케이션이 작성될 수 있다. CDP API는 3개의 하위 부분을 가질 수 있다.

1. 일반 CDP 데이터 액세스. 이것은 스토어, 세션, 트랜잭션(예를 들어, StorageContext), 쿼리 서비스(예를 들어, StorageSearcher) 및 CRUD 서비스(예를 들어, SaveChanges)를 노출시키는 API의 일부분이다.

2. CDM 데이터 클래스. 이것은 개체(Entity), 관계(Relationship), 확장(Extension), 기타 등등의 CDM 개념들을 노출시키는 표준형의 어플리케이션-독립적인 클래스의 세트이다.

3. 도메인 데이터 클래스. 이들은 CDM(402)에 부합하지만 도메인 관련 속성 및 거동을 노출시키는 Contact, Message, PurchaseOrders 등의 어플리케이션/프레임워크-관련 클래스이다.

CDM(402)은 또한 쿼리 언어 CQL을 정의할 수 있다. CQL은 프로그래머가 처리하는 객체 구조에 대해 리치 쿼리를 할 수 있도록 설계되어 있다. 이하의 것은 CQL 형식주의(formalism)의 기초를 위해 이용되는 3가지 식별된 기술이다.

1. OPath: OPath 언어는 SQL 및 XPath에 뿌리를 두고 있으며 XPath의 CLR-객체 버전이도록 설계되어 있다. 이 설계는 객체들의 속성을 역참조하는 메소드를 순차적으로 노출시키기 위해 경로 표현의 XPath 개념에 의존한다. 이 설계는 한가지 간단한 원리에 기초한다, 즉 개발자는 객체들의 컬렉션을 객체 지향 API 내의 1차 "구조적" 구문(primary structural construct)으로서 보도록 기대한다. OPath는 데이터베이스 기반 파일 저장 시스템에 대한 POR 쿼리 형식주의일 수 있다.

2. 객체 SQL: 이 방식은 그래프 및 CDM 객체의 컬렉션을 처리하기 위해 SQL 쿼리 언어를 확장한다. CLR 객체의 그래프를 쿼리 및 처리하기 위해 설계된 SQL의 변형인 WinQL(Window Query Language)은 SQL에서 필요한 확장에 대한 후보 설계이다.

3. C# 시퀀스 연산자: 이것은 광범위한 부류의 CLR 객체의 일시적인 또는 영속적인 컬렉션에 적용될 수 있는 강 자료형 컴파일-타임 검사된 쿼리 및 세트 동작에 대한 C# 확장의 세트이다(예를 들어, 객체-관계형 매핑을 통함).

전략적으로, C# 시퀀스 연산자 방법은 CQL에 대한 프레임워크가 되도록 하는데 가장 의미가 있다. CQL은 쿼리 언어이다. 생성, 업데이트, 삭제는 객체 동작(new, 속성 설정자, 기타 등등)으로서 수행된다. 영속성 엔진(408) 내의 O-R 매핑 컴포넌트는 이들 동작을 SQL에서의 기초적인 DML 동작으로 매핑할 수 있다.

CDM 유형과 프로그래밍 표면 간의 관계에 대해 이하에서 기술한다. CDM(402)에서의 "유형"의 개념은 3가지 서로 다른 레벨에서 볼 수 있다.

1. 스키마 공간: CDM 스키마에서의 유형의 설명. 이들은 런타임 스택(예를 들어, 어플리케이션으로부터 스토어에 이르기까지)의 어떤 컴포넌트 내에서도 명시적으로 구체화될 수 없다는 점에서 추상 유형이다.

2. 어플리케이션 공간: CDP API 내의 CLR 클래스로서의 유형의 표현. 스키마 공간 내의 개체/인라인 유형과 어플리케이션 공간 내의 데이터 클래스 간에 일대일 대응관계가 있다. 환언하면, CDM 스키마 내의 각각의 개체 및 인라인 유형은 CLR 클래스를 생성할 수 있다. 종종 이들 클래스는 APIG에 의해 자동적으로 생성되지만, POCO 경우에서, 개발자는 스키마 공간에서의 CLR 클래스와 유형 간의 매핑을 명시적으로 지정할 수 있다. 어플리케이션 공간은 또한 개체 및 인라인 유형에 대한 클래스 이외에 관계 클래스를 포함할 수 있다.

3. 스토리지 공간: 하부의 스토어에서의 유형의 영속성 포맷. 스토어가 관계형 스토어인 경우, 이들 유형은 테이블/UDT/코어 SQL 유형이다. CDP의 O-R 매핑 컴포넌트는 스키마 공간 내의 유형이 스토리지 공간 내의 유형으로 매핑될 수 있게 해주는 매핑 스키마를 지원한다(예를 들어, Purchase Order 개체 유형은 SQL 서버에서의 PurchaseOrder 테이블로 매핑될 수 있다).

CDP 쿼리 언어는 어플리케이션 공간을 대상으로 한다. 이것이 의미가 있는 이유는 개발자가 다른 동작(예를 들어, 객체 및 컬렉션)에 대해 사용하는 거의 유사한 추상화를 사용하여 쿼리를 하고자 하기 때문이다. 그렇지만, CQL의 시맨틱은 CDM 추상화를 사용하여 기술된다(스키마 공간).

CDP는 또한 제약/보안(112)을 포함할 수 있다. 더 큰 시맨틱 컨텍스트 내에서 검사될 때, 거의 모든 데이터는 이런저런 형태로 그의 유형의 도메인에 걸쳐 제약을 받게 된다. 따라서, 유형 및 어플리케이션 설계자가 이들 제약을 표현하는 방법을 CDP가 제공하는 것이 아주 중요하다. CSDL은 유형 설계 시에 선언적으로 제약을 작성하기 위해 사용될 수 있다. 제약의 예는 1) 길이(length), 정밀도(precision), 스케일(scale), 디폴트(default) 및 검사(check) 등의 간단한 유형 제약, 2) 요소 제약(element constraints), 발생(occurs), 고유(unique) 및 검사(check) 등의 어레이 유형 제약, 및 3) 속성 제약, 기타 등등을 포함하지만, 이에 한정되는 것은 아니다.

이들 제약은 런타임 시에 CDP 제약 엔진에 의해 시행될 수 있다. 유의할 점 은 하부의 관계형 스토어의 레벨로부터 볼 때, CDM(402)에 부합한다는 바로 그 동작이 일련의 제약을 암시한다는 것이다. 예를 들어, CDM(402)은 "모든 개체가 그의 내포 테이블의 스코프 내에서 고유의 키를 가질 것"을 요구한다. 이것은 스토어 레벨에서의 고유 키 제약으로 변환된다. 이러한 제약의 몇 가지 다른 예가 있다. 여기서의 요점은 CDP 제약 엔진이 2가지 유형의 제약, CDM(402)에 의해 암시되는 제약(CDM(402)에 부합되기 위해 요구됨) 및 유형 설계자에 의해 작성되는 제약을 시행한다는 것이다. CSDL에서 작성되는 선언적 제약 이외에, 제약은 또한 SQL 서버 저장 프로시저를 사용하여 작성될 수 있다. 이 방법은 선언적 언어에서 가능한 것보다 더 복잡한 제약의 표현을 가능하게 해준다.

게다가, 제약/보안(112)은 CDP 내의 개체에의 액세스를 제어하기 위한 보안 모델을 제공할 수 있다. CDP에 대한 보안 모델은 적어도 이하의 시나리오를 만족시켜야만 한다.

인증(authentication): 보안 모델은 오퍼레이팅 시스템 사용자를 인증하는 것을 지원할 수 있다. 이것은 도메인 내의 사용자, 작업 그룹 또는 분리된 클라이언트 기계를 포함한다. 이는 또한 NTLM 및 Kerberos 기반 인증에 대한 지원을 포함할 수 있다.

권한(authorization): CDP 보안 모델은 적어도 개체 레벨에서 보안의 권한을 지원할 수 있다. 이는 또한 개체의 읽기 및 업데이트에 대한 개별적인 퍼미션을 관리할 수 있게 해주어야만 한다. 최소한, 제약/보안(112)은 개체의 보안 식별자로서 생각되는 개체의 "속성" 및/또는 일련의 속성들을 제공한다. 개체의 액세스 권리는 보안 식별자를 파라미터로서 취하는 테이블과 연관된 함수에 의해 결정된다. CDP는 또한 보안 식별자를 변경시킬 수 있는 사용자를 개체의 나머지를 변경시킬 수 있는 사용자와 분리하여 프로비저닝할 수 있어야만 한다. CDP가 단지 읽기 및 쓰기만 하는 것보다 여러가지 퍼미션도 허용할 수 있는 일반적인 역할 기반 모델을 지원할 수 있음을 잘 알 것이다.

CDP 런타임(110)은 쿼리 결과(예를 들어, 이하에 보다 상세히 기술되는 커서) 및 커밋되지 않은 업데이트의 캐시(414)(예를 들어, 객체 캐시(414))를 유지하며, 여기서 이러한 캐시는 세션 캐시라고 할 수 있는데 그 이유는 이 캐시가 세션, 트랜잭션(404)과 연계되어 있기 때문이다. 게다가, 이는 세션이 생성될 때 존재하게 되고 세션이 종료될 때 사라진다. CDP 세션은 StorageContext 객체 내에 캡슐화된다. 어플리케이션은 StorageContext의 다수의 인스턴스를 인스턴스화할 수 있으며 그에 따라 다수의 세션, 따라서 다수의 세션 캐시를 인스턴스화할 수 있다. CDP는 또한 명시적 캐시(explicit cache)라고 하는 다른 종류의 캐시를 노출시킬 수 있다. 명시적 캐시는 하나 이상의 쿼리로부터의 데이터의 캐시를 제공한다. 데이터가 명시적 캐시로 구체화되면, 이하의 데이터 일관성 보증, 1) 읽기 전용, 비인가(non-authoritative), 2) 라이트-쓰루(write-through), 인가(authoritative), 및 3) 외부 통지(exogenous notification)를 통한 자동적 리프레쉬가 제공될 수 있다. 명시적 캐시에 대한 프로그래밍 및 쿼리 모델은 스토어 데이터에 대한 것과 거의 유사할 수 있다.

커서, 규칙(410)은 CQL로부터 반환된 일련의 데이터 개체가 한번에 하나씩 처리될 수 있게 해주는 메커니즘을 말한다. 어플리케이션은 전체 결과 세트를 메모리로 단지 복사하고 메모리 구조에서 이것의 상부에 스크롤링 패턴을 오버레이함으로써 결과 세트에 걸쳐 커서를 생성할 수 있다. 이러한 요건의 편재성(ubiquity) 및 커서를 구현하는 데 때때로 관여되는 복잡성(특히 업데이트, 페이징, 기타 등등이 고려될 때)은 어떤 데이터 플랫폼이라도 커서링 모델을 제공해야만 함을 의미한다.

CDP는 전방 전용 및 스크롤가능 커서 둘다를 제공한다. 브라우징 및 스크롤링의 기본적인 기능 이외에, CDP 커서는 이하의 특징, 1) 외부 통지 및 유지보수, 2) 확장/축소 상태를 갖는 다중 레벨 그룹화, 및 3) 동적 정렬 및 필터링(예를 들어, 사후-처리)을 제공한다. 커서가 결과 세트를 지정하기 위한 다른 메커니즘이 아닐 수 있으며 결과 세트는 쿼리에 의해 지정되고 커서는 이들 쿼리에 대한 것임을 잘 알 것이다.

CDP는 또한 비지니스 로직 호스팅(416)을 포함할 수 있다. 다수의 어플리케이션이 거의 유사한 데이터를 처리하고 있을 때, 주요 요건은 데이터가 신뢰할만한 상태로 있도록 보장하는 것이다, 즉 데이터가 여러가지 검증 규칙, 비지니스 규칙 및 유형 설계자 및/또는 데이터 소유자에 의해 마련된 임의의 다른 검사 및 균형 체계에 부합하도록 보증하는 것이다. 어플리케이션이 일반적으로 신뢰할 수 없다고 가정하는 것이 좋다. 우매함, 악의 및/또는 예측하지 못한 사용 패턴의 단순한 긴급성으로부터, 어플리케이션은 무효(invalid)를 저장 및/또는 저장하려고 시도한다. 예를 들어, 사용자는 영역 코드로서 292를 입력할 수 있고 292가 무효인 영역 코드임에도 어플리케이션은 이러한 숫자를 저장하며, 따라서 전화 번호 필드 내의 이 값은 더 이상 전화 번호를 나타내지 않는다. 환언하면, 이는 전화 번호인 것으로 "신뢰"될 수 없다. 이것을 방지하는 보통의 방법은 신뢰 영역(trust boundary)(별도의 프로세스에서 실행되고 어플리케이션에 의해 행해진 데이터 변동을 검사하여 이러한 변동을 "승인"하는 선언적 규칙/검증 코드/기타 등등(예를 들어, 통상 비지니스 로직이라고 함)의 어떤 보디)를 생성하는 것이다. 이어서, 이는 이들 변동을 스토어에 저장할 수 있다. 많은 경우, 비지니스 로직은 검사-승인보다 더 많은 일을 한다. 이는 또한 비지니스 규칙을 시행하고, 작업 흐름이 일어나도록 하며, 기타 등등을 한다(예를 들어, 새로운 고객이 삽입될 때, 신용도를 보장하기 위해 이메일이 신용-체크 부서로 전송되어야만 한다).

CDP는 비지니스 로직(BL)을 작성하기 위한 몇 가지 메커니즘을 제공한다. 이들 메커니즘은 이하의 5개의 카테고리, 즉 제약(constraint), 이벤트 핸들러(event handler), 정적/인스턴스 메소드(static/instance method), 바인딩가능 거동(bindable behavior), 및 정적 서비스 메소드(static service method)로 나누어질 수 있으며, 이들 각각에 대해 이하에서 보다 상세히 기술한다. 제약/보안(112)은 전술한 바와 같이, 선언적이고 절차적일 수 있다. 이들 제약은 데이터에 근접한 스토어에 대해 실행될 수 있다. 따라서, 제약(112)은 신뢰 영역 내에 있는 것으로 간주된다. 게다가, 제약은 유형 설계자에 의해 작성될 수 있다.

비지니스 로직 호스팅(416)은 이벤트 핸들러를 이용할 수 있다. CDP API는 데이터 변경 동작 시에 몇 가지 이벤트를 발생한다. BL 저작자는 핸들러 코드를 통해 이들 이벤트에 후킹할 수 있다. 예를 들어, 주문 관리 어플리케이션을 생각해보자. 새로운 주문이 들어올 때, 어플리케이션은 주문의 가격이 고객에 대해 허가된 신용 한도보다 작도록 보장할 필요가 있다. 이 로직은 주문이 스토어에 삽입되기 전에 실행되는 이벤트 핸들러 코드의 일부일 수 있다.

광의적으로 말하면, 이하의 유형의 이벤트, 1) 검증(validation)(예를 들어, 이들 이벤트는 관심있는 당사자가 제안된 가격을 검사하고 이를 검증할 기회를 제공함), 2) 사전-저장(pre-save)(예를 들어, 이 이벤트는 변동을 스토어에 저장하기 바로 전에 발생되고 SQL 서버에서의 "BEFORE" 트리거와 목적 및 거동이 거의 유사할 수 있음), 및 3) 사후-저장(post-save)(예를 들어, 이 이벤트는 변동을 스토어에 저장한 후에 발생되고, SQL 서버에서의 AFTER 트리거와 목적 및 거동이 거의 유사할 수 있음)이 있을 수 있다. 이러한 유형의 BL은 CDP에서 실행되고, 따라서 CDP가 설치되어 있는 임의의 계층 상에서 실행될 수 있다. 따라서, 이러한 BL이 클라이언트 계층 상에서 실행될 때, 이는 다른 어플리케이션에 의해 우회(bypass)될 수 있다(예를 들어, 이는 신뢰 영역 내에서 실행되지 않는다).

게다가, 비지니스 로직 호스팅(416)은 정적/인스턴스 메소드를 호출할 수 있다. CDM 유형에 대해 자동 생성된 클래스는 부분 클래스(partial class)이다. 유형 설계자는 특정의 유형 또는 일련의 유형들에 의미가 있는 로직을 구현하기 위해 이들 부분 클래스 상에 부가의 메소드를 추가함으로써 이를 완성할 수 있다. 이하의 예, person.GetOnlineStatus()(단, person은 Person 유형의 인스턴스임), emailAddr.IsValidAddress()(단, emailAddr은 SMTPEmailAddress 유형의 인스턴스 임), 기타 등등을 생각해보자. 그의 특성상, 이러한 종류의 BL은 시행가능하지 않으며, 예를 들어 유효성을 보장하기 위해 IsValidAddress()를 호출하는 것은 어플리케이션의 몫이다. 이는 CDP가 배치되어 있는 임의의 계층 상에서 실행된다. 따라서, CDP가 클라이언트 계층 상에 있을 때 이는 신뢰 영역 내에서 실행되지 않는다.

바인딩가능 거동은 유형 설계자가 제3의 확장을 위한 플러그-인 지점을 생성할 수 있게 해주는 코딩 패턴이다. 전통적인 예는 이메일 메시지에 대한 유형이다. 서로 다른 이메일 프로그램이 주어진 기계 상에서 실행 중일 수 있다. 각각의 프로그램은 공통 메시지 유형을 사용하기를 원하지만, 각각의 프로그램은 또한 SendMessage 메소드의 거동을 맞춤화할 필요가 있다. 유형 설계자는 SendMessage 메소드에 대한 기본적인 거동을 정의하고 써드 파티가 이 구현에 포인터를 제공할 수 있도록 해줌으로써 이것을 달성한다. 바인딩가능 거동도 역시 CDP가 배치되어 있는 임의의 계층 상에서 실행된다. 따라서, CDP가 클라이언트 계층 상에 있을 때, 이는 신뢰 영역 내에서 실행되지 않는다.

정적 서비스 메소드는 중간 계층 상에서 작성 및 배치되고 클라이언트 계층으로 리모팅(remote)된 BL이다. 환언하면, BL은 중간-계층 상에서 웹 서비스로서 실행된다. 예를 들어, CreateAppointment(), GetFreeBusy(), 기타 등등의 서비스를 제공하는 일정 관리 서비스(Calendar Management Service)를 생각해보자. 이들 서비스("정적 서비스 메소드")는 CDP를 사용하여 구현되고, 웹 서비스는 중간-계층 상에 배치된다. 클라이언트 계층은 채널(이하에서 기술함)을 사용하여 이들 서비 스를 호출하기 위해 어플리케이션에 의해 사용되는 웹 서비스 프록시를 갖는다. 이러한 종류의 BL은 중간-계층 상에서 실행될 수 있고, 신뢰 영역 내에 있을 수 있다.

컴포넌트화된 아키텍처가 CDP를 어느 정도 스토어 독립적인(store agnostic) 채로 있도록 해줄 수 있다는 것을 잘 알 것이다. 객체 캐시, 커서, 세션, 트랜잭션, 기타 등등의 CDP 특징은 CDP 레벨 추상화를 이용한다. 하부의 스토리지 추상화로 매핑하는 것은 O-R 매핑 및 영속성 계층에서 일어난다. 매핑 로직을 작성함으로써, CDP는 다른 스토어 상에 구현될 수 있다.

도 5는 CDP의 여러가지 컴포넌트 내에서의 데이터 흐름을 나타낸 것이다. 이하의 예를 사용하여 어플리케이션(500)(어플리케이션(206) 및 어플리케이션(400)과 유사함)에 의한 메소드 호출에 응답하여 여러가지 컴포넌트의 상호작용을 검사하는 것은 도움이 된다.

이 예는 영속적인 ShoppingCart에 물품을 추가한다. 이 메소드가 예를 들어 ASP.NET 웹 페이지를 처리하는 것의 일부로서 호출되는 것으로 생각해보자.

라인 3: 스토리지 컨텍스트를 생성. StorageContext는 어플리케이션(500)에 의해 생성되는 OrderData 객체에 의해 캡슐화된다. OrderData 클래스는 CDM 스키마에 기술되어 있는 테이블 세트 유형을 나타낼 수 있다. OrderData 객체는 필요에 따라 스토어(202)와 상호작용하도록 구성된 StorageContext 객체를 생성한다. StorageContext의 초기화 코드는 런타임 세션 및 트랜잭션 컴포넌트(404)의 일부일 수 있으며, 이 컴포넌트는 스토어(202)로의 연결을 개설하고 세션을 개시 및 트랜잭션 컨텍스트를 생성하는 데 필요한 작업을 한다. 보안 컨텍스트는 제약/보안 컴포넌트(112)에 설정된다. 마지막으로, StorageContext의 인스턴스는 API(108)에 의해 어플리케이션(500)으로 반환된다. 2-계층 경우에서, StorageContext를 가져오면 스토어(202)로의 연결이 행해진다. 3-계층 배치에서의 연결이 약간 다를 수 있음이 잘 알 것이다.

라인 5: 쿼리. 라인 5의 표현식의 우측은 OPath 쿼리이다. 영속성 및 쿼리 엔진(408)은 CDM 쿼리에 기초하여 객체를 검색하는 메소드와의 기본적인 인터페이 스를 노출시킨다. CDM(402)에서의 CDM 구현은 지정된 OPath로 메소드를 호출한다. 영속성 및 쿼리 엔진(408)은 쿼리를 SQL로 매핑하고 이를 유선을 거쳐 TDS 페이로드로서 전송한다. 제약/보안 컴포넌트(112)는 보안이 적절히 적용되고 또 어플리케이션/사용자가 볼 수 있도록 허용된 데이터만을 보도록 보장한다. 스토어는 쿼리를 실행하고 그 결과를 다시 CDP 런타임(110)으로 반환한다. CDM(402) 및 영속성/쿼리 엔진(408)은 함께 동작하여 TDS 결과로부터 객체들을 하이드레이트(hydrate)시키고, 이들 객체를 객체 캐시(414)(예를 들어, 세션 캐시)에 배치한다. 그 결과 API(108)가 ShoppingCart 객체를 어플리케이션(500)으로 반환한다.

라인 9: 쿼리. 이 쿼리는 물론 이전의 쿼리의 결과 어떤 커서도 생성되지 않았다(GetFirst() 메소드는 기본적으로 쿼리에의 "1순위" 절에 적용된다). 그렇지만, 쿼리가 커서가 생성되어야 함을 요구하는 경우, 커서/규칙 컴포넌트(410)가 이 동작을 수행한다.

라인 12: 업데이트. 객체 캐시(141) 내의 ShoppingCart 객체는 지정된 Product로 업데이트된다.

라인 13: 변동의 플러쉬(Flush Changes). OrderData 객체에 대한 SaveChanges()의 구현은 캡슐화된 StorageContext 객체에 대해 SaveChanges()를 호출한다. StorageContext.SaveChanges()는 비지니스 로직 호스팅 컴포넌트(416)의 일부이다. 이것은 이하의 단계들을 수반한다. 먼저, 사전-저장(pre-save) 로직이 실행된다. 이어서, 검증 코드가 실행되고, 뒤이어서 사후-저장(post-save) 프로세스가 실행된다. 검증 코드가 CDP API(108)에 의해 정의되는 이벤트 내에 후킹된 다. 유의할 점은 다른 구현에서, 검증 코드가 객체에 대한 설정자(setter)에 후킹될 수 있다는 것이다. 그 다음에, 사전-저장 코드가 실행된다. 이 코드는 CDP API(108)에 의해 정의되는 이벤트 내에 후킹된다. 변동을 스토어에 기록한다. 먼저, 호스팅 컴포넌트(416)는 이 스토리지 컨텍스트 내에서 행해진 모든 변동을 포함하는 변동 벡터(change vector)를 가져오기 위해 객체 캐시(414)와 함께 동작한다. 영속성 엔진(408)은 Write(<changeVector>), 기타 등등의 메소드를 갖는 기본적인 인터페이스인 IPersist라고 하는 인터페이스를 노출시킨다. 호스팅 컴포넌트(416)는 영속성 엔진(408)으로부터 IPersist를 가져오고 변동 벡터로 IPersist.Write()를 호출한다. 영속성 엔진(408)은 기록 요청을 적절한 SQL 업데이트(실제 UPDATA문 또는 저장 프로시저 호출)로 매핑하고 이를 사용하여 변동을 스토어(202)에 기록한다. 이 프로세스 동안, 제약/보안 컴포넌트(112)는 적절한 보안 시행이 행해지도록 보장한다. 이는 또한 임의의 제약 로직을 실행한다. 마지막으로, 사후-저장 코드가 실행된다. 이 코드는 CDP API(108)에 의해 정의되는 이벤트 내에 후킹된다.

유의할 점은 비지니스 로직을 실행하면 캐시(414) 내의 객체에 변동이 일어날 수 있다는 것이다. 이들 변동은 비지니스 로직(416)이 우회되지 않도록 보장하는 myStorageContext.SaveChanges()의 호출에 의해 스토어(202)에 보존된다. 다수의 ISV(Independent Support Vendor)가 데이터 변동에 대해 로직을 실행하고자 할 수 있으며, 이 경우 이들은 그의 핸들러를 이벤트에 후킹하고 이 핸들러는 CLR에 의해 FIFO(First In/First Out) 순서로 호출된다. 이 예에서, 비지니스 로직(416) 은 ISV 검증, 사전-저장, 및 사후-저장 로직을 호스팅한다.

도 6은 CDP로 구현될 수 있는 여러가지 프레임워크를 나타낸 것이다. CDP는 여러가지 특수화된 수직 도메인 - 사용자 데이터, LOB 데이터, 기타 등등 - 에 걸쳐 사용가능하도록 설계되어 있는 데이터 플랫폼이다. CDM은 도메인 관련 구조 및 시맨틱을 표현할 정도로 충분히 풍부하지만 그와 동시에 서로 다른 도메인에 걸쳐 사용가능할 정도로 충분히 일반적인 도메인 독립적인 데이터 모델을 제공한다. 여러가지 CDP 특징이 CDM에 기초하며, 따라서 모든 도메인의 어플리케이션에 걸쳐 이용가능하다.

CDP에 대해 작성된 모든 어플리케이션의 세계는 이하의 3가지 부류로 나누어질 수 있다.

1. 프레임워크: 프레임워크는 특정의 도메인에 대해 CDP를 맞춤화하기 위해 CDP에 의해 제공된 확장성 메커니즘을 사용한다. 프레임워크는 유형 특수화(type specialization) 및 부가의 서비스로 CDP에 가치를 더한다. 그렇지만, 어플리케이션에 노출된 프로그래밍 모델은 CDP 프로그래밍 모델이다. 상세하게는, 어플리케이션은 여전히 데이터 클래스 StorageContext, StorageSearcher 및 CQL을 사용한다. 데이터베이스 기반 파일 저장 시스템은 사용자 데이터 도메인에 대해 맞춤화되는 CDP 상부의 프레임워크의 예일 수 있다.

2. 수직 플랫폼: 그 자신의 API, 추상화 및 데이터 모델을 갖는 CDP 상부의 별도의 계층. 이는 CDP를 은폐시키고 완전히 다른 프로그래밍 모델을 어플리케이션에 노출시킨다. 예를 들어, 이메일과 관련하여 이용되는 어플리케이션은 CDP를 사용할 수 있지만 그의 사용자를 위해 이메일 객체 모델(Email Object Model)을 노출시킨다.

3. "정규" 어플리케이션. 일련의 특정 작업을 달성하기로 되어 있는 CDP 어플리케이션. 이는 임의의 CDP 유형을 특수화하지도, 프로그래밍 모델을 노출시키지도, 임의의 프레임워크 또는 수직 플랫폼을 사용하지도 않는다.

수직 플랫폼 및 "정규" 어플리케이션은 단지 코드일 뿐이며, 이들은 열정이나 편견없이 원하는 임의의 방식으로 CDP를 사용할 수 있다. 프레임워크는 약간 다르며, 프레임워크가 CDP를 어플리케이션으로부터 은폐시키지 않고 CDP에 가치를 부가하기 때문에, 이들은 이하의 규칙을 준수할 수 있다.

1. 프레임워크 데이터 모델은 CDM과 동일하거나 CDM의 간단한 잘 문서화된 특수화이다. 이는 새로운 유형을 정의할 수 있지만, 이들 유형은 개체(Entity)에 의해 궁극적 수퍼타입으로 지정된다(ultimate-supertyped).

2. 프레임워크는 CSDL을 사용하여 기존의 CDM 유형에 대한 부가의 제약을 정의 및/또는 새로운 제약을 작성할 수 있다. 환언하면, 제약은 제약 정의를 위한 CDM 방법을 사용하여 표현되어야만 한다.

3. 프레임워크는 보통 그 자신의 쿼리 언어를 노출시키지 않으며, 노출시키더라도 CQL 대신이 아니라 그에 부가하여 행해질 수 있다.

4. 프레임워크는 보통 그 자신의 프로그래밍 모델을 노출시키지 않으며, 노출시키더라도 CDP API 대신이 아니라 그에 부가하여 행해질 수 있다.

5. 프레임워크는 CDP 상부에 부가의 특수화된 서비스를 제공한다. 이들 서 비스는 CDP 비지니스 로직으로서 또는 부가의 헬퍼 클래스 및 메소드로서 구현될 수 있다.

상기한 규칙들 모두는 어플리케이션이 주어진 프레임워크를 사용하는지 여부에 상관없이 그 프레임워크에 의해 CDP에 저장된 데이터가 모든 어플리케이션이 액세스가능하게 될 수 있도록 보장하기 위한 것임을 잘 알 것이다.

도 6은 CDP 계층(602) 상부의 3개의 프레임워크, 사용자 어플리케이션 프레임워크(UAF)(604)(예를 들어, 데이터베이스 기반 파일 저장 시스템, WinFS, 기타 등등), 협업 프레임워크(608)(WSS 등), 및 비지니스 프레임워크(610)(BF)(예를 들어, LOB 프레임워크)를 나타낸 것이다. 각각의 프레임워크에 속하는 데이터는 프레임워크 박스와 동일한 패턴으로 도시되어 있다. 예를 들어, UAF(604)는 연락처(618) 및 아이템(620) 데이터를 가지며, 협업 프레임워크(608)는 문서 라이브러리(622) 데이터를 가지며, BF(610)는 주문(624) 데이터를 갖는다. 유의할 점은 이들 유형 모두가 개체(Entity)(626)에 대해 궁극적-수퍼타입(ultimate-supertyped)이라는 것이다.

도 6은 또한 어플리케이션 계층에 3개의 어플리케이션, 연락처 관리 어플리케이션(612), 협업 어플리케이션(614)(이메일 어플리케이션 등) 및 고객 관계 관리(CRM) 어플리케이션(616)을 나타내고 있다. 연락처 관리 어플리케이션(612)은 전적으로 UAF(604)로부터의 데이터를 처리하고, CRM 어플리케이션(616)은 UAF(604) 및 BF(610) 둘다로부터의 데이터를 처리하며, 협업 어플리케이션(614)은 3개의 프레임워크(예를 들어, UAF(604), 협업 프레임워크(608) 및 BF(610)) 모두로부터의 데이터를 처리한다.

도 7은 다수의 어플리케이션이 데이터를 공유할 수 있게 해주는 공통 데이터베이스 기반 파일 저장 시스템 시나리오를 나타낸 것이다. 환언하면, 도 7은 다수의 어플리케이션이 단일의 프레임워크를 사용하는 것을 나타낸 것이다. CDP 컴포넌트 및 스토어 컴포넌트(702)(도 7에서 CDP + 스토어로서 나타냄)는 오퍼레이팅 시스템에 대해 임의의 모든 어플리케이션에 의해 이용되는 단일의 데이터 플랫폼이 되도록 이용될 수 있다. 이점(전술하였음)은 리치 모델링, 데이터 투명성, 및 데이터 공유이다. 이들 이점에 대해 이하에서 보다 상세히 기술될 수 있다.

CDM은 일련의 다양한 어플리케이션 및 시나리오에 의해 요구되는 유형들을 기술하는 데 사용될 수 있는 유연성있는 모델링 환경을 제공한다. 예를 들어, 사용자 데이터(예를 들어, 문서, 파일, 사진, 음악,...), LOB 데이터(예를 들어, 고객, 주문, 주문 상세,...), PIM 데이터(예를 들어, 연락처, 이메일, 일정, 작업,...)는 모두 CDM을 사용하여 모델링될 수 있다. 구조화된, 반구조화된 및 비구조화된 데이터에 걸쳐 있고 또 수직 도메인에 걸쳐 있는 이러한 종류의 리치 모델링은 단일의 어플리케이션이 공통의 추상화 및 쿼리 언어를 사용하여 여러가지 종류의 데이터를 처리하는 것을 가능하게 해준다. 환언하면, CDP는 하나의 스토어로서 사용될 수 있다.

CDP는 모든 어플리케이션에 의해 이용되는 단일의 데이터 플랫폼으로서 이용될 수 있다. 게다가, CDP를 사용하여 저장된 데이터는 이를 처리하는(예를 들어, 보안 정책이 적용되는) 모든 어플리케이션이 이용가능하게 될 수 있다. 이하의 것 을 생각해보자. 즉, 각각의 어플리케이션은 데이터를, 그 어플리케이션 자체(예를 들어, 데이터를 저장한 어플리케이션)를 제외한 다른 어플리케이션에 불투명한 포맷으로 저장한다. 단지 2개의 예를 제공하기 위해, 이메일 우편함의 콘텐츠가 이메일 어플리케이션을 제외한 다른 어플리케이션 모두에 불투명하고, CRM 어플리케이션은 고객, 사례, 기타 등등의 추상화를 생성하기 위해 그 어플리케이션이 테이블 상부에 오버레이하는 일련의 정교한 스키마를 가지며, 따라서 "고객"의 개념을 다른 어플리케이션 모두에 불투명하게 만든다(예를 들어, 어플리케이션들이 CRM 어플리케이션에 의해 사용되는 스키마를 알고 있지 않은 한).

명백하게도, 이메일 어플리케이션에는 CRM 어플리케이션에 의해 저장된 데이터와 개념적으로 유사한 데이터가 있다 - 한 예가 연락처 정보이다 -. 사용자에 관한 한, 연락처는 연락처이다. 이 관점에서 볼 때, 동일한 연락처 정보가 2번, CRM에서는 한번, 그리고 이메일 우편함에서는 한번 저장되는 이유를 이해하기가 어렵다. 여기에서의 문제는 단지 여분의 스토리지가 아니라 이것이 암시하는 모든 변칙들 - 업데이트가 2곳 모두에서 일어나게 하는 것, 삭제를 모순이 없게 하는 것, 및 2곳 모두에서 삽입을 보장하는 것, 기타 등등 - 이다. 이메일 어플리케이션 및 CRM 어플리케이션 둘다가 CDP 스토어(702) 상에 구축될 때 일어나는 일을 생각해보자. CDM을 사용하여, 연락처(Contact) 유형은 개체(Entity) 유형으로부터 도출될 수 있고, 그의 구조는 이메일 어플리케이션 및 CRM 어플리케이션 둘다에 투명하게 된다. 따라서, 2개의 어플리케이션이 유형에 대한 스키마에 동의하는 한, 개별적인 어플리케이션이 서로의 존재를 모른 상태에서 서로의 데이터를 사용할 수 있다. CDP가 공통 쿼리 모델을 제공하기 때문에, CRM 어플리케이션(예를 들어)은 연락처의 특정의 인스턴스가 그에 속하는지 여부에 상관없이 연락처 데이터를 얻기 위해 쿼리할 수 있다.

리치 모델링, 데이터 투명성 및 플랫폼-프레임워크 아키텍처의 조합은 많은 다수의 어플리케이션 및 프레임워크의 조합을 포함하는 공유/상호운용성 시나리오를 가능하게 해준다. 용어 '공유'는 어느 어플리케이션이 데이터를 저장하였는지 및/또는 어느 프레임워크가 그 데이터를 저장하는 데 이용되었는지에 상관없이 그 데이터가 CDP에 저장되어 있는 한 그 데이터를 이용할 수 있는 어플리케이션을 말할 수 있음을 잘 알 것이다.

상세하게는, 도 7은 다수의 어플리케이션이 데이터 - 이 경우에 이는 아이템(706)으로부터 도출된 일련의 UAF 유형임 - 를 공유하는 통상의 UAF 시나리오를 나타낸 것이다. CDP 및 스토어(792)는 UAF 프레임워크(704)에 관련된 UAF 유형 세트를 포함할 수 있다. 이 UAF 유형 세트는 아이템(706)으로부터 도출될 수 있으며, 여기서 이 세트는 이메일(708), 문서(710) 및 연락처(712)를 포함할 수 있다. 또한, 아이템(706)이 개체(714)로부터 도출될 수 있음을 잘 알 것이다. 이메일 어플리케이션(716), 리치 evite 클라이언트(718) 및 프로젝트(project) M(720)(이에 한정되는 것은 아님) 등의 복수의 어플리케이션이 CDP 및 UAF 프레임워크(704)와 관련하여 이용될 수 있다. 어플리케이션, CDP, UAF가 존재하는 계층에 관하여 어떤 제한에 없음을 잘 알 것이다. 예를 들어, 도 7의 어플리케이션 중 하나가 중간 계층에서 실행 및/또는 운영될 수 있다(예를 들어, 협업 어플리케이션).

도 8은 단일의 어플리케이션이 CDP 및 연관된 아키텍처에 따른 다수의 프레임워크를 이용하는 것을 나타낸 것이다. CDP 및 스토어(702)는 모든 어플리케이션에 의해 이용되는 오퍼레이팅 시스템에 대한 단일의 데이터 플랫폼을 제공할 수 있다. LOB 프레임워크(804) 상에 주로 작성될 수 있는 CRM 어플리케이션(802)은 UAF 프레임워크(808)와 연관된 연락처 데이터(806)를 이용할 수 있다. CRM 어플리케이션(802)이 일반적으로 주문 상세(814) 및 구매 주문(816)(이에 한정되는 것은 아님) 등의 그와 연관된 데이터를 이용한다는 것을 잘 알 것이다. CRM 어플리케이션(802)은 UAF 데이터(예를 들어, 연락처 데이터(802), 아이템(810), 개체(812), 기타 등등)를 이용할 때 CDP 레벨 추상화를 이용할 수 있다. 환언하면, CRM 어플리케이션(802)은 UAF 프레임워크(808) 메소드를 이용할 필요는 없다. 게다가, CRM 어플리케이션(802)이 어떤 계층에라도 존재할 수 있음을 잘 알 것이다.

도 9는 CDP가 복수의 개별적인 프레임워크와 연관된 다수의 어플리케이션과 데이터를 공유하는 것을 나타낸 것이다. 도 9는 CDP(902) 상에 3개의 프레임워크, 즉 UAF 프레임워크(904), 협업 프레임워크(908), 및 BF 프레임워크(910)를 나타내고 있다. 복수의 어플리케이션은 프레임워크 레벨 및 CDP 레벨 프로그래밍의 조합을 이용할 수 있다. 상세하게는, 연락처 관리 어플리케이션(912), 협업 어플리케이션(914), 및 CRM 어플리케이션(916)은 프레임워크 레벨 및 CDP 레벨 프로그래밍의 조합을 이용할 수 있다. CDP(902)는 스토어(928) 내의 데이터를 공유하기 위해 복수의 개별적인 프레임워크와 연관된 복수의 어플리케이션을 제공한다.

구체적으로는, 복수의 어플리케이션이 데이터와 상호작용하는 여러가지 방식 이 있다. 연락처 관리 어플리케이션(912)은 연락처(918)를 찾아 쿼리하기 위해 CQL을 이용할 수 있으며, 이 어플리케이션(912)은 아이템 레벨 이동, 복사, contact.GetBestAddress(), 기타 등등의 UAF(904) 메소드를 이용할 수 있다. 연락처 관리 어플리케이션(912)은 또한 StorageContext, StorageSearcher 등의 코어 CDP 런타임 클래스 및 CDP 데이터 클래스(예를 들어, 연락처 클래스 및 연관된 획득자(getter) 및 설정자(setter))를 이용할 수 있다.

협업 어플리케이션(914)은 연락처(918), 문서 라이브러리(922) 내의 임의의 문서, 및 아마도 심지어 주문(924)에 대한 쿼리를 하기 위해 CQL을 이용할 수 있다. 협업 어플리케이션(914)은 이러한 쿼리를 하기 위해 UAF(904) 및/또는 BF(910)의 존재를 알 필요가 없으며, 이는 다른 프레임워크들에 의해 작성된 임의의 특수한 코드를 이용하지 않고 순전히 CDP 레벨에서 행해질 수 있다. 이는 AddDocumentToDocLib(<document>, <docLib>), 기타 등등의 문서 라이브러리(922)를 처리하기 위해 협업 프레임워크(908)에 고유한 동작을 이용한다. 협업 어플리케이션(914)은 또한 StorageContext, StorageSearcher, Contact, Order, DocLibrary, 및 연관된 설정자(setter) 및 획득자(getter) 등의 CDP 레벨 클래스를 이용할 수 있다.

CRM 어플리케이션(916)은 주어진 연락처에 의해 모든 주문에 대한 쿼리를 하기 위해 CQL을 이용한다. 연락처가 UAF(904)를 이용하여 실제로 생성되었는지를 모르는 상황에서 CRM 어플리케이션(916)이 이 쿼리를 할 수 있음을 잘 알 것이다. CRM 어플리케이션은 BF(910)에 의해 제공된 메소드 및 서비스(예를 들어, FindShipStatus(<order>))를 이용하여 주문을 처리한다. 이는 또한 StorageContext, StorageSearcher, Contact, Order, 및 연관된 setter 및 getter 등의 CDP 레벨 클래스를 이용할 수 있다.

비-CDP 스토어와 공유할 때, CDP가 제공자 모델을 이용하지 않으며, 따라서 임의적인 데이터 소스가 CDP 스토어로서 등장할 수 있다는 것에 유의하는 것이 중요하다. CDP/프레임워크 어플리케이션이 비-CDP 스토어 내의 데이터를 처리하고자 하는 경우, 이는 2가지 옵션, 1) 동기 어댑터(Sync Adapter) 아키텍처(이는 UAF의 일부임)를 사용하여 이 데이터를 CDP 스토어에 동기시킴, 및 2) 비-CDP 스토어와 통합하기 위한 커스텀 로직을 작성함을 이용할 수 있다.

도 10은 CDP의 2-계층 배치를 나타낸 것이다. CDP를 구성하는 여러가지 컴포넌트가 어떤 의미에서 모바일이다. 어떤 제한을 두고서, 이들은 서로 다른 프로세스 및 기계 영역에 걸쳐 배치됨으로써 2-계층, 3-계층 및 N-계층 구성(단, N은 1보다 크거나 같은 정수임)이 얻어질 수 있다. 2-계층 배치가 도시되어 있지만, 본 발명이 그에 한정되지 않으며 임의의 수의 계층 구성이 이용될 수 있음을 잘 알 것이다.

상세하게는, CDP API(1002) 및 CDP 런타임(1004)은 둘다 어플리케이션(1006)과 연관된 어플리케이션 프로세스에 있을 수 있다. 따라서, CDP 컴포넌트(예를 들어, CDP 런타임(1004), API(1002), 및 제약/보안(1008))이 다양한 계층에 존재할 수 있다. 예를 들어, API(1002), CDP 런타임(1004) 및 어플리케이션(1006)은 클라이언트 계층(1010)에 존재할 수 있으며, 여기서 그 안에 있는 컴포넌트들은 그 자 신의 프로세스/기계 영역에 존재할 수 있다. 게다가, 스토어(1012) 및 제약/보안(1008)은 서버 계층(1014)에 존재할 수 있으며, 여기서 그 안에 있는 컴포넌트들은 그 자신의 프로세스/기계 영역에 존재할 수 있다. 제약/보안(1008)이 스토어 프로세스에서 호스팅될 수 있는 반면 나머지 CDP 컴포넌트들은 클라이언트 프로세스에 있을 수 있음을 잘 알 것이다. 이것은 CDP 컴포넌트들이 어떻게 모바일인 것으로 간주될 수 있는지의 주된 예이다.

도 11은 본 발명의 한 측면에 따른 공유 데이터를 갖는 2-계층 배치를 나타낸 것이다. 이하에 기술되는 제1 구성은 다수의 어플리케이션이 동일한 데이터를 공유할 때이다. 이것은 어플리케이션들이 데이터를 공유해야만 함을 말하는 것이 아니며, 오히려 임의의 어플리케이션의 데이터가 다른 어플리케이션들이 이용가능하다는 것을 말하는 것이다. 또한 유의할 점은 데이터의 이용가능성이 사용자의 관점에서가 아니라 어플리케이션의 관점에서이며, 따라서 이것은 사용자 증명서의 개념과 다르다. CDP 런타임의 제약/보안 모듈은 어플리케이션에 상관없이 이것을 처리할 수 있다.

어플리케이션은 API 및 CDP 런타임과 상호작용할 수 있으며, 여기서 각각의 어플리케이션, API, 및 CDP 런타임이 영역(1102), 영역(1104) 및 영역(1106)으로 나타낸 그 자신의 기계/프로세스 영역을 가질 수 있도록 각각의 개별적인 컴포넌트를 갖는 여러가지 어플리케이션이 존재할 수 있다. 간략함을 위해, 3개의 어플리케이션(예를 들어, 어플리케이션 1, 어플리케이션 2, 어플리케이션 3)이 도시되어 있지만, 임의의 수의 어플리케이션이 이용될 수 있음을 잘 알 것이다. 어플리케이 션은 그 자신의 프로세스/기계 영역(1112) 내의 스토어(1110) 내의 공유 데이터(1108)에 액세스할 수 있다. 제약/보안(1114)이 서로 다른 어플리케이션 간의 이러한 데이터 공유 동안에 시행된다는 것을 잘 알 것이다.

이 구성은 많은 사용자 시나리오에서 아주 중요하며, 예를 들어 이것은 지능적인 데이터 인식 어플리케이션을 작성하기 위해 ISV에 의해 이용될 수 있는 체계화된 사용자 데이터(schematized user data)의 데이터베이스 기반 파일 저장 비전에서의 토대이다. 프로젝트 M은 모든 사용자 데이터에 대한 만능 캔버스가 되려는 그의 비전을 달성하기 위해 이것에 의존할 수 있다. 이것은 CDP에 의해 지원되는 주된 구성이다.

도 12는 어플리케이션이 다른 어플리케이션이 보는 것 및/또는 이용하는 것을 바라지 않는 전용 데이터(private data)를 갖도록 되어 있는 제2 구성을 나타낸 것이다. 환언하면, 전용 데이터와 관련이 있는 2-계층 배치이다. 어플리케이션 전용 데이터(application private data)의 개념을 요구하는 많은 사용자 및 ISV 시나리오가 있다. 예를 들어, 어플리케이션이 그의 구성 데이터(예를 들어, ini 파일 등가물)를 데이터베이스 기반 파일 저장 시스템에 저장하기로 결정하는 경우, 이것이 그 어플리케이션에 대해 비밀(private)인 것이 바람직하다. 많은 경우, 부분적인 비밀성 - 읽기는 허용되지만 쓰기는 허용되지 않음 -이 요구된다. 예를 들어, 이메일 어플리케이션에서, 우편함을 디스플레이하지만 우편함을 수정하는 권한은 그 자신이 갖고 있는 것이 바람직하다.

2-계층 배치에서, CDP는 이 구성에 대해 제한된 지원을 한다. SQL 서버 스 토어에서 어플리케이션 레벨 보안에 대한 타당한 지원이 없으며, 그 결과 엄밀하게 말하면 데이터 액세스를 방지하는 의미에서 데이터가 주어진 어플리케이션에 비밀인 것으로 표시될 수 없다. 그렇지만, 이 상황은 이하의 방식으로 부분적으로 지원될 수 있다.

● 어플리케이션은 그 자신의 유형을 사용하고 그의 유형을 개별적인 네임스페이스에 넣으며 이들 유형으로부터 얻어지는 데이터 클래스에 대한 전용 어셈블리(private assembly)를 생성한다. 이 스키마에 속하는 인스턴스 데이터에 대한 모든 CDP 레벨 액세스가 이 어셈블리를 통하기 때문에, 다른 어플리케이션은 대응하는 클래스에 액세스하지 않게 된다.

● 어플리케이션은 다른 어플리케이션들에 게시되지 않은 이름을 갖는 그 자신의 전용 CDP 스토어(private CDP store)(예를 들어, StorageContext가 생성될 수 있는 CDP 내의 일련의 개체)를 생성한다.

● 설명서를 사용함.

어플리케이션이 전용 데이터(private data)를 갖기 위해 상기 방법들 중 일부 또는 그 전부를 선택할 수 있음을 잘 알 것이다.

유의할 점은 CDP 아키텍처가 단독으로 전용 데이터의 진정한 개념을 구현하는 것에 대한 장애물을 생성할 수 없다는 것이다. 따라서, 어플리케이션 레벨 보안이 하부의 플랫폼에서 이용가능하게 될 때 CDP가 이를 용이하게 노출시킬 수 있음은 생각가능하다. 또한, 유의할 점은 많은 경우에 가시성을 제한할 진정한 필요성 때문이 아니라 데이터에 대해 어플리케이션 관련 비지니스 로직을 시행할 필요 성 때문에 "전용 데이터 요건"이 발생된다는 것이다. 예를 들어, 이메일 어플리케이션에 의해 생성된 로컬 우편함은 일정 폴더(calendar folder)를 가지며, 규칙은 일정 아이템만이 이 폴더에 배치될 수 있다는 것이다. 이메일 어플리케이션은, 이 규칙이 시행되는 한, 다른 어플리케이션(다른 브랜드 이메일 어플리케이션 등)이 그의 우편함을 볼 수 있는지/수정할 수 있는지 여부에 신경쓰지 않는다. CDP 아키텍처는, 모든 어플리케이션이 CDP 계층을 통해 온 것인 한, 모든 비지니스 로직의 시행을 제공한다. 중간 계층이 이것을 시행할 수 있기 때문에 3-계층 배치에서 전용 어플리케이션 데이터가 지원된다는 것을 잘 알 것이다.

계속하여 도 12에서, API 및 CDP 런타임과 상호작용하는 어플리케이션을 갖는 기계/프로세스 영역(1202) 및 API 및 CDP 런타임과 상호작용하는 어플리케이션을 갖는 기계/프로세스 영역(1204)이 도시되어 있다. 간략함을 위해, 단지 2개의 어플리케이션이 도시되어 있지만, 임의의 수의 어플리케이션이 공유 데이터(1210)에 액세스 및/또는 그 자신의 기계/프로세스 영역(1208) 내의 스토어(1206) 내의 각자의 전용 데이터(예를 들어, 어플리케이션 1 전용 데이터(1210) 및 어플리케이션 2 전용 데이터(1212))에 액세스할 수 있음을 잘 알 것이다.

도 13은 다른 어플리케이션이 스토어에 직접 액세스하도록 되어 있는 관심의 제3 구성을 나타낸 것이다. 환언하면, 직접 스토어 액세스를 갖는 2-계층 배치가 있다. 기계/프로세스 영역(1302) 내의 어플리케이션 2는 아마도 예를 들어 ADO.NET을 통해 또는 다른 데이터 액세스 API를 통해 SQL 스토어(1306)에 직접 액세스할 수 있다. 예를 들어, 기존의 SQL 어플리케이션을 갖는 대규모 IT(정보 기 술) 점포가 그 어플리케이션을 제거하고 한꺼번에 CDP 기반 어플리케이션으로 이전할 가능성이 없다. 오히려, 조금씩 CDP로 마이그레이션하는 것이 구현될 수 있다. 제로-고장 시간(zero-downtime) 및 안정성이 생산 환경에서 중요한 문제이기 때문에, CDP 어플리케이션이 얼마동안은 SQL 어플리케이션과 함께 계속하여 나란히 실행될 수 있을 가능성이 있다. CDP가 유연성있고 비규범적인 O-R(객체-관계형) 매핑을 제공하기 때문에, CDP 어플리케이션은 기존의 스키마 상에 배치될 수 있다. CDP 아키텍처는 자연스럽게 직접 SQL 액세스를 가능하게 해준다. 이러한 이유는 "어플리케이션 1 데이터"가 단순히 일련의 테이블이고 어플리케이션 2가 적절한 퍼미션을 갖는 한 어플리케이션 2가 그 데이터에 직접 액세스하지 못하게 하는 일이 없기 때문이다.

어플리케이션 2에 대한 이하의 결과에 유의하기 바란다.

1) 어플리케이션 2는 CDP 서비스(또는 CDP 상부의 프레임워크에 의해 구축된 서비스)에 액세스하지 못할 수 있다.

2) 구체적으로는, 이는 CDM의 이점을 갖지 않으며, 따라서 테이블 표현을 이해해야만 하고 또 이 레벨에서 쿼리/업데이트를 직접 발행해야만 한다.

어플리케이션 1에 대한 이하의 결과에 유의하기 바란다.

1) BL 서비스(들) 내의 비지니스 로직은 어플리케이션 2에 의해 효과적으로 우회된다.

2) 어떤 제약(예를 들어 트리거/DRI(declarative referential integrity, 선언적 참조 무결성)로서 구현되지 않은 제약)도 역시 어플리케이션 2에 의해 우회된 다.

이 특정의 배치에서, 어플리케이션 2가 잘못되지 않게 제약, 기타 등등을 시행할 그 자신의 로직을 갖도록 보장하는 것은 어플리케이션 설계자 및/또는 배치 관리자의 책무이다.

도 14 및 도 15는 CDP 컴포넌트의 3-계층 배치 구성을 나타낸 것이다. 여러가지 CDP 컴포넌트가 3-계층 구성에 배치될 수 있다. 이 구성에서, CDP 런타임(1402)은 클라이언트 계층 및 중간 계층(도 15에 도시됨) 둘다에 존재한다. 어플리케이션은 클라이언트 계층 상에 있고, 스토어(1404)는 서버 계층(도 15에 도시됨) 상에 있다. 어플리케이션 로직은 도 14 및 도 15에서 두 요청자와 관련될 수 있으며, 제1 요청자는 클라이언트(1406)이다. 제2 요청자는 웹 서비스 프록시(1408), 웹 서비스(1410)(도 15에 도시됨), 및 비지니스 로직 호스팅(1412)(도 15에 도시됨)(예를 들어, 검증, 사전-저장 로직, 및 사후-저장 로직)이다. 클라이언트(1406)가 어플리케이션이고 따라서 그 안에 포함된 로직이 적법하게 "어플리케이션 로직"으로서 불릴 수 있지만, 이것은 참조되는 것이 아니다. 오히려, 웹 서비스 프록시(1408), 웹 서비스(1410) 및 비지니스 로직 호스팅(1412) 내에 포함된 로직이 참조된다. 이것은 ISV에 의해 작성되는 코드이며 중간 계층 상에 배치되는 것이고, 따라서 실제 의미에서, 이것은 중간 계층 "어플리케이션"이다. 어플리케이션 로직은 클라이언트 및 중간 계층 둘다에 존재할 수 있다. 어플리케이션 로직이 어디에서 실행되는지에 따라, 이하에서 살펴보는 몇 가지 가능한 시나리오가 있다.

시나리오를 살펴보기 전에, 다중-계층 배치의 주제가 어플리케이션 동작들이 계층들에 걸쳐 리모팅되는 방식과 밀접하게 관련되어 있음을 잘 알 것이다. 용어 '리모팅(remoting)'은 어플리케이션 레벨 또는 CDP-서비스 레벨 동작들을 계층들에 걸쳐 리모팅하는 이하의 3가지 일반적인 방법을 포괄할 수 있다.

1. 웹 서비스를 통한 어플리케이션 레벨 리모팅: 이 시나리오에서, 어플리케이션 로직은 중간 계층에 존재하고 리모팅된 정적 메소드(remoted static method)로서 클라이언트에 노출된다. 이것에 대해서는 이하에서 상세히 기술한다.

2. 암시적인 CDP-서비스 호출 리모팅(implicit CDP-service call remoting): FindAll(), FindOne(), SaveChanges() 등의 CDP API 호출이 리모팅 에이전트 및 리모팅 서비스 컴포넌트를 거쳐 중간 계층으로 암시적으로 전송된다. 이 아키텍처에 대해서는 이하에 기술된다. 게다가, 이후의 섹션들은 이것이 어떻게 동작하는지를 기술하는 예를 갖는다.

3. 명시적인 분리 리모팅(explicit, disconnected remoting): CDP API는 프로그래밍 패턴을 정의하고 이에 의해 어플리케이션은 계층-교차 동작이 언제 일어나야 하는지를 명시적으로 정의한다. 이 동작의 결과 데이터 검색이 일어난 경우, 검색된 데이터는 클라이언트 계층 상에 저장된다. 이 패턴은 보통 "분리 모드(disconnected mode)"(이하에서 기술함)라고 한다.

상세하게는, 도 14 및 도 15는 어플리케이션 로직이 다중-계층(예를 들어, 웹 서비스)에서 실행되는 것을 나타낸 것이다. 중간-계층 배치에 대한 주된 시나리오는 어플리케이션 로직이 전적으로 중간 계층에서만 실행되는 경우로서, 클라이언트(1406)는 웹 서비스 메커니즘(예를 들어, 웹 서비스 프록시(1408) 및 웹 서비 스(1410))을 통해 이 로직을 호출한다. 서버 계층 상의 보안 엔진이 중간 계층 CDP 프로세스에서 호스팅될 수 있음을 잘 알 것이다. 2-계층 배치에서, CDP 호출은 클라이언트 프로세스 내의 CDP 런타임(1402)에 의해 처리되고, 이 런타임은 필요한 경우 서버에 접촉한다. 3-계층 배치에서, 어떤 CDP 호출은 로컬적으로(클라이언트 계층을 통해) 처리되고, 어떤 것은 원격적으로(중간 계층을 통해) 처리된다. 게다가, 또다른 것들은 두 곳 모두에서 처리될 수 있다. 3-계층 배치는 적절한 호출을 리모팅하는 방법을 정의한다.

클라이언트 계층 상의 리모팅 에이전트(1414)는 요청들을 패키지화하여 중간 계층 상의 CDP로 전송하기 위해 채널(예를 들어, 인디고(Indigo))을 사용할 수 있는 컴포넌트이다(이것이 원격 프로시저 호출의 실제 동작이다). 중간 계층 상에는 이들 요청들에 대해 적절하게는 충분히 서비스하는 리모팅 서비스(1416)(도 15에 도시됨)가 있다. 이 패턴은 통상적으로 SOA(Service Oriented Architecture, 서비스 지향 아키텍처)라고 알려져 있는 것의 일부이다. SOA의 특성은 서로 다른 계층들이 메시지를 교환함으로써 서로 통신한다는 것이다. CDP는 이를 위해 인디고 기반구조를 이용할 수 있다.

리모팅 서비스는 "쿼리를 실행", "삽입", "삭제", "업데이트", "생성", "저장", "키가 주어지면 객체를 가져옴", "루트 키를 가져옴" 등의 일련의 데이터 지향 서비스(data oriented service)를 제공한다. SOA 패러다임에 따라서, 이들 동작은 SOAP 메시지 내의 동사(verb)일 수 있다. 클라이언트 계층이 중간 계층에서 실행시키고자 하는 어떤 동작이라도 이들 간단한 동사로서 표현된다. 이들 기본적 인 메시징 동사는 인디고에 의해 제공된 도구를 사용하여 2개의 인터페이스에 대한 메소드로 추상화되며, 실제 이들은 전술한 바 있는 IPersist 및 IQuery 인터페이스이다. 따라서, 리모팅 에이전트(1414) 및 리모팅 서비스(1416)는 모두 IPersist 및 IQuery 인터페이스의 메소드를 리모팅하기 위한 인디고 채널 상의 종단점으로서 기능한다. IQuery 및 IPersist 내의 메소드들이 이하의 의미에서 "입도가 거칠다(coarse-grained)"는 것을 잘 알 것이다. 즉, 이들 메소드는 큰 객체 세트에 대해 쿼리를 하거나 그를 처리하는 데 사용될 수 있다. 예를 들어, SaveChanges () 메소드에 응답하여, 리모팅 에이전트(1414)는 전체 객체 세트가 더티(dirty) 상태인 리모팅 서비스(1416)에 대해 IPersist.Write()를 한번 발행한다. 따라서, 클라이언트와 중간 계층 간의 인터페이스는 벌크 지향(bulk-oriented)이며 채티(chatty)가 아니다.

메소드 호출에 응답하여, 도 14 및 도 15에 도시된 여러가지 모듈에 걸친 데이터/제어 흐름을 검사하기 위한 이하의 의사 코드 예가 예시되어 있다. 이하의 것은 단지 예로서 본 발명의 아키텍처가 그에 한정되는 것이 아님을 잘 알 것이다.

이 예에서, 어플리케이션은 회사 인트라넷을 통해 Anil Nori에 대한 공유 일정을 쿼리하여 xxxx년 10월 29일 오전 9시에 대한 그의 일정 엔트리를 가져온다. 이것은 ScheduleEntry 객체에 의해 표현되어 있으며, 이는 Entity로부터 파생된 유형이다(예를 들어, ScheduleEntry는 PIM 스키마의 일부로서 사용자의 스케쥴 내의 아이템을 나타낸다). 이는 ScheduleEntry를 수정한다, 즉 텍스트 "[important, please come!]"을 약속의 제목에 첨부한다. 이는 이어서 웹 서비스(ScheduleService라고 함)를 통해 CreateAppointment 메소드를 호출하여 이 수정된 ScheduleEntry를 Pedro Celis의 공유 일정에 넣는다. 이 코드 단편은 3-계층 배치에서의 몇 가지 주요 사항을 나타낸 것이다.

1. 클라이언트는 로컬 CDP 런타임을 사용하여 스토어 개체에 대한 쿼리를 행한다. 이 쿼리는 중간-계층 상에서 실행된다.

2. 이 쿼리 결과는 클라이언트 계층 CDP의 세션 캐시에 있다.

전체 "어플리케이션 로직" - 비지니스 로직, 검증, 기타 등등을 포함함 -은 웹 서비스에 의해 또 CDP의 BL 호스팅 엔진에 의해 중간 계층 상에서 실행된다. 이 프로세싱은 CreateAppointment() 메소드의 호출에 의해 트리거된다. 이하의 것은 여러가지 모듈 간의/에 걸친 데이터 흐름의 상세한 검사이다.

라인 1: 스토리지 컨텍스트를 생성함. StorageContext 객체(예를 들어, 클라이언트 계층 상의 API(1418))는 어플리케이션 및/또는 클라이언트(1406)에 의해 생성되는 Data 객체에 의해 캡슐화된다. Data 클래스는 CDM 스키마에 기술된 테이블 세트 유형을 나타낸다. Data 객체는 필요에 따라 스토어(1404)와 상호작용하도록 구성된 StorageContext 객체를 생성한다. StorageContext의 초기화 코드는 클라이언트 계층 상의 CDP 런타임(1402)의 일부이다.

라인 2: 쿼리. 라인 2의 표현식의 RHS는 OPath 쿼리이다. 이 쿼리는 최대 하나의 ScheduleEntity 객체 - 10/29/04, 9AM의 첫번째 엔트리(예를 들어, "첫번째 엔트리"의 정확한 정의가 존재하는 것으로 가정함) - 를 반환한다. 클라이언트 계층 상의 CDP 런타임(1402)은 리모팅 에이전트(1414)를 통해 IQuery 인터페이스를 가져오며 그에 대해 ExecuteQuery(<Opath>)를 호출한다. 리모팅 에이전트(1414)는 인디고 채널을 이용할 수 있고 이 쿼리를 중간 계층 상의 리모팅 서비스(1416)로 전송한다. 이 쿼리는 2-계층 경우에서와 같이 매핑되고 실행되며, 그 결과는 클라이언트 계층으로 반환된다. 여기에서 2가지 가능성이 있다.

1. 객체를 하이드레이트하지 않고 원래의 TDS 결과가 중간 계층으로부터 클라이언트 계층으로 반환된다. 클라이언트 계층 상의 CDP 런타임(1402)은 이어서 이 객체들을 하이드레이트한다.

2. 이들 객체가 객체 캐시(414)에 이미 존재하는 경우, 하이드레이트된 객체가 클라이언트 계층으로 반환된다.

전체 OPath 쿼리가 인디고 채널을 거쳐 전송된다는 것을 잘 알 것이다. 예를 들어, 쿼리가 "유형 ScheduleEntry의 모든 객체를 탐색"(즉, FindAll() 메소드 호출)인 경우, 이 전체 쿼리는 (객체당 하나의 메시지가 아니라) 하나의 SOAP 메시지로 (중간 계층 상의 리모팅 서비스(1416)로) 전송된다.

라인 3: 클라이언트 계층 객체 캐시를 처리. ScheduleEntry 객체가 클라이언트 계층으로 반환되면, 이는 클라이언트 계층 상의 CDP 런타임(1402)의 세션 캐시 내에서의 추가의 처리를 위해 이용가능하다. 클라이언트(1406)가 ScheduleEntry 객체의 DisplayName 속성을 변경할 때, 이것은 전적으로 클라이언트 계층 상의 CDP 런타임(1402)에 의해 처리된다.

라인 4: 클라이언트 계층 상에 웹 서비스 프록시를 새로 생성(new-ing)함. 아마도, 클라이언트(1406)는 설계 동안에 이미 적절한 asmx(또는 인디고 등가물)에 참조를 부가하였다. 라인 4는 클라이언트 상에 웹 서비스 프록시 객체의 인스턴스를 생성할 수 있다. 이 호출은 전적으로 웹 서비스 프록시(1408)에 의해 서비스된다.

라인 5: 웹 서비스 메소드를 호출함. CreateAppointment()는 중간 계층 상의 웹 서비스(1410)에 의해 리모팅되는 메소드들 중 하나이다. 이 메소드는 ScheduleEntry 객체 및 CDP 연결 문자열을 취하고, 이는 이 정보를 사용하여 연결 문자열에 의해 정의된 StorageContext 내에 ScheduleEntry 객체를 생성한다. 적절한 비지니스 로직 및 검증 로직의 실행은 이 쓰기 동작 내에 내재되어 있다. 이 메소드는 웹 서비스 프록시(1408)에 의해 패키지화되고 SOAP 메시지를 통해 인디고 채널을 거쳐 중간 계층 상의 웹 서비스(1410)로 전송된다. 웹 서비스(1410)는 임의의 다른 어플리케이션이 있는 것처럼 중간 계층 상의 CDP API(1420)의 호출을 통해 이 메소드를 구현한다. 여기서 주목할 요점은 CreateAppointment()에 대한 전체 로직이 중간 계층 상에서 실행된다는 것이다.

도 16 및 도 17은 어플리케이션 로직이 클라이언트 계층 및 중간 계층 둘다에서 실행되는 것을 나타낸 것이다. 메소드 호출에 응답하여 서로 다른 컴포넌트 및 계층을 통한 데이터/제어 흐름은 예를 이용하여 보다 상세히 기술될 수 있다. 이하의 예는 전술한 예와 유사하다.

이전의 예들로부터 알 수 있는 바와 같이, 라인 3은 스토리지 컨텍스트를 생성하며, 라인 5 및 라인 9는 쿼리에 관한 것이고, 라인 12는 업데이트에 관한 것이다.

라인 13: 변동을 플러쉬함. 이하의 2가지 가능성을 살펴보자.

1. BL은 클라이언트 계층에서도 중간 계층에서도 실행된다. 이 경우, 클라이언트 계층 상의 비지니스 로직 호스트(416)는 검증 및 사전-저장 로직을 실행하고 IPersist.Write(<change vector>)로 클라이언트 계층 상의 리모팅 에이전트(1414)를 호출한다. 리모팅 에이전트(1414)는 이 호출을 중간 계층 상의 리모팅 서비스(1416)(도 17에 도시됨)로 전송한다. 리모팅 서비스(1416)는 중간 계층 상의 객체 캐시(414)를 더티(dirty) 상태로 만들고, SaveChanges()를 호출한다. 이것은 전술한 바와 같이 BL 및 영구 보존 단계를 실행하고 리모팅 서비스(1416)로 되돌아가며, 여기서 리모팅 서비스(1416)는 이어서 클라이언트 계층 상의 리모팅 에이전트(1414)로 되돌아가고, 이어서 다시 비지니스 로직 호스팅(416)으로 되돌아간다. 클라이언트측 사후-저장 로직은 비지니스 로직 호스팅(416)에 의해 실행될 수 없다.

2. BL은 중간 계층 상에서만 실행된다. 이 경우, 비지니스 로직 호스팅(416)은 즉각 이 호출을 리모팅 에이전트(1414)로 전달하고, 이어서 리모팅 에이전트(1414)는 이를 리모팅 서비스(1416)로 전송한다. 프로세싱은 전술한 바와 같이 중간 계층 상에서 일어난다.

양 계층 상에서 BL을 실행하는 것의 이점은 사전-저장 로직의 검증에서의 에 러의 경우, 이들 에러는 중간 계층으로 연결하는 비용을 들일 필요없이 클라이언트 계층 상에서 트랩될 수 있다는 것이다.

매끄러운 오프라인 경험은 데이터베이스 기반 파일 저장 시스템의 목표 중 하나이다. 이것은 데이터를 원격 스토어와 동기화시키는 로컬 스토어(1602)를 필요로 할 수 있다. 로컬 스토어(1602)는 제약/보안(1604)을 더 포함할 수 있다. 이 경우, 로컬 스토어(1602)는 거의 유사한 기계 상에 있지만, 서로 다른 프로세스에 있다(이는 우리의 정의에 따르면 여전히 2-계층 배치임). 3-계층 및 2-계층 배치에 대한 프로그래밍 모델이 대칭이기 때문에, 동기화 등의 서비스가 로컬 스토어(1602)와 중간 계층 사이에서 동작하고 이 데이터가 동기를 유지하도록 하는 것이 용이하다.

상기한 코드 예의 라인 2를 살펴보자. 쿼리의 결과 계층-교차 동작이 일어난다. 이 특정의 예에서, 하나의 객체(ScheduleEntry 객체)가 반환되었다. 그렇지만, 일반적으로 이것은 잠재적으로 아주 큰 결과 세트를 반환할 수 있다. 유사한 설명이 이전에 제공된 코드 예의 라인 5에도 적용된다. 3-계층 배치에서 관계가 있는 고려될 수 있는 2가지 문제가 있다.

● 계층 교차는 잠재적으로 고비용이고 따라서 암시적으로 일어나지 않을 수 있다. 라인 2에 이것이 계층 교차 동작을 일으킬 것이라는 명시적인 표시가 없다 - 환언하면, "마법"이 관여된다. "마법"은 여기서 어플리케이션이 그에 관해 모르거나 그의 발생을 제어할 능력이 없는 상황에서 무언가가 일어난다는 의미에서 사용된다. 많은 경우에, 마법은 양호하지만, 실제 많은 소프트웨어의 목표는 하부의 복잡도를 감추고 또 일들이 "마법에 의한 것처럼" 행해지도록 하는 것이다. 그렇지만, 이 특정의 경우에, 오랜 경험으로 볼 때, 어플리케이션 작성자는 하부의 코드가 네트워크를 질식시키지 않고 또 서버에 압박을 가하지 않고 어떻게든 많은 데이터를 반환한다고 가정하여 싫든 좋든 엄청난 쿼리를 전송한다. 임의의 계층 교차 마법이 어플리케이션에 명시적으로 행해지고 그에 따라 신중한 코딩 실무를 장려하는 것이 입증된 설계 패러다임이다( "select * needed from <million-row-table>" 또는 아마도 WHERE 절이 이용될 수 있다).

● 클라이언트측 캐싱 및 상태 비저장 동작(stateless operation): 신중한 코딩의 시도에도 불구하고, 어플리케이션이 (잠재적으로 큰) 데이터 세트를 처리해야 하는 때가 있으며, 이 데이터 세트가 무엇인지를 어플리케이션이 알고 있는 경우가 많다. 이러한 경우에 데이터 액세스를 최적화하기 위해, 어플리케이션은 쿼리를 실행하고 (잠재적으로 큰) 데이터 세트를 페치하며 이를 로컬적으로 캐시에 보관할 능력을 가져야만 한다. 그 데이터의 로컬 복사본에 대해 추가의 쿼리/정렬/필터링/변경이 행해진다. 마지막으로, 플러쉬 동작은 이 변동을 다시 스토어에 기록한다. 로컬 캐시에 대해 동작한다는 것은 중간-계층이 아주 최소한의 상태를 유지하며(또는 상태를 전혀 유지하지 않으며), 그에 따라 이를 보다 확장성있게 만든다는 것을 의미한다.

해결책은 명시적인 분리 모델(explicit disconnected model)을 제공하는 것이다. 이것은 이하의 패턴을 특징으로 한다.

1. 어플리케이션은 이하의 방식으로 로컬 캐시를 인스턴스화한다.

2. 로컬 캐시는 하나 이상의 쿼리의 결과를 포함하게 되며, 이하와 같이 지정된다.

// 기타

3. 어플리케이션은 로컬 컨텍스트를 "채운다"

4. 어플리케이션은 임의의 스토리지 컨텍스트에서와 같이 로컬 컨텍스트에 동작한다. 예를 들어,

5. 마지막으로, 어플리케이션은 변동들을 한번에 스토어로 전송하고, 이하와 같이 지정된다.

//sc는 StorageContext이다

순진한 코드에 의해 어떤 마법도 트리거되지 않도록 어플리케이션이 계층 교차 동작 - 단계 3에서의 lc.Fill() - 이 일어나기를 원할 때 어플리케이션이 어떻게 명시적으로 될 수 있는지에 주목한다. 또한, 모든 후속 동작들이 로컬 캐시 상에서 일어날 수 있고 따라서 계층 교차가 최소화된다(이와 함께 중간-계층 상에 상태를 유지하는 일이 수반됨)는 것에 주목한다. 상기 코드 단편에 의해 암시되는 모델이 ADO.NET에서의 데이터세트 모델과 아주 유사함을 잘 알 것이다. CDP는 또한 분리 모델도 제공할 수 있다.

이하의 경우, 즉 (a) 2-계층 어플리케이션이 분리 프로그래밍 모델만을 사용하는 경우 또는 (b) 2-계층 어플리케이션이 분리 프로그래밍 모델을 사용하기 위해 재작성된 경우 중 하나가 참이 아닌 한, 2-계층 어플리케이션이 3-계층 환경에 배치되어서는 안 된다.

CDP는 3-계층 배치에서 연결 및 분리 프로그래밍 모델 둘다를 가능하게 해주는 방법을 취한다. 어플리케이션은 "3-계층 환경에 배치되기를 기대하는 경우, 분리 캐시를 사용해야만 한다"는 가이드라인을 제공받는다.

CDP 스토어에 대해 기술하는 이하의 섹션에 대한 컨텍스트를 설정하기 위해, 유의할 점은 모든 SQL 서버 데이터의 공간이 이하의 4-레벨 계층구조, 즉 인스턴스, 데이터베이스, 스키마 및 테이블로 분할된다는 것이다. 연결가능 유닛(connectable unit)은 인스턴스이고, 데이터베이스는 백업(backup), 복원(restore), 및 복제(replication)가 정의되는 컨테이너(container)이다. 데이터베이스와 스키마의 조합은 쿼리를 위한 컨텍스트를 제공한다. CDP는 3-레벨 계층구 조, 즉 스토어, 스키마 및 유형을 사용한다. CDP 스토어는 연결가능 유닛이고, 스키마는 쿼리를 위한 컨텍스트를 제공한다. 주어진 스키마는 다수의 CDP 스토어에 의해 호스팅될 수 있다(예를 들어, 일련의 유형(CRM 스키마)이 CDP의 2개의 서로 다른 인스턴스 상에 배치될 수 있다). "동일성"이 요망되는 경우, CDP 외부의 메커니즘(복제, 벌크-복사)이 사용되어야만 한다. 주어진 CDP 스토어는 그 위에 배치된 다수의 스키마 - HR 스키마, 회계 스키마, 기타 등등 - 를 가질 수 있다.

여기에서 네이밍 및 발견에 대해 기술한다. 전술한 이하의 코드의 라인 3을 살펴보자.

이하에서는 CDP 스토어의 네이밍 및 이용가능한 스토어의 발견에 대해 기술한다. CDP 스토어가 보다 명백하게 정의된다. 2가지 가능성이 있다.

1. 이는 실제의 물리적 스토어 - 실제 서버 상의 데이터베이스 - 이다.

2. 이는 논리적 스토어 - ctor에 대한 인수가 개체 인스턴스의 논리적 컨테이너를 식별함 - 이다. 실제로, 이것은 복제된 물리적 스토어의 팜(farm)으로서 배치될 수 있으며, 프론트 엔드 서버는 이 특정의 세션에 대한 컨텍스트를 형성하는 실제의 물리적 스토어를 택하기 위해 부하 분산기(load balancer)와 함께 동작한다. CDP 모델에서, 스토리지 컨텍스트는 물리적 스토어가 아니라 논리적 스토어를 식별한다. CDP는 복제, 백업/복원 메커니즘이 물리적 스토어의 레벨에서 어떻게 동작하는지를 지정하지 않는다.

ctor 인수의 포맷과 관련하여, 연결 문자열은 URI(Uniform Resource Identifier)이다. 개개의 프레임워크는 그의 어플리케이션에 의해 사용하기 위한 대안의 네이밍 포맷을 정의할 수 있다. 예를 들어, UAF는 그의 어플리케이션이 UNC 이름(예를 들어, ＼＼server＼＼share)을 지정함으로써 스토리지 컨텍스트를 설정하도록 선택할 수 있다. 그렇지만, URI에 의해 CDP 스토어에 연결하는 것이 항상 가능해야만 한다. 환언하면, 프레임워크에 의해 사용되는 임의의 대안적인 이름이 대응하는 CDP 레벨 URI로의 잘 정의된 매핑을 가져야만 한다.

CDP는 스토어가 어떻게 발견될 수 있는지를 지정하지 않는다. 이를 위해, 어플리케이션이 기존의 메커니즘 및 보관소(예를 들어, UDDI)를 사용할 수 있을 것으로 예상된다. 게다가, 프레임워크는 발견을 위해 그 자신의 메소드를 지정할 수 있다.

이 섹션에서, 어플리케이션이 이용할 수 있는 부가의 CDP 서비스에 대해 기술한다. 이들 서비스로는 다음과 같은 것이 있다.

● 감시자/통지(Watcher/Notification) 서비스

● 동기화 서비스

● 명시적 캐시 서비스

● 유틸리티 동작

이 섹션은 구조적이 아니라 설명적인 것으로 보아야 한다.

감시자/통지 서비스. 통지(별칭: 감시자)는 하부의 스토어에 영구 보존된 개체(데이터)에 대한 변동의 비동기적 통지를 발생하는 기능을 제공한다. 어플리 케이션(또는 임의의 다른 컴포넌트)은 이 서비스를 사용하여 영구 보존된 개체에서의 변동을 감시한다. 어플리케이션은 그가 감시하는 것 및 얼마나 자주 통지받기를 원하는지에 대해 완벽하게 제어한다. 예를 들어, RAV(Rich Application View) 통지는 감시자를 사용하여 구축되고, 클라이언트측 브라우징 어플리케이션은 이들 통지를 사용하여 데이터 변동에 적극적으로 대응하기 위해 RAV를 사용할 수 있다.

CDP 프로그래밍 모델은 개체에서의 변동을 감시할 수 있는 Watcher 클래스를 지원한다. 프레임워크 및 어플리케이션이 상위 레벨 감시자 추상화를 구축하는 데 개체 감시자 메커니즘이면 충분하다. 예를 들어, 데이터베이스 기반 파일 저장 시스템은 개체 감시자 추상화 상에 아이템, 아이템 확장, 및 링크(Link) 감시자 추상화를 구축할 수 있다(예를 들어, 개체가 감시될 수 있는 가장 세분화된 데이터(most granular piece of data)임에 유의할 것).

동기화 서비스. CDP에 기록된 어플리케이션은 물론 그 상부의 프레임워크는 이하의 동기화 관련 서비스로부터 도움을 받는다.

1) 변동 추적을 위한 스키마 주석. 스키마 설계자는 그의 개체 유형에 대한 변동 단위 경계를 지정할 수 있다. 변동 단위 명세는 변동 추적 서비스의 기능을 제어한다.

2) 변동 추적. 대체로 어플리케이션에는 보이지 않으며, 이는 모든 CDP 동작 동안에 변동 단위에 대한 버전들은 물론 개체 삭제 등의 중요한 동작의 로그를 유지한다. 변동 추적은 레거시 어플리케이션이 계속하여 변동을 하여 CDP 런타임을 우회하는 경우에도 정확하게 기능한다.

3) 변동 열거. CDP 어플리케이션이 일련의 개체 및 어떤 워터마크 이후에 수정된 그의 변동 단위를 검색할 수 있게 해준다. 변동은 CDP 개체 및 RowSet로서 반환된다. 고장, 백업, 및 복원에 직면하여 워터마크 유지 및 복잡한 동기화 위상을 위한 일련의 서비스가 제공된다.

4) 충돌 검출. CDP 동작(업데이트 등)이 이미 수행된 동작과 충돌하게 될지를 CDP 어플리케이션이 판정할 수 있게 해준다(다시 말하면, 워터마크에 기초함). 이 코어 기능을 사용하여, 프레임워크는 부가의 상위 레벨 동기화 서비스를 구축할 수 있다.

명시적 캐시 서비스. CDP 내의 명시적 캐시 서비스는 어플리케이션의 개선된 성능/확장성, 분리 프로그래밍 모델에 대한 지원(예를 들어, 분리 프로그래밍 모델이 전기능을 갖춘 명시적 캐시의 도움 없이 구현될 수 있음에 유의할 것), 및 임시 데이터에 대한 지원을 제공한다. 이하의 것은 명시적 캐시에서의 특징이 될 수 있다.

● 서로 다른 유형의 데이터(예를 들어, 개체, 비구조화된 및 XML 데이터)를 캐싱함

● 서로 다른 캐시 액세스 모드(예를 들어, 읽기 전용, 읽기 쓰기, 공유, 기타 등등)

● 저장된 데이터와의(예를 들어, SQL 서버에 저장된 데이터에 대한) 캐시 일관성

● 어플리케이션 장애극복을 위한 다수의 CDP 캐시에 걸친 캐시(어떤 유형의 데이터, 예를 들어 세션 컨텍스트 데이터) 일관성

명시적 캐시에 대한 프로그래밍 표면은 이하의 것을 노출시킬 수 있다.

● 캐시의 생성

● 캐시의 채움

● (데이터의 일부의) 캐시를 하부의 스토어에 영구 보존함

● 캐싱된 데이터에 대한 쿼리 및 업데이트

유틸리티 동작. CDP는 개체 및 개체의 컬렉션에 대한 각종의 관리 및 유틸리티 동작에 대한 지원을 제공한다. 이러한 동작의 예로는 복사, 이동, 직렬화/역직렬화, 및 백업/복원이 있다.

이제 도 18을 참조하면, 개체를 이용하는 아이템의 모델링이 나타내어져 있다. 데이터베이스 기반 파일 저장 시스템(예를 들어, WinFS) 구현은 CDP 및 UAF(User Application Framework) 둘다의 측면을 포괄한다. 유의할 점은 CDP 아키텍처가 데이터베이스 기반 파일 저장 시스템의 재작성(re-write)이 아니라 그 안의 컴포넌트의 재세그먼트화(re-segmentation)를 의미한다는 것이다.

이 섹션에서, UAF가 정의되고 이어서 데이터베이스 기반 파일 저장 시스템의 여러가지 컴포넌트가 어떻게 UAF 및 CDP로 세그먼트화될 수 있는지에 관하여 검사된다.

UAF는 "사용자" 데이터를 모델링하는 것과 관련된 CDP 프레임워크이다. 사용자 데이터는 문서, 사진, 음악, 연락처, 기타 등등의 일반적인 최종 사용자에 관련된 통상의 일상 데이터를 말한다.

기본적인 CDP 기반구조에, UAF는 이하의 것을 부가한다.

● 기본 아이템 유형(및 관련된 유형)

● 사용자 데이터를 모델링하기 위한 실제 유형

● 수명 관리, 포함, 기타 등등의 제약

● 사용자가 아이템을 가지고 할 수 있는 일: 이동, 복사, 이름변경, 직렬화,...

● 아이템에 대한 구성상의 제약: 컨테이너, 목록, 자동 목록(autolist), 주석, 카테고리

● 아이템에 대한 최종 사용자 프로그래밍 추상화(규칙 작성 등)

어플리케이션 개발자의 경우, CDP가 UAF 프로그래밍 모델임을 잘 알 것이다.

구체적으로는, 도 18은 UAF에서의 아이템의 개념 및 이것이 실제로 몇개의 개체로부터 어떻게 도출되는지에 대해 나타낸 것이다. 문서 아이템(1802)은 문서(1804), 복수의 링크(1806) 및 문서 확장(1808)(이에 한정되는 것은 아님) 등의 몇 가지 개체로부터 도출될 수 있다. 저작자 아이템(1810)은 저작자(1812) 및 저작자 확장(1814) 등의 몇 가지 개체로부터 도출될 수 있다.

도 19를 참조하면, CDP 상부에 UAF를 구현함으로써 여러가지 기능을 구현하는 확장가능 메커니즘이 도시되어 있다. UAF가 CDP 상부에 구축되기 때문에, 이는 부가의 기능을 구현하기 위해 CDP 확장성 메커니즘을 이용할 수 있다. CDP 상부에 UAF를 구축하는 것은 여러가지 계층 및/또는 컴포넌트를 포함할 수 있다. 스토어(1902)는 CDP 제약 엔진(1904)을 포함할 수 있으며, 여기서 CDP 제약 엔진(1904)은 적어도 하나의 UAF 제약(1906)을 포함한다. CDP 런타임(1908)은 UAF 아이템 거동(1910)을 포함할 수 있는 BL 호스트(1912)를 포함할 수 있다. UAF 아이템 거동(1910)은 UAF 바인딩가능 거동(1914)을 더 포함할 수 있다. CDP 런타임(1908)의 상부에, 임의의 다른 UAF 서비스(1916)가 존재할 수 있다.

UAF는 CDP의 제약 엔진을 사용하여 아이템 의미론(및 다른 유형 시맨틱)을 시행한다. 이들은 CSDL을 사용하여 작성되며, 스키마 생성기는 이들에 대한 스토어 레벨 제약을 생성한다. 이동, 직렬화, 기타 등등의 아이템 거동은 CDP의 BL 메커니즘을 사용하여 구현된다. UAF 유형은 그와 연관된 바인딩가능 거동을 가질 수 있다. 이들 거동은 유형들이 지정되고 배치된 후에 UAF 어플리케이션 개발자에 의해 작성된다. 동기, 메타데이터 처리, 기타 등등의 다른 UAF 서비스는 정규의 CDP 코드로서 구현된다. 모두 합하여, CDP의 여러가지 계층에서 실행되는 이들 개별적인 로직이 UAF를 형성한다.

이하의 설명은 CDP와 UAF 간에 데이터베이스 기반 파일 저장 시스템을 분할하는 것에 적용가능하다. 데이터베이스 기반 파일 저장 시스템에서의 이하의 기능은 CDP 계층에 속한다.

1. O-R 매핑 - 개체의 테이블로의 매핑. CDP는 POCO 시나리오 및 데이터베이스 기반 파일 저장 시스템 서버 시나리오를 처리하기 위해 비규범적 매핑을 지원한다. 이것은 또한 업데이트 매핑을 제공하여 개체(및 파생된) 유형에 대한 기본적인 CUD 동작을 제공한다.

2. OPath 쿼리 매핑

3. Entity 및 다른 CDM 코어 유형의 구현

4. 세션 및 트랜잭션 관리와 함께 StorageContext 및 StorageSearcher

5. 세션 캐시, 캐시 플러쉬 로직(SaveChanges)

6. 변동 추적

7.개체 유형에 관한 감시자

8. RAV를 비롯한 커서 서비스

9. 아이템 레벨 보안 시행 메커니즘(행 레벨 보안, 보안 서술자는 유형 뷰에 포함된다)

데이터베이스 기반 파일 저장 시스템에서의 이하의 기능은 UAF 계층에 속한다.

1. 바인딩가능 인스턴스별 거동(bindable, per-instance behavior)

2. 데이터베이스 기반 파일 저장 시스템 API 메타데이터(CLR 메타데이터로서 표현된 클라이언트 클래스 및 거동)

3. 아이템 레벨 메소드(복사, 이동, 직렬화, 이름변경)

4. 동기, 동기 스코프, 변동 열거

5. 컨테이너에 관한 감시자

6. 효율적인 경로 이름 계산 및 아이템 도메인에 대한 경로 테이블

7. 메타데이터 핸들러

8. 데이터베이스 기반 파일 저장 시스템 네임스페이스

9. 아이템 무결성(컨테이너, 아이템 부분, 링크, 파일 스트림, 수명 관리, 기타 등등)을 시행하는 코드

도 20은 LOB 어플리케이션이 CDP 상에 구현되어 있는 예를 나타낸 것이다. 이하에서는, LOB 프레임워크 요건 및 어떻게 이들이 CDP에 의해 지원될 수 있는지에 대해 기술한다. 비지니스 프레임워크 어플리케이션은 LOB 어플리케이션인 것으로 간주될 수 있다. 비지니스 어플리케이션에 대한 코어 특징 세트는 공유 비지니스 컴포넌트로서 패키지화되어 있다. 이들 컴포넌트의 그룹은 일반 재무 회계(general ledger in financials) 내지 CRM에서의 영업 자동화(sales force automation) 서비스 등의 여러가지 비지니스 기능을 관리한다. 주요 특징은 이들 컴포넌트가 정체불명이고(faceless) 확장성이 있으며, 어느 레벨의 기능 및 복잡도가 이용되는지에 따라 여러 마켓의 요구에 서비스하기 위해 이용될 수 있다.

비지니스 프레임워크(BF)는 비지니스 솔루션 프레임워크 및 비지니스 어플리케이션 프레임워크로 이루어질 수 있다. 비지니스 솔루션 프레임워크는 대부분의 비지니스 어플리케이션을 구축하는 데 유용한 기능을 제공한다. 이것은 Money 및 Quantity 등의 기본적인 비지니스 데이터 유형, 고객, 비지니스 단위, 다중-통화 정보 및 지불 조건 등의 어플리케이션 패밀리 전체의 비지니스 개체, 비지니스 트랜잭션 및 계정 등의 공통 비지니스 패턴을 구현하는 구성 블록, 및 비지니스 트랜잭션을 포스팅하기 위한 것 등의 공통 비지니스 프로세스 패턴을 포함한다.

솔루션 프레임워크는 데이터 액세스, 보안, 사용자 인터페이스, 작업 흐름, 컴포넌트 프로그래밍 모델 및 기타 등등을 위한 풍부한 서비스를 제공함으로써 컴포넌트를 작성하는 것을 지원하는 비지니스 어플리케이션 프레임워크를 사용하여 작성된다. 솔루션 프레임워크에 의해 정의되는 비지니스 모델 및 규칙이 어플리케이션에 적절하지 않은 경우, 이는 우회될 수 있고 또 어플리케이션의 개발자는 어플리케이션 프레임워크를 직접 사용할 수 있다.

비지니스 어플리케이션 프레임워크는 .NET 프레임워크를 취하는 규범적 프로그래밍 모델을 제공하며, 그의 기능을 비지니스 어플리케이션에 집중한다. 꽤 확장성있는 반면, 이는 보다 일반적인 솔루션이 하지 않는 어플리케이션 개발자를 위한 다수의 결정을 하며, 그에 따라 이를 사용하는 생태계 내의 모든 어플리케이션에 대한 구현 및 구조에서의 생산성 및 일관성을 향상시킨다. 비지니스 어플리케이션 프레임워크는 웹 기반의 분산 OLTP 어플리케이션을 작성하기 위한 프로그래밍 모델 및 서비스를 제공한다. 이는 임의의 제품에 특별한 어떤 비지니스 로직도 포함하지 않을 수 있으며, 따라서 비지니스 어플리케이션을 작성하는 데는 물론 그의 기본적인 프로파일을 근사화(fitting)하는 임의의 다른 어플리케이션에도 적합하다. 이는 데이터 액세스, 메시징(SOAP 및 다른 프로토콜의 사용 등), 작업 흐름, 이벤트 중개(event brokering), 인스턴스 활성화, 진단, 구성, 메타데이터 관리(반영), 어플리케이션 컴포넌트 보안, 글로벌화, 비지니스 데스크 셸(business desk shell) 및 기타에 대한 지원을 제공하는 일련의 서비스를 제공한다. CDP에 대한 요건은 주로 BF의 비지니스 어플리케이션 프레임워크 부분으로부터 나오며, 특히 데이터 액세스 및 데이터 로직의 리모팅의 분야에서 그렇다.

개체 영속성(entity persistence, EP), 비지니스 프레임워크 내의 데이터 액세스 서브시스템은 실용적 객체 관계형 매핑 프레임워크에 기초한 풍부한 데이터 모델을 지원한다. 이는 개발자가 관계형 행(relational row)에 매핑되는 (C#) 객체를 처리한다는 점에서 객체 관계형이다. 코어 데이터 모델링 개념은 개체 및 개체들 간의 관계이다. 공통 데이터 모델(Common Data Model, CDM)은 기본적으로 BF 데이터 액세스의 데이터 모델링 요건을 지원한다. MBF EP는 이하의 데이터 액세스 동작에 대한 지원을 필요로 한다.

● 개체 생성, 읽기, 업데이트 및 삭제

● DataSet을 반환하는 애드혹 쿼리

● 데이터베이스에서 실행되는 세트 기반 동작

BF는 분산 서비스 지향 구성을 지원하기 위한 에이전트/서비스 프레임워크를 규정한다. 어떤 비지니스 기능이 주어지면, 에이전트는 가능한 한 기능의 사용자에 가까운 곳에서 실행되고, 서버는 가능한 한 데이터에 가까운 곳에서 실행된다. "가능한 한 가까운"은 각각의 배치 시나리오 및 사용자의 종류에 따라 다르다. 에이전트/서비스 패턴은 2-계층(클라이언트-서버) 내지 다중-계층 배치의 배치 유연성을 제공한다. 이러한 배치에서, 서비스는 서비스 경계에 걸쳐 호출될 수 있는 인터페이스를 제공하고, 에이전트는 일반적으로 클라이언트(사용자)에 가까이 있는 데이터를 페치하고 그를 처리하며 변동을 서비스에 전파한다.

상세하게는, 도 20은 LOB 프레임워크 및/또는 어플리케이션이 어떻게 CDP를 이용할 수 있는지를 나타낸 것이다. 프레임워크 및 프레임워크를 이용하여 작성된 어플리케이션은 중간 계층 상의 울트라 어플리케이션 서버(ultra application server)(2002)에서 호스팅될 수 있다. 이는 작업 흐름, 메시징, 비지니스 프로세 스, 기타 등등(이에 한정되는 것은 아님)의 표준 LOB 서비스를, 클라이언트 어플리케이션(2004)으로의 웹 서비스 인터페이스 형태로 제공할 수 있다. 울트라 어플리케이션 서버(2002)는 CDP를 이용하여 스토어 제약(2006)(CDP 제약 엔진(2014)을 통해) 및 데이터 중심 비지니스 로직(2008)을 작성할 수 있다. 클라이언트 어플리케이션(2004)은 인디고 채널을 통해 (예를 들어, 웹 서비스 프록시(2010) 및 웹 서비스 인터페이스(2012)를 이용하여) 웹 서비스 메소드를 호출할 수 있다. 게다가, 이는 그의 객체 영속성/데이터 액세스 요구에 대해 클라이언트 계층 상의 CDP를 사용할 수 있다.

이하의 것들, 즉 1) 세션 관리, 2) CRUD, 3) 공통 데이터 모델(CDM) 지원(예를 들어, 개체 추상화, 개체 확장), 4) 쿼리(예를 들어, 애드혹, 개체), 5) 객체 캐시의 실행(암시적), 6) 동시성 관리(예를 들어, 최적, 격리 레벨, 충돌 검출, 기타 등등), 7) 비지니스 로직(예를 들어, 메소드에서, 검증/디폴팅, 속성 패턴, 이벤트), 8) 보안 확장, 9) 제공자(예를 들어, 관계형 데이터베이스 기반 파일 저장 시스템)와의 매핑(쿼리, 스키마),10) 메타데이터 확장 기능(개체의 다른 사용을 지원함), 11) 세트 동작, 12) 저장 프로시저 호출 기능, 및 13) N-계층 배치는 CDP에 의해 만족될 수 있다.

BF 개체 영속성은 CDP에 대한 자연적인 적합성이다. BF의 영속성 요건의 대부분은 CDP에 의해 완전히 지원된다. SOA 요건 중 어떤 것은 또한 CDP에 의해 해소된다. 그렇지만, 에이전트/서비스 모델, BF 비지니스 동작 및 프로세스에 대한 완전한 지원은 CDP 상부에 LOB 프레임워크로서 구축될 수 있다. MBF의 비지니스 솔루션 프레임워크는 또한 CDP의 상부에 계층을 이루고 있다.

도 21 및 도 22는 본 발명에 따른 방법을 나타낸 것이다. 설명의 편의상, 이 방법은 일련의 단계들로서 도시되고 설명된다. 본 발명이 예시된 단계들에 의해 및/또는 단계들의 순서에 의해 제한되지 않으며, 예를 들어 단계들이 다양한 순서로 및/또는 동시에 일어날 수 있고 또 본 명세서에 도시되고 기술되지 않은 다른 단계들과 함께 일어날 수 있음을 잘 알 것이다. 게다가, 모든 예시된 단계들이 본 발명에 따른 방법을 구현해야만 하는 것은 아닐 수 있다. 게다가, 당업자라면 이 방법이 다른 대안으로서 상태도 또는 이벤트를 통해 일련의 상호 연관된 상태로서 표현될 수 있음을 잘 알 것이다.

도 21은 CDP의 여러가지 컴포넌트 내에서의 데이터의 흐름의 관리를 용이하게 해주는 방법(2100)을 나타낸 것이다. 참조 번호(2102)에서, 어플리케이션은 주문 데이터 객체를 생성한다. 주문 데이터 클래스는 CDM 스키마에 기술되어 있는 테이블 세트 유형을 나타낼 수 있다. 주문 데이터 객체는 필요에 따라 스토어와 상호작용하도록 구성될 수 있는 스토리지 컨텍스트 객체를 생성한다. 참조 번호(2104)에서, 세션을 개시하고 또 트랜잭션 컨텍스트를 생성함으로써 스토어로의 연결이 개설되며, 여기서 보안 컨텍스트가 설정된다. 참조 번호(2106)에서, 스토리지 컨텍스트의 인스턴스가 어플리케이션으로 반환된다.

참조 번호(2108)에서, CDM 쿼리에 기초하여 객체를 검색하기 위해 인터페이스가 노출된다. 참조 번호(2110)에서, 쿼리는 보안을 적절히 적용하면서 SQL에 매핑된다. 게다가, 어플리케이션/사용자는 볼 수 있도록 허용된 데이터만을 볼 수 있다. 참조 번호(2112)에서, 쿼리로부터의 결과가 CDP 런타임으로 반환되고 또 어플리케이션으로 반환된다. 참조 번호(2114)에서, 변동을 플러쉬하기 위해, 캡슐화된 스토리지 컨텍스트 객체에 대해 변동 저장 함수가 호출될 수 있다.

도 22는 다수의 개별적인 프레임워크에 걸쳐 CDP를 배치하는 것을 용이하게 해주는 방법을 나타낸 것으로서, 여기서 개별적인 어플리케이션은 각각의 프레임워크와 관련될 수 있다. 참조 번호(2202)에서, 구조화된, 반구조화된 및 비구조화된 데이터를 저장할 수 있는 데이터 스토어가 생성된다. 참조 번호(2204)에서, CDP가 생성되고 데이터 스토어 상에 오버레이된다. 계속하여 참조 번호(2206)에서, 연관된 개별적인 어플리케이션을 갖는 다수의 프레임워크는 데이터 스토어에 액세스할 수 있다. 참조 번호(2208)에서, 공유 데이터가 개별적인 프레임워크 상의 개별적인 어플리케이션에 제공된다. 환언하면, 데이터 스토어 내의 데이터는 각자의 프레임워크에 상관없이 복수의 개별적인 어플리케이션들 간에 공유될 수 있다. 참조 번호(2210)에서, 전용 데이터가 특정의 프레임워크 상의 특정의 어플리케이션에 고유할 수 있도록 전용 데이터가 이용될 수 있다.

이제부터 도 23을 참조하면, CDP 및 연관된 컴포넌트 및/또는 프로세스의 개시된 아키텍처를 실행하는 동작을 하는 컴퓨터의 블록도가 도시되어 있다. 본 발명의 아키텍처의 여러가지 측면에 대한 부가의 컨텍스트를 제공하기 위해, 도 23 및 이하의 설명은 본 발명의 여러가지 측면이 구현될 수 있는 적합한 컴퓨팅 환경(2300)에 대한 간략하고 일반적인 설명을 제공하기 위한 것이다. 이 아키텍처가 하나 이상의 컴퓨터 상에서 실행될 수 있는 컴퓨터 실행가능 명령어의 일반적인 관 점에서 전술되어 있지만, 당업자라면 이 아키텍처가 또한 다른 프로그램 모듈들과 조합하여 및/또는 하드웨어 및 소프트웨어의 조합으로서 구현될 수 있음을 잘 알 것이다.

일반적으로, 프로그램 모듈은 특정의 작업을 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조, 기타 등등을 포함한다. 게다가, 당업자라면 본 발명의 방법들이 단일 프로세서 또는 멀티프로세서 컴퓨터 시스템, 미니컴퓨터, 메인프레임 컴퓨터는 물론 퍼스널 컴퓨터, 핸드-헬드 컴퓨팅 장치, 마이크로프로세서-기반 또는 프로그램가능 가전 제품, 및 기타 등등(이들 각각은 하나 이상의 연관된 장치와 연결되어 동작할 수 있음)을 비롯한 다른 컴퓨터 시스템 구성에서 실시될 수 있음을 잘 알 것이다.

이 예시된 측면들은 또한 어떤 작업들이 통신 네트워크를 통해 연결되어 있는 원격 프로세싱 장치들에 의해 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈들은 로컬 및 원격 메모리 저장 장치 둘다에 위치할 수 있다.

컴퓨터는 일반적으로 각종의 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체 둘다를 포함한다. 제한이 아닌 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등의 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발 성 및 비휘발성, 분리형 및 비분리형 매체 둘다를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital video disk) 또는 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이에 한정되는 것은 아니다.

통신 매체는 일반적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 반송파 또는 기타 전송 메커니즘 등의 변조된 데이터 신호로 구현하며, 임의의 정보 전달 매체를 포함한다. 용어 "변조된 데이터 신호"는 그의 특성 중 하나 이상이 그 신호에 정보를 인코딩하는 방식으로 설정 또는 변경된 신호를 의미한다. 제한이 아닌 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 연결 등의 유선 매체, 및 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함한다. 상기한 것들 중 임의의 것의 조합도 역시 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.

다시 도 23을 참조하면, 여러가지 측면을 구현하는 예시적인 환경(2300)은 컴퓨터(2302)를 포함하고, 이 컴퓨터(2302)는 프로세싱 유닛(2304), 시스템 메모리(2306) 및 시스템 버스(2308)를 포함한다. 시스템 버스(2308)는 시스템 메모리(2306)(이에 한정되는 것은 아님)를 비롯한 시스템 컴포넌트를 프로세싱 유닛(2304)에 연결시킨다. 프로세싱 유닛(2304)은 여러가지 상업적으로 이용가능한 프로세서 중 임의의 것일 수 있다. 듀얼 마이크로프로세서 및 기타의 멀티프로세서 아키텍처도 역시 프로세싱 유닛(2304)으로서 이용될 수 있다.

시스템 버스(2308)는 (메모리 콘트롤러가 갖거나 갖지 않는) 메모리 버스, 주변 버스, 및 각종의 상업적으로 이용가능한 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스에 추가적으로 상호연결될 수 있는 몇 가지 유형의 버스 구조 중 임의의 것일 수 있다. 시스템 메모리(2306)는 판독 전용 메모리(ROM)(2310) 및 랜덤 액세스 메모리(RAM)(2312)를 포함한다. 기본 입/출력 시스템(BIOS)은 ROM, EPROM, EEPROM 등의 비휘발성 메모리(2310)에 저장되며, 이 BIOS는 시동 중과 같은 때에 컴퓨터(2302) 내의 구성요소들 간의 정보의 전송을 돕는 기본적인 루틴을 포함한다. RAM(2312)은 또한 데이터를 캐싱하기 위한 정적 RAM(static RAM) 등의 고속 RAM을 포함할 수 있다.

컴퓨터(2302)는 또한 내장형 하드 디스크 드라이브(HDD)(2314)(예를 들어, EIDE, SATA) - 이 내장형 하드 디스크 드라이브(2314)는 또한 적당한 샤시(도시 생략)에 넣어 외장형으로 사용하도록 구성될 수 있음 -, 자기 플로피 디스크 드라이브(FDD)(2316)(예를 들어, 분리형 디스켓(2318)으로부터 판독하거나 그에 기록함), 및 광 디스크 드라이브(2320)(예를 들어, CD-ROM 디스크(2322)로부터 판독하거나, DVD 등의 기타 고용량 광 매체로부터 판독하거나 그에 기록함)를 포함한다. 하드 디스크 드라이브(2314), 자기 디스크 드라이브(2316) 및 광 디스크 드라이브(2320)는 각각 하드 디스크 드라이브 인터페이스(2324), 자기 디스크 드라이브 인터페이스(2326), 및 광 드라이브 인터페이스(2328)에 의해 시스템 버스(2308)에 연결될 수 있다. 외장형 드라이브 구현을 위한 인터페이스(2324)는 USB(Universal Serial Bus) 및 IEEE 1394 인터페이스 기술 중 적어도 하나 또는 둘다를 포함한다. 다른 외장형 드라이브 연결 기술은 본 발명의 범위 내에 속한다.

드라이브 및 그의 연관된 컴퓨터 판독가능 매체는 데이터, 데이터 구조, 컴퓨터 실행가능 명령어, 기타 등등의 비휘발성 저장을 제공한다. 컴퓨터(2302)에 있어서, 드라이브 및 매체는 임의의 데이터를 적당한 디지털 포맷으로 저장하기 위한 것이다. 이상에서의 컴퓨터 판독가능 매체에 대한 설명이 HDD, 분리형 자기 디스켓 및 CD 또는 DVD 등의 분리형 광 매체를 언급하고 있지만, 당업자라면 ZIP 드라이브, 자기 카세트, 플래쉬 메모리 카드, 카트리지 및 기타 등등의 컴퓨터에 의해 판독가능한 다른 유형의 매체도 역시 예시적인 오퍼레이팅 환경에서 사용될 수 있음과 또한 임의의 이러한 매체가 이 아키텍처의 방법을 수행하는 컴퓨터 실행가능 명령어를 포함할 수 있음을 잘 알 것이다.

오퍼레이팅 시스템(2330), 하나 이상의 어플리케이션 프로그램(2332), 기타 프로그램 모듈(2334) 및 프로그램 데이터(2336)를 비롯한 다수의 프로그램 모듈이 드라이브 및 RAM(2312)에 저장될 수 있다. 오퍼레이팅 시스템, 어플리케이션, 모듈, 및/또는 데이터의 전부 또는 그 일부분은 또한 RAM(2312)에 캐싱될 수 있다. 이 아키텍처에서 상업적으로 이용가능한 오퍼레이팅 시스템 또는 오퍼레이팅 시스템들의 조합이 구현될 수 있음을 잘 알 것이다.

사용자는 하나 이상의 유선/무선 입력 장치, 예를 들어 키보드(2338) 및 마우스(2340) 등의 포인팅 장치를 통해 명령 및 정보를 컴퓨터(2320)에 입력할 수 있다. 다른 입력 장치(도시 생략)로는 마이크로폰, IR 리모콘, 조이스틱, 게임 패 드, 스타일러스 펜, 터치 스크린, 기타 등등이 있을 수 있다. 이들 및 다른 입력 장치는 종종 시스템 버스(2308)에 연결되어 있는 입력 장치 인터페이스(2342)를 통해 프로세싱 유닛(2304)에 연결되지만, 병렬 포트, IEEE 1394 직렬 포트, 게임 포트, USB 포트, IR 인터페이스, 기타 등등의 다른 인터페이스에 의해 연결될 수 있다.

모니터(2344) 또는 다른 유형의 디스플레이 장치도 역시 비디오 어댑터(2346) 등의 인터페이스를 통해 시스템 버스(2308)에 연결된다. 모니터(2344) 이외에, 컴퓨터는 일반적으로 스피커, 프린터, 기타 등등의 다른 주변 출력 장치(도시 생략)를 포함한다.

컴퓨터(2302)는 원격 컴퓨터(들)(2348) 등의 하나 이상의 원격 컴퓨터로의 유선 및/또는 무선 통신을 통해 논리적 연결을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(들)(2348)는 워크스테이션, 서버 컴퓨터, 라우터, 퍼스널 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서 기반 오락 기기, 피어 장치(peer device) 또는 다른 통상의 네트워크 노드일 수 있으며, 일반적으로 컴퓨터(2302)와 관련하여 기술된 구성요소들 대부분 또는 그 전부를 포함하지만, 간략함을 위해 메모리/저장 장치(2350)만이 예시되어 있다. 도시된 논리적 연결은 근거리 통신망(LAN)(2352) 및/또는 보다 대규모의 네트워크, 예를 들어 원거리 통신망(WAN)(2354)에의 유선/무선 연결을 포함한다. 이러한 LAN 및 WAN 네트워킹 환경은 사무실 및 기업에서 통상적인 것이며, 인트라넷 등의 전사적 컴퓨터 네트워크를 용이하게 해주며, 이들 모두는 글로벌 통신 네트워크, 예를 들어 인터넷에 연결될 수 있다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(2302)는 유선 및/또는 무선 통신 네트워크 인터페이스 또는 어댑터(2356)를 통해 로컬 네트워크(2352)에 연결된다. 어댑터(2356)는 무선 어댑터(2356)와의 통신을 위해 배치되어 있는 무선 액세스 포인트를 포함할 수 있는 LAN(2352)으로의 유선 또는 무선 통신을 용이하게 해줄 수 있다.

WAN 네트워킹 환경에서 사용될 때, 컴퓨터(2302)는 모뎀(2358)을 포함할 수 있거나, WAN(2354) 상의 통신 서버에 연결되어 있거나, 또는 인터넷을 통하는 등 WAN(2354)을 통해 통신을 설정하는 다른 수단을 갖는다. 내장형 또는 외장형 및 유선 또는 무선 장치일 수 있는 모뎀(2358)은 직렬 포트 인터페이스(2342)를 통해 시스템 버스(2308)에 연결된다. 네트워크화된 환경에서, 컴퓨터(2302)와 관련하여 도시된 프로그램 모듈 또는 그의 일부분은 원격 메모리/저장 장치(2350)에 저장될 수 있다. 도시된 네트워크 연결이 예시적인 것이고 컴퓨터들 간의 통신 링크를 설정하는 다른 수단이 사용될 수 있음을 잘 알 것이다.

컴퓨터(2302)는 무선 통신을 하도록 배치된 임의의 무선 장치 또는 개체, 예를 들어 프린터, 스캐너, 데스크톱 및/또는 휴대용 컴퓨터, 개인 휴대 단말기, 통신 위성, 무선 검출가능 태그와 연관된 임의의 장비 또는 장소(예를 들어, 키오스크, 신문 가판대, 휴게실), 및 전화와 통신하는 동작을 한다. 이것은 적어도 Wi-Fi 및 블루투스™ 무선 기술을 포함한다. 따라서, 통신은 종래의 네트워크에서와 같이 사전 정의된 구조이거나 단순히 적어도 2개의 장치 간의 애드혹 통신(ad hoc communication)일 수 있다.

Wi-Fi(Wireless Fidelity)는 유선 없이 가정의 소파, 호텔 객실의 침대, 또는 직장의 회의실로부터 인터넷으로의 연결을 가능하게 해준다. Wi-Fi는 이러한 장치, 예를 들어 컴퓨터가 실내 및 실외에서, 즉 기지국의 통화권 내의 어느 곳에서라도 데이터를 전송 및 수신할 수 있게 해주는 셀 전화에서 사용되는 것과 유사한 무선 기술이다. Wi-Fi 네트워크는 안전하고 신뢰성있으며 고속인 무선 연결을 제공하기 위해 IEEE 802.11(a, b, g, 등등)이라고 하는 무선 기술을 사용한다. Wi-Fi 네트워크는 컴퓨터를 서로, 인터넷에 또한 (IEEE 802.3 또는 이더넷을 사용하는) 유선 네트워크에 연결하는 데 사용될 수 있다. Wi-Fi 네트워크는 비인가 2.4 및 5 GHz 무선 대역에서, 11 Mbps(802.11a) 또는 54 Mbps(802.11b) 데이터 레이트로, 또는 양 대역(듀얼 대역)을 포함하는 제품에서 동작하며, 따라서 이 네트워크는 많은 사무실에서 사용되는 기본적인 10BaseT 유선 이더넷 네트워크와 유사한 실세계 성능을 제공할 수 있다.

이제부터 도 24를 참조하면, 데이터 관리를 제공하기 위해 CDP 및 각자의 컴포넌트 및/또는 프로세스에 의해 이용될 수 있는 예시적인 컴퓨팅 환경(2400)의 개략 블록도가 도시되어 있다. 시스템(2400)은 하나 이상의 클라이언트(들)(2402)를 포함한다. 클라이언트(들)(2400)는 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세서, 컴퓨팅 장치)일 수 있다. 클라이언트(들)(2402)는 예를 들어 이 아키텍처를 이용함으로써 쿠키(들) 및/또는 연관된 컨텍스트 정보를 저장해둘 수 있다.

시스템(2400)은 또한 하나 이상의 서버(들)(2404)를 포함한다. 서버(들)(2404)도 역시 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버(2404)는 예를 들어 이 아키텍처를 이용함으로써 변환(transformation)을 수행하는 스레드를 저장해둘 수 있다. 클라이언트(2402)와 서버(2404) 간의 한가지 가능한 통신은 2개 이상의 컴퓨터 프로세스 간에 전송되도록 구성되어 있는 데이터 패킷 형태일 수 있다. 데이터 패킷은 예를 들어 쿠키 및/또는 연관된 컨텍스트 정보를 포함할 수 있다. 시스템(2400)은 클라이언트(들)(2402)와 서버(들)(2404) 간의 통신을 용이하게 해주기 위해 이용될 수 있는 통신 프레임워크(2406)(예를 들어, 인터넷 등의 글로벌 통신 네트워크)를 포함한다.

통신은 유선(광 섬유를 포함함) 및/또는 무선 기술을 통해 용이하게 될 수 있다. 클라이언트(들)(2402)는 클라이언트(들)(2402)에 로컬인 정보(예를 들어, 쿠키(들) 및/또는 연관된 컨텍스트 정보)를 저장하는 데 이용될 수 있는 하나 이상의 클라이언트 데이터 스토어(들)(2408)와 연결되어 동작한다. 이와 유사하게, 서버(들)(2404)는 서버(2404)에 로컬인 정보를 저장하는 데 이용될 수 있는 하나 이상의 서버 데이터 스토어(들)(2410)와 연결되어 동작한다.

이상에 기술된 바는 개시된 발명의 예들을 포함한다. 물론, 이 아키텍처를 설명하기 위해 모든 생각할 수 있는 컴포넌트 및/또는 방법의 조합을 기술할 수는 없지만, 당업자라면 이 아키텍처의 많은 추가의 조합 및 치환이 가능함을 잘 알 것이다. 따라서, 이 아키텍처는 첨부된 청구항의 정신 및 범위 내에 속하는 이러한 변경, 수정 및 변형 모두를 포괄하는 것으로 보아야 한다. 게다가, 상세한 설명 또는 청구항에서 용어 "포함하는"이 사용되는 범위까지, 이러한 용어는 "포함하는"이 청구항에서 이행구로서 사용될 때의 용어 "포함하는"이 해석되는 것과 유사하게 포함적인 것으로 보아야 한다.

공통 데이터 스토어와, 다수의 개별적인 어플리케이션 프레임워크의 다수의 어플리케이션 간의 데이터 관리가 제공된다.

Claims (20)

1. 데이터에 대한 균등한 액세스(uniform access)를 허용하는 복수의 개별적인 어플리케이션 프레임워크에 의해 액세스가능한 데이터 서비스들을 제공함으로써 데이터 관리를 하기 위한 적어도 하나의 프로세서를 포함하는 컴퓨터 시스템으로서,

   공개 클래스(public class), 인터페이스 및 정적 헬퍼 함수(static helper function) 중 적어도 하나의 형태로 상기 개별적인 어플리케이션 프레임워크들과 연관된 어플리케이션들에 통신하게 하는 어플리케이션 프로그램 인터페이스(API),

   상기 API에 인터페이스하고 객체-관계형 매핑(object-relational mapping), 쿼리 매핑(query mapping), 및 제약들의 시행(enforcing of constraints) 중 적어도 하나를 제공하는 런타임 컴포넌트,

   상기 복수의 개별적인 어플리케이션 프레임워크에 걸쳐 사용되는(used across) 공통 데이터 모델 - 상기 복수의 개별적인 어플리케이션 프레임워크는 LOB(line of business) 프레임워크, 최종 사용자 프레임워크, 시스템 관리 프레임워크, 사용자 어플리케이션 프레임워크, 협업 프레임워크, 비지니스 프레임워크, 및 개인 정보 프레임워크 중 2개 이상을 포함함 -,

   공유 데이터와 전용 데이터(private data)를 포함하고 데이터 서비스를 제공하기 위해 구조화된 데이터 유형, 반구조화된 데이터 유형 및 비구조화된 데이터 유형을 모델링 및 저장하는 데이터 스토어 - 상기 공유 데이터는 상기 공통 데이터 모델을 통해, 상기 복수의 개별적인 어플리케이션 프레임워크 내의 대응하는 어플리케이션 프레임워크들과 연관된 개별적인 어플리케이션들이 액세스가능하며,

   상기 전용 데이터는 상기 공통 데이터 모델을 통해, 상기 복수의 개별적인 어플리케이션 프레임워크 내의 특정의 어플리케이션 프레임워크와 연관된 특정의 어플리케이션에 의해서만 액세스가능함 -, 및

   규범적 객체-관계형 매핑(prescriptive object-relational mapping) 및 비규범적 객체-관계형 매핑(non-prescriptive object-relational mapping) 중 적어도 하나를 호출(invoking)함으로써 언어 클래스를 하부의(underlying) 테이블 표현에 매핑하는 객체-관계형 매핑을 호출하는 영속성 엔진

   을 포함하는, 컴퓨터 시스템.
2. 제1항에 있어서,

   상기 공통 데이터 모델은 도메인 특유 유형(domain specific type), 제약, 및 관계(relationship) 중 적어도 하나를 생성하기 위한 것인, 컴퓨터 시스템.
3. 제2항에 있어서,

   상기 도메인 특유 유형은 메소드와 속성 중 적어도 하나의 그룹화(grouping)에 대한 명세(specification)인 개체 유형(entity type)이며,

   상기 도메인 특유 유형은 개체, 테이블, 테이블 세트, 및 관계 중 적어도 하나를 이용하는, 컴퓨터 시스템.
4. 제3항에 있어서,

   스키마(schema)는 상기 개체, 상기 관계, 및 상기 테이블 세트 중 적어도 하나를, 네임스페이스(namespace)와 연관되도록 정의하는, 컴퓨터 시스템.
5. 제2항에 있어서,

   상기 공통 데이터 모델은 상기 공통 데이터 모델에 의해 정의되는 유형 시스템(type system)에 대한 쿼리 언어를 포함하고,

   상기 쿼리 언어는 저장된 데이터에 대한 강 자료형 객체-기반 추상화(strongly typed, object-based abstraction)를 제공하는 객체 구조에 대한 리치 쿼리(rich query)를 허용하는, 컴퓨터 시스템.
6. 제5항에 있어서,

   상기 쿼리 언어는 Opath 및 OSQL(object-oriented structured query language, 객체 지향 구조화된 쿼리 언어) 중 적어도 하나인, 컴퓨터 시스템.
7. 제1항에 있어서,

   제약들의 선언적 작성(declarative authoring)에 사용되고, 데이터 플랫폼의 적어도 하나의 개체에의 액세스를 제어하는 제약/보안 엔진(constraint/security engine)을 더 포함하는, 컴퓨터 시스템.
8. 제1항에 있어서,

   상기 매핑은 어플리케이션 공간으로부터 상기 공통 데이터 모델로의 매핑이고 상기 공통 데이터 모델로부터 상기 데이터 스토어로의 매핑과는 독립적인, 컴퓨터 시스템.
9. 제1항에 있어서,

   상기 어플리케이션은 최종 사용자 어플리케이션, 지식 근로자 어플리케이션, LOB 어플리케이션, 웹 어플리케이션, 연락처 관리 어플리케이션, 문서 관리 어플리케이션, 협업 어플리케이션, 이메일 어플리케이션, 고객 관계 관리 어플리케이션, 기업 자원 관리(enterprise resource planning) 어플리케이션, 및 시스템 관리 어플리케이션 중 적어도 하나인, 컴퓨터 시스템.
10. 제1항에 있어서,

    상기 런타임 컴포넌트는 식별자 매핑(identification mapping), 객체 변동 추적(object change tracking) 및 원래 값(original value) 중 적어도 하나를 포함하는 개체 상태의 관리를 제공하는, 컴퓨터 시스템.
11. 제1항에 있어서,

    데이터 플랫폼 및 각각의 컴포넌트들은 계층 독립적(tier-agnostic)이고, 클라이언트 계층, 중간 계층, 서버 계층 및 웹 서비스 계층 중 적어도 하나에 존재할 수 있는, 컴퓨터 시스템.
12. 제1항에 있어서,

    규칙 서비스, 변동 추적 서비스, 충돌 검출 서비스(conflict detection service), 이벤팅 서비스, 및 통지 서비스 중 적어도 하나를 더 포함하는, 컴퓨터 시스템.
13. 데이터 스토어 및 복수의 개별적인 어플리케이션 프레임워크의 복수의 어플리케이션 사이에서 데이터를 관리하기 위한 컴퓨터 구현 방법으로서,

    상기 방법의 적어도 하나의 단계들은 컴퓨터에 의해서 수행되며,

    데이터 서비스를 제공하기 위해 구조화된 데이터 유형, 반구조화된 데이터 유형 및 비구조화된 데이터 유형을 모델링 및 저장하는 상기 데이터 스토어 상에 데이터 플랫폼을 오버레이(overlay)하는 단계;

    각각의 어플리케이션 프레임워크 내의 적어도 하나의 어플리케이션이 상기 데이터 스토어를 액세스할 수 있도록 해주기 위해 상기 데이터 플랫폼 상에 상기 복수의 개별적인 어플리케이션 프레임워크를 오버레이하는 단계 - 상기 복수의 개별적인 어플리케이션 프레임워크는 LOB(line of business) 프레임워크, 최종 사용자 프레임워크, 시스템 관리 프레임워크, 사용자 어플리케이션 프레임워크, 협업 프레임워크, 비지니스 프레임워크, 및 개인 정보 프레임워크 중 2개 이상을 포함함 - ;

    공개 클래스, 인터페이스, 및 정적 헬퍼 함수 중 적어도 하나의 형태로 상기 어플리케이션들에 통신하는 것을 가능하게 하는 API를 제공하는 단계;

    객체-관계형 매핑, 쿼리 매핑, 및 제약들의 시행 중 적어도 하나를 데이터 플랫폼에서 제공하는 단계;

    상기 데이터 스토어에 액세스하기 위해 상기 복수의 개별적인 어플리케이션 프레임워크에 의해 이용되는 공통 데이터 모델을 상기 데이터 플랫폼에서 제공하는 단계 - 상기 데이터 스토어에 저장된 공유 데이터는 상기 복수의 개별적인 어플리케이션 프레임워크 내의 대응하는 어플리케이션 프레임워크들과 연관된 개별적인 어플리케이션들이 액세스가능하며, 상기 데이터 스토어에 저장된 전용 데이터는 상기 복수의 개별적인 어플리케이션 프레임워크 내의 특정의 어플리케이션 프레임워크와 연관된 특정의 어플리케이션만이 액세스가능함 - ; 및

    규범적 객체-관계형 매핑 및 비규범적 객체-관계형 매핑 중 적어도 하나를 호출함으로써 언어 클래스를 하부의 테이블 표현에 매핑하는 객체-관계형 매핑을 호출하는 영속성 엔진을 제공하는 단계

    를 포함하는, 컴퓨터 구현 방법.
14. 제13항에 있어서,

    객체를 생성하는 단계;

    세션을 이용하여 상기 데이터 스토어로의 연결을 개설하고 보안 컨텍스트를 설정하는 단계;

    스토리지 컨텍스트의 인스턴스를 어플리케이션에 반환하는 단계;

    객체들을 검색하기 위해 인터페이스를 노출시키는 단계;

    보안을 적용하면서 쿼리를 SQL에 매핑하는 단계;

    결과를 데이터 플랫폼 런타임 및 상기 어플리케이션에 반환하는 단계; 및

    변동들을 캡슐화된 스토리지 컨텍스트 객체 상에 저장하는 단계

    를 더 포함하는, 컴퓨터 구현 방법.
15. 데이터에 대한 균등한 액세스를 허용하는 복수의 개별적인 어플리케이션 프레임워크에 의해 액세스가능한 데이터 서비스들을 제공함으로써 데이터 관리를 하기 위한 적어도 하나의 프로세서를 포함하는 컴퓨터 시스템으로서,

    공개 클래스, 인터페이스 및 정적 헬퍼 함수 중 적어도 하나의 형태로 상기 개별적인 어플리케이션 프레임워크들과 연관된 어플리케이션들에 통신하는 어플리케이션 프로그램 인터페이스(API) 수단,

    상기 API 수단에 인터페이스하고 객체-관계형 매핑, 쿼리 매핑, 및 제약들의 시행 중 적어도 하나를 제공하는 수단,

    복수의 개별적인 어플리케이션 프레임워크에 의해 사용되는 공통 데이터 모델을 제공하기 위한 수단 - 상기 복수의 개별적인 어플리케이션 프레임워크는 사용자 어플리케이션 프레임워크 및 LOB(line of business) 어플리케이션 프레임워크를 포함함 -, 및

    데이터 서비스를 제공하기 위해 구조화된 데이터 유형, 반구조화된 데이터 유형 및 비구조화된 데이터 유형을 모델링 및 저장하는 데이터 스토어를 제공하는 수단 - 상기 데이터 스토어는 공유 데이터와 전용 데이터를 포함함 -

    을 포함하고,

    상기 공유 데이터는 상기 공통 데이터 모델을 통해, 상기 복수의 개별적인 어플리케이션 프레임워크 내의 대응하는 어플리케이션 프레임워크들과 연관된 개별적인 어플리케이션들이 액세스가능하며, 상기 전용 데이터는 상기 공통 데이터 모델을 통해, 상기 복수의 개별적인 어플리케이션 프레임워크 내의 특정의 어플리케이션 프레임워크와 연관된 특정의 어플리케이션에 의해서만 액세스가능하며,

    객체-관계형 매핑, 쿼리 매핑, 및 제약들의 시행 중 적어도 하나를 제공하는 수단은 규범적 객체-관계형 매핑 및 비규범적 객체-관계형 매핑 중 적어도 하나를 호출함으로써 언어 클래스를 하부의 테이블 표현에 매핑하는 객체-관계형 매핑을 호출하는 영속성 엔진을 포함하는,

    컴퓨터 시스템.
16. 제15항에 있어서,

    제약들의 선언적 작성(declarative authoring)에 사용되고, 상기 컴퓨터 시스템의 적어도 하나의 개체에의 액세스를 제어하는 제약/보안 엔진(constraint/security engine)을 더 포함하는, 컴퓨터 시스템.
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images