Системы и способы сопряжения прикладных программ с платформой хранения на основе статей

Системы и способы сопряжения прикладных программ с платформой хранения на основе статей

Иллюстрации

Показать все

Реферат

Перекрестная ссылка

Изобретение связано по тематике с изобретениями, раскрыми в следующих заявках общего присвоения: патентной заявке США № (еще не присвоенной) (Реестр поверенного № MSFT-1748), поданной одновременно с данной заявкой, под названием "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION"; патентной заявке США № (еще не присвоенной) (Реестр поверенного № MSFT-1749), поданной одновременно с данной заявкой, под названием "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION"; патентной заявке США № (еще не присвоенной) (Реестр поверенного № MSFT-1750), поданной одновременно с данной заявкой, под названием "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; патентной заявке США № (еще не присвоенной) (Реестр поверенного № MSFT-1751), поданной одновременно с данной заявкой, под названием "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"; патентной заявке США № (еще не присвоенной) (Реестр поверенного № MSFT-1752), поданной одновременно с данной заявкой, под названием "SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; патентной заявке США № (еще не присвоенной) (Реестр поверенного № MSFT-2734), поданной одновременно с данной заявкой, под названием "STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA"; и патентной заявке США № (еще не присвоенной) (Реестр поверенного № MSFT-2735), поданной одновременно с данной заявкой, под названием "SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM".

Область техники, к которой относится изобретение

Настоящее изобретение относится в целом к области хранения и извлечения информации и, в частности, к активной платформе хранения для организации, поиска и совместного использования различных типов данных в компьютерной системе.

Уровень техники

В течение последнего десятилетия наблюдался рост емкости индивидуального диска примерно на семьдесят процентов (70%) в год. Закон Мура точно предсказал существенный рост вычислительной мощности центральных процессоров (ЦП), произошедший за эти годы. Технологии проводной и беспроводной связи обеспечили большие возможности соединения и пропускную способность. При условии, что современные тенденции сохранятся, через несколько лет средний портативный компьютер будет иметь емкость хранения около одного терабайта (ТБ), и будет содержать миллионы файлов, и жесткие диски емкостью 500 гигабайт (ГБ) получат широкое распространение.

Потребители используют свои компьютеры, в основном, для связи и для организации личной информации, будь то данные в традиционном стиле личной информационной системы (PIM) или мультимедийные данные, например цифровая музыка или фотографии. Объем цифрового контента и возможность хранения необработанных байтов значительно возросли; однако доступные потребителям способы организации и унификации этих данных не получили адекватного развития. Специалисты в области информационных технологий тратят очень много времени на организацию и совместное использование информации и, согласно некоторым исследованиям, специалисты в области информационных технологий тратят 15-25% своего времени на непродуктивную деятельность, связанную с информацией. Согласно другим исследованиям типичный специалист в области информационных технологий тратит ежедневно около 2,5 часов на поиск информации.

Разработчики и департаменты по информационным технологиям (IT) тратят много времени и денег на построение своих собственных хранилищ данных для обычных абстракций хранения для представления личностей, мест, времен и событий. Это приводит не только к дублированию работы, но и к созданию островов общих данных без каких-либо механизмов общего поиска или совместного использования этих данных. Только представьте, сколько адресных книжек может сегодня существовать на компьютере, на котором установлена операционная система Microsoft Windows. Многие приложения, например клиенты электронной почты и персональные финансовые программы, поддерживают отдельные адресные книжки, и приложения в незначительной степени могут совместно пользоваться данными адресных книжек, которые по отдельности поддерживаются каждой такой программой. Следовательно, финансовая программа (наподобие Microsoft Money) не может совместно использовать адреса получателей денег с адресами, поддерживаемыми в папке контактов электронной почты (например, в Microsoft Outlook). Действительно, многие пользователи имеют несколько устройств, и было бы логично, если бы они синхронизировали свои личные данные между ними и по обширной совокупности дополнительных устройств, включая сотовые телефоны, для таких коммерческих услуг как MSN и AOL; тем не менее, для совместной работы с документами общего пользования в основном приходится присоединять документы к сообщениям электронной почты, т.е. действовать вручную и малоэффективно.

Одна из причин такого недостатка сотрудничества, свойственного традиционным подходам к организации информации в компьютерных системах, сводится к использованию систем на основе файлов, папок и директорий ("файловых систем") для организации совокупностей файлов в директорные иерархические структуры папок на основании абстракции физической организации среды хранения, используемой для хранения файлов. Операционная система Multics, разработанная в 60-х годах, впервые использовала файлы, папки и директории для манипулирования сохраняемыми единицами данных на уровне операционной системы. В частности, Multics использовала символические адреса в иерархии файлов (тем самым введя идею пути к файлу), где физические адреса файлов не были прозрачны для пользователя (приложений и конечных пользователей). Эта файловая система никаким образом не была связана с форматом файла для какого-либо отдельного файла, и отношения между файлами не рассматривались на уровне операционной системы (т.е. не относились к положению файла в иерархии). С появлением Multics сохраняемые данные стали организовывать в файлы, папки и директории на уровне операционной системы. Эти файлы, в общем случае, включают в себя саму иерархию файлов («директорию»), воплощенную в особом файле, поддерживаемом файловой системой. Эта директория, в свою очередь, поддерживает список записей, соответствующих всем остальным файлам в директории и положению узла таких файлов в иерархии (именуемых здесь папками). Таким было состояние техники в течение приблизительно сорока лет.

Хотя файловая система обеспечивает разумное представление информации, размещенной в физической системе хранения компьютера, она, тем не менее, является абстракцией этой физической системы хранения, вследствие чего для использования файлов требуется уровень опосредования (интерпретации) между тем, чем манипулирует пользователь (единицы, имеющие контекст, признаки и отношения к другим единицам), и тем, что обеспечивает операционная система (файлами, папками и директориями). Поэтому пользователям (приложениям и/или конечным пользователям) ничего не остается, как вводить единицы информации в структуру файловой системы, даже если это неэффективно, неадекватно или нежелательно по какой-либо причине. Кроме того, существующим файловым системам мало что известно о структуре данных, хранящихся в отдельных файлах и, в результате, большая часть информации остается запертой в файлах, доступных (и понятных) только для приложений, которые их записали. Таким образом, недостаток схематического описания информации и механизмов манипулирования информацией приводит к созданию бункеров данных с очень малой возможностью совместного использования данных между отдельными бункерами. Например, многие пользователи персональных компьютеров (ПК) имеют более пяти различных хранилищ, в которых содержится информация о людях, с которыми они общаются на некотором уровне, например Outlook Contacts, адреса онлайнового эккаунта, Windows Address Book, Quicken Payees, и списки друзей службы мгновенного обмена сообщениями (IM), поскольку организация файлов представляет значительную трудность для этих пользователей ПК. Поскольку в большинстве существующих файловых систем используется модель вложенных папок для организации файлов и папок, по мере возрастания количества файлов, усилия, необходимые для поддержания гибкой и эффективной схемы организации, многократно возрастают. При этом было бы весьма полезно иметь несколько классификаций одного файла; однако использование жестких или мягких связей в существующих файловых системах весьма неудобно и трудно осуществимо.

Ранее было предпринято несколько неудачных попыток исправить недостатки файловых систем. Некоторые из этих предыдущих попыток предполагали использование контентно-адресуемой памяти для обеспечения механизма, позволяющего обращаться к данным по контенту, а не по физическому адресу. Однако эти усилия оказались безуспешными, поскольку, хотя контентно-адресуемая память оказалась полезной для маломасштабного использования такими устройствами, как блоки кэш-памяти и блоки управления памятью, крупномасштабное использование для таких устройств как физические среды хранения, все же было невозможно по ряду причин и, следовательно, такого решения просто не существует. Были предприняты попытки использовать системы объектно-ориентированной базы данных (OODB), но эти попытки, несмотря на сильные стороны базы данных и хорошие нефайловые представления, оказались неэффективными при обработке файловых представлений и не смогли сравниться по скорости, эффективности и простоте с иерархической структурой на основе папок на уровне системы программно-аппаратного интерфейса. Другие попытки, например попытки использовать SmallTalk (и другие производные), оказались весьма эффективными при обработке файловых и нефайловых представлений, но им не хватало признаков баз данных, необходимых, чтобы эффективно организовывать и использовать отношения, существующие между различными файлами данных, вследствие чего общая эффективность таких систем оказалась неприемлемой. Были попытки использовать BeOS (и другие подобные разработки операционных систем), которые оказались неадекватными при обработке нефайловых представлений - страдали теми же недостатками, что и традиционные файловые системы - несмотря на способность адекватно представлять файлы, обеспечивая в то же время некоторые необходимые признаки баз данных.

Технология баз данных - это другая область техники, в которой существуют сходные трудности. Например, хотя модель реляционной базы данных получила большой коммерческий успех, в действительности, независимые поставщики программного обеспечения (ISV) обычно используют незначительную часть функциональных возможностей программных продуктов реляционной базы банных (например, Microsoft SQL Server). Напротив, большинство приложений взаимодействует с таким продуктом посредством таких простых команд, как "gets" и "puts". Хотя для этого существует ряд очевидных причин, например недоверие к платформе или базе данных, одна ключевая причина, которая часто остается незамеченной, состоит в том, что база данных не всегда обеспечивает именно те абстракции, которые нужны большинству поставщиков коммерческих приложений. Например, тогда как реальный мир оперирует понятием «статей», например, «потребителей» или «порядками» (совместно с внедренными «строчными статьями» порядка в качестве статей в или их самих), реляционные базы данных оперируют только терминами таблиц и строк. Поэтому, в то время как приложению могут потребоваться аспекты согласованности, блокировки, безопасности и/или триггеров на уровне статей (и пр.), в общем случае базы данных обеспечивают эти признаки только на уровне таблиц/строк. Хотя это может хорошо работать, если каждая статья отображается в одну строку в некоторой таблице базы данных, в случае порядка с множественными строчными статьями, по той или иной причине статья в действительности отображается на множественные таблицы и, при этом, простая система реляционной базы данных не вполне обеспечивает правильные абстракции. Поэтому приложение должно построить логику над базой данных для обеспечения этих основных абстракций. Другими словами, основная реляционная модель не обеспечивает достаточной платформы для хранения данных, на которой можно легко разрабатывать приложения более высокого уровня, поскольку основная реляционная модель требует уровня опосредования между приложением и системой хранения, где семантическая структура данных может быть видна в приложении в определенных случаях. Хотя некоторые поставщики баз данных встраивают в свои продукты функциональные возможности более высокого уровня, например, обеспечивая реляционные возможности объектов, новые организационные модели и т.п., ни один из них до сих пор не обеспечил необходимого исчерпывающего решения, причем истинно исчерпывающее решение это то, которое обеспечивает как полезные абстракции модели данных (например, «статьи», «расширения», «отношения» и т.д.) для полезных абстракций домена (например, «личности», «места», «события» и т.д.).

Ввиду вышеуказанных недостатков существующих технологий хранения и баз данных необходима новая платформа хранения, обеспечивающая улучшенную способность к организации, поиску и совместному использованию всех типов данных в компьютерной системе - платформа хранения, которая расширяет платформу данных за пределы существующих файловых систем и систем баз данных и которая призвана быть хранилищем для всех типов данных. Настоящее изобретение удовлетворяет эту потребность.

Сущность изобретения

В нижеследующем разделе «сущность изобретения» предусмотрен обзор различных аспектов изобретения. Он не призван обеспечивать исчерпывающего описания всех важных аспектов изобретения, а также определять объем изобретения. Напротив, этот раздел служит введением в нижеследующие подробное описание и чертежи.

Настоящее изобретение относится к платформе хранения для организации, поиска и совместного использования данных. Платформа хранения согласно настоящему изобретению расширяет понятие хранения данных за пределы существующих файловых систем и систем баз данных и призвана быть хранилищем для всех типов данных, включая структурированные, неструктурированные или частично структурированные данные.

Согласно одному аспекту настоящего изобретения платформа хранения настоящего изобретения содержит хранилище данных, реализованное на машине базы данных. Согласно различным вариантам осуществления настоящего изобретения машина базы данных содержит машину реляционной базы данных с реляционными расширениями объекта. Хранилище данных реализует модель данных, которая поддерживает организацию, поиск, совместное использование, синхронизацию и защиту данных. Конкретные типы данных описаны в схемах, и платформа обеспечивает механизм для расширения множества схем для задания новых типов данных (в сущности подтипы основных типов обеспечиваются схемами). Возможность синхронизации способствует совместному использованию данных между пользователями или системами. Обеспечены возможности, аналогичные файловой системе, которые позволяют хранилищу данных взаимодействовать с существующими файловыми системами, но без ограничения такими традиционными файловыми системами. Механизм отслеживания изменений обеспечивает возможность отслеживать изменения в хранилище данных. Платформа хранения дополнительно содержит набор программных интерфейсов приложения, которые позволяют приложениям осуществлять доступ ко всем вышеупомянутым возможностям платформы хранения и доступ к данным, описанным в схемах.

Согласно другому аспекту изобретения модель данных, реализованная посредством хранилища данных, задает единицы хранения данных в терминах статей, элементов и отношений. Статья является единицей данных, сохраняемой в хранилище данных, и может содержать один или более элементов и отношений. Элемент - это экземпляр типа, содержащий одно или более полей (также именуемых здесь свойствами). Отношение - это связь между двумя статьями (используемые здесь эти и другие конкретные термины могут писаться с заглавной буквы, чтобы их можно было отличить от других терминов, используемых в непосредственной близости; однако нет никакого намерения делать различия между термином, написанным с заглавной буквы, например «Статья», и тем же термином, написанным со строчной буквы, например «статья», и никакие такие различия не предполагаются и не подразумеваются).

Согласно другому аспекту изобретения компьютерная система содержит совокупность Статей, причем каждая Статья содержит дискретную сохраняемую единицу информации, которой может манипулировать система программно-аппаратного интерфейса; совокупность Папок статей, которые образуют организационную структуру упомянутых Статей; и систему программно-аппаратного интерфейса для манипулирования совокупностью Статей, причем каждая Статья принадлежит, по меньшей мере, одной Папке статей и может принадлежать более, чем одной Папке статей.

Согласно другому аспекту изобретения компьютерная система содержит совокупность Статей, причем каждая Статья содержит дискретную сохраняемую единицу информации, которой может манипулировать система программно-аппаратного интерфейса, и Статья или некоторые из значений свойства Статьи вычисляются динамически, а не выводятся из постоянного хранилища. Другими словами, система программно-аппаратного интерфейса не требует сохранения Статьи, и поддерживаются определенные операции, например, способность перечислять текущее множество Статей или способность извлекать Статью по ее идентификатору (который более полно описан в разделах, где описан программный интерфейс приложения или API) платформы хранения - например, Статьей может быть текущее местоположение сотового телефона или температура, считанная датчиком температуры.

Согласно другому аспекту изобретения система программно-аппаратного интерфейса для компьютерной системы, причем упомянутая система программно-аппаратного интерфейса манипулирует совокупностью Статей, дополнительно содержит Статьи, связанные между собой совокупностью Отношений, которыми управляет система программно-аппаратного интерфейса. Согласно другому аспекту изобретения предоставляется система программно-аппаратного интерфейса для компьютерной системы, причем упомянутая система программно-аппаратного интерфейса манипулирует совокупностью дискретных единиц информации, имеющих свойства, понимаемые системой программно-аппаратного интерфейса. Согласно другому аспекту изобретения система программно-аппаратного интерфейса для компьютерной системы содержит схему ядра для задания множества Статей ядра, которые упомянутая система программно-аппаратного интерфейса понимает и может непосредственно обрабатывать в заранее определенном и предсказуемом порядке. Согласно другому аспекту изобретения раскрыт способ манипулирования совокупностью дискретных единиц информации («Статей») в системе программно-аппаратного интерфейса для компьютерной системы, причем способ содержит взаимосвязывание упомянутых Статей посредством совокупности Отношений и управление этими Отношениями на уровне системы программно-аппаратного интерфейса.

Согласно другому признаку изобретения API платформы хранения обеспечивает классы данных для каждой статьи, расширения статьи и отношения, заданных в множестве схем платформы хранения. Кроме того, программный интерфейс приложения обеспечивает множество классов структур, которые задают общее множество поведений для классов данных и которые, совместно с классами данных, обеспечивают основную модель программирования для API платформы хранения. Согласно другому признаку изобретения API платформы хранения обеспечивает упрощенную модель запроса, которая позволяет разработчикам прикладных программ формировать запросы на основании различных свойств статей в хранилище данных, при этом разработчик прикладной программы изолирован от подробностей языка запроса нижележащей машины базы данных. Согласно еще одному аспекту API платформы хранения согласно настоящему изобретению API собирает изменения в статье, внесенные прикладной программой, после чего организует их в правильные обновления, необходимые машине базы данных (или машине хранения любого вида), на которой реализовано хранилище данных. Это позволяет разработчикам прикладных программ производить изменения статьи в памяти, оставляя API сложные аспекты обновлений хранилища данных.

Благодаря своей общей основе хранения и схематизированным данным платформа хранения согласно настоящему изобретению позволяет более эффективно разрабатывать приложение для потребителей, специалистов в области информационных технологий и предприятий. Она обеспечивает богатый и расширяемый программный интерфейс приложения, который не только делает доступными возможности, свойственные этой модели данных, но также охватывает и расширяет существующие файловую систему и методы доступа к базе данных.

Другие признаки и преимущества изобретения следуют из нижеследующего подробного описания изобретения и прилагаемых чертежей.

Краткое описание чертежей

Вышеизложенную сущность изобретения, а также нижеследующее подробное описание изобретения можно лучше понять совместно с прилагаемыми чертежами. В целях иллюстрации изобретения на чертежах показаны иллюстративные варианты осуществления различных аспектов изобретения; однако изобретение не ограничивается раскрытыми конкретными способами и инструментариями. На чертежах:

фиг.1 - блок-схема компьютерной системы, в которую можно включить аспекты настоящего изобретения;

фиг.2 - блок-схема компьютерной системы, разделенной на три компонента: аппаратный компонент, компонент системы программно-аппаратного интерфейса и компонент прикладных программ;

фиг.2А - традиционная древовидная иерархическая структура файлов, сгруппированных в папки в директории в операционной системе на основе файлов;

фиг.3 - блок-схема платформы хранения согласно настоящему изобретению;

фиг.4 - структурное соотношение между Статьями, Папками статей и Категориями согласно различным вариантам осуществления настоящего изобретения;

фиг.5А - блок-схема структуры Статьи;

фиг.5В - блок-схема сложных типов свойств Статьи, показанной на фиг.5А;

фиг.5С - блок-схема Статьи «положение», в которой дополнительно описаны ее сложные типы (перечисленные в явном виде);

фиг.6А - иллюстрирует Статью как подтип Статья в Базовой схеме;

фиг.6В - блок-схема подтипа Статья, показанного в фиг.6А, в которой в явном виде перечислены его собственные типы (помимо его прямых свойств);

фиг.7 - блок-схема Базовой схемы, включающей в себя два ее типа классов верхнего уровня, Item и PropertyBase, и выведенные из них дополнительные типы Базовой схемы;

фиг.8А - блок-схема, иллюстрирующая Статьи в Схеме ядра;

фиг.8В - блок-схема, иллюстрирующая типы свойств в Схеме ядра;

фиг.9 - блок-схема, иллюстрирующая Папку статей, входящие в нее статьи и отношения взаимосвязи между Папкой статей и входящими в нее статьями;

фиг.10 - блок-схема, иллюстрирующая Категорию (которая, в свою очередь, сама является статьей), входящие в нее статьи и отношения взаимосвязи между Категорией и входящими в нее статьями;

фиг.11 - диаграмма, иллюстрирующая иерархию типов ссылки модели данных платформы хранения, согласно настоящему изобретению;

фиг.12 - диаграмма, иллюстрирующая, как классифицирующая отношения, согласно варианту осуществления настоящего изобретения;

фиг.13 - диаграмма, иллюстрирующая механизм извещения, согласно варианту осуществления настоящего изобретения;

фиг.14 - диаграмма, иллюстрирующая пример, в котором две транзакции вставляют новую запись в одно и то же бинарное дерево;

фиг.15 - иллюстрирует процесс обнаружения изменения данных согласно варианту осуществления настоящего изобретения;

фиг.16 - пример дерева директории;

фиг.17 - пример, в котором существующая папка файловой системы на основе директории перемещается в хранилище данных платформы хранения согласно аспекту настоящего изобретения;

фиг.18 - иллюстрирует понятие Папок включения согласно варианту осуществления настоящего изобретения;

фиг.19 - иллюстрирует основную архитектуру API платформы хранения;

фиг.20 - схематически представляет различные компоненты стека API платформы хранения;

фиг.21A и 21B - графическое представление иллюстративной Схемы контактов (Статей и Элементов);

фиг.22 - структура среды выполнения API платформы хранения согласно аспекту настоящего изобретения;

фиг.23 - иллюстрирует выполнение операции FindAll согласно варианту осуществления настоящего изобретения;

фиг.24 - иллюстрирует процесс генерации классов API платформы хранения из схемы платформы хранения согласно аспекту настоящего изобретения;

фиг.25 - схема, на которой основана File API, согласно другому аспекту настоящего изобретения;

фиг.26 - диаграмма формата маски доступа, используемой в целях защиты данных, согласно варианту осуществления настоящего изобретения;

фиг.27 (a), (b), и (c) - изображают новые одинаково защищенные области безопасности, вырезанные из существующей области безопасности, согласно варианту осуществления одного аспекта настоящего изобретения;

фиг.28 - диаграмма, иллюстрирующая понятие вида поиска Статьи, согласно варианту осуществления одного аспекта настоящего изобретения;

фиг.29 - диаграмма иллюстративной иерархии статей согласно варианту осуществления настоящего изобретения.Подробное описание изобретения

Содержание

I. Введение

А. Иллюстративная вычислительная среда

В. Традиционное хранение на основе файлов

II. НОВАЯ ПЛАТФОРМА ХРАНЕНИЯ ДЛЯ ОРГАНИЗАЦИИ, ПОИСКА И СОВМЕСТНОГО ИСПОЛЬЗОВАНИЯ ДАННЫХ

А. Глоссарий

В. Обзор платформы хранения

С. МОДЕЛЬ ДАННЫХ

1. Статьи

2. Идентификация статьи

а) Ссылки на статью

(1) ItemIDReference

(2) ItemPathReference

b) Иерархия типов ссылки

3. Папки статей и Категории

4. Схемы

a) Базовая схема

b) Схема ядра

5. Отношения

a) Декларация отношения

b) Отношение поддержки

с) Отношения внедрения

е) Правила и ограничения

f) Упорядочение отношений

6. Расширяемость

a) Расширения статьи

b) Расширение типов вложенных элементов

D. МАШИНА БАЗЫ ДАННЫХ

1. Реализация хранилища данных с использованием UDT

2. Отображение статей

3. Отображение расширений

4. Отображение вложенных элементов

5. Идентификация объекта

6. Именование объектов SQL

7. Именование столбцов

8. Виды поиска

а) Статья

(1) Главный вид поиска статьи

(2) Типизированные виды поиска статьи

b) Расширения статьи

(1) Главный вид поиска расширения

(2) Типизированные виды поиска расширения

c) Вложенные элементы

d) Отношения

(1) Главный вид поиска отношения

(2) Виды поиска экземпляра отношения

9. Обновления

10. Отслеживание изменений и надгробия

а) Отслеживание изменений

(1) Отслеживание изменений в «главных» видах поиска

(2) Отслеживание изменений в «типизированных» видах поиска

b) Надгробия

(1) Надгробия статей

(2) Надгробия расширений

(3) Надгробия отношений

(4) Очистка надгробий

11. API и функции помощника

а) Функция [System.Storage].GetItem

b) Функция [System.Storage].GetExtension

с) Функция [System.Storage].GetRelationship

12. Метаданные

а) Метаданные схемы

b) Метаданные экземпляра

Е. Безопасность

1. Обзор

2. Подробное описание модели безопасности

a) Структура описателя безопасности

(1) Формат маски доступа

(2) Общие права доступа

(3) Стандартные права доступа

b) Права, зависящие от статьи

(1) Права, зависящие от объекта «файл» и «директория»

(2) WinFSItemRead

(3) WinFSItemReadAttributes

(4) WinFSItemWriteAttributes

(5) WinFSItemWrite

(6) WinFSItemAddLink

(7) WinFSItemDeleteLink

(8) Права на удаление статьи

(9) Права на копирование статьи

(10) Права на перемещение статьи

(11) Права на просмотр политики безопасности на статье

(12) Права на изменение политики безопасности на статье

(13) Права, не имеющие прямого эквивалента

3. Реализация

а) Создание новой статьи в контейнере

b) Добавление к статье явного ACL

с) Добавление к статье отношения поддержки

d) Удаление отношения поддержки из статьи

е) Удаление явного ACL из статьи

f) Изменение ACL, связанного со статьей

F. Извещения и отслеживание изменений

1. Сохранение событий изменения

а) События

b) Наблюдатели

2. Механизм отслеживания изменений и генерации извещений

а) Отслеживание изменений

b) Управление метками времени

с) Обнаружение изменения данных - обнаружение событий

G. Синхронизация

1. Синхронизация между платформами хранения

а) Приложения управления синхронизацией

b) Аннотация схемы

с) Конфигурация синхронизации

(1) Папка сообщества - отображения

(2) Профили

(3) Расписания

d) Обработка конфликтов

(1) Обнаружение конфликта

(а) Конфликты на основе знания

(b) Конфликты на основе ограничений

(2) Обработка конфликтов

(а) Автоматическое разрешение конфликтов

(b) Регистрация конфликтов

(с) Инспектирование и разрешения конфликтов

(d) Сходимость копий и распространение разрешений конфликтов

2. Синхронизация с хранилищами данных, не связанными с платформой хранения

а) Службы синхронизации

(1) Перечисление изменений

(2) Применение изменений

(3) Разрешение конфликтов

b) Реализация адаптера

3. Безопасность

4. Управляемость

Н. Возможность взаимодействия с традиционными файловыми системами

1. Модель возможности взаимодействия

2. Особенности хранилища данных

а) Не том

b) Структура хранилища

с) Не все файлы мигрируют

d) Доступ из пространства имен NTFS к файлам платформы хранения

е) Ожидаемые буквы пространства имен/привода

I. API ПЛАТФОРМЫ ХРАНЕНИЯ

1. Обзор

2. Именование и области действия

3. Компоненты API платформы хранения

4. Классы данных

5. Структура среды выполнения

а) Классы структуры среды выполнения

(1) ItemContext

(2) ItemSearcher

(a) Целевой тип

(b) Фильтры

(с) Подготовка поисков

(d) Опции Find

b) Структура среды выполнения в процессе работы

(1) Открытие и закрытие объектов ItemContext

(2) Поиск объектов

(а) Опции поиска

(b) FindOne и FindOnly

(с) Короткие вызовы поиска на ItemContext

(d) Нахождение по ИД или пути

(е) Шаблон GetSearcher

6. Безопасность

7. Поддержка отношений

а) Базовые типы отношений

(1) Класс Relationship

(2) Класс ItemReference

(3) Класс ItemIdReference

(4) Класс ItemPathReference

(5) Структура RelationshipId

(6) Класс VirtualRelationshipCollection

b) Сгенерированные типы отношений

(1) Сгенерированные типы отношений

(2) Класс RelationshipPrototype

(3) Класс RelationshipPrototypeCollection

c) Поддержка отношений в классе Item

(1) Класс Item

(2) Класс RelationshipCollection

d) Поддержка отношений в выражениях поиска

(1) Переход от статей к отношениям

(2) Переход от отношений к статьям

(3) Комбинирование обхода отношений

е) Примеры использования поддержки отношений

(1) Поиск отношений

(2) Навигация от отношения к исходной и целевой статьям

(3) Навигация от исходных статей к отношениям

(4) Создание отношений (и статей)

(5) Удаление отношений (и статей)

8. «Расширение» API платформы хранения

a) Поведения домена

b) Поведения добавления значений

с) Поведения добавления значения как поставщики услуг

9. Структура среды разработки

10. Формализм запросов

а) Основы фильтрации

b) Приведения типов

11. Удаленные операции

а) Локальная/удаленная прозрачность в API

b) Реализация удаленных операций в платформе хранения

с) Доступ к хранилищам, не относящимся к платформе хранения

d) Отношение к DFS

е) Отношение к GXA/Indigo

12. Ограничения

13. Совместное использование

а) Представление совместно используемого ресурса

b) Управление совместно используемыми ресурсами

с) Доступ к совместно используемым ресурсам

d) Обнаружимость

14. Семантика Find

15. API Contacts платформы хранения

а) Обзор System.Storage.Contact

b) Поведения домена

16. API File платформы хранения

а) Введение

(1) Отражение тома NTFS в платформе хранения

(2) Создание файлов и директорий в пространстве имен платформы хранения

b) Схема файлов

с) Обзор System.Storage.Files

d) Примеры кода

(1) Открытие файла и запись в него

(2) Использование запросов

e) Поведения домена

J. Заключение

I. Введение

Предмет настоящего изобретения описан конкретно, чтобы удовлетворять установленным требованиям. Однако само по себе описание не призвано ограничивать объем этого патента. Напротив, изобретатели предусматривают, что заявленный предмет можно воплощать и другими способами, включающими в себя другие этапы или сочетания этапов, аналогичных описанным в этом документе, совместно с другими современными или будущими технологиями. Кроме того, хотя термин «этап» можно использовать здесь в значении различных элементов применяемых способов, термин не следует интерпретировать как подразумевающий какой-либо конкретный порядок среди или между различными раскрытыми здесь этапами, если и пока порядок отдельных этапов не описан в явном виде.

А. Иллюстративная вычислительная среда

На компьютере могут выполняться многочисленные варианты осуществления настоящего изобретения. Фиг.1 и нижеследующее описание призваны обеспечивать краткое общее описание подходящей среды вычислительной системы, в которой можно реализовать изобретение. Хотя это не требуется, различные аспекты изобретения можно описать в общем контексте компьютерно-выполняемых команд, например, программных модулей, выполняемых компьютером, например, клиентской рабочей станцией или сервером. В общем случае, программные модули включают в себя процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют определенные задачи или реализуют определенные абстрактные типы данных. Кроме того, изобретение можно осуществлять на практике в других конфигурациях компьютерной системы, включая карманные устройства, многопроцессорные системы, микропроцессорную или программируемую бытовую электронику, сетевые ПК, миникомпьютеры, универсальные компьютеры, и т.п. Изобретение также можно применять на практике в распределенных вычислительных средах, где задачи выполняются удаленными устройствами обработки, связанными друг с другом посредством сети передачи данных. В распределенной вычислительной среде программные модули размещаются как на локальных, так и на удаленных компьютерных запоминающих устройствах.

Согласно фиг.1 иллюстративная вычислительная система общего назначения включает в себя традиционный персональный компьютер 20 и т.п., включающий в себя процессор 21, системную память 22 и системную шину 23, которая подключает различные компоненты системы, в том числе системную память, к процессору 21. Системная шина 23 может относиться к любому из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину с использованием различных шинных архитектур. Системная память включает постоянную память (ПЗУ) 24 и оперативную память (ОЗУ) 25. Базовая система ввода/вывода (BIOS) 26, содержащая основные процедуры, которые помогают переносить информацию между элементами компьютера, например, при запуске, обычно хранятся в ПЗУ 24. Персональный компьютер 20 также может включать в себя привод 27 жесткого диска, который считывает с или записывает на стационарный жесткий диск, который не показан, привод 28 магнитного диска, который считывает с или записывает на сменный магнитный диск 29, и привод 30 оптического диска, который считывает с или записывает на сменный оптический диск 31, например, CD-ROM или другой оптический носитель. Привод 27 жесткого диска, привод 28 магнитного диска и привод 30 оптического диска подключены к системной шине 23 посредством интерфейса 32 привода жесткого диска, интерфейса 33 привода магнитного диска и интерфейса 34 привода оптического диска, соответственно. Приводы и соответствующие компьютерно-считываемые среды обеспечивают энер