KR101109390B1 - 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 동기화 서비스를 제공하는시스템 및 방법 - Google Patents

Abstract

본 발명의 여러 실시예들은 "WinFs"와 "non-WinFS" 데이터 소스들 사이에 정보를 동기화하기 위해 동기화 어댑터를 사용한다. 어댑터의 예는 WinFS 연락 폴더와 non-WinFS 메일박스 사이에 어드레스 북 정보를 동기화하는 어댑터를 포함한다. 이들 예에서, 어댑터 개발자들은 WinFS 스키마와 non-WinFS 데이터 소스 스키마 사이의 스키마 변환 코드를 개발하기 위해 WinFS 동기화 플랫폼에서 제공되는 서비스에 액세스하기 위해 본 명세서에 설명되는 WinFS 동기화 코어 서비스 API를 사용할 수 있다. 또한, 어댑터 개발자는 non-WinFS 데이터 소스와 변경을 전달하기 위한 프로토콜 지원을 제공한다. 동기화 어댑터는 동기화 제어기 API를 이용하여 호출되고 제어되며, 이 API를 이용하여 진행 및 에러를 보고한다.

하드웨어, 소프트웨어, 인터페이스, 저장 플랫폼, 인스턴스, 동기화, 애플리케이션 프로그래밍 인터페이스, API, 운영 체제, OS

Description

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

<상호 참조>

본 출원은 2004년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들에 대한 동기화 서비스를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/692,515(대리인 관리번호 제MSFT-2844호); 2003년 8월 21일자로 출원된 "항목 기반 저장 플랫폼을 가진 애플리케이션 프로그램들을 인터페이스하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,575(대리인 관리번호 제MSFT-2733호); 및 2003년 8월 21일자로 출원된 "항목 기반 저장 플랫폼을 가진 애플리케이션 프로그램들을 인터페이스하기 위한 시스템 및 방법"이라는 제목의 국제 출원 번호 PCT/US03/26150(대리인 관리번호 제2777호)에 대한 우선권을 주장하며, 이들 출원의 개시 내용은 전체적으로 본 명세서에 참고로 반영되었다.

본 출원은 다음의 본 출원과 공히 양도된 출원들에 개시된 발명들과 내용이 관련되어 있으며, 이들 출원들의 내용은 본 명세서에 그 전체(및 편의를 위해 부분 요약됨)가 반영되어 있다: 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능하지만 물리적 표현에 무관한 정보의 단위들을 표현하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/647,058(대리인 관리번호 제MSFT-1748호); 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 그들의 물리적 체계로부터 분리하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 10/646,941(대리인 관리번호 제MSFT-1749호); 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하기 위한 기본 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,940(대리인 관리번호 제MSFT-1750호); 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하기 위한 최상위 레벨 구조를 제공하는 코어 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,632(대리인 관리번호 제MSFT-1751호); 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들 간의 관계를 표현하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,645(대리인 관리번호 제MSFT-1752호); 2003년 8월 21일자로 출원된 "데이터의 체계화, 검색 및 공유를 위한 저장 플랫폼"이라는 제목의 미국 특허 출원 번호 10/646,646(대리인 관리번호 제MSFT-2734호); 2003년 8월 21일자로 출원된 "항목 기반 저장 플랫폼에서의 데이터 모델링을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,580(대리인 관리번호 제MSFT-2735호); 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하는 디지털 화상 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/692,779(대리인 관리번호 제MSFT-2829호); 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들에 대한 관계 및 계층적 동기화 서비스를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/692,508(대리인 관리번호 제MSFT-2845호); 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들에 대한 동기화 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/693,362(대리인 관리번호 제MSFT-2846호); 및 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들에 대한 확장 및 상속을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/693,574(대리인 관리번호 제MSFT-2847호).

본 발명은 일반적으로 정보 저장 및 검색 분야에 관한 것이며, 더욱 상세하게는 컴퓨터화된 시스템에서 상이한 타입의 데이터를 체계화하고, 검색하고, 공유하기 위한 액티브 저장 플랫폼에 관한 것이다.

개별 디스크 용량은 지난 10년 동안 해마다 약 70%씩 증가하여 왔다. 무어의 법칙은 수년 동안 이루어진 놀랄만한 CPU 성능의 향상을 정확히 예측하였다. 유선 및 무선 기술은 엄청난 접속성 및 대역폭을 제공하였다. 현재의 경향이 계속 된다고 가정하면, 수년 내에 평균적인 랩탑 컴퓨터는 약 1 테라바이트(TB)의 저장 용량을 가질 것이고, 수백만 개의 파일을 포함할 것이며, 500 기가바이트(GB) 드라이브가 일반적으로 될 것이다.

소비자들은 그것이 전통적인 개인 정보 관리자(PIM) 스타일의 데이터인지 디지털 음악 또는 사진과 같은 매체인지에 관계없이 그들의 컴퓨터를 주로 통신 및 개인 정보의 체계화에 이용한다. 디지털 콘텐츠의 양, 및 미처리 바이트(raw bytes)를 저장하는 능력은 엄청나게 증가하여 왔지만, 소비자들이 데이터를 체계화하고 통합하기 위해 사용할 수 있는 방법은 보조를 맞추지 못했다. 지식 노동자들은 정보를 관리하고 공유하는 데 막대한 양의 시간을 소비하며, 몇몇 연구에 의하면 지식 노동자들이 그들의 시간의 15-25%를 비생산적인 정보 관련 활동에 소비하는 것으로 추정되고 있다. 다른 연구에 따르면, 일반적인 지식 노동자는 정보를 검색하기 위해 하루에 약 2.5 시간을 소비하는 것으로 추정되고 있다.

개발자들 및 정보 기술(IT) 분야들은 사람, 장소, 시간 및 이벤트와 같은 것들을 표현하기 위한 공통 저장 추상화를 위해 그들 자신의 데이터 저장소를 구축하는 데 상당한 양의 시간 및 돈을 투자한다. 이것은 중복된 작업을 유발할 뿐만 아니라, 공통 데이터의 공통 검색 또는 공유를 위한 메커니즘이 없는 공통 데이터의 섬들을 생성한다. 마이크로소프트 윈도우 운영 체제를 실행하는 컴퓨터 상에 오늘날 얼마나 많은 어드레스 북이 존재할 수 있는지를 고려하자. 이메일 클라이언트 및 개인용 회계 프로그램과 같은 많은 애플리케이션은 개별 어드레스 북을 유지하며, 각각의 프로그램이 개별적으로 유지하고 있는 어드레스 북 데이터에 대한 애플 리케이션들의 공유는 거의 존재하지 않는다. 결과적으로, 회계 프로그램(예컨대, 마이크로소프트 머니)은 수취인에 대한 어드레스를 이메일 연락 폴더(예컨대, 마이크로소프트 아웃룩에 있는 폴더)에 저장된 어드레스와 함께 공유하지 않는다. 실제로, 많은 사용자들은 다양한 장치를 갖고 있으며, 논리적으로 그들의 개인 데이터를 그들 자신들 사이에서, 그리고 휴대폰를 포함하는 다양한 추가 소스를 통해 MSN 및 AOL과 같은 사용 서비스로 동기화해야 하는데, 그럼에도 공유 문서들의 협동은 문서들을 이메일 메시지에 첨부함으로써, 즉 수동으로 그리고 비효율적으로 충분히 달성된다.

이러한 협동의 부족에 대한 하나의 이유는 컴퓨터 시스템에서 정보의 체계화를 위한 전통적인 접근법이 파일을 저장하는 데 사용되는 저장 매체의 물리적 체계화의 추상화에 기초하여 다수의 파일을 폴더들의 디렉토리 계층 구조로 체계화하기 위해 파일-폴더-디렉토리 기반 시스템("파일 시스템")의 사용에 중점을 두어 왔다는 점이다. 1960년대에 개발된 멀틱스(Multics) 운영 체제은 운영 체제 레벨에서 저장 가능한 데이터의 단위들을 관리하기 위해 파일, 폴더 및 디렉토리의 사용을 개척한 것으로 여겨질 수 있다. 구체적으로, 멀틱스는 파일들의 계층 구조 내에서 심볼 어드레스를 사용하였는데(이에 따라 파일 경로의 아이디어를 도입함), 파일들의 물리적 어드레스는 사용자에게(애플리케이션 및 최종 사용자) 투명하지 않았다. 이러한 파일 시스템은 임의의 개별 파일의 파일 포맷에는 전혀 관심이 없었으며, 파일들 사이의 관계들은 운영 체제 레벨에서(즉, 계층 구조 내의 파일의 위치가 아님) 무관한 것으로 간주되었다. 멀틱스의 출현 이후, 저장 가능 데이터는 운영 체 제 레벨에서 파일, 폴더 및 디렉토리로 체계화되었다. 이들 파일은 일반적으로 파일 시스템에 의해 유지되는 특수 파일에 삽입된 파일 계층 구조 자체("디렉토리")를 포함한다. 또한, 이 디렉토리는 디렉토리 내의 다른 파일들 모두에 대응하는 엔트리들의 리스트, 및 계층 구조에서의 이러한 파일들의 노드 위치(본 명세서에서 폴더로서 지칭됨)를 유지한다. 이것은 약 40년 동안 이 기술의 상태였다.

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

파일 시스템의 단점을 해결하고자 했던 여러 성공하지 못한 시도가 과거에 행해졌다. 이러한 이전의 시도들 중 일부는 데이터가 물리적 어드레스에 의해서가 아니라 콘텐츠에 의해 액세스될 수 있는 메커니즘을 제공하기 위한 콘텐츠 어드레스 가능 메모리의 사용을 포함한다. 그러나, 이러한 노력들은 성공적이지 못한 것으로 입증되었는데, 이는 콘텐츠 어드레스 가능 메모리가 캐시 및 메모리 관리 유닛과 같은 장치들에 의한 소규모 사용에는 유용한 것으로 입증된 반면, 물리적 저장 매체와 같은 장치에서의 대규모 사용은 다양한 이유로 아직 가능하지 않기 때문이며, 따라서 이러한 솔루션은 존재하지 않는다. 객체 지향 데이터베이스(OODB) 시스템을 이용한 다른 시도가 이루어졌으나, 이러한 시도는 강력한 데이터베이스 특성 및 양호한 비 파일(non-file) 표현을 특징으로 하지만, 파일 표현의 처리에 효과적이지 못했으며, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 파일 및 폴더 기반 계층 구조의 속도, 효율 및 단순성을 복제할 수 없었다. SmallTalk(및 다른 파생물)를 사용하려고 시도한 것들과 같은 다른 노력들은 파일 및 비 파일 표현의 처리에 아주 효과적이지만, 다양한 데이터 파일 사이에 존재하는 관계들을 효 율적으로 체계화하고 이용하는 데 필요한 데이터베이스 기능이 부족하여 전체적인 시스템 효율이 수용될 수 없는 것으로 입증되었다. BeOS(및 다른 그러한 운영 체제 연구)를 이용하려는 또 다른 시도는 소정의 필요한 데이터베이스 기능을 제공하면서 파일을 적절히 표현할 수 있음에도 불구하고 비 파일 표현의 처리에 적절하지 않음(전통적인 파일 시스템과 동일한 핵심적인 단점)이 입증되었다.

데이터베이스 기술은 유사한 문제가 존재하는 또 하나의 기술 영역이다. 예컨대, 관계형 데이터베이스 모델은 대단한 상업적 성공을 거두었지만, 실제로 개별 소프트웨어 벤더들(ISV)은 일반적으로 관계형 데이터베이스 소프트웨어 제품(예컨대, 마이크로소프트 SQL 서버)에서 이용할 수 있는 기능의 작은 부분을 이용한다. 대신에, 애플리케이션의 이러한 제품과의 상호작용의 대부분은 단순한 "입수(gets)" 및 "배치(puts)"의 형태이다. 이에 대해서는 명백한 이유가 많이 있지만(예컨대, 플랫폼 또는 데이터베이스가 불가지론적임), 종종 간과하기 쉬운 하나의 중요한 이유는 데이터베이스가 주요 비지니스 애플리케이션 벤더가 실제로 필요로 하는 정확한 추상화를 항상 제공하지는 못한다는 것이다. 예컨대, 실세계는 "고객" 또는 "주문"과 같은 "항목들"(주문의 삽입된 "라인 항목"을 그 내부의 항목 및 그의 항목으로서 함께)에 대한 개념을 갖지만, 관계형 데이터베이스는 단지 테이블 및 행에 대해서만 말한다. 결과적으로, 애플리케이션은 (몇 가지 예를 들면) 항목 레벨에서 일관성, 잠금, 보안 및/또는 트리거의 양태를 갖기를 원할 수 있지만, 일반적으로 데이터베이스는 테이블/행 레벨에서만 이러한 기능을 제공한다. 이것은 각 항목이 데이터베이스에서 소정 테이블 내의 단일 행으로 매핑되는 경우에는 훌 륭하게 동작할 수 있지만, 다수의 라인 항목을 가진 주문의 경우, 항목이 실제로는 다수의 테이블로 매핑되는 이유들이 존재할 수 있으며, 그러한 경우, 단순한 관계형 데이터베이스 시스템은 올바른 추상화를 전혀 제공하지 못한다. 결과적으로, 애플리케이션은 이러한 기본 추상화를 제공하기 위해 데이터베이스의 상부에 논리를 구축해야 한다. 즉, 기본 관계 모델은 보다 높은 레벨의 애플리케이션이 쉽게 개발될 수 있는 데이터 저장용의 충분한 플랫폼을 제공하지 못하는데, 이는 기본 관계 모델이 애플리케이션과 저장 시스템 사이에 간접 레벨을 필요로 하기 때문이다(여기서, 데이터의 시맨틱(semantic) 구조는 소정의 인스턴스에서 애플리케이션에서만 볼 수 있다). 일부 데이터베이스 벤더들은 보다 높은 레벨의 기능을 그들의 제품 내에 구축하고 있지만(예컨대, 객체 관계 능력, 새로운 체계화 모델 등의 제공), 그 어느 것도 필요한 포괄적인 솔루션의 종류를 아직 제공하지 못하고 있는데, 진정으로 포괄적인 솔루션은 유용한 데이터 모델 추상화(예컨대, "항목", "확장", "관계" 등) 및 유용한 도메인 추상화(예컨대, "사람", "위치", "이벤트" 등) 양자를 제공하는 솔루션이다.

기존의 데이터 저장 및 데이터베이스 기술의 전술한 결함에 비추어, 컴퓨터 시스템에서 모든 타입의 데이터를 체계화하고, 검색하고, 공유할 수 있는 향상된 능력을 제공하는 새로운 저장 플랫폼, 즉 기존의 파일 시스템 및 데이터베이스 시스템을 넘어 데이터 플랫폼을 확장하고 확대하며, 모든 타입의 데이터에 대한 저장소가 되도록 설계된 저장 플랫폼이 필요하다. 본 발명은 본 명세서의 앞 부분에 참조로서 반영된 관련 발명들과 함께 이러한 요구를 만족시킨다.

다음의 요약은 본 명세서에 참조로 반영된 관련 발명("관련 발명")과 관련하여 설명되는 발명의 다양한 양태의 개요를 제공한다. 이 요약은 본 발명의 중요한 양태들 모두를 망라한 설명을 제공하는 것을 의도하지 않지 않으며, 본 발명의 범위를 한정하지도 않는다. 오히려, 이 요약은 뒤따르는 상세한 설명 및 도면에 대한 서론으로서 기능하도록 의도된다.

관련 발명은 물론 본 발명은 일반적으로, 데이터를 체계화하고, 검색하고, 공유하기 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 기존 파일 시스템 및 데이터베이스 시스템을 넘어 데이터 저장의 개념을 확장하고 확대하며, 구조화된 데이터, 구조화되지 않은 데이터 또는 반 구조화된 데이터를 포함하는 모든 타입의 데이터에 대한 저장소가 되도록 설계되어 있다.

본 발명의 저장 플랫폼은 데이터베이스 엔진 상에 구현된 데이터 저장소를 포함한다. 데이터베이스 엔진은 객체 관계 확장들을 가진 관계형 데이터베이스 엔진을 포함한다. 데이터 저장소는 데이터의 체계화, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델을 구현한다. 특정 타입의 데이터는 스키마에서 기술되며, 플랫폼은 새로운 타입의 데이터(본질적으로 스키마에 의해 제공되는 기본 타입의 서브타입)를 정의하도록 스키마 세트를 확장하기 위한 메커니즘을 제공한다. 동기화 능력은 사용자들 또는 시스템들 사이에서 데이터의 공유를 쉽게 한다. 종래의 파일 시스템에 대한 제한 없이 이러한 종래의 파일 시스템과 데이터 저장소의 연동을 허용하는 파일 시스템 유사 능력이 제공된다. 변경 추적 메커니즘은 데이터 저장소에 대한 변경을 추적하는 능력을 제공한다. 저장 플랫폼은 또한 애플리케이션이 저장 플랫폼의 전술한 능력들 모두에 액세스할 수 있고 스키마에 기술된 데이터에 액세스할 수 있게 하는 한 세트의 애플리케이션 프로그램 인터페이스를 포함한다.

데이터 저장소에 의해 구현되는 데이터 모델은 항목, 요소 및 관계에 의하여 데이터 저장의 단위들을 정의한다. 항목은 데이터 저장소에 저장할 수 있는 데이터의 단위이며, 하나 이상의 요소 및 관계를 포함할 수 있다. 요소는 하나 이상의 필드(본 명세서에 속성으로도 지칭됨)를 포함하는 타입의 인스턴스이다. 관계는 두 항목 사이의 링크이다. (본 명세서에서 사용되는 이들 및 다른 특정 용어들은 이들을 매우 근접하게 사용되는 다른 용어들과 분리하기 위해 대문자화될 수 있지만, 대문자화된 용어, 예컨대 "Item"과 대문자화되지 않은 동일 용어, 예컨대 "item"을 구별할 의도는 전혀 없으며, 어떠한 차이도 가정되거나 암시되지 않아야 한다.)

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

항목 또는 항목의 속성 값들 중 일부는 영구 저장소로부터 도출되는 것과 반대로 동적으로 계산될 수 있다. 즉, 하드웨어/소프트웨어 인터페이스 시스템은 항목이 저장되는 것을 요구하지 않으며, 현재의 항목들의 세트를 열거할 수 있는 능력, 또는 저장 플랫폼에 대한 그의 식별자가 주어질 때 항목을 검색할 수 있는 능력(애플리케이션 프로그래밍 인터페이스 또는 API를 설명하는 섹션에서 보다 상세히 설명됨)과 같은 소정의 동작들이 지원되는데, 예컨대 항목은 휴대폰의 현재 위치 또는 온도 센서에 읽은 온도일 수 있다. 하드웨어/소프트웨어 인터페이스 시스템은 다수의 항목을 조작할 수 있으며, 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리되는 다수의 관계에 의해 상호 접속되는 항목들을 더 포함할 수 있다.

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

저장 플랫폼의 API는 저장 플랫폼 스키마 세트에 정의된 각 항목, 항목 확장 및 관계에 대한 데이터 클래스를 제공한다. 또한, API는 데이터 클래스들에 대한 공통 거동 세트를 정의하고 데이터 클래스들과 함께 저장 플랫폼 API에 대한 기본 프로그래밍 모델을 제공하는 한 세트의 프레임워크 클래스를 제공한다. 저장 플랫폼 API는, 기반 데이터베이스 엔진의 질의 언어의 정보로부터 애플리케이션 프로그래머들을 격리시키는 방식으로, 애플리케이션 프로그래머들이 데이터 저장소 내의 항목들의 다양한 속성에 기초하여 질의를 형성하는 것을 가능하게 하는 간략화된 질의 모델을 제공한다. 저장 플랫폼 API는 또한 애플리케이션 프로그램에 의해 이루어진 항목에 대한 변경을 수집한 후, 데이터 저장소가 구현되는 데이터베이스 엔진(또는 임의 종류의 저장 엔진)에 의해 요구되는 정확한 갱신들 내에 이들을 체계화한다. 이것은 애플리케이션 프로그래머들이 메모리 내에서 항목을 변경하는 것을 가능하게 하며, 데이터 저장소 갱신들의 복잡성을 API로 넘기는 것을 가능하게 한다.

본 발명의 저장 플랫폼은 그의 공통 저장 기초 및 스키마화된 데이터를 통해 소비자, 지식 노동자 및 기업에 보다 효율적인 애플리케이션의 개발을 가능하게 한다. 이것은 그의 데이터 모델에 고유한 능력들을 이용할 수 있게 해줄 뿐 아니라 기존 파일 시스템 및 데이터베이스 액세스 방법을 수용하고 확장하는 풍부하고 확장 가능한 API를 제공한다.

이러한 상호 관련된 발명들의 최우선 구조의 일부로서(상세한 설명의 섹션 II에서 상세히 설명됨), 본 발명은 특히 동기화 API(상세한 설명의 섹션 III에서 상세히 설명됨)와 관련된다. 본 발명의 다른 특징 및 이점은 아래의 발명의 상세한 설명 및 첨부 도면으로부터 명백해질 것이다.

전술한 요약 및 아래의 발명의 상세한 설명은 첨부된 도면들과 함께 읽을 때 더 잘 이해된다. 본 발명을 설명하기 위해, 본 발명의 다양한 실시예가 도면들에 도시되어 있지만, 본 발명은 개시된 특정 방법 및 수단으로 한정되지 않는다.

도 1은 본 발명의 양태들이 구현될 수 있는 컴퓨터 시스템을 나타내는 블록 도이다.

도 2는 3개의 컴포넌트 그룹, 즉 하드웨어 컴포넌트, 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트 및 애플리케이션 프로그램 컴포넌트로 분할된 컴퓨터 시스템을 나타내는 블록도이다.

도 2A는 파일 기반 운영 체제에서 디렉토리 내의 폴더들에 그룹화된 파일들에 대한 종래의 트리 기반 계층 구조를 나타내는 도면이다.

도 3은 저장 플랫폼을 나타내는 블록도이다.

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

도 5A는 항목의 구조를 나타내는 블록도이다.

도 5B는 도 5A의 항목의 복합 속성 타입을 나타내는 블록도이다.

도 5C는 복합 타입들이 자세하게 설명된(명시적으로 리스트된) "위치" 항목을 나타내는 블록도이다.

도 6A는 항목을 기본 스키마에서 발견되는 그 항목의 서브타입으로서 나타내는 도면이다.

도 6B는 상속 타입들이 명시적으로 리스트된(직접 속성 외에) 도 6A의 서브타입 항목을 나타내는 블록도이다.

도 7은 2개의 최상위 레벨 클래스 타입, 즉 Item 및 PropertyBase를 포함하는 기본 스키마, 및 이로부터 도출되는 추가적인 기본 스키마 타입들을 나타내는 블록도이다.

도 8A는 코어 스키마 내의 항목들을 나타내는 블록도이다.

도 8B는 코어 스키마 내의 속성 타입들을 나타내는 블록도이다.

도 9는 항목 폴더, 그의 멤버 항목들, 및 항목 폴더와 그의 멤버 항목들 사이의 상호접속 관계를 나타내는 블록도이다.

도 10은 카테고리(다시, 항목 자체), 그의 멤버 항목들, 및 카테고리와 그의 멤버 항목들 사이의 상호접속 관계를 나타내는 블록도이다.

도 11은 저장 플랫폼의 데이터 모델의 참조 타입 계층 구조를 나타내는 도면이다.

도 12는 관계들이 어떻게 분류되는지를 나타내는 도면이다.

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

도 14는 2개의 트랜잭션이 모두 동일한 B 트리 내에 새로운 레코드를 삽입하는 예를 나타내는 도면이다.

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

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

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

도 18은 포함 폴더의 개념을 나타내는 도면이다.

도 19는 저장 플랫폼 API의 기본 구조를 나타내는 도면이다.

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

도 21A는 예시적인 연락 항목 스키마의 도면이다.

도 21B는 도 21A의 예시적인 연락 항목 스키마에 대한 요소들의 도면이다.

도 22는 저장 플랫폼 API의 실행시간 프레임워크를 나타내는 도면이다.

도 23은 "FindAll" 동작의 실행을 나타내는 도면이다.

도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타내는 도면이다.

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

도 26은 데이터 보안을 위해 사용되는 액세스 마스크 포맷을 나타내는 도면이다.

도 27(a, b 및 c 부분)은 동일하게 보호되는 새로운 보안 영역이 기존 보안 영역으로부터 분리되는 것을 나타내는 도면이다.

도 28은 항목 검색 뷰의 개념을 나타내는 도면이다.

도 29는 예시적인 항목 계층 구조를 나타내는 도면이다.

도 30A는 인터페이스 Interface1을 제1 및 제2 코드 세그먼트들이 통신하는 통로로서 나타내는 도면이다.

도 30B는 인터페이스가, 시스템의 제1 및 제2 코드 세그먼트들이 매체(M)를 통해 통신하는 것을 가능하게 하는 인터페이스 객체들 I1 및 I2를 포함하는 것으로 나타내는 도면이다.

도 31A는 인터페이스 Interface1에 의해 제공되는 기능이 어떻게 인터페이스의 통신을 변환하도록 다수의 인터페이스 Interface1A, Interface1B, Interface1C 로 세분되는지를 나타내는 도면이다.

도 31B는 인터페이스 I1에 의해 제공되는 기능이 어떻게 다수의 인터페이스 I1a, I1b, I1c로 세분되는지를 나타내는 도면이다.

도 32A는 의미 없는 파라미터 정밀도가 무시되거나 임의의 파라미터로 대체될 수 있는 시나리오를 나타내는 도면이다.

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

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

도 33B는 인터페이스의 일부 또는 전부가 병합된 인터페이스를 형성하기 위해 다른 인터페이스 내에 인라인 작성될 수 있는 시나리오를 나타내는 도면이다.

도 34A는 미들웨어의 하나 이상의 부분들이 어떻게 제1 인터페이스 상의 통신들을 하나 이상의 상이한 인터페이스에 적응시키기 위해 이들을 변환할 수 있는지를 나타내는 도면이다.

도 34B는 어떻게 코드 세그먼트가 하나의 인터페이스로부터 통신을 수신하지만 기능을 제2 및 제3 인터페이스로 전송하기 위해 인터페이스와 함께 도입될 수 있는지를 나타내는 도면이다.

도 35A는 JIT(Just-In-Time) 컴파일러가 어떻게 하나의 코드 세그먼트로부터의 통신을 다른 코드 세그먼트로 변환하는지를 나타내는 도면이다.

도 35B는 하나 이상의 인터페이스를 동적으로 재기입하는 JIT 메소드가 상기 인터페이스를 동적으로 인수 분해하거나 변경하기 위해 적용될 수 있음을 나타내는 도면이다.

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

도 37은 어떻게 상태가 계산되는지, 또는 그와 관련된 메타데이터가 교환되는지를 알지 못하는 단순한 어댑터를 가정하는 본 발명의 일 실시예를 나타내는 도면이다.

목차

I. 서론

A. 예시적인 컴퓨팅 환경

B. 통상의 파일 기반 저장

II. 데이터의 체계화, 검색 및 공유를 위한 WINFS 저장 플랫폼

A. 용어집

B. 저장 플랫폼의 개요

C. 데이터 모델

1. 항목

2. 항목 식별

3. 항목 폴더 및 카테고리

4. 스키마

a) 기본 스키마

b) 코어 스키마

5. 관계

a) 관계 선언

b) 유지 관계

c) 삽입 관계

d) 참조 관계

e) 규칙 및 제한

f) 관계 순서화

6. 확장성

a) 항목 확장

b) 중첩 요소 타입 확장

D. 데이터베이스 엔진

1. UDT를 이용한 데이터 저장소 구현

2. 항목 매핑

3. 확장 매핑

4. 중첩 요소 매핑

5. 객체 식별

6. SQL 객체 명명

7. 칼럼 명명

8. 검색 뷰

a) 항목

(1) 마스터 항목 검색 뷰

(2) 타입화된 항목 검색 뷰

b) 항목 확장

(1) 마스터 확장 검색 뷰

(2) 타입화된 확장 검색 뷰

c) 중첩 요소

d) 관계

(1) 마스터 관계 검색 뷰

(2) 관계 인스턴스 검색 뷰

e)

9. 갱신

10. 변경 추적 및 묘비

a) 변경 추적

(1) "마스터" 검색 뷰에서의 변경 추적

(2) "타입화된" 검색 뷰에서의 변경 추적

b) 묘비

(1) 항목 묘비

(2) 확장 묘비

(3) 관계 묘비

(4) 묘비 소거

11. 헬퍼 API 및 함수

a) 함수 [System.Storage].GetItem

b) 함수 [System.Storage].GetExtension

c) 함수 [System.Storage].GetRelationship

12. 메타데이터

a) 스키마 메타데이터

b) 인스턴스 메타데이터

E. 보안

F. 통지 및 변경 추적

G. 통상의 파일 시스템 연동성

H. 저장 플랫폼 API

III. 동기화 API

A. 동기화의 개요

1. 저장 플랫폼 대 저장 플랫폼 동기화

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

b) 스키마 주석

c) Sync 구성

(1) 공동체 폴더-매핑

(2) 프로파일

(3) 스케쥴

d) 충돌 처리

(1) 충돌 검출

(a) 지식 기반 충돌

(b) 제한 기반 충돌

(2) 충돌 처리

(a) 자동 충돌 해결

(b) 충돌 로깅

(c) 충돌 검사 및 해결

(d) 사본의 수렴 및 충돌 해결의 전파

2. 비 저장 플랫폼 데이터 저장소에 대한 동기화

a) 동기화 서비스

(1) 변경 열거

(2) 변경 적용

(3) 충돌 해결

b) 어댑터 구현

3. 보안

4. 관리성

B. 동기화 API의 개요

1. 일반 용어

2. 동기화 API의 원리

C. 동기화 API 서비스

1. 변경 열거

2. 변경 적용

3. 샘플 코드

4. API 동기화의 방법

D. 동기화 스키마의 추가 양태들

IV. 결론

I. 서론

본 발명의 내용은 법적인 요건을 만족시키도록 구체적으로 설명된다. 그러나, 설명 자체는 본 발명의 범위를 한정하려는 의도는 아니다. 오히려, 본 발명자는 특허 청구된 내용이 다른 현재 또는 미래의 기술과 함께 본 명세서에서 설명된 것들과 다른 단계들 또는 유사한 단계들의 조합을 포함하도록 다른 방식으로 구현될 수도 있음을 고려하였다. 더욱이, "단계"라는 용어가 본 명세서에서 이용 방법들의 상이한 요소들을 의미하기 위해 사용될 수 있지만, 이 용어는 개별 단계들의 순서가 명시적으로 기술될 때를 제외하고는 다양한 단계들 사이의 임의의 특정 순서를 의미하는 것으로 해석되지 않아야 한다.

A. 예시적인 컴퓨팅 환경

본 발명의 다양한 실시예는 컴퓨터 상에서 실행될 수 있다. 도 1 및 아래의 설명은 본 발명이 구현될 수 있는 적절한 컴퓨팅 환경의 간략한 전반적인 설명을 제공하고자 의도된다. 요구되지는 않지만, 본 발명의 다양한 양태는 클라이언트 워크스테이션 또는 서버와 같은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행 가능 명령어와 일반적으로 관련하여 설명될 수 있다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 더욱이, 본 발명은 핸드헬드 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그래머블 소비자 전자장치, 네트워크 PC, 미니 컴퓨터, 메인프레임 컴퓨터 등을 포함하는 다른 컴퓨터 시스템 구성에서 실시될 수 있다. 본 발명은 또한 통신 네트워크를 통해 링크 된 원격 처리 장치들에 의해 작업가 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 양자에 위치할 수 있다.

도 1에 도시된 바와 같이, 예시적인 범용 컴퓨팅 시스템은 처리 장치(21), 시스템 메모리(22), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 처리 장치(21)에 결합하는 시스템 버스(23)를 포함하는 통상의 개인용 컴퓨터(20) 등을 포함한다. 시스템 버스(23)는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 다양한 버스 아키텍처 중 어느 하나를 이용한 로컬 버스를 포함하는 여러 타입의 버스 아키텍처 중 하나일 수 있다. 시스템 메모리는 ROM(24) 및 RAM(25)을 포함한다. 예컨대 시동 중에 개인용 컴퓨터(20) 내의 요소들 사이에서 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 BIOS(26)는 ROM(24)에 저장된다. 개인용 컴퓨터(20)는 도시되지 않은 하드 디스크에 대한 판독 및 기입을 위한 하드 디스크 드라이브(27), 도시되지 않은 착탈식 자기 디스크(29)에 대한 판독 및 기입을 위한 자기 디스크 드라이브(28), 및 CD-ROM 또는 다른 광학 매체와 같은 착탈식 광 디스크(31)에 대한 판독 및 기록을 위한 광 디스크 드라이브(30)를 더 포함할 수 있다. 하드 디스크 드라이브(27), 자기 디스크 드라이브(28) 및 광 디스크 드라이브(30)는 각각 하드 디스크 드라이브 인터페이스(32), 자기 디스크 드라이브 인터페이스(33) 및 광 디스크 드라이브 인터페이스(34)에 의해 시스템 버스(23)에 접속된다. 드라이브들 및 관련 컴퓨터 판독 가능 매체들은 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 개인용 컴퓨터(20)용 데이터의 비휘발성 저장을 제공 한다. 본 명세서에 설명되는 예시적인 환경이 하드 디스크, 착탈식 자기 디스크(29) 및 착탈식 광 디스크(21)를 사용하고 있지만, 자기 카세트, 플래시 메모리 카드, DVD, 베르누이 카트리지, 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, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 도 1에는 메모리 저장 장치(50)만이 도시되어 있지만, 일반적으로 개인용 컴퓨터(20)와 관련하여 위에 설명된 요소들의 대부분 또는 전부를 포함한다. 도 1에 도시된 논리 접속은 LAN(51) 및 WAN(52)을 포함한다. 이러한 네트워킹 환경은 사무실, 기업 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적이다.

개인용 컴퓨터(20)는 LAN 네트워킹 환경에서 사용될 때 네트워크 인터페이스 또는 어댑터(53)를 통해 LAN(51)에 접속된다. 개인용 컴퓨터(20)는 WAN 네트워킹 환경에서 사용될 때 일반적으로 인터넷과 같은 WAN(52)을 통해 통신을 설정하기 위한 모뎀 또는 다른 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(54)은 직렬 포트 인터페이스(46)를 통해 시스템 버스(23)에 접속된다. 네트워크 환경에서, 개인용 컴퓨터(20)와 관련하여 설명된 프로그램 모듈 또는 그 부분들은 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 사이에 통신 링크를 설정하기 위한 다른 수단이 사용될 수 있다는 것을 이해할 것이다.

도 2의 블록도에 도시된 바와 같이, 컴퓨터 시스템(200)은 크게 세 개의 컴포넌트 그룹, 즉 하드웨어 컴포넌트(202), 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204), 및 애플리케이션 프로그램 컴포넌트(206)(본 명세서에서 소정의 상 황에서 "사용자 컴포넌트" 또는 "소프트웨어 컴포넌트"로도 지칭됨)로 분류될 수 있다.

컴퓨터 시스템(200)의 다양한 실시예에서, 그리고 도 1을 다시 참조하면, 하드웨어 컴포넌트(202)는 CPU(21), 메모리(ROM(24) 및 RAM(25)), BIOS(26), 및 특히 키보드(40), 마우스(42), 모니터(47) 및/또는 프린터(도시되지 않음)와 같은 다양한 입출력(I/O) 장치를 포함할 수 있다. 하드웨어 컴포넌트(202)는 컴퓨터 시스템(200)을 위한 기본 물리적 기반 구조를 포함한다.

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

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

하드웨어/소프트웨어 인터페이스 시스템은 일반적으로 시동시에 컴퓨터 시스템에 로딩된 후, 컴퓨터 시스템 내의 모든 애플리케이션 시스템을 관리한다. 애플리케이션 프로그램은 API를 통해 서비스를 요구함으로써 하드웨어/소프트웨어 인터페이스 시스템과 상호작용한다. 몇몇 애플리케이션 프로그램은 최종 사용자가 명령 언어 또는 GUI와 같은 사용자 인터페이스를 통해 하드웨어/소프트웨어 인터페이스 시스템과 상호작용하는 것을 가능하게 한다.

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

하드웨어/소프트웨어 인터페이스 시스템 쉘(여기서는 단순히 "쉘"로서 지칭됨)은 하드웨어/소프트웨어 인터페이스 시스템에 대한 대화식 최종 사용자 인터페이스이다. (쉘은 "명령 해석기" 또는 운영 체제에서 "운영 체제 쉘"로도 지칭될 수 있다.) 쉘은 애플리케이션 및/또는 최종 사용자에 의해 직접 액세스될 수 있는 하드웨어/소프트웨어 인터페이스 시스템의 외곽 계층이다. 쉘과 달리, 커널은 하드웨어 컴포넌트와 직접 상호작용하는 하드웨어/소프트웨어 인터페이스 시스템의 내부 계층이다.

본 발명의 다양한 실시예가 컴퓨터화된 시스템에 특히 적합한 것으로 생각되지만, 본 명세서에서 이러한 실시예들로 본 발명을 한정하려는 어떤 것도 의도되지 않는다. 이와 달리, 여기서 사용되는 "컴퓨터 시스템"이라는 용어는 장치들이 사실상 전자, 머신, 논리 또는 가상 장치인지에 관계없이 정보를 저장하고 처리할 수 있고, 그리고/또는 저장된 정보를 이용하여 장치 자체의 거동 또는 실행을 제어할 수 있는 임의의 장치 및 모든 장치를 포함하는 것으로 의도된다.

B. 통상의 파일 기반 저장

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

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

전술한 것 외에, 각 폴더는 그의 서브 폴더 및 그의 파일들에 대한 컨테이너인데, 즉 각 폴더는 그의 서브 폴더 및 파일을 소유한다. 예컨대, 폴더가 하드웨어/소프트웨어 인터페이스 시스템에 의해 삭제될 때, 그 폴더의 서브 폴더 및 파일들도 삭제된다(각 서브 폴더의 경우, 그 자신의 서브 폴더 및 파일들을 반복적으로 더 포함한다). 마찬가지로, 각 파일은 일반적으로 단 하나의 폴더에 의해 소유되며, 파일이 복사될 수 있고, 사본이 다른 폴더에 위치될 수 있지만, 파일의 사본 자체는 원본과의 직접적인 연결을 갖지 않는 상이하고 개별적인 단위이다(예를 들어, 원본 파일에 대한 변경은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서는 사본 파일에 반영되지 않는다). 이러한 관계에 따라서, 파일 및 폴더는 특성상 "물리적"인데, 이는 폴더가 물리적 컨테이너와 같이 취급되고, 파일이 이 컨테이너 내의 상이하고 개별적인 물리적 요소로 취급되기 때문이다.

II. 데이터의 체계화, 검색 및 공유를 위한 WINFS 저장 플랫폼

본 발명은 여기서 초기에 설명된 바와 같이 참조로 반영된 관련 발명들과 함께 데이터를 체계화하고, 검색하고, 공유하기 위한 저장 플랫폼에 관련된다. 본 발명의 저장 플랫폼은 전술한 기존 파일 시스템 및 데이터베이스 시스템의 종류들을 넘어 데이터 플랫폼을 확장하고 확대하며, 항목이라고 하는 새로운 데이터 형태를 포함하는 모든 데이터 타입에 대한 저장소가 되도록 설계된다.

A. 용어집

본 명세서 및 청구범위에서 사용되는 아래의 용어는 다음의 의미를 갖는다.

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

ㆍ"운영 체제(OS)"는 애플리케이션 프로그램과 컴퓨터 하드웨어 사이에서 중개자로서 기능하는 특수 프로그램이다. OS는 대부분의 경우 쉘 및 커널을 포함한다.

ㆍ"하드웨어/소프트웨어 인터페이스 시스템"은 컴퓨터 시스템의 기반 하드웨 어 컴포넌트들과 컴퓨터 시스템 상에서 실행되는 애플리케이션들 사이의 인터페이스로서 기능하는 소프트웨어 또는 하드웨어 및 소프트웨어의 조합이다. 하드웨어/소프트웨어 인터페이스 시스템은 일반적으로 운영 체제를 포함한다(그리고, 몇몇 실시예에서는 운영 체제만으로 구성된다). 하드웨어/소프트웨어 인터페이스 시스템은 또한 가상 머신 관리자(VMM), 공통 언어 실행 시간(CLR) 또는 그의 기능적 등가물, 자바 가상 머신(JVM) 또는 그의 기능적 등가물, 또는 컴퓨터 시스템 내의 운영 체제에 대신하거나 추가적으로 다른 그러한 소프트웨어 컴포넌트를 포함할 수 있다. 하드웨어/소프트웨어 인터페이스 시스템의 목적은 사용자가 애플리케이션 프로그램을 실행할 수 있는 환경을 제공하는 것이다. 임의의 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 하드웨어를 효율적인 방식으로 사용하는 것은 물론 컴퓨터 시스템을 사용하기 편리하게 만드는 것이다.

B. 저장 플랫폼의 개요

도 3을 참조하면, 저장 플랫폼(300)은 데이터베이스 엔진(314) 상에서 구현되는 데이터 저장소(302)를 포함한다. 일 실시예에서, 데이터베이스 엔진은 객체 관계 확장들을 가진 관계형 데이터베이스 엔진을 포함한다. 일 실시예에서, 관계형 데이터베이스 엔진(314)은 마이크로소프트 SQL 서버 관계형 데이터베이스 엔진을 포함한다. 데이터 저장소(302)는 데이터의 체계화, 검색, 공유, 동기화, 및 보안을 지원하는 데이터 모델(304)을 구현한다. 특정 타입의 데이터는 스키마(340)와 같은 스키마에서 기술되며, 저장 플랫폼(300)은 후술하는 바와 같이 이러한 스 키마를 전개하는 것은 물론, 이러한 스키마를 확장하기 위한 도구(346)를 제공한다.

데이터 저장소(302) 내에 구현되는 변경 추적 메커니즘(306)은 데이터 저장소에 대한 변경을 추적할 수 있는 능력을 제공한다. 데이터 저장소(302)는 또한 보안 능력(308) 및 승진/강등 능력(310)을 제공하는데, 이들 양자는 후술한다. 데이터 저장소(302)는 또한 다른 저장 플랫폼 컴포넌트 및 저장 플랫폼을 이용하는 애플리케이션 프로그램(예컨대, 애플리케이션 프로그램 350a, 350b, 350c)에게 데이터 저장소(302)의 능력들을 노출시키기 위한 한 세트의 API(312)를 제공한다. 본 발명의 저장 플랫폼은 애플리케이션 프로그램(350a, 350b, 350c)과 같은 애플리케이션 프로그램이 전술한 저장 플랫폼의 모든 능력에 액세스하고 스키마에 기술된 데이터에 액세스하는 것을 가능하게 하는 API(322)를 더 포함한다. 저장 플랫폼 API(322)는 OLE DB API(324) 및 마이크로소프트 윈도우 Win32 API(326)와 같은 다른 API와 함께 애플리케이션 프로그램에 의해 사용될 수 있다.

본 발명의 저장 플랫폼은 사용자들 또는 시스템들 사이의 데이터 공유를 쉽게 하는 동기화 서비스(330)를 포함하는 다양한 서비스(328)를 애플리케이션 프로그램에 제공할 수 있다. 예컨대, 동기화 서비스(330)는 데이터 저장소(302)와 동일한 포맷을 가진 다른 데이터 저장소(340)와의 연동은 물론, 다른 포맷을 가진 데이터 저장소(342)에 대한 액세스를 가능하게 할 수 있다. 저장 플랫폼(300)은 또한 윈도우 NTFS 파일 시스템(318)과 같은 기존 파일 시스템과 데이터 저장소(302)의 연동을 허용하는 파일 시스템 능력을 제공한다. 적어도 몇몇 실시예에서, 저장 플랫폼(300)은 또한 데이터가 다른 시스템 상에서 동작하는 것을 가능하게 하고 다른 시스템과의 상호작용을 가능하게 하는 추가적인 능력을 애플리케이션 프로그램에게 제공할 수 있다. 이러한 능력들은 정보 에이전트 서비스(334) 및 통지 서비스(332)와 같은 추가 서비스(328)의 형태는 물론, 다른 유틸리티(336)의 형태로 구현될 수 있다.

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

아래의 설명에서, 그리고 다양한 도면들에서, 본 발명의 저장 플랫폼(300)은 "WinFS"로 지칭될 수 있다. 그러나, 이러한 저장 플랫폼을 지칭하는 명칭의 사용은 단지 설명의 편의를 위한 것이며, 어떠한 식으로도 제한하려는 의도는 아니다.

C. 데이터 모델

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

데이터 모델은 2개의 기본 메커니즘, 즉 타입 및 관계에 의존한다. 타입은 타입의 인스턴스의 형태를 지배하는 포맷을 제공하는 구조이다. 포맷은 순서화된 속성들의 세트로서 표현된다. 속성은 주어진 타입의 값 또는 값들의 세트에 대한 명칭이다. 예컨대, USPostalAddress 타입은 Street, City, Zip, State의 속성들을 가질 수 있는데, 여기서 Street, City 및 State는 스트링 타입이고, Zip은 Int32 타입이다. Street는 다가(즉 한 세트의 값들)이어서, 어드레스가 Street 속성에 대해 둘 이상의 값을 갖는 것을 허용할 수 있다. 시스템은 다른 타입의 구축에 사용될 수 있는 소정의 기본 타입을 정의하는데, 이들은 String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DataTime, Decimal 및 GUID를 포함한다. 타입의 속성들은 기본 타입들 중 어느 하나 또는 (아래에 설명되는 소정의 제한과 함께) 구축된 타입들 중 어느 하나를 이용하여 정의될 수 있다. 예컨대, 좌표 및 어드레스 속성을 가진 위치 타입이 정의될 수 있는데, 어드레스 속성은 전술한 바와 같이 USPostalAddress 타입이다. 속성들은 또한 필수적 또는 선택적일 수 있다.

관계는 두 타입의 인스턴스들의 세트들 사이에 선언될 수 있으며, 이들 사이의 매핑을 표현한다. 예컨대, 사람 타입과, 어느 사람이 어느 위치에 살고 있는지를 정의하는 LivesAt이라고 하는 위치 타입 사이에 관계가 선언될 수 있다. 관계는 명칭, 2개의 엔드 포인트, 즉 소스 엔드 포인트 및 타겟 엔드 포인트를 갖는다. 관계는 또한 순서화된 속성들의 세트를 가질 수 있다. 소스 및 타겟 엔드 포인트들 양자는 명칭 및 타입을 갖는다. 예컨대, LivesAt 관계는 사람 타입의 거주자라고 하는 소스 및 위치 타입의 주거지라고 하는 타겟을 가지며, 또한 거주자가 주거지에 산 기간을 나타내는 StartDate 및 EndDate 속성을 갖는다. 사람은 시간에 따라 다수의 주거지에 살 수 있고, 주거지는 다수의 거주자를 가질 수 있으며, 따라서 StartDate 및 EndDate 정보를 넣을 가장 가능성 있는 장소는 관계 자체이다.

관계는 엔드 포인트 타입으로 주어진 타입에 의해 제한되는 인스턴스들 사이의 매핑을 정의한다. 예컨대, LivesAt 관계는 자동차가 거주자인 관계일 수 없는데, 이는 자동차가 사람이 아니기 때문이다.

데이터 모델은 타입들 사이의 서브 타입-수퍼 타입 관계의 정의를 허용한다. BaseType 관계로도 알려진 서브 타입-수퍼 타입 관계는 타입 A가 타입 B에 대한 BaseType인 경우에 B의 모든 인스턴스가 A의 인스턴스이기도 한 경우가 존재해야 하는 방식으로 정의된다. 이것을 표현하는 또 하나의 방법은 B에 따르는 모든 인스턴스는 A도 따라야 한다는 것이다. 예컨대, A가 스트링 타입의 속성 명칭을 갖고, B가 Int16 타입의 속성 나이를 갖는 경우, B의 임의의 인스턴스는 명칭 및 나이 양자를 가져야 한다. 타입 계층 구조는 루트에 단일 수퍼 타입을 가진 트리로 서 생각될 수 있다. 루트로부터의 분기들은 제1 레벨의 서브 타입들을 제공하며, 이 레벨의 분기들은 제2 레벨의 서브 타입들을 제공하는 등, 이것은 그 자체가 어떠한 서브 타입도 갖지 않는 말단 서브 타입까지 계속된다. 트리는 균일한 깊이를 갖는 것으로 제한되지 않으나, 어떠한 순환도 포함할 수 없다. 주어진 타입이 제로 또는 많은 서브 타입 및 제로 또는 하나의 수퍼 타입을 가질 수 있다. 주어진 인스턴스는 많아야 하나의 타입 및 이 타입의 수퍼 타입에 따를 수 있다. 또 하나의 방법으로서, 트리 내에 임의의 레벨의 주어진 인스턴스에 대해, 이 인스턴스는 그 레벨에 있는 많아야 하나의 서브 타입에 따를 수 있다. 타입은 그 타입의 인스턴스들이 그 타입의 서브 타입의 인스턴스이기도 해야 하는 경우 추상적이라고 일컬어진다.

1. 항목

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

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

항목은 연락, 사람, 서비스, 위치, 문서(모든 다양한 종류) 등과 같은 데이터의 실세계의 쉽게 이해될 수 있는 단위를 나타낸다. 도 5A는 항목의 구조를 나타내는 블록도이다. 항목의 고유 명칭은 "위치"이다. 항목의 적격 명칭은 이 항목의 구조가 코어 스키마 내에 특정 타입의 항목으로 정의되어 있음을 나타내는 "Core.Location"이다. (코어 스키마는 후술한다.)

위치 항목은 EAddress, MetropolitanRegion, Neighborhood 및 PostalAddress를 포함하는 다수의 속성을 갖는다. 각각에 대한 속성의 특정 타입은 속성 명칭 직후에 표시되며, 콜론(":")에 의해 속성 명칭과 구분된다. 타입 명칭의 우측에, 그 속성 타입에 대해 허용되는 값들의 수가 대괄호들("[]") 사이에 표시되는데, 콜론 우측의 별표("*")는 미지정 및/또는 비제한 수("다수")를 나타낸다. 콜론 우측의 "1"은 기껏해야 하나의 값이 존재할 수 있다는 것을 나타낸다. 콜론 좌측의 제로("0")는 속성이 선택적이라는 것을 나타낸다(아무 값도 존재하지 않을 수 있다). 콜론 좌측의 "1"은 적어도 하나의 값이 존재해야 한다는 것을 나타낸다(속성이 필요하다). Neighborhood 및 MetropolitanRegion은 모두 미리 정의된 데이터 타입 또는 "단순 타입"(그리고 본 명세서에서 대문자화 없이 표시됨)인 "nvarchar"(또는 등가물) 타입이다. 그러나, EAddress 및 PostalAddress는 각각 EAddress 및 PostalAddress 타입의 정의된 타입 또는 "복합 타입"(여기서 대문자화에 의해 표시됨)의 속성들이다. 복합 타입은 하나 이상의 단순 데이터 타입 및/또는 다른 복합 타입으로부터 도출되는 타입이다. 항목의 속성들에 대한 복합 타입은 또한 "중첩 요소"를 구성하는데, 이는 복합 타입의 상세가 그의 속성들을 정의하기 위해 직접 항목 내에 중첩되고, 복합 타입에 관한 정보가 이들 속성을 가진 항목과 함께 (후술하는 바와 같이 항목의 경계 내에) 유지되기 때문이다. 이러한 타입화의 개념은 공지되어 있으며, 당업자들에게 쉽게 이해된다.

도 5B는 복합 속성 타입인 PostalAddress 및 EAddress를 나타내는 블록도이다. PostalAddress 속성 타입은 PostalAddress 속성 타입의 항목이 0 또는 1의 City 값, 0 또는 1의 CountryCode 값, 0 또는 1의 MailStop 값 및 임의 수(0 내지 다수)의 PostalAddressType 등등을 갖는 것으로 예상될 수 있다. 이러한 방식으로, 항목 내의 특정 속성에 대한 데이터의 형상이 그에 따라 정의된다. EAddress 속성 타입은 도시된 바와 유사하게 정의된다. 본 명세서에서는 선택적으로 사용되지만, 위치 항목에서 복합 타입을 표현하는 또 하나의 방법은 항목을 그 안에 리스트된 각각의 복합 타입의 개별 속성들과 함께 드로잉하는 것이다. 도 5C는 복합 타입들이 더 기술되어 있는 위치 항목을 나타내는 블록도이다. 그러나, 이러한 도 5C의 위치 항목의 대체 표현은 도 5A에 도시된 것과 정확히 동일한 항목에 대한 것이라는 것을 이해해야 한다. 본 발명의 저장 플랫폼은 또한 서브 타입화를 허용하는데, 이에 따라 하나의 속성 타입이 다른 속성 타입의 서브 타입이 될 수 있다(하나의 속성 타입은 다른 부모 속성 타입의 속성을 상속한다).

속성들 및 이들의 속성 타입과 유사하지만 다르게, 항목들은 서브 타입화의 주체일 수도 있는 그들 자신의 항목 타입들을 고유하게 표현한다. 즉, 본 발명의 여러 실시예에서의 저장 플랫폼은 항목이 다른 항목의 서브 타입이 되는 것을 허용 한다(이에 따라 하나의 항목은 다른 부모 항목의 속성을 상속한다). 더욱이, 본 발명의 다양한 실시예에서, 모든 항목은 기본 스키마에서 발견되는 제1 및 기본 항목 타입인 "항목" 항목 타입의 서브 타입이다. (기본 스키마도 후술된다). 도 6A는 기본 스키마에서 발견되는 Item 항목 타입의 서브 타입인 항목, 이 인스턴스 내의 위치 항목을 나타낸다. 이 도면에서, 화살표는 위치 항목이(모든 다른 항목과 같이) Item 항목 타입의 서브 타입임을 나타낸다. 모든 다른 항목이 도출되는 기본 항목인 Item 항목 타입은 ItemId 및 다양한 타임 스탬프와 같은 다수의 중요한 속성을 가지며, 이에 의해 운영 체제 내의 모든 항목의 표준 속성을 정의한다. 이 도면에서, 이러한 Item 항목 타입의 속성들은 위치에 의해 상속되며, 이에 의해 위치의 속성이 된다.

Item 항목 타입으로부터 상속된 위치 항목의 속성을 표현하는 또 하나의 방법은 위치를 그 안에 리스트된 부모 항목으로부터의 각각의 속성 타입의 개별 속성들과 함께 드로잉하는 것이다. 도 6B는 직접 속성 외에 상속된 타입들이 기술되는 위치 항목을 나타내는 블록도이다. 이 도면에서는 위치가 그의 속성들 모두와 함께, 즉 이 도면과 도 5A 양쪽에 도시된 직접 속성, 및 이 도면에는 도시되어 있으나 도 5A에는 없는(반면, 도 5A에서는, 위치 항목이 Item 항목 타입의 서브 타입이라는 것을 화살표로 표시함으로써 이들 속성이 참조된다) 상속된 속성과 함께 도시되어 있지만, 이 위치 항목은 도 5A에 도시된 것과 동일한 항목이라는 점에 유의하고 이해해야 한다.

항목은 독립 객체이며, 따라서 항목을 삭제할 경우, 항목의 직접 및 상속 속 성 모두가 또한 삭제된다. 마찬가지로, 항목을 검색할 때, 수신되는 것은 항목 및 그의 모든 직접 및 상속 속성(그의 복합 속성 타입에 관한 정보 포함)이다. 본 발명의 소정 실시예는 특정 항목을 검색할 때 속성들의 서브 세트를 요구하는 것을 가능하게 하지만, 이러한 많은 실시예의 디폴트는 검색시 항목을 그의 모든 직접 및 상속 속성들과 함께 제공하는 것이다. 더욱이, 항목의 속성은 또한 그 항목의 타입의 기존 속성에 새로운 속성을 추가함으로써 확장될 수 있다. 이러한 "확장"은 그후 항목의 진정한 속성이 되며, 그 항목의 서브 타입은 확장 속성을 자동으로 포함할 수 있다.

항목의 "경계"는 그의 속성(복합 속성 타입, 확장 등을 포함)에 의해 표현된다. 항목의 경계는 또한 복사, 삭제, 이동, 생성 등과 같이 항목에 대해 수행되는 동작의 한계를 표현한다. 예컨대, 본 발명의 여러 실시예에서, 항목이 복사될 때, 그 항목의 경계 내의 모든 것이 또한 복사된다. 각 항목에 대해, 경계는 다음을 포함한다:

ㆍ 항목의 항목 타입, 및 항목이 다른 항목의 서브 타입인 경우(모든 항목이 기본 스키마 내의 단일 항목 및 항목 타입으로부터 도출되는 본 발명의 여러 실시예의 경우와 같이), 임의의 적용 가능한 서브 타입 정보(즉, 부모 항목 타입에 관한 정보). 복사되는 원본 항목이 다른 항목의 서브 타입인 경우, 사본도 그 동일 항목의 서브 타입일 수 있다.

ㆍ 있을 경우, 항목의 복합 타입 속성 및 확장. 원본 항목이 복합 타입(원시 또는 확장)의 속성을 가진 경우, 사본도 동일한 복합 타입을 가질 수 있다.

ㆍ 항목의 "소유 관계"에 대한 기록, 즉 이 항목(소유 항목)이 어떤 다른 항목(타겟 항목)을 소유하고 있는지를 나타내는 항목 자신의 리스트. 이것은 후술하는 바와 같이 항목 폴더와 특히 관련이 있으며, 규칙은 아래에서 모든 항목이 적어도 하나의 항목 폴더에 속해야 하는 것을 지시한다. 더욱이, 후술하는 삽입 항목과 관련하여, 삽입 항목은 이 삽입 항목이 복사, 삭제 등과 같은 동작을 위해 삽입되는 항목의 일부로서 간주된다.

2. 항목 식별

항목은 ItemID에 의해 글로벌 항목 공간 내에서 고유하게 식별된다. Base.Item 타입은 항목에 대한 식별자를 저장하는 타입 GUID의 필드 ItemID를 정의한다. 항목은 데이터 저장소(302) 내에 정확하게 하나의 식별자를 가져야 한다.

항목 참조는 항목을 찾고 식별하기 위한 정보를 포함하는 데이터 구조이다. 데이터 모델에서, 모든 항목 참조 타입이 도출되는 ItemReference라는 명칭의 추상 타입이 정의된다. ItemReference 타입은 Resolve라는 명칭의 가상 메소드를 정의한다. Resolve 메소드는 ItemReference를 분석하고, 항목을 리턴한다. 이 메소드는 참조가 주어질 때 항목을 검색하는 함수를 구현하는 ItemReference의 구체적인 서브 타입들에 의해 무시된다. Resolve 메소드는 저장 플랫폼 API(322)의 일부로서 호출된다.

ItemIDReference는 ItemReference의 서브 타입이다. 이것은 Locator 및 ItemID 필드를 정의한다. Locator 필드는 항목 도메인을 명명(즉, 식별)한다. 이 것은 항목 도메인에 대한 Locator의 값을 분석할 수 있는 로케이터 분석 메소드에 의해 처리된다. ItemID 필드는 ItemID 타입이다.

ItemPathReference는 Locator 및 Path 필드를 정의하는 ItemReference의 특수 형태이다. Locator 필드는 항목 도메인을 식별한다. 이것은 항목 도메인에 대한 Locator의 값을 분석할 수 있는 로케이터 분석 메소드에 의해 처리된다. Path 필드는 Locator에 의해 제공되는 항목 도메인에서 루트된 저장 플랫폼 명칭 공간 내의 (상대) 경로를 포함한다.

이러한 타입의 참조는 세트 동작에서 사용될 수 없다. 참조는 일반적으로 경로 분석 프로세스를 통해 분석되어야 한다. 저장 플랫폼 API(322)의 Resolve 메소드는 이러한 기능을 제공한다.

전술한 참조 형태는 도 11에 도시된 참조 타입 계층 구조를 통해 표현된다. 이러한 타입으로부터 상속되는 추가적인 참조 타입들이 스키마에서 정의될 수 있다. 이들은 관계 선언에서 타겟 필드의 타입으로서 사용될 수 있다.

3. 항목 폴더 및 카테고리

후술하는 바와 같이, 항목 그룹은 항목 폴더(파일 폴더와 혼동하지 말 것)라고 하는 특수 항목 내에 체계화된다. 그러나, 대부분의 파일 시스템과 달리, 항목은 둘 이상의 항목 폴더에 속할 수 있으며, 따라서 항목이 하나의 항목 폴더에서 액세스되고 수정된 때, 이 수정된 항목은 다른 항목 폴더로부터 직접 액세스될 수 있다. 본질적으로, 항목에 대한 액세스는 상이한 항목 폴더들로부터 이루어질 수 있지만, 실제로 액세스되는 것은 실제로는 동일한 항목이다. 그러나, 항목 폴더는 그의 멤버 항목들 모두를 반드시 소유하지는 않거나, 단순히 다른 폴더와 함께 항목들을 공유할 수 있으며, 따라서 항목 폴더의 삭제가 반드시 항목의 삭제로 귀착되는 것은 아니다. 그럼에도, 본 발명의 여러 실시예에서, 항목은 적어도 하나의 항목 폴더에 속해야 하며, 따라서 특정 항목에 대한 유일한 항목 폴더가 삭제된 경우, 몇몇 실시예에서는 항목이 자동으로 삭제되거나, 다른 실시예에서는 항목이 자동으로 디폴트 항목 폴더(예컨대, 다양한 파일-폴더 기반 시스템에서 사용되는 유사 명칭 폴더들과 개념적으로 유사한 "Trash Can" 항목 폴더)의 멤버가 된다.

또한 후술하는 바와 같이, 항목은 또한 (a) 항목 타입(또는 타입들), (b) 특정 직접 또는 상속 속성(또는 속성들), 또는 (c) 항목 속성에 대응하는 특정 값(또는 값들)과 같은 공통 기술 특성에 기초하는 카테고리에 속할 수 있다. 예컨대, 개인 연락 정보에 대한 특정 속성을 포함하는 항목은 자동으로 Contact 카테고리에 속할 수 있으며, 연락 정보 속성을 가진 임의의 항목도 자동으로 이 카테고리에 속할 것이다. 마찬가지로, "New York City" 값의 위치 속성을 갖는 임의의 항목은 자동으로 NewYorkCity 카테고리에 속할 수 있다.

카테고리는 개념적으로 항목 폴더와 다른데, 이는 항목 폴더가 서로 관련되지 않은(즉 공통 기술 특성이 없는) 항목들을 포함할 수 있는 반면, 카테고리 내의 각 항목은 그 카테고리에 대해 기술되는 공통 타입, 속성 또는 값(공통성)을 가지며, 카테고리 내의 다른 항목들에 대한, 그리고 그들 사이에서의 관계에 대한 기초를 형성하는 것은 이러한 공통성이기 때문이다. 더욱이, 특정 폴더 내의 항목의 멤버는 그 항목의 임의의 특정 양태에 강제로 기초하지 않는 반면, 소정 실시예에서 카테고리에 절대적으로 관련된 공통성을 가진 모든 항목은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 자동으로 그 카테고리의 멤버가 될 수 있다. 개념적으로, 카테고리는 또한 특정 질의(예를 들어, 데이터베이스와 관련하여)의 결과에 기초하는 멤버을 갖는 가상 항목 폴더로 간주될 수도 있으며, 따라서 이러한 질의의 조건(카테고리의 공통성에 의해 정의됨)을 만족시키는 항목들은 카테고리의 멤버을 포함한다.

도 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개의 최상위 레벨 타입, 즉 Item, Extension 및 PropertyBase를 정의한다. 도시된 바와 같이, 항목 타입은 기본 "항목" 항목 타입의 속성들에 의해 정의 된다. 이와 달리, 최상위 레벨 속성 타입 "PropertyBase"는 미리 정의된 속성을 갖지 않으며, 단지 모든 다른 속성 타입이 도출되고, 도출된 모든 속성 타입이 상호 관련되는(단일 속성 타입으로부터 공동으로 도출됨) 앵커일 뿐이다. 확장 타입 속성은 확장이 어느 항목을 확장하는지는 물론, 항목이 다수의 확장을 가질 수 있을 때 하나의 확장을 다른 확장과 구별할 수 있는 식별자를 정의한다.

ItemFolder는 항목으로부터 상속된 속성들 외에 그의 멤버들(있을 경우)에 대한 링크를 설정하기 위한 관계를 특징으로 하는 Item 항목 타입의 서브 타입이며, IdentityKey 및 Property는 PropertyBase의 서브 타입이다. 또한, CategoryRef는 IdentityKey의 서브 타입이다.

b) 코어 스키마

본 발명의 저장 플랫폼의 다양한 실시예는 최상위 레벨 항목 타입 구조에 대한 개념적 프레임워크를 제공하는 코어 스키마를 더 포함한다. 도 8A는 코어 스키마 내의 항목을 나타내는 블록도이고, 도 8B는 코어 스키마 내의 속성 타입을 나타내는 블록도이다. 파일-폴더 기반 시스템에서 상이한 확장자(*.com, *.exe, *.bat, *.sys 등) 및 다른 기준을 가진 파일들 사이의 차이는 코어 스키마의 함수와 유사하다. 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서, 코어 스키마는, 직접(항목 타입에 의해) 또는 간접으로(항목 서브 타입에 의해) 항목 기반 하드웨어/소프트웨어 인터페이스 시스템이 이해하고 소정의 예측 가능한 방식으로 직접 처리할 수 있는 하나 이상의 코어 스키마 항목 타입으로 모든 항목을 특징화 하는 한 세트의 코어 항목 타입을 정의한다. 미리 정의된 항목 타입은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가장 공통적인 항목을 반영하며, 따라서 코어 스키마를 포함하는 미리 정의된 항목 타입을 이해하는 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 일정 레벨의 효율성이 얻어진다.

소정 실시예에서, 코어 스키마는 확장 가능하지 않은데, 즉 코어 스키마의 일부인 미리 정의되고 도출된 특정 항목 타입들을 제외하고는 기본 스키마 내의 항목 타입으로부터 어떠한 추가적인 항목 타입도 직접 서브 타입화될 수 없다. 코어 스키마에 대한 확장을 방지함으로써(즉, 코어 스키마에 새로운 항목의 추가를 방지함으로써), 저장 플랫폼은 코어 스키마 항목 타입들의 사용을 지시하는데, 이는 모든 후속 항목 타입이 반드시 코어 스키마 항목 타입의 서브 타입이기 때문이다. 이러한 구조는 추가적인 항목 타입을 정의함에 있어서 합리적인 정도의 유연성을 가능하게 하면서 미리 정의된 코어 항목 타입 세트를 갖는 이익도 유지할 수 있게 한다.

본 발명의 다양한 실시예에서, 그리고 도 8A를 참조하면, 코어 스키마에 의해 지원되는 특정 항목 타입은 다음 중 하나 이상을 포함한다.

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

ㆍ Commodity: 값을 식별할 수 있는 항목

ㆍ Device: 정보 처리 능력을 지원하는 논리 구조를 가진 항목

ㆍ Document: 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 해 석되지 않는 대신 문서 타입에 대응하는 애플리케이션 프로그램에 의해 해석되는 콘텐츠를 가진 항목

ㆍ Event: 환경에서 소정의 발생을 기록하는 항목

ㆍ Location: 물리적 위치(예컨대, 지리적 위치)를 나타내는 항목

ㆍ Message: 둘 이상의 원리(아래 정의됨) 사이의 통신 항목

ㆍ Principal: ItemID와 별도로 명확하게 입증할 수 있는 적어도 하나의 식별자(예컨대, 사람, 조직, 그룹, 세대, 저자, 서비스 등의 식별자)를 가진 항목

ㆍ Statement: 제한 없이, 정책, 가입, 자격증 등을 포함하는 환경에 관한 특수 정보를 가진 항목

마찬가지로, 그리고 도 8B를 참조하면, 코어 스키마에 의해 지원되는 특정 속성 타입은 다음 중 하나 이상을 포함할 수 있다.

ㆍ Certificate(기본 스키마 내의 기본 PropertyBase 타입으로부터 도출됨)

ㆍ Principal Identity Key(기본 스키마 내의 IdentityKey 타입으로부터 도출됨)

ㆍ Postal Address(기본 스키마 내의 속성 타입으로부터 도출됨)

ㆍ Rich Text(기본 스키마 내의 속성 타입으로부터 도출됨)

ㆍ EAddress(기본 스키마 내의 속성 타입으로부터 도출됨)

ㆍ IdentitySecurityPackage(기본 스키마 내의 관계 타입으로부터 도출됨)

ㆍ RoleOccupancy(기본 스키마 내의 관계 타입으로부터 도출됨)

ㆍ BasicPresence(기본 스키마 내의 관계 타입으로부터 도출됨)

이들 항목 및 속성은 도 8A 및 도 8B에 설명된 그들 각각의 속성에 의해 또한 설명된다.

5. 관계

관계는 하나의 항목이 소스로 지정되고 다른 항목이 타겟으로 지정되는 바이너리 관계이다. 소스 항목 및 타겟 항목은 관계에 의해 관련된다. 소스 항목은 일반적으로 관계의 수명을 제어한다. 즉, 소스 항목이 삭제될 대, 항목들 사이의 관계도 삭제된다.

관계는 포함 및 참조 관계로 분류된다. 포함 관계는 타겟 항목의 수명을 제어하는 반면, 참조 관계는 어떠한 수명 관리 시맨틱도 제공하지 않는다. 도 12는 관계들이 분류되는 방식을 나타낸다.

포함 관계 타입은 유지 및 삽입 관계로 더 분류된다. 항목에 대한 모든 유지 관계가 제거될 때, 그 항목은 삭제된다. 유지 관계는 참조 카운팅 메커니즘을 통해 타겟의 수명을 제어한다. 삽입 관계는 복합 항목의 모델링을 가능하게 하며, 배타적 유지 관계로서 간주될 수 있다. 항목은 하나 이상의 유지 관계의 타겟일 수 있으나, 항목은 단 하나의 삽입 관계의 타겟일 수 있다. 삽입 관계의 타겟인 항목은 임의의 다른 유지 또는 삽입 관계의 타겟이 될 수 없다.

참조 관계는 타겟 항목의 수명을 제어하지 않는다. 참조 관계는 공중에 뜰 수 있는데, 즉 타겟 항목이 존재하지 않을 수 있다. 참조 관계는 글로벌 항목 명칭 공간(즉, 원격 데이터 저장소 포함) 내의 어느 곳에서나 항목에 대한 참조를 모 델링하는 데 사용될 수 있다.

항목의 인출은 그의 관계를 자동으로 인출하지 못한다. 애플리케이션은 항목의 관계를 명시적으로 요구해야 한다. 또한, 관계의 수정은 소스 또는 타겟 항목을 수정하지 못하며, 유사하게 관계의 추가는 소스/타겟 항목에 영향을 주지 못한다.

a) 관계 선언

명시적인 관계 타입은 다음 요소들과 함께 정의된다.

ㆍ 관계 명칭은 명칭 속성 내에 지정된다.

ㆍ 관계 타입은 다음 중 하나: 유지, 삽입, 참조. 이것은 타입 속성 내에 지정된다.

ㆍ 소스 및 타겟 엔드 포인트. 각 엔드 포인트는 참조되는 항목의 명칭 및 타입을 지정한다.

ㆍ 소스 엔드 포인트 필드는 일반적으로 ItemID 타입(선언되지 않음)이며, 관계 인스턴스와 동일한 데이터 저장소 내의 항목을 참조해야 한다.

ㆍ 유지 및 삽입 관계에 대해, 타겟 엔드 포인트 필드는 ItemIDReference 타입이어야 하며, 관계 인스턴스와 동일한 저장소 내의 항목을 참조해야 한다. 참조 관계에 대해, 타겟 엔드 포인트는 임의의 ItemReference 타입일 수 있으며, 다른 저장 플랫폼 데이터 저장소 내의 항목을 참조할 수 있다.

ㆍ 선택적으로 스칼라 또는 PropertyBase 타입의 하나 이상의 필드들이 선언 될 수 있다. 이들 필드는 관계와 관련된 데이터를 포함할 수 있다.

ㆍ 관계 인스턴스는 글로벌 관계 테이블에 저장된다.

ㆍ 모든 관계 인스턴스는 조합(소스 ItemID, 관계 ID)에 의해 고유하게 식별된다. 관계 ID는 그들의 타입에 관계 없이 주어진 항목에 소스를 가진 모든 관계에 대해 주어진 소스 ItemID 내에서 고유하다.

소스 항목은 관계의 소유자이다. 소유자로서 지정된 항목이 관계의 수명을 제어하는 반면, 관계 자체는 그가 관계하는 항목으로부터 분리된다. 저장 플랫폼 API(322)는 항목과 관련된 관계를 노출시키기 위한 메커니즘을 제공한다.

다음은 관계 선언의 일례이다:

이것은 참조 관계의 일례이다. 관계는 소스 참조에 의해 참조되는 사람 항목이 존재하지 않는 경우 생성될 수 없다. 또한, 사람 항목이 삭제되면, 사람과 조직 사이의 관계 인스턴스는 삭제된다. 그러나, 조직 항목이 삭제되면, 관계는 삭제되지 않고 공중에 뜬 상태가 된다.

b) 유지 관계

유지 관계는 타겟 항목의 참조 수 기반 수명 관리를 모델링하는 데 사용된다.

항목은 0개 이상의 항목에 대한 관계의 소스 엔드 포인트일 수 있다. 삽입된 항목이 아닌 항목은 하나 이상의 유지 관계의 타겟일 수 있다.

타겟 엔드 포인트 참조 타입은 ItemIDReference이어야 하며, 관계 인스턴스와 동일한 저장소 내의 항목을 참조해야 한다.

유지 관계는 타겟 엔드 포인트의 수명 관리를 이행한다. 유지 관계 인스턴스 및 이것이 목표로 하는 항목의 생성은 최소 동작(atomic operation)이다. 동일 항목을 목표로 하는 추가적인 유지 관계 인스턴스가 생성될 수 있다. 타겟 엔드 포인트로서 주어진 항목을 갖는 최종 유지 관계 인스턴스가 삭제되면, 타겟 항목도 삭제된다.

관계 선언에서 지정되는 엔드 포인트 항목의 타입은 일반적으로 관계의 인스턴스가 생성될 때 강제된다. 엔드 포인트 항목의 타입은 관계가 설정된 후에는 변경될 수 없다.

유지 관계들은 항목 명칭 공간의 형성에 중요한 역할을 한다. 이들은 소스 항목에 대한 타겟 항목의 명칭을 정의하는 "명칭" 속성을 포함한다. 이러한 상대적 명칭은 주어진 항목을 소스로 하는 모든 유지 관계에 대해 고유하다. 루트 항목에서 주어진 항목까지의 상대적 명칭들의 순서화된 리스트는 항목에 대한 완전한 명칭을 형성한다.

유지 관계는 방향 비순환 그래프(DAG)를 형성한다. 유지 관계가 생성될 때, 시스템은 순환이 생성되지 않는 것을 보장함으로써 항목 명칭 공간이 DAG를 형성하는 것을 보장한다.

유지 관계가 타겟 항목의 수명을 제어하는 반면, 타겟 엔드 포인트 항목의 동작 일관성을 제어하지 못한다. 타겟 항목은 유지 관계를 통해 타겟 항목을 소유하는 항목으로부터 동작면에서 독립적이다. 유지 관계의 소스인 항목에 대한 복사, 이동, 백업 및 다른 동작은 동일 관계의 타겟인 항목에 영향을 주지 못하는데, 예를 들면, 즉 폴더 항목의 백업은 폴더 내의 모든 항목(FolderMember 관계의 타겟들)을 자동으로 백업하지 못한다.

다음은 유지 관계의 일례이다.

FolderMember 관계는 일반적인 항목들의 집합으로서의 폴더의 개념을 가능하게 한다.

c) 삽입 관계

삽입 관계는 타겟 항목의 수명의 배타적인 제어의 개념을 모델링한다. 삽입 관계는 복합 항목들의 개념을 가능하게 한다.

삽입 관계 인스턴스 및 이것이 목표로 하는 항목의 생성은 최소 동작이다. 항목은 0개 이상의 삽입 관계의 소스일 수 있다. 그러나, 항목은 하나 및 단 하나의 삽입 관계의 타겟일 수 있다. 삽입 관계의 타겟인 항목은 유지 관계의 타겟이 될 수 없다.

타겟 엔드 포인트 참조 타입은 ItemIDReference이어야 하며, 관계 인스턴스와 동일한 데이터 저장소 내의 항목을 참조해야 한다.

관계 선언에서 지정되는 엔드 포인트 항목의 타입은 일반적으로 관계의 인스턴스가 생성될 때 강제된다. 엔드 포인트 항목의 타입은 관계가 설정된 후에는 변경될 수 없다.

삽입 관계는 타겟 엔드 포인트의 동작 일관성을 제어한다. 예컨대, 항목의 일련화 동작은 그 항목은 물론 그들의 타겟들 모두로부터 나온 모든 삽입 관계의 일련화를 포함할 수 있으며, 항목의 복사는 또한 그의 모든 삽입된 항목을 복사한다.

다음은 선언의 일례이다.

d) 참조 관계

참조 관계는 그것이 참조하는 항목의 수명을 제어하지 않는다. 심지어, 참조 관계는 타겟의 존재를 보장하지 않으며, 관계 선언에서 지정되는 타겟의 타입도 보장하지 않는다. 이것은 참조 관계가 현수 상태일 수 있다는 것을 의미한다. 또한, 참조 관계는 다른 데이터 저장소 내의 항목을 참조할 수 있다. 참조 관계는 웹 페이지 내의 링크와 유사한 개념으로 간주될 수 있다.

다음은 참조 관계 선언의 일례이다.

타겟 엔드 포인트에서 임의의 참조 관계가 허용된다. 참조 관계에 참여하는 항목들은 임의의 항목 타입일 수 있다.

참조 관계는 항목들 사이의 대부분의 비 수명 관리 관계를 모델링하는 데 사용된다. 타겟의 존재가 강제되지 않으므로, 참조 관계는 느슨하게 결합된 관계를 모델링하는 데 편리하다. 참조 관계는 다른 컴퓨터 상의 저장소를 포함하는 다른 데이터 저장소 내의 항목을 타겟으로 하여 사용될 수 있다.

e) 규칙 및 제한

다음의 추가적인 규칙 및 제한은 관계에 적용된다.

ㆍ 항목은 (단 하나의 삽입 관계) 또는 (하나 이상의 유지 관계)의 타겟이어야 한다. 하나의 예외는 루트 항목이다. 항목은 0개 이상의 참조 관계의 타겟일 수 있다.

ㆍ 삽입 관계의 타겟인 항목은 유지 관계의 소스일 수 없다. 이것은 참조 관계의 소스일 수 있다.

ㆍ 항목은 파일로부터 승진된 경우 유지 관계의 소스가 될 수 없다. 이것은 삽입 관계 및 참조 관계의 소스가 될 수 있다.

ㆍ 파일로부터 승진된 항목은 삽입 관계의 타겟이 될 수 없다.

f) 관계들의 순서화

적어도 하나의 실시예에서, 본 발명의 저장 플랫폼은 관계들의 순서화를 지 원한다. 순서화는 기본 관계 정의 내의 "순서(Order)"라는 명칭의 속성을 통해 달성된다. 순서 필드에 대한 고유성 제한은 존재하지 않는다. 동일한 "순서" 속성 값을 가진 관계들의 순서는 보장되지 않으나, 이들이 보다 낮은 "순서" 값을 가진 관계 후에, 그리고 보다 높은 "순서" 필드 값을 가진 관계 전에 순서화될 수 있는 것은 보장된다.

애플리케이션은 조합(SourceItemID, RelationshipID, Order) 상에서의 순서화에 의해 디폴트 순서로 관계를 입수할 수 있다. 주어진 항목으로부터 나온 모든 관계 인스턴스는 집합 내의 관계의 타입에 관계없이 단일 집합으로서 순서화된다. 그러나, 이것은 주어진 타입의 모든 관계(예컨대, FolderMembers)가 주어진 항목에 대한 관계 집합의 순서화된 서브세트임을 보장한다.

관계를 조작하기 위한 데이터 저장소 API(312)는 관계들의 순서화를 지원하는 한 세트의 동작을 구현한다. 다음 용어들은 동작의 설명을 돕기 위해 도입된다.

ㆍ RelFirst는 순서 값 OrdFirst를 가진 순서화된 집합 내의 첫 번째 관계이다.

ㆍ RelLast는 순서 값 OrdLast를 가진 순서화된 집합 내의 최종 관계이다.

ㆍ RelX는 순서 값 OrdX를 가진 집합 내의 소정의 관계이다.

ㆍ RelPrev는 OrdX보다 작은 순서 값 OrdPrev를 가진 집합에서 RelX에 가장 가까운 관계이다.

ㆍ RelNext는 OrdX보다 큰 순서 값 OrdNext를 가진 집합에서 RelX에 가장 가 까운 관계이다.

동작들은 다음을 포함하지만 이에 한하지 않는다.

ㆍ InsertBeforeFirst(SourceItemID, Relationship)는 집합 내의 제1 관계로서 관계를 삽입한다. 새로운 관계의 순서 속성 값은 OrdFirst보다 작을 수 있다.

ㆍ InsertAfterLast(SourceItemID, Relationship)는 집합 내의 최종 관계로서 관계를 삽입한다. 새로운 관계의 순서 속성 값은 OrdLast보다 클 수 있다.

ㆍ InsertAt(SourceItemID, ord, Relationship)는 순서 속성에 대한 지정 값을 가진 관계를 삽입한다.

ㆍ InsertBefore(SourceItemID, ord, Relationship)는 주어진 순서 값을 가진 관계 앞에 관계를 삽입한다. 새로운 관계는 OrdPrev와 ord 사이(이들 값은 포함하지 않음)의 순서 값이 할당될 수 있다.

ㆍ InsertAfter(SourceItemID, ord, Relationship)는 주어진 순서 값을 가진 관계 뒤에 관계를 삽입한다. 새로운 관계는 ord와 OrdNext 사이(이들 값은 포함되지 않음)의 순서 값이 할당될 수 있다.

ㆍ MoveBefore(SourceItemID, ord, Relationship)는 주어진 관계 ID를 가진 관계를 지정된 순서 값을 가진 관계 앞으로 이동시킨다. 관계는 OrdPrev와 ord 사이(이들 값은 포함되지 않음)의 새로운 순서 값이 할당될 수 있다.

ㆍ MoveAfter(SourceItemID, ord, Relationship)는 주어진 관계 ID를 가진 관계를 지정된 순서 값을 가진 관계 뒤로 이동시킨다. 관계는 ord와 OrdNext 사이(이들 값은 포함되지 않음)의 새로운 순서 값이 할당될 수 있다.

전술한 바와 같이, 모든 항목은 항목 폴더의 멤버여야 한다. 관계에 의하여, 모든 항목은 항목 폴더와의 관계를 가져야 한다. 본 발명의 여러 실시예에서, 소정의 관계들은 항목들 사이에 존재하는 관계에 의해 표현된다.

본 발명의 다양한 실시예에서 구현되는 바와 같이, 관계는 하나의 항목(소스)에 의해 다른 항목(타겟)으로 확장되는 방향성 바이너리 관계를 제공한다. 관계는 소스 항목(관계를 확장한 항목)에 의해 소유되며, 따라서 소스가 제거되는 경우에는 관계가 제거된다(예컨대, 관계는 소스 항목이 삭제될 때 삭제된다). 더욱이, 소정의 예에서, 관계는 타겟 항목의 소유를 공유(공동 소유)할 수 있으며, 이러한 소유는 (관계 속성 타입에 대해 도 7에 도시된 바와 같이) 관계의 IsOwned 속성(또는 그의 등가물) 내에 반영될 수 있다. 이들 실시예에서, 새로운 IsOwned 관계의 생성은 타겟 항목에 대한 참조 수를 자동으로 증가시키며, 이러한 관계의 삭제는 타겟 항목에 대한 참조 수를 감소시킬 수 있다. 이러한 특정 실시예에서, 항목들은 이들이 0보다 큰 참조 수를 갖는 경우 계속 존재하며, 참조 수가 0이 되는 경우 자동으로 삭제된다. 또한, 항목 폴더는 다른 항목들에 대해 한 세트의 관계를 갖는(또는 가질 수 있는) 항목인데, 이들 다른 항목들은 항목 폴더의 멤버을 포함한다. 다른 실제적인 관계의 구현도 가능하며, 여기서 설명되는 기능을 달성하도록 본 발명에 의해 예측된다.

실제 구현과 관계없이, 관계는 하나의 객체에서 다른 객체로의 선택 가능한 연결이다. 하나의 항목이 둘 이상의 항목 폴더는 물론, 하나 이상의 카테고리에 속할 수 있는 능력, 및 이들 항목, 폴더 및 카테고리가 공개적인지 사적인지의 여 부는 항목 기반 구조에서의 존재(또는 부재)에 대해 주어지는 의미에 의해 결정된다. 이러한 논리 관계는 물리적 구현에 관계없이 본 명세서에서 설명되는 기능을 달성하기 위해 구체적으로 사용되는 한 세트의 관계에 할당되는 의미들이다. 논리 관계는 항목과 그의 항목 폴더(들) 또는 카테고리들(및 그 역) 사이에 설정되는데, 이는 본질적으로 항목 폴더 및 카테고리가 각각 항목의 특수한 타입이기 때문이다. 결과적으로, 항목 폴더 및 카테고리는 복사되고, 이메일 메시지에 추가되고, 문서에 삽입되는 등등 제한 없이, 임의의 다른 항목과 동일한 방식으로 동작될 수 있으며, 항목 폴더 및 카테고리는 다른 항목에 대한 것과 동일한 메커니즘을 이용하여 일련화 및 비일련화(가져오기 및 가져가기)될 수 있다. (예를 들어, XML에서 모든 항목은 일련화 포맷을 가질 수 있으며, 이러한 포맷은 항목 폴더, 카테고리 및 항목에 동일하게 적용된다.)

항목과 그의 항목 폴더 사이의 관계를 나타내는 전술한 관계는 논리적으로 항목에서 항목 폴더로, 항목 폴더에서 항목으로, 또는 양쪽으로 확장될 수 있다. 항목에서 항목 폴더로 확장되는 관계는 항목 폴더가 항목에 대해 공개적이며 항목과 그의 멤버 정보를 공유한다는 것을 나타내지만, 역으로 항목에서 항목 폴더로의 논리 관계의 결여는 항목 폴더가 항목에 대해 사적이며, 항목과 그의 멤버 정보를 공유하지 않는다는 것을 나타낸다. 유사하게, 항목 폴더에서 항목으로 논리적으로 확장되는 관계는 항목이 공개적이며 항목 폴더와 공유될 수 있다는 것을 나타내는 반면, 항목 폴더에서 항목으로의 논리 관계의 결여는 항목이 사적이고, 공유될 수 없다는 것을 나타낸다. 결과적으로, 항목 폴더가 다른 시스템에 노출될 때, 이것 은 이 새로운 상황에서 공유되는 "공개" 항목이며, 항목이 그의 항목 폴더에서 다른 공유 가능한 항목들을 검색할 때, 이것은 항목에 이에 속하는 공유 가능한 항목들에 관한 정보를 제공하는 "공개" 항목 폴더들이다.

도 9는 항목 폴더(이것은 또한 항목 그 자체이다), 그의 멤버 항목들, 및 항목 폴더와 그의 멤버 항목들 사이의 상호 연결 관계를 나타내는 블록도이다. 항목 폴더(900)는 다수의 항목(902, 904, 906)을 갖는다. 항목 폴더(900)는 그 자신으로부터 항목(902)으로의 관계(912)를 갖는데, 이 관계는 항목(902)이 공개적이며 항목 폴더(900), 그의 멤버들(904, 906), 및 항목 폴더(900)에 액세스할 수 있는 임의의 다른 항목 폴더들, 카테고리들, 또는 항목들(도시되지 않음)과 공유될 수 있다는 것을 나타낸다. 그러나, 항목 폴더(900)가 항목(902)에 대해 사적이며, 항목(902)과 그의 멤버 정보를 공유하지 않는다는 것을 나타내는 항목(902)에서 항목 폴더(900)로의 관계는 존재하지 않는다. 한편, 항목(904)은, 항목 폴더(900)가 공개적이며 항목(904)과 그의 멤버 정보를 공유한다는 것을 나타내는 그 자신에서 항목 폴더(900)로의 관계를 갖지 않는다. 그러나, 항목(904)이 사적이며 항목 폴더(900), 그의 다른 멤버들(902, 906), 및 항목 폴더(900에 액세스할 수 있는 항목 폴더, 카테고리 또는 항목(도시되지 않음)과 공유되지 않음을 나타내는 항목 폴더(900)에서 항목(904)으로의 관계가 존재하지 않는다. 항목 폴더의 항목들(902, 904)에 대한 관계(또는 관계의 결여)와 달리, 항목 폴더(900)는 그 자신에서 항목(906)으로의 관계(916)를 가지며, 항목(906)은 역으로 항목 폴더(900)로의 관계(926)을 갖는데, 이들 관계는 함께 항목(906)이 공개적이며 항목 폴더(900), 그의 멤버들(902, 904), 및 항목 폴더(900)에 액세스할 수 있는 임의의 다른 항목 폴더, 카테고리 또는 항목(도시되지 않음)과 공유될 수 있고, 항목 폴더(900)이 공개적이고 항목(906)과 그의 멤버 정보를 공유한다는 것은 나타낸다.

전술한 바와 같이, 항목 폴더 내의 항목들은 공유성을 공유할 필요는 없는데, 이는 항목 폴더가 "기술"되지 않기 때문이다. 한편, 카테고리는 그의 멤버 항목들 모두에 공통인 공통성에 의해 기술된다. 결과적으로, 카테고리의 멤버는 기술된 공통성을 가진 항목들로 고유하게 제한되며, 소정 실시예에서 카테고리의 기술을 만족시키는 모든 항목은 자동으로 카테고리의 멤버가 된다. 따라서, 항목 폴더는 평범한 타입의 구조들이 그들의 멤버에 의해 표현되는 것을 허용하는 반면, 카테고리는 정의된 공통성에 기초하여 멤버을 허용한다.

물론, 카테고리 기술은 사실상 논리적이며, 따라서 카테고리는 타입들, 속성들 및/또는 값들의 임의의 논리적 표현에 의해 기술될 수 있다. 예컨대, 카테고리의 논리적 표현은 2개의 속성 중 하나 또는 양자를 갖는 항목들을 포함하는 그의 멤버일 수 있다. 카테고리에 대해 기술된 이러한 속성들이 "A" 및 "B"인 경우, 카테고리 멤버는 속성 A를 가지나 B는 갖지 않는 항목들, 속성 A는 갖지 않고 B를 갖는 항목들, 및 속성 A 및 B를 모두 갖는 항목들을 포함할 수 있다. 이러한 속성들의 논리적 표현은 논리 연산자 "OR"에 의해 기술되는데, 카테고리에 의해 기술되는 멤버들의 세트는 속성 A OR B를 가진 항목들이다. 유사한 논리 연산자(제한 없이 "AND", "XOR" 및 "NOT"를 단독으로 또는 조합으로 포함)도 당업자가 이해하듯이 카테고리를 기술하는 데 사용될 수 있다.

항목 폴더(기술되지 않음)와 카테고리(기술됨) 사이의 차이에도 불구하고, 항목에 대한 카테고리의 관계 및 카테고리에 대한 항목의 관계는 본질적으로 본 발명의 많은 실시예에서 항목 폴더 및 항목에 대해 위에 개시한 것과 동일한 방식을 갖는다.

도 10은 카테고리(항목 자체), 그의 멤버 항목들, 및 카테고리와 그의 멤버 항목들 사이의 상호 연결 관계를 나타내는 블록도이다. 카테고리(1000)는 다수의 항목(1002, 1004, 1006)을 멤버으로서 갖는데, 이들 모두는 카테고리(1000)에 의해 기술되는 바와 같이 공통 속성들, 값들 또는 타입들(1008)의 소정의 조합을 공유한다. 카테고리(1000)는 그 자체에서 항목(1002)으로의 관계(1012)를 갖는데, 이 관계는 항목(1002)이 공개적이며, 카테고리(1000), 그의 멤버들(1004, 1006), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 있다는 것을 나타낸다. 그러나, 카테고리(1000)가 항목(1002)에 대해 사적이며, 항목(1002)과 그의 멤버 정보를 공유하지 않는다는 것을 나타내는, 항목(1002)에서 카테고리(1000)로의 관계는 존재하지 않는다. 한편, 항목(1004)은 카테고리(1000)가 공개적이며, 항목(1004)과 그의 멤버 정보를 공유한다는 것을 나타내는, 그 자체에서 카테고리(1000)로의 관계(1024)를 갖지 않는다. 그러나, 항목(1004)이 사적이며, 카테고리(1000), 그의 다른 멤버들(1002, 1006), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 없다는 것은 나타내는 카테고리(1000)에서 항목(1004)으로 확장되는 관계가 존재하지 않는다. 카테고리의 항목(1002, 1004)과의 관계(또는 그의 결여)와 달리, 카테고리(1000)는 그 자체에서 항목(1006)으로의 관계를 가지며, 항목(1006)은 역으로 카테고리(1000)로의 관계를 갖는데, 이들 관계는 함께 항목(1006)이 공개적이며 카테고리(1000), 그의 항목 멤버들(1002, 1004), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 있다는 것과, 카테고리(1000)가 공개적이며, 항목(1006)과 그의 멤버 정보를 공유한다는 것을 나타낸다.

마지막으로, 카테고리 및 항목 폴더들 자체는 항목이기 때문에, 소정의 다른 실시예에서 항목들은 서로에 대한 관계를 가질 수 있고, 카테고리는 항목 폴더에 대한 관계를, 항목 폴더는 카테고리에 대한 관계를 가질 수 있으며, 카테고리, 항목 폴더 및 항목은 다른 카테고리, 항목 폴더 및 항목에 대한 관계를 가질 수 있다. 그러나, 다양한 실시예에서, 항목 폴더 구조 및/또는 카테고리 구조는 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 순환을 포함하는 것이 금지된다. 항목 폴더 및 카테고리 구조가 방향 그래프와 유사한 경우, 순환을 금지하는 실시예들은 그래프 이론 분야의 수학적 정의에 의해 동일한 정점에서 어떠한 경로도 시작하거나 끝나지 않는 방향 그래프인 방향 비순환 그래프(DAG)와 유사하다.

6. 확장성

저장 플랫폼은 전술한 바와 같이 초기 스키마 세트(340)를 구비한다. 또한, 그러나 적어도 일부 실시예에서 저장 플랫폼은 개별 소프트웨어 벤더(ISV)를 포함하는 고객들이 새로운 스키마(344)(즉, 새로운 항목 및 중첩 요소 타입)를 생성하 는 것을 허용한다. 이 섹션은 초기 스키마 세트(340)에 정의된 항목 타입 및 중첩 요소 타입(또는 단순히 요소 타입)을 확장함으로써 이러한 스키마를 생성하는 메커니즘을 다룬다.

바람직하게도, 초기의 항목 및 중첩 요소 타입 세트는 다음과 같이 제한된다.

ㆍ ISV는 새로운 항목 타입, 즉 서브 타입인 Base.Item을 도입하는 것이 허용된다.

ㆍ ISV는 새로운 중첩 요소 타입, 즉 서브 타입인 Base.NestedElement를 도입하는 것이 허용된다.

ㆍ ISV는 새로운 확장, 즉 서브 타입인 Base.NestedElement를 도입하는 것이 허용된다.

ㆍ 그러나, ISV는 저장 플랫폼 스키마의 초기 세트(340)에 의해 정의된 임의의 타입(항목, 중첩 요소 또는 확장 타입)을 서브 타입화할 수 없다.

저장 플랫폼 스키마의 초기 세트에 정의된 항목 타입 또는 중첩 요소 타입은 ISV 애플리케이션의 요구에 정확하게 부응하지 않을 수 있기 때문에, ISV가 타입을 주문화하는 것을 허용할 필요가 있다. 이것은 확장의 개념으로 허용된다. 확장은 강력하게 타입화된 확장이지만, (a) 이것은 독립적으로 존재할 수 없고, (b) 항목 또는 중첩 요소에 첨부되어야 한다.

스키마 확장성의 필요성을 다루는 것 외에, 확장은 또한 "멀티 타입화" 문제를 다룬다. 소정의 실시예에서, 저장 플랫폼은 다수의 상속 또는 중첩 서브 타입 을 지원하지 않을 수 있기 때문에, 애플리케이션은 확장을 중첩 타입 인스턴스를 모델링하기 위한 방법으로서 이용할 수 있다(예컨대, 문서는 합법 문서는 물론 보안 문서이다).

a) 항목 확장

항목 확장성을 제공하기 위하여, 데이터 모델은 또한 Base. Extension이라는 명칭의 추상 타입을 정의한다. 이것은 확장 타입의 계층 구조에 대한 루트 타입이다. 애플리케이션은 특정 확장 타입을 생성하기 위해 Base.Extension을 서브 타입화할 수 있다.

Base.Extension 타입은 다음과 같이 Base.Extension 내에 정의된다.

ItemID 필드는 확장이 연관되어 있는 항목의 ItemID를 포함한다. 이 ItemID를 가진 항목이 존재해야 한다. 확장은 소정의 ItemID를 가진 항목이 존재하지 않는 경우 생성될 수 없다. 항목이 삭제되면, 동일한 ItemID를 가진 모든 확장이 삭제된다. 튜플(ItemID, ExtensionID)은 확장 인스턴스를 고유하게 식별한다.

확장 타입의 구조는 항목 타입의 구조와 유사하다.

ㆍ 확장 타입은 필드를 갖는다.

ㆍ 필드는 기본 또는 중첩 요소 타입일 수 있다.

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

다른 제한은 확장 타입에 적용된다.

ㆍ 확장은 관계의 소스 및 타겟일 수 없다.

ㆍ 확장 타입 인스턴스는 항목과 별개로 존재할 수 없다.

ㆍ 확장 타입은 저장 플랫폼 타입 정의에서 필드 타입으로 사용될 수 없다.

주어진 항목 타입과 관련될 수 있는 확장의 타입에는 제한이 없다. 어떠한 확장 타입도 임의의 항목 타입을 확장하는 것이 허용된다. 다수의 확장 인스턴스가 항목에 첨부될 때, 이들은 구조 및 거동 양자에서 서로 독립적이다.

확장 인스턴스는 저장되어 항목으로부터 개별적으로 액세스된다. 모든 확장 타입 인스턴스는 글로벌 확장 뷰로부터 액세스될 수 있다. 어떤 타입의 항목과 연관되어 있는지에 관계없이 소정 확장 타입의 모든 인스턴스를 리턴하는 효율적인 질의가 구축될 수 있다. 저장 플랫폼 API는 항목에 대한 확장을 저장, 검색 및 수정할 수 있는 프로그래밍 모델을 제공한다.

확장 타입은 저장 플랫폼 단일 상속 모델을 이용하여 서브 타입화된 타입일 수 있다. 확장 타입으로부터의 도출은 새로운 확장 타입을 생성한다. 확장의 구조 또는 거동은 항목 타입 계층 구조의 구조 또는 거동을 무시하거나 대체할 수 없다. 항목 타입과 유사하게, 확장 타입 인스턴스는 확장 타입과 관련된 뷰를 통해 직접 액세스될 수 있다. 확장의 ItemID는 이들이 어느 항목에 속하는지를 나타내며, 글로벌 항목 뷰로부터 대응하는 항목 객체를 검색하는 데 사용될 수 있다. 확장은 동작의 일관성을 위해 항목의 일부로 간주된다. 저장 플랫폼이 정의하는 복사/이동, 백업/복원 및 다른 일반 동작들은 항목의 일부로서 확장에 대해 동작할 수 있다.

다음 예를 고려하자. 윈도우 타입 세트 내에 연락 타입이 정의된다.

CRM 애플리케이션 개발자는 저장 플랫폼에 저장된 연락에 CRM 애플리케이션 확장을 첨부하기를 원한다. 애플리케이션 개발자는 애플리케이션이 조작할 수 있는 추가적인 데이터 구조를 포함하는 CRM 확장을 정의한다.

HR 애플리케이션 개발자는 또한 연락에 추가 데이터를 첨부하기를 원할 수 있다. 이 데이터는 CRM 애플리케이션 데이터와 무관하다. 또한, 애플리케이션 개발자는 확장을 생성할 수 있다.

CRMExtension 및 HRExtension은 연락 항목에 첨부될 수 있는 2개의 독립적인 확장이다. 이들은 서로 독립적으로 생성되고 액세스된다.

위의 예에서, CRMExtension 타입의 필드 및 메소드는 연락 계층 구조의 필드 또는 메소드를 무시할 수 없다. CRMExtension 타입의 인스턴스는 연락이 아니라 항목 타입에 첨부될 수 있다는 점에 유의해야 한다.

연락이 검색될 때, 그의 항목 확장이 자동으로 검색되는 것은 아니다. 연락 항목이 주어지면, 그와 관련된 항목 확장은 동일한 ItemID를 가진 확장에 대한 글로벌 확장 뷰에 질의함으로써 액세스될 수 있다.

시스템 내의 모든 CRMExtension 확장들은 이들이 어느 항목에 속하는지에 관계없이 CRMExtension 타입 뷰를 통해 액세스될 수 있다. 항목의 모든 항목 확장은 동일한 항목 ID를 공유한다. 위 예에서, 연락 항목 인스턴스 및 첨부된 CRMExtension 및 HRExtension 인스턴스는 동일한 ItemID를 공유한다.

다음 테이블은 항목, 확장 및 중첩 요소 타입 사이의 유사성 및 차이를 요약 한 것이다.

항목 대 항목 확장 대 중첩 요소

	항목	항목 확장	중첩 요소
항목 ID	그 자신의 항목 ID를 갖는다.	항목의 항목 ID를 공유한다.	그 자신의 항목 ID를 갖지 않는다. 중첩 요소는 항목의 일부이다.
저장	항목 계층 구조는 그 자신의 테이블에 저장된다.	항목 확장 계층 구조는 그 자신의 테이블에 저장된다.	항목과 함께 저장된다.
질의/검색	항목 테이블에 질의할 수 있다.	항목 확장 테이블에 질의할 수 있다.	일반적으로 포함하는 항목 컨텍스트 내에서만 질의될 수 있다.
질의/검색 범위	항목 타입의 모든 인스턴스를 검색할 수 있다.	항목 확장 타입의 모든 인스턴스를 검색할 수 있다.	일반적으로 단일 (포함) 항목의 중첩 요소 타입 인스턴스 내에서만 검색할 수 있다.
관계 시맨틱	항목들에 대한 관계를 가질 수 있다.	항목 확장에 대한 관계 없음.	중첩 요소에 대한 관계 없음
항목에 대한 연관성	유지, 삽입 및 소프트 관계를 통해 다른 항목과 관련될 수 있다.	일반적으로 확장을 통해서만 관련될 수 있다. 확장 시맨틱은 삽입된 항목 시맨틱과 유사하다.	필드를 통해 항목과 관련됨, 중첩 요소는 항목의 일부이다.

b) 중첩 요소 확장

중첩 요소 타입은 항목 타입과 동일한 메커니즘으로 확장되지 않는다. 중첩 요소의 확장은 중첩 요소 타입의 필드와 동일한 메커니즘으로 저장되고 액세스된다.

데이터 모델은 Element라는 명칭의 중첩 요소 타입의 루트를 정의한다.

중첩 요소 타입은 이 타입으로부터 상속된다. NestElement 요소 타입은 요소들의 멀티 세트인 필드를 추가적으로 정의한다.

중첩 요소 확장은 다음의 방식에서 항목 확장과 다르다.

ㆍ 중첩 요소 확장은 확장 타입이 아니다. 이것은 Base.Extension 타입에서 루트가 되는 확장 타입 계층 구조에 속하지 않는다.

ㆍ 중첩 요소 확장은 항목의 다른 필드들과 함께 저장되며, 글로벌 액세스가 가능하지 않으며, 주어진 확장 타입의 모든 인스턴스를 검색하는 질의가 구축될 수 없다.

ㆍ 이들 확장은 (항목의) 다른 중첩 요소들이 저장되는 것과 동일한 방식으로 저장된다. 다른 중첩 세트와 같이, 중첩 요소 확장은 UDT에 저장된다. 이들은 중첩 요소 타입의 확장 필드를 통해 액세스될 수 있다.

ㆍ 다가 속성들에 액세스하는 데 사용되는 집합 인터페이스도 타입 확장 세트에 대한 액세스 및 반복을 위해 사용된다.

다음 테이블은 항목 확장 및 중첩 요소 확장을 요약하고 비교한 것이다.

항목 확장 대 중첩 요소 확장

	항목 확장	중첩 요소 확장
저장	항목 확장 계층 구조가 그 자신의 테이블에 저장된다.	중첩 요소와 같이 저장된다.
질의/검색	항목 확장 테이블에 질의할 수 있다.	일반적으로 포함 항목 컨텍스트 내에서만 질의될 수 있다.
질의/검색 범위	항목 확장 타입의 모든 인스턴스를 검색할 수 있다.	일반적으로 단일 (포함) 항목의 중첩 요소 타입 인스턴스 내에서만 검색할 수 있다.
프로그래밍 가능성	특수 확장 API 및 확장 테이블에 대한 특수 질의가 필요하다.	중첩 요소 확장은 중첩 요소의 임의의 다른 다가 필드와 유사하며, 정상 중첩 요소 타입 API가 사용된다.
거동	거동을 연관시킬 수 있다.	거동이 허용되지 않음(?)
관계 시맨틱	항목 확장에 대한 관계 없음	중첩 요소 확장에 대한 관계 없음
항목 ID	항목의 항목 ID를 공유한다.	그 자신의 항목 ID를 갖지 않는다. 중첩 요소 확장은 항목의 일부이다.

D. 데이터베이스 엔진

전술한 바와 같이, 데이터 저장소는 데이터베이스 엔진 상에서 구현된다. 본 실시예에서, 데이터베이스 엔진은 객체 관계 확장으로 마이크로소프트 SQL 서버 엔진과 같은 SQL 질의 언어를 구현하는 관계형 데이터베이스 엔진을 포함한다. 이 섹션은 본 실시예에 따라 데이터 저장소를 구현하는 데이터 모델의 관계 저장소에 대한 매핑을 설명하며, 저장 플랫폼 클라이언트에 의해 소비되는 논리 API에 대한 정보를 제공한다. 그러나, 상이한 데이터베이스 엔진이 사용될 때 상이한 매핑이 사용될수 있다는 것을 이해해야 한다. 실제로, 관계형 데이터베이스 엔진 상에서 저장 플랫폼 개념 데이터 모델을 구현하는 것 외에, 예를 들어 객체 지향 및 XML 데이터베이스와 같은 다른 타입의 데이터베이스 상에서도 구현될 수 있다.

객체 지향(OO) 데이터베이스 시스템은 프로그래밍 언어 객체(예컨대, C++, 자바)에 대한 지속성 및 트랜잭션을 제공한다. "항목"의 저장 플랫폼 개념은 삽입된 집합들이 객체에 추가되어야 하지만 객체 지향 시스템에서 "객체"로 양호하게 매핑된다. 상속 및 중첩 요소 타입과 같은 다른 저장 플랫폼 타입 개념들도 객체 지향 타입 시스템에 매핑된다. 객체 지향 시스템은 일반적으로 객체 식별자를 이미 지원하며, 따라서 항목 식별자는 객체 식별자로 매핑될 수 있다. 항목 거동(동작)은 객체 메소드로 양호하게 매핑된다. 그러나, 객체 지향 시스템은 일반적으로 체계적인 능력이 부족하며, 검색이 열악하다. 또한, 객체 지향 시스템은 비구조적 및 반구조적 데이터에 대한 지원을 제공하지 않는다. 여기에 설명되는 완전한 저장 플랫폼 데이터 모델을 지원하기 위하여, 관계, 폴더 및 확장과 같은 개념들이 객체 데이터 모델에 추가될 필요가 있다. 또한, 승진, 동기화, 통지 및 보안과 같은 메커니즘이 구현될 필요가 있다.

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

다음의 서브 섹션과 관련하여, 개시된 일반 정보를 쉽게 하는 몇몇 설명이 제공되는데, 도 13은 통지 메커니즘을 설명하는 도면이다. 도 14는 2개의 트랜잭션 양자가 동일한 B 트리에 새로운 레코드를 삽입하는 예를 나타내는 도면이다. 도 15는 데이터 변경 검출 프로세스를 나타낸다. 도 16은 예시적인 디렉토리 트리를 나타낸다. 도 17은 디렉토리 기반 파일 시스템의 기존 폴더가 저장 플랫폼 데이터 저장소로 이동되는 예를 나타낸다.

1. UDT를 이용한 데이터 저장소 구현

본 실시예에서, 일 실시예에서 마이크로소프트 SQL 서버 엔진을 포함하는 관계형 데이터베이스 엔진(314)은 내장 스칼라 타입을 지원한다. 내장 스칼라 타입은 "원시적"이고 "단순"하다. 이것은 사용자가 그 자신의 타입을 정의할 수 없다는 의미에서 원시적이며, 복합 구조를 캡슐화할 수 없다는 의미에서 단순하다. 사용자 정의 타입(이하, UDT)은 사용자가 복잡하고 구조화된 타입을 정의함으로써 타입 시스템을 확장하는 것을 가능하게 함으로써 원시 스칼라 타입 시스템 위에 그리고 이를 넘어서 타입 확장성을 위한 메커니즘을 제공한다. UDT가 사용자에 의해 정의되면, 이 UDT는 내장 스칼라 타입이 사용될 수 있는 타입 시스템 내의 어디에서나 사용될 수 있다.

본 발명의 일 양태에 따르면, 저장 플랫폼 스키마는 데이터베이스 엔진 저장소 내의 UDT 클래스로 매핑된다. 데이터 저장소 항목들은 Base.Item 타입으로부터 도출되는 UDT 클래스로 매핑된다. 항목과 같이, 확장도 UDT 클래스로 매핑되며, 상속을 이용한다. 루트 확장 타입은 모든 확장 타입이 도출되는 Base.Extension이다.

UDT는 CLR 클래스이며, 이는 상태(즉, 데이터 필드) 및 거동(즉, 루틴)을 갖는다. UDT는 관리형 언어들, 즉 C#, VB.NET 등 중 어느 하나를 이용하여 정의된다. UDT 메소드 및 연산자는 그 타입의 인스턴스에 대해 T-SQL에서 호출될 수 있다. UDT는 행 내의 열의 타입, T-SQL 내의 루틴의 파라미터의 타입 또는 T-SQL 내의 변수의 타입일 수 있다.

저장 플랫폼 스키마의 UDT 클래스로의 매핑은 고레벨에서 매우 간단하다. 일반적으로, 저장 플랫폼 스키마는 CLR 명칭 공간으로 매핑된다. 저장 플랫폼 타입은 CLR 클래스로 매핑된다. CLR 클래스 상속은 저장 플랫폼 타입 상속을 미러링하며, 저장 플랫폼 속성은 CLR 클래스 속성으로 매핑된다.

2. 항목 매핑

항목들이 바람직하게 글로벌 검색 가능하고, 본 실시예의 관계형 데이터베이스에서 상속 및 타입 대체성이 지원되는 경우, 데이터베이스 저장소 내의 항목 저장을 위하여 가능한 하나의 구현은 타입 Base.Item의 열을 가진 단일 테이블에 모든 항목을 저장하는 것이다. 타입 대체성을 이용하면, 모든 타입의 항목들이 저장 될 수 있으며, 검색은 유콘(Yukon)의 "is of(타입)" 연산자를 이용하여 항목 타입 및 서브 타입에 의해 필터링될 수 있다.

그러나, 이러한 접근법과 관련된 오버헤드에 대한 염려로 인해, 본 실시예에서는 항목들이 최상위 레벨 타입에 의해 분류되며, 따라서 각 타입 "패밀리"의 항목들은 개별 테이블에 저장된다. 이러한 분할 스킴 하에서는 Base.Item으로부터 직접 상속되는 각각의 항목 타입에 대해 테이블이 생성된다. 이들 아래에서 상속되는 타입들은 전술한 바와 같이 타입 대체성을 이용하여 적절한 타입 패밀리에 저장된다. Base.Item으로부터의 제1 레벨의 상속만이 특수하게 처리된다.

모든 항목에 대한 글로벌 검색 가능 속성들의 사본을 저장하기 위하여 "쉐도우" 테이블이 사용된다. 이 테이블은 모든 데이터 변경을 행하는 저장 플랫폼 API의 Update() 메소드에 의해 유지될 수 있다. 타입 패밀리 테이블과 달리, 이 글로벌 항목 테이블은 완전한 UDT 항목 객체가 아니라 항목의 최상위 레벨 스칼라 속성만을 포함한다. 글로벌 항목 테이블은 ItemID 및 TypeID를 노출시킴으로써 타입 패밀리 테이블에 저장된 항목 객체에 대한 네비게이션을 허용한다. ItemID는 일반적으로 데이터 저장소 내의 항목을 고유하게 식별한다. TypeID는 여기서 설명되지 않는 메타데이터를 이용하여 타입 명칭 및 항목을 포함하는 뷰로 매핑될 수 있다. 글로벌 항목 테이블과 관련하여, 그리고 다른 상황과 관련하여, 항목을 그의 ItemID에 의해 찾는 것은 일반적인 동작일 수 있으므로, 항목의 ItemID가 주어지면 항목 객체를 검색하기 위한 GetItem() 함수가 제공된다.

편리한 액세스를 위해, 그리고 구현 상세를 가능한 한도까지 숨기기 위해, 항목에 대한 모든 질의는 전술한 항목 테이블 상에 구축된 뷰들에 대한 것일 수 있다. 구체적으로, 적절한 타입 패밀리 테이블에 대해 각각의 항목 타입에 대한 뷰들이 생성될 수 있다. 이러한 타입 뷰는 서브 타입을 포함하는 관련 타입의 모든 항목을 선택할 수 있다. 편의를 위해, UDT 객체 외에, 뷰들은 상속된 필드를 포함하는 그 타입의 모든 최상위 레벨 필드에 대한 열들을 노출시킬 수 있다.

3. 확장 매핑

확장은 항목과 매우 유사하며, 동일한 요건들의 일부를 갖는다. 상속을 지원하는 다른 루트 타입으로서, 확장은 저장에 있어서의 동일한 고려 및 트레이드오프 중 많은 부분에 종속된다. 이 때문에, 유사한 타입 패밀리 매핑이 단일 테이블 접근법이 아니라 확장에 적용된다. 물론, 다른 실시예에서는 단일 테이블 접근법이 이용될 수 있다. 본 실시예에서, 확장은 ItemID에 의해 정확히 하나의 항목과 연관되며, 항목과 관련하여 고유한 ExtensionID를 포함한다. 항목에서와 같이, ItemID 및 ExtensionID 쌍으로 이루어진 확장 식별자가 주어질 때 확장을 검색하기 위한 함수가 제공될 수 있다. 항목 타입 뷰와 유사하게 각각의 확장 타입에 대한 뷰가 생성된다.

4. 중첩 요소 매핑

중첩 요소들은 항목, 확장, 관계, 또는 깊게 중첩된 구조를 형성하는 다른 중첩 요소들 내에 삽입될 수 있는 타입이다. 항목 및 확장과 같이, 중첩 요소는 UDT로서 구현되지만, 항목 및 확장 내에 저장된다. 따라서, 중첩 요소들은 그들의 항목 및 확장 컨테이너의 매핑을 넘어서는 어떠한 저장 매핑도 갖지 않는다. 즉, 시스템 내에는 중첩 요소 타입의 인스턴스를 직접 저장하는 테이블이 존재하지 않으며, 중첩 요소에 특정하게 전용화된 어떠한 뷰도 존재하지 않는다.

5. 객체 식별

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

6. SQL 객체 명명

데이터 저장소에서 생성된 모든 객체는 저장 플랫폼 스키마 명칭으로부터 도출된 SQL 스키마 명칭에 저장될 수 있다. 예컨대, 저장 플랫폼 기본 스키마(종종 "Base"라고 함)는 "[System.Storage]" SQL 스키마 내에 "[System.Storage].Item"과 같은 타입을 생성할 수 있다. 생성된 명칭 앞에는 명명 충돌을 없애기 위하여 한정사가 붙는다. 적절한 경우, 명칭의 각각의 논리 부분에 대한 분리자로서 느낌표(!)가 사용된다. 아래의 테이블은 데이터 저장소 내의 객체들에 대해 사용되는 명명 규약의 개요를 나타낸다. 각각의 스키마 요소(항목, 확장, 관계 및 뷰)는 데이 터 저장소 내의 인스턴스에 액세스하는 데 사용되는 장식 명명 규약과 함께 리스트되어 있다.

객체	명칭 장식	설명	예
마스터 항목 검색 뷰	Master!Item	현재 항목 도메인 내의 항목들의 요약을 제공한다.	[System.Storage]. [Master!Item]
타입화된 항목 검색 뷰	ItemType	항목 및 임의의 부모 타입(들)으로부터의 모든 속성 데이터를 제공한다.	[AcmeCorp.Doc]. [OfficeDoc]
마스터 확장 검색 뷰	Master!Extension	현재 항목 도메인 내의 모든 확장의 요약을 제공한다.	[System.Storage]. [Master!Extension]
타입화된 확장 검색 뷰	Extension!extensionType	확장에 대한 모든 속성 데이터를 제공한다.	[AcmeCorp.Doc]. [Extension!StickyNote]
마스터 관계 뷰	Master!Relationship	현재 항목 도메인 내의 모든 관계의 요약을 제공한다.	[System.Storage]. [Master!Relationship]
관계 뷰	Relation!relationshipName	주어진 관계와 관련된 모든 데이터를 제공한다.	[AcmeCorp.Doc]. [Relationship!AuthorsFromDocument]
뷰	View!viewName	스키마 뷰 정의에 기초하여 열/타입을 제공한다.	[AcmeCorp.Doc]. [View!DocumentTitles]

7. 열 명명

임의의 객체 모델을 저장소로 매핑할 때, 명명 충돌의 가능성은 애플리케이션 객체와 함께 저장된 추가 정보로 인해 발생한다. 명명 충돌을 방지하기 위해, 모든 논-타입 특정 열(타입 선언 내의 명명 속성으로 직접 매핑되지 않는 열들) 앞에는 밑줄(_) 문자가 붙여진다. 본 실시예에서, 밑줄(_) 문자는 임의의 식별자 속성의 시작 문자로서 허용되지 않는다. 또한, CLR과 데이터 저장소 사이의 명명을 통일하기 위하여 저장 플랫폼 타입 또는 스키마 요소(관계 등)의 모든 속성은 대문자화된 제1 문자를 가져야 한다.

8. 검색 뷰

뷰는 저장된 콘텐츠를 검색하기 위해 저장 플랫폼에 의해 제공된다. SQL 뷰가 각각의 항목 및 확장 타입에 대해 제공된다. 또한, 관계 및 뷰를 지원하기 위해(데이터 모델에 정의된 바와 같이) 뷰들이 제공된다. 저장 플랫폼 내의 모든 SQL 뷰 및 기본 테이블은 판독 전용이다. 후술하는 바와 같이, 데이터는 저장 플랫폼 API의 Update() 메소드를 이용하여 저장 또는 변경될 수 있다.

저장 플랫폼 스키마 내에 명시적으로 정의된(저장 플랫폼에 의해 자동 생성된 것이 아니라 스키마 설계자에 의해 정의된) 각각의 뷰는 명명된 SQL 뷰 [<schema-name>].[View!<view-name>]에 의해 액세스될 수 있다. 예를 들어, 스키마 "AcmePublisher.Books" 내에 "BookSales"로 명명된 뷰는 명칭 "[AcmePublisher.Bookks].[View!BookSales]"를 이용하여 액세스될 수 있다. 뷰의 출력 포맷은 뷰 단위로(뷰를 정의하는 자에 의해 제공되는 임의의 질의에 의해 정의됨) 맞춰지므로, 열은 스키마 뷰 정의에 기초하여 직접 매핑된다.

저장 플랫폼 데이터 저장소 내의 모든 SQL 검색 뷰는 다음과 같은 열 순서화 규약을 이용한다.

ㆍ ItemId, ElementId, RelationshipId 등과 같은 뷰 결과의 논리 "키" 열

ㆍ TypeId와 같은 결과의 타입에 대한 메타데이터 정보

ㆍ CreateVersion, UpdateVersion 등과 같은 변경 추적 열

ㆍ 타입 특정 열(선언 타입의 속성)

ㆍ 타입 특정 뷰(패밀리 뷰)는 또한 객체를 리턴하는 객체 열을 포함한다.

각 타입 패밀리의 멤버들은 일련의 항목 뷰들을 이용하여 검색 가능한데, 데이터 저장소에는 항목 타입당 하나의 뷰가 존재한다. 도 28은 항목 검색 뷰의 개념을 나타내는 도면이다.

a) 항목

각 항목 검색 뷰는 특정 타입 또는 그의 서브 타입의 항목의 각 인스턴스에 대한 행을 포함한다. 예를 들어, 문서에 대한 뷰는 Document, LegalDocument 및 ReviewDocument의 인스턴스를 리턴할 수 있다. 이러한 예가 주어지면, 항목 뷰는 도 29에 도시된 바와 같이 개념화될 수 있다.

(1) 마스터 항목 검색 뷰

저장 플랫폼 데이터 저장소의 각 인스턴스는 마스터 항목 뷰라고 하는 특수 항목을 정의한다. 이 뷰는 데이터 저장소 내의 각 항목에 대한 요약 정보를 제공한다. 뷰는 항목 타입 속성당 하나의 열, 항목의 타입을 기술하는 열, 및 변경 추적 및 동기화 정보를 제공하는 데 사용되는 여러 열을 제공한다. 마스터 항목 뷰는 명칭 "[System.Storage].[Master!Item]"을 이용하여 데이터 저장소에서 식별된다.

열	타입	설명
ItemId	ItemId	항목의 저장 플랫폼 식별자
_TypeId	TypeId	항목의 TypeId는 항목의 정확한 타입을 식별하며, 메타데이터 카탈로그를 이용하여 타입에 대한 정보를 검색하는 데 사용될 수 있다.
_RootItemId	ItemId	이 항목의 수명을 제어하는 제1 비삽입 조상의 ItemId
<global change tracking>	...	글로벌 변경 추적 정보
<Item props>	n/a	항목 타입 속성당 하나의 열

(2) 타입화된 항목 검색 뷰

각 항목 타입은 또한 검색 뷰를 갖는다. 루트 항목 뷰와 유사한 반면, 이 뷰는 "_Item" 열을 통해 항목 객체에 대한 액세스도 제공한다. 각각의 타입화된 항목 검색 뷰는 명칭 [schemaName].[itemTypeName]를 이용하여 데이터 저장소에서 식별된다. 예를 들어, [AcmeCorp.Doc][OfficeDoc].

열	타입	설명
ItemId	ItemId	항목의 저장 플랫폼 식별자
<type change tracking>	...	타입 변경 추적 정보
<parent props>	<property specific>	부모 속성당 하나의 열
<item props>	<property specific>	이 타입의 배타적 속성당 하나의 열
_Item	항목의 CLR 타입	CLR 객체-선언 항목의 타입

b) 항목 확장

WinFS 저장소 내의 모든 항목 확장은 또한 검색 뷰를 이용하여 검색 가능하다.

(1) 마스터 확장 검색 뷰

데이터 저장소의 각각의 인스턴스는 마스터 확장 뷰라고 하는 특수 확장 뷰 를 정의한다. 이 뷰는 데이터 저장소 내의 각각의 확장에 대한 요약 정보를 제공한다. 뷰는 확장 속성당 하나의 열, 확장 타입을 기술하는 하나의 열, 및 변경 추적 및 동기화 정보를 제공하는 데 사용되는 여러 열을 갖는다. 마스터 확장 뷰는 명칭 [System.Storage].[Master!Extension]"을 이용하여 데이터 저장소에서 식별된다.

열	타입	설명
ItemId	ItemId	확장이 연관된 항목의 저장 플랫폼 식별자
ExtensionId	ExtensionId(GUID)	이 확장 인스턴스의 ID
_TypeId	TypeId	확장의 TypeId는 확장의 정확한 타입을 식별하며, 메타데이터 카탈로그를 이용하여 확장에 대한 정보를 검색하는 데 사용될 수 있다.
<global change tracking>	...	글로벌 변경 추적 정보
<ext properties>	<property specific>	확장 타입 속성당 하나의 열

(2) 타입화된 확장 검색 뷰

각각의 확장 타입은 또한 검색 뷰를 갖는다. 마스터 확장 뷰와 유사한 반면, 이 뷰는 _Extension 열을 통해 항목에 대한 액세스도 제공한다. 각각의 타입화된 확장 검색 뷰는 명칭 [schemaName].[Extension!extensionTypeName]을 이용하여 데이터 저장소에서 식별된다. 예를 들어, [AcmeCorp.Doc].[Extension!OfficeDocExt].

열	타입	설명
ItemId	ItemId	이 확장이 연관된 항목의 저장 플랫폼 식별자
ExtensionId	ExtensionId(GUID)	이 확장 인스턴스의 ID
<type change tracking>	...	타입 변경 추적 정보
<parent props>	<property specific>	부모 속성당 하나의 열
<ext props>	<property specific>	이 타입의 배타적 속성당 하나의 열
_Extension	확장 인스턴스의 CLR 타입	CLR 객체-선언 확장의 타입

c) 중첩 요소

모든 중첩 요소는 항목, 확장 또는 관계 인스턴스 내에 저장된다. 이에 따라, 이들은 적절한 항목, 확장 또는 관계 검색 뷰에 질의함으로써 액세스된다.

d) 관계

전술한 바와 같이, 관계는 저장 플랫폼 데이터 저장소 내의 항목들 사이의 연결의 기본 단위를 형성한다.

(1) 마스터 관계 검색 뷰

각각의 데이터 저장소는 마스터 관계 뷰를 제공한다. 이 뷰는 데이터 저장소 내의 모든 관계 인스턴스에 대한 정보를 제공한다. 마스터 관계 뷰는 명칭 "[System.Storage].[Master!Relationship]"을 이용하여 데이터 저장소에서 식별된다.

열	타입	설명
ItemId	ItemId	소스 엔드포인트의 식별자(ItemId)
RelationshipId	RelationshipId(GUID)	관계 인스턴스의 ID
_RelTypeId	RelationshipTypeId	관계의 RelTypeId는 메타데이터 카탈로그를 이용하여 관계 인스턴스의 타입을 식별한다.
<global change tracking>	...	글로벌 변경 추적 정보
TargetItemReference	ItemReference	타겟 엔드포인트의 식별자
_Relationship	Relationship	이 인스턴스에 대한 관계 객체의 인스턴스

(2) 관계 인스턴스 검색 뷰

각각의 선언된 관계는 또한 특정 관계의 모든 인스턴스를 리턴하는 검색 뷰를 갖는다. 마스터 관계 뷰와 유사하지만, 이 뷰는 관계 데이터의 각 속성에 대해 명명된 열을 또한 제공한다. 각각의 관계 인스턴스 검색 뷰는 명칭 [schemaName].[Relationship!relationshipName]을 이용하여 데이터 저장소에서 식별된다. 예를 들면, [AcmeCorp.Doc].[Relationship!DocumentAuthor].

열	타입	설명
ItemId	ItemId	소스 엔드포인트의 식별자(ItemId)
RelationshipId	RelationshipId(GUID)	관계 인스턴스의 ID
<type change tracking>	...	타입 변경 추적 정보
TargetItemReference	ItemReference	타겟 엔드포인트의 식별자
<source name>	ItemId	소스 엔드포인트 식별자의 명명된 속성(ItemId의 별명)
<target name>	ItemReference 또는 도출된 클래스	타겟 엔드포인트 식별자의 명명된 속성(TargetItemReference에 대한 별명 및 캐스트)
<rel property>	<property specific>	관계 정의의 속성당 하나의 열
_Relationship	관계 인스턴스의 CLR 타입	CLR 객체-선언 관계의 타입

e)

9. 갱신

저장 플랫폼 데이터 저장소 내의 모든 뷰는 판독 전용이다. 데이터 모델 요소(항목, 확장 또는 관계)의 새로운 인스턴스를 생성하기 위하여, 또는 기존 인스턴스를 갱신하기 위하여, 저장 플랫폼 API의 ProcessOperation 또는 ProcessUpdategram 메소드가 사용되어야 한다. ProcessOperation 메소드는 수행될 액션을 상술하는 "동작"을 소비하는 데이터 저장소에 의해 정의된 단일 저장 절차이다. ProcessUpdategram 메소드는 수행될 한 세트의 액션을 집합적으로 상술하는 "updategram"으로 알려진 순서화된 동작 세트를 취하는 저장된 절차이다.

동작 포맷은 확장 가능하며, 스키마 요소에 대한 다양한 동작을 제공한다. 소정의 일반 동작들은 다음을 포함한다.

1. 항목 동작

a. CreateItem(삽입 또는 유지 관계와 관련된 새로운 항목 생성)

b. UpdateItem(기존 항목 갱신)

2. 관계 동작

a. CreateRelationship(참조 또는 유지 관계의 인스턴스 생성)

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

c. DeleteRelationship(관계 인스턴스 제거)

3. 확장 동작

a. CreateExtension(기존 항목에 확장 추가)

b. UpdateExtension(기존 확장 갱신)

c. DeleteExtension(확장 삭제)

10. 변경 추적 및 묘비

변경 추적 및 묘비 서비스는 후술하는 바와 같이 데이터 저장소에 의해 제공된다. 이 섹션은 데이터 저장소에 노출되는 변경 추적 정보의 개요를 제공한다.

a) 변경 추적

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

데이터 저장소 내의 각각의 요소에 대해, 변경 추적 정보는 2개의 장소, 즉 마스터 요소 뷰 및 타입화된 요소 뷰로부터 이용할 수 있다. 예를 들어, AcmeCorp.Document.Document 항목 타입에 대한 변경 추적 정보는 마스터 항목 뷰 "[System.Storage].[Master!Item] 및 타입화된 검색 뷰 [AcmeCorp.Document].[Document]로부터 이용 가능하다.

(1) 마스터 검색 뷰에서의 변경 추적

마스터 검색 뷰 내의 변경 추적 정보는 요소의 생성 및 갱신 버젼에 대한 정보, 동기 파트너가 생성하고 최종 갱신한 요소의 대상인 정보, 및 생성 및 갱신을 위한 각 파트너로부터의 버젼 번호를 제공한다. 동기 관계(후술함) 내의 파트너들은 파트너 키에 의해 정의된다. 타입 [System.Storage.Store].ChangeTrackingInfo의 _ChangeTrackingInfo라는 명칭의 단일 UDT 객체가 이러한 모든 정보를 포함한다. 타입은 System.Storage 스키마에서 정의된다. _ChangeTrackingInfo는 항목, 확장 및 관계에 대한 모든 글로벌 검색 뷰에서 이용될 수 있다. ChangeTrackingInfo의 타입 정의는 다음과 같다.

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

열	설명
_CreationLocalTS	로컬 머신에 의한 생성 타임 스탬프
_CreatingPartnerKey	이 엔티티를 생성한 파트너의 PartnerKey. 엔티티가 로컬 생성된 경우, 이것은 로컬 머신의 PartnerKey이다.
_CreatingPartnerTS	이 엔티티가 _CreatingPartnerKey에 대응하는 파트너에서 생성된 시간의 타임 스탬프.
_LastUpdateLocalTS	로컬 머신에서의 갱신 시간에 대응하는 로컬 타임 스탬프
_LastUpdatingPartnerKey	이 엔티티를 최종 갱신한 파트너의 PartnerKey. 엔티티에 대한 최종 갱신이 로컬 수행된 경우, 이것은 로컬 머신의 PartnerKey이다.
_LastUpdatingPartnerTS	이 엔티티가 _LastUpdatingPartnerKey에 대응하는 파트너에서 갱신된 시간의 타임 스탬프

(2) 타입화된 검색 뷰에서의 변경 추적

각각의 타입화된 검색 뷰는 글로벌 검색 뷰와 동일한 정보를 제공하는 것 외에 동기 토폴로지에서 각각의 요소의 동기 상태를 기록하는 추가 정보를 제공한다.

열	타입	설명
<global change tracking>	...	글로벌 변경 추적으로부터의 정보
_ChangeUnitVersions	MultiSet<ChangeUnitVersion>	특정 요소 내의 변경 단위의 버젼 번호에 대한 설명
_ElementSyncMetadata	ElementSyncMetadata	동기화 실행 시간에만 관련된 항목에 대한 추가적인 버젼 독립 메타데이터
_VersionSyncMetadata	VersionSyncMetadata	동기화 실행 시간에만 관련된 버젼에 대한 추가 버젼 특정 메타데이터

b) 묘비

데이터 저장소는 항목, 확장 및 관계에 대한 묘비 정보를 제공한다. 묘비 뷰는 한 곳에서 살아 있는 엔티티 및 묘비를 가진 엔티티(항목, 확장 및 관계) 양자에 대한 정보를 제공한다. 항목 및 확장 묘비 뷰는 대응 객체에 대한 액세스를 제공하지 않는 반면, 관계 묘비는 관계 객체에 대한 액세스를 제공한다(관계 객체는 묘비를 가진 관계의 경우 공백이다).

(1) 항목 묘비

항목 묘비는 뷰 [System.Storage].[Tombstone!Item]을 통해 시스템으로부터 검색된다.

열	타입	설명
ItemId	ItemId	항목의 식별자
_TypedID	TypedID	항목의 타입
<Item properties>	...	모든 항목에 대해 정의된 속성
_RootItemId	ItemId	이 항목을 포함하는 제1 비삽입 항목의 ItemId
_ChangeTrackingInfo	타입 ChangeTrackingInfo의 CLR 인스턴스	이 항목에 대한 변경 추적 정보
_IsDeleted	BIT	이것은 살아 있는 항목에 대해 0이고, 묘비를 가진 항목에 대해 1인 플래그이다.
_DeletionWallclock	UTCDATETIME	항목을 삭제한 파트너에 따르는 UTC 벽시계 날자 시간. 이것은 항목이 살아 있는 경우 공백이다.

(2) 확장 묘비

확장 묘비는 뷰 [System.Storage].[Tombstone!Extension]을 이용하여 시스템으로부터 검색된다. 확장 변경 추적 정보는 ExtensionId 속성이 추가된 항목에 대해 제공되는 것과 유사하다.

열	타입	설명
ItemId	ItemId	확장을 소유하는 항목의 식별자
ExtensionId	ExtensionId	확장의 확장 ID
_TypedID	TypedID	확장의 타입
_ChangeTrackingInfo	타입 ChangeTrackingInfo의 CLR 인스턴스	이 확장에 대한 변경 추적 정보
_IsDeleted	BIT	이것은 살아 있는 항목에 대해 0이고, 묘비를 가진 항목에 대해 1인 플래그이다.
_DeletionWallclock	UTCDATETIME	항목을 삭제한 파트너에 따르는 UTC 벽시계 날자 시간. 이것은 확장이 살아 있는 경우 공백이다.

(3) 관계 묘비

관계 묘비는 뷰 [System.Storage].[Tombstone!Relationship]을 통해 시스템 으로부터 검색된다. 관계 묘비 정보는 확장에 대해 제공되는 것과 유사하다. 그러나, 관계 인스턴스의 타겟 ItemRef에 대한 추가 정보가 제공된다. 또한, 관계 객체도 선택된다.

열	타입	설명
ItemId	ItemId	관계를 소유하는 항목의 식별자(관계 소스 엔드포인트의 식별자)
RelationshipId	RelationshipId	관계의 RelationshipId
_TypedID	TypedID	관계의 타입
_ChangeTrackingInfo	타입 ChangeTrackingInfo의 CLR 인스턴스	이 관계에 대한 변경 추적 정보
_IsDeleted	BIT	이것은 살아 있는 항목에 대해 0이고 묘비를 가진 항목에 대해 1인 플래그이다.
_DeletionWallclock	UTCDATETIME	관계를 삭제한 파트너에 따르는 UTC 벽시계 날자 시간. 이것은 관계가 살아 있는 경우 공백이다.
_Relationship	관계의 CLR 인스턴스	이것은 살아 있는 관계에 대한 관계 객체이다. 이것은 묘비를 가진 관계에 대해 공백이다.
TargetItemReference	ItemReference	타겟 엔드포인트의 식별자

(4) 묘비 제거

묘비 정보의 무제한 증가를 방지하기 위해, 데이터 저장소는 묘비 제거 작업을 제공한다. 이 작업는 묘비 정보가 언제 폐기될 수 있는지를 결정한다. 작업는 로컬 생성/갱신 버젼에 대한 경계를 계산한 후, 모든 초기 묘비 버젼을 폐기함으로써 묘비 정보를 단축시킨다.

11. 헬퍼 API 및 함수

기본 매핑도 다수의 헬퍼 함수를 제공한다. 이들 함수는 데이터 모델을 통 해 일반 동작들을 돕도록 제공된다.

a) 함수 [System.Storage].GetItem

b) 함수 [System.Storage].GetExtension

c) 함수 [System.Storage].GetRelationship

12. 메타데이터

저장소에서 표현되는 2가지 타입의 메타데이터, 즉 인스턴스 메타데이터(항목의 타입 등) 및 타입 메타데이터가 존재한다.

a) 스키마 메타데이터

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

b) 인스턴스 메타데이터

인스턴스 메타데이터는 항목의 타입에 대해 질의하기 위해 애플리케이션에 의해 사용되며, 항목과 관련된 확장을 찾는다. 항목에 대한 ItemId가 주어지면, 애플리케이션은 글로벌 항목 뷰에 질의하여 항목의 타입을 리턴하고 이 값을 이용하여 메타 타입 뷰에 질의하여 항목의 선언 타입에 대한 정보를 리턴할 수 있다. 다음은 그 예이다.

E. 보안

일반적으로, 모든 보안 가능 객체는 도 26에 도시된 액세스 마스크 포맷을 이용하여 그들의 액세스 권리를 배열한다. 이 포맷에서, 낮은 순위의 16 비트는 객체 특정 액세스 관리에 대한 것이고, 다음 7 비트는 대부분의 객체 타입에 적용되는 표준 액세스 권리에 대한 것이며, 높은 순위의 4 비트는 각각의 객체 타입이 표준 및 객체 특정 권리의 세트로 매핑될 수 있는 일반 액세스 권리를 지정하는 데 사용된다. ACCESS_SYSTEM_SECURITY 비트는 객체의 SACL에 액세스할 수 있는 권리 에 대응한다.

도 26의 액세스 마스크 구조에서, 항목 특정 권리는 객체 특정 권리 섹션(낮은 순위의 16 비트)에 배치된다. 본 실시예에서 저장 플랫폼은 보안 관리를 위해 2 세트의 API, 즉 Win32 및 저장 플랫폼 API를 노출시키므로, 파일 시스템 객체 특정 권리는 저장 플랫폼 객체 특정 권리의 설계를 자극하도록 고려되어야 한다.

본 발명의 저장 플랫폼에 대한 보안 모델은 본 명세서에서 초기에 참조로 반영된 관련 출원들에 충분히 설명되어 있다. 이와 관련하여, 도 27(a, b, c 부분)은 보안 모델의 일 실시예에 따라 동일하게 보호되는 새로운 보안 영역이 기존 보안 영역으로부터 분리되는 것을 나타내고 있다.

F. 통지 및 변경 추적

본 발명의 다른 양태에 따르면, 저장 플랫폼은 애플리케이션이 데이터 변경을 추적하는 것을 허용하는 통지 능력을 제공한다. 이 기능은 주로 휘발 상태를 유지하거나 데이터 변경 이벤트에서 비지니스 논리를 실행하는 애플리케이션들을 위한 것이다. 애플리케이션은 항목, 항목 확장 및 항목 관계 상의 통지에 등록한다. 통지는 데이터 변경이 행해진 후에 비동기적으로 전달된다. 애플리케이션은 항목, 확장 및 관계 타입은 물론 동작의 타입에 의해 통지를 필터링할 수 있다.

일 실시예에 따르면, 저장 플랫폼 API(322)는 통지에 대해 2 종류의 인터페이스를 제공한다. 첫째, 애플리케이션은 항목, 항목 확장 및 항목 관계에 대한 변경에 의해 트리거되는 단순 데이터 변경 이벤트에 등록한다. 둘째, 애플리케이션 은 항목, 항목 확장 및 항목들 사이의 관계의 세트를 모니터하기 위해 "감시자" 객체를 생성한다. 감시자 객체의 상태는 저장될 수 있으며, 시스템 고장 후 또는 시스템이 연장된 기간 동안 오프라인으로 된 후에 재생성될 수 있다. 단일 통지는 다수의 갱신을 반영할 수 있다.

이러한 기능에 대한 추가적인 상세는 본 명세서에서 초기에 참고로 반영된 관련 출원에서 발견할 수 있다.

G. 통상적인 파일 시스템 연동성

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

그러나, NTFS 파일 시스템을 본 발명의 저장 플랫폼으로 완전히 대체하는 것은 기존 Win32 기반 애플리케이션 프로그램들의 재 코딩을 필요로하고, 이러한 재 코딩은 바람직하지 않을 수 있다는 것을 고려하면, 본 발명의 저장 플랫폼이 NTFS와 같은 기존 파일 시스템과의 소정의 연동성을 제공하는 것이 이로울 것이다. 따라서, 본 발명의 일 실시예에서, 저장 플랫폼은 Win32 프로그래밍 모델에 의존하는 애플리케이션 프로그램들이 통상의 NTFS 파일 시스템은 물론, 저장 플랫폼의 양 데이터 저장소의 콘텐츠에 액세스하는 것을 가능하게 한다. 이 때문에, 저장 플랫폼은 연동을 용이하게 하기 위해 Win32 명명 규약의 수퍼 세트인 명명 규약을 사용한다. 또한, 저장 플랫폼은 Win32 API를 통해 저장 플랫폼 볼륨에 저장된 파일 및 디렉토리에 액세스하는 것을 지원한다.

이 기능에 대한 추가 상세는 본 명세서의 앞에서 참조로 반영된 관련 출원들에서 발견할 수 있다.

H. 저장 플랫폼 API

저장 플랫폼은 애플리케이션 프로그램들이 전술한 저장 플랫폼의 기능 및 능력에 액세스하고 데이터 저장소에 저장된 항목들에 액세스하는 것을 가능하게 하는 API를 포함한다. 이 섹션은 본 발명의 저장 플랫폼의 저장 플랫폼 API의 일 실시예를 설명한다. 이 기능에 대한 상세는 본 명세서의 앞에서 참조로 반영된 관련 출원들에서 발견할 수 있으며, 편의를 위해 이 정보의 일부가 아래 요약된다.

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

도 19는 본 발명에 따른 저장 플랫폼 API의 기본 아키텍처를 나타낸다. 저장 플랫폼 API는 SQLClient(1900)를 이용하여 로컬 데이터 저장소(302)와 대화하며, 또한 SQLClient(1900)를 이용하여 원격 데이터 저장소(예컨대, 데이터 저장소 340)와 대화할 수 있다. 로컬 저장소(302)는 또한 분산 질의 프로세서(DQP)를 이용하거나 후술하는 저장 플랫폼 동기화 서비스("Sync")를 통해 원격 데이터 저장소(340)와 대화할 수 있다. 저장 플랫폼 API(322)는 전술한 바와 같이 애플리케이션의 가입을 통지 엔진(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)는 결합된 항목에 대응하는 ItemContext 객체(2202)를 생성하여 이를 애플리케이션에게 리턴한다.

3. 애플리케이션은 항목들의 집합을 얻기 위해 이 ItemContext 상에 Find를 제출하는데, 리턴된 집합은 개념적으로 (관계들로 인해) 객체 그래프(2204)이다.

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

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

도 23은 "FindAll" 동작의 실행을 나타낸다.

도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타낸다.

도 25는 File API가 근거로 하는 스키마를 나타낸다. 저장 플랫폼 API는 파일 객체를 처리하기 위한 명칭 공간을 포함한다. 이 명칭 공간은 System.Storage.Files라고 한다. System.Storage.Files 내의 클래스들의 데이터 멤버들은 저장 플랫폼 저장소에 저장된 정보를 직접 반사하며, 이 정보는 파일 시스템 객체로부터 승진하거나, Win32 API를 이용하여 고유하게 생성될 수 있다. System.Storage.Files 명칭 공간은 2개의 클래스, 즉 FileItem 및 DirectoryItem을 갖는다. 이 클래스의 멤버들 및 그의 메소드들은 도 25의 스키마 도면을 봄으로써 쉽게 발견될 수 있다. FileItem 및 DirectoryItem은 저장 플랫폼 API로부터 판독 전용이다. 이들을 수정하기 위해서는 Win32 API 또는 System.IO 내의 클래스를 이용해야 한다.

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

개념적으로 프로그래밍 인터페이스는 도 30A 또는 30B에 도시된 바와 같이 일반적으로 보여질 수 있다. 도 30A는 제1 및 제2 코드 세그먼트가 통신하는 수단 인 통로로서 인터페이스 Interface1을 나타내고 있다. 도 30B는 시스템의 제1 및 제2 코드 세그먼트가 매체(M)를 통해 통신하는 것을 가능하게 하는 인터페이스 객체 I1 및 I2(이들은 제1 및 제2 코드 세그먼트의 일부이거나 아닐 수도 있다)를 포함하는 것으로서 인터페이스를 도시하고 있다. 도 30B를 볼 때, 인터페이스 객체 I1 및 I2를 동일 시스템의 개별 인터페이스로서 간주하고, 또한 객체 I1 및 I2 플러스 매체(M)이 인터페이스를 포함하는 것으로 간주할 수 있다. 도 30A 및 30B는 양방향 흐름, 및 흐름의 각 측 상의 인터페이스를 도시하고 있지만, 소정의 구현들은 일 방향으로의 정보 흐름을 갖거나(또는 후술하는 바와 같이 정보 흐름이 없거나), 한쪽에만 인터페이스 객체를 가질 수 있다. 예를 들어, API, 엔트리 포인트, 메소드, 함수, 서브루틴, 원격 프로시저 호출 및 COM 인터페이스와 같은 용어들은 프로그래밍 인터페이스의 정의 내에 포함되지만, 이것으로 한정되는 것은 아니다.

프로그래밍 인터페이스의 양태들은 제1 코드 세그먼트가 제2 코드 세그먼트로 정보를 전송할 수 있게 하는 메소드(여기서, "정보"는 넓은 의미로 사용되며, 데이터, 명령, 요구 등을 포함한다); 제2 코드 세그먼트가 정보를 수신할 수 있게 하는 메소드; 및 정보의 구조, 시퀀스, 신택스, 조직, 스키마, 타이밍 및 내용을 포함할 수 있다. 이와 관련하여, 기반 전송 매체 자체는 정보가 인터페이스에 의해 정의된 방식으로 전송되는 한은 매체가 유선인지 무선인지, 또는 이들의 조합인지에 관계없이 인터페이스의 동작에 중요하지 않을 수 있다. 소정의 상황에서, 하나의 코드 세그먼트가 제2 코드 세그먼트에 의해 수행되는 기능에 간단히 액세스할 때와 같이 정보 전송이 다른 메커니즘을 통하거나(예컨대, 버퍼, 파일 등에 위치한 정보는 코드 세그먼트들 사이의 정보 흐름으로부터 분리된다) 존재하지 않을 수 있을 때 정보는 통상적인 의미에서 한 방향 또는 양 방향으로 전송되지 않을 수 있다. 이러한 양태들 중 임의의 양태 또는 모든 양태는 예를 들어 코드 세그먼트들이 느슨하게 결합되거나 밀접하게 결합된 구성에서 시스템의 일부인지의 여부에 따라 주어진 상황에서 중요할 수 있으며, 따라서 이 리스트는 예시적인 것일 뿐 제한적이 아닌 것으로 간주되어야 한다.

이러한 프로그래밍 인터페이스의 개념은 당업자에게 공지되어 있으며, 전술한 본 발명의 상세한 설명으로부터 명백하다. 그러나, 프로그래밍 인터페이스를 구현하는 다른 방법들이 있으며, 명백하게 배제되지 않은 한, 이들도 본 명세서의 끝에 설명되는 청구범위에 포함되는 것으로 의도된다. 그러한 다른 방법들은 도 30A 및 30B의 간단한 도면보다 복잡한 것으로 보일 수 있지만, 그럼에도 이들은 동일한 전체 결과를 달성하는 유사한 기능을 수행한다. 이제, 프로그래밍 인터페이스의 몇몇 예시적인 대체 구현을 간단히 설명한다.

인수 분해: 하나의 코드 세그먼트에서 다른 코드 세그먼트로의 통신은 통신을 다수의 개별 통신으로 분해함으로써 간접적으로 완수될 수 있다. 이것은 도 31A 및 31B에 개략적으로 도시되어 있다. 도시된 바와 같이, 몇몇 인터페이스는 분할 가능한 기능 세트에 의해 설명될 수 있다. 따라서, 도 30A 및 30B의 인터페이스 기능은, 수학적으로 24 또는 2×2×3×2를 제공할 수 있는 것과 같이, 동일한 결과를 달성할 수 있도록 인수 분해될 수 있다. 따라서, 도 31A에 도시된 바와 같이, 인터페이스 Interface1에 의해 제공되는 기능은 동일한 결과를 달성하면서 인 터페이스의 통신을 변환하기 위해 다수의 인터페이스 Interface1A, Interface1B, Interface1C 등으로 세분될 수 있다. 도 31B에 도시된 바와 같이, 인터페이스 I1에 의해 제공되는 기능은 동일한 결과를 달성하면서 다수의 인터페이스 I1a, I1b, I1c 등으로 세분될 수 있다. 마찬가지로, 제1 코드 세그먼트로부터 정보를 수신하는 제2 코드 세그먼트의 인터페이스 I2는 다수의 인터페이스 I2a, I2b, I2c 등으로 인수 분해될 수 있다. 인수 분해시, 제1 코드 세그먼트에 포함되는 인터페이스의 수는 제2 코드 세그먼트에 포함되는 인터페이스의 수와 일치할 필요는 없다. 도 31A 및 31B의 경우들 중 어느 하나에서, 인터페이스 Interface1 및 I1의 기능적인 사상은 도 30A 및 30B와 각각 동일하게 유지된다. 인터페이스의 인수 분해는 또한 결합, 교환 및 다른 수학적 특성을 따를 수 있으며, 따라서 인수 분해는 인식하기 어려울 수 있다. 예를 들어, 동작들의 순서화는 중요하지 않을 수 있으며, 결과적으로 하나의 인터페이스에 의해 수행되는 기능은 이 인터페이스에 도달하기 전에 다른 코드 또는 인터페이스에 의해 수행되거나, 시스템의 개별 컴포넌트에 의해 수행될 수 있다. 더욱이, 동일 결과를 달성하는 상이한 함수 호출을 다양한 방법이 있다는 것을 프로그래밍 분야의 당업자는 이해할 수 있다.

재정의: 몇몇 경우에, 여전히 의도한 결과를 달성하면서 프로그래밍 인터페이스의 소정의 양태들(예컨대, 파라미터들)을 무시, 추가 또는 재정의할 수 있다. 이것은 도 32A 및 32B에 도시되어 있다. 예컨대, 도 30A의 인터페이스 Interface1이 3개의 파라미터, 즉 입력, 정확도 및 출력을 포함하고 제1 코드 세그먼트에서 제2 코드 세그먼트로 발행되는 호출인 함수 호출 Square(input, precision, output)를 포함하는 것으로 가정한다. 도 32A에 도시된 바와 같이, 중간 파라미터인 정확도가 주어진 시나리오에서 중요하지 않은 경우, 이 파라미터는 무시되거나, (이 상황에서) 의미 없는 파라미터로 대체될 수도 있다. 또한, 중요하지 않은 추가 파라미터를 추가할 수도 있다. 어느 경우에나, 입력이 제2 코드 세그먼트에 의해 제곱된 후 출력이 리턴되는 한 제곱의 기능은 달성될 수 있다. 정확도는 매우 양호하게 컴퓨팅 시스템의 소정의 다운스트림 또는 다른 부분에 의미 있는 파라미터일 수 있으나, 정확도가 제곱을 계산하는 좁은 목적에 필요하지 않은 것으로 인식되면, 정확도는 대체되거나 무시될 수 있다. 예컨대, 유효한 정확도 값을 전달하는 대신, 생일과 같은 의미 없는 값이 결과에 악영향을 미치지 않고 전달될 수 있다. 마찬가지로, 도 32B에 도시된 바와 같이, 인터페이스 I1은 파라미터를 무시하거나 인터페이스에 추가하도록 재정의된 인터페이스 I1'로 대체된다. 인터페이스 I2는 마찬가지로 불필요한 파라미터, 또는 그 밖의 곳에서 처리될 수 있는 파라미터를 무시하도록 재정의된 인터페이스 I2'로 재정의될 수 있다. 여기서 요점은 몇몇 경우에 프로그래밍 인터페이스가 소정의 목적에 필요하지 않은 파라미터들과 같은 양태들을 포함할 수 있으며, 따라서 이들은 무시 또는 재정의되거나, 다른 목적을 위해 그 밖의 다른 곳에서 처리될 수 있다는 점이다.

인라인 코딩: 2개의 개별 코드 모듈의 기능의 일부 또는 전부를 병합하여 이들 사이의 인터페이스가 형태를 변경하도록 하는 것이 가능하다. 예컨대, 도 30A 및 30B의 기능은 각각 도 33A 및 33B의 기능으로 변환될 수 있다. 도 33A에서, 도 30A의 이전 제1 및 제2 코드 세그먼트들은 이들 양자를 포함하는 모듈로 병합된다. 이 경우, 코드 세그먼트들은 여전히 서로 통신할 수 있지만, 인터페이스는 단일 모듈에 보다 적절한 형태로 적응될 수 있다. 따라서, 예를 들면, 정형적인 호출 및 리턴 명령문이 더 이상 필요하지 않을 수 있지만, 인터페이스 Interface1에 따르는 유사한 처리 또는 응답이 여전히 실행될 수 있다. 마찬가지로, 도 33B에 도시된 바와 같이, 도 30B로부터의 인터페이스 I2의 일부(또는 전부)는 인터페이스 I1 내에 인라인으로 작성되어 인터페이스 I1'가 형성될 수 있다. 도시된 바와 같이, 인터페이스 I2는 I2a 및 I2b로 분할되며, 인터페이스 부분 I2a는 인터페이스 I1과 함께 인라인 코딩되어 인터페이스 I1''이 형성된다. 구체적인 예로서, 도 30B로부터의 인터페이스 I1이, 인터페이스 I2에 의해 수신되고 제2 코드 세그먼트에 의해 입력으로 전달된 값을 처리한 후(입력 값을 제곱함) 제곱된 결과를 출력으로 전달하는 함수 호출 square(input, output)을 수행하는 것으로 가정한다. 이 경우, 제2 코드 세그먼트에 의해 수행되는 처리(입력 제곱)는 인터페이스로의 호출 없이 제1 코드 세그먼트에 의해 수행될 수 있다.

분리: 하나의 코드 세그먼트에서 다른 코드 세그먼트로의 통신은 통신을 다수의 개별 통신으로 분리함으로써 간접적으로 달성될 수 있다. 이것은 도 34A 및 34B에 개략 도시되어 있다. 도 34A에 도시된 바와 같이, 하나 이상의 미들웨어(오리지날 인터페이스로부터 기능 및/또는 인터페이스 기능들을 분리하므로 분리 인터페이스)가 제1 인터페이스 Interface1 상의 통신들을 변환하여 이들이 상이한 인터페이스, 이 경우 인터페이스 Interface2A, Interface2B 및 Interface2C를 따르도록 하기 위해 제공된다. 이것은 예를 들어 인터페이스1 프로토콜에 따라 예컨대 운영 체제와 통신하도록 설계된 설치 기반 애플리케이션들이 존재하지만, 이후 운영 체제이 상이한 인터페이스, 이 경우 인터페이스 Interface2A, Interface2B 및 Interface2C를 사용하도록 변경된 경우에 행해질 수 있다. 요점은, 제2 코드 세그먼트에 의해 사용되는 오리지날 인터페이스가 변경되어, 제1 코드 세그먼트에 의해 사용되는 인터페이스와 더 이상 호환이 되지 않으며, 따라서 신구 인터페이스들을 호환 가능하게 하기 위해 매개물이 사용된다는 점이다. 마찬가지로, 도 34B에 도시된 바와 같이, 인터페이스 I1로부터 통신을 수신하는 분리 인터페이스 DI1 및 인터페이스 기능을 예컨대 인터페이스 I2a 및 I2b로 전송하는 분리 인터페이스 DI2를 구비한 제3 코드 세그먼트가 도입될 수 있는데, I2a 및 I2b는 DI2와 함께 동작하도록 재설계되지만 동일한 기능적 결과를 제공한다. 마찬가지로, DI1 및 DI2는 동일하거나 유사한 기능적 결과를 제공하면서 도 30B의 인터페이스 I1 및 I2의 기능을 새로운 운영 체제으로 전달하도록 함께 동작할 수 있다.

재작성: 또 하나의 가능한 변형은 코드를 동적으로 재작성하여 인터페이스 기능을, 동일한 전체 결과를 달성하는 그 외의 다른 것으로 대체하는 것이다. 예컨대, 중간 언어로 표현된 코드 세그먼트가 실행 환경(예컨대, 네트 프레임워크, 자바 실행시간 환경 또는 다른 유사한 실행시간 타입 환경에 의해 제공됨)에서 JIT(Just-in-Time) 컴파일러 또는 인터프리터로 제공되는 시스템이 존재할 수 있다. JIT 컴파일러는 제1 코드 세그먼트에서 제2 코드 세그먼트로 통신들을 동적으로 변환하도록, 즉 이들 통신을 제2 코드 세그먼트(오리지날 또는 다른 제2 코드 세그먼트)에 의해 요구될 수 있는 바와 같이 상이한 인터페이스에 따르도록 하기 위해 재작성될 수 있다. 이것은 도 35A 및 35B에 도시되어 있다. 도 35A에 도시된 바와 같이, 이러한 접근법은 전술한 분리 시나리오와 유사하다. 이것은 예컨대 설치 기반 애플리케이션들이 Interface1 프로토콜에 따라 운영 체제와 통신하도록 설계되지만, 이후 운영 체제이 상이한 인터페이스를 사용하도록 변경되는 경우에 행해질 수 있다. JIT 컴파일러는 통신들이 설치 기반 애플리케이션들에서 운영 체제의 새로운 인터페이스로 온더플라이로 따르도록 하기 위해 사용될 수 있다. 도 35B에 도시된 바와 같이, 인터페이스를 동적으로 재작성하는 이러한 접근법은 인터페이스를 동적으로 인수 분해하거나 변경하기 위해 적용될 수도 있다.

대체 실시예들을 통해 인터페이스와 동일하거나 유사한 결과를 달성하는 전술한 시나리오들은 또한 다양한 방법으로, 직렬 및/또는 병렬로, 또는 다른 중재 코드와 함께 조합될 수 있다는 점에 유의해야 한다. 따라서, 전술한 대체 실시예들은 서로 배타적이지 않고, 혼합, 매칭 및 조합되어, 도 30A 및 30B에 제공된 일반 시나리오와 동일하거나 동등한 시나리오를 생성할 수 있다. 또한, 대부분의 프로그래밍 구조에서와 같이, 본 명세서에는 설명되지 않을 수 있지만 본 발명의 사상 및 범위에 의해 표현되는 인터페이스의 동일 또는 유사 기능을 달성하는 다른 유사한 방법들이 존재함에 유의해야 하는데, 즉 이것은 적어도 부분적으로 인터페이스의 값의 기초가 되는 인터페이스에 의해 표현되는 기능, 및 인터페이스에 의해 가능하게 되는 이로운 결과들이라는 점에 유의한다.

III. 동기화 API

동기화에 대한 여러 접근법은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가능하다. 섹션 A는 본 발명의 여러 실시예를 개시하며, 섹션 B는 동기화를 위한 API의 다양한 실시예에 초점을 둔다.

A. 동기화 개요

본 발명의 여러 실시예에서, 그리고 도 3과 관련하여, 저장 플랫폼은 (i) 저장 플랫폼의 다수의 인스턴스(각각 그 자신의 데이터 저장소(302)를 가짐)가 융통성 있는 규칙 세트에 따라 그들의 콘텐츠의 부분들을 동기화시키는 것을 허용하고, (ii) 제3자가 본 발명의 저장 플랫폼의 데이터 저장소를 독점 프로토콜을 구현하는 다른 데이터 소스와 동기화하기 위한 기반 구조를 제공하는 동기화 서비스(330)를 제공한다.

저장 플랫폼 대 저장 플랫폼 동기화는 참여 "사본들"의 그룹 사이에서 발생한다. 예컨대, 도 3을 참조하면, 아마도 다른 컴퓨터 시스템 상에서 실행되는 저장 플랫폼의 또 하나의 인스턴스의 제어하에 저장 플랫폼(300)의 데이터 저장소(302)와 다른 원격 데이터 저장소(338) 사이의 동기화를 제공하는 것이 바람직할 수 있다. 이 그룹의 모든 멤버는 임의의 주어진 시간에 임의의 주어진 사본을 반드시 알 필요는 없다.

다른 사본들은 독립적으로(즉, 동시에) 변경을 행할 수 있다. 동기화 프로세스는 모든 사본이 다른 사본들에 의해 행해진 변경을 인식하게 만드는 것으로 정의된다. 동기화 능력은 본질적으로 멀티 마스터이다.

본 발명의 동기화 능력은 사본들이

ㆍ 다른 사본이 어떠한 변경을 알고 있는지를 판정하고,

ㆍ 이 사본이 알지 못하는 변경에 대한 정보를 요구하고,

ㆍ 다른 사본이 알지 못하는 변경에 대한 정보를 전달하고,

ㆍ 2개의 변경이 언제 서로 충돌하는지를 판정하고,

ㆍ 변경을 로컬 적용하고,

ㆍ 수렴을 보장하기 위해 충돌 해결을 다른 사본들에 전달하고,

ㆍ 충돌 해결을 위한 지정된 정책에 기초하여 충돌을 해결하는 것을 허용한다.

1. 저장 플랫폼 대 저장 플랫폼 동기화

본 발명의 저장 플랫폼의 동기화 서비스(330)의 주요 응용은 저장 플랫폼의 다수의 인스턴스(각각 그 자신의 데이터 저장소를 가짐)를 동기화하는 것이다. 동기화 서비스는 저장 플랫폼 스키마 레벨에서(데이터베이스 엔진(314)의 기본 테이블이 아님) 동작한다. 따라서, 예를 들면, "범위(Scopes)"는 후술하는 바와 같이 동기화 세트를 정의하는 데 사용된다.

동기화 서비스는 "순수 변경(net change)"의 원리로 동작한다. 동기화 서비스는 개별 동작들(예컨대, 트랜잭션 복제)을 기록하고 전송하는 것이 아니라, 이 동작들의 최종 결과를 전송하며, 따라서 종종 다수의 동작의 결과들을 단일 결과 변경으로 통합한다.

동기화 서비스는 일반적으로 트랜잭션 경계를 존중하지 않는다. 즉, 단일 트랜잭션에서 저장 플랫폼 데이터 저장소에 대해 2개의 변경이 행해진 경우, 이들 변경이 모든 다른 사본들에 최소 단위로(atomically) 적용된다는 보장이 없는데, 즉 하나의 변경은 다른 변경 없이도 나타날 수 있다. 이 원리에 대한 예외는, 2개의 변경이 동일 트랜잭션에서 동일 항목에 대해 행해진 경우, 이들 변경은 최소 단위로 다른 복제들로 전송되고 적용되는 것이 보장된다는 것이다. 따라서, 항목들은 동기화 서비스의 일관성 단위이다.

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

임의의 애플리케이션이 동기화 서비스에 연결되어, 동기화 동작을 개시할 수 있다. 이러한 애플리케이션은 동기화를 행하는 데 필요한 파라미터들을 모두 제공한다(아래의 동기 프로파일 참조). 이 애플리케이션은 본 명세서에서 동기화 제어 애플리케이션(SCA)이라 한다.

2개의 저장 플랫폼 인스턴스를 동기화할 때, 동기화는 SCA에 의해 한쪽에서 개시된다. SCA는 원격 파트너와 동기화하기 위해 로컬 동기화 서비스에 알린다. 다른 쪽에서는 시발 머신으로부터 동기화 서비스에 의해 전송된 메시지에 의해 동기화 서비스가 개시된다. 동기화 서비스는 도달 머신 상에 존재하는 지속적인 구성 정보(아래 매핑 참조)에 기초하여 응답한다. 동기화 서비스는 스케쥴에 따라 또는 이벤트에 응답하여 실행될 수 있다. 이들 경우에, 스케쥴을 구현하는 동기화 서비스가 SCA가 된다.

동기화를 가능하게 하기 위하여, 두 단계가 취해져야 한다. 먼저, 스키마 설계자는 저장 플랫폼 스키마에 적절한 동기화 시맨틱(후술하는 바와 같이 변경 단위를 나타냄)을 주석으로 달아야 한다. 둘째, 동기화는 동기화에 참여할 저장 플랫폼의 인스턴스를 가진 머신들 모두에서 적절히 구성되어야 한다.

b) 스키마 주석 달기

동기화 서비스의 기본 개념은 변경 단위의 개념이다. 변경 단위는 저장 플랫폼에 의해 개별적으로 추적되는 스키마의 가장 작은 부분이다. 모든 변경 단위에 대해, 동기화 서비스는 변경 단위가 최종 동기화 이후 변경되었는지의 여부를 결정할 수 있다.

스키마에 변경 단위를 표시하는 것은 여러 목적을 갖는다. 먼저, 이것은 동기화 서비스가 유선 상에서 얼마나 기탄없는지를 판정한다. 변경 단위 내에서 변경이 행해질 때, 전체 변경 단위는 다른 사본들로 전송되는데, 이는 동기화 서비스가 변경 단위의 어느 부분이 변경되었는지를 알지 못하기 때문이다. 둘째, 이것은 충돌 검출의 입도를 결정한다. 2개의 동시 변경(이 용어는 후속 섹션에서 상세히 정의된다)이 동일 변경 단위에 대해 행해질 때, 동기화 서비스는 충돌을 일으키는 반면, 동시 변경이 상이한 변경 단위들에 대해 행해지는 경우에는 충돌이 발생하지 않고, 변경들은 자동으로 병합된다. 셋째, 이것은 시스템에 의해 유지되는 메타데이터의 양에 강한 영향을 미친다. 동기화 서비스 메타데이터의 많은 부분은 변경 단위에 대해 유지되며, 따라서 변경 단위들이 동기화의 오버헤드를 보다 적게 증가 시키게 된다.

변경 단위의 정의는 올바른 트레이드오프의 발견을 필요로 한다. 이 때문에, 동기화 서비스는 스키마 설계자가 프로세스에 참여하는 것을 허용한다.

일 실시예에서, 동기화 서비스는 요소보다 큰 변경 단위를 지원하지 않는다. 그러나, 동기화 서비스는 스키마 설계자가 요소보다 작은 변경 단위를 지정할 수 있는 능력, 즉 요소의 다수의 속성을 개별 변경 단위로 그룹화할 수 있는 능력을 지원한다. 이 실시예에서, 이것은 다음의 신택스를 이용하여 달성된다.

c) 동기화 구성

동기화에서 자신들의 데이터의 소정 부분을 유지하기를 원하는 저장 플랫폼 파트너들의 그룹은 동기화 공동체로 지칭된다. 공동체의 멤버들이 동기화 상태에 머물기를 원하는 동안, 이들은 정확히 동일한 방식으로 데이터를 표시할 필요는 없는데, 즉 동기화 파트너들은 이들이 동기화하고 있는 데이터를 변환할 수 있다.

피어 대 피어 시나리오에서, 피어들이 이들의 파트너들 모두에 대한 변환 매핑을 유지하는 것은 비현실적이다. 대신에, 동기화 서비스는 "공동체 폴더"를 정의하는 접근법을 취한다. 공동체 폴더는 모든 공동체 멤버들이 동기화되고 있는 가상적인 "공유 폴더"를 나타내는 추상 개념이다.

이 개념은 일례에 의해 가장 잘 설명된다. 조(Joe)가 동기화 상태에서 자신의 여러 컴퓨터들의 내 문서 폴더들을 유지하기를 원하는 경우, 조는 예컨대 JoesDocuments라고 하는 공동체 폴더를 정의한다. 그러면, 모든 컴퓨터에서 조는 가상적인 JoesDocuments 폴더와 로컬 내 문서 폴더 사이의 매핑을 구성한다. 이 시점으로부터, 조의 컴퓨터들이 서로 동기화될 때, 이들은 이들의 로컬 항목들이 아니라 JoesDocuments 내의 문서들에 관해 대화한다. 이러한 방식으로, 조의 모든 컴퓨터들은 다른 컴퓨터들이 누구인지를 알지 않고도 서로를 이해하게 되며, 공동체 폴더는 동기화 공동체의 공통어가 된다.

동기화 서비스의 구성은 3 단계, 즉 (1) 로컬 폴더와 공동체 폴더 간의 매핑을 정의하는 단계, (2) 무엇이 동기화되는지(예컨대, 누구와 동기화되는지, 어느 서브 세트가 전송되어야 하고 수신되어야 하는지)를 결정하는 동기화 프로파일을 정의하는 단계, 및 (3) 상이한 동기화 프로파일들이 실행되어야 하는 스케쥴 또는 이들을 수동으로 실행하는 스케쥴을 정의하는 단계로 구성된다.

(1) 공동체 폴더-매핑

공동체 폴더 매핑은 개별 머신들 상에 XML 구성 파일로서 저장된다. 각각의 매핑은 다음 스키마를 갖는다.

/mappings/ communityFolder

이 요소는 이 매핑의 대상인 공동체 폴더의 명칭을 정한다. 명칭은 폴더의 신택스 규칙을 따른다.

/mappings/ localFolder

이 요소는 매핑이 변환되는 로컬 폴더의 명칭을 정한다. 이 명칭은 폴더의 신택스 규칙을 따른다. 폴더는 매핑이 유효하도록 이미 존재해야 한다. 이 폴더 내의 항목들은 이 매핑에 대한 동기화를 위해 고려된다.

/mappings/transformations

이 요소는 공동체 폴더에서 로컬 폴더로 그리고 그 역으로 항목들을 변환하는 방법을 정의한다. 존재하지 않거나 비어 있는 경우, 변환은 행해지지 않는다. 구체적으로 이것은 어떠한 ID도 매핑되지 않는다는 것을 의미한다. 이 구성은 주로 폴더의 캐시를 생성하는 데 유용하다.

/mappings/transformation/ mapIDs

이 요소는 공동체 ID들이 다시 사용되는 것이 아니라 새로 생성된 로컬 ID들이 공동체 폴더로부터 매핑된 항목들 모두에 대해 할당될 것을 요구한다. 동기화 실행 시간은 항목들을 이리저리 변환하기 위해 ID 매핑을 유지한다.

/mappings/transformations/ localRoot

이 요소는 공동체 폴더 내의 모든 루트 항목들이 지정된 루트의 자식들이 될 것을 요구한다.

/mappings/ runAs

이 요소는 누구의 권한 하에 이 매핑에 대한 요구들이 처리되는지를 제어한다. 존재하지 않는 경우, 송신자가 가정된다.

/mappings/ runAs /sender

이 요소의 존재는 이 매핑에 대한 메시지의 송신자가 구현되어 그의 신임 하에 요구들이 처리되어야 한다는 것을 지시한다.

(2) 프로파일

동기화 프로파일은 동기화를 개시하는 데 필요한 파라미터들의 종합 세트이다. 이것은 동기화 개시를 위해 SCA에 의해 동기화 실행 시간으로 제공된다. 저장 플랫폼 대 저장 플랫폼 동기화에 대한 동기화 프로파일은 다음 정보를 포함한다.

ㆍ 변경에 대한 소스 및 목표로서 기능하는 로컬 폴더

ㆍ 동기화될 원격 폴더 명칭- 이 폴더는 위에서 정의된 매핑을 통해 원격 파트너로부터 공개되어야 한다.

ㆍ 방향-동기화 서비스는 전송만을, 수신만을, 그리고 전송-수신 동기화를 지원한다.

ㆍ 로컬 필터-어떤 로컬 정보가 원격 파트너에게 전송될지를 선택한다. 로컬 폴더에 대한 저장 플랫폼 질의로서 표현된다.

ㆍ 원격 필터- 원격 파트너로부터 어떤 원격 정보가 검색될지를 선택한다. 공동체 폴더에 대한 저장 플랫폼 질의로서 표현된다.

ㆍ 변환-로컬 포맷에 대해 어떻게 항목을 변환할지를 정의한다.

ㆍ 로컬 보안-원격 엔드포인트로부터 검색된 변경들이 원격 엔드포인트(의인화됨)의 허가 하에 또는 로컬 동기화를 개시하는 사용자의 허가 하에 적용되어야 하는지를 지정한다.

ㆍ 충돌 해결 정책-충돌이 거부, 로그 또는 자동 해결되어야 하는지를 지정한다. 후자의 경우, 어느 충돌 해결자를 이용할지는 물론 그에 대한 구성 파라미 터를 지정한다.

동기화 서비스는 동기화 프로파일들의 간단한 구축을 허용하는 실행시간 CLR 클래스를 제공한다. 프로파일들은 또한 쉬운 저장을 위해 XML 파일들에 대해 일련화될 수 있다(종종 스케쥴과 함께). 그러나, 모든 프로파일이 저장되는 저장 플랫폼 내의 표준 장소는 없으며, SCA는 프로파일을 계속 유지하지 않고 프로파일을 스폿 상에 구축해도 좋다. 동기화를 개시하기 위해 로컬 매핑을 갖출 필요는 없다는 점에 유의한다. 모든 동기화 정보는 프로파일에서 지정될 수 있다. 그러나, 원격 측에 의해 개시되는 동기화 요구에 응답하기 위해서는 매핑이 필요하다.

(3) 스케쥴

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

d) 충돌 처리

동기화 서비스에서의 충돌 처리는 3 단계, 즉 (1) 변경 적용 시간에 발생하 는 충돌 검출 단계-이 단계는 변경이 안전하게 적용될 수 있는지를 판정한다-; (2) 자동 충돌 해결 및 로깅 단계-이 단계 동안(충돌이 검출된 직후 발생함), 충돌이 해결될 수 있는지를 알아 보기 위해 자동 충돌 해결자가 참고되며, 해결될 수 없는 경우, 충돌은 선택적으로 로그된다-; 및 (3) 충돌 검사 및 해결 단계-이 단계는 소정의 충돌이 로그되어 있는 경우에 발생하며, 동기화 세션과 관련 없이 발생하는데, 이때 로그된 충돌들이 해결되어 로그로부터 제거될 수 있다.

(1) 충돌 검출

이 실시예에서, 동기화 서비스는 두 종류의 충돌, 즉 지식 기반 충돌 및 제한 기반 충돌을 검출한다.

(a) 지식 기반 충돌

지식 기반 충돌은 2개의 사본이 동일 변경 단위에 대해 독립적인 변경을 행할 때 발생한다. 2개의 변경은 이들이 서로에 대한 지식 없이 이루어지는 경우 독립적이라고 일컬어지는데, 즉 제1 변경의 버젼은 제2 변경에 대한 지식에 의해 커버되지 않으며, 그 반대의 경우도 그러하다. 동기화 서비스는 전술한 바의 사본의 지식에 기초한 모든 충돌을 자동 검출한다.

충돌을 종종, 변경 단위의 버젼 이력 내의 포크(fork)로 간주하는 것이 도움이 될 수 있다. 변경 단위의 생애에 충돌이 발생하지 않는 경우, 그 버젼 이력은 간단한 체인이며, 즉 각각의 변경은 이전 변경 후에 발생한다. 지식 기반 충돌의 경우, 2개의 변경은 동시에 발생하여, 체인 분할되어 버젼 트리가 되게 한다.

(b) 제한 기반 충돌

독립적인 변경들이 함께 적용될 때 보전 제한을 위반하는 경우가 있다. 예컨대, 동일 디렉토리에 동일 명칭을 가진 파일을 생성하는 2개의 복제는 이러한 충돌을 발생시킬 수 있다.

제한 기반 충돌은 2개의 독립적인 변경(지식 기반 충돌과 똑같이)을 수반하지만, 이들은 동일 변경 단위에 영향을 미치지 않는다. 오히려, 이들은 상이하지만 그 사이에 제한이 존재하는 변경 단위들에 영향을 미친다.

동기화 서비스는 변경 적용시에 제한 위반을 검출하여 제한 기반 충돌을 자동으로 발생시킨다. 제한 기반 충돌의 해결은 대개 제한을 위반하지 않는 방식으로 변경을 수정하는 고객 모드를 요구한다. 동기화 서비스는 이를 행하기 위한 범용 메커니즘을 제공하지 않는다.

(2) 충돌 처리

충돌이 검출된 때, 동기화 서비스는 (동기화 프로파일에서 동기화 개시자에 의해 선택되는) 3가지 동작 중 하나, 즉 변경을 거부하고 이것을 다시 송신자에게 리턴하거나, (2) 충돌을 충돌 로그에 로그하거나, (3) 충돌을 자동으로 해결하는 동작을 취할 수 있다.

변경이 거부되면, 동기화 서비스는 변경이 사본에 도달하지 않는 것처럼 동 작한다. 부정 응답이 발신자에게 전송된다. 이러한 해결 정책은 주로 충돌의 로깅이 가능하지 않은 헤드 없는 사본들(예를 들어, 파일 서버)에 유용하다. 그 대신, 이러한 사본들은 다른 사본들이 충돌을 거절함으로써 충돌을 처리하도록 시킨다.

동기 개시자들은 이들의 동기화 프로파일에 충돌 해결을 구성한다. 동기화 서비스는 다음과 같은 방법으로, 즉 성공할 때까지 하나씩 시도될 충돌 해결자들의 리스트를 지정한 후, 충돌 해결자들을 충돌 타입들에 연관시킴으로써, 즉 갱신-갱신 지식 기반 충돌들을 하나의 해결자로 전송하지만 다른 모든 충돌들을 로그로 전송함으로써 단일 프로파일에 다수의 충돌 해결자를 결합시키는 것을 지원한다.

(a) 자동 충돌 해결

동기화 서비스는 다수의 디폴트 충돌 해결자를 제공한다. 이 리스트는 다음을 포함한다.

ㆍ 로컬 윈(win): 로컬 저장 데이터를 가진 충돌에서의 경우, 들어오는 변경을 무시한다.

ㆍ 원격 윈: 들어오는 변경을 가진 충돌에서의 경우, 로컬 데이터를 무시한다.

ㆍ 최종 작성자 윈: 변경의 타임 스탬프에 기초하여 변경 단위마다 로컬 윈 또는 원격 윈을 선택한다(일반적으로 동기화 서비스는 클럭 값에 의존하지 않는데, 이 충돌 해결자는 이 규칙에 대한 단 하나의 예외이다).

ㆍ 결정론적임: 모든 사본 상에서 동일하도록, 그렇지 않은 경우 무의미한 것을 보장하는 방식으로 위너를 선택하는데, 동기화 서비스의 일 실시예에서는 파트너 ID의 사전 편집 비교를 이용하여 이 기능을 구현한다.

또한, ISV는 그 자신의 충돌 해결자를 구현하고 설치할 수 있다. 고객 충돌 해결자들은 구성 파라미터들을 받아들일 수 있는데, 이 파라미터들은 동기화 프로파일의 충돌 해결 섹션에서 SCA에 의해 지정되어야 한다.

충돌 해결자는 충돌을 처리할 때 (충돌 변경 대신에) 수행되어야 하는 동작들의 리스트를 실행시간으로 리턴한다. 이후, 동기화 서비스는 충돌 처리자가 고려하고 있는 것을 포함하도록 적절히 조정된 원격 지식을 가진 이들 동작들을 적용한다.

해결을 적용하는 동안 다른 충돌이 검출될 수 있다. 이 경우, 새로운 충돌은 원래의 처리를 재개하기 전에 해결되어야 한다.

충돌을 항목의 버젼 이력에서 분기로서 간주할 때, 충돌 해결은 2개의 분기를 단일 포인트를 형성하도록 결합한 연결로서 보여질 수 있다. 따라서, 충돌 해결은 버젼 이력을 DAG로 바꾼다.

(b) 충돌 로깅

충돌 해결자의 매우 특이한 한 종류는 충돌 로거이다. 동기화 서비스는 충돌을 타입 ConflictRecord의 항목으로서 로그한다. 이 레코드는 충돌하고 있는 항목들과 다시 관련된다(항목들 자체가 삭제되지 않은 경우). 각 충돌 레코드는 충 돌을 유발하는 들어오는 변경, 충돌의 타입, 즉 갱신-갱신, 갱신-삭제, 삭제-갱신, 삽입-삽입, 또는 제한, 및 들어오는 변경의 버젼 및 이를 전송하는 사본에 대한 지식을 포함한다. 로그된 충돌들은 후술하는 바와 같이 검사 및 해결에 이용될 수 있다.

(c) 충돌 검사 및 해결

동기화 서비스는 충돌 로그를 검사하고 그 안에 충돌의 해결을 제안하기 위해 애플리케이션에 대한 API를 제공한다. API는 애플리케이션이 모든 충돌, 또는 주어진 항목에 관한 충돌을 열거하는 것을 허용한다. API는 또한 이러한 애플리케이션이 세가지 방법, 즉 (1) 로그된 변경을 수용하고 충돌하는 로컬 변경을 덮어쓰는 원격 윈, (2) 로그된 변경의 충돌하는 부분을 무시하는 로컬 윈, 및 (3) 애플리케이션이 그의 의견에서 충돌을 해결하는 병합을 제안하는 새로운 변경 제안 중 하나로 로그된 충돌을 해결하는 것을 허용한다. 애플리케이션에 의해 충돌이 해결되면, 동기화 서비스는 로그로부터 제거된다.

(d) 사본의 수렴 및 충돌 해결의 전파

복잡한 동기화 시나리오에서, 동일한 충돌이 다수의 사본에서 검출될 수 있다. 이것이 발생할 경우, 여러 가지가 발생할 수 있는데, 즉 (1) 충돌이 하나의 사본에서 해결되고, 이 해결이 다른 사본으로 전송되거나, (2) 충돌이 양 사본에서 자동으로 해결되거나, (3) 충돌이 양 사본에서 수동으로(충돌 검사 API를 통해) 해 결될 수 있다.

수렴을 보장하기 위해, 동기화 서비스는 충돌 해결을 다른 사본으로 전송한다. 충돌을 해결하는 변경이 사본에 도달할 때, 동기화 서비스는 로그에서 이 갱신에 의해 해결되는 임의의 충돌 레코드들을 찾아 이들을 제거한다. 이러한 의미에서, 하나의 사본에서의 충돌 해결은 모든 다른 사본에 결합된다.

동일 충돌에 대해 상이한 사본들에 의해 상이한 위너들이 선택되는 경우, 동기화 서비스는 충돌 해결을 결합하는 원리를 적용하여 2개의 해결 중 하나를 나머지에 대해 자동으로 승리하도록 선택한다. 위너는 항상 동일한 결과를 생성하는 것을 보장하는 결정론적 방식으로 선택된다(일 실시예는 사본 ID 사전 편집 비교를 이용한다).

동일 충돌에 대해 상이한 사본들에 의해 상이한 "새로운 변경들"이 제안되는 경우, 동기화 서비스는 이 새로운 충돌을 특수 충돌로서 취급하고, 충돌 로거를 이용하여 이 새로운 충돌이 다른 사본들로 전파되는 것을 방지한다. 이러한 상황은 일반적으로 수동 충돌 해결에서 발생한다.

2. 비저장 플랫폼 데이터 저장소에 대한 동기화

본 발명의 저장 플랫폼의 다른 양태에 따르면, 저장 플랫폼은 저장 플랫폼이 마이크로소프트 익스체인지, AD, 핫메일 등과 같은 레거시 시스템에 동기화하는 것을 허용하는 동기화 어댑터를 구현하기 위해 ISV에 대한 아키텍처를 제공한다. 동기 어댑터는 후술하는 바와 같이 동기화 서비스에 의해 제공되는 많은 동기화 서비 스로부터 이익을 얻는다.

그 명칭에도 불구하고, 동기화 어댑터는 소정의 저장 플랫폼 아키텍처 내로의 플러그-인으로서 구현될 필요는 없다. 원할 경우, "동기 어댑터"는 단지 동기화 서비스 실행시간 인터페이스를 이용하여 변경 열거 및 적용과 같은 서비스를 얻는 임의의 애플리케이션일 수 있다.

다른 것들이 주어진 백엔드에 대한 동기화를 구성하고 실행하는 것을 보다 간단하게 하기 위해, 동기 어댑터 작성자는 전술한 바와 같이 동기화 프로파일이 주어질 때 동기화를 실행하는 표준 동기화 어댑터 인터페이스를 노출시키도록 권장된다. 프로파일은 구성 정보를 어댑터에 제공하며, 어댑터는 그 중 일부를 실행 시간에 전달하여 실행시간 서비스(예컨대, 폴더 동기화)를 제어한다.

a) 동기화 서비스

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

(1) 변경 열거

동기화 서비스에 의해 유지되는 변경 추적 데이터에 기초하여, 변경 열거는 동기 어댑터가 데이터 저장소 폴더에 대해 이 파트너와의 지난번 동기화가 시도된 후에 발생한 변경들을 쉽게 열거하는 것을 허용한다.

변경들은 최종 동기화에 대한 정보를 표현하는 불투명 구조인 "앵커"의 개념에 기초하여 열거된다. 앵커는 이전 섹션에서 설명한 바와 같이 저장 플랫폼 지식의 형태를 갖는다. 변경 열거 서비스를 이용하는 동기 어댑터들은 2개의 넓은 카테고리, 즉 "저장된 앵커"를 사용하는 어댑터들 및 "제공된 앵커"를 사용하는 어댑터들로 분류된다.

그 차이는 최종 동기화에 대한 정보가 클라이언트에 저장되는지, 또는 서버에 저장되는지에 기초한다. 종종, 어댑터가 클라이언트 상에 이 정보를 저장하는 것이 더 쉬우며, 백엔드는 종종 이 정보를 편리하게 저장할 수 없다. 한편, 다수의 클라이언트가 동일한 백엔드에 동기화할 경우, 클라이언트 상에 이 정보를 저장하는 것은 비효율적이며, 몇몇 경우에는 옳지 않은데, 이는 하나의 클라이언트가 다른 클라이언트가 이미 서버에게로 푸시한 변경을 알지 못하게 한다. 어댑터가 서버에 저장된 앵커를 사용하기를 원하는 경우, 어댑터는 이 앵커를 변경 열거시에 저장 플랫폼에 제공할 필요가 있다.

저장 플랫폼이 앵커를 (로컬 또는 원격 저장소에 대해) 유지하기 위하여, 저장 플랫폼은 서버에서 성공적으로 적용된 변경들을 알 필요가 있다. 이 변경들만이 앵커에 포함될 수 있다. 변경 열거 동안, 동기화 어댑터는 어느 변경들이 성공적으로 적용되었는지를 보고하기 위해 확인 인터페이스를 사용한다. 동기화의 종료시, 제공된 앵커를 사용하는 어댑터들은 새로운 앵커(성공적으로 적용된 변경들 모두를 포함함)를 판독하여 이를 그들의 백엔드로 전송해야 한다.

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

(2) 변경 적용

변경 적용은 동기화 어댑터들이 그들의 백엔드로부터 수신되는 변경들을 로컬 저장 플랫폼에 적용하는 것을 허용한다. 어댑터들은 변경들을 저장 플랫폼 스키마로 변환할 것으로 예상된다. 도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타낸다.

변경 적용의 주요 기능은 충돌을 자동으로 검출하는 것이다. 저장 플랫폼-저장 플랫폼 동기화의 경우에서와 같이, 충돌은 2개의 중복 변경이 서로에 대한 지식 없이 행해지는 것으로서 정의된다. 어댑터들이 변경 적용을 이용할 때, 이들은 충돌 검출 수행과 관련될 앵커를 지정해야 한다. 변경 적용은 어댑터의 지식에 의해 커버되지 않는 중복 로컬 변경이 검출되는 경우에 충돌을 발생시킨다. 변경 열거와 유사하게, 어댑터들은 저장 또는 제공된 앵커를 사용할 수 있다. 변경 적용은 어댑터 특정 메타데이터의 효율적인 저장을 지원한다. 이러한 데이터는 어댑터에 의해 적용되고 있는 변경들에 첨부될 수 있으며, 동기화 서비스에 의해 저장될 수 있다. 데이터는 다음 변경 열거시에 리턴될 수 있다.

(3) 충돌 해결

전술한 충돌 해결 메커니즘(로깅 및 자동 해결 옵션)은 또한 동기화 어댑터들이 이용할 수 있다. 동기화 어댑터들은 변경을 적용할 때 충돌 해결을 위한 정책을 지정할 수 있다. 지정된 경우, 충돌들은 지정된 충돌 처리자로 전달되어 (가능한 경우) 해결될 수 있다. 충돌들은 또한 로그될 수 있다. 어댑터는 로컬 변경을 백엔드에 적용하려고 시도할 때 충돌을 검출할 수 있다. 이 경우, 어댑터는 여전히 정책에 따라 해결되도록 동기화 실행시간에 충돌을 전달할 수 있다. 또한, 동기화 어댑터들은 동기화 서비스에 의해 검출된 임의의 충돌들이 처리를 위해 그들에게 전송될 것을 요구할 수 있다. 이것은 특히 백엔드가 충돌을 저장하거나 해결할 수 있는 경우에 편리하다.

b) 어댑터 구현

몇몇 어댑터들은 단지 실행시간 인터페이스를 이용하는 애플리케이션이지만, 어댑터들은 표준 어댑터 인터페이스를 구현하도록 권장된다. 이들 인터페이스는 동기화 제어 애플리케이션들이 어댑터가 주어진 동기화 프로파일에 따라 동기화를 수행할 것을 요구하고, 진행중인 동기화를 취소하고, 진행중인 동기화에 대한 진행 보고를 수신하는 것을 허용한다.

3. 보안

동기화 서비스는 저장 플랫폼에 의해 구현되는 보안 모델에 가능한 적게 도입하려고 노력한다. 동기화에 대한 새로운 권리를 정의하기보다는 기존 권리를 사용한다. 구체적으로는 다음과 같다.

ㆍ 데이터 저장소 항목을 판독할 수 있는 누구라고 그 항목에 대한 변경을 열거할 수 있다.

ㆍ 데이터 저장소 항목에 기입할 수 있는 누구라도 그 항목에 변경을 적용할 있다.

ㆍ 데이터 저장소 항목을 확장할 수 있는 누구라도 동기화 메타데이터를 그 항목과 연관시킬 수 있다.

동기화 서비스는 보안 저자 정보를 유지하지 않는다. 사용자 U에 의해 사본 A에 변경이 행해져 사본 B로 전송될 때, 변경이 A에서(또는 U에 의해) 최초로 이루어졌다는 사실은 없어진다. B가 이 변경을 사본 C로 전송하는 경우, 이것은 A의 권한이 아니라 B의 권한 하에 이루어진다. 이것은 다음과 같은 제한을 유발하는데, 즉 사본이 항목에 대해 그 자신의 변경을 만들 권한이 없는 경우, 이 사본은 다른 사본들에 의해 만들어진 변경을 전송할 수 없다.

동기화 서비스가 개시될 때, 이것은 동기화 제어 애플리케이션에 의해 행해진다. 동기화 서비스는 SCA의 식별자를 의인화하며, 이 식별자 하에 모든 동작(로컬 및 원격 양자)을 수행한다. 예를 들어, 사용자 U는 로컬 동기화 서비스가 사용자 U가 판독 액세스하지 않은 항목들에 대해 원격 저장 플랫폼으로부터 변경을 검색하게 할 수 없다는 점에 유의한다.

4. 관리성

사본들의 분산 공동체의 모니터링은 복잡한 문제이다. 동기화 서비스는 사본들의 상태에 대한 정보를 수집하고 분배하기 위해 "스위프" 알고리즘을 사용할 수 있다. 스위프 알고리즘의 속성들은 구성된 모든 사본들에 대한 정보가 결국 수집되고, 실패(무응답) 사본들이 검출되는 것을 보장한다.

이러한 공동체 전체 모니터링 정보는 모든 사본에서 이용 가능하게 된다. 모니터링 도구는 임의의 선택된 사본에서 실행되어 이 모니터링 정보를 검사하고 관리적 결정을 행할 수 있다. 영향을 받은 사본들에서 직접 임의의 구성 변경이 행해져야 한다.

B. 동기화 API 개요

점차 분산되는 디지털 세계에서, 개인 및 작업 그룹은 종종 다양한 상이한 장치 및 위치에 정보 및 데이터를 저장한다. 이것은 분리되고, 종종 상이하고, 항상 동기화되는 데이터 저장소들에 정보를 최소한의 사용자 중재로 유지할 수 있는 데이터 동기화 서비스의 개발을 지원해왔다.

본 명세서의 섹션 II에 설명된 풍부한 저장 플랫폼(a.k.a, "WinFS)의 일부인 본 발명의 동기화 플랫폼은 다음의 3가지 주요 대상을 다룬다.

ㆍ 애플리케이션 및 서비스가 상이한 "WinFS" 저장소들 사이에서 데이터를 동기화하는 것을 허용한다.

ㆍ 개발자들이 "WinFS" 및 non-"WinFS" 저장소들 사이에서 데이터를 동기화하기 위한 풍부한 솔루션을 구축하는 것을 가능하게 한다.

ㆍ 개발자들에게 동기화 사용자 경험을 주문화하기 위한 적절한 인터페이스를 제공한다.

1. 일반 용어법

후술하는 섹션 III.B의 설명에 관한 보다 세련된 몇몇 정의 및 주요 개념은 다음과 같다.

동기화 사본: 대부분의 애플리케이션은 WinFS 저장소 내의 항목들의 소정의 서브세트에 대한 변경을 추적, 열거 및 동기화하는 데에만 관련이 있다. 동기화 동작에 참여하는 항목들의 세트는 동기화 사본이라 한다. 사본은 주어진 WinFS 포함 계층 구조(대개 폴더 항목을 루트로 함) 내에 포함된 항목들로 정의된다. 모든 동기화 서비스는 주어진 사본과 관련하여 수행된다. WinFS 동기화는 사본들을 정의, 관리 및 제거하는 메커니즘을 제공한다. 모든 사본은 주어진 WinFS 저장소 내에서 자신을 고유하게 식별하는 GUID 식별자를 갖는다.

동기화 파트너: 동기화 파트너는 WinFS 항목, 확장 및 관계 상에서 변경에 영향을 줄 수 있는 엔티티로서 정의된다. 따라서, 모든 WinFS 저장소는 동기 파트너라고 할 수 있다. non-WinFS 저장소와 동기화될 때, 외부 데이터 저장소(EDS)도 동기 파트너라고 할 수 있다. 모든 파트너는 자신을 고유하게 식별하는 GUID 식별자를 갖는다.

동기화 공동체: 동기화 공동체는 피어 대 피어 동기화 동작에 의한 동기화시에 유지되는 사본들의 집합으로서 정의된다. 이들 사본은 모두 동일한 WinFS 저장소, 상이한 WinFS 저장소, 또는 심지어 non-WinFS 저장소 상의 가상 사본들인 목록 자체에 있을 수 있다. WinFS 동기화는, 특히 공동체 내의 동기화 동작들만이 WinFS 동기화 서비스(WinFS 어댑터)를 통하는 경우에는 공동체에 대한 임의의 특정 토폴로지를 규정하거나 지정하지 않는다. 동기화 어댑터들(아래에 정의됨)은 그들 자신의 토폴로지 제한을 도입할 수 있다.

변경 추적, 변경 단위 및 버젼: 모든 WinFS 저장소는 모든 로컬 WinFS 항목, 확장 및 관계에 대한 변경을 추적한다. 변경은 스키마에 정의된 변경 단위 입도의 레벨에서 추적된다. 임의의 항목, 확장 및 관계 타입의 최상위 레벨 필드들은 스키마 설계자에 의해 변경 단위로 세분될 수 있는데, 최소 입도가 하나의 최상위 레벨 필드가 된다. 변경 추적을 위해, 모든 변경 단위에는 버젼이 할당되며, 버젼은 동기화 파트너 id 및 버젼 번호의 쌍이다(버젼 번호는 파트너 특정 단조 증가 번호이다). 버젼들은 변경이 저장소에서 로컬하게 발생하거나 변경이 다른 사본으로부터 얻어질 때 갱신된다.

동기화 지식: 지식은 임의의 시간에 주어진 동기화 사본의 상태를 나타내는데, 즉 주어진 사본이 로컬하게 또는 다른 사본들로부터 인식하는 모든 변경에 대한 메타데이터를 캡슐화한다. WinFS 동기화는 동기화 동작들에서 동기화 사본들에 대한 지식을 유지하고 갱신한다. 중요한 유의점은 지식 표현이 지식이 저장되어 있는 특정 사본에 대해서가 아니라 전체 공동체에 관하여 해석되는 것을 허용한다 는 점이다.

동기화 어댑터: 동기화 어댑터는 동기화 실행시간 API를 통해 WinFS 동기화 서비스에 액세스하고 WinFS 데이터의 non-WinFS 데이터 저장소에 대한 동기화를 가능하게 하는 관리형 코드 애플리케이션이다. 시나리오의 요건에 따라, WinFS 데이터의 어느 서브세트가, 그리고 어떤 WinFS 데이터 타입들이 동기화되어야 하는지에 관해서는 어댑터 개발자에게 맡겨진다. 어댑터는 EDS와의 통신, WinFS 스키마의 EDS 지원 스키마로의/로부터의 변환, 및 그 자신의 구성 및 메타데이터의 관리를 담당한다. 어댑터는 일반 구성을 이용하여 WinFS 동기화 팀에 의해 제공되는 어댑터들에 대한 기반 구조를 제어할 수 있게 WinFS 동기화 어댑터 API를 구현하도록 강하게 권장된다. 보다 상세한 것은 WinFS 동기화 어댑터 API[SADP] 사양 및 WinFS 동기화 제어기 API[SCTRL] 사양을 참조한다.

WinFS 데이터를 외부 non-WinFS 저장소에 동기화하고 WinFS 포맷의 지식을 생성하거나 유지할 수 없는 어댑터들에 대해, WinFS 동기화는 후속 변경 열거 또는 적용 동작에 사용될 수 있는 원격 지식을 얻기 위한 서비스를 제공한다. 백엔드 저장소의 능력에 따라, 어댑터는 원격 지식을 백엔드 상에 또는 로컬 WinFS 저장소 상에 저장하기를 원할 수 있다.

간략화를 위해, 동기화 "사본"은 단일 논리 위치에 존재하는 "WinFS" 저장소 내의 한 세트의 데이터를 표현하는 구조인 반면, non-"WinFS" 저장소 상의 데이터는 "데이터 소스"라고 하며, 일반적으로 어댑터의 사용을 필요로 한다.

원격 지식: 주어진 동기화 사본이 다른 사본으로부터 변경을 얻기를 원할 때 , 이 사본은 그 자신의 지식을 다른 사본이 변경들을 열거하는 기준선으로서 제공한다. 마찬가지로, 주어진 사본이 다른 사본으로 변경을 전송하기를 원할 때, 이 사본은 그 자신의 지식을 충돌을 검출하기 위해 다른 사본에 의해 사용될 수 있는 기준선으로서 제공한다. 동기 변경 열거 및 적용 동안 제공되는 이러한 다른 사본에 대한 지식은 원격 지식이라 한다.

2. 동기화 API 원리

소정의 실시예에서, 동기화 API는 2개의 부분, 즉 동기화 구성 API 및 동기화 제어기 API로 분리된다. 동기화 구성 API는 애플리케이션이 동기화를 구성하고 2개의 사본 사이의 특정 동기화 세션에 대한 파라미터들을 지정할 수 있게 한다. 주어진 동기화 세션에 대해, 구성 파라미터들은 동기화될 항목들의 세트, 동기화의 타입(일방향 또는 양방향), 원격 데이터 저장소에 대한 정보 및 충돌 해결 정책을 포함한다. 동기화 제어기 API는 동기화 세션을 개시하고, 동기화를 취소하며, 진행중인 동기화에 대한 진행 및 에러 정보를 수신한다. 더욱이, 동기화가 미리 정해진 스케쥴에 따라 수행될 필요가 있는 특정 실시예에서, 이러한 시스템은 스케쥴링을 주문화하기 위한 스케쥴링 메커니즘을 포함할 수 있다.

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

그러나, 본 발명의 소정 실시예에서, WinFS 데이터 저장소를 다른 WinFS 데이터 저장소에 동기화할 때, 동기화 어댑터는 WinFS 대 WinFS 동기화 서비스가 하드웨어/소프트웨어 인터페이스 시스템 내에 통합되는 경우 필요하지 않을 수 있다. 어느 경우에나, 이러한 여러 실시예는 WinFS 대 WinFS 및 동기화 어댑터 솔루션들 양자에 대해 한 세트의 동기화 서비스를 제공하는데, 이는 다음을 포함한다.

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

ㆍ 주어진 과거 상태 이후의 효율적인 증분식 변경 열거에 대한 지원

ㆍ WinFS에 대한 외부 변경의 적용

ㆍ 변경 적용 동안의 충돌 처리.

공통 데이터 저장소의 3개의 인스턴스 및 이들을 동기화하기 위한 컴포넌트들을 나타내는 도 36을 참조한다. 제1 시스템(3602)은 WinFS 대 WinFS 동기화 서비스(3622) 및 WinFS 대 non-WinFS 동기화를 위해 동기화 API(3652)를 사용할 수 있도록 노출시키는(3646) 코어 동기화 서비스(3624)를 포함하는 WinFS 데이터 저장소(3612)를 갖는다. 제1 시스템(3602)과 유사하게, 제2 시스템(3604)은 WinFS 대 WinFS 동기화 서비스(3632) 및 WinFS 대 non-WinFS 동기화를 위해 동기 API(3652)를 이용할 수 있도록 노출시키는(3646) 코어 동기화 서비스(3634)를 포함하는 WinFS 데이터 저장소(3614)를 갖는다. 제1 시스템(3602) 및 제2 시스템(3604)은 그들 각각의 WinFS 대 WinFS 동기화 서비스(3622, 3632)를 통해 동기화된다(3642). WinFS 시스템이 아닌 제3 시스템(3606)은 WinFS 사본들을 가진 동기화 공동체 내에 데이터 소스를 유지하기 위해 WinFS 동기화를 이용하는 애플리케이션(3666)을 갖는다. 이 애플리케이션은 WinFS 대 WinFS 동기화 서비스(3622)(이것이 그 자체를 WinFS 데이터 저장소로서 가상화할 수 있는 경우) 또는 동기화 API(3652)와 인터페이스하는 동기화 어댑터(3662)를 통해 WinFS 데이터 저장소(3612)와 직접 인터페이스하는(3644) WinFS 동기화 구성/제어 서비스(3664)를 이용할 수 있다.

이 도면에 도시된 바와 같이, 제1 시스템(3602)은 제2 시스템(3604) 및 제3 시스템(3606) 양자를 인식하고 직접 동기화된다. 그러나, 제2 시스템(3604) 및 제3 시스템(3606) 양자는 서로를 알지 못하며, 따라서 그들의 변경을 서로 직접 동기화하지 못하지만, 대신에 하나의 시스템에서 발생하는 변경은 제1 시스템(3602)을 통해 전파되어야 한다.

C. 동기화 API 서비스

본 발명의 여러 실시예는 2개의 기본 서비스, 즉 변경 열거 및 변경 적용을 포함하는 동기화 서비스와 관련된다.

1. 변경 열거

전술한 바와 같이, 변경 열거는 동기화 어댑터가 데이터 저장소 폴더에 대해 이 파트너와 최종 동기화가 시도된 이후 발생한 변경들을 동기화 서비스에 의해 유지되는 변경 추적 데이터에 기초하여 쉽게 열거하는 것을 허용한다. 변경 열거와 관련하여, 본 발명의 여러 실시예는 다음과 관련된다.

ㆍ 지정된 지식 인스턴스에 대해, 주어진 사본 내의 항목, 확장 및 관계에 대한 변경들의 효율적인 열거

ㆍ WinFS 스키마에 지정된 변경 단위 입도의 레벨에서의 변경들의 열거

ㆍ 복합 항목들에 관하여 열거된 변경들의 그룹화. 복합 항목은 항목, 모든 그의 확장, 항목에 대한 모든 유지 관계 및 그의 삽입 항목들에 대응하는 모든 복합 항목으로 구성된다. 항목들 사이의 참조 관계에 대한 변경은 개별적으로 열거된다.

ㆍ 변경 열거시의 배치화. 배치의 입도는 복합 항목 또는 관계 변경(참조 관계에 대해)이다.

ㆍ 변경 열거 동안 사본 내의 항목들에 대한 필터의 지정. 예를 들어, 사본은 주어진 폴더 내의 모든 항목으로 구성되지만, 특정 변경 열거에 대해 애플리케이션은 첫 번째 명칭이 'A'로 시작되는 모든 연락 항목들에 대한 변경만을 열거하기를 원한다(이러한 지원은 B 이정표 뒤에 추가된다).

ㆍ 열거된 변경들에 대한 원격 지식을, 지식 내에 동기화에 실패한 것으로 개별 변경 단위들(또는 전체 항목, 확장 또는 관계)을 기록할 수 있는 능력과 함께 이용하여, 이들이 다음 번에 다시 열거될 수 있도록 한다.

ㆍ 변경 열거 동안 변경들과 함께 메타데이터를 리턴함으로써 WinFS 동기화 메타데이터를 이해할 수 있는 향상된 어댑터의 이용

2. 변경 적용

전술한 바와 같이, 변경 적용은 동기 어댑터들이 그들의 백엔드로부터 수신한 변경들을 로컬 저장 플랫폼에 적용하는 것을 허용하는데, 이는 어댑터들이 변경을 저장 플랫폼 스키마로 변환할 것으로 예상되기 때문이다. 변경 적용과 관련하여, 본 발명의 여러 실시예는 다음과 관련된다.

ㆍ 대응하는 갱신들을 가진 다른 사본들(또는 non-WinFS 저장소)에서 WinFS 변경 메타데이터로의 증분식 변경의 적용

ㆍ 변경 단위 입도에서의 변경 적용시의 충돌의 검출

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

ㆍ 다음 변경 열거 동작 동안 애플리케이션 제공 변경들의 "반사"를 방지하기 위한 변경 적용 동안의 원격 지식의 갱신

ㆍ 변경들과 함께 WinFS 동기화 메타데이터를 이해하고 제공할 수 있는 향상된 어댑터의 이용.

3 샘플 코드

다음은 FOO 동기화 어댑터가 어떻게 동기화 실행시간과 상호작용하는지에 대한 코드 샘플이다(여기서, 모든 어댑터 특정 함수들 앞에는 FOO가 첨부된다):

4. API 동기화의 방법

본 발명의 일 실시예에서, WinFS 저장소와 non-WinFS 저장소 사이의 동기화는 WinFS 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 노출되는 동기화 API를 통해 달성될 수 있다.

일 실시예에서, 모든 동기화 어댑터는 이들이 일관되게 전개, 초기화 및 제어될 수 있도록 동기화 어댑터 API, 공통 언어 실행시간(CLR) 관리형 API를 구현하도록 요구된다. 어댑터 API는 다음을 제공한다.

ㆍ 어댑터를 하드웨어/소프트웨어 인터페이스 시스템 동기화 프레임워크에 등록하기 위한 표준 메커니즘

ㆍ 어댑터들이 그들의 능력 및 어댑터를 초기화하는 데 필요한 구성 정보의 타입을 선언할 수 있는 표준 메커니즘

ㆍ 초기화 정보를 어댑터에 전달하기 위한 표준 메커니즘

ㆍ 어댑터들이 동기화를 호출하는 애플리케이션으로 진행 상태를 보고하기 위한 메커니즘

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

ㆍ 진행중인 동기화 동작의 최소를 요구하기 위한 메커니즘

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

ㆍ 보안 목적. 어댑터는 소정의 프로세스 또는 서비스의 프로세스 공간에서 실행되어야 한다.

ㆍ 어댑터는 호출 애플리케이션으로부터의 요구를 처리하는 것에 더하여 다른 소스로부터의 요구, 예를 들어 들어오는 네트워크 요구를 처리해야 한다.

도 37을 참조하면, 본 발명의 일 실시예는 상태가 어떻게 계산되는지, 또는 그와 관련된 메타데이터가 어떻게 교환되는지를 알지 못하는 단순한 어댑터를 가정한다. 이 실시예에서, 동기화는 사본에 의해, 이 사본이 동기화하기를 원하는 데이터 소스와 관련하여, 먼저 단계 3702에서 사본이 상기 데이터 소스와 최종 동기화된 후 어떠한 변경이 발생했는지를 검출함으로써 달성되며, 이후 사본은 최종 동기화 이후에 발생한 증분식 변경을 그의 현재 상태 정보에 기초하여 전송하며, 이 현재 상태 정보 및 증분식 변경은 어댑터를 통해 데이터 소스로 전송된다. 단계 3704에서, 어댑터는 이전 단계에서 사본으로부터 변경 데이터를 수신한 때 가능한 한 데이터 소스에 대한 많은 변경을 행하고, 어느 변경이 성공적이고 어느 변경이 실패했는지를 추적하며, 성공 및 실패 정보를 (사본의) WinFS로 전송한다. 사본의 하드웨어/소프트웨어 인터페이스 시스템(WinFS)은 단계 3706에서, 사본으로부터 성공 및 실패 정보를 수신한 후 데이터 소스에 대한 새로운 상태 정보를 계산하고, 이 정보를 그의 사본에 의한 미래의 사용을 위해 저장하며, 이 새로운 상태 정보를 데이터 소스로, 즉 어댑터에 의한 저장 및 후속 사용을 위해 어댑터로 전송한다.

D. 동기화 스키마의 추가 양태

다음은 본 발명의 다양한 실시예에서 동기화 스키마의 추가(또는 보다 특정 한) 양태들이다.

ㆍ 각각의 사본은 데이터 저장소의 전체로부터 정의된 데이터의 동기화 서브세트, 즉 다수의 인스턴스를 가진 데이터 슬라이스이다.

ㆍ 충돌 해결 정책은 각각의 사본(및 어댑터/데이터 소스 조합)에 의해 개별적으로 처리되는데, 즉 각각의 사본은 그 자신의 기준 및 충돌 해결 스키마에 기초하여 충돌을 해결할 수 있다. 더욱이, 데이터 저장소의 각각의 인스턴스의 차이가 발생하여 추가적인 미래의 충돌을 유발할 수 있지만, 갱신된 상태 정보에 반영된 바와 같은 충돌들의 증분식 및 순차 열거는 갱신 상태 정보를 수신하는 다른 사본들에게는 보이지 않는다.

ㆍ 동기화 스키마의 루트에는 고유 ID를 갖는 루트 폴더(사실상 루트 항목)를 정의하는 기본 타입, 멤버으로 있는 동기화 공동체에 대한 ID, 및 특정 사본에 대해 필요하거나 바람직한 모든 필터 및 다른 요소를 구비한 사본이 존재한다.

ㆍ 각각의 사본의 매핑은 사본 내에 유지되며, 이에 따라 임의의 특정 사본에 대한 매핑은 이 사본이 알지 못하는 다른 사본들로 제한된다. 이러한 매핑은 전체 동기화 공동체의 서브세트만을 포함할 수 있지만, 상기 사본에 대한 변경은 여전히 공유 사본들을 통해 (임의의 특정 사본은 알지 못하는 사본과 어떤 다른 사본들을 공유하고 있는지를 알지 못하지만) 전체 동기화 공동체로 전파된다.

ㆍ 동기화 스키마는 모든 사본들이 이용할 수 있는 미리 정의된 복수의 충돌 처리자는 물론, 사용자/개발자 정의 고객 충돌 처리자의 능력을 포함한다. 스키마는 또한 3개의 특수 "충돌 해결자", 즉 (a) 예컨대 (i) 두 곳에서 동일한 변경 단 위가 변경된 때 처리하는 방법, (ii) 변경 단위가 한 곳에서는 변경되었지만 다른 곳에서는 삭제된 때 처리하는 방법, 및 (iii) 2개의 상이한 변경 단위가 두 다른 곳에서 동일 명칭을 가질 때 처리하는 방법에 기초하여 상이한 방식으로 상이한 충돌을 해결하는 충돌 "필터", (b) 충돌 "해결자 리스트"-이 리스트의 각 요소는 충돌이 성공적으로 해결될 때까지 순차적으로 시도될 일련의 동작을 지정한다-, 및 (c) 충돌을 추적하지만 사용자의 중재 없이는 더 이상의 동작을 취하지 않는 "무동작(do-nothing)" 로그를 포함할 수 있다.

ㆍ 사본들의 동기화 스키마 및 사용은 진정한 분산형 피어 대 피어 멀티 마스터 동기화 공동체를 가능하게 한다. 더욱이, 동기화 공동체 타입을 존재하지 않지만, 동기화 공동체는 단지 사본들 자체의 공동체 필드 내의 값으로서 존재한다.

ㆍ 모든 사본은 증분식 변경 열거를 추적하고 동기화 공동체 내에 공지된 다른 사본들에 대한 상태 정보를 저장하기 위한 그 자신의 메타데이터를 갖는다.

ㆍ 변경 단위들은 파트너 키 플러스 파트너 변경 번호를 포함하는 버젼; 각각의 변경 단위에 대한 항목/확장/관계 버젼; 사본이 동기화 공동체로부터 보거나 수신한 변경에 관한 지식; GUID 및 로컬 ID 구성; 및 삭제를 위해 참조 관계 상에 저장된 GUID를 포함하는 그들 자신의 메타데이터를 갖는다.

IV. 결론

전술한 바와 같이, 본 발명은 데이터의 체계화, 검색 및 공유를 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 기존의 파일 시스템 및 데이터베 이스 시스템을 넘어 데이터 저장의 개념을 확장하고 넓히며, 구조화되거나, 구조화되지 않거나, 관계형(테이블) 데이터와 같은 반 구조화된 데이터, XML 및 항목이라고 하는 새로운 형태의 데이터를 포함하는 모든 타입의 데이터에 대한 저장소가 되도록 설계된다. 본 발명의 저장 플랫폼은 그의 일반 저장 기초 및 스키마화된 데이터를 통해 소비자들, 지식 노동자들 및 기업들을 위해 보다 효율적인 애플리케이션 개발을 가능하게 한다. 저장 플랫폼은 그의 데이터 모델에 고유한 능력을 이용할 수 있게 할 뿐만 아니라 기존 파일 시스템 및 데이터베이스 액세스 방법을 수용하고 확장하는 풍부하고 확장 가능한 애플리케이션 프로그래밍 인터페이스를 제공한다. 본 발명의 넓은 발명적 개념을 벗어나지 않고 전술한 실시예들에 대한 변경이 이루어질 수 있다는 것을 이해해야 한다. 따라서, 본 발명은 개시된 특정 실시예들로 제한되는 것이 아니라, 첨부된 청구범위에 의해 정의되는 발명의 사상 및 범위 내에 있는 모든 수정을 커버하는 것으로 의도된다.

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

Claims (30)

1. 프로세서 및 컴퓨터 판독가능 저장 매체를 포함하는 저장 플랫폼 시스템으로서,

   운영 체제(operating system)를 위한 명령어들 - 상기 운영 체제는 커널을 포함하고, 상기 커널은 파일 시스템을 인캡슐레이트(encapsulates)하는 데이터베이스 운영 프로그램을 포함하고, 상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램은 데이터를 파일 스트림들로서 상기 파일 시스템에 저장하고, 상기 파일 스트림들에 대한 메타데이터를 포함하는 아이템들을 생성하고, 상기 아이템들을 상기 데이터베이스 운영 프로그램에 저장하도록 구성되고, 상기 데이터베이스 운영 프로그램은 베이스 스키마(base schema) 및 상기 베이스 스키마를 상기 데이터에 대한 스키마를 정의하기 위해 확장시키고, 상기 데이터를 상기 데이터에 대한 스키마에 기초하여 프로그램가능하도록 정의된(programmably defined) 변경 단위들로 분할하도록 구성된 메커니즘을 포함하고, 변경 단위는 상기 파일 시스템과 통합된 상기 데이터베이스 운영 프로그램에 의해 개별적으로 추적되는 스키마의 가장 작은 부분(smallest piece)이고, 변경 단위의 크기는 조정가능함 -;

   을 포함하고,

   상기 데이터베이스 운영 프로그램은 비동기적 원격 컴퓨터 시스템(non-synch-aware remote computer system)에 저장된 파일들에 대한 상태 정보를 생성하고 저장하도록 구성되며, 상기 상태 정보는 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 변경 정보를 포함하고, 상기 비동기적 원격 컴퓨터 시스템은 상기 프로세서 상에서 실행되는 동기화 서브시스템과 호환될 수 있는 동기화인 동기화 서브시스템을 포함하지 않으며,

   상기 운영 체제는 상기 데이터베이스 운영 프로그램에 저장된 아이템들에 대한 상태 정보를 상기 비동기적 원격 컴퓨터 시스템에 저장된 대응하는 파일들에 대한 상태 정보와 비교하도록 구성되는 상기 동기화 서브시스템을 더 포함하고;

   상기 동기화 서브시스템은 또한 상기 비교에 기초하여 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들 중 어떤 파일들이 업데이트가 요구되는지 판정하도록 구성되며,

   상기 동기화 서브시스템은 또한 아이템들을 상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅(formatted)된 파일들로 변환하도록 구성되며,

   상기 동기화 서브시스템은 또한 상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅된 파일들을 상기 비동기적 원격 컴퓨터 시스템으로 전송하도록 구성되며,

   상기 동기화 서브시스템은 또한 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 업데이트하도록 구성되며,

   상기 비동기적 원격 컴퓨터 시스템은 상기 파일들을 수신하여 상기 파일들을 파일 시스템에 저장하도록 구성된, 저장 플랫폼 시스템.
2. 제1항에 있어서,

   상기 동기화 서브시스템은 동기화 동작 중 데이터 저장소의 전체 데이터 중에서 서브세트의 데이터만을 동기화하는, 저장 플랫폼 시스템.
3. 제1항에 있어서,

   상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램을 동작시키는 명령어들은 커널 모드 동안 실행되도록 구성되는, 저장 플랫폼 시스템.
4. 제3항에 있어서,

   상기 운영 체제는 커널 모드 동안 실행되도록 구성된 애플리케이션 프로그램 인터페이스를 더 포함하고, 상기 애플리케이션 프로그램 인터페이스는 상기 데이터베이스 운영 프로그램에 저장된 상기 아이템들을 상기 운영 체제의 사용자 모드에서 실행되는 애플리케이션들에 노출시키도록 구성되는, 저장 플랫폼 시스템.
5. 제1항에 있어서,

   상기 동기화 서브시스템은 상기 비동기적 원격 컴퓨터 시스템에 독립적인 변경들을 동기화하도록 구성되는, 저장 플랫폼 시스템.
6. 제1항에 있어서,

   동기화 시의 충돌들이 자동으로 검출되고, 소정의 판정 가능 기준에 기초하여 해결되는, 저장 플랫폼 시스템.
7. 제6항에 있어서,

   상기 충돌들 중 일부는 최종 사용자에 의한 수동 해결을 위해 로깅(logging)됨으로써 해결되는, 저장 플랫폼 시스템.
8. 제1항에 있어서,

   상기 동기화 서브시스템은 동기화 파트너와의 이전 동기화들의 상태를 추적하여, 최종 동기화 이후에 변경된 변경 단위들만을 상기 파트너와 동기화하는, 저장 플랫폼 시스템.
9. 컴퓨터 시스템에 저장된 데이터를 동기화시키기 위한 방법으로서,

   커널을 포함하는 운영 체제를 실행시키는 단계 - 상기 커널은 파일 시스템을 인캡슐레이트하는 데이터베이스 운영 프로그램을 포함하고, 상기 데이터베이스 운영 프로그램은 베이스 스키마 및 상기 베이스 스키마를 상기 데이터에 대한 스키마를 정의하기 위해 확장시키는 메커니즘을 포함함 -;

   상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해, 데이터를 파일 스트림들로서 상기 파일 시스템에 저장하는 단계;

   상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해, 상기 파일 스트림들에 대한 메타데이터를 포함하는 아이템들을 생성하는 단계 - 상기 메타데이터는 상기 데이터에 대한 스키마에 의해 정의됨 -;

   상기 아이템들을 상기 데이터베이스 운영 프로그램에 저장하는 단계;

   상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해, 상기 데이터를 상기 데이터에 대한 스키마에 기초하여 프로그램가능하도록 정의된 변경 단위들로 분할하는 단계 - 변경 단위는 상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해 개별적으로 추적되는 스키마의 가장 작은 부분이고, 변경 단위의 크기는 조정가능함 -;

   상기 데이터베이스 운영 프로그램에 의해, 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 생성하는 단계 - 상기 상태 정보는 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 변경 정보를 포함하고, 상기 비동기적 원격 컴퓨터 시스템은 상기 데이터베이스 운영 프로그램과 호환될 수 있는 동기화인 동기화 서브시스템을 포함하지 않음 -;

   상기 데이터베이스 운영 프로그램에 의해, 상기 데이터베이스 운영 프로그램에 저장된 아이템들에 대한 변경 단위 정보를 비동기적 원격 컴퓨터 시스템에 저장된 대응하는 파일들에 대한 상태 정보와 비교하는 단계;

   상기 데이터베이스 운영 프로그램에 의해, 상기 비교에 기초하여 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들 중 어떤 파일들이 업데이트가 요구되는지 판정하는 단계;

   상기 데이터베이스 운영 프로그램에 의해, 아이템들을 상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅된 파일들로 변환하는 단계;

   상기 데이터베이스 운영 프로그램에 의해, 상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅된 파일들을 상기 비동기적 원격 컴퓨터 시스템으로 전송하는 단계;

   상기 데이터베이스 운영 프로그램에 의해, 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 업데이트하는 단계

   를 포함하고,

   상기 비동기적 원격 컴퓨터 시스템은 상기 파일들을 수신하여 상기 파일들을 파일 시스템에 저장하도록 구성된, 동기화 방법.
10. 제9항에 있어서,

    상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램을 동작시키는 코드는 상기 운영 체제의 커널 모드 동안 실행되도록 구성되는, 동기화 방법.
11. 제10항에 있어서,

    변경 단위 입도의 레벨(level of change unit granularity)에서 동기화 충돌들을 검출하는 단계를 더 포함하는 동기화 방법.
12. 제10항에 있어서,

    인스턴스들이 변경 적용시에 개별 변경 단위 레벨에서 성공, 실패, 충돌 중 적어도 하나를 보고하는 단계 - 상기 인스턴스들은 동기화 데이터를 포함함 -; 및

    애플리케이션이 백엔드 상태를 업데이트하기 위하여 동기화 데이터를 사용하는 단계

    를 더 포함하는 동기화 방법.
13. 데이터를 동기화시키기 위한 방법으로서,

    커널을 포함하는 운영 체제를 실행시키는 단계 - 상기 커널은 파일 시스템을 인캡슐레이트하는 데이터베이스 운영 프로그램을 포함함 -;

    상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해, 데이터를 파일 스트림들로서 상기 파일 시스템에 저장하는 단계;

    상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해, 상기 파일 스트림들에 대한 메타데이터를 포함하는 상기 파일 스트림들과 관련된 아이템들을 생성하는 단계 - 상기 메타데이터는 상기 데이터에 대한 스키마에 의해 정의되고, 상기 아이템들은 베이스 스키마로부터 획득된 스키마에 따르며, 상기 스키마는 변경 단위의 크기를 정의하고, 변경 단위는 상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해 개별적으로 추적되는 스키마의 가장 작은 부분임 -;

    상기 아이템들을 상기 데이터베이스 운영 프로그램에 저장하는 단계;

    상기 데이터베이스 운영 프로그램에 의해, 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 생성하는 단계 - 상기 상태 정보는 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 변경 정보를 포함하고, 상기 비동기적 원격 컴퓨터 시스템은 상기 데이터베이스 운영 프로그램과 호환될 수 있는 동기화인 동기화 서브시스템을 포함하지 않음 -;

    상기 데이터베이스 운영 프로그램에 의해, 상기 데이터베이스 운영 프로그램에 저장된 아이템들에 대한 변경 단위 정보를 비동기적 원격 컴퓨터 시스템에 저장된 대응하는 파일들에 대한 상태 정보와 비교하는 단계;

    상기 데이터베이스 운영 프로그램에 의해, 상기 비교에 기초하여 상기 데이터베이스 운영 프로그램의 아이템들 중 어떤 아이템들이 업데이트가 요구되는지 판정하는 단계;

    상기 비동기적 원격 컴퓨터 시스템으로부터 업데이트가 요구되는 아이템들에 대응하는 파일들을 수신하는 단계;

    상기 데이터베이스 운영 프로그램에 의해, 업데이트가 요구되는 아이템들에 대응하는 파일들을 아이템들로 변환하는 단계;

    상기 데이터베이스 운영 프로그램에 의해, 상기 데이터베이스 운영 프로그램의 업데이트가 요구되는 아이템들에 대응하는 파일들로부터 획득된 아이템들을 저장하는 단계; 및

    상기 데이터베이스 운영 프로그램에 의해, 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 업데이트된 상태 정보를 저장하는 단계

    를 포함하는 동기화 방법.
14. 제13항에 있어서,

    상기 변경 단위마다 변경 단위 상의 각 변경에 대한 성공 또는 실패에 기초하여 상기 데이터베이스 운영 프로그램에 저장된 정보의 새로운 상태를 계산하고, 상기 새로운 상태 정보를 저장하는 단계

    를 더 포함하는 동기화 방법.
15. 제13항에 있어서,

    상기 비동기적 원격 컴퓨터 시스템으로부터 각각의 변경이 성공적인지를 나타내는 정보를 수신하는 단계; 및

    상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해, 상기 정보를 저장하는 단계

    를 더 포함하는 동기화 방법.
16. 컴퓨터 판독가능 명령어들을 포함하는 컴퓨터 판독가능 저장 매체로서,

    운영 체제를 위한 명령어들 - 상기 운영 체제는 커널 및 쉘(shell)을 포함하고, 애플리케이션들은 상기 운영 체제의 쉘 상에서 실행되며, 상기 운영 체제를 위한 명령어들은 파일 시스템을 인캡슐레이트하는 데이터베이스 운영 프로그램을 포함하고, 상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램은 상기 운영 체제의 상기 커널의 일부이며, 상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램을 위한 명령어들은 데이터를 파일 스트림들로서 상기 파일 시스템에 저장하고, 상기 파일 스트림들에 대한 메타데이터를 포함하는 상기 파일 스트림들에 대한 아이템들을 생성하도록 구성되고, 상기 메타데이터의 포맷은 복수의 스키마 중 하나에 따르고, 상기 복수의 스키마의 각각은 베이스 스키마로부터 획득되고, 상기 복수의 스키마의 각각은 프로그램가능하도록 정의된 변경 단위들을 포함하고, 변경 단위는 상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해 개별적으로 추적되는 스키마의 가장 작은 부분임 -;

    비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 생성하기 위한 명령어들 - 상기 상태 정보는 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 변경 정보를 포함하고, 상기 비동기적 원격 컴퓨터 시스템은 상기 데이터베이스 운영 프로그램과 호환될 수 있는 동기화인 동기화 서브시스템을 포함하지 않음 -;

    상기 데이터베이스 운영 프로그램에 저장된 아이템들에 대한 변경 단위 정보를 비동기적 원격 컴퓨터 시스템에 저장된 대응하는 파일들에 대한 상태 정보와 비교하기 위한 명령어들;

    상기 비교에 기초하여 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들 중 어떤 파일들이 업데이트가 요구되는지 판정하기 위한 명령어들;

    아이템들을 상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅된 파일들로 변환하기 위한 명령어들;

    상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅된 파일들을 상기 비동기적 원격 컴퓨터 시스템으로 전송하기 위한 명령어들; 및

    상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 업데이트하기 위한 명령어들

    을 포함하고,

    상기 비동기적 원격 컴퓨터 시스템은 상기 파일들을 수신하여 상기 파일들을 파일 시스템에 저장하도록 구성된, 컴퓨터 판독가능 저장 매체.
17. 제16항에 있어서,

    상기 비동기적 원격 컴퓨터 시스템이 상기 파일들을 파일 시스템에 성공적으로 저장하였는지 판정하기 위한 명령어들을 더 포함하는, 컴퓨터 판독가능 저장 매체.
18. 제16항에 있어서,

    상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램을 위한 명령어들은 상기 운영 체제의 커널 모드 동안 실행되도록 구성되는, 컴퓨터 판독가능 저장 매체.
19. 제16항에 있어서,

    동기화 시의 충돌들을 자동으로 검출하고, 소정의 판정 가능 기준에 기초하여 상기 충돌들을 해결하기 위한 명령어들을 더 포함하는 컴퓨터 판독가능 저장 매체.
20. 제19항에 있어서,

    상기 충돌들 중 일부를 최종 사용자에 의한 수동 해결을 위해 로깅됨으로써 해결하기 위한 명령어들을 더 포함하는 컴퓨터 판독가능 저장 매체.
21. 제16항에 있어서,

    동기화 파트너와의 이전 동기화들의 상태를 추적하여, 최종 동기화 이후에 변경된 변경 단위들만을 상기 파트너와 동기화하는 동기화 과정을 위한 명령어들을 더 포함하는, 컴퓨터 판독가능 저장 매체.
22. 데이터를 동기화하기 위한 컴퓨터 판독가능 명령어들을 포함하는 컴퓨터 판독가능 저장 매체로서,

    커널을 위한 명령어들을 포함하는 운영 체제를 실행시키기 위한 명령어들 - 상기 커널을 위한 명령어들은 데이터베이스 운영 프로그램에 의해 인캡슐레이트된 파일 시스템을 위한 명령어들을 포함하고, 상기 데이터베이스 운영 프로그램을 위한 명령어들은 베이스 스키마 및 상기 베이스 스키마를 데이터에 대한 스키마를 정의하기 위해 확장시키는 메커니즘을 포함함 -;

    을 포함하고,

    상기 운영 체제의 상기 커널을 위한 명령어들은 데이터를 파일 스트림들로서 상기 파일 시스템에 저장하기 위한 명령어들을 포함하고,

    상기 운영 체제의 상기 커널을 위한 명령어들은 상기 파일 스트림들에 대한 메타데이터를 포함하는 아이템들을 생성하기 위한 명령어들을 포함하고, 상기 메타데이터는 상기 데이터에 대한 스키마에 의해 정의되며,

    상기 운영 체제의 상기 커널을 위한 명령어들은 상기 아이템들을 상기 데이터베이스 운영 프로그램에 저장하기 위한 명령어들을 포함하고,

    상기 운영 체제의 상기 커널을 위한 명령어들은 상기 데이터를 상기 데이터에 대한 스키마에 기초하여 프로그램가능하도록 정의된 변경 단위들로 분할하기 위한 명령어들을 포함하고, 변경 단위는 상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램에 의해 개별적으로 추적되는 스키마의 가장 작은 부분이며, 변경 단위의 크기는 조정가능하고,

    상기 데이터베이스 운영 프로그램을 위한 명령어들은 상기 데이터에 대한 변경들을 순차적으로 열거하고 변경 단위 별로 상기 변경들(changes on a per change unit basis)을 추적하고,

    상기 데이터베이스 운영 프로그램을 위한 명령어들은 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 생성하기 위한 명령어들을 포함하고, 상기 상태 정보는 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 변경 정보를 포함하고, 상기 비동기적 원격 컴퓨터 시스템은 상기 데이터베이스 운영 프로그램과 호환될 수 있는 동기화인 동기화 서브시스템을 포함하지 않음 -;

    상기 데이터베이스 운영 프로그램을 위한 명령어들은 상기 데이터베이스 운영 프로그램에 저장된 아이템들에 대한 변경 단위 정보를 비동기적 원격 컴퓨터 시스템에 저장된 대응하는 파일들에 대한 상태 정보와 비교하기 위한 명령어들을 포함하고,

    상기 데이터베이스 운영 프로그램을 위한 명령어들은 상기 비교에 기초하여 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들 중 어떤 파일들이 업데이트가 요구되는지 판정하기 위한 명령어들을 포함하고,

    상기 데이터베이스 운영 프로그램을 위한 명령어들은 아이템들을 상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅된 파일들로 변환하기 위한 명령어들을 포함하고,

    상기 데이터베이스 운영 프로그램을 위한 명령어들은 상기 비동기적 원격 컴퓨터 시스템에의 저장을 위해 포맷팅된 파일들을 상기 비동기적 원격 컴퓨터 시스템으로 전송하기 위한 명령어들을 포함하고,

    상기 데이터베이스 운영 프로그램을 위한 명령어들은 상기 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 업데이트하기 위한 명령어들을 포함하고,

    상기 비동기적 원격 컴퓨터 시스템은 상기 파일들을 수신하여 상기 파일들을 파일 시스템에 저장하도록 구성된, 컴퓨터 판독가능 저장 매체.
23. 제22항에 있어서,

    상기 파일 시스템을 인캡슐레이트하는 상기 데이터베이스 운영 프로그램을 위한 명령어들은 상기 운영 체제의 커널 모드 동안 실행되도록 구성되는, 컴퓨터 판독가능 저장 매체.
24. 제23항에 있어서,

    변경 단위 입도의 레벨에서 동기화 충돌들을 검출하기 위한 명령어들을 더 포함하는, 컴퓨터 판독가능 저장 매체.
25. 제23항에 있어서,

    변경 적용시에 개별 변경 단위 레벨에서 성공, 실패, 충돌 중 적어도 하나를 보고하는 인스턴스들을 위한 명령어들 - 상기 인스턴스들은 동기화 데이터를 포함함 -; 및

    백엔드 상태를 업데이트하기 위하여 동기화 데이터를 사용하는 애플리케이션들을 위한 명령어들

    을 더 포함하는 컴퓨터 판독가능 저장 매체.
26. 데이터를 동기화하기 위한 컴퓨터 판독가능 명령어들을 포함하는 컴퓨터 판독가능 저장 매체로서,

    커널을 포함하는 운영 체제를 실행시키기 위한 명령어들 - 상기 커널은 데이터베이스 운영 프로그램에 의해 인캡슐레이트된 파일 시스템을 포함하고, 상기 운영 체제의 상기 커널을 위한 명령어들은 데이터를 파일 스트림들로서 상기 파일 시스템에 저장하기 위한 명령어들을 포함하고, 상기 운영 체제의 상기 커널을 위한 명령어들은 상기 파일 스트림들에 대한 메타데이터를 포함하는 상기 파일 스트림들에 관련된 아이템들을 생성하기 위한 명령어들을 포함하고, 상기 메타데이터는 상기 데이터에 대한 스키마에 의해 정의되고, 상기 아이템들은 베이스 스키마로부터 획득된 스키마에 따르고, 상기 스키마는 변경 단위의 크기를 정의하고, 변경 단위는 상기 파일 시스템과 통합된 상기 데이터베이스 운영 프로그램에 의해 개별적으로 추적되는 스키마의 가장 작은 부분임 -;

    상기 아이템들을 상기 데이터베이스 운영 프로그램에 저장하기 위한 명령어들;

    비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 상태 정보를 생성하기 위한 명령어들 - 상기 상태 정보는 비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 변경 정보를 포함하고, 상기 비동기적 원격 컴퓨터 시스템은 상기 데이터베이스 운영 프로그램과 호환될 수 있는 동기화 서브시스템을 포함하지 않음 -;

    상기 데이터베이스 운영 프로그램에 저장된 아이템들에 대한 변경 단위 정보를 비동기적 원격 컴퓨터 시스템에 저장된 대응하는 파일들에 대한 상태 정보와 비교하기 위한 명령어들;

    상기 비교에 기초하여 상기 데이터베이스 운영 프로그램의 아이템들 중 어떤 아이템들이 업데이트가 요구되는지 판정하기 위한 명령어들;

    상기 비동기적 원격 컴퓨터 시스템으로부터 상기 업데이트가 요구되는 아이템들에 대응하는 파일들을 수신하기 위한 명령어들;

    상기 업데이트가 요구되는 아이템들에 대응하는 파일들을 아이템들로 변환하기 위한 명령어들;

    상기 데이터베이스 운영 프로그램의 상기 업데이트가 요구되는 아이템들에 대응하는 상기 파일들로부터 획득된 아이템들을 저장하기 위한 명령어들; 및

    비동기적 원격 컴퓨터 시스템에 저장된 파일들에 대한 업데이트된 상태 정보를 저장하기 위한 명령어들

    을 포함하는 컴퓨터 판독가능 저장 매체.
27. 제26항에 있어서,

    상기 비동기적 원격 컴퓨터 시스템이 상기 파일들을 파일 시스템에 성공적으로 저장하였는지 판정하기 위한 명령어들을 더 포함하는 컴퓨터 판독가능 저장 매체.
28. 제26항에 있어서,

    상기 비동기적 원격 컴퓨터 시스템으로부터 각각의 변경이 성공적인지를 나타내는 상태 정보를 수신하기 위한 명령어들; 및

    상기 정보를 저장하기 위한 명령어들을 더 포함하는 컴퓨터 판독가능 저장 매체.
29. 삭제
30. 삭제

Images