KR101120817B1 - 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 관계 및 계층적 동기화서비스를 제공하는 시스템 및 방법 - Google Patents
하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 관계 및 계층적 동기화서비스를 제공하는 시스템 및 방법 Download PDFInfo
- Publication number
- KR101120817B1 KR101120817B1 KR1020057010790A KR20057010790A KR101120817B1 KR 101120817 B1 KR101120817 B1 KR 101120817B1 KR 1020057010790 A KR1020057010790 A KR 1020057010790A KR 20057010790 A KR20057010790 A KR 20057010790A KR 101120817 B1 KR101120817 B1 KR 101120817B1
- Authority
- KR
- South Korea
- Prior art keywords
- item
- relationship
- data
- change
- instance
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 96
- 230000008859 change Effects 0.000 claims abstract description 221
- 230000007246 mechanism Effects 0.000 claims description 35
- 238000013499 data model Methods 0.000 claims description 29
- 230000001360 synchronised effect Effects 0.000 claims description 26
- 239000013598 vector Substances 0.000 claims description 21
- 230000006399 behavior Effects 0.000 claims description 15
- 230000008520 organization Effects 0.000 claims description 14
- 238000000926 separation method Methods 0.000 claims description 4
- 238000012217 deletion Methods 0.000 abstract description 11
- 230000037430 deletion Effects 0.000 abstract description 11
- 239000008186 active pharmaceutical agent Substances 0.000 description 92
- 238000013507 mapping Methods 0.000 description 44
- 230000006870 function Effects 0.000 description 38
- 238000012423 maintenance Methods 0.000 description 29
- 238000010586 diagram Methods 0.000 description 28
- 230000008569 process Effects 0.000 description 27
- 238000003780 insertion Methods 0.000 description 23
- 230000037431 insertion Effects 0.000 description 23
- 238000004891 communication Methods 0.000 description 21
- 230000000875 corresponding effect Effects 0.000 description 15
- 230000009471 action Effects 0.000 description 14
- 238000012545 processing Methods 0.000 description 11
- 238000001514 detection method Methods 0.000 description 10
- 238000013459 approach Methods 0.000 description 9
- 238000013500 data storage Methods 0.000 description 9
- 238000007726 management method Methods 0.000 description 9
- 230000003287 optical effect Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 210000001072 colon Anatomy 0.000 description 5
- 239000002131 composite material Substances 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 150000001875 compounds Chemical class 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 239000000725 suspension Substances 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000009434 installation Methods 0.000 description 3
- 230000005055 memory storage Effects 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 230000000644 propagated effect Effects 0.000 description 3
- 238000006467 substitution reaction Methods 0.000 description 3
- 230000009466 transformation Effects 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 230000003542 behavioural effect Effects 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000011112 process operation Methods 0.000 description 2
- 230000009897 systematic effect Effects 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- PEDCQBHIVMGVHV-UHFFFAOYSA-N Glycerine Chemical compound OCC(O)CO PEDCQBHIVMGVHV-UHFFFAOYSA-N 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 238000012508 change request Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000001351 cycling effect Effects 0.000 description 1
- 238000005034 decoration Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000009429 electrical wiring Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012806 monitoring device Methods 0.000 description 1
- 239000010813 municipal solid waste Substances 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
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
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/178—Techniques for file synchronisation in 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/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/104—Peer-to-peer [P2P] networks
-
- 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
-
- 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/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
- H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Abstract
본 발명의 여러 실시예는 동기화 서비스를 제공하는 저장 플랫폼을 포함하는데, 이 서비스는 (i) 저장 플랫폼의 다수의 인스턴스(각각 그 자신의 데이터 저장소를 가짐)가 유연한 규칙 세트에 따라 그들의 콘텐츠의 일부들을 동기화하는 것을 허용하고, (ii) 제3자가 본 발명의 저장 플랫폼의 데이터 저장소를 독점 프로토콜을 구현하는 다른 데이터 소스들과 동기화할 수 있도록 기반 구조를 제공한다. 그러나, 많은 동기화 시나리오에서 충돌이 발생할 수 있다. 예컨대, A1 및 B2는 동일 변경 단위에 대해 이루어지는 변경들이거나, A1은 B2가 수정하고 있는 동일 변경 단위에 대한 삭제일 수 있다. 이러한 충돌들 중 일부는 본 명세서의 초기에 설명된 충돌 해결 옵션을 이용하여 해결될 수 있지만, 소정의 충돌들은 매우 어려운 문제를 일으키며, 이러한 문제들 및 그의 해결이 본 명세서에서 설명된다.
저장 플랫폼, 동기화 서비스, 애플리케이션 프로그래밍 인터페이스, 충돌, 변경
Description
<상호 참조>
본 출원은 2003년 10월 24일자로 출원된 "하드웨어/소프트웨어 인터페이스 시스템에 의해 정보 관리 가능 단위들에 대한 관계 및 계층적 동기화 서비스를 제공하는 시스템 및 방법"이라는 제목의 미국 특허 출원 번호 10/692,508; 2003년 8월 21일자로 출원된 "데이터의 체계화, 검색 및 공유를 위한 저장 플랫폼"이라는 제목의 미국 특허 출원 번호 10/646,646; 및 2003년 8월 21일자로 출원된 "데이터의 체계화, 검색 및 공유를 위한 저장 플랫폼"이라는 제목의 국제 출원 번호 PCT/US03/27419에 대한 우선권을 주장하며, 이들 출원의 개시 내용은 본 명세서에 참고로 반영되었다.
본 출원은 다음의 일반 양도된 출원들에 개시된 발명들과 내용이 관련되어 있으며, 이들 출원들의 내용은 본 명세서에 그 전체(및 편의를 위해 부분 요약됨)가 반영되어 있다: 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.
본 발명은 정보 저장 및 검색은 물론, 컴퓨터화된 시스템에서 상이한 타입의 데이터를 체계화하고, 검색하고, 공유하기 위한 액티브 저장 플랫폼에 관한 것이다. 구체적으로, 본 발명은 데이터 플랫폼의 다수의 인스턴스 사이의 데이터 동기화에 관한 것으로서, 보다 상세하게는 계층 구조화된 동기화 시스템의 이용에 관한 것이다.
개별 디스크 용량은 지난 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)"의 형태이다. 이에 대한 아주 분명한 많은 이유가 있지만(예컨대, 플랫폼 또는 데이터베이스가 불가지론적임), 종종 주목되지 않는 하나의 중요한 이유는 데이터베이스가 주요 비지니스 애플리케이션 벤더가 실제로 필요로 하는 정확한 추상화를 반드시 제공하지는 못한다는 것이다. 예컨대, 실세계는 "고객" 또는 "주문"과 같은 "항목들"(주문의 삽입된 "라인 항목"을 그 내부의 항목 및 그의 항목으로서 함께)에 대한 개념을 갖지만, 관계형 데이터베이스는 단지 테이블 및 행에 대해서만 말한다. 결과적으로, 애플리케이션은 (몇 가지 예를 들면) 항목 레벨에서 일관성, 로킹, 보안 및/또는 트리거의 양태를 갖기를 원할 수 있지만, 일반적으로 데이터베이스는 테이블/행 레벨에서만 이러한 기능을 제공한다. 이것은 각 항목이 데이터베이스에서 소정 테이블 내의 단일 행으로 맵핑되는 경우에는 훌륭하게 동작할 수 있지만, 다수의 라인 항목을 가진 주문의 경우, 항목이 실제로는 다수의 테이블로 맵핑되는 이유들이 존재할 수 있으며, 그러한 경우, 단순한 관계형 데이터베이스 시스템은 올바른 추상화를 전혀 제공하지 못한다. 결과적으로, 애플리케이션은 이러한 기본 추상화를 제공하기 위해 데이터베이스의 상부에 논리를 구축해야 한다. 즉, 기본 관계 모델은 보다 높은 레벨의 애플리케이션이 쉽게 개발될 수 있는 데이터 저장용의 충분한 플랫폼을 제공하지 못하는데, 이는 기본 관계 모델이 애플리케이션과 저장 시스템 사이에 간접 레벨을 필요로 하기 때문이다(여기서, 데이터의 시맨틱 구조는 소정의 인스턴스에서 애플리케이션에서만 볼 수 있다). 일부 데이터베이스 벤더들은 보다 높은 레벨의 기능을 그들의 제품 내에 구축하고 있지만(예컨대, 객체 관계 능력, 새로운 체계화 모델 등의 제공), 그 어느 것도 필요한 포괄적인 솔루션의 종류를 아직 제공하지 못하고 있는데, 진정으로 포괄적인 솔루션은 유용한 데이터 모델 추상화(예컨대, "항목", "확장", "관계" 등) 및 유용한 도메인 추상화(예컨대, "사람", "위치", "이벤트" 등) 양자를 제공하는 솔루션이다.
기존의 데이터 저장 및 데이터베이스 기술의 전술한 결함에 비추어, 컴퓨터 시스템에서 모든 타입의 데이터를 체계화하고, 검색하고, 공유할 수 있는 향상된 능력을 제공하는 새로운 저장 플랫폼, 즉 기존의 파일 시스템 및 데이터베이스 시스템을 넘어 데이터 플랫폼을 확장하고 확대하며, 모든 타입의 데이터에 대한 저장소가 되도록 설계된 저장 플랫폼이 필요하다. 본 발명은 본 명세서의 앞 부분에 참조로서 반영된 관련 발명들과 함께 이러한 요구를 만족시킨다.
다음의 요약은 본 명세서에 참조로 반영된 관련 발명("관련 발명")과 관련하여 설명되는 발명의 다양한 양태의 개요를 제공한다. 이 요약은 본 발명의 중요한 양태들 모두를 망라한 설명을 제공하는 것을 의도하지 않지 않으며, 본 발명의 범위를 한정하지도 않는다. 오히려, 이 요약은 뒤따르는 상세한 설명 및 도면에 대한 서론으로서 기능하도록 의도된다.
관련 발명은 물론 본 발명은 일반적으로, 데이터를 체계화하고, 검색하고, 공유하기 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 기존 파일 시스템 및 데이터베이스 시스템을 넘어 데이터 저장의 개념을 확장하고 확대하며, 구조화된 데이터, 구조화되지 않은 데이터 또는 반 구조화된 데이터를 포함하는 모든 타입의 데이터에 대한 저장소가 되도록 설계되어 있다.
본 발명의 저장 플랫폼은 데이터베이스 엔진 상에 구현된 데이터 저장소를 포함한다. 데이터베이스 엔진은 객체 관계 확장들을 가진 관계형 데이터베이스 엔진을 포함한다. 데이터 저장소는 데이터의 체계화, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델을 구현한다. 특정 타입의 데이터는 스키마에서 기술되며, 플랫폼은 새로운 타입의 데이터(본질적으로 스키마에 의해 제공되는 기본 타입의 서브타입)를 정의하도록 스키마 세트를 확장하기 위한 메카니즘을 제공한다. 동기화 능력은 사용자들 또는 시스템들 사이에서 데이터의 공유를 쉽게 한다. 종래의 파일 시스템에 대한 제한 없이 이러한 종래의 파일 시스템과 데이터 저장소의 연동을 허용하는 파일 시스템 유사 능력이 제공된다. 변경 추적 메카니즘은 데이터 저장소에 대한 변경을 추적하는 능력을 제공한다. 저장 플랫폼은 또한 애플리케이션이 저장 플랫폼의 전술한 능력들 모두에 액세스할 수 있고 스키마에 기술된 데이터에 액세스할 수 있게 하는 한 세트의 애플리케이션 프로그램 인터페이스를 포함한다.
데이터 저장소에 의해 구현되는 데이터 모델은 항목, 요소 및 관계에 의하여 데이터 저장의 단위들을 정의한다. 항목은 데이터 저장소에 저장할 수 있는 데이터의 단위이며, 하나 이상의 요소 및 관계를 포함할 수 있다. 요소는 하나 이상의 필드(본 명세서에 속성으로도 지칭됨)를 포함하는 타입의 인스턴스이다. 관계는 두 항목 사이의 링크이다. (본 명세서에서 사용되는 이들 및 다른 특정 용어들은 이들을 매우 근접하게 사용되는 다른 용어들과 분리하기 위해 대문자화될 수 있지만, 대문자화된 용어, 예컨대 "Item"과 대문자화되지 않은 동일 용어, 예컨대 "item"을 구별할 의도는 전혀 없으며, 어떠한 차이도 가정되거나 암시되지 않아야 한다.)
컴퓨터 시스템은 또한 각 항목이 하드웨어/소프트웨어 인터페이스 시스템에 의해 조작될 수 있는 개별 저장 가능한 정보 단위를 구성하는 복수의 항목; 상기 항목들에 대한 체계적인 구조를 구성하는 항목 폴더; 및 복수의 항목을 조작하기 위한 하드웨어/소프트웨어 인터페이스 시스템을 포함하며, 각 항목은 적어도 하나의 항목 폴더에 속하며, 둘 이상의 항목 폴더에 속할 수 있다.
항목 또는 항목의 속성 값들 중 일부는 영구 저장소로부터 도출되는 것과 달리 동적으로 계산될 수 있다. 즉, 하드웨어/소프트웨어 인터페이스 시스템은 항목이 저장되는 것을 요구하지 않으며, 현재의 항목들의 세트를 열거할 수 있는 능력, 또는 저장 플랫폼에 대한 그의 식별자가 주어질 때 항목을 검색할 수 있는 능력(애플리케이션 프로그래밍 인터페이스 또는 API를 설명하는 섹션에서 보다 상세히 설명됨)과 같은 소정의 동작들이 지원되는데, 예컨대 항목은 셀 전화의 현재 위치 또는 온도 센서에 읽은 온도일 수 있다. 하드웨어/소프트웨어 인터페이스 시스템은 다수의 항목을 조작할 수 있으며, 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리되는 다수의 관계에 의해 상호 접속되는 항목들을 더 포함할 수 있다.
컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템은 하드웨어/소프트웨어 인터페이스 시스템이 이해하고 소정의 예측 가능한 방식으로 직접 처리할 수 있는 한 세트의 코어 항목을 정의하기 위한 코어 스키마를 더 포함한다. 다수의 항목을 조작하기 위하여, 컴퓨터 시스템은 상기 항목들을 다수의 관계와 상호접속시키며, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 상기 관계들을 관리한다.
저장 플랫폼의 API는 저장 플랫폼 스키마 세트에 정의된 각 항목, 항목 확장 및 관계에 대한 데이터 클래스를 제공한다. 또한, API는 데이터 클래스들에 대한 공통 거동 세트를 정의하고 데이터 클래스들과 함께 저장 플랫폼 API에 대한 기본 프로그래밍 모델을 제공하는 한 세트의 프레임워크 클래스를 제공한다. 저장 플랫폼 API는, 기반 데이터베이스 엔진의 질의 언어의 상세로부터 애플리케이션 프로그래머들을 격리시키는 방식으로, 애플리케이션 프로그래머들이 데이터 저장소 내의 항목들의 다양한 속성에 기초하여 질의를 형성하는 것을 가능하게 하는 간략화된 질의 모델을 제공한다. 저장 플랫폼 API는 또한 애플리케이션 프로그램에 의해 이루어진 항목에 대한 변경을 수집한 후, 데이터 저장소가 구현되는 데이터베이스 엔진(또는 임의 종류의 저장 엔진)에 의해 요구되는 정확한 갱신들 내에 이들을 체계화한다. 이것은 애플리케이션 프로그래머들이 메모리 내에서 항목을 변경하는 것을 가능하게 하며, 데이터 저장소 갱신들의 복잡성을 API로 넘기는 것을 가능하게 한다.
본 발명의 저장 플랫폼은 그의 공통 저장 기초 및 스키마화된 데이터를 통해 소비자, 지식 노동자 및 기업에 보다 효율적인 애플리케이션의 개발을 가능하게 한다. 이것은 그의 데이터 모델에 고유한 능력들을 이용할 수 있게 해줄 뿐 아니라 기존 파일 시스템 및 데이터베이스 액세스 방법을 수용하고 확장하는 풍부하고 확장 가능한 API를 제공한다.
이러한 상호 관련된 발명들의 최우선 구조의 일부로서(상세한 설명의 섹션 II에서 상세히 설명됨), 본 발명은 특히 동기화 API(상세한 설명의 섹션 III에서 상세히 설명됨)와 관련된다. 본 발명의 다른 특징 및 이점은 아래의 발명의 상세한 설명 및 첨부 도면으로부터 명백해질 것이다.
전술한 요약 및 아래의 발명의 상세한 설명은 첨부된 도면들과 함께 읽을 때 더 잘 이해된다. 본 발명을 설명하기 위해, 본 발명의 다양한 실시예가 도면들에 도시되어 있지만, 본 발명은 개시된 특정 방법 및 수단으로 한정되지 않는다.
도 1은 본 발명의 양태들이 구현될 수 있는 컴퓨터 시스템을 나타내는 블록도.
도 2는 3개의 컴포넌트 그룹, 즉 하드웨어 컴포넌트, 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트 및 애플리케이션 프로그램 컴포넌트로 분할된 컴퓨터 시스템을 나타내는 블록도.
도 2A는 파일 기반 오퍼레이팅 시스템에서 디렉토리 내의 폴더들에 그룹화된 파일들에 대한 종래의 트리 기반 계층 구조를 나타내는 도면.
도 3은 저장 플랫폼을 나타내는 블록도.
도 4는 항목들, 항목 폴더들 및 카테고리들 사이의 구조 관계를 나타내는 도면.
도 5A는 항목의 구조를 나타내는 블록도.
도 5B는 도 5A의 항목의 복합 속성 타입을 나타내는 블록도.
도 5C는 복합 타입들이 더 설명된(명시적으로 리스트된) "위치" 항목을 나타내는 블록도.
도 6A는 항목을 기본 스키마에서 발견되는 그 항목의 서브타입으로서 나타내는 도면.
도 6B는 상속 타입들이 명시적으로 리스트된(직접 속성 외에) 도 6A의 서브타입 항목을 나타내는 블록도.
도 7은 2개의 최상위 레벨 클래스 타입, 즉 Item 및 PropertyBase를 포함하는 기본 스키마, 및 이로부터 도출되는 추가적인 기본 스키마 타입들을 나타내는 블록도.
도 8A는 코어 스키마 내의 항목들을 나타내는 블록도.
도 8B는 코어 스키마 내의 속성 타입들을 나타내는 블록도.
도 9는 항목 폴더, 그의 회원 항목들, 및 항목 폴더와 그의 회원 항목들 사 이의 상호접속 관계를 나타내는 블록도.
도 10은 카테고리(다시, 항목 자체), 그의 회원 항목들, 및 카테고리와 그의 회원 항목들 사이의 상호접속 관계를 나타내는 블록도.
도 11은 저장 플랫폼의 데이터 모델의 참조 타입 계층 구조를 나타내는 도면.
도 12는 관계들이 어떻게 분류되는지를 나타내는 도면.
도 13은 통지 메카니즘을 나타내는 도면.
도 14는 2개의 트랜잭션이 모두 동일한 B 트리 내에 새로운 레코드를 삽입하는 예를 나타내는 도면.
도 15는 데이터 변경 검출 프로세스를 나타내는 도면.
도 16은 예시적인 디렉토리 트리를 나타내는 도면.
도 17은 디렉토리 기반 파일 시스템의 기존 폴더가 저장 플랫폼 데이터 저장소 내로 이동하는 예를 나타내는 도면.
도 18은 포함 폴더의 개념을 나타내는 도면.
도 19는 저장 플랫폼 API의 기본 구조를 나타내는 도면.
도 20은 저장 플랫폼 API 스택의 다양한 컴포넌트를 개략적으로 나타내는 도면.
도 21A는 예시적인 콘택 항목 스키마의 도면.
도 21B는 도 21A의 예시적인 콘택 항목 스키마에 대한 요소들의 도면.
도 22는 저장 플랫폼 API의 실행시간 프레임워크를 나타내는 도면.
도 23은 "FindAll" 동작의 실행을 나타내는 도면.
도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타내는 도면.
도 25는 파일 API가 기초로 하는 스키마를 나타내는 도면.
도 26은 데이터 보안을 위해 사용되는 액세스 마스크 포맷을 나타내는 도면.
도 27(a, b 및 c 부분)은 동일하게 보호되는 새로운 보안 영역이 기존 보안 영역으로부터 분리되는 것을 나타내는 도면.
도 28은 항목 검색 뷰의 개념을 나타내는 도면.
도 29는 예시적인 항목 계층 구조를 나타내는 도면.
도 30A는 인터페이스 Interface1을 제1 및 제2 코드 세그먼트들이 통신하는 콘딧으로서 나타내는 도면.
도 30B는 인터페이스가, 시스템의 제1 및 제2 코드 세그먼트들이 매체(M)를 통해 통신하는 것을 가능하게 하는 인터페이스 객체들 I1 및 I2를 포함하는 것으로 나타내는 도면.
도 31A는 인터페이스 Interface1에 의해 제공되는 기능이 어떻게 인터페이스의 통신을 변환하도록 다수의 인터페이스 Interface1A, Interface1B, Interface1C로 세분되는지를 나타내는 도면.
도 31B는 인터페이스 I1에 의해 제공되는 기능이 어떻게 다수의 인터페이스 I1a, I1b, I1c로 세분되는지를 나타내는 도면.
도 32A는 의미 없는 파라미터 정밀도가 무시되거나 임의의 파라미터로 대체 될 수 있는 시나리오를 나타내는 도면.
도 32B는 인터페이스가 인터페이스를 무시하거나 파라미터를 추가하도록 정의된 대체 인터페이스에 의해 대체되는 시나리오를 나타내는 도면.
도 33A는 제1 및 제2 코드 세그먼트들이 이들 모두를 포함하는 모듈로 병합되는 시나리오를 나타내는 도면.
도 33B는 인터페이스의 일부 또는 전부가 병합된 인터페이스를 형성하기 위해 다른 인터페이스 내에 인라인 작성될 수 있는 시나리오를 나타내는 도면.
도 34A는 미들웨어의 하나 이상의 부분들이 어떻게 제1 인터페이스 상의 통신들을 하나 이상의 상이한 인터페이스에 적응시키기 위해 이들을 변환할 수 있는지를 나타내는 도면.
도 34B는 코드 세그먼트가 어떻게 하나의 인터페이스로부터 통신을 수신하지만 기능을 제2 및 제3 인터페이스로 전송하기 위해 인터페이스와 함께 도입될 수 있는지를 나타내는 도면.
도 35A는 JIT(Just-In-Time) 컴파일러가 어떻게 하나의 코드 세그먼트로부터의 통신을 다른 코드 세그먼트로 변환하는지를 나타내는 도면.
도 35B는 하나 이상의 인터페이스를 동적으로 재기입하는 JIT 메소드가 상기 인터페이스를 동적으로 인수 분해하거나 변경하기 위해 적용될 수 있음을 나타내는 도면.
도 36은 공통 데이터 저장소의 3개의 인스턴스 및 이들을 동기화하는 컴포넌트들을 나타내는 도면.
도 37은 어떻게 상태가 계산되는지, 또는 그와 관련된 메타데이터가 교환되는지를 알지 못하는 단순한 어댑터를 가정하는 본 발명의 일 실시예를 나타내는 도면.
도 38A-D는 변경들에 대한 예외 및 솔루션을 하이라이트하기 위해 순차 변경 열거 방법을 이용하여 어떻게 변경들이 추적되고, 열거되고, 동기화되는지를 나타내는 도면.
목차
I. 서론
A. 예시적인 컴퓨팅 환경
B. 통상의 파일 기반 저장
II. 데이터의 체계화, 검색 및 공유를 위한 WINFS 저장 플랫폼
A. 용어집
B. 저장 플랫폼의 개요
C. 데이터 모델
1. 항목
2. 항목 식별
3. 항목 폴더 및 카테고리
4. 스키마
a) 기본 스키마
b) 코어 스키마
5. 관계
a) 관계 선언
b) 유지 관계
c) 삽입 관계
d) 참조 관계
e) 규칙 및 제한
f) 관계 순서화
6. 확장성
a) 항목 확장
b) 중첩 요소 타입 확장
D. 데이터베이스 엔진
1. UDT를 이용한 데이터 저장소 구현
2. 항목 맵핑
3. 확장 맵핑
4. 중첩 요소 맵핑
5. 객체 식별
6. SQL 객체 명명
7. 칼럼 명명
8. 검색 뷰
a) 항목
(1) 마스터 항목 검색 뷰
(2) 타입화된 항목 검색 뷰
b) 항목 확장
(1) 마스터 확장 검색 뷰
(2) 타입화된 확장 검색 뷰
c) 중첩 요소
d) 관계
(1) 마스터 관계 검색 뷰
(2) 관계 인스턴스 검색 뷰
e)
9. 갱신
10. 변경 추적 및 툼스톤(tombstone)
a) 변경 추적
(1) "마스터" 서비스 뷰에서의 변경 추적
(2) "타입화된" 검색 뷰에서의 변경 추적
b) 툼스톤
(1) 항목 툼스톤
(2) 확장 툼스톤
(3) 관계 툼스톤
(4) 툼스톤 소거
11. 헬퍼 API 및 함수
a) 함수 [System.Storage].GetItem
b) 함수 [System.Storage].GetExtension
c) 함수 [System.Storage].GetRelationship
12. 메타데이터
a) 스키마 메타데이터
b) 인스턴스 메타데이터
E. 보안
F. 통지 및 변경 추적
G. 통상의 파일 시스템 연동성
H. 저장 플랫폼 API
III. 동기화 API
A. 동기화의 개요
1. 저장 플랫폼 대 저장 플랫폼 동기화
a) 동기화(Sync) 제어 애플리케이션
b) 스키마 주석
c) Sync 구성
(1) 공동체 폴더-맵핑
(2) 프로파일
(3) 스케쥴
d) 충돌 처리
(1) 충돌 검출
(a) 지식 기반 충돌
(b) 제한 기반 충돌
(2) 충돌 처리
(a) 자동 충돌 해결
(b) 충돌 로깅
(c) 충돌 검사 및 해결
(d) 사본의 수렴 및 충돌 해결의 전파
2. 비 저장 플랫폼 데이터 저장소에 대한 동기화
a) 동기화 서비스
(1) 변경 열거
(2) 변경 적용
(3) 충돌 해결
b) 어댑터 구현
3. 보안
4. 관리성
B. 동기화 API의 개요
1. 일반 용어
2. 동기화 API의 원리
C. 동기화 API 서비스
1. 변경 열거
2. 변경 적용
3. 샘플 코드
4. API 동기화의 방법
IV. 결론
I. 서론
본 발명의 내용은 법적인 요건을 만족시키도록 구체적으로 설명된다. 그러나, 설명 자체는 본 발명의 범위를 한정하려는 의도는 아니다. 오히려, 본 발명자는 특허 청구된 내용이 다른 현재 또는 미래의 기술과 함께 본 명세서에서 설명된 것들과 다른 단계들 또는 유사한 단계들의 조합을 포함하도록 다른 방식으로 구현될 수도 있음을 고려하였다. 더욱이, "단계"라는 용어가 본 명세서에서 이용 방법들의 상이한 요소들을 의미하기 위해 사용될 수 있지만, 이 용어는 개별 단계들의 순서가 명시적으로 기술될 때를 제외하고는 다양한 단계들 사이의 임의의 특정 순서를 의미하는 것으로 해석되지 않아야 한다.
A. 예시적인 컴퓨팅 환경
본 발명의 다양한 실시예는 컴퓨터 상에서 실행될 수 있다. 도 1 및 아래의 설명은 본 발명이 구현될 수 있는 적절한 컴퓨팅 환경의 간략한 전반적인 설명을 제공하고자 의도된다. 요구되지는 않지만, 본 발명의 다양한 양태는 클라이언트 워크스테이션 또는 서버와 같은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행 가능 명령과 일반적으로 관련하여 설명될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 더욱이, 본 발명은 핸드헬드 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그래머블 소비자 전자장치, 네트워크 PC, 미니 컴퓨터, 메인프레임 컴퓨터 등을 포함하는 다른 컴퓨터 시스템 구성에서 실시될 수 있다. 본 발명은 또한 통신 네트워크를 통해 링크 된 원격 프로세싱 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 양자에 위치할 수 있다.
도 1에 도시된 바와 같이, 예시적인 범용 컴퓨팅 시스템은 프로세싱 유닛(21), 시스템 메모리(22), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(21)에 결합하는 시스템 버스(23)를 포함하는 통상의 개인용 컴퓨터(20) 등을 포함한다. 시스템 버스(23)는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 다양한 버스 아키텍처 중 어느 하나를 이용한 로컬 버스를 포함하는 여러 타입의 버스 아키텍처 중 하나일 수 있다. 시스템 메모리는 ROM(24) 및 RAM(25)을 포함한다. 예컨대 시동 중에 개인용 컴퓨터(20) 내의 요소들 사이에서 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 BIOS(26)는 ROM(24)에 저장된다. 개인용 컴퓨터(20)는 도시되지 않은 하드 디스크에 대한 판독 및 기입을 위한 하드 디스크 드라이브(27), 도시되지 않은 분리식 자기 디스크(29)에 대한 판독 및 기입을 위한 자기 디스크 드라이브(28), 및 CD-ROM 또는 다른 광학 매체와 같은 분리식 광 디스크(31)에 대한 판독 및 기록을 위한 광 디스크 드라이브(30)를 더 포함할 수 있다. 하드 디스크 드라이브(27), 자기 디스크 드라이브(28) 및 광 디스크 드라이브(30)는 각각 하드 디스크 드라이브 인터페이스(32), 자기 디스크 드라이브 인터페이스(33) 및 광 디스크 드라이브 인터페이스(34)에 의해 시스템 버스(23)에 접속된다. 드라이브들 및 관련 컴퓨터 판독 가능 매체들은 컴퓨터 판독 가능 명령들, 데이터 구조, 프로그램 모듈 및 다른 개인용 컴퓨터(20)용 데이터의 불휘발성 저장을 제공 한다. 본 명세서에 설명되는 예시적인 환경이 하드 디스크, 분리식 자기 디스크(29) 및 분리식 광 디스크(21)를 사용하고 있지만, 자기 카세트, 플래시 메모리 카드, DVD, 베르누이 카트리지, RAM, ROM 등과 같이 컴퓨터에 의해 액세스될 수 있는 데이터를 저장할 수 있는 다른 타입의 컴퓨터 판독 가능 매체도 예시적인 컴퓨팅 환경에서 사용될 수 있다는 것을 당업자들은 이해해야 한다. 마찬가지로, 예시적인 환경은 열 센서 및 보안 또는 화재 경보 시스템과 같은 많은 타입의 모니터링 장치, 및 다른 정보 소스를 포함할 수 있다.
오퍼레이팅 시스템(35), 하나 이상의 애플리케이션 프로그램(36), 다른 프로그램 모듈(37) 및 프로그램 데이터(38)를 포함하는 다수의 프로그램 모듈이 하드 디스크, 자기 디스크(29), 광 디스크(31), ROM(24) 또는 RAM(25)에 저장될 수 있다. 사용자는 키보드(40) 및 포인팅 장치(42)와 같은 입력 장치를 통해 개인용 컴퓨터(20)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(도시되지 않음)는 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 및 다른 입력 장치들은 종종 시스템 버스에 결합되는 직렬 포트 인터페이스(46)를 통해 프로세싱 유닛(21)에 접속되지만, 병렬 포트, 게임 포트 또는 USB와 같은 다른 인터페이스를 통해 접속될 수 있다. 모니터(47) 또는 다른 타입의 표시 장치도 비디오 어댑터(48)와 같은 인터페이스를 통해 시스템 버스(23)에 접속된다. 모니터(47) 외에, 개인용 컴퓨터는 일반적으로 스피커 및 프린터와 같은 다른 주변 출력 장치(도시되지 않음)를 포함한다. 도 1의 예시적인 시스템은 또한 호스트 어댑터(55), SCSI 버스(56) 및 SCSI 버스(56)에 접속된 외부 저장 장치(62)를 포함한다.
개인용 컴퓨터(20)는 원격 컴퓨터(49)와 같은 하나 이상의 원격 컴퓨터에 대한 논리 접속을 이용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(49)는 다른 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 도 1에는 메모리 저장 장치(50)만이 도시되어 있지만, 일반적으로 개인용 컴퓨터(20)와 관련하여 위에 설명된 요소들의 대부분 또는 전부를 포함한다. 도 1에 도시된 논리 접속은 LAN(51) 및 WAN(52)을 포함한다. 이러한 네트워킹 환경은 사무실, 기업 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적이다.
개인용 컴퓨터(20)는 LAN 네트워킹 환경에서 사용될 때 네트워크 인터페이스 또는 어댑터(53)를 통해 LAN(51)에 접속된다. 개인용 컴퓨터(20)는 WAN 네트워킹 환경에서 사용될 때 일반적으로 인터넷과 같은 WAN(52)을 통해 통신을 설정하기 위한 모뎀 또는 다른 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(54)은 직렬 포트 인터페이스(46)를 통해 시스템 버스(23)에 접속된다. 네트워크 환경에서, 개인용 컴퓨터(20)와 관련하여 설명된 프로그램 모듈 또는 그 부분들은 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 사이에 통신 링크를 설정하기 위한 다른 수단이 사용될 수 있다는 것을 이해할 것이다.
도 2의 블록도에 도시된 바와 같이, 컴퓨터 시스템(200)은 크게 세 개의 컴포넌트 그룹, 즉 하드웨어 컴포넌트(202), 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204), 및 애플리케이션 프로그램 컴포넌트(206)(본 명세서에서 소정의 상 황에서 "사용자 컴포넌트" 또는 "소프트웨어 컴포넌트"로도 지칭됨)로 분류될 수 있다.
컴퓨터 시스템(200)의 다양한 실시예에서, 그리고 도 1을 다시 참조하면, 하드웨어 컴포넌트(202)는 CPU(21), 메모리(ROM(24) 및 RAM(25)), BIOS(26), 및 특히 키보드(40), 마우스(42), 모니터(47) 및/또는 프린터(도시되지 않음)와 같은 다양한 입출력(I/O) 장치를 포함할 수 있다. 하드웨어 컴포넌트(202)는 컴퓨터 시스템(200)을 위한 기본 물리적 기반 구조를 포함한다.
애플리케이션 프로그램 컴포넌트(206)는 컴파일러, 데이터베이스 시스템, 워드 프로세서, 비지니스 프로그램, 비디오 게임 등을 포함하지만 이에 한하지 않는 다양하나 소프트웨어 프로그램을 포함한다. 애플리케이션 프로그램은 문제를 해결하고, 솔루션을 제공하고, 다양한 사용자(기계, 다른 컴퓨터 시스템 및/또는 최종 사용자)의 데이터를 처리하기 위해 컴퓨터 자원을 이용하는 수단을 제공한다.
하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204)는 대부분의 경우 그 자체가 쉘 및 커널을 포함하는 오퍼레이팅 시스템(OS)을 포함한다(그리고, 몇몇 실시예에서는 오퍼레이팅 시스템만으로 이루어진다). OS는 애플리케이션 프로그램과 컴퓨터 하드웨어 사이에서 중개자로서 동작하는 특수 프로그램이다. 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204)는 또한 가상 기계 관리자(VMM), 공통 언어 실행 시간(CLR) 또는 그의 기능적 등가물, 자바 가상 기계(JVM) 또는 그의 기능적 등가물, 또는 컴퓨터 시스템 내의 오퍼레이팅 시스템에 대신하거나 추가적으로 다른 그러한 소프트웨어 컴포넌트를 포함할 수 있다. 하드웨어/소프트웨어 인 터페이스 시스템의 목적은 사용자가 애플리케이션 프로그램을 실행할 수 있는 환경을 제공하는 것이다. 임의의 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 하드웨어를 효율적인 방식으로 사용하는 것은 물론 컴퓨터 시스템을 사용하기 편리하게 만드는 것이다.
하드웨어/소프트웨어 인터페이스 시스템은 일반적으로 시동시에 컴퓨터 시스템에 로딩된 후, 컴퓨터 시스템 내의 모든 애플리케이션 시스템을 관리한다. 애플리케이션 프로그램은 API를 통해 서비스를 요구함으로써 하드웨어/소프트웨어 인터페이스 시스템과 상호작용한다. 몇몇 애플리케이션 프로그램은 최종 사용자가 명령 언어 또는 GUI와 같은 사용자 인터페이스를 통해 하드웨어/소프트웨어 인터페이스 시스템과 상호작용하는 것을 가능하게 한다.
하드웨어/소프트웨어 인터페이스 시스템은 통상적으로 애플리케이션에 대한 다양한 서비스를 수행한다. 다수의 프로그램이 동시에 실행될 수 있는 멀티 태스킹 하드웨어/소프트웨어 인터페이스 시스템에서, 하드웨어/소프트웨어 인터페이스 시스템은 어느 애플리케이션이 어떤 순서로 실행되어야 하는지, 그리고 교대를 위해 다른 애플리케이션으로 스위칭하기 전에 각각의 애플리케이션에 대해 얼마나 많은 시간이 할당되어야 하는지를 결정한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 다수의 애플리케이션 사이에서의 내부 메모리의 할당을 관리하며, 하드 디스크, 프린터 및 다이얼-업 포트와 같은 부착된 하드웨어 장치에 대한 입출력을 처리한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 동작의 상태 및 발생했을 수 있는 임의의 에러에 관한 메시지를 각각의 애플리케이션(및 소정의 경우 최 종 사용자)으로 전송한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 배치 작업(예컨대 인쇄)의 관리를 오프로딩하여, 개시 애플리케이션이 이 작업으로부터 자유롭게 되어 다른 처리 및/또는 동작을 재개하게 할 수 있다. 병렬 처리를 제공할 수 있는 컴퓨터 상에서, 하드웨어/소프트웨어 인터페이스 시스템은 또한 프로그램이 2개 이상의 프로세서에서 동시에 실행되도록 프로그램의 분할을 관리한다.
하드웨어/소프트웨어 인터페이스 시스템 쉘(여기서는 단순히 "쉘"로서 지칭됨)은 하드웨어/소프트웨어 인터페이스 시스템에 대한 대화식 최종 사용자 인터페이스이다. (쉘은 "명령 해석기" 또는 오퍼레이팅 시스템에서 "오퍼레이팅 시스템 쉘"로도 지칭될 수 있다.) 쉘은 애플리케이션 및/또는 최종 사용자에 의해 직접 액세스될 수 있는 하드웨어/소프트웨어 인터페이스 시스템의 외곽 계층이다. 쉘과 달이, 커널은 하드웨어 컴포넌트와 직접 상호작용하는 하드웨어/소프트웨어 인터페이스 시스템의 내부 계층이다.
본 발명의 다양한 실시예가 컴퓨터화된 시스템에 특히 적합한 것으로 생각되지만, 본 명세서에서 이러한 실시예들로 본 발명을 한정하려는 어떤 것도 의도되지 않는다. 이와 달리, 여기서 사용되는 "컴퓨터 시스템"이라는 용어는 장치들이 사실상 전자, 기계, 논리 또는 가상 장치인지에 관계없이 정보를 저장하고 처리할 수 있고, 그리고/또는 저장된 정보를 이용하여 장치 자체의 거동 또는 실행을 제어할 수 있는 임의의 장치 및 모든 장치를 포함하는 것으로 의도된다.
B. 통상의 파일 기반 저장
오늘날 대부분의 컴퓨터 시스템에서, "파일"은 하드웨어/소프트웨어 인터페이스 시스템은 물론 애플리케이션 프로그램, 데이터 세트 등을 포함할 수 있는 저장 가능한 정보의 단위이다. 현대의 모든 하드웨어/소프트웨어 인터페이스 시스템(윈도우, 유닉스, 리눅스, 맥 OS, 가상 기계 시스템 등)에서, 파일은 하드웨어/소프트웨어 인터페이스 시스템에 의해 조작될 수 있는 정보(예컨대, 데이터, 프로그램 등)의 기본적인 개별(저장 가능 및 검색 가능) 단위이다. 파일 그룹은 일반적으로 폴더에 체계화된다. 마이크로소프트 윈도우, 매킨토시 OS, 및 다른 하드웨어/소프트웨어 인터페이스 시스템에서, 폴더는 정보의 단일 단위로서 검색되고, 이동되고, 조작될 수 있는 파일들의 집합이다. 또한, 이러한 폴더는 디렉토리라는 트리 기반 계층 구조에 체계화된다(후술함). DOS, z/OS 및 대부분의 유닉스 기반 오퍼레이팅 시스템과 같은 소정의 다른 하드웨어/소프트웨어 인터페이스 시스템에서, "디렉토리" 및/또는 "폴더"라는 용어는 상호 교환 가능하게 사용되며, 초기의 애플 컴퓨터 시스템(예컨대, 애플 IIe)은 디렉토리 대신에 "카탈로그"라는 용어를 사용했지만, 여기서 사용되는 바와 같이, 이들 용어 모두는 동의어이고 상호 교환 가능한 것으로 간주되며, 계층적 정보 저장 구조들 및 이들의 폴더 및 파일 컴포넌트에 대한 모든 다른 등가 용어 및 참조를 더 포함하는 것으로 의도된다.
통상적으로, 디렉토리(폴더들의 디렉토리)는, 파일들이 폴더 내에 그룹화되고, 또한 폴더들이 디렉토리 트리를 포함하는 상대적 노드 위치에 따라 배열되는 트리 기반 계층 구조이다. 예컨대, 도 2A에 도시된 바와 같이, DOS 기반 파일 시스템 기본 폴더(또는 "루트 디렉토리")(212)는 다수의 폴더(214)를 포함할 수 있는 데, 이들 각각은 또한 추가적인 폴더들(특정 폴더의 "서브폴더")(216)을 포함할 수 있으며, 이들의 각각도 추가 폴더(218)를 포함할 수 있다(이것은 무한 반복될 수 있다). 이들 폴더 각각은, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 폴더 내의 개별 파일들이 트리 계층 구조 내의 그들의 위치 외에는 어떠한 공통점도 갖지 않을지라도 하나 이상의 파일(220)을 가질 수 있다. 놀랍지 않게도, 파일들을 폴더 계층 구조 내에 체계화하는 이러한 접근법은 이들 파일을 저장하는 데 사용되는 일반적인 저장 매체(예컨대, 하드 디스크, 플로피 디스크, CD-ROM 등)의 물리적 체계화를 간접적으로 반영한다.
전술한 것 외에, 각 폴더는 그의 서브 폴더 및 그의 파일들에 대한 컨테이너인데, 즉 각 폴더는 그의 서브 폴더 및 파일을 소유한다. 예컨대, 폴더가 하드웨어/소프트웨어 인터페이스 시스템에 의해 삭제될 때, 그 폴더의 서브 폴더 및 파일들도 삭제된다(각 서브 폴더의 경우, 그 자신의 서브 폴더 및 파일들을 반복적으로 더 포함한다). 마찬가지로, 각 파일은 일반적으로 단 하나의 폴더에 의해 소유되며, 파일이 복사될 수 있고, 사본이 다른 폴더에 위치될 수 있지만, 파일의 사본 자체는 원본과의 직접적인 연결을 갖지 않는 상이하고 개별적인 단위이다(예를 들어, 원본 파일에 대한 변경은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서는 사본 파일에 반영되지 않는다). 이러한 관계에 따라서, 파일 및 폴더는 특성상 "물리적"인데, 이는 폴더가 물리적 컨테이너와 같이 취급되고, 파일이 이 컨테이너 내의 상이하고 개별적인 물리적 요소로 취급되기 때문이다.
II. 데이터의 체계화, 검색 및 공유를 위한 WINFS 저장 플랫폼
본 발명은 여기서 초기에 설명된 바와 같이 참조로 반영된 관련 발명들과 함께 데이터를 체계화하고, 검색하고, 공유하기 위한 저장 플랫폼에 관련된다. 본 발명의 저장 플랫폼은 전술한 기존 파일 시스템 및 데이터베이스 시스템의 종류들을 넘어 데이터 플랫폼을 확장하고 확대하며, 항목이라고 하는 새로운 데이터 형태를 포함하는 모든 데이터 타입에 대한 저장소가 되도록 설계된다.
A. 용어집
본 명세서 및 청구범위에서 사용되는 아래의 용어는 다음의 의미를 갖는다.
- "항목(Item)"은 하드웨어/소프트웨어 인터페이스 시스템에 의해 액세스될 수 있는 저장 가능 정보의 단위이며, 단순 파일과 달리 하드웨어/소프트웨어 인터페이스 시스템 쉘에 의해 최종 사용자에게 노출되는 모든 객체에 걸쳐서 공통으로 지원되는 기본 속성 세트를 가진 객체이다. 항목은 또한 새로운 속성 및 관계가 도입되는 것을 허용하는 특징들을 포함하는 모든 항목 타입에 걸쳐 공통으로 지원되는 속성 및 관계를 갖는다(후술함).
- "오퍼레이팅 시스템(OS)"은 애플리케이션 프로그램과 컴퓨터 하드웨어 사이에서 중개자로서 기능하는 특수 프로그램이다. OS는 대부분의 경우 쉘 및 커널을 포함한다.
- "하드웨어/소프트웨어 인터페이스 시스템"은 컴퓨터 시스템의 기반 하드웨어 컴포넌트들과 컴퓨터 시스템 상에서 실행되는 애플리케이션들 사이의 인터페이 스로서 기능하는 소프트웨어 또는 하드웨어 및 소프트웨어의 조합이다. 하드웨어/소프트웨어 인터페이스 시스템은 일반적으로 오퍼레이팅 시스템을 포함한다(그리고, 몇몇 실시예에서는 오퍼레이팅 시스템만으로 구성된다). 하드웨어/소프트웨어 인터페이스 시스템은 또한 가상 기계 관리자(VMM), 공통 언어 실행 시간(CLR) 또는 그의 기능적 등가물, 자바 가상 기계(JVM) 또는 그의 기능적 등가물, 또는 컴퓨터 시스템 내의 오퍼레이팅 시스템에 대신하거나 추가적으로 다른 그러한 소프트웨어 컴포넌트를 포함할 수 있다. 하드웨어/소프트웨어 인터페이스 시스템의 목적은 사용자가 애플리케이션 프로그램을 실행할 수 있는 환경을 제공하는 것이다. 임의의 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 하드웨어를 효율적인 방식으로 사용하는 것은 물론 컴퓨터 시스템을 사용하기 편리하게 만드는 것이다.
B. 저장 플랫폼의 개요
도 3을 참조하면, 저장 플랫폼(300)은 데이터베이스 엔진(314) 상에서 구현되는 데이터 저장소(302)를 포함한다. 일 실시예에서, 데이터베이스 엔진은 객체 관계 확장들을 가진 관계형 데이터베이스 엔진을 포함한다. 일 실시예에서, 관계형 데이터베이스 엔진(314)은 마이크로소프트 SQL 서버 관계형 데이터베이스 엔진을 포함한다. 데이터 저장소(302)는 데이터의 체계화, 검색, 공유, 동기화, 및 보안을 지원하는 데이터 모델(304)을 구현한다. 특정 타입의 데이터는 스키마(340)와 같은 스키마에서 기술되며, 저장 플랫폼(300)은 후술하는 바와 같이 이러한 스키마를 전개하는 것은 물론, 이러한 스키마를 확장하기 위한 도구(346)를 제공한 다.
데이터 저장소(302) 내에 구현되는 변경 추적 메카니즘(306)은 데이터 저장소에 대한 변경을 추적할 수 있는 능력을 제공한다. 데이터 저장소(302)는 또한 보안 능력(308) 및 승진/강등 능력(310)을 제공하는데, 이들 양자는 후술한다. 데이터 저장소(302)는 또한 다른 저장 플랫폼 컴포넌트 및 저장 플랫폼을 이용하는 애플리케이션 프로그램(예컨대, 애플리케이션 프로그램 350a, 350b, 350c)에게 데이터 저장소(302)의 능력들을 노출시키기 위한 한 세트의 API(312)를 제공한다. 본 발명의 저장 플랫폼은 애플리케이션 프로그램(350a, 350b, 350c)과 같은 애플리케이션 프로그램이 전술한 저장 플랫폼의 모든 능력에 액세스하고 스키마에 기술된 데이터에 액세스하는 것을 가능하게 하는 API(322)를 더 포함한다. 저장 플랫폼 API(322)는 OLE DB API(324) 및 마이크로소프트 윈도우 Win32 API(326)와 같은 다른 API와 함께 애플리케이션 프로그램에 의해 사용될 수 있다.
본 발명의 저장 플랫폼은 사용자들 또는 시스템들 사이의 데이터 공유를 쉽게 하는 동기화 서비스(330)를 포함하는 다양한 서비스(328)를 애플리케이션 프로그램에 제공할 수 있다. 예컨대, 동기화 서비스(330)는 데이터 저장소(302)와 동일한 포맷을 가진 다른 데이터 저장소(340)와의 연동은 물론, 다른 포맷을 가진 데이터 저장소(342)에 대한 액세스를 가능하게 할 수 있다. 저장 플랫폼(300)은 또한 윈도우 NTFS 파일 시스템(318)과 같은 기존 파일 시스템과 데이터 저장소(302)의 연동을 허용하는 파일 시스템 능력을 제공한다. 적어도 몇몇 실시예에서, 저장 플랫폼(300)은 또한 데이터가 다른 시스템 상에서 동작하는 것을 가능하게 하고 다 른 시스템과의 상호작용을 가능하게 하는 추가적인 능력을 애플리케이션 프로그램에게 제공할 수 있다. 이러한 능력들은 정보 에이전트 서비스(334) 및 통지 서비스(332)와 같은 추가 서비스(328)의 형태는 물론, 다른 유틸리티(336)의 형태로 구현될 수 있다.
적어도 몇몇 실시예에서, 저장 플랫폼은 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템 내에 구현되거나, 그의 통합 부분을 형성한다. 예컨대, 그리고 제한 없이, 본 발명의 저장 플랫폼은 오퍼레이팅 시스템, 가상 기계 관리자(VMM), CLR 또는 그의 기능적 등가물, 또는 JVM 또는 그의 기능적 등가물 내에 구현되거나, 그의 통합 부분을 형성할 수 있다. 본 발명의 저장 플랫폼은 그의 공통 저장 기초 및 스키마화된 데이터를 통해 소비자, 지식 노동자 및 기업을 위한 보다 효율적인 애플리케이션 개발을 가능하게 한다. 저장 플랫폼은 그의 데이터 모델에 고유한 능력들을 이용할 수 있게 만들 뿐만 아니라 기존의 파일 시스템 및 데이터베이스 액세스 방법을 수용하고 확장하는 풍부하고 확장 가능한 프로그래밍 표면 영역을 제공한다.
아래의 설명에서, 그리고 다양한 도면들에서, 본 발명의 저장 플랫폼(300)은 "WinFS"로 지칭될 수 있다. 그러나, 이러한 저장 플랫폼을 지칭하는 명칭의 사용은 단지 설명의 편의를 위한 것이며, 어떠한 식으로도 제한하려는 의도는 아니다.
C. 데이터 모델
본 발명의 저장 플랫폼(300)의 데이터 저장소(302)는 저장소에 상주하는 데 이터의 체계화, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델을 구현한다. 본 발명의 데이터 모델에서, "항목"은 저장 정보의 기본 단위이다. 데이터 모델은 후술하는 바와 같이 항목 및 항목 확장을 선언하고, 항목들에 대한 관계를 설정하며, 항목들을 항목 폴더 내에 그리고 카테고리 내에 체계화하기 위한 메카니즘을 제공한다.
데이터 모델은 2개의 기본 메카니즘, 즉 타입 및 관계에 의존한다. 타입은 타입의 인스턴스의 형태를 지배하는 포맷을 제공하는 구조이다. 포맷은 순서화된 속성들의 세트로서 표현된다. 속성은 주어진 타입의 값 또는 값들의 세트에 대한 명칭이다. 예컨대, USPostalAddress 타입은 Street, City, Zip, State의 속성들을 가질 수 있는데, 여기서 Street, City 및 State는 스트링 타입이고, Zip은 Int32 타입이다. Street는 다가(즉 한 세트의 값들)이어서, 어드레스가 Street 속성에 대해 둘 이상의 값을 갖는 것을 허용할 수 있다. 시스템은 다른 타입의 구축에 사용될 수 있는 소정의 기본 타입을 정의하는데, 이들은 String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DataTime, Decimal 및 GUID를 포함한다. 타입의 속성들은 기본 타입들 중 어느 하나 또는 (아래에 설명되는 소정의 제한과 함께) 구축된 타입들 중 어느 하나를 이용하여 정의될 수 있다. 예컨대, 좌표 및 어드레스 속성을 가진 위치 타입이 정의될 수 있는데, 어드레스 속성은 전술한 바와 같이 USPostalAddress 타입이다. 속성들은 또한 필요하거나 선택적일 수 있다.
관계는 두 타입의 인스턴스들의 세트들 사이에 선언될 수 있으며, 이들 사이 의 맵핑을 표현한다. 예컨대, 사람 타입과, 어느 사람이 어느 위치에 살고 있는지를 정의하는 LivesAt이라고 하는 위치 타입 사이에 관계가 선언될 수 있다. 관계는 명칭, 2개의 엔드 포인트, 즉 소스 엔드 포인트 및 타겟 엔드 포인트를 갖는다. 관계는 또한 순서화된 속성들의 세트를 가질 수 있다. 소스 및 타겟 엔드 포인트들 양자는 명칭 및 타입을 갖는다. 예컨대, LivesAt 관계는 사람 타입의 거주자라고 하는 소스 및 위치 타입의 주거지라고 하는 타겟을 가지며, 또한 거주자가 주거지에 산 기간을 나타내는 StartDate 및 EndDate 속성을 갖는다. 사람은 시간에 따라 다수의 주거지에 살 수 있고, 주거지는 다수의 거주자를 가질 수 있으며, 따라서 StartDate 및 EndDate 정보를 넣을 가장 가능성 있는 장소는 관계 자체이다.
관계는 엔드 포인트 타입으로 주어진 타입에 의해 제한되는 인스턴스들 사이의 맵핑을 정의한다. 예컨대, LivesAt 관계는 자동차가 거주자인 관계일 수 없는데, 이는 자동차가 사람이 아니기 때문이다.
데이터 모델은 타입들 사이의 서브 타입-수퍼 타입 관계의 정의를 허용한다. BaseType 관계로도 알려진 서브 타입-수퍼 타입 관계는 타입 A가 타입 B에 대한 BaseType인 경우에 B의 모든 인스턴스가 A의 인스턴스이기도 한 경우가 존재해야 하는 방식으로 정의된다. 이것을 표현하는 또 하나의 방법은 B에 따르는 모든 인스턴스는 A도 따라야 한다는 것이다. 예컨대, A가 스트링 타입의 속성 명칭을 갖고, B가 Int16 타입의 속성 나이를 갖는 경우, B의 임의의 인스턴스는 명칭 및 나이 양자를 가져야 한다. 타입 계층 구조는 루트에 단일 수퍼 타입을 가진 트리로서 생각될 수 있다. 루트로부터의 분기들은 제1 레벨의 서브 타입들을 제공하며, 이 레벨의 분기들은 제2 레벨의 서브 타입들을 제공하는 등, 이것은 그 자체가 어떠한 서브 타입도 갖지 않는 말단 서브 타입까지 계속된다. 트리는 균일한 깊이를 갖는 것으로 제한되지 않으나, 어떠한 순환도 포함할 수 없다. 주어진 타입이 제로 또는 많은 서브 타입 및 제로 또는 하나의 수퍼 타입을 가질 수 있다. 주어진 인스턴스는 많아야 하나의 타입 및 이 타입의 수퍼 타입에 따를 수 있다. 또 하나의 방법으로서, 트리 내에 임의의 레벨의 주어진 인스턴스에 대해, 이 인스턴스는 그 레벨에 있는 많아야 하나의 서브 타입에 따를 수 있다. 타입은 그 타입의 인스턴스들이 그 타입의 서브 타입의 인스턴스이기도 해야 하는 경우 추상적이라고 일컬어진다.
1. 항목
항목은 단순 파일과 달리 저장 플랫폼에 의해 최종 사용자 또는 애플리케이션 프로그램에게 노출되는 모든 객체에 걸쳐 공통으로 지원되는 속성들의 기본 세트를 가진 객체인 저장 가능 정보의 단위이다. 항목은 또한 후술하는 바와 같이 새로운 속성 및 관계가 도입되는 것을 허용하는 특징들을 포함하는 모든 항목 타입에 걸쳐 공통으로 지원되는 속성 및 관계를 갖는다.
항목은 복사, 삭제, 이동, 개방, 인쇄, 백업, 복원, 복제 등과 같은 일반 동작에 대한 객체이다. 항목은 저장 및 검색될 수 있는 단위이며, 저장 플랫폼에 의해 조작되는 저장 가능 정보의 모든 형태는 항목, 항목의 속성 또는 항목 사이의 관계로서 존재하는데, 이들 각각은 후술한다.
항목은 콘택, 사람, 서비스, 위치, 문서(모든 다양한 종류) 등과 같은 데이터의 실세계의 쉽게 이해될 수 있는 단위를 나타낸다. 도 5A는 항목의 구조를 나타내는 블록도이다. 항목의 고유 명칭은 "위치"이다. 항목의 적격 명칭은 이 항목의 구조가 코어 스키마 내에 특정 타입의 항목으로 정의되어 있음을 나타내는 "Core.Location"이다. (코어 스키마는 후술한다.)
위치 항목은 EAddress, MetropolitanRegion, Neighborhood 및 PostalAddress를 포함하는 다수의 속성을 갖는다. 각각에 대한 속성의 특정 타입은 속성 명칭 직후에 표시되며, 콜론(":")에 의해 속성 명칭과 구분된다. 타입 명칭의 우측에, 그 속성 타입에 대해 허용되는 값들의 수가 대괄호들("[]") 사이에 표시되는데, 콜론 우측의 별표("*")는 미지정 및/또는 비제한 수("다수")를 나타낸다. 콜론 우측의 "1"은 기껏해야 하나의 값이 존재할 수 있다는 것을 나타낸다. 콜론 좌측의 제로("0")는 속성이 선택적이라는 것을 나타낸다(아무 값도 존재하지 않을 수 있다). 콜론 좌측의 "1"은 적어도 하나의 값이 존재해야 한다는 것을 나타낸다(속성이 필요하다). Neighborhood 및 MetropolitanRegion은 모두 미리 정의된 데이터 타입 또는 "단순 타입"(그리고 본 명세서에서 대문자화 없이 표시됨)인 "nvarchar"(또는 등가물) 타입이다. 그러나, EAddress 및 PostalAddress는 각각 EAddress 및 PostalAddress 타입의 정의된 타입 또는 "복합 타입"(여기서 대문자화에 의해 표시됨)의 속성들이다. 복합 타입은 하나 이상의 단순 데이터 타입 및/또는 다른 복합 타입으로부터 도출되는 타입이다. 항목의 속성들에 대한 복합 타입은 또한 "중첩 요소"를 구성하는데, 이는 복합 타입의 상세가 그의 속성들을 정의하기 위해 직접 항목 내에 중첩되고, 복합 타입에 관한 정보가 이들 속성을 가진 항목과 함께 (후술하는 바와 같이 항목의 경계 내에) 유지되기 때문이다. 이러한 타입화의 개념은 공지되어 있으며, 당업자들에게 쉽게 이해된다.
도 5B는 복합 속성 타입인 PostalAddress 및 EAddress를 나타내는 블록도이다. PostalAddress 속성 타입은 PostalAddress 속성 타입의 항목이 0 또는 1의 City 값, 0 또는 1의 CountryCode 값, 0 또는 1의 MailStop 값 및 임의 수(0 내지 다수)의 PostalAddressType 등등을 갖는 것으로 예상될 수 있다. 이러한 방식으로, 항목 내의 특정 속성에 대한 데이터의 형상이 그에 따라 정의된다. EAddress 속성 타입은 도시된 바와 유사하게 정의된다. 본 명세서에서는 선택적으로 사용되지만, 위치 항목에서 복합 타입을 표현하는 또 하나의 방법은 항목을 그 안에 리스트된 각각의 복합 타입의 개별 속성들과 함께 드로잉하는 것이다. 도 5C는 복합 타입들이 더 기술되어 있는 위치 항목을 나타내는 블록도이다. 그러나, 이러한 도 5C의 위치 항목의 대체 표현은 도 5A에 도시된 것과 정확히 동일한 항목에 대한 것이라는 것을 이해해야 한다. 본 발명의 저장 플랫폼은 또한 서브 타입화를 허용하는데, 이에 따라 하나의 속성 타입이 다른 속성 타입의 서브 타입이 될 수 있다(하나의 속성 타입은 다른 부모 속성 타입의 속성을 상속한다).
속성들 및 이들의 속성 타입과 유사하지만 다르게, 항목들은 서브 타입화의 주체일 수도 있는 그들 자신의 항목 타입들을 고유하게 표현한다. 즉, 본 발명의 여러 실시예에서의 저장 플랫폼은 항목이 다른 항목의 서브 타입이 되는 것을 허용한다(이에 따라 하나의 항목은 다른 부모 항목의 속성을 상속한다). 더욱이, 본 발 명의 다양한 실시예에서, 모든 항목은 기본 스키마에서 발견되는 제1 및 기본 항목 타입인 "항목" 항목 타입의 서브 타입이다. (기본 스키마도 후술된다). 도 6A는 기본 스키마에서 발견되는 Item 항목 타입의 서브 타입인 항목, 이 인스턴스 내의 위치 항목을 나타낸다. 이 도면에서, 화살표는 위치 항목이(모든 다른 항목과 같이) Item 항목 타입의 서브 타입임을 나타낸다. 모든 다른 항목이 도출되는 기본 항목인 Item 항목 타입은 ItemId 및 다양한 타임 스탬프와 같은 다수의 중요한 속성을 가지며, 이에 의해 오퍼레이팅 시스템 내의 모든 항목의 표준 속성을 정의한다. 이 도면에서, 이러한 Item 항목 타입의 속성들은 위치에 의해 상속되며, 이에 의해 위치의 속성이 된다.
Item 항목 타입으로부터 상속된 위치 항목의 속성을 표현하는 또 하나의 방법은 위치를 그 안에 리스트된 부모 항목으로부터의 각각의 속성 타입의 개별 속성들과 함께 드로잉하는 것이다. 도 6B는 직접 속성 외에 상속된 타입들이 기술되는 위치 항목을 나타내는 블록도이다. 이 도면에서는 위치가 그의 속성들 모두와 함께, 즉 이 도면과 도 5A 양쪽에 도시된 직접 속성, 및 이 도면에는 도시되어 있으나 도 5A에는 없는(반면, 도 5A에서는, 위치 항목이 Item 항목 타입의 서브 타입이라는 것을 화살표로 표시함으로써 이들 속성이 참조된다) 상속된 속성과 함께 도시되어 있지만, 이 위치 항목은 도 5A에 도시된 것과 동일한 항목이라는 점에 유의하고 이해해야 한다.
항목은 독립 객체이며, 따라서 항목을 삭제할 경우, 항목의 직접 및 상속 속성 모두가 또한 삭제된다. 마찬가지로, 항목을 검색할 때, 수신되는 것은 항목 및 그의 모든 직접 및 상속 속성(그의 복합 속성 타입에 관한 정보 포함)이다. 본 발명의 소정 실시예는 특정 항목을 검색할 때 속성들의 서브 세트를 요구하는 것을 가능하게 하지만, 이러한 많은 실시예의 디폴트는 검색시 항목을 그의 모든 직접 및 상속 속성들과 함께 제공하는 것이다. 더욱이, 항목의 속성은 또한 그 항목의 타입의 기존 속성에 새로운 속성을 추가함으로써 확장될 수 있다. 이러한 "확장"은 그후 항목의 진정한 속성이 되며, 그 항목의 서브 타입은 확장 속성을 자동으로 포함할 수 있다.
항목의 "경계"는 그의 속성(복합 속성 타입, 확장 등을 포함)에 의해 표현된다. 항목의 경계는 또한 복사, 삭제, 이동, 생성 등과 같이 항목에 대해 수행되는 동작의 한계를 표현한다. 예컨대, 본 발명의 여러 실시예에서, 항목이 복사될 때, 그 항목의 경계 내의 모든 것이 또한 복사된다. 각 항목에 대해, 경계는 다음을 포함한다:
- 항목의 항목 타입, 및 항목이 다른 항목의 서브 타입인 경우(모든 항목이 기본 스키마 내의 단일 항목 및 항목 타입으로부터 도출되는 본 발명의 여러 실시예의 경우와 같이), 임의의 적용 가능한 서브 타입 정보(즉, 부모 항목 타입에 관한 정보). 복사되는 원본 항목이 다른 항목의 서브 타입인 경우, 사본도 그 동일 항목의 서브 타입일 수 있다.
- 있을 경우, 항목의 복합 타입 속성 및 확장. 원본 항목이 복합 타입(원시 또는 확장)의 속성을 가진 경우, 사본도 동일한 복합 타입을 가질 수 있다.
- 항목의 "소유 관계"에 대한 기록, 즉 이 항목(소유 항목)이 어떤 다른 항 목(타겟 항목)을 소유하고 있는지를 나타내는 항목 자신의 리스트. 이것은 후술하는 바와 같이 항목 폴더와 특히 관련이 있으며, 규칙은 아래에서 모든 항목이 적어도 하나의 항목 폴더에 속해야 하는 것을 지시한다. 더욱이, 후술하는 삽입 항목과 관련하여, 삽입 항목은 이 삽입 항목이 복사, 삭제 등과 같은 동작을 위해 삽입되는 항목의 일부로서 간주된다.
2. 항목 식별
항목은 ItemID에 의해 글로벌 항목 공간 내에서 고유하게 식별된다. Base.Item 타입은 항목에 대한 식별자를 저장하는 타입 GUID의 필드 ItemID를 정의한다. 항목은 데이터 저장소(302) 내에 정확하게 하나의 식별자를 가져야 한다.
항목 참조는 항목을 찾고 식별하기 위한 정보를 포함하는 데이터 구조이다. 데이터 모델에서, 모든 항목 참조 타입이 도출되는 ItemReference라는 명칭의 추상 타입이 정의된다. ItemReference 타입은 Resolve라는 명칭의 가상 메소드를 정의한다. Resolve 메소드는 ItemReference를 분석하고, 항목을 리턴한다. 이 메소드는 참조가 주어질 때 항목을 검색하는 함수를 구현하는 ItemReference의 구체적인 서브 타입들에 의해 무시된다. Resolve 메소드는 저장 플랫폼 API(322)의 일부로서 호출된다.
ItemIDReference는 ItemReference의 서브 타입이다. 이것은 Locator 및 ItemID 필드를 정의한다. Locator 필드는 항목 도메인을 명명(즉, 식별)한다. 이것은 항목 도메인에 대한 Locator의 값을 분석할 수 있는 로케이터 분석 메소드에 의해 처리된다. ItemID 필드는 ItemID 타입이다.
ItemPathReference는 Locator 및 Path 필드를 정의하는 ItemReference의 특수 형태이다. Locator 필드는 항목 도메인을 식별한다. 이것은 항목 도메인에 대한 Locator의 값을 분석할 수 있는 로케이터 분석 메소드에 의해 처리된다. Path 필드는 Locator에 의해 제공되는 항목 도메인에서 루트된 저장 플랫폼 명칭 공간 내의 (상대) 경로를 포함한다.
이러한 타입의 참조는 세트 동작에서 사용될 수 없다. 참조는 일반적으로 경로 분석 프로세스를 통해 분석되어야 한다. 저장 플랫폼 API(322)의 Resolve 메소드는 이러한 기능을 제공한다.
전술한 참조 형태는 도 11에 도시된 참조 타입 계층 구조를 통해 표현된다. 이러한 타입으로부터 상속되는 추가적인 참조 타입들이 스키마에서 정의될 수 있다. 이들은 관계 선언에서 타겟 필드의 타입으로서 사용될 수 있다.
3. 항목 폴더 및 카테고리
후술하는 바와 같이, 항목 그룹은 항목 폴더(파일 폴더와 혼동하지 말 것)라고 하는 특수 항목 내에 체계화된다. 그러나, 대부분의 파일 시스템과 달리, 항목은 둘 이상의 항목 폴더에 속할 수 있으며, 따라서 항목이 하나의 항목 폴더에서 액세스되고 수정된 때, 이 수정된 항목은 다른 항목 폴더로부터 직접 액세스될 수 있다. 본질적으로, 항목에 대한 액세스는 상이한 항목 폴더들로부터 이루어질 수 있지만, 실제로 액세스되는 것은 실제로는 동일한 항목이다. 그러나, 항목 폴더는 그의 회원 항목들 모두를 반드시 소유하지는 않거나, 단순히 다른 폴더와 함께 항목들을 공유할 수 있으며, 따라서 항목 폴더의 삭제가 반드시 항목의 삭제로 귀착되는 것은 아니다. 그럼에도, 본 발명의 여러 실시예에서, 항목은 적어도 하나의 항목 폴더에 속해야 하며, 따라서 특정 항목에 대한 유일한 항목 폴더가 삭제된 경우, 몇몇 실시예에서는 항목이 자동으로 삭제되거나, 다른 실시예에서는 항목이 자동으로 디폴트 항목 폴더(예컨대, 다양한 파일-폴더 기반 시스템에서 사용되는 유사 명칭 폴더들과 개념적으로 유사한 "Trash Can" 항목 폴더)의 회원이 된다.
또한 후술하는 바와 같이, 항목은 또한 (a) 항목 타입(또는 타입들), (b) 특정 직접 또는 상속 속성(또는 속성들), 또는 (c) 항목 속성에 대응하는 특정 값(또는 값들)과 같은 공통 기술 특성에 기초하는 카테고리에 속할 수 있다. 예컨대, 개인 콘택 정보에 대한 특정 속성을 포함하는 항목은 자동으로 Contact 카테고리에 속할 수 있으며, 콘택 정보 속성을 가진 임의의 항목도 자동으로 이 카테고리에 속할 것이다. 마찬가지로, "New York City" 값의 위치 속성을 갖는 임의의 항목은 자동으로 NewYorkCity 카테고리에 속할 수 있다.
카테고리는 개념적으로 항목 폴더와 다른데, 이는 항목 폴더가 서로 관련되지 않은(즉 공통 기술 특성이 없는) 항목들을 포함할 수 있는 반면, 카테고리 내의 각 항목은 그 카테고리에 대해 기술되는 공통 타입, 속성 또는 값(공통성)을 가지며, 카테고리 내의 다른 항목들에 대한, 그리고 그들 사이에서의 관계에 대한 기초를 형성하는 것은 이러한 공통성이기 때문이다. 더욱이, 특정 폴더 내의 항목의 회원은 그 항목의 임의의 특정 양태에 강제로 기초하지 않는 반면, 소정 실시예에 서 카테고리에 절대적으로 관련된 공통성을 가진 모든 항목은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 자동으로 그 카테고리의 회원이 될 수 있다. 개념적으로, 카테고리는 또한 특정 질의(예를 들어, 데이터베이스와 관련하여)의 결과에 기초하는 회원을 갖는 가상 항목 폴더로 간주될 수도 있으며, 따라서 이러한 질의의 조건(카테고리의 공통성에 의해 정의됨)을 만족시키는 항목들은 카테고리의 회원을 포함한다.
도 4는 항목들, 항목 폴더들 및 카테고리들 사이의 구조 관계를 나타낸다. 다수의 항목(402, 404, 406, 408, 410, 412,414, 416, 418, 420)은 다양한 항목 폴더(422, 424, 426, 428, 430)의 회원이다. 몇몇 항목들은 둘 이상의 항목 폴더에 속할 수 있는데, 예를 들어 항목 402는 항목 폴더들 422 및 424에 속한다. 몇몇 항목들, 예컨대 항목 402, 404, 406, 408, 410 및 412는 또한 하나 이상의 카테고리 432, 434 및 436의 회원이며, 다른 항목들, 예를 들어 항목들 414, 416, 418 및 420은 어떠한 카테고리에도 속하지 않을 수 있다(그러나, 이것은 임의의 속성의 소유가 자동으로 카테고리 내의 회원을 의미하고, 따라서 항목이 임의의 카테고리의 회원이 되지 않기 위해서는 완전히 특징이 없어야 하는 소정의 실시예에서 거의 가능하지 않다). 폴더들의 계층 구조와 달리, 카테고리 및 항목 폴더 양자는 도시된 바와 같은 방향 그래프와 보다 유사한 구조를 갖는다. 임의의 이벤트에서, 항목, 항목 폴더, 및 카테고리는 모두 항목(항목 타입은 상이함)이다.
파일, 폴더 및 디렉토리와 달리, 본 발명의 항목, 항목 폴더 및 카테고리는 특성상 "물리적"이 아닌데, 이는 이들이 물리적 컨테이너의 개념적 등가를 갖지 않 으며, 따라서 항목들은 둘 이상의 위치에 존재할 수 있기 때문이다. 항목들이 둘 이상의 항목 폴더 위치에 존재할 수 있고 카테고리 내에 체계화될 수 있는 능력은 현재 이 분야에서 이용할 수 있는 것을 넘어서, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 향상되고 풍부한 데이터 조작 및 저장 구조 능력을 제공한다.
4. 스키마
a) 기본 스키마
항목의 생성 및 사용을 위한 보편적 기초를 제공하기 위하여, 본 발명의 저장 플랫폼의 다양한 실시예는 항목 및 속성을 생성하고 체계화하기 위한 개념적 프레임워크를 설정하는 기본 스키마를 포함한다. 기본 스키마는 항목 및 속성의 소정의 특수 타입들, 및 서브 타입들이 더 도출될 수 있는 이러한 특수 기초 타입들의 특징들을 정의한다. 이러한 기본 스키마의 사용은 프로그래머가 개념적으로 항목들(및 이들 각각의 타입들)과 속성들(및 이들 각각의 타입들)을 구별하는 것을 허용한다. 더욱이, 기본 스키마는 모든 항목(및 이들에 대응하는 항목 타입)이 기본 스키마 내의 기본 항목(및 이에 대응하는 항목 타입)으로부터 도출될 때 모든 항목이 소유할 수 있는 속성들의 기본 세트를 설명한다.
도 7에 도시된 바와 같이, 그리고 본 발명의 여러 실시예와 관련하여, 기본 스키마는 3개의 최상위 레벨 타입, 즉 Item, Extension 및 PropertyBase를 정의한다. 도시된 바와 같이, 항목 타입은 기본 "항목" 항목 타입의 속성들에 의해 정의된다. 이와 달리, 최상위 레벨 속성 타입 "PropertyBase"는 미리 정의된 속성을 갖지 않으며, 단지 모든 다른 속성 타입이 도출되고, 도출된 모든 속성 타입이 상호 관련되는(단일 속성 타입으로부터 공동으로 도출됨) 앵커일 뿐이다. 확장 타입 속성은 확장이 어느 항목을 확장하는지는 물론, 항목이 다수의 확장을 가질 수 있을 때 하나의 확장을 다른 확장과 구별할 수 있는 식별자를 정의한다.
ItemFolder는 항목으로부터 상속된 속성들 외에 그의 회원들(있을 경우)에 대한 링크를 설정하기 위한 관계를 특징으로 하는 Item 항목 타입의 서브 타입이며, IdentityKey 및 Property는 PropertyBase의 서브 타입이다. 또한, CategoryRef는 IdentityKey의 서브 타입이다.
b) 코어 스키마
본 발명의 저장 플랫폼의 다양한 실시예는 최상위 레벨 항목 타입 구조에 대한 개념적 프레임워크를 제공하는 코어 스키마를 더 포함한다. 도 8A는 코어 스키마 내의 항목을 나타내는 블록도이고, 도 8B는 코어 스키마 내의 속성 타입을 나타내는 블록도이다. 파일-폴더 기반 시스템에서 상이한 확장자(*.com, *.exe, *.bat, *.sys 등) 및 다른 기준을 가진 파일들 사이의 차이는 코어 스키마의 함수와 유사하다. 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서, 코어 스키마는, 직접(항목 타입에 의해) 또는 간접으로(항목 서브 타입에 의해) 항목 기반 하드웨어/소프트웨어 인터페이스 시스템이 이해하고 소정의 예측 가능한 방식으로 직접 처리할 수 있는 하나 이상의 코어 스키마 항목 타입으로 모든 항목을 특징화하는 한 세트의 코어 항목 타입을 정의한다. 미리 정의된 항목 타입은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가장 공통적인 항목을 반영하며, 따라서 코어 스키마를 포함하는 미리 정의된 항목 타입을 이해하는 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 일정 레벨의 효율성이 얻어진다.
소정 실시예에서, 코어 스키마는 확장 가능하지 않은데, 즉 코어 스키마의 일부인 미리 정의되고 도출된 특정 항목 타입들을 제외하고는 기본 스키마 내의 항목 타입으로부터 어떠한 추가적인 항목 타입도 직접 서브 타입화될 수 없다. 코어 스키마에 대한 확장을 방지함으로써(즉, 코어 스키마에 새로운 항목의 추가를 방지함으로써), 저장 플랫폼은 코어 스키마 항목 타입들의 사용을 지시하는데, 이는 모든 후속 항목 타입이 반드시 코어 스키마 항목 타입의 서브 타입이기 때문이다. 이러한 구조는 추가적인 항목 타입을 정의함에 있어서 합리적인 정도의 유연성을 가능하게 하면서 미리 정의된 코어 항목 타입 세트를 갖는 이익도 유지할 수 있게 한다.
본 발명의 다양한 실시예에서, 그리고 도 8A를 참조하면, 코어 스키마에 의해 지원되는 특정 항목 타입은 다음 중 하나 이상을 포함한다.
- 카테고리: 이 항목 타입(및 이로부터 도출되는 서브 타입)의 항목들은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 유효한 카테고리를 나타낸다.
- 일용품: 값을 식별할 수 있는 항목
- 장치: 정보 처리 능력을 지원하는 논리 구조를 가진 항목
- 문서: 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 해석되지 않는 대신 문서 타입에 대응하는 애플리케이션 프로그램에 의해 해석되는 콘텐츠를 가진 항목
- 이벤트: 환경에서 소정의 발생을 기록하는 항목
- 위치: 물리적 위치(예컨대, 지리적 위치)를 나타내는 항목
- 메시지: 둘 이상의 원리(아래 정의됨) 사이의 통신 항목
- 본인(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)는 항목과 관련된 관계를 노출시키기 위한 메카니즘을 제공한다.
다음은 관계 선언의 일례이다:
이것은 참조 관계의 일례이다. 관계는 소스 참조에 의해 참조되는 사람 항목이 존재하지 않는 경우 생성될 수 없다. 또한, 사람 항목이 삭제되면, 사람과 조직 사이의 관계 인스턴스는 삭제된다. 그러나, 조직 항목이 삭제되면, 관계는 삭제되지 않고 현수 상태가 된다.
b) 유지 관계
유지 관계는 타겟 항목의 참조 수 기반 수명 관리를 모델링하는 데 사용된 다.
항목은 0개 이상의 항목에 대한 관계의 소스 엔드 포인트일 수 있다. 삽입된 항목이 아닌 항목은 하나 이상의 유지 관계의 타겟일 수 있다.
타겟 엔드 포인트 참조 타입은 ItemIDReference이어야 하며, 관계 인스턴스와 동일한 저장소 내의 항목을 참조해야 한다.
유지 관계는 타겟 엔드 포인트의 수명 관리를 이행한다. 유지 관계 인스턴스 및 이것이 목표로 하는 항목의 생성은 최소 동작(atomic operation)이다. 동일 항목을 목표로 하는 추가적인 유지 관계 인스턴스가 생성될 수 있다. 타겟 엔드 포인트로서 주어진 항목을 갖는 최종 유지 관계 인스턴스가 삭제되면, 타겟 항목도 삭제된다.
관계 선언에서 지정되는 엔드 포인트 항목의 타입은 일반적으로 관계의 인스턴스가 생성될 때 강제된다. 엔드 포인트 항목의 타입은 관계가 설정된 후에는 변경될 수 없다.
유지 관계들은 항목 명칭 공간의 형성에 중요한 역할을 한다. 이들은 소스 항목에 대한 타겟 항목의 명칭을 정의하는 "명칭" 속성을 포함한다. 이러한 상대적 명칭은 주어진 항목을 소스로 하는 모든 유지 관계에 대해 고유하다. 루트 항목에서 주어진 항목까지의 상대적 명칭들의 순서화된 리스트는 항목에 대한 완전한 명칭을 형성한다.
유지 관계는 방향 비순환 그래프(DAG)를 형성한다. 유지 관계가 생성될 때, 시스템은 순환이 생성되지 않는 것을 보장함으로써 항목 명칭 공간이 DAG를 형성하 는 것을 보장한다.
유지 관계가 타겟 항목의 수명을 제어하는 반면, 타겟 엔드 포인트 항목의 동작 일관성을 제어하지 못한다. 타겟 항목은 유지 관계를 통해 타겟 항목을 소유하는 항목으로부터 동작면에서 독립적이다. 유지 관계의 소스인 항목에 대한 복사, 이동, 백업 및 다른 동작은 동일 관계의 타겟인 항목에 영향을 주지 못하는데, 예를 들면, 즉 폴더 항목의 백업은 폴더 내의 모든 항목(FolderMember 관계의 타겟들)을 자동으로 백업하지 못한다.
다음은 유지 관계의 일례이다.
FolderMember 관계는 일반적인 항목들의 집합으로서의 폴더의 개념을 가능하게 한다.
c) 삽입 관계
삽입 관계는 타겟 항목의 수명의 배타적인 제어의 개념을 모델링한다. 삽입 관계는 복합 항목들의 개념을 가능하게 한다.
삽입 관계 인스턴스 및 이것이 목표로 하는 항목의 생성은 최소 동작이다. 항목은 0개 이상의 삽입 관계의 소스일 수 있다. 그러나, 항목은 하나 및 단 하나의 삽입 관계의 타겟일 수 있다. 삽입 관계의 타겟인 항목은 유지 관계의 타겟이 될 수 없다.
타겟 엔드 포인트 참조 타입은 ItemIDReference이어야 하며, 관계 인스턴스와 동일한 데이터 저장소 내의 항목을 참조해야 한다.
관계 선언에서 지정되는 엔드 포인트 항목의 타입은 일반적으로 관계의 인스턴스가 생성될 때 강제된다. 엔드 포인트 항목의 타입은 관계가 설정된 후에는 변경될 수 없다.
삽입 관계는 타겟 엔드 포인트의 동작 일관성을 제어한다. 예컨대, 항목의 일련화 동작은 그 항목은 물론 그들의 타겟들 모두로부터 나온 모든 삽입 관계의 일련화를 포함할 수 있으며, 항목의 복사는 또한 그의 모든 삽입된 항목을 복사한다.
다음은 선언의 일례이다.
d) 참조 관계
참조 관계는 그것이 참조하는 항목의 수명을 제어하지 않는다. 심지어, 참조 관계는 타겟의 존재를 보장하지 않으며, 관계 선언에서 지정되는 타겟의 타입도 보장하지 않는다. 이것은 참조 관계가 현수 상태일 수 있다는 것을 의미한다. 또 한, 참조 관계는 다른 데이터 저장소 내의 항목을 참조할 수 있다. 참조 관계는 웹 페이지 내의 링크와 유사한 개념으로 간주될 수 있다.
다음은 참조 관계 선언의 일례이다.
타겟 엔드 포인트에서 임의의 참조 관계가 허용된다. 참조 관계에 참여하는 항목들은 임의의 항목 타입일 수 있다.
참조 관계는 항목들 사이의 대부분의 비 수명 관리 관계를 모델링하는 데 사용된다. 타겟의 존재가 강제되지 않으므로, 참조 관계는 느슨하게 결합된 관계를 모델링하는 데 편리하다. 참조 관계는 다른 컴퓨터 상의 저장소를 포함하는 다른 데이터 저장소 내의 항목을 타겟으로 하여 사용될 수 있다.
e) 규칙 및 제한
다음의 추가적인 규칙 및 제한은 관계에 적용된다.
- 항목은 (단 하나의 삽입 관계) 또는 (하나 이상의 유지 관계)의 타겟이어야 한다. 하나의 예외는 루트 항목이다. 항목은 0개 이상의 참조 관계의 타겟일 수 있다.
- 삽입 관계의 타겟인 항목은 유지 관계의 소스일 수 없다. 이것은 참조 관 계의 소스일 수 있다.
- 항목은 파일로부터 승진된 경우 유지 관계의 소스가 될 수 없다. 이것은 삽입 관계 및 참조 관계의 소스가 될 수 있다.
- 파일로부터 승진된 항목은 삽입 관계의 타겟이 될 수 없다.
f) 관계들의 순서화
적어도 하나의 실시예에서, 본 발명의 저장 플랫폼은 관계들의 순서화를 지원한다. 순서화는 기본 관계 정의 내의 "순서(Order)"라는 명칭의 속성을 통해 달성된다. 순서 필드에 대한 고유성 제한은 존재하지 않는다. 동일한 "순서" 속성 값을 가진 관계들의 순서는 보장되지 않으나, 이들이 보다 낮은 "순서" 값을 가진 관계 후에, 그리고 보다 높은 "순서" 필드 값을 가진 관계 전에 순서화될 수 있는 것은 보장된다.
애플리케이션은 조합(SourceItemID, RelationshipID, Order) 상에서의 순서화에 의해 디폴트 순서로 관계를 취득할 수 있다. 주어진 항목으로부터 나온 모든 관계 인스턴스는 집합 내의 관계의 타입에 관계없이 단일 집합으로서 순서화된다. 그러나, 이것은 주어진 타입의 모든 관계(예컨대, FolderMembers)가 주어진 항목에 대한 관계 집합의 순서화된 서브세트임을 보장한다.
관계를 조작하기 위한 데이터 저장소 API(312)는 관계들의 순서화를 지원하는 한 세트의 동작을 구현한다. 다음 용어들은 동작의 설명을 돕기 위해 도입된다.
- RelFirst는 순서 값 OrdFirst를 가진 순서화된 집합 내의 첫 번째 관계이다.
- RelLast는 순서 값 OrdLast를 가진 순서화된 집합 내의 최종 관계이다.
- RelX는 순서 값 OrdX를 가진 집합 내의 소정의 관계이다.
- RelPrev는 OrdX보다 작은 순서 값 OrdPrev를 가진 집합에서 RelX에 가장 가까운 관계이다.
-RelNext는 OrdX보다 큰 순서 값 OrdNext를 가진 집합에서 RelX에 가장 가까운 관계이다.
동작들은 다음을 포함하지만 이에 한하지 않는다.
- InsertBeforeFirst(SourceItemID, Relationship)는 집합 내의 제1 관계로서 관계를 삽입한다. 새로운 관계의 순서 속성 값은 OrdFirst보다 작을 수 있다.
- InsertAfterLast(SourceItemID, Relationship)는 집합 내의 최종 관계로서 관계를 삽입한다. 새로운 관계의 순서 속성 값은 OrdLast보다 클 수 있다.
- InsertAt(SourceItemID, ord, Relationship)는 순서 속성에 대한 지정 값을 가진 관계를 삽입한다.
- InsertBefore(SourceItemID, ord, Relationship)는 주어진 순서 값을 가진 관계 앞에 관계를 삽입한다. 새로운 관계는 OrdPrev와 ord 사이(이들 값은 포함하지 않음)의 순서 값이 할당될 수 있다.
- InsertAfter(SourceItemID, ord, Relationship)는 주어진 순서 값을 가진 관계 뒤에 관계를 삽입한다. 새로운 관계는 ord와 OrdNext 사이(이들 값은 포함되 지 않음)의 순서 값이 할당될 수 있다.
- MoveBefore(SourceItemID, ord, Relationship)는 주어진 관계 ID를 가진 관계를 지정된 순서 값을 가진 관계 앞으로 이동시킨다. 관계는 OrdPrev와 ord 사이(이들 값은 포함되지 않음)의 새로운 순서 값이 할당될 수 있다.
- MoveAfter(SourceItemID, ord, Relationship)는 주어진 관계 ID를 가진 관계를 지정된 순서 값을 가진 관계 뒤로 이동시킨다. 관계는 ord와 OrdNext 사이(이들 값은 포함되지 않음)의 새로운 순서 값이 할당될 수 있다.
전술한 바와 같이, 모든 항목은 항목 폴더의 회원이어야 한다. 관계에 의하여, 모든 항목은 항목 폴더와의 관계를 가져야 한다. 본 발명의 여러 실시예에서, 소정의 관계들은 항목들 사이에 존재하는 관계에 의해 표현된다.
본 발명의 다양한 실시예에서 구현되는 바와 같이, 관계는 하나의 항목(소스)에 의해 다른 항목(타겟)으로 확장되는 방향성 바이너리 관계를 제공한다. 관계는 소스 항목(관계를 확장한 항목)에 의해 소유되며, 따라서 소스가 제거되는 경우에는 관계가 제거된다(예컨대, 관계는 소스 항목이 삭제될 때 삭제된다). 더욱이, 소정의 예에서, 관계는 타겟 항목의 소유를 공유(공동 소유)할 수 있으며, 이러한 소유는 (관계 속성 타입에 대해 도 7에 도시된 바와 같이) 관계의 IsOwned 속성(또는 그의 등가물) 내에 반영될 수 있다. 이들 실시예에서, 새로운 IsOwned 관계의 생성은 타겟 항목에 대한 참조 수를 자동으로 증가시키며, 이러한 관계의 삭제는 타겟 항목에 대한 참조 수를 감소시킬 수 있다. 이러한 특정 실시예에서, 항목들은 이들이 0보다 큰 참조 수를 갖는 경우 계속 존재하며, 참조 수가 0이 되는 경우 자동으로 삭제된다. 또한, 항목 폴더는 다른 항목들에 대해 한 세트의 관계를 갖는(또는 가질 수 있는) 항목인데, 이들 다른 항목들은 항목 폴더의 회원을 포함한다. 다른 실제적인 관계의 구현도 가능하며, 여기서 설명되는 기능을 달성하도록 본 발명에 의해 예측된다.
실제 구현과 관계없이, 관계는 하나의 객체에서 다른 객체로의 선택 가능한 연결이다. 하나의 항목이 둘 이상의 항목 폴더는 물론, 하나 이상의 카테고리에 속할 수 있는 능력, 및 이들 항목, 폴더 및 카테고리가 공개적인지 사적인지의 여부는 항목 기반 구조에서의 존재(또는 부재)에 대해 주어지는 의미에 의해 결정된다. 이러한 논리 관계는 물리적 구현에 관계없이 본 명세서에서 설명되는 기능을 달성하기 위해 구체적으로 사용되는 한 세트의 관계에 할당되는 의미들이다. 논리 관계는 항목과 그의 항목 폴더(들) 또는 카테고리들(및 그 역) 사이에 설정되는데, 이는 본질적으로 항목 폴더 및 카테고리가 각각 항목의 특수한 타입이기 때문이다. 결과적으로, 항목 폴더 및 카테고리는 복사되고, 이메일 메시지에 추가되고, 문서에 삽입되는 등등 제한 없이, 임의의 다른 항목과 동일한 방식으로 동작될 수 있으며, 항목 폴더 및 카테고리는 다른 항목에 대한 것과 동일한 메카니즘을 이용하여 일련화 및 비일련화(가져오기 및 가져가기)될 수 있다. (예를 들어, XML에서 모든 항목은 일련화 포맷을 가질 수 있으며, 이러한 포맷은 항목 폴더, 카테고리 및 항목에 동일하게 적용된다.)
항목과 그의 항목 폴더 사이의 관계를 나타내는 전술한 관계는 논리적으로 항목에서 항목 폴더로, 항목 폴더에서 항목으로, 또는 양쪽으로 확장될 수 있다. 항목에서 항목 폴더로 확장되는 관계는 항목 폴더가 항목에 대해 공개적이며 항목과 그의 회원 정보를 공유한다는 것을 나타내지만, 역으로 항목에서 항목 폴더로의 논리 관계의 결여는 항목 폴더가 항목에 대해 사적이며, 항목과 그의 회원 정보를 공유하지 않는다는 것을 나타낸다. 유사하게, 항목 폴더에서 항목으로 논리적으로 확장되는 관계는 항목이 공개적이며 항목 폴더와 공유될 수 있다는 것을 나타내는 반면, 항목 폴더에서 항목으로의 논리 관계의 결여는 항목이 사적이고, 공유될 수 없다는 것을 나타낸다. 결과적으로, 항목 폴더가 다른 시스템에 노출될 때, 이것은 이 새로운 상황에서 공유되는 "공개" 항목이며, 항목이 그의 항목 폴더에서 다른 공유 가능한 항목들을 검색할 때, 이것은 항목에 이에 속하는 공유 가능한 항목들에 관한 정보를 제공하는 "공개" 항목 폴더들이다.
도 9는 항목 폴더(이것은 또한 항목 그 자체이다), 그의 회원 항목들, 및 항목 폴더와 그의 회원 항목들 사이의 상호 연결 관계를 나타내는 블록도이다. 항목 폴더(900)는 다수의 항목(902, 904, 906)을 갖는다. 항목 폴더(900)는 그 자신으로부터 항목(902)으로의 관계(912)를 갖는데, 이 관계는 항목(902)이 공개적이며 항목 폴더(900), 그의 회원들(904, 906), 및 항목 폴더(900)에 액세스할 수 있는 임의의 다른 항목 폴더들, 카테고리들, 또는 항목들(도시되지 않음)과 공유될 수 있다는 것을 나타낸다. 그러나, 항목 폴더(900)가 항목(902)에 대해 사적이며, 항목(902)과 그의 회원 정보를 공유하지 않는다는 것을 나타내는 항목(902)에서 항목 폴더(900)로의 관계는 존재하지 않는다. 한편, 항목(904)은, 항목 폴더(900)가 공개적이며 항목(904)과 그의 회원 정보를 공유한다는 것을 나타내는 그 자신에서 항 목 폴더(900)로의 관계를 갖지 않는다. 그러나, 항목(904)이 사적이며 항목 폴더(900), 그의 다른 회원들(902, 906), 및 항목 폴더(900에 액세스할 수 있는 항목 폴더, 카테고리 또는 항목(도시되지 않음)과 공유되지 않음을 나타내는 항목 폴더(900)에서 항목(904)으로의 관계가 존재하지 않는다. 항목 폴더의 항목들(902, 904)에 대한 관계(또는 관계의 결여)와 달리, 항목 폴더(900)는 그 자신에서 항목(906)으로의 관계(916)를 가지며, 항목(906)은 역으로 항목 폴더(900)로의 관계(926)을 갖는데, 이들 관계는 함께 항목(906)이 공개적이며 항목 폴더(900), 그의 회원들(902, 904), 및 항목 폴더(900)에 액세스할 수 있는 임의의 다른 항목 폴더, 카테고리 또는 항목(도시되지 않음)과 공유될 수 있고, 항목 폴더(900)가 공개적이고 항목(906)과 그의 회원 정보를 공유한다는 것은 나타낸다.
전술한 바와 같이, 항목 폴더 내의 항목들은 공유성을 공유할 필요는 없는데, 이는 항목 폴더가 "기술"되지 않기 때문이다. 한편, 카테고리는 그의 회원 항목들 모두에 공통인 공통성에 의해 기술된다. 결과적으로, 카테고리의 회원은 기술된 공통성을 가진 항목들로 고유하게 제한되며, 소정 실시예에서 카테고리의 기술을 만족시키는 모든 항목은 자동으로 카테고리의 회원이 된다. 따라서, 항목 폴더는 평범한 타입의 구조들이 그들의 회원에 의해 표현되는 것을 허용하는 반면, 카테고리는 정의된 공통성에 기초하여 회원을 허용한다.
물론, 카테고리 기술은 사실상 논리적이며, 따라서 카테고리는 타입들, 속성들 및/또는 값들의 임의의 논리적 표현에 의해 기술될 수 있다. 예컨대, 카테고리의 논리적 표현은 2개의 속성 중 하나 또는 양자를 갖는 항목들을 포함하는 그의 회원일 수 있다. 카테고리에 대해 기술된 이러한 속성들이 "A" 및 "B"인 경우, 카테고리 회원은 속성 A를 가지나 B는 갖지 않는 항목들, 속성 A는 갖지 않고 B를 갖는 항목들, 및 속성 A 및 B를 모두 갖는 항목들을 포함할 수 있다. 이러한 속성들의 논리적 표현은 논리 연산자 "OR"에 의해 기술되는데, 카테고리에 의해 기술되는 회원들의 세트는 속성 A OR B를 가진 항목들이다. 유사한 논리 연산자(제한 없이 "AND", "XOR" 및 "NOT"를 단독으로 또는 조합으로 포함)도 당업자가 이해하듯이 카테고리를 기술하는 데 사용될 수 있다.
항목 폴더(기술되지 않음)와 카테고리(기술됨) 사이의 차이에도 불구하고, 항목에 대한 카테고리의 관계 및 카테고리에 대한 항목의 관계는 본질적으로 본 발명의 많은 실시예에서 항목 폴더 및 항목에 대해 위에 개시한 것과 동일한 방식을 갖는다.
도 10은 카테고리(항목 자체), 그의 회원 항목들, 및 카테고리와 그의 회원 항목들 사이의 상호 연결 관계를 나타내는 블록도이다. 카테고리(1000)는 다수의 항목(1002, 1004, 1006)을 회원으로서 갖는데, 이들 모두는 카테고리(1000)에 의해 기술되는 바와 같이 공통 속성들, 값들 또는 타입들(1008)의 소정의 조합을 공유한다. 카테고리(1000)는 그 자체에서 항목(1002)으로의 관계(1012)를 갖는데, 이 관계는 항목(1002)이 공개적이며, 카테고리(1000), 그의 회원들(1004, 1006), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 있다는 것을 나타낸다. 그러나, 카테고리(1000)가 항목(1002)에 대해 사적이며, 항목(1002)과 그의 회원 정보를 공유하지 않는다는 것을 나타내는, 항목(1002)에서 카테고리(1000)로의 관계는 존재하지 않는다. 한편, 항목(1004)은 카테고리(1000)가 공개적이며, 항목(1004)과 그의 회원 정보를 공유한다는 것을 나타내는, 그 자체에서 카테고리(1000)로의 관계(1024)를 갖지 않는다. 그러나, 항목(1004)이 사적이며, 카테고리(1000), 그의 다른 회원들(1002, 1006), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 없다는 것은 나타내는 카테고리(1000)에서 항목(1004)으로 확장되는 관계가 존재하지 않는다. 카테고리의 항목(1002, 1004)과의 관계(또는 그의 결여)와 달리, 카테고리(1000)는 그 자체에서 항목(1006)으로의 관계를 가지며, 항목(1006)은 역으로 카테고리(1000)로의 관계를 갖는데, 이들 관계는 함께 항목(1006)이 공개적이며 카테고리(1000), 그의 항목 회원들(1002, 1004), 및 카테고리(1000)에 액세스할 수 있는 임의의 다른 카테고리, 항목 폴더 또는 항목(도시되지 않음)과 공유될 수 있다는 것과, 카테고리(1000)가 공개적이며, 항목(1006)과 그의 회원 정보를 공유한다는 것을 나타낸다.
마지막으로, 카테고리 및 항목 폴더들 자체는 항목이기 때문에, 소정의 다른 실시예에서 항목들은 서로에 대한 관계를 가질 수 있고, 카테고리는 항목 폴더에 대한 관계를, 항목 폴더는 카테고리에 대한 관계를 가질 수 있으며, 카테고리, 항목 폴더 및 항목은 다른 카테고리, 항목 폴더 및 항목에 대한 관계를 가질 수 있다. 그러나, 다양한 실시예에서, 항목 폴더 구조 및/또는 카테고리 구조는 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 순환을 포함하는 것이 금지된다. 항목 폴더 및 카테고리 구조가 방향 그래프와 유사한 경우, 순환을 금지하는 실시예들은 그래프 이론 분야의 수학적 정의에 의해 동일한 정점에서 어떠한 경로도 시작하거나 끝나지 않는 방향 그래프인 방향 비순환 그래프(DAG)와 유사하다.
6. 확장성
저장 플랫폼은 전술한 바와 같이 초기 스키마 세트(340)를 구비한다. 또한, 그러나 적어도 일부 실시예에서 저장 플랫폼은 개별 소프트웨어 벤더(ISV)를 포함하는 고객들이 새로운 스키마(344)(즉, 새로운 항목 및 중첩 요소 타입)를 생성하는 것을 허용한다. 이 섹션은 초기 스키마 세트(340)에 정의된 항목 타입 및 중첩 요소 타입(또는 단순히 요소 타입)을 확장함으로써 이러한 스키마를 생성하는 메카니즘을 다룬다.
바람직하게도, 초기의 항목 및 중첩 요소 타입 세트는 다음과 같이 제한된다.
- ISV는 새로운 항목 타입, 즉 서브 타입인 Base.Item을 도입하는 것이 허용된다.
- ISV는 새로운 중첩 요소 타입, 즉 서브 타입인 Base.NestedElement를 도입하는 것이 허용된다.
- ISV는 새로운 확장, 즉 서브 타입인 Base.NestedElement를 도입하는 것이 허용된다.
- 그러나, ISV는 저장 플랫폼 스키마의 초기 세트(340)에 의해 정의된 임의의 타입(항목, 중첩 요소 또는 확장 타입)을 서브 타입화할 수 없다.
저장 플랫폼 스키마의 초기 세트에 정의된 항목 타입 또는 중첩 요소 타입은 ISV 애플리케이션의 요구에 정확하게 부응하지 않을 수 있기 때문에, ISV가 타입을 주문화하는 것을 허용할 필요가 있다. 이것은 확장의 개념으로 허용된다. 확장은 강력하게 타입화된 확장이지만, (a) 이것은 독립적으로 존재할 수 없고, (b) 항목 또는 중첩 요소에 첨부되어야 한다.
스키마 확장성의 필요성을 다루는 것 외에, 확장은 또한 "멀티 타입화" 문제를 다룬다. 소정의 실시예에서, 저장 플랫폼은 다수의 상속 또는 중첩 서브 타입을 지원하지 않을 수 있기 때문에, 애플리케이션은 확장을 중첩 타입 인스턴스를 모델링하기 위한 방법으로서 이용할 수 있다(예컨대, 문서는 합법 문서는 물론 보안 문서이다).
a) 항목 확장
항목 확장성을 제공하기 위하여, 데이터 모델은 또한 Base. Extension이라는 명칭의 추상 타입을 정의한다. 이것은 확장 타입의 계층 구조에 대한 루트 타입이다. 애플리케이션은 특정 확장 타입을 생성하기 위해 Base.Extension을 서브 타입화할 수 있다.
Base.Extension 타입은 다음과 같이 Base.Extension 내에 정의된다.
ItemID 필드는 확장이 연관되어 있는 항목의 ItemID를 포함한다. 이 ItemID를 가진 항목이 존재해야 한다. 확장은 소정의 ItemID를 가진 항목이 존재하지 않는 경우 생성될 수 없다. 항목이 삭제되면, 동일한 ItemID를 가진 모든 확장이 삭제된다. 튜플(ItemID, ExtensionID)은 확장 인스턴스를 고유하게 식별한다.
확장 타입의 구조는 항목 타입의 구조와 유사하다.
- 확장 타입은 필드를 갖는다.
- 필드는 기본 또는 중첩 요소 타입일 수 있다.
- 확장 타입은 서브 타입화될 수 있다.
다른 제한은 확장 타입에 적용된다.
- 확장은 관계의 소스 및 타겟일 수 없다.
- 확장 타입 인스턴스는 항목과 별개로 존재할 수 없다.
- 확장 타입은 저장 플랫폼 타입 정의에서 필드 타입으로 사용될 수 없다.
주어진 항목 타입과 관련될 수 있는 확장의 타입에는 제한이 없다. 어떠한 확장 타입도 임의의 항목 타입을 확장하는 것이 허용된다. 다수의 확장 인스턴스 가 항목에 첨부될 때, 이들은 구조 및 거동 양자에서 서로 독립적이다.
확장 인스턴스는 저장되어 항목으로부터 개별적으로 액세스된다. 모든 확장 타입 인스턴스는 글로벌 확장 뷰로부터 액세스될 수 있다. 어떤 타입의 항목과 연관되어 있는지에 관계없이 소정 확장 타입의 모든 인스턴스를 리턴하는 효율적인 질의가 구축될 수 있다. 저장 플랫폼 API는 항목에 대한 확장을 저장, 검색 및 수정할 수 있는 프로그래밍 모델을 제공한다.
확장 타입은 저장 플랫폼 단일 상속 모델을 이용하여 서브 타입화된 타입일 수 있다. 확장 타입으로부터의 도출은 새로운 확장 타입을 생성한다. 확장의 구조 또는 거동은 항목 타입 계층 구조의 구조 또는 거동을 무시하거나 대체할 수 없다. 항목 타입과 유사하게, 확장 타입 인스턴스는 확장 타입과 관련된 뷰를 통해 직접 액세스될 수 있다. 확장의 ItemID는 이들이 어느 항목에 속하는지를 나타내며, 글로벌 항목 뷰로부터 대응하는 항목 객체를 검색하는 데 사용될 수 있다. 확장은 동작의 일관성을 위해 항목의 일부로 간주된다. 저장 플랫폼이 정의하는 복사/이동, 백업/복원 및 다른 일반 동작들은 항목의 일부로서 확장에 대해 동작할 수 있다.
다음 예를 고려하자. 윈도우 타입 세트 내에 콘택 타입이 정의된다.
CRM 애플리케이션 개발자는 저장 플랫폼에 저장된 콘택에 CRM 애플리케이션 확장을 첨부하기를 원한다. 애플리케이션 개발자는 애플리케이션이 조작할 수 있는 추가적인 데이터 구조를 포함하는 CRM 확장을 정의한다.
HR 애플리케이션 개발자는 또한 콘택에 추가 데이터를 첨부하기를 원할 수 있다. 이 데이터는 CRM 애플리케이션 데이터와 무관하다. 또한, 애플리케이션 개발자는 확장을 생성할 수 있다.
CRMExtension 및 HRExtension은 콘택 항목에 첨부될 수 있는 2개의 독립적인 확장이다. 이들은 서로 독립적으로 생성되고 액세스된다.
위의 예에서, CRMExtension 타입의 필드 및 메소드는 콘택 계층 구조의 필드 또는 메소드를 무시할 수 없다. CRMExtension 타입의 인스턴스는 콘택이 아니라 항목 타입에 첨부될 수 있다는 점에 유의해야 한다.
콘택이 검색될 때, 그의 항목 확장이 자동으로 검색되는 것은 아니다. 콘택 항목이 주어지면, 그와 관련된 항목 확장은 동일한 ItemID를 가진 확장에 대한 글로벌 확장 뷰에 질의함으로써 액세스될 수 있다.
시스템 내의 모든 CRMExtension 확장들은 이들이 어느 항목에 속하는지에 관계없이 CRMExtension 타입 뷰를 통해 액세스될 수 있다. 항목의 모든 항목 확장은 동일한 항목 ID를 공유한다. 위 예에서, 콘택 항목 인스턴스 및 첨부된 CRMExtension 및 HRExtension 인스턴스는 동일한 ItemID를 공유한다.
다음 테이블은 항목, 확장 및 중첩 요소 타입 사이의 유사성 및 차이를 요약한 것이다.
항목 대 항목 확장 대 중첩 요소
| 항목 | 항목 확장 | 중첩 요소 | |
| 항목 ID | 그 자신의 항목 ID를 갖는다. | 항목의 항목 ID를 공유한다. | 그 자신의 항목 ID를 갖지 않는다. 중첩 요소는 항목의 일부이다. |
| 저장 | 항목 계층 구조는 그 자신의 테이블에 저장된다. | 항목 확장 계층 구조는 그 자신의 테이블에 저장된다. | 항목과 함께 저장된다. |
| 질의/검색 | 항목 테이블에 질의할 수 있다. | 항목 확장 테이블에 질의할 수 있다. | 일반적으로 포함하는 항목 컨텍스트 내에서만 질의될 수 있다. |
| 질의/검색 범위 | 항목 타입의 모든 인스턴스를 검색할 수 있다. | 항목 확장 타입의 모든 인스턴스를 검색할 수 있다. | 일반적으로 단일 (포함) 항목의 중첩 요소 타입 인스턴스 내에서만 검색할 수 있다. |
| 관계 시맨틱 | 항목들에 대한 관계를 가질 수 있다. | 항목 확장에 대한 관계 없음. | 중첩 요소에 대한 관계 없음 |
| 항목에 대한 연관성 | 유지, 삽입 및 소프트 관계를 통해 다른 항목과 관련될 수 있다. | 일반적으로 확장을 통해서만 관련될 수 있다. 확장 시맨틱은 삽입된 항목 시맨틱과 유사하다. | 필드를 통해 항목과 관련됨, 중첩 요소는 항목의 일부이다. |
b) 중첩 요소 확장
중첩 요소 타입은 항목 타입과 동일한 메카니즘으로 확장되지 않는다. 중첩 요소의 확장은 중첩 요소 타입의 필드와 동일한 메카니즘으로 저장되고 액세스된다.
데이터 모델은 Element라는 명칭의 중첩 요소 타입의 루트를 정의한다.
중첩 요소 타입은 이 타입으로부터 상속된다. NestElement 요소 타입은 요소들의 멀티 세트인 필드를 추가적으로 정의한다.
중첩 요소 확장은 다음의 방식에서 항목 확장과 다르다.
- 중첩 요소 확장은 확장 타입이 아니다. 이것은 Base.Extension 타입에서 루트가 되는 확장 타입 계층 구조에 속하지 않는다.
- 중첩 요소 확장은 항목의 다른 필드들과 함께 저장되며, 글로벌 액세스가 가능하지 않으며, 주어진 확장 타입의 모든 인스턴스를 검색하는 질의가 구축될 수 없다.
- 이들 확장은 (항목의) 다른 중첩 요소들이 저장되는 것과 동일한 방식으로 저장된다. 다른 중첩 세트와 같이, 중첩 요소 확장은 UDT에 저장된다. 이들은 중첩 요소 타입의 확장 필드를 통해 액세스될 수 있다.
- 다가 속성들에 액세스하는 데 사용되는 집합 인터페이스도 타입 확장 세트에 대한 액세스 및 반복을 위해 사용된다.
다음 테이블은 항목 확장 및 중첩 요소 확장을 요약하고 비교한 것이다.
항목 확장 대 중첩 요소 확장
| 항목 확장 | 중첩 요소 확장 | |
| 저장 | 항목 확장 계층 구조가 그 자신의 테이블에 저장된다. | 중첩 요소와 같이 저장된다. |
| 질의/검색 | 항목 확장 테이블에 질의할 수 있다. | 일반적으로 포함 항목 컨텍스트 내에서만 질의될 수 있다. |
| 질의/검색 범위 | 항목 확장 타입의 모든 인스턴스를 검색할 수 있다. | 일반적으로 단일 (포함) 항목의 중첩 요소 타입 인스턴스 내에서만 검색할 수 있다. |
| 프로그래밍 가능성 | 특수 확장 API 및 확장 테이블에 대한 특수 질의가 필요하다. | 중첩 요소 확장은 중첩 요소의 임의의 다른 다가 필드와 유사하며, 정상 중첩 요소 타입 API가 사용된다. |
| 거동 | 거동을 연관시킬 수 있다. | 거동이 허용되지 않음(?) |
| 관계 시맨틱 | 항목 확장에 대한 관계 없음 | 중첩 요소 확장에 대한 관계 없음 |
| 항목 ID | 항목의 항목 ID를 공유한다. | 그 자신의 항목 ID를 갖지 않는다. 중첩 요소 확장은 항목의 일부이다. |
D. 데이터베이스 엔진
전술한 바와 같이, 데이터 저장소는 데이터베이스 엔진 상에서 구현된다. 본 실시예에서, 데이터베이스 엔진은 객체 관계 확장으로 마이크로소프트 SQL 서버 엔진과 같은 SQL 질의 언어를 구현하는 관계형 데이터베이스 엔진을 포함한다. 이 섹션은 본 실시예에 따라 데이터 저장소를 구현하는 데이터 모델의 관계 저장소에 대한 맵핑을 설명하며, 저장 플랫폼 클라이언트에 의해 소비되는 논리 API에 대한 정보를 제공한다. 그러나, 상이한 데이터베이스 엔진이 사용될 때 상이한 맵핑이 사용될수 있다는 것을 이해해야 한다. 실제로, 관계형 데이터베이스 엔진 상에서 저장 플랫폼 개념 데이터 모델을 구현하는 것 외에, 예를 들어 객체 지향 및 XML 데이터베이스와 같은 다른 타입의 데이터베이스 상에서도 구현될 수 있다.
객체 지향(OO) 데이터베이스 시스템은 프로그래밍 언어 객체(예컨대, C++, 자바)에 대한 지속성 및 트랜잭션을 제공한다. "항목"의 저장 플랫폼 개념은 삽입된 집합들이 객체에 추가되어야 하지만 객체 지향 시스템에서 "객체"로 양호하게 맵핑된다. 상속 및 중첩 요소 타입과 같은 다른 저장 플랫폼 타입 개념들도 객체 지향 타입 시스템에 맵핑된다. 객체 지향 시스템은 일반적으로 객체 식별자를 이미 지원하며, 따라서 항목 식별자는 객체 식별자로 맵핑될 수 있다. 항목 거동(동작)은 객체 메소드로 양호하게 맵핑된다. 그러나, 객체 지향 시스템은 일반적으로 체계적인 능력이 부족하며, 검색이 열악하다. 또한, 객체 지향 시스템은 비구조적 및 반구조적 데이터에 대한 지원을 제공하지 않는다. 여기에 설명되는 완전한 저장 플랫폼 데이터 모델을 지원하기 위하여, 관계, 폴더 및 확장과 같은 개념들이 객체 데이터 모델에 추가될 필요가 있다. 또한, 승진, 동기화, 통지 및 보안과 같은 메카니즘이 구현될 필요가 있다.
객체 지향 시스템과 유사하게, XSD(XML 스키마 정의)에 기초하는 XML 데이터베이스는 단일 상속 기반 타입 시스템을 지원한다. 본 발명의 항목 타입 시스템은 XSD 타입 모델로 맵핑될 수 있다. XSD는 또한 거동에 대한 지원을 제공하지 않는다. 항목에 대한 XSD는 항목 거동에 대해 보강되어야 한다. XML 데이터베이스는 단일 XSD 문서를 처리하며, 체계화 및 광범위한 검색 능력이 부족하다. 객체 지향 데이터베이스에서와 같이, 여기서 설명되는 데이터 모델을 지원하기 위하여, 관계 및 폴더와 같은 다른 개념들이 이러한 XML 데이터베이스에 포함될 필요가 있으며, 또한 동기화, 통지 및 보안과 같은 메카니즘이 구현될 필요가 있다.
다음의 서브 섹션과 관련하여, 개시된 일반 정보를 쉽게 하는 몇몇 설명이 제공되는데, 도 13은 통지 메카니즘을 설명하는 도면이다. 도 14는 2개의 트랜잭션 양자가 동일한 B 트리에 새로운 레코드를 삽입하는 예를 나타내는 도면이다. 도 15는 데이터 변경 검출 프로세스를 나타낸다. 도 16은 예시적인 디렉토리 트리를 나타낸다. 도 17은 디렉토리 기반 파일 시스템의 기존 폴더가 저장 플랫폼 데이터 저장소로 이동되는 예를 나타낸다.
1. UDT를 이용한 데이터 저장소 구현
본 실시예에서, 일 실시예에서 마이크로소프트 SQL 서버 엔진을 포함하는 관계형 데이터베이스 엔진(314)은 내장 스칼라 타입을 지원한다. 내장 스칼라 타입은 "원시적"이고 "단순"하다. 이것은 사용자가 그 자신의 타입을 정의할 수 없다는 의미에서 원시적이며, 복합 구조를 캡슐화할 수 없다는 의미에서 단순하다. 사용자 정의 타입(이하, UDT)은 사용자가 복잡하고 구조화된 타입을 정의함으로써 타입 시스템을 확장하는 것을 가능하게 함으로써 원시 스칼라 타입 시스템 위에 그리고 이를 넘어서 타입 확장성을 위한 메카니즘을 제공한다. UDT가 사용자에 의해 정의되면, 이 UDT는 내장 스칼라 타입이 사용될 수 있는 타입 시스템 내의 어디에서나 사용될 수 있다.
본 발명의 일 양태에 따르면, 저장 플랫폼 스키마는 데이터베이스 엔진 저장소 내의 UDT 클래스로 맵핑된다. 데이터 저장소 항목들은 Base.Item 타입으로부터 도출되는 UDT 클래스로 맵핑된다. 항목과 같이, 확장도 UDT 클래스로 맵핑되며, 상속을 이용한다. 루트 확장 타입은 모든 확장 타입이 도출되는 Base.Extension이다.
UDT는 CLR 클래스이며, 이는 상태(즉, 데이터 필드) 및 거동(즉, 루틴)을 갖는다. UDT는 관리형 언어들, 즉 C#, VB.NET 등 중 어느 하나를 이용하여 정의된다. UDT 메소드 및 연산자는 그 타입의 인스턴스에 대해 T-SQL에서 호출될 수 있다. UDT는 행 내의 열의 타입, T-SQL 내의 루틴의 파라미터의 타입 또는 T-SQL 내의 변수의 타입일 수 있다.
저장 플랫폼 스키마의 UDT 클래스로의 맵핑은 고레벨에서 매우 간단하다. 일반적으로, 저장 플랫폼 스키마는 CLR 명칭 공간으로 맵핑된다. 저장 플랫폼 타입은 CLR 클래스로 맵핑된다. CLR 클래스 상속은 저장 플랫폼 타입 상속을 미러링하며, 저장 플랫폼 속성은 CLR 클래스 속성으로 맵핑된다.
2. 항목 맵핑
항목들이 바람직하게 글로벌 검색 가능하고, 본 실시예의 관계형 데이터베이스에서 상속 및 타입 대체성이 지원되는 경우, 데이터베이스 저장소 내의 항목 저장을 위하여 가능한 하나의 구현은 타입 Base.Item의 열을 가진 단일 테이블에 모든 항목을 저장하는 것이다. 타입 대체성을 이용하면, 모든 타입의 항목들이 저장 될 수 있으며, 검색은 유콘(Yukon)의 "is of(타입)" 연산자를 이용하여 항목 타입 및 서브 타입에 의해 필터링될 수 있다.
그러나, 이러한 접근법과 관련된 오버헤드에 대한 염려로 인해, 본 실시예에서는 항목들이 최상위 레벨 타입에 의해 분류되며, 따라서 각 타입 "패밀리"의 항목들은 개별 테이블에 저장된다. 이러한 분할 스킴 하에서는 Base.Item으로부터 직접 상속되는 각각의 항목 타입에 대해 테이블이 생성된다. 이들 아래에서 상속되는 타입들은 전술한 바와 같이 타입 대체성을 이용하여 적절한 타입 패밀리에 저장된다. Base.Item으로부터의 제1 레벨의 상속만이 특수하게 처리된다.
모든 항목에 대한 글로벌 검색 가능 속성들의 사본을 저장하기 위하여 "쉐도우" 테이블이 사용된다. 이 테이블은 모든 데이터 변경을 행하는 저장 플랫폼 API의 Update() 메소드에 의해 유지될 수 있다. 타입 패밀리 테이블과 달리, 이 글로벌 항목 테이블은 완전한 UDT 항목 객체가 아니라 항목의 최상위 레벨 스칼라 속성만을 포함한다. 글로벌 항목 테이블은 ItemID 및 TypeID를 노출시킴으로써 타입 패밀리 테이블에 저장된 항목 객체에 대한 네비게이션을 허용한다. ItemID는 일반적으로 데이터 저장소 내의 항목을 고유하게 식별한다. TypeID는 여기서 설명되지 않는 메타데이터를 이용하여 타입 명칭 및 항목을 포함하는 뷰로 맵핑될 수 있다. 글로벌 항목 테이블과 관련하여, 그리고 다른 상황과 관련하여, 항목을 그의 ItemID에 의해 찾는 것은 일반적인 동작일 수 있으므로, 항목의 ItemID가 주어지면 항목 객체를 검색하기 위한 GetItem() 함수가 제공된다.
편리한 액세스를 위해, 그리고 구현 상세를 가능한 한도까지 숨기기 위해, 항목에 대한 모든 질의는 전술한 항목 테이블 상에 구축된 뷰들에 대한 것일 수 있다. 구체적으로, 적절한 타입 패밀리 테이블에 대해 각각의 항목 타입에 대한 뷰들이 생성될 수 있다. 이러한 타입 뷰는 서브 타입을 포함하는 관련 타입의 모든 항목을 선택할 수 있다. 편의를 위해, UDT 객체 외에, 뷰들은 상속된 필드를 포함하는 그 타입의 모든 최상위 레벨 필드에 대한 열들을 노출시킬 수 있다.
3. 확장 맵핑
확장은 항목과 매우 유사하며, 동일한 요건들의 일부를 갖는다. 상속을 지원하는 다른 루트 타입으로서, 확장은 저장에 있어서의 동일한 고려 및 트레이드오프 중 많은 부분에 종속된다. 이 때문에, 유사한 타입 패밀리 맵핑이 단일 테이블 접근법이 아니라 확장에 적용된다. 물론, 다른 실시예에서는 단일 테이블 접근법이 이용될 수 있다. 본 실시예에서, 확장은 ItemID에 의해 정확히 하나의 항목과 연관되며, 항목과 관련하여 고유한 ExtensionID를 포함한다. 항목에서와 같이, ItemID 및 ExtensionID 쌍으로 이루어진 확장 식별자가 주어질 때 확장을 검색하기 위한 함수가 제공될 수 있다. 항목 타입 뷰와 유사하게 각각의 확장 타입에 대한 뷰가 생성된다.
4. 중첩 요소 맵핑
중첩 요소들은 항목, 확장, 관계, 또는 깊게 중첩된 구조를 형성하는 다른 중첩 요소들 내에 삽입될 수 있는 타입이다. 항목 및 확장과 같이, 중첩 요소는 UDT로서 구현되지만, 항목 및 확장 내에 저장된다. 따라서, 중첩 요소들은 그들의 항목 및 확장 컨테이너의 맵핑을 넘어서는 어떠한 저장 맵핑도 갖지 않는다. 즉, 시스템 내에는 중첩 요소 타입의 인스턴스를 직접 저장하는 테이블이 존재하지 않으며, 중첩 요소에 특정하게 전용화된 어떠한 뷰도 존재하지 않는다.
5. 객체 식별
데이터 모델 내의 각 엔티티, 즉 항목, 확장 및 관계는 고유 키 값을 갖는다. 항목은 그의 ItemID에 의해 고유하게 식별된다. 확장은 (ItemID, ExtensionID)의 합성 키에 의해 고유하게 식별된다. 관계는 합성 키(ItemID, RelationID)에 의해 식별된다. ItemID, ExtensionID 및 RelationID는 GUID 값이다.
6. SQL 객체 명명
데이터 저장소에서 생성된 모든 객체는 저장 플랫폼 스키마 명칭으로부터 도출된 SQL 스키마 명칭에 저장될 수 있다. 예컨대, 저장 플랫폼 기본 스키마(종종 "Base"라고 함)는 "[System.Storage]" SQL 스키마 내에 "[System.Storage].Item"과 같은 타입을 생성할 수 있다. 생성된 명칭 앞에는 명명 충돌을 없애기 위하여 한정사가 붙는다. 적절한 경우, 명칭의 각각의 논리 부분에 대한 분리자로서 느낌표(!)가 사용된다. 아래의 테이블은 데이터 저장소 내의 객체들에 대해 사용되는 명명 규약의 개요를 나타낸다. 각각의 스키마 요소(항목, 확장, 관계 및 뷰)는 데이 터 저장소 내의 인스턴스에 액세스하는 데 사용되는 장식 명명 규약과 함께 리스트되어 있다.
| 객체 | 명칭 장식 | 설명 | 예 |
| 마스터 항목 검색 뷰 | Master!Item | 현재 항목 도메인 내의 항목들의 요약을 제공한다. | [System.Storage]. [Master!Item] |
| 타입화된 항목 검색 뷰 | ItemType | 항목 및 임의의 부모 타입(들)으로부터의 모든 속성 데이터를 제공한다. | [AcmeCorp.Doc]. [OfficeDoc] |
| 마스터 확장 검색 뷰 | Master!Extension | 현재 항목 도메인 내의 모든 확장의 요약을 제공한다. | [System.Storage]. [Master!Extension] |
| 타입화된 확장 검색 뷰 | Extension!extensionType | 확장에 대한 모든 속성 데이터를 제공한다. | [AcmeCorp.Doc]. [Extension!StickyNote] |
| 마스터 관계 뷰 | Master!Relationship | 현재 항목 도메인 내의 모든 관계의 요약을 제공한다. | [System.Storage]. [Master!Relationship] |
| 관계 뷰 | Relation!relationshipName | 주어진 관계와 관련된 모든 데이터를 제공한다. | [AcmeCorp.Doc]. [Relationship!AuthorsFromDocument] |
| 뷰 | View!viewName | 스키마 뷰 정의에 기초하여 열/타입을 제공한다. | [AcmeCorp.Doc]. [View!DocumentTitles] |
7. 열 명명
임의의 객체 모델을 저장소로 맵핑할 때, 명명 충돌의 가능성은 애플리케이션 객체와 함께 저장된 추가 정보로 인해 발생한다. 명명 충돌을 방지하기 위해, 모든 논-타입 특정 열(타입 선언 내의 명명 속성으로 직접 맵핑되지 않는 열들) 앞에는 밑줄(_) 문자가 붙여진다. 본 실시예에서, 밑줄(_) 문자는 임의의 식별자 속성의 시작 문자로서 허용되지 않는다. 또한, CLR과 데이터 저장소 사이의 명명을 통일하기 위하여 저장 플랫폼 타입 또는 스키마 요소(관계 등)의 모든 속성은 대문자화된 제1 문자를 가져야 한다.
8. 검색 뷰
뷰는 저장된 콘텐츠를 검색하기 위해 저장 플랫폼에 의해 제공된다. SQL 뷰가 각각의 항목 및 확장 타입에 대해 제공된다. 또한, 관계 및 뷰를 지원하기 위해(데이터 모델에 정의된 바와 같이) 뷰들이 제공된다. 저장 플랫폼 내의 모든 SQL 뷰 및 기본 테이블은 판독 전용이다. 후술하는 바와 같이, 데이터는 저장 플랫폼 API의 Update() 메소드를 이용하여 저장 또는 변경될 수 있다.
저장 플랫폼 스키마 내에 명시적으로 정의된(저장 플랫폼에 의해 자동 생성된 것이 아니라 스키마 설계자에 의해 정의된) 각각의 뷰는 명명된 SQL 뷰 [<schema-name>].[View!<view-name>]에 의해 액세스될 수 있다. 예를 들어, 스키마 "AcmePublisher.Books" 내에 "BookSales"로 명명된 뷰는 명칭 "[AcmePublisher.Bookks].[View!BookSales]"를 이용하여 액세스될 수 있다. 뷰의 출력 포맷은 뷰 단위로(뷰를 정의하는 자에 의해 제공되는 임의의 질의에 의해 정의됨) 맞춰지므로, 열은 스키마 뷰 정의에 기초하여 직접 맵핑된다.
저장 플랫폼 데이터 저장소 내의 모든 SQL 검색 뷰는 다음과 같은 열 순서화 규약을 이용한다.
- ItemId, ElementId, RelationshipId 등과 같은 뷰 결과의 논리 "키" 열
- TypeId와 같은 결과의 타입에 대한 메타데이터 정보
- CreateVersion, UpdateVersion 등과 같은 변경 추적 열
- 타입 특정 열(선언 타입의 속성)
- 타입 특정 뷰(패밀리 뷰)는 또한 객체를 리턴하는 객체 열을 포함한다.
각 타입 패밀리의 회원들은 일련의 항목 뷰들을 이용하여 검색 가능한데, 데이터 저장소에는 항목 타입당 하나의 뷰가 존재한다. 도 28은 항목 검색 뷰의 개념을 나타내는 도면이다.
a) 항목
각 항목 검색 뷰는 특정 타입 또는 그의 서브 타입의 항목의 각 인스턴스에 대한 행을 포함한다. 예를 들어, 문서에 대한 뷰는 Document, LegalDocument 및 ReviewDocument의 인스턴스를 리턴할 수 있다. 이러한 예가 주어지면, 항목 뷰는 도 29에 도시된 바와 같이 개념화될 수 있다.
(1) 마스터 항목 검색 뷰
저장 플랫폼 데이터 저장소의 각 인스턴스는 마스터 항목 뷰라고 하는 특수 항목을 정의한다. 이 뷰는 데이터 저장소 내의 각 항목에 대한 요약 정보를 제공한다. 뷰는 항목 타입 속성당 하나의 열, 항목의 타입을 기술하는 열, 및 변경 추적 및 동기화 정보를 제공하는 데 사용되는 여러 열을 제공한다. 마스터 항목 뷰는 명칭 "[System.Storage].[Master!Item]"을 이용하여 데이터 저장소에서 식별된다.
| 열 | 타입 | 설명 |
| ItemId | ItemId | 항목의 저장 플랫폼 식별자 |
| _TypeId | TypeId | 항목의 TypeId는 항목의 정확한 타입을 식별하며, 메타데이터 카탈로그를 이용하여 타입에 대한 정보를 검색하는 데 사용될 수 있다. |
| _RootItemId | ItemId | 이 항목의 수명을 제어하는 제1 비삽입 조상의 ItemId |
| <global change tracking> | ... | 글로벌 변경 추적 정보 |
| <Item props> | n/a | 항목 타입 속성당 하나의 열 |
(2) 타입화된 항목 검색 뷰
각 항목 타입은 또한 검색 뷰를 갖는다. 루트 항목 뷰와 유사한 반면, 이 뷰는 "_Item" 열을 통해 항목 객체에 대한 액세스도 제공한다. 각각의 타입화된 항목 검색 뷰는 명칭 [schemaName].[itemTypeName]를 이용하여 데이터 저장소에서 식별된다. 예를 들어, [AcmeCorp.Doc][OfficeDoc].
| 열 | 타입 | 설명 |
| ItemId | ItemId | 항목의 저장 플랫폼 식별자 |
| <type change tracking> | ... | 타입 변경 추적 정보 |
| <parent props> | <property specific> | 부모 속성당 하나의 열 |
| <item props> | <property specific> | 이 타입의 배타적 속성당 하나의 열 |
| _Item | 항목의 CLR 타입 | CLR 객체-선언 항목의 타입 |
b) 항목 확장
WinFS 저장소 내의 모든 항목 확장은 또한 검색 뷰를 이용하여 검색 가능하다.
(1) 마스터 확장 검색 뷰
데이터 저장소의 각각의 인스턴스는 마스터 확장 뷰라고 하는 특수 확장 뷰 를 정의한다. 이 뷰는 데이터 저장소 내의 각각의 확장에 대한 요약 정보를 제공한다. 뷰는 확장 속성당 하나의 열, 확장 타입을 기술하는 하나의 열, 및 변경 추적 및 동기화 정보를 제공하는 데 사용되는 여러 열을 갖는다. 마스터 확장 뷰는 명칭 [System.Storage].[Master!Extension]"을 이용하여 데이터 저장소에서 식별된다.
| 열 | 타입 | 설명 |
| ItemId | ItemId | 확장이 연관된 항목의 저장 플랫폼 식별자 |
| ExtensionId | ExtensionId(GUID) | 이 확장 인스턴스의 ID |
| _TypeId | TypeId | 확장의 TypeId는 확장의 정확한 타입을 식별하며, 메타데이터 카탈로그를 이용하여 확장에 대한 정보를 검색하는 데 사용될 수 있다. |
| <global change tracking> | ... | 글로벌 변경 추적 정보 |
| <ext properties> | <property specific> | 확장 타입 속성당 하나의 열 |
(2) 타입화된 확장 검색 뷰
각각의 확장 타입은 또한 검색 뷰를 갖는다. 마스터 확장 뷰와 유사한 반면, 이 뷰는 _Extension 열을 통해 항목에 대한 액세스도 제공한다. 각각의 타입화된 확장 검색 뷰는 명칭 [schemaName].[Extension!extensionTypeName]을 이용하여 데이터 저장소에서 식별된다. 예를 들어, [AcmeCorp.Doc].[Extension!OfficeDocExt].
| 열 | 타입 | 설명 |
| ItemId | ItemId | 이 확장이 연관된 항목의 저장 플랫폼 식별자 |
| ExtensionId | ExtensionId(GUID) | 이 확장 인스턴스의 ID |
| <type change tracking> | ... | 타입 변경 추적 정보 |
| <parent props> | <property specific> | 부모 속성당 하나의 열 |
| <ext props> | <property specific> | 이 타입의 배타적 속성당 하나의 열 |
| _Extension | 확장 인스턴스의 CLR 타입 | CLR 객체-선언 확장의 타입 |
c) 중첩 요소
모든 중첩 요소는 항목, 확장 또는 관계 인스턴스 내에 저장된다. 이에 따라, 이들은 적절한 항목, 확장 또는 관계 검색 뷰에 질의함으로써 액세스된다.
d) 관계
전술한 바와 같이, 관계는 저장 플랫폼 데이터 저장소 내의 항목들 사이의 연결의 기본 단위를 형성한다.
(1) 마스터 관계 검색 뷰
각각의 데이터 저장소는 마스터 관계 뷰를 제공한다. 이 뷰는 데이터 저장소 내의 모든 관계 인스턴스에 대한 정보를 제공한다. 마스터 관계 뷰는 명칭 "[System.Storage].[Master!Relationship]"을 이용하여 데이터 저장소에서 식별된다.
| 열 | 타입 | 설명 |
| ItemId | ItemId | 소스 엔드포인트의 식별자(ItemId) |
| RelationshipId | RelationshipId(GUID) | 관계 인스턴스의 ID |
| _RelTypeId | RelationshipTypeId | 관계의 RelTypeId는 메타데이터 카탈로그를 이용하여 관계 인스턴스의 타입을 식별한다. |
| <global change tracking> | ... | 글로벌 변경 추적 정보 |
| TargetItemReference | ItemReference | 타겟 엔드포인트의 식별자 |
| _Relationship | Relationship | 이 인스턴스에 대한 관계 객체의 인스턴스 |
(2) 관계 인스턴스 검색 뷰
각각의 선언된 관계는 또한 특정 관계의 모든 인스턴스를 리턴하는 검색 뷰를 갖는다. 마스터 관계 뷰와 유사하지만, 이 뷰는 관계 데이터의 각 속성에 대해 명명된 열을 또한 제공한다. 각각의 관계 인스턴스 검색 뷰는 명칭 [schemaName].[Relationship!relationshipName]을 이용하여 데이터 저장소에서 식별된다. 예를 들면, [AcmeCorp.Doc].[Relationship!DocumentAuthor].
| 열 | 타입 | 설명 |
| ItemId | ItemId | 소스 엔드포인트의 식별자(ItemId) |
| RelationshipId | RelationshipId(GUID) | 관계 인스턴스의 ID |
| <type change tracking> | ... | 타입 변경 추적 정보 |
| TargetItemReference | ItemReference | 타겟 엔드포인트의 식별자 |
| <source name> | ItemId | 소스 엔드포인트 식별자의 명명된 속성(ItemId의 별명) |
| <target name> | ItemReference 또는 도출된 클래스 | 타겟 엔드포인트 식별자의 명명된 속성(TargetItemReference에 대한 별명 및 캐스트) |
| <rel property> | <property specific> | 관계 정의의 속성당 하나의 열 |
| _Relationship | 관계 인스턴스의 CLR 타입 | CLR 객체-선언 관계의 타입 |
e)
9. 갱신
저장 플랫폼 데이터 저장소 내의 모든 뷰는 판독 전용이다. 데이터 모델 요소(항목, 확장 또는 관계)의 새로운 인스턴스를 생성하기 위하여, 또는 기존 인스턴스를 갱신하기 위하여, 저장 플랫폼 API의 ProcessOperation 또는 ProcessUpdategram 메소드가 사용되어야 한다. ProcessOperation 메소드는 수행될 액션을 상술하는 "동작"을 소비하는 데이터 저장소에 의해 정의된 단일 저장 절차이다. ProcessUpdategram 메소드는 수행될 한 세트의 액션을 집합적으로 상술하는 "updategram"으로 알려진 순서화된 동작 세트를 취하는 저장된 절차이다.
동작 포맷은 확장 가능하며, 스키마 요소에 대한 다양한 동작을 제공한다. 소정의 일반 동작들은 다음을 포함한다.
1. 항목 동작
a. CreateItem(삽입 또는 유지 관계와 관련된 새로운 항목 생성)
b. UpdateItem(기존 항목 갱신)
2. 관계 동작
a. CreateRelationship(참조 또는 유지 관계의 인스턴스 생성)
b. UpdateRelationship(관계 인스턴스 갱신)
c. DeleteRelationship(관계 인스턴스 제거)
3. 확장 동작
a. CreateExtension(기존 항목에 확장 추가)
b. UpdateExtension(기존 확장 갱신)
c. DeleteExtension(확장 삭제)
10. 변경 추적 및 툼스톤
변경 추적 및 툼스톤 서비스는 후술하는 바와 같이 데이터 저장소에 의해 제공된다. 이 섹션은 데이터 저장소에 노출되는 변경 추적 정보의 개요를 제공한다.
a) 변경 추적
데이터 저장소에 의해 제공되는 각 검색 뷰는 변경 추적 정보를 제공하는 데 사용되는 열들을 포함하며, 이 열들은 모든 항목, 확장 및 관계 뷰에 걸쳐 공통이다. 스키마 설계자에 의해 명시적으로 정의되는 저장 플랫폼 스키마 뷰는 변경 추적 정보를 자동으로 제공하지 않으며, 이러한 정보는 뷰 자체가 구축되는 검색 뷰를 통해 간접적으로 제공된다.
데이터 저장소 내의 각각의 요소에 대해, 변경 추적 정보는 2개의 장소, 즉 마스터 요소 뷰 및 타입화된 요소 뷰로부터 이용할 수 있다. 예를 들어, AcmeCorp.Document.Document 항목 타입에 대한 변경 추적 정보는 마스터 항목 뷰 "[System.Storage].[Master!Item] 및 타입화된 검색 뷰 [AcmeCorp.Document].[Document]로부터 이용 가능하다.
(1) 마스터 검색 뷰에서의 변경 추적
마스터 검색 뷰 내의 변경 추적 정보는 요소의 생성 및 갱신 버젼에 대한 정보, 동기 파트너가 생성하고 최종 갱신한 요소의 대상인 정보, 및 생성 및 갱신을 위한 각 파트너로부터의 버젼 번호를 제공한다. 동기 관계(후술함) 내의 파트너들은 파트너 키에 의해 정의된다. 타입 [System.Storage.Store].ChangeTrackingInfo의 _ChangeTrackingInfo라는 명칭의 단일 UDT 객체가 이러한 모든 정보를 포함한 다. 타입은 System.Storage 스키마에서 정의된다. _ChangeTrackingInfo는 항목, 확장 및 관계에 대한 모든 글로벌 검색 뷰에서 이용될 수 있다. ChangeTrackingInfo의 타입 정의는 다음과 같다.
이들 속성은 다음 정보를 포함한다.
| 열 | 설명 |
| _CreationLocalTS | 로컬 기계에 의한 생성 타임 스탬프 |
| _CreatingPartnerKey | 이 엔티티를 생성한 파트너의 PartnerKey. 엔티티가 로컬 생성된 경우, 이것은 로컬 기계의 PartnerKey이다. |
| _CreatingPartnerTS | 이 엔티티가 _CreatingPartnerKey에 대응하는 파트너에서 생성된 시간의 타임 스탬프. |
| _LastUpdateLocalTS | 로컬 기계에서의 갱신 시간에 대응하는 로컬 타임 스탬프 |
| _LastUpdatingPartnerKey | 이 엔티티를 최종 갱신한 파트너의 PartnerKey. 엔티티에 대한 최종 갱신이 로컬 수행된 경우, 이것은 로컬 기계의 PartnerKey이다. |
| _LastUpdatingPartnerTS | 이 엔티티가 _LastUpdatingPartnerKey에 대응하는 파트너에서 갱신된 시간의 타임 스탬프 |
(2) 타입화된 검색 뷰에서의 변경 추적
각각의 타입화된 검색 뷰는 글로벌 검색 뷰와 동일한 정보를 제공하는 것 외 에 동기 토폴로지에서 각각의 요소의 동기 상태를 기록하는 추가 정보를 제공한다.
| 열 | 타입 | 설명 |
| <global change tracking> | ... | 글로벌 변경 추적으로부터의 정보 |
| _ChangeUnitVersions | MultiSet<ChangeUnitVersion> | 특정 요소 내의 변경 단위의 버젼 번호에 대한 설명 |
| _ElementSyncMetadata | ElementSyncMetadata | 동기화 실행 시간에만 관련된 항목에 대한 추가적인 버젼 독립 메타데이터 |
| _VersionSyncMetadata | VersionSyncMetadata | 동기화 실행 시간에만 관련된 버젼에 대한 추가 버젼 특정 메타데이터 |
b) 툼스톤
데이터 저장소는 항목, 확장 및 관계에 대한 툼스톤 정보를 제공한다. 툼스톤 뷰는 한 곳에서 살아 있는 엔티티 및 툼스톤을 가진 엔티티(항목, 확장 및 관계) 양자에 대한 정보를 제공한다. 항목 및 확장 툼스톤 뷰는 대응 객체에 대한 액세스를 제공하지 않는 반면, 관계 툼스톤은 관계 객체에 대한 액세스를 제공한다(관계 객체는 툼스톤을 가진 관계의 경우 공백이다).
(1) 항목 툼스톤
항목 툼스톤은 뷰 [System.Storage].[Tombstone!Item]을 통해 시스템으로부터 검색된다.
| 열 | 타입 | 설명 |
| ItemId | ItemId | 항목의 식별자 |
| _TypedID | TypedID | 항목의 타입 |
| <Item properties> | ... | 모든 항목에 대해 정의된 속성 |
| _RootItemId | ItemId | 이 항목을 포함하는 제1 비삽입 항목의 ItemId |
| _ChangeTrackingInfo | 타입 ChangeTrackingInfo의 CLR 인스턴스 | 이 항목에 대한 변경 추적 정보 |
| _IsDeleted | BIT | 이것은 살아 있는 항목에 대해 0이고, 툼스톤을 가진 항목에 대해 1인 플래그이다. |
| _DeletionWallclock | UTCDATETIME | 항목을 삭제한 파트너에 따르는 UTC 벽시계 날자 시간. 이것은 항목이 살아 있는 경우 공백이다. |
(2) 확장 툼스톤
확장 툼스톤은 뷰 [System.Storage].[Tombstone!Extension]을 이용하여 시스템으로부터 검색된다. 확장 변경 추적 정보는 ExtensionId 속성이 추가된 항목에 대해 제공되는 것과 유사하다.
| 열 | 타입 | 설명 |
| ItemId | ItemId | 확장을 소유하는 항목의 식별자 |
| ExtensionId | ExtensionId | 확장의 확장 ID |
| _TypedID | TypedID | 확장의 타입 |
| _ChangeTrackingInfo | 타입 ChangeTrackingInfo의 CLR 인스턴스 | 이 확장에 대한 변경 추적 정보 |
| _IsDeleted | BIT | 이것은 살아 있는 항목에 대해 0이고, 툼스톤을 가진 항목에 대해 1인 플래그이다. |
| _DeletionWallclock | UTCDATETIME | 항목을 삭제한 파트너에 따르는 UTC 벽시계 날자 시간. 이것은 확장이 살아 있는 경우 공백이다. |
(3) 관계 툼스톤
관계 툼스톤은 뷰 [System.Storage].[Tombstone!Relationship]을 통해 시스템으로부터 검색된다. 관계 툼스톤 정보는 확장에 대해 제공되는 것과 유사하다. 그러나, 관계 인스턴스의 타겟 ItemRef에 대한 추가 정보가 제공된다. 또한, 관계 객체도 선택된다.
| 열 | 타입 | 설명 |
| ItemId | ItemId | 관계를 소유하는 항목의 식별자(관계 소스 엔드포인트의 식별자) |
| RelationshipId | RelationshipId | 관계의 RelationshipId |
| _TypedID | TypedID | 관계의 타입 |
| _ChangeTrackingInfo | 타입 ChangeTrackingInfo의 CLR 인스턴스 | 이 관계에 대한 변경 추적 정보 |
| _IsDeleted | BIT | 이것은 살아 있는 항목에 대해 0이고 툼스톤을 가진 항목에 대해 1인 플래그이다. |
| _DeletionWallclock | UTCDATETIME | 관계를 삭제한 파트너에 따르는 UTC 벽시계 날짜, 시간. 이것은 관계가 살아 있는 경우 공백이다. |
| _Relationship | 관계의 CLR 인스턴스 | 이것은 살아 있는 관계에 대한 관계 객체이다. 이것은 툼스톤을 가진 관계에 대해 공백이다. |
| TargetItemReference | ItemReference | 타겟 엔드포인트의 식별자 |
(4) 툼스톤 제거
툼스톤 정보의 무제한 증가를 방지하기 위해, 데이터 저장소는 툼스톤 제거 태스크를 제공한다. 이 태스크는 툼스톤 정보가 언제 폐기될 수 있는지를 결정한다. 태스크는 로컬 생성/갱신 버젼에 대한 경계를 계산한 후, 모든 초기 툼스톤 버젼을 폐기함으로써 툼스톤 정보를 단축시킨다.
11. 헬퍼 API 및 함수
기본 맵핑도 다수의 헬퍼 함수를 제공한다. 이들 함수는 데이터 모델을 통 해 일반 동작들을 돕도록 제공된다.
a) 함수 [System.Storage].GetItem
b) 함수 [System.Storage].GetExtension
c) 함수 [System.Storage].GetRelationship
12. 메타데이터
저장소에서 표현되는 2가지 타입의 메타데이터, 즉 인스턴스 메타데이터(항목의 타입 등) 및 타입 메타데이터가 존재한다.
a) 스키마 메타데이터
스키마 메타데이터는 메타 스키마로부터의 항목 타입의 인스턴스로서 데이터 저장소에 저장된다.
b) 인스턴스 메타데이터
인스턴스 메타데이터는 항목의 타입에 대해 질의하기 위해 애플리케이션에 의해 사용되며, 항목과 관련된 확장을 찾는다. 항목에 대한 ItemId가 주어지면, 애플리케이션은 글로벌 항목 뷰에 질의하여 항목의 타입을 리턴하고 이 값을 이용 하여 메타 타입 뷰에 질의하여 항목의 선언 타입에 대한 정보를 리턴할 수 있다. 다음은 그 예이다.
E. 보안
일반적으로, 모든 보안 가능 객체는 도 26에 도시된 액세스 마스크 포맷을 이용하여 그들의 액세스 권리를 배열한다. 이 포맷에서, 낮은 순위의 16 비트는 객체 특정 액세스 관리에 대한 것이고, 다음 7 비트는 대부분의 객체 타입에 적용되는 표준 액세스 권리에 대한 것이며, 높은 순위의 4 비트는 각각의 객체 타입이 표준 및 객체 특정 권리의 세트로 맵핑될 수 있는 일반 액세스 권리를 지정하는 데 사용된다. ACCESS_SYSTEM_SECURITY 비트는 객체의 SACL에 액세스할 수 있는 권리에 대응한다.
도 26의 액세스 마스크 구조에서, 항목 특정 권리는 객체 특정 권리 섹션(낮은 순위의 16 비트)에 배치된다. 본 실시예에서 저장 플랫폼은 보안 관리를 위해 2 세트의 API, 즉 Win32 및 저장 플랫폼 API를 노출시키므로, 파일 시스템 객체 특정 권리는 저장 플랫폼 객체 특정 권리의 설계를 자극하도록 고려되어야 한다.
본 발명의 저장 플랫폼에 대한 보안 모델은 본 명세서에서 초기에 참조로 반영된 관련 출원들에 충분히 설명되어 있다. 이와 관련하여, 도 27(a, b, c 부분)은 보안 모델의 일 실시예에 따라 동일하게 보호되는 새로운 보안 영역이 기존 보 안 영역으로부터 분리되는 것을 나타내고 있다.
F. 통지 및 변경 추적
본 발명의 다른 양태에 따르면, 저장 플랫폼은 애플리케이션이 데이터 변경을 추적하는 것을 허용하는 통지 능력을 제공한다. 이 기능은 주로 휘발 상태를 유지하거나 데이터 변경 이벤트에서 비지니스 논리를 실행하는 애플리케이션들을 위한 것이다. 애플리케이션은 항목, 항목 확장 및 항목 관계 상의 통지에 등록한다. 통지는 데이터 변경이 행해진 후에 비동기적으로 전달된다. 애플리케이션은 항목, 확장 및 관계 타입은 물론 동작의 타입에 의해 통지를 필터링할 수 있다.
일 실시예에 따르면, 저장 플랫폼 API(322)는 통지에 대해 2 종류의 인터페이스를 제공한다. 첫째, 애플리케이션은 항목, 항목 확장 및 항목 관계에 대한 변경에 의해 트리거되는 단순 데이터 변경 이벤트에 등록한다. 둘째, 애플리케이션은 항목, 항목 확장 및 항목들 사이의 관계의 세트를 모니터하기 위해 "감시자" 객체를 생성한다. 감시자 객체의 상태는 저장될 수 있으며, 시스템 고장 후 또는 시스템이 연장된 기간 동안 오프라인으로 된 후에 재생성될 수 있다. 단일 통지는 다수의 갱신을 반영할 수 있다.
이러한 기능에 대한 추가적인 상세는 본 명세서에서 초기에 참고로 반영된 관련 출원에서 발견할 수 있다.
G. 통상적인 파일 시스템 연동성
전술한 바와 같이, 본 발명의 저장 플랫폼은 적어도 몇몇 실시예에서 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템의 통합 부분으로서 구현된다. 예컨대, 본 발명의 저장 플랫폼은 마이크로소프트 윈도우 오퍼레이팅 시스템 패밀리와 같은 오퍼레이팅 시스템의 통합 부분으로서 구현될 수 있다. 그 능력에 있어서, 저장 플랫폼 API는 애플리케이션 프로그램들이 오퍼레이팅 시스템과 상호작용할 수 있게 하는 오퍼레이팅 시스템 API의 일부가 된다. 따라서, 저장 플랫폼은 애플리케이션 프로그램들이 오퍼레이팅 시스템에서 정보를 저장하게 하는 수단이 되며, 따라서 저장 플랫폼의 항목 기반 데이터 모델은 오퍼레이팅 시스템의 통상적인 파일 시스템을 대체한다. 예를 들어, 마이크로소프트 윈도우 오퍼레이팅 시스템 패밀리에서 구현되는 바와 같이, 저장 플랫폼은 이 오퍼레이팅 시스템에서 구현된 NTFS 파일 시스템을 대체할 수 있다. 현재, 애플리케이션 프로그램들은 윈도우 오퍼레이팅 시스템 패밀리에 의해 노출되는 Win32 API를 통해 NTFS 파일 시스템의 서비스에 액세스한다.
그러나, NTFS 파일 시스템을 본 발명의 저장 플랫폼으로 완전히 대체하는 것은 기존 Win32 기반 애플리케이션 프로그램들의 재 코딩을 필요로하고, 이러한 재 코딩은 바람직하지 않을 수 있다는 것을 고려하면, 본 발명의 저장 플랫폼이 NTFS와 같은 기존 파일 시스템과의 소정의 연동성을 제공하는 것이 이로울 것이다. 따라서, 본 발명의 일 실시예에서, 저장 플랫폼은 Win32 프로그래밍 모델에 의존하는 애플리케이션 프로그램들이 통상의 NTFS 파일 시스템은 물론, 저장 플랫폼의 양 데이터 저장소의 콘텐츠에 액세스하는 것을 가능하게 한다. 이 때문에, 저장 플랫폼 은 연동을 용이하게 하기 위해 Win32 명명 규약의 수퍼 세트인 명명 규약을 사용한다. 또한, 저장 플랫폼은 Win32 API를 통해 저장 플랫폼 볼륨에 저장된 파일 및 디렉토리에 액세스하는 것을 지원한다.
이 기능에 대한 추가 상세는 본 명세서의 앞에서 참조로 반영된 관련 출원들에서 발견할 수 있다.
H. 저장 플랫폼 API
저장 플랫폼은 애플리케이션 프로그램들이 전술한 저장 플랫폼의 기능 및 능력에 액세스하고 데이터 저장소에 저장된 항목들에 액세스하는 것을 가능하게 하는 API를 포함한다. 이 섹션은 본 발명의 저장 플랫폼의 저장 플랫폼 API의 일 실시예를 설명한다. 이 기능에 대한 상세는 본 명세서의 앞에서 참조로 반영된 관련 출원들에서 발견할 수 있으며, 편의를 위해 이 정보의 일부가 아래 요약된다.
도 18을 참조하면, 포함 폴더는 다른 항목에 대한 유지 관계를 포함하는 항목이며, 파일 시스템 폴더의 일반 개념의 등가이다. 각 항목은 적어도 하나의 포함 폴더 내에 포함된다.
도 19는 본 발명에 따른 저장 플랫폼 API의 기본 아키텍처를 나타낸다. 저장 플랫폼 API는 SQLClient(1900)를 이용하여 로컬 데이터 저장소(302)와 대화하며, 또한 SQLClient(1900)를 이용하여 원격 데이터 저장소(예컨대, 데이터 저장소 340)와 대화할 수 있다. 로컬 저장소(302)는 또한 분산 질의 프로세서(DQP)를 이용하거나 후술하는 저장 플랫폼 동기화 서비스("Sync")를 통해 원격 데이터 저장소 (340)와 대화할 수 있다. 저장 플랫폼 API(322)는 전술한 바와 같이 애플리케이션의 가입을 통지 엔진(332)으로 전달하고 통지를 애플리케이션(예컨대, 애플리케이션 350a, 350b 또는 350c)으로 라우팅하는 데이터 저장소 통지용 브리지 API로서 기능한다. 일 실시예에서, 저장 플랫폼 API(322)는 또한 마이크로소프트 익스체인지 및 AD 내의 데이터에 액세스할 수 있도록 제한된 "제공자" 아키텍처를 정의할 수 있다.
도 20은 저장 플랫폼 API의 다양한 컴포넌트를 개략적으로 나타낸다. 저장 플랫폼 API는 다음 컴포넌트들, 즉 (1) 저장 플랫폼 요소 및 항목 타입을 나타내는 데이터 클래스(2002), (2) 객체의 지속성을 관리하고 지원 클래스(2006)를 제공하는 실행시간 프레임워크(2004), 및 (3) 저장 플랫폼 스키마로부터 CLR 클래스를 생성하는 데 사용되는 도구(2008)로 구성된다.
주어진 스키마로부터 결과되는 클래스들의 계층 구조는 그 스키마 내의 타입들의 계층 구조를 직접 반영한다. 예를 들어, 도 21A 및 21B에 도시된 것과 같은 콘택 스키마에 정의된 항목 타입들을 고려하자.
도 22는 실행 시간 프레임워크의 동작을 나타낸다. 실행시간 프레임워크는 다음과 같이 동작한다.
1. 애플리케이션(350a, 350b 또는 350c)은 저장 플랫폼 내의 항목들에 결합된다.
2. 프레임워크(2004)는 결합된 항목에 대응하는 ItemContext 객체(2202)를 생성하여 이를 애플리케이션에게 리턴한다.
3. 애플리케이션은 항목들의 집합을 얻기 위해 이 ItemContext 상에 Find를 제출하는데, 리턴된 집합은 개념적으로 (관계들로 인해) 객체 그래프(2204)이다.
4. 애플리케이션은 데이터를 변경, 삭제 및 삽입한다.
5. 애플리케이션은 Update() 메소드를 호출하여 변경을 저장한다.
도 23은 "FindAll" 동작의 실행을 나타낸다.
도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타낸다.
도 25는 File API가 근거로 하는 스키마를 나타낸다. 저장 플랫폼 API는 파일 객체를 처리하기 위한 명칭 공간을 포함한다. 이 명칭 공간은 System.Storage.Files라고 한다. System.Storage.Files 내의 클래스들의 데이터 회원들은 저장 플랫폼 저장소에 저장된 정보를 직접 반사하며, 이 정보는 파일 시스템 객체로부터 승진하거나, Win32 API를 이용하여 고유하게 생성될 수 있다. System.Storage.Files 명칭 공간은 2개의 클래스, 즉 FileItem 및 DirectoryItem을 갖는다. 이 클래스의 회원들 및 그의 메소드들은 도 25의 스키마 도면을 봄으로써 쉽게 발견될 수 있다. FileItem 및 DirectoryItem은 저장 플랫폼 API로부터 판독 전용이다. 이들을 수정하기 위해서는 Win32 API 또는 System.IO 내의 클래스를 이용해야 한다.
API와 관련하여, 프로그래밍 인터페이스(또는 보다 간단하게 인터페이스)는 하나 이상의 코드 세그먼트가 하나 이상의 다른 코드 세그먼트에 의해 제공되는 기능과 통신하거나 이에 액세스하는 것을 가능하게 하는 임의의 메카니즘, 프로세스, 프로토콜로서 보여질 수 있다. 대안으로, 프로그래밍 인터페이스는 다른 컴포넌트의 하나 이상의 메카니즘, 메소드, 함수 호출, 모듈 등에 통신 결합할 수 있는 시스템의 컴포넌트의 하나 이상의 메카니즘, 메소드, 함수 호출, 모듈, 객체 등으로서 보여질 수 있다. 앞 문장에서 "코드 세그먼트"라는 용어는 하나 이상의 명령 또는 코드 라인을 포함하는 것으로 의도되며, 적용되는 용어법에 관계 없이, 또는 코드 세그먼트들이 개별적으로 컴파일되거나, 코드 세그먼트들이 소스, 중간 또는 객체 코드로서 제공되는 것과 관계 없이, 코드 세그먼트들이 실행시간 시스템 또는 프로세스에서 사용되거나, 이들이 동일 또는 상이한 기계들 상에 또는 다수의 기계들에 분산되어 배치되거나, 코드 세그먼트들에 의해 표현되는 기능이 전적으로 소프트웨어로, 전적으로 하드웨어로, 또는 하드웨어 및 소프트웨어의 조합으로 구현되는지에 관계없이 예컨대 코드 모듈, 객체, 서브루틴, 함수 등을 포함한다.
개념적으로 프로그래밍 인터페이스는 도 30A 또는 30B에 도시된 바와 같이 일반적으로 보여질 수 있다. 도 30A는 제1 및 제2 코드 세그먼트가 통신하는 수단인 콘딧으로서 인터페이스 Interface1을 나타내고 있다. 도 30B는 시스템의 제1 및 제2 코드 세그먼트가 매체(M)를 통해 통신하는 것을 가능하게 하는 인터페이스 객체 I1 및 I2(이들은 제1 및 제2 코드 세그먼트의 일부이거나 아닐 수도 있다)를 포함하는 것으로서 인터페이스를 도시하고 있다. 도 30B를 볼 때, 인터페이스 객체 I1 및 I2를 동일 시스템의 개별 인터페이스로서 간주하고, 또한 객체 I1 및 I2 플러스 매체(M)이 인터페이스를 포함하는 것으로 간주할 수 있다. 도 30A 및 30B는 양방향 흐름, 및 흐름의 각 측 상의 인터페이스를 도시하고 있지만, 소정의 구 현들은 일 방향으로의 정보 흐름을 갖거나(또는 후술하는 바와 같이 정보 흐름이 없거나), 한쪽에만 인터페이스 객체를 가질 수 있다. 예를 들어, API, 엔트리 포인트, 메소드, 함수, 서브루틴, 원격 프로시저 호출 및 COM 인터페이스와 같은 용어들은 프로그래밍 인터페이스의 정의 내에 포함되지만, 이것으로 한정되는 것은 아니다.
프로그래밍 인터페이스의 양태들은 제1 코드 세그먼트가 제2 코드 세그먼트로 정보를 전송할 수 있게 하는 메소드(여기서, "정보"는 넓은 의미로 사용되며, 데이터, 명령, 요구 등을 포함한다); 제2 코드 세그먼트가 정보를 수신할 수 있게 하는 메소드; 및 정보의 구조, 시퀀스, 신택스, 조직, 스키마, 타이밍 및 내용을 포함할 수 있다. 이와 관련하여, 기반 전송 매체 자체는 정보가 인터페이스에 의해 정의된 방식으로 전송되는 한은 매체가 유선인지 무선인지, 또는 이들의 조합인지에 관계없이 인터페이스의 동작에 중요하지 않을 수 있다. 소정의 상황에서, 하나의 코드 세그먼트가 제2 코드 세그먼트에 의해 수행되는 기능에 간단히 액세스할 때와 같이 정보 전송이 다른 메카니즘을 통하거나(예컨대, 버퍼, 파일 등에 위치한 정보는 코드 세그먼트들 사이의 정보 흐름으로부터 분리된다) 존재하지 않을 수 있을 때 정보는 통상적인 의미에서 한 방향 또는 양 방향으로 전송되지 않을 수 있다. 이러한 양태들 중 임의의 양태 또는 모든 양태는 예를 들어 코드 세그먼트들이 느슨하게 결합되거나 밀접하게 결합된 구성에서 시스템의 일부인지의 여부에 따라 주어진 상황에서 중요할 수 있으며, 따라서 이 리스트는 예시적인 것일 뿐 제한적이 아닌 것으로 간주되어야 한다.
이러한 프로그래밍 인터페이스의 개념은 당업자에게 공지되어 있으며, 전술한 본 발명의 상세한 설명으로부터 명백하다. 그러나, 프로그래밍 인터페이스를 구현하는 다른 방법들이 있으며, 명백하게 배제되지 않은 한, 이들도 본 명세서의 끝에 설명되는 청구범위에 포함되는 것으로 의도된다. 그러한 다른 방법들은 도 30A 및 30B의 간단한 도면보다 복잡한 것으로 보일 수 있지만, 그럼에도 이들은 동일한 전체 결과를 달성하는 유사한 기능을 수행한다. 이제, 프로그래밍 인터페이스의 몇몇 예시적인 대체 구현을 간단히 설명한다.
인수 분해: 하나의 코드 세그먼트에서 다른 코드 세그먼트로의 통신은 통신을 다수의 개별 통신으로 분해함으로써 간접적으로 완수될 수 있다. 이것은 도 31A 및 31B에 개략적으로 도시되어 있다. 도시된 바와 같이, 몇몇 인터페이스는 분할 가능한 기능 세트에 의해 설명될 수 있다. 따라서, 도 30A 및 30B의 인터페이스 기능은, 수학적으로 24 또는 2×2×3×2를 제공할 수 있는 것과 같이, 동일한 결과를 달성할 수 있도록 인수 분해될 수 있다. 따라서, 도 31A에 도시된 바와 같이, 인터페이스 Interface1에 의해 제공되는 기능은 동일한 결과를 달성하면서 인터페이스의 통신을 변환하기 위해 다수의 인터페이스 Interface1A, Interface1B, Interface1C 등으로 세분될 수 있다. 도 31B에 도시된 바와 같이, 인터페이스 I1에 의해 제공되는 기능은 동일한 결과를 달성하면서 다수의 인터페이스 I1a, I1b, I1c 등으로 세분될 수 있다. 마찬가지로, 제1 코드 세그먼트로부터 정보를 수신하는 제2 코드 세그먼트의 인터페이스 I2는 다수의 인터페이스 I2a, I2b, I2c 등으로 인수 분해될 수 있다. 인수 분해시, 제1 코드 세그먼트에 포함되는 인터페이스의 수는 제2 코드 세그먼트에 포함되는 인터페이스의 수와 일치할 필요는 없다. 도 31A 및 31B의 경우들 중 어느 하나에서, 인터페이스 Interface1 및 I1의 기능적인 사상은 도 30A 및 30B와 각각 동일하게 유지된다. 인터페이스의 인수 분해는 또한 결합, 교환 및 다른 수학적 특성을 따를 수 있으며, 따라서 인수 분해는 인식하기 어려울 수 있다. 예를 들어, 동작들의 순서화는 중요하지 않을 수 있으며, 결과적으로 하나의 인터페이스에 의해 수행되는 기능은 이 인터페이스에 도달하기 전에 다른 코드 또는 인터페이스에 의해 수행되거나, 시스템의 개별 1에 의해 제공되는 기능은 동일한 결과를 달성하면서 다수의 인터페이스 I1a, I1b, I1c 등으로 세분될 수 있다. 마찬가지로, 제1 코드 세그먼트로부터 정보를 수신하는 제2 코드 세그먼트의 인터페이스 I2는 다수의 인터페이스 I2a, I2b, I2c 등으로 인수 분해될 수 있다. 인수 분해시, 제1 코드 세그먼트에 포함되는 인터페이스의 수는 제2 코드 세그먼트에 포함되는 인터페이스의 수와 일치할 필요는 없다. 도 31A 및 31B의 경우들 중 어느 하나에서, 인터페이스 Interface1 및 I1의 기능적인 사상은 도 30A 및 30B와 각각 동일하게 유지된다. 인터페이스의 인수 분해는 또한 결합, 교환 및 다른 수학적 특성을 따를 수 있으며, 따라서 인수 분해는 인식하기 어려울 수 있다. 예를 들어, 동작들의 순서화는 중요하지 않을 수 있으며, 결과적으로 하나의 인터페이스에 의해 수행되는 기능은 이 인터페이스에 도달하기 전에 다른 코드 또는 인터페이스에 의해 수행되거나, 시스템의 개별 컴포넌트에 의해 수행될 수 있다. 더욱이, 동일 결과를 달성하는 상이한 함수 호출을 다양한 방법이 있다는 것을 프로그래밍 분야의 당업자는 이해할 수 있다.
재정의: 몇몇 경우에, 여전히 의도한 결과를 달성하면서 프로그래밍 인터페이스의 소정의 양태들(예컨대, 파라미터들)을 무시, 추가 또는 재정의할 수 있다. 이것은 도 32A 및 32B에 도시되어 있다. 예컨대, 도 30A의 인터페이스 Interface1이 3개의 파라미터, 즉 입력, 정확도 및 출력을 포함하고 제1 코드 세그먼트에서 제2 코드 세그먼트로 발행되는 호출인 함수 호출 Square(input, precision, output)를 포함하는 것으로 가정한다. 도 32A에 도시된 바와 같이, 중간 파라미터인 정확도가 주어진 시나리오에서 중요하지 않은 경우, 이 파라미터는 무시되거나, (이 상황에서) 의미 없는 파라미터로 대체될 수도 있다. 또한, 중요하지 않은 추가 파라미터를 추가할 수도 있다. 어느 경우에나, 입력이 제2 코드 세그먼트에 의해 제곱된 후 출력이 리턴되는 한 제곱의 기능은 달성될 수 있다. 정확도는 매우 양호하게 컴퓨팅 시스템의 소정의 다운스트림 또는 다른 부분에 의미 있는 파라미 터일 수 있으나, 정확도가 제곱을 계산하는 좁은 목적에 필요하지 않은 것으로 인식되면, 정확도는 대체되거나 무시될 수 있다. 예컨대, 유효한 정확도 값을 전달하는 대신, 생일과 같은 의미 없는 값이 결과에 악영향을 미치지 않고 전달될 수 있다. 마찬가지로, 도 32B에 도시된 바와 같이, 인터페이스 I1은 파라미터를 무시하거나 인터페이스에 추가하도록 재정의된 인터페이스 I1'로 대체된다. 인터페이스 I2는 마찬가지로 불필요한 파라미터, 또는 그 밖의 곳에서 처리될 수 있는 파라미터를 무시하도록 재정의된 인터페이스 I2'로 재정의될 수 있다. 여기서 요점은 몇몇 경우에 프로그래밍 인터페이스가 소정의 목적에 필요하지 않은 파라미터들과 같은 양태들을 포함할 수 있으며, 따라서 이들은 무시 또는 재정의되거나, 다른 목적을 위해 그 밖의 다른 곳에서 처리될 수 있다는 점이다.
인라인 코딩: 2개의 개별 코드 모듈의 기능의 일부 또는 전부를 병합하여 이들 사이의 인터페이스가 형태를 변경하도록 하는 것이 가능하다. 예컨대, 도 30A 및 30B의 기능은 각각 도 33A 및 33B의 기능으로 변환될 수 있다. 도 33A에서, 도 30A의 이전 제1 및 제2 코드 세그먼트들은 이들 양자를 포함하는 모듈로 병합된다. 이 경우, 코드 세그먼트들은 여전히 서로 통신할 수 있지만, 인터페이스는 단일 모듈에 보다 적절한 형태로 적응될 수 있다. 따라서, 예를 들면, 정형적인 호출 및 리턴 명령문이 더 이상 필요하지 않을 수 있지만, 인터페이스 Interface1에 따르는 유사한 처리 또는 응답이 여전히 실행될 수 있다. 마찬가지로, 도 33B에 도시된 바와 같이, 도 30B로부터의 인터페이스 I2의 일부(또는 전부)는 인터페이스 I1 내에 인라인으로 작성되어 인터페이스 I1'가 형성될 수 있다. 도시된 바와 같이, 인 터페이스 I2는 I2a 및 I2b로 분할되며, 인터페이스 부분 I2a는 인터페이스 I1과 함께 인라인 코딩되어 인터페이스 I1''이 형성된다. 구체적인 예로서, 도 30B로부터의 인터페이스 I1이, 인터페이스 I2에 의해 수신되고 제2 코드 세그먼트에 의해 입력으로 전달된 값을 처리한 후(입력 값을 제곱함) 제곱된 결과를 출력으로 전달하는 함수 호출 square(input, output)을 수행하는 것으로 가정한다. 이 경우, 제2 코드 세그먼트에 의해 수행되는 처리(입력 제곱)는 인터페이스로의 호출 없이 제1 코드 세그먼트에 의해 수행될 수 있다.
분리: 하나의 코드 세그먼트에서 다른 코드 세그먼트로의 통신은 통신을 다수의 개별 통신으로 분리함으로써 간접적으로 달성될 수 있다. 이것은 도 34A 및 34B에 개략 도시되어 있다. 도 34A에 도시된 바와 같이, 하나 이상의 미들웨어(오리지날 인터페이스로부터 기능 및/또는 인터페이스 기능들을 분리하므로 분리 인터페이스)가 제1 인터페이스 Interface1 상의 통신들을 변환하여 이들이 상이한 인터페이스, 이 경우 인터페이스 Interface2A, Interface2B 및 Interface2C를 따르도록 하기 위해 제공된다. 이것은 예를 들어 인터페이스1 프로토콜에 따라 예컨대 오퍼레이팅 시스템과 통신하도록 설계된 설치 기반 애플리케이션들이 존재하지만, 이후 오퍼레이팅 시스템이 상이한 인터페이스, 이 경우 인터페이스 Interface2A, Interface2B 및 Interface2C를 사용하도록 변경된 경우에 행해질 수 있다. 요점은, 제2 코드 세그먼트에 의해 사용되는 오리지날 인터페이스가 변경되어, 제1 코드 세그먼트에 의해 사용되는 인터페이스와 더 이상 호환이 되지 않으며, 따라서 신구 인터페이스들을 호환 가능하게 하기 위해 매개물이 사용된다는 점이다. 마찬 가지로, 도 34B에 도시된 바와 같이, 인터페이스 I1로부터 통신을 수신하는 분리 인터페이스 DI1 및 인터페이스 기능을 예컨대 인터페이스 I2a 및 I2b로 전송하는 분리 인터페이스 DI2를 구비한 제3 코드 세그먼트가 도입될 수 있는데, I2a 및 I2b는 DI2와 함께 동작하도록 재설계되지만 동일한 기능적 결과를 제공한다. 마찬가지로, DI1 및 DI2는 동일하거나 유사한 기능적 결과를 제공하면서 도 30B의 인터페이스 I1 및 I2의 기능을 새로운 오퍼레이팅 시스템으로 전달하도록 함께 동작할 수 있다.
재작성: 또 하나의 가능한 변형은 코드를 동적으로 재작성하여 인터페이스 기능을, 동일한 전체 결과를 달성하는 그 외의 다른 것으로 대체하는 것이다. 예컨대, 중간 언어로 표현된 코드 세그먼트가 실행 환경(예컨대, 네트 프레임워크, 자바 실행시간 환경 또는 다른 유사한 실행시간 타입 환경에 의해 제공됨)에서 JIT(Just-in-Time) 컴파일러 또는 인터프리터로 제공되는 시스템이 존재할 수 있다. JIT 컴파일러는 제1 코드 세그먼트에서 제2 코드 세그먼트로 통신들을 동적으로 변환하도록, 즉 이들 통신을 제2 코드 세그먼트(오리지날 또는 다른 제2 코드 세그먼트)에 의해 요구될 수 있는 바와 같이 상이한 인터페이스에 따르도록 하기 위해 재작성될 수 있다. 이것은 도 35A 및 35B에 도시되어 있다. 도 35A에 도시된 바와 같이, 이러한 접근법은 전술한 분리 시나리오와 유사하다. 이것은 예컨대 설치 기반 애플리케이션들이 Interface1 프로토콜에 따라 오퍼레이팅 시스템과 통신하도록 설계되지만, 이후 오퍼레이팅 시스템이 상이한 인터페이스를 사용하도록 변경되는 경우에 행해질 수 있다. JIT 컴파일러는 통신들이 설치 기반 애플리케이 션들에서 오퍼레이팅 시스템의 새로운 인터페이스로 온더플라이로 따르도록 하기 위해 사용될 수 있다. 도 35B에 도시된 바와 같이, 인터페이스를 동적으로 재작성하는 이러한 접근법은 인터페이스를 동적으로 인수 분해하거나 변경하기 위해 적용될 수도 있다.
대체 실시예들을 통해 인터페이스와 동일하거나 유사한 결과를 달성하는 전술한 시나리오들은 또한 다양한 방법으로, 직렬 및/또는 병렬로, 또는 다른 중재 코드와 함께 조합될 수 있다는 점에 유의해야 한다. 따라서, 전술한 대체 실시예들은 서로 배타적이지 않고, 혼합, 매칭 및 조합되어, 도 30A 및 30B에 제공된 일반 시나리오와 동일하거나 동등한 시나리오를 생성할 수 있다. 또한, 대부분의 프로그래밍 구조에서와 같이, 본 명세서에는 설명되지 않을 수 있지만 본 발명의 사상 및 범위에 의해 표현되는 인터페이스의 동일 또는 유사 기능을 달성하는 다른 유사한 방법들이 존재함에 유의해야 하는데, 즉 이것은 적어도 부분적으로 인터페이스의 값의 기초가 되는 인터페이스에 의해 표현되는 기능, 및 인터페이스에 의해 가능하게 되는 이로운 결과들이라는 점에 유의한다.
III. 동기화 API
동기화에 대한 여러 접근법은 항목 기반 하드웨어/소프트웨어 인터페이스 시스템에서 가능하다. 섹션 A는 본 발명의 여러 실시예를 개시하며, 섹션 B는 동기화를 위한 API의 다양한 실시예에 초점을 둔다.
A. 동기화 개요
본 발명의 여러 실시예에서, 그리고 도 3과 관련하여, 저장 플랫폼은 (i) 저장 플랫폼의 다수의 인스턴스(각각 그 자신의 데이터 저장소(302)를 가짐)가 융통성 있는 규칙 세트에 따라 그들의 콘텐츠의 부분들을 동기화시키는 것을 허용하고, (ii) 제3자가 본 발명의 저장 플랫폼의 데이터 저장소를 독점 프로토콜을 구현하는 다른 데이터 소스와 동기화하기 위한 기반 구조를 제공하는 동기화 서비스(330)를 제공한다.
저장 플랫폼 대 저장 플랫폼 동기화는 참여 "사본들"의 그룹 사이에서 발생한다. 예컨대, 도 3을 참조하면, 아마도 다른 컴퓨터 시스템 상에서 실행되는 저장 플랫폼의 또 하나의 인스턴스의 제어하에 저장 플랫폼(300)의 데이터 저장소(302)와 다른 원격 데이터 저장소(338) 사이의 동기화를 제공하는 것이 바람직할 수 있다. 이 그룹의 모든 회원은 임의의 주어진 시간에 임의의 주어진 사본을 반드시 알 필요는 없다.
다른 사본들은 독립적으로(즉, 동시에) 변경을 행할 수 있다. 동기화 프로세스는 모든 사본이 다른 사본들에 의해 행해진 변경을 인식하게 만드는 것으로 정의된다. 동기화 능력은 본질적으로 멀티 마스터이다.
본 발명의 동기화 능력은 사본들이
- 다른 사본이 어떠한 변경을 알고 있는지를 판정하고,
- 이 사본이 알지 못하는 변경에 대한 정보를 요구하고,
- 다른 사본이 알지 못하는 변경에 대한 정보를 전달하고,
- 2개의 변경이 언제 서로 충돌하는지를 판정하고,
- 변경을 로컬 적용하고,
- 수렴을 보장하기 위해 충돌 해결을 다른 사본들에 전달하고,
- 충돌 해결을 위한 지정된 정책에 기초하여 충돌을 해결하는 것을 허용한다.
1. 저장 플랫폼 대 저장 플랫폼 동기화
본 발명의 저장 플랫폼의 동기화 서비스(330)의 주요 응용은 저장 플랫폼의 다수의 인스턴스(각각 그 자신의 데이터 저장소를 가짐)를 동기화하는 것이다. 동기화 서비스는 저장 플랫폼 스키마 레벨에서(데이터베이스 엔진(314)의 기본 테이블이 아님) 동작한다. 따라서, 예를 들면, "범위(Scopes)"는 후술하는 바와 같이 동기화 세트를 정의하는 데 사용된다.
동기화 서비스는 "순수 변경(net change)"의 원리로 동작한다. 동기화 서비스는 개별 동작들(예컨대, 트랜잭션 복제)을 기록하고 전송하는 것이 아니라, 이 동작들의 최종 결과를 전송하며, 따라서 종종 다수의 동작의 결과들을 단일 결과 변경으로 통합한다.
동기화 서비스는 일반적으로 트랜잭션 경계를 존중하지 않는다. 즉, 단일 트랜잭션에서 저장 플랫폼 데이터 저장소에 대해 2개의 변경이 행해진 경우, 이들 변경이 모든 다른 사본들에 최소 단위로(atomically) 적용된다는 보장이 없는데, 즉 하나의 변경은 다른 변경 없이도 나타날 수 있다. 이 원리에 대한 예외는, 2개 의 변경이 동일 트랜잭션에서 동일 항목에 대해 행해진 경우, 이들 변경은 최소 단위로 다른 복제들로 전송되고 적용되는 것이 보장된다는 것이다. 따라서, 항목들은 동기화 서비스의 일관성 단위이다.
a) 동기화(Sync) 제어 애플리케이션
임의의 애플리케이션이 동기화 서비스에 연결되어, 동기화 동작을 개시할 수 있다. 이러한 애플리케이션은 동기화를 행하는 데 필요한 파라미터들을 모두 제공한다(아래의 동기 프로파일 참조). 이 애플리케이션은 본 명세서에서 동기화 제어 애플리케이션(SCA)이라 한다.
2개의 저장 플랫폼 인스턴스를 동기화할 때, 동기화는 SCA에 의해 한쪽에서 개시된다. SCA는 원격 파트너와 동기화하기 위해 로컬 동기화 서비스에 알린다. 다른 쪽에서는 시발 기계로부터 동기화 서비스에 의해 전송된 메시지에 의해 동기화 서비스가 개시된다. 동기화 서비스는 도달 기계 상에 존재하는 지속적인 구성 정보(아래 맵핑 참조)에 기초하여 응답한다. 동기화 서비스는 스케쥴에 따라 또는 이벤트에 응답하여 실행될 수 있다. 이들 경우에, 스케쥴을 구현하는 동기화 서비스가 SCA가 된다.
동기화를 가능하게 하기 위하여, 두 단계가 취해져야 한다. 먼저, 스키마 설계자는 저장 플랫폼 스키마에 적절한 동기화 시맨틱(후술하는 바와 같이 변경 단위를 나타냄)을 주석으로 달아야 한다. 둘째, 동기화는 동기화에 참여할 저장 플랫폼의 인스턴스를 가진 기계들 모두에서 적절히 구성되어야 한다.
b) 스키마 주석 달기
동기화 서비스의 기본 개념은 변경 단위의 개념이다. 변경 단위는 저장 플랫폼에 의해 개별적으로 추적되는 스키마의 가장 작은 부분이다. 모든 변경 단위에 대해, 동기화 서비스는 변경 단위가 최종 동기화 이후 변경되었는지의 여부를 결정할 수 있다.
스키마에 변경 단위를 표시하는 것은 여러 목적을 갖는다. 먼저, 이것은 동기화 서비스가 유선 상에서 얼마나 기탄없는지를 판정한다. 변경 단위 내에서 변경이 행해질 때, 전체 변경 단위는 다른 사본들로 전송되는데, 이는 동기화 서비스가 변경 단위의 어느 부분이 변경되었는지를 알지 못하기 때문이다. 둘째, 이것은 충돌 검출의 입도를 결정한다. 2개의 동시 변경(이 용어는 후속 섹션에서 상세히 정의된다)이 동일 변경 단위에 대해 행해질 때, 동기화 서비스는 충돌을 일으키는 반면, 동시 변경이 상이한 변경 단위들에 대해 행해지는 경우에는 충돌이 발생하지 않고, 변경들은 자동으로 병합된다. 셋째, 이것은 시스템에 의해 유지되는 메타데이터의 양에 강한 영향을 미친다. 동기화 서비스 메타데이터의 많은 부분은 변경 단위에 대해 유지되며, 따라서 변경 단위들이 동기화의 오버헤드를 보다 적게 증가시키게 된다.
변경 단위의 정의는 올바른 트레이드오프의 발견을 필요로 한다. 이 때문에, 동기화 서비스는 스키마 설계자가 프로세스에 참여하는 것을 허용한다.
일 실시예에서, 동기화 서비스는 요소보다 큰 변경 단위를 지원하지 않는다. 그러나, 동기화 서비스는 스키마 설계자가 요소보다 작은 변경 단위를 지정할 수 있는 능력, 즉 요소의 다수의 속성을 개별 변경 단위로 그룹화할 수 있는 능력을 지원한다. 이 실시예에서, 이것은 다음의 신택스를 이용하여 달성된다.
c) 동기화 구성
동기화에서 자신들의 데이터의 소정 부분을 유지하기를 원하는 저장 플랫폼 파트너들의 그룹은 동기화 공동체로 지칭된다. 공동체의 회원들이 동기화 상태에 머물기를 원하는 동안, 이들은 정확히 동일한 방식으로 데이터를 표시할 필요는 없는데, 즉 동기화 파트너들은 이들이 동기화하고 있는 데이터를 변환할 수 있다.
피어 대 피어 시나리오에서, 피어들이 이들의 파트너들 모두에 대한 변환 맵 핑을 유지하는 것은 비현실적이다. 대신에, 동기화 서비스는 "공동체 폴더"를 정의하는 접근법을 취한다. 공동체 폴더는 모든 공동체 회원들이 동기화되고 있는 가상적인 "공유 폴더"를 나타내는 추상 개념이다.
이 개념은 일례에 의해 가장 잘 설명된다. 조(Joe)가 동기화 상태에서 자신의 여러 컴퓨터들의 내 문서 폴더들을 유지하기를 원하는 경우, 조는 예컨대 JoesDocuments라고 하는 공동체 폴더를 정의한다. 그러면, 모든 컴퓨터에서 조는 가상적인 JoesDocuments 폴더와 로컬 내 문서 폴더 사이의 맵핑을 구성한다. 이 시점으로부터, 조의 컴퓨터들이 서로 동기화될 때, 이들은 이들의 로컬 항목들이 아니라 JoesDocuments 내의 문서들에 관해 대화한다. 이러한 방식으로, 조의 모든 컴퓨터들은 다른 컴퓨터들이 누구인지를 알지 않고도 서로를 이해하게 되며, 공동체 폴더는 동기화 공동체의 공통어가 된다.
동기화 서비스의 구성은 3 단계, 즉 (1) 로컬 폴더와 공동체 폴더 간의 맵핑을 정의하는 단계, (2) 무엇이 동기화되는지(예컨대, 누구와 동기화되는지, 어느 서브 세트가 전송되어야 하고 수신되어야 하는지)를 결정하는 동기화 프로파일을 정의하는 단계, 및 (3) 상이한 동기화 프로파일들이 실행되어야 하는 스케쥴 또는 이들을 수동으로 실행하는 스케쥴을 정의하는 단계로 구성된다.
(1) 공동체 폴더-맵핑
공동체 폴더 맵핑은 개별 기계들 상에 XML 구성 파일로서 저장된다. 각각의 맵핑은 다음 스키마를 갖는다.
/mappings/communityFolder
이 요소는 이 맵핑의 대상인 공동체 폴더의 명칭을 정한다. 명칭은 폴더의 신택스 규칙을 따른다.
/mappings/localFolder
이 요소는 맵핑이 변환되는 로컬 폴더의 명칭을 정한다. 이 명칭은 폴더의 신택스 규칙을 따른다. 폴더는 맵핑이 유효하도록 이미 존재해야 한다. 이 폴더 내의 항목들은 이 맵핑에 대한 동기화를 위해 고려된다.
/mappings/transformations
이 요소는 공동체 폴더에서 로컬 폴더로 그리고 그 역으로 항목들을 변환하는 방법을 정의한다. 존재하지 않거나 비어 있는 경우, 변환은 행해지지 않는다. 구체적으로 이것은 어떠한 ID도 맵핑되지 않는다는 것을 의미한다. 이 구성은 주로 폴더의 캐시를 생성하는 데 유용하다.
/mappings/transformation/mapIDs
이 요소는 공동체 ID들이 다시 사용되는 것이 아니라 새로 생성된 로컬 ID들이 공동체 폴더로부터 맵핑된 항목들 모두에 대해 할당될 것을 요구한다. 동기화 실행 시간은 항목들을 이리저리 변환하기 위해 ID 맵핑을 유지한다.
/mappings/transformations/localRoot
이 요소는 공동체 폴더 내의 모든 루트 항목들이 지정된 루트의 자식들이 될 것을 요구한다.
/mappings/runAs
이 요소는 누구의 권한 하에 이 맵핑에 대한 요구들이 처리되는지를 제어한다. 존재하지 않는 경우, 송신자가 가정된다.
/mappings/runAs/sender
이 요소의 존재는 이 맵핑에 대한 메시지의 송신자가 구현되어 그의 신임 하에 요구들이 처리되어야 한다는 것을 지시한다.
(2) 프로파일
동기화 프로파일은 동기화를 개시하는 데 필요한 파라미터들의 종합 세트이다. 이것은 동기화 개시를 위해 SCA에 의해 동기화 실행 시간으로 제공된다. 저장 플랫폼 대 저장 플랫폼 동기화에 대한 동기화 프로파일은 다음 정보를 포함한다.
- 변경에 대한 소스 및 목표로서 기능하는 로컬 폴더
- 동기화될 원격 폴더 명칭- 이 폴더는 위에서 정의된 맵핑을 통해 원격 파트너로부터 공개되어야 한다.
- 방향-동기화 서비스는 전송만을, 수신만을, 그리고 전송-수신 동기화를 지원한다.
- 로컬 필터-어떤 로컬 정보가 원격 파트너에게 전송될지를 선택한다. 로컬 폴더에 대한 저장 플랫폼 질의로서 표현된다.
- 원격 필터- 원격 파트너로부터 어떤 원격 정보가 검색될지를 선택한다. 공동체 폴더에 대한 저장 플랫폼 질의로서 표현된다.
- 변환-로컬 포맷에 대해 어떻게 항목을 변환할지를 정의한다.
- 로컬 보안-원격 엔드포인트로부터 검색된 변경들이 원격 엔드포인트(의인화됨)의 허가 하에 또는 로컬 동기화를 개시하는 사용자의 허가 하에 적용되어야 하는지를 지정한다.
- 충돌 해결 정책-충돌이 거부, 로그 또는 자동 해결되어야 하는지를 지정한다. 후자의 경우, 어느 충돌 해결자를 이용할지는 물론 그에 대한 구성 파라미터를 지정한다.
동기화 서비스는 동기화 프로파일들의 간단한 구축을 허용하는 실행시간 CLR 클래스를 제공한다. 프로파일들은 또한 쉬운 저장을 위해 XML 파일들에 대해 일련화될 수 있다(종종 스케쥴과 함께). 그러나, 모든 프로파일이 저장되는 저장 플랫폼 내의 표준 장소는 없으며, SCA는 프로파일을 계속 유지하지 않고 프로파일을 스폿 상에 구축해도 좋다. 동기화를 개시하기 위해 로컬 맵핑을 갖출 필요는 없다는 점에 유의한다. 모든 동기화 정보는 프로파일에서 지정될 수 있다. 그러나, 원격 측에 의해 개시되는 동기화 요구에 응답하기 위해서는 맵핑이 필요하다.
(3) 스케쥴
일 실시예에서, 동기화 서비스는 그 자신의 스케쥴링 기반 구조를 제공하지 않는다. 그 대신, 이 태스크를 수행할 다른 컴포넌트, 즉 마이크로소프트 윈도우 오퍼레이팅 시스템에서 이용할 수 있는 윈도우 스케쥴러에 의존한다. 동기화 서비스는 SCA로서 동작하고 XML 파일에 저장된 동기화 프로파일에 기초하여 동기화를 트리거하는 명령 라인 유틸리티를 포함한다. 이 유틸리티는 스케쥴에 따라, 또는 사용자 로그온 또는 로그오프와 같은 이벤트에 응답하여 동기화를 실행하는 윈도우 스케쥴러를 구성하는 것을 용이하게 한다.
d) 충돌 처리
동기화 서비스에서의 충돌 처리는 3 단계, 즉 (1) 변경 적용 시간에 발생하는 충돌 검출 단계-이 단계는 변경이 안전하게 적용될 수 있는지를 판정한다-; (2) 자동 충돌 해결 및 로깅 단계-이 단계 동안(충돌이 검출된 직후 발생함), 충돌이 해결될 수 있는지를 알아 보기 위해 자동 충돌 해결자가 참고되며, 해결될 수 없는 경우, 충돌은 선택적으로 로그된다-; 및 (3) 충돌 검사 및 해결 단계-이 단계는 소정의 충돌이 로그되어 있는 경우에 발생하며, 동기화 세션과 관련 없이 발생하는데, 이때 로그된 충돌들이 해결되어 로그로부터 제거될 수 있다.
(1) 충돌 검출
이 실시예에서, 동기화 서비스는 두 종류의 충돌, 즉 지식 기반 충돌 및 제한 기반 충돌을 검출한다.
(a) 지식 기반 충돌
지식 기반 충돌은 2개의 사본이 동일 변경 단위에 대해 독립적인 변경을 행할 때 발생한다. 2개의 변경은 이들이 서로에 대한 지식 없이 이루어지는 경우 독 립적이라고 일컬어지는데, 즉 제1 변경의 버젼은 제2 변경에 대한 지식에 의해 커버되지 않으며, 그 반대의 경우도 그러하다. 동기화 서비스는 전술한 바의 사본의 지식에 기초한 모든 충돌을 자동 검출한다.
충돌을 종종, 변경 단위의 버젼 이력 내의 포크(fork)로 간주하는 것이 도움이 될 수 있다. 변경 단위의 생애에 충돌이 발생하지 않는 경우, 그 버젼 이력은 간단한 체인이며, 즉 각각의 변경은 이전 변경 후에 발생한다. 지식 기반 충돌의 경우, 2개의 변경은 동시에 발생하여, 체인 분할되어 버젼 트리가 되게 한다.
(b) 제한 기반 충돌
독립적인 변경들이 함께 적용될 때 보전 제한을 위반하는 경우가 있다. 예컨대, 동일 디렉토리에 동일 명칭을 가진 파일을 생성하는 2개의 복제는 이러한 충돌을 발생시킬 수 있다.
제한 기반 충돌은 2개의 독립적인 변경(지식 기반 충돌과 똑같이)을 수반하지만, 이들은 동일 변경 단위에 영향을 미치지 않는다. 오히려, 이들은 상이하지만 그 사이에 제한이 존재하는 변경 단위들에 영향을 미친다.
동기화 서비스는 변경 적용시에 제한 위반을 검출하여 제한 기반 충돌을 자동으로 발생시킨다. 제한 기반 충돌의 해결은 대개 제한을 위반하지 않는 방식으로 변경을 수정하는 고객 모드를 요구한다. 동기화 서비스는 이를 행하기 위한 범용 메카니즘을 제공하지 않는다.
(2) 충돌 처리
충돌이 검출된 때, 동기화 서비스는 (동기화 프로파일에서 동기화 개시자에 의해 선택되는) 3가지 동작 중 하나, 즉 변경을 거부하고 이것을 다시 송신자에게 리턴하거나, (2) 충돌을 충돌 로그에 로그하거나, (3) 충돌을 자동으로 해결하는 동작을 취할 수 있다.
변경이 거부되면, 동기화 서비스는 변경이 사본에 도달하지 않는 것처럼 동작한다. 부정 응답이 발신자에게 전송된다. 이러한 해결 정책은 주로 충돌의 로깅이 가능하지 않은 헤드 없는 사본들(예를 들어, 파일 서버)에 유용하다. 그 대신, 이러한 사본들은 다른 사본들이 충돌을 거절함으로써 충돌을 처리하도록 시킨다.
동기 개시자들은 이들의 동기화 프로파일에 충돌 해결을 구성한다. 동기화 서비스는 다음과 같은 방법으로, 즉 성공할 때까지 하나씩 시도될 충돌 해결자들의 리스트를 지정한 후, 충돌 해결자들을 충돌 타입들에 연관시킴으로써, 즉 갱신-갱신 지식 기반 충돌들을 하나의 해결자로 전송하지만 다른 모든 충돌들을 로그로 전송함으로써 단일 프로파일에 다수의 충돌 해결자를 결합시키는 것을 지원한다.
(a) 자동 충돌 해결
동기화 서비스는 다수의 디폴트 충돌 해결자를 제공한다. 이 리스트는 다음을 포함한다.
- 로컬 윈(win): 로컬 저장 데이터를 가진 충돌에서의 경우, 들어오는 변경 을 무시한다.
- 원격 윈: 들어오는 변경을 가진 충돌에서의 경우, 로컬 데이터를 무시한다.
- 최종 작성자 윈: 변경의 타임 스탬프에 기초하여 변경 단위마다 로컬 윈 또는 원격 윈을 선택한다(일반적으로 동기화 서비스는 클럭 값에 의존하지 않는데, 이 충돌 해결자는 이 규칙에 대한 단 하나의 예외이다).
- 결정론적임: 모든 사본 상에서 동일하도록, 그렇지 않은 경우 무의미한 것을 보장하는 방식으로 위너를 선택하는데, 동기화 서비스의 일 실시예에서는 파트너 ID의 사전 편집 비교를 이용하여 이 기능을 구현한다.
또한, ISV는 그 자신의 충돌 해결자를 구현하고 설치할 수 있다. 고객 충돌 해결자들은 구성 파라미터들을 받아들일 수 있는데, 이 파라미터들은 동기화 프로파일의 충돌 해결 섹션에서 SCA에 의해 지정되어야 한다.
충돌 해결자는 충돌을 처리할 때 (충돌 변경 대신에) 수행되어야 하는 동작들의 리스트를 실행시간으로 리턴한다. 이후, 동기화 서비스는 충돌 처리자가 고려하고 있는 것을 포함하도록 적절히 조정된 원격 지식을 가진 이들 동작들을 적용한다.
해결을 적용하는 동안 다른 충돌이 검출될 수 있다. 이 경우, 새로운 충돌은 원래의 처리를 재개하기 전에 해결되어야 한다.
충돌을 항목의 버젼 이력에서 분기로서 간주할 때, 충돌 해결은 2개의 분기를 단일 포인트를 형성하도록 결합한 연결로서 보여질 수 있다. 따라서, 충돌 해 결은 버젼 이력을 DAG로 바꾼다.
(b) 충돌 로깅
충돌 해결자의 매우 특이한 한 종류는 충돌 로거이다. 동기화 서비스는 충돌을 타입 ConflictRecord의 항목으로서 로그한다. 이 레코드는 충돌하고 있는 항목들과 다시 관련된다(항목들 자체가 삭제되지 않은 경우). 각 충돌 레코드는 충돌을 유발하는 들어오는 변경, 충돌의 타입, 즉 갱신-갱신, 갱신-삭제, 삭제-갱신, 삽입-삽입, 또는 제한, 및 들어오는 변경의 버젼 및 이를 전송하는 사본에 대한 지식을 포함한다. 로그된 충돌들은 후술하는 바와 같이 검사 및 해결에 이용될 수 있다.
(c) 충돌 검사 및 해결
동기화 서비스는 충돌 로그를 검사하고 그 안에 충돌의 해결을 제안하기 위해 애플리케이션에 대한 API를 제공한다. API는 애플리케이션이 모든 충돌, 또는 주어진 항목에 관한 충돌을 열거하는 것을 허용한다. API는 또한 이러한 애플리케이션이 세가지 방법, 즉 (1) 로그된 변경을 수용하고 충돌하는 로컬 변경을 덮어쓰는 원격 윈, (2) 로그된 변경의 충돌하는 부분을 무시하는 로컬 윈, 및 (3) 애플리케이션이 그의 의견에서 충돌을 해결하는 병합을 제안하는 새로운 변경 제안 중 하나로 로그된 충돌을 해결하는 것을 허용한다. 애플리케이션에 의해 충돌이 해결되면, 동기화 서비스는 로그로부터 제거된다.
(d) 사본의 수렴 및 충돌 해결의 전파
복잡한 동기화 시나리오에서, 동일한 충돌이 다수의 사본에서 검출될 수 있다. 이것이 발생할 경우, 여러 가지가 발생할 수 있는데, 즉 (1) 충돌이 하나의 사본에서 해결되고, 이 해결이 다른 사본으로 전송되거나, (2) 충돌이 양 사본에서 자동으로 해결되거나, (3) 충돌이 양 사본에서 수동으로(충돌 검사 API를 통해) 해결될 수 있다.
수렴을 보장하기 위해, 동기화 서비스는 충돌 해결을 다른 사본으로 전송한다. 충돌을 해결하는 변경이 사본에 도달할 때, 동기화 서비스는 로그에서 이 갱신에 의해 해결되는 임의의 충돌 레코드들을 찾아 이들을 제거한다. 이러한 의미에서, 하나의 사본에서의 충돌 해결은 모든 다른 사본에 결합된다.
동일 충돌에 대해 상이한 사본들에 의해 상이한 위너들이 선택되는 경우, 동기화 서비스는 충돌 해결을 결합하는 원리를 적용하여 2개의 해결 중 하나를 나머지에 대해 자동으로 승리하도록 선택한다. 위너는 항상 동일한 결과를 생성하는 것을 보장하는 결정론적 방식으로 선택된다(일 실시예는 사본 ID 사전 편집 비교를 이용한다).
동일 충돌에 대해 상이한 사본들에 의해 상이한 "새로운 변경들"이 제안되는 경우, 동기화 서비스는 이 새로운 충돌을 특수 충돌로서 취급하고, 충돌 로거를 이용하여 이 새로운 충돌이 다른 사본들로 전파되는 것을 방지한다. 이러한 상황은 일반적으로 수동 충돌 해결에서 발생한다.
2. 비저장 플랫폼 데이터 저장소에 대한 동기화
본 발명의 저장 플랫폼의 다른 양태에 따르면, 저장 플랫폼은 저장 플랫폼이 마이크로소프트 익스체인지, AD, 핫메일 등과 같은 레거시 시스템에 동기화하는 것을 허용하는 동기화 어댑터를 구현하기 위해 ISV에 대한 아키텍처를 제공한다. 동기 어댑터는 후술하는 바와 같이 동기화 서비스에 의해 제공되는 많은 동기화 서비스로부터 이익을 얻는다.
그 명칭에도 불구하고, 동기화 어댑터는 소정의 저장 플랫폼 아키텍처 내로의 플러그-인으로서 구현될 필요는 없다. 원할 경우, "동기 어댑터"는 단지 동기화 서비스 실행시간 인터페이스를 이용하여 변경 열거 및 적용과 같은 서비스를 얻는 임의의 애플리케이션일 수 있다.
다른 것들이 주어진 백엔드에 대한 동기화를 구성하고 실행하는 것을 보다 간단하게 하기 위해, 동기 어댑터 작성자는 전술한 바와 같이 동기화 프로파일이 주어질 때 동기화를 실행하는 표준 동기화 어댑터 인터페이스를 노출시키도록 권장된다. 프로파일은 구성 정보를 어댑터에 제공하며, 어댑터는 그 중 일부를 실행 시간에 전달하여 실행시간 서비스(예컨대, 폴더 동기화)를 제어한다.
a) 동기화 서비스
동기화 서비스는 다수의 동기화 서비스를 어댑터 작성자에게 제공한다. 이 섹션의 나머지에서는 저장 플랫폼이 동기화를 행하고 있는 기계를 "클라이언트"로, 어댑터가 대화하고 있는 비저장 플랫폼 백엔드를 "서버"로 지칭하는 것이 편리하다.
(1) 변경 열거
동기화 서비스에 의해 유지되는 변경 추적 데이터에 기초하여, 변경 열거는 동기 어댑터가 데이터 저장소 폴더에 대해 이 파트너와의 지난번 동기화가 시도된 후에 발생한 변경들을 쉽게 열거하는 것을 허용한다.
변경들은 최종 동기화에 대한 정보를 표현하는 불투명 구조인 "앵커"의 개념에 기초하여 열거된다. 앵커는 이전 섹션에서 설명한 바와 같이 저장 플랫폼 지식의 형태를 갖는다. 변경 열거 서비스를 이용하는 동기 어댑터들은 2개의 넓은 카테고리, 즉 "저장된 앵커"를 사용하는 어댑터들 및 "제공된 앵커"를 사용하는 어댑터들로 분류된다.
그 차이는 최종 동기화에 대한 정보가 클라이언트에 저장되는지, 또는 서버에 저장되는지에 기초한다. 종종, 어댑터가 클라이언트 상에 이 정보를 저장하는 것이 더 쉬우며, 백엔드는 종종 이 정보를 편리하게 저장할 수 없다. 한편, 다수의 클라이언트가 동일한 백엔드에 동기화할 경우, 클라이언트 상에 이 정보를 저장하는 것은 비효율적이며, 몇몇 경우에는 옳지 않은데, 이는 하나의 클라이언트가 다른 클라이언트가 이미 서버에게로 푸시한 변경을 알지 못하게 한다. 어댑터가 서버에 저장된 앵커를 사용하기를 원하는 경우, 어댑터는 이 앵커를 변경 열거시에 저장 플랫폼에 제공할 필요가 있다.
저장 플랫폼이 앵커를 (로컬 또는 원격 저장소에 대해) 유지하기 위하여, 저 장 플랫폼은 서버에서 성공적으로 적용된 변경들을 알 필요가 있다. 이 변경들만이 앵커에 포함될 수 있다. 변경 열거 동안, 동기화 어댑터는 어느 변경들이 성공적으로 적용되었는지를 보고하기 위해 확인 인터페이스를 사용한다. 동기화의 종료시, 제공된 앵커를 사용하는 어댑터들은 새로운 앵커(성공적으로 적용된 변경들 모두를 포함함)를 판독하여 이를 그들의 백엔드로 전송해야 한다.
종종, 어댑터들은 이들이 저장 플랫폼 데이터 저장소에 삽입하는 항목들과 함께 어댑터 특정 데이터를 저장할 필요가 있다. 이러한 데이터의 일반 예는 원격 ID 및 원격 버젼(타임 스탬프)이다. 동기화 서비스는 이러한 데이터를 저장하기 위한 메카니즘을 제공하며, 변경 열거는 이러한 여분의 데이터를 리턴되는 변경과 함께 수신하기 위한 메카니즘을 제공한다. 이것은 대부분의 경우에 어댑터들이 데이터베이스에 재질의할 필요를 없앤다.
(2) 변경 적용
변경 적용은 동기화 어댑터들이 그들의 백엔드로부터 수신되는 변경들을 로컬 저장 플랫폼에 적용하는 것을 허용한다. 어댑터들은 변경들을 저장 플랫폼 스키마로 변환할 것으로 예상된다. 도 24는 저장 플랫폼 API 클래스들이 저장 플랫폼 스키마로부터 생성되는 프로세스를 나타낸다.
변경 적용의 주요 기능은 충돌을 자동으로 검출하는 것이다. 저장 플랫폼-저장 플랫폼 동기화의 경우에서와 같이, 충돌은 2개의 중복 변경이 서로에 대한 지식 없이 행해지는 것으로서 정의된다. 어댑터들이 변경 적용을 이용할 때, 이들은 충돌 검출 수행과 관련될 앵커를 지정해야 한다. 변경 적용은 어댑터의 지식에 의해 커버되지 않는 중복 로컬 변경이 검출되는 경우에 충돌을 발생시킨다. 변경 열거와 유사하게, 어댑터들은 저장 또는 제공된 앵커를 사용할 수 있다. 변경 적용은 어댑터 특정 메타데이터의 효율적인 저장을 지원한다. 이러한 데이터는 어댑터에 의해 적용되고 있는 변경들에 첨부될 수 있으며, 동기화 서비스에 의해 저장될 수 있다. 데이터는 다음 변경 열거시에 리턴될 수 있다.
(3) 충돌 해결
전술한 충돌 해결 메카니즘(로깅 및 자동 해결 옵션)은 또한 동기화 어댑터들이 이용할 수 있다. 동기화 어댑터들은 변경을 적용할 때 충돌 해결을 위한 정책을 지정할 수 있다. 지정된 경우, 충돌들은 지정된 충돌 처리자로 전달되어 (가능한 경우) 해결될 수 있다. 충돌들은 또한 로그될 수 있다. 어댑터는 로컬 변경을 백엔드에 적용하려고 시도할 때 충돌을 검출할 수 있다. 이 경우, 어댑터는 여전히 정책에 따라 해결되도록 동기화 실행시간에 충돌을 전달할 수 있다. 또한, 동기화 어댑터들은 동기화 서비스에 의해 검출된 임의의 충돌들이 처리를 위해 그들에게 전송될 것을 요구할 수 있다. 이것은 특히 백엔드가 충돌을 저장하거나 해결할 수 있는 경우에 편리하다.
b) 어댑터 구현
몇몇 어댑터들은 단지 실행시간 인터페이스를 이용하는 애플리케이션이지만, 어댑터들은 표준 어댑터 인터페이스를 구현하도록 권장된다. 이들 인터페이스는 동기화 제어 애플리케이션들이 어댑터가 주어진 동기화 프로파일에 따라 동기화를 수행할 것을 요구하고, 진행중인 동기화를 취소하고, 진행중인 동기화에 대한 진행 보고를 수신하는 것을 허용한다.
3. 보안
동기화 서비스는 저장 플랫폼에 의해 구현되는 보안 모델에 가능한 적게 도입하려고 노력한다. 동기화에 대한 새로운 권리를 정의하기보다는 기존 권리를 사용한다. 구체적으로는 다음과 같다.
- 데이터 저장소 항목을 판독할 수 있는 누구라도 그 항목에 대한 변경을 열거할 수 있다.
- 데이터 저장소 항목에 기입할 수 있는 누구라도 그 항목에 변경을 적용할 있다.
- 데이터 저장소 항목을 확장할 수 있는 누구라도 동기화 메타데이터를 그 항목과 연관시킬 수 있다.
동기화 서비스는 보안 저자 정보를 유지하지 않는다. 사용자 U에 의해 사본 A에 변경이 행해져 사본 B로 전송될 때, 변경이 A에서(또는 U에 의해) 최초로 이루어졌다는 사실은 없어진다. B가 이 변경을 사본 C로 전송하는 경우, 이것은 A의 권한이 아니라 B의 권한 하에 이루어진다. 이것은 다음과 같은 제한을 유발하는데, 즉 사본이 항목에 대해 그 자신의 변경을 만들 권한이 없는 경우, 이 사본은 다른 사본들에 의해 만들어진 변경을 전송할 수 없다.
동기화 서비스가 개시될 때, 이것은 동기화 제어 애플리케이션에 의해 행해진다. 동기화 서비스는 SCA의 식별자를 의인화하며, 이 식별자 하에 모든 동작(로컬 및 원격 양자)을 수행한다. 예를 들어, 사용자 U는 로컬 동기화 서비스가 사용자 U가 판독 액세스하지 않은 항목들에 대해 원격 저장 플랫폼으로부터 변경을 검색하게 할 수 없다는 점에 유의한다.
4. 관리성
사본들의 분산 공동체의 모니터링은 복잡한 문제이다. 동기화 서비스는 사본들의 상태에 대한 정보를 수집하고 분배하기 위해 "스위프" 알고리즘을 사용할 수 있다. 스위프 알고리즘의 속성들은 구성된 모든 사본들에 대한 정보가 결국 수집되고, 실패(무응답) 사본들이 검출되는 것을 보장한다.
이러한 공동체 전체 모니터링 정보는 모든 사본에서 이용 가능하게 된다. 모니터링 도구는 임의의 선택된 사본에서 실행되어 이 모니터링 정보를 검사하고 관리적 결정을 행할 수 있다. 영향을 받은 사본들에서 직접 임의의 구성 변경이 행해져야 한다.
B. 동기화 API 개요
점차 분산되는 디지털 세계에서, 개인 및 작업 그룹은 종종 다양한 상이한 장치 및 위치에 정보 및 데이터를 저장한다. 이것은 분리되고, 종종 상이하고, 항 상 동기화되는 데이터 저장소들에 정보를 최소한의 사용자 중재로 유지할 수 있는 데이터 동기화 서비스의 개발을 지원해왔다.
본 명세서의 섹션 II에 설명된 풍부한 저장 플랫폼(a.k.a, "WinFS)의 일부인 본 발명의 동기화 플랫폼은 다음의 3가지 주요 대상을 다룬다.
- 애플리케이션 및 서비스가 상이한 "WinFS" 저장소들 사이에서 데이터를 동기화하는 것을 허용한다.
- 개발자들이 "WinFS" 및 non-"WinFS" 저장소들 사이에서 데이터를 동기화하기 위한 풍부한 솔루션을 구축하는 것을 가능하게 한다.
- 개발자들에게 동기화 사용자 경험을 주문화하기 위한 적절한 인터페이스를 제공한다.
1. 일반 용어법
후술하는 섹션 III.B의 설명에 관한 보다 세련된 몇몇 정의 및 주요 개념은 다음과 같다.
동기화 사본: 대부분의 애플리케이션은 WinFS 저장소 내의 항목들의 소정의 서브세트에 대한 변경을 추적, 열거 및 동기화하는 데에만 관련이 있다. 동기화 동작에 참여하는 항목들의 세트는 동기화 사본이라 한다. 사본은 주어진 WinFS 포함 계층 구조(대개 폴더 항목을 루트로 함) 내에 포함된 항목들로 정의된다. 모든 동기화 서비스는 주어진 사본과 관련하여 수행된다. WinFS 동기화는 사본들을 정의, 관리 및 제거하는 메카니즘을 제공한다. 모든 사본은 주어진 WinFS 저장소 내 에서 자신을 고유하게 식별하는 GUID 식별자를 갖는다.
동기화 파트너: 동기화 파트너는 WinFS 항목, 확장 및 관계 상에서 변경에 영향을 줄 수 있는 엔티티로서 정의된다. 따라서, 모든 WinFS 저장소는 동기 파트너라고 할 수 있다. non-WinFS 저장소와 동기화될 때, 외부 데이터 저장소(EDS)도 동기 파트너라고 할 수 있다. 모든 파트너는 자신을 고유하게 식별하는 GUID 식별자를 갖는다.
동기화 공동체: 동기화 공동체는 피어 대 피어 동기화 동작에 의한 동기화시에 유지되는 사본들의 집합으로서 정의된다. 이들 사본은 모두 동일한 WinFS 저장소, 상이한 WinFS 저장소, 또는 심지어 non-WinFS 저장소 상의 가상 사본들인 목록 자체에 있을 수 있다. WinFS 동기화는, 특히 공동체 내의 동기화 동작들만이 WinFS 동기화 서비스(WinFS 어댑터)를 통하는 경우에는 공동체에 대한 임의의 특정 토폴로지를 규정하거나 지정하지 않는다. 동기화 어댑터들(아래에 정의됨)은 그들 자신의 토폴로지 제한을 도입할 수 있다.
변경 추적, 변경 단위 및 버젼: 모든 WinFS 저장소는 모든 로컬 WinFS 항목, 확장 및 관계에 대한 변경을 추적한다. 변경은 스키마에 정의된 변경 단위 입도의 레벨에서 추적된다. 임의의 항목, 확장 및 관계 타입의 최상위 레벨 필드들은 스키마 설계자에 의해 변경 단위로 세분될 수 있는데, 최소 입도가 하나의 최상위 레벨 필드가 된다. 변경 추적을 위해, 모든 변경 단위에는 버젼이 할당되며, 버젼은 동기화 파트너 id 및 버젼 번호의 쌍이다(버젼 번호는 파트너 특정 단조 증가 번호이다). 버젼들은 변경이 저장소에서 로컬하게 발생하거나 변경이 다른 사본으로부 터 얻어질 때 갱신된다.
동기화 지식: 지식은 임의의 시간에 주어진 동기화 사본의 상태를 나타내는데, 즉 주어진 사본이 로컬하게 또는 다른 사본들로부터 인식하는 모든 변경에 대한 메타데이터를 캡슐화한다. WinFS 동기화는 동기화 동작들에서 동기화 사본들에 대한 지식을 유지하고 갱신한다. 중요한 유의점은 지식 표현이 지식이 저장되어 있는 특정 사본에 대해서가 아니라 전체 공동체에 관하여 해석되는 것을 허용한다는 점이다.
동기화 어댑터: 동기화 어댑터는 동기화 실행시간 API를 통해 WinFS 동기화 서비스에 액세스하고 WinFS 데이터의 non-WinFS 데이터 저장소에 대한 동기화를 가능하게 하는 관리형 코드 애플리케이션이다. 시나리오의 요건에 따라, WinFS 데이터의 어느 서브세트가, 그리고 어떤 WinFS 데이터 타입들이 동기화되어야 하는지에 관해서는 어댑터 개발자에게 맡겨진다. 어댑터는 EDS와의 통신, WinFS 스키마의 EDS 지원 스키마로의/로부터의 변환, 및 그 자신의 구성 및 메타데이터의 관리를 담당한다. 어댑터는 일반 구성을 이용하여 WinFS 동기화 팀에 의해 제공되는 어댑터들에 대한 기반 구조를 제어할 수 있게 WinFS 동기화 어댑터 API를 구현하도록 강하게 권장된다. 보다 상세한 것은 WinFS 동기화 어댑터 API[SADP] 사양 및 WinFS 동기화 제어기 API[SCTRL] 사양을 참조한다.
WinFS 데이터를 외부 non-WinFS 저장소에 동기화하고 WinFS 포맷의 지식을 생성하거나 유지할 수 없는 어댑터들에 대해, WinFS 동기화는 후속 변경 열거 또는 적용 동작에 사용될 수 있는 원격 지식을 얻기 위한 서비스를 제공한다. 백엔드 저장소의 능력에 따라, 어댑터는 원격 지식을 백엔드 상에 또는 로컬 WinFS 저장소 상에 저장하기를 원할 수 있다.
간략화를 위해, 동기화 "사본"은 단일 논리 위치에 존재하는 "WinFS" 저장소 내의 한 세트의 데이터를 표현하는 구조인 반면, non-"WinFS" 저장소 상의 데이터는 "데이터 소스"라고 하며, 일반적으로 어댑터의 사용을 필요로 한다.
원격 지식: 주어진 동기화 사본이 다른 사본으로부터 변경을 얻기를 원할 때, 이 사본은 그 자신의 지식을 다른 사본이 변경들을 열거하는 기준선으로서 제공한다. 마찬가지로, 주어진 사본이 다른 사본으로 변경을 전송하기를 원할 때, 이 사본은 그 자신의 지식을 충돌을 검출하기 위해 다른 사본에 의해 사용될 수 있는 기준선으로서 제공한다. 동기 변경 열거 및 적용 동안 제공되는 이러한 다른 사본에 대한 지식은 원격 지식이라 한다.
2. 동기화 API 원리
소정의 실시예에서, 동기화 API는 2개의 부분, 즉 동기화 구성 API 및 동기화 제어기 API로 분리된다. 동기화 구성 API는 애플리케이션이 동기화를 구성하고 2개의 사본 사이의 특정 동기화 세션에 대한 파라미터들을 지정할 수 있게 한다. 주어진 동기화 세션에 대해, 구성 파라미터들은 동기화될 항목들의 세트, 동기화의 타입(일방향 또는 양방향), 원격 데이터 저장소에 대한 정보 및 충돌 해결 정책을 포함한다. 동기화 제어기 API는 동기화 세션을 개시하고, 동기화를 취소하며, 진행중인 동기화에 대한 진행 및 에러 정보를 수신한다. 더욱이, 동기화가 미리 정 해진 스케쥴에 따라 수행될 필요가 있는 특정 실시예에서, 이러한 시스템은 스케쥴링을 주문화하기 위한 스케쥴링 메카니즘을 포함할 수 있다.
본 발명의 여러 실시예는 "WinFS" 및 non-"WinFS" 데이터 소스들 사이에서 정보를 동기화하기 위해 동기화 어댑터를 사용한다. 어댑터의 예는 "WinFS" 콘택 폴더 및 non-WinFS 메일박스 사이에서 어드레스 북 정보를 동기화하는 어댑터를 포함한다. 이 예에서, 어댑터 개발자는 "WinFS" 스키마와 non-"WinFS" 데이터 소스 스키마 사이의 스키마 변환 코드를 개발하기 위하여 "WinFS" 동기화 플랫폼에 의해 제공되는 서비스에 액세스하기 위하여 본 명세서에서 설명되는 "WinFS" 동기화 코어 서비스 API를 사용할 수 있다. 또한, 어댑터 개발자는 변경들을 non-WinFS 데이터 소스와 통신하기 위한 프로토콜 지원을 제공한다. 동기화 어댑터는 동기화 제어기 API를 사용하여 호출되고 제어되며, 이 API를 이용하여 진행 및 에러를 보고한다.
그러나, 본 발명의 소정 실시예에서, WinFS 데이터 저장소를 다른 WinFS 데이터 저장소에 동기화할 때, 동기화 어댑터는 WinFS 대 WinFS 동기화 서비스가 하드웨어/소프트웨어 인터페이스 시스템 내에 통합되는 경우 필요하지 않을 수 있다. 어느 경우에나, 이러한 여러 실시예는 WinFS 대 WinFS 및 동기화 어댑터 솔루션들 양자에 대해 한 세트의 동기화 서비스를 제공하는데, 이는 다음을 포함한다.
- WinFS 항목, 확장 및 관계에 대한 변경의 추적
- 주어진 과거 상태 이후의 효율적인 증분식 변경 열거에 대한 지원
- WinFS에 대한 외부 변경의 적용
- 변경 적용 동안의 충돌 처리.
공통 데이터 저장소의 3개의 인스턴스 및 이들을 동기화하기 위한 컴포넌트들을 나타내는 도 36을 참조한다. 제1 시스템(3602)은 WinFS 대 WinFS 동기화 서비스(3622) 및 WinFS 대 non-WinFS 동기화를 위해 동기화 API(3652)를 사용할 수 있도록 노출시키는(3646) 코어 동기화 서비스(3624)를 포함하는 WinFS 데이터 저장소(3612)를 갖는다. 제1 시스템(3602)과 유사하게, 제2 시스템(3604)은 WinFS 대 WinFS 동기화 서비스(3632) 및 WinFS 대 non-WinFS 동기화를 위해 동기 API(3652)를 이용할 수 있도록 노출시키는(3646) 코어 동기화 서비스(3634)를 포함하는 WinFS 데이터 저장소(3614)를 갖는다. 제1 시스템(3602) 및 제2 시스템(3604)은 그들 각각의 WinFS 대 WinFS 동기화 서비스(3622, 3632)를 통해 동기화된다(3642). WinFS 시스템이 아닌 제3 시스템(3606)은 WinFS 사본들을 가진 동기화 공동체 내에 데이터 소스를 유지하기 위해 WinFS 동기화를 이용하는 애플리케이션(3666)을 갖는다. 이 애플리케이션은 WinFS 대 WinFS 동기화 서비스(3622)(이것이 그 자체를 WinFS 데이터 저장소로서 가상화할 수 있는 경우) 또는 동기화 API(3652)와 인터페이스하는 동기화 어댑터(3662)를 통해 WinFS 데이터 저장소(3612)와 직접 인터페이스하는(3644) WinFS 동기화 구성/제어 서비스(3664)를 이용할 수 있다.
이 도면에 도시된 바와 같이, 제1 시스템(3602)은 제2 시스템(3604) 및 제3 시스템(3606) 양자를 인식하고 직접 동기화된다. 그러나, 제2 시스템(3604) 및 제3 시스템(3606) 양자는 서로를 알지 못하며, 따라서 그들의 변경을 서로 직접 동기화하지 못하지만, 대신에 하나의 시스템에서 발생하는 변경은 제1 시스템(3602)을 통해 전파되어야 한다.
C. 동기화 API 서비스
본 발명의 여러 실시예는 2개의 기본 서비스, 즉 변경 열거 및 변경 적용을 포함하는 동기화 서비스와 관련된다.
1. 변경 열거
전술한 바와 같이, 변경 열거는 동기화 어댑터가 데이터 저장소 폴더에 대해 이 파트너와 최종 동기화가 시도된 이후 발생한 변경들을 동기화 서비스에 의해 유지되는 변경 추적 데이터에 기초하여 쉽게 열거하는 것을 허용한다. 변경 열거와 관련하여, 본 발명의 여러 실시예는 다음과 관련된다.
- 지정된 지식 인스턴스에 대해, 주어진 사본 내의 항목, 확장 및 관계에 대한 변경들의 효율적인 열거
- WinFS 스키마에 지정된 변경 단위 입도의 레벨에서의 변경들의 열거
- 복합 항목들에 관하여 열거된 변경들의 그룹화. 복합 항목은 항목, 모든 그의 확장, 항목에 대한 모든 유지 관계 및 그의 삽입 항목들에 대응하는 모든 복합 항목으로 구성된다. 항목들 사이의 참조 관계에 대한 변경은 개별적으로 열거된다.
- 변경 열거시의 배치화. 배치의 입도는 복합 항목 또는 관계 변경(참조 관계에 대해)이다.
- 변경 열거 동안 사본 내의 항목들에 대한 필터의 지정. 예를 들어, 사본 은 주어진 폴더 내의 모든 항목으로 구성되지만, 특정 변경 열거에 대해 애플리케이션은 첫 번째 명칭이 'A'로 시작되는 모든 콘택 항목들에 대한 변경만을 열거하기를 원한다(이러한 지원은 B 이정표 뒤에 추가된다).
- 열거된 변경들에 대한 원격 지식을, 지식 내에 동기화에 실패한 것으로 개별 변경 단위들(또는 전체 항목, 확장 또는 관계)을 기록할 수 있는 능력과 함께 이용하여, 이들이 다음 번에 다시 열거될 수 있도록 한다.
- 변경 열거 동안 변경들과 함께 메타데이터를 리턴함으로써 WinFS 동기화 메타데이터를 이해할 수 있는 향상된 어댑터의 이용
2. 변경 적용
전술한 바와 같이, 변경 적용은 동기 어댑터들이 그들의 백엔드로부터 수신한 변경들을 로컬 저장 플랫폼에 적용하는 것을 허용하는데, 이는 어댑터들이 변경을 저장 플랫폼 스키마로 변환할 것으로 예상되기 때문이다. 변경 적용과 관련하여, 본 발명의 여러 실시예는 다음과 관련된다.
- 대응하는 갱신들을 가진 다른 사본들(또는 non-WinFS 저장소)에서 WinFS 변경 메타데이터로의 증분식 변경의 적용
- 변경 단위 입도에서의 변경 적용시의 충돌의 검출
- 변경 적용시 개별 변경 단위 레벨에서의 성공, 실패 및 충돌의 보고. 이에 따라, 애플리케이션들(어댑터 및 동기화 제어 애플리케이션 포함)은 이 정보를 진행, 에러 및 상태 보고를 위해, 그리고 만일 있다면 그들의 백엔드 상태를 갱신 하기 위해 사용할 수 있다.
- 다음 변경 열거 동작 동안 애플리케이션 제공 변경들의 "반사"를 방지하기 위한 변경 적용 동안의 원격 지식의 갱신
- 변경들과 함께 WinFS 동기화 메타데이터를 이해하고 제공할 수 있는 향상된 어댑터의 이용.
3. 샘플 코드
다음은 FOO 동기화 어댑터가 어떻게 동기화 실행시간과 상호작용하는지에 대한 코드 샘플이다(여기서, 모든 어댑터 특정 함수들 앞에는 FOO가 첨부된다):
4. API 동기화의 방법
본 발명의 일 실시예에서, WinFS 저장소와 non-WinFS 저장소 사이의 동기화는 WinFS 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 노출되는 동기화 API를 통해 달성될 수 있다.
일 실시예에서, 모든 동기화 어댑터는 이들이 일관되게 전개, 초기화 및 제 어될 수 있도록 동기화 어댑터 API, 공통 언어 실행시간(CLR) 관리형 API를 구현하도록 요구된다. 어댑터 API는 다음을 제공한다.
- 어댑터를 하드웨어/소프트웨어 인터페이스 시스템 동기화 프레임워크에 등록하기 위한 표준 메카니즘
- 어댑터들이 그들의 능력 및 어댑터를 초기화하는 데 필요한 구성 정보의 타입을 선언할 수 있는 표준 메카니즘
- 초기화 정보를 어댑터에 전달하기 위한 표준 메카니즘
- 어댑터들이 동기화를 호출하는 애플리케이션으로 진행 상태를 보고하기 위한 메카니즘
- 동기화 동안 발생하는 임의의 에러를 보고하기 위한 메카니즘
- 진행중인 동기화 동작의 최소를 요구하기 위한 메카니즘
시나리오의 요건에 따라 어댑터에 대한 2가지 잠재적인 프로세스 모델이 있다. 어댑터는 그를 호출하는 애플리케이션과 동일한 프로세스 공간에서 또는 개별 프로세스에서 단독으로 실행될 수 있다. 그 자신의 개별 프로세스에서 실행되기 위해, 어댑터는 자신을 인스턴스화하는 데 사용되는 그 자신의 팩토리 클래스를 정의한다. 팩토리는 호출 애플리케이션과 동일한 프로세스에서 어댑터의 인스턴스를 리턴하거나, 다른 마이크로소프트 공통 언어 실행시간 애플리케이션 도메인 또는 프로세스에서 어댑터의 원격 인스턴스를 리턴할 수 있다. 동일 프로세스에서 어댑터를 인스턴스화하는 디폴트 팩토리 구현이 제공된다. 실제로, 많은 어댑터는 호출 애플리케이션과 동일한 프로세스에서 실행된다. 프로세스 모델의 아웃은 대개 다음 이유 중 하나 또는 두가지 이유로 필요하다.
- 보안 목적. 어댑터는 소정의 프로세스 또는 서비스의 프로세스 공간에서 실행되어야 한다.
- 어댑터는 호출 애플리케이션으로부터의 요구를 처리하는 것에 더하여 다른 소스로부터의 요구, 예를 들어 들어오는 네트워크 요구를 처리해야 한다.
도 37을 참조하면, 본 발명의 일 실시예는 상태가 어떻게 계산되는지, 또는 그와 관련된 메타데이터가 어떻게 교환되는지를 알지 못하는 단순한 어댑터를 가정한다. 이 실시예에서, 동기화는 사본에 의해, 이 사본이 동기화하기를 원하는 데이터 소스와 관련하여, 먼저 단계 3702에서 사본이 상기 데이터 소스와 최종 동기화된 후 어떠한 변경이 발생했는지를 검출함으로써 달성되며, 이후 사본은 최종 동기화 이후에 발생한 증분식 변경을 그의 현재 상태 정보에 기초하여 전송하며, 이 현재 상태 정보 및 증분식 변경은 어댑터를 통해 데이터 소스로 전송된다. 단계 3704에서, 어댑터는 이전 단계에서 사본으로부터 변경 데이터를 수신한 때 가능한 한 데이터 소스에 대한 많은 변경을 행하고, 어느 변경이 성공적이고 어느 변경이 실패했는지를 추적하며, 성공 및 실패 정보를 (사본의) WinFS로 전송한다. 사본의 하드웨어/소프트웨어 인터페이스 시스템(WinFS)은 단계 3706에서, 사본으로부터 성공 및 실패 정보를 수신한 후 데이터 소스에 대한 새로운 상태 정보를 계산하고, 이 정보를 그의 사본에 의한 미래의 사용을 위해 저장하며, 이 새로운 상태 정보를 데이터 소스로, 즉 어댑터에 의한 저장 및 후속 사용을 위해 어댑터로 전송한다.
D. 동기화 스키마의 추가 양태
다음은 본 발명의 다양한 실시예에서 동기화 스키마의 추가(또는 보다 특정한) 양태들이다.
- 각각의 사본은 데이터 저장소의 전체로부터 정의된 데이터의 동기화 서브세트, 즉 다수의 인스턴스를 가진 데이터 슬라이스이다.
- 충돌 해결 정책은 각각의 사본(및 어댑터/데이터 소스 조합)에 의해 개별적으로 처리되는데, 즉 각각의 사본은 그 자신의 기준 및 충돌 해결 스키마에 기초하여 충돌을 해결할 수 있다. 더욱이, 데이터 저장소의 각각의 인스턴스의 차이가 발생하여 추가적인 미래의 충돌을 유발할 수 있지만, 갱신된 상태 정보에 반영된 바와 같은 충돌들의 증분식 및 순차 열거는 갱신 상태 정보를 수신하는 다른 사본들에게는 보이지 않는다.
- 동기화 스키마의 루트에는 고유 ID를 갖는 루트 폴더(사실상 루트 항목)를 정의하는 기본 타입, 회원으로 있는 동기화 공동체에 대한 ID, 및 특정 사본에 대해 필요하거나 바람직한 모든 필터 및 다른 요소를 구비한 사본이 존재한다.
- 각각의 사본의 맵핑은 사본 내에 유지되며, 이에 따라 임의의 특정 사본에 대한 맵핑은 이 사본이 알지 못하는 다른 사본들로 제한된다. 이러한 맵핑은 전체 동기화 공동체의 서브세트만을 포함할 수 있지만, 상기 사본에 대한 변경은 여전히 공유 사본들을 통해 (임의의 특정 사본은 알지 못하는 사본과 어떤 다른 사본들을 공유하고 있는지를 알지 못하지만) 전체 동기화 공동체로 전파된다.
- 동기화 스키마는 모든 사본들이 이용할 수 있는 미리 정의된 복수의 충돌 처리자는 물론, 사용자/개발자 정의 고객 충돌 처리자의 능력을 포함한다. 스키마는 또한 3개의 특수 "충돌 해결자", 즉 (a) 예컨대 (i) 두 곳에서 동일한 변경 단위가 변경된 때 처리하는 방법, (ii) 변경 단위가 한 곳에서는 변경되었지만 다른 곳에서는 삭제된 때 처리하는 방법, 및 (iii) 2개의 상이한 변경 단위가 두 다른 곳에서 동일 명칭을 가질 때 처리하는 방법에 기초하여 상이한 방식으로 상이한 충돌을 해결하는 충돌 "필터", (b) 충돌 "해결자 리스트"-이 리스트의 각 요소는 충돌이 성공적으로 해결될 때까지 순차적으로 시도될 일련의 동작을 지정한다-, 및 (c) 충돌을 추적하지만 사용자의 중재 없이는 더 이상의 동작을 취하지 않는 "무동작(do-nothing)" 로그를 포함할 수 있다.
- 사본들의 동기화 스키마 및 사용은 진정한 분산형 피어 대 피어 멀티 마스터 동기화 공동체를 가능하게 한다. 더욱이, 동기화 공동체 타입을 존재하지 않지만, 동기화 공동체는 단지 사본들 자체의 공동체 필드 내의 값으로서 존재한다.
- 모든 사본은 증분식 변경 열거를 추적하고 동기화 공동체 내에 공지된 다른 사본들에 대한 상태 정보를 저장하기 위한 그 자신의 메타데이터를 갖는다.
- 변경 단위들은 파트너 키 플러스 파트너 변경 번호를 포함하는 버젼; 각각의 변경 단위에 대한 항목/확장/관계 버젼; 사본이 동기화 공동체로부터 보거나 수신한 변경에 관한 지식; GUID 및 로컬 ID 구성; 및 삭제를 위해 참조 관계 상에 저장된 GUID를 포함하는 그들 자신의 메타데이터를 갖는다.
E. 동기화 계층 구조
전술한 바와 같이, 각각의 사본(및 데이터 소스 및/또는 어댑터)은 그의 변경들의 증분식 및 순차적 열거를 유지하는데, 이러한 변경 각각에는 대응하는 증분식 및 순차적 변경 번호가 할당된다(즉, 제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로 서로 관련시킴으 로써 문제가 완전히 방지될 수 있도록 변경들을 재순서화하는 것이다.
IV. 결론
전술한 바와 같이, 본 발명은 데이터의 체계화, 검색 및 공유를 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 기존의 파일 시스템 및 데이터베이스 시스템을 넘어 데이터 저장의 개념을 확장하고 넓히며, 구조화되거나, 구조화되지 않거나, 관계형(테이블) 데이터와 같은 반 구조화된 데이터, XML 및 항목이라고 하는 새로운 형태의 데이터를 포함하는 모든 타입의 데이터에 대한 저장소가 되도록 설계된다. 본 발명의 저장 플랫폼은 그의 일반 저장 기초 및 스키마화된 데이터를 통해 소비자들, 지식 노동자들 및 기업들을 위해 보다 효율적인 애플리케이션 개발을 가능하게 한다. 저장 플랫폼은 그의 데이터 모델에 고유한 능력을 이용할 수 있게 할 뿐만 아니라 기존 파일 시스템 및 데이터베이스 액세스 방법을 수용하고 확장하는 풍부하고 확장 가능한 애플리케이션 프로그래밍 인터페이스를 제공한다. 본 발명의 넓은 발명적 개념을 벗어나지 않고 전술한 실시예들에 대한 변경이 이루어질 수 있다는 것을 이해해야 한다. 따라서, 본 발명은 개시된 특정 실시예들로 제한되는 것이 아니라, 첨부된 청구범위에 의해 정의되는 발명의 사상 및 범위 내에 있는 모든 수정을 커버하는 것으로 의도된다.
위의 설명으로부터 명백하듯이, 본 발명의 다양한 시스템, 방법 및 양태의 모두 또는 일부는 프로그램 코드(즉, 명령)의 형태로 구현될 수 있다. 이 프로그램 코드는, 제한 없이 플로피 디스켓, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, 자기 테 이프, 플래시 메모리, 하드 디스크 드라이브를 포함하는 자기, 전기 또는 광학 저장 매체와 같은 컴퓨터 판독 가능 매체 또는 임의의 다른 기계 판독 가능 저장 매체에 저장될 수 있으며, 프로그램 코드가 컴퓨터 또는 서버와 같은 기계에 로딩되어 실행될 때, 기계는 본 발명을 실시하는 장치가 된다. 본 발명은 또한 전기 배선 또는 유선, 광섬유, 인터넷 또는 인트라넷을 포함하는 네트워크, 또는 임의의 다른 전송 형태 등의 소정의 전송 매체를 통해 전송되는 프로그램 코드의 형태로 구현될 수 있으며, 프로그램 코드가 컴퓨터와 같은 기계에 의해 수신되고 로딩되어 실행될 때, 기계는 본 발명을 실시하는 장치가 된다. 프로그램 코드는 범용 프로세서에서 구현될 때, 프로세서와 결합하여 특정 논리 회로와 유사하게 동작하는 고유한 장치를 제공한다.
Claims (30)
- 데이터 플랫폼에 대한 복수 개의 인스턴스들을 동기화하기 위한 스토리지 플랫폼을 제공하는 컴퓨터 시스템에 있어서,데이터베이스 엔진;데이터를 저장하기 위해 상기 데이터베이스 엔진에 구현되는 데이터 스토어(data store) - 상기 데이터 스토어는 데이터 모델을 구현하고, 상기 데이터 스토어에 저장된 데이터의 조직, 검색, 공유, 동기화 및 보안을 지원하고, 데이터의 구체적인 유형이 스키마들(schemas)에 기재되고, 상기 스토리지 플랫폼은 새로운 유형의 데이터를 정의하기 위해 상기 스키마들을 확장하는 매커니즘을 제공하고, 상기 데이터 스토어는 애플리케이션 프로그램에 의해 이루어지는 데이터에 대한 변경을 추적하도록 구성됨 -;애플리케이션 프로그램들이 상기 스토리지 플랫폼의 서비스들 및 기능들(capabilities)을 모두 액세스하는 것과 상기 스키마들에 기재된 데이터에 액세스하는 것을 가능하게 하고 특정 데이터에 대한 변경들을 나타내는 통지들(notifications)에 대해 특정 애플리케이션 프로그램들을 등록하기 위하여 추적하도록 구성된 애플리케이션 프로그래밍 인터페이스; 및상이한 유형의 항목들, 요소들(elements) 및 관계들(relationships)을 정의하는 한 세트의 스키마들을 포함하고,상기 애플리케이션 프로그래밍 인터페이스는, 상기 한 세트의 스키마들에 정의된 상기 상이한 유형의 항목들, 요소들 및 관계들의 각각에 대한 클레스를 포함하고, 상기 스토리지 플랫폼은 기존 파일 시스템들(existing file systems)과의 상호 운용성(interoperability)을 지원하고 사용자들 및 시스템들이 상기 데이터 스토어의 서로 다른 인스턴스들에 저장된 데이터를 동기화(synchronize)하는 것이 가능하도록 하며, 상기 데이터 스토어에서의 데이터는 항목들, 요소들 및 관계들로 정의되고, 각 항목은 상기 데이터 스토어에 저장가능한 데이터의 단위이고 하나 이상의 요소들을 포함하며, 상기 요소는 하나 이상의 필드를 포함하는 유형의 인스턴스이고, 상기 관계는 적어도 두 개의 항목들 간의 링크인, 스토리지 플랫폼을 제공하는 컴퓨터 시스템.
- 제1항에 있어서,데이터는 기존 항목 유형에 대한 확장자(extension)의 형태로 상기 데이터 스토어에 저장되고, 상기 애플리케이션 프로그래밍 인터페이스는 각각의 서로 다른 항목 확장자에 대한 클래스를 포함하는, 스토리지 플랫폼을 제공하는 컴퓨터 시스템.
- 제1항에 있어서,상기 항목, 요소 및 관계의 각 유형에 대한 클래스는 항목, 요소 및 관계의 각 유형을 정의하는 상기 한 세트의 스키마들에 기초하여 자동 생성되는, 스토리지 플랫폼을 제공하는 컴퓨터 시스템.
- 제1항에 있어서,상기 항목, 요소 및 관계의 각 유형에 대한 클래스들은 한 세트의 데이터 클래스들을 정의하고, 상기 애플리케이션 프로그래밍 인터페이스는 상기 데이터 클레스들에 대한 공통의 행동(behavior) 세트를 정의하는 제2 클레스 세트를 더 포함하는, 스토리지 플랫폼을 제공하는 컴퓨터 시스템.
- 제1항에 있어서,상기 데이터 스토어에서의 상이한 유형의 항목들, 요소들 및 관계들은 상기 데이터베이스 엔진에서 사용자 정의 유형(user-defined type: UDT)으로서 구현되는, 스토리지 플랫폼을 제공하는 컴퓨터 시스템.
- 제1항에 있어서,두 개의 항목간의 상기 관계는 하드웨어 또는 소프트웨어 인터페이스 시스템에 의해 자동적으로 성립되는, 스토리지 플랫폼을 제공하는 컴퓨터 시스템.
- 제1항에 있어서,상기 한 세트의 스키마들은 코어 스키마(Core Schema)를 포함하고, 상기 코어 스키마는 그에 의해 상기 스토리지 플랫폼이 인식하고 미리 결정된 방식으로 직접적으로 처리하는 한 세트의 코어 항목들(Core Items)을 정의하는, 스토리지 플랫폼을 제공하는 컴퓨터 시스템.
- 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법으로서,데이터 플랫폼의 제1 인스턴스에서 복수개의 항목을 저장하는 단계 - 상기 제1 인스턴스에 저장된 각 항목은 적어도 하나의 변경 유닛을 포함하고, 상기 데이터 플랫폼은 변경 유닛에 대한 변경을 추적하도록 구성됨 -;상기 데이터 플랫폼의 상기 제1 인스턴스에 의해, 제1 항목의 제1 변경 유닛에 대한 변경을 저장하는 단계 - 상기 제1 항목은 부모 항목(parent item)의 자식(child)이며, 상기 제1 항목 및 상기 부모 항목은 상기 복수개의 항목들에 포함됨 -;상기 제1 항목의 상기 제1 변경 유닛에 대한 변경 이후에 상기 데이터 플랫폼의 상기 제1 인스턴스에 의해, 상기 부모(parent) 항목의 부모 변경 유닛에 대한 변경을 저장하는 단계;상기 데이터 플랫폼의 상기 제1 인스턴스에 의해, 각각 변경 번호에 의해 식별되는 변경 유닛에 대한 변경들을 순차적으로 고유 나열(uniquely enumerating)하는 단계;상기 데이터 플랫폼의 상기 제1 인스턴스에 의해 분리 벡터(separate vector)를 유지하는 단계 - 상기 분리 벡터는 상기 순차적으로 나열된 변경 및 상기 데이터 플랫폼의 제2 인스턴스의 가장 최근에 알려진 변경 번호에 대응하고, 상기 분리 벡터는 상기 데이터 플랫폼의 상기 제1 인스턴스에 대해 행해진 모든 변경들을 나타냄 -;상기 데이터 플랫폼의 상기 제2 인스턴스로부터 상기 데이터 플랫폼의 상기 제1 인스턴스에 의해 동기화 요구를 수신하는 단계 - 상기 동기화 요구는 상기 데이터 플랫폼의 상기 제2 인스턴스들과 연관된 제2 벡터를 포함함 -;상기 데이터 플랫폼의 상기 제1 인스턴스에 의해, 상기 데이터 플랫폼의 상기 제2 인스턴스가 상기 제2 벡터에 따른 상기 부모 항목의 상기 부모 변경 유닛에 대한 변경 및 상기 제1 항목의 상기 제1 변경 유닛에 대한 변경을 포함하지 않는지를 판단하는 단계; 및상기 데이터 플랫폼의 상기 제1 인스턴스에 의해, 상기 제1 항목의 상기 제1 변경 유닛에 대한 변경을 전송하기 전에, 상기 부모 항목의 상기 부모 변경 유닛에 대한 변경을 전송하는 단계를 포함하는 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법.
- 제8항에 있어서,상기 변경 번호는 고유 식별 번호 및 상대적 증분 카운트를 포함하는, 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법.
- 제8항에 있어서,상기 데이터 플랫폼의 상기 제1 인스턴스는, 상기 데이터 플랫폼의 상기 제2 인스턴스와 부분적으로 동기화하기 위해, 상기 데이터 플랫폼의 상기 제2 인스턴스에 그의 벡터를 발송함으로써 상기 데이터 플랫폼의 상기 제2 인스턴스로부터 변경들을 요청하고, 상기 데이터 플랫폼의 상기 제2 인스턴스는 상기 데이터 플랫폼의 상기 제1 인스턴스로부터 수신한 벡터에 기반하여 상기 제1 벡터가 아직 수신하지 않은 변경들만을 상기 데이터 플랫폼의 상기 제1 인스턴스로 발송하는, 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법.
- 제8항에 있어서,상기 데이터 플렛폼의 제1 인스턴스는, 제1 항목을 변경하여 관계(Relationship)를 통해 앞서 동기화되지 않았던 제2 항목에 관련되도록 할 때, 상기 데이터 플랫폼의 상기 제2 인스턴스로 상기 제2 항목에 관한 모든 변경 정보를 상기 데이터 플랫폼의 상기 제2 인스턴스와 동기화할 때 발송하는, 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법.
- 제8항에 있어서,제1 인스턴스에 의해 삭제된 항목에 대해, 상기 삭제된 항목의 식별자를 포함하는 툼스톤(tombstone)이 생성되고, 상기 툼스톤은 상기 데이터 플랫폼의 제2 인스턴스에서 삭제될 항목을 식별하도록 상기 데이터 플랫폼의 상기 제2 인스턴스에게 통지하기 위한 동기화의 일부로서 전송되는, 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법.
- 제8항에 있어서,상기 데이터 플랫폼의 제1 인스턴스의 제1 관계 및 제2 관계는, 임시 명칭 요소를 이용하여, 순서대로 (a) 상기 제1 관계의 명칭이 상기 임시 명칭 요소에 전달되고, (b) 상기 제2 관계의 명칭이 상기 제1 관계에 전달되고, (c) 상기 임시 명칭 요소에 저장된 상기 명칭이 상기 제2 관계로 복사되도록, 명칭을 스왑(swap)하고,상기 데이터 플랫폼의 상기 제1 인스턴스는, 상기 데이터 플랫폼의 제2 인스턴스와 동기되고, (i) 상기 제1 관계에 대한 새로운 명칭 및 (ii) 상기 제2 관계에 대한 새로운 명칭을 순서대로 나타내는 변경 유닛들의 듀오(duo)를 발송하고,변경들의 상기 듀오의 제1 변경을 실행하는 것은, 상기 제1 변경의 결과가 동일 명칭을 갖는 상기 제1 관계 및 상기 제2 관계를 위한 것임으로 인해, 시도된 변경이 상기 제2 인스턴스에 에러를 유발하는 결과를 가져오고,상기 방법은 상기 데이터 플랫폼의 상기 제2 인스턴스가 상기 제1 관계의 상기 명칭을 로컬 임시 명칭 요소로 복사하도록 하여,동기화 중에 상기 제2 관계의 상기 명칭을 상기 제1 관계로 복사하기 위한 후속 변경이 수신되는 경우, 상기 로컬 임시 명칭 요소에서의 상기 명칭을 상기 제1 관계로 복사하고 상기 변경을 실시하며,동기화 중에 상기 제2 관계의 상기 명칭을 상기 제1 관계로 복사하기 위한 후속 변경이 수신되지 않는 경우, 상기 시도된 변경에 대해 충돌(conflict)을 일으키는, 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법.
- 제8항에 있어서,상대 참조(relative reference)에 대한 적어도 하나의 변경과 적어도 하나의 다른 변경을 포함하는 현수 상대 참조(dangling relative reference)를 허용하지 않는 저장 플랫폼 상의 상기 데이터 플랫폼의 제2 인스턴스와 현수 상대 참조를 허용하는 스토리지 플랫폼 상의 상기 데이터 플랫폼의 제1 인스턴스 사이의 동기화를 위해, 상기 하나의 다른 변경 이후에 상기 상대 참조에 대한 상기 변경을 전송하는, 데이터 플랫폼에 대한 복수개의 인스턴스들을 동기화하는 방법.
- 제8항 내지 제14항 중 어느 한 항에 기재된 방법을 수행하기 위한 컴퓨터 실행가능 명령어들을 기록한 컴퓨터 판독가능 기록매체.
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| WOPCT/US03/27419 | 2003-08-21 | ||
| US10/646,646 US7349913B2 (en) | 2003-08-21 | 2003-08-21 | Storage platform for organizing, searching, and sharing data |
| PCT/US2003/027419 WO2005029314A1 (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 |
| PCT/US2004/024508 WO2005024552A2 (en) | 2003-08-21 | 2004-07-29 | Systems and methods for providing relational hierarchical synchronization services |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20060032579A KR20060032579A (ko) | 2006-04-17 |
| KR101120817B1 true KR101120817B1 (ko) | 2012-06-12 |
Family
ID=37141931
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020057010790A KR101120817B1 (ko) | 2003-08-21 | 2004-07-29 | 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 관계 및 계층적 동기화서비스를 제공하는 시스템 및 방법 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7483923B2 (ko) |
| EP (1) | EP1654619A4 (ko) |
| JP (1) | JP4583377B2 (ko) |
| KR (1) | KR101120817B1 (ko) |
| CN (1) | CN100458732C (ko) |
| WO (1) | WO2005024552A2 (ko) |
Families Citing this family (84)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7440985B2 (en) * | 2003-07-31 | 2008-10-21 | Microsoft Corporation | Filtered replication of data stores |
| US8166101B2 (en) * | 2003-08-21 | 2012-04-24 | Microsoft Corporation | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
| US7590643B2 (en) * | 2003-08-21 | 2009-09-15 | Microsoft Corporation | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system |
| US8238696B2 (en) | 2003-08-21 | 2012-08-07 | Microsoft Corporation | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system |
| US8131739B2 (en) | 2003-08-21 | 2012-03-06 | Microsoft Corporation | Systems and methods for interfacing application programs with an item-based storage platform |
| US7401104B2 (en) * | 2003-08-21 | 2008-07-15 | Microsoft Corporation | Systems and methods for synchronizing computer systems through an intermediary file system share or device |
| US7822795B2 (en) * | 2003-09-19 | 2010-10-26 | Lattix, Inc. | Apparatus and methods for displaying and determining dependency relationships among subsystems in a computer software system |
| US7318216B2 (en) * | 2003-09-24 | 2008-01-08 | Tablecode Software Corporation | Software application development environment facilitating development of a software application |
| US7698383B2 (en) * | 2004-02-27 | 2010-04-13 | Research In Motion Limited | System and method for building component applications using metadata defined mapping between message and data domains |
| US7480670B1 (en) * | 2004-03-19 | 2009-01-20 | Teradata Us, Inc. | Activation of native operations for distinct-user defined types |
| US7778962B2 (en) * | 2004-04-30 | 2010-08-17 | Microsoft Corporation | Client store synchronization through intermediary store change packets |
| US7856621B2 (en) * | 2004-05-19 | 2010-12-21 | International Business Machines Corporation | Method for synchronization of concurrently modified interdependent semi-derived artifacts |
| US7975266B2 (en) * | 2004-07-30 | 2011-07-05 | Sap Aktiengesellschaft | Remote installation of computer resources |
| US20070271317A1 (en) * | 2004-08-16 | 2007-11-22 | Beinsync Ltd. | System and Method for the Synchronization of Data Across Multiple Computing Devices |
| US7805422B2 (en) | 2005-02-28 | 2010-09-28 | Microsoft Corporation | Change notification query multiplexing |
| US7822793B2 (en) * | 2005-04-01 | 2010-10-26 | Microsoft Corporation | User data profile namespace |
| US20060242104A1 (en) * | 2005-04-21 | 2006-10-26 | Microsoft Corporation | Systems and methods for manipulating data in a data storage system |
| US7620668B2 (en) * | 2005-05-06 | 2009-11-17 | Microsoft Corporation | Authoritative and non-authoritative restore |
| US20060277224A1 (en) * | 2005-06-07 | 2006-12-07 | Microsoft Corporation | Synchronizing arbitrary data using a flexible schema |
| US7788223B2 (en) | 2005-12-05 | 2010-08-31 | Microsoft Corporation | Resource freshness and replication |
| US7650389B2 (en) * | 2006-02-01 | 2010-01-19 | Subhashis Mohanty | Wireless system and method for managing logical documents |
| US7689593B2 (en) * | 2005-12-30 | 2010-03-30 | Sap Ag | Systems and methods for accessing a shared space in a provider-tenant environment |
| US7917607B2 (en) * | 2005-12-30 | 2011-03-29 | Sap Ag | Software management systems and methods, including use of such systems and methods in a provider-tenant environment |
| WO2007113836A2 (en) * | 2006-04-03 | 2007-10-11 | Beinsync Ltd. | Peer to peer syncronization system and method |
| US7792792B2 (en) * | 2006-05-22 | 2010-09-07 | Microsoft Corporation | Synchronizing structured web site contents |
| US7769727B2 (en) * | 2006-05-31 | 2010-08-03 | Microsoft Corporation | Resolving update-delete conflicts |
| US7933869B2 (en) * | 2006-12-29 | 2011-04-26 | Sap Ag | Method and system for cloning a tenant database in a multi-tenant system |
| US8069184B2 (en) * | 2006-12-29 | 2011-11-29 | Sap Ag | Systems and methods to implement extensibility of tenant content in a provider-tenant environment |
| US20080162587A1 (en) * | 2006-12-29 | 2008-07-03 | Ulrich Auer | Server synchronization for maintenance activities |
| US9558184B1 (en) * | 2007-03-21 | 2017-01-31 | Jean-Michel Vanhalle | System and method for knowledge modeling |
| US9053113B2 (en) | 2007-03-28 | 2015-06-09 | International Business Machines Corporation | Autonomic generation of document structure in a content management system |
| US20080294701A1 (en) * | 2007-05-21 | 2008-11-27 | Microsoft Corporation | Item-set knowledge for partial replica synchronization |
| US8505065B2 (en) * | 2007-06-20 | 2013-08-06 | Microsoft Corporation | Access control policy in a weakly-coherent distributed collection |
| US20090006489A1 (en) * | 2007-06-29 | 2009-01-01 | Microsoft Corporation | Hierarchical synchronization of replicas |
| US7685185B2 (en) * | 2007-06-29 | 2010-03-23 | Microsoft Corporation | Move-in/move-out notification for partial replica synchronization |
| US20090024558A1 (en) * | 2007-07-16 | 2009-01-22 | Sap Ag | Methods and systems for storing and retrieving rejected data |
| CN101276371B (zh) * | 2008-04-18 | 2012-12-05 | 浙江大学 | 基于操作流的异步交互式数据挖掘系统及方法 |
| FR2932289B1 (fr) * | 2008-06-06 | 2012-08-03 | Active Circle | Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees. |
| US8713048B2 (en) * | 2008-06-24 | 2014-04-29 | Microsoft Corporation | Query processing with specialized query operators |
| US8364751B2 (en) | 2008-06-25 | 2013-01-29 | Microsoft Corporation | Automated client/server operation partitioning |
| US8010487B2 (en) | 2008-06-27 | 2011-08-30 | Microsoft Corporation | Synchronization and collaboration within peer-to-peer and client/server environments |
| GB0817022D0 (en) | 2008-09-17 | 2008-10-22 | Sage Technologies Ltd | Information synchronisation |
| US10061464B2 (en) | 2010-03-05 | 2018-08-28 | Oracle International Corporation | Distributed order orchestration system with rollback checkpoints for adjusting long running order management fulfillment processes |
| US10789562B2 (en) | 2010-03-05 | 2020-09-29 | Oracle International Corporation | Compensation patterns for adjusting long running order management fulfillment processes in an distributed order orchestration system |
| US9904898B2 (en) * | 2010-03-05 | 2018-02-27 | Oracle International Corporation | Distributed order orchestration system with rules engine |
| US8290900B2 (en) | 2010-04-24 | 2012-10-16 | Research In Motion Limited | Apparatus, and associated method, for synchronizing directory services |
| US9658901B2 (en) | 2010-11-12 | 2017-05-23 | Oracle International Corporation | Event-based orchestration in distributed order orchestration system |
| US8826222B2 (en) * | 2011-08-02 | 2014-09-02 | International Business Machines Corporation | Pre-merge conflict avoidance |
| US8756566B2 (en) | 2011-11-02 | 2014-06-17 | International Business Machines Corporation | Parallel development of a software system |
| US10552769B2 (en) | 2012-01-27 | 2020-02-04 | Oracle International Corporation | Status management framework in a distributed order orchestration system |
| US9286162B2 (en) | 2012-02-02 | 2016-03-15 | Netapp, Inc. | System and method for guaranteeing consistent data synchronization from a volatile data source |
| US8874551B2 (en) * | 2012-05-09 | 2014-10-28 | Sap Se | Data relations and queries across distributed data sources |
| US9672560B2 (en) | 2012-06-28 | 2017-06-06 | Oracle International Corporation | Distributed order orchestration system that transforms sales products to fulfillment products |
| CN103873495B (zh) * | 2012-12-10 | 2019-01-15 | 联想(北京)有限公司 | 文件同步的方法和使用该方法的电子设备 |
| EP2746972B1 (en) * | 2012-12-20 | 2019-03-20 | Dassault Systèmes | Designing an assembly of parts in a three-dimensional scene |
| US20150220331A1 (en) * | 2014-02-05 | 2015-08-06 | International Business Machines Corporation | Resolving merge conflicts that prevent blocks of program code from properly being merged |
| US10366070B2 (en) | 2015-02-20 | 2019-07-30 | Scality S.A. | Locking and I/O improvements of systems built with distributed consistent database implementations within an object store |
| US10261960B2 (en) | 2014-09-12 | 2019-04-16 | Scality, S.A. | Snapshots and forks of storage systems using distributed consistent databases implemented within an object store |
| US9524302B2 (en) * | 2014-03-05 | 2016-12-20 | Scality, S.A. | Distributed consistent database implementation within an object store |
| US10248682B2 (en) | 2015-02-20 | 2019-04-02 | Scality, S.A. | Object storage system capable of performing snapshots, branches and locking |
| IN2015CH01317A (ko) * | 2015-03-18 | 2015-04-10 | Wipro Ltd | |
| US10019460B2 (en) * | 2015-09-14 | 2018-07-10 | Microsoft Technology Licensing, Llc | Hosted file sync with direct access to hosted files |
| US10693962B1 (en) * | 2015-12-18 | 2020-06-23 | EMC IP Holding Company LLC | Language and mechanism for modeling and exporting storage platform topologies, attributes, and behaviors |
| US11157517B2 (en) | 2016-04-18 | 2021-10-26 | Amazon Technologies, Inc. | Versioned hierarchical data structures in a distributed data store |
| US10467002B2 (en) * | 2016-06-24 | 2019-11-05 | Vmware, Inc. | Validating interoperability of installed components of a computer system |
| US10255064B2 (en) * | 2016-06-24 | 2019-04-09 | Vmware, Inc. | Upgrade analysis of a computer system |
| CN108073592B (zh) * | 2016-11-10 | 2022-09-06 | 惠州市康冠科技有限公司 | 判断序列号是否重复的方法及电视机序列号的写入方法 |
| WO2018176139A1 (en) * | 2017-03-28 | 2018-10-04 | Open Text Sa Ulc | Integration services systems, methods and computer program products for ecm-independent etl tools |
| US10671639B1 (en) | 2017-03-30 | 2020-06-02 | Amazon Technologies, Inc. | Selectively replicating changes to hierarchial data structures |
| US10860550B1 (en) | 2017-03-30 | 2020-12-08 | Amazon Technologies, Inc. | Versioning schemas for hierarchical data structures |
| US10423342B1 (en) | 2017-03-30 | 2019-09-24 | Amazon Technologies, Inc. | Scaling events for hosting hierarchical data structures |
| WO2019084781A1 (en) | 2017-10-31 | 2019-05-09 | EMC IP Holding Company LLC | Management of data using templates |
| US11086901B2 (en) * | 2018-01-31 | 2021-08-10 | EMC IP Holding Company LLC | Method and system for efficient data replication in big data environment |
| US20190342380A1 (en) * | 2018-05-07 | 2019-11-07 | Microsoft Technology Licensing, Llc | Adaptive resource-governed services for performance-compliant distributed workloads |
| US11032367B2 (en) * | 2018-07-16 | 2021-06-08 | Microsoft Technology Licensing, Llc | Long upload time detection and management |
| US11151117B2 (en) | 2018-07-30 | 2021-10-19 | International Business Machines Corporation | Increasing the accuracy of a statement by analyzing the relationships between entities in a knowledge graph |
| JP7111882B2 (ja) * | 2018-08-02 | 2022-08-02 | ヒタチ ヴァンタラ エルエルシー | サーバ情報の分散回復 |
| US11042547B2 (en) * | 2018-09-10 | 2021-06-22 | Nuvolo Technologies Corporation | Mobile data synchronization framework |
| CN109450670B (zh) * | 2018-10-19 | 2022-04-01 | 杭州东方通信软件技术有限公司 | 一种人工智能模式下的指令冲突判断方法及其系统 |
| US11238063B2 (en) * | 2019-07-25 | 2022-02-01 | EMC IP Holding Company LLC | Provenance-based replication in a storage system |
| CN112989773B (zh) * | 2019-12-13 | 2024-02-20 | 北京庖丁科技有限公司 | 用于同步更新数据的方法、装置、设备和计算机可读介质 |
| US20230259505A1 (en) * | 2022-01-26 | 2023-08-17 | Oracle International Corporation | Future transaction processing |
| US11940960B2 (en) | 2022-04-21 | 2024-03-26 | Folder Front, LLC | Intelligent folder-based data organization system |
| US11704199B1 (en) * | 2022-06-11 | 2023-07-18 | Snowflake Inc. | Data replication with cross replication group references |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6317754B1 (en) | 1998-07-03 | 2001-11-13 | Mitsubishi Electric Research Laboratories, Inc | System for user control of version /Synchronization in mobile computing |
| US20020174180A1 (en) | 2001-03-16 | 2002-11-21 | Novell, Inc. | Client-server model for synchronization of files |
Family Cites Families (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US590870A (en) * | 1897-09-28 | Swinging gate | ||
| US5900870A (en) | 1989-06-30 | 1999-05-04 | Massachusetts Institute Of Technology | Object-oriented computer user interface |
| US5710922A (en) * | 1993-06-02 | 1998-01-20 | Apple Computer, Inc. | Method for synchronizing and archiving information between computer systems |
| US6078925A (en) * | 1995-05-01 | 2000-06-20 | International Business Machines Corporation | Computer program product for database relational extenders |
| US5765171A (en) * | 1995-12-29 | 1998-06-09 | Lucent Technologies Inc. | Maintaining consistency of database replicas |
| US5806074A (en) * | 1996-03-19 | 1998-09-08 | Oracle Corporation | Configurable conflict resolution in a computer implemented distributed database |
| US6112024A (en) * | 1996-10-02 | 2000-08-29 | Sybase, Inc. | Development system providing methods for managing different versions of objects with a meta model |
| US6708221B1 (en) * | 1996-12-13 | 2004-03-16 | Visto Corporation | System and method for globally and securely accessing unified information in a computer network |
| US6085192A (en) * | 1997-04-11 | 2000-07-04 | Roampage, Inc. | System and method for securely synchronizing multiple copies of a workspace element in a network |
| US6240414B1 (en) * | 1997-09-28 | 2001-05-29 | Eisolutions, Inc. | Method of resolving data conflicts in a shared data environment |
| US6108004A (en) * | 1997-10-21 | 2000-08-22 | International Business Machines Corporation | GUI guide for data mining |
| US6052735A (en) * | 1997-10-24 | 2000-04-18 | Microsoft Corporation | Electronic mail object synchronization between a desktop computer and mobile device |
| US6151606A (en) * | 1998-01-16 | 2000-11-21 | Visto Corporation | System and method for using a workspace data manager to access, manipulate and synchronize network data |
| US6263342B1 (en) * | 1998-04-01 | 2001-07-17 | International Business Machines Corp. | Federated searching of heterogeneous datastores using a federated datastore object |
| US6519597B1 (en) * | 1998-10-08 | 2003-02-11 | International Business Machines Corporation | Method and apparatus for indexing structured documents with rich data types |
| US6338056B1 (en) * | 1998-12-14 | 2002-01-08 | International Business Machines Corporation | Relational database extender that supports user-defined index types and user-defined search |
| US6336173B1 (en) * | 1999-04-01 | 2002-01-01 | International Business Machines Corporation | Storing and tracking multiple copies of data in data storage libraries |
| US6199195B1 (en) * | 1999-07-08 | 2001-03-06 | Science Application International Corporation | Automatically generated objects within extensible object frameworks and links to enterprise resources |
| US6370541B1 (en) * | 1999-09-21 | 2002-04-09 | International Business Machines Corporation | Design and implementation of a client/server framework for federated multi-search and update across heterogeneous datastores |
| US7013313B1 (en) * | 1999-11-24 | 2006-03-14 | Pumatech, Inc. | System and methods for inheriting information into a dataset |
| US6556983B1 (en) * | 2000-01-12 | 2003-04-29 | Microsoft Corporation | Methods and apparatus for finding semantic information, such as usage logs, similar to a query using a pattern lattice data space |
| US6928467B2 (en) * | 2000-02-02 | 2005-08-09 | Inno Path Software, Inc. | Apparatus and methods for providing data synchronization by facilitating data synchronization system design |
| US6820088B1 (en) * | 2000-04-10 | 2004-11-16 | Research In Motion Limited | System and method for synchronizing data records between multiple databases |
| JP2002149464A (ja) * | 2000-08-17 | 2002-05-24 | Fusionone Inc | データ転送および同期システム用のベースローリングエンジン |
| US6999956B2 (en) * | 2000-11-16 | 2006-02-14 | Ward Mullins | Dynamic object-driven database manipulation and mapping system |
| US6985915B2 (en) * | 2001-02-28 | 2006-01-10 | Kiran Somalwar | Application independent write monitoring method for fast backup and synchronization of files |
| US6877111B2 (en) * | 2001-03-26 | 2005-04-05 | Sun Microsystems, Inc. | Method and apparatus for managing replicated and migration capable session state for a Java platform |
| US7099896B2 (en) * | 2001-04-06 | 2006-08-29 | Patientkeeper, Inc. | Synchronizing data between disparate schemas using composite version |
| US7711771B2 (en) * | 2001-05-25 | 2010-05-04 | Oracle International Corporation | Management and synchronization application for network file system |
| US6697818B2 (en) * | 2001-06-14 | 2004-02-24 | International Business Machines Corporation | Methods and apparatus for constructing and implementing a universal extension module for processing objects in a database |
| US6772178B2 (en) * | 2001-07-27 | 2004-08-03 | Sun Microsystems, Inc. | Method and apparatus for managing remote data replication in a distributed computer system |
| EP1459213B1 (en) * | 2001-11-15 | 2017-05-10 | Good Technology Holdings Limited | System and methods for asychronous synchronization |
| GB0128243D0 (en) * | 2001-11-26 | 2002-01-16 | Cognima Ltd | Cognima patent |
| US7177865B2 (en) * | 2003-06-30 | 2007-02-13 | Sap Ag | Data synchronization method and system |
-
2003
- 2003-10-24 US US10/692,508 patent/US7483923B2/en not_active Expired - Fee Related
-
2004
- 2004-07-29 WO PCT/US2004/024508 patent/WO2005024552A2/en active Application Filing
- 2004-07-29 EP EP04779523A patent/EP1654619A4/en not_active Ceased
- 2004-07-29 KR KR1020057010790A patent/KR101120817B1/ko active IP Right Grant
- 2004-07-29 JP JP2006523869A patent/JP4583377B2/ja not_active Expired - Fee Related
- 2004-07-29 CN CNB2004800017257A patent/CN100458732C/zh not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6317754B1 (en) | 1998-07-03 | 2001-11-13 | Mitsubishi Electric Research Laboratories, Inc | System for user control of version /Synchronization in mobile computing |
| US20020174180A1 (en) | 2001-03-16 | 2002-11-21 | Novell, Inc. | Client-server model for synchronization of files |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100458732C (zh) | 2009-02-04 |
| US7483923B2 (en) | 2009-01-27 |
| WO2005024552A2 (en) | 2005-03-17 |
| KR20060032579A (ko) | 2006-04-17 |
| EP1654619A2 (en) | 2006-05-10 |
| JP2007515695A (ja) | 2007-06-14 |
| JP4583377B2 (ja) | 2010-11-17 |
| US20050044530A1 (en) | 2005-02-24 |
| EP1654619A4 (en) | 2008-02-20 |
| WO2005024552A3 (en) | 2006-11-30 |
| CN1961294A (zh) | 2007-05-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101120817B1 (ko) | 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 관계 및 계층적 동기화서비스를 제공하는 시스템 및 방법 | |
| KR101041319B1 (ko) | 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한정보 단위의 피어 대 피어 동기화를 위해 충돌 처리를제공하는 시스템 및 방법 | |
| RU2377646C2 (ru) | Системы и способы для обеспечения услуг синхронизации для блоков информации, управляемых аппаратной/программной интерфейсной системой | |
| KR100959473B1 (ko) | 저장 플랫폼과 애플리케이션 프로그램 사이의 애플리케이션프로그래밍 인터페이스 | |
| US7739316B2 (en) | Systems and methods for the implementation of base schema for organizing units of information manageable by a hardware/software interface system | |
| US7483915B2 (en) | Systems and method for representing relationships between units of information manageable by a hardware/software interface system | |
| KR101024730B1 (ko) | 항목 기반 저장 플랫폼 내에서 데이터 모델링하기 위한시스템 및 방법 | |
| JP4583376B2 (ja) | ハードウェア／ソフトウェアインタフェースシステムにより管理可能な情報のユニットに対する同期処理サービスを実現するシステムおよび方法 | |
| US20050055354A1 (en) | Systems and methods for representing units of information manageable by a hardware/software interface system but independent of physical representation | |
| JP4901472B2 (ja) | ハードウェア／ソフトウェア・インターフェース・システムにより管理可能な情報の単位を編成するデジタル・イメージ・スキーマの実装のためのシステムおよび方法 | |
| JP4580389B2 (ja) | 仲介ファイルシステム共有または仲介デバイスを介してコンピュータシステムを同期させるためのシステムおよび方法 | |
| JP4583375B2 (ja) | 同期スキーマの実装のためのシステム | |
| JP4580390B2 (ja) | ハードウェア／ソフトウェアインターフェイスシステムによって管理可能な情報単位の拡張および継承のためのシステムおよび方法 | |
| RU2371757C2 (ru) | Системы и способы моделирования данных в основанной на предметах платформе хранения | |
| RU2412461C2 (ru) | Системы и способы сопряжения прикладных программ с платформой хранения на основе статей | |
| KR101109390B1 (ko) | 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보의 단위들에 대한 동기화 서비스를 제공하는시스템 및 방법 | |
| KR101149959B1 (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 | ||
| FPAY | Annual fee payment |
Payment date: 20150121 Year of fee payment: 4 |
|
| FPAY | Annual fee payment |
Payment date: 20160119 Year of fee payment: 5 |
|
| FPAY | Annual fee payment |
Payment date: 20170119 Year of fee payment: 6 |
|
| FPAY | Annual fee payment |
Payment date: 20180118 Year of fee payment: 7 |
|
| FPAY | Annual fee payment |
Payment date: 20190116 Year of fee payment: 8 |
|
| FPAY | Annual fee payment |
Payment date: 20200115 Year of fee payment: 9 |