KR101109399B1 - Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system - Google Patents
Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system Download PDFInfo
- Publication number
- KR101109399B1 KR101109399B1 KR1020057012324A KR20057012324A KR101109399B1 KR 101109399 B1 KR101109399 B1 KR 101109399B1 KR 1020057012324 A KR1020057012324 A KR 1020057012324A KR 20057012324 A KR20057012324 A KR 20057012324A KR 101109399 B1 KR101109399 B1 KR 101109399B1
- Authority
- KR
- South Korea
- Prior art keywords
- item
- version
- storage platform
- folder
- elements
- Prior art date
Links
Images
Classifications
-
- 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
- G06F16/1787—Details of non-transparently synchronising 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
본 발명의 여러 실시예들은, (i) 저장 플랫폼의 복수의 인스턴스들(각각이 그 자신의 데이터 스토어를 가짐)이 유연성 있는 규칙 세트에 따라서 그들의 콘텐츠의 파트들을 동기화하도록 허용하고, (ii) 제3자들이 본 발명의 저장 플랫폼의 데이터 스토어를 동기화하는 인프라구조에 사유 프로토콜(proprietary protocols)을 구현하는 다른 데이터 소스들을 제공하는 동기화 서비스를 제공하는 저장 플랫폼을 포함한다. 여러 실시예들에서, 저장-플랫폼-대-저장-플랫폼 동기화는 관여하는 "복제본"의 그룹 사이에서 발생한다. 예를 들어, 아마도, 상이한 컴퓨터 시스템에서 운영되는 저장 플랫폼의 또 다른 인스턴스의 제어 하에서 또 다른 원격 데이터 스토어를 갖는 저장 플랫폼의 데이터 스토어 사이에 동기화를 제공하는 것이 바람직할 수 있다.
하드웨어/소프트웨어 인터페이스 시스템, 스키마, 아이템, 속성, 관계
Various embodiments of the present invention allow (i) multiple instances of the storage platform, each having its own data store, to synchronize parts of their content according to a flexible set of rules, and (ii) A third party includes a storage platform that provides a synchronization service that provides other data sources that implement proprietary protocols in the infrastructure for synchronizing the data store of the storage platform of the present invention. In various embodiments, storage-platform-to-storage-platform synchronization occurs between groups of participating “replicas”. For example, it may be desirable to provide synchronization between data stores of a storage platform with another remote data store, perhaps under the control of another instance of a storage platform operating on a different computer system.
Hardware / software interface systems, schemas, items, attributes, relationships
Description
<상호 참조><Cross Reference>
본 출원은 2003년 10월 24일자로 출원된 미국 공보 제10/693,362호(대리인 사건 번호 MSFT-2846); "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"이라는 제목으로 2003년 8월 21일자로 출원된 미국 특허 출원 번호 10/646,632(대리인 사건 번호 MSFT-1751); 및 2003년 8월 21일자로 출원된 국제 출원 번호 PCT/US03/26144의 우 선권을 주장하며, 이들 개시물들은 전체가 참조로서 여기에 포함된다.This application discloses US Publication No. 10 / 693,362 filed on October 24, 2003 (Agent Case Number MSFT-2846); United States Patent Application No. 10 / filed Aug. 21, 2003 entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM” 646,632 (agent case number MSFT-1751); And International Application No. PCT / US03 / 26144, filed August 21, 2003, which disclosures are incorporated herein by reference in their entirety.
본 출원은 다음의 공히 양도된 출원들에서 개시된 발명들에 대한 요지와 관련이 있고, 이들 출원의 내용들은 참고로 본 명세서에 통합된다(그리고 편의상 여기서는 부분적으로 요약화된다): "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION"이라는 제목으로 2003년 8월 21일자로 출 원된 미국 특허 출원 번호 10/647,058(대리인 사건 번호 MSFT-1748); "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION"이라는 제목으로 2003년 8월 21일자로 출원된 미국 특허 출원 번호 10/646,941(대리인 사건 번호 MSFT-1749); "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"이라는 제목으로 2003년 8월 21일자로 출원된 미국 특허 출원 번호 10/646,940(대리인 사건 번호 MSFT-1750); "SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"이라는 제목으로 2003년 8월 21일자로 출원된 미국 특허 출원 번호 10/646,645(대리인 사건 번호 MSFT-1752); "SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM"이라는 제목으로 2003년 8월 21일자로 출원된 미국 특허 출원 번호 10/646,575(대리인 사건 번호 MSFT-2733); "STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA"라는 제목으로 2003년 8월 21일자로 출원된 미국 특허 출원 번호 10/646,646(대리인 사건 번호 MSFT-2734); "SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM"이라는 제목으로 2003년 8월 21일자로 출원된 미국 특허 출원 번호 10/646,580(대리인 사건 번호 MSFT-2735); "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"라는 제목으로 2003년 10월 24일자로 출원된 미국 특허 공보 제10/692,779호(대리인 사건번호 MSFT-2829); "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"이라는 제목으로 2003년 10월 24일자로 출원된 미국 특허 출원 번호 10/692,515(대리인 사건 번호 MSFT-2844); "SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"이라는 제목으로 2003년 10월 24일자로 출원된 미국 특허 출원 번호 10/692,508(대리인 사건 번호 MSFT-2845); 및 "SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"이라는 제목으로 2003년 10월 24일자로 출원된 미국 특허 출원 번호 10/693,574(대리인 사건 번호 MSFT-2847).This application is related to the subject matter of the inventions disclosed in the following commonly assigned applications, the contents of which are incorporated herein by reference (and are partially summarized herein for convenience): "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION, US Patent Application No. 10 / 647,058 filed August 21, 2003 (Agency Case Number MSFT-1748); U.S. Patent Application No. 10 / 646,941 filed on August 21, 2003 entitled "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION" (Representative Case Number MSFT-1749); United States Patent Application No. 10 / 646,940, filed Aug. 21, 2003, entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM" 1750); US Patent Application No. 10 / 646,645, filed Aug. 21, 2003, entitled “SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM” (Representative Case Number MSFT-1752); US Patent Application No. 10 / 646,575, filed Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM” (Representative Case Number MSFT-2733); US patent application Ser. No. 10 / 646,646, filed August 21, 2003, entitled “STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA” (Representative Case Number MSFT-2734); US Patent Application No. 10 / 646,580, filed August 21, 2003, entitled “SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM” (Representative Case Number MSFT-2735); U.S. Patent Publication No. 10 / 692,779 filed October 24, 2003 entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM" MSFT-2829); US Patent Application No. 10 / 692,515, filed Oct. 24, 2003 entitled “SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM” (Representative Case Number MSFT-2844); United States Patent Application No. 10 / 692,508 filed October 24, 2003 entitled "SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM" ); And US patent application Ser. No. 10 / 693,574, filed Oct. 24, 2003 entitled "SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM."
<발명의 분야>[0001]
본 발명은 일반적으로 정보 저장 및 검색 분야에 관한 것이고, 보다 구체적으로는, 컴퓨터화된 시스템에서의 서로 다른 타입의 데이터 및 특히 이미지 데이터를 조직하고, 검색하고, 공유하기 위한 액티브 저장 플랫폼(active storage platform)에 관한 것이다.FIELD OF THE INVENTION The present invention generally relates to the field of information storage and retrieval, and more particularly to active storage platforms for organizing, retrieving and sharing different types of data and especially image data in computerized systems. platform).
개개의 디스크 용량은 지난 10년간에 걸쳐서 해마다 대략 칠십 퍼센트(70%) 정도로 성장하였다. 무어의 법칙(Moore's law)은 수년에 걸쳐서 일어난 중앙 처리 장치(CPU)의 엄청난 증진(gains)을 정확히 예언하였다. 유선 및 무선 기술들은 엄청난 접속성 및 대역폭을 제공하였다. 현재의 추세가 지속한다고 추정할 때, 수년 내에 보통 수준의 랩탑 컴퓨터는 대략 1 테라바이트(TB)의 저장 용량을 소유하고 수백만의 파일들을 포함할 것이고, 500 기가바이트(GB) 드라이브들이 흔하게 될 것이다.Individual disk capacity has grown by approximately seventy percent (70%) each year over the last decade. Moore's law accurately predicted the tremendous gains of the central processing unit (CPU) over the years. Wired and wireless technologies have provided tremendous connectivity and bandwidth. Given that current trends persist, within a few years, a normal laptop computer will have approximately 1 terabyte (TB) of storage capacity and contain millions of files, with 500 gigabyte (GB) drives becoming commonplace. .
소비자들은 그들의 컴퓨터를 주로 통신용으로 및 개인 정보(그것이 전통적인 개인 정보 관리 프로그램(PIM : personal information manager) 스타일 데이터이든지 디지털 음악 또는 사진과 같은 미디어이든지간에)를 조직하기 위해 사용한다. 디지털 콘텐츠의 양, 및 미가공 바이트들(raw bytes)을 저장하는 능력은 엄청나게 증가하였지만, 이 데이터를 조직하고 통합하기 위해 소비자들이 이용할 수 있는 방법들은 보조를 맞추지 못하고 있다. 지식 노동자들은 정보를 관리하고 공유하는 데 막대한 양의 시간을 소비하고, 일부 연구에 따르면 지식 노동자들은 그들의 시간의 15-20%를 비생산적인 정보 관련 활동에 소비하는 것으로 추정된다. 다른 연구에 따르면 전형적인 지식 노동자는 하루에 약 2.5 시간을 정보를 검색하는데 소비하는 것으로 추정된다.Consumers use their computers primarily for communication and to organize personal information (whether it is traditional personal information manager (PIM) style data or media such as digital music or photos). The amount of digital content, and the ability to store raw bytes, has increased tremendously, but the methods available to consumers to organize and integrate this data are not keeping pace. Knowledge workers spend enormous amounts of time managing and sharing information, and some studies estimate that 15-20% of their time is spent on unproductive information-related activities. Other research estimates that a typical knowledge worker spends about 2.5 hours a day searching for information.
개발자들 및 정보 기술(IT) 부문들은 상당한 양의 시간과 돈을 사람, 장소, 시간, 및 이벤트와 같은 것들을 나타내는 공통의 저장 추상화(storage abstactions)를 위한 그들 자신의 데이터 스토어(data stores)를 구축하는 데 투자한다. 이것은 중복된 작업을 초래할 뿐만 아니라, 공통의 데이터에 대한 공통의 검색 또는 공유를 위한 아무런 메커니즘도 없이 공통의 데이터의 아일랜드들 (islands)을 생성하기도 한다. 오늘날 마이크로소프트 윈도즈(Microsoft Windows) 운영 시스템을 실행하는 컴퓨터 상에 얼마나 많은 주소록(address book)이 존재할 수 있는지를 좀 생각해보자. 이메일 클라이언트 및 개인 재정 프로그램과 같은 다수의 애플리케이션들이 개개의 주소록을 유지하고, 각각의 그러한 프로그램이 개별적으로 유지하는 주소록 데이터에 대한 공유가 애플리케이션들 사이에서 거의 없다. 따라서, (Microsoft Money와 같은) 재정 프로그램은 수취인들(payees)에 대한 주소들을 (Microsoft Outlook 내의 것과 같은) 이메일 콘택트 폴더(email contact folder) 내에 유지된 주소들과 공유하지 않는다. 실제로, 많은 사용자들이 다수의 디바이스를 갖고 있고 논리적으로 그들의 개인 데이터를 그들 자신들 사이에서 이동 전화(cell phones)에서 MSN 및 AOL과 같은 상업적 서비스까지를 포함하는 다양한 부가적인 소스들을 통하여 동기화시켜야 하지만, 그럼에도 공유 문서들의 제휴는 주로 이메일 메시지에 문서들을 첨부함으로써, 즉 수동으로 비효율적으로 달성된다.Developers and information technology (IT) sectors build their own data stores for common storage abstactions representing significant amounts of time and money such as people, places, time, and events. Invest in it. Not only does this result in redundant work, it also creates islands of common data without any mechanism for common retrieval or sharing of common data. Consider how many address books can exist on a computer running the Microsoft Windows operating system today. Many applications, such as email clients and personal finance programs, maintain individual address books, and there is little sharing between the address book data that each such program maintains individually. Thus, financial programs (such as Microsoft Money) do not share addresses for payees with addresses maintained in an email contact folder (such as in Microsoft Outlook). Indeed, many users have multiple devices and must logically synchronize their personal data between themselves through a variety of additional sources, from cell phones to commercial services such as MSN and AOL, but nevertheless Affiliation of shared documents is mainly accomplished inefficiently by attaching documents to an email message, ie manually.
이 제휴의 결여의 한 가지 이유는 컴퓨터 시스템들에서의 정보의 조직에 대한 전통적인 방법들은 파일-폴더-및-디렉토리-기반 시스템("파일 시스템")을 이용하여, 파일들을 저장하기 위해 사용되는 저장 매체의 물리적 조직의 추상화에 기초하여 복수의 파일들을 폴더들의 디렉토리 계층 구성으로 조직하는 것에 집중하였다는 점이다. 1960년대 중에 개발된 Multics 운영 시스템은 파일, 폴더, 및 디렉토리를 이용하여 운영 시스템 레벨에서 저장 가능한 데이터 단위들을 관리하는 것을 개척한 공로가 인정될 수 있다. 구체적으로, Multics는 파일들의 물리적 주소가 사용자(애플리케이션 및 최종 사용자)에게 투명하지 않았던 파일들의 계층 구성 내에서 기호 주소(symbolic addresses)를 사용하였다(그로써 파일 경로(file path)의 아이디어를 도입하였다). 이 파일 시스템은 임의의 개개의 파일의 파일 포맷과 완전히 무관하였고, 파일들 사이의 관계들은 운영 시스템 레벨에서 무관한 것으로 간주되었다(즉, 계층 구성 내의 파일의 위치 이외). Multics의 출현 이후로, 저장 가능한 데이터는 운영 시스템 레벨에서 파일, 폴더, 및 디렉토리로 조직되었다. 이들 파일들은 일반적으로 파일 시스템에 의해 유지되는 특별한 파일 내에 구현된 파일 계층 구성 자체("디렉토리")를 포함한다. 이 디렉토리는 또한 디렉토리 내의 다른 파일들 모두에 대응하는 엔트리들의 리스트 및 (여기에서 폴더라고 불리는) 계층 구성 내의 그러한 파일들의 노드 위치를 유지한다. 이러한 것이 대략 40년 동안의 기술적 현상이었다.One reason for the lack of this association is that traditional methods for the organization of information in computer systems are used to store files, using file-folder- and-directory-based systems ("file systems"). It focuses on organizing a plurality of files into a directory hierarchy of folders based on the abstraction of the physical organization of the media. The Multics operating system, developed during the 1960s, can be credited with pioneering the management of data units that can be stored at the operating system level using files, folders, and directories. Specifically, Multics used symbolic addresses within the hierarchy of files where the physical addresses of the files were not transparent to users (applications and end users) (thus introducing the idea of file paths). . This file system was completely independent of the file format of any individual file, and the relationships between the files were considered irrelevant at the operating system level (ie, other than the location of the files in the hierarchy). Since the advent of Multics, storeable data has been organized into files, folders, and directories at the operating system level. These files generally contain the file hierarchy itself ("directory") implemented within a particular file maintained by the file system. This directory also maintains a list of entries corresponding to all of the other files in the directory and the node location of those files in the hierarchy (called a folder here). This was a technical phenomenon for about 40 years.
그러나, 파일 시스템은 컴퓨터의 물리적 저장 시스템에 상주하는 정보의 합리적인 표현을 제공하기는 하지만, 그럼에도 파일 시스템은 그 물리적 저장 시스템의 추상화이므로, 파일들의 이용은 사용자가 조작 처리하는 것(컨텍스트, 특징, 및 다른 단위들에 대한 관계를 갖는 단위들)과 운영 시스템이 제공하는 것(파일, 폴더, 및 디렉토리) 사이에 간접화 레벨(번역)(a level of indirection(interpretation))을 필요로 한다. 따라서, 사용자(애플리케이션 및/또는 최종 사용자)는 정보 단위들을 파일 시스템 구조로 강제화할 수 밖에 없으며, 그렇게 하는 것이 비효율적이거나, 불일치하거나, 또는 다르게는 바람직하지 않은 경우라 할지라도 어쩔 수 없다. 더욱이, 기존의 파일 시스템들은 개개의 파일들에 저장된 데이터의 구조에 관하여 거의 알지 못하고, 이 때문에, 그 정보의 대부분은 그것들을 기록한 애플리케이션들에게만 액세스될 수 있는(및 이해될 수 있는) 파일들 내에 감금된(locked up) 상태로 남는다. 따라서, 정보에 대한 개략적인 기술, 및 정보를 관리하기 위한 메커니즘의 이러한 결여는 개개의 사일로들(silos) 사이에 데이터 공유가 거의 없는 데이터의 사일로들의 생성으로 이어진다. 예를 들면, 많은 퍼스널 컴퓨터(PC) 사용자들은 어떤 레벨에서 그들이 상호 작용하는 사람들에 관한 정보를 포함하는 5개 이상의 별개의 스토어들 - 예를 들면, 아웃룩 콘텍트(Outlook Contacts), 온라인 계정 주소, 윈도즈 주소록(Windows Address Book), Quicken Payees, 및 인스턴트 메시징(IM) 버디 리스트 - 를 갖고 있다. 왜냐하면 파일들을 조직하는 것이 이들 PC 사용자들에게는 중요한 도전 과제를 제시하기 때문이다. 대부분의 기존의 파일 시스템들은 파일들 및 폴더들을 조직하기 위해 네스트된 폴더 메타포(nested folder metaphor)를 이용하기 때문에, 파일들의 수가 증가함에 따라서 유연성이 있고 효율적인 조직 체계(organization scheme)를 유지하기 위해 필요한 노력이 상당히 위협을 받게 된다. 그러한 경우에는, 단일 파일의 다수의 분류를 갖는 것이 매우 유익하겠지만, 기존의 파일 시스템에서 하드 또는 소프트 링크들을 이용하는 것은 성가시고 유지하기가 곤란하다.However, while a file system provides a reasonable representation of the information residing in a computer's physical storage system, nevertheless the file system is an abstraction of its physical storage system, so the use of files is something that a user manipulates (contexts, features, And a level of indirection (interpretation) between the units having relationships to other units) and what the operating system provides (files, folders, and directories). Thus, the user (application and / or end user) has no choice but to force the units of information into the file system structure, even if it is inefficient, inconsistent, or otherwise undesirable. Moreover, existing file systems know little about the structure of the data stored in individual files, and because of this, most of that information is in files that can only be accessed (and understood) by the applications that recorded them. It remains locked up. Thus, this lack of a coarse description of the information and the mechanism for managing the information leads to the generation of silos of data with little data sharing between the individual silos. For example, many personal computer (PC) users have five or more separate stores that contain information about the people they interact with at some level—for example, Outlook Contacts, online account addresses, Windows Windows Address Book, Quicken Payees, and Instant Messaging (IM) buddy list. This is because organizing files presents a significant challenge for these PC users. Most existing file systems use nested folder metaphors to organize files and folders, so as the number of files increases, it is necessary to maintain a flexible and efficient organization scheme. Efforts are severely threatened. In such cases, having multiple classifications of a single file would be very beneficial, but using hard or soft links in existing file systems is cumbersome and difficult to maintain.
파일 시스템들의 단점을 해결하려는 몇몇 시도들이 과거에 행해졌지만, 성공하지 못했다. 이들 이전의 시도들 중 일부는 콘텐츠 어드레싱 가능한 메모리(content addressable memory)를 사용하여 물리적 주소에 의하기보다는 콘텐츠에 의해 데이터가 액세스될 수 있게 하는 메커니즘을 제공하는 것을 포함하였다. 그 러나, 이러한 노력들은 성공하지 못한 것으로 판명되었다. 왜냐하면, 콘텐츠 어드레싱 가능한 메모리는 캐시 및 메모리 관리 유닛과 같은 디바이스들에 의한 소규모 사용에 대해서는 유용한 것으로 판명되었지만, 물리적 저장 매체와 같은 디바이스들에 의한 대규모 사용은 아직은 여러가지 이유로 가능하지 않고, 따라서 그러한 해법은 전혀 존재하지 않기 때문이다. 객체 지향 데이터베이스(OODB) 시스템을 이용한 다른 시도들이 행해졌지만, 이 시도들은, 강력한 데이터베이스 특성과 양호한 비파일 표현(non-file representations)을 특징으로 하기 때문에, 파일 표현(file representations)을 다루는 데에는 효과적이지 않았고 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 파일 및 폴더 기반 계층형 구조의 속도, 효율성, 및 단순성을 복제할 수 없었다. 스몰토크(SmallTalk)(및 다른 파생물들)를 이용하려고 한 것들과 같은 다른 노력들은 파일 및 비파일 표현들을 다루는 데에는 상당히 효과적인 것으로 판명되었지만 여러가지 데이터 파일들 사이에 존재하는 관계들을 효율적으로 조직하고 이용하기 위해 필요한 데이터베이스 특징은 결여하였고, 따라서 그러한 시스템들의 전체 효율성은 수용하기 어려운 것이었다. BeOS를 이용하려는 또 다른 시도들(및 다른 그러한 운영 시스템 연구)은, 얼마간의 필요한 데이터베이스 특징들을 제공하면서 파일들을 적절하게 표현할 수 있음에도 불구하고, 비파일 표현들을 다루는 데는 부적당한 것으로 판명되어, 전통적인 파일 시스템들과 동일한 주요 단점이 있다.Several attempts have been made in the past to address the shortcomings of file systems, but have not been successful. Some of these previous attempts have included using content addressable memory to provide a mechanism to allow data to be accessed by content rather than by physical address. However, these efforts proved unsuccessful. Because content addressable memory has proved useful for small use by devices such as cache and memory management units, large use by devices such as physical storage media is not yet possible for a variety of reasons, and such solutions It doesn't exist at all. Although other attempts have been made using the object-oriented database (OODB) system, these attempts are effective in dealing with file representations because they feature strong database features and good non-file representations. And could not replicate the speed, efficiency, and simplicity of file and folder-based hierarchies at the hardware / software interface system level. Other efforts, such as those attempting to use SmallTalk (and other derivatives), have proven to be quite effective in dealing with file and non-file representations, but to efficiently organize and use the relationships that exist between the various data files. The necessary database features were lacking, so the overall efficiency of such systems was unacceptable. Other attempts to use BeOS (and other such operating system studies) have proved inadequate in dealing with non-file representations, despite being able to properly represent the files while providing some necessary database features. There are the same major disadvantages as systems.
데이터베이스 기술은 유사한 도전 과제가 존재하는 또 다른 기술 분야이다. 예를 들면, 관계 데이터베이스(relational database) 모델은 커다란 상업적 성공을 거두었지만, 실제로 독립적 소프트웨어 벤더들(ISV: independent software vendors)은 일반적으로 (마이크로소프트 SQL 서버와 같은) 관계 데이터베이스 소프트웨어 제품들에서 이용 가능한 기능의 작은 부분을 수행한다. 그 대신에, 그러한 제품과의 애플리케이션의 상호 작용의 대부분은 단순한 "gets" 및 "puts"의 형태로 되어 있다. 플랫폼 또는 데이터베이스 불가지론적인(platform or database agnostic) 것과 같은, 이에 대한 다수의 선뜻 명백한 이유들이 있지만, 종종 간과되는 하나의 중요한 이유는 데이터베이스가 반드시 주요 비즈니스 애플리케이션 벤더가 실제로 필요로 하는 정확한 추상화(abstractions)를 제공하지는 않는다는 사실이다. 예를 들면, 실재 세계는 "고객"(customers) 또는 "주문"(orders)과 같은 "아이템"의 개념을 (아이템들 자체로서 주문의 임베드된(embedded) "라인 아이템"(line items)과 함께) 갖고 있지만, 관계 데이터베이스는 표(tables) 및 행(rows)의 관점에서만 거론한다. 따라서, 애플리케이션은 아이템 레벨에서 일관성(consistency), 잠금(locking), 보안, 및/또는 트리거(triggers)의 특징들을 갖기를 원할 수 있지만(몇 가지를 거론하면), 일반적으로 데이터베이스는 이들 특징들을 표/행 레벨에서만 제공한다. 이것은 각각의 아이템이 데이터베이스 내의 어떤 표 내의 단일 행에 매핑되는 경우에는 유효할 수 있지만, 다수의 라인 아이템들을 갖는 주문의 경우에는 하나의 아이템이 실제로 다수의 표에 매핑되는 이유들이 있을 수 있고, 그런 경우라면, 단순한 관계 데이터베이스 시스템은 올바른 추상화들을 완전히 제공하지는 않는다. 따라서, 애플리케이션은 이들 기본적인 추상화를 제공하기 위해 데이터베이스의 상부에 논리를 구축하여야 한다. 바꾸어 말하면, 기본적인 관계 모델은 그 위에서 상위 레벨 애플리케이션들이 쉽게 개발될 수 있는 데이터 저장을 위한 충분한 플랫폼을 제공하지 않는다. 왜냐하면 기본적인 관계 모델은 애플리케이션과 저장 시스템 사이에 간접화 레벨 - 여기에서 데이터의 의미 구조는 어떤 경우에 애플리케이션에서 가시화될 수 있을 뿐이다 - 을 필요로 하기 때문이다. 어떤 데이터베이스 벤더들은 그들의 제품에 상위 레벨 기능을 구축하고 있지만(예컨대 객체 관계 능력(object relational capabilities), 새로운 조직 모델(organizational models) 등을 제공하는 것과 같은), 아직은 아무도 요구되는 일종의 포괄적인 해법(comprehensive solution)을 제공하지 못했다. 여기에서 진정으로 포괄적인 해법은 유용한 도메인 추상화(예컨대 "Persons"(사람), "Locations"(장소), "Events"(이벤트) 등)에 대해 유용한 데이터 모델 추상화(예컨대 "Items"(아이템), "Extensions"(확장), "Relationships"(관계) 등)을 제공하는 것이다).Database technology is another technical area where similar challenges exist. For example, the relational database model has had great commercial success, but in fact independent software vendors (ISVs) are generally available in relational database software products (such as Microsoft SQL Server). Perform a small part of the function. Instead, most of the application's interaction with such products is in the form of simple "gets" and "puts". There are a number of obvious reasons for this, such as platform or database agnostic, but one important reason that is often overlooked is that the database does not necessarily capture the exact abstractions that major business application vendors actually need. It is not provided. For example, the real world incorporates the concept of "items" such as "customers" or "orders" (with the embedded "line items" of the order as the items themselves). The relational database is only discussed in terms of tables and rows. Thus, an application may want to have features of consistency, locking, security, and / or triggers at the item level (in some cases), but in general a database may list these features. Provided only at the / row level. This may be valid if each item is mapped to a single row in a table in the database, but for orders with multiple line items, there may be reasons why an item actually maps to multiple tables, such as If that's the case, a simple relational database system doesn't fully provide the right abstractions. Thus, the application must build logic on top of the database to provide these basic abstractions. In other words, the underlying relationship model does not provide a sufficient platform for data storage on which high-level applications can be easily developed. This is because the underlying relationship model requires a level of indirection between the application and the storage system, where the semantics of the data can only be made visible to the application in some cases. Some database vendors are building high-level capabilities in their products (such as providing object relational capabilities, new organizational models, etc.), but a kind of comprehensive solution that no one is still looking for. solution). A truly comprehensive solution here is useful data model abstractions (e.g. "Items" (items), for useful domain abstractions (e.g. "Persons", "Locations", "Events", etc.), "Extensions", "Relationships", etc.).
기존의 데이터 저장 및 데이터베이스 기술에서의 전술한 결점들을 고려하여, 컴퓨터 시스템에서의 모든 타입의 데이터를 조직하고, 검색하고, 공유하는 개선된 능력을 제공하는 새로운 저장 플랫폼 - 기존의 파일 시스템 및 데이터베이스 시스템을 넘어서 데이터 플랫폼을 확장하고 넓히며, 모든 타입의 데이터에 대한 스토어가 되도록 설계되어 있는 저장 플랫폼 - 이 요구되고 있다. 본 발명은, 이전에 참조로서 포함된 관련 발명들과 함께, 이러한 요구를 만족시킨다.Taking into account the aforementioned drawbacks of existing data storage and database technologies, a new storage platform providing an improved ability to organize, search and share all types of data in computer systems-existing file systems and database systems There is a need for a storage platform that extends and extends the data platform beyond and designed to be a store for all types of data. The present invention, together with the related inventions previously incorporated by reference, satisfies this need.
<개요><Overview>
이하의 개요는 본 명세서의 앞에서 참고로 통합된 관련 발명들("관련 발명 들")의 컨텍스트에서 기술된 발명의 다양한 양태들에 대한 개관을 제공한다. 이 개요는 본 발명의 모든 중요한 양태들에 대한 남김 없는 설명을 제공하기 위한 것도 아니고, 본 발명의 범위를 정의하기 위한 것도 아니다. 오히려, 이 개요는 다음에 오는 상세한 설명 및 도면들에 대한 서론의 역할을 하도록 의도되어 있다.The following summary provides an overview of the various aspects of the invention described in the context of related inventions (“related inventions”) incorporated herein by reference in their entirety. This Summary is not intended to provide an exhaustive description of all important aspects of the invention, nor is it intended to define the scope of the invention. Rather, this summary is intended to serve as an introduction to the following detailed description and drawings.
본 발명 뿐만 아니라 관련 발명들은 총괄적으로 데이터를 조직하고, 검색하고, 공유하기 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 기존의 파일 시스템 및 데이터베이스 시스템을 넘어서 데이터 저장의 개념을 확장하고 넓히며, 구조화되거나, 비구조화되거나, 또는 반구조화된(semi-structured) 데이터를 포함하는 모든 타입의 데이터에 대한 스토어가 되도록 설계되어 있다.The invention as well as related inventions collectively relate to a storage platform for organizing, retrieving, and sharing data. The storage platform of the present invention extends and broadens the concept of data storage beyond existing file systems and database systems, for all types of data including structured, unstructured, or semi-structured data. It is designed to be a store.
본 발명의 저장 플랫폼은 데이터베이스 엔진 상에 구현된 데이터 스토어를 포함한다. 데이터베이스 엔진은 객체 관계 확장들(object relational extensions)을 갖는 관계 데이터베이스 엔진을 포함한다. 데이터 스토어는 데이터의 조직, 검색, 공유, 동기화, 및 보안을 지원하는 데이터 모델을 구현한다. 데이터의 구체적인 타입들은 스키마들에서 기술되고, 플랫폼은 데이터의 새로운 타입들(본질적으로 스키마들에 의해 제공된 기본적인 타입들의 서브타입들(subtypes))을 정의하도록 스키마들의 세트를 확장하는 메커니즘을 제공한다. 동기화 능력은 사용자들 또는 시스템들 사이에서의 데이터의 공유를 용이하게 한다. 기존의 파일 시스템들과의 데이터 스토어의 상호 운용성을 허용하면서도 그러한 전통적인 파일 시스템들의 제한이 없는 파일-시스템 같은 능력들(file-system-like capabilities)이 제공된다. 변경 추적 메커니즘은 데이터 스토어에 대한 변경들을 추적하는 능력을 제공한다. 저장 플랫폼은 애플리케이션들이 저장 플랫폼의 전술한 능력들 모두에 액세스하고 또한 스키마들에서 기술된 데이터에 액세스할 수 있게 하는 애플리케이션 프로그램 인터페이스들의 세트를 더 포함한다.The storage platform of the present invention includes a data store implemented on a database engine. The database engine includes a relational database engine with object relational extensions. Data stores implement a data model that supports organization, retrieval, sharing, synchronization, and security of data. Specific types of data are described in schemas, and the platform provides a mechanism to extend the set of schemas to define new types of data (essentially subtypes of the basic types provided by the schemas). The synchronization capability facilitates sharing of data between users or systems. File-system-like capabilities are provided that allow for interoperability of the data store with existing file systems, but without the limitations of such traditional file systems. The change tracking mechanism provides the ability to track changes to the data store. The storage platform further includes a set of application program interfaces that allow applications to access all of the aforementioned capabilities of the storage platform and also to access the data described in the schemas.
데이터 스토어에 의해 구현되는 데이터 모델은 아이템(items), 엘리먼트(elements), 및 관계(relationships)에 의하여 데이터 저장의 단위들을 정의한다. 아이템은 데이터 스토어에 저장 가능한 데이터의 단위이고 하나 이상의 엘리먼트 및 관계를 포함할 수 있다. 엘리먼트는 하나 이상의 필드들(본 명세서에서는 속성(property)이라고도 함)을 포함하는 타입의 인스턴스이다. 관계는 2개의 아이템들 간의 링크이다. (본 명세서에서 사용될 때, 이들 및 다른 특정한 용어들은 아주 밀접하게 사용되는 다른 용어들과 분리하기 위하여 대문자로 시작될 수 있다. 그러나, 대문자로 시작된 용어, 예를 들면 "Item"과 대문자로 시작되지 않을 때의 동일한 용어, 예를 들면 "item"을 구별하려는 아무런 의도도 없고, 그러한 구별이 가정되거나 암시되어서는 안 된다.)The data model implemented by the data store defines the units of data storage by items, elements, and relationships. An item is a unit of data that can be stored in a data store and can include one or more elements and relationships. An element is an instance of a type that contains one or more fields (also referred to herein as properties). A relationship is a link between two items. (When used herein, these and other specific terms may begin with an uppercase letter to separate them from other terms that are used very closely. However, terms that begin with an uppercase letter, such as "Item" and may not begin with an uppercase letter. There is no intention to distinguish the same terminology, eg "item," and such distinction must not be assumed or implied.)
컴퓨터 시스템은 복수의 아이템들 - 각각의 아이템은 하드웨어/소프트웨어 인터페이스 시스템에 의해 조작 처리될 수 있는 개별 저장 가능한 정보 단위(discrete storable unit of information)를 구성함 - 과; 상기 아이템들에 대한 조직 구조(organizational structure)를 구성하는 복수의 아이템 폴더들과; 복수의 아이템들을 조작 처리하기 위한 하드웨어/소프트웨어 인터페이스 시스템을 포함하고, 각각의 아이템은 적어도 하나의 아이템 폴더에 속하고 2 이상의 아이템 폴더에 속할 수 있다.The computer system comprises a plurality of items, each item constructing a discrete storage unit of information that can be manipulated by a hardware / software interface system; A plurality of item folders constituting an organizational structure for the items; A hardware / software interface system for manipulating a plurality of items, each item belonging to at least one item folder and belonging to two or more item folders.
아이템 또는 아이템의 속성 값들의 일부는 지속성 스토어(persistent store)로부터 도출되는 것에 대립되는 것으로서 동적으로 계산될 수 있다. 바꾸어 말하면, 하드웨어/소프트웨어 인터페이스 시스템은 아이템이 저장될 것을 요구하지 않고, 아이템들의 현재 세트를 열거(enumerate)하는 능력 또는 저장 플랫폼의 그것의 식별자(이에 대해서는 애플리케이션 프로그래밍 인터페이스, 즉 API를 설명하는 섹션들에서 보다 상세히 설명됨)가 주어질 경우 아이템을 검색하는 능력과 같은 어떤 동작들이 지원된다 - 예를 들면, 아이템은 이동 전화(cell phone)의 현재 위치이거나 또는 온도 센서 상의 온도 수치일 수 있다. 하드웨어/소프트웨어 인터페이스 시스템은 복수의 아이템들을 조작 처리할 수 있고, 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리되는 복수의 관계들(Relationships)에 의해 상호 연결된 아이템들을 더 포함할 수 있다.An item or part of an item's attribute values may be calculated dynamically as opposed to being derived from a persistent store. In other words, the hardware / software interface system does not require the item to be stored, but the ability to enumerate the current set of items or its identifier of the storage platform (in this section sections describing the application programming interface, ie API). Some operations are supported, such as the ability to search for an item, as described in greater detail below, eg, the item may be the current location of a cell phone or a temperature reading on a temperature sensor. The hardware / software interface system can manipulate a plurality of items and can further include items interconnected by a plurality of relationships managed by the hardware / software interface system.
컴퓨터 시스템을 위한 하드웨어/소프트웨어 인터페이스 시스템은 상기 하드웨어/소프트웨어 인터페이스 시스템이 이해하고 미리 정해지고 예측 가능한 방법으로 직접 처리할 수 있는 코어 아이템들(core Items)의 세트를 정의하는 코어 스키마를 더 포함한다. 복수의 아이템들을 조작 처리하기 위하여, 컴퓨터 시스템은 상기 아이템들을 복수의 관계들로 상호 연결하고 상기 관계들을 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 관리한다.The hardware / software interface system for a computer system further includes a core schema that defines a set of core items that the hardware / software interface system can understand and directly process in a predetermined and predictable manner. To manipulate a plurality of items, a computer system interconnects the items into a plurality of relationships and manages the relationships at a hardware / software interface system level.
저장 플랫폼의 API는 저장 플랫폼 스키마들의 세트에서 정의된 각각의 아이템, 아이템 확장, 및 관계에 대한 데이터 클래스들을 제공한다. 또한, 애플리케이션 프로그래밍 인터페이스는 상기 데이터 클래스들에 대한 비헤이비어들(behaviors)의 공통의 세트를 정의하고, 상기 데이터 클래스들과 함께, 저장 플랫폼 API에 대한 기본적인 프로그래밍 모델을 제공하는 프레임워크 클래스들의 세트를 제공한다. 저장 플랫폼 API는 하위(underlying) 데이터베이스 엔진의 쿼리 언어(query language)의 상세로부터 애플리케이션 프로그래머를 격리시키는 방식으로, 애플리케이션 프로그래머들이 데이터 스토어 내의 아이템들의 갖가지 속성들에 기초하여 쿼리들을 형성할 수 있게 하는 간략화된 쿼리 모델을 제공한다. 저장 플랫폼 API는 또한 애플리케이션 프로그램에 의해 행해진 아이템에 대한 변경들을 수집하고 그 후 그것들을 데이터 스토어가 구현되는 데이터베이스 엔진(또는 임의의 종류의 저장 엔진)에 의해 요구되는 정확한 업데이트들로 조직한다. 이에 따라 애플리케이션 프로그래머들이 메모리 내의 아이템에 대한 변경들을 행할 수 있게 되고, 데이터 스토어 업데이트들의 복잡성은 API에게 남겨진다.The storage platform's API provides data classes for each item, item extension, and relationship defined in the set of storage platform schemas. In addition, an application programming interface defines a common set of behaviors for the data classes and, together with the data classes, provides a set of framework classes that provide a basic programming model for a storage platform API. do. The storage platform APIs isolate application programmers from the details of the underlying database engine's query language, simplifying the application programmers to form queries based on various attributes of items in the data store. Provide a modeled query model. The storage platform API also collects changes to items made by the application program and then organizes them into the exact updates required by the database engine (or any kind of storage engine) in which the data store is implemented. This allows application programmers to make changes to items in memory, leaving the complexity of data store updates to the API.
본 발명의 저장 플랫폼은, 그것의 공통의 저장 토대(storage foundation) 및 조직적으로 배열된 데이터(schematized data)를 통하여, 소비자, 지식 노동자 및 기업에게 보다 효율적인 애플리케이션 개발을 가능케 한다. 그것은 그것의 데이터 모델에서의 고유한 능력들을 이용할 수 있게 할 뿐만 아니라, 기존의 파일 시스템 및 데이터베이스 액세스 방법들을 포용하고 확장하는 풍부하고 확장성이 있는 애플리케이션 프로그래밍 인터페이스를 제공한다.The storage platform of the present invention, through its common storage foundation and organized data, enables more efficient application development for consumers, knowledge workers and enterprises. It not only makes use of the capabilities inherent in its data model, but also provides a rich and extensible application programming interface that embraces and extends existing file system and database access methods.
(상세한 설명의 섹션 Ⅱ에서 상세히 설명되는) 상호 관련 발명들의 이러한 중요한 구조의 관점 내에서, 본 발명은 특히 (상세한 설명의 섹션 Ⅲ에서 상세히 설명되는) 동기화 스키마에 관한 것이다. 본 발명의 다른 특징들 및 이점들은 본 발명에 대한 이하의 상세한 설명 및 첨부 도면들로부터 명백해질 것이다.Within the context of this important structure of interrelated inventions (described in detail in section II of the detailed description), the present invention relates in particular to a synchronization scheme (described in detail in section III of the detailed description). Other features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings.
전술한 개요는 물론, 본 발명에 대한 이하의 상세한 설명은, 첨부된 도면들과 함께 읽으면 더 잘 이해된다. 본 발명을 예시 설명하기 위하여, 본 발명의 갖가지 양태들에 대한 예시적인 실시예들이 도면들에 도시되어 있지만, 본 발명은 개시된 특정한 방법들 및 수단들에 한정되지 않는다. 도면들에서,In addition to the foregoing summary, the following detailed description of the invention is better understood when read in conjunction with the accompanying drawings. In order to illustrate the invention, illustrative embodiments of various aspects of the invention are shown in the drawings, but the invention is not limited to the specific methods and means disclosed. In the drawings,
도 1은 본 발명의 양태들이 통합될 수 있는 컴퓨터 시스템을 나타내는 블록도.1 is a block diagram illustrating a computer system in which aspects of the present invention may be incorporated.
도 2는 3개의 컴포넌트 그룹들: 하드웨어 컴포넌트, 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트, 및 애플리케이션 프로그램 컴포넌트로 나누어진 컴퓨터 시스템을 예시하는 블록도.2 is a block diagram illustrating a computer system divided into three component groups: hardware component, hardware / software interface system component, and application program component.
도 2A는 파일 기반 운영 시스템(file-based operating system)에서의 디렉토리 내의 폴더들 내에 그룹화된 파일들에 대한 전통적인 트리 기반 계층형 구조를 예시하는 도면.FIG. 2A illustrates a traditional tree-based hierarchical structure for files grouped into folders in a directory in a file-based operating system. FIG.
도 3은 저장 플랫폼을 예시하는 블록도.3 is a block diagram illustrating a storage platform.
도 4는 아이템, 아이템 폴더, 및 카테고리 간의 구조적 관계를 예시하는 도면.4 illustrates the structural relationship between items, item folders, and categories.
도 5A는 아이템의 구조를 예시하는 블록도.5A is a block diagram illustrating the structure of an item.
도 5B는 도 5A의 아이템의 복합 속성 타입들을 예시하는 블록도.5B is a block diagram illustrating complex attribute types of the item of FIG. 5A.
도 5C는 "Location" 아이템을 예시하는 블록도 - 그것의 복합 타입들이 더 설명(명시적으로 리스트)되어 있음 - .5C is a block diagram illustrating an “Location” item, where its complex types are further described (explicitly listed).
도 6A는 베이스 스키마(Base Schema)에서 발견된 아이템의 서브타입(subtype)으로서 아이템을 예시하는 도면.FIG. 6A illustrates the item as a subtype of the item found in the Base Schema. FIG.
도 6B는 도 6A의 서브타입 아이템을 예시하는 블록도 - (그것의 순간 속성들(immediate properties) 외에) 그것의 상속 타입들(inherited types)이 명시적으로 리스트되어 있음 - .FIG. 6B is a block diagram illustrating the subtype item of FIG. 6A, where its inherited types are explicitly listed (in addition to its instantiated properties).
도 7은 2개의 상위 레벨 클래스 타입인 Item 및 PropertyBase, 및 그들로부터 도출된 부가적인 베이스 스키마 타입들을 포함하는 베이스 스키마를 예시하는 블록도.FIG. 7 is a block diagram illustrating a base schema comprising two higher level class types, Item and PropertyBase, and additional base schema types derived therefrom.
도 8A는 코어 스키마(Core Schema) 내의 아이템들을 예시하는 블록도.8A is a block diagram illustrating items in a Core Schema.
도 8B는 코어 스키마 내의 속성 타입들을 예시하는 블록도.8B is a block diagram illustrating attribute types in a core schema.
도 9는 아이템 폴더(Item Folder), 그것의 멤버 아이템들, 및 아이템 폴더와 그것의 멤버 아이템들 간의 상호 연결 관계들(Relationships)을 예시하는 블록도.9 is a block diagram illustrating an Item Folder, its member items, and the relations between the Item Folder and its member items.
도 10은 카테고리(Category)(이것은 또한 아이템 자체임), 그것의 멤버 아이템들, 및 카테고리와 그것의 멤버 아이템들 간의 상호 연결 관계들을 예시하는 블록도.10 is a block diagram illustrating a Category (which is also the item itself), its member items, and the interconnections between the category and its member items.
도 11은 저장 플랫폼의 데이터 모델의 참조 타입 계층 구성을 예시하는 도면.11 illustrates a reference type hierarchy of data model of the storage platform.
도 12는 관계들이 어떻게 분류되는지를 예시하는 도면.12 illustrates how relationships are classified.
도 13은 통지 메커니즘을 예시하는 도면.13 illustrates a notification mechanism.
도 14는 2개의 트랜잭션들이 양쪽 모두 새로운 레코드를 동일한 B-트리에 삽입하는 예를 예시하는 도면.14 illustrates an example where two transactions insert both new records into the same B-tree.
도 15는 데이터 변경 검출 프로세스를 예시하는 도면.15 illustrates a data change detection process.
도 16은 예시적인 디렉토리 트리를 예시하는 도면.16 illustrates an example directory tree.
도 17은 디렉토리 기반 파일 시스템의 기존의 폴더가 저장 플랫폼 데이터 스토어 내로 이동되는 예를 도시하는 도면.FIG. 17 illustrates an example of an existing folder of a directory-based file system being moved into a storage platform data store. FIG.
도 18은 컨테인먼트 폴더(Containment Folders)의 개념을 예시하는 도면.FIG. 18 illustrates the concept of Container Folders. FIG.
도 19는 저장 플랫폼 API 스택의 기본적인 아키텍처를 예시하는 도면.19 illustrates the basic architecture of the storage platform API stack.
도 20은 저장 플랫폼 API의 갖가지 컴포넌트들을 개략적으로 나타내는 도면.20 schematically illustrates various components of a storage platform API.
도 21A는 예시적인 콘택트 아이템(Contacts Item) 스키마에 대한 그림 표현.21A is a pictorial representation of an example Contact Items Item schema.
도 21B는 도 21A의 예시적인 콘택트 아이템 스키마의 엘리먼트들에 대한 그림 표현.FIG. 21B is a pictorial representation of elements of the example contact item schema of FIG. 21A. FIG.
도 22는 저장 플랫폼 API의 런타임 프레임워크(runtime framework)를 예시하는 도면.FIG. 22 illustrates a runtime framework of the storage platform API. FIG.
도 23은 "FindAll" 동작의 실행을 예시하는 도면.Fig. 23 illustrates execution of the "FindAll" operation.
도 24는 저장 플랫폼 스키마로부터 저장 플랫폼 API 클래스들이 생성되는 프로세스를 예시하는 도면.24 illustrates a process by which storage platform API classes are generated from a storage platform schema.
도 25는 파일 API가 기초고 있는 스키마를 예시하는 도면.25 is a diagram illustrating a schema on which a file API is based.
도 26은 데이터 보안을 위해 사용되는 액세스 마스크 포맷을 예시하는 도면이다.FIG. 26 is a diagram illustrating an access mask format used for data security.
도 27은 기존의 보안 영역으로부터 새로운 동일하게 보호되는 보안 영역이 만들어지는 것을 도시하는 도면(부분 a, b, 및 c).FIG. 27 is a diagram showing that new equally protected security zones are created from existing security zones (parts a, b, and c).
도 28은 아이템 검색 뷰(Item search view)의 개념을 예시하는 도면.FIG. 28 illustrates the concept of an Item search view. FIG.
도 29는 예시적인 아이템 계층 구성을 예시하는 도면.29 illustrates an example item hierarchy configuration.
도 30A는 제1 및 제2 코드 세그먼트들이 통신하는 도관(conduit)으로서의 인터페이스 Interface1을 예시하는 도면.FIG. 30A illustrates interface Interface1 as a conduit through which first and second code segments communicate. FIG.
도 30B는 시스템의 제1 및 제2 코드 세그먼트들이 매체 M을 통하여 통신할 수 있게 하는 인터페이스 객체 I1 및 I2를 포함하는 인터페이스를 예시하는 도면.FIG. 30B illustrates an interface that includes interface objects I1 and I2 that allow first and second code segments of the system to communicate over medium M. FIG.
도 31A는 인터페이스의 통신들을 변환하기 위해 인터페이스 Interface1에 의해 제공된 기능이 어떻게 다수의 인터페이스 Interface1A, Interface1B, Interface1C로 세분될 수 있는지를 예시하는 도면.FIG. 31A illustrates how the functionality provided by interface Interface1 to convert communications of an interface can be subdivided into multiple interfaces Interface1A, Interface1B, Interface1C. FIG.
도 31B는 인터페이스 I1에 의해 제공된 기능이 어떻게 다수의 인터페이스 I1a, 인터페이스 I1b, 인터페이스 I1c로 세분될 수 있는지를 예시하는 도면.FIG. 31B illustrates how the functionality provided by interface I1 can be subdivided into multiple interfaces Ila, interface Ilb, interface Ilc.
도 32A는 무의미한 파라미터 정밀도(precision)가 무시되거나 또는 임의의 파라미터로 대체될 수 있는 시나리오를 예시하는 도면.32A illustrates a scenario in which meaningless parameter precision can be ignored or replaced with any parameter.
도 32B는 인터페이스가 파라미터들을 무시하거나 또는 인터페이스에 파라미터를 부가하도록 정의되는 대체 인터페이스에 의해 대체되는 시나리오를 예시하는 도면.32B illustrates a scenario in which an interface is replaced by an alternate interface defined to ignore parameters or add parameters to the interface.
도 33A는 제1 및 제2 코드 세그먼트들이 이들 둘 다를 포함하는 모듈로 병합되는 시나리오를 예시하는 도면.FIG. 33A illustrates a scenario in which first and second code segments are merged into a module that includes both.
도 33B는 병합된 인터페이스를 형성하기 위해 인터페이스의 일부 또는 전부가 또 다른 인터페이스 내에 인라인(inline)으로 기입될 수 있는 시나리오를 예시하는 도면.33B illustrates a scenario in which some or all of an interface may be written inline within another interface to form a merged interface.
도 34A는 미들웨어(middleware)의 하나 이상의 피스들(pieces)을 하나 이상의 서로 다른 인터페이스들에 일치시키도록 하기 위해 상기 하나 이상의 피스들이 제1 인터페이스 상의 통신들을 어떻게 변환할 수 있는지를 예시하는 도면.34A illustrates how the one or more pieces can translate communications on a first interface to match one or more pieces of middleware to one or more different interfaces.
도 34B는 하나의 인터페이스로부터 통신을 수신하지만 그 기능을 제2 및 제3 인터페이스들로 송신하는 인터페이스와 함께 어떻게 코드 세그먼트가 도입될 수 있는지를 예시하는 도면.34B illustrates how a code segment can be introduced with an interface that receives communication from one interface but transmits its functionality to the second and third interfaces.
도 35A는 JIT(just-in-time complier)가 어떻게 하나의 코드 세그먼트로부터 또 다른 코드 세그먼트로 통신들을 변환할 수 있는지를 예시하는 도면.35A illustrates how a just-in-time complier (JIT) can transform communications from one code segment to another.
도 35B는 하나 이상의 인터페이스들을 동적으로 재기입하는 JIT 방법이 상기 인터페이스를 동적으로 팩터링(factor)하거나 또는 그렇지 않으면 상기 인터페이스를 변경하기 위해 적용될 수 있는 JIT 방법을 예시하는 도면.35B illustrates a JIT method in which a JIT method for dynamically rewriting one or more interfaces may be applied to dynamically factor or otherwise change the interface.
도 36은 공통 데이터 스토어의 3가지 인스턴스들 및 이들을 동기화시키기 위한 컴포넌트들을 예시하는 도면.36 illustrates three instances of a common data store and components for synchronizing them.
도 37은 상태가 산출되는 방법 또는 그것의 관련 메타데이터가 교환되는 방법을 인식하지 못하는 간단한 어댑터를 가정하는 본 발명의 일 실시예를 예시하는 도면.FIG. 37 illustrates an embodiment of the present invention assuming a simple adapter that does not recognize how a state is calculated or how its associated metadata is exchanged.
목차Contents
I. 도입I. Introduction
A. 예시적인 컴퓨팅 환경A. Example Computing Environment
B. 전통적인 파일 기반 저장B. Traditional File Based Storage
Ⅱ. 데이터를 조직, 검색, 및 공유하기 위한 WINFS 저장 플랫폼II. WINFS storage platform for organizing, searching, and sharing data
A. 용어 모음A. Glossary
B. 저장 플랫폼 개관B. Storage Platform Overview
C. 데이터 모델C. Data Model
1. 아이템1. Item
2. 아이템 식별2. Item Identification
3. 아이템 폴더 및 카테고리3. Item Folders and Categories
4. 스키마4. Schema
a) 베이스 스키마a) base schema
b) 코어 스키마b) core schema
5. 관계5. Relationship
a) 관계 선언a) relationship declaration
b) 홀딩 관계b) holding relationship
c) 임베딩 관계c) embedding relationship
d) 참조 관계d) reference relationships
e) 규칙 및 제약e) rules and restrictions
f) 관계의 순서화f) ordering of relationships
6. 확장성6. Scalability
a) 아이템 확장a) item expansion
b) NestedElement 타입 확장b) NestedElement type extension
D. 데이터베이스 엔진D. Database Engine
1. UDT를 이용한 데이터 스토어 구현1. Data Store Implementation using UDT
2. 아이템 매핑2. Item Mapping
3. 확장 매핑3. Extension Mapping
4. 네스트된 엘리먼트 매핑4. Nested Element Mapping
5. 객체 ID5. Object ID
6. SQL 객체 명명6. Naming SQL Objects
7. 칼럼 명명7. Column Naming
8. 검색 뷰8. Search View
a) 아이템a) items
(1) 마스터 아이템 검색 뷰(1) Master Item Search View
(2) 타입 아이템 검색 뷰(2) Type Item Search View
b) 아이템 확장b) item expansion
(1) 마스터 확장 검색 뷰(1) master extended search view
(2) 타입 확장 검색 뷰(2) type extended search view
c) 네스트된 엘리먼트c) nested elements
d) 관계d) relationships
(1) 마스터 관계 검색 뷰(1) Master Relationship Search View
(2) 관계 인스턴스 검색 뷰(2) relationship instance search view
e)e)
9. 업데이트9. Update
10. 변경 추적 및 툼스톤(Tomstones)10. Change Tracking and Tombstones
a) 변경 추적a) change tracking
(1) "마스터" 검색 뷰에서의 변경 추적(1) Change tracking in the "master" search view
(2) "타입" 검색 뷰에서의 변경 추적(2) Change tracking in "type" search views
b) 툼스톤b) tombstone
(1) 아이템 툼스톤(1) Item Tombstone
(2) 확장 툼스톤(2) Extended Tombstone
(3) 관계 툼스톤(3) relationship tombstone
(4) 툼스톤 클린업(4) Tombstone Clean Up
11. 도우미 API 및 함수11. Helper APIs and Functions
a) 함수 [System.Storage].GetItema) function [System.Storage] .GetItem
b) 함수 [System.Storage].GetExtensionb) function [System.Storage] .GetExtension
c) 함수 [System.Storage].GetRelationshipc) function [System.Storage] .GetRelationship
12. 메타데이터12. Metadata
a) 스키마 메타데이터a) schema metadata
b) 인스턴스 메타데이터b) instance metadata
E. 보안E. Security
F. 통지 및 변경 추적F. Notice and Change Tracking
G. 전통적인 파일 시스템 상호 운용성G. Traditional File System Interoperability
H. 저장 플랫폼 APIH. Storage Platform API
Ⅲ. 동기화 APIIII. Sync API
A. 동기화 개관A. Synchronization Overview
1. 저장 플랫폼 대 저장 플랫폼 동기화1. Storage platform vs storage platform synchronization
a) 동기화(Sync) 제어 애플리케이션a) Sync control application
b) 스키마 주석b) schema annotation
c) Sync 구성c) Sync configuration
(1) 공동체 폴더 - 매핑(1) Community Folder-Mapping
(2) 프로파일(2) profile
(3) 스케줄(3) schedule
d) 충돌 핸들링d) collision handling
(1) 충돌 검출(1) collision detection
(a) 지식 기반 충돌(a) knowledge base conflict
(b) 제약 기반 충돌(b) constraint-based collisions
(2) 충돌 처리(2) conflict handling
(a) 자동 충돌 레졸루션(a) Auto Collision Resolution
(b) 충돌 로깅(b) conflict logging
(c) 충돌 검사 및 레졸루션(c) Collision Checking and Resolution
(d) 복제의 컨버전스(convergence) 및 충돌(d) Convergence and Conflict of Replication
레졸루션의 전파Propagation of Resolution
2. 비저장 플랫폼 데이터 스토어에의 동기화2. Synchronization to non-storage platform data store
a) Sync 서비스a) Sync service
(1) 변경 열거(1) change enumeration
(2) 변경 적용(2) apply changes
(3) 충돌 레졸루션(3) collision resolution
b) 어댑터 구현b) adapter implementation
3. 보안3. Security
4. 관리능력4. Management ability
B. 동기화 API 개관B. Synchronization API Overview
1. 일반적인 용어1. General terms
2. 동기화 API 원리들2. Synchronization API Principles
C. 동기화 API 서비스들C. Synchronization API Services
1. 변경 열거1. Change enumeration
2. 변경 응용2. Change Application
3. 간단한 코드3. Simple Code
4. API 동기화의 메서드들4. Methods of API Synchronization
Ⅳ. 결론Ⅳ. conclusion
I. 도입I. Introduction
본 발명의 주제는 법정 요건들을 충족시키도록 상세하게 설명된다. 그러나, 이 설명 자체는 이 특허의 범위를 제한하도록 의도되어 있지 않다. 도리어, 발명자들은 청구된 주제가 다른 특허 또는 장래의 기술과 관련하여, 이 명세서에서 설명된 것들과 유사한 단계들의 조합 또는 상이한 단계들을 포함하도록 다른 방법들로 구현될 수도 있다는 것을 염두에 두었다. 더욱이, "단계"(step)라는 용어는 채용된 방법들의 서로 다른 요소들을 의미하도록 본 명세서에서 사용될 수 있지만, 이 용어는 개개의 단계들의 순서가 명시적으로 기술되지 않는 한 본 명세서에서 개시된 갖가지 단계들 사이의 어떤 특정 순서를 의미하는 것으로 해석되어서는 안 된다.The subject matter of the present invention is described in detail to meet statutory requirements. However, this description itself is not intended to limit the scope of this patent. Rather, the inventors have kept in mind that the claimed subject matter may be implemented in other ways to include different steps or combinations of steps similar to those described herein with respect to other patents or future technologies. Moreover, the term "step" may be used herein to mean different elements of the employed methods, although the term is used to describe various steps disclosed herein unless the order of individual steps is explicitly stated. It should not be interpreted as meaning any particular order between them.
A. 예시적인 컴퓨팅 환경A. Example Computing Environment
본 발명의 다수의 실시예들은 컴퓨터 상에서 실행될 수 있다. 도 1 및 이하의 논의는 본 발명의 구현될 수 있는 적당한 컴퓨팅 환경에 대한 간단한 일반적인 설명을 제공하도록 의도되어 있다. 필수적인 것은 아니지만, 본 발명의 갖가지 양태들은 클라이언트 워크스테이션 또는 서버와 같은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행 가능한 명령들의 일반적인 문맥에서 설명될 수 있다. 일반적으로, 프로그램 모듈들은 특정 작업을 수행하거나 또는 특정 추상(abstract) 데이터 타입들을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 또한, 본 발명은 핸드 헬드 디바이스, 멀티 프로세서 시스템, 마이크로프로세서 기반 또는 프로그램 가능한 소비자 전자 기기, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는 다른 컴퓨터 시스템 구성을 이용하여 실시될 수도 있다. 본 발명은 또한 통신 네트워크를 통하여 연결되어 있는 원격 처리 디바이스들에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서는, 프로그램 모듈들은 로컬 메모리 기억 장치 및 원격 메모리 기억 장치 양쪽 모두에 위치할 수 있다.Many embodiments of the invention may be implemented on a computer. 1 and the following discussion are intended to provide a brief general description of suitable computing environments in which the invention may be implemented. Although not required, various aspects of the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer, such as a client workstation or server. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced using other computer system configurations, including hand held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
도 1에 도시된 바와 같이, 예시적인 범용 컴퓨팅 시스템은, 처리 장치(21), 시스템 메모리(22), 및 이 시스템 메모리를 포함하는 각종 시스템 컴포넌트들을 상기 처리 장치(21)에 연결하는 시스템 버스(23)를 포함하는 종래의 퍼스널 컴퓨터(20) 또는 그와 유사한 것을 포함한다. 시스템 버스(23)는 각종 버스 아키텍처 중 어느 하나를 이용한 메모리 버스 또는 메모리 컨트롤러, 주변 버스, 및 로컬 버스를 포함하는 몇몇 타입의 버스 구조들 중 어느 하나일 수 있다. 시스템 메모리는 판독 전용 메모리(ROM)(24) 및 랜덤 액세스 메모리(RAM)(25)를 포함한다. 시동(start-up) 중과 같이 퍼스널 컴퓨터(20) 내의 엘리먼트들 간의 정보 전송을 돕는 기본 루틴들을 포함하는 기본 입출력 시스템(BIOS)(26)은 ROM(24)에 저장된다. 퍼스널 컴퓨터(20)는 또한 도시되지 않은 하드 디스크로부터 판독하고 거기에 기록하기 위한 하드 디스크 드라이브(27), 탈착 가능한 자기 디스크(29)로부터 판독하거나 거기에 기록하기 위한 자기 디스크 드라이브(28), 및 CD ROM 또는 다른 광학 매체와 같은 탈착 가능한 광 디스크(31)로부터 판독하거나 거기에 기록하기 위한 광 디스크 드라이브(30)를 포함할 수 있다. 하드 디스크 드라이브(27), 자기 디스크 드라이브(28), 및 광 디스크 드라이브(30)는 각각 하드 디스크 드라이브 인터페이스(32), 자기 디스크 드라이브 인터페이스(33), 및 광 디스크 드라이브 인터페이스(34)에 의해 시스템 버스(23)에 접속된다. 이 드라이브들과 그들의 관련 컴퓨터 판독 가능 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 및 퍼스널 컴퓨터(20)용의 다른 데이터의 불휘발성 저장을 제공한다. 여기에서 설명된 예시적 환경은 하드 디스크, 탈착 가능한 자기 디스크(29), 및 탈착 가능한 광 디스크(31)를 채용하지만, 숙련된 당업자라면 자기 카세트, 플래시 메모리 카드, 디지털 비디오 디스크, 베르누이 카트리지, 랜덤 액세스 메모리(RAMs), 판독 전용 메모리(ROMs) 등과 같이, 컴퓨터에 의해 액세스 가능한 데이터를 저장할 수 있는 다른 타입의 컴퓨터 판독 매체도 또한 이 예시적인 운영 환경에서 사용될 수 있다는 것을 알 것이다. 마찬가지로, 이 예시적인 환경은 또한 열 센서 및 보안 또는 화재 경보 시스템과 같은 여러 타입의 모니터링 디바이스, 및 다른 정보 소스를 포함할 수도 있다.As shown in FIG. 1, an exemplary general-purpose computing system includes a system bus that connects a
하드 디스크, 자기 디스크(29), 광 디스크(31), ROM(24) 또는 RAM(25) 상에는, 운영 시스템(35), 하나 이상의 애플리케이션 프로그램(36), 다른 프로그램 모듈들(37) 및 프로그램 데이터(38)를 포함하는, 다수의 프로그램 모듈들이 저장될 수 있다. 사용자는 키보드(40) 및 포인팅 디바이스(42)와 같은 입력 디바이스들을 통하여 퍼스널 컴퓨터(20)에 커맨드 및 정보를 입력할 수 있다. (도시되지 않은) 다른 입력 디바이스들은 마이크, 조이스틱, 게임 패드, 위성 디스크(satellite disk), 스캐너 또는 그와 유사한 것을 포함할 수 있다. 이들 및 다른 입력 디바이스들은 흔히 시스템 버스에 연결되어 있는 직렬 포트 인터페이스(46)를 통하여 처리 장치(21)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 버스(USB)와 같은 다른 인터페이스들에 의해 접속될 수도 있다. 모니터(47) 또는 다른 타입의 디스플레이 디바이스도 비디오 어댑터(48)와 같은 인터페이스를 통하여 시스템 버스(23)에 접속된다. 모니터(47) 이외에, 퍼스널 컴퓨터는 일반적으로 스피커 및 프린터와 같은 (도시되지 않은) 다른 주변 출력 디바이스들을 포함한다. 도 1의 예시적인 시스템은 또한 호스트 어댑터(55), 소형 컴퓨터 시스템 인터페이스(SCSI) 버스(56), 및 SCSI 버스(56)에 접속된 외부 기억 장치(62)를 포함한다.On hard disk,
퍼스널 컴퓨터(20)는 원격 컴퓨터(49)와 같은 하나 이상의 원격 컴퓨터들에의 논리적 접속을 이용한 네트워크 환경에서 동작할 수도 있다. 원격 컴퓨터(49)는 또 다른 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스(peer device) 또는 다른 공통의 네트워크 노드일 수 있고, 도 1에는 메모리 기억 디바이스(50)만이 예시되어 있지만, 일반적으로 퍼스널 컴퓨터(20)와 관련하여 상술한 엘리먼트들 중의 다수 또는 전부를 포함한다. 도 1에 도시된 논리적 접속은 근거리 통신망(LAN)(51) 및 광역 통신망(WAN)(52)를 포함한다. 그러한 네트워킹 환경들은 사무실, 기업 광역(enterprise wide) 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.
LAN 네트워크 환경에서 사용될 때, 퍼스널 컴퓨터(20)는 네트워크 인터페이스 또는 어댑터(53)를 통하여 LAN(51)에 접속된다. WAN 네트워크 환경에서 사용될 때, 퍼스널 컴퓨터(20)는 일반적으로 모뎀(54)이나 또는 인터넷과 같은 광역 통신망(52)을 통하여 통신을 설정하기 위한 다른 수단을 포함한다. 내장형이거나 또는 외장형일 수 있는 모뎀(54)은 직렬 포트 인터페이스(46)를 통하여 시스템 버스(23)에 접속된다. 네트워킹크 환경에서, 퍼스널 컴퓨터(20)와 관련하여 도시된 프로그램 모듈들, 또는 그것들의 일부는, 원격 메모리 기억 장치에 저장될 수 있다. 도시된 네트워크 접속들은 예시적인 것이고 컴퓨터들 간에 통신 링크를 설정하는 다른 수단이 사용될 수도 있다는 것을 알 것이다.When used in a LAN network environment, the
도 2의 블록도에 예시된 바와 같이, 컴퓨터 시스템(200)은 대략 3개의 컴포넌트 그룹: 하드웨어 컴포넌트(202), 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204), 및 애플리케이션 프로그램 컴포넌트(206)(본 명세서의 특정한 상황에서 "사용자 컴포넌트" 또는 "소프트웨어 컴포넌트"라고도 함)로 나누어질 수 있다.As illustrated in the block diagram of FIG. 2,
컴퓨터 시스템(200)의 갖가지 실시예들에서, 그리고 다시 도 1을 참조하면, 하드웨어 컴포넌트(202)는 중앙 처리 장치(CPU)(21), 메모리(ROM(24) 및 ROM(25) 양쪽 모두), 기본 입출력 시스템(BIOS)(26), 및 특히 키보드(40), 마우스(42), 모니터(47), 및/또는 (도시되지 않은) 프린터와 같은 각종 입출력(I/O) 디바이스들을 포함할 수 있다. 하드웨어 컴포넌트(202)는 컴퓨터 시스템(200)에 대한 기본적인 물리적 인프라구조(infrastructure)를 포함한다.In various embodiments of
애플리케이션 프로그램 컴포넌트(206)는 컴파일러, 데이터베이스 시스템, 워드 프로세서, 사무용 프로그램, 비디오 게임 등을 포함하면서도 이들에 한정되지 않는 다양한 소프트웨어 프로그램들을 포함한다. 애플리케이션 프로그램은 다양한 사용자들(머신, 다른 컴퓨터 시스템, 및/또는 최종 사용자)을 위해 문제를 해결하고, 해법을 제공하고, 데이터를 처리하기 위해 컴퓨터 자원들(computer resources)이 이용되도록 하는 수단을 제공한다.The
하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204)는 대개의 경우에, 그것 자체가 셸(shell) 및 커널(kernel)을 포함하는 운영 시스템을 포함한다(그리고, 일부 실시예에서는, 단지 그것만으로 이루어질 수 있다). "운영 시스템"(OS: operarating system)은 애플리케이션 프로그램들과 컴퓨터 하드웨어 간의 매개자의 역할을 하는 특별한 프로그램이다. 하드웨어/소프트웨어 인터페이스 시스템 컴포넌트(204)는 또한 컴퓨터 시스템 내의 운영 시스템 대신에 또는 그것에 더하여, 가상 머신 관리자(VMM: virtual machine manager), 공통 언어 런타임(CLR: Common Language Runtime) 또는 그것의 기능적 등가물, 자바 가상 머신(JVM : Java Virtual Machine) 또는 그것의 기능적 등가물, 또는 다른 그러한 소프트웨어 컴포넌트들을 포함할 수 있다. 하드웨어/소프트웨어 인터페이스 시스템의 용도는 사용자가 애플리케이션 프로그램들을 실행할 수 있는 환경을 제공하는 것이다. 임의의 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 하드웨어를 효율적으로 이용할 뿐만 아니라, 컴퓨터 시스템을 사용하기 편리하게 하는 것이다.Hardware / software
하드웨어/소프트웨어 인터페이스 시스템은 일반적으로 시동 시에 컴퓨터 시스템에 로드되고 그 후에 컴퓨터 시스템 내의 모든 애플리케이션 프로그램들을 관리한다. 애플리케이션 프로그램들은 애플리케이션 프로그램 인터페이스(API)를 통하여 서비스를 요구함으로써 하드웨어/소프트웨어 인터페이스 시스템과 상호 작용한다. 어떤 애플리케이션 프로그램들은 최종 사용자들이 커맨드 언어 또는 그래픽 사용자 인터페이스(GUI)와 같은 사용자 인터페이스를 통하여 하드웨어/소프트웨어 인터페이스 시스템과 상호 작용할 수 있게 한다.The hardware / software interface system is generally loaded into the computer system at startup and then manages all application programs within the computer system. Application programs interact with a hardware / software interface system by requesting services through an application program interface (API). Some application programs allow end users to interact with a hardware / software interface system through a user interface, such as a command language or graphical user interface (GUI).
하드웨어/소프트웨어 인터페이스 시스템은 전통적으로 애플리케이션들에 대한 각종 서비스를 수행한다. 다수의 프로그램들이 동시에 실행될 수 있는 멀티태스킹 하드웨어/소프트웨어 인터페이스 시스템에서는, 하드웨어/소프트웨어 인터페이스 시스템은 어느 애플리케이션들이 어떤 순서로 실행되어야 하는지 및 전환을 위해 다른 애플리케이션으로 스위칭하기 전에 각각의 애플리케이션에 대해 얼마나 많은 시간이 할당되어야 하는지를 결정한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 다수의 애플리케이션들 사이에서의 내부 메모리의 공유를 관리하고, 하드 디스크, 프린터, 및 다이얼업 포트(dial-up ports)와 같은 부착된 하드웨어 디바이스들로의 입력 및 그들로부터의 출력을 처리한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 동작 상태 및 발생했을지도 모르는 에러들에 관한 메시지를 각각의 애플리케이션에게(및, 어떤 경우에는, 최종 사용자에게) 송신한다. 하드웨어/소프트웨어 인터페이스 시스템은 또한 일괄 작업(예를 들면, 인쇄)의 관리를 오프로드(offload)함으로써 개시 애플리케이션(initiating application)이 이 작업으로부터 해방되어 다른 처리 및/또는 동작을 재개할 수 있도록 할 수 있다. 병렬 처리를 제공할 수 있는 컴퓨터들에서는, 하드웨어/소프트웨어 인터페이스 시스템은 또한 프로그램이 2 이상의 프로세서 상에서 동시에 실행되도록 그 프로그램의 분할을 관리한다.Hardware / software interface systems traditionally perform various services for applications. In a multitasking hardware / software interface system in which multiple programs can run simultaneously, the hardware / software interface system determines which applications should run in what order and how much time for each application before switching to another application for conversion. Determine if this should be allocated. The hardware / software interface system also manages the sharing of internal memory among multiple applications, and inputs to and from attached hardware devices such as hard disks, printers, and dial-up ports. Process the output of The hardware / software interface system also sends a message to each application (and, in some cases, to the end user) about an operational state and errors that may have occurred. The hardware / software interface system can also offload the management of batch jobs (eg, printing) so that the initiating application can be freed from this job and resume other processing and / or operations. have. In computers that can provide parallel processing, the hardware / software interface system also manages the division of the program so that the program runs on two or more processors simultaneously.
하드웨어/소프트웨어 인터페이스 시스템 셸(여기에서는 간단히 "셸"이라고 함)은 하드웨어/소프트웨어 인터페이스 시스템에 대한 대화형 최종 사용자 인터페이스이다. (셸은 또한 "커맨드 번역기"(command interpreter)라고도 하고, 운영 시스템에서는, "운영 시스템 셸"(operating system shell)이라고도 한다). 셸은 애플리케이션 프로그램들 및/또는 최종 사용자들에 의해 직접 액세스 가능한 하드웨어/소프트웨어 인터페이스 시스템의 외부층이다. 셸과는 대조적으로, 커널은 하드웨어 컴포넌트들과 직접 상호 작용하는 하드웨어/소프트웨어 인터페이스 시스템의 가장 안쪽 층이다.The hardware / software interface system shell (hereafter simply referred to as the "shell") is an interactive end user interface to the hardware / software interface system. (Shells are also called "command interpreters," and in operating systems, they are also called "operating system shells.") The shell is the outer layer of the hardware / software interface system that is directly accessible by application programs and / or end users. In contrast to the shell, the kernel is the innermost layer of the hardware / software interface system that interacts directly with the hardware components.
본 발명의 다수의 실시예들은 컴퓨터화된 시스템들에 특히 적합한 것으로 생각되지만, 이 명세서 내의 어떤 것도 본 발명을 그러한 실시예들에 한정하도록 의도되어 있지 않다. 그에 반하여, 여기에서 사용된 "컴퓨터 시스템"이라는 용어는 정보를 저장하고 처리할 수 있고 저장된 정보를 이용하여, 해당 디바이스가 본질상 전자적이든, 기계적이든, 논리적이든, 또는 가상적이든 상관없이, 디바이스 자체의 비헤이비어 또는 실행을 제어할 수 있는 임의의 및 모든 디바이스들을 두루 포함하도록 의도되어 있다.While many embodiments of the invention are deemed particularly suitable for computerized systems, nothing in this specification is intended to limit the invention to those embodiments. In contrast, the term “computer system” as used herein may store and process information and, using the stored information, whether the device is inherently electronic, mechanical, logical, or virtual, the device itself. It is intended to include any and all devices capable of controlling the behavior or execution of a.
B. 전통적인 파일 기반 저장B. Traditional File Based Storage
오늘날 대부분의 컴퓨터 시스템에서, "파일"(files)은 애플리케이션 프로그램, 데이터 세트 등은 물론 하드웨어/소프트웨어 인터페이스 시스템을 포함할 수 있는 저장 가능한 정보 단위이다. 모든 최신의 하드웨어/소프트웨어 인터페이스 시스템(Windows, Unix, Linux, Mac OS, 가상 머신 시스템 등)에서, 파일은 하드웨어/소프트웨어 인터페이스 시스템에 의해 조작 처리될 수 있는 기본적인 개별 (저장 가능하고 검색 가능한) 정보 단위(예를 들면, 데이터, 프로그램 등)이다. 파일 그룹들은 일반적으로 "폴더"(folders)로 조직된다. 마이크로소프트 윈도즈, 매킨토시 OS, 및 다른 하드웨어/소프트웨어 인터페이스 시스템에서, 폴더는 하나의 정보 단위로서 검색되고, 이동되고, 다르게는 조작 처리될 수 있는 파일들의 컬렉션이다. 이 폴더들은 다시 (아래에서 더 상세히 논의되는) "디렉토리"(directory)라고 하는 트리 기반 계층 구성 배열로 조직된다. DOS, z/OS 및 대부분의 Unix 기반 운영 시스템과 같은, 어떤 다른 하드웨어/소프트웨어 인터페이스 시스템들에서는, "디렉토리" 및/또는 "폴더"라는 용어들이 상호 교환 가능하고, 초기 애플 컴퓨터 시스템들(예를 들면, Apple Ⅱe)은 디렉토리 대신에 "카탈로그"(catalog)라는 용어를 사용하였지만, 여기에서 사용될 때 모든 이들 용어들은 같은 의미이고 상호 교환 가능한 것으로 생각되고 계층형 정보 저장 구조들 및 그들의 폴더 및 파일 컴포넌트들에 대한 모든 다른 동등한 용어들 및 참조들을 더 포함하도록 의도되어 있다.In most computer systems today, "files" are storage units of information that may include application programs, data sets, etc., as well as hardware / software interface systems. In all modern hardware / software interface systems (Windows, Unix, Linux, Mac OS, virtual machine systems, etc.), files are basic, individual (storable and searchable) units of information that can be manipulated by hardware / software interface systems. (E.g., data, programs, etc.). File groups are typically organized into "folders". In Microsoft Windows, Macintosh OS, and other hardware / software interface systems, a folder is a collection of files that can be retrieved, moved, and otherwise manipulated as a unit of information. These folders are again organized into a tree-based hierarchical arrangement called a "directory" (discussed in more detail below). In some other hardware / software interface systems, such as DOS, z / OS, and most Unix-based operating systems, the terms "directory" and / or "folder" are interchangeable, and early Apple computer systems (eg For example, Apple IIe used the term "catalog" instead of a directory, but when used herein all these terms are considered to be synonymous and interchangeable, and hierarchical information storage structures and their folder and file components. It is intended to further include all other equivalent terms and references to these.
전통적으로, 디렉토리(폴더들의 디렉토리(directory of folders)라고도 알려져 있음)는, 파일들이 폴더들로 그룹화되고 폴더는 다시 디렉토리 트리를 포함하는 상대적 노드 위치(relative nodal locations)에 따라서 배열되어 있는 트리 기반 계층형 구조이다. 예를 들면, 도 2A에 예시된 바와 같이, DOS 기반 파일 시스템 베이스 폴더("루트 디렉토리")(212)는 복수의 폴더(214)를 포함할 수 있고, 이 폴더들 각각은 또한 (그 특정 폴더의 "하위 폴더들"로서) 부가적인 폴더들(216)을 포함할 수 있고, 이것들 각각은 또한 부가적인 폴더들(218)을 무한히 포함할 수 있다. 이들 폴더들 각각은 하나 이상의 파일들(220)을 가질 수 있지만, 하드웨어/소프트웨어 인터페이스 시스템 레벨에서, 폴더 내의 개개의 파일들은 트리 계층 구성에서의 그들의 위치 이외에 아무 것도 공통으로 갖지 않는다. 파일들을 폴더 계층 구성들로 조직하는 이러한 방법은 이들 파일들을 저장하기 위해 사용되는 전형적인 저장 매체(예를 들면, 하드 디스크, 플로피 디스크, CD-ROM 등)의 물리적 조직을 간접적으로 반영한다는 것은 놀라운 일이 아니다.Traditionally, a directory (also known as a directory of folders) is a tree-based hierarchy in which files are grouped into folders and folders are arranged according to relative nodal locations, which in turn contain a directory tree. Mold structure. For example, as illustrated in FIG. 2A, the DOS-based file system base folder (“root directory”) 212 may include a plurality of
전술한 것들 외에, 각각의 폴더는 그것의 하위 폴더 및 그것의 파일들에 대한 컨테이너이다. 즉, 각각의 폴더는 그것의 하위 폴더들 및 파일들을 소유한다. 예를 들면, 폴더가 하드웨어/소프트웨어 인터페이스 시스템에 의해 삭제되는 경우, 그 폴더의 하위 폴더들 및 파일들도 또한 삭제된다(각각의 하위 폴더의 경우에는, 그 자신의 하위 폴더들 및 파일들을 반복적으로 더 포함한다). 마찬가지로, 각각의 파일은 일반적으로 오직 하나의 폴더에 의해서만 소유되며, 파일은 복사될 수 있고 그 복사본은 상이한 폴더에 위치할 수 있지만, 파일의 복사본 자체는 원본과 직접적인 관계가 없는 별개의 분리된 단위이다(예를 들면, 원본 파일에 대한 변경은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 복사본 파일에 반영되지 않는다). 따라서, 이와 관련하여, 파일들 및 폴더들은 본질상 특징적으로 "물리적"이다. 왜냐하면, 폴더들은 물리적 컨테이너처럼 취급되고, 파일들은 이들 컨테이너 내의 별개의 분리된 물리적 엘리먼트들로서 취급되기 때문이다.In addition to the above, each folder is a container for its subfolders and their files. That is, each folder owns its subfolders and files. For example, if a folder is deleted by the hardware / software interface system, the subfolders and files of that folder are also deleted (in the case of each subfolder, iteratively repeats its own subfolders and files). More). Similarly, each file is typically owned only by one folder, the file can be copied and its copy can be located in a different folder, but the copy of the file itself is a separate discrete unit that is not directly related to the original. (Eg, changes to the original file are not reflected in the copy file at the hardware / software interface system level). Thus, in this regard, files and folders are inherently "physical" in nature. This is because folders are treated like physical containers, and files are treated as separate, separate physical elements within these containers.
Ⅱ. 데이터를 조직, 검색, 및 공유하기 위한 WINFS 저장 플랫폼II. WINFS storage platform for organizing, searching, and sharing data
본 발명은, 본 명세서의 앞에서 논의된 바와 같이 참고로 반영된 관련 발명들과 조합하여, 데이터를 조직하고, 검색하고, 공유하기 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 위에서 논의된 기존의 파일 시스템 및 데이터베이스 시스템을 넘어서 데이터 플랫폼을 확장하고 넓히며, 아이템이라고 불리는 새로운 형태의 데이터를 포함하는 모든 타입의 데이터에 대한 스토어가 되도록 설계되어 있다.The present invention relates to a storage platform for organizing, retrieving, and sharing data in combination with related inventions incorporated by reference as discussed previously herein. The storage platform of the present invention is designed to extend and widen the data platform beyond the existing file and database systems discussed above, and to be a store for all types of data, including new types of data called items.
A. 용어 모음A. Glossary
본 명세서 및 청구항들에서 사용될 때, 이하의 용어들은 이하의 의미를 갖는다:As used in this specification and claims, the following terms have the following meanings:
B. 저장 플랫폼 개관B. Storage Platform Overview
도 3을 참조하면, 저장 플랫폼(300)은 데이터베이스 엔진(314) 상에 구현된 데이터 스토어(302)를 포함한다. 일 실시예에서, 데이터베이스 엔진은 객체 관계 확장들(object relational extensions)을 갖는 관계 데이터베이스 엔진을 포함한다. 일 실시예에서, 관계 데이터베이스 엔진(314)은 마이크로소프트 SQL 서버 관계 데이터베이스 엔진을 포함한다. 데이터 스토어(302)는 데이터의 조직, 검색, 공유, 동기화, 및 보안을 지원하는 데이터 모델(304)을 구현한다. 데이터의 특정 타입들은 스키마(340)와 같은 스키마들에서 기술되고, 저장 플랫폼(300)은 아래에서 더 상세히 설명되는 바와 같이 그 스키마들을 확장할 뿐만 아니라 그 스키마들을 전개(deploy)하기 위한 도구들(346)을 제공한다.Referring to FIG. 3,
데이터 스토어(302) 내에서 구현되는 변경 추적 메커니즘(306)은 데이터 스토어에 대한 변경들을 추적하는 능력을 제공한다. 데이터 스토어(302)는 또한 보안 능력들(308) 및 프로모션/디모션(promotion/demotion) 능력(310)을 제공하고, 이 양자에 대해서는 아래에서 더 상세히 논의된다. 데이터 스토어(302)는 또한 데이터 스토어(302)의 능력들을 저장 플랫폼을 이용하는 애플리케이션 프로그램들(예를 들면, 애플리케이션 프로그램들(350a, 350b, 및 350c)) 및 다른 저장 플랫폼 컴포넌트들에게 노출시키기 위한 애플리케이션 프로그래밍 인터페이스들(312)의 세트를 제공한다. 본 발명의 저장 플랫폼은 또한 애플리케이션 프로그램들(350a, 350b, 및 350c)과 같은 애플리케이션 프로그램들이 저장 플랫폼의 전술한 능력들 모두에 액세스하고 스키마들에서 기술된 데이터에 액세스할 수 있게 하는 애플리케이션 프로그램 인터페이스들(API)(322)을 더 포함한다. 저장 플랫폼 API(322)는 OLE DB API(324) 및 마이크로소프트 윈도즈 Win32 API(326)와 같은 다른 API들과 조합하여 애플리케이션 프로그램들에 의해 사용될 수 있다.The
본 발명의 저장 플랫폼(300)은 사용자들 또는 시스템들 사이에서의 데이터의 공유를 용이하게 하는 동기화 서비스(330)를 포함하는 갖가지 서비스들(328)을 애플리케이션 프로그램들에게 제공할 수 있다. 예를 들면, 동기화 서비스(330)는 다른 포맷들을 갖는 데이터 스토어들(342)에의 액세스뿐만 아니라, 데이터 스토어(302)와 동일한 포맷을 갖는 다른 데이터 스토어들(340)과의 상호 운용성을 가능케 할 수 있다. 저장 플랫폼(300)은 또한 윈도즈 NTFS 파일 시스템(318)과 같은 기존의 파일 시스템과의 데이터 스토어(302)의 상호 운용성을 허용하는 파일 시스템 능력을 제공한다. 적어도 일부 실시예들에서, 저장 플랫폼(320)은 또한 데이터에 작용될 수 있고 다른 시스템들과의 상호 작용을 가능케 하는 부가적인 능력들을 애플리케이션 프로그램들에게 제공할 수 있다. 이들 능력들은 정보 에이전트(Info Agent) 서비스(334) 및 통지 서비스(332)와 같은 부가적인 서비스(328)의 형태로는 물론, 다른 유틸리티(336)의 형태로도 구현될 수 있다.The
적어도 일부 실시예들에서, 저장 플랫폼은 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템 내에 구현되거나, 또는 그것의 필수적인 부분을 형성한다. 예를 들면, 그리고 제한 없이, 본 발명의 저장 플랫폼은 운영 시스템, 가상 머신 관리자(VMM), 공통 언어 런타임(CLR) 또는 그것의 기능적 등가물, 자바 가상 머신(JVM) 또는 그것의 기능적 등가물 내에 구현되거나, 또는 그것의 필수적인 부분을 형성할 수 있다. 본 발명의 저장 플랫폼은, 그것의 공통의 저장 토대(storage foundation) 및 조직적으로 배열된 데이터(schematized data)를 통하여, 소비자, 지식 노동자 및 기업에게 보다 효율적인 애플리케이션 개발을 가능케 한다. 그것은 그것의 데이터 모델에서의 고유한 능력들을 이용할 수 있게 할 뿐만 아니라, 기존의 파일 시스템 및 데이터베이스 액세스 방법들을 포용하고 확장하는 풍부하고 확장성이 있는 애플리케이션 프로그래밍 표면적을 제공한다.In at least some embodiments, the storage platform is implemented within, or forms an integral part of, the hardware / software interface system of the computer system. For example, and without limitation, the storage platform of the present invention may be implemented within an operating system, a virtual machine manager (VMM), a common language runtime (CLR) or a functional equivalent thereof, a Java virtual machine (JVM) or a functional equivalent thereof, or Or an integral part thereof. The storage platform of the present invention, through its common storage foundation and organized data, enables more efficient application development for consumers, knowledge workers and enterprises. It not only makes use of the capabilities inherent in its data model, but also provides a rich and scalable application programming surface area that embraces and extends existing file system and database access methods.
이하의 설명에서, 및 여러 도면들에서, 본 발명의 저장 플랫폼(300)은 "WinFS"로 불릴 수 있다. 그러나, 저장 플랫폼을 언급하기 위해 이러한 이름을 사용하는 것은 오로지 설명의 편의를 위한 것일 뿐 결코 제한하려는 것이 아니다.In the following description, and in the various figures, the
C. 데이터 모델C. Data Model
본 발명의 저장 플랫폼(300)의 데이터 스토어(302)는 스토어 내에 상주하는 데이터의 조직, 검색, 공유, 동기화, 및 보안을 지원하는 데이터 모델을 구현한다. 본 발명의 데이터 모델에서, "아이템"은 저장 정보의 기본적인 단위이다. 데이터 모델은 아이템 및 아이템 확장을 선언하고 아이템들 간의 관계를 설정하고 아이템 폴더 및 카테고리 내의 아이템들을 조직하기 위한 메커니즘을 제공하는데, 이에 대해서는 아래에서 더 상세히 설명한다.The
데이터 모델은 2개의 기본 메커니즘, 타입(Types) 및 관계(Relationships)에 의존한다. 타입은 타입의 인스턴스의 형태를 제어하는 포맷을 제공하는 구조이다. 포맷은 속성들의 순서화된 세트로서 표현된다. 속성(Property)은 주어진 타입의 값 또는 값들의 세트에 대한 이름이다. 예를 들면 USPostalAddress 타입은 Street(가), City(시), Zip(우편번호), State(주) 속성들을 갖고, 여기에서 Street, City 및 State는 String(문자열) 타입이고, Zip은 Int32 타입이다. Street는 다중 값(즉, 값들의 세트)일 수 있고 따라서 주소가 Street 속성에 대해 2 이상의 값을 갖도록 허용한다. 시스템은 다른 타입들의 구성에 이용될 수 있는 특정 기본 타입들(primitive types)을 정의한다 - 이들은 String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal 및 GUID를 포함한다. 타입의 속성들은 기본 타입들 중 임의의 것 또는 (아래에서 지적된 얼마간의 제한을 갖고) 구성된 타입들 중 임의의 것을 이용하여 정의될 수 있다. 예를 들면 Coordinate 및 Address 속성들을 가진 Location 타입이 정의될 수 있고, 여기에서 Address 속성은 상술한 바와 같이 USPostalAddress 타입이다. 속성들은 또한 필수 사양이거나 선택 사양일 수 있다.The data model relies on two basic mechanisms, Types, and Relationships. Types are structures that provide a format that controls the type of instances of a type. The format is represented as an ordered set of attributes. Property is the name of a value or set of values of a given type. For example, the USPostalAddress type has properties Street, City, Zip, and State, where Street, City, and State are of type String, and Zip is of type Int32. . Street can be multiple values (ie, a set of values), thus allowing an address to have more than one value for the Street attribute. The system defines certain primitive types that can be used to construct other types-these include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal and GUID. . Attributes of a type can be defined using any of the base types or any of the constructed types (with some limitations noted below). For example, a Location type with Coordinate and Address attributes can be defined, where the Address attribute is of type USPostalAddress as described above. Attributes may also be required or optional.
관계(Relationships)는 선언될 수 있고 2개의 타입의 인스턴스들의 세트들 간의 매핑을 나타낸다. 예를 들면 어느 사람들이 어느 장소들에 사는지를 정의하는 Person(사람) 타입과 Location(장소) 타입 간에 선언된 LivesAt이라고 불리는 관계가 있을 수 있다. 관계는 이름과, 2개의 종점(endpoints), 즉 소스 종점 및 타깃 종점을 갖는다. 관계는 또한 속성들의 순서화된 세트를 가질 수 있다. 소스 및 타깃 종점들 모두는 이름 및 타입을 가질 수 있다. 예를 들면 LiveAt 관계는 Person 타입의 Occupant(거주자)라고 불리는 소스와 Location 타입의 Dwelling(거주지)라고 불리는 타깃을 갖고 또한 거주자가 거주지에 살았던 기간을 나타내는 StartDate(시작 날짜) 및 EndDate(종료 날짜) 속성들을 갖는다. 사람은 시간에 따라 다수의 거주지에 살 수 있고 거주지는 다수의 거주자를 가질 수 있으므로 StartDate 및 EndDate 정보를 가장 많이 넣을 것 같은 장소는 관계 자체 상일 것이다.Relationships can be declared and represent a mapping between sets of instances of two types. For example, there may be a relationship called LivesAt that is declared between the Person type and the Location type that define which people live in which places. The relationship has a name and two endpoints, a source endpoint and a target endpoint. A relationship can also have an ordered set of attributes. Both source and target endpoints can have a name and type. For example, the LiveAt relationship has a source called Occupant of type Person and a target called Dwelling of type Location, and also has a StartDate and EndDate attribute indicating how long the tenant has lived in the residence. Have them. People can live in multiple dwellings over time and dwellings can have multiple dwellers, so the place most likely to put the StartDate and EndDate information would be in the relationship itself.
관계는 종점 타입으로서 주어진 타입에 의해 구속되는 인스턴스들 간의 매핑을 정의한다. 예를 들면, LivesAt 관계는 자동차가 거주자인 관계가 될 수 없다. 왜냐하면 자동차는 사람이 아니기 때문이다.A relationship is an endpoint type that defines a mapping between instances bound by a given type. For example, a LivesAt relationship cannot be a car resident relationship. Because cars are not humans.
데이터 모델은 타입들 간의 서브타입-슈퍼타입 관계의 정의를 허용한다. BaseType 관계로도 알려져 있는 서브타입-슈퍼타입 관계는 타입 A가 타입 B에 대한 BaseType이면 그것은 B의 모든 인스턴스가 또한 A의 인스턴스인 경우이어야 한다라는 식으로 정의된다. 이것을 표현하는 다른 방법은 B에 따르는 모든 인스턴스는 A에 따라야 한다는 것이다. 만일, 예를 들어 A가 String(문자열) 타입의 Name(이름) 속성을 갖는 반면에 B는 Int16 타입의 Age(나이) 속성을 갖는다면, B의 임의의 인스턴스는 이름과 나이 양쪽 모두를 가져야 한다. 타입 계층 구성은 루트에 단 하나의 슈퍼타입을 갖는 트리로서 파악될 수 있다. 루트로부터의 브랜치들(branches)은 제1 레벨 서브타입들을 제공하고, 이 레벨에서의 브랜치들은 제2 레벨 서브타입들을 제공하는 등등으로 그들 자신이 어떠한 서브타입도 갖고 있지 않은 가장 먼 리프(leaf-most) 서브타입들까지 진행된다. 트리는 균일한 깊이가 되도록 구속되지 않지만 어떠한 사이클도 포함할 수 없다. 주어진 타입은 0 또는 다수의 서브타입들과 0 또는 하나의 슈퍼타입을 가질 수 있다. 주어진 인스턴스는 기껏해야 하나의 타입과 그 타입의 슈퍼타입들에 따를 수 있다. 바꾸어 말하면, 트리 내의 임의의 레벨에서의 주어진 인스턴스에 있어서 그 인스턴스는 그 레벨에서 기껏해야 하나의 서브타입에 따를 수 있다. 타입의 인스턴스들이 또한 그 타입의 서브타입의 인스턴스가 되어야 한다면 그 타입은 Abstract라고 한다.The data model allows the definition of subtype-supertype relationships between types. A subtype-supertype relationship, also known as a BaseType relationship, is defined such that if type A is a BaseType for type B, it must be the case that all instances of B are also instances of A. Another way to express this is that every instance following B must follow A. For example, if A has a Name attribute of type String while B has an Age attribute of type Int16, then any instance of B must have both a name and an age. . The type hierarchy can be thought of as a tree with only one supertype at the root. Branches from the root provide first-level subtypes, branches at this level provide second-level subtypes, and so on, with the furthest leaf- in which they do not have any subtypes themselves. most) up to subtypes. The tree is not constrained to be of uniform depth but can contain no cycles. A given type can have zero or multiple subtypes and zero or one supertype. A given instance can conform to at most one type and its supertypes. In other words, for a given instance at any level in the tree, that instance can follow at most one subtype at that level. If instances of a type must also be instances of subtypes of that type, the type is called Abstract.
1. 아이템1. Item
아이템은 간단한 파일과 달리, 저장 플랫폼에 의해 최종 사용자 또는 애플리케이션 프로그램에게 노출되는 모든 객체들에 걸쳐서 공통으로 지원되는 속성들의 기본 세트를 갖는 객체인, 저장 가능한 정보의 단위이다. 아이템은 또한 아래에서 논의되는 바와 같이, 새로운 속성들 및 관계들이 도입될 수 있게 하는 특징들을 포함하는 모든 아이템 타입들에 걸쳐서 공통으로 지원되는 속성들 및 관계들을 갖는다.An item is a unit of storeable information that, unlike a simple file, is an object with a basic set of attributes that is commonly supported across all objects exposed to the end user or application program by the storage platform. An item also has properties and relationships that are commonly supported across all item types, including features that allow new properties and relationships to be introduced, as discussed below.
아이템들은 복사, 삭제, 이동, 열기, 인쇄, 백업, 복원, 복제 등과 같은 통상의 동작들을 위한 객체들이다. 아이템들은 저장되고 검색될 수 있는 단위들이고 저장 플랫폼에 의해 조작 처리되는 모든 형태의 저장 가능한 정보는 아이템, 아이템의 속성, 또는 아이템들 간의 관계로서 존재하고, 이들 각각에 대해서는 아래에서 더 상세히 논의된다.Items are objects for common operations such as copy, delete, move, open, print, backup, restore, duplicate, and the like. Items are units that can be stored and retrieved and all forms of storeable information manipulated by the storage platform exist as items, attributes of items, or relationships between items, each of which is discussed in more detail below.
아이템들은 콘택트(Contacts), 사람, 서비스, 장소, (모든 각종의) 문서 등과 같이 데이터의 실재 세계의 쉽게 이해할 수 있는 단위들을 나타내기 위한 것이다. 도 5A는 아이템의 구조를 예시하는 블록도이다. 아이템의 부적당한 이름은 "Location"이다. 아이템의 적당한 이름은 "Core.Location"이고 이것은 이 아이템 구조가 코어 스키마(Core Schema) 내의 특정 타입의 아이템으로서 정의되는 것을 나타낸다. (코어 스키마에 대해서는 나중에 더 상세히 논의된다.)Items are meant to represent easily understandable units of the real world of data, such as contacts, people, services, places, (all sorts of) documents, and the like. 5A is a block diagram illustrating the structure of an item. The inappropriate name of the item is "Location". The proper name of the item is "Core. Location", which indicates that this item structure is defined as an item of a particular type in the core schema. (The core schema is discussed in more detail later.)
Location 아이템은 EAddresses, MetropolitanRegion, Neighborhood, 및 PostalAddress를 포함하는 복수의 속성들을 갖는다. 각각에 대한 속성의 특정 타입은 속성 이름의 바로 다음에 표시되고 콜론(":")에 의해 속성 이름과 분리된다. 타입 이름의 우측에는, 해당 속성 타입에 대해 허용된 값들의 수가 각괄호들("[]") 사이에 표시되고 콜론(":") 우측의 별표("*")는 불특정된 및/또는 무제한의 수("다수")를 나타낸다. 콜론 우측의 "1"는 기껏해야 하나의 값이 있을 수 있음을 나타낸다. 콜론 좌측의 "0"은 속성이 선택 사양임을(전혀 값이 없을 수 있음을) 나타낸다. 콜론 좌측의 "1"은 적어도 하나의 값이 있어야 함을(속성이 요구됨을) 나타낸다. Neighborhood 및 MetropolitanRegion은 둘 다 미리 정의된 데이터 타입이거나 "단순 타입"(simple type)(여기에서는 대문자를 사용하지 않고서 표시됨)인 "nvarchar" 타입(또는 등가물)이다. 그러나, EAddresses 및 PostalAddresses는 각각 EAddress 및 PostAddress 타입의 정의된 타입이거나 또는 "복합 타입"(complex types")(여기에서는 대문자를 사용하여 표시됨)의 속성들이다. 복합 타입은 하나 이상의 단순 데이터 타입들로부터 및/또는 다른 복합 타입들로부터 도출되는 타입이다. 아이템의 속성들에 대한 복합 타입들은 또한 "네스트된 엘리먼트들"(nested elements)을 구성한다. 왜냐하면 복합 타입의 상세들은 그것의 속성들을 정의하기 위해 순간 아이템(immediate Item) 내에 네스트되고, 이들 복합 타입들에 관한 정보는 이들 속성들을 갖는 아이템과 함께(나중에 논의되는 바와 같이, 아이템의 경계 내에) 유지되기 때문이다. 타이핑(typing)의 이 개념들은 잘 알려져 있고 숙련된 당업자들에 의해 쉽게 이해된다.The Location item has a plurality of attributes including EAddresses, MetropolitanRegion, Neighborhood, and PostalAddress. The specific type of attribute for each is shown immediately after the attribute name and separated from the attribute name by a colon (":"). To the right of the type name, the number of allowed values for that attribute type is indicated between square brackets ("[]") and the asterisk ("*") to the right of the colon (":") is unspecified and / or unlimited. Represent a number ("many"). "1" to the right of the colon indicates that there can be at most one value. "0" to the left of the colon indicates that the attribute is optional (there may be no value at all). "1" to the left of the colon indicates that there must be at least one value (the attribute is required). Neighborhood and MetropolitanRegion are both predefined data types or "nvarchar" types (or equivalents) that are "simple types" (here shown without capital letters). However, EAddresses and PostalAddresses are defined types of the EAddress and PostAddress types, respectively, or attributes of "complex types" (indicated here using capital letters): Complex types are from one or more simple data types and And / or derived from other complex types Complex types for the attributes of an item also constitute "nested elements" because the details of the complex type are instantaneous to define its attributes. This is because nested within an Item and information about these complex types is kept with the item with these attributes (as discussed later, within the bounds of the item). It is easily understood by those skilled in the art that are known and skilled.
도 5B는 복합 속성 타입 PostalAddress 및 EAddress를 예시하는 블록도이다. PostalAddress 속성 타입은 속성 타입 Postal Address의 아이템이 0 또는 하나의 City 값, 0 또는 하나의 CountryCode 값, 0 또는 하나의 MailStop 값, 및 임의의 수(0 내지 다수)의 PostalAddressType들 등등을 가질 것으로 예상될 수 있음을 정의한다. 이런 식으로, 아이템 내의 특정 속성에 대한 데이터의 형상이 이로써 정의된다. EAddress 속성 타입은 도시된 바와 같이 유사하게 정의된다. 비록 이 애플리케이션에서는 선택적으로 사용되지만, Location 아이템 내의 복합 타입들을 표현하는 다른 방법은 거기에 리스트된 각각의 복합 타입의 개개의 속성들과 함께 아이템을 그리는 것이다. 도 5C는 Location 아이템을 예시하는 것으로 그것의 복합 타입들이 더 설명되어 있는 블록도이다. 그러나, 이 도 5C에서의 Location 아이템에 대한 이 대안적인 표현은 도 5A에 예시된 것과 동일한 아이템에 대한 것임을 이해해야 한다. 본 발명의 저장 플랫폼은 또한 서브타이핑(subtyping)을 허용하고, 그에 따라서 하나의 속성 타입이 다른 것의 서브타입이 될 수 있다(그 하나의 속성 타입은 다른, 부모 속성 타입의 속성들을 상속한다).5B is a block diagram illustrating the complex attribute types PostalAddress and EAddress. The PostalAddress attribute type is expected that an item of attribute type Postal Address will have zero or one City value, zero or one CountryCode value, zero or one MailStop value, any number (from zero to many) PostalAddressTypes, and so forth. Define that it can. In this way, the shape of the data for a particular attribute in the item is thereby defined. The EAddress attribute type is similarly defined as shown. Although optionally used in this application, another way to represent complex types within a Location item is to draw an item with the individual attributes of each complex type listed there. Fig. 5C is a block diagram illustrating a Location item, the complex types of which are further described. However, it should be understood that this alternative representation of the Location item in this FIG. 5C is for the same item as illustrated in FIG. 5A. The storage platform of the present invention also allows for subtyping, so that one attribute type can be a subtype of another (that one attribute type inherits attributes of another, parent attribute type).
속성들 및 그들의 속성 타입들과 유사하지만 다르게, 아이템들은 서브타입의 주제일 수도 있는 그들 자신의 아이템 타입들을 고유하게 표현한다. 바꾸어 말하면, 본 발명의 몇몇 실시예들에서의 저장 플랫폼은 하나의 아이템이 다른 아이템의 서브타입이 되도록 허용한다(그에 따라서 그 하나의 아이템이 다른, 부모 아이템의 속성들을 상속한다). 또한, 본 발명의 다양한 실시예들에서, 모든 아이템은 베이스 스키마에서 발견되는 제1 및 기본적인 아이템 타입인 "Item" 아이템 타입의 서브타입이다. (베이스 스키마에 대해서는 또한 나중에 상세히 논의될 것이다.) 도 6A는 아이템, 즉 이 인스턴스 내의 Location 아이템을, 베이스 스키마 내에서 발견되는 Item 아이템 타입의 서브타입인 것으로 예시한다. 이 도면에서, 화살표는 (모든 다른 아이템들처럼) Location 아이템이 Item 아이템 타입의 서브타입임을 나타낸다. Item 아이템 타입은, 모든 다른 아이템들이 그로부터 도출되는 기본적인 아이템으로서, ItemId 및 각종 타임스탬프들과 같은 다수의 중요한 속성들을 갖고, 그에 의하여 운영 시스템 내의 모든 아이템들의 표준 속성들을 정의한다. 본 도면에서, Item 아이템 타입의 이들 속성들은 Location에 의해 상속되고 그에 의하여 Location의 속성들이 된다.Similar to attributes and their attribute types, but differently, items uniquely represent their own item types, which may be the subject of a subtype. In other words, the storage platform in some embodiments of the present invention allows one item to be a subtype of another item (thus one item inherits attributes of another, parent item). Further, in various embodiments of the present invention, all items are subtypes of the "Item" item type, which is the first and basic item type found in the base schema. (The base schema will also be discussed in detail later.) FIG. 6A illustrates an item, that is, a Location item in this instance, as being a subtype of the Item item type found in the base schema. In this figure, the arrow indicates that the Location item (like all other items) is a subtype of the Item item type. The Item item type is a basic item from which all other items are derived and has a number of important attributes, such as ItemId and various time stamps, thereby defining the standard attributes of all items in the operating system. In this figure, these attributes of the Item item type are inherited by Location and thereby become attributes of Location.
Item 아이템 타입으로부터 상속된 Location 아이템 내의 속성들을 표현하는 다른 방법은 거기에 리스트된 부모 아이템으로부터의 각각의 속성 타입의 개개의 속성들과 함께 Location을 그리는 것이다. 도 6B는 Location 아이템을 예시하는 것으로 그것의 순간 속성들(immediate properties) 외에 그것의 상속 타입들이 설명되어 있는 블록도이다. 이 아이템은 도 5A에 예시된 것과 동일한 아이템임을 유의하고 이해해야 한다. 다만, 본 도면에서는 Location이 그것의 모든 속성들, 이 도면 및 도 5A에 도시된 즉시 속성들, 및 이 도면에는 도시되어 있지만 도 5A에는 도시되지 않은 상속 속성들(도 5A에서는 이들 속성들이 Location 아이템이 Item 아이템 타입의 서브타입임을 화살표로 도시함으로써 참조된다)과 함께 예시되어 있다.Another way to represent attributes in a Location item inherited from an Item item type is to draw a Location with individual attributes of each attribute type from the parent item listed there. 6B is a block diagram illustrating a Location item, in which its inheritance types are described in addition to its instantiated properties. Note that this item is the same item as illustrated in FIG. 5A. However, in this drawing, Location is all of its properties, this property and the immediate properties shown in FIG. 5A, and inherited properties that are shown in this drawing but not shown in FIG. 5A (in FIG. Is referenced by the arrow indicating that it is a subtype of the Item item type.
아이템들은 독립 실행형 객체들(stand-alone objects)이고, 따라서, 아이템을 삭제하면, 그 아이템의 모든 순간 및 상속 속성들이 또한 삭제된다. 마찬가지로, 아이템을 검색할 때, 수신되는 것은 아이템 및 그것의 모든 순간 및 상속 속성들(그것의 복합 속성 타입들에 관한 정보를 포함)이다. 본 발명의 어떤 실시예들은 특정 아이템을 검색할 때 속성들의 서브세트를 요구할 수 있게 하지만, 다수의 그러한 실시예들에 대한 디폴트는 검색될 때 그것의 모든 순간 및 상속 속성들과 함께 아이템을 제공하는 것이다. 또한, 아이템들의 속성들은 해당 아이템의 타입의 기존 속성들에 새로운 속성들을 부가함으로써 확장될 수도 있다. 이들 "확장"(extensions)은 그 후에 아이템의 진실한 속성들이고 해당 아이템 타입의 서브타입들은 자동적으로 확장 속성들을 포함할 것이다.Items are stand-alone objects, so when you delete an item, all the instantaneous and inherited properties of that item are also deleted. Likewise, when retrieving an item, what is received is the item and all of its instantaneous and inherited attributes (including information about its complex attribute types). While certain embodiments of the present invention may require a subset of attributes when searching for a particular item, the default for many such embodiments is to provide an item with all of its instantaneous and inherited attributes when retrieved. will be. Also, the attributes of the items may be extended by adding new attributes to existing attributes of the type of the item. These "extensions" are then the true attributes of the item and the subtypes of that item type will automatically include the extension attributes.
아이템의 "경계"(boundary)는 그것의 속성들(복합 속성 타입, 확장 등을 포함)에 의해 표현된다. 아이템의 경계는 또한 복사, 삭제, 이동, 생성 등과 같은 아이템에 대해 행해지는 동작의 한계를 표현한다. 예를 들면, 본 발명의 몇몇 실시예에서, 아이템이 복사될 때, 해당 아이템의 경계 내의 모든 것이 또한 복사된다. 각각의 아이템에 대하여, 경계는 다음의 것들을 포함한다:The "boundary" of an item is represented by its attributes (including complex attribute types, extensions, etc.). The boundary of an item also represents the limitation of the action taken on the item, such as copying, deleting, moving, creating, or the like. For example, in some embodiments of the invention, when an item is copied, everything within the bounds of that item is also copied. For each item, the boundary includes the following:
2. 아이템 식별2. Item Identification
아이템들은 ItemID을 갖는 글로벌 아이템 공간 내에서 고유하게 식별된다. Base.Item 타입은 그 아이템에 대한 ID를 저장하는 GUID 타입의 필드 ItemID를 정의한다. 아이템은 데이터 스토어(302)에서 정확히 하나의 ID를 가져야만 한다.Items are uniquely identified within a global item space with an ItemID. Base.Item type defines a field ItemID of type GUID that stores the ID for that item. The item must have exactly one ID in the
아이템 참조(item reference)는 아이템을 위치 지정하고 식별하기 위한 정보를 포함하는 데이터 구조이다. 데이터 모델에서, 모든 아이템 참조 타입들이 그로부터 도출되는 ItemReference라고 명명된 추상 타입이 정의된다. ItemReference 타입은 Resolve라고 명명된 가상의 메서드를 정의한다. 이 메서드는 참조가 주어졌을 때 아이템을 검색하는 함수를 구현하는, ItemReference의 구상 서브타입들(concrete subtypes)에 의해 무효화된다(overridden). Resolve 메서드는 저장 플랫폼 API 322의 파트로서 호출된다.An item reference is a data structure that contains information for locating and identifying an item. In the data model, an abstract type named ItemReference is defined from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. This method is overridden by concrete subtypes of ItemReference, which implement a function to retrieve an item given a reference. The Resolve method is called as part of the
ItemIDReference는 ItemReference의 서브타입이다. 그것은 Locator 및 ItemID 필드를 정의한다. Locator 필드는 아이템 도메인을 명명한다(즉, 식별한다). 그것은 Locator의 값을 아이템 도메인으로 리졸브(resolve)할 수 있는 로케이터 레졸루션 메서드에 의해 처리된다. ItemID 필드는 Item ID 타입이다.ItemIDReference is a subtype of ItemReference. It defines the Locator and ItemID fields. The Locator field names (ie, identifies) the item domain. It is handled by a locator resolution method that can resolve the value of the Locator to the item domain. The ItemID field is an Item ID type.
ItemPathReference는 Locator 및 Path 필드를 정의하는 ItemReference의 특수화(specialization)이다. Locator 필드는 아이템 도메인을 식별한다. 그것은 Locator의 값을 아이템 도메인으로 리졸브할 수 있는 로케이터 레졸루션 메서드에 의해 처리된다. Path 필드는 Locator에 의해 제공된 아이템 도메인에 루트(root)를 둔 저장 플랫폼 네임스페이스 내의 (상대) 경로를 포함한다.ItemPathReference is a specialization of ItemReference that defines the Locator and Path fields. The Locator field identifies the item domain. It is handled by a locator resolution method that can resolve the value of the Locator to the item domain. The Path field contains the (relative) path in the storage platform namespace rooted at the item domain provided by the Locator.
이런 타입의 참조는 세트 연산(set operation)에서 사용될 수 없다. 이 참조는 일반적으로 경로 레졸루션 처리를 통하여 리졸브되어야 한다. 저장 플랫폼 API(322)의 리졸브 메서드는 이 기능을 제공한다.This type of reference cannot be used in set operations. This reference should generally be resolved via a path resolution process. The resolve method of the
위에서 논의된 참조 형태들은 도 11에 예시된 참조 타입 계층 구성을 통하여 표현된다. 이들 타입으로부터 상속하는 부가적인 참조 타입들은 스키마들에서 정의될 수 있다. 그것들은 타깃 필드의 타입으로서 관계 선언에서 사용될 수 있다.Reference forms discussed above are represented via the reference type hierarchy structure illustrated in FIG. 11. Additional reference types that inherit from these types can be defined in schemas. They can be used in relationship declarations as types of target fields.
3. 아이템 폴더 및 카테고리3. Item Folders and Categories
아래에서 더 상세히 논의되겠지만, 아이템들의 그룹들은 아이템 폴더(파일 폴더와 혼동되지 않아야 할 것이다)라고 불리는 특별한 아이템들로 조직된다. 그러나, 대부분의 파일 시스템에서와 달리, 아이템은 2 이상의 아이템 폴더에 속할 수 있고, 그에 따라 하나의 아이템 폴더에서 아이템이 액세스되고 변경될 경우, 이 변경된 아이템은 다른 아이템 폴더로부터 직접 액세스될 수 있다. 본질적으로, 하나의 아이템에 대한 액세스가 서로 다른 아이템 폴더들로부터 발생될 수는 있지만, 실제로 액세스되는 것은 사실상 바로 그 동일한 아이템이다. 그러나, 아이템 폴더는 반드시 그것의 멤버 아이템들 전부를 소유할 필요는 없고, 다만 다른 폴더들과 함께 아이템들을 공동 소유할 수 있고, 그에 따라 아이템 폴더의 삭제로 인해 반드시 아이템이 삭제될 필요는 없다. 그럼에도 불구하고, 본 발명의 몇몇 실시예들에서는, 아이템이 적어도 하나의 아이템 폴더에 속해야 하고 따라서 특정 아이템에 대한 유일한 아이템 폴더가 삭제되면, 일부 실시예들에서, 그 아이템이 자동으로 삭제되거나, 또는 다른 실시예들에서, 그 아이템이 자동으로 디폴트 아이템 폴더(예를 들면, 갖가지 파일-및-폴더 기반 시스템들에서 사용되는 유사하게 명명된 폴더들과 개념적으로 유사한 "TrashCan"(휴지통) 아이템 폴더)의 멤버가 된다.As will be discussed in more detail below, groups of items are organized into special items called item folders (which should not be confused with file folders). However, unlike in most file systems, an item can belong to two or more item folders, so that when an item is accessed and changed in one item folder, the changed item can be accessed directly from another item folder. In essence, access to one item may occur from different item folders, but in fact it is actually the same item that is accessed. However, an item folder does not necessarily need to own all of its member items, but can co-own items with other folders, and hence items need not necessarily be deleted due to deletion of the item folder. Nevertheless, in some embodiments of the present invention, if an item must belong to at least one item folder and thus the only item folder for a particular item is deleted, in some embodiments, the item is automatically deleted, or In other embodiments, the item is automatically a default item folder (eg, a "TrashCan" item folder that is conceptually similar to similarly named folders used in various file-and-folder based systems). Become a member of
또한 아래에서 더 상세히 논의되겠지만, 아이템들은 (a) 아이템 타입(또는 타입들), (b) 특정한 순간 또는 상속 속성(또는 속성들), 또는 (c) 아이템 속성에 대응하는 특정 값(또는 값들)과 같은 공통의 기술 특성(common described characteristics)에 기초한 카테고리들에 속할 수도 있다. 예를 들면, 개인의 콘택트 정보(personal contacts information)에 대한 특정 속성들을 포함하는 아이템은 자동으로 콘택트 카테고리에 속할 것이고, 콘택트 정보 속성들을 갖는 어떠한 아이템이든지 마찬가지로 자동으로 이 카테고리에 속할 것이다. 마찬가지로, "New York City"의 값을 갖는 location 속성을 갖는 어떠한 아이템이든지 자동으로 NewYorkCity 카테고리에 속할 것이다.Also as will be discussed in more detail below, items may be: (a) item type (or types), (b) specific instantaneous or inherited attributes (or attributes), or (c) specific values (or values) corresponding to item attributes. It may belong to categories based on common described characteristics, such as. For example, an item that includes certain attributes for personal contact information will automatically belong to the contact category, and any item with contact information attributes will automatically belong to this category as well. Similarly, any item with a location attribute with a value of "New York City" will automatically belong to the NewYorkCity category.
카테고리들은 아이템 폴더들과는 개념적으로 다르다. 즉, 아이템 폴더들은 상호 관련이 없는(즉, 공통의 기술 특성이 없는) 아이템들을 포함할 수 있는 반면, 카테고리 내의 각각의 아이템은 해당 카테고리에 대해 기술되는 공통의 타입, 속성, 또는 값("공통성")을 갖고, 카테고리 내의 다른 아이템들에 대한 또는 다른 아이템들 사이에서의 그것의 관계에 대한 토대를 형성하는 것이 이러한 공통성이다. 또한, 특정 폴더 내의 아이템의 멤버십은 해당 아이템의 임의의 특정한 특징에 기초하여 강제적이지 않은 반면, 어떤 실시예들에서 하나의 카테고리에 카테고리별로(categorically) 관련된 공통성을 갖는 모든 아이템들은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 자동으로 해당 카테고리의 멤버가 될 것이다. 개념적으로, 카테고리들은 또한 그 멤버십이 (예컨대 데이터베이스의 컨텍스트에서의) 특정 쿼리의 결과에 기초하는 가상 아이템 폴더들로서 간주될 수 있고, (카테고리의 공통성들에 의해 정의된) 이 쿼리의 조건들을 만족시키는 아이템들은 따라서 카테고리의 멤버십을 포함할 것이다.Categories are conceptually different from item folders. That is, item folders may contain items that are not correlated (ie, have no common technical characteristics), while each item in a category has a common type, attribute, or value described for that category ("commonality"). It is this commonality that "" and forms the basis for its relationship to other items in a category or between other items. In addition, while membership of an item in a particular folder is not mandatory based on any particular feature of that item, in some embodiments all items that have a categorically related commonality in one category are hardware / software interface systems. You will automatically be a member of that category in the level. Conceptually, categories can also be considered as virtual item folders whose membership is based on the results of a particular query (eg in the context of a database), and satisfying the conditions of this query (defined by the categories' commonalities). The items will therefore contain membership of the category.
도 4는 아이템들, 아이템 폴더들, 및 카테고리들 간의 구조적 관계를 예시한다. 복수의 아이템들(402, 404, 406, 408, 410, 412, 414, 416, 418, 420)은 각종 아이템 폴더들(422, 424, 426, 428, 430)의 멤버들이다. 어떤 아이템들은 2 이상의 아이템 폴더에 속할 수 있다. 예를 들어, 아이템(402)은 아이템 폴더들(422, 424)에 속한다. 어떤 아이템들, 예를 들어, 아이템들(402, 404, 406, 408, 410, 412)은 또한 하나 이상의 카테고리들(432, 434, 436)의 멤버들이고, 다른 아이템들, 예를 들어, 아이템들(414, 416, 418, 420)은 아무런 카테고리에도 속하지 않을 수 있다(비록 이것은 임의의 속성의 소유가 자동으로 카테고리 내의 멤버십을 의미하는 어떤 실시예들에서는 거의 있을 것 같지 않고, 따라서 그러한 실시예에서는 어떠한 카테고리의 멤버도 되지 않기 위하여 아이템이 전혀 특징이 없어야 하겠지만). 폴더들의 계층형 구조와는 대조적으로, 카테고리들 및 아이템 폴더들은 도시된 바와 같이 지향성 그래프와 더 많이 유사한 구조들을 갖는다. 어떤 경우든, 아이템들, 아이템 폴더들, 및 카테고리들은 모두 아이템들이다(비록 서로 다른 아이템 타입들이기는 하지만).4 illustrates a structural relationship between items, item folders, and categories. The plurality of
파일들, 폴더들, 및 디렉토리들과는 대조적으로, 본 발명의 아이템들, 아이템 폴더들, 및 카테고리들은 본질상 특징적으로 "물리적"이 아니다. 왜냐하면 그것들은 물리적 컨테이너들의 개념적 등가물을 갖고 있지 않고, 따라서 아이템들은 2 이상의 그러한 로케이션에 존재할 수 있기 때문이다. 카테고리들로 조직될 뿐만 아니라 2 이상의 아이템 폴더 로케이션에 아이템들이 존재할 수 있는 능력은 이 기술 분야에서 현재 이용 가능한 정도를 넘어서, 하드웨어/소프트웨어 인터페이스 레벨에서 향상되고 풍부해진 정도의 데이터 조작 처리 및 저장 구조 능력들을 제공한다 In contrast to files, folders, and directories, the items, item folders, and categories of the present invention are not inherently "physical" in nature. Because they do not have conceptual equivalents of physical containers, the items can therefore exist in more than one such location. The ability for items to exist in more than one item folder location, as well as organized into categories, goes beyond what is currently available in the art, and enhances and enriches data manipulation processing and storage structure capabilities at the hardware / software interface level. Provide
4. 스키마4. Schema
a) 베이스 스키마(Base Schema)a) Base Schema
아이템들의 생성 및 이용에 대한 보편적인 토대를 제공하기 위하여, 본 발명의 저장 플랫폼의 여러 실시예들은 아이템들 및 속성들을 생성하고 조직하기 위한 개념적 프레임워크를 확립하는 베이스 스키마를 포함한다. 이 베이스 스키마는 아이템들 및 속성들의 어떤 특별한 타입들, 및 이 특별한 기본적 타입들의 특징들을 정의하고, 그로부터 서브타입들이 더 도출될 수 있다. 이 베이스 스키마의 이용으로 프로그래머가 아이템들(및 그들 각각의 타입들)과 속성들(및 그들 각각의 타입들)을 개념적으로 구별할 수 있게 된다. 또한, 모든 아이템들(및 그들의 대응하는 아이템 타입들)이 베이스 스키마 내의 이 기본적 아이템(및 그것의 대응하는 아이템 타입)으로부터 도출되기 때문에, 베이스 스키마는 모든 아이템들이 소유할 수 있는 속성들의 기본적 세트를 제시한다.In order to provide a universal foundation for the creation and use of items, various embodiments of the storage platform of the present invention include a base schema that establishes a conceptual framework for creating and organizing items and attributes. This base schema defines certain special types of items and attributes, and features of these special basic types, from which further subtypes can be derived. The use of this base schema allows programmers to conceptually distinguish items (and their respective types) and attributes (and their respective types). In addition, since all items (and their corresponding item types) are derived from this basic item (and its corresponding item type) in the base schema, the base schema creates a basic set of attributes that all items can possess. present.
도 7에 예시된 바와 같이, 그리고 본 발명의 몇몇 실시예들과 관련하여, 베이스 스키마는 3개의 상위 레벨 타입들: Item, Extension, 및 PropertyBase를 정의한다. 도시된 바와 같이, 아이템 타입은 이 기본적 "Item" 아이템 타입의 속성들에 의해 정의된다. 이와 대조적으로, 상위 레벨 속성 타입 "PropertyBase"는 미리 정의된 속성들을 갖지 않고 단지 그로부터 다른 모든 속성 타입들이 도출되고 그를 통하여 모든 도출된 속성 타입들이 상호 관련되는(단일 특성 타입으로부터 공통으로 도출되는) 앵커(anchor)에 불과하다. Extension 타입 속성들은 그 확장이 어느 아이템을 확장하는지를 정의할 뿐만 아니라 아이템이 다수의 확장들을 가질 수 있도록 하나의 확장과 다른 확장을 구별하는 식별 정보를 정의한다.As illustrated in FIG. 7 and with respect to some embodiments of the invention, the base schema defines three higher level types: Item, Extension, and PropertyBase. As shown, the item type is defined by the properties of this basic "Item" item type. In contrast, the high level property type "PropertyBase" does not have predefined properties and only anchors from which all other property types are derived and through which all derived property types are correlated (commonly derived from a single property type). It is just anchor. Extension type attributes not only define which item the extension extends, but also define identifying information that distinguishes one extension from another so that an item can have multiple extensions.
ItemFolder는, 아이템으로부터 상속되는 속성들 외에, 그것의 멤버들(만일 있다면)에의 링크를 확립하기 위한 관계(Relationship)를 특징짓는 Item 아이템 타입의 서브타입인 반면, IdentityKey 및 Property는 모두 PropertyBase의 서브타입들이다. 그리고, CategoryRef는 IdentityKey의 서브타입이다.ItemFolder is a subtype of the Item item type that, in addition to the properties inherited from the item, characterizes a relationship to establish a link to its members (if any), while IdentityKey and Property are both subtypes of PropertyBase. admit. CategoryRef is a subtype of IdentityKey.
b) 코어 스키마(Core Schema)b) Core Schema
본 발명의 저장 플랫폼의 여러 실시예들은 또한 상위 레벨 아이템 타입 구조에 대한 개념적 프레임워크를 제공하는 코어 스키마를 포함한다. 도 8A는 코어 스키마 내의 아이템들을 예시하는 블록도이고, 도 8B는 코어 스키마 내의 속성 타입들을 예시하는 블록도이다. 파일-및-폴더 기반 시스템들에서 서로 다른 확장자들(*.com, *.exe, *.bat, *.sys 등) 및 다른 그러한 기준(criteria)으로 파일들 사이에 행해진 구별은 코어 시키마의 기능과 유사하다. 아이템 기반 하드웨어/소프트웨어 인터페이스 시스템에서, 코어 스키마는 모든 아이템들을 아이템 기반 하드웨어/소프트웨어 인터페이스 시스템이 이해하고 미리 정해지거나 또는 예측 가능한 방법으로 직접 처리할 수 있는 하나 이상의 코어 스키마 아이템 타입들로 직접적으로(아이템 타입에 의해) 또는 간접적으로(아이템 서브타입에 의해) 특징화하는 코어 아이템 타입들의 세트를 정의한다. 미리 정의된 아이템 타입들은 아이템 기반 하드웨어/소프트웨어 시스템 내의 가장 공통적인 아이템들을 반영하고 따라서 코어 스키마를 포함하는 이들 미리 정의된 아이템 타입들을 이해하는 아이템 기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 어느 정도의 효율성이 얻어진다.Several embodiments of the storage platform of the present invention also include a core schema that provides a conceptual framework for higher level item type structures. 8A is a block diagram illustrating items in a core schema, and FIG. 8B is a block diagram illustrating attribute types in a core schema. The distinction made between files with different extensions (* .com, * .exe, * .bat, * .sys, etc.) and other such criteria in file-and-folder based systems is a function of the core schema. Similar to In an item-based hardware / software interface system, the core schema directly (item) all items into one or more core schema item types that the item-based hardware / software interface system can understand and process directly in a predetermined or predictable manner. Define a set of core item types that are characterized by type) or indirectly (by item subtype). Predefined item types reflect some of the most common items in an item based hardware / software system and thus some degree of efficiency is gained by an item based hardware / software interface system that understands these predefined item types, including the core schema. Lose.
어떤 실시예들에서는, 코어 스키마는 확장 가능하지 않다. 즉, 코어 스키마의 일부인 특정한 미리 정의되고 도출된 아이템 타입들을 제외하고 베이스 스키마 내의 아이템 타입으로부터 어떠한 부가적인 아이템 타입들도 서브타이핑될 수 없다. 코어 스키마에 대한 확장들을 방지함으로써(즉, 코어 스키마에 새로운 아이템들을 부가하는 것을 방지함으로써), 저장 플랫폼은 코어 스키마 타입들을 사용을 명령한다. 왜냐하면 모든 후속의 아이템 타입이 반드시 코어 스키마 아이템 타입의 서브타입은 아니기 때문이다. 이러한 구조는 부가적인 아이템 타입들을 정의하는 데 있어서 합당한 정도의 유연성을 가능케 하는 한편으로, 또한 코어 아이템 타입들의 미리 정의된 세트를 갖는 이점들을 보존한다.In some embodiments, the core schema is not extensible. That is, no additional item types can be subtyped from the item type in the base schema except for certain predefined and derived item types that are part of the core schema. By preventing extensions to the core schema (ie, preventing adding new items to the core schema), the storage platform instructs the use of core schema types. This is because not all subsequent item types are necessarily subtypes of the core schema item type. This structure allows a reasonable degree of flexibility in defining additional item types, while also preserving the advantages of having a predefined set of core item types.
본 발명의 여러 실시예들에서, 그리고 도 8A를 참조하여, 코어 스키마에 의해 지원되는 특정한 아이템 타입들은 다음의 것들 중 하나 이상을 포함할 수 있다:In various embodiments of the present invention, and with reference to FIG. 8A, certain item types supported by the core schema may include one or more of the following:
마찬가지로, 그리고 도 8B를 참조하여, 코어 스키마에 의해 지원되는 특정 속성 타입들은 다음의 것들 중 하나 이상을 포함할 수 있다:Likewise, and with reference to FIG. 8B, certain attribute types supported by the core schema may include one or more of the following:
이들 아이템들 및 속성들은 도 8A 및 도 8B에서 제시된 그들 각각의 속성들에 의해 더 설명된다.These items and attributes are further described by their respective attributes presented in FIGS. 8A and 8B.
5. 관계(Relationships)5. Relationships
관계들은 하나의 아이템이 소스로 지정되고 다른 아이템이 타깃으로 지정되는 바이너리 관계들이다. 소스 아이템 및 타깃 아이템은 관계에 의해 관련된다. 소스 아이템은 일반적으로 관계의 수명(life-time)을 제어한다. 즉, 소스 아이템이 삭제되면, 아이템들 간의 관계도 삭제된다.Relationships are binary relationships in which one item is designated as the source and the other item is targeted. Source items and target items are related by relationship. Source items generally control the life-time of a relationship. That is, when the source item is deleted, the relationship between the items is also deleted.
관계들은 컨테인먼트(Containment) 및 참조(Reference) 관계들로 분류된다. 컨테인먼트 관계들은 타깃 아이템들의 수명을 제어하는 반면, 참조 관계들은 어떠한 수명 관리 의미론(semantics)도 제공하지 않는다. 도 12는 관계들이 분류되는 방식을 예시한다.Relationships are classified into containment and reference relationships. Containment relationships control the lifetime of the target items, while reference relationships do not provide any life management semantics. 12 illustrates how the relationships are classified.
컨테인먼트 관계 타입들은 홀딩(Holding) 및 임베딩(Embedding) 관계들로 분류된다. 하나의 아이템에 대한 모든 홀딩 관계들이 제거되면, 그 아이템은 삭제된다. 홀딩 관계는 참조 카운팅 메커니즘을 통하여 타깃의 수명을 제어한다. 임베딩 관계들은 복합 아이템들의 모델링을 가능케 하고 배타적인(exclusive) 홀딩 관계들로 간주될 수 있다. 아이템은 하나 이상의 홀딩 관계의 타깃이 될 수 있지만, 아이템은 정확히 하나의 임베딩 관계의 타깃이 될 수 있다. 임베딩 관계의 타깃인 아이템은 임의의 다른 홀딩 및 임베딩 관계들의 타깃이 될 수 없다.Containment relationship types are classified into holding and embedding relationships. When all holding relationships for an item are removed, the item is deleted. The holding relationship controls the life of the target through a reference counting mechanism. Embedding relationships allow the modeling of complex items and can be considered as exclusive holding relationships. An item can be the target of one or more holding relationships, but an item can be the target of exactly one embedding relationship. An item that is the target of an embedding relationship cannot be the target of any other holding and embedding relationships.
참조 관계들은 타깃 아이템의 수명을 제어하지 않는다. 그것들은 댕글링(dangling)으로 될 수 있다. 즉, 타깃 아이템이 존재하지 않을 수 있다. 참조 관계들은 (즉, 원격 데이터 스토어들을 포함하는) 글로벌 아이템 네임스페이스 내의 어디에서도아이템들에 대한 참조들을 모델링하기 위해 사용될 수 있다.Reference relationships do not control the life of the target item. They can be dangling. That is, the target item may not exist. Reference relationships can be used to model references to items anywhere in the global item namespace (ie, including remote data stores).
아이템을 페칭(fetching)함으로써 그것의 관계들이 자동으로 페칭되지 않는다. 애플리케이션들은 아이템의 관계들을 명시적으로 요구해야 한다. 게다가, 관계들을 수정함으로써 타깃 아이템의 소스가 수정되지 않고, 마찬가지로, 관계를 부가함으로써 소스/타깃 아이템이 영향을 받지는 않는다.By fetching an item, its relationships are not automatically fetched. Applications must explicitly request the relationships of items. In addition, modifying the relationships does not modify the source of the target item, and likewise, adding the relationship does not affect the source / target item.
a) 관계 선언(Relationship Declaration)a) Relationship Declaration
명시적 관계 타입들은 다음의 엘리먼트들로 정의된다:Explicit relationship types are defined by the following elements:
소스 아이템은 관계의 소유자이다. 소유자로서 지정된 아이템이 관계의 수명을 제어하는 한편, 관계 자체는 그것과 관련이 있는 아이템들로부터 분리된다. 저장 플랫폼 API(322)는 아이템과 관련된 관계들을 노출시키기 위한 메커니즘들을 제공한다.The source item is the owner of the relationship. While the item designated as the owner controls the lifetime of the relationship, the relationship itself is separated from the items associated with it.
여기에 관계 선언의 일례가 있다:Here is an example of a relationship declaration:
이것은 참조 관계의 일례이다. 소스 참조에 의해 참조되는 person 아이템이 존재하지 않으면 이 관계는 생성될 수 없다. 또한, person 아이템이 삭제되면, 사람(person)과 조직(organization) 간의 관계 인스턴스들은 삭제된다. 그러나, Organization 아이템이 삭제되면, 관계는 삭제되지 않고 그것은 댕글링 상태로 된다.This is an example of a reference relationship. This relationship cannot be created if the person item referenced by the source reference does not exist. Also, when the person item is deleted, the relationship instances between person and organization are deleted. However, if the Organization item is deleted, the relationship is not deleted and it becomes dangling.
b) 홀딩 관계(Holding Relationships)b) Holding Relationships
홀딩 관계들은 타깃 아이템들의 참조 카운트 기반 수명 관리(reference count based life-time management)를 모델링하기 위해 사용된다.Holding relationships are used to model reference count based life-time management of target items.
아이템은 아이템들에 대한 0 이상의 관계들에 대한 소스 종점일 수 있다. 임베드된 아이템(embedded Item)이 아닌 아이템은 하나 이상의 홀딩 관계들에서의 타깃이 될 수 있다.An item can be a source endpoint for zero or more relationships to items. An item that is not an embedded item may be a target in one or more holding relationships.
타깃 종점 참조 타입은 ItemIDReference이어야 하고 그것은 관계 인스턴스로서 동일한 스토어 내의 아이템을 참조하여야 한다.The target endpoint reference type must be an ItemIDReference and it must refer to an item in the same store as the relationship instance.
홀딩 관계들은 타깃 종점의 수명 관리를 시행(enforce)한다. 홀딩 관계 인스턴스 및 그것이 타깃으로 하는 아이템의 생성은 원자 동작(atomic operation)이다. 동일한 아이템을 타깃으로 하는 부가적인 홀딩 관계 인스턴스들이 생성될 수 있다. 주어진 아이템을 타깃 종점으로 하는 마지막 홀딩 관계 인스턴스가 삭제되면 타깃 아이템도 삭제된다.Holding relationships enforce life management of the target endpoint. The creation of a holding relationship instance and the item it targets is an atomic operation. Additional holding relationship instances may be created that target the same item. If the last holding relationship instance with the given item as the target endpoint is deleted, the target item is also deleted.
관계 선언에서 특정된 종점 아이템들의 타입들은 일반적으로 관계의 인스턴스가 생성될 때 시행될 것이다. 종점 아이템들의 타입들은 관계가 확립된 후에는 변경될 수 없다.The types of endpoint items specified in the relationship declaration will generally be enforced when an instance of the relationship is created. The types of endpoint items cannot be changed after the relationship is established.
홀딩 관계들은 아이템 네임스페이스를 형성하는 데 중요한 역할을 한다. 그것들은 소스 아이템에 상대적인 타깃 아이템의 이름을 정의하는 "Name" 속성을 포함한다. 이 상대 이름은 주어진 아이템으로부터 발생된 모든 홀딩 관계들에 대해 고유하다. 루트 아이템에서 시작하여 주어진 아이템까지 이 상대 이름들의 순서화된 리스트는 그 아이템에 대한 전체 이름(full name)을 형성한다.Holding relationships play an important role in forming the item namespace. They include a "Name" attribute that defines the name of the target item relative to the source item. This relative name is unique for all holding relationships resulting from a given item. An ordered list of these relative names, starting at the root item and up to a given item, forms the full name for that item.
홀딩 관계들은 지향성 비순환 그래프(directed acyclic graph: DAG)를 형성한다. 홀딩 관계가 생성되면 시스템은 사이클이 생성되지 않도록 보장하고, 따라서 아이템 네임스페이스가 DAG를 형성하도록 보장한다.Holding relationships form a directed acyclic graph (DAG). Once a holding relationship is created, the system ensures that no cycle is created, thus ensuring that the item namespace forms a DAG.
홀딩 관계는 타깃 아이템의 수명을 제어하지만, 그것은 타깃 종점 아이템의 동작의 일관성을 제어하지는 않는다. 타깃 아이템은 홀딩 관계를 통하여 그것을 소유하는 아이템으로부터 동작상으로 독립적이다. 홀딩 관계의 소스인 아이템에 대한 복사, 이동, 백업 및 다른 동작들은 동일한 관계의 타깃인 아이템에 영향을 미치지 않는다. 예를 들면, 즉 폴더 아이템을 백업함으로써 폴더 내의 모든 아이템들(FolderMember 관계의 타깃들)이 자동으로 백업되지는 않는다.The holding relationship controls the lifetime of the target item, but it does not control the consistency of the behavior of the target endpoint item. The target item is operatively independent of the item that owns it through the holding relationship. Copying, moving, backing up, and other operations on an item that is the source of a holding relationship do not affect items that are the target of the same relationship. For example, by backing up a folder item, not all items in the folder (targets in the FolderMember relationship) are automatically backed up.
다음은 홀딩 관계의 일례이다:The following is an example of a holding relationship:
FolderMembers 관계는 아이템들의 일반적 컬렉션(generic collection)으로서 폴더의 개념을 가능케 한다.The FolderMembers relationship enables the concept of folders as a generic collection of items.
c) 임베딩 관계(Embedding Relationships)c) Embedding Relationships
임베딩 관계들은 타깃 아이템의 수명에 대한 배타적 제어의 개념을 모델링한다. 그것들은 복합 아이템들의 개념을 가능케 한다.Embedding relationships model the concept of exclusive control over the lifetime of the target item. They enable the concept of composite items.
임베딩 관계 인스턴스 및 그것이 타깃으로 하는 아이템의 생성은 원자 동작이다. 아이템은 0 또는 그 이상의 임베딩 관계의 소스일 수 있다. 그러나, 아이템은 하나의 및 단 하나의 임베딩 관계의 타깃일 수 있다. 임베딩 관계의 타깃인 아이템은 홀딩 관계의 타깃일 수 없다.The creation of an embedding relationship instance and the item it targets is atomic behavior. The item may be a source of zero or more embedding relationships. However, an item can be the target of one and only one embedding relationship. An item that is a target of an embedding relationship cannot be a target of a holding relationship.
타깃 종점 참조 타입은 ItemIDReference이어야 하고 그것은 관계 인스턴스로서 동일한 데이터 스토어 내의 아이템을 참조해야 한다.The target endpoint reference type must be an ItemIDReference and it must refer to an item in the same data store as the relationship instance.
관계 선언에서 특정된 종점 아이템들의 타입들은 일반적으로 관계의 인스턴스가 생성될 때 시행될 것이다. 종점 아이템들의 타입들은 관계가 확립된 후에는 변경될 수 없다.The types of endpoint items specified in the relationship declaration will generally be enforced when an instance of the relationship is created. The types of endpoint items cannot be changed after the relationship is established.
임베딩 관계들은 타깃 종점의 동작적인 일관성을 제어할 수 있다. 예를 들면 아이템의 직렬화(serializing)의 동작은 해당 아이템뿐만 아니라 그들의 타깃들 모두로부터 발생하는 모든 임베딩 관계들의 직렬화(serialization)를 포함할 수 있고, 아이템을 복사하는 것은 또한 모든 그것의 임베드된 아이템들을 복사한다.Embedding relationships can control the operational consistency of the target endpoint. For example, the operation of serializing an item may include the serialization of all embedding relationships arising from both the item as well as their targets, and copying the item may also include all its embedded items. Copy
다음은 선언의 일례이다:The following is an example of a declaration:
d) 참조 관계(Reference Relationships)d) Reference Relationships
참조 관계는 그것이 참조하는 아이템의 수명을 제어하지 않는다. 심지어, 참조 관계들은 타깃의 존재를 보증하지도 않고, 관계 선언에서 특정된 대로 타깃의 타입을 보증하지도 않는다. 이것은 참조 관계들이 댕글링으로 될 수 있다는 것을 의미한다. 또한, 참조 관계는 다른 데이터 스토어들 내의 아이템들을 참조할 수 있다. 참조 관계들은 웹 페이지들에서의 링크들과 유사한 개념으로 간주될 수 있다.A reference relationship does not control the life of the item it references. Even reference relationships do not guarantee the existence of the target, nor do they guarantee the type of the target as specified in the relationship declaration. This means that the reference relationships can be dangling. In addition, the reference relationship may refer to items in other data stores. Reference relationships can be thought of as a concept similar to links in web pages.
다음은 참조 관계 선언의 일례이다:The following is an example of a reference relationship declaration:
타깃 종점에는 임의의 참조 타입이 허용된다. 참조 관계에 관여하는 아이템들은 임의의 아이템 타입일 수 있다.Any reference type is allowed for the target endpoint. The items involved in the reference relationship can be of any item type.
참조 관계들은 아이템들 간의 대부분의 비수명 관리 관계들(non-lifetime management relationships)을 모델링하기 위해 사용된다. 타깃의 존재는 시행되지 않으므로, 참조 관계는 느슨하게 연결된 관계들(loosely-coupled relationships)을 모델링하기에 편리하다. 참조 관계는 다른 컴퓨터 상의 스토어들을 포함한 다른 데이터 스토어들 내의 아이템들을 타깃팅하기 위해 사용될 수 있다.Reference relationships are used to model most of the non-lifetime management relationships between items. Since the presence of the target is not enforced, the reference relationship is convenient for modeling loosely-coupled relationships. The reference relationship can be used to target items in other data stores, including stores on other computers.
e) 규칙 및 제약(Rules and Constraints)e) Rules and Constraints
다음의 부가적인 규칙들 및 제약들이 관계들에 적용된다:The following additional rules and constraints apply to relationships:
f) 관계들의 순서화(Ordering of Relationships)f) Ordering of Relationships
적어도 하나의 실시예에서, 본 발명의 저장 플랫폼은 관계들의 순서화를 지원한다. 이 순서화는 베이스 관계 정의에서 "Order"라고 명명된 속성을 통하여 성취된다. Order 필드에는 어떠한 고유성 제약(uniqueness constraint)도 없다. 동일한 "order"(순서) 속성 값을 갖는 관계들의 순서는 보증되지 않지만, 그것들은 보다 낮은 "order" 값을 갖는 관계들 뒤에 그리고 보다 높은 "order" 필드 값을 갖는 관계들 앞에 순서화될 수 있다는 것은 보증된다.In at least one embodiment, the storage platform of the present invention supports the ordering of relationships. This ordering is accomplished through an attribute named "Order" in the base relationship definition. There is no uniqueness constraint on the Order field. The order of relationships with the same "order" attribute value is not guaranteed, but it can be ordered after relationships with lower "order" values and before relationships with higher "order" field values. Guaranteed.
애플리케이션들은 조합(SourceItemID, RelationshipID, Order)에 기초하여 순서화함으로써 디폴트 순서의 관계들을 얻을 수 있다. 주어진 아이템으로부터 발생된 모든 관계 인스턴스들은 컬렉션 내의 관계들의 타입에 상관없이 단일 컬렉션으로서 순서화된다. 그러나 이것은 주어진 타입의 모든 관계들(예를 들면, FolderMembers)이 주어진 아이템에 대한 관계 컬렉션의 순서화된 서브세트임을 보증한다.Applications can obtain relationships in a default order by ordering based on a combination (SourceItemID, RelationshipID, Order). All relationship instances resulting from a given item are ordered as a single collection, regardless of the type of relationships in the collection. However, this ensures that all relationships of a given type (eg FolderMembers) are an ordered subset of the collection of relationships for a given item.
관계들을 조작 처리하기 위한 데이터 스토어 API(312)는 관계들의 순서화를 지원하는 동작들의 세트를 구현한다. 다음의 용어들이 그 동작들의 설명을 돕기 위해 도입된다:The
동작들은 다음을 포함하지만 이들에 제한되지는 않는다:Actions include but are not limited to:
앞에서 언급한 바와 같이, 모든 아이템은 아이템 폴더의 멤버이어야 한다. 관계(Relationships)의 관점에서, 모든 아이템은 아이템 폴더와 관계를 가져야 한다. 본 발명의 몇몇 실시예에서, 어떤 관계들은 아이템들 간에 존재하는 관계들에 의해 표현된다.As mentioned earlier, every item must be a member of an item folder. In terms of relationships, every item must have a relationship with an item folder. In some embodiments of the invention, certain relationships are represented by relationships that exist between items.
본 발명의 다양한 실시예들에서 구현될 때, 관계(Relationship)는 하나의 아이템(소스)에 의해 또 하나의 아이템(타깃)으로 "확장"되는 지향성 바이너리 관계(directed binary 관계)를 제공한다. 관계는 소스 아이템(그것을 확장한 아이템)에 의해 소유되고, 따라서 소스가 제거되면 관계는 제거된다(예를 들면, 관계는 소스 아이템이 삭제될 때 삭제된다). 더욱이, 어떤 경우에, 관계는 (공동 소유의) 타깃 아이템의 소유권을 공유하고, 그러한 소유권은 (관계 속성 타입에 대하여 도 7에 도시된 바와 같이) 관계의 IsOwned 속성(또는 그것의 등가물)에 반영될 것이다. 이들 실시예에서, 새로운 IsOwned 관계의 생성은 타깃 아이템 상의 참조 카운트를 자동으로 증가시키고, 그러한 관계의 삭제는 타깃 아이템 상의 참조 카운트를 감소시킬 것이다. 이들 특정 실시예들에서, 아이템들은 0보다 큰 참조 카운트를 갖는다면 계속해서 존재하고, 그 카운트가 0에 도달하면 자동으로 삭제된다. 다시, 아이템 폴더는 다른 아이템들(이들 다른 아이템들은 아이템 폴더의 멤버십을 포함함)에 대한 관계들의 세트를 갖는(또는 가질 수 있는) 아이템이다. 여기에서 설명된 기능을 성취하기 위해 본 발명에 의해 Relationship들의 다른 실제의 구현들이 가능하고 예상된다.When implemented in various embodiments of the present invention, a relationship provides a directed binary relationship that is "extended" by one item (source) to another item (target). The relationship is owned by the source item (the item that extends it), so when the source is removed the relationship is removed (eg, the relationship is deleted when the source item is deleted). Moreover, in some cases, the relationship shares ownership of the target item (co-owned), and such ownership is reflected in the IsOwned attribute (or its equivalent) of the relationship (as shown in FIG. 7 for the relationship attribute type). Will be. In these embodiments, creation of a new IsOwned relationship will automatically increase the reference count on the target item, and deletion of such a relationship will decrease the reference count on the target item. In these particular embodiments, the items continue to exist if they have a reference count greater than zero and are automatically deleted when the count reaches zero. Again, an item folder is an item that has (or may have) a set of relationships for other items (these other items include membership of the item folder). Other practical implementations of Relationships are possible and expected by the present invention to achieve the functionality described herein.
실제의 구현들에 상관없이, 관계는 하나의 객체로부터 다른 객체로의 선택 가능한 연결이다. 하나의 아이템이 2 이상의 아이템 폴더에는 물론, 하나 이상의 카테고리에 속할 수 있는 능력은, 이들 아이템들, 폴더들, 및 카테고리들이 공용(public)이든 전용(private)이든, 아이템 기반 구조에서 존재(또는 그것의 결여)에 주어진 의미들에 의해 결정된다. 이들 논리적 관계들은, 물리적 구현에 상관없이, 여기에서 설명된 기능을 성취하기 위해 구체적으로 이용되는, 관계들의 세트에 할당된 의미들이다. 논리적 관계들은 아이템과 그것의 폴더(들) 또는 카테고리들(혹은 반대로) 사이에 확립된다. 왜냐하면, 본질적으로, 아이템 폴더들 및 카테고리들은 각각 특별한 타입의 아이템이기 때문이다. 따라서, 아이템 폴더들 및 카테고리들은 임의의 다른 아이템과 동일하게 작용될 수 있고 - 제한 없이 복사되고, 이메일 메시지에 부가되고, 문서 내에 임베드되는 등등 - 아이템 폴더들 및 카테고리들은 다른 아이템들에 대해서와 동일한 메커니즘을 이용하여 직렬화(serialize) 및 비직렬화(de-serialize)될(가져오기(import) 및 내보내기(export)될) 수 있다. (예를 들면, XML에서 모든 아이템들은 직렬화 포맷을 가질 수 있고, 이 포맷은 아이템 폴더들, 카테고리들, 및 아이템들에 동등하게 적용된다.)Regardless of the actual implementations, a relationship is a selectable connection from one object to another. The ability of an item to belong to more than one category, as well as to more than one item folder, exists in an item infrastructure, whether or not these items, folders, and categories are public or private. Is determined by the meanings given in. These logical relationships are the meanings assigned to the set of relationships that are specifically used to achieve the functionality described herein, regardless of the physical implementation. Logical relationships are established between the item and its folder (s) or categories (or vice versa). Because, in essence, item folders and categories are each a special type of item. Thus, item folders and categories can act the same as any other item-copied without limitation, added to an email message, embedded in a document, etc.-Item folders and categories are the same as for other items. The mechanism can be used to serialize and deserialize (import and export). (For example, all items in XML can have a serialization format, which applies equally to item folders, categories, and items.)
아이템과 그 아이템 폴더(들) 간의 관계를 나타내는 전술한 관계들은 아이템으로부터 아이템 폴더로, 또는 아이템 폴더로부터 아이템으로, 또는 양쪽 모두로 논리적으로 확장할 수 있다. 아이템으로부터 아이템 폴더로 논리적으로 확장하는 관계는 그 아이템 폴더가 해당 아이템에 공용이고 그것의 멤버십 정보를 해당 아이템과 공유한다는 것을 나타내고, 반대로, 아이템으로부터 아이템 폴더로의 논리적 관계의 결여는 아이템 폴더가 해당 아이템에 전용이고 그것의 멤버십을 해당 아이템과 공유하지 않는다는 것을 나타낸다. 마찬가지로, 아이템 폴더로부터 아이템으로 논리적으로 확장하는 관계는 그 아이템이 해당 아이템 폴더에 공용이고 공유 가능하다는 것을 나타내는 반면, 아이템 폴더로부터 아이템으로의 논리적 관계의 결여는 그 아이템이 전용이고 공유 불가능하다는 것을 나타낸다. 따라서, 아이템 폴더가 다른 시스템에 내보내기될 때, 그것은 새로운 컨텍스트에서 공유되는 "공용" 아이템들이고, 아이템이 다른 공유 가능한 아이템들에 대한 그것의 아이템 폴더들을 검색할 때, 그것은 거기에 속하는 공유 가능한 아이템들에 관한 정보를 그 아이템에 제공하는 "공용" 아이템 폴더들이다.The aforementioned relationships indicative of the relationship between an item and its item folder (s) may logically extend from item to item folder, from item folder to item, or both. A logically expanding relationship from an item to an item folder indicates that the item folder is common to that item and shares its membership information with that item, on the contrary, the lack of a logical relationship from item to item folder indicates that the item folder Indicates that the item is private and does not share its membership with that item. Similarly, a logically expanding relationship from an item folder to an item indicates that the item is public and shareable to the item folder, while the lack of a logical relationship from the item folder to the item indicates that the item is dedicated and unsharable. . Thus, when an item folder is exported to another system, it is a "public" item that is shared in a new context, and when the item retrieves its item folders for other shareable items, it is the shareable items belonging to it. "Public" item folders that provide information about the item.
도 9는 아이템 폴더(이것은 다시 아이템 자체이기도 하다), 그것의 멤버 아이템들, 및 아이템 폴더와 그것의 멤버 아이템들 간의 상호 연결 관계들을 예시하는 블록도이다. 아이템 폴더(900)는 멤버들로서 복수의 아이템들(902, 904, 906)을 갖는다. 아이템 폴더(900)는 자신으로부터 아이템(902)으로의 관계(912)를 갖고 이것은 그 아이템(902)이 공용이고 아이템 폴더(900), 그것의 멤버들(904, 906), 및 임의의 다른 아이템 폴더들, 카테고리들, 또는 아이템 폴더(900)에 액세스할지도 모르는 아이템들(도시되지 않음)에게 공유 가능하다는 것을 나타낸다. 그러나, 아이템(902)으로부터 아이템 폴더(900)로의 관계는 없고 이것은 아이템 폴더(900)가 아이템(902)에 전용이고 그것의 멤버십 정보를 아이템(902)과 공유하지 않는다는 것을 나타낸다. 한편, 아이템(904)은 자신으로부터 아이템 폴더(900)로의 관계(924)를 갖고 이것은 아이템 폴더(900)가 공용이고 그것의 멤버십 정보를 아이템(904)와 공유한다는 것을 나타낸다. 그러나, 아이템 폴더(900)로부터 아이템(904)으로의 관계는 없고 이것은 아이템(904)이 전용이고 아이템 폴더(900), 그것의 다른 멤버들(902, 906), 및 임의의 다른 아이템 폴더들, 카테고리들, 또는 아이템 폴더(900)에 액세스할지도 모르는 아이템들(도시되지 않음)에게 공유 불가능하다는 것을 나타낸다. 아이템들(902, 904)에 대한 그것의 관계들(또는 그것의 결여)과 대조적으로, 아이템 폴더(900)는 자신으로부터 아이템(906)으로의 관계(916)를 갖고 아이템(906)은 역으로 아이템 폴더(900)로의 관계(926)를 갖고, 이것들은 함께 아이템(906)이 공용이고 아이템 폴더(900), 그것의 멤버들(902, 904), 및 임의의 다른 아이템 폴더들, 카테고리들, 또는 아이템 폴더(900)에 액세스할지도 모르는 아이템들(도시되지 않음)에게 공유 가능하고, 또한 아이템 폴더(900)가 공용이고 그것의 멤버십 정보를 아이템(906)과 공유한다는 것을 나타낸다.9 is a block diagram illustrating an item folder (which is again an item itself), its member items, and the interconnections between the item folder and its member items. The
앞에서 논의한 바와 같이, 아이템 폴더 내의 아이템들은 아이템 폴더들이 "기술"(describe)되지 않기 때문에 공통성을 공유할 필요가 없다. 한편, 카테고리들은 그것의 멤버 아이템들 모두에게 공통인 공통성에 의해 기술된다. 따라서 카테고리의 멤버십은 기술된 공통성을 갖는 아이템들에 고유하게 제한되고, 어떤 실시예들에서는, 카테고리의 기술을 만족시키는 모든 아이템들이 자동으로 그 카테고리의 멤버들로 된다. 따라서, 아이템 폴더들은 사소한 타입 구조들이 그들의 멤버십에 의해 표현되도록 허용하는 반면, 카테고리들은 정의된 공통성에 기초하여 멤버십을 허용한다.As discussed above, items in an item folder do not need to share commonality because the item folders are not "described." On the other hand, categories are described by commonality to all of their member items. Thus, membership of a category is inherently limited to items with the described commonality, and in some embodiments, all items that satisfy the description of the category automatically become members of that category. Thus, item folders allow minor type structures to be represented by their membership, while categories allow membership based on defined commonalities.
물론 카테고리 기술들은 본질상 논리적이고, 따라서 카테고리는 타입들, 속성들, 및/또는 값들의 임의의 논리적 표현에 의해 기술될 수 있다. 예를 들면, 카테고리에 대한 논리적 표현은 2개의 속성들 중 하나 또는 양쪽 모두를 갖는 아이템들을 포함하는 그것의 멤버십일 수 있다. 만일 카테고리에 대한 이들 기술된 속성들이 "A" 및 "B"이면, 카테고리 멤버십은 속성 A는 갖고 B는 갖지 않는 아이템들, 속성 B는 갖고 A는 갖지 않는 아이템들, 속성 A 및 B 양쪽 모두를 갖는 아이템들을 포함할 수 있다. 속성들에 대한 이 논리적 표현은 논리적 연산자 "OR"에 의해 기술되고 카테고리에 의해 기술된 멤버들의 세트는 속성 A OR B를 갖는 아이템들이다. 숙련된 당업자라면 알겠지만, (제한 없이 "AND", "XOR", 및 "NOT"를 단독으로 또는 조합하여 포함하는) 유사한 논리적 피연산자들이 또한 카테고리를 기술하기 위해 사용될 수 있다.Of course category descriptions are logical in nature, and thus a category can be described by any logical representation of types, attributes, and / or values. For example, the logical representation for a category may be its membership including items with one or both of the two attributes. If these described attributes for the category are "A" and "B", then the category membership is for items with attribute A but without B, items with attribute B and no A, both attributes A and B. It may include items having. This logical representation of the attributes is described by the logical operator "OR" and the set of members described by the category are items with the attribute A OR B. As will be appreciated by those skilled in the art, similar logical operands (including without limitation "AND", "XOR", and "NOT" alone or in combination) may also be used to describe categories.
(기술되지 않은) 아이템 폴더들 및 (기술된) 카테고리들 간의 구별에도 불구하고, 본 발명의 여러 실시예들에서 아이템 폴더들 및 아이템들에 대하여 위에서 개시한 것과 본질적으로 동일하게 카테고리들은 아이템들에 관계하고 아이템들은 카테고리에 관계한다.Notwithstanding the distinction between item folders (not described) and categories (described), categories are essentially identical to those described above for item folders and items in various embodiments of the invention. Related items and categories.
도 10은 카테고리(이것은 다시 아이템 자체이기도 하다), 그것의 멤버 아이템들, 및 카테고리와 그것의 멤버 아이템들 간의 상호 연결 관계들을 예시하는 블록도이다. 카테고리(1000)는 멤버들로서 복수의 아이템들(1002, 1004, 1006)을 갖고, 이것들 모두는 카테고리(1000)에 의해 기술된 공통의 속성들, 값들, 또는 타입들(1008)(공통성 기술(1008'))의 어떤 조합을 공유한다. 카테고리(1000)는 자신으로부터 아이템(1002)으로의 관계(1012)를 갖고 이것은 그 아이템(1002)이 공용이고 카테고리(1000), 그것의 멤버들(1004, 1006), 및 임의의 다른 카테고리들, 아이템 폴더들, 또는 카테고리(1000)에 액세스할지도 모르는 아이템들(도시되지 않음)에게 공유 가능하다는 것을 나타낸다. 그러나, 아이템(1002)으로부터 카테고리(1000)로의 관계는 없고 이것은 카테고리(1000)가 아이템(1002)에 전용이고 그것의 멤버십 정보를 아이템(1002)과 공유하지 않는다는 것을 나타낸다. 한편, 아이템(1004)은 자신으로부터 카테고리(1000)로의 관계(1024)를 갖고 이것은 카테고리(1000)가 공용이고 그것의 멤버십 정보를 아이템(1004)와 공유한다는 것을 나타낸다. 그러나, 카테고리(1000)로부터 아이템(1004)으로 확장된 관계는 없고 이것은 아이템(1004)이 전용이고 카테고리(1000), 그것의 다른 멤버들(1002, 1006), 및 임의의 다른 카테고리들, 아이템 폴더들, 또는 카테고리(1000)에 액세스할지도 모르는 아이템들(도시되지 않음)에게 공유 불가능하다는 것을 나타낸다. 아이템들(1002, 1004)과의 그것의 관계들(또는 그것의 결여)과 대조적으로, 카테고리(1000)는 자신으로부터 아이템(1006)으로의 관계(1016)를 갖고 아이템(1006)은 역으로 카테고리(1000)로의 관계(1026)를 갖고, 이것들은 함께 아이템(1006)이 공용이고 카테고리(1000), 그것의 멤버들(1002, 1004), 및 임의의 다른 카테고리들, 아이템 폴더들, 또는 카테고리(1000)에 액세스할지도 모르는 아이템들(도시되지 않음)에게 공유 가능하고, 또한 카테고리(1000)가 공용이고 그것의 멤버십 정보를 아이템(1006)과 공유한다는 것을 나타낸다.10 is a block diagram illustrating a category (which in turn is the item itself), its member items, and the interconnections between the category and its member items.
마지막으로, 카테고리들 및 아이템 폴더들은 그들 자신이 아이템들이고, 아이템들은 서로 관계할 수 있기 때문에, 카테고리들이 아이템 폴더들에 관계할 수도 있고 아이템 폴더들이 카테고리들에 관계할 수도 있고, 어떤 다른 실시예들에서 카테고리들, 아이템 폴더들, 및 아이템들은 각각 다른 카테고리들, 아이템 폴더들, 및 아이템들에 관계할 수 있다. 그러나, 여러 실시예들에서, 아이템 폴더 구조들 및/또는 카테고리 구조들은 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 사이클들을 포함하는 것이 금지된다. 아이템 폴더 및 카테고리 구조들이 지향성 그래프들과 유사한 경우에, 사이클들을 금지하는 실시예들은 지향성 비순환 그래프들(DAGs: directed acyclic graphics)과 유사하고, 이것은 그래프 이론의 기술 분야에서의 수학적 정의에 의해 아무런 경로도 시작하지 않고 동일한 정점(vertex)에서 종료하지 않는 지향성 그래프들이다.Finally, because categories and item folders are items themselves, items may relate to each other, categories may relate to item folders, item folders may relate to categories, and some other embodiments. In categories, item folders, and items may relate to other categories, item folders, and items, respectively. However, in various embodiments, item folder structures and / or category structures are prohibited from including cycles at the hardware / software interface system level. In the case where the item folder and category structures are similar to directional graphs, the embodiments that prohibit cycles are similar to directed acyclic graphics (DAGs), which are no paths by mathematical definition in the technical field of graph theory. These are directivity graphs that do not start or end at the same vertex.
6. 확장성(Extensibility)6. Extensibility
저장 플랫폼은 상술한 바와 같이 스키마들의 초기 세트(340)를 구비하도록 의도되어 있다. 그러나, 또한, 적어도 일부 실시예들에서, 저장 플랫폼은 독립적 소프트웨어 벤더(ISV들)를 포함하는 고객들이 새로운 스키마들(344)(즉, 새로운 아이템 및 네스트된 엘리먼트 타입들)을 생성하도록 허용한다. 이 섹션은 스키마들의 초기 세트(340)에서 정의된 아이템 타입들 및 네스트된 엘리먼트 타입들(또는 간단히 "엘리먼트" 타입들)을 확장함으로써 그러한 스키마들을 생성하기 위한 메커니즘을 다룬다.The storage platform is intended to have an
바람직하게는, 아이템 및 네스트된 엘리먼트 타입들의 초기 세트의 확장은 다음과 같이 제약을 받는다:Preferably, the extension of the initial set of item and nested element types is constrained as follows:
그러나,But,
저장 플랫폼 스키마들의 초기 세트에 의해 정의된 아이템 타입 또는 네스트된 아이템 타입은 ISV 애플리케이션의 요구에 정확히 부합하지 않을 수도 있으므로, ISV들이 타입을 맞춤화(customize)하도록 허용할 필요가 있다. 이것은 확장(Extensions)의 개념으로 허용된다. 확장들은 공고히 타이핑된 인스턴스들이지만 (a) 그것들은 독립적으로 존재할 수 없고 (b) 그것들은 아이템 또는 네스트된 엘리먼트에 첨부되어야 한다.The item type or nested item type defined by the initial set of storage platform schemas may not exactly meet the needs of the ISV application, so it is necessary to allow ISVs to customize the type. This is allowed in the concept of extensions. Extensions are well-typed instances, but (a) they cannot exist independently and (b) they must be attached to an item or nested element.
스키마 확장성에 대한 요구를 다루는 것 외에, 확장들은 또한 "멀티타이핑"(multi-typing) 문제를 다루도록 의도되어 있다. 일부 실시예들에서, 저장 플랫폼은 다수의 상속 또는 중첩 서브타입들을 지원하지 않을 수 있으므로, 애플리케이션들은 중첩 타입 인스턴스들을 모델링하는 방법으로서 확장들을 이용할 수 있다(예를 들면, Document는 안전한 문서일 뿐만 아니라 법적 문서이다).In addition to addressing the need for schema extensibility, extensions are also intended to address the "multi-typing" problem. In some embodiments, the storage platform may not support multiple inheritance or nested subtypes, so applications may use extensions as a method of modeling nested type instances (eg, Document is not only a secure document, Legal document).
a) 아이템 확장(Item extensions)a) Item extensions
아이템 확장성을 제공하기 위하여, 데이터 모델은 Base.Extension이라고 명명된 추상 타입을 더 정의한다. 이것은 확장 타입들의 계층 구성에 대한 루트 타입이다. 애플리케이션들은 특정 확장 타입들을 생성하기 위해 Base.Extension들을 서브타이핑할 수 있다.To provide item extensibility, the data model further defines an abstract type named Base.Extension. This is the root type for the hierarchy of extension types. Applications can subtype Base.Extensions to create specific extension types.
Base.Extension 타입은 베이스 스키마에서 다음과 같이 정의된다.Base.Extension type is defined as follows in base schema.
ItemID 필드는 확장이 관련되어 있는 아이템의 ItemID를 포함한다. 이 ItemID를 갖는 아이템이 존재하여야 한다. 주어진 ItemID를 갖는 아이템이 존재하지 않으면 확장은 생성될 수 없다. 아이템이 삭제되면 동일한 ItemID를 갖는 모든 확장들이 삭제된다. 투플(tuple)(ItemID,ExtensionID)은 확장 인스턴스를 고유하게 정의한다.The ItemID field contains the ItemID of the item to which the extension is associated. An item with this ItemID must exist. An extension cannot be created if there is no item with the given ItemID. When an item is deleted, all extensions with the same ItemID are deleted. A tuple (ItemID, ExtensionID) uniquely defines an extension instance.
확장 타입의 구조는 아이템 타입의 구조와 유사하다:The structure of an extended type is similar to that of an item type:
다음의 제한들이 확장 타입들에 적용된다:The following restrictions apply to extension types:
주어진 아이템 타입과 관련될 수 있는 확장 타입들에는 아무런 제약도 없다. 어떠한 확장 타입이든지 임의의 아이템 타입을 확장하도록 허용된다. 아이템에 다수의 확장 인스턴스들이 첨부되는 경우, 그것들은 구조 및 작용 모두에서 서로 독립적이다.There are no restrictions on the types of extensions that can be associated with a given item type. Any extension type is allowed to extend any item type. When multiple extension instances are attached to an item, they are independent of each other in both structure and action.
확장 인스턴스들은 아이템과 별도로 저장되고 액세스된다. 모든 확장 타입 인스턴스들은 글로벌 확장 뷰(global extension view)로부터 액세스 가능하다. 그것들이 관련되어 있는 아이템의 타입이 무엇이든 상관없이 주어진 확장 타입의 모든 인스턴스들을 반환(return)할 효율적인 쿼리가 구성될 수 있다. 저장 플랫폼 API들은 아이템들 상의 확장들을 저장, 검색 및 수정할 수 있는 프로그래밍 모델을 제공한다.Extension instances are stored and accessed separately from the item. All extension type instances are accessible from the global extension view. No matter what type of item they are associated with, an efficient query can be constructed that will return all instances of a given extended type. Storage platform APIs provide a programming model for storing, retrieving, and modifying extensions on items.
확장 타입들은 저장 플랫폼 단일 상속 모델을 이용하여 서브타이핑된 타입일 수 있다. 확장 타입으로부터 도출함으로써 새로운 확장 타입이 생성된다. 확장의 구조 또는 작용은 아이템 타입 계층 구성의 구조 또는 비헤이비어들을 무효화(override)하거나 대체할 수 없다. 아이템 타입들과 마찬가지로, 확장 타입 인스턴스들은 확장 타입과 관련된 뷰를 통하여 직접 액세스될 수 있다. 확장의 ItemID는 그것들이 어느 아이템에 속하는지를 나타내고 글로벌 아이템 뷰로부터 대응하는 아이템 객체를 검색하기 위해 사용될 수 있다. 확장들은 동작의 일관성을 위하여 아이템의 일부로 간주된다. 복사/이동, 백업/복원 및 저장 플랫폼이 정의하는 다른 공통의 동작들은 아이템의 일부로서 확장들에 작용할 수 있다.Extension types may be subtyped using a storage platform single inheritance model. By deriving from an extension type, a new extension type is created. The structure or behavior of an extension may not override or replace the structure or behavior of an item type hierarchy. Like item types, extension type instances can be accessed directly through views associated with the extension type. The ItemID of the extension indicates which item they belong to and can be used to retrieve the corresponding item object from the global item view. Extensions are considered part of the item for consistency of operation. Other common operations that copy / move, backup / restore, and storage platforms define may act on extensions as part of the item.
다음 예를 생각해보자. Contact 타입이 윈도즈 타입 세트에서 정의된다.Consider the following example. The contact type is defined in the Windows type set.
</Type></ Type>
CRM 애플리케이션 개발자는 저장 플랫폼에 저장된 콘택트들에 CRM 애플리케이션 확장을 첨부하기를 원할 것이다. 이 애플리케이션 개발자는 애플리케이션이 조작 처리할 수 있는 부가적인 데이터 구조를 포함할 CRM 확장을 정의할 것이다.The CRM application developer will want to attach the CRM application extension to the contacts stored on the storage platform. The application developer will define a CRM extension that will contain additional data structures that the application can manipulate.
또한 HR 애플리케이션 개발자가 콘택트와 함께 부가적인 데이터를 첨부하기를 원할 수 있다. 이 데이터는 CRM 애플리케이션 데이터와 독립적이다. 다시 애플리케이션 개발자는 확장을 생성할 수 있다.HR application developers may also want to attach additional data with their contacts. This data is independent of CRM application data. Again, application developers can create extensions.
CRMExtension 및 HRExtension은 Contact 아이템들에 첨부될 수 있는 2개의 독립된 확장들이다. 그것들은 서로 독립적으로 생성되고 액세스될 수 있다.CRMExtension and HRExtension are two independent extensions that can be attached to Contact items. They can be created and accessed independently of each other.
상기 예에서, CRMExtension 타입의 필드들 및 메서드들은 Contact 계층 구성의 필드들 또는 메서드들을 무효화할 수 없다. CRMExtension 타입의 인스턴스들은 Contact 이외의 아이템 타입들에 첨부될 수 있다는 것에 유의해야 할 것이다.In the example above, fields and methods of the CRMExtension type cannot invalidate fields or methods of the Contact hierarchy. It should be noted that instances of the CRMExtension type can be attached to item types other than Contact.
Contact 아이템이 검색될 때, 그것의 아이템 확장들은 자동으로 검색되지 않는다. Contact 아이템이 주어진 경우, 그것의 관련 아이템 확장들은 동일한 ItemID를 갖는 확장들에 대하여 글로벌 확장 뷰를 쿼리(query)함으로써 액세스될 수 있다.When a Contact item is retrieved, its item extensions are not automatically retrieved. Given a Contact item, its related item extensions can be accessed by querying the global extension view for extensions with the same ItemID.
시스템 내의 모든 CRMExtension 확장들은 그들이 어느 아이템에 속하는지에 상관없이 CRMExtension 타입 뷰를 통하여 액세스될 수 있다. 아이템의 모든 아이템 확장들은 동일한 아이템 id를 공유한다. 상기 예에서, Contact 아이템 인스턴스들 및 첨부된 CRMExtension 및 HRExtension 인스턴스들은 동일한 ItemID를 공유한다.All CRMExtension extensions in the system can be accessed through the CRMExtension type view, regardless of which item they belong to. All item extensions of an item share the same item id. In this example, Contact item instances and the attached CRMExtension and HRExtension instances share the same ItemID.
다음의 표는 아이템(Item), 확장(Extension) 및 NestedElement 타입들 간의 유사점 및 차이점들을 요약한다:The following table summarizes the similarities and differences between the Item, Extension, and NestedElement types:
아이템 대 아이템 확장 대 NestedElementItem vs Item Expansion vs NestedElement
(Relationship semantics)(Relationship semantics)
b) NestedElement 타입 확장b) NestedElement type extension
네스트된 엘리먼트 타입들은 아이템 타입들과 동일한 메커니즘으로 확장되지 않는다. 네스트된 엘리먼트들의 확장들은 네스트된 엘리먼트 타입들의 필드들과 동일한 메커니즘으로 저장되고 액세스된다.Nested element types do not extend to the same mechanism as item types. Extensions of nested elements are stored and accessed with the same mechanism as fields of nested element types.
데이터 모델은 Element라고 명명된 네스트된 엘리먼트 타입들에 대한 루트를 정의한다:The data model defines a root for nested element types named Element:
NestedElement 타입은 이 타입으로부터 상속한다. NestedElement 엘리먼트 타입은 부가적으로 엘리먼트들의 멀티세트인 필드를 정의한다.The NestedElement type inherits from this type. The NestedElement element type additionally defines a field that is a multiset of elements.
NestedElement 확장들은 다음과 같이 아이템 확장들과 다르다:NestedElement extensions differ from item extensions as follows:
다음 표는 아이템 확장들 및 NestedElement 확장들을 요약하고 비교한다.The following table summarizes and compares item extensions and NestedElement extensions.
아이템 확장 대 NestedElement 확장Item Expansion vs NestedElement Extension
D. 데이터베이스 엔진D. Database Engine
위에서 언급한 바와 같이, 데이터 스토어는 데이터베이스 엔진 상에서 구현된다. 본 실시예에서, 데이터베이스 엔진은 객체 관계 확장들(object relational extensions)로, 마이크로소프트 SQL 서버 엔진과 같은, SQL 쿼리 언어를 구현하는 관계 데이터베이스 엔진(relational database engine)을 포함한다. 이 섹션은 본 실시예에 따라서, 데이터 스토어가 구현하는 데이터 모델의 관계 스토어에의 매핑을 설명하고 저장 플랫폼 클라이언트들에 의해 소비되는 논리적 API에 대한 정보를 제공한다. 그러나, 상이한 데이터베이스 엔진이 이용될 때 상이한 매핑이 이용될 수 있음은 물론이다. 실제로, 관계 데이터베이스 엔진 상에서 저장 플랫폼 개념 데이터베이스 모델을 구현하는 것 외에, 그것은 다른 타입의 데이터베이스들, 예를 들면, 객체 지향(object-oriented) 및 XML 데이터베이스들 상에서도 구현될 수 있다.As mentioned above, the data store is implemented on a database engine. In this embodiment, the database engine includes object relational extensions, a relational database engine that implements the SQL query language, such as the Microsoft SQL Server engine. This section describes the mapping of the data model that the data store implements to the relation store, and provides information about the logical APIs consumed by the storage platform clients, according to this embodiment. However, of course, different mappings may be used when different database engines are used. Indeed, in addition to implementing the storage platform conceptual database model on the relational database engine, it can also be implemented on other types of databases, for example, object-oriented and XML databases.
객체 지향(OO) 데이터베이스 시스템은 프로그래밍 언어 객체들(예를 들면, C++, Java)에 대한 영속성 및 트랜잭션들을 제공한다. "아이템"의 저장 플랫폼 개념은 객체 지향 시스템에서의 "객체"(Object)에도 잘 매핑된다(비록 임베드된 컬렉션들이 객체들에 부가되어야 하겠지만). 상속 및 네스트된 엘리먼트 타입들처럼, 다른 저장 플랫폼 타입 개념들도 객체 지향 타입 시스템들을 매핑한다. 객체 지향 시스템들은 전형적으로 이미 객체 아이덴티티(identity)를 지원하고, 따라서 아이템 아이덴티티는 객체 아이덴티티에 매핑될 수 있다. 아이템 비헤이비어들(동작들)은 객체 메서드들에 잘 매핑된다. 그러나, 객체 지향 시스템들은 전형적으로 조직 능력(organizational capabilities)이 없고 검색에서 취약하다. 또한, 객체 지향 시스템들은 비구조화된 및 반구조화된 데이터에 대한 지원을 제공하지 않는다. 여기에서 설명된 완전한 저장 플랫폼 데이터 모델을 지원하기 위하여, 관계, 폴더, 및 확장과 같은 개념들이 객체 데이터 모델에 부가될 필요가 있을 것이다. 게다가, 프로모션, 동기화, 통지, 및 보안과 같은 메커니즘들이 구현될 필요가 있을 것이다.Object-Oriented (OO) database systems provide persistence and transactions for programming language objects (eg, C ++, Java). The concept of the storage platform of "items" maps well to "Objects" in object-oriented systems (although embedded collections must be added to objects). Like inherited and nested element types, other storage platform type concepts map object-oriented type systems. Object-oriented systems typically already support object identity, so item identity can be mapped to object identity. Item behaviors (actions) map well to object methods. However, object-oriented systems typically lack organizational capabilities and are vulnerable to search. In addition, object-oriented systems do not provide support for unstructured and semi-structured data. In order to support the complete storage platform data model described herein, concepts such as relationships, folders, and extensions will need to be added to the object data model. In addition, mechanisms such as promotion, synchronization, notification, and security will need to be implemented.
객체 지향 시스템들과 유사하게, XML 데이터베이스들은, XSD(XML Schema Definition)에 기초하여, 단일 상속 기반 타입 시스템(single-inheritance based type system)을 지원한다. 본 발명의 아이템 타입 시스템은 XSD 타입 모델에 매핑될 수 있을 것이다. XSD들은 또한 비헤이비어들에 대한 지원을 제공하지 않는다. 아이템들에 대한 XSD들은 아이템 비헤이비어들(item behaviors)로 증가(augment)되어야 할 것이다. XML 데이터베이스들은 단일 XSD 문서들을 다루고 조직화 및 넓은 검색 능력들이 없다. 객체 지향 데이터베이스들에서와 같이, 여기에서 설명된 데이터 모델을 지원하기 위하여, 관계, 및 폴더와 같은 다른 개념들이 그러한 XLM 데이터베이스들에 통합될 필요가 있을 것이고, 또한 동기화, 통지 및 보안과 같은 메커니즘들이 구현될 필요가 있을 것이다.Similar to object-oriented systems, XML databases support a single-inheritance based type system, based on XML Schema Definition (XSD). The item type system of the present invention may be mapped to an XSD type model. XSDs also do not provide support for behaviors. XSDs for items will have to be augmented with item behaviors. XML databases handle single XSD documents and lack organizational and broad search capabilities. As with object-oriented databases, in order to support the data model described herein, other concepts such as relationships, and folders will need to be integrated into such XLM databases, and mechanisms such as synchronization, notification, and security may also be required. It will need to be implemented.
다음의 하위 섹션들과 관련하여, 개시된 일반적인 정보의 이해를 용이하게 하기 위하여 약간의 예시들이 제공된다. 도 13은 통지 메커니즘을 예시하는 도면이다. 도 14는 2개의 트랜잭션들이 양쪽 모두 새로운 레코드를 동일한 B-트리에 삽입하는 예를 예시하는 도면이다. 도 15는 데이터 변경 검출 프로세스를 예시한다. 도 16은 예시적인 디렉토리 트리를 예시한다. 도 17은 디렉토리 기반 파일 시스템의 기존의 폴더가 저장 플랫폼 데이터 스토어 내로 이동되는 예를 도시한다.Regarding the following subsections, some examples are provided to facilitate understanding of the general information disclosed. 13 is a diagram illustrating a notification mechanism. 14 is a diagram illustrating an example in which two transactions both insert a new record into the same B-tree. 15 illustrates a data change detection process. 16 illustrates an example directory tree. 17 shows an example where an existing folder of a directory-based file system is moved into a storage platform data store.
1. UDT를 이용한 데이터 스토어 구현1. Data Store Implementation using UDT
본 실시예에서는, 일 실시예에서 마이크로소프트 SQL 서버 엔진을 포함하는 관계 데이터베이스 엔진(314)이 내장형(built-in) 스칼라 타입들(built-in scalar types)을 지원한다. 내장형 스칼라 타입들은 "원시적"(native)이고 "단순"(simple)하다. 그것들은 사용자가 그들 자신의 타입들을 정의할 수 없다는 점에서 원시적이고 그것들이 복합 구조를 캡슐화(encapsulate)할 수 없다는 점에서 단순하다. 사용자 정의 타입들(이하에서는, UDT들)은 사용자들이 복합의 구조화된 타입들을 정의하여 원시 스칼라 타입 시스템을 확장할 수 있게 함으로써 상기 원시 스칼라 타입 시스템을 넘어서 타입 확장성에 대한 메커니즘을 제공한다. 일단 사용자에 의해 정의되면, UDT는 내장형 스칼라 타입이 사용될 수 있는 타입 시스템 내의 어디에서든지 사용될 수 있다.In this embodiment, the relational database engine 314, which in one embodiment includes the Microsoft SQL Server engine, supports built-in scalar types. Built-in scalar types are "native" and "simple". They are primitive in that users cannot define their own types and are simple in that they cannot encapsulate complex structures. User-defined types (hereinafter, UDTs) provide a mechanism for type extensibility beyond the native scalar type system by allowing users to define complex structured types to extend the native scalar type system. Once defined by the user, the UDT can be used anywhere in the type system where built-in scalar types can be used.
본 발명의 일 양태에 따르면, 저장 플랫폼 스키마들은 데이터베이스 엔진 스토어 내의 UDT 클래스들에 매핑된다. 데이터 스토어 아이템들은 Base.Item 타입으로부터 도출하는 UDT 클래스들에 매핑된다. 아이템들처럼, 확장들도 UDT 클래스들에 매핑되고 상속을 이용한다. 루트 확장 타입은 Base.Extension이고, 그로부터 모든 확장 타입들이 도출된다.According to one aspect of the invention, storage platform schemas are mapped to UDT classes in a database engine store. Data store items are mapped to UDT classes that derive from the Base.Item type. Like items, extensions are mapped to UDT classes and use inheritance. The root extension type is Base.Extension, from which all extension types are derived.
UDT는 CLR 클래스이다 - 그것은 상태(즉, 데이터 필드들) 및 비헤이비어(즉, 루틴들)을 갖는다. UDT들은 관리되는 언어들 - C#, VB.NET 등 - 중 임의의 것을 이용하여 정의된다. UDT 메서드들 및 연산자들은 그 타입의 인스턴스에 대하여 T-SQL에서 호출될 수 있다. UDT는 로우(row) 내의 칼럼(column)의 타입, T-SQL 내의 루틴의 파라미터의 타입, 또는 T-SQL 내의 변수의 타입일 수 있다.UDT is a CLR class-it has state (ie data fields) and behaviors (ie routines). UDTs are defined using any of the managed languages-C #, VB.NET, etc. UDT methods and operators can be called in T-SQL for instances of that type. The UDT may be the type of a column in a row, the type of a parameter of a routine in T-SQL, or the type of a variable in T-SQL.
저장 플랫폼 스키마들의 UTD 클래스들에의 매핑은 하이 레벨에서 상당히 직접적이다(fairly straightforward). 일반적으로, 저장 플랫폼 스키마는 CLR 네임스페이스에 매핑된다. 저장 플랫폼 타입은 CLR 클래스에 매핑된다. CLR 클래스 상속은 저장 플랫폼 타입 상속을 반영하고, 저장 플랫폼 속성은 CLR 클래스 속성에 매핑된다.The mapping of storage platform schemas to UTD classes is fairly straightforward at a high level. In general, the storage platform schema is mapped to the CLR namespace. The storage platform type is mapped to the CLR class. CLR class inheritance reflects storage platform type inheritance, and storage platform properties are mapped to CLR class properties.
2. 아이템 매핑2. Item Mapping
아이템들이 전역적으로 검색 가능한 것이 바람직하고, 상속 및 타입 대체성(substitutability)에 대한 본 실시예의 관계 데이터에서의 지원이 있을 경우, 데이터베이스 스토어 내의 아이템 저장에 대한 하나의 가능한 구현은 모든 아이템들을 Base.Item 타입의 칼럼을 갖는 단일 표에 저장하는 것일 것이다. 타입 대체성을 이용하여, 모든 타입의 아이템들이 저장될 수 있고, 검색들은 Yukon의 "is of (Type)" 연산자를 이용하여 아이템 타입 및 서브타입에 의해 필터링될 수 있다.If the items are preferably globally searchable, and there is support in the relationship data of this embodiment for inheritance and type substitutability, one possible implementation for storing items in a database store may list all items. You will store it in a single table with columns of type Item. Using type substitution, items of all types can be stored, and searches can be filtered by item type and subtype using Yukon's "is of (Type)" operator.
그러나, 그러한 방법과 관련된 오버헤드(overhead)에 대한 우려 때문에, 본 실시예에서는, 아이템들이 상위 레벨 타입에 의해 나누어지고, 따라서 각각의 타입 "패밀리"의 아이템들은 별개의 표에 저장된다. 이 분할 방식 하에서는, Base.Item으로부터 직접 상속하는 각각의 아이템 타입에 대해 표가 생성된다. 이것들 아래에 상속하는 타입들은 위에서 설명한 바와 같이 타입 대체성을 이용하여 적당한 타입 패밀리 표에 저장된다. Base.Item으로부터의 상속의 제1 레벨만이 특별하게 취급된다.However, due to the concern about the overhead associated with such a method, in this embodiment, the items are divided by higher level type, so that items of each type "family" are stored in a separate table. Under this partitioning scheme, a table is created for each item type that inherits directly from Base.Item. Types inheriting from below are stored in the appropriate type family table using type substitution as described above. Only the first level of inheritance from Base.Item is treated specially.
모든 아이템들에 대해 전역적으로 검색 가능한 속성들의 복사본을 저장하기 위하여 "음영"(shadow) 표가 사용된다. 이 표는, 그를 통해 모든 데이터 변경들이 행해지는, 저장 플랫폼 API의 Update() 메서드에 의해 유지될 수 있다. 타입 패밀리 표들과 다르게, 이 글로벌 아이템 표는, 전체 UDT 아이템 객체가 아니라, 아이템의 상위 레벨 스칼라 속성들만을 포함한다. 이 글로벌 아이템 표는 ItemID 및 TypeID를 노출시킴으로써 타입 패밀리 표에 저장된 아이템 객체에의 탐색을 가능케 한다. ItemID는 일반적으로 데이터 스토어 내의 아이템을 고유하게 식별할 것이다. TypeID는 여기에서 설명되지 않은 메타데이터를 이용하여 타입 이름 및 해당 아이템을 포함하는 뷰에 매핑될 수 있다. 그것의 ItemID에 의해 아이템을 찾는 것은 공통의 동작일 수 있으므로, 글로벌 아이템 표의 컨텍스트에서 및 다른 경우에서, 아이템의 ItemID가 주어지면 아이템 객체를 검색하기 위한 GetItem() 함수가 제공된다.A "shadow" table is used to store a copy of the globally searchable attributes for all items. This table can be maintained by the Update () method of the storage platform API, through which all data changes are made. Unlike type family tables, this global item table contains only the high level scalar properties of the item, not the entire UDT item object. This global item table exposes ItemID and TypeID to enable navigation to item objects stored in the type family table. The ItemID will typically uniquely identify the item in the data store. The TypeID may be mapped to a view containing the type name and the corresponding item using metadata not described herein. Since finding an item by its ItemID can be a common operation, in the context of a global item table and in other cases, a GetItem () function is provided to retrieve an item object given the ItemID of the item.
편리한 액세스를 위하여 그리고 가능한 한 구현 상세를 감추기 위하여, 아이템들의 모든 쿼리들은 위에서 설명한 아이템 표들 상에 구축된 뷰들에 대한 것일 수 있다. 구체적으로, 뷰들은 적당한 타입의 패밀리 표에 대하여 각각의 아이템 타입마다 생성될 수 있다. 이들 타입 뷰들은 서브타입들을 포함하여, 관련 타입의 모든 아이템들을 선택할 수 있다. 편의를 위하여, UDT 객체 외에, 뷰들은 상속 필드들을 포함하여, 해당 타입의 상위 레벨 필드들 모두에 대한 칼럼들을 노출시킬 수 있다.For convenient access and to hide the implementation details as much as possible, all queries of the items may be for views built on the item tables described above. Specifically, views may be created for each item type for a family table of the appropriate type. These type views can select all items of the related type, including subtypes. For convenience, in addition to the UDT object, views may expose columns for all of the higher level fields of that type, including inherited fields.
3. 확장 매핑3. Extension Mapping
확장들은 아이템들과 매우 유사하고 몇 가지의 동일한 요건들을 갖는다. 또 하나의 루트 타입 지원 상속으로서, 확장들은 저장 시에 다수의 동일한 고려(considerations) 및 트레이드오프(trade-offs)의 대상이 된다. 이 때문에, 단일 표 방법보다는, 유사 타입 패밀리 매핑이 확장들에 적용된다. 물론, 다른 실시예들에서, 단일 표 방법이 사용될 수 있다. 본 실시예에서, 확장은 ItemID에 의해 정확히 하나의 아이템과 관련되고, 아이템의 컨텍스트에서 고유한 ExtensionID를 포함한다. 아이템들에서와 같이, ItemID 및 ExtensionID 쌍으로 이루어진 그것의 아이덴티티가 주어지면 확장을 검색하기 위한 함수가 제공될 수 있다. 아이템 타입 뷰들과 마찬가지로, 각각의 확장 타입마다 뷰가 생성된다.Extensions are very similar to items and have some of the same requirements. As another root type support inheritance, extensions are subject to many of the same considerations and trade-offs in storage. Because of this, rather than single table method, similar type family mapping is applied to extensions. Of course, in other embodiments, a single table method may be used. In this embodiment, the extension is associated with exactly one item by ItemID and includes an ExtensionID that is unique in the context of the item. As with items, a function may be provided to retrieve an extension given its identity, which consists of an ItemID and ExtensionID pair. As with item type views, a view is created for each extension type.
4. 네스트된 엘리먼트 매핑4. Nested Element Mapping
네스트된 엘리먼트들(Nested Elements)은 깊게 네스트된 구조들을 형성하기 위해 아이템들, 확장들, 관계들, 또는 다른 네스트된 엘리먼트들에 임베드될 수 있는 타입들이다. 아이템들 및 확장들처럼, 네스트된 엘리먼트들은 UDT들로서 구현되지만, 그것들은 아이템들 및 확장들 내에 저장된다. 따라서, 네스트된 엘리먼트들은 그들의 아이템 및 확장 컨테이너들의 저장 매핑 이외에 저장 매핑을 갖지 않는다. 바꾸어 말하면, 시스템 내에 NestedElement 타입들의 인스턴스들을 직접 저장하는 표가 없고, 네스트된 엘리먼트들에 특정하게 전용되는 뷰가 없다.Nested Elements are types that can be embedded in items, extensions, relationships, or other nested elements to form deeply nested structures. Like items and extensions, nested elements are implemented as UDTs, but they are stored within items and extensions. Thus, nested elements do not have a storage mapping other than the storage mapping of their item and extension containers. In other words, there is no table in the system that stores instances of NestedElement types directly, and no views are specifically dedicated to nested elements.
5. 객체 아이덴티티(Object Identity)5. Object Identity
데이터 모델 내의 각각의 엔트리, 즉 각각의 아이템, 확장 및 관계는 고유의 키 값(key value)을 갖는다. 아이템은 그것의 ItemId에 의해 고유하게 식별된다. 확장은 (ItemId, ExtensionId)의 혼합 키에 의해 고유하게 식별된다. 관계는 혼합 키(ItemId, RelationshipId)에 의해 식별된다. ItemId, ExtensionId 및 RelationshipId는 GUID 값들이다.Each entry in the data model, each item, extension, and relationship, has a unique key value. An item is uniquely identified by its ItemId. Extensions are uniquely identified by a mixed key of (ItemId, ExtensionId). Relationships are identified by mixed keys (ItemId, RelationshipId). ItemId, ExtensionId and RelationshipId are GUID values.
6. SQL 객체 명명6. Naming SQL Objects
데이터 스토어 내에 생성된 모든 객체들은 저장 플랫폼 스키마 이름으로부터 도출된 SQL 스키마 이름으로 저장될 수 있다. 예를 들면, 저장 플랫폼 베이스 스키마(흔히 "베이스"(Base)라 불림)는 "[System.Storage].Item"과 같은 "[System.Storage]" SQL 스키마 내의 타입들을 생성할 수 있다. 생성된 이름들은 명명 충돌(naming conflicts)을 제거하기 위하여 한정자(qualifier)가 앞에 붙는다. 적당할 경우, 감탄 문자(!)가 이름의 각각의 논리적 파트에 대한 분리자로서 사용된다. 아래의 표는 데이터 스토어 내의 객체들에 대해 사용되는 명명 규칙을 약술(outline)한다. 각각의 스키마 엘리먼트(아이템, 확장, 관계 및 뷰)가 데이터 스토어 내의 인스턴스들에 액세스하기 위해 사용되는 수식된 명명 규칙(decorated naming convention)과 함께 리스트되어 있다.All objects created in the data store can be stored with the SQL schema name derived from the storage platform schema name. For example, the storage platform base schema (commonly called "Base") can create types in the "[System.Storage]" SQL schema, such as "[System.Storage] .Item". Generated names are prefixed with qualifiers to eliminate naming conflicts. Where appropriate, exclamation characters (!) Are used as separators for each logical part of the name. The table below outlines the naming conventions used for objects in the data store. Each schema element (items, extensions, relationships, and views) is listed with a decorated naming convention used to access instances in the data store.
[Master!Item]
[System.Storage].
[ Master! Item ]
[OfficeDoc]
AcmeCorp.Doc.
[OfficeDoc]
[Master!Extension]
[System.Storage].
[Master! Extension]
[Extension!StickyNote]AcmeCorp.Doc.
[ Extension ! StickyNote]
[Master!Relationship] [System.Storage].
[Master! Relationship]
[Relationship!AuthorsFromDocument]AcmeCorp.Doc.
[ Relationship ! AuthorsFromDocument]
[View!DocumentTitles]AcmeCorp.Doc.
[ View ! DocumentTitles]
7. 칼럼 명명7. Column Naming
임의의 객체 모델을 스토어 내에 매핑할 경우, 애플리케이션 객체와 함께 저장된 부가적인 정보 때문에 명명 충돌의 가능성이 발생한다. 명명 충돌을 피하기 위하여, 모든 비타입 특정 칼럼들(non-type specific columns)(타입 선언 내의 명명된 속성에 직접 매핑하지 않는 칼럼들)은 밑줄(_) 문자가 앞에 붙는다. 본 실시예에서, 밑줄(_) 문자들은 임의의 식별자 속성의 시작 문자로서 허용되지 않는다. 또한, CLR과 데이터 스토어 간의 명명을 단일화하기 위하여, 저장 플랫폼 타입들 또는 스키마 엘리먼트(관계 등)의 모든 속성들은 대문자로 된 첫 번째 문자를 가져야 한다.When mapping an arbitrary object model into a store, the possibility of naming conflicts arises because of the additional information stored with the application object. To avoid naming conflicts, all non-type specific columns (columns that do not directly map to named attributes in the type declaration) are prefixed with an underscore (_) character. In this embodiment, underscore (_) characters are not allowed as the start character of any identifier attribute. In addition, to unify naming between the CLR and the data store, all attributes of storage platform types or schema elements (such as relationships) must have the first letter in uppercase.
8. 검색 뷰(Search Views)8. Search Views
저장된 콘텐츠를 검색하기 위하여 저장 플랫폼에 의해 뷰들이 제공된다. 각각의 아이템 및 확장 타입에 대하여 SQL 뷰가 제공된다. 또한, (데이터 모델에 의해 정의된 바와 같이) 관계들 및 뷰들을 지원하기 위해 뷰들이 제공된다. 저장 플랫폼 내의 모든 SQL 뷰들 및 하위 표들(underlying tables)은 읽기 전용이다. 아래에서 더 상세히 설명되겠지만, 데이터는 저장 플랫폼 API의 Update() 메서드를 이용하여 저장되거나 변경될 수 있다.Views are provided by the storage platform to retrieve the stored content. SQL views are provided for each item and extension type. In addition, views are provided to support relationships and views (as defined by the data model). All SQL views and underlying tables in the storage platform are read only. As described in more detail below, data can be stored or changed using the Update () method of the storage platform API.
저장 플랫폼 스키마에서 명시적으로 정의된(스키마 설계자에 의해 정의되고, 저장 플랫폼에 의해 자동으로 생성되지 않은) 각각의 뷰는 명명된 SQL 뷰 [<schema-name>].[View!<view-name>]에 의해 액세스 가능하다. 예를 들면, 스키마 "AcmePublisher.Books"에서 "BookSales"라고 명명된 뷰는 이름 "[AcmePublisher.Books].[View!BookSales]"를 이용하여 액세스 가능할 것이다. 뷰의 출력 포맷은 뷰별로(on a per-view basis) 맞춤화(custom)되므로(뷰를 정의하는 당사자(party)에 의해 제공된 임의의 쿼리에 의해 정의됨), 칼럼들은 스키마 뷰 정의에 기초하여 직접 매핑된다.Each view explicitly defined in the storage platform schema (defined by the schema designer and not automatically generated by the storage platform) is named SQL view [<schema-name>]. [ View! accessible by <view-name>]. For example, a view named "BookSales" in the schema "AcmePublisher.Books" would be accessible using the name "[AcmePublisher.Books]. [View! BookSales]". Since the output format of the view is customized on a per-view basis (defined by any query provided by the party defining the view), the columns are directly based on the schema view definition. Mapped.
저장 플랫폼 데이터 스토어 내의 모든 SQL 검색 뷰들은 칼럼들에 대한 다음의 순서화 규칙을 이용한다:All SQL search views in the storage platform data store use the following ordering rules for columns:
각각의 타입 패밀리의 멤버들은 일련의 아이템 뷰들을 이용하여 검색 가능하고, 데이터 스토어 내의 아이템 타입마다 하나의 뷰가 있다. 도 28은 아이템 검색 뷰의 개념을 예시하는 도면이다.Members of each type family are searchable using a series of item views, and there is one view for each item type in the data store. 28 is a diagram illustrating the concept of an item search view.
a) 아이템a) items
각각의 아이템 검색 뷰는 특정 타입 또는 그것의 서브타입들의 아이템의 각각의 인스턴스에 대한 행(row)을 포함한다. 예를 들면, Document에 대한 뷰는 Document, LegalDocument 및 ReviewDocument의 인스턴스들을 반환할 수 있다. 이 예가 주어지면, 아이템 뷰들은 도 29에 도시된 바와 같이 개념화될 수 있다.Each item search view includes a row for each instance of an item of a particular type or subtypes thereof. For example, a view for Document can return instances of Document, LegalDocument, and ReviewDocument. Given this example, item views can be conceptualized as shown in FIG. 29.
(1) 마스터 아이템 검색 뷰(Master Item Search View)(1) Master Item Search View
저장 플랫폼 데이터 스토어의 각각의 인스턴스는 마스터 아이템 뷰(Master Item View)라고 불리는 특별한 아이템 뷰를 정의한다. 이 뷰는 데이터 스토어 내의 각각의 아이템에 관한 요약 정보를 제공한다. 이 뷰는 아이템 타입 속성마다 하나의 칼럼을 제공하고, 아이템의 타입을 기술하는 칼럼 및 변경 추적 및 동기화 정보를 제공하기 위해 사용되는 몇몇 칼럼들을 제공한다. 마스터 아이템 뷰는 이름 "[System.Storage].[Master!Item]"을 이용하여 데이터 스토어 내에서 식별된다.Each instance of the storage platform data store defines a special item view called Master Item View. This view provides summary information about each item in the data store. This view provides one column per item type attribute, a column describing the type of the item, and some columns used to provide change tracking and synchronization information. The master item view is identified in the data store using the name "[System.Storage]. [Master! Item]".
(2) 타입 아이템 검색 뷰(Typed Item Search Views)(2) Typed Item Search Views
각각의 아이템 타입은 또한 검색 뷰를 갖는다. 루트 아이템 뷰와 유사하지만, 이 뷰는 또한 "_Item" 칼럼을 통하여 아이템 객체에의 액세스를 제공한다. 각각의 타입 아이템 검색 뷰는 이름 [schemaName].[itemTypeName]을 이용하여 데이터 스토어 내에서 식별된다. 예를 들면, [AcmeCorp.Doc].[OfficeDoc].Each item type also has a search view. Similar to the root item view, this view also provides access to the item object through the "_Item" column. Each type item search view is identified in the data store using the name [ schemaName ]. [ ItemTypeName ]. For example, [AcmeCorp.Doc]. [OfficeDoc].
b) 아이템 확장b) item expansion
WinFS 스토어 내의 모든 아이템 확장들은 또한 검색 뷰들을 이용하여 액세스 가능하다.All item extensions in the WinFS store are also accessible using search views.
(1) 마스터 확장 검색 뷰(1) master extended search view
데이터 스토어의 각각의 인스턴스는 마스터 확장 뷰(Master Extension View)라고 불리는 특별한 확장 뷰를 정의한다. 이 뷰는 데이터 스토어 내의 각각의 확장에 관한 요약 정보를 제공한다. 이 뷰는 확장 속성마다 하나의 칼럼을 제공하고, 확장의 타입을 설명하는 칼럼 및 변경 추적 및 동기화 정보를 제공하기 위해 사용되는 몇몇 칼럼들을 제공한다. 마스터 확장 뷰는 이름 "[System.Storage].[Master!Extension]"을 이용하여 데이터 스토어 내에서 식별된다.Each instance of a data store defines a special extended view extended view called the Master (Master Extension View). This view provides summary information about each extension in the data store. This view provides one column per extension attribute, a column describing the type of extension, and some columns used to provide change tracking and synchronization information. The master extension view is identified in the data store using the name "[System.Storage]. [Master! Extension]".
(2) 타입 확장 검색 뷰(Typed Extension Search Views)(2) Typed Extension Search Views
각각의 확장 타입은 또한 검색 뷰를 갖는다. 마스터 확장 뷰와 유사하지만, 이 뷰는 또한 _Extension 칼럼을 통하여 아이템 객체에의 액세스를 제공한다. 각각의 타입 확장 검색 뷰는 이름 [schemaName].[Extension!extensionTypeName]을 이용하여 데이터 스토어 내에서 식별된다. 예를 들면, [AcmeCorp.Doc].[Extension!OfficeDocExt].Each type of extension also has a search view. Similar to the master extension view, this view also provides access to the item object through the _Extension column. Each type extension search view is identified in the data store using the name [schemaName]. [ Extension ! ExtensionTypeName]. For example, [AcmeCorp.Doc]. [Extension! OfficeDocExt].
c) 네스트된 엘리먼트(Nested Elements)c) Nested Elements
모든 네스트된 엘리먼트들은 아이템, 확장 또는 관계 인스턴스들 내에 저장된다. 그러므로, 그것들은 적당한 아이템, 확장, 또는 관계 검색 뷰를 쿼리함으로써 액세스된다.All nested elements are stored in item, extension, or relationship instances. Therefore, they are accessed by querying the appropriate item, extension, or relationship search view.
d) 관계(Relationships)d) Relationships
위에서 논의한 바와 같이, 관계들은 저장 플랫폼 데이터 스토어 내의 아이템들 간의 연결의 기본적인 단위를 형성한다.As discussed above, relationships form the basic unit of connection between items in a storage platform data store.
(1) 마스터 관계 검색 뷰(1) Master Relationship Search View
각각의 데이터 스토어는 마스터 관계 뷰(Master Relationship View)를 제공한다. 이 뷰는 데이터 스토어 내의 모든 관계 인스턴스들에 관한 정보를 제공한다. 마스터 관계 뷰는 이름 "[System.Storage].[Master!Relationship]"을 이용하여 데이터 스토어 내에서 식별된다.Each data store provides a Master Relationship View. This view provides information about all relationship instances in the data store. The master relationship view is identified in the data store using the name "[System.Storage]. [Master! Relationship]".
(2) 관계 인스턴스 검색 뷰(2) relationship instance search view
각각의 선언된 관계는 또한 특정 관계의 모든 인스턴스들을 반환하는 검색 뷰를 갖는다. 마스터 관계 뷰와 유사하지만, 이 뷰는 또한 관계 데이터의 각각의 속성에 대한 명명된 칼럼들을 제공한다. 각각의 관계 인스턴스 검색 뷰는 이름 [schemaName].[Relationship!relationshipName]을 이용하여 데이터 스토어 내에서 식별된다. 예를 들면, [AcmeCorp.Doc].[Relationship!DocumentAuthor].Each declared relationship also has a search view that returns all instances of that particular relationship. Similar to the master relationship view, this view also provides named columns for each attribute of the relationship data. Each relationship instance search view is identified within the data store using the name [schemaName]. [ Relationship ! RelationshipName ]. For example, [AcmeCorp.Doc]. [Relationship! DocumentAuthor].
e)e)
9. 업데이트9. Update
저장 플랫폼 데이터 스토어 내의 모든 뷰들은 읽기 전용이다. 데이터 모델 엘리먼트(아이템, 확장 또는 관계)의 새로운 인스턴스를 생성하거나, 또는 기존의 인스턴스를 업데이트하기 위하여, 저장 플랫폼 API의 ProcessOperation 또는 ProcessUpdategram 메서드들이 이용되어야 한다. ProcessOperation 메서드는 수행될 액션을 상술(detail)하는 "연산"(operation)을 소비하는 데이터 스토어에 의해 정의된 단일의 저장된 프로시저(procedure)이다. ProcessUpdategram 메서드는 수행될 액션들의 세트를 집합적으로 상술하는 "updategram"이라고 알려진, 연산들의 순서화된 세트를 취하는 저장된 프로시저이다.All views in the storage platform data store are read only. To create a new instance of a data model element (item, extension, or relationship), or update an existing instance, the ProcessOperation or ProcessUpdategram methods of the storage platform API must be used. The ProcessOperation method is a single stored procedure defined by a data store that consumes an "operation" that details the action to be performed. The ProcessUpdategram method is a stored procedure that takes an ordered set of operations, known as an "updategram", which collectively specifies the set of actions to be performed.
연산 포맷(operation format)은 확장 가능하고 스키마 엘리먼트들에 대하여 갖가지 연산들을 제공한다. 몇 가지의 공통 연산들은 다음을 포함한다:The operation format is extensible and provides various operations on schema elements. Some common operations include:
1. 아이템 연산:1. Item operation:
a. CreateItem(임베딩 또는 홀딩 관계의 컨텍스트에서 새로운 아이템을 생성함)a. CreateItem (creates a new item in the context of an embedding or holding relationship)
b. UpdateItem(기존의 아이템을 업데이트함)b. UpdateItem (updates an existing item)
2. 관계 연산:2. Relational operation:
a. CreateRelationship(참조 또는 홀딩 관계의 인스턴스를 생성함)a. CreateRelationship (creates an instance of a reference or holding relationship)
b. UpdateRelationship(관계 인스턴스를 업데이트함)b. UpdateRelationship (updates a relationship instance)
c. DeleteRelationship(관계 인스턴스를 제거함)c. DeleteRelationship (removes a relationship instance)
3. 확장 연산:3. Extended operation:
a. CreateExtension(기존의 아이템에 확장을 부가함)a. CreateExtension (adds an extension to an existing item)
b. UpdateExtension(기존의 확장을 업데이트함)b. UpdateExtension (updates an existing extension)
c. DeleteExtension(확장을 삭제함)c. DeleteExtension (removes an extension)
10. 변경 추적 및 툼스톤(Change Tracking & Tombstones)10. Change Tracking & Tombstones
아래에서 더 상세히 논의되는 바와 같이, 데이터 스토어에 의해 변경 추적 및 툼스톤 서비스들이 제공된다. 이 섹션은 데이터 스토어에서 노출된 변경 추적 정보에 대한 개요를 제공한다.As discussed in more detail below, change tracking and tombstone services are provided by the data store. This section provides an overview of the change tracking information exposed in the data store.
a) 변경 추적a) change tracking
데이터 스토어에 의해 제공된 각각의 검색 뷰는 변경 추적 정보를 제공하기 위해 사용되는 칼럼들을 저장하고, 이 칼럼들은 모든 아이템, 확장 및 검색 뷰에 걸쳐서 공통이다. 스키마 설계자들에 의해 명시적으로 정의된, 저장 플랫폼 스키마 뷰들은 변경 추적 정보를 자동으로 제공하지 않는다 - 그러한 정보는 뷰 자체가 구축되어 있는 검색 뷰들을 통하여 간접적으로 제공된다.Each search view provided by the data store stores columns used to provide change tracking information, which are common across all item, extension, and search views. Storage platform schema views, explicitly defined by schema designers, do not automatically provide change tracking information-such information is provided indirectly through the search views in which the view itself is built.
데이터 스토어 내의 각각의 엘리먼트에 대하여, 변경 추적 정보는 두 곳 - "마스터" 엘리먼트 뷰 및 "타입"(typed) 엘리먼트 뷰로부터 얻을 수 있다. 예를 들면, AcmeCorp.Document.Document 아이템 타입에 관한 변경 추적 정보는 마스터 아이템 뷰 "[System.Storage].[Master!Item]" 및 타입 아이템 검색 뷰 [AcmeCorp.Document].[Document]로부터 얻을 수 있다.For each element in the data store, change tracking information can be obtained from two places-the "master" element view and the "typed" element view. For example, change tracking information for the AcmeCorp.Document.Document item type can be obtained from the master item view "[System.Storage]. [Master! Item]" and the type item search view [AcmeCorp.Document]. [Document]. have.
(1) "마스터" 검색 뷰에서의 변경 추적(1) Change tracking in the "master" search view
마스터 검색 뷰들 내의 변경 추적 정보는 엘리먼트의 생성 및 업데이트 버전들에 관한 정보, 어느 동기 파트너(sync partner)가 그 엘리먼트를 생성하였는지, 어느 동기 파트너가 마지막으로 그 엘리먼트를 업데이트하였는지 및 생성 및 변경을 위한 각각의 파트너로부터의 버전 번호들에 관한 정보를 제공한다. (아래에서 설명되는) 동기 관계들 내의 파트너들은 파트너 키(partner key)에 의해 식별된다. [System.Storage.Store].ChangeTrackingInfo 타입의 _ChangeTrackingInfo라고 명명된 단일 UDT 객체는 모든 이런 정보를 포함한다. 이 타입은 System.Storage 스키마에서 정의된다. _ChangeTrackingInfo는 아이템, 확장 및 관계에 대한 모든 글로벌 검색 뷰들에서 얻을 수 있다. ChangeTrackingInfo의 타입 정의는 다음과 같다:The change tracking information in the master search views includes information about the creation and update versions of the element, which sync partner created the element, which sync partner last updated the element, and for creation and modification. Provides information about the version numbers from each partner. Partners in synchronization relationships (described below) are identified by partner key. A single UDT object named _ChangeTrackingInfo of type [System.Storage.Store] .ChangeTrackingInfo contains all this information. This type is defined in the System.Storage schema. _ChangeTrackingInfo can be obtained from all global search views for items, extensions and relationships. The type definition for ChangeTrackingInfo is as follows:
이들 속성은 다음의 정보를 포함한다:These attributes include the following information:
(2) "타입" 검색 뷰에서의 변경 추적(2) Change tracking in "type" search views
글로벌 검색 뷰로서 동일한 정보를 제공하는 것 외에, 각각의 타입 검색 뷰는 동기 토폴로지(sync topology)에서의 각각의 엘리먼트의 동기 상태를 기록하는 부가적인 정보를 제공한다.In addition to providing the same information as the global search view, each type search view provides additional information that records the synchronization status of each element in the sync topology.
b) 툼스톤b) tombstone
데이터 스토어는 아이템, 확장 및 관계에 대한 툼스톤 정보를 제공한다. 툼스톤 뷰들은 한 곳에서의 라이브(live) 및 툼스톤(tombstoned) 엔티티들(아이템, 확장 및 관계들)에 관한 정보를 제공한다. 아이템 및 확장 툼스톤 뷰들은 대응하는 객체에의 액세스를 제공하지 않는 반면, 관계 툼스톤 뷰는 관계 객체에의 액세스를 제공한다(이 관계 객체는 툼스톤 관계의 경우에 NULL이다).The data store provides tombstone information about items, extensions, and relationships. Tombstone views provide information about live and tombstoned entities (items, extensions and relationships) in one place. Item and extended tombstone views do not provide access to the corresponding object, while relationship tombstone views provide access to the relationship object (this relationship object is NULL in the case of a tombstone relationship).
(1) 아이템 툼스톤(1) Item Tombstone
아이템 툼스톤들은 뷰 [System.Storage].[Tombstone!Item]을 통하여 시스템으로부터 검색된다.Item tombstones are retrieved from the system via the view [System.Storage]. [Tombstone! Item].
(2) 확장 툼스톤(2) Extended Tombstone
확장 툼스톤들은 뷰 [System.Storage].[Tombstone!Extension]을 사용하여 시스템으로부터 검색된다. 확장 변경 추적 정보는 ExtensionId 속성의 부가와 함께 아이템들에 대해 제공된 것과 유사하다.Extension tombstones are retrieved from the system using the view [System.Storage]. [Tombstone! Extension]. Extension change tracking information is similar to that provided for items with the addition of the ExtensionId attribute.
(3) 관계 툼스톤(3) relationship tombstone
관계 툼스톤들은 뷰 [System.Storage].[Tombstone!Relationship]을 통하여 시스템으로부터 검색된다. 관계 툼스톤 정보는 확장들에 대해 제공된 것과 유사하다. 그러나, 관계 인스턴스의 타깃 ItemRef에 대한 부가적인 정보가 제공된다. 게다가, 관계 객체도 선택된다.Relation tombstones are retrieved from the system through the view [System. Storage]. [Tombstone! Relation]. The relationship tombstone information is similar to that provided for the extensions. However, additional information is provided about the target ItemRef of the relationship instance. In addition, relation objects are also selected.
(4) 툼스톤 클린업(Tombstone Cleanup)(4) Tombstone Cleanup
툼스톤 정보의 무한 성장을 막기 위하여, 데이터 스토어는 툼스톤 클린업 태스크를 제공한다. 이 태스크는 툼스톤 정보가 폐기될 수 있는 때를 결정한다. 이 태스크는 로컬 생성/업데이트 버전에 대한 경계(bound)를 계산한 다음 모든 이전의 툼스톤 버전들을 폐기함으로써 툼스톤 정보를 절단한다(truncate).To prevent the infinite growth of tombstone information, the data store provides a tombstone cleanup task. This task determines when tombstone information can be discarded. This task truncates the tombstone information by calculating the bounds for the locally generated / updated version and then discarding all previous tombstone versions.
11. 도우미 API 및 함수(Helper APIs and Functions)11.Helper APIs and Functions
베이스 매핑은 또한 다수의 도우미 함수들을 제공한다. 이들 함수는 데이터 모델에 대한 공통의 연산들을 돕기 위하여 제공된다.Base mapping also provides a number of helper functions. These functions are provided to help with common operations on the data model.
a) 함수 [System.Storage].GetItema) function [System.Storage] .GetItem
ItemId가 주어질 경우 아이템 객체를 반환한다Returns an Item object given the ItemId.
////
Item GetItem(ItemId ItemId)Item GetItem (ItemId ItemId)
b) 함수 [System.Storage].GetExtensionb) function [System.Storage] .GetExtension
//ItemId 및 ExtensionId가 주어질 경우 확장 객체를 반환한다// Return the extension object if ItemId and ExtensionId are given.
////
Extension GetExtension(ItemId ItemId, ExtensionId ExtensionId)Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId)
c) 함수 [System.Storage].GetRelationshipc) function [System.Storage] .GetRelationship
//ItemId 및 RelationshipId가 주어질 경우 관계 객체를 반환한다// Return relation object if ItemId and RelationshipId are given
////
Relationship GetRelationship(ItemId ItemId, RelationshipId RelationshipId)Relationship GetRelationship (ItemId ItemId, RelationshipId RelationshipId)
12. 메타데이터(Metadata)12. Metadata
스토어 내에서 표현되는 2 가지 타입의 메타데이터가 있다: 인스턴스 메타데이터(아이템의 타입 등), 및 타입 메타데이터.There are two types of metadata represented within the store: instance metadata (such as the type of item), and type metadata.
a) 스키마 메타데이터a) schema metadata
스키마 메타데이터는 메타 스카마로부터의 아이템 타입들의 인스턴스들로서 데이터 스토어 내에 저장된다.Schema metadata is stored in the data store as instances of item types from the meta schema.
b) 인스턴스 메타데이터b) instance metadata
인스턴스 메타데이터는 아이템의 타입을 쿼리하기 위해 애플리케이션에 의해 사용되고 아이템과 관련된 확장들을 찾는다. 아이템에 대한 ItemId가 주어질 경우, 애플리케이션은 아이템의 타입을 반환하는 글로벌 아이템 뷰를 쿼리하고 이 값을 이용하여 아이템의 선언된 타입에 대한 정보를 반환하는 Meta.Type 뷰를 쿼리할 수 있다. 예를 들면,The instance metadata is used by the application to query the type of the item and finds extensions associated with the item. Given an ItemId for an item, the application can query the global item view that returns the item's type and use this value to query the Meta.Type view that returns information about the item's declared type. For example,
E. 보안E. Security
일반적으로, 모든 보안 가능한 객체들(securable objects)은 도 26에 도시된 액세스 마스크 포맷을 이용하여 그들의 액세스 권리들을 배열한다. 이 포맷에서, 하위 16 비트는 객체 특정 액세스 권리에 대한 것이고, 다음 7 비트는 대부분의 객체 타입들에 적용되는 표준 액세스 권리에 대한 것이고, 4개의 상위 비트는 각각의 객체 타입이 표준 및 객체 특정 권리들의 세트에 매핑할 수 있는 일반적 액세스 권리들(generic access rights)을 특정하기 위해 사용된다. ACCESS_SYSTEM_SECURITY 비트는 객체의 SACL에 액세스할 권리에 대응한다.In general, all securable objects arrange their access rights using the access mask format shown in FIG. In this format, the lower 16 bits are for object specific access rights, the next 7 bits are for standard access rights that apply to most object types, and the four upper bits are for each object type for standard and object specific rights. It is used to specify generic access rights that can be mapped to a set of these. The ACCESS_SYSTEM_SECURITY bit corresponds to the right to access the SACL of the object.
도 26의 액세스 마스크 구조에서, 아이템 특정 권리들은 객체 특정 권리(Object Specific Rights) 섹션에 배치된다(하위 16비트). 본 실시예에서는, 저장 플랫폼이 보안 관리를 위해 2 세트의 API들 - Win32 및 저장 플랫폼 API를 노출시키기 때문에, 저장 플랫폼 객체 특정 권리들의 설계에 동기를 주기 위해 파일 시스템 객체 특정 권리들이 고려되어야 한다.In the access mask structure of FIG. 26, item specific rights are placed in the Object Specific Rights section (lower 16 bits). In this embodiment, since the storage platform exposes two sets of APIs-Win32 and the storage platform API for security management, file system object specific rights must be considered to motivate the design of storage platform object specific rights.
본 발명의 저장 플랫폼에 대한 보안 모델은 본 명세서의 앞에서 참고로 통합된 관련 출원들에 상세히 설명되어 있다. 이와 관련하여, 도 27(부분 a, b, 및 c)은 보안 모델의 일 실시예에 따라서, 기존의 보안 영역으로부터 새로운 동일하게 보호되는 보안 영역이 만들어지는 것을 도시한다.The security model for the storage platform of the present invention is described in detail in the related applications incorporated herein by reference. In this regard, Figure 27 (parts a, b, and c) illustrates that a new equally protected security zone is created from an existing security zone, according to one embodiment of the security model.
F. 통지 및 변경 추적F. Notice and Change Tracking
본 발명의 다른 양태에 따르면, 저장 플랫폼은 애플리케이션들이 데이터 변경을 추적하도록 허용하는 통지 능력(notifications capability)을 제공한다. 이 특징은 주로 휘발성 상태를 유지하거나 데이터 변경 이벤트에 대한 비즈니스 로직을 실행하는 애플리케이션들을 위하여 의도되어 있다. 애플리케이션들은 아이템, 아이템 확장 및 아이템 관계에 대한 통지들을 등록한다. 통지들은 데이터 변경들이 행해진 후에 비동기적으로 전달된다. 에플리케이션들은 아이템, 확장 및 관계 타입뿐만 아니라 동작 타입에 의해서 통지들을 필터링할 수 있다.According to another aspect of the present invention, the storage platform provides notifications capability that allows applications to track data changes. This feature is primarily intended for applications that remain volatile or execute business logic on data change events. Applications register for notifications about items, item extensions, and item relationships. Notifications are delivered asynchronously after data changes are made. Applications can filter notifications by action type as well as item, extension and relationship type.
일 실시예에 따르면, 저장 플랫폼 API(322)는 통지를 위해 2종류의 인터페이스들을 제공한다. 첫째로, 애플리케이션들은 아이템, 아이템 확장 및 아이템 관계들에 대한 변경들에 의해 트리거된 단순 데이터 변경 이벤트들을 등록한다. 둘째로, 애플리케이션들은 아이템, 아이템 확장 및 아이템들 간의 관계들의 세트들을 모니터하기 위해 "워처"(watcher) 객체들을 생성한다. 워처 객체의 상태는 저장될 수 있고 시스템 장애 후에 또는 시스템이 연장된 시간 기간 동안 오프라인으로 된 후에 재생성될 수 있다. 단일 통지가 다수의 업데이트들을 반영할 수도 있다.According to one embodiment,
이 기능에 관한 부가적인 상세는 본 명세서의 앞에서 참고로 통합된 관련 출원들에서 찾을 수 있다.Additional details regarding this function may be found in the related applications incorporated herein by reference.
G. 전통적 파일 시스템 상호 운용성G. Traditional File System Interoperability
위에서 언급한 바와 같이, 본 발명의 저장 플랫폼은, 적어도 일부 실시예들에서, 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템의 필수적인 부분으로서 구현되도록 의도되어 있다. 예를 들면, 본 발명의 저장 플랫폼은 마이크로소프트 윈도즈 계열 운영 시스템들과 같은 운영 시스템의 필수적인 부분으로서 구현될 수 있다. 그 입장에서, 저장 플랫폼 API는 운영 시스템 API들의 일부가 되고 그를 통하여 애플리케이션 프로그램들이 운영 시스템과 상호 작용한다. 따라서, 저장 플랫폼은 애플리케이션 프로그램들이 운영 시스템 상에 정보를 저장하는 수단이 되고, 그러므로 저장 플랫폼의 아이템 기반 데이터 모델은 그러한 운영 시스템의 전통적 파일 시스템을 대체한다. 예를 들면, 마이크로소프트 윈도즈 계열 운영 시스템들에서 구현될 때, 저장 플랫폼은 그 운영 시스템에서 구현된 NFTS 파일 시스템을 대체할 수 있다. 현재, 애플리케이션 프로그램들은 윈도즈 계열 운영 시스템에 의해 노출된 Win32 API들을 통하여 NTFS 파일 시스템의 서비스들에 액세스한다.As mentioned above, the storage platform of the present invention is, in at least some embodiments, intended to be implemented as an integral part of the hardware / software interface system of a computer system. For example, the storage platform of the present invention may be implemented as an integral part of an operating system, such as Microsoft Windows family operating systems. From that point on, the storage platform API becomes part of the operating system APIs through which application programs interact with the operating system. Thus, the storage platform is the means by which application programs store information on the operating system, and therefore the item-based data model of the storage platform replaces the traditional file system of such operating system. For example, when implemented in Microsoft Windows family operating systems, the storage platform can replace the NFTS file system implemented in that operating system. Currently, application programs access the services of the NTFS file system through the Win32 APIs exposed by the Windows family of operating systems.
그러나, 본 발명의 저장 플랫폼으로 NTFS 파일 시스템을 완전히 대체하려면 기존의 Win32 기반 애플리케이션 프로그램들의 재코딩(recoding)이 필요할 것이고 그러한 재코딩은 바람직하지 않을 것임을 인지하면, 본 발명의 저장 플랫폼이 NTFS와 같은 기존의 파일 시스템들과의 상호 운용성을 제공하는 것이 유익할 것이다. 그러므로, 본 발명의 일 실시예에서, 저장 플랫폼은 Win32 프로그래밍 모델에 의지하는 애플리케이션 프로그램들이 저장 플랫폼의 데이터 스토어뿐만 아니라 전통적인 NTFS 파일 시스템의 콘텐츠에 액세스할 수 있게 한다. 이 때문에, 저장 플랫폼은 용이한 상호 운용성을 돕기 위하여 Win32 명명 규칙의 슈퍼세트인 명명 규칙을 사용한다. 또한, 저장 플랫폼은 Win32 API를 통하여 저장 플랫폼에 저장된 파일들 및 디렉토리들에 액세스하는 것을 지원한다.However, recognizing that a complete replacement of the NTFS file system with the storage platform of the present invention will require recoding of existing Win32-based application programs, and such recoding would be undesirable. It would be beneficial to provide interoperability with existing file systems. Therefore, in one embodiment of the present invention, the storage platform allows application programs that rely on the Win32 programming model to access the contents of the traditional NTFS file system as well as the data store of the storage platform. Because of this, the storage platform uses a naming convention that is a superset of the Win32 naming convention to facilitate easy interoperability. The storage platform also supports accessing files and directories stored on the storage platform through the Win32 API.
이 기능의 부가적인 상세는 본 명세서의 앞에서 참고로 통합된 관련 출원들에서 얻을 수 있다.Additional details of this functionality can be obtained from the related applications incorporated herein by reference.
H. 저장 플랫폼 APIH. Storage Platform API
저장 플랫폼은 애플리케이션 프로그램들이 위에서 논의된 저장 플랫폼의 특징들 및 능력들에 액세스할 수 있게 하고 또한 데이터 스토어에 저장된 아이템들에 액세스할 수 있게 하는 API를 포함한다. 이 섹션은 본 발명의 저장 플랫폼의 저장 플랫폼 API의 일 실시예를 설명한다. 이 기능에 관한 상세는 본 명세서의 앞에서 참고로 통합된 관련 출원들에서 얻을 수 있고, 편의를 위하여 이 정보의 일부가 아래에 요약되어 있다.The storage platform includes an API that allows application programs to access the features and capabilities of the storage platform discussed above and also to access items stored in the data store. This section describes one embodiment of the storage platform API of the storage platform of the present invention. Details regarding this function can be obtained from related applications incorporated by reference earlier in this specification, and some of this information is summarized below for convenience.
도 18을 참조하면, 컨테인먼트 폴더(Containment Folder)는 다른 아이템들에 대한 홀딩 관계를 포함하는 아이템이고 파일 시스템 폴더의 공통 개념의 등가물이다. 각각의 아이템은 적어도 하나의 컨테인먼트 폴더 내에 "포함"(contained)된다.Referring to FIG. 18, atainment folder is an item including a holding relationship to other items and is an equivalent of a common concept of a file system folder. Each item is "contained" in at least one containment folder.
도 19는 본 발명에 따라, 저장 플랫폼 API의 기본 아키텍처를 예시한다. 저장 플랫폼 API는 로컬 데이터 스토어(302)와 이야기하기 위해 SQLClient(1900)를 이용하고 또한 원격 데이터 스토어(예를 들면 데이터 스토어(340))와 이야기하기 위해 SQLClient(1900)를 이용할 수도 있다. 로컬 스토어(302)는 또한 DQP(Distributed Query Processor)를 이용하거나 또는 위에서 설명한 저장 플랫폼 동기화 서비스("Sync")를 통하여 원격 데이터 스토어(340)와 이야기할 수도 있다. 저장 플랫폼 API(322)는 또한, 위에서도 설명한 바와 같이, 데이터 스토어 통지를 위한 브리지 API로 기능하여, 애플리케이션의 가입들(subscriptions)을 통지 엔진(332)에 전달하고 통지들을 애플리케이션(예를 들면, 애플리케이션들(350a, 350b, 또는 350c))에 라우팅한다. 일 실시예에서, 저장 플랫폼 API(322)는 또한 Microsoft Exchange 및 AD 내의 데이터에 액세스할 수 있도록 제한된 "제공자"(provider) 아키텍처를 정의할 수도 있다.19 illustrates the basic architecture of a storage platform API, in accordance with the present invention. The storage platform API may use SQLClient 1900 to talk to the
도 20은 저장 플랫폼 API의 여러 컴포넌트들을 개략적으로 나타낸다. 저장 플랫폼 API는 다음의 컴포넌트들로 이루어진다: 저장 플랫폼 엘리먼트 및 아이템 타입들을 나타내는 데이터 클래스들(2002); (2) 객체 지속성(object persistence)을 관리하고 지원 클래스들(2006)을 제공하는 런타임 프레임워크(2004); 및 (3) 저장 플랫폼 스키마들로부터 CLR 클래스들을 생성하기 위해 이용되는 도구들(2008).20 schematically illustrates various components of a storage platform API. The storage platform API consists of the following components: data classes 2002 representing storage platform element and item types; (2) a runtime framework 2004 that manages object persistence and provides
주어진 스키마로부터 생기는 클래스들의 계층 구성은 해당 스키마 내의 타입들의 계층 구성을 직접 반영한다. 일례로서, 도 21A 및 도 21B에 도시된 바와 같이 Contacts 스키마에서 정의된 아이템 타입들을 고려해보자.The hierarchy of classes resulting from a given schema directly reflects the hierarchy of types in that schema. As an example, consider item types defined in the Contacts schema as shown in FIGS. 21A and 21B.
도 22는 동작 중인 런타임 프레임워크를 예시한다. 런타임 프레임워크는 다음과 같이 동작한다:22 illustrates a runtime framework in operation. The runtime framework works as follows:
1. 애플리케이션(350a, 350b, 또는 350c)이 저장 플랫폼 내의 아이템에 바인딩한다.1. The application 350a, 350b, or 350c binds to an item in the storage platform.
2. 프레임워크(2004)는 바인딩된 아이템에 대응하는 ItemContext 객체(2202)를 생성하고 그것을 애플리케이션에 반환한다.2. The framework 2004 creates an
3. 애플리케이션은 이 ItemContext 상에 Find를 제시하여 아이템들의 컬렉션(collection)을 수취한다; 반환된 컬렉션은 개념적으로 (관계들에 기인하는) 객체 그래프(2204)이다.3. The application presents a Find on this ItemContext to receive a collection of items; The returned collection is conceptually an object graph 2204 (due to relationships).
4. 애플리케이션은 데이터를 변경, 삭제, 및 삽입한다.4. The application changes, deletes, and inserts data.
5. 애플리케이션은 Update() 메서드를 호출함으로써 변경들을 저장(save)한다.5. The application saves the changes by calling the Update () method.
도 23은 "FindAll" 동작의 실행을 예시한다.23 illustrates execution of the "FindAll" operation.
도 24는 저장 플랫폼 스키마로부터 저장 플랫폼 API 클래스들이 생성되는 프로세스를 예시한다.24 illustrates a process in which storage platform API classes are generated from a storage platform schema.
도 25는 파일 API가 기초하고 있는 스키마를 예시한다. 저장 플랫폼 API는 파일 객체들을 취급하기 위한 네임스페이스를 포함한다. 이 네임스페이스는 System.Storage.Files라고 불린다. System.Storage.Files 내의 클래스들의 데이터 멤버들은 저장 플랫폼 스토어에 저장된 정보를 직접 반영한다; 이 정보는 파일 시스템 객체들로부터 "프로모트(promote)"되거나 또는 Win32 API를 사용하여 본래부터 생성될 수 있다. System.Storage.Files 네임스페이스는 2개의 클래스를 갖는다: FileItem 및 DirectoryItem. 이들 클래스의 멤버들 및 그것들의 메서드들은 도 25의 스키마 도면을 봄으로써 쉽게 추측된다. FileItem 및 DirectoryItem은 저장 플랫폼 API로부터 읽기 전용이다. 그것들을 수정하기 위해서는, Win32 API 또는 System.IO 내의 클래스들을 사용해야 한다.25 illustrates the schema on which the File API is based. The storage platform API includes a namespace for handling file objects. This namespace is called System.Storage.Files. The data members of the classes in System.Storage.Files directly reflect the information stored in the storage platform store; This information can be "promoted" from file system objects or inherently generated using the Win32 API. The System.Storage.Files namespace has two classes: FileItem and DirectoryItem. Members of these classes and their methods are easily inferred by looking at the schema diagram of FIG. FileItem and DirectoryItem are read-only from the storage platform API. To modify them, you must use the classes in the Win32 API or System.IO.
API들과 관련하여, 프로그래밍 인터페이스(또는 더 간단히 말해서, 인터페이스)는 하나 이상의 코드 세그먼트(들)가 하나 이상의 다른 코드 세그먼트(들)에 의해 제공된 기능과 통신하거나 그 기능에 액세스할 수 있게 하기 위한 임의의 메커니즘, 프로세스, 프로토콜로 간주될 수 있다. 다르게는, 프로그래밍 인터페이스는 시스템의 다른 컴포넌트(들)의 하나 이상의 메커니즘(들), 메서드(들), 함수 호출(들), 모듈(들) 등에 통신 결합가능한 시스템의 컴포넌트의 하나 이상의 메커니즘(들), 메서드(들), 함수 호출(들), 모듈(들), 객체(들) 등으로 간주될 수 있다. 바로 앞의 문장에서 "코드 세그먼트"(segment of code)라는 용어는, 적용된 용어에 상관없이 또는 코드 세그먼트들이 따로따로 컴파일되든 아니든, 또는 코드 세그먼트들이 소스, 중간 혹은 객체 코드로서 제공되든, 코드 세그먼트들이 런타임 시스템 또는 프로세스에서 이용되든 아니든, 또는 그것들이 동일한 머신 상에 있든 서로 다른 머신들 상에 있든 또는 다수의 머신들에 걸쳐서 분산되어 있든, 또는 코드 세그먼트들에 의해 표현되는 기능이 전적으로 소프트웨어로 구현되든, 전적으로 하드웨어로 구현되든, 또는 하드웨어와 소프트웨어의 조합으로 구현되든 상관없이, 코드의 하나 이상의 명령 또는 라인들을 포함하도록 의도되어 있고, 예를 들면, 코드 모듈들, 객체들, 서브루틴들, 함수들 등을 포함한다.In the context of APIs, a programming interface (or more simply, an interface) is any means for enabling one or more code segment (s) to communicate with or access a function provided by one or more other code segment (s). Can be considered as a mechanism, process, or protocol. Alternatively, the programming interface may be one or more mechanism (s) of components of the system that are communicatively coupled to one or more mechanism (s), method (s), function call (s), module (s), etc., of other component (s) of the system. , Method (s), function call (s), module (s), object (s), and so forth. In the preceding sentence, the term "segment of code" means that the code segments may be used regardless of the applied term or whether the code segments are compiled separately or whether the code segments are provided as source, intermediate or object code. Whether used in a runtime system or process, or whether they are on the same machine, on different machines, or distributed across multiple machines, or whether the functionality represented by code segments is implemented entirely in software It is intended to include one or more instructions or lines of code, whether implemented entirely in hardware or in a combination of hardware and software, for example, code modules, objects, subroutines, functions And the like.
관념적으로, 프로그래밍 인터페이스는 도 30A 또는 도 30A에 도시된 바와 같이, 포괄적으로 생각될 수 있다. 도 30A는 시스템의 제1 및 제2 코드 세그먼트들이 통신하는 도관(conduit)으로서 인터페이스 Interface1을 예시한다. 도 30B는 시스템의 제1 및 제2 세그먼트들이 매체 M을 통하여 통신할 수 있게 하는 인터페이스 객체들 I1 및 I2(제1 및 제2 코드 세그먼트들의 파트일 수도 아닐 수도 있음)을 포함하는 것으로 인터페이스를 예시한다. 도 30B의 보기에서는, 인터페이스 객체들 I1 및 I2를 동일 시스템의 별개의 인터페이스들로 생각할 수도 있고 객체들 I1 및 I2에 매체 M을 더한 것이 인터페이스를 구성하는 것을 생각할 수도 있다. 도 30A 및 30B는 양방향 흐름 및 그 흐름의 양쪽에서의 인터페이스를 보여주지만, 어떤 구현들은 한 방향으로의 정보 흐름만을 갖거나(또는 아래에서 설명하는 바와 같이 아무런 정보 흐름도 없거나) 한 쪽에 하나의 인터페이스 객체만을 가질 수 있다. 제한이 아니라 예로서, 애플리케이션 프로그래밍 인터페이스(API), 엔트리 포인트(entry point), 메서드, 함수, 서브루틴, 원격 프로시저 호출(remote procedure call), 및 컴포넌트 객체 모델(COM: component object model) 인터페이스와 같은 용어들이 프로그래밍 인터페이스의 정의 내에서 두루 포함된다.In concept, the programming interface may be considered inclusive, as shown in FIG. 30A or 30A. 30A illustrates the interface Interface1 as a conduit through which the first and second code segments of the system communicate. 30B illustrates the interface as including interface objects I1 and I2 (which may or may not be part of the first and second code segments) that allow the first and second segments of the system to communicate over medium M. FIG. do. In the example of FIG. 30B, the interface objects I1 and I2 may be thought of as separate interfaces of the same system and the addition of the medium M to the objects I1 and I2 may constitute the interface. 30A and 30B show a bidirectional flow and an interface in both of those flows, but some implementations have only one information flow in one direction (or no information flow as described below) or one interface object on one side. You can only have Examples include, but are not limited to, application programming interfaces (APIs), entry points, methods, functions, subroutines, remote procedure calls, and component object model (COM) interfaces. The same terms are included throughout the definition of a programming interface.
그러한 프로그래밍 인터페이스의 양태들은 제1 코드 세그먼트가 제2 코드 세그먼트에 정보(여기서 "정보"는 넓은 의미로 사용되고 데이터, 커맨드, 요구(requests) 등을 포함한다)를 전송하는 메서드; 제2 코드 세그먼트가 상기 정보를 수신하게 하는 메서드; 및 상기 정보의 구조, 시퀀스, 구문, 조직, 스키마, 타이밍 및 콘텐츠를 포함할 수 있다. 이와 관련하여, 하위 전송 매체(underlying transport medium) 자체는, 그 매체가 유선이든 무선이든, 또는 양자의 조합이든, 상기 정보가 상기 인터페이스에 의해 정의된 방식으로 전송되기만 한다면, 인터페이스의 동작에 중요하지 않을 수 있다. 어떤 경우에, 정보는 종래의 의미에서 한 방향 또는 양방향으로 전달되지 않을 수도 있다. 왜냐하면 하나의 코드 세그먼트가 제2의 코드 세그먼트에 의해 수행되는 기능에 단순히 액세스하는 경우와 같이, 정보 전송은 다른 메커니즘(예를 들면, 코드 세그먼트들 간의 정보 흐름과 별도로 버퍼, 파일 등에 배치된 정보)을 통하거나 또는 존재하지 않을 수 있기 때문이다. 이들 양태들의 어느 것이든 또는 전부가 주어진 상황에서, 예를 들면 코드 세그먼트들이 느슨하게 연결된 또는 긴밀하게 연결된 구성에서 시스템의 일부인지에 따라서 중요할 수 있고, 따라서 이 리스트는 예시적이고 비제한적인 것으로 간주되어야 할 것이다.Aspects of such a programming interface include a method in which a first code segment sends information to a second code segment, where "information" is used in a broad sense and includes data, commands, requests, and the like; A method of causing a second code segment to receive the information; And the structure, sequence, syntax, organization, schema, timing, and content of the information. In this regard, the underlying transport medium itself, whether the medium is wired or wireless, or a combination of both, is not critical to the operation of the interface as long as the information is transmitted in a manner defined by the interface. You may not. In some cases, the information may not be conveyed in one or both directions in the conventional sense. Because information transfer is a different mechanism (for example, information placed in buffers, files, etc., separate from the flow of information between code segments), such as when one code segment simply accesses a function performed by a second code segment. It may or may not exist. Any or all of these aspects may be important depending on the situation given, for example, where the code segments are part of a system in a loosely connected or tightly coupled configuration, so this list should be considered as illustrative and non-limiting. something to do.
프로그래밍 인터페이스의 이 개념은 숙련된 당업자에게 공지되어 있고 본 발명의 전술한 상세한 설명으로부터 분명하다. 그러나, 프로그래밍 인터페이스를 구현하는 다른 방법들이 있고, 명백히 배제되지 않는 한, 이것들도 본 명세서의 말미에 제시된 청구항들에 의해 포함되도록 의도된다. 그런 다른 방법들은 도 30A 및 30B의 극히 단순화한 보기(views)보다 난재해거나 복잡해보일 수 있지만, 그럼에도 불구하고 그것들은 유사한 기능을 수행하여 동일한 전체 결과를 성취한다. 이제부터 프로그래밍 인터페이스의 몇몇 예시적인 대체 구현예들을 간단히 설명해보겠다.This concept of a programming interface is known to those skilled in the art and is apparent from the foregoing detailed description of the invention. However, there are other ways of implementing a programming interface, and unless expressly excluded, these are also intended to be covered by the claims set forth at the end of this specification. Such other methods may appear more difficult or complex than the extremely simplified views of FIGS. 30A and 30B, but they nevertheless perform similar functions to achieve the same overall result. We will now briefly describe some example alternative implementations of the programming interface.
팩터링(factoring) : 하나의 코드 세그먼트로부터 다른 것으로의 통신은 그 통신을 다수의 이산 통신들(discrete communications)로 분해함으로써 간접적으로 성취될 수 있다. 이것은 도 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에서와 여전히 동일하다. 인터페이스들의 팩터링은 또한 그 팩터링을 알아내기 곤란하도록 결합(associtave), 교환(commutative), 및 다른 수학적 특성들을 따를 수 있다. 이를테면, 동작들의 순서화는 중요하지 않을 수 있고, 따라서, 인터페이스에 의해 수행되는 기능은 그 인터페이스에 도달하기 훨씬 전에 코드 또는 인터페이스의 다른 피스(piece)에 의해 수행될 수 있고, 또는 시스템의 별도의 컴포넌트에 의해 수행될 수 있다. 또한, 프로그래밍 기술 분야의 통상의 기술을 가진 자라면 동일한 결과를 성취하는 다른 함수 호출들을 행하는 갖가지 방법들이 있다는 것을 알 수 있다. Factoring : Communication from one code segment to another can be accomplished indirectly by breaking down the communication into a number of discrete communications. This is shown schematically in FIGS. 31A and 31B. As shown, some interfaces may be described in terms of divisible sets of functionality. Thus, the interface functionality of FIGS. 30A and 30B can be factored to achieve the same result, as can mathematically provide 24, i.e., 2x2x3x2. Thus, as illustrated in FIG. 31A, the functionality provided by interface Interface1 may be subdivided to convert communications of that interface to multiple interfaces Interface1A, Interface1B, Interface1C, etc., but realize the same result. As illustrated in FIG. 31B, the functionality provided by interface I1 can be subdivided into multiple interfaces Ila, Ib, I1c, etc. while achieving the same result. Similarly, interface I2 of the second code segment receiving information from the first code segment may be factored into multiple interfaces I2a, I2b, I2c, and the like. When factoring, the number of interfaces included with the first code segment need not match the number of interfaces included with the second code segment. In either case of FIGS. 31A and 31B, the functional meaning of the interfaces Interface1 and I1 are still the same as in FIGS. 30A and 30B, respectively. The factoring of the interfaces may also follow associative, commutative, and other mathematical features to make the factoring difficult to figure out. For example, the ordering of operations may not be important, so that the functionality performed by an interface may be performed by code or another piece of interface long before it reaches that interface, or as a separate component of the system. It can be performed by. In addition, one of ordinary skill in the art will appreciate that there are various ways to make other function calls that achieve the same result.
재정의(Redefinition) : 일부 경우에, 프로그래밍 인터페이스의 어떤 특징들(aspects)(예를 들면, 파라미터들)을 무시하거나, 부가하거나 또는 재정의하면서도 의도된 결과를 성취하는 것이 가능할 수 있다. 이것은 도 32A 및 도 32B에 예시되어 있다. 예를 들면, 도 30A의 인터페이스 Interface1은 3개의 파라미터인 입력(input), 정밀도(precision) 및 출력(output)을 포함하고, 제1 코드 세그먼트로부터 제2 코드 세그먼트로 발행되는 호출인, 함수 호출 Square(입력, 정밀도, 출력)를 포함한다고 가정하자. 만일 중앙의 파라미터인 정밀도가, 도 32A에 도시된 바와 같이, 주어진 시나리오에서 중요하지 않다면, 그것은 무시되거나 또는 의미 없는(이 상황에서) 파라미터로 대체되는 것도 좋을 수 있다. 또한 중요하지 않은 부가적인 파라미터를 부가할 수도 있다. 어느 경우든, 입력이 제2 코드 세그먼트에 의해 제곱(square)된 후에 출력이 반환되는 한, square의 기능은 성취될 수 있다. 정밀도는 컴퓨터 시스템의 어떤 다운스크림 또는 다른 부분에게 의미 있는 파라미터일지도 모르지만, 제곱(square)을 계산하는 한정된 목적을 위해 정밀도가 필요하지 않다고 일단 인지되면, 그것은 대체되거나 무시될 수 있다. 예를 들면, 유효 정밀도 값을 전달하는 대신에, 결과에 악영향을 미치지 않으면 생일 날짜와 같은 무의미한 값이 전달될 수 있다. 마찬가지로, 도 32B에 도시된 바와 같이, 인터페이스 I1은 그 인터페이스에 파라미터들을 부가하거나 또는 무시하도록 재정의된, 인터페이스 I1'에 의해 대체된다. 인터페이스 I2는 마찬가지로 불필요한 파라미터들, 즉 다른 곳에서 처리될 수 있는 파라미터들을 무시하도록 재정의된, 인터페이스 I2'에 의해 대체될 수 있다. 여기에서 요점은 일부 경우에 프로그래밍 인터페이스가 어떤 목적을 위해 필요하지 않은, 파라미터들과 같은, 특징들을 포함할 수 있고, 따라서 그것들은 무시되거나 재정의되거나, 또는 다른 목적을 위해 다른 곳에서 처리될 수 있다는 점이다. Redefinition : In some cases, it may be possible to achieve the intended result while ignoring, adding or redefining certain aspects (eg, parameters) of the programming interface. This is illustrated in Figures 32A and 32B. For example, interface Interface1 of FIG. 30A includes a function call Square, which is a call issued from a first code segment to a second code segment, including three parameters: input, precision, and output. Suppose you include (input, precision, output). If the central parameter precision is not important in a given scenario, as shown in FIG. 32A, it may also be ignored or replaced with a meaningless (in this situation) parameter. It is also possible to add additional parameters that are not important. In either case, as long as the output is returned after the input is squared by the second code segment, the functionality of square can be achieved. Precision may be a meaningful parameter to any downstream or other portion of a computer system, but once it is recognized that precision is not needed for the limited purpose of calculating square, it may be replaced or ignored. For example, instead of passing an effective precision value, a nonsensical value, such as a birthday date, can be delivered unless it adversely affects the result. Similarly, as shown in FIG. 32B, interface I1 is replaced by interface I1 ', which has been overridden to add or ignore parameters to that interface. Interface I2 can likewise be replaced by interface I2 ', which has been overridden to ignore unnecessary parameters, i.e. parameters that can be handled elsewhere. The point here is that in some cases a programming interface may include features, such as parameters, that are not needed for some purpose, so that they may be ignored or redefined, or processed elsewhere for other purposes. Is the point.
인라인 코딩(Inline Coding) : 2개의 별개의 코드 모듈들 간의 "인터페이스"가 형태를 변경하도록 그 코드 모듈들의 기능의 일부 또는 전부를 병합하는 것도 실행할 수 있을 것이다. 예를 들면, 도 30A 및 도 30B의 기능은 각각 도 33A 및 도 33B의 기능으로 변환될 수 있다. 도 33A에서, 도 30A의 이전의 제1 및 제2 코드 세그먼트들은 그들 모두를 포함하는 하나의 모듈로 병합된다. 이 경우에, 코드 세그먼트들은 여전히 서로 통신할 수 있지만 인터페이스는 단일 모듈에 보다 적합한 형태로 적용될 수 있다. 따라서, 예를 들면, 형식적인 호출(Call) 및 반환(Return) 문장들은 더 이상 필요하지 않을 수 있지만, 인터페이스 Interface1에 따른 마찬가지의 처리 또는 응답(들)이 여전히 유효할 수 있다. 마찬가지로, 도 33B에 도시된 바와 같이, 도 30B로부터의 인터페이스 I2의 일부(또는 전부)가 인터페이스 I1에 인라인으로 기입되어 인터페이스 I1"을 형성할 수 있다. 예시된 바와 같이, 인터페이스 I2는 I2a 및 I2b로 분할되고, 인터페이스 부분 I2a는 인터페이스 I1과 함께 인라인으로 코딩되어 인터페이스 I1"을 형성하였다. 구체적인 예를 위해, 도 30B로부터의 인터페이스 I1이 함수 호출 square(입력, 출력)을 수행하는 것을 생각해보자. 여기서, 상기 함수 호출 square(입력, 출력)은 인터페이스 I2에 의해 수신되고, 이 인터페이스 I2는 제2 코드 세그먼트에 의해 입력과 함께 전달된 값을 처리(그것을 제곱(square))한 후에, 제곱된 결과를 출력과 함께 도로 전달한다. 그런 경우에, 제2 코드 세그먼트에 의해 수행되는 처리(입력을 제곱)는 인터페이스에 대한 호출 없이 제1 코드 세그먼트에 의해 수행될 수 있다. Inline Coding : It may also be possible to merge some or all of the functionality of the code modules so that the "interface" between two separate code modules changes shape. For example, the functions of FIGS. 30A and 30B may be converted to the functions of FIGS. 33A and 33B, respectively. In FIG. 33A, the previous first and second code segments of FIG. 30A are merged into one module that contains them all. In this case, the code segments can still communicate with each other but the interface can be applied in a form more suitable for a single module. Thus, for example, formal Call and Return statements may no longer be needed, but the same processing or response (s) according to interface Interface1 may still be valid. Similarly, as shown in FIG. 33B, a portion (or all) of interface I2 from FIG. 30B may be written inline to interface I1 to form interface I1 ". As illustrated, interface I2 may be represented by I2a and I2b. And interface portion I2a was coded inline with interface I1 to form interface I1 ". For a specific example, consider interface I1 from FIG. 30B performing a function call square (input, output). Here, the function call square (input, output) is received by interface I2, which interface (I2) squares the result after processing (squared it) the value passed with the input by the second code segment. And pass it along with the output. In such a case, the processing performed by the second code segment (input squared) may be performed by the first code segment without a call to the interface.
분리(Divorce) : 하나의 코드 세그먼트로부터 다른 것으로의 통신은 그 통신을 다수의 이산 통신으로 분해함으로써 성취될 수 있다. 이것은 도 34A 및 도 34B에 개략적으로 도시되어 있다. 도 34A에 도시된 바와 같이, 미들웨어의 하나 이상의 피스(들)(이것들은 원본 인터페이스로부터의 기능 및/또는 인터페이스 기능들을 분리(divorce)하므로, 분리 인터페이스(들)(Diverce Interface(s))이라 함)이 제공되어 제1 인터페이스 Interface1 상에서 통신들을 변환하여 그것들을 상이한 인터페이스, 이 경우 인터페이스들 Interface2A, Interface2B 및 Interface2C에 적합하게 한다. 이것은 예를 들면 Interface1 프로토콜에 따라서 운영 시스템과 통신하도록 설계된 애플리케이션들의 설치된 베이스가 있지만, 그 운영 시스템이 상이한 인터페이스, 이 경우에는 인터페이스들 Interface2A, Interface2B 및 Interface2C를 사용하도록 변경되는 경우에 행해질 수 있다. 요점은 제2 코드 세그먼트에 의해 사용되는 원본 인터페이스가 더 이상 제1 코드 세그먼트에 의해 사용되는 인터페이스와 호환되지 않도록 변경되고, 따라서 이전 인터페이스와 새로운 인터페이스를 호환되게 하기 위하여 매개물(intermediary)이 사용된다는 점이다. 마찬가지로, 도 34B에 도시된 바와 같이, 인터페이스 I1로부터 통신들을 수신하는 분리 인터페이스 DI1를 갖고, 예를 들면 DI2와 함께 동작하도록 재설계된 인터페이스들 I2a 및 I2b에 인터페이스 기능을 송신하는 분리 인터페이스 DI2를 갖는 제3 코드 세그먼트가 도입될 수 있지만, 동일한 기능적 결과를 제공한다. 마찬가지로, DI1 및 DI2는 함께 동작하여 도 30B의 인터페이스 I1 및 I2의 기능을 새로운 운영 시스템으로 변환하지만, 동일하거나 유사한 기능적 결과를 제공한다. Divorce : Communication from one code segment to another can be accomplished by breaking the communication into multiple discrete communications. This is shown schematically in FIGS. 34A and 34B. As shown in Figure 34A, one or more piece (s) of middleware (these are called Diverce Interface (s), since they divide functionality and / or interface functions from the original interface). ) Is provided to convert communications on the first interface Interface1 to make them suitable for different interfaces, in this case interfaces Interface2A, Interface2B and Interface2C. This can be done if, for example, there is an installed base of applications designed to communicate with the operating system according to the Interface1 protocol, but the operating system is changed to use a different interface, in this case interfaces Interface2A, Interface2B and Interface2C. The point is that the original interface used by the second code segment is no longer compatible with the interface used by the first code segment, and therefore intermediary is used to make the old and new interfaces compatible. to be. Similarly, as shown in FIG. 34B, the second interface has a separate interface DI1 that receives communications from the interface I1, and has a separate interface DI2 that transmits the interface function to interfaces I2a and I2b that have been redesigned to work with DI2, for example. Three code segments can be introduced, but provide the same functional results. Likewise, DI1 and DI2 work together to convert the functionality of interfaces I1 and I2 of FIG. 30B to a new operating system, but provide the same or similar functional results.
재기입(Rewriting) : 또 다른 가능한 변형은 인터페이스 기능을 어떤 다른 것으로 대체하면서도 동일한 전체 결과를 성취하도록 코드를 동적으로 재기입하는 것이다. 예를 들면, 중간 언어(예를 들면, 마이크로소프트 IL, Java ByteCode 등)로 제시된 코드 세그먼트가 (예컨대 .Net 프레임워크, Java 런타임 환경, 또는 다른 유사한 런타임 타입 환경들에 의해 제공된 것과 같은) 실행 환경에서 JIT(Just-in-Time) 컴파일러 또는 인터프리터로 제공되는 시스템이 존재할 수 있다. JIT 컴파일러는 제1 코드 세그먼트로부터의 통신들을 제2 코드 세그먼트로 동적으로 변환하도록, 즉 그것들을 제2 코드 세그먼트(원본 또는 상이한 제2 코드 세그먼트)에 의해 요구될 수 있는 상이한 인터페이스에 적합하게 하도록 기입될 수 있다. 이것은 도 35A 및 도 35B에 도시되어 있다. 도 35A에서 알 수 있는 바와 같이, 이 방법은 위에서 설명된 분리(Divorce) 시나리오와 유사하다. 이것은 예를 들면, 애플리케이션들의 설치된 베이스가 Interface 1 프로토콜에 따라서 운영 시스템과 통신하도록 설계되어 있지만, 운영 시스템이 상이한 인터페이스를 사용하도록 변경되는 경우에 행해질 수 있다. JIT 컴파일러는 설치된 베이스 애플리케이션들로부터의 진행중인 통신들을 운영 시스템의 새로운 인터페이스에 적합하게 하기 위해 사용될 수 있다. 도 35B에 도시된 바와 같이, 인터페이스(들)을 동적으로 재기입하는 이 방법은 또한 인터페이스(들)를 동적으로 팩터링하거나 또는 다르게 변경하기 위해 적용될 수 있다. Rewriting : Another possible variant is to dynamically rewrite the code to achieve the same overall result while replacing the interface function with something else. For example, a code segment presented in an intermediate language (eg Microsoft IL, Java ByteCode, etc.) may be an execution environment (such as provided by the .Net framework, Java runtime environment, or other similar runtime type environments). There may be a system provided as a just-in-time (JIT) compiler or interpreter. The JIT compiler writes to dynamically convert communications from the first code segment to the second code segment, ie to adapt them to the different interfaces that may be required by the second code segment (original or different second code segment). Can be. This is illustrated in Figures 35A and 35B. As can be seen in Figure 35A, this method is similar to the Divorce scenario described above. This can be done, for example, if the installed base of applications is designed to communicate with the operating system according to the
또한 대안 실시예들을 통하여 인터페이스로서 동일하거나 유사한 결과를 성취하기 위한 상술한 시나리오들은 다양한 방법으로, 직렬로 및/또는 병렬로, 또는 다른 중재 코드에 의해 조합될 수도 있다는 것에 주목해야 할 것이다. 따라서, 위에서 제시된 대안 실시예들은 상호 배타적이지 않고 도 30A 및 도 30B에서 제시된 일반적 시나리오들과 동일하거나 동등한 시나리오들을 생성하도록 혼합되고, 매칭되고, 결합될 수 있다. 또한, 대부분의 프로그래밍 구성들에서와 같이, 여기에서 설명되어 있지 않지만, 그럼에도 불구하고 본 발명의 사상 및 범위에 의해 표현되는 인터페이스의 동일하거나 유사한 기능을 성취하는 다른 유사한 방법들이 있다는 것에 주목한다. 즉, 그것은 적어도 부분적으로 인터페이스의 값의 아래에 있는 인터페이스에 의해 표현되는 기능, 및 인터페이스의 값의 아래에 있는 인터페이스에 의해 가능하게 되는 유리한 결과들이라는 것에 주목한다.It should also be noted that the above-described scenarios for achieving the same or similar result as an interface through alternative embodiments may be combined in various ways, serially and / or in parallel, or by other arbitration code. Thus, the alternative embodiments presented above may be mixed, matched, and combined to create scenarios that are the same or equivalent to the general scenarios shown in FIGS. 30A and 30B and are not mutually exclusive. It is also noted that, as in most programming configurations, there are other similar ways to achieve the same or similar functionality of the interface, which is not described herein, but is nevertheless represented by the spirit and scope of the present invention. That is, it is noted that it is the functions represented by the interface that are at least partially below the value of the interface, and the advantageous results made possible by the interface below the value of the interface.
Ⅲ. 동기화 APIIII. Sync API
아이템 기반 하드웨어/소프트웨어 인터페이스 시스템에서는 동기화에 대한 여러가지 접근법들이 가능하다. 섹션 A는 본 발명의 여러가지 실시예들을 개시하고, 섹션 B는 동기화용 API의 여러가지 실시예들에 초점을 맞추고 있다.In an item based hardware / software interface system, several approaches to synchronization are possible. Section A discloses various embodiments of the present invention, and Section B focuses on various embodiments of the API for synchronization.
A. 동기화 개관A. Synchronization Overview
본 발명의 여러 실시예들에 있어서, 도 3과 관련하여, 저장 플랫폼은 (i) 저장 플랫폼의 다수의 인스턴스들(각각이 그 자신의 데이터 스토어(302)를 가짐)이 유연성 있는 규칙 세트에 따라서 그들의 콘텐츠의 파트들을 동기화하도록 허용하고, (ii) 제3자들이 본 발명의 저장 플랫폼의 데이터 스토어를 동기화하는 인프라구조에 사유 프로토콜(proprietary protocols)을 구현하는 다른 데이터 소스들을 제공하는 동기화 서비스(330)를 제공한다.In various embodiments of the present invention, in connection with FIG. 3, the storage platform may be configured to: (i) multiple instances of the storage platform, each with its
관여하는 복제본들(participating replicas)의 그룹 사이에서 저장 플랫폼 대 저장 플랫폼 동기화가 발생한다. 예를 들어, 도 3을 참조하면, 저장 플랫폼(300)의 데이터 스토어(302)와 아마도 다른 컴퓨터 시스템 상에서 실행되는 저장 플랫폼의 다른 인스턴스의 제어 하의 다른 원격 데이터 스토어(338) 사이의 동기화를 제공하는 것이 바람직할 수 있다. 이 그룹의 전체 멤버십은 임의의 주어진 시간에 임의의 주어진 복제본에게 반드시 알려질 필요는 없다.Storage platform-to-storage platform synchronization occurs between groups of participating replicas. For example, referring to FIG. 3, which provides synchronization between the
서로 다른 복제본들이 독립적으로(즉, 동시에) 변경들을 행할 수 있다. 동기화의 프로세스는 모든 복제본들이 다른 복제본들에 의해 행해진 변경들을 알아차리게 하는 것으로 정의된다. 이 동기화 능력은 본래부터 멀티마스터(multi-master)이다.Different replicas can make changes independently (ie, at the same time). The process of synchronization is defined as making all replicas aware of the changes made by other replicas. This synchronization capability is inherently multi-master.
본 발명의 동기화 능력은 복제본들이:The synchronization capability of the present invention is that replicas:
1. 저장 플랫폼 대 저장 플랫폼 동기화(storage platform-to-storage platform sync)1.Storage platform-to-storage platform sync
본 발명의 저장 플랫폼의 동기화 서비스(330)의 주 응용은 저장 플랫폼의 다수의 인스턴스들(각각이 그 자신의 데이터 스토어를 가짐)을 동기화하는 것이다. 동기화 서비스는 (데이터베이스(314)의 하위 표들(underlying tables)보다는) 저장 플랫폼 스키마의 레벨에서 동작한다. 따라서, 예를 들면, 아래에서 논의되는 바와 같이 동기화 세트들을 정의하기 위해 "범위"(Scopes)가 사용된다.The main application of the synchronization service 330 of the storage platform of the present invention is to synchronize multiple instances of the storage platform, each with its own data store. The synchronization service operates at the level of the storage platform schema (rather than the underlying tables of the database 314). Thus, for example, "Scopes" are used to define synchronization sets as discussed below.
동기화 서비스는 "최종 변경"(net changes)의 원리에 입각하여 동작한다. (트랜잭션 복제(transactional replication)와 같은) 개개의 동작들을 기록하고 보내기보다는, 동기화 서비스는 이들 동작들의 최종 결과를 보내고, 따라서 다수의 동작들의 결과들을 단일의 결과적인 변경으로 통합한다.The synchronization service operates on the principle of "net changes". Rather than record and send individual operations (such as transactional replication), the synchronization service sends the final results of these operations, thus integrating the results of multiple operations into a single resulting change.
동기화 서비스는 일반적으로 트랙잭션 경계들을 고려하지 않는다. 바꾸어 말하여, 단일 트랜잭션에서 저장 플랫폼 데이터 스토어에 대해 2개의 변경이 행해지면, 이들 변경들이 모든 다른 복제들에서 자동으로 적용된다고 하는 보장이 없다 -- 하나가 다른 하나 없이 나타날 수도 있다. 이 원리의 예외는 동일 트랜잭션에서 동일 아이템에 대해 2개의 변경이 행해지면, 이들 변경들은 다른 복제들에 자동으로 보내지고 적용되도록 보증된다. 따라서, 아이템들은 동기화 서비스의 일관성 단위들(consistency units)이다.The synchronization service generally does not take into account transaction boundaries. In other words, if two changes are made to the storage platform data store in a single transaction, there is no guarantee that these changes are automatically applied in all other replicas-one may appear without the other. An exception to this principle is that if two changes are made to the same item in the same transaction, those changes are guaranteed to be automatically sent and applied to other replicas. Thus, items are the consistency units of the synchronization service.
a) 동기화(Sync) 제어 애플리케이션a) Sync control application
임의의 애플리케이션이 동기화 서비스에 접속하여 동기화 동작을 개시할 수 있다. 그러한 애플리케이션은 동기화를 수행하기 위해 요구되는 모든 파라미터들을 제공한다(아래 sync 프로파일 참조). 그러한 애플리케이션들은 여기에서 Sync 제어 애플리케이션들(SCAs: Sync Controlling Applications)이라고 불린다.Any application can connect to the synchronization service to initiate a synchronization operation. Such an application provides all the parameters required to perform the synchronization (see sync profile below). Such applications are referred to herein as Sync Controlling Applications (SCAs).
2개의 저장 플랫폼 인스턴스들을 동기화할 때, SCA에 의해 한쪽에서 sync가 개시된다. 그 SCA는 원격 파트너와 동기화하도록 로컬 동기화 서비스에게 알린다. 다른 쪽에서, 동기화 서비스는 발신 기계(originating machine)로부터 동기화 서비스에 의해 보내진 메시지들에 의해 깨어난다(awoken). 그것은 목적지 기계(destination machine) 상에 존재하는 지속 구성 정보(persistent configuration information)(아래 매핑 참조)에 기초하여 응답한다. 동기화 서비스는 스케줄대로 또는 이벤트들에 응답하여 실행될 수 있다. 이들 경우에, 스케줄을 구현하는 동기화 서비스는 SCA가 된다.When synchronizing two storage platform instances, sync is initiated on one side by the SCA. The SCA notifies the local synchronization service to synchronize with the remote partner. On the other side, the synchronization service is awoken by messages sent by the synchronization service from the originating machine. It responds based on persistent configuration information (see mapping below) that resides on the destination machine. The synchronization service may run on a schedule or in response to events. In these cases, the synchronization service implementing the schedule is the SCA.
동기화를 가능케 하기 위하여, 2개의 조치가 취해져야 한다. 첫째로, 스키마 설계자는 (아래에서 설명되는 바와 같이 변경 단위들(Change Units)을 지정하는) 적당한 sync 의미론으로 저장 플랫폼 스키마에 주석을 달아야 한다. 둘째로, 동기화는 (아래에서 설명되는 바와 같이) 동기화에 관여할 저장 플랫폼의 인스턴스를 갖는 모든 머신들 상에서 적당히 구성되어야 한다.In order to enable synchronization, two actions must be taken. First, the schema designer must annotate the storage platform schema with the appropriate sync semantics (specifying change units as described below). Second, the synchronization must be properly configured on all machines with an instance of the storage platform that will be involved in the synchronization (as described below).
b) 스키마 주석(Schema annotation)b) Schema annotation
동기화 서비스의 기본적인 개념은 변경 단위(Change Unit)의 개념이다. 변경 단위는 저장 플랫폼에 의해 개별적으로 추적되는 최소의 스키마 단편(smallest piece of schema)이다. 모든 변경 단위에 대하여, 동기화 서비스는 마지막 sync 이래로 그것이 변경되었는지 또는 변경되지 않았는지 여부를 결정할 수 있을 것이다.The basic concept of the synchronization service is the concept of change units. The change unit is the smallest piece of schema that is tracked separately by the storage platform. For every change unit, the synchronization service may be able to determine whether or not it has changed since the last sync.
스카마 내의 변경 단위들을 지정하는 것은 몇 가지 목적에 도움이 된다. 첫째로, 그것은 유선 상에서 동기화 서비스가 얼마나 채티(chatty)한지를 결정한다. 변경이 변경 단위 내에서 행해질 경우, 전체 변경 단위가 다른 복제본들에게 보내진다. 왜냐하면 동기화 서비스는 변경 단위의 어느 파트가 변경되었는지를 알지 못하기 때문이다. 둘째로, 그것은 충돌 검출의 입도(granularity)를 결정한다. 2개의 동시 발생의 변경들(이들 용어는 후속 섹션들에서 상세히 정의됨)이 동일한 변경 단위에 대해 행해질 경우, 동기화 서비스는 충돌을 제기(raise)하고, 다른 한편으로, 2개의 동시 발생의 변경들이 서로 다른 변경 단위들에 대해 행해지면, 아무런 충돌도 제기되지 않고 그 변경들은 자동으로 병합된다. 셋째로, 그것은 시스템에 의해 유지된 메타데이터의 양에 상당히 영향을 미친다. 동기화 서비스 메타데이터의 많은 것은 변경 단위마다 유지되고, 따라서 변경 단위들을 작게 하면 sync의 부하(overhead)가 증가된다.Specifying change units within a schema serves several purposes. First, it determines how chatty the synchronization service is on the wire. When a change is made within a change unit, the entire change unit is sent to other replicas. This is because the synchronization service does not know which part of the change unit has changed. Second, it determines the granularity of collision detection. If two concurrent occurrences of change (these terms are defined in detail in subsequent sections) are made for the same unit of change, the synchronization service raises a collision, on the other hand, When made for different change units, no conflict is raised and the changes are merged automatically. Third, it significantly affects the amount of metadata maintained by the system. Much of the synchronization service metadata is maintained per change unit, so making the change units small increases the overhead of sync.
변경 단위들을 정의하는 것은 올바른 트레이드오프들을 찾는 것을 필요로 한다. 그 때문에, 동기화 서비스는 스키마 설계자들이 프로세스에 관여하도록 허용한다.Defining change units requires finding the right tradeoffs. As such, the synchronization service allows schema designers to participate in the process.
일 실시예에서, 동기화 서비스는 엘리먼트보다 큰 변경 단위들을 지원하지 않는다. 그러나, 그것은 스키마 설계자들이 엘리먼트보다 작은 변경 단위들을 특정할 능력을 지원한다 --- 즉, 엘리먼트의 다수의 속성들(attributes)을 별개의 변경 단위로 그룹화하는 것을 지원한다. 그 실시예에서, 이것은 다음의 구문을 이용하여 달성된다:In one embodiment, the synchronization service does not support change units larger than the element. However, it supports the ability of schema designers to specify change units smaller than an element-that is, to group multiple attributes of an element into separate change units. In that embodiment, this is accomplished using the following syntax:
c) Sync 구성c) Sync configuration
그들의 데이터의 특정 파트들을 sync로 유지하기를 원하는 저장 플랫폼 파트너들의 그룹은 sync 공동체(sync community)라고 불린다. 이 공동체의 멤버들은 sync에 머무르기를 원하지만, 그것들은 반드시 데이터를 정확히 동일하게 나타낼 필요는 없다. 바꾸어 말하면, sync 파트너들은 그들이 동기화하고 있는 데이터를 변환할 수 있다.The group of storage platform partners who want to keep certain parts of their data in sync is called the sync community. Members of this community want to stay in sync, but they don't necessarily represent data exactly the same. In other words, sync partners can transform the data they are synchronizing.
피어 투 피어 시나리오(peer-to-peer scenario)에서는, 피어들이 그들의 파트너들 모두에 대한 변환 매핑들을 유지하는 것은 비실용적이다. 대신에, 동기화 서비스는 "공동체 폴더들"(Community Folders)을 정의하는 방법을 취한다. 공동체 폴더는 모든 공동체 멤버들이 동기화하고 있는 가상적 "공유 폴더"(shared folder)를 나타내는 추상화이다.In a peer-to-peer scenario, it is impractical for peers to maintain translation mappings for all of their partners. Instead, the synchronization service takes a way to define "Community Folders". Community folders are abstractions that represent virtual "shared folders" that all community members are synchronizing.
이 개념은 예에 의해 가장 잘 설명된다. 만일 조(Joe)가 그의 몇 개의 컴퓨터들의 내문서(My Documents) 폴더들을 sync로 유지하기를 원하면, 조(Joe)는 이를테면 JoesDocuments라고 불리는 공동체 폴더를 정의한다. 그 후, 모든 컴퓨터 상에서, Joe는 가상적 JoesDocuments 폴더와 로컬 My Documents 폴더 사이의 매핑을 구성한다. 이 시점부터, Joe의 컴퓨터들이 서로 동기화할 때, 그것들은 그들의 로컬 아이템들보다는, JoesDocuments 내의 문서들에 관하여 이야기(talk)한다. 이런 식으로, 모든 Joe의 컴퓨터들은 상대가 누구인지 모르고도 서로 이해한다 -- 공동체 폴더는 sync 공동체의 공통어(lingua franca)가 된다.This concept is best explained by example. If Joe wants to keep the My Documents folders on several of his computers in sync, Joe defines a community folder called JoesDocuments, for example. Then, on every computer, Joe configures the mapping between the virtual JoesDocuments folder and the local My Documents folder. From this point on, when Joe's computers synchronize with each other, they talk about documents in JoesDocuments, rather than their local items. In this way, all Joe's computers understand each other without knowing who they are-community folders become the lingua franca of the sync community.
동기화 서비스를 구성하는 것은 3 단계로 이루어진다: (1) 로컬 폴더들과 공동체 폴더들 간의 매핑들을 정의하는 단계; (2) 무엇이 동기화되는지(예를 들면, 누구와 동기화하는지 및 어떤 서브세트들이 송신되어야 하는지 및 어느 것이 수신하였는지)를 결정하는 sync 프로파일들을 정의하는 단계; (3) 상이한 sync 프로파일들이 실행되어야 하는 스케줄들을 정의하거나, 또는 그것들을 수동으로 실행하는 단계.Configuring the synchronization service consists of three steps: (1) defining mappings between local folders and community folders; (2) defining sync profiles that determine what is synchronized (eg, with whom and with what subsets should be transmitted and which received); (3) Defining schedules for which different sync profiles should be executed, or executing them manually.
(1) 공동체 폴더 - 매핑(1) Community Folder-Mapping
공동체 폴더 매핑들은 개개의 머신들 상에 XML 구성 파일들로서 저장된다. 각각의 매핑은 다음의 스키마를 갖는다:Community folder mappings are stored as XML configuration files on individual machines. Each mapping has the following schema:
/mappings/communityFolder / mappings / communityFolder
이 엘리먼트는 이 매핑이 대상으로 하는 공동체 폴더를 명명한다. 이 이름은 폴더들의 구문 규칙 다음에 온다.This element names the community folder that this mapping targets. This name follows the syntax rules of the folders.
/mappings/localFolder / mappings / localFolder
이 엘리먼트는 매핑이 변환하는 로컬 폴더를 명명한다. 이 이름은 폴더들의 구문 규칙 다음에 온다. 이 폴더는 매핑이 유효하기 위해 항상 존재해야 한다. 이 폴더 내의 아이템들은 이 매핑마다의 동기화를 위해 고려된다.This element names the local folder that the mapping translates to. This name follows the syntax rules of the folders. This folder must always exist for the mapping to be valid. Items in this folder are considered for synchronization per this mapping.
/mappings/transformations / mappings / transformations
이 엘리먼트는 아이템들을 공동체 폴더로부터 로컬 폴더로 변환하고 다시 역으로 변환하는 방법을 정의한다. 만일 존재하지 않거나 비어 있다면, 아무런 변환도 수행되지 않는다. 특히, 이것은 아무런 ID도 매핑되지 않는다는 것을 의미한다. 이 구성은 주로 폴더의 캐시를 생성하는 데 유용하다.This element defines how items are converted from community folders to local folders and back. If not present or empty, no conversion is performed. In particular, this means that no ID is mapped. This configuration is mainly useful for creating a cache of folders.
/mappings/transformations/mapIDs / mappings / transformations / mapIDs
이 엘리먼트는 공동체 ID들을 재사용하기보다는 새로이 생성된 로컬 ID들이 공동체 폴더로부터 매핑된 모든 아이템들에 할당되도록 요구한다. Sync Runtime은 아이템들을 앞뒤로 변환하기 위해 ID 매핑들을 유지할 것이다.This element requires newly created local IDs to be assigned to all items mapped from the community folder, rather than reusing community IDs. Sync Runtime will maintain ID mappings to convert items back and forth.
/mappings/transformations/localRoot / mappings / transformations / localRoot
이 엘리먼트는 공동체 폴더 내의 모든 루트 아이템들이 특정 루트의 자식으로 되도록 요구한다.This element requires that all root items in the community folder be children of a particular root.
/mappings/runAs / mappings / runAs
이 엘리먼트는 누구의 권한 하에서 이 매핑에 대한 요구들이 처리되는지를 제어한다. 만일 없다면, 송신자(sender)가 추측된다.This element controls under whose authority the requests for this mapping are handled. If not, the sender is assumed.
/mappings/runAs/sender / mappings / runAs / sender
이 엘리먼트의 존재는 이 매핑에 대한 메시지들의 송신자가 가장(impersonate)되어야 한다는 것을 나타내고, 그의 자격 증명(credentials) 하에서 처리될 것을 요구한다.The presence of this element indicates that the sender of messages for this mapping should be impersonated and requires that it be processed under its credentials.
(2) 프로파일(2) profile
Sync 프로파일은 동기화를 시작(kick off)하기 위해 요구되는 파라미터들의 전체 세트이다. 그것은 sync를 개시하기 위해 SCA에 의해 Sync Runtime에 공급된다. 저장 플랫폼 대 저장 플랫폼 동기화를 위한 Sync 프로파일들은 다음의 정보를 포함한다:The Sync profile is the full set of parameters required to kick off synchronization. It is supplied to the Sync Runtime by the SCA to initiate sync. Sync profiles for storage platform to storage platform synchronization include the following information:
동기화 서비스는 Sync 프로파일들의 간단한 작성을 허용하는 런타임 CLR 클래스(runtime CLR class)를 제공한다. 프로파일들은 또한 용이한 저장을 위하여 XML 파일들로 및 XML 파일들로부터 직렬화될 수 있다(흔히 스케줄과 함께). 그러나, 저장 플랫폼 내에 모든 프로파일들의 저장되는 표준 위치가 없다. SCA들은 그것을 고집하지 않고 즉석에서(on the spot) 마음대로 프로파일을 작성할 수 있다. sync를 개시하기 위해 로컬 매핑을 가질 필요는 없음을 주의해야 한다. 모든 sync 정보는 프로파일에서 특정될 수 있다. 그러나, 매핑은 원격 사이드에 의해 개시된 sync 요구에 응답하기 위하여 필요하다.The synchronization service provides a runtime CLR class that allows simple creation of Sync profiles. Profiles can also be serialized to and from XML files (often with a schedule) for easy storage. However, there is no standard location where all profiles are stored within the storage platform. SCAs can freely profile on the spot without sticking to it. Note that you do not need to have a local mapping to initiate sync. All sync information can be specified in the profile. However, mapping is needed to respond to the sync request initiated by the remote side.
(3) 스케줄(3) schedule
일 실시예에서, 동기화 서비스는 그 자신의 스케줄링 인프라구조를 제공하지 않는다. 대신에, 그것은 이 태스크를 수행하기 위해 다른 컴포넌트에 의지한다 - 마이크로소프트 윈도즈 운영 시스템과 함께 이용가능한 윈도즈 스케줄러(Windows Scheduler). 동기화 서비스는 SCA로서 기능하고 XML 파일 내에 저장된 sync 프로파일에 기초하여 동기화를 트리거하는 명령 행 유틸리티(command-line utility)를 포함한다. 이 유틸리티는 스케줄대로, 또는 사용자 로그온 또는 로그오프와 같은 이벤트들에 응답하여 동기화를 실행하도록 윈도즈 스케줄러를 구성하는 것을 매우 용이하게 한다.In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, it relies on other components to perform this task-the Windows Scheduler available with the Microsoft Windows operating system. The synchronization service includes a command-line utility that functions as an SCA and triggers synchronization based on the sync profile stored in the XML file. This utility makes it very easy to configure the Windows scheduler to perform synchronization on a schedule or in response to events such as user logon or logoff.
d) 충돌 핸들링(Conflict Handling)d) Conflict Handling
동기화 서비스 내의 충돌 처리는 3 단계로 나누어진다: (1) 변경 적용 시간에 일어나는 충돌 검출 - 이 단계는 변경이 안전하게 적용될 수 있는지를 결정한다; (2) 자동 충돌 레졸루션 및 로깅 - (충돌이 검출된 직후에 일어나는) 이 단계 중에 충돌이 리졸브될 수 있는지를 알기 위해 자동 충돌 리졸버가 참고(consult)된다 - 만일 충돌이 리졸브될 수 없다면, 충돌은 선택적으로(optionally) 로깅될 수 있다; (3) 충돌 검사 및 레졸루션 - 이 단계는 몇몇 충돌들이 로깅되면 발생되고, sync 세션의 컨텍스트 밖에서 발생된다 - 이 때, 로깅된 충돌들은 리졸브되고 로그로부터 제거될 수 있다.Conflict processing in the synchronization service is divided into three phases: (1) collision detection occurring at the time of change application-this step determines whether the change can be safely applied; (2) Automatic Collision Resolution and Logging-An automatic collision resolver is consulted to see if a collision can be resolved during this phase (which happens immediately after a collision is detected)-if the collision cannot be resolved, Conflicts can optionally be logged; (3) Collision checking and resolution-This step occurs when some conflicts are logged and occurs outside the context of the sync session-at which time the logged conflicts can be resolved and removed from the log.
(1) 충돌 검출(1) collision detection
본 실시예에서, 동기화 서비스는 2가지 유형의 충돌들을 검출한다: 지식 기반 충돌 및 제약 기반 충돌.In this embodiment, the synchronization service detects two types of conflicts: knowledge based collisions and constraint based collisions.
(a) 지식 기반 충돌(Knowledge-based conflicts)(a) Knowledge-based conflicts
지식 기반 충돌은 2개의 복제본들이 동일한 변경 단위에 대해 독립적인 변경들을 행할 때 발생한다. 2개의 변경이 서로에 대한 지식이 없이 행해지는 경우에 -- 바꾸어 말하면, 첫 번째 것의 버전이 두 번째 것의 지식에 의해 커버되지 않고 또한 그 반대인 경우에 두 변경들은 독립적이라고 불린다. 동기화 서비스는 위에서 설명한 바와 같이 복제본의 지식에 기초하여 그러한 모든 충돌들을 자동으로 검출한다.Knowledge base conflicts arise when two replicas make independent changes to the same unit of change. If two changes are made without knowledge of each other-in other words, if the version of the first is not covered by the knowledge of the second and vice versa, the two changes are called independent. The synchronization service automatically detects all such conflicts based on the replica's knowledge as described above.
때로는 충돌들을 변경 단위의 버전 히스토리에서의 분기들(forks)로서 간주하는 것이 유익하다. 만일 변경 단위의 일생에서 아무런 충돌도 일어나지 않으면, 그것의 버전 히스토리는 단순 체인(simple chain)이다 -- 각각의 변경은 이전의 것 후에 일어난다. 지식 기반 충돌의 경우에, 2개의 변경들은 동시에 일어나서, 체인이 나누어지고 버전 트리가 되게 한다.Sometimes it is useful to regard conflicts as forks in the version history of the change unit. If no conflict occurs in the life of a change unit, its version history is a simple chain-each change occurs after the previous one. In the case of knowledge base collisions, the two changes occur at the same time, causing the chain to be split and version tree.
(b) 제약 기반 충돌(Constraint-based conflicts)(b) Constraint-based conflicts
독립적인 변경들이 함께 적용될 때 무결성 제약(integrity constraint)을 위반하는 경우들이 있다. 이를테면, 동일 디렉토리 내에 동일 이름을 갖는 파일을 생성하는 2개의 복제본들이 그러한 충돌을 일으킬 수 있다.There are cases in which integrity constraints are violated when independent changes are applied together. For example, two replicas that create a file with the same name in the same directory can cause such a conflict.
제약 기반 충돌은 (지식 기반 충돌과 마찬가지로) 2개의 독립적인 변경들을 수반하지만, 그것들은 동일한 변경 단위에 영향을 미치지 않는다. 도리어, 그것들은 상이한 변경 단위들에 영향을 미치지만 그들 사이에 존재하는 제약을 갖는다.Constraint based collisions involve two independent changes (as with knowledge based collisions), but they do not affect the same unit of change. Rather, they affect different change units but have constraints that exist between them.
동기화 서비스는 변경 적용 시간에 제약 위반을 검출하고 자동으로 제약 기반 충돌들을 제기한다. 제약 기반 충돌들을 리졸브하는 데에는 통상적으로 제약을 위반하지 않도록 변경들을 수정하는 맞춤 코드(custom code)가 요구된다; 동기화 서비스는 그렇게 하기 위한 범용 메커니즘을 제공하지 않는다.The synchronization service detects constraint violations at the time of change application and automatically raises constraint based conflicts. Resolving constraint based conflicts typically requires custom code to modify the changes so as not to violate the constraints; The synchronization service does not provide a general purpose mechanism for doing so.
(2) 충돌 처리(Conflict Processing)(2) Conflict Processing
충돌이 검출되면, 동기화 서비스는 (Sync 프로파일 내의 sync 개시자(initiator)에 의해 선택된) 3개의 조치들 중 하나를 취할 수 있다: (1) 변경을 리젝트하고, 그것을 송신자에게로 반환한다; (2) 충돌을 충돌 로그 내로 로깅한다; 또는 (3) 충돌을 자동으로 리졸브한다.If a conflict is detected, the synchronization service may take one of three actions (selected by the sync initiator in the Sync profile): (1) reject the change and return it to the sender; (2) log the conflict into the conflict log; Or (3) resolve conflicts automatically.
만일 변경이 리젝트되면, 동기화 서비스는 마치 그 변경이 복제본에 도착하지 않은 것처럼 동작한다. 발신자에게 부정 응답(negative acknowledgement)이 송신된다. 이 레졸루션 정책은 주로 로깅 충돌들이 있음직하지 않은 (파일 서버들과 같은) 헤드 없는 복제본들(head-less replicas) 상에서 유용하다. 대신에, 그러한 복제본들은 충돌들을 리젝트함으로써 다른 것들에게 그 충돌들을 처리하도록 강요한다.If the change is rejected, the synchronization service behaves as if the change did not arrive at the replica. A negative acknowledgment is sent to the sender. This resolution policy is mainly useful on head-less replicas (such as file servers) where logging conflicts are unlikely. Instead, such replicas force others to handle the conflicts by rejecting the conflicts.
Sync 개시자들은 그들의 Sync 프로파일들에서 충돌 레졸루션을 구성한다. 동기화 서비스는 다음의 방법으로 단일 프로파일에서 다수의 충돌 리졸버들을 결합하는 것을 지원한다 - 첫째로, 시도될 충돌 리졸버들의 리스트를 그들 중 하나가 성공할 때까지 잇따라 특정함으로써, 그리고 둘째로, 충돌 리졸버들을 충돌 유형들과 관련시킴으로써, 예를 들면, 업데이트-업데이트 지식 기반 충돌들을 하나의 리졸버에게 보내고, 다른 모든 충돌들은 로그에게 보냄으로써.Sync initiators configure conflict resolution in their Sync profiles. The synchronization service supports combining multiple conflict resolvers in a single profile in the following way-first, by specifying a list of conflict resolvers to be attempted successively until one of them succeeds, and secondly, conflict conflict resolvers. By relating types, for example by sending update-update knowledge base conflicts to one resolver and all other conflicts to the log.
(a) 자동 충돌 레졸루션(a) Auto Collision Resolution
동기화 서비스는 다수의 디폴트 충돌 리졸버들을 제공한다.The synchronization service provides a number of default conflict resolvers.
이 리스트는 다음의 것들을 포함한다:This list includes:
게다가, ISV들은 그들 자신의 리졸버들을 구현하고 설치할 수 있다. 맞춤 충돌 리졸버들(custom conflict resolvers)은 구성 파라미터들을 수용(accept)할 수 있고, 그러한 파라미터들은 Sync 프로파일의 충돌 레졸루션 섹션의 SCA에 의해 특정되어야 한다.In addition, ISVs can implement and install their own resolvers. Custom conflict resolvers can accept configuration parameters, which should be specified by the SCA of the conflict resolution section of the Sync profile.
충돌 리졸버가 충돌을 핸들링할 때, 그것은 (충돌하는 변경 대신에) 수행될 필요가 있는 동작들의 리스트를 런타임에 도로 반환한다. 그 후 동기화 서비스는 충돌 핸들러가 고려한 것을 포함하는 원격 지식을 적절히 조정하는 이러한 동작들을 적용한다.When a conflict resolver handles a conflict, it returns back to the list of actions that need to be performed (instead of a conflicting change). The synchronization service then applies these actions to properly coordinate remote knowledge, including what the conflict handler considered.
레졸루션을 적용하는 동안 다른 충돌이 검출되는 것이 가능하다. 그러한 경우에, 새로운 충돌은 원래의 처리가 다시 시작하기 전에 리졸브되어야 한다.It is possible that other collisions can be detected while applying resolution. In such a case, a new conflict must be resolved before the original processing can resume.
충돌들을 아이템의 버전 히스토리에서의 분기들로 간주할 때, 충돌 레졸루션들은 2개의 분기들을 결합하여 단일 점을 형성하는 조인들(joins)으 간주될 수 있다. 따라서, 충돌 레졸루션들은 버전 히스토리들을 DAG들로 변화시킨다.When considering collisions as branches in the version history of an item, collision resolutions can be considered joins that combine two branches to form a single point. Thus, conflict resolutions change version histories to DAGs.
(b) 충돌 로깅(Conflict Logging)(b) Conflict Logging
매우 특별한 종류의 충돌 리졸버가 충돌 로거(Conflict Logger)이다. 동기화 서비스는 충돌들을 ConflictRecord 타입의 아이템들로서 로깅한다. 이들 레코드들은 충돌하고 있는 아이템들에 다시 관련된다(그 아이템들 자신이 삭제되지 않는 한). 각각의 충돌 레코드는, 충돌을 일으킨 착신되는 변경(incoming change); 충돌의 유형: 업데이트-업데이트, 업데이트-삭제, 삭제-업데이트, 삽입-삽입, 또는 제약; 및 착신되는 변경의 버전 및 그것을 송신한 복제본의 지식을 포함한다. 로깅된 충돌들은 아래에서 설명되는 바와 같이 검사 및 레졸루션을 위해 이용 가능하다.A very special kind of collision resolver is the conflict logger. The synchronization service logs conflicts as items of type ConflictRecord. These records relate to the conflicting items (unless the items themselves are deleted). Each conflict record includes an incoming change that caused the conflict; Type of conflict: update-update, update-delete, delete-update, insert-insert, or constraint; And the version of the incoming change and the knowledge of the replica that sent it. Logged conflicts are available for inspection and resolution as described below.
(c) 충돌 검사 및 레졸루션(c) Collision Checking and Resolution
동기화 서비스는 충돌 로그를 검사하고 그 안의 충돌들의 레졸루션들을 제안하기 위해 API를 애플리케이션들에 제공한다. API는 애플리케이션이 모든 충돌들, 또는 주어진 아이템에 관련된 충돌들을 열거(enumerate)할 수 있게 한다. 그것은 또한 그런 애플리케이션들이 다음 3가지 방법 중 하나로 로깅된 충돌들을 리졸브할 수 있게 한다: (1) 원격 윈 -- 로깅된 변경을 수용하고 충돌하는 로컬 변경을 덮어쓰기(overwriting)함; (2) 로컬 윈 -- 로깅된 변경의 충돌하는 파트들을 무시함; 및 (3) 새로운 변경을 제안 -- 애플리케이션이, 그것의 의견으로, 충돌을 리졸브하는 병합(merge)을 제안하는 경우. 일단 충돌들이 애플리케이션에 의해 리졸브되면, 동기화 서비스는 충돌들을 로그로부터 제거한다.The synchronization service provides an API to applications to examine the conflict log and suggest resolutions of conflicts therein. The API allows an application to enumerate all conflicts or conflicts related to a given item. It also allows such applications to resolve logged conflicts in one of three ways: (1) Remote Win-accepts logged changes and overwrites conflicting local changes; (2) local wins-ignore conflicting parts of logged changes; And (3) suggest a new change-if the application, in its opinion, proposes a merge that resolves the conflict. Once conflicts are resolved by the application, the synchronization service removes the conflicts from the log.
(d) 복제본들의 컨버전스 및 충돌 레졸루션들의 전파(Convergence of replicas and Propagation of Conflict Resolutions)(d) Convergence of replicas and Propagation of Conflict Resolutions
복잡한 동기화 시나리오들에서, 동일한 충돌이 다수의 복제본들에서 검출될 수 있다. 이런 경우가 발생하면, 몇 가지 것들이 일어날 수 있다: (1) 충돌은 하나의 복제본 상에서 리졸브될 수 있고, 레졸루션이 다른 것에 보내진다; (2) 충돌은 양쪽 복제본들에서 자동으로 리졸브된다; 또는 (3) 충돌은 양쪽 복제본들에서 수동으로(충돌 검사 API를 통하여) 리졸브된다.In complex synchronization scenarios, the same collision can be detected in multiple replicas. If this happens, several things can happen: (1) Collisions can be resolved on one replica and resolution is sent to another; (2) the conflict is resolved automatically in both replicas; Or (3) the conflict is resolved manually (via the collision check API) in both replicas.
컨버전스를 보증하기 위하여, 동기화 서비스는 충돌 레졸루션들을 다른 복제본들에 전송한다. 충돌을 리졸브하는 변경이 복제본에 도착하면, 동기화 서비스는 이 업데이트에 의해 리졸브되는 로그 내의 임의의 충돌 레코드들을 자동으로 찾고 그것들을 제거한다. 이런 의미에서, 하나의 복제본에서의 충돌 레졸루션은 다른 모든 복제본들에서 구속력이 있다(binding).To ensure convergence, the synchronization service sends conflict resolutions to other replicas. When a change that resolves a conflict arrives at the replica, the synchronization service automatically finds any conflict records in the log resolved by this update and removes them. In this sense, collision resolution in one replica is binding on all other replicas.
만일 동일한 충돌에 대해 서로 다른 복제본들에 의해 서로 다른 승자들이 선택된다면, 동기화 서비스는 구속력 있는 충돌 레졸루션의 원리를 적용하여 2개의 레졸루션 중 하나를 골라 다른 것에 대해 자동으로 승리하게 한다. 승자는 언제나 동일한 결과를 생성하도록 보증되는 결정적 방식으로 선택된다(일 실시예는 복제본 ID 사전적 비교를 이용한다).If different winners are selected by different replicas for the same conflict, the synchronization service applies the principle of binding conflict resolution to select one of the two resolutions and automatically win the other. The winner is chosen in a deterministic manner that is guaranteed to always produce the same result (one embodiment uses replica ID dictionary comparison).
만일 동일한 충돌에 대해 서로 다른 복제본들에 의해 서로 다른 "새로운 변경"이 제안된다면, 동기화 서비스는 이 새로운 충돌을 특별한 충돌로 취급하고 충돌 로거(Conflict Logger)를 이용하여 그것이 다른 복제본들에 전파되지 못하도록 한다. 그러한 상황은 수동 충돌 레졸루션에 의해 일반적으로 일어난다.If different "new changes" are proposed by different replicas for the same conflict, the synchronization service treats this new conflict as a special conflict and uses a Conflict Logger to prevent it from propagating to other replicas. do. Such a situation is generally caused by manual collision resolution.
2. 비저장 플랫폼 데이터 스토어들에의 동기화(Synchronizing to non-storage platform data stores)2. Synchronizing to non-storage platform data stores
본 발명의 저장 플랫폼의 다른 양태에 따르면, 저장 플랫폼은 저장 플랫폼이 Miscrosoft Exchange, AD, Hotmail 등과 같은 레거시(legacy) 시스템들에 동기화하도록 허용하는 Sync 어댑터들을 구현하기 위한 아키텍처를 ISV들에 제공한다. Sync 어댑터들은 아래에서 설명하는 바와 같이 동기화 서비스에 의해 제공되는 다수의 Sync 서비스로부터 이익을 얻는다.According to another aspect of the storage platform of the present invention, the storage platform provides the ISVs with an architecture to implement Sync adapters that allow the storage platform to synchronize to legacy systems such as Miscrosoft Exchange, AD, Hotmail, and the like. Sync adapters benefit from a number of Sync services provided by the synchronization service as described below.
그 이름에도 불구하고, Sync 어댑터들은 어떤 저장 플랫폼 아키텍처로의 플러그인(plug-ins)으로서 구현될 필요가 없다. 원한다면, "sync 어댑터"는 단순히 동기화 서비스 런타임 인터페이스들을 이용하여 변경 열거 및 적용과 같은 서비스들을 획득하는 임의의 애플리케이션일 수 있다.Despite its name, Sync adapters do not need to be implemented as plug-ins to any storage platform architecture. If desired, the "sync adapter" may simply be any application that obtains services such as change enumeration and application using the synchronization service runtime interfaces.
다른 것들이 주어진 백엔드(backend)에의 동기화를 구성하고 실행하는 것을 보다 간단하게 하기 위하여, Sync 어댑터 라이터들은 상술한 바와 같이 Sync 프로파일이 주어질 경우 sync를 실행하는 표준 Sync 어댑터 인터페이스를 노출시키도록 고무된다. 프로파일은 어댑터에 구성 정보를 제공하고, 그 어댑터들 중 일부는 런타임 서비스들(예를 들면, 동기화할 폴더)을 제어하기 위해 Sync 런타임(Sync Runtime)에 전달된다.To make it simpler for others to configure and implement synchronization to a given backend, Sync adapter writers are encouraged to expose a standard Sync adapter interface that performs sync when given a Sync profile as described above. Profiles provide configuration information to adapters, some of which are passed to Sync Runtime to control runtime services (eg, folders to synchronize).
a) Sync 서비스a) Sync service
동기화 서비스는 어댑터 라이터들에게 다수의 sync 서비스를 제공한다. 이 섹션에 나머지에서는, 그 위에서 저장 플랫폼이 동기화를 행하고 있는 머신을 "클라이언트"라고 부르고 어댑터가 이야기하고 있는 대상인 비저장 플랫폼 백엔드는 "서버"라고 부르는 것이 편리하다.The synchronization service provides a number of sync services to adapter writers. In the remainder of this section, it is convenient to call the machine on which the storage platform is synchronizing on it as the "client" and the non-storage platform backend that the adapter is talking about as the "server."
(1) 변경 열거(Change Enumeration)(1) change enumeration
동기화 서비스에 의해 유지되는 변경 추적 데이터에 기초하여, 변경 열거는 sync 어댑터들이 이 파트너와의 마지막 동기화가 시도된 이래로 데이터 스토어 폴더에 일어난 변경들을 쉽게 열거할 수 있게 한다.Based on the change tracking data maintained by the synchronization service, change enumeration allows the sync adapters to easily enumerate changes that have occurred in the data store folder since the last synchronization with this partner was attempted.
변경들은 "앵커"(anchor) - 마지막 동기화에 관한 정보를 나타내는 불투명 구조 - 의 개념에 기초하여 열거된다. 앵커는 이전의 섹션들에서 설명한 바와 같이 저장 플랫폼 지식의 형태를 취한다. 변경 열거 서비스를 이용하는 Sync 어댑터들은 2개의 넓은 카테고리에 속한다: "저장된 앵커"(stored anchors)를 이용하는 것들 대 "공급된 앵커"(supplied anchors)를 이용하는 것들.Changes are listed based on the concept of "anchor"-an opaque structure representing information about the last synchronization. The anchor takes the form of storage platform knowledge as described in the previous sections. Sync adapters using the change enumeration service fall into two broad categories: those using "stored anchors" versus those using "supplied anchors".
그 구별은 마지막 sync에 관한 정보가 어디에 - 클라이언트에 또는 서버에 - 저장되어 있는지에 기초한다. 종종 어댑터들이 이 정보를 클라이언트에 저장하는 것이 보다 용이하다 - 백 엔드는 종종 이 정보를 편리하게 저장할 수 없다. 다른 한편으로, 다수의 클라이언트들이 동일한 백엔드(backend)에 동기화하면, 이 정보를 클라이언트에 저장하는 것은 비효율적이고 어떤 경우 부정확하다 - 그것은 한 클라이언트가 이미 서버에 푸시 업(push-up)한 변경들을 다른 하나의 클라이언트가 알아채지 못하게 한다. 만일 어댑터가 서버 저장된 앵커를 사용하기를 원한다면, 그 어댑터는 변경 열거 시간에 저장 플랫폼에 다시 그것을 공급할 필요가 있다.The distinction is based on where the information about the last sync is stored-either at the client or at the server. It is often easier for adapters to store this information on the client-the back end often cannot store this information conveniently. On the other hand, if multiple clients are synchronizing to the same backend, storing this information on the client is inefficient and in some cases inaccurate-it means that one client already pushes up the server to the other. Don't let one client know. If the adapter wants to use a server stored anchor, the adapter needs to supply it back to the storage platform at change enumeration time.
저장 플랫폼이 앵커를 유지하기 위해서는(로컬 저장을 위해서든 원격 저장을 위해서든), 저장 플랫폼은 서버에서 성공적으로 적용된 변경들을 알게 되어야 할 필요가 있다. 이들 및 오직 이들 변경들만이 앵커에 포함될 수 있다. 변경 열거 동안, Sync 어댑터들은 승인 인터페이스(Acknowledgement interface)를 이용하여 어떤 변경들이 성공적으로 적용되었는지를 보고할 수 있다. 동기화의 마지막에서, 공급된 앵커들을 이용하는 어댑터들은 (성공적으로 적용된 변경들 모두를 통합하는) 새로운 앵커를 판독하여 그것을 그들의 백엔드에 송신해야 한다.In order for the storage platform to maintain anchors (either locally or remotely), the storage platform needs to be aware of the changes that have been successfully applied on the server. Only these and only these changes can be included in the anchor. During change enumeration, Sync adapters can use the Acknowledgment interface to report which changes were applied successfully. At the end of synchronization, adapters using supplied anchors must read the new anchor (integrating all successfully applied changes) and send it to their backend.
흔히, 어댑터들은 그들이 저장 플랫폼 데이터 스토어에 삽입하는 아이템들과 함께 어댑터 특정 데이터를 저장할 필요가 있다. 그러한 데이터의 통상의 예들은 원격 ID들 및 원격 버전들(타임스탬프)이다. 동기화 서비스는 이 데이터를 저장하기 위한 메커니즘을 제공하고, 변경 열거는 반환되는 변경들과 함께 이 부가적인 데이터를 수신하기 위한 메커니즘을 제공한다. 이것은 대부분의 경우에 어댑터들이 데이터베이스를 다시 쿼리할 필요성을 제거한다.Often, adapters need to store adapter specific data along with the items they insert into the storage platform data store. Typical examples of such data are remote IDs and remote versions (timestamps). The synchronization service provides a mechanism for storing this data, and change enumeration provides a mechanism for receiving this additional data with the changes returned. This eliminates the need for adapters to query the database in most cases.
(2) 변경 적용(Change Application)(2) Change Application
변경 적용은 Sync 어댑터들이 그들의 백엔드로부터 로컬 저장 플랫폼에 수신된 변경들을 적용할 수 있게 한다. 어댑터들은 그 변경들을 저장 플랫폼 스키마로 변환할 것으로 기대된다. 도 24는 저장 플랫폼 스키마로부터 저장 플랫폼 API 클래스들의 생성되는 프로세스를 예시한다.Apply changes allows Sync adapters to apply changes received from their backend to the local storage platform. Adapters are expected to convert those changes to the storage platform schema. 24 illustrates a process of generating storage platform API classes from a storage platform schema.
변경 적용의 주요 기능은 충돌들을 자동으로 검출하는 것이다. 저장 플랫폼 대 저장 플랫폼 sync의 경우에서와 같이, 충돌은 2개의 중첩하는 변경들이 서로에 대한 지식 없이 행해지는 것으로 정의된다. 어댑터들이 변경 적용을 사용할 때, 그것들은 어떤 충돌 검출이 수행되는지에 관하여 앵커를 특정해야 한다. 변경 적용은 어댑터의 지식에 의해 커버되지 않는 중첩하는 로컬 변경이 검출되면 충돌을 제기한다. 변경 열거와 유사하게, 어댑터들은 저장된 앵커 또는 공급된 앵커를 이용한다. 변경 적용은 어댑터 특정 메타데이터의 효율적인 저장을 지원한다. 그러한 데이터는 어댑터에 의해, 적용되는 변경들에 첨부될 수 있고, 동기화 서비스에 의해 저장될 수도 있다. 그 데이터는 다음 변경 열거에서 반환될 수도 있다.The main function of applying change is to automatically detect collisions. As in the case of storage platform to storage platform sync, a collision is defined as two overlapping changes made without knowledge of each other. When adapters use change application, they must specify an anchor as to what collision detection is performed. Change application raises a conflict if an overlapping local change is detected that is not covered by the adapter's knowledge. Similar to change enumeration, adapters use either a stored anchor or a supplied anchor. Change adaptation supports efficient storage of adapter specific metadata. Such data may be attached by the adapter to the changes applied and may be stored by the synchronization service. The data may be returned in the next change enumeration.
(3) 충돌 레졸루션(3) collision resolution
위에서 설명된 충돌 레졸루션 메커니즘들(로깅 및 자종 레졸루션 옵션들)은 sync 어댑터들에게도 이용가능하다. Sync 어댑터들은 변경들을 적용할 때 충돌 레졸루션에 대한 정책을 특정할 수 있다. 만일 특정되면, 충돌들은 특정된 충돌 핸들러에 전달되어 리졸브될 수 있다(만일 가능하다면). 충돌들은 또한 로깅될 수 있다. 어댑터들은 로컬 변경을 백엔드에 적용하려고 시도할 때 충돌을 검출할 수도 있다. 그러한 경우에도, 어댑터는 정책에 따라서 리졸브되도록 충돌을 Sync 런타임에 전달할 수 있다. 게다가, Sync 어댑터들은 동기화 서비스에 의해 검출된 임의의 충돌들이 처리를 위해 다시 그들에게 보내지도록 요구할 수 있다. 이것은 백엔드가 충돌들을 저장하고 리졸브할 수 있는 경우에 특히 편리하다.The conflict resolution mechanisms described above (logging and alarm resolution options) are also available to sync adapters. Sync adapters can specify a policy for conflict resolution when applying changes. If specified, conflicts can be resolved by passing them to the specified conflict handler (if possible). Conflicts can also be logged. Adapters may detect conflicts when attempting to apply local changes to the backend. Even so, the adapter can still forward the conflict to the Sync runtime to resolve according to the policy. In addition, Sync adapters may require that any conflicts detected by the synchronization service be sent back to them for processing. This is particularly convenient where the back end can store and resolve conflicts.
b) 어댑터 구현b) adapter implementation
어떤 "어댑터들"은 단순히 런타임 인터페이스들을 이용하는 애플리케이션들이지만, 어댑터들은 표준 어댑터 인터페이스들을 구현하도록 고무된다. 이들 인터페이스는 Sync 제어 애플리케이션들로 하여금, 어댑터가 주어진 Sync 프로파일에 따라서 동기화를 수행하도록 요구하고; 진행중인 동기화를 취소하고; 진행중인 sync에 대한 진행 보고(progress reporting)(퍼센트 완료)를 수신할 수 있게 한다.Some "adapters" are simply applications that use runtime interfaces, but adapters are encouraged to implement standard adapter interfaces. These interfaces require Sync control applications to cause the adapter to perform synchronization according to a given Sync profile; Cancel ongoing synchronization; Enables you to receive progress reporting (percent complete) on ongoing sync.
3. 보안3. Security
동기화 서비스는 저장 플랫폼에 의해 구현되는 보안 모델을 가능한 한 적게 도입하려고 노력한다. 동기화에 대한 새로운 권리를 정의하기보다는, 기존의 권리들이 사용된다. 구체적으로,The synchronization service seeks to introduce as little as possible the security model implemented by the storage platform. Rather than defining new rights for synchronization, existing rights are used. Specifically,
동기화 서비스는 안전한 저작자 정보(authorship information)를 유지하지 않는다. 사용자 U에 의해 복제본 A에서 변경이 행해지고 복제본 B에 전달(forward)되는 경우, 그 변경이 원래 A에서(또는 U에 의해) 행해졌다는 사실이 소실된다. 만일 B가 이 변경을 복제본 C에 전달하면, 이것은 A의 권한이 아니라 B의 권한 하에서 행해지는 것이다. 이것은 다음의 제한을 초래한다: 만일 복제본이 그 자신의 변경들을 아이템에 행하도록 위임되지 않으면, 그것은 다른 것들에 의해 행해진 변경들을 전달할 수 없다.The synchronization service does not maintain secure authorship information. If a change is made at replica A by user U and forwarded to replica B, the fact that the change was originally made at A (or by U) is lost. If B propagates this change to replica C, it is done under B's authority, not A's authority. This results in the following limitations: If a replica is not delegated to make its own changes to an item, it cannot convey the changes made by others.
동기화 서비스가 개시될 때, 그것은 Sync 제어 애플리케이션에 의해 행해진다. 동기화 서비스는 SCA의 아이덴티티를 가장하여 그 아이덴티티 하에서 모든 동작들(로컬로 그리고 원격으로) 수행한다. 예시하기 위하여, 사용자 U가 로컬 동기화 서비스로 하여금 사용자 U가 판독 액세스할 수 없는 아이템들에 대한 원격 저장 플랫폼으로부터 변경들을 검색하게 할 수 없다는 것을 주시하자.When the synchronization service is started, it is done by the Sync control application. The synchronization service impersonates the identity of the SCA and performs all operations (locally and remotely) under that identity. To illustrate, note that user U cannot cause the local synchronization service to retrieve changes from the remote storage platform for items that user U does not have read access to.
4. 관리능력(Manageability)4. Manageability
복제본들의 분산 공동체를 모니터링하는 것은 복잡한 문제이다. 동기화 서비스는 복제본들의 상태에 관한 정보를 수집하고 분배하기 위해 "스위프"(sweep) 알고리즘을 사용한다. 스위프 알고리즘의 속성들은 모든 구성된 복제본들에 관한 정보가 결국 수집되고 실패(비응답) 복제본들이 검출되는 점을 보장한다.Monitoring the distributed community of replicas is a complex problem. The synchronization service uses a "sweep" algorithm to collect and distribute information about the status of the replicas. The properties of the sweep algorithm ensure that information about all configured replicas is eventually collected and that failed (non-responsive) replicas are detected.
이 전공동체적(community-wide) 모니터링 정보는 모든 복제본에서 이용 가능하게 된다. 이 모니터링 정보를 검사하고 관리적 결정을 행하기 위해 임의로 선택된 복제본에서 모니터링 도구들이 실행될 수 있다. 영향받은 복제본들(affected replicas)에서 직접 임의의 구성 변경들이 행해져야 한다.This community-wide monitoring information will be available on all replicas. Monitoring tools can be run on a randomly selected replica to examine this monitoring information and make administrative decisions. Any configuration changes must be made directly at the affected replicas.
B. 동기화 API 개관B. Synchronization API Overview
보다 분산형인 디지털 세계에서, 개인들 및 작업집단들은 종종 여러 상이한 디바이스들 및 위치들에 정보 및 데이터를 저장한다. 이것은 사용자 간섭을 최소한으로 유지한채, 항상 동기화된 이러한 독립적이고 종종 다른 데이터 스토어들에서 정보를 유지할 수 있는 데이터 동기화 서비스들의 개발을 부축였다. In a more decentralized digital world, individuals and workgroups often store information and data on many different devices and locations. This has led to the development of data synchronization services that can maintain information in these independent and often other data stores that are always synchronized with minimal user interference.
본 발명의 동기화 플랫폼은, 본 명세서의 섹션 Ⅱ에 기술된 풍부한 저장 플랫폼의 일부이고, 3가지 주목적을 다룬다.The synchronization platform of the present invention is part of the rich storage platform described in section II of this specification and covers three main objectives.
1. 일반적인 용어1. General terms
이하에는 이러한 섹션 Ⅲ.B에서의 후술에 관련된 몇몇 추가의 개선된 정의들 및 주요 컨셉들이 설명된다.In the following, some further improved definitions and key concepts related to the following in section III.B are described.
동기화 복제본(Sync Replica): 대부분의 애플리케이션들은 WinFS 스토어 내의 주어진 서브세트의 아이템들에 대한 변경들을 추적하고, 열거하고 동기화하는데만 관심이 있다. 동기화 동작에 참여하는 아이템들의 세트는 동기화 복제본이라 명명된다. 복제본은 주어진 WinFS 컨테인먼트 계층 내에 포함된 아이템들의 관점으로 정의된다(보통은 폴더 아이템에서 나온다). 모든 동기화 서비스들은 주어진 복제본의 컨텍스트 내에서 수행된다. WinFS 동기화는 복제본들을 정의하고, 관리하고 클린업하는 메카니즘을 제공한다. 모든 복제본은 주어진 WinFS 스토어 내에서 그것을 고유하게 식별하는 GUID 식별자를 갖는다.Sync Replica: Most applications are only interested in tracking, enumerating and synchronizing changes to items of a given subset in the WinFS store. The set of items participating in the synchronization operation is called a synchronization replica. Replicas are defined in terms of items contained within a given WinFS containment hierarchy (usually from folder items). All synchronization services are performed in the context of a given replica. WinFS synchronization provides a mechanism for defining, managing, and cleaning up replicas. Every replica has a GUID identifier that uniquely identifies it within a given WinFS store.
동기화 파트너(Sync Partner): 동기화 파트너는 WinFS 아이템들, 확장들 및 관계들에서의 변경들에 영향을 미칠 수 있는 엔티티로서 정의된다. 따라서, 모든 WinFS 스토어는 동기화 파트너로서 명명될 수 있다. 비-WinFS 스토어와 동기화하는 경우에, EDS(external data source)도 동기화 파트너로서 명명된다. 모든 파트너는 그것을 고유하게 식별하는 GUID 식별자를 갖는다.Sync Partner: A Sync Partner is defined as an entity that can affect changes in WinFS items, extensions and relationships. Thus, all WinFS stores can be named as synchronization partners. In the case of synchronizing with a non-WinFS store, an external data source (EDS) is also named as a synchronization partner. Every partner has a GUID identifier that uniquely identifies it.
Sync 공동체(Sync Community): 동기화 공동체는 피어-투-피어 동기화 동작들에 의해 동기화가 유지되는 복제본들의 집합체로서 정의된다. 이러한 복제본들은 모두 동일한 WinFS 스토어에 있을 수 있고, 상이한 WinFS 스토어들에 있을 수 있고, 또는 심지어 그들 자신을 가상 복제본들로서 비-WinFS 스토어 상에 기재할 수 있다. 특히, 단지 공동체에서의 sync 동작들이 WinFS Sync 서비스(WinFS 어댑터)를 통하는 경우에는, WinFS sync는 공동체를 위한 임의의 특정 토폴로지를 규정하거나 지정하지 않는다. 동기화 어댑터들(나중에 정의함)은 그들 자신의 토폴로지 제약들을 도입할 수 있다.Sync Community: A synchronization community is defined as a collection of replicas whose synchronization is maintained by peer-to-peer synchronization operations. These replicas may all be in the same WinFS store, may be in different WinFS stores, or even list themselves as non-WinFS stores as virtual replicas. In particular, if only sync operations in the community are via the WinFS Sync service (WinFS adapter), WinFS sync does not prescribe or specify any particular topology for the community. Synchronization adapters (defined later) can introduce their own topology constraints.
변경 추적, 변경 유닛들 및 버전들(Change Tracking, Change Units and Versions): 모든 WinFS 스토어는 모든 로컬 WinFS 아이템들, 확장들 및 관계들에 대한 변경들을 추적한다. 변경들은 스키마에 정의된 변경 유닛 입도의 레벨로 추적된다. 임의의 아이템, 확장 및 관계 타입의 상위 필드들은 스키마 설계자에 의해 변경 유닛들로 하위 분할될 수 있고, 이때 최소 입도는 하나의 상위 필드이다. 변경 추적을 위해, 모든 변경 유닛은 버전(Version)으로 할당되는데, 버전은 sync 파트너 id와 버전 넘버(버전 넘버는 파트너 지정 단조 증가 넘버이다)의 쌍이다. 버전들은 스토어에서 국부적으로 변경들이 발생할 때, 또는 변경들이 다른 복제본으로부터 얻어질 때 업데이트된다.Change Tracking, Change Units and Versions: Every WinFS store tracks changes to all local WinFS items, extensions and relationships. Changes are tracked at the level of change unit granularity defined in the schema. Upper fields of any item, extension, and relationship type may be subdivided into change units by the schema designer, where the minimum granularity is one higher field. For change tracking, every change unit is assigned a version, which is a pair of sync partner id and version number (the version number is the partner specific monotonic increment number). Versions are updated when changes occur locally in the store, or when changes are obtained from another replica.
Sync 지식(Sync Knowledge): 지식은 임의의 시간에서의 주어진 sync 복제본의 상태를 나타낸다. 즉 그것은 주어진 복제본이 국부적으로 또는 다른 복제본으로부터 인식하는 모든 변경들에 관한 메타-데이터를 캡슐화한다. WinFS 동기화는 동기화 동작들에 걸쳐 동기화 복제본들에 대한 지식을 유지 및 업데이트한다. 주의해야할 중요한 것은 지식 표시는 그것이 전체 공동체에 대하여 해석되게 하고 지식이 저장되는 특별한 복제본과 관련되지 않게 한다는 것이다. Sync Knowledge: Knowledge represents the state of a given sync copy at any time. That is, it encapsulates meta-data about all changes that a given replica recognizes locally or from another replica. WinFS synchronization maintains and updates knowledge of synchronization replicas across synchronization operations. The important thing to note is that the knowledge label causes it to be interpreted with respect to the entire community and not to the particular copy in which the knowledge is stored.
Sync 어댑터들(Sync Adapters): 동기화 어댑터는 Sync 런타임 API를 통해 WinFS Sync 서비스들에 액세스하고 비-WinFS 데이터 스토어에 대한 WinFS 데이터의 동기화를 가능하게 하는 관리된 코드 애플리케이션이다. 시나리오의 요건들에 따르면, 어떤 WinFS 데이터의 서브세트와 어떤 WinFS 데이터 타입들이 동기화되는지에 관해서는 어댑터 개발자에 달려있다. 어댑터는 EDS와의 통신, EDS 지원 스키마와 WinFS 스키마 사이의 변환, 및 그 자신의 구성 및 메타데이터를 정의 및 관리하는 것에 대한 책임이 있다. 어댑터들은 WinFS Sync 어댑터 API를 구현하여 WinFS Sync 팀에 의해 제공되는 어댑터들에 대한 공통 구성 및 제어 하부구조를 이용하도록 강하게 고무된다. 보다 상세하게는, WinFS Sync 어댑터 API 사양[SADP] 및 WinFS Sync 컨트롤러 API[SCTRL] 사양을 참조하라.Sync Adapters: Synchronization adapters are managed code applications that enable access to WinFS Sync services and synchronization of WinFS data to non-WinFS data stores through the Sync runtime API. Depending on the requirements of the scenario, it is up to the adapter developer to determine which subset of WinFS data and which WinFS data types are synchronized. The adapter is responsible for communicating with EDS, converting between EDS-supported schemas and WinFS schemas, and defining and managing its own configuration and metadata. Adapters are strongly encouraged to implement the WinFS Sync Adapter API to take advantage of the common configuration and control infrastructure for adapters provided by the WinFS Sync team. For more details, see the WinFS Sync Adapter API Specification [SADP] and the WinFS Sync Controller API [SCTRL] specification.
외부 비-WinFS 스토어들에 대한 WinFS 데이터를 동기화시키고, WinFS 포맷의 지식을 생성 또는 유지할 수 없는 어댑터들에 있어서, WinFS Sync는 후속 변경 열거 또는 응용 동작을 위해 사용될 수 있는 원격 지식을 얻기 위한 서비스들을 제공한다. 백엔드 스토어의 능력에 따라, 어댑터는 백엔드 또는 로컬 WinFS 스토어 상에 이러한 원격 지식을 저장하고 싶어할 수 있다.For adapters that synchronize WinFS data to external non-WinFS stores and cannot create or maintain knowledge of the WinFS format, WinFS Sync provides services to obtain remote knowledge that can be used for subsequent change enumeration or application operations. to provide. Depending on the capabilities of the backend store, the adapter may want to store this remote knowledge on the backend or local WinFS store.
간략함을 위해, 동기화 "복제본"은 단일 논리 위치에 존재하는 "WinFS" 스토어의 데이터 세트를 나타내는 구조이고, 비-"WinFS" 스토어 상의 데이터는 "데이터 소스"로 명명되고 일반적으로 어댑터의 사용을 요구한다.For simplicity, a synchronization "replica" is a structure that represents a data set in a "WinFS" store that exists at a single logical location, and the data on a non- "WinFS" store is named a "data source" and generally uses the adapter. Require.
원격 지식(Remote Knowledge): 주어진 sync 복제본이 또 다른 복제본으로부터 변경들을 획득하고자 하면, 그것은 다른 복제본이 열거하는 기준선이 변할때 자신의 지식을 제공한다. 마찬가지로, 주어진 복제본이 또 다른 복제본으로 변경들을 보내고자 하면, 그것은 충돌들의 검출을 위해 원격 복제본에 의해 사용될 수 있는 기준선으로서 자신의 지식을 제공한다. 이러한 sync 변경 열거 및 응용 동안 제공되는 다른 복제본에 관한 지식은 원격 지식이라 명명된다.Remote Knowledge: If a given sync replica wants to acquire changes from another replica, it provides its knowledge when the baseline listed by another replica changes. Likewise, if a given replica wants to send changes to another replica, it provides its knowledge as a baseline that can be used by the remote replica for the detection of collisions. Knowledge of other replicas provided during this sync change enumeration and application is called remote knowledge.
2. 동기화 API 주체2. Synchronization API principal
특정 실시예들에서, 동기화 API는 두 파트로 분리된다: 동기화 구성 API 및 동기화 컨트롤러 API. 동기화 구성 API는 애플리케이션들이 동기화를 구성하고 2개의 복제본들 사이에서 특정 동기화 세션용 파라미터들을 규정하는 것을 허용한다. 주어진 동기화 세션에 있어서, 구성 파라미터들은 동기화될 아이템들의 세트, 동기화의 타입(일방향 또는 양방향), 원격 데이터 소스에 관한 정보, 및 충돌 레졸루션 정책을 포함한다. 동기화 컨트롤러 API는 동기화 세션을 개시하고, 동기화를 취소하고, 진행중인 동기화에 관한 진행 및 오류 정보를 수신한다. 또한, 미리 결정된 스케쥴에서 동기화가 수행될 필요가 있는 특정 실시예들에서는, 이러한 시스템들은 스케쥴링을 맞춤화할 스케쥴링 메카니즘을 포함할 수 있다.In certain embodiments, the synchronization API is divided into two parts: the synchronization configuration API and the synchronization controller API. The synchronization configuration API allows applications to configure synchronization and specify parameters for a particular synchronization session between two replicas. For a given synchronization session, the configuration parameters include the set of items to be synchronized, the type of synchronization (one or two way), information about the remote data source, and the conflict resolution policy. The synchronization controller API initiates a synchronization session, cancels the synchronization, and receives progress and error information regarding the ongoing synchronization. Also, in certain embodiments where synchronization needs to be performed at a predetermined schedule, such systems may include a scheduling mechanism to customize the scheduling.
본 발명의 여러 실시예들은 "WinFS" 및 비-"WinFS" 데이터 소스들 사이의 정보를 동기화하기 위해 동기화 어댑터들을 채용한다. 어댑터들의 예들은 "WinFS" 컨택트 폴더와 비-WinFS 메일박스 사이에서 주소록 정보를 동기화시키는 어댑터를 포함한다. 이러한 예들에서는, 어댑터 개발자들은 "WinFS" 스키마와 비-"WinFS" 데이터 소스 스키마 사이에서 스키마 변환 코드를 개발하기 위해 "WinFS" 동기화 플랫폼에 의해 제공되는 서비스들을 액세싱하기 위해 여기에 설명된 "WinFS" 동기화 코어 서비스들 API을 사용할 수 있다. 부가적으로, 어댑터 개발지는 비-"WinFS" 데이터 소스와 변경들을 통신하기 위해 프로토콜 지원을 제공한다. 동기화 어댑터는 동기화 컨트롤러 API를 사용하여 호출 및 제어되고 이러한 API를 사용하여 진행 및 오류들을 보고한다.Various embodiments of the present invention employ synchronization adapters to synchronize information between "WinFS" and non- "WinFS" data sources. Examples of adapters include an adapter that synchronizes address book information between a "WinFS" contact folder and a non-WinFS mailbox. In these examples, adapter developers may use the "WinFS" described herein to access the services provided by the "WinFS" synchronization platform to develop schema conversion code between a "WinFS" schema and a non- "WinFS" data source schema. "You can use the synchronization core services API. Additionally, adapter development provides protocol support for communicating changes with non- "WinFS" data sources. The synchronization adapter is called and controlled using the synchronization controller API and reports progress and errors using this API.
그러나, 본 발명의 어떤 실시예들에서는, "WinFS" 데이터 스토어를 또 다른 "WinFS" 데이터 스토어와 동기화시키는 경우에, "WinFS"에서 "WinFS"로의 동기화 서비스들이 하드웨어/소프트웨어 인터페이스 시스템 내에 통합되면, 동기화 어댑터는 불필요할 수 있다. 임의의 경우, 여러 이러한 실시예들은 "WinFS" 대 "WinFS" 및 이하를 포함하는 동기화 어댑터 솔루션들 모두에 대해 동기화 서비스들의 세트를 제공한다:However, in some embodiments of the present invention, when synchronizing a "WinFS" data store with another "WinFS" data store, if synchronization services from "WinFS" to "WinFS" are integrated into the hardware / software interface system, The synchronization adapter may be unnecessary. In any case, several such embodiments provide a set of synchronization services for all of the synchronization adapter solutions including "WinFS" to "WinFS" and the following:
도 36을 참조하면, 공통 데이터 스토어의 3가지 인스턴스와 그들을 동기화시키는 컴포넌트들이 도시된다. 제1 시스템(3602)은 이용을 위해 동기화 API(3652)를 노출시키는(3646), WinFS-대-WinFS 동기화 서비스들(3622), 및 WinFS-대-비WinFS 동기화를 위한 코어 동기화 서비스들(3624)을 포함하는 WinFS 데이터 스토어(3612)를 갖는다. 제1 시스템(3602)과 마찬가지로, 제2 시스템(3604)은 이용을 위해 동기화 API(3652)를 노출시키는(3646), WinFS-대-WinFS 동기화 서비스들(3632), 및 WinFS-대-비WinFS 동기화를 위한 코어 동기화 서비스들(3634)을 포함하는 WinFs 데이터 스토어(3614)를 갖는다. 제1 시스템(3602) 및 제2 시스템(3604)는 그들 각각의 WinFS-대-WinFS 동기화 서비스들(3622, 3632)을 통해 동기화한다(3642). 제3 시스템(3606)은 WinFS 시스템이 아니며, WinFS 복제본들을 갖는 동기화 공동체 내의 데이터 소스를 유지하기 위해 WinFS 동기화(3666)를 사용하는 애플리케이션을 갖는다. 이 애플리케이션은 WinFS 동기화 구성/제어 서비스(3664)를 사용하여 WinFS 대 WinFS 동기화 서비스들(3622)을 통해(WinFS 데이터 스토어로서 그 자신을 가상화할 수 있는 경우) 또는 동기화 API(3652)와 인터페이스(3648)하는 동기화 어댑터(3662)를 통해 WinFS 데이터 스토어(3612)와 직접 인터페이스(3644)할 수 있다.Referring to FIG. 36, three instances of a common data store and components that synchronize them are shown. The
이 도면에 예시되어 있는 바와 같이, 제1 시스템(3602)은 제2 시스템(3604) 및 제3 시스템(3606) 모두를 인식하고 있으며 직접 양자와 동기한다. 그러나, 제2 시스템(3604)과 제3 시스템(3606)은 어느 것도 서로를 인식하지 못하기 때문에, 서로와 직접 그들의 변경들을 동기시킬 수 없고, 대신, 하나의 시스템에서 발생하는 변경들은 제1 시스템(3602)을 통해서 전파해야 한다.As illustrated in this figure, the
C. 동기화 API 서비스들C. Synchronization API Services
본 발명의 여러 실시예들은 2가지 기본적인 서비스들, 즉 변경 열거 및 변경 응용을 포함하는 동기화 서비스들에 관한 것이다.Various embodiments of the present invention relate to two basic services, synchronization services including change enumeration and change application.
1. 변경 열거1. Change enumeration
전술한 바와 같이, 변경 열거는, 동기화 서비스에 의해 유지되는 변경-추적 데이터에 기초하여 이 파트너와의 최종 시간 동기화가 시도된 이래로, 동기화 어댑터들이 발생된 변경들을 데이터 스토어 폴더로 용이하게 열거할 수 있게 한다. 변경 열거와 관련하여, 본 발명의 여러 실시예들은 이하에 관한 것이다:As mentioned above, change enumeration can easily enumerate changes generated by synchronization adapters into the data store folder since the last time synchronization with this partner was attempted based on the change-tracking data maintained by the synchronization service. To be. Regarding change enumeration, various embodiments of the present invention relate to:
2. 변경 응용2. Change Application
상술한 바와 같이, 어댑터들은 저장 플랫폼 스키마에 대한 변경들을 변환하도록 기대되기 때문에, 변경 응용은 동기화 어댑터들로 하여금 그들의 백엔드로부터 수신된 변경들을 로컬 저장 플랫폼에 응용할 수 있게 한다. 변경 응용과 관련하여, 본 발명의 여러 실시예들은 이하에 관한 것이다:As mentioned above, because adapters are expected to translate changes to the storage platform schema, the change application allows synchronization adapters to apply changes received from their backend to the local storage platform. In connection with the modification application, various embodiments of the present invention relate to:
3. 샘플 코드3. Sample Code
이하는 FOO 동기화 어댑터가 동기화 런터임과 상호작용하는 방법에 관한 코드 샘플이다(여기서 모든 어댑터 특정 기능들은 FOO로 프리픽스(prefix)된다).The following is a code sample of how a FOO sync adapter interacts with a synchronization runtime (where all adapter specific functions are prefixed with FOO).
4. API 동기화의 메서드4. Methods of API Synchronization
본 발명의 일 실시예에서, WinFS 스토어와 비-WinFS 스토어 사이의 동기화가 달성되는 것은 WinFS-기반 하드웨어/소프트웨어 인터페이스 시스템에 의해 노출되는 동기화 API들을 통해서 가능하다.In one embodiment of the present invention, synchronization between a WinFS store and a non-WinFS store is achieved through synchronization APIs exposed by a WinFS-based hardware / software interface system.
일 실시예에서, 모든 동기화 어댑터들은 동기화 어댑터 API, CLR(common language runtime) 관리 API를 구현하기 위해 요구되기 때문에, 일관적으로 배치되고, 초기화되고 제어될 수 있다. 어댑터 API는 이하를 제공한다:In one embodiment, all synchronization adapters may be consistently deployed, initialized, and controlled because they are required to implement a synchronization adapter API, a common language runtime (CLR) management API. The adapter API provides the following:
시나리오의 요건들에 따라, 어댑터들에 대한 2가지 가능한 프로세스 모델이 존재한다. 어댑터는 그것을 호출하고 있는 애플리케이션과 동일한 프로세스 스페이스에서 또는 독립적인 프로세스에서 모두를 스스로 실행할 수 있다. 그 자신의 독립적인 프로세스에서 실행하기 위해, 어댑터는 자신의 팩토리 클래스를 정의하는데, 이것은 어댑터를 인스턴스화하는데 사용된다. 팩토리는 호출중인 애플리케이션과 동일한 프로세스에서 어댑터의 인스턴스를 반환하거나, 상이한 마이크로소프트 공통 언어 런타임 애플리케이션 도메인 또는 프로세스에서 어댑터의 원격 인스턴스를 반환할 수 있다. 동일한 프로세스에서 어댑터를 인스턴스화하는 디폴트 팩토리 구현이 제공된다. 실제로, 많은 어댑터들은 호출중인 애플리케이션과 동일한 프로세스에서 실행할 것이다. 프로세스 외 모델은 보통 이하의 이유들중 하나 또는 모두를 위해 요구된다.Depending on the requirements of the scenario, there are two possible process models for the adapters. The adapter can run itself in the same process space as the application calling it, or in an independent process. To run in its own independent process, an adapter defines its own factory class, which is used to instantiate the adapter. The factory can return an instance of the adapter in the same process as the calling application, or a remote instance of the adapter in a different Microsoft common language runtime application domain or process. A default factory implementation is provided that instantiates the adapter in the same process. In fact, many adapters will run in the same process as the calling application. An out-of-process model is usually required for one or both of the following reasons.
도 37을 참조하면, 본 발명의 일 실시예는 상태가 산출되는 방법 또는 그 관련 메타데이터가 교환되는 방법을 알지 못하는 간단한 어댑터를 가정한다. 이러한 실시예에서, 동기화하고자 하는 데이터 소스와 관련하여, 동기화는 복제본에 의해 실현되는데, 우선, 단계 3702에서, 그것이 마지막으로 상기 데이터 소스와 동기화된 이래로 어떤 변경들이 발생했는지를 결정하고, 그후 복제본은 그것의 현재 상태 정보에 기초하여 이 마지막 동기화 이래로 발생한 증분 변경들을 전송하고, 이러한 현재 상태 정보 및 증분 변경들은 어댑터를 통해 데이터 소스로 전달된다. 단계 3704에서, 어댑터는, 이전 단계에서 복제본으로부터의 변경 데이터를 수신하면, 가능한 많은 데이터 소스에 대한 변경들을 이행하고, 어떤 변경들이 성공했는지와 어떤 것이 실패했는지를 추적하고, 성공 및 실패 정보를 다시 (복제본의) WinFS로 전달한다. 복제본의 하드웨어/소프트웨어 인터페이스 시스템(WinFS)은, 단계 3706에서, 복제본으로부터 성공 및 실패 정보를 수신하면, 데이터 소스에 대한 새로운 상태 정보를 산출하고, 미래에 그 복제본이 사용하기 위해 이러한 정보를 저장하고, 이러한 새로운 상태 정보를 다시 데이터 소스, 즉 어댑터에 의한 저장 및 후속 사용을 위해 어댑터에 전달한다. Referring to FIG. 37, an embodiment of the present invention assumes a simple adapter that does not know how a state is calculated or how its associated metadata is exchanged. In this embodiment, with respect to the data source to be synchronized, synchronization is realized by the replica, which, first, in
D. 동기화 스키마의 추가 양태들D. Additional Aspects of the Synchronization Schema
본 발명의 다양한 실시예들에 대한 동기화 스키마의 추가적인(보다 상세한) 양태들이 후술된다.Additional (more detailed) aspects of the synchronization schema for various embodiments of the present invention are described below.
복제본들의 동기화 스키마 및 사용은 진정한 분산형 피어-투-피어 멀티마스터 동기화 공동체를 인에이블한다. 또한, 동기화 공동체 타입은 없지만 동기화 공동체는 복제본들 자신의 공동체 필드값으로서 간단히 존재한다.The synchronization scheme and use of replicas enable a truly distributed peer-to-peer multimaster synchronization community. Also, there is no synchronization community type, but the synchronization community simply exists as a replica's own community field value.
모든 복제본은 증분 변경 열거를 추적하고 동기화 공동체에 공지되어 있는 다른 복제본들에 대한 상태 정보를 저장하기 위해 자신의 메타데이터를 갖는다.Every replica has its own metadata to keep track of incremental change enumerations and to store state information about other replicas known to the synchronization community.
변경 유닛은 자신의 메타데이터를 갖고, 파트너 키 플러스 파트너 변경 넘버를 포함하는 버전, 각 변경 유닛에 대한 아이템/확장/관계 버전화; 복제본이 동기화 공동체로부터 본/수신한 변경들에 관한 지식; GUID 및 로컬 ID 구성; 및 클린업을 위해 참조 관계에 저장된 GUID를 포함한다.The change unit has its own metadata, a version including the partner key plus partner change number, item / extension / relational versioning for each change unit; Knowledge of changes the replica saw / received from the synchronization community; GUID and local ID configuration; And a GUID stored in a reference relationship for cleanup.
Ⅳ. 결론Ⅳ. conclusion
위에서 예시한 바와 같이, 본 발명은 데이터를 조직하고, 검색하고, 공유하기 위한 저장 플랫폼에 관한 것이다. 본 발명의 저장 플랫폼은 기존의 파일 시스템 및 데이터베이스 시스템을 넘어서 데이터 저장의 개념을 확장하고 넓히며, 관계 (표 형태의) 데이터, XML, 및 아이템이라고 불리는 새로운 형태의 데이터와 같은 구조화된, 또는 비구조화된, 또는 반구조화된 데이터를 포함하는 데이터의 모든 타입들에 대한 스토어가 되도록 설계되어 있다. 그것의 공통의 저장 토대 및 조직적으로 배열된 데이터를 통하여, 본 발명의 저장 플랫폼은 소비자, 지식 노동자 및 기업에게 보다 효율적인 애플리케이션 개발을 가능케 한다. 그것은 그것의 데이터 모델 내에 고유한 능력들을 이용할 수 있게 할 뿐만 아니라, 기존의 파일 시스템 및 데이터베이스 액세스 방법들도 포용하고 확장하는 풍부하고 확장성이 있는 애플리케이션 프로그래밍 인터페이스를 제공한다. 본 발명의 넓은 발명적 개념을 벗어나지 않고 위에서 설명한 실시예들에 대해 변경이 행해질 수 있음은 물론이다. 따라서, 본 발명은 개시된 특정 실시예들에 한정되지 않고, 첨부된 청구의 범위에 의해 정의된 발명의 요지 및 범위 내에 있는 모든 변형들을 망라하도록 의도되어 있다.As illustrated above, the present invention relates to a storage platform for organizing, retrieving, and sharing data. The storage platform of the present invention extends and broadens the concept of data storage beyond existing file systems and database systems, and is structured or unstructured such as relational (tabular) data, XML, and new forms of data called items. It is designed to be a store for all types of data, including formatted or semi-structured data. Through its common storage foundation and systematically arranged data, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises. It not only enables the inherent capabilities within its data model, but also provides a rich and extensible application programming interface that embraces and extends existing file system and database access methods. Of course, changes may be made to the embodiments described above without departing from the broad inventive concept of the invention. Accordingly, the invention is not intended to be limited to the specific embodiments disclosed and is intended to cover all modifications that fall within the spirit and scope of the invention as defined by the appended claims.
위로부터 명백히 알 수 있는 바와 같이, 본 발명의 갖가지 시스템, 방법, 및 양태들의 전부 또는 일부는 프로그램 코드(즉, 명령어)의 형태로 구현될 수 있다. 이 프로그램 코드는 플로피 디스크, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, 자기 테이프, 플래시 메모리, 하드 디스크 드라이브, 또는 임의의 다른 기계 판독가능한 저장 매체를 포함하지만 이들에 한정되지 않는 자기적, 전기적 및 광학적 저장 매체와 같은 컴퓨터 판독가능한 매체 상에 저장될 수 있고, 프로그램 코드는 컴퓨터 또는 서버와 같은 기계에 로딩되어 그 기계에 의해 실행되고, 그 기계는 본 발명을 실시하기 위한 장치가 된다. 본 발명은 또한 예컨대, 전기 배선 또는 케이블링을 통하여, 광섬유를 통하여, 인터넷 또는 인트라넷을 포함하는 네트워크를 통하여, 또는 임의의 다른 전송 형태와 같은, 어떤 전송 매체를 통하여 전송되는 프로그램 코드의 형태로 구현될 수도 있는데, 프로그램 코드는 컴퓨터와 같은 기계에 로딩되어 그 기계에 의해 실행되고, 그 기계는 본 발명을 실시하기 위한 장치가 된다. 범용 프로세서 상에서 실행될 때, 프로그램 코드는 그 프로세서와 조합하여 특정 논리 회로들과 유사하게 동작하는 독특한 장치를 제공한다. As will be apparent from the above, all or some of the various systems, methods, and aspects of the present invention may be implemented in the form of program code (ie, instructions). This program code includes, but is not limited to, floppy disks, CD-ROMs, CD-RWs, DVD-ROMs, DVD-RAMs, magnetic tapes, flash memories, hard disk drives, or any other machine readable storage media. Can be stored on a computer readable medium, such as magnetic, electrical and optical storage media, the program code being loaded into a machine such as a computer or a server, and executed by the machine, the machine being an apparatus for practicing the present invention. Becomes The invention is also embodied in the form of program code transmitted via any transmission medium, such as via electrical wiring or cabling, via an optical fiber, via a network comprising the Internet or an intranet, or any other form of transmission. The program code may be loaded into a machine such as a computer and executed by the machine, and the machine becomes an apparatus for practicing the present invention. When executed on a general purpose processor, the program code provides a unique apparatus that, in combination with the processor, operates similarly to specific logic circuits.
Claims (27)
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/646,632 US7529811B2 (en) | 2003-08-21 | 2003-08-21 | Systems and methods for the implementation of a core schema for providing a top-level structure for organizing units of information manageable by a hardware/software interface system |
| USPCT/US03/26144 | 2003-08-21 | ||
| US10/646,632 | 2003-08-21 | ||
| PCT/US2003/026144 WO2005029313A1 (en) | 2003-08-21 | 2003-08-21 | Systems and methods for data modeling in an item-based storage platform |
| US10/693,362 US8166101B2 (en) | 2003-08-21 | 2003-10-24 | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
| US10/693,362 | 2003-10-24 | ||
| PCT/US2004/024287 WO2005024626A1 (en) | 2003-08-21 | 2004-07-29 | Systems for the implementation of a synchronization schemas |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20070083241A KR20070083241A (en) | 2007-08-24 |
| KR101109399B1 true KR101109399B1 (en) | 2012-01-30 |
Family
ID=34279605
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020057012324A KR101109399B1 (en) | 2003-08-21 | 2004-07-29 | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP1573508A4 (en) |
| JP (1) | JP4583375B2 (en) |
| KR (1) | KR101109399B1 (en) |
| CN (1) | CN1739093B (en) |
| WO (1) | WO2005024626A1 (en) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
| US8131739B2 (en) | 2003-08-21 | 2012-03-06 | Microsoft Corporation | Systems and methods for interfacing application programs with an item-based storage platform |
| 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 |
| US7805422B2 (en) | 2005-02-28 | 2010-09-28 | Microsoft Corporation | Change notification query multiplexing |
| US7788163B2 (en) * | 2005-03-11 | 2010-08-31 | Chicago Mercantile Exchange Inc. | System and method of utilizing a distributed order book in an electronic trade match engine |
| US7991740B2 (en) * | 2008-03-04 | 2011-08-02 | Apple Inc. | Synchronization server process |
| WO2012047138A1 (en) * | 2010-10-04 | 2012-04-12 | Telefonaktiebolaget L M Ericsson (Publ) | Data model pattern updating in a data collecting system |
| TWI497311B (en) * | 2013-03-28 | 2015-08-21 | Quanta Comp Inc | Inter-device communication transmission system and method thereof |
| US9542467B2 (en) | 2013-11-18 | 2017-01-10 | International Business Machines Corporation | Efficiently firing mapping and transform rules during bidirectional synchronization |
| US10402744B2 (en) | 2013-11-18 | 2019-09-03 | International Busniess Machines Corporation | Automatically self-learning bidirectional synchronization of a source system and a target system |
| US9367597B2 (en) | 2013-11-18 | 2016-06-14 | International Business Machines Corporation | Automatically managing mapping and transform rules when synchronizing systems |
| US10628424B2 (en) | 2016-09-15 | 2020-04-21 | Oracle International Corporation | Graph generation for a distributed event processing system |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5893106A (en) | 1997-07-11 | 1999-04-06 | International Business Machines Corporation | Object oriented server process framework with interdependent-object creation |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69625751T2 (en) * | 1995-07-07 | 2003-10-02 | Sun Microsystems Inc | Method and system for synchronizing execution of events when testing software |
| US5774717A (en) * | 1995-12-15 | 1998-06-30 | International Business Machines Corporation | Method and article of manufacture for resynchronizing client/server file systems and resolving file system conflicts |
| US6553391B1 (en) * | 2000-06-08 | 2003-04-22 | International Business Machines Corporation | System and method for replicating external files and database metadata pertaining thereto |
| EP1187421A3 (en) * | 2000-08-17 | 2004-04-14 | FusionOne, Inc. | Base rolling engine for data transfer and synchronization system |
| AU2002303126A1 (en) * | 2001-03-16 | 2002-10-03 | Novell, Inc. | Client-server model for synchronization of files |
| US7711771B2 (en) * | 2001-05-25 | 2010-05-04 | Oracle International Corporation | Management and synchronization application for network file system |
| CA2467404A1 (en) * | 2001-11-15 | 2003-05-30 | Visto Corporation | System and methods for asychronous synchronization |
| GB0128243D0 (en) * | 2001-11-26 | 2002-01-16 | Cognima Ltd | Cognima patent |
-
2004
- 2004-07-29 WO PCT/US2004/024287 patent/WO2005024626A1/en active Application Filing
- 2004-07-29 KR KR1020057012324A patent/KR101109399B1/en active IP Right Grant
- 2004-07-29 CN CN2004800023968A patent/CN1739093B/en not_active Expired - Fee Related
- 2004-07-29 JP JP2006523856A patent/JP4583375B2/en not_active Expired - Fee Related
- 2004-07-29 EP EP04757348A patent/EP1573508A4/en not_active Ceased
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5893106A (en) | 1997-07-11 | 1999-04-06 | International Business Machines Corporation | Object oriented server process framework with interdependent-object creation |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1739093A (en) | 2006-02-22 |
| CN1739093B (en) | 2010-05-12 |
| KR20070083241A (en) | 2007-08-24 |
| WO2005024626A1 (en) | 2005-03-17 |
| EP1573508A1 (en) | 2005-09-14 |
| JP4583375B2 (en) | 2010-11-17 |
| JP2007503049A (en) | 2007-02-15 |
| EP1573508A4 (en) | 2006-04-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7483923B2 (en) | Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system | |
| US8166101B2 (en) | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system | |
| US7512638B2 (en) | Systems and methods for providing conflict handling for peer-to-peer synchronization of units of information manageable by a hardware/software interface system | |
| US7743019B2 (en) | Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system | |
| US7590643B2 (en) | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system | |
| US7401104B2 (en) | Systems and methods for synchronizing computer systems through an intermediary file system share or device | |
| CA2512185C (en) | Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system | |
| KR20060113353A (en) | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system | |
| KR101022936B1 (en) | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system | |
| KR101109399B1 (en) | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system | |
| JP4580389B2 (en) | System and method for synchronizing computer systems via an intermediary file system share or intermediary device | |
| KR101109390B1 (en) | Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system | |
| NZ540221A (en) | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system |
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: 20141230 Year of fee payment: 4 |
|
| FPAY | Annual fee payment |
Payment date: 20151217 Year of fee payment: 5 |
|
| FPAY | Annual fee payment |
Payment date: 20161220 Year of fee payment: 6 |
|
| FPAY | Annual fee payment |
Payment date: 20171219 Year of fee payment: 7 |
|
| FPAY | Annual fee payment |
Payment date: 20181226 Year of fee payment: 8 |
|
| FPAY | Annual fee payment |
Payment date: 20191217 Year of fee payment: 9 |