KR20060047761A

KR20060047761A - 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한정보 단위의 피어 대 피어 동기화를 위해 충돌 처리를제공하는 시스템 및 방법

Info

Publication number: KR20060047761A
Application number: KR1020050039247A
Authority: KR
Inventors: 아쉬쉬 비. 샤; 이레나 후디스; 레브 노비크; 비베크 제이. 자베리
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-06-30
Filing date: 2005-05-11
Publication date: 2006-05-18
Also published as: KR101041319B1; US7512638B2; EP1612702A1; JP2006018821A; JP4738908B2; US20050044187A1

Abstract

본 발명의 다양한 실시예는 피어 대 피어 동기화 시스템에 발생한 충돌을 위한 충돌 처리에 관한 것으로서, 충돌을 올바르고 효율적으로 처리하는 능력은 데이터 손실을 최소화하면서 양호한 사용가능성을 유지하면서 동기화 동안 사용자 중재에 대한 요구를 감소시킨다. 동기화 서비스에서 충돌 처리는 세 단계, 즉, (1) 충돌 검출; (2) 자동 검출 해결 및 로그; 및 (3) 충돌 검사 및 해결로 나눠진다. 특정 실시예는 다음 충돌 처리 요소 중 하나 이상을 포함하는 충돌 처리 스키마에 관한 것이다: (a) 충돌의 도시화된 표현; (b) 충돌의 검출; (c) 충돌의 내구성 저장소로의 로그; (d) 유연하고 구성가능한 충돌 해결 정책에 따라 충돌의 자동 해결; (e) 충돌을 필터링하여 해결하는 작성가능하고 확장가능한 충돌 핸들러; (f) 소거 충돌의 자동 검출 및 제거; 및 (g) 프로그램 충돌 해결.

충돌 검사, 충돌 처리, 충돌 핸들러, 피어 대 피어 동기화, 스키마

Description

하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보 단위의 피어 대 피어 동기화를 위해 충돌 처리를 제공하는 시스템 및 방법{SYSTEMS AND METHODS FOR PROVIDING CONFLICT HANDLING FOR PEER-TO-PEER SYNCHRONIZATION OF UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM}

도 1은 본 발명의 양태가 포함될 수 있는 컴퓨터 시스템을 나타내는 블록도.

도 2는 3개의 컴포넌트 그룹, 즉, 하드웨어 컴포넌트, 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트, 및 애플리케이션 프로그램 컴포넌트로 나눠진 컴퓨터 시스템을 나태는 도면.

도 2a는 파일 기판 운영 체제에서 디렉토리 내의 폴더로 그룹화된 파일에 대하여 종래 트리 기반 계층 구조를 나타내는 도면.

도 3은 스토리지 플랫폼을 나타내는 블록도.

도 4는 항목, 항목 폴더 및 카테고리 간의 구조적 관계를 나타내는 도면.

도 5a는 항목의 구조를 나타내는 블록도.

도 5b는 도 5a의 항목의 복잡한 속성 유형을 나타내는 블록도.

도 5c는 "위치" 항목을 나타내되, 이의 복잡한 유형을 더 설명한(명시적으로 열거한) 블록도.

도 6a는 베이스 기반으로 발견된 항목의 서브타입으로서 항목을 나타내는 도 면.

도 6b는 도 6a의 서브타입 항목을 나타내되, 이의 상속형이 (이의 중간 속성에 더하여) 명시적으로 열거되는 블록도.

도 7은 두 개의 정상 레벨 클래스 유형, 항목 및 속성기반, 및 이로부터 유도된 추가 베이스 스키마를 포함하는 베이스 스키마를 나타내는 블록도.

도 8a는 코어 스키마에서 항목을 나타내는 블록도.

도 8b는 코어 스키마에서 속성 유형을 나타내는 블록도.

도 9는 항목 폴더, 이의 멤버 항목, 및 항목 폴더와 이의 멤버 항목 간의 상호 관계를 나타내는 블록도.

도 10은 카테고리(또는 항목 자체), 이의 멤버 항목, 및 카테고리와 이의 멤버 항목 간의 상호 관계를 나타내는 블록도.

도 11은 스토리지 플랫폼의 데이터 모델의 참조형 계층을 나타내는 도면.

도 12는 관계가 분류되는 방식을 나타내는 도면.

도 13은 통지 메커니즘을 나타내는 도면.

도 14는 두 개의 거래가 모두 새로운 기록을 동일한 B 트리에 삽입하는 예를 나타내는 도면.

도 15는 데이터 변환 검출 프로세스를 나타내는 도면.

도 16은 예시적인 디렉토리 트리를 나타내는 도면.

도 17은 디렉토리 기반 파일 시스템의 기존 폴더가 스토리지 플랫폼 데이터 저장소에 이동되는 예를 나타내는 도면.

도 18은 포함 폴더(Containment Folder)의 개념을 나타내는 도면.

도 19는 스토리지 플랫폼 API의 기본 아키텍처를 나타내는 도면.

도 20은 스토리지 플랫폼 API 스택의 다양한 컴포넌트를 개략적으로 나타내는 도면.

도 21a는 예시적인 컨택 항목 스키마의 그림 표현.

도 21b는 도 21a의 예시적인 컨택 항목 스키마에 대한 요소의 그림 표현.

도 22는 스토리지 플랫폼 API의 런타임 프레임워크를 나타내는 도면.

도 23은 "모두 발견(FindAll)" 동작의 실행을 나타내는 도면.

도 24는 스토리지 플랫폼 API 클래스가 스토리지 플랫폼 스키마에서 생성된 프로세스를 나타내는 도면.

도 25는 파일 API가 기초하는 스키마를 나타내는 도면.

도 26은 데이터 보안 목적으로 사용되는 액세스 마스크 포맷을 나타내는 도면.

도 27의 (a) 내지 (c)는 기존 보안 영역에서 분할된 새롭게 동일하게 보호된 보안 영역을 나타내는 도면.

도 28은 항목 검색 보기의 개념을 나타내는 도면.

도 29는 예시적인 항목 계층을 나타내는 도면.

도 30a는 제1 및 제2 코드 세그먼트가 통신하는 도관으로서 인터페이스(인터페이스1)를 나타내는 도면.

도 30b는 시스템의 제1 및 제2 코드 세그먼트가 매체 M을 통해 통신할 수 있 게 하는 인터페이스 객체(I1 및 I2)를 포함하는 인터페이스를 나타낸 도면.

도 31a는 인터페이스(인터페이스1)에 의해 제공된 함수가 인터페이스의 통신을 여러 인터페이스(인터페이스1A, 인터페이스1B, 인터페이스1C)에 분할되는 방식을 나타내는 도면.

도 31b는 인터페이스(I1)에 의해 제공된 함수가 여러 인터페이스(I1a, I1b, I1c)로 분할될 수 있는 방식을 나타내는 도면.

도 32a는 무의미한 파라미터 정밀도가 무시되거나 임의의 파라미터로 대체되는 시나리오를 나타내는 도면.

도 32b는 인터페이스가 파라미터를 무시하거나 이를 인터페이스에 추가하도록 한정된 대체 인터페이스로 대체되는 시나리오를 나타내는 도면.

도 33a는 제1 및 제2 코드 세그먼트가 이들 모두를 포함하는 모듈로 병합되는 시나리오를 나타내는 도면.

도 33b는 인터페이스의 일부 또는 전부가 다른 인터페이스에 인라인으로 기입되어 병합 인터페이스를 형성하는 시나리오를 나타내는 도면.

도 34a는 하나 이상의 미들웨어 부분이 이들에 부합하는 제1 인터페이스 상의 통신을 하나 이상의 인터페이스로 변환할 수 있는 방식을 나타내는 도면.

도 34b는 코드 세그먼트가 인터페이스에 도입되어 하나의 인터페이스로부터 통신을 수신하지만 제2 및 제3 인터페이스에 기능을 전송하는 방식을 나타내는 도면.

도 35a는 저스트 인 타임 컴파일러(JIT)가 하나의 코드 세그먼트에서 다른 코드 세그먼트로 통신을 변환할 수 있는 방식을 나타내는 도면.

도 35b는 하나 이상의 인터페이스를 동적으로 재기입하여 상기 인터페이스를 동적으로 해결 또는 변경될 수 있는 JIT 방법을 나타내는 도면.

도 36은 공통 데이터 저장소의 3개의 인스턴스와 이들을 동기화하는 컴포넌트를 나타내는 도면.

도 37은 이의 상태가 계산되는 방식 또는 이의 관련 메타데이터가 교환되는 방식을 인식하지 못하는 단일 어댑터로 가정하는 본 발명의 일 실시예를 나타내는 도면.

도 38a 내지 도 38d는 순차 변경 열거 방법론으로 변경을 추적, 열거 및 동기화하여 동일한 예외 및 솔루션을 강조하는 방식을 나타내는 도면.

도 39a는 본 발명의 여러 실시예에 대한 파이프라인의 충돌 처리를 나타내는 도면.

도 39b는 도 39a에서 나타낸 파이프라인의 논리 트래버설(logical traversal)을 나타내는 흐름도.

도 40은 본 발명의 여러 실시예에서 충돌 아이템은 타겟 항목의 복사본으로 로그되는 일 예를 나타내는 블록도.

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

206 : 애플리케이션 프로그램 컴포넌트

204 : 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트

202 : 하드웨어 컴포넌트

340 : 플랫폼 스키마

342 : 확장형 플랫폼 스키마

344 : 새로운 ISV 스키마

346 : 스키마 배치 도구

350a, 350b, 350c : 애플리케이션 프로그램

320 : 애플리케이션 프로그래밍 인터페이스

322 : 스토리지 플랫폼 API

<참조 문헌>

본 출원은 2003년 10월 24일에 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허번호 제10/646,646호(대리인 정리번호 MSFT-2745)의 일부계속출원이고, 이는 2003년 8월 21일에 출원되고 발명의 명칭이 "STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA"인 미국 특허번호 제10/646,646(대리인 정리번호 MSFT-2734)호의 일부계속출원으로서, 이들 전체 내용은 참조로서 본 명세서에 포함된다.

본 출원은 다음의 공동 양도된 출원에 개시되는 발명의 주요 사상이 관련되 며, 이의 내용은 여기서 전체로서 본 발명에 포함된다(편이를 위해 부분적으로 요약됨): 2003년 8월 21일에 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION"인 미국 특허출원번호 제10/647,058호(대리인 정리번호 MSFT-1748); 2003월 8월 21일에 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION"인 미국 특허출원번호 제10/646,941호(대리인 정리번호 MSFT-1749); 2003년 8월 21일에 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR THE IMPLEMENTATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허출원번호 제10/646,940호(대리인 정리번호 MSFT-1750); 2003년 8월 21일에 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEME FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허출원번호 제10/646,632호(대리인 정리번호 MSFT-1751); 2003년 8월 21일에 출원되고 발명의 명칭이 "SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허출원번호 제10/646,645호(대리인 정리번호 MSFT-1752); 2003년 8월 21일에 출원되고 발명의 명칭이 "SYSTEMS AND METHOD FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM"인 미국 특허출원번호 제10/646,575호(대리인 정리번호 MSFT-2733); 2003 년 8월 21일에 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM"인 미국 특허출원번호 제10/646,580호(대리인 정리번호 MSFT-2735); 동일자로 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허출원번호 제____호(미지정)(대리인 특허정리번호 MSFT-2829); 동일자로 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허출원번호 제____호(미지정)(대리인 특허정리번호 MSFT-2844); 동일자로 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허출원번호 제____호(미지정)(대리인 특허정리번호 MSFT-2846); 및 동일자로 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"인 미국 특허출원번호 제____호(미지정)(대리인 특허정리번호 MSFT-2847).

본 발명은 정보 저장 및 검색 분야뿐만 아니라 컴퓨터화된 시스템에서 상이한 유형의 데이터를 편성, 검색 및 공유하는 액티브 스토리지 플랫폼에 관한 것이다. 특히, 본 발명은 데이터 플랫폼의 여러 인스턴스 가운데 데이터의 피어 대 피어 동기화를 위한 충돌 처리에 관한 것이다.

개별 디스크 용량은 지난 십 년 동안 해마다 대략 70퍼센트(70%)로 성장하고 있다. 무어의 법칙은 수년 동안 발생한 중앙 처리 장치(CPU) 전력에서 엄청난 증가를 정확하게 예측하였다. 유선 및 무선 기술은 엄청난 접속성과 대역을 제공하였다. 현재 추세가 지속된다는 가정하에, 수년 내에 평균 랩탑 컴퓨터는 대략 1 테라바이트(TB)의 스토리지를 소유하고 수백만의 파일을 포함하며, 500 기가바이트(GB)는 보다 흔한 것이 될 것이다.

소비자는 개인 정보 관리사(PIM) 스타일 데이터이든 또는 디지털 음악 또는 사진 등의 매체이든 이들의 컴퓨터를 주로 통신 및 개인 정보를 구성하는데 사용한다. 디지털 컨텐츠의 양과 원본 바이트를 저장하는 능력은 크게 증가하였지만, 이러한 데이터를 편성하여 통합하기 위해 소비자에게 이용가능한 방법은 이 추세를 따라 잡지 못하고 있다. 지식 근로자는 상당한 양의 시간을 정보를 관리하고 공유하는데 사용하며, 몇몇 연구는 지식 근로자가 그들의 시간의 15 내지 25%를 비생산적인 정보 관련 활동에 사용한다고 추정한다. 다른 연구는 통상의 지식 근로자는 정보 검색에 매일 약 2.5 시간을 사용한다고 추정한다.

개발자와 정보 기술(IT) 부서는 사람, 장소, 시간 및 이벤트와 같은 것을 나타내는 공통 스토리지 추상화(common storage abstraction)를 위해 이들 자신의 데이터 저장소를 구축하는데 상당한 양의 시간과 돈을 투자한다. 이는 작업이 중복되게 할 뿐만 아니라 이 데이터의 공통 검색 또는 공유를 위한 어떤 메커니즘도 없이 공통 데이터의 섬을 생성한다. 오늘날 마이크로소프트 윈도우 운영 체제를 동작하는 컴퓨터 상에서 얼마나 많은 주소록이 존재하는지를 고려해보라. 이메일 클 라이언트와 개인 재무 프로그램과 같은 많은 애플리케이션은 개별 주소록을 보유하며, 이러한 프로그램 각각이 개별적으로 유지하는 주소록 데이터의 애플리케이션 사이에 공유가 거의 없다. 결과적으로, (Microsoft Money와 같은)재무 프로그램은 이메일 컨택 폴더(Microsoft Outlook에서와 같이)에 유지되는 주소에서의 수취인에 대한 주소를 공유하지 않는다. 즉, 많은 사용자는 여러 장치를 가지고 이들 중에서 그리고 셀룰러 폰에서 MSN과 AOL과 같은 상용 서비스까지 등의 광범위한 추가 소스에 걸쳐 개인 데이터를 논리적으로 동기화하여야 하지만, 그럼에도 불구하고, 공유 문서의 공동작업은 통상 문서를 이메일 메시지에 첨부하여, 즉, 수동으로 그리고 비효율적으로 달성된다.

이러한 공동작업의 결여의 이유 중 하나는 컴퓨터 시스템에서 정보의 기관으로의 종래 접근법이 파일-폴더-디렉토리 기반 시스템("파일 시스템")의 사용에 중심을 두어 파일을 저장하는데 사용되는 저장 매체의 물리 구조의 추상화에 따라 폴더의 디렉토리 계층으로 복수의 파일을 구성하기 때문이다. 1960년대에 개발된 멀틱(Multics) 운영 체제는 파일, 폴더, 및 디렉토리의 사용을 개척하여 운영 체제 레벨에서 데이터의 저장가능 단위를 관리하는데 기여할 수 있다. 특히, 멀틱은 파일의 물리 주소가 사용자(애플리케이션과 최종 사용자)에게 투명하지 않은 파일 계층 내에서 기호 주소를 사용하였다(이로 인해 파일 경로의 아이디어가 도입됨). 이러한 파일 시스템은 임의의 개별 파일의 파일 포맷에는 전혀 관심이 없었으며, 이들 파일 간의 관계는 운영 체제 레벨에서 무관한 것으로(즉, 계층 내 파일의 위치 이외의 것으로) 간주되었다. 멀틱의 도래 이후, 저장가능 데이터는 운영 체제 레벨에서 파일, 폴더, 및 디렉토리로 구성되었다. 이들 파일은 통상 파일 시스템에 의해 유지되는 특정 파일로 구현된 파일 계층 자체("디렉토리")를 포함한다. 이러한 디렉토리는 차례로 디렉토리 내의 모든 다른 파일과 계층 내에 이러한 파일(폴더라고 함)의 노드 위치에 대응하는 엔트리 리스트를 유지한다. 이러한 것은 대략 40년 동안 당업계에 공지되어 왔다.

그러나, 컴퓨터의 물리 스토리지 시스템에 상주하는 정보의 합리적인 표현을 제공하지만, 그럼에도 불구하고 파일 시스템은 물리 스토리지 시스템의 추상이고, 이에 따라, 파일의 사용은 사용자가 조작하는 것(문맥, 특징 및 다른 단위와의 관계를 갖는 단위)과 운영 체제가 제공하는 것(파일, 폴더 및 디렉토리) 사이의 간접 레벨(해석)을 요구한다. 결과적으로, 사용자(애플리케이션 및/또는 최종 사용자)는 비효율적이고, 비지속적이며, 또는 바람직하지도 않은 것을 행할 때에도 정보 단위를 파일 시스템 구조로 할 수 밖에 없다. 더욱이, 기존 파일 시스템은 개별 파일에 저장된 데이터의 구조에 대하여 거의 알지 못하고, 이로 인해 대부분의 정보는 이들을 기입한 애플리케이션에만 액세스될 수 있는(그리고 이해될 수 있는) 파일로 고정된다. 결과적으로, 이러한 정보의 개략적 설명의 부족과 정보 관리 메커니즘은 개별 저장고 사이의 데이터를 거의 공유하지 않고 데이터의 저장고의 생성을 유도한다. 예를 들면, 다수의 개인용 컴퓨터(PC) 사용자는 파일 구성은 상당한 변경을 이들 PC 사용자에게 제공하기 때문에 특정 레벨에서 상호동작하는 사람에 대한 정보를 포함하는 5개의 고유 저장소 - 예를 들면, 아웃룩 컨택, 온라인 계정 주소, 윈도우즈 주소록, 퀵 수취인(Quicken Payees) 및 인스턴트 메시징(IM) 버 디 리스트를 갖는다. 대부분의 기존 파일 시스템은 파일 및 폴더 구성을 위한 중첩 폴더 메타포어를 사용하기 때문에, 파일 수가 증가함에 따라 유연하고 효율적인 구성 방식을 유지하는데 필요한 노력은 매우 많아지게 된다. 이러한 상황에서, 단일 파일의 여러 분류를 갖는 것이 매우 유용하지만, 기존 파일 시스템에서 하드 또는 소프트 링크를 사용하는 것은 번거롭고 유지하기 어렵다.

파일 시스템의 단점을 해결하려는 성공하지 못한 여러 시도가 과거에 시도되었다. 이들 종래 시도 중 일부는 컨텐츠 어드레서블 메모리(content addressable memory)를 사용하여 물리적 주소가 아닌 컨텐츠에 의해 데이터가 액세스될 수 있는 메커니즘을 제공하는 것에 관한 것이다. 그러나, 이들 노력은 컨텐츠 어드레서블 메모리가 캐시와 메모리 관리 단위와 같이 장치별 소규모 사용에 유용하지만 물리적 저장 매체와 같은 장치의 대규모 사용은 다양한 이유로 가능하지 않기 때문에 성공적이지 않은 것으로 증명되었으며, 이에 따라, 솔루션이 존재하지 않는다. 객체 지향 데이터베이스(OODB)를 사용하는 다른 시도가 행해지고 이들 시도는 강한 데이터베이스 특성과 양호한 비파일(non-file) 표현을 특징으로 하지만, 파일 표현을 처리하는 데는 유효하지 않고 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 파일 및 폴더 기반 계층 구조의 속도, 효율성 및 단순성을 복제할 수는 없다. SmallTalk(및 다른 변형)를 사용하는 등의 다른 노력은 파일 및 비파일 표현 처리에 매우 유용한 것으로 증명되었지만 여러 데이터 파일 간에 존재하는 관계를 효율적으로 구성하고 및 사용하는 데에 필수적인 데이터베이스 특성을 결여하기 때문에 이러한 시스템의 전체 효율성은 수용할 수 없는 것이었다. BeOS(및 다른 이러한 운영 체제 연구)를 사용하는 다른 시도는 몇몇 필수적인 데이터베이스 특성을 제공하면서 파일을 적절하게 표현할 수 있더라도, 비파일 표현 처리에 부적절한 것으로 증명되었다 - 종래 파일 시스템의 결정적인 단점 -.

데이터베이스 기술은 유사한 도전이 존재하는 다른 기술 분야이다. 예를 들면, 관계 데이터베이스 모델이 상당한 상업적인 성공을 거두었지만, 실제 독립 소프트웨어 벤더(ISV)는 통상 관계 데이터베이스 소프트웨어 제품(마이크로소프트 SQL 서버)에서 이용가능한 기능의 일부분을 실행한다. 그 대신, 이러한 제품과의 애플리케이션 상호동작의 대부분은 단순히 "gets" 및 "puts"의 형태이다. 이에 대해 여러 명백한 이유가 있지만 - 플랫폼이거나 데이터베이스 어그나스틱(data agnostic) 등 -, 종종 주목되지 않은 주요 이유 중 하나는 주요 비즈니스 애플리케이션 벤더가 실제 필요로 하는 정확한 추상화를 반드시 제공할 필요가 없다는 점이다. 예를 들면, 실제 세계는 (항목으로서 주문의 임베디드 "라인 항목"과 함께)"고객" 또는 "주문"과 같은 "항목"의 관념을 갖지만, 관계 데이터베이스는 표와 행으로 표현한다. 그 결과, 애플리케이션은 항목 레벨에서(몇몇을 예로 들면) 일정성, 고정, 보안 및/또는 트리거의 양태를 갖게 하는 것이 바람직하지만, 통상 데이터베이스는 표/행 레벨에서만 이들 특성을 제공한다. 이는 각 항목이 데이터베이스에서 몇몇 표의 단일 행에 매핑되면 잘 동작하지만, 여러 라인 항목이 있는 주문이 있는 경우, 한 항목이 여러 표에 매핑되기 때문일 수 있으며, 이러한 경우에는, 단순 관계 데이터베이스는 올바른 추상화를 제공하지 않는다. 결과적으로, 애플리케이션은 데이터베이스의 정상에서 논리를 구축하여 이들 기본 추상화를 제공해야 만 한다. 다시 말하면, 기본 관계 모델은 기본 관계 모델이 애플리케이션과 스토리지 시스템 간에 간접 레벨 - 데이터의 의미 구조가 특정 인스턴스에서 애플리케이션에만 가시적인 경우 -을 요구하기 때문에 보다 높은 레벨의 애플리케이션이 용이하게 개발될 수 있는 데이터의 스토리지에 대한 충분한 플랫폼을 제공하지는 않는다. 몇몇 데이터베이스 벤더는 보다 높은 레벨의 기능을 이들 제품에 구축하지만 - 객체 관계 성능, 새로운 구성 모델 등의 제공 -, 어느 것도 실제로 충분한 솔루션이 유용한 도메인 추상화("사람(Persons)", "위치(Locations)", "이벤트(Events)")에 대한 데이터 모델 추상화("항목(Items", "Extensions", "Relationships" 등)를 제공하는 것인, 필요한 광범위한 솔루션 종류를 제공하지는 않는다.

기존 데이터 스토리지 및 데이터베이스 기술에서의 상기 단점의 관점에서, 컴퓨터 시스템에서 모든 종류의 데이터를 구성, 검색 및 공유할 개선된 능력을 제공하는 새로운 스토리지 플랫폼이 요구된다 - 기존 파일 시스템과 데이터베이스 시스템을 넘어서서 데이터 플랫폼을 연장하고 확장하하여 모든 데이터 유형에 대한 저장소로 설계되는 스토리지 플랫폼 -. 2003년 8월 21일에 출원되고 발명의 명칭이 "STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA"인 미국 특허출원번호 제10/646,646호(대리인 정리번호 MSFT-2734)에 개시된 발명은 이러한 요구를 충족한다. 이러한 스토리지 플랫폼에 대한 동기화 서비스는 2003년 10월 24일에 출원되고 발명의 명칭이 "SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION AND MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"에 더 제공된다. 본 발명의 여러 실시예는 개시된 스토리지 플랫폼에 대하여 개시된 동기화 서비스에 대한 충돌 처리하는 시스템 및 방법 뿐 아니라 본 시스템 및 방법이 적용될 수 있는 다른 동기화 서비스 및/또는 다른 스토리지 플랫폼에 대한 시스템 및 방법에 관한 것이다.

후술하는 요약은 이전에 여기서 참조로 포함된 관련 발명("관련 발명")의 경우에 나타내는 발명의 여러 양태의 개요를 제공한다. 이 요약은 본 발명의 모든 중요 양태를 모두 제공하려는 것이 아니고 본 발명의 범위를 한정하려는 것도 아니다. 그 대신, 이 요약은 후술하는 상세한 설명과 도면에 대한 도입부로서 역할한다.

본 발명은 기존 파일 시스템 및 데이터베이스 시스템을 넘어서 데이터 스토리지의 개념을 확장 및 넓히는 데이터의 구성, 검색 및 공유를 위한 스토리지 플랫폼에 관한 것이다. 이러한 스토리지 플랫폼은 구조화, 비구조화, 반구조화(semi-structured) 데이터 등의 모든 유형의 데이터에 대한 저장소로 설계된다.

스토리지 플랫폼은 데이터베이스 엔진 상에 구현된 데이터 저장소를 포함한다. 데이터베이스 엔진은 객체 관계 확장을 구비하는 관계 데이터베이스를 포함한다. 데이터 저장소는 데이터의 구성, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델을 구현한다. 특정 유형의 데이터는 스키마로 나타내며, 플랫폼은 새로운 데이터 유형(기본 유형의 실질적 서브타입은 스키마 별로 제공)을 한정하는 스키마 유형을 확장한 메커니즘을 제공한다. 동기화 성능은 사용자 또는 시스템 간 의 데이터 공유를 용이하게 한다. 기존 파일 시스템과의 데이터 저장소의 상호 운용성을 가능하게 하지만 이러한 종래 파일 시스템을 한정하지 않는 파일 시스템형 성능이 제공된다. 데이터 추적 메커니즘은 데이터 저장소에 대한 변경을 추적하는 능력을 제공한다. 또한, 스토리지 플랫폼은 애플리케이션이 스토리지 플랫폼의 상술한 모든 설명을 액세스하고 이 스키마로 표현된 데이터를 액세스할 수 있게 하는 일련의 애플리케이션 프로그램 인터페이스를 포함한다.

데이터 저장소로 구현된 데이터 모델은 항목, 요소 및 관계에 의해 데이터 저장소 단위를 한정한다. 항목은 데이터 저장소에서 저장가능한 데이터 단위이며, 하나 이상의 요소 및 관계를 포함할 수 있다. 요소는 하나 이상의 필드(또한, 여기서는 속성으로 불림)를 포함하는 유형의 인스턴스이다. 관계는 두 항목 간의 링크이다. (여기서 사용되는 바와 같이, 이들 및 다른 특정 용어는 매우 유사하게 사용되는 다른 용어와 이들을 구별하기 위해서 대문자로 시작할 수 있지만, 대문자로 시작하는 용어, 예를 들면, 항목(Item) 및 동일한 용어이지만 대문자로 시작하지 않는 용어, 예를 들면, 아이템(item) 사이를 구별할 의도는 없으며, 어떤 이러한 구분도 가정 또는 암시되지 않는다).

또한, 컴퓨터 시스템은 각 항목이 하드웨어/소프트웨어 인터페이스 시스템에 의해 조작될 수 있는 정보의 개별 저장가능 단위를 구성하는 복수의 항목; 상기 항목에 대한 구성 구조(organizational structure)를 구성하는 복수의 항목 폴더; 및 복수의 항목을 조작하는 하드웨어/소프트웨어 인터페이스 시스템을 포함하며, 각 항목은 적어도 하나의 항목 폴더에 속하며 하나 이상의 항목 폴더에 속할 수 있 다.

항목 또는 몇몇 항목 속성값은 영구 저장소로 유도되는 것과 달리 동적으로 계산될 수 있다. 다시 말하면, 하드웨어/소프트웨어 인터페이스 시스템은 항목이 저장되는 것을 요구하지 않고, 현재 항목 세트를 열거하는 능력 또는 스토리지 플랫폼의 식별자가 주어진 항목 - 예를 들면, 온도 센서 상의 온도 판독 또는 셀룰러 폰의 현재 위치일 수 있는 항목 -을 검색하는 능력 등과 같은 특정 동작이 지원된다. 하드웨어/소프트웨어 인터페이스 시스템은 복수의 항목을 조작할 수 있으며, 이 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리되는 복수의 상호 관계에 의한 항목을 더 포함할 수 있다.

이 컴퓨터 시스템에 대한 하드웨어/소프트웨어 인터페이스 시스템은 상기 하드웨어/소프트웨어 인터페이스 시스템이 미리 결정되고 소정의 방식으로 프로세스를 이해하고 직접 처리할 수 있는 일련의 코어 항목을 한정하는 코어 스키마를 더 포함한다. 복수의 항목을 조작하기 위해서, 컴퓨터 시스템은 복수의 관계로 상기 항목을 직접 접속하여 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 상기 관계를 관리한다.

스토리지 플랫폼의 API는 일련의 스토리지 플랫폼 방식에 한정된 항목, 항목 확장자 및 관계 각각에 대한 데이터 클래스를 제공한다. 또한, 애플리케이션 프로그래밍 인터페이스는 데이터 클래스에 대한 동작의 공동 세트를 한정하고, 데이터 클래스와 함께 스토리지 플랫폼 API에 대한 기본 프로그래밍 모델을 제공하는 일련의 프레임워크 클래스를 제공한다. 스토리지 플랫폼 API은, 하부 데이터베이스 엔 진의 조회 언어의 세부사항으로부터 애플리케이션 프로그래머를 차단하는 방식으로, 애플리케이션 프로그래머가 데이터 저장소의 항목의 여러 속성에 따라 조회를 구성할 수 있게 하는 단순 조회 모델을 제공한다. 또한, 스토리지 플랫폼 API은 애플리케이션 프로그램에 의해 행해진 아이템에 대한 변경을 수집한 후 이들을 데이터 저장소가 구현된 데이터베이스 엔진(또는 임의 종류의 스토리지 엔진)에 의해 요구되는 올바른 갱신으로 구성한다. 이는 애플리케이션 프로그래머가 메모리 내의 아이템에 대한 변경이 가능하지만, API에 대한 데이터 저장소 갱신을 복잡하게 한다.

이의 공통 스토리지 기반 및 도식화된 데이터에도 불구하고, 본 발명의 스토리지 플랫폼은 소비자, 지식 근로자 및 기업에 대해 보다 효율적인 애플리케이션 개발을 가능하게 한다. 이는 데이터 모델에 내재되어 있는 성능을 이용가능하게 할 뿐만 아니라 기존 파일 시스템과 데이터베이스 액세스 방법을 포함 및 확장하는 풍부하고 확장가능한 애플리케이션 프로그래밍 인터페이스를 제공한다.

이러한 상호관련 발명 전체를 지배하는 구조물의 일부로서(상세한 설명의 단락 II에 상세히 설명함), 관련 발명의 중 일부는 특히 API의 동기화에 관한 것으로서(상세한 설명의 단락 III에 상세히 설명함), 이는 스토리지 플랫폼의 광범위한 동기화 성능을 나타낸다. 본 발명의 여러 실시예는 피어 대 피어 동기화동안 발생하는 충돌을 처리하기 위해 이들 동기화 성능에 포함될 수 있다.

충돌을 정확하고 효율적으로 처리하는 능력은 양호한 사용가능성을 유지하고 동기화 동안 사용자 중재의 요구를 감소시키면서 데이터 손실을 최소화한다. 상세 한 설명의 단락 IV은 관련 발명의 스토리지 플랫폼의 동기화 시스템을 포함하지만 이에 한정되지 않는 피어 대 피어 동기화 시스템에서 충족을 처리하는 것에 관한 본 발명의 다양한 실시예의 상세한 설명을 제공한다. 다양한 실시예는 (a) 충돌 처리를 위한 공통의 확장가능 스키마를 설정하고 (b) 충돌이 검출되고 해결되고 결국에는 제거되는 것으로 진행함에 따라 충돌을 나타내는 상태를 추적하여, 피어 대 피어 동기화 시스템에서 발생하는 충돌을 나타내는 솔루션을 제공한다. 여러 실시예의 주요 특징은 이들 상술한 상태를 통해 진행함에 따라 충돌을 추적하는 능력뿐만 아니라 해결된 충돌의 자동 제거를 수행하는 능력을 포함한다. 특정 실시예는 쓸모없는 충돌(제거된 변경을 나타내는 충돌)을 검출하는 능력과 이에 따라 충돌을 제거하는 능력을 포함한다. 다른 실시예는 충돌 해결 정책을 사용하여 충돌을 동기적으로 자동 해결하는 것에 관한 것이다. 마지막으로, 그러나 덜 중요한 것은 아닌, 특정 실시예는 또한 사용자에 의해 추후 해결을 위해 로그되었던 충돌을 프로그램으로 해결하는 능력을 포함할 수 있다(사용자 지정 충돌 해결을 수행하도록 사용자 인터페이스에 의해 사용될 수 있음).

본 발명의 구체적 특성 및 이점은 단독으로 또는 관련 발명과 함께 후술하는 발명의 상세한 설명과 첨부 도면으로부터 명확하게 될 것이다.

상기 요약뿐만 아니라 본 발명의 후술하는 상세한 설명은 첨부 도면과 함께 참조하여 보다 잘 이해된다. 본 발명을 나타내기 위해서, 본 발명의 다양한 양태의 예시적인 실시예가 도시되지만, 본 발명은 개시된 특정 방법 및 도구에 한정되지 않는다.

I. 도입

본 발명의 주요 사상은 법정 요건을 충족하기 위해 구체적으로 설명한다. 그러나, 이 설명 자체는 본 발명의 범위를 한정하려는 것은 아니다. 그 대신, 본 발명은 청구한 주요 사상이 다른 방식으로 구체화되어 다른 현존하거나 장래 기술과 함께, 본 문서에 설명된 것과 상이한 단계 또는 유사한 단계의 조합을 포함할 수 있다. 더욱이, "단계"라는 용어는 사용되는 방법의 상이한 요소를 지칭하도록 사용될 수 있지만, 이 용어는 개별 단계의 순서가 명시적으로 나타내지 않는 한 여기서 개시된 여러 단계 중에서 임의의 특정 순서를 암시하는 것으로서 해석되어서는 안 된다.

A. 예시적인 컴퓨팅 환경

본 발명의 수많은 실시예는 컴퓨터 상에서 실행할 수 있다. 도 1과 후술하는 설명은 본 발명이 구현될 수 있는 적절한 컴퓨팅 환경의 간략하고 일반적인 설명을 제공하려는 것이다. 비록 필수적인 것은 아니지만, 본 발명의 다양한 양태는 클라이언트 워크스테이션 또는 서버 등의 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령의 일반적인 경우에 대하여 설명될 수 있다. 통상, 프로그램 모듈은 수행하거나 특정 추상 데이터형을 수행하는 등의 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 및 특정 작업을 포함한다. 더욱이, 본 발명은 핸드헬드 장치, 멀티 프로세스 시스템, 마이크로프로세스 기반 또는 프로그램가능한 소비자 전자제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등의 다른 컴퓨터 시 스템 구성을 사용하여 실시될 수 있다. 또한, 본 발명은 통신 네트워크를 통해 연결된 원격 처리 장치에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 스토리지 장치에 배치될 수 있다.

도 1에 도시한 바와 같이, 예시적인 범용 컴퓨팅 시스템은 처리 장치(21), 시스템 메모리(22) 및 시스템 메모리 등의 여러 시스템 컴포넌트를 처리 장치(21)에 결합하는 시스템 버스(23)를 포함하는 통상의 개인용 컴퓨터(20)를 포함한다. 시스템 버스(23)는 메모리 버스 또는 메모리 제어기, 주변 버스 및 다양한 버스 구조 중 임의의 것을 사용하여 로컬 버스를 포함하는 여러 유형의 버스 구조일 수 있다. 시스템 메모리는 판독 전용 메모리(ROM; 24)와 랜덤 액세스 메모리(RAM; 25)를 포함한다. 기본 입출력 시스템(26; BIOS)은 시동 동안과 같이 개인용 컴퓨터(20) 내의 요소들 간에 정보를 전송할 수 있게 하는 기본 루틴을 포함하여, ROM(24)에 저장된다. 또한, 개인용 컴퓨터(20)는 도시하지는 않았지만 하드 디스크로부터 판독하고 이에 기입하는 하드 디스크 드라이브(27), 분리형 자기 디스크(29)로부터 판독하거나 이에 기입하는 자기 디스크 드라이브(28), 및 CD ROM 또는 다른 강 매체와 같은 분리형 광 디스크(31)로부터 판독하거나 이에 기입하는 광 디스크 드라이브(30)를 포함할 수 있다. 하드 디스크 드라이브(27), 자기 디스크 드라이브(28), 및 광 디스크 드라이브(30)는 하드 디스크 드라이브 인터페이스(32), 자기 디스크 드라이브 인터페이스(33) 및 광 디스크 인터페이스(34)에 의해 각각 시스템 버스(23)에 연결된다. 드라이브 및 이들의 관련 컴퓨터 판독가능 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 및 개인용 컴퓨터(20)에 대한 다른 데이터의 비휘발성 스토리지를 제공한다. 여기서 설명하는 예시적인 환경은 하드 디스크, 분리형 자기 디스크(29) 및 분리형 광 디스크(31)를 사용하지만, 자기 카세트, 플래시 메모리 카드, 디지털 비디오 디스크, 베르누이 카트리지, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM) 등과 같이 컴퓨터에 의해 액세스가능한 데이터를 저장할 수 있는 다른 유형의 컴퓨터 판독가능 매체는 예시적인 운영 환경에서 사용될 수 있음을 당업자는 이해하여야 한다. 이와 같이, 또한, 예시적인 환경은 열 센서 및 보안 또는 화재 경보 시스템, 그리고 다른 정보 소스와 같은 장치를 감시하는 다른 유형을 포함한다.

다수의 프로그램 모듈은 운영 체제(35), 하나 이상의 애플리케이션 프로그램(36), 기타 프로그램 모듈(37), 및 프로그램 데이터(38) 등을 포함하여 하드 디스크, 자기 디스크(29), 광 디스크(31), ROM(24) 또는 RAM(25)에 저장될 수 있다. 사용자는 키보드(40) 및 포인팅 장치(42)와 같은 입력 장치를 통해 개인용 컴퓨터(20)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(미도시)는 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너 등을 포함할 수 있다. 이들 및 다른 입력 장치는 종종 시스템 버스에 결합되는 직렬 포트 인터페이스(46)를 통해 처리 장치(21)에 연결되지만, 병렬 포트, 게임 포트 또는 범용 직렬 버스(USB)와 같은 다른 인터페이스에 의해 연결될 수 있다. 모니터(47) 또는 다른 유형의 디스플레이 장치는 또한 비디오 어댑터(48)와 같은 인터페이스를 통해 시스템 버스(23)에 연결된다. 모니터(47)에 더하여, 개인용 컴퓨터는 통상 스피커와 프린터와 같은 다른 주변 출력 장치(미도시)를 포함한다. 도 1의 예시적인 시스템은 호스트 어댑터(55), 소형 컴퓨터 시스템 인터페이스(SCSI) 버스(56), 및 SCSI 버스(56)에 연결된 외부 스토리지 장치(62)를 포함한다.

개인용 컴퓨터(20)는 원격 컴퓨터(49)와 같은 하나 이상의 원격 컴퓨터에 대한 논리적 접속을 사용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(49)는 다른 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 메모리 스토리지 장치(50)만 도 1에 도시되어 있지만 개인용 컴퓨터(20)에 대하여 상술한 다수의 또는 모든 요소를 포함한다. 도 1에 도시된 논리적 접속은 근거리 네트워크(LAN; 51)와 광역 네트워크(WAN; 52)를 포함한다. 이러한 네트워킹 환경은 사무실, 범사내망, 인트라넷 및 인터넷에서 흔한 것이다.

LAN 네트워킹 환경에서 사용되는 경우, 개인용 컴퓨터(20)는 네트워크 인터페이스 또는 어댑터(53)를 통해 LAN(51)에 연결된다. WAN 네트워킹 환경에서 사용되는 경우, 개인용 컴퓨터(20)는 통상 인터넷과 같은 광역 네트워크(52) 상으로 통신을 설정하는 모뎀(54) 또는 다른 수단을 포함한다. 모뎀(54)은 내장형 또는 외장형일 수 있으며 직렬 포트 인터페이스(46)를 통해 시스템 버스(23)에 접속된다. 네트워크화된 환경에서, 개인용 컴퓨터(20) 또는 그 일부에 대하여 도시된 프로그램 모듈이 원격 메모리 스토리지 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적이며 컴퓨터 간의 통신을 설정하는 다른 수단이 사용될 수 있다.

도 2의 블록도에서 나타낸 바와 같이, 컴퓨터 시스템(200)은 3개의 컴포넌트 그룹, 즉, 하드웨어 컴포넌트(202), 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204) 및 애플리케이션 프로그램 컴포넌트(206)(여기서의 특정 경우 "사용자 컴포넌트" 또는 "소프트웨어 컴포넌트"로 불림)로 대략 나뉠 수 있다.

컴퓨터 시스템(200)의 다양한 실시예에서, 도 1을 다시 참조하면, 하드웨어 컴포넌트(202)는 중앙 처리 장치(CPU; 21), 메모리(ROM(24)과 RAM(25)), 기본 입출력 시스템(BIOS; 26), 및 키보드(40), 마우스(42), 모니터(47) 및/또는 프린터(미도시) 등의 다양한 입출력(I/0) 장치를 포함할 수 있다. 하드웨어 컴포넌트(202)는 컴퓨터 시스템(200)에 대한 기본 물리적 기반구조를 포함한다.

애플리케이션 프로그램 컴포넌트(206)는 컴파일러, 데이터베이스 시스템, 워드 프로세서, 비즈니스 프로그램, 비디오 게임 등을 포함하지만 이에 한정되지 않은 다양한 소프트웨어 프로그램을 포함한다. 애플리케이션 프로그램은 컴퓨터 자원이 문제를 해결하고, 솔루션을 제공하여 다양한 사용자(머신, 다른 컴퓨터 시스템 및/또는 최종 사용자)에 대한 데이터를 처리하는데 사용된다.

하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204)는 대부분의 경우 쉘 및 커널을 자체적으로 포함하는 운영 체제를 포함한다. "운영 체제(OS)"는 애플리케이션 프로그램과 컴퓨터 하드웨어 간의 중간단계로서 동작하는 특정 프로그램이다. 또한, 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204)는 가상 머신 관리자(VMM), 공통 언어 런타임(CLR) 또는 이의 기능적 등가물, 자바 가상 머신(JVM) 또는 이의 기능적 등가물, 또는 컴퓨터 시스템 내의 운영 체제를 대신하여 또는 이에 추가되는 다른 소프트웨어 컴포넌트를 포함할 수 있다. 하드웨어/소프트웨어 인터페이스 시스템의 목적은 사용자가 애플리케이션 프로그램을 실행할 수 있는 환경을 제공하는 것이다. 임의의 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 시스템이 사용하기 편리할 뿐만 아니라 효율적인 방식으로 컴퓨터 하드웨어를 사용하는 것이다.

하드웨어/소프트웨어 인터페이스 시스템은 통상 시동 시에 컴퓨터 시스템에 로딩되고 그 후 컴퓨터 시스템에서 모든 애플리케이션 프로그램을 관리한다. 애플리케이션 프로그램은 애플리케이션 프로그램 인터페이스(API)를 통해 서비스를 요청함으로써 하드웨어/소프트웨어 인터페이스에 상호 동작한다. 몇몇 애플리케이션 프로그램은 최종 사용자가 공통 언어 또는 그래픽 사용자 인터페이스(API)와 같은 사용자 인터페이스를 통해 하드웨어/소프트웨어 인터페이스 시스템을 상호동작할 수 있게 한다.

하드웨어/소프트웨어 인터페이스 시스템은 종래 애플리케이션에 대한 다양한 서비스를 수행한다. 여러 프로그램이 동시에 동작할 수 있는 멀티태스킹 하드웨어/소프트웨어 인터페이스 시스템에서, 하드웨어/소프트웨어 인터페이스 시스템은 어느 순서로 애플리케이션이 실행되어야 하는지 또는 전환을 위해 다른 애플리케이션으로 스위치하기 전에 각 애플리케이션에 대하여 또는 얼마나 많은 시간이 할당되어야 하는지를 결정한다. 또한, 하드웨어/소프트웨어 인터페이스는 여러 애플리케이션 중에서 내부 메모리의 공유를 관리하고, 하드 디스크, 프린터 및 다이얼업 포트와 같은 부착된 하드웨어 장치에 그리고 이로부터의 입출력을 처리한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 발생될 수 있는 동작 상태 및 임의의 에 러에 대하여 각 애플리케이션(몇몇 경우, 최종 사용자에 대하여)에 메시지를 전송한다. 또한, 하드웨어/소프트웨어 인터페이스 시스템은 개시애플리케이션은 이 작업에서 부담을 덜어 다른 처리 및/또는 동작을 재개하는 배치 작업(예를 들면, 프린팅)의 관리를 오프로드할 수 있다. 병렬 처리를 제공할 수 있는 컴퓨터 상에서, 하드웨어/소프트웨어 인터페이스 시스템은 또한 프로그램 분할을 관리하여 하나 이상의 프로세스를 한번에 동작시킨다.

하드웨어/소프트웨어 인터페이스 시스템 쉘(간단히 "쉘"이라 부름)은 하드웨어/소프트웨어 인터페이스 시스템으로의 대화형 최종 사용자 인터페이스이다. (쉘은 또한 "명령 인터프리터"로서, 또는 운영 체제에서 "운영 체제 쉘"로서 불릴 수 있다). 쉘은 애플리케이션 프로그램 및/또는 최종 사용자에 의해 직접 액세스가능한 하드웨어/소프트웨어 인터페이스 시스템의 외부 층이다. 쉘과 달리, 커널은 하드웨어 컴포넌트와 직접 상호동작하는 하드웨어/소프트웨어 인터페이스 시스템의 최내층이다.

본 발명의 다양한 실시예는 컴퓨터화된 시스템에 특히 적합하지만, 본 문서의 어느 것도 이러한 실시예에 본 발명을 한정시키려는 것은 아니다. 이와 달리, "컴퓨터 시스템"이라는 용어를 여기서 사용되는 바와 같이, 이러한 장치가 본래 전자, 기계, 논리 또는 가상적인 것에 관계없이 정보를 저장 및 처리할 수 있고 및/또는 저장된 정보를 사용하여 장치 자체의 동작 또는 실행을 제어할 수 있는 임의의 모든 장치를 포함시키려는 것이다.

B. 종래 파일 기반 스토리지

오늘날 대부분의 컴퓨터 시스템에서, "파일"은 애플리케이션 프로그램, 데이터 세트뿐만 아니라 하드웨어/소프트웨어 인터페이스 시스템을 포함할 수 있는 저장가능 정보의 단위이다. 모든 현대의 하드웨어/소프트웨어 인터페이스(윈도우즈, 유닉스, 리눅스, 맥 OS, 가상 머신 시스템 등)에서, 파일은 하드웨어/소프트웨어 인터페이스 시스템에 의해 작성가능한 기본 개별(저장가능하고 검색가능한) 정보 단위(예를 들면, 데이터, 프로그램 등)이다. 파일 그룹은 "폴더"로 통상 구성된다. 마이크로소프트 윈도우즈, 매킨토시 OS 및 다른 하드웨어/소프트웨어 인터페이스 시스템에서, 폴더는 단일 정보 단위로서 검색, 이동 및 조작될 수 있는 파일 모음이다. 또한, 이들 폴더는 "디렉토리"로 불리는 트리 기반 계층 배치로 구성된다(이하 보다 상세히 설명함). DOS, z/OS 및 대부분의 유닉스 기반 운영 체제와 같은 다른 특정 하드웨어/소프트웨어 인터페이스 시스템에서, "디렉토리" 및/또는 "폴더"라는 용어는 교환가능하며, 초기 애플 컴퓨터 시스템(예를 들면, 애플 IIe)는 디렉토리 대신에 "카탈로그"라는 용어를 사용하지만, 여기서 사용되는 바와 같이, 이들 모든 용어는 동의어로서 서로 교환가능한 것으로 여겨지며 계층 정보 스토리지 구조 및 이들의 폴더 및 파일 컴포넌트에 대한 모든 다른 등가 용어 및 참조를 포함하려는 것이다.

종래, 디렉토리(또는 폴더의 디렉토리)는 트리 기반 계층 구조로서, 파일은 폴더로 그룹화되고, 이에 따라 폴더는 디렉토리 트리를 포함하는 상대 노드 위치에 따라 배치된다. 예를 들면, 도 2a에 나타낸 바와 같이, DOS 기반 파일 시스템 폴더(또는 "루트 디렉토리"; 212)는 복수의 폴더(214)를 포함할 수 있으며, 이들 각 각은 추가 폴더(특정 폴더의 "서브폴더; 216), 이들은 각각 또한 무한히 추가 폴더(218)를 포함할 수 있다. 이들 폴더 각각은 하드웨어/소프트웨어 인터페이스 시스템에서 폴더 내의 개별 파일이 트리 계층에서의 위치 이외에는 공통점이 갖고 있지 않더라도, 하나 이상의 파일(220)을 가질 수 있다. 놀랍지 않게도, 폴더 계층으로의 이러한 파일 구성은 이들 파일을 저장하는데 사용되는 통상의 저장 매체의 물리적 구성을 간접 반영한다(예를 들면, 하드 디스크, 플로피 디스크, CD-ROM 등).

상기의 것에 더하여, 각 폴더는 이의 서브폴더와 파일에 대한 포함자(container)이며, 즉, 각 폴더는 서브폴더와 파일을 소유한다. 예를 들면, 폴더가 하드웨어/소프트웨어 인터페이스 시스템에 의해 삭제되면, 폴더의 서브폴더와 파일 또한 삭제된다(각 서브폴더의 경우, 자신의 서브폴더와 파일을 순환적으로 더 포함한다). 유사하게, 각 파일은 단지 하나의 폴더에 의해 통상 소유되고, 파일이 복사되어 상이한 폴더에 배치되는 경우에도, 파일의 복사본 자체는 원본과 직접적 연결이 없는 고유하고 개별 단위이다(예를 들면, 원본 파일의 변경은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 복사 파일에 반영되지 않는다). 이에 대하여, 파일 및 폴더는 폴더가 물리적 포함자로서 처리되고 파일이 이들 포함자 내의 고유하고 개별적인 물리적 요소로서 처리되기 때문에 본래 특성상 "물리적"이다.

II. 데이터를 구성, 검색 및 공유하는 WINFS 스토리지 플랫폼

여기서 상술한 바와 같이 참조로 포함된 관련 발명과 결합하여, 본 발명은 데이터의 구성, 검색 및 공유를 위한 스토리지 플랫폼에 관한 것이다. 본 발명의 스토리지 플랫폼은 상술한 기존 파일 시스템과 데이터베이스 시스템 종류를 넘어서 데이터 플랫폼을 확장하고 넓히며, 항목으로 불리는 새로운 데이터 유형 등 모든 데이터 유형에 대한 저장소로서 설계된다.

A. 용어집

여기서 그리고 청구항에서 사용되는 바와 같이, 다음 용어는 다음과 같은 의미를 갖는다:

"항목"는, 하드웨어/소프트웨어 시스템에 액세스가능한 저장가능 정보 단위로서, 단순 파일과는 달리 하드웨어/소프트웨어 인터페이스 시스템 쉘에 의해 최종 사용자에게 노출된 모든 객체에 걸쳐 공통 지원되는 기본 속성 세트를 갖는 객체이다. 또한, 항목은 새로운 속성 및 관계를 도입될 수 있게 하는 특징 등 모든 항목 유형에 걸쳐 공통 지원되는 속성 및 관계를 갖는다(보다 상세하게 후술함).

"운영 체제(OS)"는 애플리케이션 프로그램과 컴퓨터 하드웨어 간의 중간 단계로서 동작하는 특별 프로그램이다. 운영 체제는 대부분의 경우 쉘 및 커널을 포함한다.

"하드웨어/소프트웨어 인터페이스 시스템"은 컴퓨터 시스템 상에서 실행하는 컴퓨터 시스템 및 애플리케이션의 하부 하드웨어 컴포넌트 간의 인터페이스로서 동작하는 소프트웨어, 또는 하드웨어/소프트웨어 조합이다. 하드웨어/소프트웨어 인터페이스 시스템은 통상운영 체제를 포함한다(몇몇 실시예에서는 운영 체제로만 이루어진다). 하드웨어/소프트웨어 인터페이스 시스템은 또한 가상 머신 관리자(VMM), 공통 언어 런타임(CLR) 또는 이의 기능적 등가물, 자바 가상 머신(JVM) 또는 이의 기능적 등가물, 또는 컴퓨터 시스템 내의 운영 체제에 대신하여 또는 이에 추가하여 이러한 다른 소프트웨어 컴퓨터를 포함할 수 있다. 하드웨어/소프트웨어 인터페이스 시스템의 목적은 사용자가 애플리케이션 프로그램을 사용할 수 있는 환경을 제공하는 것이다. 임의의 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 시스템은 사용하기 편리하게 할 뿐만 아니라 효율적인 방식으로 컴퓨터 하드웨어를 사용할 수 있게 하는 것이다.

B. 스토리지 플랫폼 개관

도 3을 참조하면, 스토리지 플랫폼(300)은 데이터베이스 엔진(314) 상에 구현된 데이터 저장소(302)를 포함한다. 일 실시예에서, 데이터베이스 엔진은 객체 관계 확장을 구비한 관계 데이터베이스 엔진을 포함한다. 일 실시예에서, 관계 데이터베이스 엔진(314)은 마이크로소프트 SQL 서버 관계 데이터베이스 엔진을 포함한다. 데이터 저장소(302)는 데이터의 구성, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델(304)을 구현한다. 특정 데이터형은 스키마(340)와 같은 스키마로 나타내며, 스토리지 플랫폼(300)은 보다 완전히 후술하는 바와 같이 이들 스키마를 배치할 뿐만 아니라 이들 스키마를 확장하는 도구(346)를 제공한다.

데이터 저장소(302) 내에 구현된 변경 추적 메커니즘(306)은 데이터 저장소에 변경 추적 능력을 제공한다. 데이터 저장소(302)는 또한 보안 성능(308)과 프로모션(promotion)/디모션(demotion) 성능(310)을 제공하며, 이들은 보다 상세히 후술한다. 또한, 데이터 저장소(302)는 데이터 저장소(302)의 성능 스토리지 플랫폼을 사용하는 다른 스토리지 플랫폼 컴포넌트 및 애플리케이션 프로그램(예를 들면, 애플리케이션 프로그램(350a, 350b 및 350c)에 노출시키는 일련의 애플리케이 션 프로그래밍 인터페이스(312)를 제공한다. 본 발명의 스토리지 플랫폼은, 애플리케이션 프로그램(350a, 350b 및 350c)과 같은 애플리케이션 프로그램이 스토리지 플랫폼의 상기 성능 모두를 액세스하고 스키마에 나타낸 데이터를 액세스할 수 있게 하는 애플리케이션 프로그래밍 인터페이스(API; 322)를 더 포함한다. 스토리지 플랫폼 API(322)는 OLE DB API(324) 및 마이크로소프트 윈도우즈 Win32 API(326)와 같은 다른 API와 함께 애플리케이션 프로그램에 의해 사용될 수 있다.

본 발명의 스토리지 플랫폼(300)은 사용자 또는 시스템 사이에서 데이터의 공유를 용이하게 하는 동기화 서비스(330) 등의 애플리케이션 프로그램에 다양한 서비스(328)를 제공할 수 있다. 예를 들면, 동기화 서비스(330)는 데이터 저장소(302)와 동일한 포맷을 갖는 다른 데이터 저장소(340)와의 상호 운용뿐만 아니라 다른 포맷을 갖는 데이터 저장소(342)로의 액세스를 가능하게 할 수 있다. 또한, 스토리지 플랫폼(300)은 윈도우즈 NTFS 파일 시스템(318)과 같은 기존 파일 시스템과 데이터 저장소(302)의 상호 운용을 가능하게 하는 파일 시스템 성능을 제공한다. 적어도 몇몇 실시예에서, 스토리지 플랫폼(320)은 또한 데이터가 실행될 수 있게 하고 다른 시스템과 상호동작할 수 있게 하는 추가 성능을 애플리케이션 프로그램에 제공할 수 있다. 이들 성능은 정보 에이전트 서비스(334)와 통지 서비스(332)와 같은 추가 서비스(328) 형태뿐만 아니라 다른 유틸리티(336)의 형태로 구체화될 수 있다.

적어도 몇몇 실시예에서, 스토리지 플랫폼은 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템으로 구현된 이의 코어 부분을 형성한다. 예를 들면, 이 에 한정하지 않고, 본 발명의 스토리지 플랫폼은 운영 체제, 가상 머신 관리자(VMM), 공통 언어 런타임(CLR) 또는 이의 기능적 등가물, 또는 자바 가상 머신(JVM) 또는 이의 기능적 등가물로 구체화되거나 이의 코어부를 형성할 수 있다. 이의 공통 스토리지 기반 및 도식화된 데이터에도 불구하고, 본 발명의 스토리지 플랫폼은 소비자, 지식 근로자 및 기업에 대한 보다 효율적인 애플리케이션 개발을 가능하게 한다. 이는 데이터 모델에 내재된 성능을 이용가능하게 할 뿐만 아니라 기존 파일 시스템과 데이터베이스 액세스 방법을 포함 및 확장하는 풍부하고 확장가능한 프로그래밍 표면 영역을 제공한다.

후술하는 설명에서, 그리고 도면의 다양한 설명에서, 본 발명의 스토리지 플랫폼(300)은 "WinFS"로 불릴 수 있다. 그러나, 스토리지 플랫폼을 지칭하는 이러한 명칭의 사용은 설명의 편이를 위한 것으로서 임의의 방식으로 한정하려는 것은 아니다.

C. 데이터 모델

본 발명의 스토리지 플랫폼(300)의 데이터 저장소(302)는 저장소에 상주하는 데이터의 구성, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델을 구현한다. 본 발명의 데이터 모델에서, "항목"은 저장 정보의 기본 단위이다. 데이터 모델은 항목과 항목 확장을 선언하고 항목간의 관계를 설정하며 항목 폴더와 카테고리에서 항목을 구성하는 메커니즘을 제공하되, 이들은 모두 상세히 후술한다.

데이터 모델은 두 개의 기본 메커니즘, 즉, 유형 및 관계에 의존한다. 유형은 이 유형의 인스턴스의 형성을 관리하는 포맷을 제공한 구조이다. 이 포맷은 정 렬된 속성 세트로서 표현된다. 속성은 해당 유형의 값 또는 일련의 값에 대한 명칭이다. 예를 들면, US우편주소 유형은 거리, 도시, 주(state)가 문자열 유형이고 Zip이 Int32 유형인 거리, 도시, 우편번호, 주를 가질 수 있다. 거리는 여러 값(즉, 일련의 값)이어서, 이 주소는 거리 속성에 대하여 하나 이상의 값을 갖게 할 수 있다. 시스템은 문자열, 이진, 불리언, Int16, Int32, Int64, 단일, 더블, 바이트, 날짜시간, 십진 및 GUID 등의 다른 유형의 구성에서 사용될 수 있는 특정 기본형을 정의한다. 유형의 속성은 기본형 중 임의의 것 또는 (일부 제한이 후술하는)구성체 유형의 임의의 것을 사용하도록 정의될 수 있다. 예를 들면, 상술한 바와 같이 US우편주소인 속성 좌표와 주소를 갖는 위치 유형이 한정될 수 있다. 또한, 속성은 필수적이거나 선택적일 수 있다.

관계는 선언되어 두 유형의 일련의 인스턴스 간의 매핑을 나타낼 수 있다. 예를 들면, 사람 유형과 어느 사람이 어느 위치에 있는지를 한정하는 LivesAt으로 불리는 위치 유형 사이에 선언된 관계일 수 있다. 이 관계는 명칭, 두 개의 종점, 즉 소스 종점과 타겟 종점을 갖는다. 또한, 관계는 정렬된 속성 세트를 가질 수 있다. 소스 및 타겟 종점은 모두 명칭 및 유형을 갖는다. 예를 들면, LivesAt 관계는 사람 유형의 거주자로 불리는 소스와 위치 유형의 주소로 불리는 타겟을 가지며, 이에 더하여 거주자가 주소에 살고 있는 기간을 나타내는 시작일과 종료일 속성을 갖는다. 사람은 시간상 여러 주소에서 살 수 있고, 주소는 여러 거주자를 가질 수 있기 때문에 시작일과 종료일 정보를 배치하는 장소는 그 자체의 관계에 있다.

관계는 종점 유형으로서 주어진 유형에 의해 제한된 인스턴스 간의 매핑을 한정한다. 예를 들면, LivesAt 관계는 자동차가 사람이 아니기 때문에 자동차가 거주자인 관계는 있을 수 없다.

데이터 모델은 유형 사이에서 서브타입-서브타입 관계의 정의를 가능하게 한다. 서브타입-서브타입 간계는 또한 유형 A가 유형 B에 대한 기본형이면 B의 모든 인스턴스가 A의 인스턴스이어야 하도록 한정된다. 이를 표현하는 다른 방식은 B에 부합된 모든 인스턴스는 A에 부합되어야 한다는 점이다. 예를 들면, A는 문자열 유형의 명칭 속성을 갖지만, B는 Int16 유형의 나이 속성을 가지면, B의 임의의 인스턴스는 명칭과 나이를 모두 가져야 한다. 유형 계층은 루트에서 단일 수퍼유형을 갖는 트리로서 고찰될 수 있다. 루트로부터 브랜치는 제1 레벨 서브타입을 제공하고, 이 레벨에서 브랜치는 제2 레벨 서브유형을 제공하며, 자체적으로 임의의 서브 유형을 갖지 않는 최말단 서브유형까지 제공한다. 트리는 균일한 깊이의 것으로 한정되지 않지만 임의의 순환을 포함할 수 있다. 해당 유형은 제로 또는 많은 서브유형 그리고 제로 또는 하나의 수퍼 유형을 가질 수 있다. 해당 유형은 그 유형의 수퍼 유형과 함께 최대 하나의 유형에 부합할 수 있다. 달리 말하면, 트리 내의 임의의 레벨의 해당 인스턴스에 대하여, 인스턴스는 이 레벨에서 최대 하나의 서브타입에 부합할 수 있다. 이 유형의 인스턴스가 또한 유형의 서브타입의 인스턴스이어야 하는 경우 유형은 추상적이어야 한다.

1. 항목

항목은 단순 파일과 달리 스토리지 플랫폼에 의해 최종 사용자 또는 애플리 케이션 프로그램에 노출된 모든 객체에 걸쳐 공통 지원되는 기본 속성 세트를 갖는 객체인 저장가능 정보 단위이다. 또한, 항목은 후술하는 바와 같이 새로운 속성과 관계가 도입될 수 있게 하는 특징을 포함하는 모든 항목 유형에 걸쳐 공통 지원되는 속성 및 관계이다.

항목은 복사, 삭제, 이동, 열기, 인쇄, 백업, 복원, 복제 등과 같은 일반 동작에 대한 객체이다. 항목은 저장 및 검색될 수 있는 단위이고, 스토리지 플랫폼에 의해 조작된 모든 저장가능 정보 형태는 항목, 항목 속성, 또는 항목들 간의 관계로서 존재하며, 이들 각각은 보다 상세히 후술한다.

항목은 컨택, 사람, 서비스, 위치, (모든 종류의)문서 등과 같은 실제의 용이하게 이해가능한 데이터 단위를 나타내려는 것이다. 도 5a는 항목의 구조를 나타내는 블록도이다. 항목의 무적격 명칭은 "위치"이다. 항목의 적격 명칭은 이러한 항목 구조가 코어 스키마에서 특정 유형의 항목으로서 한정됨을 나타내는 "코어.위치"이다. (코어 스키마는 이하 보다 상세히 설명한다).

위치 항목은 E주소, 대도시 영역, 이웃, 및 우편주소 등의 복수의 속성을 갖는다. 각각에 대한 속성의 특정 유형은 속성명 직후에 나타내며, 콜론(":")에 의해 속성명에서 분리된다. 유형 명의 우측으로, 이 속성형에 허용된 값의 개수는 괄호("[]") 사이에 나타내며, 콜론(":") 우측의 별표("*")는 구체적이지 않고 및/또는 한정적이지 않은 수치("다수")를 나타낸다. 콜론 우측의 "1"은 최대 하나의 값임을 나타낸다. 콜론 좌측의 제로("0")는 속성이 선택적(전혀 값이 없을 수 있다)임을 나타낸다. 콜론 좌측의 "1"은 적어도 하나의 값이어야 함(속성이 필요함) 을 나타낸다. 이웃 및 대도시 영역은 소정의 데이터형인 유형 "nvarchar"(또는 등가물) 또는 "단순 유형"(대문자가 아님을 표시)이다. 그러나, E주소 및 우편 주소는 E주소와 우편 주소의 한정된 유형 또는 "복잡한 유형(대문자로 시작)"의 속성이다. 복잡한 유형은 하나 이상의 단순 데이터형 및/또는 다른 복잡한 유형으로부터 유도되는 유형이다. 또한, 항목의 속성에 대한 복잡한 유형은 복잡한 유형의 세부사항이 이의 속성을 한정하는 즉시 항목으로 중복되고, 이들 복잡한 유형에 대한 정보는 이들 속성(후술하는 항목의 경계 내에서)을 갖는 항목을 사용하여 유지된다. 이들 유형화의 개념은 공지되어 있으며 당업자에 의해 용이하게 이해된다.

도 5b는 복잡한 속성 유형인 우편주소와 E주소를 나타내는 블록도이다. 우편 주소 속성 유형은 속성 유형의 항목인 우편 주소가 제로 또는 하나의 도시값, 제로 또는 하나의 도시코드 값, 제로 또는 하나의 메일스탑 값, 및 임의 수치(제로 내지 다수)의 우편주소 유형 등을 가질 수 있음을 한정한다. 이러한 방식으로, 항목 내에서 특정 속성에 대한 데이터의 형상이 여기서 한정된다. E주소 속성 유형은 유사하게 도시한 바와 같이 한정된다. 이 출원에서 선택적으로 사용되지만, 위치 항목에서 복잡한 유형을 나타내는 다른 방식은 여기서 열거된 각 복잡한 유형의 개별 속성을 사용하여 항목을 그리는 것이다. 도 5c는 이의 복잡한 유형을 더 설명하는 위치 항목을 나타낸 블록도이다. 그러나, 도 5c에서 위치 항목의 다른 표현은 도 5a에 나타낸 것과 정확하게 동일한 항목임이 이해되어야 한다. 본 발명의 스토리지 플랫폼은 또한 하나의 속성 유형이 다른 것의 서브타입(하나의 속성 유형은 다른, 부(parent) 속성 유형의 속성을 상속함)일 수 있다.

속성 및 이들의 속성 유형이 유사하지만 고유하게, 항목은 서브타입의 대상일 수 있는 이들 자신의 항목 유형을 이들 자신의 항목 형을 내재적으로 나타낸다. 다시 말하면, 본 발명의 여러 실시예에서 스토리지 플랫폼은 항목이 다른 항목의 서브타입을 할 수 있게 한다(하나의 항목은 다른 부 항목의 속성을 상속한다). 더욱이, 본 발명의 다른 실시예에서, 모든 항목은 베이스 스키마에서 발견된 제1 및 기본 항목 유형인 "항목"의 항목 유형의 서브타입이다. (베이스 스키마는 또한 후술한다). 도 6a는 이러한 인스턴스에서 위치 항목이 베이스 스키마에서 발견된 항목의 항목 유형의 서브타입인, 항목을 나타낸다. 이 도면에서, 화살표는 위치 항목(모든 다른 항목과 같이) 항목의 항목 유형의 서브타입을 나타낸다. 모든 다른 항목이 유도되는 기본 항목으로서, 항목의 항목 유형은 항목Id와 여러 시간 스탬프와 같은 다수의 중요 속성을 가지며, 이에 의해, 운영 체제에서 모든 항목의 표준 속성을 한정한다. 본 도면에서, 항목의 항목 유형의 이들 속성은 위치로 상속되어 위치 속성이 된다.

항목의 항목 유형에서 상속된 위치 항목에서 속성을 나타내는 다른 방법은 여기서 열거된 부 항목으로부터 각 속성 유형의 개별 속성으로 위치를 도시하는 것이다. 도 6b는 위치 항목을 나타내되, 이의 상속 유형이 즉시 속성에 더하여 나타내는 블록도이다. 본 도면에서 위치는 그것의 모든 속성, 즉시 -본 도면 및 도 5a에 도시된- 및 상속 -도 5a에서는 도시되지 않지만 본 도면에서는 도시된(도 5a에서 이들 속성은 위치 항목이 항목의 항목 유형의 서브타입임을 화살표로 나타내어 참조한다)- 둘 다로 도시되지만, 이 항목은 도 5a에 도시된 것과 동일 항목임이 이 해되어야 한다.

항목은 단독형 객체로서, 이에 따라, 항목을 삭제하는 경우, 모든 항목은 즉시 및 상속 속성도 제거된다. 유사하게, 항목을 검색할 때, 수신한 것은 항목과 이의 즉시 및 상속 속성(복잡한 속성 유형에 관한 정보를 포함) 모두이다. 본 발명의 특정 실시예는 특정 항목을 검색할 때 속성의 부분집합을 요청할 수 있게 하지만, 이러한 많은 실시예에 대한 기본값은 이의 즉시 및 상속 속성 모두를 검색될 때 항목에 제공하는 것이다. 더욱이, 항목의 속성은 항목 유형의 기존 속성에 새로운 속성을 추가하여 확장될 수 있다. 이들 "확장자"는 그 후 항목의 진정 속성과 이 항목 유형의 서브타입이 확장자 속성을 자동 포함할 수 있다.

항목의 "경계"는 이의 속성(복잡한 속성 유형, 확장자 등을 포함)에 의해 표현된다. 또한, 항목의 경계는 복사, 삭제, 이동, 생성 등과 같은 항목에 대하여 수행된 연산의 한도를 나타낸다. 예를 들면, 본 발명의 여러 실시예에서, 항목이 복사되면, 항목 경계 내의 모든 것이 또한 복사된다. 각 항목에 대하여, 경계는 다음을 포함한다:

항목의 항목 유형 및, 하목이 다른 항목의 서브타입인 경우(모든 항목은 베이스 스키마에서 단일 항목과 항목 유형에서 유도되는 본 발명의 여러 실시예에서와 같이) 임의의 이용가능 서브타입 정보(즉, 부 항목 유형에 관한 정보). 복사된 원래 항목은 다른 항목의 서브타입이면, 복사본은 또한 동일 항목의 서브타입일 수 있다.

항목의 복잡한 유형 속성과 확장자(있는 경우). 원래의 항목이 복잡한 유 형의 속성(고유 또는 확장)을 가지면, 복사본은 또한 동일 복잡한 유형을 가질 수 있다.

"소유자 관계"에 대한 항목의 기록, 즉 다른 항목("타겟 항목")이 본 항목("소유 항목")에 의해 소유되는 것의 항목 자체 리스트. 이는 보다 상세히 후술하는 항목 폴더에 특히 관련되며, 이 규칙은 모든 항목이 적어도 하나의 항목 폴더에 속하여야 함을 나타낸다. 더욱이, 보다 상세히 후술하는 임베디드 항목에 있어서, 임베디드 항목은 복사, 삭제 등과 같은 연산에 대하여 임베디드되는 항목의 일부로 여겨진다.

2. 항목 식별

항목은 항목ID를 사용하여 글로벌 아이템 공간 내에서 식별된다. 베이스.항목 유형은 항목에 대한 아이덴티티를 저장하는 GUID 유형의 항목ID 필드를 한정한다. 항목은 데이터 저장소(302)에서 정확히 하나의 아이덴티티를 가져야 한다.

항목 참조는 항목을 배치 및 식별하는 정보를 포함한 데이터 구조이다. 이 데이터 모델에서, 추상형은 모든 항목 참조형이 유도하는 네임드 항목참조로 정의된다. 항목참조 유형은 리졸브(Resolve)로 명명된 가상 메소드를 한정한다. 리졸브 메소드는 항목참조를 해결하여 항목을 리턴한다. 이 메소드는 참조에 대하여 항목을 검색하는 함수를 구현하는 항목참조의 구체적인 서브타입에 의해 취소된다. 리졸브 메소드는 스토리지 플랫폼 API(322)의 일부로서 취소된다.

항목ID참조는 항목참조의 서브타입이다. 이는 위치입력기와 항목ID 필드를 정의한다. 위치 입력기 필드는 항목 도메인을 명명한다(즉, 아이덴티티). 이는 위치 입력기 값을 항목 도메인으로 해결할 수 있는 위치 입력기 해결 방법에 의해 처리된다. 항목ID 필드는 항목ID 유형이다.

항목경로참조는 위치 입력기와 경로 필드를 한정하는 위치참조의 구체화이다. 위치 입력기 필드는 항목 도메인을 식별한다. 이는 위치입력기의 값을 항목 도메인으로 해결할 수 있는 위치 입력기 리졸브 메소드에 의해 처리된다. 경로 필드는 위치 입력기에 의해 제공된 항목 도메인에서 루트인 스토리지 플랫폼 네임스페이스에 (상대) 경로를 포함한다.

이러한 참조형은 집합 연산으로 사용될 수 없다. 참조는 경로 리졸브 프로세스를 통해 통상 해결되어야 한다. 스토리지 플랫폼 API(322)의 리졸브 메소드는 이의 기능을 제공한다.

상술한 참조 형태는 도 11에 도시한 참조형 계층을 통해 표현된다. 이들 유형을 상속하는 추가 참조형은 스키마에서 한정될 수 있다. 이는 타겟 필드의 유형으로서 관계 선언에서 사용될 수 있다.

3. 항목 폴더와 카테고리

보다 상세히 후술하는 바와 같이, 항목 그룹은 항목 폴더(파일 폴더와 혼동되어서는 안됨)로 불리는 특별 항목으로 구성된다. 그러나, 대부분의 파일 시스템과 달리, 항목이 하나의 항목 폴더에서 액세스되어 고찰되는 경우 이러한 고찰된 항목은 그 후 다른 항목 폴더로부터 직접 액세스될 수 있도록 항목이 하나 이상의 항목 폴더에 속할 수 있다. 실질적으로, 항목으로의 액세스가 다른 항목 폴더에서 발생하더라도, 실제 액세스되는 것은 바로 동일한 항목이다. 그러나, 항목 폴더는 모든 멤버 항목을 반드시 가질 필요는 없거나, 또는 단순히 다른 폴더와 함께 항목을 공동소유할 수 있어, 항목 폴더의 삭제가 항목의 삭제를 반드시 야기하지는 않는다. 그럼에도 불구하고, 본 발명의 몇몇 실시예에서, 항목은 적어도 하나의 항목 폴더에 속하여야 하면, 특정 항목에 대한 단일 항목 폴더가 삭제되면, 몇몇 실시예에서, 이 항목은 자동 삭제되고, 또는, 다른 실시예에서는, 이 항목이 기본 항목 폴더의 멤버가 된다(예를 들면, 다양한 파일 및 폴더 기반 시스템에서 사용되는 유사하게 명명된 폴더와 유사한 폴더"휴지통" 항목 폴더).

보다 상세히 후술하는 바와 같이, 항목은 (a) 항목 유형(유형들), (b) 특정 즉시 또는 상속 속성(또는 특성), 또는 (c) 항목 속성에 대응하는 특정 값(값들)과 같은 일반적으로 나타내는 속성에 기초한 카테고리에 속할 수 있다. 예를 들면, 개인용 컨택 정보에 대한 특정 속성을 포함하는 항목은 컨택 항목에 자동적으로 속할 수 있으며, 컨택 정보 속성을 갖는 임의의 항목은 유사하게 이 카테고리에 자동적으로 속할 수 있다. 유사하게, "뉴욕시"와 같은 위치 속성을 갖는 항목은 뉴욕시 카테고리에 자동적으로 속할 수 있다.

카테고리는, 항목 폴더가 상호관련되지 않는 항목을 포함할 수 있고(일반적으로 나타내는 속성 없이), 카테고리 내의 각 항목은 카테고리에 대하여 나타낸 공통 유형, 속성, 또는 값(공통성")을 갖는 반면, 이의 관계에 대한 기준을 형성하고 카테고리 내의 다른 항목 중에서 그리고 이에 대하여 형성하는 공통성이라는 점에서 항목 폴더와 개념적으로 상이하다. 더욱이, 특정 폴더에서 항목의 멤버십은 이의 항목의 임의의 특정 양태에 기초하여 필수적인 반면, 특정 실시예에서, 카테고 리에 관한 카테고리적으로 공통성을 갖는 모든 항목은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 카테고리의 멤버가 자동적으로 될 수 있다. 개념적으로, 카테고리는 가상 항목 폴더로서 간주될 수 있으며, 이의 멤버십은 특정 조회의 결과에 기초하며(데이터베이스의 경우와 같이), 이에 따라 이러한 조회의 조건을 충족하는 항목(카테고리의 공통성으로 한정됨) 카테고리의 멤버십을 포함할 수 있다.

도 4는 항목, 항목 폴더, 및 카테고리 간의 구조적 관계를 나타낸다. 복수의 항목(402, 404, 406, 408, 410, 412, 414, 416, 418, 및 420)은 여러 항목 폴더(422, 424, 426, 428, 및 430)의 멤버이다. 몇몇 항목은 하나 이상의 항목 폴더에 속할 수 있으며, 예를 들면, 항목(402)은 항목 폴더(422 및 424)에 속한다. 몇몇 항목, 예를 들면, 항목(402, 404, 406, 408, 410, 및 412)은 하나 이상의 카테고리(432, 434 및 436)의 멤버이지만, 다른 시점, 예를 들면, 항목(414, 416, 418, 및 420)은 카테고리에 속하지 않을 수 있다(임의의 속성의 소유가 카테고리 내의 멤버십을 자동 암시하는 특정 실시예에서 대략 가능하지 않지만, 항목이 이러한 실시예에서 임의의 카테고리의 멤버가 되지 않기 위해서 완전히 특성이 없어야 한다). 폴더의 계층 구조와 달리, 카테고리와 항목 폴더는 모두 도시한 바와 같은 지시된 그래픽에 보다 근접한 구조물을 갖는다. 임의의 이벤트에서, 항목, 항목 폴더 및 카테고리는 모든 항목이다(상이한 항목 유형에도 불구하고).

파일, 폴더, 디렉토리에 달리, 본 발명의 항목, 항목 폴더, 및 카테고리는 물리적 포함자의 개념적 등가물을 갖기 않기 때문에 속성상 "물리적"이지 않고, 이에 따라, 이러한 하나 이상의 위치에 존재할 수 있다. 항목이 하나 이상의 항목 폴더 위치에서 존재할 뿐만 아니라 카테고리에 구성될 능력은 현재 당업계에서 사용되는 것을 넘어서서 하드웨어/소프트웨어 인터페이스 레벨에서 데이터 조작 및 스토리지 구조의 개선을 제공한다.

4. 스키마

a) 베이스 스키마

항목의 생성 및 사용을 위한 범용 기반을 제공하기 위해서, 본 발명의 스토리지 플랫폼의 다양한 실시예는 항목 및 속성을 생성하여 구성하는 개념화된 프레임워크를 설정하는 베이스 스키마을 포함한다. 베이스 스키마는 몇몇 특정 유형의 항목 및 속성을 한정하고 이들 몇몇 기본 유형의 특성으로부터 서브타입이 더 유도될 수 있다. 이러한 베이스 스키마의 사용은 프로그래머가 속성(및 이들의 개별 유형)으로부터 프로그래머가 항목(및 이들의 개별 유형)을 개념적으로 구분할 수 있게 한다. 더욱이, 베이스 스키마는 모든 항목(및 이들의 대응하는 항목 유형)이 기본 스키마(및 이의 대응하는 항목 유형)에서 이러한 기본 항목에서 유도됨에 따라 모든 항목이 소유할 수 있는 기본적인 속성 세트를 나타낸다.

도 7에서 나타낸 바와 같이, 본 발명의 여러 실시예에 대하여, 베이스 스키마는 3개의 정상 레벨 유형, 즉, 항목, 확장자 및 속성기반(PropertyBase)을 한정한다. 도시한 바와 같이, 항목 유형은 이러한 기본 "항목"의 항목 유형의 속성에 의해 한정된다. 이와 달리, 정상 레벨 속성 유형인 "속성기반"은 소정의 속성을 갖지 않으며, 모든 다른 속성 유형이 유도되고 모든 유도된 속성 유형이 상호관련되는(단일 속성 유형에서 공통으로 유도됨) 단지 앵커(anchor)이다. 확장자 유형 속성은 확장자가 확장하는 항목이 어느 것이고 하나의 확장자와 다른 확장자를 항목으로서 구분할 식별이 여러 확장자를 가질 수 있음을 한정한다.

항목폴더는 항목에서 상속된 속성에 더하여, 링크를 이의 멤버(있는 경우)에 설정하는 관계를 특징으로 하는 항목의 항목 유형의 서브타입이지만, 아이덴티티키와 속성은 속성기반의 서브타입이다. 이에 따라, 카테고리 참조는 아이덴티티키의 서브타입이다.

b) 코어 스키마

본 발명의 스토리지 플랫폼의 다양한 실시예는 정상 레벨 항목 유형 구조에 대한 개념적 프레임워크를 제공하는 코어 스키마를 더 포함한다. 도 8a는 코어 스키마에서 항목을 나타내는 블록도이며, 도 8b는 코어 스키마에서 속성 유형을 나타내는 블록도이다. 상이한 확장자(*.com, .exe, *.bat, *.sys 등)를 갖는 파일 간에 행해진 구분과 파일 및 폴더 기반 시스템에서의 이러한 다른 기준은 코어 스키마의 함수와 유사하다. 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서, 코어 스키마는 모든 항목을 항목기반 하드웨어/소프트웨어 인터페이스 시스템이 이해하여 할 수 있는 하나 이상의 코어 스키마 항목 유형을 직접(항목 유형에 의해) 또는 간접(항목 서브타입에 의해) 특성화하거나, 소정의 예측가능한 방식으로 직접 처리할 수 있는 일련의 코어 항목을 한정한다. 소정의 항목 유형은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가장 일반적인 항목을 반영함으로써, 효율성 레벨은 코어 스키마를 포함하는 이들 소정 항목 유형을 이해하는 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 획득된다.

특정 실시예에서, 코어 스키마는 확장가능하지 않으며, 다시 말하면, 코어 스키마의 일부인 특정한 소정의 유도 항목 유형을 제외하면 베이스 스키마에서 어떤 추가 항목 유형도 직접 서브타입화될 수 없다. 코어 스키마에 대한 확장을 방지함으로써(즉, 새로운 항목을 코어 스키마에 추가하는 것을 방지함으로써), 스토리지 플랫폼은 모든 후속 항목 유형이 반드시 코어 스키마 항목 유형의 서브타입이기 때문에 코어 스키마 항목 유형의 사용을 요구한다. 이러한 구조는 추가 항목 유형을 한정하면서 일련의 소정 코어 항목 유형을 갖는 이점을 보유하여 상당한 정도의 유연성을 가능하게 한다.

본 발명의 다양한 실시예에서, 그리고 도 8a를 참조하면, 코어 스키마에 의해 지원된 특정 항목 유형은 다음 중 하나 이상을 포함할 수 있다:

카테고리: 이러한 항목 유형(및 이로부터 유도된 서브타입)의 항목은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 유효 카테고리를 나타낸다.

상품(commodity): 식별가능한 값을 갖는 항목.

장치: 정보 처리 성능을 지원하는 논리 구조를 갖는 항목.

문서: 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 해석되지 않지만 문서 유형에 대응하는 애플리케이션 프로그램에 의해 해석된 컨텐츠를 갖는 항목.

이벤트: 환경에서 특정 발생을 기록하는 항목.

위치: 물리적 위치를 나타내는 항목(예를 들면, 지리적 위치).

메시지: 둘 이상의 주체(후술함) 간의 통신 항목

주체(principal): 항목Id에서 주변의 적어도 하나의 명확하게 증명가능한 아이덴티티를 갖는 항목(예를 들면, 사람, 단체, 그룹, 가정, 공사, 서비스 등의 식별).

문장: 한정, 정책, 구독, 자격 증명을 포함하지만 이에 한정되지 않은 환경에 대한 특별 정보를 갖는 항목.

유사하게, 도 8b를 참조하면, 코어 스키마에 의해 지원된 특정 속성 유형은 다음 중 하나 이상을 포함할 수 있다:

증명서(베이스 스키마에서 기본 속성기반 유형으로 유도)

주체 아이덴티티 키(베이스 스키마에서 아이덴티티 유형에서 유도)

우편 주소(베이스 스키마에서 속성 유형에서 유도)

풍부한 텍스트(베이스 스키마에서 속성 유형에서 유도)

E주소(베이스 스키마에서 속성 유형에서 유도)

아이덴티티보안패키지(베이스 스키마에서 관계 유형에서 유도)

역할점유시간(베이스 스키마에서 관계 유형에서 유도)

기본존재(베이스 스키마에서 관계 유형에서 유도)

이들 항목 및 속성은 도 8a 및 도 8b에서 설명한 이들의 개별 속성으로 나타낸다.

5. 관계

관계는 한 항목이 소스로서 다른 항목이 타겟으로서 지정되는 이진 관계이다. 소스 항목은 타겟 항목은 관계에 의해 관련된다. 소스 항목은 통상 관계의 수명을 제어한다. 즉, 소스 항목이 삭제되는 경우, 항목 간의 관계는 항상 삭제된다.

관계는, 포함 및 참조 관계로 분류된다. 포함 관계는 타겟 항목의 수명을 제어하지만, 참조 관계는 임의의 수명 관리 의미를 제공하지 않는다. 도 12는 관계가 분류되는 방식을 나타낸다.

포함 관계 유형은 홀딩 및 임베딩 관계로 더 분류된다. 항목에 대한 모든 홀딩 관계가 제거되는 경우, 항목이 삭제된다. 홀딩 관계는 참조 카운팅 메커니즘을 통해 타겟의 수명을 제어한다. 임베딩 관계는 혼합 항목의 모델링을 가능하게 하며 배타적 홀딩 관계로서 간주될 수 있다. 항목은 하나 이상의 홀딩 관계의 타겟일 수 있지만, 항목은 정확히 하나의 임베딩 관계의 타겟일 수 있다. 임베딩 관계의 타겟인 항목은 임의의 다른 홀딩 또는 임베딩 관계의 타겟일 수 없다.

참조 관계는 타겟 항목의 수명을 제어하지 않는다. 이들은 댕글링(dangling)일 수 있다 - 타겟 항목이 존재하지 않을 수 있다. 참조 관계는 글로벌 항목 네임스페이스의 임의의 장소에 대한 참조(즉, 원격 데이터 저장소를 포함)를 포함하는데 사용될 수 있다.

항목 불러오기는 이의 관계를 자동적으로 불러오지는 않는다. 애플리케이션은 항목의 관계를 명시적으로 요구하여야 한다. 또한, 관계의 변형은 소스 또는 타겟 항목을 변형하지 않으며, 유사하게, 관계의 추가는 소스/타겟 항목에 영향을 미치지 않는다.

관계 선언

명시적 관계 유형은 다음 요소를 사용하여 한정된다:

관계명은 명칭 속성으로 규정된다.

관계 유형은 다음 중 하나: 홀딩, 임베딩, 참조. 이는 유형 속성에서 규정된다.

소스 및 타겟 종점. 각 종점은 참조한 항목의 명칭 및 유형을 규정한다.

소스 종점 필드는 통상 항목ID(미선언)이며, 이는 관계 인스턴스와 동일한 데이터 저장소에서 항목을 참조하여야 한다.

홀딩 및 임베딩 관계에 있어서, 타겟 종점 필드는 항목ID참조 유형이어야 하며 이는 관계 인스턴스와 동일한 저장소의 항목을 참조하여야 한다. 참조 관계에 있어서, 타겟 종점은 임의의 항목참조 유형일 수 있으며, 다른 스토리지 플랫폼 데이터 저장소에서 항목을 참조할 수 있다.

선택적으로, 스칼라 또는 속성기반 유형 중 하나 이상의 필드가 선언될 수 있다. 이들 필드는 관계에 관련된 데이터를 포함할 수 있다.

관계 인스턴스는 글로벌 관계 표에 저장된다.

모든 관계 인스턴스는 (소스항목ID, 관계ID)조합으로 고유하게 식별된다. 관계ID는 해당 소스 항목ID 내에서 이들 유형에 관계없이 해당 항목에 유래된 모든 관계에 대하여 고유하다.

소스 항목은 관계의 소유자이다. 소유자로서 지정된 항목이 관계의 수명을 제어하지만, 관계 자체는 관련된 항목과 분리된다. 스토리지 플랫폼 API(322)는 항목에 관련된 관계를 노출하는 메커니즘을 제공한다.

관계 선언의 일 예가 제시된다:

이는 참조 관계의 일 예이다. 이 관계는 소스 참조에 의해 참조되는 사람 항목이 존재하지 않는 경우에는 생성될 수 없다. 또한, 사람 항목이 삭제되는 경우, 사람과 단계 간의 관계 인스턴스가 삭제된다. 그러나, 단계 항목이 삭제되면, 이 관계는 삭제되지 않고 댕글링된다.

홀딩 관계

홀딩 관계는 타겟 항목의 카운트 기반 수명 관리를 모델링하는데 사용된다.

항목은 항목들에 대한 제로 이상의 관계에 대한 소스 종점일 수 있다. 임베디드 항목이 아닌 항목은 하나 이상의 홀딩 관계의 타겟일 수 있다.

타겟 종점 참조형은 항목ID참조이어야 하며, 이는 관계 인스턴스와 동일한 저장소에 있는 항목을 참조하여야 한다.

홀딩 관계는 타겟 종점의 수명 관리를 실행한다. 홀딩 관계 인스턴스와 타겟되고 있는 항목의 생성은 단위 연산이다. 추가 홀딩 관계 인스턴스는 동일 항목을 타겟으로 하여 생성될 수 있다. 타겟 종점으로 해당 항목을 사용하여 마지막 홀딩 관계 인스턴스가 삭제되는 경우 타겟 항목이 또한 삭제된다.

관계 선언에서 규정된 종점 항목의 유형은 관계의 인스턴스가 생성될 때 통 상 실행될 수 있다. 이러한 종점 항목의 유형은 관계가 설정된 후에 변경될 수 없다.

홀딩 관계는 항목 네임스페이스를 형성할 때 중요한 역할을 한다. 이들은 소스 항목에 대하여 타겟 항목의 명칭을 한정하는 "명칭" 속성을 포함한다. 이러한 상대적 명칭은 해당 항목으로부터 유래된 모든 홀딩 관계에 대하여 고유하다. 루트로부터 개시하여 해당 항목까지의 이러한 상대적 명칭의 정렬된 리스트는 항목에 대한 전체 명칭을 형성한다.

홀딩 관계는 지시된 비순환 그래프(DAG)를 형성한다. 홀딩 관계가 생성될 때 순환이 생성되지 않음을 보장함으로써, 항목 네임스페이스는 DAG를 형성함을 보장한다.

홀딩 관계가 타겟 항목의 수명을 제어하지만, 이는 타겟 종점 항목의 연산 일관성을 제어하지 않는다. 타겟 항목은 홀딩 관계를 통해 이를 소유하는 항목으로부터 연상에 있어서 독립적이다. 홀딩 관계의 소스인 항목에 대한 복사, 이동, 백업 및 기타 연산은 동일 관계의 타겟인 항목에 영향을 미치지 않는다 - 예를 들면, 폴더 항목의 백업은 폴더 내의 모든 항목을 자동으로 백업하지 않는다(폴더멤버 관계의 타겟).

다음은 홀딩 관계의 일 예이다:

폴더멤버 관계는 폴더의 개념을 항목의 일반 모음으로서 가능하게 한다.

임베딩 관계

임베딩 관계는 타겟 항목의 수명의 배타적 제어를 모델링한다. 이는 혼합 항목의 개념을 가능하게 한다.

임베딩 관계 인스턴스와 이를 타겟으로 하는 항목의 생성은 단위 연산이다. 항목은 제로 이상의 임베딩 관계의 소스이다. 그러나, 항목은 하나의 그리고 단지 하나의 임베딩 관계의 타겟일 수 있다. 임베딩 관계의 타겟인 항목은 홀딩 관계의 타겟일 수 없다.

타겟 종점 참조형은 항목ID참조이어야 하며 이는 관계 인스턴스로서 동일 데이터 저장소 내의 항목을 참조하여야 한다.

관계 선언에 규정된 종점 항목의 유형은 관계의 인스턴스가 생성될 때 통상 실행되어야 한다. 종점 항목의 유형은 관계가 설정된 후에 변경될 수 없다.

임베딩 관계는 타겟 종점의 연산 일관성을 제어한다. 예를 들면, 항목의 직렬화 연산은 항목뿐만 아니라 이들의 모든 타겟에 유래한 모든 임베딩 관계의 직렬화를 포함할 수 있으며, 항목 복사는 또한 모든 이의 임베디드 항목을 복사한다.

다음은 선언의 일 예이다:

참조 관계

참조 관계는 이것이 참조하는 항목의 수명을 제어하지 않는다. 더욱이, 참조 관계는 타겟의 존재를 보증하지 않으며, 이들은 관계 선언에 규정된 바와 같은 타겟 유형을 보증하지 않는다. 이는 참조 관계가 댕글링일 수 있음을 의미한다. 또한, 참조 관계는 다른 데이터 저장소에서 항목을 참조할 수 있다. 참조 관계는 웹 페이지 내의 링크와 유사한 개념으로 여겨질 수 있다.

다음은 참조 관계 선언의 일 예이다:

임의의 참조 유형이 타겟 종점에서 허용된다. 참조 관계에 참여하는 항목은 임의의 항목 유형일 수 있다.

참조 관계는 항목들 간의 비 수명 관리 관계를 모델링하는데 사용된다. 타겟의 존재가 실시되지 않기 때문에, 참조 관계는 약한 결합 관계를 모델링하는데 편리하다. 참조 관계는 다른 컴퓨터 상의 저장소를 포함하는 다른 데이터 저장소에서 항목을 타겟하는데 사용될 수 있다.

규칙 및 제한

다음 추가 규칙 및 제한이 관계에 적용된다:

항목은 (정확히 하나의 임베딩 관계) 또는 (하나 이상의 홀딩 관계)의 타 겟이어야 한다. 하나의 예외는 루트 항목이다. 항목은 제로 이상의 참조 관계의 타겟일 수 있다.

임베딩 관계의 타겟인 항목은 홀딩 관계의 소스일 수 없다. 이는 참조 관계의 소스일 수 있다.

항목은 파일에서 진행되는 경우 홀딩 관계의 소스일 수 없다. 이는 임베딩 관계 및 참조 관계의 소스일 수 있다.

파일로부터 진행된 항목은 임베딩 관계의 타겟일 수 없다.

관계 정렬

적어도 하나의 실시예에서, 본 발명의 스토리지 플랫폼은 관계의 정렬을 지원한다. 이러한 순서는 기본 관계 정의에서 "정렬"이라 명명된 속성을 통해 달성된다. 이는 순서 필드에 대한 고유 제한이 없다. 동일한 "순서" 속성값을 갖는 관계의 순서는 보증되지 않지만, 보다 낮은 "순서" 값을 갖는 관계 후에 그리고 보다 높은 "순서" 필드값을 갖는 관계전에 정렬될 수 있도록 보증한다.

애플리케이션은 조합(소스항목ID, 관계ID, 순서)에 대하여 정렬함으로써 기본 순서로 관계를 획득할 수 있다. 해당 항목으로부터 유래된 모든 관계 인스턴스는 모음의 관계 유형에 관계없이 단일 모음으로서 정렬된다. 그러나, 이는 해당 유형(예를 들면, 폴더멤버)의 모든 관계가 해당 항목에 대한 관계 모음의 정렬된 부분집합임을 보증한다.

관계를 조작하는 데이터 저장소 API(312)는 관계의 정렬을 지원하는 일련의 연산을 구현한다. 다음 용어는 연산을 설명하는 것을 지원하도록 도입된다:

RelFirst는 순서값 OrdFirst를 갖는 정렬된 모음에서 제1 관계이다;

RelLast는 순서값 OrdLast를 갖는 정렬된 모음 내의 마지막 관계이다;

RelX는 순서값 OrdX를 갖는 모음에서 해당 관계이다;

RelPrev는 순서값 OrdPrev이 OrdX보다 적은, RelX에 대한 모음에서 가장 근접한 관계이다;

RelNext는 순서값 OrdNext가 OrdX보다 큰, RelX에 대한 모음에서 가장 근접한 관계이다.

이 연산은 다음을 포함하지만 이에 한정되지 않는다:

InsertBeforeFirst(소스항목ID, 관계)는 모음에서 제1 관계로서 이 관계를 삽입한다. 새로운 관계의 "순서" 속성의 값은 OrdFirst보다 작을 수 있다.

InsertAfterLast(소스항목ID, 관계)는 모음에서 마지막 관계로서 이 관계를 삽입한다. 새로운 관계의 "순서" 속성의 값은 OrdLast보다 클 수 있다.

InserAt(소스항목ID, ord, 관계)는 "순서" 속성에 대한 구체적 값을 갖는 관계를 삽입한다.

InserBefore(소스항목ID, ord, 관계)는 해당 순서값을 갖는 관계 이전에 이 관계를 삽입한다. 새로운 관계는 OrdPrev와 ord 사이에 비배타적으로 할당된 "순서" 값이 할당될 수 있다.

InsertAfter(소스항목ID, ord, 관계)는 해당 순서값을 갖는 관계 이후에 이 관계를 삽입한다. 새로운 관계는 ord와 OrdNext 사이에 있는 비배타적으로 할당된 "순서" 값이 할당될 수 있다.

MoveBefore(소스항목ID, ord, 관계ID)는 규정된 "순서" 값을 갖는 관계 이전으로 해당 관계 ID를 갖는 관계를 이동시킨다. 이 관계는 OrdPrev와 ord 사이에 비배타적으로 새로운 "순서" 값이 할당될 수 있다.

MoveAfter(소스항목ID, ord, 관계ID)는 규정된 "순서" 값을 갖는 관계 이후로 해당 관계 ID를 갖는 관계를 이동시킨다. 이 관계는 ord와 OrdNext 사이에 있는 새로운 순서 값을 비배타적으로 할당될 수 있다.

상술한 바와 같이, 모든 항목은 항목 폴더의 멤버이어야 한다. 관계에 있어서, 모든 항목은 항목 폴더와 관계를 가져야 한다. 본 발명의 여러 실시예에서, 특정 관계는 항목들 사이에 존재하는 관계로 나타낸다.

본 발명의 여러 실시예에서 구현된 바와 같이, 관계는 하나의 항목(소스)에 "확장"되는 지시된 이진 관계를 다른 항목(타겟)에 제공한다. 관계는 소스 항목(이를 확장하는 항목)에 의해 소유됨으로써, 소스가 제거되면 관계가 제거된다(예를 들면, 소스 항목이 삭제될 때 관계가 삭제된다). 더욱이, 특정 경우, 관계는 (공동 소유의) 타겟 항목의 소유를 공유할 수 있으며, 이러한 소유는 (관계 속성 유형에 대하여 도 7에서 도시한 바와 같이)관계의 IsOwned 속성(또는 이의 등가물)에서 반영될 수 있다. 이들 실시예에서, 새로운 IsOwned 관계의 생성은 타겟 항목의 참조 카운트를 자동 증가시키고, 이러한 관계의 삭제는 타겟 항목의 참조 카운트를 감소시킬 수 있다. 이들 특정 실시예에 대하여, 항목은 제로 이상의 참조 기준을 가지면 계속 존재하고, 카운트가 제로에 도달하면 자동 삭제된다. 또한, 항목 폴더는 다른 항목에 대한 일련의 관계를 갖는(또는 가질 수 있는) 항목이며, 이들 다 른 항목은 항목 폴더의 멤버십을 포함한다. 관계의 다른 실제적인 구현이 가능하며, 본 발명에 의해 예측되어 여기서 나타낸 기능을 달성한다.

실제 구현예에 관계없이, 관계는 하나의 객체에서 다른 객체로의 선택가능한 연결이다. 항목이 하나 이상의 항목 폴더뿐만 아니라 하나 이상의 카테고리에 속하는 능력은 이들 항목, 폴더, 카테고리가 공용 또는 전용인지에 관계없이 항목 기반 구조에서 존재(또는 이의 결여)에 주어진 의미에 의해 결정된다. 이들 논리 관계는 물리적 구현에 관계없이 일련의 관계에 할당된 의미이며, 이는 특히 여기서 나타낸 기능을 달성하도록 사용된다. 논리적 관계는 본질적으로 항목 폴더와 카테고리가 각각 특정 유형의 항목이기 때문에 항목 및 이의 항목 폴더(들) 또는 카테고리 사이에 설정된다(그 역도 마찬가지임). 결과적으로, 항목 폴더와 카테고리는 임의의 다른 항목과 동일한 방식으로 동작할 수 있으며, - 이메일 메시지에 복사 및 추가되고, 문서 내에 임베디드되는 것을 포함하지만 이에 한정되지 않음 -, 항목 폴더 및 카테고리는 다른 항목에 대해서와 동일한 메커니즘을 사용하여 직렬화 및 탈직렬화될 수 있다(임포트 및 익스포트될 수 있다). (예를 들면, XML에서 모든 항목은 직렬화 포맷을 가질 수 있으며, 이러한 포맷은 항목 폴더, 카테고리, 및 항목과 동일하게 적용된다).

상술한 관계는 항목 및 이의 항목 폴더(들) 간의 관계를 나타내며, 항목에서 항목으로, 항목 폴더에서 항목으로, 또는 두 경우 모두로 논리 확장할 수 있다. 항목에서 항목 폴더로 논리적으로 확장하는 관계는 항목 폴더가 항목에 공용이고 이 항목과 멤버십 정보를 공유함을 의미하고, 역으로, 항목에서 항목 폴더로의 논 리적 관계의 결여는 항목 폴더가 이 항목에 전용이고 이 항목과 멤버십 정보를 공유하지 않음을 의미한다. 유사하게, 항목 폴더에서 항목으로 논리적으로 연장하는 관계는 이 항목이 공용이고 이 항목과 공유가능함을 의미하지만, 항목 폴더에서 항목으로의 논리적 관계의 결여는 항목이 전용이고 공유불가능함을 의미한다. 결과적으로, 항목 폴더가 다른 시스템에 익스포트되는 경우, 이는 새로운 문맥에서 공유되는 "공용" 항목이며, 항목이 다른 공유가능한 항목에 대항 항목 폴더를 검색하는 경우, 이는 속하는 공유가능 항목에 대한 정보를 항목에 제공하는 "공용" 항목 폴더이다.

도 9는 항목 폴더(또한, 항목 자체), 이의 멤버 항목, 및 항목 폴더와 이의 멤버 항목 간의 상호 관계를 나타내는 블록도이다. 항목 폴더(900)는 멤버로서 복수의 항목(902, 904 및 906)을 갖는다. 항목 폴더(900)는, 그 자신으로부터 항목(902)으로의 관계를 갖는 것으로서, 항목(902)이 공용이고 항목 폴더(900), 이의 멤버(904 및 906), 및 임의의 다른 항목 폴더, 카테고리, 항목 폴더(900)를 액세스할 수 있는 항목(미도시)과 공용가능함을 나타낸다. 그러나, 항목(902)에서 항목 폴더(900)로의 관계는 없으며, 이는 항목 폴더(900)는 항목(902)에 차단되기 때문에 이의 멤버십 정보를 항목(902)과 공유하지 않음을 의미한다. 반면에, 항목(904)은 그 자신으로부터 항목 폴더(900)로의 관계(924)를 가지며, 이는 항목 폴더(900)가 공용이고 이의 멤버십 정보를 항목(904)과 공유함을 의미한다. 그러나, 항목 폴더(900)에서 항목(904)으로의 관계는 없으며, 이는 항목(904)이 전용이고 항목 폴더(900), 이의 다른 멤버(902 및 906), 및 임의의 다른 항목 폴더, 카테고 리, 또는 항목 폴더(900)를 액세스할 수 있는 항목(미도시)과 공유하지 않는다. 항목(902 및 904)에 대한 관계(및 이의 결여)와 달리, 항목 폴더(900)는 그 자신으로부터 항목(906)으로의 관계(916)를 가지며, 항목(906)은 항목 폴더(900)와 관계(926)를 가지며, 이는, 항목(906)이 공용이어서 항목 폴더(900), 이의 멤버(902 및 904), 및 임의의 다른 항목 폴더, 카테고리, 항목 폴더(900)를 액세스할 수 있는 항목(미도시)에 공유가능하고, 항목 폴더(900)는 공용이어서 이의 멤버십 정보를 항목(906)과 공유함을 의미한다.

상술한 바와 같이, 항목 폴더 내의 항목은 항목 폴더가 "설명되지" 않기 때문에 상품을 공유할 필요가 없다. 반면에, 카테고리는 이의 멤버 항목 모두에 공통인 상품으로 나타낸다. 결과적으로, 카테고리의 멤버십은 설명한 상품을 갖는 항목에 내재적으로 한정되고, 특정 실시예에서, 카테고리 설명을 충족하는 모든 항목은 카테고리의 멤버에 자동으로 행해진다. 따라서, 항목 폴더는 사소한 유형 구조가 이들의 멤버십으로 나타낼 수 있게 하지만, 카테고리는 한정된 상품에 기초하여 멤버십을 허용한다.

물론, 카테고리 설명은 본래 논리적이고, 이에 따라, 카테고리는 유형, 속성, 및/또는 값의 임의의 논리적 표현으로 나타낼 수 있다. 예를 들면, 카테고리의 논리적 표현은 두 속성 중 하나 또는 둘 모두를 포함하는 멤버십일 수 있다. 카테고리에 대하여 이들의 나타낸 속성이 "A" 및 "B"이면, 카테고리 멤버십은 속성 A는 갖지만 B는 갖지 않는 항목, 속성 B를 갖지만 A는 갖지 않는 항목, 및 속성 A와 B를 갖는 항목을 포함할 수 있다. 이러한 속성의 논리적 표현은 논리적 연산자 "OR"로 나타내며, 이는 카테고리로 표현한 일련의 멤버는 A OR B 속성을 갖는 항목이다. 유사한 논리적 피연산자(단독 또는 조합으로 "AND", "XOR", 및 "NOT"을 포함하지만 이에 한정되지 않음)는 당업자에 이해될 수 있는 바와 같이 카테고리를 나타내는데 사용될 수 있다.

항목 폴더(설명하지 않음)와 카테고리(설명함) 사이의 구분에도 불구하고, 항목에 대한 카테고리 관계와 카테고리에 대한 항목 관계는 본 발명의 많은 실시예에서 항목 폴더와 항목에 대하여 상술한 것과 본질적으로 동일한 방식이다.

도 10은 카테고리(또한, 항목 자신임), 이의 멤버 항목, 및 카테고리 및 이의 멤버 항목 간의 상호 관계를 나타내는 블록도이다. 카테고리(100)는 복수의 항목(1002, 1004 및 1006)을 멤버로서 가지며, 이들 모두는 상술한 바와 같이 카테고리(1000)에 의해 공통 속성, 값 또는 유형(1008)의 몇몇 조합을 공유한다. 카테고리(1000)는 이 자신으로부터 항목(1002)으로의 관계(1012)를 가지며, 이는 항목(1002)이 공용이고 카테고리(1000), 이의 멤버(1004 및 1006), 임의의 다른 카테고리, 항목 폴더, 또는 카테고리(1000)를 액세스할 수 있는 항목(미도시)과 공유가능하다. 그러나, 항목(1002)으로부터 카테고리(1000)로의 관계가 없으며, 이는 카테고리(1000)는 항목(1002)에 차단되어 이의 멤버십 정보를 항목(1002)과 공유하지 않음을 의미한다. 반면에서,항목(1004)은 그 자신으로부터 카테고리(1000)로의 관계(1024)를 가지며, 이는 카테고리(1000)는 공용이며 이의 멤버십 정보를 항목(1004)과 공유함을 의미한다. 그러나 카테고리(1000)로부터 항목(1004)으로 확장되는 관계가 아니며, 이는 항목(1004)이 전용기고 카테고리(1000), 이의 다른 멤버 (1002 및 1006), 및 임의의 다른 카테고리, 항목 폴더 또는 액세스(1000)를 액세스할 수 없는 항목(미도시)과 공유하지 않음을 의미한다. 항목(1002 및 1004)과의 관계(또는 이의 결여)와 달리, 카테고리(1000) 난 그 자신으로부터 항목(1006)으로의 관계(1016)를 가지며, 항목(1006)은 다시 카테고리(1000)로의 관계를 가지며, 이들은 모두 항목(1006)이 공용이고 카테고리(1000), 이의 항목 멤버(1002 및 1004), 및 임의의 다른 카테고리, 항목 폴더, 또는 카테고리(1000)에 액세스할 수 있는 항목과 공유가능하고, 카테고리(1000)는 공용이고 이의 멤버십 정보를 항목(1006)과 공유함을 의미한다.

마지막으로, 카테고리와 항목 폴더는 자신이 항목이고, 항목은 서로 관계이기 때문에, 카테고리는 항목 폴더에 관계일 수 있고, 그 역도 마찬가지이며, 특정 다른 실시예에서는, 카테고리, 항목 폴더 및 항목이 다른 카테고리, 항목 폴더 및 항목에 각각 관계일 수 있다. 그러나, 다양한 실시예에서, 항목 폴더 구조 및/또는 항목 구조는 사이클을 포함하는 것이 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 금지된다. 항목 폴더 및 카테고리 구조는 그래프에 유사한 경우, 사이클을 금지하는 실시예는 지시형 비순환 그래프(DAG)에 유사하며, 이들은, 그래프 이론에서 수학적 정의에 의해, 어떤 경로도 개시하지 않도록 동일 정점에서 종료하는 그래프가 지시된다.

6. 확장성

스토리지 플랫폼은 상술한 바와 같이 초기의 일련의 스키마(340)가 제공될 수 있다. 그러나, 또한, 적어도 몇몇 실시예에서, 스토리지 플랫폼은 독립 소프트 웨어 벤더(ISV)를 포함하는 고객이 새로운 스키마(344; 즉, 새로운 항목과 중첩 요소 유형)을 생성할 수 있게 한다. 본 단락은 항목 유형과 초기 일련의 스키마(340)에 한정된 중첩 요소 유형(또는 단순 "요소" 유형)을 확장함으로써 이러한 스키마를 생성하는 메커니즘을 해결한다.

바람직하게는, 초기 일련의 항목과 중첩 요소 유형의 확장자는 다음과 같이 제한된다:

ISV는 새로운 항목 유형, 즉 서브타입 베이스.항목을 도입할 수 있다;

ISV는 새로운 중첩 유형, 즉, 서브타입 베이스.중첩요소를 도입할 수 있다;

ISV는 새로운 확장자, 즉, 서브타입 베이스.중첩요소를 도입할 수 있다,

ISV는 초기의 일련의 스토리지 플랫폼 스키마(340)에 의해 한정되는 임의의 유형(항목, 중첩 요소 또는 확장자 유형)을 서브타입할 수 없다.

초기의 일련의 스토리지 플랫폼 스키마에 의해 한정되는 항목 유형 또는 중첩 요소 유형은 ISV 애플리케이션의 요구에 정확하게 일치하지 않을 수 있기 때문에, ISV를 이 유형에 커스텀화할 수 있는 것이 필요하다. 이는 확장자의 통지로 허용된다. 확장자는 강하게 유형화된 인스턴스이지만, (a) 이들은 독립적으로 존재할 수 없고 (b) 항목 또는 중첩 요소에 첨부되어야 한다.

스키마 확장성에 대한 요구를 해결하는 것에 더하여, 확장은 또한 "멀티 유형" 문제를 해결하려는 것이다. 몇몇 실시예에서, 스토리지 플랫폼은 다중 상속 또는 중첩 서브타입을 지원할 수 없기 때문에, 애플리케이션은 중첩 유형 인스턴스 를 모델링하는 방식으로서 확장자를 사용할 수 있다(예를 들면, 문서는 법적 문서뿐만 아니라 보안 문서이다).

항목 확장자

항목 확장성을 제공하기 위해서, 데이터 모델은 베이스.확장자로 명명된 추상형을 더 한정한다. 이는 확장형의 계층에 대한 루트 유형이다. 애플리케이션은 베이스.확장자를 서브타입화하여 특정 확장형을 생성할 수 있다.

다음은 베이스.확장자 유형이 베이스 스키마에 한정되는 것이다:

항목ID 필드는 확장자가 관련된 항목의 항목ID를 포함한다. 이러한 항목ID를 갖는 항목이 존재하여야 한다. 확장자는 해당 항목ID를 갖는 항목이 존재하지 않으면 생성될 수 없다. 항목이 삭제되는 경우 동일 항목ID를 갖는 모든 확장자가 삭제된다. 투플(tuple; 항목ID, 확장ID)은 확장자 인스턴스를 고유하게 식별한다.

확장형의 구조는 항목 유형의 구조와 유사하다:

확장형은 필드를 갖는다;

필드는 고유 또는 중첩 요소 유형일 수 있다; 및

확장형은 서브타입화될 수 있다.

다음 제한이 확장형에 적용된다.

확장자는 관계의 소스 및 타겟일 수 없다;

확장형은 항목으로부터 독립하여 존재할 수 없다; 및

확장형은 스토리지 플랫폼 유형 정의에서 필드 유형으로서 사용될 수 없다.

해당 항목 유형에 관련될 수 없는 확장자 유형에 대한 제한은 없다. 임의의 확장형은 임의의 항목 유형을 확장할 수 있다. 다중 확장자 인스턴스가 항목에 첨부되면, 이들은 구조 및 동작 모두에서 서로 독립적이다.

확장형 인스턴스는 항목과 독립적으로 저장 및 액세스된다. 모든 확장형 인스턴스는 글로벌 확장자 보기로부터 액세스가능하다. 이들이 관련되는 항목 유형에 관계없이 확장자의 해당 유형의 모든 인스턴스를 리턴할 수 있는 효율적인 조회가 형성될 수 있다. 스토리지 플랫폼 API은 항목에 대한 확장자를 저장, 검색 및 변형할 수 있는 프로그래밍 모델을 제공한다.

확장형은 스토리지 플랫폼 단일 상속 모델을 사용하여 서브타입화된 유형일 수 있다. 확장형에서의 유도는 새로운 확장형을 생성한다. 확장자의 구조 또는 동작은 항목 유형 계층의 구조 또는 동작을 취소 또는 대체할 수는 없다. 항목 유형과 유사하게, 확장형 인스턴스는 확장형에 관련된 보기를 통해 직접 액세스될 수 있다. 확장자의 항목ID는 이들이 어느 항목에 속하고 글로벌 항목 보기로부터 대응하는 항목 객체를 검색하는데 사용될 수 있다. 확장자는 연산 일관성을 위해 항목의 일부로서 고려된다. 스토리지 플랫폼이 한정하는 복사/이동, 백업/복원 및 다른 일반 연산은 항목의 일부로서 확장자 상에 동작할 수 있다.

다음 예를 고려하자. 컨택 유형은 윈도우즈 유형 세트로 정의된다.

CRM 애플리케이션 개발자는 CRM 애플리케이션 확장자를 스토리지 플랫폼에 저장된 컨택으로의 첨부를 원할 수 있다. 애플리케이션 개발자는 애플리케이션이 조작할 수 있는 추가 데이터 구조를 포함할 수 있는 CRM 확장자를 한정할 수 있다.

HR 애플리케이션 개발자는 컨택을 사용하여 추가 데이터를 첨부하기를 원할 수 있다. 이러한 데이터는 CRM 애플리케이션 데이터와 독립적이다. 또한, 애플리케이션 개발자는 확장자를 생성할 수 있다.

CRM 확장자와 HR 확장자는 컨택 항목에 첨부될 수 있는 두 개의 독립 확장자이다. 이들은 서로 독립적으로 생성 및 액세스된다.

상기 예에서, CRM확장자 유형의 필드 및 메소드는 컨택 계층의 필드 또는 메소드를 취소할 수 없다. CRM확장자 유형의 인스턴스는 컨택이 아닌 항목 유형에 첨부될 수 있다.

컨택 항목이 검색되는 경우, 이의 항목 확장자는 자동으로 검색되지 않는다. 컨택 항목이 주어지면, 이의 관련 항목 확장자는 동일 항목ID를 갖는 확장자에 대하여 글로벌 확장자 보기를 조회함으로써 액세스될 수 있다.

모든 CRM확장 확장자는 시스템에서 이들이 어느 항목에 속하는지에 관계없이 CRM확장자 유형 보기를 통해 액세스될 수 있다. 항목의 모든 항목 확장자는 동일한 항목 id를 공유한다. 상기 예에서, 컨택 항목 인스턴스와 첨부된 CRM확장 및 HR확장은 동일한 확장ID를 인스턴스화한다.

다음 표는 항목, 확장자 및 중첩요소 유형 간의 유사 및 차이를 요약한다.

	항목	항목 확장자	중첩 요소
항목ID	자신의 항목 id를 가짐	항목의 항목 id를 공유	자신의 항목 id를 갖지 않음. 중첩 요소는 항목의 일부임
스토리지	항목 계층은 자신의 표에 저장됨	항목 확장자 계층은 자신의 표에 저장됨	항목으로 저장
조회/검색	항목 표를 조회할 수 있음	항목 확장자 표를 조회할 수 있음	포함하는 항목 문맥 내에서만 통상 조회될 수 있음
조회/검색 범위	항목 유형의 모든 인스턴스에 걸쳐 검색가능	항목 확장자 유형의 모든 인스턴스에 걸쳐 검색 가능	단일(포함) 항목의 중첩 요소 유형 내에서만 통상 검색가능
관계 의미	항목에 대한 관계를 가질 수 있음	항목 확장자에 대한 관계가 없음	중첩 요소에 대한 관계 없음
항목의 관계	홀딩, 임베디드 및 소프트 관계를 통해 다른 항목에 관련될 수 있음	확장자를 통해서만 통상 관련될 수 있음. 확장자 의미는 임베디드 항목 의미와 유사	필드를 통해 항목에 관련됨. 중첩 요소는 항목의 일부임

항목 vs 항목 확장자 vs 중첩요소

중첩 확장요소 유형의 확장

중첩 요소 유형은 확장자 유형과 동일한 메커니즘으로 확장되지는 않는다. 중첩 요소의 확장은 중첩 요소 유형의 필드와 동일한 메커니즘으로 저장 및 액세스될 수 있다.

데이터 모델은 요소로 명명된 중첩 요소 유형에 대한 루트를 정의한다:

중첩 요소 유형은 이 유형으로부터 상속한다. 중첩요소 요소 유형은 요소의 다중 집합인 필드를 추가적으로 정의한다.

중첩요소 확장자는 다음과 같은 방식으로 항목 확장자와 상이하다:

중첩 요소 확장자는 확장자 유형이 아니다. 이들은 베이스.확장자 유형에 기인한 확장자 유형 계층에 속하지 않는다.

중첩 요소 확장자는 항목의 다른 필드와 함께 저장되며 글로벌하게 액세스가능하지는 않는다 - 해당 확장형의 모든 인스턴스를 검색하는 조회는 형성될 수 없다.

이들 확장자는 (항목의) 다른 중첩 요소가 저장되는 것과 동일한 방식으로 저장된다. 다른 중첩 집합과 같이, 중첩요소 확장자는 UDT에 저장된다. 이들은 중첩 요소 유형의 확장자 필드를 통해 액세스가능하다.

여러 값의 속성을 액세스하는데 사용되는 모음 인터페이스는 일련의 유형 확장을 액세스하고 반복하는데 또한 사용된다.

다음 표는 항목 확장자와 중첩요소 확장자를 요약하여 비교한다.

	항목 확장자	중첩요소 확장자
스토리지	항목 확장자 계층은 그 자신의 표에 저장된다	중첩 요소와 같이 저장
조회/검색	항목 확장자 표를 조회가능	포함 항목 문맥 내에서만 통상 조회 가능
조회/검색 영역	항목 확장형의 모든 인스턴스에 걸쳐 검색가능	단일(포함) 항목의 중첩 요소 유형 인스턴스 내에서만 통상 검색가능
프로그래밍가능성	특정 확장자 API와 확장자 표에 대한 특별 조회를 요구	중첩요소 확장자는 중첩 요소의 임의의 다른 여러 값의 필드와 같음; 통상의 중첩 요소 유형 API가 사용됨
동작	동작을 관련시킬 수 있음	동작이 허용안됨(?)
관계 의미	항목 확장자에 대한 관계 없음	중첩요소 확장자에 대한 관계 없음
항목 ID	항목의 항목 id를 공유	그 자신의 항목 id를 갖지 않음. 중첩요소 확장자는 항목의 일부임.

항목 확장자 vs 중첩요소 확장자

D. 데이터베이스 엔진

상술한 바와 같이, 데이터 저장소는 데이터베이스 엔진 상에 구현된다. 본 실시예에서, 데이터베이스 엔진은 객체 관계 확장자를 갖는 SQL 조회 언어를 구현하는 마이크로소프트 SQL 서버 엔진은 관계 데이터베이스 엔진을 포함한다. 이 단락은 데이터 저장소가 구현하는 데이터 모델을 관계 저장소에 매핑하는 것을 나타내며, 본 실시예에 따라 스토리지 플랫폼 클라이언트에 의해 소비되는 논리적 API에 대한 정보를 제공한다. 그러나, 상이한 데이터베이스 엔진이 사용될 때 상이한 매핑이 사용될 수 있음을 알 수 있다. 즉, 관계 데이터베이스 엔진 상에서 스토리지 플랫폼 개념 데이터 모델을 구현하는 것에 더하여, 이는 다른 유형의 데이터베이스, 예를 들면, 객체 지향 및 XML 데이터베이스 상에서 구현될 수 있다.

객체 지향(OO) 데이터베이스 시스템은 프로그래밍 언어 객체(예를 들면, C++, 자바)에 대한 지속성 및 트랜잭션을 제공한다. "항목"의 스토리지 플랫폼 관념은 임베디드 모음이 객체에 추가되어야 하더라도 객체 지향 시스템에서 "객체"에 매핑한다. 상속 및 중첩 요소 유형과 같이 다른 스토리지 플랫폼 유형 개념은 또한 객체 지향 유형 시스템을 매핑한다. 객체 지향 시스템은 통상 객체 아이덴티티를 이미 지원하며, 이에 따라, 항목 아이덴티티는 객체 아이덴티티에 매핑될 수 있다. 항목 동작(연산)은 객체 메소드에 잘 매핑된다. 그러나, 객체 지향 시스템은 통상 구성 성능이 결여되고 검색이 열악하다. 또한, 객체 지향 시스템은 구조화되지 않고 반구조화(semi-structured)된 데이터에 대한 지원을 제공하지 않는다. 여기서 설명하는 완전한 스토리지 플랫폼 데이터 모델을 지원하기 위해서, 관계, 폴더 및 확장자와 같은 개념은 객체 데이터 모델에 추가될 필요가 있을 수 있다. 또한, 프로모션, 동기화, 통지 및 보안과 같은 메커니즘이 구현될 필요가 있을 수 있다.

객체 지향 시스템과 유사하게, XSD(XML 스키마 정의)에 따라, XML 데이터베이스는 단일 상속 기반 유형 시스템을 지원한다. 본 발명의 항목 유형 시스템은 XSD 유형 모델에 매핑될 수 있다. 또한, XSD는 동작에 대한 지원을 제공하지 않는다. 항목에 대한 XSD는 항목 동작에 추가되어야 할 수 있다. XML 데이터베이스는 단일 XSD 문서를 처리하고 구조 및 폭넓은 검색 성능이 결여된다. 객체 지향 데이터베이스와 마찬가지로, 여기서 설명하는 데이터 모델을 지원하기 위해서, 관계와 같은 다른 개념과 폴더는 이러한 XML 데이터베이스로 포함될 필요가 있을 수 있으며, 또한, 동기화, 통지 및 보안과 같은 메커니즘이 구현될 필요가 있을 수 있다.

후술하는 서브섹션에 대하여, 몇몇 설명이 개시된 일반적인 정보를 용이하게 하도록 제공된다: 도 13은 통지 메커니즘을 나타내는 도면이다. 도 14는 두 개의 트랜잭션이 새로운 기록을 동일 B-트리에 삽입하는 일 예를 나타낸다. 도 15는 데이터 변환 검출 프로세스를 나타낸다. 도 16은 예시적인 디렉토리 트리를 나타낸다. 도 17은 디렉토리 기반 파일 시스템의 기존 폴더가 스토리지 플랫폼 데이터 저장소에 이동되는 일 예를 나타낸다.

1. UDT를 사용하는 데이터 저장소 구현

본 실시예에서, 관계 데이터베이스 엔진(314)은 일 실시예에서 마이크로소프트 SQL 서버 엔진을 포함하는 것으로서 내장형 빌트인(built-in) 유형을 지원한다. 빌트인 스칼라 유형은 "고유"하고 "단순"하다. 이들은 사용자가 이들 자신의 유형을 한정할 수 없다는 의미에서 고유하고 이들이 복잡한 구조를 캡슐화할 수 없기 때문에 단순하다. 사용자 정의 유형(이하, UDT)은 사용자가 복잡하고 구조화된 유형을 한정하여 유형 시스템을 확장하게 할 수 있게 함으로써 공유 스칼라 유형 시스템 상하에 유형 확장성에 대한 메커니즘을 제공한다. 일단 사용자에 의해 정의되면, UDT는 빌트인 스칼라 유형이 사용되는 유형 시스템에서 임의의 곳에 사용될 수 있다.

본 발명의 양태에 따라, 스토리지 플랫폼 스키마는 데이터베이스 엔진 저장소에서 UDT 클래스에 매핑된다. 데이터 저장소 항목은 베이스.항목 유형으로부터 유도하는 UDT 클래스에 매핑된다. 항목과 같이, 확장자는 또한 UDT 클래스에 매핑되고 상속을 사용한다. 루트 확장형은 모든 확장형이 유도되는 베이스.확장이다.

UDT는 CLR 클래스이고 - 이는 상태(즉, 데이터 필드) 및 동작(즉, 루틴)을 갖는다. UDT는 관리형 언어 중 임의의 것을 사용하여 정의된다 - C#, VB.NET 등. UDT 메소드 및 연산자는 이 유형의 인스턴스에 대한 T-SQL로 호출될 수 있다. UDT는 행에서 열의 유형, T-SQL 내의 루틴의 파라미터 유형, 또는 T-SQL에서 변수의 유형일 수 있다.

스토리지 플랫폼 스키마의 UDT 클래스로의 매핑은 하이 레벨에서 상당히 직접적이다. 통상, 스토리지 플랫폼 스키마는 CLR 네임스페이스에 매핑된다. 스토리지 플랫폼 유형은 CLR 클래스에 매핑된다. CLR 클래스 상속은 스토리지 플랫폼 유형 상속을 반영하고, 스토리지 플랫폼 속성은 CLR 클래스 속성에 매핑된다.

2. 항목 매핑

항목이 글로벌하게 검색가능하게 되는 바람직한 상태와 상속 및 유형 대체가능성에 대한 본 발명의 관계 데이터베이스에서의 지원이 주어지면, 데이터베이스 저장소에서 항목 스토리지에 대한 하나의 가능한 구현이 베이스.항목의 유형의 열을 사용하여 단일 표에서 모든 항목을 저장하여야 할 것이다. 유형 대체가능성을 사용하여, 모든 유형의 항목이 저장될 수 있으며, 검색은 항목 유형에 의해 필터링될 수 있으며, 유콘(Yukon)의 "is of(Type)" 연산자를 사용하여 서브타입한다.

그러나, 본 실시예에서 이러한 접근법에 관련된 오버헤드에 대한 관련사항으로 인해, 항목이 정상 레벨 유형으로 나뉘며, 각 유형 "군(family)"의 항목은 개별 표에 저장된다. 이러한 구획 방식하에서, 베이스.항목으로부터 직접 상속하는 각 항목 유형에 대하여 표가 생성된다. 이들 하부에 상속하는 유형은 상술한 바와 같이 유형 대체가능성을 사용하여 적절한 유형군 표에 저장된다. 베이스.항목으로부터 상속의 제1 레벨만이 특별하게 다루어진다.

"섀도우" 표는 모든 항목에 대한 글로벌하게 검색가능한 속성의 복사본을 저장하는데 사용된다. 이 표는 모든 데이터 변환이 행해지는 스토리지 플랫폼 API의 갱신() 메소드에 의해 유지될 수 있다. 유형군 표와는 달리, 이러한 글로벌 항목 표는 완전한 UDT 항목 객체가 아닌 항목의 정상 레벨 스칼라 속성만을 포함한다. 글로벌 항목 표는 항목ID과 유형ID를 노출하여 유형군 표에 저장된 항목 객체로의 항해를 가능하게 한다. 항목ID는 데이터 저장소 내에서 항목을 고유하게 식별할 수 있다. 유형ID는 여기서 설명하지 않은 메타데이터를 사용하여 유형명과 항목을 포함하는 보기에 매핑될 수 있다. 이의 항목ID에 의해 항목을 발견하는 것은 일반 연산일 수 있기 때문에, 글로벌 항목 표의 경우, GetItem() 함수는 항목의 항목ID에 주어진 항목 객체를 검색하도록 제공된다.

편이한 액세스를 위해서 그리고 가능한 범위까지 구현 세부사항을 감추기 위해서, 모든 항목의 조회는 상술한 항목 표에 기초한 보기에 대한 것일 수 있다. 구체적으로, 보기는 적절한 유형군 표에 대한 각 항목 유형에 대하여 생성될 수 있다. 이들 유형 보기는 서브타입을 포함하는 관련 유형 중 모든 항목을 선택할 수 있다. 편이성을 위해서, UDT 객체에 더하여, 보기는 상속 필드 등의 유형의 정상 레벨 필드 모두에 대한 열을 노출할 수 있다.

3. 확장자 매핑

확장자는 항목에 매우 유사하며 동일 요건 일부를 갖는다. 상속을 지원하는 다른 루트 유형으로서, 확장자는 스토리지에서 많은 동일한 고려 및 협상을 겪게 된다. 이로 인해, 유사한 유형군 매핑이 단일 표 접근법이 아닌 확장자에 적용된다. 물론, 다른 실시예에서는, 단일 표 접근법이 사용될 수 있다. 본 실시예에서, 확장자는 항목ID에 의한 정확히 하나의 항목에 관련되고, 항목의 경우 공유한 확장ID를 포함한다. 항목과 마찬가지로, 함수는 이의 아이덴티티가 주어지면 확장자를 검색하도록 제공되며, 이 아이덴티티는 항목ID와 확장ID 쌍으로 이루어진다. 보기는 항목 유형 보기와 유사하게 각각의 확장형에 대해 생성된다.

4. 중첩 요소 매핑

중첩 요소는 항목, 확장, 관계 또는 다른 중첩 요소에 임베디드되어 깊게 중첩된 구조를 형성할 수 있는 유형이다. 항목 및 확장과 같이, 중첩 요소는 UDT로서 구현되지만, 이들은 항목 및 확장 내에서 저장된다. 따라서, 중첩 요소는 이들의 항목 및 확장 포함자를 넘어서는 어떤 스토리지 매핑도 갖지 않는다. 다시 말하면, 중첩요소 유형의 인스턴스를 직접 저장하는 시스템에서 표가 없고, 중첩 요소에 구체적으로 전용인 보기가 없다.

5. 객체 아이덴티티

데이터 모델, 즉, 각 항목, 확장자 및 관계 내의 각 엔티티는 공유 키 값을 갖는다. 항목은 항목Id에 의해 고유하게 식별된다. 확장자는 (항목Id, 확장Id)의 복합 키에 의해 고유하게 식별된다. 관계는 복합 키(항목Id, 관계Id)에 의해 식별된다. 항목Id, 확장Id, 및 관계Id는 GUID 값이다.

6. SQL 객체 명명

데이터 저장소에서 생성된 모든 객체는 스토리지 플랫폼 스키마명에서 유도된 SQL 스키마명에 저장될 수 있다. 예를 들면, 스토리지 플랫폼 베이스 스키마(종종, "베이스"로 불림)는 "[시스템.스토리지].항목"과 같은 "[시스템.스토리지]" SQL 스키마에 유형을 생성할 수 있다. 생성된 명칭은 적격자에 의해 프리픽스된 충돌의 명명을 제거한다. 적절한 경우, 느낌표(!)는 명칭의 각 논리적 부분에 대한 구분자로서 사용된다. 아래 표는 데이터 저장소에서 객체로서 사용되는 명명 규약을 요약한다. 각 스키마 요소(항목, 확장, 관계 및 보기)가 데이터 저장소에서 인스턴스를 액세스하는데 사용되는 장식된 명명 규약과 함께 열거된다.

객체	명칭 장식	설명	예
마스터 항목 검색 보기	마스터!항목	현재 항목 도메인에서 항목의 요약을 제공	[시스템.스토리지] [마스터!항목]
유형화된 항목 검색 보기	항목유형	항목 및 임의의 부 유형으로부터 모든 속성 데이터를 제공	[AcmeCorp.Doc] [OfficeDoc]
마스터 확장자 검색 보기	마스터!확장자	현재 항목 도메인에서 모든 확장자의 요약을 제공	[시스템.스토리지] [마스터!항목]
유형화된 확장자 검색 보기	확장!확장형	확장을 위한 모든 속성 데이터를 제공	[AcmeCorp.Doc] [확장!스티키노트]
마스터 관계 보기	마스터!관계	현재 항목 도메인에서 모든 관계의 요약을 제공	[시스템.스토리지] [마스터.관계]
관계 보기	관계!관계명	해당 관계에 관한 모든 데이터를 제공	[AcmeCorp.Doc] [관계!문서작성자]
보기	보기!보기명칭	스키마 보기 정의에 따라 열/유형을 제공	[AcmeCorp.Doc] [보기!문서제목]

7. 열 명명

임의의 모델을 저장소에 매핑하는 경우, 충돌 명명의 가능성은 애플리케이션 객체와 함께 저장된 추가 정보로 인해 발생한다. 명명 충돌을 방지하기 위해서, 모든 비유형 특정 열(유형 선언에서 명명된 속성에 직접 매핑하지 않은 열)은 밑줄(_) 문자로 프리픽스된다. 본 실시예에서, 밑줄(_) 문자는 임의의 식별자 속성의 개시 문자로서 허용되지 않는다. 또한, CLR과 데이터 저장소 간의 명명을 통합하기 위해서, 스토리지 플랫폼 유형 또는 스키마 요소(관계 등)의 모든 속성은 대문자의 첫 문자를 가져야 한다.

8. 검색 보기

보기는 저장된 컨텐츠를 검색하는 스토리지 플랫폼에 의해 제공된다. SQL 보기는 각 항목 및 확장형에 제공된다. 또한, 보기는 관계 및 보기(데이터 모델에 의해 정의된 바와 같이)를 지원하도록 제공된다. 모든 SQL 보기 및 스토리지 플랫폼에서 아래 표는 판독전용이다. 데이터는 아래에 보다 상세히 설명하는 바와 같이 스토리지 플랫폼 API의 갱신() 메소드를 사용하여 저장 또는 변경될 수 있다.

(스키마 설계자에 의해 정의되고, 스토리지 플랫폼에 의해 자동 생성되지 않은) 스토리지 플랫폼 스키마에서 명시적으로 한정된 각 보기는 명명된 SQL 보기[<T스키마명>].[보기![보기명>]을 사용하여 액세스가능할 수 있다. 예를 들면, 스키마 "AcmePublisher.Books"에서 보기 명명의 "BookSales"는 명칭 "[AcmePublisher.Books].[View!BookSales]"를 사용하여 액세스가능하다. 보기의 출력 포맷은 (보기를 정의하는 측에 의해 제공되는 임의의 조회에 의해 정의됨)보기당 기준 상에서 흔하기 때문에, 열은 스키마 보기 정의에 기초하여 직접 매핑된다.

모든 SQL 검색 보기는 스토리지 플랫폼 데이터 저장소에서 열에 대한 다음의 정렬 규약을 사용한다:

항목Id, 요소Id, 관계Id 등의 보기 결과의 논리적 "키" 열(들).

유형Id와 같은 결과 유형에 대한 메타데이터 정보.

버전생성, 버전갱신과 같은 추적 열을 변경.

유형 특정 열(들)(선언형의 속성)

유형 특정 보기(군 포기)는 객체를 리턴하는 객체 열을 포함

각 유형군의 멤버는 데이터 저장소에서 항목 유형당 하나의 보기인, 일련의 항목 보기를 사용하여 검색가능하다. 도 28은 항목 검색 보기의 개념을 나타내는 도면이다.

항목

각 항목 검색 보기는 특정 유형 또는 이의 서브타입의 항목의 각 인스턴스에 대한 행을 포함한다. 예를 들면, 문서 보기는 문서, 법적문서, 및 문서다시보기의 인스턴스를 리턴할 수 있다. 이 예가 주어지면, 항목 보기는 도 29에서 나타낸 바와 같이 개념화될 수 있다.

(1) 마스터 항목 검색 보기

스토리지 플랫폼 데이터 저장소의 각 인스턴스는 마스터 항목.보기로 불리는 특정 항목 보기를 한정한다. 이 보기는 데이터 저장소에서 각 항목에 대한 요약 정보를 제공한다. 보기는 항목 유형 속성당 하나의 열을 제공하며, 이 열은 항목 유형을 나타내고, 이의 여러 열은 변경 추적 및 동기화 정보를 제공하는데 사용된다. 마스터 항목 보기는 명칭 "[시스템.스토리지].[마스터!항목]"을 사용하여 데이터 저장소에서 식별된다.

열	유형	설명
항목Id	항목Id	항목의 스토리지 플랫폼 아이덴티티
_유형Id	유형Id	항목의 유형Id - 항목의 정확한 유형을 식별하고 메타데이터 카탈로그를 사용하여 유형에 대한 정보를 검색하는데 사용될 수 있다.
_루트항목Id	항목Id	이 항목의 수명을 제어하는 제1 비 임베디드 원형의 항목Id
<글로벌 변경 추적>	...	글로벌 변환 추적 정보
<항목 속성>	n/a	항목 유형 속성당 하나의 열

(2) 유형화된 항목 검색 보기

각 항목 유형은 또한 검색 보기를 갖는다. 루트 항목 보기와 유사하게, 이러한 보기는 "_항목" 열을 통해 항목 객체로의 액세스를 제공한다. 각각의 유형화된 항목 검색 보기는 명칭 [스키마명].[항목유형명]을 사용하여 데이터 저장소에 식별된다. 예를 들면, [AcmeCorp.Doc].[OffDoc].

열	유형	설명
항목Id	항목Id	항목의 스토리지 플랫폼 아이덴티티
<유형 변경 추적>	...	유형 변경 추적 정보
<부 속성>	<속성 특정>	부 속성 당 하나의 열
<항목 속성>	<속성 특정>	이러한 유형의 배타적 속성 당 하나의 열
_항목	항목의 CLR 유형	CLR 객체 - 선언 항목의 유형

9. 항목 확장자

또한, WinFS 저장소에서 모든 항목 확장자는 검색 보기를 사용하여 액세스가능하다.

(1) 마스터 확장자 검색 보기

데이터 저장소의 각 인스턴스는 마스터 확장자 보기로 불리는 특별 확장자 보기를 한정한다. 이러한 보기는 데이터 저장소에서 각 확장자에 대한 요약 정보를 제공한다. 이 보기는 확장 속성당 열을 가지며, 이 열은 확장자 유형을 나타내고 이의 여러 열은 변경 추적 및 동기화 정보를 제공하는데 사용된다. 마스터 확장자 보기는 명칭 "[시스템.스토리지].[마스터!확장자]"를 사용하여 데이터 저장소에 식별된다.

열	유형	설명
항목Id	항목Id	이 확장이 관련된 항목의 스토리지 플랫폼 아이덴티티
확장Id	확장Id(GUID)	이러한 확장자 인스턴스의 Id
_유형Id	유형Id	확장의 유형Id - 확장의 정확한 유형을 식별하고 메타데이터 카탈로그를 사용하여 확장자에 대한 정보를 검색하는데 사용될 수 있다ㅣ
<글로벌 변경 추적>	...	글로벌 변경 추적 정보
<외부 속성>	<속성 특정>	확장형 속성 당 하나의 열

10. (1) 유형화된 확장 검색 보기

각 확장형은 또한 검색 보기를 갖는다. 마스터 확장자 보기와 유사하지만, 이러한 보기는 또한 _확장 열을 통해 항목 객체로의 액세스를 제공한다. 각각의 유형화된 확장은 명칭 [스키마명].[확장!확장형명]을 사용하여 데이터 저장소에 식별된다. 예를 들면, [AcmeCorp.Doc].[확장!OfficeDocExt].

열	유형	설명
항목Id	항목_Id	확장이 관련된 항목의 스토리지 플랫폼 아이덴티티
확장Id	확장Id(GUID)	이러한 확장자 인스턴스의 Id
<유형 변경 추적>	...	유형 변경 추적 정보
<부 속성>	<속성 특정>	부 속성 당 하나의 열
<외부 속성>	<속성 특정>	이러한 유형의 배타적 속성 당 하나의 열
_확장	확장자 인스턴스의 CLR 유형	CLR 객체 - 선언된 확장자의 유형

중첩 요소

모든 중첩 요소는 항목, 확장자 또는 관계 인스턴스 내에 저장된다. 이와 같이, 이들은 적절한 항목, 확장자 또는 관계 검색 보기를 조회하여 액세스된다.

관계

상술한 바와 같이, 관계는 스토리지 플랫폼 데이터 저장소에서 항목들 간의 연결의 기본 단위를 형성한다.

(2) 마스터 관계 검색 보기

각 데이터 저장소는 마스터 관계 보기를 제공한다. 이러한 보기는 데이터 저장소에서 모든 관계 인스턴스에 대한 정보를 제공한다. 마스터 관계 보기는 명칭 "[시스템.스토리지].[마스터!관계]를 사용하여 데이터 저장소 내에 식별된다.

열	유형	설명
항목Id	항목Id	소스 종점의 아이덴티티(항목Id)
관계Id	관계Id(GUID)	관계 인스턴스의 id
_RelTypeId	관계 유형Id	관계의 RelTypeId - 메타데이터 카탈로그를 사용하여 관계 인스턴스의 유형을 식별
<글로벌 변경 추적>	...	글로벌 변경 추적 정보
타겟항목참조	항목참조	타겟 정보의 아이덴티티
_관계	관계	이러한 인스턴스에 대한 관계 객체의 인스턴스

(3) 관계 인스턴스 검색 보기

또한, 각각의 선언된 관계는 검색 보기를 가지며, 이는 특정 관계의 모든 인스턴스를 리턴한다. 마스터 관계 보기와 유사하게, 이 보기는 또한 관계 데이터의 각 속성에 대한 명명된 열을 제공한다. 각 관계 인스턴스는 명칭 [스키마명].[관계!관계명]을 사용하여 데이터 저장소에서 식별된다. 예를 들면, [AcmeCorp.Doc]. [관계!문서작성자].

열	유형	설명
항목Id	항목Id	소스 종점의 아이덴티티(항목Id)
관계Id	관계Id (GUID)	관계 인스턴스의 id
<유형 변경 추적>	...	유형 변경 추적 정보
타겟항목참조	항목참조	타겟 종점의 아이덴티티
<소스명>	항목Id	소스 종점 아이덴티티의 명명된 속성(항목Id의 별칭)
<타겟명>	항목참조 또는 유도 클래스	타겟 종점 아이덴티티의 명명된 속성(타겟항목참조의 약칭 및 캐스트)
<rel 속성>	<속성 특정>	관계 정의의 속성당 하나의 열
_관계	관계 인스턴스의 CLR 유형	CLR 객체 - 선언 관계의 유형

11. 갱신

스토리지 플랫폼 데이터 저장소에서 모든 보기는 판독 전용이다. 데이터 모델 요소(항목, 확장자 또는 관계)의 모든 인스턴스를 생성하기 위해서, 또는 기존 인스턴스를 갱신하기 위해서, 스토리지 플랫폼 API의 처리동작 또는 처리갱신 메소드는 사용되어야 한다. 처리동작 메소드는 수행될 동작을 상세하게 하는 "연산"을 소모하는 데이터 저장소에 한정된 단일 저장 절차이다. 처리갱신 메소드는 "갱신(updategram)"으로 알려진 정렬된 일련의 연산을 취하는 저장된 절차이며, 이는 수행될 일련의 동작을 일괄하여 상세히 설명한다.

연산 포맷은 확장가능하며, 스키마 요소에 대하여 여러 연산을 제공한다. 몇몇 일반 연산은 다음을 포함한다:

1. 항목 연산:

a. 항목생성(임베딩 또는 홀딩 관계의 경우 새로운 항목을 생성)

b. 항목갱신(기존 항목을 갱신)

2. 관계 연산:

a. 관계생성(참조 또는 홀딩 관계의 인스턴스를 생성)

b. 관계갱신(관계 인스턴스를 갱신)

c. 관계삭제(관계 인스턴스를 제거)

3. 확장 연산:

a. 확장생성(기존 항목에 확장을 추가)

b. 확장갱신(기존 확장을 갱신)

c. 확장삭제(확장을 삭제)

12. 변경 추적 & 툼스톤(tombstone)

변경 추적 및 툼스톤 서비스는 보다 상세히 후술하는 바와 같이 데이터 저장소에 의해 제공된다. 변경 추적은 데이터 저장소에 노출된 변경 추적 정보의 요약을 제공한다.

변경 추적

데이터 저장소에 의해 제공된 각각의 검색 보기는 변경 추적 정보를 제공하는데 사용되는 열을 포함하며, 이 열은 모든 항목, 확장자 및 관계 보기에 걸쳐 일반적이다. 스토리지 플랫폼 스키마 보기는 스키마 설계자에 의해 명시적으로 한정되며 변경 추적 정보를 자동으로 제공하지는 않으며, 이러한 정보는 보기 자체가 구축된 검색 보기를 통해 간접적으로 제공된다.

데이터 저장소 내의 각 요소에 대하여, 변경 추적 정보는 두 개의 장소, 즉, "마스터" 요소 보기와 "유형화된" 요소 보기에서 이용가능하다. 예를 들면, AcmeCorp.문서.문서 항목 유형에 대한 변경 추적 정보는 마스터 항목 보기 "[시스템.스토리지].[마스터!항목]"과 유형화된 항목 검색 보기 [AcmeCorp.문서].[문서]에서 이용가능하다.

(1) "마스터" 검색 보기에서 변경 추적

마스터 검색 보기에서 변경 추적 정보는 요소의 생성 및 갱신 버전과 어느 동기 파트너가 요소를 생성했는지에 대한 정보, 어느 동기 파트너가 요소와 생성 및 갱신을 위한 각 파트너로부터 버전 수치를 마지막으로 갱신했는지에 대한 정보를 제공한다. 동기 관계(후술함)에서 파트너는 파트너 키로 식별된다. [시스템.스토리지.저장소].변경추적정보 유형의 _변경추적정보로 명명된 단일 UDT 객체는 이 모든 정보를 포함한다. 이 영은 시스템.스토리지.스키마에서 한정된다. _변경추적정보는 항목, 확장자 및 관계에 대한 모든 글로벌 검색 보기에서 이용가능하다. 변경추적정보에서 유형 정의는 다음과 같다:

이들 속성은 다음 정보를 포함한다:

열	설명
_로컬TS생성	로컬 머신에 의한 타임 스탬프의 생성
_파트너키생성	이러한 엔티티를 생성한 파트너의 파트너키. 엔티티가 로컬 생성되면, 이는 로컬 머신의 파트너키이다.
_파트너TS생성	이 엔티티가 _파트너키생성에 대응하는 파트너에서 생성된 시점의 타임스탬프
_로컬TS최종갱신	로컬 머신에서 갱신 시간에 대응하는 로컬 타임스탬프
_파트너키최종갱신	이러한 엔티티를 최종 갱신한 파트너의 파트너키. 엔티티에 대한 최종 갱신이 로컬 수행되면, 이는 로컬 머신의 파트너키이다.
_파트너TS최종갱신	이러한 엔티티가 _파트너키최종갱신에 대응하는 파트너에서 갱신하는 시점의 타임스탬프.

(2) "유형화된" 검색 보기에서 변경 추적

글로벌 검색 보기와 동일한 정보를 제공할 뿐만 아니라, 각각의 유형화된 검색 보기는 동기 토폴로지에서 각 요소의 동기 상태를 기록하는 추가 정보를 제공한다.

열	유형	설명
<글로벌 변경 추적>	...	글로벌 변경 추적에서의 정보
_변경 단위 버전	멀티세트<변경 단위 버전>	특정 요소 내의 변경 단위의 버전 수치의 설명
_요소동기메타데이터	요소동기메타데이터	동기화 런타임에만 관심있는 이 항목에 대한 추가 버전 독립 메타데이터
_버전동기메타데이터	버전동기메타데이터	동기화 런타임에만 관심있는 이 버전에 대한 추가 버전 특정 메타데이터

툼스톤

데이터 저장소는 항목, 확장자 및 관계에 대한 툼스톤 정보를 제공한다. 툼스톤 보기는 일 장소에서 라이브 및 툼스톤 엔티티(항목, 확장자 및 관계)에 대한 정보를 제공한다. 항목 및 확장 툼스톤 보기는 대응 객체로의 액세스를 제공하지 않지만, 관계 툼스톤은 관계 객체로의 액세스를 제공한다(관계 객체는 툼스톤 관계의 경우 NULL이다).

(3) 항목 툼스톤

항목 툼스톤은 보기 [시스템.스토리지].[툼스톤!항목]을 통해 시스템으로부터 검색된다.

열	유형	설명
항목Id	항목Id	항목 아이덴티티
_유형ID	유형Id	항목 유형
<항목 속성>	...	모든 항목에 대하여 한정된 속성
_룸항목Id	항목Id	이 항목을 포함하는 제1 비 임베딩 항목의 항목Id
_변경추적정보	유형 변경추적 정보의 CLR 인스턴스	이 항목에 대한 변경 추적 정보
_삭제여부	BIT	라이브 항목에 대하여 O이고 툼스톤 항목에 대하여 1인 플래그
_월클락삭제	UTC날짜시간	UTC는 항목을 삭제한 파트너에 따라 날짜 시간을 월클락한다. 이는 항목이 라이브이면 NULL이다.

(4) 확장 툼스톤

확장 툼스톤은 보기 [시스템.스토리지].[툼스톤!확장]을 사용하여 시스템에서 검색된다. 확장 변경 추적 정보는 확장Id 속성의 추가를 항목에 제공된 것과 유사하다.

열	유형	설명
항목Id	항목Id	확장을 소유하는 항목의 아이덴티티
확장Id	확장Id	확장의 확장Id
_유형ID	유형Id	확장의 유형
_변경추적정보	변경추적정보 유형의 CLR 인스턴스	이러한 확장에 대한 변경 추적 정보
_삭제여부	BIT	라이브 항목에 대하여 0이고 툼스톤 확장에 대하여 1인 플래그
_월클락삭제	UTC날짜시간	UTC는 확장을 삭제한 파트너에 따라 날짜시간을 월클락한다. 이는 확장이 라이브이면 NULL이다.

(5) 관계 툼스톤

관계 툼스톤은 보기 [시스템.스토리지].[툼스톤!관계]를 통해 시스템에서 검색된다. 관계 툼스톤 정보는 확장에 제공된 것과 유사한다. 그러나, 추가 정보는 관계 인스턴스의 타겟 항목참조에 대하여 제공된다. 또한, 관계 객체가 또한 선택된다.

열	유형	설명
항목Id	항목Id	관계를 소유한 항목의 아이덴티티(관계 소스 종점의 아이덴티티)
관계Id	관계Id	관계의 관계Id
_유형ID	유형Id	관계 유형
_변경추적정보	유형 변경추적정보의 CLR 인스턴스	이 관계에 대한 변경 추적 정보
_삭제여부	BIT	라이브 항목에 대하여 0이고 툼스톤 항목에 대하여 1인 플래그
_삭제월클락	UTC날짜시간	UTC는 관계를 삭제한 파트너에 따라 날짜 시간을 월클락한다. 이는 관계가 라이브이면 NULL이다.
_관계	관계의 CLR 인스턴스	라이브 관계에 대한 관계 객체이다. 툼스톤 관계에 대하여 NULL이다.
타겟항목참조	항목참조	타겟 종점의 아이덴티티

(6) 툼스톤 소거

툼스톤 정보의 무한정 성장을 방지하기 위해서, 데이터 저장소는 툼스톤 소거 작업을 제공한다. 이러한 작업은 툼스톤 정보가 폐기될 수 있는 때를 결정한다. 이 작업은 로컬 생성/갱신 버전에 대한 한계를 계산한 후 모든 이전 툼스톤 버전을 폐기하여 툼스톤 정보를 절단한다.

13. 도움말 API 및 함수

베이스 매핑은 또한 다수의 도움말 함수를 제공한다. 이들 함수는 데이터 모델에 대하여 일반 연산을 지원하도록 제공된다.

함수 [시스템.스토리지].항목얻기

//항목Id가 주어지면 항목 객체를 리턴

//

Item GetItem(ItemId ItemId)

함수 [시스템.스토리지].확장얻기

//항목Id 및 확장Id가 주어지면 확장 객체를 리턴

//

Extension GetExtension(ItemId ItemId, ExtensionId ExtensionId)

함수 [시스템.스토리지].관계얻기

//항목Id와 확장Id가 주어지면 관계 객체를 리턴

//

Relationship GetRelationship(ItemId ItemId, RelationshipId RelationshipId)

14. 메타데이터

저장소로 표현된 두 종류의 메타데이터가 있다: 인스턴스 메타데이터(항목 유형 등), 및 유형 메타데이터.

스키마 메타데이터

스키마 메타데이터는 메타 스키마로부터 항목 유형의 인스턴스로서 데이터 저장소에 저장된다.

인스턴스 메타데이터

인스턴스 메타데이터는 항목의 유형에 대하여 조회에 대한 애플리케이션에 의해 사용되고 항목에 관련된 확장을 발견한다. 항목에 대한 항목Id가 주어지면, 애플리케이션은 글로벌 항목 보기를 조회하여 항목의 유형을 리턴할 수 있고 이 값을 사용하여 메타.유형 보기를 조회하고 항목의 선언형에 대한 정보를 리턴한다. 예를 들면,

//해당 항목 인스턴스에 대하여 메타데이터 항목 객체를 리턴

//

SELECT m._Item AS metadataInfoObj

FROM [System.Storage].[Item]i INNER JOIN [Meta].[Type] m ON i._TypeId=m.ItemId

WHERE i.ItemId=@ItemId

E. 보안

통상, 보든 보안가능 객체는 도 26에서 나타낸 액세스 마스크 포맷을 사용하여 이들의 액세스 권한을 구성한다. 이 포맷에서, 낮은 차수의 16비트는 객체 특정 액세스 권한에 대한 것이며, 다음 7비트는 대부분의 객체 유형에 적용되는 표준 액세스 권한에 대한 것이며, 4개의 고차 비트는 각 객체형을 일련의 표준과 객체 특정 권한을 매핑할 수 있는 일반 액세스 권한을 규정하는데 사용된다. ACCESS_SYSTEM_SECURITY 비트는 객체의 SACL을 액세스하는 권한에 대응한다.

도 26의 액세스 마스크 구조에서, 항목 특정 권한은 객체 특정 권한 단락(저차 16 비트)에 배치된다. 본 실시예에서 스토리지 플랫폼은 두 개의 API 세트를 노출하여 보안 - Win32와 스토리지 플랫폼 API - 를 관리하기 때문에, 파일 시스템 객체 특정 권한은 스토리지 플랫폼 객체 특정 권한의 설계를 촉진하기 위해서 고려되어야 한다.

본 발명의 스토리지 플랫폼에 대한 보안 모델은 여기서 이전에 참조로 포함되는 관련 출원에서 완전히 설명된다. 이 점에서, 도 27a 내지 도 27c는 보안 모델의 일 실시예에 따라 기존 보안 영역에서 산출된 새롭게 동일하게 보호된 보안 영역을 나타낸다.

F. 통지 및 변경 추적

본 발명의 다른 양태에 따르면, 스토리지 플랫폼은 애플리케이션이 데이터 변경을 추적할 수 있게 하는 통지 성능을 제공한다. 이 특성은 휘발성 상태를 유지하거나 데이터 변경 이벤트에 대한 비즈니스 논리를 실행하는 애플리케이션에 대하여 주로 의도된 것이다. 애플리케이션은 항목, 항목 확장 및 항목 관계에 대한 통지에 대하여 등록한다. 통지는 데이터 변경이 위임된 후에 비동기로 전달된다. 애플리케이션은 항목, 확장자 및 관계 유형뿐만 아니라 연산 유형별로 통지를 필터링할 수 있다.

일 실시예에 따라, 스토리지 플랫폼 API(332)는 통지에 두 종류의 인터페이스를 제공한다. 첫째는, 항목, 항목 확장 및 항목 관계에 대한 변경에 의해 트리거되는 단순 데이터 변경 이벤트에 대하여 애플리케이션을 등록한다. 둘째, 애플리케이션은 "감시자" 객체를 생성하여 일련의 항목, 항목 확장, 및 항목들 간의 관계를 감시한다. 감시자 객체의 상태는 시스템 실패 후에 또는 시스템이 연장된 시간에 대하여 오프라인이 된 후에 저장되어 재생성될 수 있다. 단일 통지는 여러 갱신을 반영할 수 있다.

이러한 기능에 대한 추가 세부사항은 여기서 이전에 참조로 포함된 관련 애플리케이션에 발견될 수 있다.

G. 종래 파일 시스템 상호 운용성

상술한 바와 같이, 적어도 몇몇 실시예에서, 본 발명의 스토리지 플랫폼은 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템의 핵심부로서 구체화하려는 것이다. 예를 들면, 본 발명의 스토리지 플랫폼은 운영 체제의 마이크로소프트 윈도우즈 패밀리와 같은 운영 체제의 핵심부로서 구체화될 수 있다. 이 용량에서, 스토리지 플랫폼 API는 애플리케이션 프로그램이 운영 체제와 상호동작하는 운영 체제 API의 일부가 된다. 따라서, 스토리지 플랫폼은 애플리케이션이 운영 체제에 대한 정보를 저장하는 수단이 되고, 따라서 스토리지 플랫폼의 항목 기반 데이터 모델은 이러한 운영 체제의 종래 파일 시스템을 대체한다. 예를 들면, 운영 체제의 마이크로소프트 윈도우즈 패밀리에서 구체화된 경우와 같이, 스토리지 플랫폼은 이 운영 체제로 구현된 NTFS 파일 시스템을 대체할 수 있다. 현재, 애플리케이션 프로그램은 운영 체제의 윈도우즈 패밀리에 의해 노출된 Win32 API를 통해 NTFS 파일 시스템의 서비스를 액세스한다.

그러나, 본 발명의 스토리지 플랫폼으로 NTFS 파일 시스템을 완전히 대체하는 것은 인식하는 것은 기존 Win32 기반 애플리케이션 프로그램의 기록을 요구할 수 있으며, 이러한 기록이 바람직하지 않을 수 있다는 점을 고려하면, 본 발명의 스토리지 플랫폼은 NTFS와 같은 기존 파일 시스템과의 일부 상호 운용성을 제공하는 것이 이로울 수 있다. 따라서, 본 발명의 일 실시예에서, 스토리지 플랫폼은 Win32 프로그래밍 모델에 의존하는 애플리케이션 프로그램이 스토리지 플랫폼의 데이터 저장소와 종래 NTFS 파일 시스템의 컨텐츠를 액세스할 수 있게 한다. 이를 위해, 스토리지 플랫폼은 Win32 명명 규약의 수퍼세트인 명명 규약을 사용하여 용이한 상호 운용성을 용이하게 한다. 또한, 스토리지 플랫폼은 Win32 API를 통해 스토리지 플랫폼 볼륨에 저장된 파일 및 디렉토리 액세스를 지원한다.

이러한 기능에 관한 추가적인 세부사항은 여기서 이전에 참조로서 포함된 관련 출원에서 발견될 수 있다.

H. 스토리지 플랫폼 API

스토리지 플랫폼은 애플리케이션 프로그램이 상술한 스토리지 플랫폼의 특성 및 성능을 액세스할 수 있게 하고 데이터 저장소에 저장된 항목을 액세스할 수 있게 하는 API를 포함한다. 본 단락은 본 발명의 스토리지 플랫폼의 스토리지 플랫폼 API의 일 실시예를 나타낸다. 이 기능에 관한 세부사항은 여기서 참조로 포함된 관련 애플리케이션에서 발견될 수 있으며, 이 정보 중 일부는 편이를 위해 아래 요약한다.

도 18을 참조하면, 포함 폴더는 다른 항목에 홀딩 관계를 포함하는 항목이고 파일 시스템 폴더의 일반 개념의 등가물이다. 각 항목은 적어도 하나의 포함 폴더 내에 "포함된다".

도 19는 본 발명에 따라 스토리지 플랫폼 API의 기본 아키텍처를 나타낸다. 스토리지 플랫폼 API는 SQL클라이언트(1900)를 사용하여 로컬 데이터 저장소(302)에 대화하며, 또한 SQL클라이언트(1900)를 사용하여 원격 데이터 저장소(예를 들면, 데이터 저장소(340))에 대화할 수 있다. 로컬 저장소(302)는 또한 DQP(분산 조회 처리기)를 사용하여 또는 후술하는 스토리지 플랫폼 동기화 서비스("Sync")를 통해 원격 데이터 저장소(340)에 대화할 수 있다. 상술한 바와 같이, 스토리지 플랫폼 API(332)는 또한 데이터 저장소 통지, 애플리케이션 구독의 통지 엔진(332)으로의 전달, 및 통지의 애플리케이션(예를 들어, 애플리케이션 350a, 350b 또는 350c)으로의 라우팅을 위한 브리지 API로서 동작한다. 일 실시예에서, 스토리지 플랫폼 API(322)는 마이크로소프트 익스체인지 및 AD를 액세스할 수 있도록 한정된 "제공자" 아키텍처를 한정할 수 있다.

도 20은 스토리지 플랫폼 API의 다양한 컴포넌트를 개략적으로 나타낸다. 스토리지 플랫폼 API는 다음 컴포넌트, 즉, (1) 스토리지 플랫폼 요소 및 항목 유형을 나타내는 데이터 클래스(2002), (2) 객체 지속성을 관리하고 지원 클래스(2006)를 제공하는 런타임 프레임워크(2004); 및 (3) 스토리지 플랫폼 스키마로부터 CLR 클래스를 생성하는데 사용되는 도구(2008)로 이루어진다.

해당 스키마에 기인한 계층은 이 스키마에서 유형의 계층을 직접 반영한다. 일 예로서, 도 21a 및 도 21b에서 도시한 바와 같은 컨택 스키마에서 한정된 항목 유형을 고려하자.

도 22는 동작 중인 런타임 프레임워크를 나타낸다. 런타임 프레임워크는 다음과 같이 동작한다:

1. 애플리케이션(350a, 350b 또는 350c)은 스토리지 플랫폼 내의 항목에 결합한다.

2. 프레임워크(2004)는 한계 항목에 대응하여 항목문맥 객체(2202)를 생성하고 이를 애플리케이션에 리턴한다.

3. 애플리케이션은 이 항목문맥에 대한 발견을 제출하여 항목 모음을 획득한다; 리턴된 모음은 (관계로 인해)개념적으로 객체 그래프(2204)이다.

4. 이 애플리케이션은 데이터를 변경, 삭제 및 삽입한다.

5. 애플리케이션은 갱신() 메소드를 호출하여 변경을 저장한다.

도 23은 "FindAll" 연산의 실행을 나타낸다.

도 24는 스토리지 플랫폼 API 클래스가 스토리지 플랫폼 스키마로부터 생성되는 프로세스를 나타낸다.

도 25는 파일 API가 기초로 하는 스키마를 나타낸다. 스토리지 플랫폼 API는 파일 객체를 다루는 네임스페이스를 포함한다. 이러한 네임스페이스는 시스템.스토리지.파일이라 불린다. 시스템.스토리지.파일에서 클래스의 데이터 멤버는 스토리지 플랫폼 저장소에 저장된 정보를 직접 반영하며, 이 정보는 파일 시스템 객체로부터 "프로모션"되고, Win32 API를 사용하여 고유하게 생성될 수 있다. 시스템.스토리지.파일 네임스페이스는 두 개의 클래스, 즉, 파일항목과 디렉토리항목을 갖는다. 이들 클래스의 멤버와 이의 메소드는 도 25에서 개략도에 의하면 용이하게 예측될 수 있다. 파일항목과 디렉토리항목은 스토리지 플랫폼 API로부터 판독 전용이다. 이들을 변형하기 위해서, Win32 API 또는 시스템.IO에서 클래스를 사용하여야 한다.

API에 있어서, 프로그래밍 인터페이스(또는 보다 간단하게는, 인터페이스)는 하나 이상의 코드 세그먼트가 하나 이상의 코드 세그먼트에 의해 제공된 기능과 통신하거나 이에 액세스할 수 있게 하는 임의의 메커니즘, 프로세스, 프로토콜로서 간주될 수 있다. 다르게는, 프로그래밍 인터페이스는 다른 컴포넌트의 하나 이상의 메커니즘(들), 메소드(들), 함수 호출(들), 모듈(들) 등에 통신 결합이 가능한 시스템의 컴포넌트의 하나 이상의 메커니즘(들), 메소드(들), 함수 호출(들), 모듈(들), 객체(들)로서 간주될 수 있다. 이전 문장에서 "코드 세그먼트"라는 용어는 하나 이상의 명령 또는 코드 라인을 포함하려는 것이며, 적용된 용어에 관계없이 또는 코드 세그먼트가 개별적으로 컴파일되는지, 또는 코드 세그먼트가 소스, 중간 또는 객체 코드로서 제공되는지, 코스 세그먼트가 런타임 시스템 또는 프로세스에 사용되는지 또는 이들이 여러 머신에 걸쳐 분산되거나 동리 또는 상이한 머신 상에 배치되는지, 또는 코드 세그먼트에 의해 표현된 기능이 완전히 소프트웨어, 완전히 하드웨어, 또는 하드웨어 및 소프트웨어의 조합으로 구현되는지에 관계없이, 예를 들면, 코드 모듈, 객체, 서브루틴, 함수 등을 포함한다.

개념적으로, 프로그래밍 인터페이스는 도 30a 또는 도 30b에 도시한 바와 같이 일반적으로 관측될 수 있다. 도 30a는 제1 및 제2 코드 세그먼트가 통신하는 도관으로서 인터페이스(인터페이스1)를 나타낸다. 도 30b는 시스템의 제1 및 제2 코드 세그먼트가 매체 M을 통해 통신할 수 있게 하는 인터페이스 객체(I1 및 I2; 제1 및 제2 코드 세그먼트의 일부이거나 일부가 아닐 수 있음)를 포함하는 것으로서 인터페이스를 나타낸다. 도 30b의 관점에서, 동일 시스템의 별도 인터페이스로서 인터페이스 객체(I1 및 I2)를 고려할 수 있으며, 또한 객체(I1과 I2)와 매체 M의 합이 인터페이스를 포함한다고 고려할 수 있다. 도 30a 및 도 30b가 양방향성 흐름과 이 흐름의 각 측면 상의 인터페이스를 나타내지만, 특정 구현예는 일 방향으로 정보 흐름만을 가질 수 있으며(또는 후술하는 바와 같이 정보 흐름이 없음), 또는 일 측 상의 인터페이스 객체만을 가질 수 있다. 한정이 아닌 예를 들면, 애플리케이션 프로그래밍 인터페이스(API), 엔트리 포인트, 메소드, 함수, 서브루틴, 원격 절차 호출 및 컴포넌트 객체 모델(COM) 인터페이스와 같은 용어는 프로그래밍 인터페이스의 정의 내에 포함된다.

이러한 프로그래밍 인터페이스의 양태는 제1 코드 세그먼트가 정보("정보"는 최광역의 의미로서 사용되고 데이터, 명령, 요청을 포함함)를 제2 코드 세그먼트에 전송하는 메소드; 제2 코드 세그먼트가 정보를 수신하는 메소드; 및 정보의 구조, 시퀀스, 구문, 기관, 스키마, 타이밍 및 컨텐츠를 포함할 수 있다. 이 점에서, 하부 전송 매체 자체는 매체가 유선인지 무선인지 또는 이 둘의 조합인지에 관계없이 정보가 인터페이스에 의해 한정된 방식으로 전송되는 한 인터페이스의 동작에 중요하지 않을 수 있다. 특정 경우, 정보 전송이 하나의 코드 세그먼트가 제2 코드 세그먼트에 의해 수행되는 기능을 액세스함에 따라 다른 메커니즘(예를 들면, 버퍼, 파일 등에 배치되고 코드 세그먼트 간의 정보 흐름과는 구별된 정보)을 통해서나 비존재에 있을 수 있다. 이들의 임의의 또는 모든 양태는 해당 상황, 예를 들면, 코드 세그먼트가 약하게 또는 강하게 결합된 구성에서 시스템의 일부인지에 따라 중요할 수 있으며, 따라서, 이 리스트는 예시적이며 한정적이지 않은 것으로 간주되어야 한다.

이러한 프로그래밍 인터페이스의 개념은 당업자에게 공지된 것이거나 본 발명의 상술한 설명으로부터 명백하다. 그러나, 프로그래밍 인터페이스를 구현하는 다른 방식이 있으며, 달리 배제되지 않으면, 이들은 또한 본 명세서의 말미에 설명되는 청구항에 의해 포함시키려는 것이다. 이러한 다른 방식은 도 30a 및 도 30b의 단순 보기보다 정교하거나 복잡하게 나타나지만, 그럼에도 불구하고 이들은 유사한 함수를 수행하여 동일한 전체 결과를 달성하게 한다. 이제 프로그래밍 인터페이스의 예시적인 다른 구현예를 간단히 나타낼 수 있다.

공통분할(factoring): 하나의 코드 세그먼트에서 다른 것으로의 통신은 통신을 여러 개별 통신으로 분할하여 간접적으로 달성될 수 있다. 이는 도 31a 및 도 31b에서 개략적으로 도시된다. 나타낸 바와 같이, 몇몇 인터페이스는 해결가능한 일련의 기능에 대하여 나타낼 수 있다. 따라서, 도 30a 및 도 30b의 인터페이스 기능은 24 또는 2×2×3×2을 수학적으로 제공하는 것과 같이 동일한 결과를 달성하도록 공통분할될 수 있다. 따라서, 도 31a에서 나타낸 바와 같이, 인터페이스(인터페이스1)에 의해 제공되는 함수는 여러 인터페이스(인터페이스1A, 인터페이스1B, 인터페이스1C)로 인터페이스의 통신을 변경하도록 서브분할될 수 있으면서 동일 결과를 달성할 수 있다. 도 31b에 나타낸 바와 같이, 인터페이스 I1에 의해 제공된 함수는 동일한 결과를 달성하면서 여러 인터페이스 I1a, I1b, I1c 등으로 서브분할될 수 있다. 유사하게, 제1 코드 세그먼트로부터 정보를 수신하는 제2 코드 세그먼트의 인터페이스(I2)는 여러 인터페이스(I2a, I2b, I2c) 등으로 분할될 수 있다. 공통 분할 시에, 제1 코드 세그먼트에 포함된 세그먼트의 개수는 제2 코드 세그먼트에 포함된 인터페이스의 개수와 일치할 필요는 없다. 도 31a 및 도 31b의 경우 중 하나에서, 인터페이스(인터페이스1 및 I1)의 기본 정신은 각각 도 30a 및 도 30B와 동일하게 된다. 인터페이스의 공통 분할은 통한 공통 분할이 인식하기 어려울 수 있도록 교환, 결합, 및 다른 수학 속성을 따를 수 있다. 예를 들면, 연산의 정렬은 중요하지 않을 수 있으며, 그 결과, 인터페이스에 의해 수행되는 함수가 다른 코드 또는 인터페이스 부분에 의해 또는 시스템의 개별 컴포넌트에 의해 수행되는 인터페이스를 도달하기 이전에 양호하게 수행될 수 있다. 더욱이, 프로그래밍 업계에서 당업자는 동일 결과를 달성하는 상이한 함수 호출을 행하는 다양한 방식이 있음을 이해할 수 있다.

재정의(Redefinition): 몇몇 경우, 프로그래밍 인터페이스의 특정 양태(예를 들면, 파라미터)를 무시, 추가 또는 재정의할 수 있지만, 여전히 의도한 결과를 달성할 수 있다. 이는 도 32a 및 도 32b에 도시되어 있다. 예를 들면, 도 30a의 인터페이스(인터페이스1)는 함수 호출 스퀘어(입력, 정확성, 출력)를 포함하며, 이 호출은 3개의 파라미터인, 입력, 정확성 및 출력을 포함하고 제1 코드 세그먼트에서 제2 코드 세그먼트로 발행된 것이다. 미들 파라미터 정확성이 도 32a에 도시한 바와 같은 해당 시나리오에서 관심이 없는 경우, 무시되거나 심지어 무의미한(이 상황에서) 파라미터로 또한 대체될 수 있다. 또한, 무관심한 추가 파라미터를 추가할 수 있다. 이 경우, 스퀘어의 기능은 입력이 제2 코드 세그먼트에 의해 제곱된 후 출력이 리턴되는 한 달성될 수 있다. 정확성은 컴퓨팅 시스템의 몇몇 다운스트림 또는 다른 부분에 유의미한 파라미터일 수 있지만, 일단 정확에서 제곱을 계산할 협의의 목적으로 필요하지 않는다면, 대체되거나 무시될 수 있다. 예를 들면, 유효 정확성 값을 전달하는 대신, 생일과 같은 유의미한 값은 이 결과에 악영향을 주지 않고 전달될 수 있다. 유사하게, 도 32b에 도시한 바와 같이, 인터페이스 I1은 인터페이스 I1'에 의해 대체되고 무시하거나 인터페이스에 파라미터를 추가하도록 재정의된다. 인터페이스 I2는 유사하게 인터페이스 I2'로서 재정의될 수 있고, 불필요한 파라미터 또는 다른 곳에서 처리될 수 있는 파라미터를 무시하도록 재정의될 수 있다. 여기서 중요한 점은 프로그래밍 인터페이스는 몇몇 목적으로 요구되지 않은 파라미터와 같은 양태를 포함하거나 다른 목적으로 무시, 재정의 또는 처리될 수 있다는 점이다.

인라인 코딩: 또한, 이들 간의 "인터페이스"는 형태를 변경하도록 두 개의 개별 코드 모듈의 기능의 일부 또는 전부를 병합할 수 있다. 예를 들면, 도 30a 및 도 30b의 기능은 도 33a 및 도 33b의 기능으로 각각 변환될 수 있다. 도 33a에서, 도 30a의 이전의 제1 및 제2 코드 세그먼트는 이들을 모두 포함하는 모듈로 병합된다. 이 경우, 코드 세그먼트는 여전히 서로 통신할 수 있지만, 이 인터페이스는 단일 모듈에 보다 적합한 형태에 적용될 수 있다. 따라서, 예를 들면, 형식적 호출 및 리턴 문장은 더 이상 필요하지 않을 수 있지만, 인터페이스(인터페이스1)에 따른 유사한 처리 또는 응답(들)이 여전히 유효할 수 있다. 유사하게, 도 33b에 나타낸 바와 같이, 도 30b에서 인터페이스(I2)의 일부(또는 전부)는 인터페이스(I1)에 인라인 기입되어 인터페이스(I1)를 형성할 수 있다. 나타낸 바와 같이, 인터페이스(I2)는 I2a 및 I2b로 나뉘며, 인터페이스 부분 I2a는 인터페이스 I1과 인라인으로 코딩되어 인터페이스 I1''을 형성하였다. 구체적인 예로서, 도 30b에서의 인터페이스 I1은 함수 호출 스퀘어(입력, 출력)를 수행하며, 이는 제2 코드 세그먼트에 의해 입력에 전달된 값을 전달한 후에(이를 제곱한 후에), 출력을 사용하여 제곱된 결과를 다시 전달하는, 인터페이스 I2에 의해 수신된다. 이러한 경우, 제2 코드 세그먼트(입력을 제곱)에 의해 수행되는 처리는 인터페이스에 대한 호출없이 제1 코드 세그먼트에 의해 수행될 수 있다.

분리(divorce): 제1 코드 세그먼트에서 다른 것으로의 통신은 이 통신을 여러 개별 통신으로 분할하여 간접적으로 달성될 수 있다. 이는 도 34a 및 도 34b에서 개략적으로 도시되어 있다. 도 34a에 도시한 바와 같이, 미들웨어 중 하나 이상의 부분(들)(분리 기능 및/또는 인터페이스 함수를 원래의 인터페이스에서 분리하기 때문에 분리 인터페이스(들))이 제1 인터페이스(인터페이스1) 상의 통신을 전환하여 이들을 상이한 인터페이스, 이 경우 인터페이스(인터페이스2A, 인터페이스2B 및 인터페이스2C)에 이들을 적응시킨다. 이들은 인터페이스1 프로토콜에 따라 예를 들면 운영 체제와 통신하도록 설계된 애플리케이션의 설치된 베이스인 경우, 운영 체제는 상이한 인터페이스, 이 경우, 인터페이스(인터페이스2A, 인터페이스2B, 및 인터페이스2C)를 사용하도록 변경된다. 중요한 점은 제2 코드 세그먼트에 의해 사용된 원래의 인터페이스는 제1 코드 세그먼트에 의해 사용되는 인터페이스와 더 이상 호환가능하지 않도록 변경되며, 이의 중간은 이전의 그리고 새로운 인터페이스가 호환하게 하는데 사용된다는 점이다. 유사하게, 도 34b에 도시한 바와 같이, 제3 코드 세그먼트는 인터페이스 I1에서의 통신을 수신하는 분리 인터페이스 DI1, 인터페이스 기능을, 예를 들면, D12와 동작하도록 재설계된 인터페이스 I2a 및 I2b에 전송하지만 동일 기능적 결과를 제공하는 분리 인터페이스 D12를 사용하여 도입될 수 있다. 유사하게, DI1 및 DI2는 도 30b의 인터페이스 I1 및 I2의 기능을 새로운 운영 체제로 번역하도록 협업하면서 동일하거나 유사한 기능적 결과를 제공할 수 있다.

재기입: 또 다른 가능한 변형은 코드를 동적으로 재기입하여 인터페이스 기능을 다른 것으로 대체하는 동일한 전체 결과를 달성하게 한다. 예를 들면, 중간 언어(예를 들면, 마이크로소프트 IL, 자바 바이트코드 등)에 제시된 코드 세그먼트는 실행 환경(.Net 프레임워크에 의해 제공되는 바와 같이, 자바 런타임 환경 또는 다른 유사한 런타임 유형 환경)에서 저스트 인 타임(JIT) 컴파일러 또는 인터프리터에 제공되는 시스템일 수 있다. JIT 컴파일러는 제1 코드 세그먼트에서 제2 코드 세그먼트로의 통신을 동적으로 변형시켜 제2 코드 세그먼트(원래의 또는 상이한 제2 코드 세그먼트)에 의해 요구될 수 있는 바와 같은 상이한 인터페이스에 부합하도록 재기입될 수 있다. 이는 도 35a 및 도 35b에 도시한다. 도 35a에 도시할 수 있는 것과 같이, 이러한 접근법은 상술한 분리 시나리오에 유사하다. 예를 들면, 애플리케이션의 인스톨된 베이스가 인터페이스 1 프로토콜에 따라 운영 체제와 통신하도록 설계되는 경우, 운영 체제는 상이한 인터페이스를 사용하도록 변경될 수 있다. JIT 컴파일러는 인스톨된 기반 애플리케이션으로부터 운영 체제의 새로운 인터페이스로의 활동 중인 통신을 적용하는데 사용될 수 있다. 도 35b에 도시한 바와 같이, 인터페이스를 동적으로 재기입하는 이러한 도구는 인터페이스를 동적으로 공통 분할하고 다르게는 이를 변형하도록 적용될 수 있다.

또한, 다른 실시예를 통해 인터페이스로서 동일 또는 유사한 결과를 달성하기 위한 상술한 시나리오는 또한 여러 방식으로, 직렬 및/또는 병렬로 또는 다른 중재 코드로 조합될 수 있다. 따라서, 상기 제시된 다른 실시예는 상호 배타적이지 않고, 도 30a 및 도 30b에 제시된 일반 시나리오에 동일 또는 등가의 시나리오를 생성하도록 혼합, 매칭 및 조합될 수 있음이 인식되어야 한다. 또한, 대부분의 프로그램 구성체와 같이, 여기서 설명될 수 없지만 그럼에도 불구하고 본 발명의 취지 및 범위에 의해 제시될 수 있는 인터페이스의 동일 또는 유사한 기능을 달성하는 다른 유사한 방식이 있음이 이해되어야 하며, 다시 말하면, 인터페이스 값의 하부에 있는 인터페이스에 의해 적어도 일부의 기능이 표현되고 이점이 구현됨이 이해되어야 한다.

III. 동기화 API

동기화에 대한 여러 접근법은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가능하다.

A. 동기화 개관

본 발명의 여러 실시예에서, 및 도 3에 있어서, 스토리지 플랫폼은 (i) 스토리지 플랫폼의 여러 인스턴스(각각이 자신의 데이터 저장소(302))가 유연한 일련의 규칙에 따라 이들 내용의 일부를 동기화할 수 있게 하고, (ii) 제3자에 대한 기반구조를 제공하여 전용 프로토콜을 구현하는 다른 데이터 소스를 사용하여 본 발명의 스토리지 플랫폼의 데이터 저장소를 동기화하는 동기화 서비스(330)를 제공한다.

스토리지 플랫폼 대 스토리지 플랫폼 동기화는 참여하는 "복제" 그룹 사이에서 발생한다. 예를 들면, 도 3을 참조하면, 상이한 컴퓨터 시스템에서 동작하는 스토리지 플랫폼의 다른 경우의 제어 하에서 다른 원격 데이터 저장소(338)와 스토리지 플랫폼(300)의 데이터 저장소(302) 간의 동기화를 제공하는 것이 바람직할 수 있다. 이러한 그룹의 전체 멤버십은 임의의 해당 시간에 임의의 해당 복제로 반드시 공지될 필요는 없다.

상이한 복제는 독립적으로(즉, 동시발생하여) 변경될 수 있다. 동기화 프로세스는 모든 복제가 다른 복제에 의해 행해진 변경을 인식하는 것으로서 정의된다. 이러한 동기화 성능은 내재적으로 멀티 마스터(즉, 피어 대 피어)이다.

본 발명의 동기화 성능은 복제가 다음을 가능하게 한다:

다른 복제가 인식하는 변경을 결정;

이러한 복제가 인식하지 않은 변경에 대한 정보를 요청;

다른 복제가 인식하지 않은 변경에 대한 정보를 전달;

두 변화가 서로 충돌한 경우를 결정;

변경을 국부적으로 적용;

충돌 해결을 다른 복제에 전달하여 수렴을 보장; 및

충돌 해결에 대한 규정된 정책에 기초하여 충돌을 해결.

1. 스토리지 플랫폼 대 스토리지 플랫폼 동기화

본 발명의 스토리지 플랫폼의 동기화 서비스(330)의 주요 애플리케이션은 스토리지 플랫폼의 여러 인스턴스를 동기화시키는 것이다(각각이 자신의 데이터 저장소를 가짐). 동기화 서비스는 (데이터베이스 엔진(314)의 하부 표 대신) 스토리지 플랫폼 스키마의 레벨에서 동작한다. 따라서, 예를 들면, "영역"은 후술하는 동기화 세트를 정의하는데 사용된다.

동기화 서비스는 "전체 변화"의 원리 상에 동작한다. 개별 연산(트랜잭션 복제 등)을 기록하여 전송하지 않고, 동기화 서비스는 이들 연산의 최종 결과를 정송함으로써, 여러 연산의 결과를 단일 결과 변경을 통합할 수 있다.

동기화 서비스는 통상 트랜잭션 경계를 중요시하지 않는다. 다시 말하면, 단일 트랜잭션에서 스토리지 플랫폼 데이터 저장소에 대한 두 개의 변경이 행해지면, 이들 변경은 모든 다른 복제에서 단위로 적용되는, 즉, 하나가 다른 것 없이 나타날 수 있음을 보증하지는 않는다. 이러한 원리에 대한 예외는 두 개의 변경이 동일 트랜잭션 내의 동일 항목에 행해지면 이들 변경은 다른 복제에 단위로 전송되어 적용되도록 보장된다. 따라서, 항목은 동기화 서비스의 일관성 단위이다.

동기화(동기) 제어 애플리케이션

임의의 애플리케이션은 동기화 서비스에 접속하고 동기 연산을 개시할 수 있다. 이러한 애플리케이션은 동기화를 수행하는데 필요한 모든 파라미터를 제공한다(후술하는 동기 프로파일 참조). 이러한 애플리케이션은 여기서 동기 제어 애플리케이션(SCA)으로서 불린다.

두 개의 스토리지 플랫폼 인스턴스를 동기화하는 경우, 동기는 SCA에 의한 일 면에서 개시된다. SCA는 로컬 동기화 서비스를 통지하여 원격 파트너와 동기화한다. 다른 면에서, 동기화 서비스는 발신 머신으로부터 동기화 서비스에 의해 전송된 메시지에 의해 일깨워진다. 이는 데스티네이션 머신 상에 존재하는 영구 구성 정보(후술하는 매핑 참조)에 기초하여 응답한다. 동기화 서비스는 스케줄 상에서 또는 이벤트에 응답하여 동작할 수 있다. 이들 경우, 스케줄을 구현하는 동기화 서비스는 SCAR가 된다.

동기화를 가능하게 하기 위해서, 두 개의 단계가 취할 필요가 있다. 첫째, 스키마 설계자는 적절한 동기 의미를 사용하여 스토리지 플랫폼 스키마을 주석 기재하여야 한다(후술하는 바와 같이 변경 단위를 지정). 둘째, 동기화는 (후술하는 바와 같이)이 동기화에서 참가하는 스토리지 플랫폼의 인스턴스를 갖는 모든 머신 상에서 적절하게 구성되어야 한다.

스키마 주석

동기화 서비스의 기본 개념은 변경 단위의 개념이다. 변경 단위는 스토리지 플랫폼에 의해 개별적으로 추적된 스키마의 최소 부분이다. 모든 변경 단위에 있어서, 동기화 서비스는 마지막 동기 이후 변경되는지 또는 변경하지 않았는지를 판정할 수 있다.

스키마에서 변경 단위의 지정은 여러 목적의 역할을 한다. 첫째, 동기화 서비스가 유선에서 얼마나 빈번한지(chatty)를 결정한다. 변경 단위에서 변경이 행해진 경우, 동기화 서비스는 변경 단위의 어느 부분이 변경되었는지를 인식하지 않기 때문에 전체 변경 단위가 다른 복제에 전송된다. 둘째, 이는 충돌 검출의 세분성을 결정한다. 두 개의 동시발생 변경(이들 용어는 후속 단락에서 보다 상세히 설명함)이 동일한 변경 단위에 행해진 경우, 동기화 서비스는 충돌을 야기하지만, 반면에, 동시발생 변경이 상이한 변경 단위에 행해진 경우, 어떤 충돌도 야기되지 않고 변경은 자동으로 병합된다. 셋째, 이는 시스템에 의해 유지된 메타데이터의 양에 강하게 영향을 미친다. 동기화 서비스 데이터의 많은 부분은 변경 단위별로 유지되며, 이에 따라 변경 단위가 동기화 오버헤드를 더욱 작게 증가하게 한다.

변경 단위의 한정은 올바른 타협의 발견을 요구한다. 이러한 이유로 인해, 동기화 서비스는 스키마 설계자가 이 프로세스를 참가할 수 있게 한다.

일 실시예에서, 동기화 서비스는 일 요소보다 큰 변경 단위를 지원하지 않는다. 그러나, 이는 스키마 설계자가 요소보다 적은 변경 단위를 규정하도록 하는 능력을 지원한다 - 즉, 요소의 여러 속성을 개별 변경 단위로 그룹화한다. 이 실시예에서, 이는 다음 구문을 사용하여 달성된다:

동기화 구성

데이터의 특정 부분을 동기로 유지하기를 원하는 스토리지 플랫폼 파트너의 그룹은 동기 커뮤니티로 불린다. 커뮤니티의 멤버는 동기로 유지하기를 원하지만, 이들은 정확히 동일한 방식으로 데이터를 표현할 필요는 없으며, 다시 말하면, 동기 파트너는 이들이 동기화하면 데이터를 변형할 수 있다.

피어 대 피어 시나리오에서, 피어들이 이들 파트너 모두에 대한 변형 매핑을 유지하는 것이 비실용적이다. 그 대신, 동기화 서비스는 "커뮤니티 폴더"를 한정하는 방식을 취한다. 커뮤니티 폴더는 모든 커뮤니티 멤버가 동기화하는 가정의 "공유 폴더"를 나타내는 추상화이다.

이러한 개념은 일 예에 의해 가장 잘 나타낸다. Joe가 그의 여러 컴퓨터의 내 문서 폴더를 동기로 유지하기 원하는 경우, Joe는 커뮤니티 폴더, 이를테면 JoesDocument를 한정한다. 그 후, 모든 컴퓨터 상에서, Joe는 가정 JoesDocument 폴더와 로컬 내 문서 폴더 간의 매핑을 구성한다. 이 점에서, Joe의 컴퓨터는 서로 동기화하는 경우, 이들은 이들의 로컬 항목 대신 JoesDocument에서 문서에 대하여 말한다. 이러한 방식은, 모든 Joe의 컴퓨터는 다른 사람이 누구인지를 인식할 필요없이 서로 이해한다 - 커뮤니티는 동기 커뮤니티의 공통어가 된다.

동기화 서비스의 구성은, (1) 로컬 폴더와 커뮤니티 폴더 간의 매핑을 한정하는 단계, (2) 무엇이 동기화를 얻는지(예를 들면, 누구와 동기화하며 어느 부분집합이 전송되어야 하는지 그리고 어느 것이 수신되는지)를 결정하는 동기화 프로파일을 한정하는 단계, (3) 상이한 동기 프로파일이 동작하거나 이들을 수동으로 동작하는 스케줄을 한정하는 단계인 3단계로 이루어진다.

(1) 커뮤니티 폴더 - 매핑

커뮤니티 폴더 매핑은 개별 머신 상의 XML 구성 파일로서 저장된다. 각 매핑은 다음 스키마를 갖는다.

/mappings/communityFolder

이 요소는 이러한 매핑에 대한 커뮤니티 폴더를 명명한다. 이 명칭은 폴더의 구문 규칙을 따른다.

/mappings/localFolder

이 요소는 매핑이 변화하는 로컬 폴더를 명명한다. 이 명칭은 폴더의 구문 규칙을 따른다. 이 폴더는 매핑이 유효하게 하도록 이미 존재하여야 한다. 이 폴더 내의 항목은 이러한 매핑별 동기화에 대하여 고려된다.

/mapping/transformations

이 요소는 커뮤니티 폴더에서 로컬 폴더로 항목을 변형하는 방식을 한정한다. 부재 또는 없는 경우, 어떤 변형도 수행되지 않는다. 특히, 이는 어떤 ID도 매핑되지 않음을 의미한다. 이러한 구성은 폴더의 캐시를 생성하는데 주로 유용하다.

/mapping/tranformation/mapIDs

이 요소는 새롭게 생성된 로컬 ID,는 커뮤니티 ID 대신 커뮤니티 폴더로부터 매핑된 모든 항목에 할당되도록 요청한다. 동기 런타임은 ID 매핑이 항목 전후로 변환하도록 유지할 수 있다.

/mappings/transformation/localRoot

이 요소는 커뮤니티 폴더 내의 모든 루트 항목이 특정 루트의 자(children)가 되도록 요청한다.

/mappings/runAs

이 요소는 어느 권한 요청이 이 매핑에 대하여 처리되는지를 제어한다. 부재시에는, 전송자가 가정된다.

/mappings/runAs/sender

이 요소의 존재는 이러한 매핑의 메시지의 전송자는 구현되어야 하며, 요청은 그의 자격 증명 하에서 처리됨을 나타낸다.

(2) 프로파일

동기 프로파일은 동기화를 개시하는데 필요한 일련의 전체 파라미터이다. 이는 동기를 초기화하는 동기 런타임에 SCA에 제공된다. 스토리지 플랫폼 대 스토리지 플랫폼 동기화에 대한 동기 프로파일은 다음 정보를 포함한다:

변경에 대한 소스 및 데스티네이션으로서 동작하는 로컬 폴더;

동기화하는 원격 폴더명 - 이 폴더는 상기 한정된 매핑에 의해 원격 파트너에서 공개되어야 한다;

방향 - 이 동기화 서비스는 전송 전용, 수신 전용 및 송수신 동기를 지원한다.

로컬 필터 - 어느 로컬 정보를 원격 파트너에 전송할지를 선택. 로컬 폴더에 대하여 스토리지 플랫폼 조회로서 표현;

원격 필터 - 어느 원격 정보가 원격 파트너로부터 검색하는지를 선택 - 커뮤니티 폴더에 대하여 스토리지 플랫폼 조회로서 표현;

변형 - 로컬 포맷으로 그리고 이로부터 항목을 변형하는 방식을 한정;

로컬 보안 - 원격 종점에서 검색되는 변환이 원격 종점(구현화된)의 허용 하에서 또는 사용자가 동기를 로컬 개시하면서 적용되는지를 규정; 및

충돌 해결 정책 - 충돌이 거절, 로그 또는 자동 해결되는지를 규정 - 후자의 경우, 이는 어떤 충돌 리졸버를 사용할지 뿐만 아니라 이에 대한 구성 파라미터를 규정한다.

동기화 서비스는 동기 프로파일의 단순 구성을 허용하여 런타임 CLR 클래스를 제공한다. 또한, 프로파일은 용이한 스토리지에 대하여(종종 스케줄에 따라) XML 파일로 직렬화될 수 있다. 그러나, 모든 프로파일이 저장되는 프로파일 플랫폼에서 표준 장소는 없으며; SCA가 이를 이전에 고집하지 않고 즉시 프로파일을 구성할 수 있다. 동기를 개시하는 로컬 매핑을 가질 필요는 없다. 모든 동기 정보는 프로파일 내에 규정될 수 있다. 그러나, 매핑은 원격 측에 의해 개시되는 동기 요청에 응답하기 위해서 요청된다.

(3) 스케줄

일 실시예에서, 동기화 서비스는 자신의 스케줄링 기반구조를 제공하지 않는다. 그 대신, 이는 본 작업을 수행하는 다른 컴포넌트, 즉 마이크로소프트 윈도우즈 운영 체제에서 이용가능한 윈도우즈 스케줄러에 의존한다. 동기화 서비스는 SCA로서 동작하고 XML 파일에서 저장된 동기 프로파일에 따라 동기화를 트리거하는 명령 라인 유틸리티를 포함한다. 이러한 유틸리티는 윈도우즈 스케줄러를 구성하여 스케줄 상에서 또는 사용자 로그온 또는 로그오프와 같은 이벤트에 응답하여 동기화를 실행하는 것을 매우 용이하게 한다.

충돌 처리

동기화 서비스에서 충돌 처리는 3단계로 분할된다: (1) 변경 애플리케이션 시간에서 발생하는 충돌 검출 - 이 단계는 변경이 안전하게 적용될 수 있는지를 판정함; (2) 자동 충돌 해결 및 로그 - (충돌이 검출된 직후에 발생하는)이 단계 동안 자동 충돌 리졸버(또는 "충돌 핸들러")는 충돌이 해결될 수 있는지를 확인하도록 점검하며, 그렇지 않은 경우, 충돌은 선택적으로 로그될 수 있음; 및 (3) 충돌 감시 및 해결 - 이 단계는 몇몇 충돌이 로그한 경우에 발생하며, 동기 세션의 경우 밖에서 발생하며, 이 때 로그된 충돌이 분해되어 로그로부터 제거될 수 있다. 본 발명의 다양한 실시예는 단락 IV에서 보다 상세히 후술하는 충돌 처리에 관한 것이다.

2. 비 스토리지 플랫폼 데이터 저장소와의 동기화

본 발명의 스토리지 플랫폼의 다른 양태에 따르면, 스토리지 플랫폼은 이 스토리지 플랫폼이 마이크로소프트 익스체인지, AD, 핫메일, 등과 같은 레거시 시스템에 동기화할 수 있게 하는 동기 어댑터를 ISV가 구현하는 아키텍처를 제공한다. 동기 어댑터는 후술하는 바와 같은 동기화 서비스에 의해 제공된 많은 동기 서비스의 장점을 취한다.

그 명칭에도 불구하고, 동기 어댑터는 몇몇 스토리지 플랫폼 아키텍처로의 플러그 인으로서 구현될 필요는 없다. 원하는 경우, "동기 어댑터"는 단순히 동기화 서비스 런타임 인터페이스를 사용하여 변경 열거 및 애플리케이션과 같은 서비스를 획득한 임의의 애플리케이션일 수 있다.

다른 것이 해당 백엔드로 동기화를 구성 및 실행하기 위해서, 동기 어댑터는 표준 동기 어댑터 인터페이스를 노출하도록 촉구되며, 이는 후술한 바와 같이 동기 프로파일에 대하여 동기를 실행한다. 이 프로파일은 어댑터에 구성 정보를 제공하며, 이 어댑터 중 몇몇은 동기 런타임에 전달되어 런타임 서비스를 제어한다(예를 들면, 폴더 동기화).

동기 서비스

동기화 서비스는 다수의 동기 서비스를 어댑터 작성자에게 제공한다. 본 단락의 나머지에 있어서, 스토리지 플랫폼이 "클라이언트"로서 동기화를 수행하고 어댑터가 대화하고 있는 비 스토리지 플랫폼 백엔드는 "서버"로서 동기화를 수행하는 머신을 지칭하는 것이 편리하다.

(1) 열거 변경

동기화 서비스에 의해 유지되는 변경 추적 데이터에 따라, 변경 열거는 이 프린터와의 최종 동기화가 시도된 이래 데이터 저장소 폴더에 발생한 변경을 동기 어댑터가 용이하게 열거할 수 있게 한다.

최종 동기화에 대한 정보를 나타내는 불명료한 구조인 "앵커"의 개념에 따라 변경이 열거된다. 이 앵커는 이전 단락에서 나타낸 바와 같이 스토리지 플랫폼 지식의 형태를 취한다. 변경 열거 서비스를 사용하는 동기 어댑터는 두 개의 큰 카테고리에 해당된다: "저장된 앵커"를 사용하는 것과 "공급된 앵커"를 사용하는 것.

이 구별은 클라이언트 상에서 또는 서버 상에서 최종 동기에 대한 정보가 저장되는 장소에 의존한다. 이는 종종 어댑터가 클라이언트에 대한 정보를 저장하는 것이 보다 용이해지며, 백엔드는 종종 이러한 정보를 용이하게 저장할 수 없다. 반면에, 여러 클라이언트가 동일 백엔드에 동기화하지 않으면, 클라이언트 상에 이 정보를 저장하는 것은 충분하지 않고, 몇몇 경우에는 부정확하여, 하나의 클라이언트가 서버에 이미 푸시된 다른 클라이언트의 변경을 인식하지 못하게 한다. 어댑터가 서버 저장된 앵커를 사용하기를 원하는 경우, 어댑터는 변경 열거의 시점에서 스토리지 플랫폼으로 다시 제공할 필요가 있다.

스토리지 정보가 앵커를 유지하기 위해서(로컬 또는 원격 스토리지에 대하여), 스토리지 플랫폼은 서버에 성공적으로 적용된 변경을 인식할 필요가 있다. 이들 및 단지 이들 변경만이 앵커에 포함될 수 있다. 변경 열거 동안, 동기 어댑터는 인식 인터페이스를 사용하여 어느 변경이 성공적으로 적용되는지 보고한다. 동기화의 말미에서, 제공된 앵커를 사용한 어댑터는 새로운 앵커를 판독하고(이는 모든 성공적으로 적용된 변경을 포함함), 이를 백엔드에 전송하여야 한다.

종종, 어댑터는 스토리지 플랫폼 데이터 저장소에 삽입함 항목과 함께 어댑터 특정 데이터를 저장할 필요가 있다. 이러한 데이터의 일반 예는 원격 ID와 원격 버전(타임스탬프)이다. 동기화 서비스는 이러한 데이터를 저장하는 메커니즘을 제공하며, 변경 열거는 리턴되는 변경과 함께 이러한 잉여 데이터를 수신하는 메커니즘을 제공한다. 이는 대부분의 경우 데이터베이스를 어댑터가 다시 조회할 필요성을 제거한다.

(2) 변경 애플리케이션

변경 애플리케이션은 동기 어댑터가 이들의 백엔드로부터 수신된 변경을 로컬 스토리지 플랫폼에 적용할 수 있게 한다. 어댑터는 이 변경을 스토리지 플랫폼 스키마에 변형할 수 있다. 도 24는 스토리지 플랫폼 스키마로부터 스토리지 플랫폼 API 클래스가 생성되는 프로세스를 나타낸다.

변경 애플리케이션의 주요 함수는 충돌을 자동 검출하는 것이다. 스토리지 플랫폼 대 스토리지 플랫폼 동기의 경우에서와 같이, 충돌은 서로에 대한 지식 없이 행해지는 두 개의 중첩 변경으로서 정의된다. 어댑터가 변경 애플리케이션을 사용하는 경우, 이들은 어느 충돌 검출이 수행되는지에 대하여 앵커를 규정하여야 한다. 변경 애플리케이션은 어댑터의 지식에 의해 커버되지 않은 중첩 로컬 변경이 검출되면 충돌을 야기한다. 변경 열거와 유사하게, 어댑터는 저장되거나 제공된 앵커를 사용할 수 있다. 변경 애플리케이션은 어댑터 특정 메타데이터의 효율적인 스토리지를 지원한다. 이러한 데이터는 어댑터에 의해 적용된 변경에 첨부될 수 있으며, 동기화 서비스에 의해 저장될 수 있다. 이 데이터는 다음 변경 열거에 리턴될 수 있다.

(3) 충돌 해결

(로그 및 자동 해결 옵션을 포함하는)단락 IV에서 후술하는 충돌 해결 메커니즘은 동기 어댑터에도 이용가능하다. 동기 어댑터는 변경을 적용하는 경우 충돌 해결을 위한 정책을 규정할 수 있다. 규정되면, 충돌은 규정된 충돌 핸들러에 전달되어 (가능하다면)해결될 수 있다. 충돌은 또한 로그될 수 있다. 어댑터는 백엔드에 대한 로컬 변경의 적용을 시도할 때 충돌을 검출할 수 있다. 이러한 경우, 어댑터는 여전히 충돌을 동기 런타임으로 전달하여 정책에 따라 해결될 수 있게 한다. 또한, 동기 어댑터는 임의의 충돌이 처리를 위해 이들에 전송된 동기화 서비스에 의해 검출되도록 요청할 수 있다. 이는 특히 백엔드가 충돌을 저장하거나 해결할 수 있는 경우에 특히 편리하다.

어댑터 구현

몇몇 "어댑터"는 런타임 인터페이스를 사용하여 단순히 애플리케이션이지만, 어댑터는 표준 어댑터 인터페이스를 구현하도록 촉구된다. 이들 인터페이스는 동기 제어 애플리케이션이 해당 동기 프로파일에 따라 어댑터가 동기화를 수행하도록 요청하고; 진행 중인 동기화를 취소하며; 진행 중인 동기에 대한 진행 보고(퍼센트 완성률)를 수신할 수 있게 한다.

3. 보안

이 동기화 서비스는 가능한 적은 부분을 스토리지 플랫폼에 의해 구현되는 보안 모델로 도입하려 한다. 동기화에 대한 새로운 권한을 정의하는 대신, 기존 권한이 사용된다. 구체적으로는,

데이터 저장소 항목을 판독할 수 있는 이는 이 항목에 대한 변경을 열거할 수 있다;

데이터 저장소 항목을 기입할 수 있는 이는 이 항목에 변경을 적용할 수 있다; 및

데이터 저장소 항목을 확장할 수 있는 이는 동기 메타데이터를 이 항목과 관련시킬 수 있다.

동기화 서비스는 보안 작성 정보를 유지하지 않는다. 변환가 사용자 U에 의해 복제 A에 행해져서 복제 B에 전송되는 경우, 변경이 A에서(또는 U에 의해) 원래 행해졌다는 사실은 잊혀진다. B가 이 변경을 복제 C에 전송하면, 이는 A가 아닌 B의 권한 하에서 행해진다. 이는 다음의 제한을 유도한다: 복제가 항목에 대한 그 자신의 변경을 행하도록 신뢰받지 않으면, 이는 다른 것에 의해 행해진 변경을 전달할 수 없다.

동기화 서비스가 개시되는 경우, 이는 동기 제어 애플리케이션에 의해 행해진다. 동기화 서비스는 SCA의 아이덴티티를 구현하고 이 아이덴티티 하에서 모든 (로컬 및 원격)연산을 수행한다. 이를 설명하면, 사용자 U는, 사용자 U가 액세스를 판독하지 않은 항목에 대하여 로컬 동기화 서비스가 원격 스토리지 플랫폼으로부터 변경을 검색하게 할 수는 없다.

4. 관리가능성

복제의 분산 커뮤니티의 감시는 복잡한 문제이다. 동기화 서비스는 "스위프" 알고리즘을 사용하여 복제 상태에 대한 정보를 수집 및 배포할 수 있다. 스위프 알고리즘의 속성은 모든 구성된 복제에 대한 정보가 결국 수집되고 실패(비응답) 복제가 검출되도록 보장한다.

이러한 전 커뮤니티의 감시 정보는 모든 복제에서 이용가능하게 된다. 감시 도구는 임의 선택된 복제에서 실행되어 이러한 감시 정보를 점검하여 행정적 결정을 내릴 수 있게 한다. 임의의 구성 변경은 영향을 받은 복제에서 직접 행해져야 한다.

B. 동기화 API 개관

점점 분산된 디지털 세상에서, 개인 및 작업 그룹은 종종 다양한 서로 다른 장치 및 위치에서 정보 및 데이터를 저장한다. 이는 정보를 최소 사용자 중재로 모든 시점에서 동기화되는 이들 개별, 종종 이종의 데이터 저장소에 유지할 수 있는 데이터 동기화 서비스의 구현을 촉진한다.

본 발명의 동기화 플랫폼은, 여기서의 단락 II에서 설명한 풍부한 스토리지 플랫폼의 일부(즉, "WinFS")로서, 3개의 주요 목적을 해결한다:

애플리케이션 및 서비스가 상이한 "WinFS" 저장소 사이의 데이터를 효율적으로 동기화할 수 있게 한다.

개발자가 "WinFS"와 비 "WinFS" 저장소 사이에 데이터를 동기화하는 풍부한 솔루션을 구축할 수 있게 한다.

적절한 인터페이스를 개발자에게 제공하여 동기화 사용자 경험을 커스텀화한다.

1. 일반 용어

단락 III.B의 추후 설명에 관련된 몇몇 추가 세부 정의 및 주요 개념을 이하 나타낸다:

동기 복제(Sync Replica): 대부분의 애플리케이션은 WinFS 저장소 내의 항목의 해당 부분집합에 대한 변경을 추적, 열거 및 동기화하는 데에만 관심이 있다. 동기화 연산에 관여하는 항목 집합은 동기화 복제로 불린다. 복제는 해당 WinFS 포함 계층(통상 폴더 항목에 루트가 있음) 내에 포함된 항목으로 정의된다. 모든 동기화 서비스는 해당 복제의 문맥 내에 수행된다. WinFS 동기는 복제를 한정, 관리 및 소거하는 메커니즘을 제공한다. 모든 복제는 해당 WinFS 저장소 내에서 이를 고유하게 식별하는 GUID 식별자를 갖는다.

동기 파트너(Sync Partner): 동기 파트너는 WinFS 항목, 확장자 및 관계에 대한 변경에 영향을 줄 수 있는 엔티티로서 정의된다. 따라서, 모든 WinFS 저장소는 동기 파트로 불릴 수 있다. 비 WinFS 저장소와 동기화되는 경우, 외부 데이터 소스(EDS)도 동기 파트너로서 불린다. 모든 파트너는 이를 고유하게 식별하는 GUID 식별자를 갖는다.

동기 커뮤니티(Sync Community): 동기화 커뮤니티는 피어 대 피어 동기화 연산에 의해 동기로 유지되는 복제 모음으로서 정의된다. 이들 복제는, 동일한 WinFS 저장소, 상이한 WinFS 저장소에 모두 있을 수 있으며, 또는 심지어 비 WinFS 저장소에 대한 가상 복제로서 나타날 수 있다. WinFS 동기는 커뮤니티 내에서 오직 동기 연산만이 WinFS 동기 서비스(WinFS 어댑터)를 통하는 경우에도 커뮤니티에 대한 임의의 특정 토폴로지를 규정하거나 요구할 수 있다. (아래 한정된)동기화 어댑터는 이들 자신의 토폴로지 제한을 도입할 수 있다.

변경 추적(Change Tracking), 변경 단위 및 버전: 모든 WinFS 저장소는 모든 로컬 WinFS 항목, 확장자 및 관계에 대한 변경을 추적한다. 변경은 스키마에 한정된 변경 단위 세분성 레벨에서 추적된다. 임의의 항목, 확장자 및 관계 유형의 정상 레벨 필드는 최소의 세분성이 정상 레벨 필드가 되도록 스키마 설계자에 의해 변경 단위로 서브 분할될 수 있다. 변경 추적 목적을 위해, 모든 변경 단위에는 버전이 할당되며, 이 경우 버전이 한 쌍의 동기 파트너 id와 버전 수치이다(버전 수치는 파트너 특정 단조 증가 수치이다). 버전은 저장소에서 로컬로 변경이 발생함에 따라 또는 이들이 다른 복제로부터 획득됨에 따라 갱신된다.

동기 지식(Sync Knowledge): 지식은 임의의 시점에서 해당 동기 복제의 상태를 나타내고, 다시 말하면, 로컬 또는 다른 복제로부터 해당 복제가 인식하는 모든 변경에 대한 메타데이터를 캡슐화한다. WinFS 동기는 동기 연산에 걸쳐 동기 복제에 대한 지식을 유지하고 갱신한다. 중요한 점은 지식 표현이 지식이 저장된 특정 복제에 대해서만이 아닌 전체 커뮤니티에 대하여 해석될 수 있게 한다는 점이다.

동기 어댑터(Sync Adapter): 동기화 어댑터는 동기 런타임 API를 통해 WinFS 동기 서비스를 액세스하는 관리형 코드 애플리케이션이며, 비 WinFS 데이터 저장소에 WinFS 데이터의 동기화를 가능하게 한다. 시나리오의 요건에 따라, WinFS 데이터의 어느 부분이 그리고 어떤 WinFS 데이터형이 동기화할 할 것인지에 대한 것은 어댑터 개발자의 몫이다. 어댑터는 EDS와의 통신, EDS 지원 스키마로 그리고 이로부터 WinFS 방식의 전송, 및 이들 자신의 구성 및 메타데이터의 한정을 담당한다. 어댑터는 WinFS 동기 어댑터 API를 구현하여 일반 구성을 이용하고 WinFS 동기 팀에 의해 제공되는 어댑터에 대한 기반구조를 제어하게 된다. 보다 상세하게는, WinFS 동기 어댑터 API 사양[SADP] 및 WinFS 동기 제어기 API[SCTRL] 사양을 참조하기 바란다.

WinFS 데이터를 외부 비 WinFS 저장소에 동기화하고 WinFS 포맷으로 지식을 생성하거나 유지할 수 없는 어댑터에 있어서, WinFS 동기는 후속 변경 열거 또는 애플리케이션 연산에 사용될 수 있는 원격 지식을 획득할 서비스를 제공한다. 백엔드 저장소의 성능에 따라, 어댑터는 백엔드 상에서 또는 로컬 WinFS 저장소에 이러한 원격 지식을 저장하기 원할 수 있다.

간이함을 위해서, 동기화 "복제"는 단일 논리적 위치에 존재하는 "WinFS" 저장소에서 일련의 데이터를 나타내는 구조이지만, 비 "WinFS" 저장소 상의 데이터는 "데이터 소스"로 불리고 통상 어댑터의 사용을 요구한다.

원격 지식(Remote Knowledge): 해당 동기 복제가 다른 복제로부터 변경을 획득하기를 원하는 경우, 이는 자신의 지식을 다른 복제가 열거하는 복제에 대하여 베이스라인으로서 제공한다. 유사하게, 해당 복제가 다른 복제에 대한 변경을 전송하기 원하는 경우, 이는 충돌을 검출하는 원격 복제에 의해 사용될 수 있는 베이스라인으로서 그 자신의 지식을 제공한다. 동기 변경 열거 및 애플리케이션 동안 제공되는 이러한 다른 복제에 대한 지식은 원격 지식으로 불린다.

2. 동기화 API 주체

특정 실시예에서, 동기화 API는 두 부분으로 구별된다: 동기화 구성 API.와 동기화 제어기 API. 동기화 구성 API는 애플리케이션이 동기를 구성하고 이들 복제 간의 특정 동기화 세션에 대하여 파라미터를 규정할 수 있게 한다. 해당 동기화 세션에 대하여, 구성 파라미터는 동기화될 항목의 집합, 동기화 유형(일방향, 또는 양방향), 원격 데이터 소스에 대한 정보, 및 충돌 해결 정책을 포함한다. 해당 제어기 API는 동기화 세션을 개시하고, 동기화를 취소하며, 진행 중인 동기화에 대한 진행 및 에러 정보를 수신한다. 더욱이, 동기화가 소정 스케줄 상에서 수행될 필요가 있는 특정 실시예에 있어서, 이러한 시스템은 스케줄을 커스텀화할 스케줄링 메커니즘을 포함할 수 있다.

본 발명의 여러 실시예는 "WinFS" 및 비 "WinFS" 데이터 소스 간의 정보를 동기화하는 동기화 어댑터를 사용한다. 어댑터의 예는 "WinFS" 컨택 폴더와 비-WinFs 우편함 간의 주소록 정보를 동기화하는 어댑터를 포함한다. 이들 경우, 어댑터 개발자는 "WinFS" 스키마와 비 "WinFS" 데이터 소스 스키마 간의 스키마 변환 코드를 개발하기 위해서 "WinFS" 동기화 플랫폼에 의해 제공되는 서비스를 액세스하는 여기서 설명하는 "WinFS" 동기화 코어 서비스를 사용할 수 있다. 또한, 어댑터 개발자는 비 "WinFS" 데이터 소스와 변환을 통신하기 위한 프로토콜 지원을 제공한다. 동기화 어댑터는 동기화 제어기 API를 사용하여 호출 및 제어되고 이러한 API를 사용하여 진행 및 에러를 보고한다.

그러나, 본 발명의 특정 실시예에서, "WinFS" 데이터 저장소를 "WinFS" 데이터 저장소와 동기화하는 경우, 동기화 어댑터는 "WinFS" 대 "WinFS" 동기화 서비스가 하드웨어/소프트웨어 인터페이스 시스템에 통합될 수 있으면 불필요해질 수 있다. 임의의 이벤트에서, 이러한 여러 실시예는 "WinFS" 대 "WinFS" 모두에 대한 일련의 동기화 서비스와 다음을 포함하는 동기화 어댑터 솔루션을 제공한다:

"WinFS" 항목, 확장자 및 관계에 대한 변경의 추적

해당 과거 상태 이후 효율적인 증가 변경 열거를 지원

외부 변경을 "WinFS"에 적용

변경 애플리케이션 동안 충돌 처리.

도 36을 참조하면, 공통 데이터 저장소의 3 인스턴스와 이들을 동기화하는 컴포넌트를 나타낸다. 제1 시스템(3602)은 사용을 위해 동기 API(3652)를 노출하는(3646) WinFS 대 비 WinFS 동기화에 대하여 WinFS 대 WinFS 서비스(3622)와 코어 동기 서비스(3624)를 포함하는 WinFS 데이터 저장소(3612)를 갖는다. 제1 파일 시스템(3602)과 유사하게, 제2 시스템(3604)은 사용을 위해 동기 API(3652)를 노출하는(3646) WinFS 대 비 WinFS 동기화에 대하여 WinFS 대 WinFS 동기 서비스(3632)와 코어 동기 서비스(3634)를 포함하는 WinFS 데이터 저장소(3614)를 갖는다. 제1 시스템(3602)과 제2 시스템(3604)은 이들의 각각의 WinFS 대 WinFS 동기 서비스(3622 및 3632)를 통해 동기화한다(3642). WinFS 시스템이 아닌 제3 시스템(3606)은 WinFS 동기(3666)를 사용하여 데이터 소스를 WinFS 복제와 동기 커뮤니티에 있게 유지하는 애플리케이션을 갖는다. 이 애플리케이션은 WinFS 동기 구성/제어 서비스(3664)를 사용하여 WinFS 대 WinFS 동기 서비스(3622; 그 자신을 WinFS 데이터 저장소로서 시각화할 수 있는 경우)를 통해 또는 동기 API(3652)와 인터페이스하는(3648) 동기 어댑터(3662)를 통해 WinFS 데이터 저장소(3612)와 직접 인터페이스할 수 있다.

도면에서 나타낸 바와 같이, 파일 시스템(3602)은 제2 시스템(3604)과 제3 시스템(3606)을 인식하고 이에 직접 동기화한다. 그러나, 제2 시스템(3604)과 제3 시스템(3606) 모두 서로를 인식하지 않기 때문에, 서로 직접 그들의 변경을 동기화하지는 않고 그 대신 하나의 시스템에서 발생한 변경이 제1 시스템(3602)을 통해 전파되어야 한다.

C. 동기화 API 서비스

본 발명의 여러 실시예는 두 개의 기본 서비스를 포함하는 동기화 서비스에 관한 것이다: 변경 열거 및 변경 애플리케이션.

1. 변경 열거

여기서 상술한 바와 같이, 이 파트너와의 최종 시간 동기화가 동기화 서비스에 의해 유지되는 변경 추적 데이터에 따라 시도되기 때문에, 변경 열거는 동기 어댑터가 데이터 저장소 폴더에 발생한 변경을 용이하게 열거할 수 있게 한다. 변경 열거에 있어서, 본 발명의 여러 실시예는 다음에 관한 것이다:

규정된 지식 인스턴스에 대하여 해당 복제에서 항목, 확장자 및 관계에 대한 변경의 효율적인 열거.

WinFS 스키마에서 규정된 변경 단위 세분성 레벨에서 변경의 열거.

혼합 항목으로 열거된 변경을 그룹화. 혼합 항목은 하나의 항목, 이의 모든 확장자, 항목에 대한 모든 홀딩 관계 및 이의 임베디드 항목에 대응하는 모든 혼합 항목으로 이루어진다. 항목들 간의 참조 관계에 대한 변경은 개별적으로 열거된다.

변경 열거에 대한 배칭(batching). 배치 세분성은 혼합 항목 또는 관계 변경이다(참조 관계를 위해).

변경 열거 동안 복제 내의 항목에 대한 필터의 사양, 예를 들면, 복제는 해당 폴더 내의 모든 항목으로 이루어지지만, 이러한 특정 변경 열거에 대하여, 애플리케이션은 제1 명칭이 'A'로 개시하는 모든 컨택 항목에 대한 변경만을 열거하기를 원할 수 있다(이러한 지원은 포스트 B-마일스톤일 수 있다).

개별 변경 단위(또는 전체 항목, 확장자 또는 관계)를 지식에서 동기 실패로서 기록할 능력을 사용하여, 다음 시간에 이들을 다시 열거할 수 있도록 열거된 변경에 대한 원격 지식의 사용.

변경 열거 동안 변경에 따라 메타데이터를 리턴하여 WinFS 동기 메타데이터를 이해할 수 있는 개선된 어댑터의 사용.

2. 변경 애플리케이션

여기서 상술한 바와 같이, 변경 애플리케이션은 어댑터가 이 변경을 스토리지 플랫폼 스키마에 변환시키려는 경우, 동기 어댑터가 이들의 백엔드로부터 수신된 변경을 로컬 스토리지 플랫폼에 적용할 수 있게 한다. 변경 애플리케이션에 있어서, 본 발명의 여러 실시예는 다음에 관한 것이다:

WinFS 변경 메타데이터에 대한 대응 갱신을 사용하여 다른 복제(또는 비 WinFS 저장소)로부터 증가 변경의 적용.

변경 단위 세분성에서 변경 애플리케이션 상의 충돌의 검출.

변경 애플리케이션 상의 개별 변경 단위 레벨에서 성공, 실패 및 충돌의 보고, 이에 따라, 애플리케이션(어댑터 및 동기 제어 애플리케이션 포함)은 진행, 에러 및 상태 보고를 위해 그리고 이들의 백엔드 상태를 갱신하기 위해(있는 경우), 이 정보를 사용할 수 있다.

다음 변경 열거 연산 동안 애플리케이션 제공 변경의 "반사"를 방지하기 위해서 변경 애플리케이션 동안 원격 지식의 갱신.

변경과 함께 WinFS 동기 메타데이터를 이해 및 제공할 수 있는 개선된 어댑터의 사용.

3. 샘플 코드

다음은 FOO 동기 어댑터가 동기 런타임과 상호동작할 수 있는 방식에 대한 코드 샘플이다(모든 어댑터 특정 함수는 FOO로 프리픽스된다):

ItemsContext ctx= new ItemContext("\.\System/UserData\dshah\My Contacts", true);

//프로파일에서 복제 항목 id와 원격 파트너 id를 얻기.

//대부분의 어댑터는 동기 프로파일에서 이 정보를 얻을 수 있다.

Guid replicaItemId = Foo_GetReplicaId();

Guid remotePartnerId = Foo_Get_RemotePartnerId();

//

//상기와 같은 저장지식Id를 사용하여 저장소에서 저장된 지식을 찾기.

//

Replica Knowledge remoteKnowledge =...;

//

// 복제동기화기를 초기화

ctx.ReplicaSynchronizer = new ReplicaSynchronizer(replicaItemId, remotePartnerId);

ctx.ReplicaSynchronizer.RemoteKnowledge = remoteKnowledge;

ChangeReader reader = ctx.ReplicaSynchronizer.GetChangeReader();

//

// 변경을 열거하고 이들을 처리

//

bool bChangesToRead = true;

while(bChangesToRead)

{

ChangesCollection<object> changes = null;

bChangesToRead = reader.ReadChanges(10, out changes);

foreach(object change in changes)

{

//열거된 객체를 처리, 어댑터는 자신의 스키마 변형 및 ID 매핑을 수행.

//이는 상기 목적을 위해 Ctx로부터 추가 객체를 검색하여 원격 저장소에

//대하여 적용된 후에 어댑터 메타데이터를 변형할 수 있음.

ChangesStatus status = FOOProcessAndApplyToRemoteStore(change);

//상태를 사용하여 습득된 지식을 갱신

reader.AcknowledgeChange(changeStatus);

}

remote Knowledge = ctx.ReplicaSynchronizer.GetUpdatedRemoteKnowledge();

reader.Close();

//

//있는 경우, 갱신된 지식과 어댑터 메타데이터를 저장

//

ctx.Update();

//

//변경 애플리케이션에 대하여 샘플, 우선, 저장지식Id를 사용하여

//원격 지식을 이전과 같이 초기화.

//

remoteKnowledge = ...;

ctx.ReplicaSynchronizer.ConflictPolicy = conflictPolicy;

ctx.ReplicaSynchronizer.RemotePartnerId = remotePartnerId;

ctx.ReplicaSynchronizer.RemoteKnowledge = remoteKnowledge;

ctx.ReplicaSynchronizer.ChangeStatusEvent+=FOO_OnChangeStatusEvent;

//

//원격 저장소에서 변경을 획득. 어댑터는 저장소로부터

// 이의 백엔드 특정 메타데이터의 검색을 담당.

// 이는 복제에 대한 확장일 수 있다.

//

object remoteAnchor = FOO_GetRemoteAnchorFromStore();

FOO_RemoteChangeCollection remoteChanges = FOO_GetRemoteChanges

(remoteAnchor);

//

//변경 모음을 채운다

//

foreach(FOO_RemoteChange change in remoteChanges)

{

//어댑터는 ID 매핑을 담당

Guid localId = FOO_MapRemoteId(change);

// 사람 객체를 동기화한다고 가정

ItemSearcher searcher = Person.GetSearcher(ctx);

searcher.Filters.Add("PersonId=@localId");

searcher.Parameters["PersonalId"] = localId;

Person person = searcher.FindOne();

//

//어댑터는 원격 변경을 사람 객체에 대한 변형으로 전환

//이 어댑터의 일부가 원격 객체에 대한 항목 레벨 백엔드

//특정 데이터로 변경될 수 있음

//

FOO_TransformRemoteToLocal(remoteChange, person);

}

ctx.Update();

//

// 새로운 원격 앵커를 저장(이는 복제에 대한 확장일 수 있음)

//

FOO_SaveRemoteAnchor();

//

// 이는 원격 지식이 동기화되지 않기 때문에 정규 WinFS API 저장이다.

//

remoteKnowledge = ctx.ReplicaSynchronizer.GetUpdatedRemoteKnowledge();

ctx.Update();

ctx.Close();

//

//애플리케이션 상태를 처리하는 어댑터 콜백이 콜백한다

//

void FOO_OnEntitySaved(object sender, ChangeStatusEventArgs args)

{

remoteAnchor.AcceptChange(args.ChangeStatus);

}

4. API 동기화 방법

본 발명의 일 실시예에서, WinFS 저장소와 비 WinFS 저장소 간의 동기화가 달성됨은 WinFS 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 노출된 동기화 API를 통해 가능하다.

일 실시예에서, 모든 동기화 어댑터는 동기화 어댑터 API, 공통 언어 런타임(CLR) 관리형 API를 구현하도록 요구되기 때문에, 이들은 일정하게 배치, 초기화 및 제어될 수 있다. 어댑터 API는 다음을 제공한다:

하드웨어/소프트웨어 인터페이스 시스템 동기화 프레임워크를 사용하여 어댑터를 등록하는 표준 메커니즘.

어댑터를 초기화하는데 필요한 구성 정보의 유형과 이들의 성능을 선언하는 어댑터에 대한 표준 메커니즘.

초기화 정보를 어댑터에 전달하는 표준 메커니즘.

동기화를 호출하는 애플리케이션에 다시 진행 상태를 보고하는 어댑터에 대한 메커니즘.

동기화 동안 발생하는 임의의 에러를 보고하는 메커니즘.

진행 중인 동기화 연산의 취소를 요청하는 메커니즘.

시나리오의 요건에 따라, 어댑터에 대한 2개의 가능한 프로세스 모델이 있다. 어댑터는 애플리케이션이 이를 호출하는 애플리케이션과 동일한 프로세스 공간으로 또는 단독으로 모두 별개 프로세스에서 실행할 수 있다. 그 자신의 개별 프로세스를 실행하기 위해서, 어댑터는 어댑터를 인스턴스화하는데 사용되는 그 자신의 팩토리 클래스를 한정한다. 팩토리는 호출 애플리케이션과 동일한 프로세스에서 어댑터의 인스턴스를 리턴하거나, 상이한 마이크로소프트 공통 언어 런타임 애플리케이션 도메인 또는 프로세스에서 어댑터의 원격 인스턴스를 리턴할 수 있다. 동일 프로세스에서 어댑터를 예시하는 기본 팩토리 구현이 제공된다. 실제, 많은 어댑터가 호출 애플리케이션과 동일 프로세스에서 동작할 수 있다. 아웃 오브 프로세스 모델은 다음 이유 중 하나 또는 둘에 대하여 요구된다.

보안 목적. 어댑터는 특정 프로세스 또는 서비스의 공간을 프로세스에서 동작하여야 한다.

어댑터는 호출 애플리케이션으로부터 요청을 처리하는 것에 더하여 다른 소스로부터 요청, 예를 들면, 인커밍 네트워크 요청을 처리하여야 한다.

도 37을 참조하면, 본 발명의 일 실시예는 상태가 계산되는 방식 또는 이의 관련 메타데이터가 교환되는 방식을 인식하지 못하는 단순 어댑터를 가정한다. 이 실시예에서, 동기화는 동기화하기를 원하는 데이터 소스에 있어서, 우선 단계 3702에서, 상기 데이터 소스에 마지막으로 동기화된 후에 발생된 변경을 결정함으로써 달성되고, 이 복제는 그 후 이의 현재 상태 정보에 따라 이의 최종 동기화 이해 발생한 증가 변경을 전송하고, 이의 현재 상태 정보와 증가 변경은 어댑터를 통해 데이터 소스에 대한 것이다. 단계 3704에서, 어댑터는 이전 단계에서 복제로부터 변경 데이터를 수신 시에 가능한 한 데이터 소스에 많은 변경을 구현하고, 어느 변환이 성공적이고 실패하는지를 추적하며, 성공 및 실패 정보를 다시 (복제의) WinFS에 전송한다. 단계 3706에서, 복제(WinFS)의 하드웨어/소프트웨어 인터페이스 시스템은 복제로부터 성공 및 실패 정보를 수신 시에, 데이터 소스에 대한 새로운 상태 정보를 계산하고, 이의 복제에 의한 추후 사용을 위해 이 정보를 저장하며, 데이터 소스에, 즉, 저장 및 어댑터에 의한 추후 사용을 위해 어댑터에 이 새로운 상태 정보를 전송한다.

D. 동기화 계층

여기서 상술한 바와 같이, 각각의 복제(및 데이터 소스 및/또는 어댑터)는 이러한 각각의 변경이 대응하는 증가 및 순차 변경 수치에 할당되어(즉, 제1 변경은 1이고, 제2 변경은 2이며, 제3 변경은 3인 등) 이의 변경의 증가하는 순차 열거를 유지한다. 더욱이, 각 복제는 또한 이들 다른 복제로부터 수신한 어느 변경을 추적하는 동기 커뮤니티에서 다른 공지된 복제(동기 파트너)에 대한 상태 정보를 유지한다. 제2 복제로부터 기인한 제1 복제에 적용된 최종 변경의 변경 수치를 인식함으로써, 제1 복제는 그 후 이 수치를 사용하여 이러한 최종 적용된 변경의 수치보다 큰 변경만을 그 후 요청, 수신 또는 처리할 수 있다. 도 38a 내지 도 38d는 이러한 순차적 변경 열거 방법론을 사용하여 변경이 추적, 열거 및 동기화되는 방식을 나타낸다.

도 38a에서, 동기 파트너 A 및 B는 공통 동기 커뮤니티 내의 복제이며, 어떤 변경도 행해지지 않았기 때문에 각 복제에 대한 제로의 개수를 변경하는 것과 동일한 - 예를 들면, 각 복제에 대하여 각각 A0 및 B0인 현재 상태로 도시되어 있다. (이 실시예에서, 고유 변경 수치는 초기 상태를 반영하는데 사용된다). 그 자신의 상태를 인식하고 이의 동기 파트너의 상태를 추적하는 각각의 복제는 여기서 나타낸 (도시한 바와 같이, 복제 자신의 첫 상태 후에 최종 동기화, 이 경우, 초기화에 따라 각 파트너의 마지막으로 알려진 상태를 열거하는)"벡터"로 이 정보를 반영한다. 복제 A에 대한 초기 벡터는 "[A0, B0]"이고 복제 B에 대한 초기 벡터는 "[BO, A0]"이며, 이 두 복제는 현재 완전히 동기이다.

도 38b에서, 복제 A는 변경하여 고유 변경 수치 A1(복제 자체 "A"에 대한 고유 식별을 포함하는 변경 수치뿐만 아니라 이 복제 "1"에 대한 변경에 대한 고유하고 증가된 수치)의 변경을 할당한다. 반면에, 복제 B는 두 개의 변경을 행하여 이들 변경을 각각 B1과 B2의 고유 증가 변경 수치에 할당한다. 이 때, 그리고 다음 동기화 전에, 복제는 이제 동기에서 벗어나고, 복제 A에 대한 벡터는 이제 [A1, B0]이고, 복제 B에 대한 벡터는 [B2, A0]이다(또한, 마지막으로 알려진 변경을 반영).

도 38c에서, 복제 A는 복제 B에 변경을 요청하는 현재 벡터를 전송하여 복제 B와 동기화한다(단계 1). 복제 B는 복제 A의 벡터를 수신하여 두 변화, B1과 B2를 복제 A에 전송하기 위해 필요한 것을 계산하여 이렇게 행하도록 진행한다(단계 2). 복제 A는 B1과 B2로서 식별된 복제 B의 변경(즉, 변경 단위)을 수신하고, 이들을 적용하여, 이 자신의 벡터를 [A1, B2]로 갱신한다(단계 3).

도 38d에 나타낸 다른 실시예에서, 복제 B는 복제 A에 대한 올바른 변경을 계산하여 전송함과 함께(단계 2), 복제 A의 벡터에 따라, 복제 A에 대한 변경이 행해지고 복제 B는 행해지지 않는다고 판정함에 따라, 복제 B는 또한 그 자신의 벡터와 복제 A에 대한 변경 요청을 전송한다(단계 2'). 그 후, 복제 A가 복제 B'의 변경을 수신하고, 이들을 적용하며 그 자신의 벡터를 [A1, B2]에 갱신하는 경우(단계 3 동안), 이는 또한 이 중 어느 것이 복제 b에 전송하도록 변경하는지를 계산하고 이들을 또한 전송한다(단계 3'). 복제 B는 이 정보를 수신 시에, 변경을 행하여 이 벡터를 [B2, A1]에 갱신한다(단계 4).

상기 예에 있어서, 충돌은 다수의 환경에서 발생할 수 있다. 예를 들면, A1과 B2는 동일 변경 단위에 대하여 행해진 변경일 수 있으며, 또는 A1은 동일 변경 단위에 대한 삭제이고 BS는 변형하는 것일 수 있다. 이들 충돌 중 일부가 상술한 충돌 해결 옵션을 사용하여 해결될 수 있지만, 특정 충돌은 특히 어려운 도전을 제공하고, 이들 도전 및 다른 솔루션은 본 예의 관점에서 이하 설명된다.

1. 이전 "범위 밖" 변경을 동기화

본 발명의 특정 실시예에서, 복제의 범위는 정적이지 않을 수 있다. 결과적으로, 복제 A는 범위 내에 있지 않은 항목과 범위 내에 있는 항목 간의 새로운 관계를 생성하는 변경으로 그 범위를 유효하게 증가시킨다. 그러나, 범위 밖에 있는 항목에 대한 변경 단위가 복제 A 및 복제 B 사이에 동기화되지 않는다고 가정하면(이는 복제에 대한 동기화 범위 밖에 있기 때문에), 동기화 비일정성은 특정 항목에 대한 비전 경로에 대하여 발생할 수 있다. 이 문제에 대한 솔루션은 복제 A에서 범위 내 항목과 범위 밖 항목 간의 관계를 생성하는 특정 변경과 함께 범위 밖 항목에 모든 변경이 복제 B에 행해지는 복제 A가 전송되는 것이다.

2. 부-자 탈정렬 동기화

본 발명의 특정 실시예에서, 동기화에 있어서, 부 항목은 자 항목(예를 들면, 항목 K, 자(child)가 항목 J에 임베디드되면, 부(parent), 항목 K는 항목 J가 전송되기 전에 전송될 수 없음) 이전에 항상 전송되는 주요 원리이다. 그러나, 복제 A에 있어서, 동기화들 간에 항목 J 및 K는 모두 변경되지만 자 항목 K가 (예를 들면, 이의 식별 번호의 수치 순위에 따라)낮은 정렬 수치인 경우에는 통상 우선 전송될 수 있다. 본 발명의 다양한 실시예에서 동기화를 위한 이 문제의 한 솔루션은 두 개의 그룹으로 변경을 나누는 것, 즉, 하나는 항목 K에 행해진 변경만을 반영하는 것이고, 제2의 것은 항목 J에 행해진 변경만을 반영하는 것으로서, 이들을 올바른 순서로 전송한다(즉, 부 항목 J에 대한 것을 전송한 후에 자 항목 K에 대한 변경 그룹을 전송).

3. 툼스톤 전파

여기서 상술한 바와 같이, 툼스톤은 동기화 목적을 위해 삭제된 변경 단위를 표시하는데 사용된다. 그러나, 동기화는 동기 커뮤니티에서 여러 백터에 대하여 비동기이기 때문에, 이들 툼스톤은 전체 데이터 플랫폼을 통해 전파하여야 한다. 이 문제는, 툼스톤 전파에 기인하지 않고, 복제 B와의 동기 동안, 복제 A가 하나의 항목을 생성하여 그 항목을 복제 B에 전송할 수 있다는 점이다. 복제 A는 그 후 항목을 삭제할 수 있으며, 복제 C와의 동기 동안, 전송할 것이 없기 때문에(항목을 삭제되기 때문에) 이 항목에 대한 어느 것도 전송하지 않을 수 있다. 그 후, 복제 B와 복제 C가 동기화를 시도하는 경우, 복제 C는 복제 B로부터 항목을 수신하여 B 상에 유지할 수 있다.

본 발명의 다양한 실시예에 대한 이러한 문제점의 솔루션은 복제 A가 툼스톤으로 삭제된 항목을 표시하는 것이다. 그 후, 복제 A가 항목을 삭제하는 경우, 복제 C와의 동기 동나, 이는 복제 B에 툼스톤을 전송한다. 복제 B와 복제 C가 그 후 동기를 시도하는 경우, 복제 B는 툼스톤을 수신하며 이 항목은 현재 동기 커뮤니티에서 완전히 제거된다.

4. 루트 툼스톤 전파

P1에서, 항목 X가 복수의 임베디드 항목 A, B, C, D 및 E를 갖는 경우, 동일한 전체 결과가 P1이 부 X(하나의 변화)를 단순 검출할 때 발생하기 때문에, P1이 우선 이들 자 항목을 우선 삭제하고 동기화 간의 부 항목 X를 두 번째로 삭제할 때 임베디드 항목이 자동적으로 삭제될 수 있는 흥미있는 시나리오가 발생한다(즉, 6개의 변경으로서, del A, del B, del C, del D, del E 및 del X). 이 점에서, 본 발명의 여러 실시예는 동기화 시에 X의 삭제가 6개의 개별 삭제 이벤트의 등가물임을 인식하여 효율성을 획득하고, 이에 따라, P1은 X의 삭제에 대응하여 변경 단위를 P2에만 전송하고 이러한 삭제를 P2에서 X의 임베디드 항목으로 자연스럽게 전파할 수 있게 한다.

5. 관계명 스와핑

상술한 바와 같이, 관계는 명칭을 가지며, 따라서 하나의 복제가 임시명 요소(X)의 사용을 통해 두 개의 관계(R1 및 R2)에 대한 명칭을 스왑할 수 있으며, 다시 말하면, R1의 명칭이 X에 복사되고, R2의 명칭이 R1에 복사되며, X는 R2에 복사되고, 마지막으로, X가 삭제된다. 그러나, 파트너 복제(P2)는 임시명 요소(X)에 대한 어떤 지식도 알지 못하기 때문에, 에러는 R1이 새로운 명칭이고, 이러한 명칭을 변경하려는 P2의 시도는 R1과 R2에 대하여 동일한 명칭을 사용하는 에러를 야기 하므로 동기화 동안 에러가 발생한다. 본 발명의 다양한 실시예에 대한 본 문제점의 솔루션 중 하나는, 동일 명칭의 에러를 수신하거나 인식할 때, 가능한 명칭 스왑 시나리오를 가정하고 이의 자신의 임시명 요소(Y)를 자동 생성하기 위해서, 후속 변경이 R2를 X에서의 명칭으로 재명명하는 것을 포함하면, 이는 스왑을 완료한다(다르게는, 정규 충돌 이벤트로서 시나리오를 생성한다).

6. 참조 관계

복제 P1(WinFS 시스템)과 데이터 소스 P2(비 WinFS 시스템 상에서 동작) 간의 동기화에 있어서, (WinFS에 의해 지원된)댕글링 관계가 비 WinFS 시스템에 의해 지원되는 경우에 문제점이 발생한다. 이 문제점은 P1에 대하여 관계 R을 갖는 두 항목(A 및 B)을 가질 때 문제점이 발생하며, P1은 A(변경 단위 P1-21로서), R(변경 단위 P1-22로서), 및 B(변경 단위 P1-23으로서)의 순서로 이들을 생성한다. R이 생성되는 경우(P1-22), R은 댕글링 관계이므로, P2는 이들 변경에 순서대로 적용하고, 허용되지 않은 댕글링 관계 에러가 야기된다. 본 발명의 여러 실시예에 대한 이 문제에 대한 솔루션은 모든 참조 관계(예를 들면, R)가 모든 다른 변경이 P1에서 P2로 전송된 후에 전송되도록 변경을 대신 재정렬하는 것이며, 이에 따라, 문제는 항목 A와 B를 우선 생성한 후 이들을 서로 R에 관련시킴으로써 모두 방지된다.

E. 동기 스키마의 추가 양태

다음은 본 발명의 다양한 실시예에 대한 동기화 스키마의 추가(보다 구체적인) 양태이다.

각 복제는 다중 인스턴스를 갖는 데이터 슬라이스인 데이터 저장소 전체에서 데이터의 한정된 동기화 부분집합이다.

동기 스키마의루트에는 고유 ID를 갖는 루트 폴더(사실상, 루트 항목)를 정의하는 기본형을 갖는 복제가 있으며, 동기 커뮤니티에서 ID는 멤버인 것으로서, 필더와 다른 요소가 필요한 것이 무엇이든 특정 복제에 대하여 바람직하다.

각 복제의 "매핑"은 복제 내에서 유지되며, 이와 같이, 임의의 특정 복제에 대한 매핑은 이러한 복제가 인식하는 다른 복제에 한정된다. 이 매핑은 전체 동기 커뮤니티의 부분집합만을 포함할 수 있지만, (임의의 특정 복제가 미지의 복제와 공동으로 공유하는 다른 복제를 알지 못하는 경우에도)상기 복제에 대한 변경은 공통 공유된 복제를 통해 전체 동기 커뮤니티에 여전히 전파할 수 있다.

복제의 동기 스키마 및 사용은 실제 분산된 피어 대 피어 멀티 마스터 동기화 커뮤니티를 가능하게 한다. 더욱이, 동기 커뮤니티 유형이 없지만, 동기 커뮤니티는 단순히 복제 자체의 커뮤니티 필드에서의 값으로서 존재한다.

각 복제는 증가 변경 열거를 추적하고 동기 커뮤니티에서 알려진 다른 복제에 대하여 상태 정보를 저장하는 자신의 메타데이터를 갖는다.

변경 단위는, 파트너 키와 파트너 변경 수치의 합을 포함하는 버전; 각 변경 단위에 대한 항목/확장자/관계 버전; 동기 커뮤니티에서 복제가 관측/수신한 변경에 대한 지식; GUID 및 로컬 ID 구성; 및 소거를 위해 참조 관계로 저장되는 GUID를 포함하는 이들 자신의 메타데이터를 갖는다.

IV. 동기화 - 충돌 처리

여기서 상술한 바와 같이, 동기화 서비스에서 충돌 처리는 3개의 단계, 즉, (1) 변경 애플리케이션 시간에서 발생하는 충돌 처리 - 이 단계는 변경이 안전하게 적용되는지를 판정함 -; (2) 자동 충돌 해결 및 로그 - 이 단계 동안(충돌이 검출된 직후에 발생함) 자동 처리 핸들러는 충돌이 해결될 수 있는지를 확인하도록 요청되고 충돌이 해결될 수 없으면, 이 충돌은 선택적으로 로그될 수 있음 -; 및(3) 충돌 검사 및 해결 - 이 단계는 몇몇 충돌이 로그될 때 발생하고 동기 세션의 경우 밖에서 발생하며, 이 때, 로그된 충돌은 해결되어 로그에서 제거될 수 있음 - 로 나뉘어진다.

A. 충돌 처리 스키마

본 발명의 여러 실시예는 구체적으로 피어 대 피어 동기화 시스템(상술한 동기화 시스템 등)에서 발생하는 충돌에 대한 충돌 처리에 관한 것이다. 충돌을 올바르고 효율적으로 처리하는 능력은 데이터 손실을 최소화하면서 양호한 사용가능성을 유지하고 동기화 동안 사용자 중재의 필요를 저감시킨다. 본 발명의 여러 실시예는 후술하는 충돌 처리 요소 중 하나 이상을 포함하는 충돌 처리 스키마에 관한 것이다: (a) 충돌의 개략화된 표현; (b) 충돌 검출; (c) 충돌을 내구성 저장소에 로그; (d) 유연하고 구성가능한 충돌 해결 정책에 따라 충돌의 자동 해결; (e) 충돌을 필터링하여 해결하는 구성가능하고 확장가능한 충돌 핸들러; (f) 소거 충돌의 자동 검출 및 제거; 및 (g) 프로그램 충돌 해결. 더욱이, 충돌 처리 스키마로부터 분리하여, 이들 충돌 처리 요소 각각은 본 발명의 추가 실시예를 나타낸다.

1. 충돌 유형

통상, 충돌은 동기화 연산("변경 애플리케이션 실패") 동안 데이터를 동기화할 능력이 없는 경우일 때마다 충돌이 발생한다. 이들 실패는 통상 충돌이 두 개의 카테고리, 즉, 제한 충돌 및 지식 충돌로 나뉠 수 있지만, 다양한 이유로 인해 발생할 수 있다.

지식 기반 충돌

지식 기발 충돌은 두 개의 복제가 동일한 변경 단위에 대한 독립적인 변경을 행하는 경우에 발생한다. 두 변화는 서로에 대한 지식없이 행해지는 경우에 독립적이라 하며, 다시 말하면, 제1의 버전이 제2 의 지식없이 커버되지 않고 그 역도 마찬가지이다. 동기화 서비스는 상술한 복제 지식에 따라 이러한 충돌을 모두 자동적으로 검출하고 이들 충돌을 상술한 바와 같이 처리한다. 지식 충돌의 몇몇 구체적인 유형은 갱신-삭제, 삭제-갱신, 및 갱신-갱신 충돌을 포함힌다(각 명칭은 로컬 동작과 원격 동작을 순서대로 나타내며; 예를 들면, 갱신-삭제 충돌은 로컬 갱신과 원격 삭제를 동일 날짜에 기인한 것이다.

종종, 변경 단위의 버전 이력에서 충돌을 갈래로 보는 것이 유용하다. 충돌이 변경 단위의 수명동안 발생하지 않는 경우, 이의 버전 이력은 단순 체인이며, 각 변경은 이전 변경 이후에 발생한다. 지식 기반 충돌의 경우, 두 변화는 병렬로 발생하여, 체인이 분기되어 버전 트리가 되게 한다.

요약하면, 지식 충돌이 지식과 버전 처리의 결과로서 발생한다. 데이터베이스에 저장된 정보에 대한 충돌 버전을 갖는 변경이 적용되는 경우 WinFS 동기화에 의해 이들이 생성된다. 충돌은 충돌 변경 정보뿐만 아니라 버전 정보를 포함할 필요가 있다. 지식 충돌에 대한 대부분의 요건은 또한 제한 충돌에 대한 요건이다. 그러나, 지식 충돌은 동기 버전 및 지식의 베이스에만 기초하여 검출될 수 있다.

제한 기반 충돌

독립적 변경이 서로 적용되는 경우 무결성 제한을 어기는 경우가 있다. 예를 들면, 동일 디렉토리에서 동일한 명칭을 갖는 파일을 두 개의 복제는 충돌이 시스템 내의 제한(폴더 내의 공유 항목명의 실행)이 이러한 유형의 제한 기반 충돌을 야기할 수 있게 한다.

통상, 제한 기반 충돌은 지식 기반 충돌에 대해서와 같이 두 개의 독립 변경을 포함하지만, 제한 기반 충돌은 동일한 변경 단위를 영향을 주지 않지만 대신 이들 사이에 존재하는 제한으로 상이한 변경 단위에 영향을 미치는 변경을 포함한다. 제한 기반 충돌은 하나가 충돌을 갖고 다른 것이 충돌이 아닌 경우 두 개의 상이한 유형의 시스템 간에 동기화할 때와 같은 단일 변경에 기인할 수 있다. 예를 들면, 최대 파일명 길이가 8 문자 길이인 제한을 시스템이 가지면, 변경이 8문자 길이 이상으로 하는 파일명에 대한 것인 이러한 제한을 갖지 않은 다른 시스템으로부터 파일에 대한 변경을 이 시스템이 수신하면, 제한 충돌이 야기된다(하나의 단일 머신이 단일 변경에서 발생한다).

특정 유형의 제한 충돌은 다음을 포함하지만 이에 한정되지 않는다:

삽입-삽입 충돌: 이는 두 개의 동기화 파트너는 동일명을 갖는 파일과 같이 동일한 논리적 식별자를 갖는 객체를 두 개의 동기화 파트너 각각이 생성할 때 발생한다.

비 부(No-Parent) 충돌: 이는 생성될 인커밍 객체의 부가 존재하지 않은 경우에 발생한다. 일 예는 파일이 이의 부 폴더 이전에 수신되는 경우에 발생한다.

비한정 유형(Undefined-Type) 충돌: 이는 인커밍 객체의 스키마가 인스톨되지 않아 객체가 생성되는 것을 방지할 때 발생한다.

요약하면, 제한 충돌은 실패에 의해 여러 이유로 인한 변경을 적용하게 된다. 이러한 실패는 의미있게 처리되면 또는 사용자 상호동작을 통해 궁극적 해결을 위해 로그될 수 있으면 이벤트 수렴이 되는 해결의 형태로서 제한 충돌이라 불린다. 보고되는 것 이외의 것으로 의미있게 처리될 수 없는 실패는 단순히 변경 애플리케이션 에러로 불린다. 특정 실시예에서, 모든 변경 애플리케이션 실패는 에러로서 처리되며, 즉, 어떤 인식된 제한 충돌도 없다. 또한, 특정 실시예에서, 전송 동기화동안 발생하는 모든 충돌은 지식 충돌이 다음 수신 동기화에서 다시 제시됨에 따라 무시된다. (비 수렴을 야기하는 다른 실패가 또한 무시될 수 있다).

2. 충돌 검출

동기화 서비스는 변경 애플리케이션 시점에서 제한 위반을 검출하고 제한 기반 충돌을 자동적으로 야기한다. 충돌 기반 충돌의 해결은 통상 제한을 어기지 않는 방식으로 변경을 변경하는 커스텀 코드를 요구하며, 동기화 서비스는 이를 행하기 위한 범용 메커니즘을 제공할 수 있거나 제공하지 않을 수 있다.

본 발명의 다양한 실시예에서, 로컬 지식이 원격 버전을 인식하는지를 점검하여 변경 단위별로 충돌이 검출되고 그 역도 마찬가지이다. 지식 기반 충돌에 있어서, 4개의 충돌 검출 시나리오가 있다:

1. 로컬 지식은 원격 버전을 인식하고, 원격 지식은 로컬 버전을 인식하지 않음: 이는 인커밍 변경이 소멸되고 이에 따라 폐기됨을 의미한다.

2. 로컬 지식은 원격 버전을 인식하지 않고, 원격 지식은 로컬 버전을 인식함: 이는 인커밍 변경이 로컬 버전보다 최근이고 이에 따라 허용됨을 의미한다.

3. 로컬 지식은 원격 버전을 인식하고, 원격 지식은 로컬 버전을 인식함. 이는 두 버전이 등가인 경우에만 발생할 수 있으며, 따라서, 어떤 변경도 적용되지 않는다.

4. 로컬 지식은 원격 버전을 인식하지 않고, 원격 지식은 로컬 버전을 인식하지 않음. 이는 로컬 및 원격 버전이 충돌하지 않음을 의미하며, 따라서, 충돌이 야기된다.

3. 충돌 처리

충돌은 전송 또는 수신 동기화 동안 발생할 수 있지만, 두 파트너가 일반향 동기화 연산으로 유사한 경우(두 개의 유사하게 구성된 WinFS 저장소 등), 이 시나리오는 대칭적이며 충돌을 동기로 자동적으로 해결하거나 비동기 해결을 위해 충돌을 (자동 또는 수동으로)로그함으로써 수신 측에서 가장 용이하게 처리될 수 있다.

물론, 전송 파트너가 WinFS 대 비 WinFS 동기화에서와 같이 충돌을 처리할 필요가 있을 수 있는 상황이 있다. 이러한 경우, 전송 파트너에 이동할 수 없는 제한 충돌은 후속 수신 동기화에 있게 된다. 또한, 수신 파트너는 충돌 로그를 갖지 않을 수 있지만, 관리를 용이함을 위해 전송 충돌을 사용할 필요가 있을 수 있다. 이러한 경우, (후술하는)전송자가 충돌을 해결하게 하는 변경이 거부될 수 있다.

동기 개시자는 이들의 동기 프로파일에서 충돌 해결을 구성한다. 동기화 서비스는 단일 프로파일에서 여러 충돌 핸들러의 조합을 지원한다. 충돌 처리 메커니즘은 확장가능하기 때문에, 여러 충돌 핸들러를 조합하는 여러 방식이 있다. 하나의 특정 방법은 (후술한 바와 같이)이들 중 하나가 성공할 때까지 차례로 시도되는 일련의 충돌 핸들러를 규정하는 것을 포함한다. 다른 방법은, 충돌 핸들러가 충돌 유형에 관련시키는, 예를 들면, 갱신-갱신 지식 기반 충돌을 하나의 충돌 핸들러에 지시하고, 다른 모든 충돌을 로그에 지시하는 것 등을 포함한다.

충돌이 검출되면, 동기화 서비스는 세 개의 동작(동기 프로파일에서 동기 개시자에 의해 선택), 즉, (1) 변경 거부, (2) 충돌을 자동 거부, 또는 (3) 충돌을 충돌 로그에 기록한 것 중 하나를 취할 수 있다.

변경 거부

변경이 거부되면, 동기화 서비스는 복제에서 변경이 도달하지 않은 것처럼 동작하며, 부정 응답은 발신자에게 다시 전송된다. 이 해결 정책은 충돌 기록이 가능하지 않은 헤드없는(head-less; 파일서버와 같은) 복제에서 주로 유용하다. 그 대신, 이러한 복제는 이들을 거부하여 다른 것이 이 충동을 처리하게 한다.

자동 충돌 해결

자동 충돌 해결은 규정된 정책에 따라 동기적으로 충돌을 해결하는 프로세스이다. WinFS 동기화 동작에서, 정책은 전송 동작과 수신 동작에 대하여 독립적으로 규정될 수 있다. 자동 충돌 해결 정책은 동기화 프로파일을 통해 규정된다. 야기된 충돌은 프로파일 내에 규정된 정상 레벨 충돌 핸들러에 전달된다. 이러한 충돌 핸들러는 충돌을 해결하거나, 이를 로그하거나, 이를 충돌 처리 파이프라인을 따라 추가 처리를 위해 다른 충돌 핸들러에 전달할 수 있다.

도 39a는 본 발명의 여러 실시예에 대한 충돌 처리 파이프라인을 나타낸다. 도면에서, 충돌이 발생한 경우, 충돌 핸들러 리스트(또는 "리스트"; 3910)는 충돌 항목(3902)을 수신하고, 이 충돌을 제1 핸들러(3912)에 파이프라인, 이 경우에는 필터의 제1 경로 상으로 전달한다. 필터(3912)는 충돌(3902)을 평가하는 게이트 키퍼로서 이를 다음 핸들러(3914)에 전달하게 하거나 이를 리스트(3901)에 다시 거부하여 그 후 리스트(3912)에 다시 통과한 후 이를 파이프라인의 다음 경로 상의 제1 핸들러(3922)에 전달한다. 충돌(3902)은 제1 필터(3912)에 의해, 이 경우, 리졸버(resolver)인 제2 핸들러(3914)에 전달되면, 충돌은 가능하면 리졸버(3914)에 의해 해결되거나, 가능하지 않으면, 충돌은 제1 핸들러(3922)에 거부되고 리스트(3190)에 거부된 후, 파이프라인의 다음 경로 상으로 리졸버(3922)에 전달된다. 그 후, 충돌은 (a) 파이프라인에서 핸들러 중의 하나에 의해 해결되고, (b) "로거(logger)", 예를 들면, 로거(3936)로서 알려진 특별 충돌 핸들러에 의해 충돌 로그에 명시적으로 로그되고(즉, 충돌이 이들 필터(3934)에 통과시키는 경우), (c) 함께 파이프라인 밖으로 전달되어 기본값으로 충돌 로그에 전송될 때(로거(3944)로서 꺾은 선으로 논리적으로 도시함)까지 파이프라인을 통해 계속 처리된다.

도 39b는 도 39a에서 나타낸 파이프라인의 논리적 트래버설을 나타내는 흐름도이다. 도 39b에서, 그리고 도 39a를 또한 참조하면, 충돌(3902)은 단계 3950에서 충돌 핸들러 리스트(3910)에서 파이프라인에 입력하고, 단계 3952에서 초기에 필터(3912)에 전송된다. 단계 3954에서, 충돌(3902)이 이러한 필터(3912)를 전달하면, 충돌은 단계 3956에서 리졸버(3914)에서 진행하여 단계 3958에서 충돌(3902) 해결을 시도한다. 성공한 경우, 단계 3998에서, 프로세스가 리턴하며, 그렇지 않은 경우, 충돌이 단계 3960에서 리졸버(3922)에 진행하며, 단계 3962에서, 충돌(3902) 해결을 시도한다. 성공한 경우, 단계 3998에서, 프로세스가 리턴하며, 다르게는, 단계 3964에서 리스트(3932)에 진행하여, 이로부터, 단계 3966에서, 필터(3934)로 진행하며, 단계 3968에서 충돌(3902)이 이러한 필터(3934)를 전달한 후, 단계 3972에서 충돌(3902)은 (미도시한) 충돌 로드에 단계 3970에서 로거(3936)에 의해 로그되어 단계 3998에서 프로세스가 리턴한다; 다르게는, 충돌(3902)은 단계 3972에서 필터(3938)에 전송되고, 이 충돌(3902)은 단계 3974에서 이러한 필터(3938)를 전달하면, 충돌(3902)은 단계 3976에서 리졸버(340)에 진행하고, 이는 단계 3978에서 충돌(3902)의 해결을 시도한다. 성공한 경우, 단계 3998에서, 프로세스는 리턴하고, 그렇지 않으면, 충돌은 단계 3980에서 리졸버(3942)에 진행하며, 이는 단계 3982에서 충돌(3902)의 해결을 시도한다. 성공하는 경우, 단계 3998에서 프로세스는 리턴하고, 그렇지 않으면 충돌(3902)은 단계 3984에서 리졸버(3936)에 의해 충돌 로그(미도시)에 로그되고 프로세스는 단계(3998)에서 리턴한다.

도 39a 및 도 39b에는 도시하지 않았지만, 연속적인 충돌 리졸버의 경로는, 충돌이 하나의 리졸버에 의해 해결될 수 없으면, 이 충돌은 충돌 해결을 시도하는 다음 리졸버에 전달되어 등으로 또한 구성될 수 있다. 충돌이 미해결될 남게 되면, 이 충돌은 다음 경로에 진행하기 위해서 리스트의 경로에 전달되지 않음은 경로의 마지막 부분에서 뿐이다. 유사하게, 리스트에 대한 모든 경로가 모든 사용되도 충돌이 미해결이면, 리스트는 그 후 다음 리스트에 도달할 때까지 충돌을 경로까지 백업하는 등이다.

또한, 파이프라인은 리스트로 개시할 필요가 없음을 주목하는 것이 중요한 반면에, 이는 예를 들면 필터와 같은 임의 유형의 충돌 핸들러로 개시할 수 있다. 그러나, 이에 관계없이, 충돌이 파이프라인에서 제1 충돌 핸들러에 경로로 다시 전달되면, 이 충돌 핸들러는 시도할 추가 경로를 갖지 않으면(모든 경로가 시도되지 않은 경우 충돌 핸들러 리스트에 대한 경우만일 수 있음), 충돌은 파이프라인에서 벗어나서, 자동적으로 그리고 기본으로 충돌 로그에 로그된다.

충돌 핸들러 유형은 충돌 핸들러 리스트, 충돌 로그, 충돌 필터, 및 다른 유형의 충돌 핸들러를 포함하는 충돌 핸들러에 대한 기본형이다. 또한, 동기화 서비스는 또한 다음을 포함하지만 이에 한정되지 않은 다수의 기본 충돌 핸들러를 제공할 수 있다:

로컬 승리: 승자로서 인커밍 데이터 상으로 로컬 저장된 데이터를 선택하여 충돌을 해결

원격 승리: 승자로서 로컬 저장 데이터 상으로 인커밍 데이터를 선택하여 충돌을 해결

최종 작성자 승리: 변경 단위의 타임스탬프에 기초하여 변경 단위당 로컬 승리 또는 원격 승리를 선택(통상, 동기화 서비스는 클럭값에 의존하지 않으며, 이 충돌 리졸버는 이 규칙에 대한 유일한 예외임에 주목하자);

결정적: 복제에서와 동일하게 보장되는, 그러나 다른 곳에는 의미있지 않은 방식으로 승자를 선택 - 동기화 서비스의 일 실시예는 파트너 ID의 사전식 비교를 사용하여 이러한 특징을 구현.

예를 들면, 충돌 핸들러는 갱신-삭제 충돌에 대하여, 로컬 승리 해결이 적용되어야 하고 모든 다른 충돌에 대하여 최종 작성자 승리 해결이 적용되어야 함을 다음과 같이 규정할 수 있다:

물론, 충돌 핸들러가 규정되지 않으면, 또는 충돌이 임의의 규정된 충돌 핸들러에 의해 처리되지 않으면, 충돌은 충돌 로그에서 발생된다. 특정 실시예에 대하여, 충돌 로그는 또한 충돌 핸들러이다.

본 발명의 다양한 실시예에 대하여, ISV는 이들 자신의 충돌 핸들러를 구현하고 인스톨할 수 있다. 커스텀 충돌 핸들러는 이러한 파라미터가 동기 프로파일의 충돌 해결 부분에서 SCA에 의해 규정되어야 하더라도 구성 파라미터를 허용할 수 있다.

충돌 리졸버가 충돌을 처리하는 경우, 이는 런타임에 수행될 필요가 있는(충돌 변경에 대신하여) 동작 리스트를 리턴한다. 그 후, 동기화 서비스는 충돌 핸들러가 고려하는 것을 포함하도록 적절하게 조절된 원격 지식을 갖는 이들 동작을 적용한다.

다른 충돌은 해결을 적용하면서 검출될 수 있다. 이러한 경우, 새로운 충돌은 원래 처리가 재개하기 전에 해결되거나 로그되어야 한다.

항목의 버전 이력에서 브랜치로서 충돌을 고려하는 경우, 충돌 해결이 두 갈래를 결합하여 단일 점으로 형성하는 결합으로서 간주될 수 있다. 따라서, 충돌 해결은 버전 이력을 지시형 비순환 그래프(DAG)에 변환한다.

충돌 로그

몇몇 보고된 충돌은 자동 충돌 해결을 사용하여 동기적으로 해결될 수 있지만, 다른 것은 추후 프로그램적 해결을 위해 로그되어야 한다. 충돌 로그는 충돌 리졸브 프로세스가 비동기적으로 진행할 수 있게 하며, 다시 말하면, 충돌이 검출될 때 해결될 필요는 없지만 추후 해결을 위해 로그될 수 있다. 예를 들면, 충돌 뷰어 애플리케이션은 사용자가 사질 후에 로그된 충돌을 감시하고 수동으로 해결할 수 있게 할 수 있다.

본 발명의 여러 실시예에 대하여, 충돌 핸들러의 매우 특별한 종류는 충돌 로거(또는 보다 간단히, 로거(logger))이다. 동기화 서비스는 유형 충돌기록의 항목(또는, 다른 실시예에서, 단순히 충돌 유형)으로서 충돌 로그에 충돌을 로그한다. 이들 기록은 (항목 자체가 삭제되지 않았다면)충돌 내에 있는 항목에 다시 관련된다. 특정 실시예에서, 각 충돌 기론은, 충돌을 야기한 인커밍 변화; 충돌 유형(예를 들면, 갱신-갱신, 갱신-삭제, 삭제-갱신, 삽입-삽입, 또는 제한); 및 인커밍 변화의 버전과 이를 전송하는 복제의 지식을 포함한다. 본 발명의 특정한 다른 실시예에서, 각각의 이러한 충돌 항목은 충돌 변경 데이터 및 메타데이터, 변경 적용자 정보와 같은 다른 문맥 정보뿐만 아니라 문맥의 설명; 참여(enlistment) 데이터, 및 원격 파트너명을 포함한다. 또한, 변경 데이터는 변경을 적용하는데 사용될 수 있는 포맷으로 저장된다. 더욱이, 본 발명의 다양한 실시예에서, 충돌에서 유도된 각 유형은 충돌의 유형에 관련된 새로운 필드를 추가할 수 있다. 예를 들면, 삽입 삽입충돌 유형은 고유 제한이 어기게 되는 항목의 항목 ID를 추가한다.

본 발명의 여러 실시예에서, 로그될 충돌 항목은 충돌 항목에 대한 확장으로서 또는 이와 충돌 항목 자체 사이에 한정된 관계로 충돌 로그에 저장된 개별 항목으로서, 또는 다르게는 충돌 항목 자체의 일부로서(일련의 속성 값 쌍과 같이) 타겟 항목의 복사본을 포함할 수 있다. (내구성 데이터 저장소 상에 저장된)충돌 로그가 타겟의 일부로서 또는 이에 결합하여 저장될 이 타겟 항목은 우선 충돌을 야기하는 특정 변경을 반영할 수 있다. 도 40은 예시적인 컨택 항목을 사용하여 이러한 접근법을 나타내는 블록도이다. 이 예에서, 컨택 항목(4002, "타겟 항목")은 마지막으로 성공적인 동기화로서 "John"에 초기 설정되는 명칭 필드(4004)를 포함한다. 이 필드(4004)는 그 후 로컬 시스템에 의해 "Bob"으로 로컬 변환된다. 후속 동기화 동안, 이러한 동일 필드(4004)를 변경하려는 시도는 로컬 시스템이 "Bob" 또는 "Jane" 중 어느 명칭 변경이 적용되어야 하는지를 확인할 수 없기 때문에 충돌이 되어, 로컬 변경("Bob")이 보유되고, 충돌(4006)은 이 충돌을 야기하는 변경("Jane")의 적용을 반영하는 충돌 항목(4002')의 복사본과 함께 충돌 로그(4008)에 로그된다. 이러한 방식으로, 충돌 로그는 충돌을 야기하는 완전한 타겟 항목을 포함하며, 이러한 특정 타겟 항목은 시도된 변경이 충돌을 야기하는 항목 상에 행해질 수 있음을 반영하도록 갱신된다.

충돌 로그에 충돌을 추가하기 위해서, 로그는 동일 변경 단위(들) 상에 다른 충돌이 있는지를 결정하도록 우선 검색된다. 동일 변경 단위에 대한 임의의 기존 충돌이 있으면, 가능한 제거를 위해 점검된다. 기존 충돌은 이의 변경 인식이 새로운 충돌의 변경 인식에 의해 포함되면 제거된다. 반면에, 새로운 충돌의 변경 인식이 기존 로그된 충돌의 변경 인식에 의해 포함되면, 새로운 충돌이 폐기되며 그 역도 마찬가지이다(즉, 인식이 이 충돌의 인식을 포함하는 변경을 저장소가 수신하고 성공적으로 적용하는 경우와 같이, 이의 인식이 저장소의 인식에 의해 포함되면, 충돌은 또한 소거된다). 두 변화 인식이 다른 것을 모두 포함하지 않은 제3의 경우, 새로운 충돌이 로그에 추가되고, 동일 변경 단위에 대응하는 충돌 모두는 수동으로 또는 자동적으로 추후 해결될 때까지 로그에서 존재한다.

충돌 감시 및 해결

동기화 서비스는 애플리케이션에 대한 API를 제공하여 충돌 로그를 점검하고 이의 충돌의 해결을 제시한다. API는 애플리케이션이 모든 충돌 또는 해당 항목에 관련된 충돌을 열거할 수 있게 한다. 또한, 이러한 애플리케이션이 3가지 방식, 즉, (1) 원격 승리 - 로그 변경을 승인하고 충돌 로컬 변경을 덮어 쓰기; (2) 로컬 승리 - 로그 변경의 충돌 부분을 무시; 및 (3) 새로운 변경 제안 - 이 생각에서 충돌을 해결하는 병합을 애플리케이션이 제안하는 경우 중 하나로 로그 충돌을 해결할 수 있게 한다. 충돌이 애플리케이션에 의해 해결되면, 동기화 서비스는 로그로부터 이들을 제거한다.

복제의 수렴 및 충돌 해결의 전파

복잡한 동기화 시나리오에서, 동일한 충돌은 여러 복제에서 검출될 수 있다. 이것이 발생하면, 여러 일이 발생할 수 있다: (1) 충돌이 하나의 복제 상에서 해결될 수 있고, 이 해결은 다른 것에 전송될 수 있다; (2) 충돌은 두 복제를 모두 자동적으로 해결된다; 또는 (3) 충돌은 복제 모두에 수동적으로 (충돌 검사 API를 통해)해결된다.

수렴을 확보하기 위해서, 동기화 서비스는 충돌 해결을 다른 복제에 전달한다. 충돌을 해결하는 변경이 복제에 도달하는 경우, 동기화 서비스는 이 갱신에 의해 해결되는 로그에서 임의의 충돌 기록을 자동 발견하여 이들을 제거한다. 이러한 의미에서, 충돌 해상도는 하나의 복제에서 모든 다른 복제에 결합한다.

상이한 승자가 동일 충돌에 대한 상이한 충돌에 대한 상이한 복제에 의해 선택되면, 동기화 서비스는 결합 충돌 해결의 원리를 적용하고 두 해결 중 하나를 선택하여 다른 것에 대하여 자동적으로 승리하게 된다. 승자는 동일 결과를 항상 산출하도록 보장되는 결정 방식으로 선택된다(일 실시예에서 사용자 복제 ID 사전적 비교).

상이한 "새로운 변경"이 동일 충돌에 대하여 상이한 복제에 의해 제안되면, 동기화 서비스는 특별 충돌로서 이 새로운 충돌을 처리하고 충돌 로거를 사용하여 이를 다른 복제에 전파되는 것을 방지한다. 이러한 상황은 수동 충돌 해결에서 통상 발생한다.

B. 충돌 처리 스키마의 추가 양태

다음은 본 발명의 여러 실시예에 대한 충돌 처리 스키마의 추가(또는 보다 구체적인) 양태이다.

충돌 해결 정책은 각 복제(및 어댑터/데이터 소스 조합)에 의해 각각 처리되며, 다시 말하면, 각 복제는 그 자신의 기준과 충돌 해결 스키마에 기초한 충돌을 해결할 수 있다. 더욱이, 데이터 저장소의 각 인스턴스의 차이는 추가 장래 충돌을 야기할 수 있지만, 충돌의 증가 및 순차 열거는 갱신된 상태 정보에 반영되는 바와 같이 갱신된 상태 정보를 수신하는 다른 복제에 비가시적이다.

동기 스키마는 모든 복제에 이용가능한 복수의 소정 충돌 핸들러뿐만 아니라 사용자/개발자 한정 커스텀 충돌 핸들러를 포함한다. 또한, 스키마는 또한 3개의 특정 "충돌 핸들러"; (a) 상이한 충돌을 상이한 방식, 예를 들면, (i) 동일 변경 단위가 두 장소에서 변경되는 경우 처리 방식, (ii) 변경 단위가 한 장소에서 변경되지만 다른 장소에서 삭제되는 처리 방식, 및 (iii) 두 개의 상이한 변경 단위가 두 개의 상이한 위치에서 동일한 명칭을 갖는 처리 방식으로 해결하는 충돌 "필터"; (b) 충돌이 성공적으로 해결될 때까지 리스트의 각 요소가 순서대로 일련의 동작을 규정하는 충돌 "핸들러 리스트"; 및 (c) 충돌을 추적하지만 사용자 중재 없이 추가 동작을 취하지 않은 "아무것도 하지 않음"을 포함할 수 있다.

V. 결론

상술한 바와 같이, 본 발명은 데이터를 구성, 검색 및 공유하는 스토리지 플랫폼에 관한 것이다. 본 발명의 스토리지 플랫폼은 기존 파일 시스템 및 데이터베이스 시스템을 넘어서서 데이터 스토리지의 개념을 확장하여 넓히며, 관계(표) 데이터, XML, 및 항목이라 부르는 새로운 형태의 데이터와 같은 구조화된, 비구조화된 또는 반 구조화된 데이터를 포함하는 모든 유형의 데이터에 대한 저장소가 되도록 설계된다. 이의 공통 스토리지 기반 및 개략화된 데이터에도 불구하고, 본 발명의 스토리지 플랫폼은 소비자, 지식 근로자 및 기업에 대한 보다 효율적인 애플리케이션 개발을 가능하게 한다. 이는 이의 데이터 모델에 내재한 성능을 이용가능하게 할 뿐만 아니라 기존 파일 시스템과 데이터베이스 액세스 메소드를 포함하여 확장하는 풍부하고 확장가능 애플리케이션 프로그래밍 인터페이스를 제공한다. 본 발명의 개념에서 벗어나지 않고 상술한 실시예에 대한 변경이 행해질 수 있음이 이해될 것이다. 따라서, 본 발명은 개시된 특정 실시예에 한정되지 않지만, 첨부한 청구항에 의해 한정된 바와 같은 본 발명의 취지 및 범위 내에 있는 모든 변형을 커버하려는 것이다.

상기로부터 명확한 바와 같이, 본 발명의 다양한 시스템, 방법 및 양태의 전부 또는 일부는 프로그램 코드(즉, 명령)의 형태로 구현될 수 있다. 이 프로그램 코드는, 플로피 디스켓, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, 자기 테이프, 플래시 메모리, 하드 디스크 드라이브 또는 임의의 다른 머신 판독가능 저장 매체를 포함하지만 이에 한정되지 않은 자기, 전기, 또는 광 저장 매체 등의 컴퓨터 판독가능 매체 상에서 저장될 수 있으며, 프로그램 코드가 컴퓨터 또는 서버와 같은 머신에 로딩되어 에이 의해 실행되는 경우, 머신은 본 발명을 실시하는 장치가 된다. 또한, 본 발명은 전선 또는 케이블과 같은 몇몇 전송 매체 상으로, 광섬유를 통해, 인터넷 또는 인트라넷 등의 네트워크를 통해, 또는 임의의 다른 형태의 전송을 통해 전송되는 프로그램 코드 형태로 구현될 수 있으며, 프로그램 코드가 컴퓨터와 같은 머신에 수신 및 로딩되어 이에 의해 실행되는 경우, 머신은 본 발명을 실시하는 장치가 된다. 범용 프로세서 상에서 구현되는 경우, 프로그램 코드는 특정 논리 회로와 유사하게 동작하는 고유 장치를 제공하도록 프로세서와 결합한다.

상술한 바와 같이, 본 발명은 데이터를 구성, 검색 및 공유하는 스토리지 플 랫폼에 관한 것이다. 본 발명의 스토리지 플랫폼은 기존 파일 시스템 및 데이터베이스 시스템을 넘어서서 데이터 스토리지의 개념을 확장하여 넓히며, 관계(표) 데이터, XML, 및 항목이라 부르는 새로운 형태의 데이터와 같은 구조화된, 비구조화된 또는 반 구조화된 데이터를 포함하는 모든 유형의 데이터에 대한 저장소가 되도록 설계된다. 이의 공통 스토리지 기반 및 개략화된 데이터에도 불구하고, 본 발명의 스토리지 플랫폼은 소비자, 지식 근로자 및 기업에 대한 보다 효율적인 애플리케이션 개발을 가능하게 한다. 이는 이의 데이터 모델에 내재한 성능을 이용가능하게 할 뿐만 아니라 기존 파일 시스템과 데이터베이스 액세스 메소드를 포함하여 확장하는 풍부하고 확장가능 애플리케이션 프로그래밍 인터페이스를 제공한다.

Claims

피어 대 피어 동기화 시스템에서 충돌을 처리하는 방법에 있어서,

충돌을 식별하는 단계; 및

상기 피어 대 피어 동기화 시스템에 의한 상기 충돌의 해결을 위해 데이터 저장소에 저장가능한 데이터 단위("항목")로서 상기 충돌을 표현하는 단계

를 포함하는 방법.
제1항에 있어서,

특정 충돌에 대하여, 상기 피어 대 피어 동기화 시스템에 의한 상기 충돌의 추후 해결의 위해 내구성 데이터 저장소에 상기 충돌 항목을 로그하는 단계; 및

특정 충돌에 대하여, 적어도 하나의 구체적 충돌 핸들러를 규정하는 충돌 해결 정책에 따라 상기 충돌을 자동 해결하는 단계를 포함하며,

상기 충돌 핸들러는 다음 유형의 충돌 핸들러, 즉, 필터 및 리졸버(resolver)를 포함하는 충돌 핸들러 그룹 중 하나인 방법.
제2항에 있어서,

상기 충돌 핸들러는 항목이고 확장가능하며; 및

상기 충돌 핸들러 그룹은 작성가능(composable)하고 확장가능한 방법.
제3항에 있어서,

상기 충돌 해결 정책은 충돌 처리 파이프라인을 포함하는 적어도 두 개의 충돌 핸들러를 규정하는 방법.
제2항에 있어서,

상기 데이터 저장소에서 소거 충돌 항목의 제거를 포함하지만 이에 한정되지 않는 소거 충돌의 자동 검출 및 제거를 더 포함하는 방법.
제1항에 있어서,

내구성 데이터 저장소에 로그될 때 상기 충돌 항목은 상기 충돌을 야기하는 변경이 적용되는 타겟 항목의 복사본을 포함하는 방법.
제6항에 있어서,

상기 타겟 항목의 상기 복사본은 상기 충돌을 야기하는 상기 변경을 반영하는 방법.
제1항에 있어서,

특정 변경 단위에 관한 제1 충돌 항목을 상기 피어 대 피어 동기화 시스템에 의한 상기 제1 충돌의 추후 해결을 위해 내구성 데이터 저장소에 로그하는 단계를 더 포함하며, 상기 충돌 항목은 변경 인식을 포함하고, 상기 충돌 항목을 상기 내 구성 데이터 저장소에 로그하는 단계는,

상기 내구성 데이터 저장소를 검색하여 상기 제1 충돌 항목과 동일한 구체적 변경 단위에 대해 이미 존재하는 기존 충돌 항목이 있는지를 판정하는 단계;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 기존 충돌 항목의 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 포함되면 상기 기존 충돌 항목을 제거하는 단계;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 제1 충돌 항목의 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되면 상기 제1 충돌 항목을 제거하는 단계; 및

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있고, 상기 제1 충돌 항목의 상기 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되지 않고, 상기 기존 충돌 항목의 상기 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 의해 포함되지 않으면, 상기 기존 충돌 항목을 유지하고 상기 제1 충돌 항목을 상기 내구성 데이터 저장소에 추가하는 단계

를 포함하는 방법.
피어 대 피어 동기화 시스템에서 충돌을 처리하는 시스템에 있어서,

충돌을 식별하는 서브시스템;

데이터 저장소에 저장가능한 데이터 단위("항목")로서 상기 충돌을 표현하는 서브시스템; 및

상기 충돌을 해결하는 서브시스템

을 포함하는 시스템.
제9항에 있어서,

상기 피어 대 피어 동기화 시스템에 의한 상기 충돌의 추후 해결을 위해 내구성 데이터 저장소에 상기 충돌 항목을 로그하는 서브시스템; 및

적어도 하나의 특정 충돌 핸들러를 규정하는 충돌 해결 정책에 따라 상기 충돌을 자동 해결하는 서브 시스템을 더 포함하며,

상기 충돌 핸들러는 충돌 핸들러의 다음 유형, 즉, 필터 및 리졸버를 포함하는 충돌 핸들러 그룹 중 하나인 시스템.
제10항에 있어서,

확장가능한 충돌 핸들러; 및

충돌 핸들러의 작성가능하고 확장가능한 그룹

을 더 포함하는 시스템.
제11항에 있어서,

충돌 처리 파이프라인을 더 포함하며, 상기 충돌 처리 파이프라인은 적어도 두 개의 충돌 핸들러를 포함하는 시스템.
제10항에 있어서,

상기 데이터 저장소에서 소거 충돌 항목의 제거를 포함하지만 이에 한정되지 않는 소거 충돌의 자동 검출 및 제거를 위한 서브시스템을 더 포함하는 시스템.
제9항에 있어서,

충돌을 야기하는 변경이 적용되는 타겟 항목의 복사본을 제작하고, 내구성 데이터 저장소 상에 유지되는 충돌 로그에서 충돌 항목과 함께 상기 복사본을 저장하는 서브시스템을 더 포함하는 시스템.
제14항에 있어서,

상기 타겟 항목의 상기 복사본을 상기 충돌을 야기하는 상기 변경을 반영하도록 변형하는 서브시스템을 더 포함하는 시스템.
제9항에 있어서,

상기 피어 대 피어 동기화 시스템에 의한 상기 제1 충돌의 추후 해결을 위해 내구성 데이터 저장소에 특정 변경 단위에 관한 제1 충돌 항목을 로그하는 서브시스템을 더 포함하며, 상기 충돌 항목은 변경 인식을 포함하고, 상기 충돌 항목을 상기 내구성 데이터 저장소에 로그하는 상기 서브시스템은,

상기 내구성 데이터 저장소를 검색하여 상기 제1 충돌 항목과 동일한 구체적 변경 단위에 대해 이미 존재하는 기존 충돌 항목이 있는지를 판정하는 서브시스템;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 기존 충돌 항목의 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 포함되면 상기 기존 충돌 항목을 제거하는 서브시스템;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 제1 충돌 항목의 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되면 상기 제1 충돌 항목을 제거하는 서브시스템; 및

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있고, 상기 제1 충돌 항목의 상기 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되지 않고, 상기 기존 충돌 항목의 상기 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 의해 포함되지 않으면, 상기 기존 충돌 항목을 유지하고 상기 제1 충돌 항목을 상기 내구성 데이터 저장소에 추가하는 서브시스템

을 더 포함하는 시스템.
피어 대 피어 동기화 시스템에서 충돌을 처리하는 컴퓨터 판독가능 명령어를 포함하는 컴퓨터 판독가능 매체로서,

충돌을 식별하여 상기 피어 대 피어 동기화 시스템에 의한 상기 충돌의 해결을 위해 데이터 저장소에 저장가능한 데이터 단위("항목")로서 상기 충돌을 표현하는 명령어를 포함하는 컴퓨터 판독가능 매체.
제17항에 있어서,

상기 피어 대 피어 동기화 시스템에 의한 상기 충돌의 추후 해결을 위해 내구성 데이터 저장소에 상기 충돌 항목을 로그하는 명령어; 및

적어도 하나의 특정 충돌 핸들러를 규정하는 충돌 해결 정책에 따라 상기 충돌을 자동 해결하는 명령어를 더 포함하며,

상기 충돌 핸들러는 충돌 핸들러의 다음 유형, 즉, 필터 및 리졸버를 포함하는 충돌 핸들러의 그룹 중 하나인 컴퓨터 판독가능 매체.
제18항에 있어서,

상기 충돌 핸들러는 항목이고 확장가능하며,

상기 충돌 핸들러 그룹은 작성가능하고 확장가능한 컴퓨터 판독가능 매체.
제19항에 있어서,

상기 충돌 해결 정책은 충돌 처리 파이프라인을 포함하는 적어도 두 개의 충돌 핸들러를 규정하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
제18항에 있어서,

상기 데이터 저장소에서 소거 충돌 항목의 제거를 포함하지만 이에 한정되지 않는 소거 충돌의 자동 검출 및 제거를 위한 명령어를 더 포함하는 컴퓨터 판독가능 매체.
제17항에 있어서,

내구성 데이터 저장소에 로그될 때 상기 충돌 항목은 상기 충돌을 야기하는 변경이 적용되는 상기 타겟 항목의 복사본을 포함하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
제22항에 있어서,

상기 타겟 항목의 상기 복사본은 상기 충돌을 야기하는 상기 변경을 반영하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
제17항에 있어서,

특정 변경 단위에 관한 제1 충돌 항목을 상기 피어 대 피어 동기화 시스템에 의한 상기 제1 충돌의 추후 해결을 위해 내구성 데이터 저장소에 로그하는 명령어를 더 포함하며, 상기 충돌 항목은 변경 인식을 포함하고, 상기 충돌 항목을 상기 내구성 데이터 저장소에 로그하는 명령어는,

상기 내구성 데이터 저장소를 검색하여 상기 제1 충돌 항목과 동일한 구체적 변경 단위에 대해 이미 존재하는 기존 충돌 항목이 있는지를 판정하는 명령어;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 기존 충돌 항목의 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 포함되면 상기 기존 충돌 항목을 제거하는 명령어;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 제1 충돌 항목의 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되면 상기 제1 충돌 항목을 제거하는 명령어; 및

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있고, 상기 제1 충돌 항목의 상기 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되지 않고, 상기 기존 충돌 항목의 상기 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 의해 포함되지 않으면, 상기 기존 충돌 항목을 유지하고 상기 제1 충돌 항목을 상기 내구성 데이터 저장소에 추가하는 명령어

를 더 포함하는 컴퓨터 판독가능 매체.
피어 대 피어 동기화 시스템에서 충돌을 처리하는 하드웨어 제어 장치에 있어서,

충돌을 식별하는 수단; 및

상기 피어 대 피어 동기화 시스템에 의한 상기 충돌의 해결을 위해 데이터 저장소에서 저장가능한 데이터 단위("항목")로서 상기 충돌을 표현하는 수단

을 포함하는 하드웨어 제어 장치.
제25항에 있어서,

특정 충돌에 대하여, 상기 피어 대 피어 동기화 시스템에 의한 상기 충돌의 추후 해결의 위해 내구성 데이터 저장소에 상기 충돌 항목을 로그하는 수단; 및

특정 충돌에 대하여, 적어도 하나의 구체적 충돌 핸들러를 규정하는 충돌 해결 정책에 따라 상기 충돌을 자동 해결하는 수단을 포함하며,

상기 충돌 핸들러는 다음 유형의 충돌 핸들러, 즉, 필터 및 리졸버(resolver)를 포함하는 충돌 핸들러 그룹 중 하나인 하드웨어 제어 장치.
제26항에 있어서,

상기 충돌 핸들러가 확장가능한 항목인 수단; 및

상기 충돌 핸들러 그룹이 작성가능하고 확장가능한 수단

을 더 포함하는 하드웨어 제어 장치.
제27항에 있어서,

상기 충돌 해결 정책은 충돌 처리 파이프라인을 포함하는 적어도 두 개의 충 돌 핸들러를 규정하는 수단을 더 포함하는 하드웨어 제어 장치.
제26항에 있어서,

상기 데이터 저장소에서 소거 충돌 항목의 제거를 포함하지만 이에 한정되지 않는 소거 충돌의 자동 검출 및 제거하는 수단을 더 포함하는 하드웨어 제어 장치.
제25항에 있어서,

내구성 데이터 저장소에 로그될 때 상기 충돌 항목은 상기 충돌을 야기하는 변경이 적용되는 상기 타겟 항목의 복사본을 포함하는 수단을 더 포함하는 하드웨어 제어 장치.
제30항에 있어서,

상기 타겟 항목의 상기 복사본은 상기 충돌을 야기하는 상기 변경을 반영하는 수단을 더 포함하는 하드웨어 제어 장치.
제25항에 있어서,

특정 변경 단위에 관한 제1 충돌 항목을 상기 피어 대 피어 동기화 시스템에 의해 상기 제1 충돌의 추후 해결을 위해 내구성 데이터 저장소에 로그하는 수단을 더 포함하며, 상기 충돌 항목은 변경 인식을 포함하고, 상기 충돌 항목을 상기 내구성 데이터 저장소에 로그하는 수단은,

상기 내구성 데이터 저장소를 검색하여 상기 제1 충돌 항목과 동일한 구체적 변경 단위에 대해 이미 존재하는 기존 충돌 항목이 있는지를 판정하는 수단;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 기존 충돌 항목의 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 포함되면 상기 기존 충돌 항목을 제거하는 수단;

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있는 경우, 상기 제1 충돌 항목의 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되면 상기 제1 충돌 항목을 제거하는 수단; 및

상기 제1 충돌 항목과 동일한 특정 변경 단위에 대해 상기 내구성 데이터 저장소에 이미 존재하는 기존 충돌 항목이 있고, 상기 제1 충돌 항목의 상기 변경 인식이 상기 기존 충돌 항목의 상기 변경 인식에 포함되지 않고, 상기 기존 충돌 항목의 상기 변경 인식이 상기 제1 충돌 항목의 상기 변경 인식에 의해 포함되지 않으면, 상기 기존 충돌 항목을 유지하고 상기 제1 충돌 항목을 상기 내구성 데이터 저장소에 추가하는 수단

을 포함하는 하드웨어 제어 장치.