KR100959473B1 - 저장 플랫폼과 애플리케이션 프로그램 사이의 애플리케이션프로그래밍 인터페이스 - Google Patents

Abstract

본 발명의 다양한 실시예들은 저장된 데이터가 항목, 요소, 및 관계의 관점에서 정의된 데이터 저장소(도 20, 2014)(항목은 데이터 저장소 내에 저장가능한 데이터 단위이면서 하나 이상의 요소들을 포함하고, 요소는 하나 이상의 필드들을 포함하는 타입의 인스턴스(instance)(도 20, 2016)이고, 관계는 적어도 2개의 항목들 간의 링크임); 상이한 타입의 항목, 요소 및 관계들을 정의(도 20, 2016)하는 스키마들의 세트(도 20, 2014); 및 스키마들의 세트 내에 정의된 상이한 항목, 요소 및 관계의 각각에 대한 클래스(도 20, 2008)를 포함하는 애플리케이션 프로그래밍 인터페이스(도 20, 350a, 350b, 350c)를 포함하는 저장 플랫폼(도 20)에 관한 것이다. 데이터는 또한 기존 항목 타입에 대한 확장의 형태로 상기 데이터 저장소에 저장될 수 있으며, 여기서 애플리케이션 프로그래밍 인터페이스는 각각의 상이한 항목 확장에 대한 클래스(도 20, 2006)를 포함한다.

인터페이스, 저장 플랫폼, 동기화, 애플리케이션 프로그래밍 인터페이스, API

Description

저장 플랫폼과 애플리케이션 프로그램 사이의 애플리케이션 프로그래밍 인터페이스{SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM}

<상호 참조>

본 출원은 다음의 본 출원과 공히 양도된 출원들에 개시된 발명들과 내용이 관련되어 있다: "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능하지만 물리적 표현에 무관한 정보의 단위들을 표현하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 (아직 부여되지 않았음) (대리인 관리번호 제MSFT-1748호); "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 그들의 물리적 체계로부터 분리하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 (아직 부여되지 않았음) (대리인 관리번호 제MSFT-1749호); "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하기 위한 기본 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 (아직 부여되지 않았음) (대리인 관리번호 제MSFT-1750호); "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하기 위한 최상위 레벨 구조를 제공하는 코어 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 (아직 부여되지 않았음) (대리인 관리번호 제MSFT-1751호); "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들 간의 관 계를 표현하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 (아직 부여되지 않았음) (대리인 관리번호 제MSFT-1752호); "데이터의 체계화, 검색 및 공유를 위한 저장 플랫폼"이라는 제목의 미국 특허 출원 번호 (아직 부여되지 않았음) (대리인 관리번호 제MSFT-2734호); "항목 기반 저장 플랫폼에서의 데이터 모델링을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 (아직 부여되지 않았음) (대리인 관리번호 제MSFT-2735호).

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

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

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

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

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

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

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

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

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

다음의 요약은 발명의 다양한 양태의 개요를 제공한다. 이 요약은 본 발명의 중요한 양태들 모두를 망라한 설명을 제공하기 위해 의도된 것은 아니며, 본 발명의 범위를 한정하지도 않는다. 오히려, 이 요약은 뒤따르는 상세한 설명 및 도면에 대한 서론으로서 기능하도록 의도된다.

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

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

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

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

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

본 발명의 다른 양태에 따라, 다수의 항목을 조작하는 컴퓨터 시스템용 하드웨어/소프트웨어 인터페이스 시스템은 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리되는 다수의 관계에 의해 상호접속된 항목들을 더 포함한다. 본 발명의 다른 양태에 따라, 컴퓨터 시스템용 하드웨어/소프트웨어 인터페이스 시스템은 자기가 이해할 수 있는 속성들을 갖는 다수의 별개의 정보 단위를 조작한다. 본 발명의 다른 양태에 따라, 컴퓨터 시스템용 하드웨어/소프트웨어 인터페이스 시스템은 자신이 이해하고, 미리결정된 방식 및 예측가능한 방식으로 직접 처리할 수 있는 코어 항목 세트를 정의하기 위한 코어 스키마를 포함한다. 본 발명의 다른 양태에 따라, 상기 항목들을 다수의 관계와 상호접속시키는 것 및 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 상기 관계를 관리하는 것을 포함하는, 컴퓨터 시스템용 하드웨어/소프트웨어 인터페이스 시스템 내에서 다수의 별개의 정보 단위("항목")를 관리하기 위한 방법이 개시된다.

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

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

본 발명의 다른 특징 및 이점은 아래의 발명의 상세한 설명 및 첨부 도면으로부터 명백해질 것이다.

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

도 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는 예시적인 연락처 (항목 및 요소) 스키마의 도면이다.

도 22는 본 발명의 양태에 따른, 저장 플랫폼 API의 실행시간 프레임워크를 나타내는 도면이다.

도 23은 본 발명의 일 실시예에 따른, FindAll 동작의 실행을 나타내는 도면이다.

도 24는 본 발명의 양태에 따라, 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타내는 도면이다.

도 25는 본 발명의 다른 양태에 따른, 파일 API가 기초로 하는 스키마를 나타내는 도면이다.

도 26은 본 발명의 일 실시예에 따라, 데이터 보안을 위해 사용되는 액세스 마스크 포맷(access mask format)을 나타내는 도면이다.

도 27은 본 발명의 일 양태의 일 실시예에 따라, 동일하게 보호되는 새로운 보안 영역이 기존 보안 영역으로부터 보호되는 것을 나타내는 도면이다.

도 28은 본 발명의 일 양태의 일 실시예에 따른, 항목 검색 뷰(Item search view)의 개념을 나타내는 도면이다.

도 29는 본 발명의 일 실시예에 따른, 예시적인 항목 계층 구조를 나타내는 도면이다.

목차

I. 서론

A. 예시적인 컴퓨팅 환경

B. 통상의 파일 기반 저장

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

A. 용어집

B. 저장 플랫폼의 개요

C. 데이터 모델

1. 항목

2. 항목 식별

a) 항목 참조

(1) ItemIDReference

(2) ItemPathReference

b) 참조 타입 계층 구조

3. 항목 폴더 및 카테고리

4. 스키마

a) 기본 스키마

b) 코어 스키마

5. 관계

a) 관계 선언

b) 유지 관계

c) 삽입 관계

d) 참조 관계

e) 규칙 및 제한

f) 관계 순서화

6. 확장성

a) 항목 확장

b) NestedElement 타입 확장

D. 데이터베이스 엔진

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

2. 항목 매핑

3. 확장 매핑

4. 중첩 요소 매핑

5. 객체 식별

6. SQL 객체 명명

7. 칼럼 명명

8. 검색 뷰

a) 항목

(1) 마스터 항목 검색 뷰

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

b) 항목 확장

(1) 마스터 확장 검색 뷰

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

c) 중첩 요소

d) 관계

(1) 마스터 관계 검색 뷰

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

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. 보안

1. 개요

2. 보안 모델의 상세 설명

a) 보안 기술자 구조

(1) 액세스 마스크 포맷

(2) 일반 액세스 권리

(3) 표준 액세스 권리

b) 항목 특정 권리

(1) 파일 및 디렉토리 객체 특정 권리

(2) WinFSItemRead

(3) WinFSItemRead 속성

(4) WinFSItemWrite 속성

(5) WinFSItemWrite

(6) WinFSItemAddLink

(7) WinFSItemDeleteLink

(8) 항목을 삭제하기 위한 권리

(9) 항목을 복사하기 위한 권리

(10) 항목을 이동시키기 위한 권리

(11) 항목에 대한 보안 정책을 보기 위한 권리

(12) 항목에 대한 보안 정책을 변경하기 위한 권리

(13) 직접적인 등가물을 갖지 않는 권리

3. 구현

a) 컨테이너 내에 새로운 항목 생성

b) 항목에 명시적인 ACL 추가

c) 항목에 유지 관계 추가

d) 항목으로부터 유지 관계 삭제

e) 항목으로부터 명시적인 ACL 삭제

f) 항목에 관련된 ACL 수정

F. 통지 및 변경 추적

1. 저장 변경 이벤트

a) 이벤트

b) 감시자

2. 변경 추적 및 통지 생성 메커니즘

a) 변경 추적

b) 타임 스탬프 관리

c) 데이터 변경 삭제 - 이벤트 검출

G. 동기화

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. 관리성

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

1. 연동성에 대한 모델

2. 데이터 저장소 기능

a) 볼륨이 아님

b) 저장소 구조

c) 모든 파일들이 이주되지 않음

d) 저장 플랫폼 파일에의 NTFS 명칭 공간 액세스

e) 예상되는 명칭 공간/도출 문자

I. 저장 플랫폼 API

1. 개요

2. 명명 및 범위

3. 저장 플랫폼 API 컴포넌트

4. 데이터 클래스

5. 실행시간 프레임워크

a) 실행시간 프레임워크 클래스

(1) ItemContext

(2) ItemSearcher

(a) 타겟 타입

(b) 필터

(c) 검색 준비

(d) 옵션 찾기

(3) 항목 결과 스트림("FindResult")

b) 동작의 실행시간 프레임워크

c) 공통 프로그래밍 패턴

(1) ItemContext 객체 열고 닫기

(2) 객체 검색

(a) 검색 옵션

(b) FindOne 및 FindOnly

(c) ItemContext에 대한 쇼트컷 검색

(d) ID 또는 경로에 의한 찾기

(e) GetSearcher 패턴

(3) 저장소 갱신

6. 보안

7. 관계 지원

a) 기본 관계 타입

(1) Relationship 클래스

(2) ItemReference 클래스

(3) ItemIdReference 클래스

(4) ItemPathReference 클래스

(5) RelationshipId 구조

(6) VirtualRelationshipCollection 클래스

b) 생성된 관계 타입

(1) 생성된 관계 타입

(2) RelationshipPrototype 클래스

(3) RelationshipPrototypeCollection 클래스

c) 항목 클래스 내의 관계 지원

(1) Item 클래스

(2) RelationshipCollection 클래스

d) 검색 표현 내의 관계 지원

(1) 항목으로부터 관계로 트래버스(traverse)함

(2) 관계로부터 항목으로 트래버스함

(3) 관계 트래버설(traversal) 조합

e) 관계 지원의 예시적인 사용

(1) 관계에 대한 검색

(2) 관계로부터 소스 및 타겟 항목으로 네비게이션

(3) 소스 항목으로부터 관계로 네비게이션

(4) 관계(및 항목) 생성

(5) 관계(및 항목) 삭제

8. 저장 플랫폼 API "확장"

a) 도메인 거동

b) 값-추가 거동

c) 서비스 공급자로서의 값-추가 거동

9. 시간 프레임워크 설계

10. 질의 형식

a) 필터 기초

b) 타입 캐스트(cast)

c) 필터 신택스

11. 원격

a) API의 로컬/원격 투명성

b) 원격의 저장소 플랫폼 구현

c) 비 저장 플랫폼 저장소에의 액세스

d) DFS와의 관계

e) GXA/인디고(indigo)와의 관계

12. 제한

13. 공유

a) 공유 표현

b) 공유 관리

c) 공유 액세스

d) 발견성

14. Find의 시맨틱

15. 저장소 플랫폼 연락처 API

a) System.Storage.Contact의 개요

b) 도메인 거동

16. 저장소 플랫폼 파일 API

a) 소개

(1) 저장소 플랫폼 내의 NTFS 볼륨을 반영

(2) 저장 플랫폼 명칭 공간에 파일 및 디렉토리 생성

b) 파일 스키마

c) System.Storage.Files의 개요

d) 코드 예

(1) 파일 열기 및 파일에 기록

(2) 질의 사용

e) 도메인 거동

J. 결론

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) 내에 정확하게 하나의 식별자를 가져야 한다.

a) 항목 참조

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

(1) ItemIDReference

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

(2) ItemPathReference

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

b) 참조 타입 계층 구조

이러한 타입의 참조는 세트 동작에서 사용될 수 없다. 참조는 일반적으로 경로 분석 프로세스를 통해 분석되어야 한다. 저장 플랫폼 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) 참조 관계

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

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

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

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

e) 규칙 및 제한

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

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

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

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

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

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

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

물론, 카테고리 기술은 사실상 논리적이며, 따라서 카테고리는 타입들, 속성들 및/또는 값들의 임의의 논리적 표현에 의해 기술될 수 있다. 예컨대, 카테고리의 논리적 표현은 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)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 있다는 것을 나타낸다. 그러나, 항목(1002)에서 카테고리(1000)로의 관계는 존재하지 않으며, 이는 카테고리(1000)가 항목(1002)에 대해 사적이며, 항목(1002)과 그의 멤버 정보를 공유하지 않는다는 것을 나타낸다. 한편, 항목(1004)은 그 자체에서 카테고리(1000)로의 관계(1024)를 갖지 않으며, 이는 카테고리(1000)가 공개적이며, 항목(1004)과 그의 멤버 정보를 공유한다는 것을 나타낸다. 그러나, 카테고리(1000)에서 항목(1004)으로 확장되는 관계는 존재하지 않으며, 이는 항목(1004)이 사적이며, 카테고리(1000), 그의 다른 멤버들(1002, 1006), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 없다는 것은 나타낸다. 카테고리의 항목(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) 항목 또는 중첩 요소에 첨부되어야 한다.

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

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

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 데이터베이스에 포함될 필요가 있으며, 또한 동기화, 통지 및 보안과 같은 메커니즘이 구현될 필요가 있다.

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

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

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

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

다음 예는 UDT의 기초를 예시한다. MapLib.dll은 MapLib라 불리는 어셈블리를 갖는다고 가정하자. 이 어셈블리에서는, 명칭 공간 BaseType 하에 Point라 불리는 클래스가 있다:

다음의 T-SOL 코드는 클래스 Point를 Point라 불리는 SQL 서버 UDT에 결합한다. 제1 단계는 MapLib 어셈블리를 데이터베이스에 로드하는 "CreateAssembly"를 호출한다. 제2 단계는 사용자 정의 타입 "Point"를 생성하기 위한 "CreateType"을 호출하고, 그것을 관리 타입 BaseTypes.Point에 결합시킨다:

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

본원에서 도 29에 예시된 항목 계층 구조는 예로서 사용된다. 이것은, 모든 항목 타입들이 화살표로 나타낸 상속에 의해 도출된 항목 타입(예를 들어, Contact.Person 및 Contact.Employee)들의 세트를 따라 도출되는 Base.Item 타입을 나타낸다.

2. 항목 매핑

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

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

모든 항목에 대한 글로벌 검색 가능 속성들의 사본을 저장하기 위하여 "쉐도우" 테이블이 사용된다. 이 테이블은 모든 데이터 변경을 행하는 저장 플랫폼 API의 Update() 메소드에 의해 유지될 수 있다. 타입 패밀리 테이블과 달리, 이 글로벌 항목 테이블은 완전한 UDT 항목 객체가 아니라 항목의 최상위 레벨 스칼라 속성만을 포함한다.

글로벌 항목 테이블의 구조는 다음과 같다:

글로벌 항목 테이블은 ItemID 및 TypeID를 노출시킴으로써 타입 패밀리 테이블에 저장된 항목 객체에 대한 네비게이션을 허용한다. ItemID는 일반적으로 데이터 저장소 내의 항목을 고유하게 식별한다. TypeID는 여기서 설명되지 않는 메타데이터를 사용하여 타입 명칭 및 항목을 포함하는 뷰로 매핑될 수 있다.

글로벌 항목 테이블과 관련하여, 그리고 다른 상황과 관련하여, 항목을 그의 ItemID에 의해 찾는 것은 일반적인 동작일 수 있으므로, 항목의 ItemID가 주어지면 항목 객체를 리트리브하기 위한 GetItem() 함수가 제공된다. 이 함수는 다음의 선언을 갖는다:

Base.Item Base.GetItem(uniqueidentifier ItemID)

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

완벽함을 위해, 뷰는 또는 글로벌 항목 테이블에 대해서도 생성될 수 있다. 이 뷰는 초기에 테이블과 동일한 열들을 노출할 수 있다:

3. 확장 매핑

확장은 항목과 매우 유사하며, 동일한 요건들의 일부를 갖는다. 상속을 지원하는 다른 루트 타입으로서, 확장은 저장에 있어서의 동일한 고려 및 트레이드오프 중 많은 부분에 종속된다. 이 때문에, 유사한 타입 패밀리 매핑이 단일 테이블 접근법이 아니라 확장에 적용된다. 물론, 다른 실시예에서는 단일 테이블 접근법이 사용될 수 있다.

본 실시예에서, 확장은 ItemID에 의해 정확히 하나의 항목과 연관되며, 항목과 관련하여 고유한 ExtensionID를 포함한다. 확장 테이블은 다음의 정의를 갖는다:

항목에서와 같이, ItemID 및 ExtensionID 쌍으로 이루어진 확장 식별자가 주어질 때 확장을 리트리브하기 위한 기능이 제공될 수 있다. 이 기능은 다음의 선언을 갖는다:

항목 타입 뷰와 유사한 각각의 항복 타입에 대한 뷰가 생성된다. 다음의 타 입을 가진 예시적인 항목 계층 구조에 병렬인 확장 계층구조를 가정하자: Base.Extension, Contact.PersonExtension, Contact.EmployeeExtention. 다음의 뷰가 생성될 수 있다:

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. 열 명명

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

8. 검색 뷰

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

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

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

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

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

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

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

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

각 타입 패밀리의 멤버들은 일련의 항목 뷰들을 사용하여 검색 가능한데, 데이터 저장소에는 항목 타입당 하나의 뷰가 존재한다. 도 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 객체-선언 관계의 타입

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. 보안

이 섹션은 일 실시예에 따른 본 발명의 저장 플랫폼에 대한 보안 모델을 설명한다.

1. 개요

본 발명에 따르면, 저장 플랫폼의 보안 정책이 특정 및 시행되는 입상(granularity)이 주어진 데이터 저장소의 항목에 대한 다양한 동작들의 레벨에 있 으며, 전체로부터 항목의 부분들을 개별적으로 보안하기 위한 능력은 없다. 보안 모듈은 액세스 제어 리스트(ACL)를 통해 항목에 대해서 이러한 동작들을 수행하기 위한 액세스가 주어질 수 있는 또는 거절될 수 있는 주체의 세트를 특정한다. 각각의 ACL은 액세스 제어 엔트리(ACE)의 순서화된 집합이다.

항목에 대한 보안 정책은 임의 액세스 제어 정책 및 시스템 액세스 제어 정책에 의해 완벽하게 설명될 수 있다. 이들 각각은 ACL의 세트이다. 제2 ACL 세트가 객체가 소정의 방식으로 조작될 때 감사하는 시스템이 동작하는 방법을 특정하는 SACL(시스템 액세스 제어 리스트)를 의미하는 반면, 제1 세트(DACL)는 항목의 소유자가 다양한 주체에 준 임의 액세스를 나타낸다. 이외에, 데이터 저장소 내의 각각의 항목은 항목의 소유자에 대응하는 SID(소유자 SID)에 관련된다.

저장 플랫폼 데이터 저장소 내에 항목들을 체계화하기 위한 주요 메커니즘은 포함 계층 구조의 그것이다. 포함 계층 구조는 항목들 간의 유지 관계를 사용하여 실현된다. "A는 B를 포함한다"와 같이 표현된 두 개의 항목 A와 B 간의 유지 관계는 항목 A가 항목 B의 수명에 영향을 줄 수 있게 한다. 일반적으로, 데이터 저장소 내의 항목은 다른 항목으로부터 그것으로의 유지 관계가 존재하기 전까지는 존재할 수 없다. 유지 관계는 항목의 수명을 제어하는 것 이외에 항목에 대한 보안 정책을 전파하기 위해 필요한 메커니즘을 제공한다.

각각의 항목에 대해 특정된 보안 정책은 그 항목에 대해 명시적으로 특정된 부분 및 데이터 저장소 내의 항목의 부모로부터 상속된 부분의 두 개의 부분으로 구성된다. 임의의 항목에 대해 명시적으로 정의된 보안 정책은 조건하에서 항목에 의 액세스를 관리하는 부분 및 포함 계층 구조 내의 그것의 모든 자손들에 상속된 보안 정책에 영향을 주는 부분의 두 개의 부분으로 구성된다. 자손에 상속된 보안 정책은 명시적으로 정의된 정책 및 상속된 정책의 기능이다.

보안 정책은 유지 관계를 통해 전파되고 임의의 항목에서 무시될 수 있기 때문에, 항목에 대한 효율적인 보안 정책을 결정하는 방법을 특정할 필요가 있다. 본 실시예에서, 데이터 저장소 포함 계층 구조 내의 항목은 저장소의 루트에서부터 그 항목까지의 모든 경로를 따라 ACL을 상속한다.

임의의 주어진 경로에 대해서 상속된 ACL 내에서, ACL 내의 다양한 ACE들의 순서화는 시행되는 최종 보안 정책을 결정한다. 다음의 설명은 ACL 내의 ACE들의 순서화를 설명한다. 항목에 의해 상속되는 ACL 내의 ACE들의 순서화는 다음의 두 개의 규칙에 의해 결정된다 -

제1 규칙은 포함 계층 구조의 루트로부터 항목 I로의 경로 내의 여러 항목들로부터 상속된 ACE를 계층화한다. 보다 근접한 컨테이너로부터 상속된 ACE는 멀리 있는 컨테이너로부터 상속된 엔트리보다 선행된다. 직관적으로, 이것은 관리자가 포함 계층 구조 내의 보다 멀리서부터 상속된 ACE를 무시하기 위한 능력을 허용한다. 이 규칙은 다음과 같다:

제2 규칙은 항목에 액세스를 준 ACE 앞의 항목에 액세스를 거절한 ACE를 두도록 순서화한다.

트리인 포함 계층 구조의 경우에, 트리의 루트로부터 항목까지에는 오직 하나의 경로만이 존재하며, 항목은 오직 하나의 상속된 ACL를 갖는다. 이런 상황에서, 항목에 상속된 ACL은 ACL 내의 ACE들의 상대적인 순서화의 관점에서 기존 윈도우즈 보안 모델 내에서 파일(항목)에 상속된 ACL과 일치한다.

그러나, 데이터 저장소 내의 포함 계층 구조는 항목에 대한 다수의 유지 관계들이 허용되기 때문에 방향성 비순환 그래프(DAG)이다. 이 조건 하에서, 포함 계층 구조의 루트로부터 항목으로의 다수의 경로가 존재한다. 항목은 모든 경로를 따라 ACL을 상속받기 때문에, 각각의 항목은 단일 ACL과는 반대인 ACL의 집합에 연관된다. 이것은 파일 또는 폴더에 단지 하나의 ACL만이 연관되는 종래 파일 시스템 모델과 다르다는 것을 명심하자.

포함 계층 구조가 트리가 아니라 DAG일 때 정성들여 만들 필요가 있는 두 개의 양태가 있다. 항목이 자신의 부모로부터 둘 이상의 ACL을 상속받을 때 그 항목에 대한 효율적인 보안 정책이 어떻게 계산되는지에 대한 설명이 필요하며, 그들이 어떻게 체계화되고 표현되는지는 저장 플랫폼 데이터 저장소에 대한 보안 모델의 관리에 직접적으로 관련된다.

다음의 알고리즘은 주어진 항목에 주어진 주체에 대한 액세스 권리를 평가한다. 이 문서를 통해, 다음은 항목에 연관된 ACL을 설명한다.

Inherited_ACLs(ItemId) - 항목 식별자가 ItemId인 항목이 저장소 내의 자신의 부모로부터 상속받은 ACL들의 세트.

Explicit_ACL(ItemId) - 식별자가 ItemId인 항목에 대해 명시적으로 정의된 ACL.

상기 루틴은 원하는 액세스가 명시적으로 거절되지 않았으면, STATES_SUCCESS를 리턴하며, pGrantedAccess는 사용자가 원하는 어떤 권리가 특정된 ACL에 의해 주어졌는지를 결정한다. 원하는 액세스 중 어느 것이라도 명시적으로 거절되면, 루틴은 STATUS_ACCESS_DENIED를 리턴한다.

임의의 항목에서 정의된 보안 정책의 영향 범위는 데이터 저장소 상에 정의된 포함 계층 구조 내의 항목의 모든 자손들을 커버한다. 명시적인 정책이 정의된 모든 항목들에 대해서, 사실 포함 계층 내의 모든 자손들에 상속된 정책이 정의되어 있다. 모든 자손들에게 상속된 유효한 ACL은 상속된 각각의 ACL을 취하고, ACL 의 개시시에 상속가능한 ACE을 명시적인 ACL 내에 추가함으로써 획득된다. 이는 항목에 연관된 상속가능한 ACL의 세트를 의미한다.

폴더 항목에서 루트된 포함 계층 구조 내의 명시적인 보안 사양이 없으면, 폴더의 보안 사양이 포함 계층 구조 내의 그 항목의 모든 자손들에게 적용된다. 그러므로, 명시적인 보안 정책 사양이 제공된 모든 항목은 동일하게 보호된 항목들의 영역을 정의하고, 모든 항목에 대한 유효한 ACL은 그 항목에 대한 상속가능한 ACL 세트이다. 이는 트리인 포함 계층 구조의 경우에 영역을 완벽하게 정의할 것이다. 각각의 영역이 수와 연관되어 있으면, 단순히 항목과 함께, 그 항목이 속한 영역을 포함하는 것으로 충분할 것이다.

그러나, DAG인 포함 계층 구조에 대해서, 효과적인 보안 정책이 변경되는 포함 계층 구조 내의 포인트는 두 가지 종류의 항목에 의해 결정된다. 첫 번째는 명시적인 ACL이 특정된 항목이다. 전형적으로, 이것들은 관리자가 명시적으로 ACL을 특정한 포함 계층 구조 내의 포인트이다. 두 번째는 두 개 이상의 부모를 갖는 항목이며, 이 부모는 그들에 연관된 상이한 보안 정책을 갖는다. 전형적으로, 이들은 볼륨에 대해 특정된 보안 정책의 합류점이며, 새로운 보안 정책의 시작을 나타내는 항목이다.

이 정의에 의해, 데이터 저장소 내의 모든 항목들은 동일하게 보호되는 보안 영역의 루트인 것들과 그렇지 않은 것들의 두 개의 카테고리 중 하나에 속한다. 보안 영역을 정의하지 않은 항목도 분명히 하나의 보안 영역에 속한다. 트리의 경우에서와 같이, 항목에 대한 효과적인 보안은 항목과 함께 항목이 속해 있는 영역 을 특정함으로써 특정될 수 있다. 이는, 저장소 내에서 동일하게 보호되는 다양한 영역에 기초하여 저장 플랫폼 데이터 저장소의 보안을 관리하기 위한 간단한 모델을 이끌어낸다.

2. 보안 모델의 상세 설명

이 섹션은 포함된 ACL 및 보안 기술자 내의 개별적인 권리가 다양한 동작에 어떻게 영향을 주는지를 설명함으로써 항목이 어떻게 보안되는지에 대한 상세를 제공한다.

a) 보안 기술자 구조

보안 모델의 상세를 설명하기 전에, 보안 기술자에 대한 기초 설명이 유용하다. 보안 기술자는 보안가능한 객체에 연관된 보안 정보를 포함한다. 보안 기술자는 SECURITY_DESCRIPTOR 구조 및 그에 연관된 보안 정보로 구성된다. 보안 기술자는 다음의 보안 정보를 포함할 수 있다:

1. 객체의 소유자 및 주요 그룹에 대한 SID.

2. 특정한 사용자 또는 그룹에 허용된 또는 거절된 액세스 권리를 특정 DACL.

3. 객체에 대한 감사 레코드를 생성하려고 시도하는 액세스의 타입을 특정하는 SACL.

4. 보안 기술자 또는 그것의 개별적인 멤버들에 의미를 부여하는 제어 비트 의 세트.

가급적, 애플리케이션은 보안 기술자의 콘텐츠를 직접적으로 조작할 수 없다. 객체의 보안 기술자 내의 보안 정보를 설정하고 리트리브하기 위한 기능이 존재한다. 이외에, 새로운 객체에 대한 보안 기술자를 생성하고 초기화하기 위한 기능도 존재한다.

임의 액세스 제어 리스트(DACL)는 보안가능한 객체들에의 액세스가 허용된 또는 거절된 트러스티(trustee)를 식별한다. 프로세스가 보안가능한 객체에 액세스하려고 시도할 때, 시스템은 객체 DACL 내의 ACE를 체크하여 그것에 액세스를 줄지를 판정한다. 객체가 DACL을 갖지 않으면, 시스템은 모두에게 전체 액세스를 준다. 객체의 DACL이 ACE를 하나도 갖지 않으면, DACL이 어떤 액세스 권리도 허용하지 않는 것이기 때문에 시스템은 객체에 액세스하기 위한 모든 시도를 거절한다. 시스템은 요청된 액세스 권리들 모두를 허용하는 하나 이상의 ACE를 찾아 내거나 요청된 액세스 권리 중 임의의 것이 거절될 때까지 일련의 ACE를 체크한다.

시스템 액세스 제어 리스트(SACL)는 로그 시도들에 대한 관리자가 보안되는 객체에 액세스할 수 있게 한다. 각각의 ACE는 시스템이 보안 이벤트 로그 내에 레코드를 생성하게 하는 특정 트러스티를 사용하여 액세스 시도의 타입을 특정한다. SACL 내의 ACE는 액세스 시도가 실패했을 때, 성공했을 때, 또는 둘 다의 경우에 감사 레코드를 생성할 수 있다. SACL은 또한 인증되지 않은 사용자가 객체에의 액세스를 획득하려고 시도할 때 경보를 울릴 수 있다.

모든 ACE 타입은 다음의 액세스 제어 정보를 포함한다:

1. ACE가 적용되는 트러스티를 식별하는 보안 식별자(SID)

2. ACE가 제어하는 액세스 권리를 특정하는 액세스 마스크

3. ACE의 타입을 나타내는 플래그

4. 자식 컨테이너 또는 객체가 ACL이 첨부된 주요 객체로부터 ACE를 상속받을 수 있는지를 판정하는 비트 플래그 세트

다음의 테이블은 모든 보안가능한 객체들에 의해 지원되는 세 개의 ACE 타입을 리스트한다.

타입	설명
액세스-거절된 ACE	DACL 내에서 트러스티에 액세스 권리를 거절하기 위해 사용됨.
액세스-허용된 ACE	ACL 내에서 트러스티에 액세스 권리를 허용하기 위해 사용됨.
시스템-감시 ACE	SACL 내에서 트러스티가 특정된 액세스 권리를 행사하려고 시도할 때 감사 레코드를 생성하기 위해 사용됨.

(1) 액세스 마스크 포맷

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

(2) 일반 액세스 권리

일반 권리는 마스크 내의 4개의 높은 순위의 비트 내에 특정된다. 각 타입의 보안가능한 객체는 이러한 비트들을 표준 및 객체 특정 액세스 권리의 세트에 매핑한다. 예를 들어, 파일 객체는 GENERIC_READ 비트를 READ_CONTROL 및 SYNCRONIZE 표준 액세스 권리, 그리고 FILE_READ_DATA, FILE_READ_EA, 및 FILE_READ_ATTRIBUTES 객체 특정 액세스 권리에 매핑한다. 다른 타입의 객체는 GENERIC_READ 비트를 그 타입의 객체에 적절한 아무 액세스 권리 세트에나 매핑한다.

일반 액세스 권리는 객체에 대한 처리를 열 때 필요한 액세스의 타입을 특정하는 데 사용될 수 있다. 이는 전형적으로 대응하는 표준 및 특정 권리 모두를 특정하는 것보다 간단하다. 다음 테이블은 일반 액세스 권리에 대해 정의된 상수(constant)를 나타낸다.

상수	일반 의미
GENERIC_ALL	판독, 기록, 및 실행 액세스
GENERIC_EXECUTE	실행 액세스
GENERIC_READ	판독 액세스
GENERIC_WRITE	기록 액세스

(3) 표준 액세스 권리

각 타입의 보안가능한 객체는 그 타입의 객체에 특정한 동작에 대응하는 액세스 권리 세트를 갖는다. 이들 객체 특정 액세스 권리 이외에, 대부분의 타입의 보안가능한 객체에 공통적인 동작에 대응하는 표준 액세스 권리의 세트가 존재한다. 다음의 테이블은 표준 액세스 권리에 대해 정의된 상수를 나타낸다.

상수	의미
DELETE	객체를 삭제하기 위한 권리
READ_CONTROL	SACL 내의 정보를 제외한 객체 보안 식별자 내의 정보를 판독하기 위한 권리
SYNCHRONIZE	객체를 동기화하기 위한 권리. 이는 스레드가, 객체가 시그널링된 상태일 때까지 대기할 수 있게 함. 몇몇 객체 타입은 이 액세스 권리를 지원하지 않음.
WRITE_DAC	객체 보안 기술자 내의 DACL을 수정하기 위한 권리
WRITE_OWER	객체 보안 기술자 내의 소유자를 변경하기 위한 권리

b) 항목 특정 권리

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

(1) 파일 및 디렉토리 객체 특정 권리

다음의 테이블을 고려하자:

디렉토리	디렉토리 설명	파일	파일 설명	값
FILE_LIST_DIRECTORY	디렉토리의 콘텐츠를 리스트하기 위한 권리	FILE_READ_DATA	대응하는 파일 데이터를 판독하기 위한 권리	0x0001
FILE_ADD_FILEX	디렉토리에 파일을 생성하기 위한 권리	FILE_WRITE_DATA	파일에 데이터를 기록하기 위한 권리	0x0002
FILE_ADD_SUBDIRECTORY	서브디렉토리를 생성하기 위한 권리	FILE_APPEND_DATA	파일에 데이터를 첨부하기 위한 권리	0x0004
FILE_READ_EA	확장된 파일 속성을 판독하기 위한 권리	FILE_READ_EA	확장된 파일 속성을 판독하기 위한 권리	0x0008
FILE_WRITE_EA	확장된 파일 속성을 기록하기 위한 권리	FILE_WRITE_EA	확장된 파일 속성을 기록하기 위한 권리	0x0010
FILE_TRAVERSE	디렉토리를 트래버싱(traversing)하기 위한 권리	FILE_EXECUTE	원시 코드 파일에 대해서, 파일을 실행하기 위한 권리	0x0020
FILE_DELETE_CHILD	디렉토리 및 그것이 포함한 모든 파일을 삭제하기 위한 권리	없음	없음	0x0040
FILE_READ_ATTRIBUTES	디렉토리 속성을 판독하기 위한 권리	FILE_READ_ATTRIBUTES	파일 속성을 판독하기 위한 권리	0x0080
FILE_WRITE_ATTRIBUTES	디렉토리 속성을 기록하기 위한 권리	FILE_WRITE_ATTRIBUTES	파일 속성을 기록하기 위한 권리	0x0100

상기 테이블을 참조하여, 파일 시스템이 파일과 디렉토리 사이의 근본적인 구별을 만든다는 것(왜 파일 권리와 디렉토리 권리가 동일한 비트에 오버랩되는 지)을 명심하자. 파일 시스템은 애플리케이션이 이러한 객체들에 대한 거동을 제어하도록 허용하는 매우 입상적인 권리를 정의한다. 예를 들어, 그들은 애플리케이션이 파일에 연관된 속성(FILE_READ/WRITE_ATTRIBUTES), 확장된 속성, 및 DATA 스트림을 구별하는 것을 허용한다.

예를 들어, 본 발명의 저장 플랫폼의 보안 모델의 목적은 권리 할당 모델을 단순화시켜, 데이터 저장소 항목(연락처, 이메일 등)에 대해서 동작하는 애플리케 이션이 일반적으로, 속성, 확장된 속성, 및 데이터 스트림을 구별할 필요 없게 하는 것이다. 그러나, 파일 및 폴더에 대해서, 입상적인 Win32 권리를 보호하고, 저장 플랫폼을 통한 액세스의 시맨틱이 정의됨으로써, Win32 애플리케이션과의 호환성 제공될 수 있다. 이 매핑은 다음에 특정된 각각의 항목 권리에 의해 설명된다.

다음의 항목 권리는 연관된 허용가능한 동작에 의해 특정된다. 이러한 항목 권리들 각각을 지원하는 등가의 Win32 권리도 또한 제공된다.

(2) WinFSItemRead

이 권리는 삽입된 관계를 통해 항목에 링크된 항목들을 포함하는 항목의 모든 요소들에의 판독 액세스를 허용한다. 이것은 또한 유지 관계를 통해 이 항목에 링크된 항목들의 열거(또한 디렉토리 리스팅으로도 알려짐)를 허용한다. 이것은 참조 관계를 통해 링크된 항목의 명칭을 포함한다. 이 권리는 다음에 매핑된다:

파일:

(FILE_READ_DATA|SYNCHRONIZE)

폴더:

(FILE_LIST_DIRECTORY|SYNCHRONIZE)

시맨틱은 보안 애플리케이션이 WinFSItemReadData를 설정하고 상기 특정된 파일 권리의 조합으로 권리 마스크를 특정할 수 있다는 것이다.

(3) WinFSItemReadAttributes

이 권리는 파일 시스템이 기초 파일 속성과 데이터 스트림 사이를 구별하는 것과 같이 항목의 기초 속성에의 판독 액세스를 허용한다. 가급적, 이러한 기초 속성은 모든 항목들이 도출되는 기초 항목 내에 상주하는 것들이다. 이 권리는 다음에 매핑된다:

파일:

(FILE_READ_ATTRIBUTE)

폴더:

(FILE_READ_ATTRIBUTE)

(4) WinFSItemWriteAttributes

이 권리는 파일 시스템이 기초 파일 속성과 데이터 스트림 사이를 구별하는 것과 같이 항목의 기초 속성에의 기록 액세스를 허용한다. 가급적, 이러한 기초 속성은 모든 항목들이 도출되는 기초 항목 내에 상주한다. 이 권리는 다음에 매핑된다:

파일:

(FILE_WRITE_ATTRIBUTES)

폴더:

(FILE_WRITE_ATTRIBUTES)

(5) WinFSItemWrite

이 권리는 삽입 관계를 통해 링크된 항목들을 포함하는 항목의 모든 요소에 기록을 하기 위한 능력을 허용한다. 이 권리는 또한 다른 항목들에 삽입 관계를 추가 또는 삭제하기 위한 능력을 허용한다. 이 권리는 다음에 매핑된다:

파일:

(FILE_WRITE_DATA)

폴더:

(FILE_ADD_FILE)

저장 플랫폼 데이터 저장소에서, 항목과 폴더 간에는 차이가 없는데, 이는 항목도 또한 데이터 저장소 내의 다른 항목들과의 유지 관계를 가질 수 있기 때문이다. 이에 따라, FILE_ADD_SUBDIRECTORY(또는 FILE_APPEND_DATA) 권리를 가지면, 다른 항목들과의 관계의 소스인 항목을 가질 수 있다.

(6) WinFSItemAddLink

이 권리는 저장소 내의 항목에 유지 관계를 추가하기 위한 권리를 허용한다. 다수의 유지 관계에 대한 보안 모델이 항목에 대한 보안을 변경하며, 이 변경이 계층 구조 내의 보다 높은 포인트로부터 온 것이면, WRITE_DAC를 우회할 수 있기 때문에, 그것과의 관계를 생성할 수 있기 위해 목적지 항목에 대한 WRITE_DAC가 요청된다. 이 권리는 다음에 매핑된다:

파일:

(FILE_APPEND_DATA)

폴더:

(FILE_ADD_SUBDIRECTORY)

(7) WinFSItemDeleteLink

이 권리는 항목을 삭제하기 위한 권리가 주체에 주어지지 않았더라도, 항목의 유지를 삭제하기 위한 능력을 허용한다. 이것은 파일 시스템 모델에 일관적이며, 정화를 돕는다. 이 권리는 다음에 매핑된다:

파일:

(FILE_DELETE_CHILD) - 파일 시스템은 이 권리에 대한 파일 등가물을 갖지 않지만, 우리는 다른 것과의 유지 관계를 갖는 항목에 대한 개념을 가지며, 이에 따라 비 폴더에 대해서도 이 권리가 전달된다는 것을 명심하자.

폴더:

(FILE_DELETE_CHILD)

(8) 항목을 삭제하기 위한 권리

항목에의 마지막 보유 관계가 사라지면, 항목은 삭제된다. 항목을 삭제하는 것에 대한 명시적인 개념은 없다. 항목과의 모든 유지 관계를 삭제하는 정화 동작은 있지만, 그것은 고레벨 기능이며, 시스템 기본은 아니다.

경로를 사용하여 특정된 임의의 항목은 (1) 경로에 따른 부모 항목이 주체에의 기록 액세스를 주지 않거나 (2) 항목에 대한 표준 권리가 DELETE를 주는 두 개의 조건 중 하나를 만족하면, 링크가 해제될 수 있다. 마지막 관계가 제거되면, 항목은 시스템으로부터 사라진다. ItemID를 사용하여 특정된 임의의 항목은, 항목에 대한 표준 권리가 DELETE를 주면 링크가 해제될 수 있다.

(9) 항목을 복사하기 위한 권리

주체에게 항목에 대한 WinFSItemRead, 및 목적지 폴더에 대한 WinFSItemWrite가 주어지면, 항목은 소스로부터 목적지 폴더로 복사될 수 있다.

(10) 항목을 이동하기 위한 권리

파일 시스템 내에서의 파일 이동은 소스 파일에 대한 DELETE 권리, 및 목적지 디렉토리에 대한 FILE_ADD_FILE 만을 요청하며, 이는 그것이 목적지에 대한 ACL를 보호하기 때문이다. 그러나, 플래그는 애플리케이션이 교차-볼륨 이동의 경우에 CopyFile 시맨틱을 허용할 수 있다는 것을 특정하게 하는 MoveFileEx 호출(MOVEFILE_COPY_ALLOWED)로 특정될 수 있다. 이동시에 보안 기술자에 의해 무엇이 발생하는지에 관한 잠재적인 4가지 선택이 있다:

1. 파일과 함께 전체 ACL를 이동시킴 - 디폴트 인트라-볼륨 이동 시맨틱.

2. 파일과 함께 전체 ACL를 이동시키고 ACL를 보호된 것으로 표식함.

3. 명시적인 ACE만을 이동시키고 목적지 상에 다시 상속받음.

4. 아무것도 이동시키지 않고, 목적지 상에 다시 상속받음 - 디폴트 인터-볼륨 이동 시맨틱 - 파일 복사와 같음.

본 보안 모델에서, 애플리케이션이 MOVEFILE_COPY_ALLOWED 플래그를 특정하 면, 이 4가지 선택은 인터 및 인트라 볼륨 경우 모두에 대해서 수행된다. 플래그가 특정되지 않았으면, 목적지가 동일한 보안 영역(즉, 동일한 상속성 시맨틱) 내에 있지 않는 이상 제2 옵션이 수행된다. 저장 플랫폼 레벨 이동은 제4 선택을 구현하고, 사본과 같은 소스에 대한 READ_DATA를 요청한다.

(11) 항목에 대한 보안 정책을 보기 위한 권리

항목이 주체에게 표준 권리 READ_CONTROL을 주면, 항목의 보안이 보여질 수 있다.

(12)항목에 대한 보안 정책을 변경하기 위한 권리

항목이 주체에게 표준 권리 WRITE_DAC를 주면, 항목의 보안은 변경될 수 있다. 그러나, 데이터 저장소가 내재적 상속성을 제공하면, 이것은 보안이 계층 구조 상에서 어떻게 변경될 수 있는지를 의미한다. 계층 구조의 루트가 WRITE_DAC을 주면, 계층 구조(또는 DAG) 내의 특정 항목이 주체에게 WIRTE_DAC를 주지 않았는지에 상관없이 보안 정책이 전체 계층 구조 상에서 변경된다는 것이 규칙이다.

(13) 직접적인 등가물을 갖지 않을 권리

본 실시예에서, FILE_EXECITE(디렉토리에 대한 FILE_TRAVERSE)는 저장 플랫폼 내에 직접적인 등가물을 갖지 않는다. 모델은 Win32 호환성을 위해서 이것들을 유지하고 있지만, 이러한 권리에 기초하여 항목에 대해 행해지는 어떤 액세스 결정 도 하지 않는다. FILE_READ/WRITE_EA와 같이, 데이터 저장소 항목이 확장된 속성에 대한 개념을 갖지 않기 때문에, 이 비트에 대한 시맨틱은 제공되지 않는다. 그러나, 이 비트는 Win32 호환성을 위해 남아있는다.

3. 구현

동일하게 보호된 영역을 정의하는 모든 항목들은 보안 테이블 내에 그들에 관련된 엔트리를 갖는다. 보안 테이블을 다음과 같이 정의된다:

항목 식별자

아이템 순서 경로(Item Ordpath)

명시적인 항목 ACL

경로 ACL

영역 ACL

항목 식별자 엔트리는 동일하게 보호된 보안 영역의 루트의 항목 식별자이다. 항목 순서 경로 엔트리는 동일하게 보호되는 보안 영역의 루트에 연관된 순서 경로이다. 명시적인 항목 ACL 엔트리는 동일하게 보호되는 보안 영역의 루트에 대한 정의된 명시적인 ACL이다. 몇몇의 경우에, 이것은 NULL일 수 있는데, 예를 들어, 항목이 상이한 영역에 속한 다수의 부모를 가지는 것으로 인해, 새로운 보안 영역이 정의될 때 그러하다. 경로 ACL 엔트리는 항목에 상속된 ACL의 세트이며, 영역 ACL 엔트리는 항목에 연관된 동일하게 보호되는 보안 영역에 대해 정의된 ACL의 세트이다.

주어진 저장소 내의 임의의 항목에 대해 효과적인 보안에 대한 계산은 이 테이블에 영향을 준다. 항목에 연관된 보안 정책을 결정하기 위해, 항목에 연관된 보안 영역이 획득되고 그 영역에 연관된 ACL이 리트리브된다.

항목에 관련된 보안 정책은 직접적으로 명시적인 ACL을 추가하거나 간접적으 로 새로운 보안 영역에 대한 공식을 생성하는 유지 관계를 추가함으로써 변경되므로 보안 테이블은 항목의 효과적인 보안을 결정하기 위한 상기 알고리즘이 유효하다는 것을 보증하기 위해 계속 갱신된다.

보안 테이블을 유지하기 위한 저장소에의 다양한 변경 및 동반 알고리즘은 다음과 같다:

a) 컨테이너 내에 새로운 아이템 생성

항목이 컨테이너 내에 새롭게 생성될 때, 그것은 컨테이너에 연관된 모든 ACL들을 상속받는다. 새롭게 생성된 항목은 단 하나의 부모만을 가지기 때문에, 그것은 자신의 부모와 동일한 영역에 속한다. 따라서 보안 테이블에 새로운 엔트리를 생성할 필요가 없다.

b) 항목에 명시적인 ACL 추가

ACL이 항목에 추가될 때, 그것은 주어진 항목과 동일한 보안 영역에 속하는 포함 계층 구조 내의 자신의 자손들 모두에 대한 새로운 보안 영역을 정의한다. 포함 계층 구조 내의 주어진 항목의 자손들이지만 다른 보안 영역에 속한 모든 항목에 대해서, 보안 영역은 변경되지 않은 채로 남아 있지만 그 영역에 연관된 효과적인 ACL은 새로운 ACL의 추가를 반영하도록 변경된다.

이 새로운 보안 영역의 소개는, 옛 보안 영역과 새롭게 정의된 보안 영역을 스트래들(straddle)하고 있는 조상들과 다수의 유지 관계를 갖고 있는 모든 항목들 에 대한 더한 영역 정의를 트리거할 수 있다.

도 27a, b, 및 c는 새로운 명시적인 ACL을 도입함으로써 기존 보안 영역으로부터 분리되는 새로운 동일하게 보호되는 보안 영역을 나타낸다. 이것은 참조번호 2로 표시된 노드에 의해 나타내진다. 그러나, 항목이 다수의 유지 관계를 갖고 있기 때문에, 이 새로운 영역의 소개는 추가적인 영역 3을 생성한다.

다음의 보안 테이블의 일련의 갱신은 동일하게 보호되는 보안 영역의 인수분해를 반영한다.

c) 항목에 유지 관계 추가

유지 관계는 항목에 추가될 때, 세 가지 가능성 중 하나를 발생시킨다. 유지 관계의 타겟, 즉 조건 하의 항목이 보안 영역의 루트이면, 영역에 관련된 효과적인 ACL은 변경되고 보안 테이블에 대한 수정이 더 이상 요청되지 않는다. 새로운 유지 관계의 소스의 보안 영역이 항목의 기존 부모의 보안 영역과 동일하면, 변경이 요청되지 않는다. 그러나, 항목이 상이한 보안 영역에 속한 부모를 가지면, 보안 영역의 루트로 주어진 항목을 갖는 새로운 보안 영역이 형성된다. 이 변경은 항목에 연관된 보안 영역을 수정함으로써 포함 계층 구조 내의 모든 항목들에게 전파된다. 조건 하의 항목과 동일한 보안 영역에 속한 모든 항목들 및 포함 계층 구조 내의 그것의 자손들은 변경될 필요가 있다. 일단 변경되면, 다수의 유지 관계를 갖는 항목들 모두는 변경이 더 요청되는지를 판정하기 위해 검사되어야 한다. 이러한 항목 중 임의의 것이 상이한 보안 영역의 부모를 가지면, 변경이 더 요청될 수 있다.

d) 항목으로부터 유지 관계를 삭제

보유 관계가 항목으로부터 삭제될 때, 소정의 조건이 만족되면, 한 보안 영역이 그것의 부모 영역과 함께 붕괴될 가능성이 있다. 보다 정확하게, 이것은 (1) 유지 관계의 제거가 하나의 부모를 갖는 항목을 생성하면 그 항목에 대한 어떤 명시적인 ACL도 특정되지 않고, (2) 유지 관계의 제거가 부모들이 모두 동일한 보안 영역 내에 있는 항목을 생성하면 그 항목에 대한 어떤 명시적인 ACL도 특정되지 않는다는 조건 하에서 이루어질 수 있다. 이러한 환경하에서, 보안 영역은 부모와 동일하게 표식될 수 있다. 이 표식은 보안 영역이 붕괴된 영역에 대응하는 항목들 모두에 적용될 필요가 있다.

e) 항목으로부터 명시적인 ACL 삭제

명시적인 ACL이 항목으로부터 삭제될 때, 그 항목에서 루트된 보안 영역은 자기 부모의 보안 영역으로 붕괴될 수 있다. 보다 정확하게, 이것은, 명시적인 ACL의 제거가 포함 계층 구조 내의 부모가 동일한 보안 영역에 속해 있는 항목을 생성하면, 행해질 수 있다. 이 환경에서, 보안 영역은 부모와 동일하게 표식될 수 있으며, 변경은 보안 영역이 붕괴된 영역에 대응하는 모든 항목에 적용될 수 있다.

f) 항목에 관련된 ACL 수정

이 시나리오에서, 보안 테이블에 어떠한 새로운 추가도 요청되지 않는다. 영역에 연관된 유효한 ACL이 갱신되고, 새로운 ACL 변경이 그것에 의한 영향을 받는 보안 영역에 전파된다.

F. 통지 및 변경 추적

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

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

1. 저장 변경 이벤트

이 섹션은 저장 플랫폼 API(322)에 의해 제공된 통지 인터페이스가 어떻게 사용되는지의 몇몇 예를 제공한다.

a) 이벤트

항목, 항목 확장, 및 항목 관계는 데이터 변경 통지에 대해 등록하기 위해 애플리케이션이 사용하는 데이터 변경 이벤트를 노출시킨다. 다음의 코드 샘플은 기초 항목 클래스에 대한 ItemModified 및 ItemRemoved 이벤트 핸들러(handler)들의 정의를 나타낸다.

모든 통지들은 데이터 저장소로부터 변경된 항목을 리트리브하기에 충분한 데이터를 전달한다. 다음의 코드 샘플은 항목, 항목 확장, 및 항목 관계에 대한 이벤트들에 대해서 어떻게 등록해야 할지를 나타낸다:

본 실시예에서, 저장 플랫폼은, 마지막으로 전달된 이후 개별 항목이 수정 또는 삭제되면, 또는 데이터 저장소로부터의 마지막 패치 이후 새로운 등록이 행해진 경우에 통지가 애플리케이션에 통지될 것을 보증한다.

b) 감시자

본 실시예에서, 저장 플랫폼은 (1) 폴더 또는 폴더 계층 구조, (2) 항목 문맥, 또는 (3) 특정 항목에 연관된 객체를 모니터하기 위한 감시자 클래스를 정의한다. 세 가지 카테고리 각각에 대해서, 저장 플랫폼은 연관된 항목, 항목 확장, 또는 항목 관계를 모니터하는 특정한 감시자 클래스를 제공하는데, 예를 들어, 저장 플랫폼은 각각 FolderItemWatcher, FolderRelationshipWatcher, 및 FolderExtensionWatcher 클래스를 제공한다.

감시자를 생성할 때, 애플리케이션은 기존 항목, 즉 항목, 확장 또는 관계에 대한 통지를 요청할 수 있다. 이 옵션은 대개 사적 항목 캐시(cache)를 유지하는 애플리케이션에 대한 것이다. 요청되지 않았으면, 애플리케이션은 감시자 객체가 생성된 이후 일어나는 모든 갱신에 관한 통지를 수신한다.

통지를 전달하면서, 저장 플랫폼은 "WatcherState" 객체를 제공한다. WatcherState는 직렬화되어 디스크 상에 저장된다. 그 후 감시자 상태는 실패한 후에 또는 오프-라인이 된 후 재접속할 때 개별 감시자를 재생성하기 위해 사용될 수 있다. 새롭게 재생성된 감시자는 수신확인되지 않은 통지를 재생성할 것이다. 애플리케이션은 "Exclude" 메소드를 호출함으로써 통지에 참조를 제공하는 개별 감시자 상태 상에 통지의 전달을 나타낸다.

저장 플랫폼은 감시자 상태의 개별적인 사본을 각각의 이벤트 핸들러에 전달한다. 동일한 이벤트 핸들러의 다음 호출 상에서 수신된 감시자 상태는 이전에 수신된 모든 통지의 전달을 가정한다.

예를 들어, 다음의 코드 샘플은 FolderItemWatcher의 정의를 나타낸다.

다음의 코드 샘플은 폴더의 콘텐츠를 모니터하기 위한 폴더 감시자 객체를 어떻게 생성해야하는지를 나타낸다. 감시자는 새로운 음악 항목이 추가되거나 기존 음악 항목이 갱신 또는 삭제될 때, 통지, 즉, 이벤트를 생성한다. 폴더 감시자는 특정한 폴더 또는 폴더 계층 구조 내의 모든 폴더들을 모니터한다.

2. 변경 추적 및 통지 생성 메커니즘

저장 플랫폼은 데이터 변경을 추적하고 통지를 생성하기 위한 단순하지만 유효한 메커니즘을 제공한다. 클라이언트는 데이터를 리트리브하는 데 사용되는 동일한 접속에 대한 통지를 리트리브한다. 이것은 주로 보안 체크를 단순화하고, 지연을 제거하며, 가능한 네트워크 구성을 제한한다. 통지는 선택 스테이트먼트 (select statement)를 발행함으로써 리트리브된다. 폴링을 방지하기 위해, 클라이언트는 데이터베이스 엔진(314)이 제공하는 "waitfor" 기능을 사용할 수 있다. 도 13은 기본적인 저장 플랫폼 통지 개념을 나타낸다. 이 waitfor 질의는, 결과가 사용가능하게 되기 전까지 호출 스레드가 차단되는 경우에 동기적으로, 또는 그 스레드가 차단되지 않고 결과가 개별 스레드에 리턴된 경우(사용이능한 때)에 비동기적으로 실행될 수 있다.

"waitfor" 및 "select"의 조합은 변경이 개별 데이터 영역 상에 통지 잠금을 설정함으로써 모니터될 수 있을 때 특정한 데이터 범위에 맞는 데이터 변경을 모니터하기에 좋다. 이것은 여러 공통 저장 플랫폼 시나리오를 유지한다. 개별적인 항목에의 변경은 개별 데이터 영역 상에 통지 잠금을 설정함으로써 효율적으로 모니터될 수 있다. 폴더 및 폴더 트리에의 변경은 경로 영역 상에 통지 잠금을 설정함으로써 모니터될 수 있다. 타입 및 그것의 서브타입에의 변경은 타입 영역 상에 통지 잠금을 설정함으로써 모니터될 수 있다.

일반적으로, 통지를 처리하는 것에 연관된 (1) 데이터 변경 또는 심지어 탐지, (2) 가입 일치, 및 (3) 통지 전달의 세 가지의 별개의 페이즈(phase)들이 존재한다. 동기적인 통지 전달, 즉 데이터 변경을 수행하는 트랜젝션의 일부로서의 통지 전달을 제외하고, 저장 플랫폼은 두 개의 통지 전달 형태를 구현할 수 있다:

1) 즉각적인 이벤트 탐지: 이벤트 탐지 및 가입 일치는 갱신 트랜젝션의 일부로서 수행된다. 통지는 가입자에 의해 모니터되는 테이블에 삽입된다.

2) 연기된(deferred) 이벤트 탐지: 이벤트 탐지 및 가입 일치는 갱신 트랜젝 션이 행해지고 난 이후 수행된다. 그 후, 실제 가입자 또는 매개물은 이벤트를 탐지하고 통지를 생성한다.

즉각적인 이벤트 탐지는 추가적인 코드가 갱신 동작의 일부로 실행될 것을 요청한다. 이것은 관련 상태 변경을 나타내는 이벤트들을 포함하는 관련 이벤트 모두를 캡쳐하는 것을 허용한다.

연기된 이벤트 탐지는 동작을 갱신하기 위해 추가적인 코드를 추가할 필요성을 제거한다. 이벤트 탐지는 궁극적인 가입자에 의해 행해진다. 연기된 이벤트 탐지는 이벤트 탐지 및 이벤트 전달을 자연스럽게 일괄처리하며, 데이터베이스 엔진(314)(예를 들어, SQL 서버)의 질의 실행 기반구조에 잘 맞는다.

연기된 이벤트 탐지는 로그 또는 갱신 동작에 의해 남겨진 흔적에 응답한다. 저장 플랫폼은 삭제된 데이터 항목에 대한 묘비와 함께 논리적인 타임 스탬프 세트를 유지한다. 변경을 위해 데이터 저장소를 스캔할 때, 클라이언트는 변경을 탐지하기 위한 낮은 워터마크(watermark)를 정의하는 타임 스탬프, 및 중복 통지를 방지하기 위한 타임 스탬프 세트를 제공한다. 애플리케이션은 낮은 워터마크가 나타낸 시간 이후 발생하는 모든 수정에 대한 통지를 수신할 수 있다.

코어 뷰에의 액세스를 가진 세련된 애플리케이션은 사적인 매개변수 및 중복 필터 테이블을 생성함으로써 잠재적으로 큰 항목 세트를 모니터하기 위해 필요한 SQL 스테이트먼트를 최적화하고 그것의 개수를 줄일 수 있다. 풍부한 뷰를 지원해야 하는 것들과 같은 특별한 요구들을 갖는 애플리케이션은 데이터 변경을 모니터하고 그들의 사적인 스냅샷(snapshot)을 복구하기 위해 사용가능한 변경 추적 프레 임워크를 사용할 수 있다.

그러므로, 일 실시예에서, 가급적으로 저장 플랫폼은 다음에 보다 완벽하게 설명된 바와 같이 연기된 이벤트 탐지 접근법을 구현한다.

a) 변경 추적

모든 항목, 확장 및 항목 관계 정의는 고유한 식별자를 갖는다. 변경 추적은 모든 데이터 항목에 대한 생성, 갱신 및 삭제 시간을 기록하기 위해 논리적인 타임 스탬프의 세트를 유지한다. 삭제된 데이터 항목을 나타내기 위해 묘비 엔트리가 사용된다.

애플리케이션은 그 정보를 사용하여, 애플리케이션이 마지막으로 데이터 저장소에 액세스한 이후 특정한 항목, 항목 확장, 또는 항목 관계가 새롭게 추가, 갱신 또는 삭제되었는지를 효율적으로 모니터한다. 다음의 예는 이 메커니즘을 나타낸다.

모든 삭제된 항목, 항목 확장 및 관계는 대응하는 묘비 테이블에 기록된다. 다음에 템플릿(template)이 나타내진다.

효율성을 위해, 저장 플랫폼은 항목, 항목 확장, 관계 및 경로 명칭에 대한 글로벌 테이블 세트를 유지한다. 이러한 글로벌 룩업 테이블(global lookup table)은 효율적으로 데이터 영역을 모니터하고 연관된 타임 스탬프 및 타입 정보를 리트리브하기 위해 애플리케이션에 의해 사용될 수 있다.

b) 타임 스탬프 관리

논리적인 타임 스탬프는 데이터베이스 저장소, 즉 저장 플랫폼 볼륨에 "로컬"이다. 타임 스탬프는 단조롭게 64-비트 값으로 증가한다. 단일 타임 스탬프를 보유하는 것은, 종종 저장 플랫폼 볼륨에의 마지막 접속 이후 데이터가 변경됐는지를 탐지하기에 충분하다. 그러나, 대부분의 현실적인 시나리오에서는, 중복을 계속적으로 체크하기 위해 몇 개의 타임 스탬프가 더 필요하다. 그 이유에 다음에 설명된다.

관계형 데이터베이스 테이블은 물리적인 데이터 구조(즉, B-트리, 힙 등)의 세트의 상부에 구축된 논리적인 추상화이다. 새롭게 생성되거나 갱신된 레코드에 타임 스탬프를 할당하는 것은 최소단위 동작(atomic action)이 아니다. 그 레코드를 기초 데이터 구조에 삽입하는 것은 상이한 시간에 발행할 수 있으며, 따라서 애플리케이션은 레코드 순서가 흐트러졌다는 것을 알 수 있다.

도 14는 새로운 레코드를 동일한 B-트리에 삽입하는 두 개의 트랜젝션을 나타낸다. 트랜젝션 T3이 트랜젝션 T2의 삽입이 스케줄링되기 이전에 자신의 레코드를 삽입하기 때문에, B-트리를 스캔하는 애플리케이션은 T2에 의해 삽입된 것 이전 에 트랜젝션 T3에 의해 삽입된 레코드를 볼 수 있다. 이에 따라, 판독기는 시간 "10"까지 생성된 모든 레코드들을 보았다고 부정확하게 가정할 수 있다. 이 문제점을 해결하기 위해, 데이터베이스 엔진(314)은 모든 갱신이 행해지고 개별적인 기초 데이터 구조에 삽입되기 전까지 낮은 워터마크를 리턴하는 기능을 제공한다. 상기 예에서, 트랜젝션 T2가 행해지기 이전에 판독기가 시작되었다고 가정하면, 리턴된 낮은 워터마크는 "5"일 것이다. 데이터베이스 엔진(314)이 제공한 낮은 워터마크는 애플리케이션이 데이터베이스 또는 데이터 변경에 대한 데이터 영역을 스캔할 때 어느 항목을 무시해야하는지를 효율적으로 결정하는 것을 허용한다. 일반적으로, ACID 트랜젝션은 매우 단시간 동안만 지속되리라고 가정되며, 낮은 워터마크는 가장 최근에 분배된 타임 스탬프에 매우 근접하리라고 기대된다. 오래 지속되는 트랜젝션이 존재할 때, 애플리케이션은 중복을 탐지하고 삭제하기 위해 개별적인 타임 스탬프를 유지해야만 할 것이다.

c) 데이터 변경 탐지 - 이벤트 탐지

데이터 저장소를 질의할 때, 애플리케이션은 낮은 워터마크를 획득한다. 그 후, 애플리케이션은 그 워터마크를 사용하여 생성, 갱신 또는 삭제 타임 스탬프가 리턴된 낮은 워터마크보다 큰 엔트리를 찾기 위해 데이터 저장소를 스캔한다. 도 15는 이 프로세스를 나타낸다.

중복 통지를 방지하기 위해, 애플리케이션은 리턴된 낮은 워터마크보다 큰 타임 스탬프를 기억하고 있다가, 중복을 제거하기 위해 그들을 사용한다. 애플리 케이션은 큰 중복 타임 스탬프 세트를 효율적으로 관리하기 위해 세션 로컬 임시 테이블을 생성한다. select 스테이트먼트를 발행하기 전에, 다음에 나타낸 것처럼, 애플리케이션은 이미 리턴된 모든 중복 타임 스탬프를 삽입하고, 리턴된 마지막 낮은 워터마크보다 오래된 것들을 삭제한다.

E. 동기화

본 발명의 또 다른 양태에 따라, 저장 플랫폼은 (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) 스키마 주석 달기

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

스키마에 변경 단위를 표시하는 것은 여러 목적을 갖는다. 먼저, 이것은 유선 상에서 동기화 서비스의 채티(chatty) 정도가 어떤지를 판정한다. 변경 단위 내에서 변경이 행해질 때, 전체 변경 단위는 다른 사본들로 전송되는데, 이는 동기화 서비스가 변경 단위의 어느 부분이 변경되었는지를 알지 못하기 때문이다. 둘째, 이것은 충돌 검출의 입도를 결정한다. 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. 관리성

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

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

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

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

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

1. 연동성에 대한 모델

본 발명의 이 양태에 따르고, 전술된 실시예에 따르면, 저장 플랫폼은 비 파일 항목(non-file item) 및 파일 항목이 체계화될 수 있는 하나의 명칭 공간을 구현한다. 이 모델에 의해, 다음의 이점들이 취해진다:

1. 데이터 저장소 내의 폴더들은 파일 및 비 파일 항목 모두를 포함할 수 있으므로, 파일 및 스키마화된 데이터를 위한 단일 명칭 공간을 나타낸다. 또한, 이 것은 모든 사용자 데이터에 대해 균일한 보안, 공유 및 관리 모델을 제공한다.

2. 이 접근법에는 파일 및 비 파일 항목 모두가 저장 플랫폼 API를 사용하여 액세스가능하고 파일에 강요되는 특정한 규칙이 없기 때문에, 이것은 애플리케이션 개발자가 또다시 작업하기에 보다 좋은 프로그래밍 모델을 제시한다.

3. 모든 명칭 공간은 저장 플랫폼을 통해 전달되며, 이에 따라 동기적으로 처리된다. 깊은 속성 증진(파일 콘텐츠를 버림)은 여전히 비동기적으로 일어나지만, 동기적인 동작은 사용자와 애플리케이션에게 훨씬 더 예측가능한 환경을 제공한다는 것을 명심하는 것이 중요하다.

본 실시예에서, 이 모델의 결과로서, 저장 플랫폼 데이터 저장소로 이주되지 않는 데이터 소스에 대한 검색 능력이 제공되지 않을 수 있다. 이것은 분리형 매체, 원격 서버 및 로컬 디스크 상의 파일들을 포함한다. 외부 파일 시스템에 상주하는 항목에 대한 저장 플랫폼 내에 프록시 항목(쇼트컷 + 증진된 메타데이터)을 나타내는 동기화 어댑터가 제공된다. 프록시 항목은 데이터 소스의 명칭 공간 계층 구조의 관점 또는 보안의 관점에서 파일을 모방하려 하지 않는다.

파일 콘텐츠와 비 파일 콘텐츠 간의 프로그래밍 모델 및 명칭 공간 상에 이루어진 균형은 시간이 지남에 따라 파일 시스템으로부터 저장 플랫폼 데이터 저장소 내의 보다 구조화된 항목들로 콘텐츠를 이주하기 위한 보다 나은 경로를 애플리케이션에 제공한다. 저장 플랫폼 데이터 저장소 내의 원시 파일 항목 타입을 제공함으로써, 애플리케이션 프로그램은 Win32를 통해 여전히 파일 데이터를 조작할 수 있으면서 그 파일 데이터를 저장 플랫폼으로 이행시킬 수 있다. 결국, 애플리케이 션 프로그램은 저장 플랫폼 API로 완벽하게 이주시키고, 파일보다는 저장 플랫폼 항목의 관점에서 그들의 데이터를 구성할 수 있다.

2. 데이터 저장 기능

바람직한 연동성 레벨을 제공하기 위해, 일 실시예에서는 다음의 저장 플랫폼 데이터 저장소 기능이 구현된다.

a) 볼륨이 아님

저장 플랫폼 데이터 저장소는 개별적인 파일 시스템 볼륨으로 노출되지 않는다. 저장 플랫폼은 NTFS 상에 직접적으로 호스팅된 FILESTREAM들이 영향을 준다. 따라서, 온-디스크 포맷이 변경되지 않으며, 이에 따라 볼륨 레벨의 새로운 파일 시스템으로 저장 플랫폼을 노출시킬 필요가 없게 한다.

대신, 데이터 저장소(명칭 공간)는 NTFS 볼륨에 대응하게 구성된다. 이 명칭 공간의 일부분을 지원하는 데이터베이스 및 FILESTREAM은 저장 플랫폼 데이터 저장소가 연관된 NTFS 볼륨에 위치한다. 시스템 볼륨에 대응하는 데이터 저장소도 또한 제공된다.

b) 저장소 구조

저장소의 구조가 예와 함께 잘 예시되어 있다. 예를 들어, 도 16에 예시된 바와 같이, HomeMachine으로 명칭된 기기의 시스템 볼륨 상의 디렉토리 트리를 고 려해 보자. 본 발명의 파일 시스템 연동성 기능에 따라, C:＼drive에 대응하여, 예를 들어 "WinFSOnC"라고 불리는 UNC 공유를 통해 Win32 API에 노출된 저장 플랫폼 데이터 저장소가 존재한다. 이것은 ＼＼HomeMachine＼WinFSOnC란 UNC 명칭을 통해 연관된 데이터 저장소를 액세스가능하게 만든다.

이 실시예에서, 파일 및/또는 폴더는 명시적으로 NTFS로부터 저장 플랫폼으로 이주될 필요가 있다. 그러므로, 사용자가 저장 플랫폼에 의해 제공되는 잉여 검색/카테고리화 기능 모두를 사용하기 위해 My Document 폴더를 저장 플랫폼 데이터 저장소로 이동시키길 원하면, 계층 구조는 도 17에 나타낸 것처럼 보일 것이다. 이 예에서, 이러한 폴더들이 실제로 이동된다는 것을 명심하는 것이 중요하다. 명심해야할 또 다른 점은, 명칭 공간이 저장 플랫폼으로 이동하며, 실제 스트림이 저장 플랫폼 내의 훅업된(hookded up) 적절한 포인터를 가진 FILESTREAM으로 다시 명명된다는 것이다.

c) 모든 파일이 이주되지는 않음

사용자 데이터에 대응하거나 저장 플랫폼이 제공하는 검색/카테고리화를 필요로하는 파일들은 저장 플랫폼 데이터 저장소로 이주될 후보이다. 가급적으로, 저장 플랫폼과의 애플리케이션 프로그램 호환성에 대한 문제점을 제한하기 위해, 마이크로 윈도우즈 운영 체제의 관점에서, 본 발명의 저장 플랫폼으로 이주된 파일 세트는 MyDocument 폴더, 인터넷 익스플로러(IE) 즐겨찾기, IE 히스토리(IE History), 및 Document and Setting 디렉토리 내의 데스크탑 .ini 파일 내의 파일 에 한정된다. 가급적으로, 윈도우즈 시스템 파일의 이주는 허가되지 않는다.

d) 저장 플랫폼 파일에의 NTFS 명칭 공간 액세스

본원에 설명된 실시예에서, 저장 플랫폼으로 이주된 파일들은, 실제 파일 스트림이 NTFS에 저장되더라도 NTFS 명칭 공간을 통해 액세스되지 않는다. 이 방식으로, 멀티 헤디드(multi-headed) 구현으로부터 발생하는 복잡한 잠금 및 보안에 대해서는 고려하지 않아도 된다.

e) 확장된 명칭 공간/도출 문자

형태 ＼＼<machine name>＼<WinfsShareName>의 UNC 명칭을 통해 저장 플랫폼 내의 파일 및 폴더에의 액세스가 제공된다. 동작에 대한 도출 문자를 요청하는 애플리케이션의 클래스에 대해서, 도출 문자는 이 UNC 명칭으로 매핑될 수 있다.

I. 저장 플랫폼 API

저장 플랫폼은 애플리케이션 프로그램들이 전술한 저장 플랫폼의 기능 및 능력에 액세스하고 데이터 저장소에 저장된 항목들에 액세스하는 것을 가능하게 하는 API를 포함한다. 이 섹션은 본 발명의 저장 플랫폼의 저장 플랫폼 API의 일 실시예를 설명한다.

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

1. 개요

본 발명의 저장 플랫폼 API에 대한 본 실시예의 데이터 액세스 메커니즘은 질의, 네비게이션, 액션, 이벤트의 4가지 영역을 다룬다.

질의

일 실시예에서, 저장 플랫폼 데이터 저장소는 관계형 데이터베이스 엔진(314) 상에 구현되므로, 결과적으로, SQL 언어의 완벽한 표현력은 저장 플랫폼으로 상속된다. 보다 높은 레벨 질의 객체는 저장소를 질의하기 위한 단순화된 모델을 제공하지만, 저장의 완벽한 표현력을 캡슐화(encapsulate)할 수는 없다.

네비게이션

저장 플랫폼 데이터 모델은 기초 데이터베이스 추상화에 대한 풍부한 확장가능한 타입 시스템을 구축한다. 개발자에 대해서, 저장 플랫폼 데이터는 항목의 웹 이다. 저장 플랫폼 API는 필터링, 관계, 폴더 등을 통해 항목으로부터 항목으로의 네비게이션을 가능하게 한다. 이것은 기초 SQL 질의보다 높은 레벨의 추상화이며, 때때로, 풍부한 필터링 및 네비게이션 성능이 익숙한 CLR 코딩 패턴과 함께 사용되는 것을 허용한다.

액션

저장 플랫폼 API는 모든 항목들에 대한 공통 액션, 즉 생성, 삭제, 갱신을 객체에 대한 메소드로서 노출시킨다. 이외에, SendMail, CheckFreeBusy 등과 같은 도메인 특정 액션들도 메소드로서 사용가능하다. API 프레임워크는, ISV가 추가적인 액션을 정의함으로써 값을 추가하기 위해 사용할 수 있는 잘 정의된 패턴을 사용한다.

이벤트

저장 플랫폼 내의 데이터는 동적이다. 저장소 내의 데이터가 변경될 때 애플리케이션이 반응하게 하기 위해, API는 개발자에게 풍부한 이벤팅, 가입, 및 통지 능력을 노출한다.

2. 명명 및 범위

이것은 명칭 공간과 명명 사이를 구분하는 데 유용하다. 명칭 공간이란 용어는 일반적으로 사용되는 바와 같이 몇몇 시스템에서 사용가능한 모든 이름들의 세트를 참조한다. 이 시스템은 XML 스키마, 프로그램, 웹, 모든 ftp 사이트(및 그들의 콘텐츠)의 세트 등일 수 있다. 명명은 관심있는 모든 엔티티에 대한 고유한 명칭을 명칭 공간에 할당하기 위해 사용되는 프로세스 및 알고리즘이다. 그러므 로, 명명은 명칭 공간 내의 주어진 단위를 자명하게 참조하기에 바람직하기 때문에 중요하다. 따라서, 본원에 사용된 바와 같이 "명칭 공간"이란 용어는 실제 모든 저장 플랫폼 인스턴스 내에서 사용가능한 모든 명칭들의 세트를 참조한다. 항목은 저장 플랫폼 명칭 공간 내의 명명된 엔티티이다. UNC 명명 규약을 사용하여, 항목 명명의 고유성을 보증한다. 실제 모든 저장 플랫폼 저장소 내의 모든 항목은 UNC 명명에 의해 어드레싱가능하다.

저장 플랫폼 명칭 공간 내의 최고의 체계적 레벨은 단순히 저장 플랫폼의 인스턴스인 서비스이다. 체계화의 다음 레벨은 볼륨이다. 볼륨은 항목에 대한 최대의 자율 컨테이너(the largest autonomous container of items)이다. 각각의 저장 플랫폼 인스턴스는 하나 이상의 볼륨을 포함한다. 볼륨에는 항목이 있다. 항목은 저장 플랫폼 내의 데이터 최소단위이다.

실세계의 데이터는 거의 언제나 주어진 도메인 내에서 의미를 갖는 몇몇 시스템에 따라 체계화된다. 기초적인 모든 이러한 데이터 체계화 스키마는 데이터 모두를 명명된 그룹으로 나누는 것에 대한 개념이다. 전술된 바와 같이, 이 개념은 폴더 개념에 의해 저장 플랫폼 내에 모델링된다. 폴더는 항목의 특정한 타입이며, 포함 폴더 및 가상 폴더의 2가지 폴더 타입이 있다.

도 18을 참조하면, 포함 폴더는 다른 항목과의 유지 관계를 포함하는 항목 및 파일 시스템 폴더의 공통 개념과 등가물이다. 각각의 항목은 적어도 하나의 컨테이너 폴더에 "포함"된다.

가상 폴더는 항목들의 집합을 체계화하는 보다 동적인 방식이며, 단순히 항 목 세트가 주어진 명칭이다(상기 세트는 명시적으로 열거되거나 질의에 의해 특정됨). 가상 폴더는 자체로 항목이며, 항목 세트와의 (비 보유) 관계들의 세트를 나타내는 것으로 고려될 수 있다.

때때로, 컨테이너에 대한 보다 타이트한 개념을 모델링할 필요가 있으며, 예를 들어, 이메일 메시지에 삽입된 워드 문서는 폴더 내에 포함된 파일보다 그것의 컨테이너에 보다 밀접하게 결합된다. 이 개념은 삽입 항목의 개념에 의해 표현된다. 삽입 항목은 또 다른 항목을 참조하는 특정한 종류의 관계를 가지며, 참조된 항목은 포함하는 항목에 결합될 수 있거나 다른 한편으로 오직 그것의 문맥으로만 조정될 수 있다.

마지막으로, 저장 플랫폼은 항목 및 요소의 분류 수단으로 카테고리의 개념을 제공한다. 저장 플랫폼 내의 모든 항목 또는 요소는 하나 이상의 카테고리에 연관될 수 있다. 카테고리는 본질적으로 단순히 항목/요소에 태깅된 명칭이다. 이 명칭은 검색시에 사용될 수 있다. 저장 플랫폼 데이터 모델은 카테고리의 계층 구조에 대한 정의를 허용하며, 이에 따라 트리와 같은 데이터의 분류를 가능하게 한다.

항목에 대한 자명한 명칭은 (<serviceName>, <volumeID>, <ItemID>)의 세 개로 이루어져 있다. 몇몇 항목(구체적으로, 폴더 및 가상폴더)들은 다른 항목들의 집합이다. 이것은 항목을 식별하는 대안적인 방식(<serviceName>, <volumeID>, <itemPath>)을 제공한다.

저장 플랫폼 명칭은 서비스 문맥의 개념을 포함하며, 서비스 문맥은 (<volumeName>, <path>) 쌍으로 매핑되는 명칭이다. 이것은 항목 또는 항목 세트(예를 들어, 폴더, 가상 폴더 등)를 식별한다. 서비스 문맥의 개념에 의해, 저장 플랫폼 명칭 공간 내의 임의의 항목에 대한 UNC 명칭은 ＼＼<serviceName>＼<serviceContext>＼<itemPath>가 된다.

사용자는 서비스 문맥을 생성 및 삭제할 수 있다. 또한, 각각의 볼륨 내의 루트 디렉토리는 미리 정의된 문맥 volume-name$을 갖는다.

ItemContext는 특정된 경로 내에 살아있는 항목들에 리턴되는 결과를 제한함으로써 질의(예를 들어, 찾기 동작)의 범위를 정한다.

3. 저장 플랫폼 API 컴포넌트

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

본 발명의 일 양태에 따르면, 설계시에, 스키마 작성자는 저장 플랫폼 API 설계 시간 툴(2008)의 세트에 스키마 문서(2010) 및 도메인 메소드에 대한 코드(2012)를 제출한다. 이러한 툴은 클라이언트 측 데이터 클래스(2002) 및 저장 스키마(2014)를 생성하고, 그 스키마에 대한 클래스 정의(2016)를 저장한다. "도메인"은 특정한 스키마를 참조하며, 예를 들어, 연락처 스키마 등의 클래스에 대한 도메인 메소드에 대한 것이다. 이러한 데이터 클래스(2002)는 저장 플랫폼 데이터 를 조작하기 위해, (저장 플랫폼 API 실행시간 프레임워크 클래스(2006)와 협력하여) 애플리케이션 개발자에 의해 실행시간에 사용된다.

본 발명의 저장 플랫폼 API의 다양한 양상을 예시하기 위해, 예시적인 연락처 스키마에 기초한 예가 제시된다. 예시적인 스키마의 도시적 표현은 도 21a 및 21b에 예시된다.

4. 데이터 클래스

본 발명의 양태에 따르면, 저장 플랫폼 데이터 저장소 내의 각각의 관계뿐만 아니라 각각의 항목, 항목 확장, 및 요소 타입은 저장 플랫폼 API 내에 대응하는 클래스를 갖는다. 대략, 타입 필드는 클래스 필드로 매핑된다. 저장 플랫폼 내의 각각의 항목, 항목 확장, 및 요소는 저장 플랫폼 API 내의 대응하는 클래스의 객체로 사용가능하다. 개발자는 이러한 객체를 생성, 수정, 또는 삭제하기 위해 질의를 할 수 있다.

저장 플랫폼은 스키마의 초기 세트를 포함한다. 각각의 스키마는 항목과 요소 타입의 세트, 및 관계 세트를 정의한다. 다음은 이러한 스키마 엔티티로부터 데이터 클래스를 생성하기 위한 알고리즘의 일 실시예이다:

각각의 스키마 S에 대해서:

각각의 항목 I에 대해서, S 내에 System.Storage로 명명된 클래스 S.I가 생성된다. 이 클래스는 다음의 멤버들을 갖는다:

· 새로운 항목의 초기 폴더 및 명칭이 특정되는 것을 허용하는 구조자를 포 함하는 오버로드된 구조자(overloaded constructor)

· I 내의 각각의 필드에 대한 속성. 필드가 다수의 값을 가지면, 속성은 대응하는 요소 타입의 집합일 것임.

· 필터와 일치하는 다수의 항목들을 찾는 오버로드된 정적인 메소드(예를 들어, "FindAll"로 명명된 메소드)

· 필터와 일치하는 단일 항목을 찾는 오버로드된 정적인 메소드(예를 들어, "FindOne"으로 명명된 메소드)

· id가 주어진 항목을 찾는 정적인 메소드(예를 들어, "FindByID"으로 명명된 메소드)

· ItemContext에 관련된 명칭이 주어진 항목을 찾는 정적인 메소드(예를 들어, "FindByName"으로 명명된 메소드)

· 항목에 대한 변경을 저장하는 메소드(예를 들어, "Update"로 명명된 메소드)

· 항목의 새로운 인스턴트를 생성하는 오버로드된 정적인 생성 메소드.

이러한 메소드들은 항목의 초기 폴더가 다양한 방식으로 특정될 것을 허용한다.

각각의 요소 E에 대해서, S 내에 System.Storage로 명명된 클래스 S.E가 생성된다. 이 클래스는 다음의 멤버들을 갖는다:

· E 내의 각각의 필드에 대한 속성. 필드가 멀티 값이면, 속성은 대응하는 요소 타입의 집합일 것이다.

각각의 요소 E에 대해서, S 내에 System.Storage로 명명된 클래스 S.E Collection이 생성된다. 이 클래스는 강하게 타입화된 집합 클래스에 대한 일반적인 .NET 프레임워크 지침을 따른다. 관계 기반 요소 타입에 대해서, 이 클래스는 또한 다음의 멤버들을 포함할 것이다:

· 집합이 소스 역할(source role)에 나타낸 항목을 명시적으로 포함하는 필터와 일치하는 다수의 항목 객체를 찾는 오버로드된 메소드. 오버로드는 항목 서브 타입에 기초한 필터링을 허용하는 메소드(예를 들어, "FindAllTargetItems"로 명칭된 메소드)를 포함함.

· 집합이 소스 역할에 나타낸 항목을 명시적으로 포함하는 필터와 일치하는 단일 항목 객체를 찾는 오버로드된 메소드. 오버로드는 항목 서브 타입에 기초한 필터를 허용하는 메소드(예를 들어, "FindOneTargetItems"로 명칭된 메소드)를 포함한다.

· 집합이 소스 역할에 나타낸 항목을 명시적으로 포함하는 필터와 일치하는 중첩 요소 타입의 객체들을 찾는 오버로드된 메소드(예를 들어, "FindAllRelationship"으로 명칭된 메소드).

· 집합이 소스 역할에 나타낸 항목을 명시적으로 포함하는 필터와 일치하는 중첩 요소 타입의 객체들을 찾는 오버로드된 메소드(예를 들어, "FindAllRelationshipsForTarget"으로 명칭된 메소드).

· 집합이 소스 역할에 나타낸 항목을 명시적으로 포함하는 필터와 일치하는 중첩 요소 타입의 단일 객체를 찾는 오버로드된 메소드(예를 들어, "FindOneRelationship"으로 명칭된 메소드).

· 집합이 소스 역할에 나타낸 항목을 명시적으로 포함하는 필터와 일치하는 중첩 요소 타입의 단일 객체를 찾는 오버로드된 메소드(예를 들어, "FindOneRelationshipForTarget"으로 명칭된 메소드).

관계 R에 대해서, S 내에 System.Storage로 명명된 클래스 S.R이 생성된다. 이 클래스는 하나 또는 두 개의 관계 역할이 엔드 포인트 필드를 특정하는지에 따라, 한 개 또는 두 개의 서브 클래스를 가질 것이다.

클래스는 또한 생성된 각각의 항목 확장에 대한 이 방식으로 생성된다.

데이터 클래스는 System.Storage.<schemaName> 명칭 공간에 존재하며, 여기서 <schemaName>은 연락처, 파일 등의 대응하는 스키마의 명칭이다. 예를 들어, 연락처 스키마에 대응하는 모든 클래스들은 System.Storage.Contact 명칭 공간에 있다.

예를 들어, 도 21a 및 21b를 참조하면, 연락처 스키마는 System.Storage.Contact 명칭 공간에 포함된 다음의 클래스들을 생성한다:

· 항목: Item, Folder, WellKnownFolder, LocalMachineDataFolder, UserDataFolder, Principal, Service, GroupService, PersonService, PresenceService, ContactService, ADService, Person, User, Group, Organization, HouseHold.

· 요소: NestedElementBase, NestedElement, IdentifyKey, SecurityID, EAddress, ContactEAddress, TelephoneNumber, SMTPEAddress, InstantMessagingAddress, Template, Profile, FullName, FamilyEvent, BasicPresence, WindowsPresence, Relationship, TemplateRelationship, LocationRelationship, FamilyEventLocationRelationship, HouseHoldLocationRelationship, RoleOccupancy, EmployeeData, GroupMemberShip, OrganizationLocationRelationship, HouseHoldMemberData, FamilyData, SpouseData, ChildData.

예를 들어, Person 타입에 대한 상세한 구조(연락처 스키마 내에 정의된 것과 같음)는 XML로 다음에 제시된다:

이 타입은 다음의 클래스(오직 공개 멤버만 나타냄)를 생성한다:

또 다른 예로서, TelephoneNumber 타입에 대한 상세한 구조(연락처 스키마 내에 정의된 것과 같음)는 XML로 다음에 제시된다:

이 타입은 다음의 클래스(오직 공개 멤버만 나타냄)를 생성한다:

주어진 스키마로부터 생성된 클래스들의 계층구조는 그 스키마 내의 타입에 대한 계층 구조를 직접적으로 반영한다. 예를 들어, 연락처 스키마 내에 정의된 Item 타입을 고려하자(도 21a 및 21b 참조). 저장 플랫폼 API 내의 이것에 대응하 는 클래스 계층 구조는 다음과 같을 것이다:

Object

DataClass

ElementBase

RootItemBase

Item

Principal

Group

HouseHold

Organization

Person

User

Service

PresenceService

ContactService

ADService

RootNestedService

...(요소 클래스들)

시스템 내의 모든 오디오/비디오 매체(손상된 오디오 파일, 오디오 CD, DVD, 홈비디오 등)를 나타내는 것을 허용하는 또 다른 스키마는 사용자/애플리케이션이 상이한 종류의 오디오/비디오 매체를 저장, 체계화, 검색, 및 조작할 수 있게 한다. 기초 매체 문서 스키마는 어떤 매체도 표현하기에 충분히 일반적이며, 이 기초 스키마로의 확장은 오디오 및 비디오 매체에 대한 도메인 특정 속성을 개별적으로 처리하도록 설계된다. 이 스키마 및 다수의 다른 것들은 코어 스키마 하에서 직접적으로 또는 간접적으로 동작할 것으로 생각된다.

5. 실행시간 프레임워크

기초 저장 플랫폼 API 프로그래밍 모델은 객체 지속적이다. 애플리케이션 프로그램(또는 "애플리케이션")은 저장소를 검색하고, 저장소 내의 데이터를 나타내는 객체를 리트리브한다. 애플리케이션은 리트리브된 객체를 수정하거나 새로운 객체를 생성한 후 그들의 변경이 저장소에 전파되게 한다. 이 프로레스는 ItemConext 객체에 의해 관리된다. 검색은 ItemSearcher 객체를 사용하여 실행되며, 검색 결과는 FindResult 객체를 통해 액세스가능하다.

a) 실행시간 프레임워크 클래스

저장 플랫폼 API의 또 다른 발명적 양태에 따라, 실행시간 프레임워크는 데이터 클래스의 동작을 지원하는 다수의 클래스를 구현한다. 이러한 프레임워크 클래스는 데이터 클래스들에 대한 공통 거동 세트를 정의하고, 데이터 클래스들과 함께 저장 플랫폼 API에 대한 기초 프로그래밍 모델을 제공한다. 실행시간 프레임워크 내의 클래스들은 System.Storage 명칭 공간에 속한다. 본 실시예에서, 프레임 워크 클래스는 ItemContext, ItemSearcher 및 FindResult의 메인 클래스들을 포함한다. 다른 마이너 클래스, 열거 값, 및 대표도 제공될 수 있다.

(1) ItemContext

ItemContext 객체는 (ⅰ) 애플리케이션 프로그램이 검색하길 원하는 항목 도메인의 세트를 나타내고, (ⅱ) 저장 플랫폼으로부터 리트리브된 데이터의 상태를 나타내는 각각의 객체에 대한 상태 정보를 유지하며, (ⅲ) 저장 플랫폼과 상호작용할 때 사용되는 트랜젝션, 및 저장 플랫폼이 연동할 수 있는 임의의 파일 시스템을 관리한다.

객체 지속 엔진과 같이, ItemContext는 다음의 서비스를 제공한다:

1. 저장소로부터 판독된 데이터의 객체로의 역직렬화.

2. 객체 식별자 유지(동일한 객체는 항목이 질의 결과에 얼마나 많이 포함되어 있는지에 상관없이 주어진 항목을 표현하는 데 사용됨).

3. 객체 상태 추적.

ItemContext는 또한 저장 플랫폼에 고유한 다수의 서비스를 수행한다:

1. 변경을 지속시키기 위해 필요한 저장 플랫폼 갱신 그램 동작(storage platfrom update gram operation)을 생성 및 실행.

2. 참조 관계의 고른 네비게이션을 가능하게 하고, 멀티 도메인 검색으로부터 리트리브된 객체들이 수정 및 저장되는 것을 허용하는데 필요한 다수의 데이터 저장소에의 접속을 생성.

3. 항목을 나타내는 객체(들)에 대한 변경이 저장될 때, 파일 지원된 항목(file backed item)이 알맞게 갱신됨을 보증.

4. 다수의 저장 플랫폼 접속에 걸친 트랜젝션(파일 스트림 속성 및 파일 지원된 항목에 저장된 데이터를 갱신할 때) 및 트랜젝트된 파일 시스템을 관리.

5. 저장 플랫폼 관계 시맨틱, 파일 지원 항목, 및 스트림 타입화된 속성을 고려한 항목 생성, 복사, 이동, 및 삭제 동작을 수행.

부록 A는 일 실시예에 따른 ItemContext 클래스의 소스 코드 리스트를 제공한다.

(2) ItemSearcher

ItemSearcher 클래스는 전체 항목 객체, 항목 객체의 스트림, 또는 항목으로부터 추정된 값의 스트림을 리턴하는 단순한 검색을 지원한다. ItemSearcher는 타겟 타입 및 그 타겟 타입에 적용되는 매개변수화된 필터들의 개념 모두에 공통인 코어 기능성을 캡슐화한다. ItemSearcher는 또한, 동일한 검색이 다수의 타입에 대해서 실행될 때, 최적화로서 검색자가 미리 컴파일되거나 준비되는 것을 허용한다. 부록 B는 일 실시예에 따른 ItemSearcher 클래스 및 몇몇의 밀접하게 관련된 클래스들의 소스 코드 리스트를 제공한다.

(a) 타겟 타입

검색 타겟 타입은 ItemSearcher를 구성한 때 설정된다. 타겟 타입은 데이터 저장소에 의해 질의가능한 범위에 매핑되는 CLR 타입이다. 구체적으로, 그것은 스키마화된 뷰뿐만 아니라 항목, 관계 및 항목 확장 타입에 매핑되는 CLR 타입이다.

ItemContext.GetSearcher 메소드를 사용하여 검색자를 리트리브할 때, 검색자의 타겟 타입은 매개변수로 특정된다. 정적인 GetSearcher 메소드가 항목, 관계, 또는 항목 확장 타입(예를 들어, Person.GetSearcher)에 대해서 호출될 때, 타겟 타입은 항목, 관계, 또는 항목 확장 타입이다.

ItemSearcher에 제공된 검색 표현(예를 들어, 검색 필터 및 전체 찾기 옵션(through find option), 또는 추정 정의)은 항상 검색 타겟 타입에 관련된다. 이러한 표현들은 타겟 타입의 속성(중첩된 요소들의 속성을 포함)을 특정할 수 있으며, 이와 달리 관계 및 항목 확장으로의 결합을 특정할 수 있다.

검색 타겟 타입은 판독전용 속성(read only properly)(예를 들어, ItemSercher.Type 속성)을 통해 사용가능하다.

(b) 필터

ItemSearcher는 검색에 사용되는 필터를 정의하는 필터를 특정하기 위한 속성(예를 들어, SearchExpression 객체의 집합으로서 "Filter"라고 명명된 속성)을 포함한다. 집합 내의 모든 필터들은, 검색이 실행될 때 논리 및 연산자를 사용하여 조합된다. 그 필터는 매개변수 참조를 포함할 수 있다. 매개변수 값은 Parameters 속성을 통해 특정된다.

(c) 검색 준비

아마도 오직 매개변수 변경과 함께, 동일한 검색이 반복적으로 실행되는 상황에서 검색을 컴파일링 또는 준비함으로써 몇몇의 수행 향상이 획득될 수 있다. 이것은 ItemSearcher에 대한 준비 메소드 세트(예를 들어, 하나 이상의 항목을 리턴하는 Find를 준비하기 위한 아마도 "PrepareFind"로 명명된 메소드, 및 추정을 리턴하는 Find를 준비하기 위한 아마도 "PrepareProject"로 명명된 메소드)에 의해 이루어진다. 예:

(d) 옵션 찾기

단순한 검색에 적용될 수 있는 다수의 옵션들이 있다. 예를 들어, 그들은 FindOption 객체에 의해 특정되고 Find 메소드로 전달될 수 있다. 예:

편리성을 위해, 소팅 옵션도 또한 직접적으로 Find 메소드에 전달될 수 있다:

DelayLoad 옵션은, 큰 바이너리 속성의 값이 검색 결과가 리트리브될 때 로 드되는지, 또는 로딩이 참조되기 전까지 지연되는지를 결정한다. MaxResults 옵션은 리턴되는 결과의 최대 개수를 결정한다. 이것은 SQL 질의 내의 TOP을 특정하는 것과 등가이다. 이것은 주로 소팅과 관련하여 사용된다.

일련의 SortOption 객체가 (예를 들어, FindOptions.SortOptions 속성을 사용하여) 특정될 수 있다. 검색 결과는 제1 SortOption 객체에 의해 특정된 것처럼, 그 후 제2 SortOption 객체에 의해 특정된 것 등에 의해 특정된 것처럼 소팅될 것이다. SortOption은 소팅을 위해 사용될 속성을 나타내는 검색 표현을 특정한다. 그 표현은 다음 중 하나를 특정한다:

1. 검색 타겟 타입 내의 스칼라 속성;

2. 단일 값인 속성을 트래버싱함으로써 검색 타겟 타입으로부터 도달할 수 있는 중첩 요소 내의 스칼라 속성; 또는

3. 유효 인수를 가진 집합 기능의 결과(예를 들어, 멀티 값인 속성 또는 관계를 트래버싱함으로써 검색 타겟 타입으로부터 도달가능한 중첩 요소 내의 스칼라 속성에 적용되는 최대값).

예를 들어, 검색 타겟 타입이 System.Storage.Contact.Person이라고 가정하자:

1. "Birthdate" - 유효, 생일은 Person 타입의 스칼라 속성임.

2. "PersonalNames.Surname" - 무효, PersonalNames는 멀티 값인 속성이며, 집합 기능이 사용되지 않음.

3. "Count(PersonalNames)" - 유효, PersonalNames의 카운트.

4. "Case(Contact.MemberOfHousehold).Household.HouseholdEAddresses.StartDate" - 무효, 사용자 관계 및 집합 기능이 없는 멀티 값인 속성.

5. "Max(Cast(Contact.MemberOfHousehold).Household.HouseholdEAddresses.StartDate)" - 유효, 가장 최근 가정 이메일 어드레스 시작 날짜.

(3) 항목 결과 스트림("FindResult")

ItemSearcher(예를 들어, FindAll 메소드를 통함)는 검색에 의해 리턴된 객체에 액세스하기 위해 사용될 수 있는 객체(예를 들어, "FindResult" 객체)를 리턴한다. 부록 C는 일 실시예에 따른 FindResult 클래스 및 몇몇의 밀접하게 관련된 클래스들의 소스 코드 리스트를 제공한다.

FindResult 객체로부터 결과를 획득하기 위한, IObjectReader(및 IAsyncObjectReader)에 의해 정의된 판독 패턴, 및 IEnumerable 및 IEnumerator에 의해 정의된 열거자 패턴을 사용하는 두 개의 별개의 메소드가 존재한다. 열거자 패턴은 CLR 내에서 표준이며, C#의 foreach와 같은 언어 구조를 지원한다. 예:

판독기 패턴은, 몇몇 경우에 데이터 사본을 삭제함으로써 결과를 보다 효율적으로 처리하는 것을 허용하기 때문에 지원된다. 예:

이외에, 판독기 패턴은 비동기적인 동작을 지원한다:

본 실시예에서, FindResult는 더 이상 필요하지 않을 때 닫혀야 한다. 이것은 Close 메소드를 호출하거나, 스테이트먼트를 사용하는 C#과 같은 언어 구조를 사용하여 행해질 수 있다. 예:

b) 동작 내의 실행시간 프레임워크

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

1. 애플리케이션(350a, 350b 또는 350c)은 저장 플랫폼 내의 항목들에 결합된다.

2. 프레임워크(2004)는 결합된 항목에 대응하는 ItemContext 객체(2202)를 생성하고, 이를 애플리케이션에 리턴한다.

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

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

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

c) 공통 프로그래밍 패턴

이 섹션은 데이터 저장소 내의 항목들을 조작하기 위해 저장 플랫폼 API 프레임워크 클래스들이 어떻게 사용될 수 있는지에 대한 다양한 예를 제공한다.

(1) ItemContext 객체 열고 닫기

애플리케이션은, 예를 들어 정적인 ItemContext.Open 메소드를 호출하고 ItemContext에 연관될 항목 도메인을 식별하는 경로 또는 경로들을 제공함으로써 데이터 저장소와 상호작용하기 위해 사용될 ItemContext 객체를 획득한다. 항목 도메인은 ItemContext를 사용하여 수행되는 검색의 범위를 정하고, 이에 따라 도메인 항목 및 그 항목에 포함된 항목들만이 검색될 것이다. 예는 다음과 같다:

로컬 컴퓨터 상의 디폴터 저장소 저장 플랫폼 공유로 ItemContext 를 엶

ItemContext ic = ItemContext.Open();

주어진 저장 플랫폼 공유로 ItemContext 를 엶

ItemContext ic = ItemContext.Open(@"＼＼myserver1＼DefaultStore");

저장 플랫폼 공유 하의 항목으로 ItemContext 를 엶

ItemContext ic = ItemContext.Open(@"＼＼myserver1＼WinFSSpecs＼api＼m6");

다수의 항목 도메인으로 ItemContext 를 엶

ItemContext는 더 이상 필요하지 않을 때, 닫혀야 한다.

ItemContext 를 명시적으로 닫기

ItemContext 를 가진 스테이트먼트를 사용하여 닫기

(2) 객체 검색

본 발명의 또 다른 양태에 따르면, 저장 플랫폼 API는, 애플리케이션 프로그래머를 기초 데이터베이스 엔진의 질의 언어에 대한 세부로부터 격리시키는 방식으로, 애플리케이션 프로그래머가 데이터 저장소 내의 다양한 항목 속성에 기초하여 질의를 형성하게 할 수 있는 단순화된 질의 모델을 제공한다.

애플리케이션은 ItemContext.GetSearcher 메소드에 의해 리턴된 ItemSearcher 객체를 사용하여 ItemContext가 열렸을 때 특정된 도메인에 대해서 검색을 실행할 수 있다. 예로서, 다음의 선언을 가정해보자:

기본 검색 패턴은 GetSearcher 메소드를 호출함으로써 ItemContext로부터 리트리브된 ItemSearcher 객체를 사용하는 것에 관련된다.

주어진 타입의 모든 항목을 검색

필터를 만족하는 주어진 타입의 항목을 검색

검색 필터 스트링 내에 매개변수를 사용

주어진 타입의 및 필터를 만족시키는 관계를 검색

주어진 타입의 및 필터를 만족시키는 관계를 가진 항목을 검색

주어진 타입의 및 필터를 만족시키는 항목 확장을 검색

주어진 타입의 및 필터를 만족시키는 항목 확장을 가진 항목을 검색

(a) 검색 옵션

소팅, 지연 로딩 및 결과 개수의 제한을 포함하는 다양한 옵션들이 검색을 실행할 때 특정될 수 있다.

검색 결과 소팅

결과 카운트 제한

(b) FindOne 및 FindOnly

때때로, 특히 소트 기준을 특정할 때, 제1 결과만을 리트리브하는 것이 유용하다. 이외에, 몇몇 검색들은 오직 하나의 객체만을 리턴하리라고 예상되지만 아무 객체도 리턴하지 않으리라고는 예상되지 않는다.

하나의 객체를 검색

항상 존재한다고 예상되는 단일 객체를 검색

(c) ItemContext의 쇼트컷 검색

가능한 용이하게 단순한 검색을 실행하는 다수의 쇼트컷 메소드가 ItemContext에 존재한다.

ItemContext . FindAll 쇼트컷을 사용하는 검색

ItemContext . FindOne 쇼트컷을 사용하는 검색

Person p = ic.FindOne(typeof(Person), "PersonalNames.Surname= 'Smith'")as Person;

(d) ID 또는 경로로 찾기

이외에, 항목, 관계 및 항목 확장은 그들의 id(들)를 제공함으로써 리트리브될 수 있다. 항목은 또한 경로에 의해서도 리트리브될 수 있다.

id(들)가 주어진 항목, 관계 및 항목 확장을 획득

경로가 주어진 항목을 획득

(e) GetSearcher 패턴

저장 플랫폼 API 내에는, 다른 객체의 문맥으로 또는 특정 매개변수와 함께 검색을 실행하는 헬퍼 메소드를 제공하기에 바람직한 여러 곳이 있다. GetSearcher 패턴은 이러한 시나리오들을 가능하게 한다. API 내에는 다수의 GetSearcher 메소드가 있다. 각각은 주어진 검색을 수행하기 위한 사전에 구성된 ItemSearcher를 리턴한다. 예:

검색을 실행하기 전에 추가적인 필터를 추가할 수 있다:

결과를 어떻게 원하는지를 고를 수 있다:

(3) 저장소 갱신

일단 객체가 검색에 의해 리트리브되면, 그것은 필요에 따라 애플리케이션에 의해 수정될 수 있다. 또한 새로운 객체가 생성되고, 기존 객체에 연관될 수 있다. 애플리케이션이 논리 그룹을 형성하는 변경을 모두 만들면, 애플리케이션은 ItemContext.Update를 호출하여, 그러한 변경들을 저장소에 지속시킨다. 본 발명의 저장 플랫폼 API의 또 다른 양태에 따르면, API는 애플리케이션 프로그램에 의해 행해진 항목에 대한 변경들을 수집하고, 그들을 데이터 저장소가 구현된 데이터베이스 엔진(또는 임의의 종류의 저장 엔진)에 의해 요구되는 올바른 갱신으로 체계화한다. 이것은 API에 대한 데이터 저장소 갱신의 복잡성은 그대로 두면서, 애 플리케이션 프로그래머가 메모리 내의 항목을 변경할 수 있게 한다.

단일 항목에 대한 변경 저장

다수의 항목에 대한 변경 저장

새로운 항목 생성

관계( 타겟 항목 가능) 삭제

항목 확장 추가

항목 확장 삭제

6. 보안

상기 섹션 Ⅱ.E(보안)을 참조하면, 저장 플랫폼 API의 본 실시예에서, ItemContext 상에 저장소 내의 항목에 관련된 보안 정책을 리트리브 및 수정하기 위해 사용가능한 5개의 메소드가 있다. 그들은 다음과 같다:

1. GetItemSecurity;

2. SetItemSecurity;

3. GetPathSecurity;

4. SetPathSecurity; 및

5. GetEffectiveItemSecurity

GetItemSecurity 및 SetItemSecurity는 항목에 연관된 명시적인 ACL을 리트리브 및 수정하기 위한 메커니즘을 제공한다. 이 ACL은 항목에 존재하는 경로에 독립적이며, (실행중에) 타겟으로서 이 항목을 갖는 유지 관계에도 독립적으로 될 것이다. 이것은 관리자가 원하면 항목에 존재하는 경로에 독립적인 항목 보안에 대해 논리적으로 추론할 수 있게 한다.

GetPathSecurity 및 SetPathSecurity는 다른 폴더로부터의 유지 관계 때문에 항목에 존재하는 ACL을 리트리브 및 수정하기 위한 메커니즘을 제공한다. 이 ACL은, 해당 경로에 공급된 것이 있다면 그 명시적인 ACL과 함께, 그 경로를 따른 항목에 대한 다양한 조상들의 ACL들로 구성된다. 이 ACL과 이전 경우의 ACL 간의 차이는 명시적인 항목 ACL은 항목에 대한 임의의 유지 관계에 독립적인 반면, 이 ACL은 대응하는 유지 관계가 존재하는 한 (실행중에) 남아 있다는 것이다.

SetItemSecurity 및 SetPathSecurity에 의해 항목에 설정될 수 있는 ACL은 상속가능하고 객체 특정한 ACE에 제한된다. 그들은 상속되었다고 표식된 ACE는 포함할 수 없다.

GetEffectiveItemSecurity는 항목에 대한 명시적인 ACL뿐만 아니라 다양한 경로 기반 ACL을 리트리브한다. 이것은 사실상 주어진 항목에 대한 인증 정책을 반영한다.

7. 관계 지원

전술된 바와 같이, 저장 플랫폼의 데이터 모델은 항목이 다른 것에 관련되는 것을 허용하는 "관계"를 정의한다. 스키마에 대한 데이터 클래스가 생성될 때, 각각의 관계 타입에 대한 다음의 클래스들이 생성된다:

1. 관계 자체를 나타내는 클래스. 이 클래스는 Relationship 클래스로부터 도출되며, 관계 타입에 특정한 멤버를 포함함.

2. 강하게 타입화된 "가상" 집합 클래스. 이 클래스는 VirtualRelationshipCollection으로부터 도출되며, 관계 인스턴트가 생성 및 삭제되는 것을 허용함.

이 섹션은 저장 플랫폼 API 내의 관계를 지원한다.

a) 기초 관계 타입

저장 플랫폼 API는 관계 API의 기반구조를 형성하는 System.Storage 명칭 공간 내의 다수의 타입을 제공한다. 이들은 다음과 같다:

1. Relationship - 모든 관계 클래스의 기초 타입

2. VirtualRelationshipCollection - 모든 관계 집합에 대한 기초 타입

3. ItemReference, ItemIDReference, ItemPathReference - 항목 참조 타입을 나타냄; 이러한 타입들 간의 관계는 도 11에 예시됨.

(1) Relationship 클래스

다음은 관계 클래스에 대한 기초 클래스이다.

(2) ItemReference 클래스

다음은 항목 참조 타입에 대한 기초 클래스이다.

ItemReference 객체는 항목 참조가 상주한 곳 이외의 저장소에 존재하는 항 목을 식별할 수 있다. 각각의 도출된 타입은 원격 저장소로의 참조가 어떻게 구성 및 사용되는지를 특정한다. 도출된 클래스 내의 GetItem 및 IsDomainConnected의 구현은 ItemContext의 멀티 도메인 지원을 사용하여, 필요한 도메인으로부터 항목을 로드하고, 도메인으로의 접속이 이미 구축되어있는지를 판정한다.

(3) ItemIdReference 클래스

다음은 ItemIdReference 클래스이다 - 항목 참조는 항목 id를 사용하여 타겟 항목을 식별함.

GetItem 및 IsDomainConnected는 ItemContext의 멀티 도메인 지원을 사용하여, 필요한 도메인으로부터 항목을 로드하고, 도메인으로의 접속이 이미 구축되어있는지를 판정한다. 이 기능은 아직 구현되지 않았다.

(4) ItemPathReference 클래스

ItemPathReference 클래스는 타겟 항목을 식별하기 위해 경로를 사용하는 항목 참조이다. 이 클래스에 대한 코드는 다음과 같다:

GetItem 및 IsDomainConnected는 ItemContext의 멀티 도메인 지원을 사용하여, 필요한 도메인으로부터 항목을 로드하고, 도메인으로의 접속이 이미 구축되어있는지를 판정한다.

(5) RelationshipId 구조

RelationshipId 구조는 RelationshipId GUID를 캡슐화한다.

이러한 값 타입은 GUID를 랩핑(wrapping)함으로써, 매개변수 및 속성들이 관계 id로 강하게 타입화될 수 있게 한다. OptionalValue<RelationshipId>는 관계 id가 널일 수 있을 때 사용되어야 한다. System.Guid.Empty에 의해 제공되는 것과 같은 빈 값은 노출되지 않는다. RelationshipId는 빈 값으로 구성될 수 없다. 디폴트 구조자를 사용하여 RelationshipId를 생성할 때, 새로운 GUID가 생성된다.

(6) VirtualRelationshipCollection 클래스

VirtualRelationshipCollection 클래스는 데이터 저장소로부터의 객체를 포함하는 관계 객체의 집합을 구현하며, 집합에 추가된 새로운 객체들을 합하지만, 저장소로부터 제거된 객체들을 포함하지 않는다. 주어진 소스 항목 id를 갖는 특정된 관계 타입의 객체는 집합에 포함된다.

이것은 각각의 관계 타입에 대해 생성된 관계 집합 클래스에 대한 기초 클래스이다. 이 클래스는 주어진 항목 관계의 용이한 조작 및 액세스를 제공하기 위해 소스 항목 타입 내의 속성 타입으로 사용될 수 있다.

VirtualRelationshipCollection의 콘텐츠를 열거하는 것은 잠재적으로 다수의 관계 객체가 저장소로부터 로드될 것을 필요로 한다. 애플리케이션은 Count 속성을 사용하여, 얼마나 많은 관계들이 로드될 수 있는지를 집합의 콘텐츠를 열거하기 전에 판정한다. 집합에 객체를 추가하고 그로부터 객체를 제거하는 것은 관계가 저장소로부터 로드될 것을 필요로 하지 않는다.

효율성을 위해, 애플리케이션이 모든 항목 관계를 열거하는 대신에 VirtualRelationshipCollection 객체를 사용하여 특정 기준을 만족하는 관계들만을 검색하는 것이 바람직하다. 관계 객체를 집합에 추가하면, ItemContext.Update가 호출될 때, 표현된 관계가 저장소에 생성된다. 관계 객체를 집합으로부터 제거하면, ItemContext.Update가 호출될 때, 표현된 관계가 저장소에서 삭제된다. 가상 집합은 관계 객체가 Item.Relationships 집합이나 그 항목에 대한 임의의 다른 관계 집합을 통해 추가/제거되는지에 상관없이 올바른 객체 세트를 포함한다.

다음의 코드는 VirtualRelationshipCollection 클래스를 정의한다:

b) 생성된 관계 타입

저장 플랫폼 스키마에 대한 클래스를 생성할 때, 각각의 관계 선언에 대해서 클래스가 생성된다. 관계 자체를 나타내는 클래스 이외에, 관계 집합 클래스가 또한 각각의 관계에 대해서 생성된다. 이러한 클래스는 관계 소스 또는 타겟 항목 클래스의 속성 타입으로 사용된다.

이 섹션은 다수의 "견본" 클래스들을 사용하여 생성된 클래스를 설명한다. 즉, 특정된 관계 선언이 주어지면, 생성된 클래스가 설명된다. 견본 클래스 내에서 사용된 클래스, 타입 및 엔드 포인트 명칭은 스키마 내에 특정된, 관계에 대한 명칭을 위한 위치 홀더(place holder)이며, 문자적으로 취해지면 안된다.

(1) 생성된 관계 타입

이 섹션은 각각의 관계 타입에 대해서 생성된 클래스들을 설명한다. 예:

이 관계 정의가 주어지면, RelationshipPrototype 및 RelationshipPrototypeCollection 클래스가 생성된다. RelationshipPrototype 클래스는 관계 자체를 나타낸다. RelationshipPrototypeCollection 클래스는 소스 엔트 포인트로서 특정된 항목을 갖는 RelationshipPrototype 인스턴스에의 액세스를 제공한다.

(2) RelationshipPrototype 클래스

이것은 "HoldingRelationshipPrototype"으로 명명된 유지 관계에 대한 견본 관계 클래스이며, 여기서 소스 엔드 포인트는 "Head"로 명명되고 "Foo" 항목 타입을 특정하며, 타겟 엔드 포인트는 "Tail"로 명명되고 "Bar" 항목 타입을 특정한다. 그것은 다음과 같이 정의된다:

(3) RelationshipPrototypeCollection 클래스

이것은 특정된 항목이 소유하는 RelationshipPrototype 관계 인스턴스의 집합을 유지하는 RelationshipPrototype 클래스로 생성된 견본 클래스이다. 이것은 다음과 같이 정의된다:

c) 항목 클래스 내의 관계 지원

Item 클래스는 그 항목이 관계의 소스인 관계에의 액세스를 제공하는 Relationship 속성을 포함한다. Relationship 속성은 타입 RelationshipCollection을 갖는다.

(1) Item 클래스

다음의 코드는 Item 클래스의 관계 문맥 속성들을 나타낸다:

(2) RelationshipCollection 클래스

이 클래스는 관계 주어진 항목이 관계의 소스일 때, 관계 인스턴스에의 액세스를 제공한다. 이것은 다음과 같이 정의된다:

d) 검색 표현 내의 관계 지원

검색 표현 내의 관계와 관련 항목 간의 결합의 트래버설을 특정하는 것이 가능하다.

(1) 항목으로부터 관계로의 트래버싱

검색 표현의 현재 문맥이 항목의 세트일 때, 항목이 소스인 경우, 항목과 관계 인스턴스 간의 결합은 Item.Relationships 속성을 사용하여 행해질 수 있다. 특정한 타입의 관계와 결합하는 것은 검색 표현 Cast 연산자를 사용하여 특정될 수 있다.

강하게 타입화된 관계 집합(예를 들어, Folder.MemberRelationships)이 또한 검색 표현에 사용될 수 있다. 관계 타입으로의 캐스트(cast)는 절대적이다.

일단 관계 세트가 구축되면, 그 관계의 속성들은 술어부(predicate) 내에 또 는 추정의 타겟으로 사용될 수 있다. 추정의 타겟을 특정하기 위해 사용될 때, 관계 세트가 리턴될 수 있다. 예를 들어, 다음의 스테이트먼트는 관계의 StartDate 속성이 '1/1/2000'보다 크거나 같은 값을 갖는 체계에 관련된 모든 사람들을 찾을 것이다.

Person 타입이 타입 (EmployeeEmployer 관계 타입에 대해 생성된 것과 같은) EmployeeSideEmployerEmployeeRelationships의 속성 EmployerContext를 가지면, 이것은 다음과 같이 작성될 수 있다:

(2) 관계로부터 항목으로의 트래버싱

검색 표현의 현재 문맥이 관계의 세트일 때, 관계로부터 관계의 엔드 포인트로의 결합은 엔드 포인트의 명칭을 특정함에 의해 트래버싱될 수 있다. 일단 관련 항목의 세트가 구축되면, 이러한 항목들의 속성은 술어부 내에 또는 추정의 타겟으로 사용될 수 있다. 추정의 타겟을 특정하기 위해 사용될 때, 항목 세트가 리턴될 수 있다. 예를 들어, 다음의 스테이트먼트는 (체계에 상관없이) 고용인의 성이 "Smith"인 모든 EmployeeOfOrganization 관계를 찾을 것이다:

검색 표현 Cast 연산자를 사용하여, 엔드 포인트 항목의 타입을 필터링할 수 있다. 예를 들어, 멤버가 별명 "Smith"를 갖는 Person 항목인 모든 MemberOfFolder 관계 인스턴스를 찾아보자:

(3) 관계 트래버설 조합

상기 2개의 패턴(항목으로부터 관계로의 및 관계로부터 항목으로의 트래버싱)을 조합하여 임의 복합 트래버설을 생성할 수 있다. 예를 들어, 별명이 "Smith"인 고용인을 갖는 모든 체계를 찾아보자:

다음의 예는 "New York" 지역에 있는 가정에 살고 있는 사람들을 나타내는 모든 Person 항목을 찾을 것이다(TODO: 이것은 더 이상 대안이 지원되지 않음).

e) 관계 지원의 예시적인 사용

다음은 관계를 조작하기 위해 저장 플랫폼 API 내의 관계 지원이 어떻게 사용될 수 있는지의 예이다. 다음의 예에 대해서, 다음의 선언을 가정하자:

(1) 관계 검색

소스 또는 타겟 관계를 검색하는 것이 가능하다. 필터를 사용하여, 특정된 타입의 및 주어진 속성 값을 갖는 관계를 선택할 수 있다. 또한 필터를 사용하여, 관련 항목 타입 또는 속성 값에 기초하여 관계를 선택할 수 있다. 예를 들어, 다음의 검색이 수행될 수 있다:

주어진 항목이 소스인 모든 관계

주어진 항목이 "A%"와 일치하는 명칭을 갖는 소스인 모든 관계

주어진 항목이 소스인 모든 FolderMember 관계

주어진 항목이 소스이고 명칭이 "A%"와 같은 모든 FolderMember 관계

타겟 항목이 Person인 모든 FolderMember 관계

타겟 항목이 별명 "Smith"를 갖는 Person인 모든 FolderMember 관계

상기 도시된 GetSearcher 이외에, 각각의 관계 클래스는 정적인 FindAll, FineOne 및 FineOnly API를 지원한다. 이외에, 관계 타입은 ItemContext.GetSearcher, ItemContext.FindAll, ItemContext.FindOne 또는 ItemContext.FindOnly를 호출할 때 특정될 수 있다.

(2) 관계로부터 소스 및 타겟 항목으로의 네비게이션

일단 관계 객체가 검색을 통해 리트리브되면, 타겟 또는 소스 항목으로 "네비게이션"하는 것이 가능하다. 기초 관계 클래스는 Item 객체를 리턴하는 SourceItem 및 TargetItem 속성을 제공한다. 생성된 관계 클래스는 강하게 타입화된 등가물 및 명명된 속성(예를 들어, FolderMember.FolderItem 및 FolderMember.MemberItem)을 제공한다. 예:

명칭이 " Foo "인 관계를 위해 소스 및 타겟 항목으로 네비게이션

타겟 항목으로 네비게이션

타겟 항목이 관계가 발견된 도메인 내에 없더라도, 타겟 항목으로의 네비게이션은 동작한다. 이러한 경우에, 저장 플랫폼 API는 필요한 때에 타겟 도메인에의 접속을 연다. 애플리케이션은, 접속이 타겟 항목을 리트리브하기 전에 요청될지를 판정할 수 있다.

접속 해제된 도메인 내의 타겟 항목 체크

(3) 소스 항목으로부터 관계로 네비게이션

항목 객체가 주어지면, 명시적인 검색을 실행하지 않으면서도 그 항목이 소스인 관계로 네비게이션할 수 있다. 이것은 Item.Relationship 집합 속성 또는 Folder.MemberRealtionships 등의 강하게 타입화된 집합 속성을 사용하여 행해진다. 관계로부터 타겟 항목으로 네비게이션하는 것이 가능하다. 이러한 네이게이션은 타겟 항목이 소스 항목의 ItemContext에 연관된 항목 도메인 내에 없으며, 타겟 항목이 타겟 항목과 동일한 저장소 내에 없더라도 행해진다. 예:

소스 항목으로부터 타겟 항목으로의 관계로의 네비게이션

폴더 항목으로부터 타겟 항목으로의 Foldermember 관계로의 네비게이션

항목은 다수의 관계를 가질 수 있으므로 애플리케이션은 관계 집합을 열거할 때 조심해야 한다. 일반적으로, 검색은 전체 집합을 열거하는 대신 관심 있는 특정한 관계를 식별하는 데 사용된다. 또한, 관계에 대한 집합 기반 프로그래밍 모델을 갖는 것은 충분히 가치가 있으며 다수의 관계를 갖는 항목은 거의 없으므로, 개발자에 의해 오용될 위험성이 정당화된다. 애플리케이션은 집합 내의 관계들의 개수를 체크하고, 필요하면 다른 프로그래밍 모델을 사용할 수 있다. 예:

관계 집합의 크기를 체크

전술된 관계 집합은 실제로 애플리케이션이 집합을 열거하려고 시도하기 전까지는 각각의 관계를 나타내는 객체에 의해 실제로 파퓰레이트되지 않는다는 의미에서 "가상적"이다. 집합이 열거되면, 결과는 저장소 내에 있는 것과, 애플리케이 션에 의해 추가되었지만 아직 저장되지 않은 것을 반영하고, 애플리케이션에 의해 제거되었지만 아직 저장되지는 않은 임의의 관계들은 반영하지 않는다.

(4) 관계(및 항목) 생성

새로운 관계는 관계 객체를 생성하고, 그것을 소스 항목 내의 관계 집합에 추가하고, ItemContext를 갱신함으로써 생성된다. 새로운 항목을 생성하기 위해, 유지 또는 삽입 관계가 생성되어야 한다. 예:

기존 폴더에 새로운 항목 추가

기존 폴더에 기존 항목 추가

새로운 폴더에 기존 항목 추가

새로운 폴더에 새로운 항목 추가

(5) 관계(및 항목) 삭제

유지 관계 삭제

8. 저장 플랫폼 API "확장"

전술된 바와 같이, 모든 저장 플랫폼 스키마는 클래스 세트를 생성한다. 이러한 클래스들은 Find*과 같은 표준형 메소드를 가지며, 또한 필드 값을 획득 및 설정하기 위한 속성들을 갖는다. 이러한 클래스 및 관련 메소드는 저장 플랫폼 API의 기반구조를 형성한다.

a) 도메인 거동

이러한 표준형 메소드 이외에, 모든 스키마는 그것에 대한 도메인 특정 메소드의 세트를 갖는다. 우리는 이러한 도메인 거동을 호출한다. 예를 들어, 연락처 스키마 내의 몇몇의 도메인 거동은 다음과 같다:

· 이메일 어드레스가 유효한가?

· 폴더가 주어지면, 폴더의 모든 멤버들의 집합을 획득.

· 항목 ID가 주어지면, 이 항목을 나타내는 객체를 획득.

· Person이 주어지면, 그의 온라인 상태를 획득.

· 새로운 연락처 또는 임시적인 연락처를 생성하기 위한 헬퍼 기능.

· 등

"표준형" 거동(Find* 등)과 도메인 거동 사이를 구별하는 동안, 그들은 프로그래머에게 단순히 메소드로 보여짐을 명심하는 것이 중요하다. 이러한 메소드들 간의 구별은, 도메인 거동이 변경되지 못하게 코드화되는 반면 표준형 거동은 저장 플랫폼 API 설계 시간 툴에 의해 스키마 파일로부터 자동으로 생성된다는 사실에 근거한다.

그들의 그 특성에 의해, 이러한 도메인 거동은 직접 생성된다. 이것은 C#의 초기 버전이 클래스의 전체 구현이 단일 파일 내에 있을 것을 요청하는 실질적인 문제를 이끌어낸다. 그러므로, 이것은 자동으로 생성된 클래스 파일이 도메인 거동들을 추가하도록 편집되어야 한다고 강요한다. 그것만으로, 이것은 문제가 될 수 있다.

이러한 문제에 대해서 부분적인 클래스라고 불리는 기능이 C#에 도입되어 있다. 기본적으로, 부분적인 클래스는 클래스 구현이 다수의 파일들을 스팬(span)하는 것을 허용한다. 부분적인 클래스는 키워드 부분이 그것의 선언을 뒤따른다는 것을 제외하면 보통의 클래스와 동일하다:

이제, Person에 대한 도메인 거동은 다음과 같이 상이한 파일 내에 놓여질 수 있다:

b) 값 추가 거동

도메인 거동을 갖는 데이터 클래스는 애플리케이션 개발자가 구축하는 기반 구조를 형성한다. 그러나, 데이터 클래스가 그 데이터에 관련된 생각해낼 수 있는 모든 거동을 노출하는 것은 불가능하며 바람직하지 않다. 저장 플랫폼은 개발자가 저장 플랫폼 API가 제공하는 기초 기반구조를 구축하는 것을 허용한다. 본원에서 기초 패턴은 하나 이상의 저장 플랫폼 데이터 클래스를 매개변수로서 취하는 메소드의 클래스를 작성하기 위한 것이다. 예를 들어, 마이크로소프트 아웃룩이나 마이크로소프트 윈도우즈 메신저를 사용하여 이메일을 송신하기 위한 값 추가 클래스는 다음과 같을 수 있다:

이러한 값 추가 클래스는 저장 플랫폼에 등록될 수 있다. 등록 데이터는 저장 플랫폼이 모든 설치된 저장 플랫폼 타입에 대해서 유지하는 스키마 메타데이터에 연관된다. 이 메타데이터는 저장 플랫폼 항목으로 저장되고, 질의될 수 있다.

값 추가 클래스의 등록은 강력한 기능인데, 예를 들어 그것은 다음의 시나리오를 허용한다: Shell 익스플로러 내의 Person 객체 상에서의 오른쪽 클릭 및 허용된 액션 세트는 Person에 대해 등록된 값 추가 클래스로부터 도출될 수 있었다.

c) 서비스 공급자로서의 값 추가 거동

본 실시예에서, 저장 플랫폼 API는 값 추가 클래스가 주어진 타입에 대한 "서비스"로서 등록될 수 있는 메커니즘을 제공한다. 이것은 애플리케이션이 주어진 타입의 서비스 공급자(=값 추가 클래스)를 설정 및 획득하게 한다. 이 메커니즘을 활용하길 원하는 값 추가 클래스는 잘 알려진 인터페이스를 구현해야 하며, 예는 다음과 같다:

모든 저장 플랫폼 API 데이터 클래스는 ICachedServiceProvider 인터페이스를 구현한다. 이 인터페이스는 다음과 같은 System.IServiceProvider 인터페이스 를 확장시킨다:

이 인터페이스를 사용하여, 애플리케이션은 특정한 타입의 서비스 공급자를 요청할 뿐만 아니라 서비스 공급자 인스턴스를 설정할 수 있다.

이 인터페이스를 지원하기 위해, 저장 플랫폼 데이터 클래스는 타입에 의해 정렬된 서비스 공급자의 해시 테이블을 유지한다. 서비스 공급자가 요청될 때, 구현은 우선 특정된 타입의 서비스 공급자가 설정되어 있는지를 알아보기 위해 해시 테이블을 본다. 서비스 공급자가 없으면, 등록된 서비스 공급자 기반구조를 사용하여 특정된 타입의 서비스 공급자를 식별한다. 그 후 이 공급자의 인스턴스가 생성되고 해시 테이블에 추가된 후 리턴된다. 또한 데이터 클래스 상의 공유된 메소드가 서비스 공급자를 요청하고 그 공급자에게 동작을 포워딩할 수 있다는 것도 명심하자. 예를 들어, 이것을 사용하여 사용자에 의해 특정된 이메일 시스템을 사용하는 메일 메시지 클래스에 대한 송신 메소드를 제공한다.

9. 타임 프레임워크 설계

이 섹션은 본 발명의 실시예에 따라 저장 플랫폼 스키마가 어떻게 클라이언트 상의 저장 플랫폼 API 클래스 및 서버 상의 UDT 클래스로 변하는지를 설명한다. 도 24는 관련된 요소들을 나타낸다.

도 24를 참조하면, 스키마 내의 타입은 XML 파일(상자 1)에 포함된다. 이 파 일은 또한 스키마에 관련된 필드 레벨 및 항목 레벨 제약을 포함한다. 저장 플랫폼 클래스 생성자(xfs2cs.exe - 상자 2)는 이 파일을 취하고, 저장 UDT에 대한 부분적인 클래스(상자 5), 및 클라이언트 클래스에 대한 부분적인 클래스(상자 3)를 를 생성한다. 각각의 스키마 도메인에 대해서, 도메인 거동이라 불리는 추가적인 메소드가 존재한다. 저장소(상자 7), 클라이언트(상자 6), 및 두 곳 모두(상자 4)에 의미가 있는 도메인 거동이 존재한다. 상자(4, 6, 및 7) 내의 코드는 직접 작성된다(자동으로 생성되지 않음). 상자(3, 4, 및 6) 내의 부분적인 클래스들은 함께 저장 플랫폼 API 도메인 클래스에 대한 완벽한 클래스 구현을 형성한다. 상자 (3, 4, 및 6)는 컴파일되어(상자 8), 저장 플랫폼 API 클래스(상자 11)를 형성한다(실제로, 저장 플랫폼 API는 모든 초기 스키마 도메인으로부터 생성된 상자(3, 4, 및 6)을 컴파일링한 결과임). 도메인 클래스 이외에, 값 추가 거동을 구현하는 추가적인 클래스도 또한 존재한다. 이러한 클래스들은 하나 이상의 스키마 도메인 내의 하나 이상의 클래스를 사용한다. 이것은 상자(10)로 표현된다. 상자(4, 5, 및 7) 내의 부분적인 클래스들은 함께 서버 UDT 클래스에 대한 완벽한 클래스 구현을 형성한다. 상자(4, 5, 및 7)는 컴파일링되어(상자 9), 서버 측 UDT 어셈블리(상자 12)를 형성한다(실제로, 서버 측 UDT 어셈블리는 모든 초기 스키마 도메인으로부터 생성된 상자(4, 5, 및 7)을 컴파일링한 결과임). DDL 명령 생성자 모듈(상자 13)은 UDT 어셈블리(상자 12) 및 스키마 파일(상자 1)을 취하고, 그들을 데이터 저장소 상에 설치한다. 이 프로세스는 (다른 것들 중에서) 각각의 스키마 내의 타입에 대한 테이블 및 뷰의 생성에 관련된다.

10. 질의 공식

기초로 축소될 때, 저장 플랫폼 API를 사용할 때의 애플리케이션 패턴은 ItemContext를 열고, 원하는 객체를 리트리브하기 위해 필터 기준와 함께 Find를 사용하고, 객체에 대해서 동작하고, 저장소에 변경을 송신한다. 이 섹션은 무엇이 필터 스트링으로 되는지의 신택스에 관한 것이다.

저장 플랫폼 데이터 객체를 찾을 때 제공되는 필터 스트링은 객체의 속성이 리턴되기 위해 만족되어야 하는 조건을 설명한다. 저장 플랫폼 API에 의해 사용되는 신택스는 타입 캐스트 및 관계 트래버설을 지원한다.

a) 필터 기초

필터 스트링은 비어있거나(특정된 타입의 모든 객체가 리턴되어야 함을 나타냄) 각각의 리턴된 객체가 만족해야 하는 블리언 표현이다. 표현은 객체의 속성을 참조한다. 저장 플랫폼 API 실행시간은 이러한 속성 명칭들이 어떻게 저장 플랫폼 타입 필드 명칭 및 궁극적으로 저장 플랫폼 저장소에 의해 유지되는 SQL 뷰에 매핑되는지를 알고 있다.

다음의 예를 고려하자:

중첩된 객체의 속성은 또한 필터에서도 사용될 수 있다. 예:

집합에 대해서, 각괄호 내의 조건을 사용하여 멤버를 필터링할 수 있다. 예:

다음의 예는 1999년 12월 31일 이후에 태어난 사람들 모두를 리스트한다:

라인 1은 로컬 컴퓨터의 저장 플랫폼 저장소 상의 "Work Contacts"에 액세스하기 위한 새로운 ItemContext 객체를 생성한다. 라인 3 및 4는 표현 "Birthdate > '12/31/1999'"에 의해 특정된 것과 같이 Birthdate 속성이 1999년 12월 31일 이후로 특정된 Person 객체의 집합을 획득한다. 이 FindAll 동작의 실행은 도 23에 예시된다.

b) 타입 캐스트

속성에 저장된 값의 타입이 속성 선언된 타입으로부터 도출되는 경우가 종종 있다. 예를 들어, Person 내의 PersonalEAddress 속성은 EMailAddress와 같은 EAddress 및 TelephoneNumber로부터 도출된 타입의 집합을 포함한다. 전화번호 국번에 기초하여 필터링하기 위해, Eaddress 타입을 TelephoneNumber 타입으로 캐스팅할 필요가 있다:

c) 필터 신택스

다음은 일 실시예에 따라 저장 플랫폼 API가 지원하는 필터 신택스에 대한 설명이다.

11. 원격

a) API 내의 로컬/원격 투명성

저장 플랫폼 내의 데이터 액세스는 로컬 저장 플랫폼 인스턴스를 타겟으로 한다. 질의(또는 그것의 일부)가 원격 데이터를 참조하면, 로컬 인스턴스는 라우터로 기능한다. 그러므로, API 계층은 로컬/원격 투명성을 제공하며; 로컬 데이터 액세스와 원격 데이터 액세스 간의 API에는 아무런 구조적인 차이가 없다. 그것은 순수하게 요청된 범위의 기능이다.

저장 플랫폼 데이터 저장소는 또한 분산형 질의도 구현하며, 이에 따라, 로컬 저장 플랫폼 인스턴스에 접속되고, 상이한 볼륨(몇몇은 로컬 저장소 상에 있고 다른 것들은 원격 저장소 상에 있음)으로부터의 항목들을 포함하는 질의를 수행하는 것이 가능하다. 저장소는 결과들을 조합하여, 그것을 애플리케이션에 나타낸다. 저장 플랫폼 API(이에 따라 애플리케이션 개발자)의 관점으로부터, 임의의 원격 액세스는 완벽하게 고르고 투명하다.

저장 플랫폼 API는 애플리케이션이 주어진 ItemContext 객체가 ItemContext객체에 대한 속성인 IsRemote 속성을 사용하여 로컬 또는 원격 접속을 나타낼지를 판정하는 것을 허용한다. 다른 것들 중에서, 애플리케이션은 성능, 신뢰 등에 대한 사용자 기대를 설정하는 것을 돕기 위해 가상 피드백을 제공하길 원할 수 있다.

b) 원격의 저장소 플랫폼 구현

저장 플랫폼 데이터 저장소는 HTTP를 통해 동작하는 특별한 OLEDB 공급자를 사용하여 서로 대화한다(디폴트 OLEDB 공급자는 TDS를 사용함). 일 실시예에서, 분산형 질의는 관계형 데이터베이스 엔진의 디폴트 OPENROWSET 기능을 통해 동작한다. 특별 사용자 정의 기능(UDF): DoRemoteQuery(server, queryText)가 실제적인 원격을 행하기 위해 제공된다.

c) 비저장 플랫폼 저장소에의 액세스

본 발명의 저장 플랫폼의 일 실시예에서, 임의의 저장소가 저장 플랫폼 데이터 액세스에 참여하는 것을 허용하는 일반 공급자 구조는 없다. 그러나, 마이크로소프트 익스체인지(Microsoft Exchange) 및 마이크로소프트 액티브 디렉토리(Microsoft Active Directory, AD)의 특별한 경우에 대한 제한된 공급자 구조가 제공된다. 이것은, 공급자가 저장 플랫폼에 있을 때 그들이 저장 플랫폼 API를 사용하며 AD 및 익스체인지 내의 데이터에 액세스할 수 있지만, 그들이 액세스할 수 있는 데이터는 저장 플랫폼 스키마화된 타입으로 제한된다는 것을 함축한다. 이에 따라, 어드레스 북(=저장 플랫폼 Person 타입들의 집합)은 AD에서 지원되며, 메일, 달력 및 연락처는 익스체인지에 대해 지원된다.

d) DFS와의 관계

저장 플랫폼 속성 증진자는 지난 마운트 포인트(mount point)는 증진시키지 않는다. 명칭 공간이 마운트 포인트를 통해 액세스하기에 충분히 풍부하더라도, 질의는 그들을 통과하지 않는다. 저장 플랫폼 볼륨은 DFS 트리 내의 리프 노드(leaf node)로 보여질 수 있다.

e) GXA/인디고(Indigo)와의 관계

개발자는 개발 플랫폼 API를 사용해, 데이터 저장소의 상부 상의 "GXA 헤드"를 노출시킬 수 있다. 개념적으로, 이것은 임의의 다른 웹 서비스를 생성하는 것과 다르지 않다. 저장 플랫폼 API는 GXA를 사용하여 저장 플랫폼 데이터 저장소와 대화하지 않는다. 전술된 바와 같이, API는 TDS를 사용하여 로컬 저장소와 대화하고, 임의의 원격은 동기화 서비스를 사용하여 로컬 저장소에 의해 처리된다.

12. 제약

저장 플랫폼 데이터 모델은 타입에 대한 값 제약을 허용한다. 이러한 제약들은 저장소에서 자동으로 평가되고, 프로세스는 사용자에게 투명하다. 그 제약들은 서버에서 체크됨을 명심하자. 때때로, 서버에의 왕복에 대한 오버헤드를 초래하지 않으면서 입력 데이터가 제약을 만족한다는 것을 검증하기 위한 유연성을 개발자에게 주는 것이 바람직함을 명심하자. 이것은 최종 사용자가 객체를 파퓰레이트하는데 사용되는 데이터를 입력하는 상호작용적인 애플리케이션에 특히 유용하다. 저장 플랫폼 API는 이러한 기능들을 제공한다.

스키마를 나타내는 적절한 데이터베이스 객체를 생성하기 위해 저장 플랫폼에 의해 사용되는 저장 플랫폼 스키마가 XML 파일 내에 특정된다는 것을 상기하자. 그것은 저장 플랫폼 API의 설계 시간 프레임워크에 의해 사용되어, 클래스를 자동으로 생성한다.

이것은 연락처 스키마를 생성하기 위해 사용되는 XML 파일의 부분적인 리스트이다:

상기 XML 내의 Check 태그는 Person 타입에 대한 제약을 특정한다. 하나 이상의 체크 태그가 있을 수 있다. 상기 제약은 일반적으로 저장소 내에서 체크된다. 제약이 또한 애플리케이션에 의해 명시적으로 체크될 수 있음을 특정하기 위해, 상기 XML은 다음과 같이 수정된다:

참으로 설정된 <Check> 요소에 대한 새로운 "InApplication" 속성에 주의하자. 이것은 저장 플랫폼 API가, Validate()라 불리는 Person 클래스 상의 인스턴스 메소드를 통해 API 내의 제약을 표면화하게 한다. 애플리케이션은 객체에 대해 이 메소드를 호출하여, 데이터가 유효하다는 것을 보증하고, 서버로의 잠재적으로 불필요한 왕복을 방지할 수 있다. 이것은 검증 결과를 나타내기 위해 부울을 리턴한다. 값 제약은 클라이언트가 <object>.Validate() 메소드를 호출하는지에 상관없이 아직 서버에 적용된다는 것을 명심하자. 이것이 Validate가 어떻게 사용될 수 있는지에 대한 예이다:

저장 플랫폼 저장소(저장 플랫폼 API, ADO.NET, OLEDB, 및 ADO)로의 다수의 액세스 경로가 존재한다. 이것은 ODBC로부터 작성된 데이터가 저장 플랫폼 API로부터 작성될 수 있는 동일한 데이터 보전 제약을 만족하는지를 어떻게 보장할 수 있는지의 믿을만한 제약 체킹에 대한 의문을 발생시킨다. 저장소에의 모든 제약들이 체크되기 때문에, 제약은 이제 믿을만한 것이다. 저장소에 이르기 위해 어느 API 경로를 사용하는지에 상관없이, 저장소에 작성된 모든 것은 저장소에서 제약 체크를 통해 필터링된다.

13. 공유

저장 플랫폼 내의 공유는 다음과 같은 형태이다:

＼＼<DNS Name>＼<Context Service>

여기서 <DNS Name>는 기기의 DNS 명칭이고, <Context Service>는 그 기기의 볼륨 내의 포함 폴더, 가상 폴더 또는 항목이다. 예를 들어, 기기 "Johns_Desktop"은 Johns_Information이라 불리는 볼륨을 가지며, 이 볼륨 내에는 Contacts_Categories라 불리는 폴더가 존재하며, 이 폴더는 John에 대한 작업 연락처를 갖는 Work라 불리는 폴더를 포함한다:

＼＼Johns_Desktop＼Johns_Information$＼Contacts_Categories＼Work

이것은 "WorkContacts"로 공유된다. 이 공유에 대한 정의에 의해, ＼＼Johns_Desktop＼WorkContacts＼JaneSmith는 유효한 저장 플랫폼 명칭이 되며, Person 항목 JaneSmith를 식별한다.

a) 공유 나타내기

공유 항목 타입은 공유 명칭, 및 공유 타겟(이것은 비 유지 링크(non-holding link)일 수 있음)과 같은 속성들을 갖는다. 예를 들어, 전술된 공유 명칭은 WorkContacts이며, 타겟은 볼륨 Johns_Information 상의 Contacts_Categories＼Work이다. 다음은 Share 타입에 대한 스키마 프레그먼트이다:

b) 공유 관리

공유는 항목이기 때문에, 공유는 다른 항목들처럼 관리될 수 있다. 공유는 생성, 삭제 및 수정될 수 있다. 공유는 또한 다른 저장 플랫폼 항목들과 같은 방식으로 보안된다.

c) 공유 액세스

애플리케이션은 ItemContext.Open() 메소스 호출시에 저장 플랫폼 API에 공유 명칭(예를 들어, ＼＼Johns_Desktop＼WorkContacts)을 전달함으로써 원격 저장 플랫폼 공유에 액세스한다. ItemContext.Open은 ItemContext 객체 인스턴스를 리턴한다. 그 후 저장 플랫폼 API는 로컬 저장 플랫폼 서비스와 대화한다(원격 저장 플랫폼 저장소에의 액세싱은 로컬 저장소 플랫폼을 통해 행해진다는 것을 상기). 이제, 로컬 저장 플랫폼 서비스는 주어진 공유 명칭(예를 들어, WorkContacts)을 사용하여 원격 저장 플랫폼 서비스(예를 들어, 기기 Johns_Desktop 상의)와 대화한다. 원격 저장 플랫폼 서비스는 그 후 WorkContacts를 Contacts_Categories＼Work로 번역하고, 그것을 연다. 그 후, 질의 및 다른 동작들이 다른 범위들처럼 수행된다.

d) 발견성

일 실시예에서, 애플리케이션 프로그램은 다음의 방식으로 주어진 <DNS Name> 상에서 사용가능한 공유를 발견할 수 있다. 제1 방식에 따라, 저장 플랫폼 API는 ItemContext.Open() 메소드 내의 범위 매개변수로서 DNS 명칭(예를 들어, Johns_Desktop)을 수락한다. 저장 플랫폼 API는 그 후 접속 스트링의 일부로서 이 DNS 명칭을 사용하여 저장 플랫폼 저장소에 접속한다. 이 접속으로, 애플리케이션이 할 수 있는 것은 오직 ItemContext.FindAll(typeof(Share))를 호출하는 것이다. 저장 플랫폼 서비스는 그 후 모든 첨부된 볼륨 상의 모든 공유를 결합하고, 공유 집합을 리턴한다. 제2 방식에 따라, 로컬 기기 상에서, 관리자는 FindAll(typeof(Share))에 의해 특정한 볼륨 상의, 또는 FindAll(typeof(Share), "Target(ShareDestination).Id = folderId")에 의해 특정한 폴더 상의 공유를 용이하게 발견할 수 있다.

14. Find의 시맨틱

Find* 메소드(그들이 ItemContext 객체 또는 개별적인 항목에 대해 호출되는지에 상관없이)는 일반적으로 주어진 문맥으로 항목(삽입된 항목 포함)에 적용된다. 중첩된 요소는 Find를 갖지 않는다(그들은 그들이 포함하는 Item들에 독립적으로 검색될 수 없음). 중첩된 요소는 Find를 가질 수 없다(그들은 그들의 포함 항목에 무관하게 검색되지 않음). 이것은 저장 플랫폼 데이터 모델에 의한 바람직한 시맨틱에 일관적이며, 여기서 중첩된 요소는 포함 항목으로부터의 그들의 "식별자"를 도출한다. 이러한 개념을 보다 명료하게 하기 위해, 유효한 및 무효한 찾기 동작의 예는 다음과 같다:

a) 시외 국번이 206인 시스템 내의 모든 전화 번호를 보여주는가?

무효, 찾기가 항목을 참조하지 않고 전화번호(요소)에 대해서 행해지기 때문.

b) 시외 국번이 206인 모든 Person들의 모든 전화 번호를 보여주는가?

무효, Person(=항목)이 참조되지만, 검색 기준은 그 항목에 관련되지 않음.

c) 시외 국번이 206인 Murali(=단 한 명의 사람)의 모든 전화 번호를 보여주는가?

유효, Item("Murali"로 명명된 Person)에 대한 검색 기준이 있기 때문.

이 규칙은 Base.Relationship 타입으로부터 직접적으로 또는 간접적으로 도출된 중첩 요소 타입에 대해서는 예외이다. 이러한 타입은 관계 클래스를 통해 개별적으로 질의될 수 있다. 이러한 질의들은, 저장 플랫폼 구현이 Relationship 요소를 저장하기 위해 그것을 항목 UDT 내부에 삽입하는 대신 "마스터 링크 테이블"을 채용하기 때문에 지원될 수 있다.

15. 저장 플랫폼 연락처 API

이 섹션은 저장 플랫폼 연락처 API의 개요를 설명한다. 연락처 API 배후의 스키마는 도 21a 및 21b에 나타낸다.

a) System.Storage.Contact의 개요

저장 플랫폼 API는 연락처 스키마 내에 항목 및 요소들을 다루기 위한 명칭 공간을 포함한다. 이 명칭 공간은 System.Storage.Contact로 불린다.

예를 들어, 이 스키마는 다음의 클래스들을 갖는다:

· Item: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location

· Elements: Profile, PostalAddress, EmailAddress, TelephoneNumber, RealTimeAddress, EAddress, FullName, BasicPresence, GroupMembership, RoleOccupancy

b) 도메인 거동

다음은 연락처 스키마에 대한 도메인 거동의 리스트이다. 충분히 높은 레벨로부터 관측할 때, 도메인 거동은 잘 체계화가능한 카테고리들에 속한다:

· 정적인 헬퍼. 예를 들어, 새로운 사람 연락처를 생성하기 위한 Person.CreatePersonalContact();

· 인스턴스 헬퍼. 예를 들어, 사용자(User 클래스의 인스턴스)를 자동 로그인으로 표시된 모든 프로파일로 로그인시키는 user.AutoLoginToAllProfiles();

· CategoryGUID. 예를 들어, Category.Home, Category.Work 등;

· 도출된 속성. 예를 들어, emailAddress.Address() - 주어진 emailAddress(=EmailAddress 클래스의 인스턴스)의 사용자 명칭 및 도메인 필드를 조합한 스트링을 리턴함; 및

· 도출된 집합. 예를 들어, person.PersonalEamilAddresses - Person 클래스의 인스턴스가 주어지면, 그 사람의 개인 이메일 어드레스를 획득함.

다음 테이블은 도메인 거동을 갖는 연락처 내의 각각의 클래스에 대한 이러한 메소드들의 리스트 및 그들이 속한 카테고리를 나타낸다.

BasicPresence	카테고리 URI	UnknownCategoryURI, OfflineCategoryURI, BusyCategoryURI, AwayCategoryURI, OnlineCategoryURI
	정적인 헬퍼	ConvertPresenceStateToString - 현재 상태를 위치 지정된 스트링으로 포매팅(실제로 로컬화가 추가될 필요가 있음; 지금은 익숙한 영어 스트링으로만 행해짐)
Category	카테고리 GUID	Home, Work, Primary, Secondary, Cell, Fax, Pager
EmailAddress	도출된 속성	Address - 상용자 명칭 및 도메인의 조합
	정적인 헬퍼	IsValidEmailAddress
Folder	도출된 속성	GetChildItemCollection - FolderMembership의 타겟에 기초하여 항목 집합을 만듦
	정적인 헬퍼	GetKnownFolder - 잘 알려진 폴더를 획득하기 위해 특정화된 질의
		AddToPersonalContacts - 항목을 잘 알려진 개인적인 연락처 폴더에 추가
Item	정적인 집합	GetItemFromID - ID 기반 질의를 행함
Relationship	인스턴스 헬퍼	BindToTarget - 타겟에 대한 항목을 리턴
Person	도출된 집합	PersonalRealtimeAddresses, PersonalEamilAddresses, PersonalTelephoneNumbers
	도출된 속성	OnlineStatus, OnlineStatusIconSource, PrimaryEmailAddress, PrimarySecurityID
	정적인 헬퍼	CreatePersonalContact, CreateTemporaryContact - 잘알려진 폴더에 새로운 사람을 생성
		GetCurrentUser - 현재 로그인한 사용자에 대한 Person을 획득
SecurityID	도출된 속성	UserName, DomainName, DomainUserName
TelephoneNumber	인스턴스 헬퍼	SetFromUserInputString - 전화 번호 스트링을 부분들로 파싱
	정적인 헬퍼	ParseNumber - 전화 번호 스트링을 부분들로 파싱
User	인스턴스 헬퍼	AutoLoginToAllProfiles - 자동로그인으로 표식된 모든 프로파일로 로그

16. 저장 플랫폼 파일 API

이 섹션은 본 발명의 일 실시예에 따른 저장 플랫폼 파일 API의 개요를 설명 한다.

a) 소개

(1) 저장 플랫폼 내에 NTFS 볼륨을 반영

저장 플랫폼은 기존 NTFS 볼륨 내의 콘텐츠를 색인하는 방식을 제공한다. 이것은 NTFS 내의 각각의 파일 스트림 또는 디렉토리로부터 속성을 추출("증진")하고, 이러한 속성을 저장 플랫폼 내에 항목으로 저장함으로써 이루어진다.

저장 플랫폼 파일 스키마는 증진된 파일 시스템 엔티티를 저장하기 위한 File 및 Directory의 두 개의 항목 타입을 정의한다. Directory 타입은 Folder 타입의 서브타입이며, 이것은 다른 Directory 항목 또는 File 항목을 포함하는 포함 폴더이다.

Directory 항목은 Directory 및 File 항목을 포함할 수 있으며, 그것은 임의의 다른 타입의 항목은 포함할 수 없다. 저장 플랫폼이 관련되는 한, Directory 및 File 항목은 데이터 액세스 API의 임의의 것으로부터 판독만 된다. 파일 시스템 증진 관리자(FSPM) 서비스는 변경된 속성들을 저장 플랫폼으로 비동기적으로 증진시킨다. File 및 Directory 항목의 속성은 Win32 API에 의해 변경될 수 있다. 저장 플랫폼 API를 사용하여 File 항목에 관련된 스트림을 포함하는 이러한 항목들의 속성들 중 임의의 것을 판독할 수 있다.

(2) 저장 플랫폼 명칭 공간 내의 파일 및 디렉토리 생성

NTFS 볼륨이 저장 플랫폼 볼륨으로 증진될 때, 그것 내의 모든 파일 및 디렉토리들은 그 볼륨의 특정 부분에 존재한다. 이 영역은 저장 플랫폼 관점으로부터 판독만 되며, FSPM은 새로운 디렉토리 및 파일들을 생성하고/하거나 기존 항목의 속성을 변경할 수 있다.

이 볼륨의 명칭 공간의 나머지 부분은 Principal, Organization, Document, Folder 등의 보통의 전반적인 저장 플랫폼 항목 타입을 포함한다. 저장 플랫폼은 또한 저장 플랫폼 명칭 공간의 임의의 부분 내에 파일 및 디렉토리를 생성하는 것을 허용한다. 이러한 "원시" 파일 및 디렉토리는 NTFS 파일 시스템 내에 부본을 갖지 않고, 저장 플랫폼 내에 전체적으로 저장된다. 또한, 속성에 대한 변경은 즉각적으로 가시화 가능하게 된다.

그러나, 프로그래밍 모델은 동일하게 남아있으며, 그들은 저장 플랫폼 데이터 액세스 API에 관련되는 한 여전히 판독만 된다. "원시" 파일 및 디렉토리는 Win32를 사용하여 갱신되어야 한다. 이것은 다음과 같은 개발자의 정신적 모델을 단순화한다, 즉:

1. 임의의 저장 플랫폼 항목 타입은 (물론, 허가에 의해 방해되지 않는 한)명칭 공간의 어느 곳에나 생성될 수 있음;

2. 임의의 저장 플랫폼 항목 타입은 저장 플랫폼 API를 사용하여 판독될 수 있음;

3. 파일 및 디렉토리를 제외한 모든 저장 플랫폼 항목 타입은 저장 플랫폼 API를 사용하여 작성됨.

4. 파일 및 디렉토리 항목이 명칭 공간 내의 어디에 있는지에 상관없이 그들에 기록하기 위해, Win32 API를 사용함.

5. "증진되는" 명칭 공간 내의 파일/디렉토리 항목에의 변경은 저장 플랫폼 내에 즉각적으로 나타나지 않을 수 있으며, "자발적인" 명칭 공간 내에서는 변경이 저장 플랫폼 내에 즉각적으로 반영됨.

b) 파일 스키마

도 25는 파일 API에 기초한 스키마를 예시한다.

c) System.Storage.Files의 개요

저장 플랫폼 API는 파일 객체들을 다루기 위한 명칭 공간을 포함한다. 이 명칭 공간은 System.Storage.Files로 불린다. System.Storage.Files 내의 클래스의 데이터 멤버는 저장 플랫폼 저장소에 저장된 정보를 직접적으로 반영하며, 이 정보는 파일 시스템 객체들로부터 "증진"되거나, 본래 Win32 API를 사용하여 생성될 수 있다. System.Storage.Files 명칭 공간은 FileItem 및 DirectoryItem의 두 개의 클래스를 갖는다. 이러한 클래스 및 메소드의 멤버는 도 25 내의 스키마 다이어그램을 살펴봄으로써 쉽게 예측될 수 있다. FileItem 및 DirectoryItem은 저장 플랫폼 API로부터 판독만 된다. 그들을 수정하기 위해, Win32 API 또는 Systme.IO 내의 클래스를 사용해야 한다.

d) 코드 예

이 섹션에서는 System.Storage.Files 내의 클래스들의 사용을 예시하는 세 개의 코드 예가 제공된다.

(1) 파일 열고 쓰기

이 예는 "통상적인" 파일 조작을 어떻게 하는지를 나타낸다.

라인 3은 FindByPath를 사용하여 파일을 연다. 라인 7은 파일이 쓰기가능한지를 체크하기 위해 증진된 속성, IsReadOnly의 사용을 나타낸다. 그렇다면, 라인 9에서 FileItem 객체에 대해 OpenWrite() 메소드를 사용하여, 파일 스트림을 획득한다.

(2) 질의 사용

저장 플랫폼 저장소가 파일 시스템으로부터 증진된 속성을 유지하므로, 파일에 대해 용이하게 풍부한 질의를 할 수 있다. 이 예에서, 최근 3일 내에 수정된 모든 파일들이 리스트된다:

이것은 질의를 사용하는 또 다른 예이며, 이것은 특정한 타입(=확장)의 기록가능한 파일 모두를 찾는다.

e) 도메인 거동

일 실시예에서, 표준형 속성 및 메소드 이외에, 파일 클래스는 또한 도메인 거동(직접 코딩한 속성 및 메소드)들도 갖는다. 이러한 거동들은 일반적으로 대응하는 System.IO 클래스 내의 메소드에 기초한다.

J. 결론

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

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

부록 A

부록 B

부록 C

Claims (16)

1. 저장된 데이터가 항목들, 요소들 및 관계들의 관점으로 정의된 데이터 저장소- 항목은 상기 데이터 저장소 내에 저장가능한 데이터의 단위이며 하나 이상의 요소들을 포함하고, 요소는 하나 이상의 필드들을 포함하는 타입의 인스턴스(instance)이고, 관계는 적어도 두 개의 항목들 간의 링크임 -;

   항목들, 요소들 및 관계들의 상이한 타입들을 정의하는 스키마들의 세트; 및

   상기 스키마들의 세트에 정의된 상기 상이한 항목들, 요소들 및 관계들의 각각에 대한 클래스를 포함하는 애플리케이션 프로그래밍 인터페이스

   를 포함하는 저장 플랫폼.
2. 제1항에 있어서, 데이터는 또한 기존 항목 타입에 대한 확장 형태로 상기 데이터 저장소에 저장될 수 있으며, 상기 애플리케이션 프로그래밍 인터페이스는 각각의 상이한 항목 확장에 대한 클래스를 포함하는 저장 플랫폼.
3. 제1항에 있어서, 상기 항목, 요소 및 관계의 각 타입에 대한 클래스는 항목, 요소 및 관계의 각 타입을 정의하는 상기 스키마들의 세트에 기초하여 자동으로 생성되는 저장 플랫폼.
4. 제1항에 있어서, 상기 항목, 요소 및 관계의 각 타입에 대한 클래스들은 데 이터 클래스들의 세트를 정의하고, 상기 애플리케이션 프로그래밍 인터페이스는 상기 데이터 클래스들에 대한 거동들의 공통 세트를 정의하는 클래스들의 제2 세트를 더 포함하는 저장 플랫폼.
5. 제4항에 있어서, 상기 클래스들의 제2 세트는 저장 플랫폼 범위를 나타내고 상기 데이터 저장소에 대한 질의들에 대한 문맥을 제공하는 제1 클래스, 및 상기 데이터 저장소에 대한 질의의 결과들을 나타내는 제2 클래스를 포함하는 저장 플랫폼.
6. 제1항에 있어서, 상기 데이터 저장소가 구현된 데이터베이스 엔진을 더 포함하며,

   상기 데이터 저장소 내의 항목들, 요소들 및 관계들의 상이한 타입들은 상기 데이터베이스 엔진에 사용자 정의 타입(UDT)으로 구현되는 저장 플랫폼.
7. 제6항에 있어서, 상기 애플리케이션 프로그래밍 인터페이스는, 애플리케이션 프로그래머를 상기 데이터베이스 엔진의 질의 언어의 상세(details)로부터 격리시키는 방식으로, 애플리케이션 프로그래머들이 상기 데이터 저장소 내의 상기 항목들의 다양한 속성들에 기초하여 질의들을 형성할 수 있게 하는 질의 모델을 제공하는 저장 플랫폼.
8. 데이터를 저장, 체계화, 공유 및 검색하기 위한 저장 플랫폼과 애플리케이션 프로그램 사이의 애플리케이션 프로그래밍 인터페이스를 제공하기 위한 방법으로서, 상기 저장 플랫폼은 저장된 데이터가 항목들, 요소들 및 관계들의 관점으로 정의된 데이터 저장소를 포함하며, 항목은 상기 데이터 저장소에 저장가능한 데이터의 단위이며 하나 이상의 요소들을 포함하고, 요소는 하나 이상의 필드들을 포함하는 타입의 인스턴스이고, 관계는 적어도 두 개의 항목들 간의 링크이며,

   상기 방법은,

   항목들, 요소들 및 관계들의 상이한 타입들을 정의하는 스키마들의 세트를 제공하는 단계; 및

   상기 스키마들의 세트 내에 정의된 상기 상이한 항목들, 요소들 및 관계들의 각각에 대한 클래스를 상기 애플리케이션 프로그래밍 인터페이스의 부분으로서 생성하는 단계

   를 포함하는 방법.
9. 제8항에 있어서, 데이터는 또한 기존 항목 타입에 대한 확장 형태로 상기 데이터 저장소에 저장될 수 있으며,

   각각의 상이한 항목 확장에 대한 클래스를 생성하는 단계를 더 포함하는 방법.
10. 제9항에 있어서, 상기 항목, 요소 및 관계의 각 타입에 대해 생성된 클래스 들은 데이터 클래스들의 세트를 정의하고,

    상기 데이터 클래스들에 대한 거동들의 공통 세트를 정의하는 클래스들의 제2 세트를 상기 애플리케이션 프로그래밍 인터페이스의 추가적인 부분으로서 제공하는 단계를 더 포함하는 방법.
11. 제10항에 있어서, 상기 클래스들의 제2 세트는 저장 플랫폼 범위를 나타내고 상기 데이터 저장소에 대한 질의들에 대한 문맥을 제공하는 제1 클래스, 및 상기 데이터 저장소에 대한 질의의 결과들을 나타내는 제2 클래스를 포함하는 방법.
12. 제8항에 있어서, 상기 저장 플랫폼의 데이터 저장소는 데이터베이스 엔진 상에 구현되고,

    상기 데이터 저장소 내에 항목들, 요소들 및 관계들의 상이한 타입들을 상기 데이터 베이스 엔진 내에 사용자 정의 타입(UDT)으로 구현하는 단계를 더 포함하는 방법
13. 데이터를 저장, 체계화, 공유 및 검색하기 위한 저장 플랫폼과 애플리케이션 프로그램 사이의 애플리케이션 프로그래밍 인터페이스에 있어서,

    상기 저장 플랫폼은 저장된 데이터가 항목들, 요소들 및 관계들의 관점으로 정의된 데이터 저장소를 포함하며, 항목은 상기 데이터 저장소에 저장가능한 데이터의 단위이며 하나 이상의 요소들을 포함하고, 요소는 하나 이상의 필드들을 포함 하는 타입의 인스턴스이고, 관계는 적어도 두 개의 항목들 간의 링크이며,

    스키마들의 세트가 항목들, 요소들 및 관계들의 상이한 타입들을 정의하며,

    상기 스키마들의 세트 내에 정의된 상기 상이한 항목들, 요소들 및 관계들의 각각에 대한 클래스를 포함하는 애플리케이션 프로그래밍 인터페이스.
14. 제13항에 있어서, 데이터는 또한 기존 항목 타입에 대한 확장 형태로 상기 데이터 저장소에 저장될 수 있으며,

    각각의 상이한 항목 확장에 대한 클래스를 더 포함하는 애플리케이션 프로그래밍 인터페이스.
15. 제13항에 있어서, 상기 항목, 요소 및 관계의 각 타입에 대한 클래스들은 데이터 클래스들의 세트를 정의하고,

    상기 데이터 클래스들에 대한 거동들의 공통 세트를 정의하는 클래스들의 제2 세트를 더 포함하는 애플리케이션 프로그래밍 인터페이스.
16. 제15항에 있어서, 상기 클래스들의 제2 세트는 저장 플랫폼 범위를 나타내고 상기 데이터 저장소에 대한 질의들에 대한 문맥을 제공하는 제1 클래스, 및 상기 데이터 저장소에 대한 질의의 결과들을 나타내는 제2 클래스를 포함하는 애플리케이션 프로그래밍 인터페이스.

Images