WO2005029313A1 - Systems and methods for data modeling in an item-based storage platform - Google Patents

Systems and methods for data modeling in an item-based storage platform Download PDF

Info

Publication number
WO2005029313A1
WO2005029313A1 PCT/US2003/026144 US0326144W WO2005029313A1 WO 2005029313 A1 WO2005029313 A1 WO 2005029313A1 US 0326144 W US0326144 W US 0326144W WO 2005029313 A1 WO2005029313 A1 WO 2005029313A1
Authority
WO
WIPO (PCT)
Prior art keywords
item
items
computer
folder
relationship
Prior art date
Application number
PCT/US2003/026144
Other languages
English (en)
French (fr)
Inventor
Anil K. Nori
Sameet Agarwal
J. Patrick Thompson
Pedro Celis
David G. Campbell
Soner F. Terek
Kim Cameron
Walter R. Smith
Darren A. Shakib
Nathaniel H. Ballou
Srinivasmurthy P. Acharya
Balan Sethu Raman
Peter M. Spiro
Original Assignee
Microsoft Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corporation filed Critical Microsoft Corporation
Priority to CNB038269430A priority Critical patent/CN100570549C/zh
Priority to MXPA06001986A priority patent/MXPA06001986A/es
Priority to PCT/US2003/026144 priority patent/WO2005029313A1/en
Priority to BRPI0318469-2A priority patent/BR0318469A/pt
Priority to KR1020067003584A priority patent/KR101024730B1/ko
Priority to EP03818743A priority patent/EP1658555A4/en
Priority to CA2533088A priority patent/CA2533088C/en
Priority to AU2003259959A priority patent/AU2003259959B2/en
Priority to JP2005509096A priority patent/JP4394643B2/ja
Priority to TW093122603A priority patent/TWI337310B/zh
Priority to KR1020057009283A priority patent/KR20060113353A/ko
Priority to EP04757348A priority patent/EP1573508A4/en
Priority to MXPA05006260A priority patent/MXPA05006260A/es
Priority to PCT/US2004/024569 priority patent/WO2005024666A2/en
Priority to KR1020057012324A priority patent/KR101109399B1/ko
Priority to PCT/US2004/024287 priority patent/WO2005024626A1/en
Priority to EP04779583A priority patent/EP1604310A4/en
Priority to CA2506337A priority patent/CA2506337C/en
Priority to CN2004800023968A priority patent/CN1739093B/zh
Priority to CA2815867A priority patent/CA2815867C/en
Priority to AU2004271531A priority patent/AU2004271531B2/en
Priority to PCT/US2004/024437 priority patent/WO2005024550A2/en
Priority to RU2005119974/07A priority patent/RU2412475C2/ru
Priority to JP2006523871A priority patent/JP4580390B2/ja
Priority to JP2006523867A priority patent/JP4901472B2/ja
Priority to KR1020057012318A priority patent/KR101022936B1/ko
Priority to BR0406512-3A priority patent/BRPI0406512A/pt
Priority to JP2006523856A priority patent/JP4583375B2/ja
Priority to CA2815562A priority patent/CA2815562C/en
Priority to CN2004800015016A priority patent/CN101416153B/zh
Priority to EP04779482A priority patent/EP1620781A4/en
Priority to CN200480001833.4A priority patent/CN1871598B/zh
Publication of WO2005029313A1 publication Critical patent/WO2005029313A1/en
Priority to NO20052052A priority patent/NO20052052L/no
Priority to IL168666A priority patent/IL168666A/en

Links

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • 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
    • G06F16/288—Entity relationship models
    • 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/289—Object oriented databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units

Definitions

  • MSFT-1749 filed on even date herewith, entitled “SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION”; U.S. Patent Application No. (not yet assigned) (Atty. Docket No. MSFT-1750), filed on even date herewith, entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; U.S. Patent Application No. (not yet assigned) (Atty. Docket No.
  • MSFT-1751 filed on even date herewith, 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”; U.S. Patent Application No. (not yet assigned) (Atty. Docket No. MSFT-1752), filed on even date herewith, entitled “SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; U.S. Patent Application No. (not yet assigned) (Atty.
  • the present invention relates generally to the field of information storage and retrieval, and, more particularly, to an active storage platform for organizing, searching, and sharing different types of data in a computerized system.
  • Multics used symbolic addresses within a hierarchy of files (thereby introducing the idea of a file path) where physical addresses of the files were not transparent to the user (applications and end-users).
  • This file system was entirely unconcerned with the file format of any individual file, and the relationships amongst and between files was deemed irrelevant at the operating system level (that is, other than the location of the file within the hierarchy). Since the advent of Multics, storable data has been organized into files, folders, and directories at the operating system level. These files generally include the file hierarchy itself (the "directory") embodied in a special file maintained by the file system. This directory, in turn, maintains a list of entries corresponding to all of the other files in the directory and the nodal location of such files in the hierarchy (herein referred to as the folders). Such has been the state of the art for approximately forty years.
  • the basic relational model does not provide a sufficient platform for storage of data on which higher-level applications can easily be developed because the basic relational model requires a level of indirection between the application and the storage system— where the semantic structure of the data might only be visible in the application in certain instances.
  • the present invention is directed to a storage platform for organizing, searching, 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 designed to be the store for all types of data including structured, non-structured, or semi- structured data.
  • the storage platform of the present invention comprises a data store implemented on a database engine.
  • the database engine comprises a relational database engine with object relational extensions.
  • the data store implements a data model that supports organization, searching, 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 provides by the schemas).
  • a synchronization capability facilitates the sharing of data among users or systems.
  • File-system-like capabilities are provided that allow interoperability of the data store with existing file systems but without the limitation of such traditional file systems.
  • a change tracking mechanism provides the ability track changes to the data store.
  • the storage platform further comprises a set of application program interfaces that enable applications to access all of the foregoing capabilities of the storage platform and to access the data described in the schemas.
  • the data model implemented by the data store defines units of data storage in terms of items, elements, and relationships.
  • An item is a unit of data storable in a data store and can comprise one or more elements and relationships.
  • An element is an instance of a type comprising one or more fields (also referred to herein as a property).
  • a relationship is a link between two items.
  • a computer system comprises a plurality of Items where each Item constitutes a discrete storable unit of information that can be manipulated by a hardware/software interface system; a plurality of Item Folders that constitute an organizational structure for said Items; and a hardware/software interface system for manipulating a plurality of Items and wherein each Item belongs to at least one Item Folder and may belong to more than one Item Folder.
  • a computer system comprises a plurality of Items, where each Item constitutes a discrete unit of information that can be manipulated by a hardware/software interface system, and the Item or some of the Item's property values are computed dynamically as opposed to being derived from a persistent store.
  • the hardware/software interface system does not require that the Item be stored, and certain operations are supported such as the ability to enumerate the current set of Items or the ability to retrieve an Item given its identifier (which is more fully described in the sections that describe the application programming interface, or API) of the storage platform — for example, an Item might be the current location of a cell phone or the temperature reading on a temperature sensor.
  • a hardware/software interface system for a computer system wherein said hardware/software interface system manipulates a plurality of Items, further comprises Items interconnected by a plurality of Relationships managed by the hardware/software interface system.
  • a hardware/software interface system for a computer system wherein said hardware/software interface system manipulates a plurality of discrete units of information having properties understandable by said hardware/software interface system.
  • a hardware/software interface system for a computer system comprises a core schema to define a set of core Items which said hardware/software interface system understands and can directly process in a predetermined and predictable way.
  • a method for manipulating a plurality of discrete units of information (“Items") in a hardware/software interface system for a computer system comprising interconnecting said Items with a plurality of Relationships and managing said Relationships at the hardware/software interface system level, is disclosed.
  • the API of the storage platform provides data classes for each item, item extension, and relationship defined in the set of storage platform schemas.
  • the application programming interface provides a set of framework classes that define a common set of behaviors for the data classes and that, together with the data classes, provide the basic programming model for the storage platform API.
  • the storage platform API provides a simplified query model that enables application programmers to form queries based on various properties of the items in the data store, in a manner that insulates the application programmer from the details of the query language of the underlying database engine.
  • the API collects changes to an item made by an application program and then organizes them into the correct updates required by the database engine (or any kind of storage engine) on which the data store is implemented. This enables application programmers to make changes to an item in memory, while leaving the complexity of data store updates to the API. [0019] Through its common storage foundation and schematized data, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises.
  • Fig. 1 is a block diagram representing a computer system in which aspects of the present invention may be incorporated
  • Fig. 2 is a block diagram illustrating a computer system divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component
  • Fig. 1 is a block diagram representing a computer system divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component
  • Fig. 2 is a block diagram illustrating a computer system divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component
  • FIG. 2A illustrates the traditional tree-based hierarchical structure for files grouped in folders in a directory in a file-based operating system
  • FIG. 3 is a block diagram illustrating a storage platform in accordance with the present invention
  • Fig. 4 illustrates the structural relationship between Items, Item Folders, and Categories in various embodiments of the present invention
  • Fig. 5A is a block diagram illustrating the structure of an Item
  • Fig. 5B is a block diagram illustrating the complex property types of the Item of Fig. 5 A
  • Fig. 5A is a block diagram illustrating the complex property types of the Item of Fig. 5 A
  • FIG. 5C is a block diagram illustrating the "Location" Item wherein its complex types are further described (explicitly listed);
  • Fig. 6 A illustrates an Item as a subtype of the Item found in the Base Schema;
  • Fig. 6B is a block diagram illustrating the subtype Item of Fig. 6A wherein its inherited types are explicitly listed (in addition to its immediate properties);
  • Fig. 7 is a block diagram illustrating the Base Schema including its two top- level class types, Item and PropertyBase, and the additional Base Schema types derived therefrom;
  • Fig. 8A is a block diagram illustrating Items in the Core Schema; [0034] Fig.
  • FIG. 13 is a diagram illustrating a notification mechanism, in accordance with an embodiment of the present invention.
  • Fig. 14 is a diagram illustrating an example in which two transactions are both inserting a new record into the same B-Tree;
  • Fig. 15 illustrates a data change detection process in accordance with an embodiment of the present invention;
  • Fig. 16 illustrates an exemplary directory tree;
  • Fig. 17 shows an example in which an existing folder of a directory-based file system is moved into the storage platform data store in accordance with an aspect of the present invention;
  • Fig. 18 illustrates the concept of Containment Folders, in accordance with an aspect of the present invention; [0045] Fig.
  • FIG. 19 illustrates the basic architecture of the storage platform API; [0046] Fig. 20 schematically represents the various components of the storage platform API stack; [0047] Figs. 21A and 21B are a pictorial representation of an exemplary Contacts schema (Items and Elements); [0048] Fig. 22 illustrates the runtime framework of the storage platform API, in accordance with an aspect of the present invention; [0049] Fig. 23 illustrates the execution of a FindAll operation, in accordance with an embodiment of the present invention; [0050] Fig. 24 illustrates the process by which storage platform API classes are generated from the storage platform Schema, in accordance with an aspect of the present invention; [0051] Fig.
  • FIG. 25 illustrates a schema on which a File API is based, in accordance with another aspect of the present invention
  • Fig. 26 is a diagram illustrating an access mask format used for data security purposes, in accordance with an embodiment of the present invention
  • Figs. 27(a), (b), and (c) depict a new identically protected security region being carved out of an existing security region, in accordance with an embodiment of one aspect of the present invention
  • Fig. 28 is a diagram illustrating the concept of an Item search view, in accordance with an embodiment of one aspect of the present invention
  • Fig. 29 is a diagram illustrating an exemplary Item hierarchy in accordance with an embodiment of the present invention.
  • Search Views - 64 • a) Item - 65 (1) Master Item Search View - 65 (2) Typed Item Search Views - 66 b) Item Extensions - 66 (1) Master Extension Search View - 66 (2) Typed Extension Search Views - 67 c) Nested Elements - 68 d) Relationships - 68 (1) Master Relationship Search View - 68 (2) Relationship Instance Search Views - 69 9. Updates - 69 10.
  • Change Tracking & Tombstones - 70 • a) Change Tracking - 70 ( 1) Change Tracking in "Master” Search Views - 71 (2) Change Tracldng in "Typed” Search Views - 72 b) Tombstones - 72 (1) Item Tombstones - 73 (2) Extension Tombstones - 73 (3) Relationships Tombstone - 74 (4) Tombstone Cleanup - 74 11. Helper APIs and Functions - 75 a) Function [System.Storagej.Getltem - 75 b) Function [System.Storage].GetExtension - 75 c) Function [System.Storage].GetRelationship - 75 12. Metadata - 75 a) Schema Metadata - 75 b) Instance Metadata - 75
  • E. SECURITY - 76 1. Overview - 76 2. Detailed Description of the Security Model - 81 ⁇ a) Security Descriptor structure - 81 (1) Access MaskFormat - 82 (2) Generic Access Rights - 82 (3) Standard Access Rights - 83 b) Item Specific Rights - 84 (1) File and Directory object specific rights - 84 (2) WinFSItemRead - 85 (3) WinFSItemReadAttributes - 86 (4) WinFSItemWriteAttributes - 86 (5) WinFSItemWrite - 86 (6) WinFSItemAddLink - 87 (7) WinFSItemDeleteLink - 87 (8) Rights to delete an item - 87 (9) Rights to copy an item - 88 (10) Rights to move an item - 88 (11) Rights to view the security policy on an item - 88 (12) Rights to change the security policy on an item - 88 (13) Rights that don't have a direct equivalent - 89 3.
  • H. TRADITIONAL FILE SYSTEM INTEROPERABILITY - 111 1. Model for Interoperability - 112 2. Data Store Features - 113 - a) Not a volume - 113 ⁇ b) Store Structure - 113 ⁇ c) Not all files are migrated - 114 ⁇ d) NTFS namespace access to Storage Platform files - 114 • e) Expected namespace/drive letters - 114 ⁇
  • Storage Platform File API - 166 a) Introduction - 166 (1) Reflecting an NTFS Volume in the Storage Platform - 166 (2) Creating Files and Directories in the storage platform Namespace - 166 b) File Schema - 167 c) Overview of System.Storage.Files - 167 d) Code Examples - 168 (1) Opening a File and Writing to It - 168 (2) Using Queries - 168 e) Domain Behaviors - 169
  • FIG. 1 A. EXEMPLARY COMPUTING ENVIRONMENT
  • Fig. 1 and the following discussion is intended to provide a brief general description of a suitable computing environment in which the invention may be implemented.
  • 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 a server.
  • program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types.
  • an exemplary general purpose computing system includes a conventional personal computer 20 or the like, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21.
  • the system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • the system memory includes read only memory (ROM) 24 and random access memory (RAM) 25.
  • ROM 24 read only memory
  • RAM random access memory
  • the personal computer 20 may further include a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media.
  • the hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively.
  • the drives and their associated computer readable media provide non volatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20.
  • the exemplary environment described herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 31, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs) and the like may also be used in the exemplary operating environment.
  • the exemplary environment may also include many types of monitoring devices such as heat sensors and security or fire alarm systems, and other sources of information.
  • a number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37 and program data 38.
  • a user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42.
  • Other input devices may include a microphone, joystick, game pad, satellite disk, scanner or the like.
  • serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or universal serial bus (USB).
  • a monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48.
  • personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
  • the exemplary system of Fig. 1 also includes a host adapter 55, Small Computer System Interface (SCSI) bus 56, and an external storage device 62 connected to the SCSI bus 56.
  • SCSI Small Computer System Interface
  • the personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49.
  • the remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20, although only a memory storage device 50 has been illustrated in Fig. 1.
  • the logical connections depicted in Fig. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise wide computer networks, intranets and the Internet.
  • the personal computer 20 When used in a LAN networking environment, the personal computer 20 is connected to the LAN 51 through a network interface or adapter 53.
  • the personal computer 20 When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the wide area network 52, such as the Internet.
  • the modem 54 which may be internal or external, is connected to the system bus 23 via the serial port interface 46.
  • program modules depicted relative to the personal computer 20, or portions thereof may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. [0062] As illustrated in the block diagram of Fig.
  • a computer system 200 can be roughly divided into three component groups: the hardware component 202, the hardware/software interface system component 204, and the applications programs component 206 (also referred to as the "user component” or “software component” in certain contexts herein).
  • the hardware component 202 may comprise the central processing unit (CPU) 21, the memory (both ROM 24 and RAM 25), the basic input/output system (BIOS) 26, and various input/output (I/O) devices such as a keyboard 40, a mouse 42, a monitor 47, and/or a printer (not shown), among other things.
  • the hardware component 202 comprises the basic physical infrastructure for the computer system 200.
  • the applications programs component 206 comprises various software programs including but not limited to compilers, database systems, word processors, business programs, videogames, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for various users (machines, other computer systems, and/or end-users).
  • the hardware/software interface system component 204 comprises (and, in some embodiments, may solely consist of) an operating system that itself comprises, in most cases, a shell and a kernel.
  • An "operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware.
  • the hardware/software interface system component 204 may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system.
  • VMM virtual machine manager
  • CLR Common Language Runtime
  • JVM Java Virtual Machine
  • the purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs.
  • the goal of any hardware/software interface system is to make the computer system convenient to use, as well as utilize the computer hardware in an efficient manner.
  • the hardware/software interface system is generally loaded into a computer system at startup and thereafter manages all of the application programs in the computer system.
  • the application programs interact with the hardware/software interface system by requesting services via an application program interface (API).
  • API application program interface
  • a hardware/software interface system traditionally performs a variety of services for applications. In a multitasking hardware/software interface system where multiple programs may be running at the same time, the hardware/software interface system determines which applications should run in what order and how much time should be allowed for each application before switching to another application for a turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications, and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports.
  • the hardware/software interface system also sends messages to each application (and, in certain case, to the end-user) regarding the status of operations and any errors that may have occurred.
  • the hardware/software interface system can also offload the management of batch jobs (e.g., printing) so that the initiating application is freed from this work and can resume other processing and/or operations.
  • batch jobs e.g., printing
  • a hardware/software interface system On computers that can provide parallel processing, a hardware/software interface system also manages dividing a program so that it runs on more than one processor at a time.
  • a hardware/software interface system shell (simply referred to herein as a "shell”) is an interactive end-user interface to a hardware/software interface system.
  • a shell may also be referred to as a "command interpreter” or, in an operating system, as an “operating system shell”).
  • a shell is the outer layer of a hardware/software interface system that is directly accessible by application programs and/or end-users.
  • a kernel is a hardware/software interface system's innermost layer that interacts directly with the hardware components.
  • computer system is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.
  • files are units of storable information that may include the hardware/software interface system as well as application programs, data sets, and so forth.
  • files are the basic discrete (storable and retrievable) units of information (e.g., data, programs, and so forth) that can be manipulated by the hardware/software interface system.
  • Groups of files are generally organized in "folders.”
  • a folder is a collection of files that can be retrieved, moved, and otherwise manipulated as single units of information.
  • directory a tree-based hierarchical arrangement
  • directory a tree-based hierarchical arrangement
  • the terms "directory” and/or “folder” are interchangeable, and early Apple computer systems (e.g., the Apple He) used the term "catalog” instead of directory; however, as used herein, all of these terms are deemed to be synonymous and interchangeable and are intended to further include all other equivalent terms for and references to hierarchical information storage structures and their folder and file components.
  • a directory of folders is a tree-based hierarchical structure wherein files are grouped into folders and folder, in turn, are arranged according to relative nodal locations that comprise the directory tree.
  • a DOS-based file system base folder (or "root directory") 212 may comprise a plurality of folders 214, each of which may further comprise additional folders (as "subfolders" of that particular folder) 216, and each of these may also comprise additional folders 218 ad infinitum.
  • Each of these folders may have one or more files 220 although, at the hardware/software interface system level, the individual files in a folder have nothing in common other than their location in the tree hierarchy.
  • each folder is a container for its subfolders and its files —that is, each folder owns its subfolders and files.
  • each folder is deleted by the hardware/software interface system, that folder's subfolders and files are also deleted (which, in the case of each subfolder, further includes its own subfolders and files recursively).
  • each file is generally owned by only one folder and, although a file can be copied and the copy located in a different folder, a copy of a file is itself a distinct and separate unit that has no direct connection to the original (e.g., changes to the original file are not mirrored in the copy file at the hardware/software interface system level).
  • files and folders are therefore characteristically "physical" in nature because folders are the treated like physical containers, and files are treated as discrete and separate physical elements inside these containers.
  • the storage platform of the present invention extends and broadens the data platform beyond the kinds of existing file systems and database systems discussed above, and is designed to be the store for all types of data, including a new form of data called Items.
  • Items A. GLOSSARY .
  • An "Item” is an unit of storable information accessible to a hardware/software interface system that, unlike a simple file, is an object having a basic set of properties that are commonly supported across all objects exposed to an end-user by the hardware/software interface system shell. Items also have properties and relationships that are commonly supported across all Item types including features that allow new properties and relationships to be introduced (and discussed in great detail later herein).
  • An "operating system” is a special program that acts as an intermediary between application programs and computer hardware.
  • An operating system comprises, in most cases, a shell and a kernel.
  • a "hardware/software interface system” is software, or a combination of hardware and software, that serves as the interface between the underlying hardware components of a computer system and applications that execute on the computer system.
  • a hardware/software interface system typically comprises (and, in some embodiments, may solely consist of) an operating system.
  • a hardware/software interface system may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system.
  • VMM virtual machine manager
  • CLR Common Language Runtime
  • JVM Java Virtual Machine
  • the purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs.
  • the goal of any hardware/software interface system is to make the computer system convenient to use, as well as utilize the computer hardware in an efficient manner.
  • a storage platform 300 in accordance with the present invention comprises a data store 302 implemented on a database engine 314.
  • the database engine comprises a relational database engine with object relational extensions.
  • the relational database engine 314 comprises the Microsoft SQL Server relational database engine.
  • the data store 302 implements a data model 304 that supports the organization, searching, sharing, synchronization, and security of data. Specific types of data are described in schemas, such as schemas 340, and the storage platform 300 provides tools 346 for deploying those schemas as well as for extending those schemas, as described more fully below.
  • a change tracking mechanism 306 implemented within the data store 302 provides the ability track changes to the data store.
  • the data store 302 also provides security capabilities 308 and a promotion/demotion capability 310, both of which are discussed more fully below.
  • the data store 302 also provides a set of application programming interfaces 312 to expose the capabilities of the data store 302 to other storage platform components and application programs (e.g., application programs 350a, 350b, and 350c) that utilize the storage platform.
  • the storage platform of the present invention still further comprises an application programming interfaces (API) 322, which enables application programs, such as application programs 350a, 350b, and 350c, to access all of the foregoing capabilities of the storage platform and to access the data described in the schemas.
  • API application programming interfaces
  • the storage platform API 322 may be used by application programs in combination with other APIs, such as the OLE DB API 324 and the Microsoft Windows Win32 API 326.
  • the storage platform 300 of the present invention may provide a variety of services 328 to application programs, including a synchronization service 330 that facilitates the sharing of data among users or systems.
  • the synchronization service 330 may enable interoperability with other data stores 340 having the same format as data store 302, as well as access to data stores 342 having other formats.
  • the storage platform 300 also provides file system capabilities that allow interoperability of the data store 302 with existing file systems, such as the Windows NTFS files system 318.
  • the storage platform 320 may also provide application programs with additional capabilities for enabling data to be acted upon and for enabling interaction with other systems. These capabilities may be embodied in the form of additional services 328, such as an Info Agent service 334 and a notification service 332, as well as in the form of other utilities 336. [0084] In at least some embodiments, the storage platform is embodied in, or forms an integral part of, the hardware/software interface system of a computer system.
  • the storage platform of the present invention may be embodied in, or form an integral part of, an operating system, a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, or a Java Virtual Machine (JVM) or its functional equivalent.
  • VMM virtual machine manager
  • CLR Common Language Runtime
  • JVM Java Virtual Machine
  • WinFS the storage platform 300 of the present invention
  • WinFS the storage platform 300 of the present invention
  • use of this name to refer to the storage platform is solely for convenience of description and is not intended to be limiting in any way.
  • the data store 302 of the storage platform 300 of the present invention implements a data model that supports the organization, searching, sharing, synchronization, and security of data that resides in the store.
  • an "Item" is the fundamental unit of storage information.
  • the data model provides a mechanism for declaring Items and Item extensions and for establishing relationships between Items and for organizing Items in Item Folders and in Categories, as described more fully below.
  • the data model relies on two primitive mechanisms, Types and Relationships. Types are structures which provide a format which governs the form of an instance of the Type. The format is expressed as an ordered set of Properties.
  • a Property is a name for a value or set of values of a given Type.
  • a USPostalAddress type might have the properties Street, City, Zip, State in which Street, City and State are of type String and Zip is of Type Int32. Street may be multi-valued (i.e. a set of values) allowing the address to have more than one value for the Street property.
  • the system defines certain primitive types that can be used in the construction of other types - these include String, Binary, Boolean, Intl ⁇ , Int32, Int64, Single, Double, Byte, DateTime, Decimal and GUID.
  • the Properties of a Type may be defined using any of the primitive types or (with some restrictions noted below) any of the constructed types.
  • Relationships can be declared and represent a mapping between the sets of instances of two types. For example there may be a Relationship declared between the Person Type and the Location Type called LivesAt which defines which people live at which locations. The Relationship has a name, two endpoints, namely a source endpoint and a target endpoint. Relationships may also have an ordered set of properties. Both the Source and Target endpoints have a Name and a Type.
  • the LivesAt Relationship has a Source called Occupant of Type Person and a Target called Dwelling of Type Location and in addition has properties StartDate and EndDate indicating the period of time for which the occupant lived at the dwelling. Note that a Person may live at multiple dwellings over time and a. dwelling may have multiple occupants so the most likely place to put the StartDate. and EndDate information is on the relationship itself.
  • Relationships define a mapping between instances that is constrained by the types given as the endpoint types. For example the LivesAt relationship cannot be a relationship in which an Automobile is the Occupant because an Automobile is not a Person.
  • the data model does allow the definition of a subtype-supertype relationship between types.
  • the subtype-supertype relationship also known as the BaseType relationship is defined in such a way that if Type A is a BaseType for Type B it must be the case that every instance of B is also an instance of A. Another way of expressing this is that every instance that conforms to B must also conform to A. If, for example A has a property Name of Type String while B has a property Age of Type Intl6, it follows that any instance of B must have both a Name and an Age.
  • the type hierarchy may be envisaged as an tree with a single supertype at the root. The branches from the root provide the first level subtypes, the branches at this level provide the second level subtypes and so on to the leaf -most subtypes which themselves do not have any subtypes.
  • a given Type may have zero or many subtypes and zero or one super type.
  • a given instance may conform to at most one type together with that type's super types. To put it another way, for a given instance at any level in the tree the instance may conform to at most one subtype at that level.
  • a type is said to be Abstract if instances of the type must also be an instance of a subtype of the type. 1. Items [0093] An Item is a unit of storable information that, unlike a simple file, is an object having a basic set of properties that are commonly supported across all objects exposed to an end-user or application program by the storage platform.
  • Items also have 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 the objects for common operations such as copy, delete, move, open, print, backup, restore, replicate, and so forth. Items are the units that can be stored and retrieved, and all forms of storable information manipulated by the storage platform exist as Items, properties of Items, or Relationships between Items, each of which is discussed in greater detail herein below.
  • Items are intended to represent real-world and readily-understandable units of data like Contacts, People, Services, Locations, Documents (of all various sorts), and so on.
  • Fig. 5A is a block diagram illustrating the structure of an Item.
  • the unqualified name of the Item is "Location”.
  • the qualified name of the Item is "Core.Location” which indicates that this Item structure is defined as a specific type of Item in the Core Schema. (The Core Schema is discussed in more detail later herein.)
  • the Location Item has a plurality of properties including EAddresses, MetropolitanRegion, Neighborhood, and Postal Addresses. The specific type of property for each is indicated immediately following the property name and is separated from the property name by a colon (":").
  • EAddresses and Postal Addresses are properties of defined types or "complex types" (as denoted herein by capitalization) of types EAddress and PostalAddress respectively.
  • a complex type is type that is derived from one or more simple data types and/or from other complex types.
  • the complex types for the properties of an Item also constitute "nested elements” since the details of the complex type are nested into the immediate Item to define its properties, and the information pertaining to these complex types is maintained with the Item that has these properties (within the Item's boundary, as discussed later herein).
  • FIG. 5B is a block diagram illustrating the complex property types PostalAddress and EAddress.
  • the PostalAddress property type defines that an Item of property type PostalAddress can be expected to have zero or one City values, zero or one CountryCode values, zero or one MailStop values, and any number (zero to many) of PostalAddressTypes, and so on and so forth. In this way, the shape of the data for a particular property in an Item is hereby defined.
  • the EAddress property type is similarly defined as shown.
  • another way to represent the complex types in the Location Item is to draw the Item with the individual properties of each complex type listed therein.
  • Fig. 5C is a block diagram illustrating the Location Item wherein its complex types are further described.
  • this alternative representation of the Location Item in this Fig. 5C is for the exact same Item illustrated in Fig. 5A.
  • the storage platform of the present invention also allows subtyping whereby one property type can be a subtype of another (where the one property type inherits the properties of another, parent property type).
  • Items inherently represent their own Item Types that can also be the subject of subtyping.
  • the storage platform in several embodiments of the present invention allows an Item to be a subtype of another Item (whereby the one Item inherits the properties of the other, parent Item).
  • every Item is a subtype of the "Item" Item type which is the first and foundational Item type found in the Base Schema. (The Base Schema will also be discussed in detail later herein.)
  • Fig. 6A illustrates an Item, the Location Item in this Instance, as being a subtype of the Item Item type found in the Base Schema. In this drawing, the arrow indicates that the Location Item (like all other Items) is a subtype of the Item Item type.
  • the Item Item type as the foundational Item from which all other Items are derived, has a number of important properties such as Itemld and various timestamps, and thereby defines the standard properties of all Items in an operating system. In the present figure, these properties of the Item Item type are inherited by Location and thereby become properties of Location. [0099] Another way to represent the properties in the Location Item inherited from the Item Item type is to draw Location with the individual properties of each property type from the parent Item listed therein.
  • Fig. 6B is a block diagram illustrating the Location Item wherein its inherited types described in addition to its immediate properties. It should be noted and understood that this Item is the same Item illustrated in Fig.
  • Certain embodiments of the present invention may enable one to request a subset of properties when retrieving a specific Item; however, the default for many such embodiments is to provide the Item with all of its immediate and inherited properties when retrieved.
  • the properties of Items can also be extended by adding new properties to the existing properties of that Item's type. These "extensions" are thereafter bona fide properties of the Item and subtypes of that Item type may automatically include the extension properties.
  • the "boundary" of the Item is represented by its properties (including complex property types, extensions, and so forth). An Item's boundary also represents the limit of an operation performed on an Item such as copy, delete, move, create, and so on.
  • the boundary encompasses the following: • The Item Type of the Item and, if the Item is a subtype of another Item (as is the case in several embodiments of the present invention where all Items are derived from a single Item and Item Type in the Base Schema), any applicable subtype information (that is, information pertaining to the parent Item Type). If the original Item being copied is a subtype of another Item, the copy may also be a subtype of that same Item. • The Item's complex-type properties and extensions, if any.
  • the copy may also have the same complex types.
  • Item Identification [0102] Items are uniquely identified within the global items space with an ItemlD.
  • the Base.Item type defines a field ItemlD of type GUID that stores the identity for the Item.
  • An Item must have exactly one identity in the data store 302.
  • Item References [0103]
  • An item reference is a data structure that contains information to locate and identify an Item.
  • an abstract type is defined named ItemReference from which all item reference types derive.
  • the ItemReference type defines a virtual method named Resolve. The Resolve method resolves the ItemReference and returns an Item. This method is overridden by the concrete subtypes of ItemReference, which implement a function that retrieves an Item given a reference.
  • the Resolve method is invoked as part of the storage platform API 322.
  • ItemlDReference is a subtype of ItemReference. It defines a Locator and an ItemlD field.
  • the Locator field names (i.e. identifies) an item domain. It is processed by a locator resolution method that can resolve the value of the Locator to an item domain.
  • the ItemlD field is of type ItemlD
  • ItemPathReference is a specialization of ItemReference that defines a Locator and a Path field.
  • the Locator field identifies an item domain. It is processed by a locator resolution method that can resolve the value of the Locator to an item domain.
  • the Path field contains a (relative) path in the storage platform namespace rooted at the item domain provided by the Locator. [0106] This type of reference cannot be used in a set operation. The reference must generally be resolved through a path resolution process. The Resolve method of the storage platform API 322 provides this functionality.
  • b) Reference type hierarchy [0107] The reference forms discussed above are represented through the reference type hierarchy illustrated in Figure 11. Additional reference types that inherit from these types can be defined in the schemas. They can be used in a relationship declaration as type of the target field.
  • Item Folders and Categories [0108] As discussed more fully below, groups of Items can are organized into special Items called Item Folders (which are not to be confused with file folders). Unlike in most file systems, however, an Item can belong to more than one Item Folder, such that when an Item is accessed in one Item Folder and revised, this revised Item can then be accessed directly from another Item folder. In essence, although access to an Item may occur from different Item Folders, what is actually being accessed is in fact the very same Item. However, an Item Folder does not necessarily own all of its member Items, or may simply co-own Items in conjunction with other folders, such that the deletion of an Item Folder does not necessarily result in the deletion of the Item.
  • an Item must belong to at least one Item Folder so that if the sole Item Folder for a particular Item is deleted then, for some embodiments, the Item is automatically deleted or, in alternative embodiments, the Item automatically becomes a member of a default Item Folder (e.g., a "Trash Can" Item Folder conceptually similar to similarly-named folders used in various file-and-folder-based systems).
  • Items may also belong to Categories based on common described characteristic such as (a) an Item Type (or Types), (b) a specific immediate or inherited property (or properties), or (c) a specific value (or values) corresponding to an Item property.
  • Item Folders are conceptually different form Item Folders in that, whereas Item Folders may comprise Items that are not interrelated (i.e., without a common described characteristic), each Item in a Category has a common type, property, or value (a "commonality") that is described for that Category, and it is this commonality that forms the basis for its relationship to and among the other Items in the Category.
  • Categories can also be thought of as virtual Item Folders whose membership is based on the results of a specific query (such as in the context of a database), and Items that meet the conditions of this query (defined by the commonalities of the Category) would thus comprise the Category's membership.
  • Fig. 4 illustrates the structural relationship between Items, Item Folders, and Categories in various embodiments of the present invention.
  • a plurality of Items 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 are members of various Item Folders 422, 424, 426, 428, and 430. Some Items may belong to more than one Item Folder, e.g., Item 402 belong to Item Folders 422 and 424.
  • Some Items e.g., Item 402, 404, 406, 408, 410, and 412 are also members of one or more Categories 432, 434, and 436, while other times, e.g., Items 414, 416, 418, and 420, may belong to no Categories (although this is largely unlikely in certain embodiments where the possession of any property automatically implies membership in a Category, and thus an Item would have to be completely featureless in order not to be a member of any category in such an embodiment).
  • both Categories and Item Folders have structures more akin to directed graphs as shown. In any event, the Items, Item Folders, and Categories are all Items (albeit of different Item Types).
  • the Items, Item Folders, and Categories of the present invention are not characteristically "physical" in nature because they do not have conceptual equivalents of physical containers, and therefore Items may exist in more than one such location.
  • the ability for Items to exist in more than one Item Folder location as well as being organized into Categories provides an enhanced and enriched degree of data manipulation and storage structure capabilities at the hardware/software interface level, beyond that currently available in the art.
  • Base Schema that establishes a conceptual framework for creating and organizing Items and properties.
  • the Base Schema defines certain special types of Items and properties, and the features of these special foundational types from which subtypes can be further derived.
  • the use of this Base Schema allows a programmer to conceptually distinguish Items (and their respective types) from properties (and their respective types).
  • the Base Schema sets forth the foundational set of properties that all Items may possess as all Items (and their corresponding Item Types) are derived from this foundational Item in the Base Schema (and its corresponding Item Type).
  • the Base Schema defines three top-level types: Item, Extension, and PropertyBase.
  • the Item type is defined by the properties of this foundational "Item” Item type.
  • the top level property type "PropertyBase” has no predefined properties and is merely the anchor from which all other property types are derived and through which all derived property types are interrelated (being commonly derived from the single property type).
  • the Extension type properties define which Item the extension extends as well as identification to distinguish one extension from another as an Item may have multiple extensions.
  • ItemFolder is a subtype of the Item Item type that, in addition to the properties inherited from Item, features a Relationship for establishing links to its members (if any), whereas both IdentityKey and Property are subtypes of PropertyBase. CategoryRef, in turn, is a subtype of IdentityKey.
  • b) Core Schema [0116] Various embodiments of the storage platform of the present invention further comprise a Core Schema that provides a conceptual framework for top-level Items type structures.
  • Fig. 8A is a block diagram illustrating Items in the Core Schema
  • Fig. 8B is a block diagram illustrating the property types in the Core Schema.
  • the Core Schema defines a set of core Item types that, directly (by Item type) or indirectly (by Item subtype), characterize all Items into one or more Core Schema Item types which the Item-based hardware/software interface system understands and can directly process in a predetermined and predictable way.
  • the predefined Item types reflect the most common Items in the Item-based hardware/software interface system and thus a level of efficiency is gained by the Item-based hardware/software interface system understanding these predefined Item types that comprise the Core Schema.
  • the Core Schema is not extendable — that is, no additional Item types can be subtyped directly from the Item type in the Base Schema except for the specific predefined derived Item types that are part of the Core Schema.
  • the storage platform mandates the use of the Core Schema Item types since every subsequent Item type is necessarily a subtype of a Core Schema Item type.
  • the specific Item types supported by the Core Schema may include one or more of the following: • Categories: Items of this Item Type (and subtypes derived therefrom) represent valid Categories in the Item-based hardware/software interface system. • Commodities: Items that are identifiable things of value. • Devices: Items having a logical structure that supports information processing capabilities. • Documents: Items with content that is not interpreted by the Item-based hardware/software interface system but is instead interpreted by an application program corresponding to the document type.
  • • Events Items that record certain occurrences in the environment.
  • Locations Items representing physical locations (e.g., geographical locations).
  • Messages Items of communication between two or more principals (defined below).
  • Principals Items having at least one definitively provable identity aside from an Itemld (e.g., the identification of a person, organization, group, household, authority, service, etc.).
  • Statements Items having special information regarding the environment including, without limitation, policies, subscriptions, credentials, and so forth.
  • the specific property types supported by the Core Schema may include one or more of the following: • Certificates (derived from the foundational PropertyBase type in the Base Schema) • Principal Identity Keys (derived from the IdentityKey type in the Base Schema) • Postal Address (derived from the Property type in the Base Schema) • Rich Text (derived from the Property type in the Base Schema) • EAddress (derived from the Property type in the Base Schema) • IdentitySecurityPackage (derived from the Relationship type in the Base Schema) • RoleOccupancy (derived from the Relationship type in the Base Schema) • BasicPresence (derived from the Relationship type in the Base Schema) These Items and Properties are further described by their respective properties set forth in Figs.
  • Relationships are binary relationships where one Item is designated as source and the other Item as target.
  • the source Item and the target Item are related by the relationship.
  • the source Item generally controls the life-time of the relationship. That is, when the source Item is deleted, the relationship between the Items is also deleted.
  • Relationships are classified into: Containment and Reference relationships. The containment relationships control the life-time of the target Items, while the reference relationships do not provide any life-time management semantics. Figure 12 illustrates the manner in which relationships are classified.
  • the Containment relationship types are further classified into Holding and Embedding relationships. When all holding relationships to an Item are removed, the Item is deleted.
  • a holding relationship controls the life-time of the target through a reference counting mechanism.
  • the embedding relationships enable modeling of compound Items and can be thought of as exclusive holding relationships.
  • An Item can be a target of one or more holding relationships; but an Item can be target of exactly one embedding relationship.
  • An Item that is a target of an embedding relationship can not be a target of any other holding or embedding relationships.
  • Reference relationships do not control the lifetime of the target Item. They may be dangling - the target Item may not exist. Reference relationships can be used to model references to Items anywhere in the global Item name space (i.e. including remote data stores). [0123] Fetching an Item does not automatically fetch its relationships. Applications must explicitly request the relationships of an Item.
  • Relationship Declaration [0124] The explicit relationship types are defined with the following elements: • A relationship name is specified in the Name attribute. • Relationship type, one of the following: Holding, Embedding, Reference. This is specified in the Type attribute. • Source and target endpoints. Each endpoint specifies a name and the type of the referenced Item. • The source endpoint field is generally of type ItemlD (not declared) and it must reference an Item in the same data store as the relationship instance.
  • the target endpoint field must be of type ItemlDReference and it must reference an Item in the same store as the relationship instance.
  • the target endpoint can be of any ItemReference type and can reference Items in other storage platform data stores.
  • one or more fields of a scalar or PropertyBase type can be declared. These fields may contain data associated with the relationship.
  • Relationship instances are stored in a global relationships table. • Every relationship instance is uniquely identified by the combination (source ItemlD, relationship ID). The relationship LD is unique within a given source ItemlD for all relationships sourced in a given Item regardless of their type. [0125] The source Item is the owner of the relationship.
  • the relationship can not be created if the person Item that is referenced by the source reference does not exist. Also, if the person Item is deleted, the relationship instances between the person and organization are deleted. However, if the Organization Item is deleted, the relationship is not deleted and it is dangling.
  • Holding relationships are used to model reference count based life-time management of the target Items.
  • An Item can be a source endpoint for zero or more relationships to Items.
  • An Item that is not an embedded Item can be a target of in one or more holding relationships.
  • the target endpoint reference type must be ItemlDReference and it must reference an Item in the same store as the relationship instance.
  • Holding relationships enforce lifetime management of the target endpoint.
  • the creation of a holding relationship instance and the Item that it is targeting is an atomic operation. Additional holding relationship instances can be created that are targeting the same Item. When the last holding relationship instance with a given Item as target endpoint is deleted the target Item is also deleted.
  • the types of the endpoint Items specified in the relationship declaration will generally be enforced when an instance of the relationship is created. The types of the endpoint Items can not be changed after the relationship is established.
  • Holding relationships play a key role in forming the Item namespace.
  • the holding relationships form a directed acyclic graph (DAG).
  • DAG directed acyclic graph
  • the FolderMembers relationship enables the concept of a Folder as a generic collection of Items.
  • Embedding Relationships model the concept of exclusive control of the lifetime of the target Item. They enable the concept of compound Items.
  • the creation of an embedding relationship instance and the Item that it is targeting is an atomic operation.
  • An Item can be a source of zero or more embedding relationship.
  • an Item can be a target of one and only one embedding relationship.
  • An Item that is a target of an embedding relationship can not be a target of a holding relationship.
  • the target endpoint reference type must be ItemlDReference and it must reference an Item in the same data store as the relationship instance.
  • the types of the endpoint Items specified in the relationship declaration will generally be enforced when an instance of the relationship is created.
  • the types of the endpoint Items can not be changed after the relationship is established.
  • Embedding relationships control the operational consistency of the target endpoint.
  • the operation of serializing of an Item may include serialization of all the embedding relationships that source from that Item as well as all of their targets; copying an Item also copies all its embedded Items.
  • Reference relationships can be dangling. Also, the reference relationship can reference Items in other data stores. Reference relationships can be thought of as a concept similar to links in web pages.
  • Any reference type is allowed in the target endpoint.
  • the Items that participate in a reference relationship can be of any Item type.
  • Reference relationships are used to model most non-lifetime management relationships between Items. Since the existence of the target is not enforced, the reference relationship is convenient to model loosely-coupled relationships. The reference relationship can be used to target Items in other data stores including stores on other computers.
  • Rules and constraints [0148] The following additional rules and constraints apply for relationships: 1. An Item must be a target of (exactly one embedding relationship) or (one or more holding relationships). One exception is the root Item. An Item can be a target of zero or more reference relationships 2. An Item that is a target of embedding relationship can not be source of holding relationships.
  • the storage platform of the present invention supports ordering of relationships.
  • the ordering is achieved through a property named "Order" in the base relationship definition. There is no uniqueness constraint on the Order field. The order of the relationships with the same "order" property value is not guaranteed, however it is guaranteed that they may be ordered after relationships with lower "order” value and before relationships with higher “order” field value.
  • Applications can get the relationships in the default order by ordering on the combination ( SourceltemlD, RelationshipID, Order). All relationship instances sourced from a given Item are ordered as a single collection regardless of the type of the relationships in the collection. This however guarantees that all relationships of a given type (e.g., FolderMembers) are an ordered subset of the relationship collection for a given Item.
  • the data store API 312 for manipulating relationships implement a set of operations that support ordering of relationships.
  • RelFirst is the first relationship in the ordered collection with order value OrdFirst
  • RelLast is the last relationship in the ordered collection with order value OrdLast
  • RelX is a given relationship in the collection with order value OrdX
  • RelPrev is a closest relationship in the collection to RelX with order value OrdPrev smaller then OrdX
  • RelNext is a closest relationship in the collection to RelX with order value OrdNext greater then OrdX.
  • InsertJBeforeFirst( SourceltemlD, Relationship ) Inserts the relationship as the first relationship in the collection. The value of the "Order" property of the new relationship may be smaller then OrdFirst.
  • Insert ⁇ fterLast( SourceltemlD, Relationship ) Inserts the relationship as the last relationship in the collection.
  • the value of the "Order" property of the new relationship may be greater then OrdLast.
  • In$ertAt( SourceltemlD, ord, Relationship ) Inserts a relationship with the specified value for the "Order” property.
  • InsertBefore( SourceltemlD, ord, Relationship ) Inserts the relationship before the relationship with the given order value.
  • the new relationship may be assigned "Order" value that is between OrdPrev and ord, noninclusive.
  • InsertAfler( SourceltemlD, ord, Relationship ) Inserts the relationship after the relationship with the given order value.
  • the new relationship may be assigned "Order" value that is between ord and OrdNext, non-inclusive.
  • MoveBefore( SourceltemlD, ord, RelationshipID ) Moves the relationship with given relationship ID before the relationship with specified "Order” value.
  • the relationship may be assigned a new "Order” value that is between OrdPrev and ord, non-inclusive.
  • MoveAfter( SourceltemlD, ord, RelationshipID ) Moves the relationship with given relationship JJD after the relationship with specified "Order” value.
  • the relationship may be assigned a new order value that is between ord and OrdNext, non-inclusive. [0152] As previously mentioned, every Item must be a member of an Item Folder.
  • Relationships In terms of Relationships, every Item must have a relationship with an Item Folder. In several embodiments of the present invention, certain relationships are represented by Relationships existing between the Items. [0153] As implemented for various embodiments of the present invention, a Relationship provides a directed binary relationship that is "extended" by one Item (the source) to another Item (the target). A Relationship is owned by the source Item (the Item that extended it), and thus the Relationship is removed if the source is removed (e.g., the Relationship is deleted when the source Item is deleted).
  • a Relationship may share ownership of (co-own) the target Item, and such ownership might be reflected in the IsOwned property (or its equivalent) of the Relationship (as shown in Fig. 7 for the Relationship property type).
  • creation of a new IsOwned Relationship automatically increments a reference count on the target Item, and deletion of such a Relationship may decrement the reference count on the target Item.
  • Items continue to exist if they have a reference count greater than zero, and are automatically deleted if and when the count reaches zero.
  • an Item Folder is an Item that has (or is capable of having) a set of Relationships to other Items, these other Items comprising the membership of the Item Folder.
  • Other actual implementations of Relationships are possible and anticipated by the present invention to achieve the functionality described herein.
  • a Relationship is a selectable connection from one object to another. The ability for an Item to belong to more than one Item Folder, as well as to one or more Categories, and whether these Items, Folders, and Categories are public or private, is determined by the meanings given to the existence (or lack thereof) in an Item-based structure.
  • Logical Relationships are the meanings assigned to a set of Relationships, regardless of physical implementation, which are specifically employed to achieve the functionality described herein.
  • Logical Relationships are established between the Item and its Item Folder(s) or Categories (and vice versa) because, in essence, ' Item Folders and Categories are each a special type of Item. Consequently, Item Folders and Categories can be acted upon the same way as any other Item — copied, added to an email message, embedded in a document, and so and so forth without limitation — and Item Folders and Categories can be serialized and de-serialized (imported and exported) using the same mechanisms as for other Items.
  • the aforementioned Relationships which represent the relationship between an Item and it Item Folder(s) can logically extend from the Item to the Item Folder, from the Item Folder to the Item, or both.
  • a Relationship that logically extends from an Item to an Item Folder denotes that the Item Folder is public to that Item and shares its membership information with that Item; conversely, the lack of a logical Relationship from an Item to an Item Folder denotes that the Item Folder is private to that Item and does not share its membership information with that Item.
  • a Relationship that logically extends from an Item Folder to an Item denotes that the Item is public and sharable to that Item Folder
  • the lack of a logical Relationship from the Item Folder to the Item denotes that the Item is private and non-sharable.
  • Item Folder 900 is a block diagram illustrating an Item Folder (which, again, is an Item itself), its member Items, and the interconnecting Relationships between the Item Folder and its member Items.
  • the Item Folder 900 has as members a plurality of Items 902, 904, and 906.
  • Item Folder 900 has a Relationship 912 from itself to Item 902 which denotes that the Item 902 is public and sharable to Item Folder 900, its members 904 and 906, and any other Item Folders, Categories, or Items (not shown) that might access Item Folder 900.
  • Item 902 there is no Relationship from Item 902 to the Item Folder 900 which denotes that Item Folder 900 is private to Item 902 and does not share its membership information with Item 902.
  • Item 904 does have a Relationship 924 from itself to Item Folder 900 which denotes that the Item Folder 900 is public and shares its membership information with Item 904.
  • Item 904 there is no Relationship from the Item Folder 900 to Item 904 which denotes that Item 904 is private and not sharable to Item Folder 900, its other members 902 and 906, and any other Item Folders, Categories, or Items (not shown) that might access Item Folder 900.
  • Item Folder 900 In contrast -with its Relationships (or lack thereof) to Items 902 and 904, Item Folder 900 has a Relationship 916 from itself to the Item 906 and Item 906 has a Relationship 926 back to Item Folder 900, which. together denote that Item 906 is public and sharable to Item Folder 900, its members 902 and 904, and any other Item Folders, Categories, or Items (not shown) that might access Item Folder 900, and that Item Folder 900 is public and shares its membership information with Item 906.
  • Categories are described by a commonality that is common to all of its member Items. Consequently the membership of a Category is inherently limited to Items having the described commonality and, in certain embodiments, all Items meeting the description of a Category are automatically made members of the Category. Thus, whereas Item Folders allow trivial type structures to be represented by their membership, Categories allow membership based on the defined commonality. [0158] Of course Category descriptions are logical in nature, and therefore a Category may be described by any logical representation of types, properties, and/or values.
  • a logical representation for a Category may be its membership to comprise Items have one of two properties or both. If these described properties for the Category are "A" and "B", then the Categories membership may comprise Items having property A but not B, Items having property B but not A, and Items having both properties A and B.
  • This logical representation of properties is described by the logical operator "OR” where the set of members described by the Category are Items having property A OR B. Similar logical operands (including without limitation “AND”, “XOR”, and “NOT” alone or in combination) can also be used describe a category as will be appreciated by those of skill in the art.
  • FIG. 10 is a block diagram illustrating a Category (which, again, is an Item itself), its member Items, and the interconnecting Relationships between the Category and its member Items.
  • the Category 1000 has as members a plurality of Items 1002, 1004, and 1006, all of which share some combination of common properties, values, or types 1008 as described (commonality description 1008') by the Category 1000.
  • Category 1000 has a Relationship 1012 from itself to Item 1002 which denotes that the Item 1002 is public and sharable to Category 1000, its members 1004 and 1006, and any other Categories, Item Folders, or Items (not shown) that might access Category 1000.
  • Item 1002 does not have a Relationship 1024 from itself to Category 1000 which denotes that the Category 1000 is public and shares its membership information with Item 1004.
  • Item Folder structures and/or Category structures are prohibited, at the hardware/software interface system level, from containing cycles.
  • Item Folder and Category structures are akin to directed graphs
  • the embodiments that prohibit cycles are akin to directed acyclic graphs (DAGs) which, by mathematical definition in the art of graph theory, are directed graphs wherein no path starts and ends at the same vertex. 6.
  • DAGs directed acyclic graphs
  • the storage platform is intended to be provided with an initial set of schemas 340, as described above.
  • the storage platform allows customers, including independent software vendor (ISVs), to create new schemas 344 (i.e. new Item and Nested Element types).
  • ISVs independent software vendor
  • This section addresses the mechanism for creating such schemas by extending the Item types and Nested Element types (or simply "Element" types) defined in the initial set of schemas 340.
  • extension of the initial set of Item and Nested Element types is constrained as follows: an ISV is allowed to introduce new Item types, i.e.
  • Extensions are strongly typed instances but (a) they cannot exist independently and (b) they must be attached to an Item or NFested Element.
  • Extensions are also intended to address the "multi-typing" issue. Since, in some embodiments, the storage platform may not support multiple inheritance or overlapping subtypes, applications can use Extensions as a way to model overlapping type instances (e.g. Document is a legal document as well a secure document).
  • Item extensions To provide Item extensibility, the data model further defines an abstract type named Base.Extension. This is a root type for the hierarchy of extension types. Applications can subtype Base.Extension to create specific extension types. [0167] The Base.Extension type is defined in the Base schema as follows:
  • Extension types have fields; Fields can be of primitive or nested element types; and Extension types can be sub-typed.
  • Extensions can not be sources and targets of relationships; Extension type instances can not exist independently from an item; and Extension types can not be used as field types in the storage platform type definitions [0171] There are no constraints on the types of extensions that can be associated with a given Item type. Any extension type is allowed to extend any item type.
  • extension instances When multiple extension instances are attached to an item, they are independent from each other in both structure and behavior.
  • the extension instances are stored and accessed separately from the item. All extension type instances are accessible from a global extension view. An efficient query can be composed that will return all the instances of a given type of extension regardless of what type of item they are associated with.
  • the storage platform APIs provides a programming model that can store, retrieve and modify extensions on items.
  • the extension types can be type sub-typed using the storage platform single inheritance model. Deriving from an extension type creates a new extension type. The structure or the behavior of an extension cannot override or replace the structure or behaviors of the item type hierarchy. [0174] Similar to Item types, Extension type instances can be directly accessed through the view associated with the extension type.
  • the ItemlD of the extension indicates which item they belong to and can be used to retrieve the corresponding Item object from the global Item view.
  • the extensions are considered part of the item for the purposes of operational consistency.
  • the Copy/Move, Backup/Restore and other common operations that the storage platform defines may operate on the extensions as part of the item.
  • a CRM application developer would like to attach a CRM application extension to the contacts stored in the storage platform. The application developer would define a CRM extension that would contain the additional data structure that the application can manipulate.
  • the fields and methods of the CRMExtension type cannot override 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. [0181] When the 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 Itemld. [0182] All CRMExtension extensions in the system can be accessed through the CRMExtension type view, regardless of which item they belong to. All item extension of an item share the same item id. In the above example, the Contact item instance and the attached CRMExtension and HREx ension instances the same ItemlD. [0183] The following table summarizes the similarities and differences between Item, Extension and NestedElement types:
  • Nested element is part of the item Storage Item hierarchy is Item extension Stored with item stored in its own hierarchy is stored tables in its own tables Query/Search Can query item Can query item Can generally be tables extension tables queried only within the containing item context Query/Search Can search across Can search across Can generally only scope all instances of an all instances of an search within nested item type item extension type element type instances of a singe (containing) item Relationship Can have No Relationships to No Relationships to semantics Relationships to item extensions nested elements items Association to Can be related to Can generally only Related to item via items other items via be related via fields.
  • the NestedElement type inherits from this type.
  • the NestedElement element type additionally defines a field that is a multi-set of Elements.
  • NestedElement extensions are different from item extensions in the following ways: Nested element extensions are not extension types. They do not belong to the extension type hierarchy that is rooted in the Base.Extension type. Nested element extensions are stored along with the other fields of the item and are not globally accessible - a query can not be composed that retrieves all instances of a given extension type.
  • Item extensions vs NestedElement extensions Item Extension NestedElement Extension Storage Item extension hierarchy is Stored like nested elements stored in its own tables Query/Search Can query item extension Can generally only be tables queried within the containing item context Query/Search Can search across all Can generally only search scope instances of an item within nested element type extension type instances of a singe (containing) item Programmability Need special extension NestedElement extensions APIs and special querying are like any other multion extension tables valued field of nested element; normal nested element type APIs are used Behavior Can associate behavior No behavior permitted (?) Relationship No Relationships to item No Relationships to semantics extensions NestedElement extensions Item ID Shares the item id of the Does not have its own item item id.
  • the data store is implemented on a database engine.
  • the database engine comprises a relational database engine that implements the SQL query language, such as the Microsoft SQL Server engine, with object relational extensions.
  • This section describes the mapping of the data model that the data store implements to the relational store and provides information on the logical API consumed by storage platform clients, in accordance with the present embodiment. It is understood, however, that a different mapping may be employed when a different database engine is employed. Indeed, in addition to implementing the storage platform conceptual data model on a relational database engine, it can also be implemented on other types of databases, e.g. object-oriented and XML databases.
  • An object-oriented (OO) database system provides persistence and transactions for programming language objects (e.g. C++, Java).
  • the storage platform notion of an "item” maps well to an "Object” in object-oriented systems, though embedded collections would have to be added to Objects.
  • Other storage platform type concepts like inheritance and nested element types, also map object-oriented type systems.
  • Object-oriented systems typically already support object identity; hence, item identity can be mapped to object identity.
  • the item behaviors (operations) map well to object methods.
  • object-oriented systems typically lack organizational capabilities and are poor in searching. Also, object-oriented systems to do not provide support for unstructured and semi-structured data.
  • XML databases Similar to object-oriented systems, XML databases, based on XSD (XML Schema Definition), support a single-inheritance based type system. The item type system of the present invention could be mapped to the XSD type model. XSDs also do not provide support for behaviors. The XSDs for items would have to be augmented with item behaviors. XML databases deal with single XSD documents and lack organization and broad search capabilities.
  • the relational database engine 314 which in one embodiment comprises the Microsoft SQL Server engine, supports built-in scalar types. Built-in scalar types are "native" and “simple". They are native in the sense that the user cannot define their own types and they are simple in that they cannot encapsulate a complex structure.
  • UDTs User-defined types
  • the storage platform schemas are mapped to UDT classes in the database engine store. Data store Items are mapped to UDT classes deriving from the Base.Item type. Like Items, Extensions are also mapped to UDT classes and make use of inheritance. The root Extension type is Base.Extension, from which all Extension types are derived.
  • a UDT is a CLR class - it has state (i.e., data fields) and behavior (i.e. , routines).
  • UDTs are defined using any of the managed languages - C#, VB.NET, etc.
  • UDT methods and operators can be invoked in T-SQL against an instance of that type.
  • a UDT can 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.
  • MapLib.dll has the assembly called MapLib. In this assembly, there's a class called Point, under the namespace BaseTypes: namespace BaseTypes
  • the "Point" UDT can be used as a column in a table and methods can be invoked in T-SQL as shown below:
  • a storage platform Schema is mapped to a CLR namespace.
  • a storage platform Type is mapped to a CLR class.
  • the CLR class inheritance mirrors the storage platform Type inheritance, and a storage platform Property is mapped to a CLR class property.
  • the Item hierarchy illustrated in Fig. 29 is used as an example in this document. It shows the Base.Item type from which all Item types are derived, along with a set of derived Item types (e.g., Contact.Person and Contact. Employee), with inheritance indicated by anows.
  • Item Mapping Given the desirability for Items to be globally searchable, and the support in the relational database of the present embodiment for inheritance and type substitutability, one possible implementation for Item storage in the database store would be to store all Items in a single table with a column of type Base.Item. Using type substitutability, Items of all types could be stored, and searches could be filtered by Item type and sub-type using Yukon's "is of (Type)" operator. [0201] However, due to concerns about the overhead associated with such an approach, in the present embodiment, the Items are divided by top-level type, such that Items of each type "family" are stored in a separate table.
  • a "shadow" table is used to store copies of globally searchable properties for all Items. This table may be maintained by the Update() method of the storage platform API, through which all data changes are made. Unlike the type family tables, this global Item table contains only the top-level scalar properties of the Item, not the full UDT Item object.
  • the structure of the global Item table is as follows:
  • the global Item table allows navigation to the Item object stored in a type family table by exposing an ItemlD and a TypelD.
  • the ItemlD will generally uniquely identify the Item within the data store.
  • the TypelD may be mapped using metadata, which is not described here, to a type name and the view containing the Item.
  • a Getltem() function is provided to retrieve an Item object given an Item's ItemlD.
  • This function has the following declaration: Base.Item Base.Getltem (uniqueidentifier ItemlD)
  • all queries of Items might be against views built on the Item tables described above. Specifically, views may be created for each Item type against the appropriate type family table. These type views may select all Items of the associated type, including sub-types. For convenience, in addition to the UDT object, the views may expose columns for all of the top- level fields of that type, including inherited fields. Views for the example Item hierarchy shown in Fig. 29 are as follows:
  • Doc.WordDocument view uses a "where" predicate ⁇ to restrict the set of found Items to instances of Doc.WordDocument create view Doc.WordDocument as select Jtem. ItemlD, ⁇ Properties of Base.Item ⁇ , ⁇ Properties of Doc.Document ⁇ , ⁇ Properties of Doc.WordDocument ⁇ , ⁇ Change tracking information ⁇ , cast (Jtem as Doc.WordDocument) from Doc.[Table! Document] where Jtem is of (Doc.WordDocument) [0206]
  • a view may also be created over the global Item table. This view may initially expose the same columns as the table:
  • Extensions are very similar to Items and have some of the same requirements. As another root type supporting inheritance, Extensions are subject to many of the same considerations and trade-offs in storage. Because of this, a similar type family mapping is applied to Extensions, rather than a single table approach. Of course, in other embodiments, a single table approach could be used. [0208] In the present embodiment, an Extension is associated with exactly one Item by ItemlD, and contains an ExtensionlD that is unique in the context of the Item. The Extension table has the following definition: create table Base. [Table!
  • Extension ( ItemlD uniqueidentifier not null, ExtensionlD uniqueidentifier not null, TypelD uniqueidentifier not null, ⁇ Properties of Base.Extension ⁇ , ⁇ Change tracking information ⁇ , constraint [PK_CluJ ⁇ xtension!ltemlD!ExtensionlD] primary key clustered (ItemlD asc, ExtensionlD asc) ) [0209]
  • a function might be provided to retrieve an Extension given its identity, which consists of an ItemlD and ExtensionlD pair. This function has the following declaration: Base.Extension Base.GetExtension (uniqueidentifier ItemlD, uniqueidentifier ExtensionlD,) [0210]
  • a View is created for each Extension type, similar to the Item type views. Assume an Extension hierarchy parallel to the example Item hierarchy, with the following types: Base.Extension, Contact.PersonExtension, Contact.EmployeeExtension. The following views may be created:
  • 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 UDT's, but they are stored within an Items and Extensions.
  • Nested Elements have no storage mapping beyond that of their Item and Extension containers. In other words, there are no tables in the system which directly store instances of NestedElement types, and there are no views dedicated specifically to Nested Elements. 5. Object Identity [0212] Each entity in the data model, i.e., each Item, Extension and Relationship, has a unique key value. An Item is uniquely identified by its Itemld. An Extension is uniquely identified by a composite key of (Itemld, Extensionld). A Relationship is identified by a composite key (Itemld, Relationshipld). Itemld, Extensionld and Relationshipld are GUID values. 6.
  • All objects created in the data store can be stored in a SQL schema name derived from the storage platform schema name.
  • the storage platform Base schema (often called “Base") may produce types in the "[System.Storage]” SQL schema such as "[System.Storage].
  • Item Generated names are prefixed by a qualifier to eliminate naming conflicts. Where appropriate, an exclamation character (!) is used as a separator for each logical part of the name.
  • the table below outlines the naming convention used for objects in the data store. Each schema element (Item, Extension, Relationship and View), is listed along with the decorated naming convention used to access instances in the data store.
  • 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. Data may be stored or changed using the Update() method of the storage platform API, as described more fully below.
  • Each view explicitly defined in a storage platform schema (defined by the schema designer, and not automatically generated by the storage platform) is accessible by the named SQL view [ ⁇ schema-name>].["View! ⁇ view-name>].
  • a view named "BookSales” in the schema "AcmePublisher.Books” would be accessible using the name "[AcmePublisher.Books].[View!BookSales]”.
  • Type specific views also contain an object column which returns the object [0218]
  • Members of each type family are searchable using a series of Item views, with there being one view per Item type in the data store.
  • Item [0219] Each Item search view contains a row for each instance of an Item of the specific type or its subtypes. For example, the view for Document could return instances of Document, LegalDocument and ReviewDocument. Given this example, the Item views can be conceptualized as shown in Fig. 28.
  • (1) Master Item Search View [0220] Each instance of a storage platform data store defines a special Item view called the Master Item View. This view provides summary information on each Item in the data store.
  • the view provides one column per Item type property, a column which described the type of the Item and several columns which are used to provide change tracking and synchronization information.
  • the master item view is identified in a data store using the name "[System.Storage]. [Master ⁇ tem]”.
  • (2) Typed Item Search Views [0221] Each Item type also has a search view. While similar to the root Item view, this view also provides access to the Item object via the "_Item” column.
  • Each typed item search view is identified in a data store using the name [schemaName].[itemTypeName]. For example [AcmeCorp.Doc]. [OfficeDoc].
  • Item Extensions are also accessible using search views.
  • Master Extension Search View Each instance of a data store defines a special Extension view called the Master Extension View. This view provides summary information on each Extension in the data store. The view has a column per Extension property, a column which describes the type of the Extension and several columns which are used to provide change tracking and synchronization information.
  • the master extension view is identified in a data store using the name "[System.Storage]. [Master Extension]".
  • Each Extension type also has a search view. While similar to the master extension view, this view also provides access to the Item object via the JBxtension column.
  • Each typed extension search view is identified in a data store using the name [schemaName] . [ ⁇ xtensionlextensionTypeName] . For example [AcmeCorp.Doc] . [Extension !OfficeDocEx:t] .
  • Each declared Relationship also has a search view which returns all instances of the particular relationship. While similar to the master relationship view, this view also provides named columns for each property of the relationship data.
  • Each relationship instance search view is identified in a data store using the name [schemaName] . [Relationship ! relationshipName] . For example [AcmeCorp.Doc] . [Relationship IDocument Author] .
  • the ProcessOperation method is a single stored procedure defined by the data store which consumes an "operation” that details an action to be performed.
  • the ProcessUpdategram method is a stored procedure which takes an ordered set of operations, known as an "updategram", which collectively detail a set of actions to be performed..
  • the operation format is extensible and provides various operations over the schema elements. Some common operations include: 1. Item operations: a.
  • Createltem (Creates a new item in the context of an embedding or holding relationship) b. Updateltem (updates an existing Item) 2.
  • Relationship operations a. CreateRelationship (creates an instance of a reference or holding relationship) b. UpdateRelationship (updates a relationship instance) c. DeleteRelationship (removes a relationship instances) 3.
  • Change Tracking & Tombstones Change tracking and tombstone services are provided by the data store, as discussed more fully below. This section provides an outline of the change tracking information exposed in a data store.
  • a) Change Tracking Each search view provided by the data store contains columns used to provide change tracking information; the columns are common across all Item, Extension and Relationship views. Storage platform Schema Views, defined explicitly by schema designers, do not automatically provide change tracldng information - such information is provided indirectly through the search views on which the view itself is built. [0233] For each element in the data store, change tracking, information is available from two places - the "master" element view and the "typed" element view.
  • Change tracking information on the AcmeCorp.Document.Document Item type is available from the Master Item View "[System.Storage]. [Master lltem]” and typed Item search view [AcmeCorp .Document] . [Document] .
  • Change tracking information in the master search views provides information on the creation and update versions of an element, information on which sync partner created the element, which sync partner last updated the element and the version numbers from each partner for creation and update. Partners in sync relationships (described below) are identified by partner key.
  • a single UDT object named JZhangeTrackinglnfo of type [System.Storage.Store].ChangeTrackingInfo contains all this information.
  • the type is defined in the System.Storage schema. ChangeTrackinglnfo is available in all global search views for Item, Extension and Relationship. The type definition of ChangeTrackinglnfo is:
  • each typed search view provides additional information recording the sync state of each element in the sync topology.
  • the data store provides tombstone information for Items, Extensions and Relationships.
  • the tombstone views provide information about both live and tombstoned entities (items, extensions and relationships) in one place.
  • the item and extension tombstone views do not provide access to the corresponding object, while the relationship tombstone view provides access to the relationship object (the relationship object is NULL in the case of a tombstoned relationship).
  • Item Tombstones [0237] Item tombstones are retrieved from the system via the view [System.Storage] . [Tombstone ⁇ tern] .
  • Extension Tombstones are retrieved from the system using the view [System.Storage]. [TombstonelExtension]. Extension change tracking information is similar to that provided for Items with the addition of the Extensionld property.
  • Relationships Tombstone [0239] Relationship tombstones are retrieved from the system via the view [System.Storage]. [Tombstone IRelationship]. Relationships tombstone information is similar to that provided for Extensions. However, additional information is provided on the target ItemRef of the relationship instance. In addition, the relationship object is also selected.
  • the data store provides a tombstone cleanup task. This task determines when tombstone information may be discarded. The task computes a bound on the local create / update version and then truncates the tombstone information by discarding all earlier tombstone versions.
  • Helper APIs and Functions [0241] The Base mapping also provides a number of helper functions. These functions are supplied to aid common operations over the data model. a) Function [System.Storage].GetItem
  • Metadata There are two types of metadata represented in the Store: instance metadata (the type of an Item, etc), and type metadata. a) Schema Metadata Schema metadata is stored in the data store as instances of Item types from the Meta schema. b) Instance Metadata Instance metadata is used by an application to query for the type of an Item and finds the extensions associated with an Item. Given the Itemld for an Item, an application can query the global item view to return the type of the Item and use this value to query the Meta.Type view to return information on the declared type of the Item. For example,
  • the security policy for an item can be completely described by the discretionary access control policy and the system access control policy. Each of these is a set of ACL's.
  • the first set (D ACL's) describes the discretionary access granted to the various principals by the owner of the item while the second set of ACL's is referred to as the S ACL's (System Access Control Lists) which specify how the system auditing is done when an object is manipulated in certain ways.
  • each item in the data store is associated with a SID that corresponds to the owner of the item (Owner SID).
  • the primary mechanism for organizing items in a storage platform data store is that of the containment hierarchy. The containment hierarchy is realized using holding relationships between items.
  • the holding relationship between two items A and B expressed as "A contains B" enables the item A to influence the lifetime of the item B.
  • an item in the data store cannot exist until there is a holding relationship from another item to it.
  • the holding relationship in addition to controlling the lifetime of the item, provides the necessary mechanism for propagating the security policy for an item.
  • the security policy specified for each item consists of two parts - a part that is explicitly specified for that item and a part that is inherited from the parent of the item in the data store.
  • the explicitly defined security policy for any item consists of two parts - a part that governs access to the item under consideration and a part that influences the security policy inherited by all its descendants in the containment hierarchy.
  • the security policy inherited by a descendant is a function of the explicitly defined policy and the inherited policy. [0248] Since the security policy is propagated through holding relationships and can also be overridden at any item, it is necessary to specify how the effective security policy for an item is determined. In the present embodiment, an item in the data store containment hierarchy inherits an ACL along every path from the root of the store to the item. [0249] Within the inherited ACL for any given path, the ordering of the various ACE's in the ACL determines the final security policy that is enforced. The following notation is used to describe the ordering of ACE's in an ACL.
  • the ordering of the ACE's in an ACL that is inherited by an item is determined by the following two rules - [0250]
  • the first rule stratifies the ACEs inherited from the various items in a path to the item I from the root of the containment hierarchy.
  • the ACE's inherited from a closer container takes precedence over the entries inherited from a distant container. Intuitively, this allows an administrator the ability to override ACE's inherited from farther up in the containment hierarchy.
  • the second rule orders the ACE's that deny access to an item ahead of the
  • a containment hierarchy being a tree
  • the item has exactly one inherited ACL.
  • the ACL inherited by an item matches the ACL inherited by a file (item) in the existing Windows security model in terms of the relative ordering of the ACE's within them.
  • the containment hierarchy in the data store is a directed acyclic graph (DAG) because multiple holding relationships are permitted to items. Under these conditions, there are multiple paths to an item from the root of the containment hierarchy. Since an item inherits an ACL along every path each item is associated with a collection of ACL's as opposed to a single one.
  • Inherited_ACLs(ItemId) the set of ACL's inherited by an item whose item identity is Itemld from it's parents in the store.
  • Explicit_ACL(ItemId) the ACL explicitly defined for the item whose identity is Itemld.
  • NTSTATUS ACLAccessCheck PSTD pOwnerSid, PDACL pDacl, DWORD DesiredAccess, HANDLE ClientToken, PPRIVILEGEJSET pPrivilegeSet, DWORD *pGrantedAccess
  • every item for which an explicit security policy specification is provided defines a region of identically protected items, and the effective ACL's for all the items in the region is the set of inheritable ACL's for that item.
  • the points in the containment hierarchy at which the effective security policy changes is determined by two kinds of items. The first is items for which an explicit ACL has been specified. Typically these are the points in the containment hierarchy where in the administrator has explicitly specified an ACL.
  • the second is items that have more than one parent, and the parents have different security policies associated with them. Typically, these are the items that are the confluence points of security policy specified for the volume and indicate the beginning of a new security policy.
  • all the items in the data store fall into one of two categories - those that are the root of an identically protected security region and those that are not.
  • the items that do not define security regions belong to exactly one security region.
  • the effective security for an item can be specified by specifying the region to which an item belongs along with the item. This leads to a straight forward model for administering the security of a storage platform data store based upon the various identically protected regions in the store. 2.
  • a security descriptor contains the security information associated with a securable object.
  • a security descriptor consists of a SECURITY J3ESCRIPTOR structure and its associated security information.
  • a security descriptor can include the following security information: 1. STD's for the owner and primary group of an object. 2.
  • a DACL that specifies the access rights allowed or denied to particular users or groups. 3.
  • a SACL that specifies the types of access attempts that generate audit records for the object. 4.
  • applications are not able to directly manipulate the contents of a security descriptor.
  • a discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object. When a process tries to access a securable object, the system checks the ACEs in the object's DACL to determine whether to grant access to it. If the object does not have a DACL, the system grants full access to everyone.
  • a system access control list (SACL) enables administrators to log attempts to access a secured object.
  • Each ACE specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log.
  • An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both.
  • a SACL may also raise an alarm when an unauthorized user attempts to gain access to an object.
  • All types of ACEs contain the following access control information: 1. A security identifier (SID) that identifies the trustee to which the ACE applies. 2. An access mask that specifies the access rights controlled, by the ACE. 3. A flag that indicates the type of ACE. 4. A set of bit flags that determine whether child containers or objects can inherit the ACE from the primary object to which the ACL is attached. [0267] The following table lists the three ACE types supported by all securable objects.
  • Access Mask Format All securable objects arrange their access rights using the access mask format shown in the Fig. 26.
  • the low-order 16 bits are for object-specific access rights
  • the next 7 bits are for standard access rights, which apply to most types of objects
  • the 4 high-order bits are used to specify generic access rights that each object type can map to a set of standard and object-specific rights.
  • the ACCESS JSYSTEMJSECURITY bit corresponds to the right to access the object's SACL.
  • Generic rights are specified in the 4 high-order bits within the mask. Each type of securable object maps these bits to a set of its standard and object-specific access rights. For example, a file object maps the GENERIC JREAD bit to the READ ONTROL and SYNCHRONIZE standard access rights and to the FILE JtEAD ) ATA, FUJEJREAD J3A, and FTLEJREAD_ATTRIBUTES object-specific access rights. Other types of objects map the GENERICJREAD bit to whatever set of access rights is appropriate for that type of object. [0270] Generic access rights can be used to specify the type of access needed when opening a handle to an object. This is typically simpler than specifying all the corresponding standard and specific rights. The following table shows the constants defined for the generic access rights.
  • Each type of securable object has a set of access rights that correspond to operations specific to that type of object.
  • the following table shows the constants defined for the standard access rights.
  • file systems make a fundamental distinction between files and directories, which is why the file and directory rights overlap on the same bits.
  • File systems define very granular rights, allowing applications to control behavior on these objects. For instance they allow applications to distinguish among Attributes (FILEJ ⁇ EAD/WRITE_ATTRIBUTES), Extended Attributes and the DATA stream associated with the file.
  • Attributes FILEJ ⁇ EAD/WRITE_ATTRIBUTES
  • Extended Attributes Extended Attributes
  • DATA stream associated with the file DATA stream associated with the file.
  • a goal of the security model of the storage platform of the present invention is to simplify the rights assignment model so applications operating on data store items (Contacts, Emails, etc.) generally do not have a need to distinguish between attributes, extended attributes and data streams, for example.
  • Win32 rights are preserved and the semantics of access via the storage platform are defined so that compatibility with Win32 applications can be provided. This mapping is discussed with each of the item rights specified below. [0275] The following item rights are specified with their associated allowable operations. The equivalent Win32 rights bacldng each of these item rights is also provided.
  • WinFSItemRead This right allows read access to all elements of the item, including the items linked to the item via embedded relationships. It also allows enumeration of items linked to this item via holding relationships (a.k.a., directory listing). This includes the names of items linked via reference relationships.
  • This right maps to: File: (FILEJtEAD_ATTRIBUTES) Folder: (FILEJ ⁇ EAD_ATTRIBUTES) (4) WinFSItemWriteAttributes [0279]
  • This right allows write access to basic attributes of the Item, much as file systems distinguish between basic file attributes and data streams. Preferably, these basic attributes reside in the base item that all items derive from.
  • This right maps to: File: (FILE WRITE_ATTRIBUTES) Folder: (FELE WRITE_ATTRIBUTES) (5) WinFSItemWrite [0280]
  • This right allows the ability to write to all elements of the item, including items linked via embedded relationships. This right also allows the ability to add or delete embedded relationships to other items.
  • Any item specified using a path can be unlinked if either one of two conditions is satisfied: (1) the parent item along that path grants write access to the subject, or (2) the standard rights on the item itself grant DELETE. When the last Relationship is removed, the item disappears from the system. Any item specified using the ItemlD can be unlinked if the standard rights on the item itself grant DELETE. (9) Rights to copy an item [0286] An item can be copied from a source to a destination folder if the subject is granted WinFSItemRead on the item and WmFSItemWrite on the destination folder.
  • Move file in the file system requires just the DELETE right on the source file and FILE_ADD JFELE on the destination directory, since it preserves the ACL on the destination.
  • a flag can be specified in the MoveFileEx call (MOVEFILE OPY_ALLOWED) that lets an application specify that it in the case of a cross-volume move, it can tolerate CopyFile semantics.
  • MOVEFILE OPY_ALLOWED MoveFileEx call
  • the Item Identity entry is the Item Identity of the root of an identically protected security region.
  • the Item Ordpath entry is the ordpath associated with the root of the identically protected security region.
  • the Explicit Item ACL entry is the explicit ACL defined for the root of the identically protected security region. In some cases this can be NULL, e.g., when a new security region is defined because the item has multiple parents belonging to different regions.
  • the Path ACLs entry is the set of ACL's inherited by the item, and the Region ACLs entry is the set of ACL's defined for the identically protected security region associated with the item.
  • the security region associated with the item is obtained and the ACL's associated with that region are retrieved.
  • the security table is kept up to date to ensure that the above algorithm for determining the effective security of an item is valid.
  • the various changes to the store and the accompanying algorithms to maintain the security table are as follows: a) Creating a new item in a container [0297] When an item is newly created in a container, it inherits all the ACL's associated with the container. Since the newly created item has exactly one parent it belongs to the same region as its parent.
  • Figures 27(a), (b), and (c) depict a new identically protected security region being carved out of an existing security region by introducing a new explicit ACL. This is indicated by the node marked 2. However, the introduction of this new region results in an additional region 3 being created because of an item having multiple holding Relationships. [0301] The following sequence of updates to the security tables reflect the factoring of the identically protected security regions. c) Adding a holding Relationship to an item [0302] When a holding Relationship is added to an item it gives rise to one of three possibilities. If the target of the holding Relationship, i.e., the item under consideration is the root of a security region, the effective ACL associated with the region is changed and no further modifications to the security table is required.
  • the security region of the source of the new holding Relationship is identical to the security region of the existing parents of the item no changes are required. However, if the item now has parents that belong to different security regions, then a new security region is formed with the given item as the root of the security region. This change is propagated to all the items in the containment hierarchy by modifying the security region associated with the item. All the items that belong to the same security region as the item under consideration and its descendants in the containment hierarchy need to be changed. Once the change is made, all the items that have multiple holding Relationships must be examined to determine if further changes are required. Further changes may be required if any of these items have parents of different security regions.
  • a holding Relationship is deleted from an item it is possible to collapse a security region with its parent region if certain conditions are satisfied. More precisely this can be accomplished under the following conditions: (1) if the removal of the holding Relationship results in an item that has one parent and no explicit ACL is specified for that item; (2) if the removal of the holding Relationship results in an item whose parent's are all in the same security region and no explicit ACL is defined for that item.
  • the security region can be marked to be the same as the parent. This marking needs to be applied to all the items whose security region corresponds to the region being collapsed.
  • the storage platform provides a notifications capability that allows applications to track data changes. This feature is primarily intended for applications which maintain volatile state or execute business logic on data change events. Applications register for notifications on items, item extensions and item relationships. Notifications are delivered asynchronously after data changes have been committed. Applications may filter notifications by item, extension and relationship type as well as type of operation. [0307] According to one embodiment, the storage platform API 322 provides two kinds of interfaces for notifications. First, applications register for simple data change events triggered by changes to items, item extensions and item relationships. Second, applications create "watcher" objects to monitor sets of items, item extensions and relationships between items.
  • the storage platform defines watcher classes for monitoring objects associated with a (1) folder or folder hierarchy, (2) an item context or (3) a specific item. For each of the three categories, the storage platform provides specific watcher classes which monitor associated items, item extensions or item relationships, e.g. the storage platform provides the respective FolderltemWatcher, FolderRelationshipWatcher and FolderExtensionWatcher classes.
  • an application may request notifications for preexisting items, i.e. items, extensions or relationships. This option is mostly for applications which maintain a private item cache. If not requested, applications receive notifications for all updates which occur after the watcher object has been created.
  • the storage platform supplies a "WatcherState" object.
  • the WatcherState can be serialized and saved on disk.
  • the watcher state can subsequently be used to re-create the respective watcher after a failure or when reconnecting after going off-line.
  • the newly re-created watcher will re-generate unacknowledged notifications.
  • Applications indicate delivery of a notification by calling the "Exclude” method on the respective watcher state supplying a reference to a notification.
  • the storage platform delivers separate copies of the watcher state to each event handler. Watcher states received on subsequent invocations of the same event handler presume delivery of all previously received notifications.
  • the following code sample shows how to create a folder watcher object for monitoring the contents of a folder.
  • the watcher generates notifications, i.e. events, when new music items are added or existing music items are updated or deleted.
  • Folder watchers either monitor a particular folder or all folders within a folder hierarchy.
  • the storage platform provides a simple, yet efficient mechanism to track data changes and generate notifications.
  • a client retrieves notifications on the same connection used to retrieve data. This greatly simplifies security checks, removes latenci s and constraints on possible network configurations. Notifications are retrieved by issuing select statements.
  • clients may use a "waitfor" feature provided by the database engine 314.
  • Figure 13 shows the basic storage platform notification concept. This waitfor query may be executed synchronously, in which case the calling thread is blocked until results are available, or asynchronously, in which case the thread is not blocked and results are returned on a separate thread, when available.
  • a combination of "waitfor" and “select” is attractive for monitoring data changes which fit into a particular data range as changes can be monitored by setting a notification lock on the respective data range. This holds for many common storage platform scenarios. Changes to individual items can be efficiently monitored by setting notification locks on the respective data range. Changes to folders and folder trees can be monitored by setting notification locks on path ranges. Changes to types and its subtypes can be monitored by setting notification locks on type ranges. [0320] In general, there are three distinct phases associated with processing notifications: (1) data change or even detection, (2) subscription matching and (3) notification delivery. Excluding synchronous notification delivery, i.e.
  • the storage platform can implement two forms of notification delivery: 1) Immediate Event Detection: Event detection and subscription matching is performed as part of the update transaction. Notifications are inserted into a table monitored by the subscriber; and 2) Deferred Event Detection: Event detection and subscription matching is performed after the update transaction has been committed. Subsequently the actual subscriber or an intermediary detects events and generates notifications. [0321] Immediate event detection requires additional code to be executed as part of update operations. This allows the capture of all events of interest including events indicating a relative state change. [0322] Deferred event detection removes the need to add additional code to update operations. Event detection is done by the ultimate subscriber.
  • Deferred event detection naturally batches event detection and event delivery and fits well with the query execution infrastructure of the database engine 314 (e.g., SQL Server).
  • Deferred event detection relies on a log or trace left by update operations.
  • the storage platform maintains a set of logical timestamps together with tombstones for deleted data items.
  • clients supply a timestamp which defines a low watermark for detecting changes and a set of timestamps to prevent duplicate notifications.
  • Applications might receive notifications for all changes which happened after the time indicated by the low watermark.
  • Sophisticated applications with access to core views can further optimize and reduce the number of SQL statements necessary to monitor a potentially large set of items by creating private parameter and duplicate filter tables.
  • the storage platform implements a deferred event detection approach, as described more fully below.
  • Change Tracking All items, extensions and item relationship definitions carry a unique identifier. Change tracking maintains a set of logical timestamps to record creation, update and deletion times for all data items. Tombstone entries are used to represent deleted data items.
  • Applications use that information to efficiently monitor whether a particular item, item extension or item relationship has been newly added, updated or deleted since the application last accessed the data store. The following example illustrates this mechanism.
  • Timestamp Management Logical timestamps are "local" to a database store, i.e. storage platform volume. Timestamps are monotonically increasing 64-bit values. Retaining a single timestamp is often sufficient to detect whether a data change occurred after last connecting to a storage platform volume. However, in most realistic scenarios, a few more timestamps need to be kept to check for duplicates. The reasons are explained below.
  • Relational database tables are logical abstractions built on top of a set of physical data structures, i.e. B-Tree's, heaps etc. Assigning a timestamp to a newly created or updated record is not an atomic action. Inserting that record into the underlying data structures may happen at different times, thus applications may see records out of order.
  • Figure 14 shows two transactions both inserting a new record into the same B-Tree. Since transaction T3 inserts its record before transaction T2's insert is scheduled, an application scanning the B-Tree may see the records inserted by transaction T3 before those inserted by T2. Thus, the reader may incorrectly assume that he has seen all records created up to time "10".
  • the database engine 314 provides a function which returns a low water mark up to which all updates have committed and been inserted into the respective underlying data structures.
  • the low watermark returned would be "5," assuming that the reader started before transaction T2 had been committed.
  • the low watermark provided by the database engine 314 allows applications to efficiently determine which items to ignore when scanning the database or a data range for data changes.
  • ACID transactions are assumed to last a very short time thus, low watermarks are expected to be very close to the most recently dispensed timestamp. In the presence of long lasting transactions, applications might have to keep individual timestamps to detect and discard duplicates.
  • the storage platform provides a synchronization service 330 that (i) allows multiple instances of the storage platform (each with its own data store 302) to synchronize parts of their content according to a flexible set of rules, and (ii) provides an infrastructure for third parties to synchronize the data store of the storage platform of the present invention with with other data sources that implement proprietary protocols.
  • Storage platform-to-storage platform synchronization occurs among a group of participating replicas. For example, with reference to Figure 3, it may be desirable to provide synchronization between the data store 302 of the storage platform 300 with another remote data store 338 under the control of another instance of the storage platform, perhaps running on a different computer system.
  • the total membership of this group is not necessarily known to any given replica at any given time.
  • Different replicas can make the changes independently (i.e. concunently).
  • the process of synchronization is defined as making every replica aware of the changes made by other replicas.
  • This synchronization capability is inherently multi-master.
  • the synchronization capability of the present invention allows replicas to: • determine which changes another replica is aware of; • request information about changes that this replica is not aware of; • convey information about changes that the other replica is not aware of; • determine when two changes are in conflict with each other; • apply changes locally; • convey conflict resolutions to other replicas to ensure convergence; and • resolve the conflicts based on specified policies for conflict resolutions. 1.
  • the primary 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 schemas (rather than the underlying tables of the database engine 314). Thus, for example, "Scopes" are used to define synchronization sets as discussed below.
  • the synchronization service operates on the principle of "net changes”. Rather than recording and sending individual operations (such as with transactional replication), the synchronization service sends the end-result of those operations, thus often consolidating the results of multiple operations into a single resulting change.
  • the synchronization service does not in general respect transaction boundaries. In other words, if two changes are made to a storage platform data store in a single transaction, there is no guarantee that these changes are applied at all other replicas atomically — one may show up without the other. The exception to this principle is that if two changes are made to the same Item in the same transaction, then these changes are guaranteed to be sent and applied to other replicas atomically. Thus, Items are the consistency units of the synchronization service.
  • Synchronization (Sync) Controlling Applications [0342] Any application can connect to the synchronization service and initiate a sync operation. Such an application provides all of the parameters needed to perform synchronization (see sync profile below).
  • SCAs Sync Controlling Applications
  • sync is initiated on one side by an SCA. That SCA informs the local synchronization service to synchronize with the remote partner.
  • the synchronization service is awoken by the messages sent by the synchronization service from the originating machine. It responds based on the persistent configuration information (see mappings below) present on the destination machine.
  • the synchronization service can be run on schedule or in response to events. In these cases, the synchronization service implementing the schedule becomes the SCA.
  • two steps need to be taken.
  • a fundamental concept of the synchronization service is that of a Change Unit.
  • a Change Unit is a smallest piece of schema that is individually tracked by the storage platform. For every Change Unit, the synchronization service may be able to determine whether it changed or did not change since the last sync.
  • Designating Change Units in the schema serves several purposes. First, it determines how chatty the synchronization service is on the wire.
  • the synchronization service allows schema designers to participate in the process.
  • the synchronization service does not support Change Units that are larger than an element. However, it does support the ability for schema designers to specify smaller change units than an element — namely, grouping multiple attributes of an element into a separate Change Unit. In that embodiment, this is accomplished using the following syntax:
  • sync community A group of storage platform partners that wish to keep certain parts of their data in sync are referred to as a sync community. While the members of the community want to stay in sync, they do not necessarily represent the data in exactly the same way; in other words, sync partners may transform the data they are synchronizing.
  • sync partners may transform the data they are synchronizing.
  • the synchronization service takes the approach of defining "Community Folders".
  • a community folder is an abstraction that represents a hypothetical "shared folder" that all community members are synchronizing with. [0351] This notion is best illustrated by an example.
  • Joe wants to keep My Documents folders of his several computers in sync
  • Joe defines a community folder called, say, JoesDocuments.
  • Joe configures a mapping between the hypothetical JoesDocuments folder and the local My Documents folder. From this point on, when Joe's computers synchronize with each other, they talk in terms of documents in JoesDocuments, rather than their local items. This way, all Joe's computers understand each other without having to know who the others are — the Community Folder becomes the lingua franca of the sync community.
  • Configuring the synchronization service consists of three steps: (1) defining mappings between local folders and community folders; (2) defining sync profiles that determine what gets synchronized (e.g.
  • This element names the local folder that the mapping transforms into. The name follows the syntax rules of Folders. The folder must already exist for the mapping to be valid. The items within this folder are considered for synchronization per this mapping. /mappings/transformations This element defines how to transform items from the community folder to the local folder and back. If absent or empty, no transformations are performed. In particular, this means that no IDs are mapped. This configuration is primarily useful for creating a cache of a Folder.
  • mappings/runAs This element controls under whose authority requests against this mapping are processed. If absent, sender is assumed.
  • a Sync Profile is a total set of parameters needed to kick off synchronization. It is supplied by an SCA to the Sync Runtime to initiate sync.
  • Sync profiles for storage platform-to-storage platform synchronization contain the following information: • Local Folder, to serve as the source and destination for changes; • Remote Folder name to synchronize with - this Folder must be published from the remote partner by way of a mapping as defined above; • Direction - the synchronization service supports send-only, receive-only, and send-receive sync; • Local Filter — selects what local information to send to the remote partner.
  • the synchronization service provides a runtime CLR class that allows simple building of Sync Profiles.
  • Profiles can also be serialized to and from XML files for easy storage (often alongside schedules). However, there is no standard place in the storage platform where all the profiles are stored; SCAs are welcome to construct a profile on the spot without ever persisting it. Note that there is no need to have a local mapping to initiate sync. All sync information can be specified in the profile. The mapping is, however, required in order to respond to sync requests initiated by the remote side. (3) Schedules [0356] In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, it relies on another component to peform this task - the Windows Scheduler available with the Microsoft Windows operating system.
  • the synchronization service includes a command-line utility that acts as an SCA and triggers synchronization based on a sync profile saved in an XML file.
  • This utility makes it very easy to configure the Windows Scheduler to run synchronization either on schedule, or in response to events such as user logon or logoff.
  • Conflict handling in the synchronization service is divided into three stages: (1) conflict detection, which occurs at change application time - this step determines if a change can be safely applied; (2) automatic conflict resolution and logging - during this step (that takes place immediately after the conflict is detected) automatic conflict resolvers are consulted to see if the conflict can be resolved - if not, the conflict can be optionally logged; and (3) conflict inspection and resolution - this step takes place if some conflicts have been logged, and occurs outside of the context of the sync session - at this time, logged conflicts can be resolved and removed from the log.
  • conflict Detection In the present embodiment, the synchronization service detects two types of conflicts: knowledge-based and constraint-based.
  • a knowledge-based conflict occurs when two replicas make independent changes to the same Change Unit. Two changes are called independent if they are made without knowledge of each other — in other words, the version of the first is not covered by the knowledge of the second and vice versa.
  • the synchronization service automatically detects all such conflicts based on the replicas' knowledge as described above.
  • Constraint-based conflicts There are cases where independent changes violate an integrity constraint when applied together. For instance, two replicas creating a file with the same name in the same directory could cause such a conflict to occur. [0362] A constraint-based conflict involves two independent changes (just like a knowledge-based one), but they do not affect the same change unit. Rather, they affect different change units but with a constraint existing between them. [0363] The synchronization service detects constraint violations at change application time and raises constraint-based conflicts automatically. Resolving constraint- based conflicts usually requires custom code that modifies the changes in such as way as to not violate the constraint; The synchronization service does not provide a general-purpose mechanism for doing so.
  • the synchronization service can take one of three actions (selected by the sync initiator in the Sync Profile): (1) reject the change, returning it back to sender; (2) log a conflict into a conflict log; or (3) resolve the conflict automatically. [0365] If the change is rejected, the synchronization service acts as if the change did not arrive at the replica. A negative acknowledgement is sent back to the originator. This resolution policy is primarily useful on head-less replicas (such as file servers) where logging conflicts is not feasible. Instead, such replicas force the others to deal with the conflicts by rejecting them. [0366] Sync initiators configure conflict resolution in their Sync Profiles.
  • the synchronization service supports combining multiple conflict resolvers in a single profile in the following ways - first, by specifying a list of conflict resolvers to be tried one after another, until one of them succeeds; and second, by associating conflict resolvers with conflict types, e.g. directing update-update knowledge-based conflicts to one resolver, but all the other conflicts to the log.
  • conflict resolvers with conflict types, e.g. directing update-update knowledge-based conflicts to one resolver, but all the other conflicts to the log.
  • This list includes: • local-wins: disregard incoming changes if in conflict with locally stored data; • remote-wins: disregard local data if in conflict with incoming changes; • last-writer-wins: pick either local-wins or remote-wins per change unit based on the timestamp of the change (note that the synchronization service in general does not rely on clock values; this conflict resolver is the sole exception to that rule); • Deterministic: pick a winner in a manner that is guaranteed to be the same on all replicas, but not otherwise meaningful - one embodiment of the synchronization services uses lexicographic comparisons of partner IDs to implement this feature. [0368] In addition, ISVs can implement and install their own conflict resolvers.
  • Custom conflict resolvers may accept configuration parameters; such parameters must be specified by the SCA in the Conflict Resolution section of the Sync Profile.
  • a conflict resolver When a conflict resolver handles a conflict, it returns the list of operations that need to be performed (in lieu of the conflicting change) back to the runtime. The synchronization service then applies these operations, having properly adjusted remote knowledge to include what the conflict handler has considered.
  • conflict resolutions can be viewed as joins — combining two branches to form a single point. Thus, conflict resolutions turn version histories into DAGs.
  • conflict Logging A very particular kind of a conflict resolver is the Conflict Logger.
  • the synchronization service logs conflicts as Items of type ConflictRecord. These records are related back to the items that are in conflict (unless the items themselves have been deleted).
  • Each conflict record contains: the incoming change that caused the conflict; the type of the conflict: update-update, update-delete, delete-update, insert-insert, or constraint; and the version of the incoming change and the knowledge of the replica sending it.
  • Logged conflicts are available for inspection and resolution as described below.
  • the synchronization service provides an API for applications to examine the conflict log and to suggest resolutions of the conflicts in it.
  • the API allows 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 wins — accepting the logged change and overwriting the conflicting local change; (2) local wins — ignoring conflicting parts of the logged change; and (3) suggest new change — where the application proposes a merge that, in its opinion, resolves the conflict.
  • the synchronization service removes them from the log.
  • the synchronization service applies the principle of binding conflict resolution and picks one of the two resolutions to win over the other automatically. The winner is picked in a deterministic fashion that is guaranteed to produce the same results at all times (one embodiment uses replica ID lexicographic comparisons).
  • the synchronization service treats this new conflict as a special conflict and uses the Conflict Logger to prevent it from propagating to other replicas. Such situation commonly arises with manual conflict resolution. 2.
  • the storage platform provides an architecture for ISVs to implement Sync Adapters that allow the storage platfonxi to synchronize to legacy systems such as Microsoft Exchange, AD, Hotmail, etc.
  • Sync Adapters benefit from the many Sync Service provided by the synchronization service, as described below.
  • Sync Adapters do not need to be implemented as plug-ins into some storage platform architecture. If desired, a "sync adapter" can simply be any application that utilizes the synchronization service runtime interfaces to obtain services such as change enumeration and application.
  • Sync Adapter writers are encouraged to expose the standard Sync Adapter interface, which runs sync given the Sync Profile as described above.
  • the profile provides configuration information to the adapter, some of which adapters pass to the Sync Runtime to control runtime services (e.g. the Folder to synchronize).
  • Sync Services [0381] The synchronization service provides a number of sync services to adapter writers. For the rest of this section, it is convenient to refer to the machine on which the storage platform is doing synchronization as the "client" and the non-storage platform backend that the adapter is talking to as the "server”.
  • Change Enumeration Based on the change-tracking data maintained by the synchronization service, Change Enumeration allows sync adapters to easily enumerate the changes that have occ red to a data store Folder since the last time synchronization with this partner was attempted. [0383] Changes are enumerated based on the concept of an "anchor” — an opaque structure that represents information about the last synchronization. The anchor takes the form of the storage platform Knowledge, as described in the proceeding sections. Sync adapters utilizing change enumeration services fall into two broad categories: those using "stored anchors" vs. those using "supplied anchors".
  • Change Application allows Sync Adapters to apply changes received from their backend to the local storage platform. Adapters are expected to transform the changes to the storage platform schema.
  • the primary function of change application is to automatically detect conflicts. As in the case of Storage Platform-to-Storage Platform sync, a conflict is defined as two overlapping changes being made without knowledge of each other. When adapters use Change Application, they must specify the anchor with respect to which conflict detection is performed.
  • Change Application raises a conflict if an overlapping local change that is not covered by the adapter's knowledge is detected. Similar to Change Enumeration, adapters may use either stored or supplied anchors. Change Application supports efficient storage of adapter-specific meta-data. Such data may be attached by the adapter to the changes being applied, and might be stored by the synchronization service. The data might be returned on next change enumeration. (3) Conflict Resolution [0389] The Conflict Resolution mechanisms described above (logging and automatic resolution options) are available to sync adapters as well. Sync adapters may specify the policy for conflict resolution when applying changes. If specified, conflicts may be passed on to the specified conflict handler and resolved (if possible). Conflicts can also be logged.
  • the adapter may detect a conflict when attempting to apply a local change to the backend. In such a case, the adapter may still pass the conflict on to the Sync Runtime to be resolved according to policy.
  • Sync Adapters may request that any conflicts detected by the synchronization service be sent back to them for processing. This is particularly convenient in the case where the backend is capable of storing or resolving conflicts.
  • Adapter implementation While some "adapters" are simply applications utilizing runtime interfaces, adapters are encouraged to implement the standard adapter interfaces.
  • the synchronization service strives to introduce as little as possible into the security model implemented by the storage platform. Rather than defining new rights for synchronization, existing rights are used. Specifically, • anyone who can read a data store Item can enumerate changes to that item; • anyone who can write to a data store Item can apply changes to that item; and • anyone who can extend a data store Item can associate sync meta-data with that item. [0392] The synchronization service does not maintain secure authorship information.
  • the synchronization service may use 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 failing (non- responsive) replicas are detected.
  • This community-wide monitoring information is made available at every replica. Monitoring tools can be run at an arbitrarily-chosen replica to examine this monitoring information and make administrative decisions. Any configuration changes must be made directly at the affected replicas. H.
  • the storage platform of the present invention is, in at least some embodiments, intended to be embodied as an integral part of the hardware/software interface system of a computer system.
  • the storage platform of the present invention may be embodied as an integral part of an operating system, such as the Microsoft Windows family of operating systems.
  • the storage platform API becomes a part of the operating system APIs through which application programs interact with the operating system.
  • the storage platform becomes the means through which application programs store information on the operating system, and the Item based data model of the storage platform therefore replaces the traditional files system of such an operating system.
  • the storage platform might replace the NTFS file system implemented in that operating system.
  • application programs access the services of the NTFS file system through the Win32 APIs exposed by the Windows family of operating systems.
  • the storage platform enables application programs which rely on the Win32 programming model to access the contents of both the data store of the storage platform as well as the traditional NTFS file system.
  • the storage platform uses a naming convention that is a superset of the Win32 naming conventions to facilitate easy interoperability.
  • the storage platform supports accessing files and directories stored in a storage platform volume .
  • the storage platform implements one namespace in which non-file and file items can be organized.
  • Folders in the data store can contain both file and non-file items, thus presenting a single namespace for file and schematized data. Moreover, it also provides a uniform security, sharing and administration model for all user data.
  • file and non-file items are both accessible using the storage platform APIs and no special rules are imposed for files in this approach, it presents a cleaner programming model for application developers to work against. 3. All namespace operations pass through the storage platform and hence are handled synchronously.
  • search capabilities may not be provided over data sources that are not migrated into the storage platform data store. This includes removable media, remote servers and files on the local disk.
  • a Sync Adapter is provided which manifests proxy items (shortcuts + promoted metadata) in the storage platform for items residing in foreign file systems. Proxy items do not attempt to mimic files either in terms of the namespace hierarchy of the data source or in terms of security.
  • the storage platform leverages FJLESTREAMs directly hosted on NTFS. Thus, there is no change to the on-disk format, thereby obviating any need to expose the storage platform as a new file system at the volume level.
  • a data store (namespace) is constructed corresponding to an NTFS volume.
  • the database and FILESTREAMs backing this portion of the namespace is located on the NTFS volume with which the storage platform data store is associated.
  • a data store conesponding to the system volume is also provided.
  • b) Store Structure [0404] The structure of the store is best illustrated with an example. Consider, as an example, the directory tree on the system volume of a machine named HomeMachine, as illustrated in Fig. 16.
  • NTFS namespace access to Storage Platform files [0407] In the embodiment described herein, it is desirable that files migrated into the storage platform not be accessed via the NTFS namespace even though the actual file streams are stored in NTFS. This way, complicated locking and security considerations that arise from a multi-headed implementation are avoided.
  • Expected namespace/drive letters [0408] Access to files and folders in the storage platform is provided via a UNC name of the form ⁇ machine name> ⁇ WinfsShareName>. For the class of applications that require drive letters for operation, a drive letter can be mapped to this UNC name.
  • the storage platform comprises an API that enables application programs to access the features and capabilities of the storage platform discussed above and to access items stored in the data store.
  • This section describes one embodiment of a storage platform API of the storage platform of the present invention.
  • Figure 19 illustrates the basic architecture of the storage platform API, in accordance with the present embodiment.
  • the storage platform API uses SQLClient 1900 to talk to the local data store 302 and may also use SQLClient 1900 to talk to remote data stores (e.g., data store 340).
  • the local store 302 may also talk to the remote data store 340 using either DQP (Distributed Query Processor) or through the the storage platform synchronization service ("Sync") described above.
  • DQP Distributed Query Processor
  • Sync storage platform synchronization service
  • the storage platform API 322 also acts as the bridge API for data store notifications, passing application's subscriptions to the notification engine 332 and routing notifications to the application (e.g., application 350a, 350b, or 350c), as also described above.
  • the storage platform API 322 may also define a limited "provider" architecture so that it can access data in Microsoft Exchange and AD. 1. Overview [0411]
  • the data access mechanism of the present embodiment of the storage platform API of the present invention addresses four areas: query, navigation, actions, events.
  • Query [0412]
  • the storage platform data store is implemented on a relational database engine 314; as a result, the full expressive power of the SQL language is inherent in the storage platform.
  • the storage platform data model builds a rich, extensible type system on the underlying database abstractions.
  • the storage platform data is a web of items.
  • the storage platform API enables navigation from item to item via filtering, relationships, folders, etc. This is a higher level of abstraction than the base SQL queries; at the same time, it allows rich filtering and navigation capabilities to be used with familiar CLR coding patterns.
  • Actions [0414] The storage platform API exposes common actions on all items - Create, Delete, Update; these are exposed as methods on objects. In addition, domain specific actions such as SendMail, CheckFreeBusy, etc. are also available as methods.
  • the API framework uses well defined patterns that ISVs can use to add value by defining additional actions.
  • Events Data in the storage platform is dynamic. To let applications react when data in the store is changed, the API exposes rich eventing, subscription, and notification capabilities to the developer. 2.
  • Naming and Scopes It is useful to distinguish between namespace and naming.
  • namespace refers to the set of all names available within some system. The system could be an XML schema, a program, the web, the set of all ftp sites (and their contents), etc. Naming is the process or algorithm used to assign unique names to all entities of interest within a namespace.
  • namespace refers to the set of all names available in all the storage platform instances in the universe. Items are the named entities in the the storage platform namespace.
  • the UNC naming convention is used to ensure uniqueness of item names. Every item in every the storage platform store in the universe is addressable by a UNC name.
  • the highest organizational level in the the storage platform namespace is a service - which is simply an instance of the storage platform.
  • the next level of organization is a volume.
  • a volume is the largest autonomous container of items.
  • Each storage platform instance contains one or more volumes. Within a volume are items. Items are the data atoms in the storage platform.
  • a Folder is a special type of Item; there are 2 types of Folders: Containment Folders and Virtual Folders.
  • a Containment Folder is an item which contains holding Relationships to other Items and is the equivalent of the common concept of a file system folder. Each Item is "contained" within at least one containment folder.
  • a Virtual Folder is a more dynamic way of organizing a collection of Items; it is simply a name given a set of Items - the set is either enumerated explicitly or specified by a query.
  • the Virtual Folder is itself an Item and can be thought of as representing a set of (non-holding) Relationships to a set of Items.
  • An Embedded Item has a special land of relationship which references another Item; the referenced Item can be bound to or otherwise manipulated only within the context of the containing Item.
  • the storage platform provides the notion of categories as a way of classification of Items and Elements. Every Item or Element in the storage platform can have associated with it one or more categories. A category is, in essence, simply a name that is tagged on to the Item/Element. This name can be used in searches.
  • the storage platform data model allows the definition of a hierarchy of categories, thus enabling a tree-like classification of data.
  • An unambiguous name for an item is the triplet: ( ⁇ serviceName, ⁇ volumeID>, ⁇ ItemID>).
  • the storage platform names include the notion of a service context: a service context is a name which maps to a ( ⁇ volumeName>, ⁇ path>) pair. It identifies an item or a set of items - for instance, a folder, virtual folder, etc. With the concept of service contexts, the UNC name for any item in the the storage platform namespace becomes: ⁇ serviceName> ⁇ serviceContext> ⁇ itemPath> [0425] Users can create and delete service contexts.
  • Fig. 20 schematically represents the various components of the storage platform API, in accordance with the present embodiment of the invention.
  • the storage platform API consists of the following components: (1) data classes 2002, which represent the storage platform element and item types, (2) mntime framework 2004, which manages object persistence and provides support classes 2006; and (3) tools 2008, which are used to generate CLR classes from the storage platform schemas.
  • the schema author submits a schema document 2010 and code for domain methods2012 to the set of storage platform API design time tools 2008. These tools generate the client side data classes 2002 and the store schema 2014 and store class definitions 2016 for that schema. "Domain" refers to a particular schema; for instance, we talk about domain methods for classes in the Contacts schema, etc. These data classes 2002 are used at runtime by the application developer, in concert with the storage platform API runtime framework classes 2006, to manipulate the storage platform data. [0429] For purposes of illustrating various aspects of the storage platform API of the present invention, examples are presented based on an exemplary Contacts schema. A pictorial representation of this exemplary schema is illustrated in Figures 21 A and 21B. 4.
  • each Item, Item Extension, and Element type, as well as each Relationship, in the storage platform data store has a corresponding class in the storage platform API. Roughly, the fields of the type map to the fields of the class.
  • Each item, item extension, and element in the storage platform is available as an object of the corresponding class in the storage platform API. The developer can query for, create, modify, or delete these objects.
  • the storage platform comprises an initial set of schemas. Each schema defines a set of Item and Element types, and a set of Relationships.
  • System.Storage. S.E For each Element, E, in S a class named System.Storage. S.E is generated. This class has the following members: • A property for each field in E. If the field is multi-valued, the property will be a collection of the corresponding Element types.
  • a class named System.Storage.S.ECoUection For each Element, E, in S a class named System.Storage.S.ECoUection is generated.
  • This class follows general .NET Framework guidelines for strongly typed collection classes.
  • This class will also include the following members: • An overloaded method which finds multiple Item objects that match a filter which implicitly includes the item in which the collection appears in the source role.
  • the overloads include some that allow filtering based on Item sub-type (for example, a method named "FindAUTargetltems").
  • An overloaded method which finds a single Item object that matches a filter which implicitly includes the item in which the collection appears in the source role.
  • the overloads include some that allow filter based on Item subtype (for example, a method named "FindOneTargetltem”).
  • An overloaded method which finds objects of the nested element type that match a filter which implicitly includes the item in which the collection appears in the source role (for example, a method named "FindAllRelationships").
  • An overloaded method whichs find objects of the nested element type that match a filter which implicitly includes the item in which the collection appears in the source role (for example, a method named "FindAURelationshipsForTarget”).
  • the contacts schema results in the following classes, contained in the System.Storage.Contact namespace: • Items: Item, Folder, WellKnownFolder, LocalMachineDataFolder, UserDataFolder, Principal, Service, GroupService, PersonService, PresenceService, ContactService, ADService, Person, User, Group, Organization, HouseHold • Elements: NestedElementBase, NestedElement, IdentityKey, SecuritylD, EAddress, ContactEAddress, TelehoneNumber, SMTPEAddress, InstantMessagingAddress, Template, Profile, FullName, FamilyEvent, BasicPresence, WindowsPresence, Relationship, TemplateRelationship, LocationRelationship, FamilyEventLocationRelationship, HouseHoldLocationRelationship, RoleOccupancy, EmployeeData, GroupMemberShip, OrganizationLocationRelationship, HouseHoldMemberData, FamilyData, SpouseData, ChildData [0434]
  • Data.SqlTypes.SqlBinary PersonalPicture ⁇ get; set; ⁇ public System.Storage.Core.RichTextCollection Notes ⁇ get; ⁇ public System.Storage.Base.CategoryRefCollection Profession ⁇ get; ⁇ public System.Storage.Base.ldentityKeyCollection DataSource ⁇ get; ⁇ public System. Data.SqlTypes.SqlDateTime ExpirationDate ⁇ get; set; ⁇ public System.
  • Storage.ltemStore store, string filter public static new Person FindOne( System.Storage.ltemStore store, string filter ); public new event System.Windows.Data.PropertyChangedEventHandler PropertyChangedHandler; public static new Person FindBylD( System.Storage.ltemStore store, long item_key );
  • the hierarchy of classes resulting from a given schema directly reflects the hierarchy of types in that schema.
  • the class hierarchy conesponding to this in the storage platform API would be as follows: Object DataClass ElementBase RootltemBase Item Principal Group Household Organization Person User Service PresenceService ContactService ADService RootNestedBase ... (Element classes)
  • Yet another schema the schema that allows representing all the audio/video media in the system (ripped audio files, audio CDs, DVDs, home videos, etc.), enables users/applications to store, organize, search through, and manipulate different kinds of audio/video media.
  • the base media document schema is generic enough to represent any media, and the extensions to this base schema are designed to handle domain-specific properties separately for audio and video media. This schema, and many, many others, are envisioned to operate directly or indirectly under the Core Schema. 5.
  • the basic storage platform API programming model is object persistence. Application programs (or "applications") execute a search on a store and retrieve objects representing the data in the store. Applications modify the retrieved objects or create new objects, then cause their changes to be propagated into the store. This process is managed by an ItemContext object. Searches are executed using an ItemSearcher object and search results are accessible via a FindResult object.
  • the runtime framework implements a number of classes to support the operation of the data classes. These framework classes define a common set of behaviors for the data classes and, together with the data classes, provide the basic programming model for the storage platform API. Classes in the runtime framework belong to the System.Storage namespace. In the present embodiment, the framework classes comprise the following main classes: ItemContext, ItemSearcher, and FindResult. Other minor classes, enum values, and delegates may also be provided.
  • ItemContext object (i) represents a set of item domains that an application program wants to search, (ii) maintains state information for each object that represents the state of the data as retrieved from the storage platform, and (iii) manages the transactions used when interacting with the storage platform and any file system with which the storage platform may interoperate.
  • ItemContext provides the following services: 1. Deserializes data read from the store into objects. 2. Maintains object identity (the same object is used to represent a given item no matter how many times that item is included in the result of queries). 3. Tracks object state.
  • ItemContext also performs a number of services unique to the storage platform: 1.
  • Appendix A provides a source code listing of the ItemContext class, in accordance with one embodiment thereof.
  • ItemSearcher supports simple searches, which return whole Item objects, streams of Item objects, or streams of values projected from Items. ItemSearcher encapsulates the core functionality that is common to all of these: the concept of a target type and parameterized filters that are applied to that target type. The ItemSearcher also allows searchers to be pre-compiled, or prepared, as an optimization when the same search will be executed multiple types. Appendix B provides a source code listing of the ItemSearcher class and several closely related classes, in accordance with one embodiment thereof. (a) Target Type [0447] The search target type is set when constructing an ItemSearcher. The target type is a CLR type that is mapped to a queryable extent by the data store.
  • the searcher When retrieving a searcher using the ItemContext.GetSearcher method, the searcher's target type is specified as a parameter. When a static GetSearcher method is invoked on an item, relationship, or item extension type (e.g. Person. GetSearcher), the target type is the item, relationship, or item extension type.
  • Search expressions provided in an ItemSearcher (for example, the search filter and through find options, or projection definitions) are always relative to the search target type. These expressions may specify properties of the target type (including properties of nested elements) and may specify joins to relationship and item extensions as described elsewhere.
  • the search target type is made available via a read only property (for example, an ItemSearcher.Type property).
  • the ItemSearcher contains a property to specify filters (for example, a property named "Filters" as a collection of SearchExpression objects) that define the filter used in the search. All filters in the collection are combined using a logical and operator when the search is executed.
  • the filter may contain parameter references. Parameter values are specified through the Parameters property.
  • Preparing Searches [0452] In situations where the same search is to be executed repeatedly, possibly with only parameter changes, some performance improvement can be gained by precompiling, or preparing, the search.
  • Find Options There are a number of options that can be applied to a simple search. These may be specified, for example, in a FindOptions object and passed to the Find methods. For example:
  • ItemSearcher searcher Person.GetSearcher( context );
  • FindResult result searcher.FindAII( options ); [0454] As a convenience, sort options may also be passed directly to the Find methods:
  • the DelayLoad option determines if the values of large binary properties are loaded when the search results are retrieved or if loading is delayed until they are referenced.
  • the MaxResults option determines the maximum number of results that are returned. This is equivalent to specifying TOP in a SQL query. It is most often used in conjunction with sorting.
  • a sequence of SortOption objects can be specified (for example, using a FindOptions.SortOptions property). The search results will be sorted as specified by the first SortOption object, then by as specified by the second SortOption object, etc.
  • the SortOption specifies a search expression that indicates the property that will be used for sorting. The expression specifies one of the following: 1.
  • a scalar property in the search target type 2. a scalar property in a nested element that is reachable from the search target type by traversing single valued properties; or 3. the result of an aggregation function with a valid argument (for example, Max applied to a scalar property in a nested element that is reachable from the search target type by traversing a multi-valued property or a relationship).
  • search target type is System.Storage. Contact.Person: 1. "Birthdate” - valid, birthdate is a scalar property of the Person type; 2. "PersonalNames.Surname” - Invalid, PersonalNames is a multi-valued property and no aggregation function was used; 3.
  • Item Result Stream (“FindResult")
  • the ItemSearcher (for example, through the FindAll method) returns an object that can be used to access the objects returned by the search (for example, a "FindResult” object).
  • Appendix C provides a source code listing of the FindResult class and several closely related classes, in accordance with one embodiment thereof.
  • the enumerator pattern is standard in the CLR and supports language constructs like C#'s foreach. For example:
  • the reader pattern is supported because it allows results to be processed more efficiently by eliminating a data copy in some cases. For example:
  • a FindResult should be closed when it is no longer needed. This can be done by calling the Close method or using language constructs such as C#'s using statement. For example:
  • FIG. 22 illustrates the runtime framework in operation.
  • the runtime framework operates as follows: 1. An application 350a, 350b, or 350c binds to an item in the storage platform. 2.
  • the framework 2004 creates an ItemContext object 2202 conesponding to the bound item and returns it to the application. 3.
  • the application submits a Find on this ItemContext to get a collection of Items; the returned collection is conceptually an object graph 2204 (due to relationships). 4.
  • the application changes, deletes, and inserts data. 5.
  • the application saves the changes by calling the Update() method.
  • c) Common Programming Patterns [0463] This section provides a variety of examples of how the storage platform API framework classes can be used to manipulate items in the data store.
  • the storage platform API provides a simplified query model that enables application programmers to form queries based on various properties of the items in the data store, in a manner that insulates the application programmer from the details of the query language of the underlying database engine.
  • Applications can execute a search across the domains specified when the ItemContext was opened using an ItemSearcher object returned by the ItemContext.GetSearcher method.
  • Search results are accessed using a FindResult object.
  • the basic search pattern involves using an ItemSearcher object retrieved from an ItemContext by calling the GetSearcher method.
  • the GetSearcher pattern enables these scenarios.
  • the API collects changes to an item made by an application program and then organizes them into the conect updates required by the database engine (or any kind of storage engine) on which the data store is implemented.
  • the GetPathSecurity and SetPathSecurity provide the mechanism for retrieving and modifying the ACL that exists on an item because of a holding relationship from another folder.
  • This ACL is composed from the ACL's of the various ancestors to the item along the path under consideration along with the explicit ACL if any supplied for that path.
  • the difference between this ACL and the ACL in the previous case is that this ACL remains in play only as long as the corresponding holding relationship exists while the explicit item ACL is independent of any holding relationship to an item.
  • the ACL's that can be set on an item with SetltemSecurity and SetPathSecurity is restricted to inheritable and object specific ACE's. They cannot contain any ACE marked as inherited.
  • the GetEffectiveltemSecurity retrieves the various path based ACL's as well as the explicit ACL on the item. This reflects the authorization policy in effect on the given item. 7. Support for Relationships [0480] As discussed above, the data model of the storage platform defines "relationships" that allow items to be related to one another. When the data classes for a schema are generated, the following classes are produced for each relationship type: 1. A class that represents the relationship itself.
  • This class is derived from the Relationship class and contains members specific to the relationship type. 2.
  • a strongly typed "virtual" collection class This class is derived from VirtualRelationshipCollection and allows relationship instances to be created and deleted. [0481] This section describes the support for relationshps in the storage platform API.
  • a) Base Relationship Types [0482] The storage platform API provides a number of types in the System.Storage namespace that form the foundation of the relationship API. These are: 1. Relationship - the base type of all relationship classes 2. VirtualRelationshipCollection - the base type for all relationship collections 3. ItemReference, ItemldReference, ItemPathReference - Represent the item reference types; the relationship among these types is illustrated in Fig. 11. (1) Relationship Class [0483] The following is the base class for relationship classes. public abstract class Relationship : StoreObject
  • public Item Targetltem ⁇ get; ⁇ // Determines if the ItemContext already has a connection to the target item's domain (calls // TargetltemReference.lsDomainConnected).
  • public bool IsTargetDomainConnected ⁇ get; ⁇ // The name of the target item in the namespace. The name must be unique across all the // source item's holding relationships.
  • ItemReference Class [0484] The following is the base class for item reference types.
  • public abstract class ItemReference NestedElement
  • ItemReference objects may identify items that exist in a store other than the one where the item reference itself resides. Each derived type specifies how a reference to a remote store is constructed and used. Implementations of Getltem and IsDomainConnected in derived classes use the ItemContext's multi-domain support to load items from the necessary domain and to determine if a connection to the domain has already been established. (3) ItemldReference Class [0486] The following is the ItemldRefrence class - an Item reference that uses an item id to identify the target item. public class ItemldReference : ItemReference
  • ItemPathReference Class is an item reference that uses a path to identify the target item.
  • the code for the class is as follows: public class ItemPathReference : ItemReference
  • the VirtualRelationshipCollection class implements a collection of relationship objects that includes objects from the data store, plus new objects that have been added to the collection, but not including objects that have been removed from the store. Objects of a specified relationship type with a given source item id are included in the collection. [0493] This is the base class for the relationship collection class that is generated for each relationship type. That class can be used as the type of a property in the source item type to provide access and easy manipulation of a given item's relationships. [0494] Enumerating the contents of a VirtualRelationshipCollection requires that a potentially large number of relationship objects be loaded from the store.
  • the virtual collection contains the conect set of objects regardless of whether or not a relationship object is added/removed through the Item.Relationships collection or any other relationship collection on that item.
  • the following code defines the VirtualRelationshipCollection class: public abstract class VirtualRelationshipCollection : ICollection ⁇ // The collection will contain the relationships of the specified type owned by the item // identified by itemld. protected VirtualRelationshipCollection ItemContext itemContext, Itemld itemld, Type relationshipType );
  • the RelationshipPrototype class represents the relationship itself.
  • the RelationshipPrototypeCollection class provides access to the RelationshipPrototype instances that have a specified item as the source end point.
  • RelationshipPrototype Class This is a prototypical relationship class for a holding relationship named "HoldingRelationshipPrototype" where the source end point is named “Head” and specifies the "Foo” item type and the target end point is named “Tail” and specifies the "Bar” item type. It is defined as follows: public class RelationshipPrototype : Relationship
  • RelationshipPrototypeCollection Class This is a prototypical class, generated with the RelationshipPrototype class, that maintains a collection of RelationshipPrototype relationship instances owned by a specified item. It is defined as follows: public class Relationship PrototypeCoHection : VirtualRelationshipCollection
  • the Item class contains a Relationships property that provide access to the relationships in which that item is the source of the relationship.
  • the Relationships property has the type RelationshipCollection.
  • Item Class [0503] The following code shows the relationship context properties of the Item class:. public abstract class Item : StoreObject
  • RelationshipCollection Class This class provides access to the relationship instances where a given item is the source of the relationship. It is defined as follows: public class RelationshipCollection : VirtualRelationshipCollection
  • Item source ltem.FindByld( ic, sid );
  • Itemld tid ...; // an target item's id.
  • each relationship class supports static FindAll, FindOne, and FindOnly API.
  • a relationship type can be specified when calling ItemContext.GetSearcher, ItemContext.FindAU,
  • ItemContext.FindOne or ItemContext.FindOnly.
  • the base relationship class provides Sourceltem and Targetltem properties that return an Item object.
  • the storage platform API opens a connection to the target domain as needed. Applications can determine if a connection would be required before retrieving the target item.
  • Search for target item in an unconnected domain searcher Relationship.GetSearcher( source ); foreach( Relationship relationship in searcher.FindAIIO ) ⁇ if( reltionship.lsTargetDomainConnected ) ⁇
  • Item member relationship.Targetltem; ⁇ '" ⁇
  • Item target relationship.Targetltem
  • Console.WriteLine( "Item ⁇ 0 ⁇ is the source of the following relationships:", folder.ltemld ); foreach( FolderMember folderMember in folder.MemberRelationships )
  • Item target folderMember.GetMemberltem()
  • An item may have many relationships, so applications should use caution when enumerating a relationship collection.
  • a search should be used to identify particular relationships of interest instead of enumerating the entire collection.
  • having a collection based programming model for relationships is valuable enough, and items with many relationships rare enough, that the risk of abuse by the developer is justified.
  • Applications can check the number of relationships in the collection and use a different programming model if needed. For example: Check the size of a relationship collection if( folder.MemberRelationships. Count > 1000 ) ⁇ Console.WriteLine( "Too many relationships! ); ⁇ else ⁇ ⁇ '"
  • relationship collections described above are "virtual" in the sense that they are not actually populated with objects that represent each relationship unless the application attempts to enumerate the collection. If the collection is enumerated, the results reflect what is in the store, plus what has been added by the application but not yet saved, but not any relationships that have been removed by the application but not saved.
  • Creating Relationships (and Items) [0521] New relationships are created by creating a relationship object, adding it to a relationship collection in the source item, and updating the ItemContext. To create a new item, a holding or embedding relationship must be created.
  • Every storage platform schema results in a set of classes. These classes have standard methods such as Find* and also have properties for getting and setting field values. These classes and associated methods form the foundation of the storage platform API.
  • a) Domain Behaviors [0523] In addition to these standard methods, every schema has a set of domain specific methods for it. We call these domain behaviors. For example, some of the domain behaviors in the Contacts schema are: • Is an email address valid? • Given a folder, get the collection of all members of the folder. • Given an item ID, get an object representing this item • Given a Person, get his online status • Helper functions to create a new contact or a temporary contact • And so on.
  • MailMessage m MailMessage.FindOne(...); OutlookEMailServices.SendMessage(m);
  • ICachedServiceProvider interface This interface extends the System.IServiceProvider interface as follows: interface ICachedServiceProvider : System.IServiceProvider
  • the storage platform data class maintains a hashtable of service providers keyed by type.
  • the implementation first looks in the hashtable to see if a service provider of the specified type has been set. If not, the registered service provider infrastructure is used to identify a service provider of the specified type. An instance of this provider is then created, added to the hashtable, and returned. Note that it is also possible for a shared method on the data class to request a service provider and forward an operation to that provider. For example, this could be used to provide a Send method on the mail message class that uses the e-mail system specified by the user.
  • FIG. 24 shows the components involved.
  • the types in the schema are contained in an XML file (box 1). This file also contains field level and item level constraints associated with the schema.
  • the storage platform Class generator (xfs2cs.exe - box 2) takes this file and generates the partial classes for the store UDTs (box 5) and partial classes for the client classes (box 3). For each schema domain, there exist additional methods - which we call domain behaviors.
  • Boxes 4, 5, and 7 are compiled (box 9) to form the server side UDT assembly - box 12 (actually, the server side UDT assembly is the result of compiler-plus-ing boxes 4, 5, and 7 that result from all initial schema domains).
  • the DDL Command Generator module (box 13) takes the UDT assembly (box 12) and the Schema file (box 1), and installs them on the data store. This process involves, among other things, the generation of tables and views for the types in each schema. 10.
  • Query Formalism When reduced to the basics, the application's pattern when using the storage platform API is: Open an ItemContext; use Find with a filter criterion to retrieve the desired objects; operate on the objects; and send changes back to the store.
  • the filter string provided when finding the storage platform data objects describes the conditions that the properties of the objects must meet in order to be returned.
  • the syntax used by the storage platform API supports type casts and relationship traversal.
  • a filter string is either empty, indicating that all objects of the specified type are to be returned, or a boolean expression that each returned object must satisfy.
  • the expression references the object's properties.
  • the storage platform API runtime knows how these property names map to the storage platform type field names and, ultimately, to the SQL views maintained by the the storage platform store.
  • ItemContext ctx ltemContext.Open("Work Contacts”);
  • FindResult results Person. FindAII( ctx, "Birthdate > '12/31/1999'” ); foreach( Person person in results ) Console.WriteLine(person.DisplayName); ctx.Close(); [0542] Line 1 creates a new ItemContext object to access the "Work Contacts" on the storage platform share on the local computer. Lines 3 and 4 get a collection of Person objects where the birthdate property specifies a date more recent then 12/31/1999, as specified by the expression "Birthdate > 12/31/1999"'. The execution of this FindAll operation is illustrated in Figure 23.
  • Type Casts It is often the case that the type of a value stored in a property is derived from the properties declared type. For example, the PersonalEAddresses property in Person contains a collection of types derived from EAddress such as EMailAddress and TelephoneNumber. In order to filter based on telephone area code, it is necessary to cast from the EAddress type to the TelephoneNumber type:
  • the storage platform API allows an application to determine if a given ItemContext object (as returned by the ItemContext.Open method) represents a local or remote connection using the IsRemote property - this is a property on the ItemContext object. Among other things, the application may wish to provide visual feedback to help set user expectations for performance, reliability, etc.
  • a storage platform implementation of Remoting [0548] The storage platform data stores talk to each other using a special OLEDB provider which runs over HTTP (the default OLEDB provider uses TDS). In one embodiment, a distributed query goes through the default OPENROWSET functionality of the relational database engine.
  • a special user defined function (UDF): DoRemoteQuery(server, queryText) is provided to do actual remoting.
  • c) Accessing Non-Storage Platform Stores [0549]
  • a limited provider architecture for the specific case of Microsoft Exchange and Microsoft Active Directory (AD) is provided. This implies that developers can use the storage platform API and access data in AD and Exchange just as they would in the storage platform, but that the data they can access is limited to the storage platform schematized types.
  • mail, calendar and contacts are supported for Exchange.
  • constraints are evaluated on the store automatically and the process is transparent to the user. Note that constraints are checked at the server. Having noted this, sometimes, it is desirable to give the developer the flexibility to verify that the input data satisfies the constraints without incurring the overhead of a round trip to the server. This is especially useful in interactive applications where the end user enters the data which is used to populate an object.
  • the storage platform API provides this facility. [0553] Recall that a storage platform Schema is specified in an XML file, which is used by the storage platform to generate the appropriate database objects representing the schema. It is also used by the design time framework of the storage platform API to auto generate classes.
  • the Check tags in the XML above specify the constraints on the Person type. There can be more than one check tag.
  • the above constraint is generally checked in the store.
  • Folder f UserDataFolder.FindMyPersonalContactsFolder( ctx );
  • a share in the storage platform is of the form: ⁇ DNS Name> ⁇ Context Service>, where ⁇ DNS Name> is the DNS name of the machine, and ⁇ Context Service> is a containment folder, virtual folder, or an item in a volume on that machine.
  • a share is an item, shares can be managed just as with other items. A share can be created, deleted, and modified. A share is also secured the same way as other storage platform items.
  • c) Accessing Shares An application accesses a remote storage platform share by passing the share name (e.g. ⁇ Johns_Desktop ⁇ WorkContacts) to the storage platform API in the ItemContext.OpenO method call. ItemContext.Open returns an ItemContext object instance. The storage platform API then talks to the local storage platform service (recall that accessing remote storage platform shares is done via the local storage platform). In turn, the local storage platform service talks to a remote storage platform service (e.g.
  • an application program can discover shares available on a given ⁇ DNS Name>, in the following ways. According to the first way, the storage platform API accepts a DNS name (e.g. Johns_Desktop) as the scope parameter in ItemContext.Open() method. The storage platform API then connects to the storage platform store with this DNS name as part of a connection string.
  • a DNS name e.g. Johns_Desktop
  • ItemContext.FindAU typeof(Share)
  • a storage platform service then unions all the shares on all the attached volumes and returns the collection of shares.
  • the Find* methods (regardless of whether they are called on the ItemContext object or on an individual item) generally apply to Items (including embedded items) within a given context. Nested elements do not have a Find - they cannot be searched independently of their containing Items.
  • This schema has, for example, the following classes: • Items: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location • Elements: Profile, PostalAddress, EmailAddress, TelephoneNumber, RealTimeAddress, EAddress, FullName, BasicPresence, GroupMembership, RoleOccupancy b) Domain Behaviors [0566] Below is a list of domain behaviors for the Contacts schema. When viewed from a high enough level, domain behaviors fall into well-recognizable categories: • Static Helpers, for example, Person.
  • Storage Platform File API This section gives an overview of the the storage platform File API, in accordance with one embodiment of the present invention.
  • a) Introduction (1) Reflecting an NTFS Volume in the Storage Platform [0569] The storage platform provides a way of indexing over content in existing NTFS volumes. This is accomplished by extracting ("promoting") properties from each file stream or directory in NTFS and storing these properties as Items in the storage platform.
  • the storage platform File schema defines two item types - File and Directory - to store promoted file system entities.
  • the Directory type is a subtype of the Folder type; it is a containment folder which contains other Directory items or File items.
  • a Directory item can contain Directory and File items; it cannot contain items of any other type.
  • the File System Promotion Manager (FSPM) service asynchronously promotes changed properties into the storage platform.
  • the properties of File and Directory items can be changed by the Win32 API.
  • the storage platform API can be used to read any of the properties of these items, including the stream associated with a File item.
  • (2) Creating Files and Directories in the storage platform Namespace [0572] When an NTFS volume gets promoted to a storage platform volume, all the files and directories therein are in a specific part of that volume. This area is read-only from the storage platform perspective; the FSPM can create new directories and files and/or change properties of existing items.
  • the rest of the namespace of this volume can contain the usual gamut of the storage platform item types - Principal, Organization, Document, Folder, etc.
  • the storage platform also allows you to create Files and Directories in any part of the the storage platform namespace. These "native" Files and Directories have no counterpart in the NTFS file system; they are stored entirely in the storage platform. Furthermore, changes to properties are visible immediately. [0574] However, the programming model remains the same: they are still read-only as far as the the storage platform data access APIs are concerned. The "native" Files and Directories have to be updated using Win32 APIs. This simplifies the developer's mental model, which is: 1. Any storage platform item type can be created anywhere in the namespace (unless prevented by permissions, of course); 2.
  • Any storage platform item type can be read using the storage platform API; 3. All storage platform items types are writable using the storage platform API with the exception of File and Directory; 4. To write to File and Directory items regardless of where they are in the namespace, use the Win32 API; and 5. Changes to File/Directory items in the "promoted" namespace may not appear immediately in the storage platform; in the "non-promoted" namespace, the changes are reflected immediately in the storage platform.
  • Figure 25 illustrates the schema on which the File API is based.
  • c) Overview of System.Storage.Files [0576] The storage platform API includes a namespace for dealing with 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 is "promoted" from the file system objects or may be created natively using the Win32 API.
  • Fileltem f Fileltem. FindByPath (ctx, @" ⁇ My Documents ⁇ billg.ppt");
  • Line 3 uses the FindByPath method to open the file.
  • Line 7 shows the use of the promoted property, IsReadOnly, to check if the file is writeable. If it is, then in line 9 we use the
  • the file class in addition to the standard properties and methods, the file class also has domain behaviors (hand coded properties and methods). These behaviors are generally based on methods in the conesponding System.IO classes.
  • the present invention is directed to a storage platform for organizing, searching, 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 designed to be the store for all types of data, including structured, non-structured, or semi-structured data, such as relational (tabular) data, XML, and a new form of data called Items.
  • structured, non-structured, or semi-structured data such as relational (tabular) data, XML, and a new form of data called Items.
  • the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises. It offers a rich and extensible application programming interface that not only makes available the capabilities inherent in its data model, but also embraces and extends existing file system and database access methods.
  • This program code may be stored on a computer-readable medium, such as a magnetic, electrical, or optical storage medium, including without limitation a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer or server, the machine becomes an apparatus for practicing the invention.
  • a computer-readable medium such as a magnetic, electrical, or optical storage medium, including without limitation a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer or server, the machine becomes an apparatus for practicing the invention.
  • the present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, over a network, including the Internet or an intranet, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.
  • program code When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.
  • ItemContext I Disposable, IServiceProvider ⁇ ItemContext Creation and Management Members // Applications cannot create ItemContext objects directly nor can they derive // classes from ItemContext.
  • ItemContext can provide the following kinds of services: // lltemSerialization, IStoreObjectCache public object GetService( Type serviceType ); Update Related Members // Saves changes represented by all modified objects and all objects passed to // MarkForCreate or MarkForDelete. May throw UpdateCollisionException if an update // collision is detected.
  • public void Update() // Saves changes represented by the specified objects. The objects must have either // been modified or passed to MarkForCreate or MarkForDelete, otherwise Argument- // Exception is thrown. May throw UpdateCollisionException if an update collision is // detected.
  • public lAsyncResult BeginFindAII ( AsyncCallback callback, object state ); public lAsyncResult BeginFindAII( FindOptions findOptions, AsyncCallback callback, object state ); public lAsyncResult BeginFindAII( SortOption[] sortOptions, AsyncCallback callback, object state ); public FindResult EndFindAII( lAsyncResult ar ); public lAsyncResult BeginFindOne( AsyncCallback callback, object state ); public lAsyncResult BeginFindOne( FindOptions findOptions, AsyncCallback callback, object state ); public lAsyncResult BeginFindOne( SortOptionFJ sortOptions, AsyncCallback callback, object state ); public object End
  • lObjectReader lEnumerable, IDisposable ⁇ object Current ⁇ get; ⁇ bool IsClosed ⁇ get; ⁇ bool HasResults ⁇ get; ⁇ Type ObjectType ⁇ get; ⁇ bool Read(); void Close(); ⁇ // Adds asynchronous methods to lObjectReader public interface lAsyncObjectReader : lObjectReader ⁇ lAsyncResult BeginRead( AsyncCallback callback, object state ); bool EndRead( lAsyncResult result ); ⁇ ⁇
PCT/US2003/026144 2003-08-21 2003-08-21 Systems and methods for data modeling in an item-based storage platform WO2005029313A1 (en)

Priority Applications (34)

Application Number Priority Date Filing Date Title
CNB038269430A CN100570549C (zh) 2003-08-21 2003-08-21 用于基于项目的存储平台中的数据建模的系统和方法
MXPA06001986A MXPA06001986A (es) 2003-08-21 2003-08-21 Sistemas y metodos para modelar datos en una plataforma de almacenamiento basada en elementos.
PCT/US2003/026144 WO2005029313A1 (en) 2003-08-21 2003-08-21 Systems and methods for data modeling in an item-based storage platform
BRPI0318469-2A BR0318469A (pt) 2003-08-21 2003-08-21 sistemas e métodos para modelar dados em uma plataforma de armazenamento baseada em item
KR1020067003584A KR101024730B1 (ko) 2003-08-21 2003-08-21 항목 기반 저장 플랫폼 내에서 데이터 모델링하기 위한시스템 및 방법
EP03818743A EP1658555A4 (en) 2003-08-21 2003-08-21 SYSTEMS AND METHODS FOR MODELING DATA IN A STORAGE PLATFORM BASED ON OBJECTS
CA2533088A CA2533088C (en) 2003-08-21 2003-08-21 Systems and methods for data modeling in an item-based storage platform
AU2003259959A AU2003259959B2 (en) 2003-08-21 2003-08-21 Systems and methods for data modeling in an item-based storage platform
JP2005509096A JP4394643B2 (ja) 2003-08-21 2003-08-21 アイテムベースのストレージプラットフォームにおけるデータモデリングのためのシステムおよび方法
TW093122603A TWI337310B (en) 2003-08-21 2004-07-28 Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
CA2506337A CA2506337C (en) 2003-08-21 2004-07-29 Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
JP2006523871A JP4580390B2 (ja) 2003-08-21 2004-07-29 ハードウェア／ソフトウェアインターフェイスシステムによって管理可能な情報単位の拡張および継承のためのシステムおよび方法
MXPA05006260A MXPA05006260A (es) 2003-08-21 2004-07-29 Sistemas y metodos para extensiones y herencia para unidades de informacion manejables a traves de un sistema de interfaz de sistemas de componentes fisicos de computacion y programas y sistemas de programacion.
PCT/US2004/024569 WO2005024666A2 (en) 2003-08-21 2004-07-29 Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
KR1020057012324A KR101109399B1 (ko) 2003-08-21 2004-07-29 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한정보 단위들에 대한 동기화 스키마들의 구현을 위한시스템들 및 방법들
PCT/US2004/024287 WO2005024626A1 (en) 2003-08-21 2004-07-29 Systems for the implementation of a synchronization schemas
EP04779583A EP1604310A4 (en) 2003-08-21 2004-07-29 SYSTEM AND METHOD FOR EXTENSIONS AND INFORMATION UNITS MANAGABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM
KR1020057009283A KR20060113353A (ko) 2003-08-21 2004-07-29 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한 정보 단위들을 조직하기 위한 디지털 이미지스키마의 구현을 위한 시스템 및 방법
CN2004800023968A CN1739093B (zh) 2003-08-21 2004-07-29 同步模式的实现系统
CA2815867A CA2815867C (en) 2003-08-21 2004-07-29 Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
AU2004271531A AU2004271531B2 (en) 2003-08-21 2004-07-29 Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
PCT/US2004/024437 WO2005024550A2 (en) 2003-08-21 2004-07-29 System and method for implementation of a digital image schema in a hardware/software interface
RU2005119974/07A RU2412475C2 (ru) 2003-08-21 2004-07-29 Системы и способы расширений и наследования для блоков информации, управляемых системой аппаратно-программного интерфейса
EP04757348A EP1573508A4 (en) 2003-08-21 2004-07-29 SYSTEMS FOR IMPLEMENTING SYNCHRONIZATION LOGIC
JP2006523867A JP4901472B2 (ja) 2003-08-21 2004-07-29 ハードウェア／ソフトウェア・インターフェース・システムにより管理可能な情報の単位を編成するデジタル・イメージ・スキーマの実装のためのシステムおよび方法
KR1020057012318A KR101022936B1 (ko) 2003-08-21 2004-07-29 하드웨어/소프트웨어 인터페이스 시스템에 의해 관리가능한정보 단위들에 대한 확장 및 상속을 위한 시스템 및 방법
BR0406512-3A BRPI0406512A (pt) 2003-08-21 2004-07-29 Sistemas e métodos para extensões e herança para unidades de informação gerenciáveis por um sistema de interface de hardware/software
JP2006523856A JP4583375B2 (ja) 2003-08-21 2004-07-29 同期スキーマの実装のためのシステム
CA2815562A CA2815562C (en) 2003-08-21 2004-07-29 Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
CN2004800015016A CN101416153B (zh) 2003-08-21 2004-07-29 实现组织可由硬件/软件接口系统管理的信息单元的数字图象模式的系统和方法
EP04779482A EP1620781A4 (en) 2003-08-21 2004-07-29 SYSTEMS AND METHODS FOR IMPLEMENTING A DIAGRAM OF DIGITAL IMAGES FOR THE ORGANIZATION OF INFORMATION UNITS MAY BE MANAGED BY A MATERIAL / SOFTWARE INTERFACE SYSTEM
CN200480001833.4A CN1871598B (zh) 2003-08-21 2004-07-29 用于可由硬件/软件接口系统管理的信息单元的扩展和继承的系统和方法
NO20052052A NO20052052L (no) 2003-08-21 2005-04-26 Systemer og fremgangsmater for utvidelser og videreforing av informasjonsenheter organiserbar med et grensesnittsystem av maskin-/programvare
IL168666A IL168666A (en) 2003-08-21 2005-05-18 Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2003/026144 WO2005029313A1 (en) 2003-08-21 2003-08-21 Systems and methods for data modeling in an item-based storage platform

Publications (1)

Publication Number Publication Date
WO2005029313A1 true WO2005029313A1 (en) 2005-03-31

Family

ID=34374761

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/026144 WO2005029313A1 (en) 2003-08-21 2003-08-21 Systems and methods for data modeling in an item-based storage platform

Country Status (9)

Country Link
EP (1) EP1658555A4 (ja)
JP (1) JP4394643B2 (ja)
KR (1) KR101024730B1 (ja)
CN (1) CN100570549C (ja)
AU (1) AU2003259959B2 (ja)
BR (1) BR0318469A (ja)
CA (1) CA2533088C (ja)
MX (1) MXPA06001986A (ja)
WO (1) WO2005029313A1 (ja)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7748032B2 (en) 2004-09-30 2010-06-29 Citrix Systems, Inc. Method and apparatus for associating tickets in a ticket hierarchy
US7779034B2 (en) 2005-10-07 2010-08-17 Citrix Systems, Inc. Method and system for accessing a remote file in a directory structure associated with an application program executing locally
US7853678B2 (en) 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring flow control of policy expressions
US7853679B2 (en) 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring handling of undefined policy events
US7865589B2 (en) 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing structured policy expressions to represent unstructured data in a network appliance
US7870153B2 (en) 2006-01-24 2011-01-11 Citrix Systems, Inc. Methods and systems for executing, by a virtual machine, an application program requested by a client machine
US8024568B2 (en) 2005-01-28 2011-09-20 Citrix Systems, Inc. Method and system for verification of an endpoint security scan
US8042120B2 (en) 2004-09-30 2011-10-18 Citrix Systems, Inc. Method and apparatus for moving processes between isolation environments
US8078627B2 (en) 2006-10-16 2011-12-13 Canon Kabushiki Kaisha File management apparatus, method for controlling file management apparatus, computer program, and storage medium
US8090797B2 (en) 2009-05-02 2012-01-03 Citrix Systems, Inc. Methods and systems for launching applications into existing isolation environments
US8095940B2 (en) 2005-09-19 2012-01-10 Citrix Systems, Inc. Method and system for locating and accessing resources
US8131825B2 (en) 2005-10-07 2012-03-06 Citrix Systems, Inc. Method and a system for responding locally to requests for file metadata associated with files stored remotely
US8171483B2 (en) 2007-10-20 2012-05-01 Citrix Systems, Inc. Method and system for communicating between isolation environments
US8171479B2 (en) 2004-09-30 2012-05-01 Citrix Systems, Inc. Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers
US8341287B2 (en) 2007-03-12 2012-12-25 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US8352606B2 (en) 2004-09-30 2013-01-08 Citrix Systems, Inc. Method and system for assigning access control levels in providing access to networked content files
WO2013096887A1 (en) * 2011-12-23 2013-06-27 Amiato, Inc. Scalable analysis platform for semi-structured data
US8533846B2 (en) 2006-11-08 2013-09-10 Citrix Systems, Inc. Method and system for dynamically associating access rights with a resource
US8838630B2 (en) 2006-06-30 2014-09-16 Citrix Systems, Inc. Method and systems for efficient delivery of previously stored content
US8943304B2 (en) 2006-08-03 2015-01-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US9160768B2 (en) 2007-03-12 2015-10-13 Citrix Systems, Inc. Systems and methods for managing application security profiles
US9401906B2 (en) 2004-09-30 2016-07-26 Citrix Systems, Inc. Method and apparatus for providing authorized remote access to application sessions
US9407608B2 (en) 2005-05-26 2016-08-02 Citrix Systems, Inc. Systems and methods for enhanced client side policy
US9621666B2 (en) 2005-05-26 2017-04-11 Citrix Systems, Inc. Systems and methods for enhanced delta compression
US9692725B2 (en) 2005-05-26 2017-06-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
RU2721999C1 (ru) * 2019-03-18 2020-05-25 Сергей Александрович Гайдамаков Ассоциативная сеть контактов, заметок и/или событий
CN113448584A (zh) * 2020-03-25 2021-09-28 武汉斗鱼网络科技有限公司 一种app版本管理方法、装置、介质及计算机设备

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102567315A (zh) * 2010-12-08 2012-07-11 金蝶软件（中国）有限公司 一种数据查询方法、装置及系统
CN102968685A (zh) * 2012-10-26 2013-03-13 广东电子工业研究院有限公司 一种帐户信息资产管理系统及其方法
KR102053709B1 (ko) * 2014-11-10 2019-12-09 한국전자통신연구원 편집형 영상객체 표현 방법 및 장치
CN109271490A (zh) * 2018-11-01 2019-01-25 中企动力科技股份有限公司 动态字段的分类方法和系统
US11301498B2 (en) * 2019-08-08 2022-04-12 Sap Portals Israel Ltd. Multi-cloud object store access
WO2023205035A1 (en) 2022-04-21 2023-10-26 Folder Front, LLC Intelligent folder-based data organization system
CN117150598B (zh) * 2023-09-05 2024-04-02 上海易立德信息技术股份有限公司 一种cad模型构建的族表管理与集成方法和系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5900870A (en) * 1989-06-30 1999-05-04 Massachusetts Institute Of Technology Object-oriented computer user interface
US5899996A (en) 1988-04-25 1999-05-04 Hewlett-Packard Company Method for copying linked data objects with selective copying of children objects
US6108004A (en) * 1997-10-21 2000-08-22 International Business Machines Corporation GUI guide for data mining
US6112024A (en) * 1996-10-02 2000-08-29 Sybase, Inc. Development system providing methods for managing different versions of objects with a meta model
US6370541B1 (en) * 1999-09-21 2002-04-09 International Business Machines Corporation Design and implementation of a client/server framework for federated multi-search and update across heterogeneous datastores
US6556983B1 (en) * 2000-01-12 2003-04-29 Microsoft Corporation Methods and apparatus for finding semantic information, such as usage logs, similar to a query using a pattern lattice data space
US6578046B2 (en) * 1998-04-01 2003-06-10 International Business Machines Corporation Federated searches of heterogeneous datastores using a federated datastore object

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5504892A (en) * 1994-09-08 1996-04-02 Taligent, Inc. Extensible object-oriented file system
US5915253A (en) * 1996-12-13 1999-06-22 Novell, Inc. Method and system for implementing objects in a storage system
US6324533B1 (en) 1998-05-29 2001-11-27 International Business Machines Corporation Integrated database and data-mining system
US6704743B1 (en) * 1999-09-13 2004-03-09 Copernus, Inc. Selective inheritance of object parameters in object-oriented computer environment
JP3983961B2 (ja) * 2000-07-18 2007-09-26 株式会社東芝 ディレクトリ情報管理装置及びプログラムを記録したコンピュータ読み取り可能な記録媒体
GB2371884A (en) * 2000-10-12 2002-08-07 Abb Ab Queries in an object-oriented computer system
CN1591406A (zh) * 2001-11-09 2005-03-09 无锡永中科技有限公司 集成多应用数据处理系统

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5899996A (en) 1988-04-25 1999-05-04 Hewlett-Packard Company Method for copying linked data objects with selective copying of children objects
US5900870A (en) * 1989-06-30 1999-05-04 Massachusetts Institute Of Technology Object-oriented computer user interface
US6112024A (en) * 1996-10-02 2000-08-29 Sybase, Inc. Development system providing methods for managing different versions of objects with a meta model
US6108004A (en) * 1997-10-21 2000-08-22 International Business Machines Corporation GUI guide for data mining
US6578046B2 (en) * 1998-04-01 2003-06-10 International Business Machines Corporation Federated searches of heterogeneous datastores using a federated datastore object
US6370541B1 (en) * 1999-09-21 2002-04-09 International Business Machines Corporation Design and implementation of a client/server framework for federated multi-search and update across heterogeneous datastores
US6556983B1 (en) * 2000-01-12 2003-04-29 Microsoft Corporation Methods and apparatus for finding semantic information, such as usage logs, similar to a query using a pattern lattice data space

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1658555A4 *

Cited By (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8042120B2 (en) 2004-09-30 2011-10-18 Citrix Systems, Inc. Method and apparatus for moving processes between isolation environments
US8352606B2 (en) 2004-09-30 2013-01-08 Citrix Systems, Inc. Method and system for assigning access control levels in providing access to networked content files
US8352964B2 (en) 2004-09-30 2013-01-08 Citrix Systems, Inc. Method and apparatus for moving processes between isolation environments
US9401906B2 (en) 2004-09-30 2016-07-26 Citrix Systems, Inc. Method and apparatus for providing authorized remote access to application sessions
US7748032B2 (en) 2004-09-30 2010-06-29 Citrix Systems, Inc. Method and apparatus for associating tickets in a ticket hierarchy
US9311502B2 (en) 2004-09-30 2016-04-12 Citrix Systems, Inc. Method and system for assigning access control levels in providing access to networked content files
US8171479B2 (en) 2004-09-30 2012-05-01 Citrix Systems, Inc. Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers
US8302101B2 (en) 2004-09-30 2012-10-30 Citrix Systems, Inc. Methods and systems for accessing, by application programs, resources provided by an operating system
US8286230B2 (en) 2004-09-30 2012-10-09 Citrix Systems, Inc. Method and apparatus for associating tickets in a ticket hierarchy
US8132176B2 (en) 2004-09-30 2012-03-06 Citrix Systems, Inc. Method for accessing, by application programs, resources residing inside an application isolation scope
US8024568B2 (en) 2005-01-28 2011-09-20 Citrix Systems, Inc. Method and system for verification of an endpoint security scan
US8312261B2 (en) 2005-01-28 2012-11-13 Citrix Systems, Inc. Method and system for verification of an endpoint security scan
US9621666B2 (en) 2005-05-26 2017-04-11 Citrix Systems, Inc. Systems and methods for enhanced delta compression
US9407608B2 (en) 2005-05-26 2016-08-02 Citrix Systems, Inc. Systems and methods for enhanced client side policy
US9692725B2 (en) 2005-05-26 2017-06-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US8095940B2 (en) 2005-09-19 2012-01-10 Citrix Systems, Inc. Method and system for locating and accessing resources
US7779034B2 (en) 2005-10-07 2010-08-17 Citrix Systems, Inc. Method and system for accessing a remote file in a directory structure associated with an application program executing locally
US8131825B2 (en) 2005-10-07 2012-03-06 Citrix Systems, Inc. Method and a system for responding locally to requests for file metadata associated with files stored remotely
US7949677B2 (en) 2006-01-24 2011-05-24 Citrix Systems, Inc. Methods and systems for providing authorized remote access to a computing environment provided by a virtual machine
US8051180B2 (en) 2006-01-24 2011-11-01 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine executing in a terminal services session and hosting a requested computing environment
US8010679B2 (en) 2006-01-24 2011-08-30 Citrix Systems, Inc. Methods and systems for providing access to a computing environment provided by a virtual machine executing in a hypervisor executing in a terminal services session
US7954150B2 (en) 2006-01-24 2011-05-31 Citrix Systems, Inc. Methods and systems for assigning access control levels in providing access to resources via virtual machines
US8117314B2 (en) 2006-01-24 2012-02-14 Citrix Systems, Inc. Methods and systems for providing remote access to a computing environment provided by a virtual machine
US7870153B2 (en) 2006-01-24 2011-01-11 Citrix Systems, Inc. Methods and systems for executing, by a virtual machine, an application program requested by a client machine
US8341732B2 (en) 2006-01-24 2012-12-25 Citrix Systems, Inc. Methods and systems for selecting a method for execution, by a virtual machine, of an application program
US8341270B2 (en) 2006-01-24 2012-12-25 Citrix Systems, Inc. Methods and systems for providing access to a computing environment
US8355407B2 (en) 2006-01-24 2013-01-15 Citrix Systems, Inc. Methods and systems for interacting, via a hypermedium page, with a virtual machine executing in a terminal services session
US8838630B2 (en) 2006-06-30 2014-09-16 Citrix Systems, Inc. Method and systems for efficient delivery of previously stored content
US8943304B2 (en) 2006-08-03 2015-01-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US9948608B2 (en) 2006-08-03 2018-04-17 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US8078627B2 (en) 2006-10-16 2011-12-13 Canon Kabushiki Kaisha File management apparatus, method for controlling file management apparatus, computer program, and storage medium
US9401931B2 (en) 2006-11-08 2016-07-26 Citrix Systems, Inc. Method and system for dynamically associating access rights with a resource
US8533846B2 (en) 2006-11-08 2013-09-10 Citrix Systems, Inc. Method and system for dynamically associating access rights with a resource
US8631147B2 (en) 2007-03-12 2014-01-14 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US7853678B2 (en) 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring flow control of policy expressions
US7853679B2 (en) 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring handling of undefined policy events
US8341287B2 (en) 2007-03-12 2012-12-25 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US7865589B2 (en) 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing structured policy expressions to represent unstructured data in a network appliance
US9450837B2 (en) 2007-03-12 2016-09-20 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US9160768B2 (en) 2007-03-12 2015-10-13 Citrix Systems, Inc. Systems and methods for managing application security profiles
US9009721B2 (en) 2007-10-20 2015-04-14 Citrix Systems, Inc. Method and system for communicating between isolation environments
US8171483B2 (en) 2007-10-20 2012-05-01 Citrix Systems, Inc. Method and system for communicating between isolation environments
US9021494B2 (en) 2007-10-20 2015-04-28 Citrix Systems, Inc. Method and system for communicating between isolation environments
US9009720B2 (en) 2007-10-20 2015-04-14 Citrix Systems, Inc. Method and system for communicating between isolation environments
US8326943B2 (en) 2009-05-02 2012-12-04 Citrix Systems, Inc. Methods and systems for launching applications into existing isolation environments
US8090797B2 (en) 2009-05-02 2012-01-03 Citrix Systems, Inc. Methods and systems for launching applications into existing isolation environments
WO2013096887A1 (en) * 2011-12-23 2013-06-27 Amiato, Inc. Scalable analysis platform for semi-structured data
US8732213B2 (en) 2011-12-23 2014-05-20 Amiato, Inc. Scalable analysis platform for semi-structured data
US10095732B2 (en) 2011-12-23 2018-10-09 Amiato, Inc. Scalable analysis platform for semi-structured data
RU2721999C1 (ru) * 2019-03-18 2020-05-25 Сергей Александрович Гайдамаков Ассоциативная сеть контактов, заметок и/или событий
CN113448584A (zh) * 2020-03-25 2021-09-28 武汉斗鱼网络科技有限公司 一种app版本管理方法、装置、介质及计算机设备
CN113448584B (zh) * 2020-03-25 2023-07-21 浙江满趣科技有限公司 一种app版本管理方法、装置、介质及计算机设备

Also Published As

Publication number Publication date
MXPA06001986A (es) 2006-05-17
EP1658555A4 (en) 2009-05-06
BR0318469A (pt) 2006-09-12
AU2003259959A1 (en) 2005-04-11
AU2003259959A2 (en) 2005-04-11
AU2003259959B2 (en) 2010-02-18
KR20060080921A (ko) 2006-07-11
JP4394643B2 (ja) 2010-01-06
CN100570549C (zh) 2009-12-16
JP2007521532A (ja) 2007-08-02
CN1820245A (zh) 2006-08-16
KR101024730B1 (ko) 2011-03-25
CA2533088A1 (en) 2005-03-31
EP1658555A1 (en) 2006-05-24
CA2533088C (en) 2014-04-29

Similar Documents

Publication Publication Date Title
US7428546B2 (en) Systems and methods for data modeling in an item-based storage platform
US7483915B2 (en) Systems and method for representing relationships between units of information manageable by a hardware/software interface system
US8131739B2 (en) Systems and methods for interfacing application programs with an item-based storage platform
US7555497B2 (en) Systems and methods for separating units of information manageable by a hardware/software interface system from their physical organization
US7739316B2 (en) Systems and methods for the implementation of base schema for organizing units of information manageable by a hardware/software interface system
US7349913B2 (en) Storage platform for organizing, searching, and sharing data
US7529811B2 (en) 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
CA2533088C (en) Systems and methods for data modeling in an item-based storage platform
AU2003259961B2 (en) Systems and methods for interfacing application programs with an item-based storage platform
US20050055354A1 (en) Systems and methods for representing units of information manageable by a hardware/software interface system but independent of physical representation
JP4583377B2 (ja) ハードウェア／ソフトウェアインターフェースシステムにより管理可能な情報のユニットに対する関係および階層の同期サービスを実現するシステムおよび方法
JP4583376B2 (ja) ハードウェア／ソフトウェアインタフェースシステムにより管理可能な情報のユニットに対する同期処理サービスを実現するシステムおよび方法
JP4580389B2 (ja) 仲介ファイルシステム共有または仲介デバイスを介してコンピュータシステムを同期させるためのシステムおよび方法
JP4583375B2 (ja) 同期スキーマの実装のためのシステム
WO2005024666A2 (en) Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
JP4394644B2 (ja) データの編成、検索、および共有のためのストレージプラットフォーム
ZA200600644B (en) Systems and methods for interfacing application programs with an item-based storage platform

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 03826943.0

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PG PH PL RO RU SC SD SE SG SK SL SY TJ TM TR TT TZ UA UG UZ VC VN YU ZA

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR HU IE IT LU NL PT RO SE SI SK TR BF BJ CF CI CM GA GN GQ GW ML MR NE SN TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003818743

Country of ref document: EP

Ref document number: 2003259959

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2533088

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2006/00645

Country of ref document: ZA

Ref document number: 200600645

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 579/DELNP/2006

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: PA/a/2006/001986

Country of ref document: MX

Ref document number: 2006105208

Country of ref document: RU

WWE Wipo information: entry into national phase

Ref document number: 2005509096

Country of ref document: JP

Ref document number: 1020067003584

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2003818743

Country of ref document: EP

ENP Entry into the national phase

Ref document number: PI0318469

Country of ref document: BR