KR20060110733A - 중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을동기화하는 시스템 및 방법 - Google Patents

중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을동기화하는 시스템 및 방법 Download PDF

Info

Publication number
KR20060110733A
KR20060110733A KR1020057012447A KR20057012447A KR20060110733A KR 20060110733 A KR20060110733 A KR 20060110733A KR 1020057012447 A KR1020057012447 A KR 1020057012447A KR 20057012447 A KR20057012447 A KR 20057012447A KR 20060110733 A KR20060110733 A KR 20060110733A
Authority
KR
South Korea
Prior art keywords
item
synchronization
intermediary
client
storage platform
Prior art date
Application number
KR1020057012447A
Other languages
English (en)
Other versions
KR101149959B1 (ko
Inventor
다샤트쿠마 샤
레브 노빅
마이클 더블유. 토마스
닐스 에이치. 폴만
오케추크워 씨. 에체루오
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/US2003/027419 external-priority patent/WO2005029314A1/en
Priority claimed from US10/646,646 external-priority patent/US7349913B2/en
Priority claimed from US10/692,508 external-priority patent/US7483923B2/en
Priority claimed from US10/883,621 external-priority patent/US7512638B2/en
Priority claimed from US10/889,423 external-priority patent/US7401104B2/en
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Priority claimed from PCT/US2004/024441 external-priority patent/WO2005024551A2/en
Publication of KR20060110733A publication Critical patent/KR20060110733A/ko
Application granted granted Critical
Publication of KR101149959B1 publication Critical patent/KR101149959B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles

Abstract

본 발명은, 공통 저장 플랫폼(예를 들어, 관련 발명의 새로운 저장 플랫폼)을 이용하는 2개의 클라이언트의 (예를 들어, 새로운 저장 플랫폼에 대하여 동기화 지원하지 않는 레거시 저장 플랫폼을 사용하는 대신에) 동일한 공통 저장 플랫폼을 사용하지 않는 중개자를 통해 동기화하기 위한 동기화 시스템 및 방법에 관한 것이다. 데이터는 현존하는 중개자 능력을 이용하여 동기화되지만, 여기에서 클라이언트의 데이터 구조는 보존된다. "어댑터"는 클라이언트의 저장 플랫폼에 고유한 데이터 구조 요소를 보존할 능력이 없는 중개자를 보상함으로써 클라이언트가 중개자와 상호작용할 수 있게 하기 위해 사용된다. 특정 실시예는 클라이언트에서 중개자로의 업로드 동기 데이터 및/또는 중개자에서 클라이언트로의 다운로드 동기 데이터의 어느 하나 또는 둘다에 관한 것이다. 소정의 부가적인 실시예는 또한 중개자 상의 데이터 압축에 관한 것이다.
중개자, STI 어댑터, 저장 플랫폼, 동기 파일, 송신 동기 동작, 수신 동기 동작, 압축 동작

Description

중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을 동기화하는 시스템 및 방법{SYSTEM AND METHODS FOR SYNCHRONIZING COMPUTER SYSTEMS THROUGH AN INTERMEDIARY FILE SYSTEM SHARE OR DEVICE}
<상호 참조>
본 출원은 2004년 7월 12일자로 출원된 "중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을 동기화하는 시스템 및 방법"이라는 제목의 미국 특허 출원(번호는 아직 지정되지 않음)(대리인 문서 번호 MSFT-4484)에 대한 우선권을 주장하며, 2003년 4월 30일자로 출원된 미국 가출원 번호 60/567,141(대리인 문서 번호 MSFT-3939/306727.01)에 대한 우선권을 주장하고; 또한, 2004년 6월 30일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 정보 관리 가능 단위들에 대한 피어-투-피어 동기화에 대한 충돌하는 처리를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/883,621(대리인 문서 번호 MSFT-2854)의 부분 연속이며, 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 정보 관리 가능 단위들에 대한 관계 및 계층적 동기화 서비스를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/692,508(대리인 문서 번호 MSFT-2845)의 부분 연속이며, 2003년 8월 21일자로 출원된 데이터의 체계화, 검색 및 공유를 위한 저장 플랫폼"이라는 제목의 "미국 특허 출원 10/646,646(대리인 문서 번호 MSFT-2734)의 부분 연속이고; 또한, 2003년 8월 21일자로 출원된 국제 출원 PCT/US03/27419(대리인 문서 번호 MSFT-2778)에 대한 우선권을 주장하며, 이들 출원의 개시 내용은 본 명세서에서 참고로 반영된다.
본 출원은 다음의 공동 양도된 출원들에 개시된 발명들과 내용이 관련되어 있으며, 이들 출원들의 내용은 본 명세서에 그 전체(및 편의를 위해 부분 요약됨)가 반영되어 있다: 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능하지만 물리적 표현에 무관한 정보의 단위들을 표현하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/647,058; 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 그들의 물리적 표현으로부터 분리하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 10/646,941; 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하기 위한 기본 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,940; 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하기 위한 최상위 레벨 구조를 제공하는 코어 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,632; 2003년 8월 21일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들 간의 관계를 표현하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,645; 2003년 8월 21일자로 출원된 "항목 기반 저장 플랫폼을 가진 애플리케이션 프로그램들을 인터페이스하기 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,575; 2003년 8월 21일자로 출 원된 "항목 기반 저장 플랫폼에서의 데이터 모델링을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,580; 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들을 체계화하는 디지털 화상 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/692,779; 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들에 대한 관계 및 계층적 동기화 서비스를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/692,515; 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들에 대한 동기화 스키마의 구현을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/693,362; 및 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 관리 가능한 정보의 단위들에 대한 확장 및 상속을 위한 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/693,575.
본 발명은 일반적으로, 동기화에 관한 것으로서, 더 상세하게는, 공통 저장 플랫폼(예를 들어, WinFS)을 사용하지만 다른 중간 파일 시스템 애플리케이션 프로그래밍 인터페이스(API) 액세스가능 파일 공유 또는 다른 저장 장치(예를 들어, API 액세스가능한 Win32 파일 공유 또는 다른 저장 장치)를 통해 동기하여 데이터-공유, 최종 사용자 로밍(최종 사용자 프로파일 및 그 동등물을 로밍하는 것을 포함하지만, 그것으로 제한되지 않음) 및 다른 동기화 목적을 지원하는 2개 이상의 컴퓨터 사이의 동기화에 관한 것이다.
개별 디스크 용량은 지난 10년 동안 해마다 약 70%씩 증가하여 왔다. 무어의 법칙은 수년 동안 이루어진 놀랄만한 CPU 성능의 향상을 정확히 예측하였다. 유선 및 무선 기술은 엄청난 접속성 및 대역폭을 제공하였다. 현재의 경향이 계속된다고 가정하면, 수년 내에 평균적인 랩탑 컴퓨터는 약 1 테라바이트(TB)의 저장 용량을 가질 것이고, 수백만 개의 파일을 포함할 것이며, 500 기가바이트(GB) 드라이브가 일반적으로 될 것이다.
소비자들은 그들의 컴퓨터를 주로 통신과, 전통적인 개인 정보 관리자(PIM) 스타일의 데이터인지 디지털 음악 또는 사진과 같은 매체인지에 관계없는 개인 정보의 체계화에 이용한다. 디지털 콘텐츠의 양, 및 미처리 바이트(raw bytes)를 저장하는 능력은 엄청나게 증가하여 왔지만, 소비자들이 데이터를 체계화하고 통합하기 위해 사용할 수 있는 방법은 보조를 맞추지 못했다. 지식 노동자들은 정보를 관리하고 공유하는 데 막대한 양의 시간을 소비하며, 몇몇 연구에 의하면 지식 노동자들이 그들의 시간의 15-25%를 비생산적인 정보 관련 활동에 소비하는 것으로 추정되고 있다. 다른 연구에 따르면, 일반적인 지식 노동자는 정보를 검색하기 위해 하루에 약 2.5 시간을 소비하는 것으로 추정되고 있다.
개발자들 및 정보 기술(IT) 분야들은 사람, 장소, 시간 및 이벤트와 같은 것들을 표현하기 위한 공통 저장 추상화를 위해 그들 자신의 데이터 저장소를 구축하는 데 상당한 양의 시간 및 돈을 투자한다. 이것은 중복된 작업을 유발할 뿐만 아니라, 공통 데이터의 공통 검색 또는 공유를 위한 메카니즘이 없는 공통 데이터의 섬들을 생성한다. 마이크로소프트 윈도우 오퍼레이팅 시스템을 실행하는 컴퓨터 상에 오늘날 얼마나 많은 어드레스 북이 존재할 수 있는지를 고려하자. 이메일 클라이언트 및 개인용 회계 프로그램과 같은 많은 애플리케이션은 개별 어드레스 북을 유지하며, 각각의 프로그램이 개별적으로 유지하고 있는 어드레스 북 데이터에 대한 애플리케이션들의 공유는 거의 존재하지 않는다. 결과적으로, 회계 프로그램(예컨대, 마이크로소프트 머니)은 수취인에 대한 어드레스를 이메일 콘택 폴더(예컨대, 마이크로소프트 아웃룩에 있는 폴더)에 저장된 어드레스와 함께 공유하지 않는다. 실제로, 많은 사용자들은 다양한 장치를 갖고 있으며, 논리적으로 그들의 개인 데이터를 그들 자신들 사이에서, 그리고 셀 전화를 포함하는 다양한 추가 소스를 통해 MSN 및 AOL과 같은 사용 서비스로 동기해야 하는데, 그럼에도 공유 문서들의 협동은 문서들을 이메일 메시지에 첨부함으로써, 즉 수동으로 그리고 비효율적으로 충분히 달성된다.
이러한 협동의 부족에 대한 하나의 이유는 컴퓨터 시스템에서 정보의 체계화를 위한 전통적인 접근법이 파일을 저장하는 데 사용되는 저장 매체의 물리적 체계화의 추상화에 기초하여 다수의 파일을 폴더들의 디렉토리 계층 구조로 체계화하기 위해 파일-폴더-디렉토리 기반 시스템("파일 시스템")의 사용에 중점을 두어 왔다는 점이다. 1960년대에 개발된 멀틱스(Multics) 오퍼레이팅 시스템은 오퍼레이팅 시스템 레벨에서 저장 가능한 데이터의 단위들을 관리하기 위해 파일, 폴더 및 디렉토리의 사용을 개척한 것으로 여겨질 수 있다. 구체적으로, 멀틱스는 파일들의 계층 구조 내에서 심볼 어드레스를 사용하였는데(이에 따라 파일 경로의 아이디어 를 도입함), 파일들의 물리적 어드레스는 사용자에게(애플리케이션 및 최종 사용자) 투명하지 않았다. 이러한 파일 시스템은 임의의 개별 파일의 파일 포맷에는 전혀 관심이 없었으며, 파일들 사이의 관계들은 오퍼레이팅 시스템 레벨에서(즉, 계층 구조 내의 파일의 위치가 아님) 무관한 것으로 간주되었다. 멀틱스의 출현 이후, 저장 가능 데이터는 오퍼레이팅 시스템 레벨에서 파일, 폴더 및 디렉토리로 체계화되었다. 이들 파일은 일반적으로 파일 시스템에 의해 유지되는 특수 파일에 삽입된 파일 계층 구조 자체("디렉토리")를 포함한다. 또한, 이 디렉토리는 디렉토리 내의 다른 파일들 모두에 대응하는 엔트리들의 리스트, 및 계층 구조에서의 이러한 파일들의 노드 위치(본 명세서에서 폴더로서 지칭됨)를 유지한다. 이것은 약 40년 동안 이 기술의 상태였다.
그러나, 파일 시스템은 컴퓨터의 물리 저장 시스템에 상주하는 정보의 합리적인 표현을 제공하지만, 그럼에도 물리 저장 시스템의 추상화이며, 따라서 파일들의 사용은 사용자가 조작하는 것(컨텍스트, 특징 및 다른 단위들에 대한 관계)과 오퍼레이팅 시스템이 제공하는 것(파일, 폴더 및 디렉토리) 사이의 간접(해석) 레벨을 요구한다. 결과적으로, 사용자들(애플리케이션 및/또는 최종 사용자)은 그렇게 하는 것이 비효율적이거나 일관성이 없거나 바람직하지 않은 경우에도 정보의 단위들을 파일 시스템 구조로 만드는 것 밖에 선택할 수 없다. 더욱이, 기존 파일 시스템은 개별 파일에 저장된 데이터의 구조에 대해 거의 알지 못하며, 이 때문에 정보의 대부분은 이들을 작성한 애플리케이션에 의해서만 액세스(및 이해)될 수 있는 파일들 내에 갇힌 채 유지된다. 결과적으로, 이러한 정보에 대한 개요 설명 및 정보 관리 메카니즘의 결여는 개별 저장소들 사이에서 데이터가 거의 공유되지 않는 데이터 저장소들의 생성을 유발한다. 예를 들어, 많은 PC 사용자는 이들이 소정의 레벨에서 함께 상호작용하는 사람들에 대한 정보를 포함하는 5개 이상의 다른 저장소, 예를 들어 아웃룩 콘택, 온라인 계정 어드레스, 윈도우 어드레스 북, 퀵컨 페이이(Quicken Payees) 및 인스턴트 메시징(IM) 버디 리스트를 갖는데, 이는 파일들의 체계화가 PC 사용자들에게 심각한 문제를 제공하기 때문이다. 대부분의 기존 파일 시스템은 파일들 및 폴더들을 체계화하기 위해 중첩 폴더 메타포어를 사용하므로, 파일들의 수가 증가함에 따라 유연하고 효율적인 체계화 스킴을 유지하기 위해 필요한 노력은 아주 커졌다. 이러한 상황에서, 단일 파일에 대한 다양한 분류를 갖는 것이 매우 유용하겠지만, 기존 파일 시스템에서 하드 또는 소프트 링크를 사용하는 것은 성가시고 관리하기 어렵다.
파일 시스템의 단점을 해결하고자 했던 여러 성공하지 못한 시도가 과거에 행해졌다. 이러한 이전의 시도들 중 일부는 데이터가 물리적 어드레스에 의해서가 아니라 콘텐츠에 의해 액세스될 수 있는 메카니즘을 제공하기 위한 콘텐츠 어드레스 가능 메모리의 사용을 포함한다. 그러나, 이러한 노력들은 성공적이지 못한 것으로 입증되었는데, 이는 콘텐츠 어드레스 가능 메모리가 캐시 및 메모리 관리 유닛과 같은 장치들에 의한 소규모 사용에는 유용한 것으로 입증된 반면, 물리적 저장 매체와 같은 장치에서의 대규모 사용은 다양한 이유로 아직 가능하지 않기 때문이며, 따라서 이러한 솔루션은 존재하지 않는다. 객체 지향 데이터베이스(OODB) 시스템을 이용한 다른 시도가 이루어졌으나, 이러한 시도는 강력한 데이터베이스 특성 및 양호한 논-파일 표현을 특징으로 하지만, 파일 표현의 처리에 효과적이지 못했으며, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 파일 및 폴더 기반 계층 구조의 속도, 효율 및 단순성을 복제할 수 없었다. 스몰토크(및 다른 파생물)를 사용하려고 시도한 것들과 같은 다른 노력들은 파일 및 논-파일 표현의 처리에 아주 효과적이지만, 다양한 데이터 파일 사이에 존재하는 관계들을 효율적으로 체계화하고 이용하는 데 필요한 데이터베이스 기능이 부족하여 전체적인 시스템 효율이 수용될 수 없는 것으로 입증되었다. BeOS(및 다른 그러한 오퍼레이팅 시스템 연구)를 이용하려는 또 다른 시도는 소정의 필요한 데이터베이스 기능을 제공하면서 파일을 적절히 표현할 수 있음에도 불구하고 논-파일 표현의 처리에 적절하지 않음(전통적인 파일 시스템과 동일한 핵심적인 단점)이 입증되었다.
데이터베이스 기술은 유사한 문제가 존재하는 또 하나의 기술 영역이다. 예컨대, 관계형 데이터베이스 모델은 대단한 상업적 성공을 거두었지만, 실제로 개별 소프트웨어 벤더들(ISV)은 일반적으로 관계형 데이터베이스 소프트웨어 제품(예컨대, 마이크로소프트 SQL 서버)에서 이용할 수 있는 기능의 작은 부분을 이용한다. 대신에, 애플리케이션의 이러한 제품과의 상호작용의 대부분은 단순한 "취득(gets)" 및 "배치(puts)"의 형태이다. 이에 대한 아주 분명한 많은 이유가 있지만(예컨대, 플랫폼 또는 데이터베이스가 불가지론적임), 종종 주목되지 않는 하나의 중요한 이유는 데이터베이스가 주요 비지니스 애플리케이션 벤더가 실제로 필요로 하는 정확한 추상화를 반드시 제공하지는 못한다는 것이다. 예컨대, 실세계는 "고객" 또는 "주문"과 같은 "항목들"(주문의 삽입된 "라인 항목"을 그 내부의 항목 및 그의 항목으로서 함께)에 대한 개념을 갖지만, 관계형 데이터베이스는 단지 테이블 및 행에 대해서만 말한다. 결과적으로, 애플리케이션은 (몇 가지 예를 들면) 항목 레벨에서 일관성, 로킹, 보안 및/또는 트리거의 양태를 갖기를 원할 수 있지만, 일반적으로 데이터베이스는 테이블/행 레벨에서만 이러한 기능을 제공한다. 이것은 각 항목이 데이터베이스에서 소정 테이블 내의 단일 행으로 맵핑되는 경우에는 훌륭하게 동작할 수 있지만, 다수의 라인 항목을 가진 주문의 경우, 항목이 실제로는 다수의 테이블로 맵핑되는 이유들이 존재할 수 있으며, 그러한 경우, 단순한 관계형 데이터베이스 시스템은 올바른 추상화를 전혀 제공하지 못한다. 결과적으로, 애플리케이션은 이러한 기본 추상화를 제공하기 위해 데이터베이스의 상부에 논리를 구축해야 한다. 즉, 기본 관계 모델은 보다 높은 레벨의 애플리케이션이 쉽게 개발될 수 있는 데이터 저장용의 충분한 플랫폼을 제공하지 못하는데, 이는 기본 관계 모델이 애플리케이션과 저장 시스템 사이에 간접 레벨을 필요로 하기 때문이다(여기서, 데이터의 시맨틱 구조는 소정의 인스턴스에서 애플리케이션에서만 볼 수 있다). 일부 데이터베이스 벤더들은 보다 높은 레벨의 기능을 그들의 제품 내에 구축하고 있지만(예컨대, 객체 관계 능력, 새로운 체계화 모델 등의 제공), 그 어느 것도 필요한 포괄적인 솔루션의 종류를 아직 제공하지 못하고 있는데, 진정으로 포괄적인 솔루션은 유용한 데이터 모델 추상화(예컨대, "항목", "확장", "관계" 등) 및 유용한 도메인 추상화(예컨대, "사람", "위치", "이벤트" 등) 양자를 제공하는 솔루션이다.
기존의 데이터 저장 및 데이터베이스 기술의 전술한 결함에 비추어, 컴퓨터 시스템에서 모든 타입의 데이터를 체계화하고, 검색하고, 공유할 수 있는 향상된 능력을 제공하는 새로운 저장 플랫폼, 즉 기존의 파일 시스템 및 데이터베이스 시스템을 넘어 데이터 플랫폼을 확장하고 확대하며, 모든 타입의 데이터에 대한 저장소가 되도록 설계된 저장 플랫폼이 필요하다. 2003년 8월 21일자로 출원된 "데이터 체계화, 검색 및 공유에 대한 저장 플랫폼"이라는 제목의 미국 특허 출원 번호 10/646,646(대리인 문서 번호 MSTF-2734)에 개시된 본 발명은 이 필요를 충족한다. 2003년 10원 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 정보 관리 가능 단위들에 대한 관계 및 계층적 동기화 서비스를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/646,646(대리인 문서 번호 MSFT-2745), 및 2004년 6월 30일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 정보 관리 가능 단위들에 대한 피어-투-피어 동기화에 대한 충돌하는 처리를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원(번호는 아직 이용가능하지 않음)(대리인 문서 번호 MSFT-2854/306955.01)에 의해 개시된 본 발명에서 이 저장 플랫폼(충돌 해결 방법)에 대한 동기화 서비스도 제공된다.
물론, 이 관련 특허 출원에 개시된 새로운 저장 플랫폼의 초기의 사용으로, 다양한 개별 컴퓨터 시스템들을 포함하는 동기화 네트워크를 갖는 기업은 다른 개별 컴퓨터 시스템이 계속해서 레가시 저장 플랫폼을 사용하는 반면, 몇몇 개별 컴퓨터 시스템은 새로운 저장 플랫폼을 사용한다는 것에 혼합될 것이다. 따라서, 새로운 저장 플랫폼("클라이언트")을 이용하는 2개의 컴퓨터 시스템에 있어서, 레가시 저장 플랫폼("중개자")을 이용하는 컴퓨터 시스템을 통해 동기하는 것이 필요할 수 있다. 예를 들어, 몇몇 클라이언트는 로밍 사용자 프로파일(RUP) 또는 클라이언트 측 캐싱(CSC)을 갖는 폴더 재지시(Folder Redirection)와 같은 소프트웨어를 이용하는 레가시 로밍 서비스에 등록될 수 있다. 이러한 레가시 저장 플랫폼에 대한 레가시 로밍 소프트웨어는 새로운 저장 플랫폼에 대한 로밍 데이터를 지원하지 않기 때문에, 새로운 저장 플랫폼에 대한 새로운 로밍 서비스가 필요한다. 본 발명의 다양한 실시예는 중개자를 통한 클라이언트 동기화를 위한 시스템 및 방법에 관한 것이다.
<발명의 요약>
다음의 요약은 본 명세서에 참조로 반영된 관련 발명("관련 발명")과 관련하여 설명되는 발명의 다양한 양태의 개요를 제공한다. 이 요약은 본 발명의 중요한 양태들 모두를 망라한 설명을 제공하는 것을 의도하지 않지 않으며, 본 발명의 범위를 한정하지도 않는다. 오히려, 이 요약은 뒤따르는 상세한 설명 및 도면에 대한 서론으로서 기능하도록 의도된다.
관련 발명은 물론 본 발명은 일반적으로, 데이터를 체계화하고, 검색하고, 공유하기 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 기존 파일 시스템 및 데이터베이스 시스템을 넘어 데이터 저장의 개념을 확장하고 확대하며, 구조화된 데이터, 구조화되지 않은 데이터 또는 반 구조화된 데이터를 포함하는 모든 타입의 데이터에 대한 저장소가 되도록 설계되어 있다.
본 발명의 저장 플랫폼은 데이터베이스 엔진 상에 구현된 데이터 저장소를 포함한다. 데이터베이스 엔진은 객체 관계 확장들을 가진 관계형 데이터베이스 엔 진을 포함한다. 데이터 저장소는 데이터의 체계화, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델을 구현한다. 특정 타입의 데이터는 스키마에서 기술되며, 플랫폼은 새로운 타입의 데이터(본질적으로 스키마에 의해 제공되는 기본 타입의 서브타입)를 정의하도록 스키마 세트를 확장하기 위한 메카니즘을 제공한다. 동기화 능력은 사용자들 또는 시스템들 사이에서 데이터의 공유를 쉽게 한다. 종래의 파일 시스템에 대한 제한 없이 이러한 종래의 파일 시스템과 데이터 저장소의 연동을 허용하는 파일 시스템 유사 능력이 제공된다. 변경 추적 메카니즘은 데이터 저장소에 대한 변경을 추적하는 능력을 제공한다. 저장 플랫폼은 또한 애플리케이션이 저장 플랫폼의 전술한 능력들 모두에 액세스할 수 있고 스키마에 기술된 데이터에 액세스할 수 있게 하는 한 세트의 애플리케이션 프로그램 인터페이스를 포함한다.
데이터 저장소에 의해 구현되는 데이터 모델은 항목, 요소 및 관계에 의하여 데이터 저장의 단위들을 정의한다. 항목은 데이터 저장소에 저장할 수 있는 데이터의 단위이며, 하나 이상의 요소 및 관계를 포함할 수 있다. 요소는 하나 이상의 필드(본 명세서에 속성으로도 지칭됨)를 포함하는 타입의 인스턴스이다. 관계는 두 항목 사이의 링크이다. (본 명세서에서 사용되는 이들 및 다른 특정 용어들은 이들을 매우 근접하게 사용되는 다른 용어들과 분리하기 위해 대문자화될 수 있지만, 대문자화된 용어, 예컨대 "Item"과 대문자화되지 않은 동일 용어, 예컨대 "item"을 구별할 의도는 전혀 없으며, 어떠한 차이도 가정되거나 암시되지 않아야 한다.)
컴퓨터 시스템은 또한 각 항목이 하드웨어/소프트웨어 인터페이스 시스템에 의해 조작될 수 있는 개별 저장 가능한 정보 단위를 구성하는 복수의 항목; 상기 항목들에 대한 체계적인 구조를 구성하는 항목 폴더; 및 복수의 항목을 조작하기 위한 하드웨어/소프트웨어 인터페이스 시스템을 포함하며, 각 항목은 적어도 하나의 항목 폴더에 속하며, 둘 이상의 항목 폴더에 속할 수 있다.
항목 또는 항목의 속성 값들 중 일부는 영구 저장소로부터 도출되는 것과 달리 동적으로 계산될 수 있다. 즉, 하드웨어/소프트웨어 인터페이스 시스템은 항목이 저장되는 것을 요구하지 않으며, 현재의 항목들의 세트를 열거할 수 있는 능력, 또는 저장 플랫폼에 대한 그의 식별자가 주어질 때 항목을 검색할 수 있는 능력(애플리케이션 프로그래밍 인터페이스 또는 API를 설명하는 섹션에서 보다 상세히 설명됨)과 같은 소정의 동작들이 지원되는데, 예컨대 항목은 셀 전화의 현재 위치 또는 온도 센서에 읽은 온도일 수 있다. 하드웨어/소프트웨어 인터페이스 시스템은 다수의 항목을 조작할 수 있으며, 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리되는 다수의 관계에 의해 상호 접속되는 항목들을 더 포함할 수 있다.
컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템은 하드웨어/소프트웨어 인터페이스 시스템이 이해하고 소정의 예측 가능한 방식으로 직접 처리할 수 있는 한 세트의 코어 항목을 정의하기 위한 코어 스키마를 더 포함한다. 다수의 항목을 조작하기 위하여, 컴퓨터 시스템은 상기 항목들을 다수의 관계와 상호접속시키며, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 상기 관계들을 관리한다.
저장 플랫폼의 API는 저장 플랫폼 스키마 세트에 정의된 각 항목, 항목 확장 및 관계에 대한 데이터 클래스를 제공한다. 또한, API는 데이터 클래스들에 대한 공통 거동 세트를 정의하고 데이터 클래스들과 함께 저장 플랫폼 API에 대한 기본 프로그래밍 모델을 제공하는 한 세트의 프레임워크 클래스를 제공한다. 저장 플랫폼 API는, 기반 데이터베이스 엔진의 질의 언어의 상세로부터 애플리케이션 프로그래머들을 격리시키는 방식으로, 애플리케이션 프로그래머들이 데이터 저장소 내의 항목들의 다양한 속성에 기초하여 질의를 형성하는 것을 가능하게 하는 간략화된 질의 모델을 제공한다. 저장 플랫폼 API는 또한 애플리케이션 프로그램에 의해 이루어진 항목에 대한 변경을 수집한 후, 데이터 저장소가 구현되는 데이터베이스 엔진(또는 임의 종류의 저장 엔진)에 의해 요구되는 정확한 갱신들 내에 이들을 체계화한다. 이것은 애플리케이션 프로그래머들이 메모리 내에서 항목을 변경하는 것을 가능하게 하며, 데이터 저장소 갱신들의 복잡성을 API로 넘기는 것을 가능하게 한다.
본 발명의 저장 플랫폼은 그의 공통 저장 기초 및 스키마화된 데이터를 통해 소비자, 지식 노동자 및 기업에 보다 효율적인 애플리케이션의 개발을 가능하게 한다. 이것은 그의 데이터 모델에 고유한 능력들을 이용할 수 있게 해줄 뿐 아니라 기존 파일 시스템 및 데이터베이스 액세스 방법을 수용하고 확장하는 풍부하고 확장 가능한 API를 제공한다.
이러한 상호 관련된 발명들의 최우선 구조의 일부로서(상세한 설명의 섹션 II에서 상세히 설명됨), 특정 관련 발명은 특히 동기화 API(상세한 설명의 섹션 III에서 상세히 설명됨)와 관련되며, 저장 플랫폼의 광범위한 동기화 능력을 설명한다. 본 발명의 몇몇 실시예가 이 동기화 능력과 통합되어 피어-투-피어 동기 동안 일어나는 충돌을 처리하는 것이 기대된다. 충돌을 올바르게 효율적으로 처리하는 능력은 양호한 이용성을 보유하면서 데이터 손실을 최소화하고, 동기 동안의 사용자 개입의 필요를 감소시킨다. 이 때문에, 상세한 설명의 섹션 Ⅲ은 또한, 관련 발명의 동기화 시스템 또는 저장 플랫폼을 포함하지만 이것으로 제한되지 않는 피어-투-피어 동기화 시스템 내의 충돌을 처리하기 위한 시스템 및 방법에 관한 관련 발명의 여러 실시예에 대한 상세한 설명을 포함한다.
상술된 관점에서, 본 발명의 다양한 실시예는 공통 저장 플랫폼(예를 들어, 관련 발명의 새로운 저장 플랫폼)을 이용하여 (예를 들어, 그 자체가 새로운 저장 플랫폼에 대한 동기화를 지원하지 않는 레가시 저장 플랫폼을 이용하는 것 대신에) 동일한 공통 저장 플랫폼을 이용하지 않는 중개자를 통해 동기하는 2개의 클라이언트 둘 다의 동기화를 위한 시스템 및 방법에 관한 것이다. 요약하면, 본 발명의 여러 실시예는 데이터가 중개자의 기존 능력을 이용하여 동기되지만 클라이언트의 데이터 구조는 보존되는 방법을 채용한다. 여러 실시예는 "어댑터"를 이용하여, 클라이언트가 중개자와 상호작용할 수 있게 하며, 여기서, 상기 어댑터가 클라이언트의 새로운 저장 플랫폼에 고유한 데이터 구조 엘리먼트를 보존하는 중개자 능력에 대해 효율적으로 보상한다. 본 발명의 여러 실시예는 클라언트에서 중개자로의 업로드-동기성 데이터뿐만 아니라, 중개자에서 클라이언트로의 다운로드-동기성 데이터 둘 중 하나 또는 둘 다에 관한 것이다. 또한, 특정 실시예는 중개자 상의 데 이터의 압축에 관한 것이다.
관련 발명과 함께, 본 발명의 특정 특징 및 장점은 다음의 본 발명의 상세한 설명 및 첨부 도면으로부터 명백해질 것이다.
전술한 요약 및 아래의 발명의 상세한 설명은 첨부된 도면들과 함께 읽을 때 더 잘 이해된다. 본 발명을 설명하기 위해, 본 발명의 다양한 실시예가 도면들에 도시되어 있지만, 본 발명은 개시된 특정 방법 및 수단으로 한정되지 않는다.
도 1은 본 발명의 양태들이 구현될 수 있는 컴퓨터 시스템을 나타내는 블록도.
도 2는 3개의 컴포넌트 그룹, 즉 하드웨어 컴포넌트, 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트 및 애플리케이션 프로그램 컴포넌트로 분할된 컴퓨터 시스템을 나타내는 블록도.
도 2A는 파일 기반 오퍼레이팅 시스템에서 디렉토리 내의 폴더들에 그룹화된 파일들에 대한 종래의 트리 기반 계층 구조를 나타내는 도면.
도 3은 저장 플랫폼을 나타내는 블록도.
도 4는 항목들, 항목 폴더들 및 카테고리들 사이의 구조 관계를 나타내는 도면.
도 5A는 항목의 구조를 나타내는 블록도.
도 5B는 도 5A의 항목의 복합 속성 타입을 나타내는 블록도.
도 5C는 복합 타입들이 더 설명된(명시적으로 리스트된) "위치" 항목을 나타 내는 블록도.
도 6A는 항목을 기본 스키마에서 발견되는 그 항목의 서브타입으로서 나타내는 도면.
도 6B는 상속 타입들이 명시적으로 리스트된(직접 속성 외에) 도 6A의 서브타입 항목을 나타내는 블록도.
도 7은 2개의 최상위 레벨 클래스 타입, 즉 Item 및 PropertyBase를 포함하는 기본 스키마, 및 이로부터 도출되는 추가적인 기본 스키마 타입들을 나타내는 블록도.
도 8A는 코어 스키마 내의 항목들을 나타내는 블록도.
도 8B는 코어 스키마 내의 속성 타입들을 나타내는 블록도.
도 9는 항목 폴더, 그의 회원 항목들, 및 항목 폴더와 그의 회원 항목들 사이의 상호접속 관계를 나타내는 블록도.
도 10은 카테고리(다시, 항목 자체), 그의 회원 항목들, 및 카테고리와 그의 회원 항목들 사이의 상호접속 관계를 나타내는 블록도.
도 11은 저장 플랫폼의 데이터 모델의 참조 타입 계층 구조를 나타내는 도면.
도 12는 관계들이 어떻게 분류되는지를 나타내는 도면.
도 13은 통지 메카니즘을 나타내는 도면.
도 14는 2개의 트랜잭션이 모두 동일한 B 트리 내에 새로운 레코드를 삽입하는 예를 나타내는 도면.
도 15는 데이터 변경 검출 프로세스를 나타내는 도면.
도 16은 예시적인 디렉토리 트리를 나타내는 도면.
도 17은 디렉토리 기반 파일 시스템의 기존 폴더가 저장 플랫폼 데이터 저장소 내로 이동하는 예를 나타내는 도면.
도 18은 포함 폴더의 개념을 나타내는 도면.
도 19는 저장 플랫폼 API의 기본 구조를 나타내는 도면.
도 20은 저장 플랫폼 API 스택의 다양한 컴포넌트를 개략적으로 나타내는 도면.
도 21A는 예시적인 콘택 항목 스키마의 도면.
도 21B는 도 21A의 예시적인 콘택 항목 스키마에 대한 요소들의 도면.
도 22는 저장 플랫폼 API의 실행시간 프레임워크를 나타내는 도면.
도 23은 "FindAll" 동작의 실행을 나타내는 도면.
도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타내는 도면.
도 25는 파일 API가 기초로 하는 스키마를 나타내는 도면.
도 26은 데이터 보안을 위해 사용되는 액세스 마스크 포맷을 나타내는 도면.
도 27(a, b 및 c 부분)은 동일하게 보호되는 새로운 보안 영역이 기존 보안 영역으로부터 분리되는 것을 나타내는 도면.
도 28은 항목 검색 뷰의 개념을 나타내는 도면.
도 29는 예시적인 항목 계층 구조를 나타내는 도면.
도 30A는 인터페이스 Interface1을 제1 및 제2 코드 세그먼트들이 통신하는 콘딧으로서 나타내는 도면.
도 30B는 인터페이스가, 시스템의 제1 및 제2 코드 세그먼트들이 매체(M)를 통해 통신하는 것을 가능하게 하는 인터페이스 객체들 I1 및 I2를 포함하는 것으로 나타내는 도면.
도 31A는 인터페이스 Interface1에 의해 제공되는 기능이 어떻게 인터페이스의 통신을 변환하도록 다수의 인터페이스 Interface1A, Interface1B, Interface1C로 세분되는지를 나타내는 도면.
도 31B는 인터페이스 I1에 의해 제공되는 기능이 어떻게 다수의 인터페이스 I1a, I1b, I1c로 세분되는지를 나타내는 도면.
도 32A는 의미 없는 파라미터 정밀도가 무시되거나 임의의 파라미터로 대체될 수 있는 시나리오를 나타내는 도면.
도 32B는 인터페이스가 인터페이스를 무시하거나 파라미터를 추가하도록 정의된 대체 인터페이스에 의해 대체되는 시나리오를 나타내는 도면.
도 33A는 제1 및 제2 코드 세그먼트들이 이들 모두를 포함하는 모듈로 병합되는 시나리오를 나타내는 도면.
도 33B는 인터페이스의 일부 또는 전부가 병합된 인터페이스를 형성하기 위해 다른 인터페이스 내에 인라인 작성될 수 있는 시나리오를 나타내는 도면.
도 34A는 미들웨어의 하나 이상의 부분들이 어떻게 제1 인터페이스 상의 통신들을 하나 이상의 상이한 인터페이스에 적응시키기 위해 이들을 변환할 수 있는 지를 나타내는 도면.
도 34B는 코드 세그먼트가 어떻게 하나의 인터페이스로부터 통신을 수신하지만 기능을 제2 및 제3 인터페이스로 전송하기 위해 인터페이스와 함께 도입될 수 있는지를 나타내는 도면.
도 35A는 JIT(Just-In-Time) 컴파일러가 어떻게 하나의 코드 세그먼트로부터의 통신을 다른 코드 세그먼트로 변환하는지를 나타내는 도면.
도 35B는 하나 이상의 인터페이스를 동적으로 재기입하는 JIT 메소드가 상기 인터페이스를 동적으로 인수 분해하거나 변경하기 위해 적용될 수 있음을 나타내는 도면.
도 36은 공통 데이터 저장소의 3개의 인스턴스 및 이들을 동기화하는 컴포넌트들을 나타내는 도면.
도 37은 어떻게 상태가 계산되는지, 또는 그와 관련된 메타데이터가 교환되는지를 알지 못하는 단순한 어댑터를 가정하는 본 발명의 일 실시예를 나타내는 도면.
도 38A-D는 변경들에 대한 예외 및 솔루션을 하이라이트하기 위해 순차 변경 열거 방법을 이용하여 어떻게 변경들이 추적되고, 열거되고, 동기화되는지를 나타내는 도면.
도 39A는 충돌 처리 파이프라인을 나타내는 도면.
도 39B는 도 39A에 도시된 파이프라인의 논리적 횡단을 도시한 플로우차트.
도 40은 충돌 항목이 타겟 항목의 카피로 로그된 예를 도시하는 블록도.
도 41은 2개의 클라이언트가 중개자를 통해 동기해야 하는 시나리오를 도시한 블록도.
도 42는 클라이언트가 STI 어댑터를 통해 변경 데이터를 중개자에게 송신하는 단계("송신 동기" 동작)를 도시한 흐름도.
도 43은 클라이언트가 STI 어댑터를 통해 변경 데이터를 중개자로부터 수신하는 단계("수신 동기" 동작)를 도시한 흐름도.
도 44는 STI 어댑터(즉, 송신 동기와 수신 동기를 모두 할 수 있는 클라이언트와 관련된 STI 어댑터)가 중개자 상의 공동체 폴더 내의 데이터에 대한 압축 동작을 실행하는 단계("압축" 동작)를 도시한 흐름도.
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와 같은 사용자 인터페이스를 통해 하드웨어/소프트웨어 인터페이스 시스템과 상호작용하는 것을 가능하게 한다.
하드웨어/소프트웨어 인터페이스 시스템은 통상적으로 애플리케이션에 대한 다양한 서비스를 수행한다. 다수의 프로그램이 동시에 실행될 수 있는 멀티 태스킹 하드웨어/소프트웨어 인터페이스 시스템에서, 하드웨어/소프트웨어 인터페이스 시스템은 어느 애플리케이션이 어떤 순서로 실행되어야 하는지, 그리고 교대를 위해 다른 애플리케이션으로 스위칭하기 전에 각각의 애플리케이션에 대해 얼마나 많은 시간이 할당되어야 하는지를 결정한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 다수의 애플리케이션 사이에서의 내부 메모리의 할당을 관리하며, 하드 디스크, 프린터 및 다이얼-업 포트와 같은 부착된 하드웨어 장치에 대한 입출력을 처리한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 동작의 상태 및 발생했을 수 있는 임의의 에러에 관한 메시지를 각각의 애플리케이션(및 소정의 경우 최종 사용자)으로 전송한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 배치 작업(예컨대 인쇄)의 관리를 오프로딩하여, 개시 애플리케이션이 이 작업으로부터 자유롭게 되어 다른 처리 및/또는 동작을 재개하게 할 수 있다. 병렬 처리를 제공할 수 있는 컴퓨터 상에서, 하드웨어/소프트웨어 인터페이스 시스템은 또한 프로그램이 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와 함께 애플리케이션 프로그램에 의해 사용될 수 있다.
본 발명의 저장 플랫폼(300)은 사용자들 또는 시스템들 사이의 데이터 공유를 쉽게 하는 동기화 서비스(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는 항목의 구조를 나타내는 블록도이다. 항목의 고유 명칭은 "Location"이다. 항목의 적격 명칭은 이 항목의 구조가 코어 스키마 내에 특정 타입의 항목으로 정의되어 있음을 나타내는 "Core.Location"이다. (코어 스키마는 후술한다.)
위치 항목은 EAddress, MetropolitanRegion, Neighborhood 및 PostalAddress를 포함하는 다수의 속성을 갖는다. 각각에 대한 속성의 특정 타입은 속성 명칭 직후에 표시되며, 콜론(":")에 의해 속성 명칭과 구분된다. 타입 명칭의 우측에, 그 속성 타입에 대해 허용되는 값들의 수가 대괄호들("[]") 사이에 표시되는데, 콜론 우측의 별표("*")는 미지정 및/또는 비제한 수("다수")를 나타낸다. 콜론 우측 의 "1"은 기껏해야 하나의 값이 존재할 수 있다는 것을 나타낸다. 콜론 좌측의 제로("0")는 속성이 선택적이라는 것을 나타낸다(아무 값도 존재하지 않을 수 있다). 콜론 좌측의 "1"은 적어도 하나의 값이 존재해야 한다는 것을 나타낸다(속성이 필요하다). Neighborhood 및 MetropolitanRegion은 모두 미리 정의된 데이터 타입 또는 "단순 타입"(그리고 본 명세서에서 대문자화 없이 표시됨)인 "nvarchar"(또는 등가물) 타입이다. 그러나, EAddress 및 PostalAddress는 각각 EAddress 및 PostalAddress 타입의 정의된 타입 또는 "복합 타입"(여기서 대문자화에 의해 표시됨)의 속성들이다. 복합 타입은 하나 이상의 단순 데이터 타입 및/또는 다른 복합 타입으로부터 도출되는 타입이다. 항목의 속성들에 대한 복합 타입은 또한 "중첩 요소"를 구성하는데, 이는 복합 타입의 상세가 그의 속성들을 정의하기 위해 직접 항목 내에 중첩되고, 복합 타입에 관한 정보가 이들 속성을 가진 항목과 함께 (후술하는 바와 같이 항목의 경계 내에) 유지되기 때문이다. 이러한 타입화의 개념은 공지되어 있으며, 당업자들에게 쉽게 이해된다.
도 5B는 복합 속성 타입인 PostalAddress 및 EAddress를 나타내는 블록도이다. PostalAddress 속성 타입은 PostalAddress 속성 타입의 항목이 0 또는 1의 City 값, 0 또는 1의 CountryCode 값, 0 또는 1의 MailStop 값 및 임의 수(0 내지 다수)의 PostalAddressType 등등을 갖는 것으로 예상될 수 있다. 이러한 방식으로, 항목 내의 특정 속성에 대한 데이터의 형상이 그에 따라 정의된다. EAddress 속성 타입은 도시된 바와 유사하게 정의된다. 본 명세서에서는 선택적으로 사용되지만, 위치 항목에서 복합 타입을 표현하는 또 하나의 방법은 항목을 그 안에 리스 트된 각각의 복합 타입의 개별 속성들과 함께 드로잉하는 것이다. 도 5C는 복합 타입들이 더 기술되어 있는 위치 항목을 나타내는 블록도이다. 그러나, 이러한 도 5C의 위치 항목의 대체 표현은 도 5A에 도시된 것과 정확히 동일한 항목에 대한 것이라는 것을 이해해야 한다. 본 발명의 저장 플랫폼은 또한 서브 타입화를 허용하는데, 이에 따라 하나의 속성 타입이 다른 속성 타입의 서브 타입이 될 수 있다(하나의 속성 타입은 다른 부모 속성 타입의 속성을 상속한다).
속성들 및 이들의 속성 타입과 유사하지만 다르게, 항목들은 서브 타입화의 주체일 수도 있는 그들 자신의 항목 타입들을 고유하게 표현한다. 즉, 본 발명의 여러 실시예에서의 저장 플랫폼은 항목이 다른 항목의 서브 타입이 되는 것을 허용한다(이에 따라 하나의 항목은 다른 부모 항목의 속성을 상속한다). 더욱이, 본 발명의 다양한 실시예에서, 모든 항목은 기본 스키마에서 발견되는 제1 및 기본 항목 타입인 "항목" 항목 타입의 서브 타입이다. (기본 스키마도 후술된다). 도 6A는 기본 스키마에서 발견되는 Item 항목 타입의 서브 타입인 항목, 이 인스턴스 내의 위치 항목을 나타낸다. 이 도면에서, 화살표는 위치 항목이(모든 다른 항목과 같이) Item 항목 타입의 서브 타입임을 나타낸다. 모든 다른 항목이 도출되는 기본 항목인 Item 항목 타입은 ItemId 및 다양한 타임 스탬프와 같은 다수의 중요한 속성을 가지며, 이에 의해 오퍼레이팅 시스템 내의 모든 항목의 표준 속성을 정의한다. 이 도면에서, 이러한 Item 항목 타입의 속성들은 위치에 의해 상속되며, 이에 의해 위치의 속성이 된다.
Item 항목 타입으로부터 상속된 위치 항목의 속성을 표현하는 또 하나의 방 법은 위치를 그 안에 리스트된 부모 항목으로부터의 각각의 속성 타입의 개별 속성들과 함께 드로잉하는 것이다. 도 6B는 직접 속성 외에 상속된 타입들이 기술되는 위치 항목을 나타내는 블록도이다. 이 도면에서는 위치가 그의 속성들 모두와 함께, 즉 이 도면과 도 5A 양쪽에 도시된 직접 속성, 및 이 도면에는 도시되어 있으나 도 5A에는 없는(반면, 도 5A에서는, 위치 항목이 Item 항목 타입의 서브 타입이라는 것을 화살표로 표시함으로써 이들 속성이 참조된다) 상속된 속성과 함께 도시되어 있지만, 이 위치 항목은 도 5A에 도시된 것과 동일한 항목이라는 점에 유의하고 이해해야 한다.
항목은 독립 객체이며, 따라서 항목을 삭제할 경우, 항목의 직접 및 상속 속성 모두가 또한 삭제된다. 마찬가지로, 항목을 검색할 때, 수신되는 것은 항목 및 그의 모든 직접 및 상속 속성(그의 복합 속성 타입에 관한 정보 포함)이다. 본 발명의 소정 실시예는 특정 항목을 검색할 때 속성들의 서브 세트를 요구하는 것을 가능하게 하지만, 이러한 많은 실시예의 디폴트는 검색시 항목을 그의 모든 직접 및 상속 속성들과 함께 제공하는 것이다. 더욱이, 항목의 속성은 또한 그 항목의 타입의 기존 속성에 새로운 속성을 추가함으로써 확장될 수 있다. 이러한 "확장"은 그후 항목의 진정한 속성이 되며, 그 항목의 서브 타입은 확장 속성을 자동으로 포함할 수 있다.
항목의 "경계"는 그의 속성(복합 속성 타입, 확장 등을 포함)에 의해 표현된다. 항목의 경계는 또한 복사, 삭제, 이동, 생성 등과 같이 항목에 대해 수행되는 동작의 한계를 표현한다. 예컨대, 본 발명의 여러 실시예에서, 항목이 복사될 때, 그 항목의 경계 내의 모든 것이 또한 복사된다. 각 항목에 대해, 경계는 다음을 포함한다:
- 항목의 항목 타입, 및 항목이 다른 항목의 서브 타입인 경우(모든 항목이 기본 스키마 내의 단일 항목 및 항목 타입으로부터 도출되는 본 발명의 여러 실시예의 경우와 같이), 임의의 적용 가능한 서브 타입 정보(즉, 부모 항목 타입에 관한 정보). 복사되는 원본 항목이 다른 항목의 서브 타입인 경우, 레플리커도 그 동일 항목의 서브 타입일 수 있다.
- 있을 경우, 항목의 복합 타입 속성 및 확장. 원본 항목이 복합 타입(원시 또는 확장)의 속성을 가진 경우, 레플리커도 동일한 복합 타입을 가질 수 있다.
- 항목의 "소유 관계"에 대한 기록, 즉 이 항목(소유 항목)이 어떤 다른 항목(타겟 항목)을 소유하고 있는지를 나타내는 항목 자신의 리스트. 이것은 후술하는 바와 같이 항목 폴더와 특히 관련이 있으며, 규칙은 아래에서 모든 항목이 적어도 하나의 항목 폴더에 속해야 하는 것을 지시한다. 더욱이, 후술하는 삽입 항목과 관련하여, 삽입 항목은 이 삽입 항목이 복사, 삭제 등과 같은 동작을 위해 삽입되는 항목의 일부로서 간주된다.
2. 항목 식별
항목은 ItemID에 의해 글로벌 항목 공간 내에서 고유하게 식별된다. Base.Item 타입은 항목에 대한 식별자를 저장하는 타입 GUID의 필드 ItemID를 정의한다. 항목은 데이터 저장소(302) 내에 정확하게 하나의 식별자를 가져야 한다.
항목 참조는 항목을 찾고 식별하기 위한 정보를 포함하는 데이터 구조이다. 데이터 모델에서, 모든 항목 참조 타입이 도출되는 ItemReference라는 명칭의 추상 타입이 정의된다. ItemReference 타입은 Resolve라는 명칭의 가상 메소드를 정의한다. Resolve 메소드는 ItemReference를 분석하고, 항목을 리턴한다. 이 메소드는 참조가 주어질 때 항목을 검색하는 함수를 구현하는 ItemReference의 구체적인 서브 타입들에 의해 무시된다. Resolve 메소드는 저장 플랫폼 API(322)의 일부로서 호출된다.
ItemIDReference는 ItemReference의 서브 타입이다. 이것은 Locator 및 ItemID 필드를 정의한다. Locator 필드는 항목 도메인을 명명(즉, 식별)한다. 이것은 항목 도메인에 대한 Locator의 값을 분석할 수 있는 로케이터 분석 메소드에 의해 처리된다. ItemID 필드는 ItemID 타입이다.
ItemPathReference는 Locator 및 Path 필드를 정의하는 ItemReference의 특수 형태이다. Locator 필드는 항목 도메인을 식별한다. 이것은 항목 도메인에 대한 Locator의 값을 분석할 수 있는 로케이터 분석 메소드에 의해 처리된다. Path 필드는 Locator에 의해 제공되는 항목 도메인에서 루트된 저장 플랫폼 명칭 공간 내의 (상대) 경로를 포함한다.
이러한 타입의 참조는 세트 동작에서 사용될 수 없다. 참조는 일반적으로 경로 분석 프로세스를 통해 분석되어야 한다. 저장 플랫폼 API(322)의 Resolve 메소드는 이러한 기능을 제공한다.
전술한 참조 형태는 도 11에 도시된 참조 타입 계층 구조를 통해 표현된다. 이러한 타입으로부터 상속되는 추가적인 참조 타입들이 스키마에서 정의될 수 있다. 이들은 관계 선언에서 타겟 필드의 타입으로서 사용될 수 있다.
3. 항목 폴더 및 카테고리
후술하는 바와 같이, 항목 그룹은 항목 폴더(파일 폴더와 혼동하지 말 것)라고 하는 특수 항목 내에 체계화된다. 그러나, 대부분의 파일 시스템과 달리, 항목은 둘 이상의 항목 폴더에 속할 수 있으며, 따라서 항목이 하나의 항목 폴더에서 액세스되고 수정된 때, 이 수정된 항목은 다른 항목 폴더로부터 직접 액세스될 수 있다. 본질적으로, 항목에 대한 액세스는 상이한 항목 폴더들로부터 이루어질 수 있지만, 실제로 액세스되는 것은 실제로는 동일한 항목이다. 그러나, 항목 폴더는 그의 회원 항목들 모두를 반드시 소유하지는 않거나, 단순히 다른 폴더와 함께 항목들을 공유할 수 있으며, 따라서 항목 폴더의 삭제가 반드시 항목의 삭제로 귀착되는 것은 아니다. 그럼에도, 본 발명의 여러 실시예에서, 항목은 적어도 하나의 항목 폴더에 속해야 하며, 따라서 특정 항목에 대한 유일한 항목 폴더가 삭제된 경우, 몇몇 실시예에서는 항목이 자동으로 삭제되거나, 다른 실시예에서는 항목이 자동으로 디폴트 항목 폴더(예컨대, 다양한 파일-폴더 기반 시스템에서 사용되는 유사 명칭 폴더들과 개념적으로 유사한 "Trash Can" 항목 폴더)의 회원이 된다.
또한 후술하는 바와 같이, 항목은 또한 (a) 항목 타입(또는 타입들), (b) 특정 직접 또는 상속 속성(또는 속성들), 또는 (c) 항목 속성에 대응하는 특정 값(또는 값들)과 같은 공통 기술 특성에 기초하는 카테고리에 속할 수 있다. 예컨대, 개인 콘택 정보에 대한 특정 속성을 포함하는 항목은 자동으로 Contact 카테고리에 속할 수 있으며, 콘택 정보 속성을 가진 임의의 항목도 자동으로 이 카테고리에 속할 것이다. 마찬가지로, "New York City" 값의 위치 속성을 갖는 임의의 항목은 자동으로 NewYorkCity 카테고리에 속할 수 있다.
카테고리는 개념적으로 항목 폴더와 다른데, 이는 항목 폴더가 서로 관련되지 않은(즉 공통 기술 특성이 없는) 항목들을 포함할 수 있는 반면, 카테고리 내의 각 항목은 그 카테고리에 대해 기술되는 공통 타입, 속성 또는 값(공통성)을 가지며, 카테고리 내의 다른 항목들에 대한, 그리고 그들 사이에서의 관계에 대한 기초를 형성하는 것은 이러한 공통성이기 때문이다. 더욱이, 특정 폴더 내의 항목의 회원은 그 항목의 임의의 특정 양태에 강제로 기초하지 않는 반면, 소정 실시예에서 카테고리에 절대적으로 관련된 공통성을 가진 모든 항목은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 자동으로 그 카테고리의 회원이 될 수 있다. 개념적으로, 카테고리는 또한 특정 질의(예를 들어, 데이터베이스와 관련하여)의 결과에 기초하는 회원을 갖는 가상 항목 폴더로 간주될 수도 있으며, 따라서 이러한 질의의 조건(카테고리의 공통성에 의해 정의됨)을 만족시키는 항목들은 카테고리의 회원을 포함한다.
도 4는 항목들, 항목 폴더들 및 카테고리들 사이의 구조 관계를 나타낸다. 다수의 항목(402, 404, 406, 408, 410, 412,414, 416, 418, 420)은 다양한 항목 폴더(422, 424, 426, 428, 430)의 회원이다. 몇몇 항목들은 둘 이상의 항목 폴더에 속할 수 있는데, 예를 들어 항목 402는 항목 폴더들 422 및 424에 속한다. 몇몇 항목들, 예컨대 항목 402, 404, 406, 408, 410 및 412는 또한 하나 이상의 카테고리 432, 434 및 436의 회원이며, 다른 항목들, 예를 들어 항목들 414, 416, 418 및 420은 어떠한 카테고리에도 속하지 않을 수 있다(그러나, 이것은 임의의 속성의 소유가 자동으로 카테고리 내의 회원을 의미하고, 따라서 항목이 임의의 카테고리의 회원이 되지 않기 위해서는 완전히 특징이 없어야 하는 소정의 실시예에서 거의 가능하지 않다). 폴더들의 계층 구조와 달리, 카테고리 및 항목 폴더 양자는 도시된 바와 같은 방향 그래프와 보다 유사한 구조를 갖는다. 임의의 이벤트에서, 항목, 항목 폴더, 및 카테고리는 모두 항목(항목 타입은 상이함)이다.
파일, 폴더 및 디렉토리와 달리, 본 발명의 항목, 항목 폴더 및 카테고리는 특성상 "물리적"이 아닌데, 이는 이들이 물리적 컨테이너의 개념적 등가를 갖지 않으며, 따라서 항목들은 둘 이상의 위치에 존재할 수 있기 때문이다. 항목들이 둘 이상의 항목 폴더 위치에 존재할 수 있고 카테고리 내에 체계화될 수 있는 능력은 현재 이 분야에서 이용할 수 있는 것을 넘어서, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 향상되고 풍부한 데이터 조작 및 저장 구조 능력을 제공한다.
4. 스키마
a) 기본 스키마
항목의 생성 및 사용을 위한 보편적 기초를 제공하기 위하여, 본 발명의 저장 플랫폼의 다양한 실시예는 항목 및 속성을 생성하고 체계화하기 위한 개념적 프레임워크를 설정하는 기본 스키마를 포함한다. 기본 스키마는 항목 및 속성의 소 정의 특수 타입들, 및 서브 타입들이 더 도출될 수 있는 이러한 특수 기초 타입들의 특징들을 정의한다. 이러한 기본 스키마의 사용은 프로그래머가 개념적으로 항목들(및 이들 각각의 타입들)과 속성들(및 이들 각각의 타입들)을 구별하는 것을 허용한다. 더욱이, 기본 스키마는 모든 항목(및 이들에 대응하는 항목 타입)이 기본 스키마 내의 기본 항목(및 이에 대응하는 항목 타입)으로부터 도출될 때 모든 항목이 소유할 수 있는 속성들의 기본 세트를 설명한다.
도 7에 도시된 바와 같이, 그리고 본 발명의 여러 실시예와 관련하여, 기본 스키마는 3개의 최상위 레벨 타입, 즉 Item, Extension 및 PropertyBase를 정의한다. 도시된 바와 같이, 항목 타입은 기본 "항목" 항목 타입의 속성들에 의해 정의된다. 이와 달리, 최상위 레벨 속성 타입 "PropertyBase"는 미리 정의된 속성을 갖지 않으며, 단지 모든 다른 속성 타입이 도출되고, 도출된 모든 속성 타입이 상호 관련되는(단일 속성 타입으로부터 공동으로 도출됨) 앵커일 뿐이다. 확장 타입 속성은 확장이 어느 항목을 확장하는지는 물론, 항목이 다수의 확장을 가질 수 있을 때 하나의 확장을 다른 확장과 구별할 수 있는 식별자를 정의한다.
ItemFolder는 항목으로부터 상속된 속성들 외에 그의 회원들(있을 경우)에 대한 링크를 설정하기 위한 관계를 특징으로 하는 Item 항목 타입의 서브 타입이며, IdentityKey 및 Property는 PropertyBase의 서브 타입이다. 또한, CategoryRef는 IdentityKey의 서브 타입이다.
b) 코어 스키마
본 발명의 저장 플랫폼의 다양한 실시예는 최상위 레벨 항목 타입 구조에 대한 개념적 프레임워크를 제공하는 코어 스키마를 더 포함한다. 도 8A는 코어 스키마 내의 항목을 나타내는 블록도이고, 도 8B는 코어 스키마 내의 속성 타입을 나타내는 블록도이다. 파일-폴더 기반 시스템에서 상이한 확장자(*.com, *.exe, *.bat, *.sys 등) 및 다른 기준을 가진 파일들 사이의 차이는 코어 스키마의 함수와 유사하다. 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서, 코어 스키마는, 직접(항목 타입에 의해) 또는 간접으로(항목 서브 타입에 의해) 항목 기반 하드웨어/소프트웨어 인터페이스 시스템이 이해하고 소정의 예측 가능한 방식으로 직접 처리할 수 있는 하나 이상의 코어 스키마 항목 타입으로 모든 항목을 특징화하는 한 세트의 코어 항목 타입을 정의한다. 미리 정의된 항목 타입은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가장 공통적인 항목을 반영하며, 따라서 코어 스키마를 포함하는 미리 정의된 항목 타입을 이해하는 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 일정 레벨의 효율성이 얻어진다.
소정 실시예에서, 코어 스키마는 확장 가능하지 않은데, 즉 코어 스키마의 일부인 미리 정의되고 도출된 특정 항목 타입들을 제외하고는 기본 스키마 내의 항목 타입으로부터 어떠한 추가적인 항목 타입도 직접 서브 타입화될 수 없다. 코어 스키마에 대한 확장을 방지함으로써(즉, 코어 스키마에 새로운 항목의 추가를 방지함으로써), 저장 플랫폼은 코어 스키마 항목 타입들의 사용을 지시하는데, 이는 모든 후속 항목 타입이 반드시 코어 스키마 항목 타입의 서브 타입이기 때문이다. 이러한 구조는 추가적인 항목 타입을 정의함에 있어서 합리적인 정도의 유연성을 가능하게 하면서 미리 정의된 코어 항목 타입 세트를 갖는 이익도 유지할 수 있게 한다.
본 발명의 다양한 실시예에서, 그리고 도 8A를 참조하면, 코어 스키마에 의해 지원되는 특정 항목 타입은 다음 중 하나 이상을 포함한다.
- 카테고리: 이 항목 타입(및 이로부터 도출되는 서브 타입)의 항목들은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 유효한 카테고리를 나타낸다.
- 일용품: 값을 식별할 수 있는 항목
- 장치: 정보 처리 능력을 지원하는 논리 구조를 가진 항목
- 문서: 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 해석되지 않는 대신 문서 타입에 대응하는 애플리케이션 프로그램에 의해 해석되는 콘텐츠를 가진 항목
- 이벤트: 환경에서 소정의 발생을 기록하는 항목
- 위치: 물리적 위치(예컨대, 지리적 위치)를 나타내는 항목
- 메시지: 둘 이상의 원리(아래 정의됨) 사이의 통신 항목
- 주체(principal): ItemID와 별도로 명확하게 입증할 수 있는 적어도 하나의 식별자(예컨대, 사람, 조직, 그룹, 세대, 저자, 서비스 등의 식별자)를 가진 항목
- 문장: 제한 없이, 정책, 가입, 자격증 등을 포함하는 환경에 관한 특수 정보를 가진 항목
마찬가지로, 그리고 도 8B를 참조하면, 코어 스키마에 의해 지원되는 특정 속성 타입은 다음 중 하나 이상을 포함할 수 있다.
- 증명서(기본 스키마 내의 기본 PropertyBase 타입으로부터 도출됨)
- 본인 식별 키(기본 스키마 내의 IdentityKey 타입으로부터 도출됨)
- 우편 주소(Postal Address)(기본 스키마 내의 속성 타입으로부터 도출됨)
- 리치 텍스트(Rich Text)(기본 스키마 내의 속성 타입으로부터 도출됨)
- EAddress(기본 스키마 내의 속성 타입으로부터 도출됨)
- IdentitySecurityPackage(기본 스키마 내의 관계 타입으로부터 도출됨)
- RoleOccupancy(기본 스키마 내의 관계 타입으로부터 도출됨)
- BasicPresence(기본 스키마 내의 관계 타입으로부터 도출됨)
이들 항목 및 속성은 도 8A 및 도 8B에 설명된 그들 각각의 속성에 의해 또한 설명된다.
5. 관계
관계는 하나의 항목이 소스로 지정되고 다른 항목이 타겟으로 지정되는 바이너리 관계이다. 소스 항목 및 타겟 항목은 관계에 의해 관련된다. 소스 항목은 일반적으로 관계의 수명을 제어한다. 즉, 소스 항목이 삭제될 때, 항목들 사이의 관계도 삭제된다.
관계는 포함 및 참조 관계로 분류된다. 포함 관계는 타겟 항목의 수명을 제어하는 반면, 참조 관계는 어떠한 수명 관리 시맨틱도 제공하지 않는다. 도 12는 관계들이 분류되는 방식을 나타낸다.
포함 관계 타입은 유지 및 삽입 관계로 더 분류된다. 항목에 대한 모든 유지 관계가 제거될 때, 그 항목은 삭제된다. 유지 관계는 참조 카운팅 메카니즘을 통해 타겟의 수명을 제어한다. 삽입 관계는 복합 항목의 모델링을 가능하게 하며, 배타적 유지 관계로서 간주될 수 있다. 항목은 하나 이상의 유지 관계의 타겟일 수 있으나, 항목은 단 하나의 삽입 관계의 타겟일 수 있다. 삽입 관계의 타겟인 항목은 임의의 다른 유지 또는 삽입 관계의 타겟이 될 수 없다.
참조 관계는 타겟 항목의 수명을 제어하지 않는다. 참조 관계는 현수적일 수 있는데, 즉 타겟 항목이 존재하지 않을 수 있다. 참조 관계는 글로벌 항목 명칭 공간(즉, 원격 데이터 저장소 포함) 내의 어느 곳에서나 항목에 대한 참조를 모델링하는 데 사용될 수 있다.
항목의 인출은 그의 관계를 자동으로 인출하지 못한다. 애플리케이션은 항목의 관계를 명시적으로 요구해야 한다. 또한, 관계의 수정은 소스 또는 타겟 항목을 수정하지 못하며, 유사하게 관계의 추가는 소스/타겟 항목에 영향을 주지 못한다.
a) 관계 선언
명시적인 관계 타입은 다음 요소들과 함께 정의된다.
- 관계 명칭은 명칭 속성 내에 지정된다.
- 관계 타입은 다음 중 하나: 유지, 삽입, 참조. 이것은 타입 속성 내에 지정된다.
- 소스 및 타겟 엔드 포인트. 각 엔드 포인트는 참조되는 항목의 명칭 및 타입을 지정한다.
- 소스 엔드 포인트 필드는 일반적으로 ItemID 타입(선언되지 않음)이며, 관계 인스턴스와 동일한 데이터 저장소 내의 항목을 참조해야 한다.
- 유지 및 삽입 관계에 대해, 타겟 엔드 포인트 필드는 ItemIDReference 타입이어야 하며, 관계 인스턴스와 동일한 저장소 내의 항목을 참조해야 한다. 참조 관계에 대해, 타겟 엔드 포인트는 임의의 ItemReference 타입일 수 있으며, 다른 저장 플랫폼 데이터 저장소 내의 항목을 참조할 수 있다.
- 선택적으로 스칼라 또는 PropertyBase 타입의 하나 이상의 필드들이 선언될 수 있다. 이들 필드는 관계와 관련된 데이터를 포함할 수 있다.
- 관계 인스턴스는 글로벌 관계 테이블에 저장된다.
- 모든 관계 인스턴스는 조합(소스 ItemID, 관계 ID)에 의해 고유하게 식별된다. 관계 ID는 그들의 타입에 관계 없이 주어진 항목에 소스를 가진 모든 관계에 대해 주어진 소스 ItemID 내에서 고유하다.
소스 항목은 관계의 소유자이다. 소유자로서 지정된 항목이 관계의 수명을 제어하는 반면, 관계 자체는 그가 관계하는 항목으로부터 분리된다. 저장 플랫폼 API(322)는 항목과 관련된 관계를 노출시키기 위한 메카니즘을 제공한다.
다음은 관계 선언의 일례이다:
Figure 112005035516470-PCT00001
Figure 112005035516470-PCT00002
이것은 참조 관계의 일례이다. 관계는 소스 참조에 의해 참조되는 사람 항목이 존재하지 않는 경우 생성될 수 없다. 또한, 사람 항목이 삭제되면, 사람과 조직 사이의 관계 인스턴스는 삭제된다. 그러나, 조직 항목이 삭제되면, 관계는 삭제되지 않고 현수 상태가 된다.
b) 유지 관계
유지 관계는 타겟 항목의 참조 수 기반 수명 관리를 모델링하는 데 사용된다.
항목은 0개 이상의 항목에 대한 관계의 소스 엔드 포인트일 수 있다. 삽입된 항목이 아닌 항목은 하나 이상의 유지 관계의 타겟일 수 있다.
타겟 엔드 포인트 참조 타입은 ItemIDReference이어야 하며, 관계 인스턴스와 동일한 저장소 내의 항목을 참조해야 한다.
유지 관계는 타겟 엔드 포인트의 수명 관리를 이행한다. 유지 관계 인스턴스 및 이것이 목표로 하는 항목의 생성은 최소 동작(atomic operation)이다. 동일 항목을 목표로 하는 추가적인 유지 관계 인스턴스가 생성될 수 있다. 타겟 엔드 포인트로서 주어진 항목을 갖는 최종 유지 관계 인스턴스가 삭제되면, 타겟 항목도 삭제된다.
관계 선언에서 지정되는 엔드 포인트 항목의 타입은 일반적으로 관계의 인스턴스가 생성될 때 강제된다. 엔드 포인트 항목의 타입은 관계가 설정된 후에는 변경될 수 없다.
유지 관계들은 항목 명칭 공간의 형성에 중요한 역할을 한다. 이들은 소스 항목에 대한 타겟 항목의 명칭을 정의하는 "명칭" 속성을 포함한다. 이러한 상대적 명칭은 주어진 항목을 소스로 하는 모든 유지 관계에 대해 고유하다. 루트 항목에서 주어진 항목까지의 상대적 명칭들의 순서화된 리스트는 항목에 대한 완전한 명칭을 형성한다.
유지 관계는 방향 비순환 그래프(DAG)를 형성한다. 유지 관계가 생성될 때, 시스템은 순환이 생성되지 않는 것을 보장함으로써 항목 명칭 공간이 DAG를 형성하는 것을 보장한다.
유지 관계가 타겟 항목의 수명을 제어하는 반면, 타겟 엔드 포인트 항목의 동작 일관성을 제어하지 못한다. 타겟 항목은 유지 관계를 통해 타겟 항목을 소유하는 항목으로부터 동작면에서 독립적이다. 유지 관계의 소스인 항목에 대한 복사, 이동, 백업 및 다른 동작은 동일 관계의 타겟인 항목에 영향을 주지 못하는데, 예를 들면, 즉 폴더 항목의 백업은 폴더 내의 모든 항목(FolderMember 관계의 타겟들)을 자동으로 백업하지 못한다.
다음은 유지 관계의 일례이다.
Figure 112005035516470-PCT00003
FolderMember 관계는 일반적인 항목들의 집합으로서의 폴더의 개념을 가능하게 한다.
c) 삽입 관계
삽입 관계는 타겟 항목의 수명의 배타적인 제어의 개념을 모델링한다. 삽입 관계는 복합 항목들의 개념을 가능하게 한다.
삽입 관계 인스턴스 및 이것이 목표로 하는 항목의 생성은 최소 동작이다. 항목은 0개 이상의 삽입 관계의 소스일 수 있다. 그러나, 항목은 하나 및 단 하나의 삽입 관계의 타겟일 수 있다. 삽입 관계의 타겟인 항목은 유지 관계의 타겟이 될 수 없다.
타겟 엔드 포인트 참조 타입은 ItemIDReference이어야 하며, 관계 인스턴스와 동일한 데이터 저장소 내의 항목을 참조해야 한다.
관계 선언에서 지정되는 엔드 포인트 항목의 타입은 일반적으로 관계의 인스턴스가 생성될 때 강제된다. 엔드 포인트 항목의 타입은 관계가 설정된 후에는 변경될 수 없다.
삽입 관계는 타겟 엔드 포인트의 동작 일관성을 제어한다. 예컨대, 항목의 직렬화 동작은 그 항목은 물론 그들의 타겟들 모두로부터 나온 모든 삽입 관계의 직렬화를 포함할 수 있으며, 항목의 복사는 또한 그의 모든 삽입된 항목을 복사한다.
다음은 선언의 일례이다.
Figure 112005035516470-PCT00004
d) 참조 관계
참조 관계는 그것이 참조하는 항목의 수명을 제어하지 않는다. 심지어, 참조 관계는 타겟의 존재를 보장하지 않으며, 관계 선언에서 지정되는 타겟의 타입도 보장하지 않는다. 이것은 참조 관계가 현수 상태일 수 있다는 것을 의미한다. 또한, 참조 관계는 다른 데이터 저장소 내의 항목을 참조할 수 있다. 참조 관계는 웹 페이지 내의 링크와 유사한 개념으로 간주될 수 있다.
다음은 참조 관계 선언의 일례이다.
Figure 112005035516470-PCT00005
타겟 엔드 포인트에서 임의의 참조 관계가 허용된다. 참조 관계에 참여하는 항목들은 임의의 항목 타입일 수 있다.
참조 관계는 항목들 사이의 대부분의 비 수명 관리 관계를 모델링하는 데 사용된다. 타겟의 존재가 강제되지 않으므로, 참조 관계는 느슨하게 결합된 관계를 모델링하는 데 편리하다. 참조 관계는 다른 컴퓨터 상의 저장소를 포함하는 다른 데이터 저장소 내의 항목을 타겟으로 하여 사용될 수 있다.
e) 규칙 및 제한
다음의 추가적인 규칙 및 제한은 관계에 적용된다.
- 항목은 (단 하나의 삽입 관계) 또는 (하나 이상의 유지 관계)의 타겟이어야 한다. 하나의 예외는 루트 항목이다. 항목은 0개 이상의 참조 관계의 타겟일 수 있다.
- 삽입 관계의 타겟인 항목은 유지 관계의 소스일 수 없다. 이것은 참조 관계의 소스일 수 있다.
- 항목은 파일로부터 승진된 경우 유지 관계의 소스가 될 수 없다. 이것은 삽입 관계 및 참조 관계의 소스가 될 수 있다.
- 파일로부터 승진된 항목은 삽입 관계의 타겟이 될 수 없다.
f) 관계들의 순서화
적어도 하나의 실시예에서, 본 발명의 저장 플랫폼은 관계들의 순서화를 지원한다. 순서화는 기본 관계 정의 내의 "순서(Order)"라는 명칭의 속성을 통해 달 성된다. 순서 필드에 대한 고유성 제한은 존재하지 않는다. 동일한 "순서" 속성 값을 가진 관계들의 순서는 보장되지 않으나, 이들이 보다 낮은 "순서" 값을 가진 관계 후에, 그리고 보다 높은 "순서" 필드 값을 가진 관계 전에 순서화될 수 있는 것은 보장된다.
애플리케이션은 조합(SourceItemID, RelationshipID, Order) 상에서의 순서화에 의해 디폴트 순서로 관계를 취득할 수 있다. 주어진 항목으로부터 나온 모든 관계 인스턴스는 집합 내의 관계의 타입에 관계없이 단일 집합으로서 순서화된다. 그러나, 이것은 주어진 타입의 모든 관계(예컨대, FolderMembers)가 주어진 항목에 대한 관계 집합의 순서화된 서브세트임을 보장한다.
관계를 조작하기 위한 데이터 저장소 API(312)는 관계들의 순서화를 지원하는 한 세트의 동작을 구현한다. 다음 용어들은 동작의 설명을 돕기 위해 도입된다.
- RelFirst는 순서 값 OrdFirst를 가진 순서화된 집합 내의 첫 번째 관계이다.
- RelLast는 순서 값 OrdLast를 가진 순서화된 집합 내의 최종 관계이다.
- RelX는 순서 값 OrdX를 가진 집합 내의 소정의 관계이다.
- RelPrev는 OrdX보다 작은 순서 값 OrdPrev를 가진 집합에서 RelX에 가장 가까운 관계이다.
-RelNext는 OrdX보다 큰 순서 값 OrdNext를 가진 집합에서 RelX에 가장 가까운 관계이다.
동작들은 다음을 포함하지만 이에 한하지 않는다.
- InsertBeforeFirst(SourceItemID, Relationship)는 집합 내의 제1 관계로서 관계를 삽입한다. 새로운 관계의 순서 속성 값은 OrdFirst보다 작을 수 있다.
- InsertAfterLast(SourceItemID, Relationship)는 집합 내의 최종 관계로서 관계를 삽입한다. 새로운 관계의 순서 속성 값은 OrdLast보다 클 수 있다.
- InsertAt(SourceItemID, ord, Relationship)는 순서 속성에 대한 지정 값을 가진 관계를 삽입한다.
- InsertBefore(SourceItemID, ord, Relationship)는 주어진 순서 값을 가진 관계 앞에 관계를 삽입한다. 새로운 관계는 OrdPrev와 ord 사이(이들 값은 포함하지 않음)의 순서 값이 할당될 수 있다.
- InsertAfter(SourceItemID, ord, Relationship)는 주어진 순서 값을 가진 관계 뒤에 관계를 삽입한다. 새로운 관계는 ord와 OrdNext 사이(이들 값은 포함되지 않음)의 순서 값이 할당될 수 있다.
- MoveBefore(SourceItemID, ord, Relationship)는 주어진 관계 ID를 가진 관계를 지정된 순서 값을 가진 관계 앞으로 이동시킨다. 관계는 OrdPrev와 ord 사이(이들 값은 포함되지 않음)의 새로운 순서 값이 할당될 수 있다.
- MoveAfter(SourceItemID, ord, Relationship)는 주어진 관계 ID를 가진 관계를 지정된 순서 값을 가진 관계 뒤로 이동시킨다. 관계는 ord와 OrdNext 사이(이들 값은 포함되지 않음)의 새로운 순서 값이 할당될 수 있다.
전술한 바와 같이, 모든 항목은 항목 폴더의 회원이어야 한다. 관계에 의하 여, 모든 항목은 항목 폴더와의 관계를 가져야 한다. 본 발명의 여러 실시예에서, 소정의 관계들은 항목들 사이에 존재하는 관계에 의해 표현된다.
본 발명의 다양한 실시예에서 구현되는 바와 같이, 관계는 하나의 항목(소스)에 의해 다른 항목(타겟)으로 확장되는 방향성 바이너리 관계를 제공한다. 관계는 소스 항목(관계를 확장한 항목)에 의해 소유되며, 따라서 소스가 제거되는 경우에는 관계가 제거된다(예컨대, 관계는 소스 항목이 삭제될 때 삭제된다). 더욱이, 소정의 예에서, 관계는 타겟 항목의 소유를 공유(공동 소유)할 수 있으며, 이러한 소유는 (관계 속성 타입에 대해 도 7에 도시된 바와 같이) 관계의 IsOwned 속성(또는 그의 등가물) 내에 반영될 수 있다. 이들 실시예에서, 새로운 IsOwned 관계의 생성은 타겟 항목에 대한 참조 수를 자동으로 증가시키며, 이러한 관계의 삭제는 타겟 항목에 대한 참조 수를 감소시킬 수 있다. 이러한 특정 실시예에서, 항목들은 이들이 0보다 큰 참조 수를 갖는 경우 계속 존재하며, 참조 수가 0이 되는 경우 자동으로 삭제된다. 또한, 항목 폴더는 다른 항목들에 대해 한 세트의 관계를 갖는(또는 가질 수 있는) 항목인데, 이들 다른 항목들은 항목 폴더의 회원을 포함한다. 다른 실제적인 관계의 구현도 가능하며, 여기서 설명되는 기능을 달성하도록 본 발명에 의해 예측된다.
실제 구현과 관계없이, 관계는 하나의 객체에서 다른 객체로의 선택 가능한 연결이다. 하나의 항목이 둘 이상의 항목 폴더는 물론, 하나 이상의 카테고리에 속할 수 있는 능력, 및 이들 항목, 폴더 및 카테고리가 공개적인지 사적인지의 여부는 항목 기반 구조에서의 존재(또는 부재)에 대해 주어지는 의미에 의해 결정된 다. 이러한 논리 관계는 물리적 구현에 관계없이 본 명세서에서 설명되는 기능을 달성하기 위해 구체적으로 사용되는 한 세트의 관계에 할당되는 의미들이다. 논리 관계는 항목과 그의 항목 폴더(들) 또는 카테고리들(및 그 역) 사이에 설정되는데, 이는 본질적으로 항목 폴더 및 카테고리가 각각 항목의 특수한 타입이기 때문이다. 결과적으로, 항목 폴더 및 카테고리는 복사되고, 이메일 메시지에 추가되고, 문서에 삽입되는 등등 제한 없이, 임의의 다른 항목과 동일한 방식으로 동작될 수 있으며, 항목 폴더 및 카테고리는 다른 항목에 대한 것과 동일한 메카니즘을 이용하여 직렬화 및 역직렬화(가져오기 및 가져가기)될 수 있다. (예를 들어, XML에서 모든 항목은 직렬화 포맷을 가질 수 있으며, 이러한 포맷은 항목 폴더, 카테고리 및 항목에 동일하게 적용된다.)
항목과 그의 항목 폴더 사이의 관계를 나타내는 전술한 관계는 논리적으로 항목에서 항목 폴더로, 항목 폴더에서 항목으로, 또는 양쪽으로 확장될 수 있다. 항목에서 항목 폴더로 확장되는 관계는 항목 폴더가 항목에 대해 공개적이며 항목과 그의 회원 정보를 공유한다는 것을 나타내지만, 역으로 항목에서 항목 폴더로의 논리 관계의 결여는 항목 폴더가 항목에 대해 사적이며, 항목과 그의 회원 정보를 공유하지 않는다는 것을 나타낸다. 유사하게, 항목 폴더에서 항목으로 논리적으로 확장되는 관계는 항목이 공개적이며 항목 폴더와 공유될 수 있다는 것을 나타내는 반면, 항목 폴더에서 항목으로의 논리 관계의 결여는 항목이 사적이고, 공유될 수 없다는 것을 나타낸다. 결과적으로, 항목 폴더가 다른 시스템에 노출될 때, 이것은 이 새로운 상황에서 공유되는 "공개" 항목이며, 항목이 그의 항목 폴더에서 다 른 공유 가능한 항목들을 검색할 때, 이것은 항목에 이에 속하는 공유 가능한 항목들에 관한 정보를 제공하는 "공개" 항목 폴더들이다.
도 9는 항목 폴더(이것은 또한 항목 그 자체이다), 그의 회원 항목들, 및 항목 폴더와 그의 회원 항목들 사이의 상호 연결 관계를 나타내는 블록도이다. 항목 폴더(900)는 다수의 항목(902, 904, 906)을 갖는다. 항목 폴더(900)는 그 자신으로부터 항목(902)으로의 관계(912)를 갖는데, 이 관계는 항목(902)이 공개적이며 항목 폴더(900), 그의 회원들(904, 906), 및 항목 폴더(900)에 액세스할 수 있는 임의의 다른 항목 폴더들, 카테고리들, 또는 항목들(도시되지 않음)과 공유될 수 있다는 것을 나타낸다. 그러나, 항목 폴더(900)가 항목(902)에 대해 사적이며, 항목(902)과 그의 회원 정보를 공유하지 않는다는 것을 나타내는 항목(902)에서 항목 폴더(900)로의 관계는 존재하지 않는다. 한편, 항목(904)은, 항목 폴더(900)가 공개적이며 항목(904)과 그의 회원 정보를 공유한다는 것을 나타내는 그 자신에서 항목 폴더(900)로의 관계를 갖지 않는다. 그러나, 항목(904)이 사적이며 항목 폴더(900), 그의 다른 회원들(902, 906), 및 항목 폴더(900에 액세스할 수 있는 항목 폴더, 카테고리 또는 항목(도시되지 않음)과 공유되지 않음을 나타내는 항목 폴더(900)에서 항목(904)으로의 관계가 존재하지 않는다. 항목 폴더의 항목들(902, 904)에 대한 관계(또는 관계의 결여)와 달리, 항목 폴더(900)는 그 자신에서 항목(906)으로의 관계(916)를 가지며, 항목(906)은 역으로 항목 폴더(900)로의 관계(926)을 갖는데, 이들 관계는 함께 항목(906)이 공개적이며 항목 폴더(900), 그의 회원들(902, 904), 및 항목 폴더(900)에 액세스할 수 있는 임의의 다른 항목 폴더, 카테고리 또는 항목(도시되지 않음)과 공유될 수 있고, 항목 폴더(900)가 공개적이고 항목(906)과 그의 회원 정보를 공유한다는 것은 나타낸다.
전술한 바와 같이, 항목 폴더 내의 항목들은 공유성을 공유할 필요는 없는데, 이는 항목 폴더가 "기술"되지 않기 때문이다. 한편, 카테고리는 그의 회원 항목들 모두에 공통인 공통성에 의해 기술된다. 결과적으로, 카테고리의 회원은 기술된 공통성을 가진 항목들로 고유하게 제한되며, 소정 실시예에서 카테고리의 기술을 만족시키는 모든 항목은 자동으로 카테고리의 회원이 된다. 따라서, 항목 폴더는 평범한 타입의 구조들이 그들의 회원에 의해 표현되는 것을 허용하는 반면, 카테고리는 정의된 공통성에 기초하여 회원을 허용한다.
물론, 카테고리 기술은 사실상 논리적이며, 따라서 카테고리는 타입들, 속성들 및/또는 값들의 임의의 논리적 표현에 의해 기술될 수 있다. 예컨대, 카테고리의 논리적 표현은 2개의 속성 중 하나 또는 양자를 갖는 항목들을 포함하는 그의 회원일 수 있다. 카테고리에 대해 기술된 이러한 속성들이 "A" 및 "B"인 경우, 카테고리 회원은 속성 A를 가지나 B는 갖지 않는 항목들, 속성 A는 갖지 않고 B를 갖는 항목들, 및 속성 A 및 B를 모두 갖는 항목들을 포함할 수 있다. 이러한 속성들의 논리적 표현은 논리 연산자 "OR"에 의해 기술되는데, 카테고리에 의해 기술되는 회원들의 세트는 속성 A OR B를 가진 항목들이다. 유사한 논리 연산자(제한 없이 "AND", "XOR" 및 "NOT"를 단독으로 또는 조합으로 포함)도 당업자가 이해하듯이 카테고리를 기술하는 데 사용될 수 있다.
항목 폴더(기술되지 않음)와 카테고리(기술됨) 사이의 차이에도 불구하고, 항목에 대한 카테고리의 관계 및 카테고리에 대한 항목의 관계는 본질적으로 본 발명의 많은 실시예에서 항목 폴더 및 항목에 대해 위에 개시한 것과 동일한 방식을 갖는다.
도 10은 카테고리(항목 자체), 그의 회원 항목들, 및 카테고리와 그의 회원 항목들 사이의 상호 연결 관계를 나타내는 블록도이다. 카테고리(1000)는 다수의 항목(1002, 1004, 1006)을 회원으로서 갖는데, 이들 모두는 카테고리(1000)에 의해 기술되는 바와 같이 공통 속성들, 값들 또는 타입들(1008)의 소정의 조합을 공유한다. 카테고리(1000)는 그 자체에서 항목(1002)으로의 관계(1012)를 갖는데, 이 관계는 항목(1002)이 공개적이며, 카테고리(1000), 그의 회원들(1004, 1006), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 있다는 것을 나타낸다. 그러나, 카테고리(1000)가 항목(1002)에 대해 사적이며, 항목(1002)과 그의 회원 정보를 공유하지 않는다는 것을 나타내는, 항목(1002)에서 카테고리(1000)로의 관계는 존재하지 않는다. 한편, 항목(1004)은 카테고리(1000)가 공개적이며, 항목(1004)과 그의 회원 정보를 공유한다는 것을 나타내는, 그 자체에서 카테고리(1000)로의 관계(1024)를 갖지 않는다. 그러나, 항목(1004)이 사적이며, 카테고리(1000), 그의 다른 회원들(1002, 1006), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 없다는 것은 나타내는 카테고리(1000)에서 항목(1004)으로 확장되는 관계가 존재하지 않는다. 카테고리의 항목(1002, 1004)과의 관계(또는 그의 결여)와 달리, 카테고리(1000)는 그 자체에서 항목(1006)으로의 관 계를 가지며, 항목(1006)은 역으로 카테고리(1000)로의 관계를 갖는데, 이들 관계는 함께 항목(1006)이 공개적이며 카테고리(1000), 그의 항목 회원들(1002, 1004), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 있다는 것과, 카테고리(1000)가 공개적이며, 항목(1006)과 그의 회원 정보를 공유한다는 것을 나타낸다.
마지막으로, 카테고리 및 항목 폴더들 자체는 항목이기 때문에, 소정의 다른 실시예에서 항목들은 서로에 대한 관계를 가질 수 있고, 카테고리는 항목 폴더에 대한 관계를, 항목 폴더는 카테고리에 대한 관계를 가질 수 있으며, 카테고리, 항목 폴더 및 항목은 다른 카테고리, 항목 폴더 및 항목에 대한 관계를 가질 수 있다. 그러나, 다양한 실시예에서, 항목 폴더 구조 및/또는 카테고리 구조는 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 순환을 포함하는 것이 금지된다. 항목 폴더 및 카테고리 구조가 방향 그래프와 유사한 경우, 순환을 금지하는 실시예들은 그래프 이론 분야의 수학적 정의에 의해 동일한 정점에서 어떠한 경로도 시작하거나 끝나지 않는 방향 그래프인 방향 비순환 그래프(DAG)와 유사하다.
6. 확장성
저장 플랫폼은 전술한 바와 같이 초기 스키마 세트(340)를 구비한다. 또한, 그러나 적어도 일부 실시예에서 저장 플랫폼은 개별 소프트웨어 벤더(ISV)를 포함하는 고객들이 새로운 스키마(344)(즉, 새로운 항목 및 중첩 요소 타입)를 생성하는 것을 허용한다. 이 섹션은 초기 스키마 세트(340)에 정의된 항목 타입 및 중첩 요소 타입(또는 단순히 요소 타입)을 확장함으로써 이러한 스키마를 생성하는 메카니즘을 다룬다.
바람직하게도, 초기의 항목 및 중첩 요소 타입 세트는 다음과 같이 제한된다.
- ISV는 새로운 항목 타입, 즉 서브 타입인 Base.Item을 도입하는 것이 허용된다.
- ISV는 새로운 중첩 요소 타입, 즉 서브 타입인 Base.NestedElement를 도입하는 것이 허용된다.
- ISV는 새로운 확장, 즉 서브 타입인 Base.NestedElement를 도입하는 것이 허용된다.
- 그러나, ISV는 저장 플랫폼 스키마의 초기 세트(340)에 의해 정의된 임의의 타입(항목, 중첩 요소 또는 확장 타입)을 서브 타입화할 수 없다.
저장 플랫폼 스키마의 초기 세트에 정의된 항목 타입 또는 중첩 요소 타입은 ISV 애플리케이션의 요구에 정확하게 부응하지 않을 수 있기 때문에, ISV가 타입을 주문화하는 것을 허용할 필요가 있다. 이것은 확장의 개념으로 허용된다. 확장은 강력하게 타입화된 확장이지만, (a) 이것은 독립적으로 존재할 수 없고, (b) 항목 또는 중첩 요소에 첨부되어야 한다.
스키마 확장성의 필요성을 다루는 것 외에, 확장은 또한 "멀티 타입화" 문제를 다룬다. 소정의 실시예에서, 저장 플랫폼은 다수의 상속 또는 중첩 서브 타입을 지원하지 않을 수 있기 때문에, 애플리케이션은 확장을 중첩 타입 인스턴스를 모델링하기 위한 방법으로서 이용할 수 있다(예컨대, 문서는 합법 문서는 물론 보안 문서이다).
a) 항목 확장
항목 확장성을 제공하기 위하여, 데이터 모델은 또한 Base.Extension이라는 명칭의 추상 타입을 정의한다. 이것은 확장 타입의 계층 구조에 대한 루트 타입이다. 애플리케이션은 특정 확장 타입을 생성하기 위해 Base.Extension을 서브 타입화할 수 있다.
Base.Extension 타입은 다음과 같이 Base.Extension 내에 정의된다.
Figure 112005035516470-PCT00006
ItemID 필드는 확장이 연관되어 있는 항목의 ItemID를 포함한다. 이 ItemID를 가진 항목이 존재해야 한다. 확장은 소정의 ItemID를 가진 항목이 존재하지 않는 경우 생성될 수 없다. 항목이 삭제되면, 동일한 ItemID를 가진 모든 확장이 삭제된다. 튜플(ItemID, ExtensionID)은 확장 인스턴스를 고유하게 식별한다.
확장 타입의 구조는 항목 타입의 구조와 유사하다.
- 확장 타입은 필드를 갖는다.
- 필드는 기본 또는 중첩 요소 타입일 수 있다.
- 확장 타입은 서브 타입화될 수 있다.
다른 제한은 확장 타입에 적용된다.
- 확장은 관계의 소스 및 타겟일 수 없다.
- 확장 타입 인스턴스는 항목과 별개로 존재할 수 없다.
- 확장 타입은 저장 플랫폼 타입 정의에서 필드 타입으로 사용될 수 없다.
주어진 항목 타입과 관련될 수 있는 확장의 타입에는 제한이 없다. 어떠한 확장 타입도 임의의 항목 타입을 확장하는 것이 허용된다. 다수의 확장 인스턴스가 항목에 첨부될 때, 이들은 구조 및 거동 양자에서 서로 독립적이다.
확장 인스턴스는 저장되어 항목으로부터 개별적으로 액세스된다. 모든 확장 타입 인스턴스는 글로벌 확장 뷰로부터 액세스될 수 있다. 어떤 타입의 항목과 연관되어 있는지에 관계없이 소정 확장 타입의 모든 인스턴스를 리턴하는 효율적인 질의가 구축될 수 있다. 저장 플랫폼 API는 항목에 대한 확장을 저장, 검색 및 수정할 수 있는 프로그래밍 모델을 제공한다.
확장 타입은 저장 플랫폼 단일 상속 모델을 이용하여 서브 타입화된 타입일 수 있다. 확장 타입으로부터의 도출은 새로운 확장 타입을 생성한다. 확장의 구조 또는 거동은 항목 타입 계층 구조의 구조 또는 거동을 무시하거나 대체할 수 없다. 항목 타입과 유사하게, 확장 타입 인스턴스는 확장 타입과 관련된 뷰를 통해 직접 액세스될 수 있다. 확장의 ItemID는 이들이 어느 항목에 속하는지를 나타내며, 글로벌 항목 뷰로부터 대응하는 항목 객체를 검색하는 데 사용될 수 있다. 확 장은 동작의 일관성을 위해 항목의 일부로 간주된다. 저장 플랫폼이 정의하는 복사/이동, 백업/복원 및 다른 일반 동작들은 항목의 일부로서 확장에 대해 동작할 수 있다.
다음 예를 고려하자. 윈도우 타입 세트 내에 콘택 타입이 정의된다.
Figure 112005035516470-PCT00007
CRM 애플리케이션 개발자는 저장 플랫폼에 저장된 콘택에 CRM 애플리케이션 확장을 첨부하기를 원한다. 애플리케이션 개발자는 애플리케이션이 조작할 수 있는 추가적인 데이터 구조를 포함하는 CRM 확장을 정의한다.
Figure 112005035516470-PCT00008
Figure 112005035516470-PCT00009
HR 애플리케이션 개발자는 또한 콘택에 추가 데이터를 첨부하기를 원할 수 있다. 이 데이터는 CRM 애플리케이션 데이터와 무관하다. 또한, 애플리케이션 개발자는 확장을 생성할 수 있다.
Figure 112005035516470-PCT00010
CRMExtension 및 HRExtension은 콘택 항목에 첨부될 수 있는 2개의 독립적인 확장이다. 이들은 서로 독립적으로 생성되고 액세스된다.
위의 예에서, CRMExtension 타입의 필드 및 메소드는 콘택 계층 구조의 필드 또는 메소드를 무시할 수 없다. CRMExtension 타입의 인스턴스는 콘택이 아니라 항목 타입에 첨부될 수 있다는 점에 유의해야 한다.
콘택이 검색될 때, 그의 항목 확장이 자동으로 검색되는 것은 아니다. 콘택 항목이 주어지면, 그와 관련된 항목 확장은 동일한 ItemID를 가진 확장에 대한 글로벌 확장 뷰에 질의함으로써 액세스될 수 있다.
시스템 내의 모든 CRMExtension 확장들은 이들이 어느 항목에 속하는지에 관계없이 CRMExtension 타입 뷰를 통해 액세스될 수 있다. 항목의 모든 항목 확장은 동일한 항목 ID를 공유한다. 위 예에서, 콘택 항목 인스턴스 및 첨부된 CRMExtension 및 HRExtension 인스턴스는 동일한 ItemID를 공유한다.
다음 테이블은 항목, 확장 및 중첩 요소 타입 사이의 유사성 및 차이를 요약한 것이다.
항목 대 항목 확장 대 중첩 요소
항목 항목 확장 중첩 요소
항목 ID 그 자신의 항목 ID를 갖는다. 항목의 항목 ID를 공유한다. 그 자신의 항목 ID를 갖지 않는다. 중첩 요소는 항목의 일부이다.
저장 항목 계층 구조는 그 자신의 테이블에 저장된다. 항목 확장 계층 구조는 그 자신의 테이블에 저장된다. 항목과 함께 저장된다.
질의/검색 항목 테이블에 질의할 수 있다. 항목 확장 테이블에 질의할 수 있다. 일반적으로 포함하는 항목 컨텍스트 내에서만 질의될 수 있다.
질의/검색 범위 항목 타입의 모든 인스턴스를 검색할 수 있다. 항목 확장 타입의 모든 인스턴스를 검색할 수 있다. 일반적으로 단일 (포함) 항목의 중첩 요소 타입 인스턴스 내에서만 검색할 수 있다.
관계 시맨틱 항목들에 대한 관계를 가질 수 있다. 항목 확장에 대한 관계 없음. 중첩 요소에 대한 관계 없음
항목에 대한 연관성 유지, 삽입 및 소프트 관계를 통해 다른 항목과 관련될 수 있다. 일반적으로 확장을 통해서만 관련될 수 있다. 확장 시맨틱은 삽입된 항목 시맨틱과 유사하다. 필드를 통해 항목과 관련됨, 중첩 요소는 항목의 일부이다.
b) 중첩 요소 확장
중첩 요소 타입은 항목 타입과 동일한 메카니즘으로 확장되지 않는다. 중첩 요소의 확장은 중첩 요소 타입의 필드와 동일한 메카니즘으로 저장되고 액세스된다.
데이터 모델은 Element라는 명칭의 중첩 요소 타입의 루트를 정의한다.
Figure 112005035516470-PCT00011
중첩 요소 타입은 이 타입으로부터 상속된다. NestElement 요소 타입은 요소들의 멀티 세트인 필드를 추가적으로 정의한다.
Figure 112005035516470-PCT00012
중첩 요소 확장은 다음의 방식에서 항목 확장과 다르다.
- 중첩 요소 확장은 확장 타입이 아니다. 이것은 Base.Extension 타입에서 루트가 되는 확장 타입 계층 구조에 속하지 않는다.
- 중첩 요소 확장은 항목의 다른 필드들과 함께 저장되며, 글로벌 액세스가 가능하지 않으며, 주어진 확장 타입의 모든 인스턴스를 검색하는 질의가 구축될 수 없다.
- 이들 확장은 (항목의) 다른 중첩 요소들이 저장되는 것과 동일한 방식으로 저장된다. 다른 중첩 세트와 같이, 중첩 요소 확장은 UDT에 저장된다. 이들은 중첩 요소 타입의 확장 필드를 통해 액세스될 수 있다.
- 다가 속성들에 액세스하는 데 사용되는 집합 인터페이스도 타입 확장 세트에 대한 액세스 및 반복을 위해 사용된다.
다음 테이블은 항목 확장 및 중첩 요소 확장을 요약하고 비교한 것이다.
항목 확장 대 중첩 요소 확장
항목 확장 중첩 요소 확장
저장 항목 확장 계층 구조가 그 자신의 테이블에 저장된다. 중첩 요소와 같이 저장된다.
질의/검색 항목 확장 테이블에 질의할 수 있다. 일반적으로 포함 항목 컨텍스트 내에서만 질의될 수 있다.
질의/검색 범위 항목 확장 타입의 모든 인스턴스를 검색할 수 있다. 일반적으로 단일 (포함) 항목의 중첩 요소 타입 인스턴스 내에서만 검색할 수 있다.
프로그래밍 가능성 특수 확장 API 및 확장 테이블에 대한 특수 질의가 필요하다. 중첩 요소 확장은 중첩 요소의 임의의 다른 다가 필드와 유사하며, 정상 중첩 요소 타입 API가 사용된다.
거동 거동을 연관시킬 수 있다. 거동이 허용되지 않음(?)
관계 시맨틱 항목 확장에 대한 관계 없음 중첩 요소 확장에 대한 관계 없음
항목 ID 항목의 항목 ID를 공유한다. 그 자신의 항목 ID를 갖지 않는다. 중첩 요소 확장은 항목의 일부이다.
D. 데이터베이스 엔진
전술한 바와 같이, 데이터 저장소는 데이터베이스 엔진 상에서 구현된다. 본 실시예에서, 데이터베이스 엔진은 객체 관계 확장으로 마이크로소프트 SQL 서버 엔진과 같은 SQL 질의 언어를 구현하는 관계형 데이터베이스 엔진을 포함한다. 이 섹션은 본 실시예에 따라 데이터 저장소를 구현하는 데이터 모델의 관계 저장소에 대한 맵핑을 설명하며, 저장 플랫폼 클라이언트에 의해 소비되는 논리 API에 대한 정보를 제공한다. 그러나, 상이한 데이터베이스 엔진이 사용될 때 상이한 맵핑이 사용될수 있다는 것을 이해해야 한다. 실제로, 관계형 데이터베이스 엔진 상에서 저장 플랫폼 개념 데이터 모델을 구현하는 것 외에, 예를 들어 객체 지향 및 XML 데이터베이스와 같은 다른 타입의 데이터베이스 상에서도 구현될 수 있다.
객체 지향(OO) 데이터베이스 시스템은 프로그래밍 언어 객체(예컨대, C++, 자바)에 대한 지속성 및 트랜잭션을 제공한다. "항목"의 저장 플랫폼 개념은 삽입된 집합들이 객체에 추가되어야 하지만 객체 지향 시스템에서 "객체"로 양호하게 맵핑된다. 상속 및 중첩 요소 타입과 같은 다른 저장 플랫폼 타입 개념들도 객체 지향 타입 시스템에 맵핑된다. 객체 지향 시스템은 일반적으로 객체 식별자를 이미 지원하며, 따라서 항목 식별자는 객체 식별자로 맵핑될 수 있다. 항목 거동(동작)은 객체 메소드로 양호하게 맵핑된다. 그러나, 객체 지향 시스템은 일반적으로 체계적인 능력이 부족하며, 검색이 열악하다. 또한, 객체 지향 시스템은 비구조적 및 반구조적 데이터에 대한 지원을 제공하지 않는다. 여기에 설명되는 완전한 저장 플랫폼 데이터 모델을 지원하기 위하여, 관계, 폴더 및 확장과 같은 개념들이 객체 데이터 모델에 추가될 필요가 있다. 또한, 승진, 동기화, 통지 및 보안과 같은 메카니즘이 구현될 필요가 있다.
객체 지향 시스템과 유사하게, XSD(XML 스키마 정의)에 기초하는 XML 데이터베이스는 단일 상속 기반 타입 시스템을 지원한다. 본 발명의 항목 타입 시스템은 XSD 타입 모델로 맵핑될 수 있다. XSD는 또한 거동에 대한 지원을 제공하지 않는다. 항목에 대한 XSD는 항목 거동에 대해 보강되어야 한다. XML 데이터베이스는 단일 XSD 문서를 처리하며, 체계화 및 광범위한 검색 능력이 부족하다. 객체 지향 데이터베이스에서와 같이, 여기서 설명되는 데이터 모델을 지원하기 위하여, 관계 및 폴더와 같은 다른 개념들이 이러한 XML 데이터베이스에 포함될 필요가 있으며, 또한 동기화, 통지 및 보안과 같은 메카니즘이 구현될 필요가 있다.
다음의 서브 섹션과 관련하여, 개시된 일반 정보를 쉽게 하는 몇몇 설명이 제공되는데, 도 13은 통지 메카니즘을 설명하는 도면이다. 도 14는 2개의 트랜잭션 양자가 동일한 B 트리에 새로운 레코드를 삽입하는 예를 나타내는 도면이다. 도 15는 데이터 변경 검출 프로세스를 나타낸다. 도 16은 예시적인 디렉토리 트리를 나타낸다. 도 17은 디렉토리 기반 파일 시스템의 기존 폴더가 저장 플랫폼 데이터 저장소로 이동되는 예를 나타낸다.
1. UDT를 이용한 데이터 저장소 구현
본 실시예에서, 일 실시예에서 마이크로소프트 SQL 서버 엔진을 포함하는 관계형 데이터베이스 엔진(314)은 내장 스칼라 타입을 지원한다. 내장 스칼라 타입은 "원시적"이고 "단순"하다. 이것은 사용자가 그 자신의 타입을 정의할 수 없다는 의미에서 원시적이며, 복합 구조를 캡슐화할 수 없다는 의미에서 단순하다. 사용자 정의 타입(이하, UDT)은 사용자가 복잡하고 구조화된 타입을 정의함으로써 타입 시스템을 확장하는 것을 가능하게 함으로써 원시 스칼라 타입 시스템 위에 그리고 이를 넘어서 타입 확장성을 위한 메카니즘을 제공한다. UDT가 사용자에 의해 정의되면, 이 UDT는 내장 스칼라 타입이 사용될 수 있는 타입 시스템 내의 어디에서나 사용될 수 있다.
본 발명의 일 양태에 따르면, 저장 플랫폼 스키마는 데이터베이스 엔진 저장소 내의 UDT 클래스로 맵핑된다. 데이터 저장소 항목들은 Base.Item 타입으로부터 도출되는 UDT 클래스로 맵핑된다. 항목과 같이, 확장도 UDT 클래스로 맵핑되며, 상속을 이용한다. 루트 확장 타입은 모든 확장 타입이 도출되는 Base.Extension이 다.
UDT는 CLR 클래스이며, 이는 상태(즉, 데이터 필드) 및 거동(즉, 루틴)을 갖는다. UDT는 관리형 언어들, 즉 C#, VB.NET 등 중 어느 하나를 이용하여 정의된다. UDT 메소드 및 연산자는 그 타입의 인스턴스에 대해 T-SQL에서 호출될 수 있다. UDT는 행 내의 열의 타입, T-SQL 내의 루틴의 파라미터의 타입 또는 T-SQL 내의 변수의 타입일 수 있다.
저장 플랫폼 스키마의 UDT 클래스로의 맵핑은 고레벨에서 매우 간단하다. 일반적으로, 저장 플랫폼 스키마는 CLR 명칭 공간으로 맵핑된다. 저장 플랫폼 타입은 CLR 클래스로 맵핑된다. CLR 클래스 상속은 저장 플랫폼 타입 상속을 미러링하며, 저장 플랫폼 속성은 CLR 클래스 속성으로 맵핑된다.
2. 항목 맵핑
항목들이 바람직하게 글로벌 검색 가능하고, 본 실시예의 관계형 데이터베이스에서 상속 및 타입 대체성이 지원되는 경우, 데이터베이스 저장소 내의 항목 저장을 위하여 가능한 하나의 구현은 타입 Base.Item의 열을 가진 단일 테이블에 모든 항목을 저장하는 것이다. 타입 대체성을 이용하면, 모든 타입의 항목들이 저장될 수 있으며, 검색은 유콘(Yukon)의 "is of(타입)" 연산자를 이용하여 항목 타입 및 서브 타입에 의해 필터링될 수 있다.
그러나, 이러한 접근법과 관련된 오버헤드에 대한 염려로 인해, 본 실시예에서는 항목들이 최상위 레벨 타입에 의해 분류되며, 따라서 각 타입 "패밀리"의 항 목들은 개별 테이블에 저장된다. 이러한 분할 스킴 하에서는 Base.Item으로부터 직접 상속되는 각각의 항목 타입에 대해 테이블이 생성된다. 이들 아래에서 상속되는 타입들은 전술한 바와 같이 타입 대체성을 이용하여 적절한 타입 패밀리에 저장된다. Base.Item으로부터의 제1 레벨의 상속만이 특수하게 처리된다.
모든 항목에 대한 글로벌 검색 가능 속성들의 레플리커를 저장하기 위하여 "쉐도우" 테이블이 사용된다. 이 테이블은 모든 데이터 변경을 행하는 저장 플랫폼 API의 Update() 메소드에 의해 유지될 수 있다. 타입 패밀리 테이블과 달리, 이 글로벌 항목 테이블은 완전한 UDT 항목 객체가 아니라 항목의 최상위 레벨 스칼라 속성만을 포함한다. 글로벌 항목 테이블은 ItemID 및 TypeID를 노출시킴으로써 타입 패밀리 테이블에 저장된 항목 객체에 대한 네비게이션을 허용한다. ItemID는 일반적으로 데이터 저장소 내의 항목을 고유하게 식별한다. TypeID는 여기서 설명되지 않는 메타데이터를 이용하여 타입 명칭 및 항목을 포함하는 뷰로 맵핑될 수 있다. 글로벌 항목 테이블과 관련하여, 그리고 다른 상황과 관련하여, 항목을 그의 ItemID에 의해 찾는 것은 일반적인 동작일 수 있으므로, 항목의 ItemID가 주어지면 항목 객체를 검색하기 위한 GetItem() 함수가 제공된다.
편리한 액세스를 위해, 그리고 구현 상세를 가능한 한도까지 숨기기 위해, 항목에 대한 모든 질의는 전술한 항목 테이블 상에 구축된 뷰들에 대한 것일 수 있다. 구체적으로, 적절한 타입 패밀리 테이블에 대해 각각의 항목 타입에 대한 뷰들이 생성될 수 있다. 이러한 타입 뷰는 서브 타입을 포함하는 관련 타입의 모든 항목을 선택할 수 있다. 편의를 위해, UDT 객체 외에, 뷰들은 상속된 필드를 포함 하는 그 타입의 모든 최상위 레벨 필드에 대한 열들을 노출시킬 수 있다.
3. 확장 맵핑
확장은 항목과 매우 유사하며, 동일한 요건들의 일부를 갖는다. 상속을 지원하는 다른 루트 타입으로서, 확장은 저장에 있어서의 동일한 고려 및 트레이드오프 중 많은 부분에 종속된다. 이 때문에, 유사한 타입 패밀리 맵핑이 단일 테이블 접근법이 아니라 확장에 적용된다. 물론, 다른 실시예에서는 단일 테이블 접근법이 이용될 수 있다. 본 실시예에서, 확장은 ItemID에 의해 정확히 하나의 항목과 연관되며, 항목과 관련하여 고유한 ExtensionID를 포함한다. 항목에서와 같이, ItemID 및 ExtensionID 쌍으로 이루어진 확장 식별자가 주어질 때 확장을 검색하기 위한 함수가 제공될 수 있다. 항목 타입 뷰와 유사하게 각각의 확장 타입에 대한 뷰가 생성된다.
4. 중첩 요소 맵핑
중첩 요소들은 항목, 확장, 관계, 또는 깊게 중첩된 구조를 형성하는 다른 중첩 요소들 내에 삽입될 수 있는 타입이다. 항목 및 확장과 같이, 중첩 요소는 UDT로서 구현되지만, 항목 및 확장 내에 저장된다. 따라서, 중첩 요소들은 그들의 항목 및 확장 컨테이너의 맵핑을 넘어서는 어떠한 저장 맵핑도 갖지 않는다. 즉, 시스템 내에는 중첩 요소 타입의 인스턴스를 직접 저장하는 테이블이 존재하지 않으며, 중첩 요소에 특정하게 전용화된 어떠한 뷰도 존재하지 않는다.
5. 객체 식별
데이터 모델 내의 각 엔티티, 즉 항목, 확장 및 관계는 고유 키 값을 갖는다. 항목은 그의 ItemID에 의해 고유하게 식별된다. 확장은 (ItemID, ExtensionID)의 합성 키에 의해 고유하게 식별된다. 관계는 합성 키(ItemID, RelationID)에 의해 식별된다. ItemID, ExtensionID 및 RelationID는 GUID 값이다.
6. SQL 객체 명명
데이터 저장소에서 생성된 모든 객체는 저장 플랫폼 스키마 명칭으로부터 도출된 SQL 스키마 명칭에 저장될 수 있다. 예컨대, 저장 플랫폼 기본 스키마(종종 "Base"라고 함)는 "[System.Storage]" SQL 스키마 내에 "[System.Storage].Item"과 같은 타입을 생성할 수 있다. 생성된 명칭 앞에는 명명 충돌을 없애기 위하여 한정사가 붙는다. 적절한 경우, 명칭의 각각의 논리 부분에 대한 분리자로서 느낌표(!)가 사용된다. 아래의 테이블은 데이터 저장소 내의 객체들에 대해 사용되는 명명 규약의 개요를 나타낸다. 각각의 스키마 요소(항목, 확장, 관계 및 뷰)는 데이터 저장소 내의 인스턴스에 액세스하는 데 사용되는 장식 명명 규약과 함께 리스트되어 있다.
객체 명칭 장식 설명 예
마스터 항목 검색 뷰 Master!Item 현재 항목 도메인 내의 항목들의 요약을 제공한다. [System.Storage]. [Master!Item]
타입화된 항목 검색 뷰 ItemType 항목 및 임의의 부모 타입(들)으로부터의 모든 속성 데이터를 제공한다. [AcmeCorp.Doc]. [OfficeDoc]
마스터 확장 검색 뷰 Master!Extension 현재 항목 도메인 내의 모든 확장의 요약을 제공한다. [System.Storage]. [Master!Extension]
타입화된 확장 검색 뷰 Extension!extensionType 확장에 대한 모든 속성 데이터를 제공한다. [AcmeCorp.Doc]. [Extension!StickyNote]
마스터 관계 뷰 Master!Relationship 현재 항목 도메인 내의 모든 관계의 요약을 제공한다 [System.Storage]. [Master!Relationship]
관계 뷰 Relation!relationshipName 주어진 관계와 관련된 모든 데이터를 제공한다. [AcmeCorp.Doc]. [Relationship!AuthorsFro mDocument]
뷰 View!viewName 스키마 뷰 정의에 기초하여 열/타입을 제공한다. [AcmeCorp.Doc]. [View!DocumentTitles]
7. 열 명명
임의의 객체 모델을 저장소로 맵핑할 때, 명명 충돌의 가능성은 애플리케이션 객체와 함께 저장된 추가 정보로 인해 발생한다. 명명 충돌을 방지하기 위해, 모든 논-타입 특정 열(타입 선언 내의 명명 속성으로 직접 맵핑되지 않는 열들) 앞에는 밑줄(_) 문자가 붙여진다. 본 실시예에서, 밑줄(_) 문자는 임의의 식별자 속성의 시작 문자로서 허용되지 않는다. 또한, CLR과 데이터 저장소 사이의 명명을 통일하기 위하여 저장 플랫폼 타입 또는 스키마 요소(관계 등)의 모든 속성은 대문자화된 제1 문자를 가져야 한다.
8. 검색 뷰
뷰는 저장된 콘텐츠를 검색하기 위해 저장 플랫폼에 의해 제공된다. SQL 뷰가 각각의 항목 및 확장 타입에 대해 제공된다. 또한, 관계 및 뷰를 지원하기 위해(데이터 모델에 정의된 바와 같이) 뷰들이 제공된다. 저장 플랫폼 내의 모든 SQL 뷰 및 기본 테이블은 판독 전용이다. 후술하는 바와 같이, 데이터는 저장 플랫폼 API의 Update() 메소드를 이용하여 저장 또는 변경될 수 있다.
저장 플랫폼 스키마 내에 명시적으로 정의된(저장 플랫폼에 의해 자동 생성된 것이 아니라 스키마 설계자에 의해 정의된) 각각의 뷰는 명명된 SQL 뷰 [<schema-name>].[View!<view-name>]에 의해 액세스될 수 있다. 예를 들어, 스키마 "AcmePublisher.Books" 내에 "BookSales"로 명명된 뷰는 명칭 "[AcmePublisher.Books].[View!BookSales]"를 이용하여 액세스될 수 있다. 뷰의 출력 포맷은 뷰 단위로(뷰를 정의하는 자에 의해 제공되는 임의의 질의에 의해 정의됨) 맞춰지므로, 열은 스키마 뷰 정의에 기초하여 직접 맵핑된다.
저장 플랫폼 데이터 저장소 내의 모든 SQL 검색 뷰는 다음과 같은 열 순서화 규약을 이용한다.
- ItemId, ElementId, RelationshipId 등과 같은 뷰 결과의 논리 "키" 열
- TypeId와 같은 결과의 타입에 대한 메타데이터 정보
- CreateVersion, UpdateVersion 등과 같은 변경 추적 열
- 타입 특정 열(선언 타입의 속성)
- 타입 특정 뷰(패밀리 뷰)는 또한 객체를 리턴하는 객체 열을 포함한다.
각 타입 패밀리의 회원들은 일련의 항목 뷰들을 이용하여 검색 가능한데, 데 이터 저장소에는 항목 타입당 하나의 뷰가 존재한다. 도 28은 항목 검색 뷰의 개념을 나타내는 도면이다.
a) 항목
각 항목 검색 뷰는 특정 타입 또는 그의 서브 타입의 항목의 각 인스턴스에 대한 행을 포함한다. 예를 들어, 문서에 대한 뷰는 Document, LegalDocument 및 ReviewDocument의 인스턴스를 리턴할 수 있다. 이러한 예가 주어지면, 항목 뷰는 도 29에 도시된 바와 같이 개념화될 수 있다.
(1) 마스터 항목 검색 뷰
저장 플랫폼 데이터 저장소의 각 인스턴스는 마스터 항목 뷰라고 하는 특수 항목을 정의한다. 이 뷰는 데이터 저장소 내의 각 항목에 대한 요약 정보를 제공한다. 뷰는 항목 타입 속성당 하나의 열, 항목의 타입을 기술하는 열, 및 변경 추적 및 동기화 정보를 제공하는 데 사용되는 여러 열을 제공한다. 마스터 항목 뷰는 명칭 "[System.Storage].[Master!Item]"을 이용하여 데이터 저장소에서 식별된다.
열 타입 설명
ItemId ItemId 항목의 저장 플랫폼 식별자
_TypeId TypeId 항목의 TypeId는 항목의 정확한 타입을 식별하며, 메타데이터 카탈로그를 이용하여 타입에 대한 정보를 검색하는 데 사용될 수 있다.
_RootItemId ItemId 이 항목의 수명을 제어하는 제1 비삽입 조상의 ItemId
<global change tracking> ... 글로벌 변경 추적 정보
<Item props> n/a 항목 타입 속성당 하나의 열
(2) 타입화된 항목 검색 뷰
각 항목 타입은 또한 검색 뷰를 갖는다. 루트 항목 뷰와 유사한 반면, 이 뷰는 "_Item" 열을 통해 항목 객체에 대한 액세스도 제공한다. 각각의 타입화된 항목 검색 뷰는 명칭 [schemaName].[itemTypeName]를 이용하여 데이터 저장소에서 식별된다. 예를 들어, [AcmeCorp.Doc][OfficeDoc].
열 타입 설명
ItemId ItemId 항목의 저장 플랫폼 식별자
type change tracking> ... 타입 변경 추적 정보
parent props> <property specific> 부모 속성당 하나의 열
item props> <property specific> 이 타입의 배타적 속성당 하나의 열
Item 항목의 CLR 타입 CLR 객체-선언 항목의 타입
9.
a) 항목 확장
WinFS 저장소 내의 모든 항목 확장은 또한 검색 뷰를 이용하여 검색 가능하다.
(1) 마스터 확장 검색 뷰
데이터 저장소의 각각의 인스턴스는 마스터 확장 뷰라고 하는 특수 확장 뷰를 정의한다. 이 뷰는 데이터 저장소 내의 각각의 확장에 대한 요약 정보를 제공한다. 뷰는 확장 속성당 하나의 열, 확장 타입을 기술하는 하나의 열, 및 변경 추적 및 동기화 정보를 제공하는 데 사용되는 여러 열을 갖는다. 마스터 확장 뷰는 명칭 [System.Storage].[Master!Extension]"을 이용하여 데이터 저장소에서 식별된다.
열 타입 설명
ItemId ItemId 확장이 연관된 항목의 저장 플랫폼 식별자
ExtensionId ExtensionId(GUID) 이 확장 인스턴스의 ID
_TypeId TypeId 확장의 TypeId는 확장의 정확한 타입을 식별하며, 메타데이터 카탈로그를 이용하여 확장에 대한 정보를 검색하는 데 사용될 수 있다.
<global change tracking> ... 글로벌 변경 추적 정보
<ext properties> <property specific> 확장 타입 속성당 하나의 열
10.
(1) 타입화된 확장 검색 뷰
각각의 확장 타입은 또한 검색 뷰를 갖는다. 마스터 확장 뷰와 유사한 반면, 이 뷰는 _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 객체-선언 확장의 타입
b) 중첩 요소
모든 중첩 요소는 항목, 확장 또는 관계 인스턴스 내에 저장된다. 이에 따라, 이들은 적절한 항목, 확장 또는 관계 검색 뷰에 질의함으로써 액세스된다.
c) 관계
전술한 바와 같이, 관계는 저장 플랫폼 데이터 저장소 내의 항목들 사이의 연결의 기본 단위를 형성한다.
(1) 마스터 관계 검색 뷰
각각의 데이터 저장소는 마스터 관계 뷰를 제공한다. 이 뷰는 데이터 저장소 내의 모든 관계 인스턴스에 대한 정보를 제공한다. 마스터 관계 뷰는 명칭 "[System.Storage].[Master!Relationship]"을 이용하여 데이터 저장소에서 식별된다.
열 타입 설명
ItemId IemId 소스 엔드포인트의 식별자(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 객체-선언 관계의 타입
d)
11. 갱신
저장 플랫폼 데이터 저장소 내의 모든 뷰는 판독 전용이다. 데이터 모델 요소(항목, 확장 또는 관계)의 새로운 인스턴스를 생성하기 위하여, 또는 기존 인스턴스를 갱신하기 위하여, 저장 플랫폼 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(확장 삭제)
12. 변경 추적 및 묘비
변경 추적 및 묘비 서비스는 후술하는 바와 같이 데이터 저장소에 의해 제공된다. 이 섹션은 데이터 저장소에 노출되는 변경 추적 정보의 개요를 제공한다.
a) 변경 추적
데이터 저장소에 의해 제공되는 각 검색 뷰는 변경 추적 정보를 제공하는 데 사용되는 열들을 포함하며, 이 열들은 모든 항목, 확장 및 관계 뷰에 걸쳐 공통이다. 스키마 설계자에 의해 명시적으로 정의되는 저장 플랫폼 스키마 뷰는 변경 추적 정보를 자동으로 제공하지 않으며, 이러한 정보는 뷰 자체가 구축되는 검색 뷰를 통해 간접적으로 제공된다.
데이터 저장소 내의 각각의 요소에 대해, 변경 추적 정보는 2개의 장소, 즉 마스터 요소 뷰 및 타입화된 요소 뷰로부터 이용할 수 있다. 예를 들어, AcmeCorp.Document.Document 항목 타입에 대한 변경 추적 정보는 마스터 항목 뷰 "[System.Storage].[Master!Item] 및 타입화된 검색 뷰 [AcmeCorp.Document].[Document]로부터 이용 가능하다.
(1) 마스터 검색 뷰에서의 변경 추적
마스터 검색 뷰 내의 변경 추적 정보는 요소의 생성 및 갱신 버전에 대한 정보, 동기 파트너가 생성하고 최종 갱신한 요소의 대상인 정보, 및 생성 및 갱신을 위한 각 파트너로부터의 버전 번호를 제공한다. 동기 관계(후술함) 내의 파트너들은 파트너 키에 의해 정의된다. 타입 [System.Storage.Store].ChangeTrackingInfo의 _ChangeTrackingInfo라는 명칭의 단일 UDT 객체가 이러한 모든 정보를 포함한다. 타입은 System.Storage 스키마에서 정의된다. _ChangeTrackingInfo는 항목, 확장 및 관계에 대한 모든 글로벌 검색 뷰에서 이용될 수 있다. ChangeTrackingInfo의 타입 정의는 다음과 같다.
Figure 112005035516470-PCT00013
이들 속성은 다음 정보를 포함한다.
열 설명
_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) 묘비 제거
묘비 정보의 무제한 증가를 방지하기 위해, 데이터 저장소는 묘비 제거 태스크를 제공한다. 이 태스크는 묘비 정보가 언제 폐기될 수 있는지를 결정한다. 태스크는 로컬 생성/갱신 버전에 대한 경계를 계산한 후, 모든 초기 묘비 버전을 폐기함으로써 묘비 정보를 단축시킨다.
13. 헬퍼 API 및 함수
기본 맵핑도 다수의 헬퍼 함수를 제공한다. 이들 함수는 데이터 모델을 통 해 일반 동작들을 돕도록 제공된다.
a) 함수 [System.Storage].GetItem
Figure 112005035516470-PCT00014
b) 함수 [System.Storage].GetExtension
c) 함수 [System.Storage].GetRelationship
Figure 112005035516470-PCT00016
14. 메타데이터
저장소에서 표현되는 2가지 타입의 메타데이터, 즉 인스턴스 메타데이터(항목의 타입 등) 및 타입 메타데이터가 존재한다.
a) 스키마 메타데이터
스키마 메타데이터는 메타 스키마로부터의 항목 타입의 인스턴스로서 데이터 저장소에 저장된다.
b) 인스턴스 메타데이터
인스턴스 메타데이터는 항목의 타입에 대해 질의하기 위해 애플리케이션에 의해 사용되며, 항목과 관련된 확장을 찾는다. 항목에 대한 ItemId가 주어지면, 애플리케이션은 글로벌 항목 뷰에 질의하여 항목의 타입을 리턴하고 이 값을 이용 하여 메타 타입 뷰에 질의하여 항목의 선언 타입에 대한 정보를 리턴할 수 있다. 다음은 그 예이다.
Figure 112005035516470-PCT00017
E. 보안
일반적으로, 모든 보안 가능 객체는 도 26에 도시된 액세스 마스크 포맷을 이용하여 그들의 액세스 권리를 배열한다. 이 포맷에서, 낮은 순위의 16 비트는 객체 특정 액세스 권리에 대한 것이고, 다음 7 비트는 대부분의 객체 타입에 적용되는 표준 액세스 권리에 대한 것이며, 높은 순위의 4 비트는 각각의 객체 타입이 표준 및 객체 특정 권리의 세트로 맵핑될 수 있는 일반 액세스 권리를 지정하는 데 사용된다. ACCESS_SYSTEM_SECURITY 비트는 객체의 SACL에 액세스할 수 있는 권리에 대응한다.
도 26의 액세스 마스크 구조에서, 항목 특정 권리는 객체 특정 권리 섹션(낮은 순위의 16 비트)에 배치된다. 본 실시예에서 저장 플랫폼은 보안 관리를 위해 2 세트의 API, 즉 Win32 및 저장 플랫폼 API를 노출시키므로, 파일 시스템 객체 특정 권리는 저장 플랫폼 객체 특정 권리의 설계를 자극하도록 고려되어야 한다.
본 발명의 저장 플랫폼에 대한 보안 모델은 본 명세서에서 초기에 참조로 반영된 관련 출원들에 충분히 설명되어 있다. 이와 관련하여, 도 27(a, b, c 부분)은 보안 모델의 일 실시예에 따라 동일하게 보호되는 새로운 보안 영역이 기존 보 안 영역으로부터 분리되는 것을 나타내고 있다.
F. 통지 및 변경 추적
본 발명의 다른 양태에 따르면, 저장 플랫폼은 애플리케이션이 데이터 변경을 추적하는 것을 허용하는 통지 능력을 제공한다. 이 기능은 주로 휘발 상태를 유지하거나 데이터 변경 이벤트에서 비지니스 논리를 실행하는 애플리케이션들을 위한 것이다. 애플리케이션은 항목, 항목 확장 및 항목 관계 상의 통지에 등록한다. 통지는 데이터 변경이 행해진 후에 비동기적으로 전달된다. 애플리케이션은 항목, 확장 및 관계 타입은 물론 동작의 타입에 의해 통지를 필터링할 수 있다.
일 실시예에 따르면, 저장 플랫폼 API(322)는 통지에 대해 2 종류의 인터페이스를 제공한다. 첫째, 애플리케이션은 항목, 항목 확장 및 항목 관계에 대한 변경에 의해 트리거되는 단순 데이터 변경 이벤트에 등록한다. 둘째, 애플리케이션은 항목, 항목 확장 및 항목들 사이의 관계의 세트를 모니터하기 위해 "감시자" 객체를 생성한다. 감시자 객체의 상태는 저장될 수 있으며, 시스템 고장 후 또는 시스템이 연장된 기간 동안 오프라인으로 된 후에 재생성될 수 있다. 단일 통지는 다수의 갱신을 반영할 수 있다.
이러한 기능에 대한 추가적인 상세는 본 명세서에서 초기에 참고로 반영된 관련 출원에서 발견할 수 있다.
G. 통상적인 파일 시스템 연동성
전술한 바와 같이, 본 발명의 저장 플랫폼은 적어도 몇몇 실시예에서 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템의 통합 부분으로서 구현된다. 예컨대, 본 발명의 저장 플랫폼은 마이크로소프트 윈도우 오퍼레이팅 시스템 패밀리와 같은 오퍼레이팅 시스템의 통합 부분으로서 구현될 수 있다. 그 능력에 있어서, 저장 플랫폼 API는 애플리케이션 프로그램들이 오퍼레이팅 시스템과 상호작용할 수 있게 하는 오퍼레이팅 시스템 API의 일부가 된다. 따라서, 저장 플랫폼은 애플리케이션 프로그램들이 오퍼레이팅 시스템에서 정보를 저장하게 하는 수단이 되며, 따라서 저장 플랫폼의 항목 기반 데이터 모델은 오퍼레이팅 시스템의 통상적인 파일 시스템을 대체한다. 예를 들어, 마이크로소프트 윈도우 오퍼레이팅 시스템 패밀리에서 구현되는 바와 같이, 저장 플랫폼은 이 오퍼레이팅 시스템에서 구현된 NTFS 파일 시스템을 대체할 수 있다. 현재, 애플리케이션 프로그램들은 윈도우 오퍼레이팅 시스템 패밀리에 의해 노출되는 Win32 API를 통해 NTFS 파일 시스템의 서비스에 액세스한다.
그러나, NTFS 파일 시스템을 본 발명의 저장 플랫폼으로 완전히 대체하는 것은 기존 Win32 기반 애플리케이션 프로그램들의 재 코딩을 필요로하고, 이러한 재 코딩은 바람직하지 않을 수 있다는 것을 고려하면, 본 발명의 저장 플랫폼이 NTFS와 같은 기존 파일 시스템과의 소정의 연동성을 제공하는 것이 이로울 것이다. 따라서, 본 발명의 일 실시예에서, 저장 플랫폼은 Win32 프로그래밍 모델에 의존하는 애플리케이션 프로그램들이 통상의 NTFS 파일 시스템은 물론, 저장 플랫폼의 양 데이터 저장소의 콘텐츠에 액세스하는 것을 가능하게 한다. 이 때문에, 저장 플랫폼 은 연동을 용이하게 하기 위해 Win32 명명 규약의 수퍼 세트인 명명 규약을 사용한다. 또한, 저장 플랫폼은 Win32 API를 통해 저장 플랫폼 볼륨에 저장된 파일 및 디렉토리에 액세스하는 것을 지원한다.
이 기능에 대한 추가 상세는 본 명세서의 앞에서 참조로 반영된 관련 출원들에서 발견할 수 있다.
H. 저장 플랫폼 API
저장 플랫폼은 애플리케이션 프로그램들이 전술한 저장 플랫폼의 기능 및 능력에 액세스하고 데이터 저장소에 저장된 항목들에 액세스하는 것을 가능하게 하는 API를 포함한다. 이 섹션은 본 발명의 저장 플랫폼의 저장 플랫폼 API의 일 실시예를 설명한다. 이 기능에 대한 상세는 본 명세서의 앞에서 참조로 반영된 관련 출원들에서 발견할 수 있으며, 편의를 위해 이 정보의 일부가 아래 요약된다.
도 18을 참조하면, 포함 폴더는 다른 항목에 대한 유지 관계를 포함하는 항목이며, 파일 시스템 폴더의 일반 개념의 등가이다. 각 항목은 적어도 하나의 포함 폴더 내에 포함된다.
도 19는 본 발명에 따른 저장 플랫폼 API의 기본 아키텍처를 나타낸다. 저장 플랫폼 API는 SQLClient(1900)를 이용하여 로컬 데이터 저장소(302)와 대화하며, 또한 SQLClient(1900)를 이용하여 원격 데이터 저장소(예컨대, 데이터 저장소 340)와 대화할 수 있다. 로컬 저장소(302)는 또한 분산 질의 프로세서(DQP)를 이용하거나 후술하는 저장 플랫폼 동기화 서비스("Sync")를 통해 원격 데이터 저장소 (340)와 대화할 수 있다. 저장 플랫폼 API(322)는 전술한 바와 같이 애플리케이션의 가입을 통지 엔진(332)으로 전달하고 통지를 애플리케이션(예컨대, 애플리케이션 350a, 350b 또는 350c)으로 라우팅하는 데이터 저장소 통지용 브리지 API로서 기능한다. 일 실시예에서, 저장 플랫폼 API(322)는 또한 마이크로소프트 익스체인지 및 AD 내의 데이터에 액세스할 수 있도록 제한된 "제공자" 아키텍처를 정의할 수 있다.
도 20은 저장 플랫폼 API의 다양한 컴포넌트를 개략적으로 나타낸다. 저장 플랫폼 API는 다음 컴포넌트들, 즉 (1) 저장 플랫폼 요소 및 항목 타입을 나타내는 데이터 클래스(2002), (2) 객체의 지속성을 관리하고 지원 클래스(2006)를 제공하는 실행시간 프레임워크(2004), 및 (3) 저장 플랫폼 스키마로부터 CLR 클래스를 생성하는 데 사용되는 도구(2008)로 구성된다.
주어진 스키마로부터 결과되는 클래스들의 계층 구조는 그 스키마 내의 타입들의 계층 구조를 직접 반영한다. 예를 들어, 도 21A 및 21B에 도시된 것과 같은 콘택 스키마에 정의된 항목 타입들을 고려하자.
도 22는 실행 시간 프레임워크의 동작을 나타낸다. 실행시간 프레임워크는 다음과 같이 동작한다.
1. 애플리케이션(350a, 350b 또는 350c)은 저장 플랫폼 내의 항목들에 결합된다.
2. 프레임워크(2004)는 결합된 항목에 대응하는 ItemContext 객체(2202)를 생성하여 이를 애플리케이션에게 리턴한다.
3. 애플리케이션은 항목들의 집합을 얻기 위해 이 ItemContext 상에 Find를 제출하는데, 리턴된 집합은 개념적으로 (관계들로 인해) 객체 그래프(2204)이다.
4. 애플리케이션은 데이터를 변경, 삭제 및 삽입한다.
5. 애플리케이션은 Update() 메소드를 호출하여 변경을 저장한다.
도 23은 "FindAll" 동작의 실행을 나타낸다.
도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타낸다.
도 25는 File API가 근거로 하는 스키마를 나타낸다. 저장 플랫폼 API는 파일 객체를 처리하기 위한 명칭 공간을 포함한다. 이 명칭 공간은 System.Storage.Files라고 한다. System.Storage.Files 내의 클래스들의 데이터 회원들은 저장 플랫폼 저장소에 저장된 정보를 직접 반사하며, 이 정보는 파일 시스템 객체로부터 승진하거나, Win32 API를 이용하여 고유하게 생성될 수 있다. System.Storage.Files 명칭 공간은 2개의 클래스, 즉 FileItem 및 DirectoryItem을 갖는다. 이 클래스의 회원들 및 그의 메소드들은 도 25의 스키마 도면을 봄으로써 쉽게 발견될 수 있다. FileItem 및 DirectoryItem은 저장 플랫폼 API로부터 판독 전용이다. 이들을 수정하기 위해서는 Win32 API 또는 System.IO 내의 클래스를 이용해야 한다.
API와 관련하여, 프로그래밍 인터페이스(또는 보다 간단하게 인터페이스)는 하나 이상의 코드 세그먼트가 하나 이상의 다른 코드 세그먼트에 의해 제공되는 기능과 통신하거나 이에 액세스하는 것을 가능하게 하는 임의의 메카니즘, 프로세스, 프로토콜로서 보여질 수 있다. 대안으로, 프로그래밍 인터페이스는 다른 컴포넌트의 하나 이상의 메카니즘, 메소드, 함수 호출, 모듈 등에 통신 결합할 수 있는 시스템의 컴포넌트의 하나 이상의 메카니즘, 메소드, 함수 호출, 모듈, 객체 등으로서 보여질 수 있다. 앞 문장에서 "코드 세그먼트"라는 용어는 하나 이상의 명령 또는 코드 라인을 포함하는 것으로 의도되며, 적용되는 용어법에 관계 없이, 또는 코드 세그먼트들이 개별적으로 컴파일되거나, 코드 세그먼트들이 소스, 중간 또는 객체 코드로서 제공되는 것과 관계 없이, 코드 세그먼트들이 실행시간 시스템 또는 프로세스에서 사용되거나, 이들이 동일 또는 상이한 기계들 상에 또는 다수의 기계들에 분산되어 배치되거나, 코드 세그먼트들에 의해 표현되는 기능이 전적으로 소프트웨어로, 전적으로 하드웨어로, 또는 하드웨어 및 소프트웨어의 조합으로 구현되는지에 관계없이 예컨대 코드 모듈, 객체, 서브루틴, 함수 등을 포함한다.
개념적으로 프로그래밍 인터페이스는 도 30A 또는 30B에 도시된 바와 같이 일반적으로 보여질 수 있다. 도 30A는 제1 및 제2 코드 세그먼트가 통신하는 수단인 콘딧으로서 인터페이스 Interface1을 나타내고 있다. 도 30B는 시스템의 제1 및 제2 코드 세그먼트가 매체(M)를 통해 통신하는 것을 가능하게 하는 인터페이스 객체 I1 및 I2(이들은 제1 및 제2 코드 세그먼트의 일부이거나 아닐 수도 있다)를 포함하는 것으로서 인터페이스를 도시하고 있다. 도 30B를 볼 때, 인터페이스 객체 I1 및 I2를 동일 시스템의 개별 인터페이스로서 간주하고, 또한 객체 I1 및 I2 플러스 매체(M)이 인터페이스를 포함하는 것으로 간주할 수 있다. 도 30A 및 30B는 양방향 흐름, 및 흐름의 각 측 상의 인터페이스를 도시하고 있지만, 소정의 구 현들은 일 방향으로의 정보 흐름을 갖거나(또는 후술하는 바와 같이 정보 흐름이 없거나), 한쪽에만 인터페이스 객체를 가질 수 있다. 예를 들어, API, 엔트리 포인트, 메소드, 함수, 서브루틴, 원격 프로시저 호출 및 COM 인터페이스와 같은 용어들은 프로그래밍 인터페이스의 정의 내에 포함되지만, 이것으로 한정되는 것은 아니다.
그러한 프로그래밍 인터페이스의 양태들은 제1 코드 세그먼트가 제2 코드 세그먼트로 정보를 전송할 수 있게 하는 메소드(여기서, "정보"는 넓은 의미로 사용되며, 데이터, 명령, 요구 등을 포함한다); 제2 코드 세그먼트가 정보를 수신할 수 있게 하는 메소드; 및 정보의 구조, 시퀀스, 신택스, 조직, 스키마, 타이밍 및 내용을 포함할 수 있다. 이와 관련하여, 기반 전송 매체 자체는 정보가 인터페이스에 의해 정의된 방식으로 전송되는 한은 매체가 유선인지 무선인지, 또는 이들의 조합인지에 관계없이 인터페이스의 동작에 중요하지 않을 수 있다. 소정의 상황에서, 하나의 코드 세그먼트가 제2 코드 세그먼트에 의해 수행되는 기능에 간단히 액세스할 때와 같이 정보 전송이 다른 메카니즘을 통하거나(예컨대, 버퍼, 파일 등에 위치한 정보는 코드 세그먼트들 사이의 정보 흐름으로부터 분리된다) 존재하지 않을 수 있을 때 정보는 통상적인 의미에서 한 방향 또는 양 방향으로 전송되지 않을 수 있다. 이러한 양태들 중 임의의 양태 또는 모든 양태는 예를 들어 코드 세그먼트들이 느슨하게 결합되거나 밀접하게 결합된 구성에서 시스템의 일부인지의 여부에 따라 주어진 상황에서 중요할 수 있으며, 따라서 이 리스트는 예시적인 것일 뿐 제한적이 아닌 것으로 간주되어야 한다.
이러한 프로그래밍 인터페이스의 개념은 당업자에게 공지되어 있으며, 전술한 본 발명의 상세한 설명으로부터 명백하다. 그러나, 프로그래밍 인터페이스를 구현하는 다른 방법들이 있으며, 명백하게 배제되지 않은 한, 이들도 본 명세서의 끝에 설명되는 청구범위에 포함되는 것으로 의도된다. 그러한 다른 방법들은 도 30A 및 30B의 간단한 도면보다 복잡한 것으로 보일 수 있지만, 그럼에도 이들은 동일한 전체 결과를 달성하는 유사한 기능을 수행한다. 이제, 프로그래밍 인터페이스의 몇몇 예시적인 대체 구현을 간단히 설명한다.
인수 분해: 하나의 코드 세그먼트에서 다른 코드 세그먼트로의 통신은 통신을 다수의 개별 통신으로 분해함으로써 간접적으로 완수될 수 있다. 이것은 도 31A 및 31B에 개략적으로 도시되어 있다. 도시된 바와 같이, 몇몇 인터페이스는 분할 가능한 기능 세트에 의해 설명될 수 있다. 따라서, 도 30A 및 30B의 인터페이스 기능은, 수학적으로 24 또는 2×2×3×2를 제공할 수 있는 것과 같이, 동일한 결과를 달성할 수 있도록 인수 분해될 수 있다. 따라서, 도 31A에 도시된 바와 같이, 인터페이스 Interface1에 의해 제공되는 기능은 동일한 결과를 달성하면서 인터페이스의 통신을 변환하기 위해 다수의 인터페이스 Interface1A, Interface1B, Interface1C 등으로 세분될 수 있다. 도 31B에 도시된 바와 같이, 인터페이스 I1에 의해 제공되는 기능은 동일한 결과를 달성하면서 다수의 인터페이스 I1a, I1b, I1c 등으로 세분될 수 있다. 마찬가지로, 제1 코드 세그먼트로부터 정보를 수신하는 제2 코드 세그먼트의 인터페이스 I2는 다수의 인터페이스 I2a, I2b, I2c 등으로 인수 분해될 수 있다. 인수 분해시, 제1 코드 세그먼트에 포함되는 인터페이스의 수는 제2 코드 세그먼트에 포함되는 인터페이스의 수와 일치할 필요는 없다. 도 31A 및 31B의 경우들 중 어느 하나에서, 인터페이스 Interface1 및 I1의 기능적인 사상은 도 30A 및 30B와 각각 동일하게 유지된다. 인터페이스의 인수 분해는 또한 결합, 교환 및 다른 수학적 특성을 따를 수 있으며, 따라서 인수 분해는 인식하기 어려울 수 있다. 예를 들어, 동작들의 순서화는 중요하지 않을 수 있으며, 결과적으로 하나의 인터페이스에 의해 수행되는 기능은 이 인터페이스에 도달하기 전에 다른 코드 또는 인터페이스에 의해 수행되거나, 시스템의 개별 컴포넌트에 의해 수행될 수 있다. 더욱이, 동일 결과를 달성하는 상이한 함수 호출을 다양한 방법이 있다는 것을 프로그래밍 분야의 당업자는 이해할 수 있다.
재정의: 몇몇 경우에, 여전히 의도한 결과를 달성하면서 프로그래밍 인터페이스의 소정의 양태들(예컨대, 파라미터들)을 무시, 추가 또는 재정의할 수 있다. 이것은 도 32A 및 32B에 도시되어 있다. 예컨대, 도 30A의 인터페이스 Interface1이 3개의 파라미터, 즉 입력, 정확도 및 출력을 포함하고 제1 코드 세그먼트에서 제2 코드 세그먼트로 발행되는 호출인 함수 호출 Square(input, precision, output)를 포함하는 것으로 가정한다. 도 32A에 도시된 바와 같이, 중간 파라미터인 정확도가 주어진 시나리오에서 중요하지 않은 경우, 이 파라미터는 무시되거나, (이 상황에서) 의미 없는 파라미터로 대체될 수도 있다. 또한, 중요하지 않은 추가 파라미터를 추가할 수도 있다. 어느 경우에나, 입력이 제2 코드 세그먼트에 의해 제곱된 후 출력이 리턴되는 한 제곱의 기능은 달성될 수 있다. 정확도는 매우 양호하게 컴퓨팅 시스템의 소정의 다운스트림 또는 다른 부분에 의미 있는 파라미 터일 수 있으나, 정확도가 제곱을 계산하는 좁은 목적에 필요하지 않은 것으로 인식되면, 정확도는 대체되거나 무시될 수 있다. 예컨대, 유효한 정확도 값을 전달하는 대신, 생일과 같은 의미 없는 값이 결과에 악영향을 미치지 않고 전달될 수 있다. 마찬가지로, 도 32B에 도시된 바와 같이, 인터페이스 I1은 파라미터를 무시하거나 인터페이스에 추가하도록 재정의된 인터페이스 I1'로 대체된다. 인터페이스 I2는 마찬가지로 불필요한 파라미터, 또는 그 밖의 곳에서 처리될 수 있는 파라미터를 무시하도록 재정의된 인터페이스 I2'로 재정의될 수 있다. 여기서 요점은 몇몇 경우에 프로그래밍 인터페이스가 소정의 목적에 필요하지 않은 파라미터들과 같은 양태들을 포함할 수 있으며, 따라서 이들은 무시 또는 재정의되거나, 다른 목적을 위해 그 밖의 다른 곳에서 처리될 수 있다는 점이다.
인라인 코딩: 2개의 개별 코드 모듈의 기능의 일부 또는 전부를 병합하여 이들 사이의 인터페이스가 형태를 변경하도록 하는 것이 가능하다. 예컨대, 도 30A 및 30B의 기능은 각각 도 33A 및 33B의 기능으로 변환될 수 있다. 도 33A에서, 도 30A의 이전 제1 및 제2 코드 세그먼트들은 이들 양자를 포함하는 모듈로 병합된다. 이 경우, 코드 세그먼트들은 여전히 서로 통신할 수 있지만, 인터페이스는 단일 모듈에 보다 적절한 형태로 적응될 수 있다. 따라서, 예를 들면, 정형적인 호출 및 리턴 명령문이 더 이상 필요하지 않을 수 있지만, 인터페이스 Interface1에 따르는 유사한 처리 또는 응답이 여전히 실행될 수 있다. 마찬가지로, 도 33B에 도시된 바와 같이, 도 30B로부터의 인터페이스 I2의 일부(또는 전부)는 인터페이스 I1 내에 인라인으로 작성되어 인터페이스 I1'가 형성될 수 있다. 도시된 바와 같이, 인 터페이스 I2는 I2a 및 I2b로 분할되며, 인터페이스 부분 I2a는 인터페이스 I1과 함께 인라인 코딩되어 인터페이스 I1''이 형성된다. 구체적인 예로서, 도 30B로부터의 인터페이스 I1이, 인터페이스 I2에 의해 수신되고 제2 코드 세그먼트에 의해 입력으로 전달된 값을 처리한 후(입력 값을 제곱함) 제곱된 결과를 출력으로 전달하는 함수 호출 square(input, output)을 수행하는 것으로 가정한다. 이 경우, 제2 코드 세그먼트에 의해 수행되는 처리(입력 제곱)는 인터페이스로의 호출 없이 제1 코드 세그먼트에 의해 수행될 수 있다.
분리: 하나의 코드 세그먼트에서 다른 코드 세그먼트로의 통신은 통신을 다수의 개별 통신으로 분리함으로써 간접적으로 달성될 수 있다. 이것은 도 34A 및 34B에 개략 도시되어 있다. 도 34A에 도시된 바와 같이, 하나 이상의 미들웨어(오리지날 인터페이스로부터 기능 및/또는 인터페이스 기능들을 분리하므로 분리 인터페이스)가 제1 인터페이스 Interface1 상의 통신들을 변환하여 이들이 상이한 인터페이스, 이 경우 인터페이스 Interface2A, Interface2B 및 Interface2C를 따르도록 하기 위해 제공된다. 이것은 예를 들어 인터페이스1 프로토콜에 따라 예컨대 오퍼레이팅 시스템과 통신하도록 설계된 설치 기반 애플리케이션들이 존재하지만, 이후 오퍼레이팅 시스템이 상이한 인터페이스, 이 경우 인터페이스 Interface2A, Interface2B 및 Interface2C를 사용하도록 변경된 경우에 행해질 수 있다. 요점은, 제2 코드 세그먼트에 의해 사용되는 오리지날 인터페이스가 변경되어, 제1 코드 세그먼트에 의해 사용되는 인터페이스와 더 이상 호환이 되지 않으며, 따라서 신구 인터페이스들을 호환 가능하게 하기 위해 매개물이 사용된다는 점이다. 마찬 가지로, 도 34B에 도시된 바와 같이, 인터페이스 I1로부터 통신을 수신하는 분리 인터페이스 DI1 및 인터페이스 기능을 예컨대 인터페이스 I2a 및 I2b로 전송하는 분리 인터페이스 DI2를 구비한 제3 코드 세그먼트가 도입될 수 있는데, I2a 및 I2b는 DI2와 함께 동작하도록 재설계되지만 동일한 기능적 결과를 제공한다. 마찬가지로, DI1 및 DI2는 동일하거나 유사한 기능적 결과를 제공하면서 도 30B의 인터페이스 I1 및 I2의 기능을 새로운 오퍼레이팅 시스템으로 전달하도록 함께 동작할 수 있다.
재작성: 또 하나의 가능한 변형은 코드를 동적으로 재작성하여 인터페이스 기능을, 동일한 전체 결과를 달성하는 그 외의 다른 것으로 대체하는 것이다. 예컨대, 중간 언어로 표현된 코드 세그먼트가 실행 환경(예컨대, 네트 프레임워크, 자바 실행시간 환경 또는 다른 유사한 실행시간 타입 환경에 의해 제공됨)에서 JIT(Just-in-Time) 컴파일러 또는 인터프리터로 제공되는 시스템이 존재할 수 있다. JIT 컴파일러는 제1 코드 세그먼트에서 제2 코드 세그먼트로 통신들을 동적으로 변환하도록, 즉 이들 통신을 제2 코드 세그먼트(오리지날 또는 다른 제2 코드 세그먼트)에 의해 요구될 수 있는 바와 같이 상이한 인터페이스에 따르도록 하기 위해 재작성될 수 있다. 이것은 도 35A 및 35B에 도시되어 있다. 도 35A에 도시된 바와 같이, 이러한 접근법은 전술한 분리 시나리오와 유사하다. 이것은 예컨대 설치 기반 애플리케이션들이 Interface1 프로토콜에 따라 오퍼레이팅 시스템과 통신하도록 설계되지만, 이후 오퍼레이팅 시스템이 상이한 인터페이스를 사용하도록 변경되는 경우에 행해질 수 있다. JIT 컴파일러는 통신들이 설치 기반 애플리케이 션들에서 오퍼레이팅 시스템의 새로운 인터페이스로 온더플라이로 따르도록 하기 위해 사용될 수 있다. 도 35B에 도시된 바와 같이, 인터페이스를 동적으로 재작성하는 이러한 접근법은 인터페이스를 동적으로 인수 분해하거나 변경하기 위해 적용될 수도 있다.
대체 실시예들을 통해 인터페이스와 동일하거나 유사한 결과를 달성하는 전술한 시나리오들은 또한 다양한 방법으로, 직렬 및/또는 병렬로, 또는 다른 중재 코드와 함께 조합될 수 있다는 점에 유의해야 한다. 따라서, 전술한 대체 실시예들은 서로 배타적이지 않고, 혼합, 매칭 및 조합되어, 도 30A 및 30B에 제공된 일반 시나리오와 동일하거나 동등한 시나리오를 생성할 수 있다. 또한, 대부분의 프로그래밍 구조에서와 같이, 본 명세서에는 설명되지 않을 수 있지만 본 발명의 사상 및 범위에 의해 표현되는 인터페이스의 동일 또는 유사 기능을 달성하는 다른 유사한 방법들이 존재함에 유의해야 하는데, 즉 이것은 적어도 부분적으로 인터페이스의 값의 기초가 되는 인터페이스에 의해 표현되는 기능, 및 인터페이스에 의해 가능하게 되는 이로운 결과들이라는 점에 유의한다.
III. 동기화 API
동기화에 대한 여러 접근법은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가능하다.
A. 동기화 개요
본 발명의 여러 실시예에서, 그리고 도 3과 관련하여, 저장 플랫폼은 (i) 저장 플랫폼의 다수의 인스턴스(각각 그 자신의 데이터 저장소(302)를 가짐)가 융통성 있는 규칙 세트에 따라 그들의 콘텐츠의 부분들을 동기화시키는 것을 허용하고, (ii) 제3자가 본 발명의 저장 플랫폼의 데이터 저장소를 독점 프로토콜을 구현하는 다른 데이터 소스와 동기화하기 위한 기반 구조를 제공하는 동기화 서비스(330)를 제공한다.
저장 플랫폼 대 저장 플랫폼 동기화는 참여 "레플리커"의 그룹 사이에서 발생한다. 예컨대, 도 3을 참조하면, 아마도 다른 컴퓨터 시스템 상에서 실행되는 저장 플랫폼의 또 하나의 인스턴스의 제어하에 저장 플랫폼(300)의 데이터 저장소(302)와 다른 원격 데이터 저장소(338) 사이의 동기화를 제공하는 것이 바람직할 수 있다. 이 그룹의 모든 회원은 임의의 주어진 시간에 임의의 주어진 레플리커를 반드시 알 필요는 없다.
다른 레플리커는 독립적으로(즉, 동시에) 변경을 행할 수 있다. 동기화 프로세스는 모든 레플리커가 다른 레플리커에 의해 행해진 변경을 인식하게 만드는 것으로 정의된다. 동기화 능력은 본질적으로 멀티 마스터이다.
본 발명의 동기화 능력은 레플리커가
- 다른 레플리커가 어떠한 변경을 알고 있는지를 판정하고,
- 이 레플리커가 알지 못하는 변경에 대한 정보를 요구하고,
- 다른 레플리커가 알지 못하는 변경에 대한 정보를 전달하고,
- 2개의 변경이 언제 서로 충돌하는지를 판정하고,
- 변경을 로컬 적용하고,
- 수렴을 보장하기 위해 충돌 해결을 다른 레플리커에 전달하고,
- 충돌 해결을 위한 지정된 정책에 기초하여 충돌을 해결하는 것을 허용한다.
1. 저장 플랫폼 대 저장 플랫폼 동기화
본 발명의 저장 플랫폼의 동기화 서비스(330)의 주요 응용은 저장 플랫폼의 다수의 인스턴스(각각 그 자신의 데이터 저장소를 가짐)를 동기화하는 것이다. 동기화 서비스는 저장 플랫폼 스키마 레벨에서(데이터베이스 엔진(314)의 기본 테이블이 아님) 동작한다. 따라서, 예를 들면, "범위(Scopes)"는 후술하는 바와 같이 동기화 세트를 정의하는 데 사용된다.
동기화 서비스는 "순수 변경(net change)"의 원리로 동작한다. 동기화 서비스는 개별 동작들(예컨대, 트랜잭션 복제)을 기록하고 전송하는 것이 아니라, 이 동작들의 최종 결과를 전송하며, 따라서 종종 다수의 동작의 결과들을 단일 결과 변경으로 통합한다.
동기화 서비스는 일반적으로 트랜잭션 경계를 존중하지 않는다. 즉, 단일 트랜잭션에서 저장 플랫폼 데이터 저장소에 대해 2개의 변경이 행해진 경우, 이들 변경이 모든 다른 레플리커에 최소 단위로(atomically) 적용된다는 보장이 없는데, 즉 하나의 변경은 다른 변경 없이도 나타날 수 있다. 이 원리에 대한 예외는, 2개의 변경이 동일 트랜잭션에서 동일 항목에 대해 행해진 경우, 이들 변경은 최소 단 위로 다른 복제들로 전송되고 적용되는 것이 보장된다는 것이다. 따라서, 항목들은 동기화 서비스의 일관성 단위이다.
a) 동기화(Sync) 제어 애플리케이션
임의의 애플리케이션이 동기화 서비스에 연결되어, 동기화 동작을 개시할 수 있다. 이러한 애플리케이션은 동기화를 행하는 데 필요한 파라미터들을 모두 제공한다(아래의 동기 프로파일 참조). 이 애플리케이션은 본 명세서에서 동기화 제어 애플리케이션(SCA)이라 한다.
2개의 저장 플랫폼 인스턴스를 동기화할 때, 동기화는 SCA에 의해 한쪽에서 개시된다. SCA는 원격 파트너와 동기화하기 위해 로컬 동기화 서비스에 알린다. 다른 쪽에서는 시발 기계로부터 동기화 서비스에 의해 전송된 메시지에 의해 동기화 서비스가 개시된다. 동기화 서비스는 도달 기계 상에 존재하는 지속적인 구성 정보(아래 맵핑 참조)에 기초하여 응답한다. 동기화 서비스는 스케쥴에 따라 또는 이벤트에 응답하여 실행될 수 있다. 이들 경우에, 스케쥴을 구현하는 동기화 서비스가 SCA가 된다.
동기화를 가능하게 하기 위하여, 두 단계가 취해져야 한다. 먼저, 스키마 설계자는 저장 플랫폼 스키마에 적절한 동기화 시맨틱(후술하는 바와 같이 변경 단위를 나타냄)을 주석으로 달아야 한다. 둘째, 동기화는 동기화에 참여할 저장 플랫폼의 인스턴스를 가진 기계들 모두에서 적절히 구성되어야 한다.
b) 스키마 주석 달기
동기화 서비스의 기본 개념은 변경 단위(Change Unit)의 개념이다. 변경 단위는 저장 플랫폼에 의해 개별적으로 추적되는 스키마의 가장 작은 부분이다. 모든 변경 단위에 대해, 동기화 서비스는 변경 단위가 최종 동기화 이후 변경되었는지의 여부를 결정할 수 있다.
스키마에 변경 단위를 표시하는 것은 여러 목적을 갖는다. 먼저, 이것은 동기화 서비스가 유선 상에서 얼마나 기탄없는지를 판정한다. 변경 단위 내에서 변경이 행해질 때, 전체 변경 단위는 다른 레플리커로 전송되는데, 이는 동기화 서비스가 변경 단위의 어느 부분이 변경되었는지를 알지 못하기 때문이다. 둘째, 이것은 충돌 검출의 입도를 결정한다. 2개의 동시 변경(이 용어는 후속 섹션에서 상세히 정의된다)이 동일 변경 단위에 대해 행해질 때, 동기화 서비스는 충돌을 일으키는 반면, 동시 변경이 상이한 변경 단위들에 대해 행해지는 경우에는 충돌이 발생하지 않고, 변경들은 자동으로 병합된다. 셋째, 이것은 시스템에 의해 유지되는 메타데이터의 양에 강한 영향을 미친다. 동기화 서비스 메타데이터의 많은 부분은 변경 단위에 대해 유지되며, 따라서 변경 단위들이 동기화의 오버헤드를 보다 적게 증가시키게 된다.
변경 단위의 정의는 올바른 트레이드오프의 발견을 필요로 한다. 이 때문에, 동기화 서비스는 스키마 설계자가 프로세스에 참여하는 것을 허용한다.
일 실시예에서, 동기화 서비스는 요소보다 큰 변경 단위를 지원하지 않는다. 그러나, 동기화 서비스는 스키마 설계자가 요소보다 작은 변경 단위를 지정할 수 있는 능력, 즉 요소의 다수의 속성을 개별 변경 단위로 그룹화할 수 있는 능력을 지원한다. 이 실시예에서, 이것은 다음의 신택스를 이용하여 달성된다.
Figure 112005035516470-PCT00018
Figure 112005035516470-PCT00019
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) 충돌 검사 및 해결 단계-이 단계는 소정의 충돌이 로그되어 있는 경우에 발생하며, 동기화 세션과 관련 없이 발생하는데, 이때 로그된 충돌들이 해결되어 로그로부터 제거될 수 있다. 충돌 처리에 관한 본 발명의 다양한 실시예는 이하의 섹션Ⅲ에서 더 상세히 설명된다.
2. 비저장 플랫폼 데이터 저장소에 대한 동기화
본 발명의 저장 플랫폼의 다른 양태에 따르면(그리고, 이하의 섹션 Ⅳ에 개시된 본 발명의 다양한 실시예에 관련하여), 저장 플랫폼은 저장 플랫폼이 마이크로소프트 익스체인지, AD, 핫메일 등과 같은 레거시 시스템에 동기화하는 것을 허용하는 동기화 어댑터를 구현하기 위해 ISV에 대한 아키텍처를 제공한다. 동기 어댑터는 후술하는 바와 같이 동기화 서비스에 의해 제공되는 많은 동기화 서비스로부터 이익을 얻는다.
그 명칭에도 불구하고, 동기화 어댑터는 소정의 저장 플랫폼 아키텍처 내로의 플러그-인으로서 구현될 필요는 없다. 원할 경우, "동기 어댑터"는 단지 동기화 서비스 실행시간 인터페이스를 이용하여 변경 열거 및 적용과 같은 서비스를 얻는 임의의 애플리케이션일 수 있다.
다른 것들이 주어진 백엔드에 대한 동기화를 구성하고 실행하는 것을 보다 간단하게 하기 위해, 동기 어댑터 작성자는 전술한 바와 같이 동기화 프로파일이 주어질 때 동기화를 실행하는 표준 동기화 어댑터 인터페이스를 노출시키도록 권장된다. 프로파일은 구성 정보를 어댑터에 제공하며, 어댑터는 그 중 일부를 실행 시간에 전달하여 실행시간 서비스(예컨대, 폴더 동기화)를 제어한다.
a) 동기화 서비스
동기화 서비스는 다수의 동기화 서비스를 어댑터 작성자에게 제공한다. 이 섹션의 나머지에서는 저장 플랫폼이 동기화를 행하고 있는 기계를 "클라이언트"로, 어댑터가 대화하고 있는 비저장 플랫폼 백엔드를 "서버"로 지칭하는 것이 편리하다.
(1) 변경 열거
동기화 서비스에 의해 유지되는 변경 추적 데이터에 기초하여, 변경 열거는 동기 어댑터가 데이터 저장소 폴더에 대해 이 파트너와의 지난번 동기화가 시도된 후에 발생한 변경들을 쉽게 열거하는 것을 허용한다.
변경들은 최종 동기화에 대한 정보를 표현하는 불투명 구조인 "앵커"의 개념 에 기초하여 열거된다. 앵커는 이전 섹션에서 설명한 바와 같이 저장 플랫폼 지식의 형태를 갖는다. 변경 열거 서비스를 이용하는 동기 어댑터들은 2개의 넓은 카테고리, 즉 "저장된 앵커"를 사용하는 어댑터들 및 "제공된 앵커"를 사용하는 어댑터들로 분류된다.
그 차이는 최종 동기화에 대한 정보가 클라이언트에 저장되는지, 또는 서버에 저장되는지에 기초한다. 종종, 어댑터가 클라이언트 상에 이 정보를 저장하는 것이 더 쉬우며, 백엔드는 종종 이 정보를 편리하게 저장할 수 없다. 한편, 다수의 클라이언트가 동일한 백엔드에 동기화할 경우, 클라이언트 상에 이 정보를 저장하는 것은 비효율적이며, 몇몇 경우에는 옳지 않은데, 이는 하나의 클라이언트가 다른 클라이언트가 이미 서버에게로 푸시한 변경을 알지 못하게 한다. 어댑터가 서버에 저장된 앵커를 사용하기를 원하는 경우, 어댑터는 이 앵커를 변경 열거시에 저장 플랫폼에 제공할 필요가 있다.
저장 플랫폼이 앵커를 (로컬 또는 원격 저장소에 대해) 유지하기 위하여, 저장 플랫폼은 서버에서 성공적으로 적용된 변경들을 알 필요가 있다. 이 변경들만이 앵커에 포함될 수 있다. 변경 열거 동안, 동기화 어댑터는 어느 변경들이 성공적으로 적용되었는지를 보고하기 위해 확인 인터페이스를 사용한다. 동기화의 종료시, 제공된 앵커를 사용하는 어댑터들은 새로운 앵커(성공적으로 적용된 변경들 모두를 포함함)를 판독하여 이를 그들의 백엔드로 전송해야 한다.
종종, 어댑터들은 이들이 저장 플랫폼 데이터 저장소에 삽입하는 항목들과 함께 어댑터 특정 데이터를 저장할 필요가 있다. 이러한 데이터의 일반 예는 원격 ID 및 원격 버전(타임 스탬프)이다. 동기화 서비스는 이러한 데이터를 저장하기 위한 메카니즘을 제공하며, 변경 열거는 이러한 여분의 데이터를 리턴되는 변경과 함께 수신하기 위한 메카니즘을 제공한다. 이것은 대부분의 경우에 어댑터들이 데이터베이스에 재질의할 필요를 없앤다.
(2) 변경 적용
변경 적용은 동기화 어댑터들이 그들의 백엔드로부터 수신되는 변경들을 로컬 저장 플랫폼에 적용하는 것을 허용한다. 어댑터들은 변경들을 저장 플랫폼 스키마로 변환할 것으로 예상된다. 도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타낸다.
변경 적용의 주요 기능은 충돌을 자동으로 검출하는 것이다. 저장 플랫폼-저장 플랫폼 동기화의 경우에서와 같이, 충돌은 2개의 중복 변경이 서로에 대한 지식 없이 행해지는 것으로서 정의된다. 어댑터들이 변경 적용을 이용할 때, 이들은 충돌 검출 수행과 관련될 앵커를 지정해야 한다. 변경 적용은 어댑터의 지식에 의해 커버되지 않는 중복 로컬 변경이 검출되는 경우에 충돌을 발생시킨다. 변경 열거와 유사하게, 어댑터들은 저장 또는 제공된 앵커를 사용할 수 있다. 변경 적용은 어댑터 특정 메타데이터의 효율적인 저장을 지원한다. 이러한 데이터는 어댑터에 의해 적용되고 있는 변경들에 첨부될 수 있으며, 동기화 서비스에 의해 저장될 수 있다. 데이터는 다음 변경 열거시에 리턴될 수 있다.
(3) 충돌 해결
전술한 충돌 해결 메카니즘(로깅 및 자동 해결 옵션)은 또한 동기화 어댑터들이 이용할 수 있다. 동기화 어댑터들은 변경을 적용할 때 충돌 해결을 위한 정책을 지정할 수 있다. 지정된 경우, 충돌들은 지정된 충돌 처리자로 전달되어 (가능한 경우) 해결될 수 있다. 충돌들은 또한 로그될 수 있다. 어댑터는 로컬 변경을 백엔드에 적용하려고 시도할 때 충돌을 검출할 수 있다. 이 경우, 어댑터는 여전히 정책에 따라 해결되도록 동기화 실행시간에 충돌을 전달할 수 있다. 또한, 동기화 어댑터들은 동기화 서비스에 의해 검출된 임의의 충돌들이 처리를 위해 그들에게 전송될 것을 요구할 수 있다. 이것은 특히 백엔드가 충돌을 저장하거나 해결할 수 있는 경우에 편리하다.
b) 어댑터 구현
몇몇 어댑터들은 단지 실행시간 인터페이스를 이용하는 애플리케이션이지만, 어댑터들은 표준 어댑터 인터페이스를 구현하도록 권장된다. 이들 인터페이스는 동기화 제어 애플리케이션들이 어댑터가 주어진 동기화 프로파일에 따라 동기화를 수행할 것을 요구하고, 진행중인 동기화를 취소하고, 진행중인 동기화에 대한 진행 보고를 수신하는 것을 허용한다.
3. 보안
동기화 서비스는 저장 플랫폼에 의해 구현되는 보안 모델에 가능한 적게 도 입하려고 노력한다. 동기화에 대한 새로운 권리를 정의하기보다는 기존 권리를 사용한다. 구체적으로는 다음과 같다.
- 데이터 저장소 항목을 판독할 수 있는 누구라도 그 항목에 대한 변경을 열거할 수 있다.
- 데이터 저장소 항목에 기입할 수 있는 누구라도 그 항목에 변경을 적용할 있다.
- 데이터 저장소 항목을 확장할 수 있는 누구라도 동기화 메타데이터를 그 항목과 연관시킬 수 있다.
동기화 서비스는 보안 저자 정보를 유지하지 않는다. 사용자 U에 의해 레플리커 A에 변경이 행해져 레플리커 B로 전송될 때, 변경이 A에서(또는 U에 의해) 최초로 이루어졌다는 사실은 없어진다. B가 이 변경을 레플리커 C로 전송하는 경우, 이것은 A의 권한이 아니라 B의 권한 하에 이루어진다. 이것은 다음과 같은 제한을 유발하는데, 즉 레플리커가 항목에 대해 그 자신의 변경을 만들 권한이 없는 경우, 이 레플리커는 다른 레플리커에 의해 만들어진 변경을 전송할 수 없다.
동기화 서비스가 개시될 때, 이것은 동기화 제어 애플리케이션에 의해 행해진다. 동기화 서비스는 SCA의 식별자를 의인화하며, 이 식별자 하에 모든 동작(로컬 및 원격 양자)을 수행한다. 예를 들어, 사용자 U는 로컬 동기화 서비스가 사용자 U가 판독 액세스하지 않은 항목들에 대해 원격 저장 플랫폼으로부터 변경을 검색하게 할 수 없다는 점에 유의한다.
4. 관리성
레플리커의 분산 공동체의 모니터링은 복잡한 문제이다. 동기화 서비스는 레플리커의 상태에 대한 정보를 수집하고 분배하기 위해 "스위프" 알고리즘을 사용할 수 있다. 스위프 알고리즘의 속성들은 구성된 모든 레플리커에 대한 정보가 결국 수집되고, 실패(무응답) 레플리커가 검출되는 것을 보장한다.
이러한 공동체 전체 모니터링 정보는 모든 레플리커에서 이용 가능하게 된다. 모니터링 도구는 임의의 선택된 레플리커에서 실행되어 이 모니터링 정보를 검사하고 관리적 결정을 행할 수 있다. 영향을 받은 레플리커에서 직접 임의의 구성 변경이 행해져야 한다.
B. 동기화 API 개요
점차 분산되는 디지털 세계에서, 개인 및 작업 그룹은 종종 다양한 상이한 장치 및 위치에 정보 및 데이터를 저장한다. 이것은 분리되고, 종종 상이하고, 항상 동기화되는 데이터 저장소들에 정보를 최소한의 사용자 중재로 유지할 수 있는 데이터 동기화 서비스의 개발을 지원해왔다.
본 명세서의 섹션 II에 설명된 풍부한 저장 플랫폼(소위, "WinFS")의 일부인 본 발명의 동기화 플랫폼은 다음의 3가지 주요 대상을 다룬다.
- 애플리케이션 및 서비스가 상이한 "WinFS" 저장소들 사이에서 데이터를 동기화하는 것을 허용한다.
- 개발자들이 "WinFS" 및 non-"WinFS" 저장소들 사이에서 데이터를 동기화하 기 위한 풍부한 솔루션을 구축하는 것을 가능하게 한다.
- 개발자들에게 동기화 사용자 경험을 주문화하기 위한 적절한 인터페이스를 제공한다.
1. 일반 용어법
후술하는 섹션 III.B의 설명에 관한 보다 세련된 몇몇 정의 및 주요 개념은 다음과 같다.
동기화 레플리커: 대부분의 애플리케이션은 WinFS 저장소 내의 항목들의 소정의 서브세트에 대한 변경을 추적, 열거 및 동기화하는 데에만 관련이 있다. 동기화 동작에 참여하는 항목들의 세트는 동기화 레플리커가라 한다. 레플리커는 주어진 WinFS 포함 계층 구조(대개 폴더 항목을 루트로 함) 내에 포함된 항목들로 정의된다. 모든 동기화 서비스는 주어진 레플리커과 관련하여 수행된다. WinFS 동기화는 레플리커를 정의, 관리 및 제거하는 메카니즘을 제공한다. 모든 레플리커는 주어진 WinFS 저장소 내에서 자신을 고유하게 식별하는 GUID 식별자를 갖는다.
동기화 파트너: 동기화 파트너는 WinFS 항목, 확장 및 관계 상에서 변경에 영향을 줄 수 있는 엔티티로서 정의된다. 따라서, 모든 WinFS 저장소는 동기 파트너라고 할 수 있다. non-WinFS 저장소와 동기화될 때, 외부 데이터 저장소(EDS)도 동기 파트너라고 할 수 있다. 모든 파트너는 자신을 고유하게 식별하는 GUID 식별자를 갖는다.
동기화 공동체: 동기화 공동체는 피어 대 피어 동기화 동작에 의한 동기화시 에 유지되는 레플리커의 집합으로서 정의된다. 이들 레플리커는 모두 동일한 WinFS 저장소, 상이한 WinFS 저장소, 또는 심지어 non-WinFS 저장소 상의 가상 레플리커인 목록 자체에 있을 수 있다. WinFS 동기화는, 특히 공동체 내의 동기화 동작들만이 WinFS 동기화 서비스(WinFS 어댑터)를 통하는 경우에는 공동체에 대한 임의의 특정 토폴로지를 규정하거나 지정하지 않는다. 동기화 어댑터들(아래에 정의됨)은 그들 자신의 토폴로지 제한을 도입할 수 있다.
변경 추적, 변경 단위 및 버전: 모든 WinFS 저장소는 모든 로컬 WinFS 항목, 확장 및 관계에 대한 변경을 추적한다. 변경은 스키마에 정의된 변경 단위 입도의 레벨에서 추적된다. 임의의 항목, 확장 및 관계 타입의 최상위 레벨 필드들은 스키마 설계자에 의해 변경 단위로 세분될 수 있는데, 최소 입도가 하나의 최상위 레벨 필드가 된다. 변경 추적을 위해, 모든 변경 단위에는 버전이 할당되며, 버전은 동기화 파트너 id 및 버전 번호의 쌍이다(버전 번호는 파트너 특정 단조 증가 번호이다). 버전들은 변경이 저장소에서 로컬하게 발생하거나 변경이 다른 레플리커으로부터 얻어질 때 갱신된다.
동기화 지식: 지식은 임의의 시간에 주어진 동기화 레플리커의 상태를 나타내는데, 즉 주어진 레플리커가 로컬하게 또는 다른 레플리커로부터 인식하는 모든 변경에 대한 메타데이터를 캡슐화한다. WinFS 동기화는 동기화 동작들에서 동기화 레플리커에 대한 지식을 유지하고 갱신한다. 중요한 유의점은 지식 표현이 지식이 저장되어 있는 특정 레플리커에 대해서가 아니라 전체 공동체에 관하여 해석되는 것을 허용한다는 점이다.
동기화 어댑터: 동기화 어댑터는 동기화 실행시간 API를 통해 WinFS 동기화 서비스에 액세스하고 WinFS 데이터의 non-WinFS 데이터 저장소에 대한 동기화를 가능하게 하는 관리형 코드 애플리케이션이다. 시나리오의 요건에 따라, WinFS 데이터의 어느 서브세트가, 그리고 어떤 WinFS 데이터 타입들이 동기화되어야 하는지에 관해서는 어댑터 개발자에게 맡겨진다. 어댑터는 EDS와의 통신, WinFS 스키마의 EDS 지원 스키마로의/로부터의 변환, 및 그 자신의 구성 및 메타데이터의 관리를 담당한다. 어댑터는 일반 구성을 이용하여 WinFS 동기화 팀에 의해 제공되는 어댑터들에 대한 기반 구조를 제어할 수 있게 WinFS 동기화 어댑터 API를 구현하도록 강하게 권장된다. 보다 상세한 것은 WinFS 동기화 어댑터 API[SADP] 사양 및 WinFS 동기화 제어기 API[SCTRL] 사양을 참조한다.
WinFS 데이터를 외부 non-WinFS 저장소에 동기화하고 WinFS 포맷의 지식을 생성하거나 유지할 수 없는 어댑터들에 대해, WinFS 동기화는 후속 변경 열거 또는 적용 동작에 사용될 수 있는 원격 지식을 얻기 위한 서비스를 제공한다. 백엔드 저장소의 능력에 따라, 어댑터는 원격 지식을 백엔드 상에 또는 로컬 WinFS 저장소 상에 저장하기를 원할 수 있다.
간략화를 위해, 동기화 "레플리커"은 단일 논리 위치에 존재하는 "WinFS" 저장소 내의 한 세트의 데이터를 표현하는 구조인 반면, non-"WinFS" 저장소 상의 데이터는 "데이터 소스"라고 하며, 일반적으로 어댑터의 사용을 필요로 한다.
원격 지식: 주어진 동기화 레플리커가 다른 레플리커으로부터 변경을 얻기를 원할 때, 이 레플리커는 그 자신의 지식을 다른 레플리커가 변경들을 열거하는 기 준선으로서 제공한다. 마찬가지로, 주어진 레플리커가 다른 레플리커으로 변경을 전송하기를 원할 때, 이 레플리커는 그 자신의 지식을 충돌을 검출하기 위해 다른 레플리커에 의해 사용될 수 있는 기준선으로서 제공한다. 동기 변경 열거 및 적용 동안 제공되는 이러한 다른 레플리커에 대한 지식은 원격 지식이라 한다.
2. 동기화 API 원리
소정의 실시예에서, 동기화 API는 2개의 부분, 즉 동기화 구성 API 및 동기화 제어기 API로 분리된다. 동기화 구성 API는 애플리케이션이 동기화를 구성하고 2개의 레플리커 사이의 특정 동기화 세션에 대한 파라미터들을 지정할 수 있게 한다. 주어진 동기화 세션에 대해, 구성 파라미터들은 동기화될 항목들의 세트, 동기화의 타입(일방향 또는 양방향), 원격 데이터 저장소에 대한 정보 및 충돌 해결 정책을 포함한다. 동기화 제어기 API는 동기화 세션을 개시하고, 동기화를 취소하며, 진행중인 동기화에 대한 진행 및 에러 정보를 수신한다. 더욱이, 동기화가 미리 정해진 스케쥴에 따라 수행될 필요가 있는 특정 실시예에서, 이러한 시스템은 스케쥴링을 주문화하기 위한 스케쥴링 메카니즘을 포함할 수 있다.
본 발명의 여러 실시예는 "WinFS" 및 non-"WinFS" 데이터 소스들 사이에서 정보를 동기화하기 위해 동기화 어댑터를 사용한다. 어댑터의 예는 "WinFS" 콘택 폴더 및 non-WinFS 메일박스 사이에서 어드레스 북 정보를 동기화하는 어댑터를 포함한다. 이 예에서, 어댑터 개발자는 "WinFS" 스키마와 non-"WinFS" 데이터 소스 스키마 사이의 스키마 변환 코드를 개발하기 위하여 "WinFS" 동기화 플랫폼에 의해 제공되는 서비스에 액세스하기 위하여 본 명세서에서 설명되는 "WinFS" 동기화 코어 서비스 API를 사용할 수 있다. 또한, 어댑터 개발자는 변경들을 non-WinFS 데이터 소스와 통신하기 위한 프로토콜 지원을 제공한다. 동기화 어댑터는 동기화 제어기 API를 사용하여 호출되고 제어되며, 이 API를 이용하여 진행 및 에러를 보고한다.
그러나, 본 발명의 소정 실시예에서, WinFS 데이터 저장소를 다른 WinFS 데이터 저장소에 동기화할 때, 동기화 어댑터는 WinFS 대 WinFS 동기화 서비스가 하드웨어/소프트웨어 인터페이스 시스템 내에 통합되는 경우 필요하지 않을 수 있다. 어느 경우에나, 이러한 여러 실시예는 WinFS 대 WinFS 및 동기화 어댑터 솔루션들 양자에 대해 한 세트의 동기화 서비스를 제공하는데, 이는 다음을 포함한다.
- WinFS 항목, 확장 및 관계에 대한 변경의 추적
- 주어진 과거 상태 이후의 효율적인 증분식 변경 열거에 대한 지원
- WinFS에 대한 외부 변경의 적용
- 변경 적용 동안의 충돌 처리.
공통 데이터 저장소의 3개의 인스턴스 및 이들을 동기화하기 위한 컴포넌트들을 나타내는 도 36을 참조한다. 제1 시스템(3602)은 WinFS 대 WinFS 동기화 서비스(3622) 및 WinFS 대 non-WinFS 동기화를 위해 동기화 API(3652)를 사용할 수 있도록 노출시키는(3646) 코어 동기화 서비스(3624)를 포함하는 WinFS 데이터 저장소(3612)를 갖는다. 제1 시스템(3602)과 유사하게, 제2 시스템(3604)은 WinFS 대 WinFS 동기화 서비스(3632) 및 WinFS 대 non-WinFS 동기화를 위해 동기 API(3652) 를 이용할 수 있도록 노출시키는(3646) 코어 동기화 서비스(3634)를 포함하는 WinFS 데이터 저장소(3614)를 갖는다. 제1 시스템(3602) 및 제2 시스템(3604)은 그들 각각의 WinFS 대 WinFS 동기화 서비스(3622, 3632)를 통해 동기화된다(3642). WinFS 시스템이 아닌 제3 시스템(3606)은 WinFS 레플리커를 가진 동기화 공동체 내에 데이터 소스를 유지하기 위해 WinFS 동기화를 이용하는 애플리케이션(3666)을 갖는다. 이 애플리케이션은 WinFS 대 WinFS 동기화 서비스(3622)(이것이 그 자체를 WinFS 데이터 저장소로서 가상화할 수 있는 경우) 또는 동기화 API(3652)와 인터페이스하는 동기화 어댑터(3662)를 통해 WinFS 데이터 저장소(3612)와 직접 인터페이스하는(3644) WinFS 동기화 구성/제어 서비스(3664)를 이용할 수 있다.
이 도면에 도시된 바와 같이, 제1 시스템(3602)은 제2 시스템(3604) 및 제3 시스템(3606) 양자를 인식하고 직접 동기화된다. 그러나, 제2 시스템(3604) 및 제3 시스템(3606) 양자는 서로를 알지 못하며, 따라서 그들의 변경을 서로 직접 동기화하지 못하지만, 대신에 하나의 시스템에서 발생하는 변경은 제1 시스템(3602)을 통해 전파되어야 한다.
C. 동기화 API 서비스
본 발명의 여러 실시예는 2개의 기본 서비스, 즉 변경 열거 및 변경 적용을 포함하는 동기화 서비스와 관련된다.
1. 변경 열거
전술한 바와 같이, 변경 열거는 동기화 어댑터가 데이터 저장소 폴더에 대해 이 파트너와 최종 동기화가 시도된 이후 발생한 변경들을 동기화 서비스에 의해 유지되는 변경 추적 데이터에 기초하여 쉽게 열거하는 것을 허용한다. 변경 열거와 관련하여, 본 발명의 여러 실시예는 다음과 관련된다.
- 지정된 지식 인스턴스에 대해, 주어진 레플리커 내의 항목, 확장 및 관계에 대한 변경들의 효율적인 열거
- WinFS 스키마에 지정된 변경 단위 입도의 레벨에서의 변경들의 열거
- 복합 항목들에 관하여 열거된 변경들의 그룹화. 복합 항목은 항목, 모든 그의 확장, 항목에 대한 모든 유지 관계 및 그의 삽입 항목들에 대응하는 모든 복합 항목으로 구성된다. 항목들 사이의 참조 관계에 대한 변경은 개별적으로 열거된다.
- 변경 열거시의 배치화. 배치의 입도는 복합 항목 또는 관계 변경(참조 관계에 대해)이다.
- 변경 열거 동안 레플리커 내의 항목들에 대한 필터의 지정. 예를 들어, 레플리커는 주어진 폴더 내의 모든 항목으로 구성되지만, 특정 변경 열거에 대해 애플리케이션은 첫 번째 명칭이 'A'로 시작되는 모든 콘택 항목들에 대한 변경만을 열거하기를 원한다(이러한 지원은 B 이정표 뒤에 추가된다).
- 열거된 변경들에 대한 원격 지식을, 지식 내에 동기화에 실패한 것으로 개별 변경 단위들(또는 전체 항목, 확장 또는 관계)을 기록할 수 있는 능력과 함께 이용하여, 이들이 다음 번에 다시 열거될 수 있도록 한다.
- 변경 열거 동안 변경들과 함께 메타데이터를 리턴함으로써 WinFS 동기화 메타데이터를 이해할 수 있는 향상된 어댑터의 이용
2. 변경 적용
전술한 바와 같이, 변경 적용은 동기 어댑터들이 그들의 백엔드로부터 수신한 변경들을 로컬 저장 플랫폼에 적용하는 것을 허용하는데, 이는 어댑터들이 변경을 저장 플랫폼 스키마로 변환할 것으로 예상되기 때문이다. 변경 적용과 관련하여, 본 발명의 여러 실시예는 다음과 관련된다.
- 대응하는 갱신들을 가진 다른 레플리커(또는 non-WinFS 저장소)에서 WinFS 변경 메타데이터로의 증분식 변경의 적용
- 변경 단위 입도에서의 변경 적용시의 충돌의 검출
- 변경 적용시 개별 변경 단위 레벨에서의 성공, 실패 및 충돌의 보고. 이에 따라, 애플리케이션들(어댑터 및 동기화 제어 애플리케이션 포함)은 이 정보를 진행, 에러 및 상태 보고를 위해, 그리고 만일 있다면 그들의 백엔드 상태를 갱신하기 위해 사용할 수 있다.
- 다음 변경 열거 동작 동안 애플리케이션 제공 변경들의 "반사"를 방지하기 위한 변경 적용 동안의 원격 지식의 갱신
- 변경들과 함께 WinFS 동기화 메타데이터를 이해하고 제공할 수 있는 향상된 어댑터의 이용.
3. 샘플 코드
다음은 FOO 동기화 어댑터가 어떻게 동기화 실행시간과 상호작용하는지에 대한 코드 샘플이다(여기서, 모든 어댑터 특정 함수들 앞에는 FOO가 첨부된다):
Figure 112005035516470-PCT00020
Figure 112005035516470-PCT00021
Figure 112005035516470-PCT00022
Figure 112005035516470-PCT00023
4. API 동기화의 방법
본 발명의 일 실시예에서, WinFS 저장소와 non-WinFS 저장소 사이의 동기화는 WinFS 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 노출되는 동기화 API를 통해 달성될 수 있다.
일 실시예에서, 모든 동기화 어댑터는 이들이 일관되게 전개, 초기화 및 제 어될 수 있도록 동기화 어댑터 API, 공통 언어 실행시간(CLR) 관리형 API를 구현하도록 요구된다. 어댑터 API는 다음을 제공한다.
- 어댑터를 하드웨어/소프트웨어 인터페이스 시스템 동기화 프레임워크에 등록하기 위한 표준 메카니즘
- 어댑터들이 그들의 능력 및 어댑터를 초기화하는 데 필요한 구성 정보의 타입을 선언할 수 있는 표준 메카니즘
- 초기화 정보를 어댑터에 전달하기 위한 표준 메카니즘
- 어댑터들이 동기화를 호출하는 애플리케이션으로 진행 상태를 보고하기 위한 메카니즘
- 동기화 동안 발생하는 임의의 에러를 보고하기 위한 메카니즘
- 진행중인 동기화 동작의 최소를 요구하기 위한 메카니즘
시나리오의 요건에 따라 어댑터에 대한 2가지 잠재적인 프로세스 모델이 있다. 어댑터는 그를 호출하는 애플리케이션과 동일한 프로세스 공간에서 또는 개별 프로세스에서 단독으로 실행될 수 있다. 그 자신의 개별 프로세스에서 실행되기 위해, 어댑터는 자신을 인스턴스화하는 데 사용되는 그 자신의 팩토리 클래스를 정의한다. 팩토리는 호출 애플리케이션과 동일한 프로세스에서 어댑터의 인스턴스를 리턴하거나, 다른 마이크로소프트 공통 언어 실행시간 애플리케이션 도메인 또는 프로세스에서 어댑터의 원격 인스턴스를 리턴할 수 있다. 동일 프로세스에서 어댑터를 인스턴스화하는 디폴트 팩토리 구현이 제공된다. 실제로, 많은 어댑터는 호출 애플리케이션과 동일한 프로세스에서 실행된다. 프로세스 모델의 아웃은 대개 다음 이유 중 하나 또는 두가지 이유로 필요하다.
- 보안 목적. 어댑터는 소정의 프로세스 또는 서비스의 프로세스 공간에서 실행되어야 한다.
- 어댑터는 호출 애플리케이션으로부터의 요구를 처리하는 것에 더하여 다른 소스로부터의 요구, 예를 들어 들어오는 네트워크 요구를 처리해야 한다.
도 37을 참조하면, 본 발명의 일 실시예는 상태가 어떻게 계산되는지, 또는 그와 관련된 메타데이터가 어떻게 교환되는지를 알지 못하는 단순한 어댑터를 가정한다. 이 실시예에서, 동기화는 레플리커에 의해, 이 레플리커가 동기화하기를 원하는 데이터 소스와 관련하여, 먼저 단계 3702에서 레플리커가 상기 데이터 소스와 최종 동기화된 후 어떠한 변경이 발생했는지를 검출함으로써 달성되며, 이후 레플리커는 최종 동기화 이후에 발생한 증분식 변경을 그의 현재 상태 정보에 기초하여 전송하며, 이 현재 상태 정보 및 증분식 변경은 어댑터를 통해 데이터 소스로 전송된다. 단계 3704에서, 어댑터는 이전 단계에서 레플리커으로부터 변경 데이터를 수신한 때 가능한 한 데이터 소스에 대한 많은 변경을 행하고, 어느 변경이 성공적이고 어느 변경이 실패했는지를 추적하며, 성공 및 실패 정보를 (레플리커의) WinFS로 전송한다. 레플리커의 하드웨어/소프트웨어 인터페이스 시스템(WinFS)은 단계 3706에서, 레플리커으로부터 성공 및 실패 정보를 수신한 후 데이터 소스에 대한 새로운 상태 정보를 계산하고, 이 정보를 그의 레플리커에 의한 미래의 사용을 위해 저장하며, 이 새로운 상태 정보를 데이터 소스로, 즉 어댑터에 의한 저장 및 후속 사용을 위해 어댑터로 전송한다.
D. 동기화 계층 구조
전술한 바와 같이, 각각의 레플리커(및 데이터 소스 및/또는 어댑터)은 그의 변경들의 증분식 및 순차적 열거를 유지하는데, 이러한 변경 각각에는 대응하는 증분식 및 순차적 변경 번호가 할당된다(즉, 제1 변경은 1, 제2 변경은 2, 제3 변경은 3 등등). 더욱이, 각각의 레플리커는 그의 동기화 공동체 내의 다른 공지 레플리커(동기화 파트너)로부터 어떠한 변경을 수신했는지를 추적하기 위해 이들 다른 레플리커에 대한 상태 정보를 유지한다. 제1 레플리커에 적용된 제2 레플리커으로부터의 최종 변경의 변경 번호를 앎으로써 제1 레플리커는 후에 이 번호를 이용하여, 최종 적용된 변경의 번호보다 큰 변경들만을 요구, 수신 또는 처리할 수 있다. 도 38A-D는 이러한 순차적인 변경 열거 방법을 이용하여 어떻게 변경들이 추적되고, 열거되고 동기화되는지를 나타낸다.
도 38A에서, 동기화 어댑터 A 및 B는 공통 동기화 공동체 내의 레플리커가며, 변경이 아직 행해지지 않았으므로 각각의 레플리커에 대해 0의 변경 번호로 동일하게, 예를 들어 각각의 레플리커에 대해 A0 및 B0로 표시되는 그들의 현재 상태로 도시되어 있다. (이 실시예에서, 고유 변경 번호는 초기 상태를 반영하는 데 사용된다.) 각각의 레플리커는 그 자신의 상태를 알고 그의 동기화 파트너의 상태를 추적하며, 이 정보를 도시된 바와 같이 그의 벡터 내에 반영한다(도시된 바와 같이, 레플리커 자신의 상태를 먼저 리스트하고, 최종 동기화에 기초하여 또는 이 경우에는 초기화에 기초하여 그의 파트너들 각각의 최종 공지 상태를 리스트한다). 레플리커 A에 대한 초기 벡터는 "[A0, B0]"이며, 레플리커 B에 대한 초기 벡터는 "[B0, A0]"이며, 2개의 레플리커는 현재 완전히 동기화되어 있다.
도 38B에서, 레플리커 A는 변경을 행하고 이 변경에 고유 증분 변경 번호 A1을 할당한다(변경 번호는 레플리커 자체에 대한 고유 식별자 "A"는 물론 그 레플리커의 변경에 대한 고유 증분 번호 "1"을 포함한다). 한편, 레플리커 B는 2개의 변경을 행하며 이들 변경에 각각 B1 및 B2의 고유 증분 변경 번호를 할당한다. 이 시점에서, 다음 동기화 전에, 레플리커는 이제 동기화로부터 벗어나며, 레플리커 A에 대한 벡터는 이제 [A1, B0]이고, 레플리커 B에 대한 벡터는 [B2, A0]이다(공지된 최종 변경들이 반영됨).
도 38C에서, 레플리커 A는 레플리커 B에게 그의 현재 벡터를 전송하여 변경을 요구함으로써 레플리커 B와 동기화된다(단계 1). 레플리커 B는 레플리커 A의 벡터를 수신하고, 변경들 B1 및 B2를 레플리커 A에 전송할 필요가 있는 것으로 계산하고, 따라서 그렇게 한다(단계 2). 레플리커 A는 B1 및 B2로서 식별되는 레플리커 B의 변경들(즉, 변경 단위)을 수신하고, 이들을 적용하여 그 자신의 벡터를 [A1, B2]로 갱신한다(단계 3).
도 38D에 도시된 대체 실시예에서, 레플리커 B는 올바른 변경들을 계산하여 레플리커 A로 전송(단계 2)함과 함께 또한, 레플리커 A의 벡터에 기초하여 레플리커 B가 갖지 않은 레플리커 A에 대해 행해진 변경들이 존재하는 것으로 판정하며, 따라서 레플리커 B는 또한 그 자신의 벡터 및 변경 요구를 레플리커 A로 전송한다(단계 2'). 이후, 레플리커 A가 레플리커 B의 변경들을 수신하고, 이들을 적용하 여 그 자신의 벡터를 [A1, B2]로 갱신할 때(단계 3 동안), 레플리커 A는 또한 그의 변경들 중 어느 것을 레플리커 B로 전송할지를 계산하고, 이들을 또한 전송한다(단계 3'). 레플리커 B는 이 정보를 수신한 때 변경을 행하고 그의 벡터를 [B2, A1]으로 갱신한다(단계 4).
전술한 예와 관련하여, 여러 환경에서 충돌이 발생할 수 있다. 예컨대, A1 및 B2는 동일 변경 단위에 행해진 변경들이거나, A1은 B2가 수정하고 있는 동일한 변경 단위에 대한 삭제일 수 있다. 이러한 충돌들 중 일부는 전술한 충돌 해결 옵션을 이용하여 해결될 수 있지만, 소정의 충돌들은 매우 어려운 문제를 제공하며, 이들 문제 및 그 솔루션은 본 예에 비추어 아래 설명된다.
1. "범위 외" 변경의 사전 동기화
본 발명의 소정 실시예에서, 레플리커의 범위는 정적이 아닐 수 있다. 결과적으로, 레플리커 A는 그의 범위 내의 항목과 그의 범위 밖의 항목 사이에 새로운 관계를 생성하는 변경으로 그의 범위를 효과적으로 증가시킬 수 있다. 그러나, 범위 밖의 항목에 대한 변경 단위들이 레플리커 A 및 B 사이에서 동기화되지 않은 것으로 가정하면(이것은 레플리커에 대한 동기화의 범위 밖이기 때문이다), 이 특정 항목에 대한 버전 경로와 관련하여 동기화 불일치가 발생할 수 있다. 이 문제에 대한 솔루션은 레플리커 A가 레플리커 B에게 범위 밖의 항목에 대해 이루어진 모든 변경을, 레플리커 A에서 범위 내 항목과 범위 외 항목 사이의 관계를 생성하는 특정 변경과 함께 전송하는 것이다.
2. 부모-자식 무질서의 동기화
본 발명의 소정 실시예에서, 동기화를 위해, 부모 항목이 항상 자식 항목 전에 전송되는 것이 일반적인 원리이다(예를 들어, 자식인 항목 K가 부모인 항목 J에 삽입되는 경우, 항목 K는 항목 J가 전송되기 전에는 전송될 수 없다). 그러나, 레플리커 A에 대해, 동기화들 사이에 항목들 J 및 K 양자가 변경되지만 자식 항목 K는 부모 항목 J보다 낮은 분류 번호를 가지며(예를 들어, 그의 식별 번호의 순차적 우위에 기초하여), 따라서 정상적으로 먼저 전송되는 것이 가능하다. 본 발명의 다양한 실시예에서 동기화에 대한 이러한 문제에 대한 하나의 솔루션은 변경들을 2개의 그룹, 즉 항목 K에 대해 행해진 변경만을 반영하는 그룹, 및 항목 J에 대해 행해진 변경만을 반영하는 그룹으로 분류하고, 이들을 올바른 순서로 전송하는 것이다(즉, 부모 항목 J에 대한 변경 그룹을 전송한 후에 자식 항목 K에 대한 변경 그룹을 전송한다).
3. 묘비 전파
전술한 바와 같이, 동기화를 위해 삭제된 변경 단위들을 표시하기 위해 묘비가 사용된다. 그러나, 동기화는 동기화 공동체 내의 다수의 벡터에 대해 비동기적이므로, 이들 묘비는 전체 데이터 플랫폼으로 전파되어야 한다. 묘비 전파에 대한 책임 없이 레플리커 A가 항목을 생성할 수 있고, 레플리커 B와의 동기화 동안 이 항목을 레플리커 B로 전송할 수 있다는 것이 문제이다. 이후, 레플리커 A는 이 항 목을 삭제할 수 있고, 레플리커 C와의 동기화 동안, 전송할 것이 없기 때문에(항목이 삭제되었으므로) 항목에 대한 항목에 대한 어떤 것도 전송하지 못한다. 이후, 레플리커 B 및 레플리커 C가 동기화를 시도할 때, 레플리커 C는 레플리커 B로부터 항목을 수신하고, 항목은 B 상에 존속한다.
본 발명의 다양한 실시예에서 이러한 문제에 대한 솔루션은 레플리커 A가 삭제 항목을 묘비로 표시하는 것이다. 이후, 레플리커 A가 항목을 삭제할 때, 레플리커 C와 동기화 동안 레플리커 A는 레플리커 B로 묘비를 전송한다. 이후, 레플리커 B 및 레플리커 C가 동기화를 시도할 때, 레플리커 B는 묘비도 수신하며, 항목은 이제 동기화 공동체로부터 완전히 제거된다.
4. 루트 묘비 전파
P1에서, 항목 X가 복수의 삽입 항목 A, B, C, D 및 E를 갖는 경우, 흥미로운 시나리오는, 동기화들 사이에서 P1이 먼저 자식 항목들을 삭제하고 이어서 부모 항목 X를 삭제할 때(즉, 6번의 변경으로서 A 삭제, B 삭제, C 삭제, D 삭제, E 삭제 및 X 삭제) 발생하는데, 이는 동일한 순수 결과가 P1이 부모 X를 간단히 삭제할 때(한번의 변경)(이 경우, 삽입된 항목들도 자동으로 삭제된다) 발생하기 때문이다. 이와 관련하여, 본 발명의 여러 실시예는 동기화시 X의 삭제가 정말로 6번의 개별 삭제 이벤트와 등가이고 따라서 P1은 X의 삭제에 대응하는 변경 단위만을 P2로 전송하여, 이러한 삭제가 P2 내의 삽입 항목들로 자연스럽게 전파되는 것을 허용한다는 점을 인식함으로써 효율성을 향상시킨다.
5. 관계 명칭 스와핑
전술한 바와 같이, 관계들은 명칭을 가지며, 따라서 하나의 레플리커(P1)이 임시 명칭 요소(X)를 이용하여 2개의 관계(R1 및 R2)에 대한 명칭들을 스와핑하는 것이 가능한데, 즉 R1의 명칭은 X로 복사되고, 이어서 R2의 명칭은 R1으로 복사되며, 이어서 X는 R2로 복사되고, 마지막으로 X는 삭제된다. 그러나, 파트너 레플리커(P2)은 임시 명칭 요소 X에 대해 알지 못하므로, 동기화 동안 에러가 발생하는데, 이는 R1이 새로운 명칭을 가진 것을 인식한 경우, P2가 이 명칭을 변경하려고 시도하는 것은 R1 및 R2에 대해 동일한 명칭을 사용하는 에러를 유발하기 때문이다. 본 발명의 다양한 실시예에서 이러한 문제에 대한 하나의 솔루션은 P2가 이러한 동일 명칭 에러의 수신 또는 인식시에 가능한 명칭 스왑 시나리오를 가정하고 그 자신의 임시 명칭 요소(Y)를 자동으로 생성하며, 후속 변경이 실제로 R2를 X 내의 명칭으로 재명명하는 것을 수반하는 경우, 스와핑을 완료하는 것이다(그렇지 않은 경우, 시나리오를 정규 충돌 이벤트로서 생성한다).
6. 참조 관계
레플리커 P1(WinFS 시스템에서 실행됨)과 데이터 소스 P2(non-WinFS 시스템에서 실행됨) 사이의 동기화에 대해, non-WinFS 시스템에 의해 현수 관계(WinFS에 의해 지원됨)가 지원되지 않는 상황에서는 문제가 발생한다. 이 문제는 2개의 항목 A 및 B가 P1 상에서 관계 R을 가지며, P1이 이들을 A(변경 단위 P1-21로서), R( 변경 단위 P1-22로서), B(변경 단위 P1-23으로서)의 순서로 생성할 때 발생한다. R이 생성될 때(P1-22), R은 현수 관계이며, 따라서 P2가 변경들을 순서대로 적용할 때, 허용할 수 없는 현수 관계 에러가 발생한다. 본 발명의 여러 실시예에서 이 문제에 대한 솔루션은 모든 참조 관계(예컨대, R)가 모든 다른 변경이 P1에서 P2로 전송된 후에 전송되어, 항목들 A 및 B를 먼저 생성한 후 이들을 R로 서로 관련시킴으로써 문제가 완전히 방지될 수 있도록 변경들을 재순서화하는 것이다.
E. 동기화-충돌 처리
상술된 바와 같이, 동기화 서비스에서의 충돌 처리는 3개의 단계: (1) 변경 애플리케이션 타임에 일어나는 충돌 검출(이 단계는 변경이 안전하게 적용될 수 있는지의 여부를 결정함) (2) 자동 충돌 해결 및 로그{이 단계(충돌이 검출된 직후에 일어남) 동안, 자동 충돌 핸들러(handler)는 충돌이 해결될 수 있는지를 알아보기 위해 참고됨. 해결될 수 없다면, 충돌은 선택적으로 로그됨}; 및 (3) 충돌 검사 및 해결(이 단계는 몇몇 충돌이 로그된 경우 일어나고, 동기 세션의 문맥 외부에서 발생함. 이 때 로그된 충돌은 로그로부터 해결 및 제거될 수 있음)로 나뉘어진다.
본 발명의 여러 실시예는 특히, (상술된 동기화 시스템과 같은) 피어-투-피어 동기화 시스템에서 일어나는 충돌에 대한 충돌 처리에 관한 것이다. 충돌을 올바르고 효율적으로 처리하는 능력은 데이터 손실을 최소화하면서, 양호한 이용가능성을 유지하고 동기화 동안의 사용자 개입의 필요를 감소시킨다. 본 발명의 몇몇 실시예는 다음의 충돌 처리 엘리먼트들 중 하나 이상을 포함하는 충돌 처리 스키마에 관한 것이다. 충돌 처리 엘리먼트로는 (a) 충돌의 도식화된 표현; (b) 충돌의 검출; (c) 재구적 저장소로의 충돌의 로그; (d) 유연하고 구성가능한 충돌 해결 방책에 따른 충돌의 자동 해결; (e) 충돌을 필터링하고 해결하는 조직가능하고 확장가능한 충돌 핸들러; (f) 퇴화한 충돌의 자동 검출 및 제거; 및 (g) 프로그램적 충돌 해결책이 있다. 또한, 충돌 처리 스킴과는 별도로, 이들 충돌 처리 엘리먼트 각각 자체가 본 발명의 추가 실시예를 대표한다.
1. 충돌 타입
일반적으로, 충돌은 동기화 동작("변경 애플리케이션 실패") 동안 데이터를 동기화할 수 없을 때마다 일어난다. 이 실패는 여러 이유에서 일어날 수 있지만, 일반적으로 충돌은 2가지 카테고리 즉, 제약 충돌과 지식 충돌로 나뉘어질 수 있다.
a) 지식-기반 충돌
지식-기반 충돌은 레플리커가 동일한 변경 단위에 독립적인 변경을 행할 때 일어난다. 2개의 변경은 서로에 대한 지식 없이 이루어지는 경우, 독립적인 것이라고 불린다. 다시 말하면, 제1 버전은 제2 버전에 대한 지식에 의해 포함되지 않으며, 반대로도 그러하다. 동기화 서비스는 상술된 레플리커의 지식에 기초하여 모든 그러한 충돌을 자동으로 검출하고, 이하에 설명되는 바와 같이 이러한 충돌을 처리한다. 몇몇 특정 타입의 지식 충돌은 갱신-삭제, 삭제-갱신 및 갱신-갱신 충돌을 포함한다(여기서, 각각의 명칭은 순서대로 로컬 액션 및 원격 액션을 의미함. 예를 들어, 갱신-삭제 충돌은 동일한 데이터에 대한 로컬 갱신 및 원격 삭제에 기인함).
때때로, 충돌을 변경 단위의 버전 히스토리에서의 포크(fork)로서 간주하는 것이 도움이 된다. 변경 단위의 수명 내에서 충돌이 발생하지 않으면, 그 버전 히스토리는 단순한 체인(각각의 변경은 이전 변경 후에 일어남)일 것이다. 지식-기반 충돌의 경우에, 2개의 변경이 병렬로 일어나, 체인이 분리되어 버전 트리가 되게 한다.
요약하면, 지식 충돌은 지식 및 버전 프로세싱의 결과로서 일어난다. 이것은 데이터베이스 내에 저장된 정보에 대한 충돌하는 버전을 갖는 변경이 적용될 때, WinFS 동기화에 의해 생성된다. 충돌은 충돌하는 변경 정보뿐만 아니라 버전 정보도 포함할 필요가 있다. 지식 충돌에 대한 대부분의 요구조건은 또한, 제약 충돌에 대한 요구조건이다. 그러나, 지식 충돌은 동기 버전 및 지식만을 기반으로 검출될 수 있다.
b) 제약-기반 충돌
독립적인 변경들이 함께 적용될 때 통합 제약을 침해하는 경우가 존재한다. 예를 들어, 동일한 디렉토리에서 동일한 명칭을 가진 파일을 생성하는 2개의 레플리커는 (한 폴더 내에서 유일한 항목 명칭들을 시행하는 것과 같은) 시스템 내의 제약이 이러한 타입의 제약-기반 충돌을 발생시키는 상황에서, 그러한 충돌이 일어나게 할 수 있다.
일반적으로, 제약-기반 충돌은 지식-기반 충돌에서와 같이, 2개의 독립적인 변경을 포함한다. 그러나, 제약-기반 충돌은 동일한 변경 단위에 영향을 끼치지 않지만 대신에 상이한 변경 단위들에게 그들 간에 존재하는 제약을 이용하여 영향 을 끼치는 변경을 포함한다. 제약-기반 충돌은, 하나는 제약을 갖고 다른 하나는 갖지 않는 2개의 상이한 유형의 시스템 사이에 동기할 때 단일의 변경으로부터 생길 수 있다. 예를 들어, 시스템이 최대의 파일 명칭 길이가 8개의 문자가 되는 제약을 갖는 경우, 및 그 시스템이 그러한 제약을 갖지 않는 다른 시스템으로부터의 파일에 대한 변경을 수신하는 경우(여기서, 이 변경은 파일명칭이 8개의 문자보다 더 길게 하는 파일명칭에 대한 것임), (단일 기계 상의 단일 변경으로부터 일어난) 제약 충돌이 생긴다.
특정 타입의 제약 충돌은 다음을 포함하지만 이것으로 제한되지는 않는다.
· 삽입-삽입 충돌 : 이것은 2개의 동기화 파트너가 각각 동일한 명칭을 갖는 파일과 같은 동일한 논리적 식별자를 갖는 객체를 생성하는 경우에 일어난다.
· 부모-부재 충돌 : 이것은 생성될 인입 객체의 부모가 존재하지 않는 경우에 일어난다. 그 일례는, 파일이 그 부모 폴더 전에 수신되는 것이다.
· 비정의-유형 충돌 : 이것은 인입 객체의 스키마가 설치되지 않아서, 그 객체가 생성되는 것을 방지하는 경우에 일어난다.
요약하면, 제약 충돌은 여러 이유로 인해 변경을 적용하는 데 실패하는 것에 의해 야기된다. 그러한 실패는 결국 수렴하는 해결책의 형태로 의미있게 처리될 수 있는 경우, 또는 사용자 상호작용을 통해 궁극적인 해결책에 로그될 수 있는 경우, 제약 충돌이라고 불린다. 보고되는 것보다 의미있게 처리될 수 없는 실패는 단순히 변경 애플리케이션 에러라고 불린다. 특정 실시예에 있어서, 모든 변경 애플리케이션 실패는 에러로서 다루어진다. 즉, 인식된 제약 충돌이 없게 된다. 그 리고, 특정 실시예에 있어서, 지식 충돌이 다음 수신 동기에서 다시 제공되는 것으로 예상될 때, 송신 동기 동안 일어나는 모든 충돌은 무시된다. 비-수렴에 이른 다른 실패도 무시된다.
2. 충돌 검출
동기화 서비스는 변경 애플리케이션 시간에 제약 위반을 검출하고, 자동적으로 제약-기반 충돌을 일으킨다. 제약-기반 충돌을 해결하는 것은 보통, 제약을 위반하지 않는 방법으로 변경을 수정하는 주문형 코드를 요구하며, 동기화 서비스는 그렇게 하기 위한 범용 메커니즘을 제공할 수도 있고 제공하지 않을 수도 있다.
본 발명의 다양한 실시예에 있어서, 충돌은 로컬 지식이 원격 버전을 인식하는지, 및 반대로도 그러한지의 여부를 검사함으로써 변경 단위 별로 검출된다. 지식-기반 충돌에 대하여, 여기에 4개의 충돌 검출 시나리오가 있다.
1. 원격 번전을 인식하는 로컬 지식, 로컬 버전을 인식하지 못하는 원격 지식: 이것은 인입 변경이 퇴화한 것이어서 폐기되는 것을 의미한다.
2. 원격 버전을 인식하는 로컬 지식, 로컬 버전을 인식하지 못하는 원격 지식: 이것은 인입 변경이 로컬 버전보다 더 최근이어서 수용되는 것을 의미한다.
3. 원격 버전을 인식하는 로컬 지식, 로컬 버전을 인식하지 못하는 원격 지식: 이것은 두 모전 모두가 동일하여 변경이 적용되지 않는 경우에만 일어날 수 있다.
4. 원격 버전을 알지 못하는 로컬 지식, 로컬 버전을 알지 못하는 원격 지식: 이것은 로컬 및 원격 버전이 충돌하여 충돌이 일어나는 것을 의미한다.
3. 충돌 프로세싱
충돌은 송신 또는 수신 동기화 동안 일어날 수 있다. 그러나, 일방적 동기화 수행에서 (2개의 유사하게 구성된 WinFS 저장소와 같이) 양 파트너가 유사하다면, 시나리오는 대칭이며, 동기적으로 충돌을 자동적으르 해결하거나 동기적 해결책(자동 또는 수동)에 대한 충돌을 로그함으로써 수신 측에서 가장 쉽게 처리될 수 있다.
물론, 송신 파트너가 예를 들어, WinFS에서 비-WinFS로의 동기화와 같은 충돌을 핸들할 필요가 있을 수 있는 상황이 있다. 그러한 경우에, 이동할 수 없는 제약 충돌은 후속적인 수신 동기에서 송신 파트너로 되돌아 간다. 또하, 수신하는 파트너는 출돌 로그를 가질 수 없거나, 관리의 편이성을 위해 송신자의 충돌 로그를 필요로 하지 않을 수 있다. 그러한 경우에, 변경은 모두 함께 거절되어, 송신자가 충돌을 해결하게 할 수 있다(이하에서 설명됨).
동기 개시자는 그 동기 프로파일(Sync Profile)에서 충돌 해결책을 구성한다. 동기화 서비스는 복수의 충돌 핸들러를 단일 프로파일로 결합하는 것을 지원한다. 충돌 처리 메커니즘은 확장가능하기 때문에, 복수의 충돌 핸들러를 결합하는 몇가지 방법이 있다. 하나의 특정 방법은 (이하에 설명되는 바와 같이) 그들 중 하나가 성공할 때까지 잇따라서 연계될 충돌 핸들러들의 리스트를 지정하는 것을 포함한다. 또 다른 방법은 예를 들어, 갱신-갱신 지식-기반 충돌을 하나의 충돌 핸들러에 보내는 것, 및 모든 다른 충돌을 로그에 보내는 것과 같이, 충돌 핸들러를 충돌 타입과 관련시키는 것을 포함한다.
충돌이 검출될 때, 동기화 서비스는 (동기 프로파일에서 동기 개시자에 의해 선택된)3개의 액션들, 즉, (1) 변경 거절하는 액션; (2) 자동으로 충돌을 해결하는 액션; 또는 (3)충돌을 충돌 로그에 로그하는 액션 중 하나를 취할 수 있다.
a) 변경 거절
변경이 거절되면, 동기화 서비스는 변경이 레플리커에 도달하지 않은 것처럼 동작하며, 부정 확인을 발신자에게 되돌려 보낸다. 이 해결 정책은 주로, 로그하는 충돌이 가능하지 않은 (파일 서버와 같은) 헤드레스(headless) 레플리커에 대해 유용하다. 대신에, 그러한 레플리커는 다른 것들이 자신을 거절함으로써 충돌을 다루게 한다.
b) 자동 충돌 해결
자동 충돌 해결은 특정 정책에 따라 충돌을 동기적으로 해결하는 프로세스이다. WinFS 동기화 동작에서, 정책은 송신 동작과 수신 동작에 대해 독립적으로 지정될 수 있다. 자동 충돌 해결 정책은 동기화 프로파일을 통해 지정된다. 일어난 충돌은 프로파일에서 지정된 탑-레벨 충돌 핸들러에 전달된다. 이 충돌 핸들러는 충돌을 해결하거나, 그것을 로그하거나, 충돌 처리 파이프라인을 따라 더 처리하기 위해 그 충돌을 다른 충돌 핸들러에게 전달할 수 있다.
도 39A는 본 발명의 몇몇 실시예에 관한 충돌 처리 파이프라인을 도시한 것이다. 도면에서, 충돌이 발생할 때, 충돌 핸들러 리스트(또는 "리스트")(3910)는 충돌 항목(3902)을 수신하고, 이 경우에 필터인 파이프라인의 제1 경로 상의 제1 핸들러(3912)에게 충돌을 넘겨준다. 필터(3912)는 충돌(3902)을 평가하는 게이트 키퍼(gatekeeper)로서, 충돌을 다음 핸들러(3914)로 보내게 하거나 또는 리스트(3910)로 다시 되돌려 보내는데, 리스트(3910)는 이때 리스트(3912)를 통해 되돌아온 충돌을, 이번에는 파이프라인 내의 다음 경로 상의 제1 핸들러(3922)에 보낸다. 충돌(3902)이 제1 필터(3912)에 의해, 이 경우에 해결자(resolver)인 제2 핸들러(3914)로 보내지면, 충돌은 가능한 경우에 해결자(3914)에 의해 해결되거나, 또는 가능하지 않는 경우에, 충돌은 다시 제1 핸들러(3912)로 보내지고 리스트(3910)로 보내진 다음에, 파이프라인 내의 다음 경로 상에서 해결자(3922)로 보내진다. 그 다음, 충돌은 (a) 파이프라인 내의 핸들러들 중의 한 핸들러에 의해 해결되거나, (b) "로거(logger)", 예를 들어 로거(3936)로 공지된 특정 충돌 핸들러에 의해 (즉, 충돌이 필터(3934)를 통과한 경우에) 충돌 로그(Conflict Log)로 명백하게 로드되거나, (c) 함께 파이프라인을 다시 나가게 되어, 디폴트에 의해 충돌 로그(로거(3944)로서 절선으로 논리적으로 도시됨)로 보내질 때까지, 파이프라인을 통해 계속 진행된다.
도 39B는 도 39A에 도시된 파이프라인의 논리적 횡단을 도시한 플로우차트이다. 도 39B에서, 또한 도 39A도 참조하면, 충돌(3902)은 충돌 핸들러 리스트(3910)에서 파이프라인으로 들어가서(단계 3950), 처음에 필터(3912)로 보내진다(단계 3952). 충돌(3902)이 이 필터(3912)를 통과하면(단계 3954), 충돌(3902)은 해결자(3914)로 진행하고(단계 3956), 해결자(3914)는 충돌(3902)을 해결하고자 시도한다(단계 3958). 성공적이면, 프로세스는 복귀되고(단계 3998); 그렇지 않으면, 충돌은 해결자(3922)로 진행하며(단계 3960), 해결자(3922)는 충돌(3902)을 해 결하고자 시도한다(단계 3962). 성공적이면, 프로세스는 복귀되고(단계 3998); 그렇지 않으면, 충돌은 리스트(3932)로 진행하고(단계 3964), 거기에서부터 필터(3934)로 진행하며(단계 3966), 충돌(3902)이 필터(3934)를 통과하면(단계 3968), 충돌(3902)은 로거(3936)에 의해 충돌 로그(도시되지 않음) 내로 로그되고(단계 3970), 프로세스는 복귀되며(단계 3998); 그렇지 않으면 충돌(3902)은 필터(3938)로 보내지고(단계 3972), 충돌(3902)이 이 필터(3938)를 통과하면(3974), 충돌(3902)은 해결자(3940)로 진행하고(단계 3976), 해결자(3940)는 충돌(3902)을 해결하고자 시도한다(단계 3978). 성공적이면, 프로세스는 복귀되고(단계 3998); 그렇지 않으면, 충돌은 해결자(3942)로 진행하고(단계 3980), 해결자(3942)는 충돌(3902)을 해결하고자 시도한다(단계 3982). 성공적이면, 프로세스는 복귀되고(단계 3998); 그렇지 않으면, 충돌(3902)은 로거(3944)에 의해 충돌 로그(도시되지 않음) 내로 로그되고(단계 3984), 프로세스는 복귀된다(단계 3998).
도 39A 및 39B에 도시되지는 않았지만, 충돌이 하나의 해결자에 의해 해결될 수 없는 경우에는 연속적인 충돌 리졸브의 경로가 또한 구성될 수 있으며, 그 해결될 수 없는 충돌은 다음 해결자로 보내져서, 그 해결자가 충돌을 해결하고자 시도하는 등등으로 된다는 것을 알기 바란다. 충돌이 해결되지 않은 상태로 있는 경우에는, 한 경로의 끝부분에서만, 그 충돌은 다음 경로로 진행하기 위해 경로를 역행하여 리스트로 보내진다. 이와 마찬가지로, 한 리스트의 모든 경로가 다 사용되었으며 충돌이 해결되지 않은 상태로 있으면, 그 리스트는 충돌이 다음 리스트에 도달할 때까지 그 경로를 역행하여 충돌을 통과시키는 등등을 한다.
또한, 파이프라인이 반드시 리스트로부터 시작할 필요는 없고; 오히려, 예를 들어 필터와 같은 소정 유형의 충돌 핸들러로부터 시작할 수 있다는 것을 아는 것은 중요하다. 그러나, 이와 상관없이, 충돌이 경로를 역행하여 파이프라인 내의 제1 충돌 핸들러로 보내지고, 그 충돌 핸들러가 시도하기 위한 더 이상의 추가 경로를 갖고 있지 않으면(다만, 충돌 핸들러 리스트에 대해서는 모든 경로들이 시도된 것이 아닌 경우일 수 있음), 충돌은 파이프라인을 나와서, 자동으로 디폴트에 의해 충돌 로그로 로그된다.
ConflictHandler 유형은 충돌 핸들러 리스트, 충돌 로그 및 충돌 필터를 포함하는 충돌 핸들러의 기본 유형, 및 그외 다른 유형의 충돌 핸들러이다. 또한, 동기 서비스는 또한, 다음을 포함하지만 그것에 제한되지는 않는 다수의 디폴트 충돌 핸들러를 제공할 수 있다:
· 로컬-윈스(local-wins) : 인입 데이터보다 로컬 저장된 데이터를 위너
(winner)로서 선택함으로써 충돌을 해결;
· 원격-윈스(remote-wins) : 로컬 저장된 데이터보다 인입 데이터를
위너로서 선택함으로써 충돌을 해결;
· 최종-기록기-윈스(last-writer-wins) : 변경 단위의 타임
스탬프에 기초하여 변경 단위 당 로컬-윈스 또는 원격-윈스를 선택(동기
서비스는 일반적으로 클럭 값에 의존하지 않는데; 이 충돌 해결자는 그
규칙의 유일한 예외라는 것을 알기바람);
· 결정성(Deterministic) : 모든 레플리커(replica)에 관해 동일하게 보증
되는 방식으로 위너를 선택, 그외 다른 뜻은 없음 - 동기 서비스의 한
실시예는 이 특징을 구현하기 위해 파트너 ID의 사전식 비교를 사용할 수
있음.
예를 들어, 충돌 핸들러는 다음과 같이, 갱신-삭제(Update-Delete) 충돌인 경우에는 로컬 윈스 해결이 적용되고, 그외 다른 모든 충돌에 대해서는 최종 기록기 윈스 해결이 적용되도록 지정할 수 있다:
Figure 112005035516470-PCT00024
물론, 어떤 충돌 핸들러도 지정되지 않거나, 충돌이 어떤 특정된 충돌 핸들러에 의해서도 처리되지 않으면, 충돌은 충돌 로그 내에 배치된다. 소정의 실시예의 경우에, 충돌 로그는 또한 충돌 핸들러이다.
본 발명의 여러 실시예에서, ISV는 그들 자신의 충돌 핸들러를 구현하여 설치할 수 있다. 주문형 충돌 핸들러는, 구성 파라미터가 동기 프로파일(Sync Profile)의 충돌 해결 섹션 내의 SCA에 의해 지정되어야 하긴 하지만, 구성 파라미터를 받아들일 수 있다.
충돌 해결자는 충돌을 처리할 때, 다시 런타임으로 돌아가서 (충돌하는 변경 대신에) 실행될 필요가 있는 동작 리스트를 복귀시킨다. 그 다음, 동기 서비스는 이들 동작을 적용하여, 충돌 핸들러가 고려한 것을 포함하도록 적절하게 조정된 원격 지식을 갖는다.
해결을 적용하는 동안에 다른 충돌이 검출되는 것이 가능하다. 그러한 경우에, 새로운 충돌은 오리지널 프로세싱이 재개되기 전에 해결되거나 로그되어야 한다.
충돌을 항목의 버전 이력 내의 브랜치로서 생각할 때, 충돌 해결은 단일 점(single point)을 형성하기 위해 2개의 브랜치를 결합하는 결합(joins)으로서 간주될 수 있다. 그러므로, 충돌 해결은 버전 이력을 방향성 비순환 그래프(Directed Acyclic Graphs; DAG)로 변환시킨다.
c) 충돌 로깅
몇몇 보고된 충돌이 자동 충돌 해결을 사용하여 동기식으로 해결될 수 있는 반면, 그외 다른 것은 나중에 프로그램식 해결로 로그될 수 있다. 충돌 로깅은 충돌 해결 프로세스가 비동기식으로 진행할 수 있게 하고 - 즉, 충돌은 검출되는 때에 해결될 필요가 없이, 장래의 해결을 위해 로그될 수 있다. 예를 들어, 충돌 뷰어 애플리케이션은 사용자가 사후에 로그된 충돌을 검사하여 수동으로 해결할 수 있게 할 수 있다.
본 발명의 몇몇 실시예에서, 매우 특별한 종류의 충돌 핸들러는 충돌 로거(또는 더 간단히 "로거")이다. 동기 서비스는 충돌 로그 내의 충돌을 유형 ConflictRecord(또는, 대안적인 실시예에서는 간단히 유형 Conflict)의 항목으로서 로그한다. 이들 기록은 (항목 자체가 삭제되지 않았으면) 충돌 내에 있는 항목에 다시 관련된다. 소정의 실시예에서, 각각의 충돌 기록은 충돌을 일으킨 인입 변경; 충돌 유형(예를 들어, 갱신-갱신, 갱신-삭제, 삭제-갱신, 삽입-삽입, 또는 제 약); 및 인입 변경의 버전 및 그것을 보내는 레플리커의 지식을 포함한다. 본 발명의 소정의 대안적인 실시예에서, 각각의 그러한 충돌 항목은 변경 적용 정보, 편입 데이터 및 원격 파트너 명칭과 같은 기타 문맥 정보뿐만 아니라, 충돌하는 변경 데이터 및 메타데이터, 충돌 설명을 포함한다. 또한, 변경 데이터는 변경을 적용하기 위해 사용될 수 있는 포맷으로 저장된다. 더욱이, 본 발명의 여러 실시예에서, 충돌로부터 도출한 각각의 유형은 상기 충돌 유형에 관련되는 새로운 필드를 추가할 수 있다. 예를 들어, InsertInsertConflict 유형은 유일성 제약이 위반되게 한 항목의 항목 ID를 추가한다.
본 발명의 몇몇 실시예에서, 로그될 충돌 항목은 또한 타겟 항목의 카피를, 충돌 항목의 확장으로서, 또는 단지, 그것과 충돌 항목 자체 간에 정의된 관계로 충돌 로그 내에 또한 저장된 분리된 항목으로서, 또는 대안적으로, (특성-값 쌍들의 세트와 같은) 충돌 항목 자체의 일부로서 포함할 것이다. (항구적인 데이터 저장부 상에 유지된) 충돌 로그 내의 충돌 항목의 일부로서 또는 그 충돌 항목과 함께 저장될 이 타겟 항목은 제1 위치 내에 충돌을 일으킨 특정 변경을 반영할 것이다. 도 40은 예시적인 접속(contact) 항목을 사용하는 이러한 방법을 설명하는 블록도이다. 이 예에서, 접속 항목(4002)("타겟 항목")은 최종 성공 동기화 그대로 처음에 "John"으로 설정된 명칭 필드(4004)를 포함한다. 그 다음, 이 필드(4004)는 로컬 시스템에 의해 국부적으로 "Bob"으로 변경된다. 후속적인 동기화 동안에, 로컬 시스템이 어떤 명칭 변경 "Bob" 또는 "John"이 적용되어야 하는 지를 알아낼 수 없기 때문에, 이 동일한 필드(4004)를 "Jane"으로 변경하려는 시도가 충돌을 초 래하면, 로컬 변경("Bob")이 유지되고, 충돌(4006)은 충돌을 초래한 변경("Jane")의 적용을 반영한 접속 항목(4002')의 카피와 함께 충돌 로그(4008) 내에 로그된다. 이러한 방식으로, 충돌 로그는 충돌을 일으킨 완료 타겟 항목을 포함하고, 이 특정 타겟 항목은 충돌을 초래한 항목 상에 행해지도록 시도된 변경을 반영하기 위해 갱신된다.
충돌을 충돌 로그에 추가하기 위해, 로그는 먼저 검색되어, 동일한 변경 단위(들) 상에 다른 충돌이 있는지 판정한다. 동일한 변경 단위 상에 소정의 존재하는 충돌이 있으면, 그 충돌들은 가능한 제거하기 위해 조사된다. 존재하는 충돌은 그것의 변경 인식이 새로운 충돌의 변경 인식에 의해 포함되면 제거된다. 한편, 새로운 충돌의 변경 인식이 존재하는 로그된 충돌의 변경 인식에 의해 포함되면, 새로운 충돌은 무시되고, 이와 반대로도 된다(즉, 충돌은, 저장부가 변경의 인식이 충돌의 인식을 포함하는 변경을 수신하여 성공적으로 적용할 때처럼, 또한 그 충돌의 인식이 저장부의 인식에 의해 포함되면 쓸모없게 된다). 2개의 변경 인식의 어느 것도 다른 것을 포함하지 않는 제3의 경우에는, 새로운 충돌이 로그에 추가되고, 동일한 변경 단위에 대응하는 두 충돌은 나중에 수동으로 또는 자동으로 해결될 때까지 로그 내에 존재한다.
d) 충돌 검사 및 해결
동기 서비스는 충돌 로그를 검사하여 그 충돌 로드 내에 충돌 해결을 제시하기 위한 애플리케이션을 위해 API를 제공한다. API는 애플리케이션이 모든 충돌, 또는 주어진 항목에 관련된 충돌을 일일이 열거할 수 있게 한다. 그것은 또한 그 러한 애플리케이션이 로그된 충돌을 다음 3가지 방식중의 한가지 방식으로 해결할 수 있게 한다: (1) 원격 윈스-로그된 변경을 수용하여 충돌하는 로컬 변경을 중복기입하는 방식; (2) 로컬 윈스-로그된 변경의 충돌 부분을 무시하는 방식; 및 (3) 애플리케이션이 자신의 생각으로 충돌을 해결하는 합병을 제안하는 경우에 새로운 변경을 제안하는 방식. 일단 충돌이 애플리케이션에 의해 해결되면, 동기 서비스는 그들을 로그에서 제거한다.
e) 레플리커의 수렴 및 충돌 해결의 전달
복잡한 동기 시나리오에서는, 동일한 충돌이 다수의 레플리커에서 검출될 수 있다. 이러한 일이 생기면, 몇가지 일이 발생할 수 있다: (1) 충돌이 하나의 레플리커 상에서 해결될 수 있고, 해결이 다른 곳으로 보내질 수 있음; (2) 충돌이 두 레플리커 상에서 자동으로 해결됨; 또는 (3) 충돌이 두 레플리커 상에서 (충돌 검사 API를 통해) 수동으로 해결됨.
수렴을 보장하기 위해, 동기 서비스는 충돌 해결을 다른 레플리커에 보낸다. 충돌을 해결하는 변경이 하나의 레플리커에 도달하면, 동기 서비스는 이 갱신에 의해 해결되는 로그 내의 소정의 충돌 기록을 자동으로 찾아서 그들을 제거한다. 이러한 점에서, 한 레플리커에서의 충돌 해결은 다른 모든 레플리커 상에서 구속력이 있다.
상이한 위너들이 동일한 충돌에 대해 상이한 레플리커에 의해 선택되면, 동기 서비스는 구속력있는 충돌 해결의 원리를 적용하여, 자동으로 2개의 해결책 중에 다른 것보다 우수한 해결책을 선택한다. 위너는 언제나 동일한 결과를 생성하 는 것이 보증되는 결정적 방식으로 선택된다(한 실시예는 레플리커 ID 사전식 비교를 사용한다).
서로 다른 "새로운 변경"이 동일한 충돌에 대해 서로다른 레플리커에 의해 제안되면, 동기 서비스는 이 새로운 충돌을 특정 충돌로서 처리하고, 다른 레플리커로 전달되지 않도록 충돌 로거를 사용한다. 그러한 상황은 보통 수동 충돌 해결로 발생한다.
F. 동기 스키마 및 충돌 처리 스키마의 추가 양상
다음은 본 발명의 여러 실시예에 대한 동기 스키마의 추가적인 (또는 더욱 특정된) 양상이다.
· 각각의 레플리커는 데이터 저장부 전체로부터의 데이터의 정의된 동기화
서브셋이다 - 데이터의 일부는 여러 인스턴스를 가짐.
· 동기 스키마의 루트(root)에는, 특정 레플리커를 위해 어떤 필터나 기타
요소들이 필요하거나 요구되든지, 레플리커가 한 구성요소인 동기 커뮤니
티(community)용의 ID인 유일한 ID를 갖는 루트 폴더(실제로, 루트
항목)를 정의하기 위한 기본 유형을 갖는 레플리커가 있다.
· 각 레플리커의 "매핑"은 레플리커 내에 유지되고, 그 자체로, 소정의 특
정 레플리커를 위한 매핑은 그러한 레플리커가 알고있는 다른 레플리커로
제한된다. 이러한 매핑은 단지 전체 동기 공동체의 서브셋만을 포함할
수 있지만, 상기 레플리커에 대한 변경은 (소정의 특정 레플리커가 미지
의 레플리커와 일반적으로 공유하고 있는 다른 어떤 레플리커를 모르더라
도) 일반적으로 공유된 레플리커를 통해 전체 동기 공동체로 여전히
전해질 수 있다.
· 동기 스키마, 및 레플리커의 사용은 트루(true) 분산형 피어-투-피어 멀
티마스터 동기 공동체를 가능하게 한다. 게다가, 동기 공동체 유형
은 없지만, 동기 공동체는 단순히 레플리커 자신의 공동체 필드 내의
한 값으로서 존재한다.
· 모든 레플리커는, 점진적 변경 열거를 추적하고, 동기 공동체 내에 알
려져 있는 다른 레플리커의 상태 정보를 저장하기 위한 그 자신의 메타데
이터를 갖는다.
· 변경 단위는 다음을 포함하는 그 자신의 메타데이터를 갖는다: 파트너 변
경 번호 이외에 파트너 키를 포함하는 버전; 각각의 변경 단위를 위한 아
이템/확장/관계(Item/Extension/Relationship) 버전화; 레플리커가 동기
공동체로부터 알게 된/수신한 변경에 관한 지식; GUID 및 로컬 ID 구
성; 및 클린업을 위한 참조 관계로 저장된 GUID.
다음은 본 발명의 여러 실시예에 대한 충돌 처리 스키마의 추가적인(또는 더욱 특정된) 양상이다.
· 충돌 해결 정책은 개별적으로 각 레플리커( 및 어댑터/데이터 소스 결합)
에 의해 처리된다 - 즉, 각 레플리커는 그 자신의 기준 및 충돌 해결 스
키마에 기초하여 충돌을 해결할 수 있다. 게다가, 데이터 저장부의 각
인스턴스의 차이가 발생하여 부가적인 장래의 충돌을 초래할 수 있지만,
갱신된 상태 정보에 반영된 충돌의 점진적이고 순차적인 열거는 그 갱신
된 상태 정보를 수신하는 다른 레플리커에게는 보이지 않는다.
· 동기 스키마는 사용자/개발자 정의 주문 충돌 핸들러뿐만 아니라, 모든
레플리커에게 이용가능한 다수의 선정된 충돌 핸들러를 포함한다. 스키
마는 또한 3가지 특수 "충돌 핸들러": (a) 상이한 충돌을 상이한 방식으
로 해결하는 충돌 "필터", 즉 (i) 동일한 변경 단위가 두 곳에서 변경했
을 때 처리하는 방식, (ii) 한 변경 단위가 한 곳에서는 변경되지만 다른
곳에서는 삭제될 때 처리하는 방식, 및 (iii) 2개의 상이한 변경 단위가
2개의 상이한 위치에서 동일한 명칭을 가질 때 처리하는 방식; (b) 리스
트의 각 요소가 충돌이 성공적으로 해결될 때까지 차례로 시도하기 위한
일련의 액션을 지정하는 충돌 "핸들러 리스트"; 및 (c) 충돌을 추적하지
만 사용자의 간섭없이는 더 이상의 조처를 취하지 않는 "무동작(do-
nothing)" 로그를 포함할 수 있다.
IV. 중개자(intermediary)를 통한 동기
여기에서 설명된 새로운 저장 플랫폼의 초기 이용으로, 여러가지 개별 컴퓨터 시스템으로 구성된 동기 네트워크를 갖고있는 기업은 몇몇의 개별 컴퓨터 시스템이 새로운 저장 플랫폼을 이용하는 반면, 다른 개별 컴퓨터 시스템이 계속 기존의 저장 플랫폼을 이용한다는 점에서 혼합 시스템을 가질 수 있다. 이것은 2개의 클라이언트가 새로운 저장 플랫폼을 포함하지만 서버가 종래의 저장 플랫폼을 포함하는 소정의 클라이언트-서버 동기 구조에서 특히 중요하다. 따라서, 그러한 환경 에서는, 새로운 저장 플랫폼을 이용하는 2개의 컴퓨터 시스템("클라이언트")이 레거시 저장 플랫폼을 이용하는 컴퓨터 시스템("중개자")을 통해 동기할 필요가 있을 수 있다. 예를 들어, 몇몇의 클라이언트는 클라이언트측 캐싱(CSC)의 폴더 방향변경 또는 로밍 사용자 프로파일(RUP)과 같은 소프트웨어를 이용하여 기존의 로밍 서비스 내에 등록될 수 있다. 이들 기존의 저장 플랫폼의 기존의 로밍 소프트웨어가 새로운 저장 플랫폼의 로밍 데이터를 지원하지 않기 때문에, 새로운 저장 플랫폼의 새로운 로밍 서비스가 필요하다. 본 발명의 여러 실시예는 동일한 공통 저장 플랫폼을 사용하지 않는(예를 들어, 대신에, 새로운 저장 플랫폼의 동기를 지원하지 않는 기존의 저장 플랫폼을 사용하는) 중개자를 통해 공통 저장 플랫폼(예를 들어, 관련된 발명의 새로운 저장 플랫폼)을 이용하는 2개의 클라이언트의 동기를 위한 시스템 및 방법에 관한 것이다.
A. 중개자를 위한 데이터 구조
본 발명의 몇몇 실시예는 레플리커 클라이언트와 비-레플리커 중개자 사이에 존재하고 그 사이에서 동작하는 "중개자를 통한 동기(Sync Through Intermediary)"(STI) 어댑터에 관한 것이다. 이들 실시예에서, STI 어댑터는 레플리커 클라이언트에서 비-레플리커 중개자로의 변경 열거의 결과를 직렬화하기 위해서뿐만 아니라, 비-레플리커 중개자에서 레플리커 클라이언트로의 이들 변경 결과를 역직렬화하도록 설계된다.
도 41은 2개의 클라이언트가 중개자를 통해 동기해야 하는 시나리오를 도시한 블록도이다. 도면에서, 기존의 저장 플랫폼(예를 들어, Win32)을 이용한 중개 자 컴퓨터 시스템(4102)은 새로운 저장 플랫폼(예를 들어, 편의상, 우리가 이후에 "WinLH"로 칭하게 될 여기에 설명된 관련 발명의 실시예, 이 WinLH는 도시된 바와 같이, 여기에서 WinFS 파일 시스템이라 칭해지는 것을 포함함)을 이용하는 클라이언트A(4112)와 클라이언트B(4114)에 접속된다. 중개자(4102)는 단지, 클라이언트A(4112)에서 클라이언트B(4114)로, 그리고 그 반대로 동기되는 변경을 위한 "연결부(pass-through)"로 간주될 수 있다. 그 자체로, 중개자(4102)는 그 자신을 위해 클라이언트A(4112) 또는 클라이언트B(4114)와 스스로 "동기"하지 않으므로, 중개자(4102)는 클라이언트A(4112) 또는 클라이언트B(4114)로부터 수신한 데이터를 직접 이용하지도 변경하지도 않는다. 이러한 이유로, 앞에서 이용된 용어를 사용하면, 레플리커인 클라이언트A(4112) 또는 클라이언트B(4114)는 STI 어댑터를 통해 마치 중개자(4102)가 레플리커인 것처럼 중개자(4102)와 상호작용하지만, 중개자(4102)는 레플리커가 아니다.
클라이언트A(4112) 및 클라이언트B(4114)는 각각 STI 어댑터(4122 및 4124)를 통해 중개자(4102)와 인터페이스하고, 상기 STI 어댑터는 클라이언트(4112 및 4114)의 새로운 저장 플랫폼과 중개자(4102)의 특수 기존 플랫폼 사이에서 인터페이스하기 위해 구체적으로 맞춤화된다. 본 발명의 몇몇 대안적인 실시예는 중개자가 동기할 필요가 있을 수 있는 몇몇의 기존 저장 플랫폼에 대응하는 특수 STI 어댑터에 관한 것이다. 이것은, STI 어댑터가 클라이언트들을 성공적으로 동기시키는 클라이언트들에 국한된 어댑터이긴 하지만, 마치 중개자가 진짜 레플리커인 것처럼, 클라이언트(4112 및 4114)가 (STI 어댑터(4122 및 4144)를 통해) 중개자 (4102)와 여전히 논리적으로 동기할 수 있게 한다.
레플리커 클라이언트에서 비-레플리커 중개자로의 변경 열거의 결과를 직렬화하는 것과 관련하여, 각각의 직렬화는 중개자에게 기입되도록 파일 트리플렛(triplet)으로 직렬화되는 변경들의 배치(batch)에 대응한다. 소정의 실시예에서, 이들 파일은 특수 동기 공동체에 대응하는 특수 폴더("공동체 폴더")에 기입되고, 상이한 동기 공동체는 상이한 공동체 폴더를 가질 수 있다. 이러한 상술된 파일 트리플렛은 변경 데이터 파일(change data file: CDF), 필수 지식 파일(prerequisite knowledge file: PKF) 및 학습 지식 파일(learned knowledge file: LKF)을 포함한다. CDF는 변경 단위 레벨에서 WinFS 항목에 대한 특수 변경에 속하는 정보를 포함한다. PKF는 동기 피어가 관련 변경을 적용하기 위해 미리 알고있어야 되는 것을 지정한다. 한편, LKF는 동기 피어가 관련 변경을 적용하는 경우에 학습할 것을 지정한다. 효율성을 위해, 피어-투-피어 동기와 마찬가지로, STI 어댑터는 단지 변경 단위 정보("변경된 부분" 및 그 관련 메타데이터)를 직렬화하고, 몇몇 실시예에서, 이 데이터는 단지 (항목의 특수 변경에 대해) 항목 유형, 항목 버전 번호, 변경 단위 버전, 및 변경된 특성의 값을 포함할 수 있다. 여러 실시예에서, 파일 트리플렛은 (후술되는 이유로) 메시지 직렬화 순서에 기초하여 순차 네이밍(naming) 협약을 사용해서 중개자에게 기입되는데; 예를 들어, 제1 직렬화는 중개자 시스템 상에 1.PKF(PKF 파일), 1.CDF(CDF 파일) 및 1.LKF(LKF 파일)로서 저장되는 3개의 파일을 포함할 수 있고, 제2 직렬화는 2.PKF, 2.CDF 및 2.LKF를 포함하는 등등으로 될 수 있다.
B. STI 어댑터 프로세스
본 발명의 몇몇 실시예에서, STI 어댑터는 3개의 핵심적인 동작: 송신 동기, 수신 동기 및 데이터 압축을 포함한다.
1. 송신 동기 동작
도 42는 클라이언트가 STI 어댑터를 통해 변경 데이터를 중개자에게 송신하는 단계("송신 동기" 동작)를 도시한 흐름도이다. 단계(4202)에서, STI 어댑터는 먼저, 공동체 폴더가 클라이언트의 동기 공동체에 대응하는 중개자 상에 존재하는지 확인한다. 존재한다면, 단계(4204)에서, STI 어댑터는 그 동기 공동체에 대한 중개자의 로컬 지식(ILK)의 현재 상태를 확인하기 위해 중개자의 공동체 폴더 내의 LKF의 모든 내용을 스캔하여 역직렬화한다. 한편, 공동체 폴더가 없으면, 단계(4206)에서, ILK는 널(null)로 간주되고, 공동체 폴더가 중개자 상에 생성된다.
단계(4208)에서, STI 어댑터는 다른 클라이언트(또는 다른 피어 또는 프로세스)가 송신 동기 동작 기간 중에 공동체 폴더에 판독하거나 기입하지 못하게 함으로써 데이터 무결성을 보존하기 위해 (중개자의 파일 시스템을 통해) 중개자의 공동체 폴더 상의 "기입 모드" 프로세스 로크(lock)들을 동시에 획득한다. 단계(4210)에서, STI 어댑터는 그 다음에 ILK를 클라이언트에게 통신한다. ILK 및 자신의 클라이언트 로컬 지식(CLK)에 기초하여, 단계(4212)에서, 클라이언트는 ILK에 의해 커버되지 않은 어떤 변경이 있는지 판정하고, 없으면, 프로세스는 단계(4220)로 건너뛴다. 한편, 클라이언트가 ILK에 의해 커버되지 않은 변경이 있다고 판정하면, 단계(4214)에서, 클라이언트는 ILK에 의해 커버되지 않은 열거된 변경을 준 비하여, 그것을 STI 어댑터에게 넘긴다. 단계(4216)에서, STI 어댑터는 변경 정보(변경 데이터 및 지식)의 각 배치(batch)를 직렬화하고, 단계(4218)에서, STI 어댑터는 그 다음, 직렬화된 변경 배치를 상술된 바와 같이 순차적으로 점차 증가하는 파일 트리플렛으로서 중개자의 공동체 폴더에 기입한다. 일단 모든 직렬화된 변경 배치가 중개자에 기입되었으면, 단계(4220)에서, STI 어댑터는 "기입 모드" 프로세스 로크를 해제하여, 다른 클라이언트(또는 다른 피어 또는 프로세스)가 중개자 상의 갱신된 내용을 조사할 수 있게 한다.
송신 동기 동작은 완료되었지만, STI 어댑터는 나중에 참조하기 위해 중개자에게 기입된 마지막의 가장 높은 순차적으로 증가하는 변경 트리플렛(HCT)의 식별자(또는 참조 번호)를 저장한다는 것을 알기바란다(후술됨). 또한, 송신 동기 동작의 일부분으로서 어떤 충돌 처리도 실행되지 않는다는 것을 알기바란다. 마지막으로, 클라이언트가 단지 데이터를 "풀(pull)"하는(따라서, 클라이언트가 송신 동기 동작을 시작하지 못하는) 피어-투-피어 실시예에서, 중개자가 스스로 그 송신 동기 동작을 시작하는 기능이 없다고 하면, STI 어댑터는 중개자 대신에 자발적으로 송신 동기 동작으로 시작할 수 있다.
2. 수신 동기 동작
다른 방향의 동기의 경우, 도 43은 클라이언트가 STI 어댑터를 통해 변경 데이터를 중개자로부터 수신하는 단계("수신 동기" 동작)를 도시한 흐름도이다. 단계(4302)에서, STI 어댑터는 먼저, 본 발명의 몇몇 실시예에서, 클라이언트가 STI 어댑터를 통해 중개자에게 동기 요청을 송신할 때 발생하는 클라이언트 로컬 지식 (CLK)을 수신하는데, 상기 동기 요청은 상술된 피어-투-피어 동기 방식에 따라 CLK를 고유하게 포함한다. 단계(4304)에서, STI 어댑터는 그 다음, 다른 클라이언트(또는 다른 피어 또는 프로세스)가 수신 동기 동작 기간 중에 공동체 폴더에 기입하지 못하게(소정의 실시예에서는, 판독하지 못하게) 함으로써 데이터 무결성을 보존하기 위해 (중개자의 파일 시스템을 통해) 중개자의 공동체 폴더 상의 "판독 모드" 프로세스 로크들을 획득한다. 소정의 실시예에서, 이 "판독 모드"는 더 양호한 동시성을 위해 전체 디렉토리보다 오히려 각 트리플렛을 로크하도록 최적화될 수도 있다.
단계(4306)에서, (예를 들어, 상술된 송신 동기 동작으로 발생될 수 있는) 그 중개자에게 STI 어댑터에 의해 저장된 HCT와 관련하여, STI 어댑터는 다음으로 높은 변경 트리플렛, 즉 (a) HCT보다 순서적으로 더 높고, (b) CLK(클라이언트 로컬 지식)가 그 변경 트리플렛에 대한 (PKF로부터의) 필수 지식보다 더 높으며, (c) CLK가 변경 트리플렛에 대한 (LKF로부터의) 학습 지식보다 낮은, 변경 트리플렛을 찾기 위해 중개자 상의 공동체 폴더를 스캔한다. (그러한 변경 트리플렛은 여기에서 "적용가능한 변경 트리플렛" 또는 "ACT(applicable change triplet)"로 칭해진다.) 단계(4308)에서, 그러한 변경 트리플렛(ACT)이 있으면, 단계(4310)에서, 동기 어댑터는 그 변경 트리플렛(ACT)의 내용을 레플리커-이해가능한 열거된 변경으로 역직렬화하고, 단계(4312)에서, 그 변경을 프로세스하기 위해 클라이언트에게 보낸다. 프로세스는 그 다음, 다음의 ACT를 위해 단계(4306)로 복귀하여, 아무것도 남지 않을 때까지 프로세스가 계속되고, 단계(4314)에서 STI 어댑터가 판독 모 드를 언로크(unlock)하는 때에, 프로세스가 종료된다.
3. 중개자 파일 데이터 압축(compression/compaction)
본 발명의 여러 실시예에서, STI 어댑터에 의해 작성된 직렬화 데이터 및 지식 파일을 틀에 박힌 방식으로 압축할 필요가 있고; 그렇지 않으면 항상 증가하는 수의 변경 트리플렛이 중개자 상의 모든 이용가능한 저장 공간을 채울 것이다. 이와 관련하여, 데이터 압축의 목적은 데이터 및 지식 파일의 증가가 중개자 상에서 적절하게 제한되는 것을 보장하기 위한 것이다. 본 발명의 몇몇 실시예에 의해 이용된 한가지 방법은 공유된 파일 시스템 상에 존재하도록 허용되는 변경 패킷의 수에 관해 "상위 임계치"를 설정하는 것이고, 그 임계치가 일단 초과되면, 그렇게 할 수 있는 다음 STI 어댑터가 압축 동작을 통해 중개자 상의 공유 파일 시스템(공동체 폴더 내의 파일)을 압축하기 위해 요구된다. 압축 동작은 (a) 개별적으로 존재하는 객체에 대한 변경 이력을 압축하고, (b) (충돌 해결을 통해 명확하게, 또는 묘비 클린업(tombstone cleanup)의 결과로서) 삭제된 객체에 대한 변경 방송을 제거함으로써, 공유 파일 시스템 내에 저장된 데이터의 양을 감소시킨다. 그러나, 압축은 단지 수신 동기만을 실행했고 "완전(full)" 송신 동기(즉, 중개자 상에 공동체 폴더가 없는 것처럼 제로 기준선을 갖는 완전 변경 열거)를 즉시 실행할 수 있는 클라이언트를 위해 STI 어댑터에 의해서만 실행될 수 있다. 그러므로, 압축은 중개자와 송신 동기만을 행하거나 수신 동기만을 행하는 클라이언트에 의해 실행될 수 없다.
도 44는 STI 어댑터(즉, 송신 동기와 수신 동기를 모두 할 수 있는 클라이언 트와 관련된 STI 어댑터)가 중개자 상의 공동체 폴더 내의 데이터에 대한 압축 동작을 실행하는 단계("압축" 동작)를 도시한 흐름도이다. 도면에서, "판독 모드" 프로세스 로크를 해제하기 이전인, 단계(4202)에서의 STI 어댑터의 클라이언트를 위한 성공적인 수신 동기 동작 바로 다음에(즉, 도 43의 단계(4312) 바로 다음과 단계(4314) 이전에), 단계(4404)에서, STI 어댑터는 상위 임계치가 초과되었는지 알아보기 위해 중개자 상의 공동체 폴더를 확인하고; 초과되지 않았으면, 프로세스는 종료된다(그리고, 수신 동기 프로세스는 로크를 해제하는 등에 의해 종료된다). 그러나, 상위 임계치가 초과되었으면, 단계(4406)에서, STI 어댑터는 중개자의 공동체 폴더 내의 모든 변경 트리플렛 파일을 삭제하고, 그 다음에 단계(4408)에서, STI 어댑터는 중개자의 지식이 클라이언트에 대해 널 상태(이것은, 삭제 후에, 실제로 그러함)라는 것을 표시함으로써 클라이언트와 중개자 사이에서 완전 판독 동기 동작(기입 모드 프로세스 로크를 포함)을 하기 시작한다. 결과적으로, 클라이언트의 전체 상태에 대응하는 최소한의 트리플렛 파일 세트만이 중개자에게 업로드되어 중개자 상에 존재한다.
"판독 모드"가 더 양호한 동시성을 위해 전체 디렉토리보다 오히려 각 트리플렛을 로크하도록 최적화된 이들 실시예, 및 표준 "판독 모드"를 사용하는 본 발명의 다른 대안적인 실시예에서, 프로세스는, STI 어댑터가 (중개자의 파일 시스템을 통해) 중개자의 공동체 폴더 상의 "판독 모드" 프로세스 로크를 획득하기(도 43의 단계(4304)) 전에, STI 어댑터가 압축이 요구되는지 알아보기 위해 확인하고, 압축이 요구되면, 다른 클라이언트(또는 다른 피어 또는 프로세스)가 수신 동기 동 작 기간 중에 공동체 폴더에 기입하지 못하게(소정의 실시예에서는, 판독하지 못하게) 함으로써 데이터 무결성을 보존하기 위해 표준(최적화되지 않음) "판독 모드"를 사용한다는 점에서 약간 다르다.
소정의 대안적인 실시예에서, 중개자 상의 데이터는, 클라이언트가 첫번째 것부터 시작하여 존재하는 변경 트리플렛을 중복기입함으로써 모든 변경 트리플렛을 업로드한 후, 모든 변경 트리플렛이 업로되었으면(그리고, 기존의 것들이 재기입되었으면), 완전 판독 동작 중에 업로드된 마지막 것보다 더 높은 순서 번호의 나머지 모든 변경 트리플렛이 삭제될 때까지, 삭제되지 않는다.
마지막으로, 소정의 대안적인 실시예는 또한 완전한 판독 동기 동작이 (판독 모드 프로세스 로크를 포함하여) 완료된 후에 압축을 시작한다. 그러한 실시예에서, 프로세스는 기입 모드 프로세스 로크의 획득에서부터 시작한 다음에, 상술된 모든 단계들을 계속 실행한다.
C. STI 및 다운-레벨 클라이언트 지원
상술된 것 이외에, 본 발명의 몇몇 부가적인 실시예는 상술된 중개자를 통한 동기 기술의 변형에 관한 것이다. 소정의 실시예는 "레거시(legacy) 클라이언트"가 또한 모든 데이터 파일을 액세스할 수 있는 기존 저장 플랫폼을 또한 실행하고 있는 클라이언트를 더 포함하는 시스템에 관한 것이다. 또한, 소정의 기존 클라이언트 및 다른 애플리케이션 및 프로세스가 이들 데이터 파일을 다른 용도로 액세스할 수 있다는 것이 예상된다. 예를 들어, 작성 데이터 또는 소정의 다른 고유한 파일 특성에 기초하여 파일을 동기시키는 레거시 클라이언트의 경우가 있다. 다른 예는 임의의 또는 모든 파일(예를 들어, a*.CDK 파일)을 직접 액세스하여 그것을 카피하는 기존 클라이언트가 있을 수 있다. 레거시 클라이언트는 동일한 관점에서, 제1 중개자와 (아마도 레거시 동기 기술을 사용하여) 직접 통신하는 제2 중개자로 간주될 수 있으므로, 멀티-중개자 동기가 가능하고, 이에 의해 개시된다.
V. 결론
상술된 바와 같이, 본 발명은 데이터를 조직하고 검색하며 공유하는 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 데이터 저장장치의 개념을 현존하는 파일 시스템 및 데이터베이스 시스템 이상으로 확장하고 넓히며, 관계(표) 데이터, XML, 및 항목(Item)이라는 새로운 형태의 데이터와 같은 구조적, 비구조적 또는 반구조적 데이터를 포함하는 모든 유형의 데이터를 위한 저장부가 되도록 설계된다. 저장 플랫폼의 일반적인 저장 기반 및 조직적으로 배열된 데이터를 통해, 본 발명의 저장 플랫폼은 소비자, 지식 근무자 및 기업을 위해 더욱 효율적인 애플리케이션 개발을 가능하게 한다. 그것은 데이터 모델에 고유한 능력을 이용가능하게 할 뿐만 아니라, 현존하는 파일 시스템 및 데이터베이스 액세스 방법을 받아들여 확장시키는 풍부한 확장가능한 애플리케이션 프로그래밍 인터페이스를 제공한다. 광범위한 발명의 개념을 벗어나지 않고 상술된 실시예에 변경이 행해질 수 있다는 것이 이해된다. 따라서, 본 발명은 개시된 특정 실시예에 제한되지 않고, 첨부된 청구범위에 의해 정해진 본 발명의 정신 및 범위 내에 속하는 모든 변경을 포함하고자 하는 것이다.
상기로부터 명백해진 바와 같이, 본 발명의 여러가지 시스템, 방법 및 실시 양상의 전부 또는 일부는 프로그램 코드(즉, 명령어)의 형태로 실시될 수 있다. 이 프로그램 코드는 플로피 디스켓, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, 자기 테이프, 플래시 메모리, 하드 디스크 드라이브, 또는 소정의 다른 기계 판독가능 저장 매체를 포함하여(이것에 제한되지 않음), 자기, 전기 또는 광학 저장 매체와 같은 컴퓨터 판독가능 매체 상에 저장될 수 있는데, 여기에서 프로그램 코드가 컴퓨터 또는 서버와 같은 기계 내로 로드되어 그 기계에 의해 실행될 때, 그 기계는 본 발명을 실시하는 장치가 된다. 본 발명은 또한 전기 배선 또는 케이블을 통하거나, 광섬유를 통하거나, 인터넷 또는 인트라넷을 포함하는 네트워크를 통하거나, 임의의 다른 형태의 전송을 통하는 것과 같이, 소정의 전송 매체를 통해 전송되는 프로그램 코드의 형태로 실시될 수 있는데, 프로그램 코드가 컴퓨터와 같은 기계 내로 수신되어 로드되고, 그 기계에 의해 실행될 때, 그 기계는 본 발명을 실시하는 장치가 된다. 범용 프로세서 상에서 구현될 때, 프로그램 코드는 특정 논리 회로와 유사하게 동작하는 유일한 장치를 제공하기 위해 프로세서와 결합한다.

Claims (44)

  1. 공통 저장 플랫폼(예를 들어, WinFS)을 이용하는 최소한 2개의 컴퓨터 시스템(각각 "클라이언트")을, 다른 저장 플랫폼(예를 들어, Win32)을 갖는 중간 컴퓨터 시스템("중개자")을 통해 동기화시키는 방법으로서,
    각 클라이언트 상에 상주하여 각 클라이언트를 상기 중개자에게 인터페이스하는 STI(synchronization-through-intermediary: 중개자를 통한 동기와) 어댑터의 이용을 포함하는 방법.
  2. 제1항에 있어서,
    상기 동기화는 데이터-공유 동작을 지원하기 위해 이용되는 방법.
  3. 제1항에 있어서,
    상기 동기화는 최종-사용자 로밍(roaming)을 지원하기 위해 이용되는 방법.
  4. 제1항에 있어서,
    각각의 상기 공통 저장 플랫폼은 항목 기반의 저장 플랫폼인 방법.
  5. 제4항에 있어서,
    한 클라이언트에 대한 변경 열거(enumeration)는 상기 중개자 상에 저장된 최소한 하나의 파일(각각 "동기 파일")로서 직렬화되는 방법.
  6. 제5항에 있어서,
    상기 최소한 하나의 파일은 단일 직렬화를 위해, 변경 데이터(CD)용의 변경 데이터 파일(CDF), 필수(prerequisite) 지식(PK)용의 필수 지식 파일(PKF), 및 학습 지식(LK)용의 학습 지식 파일(LKF) 중에서 최소한 하나 이상을 포함하는 방법.
  7. 제5항에 있어서,
    상기 동기화는 제1 클라이언트와 상기 중개자 사이의 송신 동기 동작을 포함하고, 상기 송신 동기 동작은,
    중개자에 대한 학습 지식을 판정하는 단계;
    상기 제1 클라이언트가 상기 중개자의 학습 지식 내에 반영되지 않은 변경을 가졌으면, 상기 중개자에게 필요한 변경 세트를 준비하는 단계; 및
    상기 필요한 변경 세트를 직렬화하여, 그것을 상기 중개자에게 기입하는 단계
    를 포함하는 방법.
  8. 제7항에 있어서,
    상기 송신 동기 동작은,
    기입 모드 프로세스 로크(lock)들을 획득하는 단계; 및
    기입 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하는 방법.
  9. 제5항에 있어서,
    상기 동기화는 제1 클라이언트와 상기 중개자 사이의 수신 동기 동작을 포함하고, 상기 수신 동기 동작은 중개자로부터의 필요한 변경 세트를 역직렬화하여 그것을 상기 클라이언트에게 적용하는 단계를 포함하는 방법.
  10. 제9항에 있어서,
    상기 수신 동기 동작은,
    판독 모드 프로세스 로크들을 획득하는 단계; 및
    판독 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하는 방법.
  11. 제5항에 있어서,
    상기 동기화는 제1 클라이언트와 상기 중개자 사이의 압축 동작(compaction operation)을 포함하고, 상기 압축 동작은,
    상기 판독 모드 프로세스 로크들을 해제하지 않고 성공적인 수신 동기 동작을 실행하는 단계;
    모든 동기 파일을 삭제하는 단계; 및
    완전 송신 동기 동작을 실행하는 단계
    를 포함하는 방법.
  12. 공통 저장 플랫폼(예를 들어, WinFS)을 이용하는 최소한 2개의 컴퓨터 시스템(각각 "클라이언트")을, 다른 저장 플랫폼(예를 들어, Win32)을 갖는 중간 컴퓨터 시스템("중개자")을 통해 동기화시키는 시스템으로서,
    각 클라이언트를 상기 중개자에게 인터페이스하기 위해 각 클라이언트 상에 상주하는 STI 어댑터를 이용하는 최소한 하나의 서브시스템을 포함하는 시스템.
  13. 제12항에 있어서,
    상기 동기화가 데이터-공유 동작을 지원하기 위해 이용되게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  14. 제12항에 있어서,
    상기 동기화가 최종-사용자 로밍을 지원하기 위해 이용되게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  15. 제12항에 있어서,
    상기 공통 저장 플랫폼이 항목 기반의 저장 플랫폼이게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  16. 제15항에 있어서,
    한 클라이언트에 대한 변경 열거가 상기 중개자 상에 저장된 최소한 하나의 파일(각각 "동기 파일")로서 직렬화되게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  17. 제16항에 있어서,
    상기 최소한 하나의 파일이 단일 직렬화를 위해, 변경 데이터(CD)용의 변경 데이터 파일(CDF), 필수 지식(PK)용의 필수 지식 파일(PKF), 및 학습 지식(LK)용의 학습 지식 파일(LKF) 중에서 최소한 하나 이상을 포함하게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  18. 제16항에 있어서,
    상기 동기화가 제1 클라이언트와 상기 중개자 사이의 송신 동기 동작을 포함하고,
    상기 송신 동기 동작은,
    중개자에 대한 학습 지식을 판정하는 단계;
    상기 제1 클라이언트가 상기 중개자의 학습 지식 내에 반영되지 않은 변경을 가졌으면, 상기 중개자에게 필요한 변경 세트를 준비하는 단계; 및
    상기 필요한 변경 세트를 직렬화하여, 그것을 상기 중개자에게 기입하는 단 계
    를 포함하게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  19. 제18항에 있어서,
    상기 송신 동기 동작이,
    기입 모드 프로세스 로크들을 획득하는 단계; 및
    기입 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  20. 제16항에 있어서,
    상기 동기화가 제1 클라이언트와 상기 중개자 사이의 수신 동기 동작을 포함하고, 상기 수신 동기 동작이 중개자로부터의 필요한 변경 세트를 역직렬화하여 그것을 상기 클라이언트에게 적용하는 단계를 포함하게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  21. 제20항에 있어서,
    상기 수신 동기 동작이,
    판독 모드 프로세스 로크들을 획득하는 단계; 및
    판독 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  22. 제16항에 있어서,
    상기 동기화가 제1 클라이언트와 상기 중개자 사이의 압축 동작을 포함하고, 상기 압축 동작이,
    상기 판독 모드 프로세스 로크들을 해제하지 않고 성공적인 수신 동기 동작을 실행하는 단계;
    모든 동기 파일을 삭제하는 단계; 및
    완전 송신 동기 동작을 실행하는 단계
    를 포함하게 하는 최소한 하나의 서브시스템을 더 포함하는 시스템.
  23. 공통 저장 플랫폼(예를 들어, WinFS)을 이용하는 최소한 2개의 컴퓨터 시스템(각각 "클라이언트")을, 다른 저장 플랫폼(예를 들어, Win32)을 갖는 중간 컴퓨터 시스템("중개자")을 통해 동기화하는 컴퓨터 판독가능 명령어를 포함하는 컴퓨터 판독가능 매체로서, 상기 컴퓨터 판독가능 명령어는,
    각 클라이언트 상에 상주하여 각 클라이언트를 상기 중개자에게 인터페이스하는 STI 어댑터의 이용을 위한 명령어를 포함하는 컴퓨터 판독가능 매체.
  24. 제23항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 동기화 데이터-공유 동작을 지원하기 위해 이용되게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  25. 제23항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 동기화가 최종-사용자 로밍을 지원하기 위해 이용되게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  26. 제23항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 각각의 상기 공통 저장 플랫폼이 항목 기반의 저장 플랫폼이게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  27. 제26항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 한 클라이언트에 대한 변경 열거가 상기 중개자 상에 저장된 최소한 하나의 파일(각각 "동기 파일")로서 직렬화되게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  28. 제27항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 최소한 하나의 파일이 단일 직렬화를 위해, 변경 데이터(CD)용의 변경 데이터 파일(CDF), 필수 지식(PK)용의 필수 지식 파일(PKF), 및 학습 지식(LK)용의 학습 지식 파일(LKF) 중에서 최소한 하나 이상을 포함하게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  29. 제27항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 동기화가 제1 클라이언트와 상기 중개자 사이의 송신 동기 동작을 포함하고, 상기 송신 동기 동작이,
    중개자에 대한 학습 지식을 판정하는 단계;
    상기 제1 클라이언트가 상기 중개자의 학습 지식 내에 반영되지 않은 변경을 가졌으면, 상기 중개자에게 필요한 변경 세트를 준비하는 단계; 및
    상기 필요한 변경 세트를 직렬화하여, 그것을 상기 중개자에게 기입하는 단계
    를 포함하게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  30. 제29항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 송신 동기 동작이,
    기입 모드 프로세스 로크들을 획득하는 단계; 및
    기입 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  31. 제27항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 동기화가 제1 클라이언트와 상기 중개자 사이의 수신 동기 동작을 포함하고, 상기 수신 동기 동작이 중개자로부터의 필요한 변경 세트를 역직렬화하여 그것을 상기 클라이언트에게 적용하는 단계를 포함 하게 하는 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  32. 제31항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 수신 동기 동작이,
    판독 모드 프로세스 로크들을 획득하는 단계; 및
    판독 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하는 명령어를 더 포함하게 하는 컴퓨터 판독가능 매체.
  33. 제27항에 있어서,
    상기 컴퓨터 판독가능 명령어는, 상기 동기화가 제1 클라이언트와 상기 중개자 사이의 압축 동작을 포함하고, 상기 압축 동작이,
    상기 판독 모드 프로세스 로크들을 해제하지 않고 성공적인 수신 동기 동작을 실행하는 단계;
    모든 동기 파일을 삭제하는 단계; 및
    완전 송신 동기 동작을 실행하는 단계
    를 포함하는 명령어를 더 포함하게 하는 컴퓨터 판독가능 매체.
  34. 공통 저장 플랫폼(예를 들어, WinFS)을 이용하는 최소한 2개의 컴퓨터 시스템(각각 "클라이언트")을, 다른 저장 플랫폼(예를 들어, Win32)을 갖는 중간 컴퓨터 시스템("중개자")을 통해 동기화하는 하드웨어 제어 장치로서,
    각 클라이언트 상에 상주하여 각 클라이언트를 상기 중개자에게 인터페이스하는 STI 어댑터의 이용을 위한 수단을 포함하는 하드웨어 제어 장치.
  35. 제34항에 있어서,
    상기 동기화가 데이터-공유 동작을 지원하기 위해 이용되게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  36. 제34항에 있어서,
    상기 동기화가 최종-사용자 로밍을 지원하기 위해 이용되게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  37. 제34항에 있어서,
    각각의 상기 공통 저장 플랫폼이 항목 기반의 저장 플랫폼이게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  38. 제37항에 있어서,
    한 클라이언트에 대한 변경 열거가 상기 중개자 상에 저장된 최소한 하나의 파일(각각 "동기 파일")로서 직렬화되게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  39. 제38항에 있어서,
    상기 최소한 하나의 파일이 단일 직렬화를 위해, 변경 데이터(CD)용의 변경 데이터 파일(CDF), 필수 지식(PK)용의 필수 지식 파일(PKF), 및 학습 지식(LK)용의 학습 지식 파일(LKF) 중에서 최소한 하나 이상을 포함하는 수단을 더 포함하게 하는 하드웨어 제어 장치.
  40. 제38항에 있어서,
    상기 동기화가 제1 클라이언트와 상기 중개자 사이의 송신 동기 동작을 포함하고, 상기 송신 동기 동작이,
    중개자에 대한 학습 지식을 판정하는 단계;
    상기 제1 클라이언트가 상기 중개자의 학습 지식 내에 반영되지 않은 변경을 가졌으면, 상기 중개자에게 필요한 변경 세트를 준비하는 단계; 및
    상기 필요한 변경 세트를 직렬화하여, 그것을 상기 중개자에게 기입하는 단계
    를 포함하게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  41. 제40항에 있어서,
    상기 송신 동기 동작이,
    기입 모드 프로세스 로크들을 획득하는 단계; 및
    기입 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  42. 제38항에 있어서,
    상기 동기화가 제1 클라이언트와 상기 중개자 사이의 수신 동기 동작을 포함하고, 상기 수신 동기 동작이 중개자로부터의 필요한 변경 세트를 역직렬화하여 그것을 상기 클라이언트에게 적용하는 단계를 포함하게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  43. 제42항에 있어서,
    상기 수신 동기 동작이,
    판독 모드 프로세스 로크들을 획득하는 단계; 및
    판독 모드 프로세스 로크들을 해제하는 단계
    를 더 포함하게 하는 수단을 더 포함하는 하드웨어 제어 장치.
  44. 제38항에 있어서,
    상기 동기화가 제1 클라이언트와 상기 중개자 사이의 압축 동작을 포함하고, 상기 압축 동작이,
    상기 판독 모드 프로세스 로크들을 해제하지 않고 성공적인 수신 동기 동작을 실행하는 단계;
    모든 동기 파일을 삭제하는 단계; 및
    완전 송신 동기 동작을 실행하는 단계
    를 포함하게 하는 수단을 더 포함하는 하드웨어 제어 장치.
KR1020057012447A 2003-08-21 2004-07-29 중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을동기화하는 시스템 및 방법 KR101149959B1 (ko)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
WOPCT/US03/27419 2003-08-21
PCT/US2003/027419 WO2005029314A1 (en) 2003-08-21 2003-08-21 Storage platform for organizing, searching, and sharing data
US10/646,646 US7349913B2 (en) 2003-08-21 2003-08-21 Storage platform for organizing, searching, and sharing data
US10/646,646 2003-08-21
US10/692,508 2003-10-24
US10/692,508 US7483923B2 (en) 2003-08-21 2003-10-24 Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system
US56714104P 2004-04-30 2004-04-30
US60/567,141 2004-04-30
US10/883,621 2004-06-30
US10/883,621 US7512638B2 (en) 2003-08-21 2004-06-30 Systems and methods for providing conflict handling for peer-to-peer synchronization of units of information manageable by a hardware/software interface system
US10/889,423 US7401104B2 (en) 2003-08-21 2004-07-12 Systems and methods for synchronizing computer systems through an intermediary file system share or device
US10/889,423 2004-07-12
PCT/US2004/024441 WO2005024551A2 (en) 2003-08-21 2004-07-29 Systems and methods for synchronizing computer systems throuth an intermediary file system share or device

Publications (2)

Publication Number Publication Date
KR20060110733A true KR20060110733A (ko) 2006-10-25
KR101149959B1 KR101149959B1 (ko) 2012-07-03

Family

ID=47470659

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057012447A KR101149959B1 (ko) 2003-08-21 2004-07-29 중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을동기화하는 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR101149959B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101522881B1 (ko) * 2008-06-12 2015-05-26 엘지전자 주식회사 분산 컴파일 시스템 및 방법
CN117745968A (zh) * 2024-02-21 2024-03-22 中国有色金属工业昆明勘察设计研究院有限公司 一种创建地质模型的方法及系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100345966B1 (ko) 2000-07-10 2002-07-26 주식회사 마이엔진 인터넷을 이용한 데이터 통신 장비의 정보 통합 관리 및공유방법
US8001242B2 (en) * 2001-05-08 2011-08-16 International Business Machines Corporation Method for redirection of host data access to multiple non-host file systems or data stores

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101522881B1 (ko) * 2008-06-12 2015-05-26 엘지전자 주식회사 분산 컴파일 시스템 및 방법
CN117745968A (zh) * 2024-02-21 2024-03-22 中国有色金属工业昆明勘察设计研究院有限公司 一种创建地质模型的方法及系统
CN117745968B (zh) * 2024-02-21 2024-04-26 中国有色金属工业昆明勘察设计研究院有限公司 一种创建地质模型的方法及系统

Also Published As

Publication number Publication date
KR101149959B1 (ko) 2012-07-03

Similar Documents

Publication Publication Date Title
KR101120817B1 (ko) 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 관계 및 계층적 동기화서비스를 제공하는 시스템 및 방법
US7401104B2 (en) Systems and methods for synchronizing computer systems through an intermediary file system share or device
KR101041319B1 (ko) 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한정보 단위의 피어 대 피어 동기화를 위해 충돌 처리를제공하는 시스템 및 방법
RU2377646C2 (ru) Системы и способы для обеспечения услуг синхронизации для блоков информации, управляемых аппаратной/программной интерфейсной системой
US8166101B2 (en) Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
JP4583376B2 (ja) ハードウェア／ソフトウェアインタフェースシステムにより管理可能な情報のユニットに対する同期処理サービスを実現するシステムおよび方法
AU2003259961A1 (en) Systems and methods for interfacing application programs with an item-based storage platform
JP4580390B2 (ja) ハードウェア／ソフトウェアインターフェイスシステムによって管理可能な情報単位の拡張および継承のためのシステムおよび方法
JP4580389B2 (ja) 仲介ファイルシステム共有または仲介デバイスを介してコンピュータシステムを同期させるためのシステムおよび方法
JP4583375B2 (ja) 同期スキーマの実装のためのシステム
KR101149959B1 (ko) 중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을동기화하는 시스템 및 방법
KR101109390B1 (ko) 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 동기화 서비스를 제공하는시스템 및 방법

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee