Патент на изобретение №2371757

(54) СИСТЕМЫ И СПОСОБЫ МОДЕЛИРОВАНИЯ ДАННЫХ В ОСНОВАННОЙ НА ПРЕДМЕТАХ ПЛАТФОРМЕ ХРАНЕНИЯ

(57) Реферат:

Изобретение относится к области хранения и извлечения информации и, в частности, к активной платформе хранения для организации, поиска и совместного использования различных типов данных в компьютеризованной системе. Изобретение позволяет создать новую платформу хранения данных, которая обеспечивает улучшенную возможность организации, поиска и совместного использования всех типов данных в компьютерной системе. Способ управления хранилищем данных заключается в организации хранилища данных, содержащего Предметы, Элементы и Связи. Предмет представляет собой единицу данных, хранимую в хранилище данных, и дополнительно содержит упомянутый Элемент и упомянутую Связь. Элемент представляет собой экземпляр типа, содержащего одно или несколько полей. Связь представляет собой связывание между по меньшей мере двумя Предметами. Хранилище данных дополнительно содержит Базовую Схему, которая устанавливает структуру для создания и организации каждого Предмета и устанавливает основополагающий набор свойств, и Основную Схему для определения набора основных типов, причем каждый тип характеризуется по меньшей мере в один основной тип, основанный на типе Предмета или подтипе Предмета. 3 н. и 11 з.п. ф-лы; 35 ил.

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

Настоящая заявка относится к предмету изобретений, описанному в следующих заявках с передачей права на совместное использование: заявка на патент США (еще не назначен) (реестр поверенного 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-2733), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM» (Системы и способы сопряжения программ приложения с основанной на предметах платформой хранения); и заявка на патент США (еще не назначен) (реестр поверенного MSFT-2734), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA» (Платформа хранения для организации, поиска и совместного использования данных).

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

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

Предшествующий уровень техники

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

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

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

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

Однако, хотя обеспечивая приемлемое представление информации, постоянно находящейся в физической системе хранения компьютера, файловая система, тем не менее, является абстракцией этой физической системы хранения, и поэтому использование файлов требует некоторого уровня косвенности (интерпретации) между тем, чем манипулирует пользователь (единицы, имеющие контекст, особенности и связи с другими единицами), и тем, что предоставляет операционная система (файлы, папки и каталоги). Следовательно, у пользователя (приложений и/или конечных пользователей) нет выбора, как загружать единицы информации в структуру файловой системы, даже когда это выполнение является неэффективным, несовместимым или иным образом нежелательным. Кроме того, у существующих файловых систем мало сведений о структуре данных, хранимых в индивидуальных файлах, и из-за этого большая часть информации остается заблокированной в файлах, к которым могут обращаться (и они могут быть понятны) только приложения, которые их записали. Следовательно, это отсутствие схематического описания информации и механизмов управления информацией приводит к созданию бункеров данных с малым совместным использованием данных между индивидуальными бункерами. Например, многие пользователи персональных компьютеров (ПК) имеют более пяти отдельных хранилищ, которые содержат информацию о людях, с которыми они взаимодействуют на некотором уровне, например контакты Outlook, получатели онлайновых счетов, адресная книга Windows, получатели платежа Quicken и списки контактных лиц мгновенного обмена сообщениями (МОС; 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С представляет собой блок-схему, иллюстрирующую Предмет «Location», в котором дополнительно описываются (явно перечисляются) его составные типы;

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

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

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

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

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

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

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

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

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

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

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

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

фиг.16 иллюстрирует примерное дерево каталогов;

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

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

фиг.19 иллюстрирует базовую архитектуру ИПП (API) платформы хранения;

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

фиг.21А и 21В представляют собой графические представления примерной схемы Контактов (Предметы и Элементы);

фиг.22 иллюстрирует интегрированную среду выполнения (runtime framework) ИПП (API) платформы хранения согласно аспекту настоящего изобретения;

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

фиг.24 иллюстрирует процесс, посредством которого классы ИПП (API) платформы хранения генерируются из Схемы платформы хранения согласно аспекту настоящего изобретения;

фиг.25 иллюстрирует схему, на которой основан ИПП (API) Файла согласно другому аспекту настоящего изобретения;

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

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

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

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

Подробное описание изобретения

СОДЕРЖАНИЕ

I. ВВЕДЕНИЕ

А. ПРИМЕРНАЯ ВЫЧИСЛИТЕЛЬНАЯ СРЕДА

В. ТРАДИЦИОННОЕ ОСНОВАННОЕ НА ФАЙЛАХ ХРАНЕНИЕ

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

А. СЛОВАРЬ

В. ОБЗОР ПЛАТФОРМЫ ХРАНЕНИЯ

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

1. Предметы

2. Идентификация предметов

а) Ссылки на предмет

(1) ItemIDReference

(2) ItemPathReference

b) Иерархия ссылочного типа

3. Папки и категории предметов

4. Схемы

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

b) Основная схема

5. Связи

а) Объявление связи

b) Связь прикрепления

с) Связи внедрения

d) Связи ссылки

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

f) Упорядочение связей

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

а) Расширения предмета

b) Расширения типов NestedElement

D. ПРОЦЕССОР БАЗЫ ДАННЫХ

1. Реализация хранилища данных, используя определяемые пользователем типы (ОПТ; UDT)

2. Отображение предметов

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

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

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

6. Именование объектов языка структурированных запросов (ЯСЗ; SQL)

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

8. Представления поиска

а) Предмет

(1) Главное представление поиска предметов

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

b) Расширения предметов

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

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

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

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. Метаданные

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

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

Е. ЗАЩИТА

1. Обзор

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

а) Структура дескриптора защиты

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

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

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

b) Характерные для предмета права

(1) Характерные для объекта права файла и каталога

(2) WinFSItemRead

(3) WinFSItemReadAttributes 86

(4) WinFSItemWriteAttribute

(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. Управляемость

H. ВОЗМОЖНОСТЬ ВЗАИМОДЕЙСТВИЯ С ТРАДИЦИОННЫМИ ФАЙЛОВЫМИ СИСТЕМАМИ

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

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

а) Не том

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

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

d) Доступ пространства имен файловой системы новой технологии (ФСНТ; NTFS) к файлам платформы хранения

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

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

1. Обзор

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

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

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

5. Интегрированная среда выполнения

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

(1) ItemContext

(2) ItemSearcher

(а) Тип цели

(b) Фильтры

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

(d) Варианты поиска

(3) Поток результатов предметов («FindResult»)

b) Интегрированная среда выполнения в работе

с) Общие шаблоны программирования

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

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

(а) Варианты поиска

(b) FindOne и FindOnly

(с) Краткие формы поиска по ItemContext

(d) Поиск по идентификатору (ИД; ID)) или пути

(е) Шаблон GetSearcher

(3) Обновление хранилища

6. Защита

7. Поддержка связей

а) Базовые типы связей

(1) Класс Relationship

(2) Класс ItemReference

(3) Класс ItemIdReference

(4) Класс ItemPathReference

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

(6) Класс VirtualRelationshipCollection

b) Генерируемые типы связей

(1) Генерируемые типы связей

(2) Класс RelationshipPrototype

(3) Класс RelationshipPrototypeCollection

с) Поддержка связей в классе Item

(1) Класс Item

(2) Класс RelationshipCollection

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

(1) Прохождение от предметов к связям

(2) Прохождение от связей к предметам

(3) Объединение прохождения связи

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

(1) Поиск связей

(2) Навигация от связи к предметам источника и цели

(3) Навигация от предметов источника к связям

(4) Создание связей (и предметов)

(5) Удаление связей (и предметов)

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

а) Методы поведения домена

b) Дополнительные методы поведения

с) Дополнительные методы поведения в качестве поставщиков служб

9. Интегрированная среда периода проектирования

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

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

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

с) Синтаксис фильтра

11. Удаленное взаимодействие

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

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

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

d) Связь с распределенной файловой системой (РФС; DFS)

е) Связь с глобальной архитектурой расширяемого языка разметки (ГАР; GXA)/Indigo

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

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

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

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

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

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

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

15. ИПП (API) контактов платформы хранения

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

b) Методы поведения доменов

16. ИПП (API) файла платформы хранения

а) Введение

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

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

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

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

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

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

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

е) Методы поведения доменов

J. ЗАКЛЮЧЕНИЕ

I. ВВЕДЕНИЕ

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

А. ПРИМЕРНАЯ ВЫЧИСЛИТЕЛЬНАЯ СРЕДА

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

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

Ряд программных модулей может храниться на жестком диске, магнитном диске 29, оптическом диске 31, в ПЗУ 24 или ОЗУ 25, включая операционную систему 35, одну или несколько программ 36 приложений, другие программные модули 37 и программные данные 38. Пользователь может вводить команды и информацию в персональный компьютер 20 при помощи устройств ввода, таких как клавиатура 40 и указательное устройство 42. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровой планшет, антенну спутниковой связи, сканер или т.п. Эти и другие устройства ввода часто соединяются с процессором 21 при помощи интерфейса 46 последовательного порта, который соединен с системной шиной, но могут соединяться при помощи других интерфейсов, таких как параллельный порт, игровой порт или универсальная последовательная шина (УПШ; USB). Монитор 47 или устройство отображения другого типа также подключается к системной шине 23 при помощи интерфейса, такого как видеоадаптер 48. В дополнение к монитору 47 персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показаны), такие как громкоговорители и принтеры. Примерная система по фиг.1 также включает в себя хост-адаптер 55, шину 56 интерфейса малых вычислительных систем (ИМВС; SCSI) и внешнее устройство 62 хранения, подключенное к шине 56 ИМВС (SCSI).

Персональный компьютер 20 может работать в сетевой среде, используя логические соединения с одним или несколькими удаленными компьютерами, такими как удаленный компьютер 49. Удаленным компьютером 49 может быть другой персональный компьютер, сервер, маршрутизатор, сетевой ПК, одноранговое устройство или другой общий узел сети, и он обычно включает в себя многие или все из элементов, описанных выше в отношении персонального компьютера 20, хотя на фиг.1 изображено только запоминающее устройство 50. Логические соединения, изображенные на фиг.1, включают в себя локальную сеть (ЛС; LAN) 51 и глобальную сеть (ГС; WAN) 52. Такие сетевые среды являются общепринятыми в офисах, компьютерных сетях масштаба предприятия, интрасетях и Интернете.

При использовании в сетевой среде ЛС (LAN) персональный компьютер 20 подключается к ЛС (LAN) 51 при помощи сетевого интерфейса или адаптера 53. При использовании в сетевой среде ГС (WAN) персональный компьютер 20 обычно включает в себя модем 54 или другое средство для установления связи по глобальной сети 52, такой как Интернет. Модем 54, который может быть внутренним или внешним, подключается к системной шине 23 при помощи интерфейса 46 последовательного порта. В сетевой среде программные модули, описанные выше в отношении персонального компьютера 20, или его частей, могут храниться в удаленном запоминающем устройстве. Понятно, что показанные сетевые подключения являются примерными, и может использоваться другое средство для установления линии связи между компьютерами.

Как изображено на блок-схеме фиг.2, компьютерная система 200 грубо может быть разделена на три группы компонентов: аппаратный компонент 202, компонент 204 аппаратной/программной интерфейсной системы и компонент 206 программ приложений (также упоминаемый как «пользовательский компонент» или «программный компонент» в некоторых контекстах данного описания).

В многочисленных вариантах осуществления компьютерной системы 200 и ссылаясь опять на фиг.1, аппаратный компонент 202 может содержать центральный процессор (ЦП; CPU) 21, память (как ПЗУ 24, так и ОЗУ 25), базовую систему 26 ввода-вывода (БСВВ; BIOS) и различные устройства ввода-вывода (ВВ; I/O), такие как клавиатура 40, мышь 42, монитор 47 и/или принтер (не показан), между прочим. Аппаратный компонент 202 содержит базовую физическую инфраструктуру для компьютерной системы 200.

Компонент 206 программ приложений содержит различные программы программного обеспечения, но не ограничивается компиляторами, системами баз данных, текстовыми редакторами, программами для бизнеса, видеоиграми и т.п. Программы приложений обеспечивают средство, посредством которого ресурсы компьютера используются для решения проблем, предоставления решений и обработки данных для различных пользователей (машин, других компьютерных систем и/или конечных пользователей).

Компонент 204 аппаратной/программной интерфейсной системы содержит (и в некоторых вариантах осуществления может состоять исключительно из) операционную систему, которая сама содержит, в большинстве случаев, оболочку и ядро. «Операционная система» (ОС; OS) представляет собой специальную программу, которая служит в качестве посредника между программами приложений и аппаратными средствами компьютера. Компонент 204 аппаратной/программной интерфейсной системы также может содержать диспетчер виртуальных машин (ДВМ; VMM), общеязыковую среду выполнения (ОЯСВ; CLR)) или ее функциональный эквивалент, виртуальную Java-машину (ВJМ; JVM) или ее функциональный эквивалент, или другие такие программные компоненты вместо или в дополнение к операционной системе в компьютерной системе. Назначением аппаратной/программной интерфейсной системы является предоставление среды, в которой пользователь может выполнять программы приложений. Цель любой аппаратной/программной интерфейсной системы заключается в том, чтобы сделать компьютерную систему удобной для использования, а также использовать аппаратные средства компьютера эффективным образом.

Аппаратная/программная интерфейсная система обычно загружается в компьютерную систему при запуске и после этого управляет всеми программами приложений в компьютерной системе. Программы приложений взаимодействуют с аппаратной/программной интерфейсной системой посредством запрашивания служб при помощи интерфейса прикладного программирования (ИПП; API). Некоторые программы приложений предоставляют возможность конечным пользователям взаимодействовать с аппаратной/программной интерфейсной системой при помощи пользовательского интерфейса, такого как командный язык или графический пользовательский интерфейс (ГПИ; GUI).

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

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

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

В. ТРАДИЦИОННОЕ ОСНОВАННОЕ НА ФАЙЛАХ ХРАНЕНИЕ

В большинстве компьютерных систем в настоящее время «файлы» представляют собой единицы хранимой информации, которые могут включать в себя аппаратную/программную интерфейсную систему, а также программы приложений, наборы данных и т.п. Во всех современных аппаратных/программных интерфейсных системах (Windows, Unix, Linux, Mac OS, системах виртуальных машин и т.п.) файлы представляют собой базовые дискретные (хранимые и извлекаемые) единицы информации (например, данные, программы и т.п.), которыми может манипулировать аппаратная/программная интерфейсная система. Группы файлов обычно организуются в «папки». В Microsoft Windows, Macintosh OS и в других аппаратных/программных интерфейсных системах папка представляет собой совокупность файлов, которые могут извлекаться, перемещаться и иным образом подвергаться манипулированию в виде одиночных единиц информации. Эти папки, в свою очередь, организуются в иерархическую структуру на основе дерева, называемую «каталогом» (более подробно описанным в данном документе ниже). В некоторых других аппаратных/программных интерфейсных системах, таких как DOS (дисковая операционная система), z/OS и большинство операционных систем на основе Unix, термины «каталог» и/или «папка» являются взаимозаменяемыми, и ранние компьютерные системы Apple (например, Apple IIe) использовали термин «каталог» (catalog) вместо каталога (directory); однако, как используется в данном описании, все эти термины, как считается, являются синонимами и взаимозаменяемыми и предназначены для того, чтобы дополнительно включать в себя все другие эквивалентные термины и для ссылок на иерархические структуры хранения информации и их компоненты папки и файлы.

Традиционно, каталог (известный также как каталог папок) представляет собой иерархическую структуру на основе дерева, в которой файлы группируются в папки, и папки, в свою очередь, упорядочиваются в соответствии с относительными узловыми точками, которые содержат дерево каталогов. Например, как изображено на фиг.2А, базовая папка (или «корневой каталог») 212 основанной на DOS файловой системы может содержать множество папок 214, каждая из которых может дополнительно содержать дополнительные папки (в качестве «подпапок» этой конкретной папки) 216, и каждая из них также может содержать дополнительные папки 218 до бесконечности. Каждая из этих папок может иметь один или несколько файлов 220, хотя на уровне аппаратной/программной интерфейсной системы индивидуальные файлы в папке не имеют ничего общего, за исключением их расположения в древовидной иерархии. Не удивительно, что этот подход организации файлов в иерархии папок косвенно отражает физическую организацию обычного носителя данных, используемого для хранения этих файлов (например, жесткие диски, дискеты, компакт-диски и т.д.).

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

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

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

А. СЛОВАРЬ

Для целей данного описания и формулы изобретения следующие термины имеют следующее значение:

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

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

«Аппаратная/программная интерфейсная система» представляет собой программное обеспечение или комбинацию аппаратных средств и программного обеспечения, которое служит в качестве интерфейса между лежащими в основе аппаратными компонентами компьютерной системы и приложениями, которые исполняются на компьютерной системе. Аппаратная/программная интерфейсная система обычно содержит (и в некоторых вариантах осуществления может состоять исключительно из) операционную систему. Аппаратная/программная интерфейсная система также может содержать диспетчер виртуальных машин (ДВМ; VMM), общеязыковую среду выполнения (ОЯСВ; CLR) или ее функциональный эквивалент, виртуальную Java-машину (BJM; JVM) или ее функциональный эквивалент, или другой такой программный компонент вместо или в дополнение к операционной системе в компьютерной системе. Целью аппаратной/программной интерфейсной системы является обеспечение среды, в которой пользователь может исполнять программы приложений. Цель любой аппаратной/программной интерфейсной системы заключается в том, чтобы сделать компьютерную систему удобной для использования, а также использовать аппаратные средства компьютера эффективным образом.

В. ОБЗОР ПЛАТФОРМЫ ХРАНЕНИЯ

Ссылаясь на фиг.3, платформа 300 хранения согласно настоящему изобретению содержит хранилище 302 данных, реализованное на процессоре (средстве обработки) 314 базы данных. В одном варианте осуществления процессор базы данных содержит процессор реляционной базы данных с объектно-реляционными расширениями. В одном варианте осуществления процессор 314 реляционной базы данных содержит процессор реляционной базы данных Microsoft SQL Server.

Хранилище 302 данных реализует модель 304 данных, которая поддерживает организацию, поиск, совместное использование, синхронизацию и защиту данных. Конкретные типы данных описываются в схемах, таких как схемы 340, и платформа 300 хранения предусматривает инструментальные средства 346 для развертывания этих схем, а также для расширения этих схем, как более подробно описано ниже.

Механизм 306 отслеживания изменений, реализованный в хранилище 302 данных, предусматривает возможность отслеживания изменений в хранилище данных. Хранилище 302 данных также обеспечивает возможности 308 защиты и возможности 310 распространения/устранения распространения, обе из которых более подробно описываются ниже. Хранилище 302 данных также обеспечивает раскрытие набором интерфейсов 312 прикладного программирования возможностей хранилища 302 данных другим компонентам платформы хранения и программам приложений (например, программам 350а, 350b и 350с приложений), которые используют платформу хранения.

Платформа хранения настоящего изобретения дополнительно содержит интерфейсы 322 прикладного программирования (ИПП; API), которые дают возможность программам приложений, таким как программы 350а, 350b и 350с приложений, обращаться ко всем вышеупомянутым возможностям платформы хранения и обращаться к данным, описанным в схемах. ИПП (API) 322 платформы хранения может использоваться программами приложений в комбинации с другими ИПП (APIs), такими как ИПП (API) 324 связывания и внедрения объектов (СВО) для баз данных (СВОБД; OLEDB) и ИПП (API) 326 Microsoft Windows Win32.

Платформа 300 хранения настоящего изобретения может предоставлять множество служб 328 для программ приложений, включая службу 330 синхронизации, которая способствует совместному использованию данных пользователями или системами. Например, служба 330 синхронизации может предоставлять возможность взаимодействия с другими хранилищами 340 данных, имеющими такой же формат, что и у хранилища 302 данных, а также доступа к хранилищам 342 данных, имеющим другие форматы. Платформа 300 хранения также предоставляет возможности файловой системы, которые предоставляют возможности взаимодействия хранилища 302 данных с существующими файловыми системами, такими как файловая система 318 ФСНТ (NTFS) Windows.

По меньшей мере в некоторых вариантах осуществления платформа 320 хранения также может предоставлять программам приложений дополнительные возможности, позволяющие выполнять воздействие на данные и взаимодействие с другими системами. Эти возможности могут осуществляться в виде дополнительных служб 328, таких как служба 334 Информационного агента и служба 332 уведомления, а также в виде других утилит 336.

По меньшей мере в некоторых вариантах осуществления платформа хранения реализуется в аппаратной/программной интерфейсной системе компьютерной системы или составляет ее неотъемлемую часть. Например, и без ограничения, платформа хранения настоящего изобретения может реализоваться в, или составляет неотъемлемую часть, операционной системе, диспетчере виртуальных машин (ДВМ; VMM), общеязыковой среде выполнения (ОЯСВ; CLR) или ее функциональном эквиваленте или виртуальной Java-машине (BJM) или ее функциональном эквиваленте.

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

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

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

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

Модель данных основывается на двух примитивных механизмах, Типы и Связи. Типы представляют собой структуры, которые обеспечивают формат, который управляет формой экземпляра Типа. Формат выражается в виде упорядоченного набора Свойств. Свойство представляет собой имя значения или набора значений данного Типа. Например, тип USPostalAddress может иметь свойства Street, City, Zip, State, в которых Street, City и State являются типа String, и Zip является Типом Int32. Street может иметь много значений (т.е. набор значений), которые дают возможность адресу иметь более одного значения для свойства Street. Система определяет некоторые элементарные типы, которые могут использоваться при построении других типов – они включают в себя String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal и GUID (глобально уникальный идентификатор (ГУИД; GUID)). Свойства Типа могут определяться с использованием любых элементарных типов или (с некоторыми ограничениями, отмеченными ниже) любых сложных типов. Например, мог быть определен Тип Location, который имел Свойства Coordinate и Address, где Свойство Address является Типа USPostalAddress, как описано выше. Свойства также могут быть обязательными и необязательными.

Связи могут объявляться и представлять отображение между наборами экземпляров двух типов. Например, может быть Связь, объявленная между Типом Person и Типом Location, названная LivesAt, которая определяет, кто из людей живет по какому местожительству. Связь имеет имя, две конечные точки, а именно конечную точку источника и конечную точку цели. Связи также могут иметь упорядоченный набор свойств. Конечные точки как Источника, так и Цели имеют Имя и Тип. Например, Связь LivesAt имеет Источник, названный Occupant Типа Person, и Цель, названную Dwelling Типа Location, и дополнительно имеет свойства StartDate и EndDate, указывающие период времени, в течение которого житель проживал по местожительства. Следует отметить, что Person может проживать по многочисленным местожительствам во времени, и местожительство может иметь многочисленных жителей, поэтому наиболее вероятным местом размещения информации о StartDate и EndDate является сама связь.

Связи определяют отображение между экземплярами, которые ограничиваются типами, данными в качестве типов конечных точек. Например, связь LivesAt не может быть связью, в которой Automobile является Occupant, так как Automobile не является Person.

Модель данных действительно позволяет выполнять определение связи подтип-подтип между типами. Связь подтип-подтип, также известная как связь BaseType, определяется таким образом, что, если Тип А является BaseType для Типа В, то должно быть так, что каждый экземпляр В также представляет собой экземпляр А. Другим способом выражения этого является то, что каждый экземпляр, который соответствует В, также должен соответствовать А. Если, например, А имеет свойство Name Типа String, тогда как В имеет свойство Age Типа Int16, то из этого следует, что любой экземпляр В должен иметь как Name, так и Age. Иерархия типов может рассматриваться как дерево с единственным супертипом в корне. Ветви от корня обеспечивают подтипы первого уровня, ветви на этом уровне обеспечивают подтипы второго уровня и т.д. до подтипов самых последних листьев, которые сами не имеют никаких подтипов. Дерево не ограничивается равномерной глубиной, но не может содержать никаких циклов. Данный Тип может иметь нуль или более подтипов и нуль или один супертип. Данный экземпляр может соответствовать самое большее одному типу вместе с супертипами этого типа. Другими словами, для данного экземпляра на любом уровне в дереве экземпляр может соответствовать самое большее одному подтипу на этом уровне.

Типом, как считается, является Abstract, если экземпляры типа также должны быть экземпляром подтипа типа.

1. Предметы

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

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

Предметы предназначены для представления реальных и легко понимаемых единиц данных, таких как Контакты, Люди, Службы, Расположения, Документы (всех различных видов) и т.д. Фиг.5А представляет собой блок-схему, иллюстрирующую структуру Предмета. Несоставным именем Предмета является «Location». Составным именем Предмета является «Core.Location», которое указывает, что эта структура Предмета определяется как конкретный тип Предмета в Основной схеме. (Основная схема описывается более подробно в данном описании ниже).

Предмет Location имеет множество свойств, включая EAddresses, MetropolitanRegion, Neighborhood и PostalAddresses. Конкретный тип свойства для каждого указывается непосредственно за именем свойства и отделяется от имени свойства двоеточием («:»). Справа от имени типа указывается ряд значений, разрешенных для этого типа свойства, между скобками («[]»), в которых звездочка («*») справа от двоеточия («:») обозначает незаданное и/или неограниченное количество («многие»). «1» справа от двоеточия указывает, что может быть самое большое одно значение. Нуль («0») слева от двоеточия указывает, что свойство является необязательным (может быть вообще без значения). «1» слева от двоеточия указывает, что должно быть по меньшей мере одно значение (требуется свойство). Neighborhood и MetropolitanRegion оба представляют собой тип «nvarchar» (или эквивалентный), который является предварительно определенным типом данных или «простым типом» (и обозначается в данном описании отсутствием выделения заглавными буквами). EAddress и PostalAddresses, однако, представляют собой свойства определенных типов или «составных типов» (обозначаемых в данном описании выделением заглавными буквами) типов EAddress и PostalAddress соответственно. Составной тип представляет собой тип, который выводится из одного или нескольких простых типов данных и/или из других составных типов. Составные типы для свойств Предмета также составляют «вложенные элементы», так как подробности составного типа вложены в непосредственный Предмет для определения ее свойств, и информация, относящаяся к этим составным типам, сохраняется с Предметом, который имеет эти свойства (внутри границ Предмета, как описано в данном описании ниже). Эти принципы задания типов хорошо известны и легко понятны для специалиста в данной области техники.

Фиг.5В представляет собой блок-схему, иллюстрирующую составные типы свойств PostalAddress и EAddress. Тип свойства PostalAddress определяет, что Предмет типа свойства PostalAddress может, как ожидается, иметь нуль или одно значение City, нуль или одно значение CountryCode, нуль или одно значение MailStop и любое количество (нуль – многие) PostalAddressTypes и т.д. и т.п. Таким образом, этим определяется вид данных для конкретного свойства в Предмете. Тип свойства EAddress определяется аналогичным образом, как показано. Хотя необязательно используемый в данном описании данной заявки, другим путем представления составных типов в Предмете Location является выведение Предмета с индивидуальными свойствами каждого составного типа, перечисленного в нем. Фиг.5С представляет собой блок-схему, иллюстрирующую Предмет Location, в котором дополнительно описываются его составные типы. Однако необходимо понять, что это альтернативное представление Предмета Location на этой фиг.5С предназначено для точно такого же Предмета, изображенного на фиг.5А. Платформа хранения настоящего изобретения также позволяет выполнять задание подтипов, посредством чего один тип свойства может быть подтипом другого (где один тип свойства наследует свойства другого, родительского типа свойства).

Аналогично, но отличаясь от свойств и их типов свойств, Предметы по сути представляют свои собственные Типы Предметов, которые также могут быть предметом задания подтипов. Другими словами, платформа хранения в нескольких вариантах осуществления настоящего изобретения предоставляет возможность Предмету быть подтипом другого Предмета (посредством чего один Предмет наследует свойства другого, родительского Предмета). Кроме того, для различных вариантов осуществления настоящего изобретения каждый Предмет представляет собой подтип типа Предмета «Item», который является первым и основополагающим типом Предмета, находящимся в Базовой схеме. (Базовая схема также подробно описывается в данном описании ниже.) Фиг.6А иллюстрирует Предмет, Предмет Location в этом Примере, который является подтипом типа Предмета Item находящегося в Базовой схеме. На этом чертеже стрелка указывает, что предмет Location (аналогично всем другим Предметам) является подтипом типа Предмета Item. Тип Предмета Item в качестве основополагающего Предмета, из которого выводятся все другие Предметы, имеет ряд важных свойств, таких как ItemId и различные временные метки, и, таким образом, определяет стандартные свойства всех Предметов в операционной системе. На настоящей фигуре эти свойства типа Предмета Item наследуются Location и, таким образом, становятся свойствами Location.

Другим путем представления свойств в Предмете Location, наследуемом из типа Предмета Item, является выведение Location с индивидуальными свойствами каждого типа свойств из родительского Предмета, перечисленного в нем. Фиг.6В представляет собой блок-схему, иллюстрирующую Предмет Location, в котором его наследованные типы описаны в дополнение к его непосредственным свойствам. Необходимо отметить и понять, что этот Предмет представляет собой тот же Предмет, что и изображенный на фиг.5А, хотя на настоящей фигуре Location изображается со всеми своими свойствами, как непосредственными – показанными как на этой фигуре, так и на фиг.5А, так и наследованными – показанными на этой фигуре, но не на фиг.5А (поскольку на фиг.5А эти свойства упоминаются посредством изображения со стрелкой, что Предмет Location является подтипом типа Предмета Item).

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

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

– Тип Item Предмета и, если Предмет является подтипом другого Предмета (как в случае с несколькими вариантами осуществления настоящего изобретения, где все Предметы выводятся из единственного Предмета и Типа Item в Базовой схеме), информацию о любом применимом подтипе (т.е. информацию, относящуюся к родительскому типу Item). Если исходный копируемый Предмет представляет собой подтип другого Предмета, копия также может быть подтипом этого же Предмета.

– Свойства и расширения составного типа Предмета, если они есть. Если исходный Предмет имеет свойства составных типов (собственные или расширенные), копия также может иметь эти же составные типы.

– Записи Предмета по «связям владения», т.е. собственный список Предмета того, какими другими Предметами («Предметами цели» или целевыми Предметами) владеет настоящий Предмет («Владеющий Предмет»). Это особенно уместно в отношении Папок Предметов, описываемых более подробно ниже, и правила, указанного ниже, что все Предметы должны принадлежать по меньшей мере одной Папке Предметов. Кроме того, в отношении внедренных предметов, описываемых более подробно ниже, внедренный предмет, как считается, является частью Предмета, в который он внедряется, для операций, таких как копирование, удаление и т.п.

2. Идентификация Предметов

Предметы однозначно идентифицируются в глобальном пространстве предметов при помощи ItemID. Тип Base.Item определяет поле ItemID типа GUID, которое хранит идентификатор для Предмета. Предмет должен иметь точно один идентификатор в хранилище 302 данных.

а) Ссылка на предмет

Ссылка на предмет представляет собой структуру данных, которая содержит информацию для определения расположения и идентификации Предмета. В модели данных определяется абстрактный тип, названный ItemReference, из которого выводятся все ссылочные типы предмета. Тип ItemReference определяет виртуальный метод, названный Resolve. Метод Resolve разрешает ItemReference и возвращает Item. Этот метод замещается конкретными подтипами ItemReference, которые реализуют функцию, которая извлекает Предмет по данной ссылке. Метод Resolve вызывается как часть ИПП (API) 322 платформы хранения.

(1) ItemIDReference

ItemIDReference представляет собой подтип ItemReference. Он определяет поле Locator и ItemID. Поле Locator именует (т.е. идентифицирует) домен предмета. Оно обрабатывается методом разрешения локатора, который может разрешить значение Локатора для домена предмета. Поле ItemID является типом ItemID.

(2) ItemPathReference

ItemPathReference представляет собой специализацию ItemReference, которая определяет поле Locator и Path. Поле Locator идентифицирует домен предмета. Оно обрабатывается методом разрешения локатора, который может разрешить значение Locator для домена предмета. Поле Path содержит (относительный) путь в пространстве имен платформы хранения с корнем в домене предмета, предусмотренным посредством Locator.

Этот тип ссылки не может использоваться в операции установки. Ссылка должна, в основном, разрешаться при помощи процесса разрешения пути. Метод Resolve ИПП (API) 322 платформы хранения обеспечивает данную функциональную возможность.

b) Иерархия ссылочного типа

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

3. Папки и категории предметов

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

Как также более подробно описано ниже, Предметы также могут принадлежать Категориям, основанным на общих описанных характеристиках, таких как (а) Тип (или Типы) Item, (b) конкретное непосредственное или наследованное свойство (или свойства) или (с) конкретное значение (или значения), соответствующее свойству Предмета. Например, Предмет, содержащий конкретные свойства для персональной контактной информации, может автоматически принадлежать Категории Contact, и любой Предмет, имеющий свойства контактной информации, будет точно так же автоматически принадлежать этой Категории. Аналогичным образом, любой Предмет, имеющий свойство расположения со значением «New York City», может автоматически принадлежать Категории NewYorkCity.

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

Фиг.4 иллюстрирует структурную связь между Предметами, Папками Предметов и Категориями в различных вариантах осуществления настоящего изобретения. Множество Предметов 402, 404, 406, 408, 410, 412, 414, 416, 418 и 420 являются членами различных Папок 422, 424, 426, 428 и 430 Предметов. Некоторые Предметы могут принадлежать более чем одной Папке Предметов, например, Предмет 402 принадлежит Папкам 422 и 424 Предметов. Некоторые Предметы, например, Предметы 402, 404, 406, 408, 410 и 412 также являются членами одной или нескольких Категорий 432, 434 и 436, тогда как в других случаях, например, Предметы 414, 416, 418 и 420 могут не принадлежать никакой Категории (хотя это, большей частью маловероятно в некоторых вариантах осуществления, где владение любым свойством автоматически означает членство в Категории, и, таким образом, Предмет должен быть совершенно лишен характерных черт, чтобы не быть членом никакой категории в таком варианте осуществления). В противоположность иерархической структуре папок как Категории, так и Папки Предметов имеют структуры, более похожие на ориентированные графы, как показано. В любом случае Предметы, Папки Предметов и Категории все представляют собой Предметы (хотя и различных Типов Item).

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

4. Схемы

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

Чтобы обеспечить всеобъемлющую основу для создания и использования Предметов, различные варианты осуществления платформы хранения настоящего изобретения содержат Базовую Схему, которая устанавливает концептуальную структуру для создания и организации Предметов и свойств. Базовая Схема определяет некоторые специальные типы Предметов и свойств и особенности этих специальных основополагающих типов, из которых могут дополнительно выводиться подтипы. Использование этой Базовой Схемы позволяет программисту концептуально отличать Предметы (и их соответствующие типы) от свойств (и их соответствующих типов). Кроме того, Базовая Схема формулирует основополагающий набор свойств, которым все Предметы могут обладать, так как все Предметы (и их соответствующие Типы Item) выводятся из этого основополагающего Предмета в Базовой Схеме (и ее соответствующего Типа Item).

Как изображено на фиг.7 и в отношении нескольких вариантов осуществления настоящего изобретения, Базовая Схема определяет три типа верхнего уровня: Item, Extension и PropertyBase. Как показано, тип Item определяется свойствами этого основополагающего типа Предметов «Item». В противоположность этому тип свойства верхнего уровня «PropertyBase» не имеет предварительно определенных свойств и представляет собой просто привязку, из которой выводятся все другие типы свойств и посредством которой связываются между собой все выводимые типы свойств (выводимые обычно из единственного типа свойств). Свойства типа Extension определяют, какой Предмет расширяет расширение, а также идентификацию для отличия одного расширения от другого, так как Предмет может иметь многочисленные расширения.

ItemFolder представляет собой подтип типа Предмета Item, который в дополнение к свойствам, наследуемым от Item, характеризуется Связью для установления связывания с ее членами (если они есть), тогда как и IdentityKey, и Property представляют собой подтипы PropertyBase. CategoryRef, в свою очередь, является подтипом IdentityKey.

b) Основная схема

Различные варианты осуществления платформы хранения настоящего изобретения дополнительно содержат Основную Схему, которая обеспечивает концептуальную основу для структур типа Item верхнего уровня. Фиг.8А представляет собой блок-схему, иллюстрирующую Предметы в Основной Схеме, и фиг.8В представляет собой блок-схему, иллюстрирующую типы свойств в Основной Схеме. Отличие, сделанное между файлами с различными расширениями (*.com, *.exe, *.bat, *.sys и т.д.), и другие такие критерии в системах, основанных на файлах и папках, аналогичны функции Основной Схемы. В основанной на Предметах аппаратной/программной интерфейсной системе Основная Схема определяет набор основных типов Item, которые непосредственно (посредством типа Item) или косвенно (посредством подтипа Item) характеризуют все Предметы в один или несколько типов Item Основной Схемы, которые основанная на Предметах аппаратная/программная интерфейсная система понимает и может непосредственно обрабатывать предварительно определенным и предсказуемым образом. Предварительно определенные типы Item отражают наиболее общие Предметы в основанной на Предметах аппаратной/программной интерфейсной системе, и, таким образом, повышается уровень эффективности посредством основанной на Предметах аппаратной/программной интерфейсной системы, понимающей эти предварительно определенные типы Item, которые содержит Основная Схема.

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

Для различных вариантов осуществления настоящего изобретения и со ссылкой на фиг.8А, конкретные типы Item, поддерживаемые Основной Схемой, могут включать в себя одно или несколько из следующего:

– Категории: Предметы этого Типа Item (и подтипы, выведенные из него) представляют действительные Категории в основанной на Предметах аппаратной/программной интерфейсной системе.

– Товары: Предметы, которые являются идентифицируемыми ценностно значимыми объектами.

– Устройства: Предметы, имеющие логическую структуру, которая поддерживает возможности обработки информации.

– Документы: Предметы с содержимым, которое не интерпретируется основанной на Предметах аппаратной/программной интерфейсной системой, но вместо этого интерпретируется программой приложения, соответствующей типу документа.

– События: Предметы, которые регистрируют некоторые случаи в среде.

– Расположения: Предметы, представляющие физические расположения (например, географические расположения).

– Сообщения: Предметы обмена данными между двумя или более принципалами (определенными ниже).

– Принципалы: Предметы, имеющие по меньшей мере один точно доказуемый идентификатор кроме ItemID (например, идентификация личности, организации, группы, семьи, органа, службы и т.д.).

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

Аналогично, и со ссылкой на фиг.8В, конкретные типы свойств, поддерживаемые Основной Схемой, могут включать в себя одно или несколько из следующего:

– Сертификаты (выводимые из основополагающего типа PropertyBase в Базовой Схеме)

– Ключи идентификации принципала (выводимые из типа IdentityKey в Базовой Схеме)

– Почтовый адрес (выводимый из типа Property в Базовой Схеме)

– Обогащенный текст (выводимый из типа Property в Базовой Схеме)

– EAddress (выводимый из типа Property в Базовой Схеме)

– IdentitySecurityPackage (выводимый из типа Relationship в Базовой Схеме)

– RoleOccupancy (выводимый из типа Relationship в Базовой Схеме)

– BasicPresence (выводимый из типа Relationship в Базовой Схеме)

Эти Предметы и Свойства дополнительно описываются набором их соответствующих свойств, изложенных на фиг.8А и 8В.

5. Связи

Связи представляют собой бинарные связи, где один Предмет обозначается как источник, а другой Предмет – как цель. Предмет источника и Предмет цели связываются связью. Предмет источника обычно управляет временем существования связи. Т.е., когда удаляется Предмет источника, также удаляется связь между Предметами.

Связи классифицируются на: связи Включения и Ссылки. Связи включения управляют временем существования Предметов цели, тогда как связи ссылки не обеспечивают никакой семантики управления временем существования. Фиг.12 иллюстрирует то, как классифицируются связи.

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

Связи ссылок не управляют временем существования Предмета цели. Они могут быть повисшими – Предмет цели может не существовать. Связи ссылок могут использоваться для моделирования ссылок на Предметы в любом месте в глобальном пространстве имен Предметов (т.е. включая удаленные хранилища данных).

Выборка Предмета не выбирает автоматически его связи. Приложения должны явно запросить связи Предмета. Кроме того, модифицирование связи не модифицирует Предмет источника или цели; аналогично, добавление связи не оказывает влияния на Предмет источника/цели.

а) Объявление связи

Явные типы связи определяются следующими элементами:

– Имя связи задается в атрибуте Name.

– Типом связи, одно из следующих: Прикрепления, Внедрения, Ссылки. Он задается в атрибуте Type.

– Конечными точками источника и цели. Каждая конечная точка задает имя и тип ссылаемого Предмета.

– Поле конечной точки источника обычно типа ItemID (не объявлен), и оно должно ссылаться на Предмет в этом же хранилище данных, что и экземпляр связи.

– Для связей Прикрепления и Внедрения поле конечной точки цели должно быть типа ItemIDReference, и оно должно ссылаться на Предмет в этом же хранилище данных, что и экземпляр связи. Для связей Ссылки конечная точка цели может быть любого типа ItemReference и может ссылаться на Предметы в других хранилищах данных платформы хранения.

– Необязательно может объявляться одно или несколько полей скалярного типа или типа PropertyBase. Эти поля могут содержать данные, ассоциированные со связью.

– Экземпляры связей хранятся в глобальной таблице связей.

– Каждый экземпляр связи однозначно идентифицируется комбинацией (ItemID источника, ID связи). ID связи является уникальным в пределах данного ItemID источника для всех связей, имеющих происхождение в данном Предмете независимо от их типа.

Предмет источника является владельцем связи. Хотя Предмет, обозначенный как владелец, управляет временем существования связи, сама связь является отдельной от Предметов, с которыми она связана. ИПП (API) 322 платформы хранения предусматривает механизмы для раскрытия связей, ассоциированных с Предметом.

Вот пример объявления связи:

ReferenceType=”ItemIDReference” />

platformTypes.DateTime” />

platformTypes.DateTime” />

platformTypes.DateTime” />

Это пример связи Ссылки. Связь не может быть создана, если не существует Предмета person, на который ссылается ссылка источника. Также, если удаляется Предмет person, удаляются экземпляры связей между person и organization. Однако, если удаляется Предмет Organization, связь не удаляется, и она является повисшей.

b) Связь прикрепления

Связи прикрепления используются для моделирования управления временем существования Предметов цели на основе подсчета ссылок.

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

Ссылочным типом конечной точки цели должен быть ItemIDReference, и он должен ссылаться на Предмет в этом же хранилище, что и экземпляр связи.

Связи прикрепления выполняют управление временем существования конечной точки цели. Создание экземпляра связи прикрепления и Предмета, для которого он является целью, представляет собой атомарную операцию. Могут создаваться дополнительные экземпляры связи прикрепления, целью которых является этот же Предмет. Когда удаляется последний экземпляр связи прикрепления с данным Предметом в качестве конечной точки цели, также удаляется Предмет цели.

Типы Предметов конечных точек, заданных в объявлении связи, вводятся в действие, когда создается экземпляр связи. Типы Предметов конечных точек не могут быть изменены после установления связи.

Связи прикрепления играют ключевую роль при формировании пространства имен Предметов. Они содержат свойство «Name», которое определяет имя Предмета цели относительно Предмета источника. Это относительное имя является уникальным для всех связей прикрепления, источником которых является данный Предмет. Упорядоченный список этих относительных имен, начинающийся с корневого Предмета до данного Предмета, формирует полное имя для Предмета.

Связи прикрепления формируют ориентированный ациклический граф (ОАГ; DAG). Когда создается связь прикрепления, система гарантирует, что не создается цикл, таким образом гарантируя, что пространство имен Предметов формирует ОАГ (DAG).

Хотя связь прикрепления управляет временем существования Предмета цели, она не управляет операционной совместимостью Предмета конечной точки цели. Предмет цели операционно не зависит от Предмета, который им владеет при помощи связи прикрепления. Операции Копирования, Перемещения, Резервирования и другие операции над Предметом, который является источником связи прикрепления, не оказывают влияния на Предмет, который является целью этой же связи, например, т.е. резервирование Предмета Папки не резервирует автоматически все Предметы в папке (цели связи FolderMember).

Нижеследующее является примером связи прикрепления:

ReferenceType=”ItemIDReference” />

Связь FolderMembers позволяет осуществлять принцип Папки в качестве обобщенной коллекции Предметов.

с) Связи внедрения

Связи внедрения моделируют принцип привилегированного управления временем существования Предмета цели. Они делают возможным понятие составных Предметов.

Создание экземпляра связи внедрения и Предмета, который представляет собой цель, является атомарной операцией. Предмет может быть источником нуля или более связей внедрения. Однако Предмет может быть целью одной и только одной связи внедрения. Предмет, который является целью связи внедрения, не может быть целью связи прикрепления.

Ссылочным типом конечной точки цели должен быть ItemIDReference, и он должен ссылаться на Предмет в этом же хранилище данных, что и экземпляр связи.

Типы Предметов конечной точки, заданные в объявлении связи, как правило, будут задействоваться, когда создается экземпляр связи. Типы Предметов конечной точки не могут изменяться после установления связи.

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

Нижеследующее представляет собой примерное объявление:

ReferenceType=”ItemIDReference” />

platformTypes.bigint” />

platformTypes.float” />

d) Связи ссылки

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

Пример объявления связи ссылки следующий:

ReferenceType=”ItemIDReference” />

platformTypes.nvarchar(256)” />

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

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

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

Следующие дополнительные правила и ограничения применяются к связям:

1. Предмет должен быть целью (точно одной связи внедрения) или (одной или нескольких связей прикрепления). Единственным исключением является корневой Предмет. Предметом может быть цель нуля или более связей ссылки.

2. Предмет, который является целью связи внедрения, не может быть источником связей прикрепления. Он может быть источником связей ссылки.

3. Предмет не может быть источником связи прикрепления, если распространяется (promoted) из файла. Он может быть источником связей внедрения и связей ссылки.

4. Предмет, который распространяется (promoted) из файла, не может быть целью связи внедрения.

f) Упорядочение связей

По меньшей мере в одном варианте осуществления платформа хранения настоящего изобретения поддерживает упорядочение связей. Упорядочение достигается посредством свойства, названного «Order» в базовом определении связей. Нет ограничения на единственность на поле Order. Не гарантируется порядок связей с одинаковым значением свойства «order», однако гарантируется, что они могут упорядочиваться после связей с более низким значением «order» и до связей с более высоким значением поля «order».

Приложения могут получать связи в порядке по умолчанию посредством упорядочивания по комбинации (SourceItemID, RelationshipID, Order). Все экземпляры связи, источником которых является данный Предмет, упорядочиваются в виде единственной коллекции независимо от типа связей в коллекции. Это, однако, гарантирует, что все связи данного типа (например, FolderMembers) представляют собой упорядоченный поднабор коллекции связей для данного Предмета.

ИПП (API) 312 хранилища данных для манипулирования связями реализует набор операций, который поддерживает упорядочение связей. Вводятся следующие термины, помогающие объяснить операции:

RelFirst представляет собой первую связь в упорядоченной коллекции со значением OrdFirst очередности;

RelLast представляет собой последнюю связь в упорядоченной коллекции со значением OrdLast очередности;

RelX представляет собой данную связь в коллекции со значением OrdX очередности;

RelPrev представляет собой ближайшую связь в коллекции к RelX со значением OrdPrev очередности, меньшим, чем OrdX; и

RelNext представляет собой ближайшую связь в коллекции к RelX со значением OrdNext очередности, большим, чем OrdX.

InsertBeforeFirst (SourceItemID, Relationship)

Вставляет связь в качестве первой связи в коллекции. Значение свойства «Order» новой связи может быть меньше, чем OrdFirst.

InsertAfterLast (SourceItemID, Relationship)

Вставляет связь в качестве последней связи в коллекции. Значение свойства «Order» новой связи может быть больше, чем OrdLast.

InsertAt (SourceItemID, ord, Relationship)

Вставляет связь с заданным значением для свойства «Order».

InsertBefore (SourceItemID, ord, Relationship)

Вставляет связь перед связью с данным значением очередности. Новой связи может быть назначено значение «Order», которое находится между OrdPrev и ord, не включая их.

InsertAfter (SourceItemID, ord, Relationship)

Вставляет связь после связи с данным значением очередности. Новой связи может быть назначено значение «Order», которое находится между ord и OrdNext, не включая их.

MoveBefore (SourceItemID, ord, RelationshipID)

Перемещает связь с данным идентификатором (ИД; ID) связи перед связью с заданным значением «Order». Связи может быть назначено новое значение «Order», которое находится между OrdPrev и ord, не включая их.

MoveAfter (SourceItemID, ord, RelationshipID)

Перемещает связь с данным ИД (ID) связи после связи с заданным значением «Order». Связи может быть назначено новое значение очередности, которое находится между ord и OrdNext, не включая их.

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

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

Независимо от фактической реализации Связь представляет собой выбираемое соединение от одного объекта к другому. Возможность принадлежности Предмета к более чем одной Папке Предметов, а также к одной или нескольким Категориям, и являются ли эти Предметы, Папки и Категории открытыми или закрытыми, определяется смыслом, данным существованию (или его отсутствию) в основанной на Предметах структуре. Эти логические Связи представляют собой смысл, назначенный набору Связей, независимо от физической реализации, которые конкретно используются для достижения функциональных возможностей, описанных в данном документе. Логические Связи устанавливаются между Предметом и его Папкой(ами) Предметов или Категориями (или наоборот), так как, по существу, Папки Предметов и Категории каждая представляет собой специальный тип Item. Следовательно, с Папками Предметов и Категориями можно действовать таким же образом, как и с любым другим Предметом – копировать, добавлять к сообщению электронной почты, внедрять в документ и т.п. и т.д. без ограничения, Папки Предметов и Категории могут сериализоваться и десериализоваться (импортироваться и экспортироваться), используя одинаковые механизмы, что и для других Предметов. (Например, в расширяемом языке разметки (РЯР; XML) все Предметы могут иметь формат сериализации, и этот формат применяется в равной степени к Папкам Предметов, Категориям и Предметам.)

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

Фиг.9 представляет собой блок-схему, иллюстрирующую Папку Предметов (которая, снова, представляет собой сам Предмет), Предметы ее членов и взаимно соединяющие Связи между Папкой Предметов и Предметами ее членов. Папка 900 Предметов имеет в качестве членов множество Предметов 902, 904 и 906. Папка 900 Предметов имеет Связь 912 от самой себя к Предмету 902, которая означает, что Предмет 902 является открытым и совместно используемым для Папки 900 Предметов, ее членов 904 и 906 и любых других Папок Предметов, Категорий или Предметов (не показаны), которые могут обращаться к Папке 900 Предметов. Однако нет Связи от Предмета 902 к Папке 900 Предметов, что означает, что Папка 900 Предметов является закрытой для Предмета 902 и не использует совместно ее информацию о членстве с Предметом 902. Предмет 904, с другой стороны, действительно имеет Связь 924 от самого себя к Папке 900 Предметов, которая означает, что Папка 900 Предметов является открытой и совместно использует ее информацию о членстве с Предметом 904. Однако нет Связи от Папки 900 Предметов к Предмету 904, которая означает, что Предмет 904 является закрытым и не совместно используемым для Папки 900 Предметов, ее других членов 902 и 906 и любых других Папок Предметов, Категорий или Предметов (не показаны), которые могут обращаться к Папке 900 Предметов. В противоположность ее Связям (или отсутствию их) к Предметам 902 и 904 Папка 900 Предметов имеет Связь 916 от самой себя к Предмету 906, и Предмет 906 имеет Связь 926 обратно к Папке 900 Предметов, которые вместе означают, что Предмет 906 является открытым и совместно используемым для Папки 900 Предметов, ее членов 902 и 904 и любых других Папок Предметов, Категорий или предметов (не показаны), которые могут обращаться к Папке 900 Предметов, и что Папка 900 Предметов является открытой и совместно использует свою информацию о членстве с Предметом 906.

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

Конечно, описания Категории являются логическими по своей сущности, и поэтому Категория может описываться любым логическим представлением типов, свойств и/или значений. Например, логическим представлением для Категории может быть то, что ее членство содержит Предметы, имеющие одно из двух свойств или оба. Если этими описанными свойствами для Категории являются «А» и «В», тогда членство Категорий может содержать Предметы, имеющие свойство А, но не В, Предметы, имеющие свойство В, но не А, и Предметы, имеющие оба свойства А и В. Это логическое представление свойств описывается логическим оператором «ИЛИ», где набор членов, описываемых Категорией, представляет собой Предметы, имеющие свойства А ИЛИ В. Аналогичные логические операнды (включая без ограничения «И», «Исключающее ИЛИ» и «НЕТ» отдельно или в комбинации) также могут использоваться для описания категории, что понятно для специалиста в данной области техники.

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

Фиг.10 представляет собой блок-схему, иллюстрирующую Категорию (которая, снова, представляет собой сам Предмет), Предметы ее членов и взаимно соединяющие Связи между Категорией и Предметами ее членов. Категория 1000 имеет в качестве членов множество Предметов 1002, 1004 и 1006, все из которых совместно используют некоторую комбинацию общих свойств, значений или типов 1008, описанных (описанием 1008′ общности) Категорией 1000. Категория 1000 имеет Связь 1012 от самой себя к Предмету 1002, которая означает, что Предмет 1002 является открытым и совместно используемым для Категории 1000, ее членов 1004 и 1006 и любых других Категорий, Папок Предметов или Предметов (не показаны), которые могут обращаться к Категории 1000. Однако нет Связи от Предмета 1002 к Категории 1000, которая означает, что Категория 1000 является закрытой для Предмета 1002 и не использует совместно свою информацию о членстве с Предметом 1002. Предмет 1004, с другой стороны, действительно имеет Связь 1024 от самого себя к Категории 1000, которая означает, что Категория 1000 является открытой и совместно использует свою информацию о членстве с Предметом 1004. Однако нет Связи, распространяемой от Категории 1000 к Предмету 1004, которая означает, что Предмет 1004 является закрытым и не является совместно используемым для Категории 1000, ее других членов 1002 и 1006 и любых других Категорий, Папок Предметов или Предметов (не показаны), которые могут обращаться к Категории 1000. В противоположность ее Связям (или отсутствию их) с Предметами 1002 и 1004 Категория 1000 имеет Связь 1016 от самой себя к Предмету 1006, и Предмет 1006 имеет Связь 1026 обратно к Категории 1000, которые вместе означают, что Предмет 1006 является открытым и совместно используемым для Категории 1000, ее членов 1002 и 1004 Предметов и любых других Категорий, Папок Предметов или Предметов (не показаны), которые могут обращаться к Категории 1000, и что Категория 1000 является открытой и совместно использует свою информацию о членстве с Предметом 1006.

Наконец, так как Категории и Папки Предметов сами являются Предметами, и Предметы могут иметь Связь друг с другом, Категории могут иметь Связь с Папками Предметов и наоборот, и Категории, Папки Предметов и Предметы могут иметь Связь с другими Категориями, Папками Предметов и Предметами соответственно в некоторых альтернативных вариантах осуществления. Однако в различных вариантах осуществления структуры Папок Предметов и/или структуры Категорий на уровне аппаратной/программной интерфейсной системы запрещены от содержания циклов. Где структуры Папок Предметов и Категорий сходны с ориентированными графами, варианты осуществления, которые запрещают циклы, сходны с ориентированными ациклическими графами (ОАГ; DAG), которые, согласно математическому определению в области теории графов, представляют собой ориентированные графы, в которых путь не начинается и не оканчивается в одной и той же вершине.

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

Предполагается, что платформа хранения предусматривается с исходным набором схем 340, как описано выше. Кроме того, однако, по меньшей мере в некоторых вариантах осуществления платформа хранения дает возможность потребителям, включая независимых поставщиков программного обеспечения (НППО; ISV), создавать новые схемы 344 (т.е. новые типы Item и Nested Element). Этот раздел касается механизма для создания таких схем посредством расширения типов Item и типов Nested Element (или просто типов «Element»), определенных в исходном наборе схем 340.

Предпочтительно, что расширение исходного набора типов Item и Nested Element ограничивается следующим образом:

НППО (ISV) разрешается вводить новые типы Item, т.е. подтип Base.Item;

НППО (ISV) разрешается вводить новые типы Nested Element, т.е. подтип Base.NestedElement;

НППО (ISV) разрешается вводить новые расширения, т.е. подтип Base.NestedElement; но

НППО (ISV) не может определять подтип любых типов (типы Item, Nested Element или Extension), определенных исходным набором схем 340 платформы хранения.

Так как тип Item или тип Nested Element, определенные исходным набором схем платформы хранения, не могут точно совпадать с потребностями приложения НППО (ISV), необходимо дать возможность НППО (ISV) настраивать тип. Это разрешается с понятием Расширения. Расширения представляют собой строго типизированные экземпляры, но (а) они не могут существовать независимо, и (b) они должны присоединяться к Предмету или Вложенному элементу (Nested Element).

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

а) Расширения предмета

Чтобы обеспечить расширяемость Предмета, модель данных дополнительно определяет абстрактный тип, названный Base.Extension. Это корневой тип для иерархии типов расширения. Приложения могут задавать подтип Base.Extension для создания конкретных типов расширения.

Тип Base.Extension определяется в Базовой схеме следующим образом:

Type=”the storage platformTypes.uniqueidentified”

Nullable=”false”

MultiValued=”false”/>

Type=”the storage platformTypes.uniqueidentified”

Nullable=”false”

MultiValued=”false”/>

Поле ItemID содержит ItemID предмета, с которым ассоциируется расширение. Должен существовать Предмет с этим ItemID. Расширение не может быть создано, если не существует предмет с данным ItemID. Когда удаляется Предмет, удаляются все расширения с одинаковым ItemID. Кортеж (ItemID, ExtensionID) однозначно идентифицирует экземпляр расширения.

Структура типа расширения аналогична структуре типа предмета:

Типы расширения имеют поля;

Поля могут быть типов простейших и вложенных элементов; и

У типов расширения могут задаваться подтипы.

Следующие ограничения применяются к типам расширений:

Расширения не могут быть источниками и целями связей;

Экземпляры типа расширения не могут существовать независимо от предмета; и

Типы расширений не могут использоваться в качестве типов полей в определениях типа платформы хранения.

Нет ограничений на типы расширений, которые могут ассоциироваться с данным типом Item. Любой тип расширения разрешен для расширения любого типа предмета. Когда множественные экземпляры расширений присоединяются к предмету, они не зависят друг от друга как по структуре, так и по методу поведения.

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

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

Аналогично типам Item к экземплярам типа Extension можно непосредственно обращаться через представление, ассоциированное с типом расширения. ItemID расширения указывает, к какому предмету они принадлежат и какой предмет может использоваться для извлечения соответствующего объекта Item из глобального представления Предмета.

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

Рассмотрим следующий пример. Тип Contact определяется в наборе Типов Windows.

Type=”String”

Nullable=”false”

MultiValued=”false”/>

Type=”Address”

Nullable=”true”

MultiValued=false”/>

Разработчик приложения управления взаимосвязями с клиентами (УВК; CRM) хотел бы присоединить расширение приложения УВК (CRM) к контактам, хранящимся в платформе хранения. Разработчик приложения определяет расширение УВК (CRM), которое содержит дополнительную структуру данных, которой приложение может манипулировать.

Type=”String”

Nullable=”false”

MultiValued=”false”/>

Разработчик приложения управления кадрами (УК; HR) может пожелать также присоединить дополнительные данные с Contact. Эти данные являются независимыми от данных приложения УВК (CRM). Разработчик приложения снова может создать расширение

Type=”String”

Nullable=”false”

MultiValued=”false”/>

CRMExtension и HRExtension представляют собой два независимых расширения, которые могут быть присоединены к предметам Contact. Они создаются и к ним обращаются независимо друг от друга.

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

Когда извлекается предмет Contact, не извлекаются автоматически его расширения предмета. При наличии предмета Contact к связанным с ним расширениям предмета можно обращаться посредством запроса глобального представления расширения в отношении расширений с одинаковым ItemId.

Ко всем расширениям CRMExtension в системе можно обращаться при помощи представления типа CRMExtension независимо от того, к какому предмету они принадлежат. Все расширения предмета у предмета совместно используют одинаковый идентификатор предмета. В вышеприведенном примере экземпляр предмета Contact и присоединенные экземпляры CRMExtension и HRExtension имеют одинаковый ItemID.

В нижеследующей таблице просуммированы сходства и различия между типами Item, Extension и NestedElement:

Item в сравнении с Item Extension в сравнении с NestedElement
	Item	Item Extension	NestedElement
ИД (ID) предмета	Имеет свой собственный ИД (ID) предмета	Совместно использует ИД (ID) предмета у предмета	Не имеет своего собственного ИД (ID) предмета. Вложенный элемент представляет собой часть предмета.
Хранение	Иерархия предметов хранится в своих собственных таблицах	Иерархия расширений предмета хранится в своих собственных таблицах	Хранится с предметом
Запрос/поиск	Может запрашивать таблицы предметов	Может запрашивать таблицы расширений предметов	Может, в основном, запрашиваться только в контексте, включающем предмет
Область действия запроса/поиска	Может выполнять поиск по всем экземплярам типа предмета	Может выполнять поиск по всем экземплярам типа расширения предмета	Может, в основном, выполнять поиск только в экземплярах типа вложенного элемента единственного (включающего) предмета
Семантика связей	Может иметь Связи к предметам	Нет Связей к расширениям предмета	Нет Связей к вложенным элементам
Ассоциация с предметами	Могут иметь связь к другим предметам при помощи Связей прикрепления, Связей внедрения и гибких Связей	Могут, в основном, иметь связи только при помощи расширений. Семантика расширений аналогична семантике внедренных предметов.	Имеет связи с предметом при помощи полей. Вложенные элементы являются частью предмета.

b) Расширение типов NestedElement

Типы Nested Element не расширяются при помощи такого же механизма, что и типы Item. Расширения вложенных элементов (nested elements) хранятся, и к ним выполняется обращение при помощи тех же механизмов, что и поля типов вложенных элементов.

Модель данных определяет корень для типов вложенных элементов, названный Element:

IsAbstract=”True”>

Type=”the storage platformTypes.uniqueidentifier”

Nullable=”false”

MultiValued=”false”/>

Тип NestedElement наследует от этого типа. Тип элемента NestedElement дополнительно определяет поле, которое представляет собой мультинабор Элементов.

IsAbstract=”True”>

Type=”Base.Element”

Nullable=”false”

MultiValued=”true”/>

Расширения NestedElement отличаются от расширений предмета следующим:

Расширения вложенных элементов не являются типами расширений. Они не принадлежат к иерархии типов расширений, корнем которой является тип Base.Extension.

Расширения вложенных элементов хранятся вместе с другими полями предмета и не являются с глобальным доступом – не может быть составлен запрос, который извлекает все экземпляры данного типа расширения.

Эти расширения хранятся таким же образом, как хранятся другие вложенные элементы (предмета). Подобно другим вложенным наборам, расширения NestedElement хранятся в ОПТ (UDT). Они являются доступными через поле Extensions типа вложенных элементов.

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

Следующая таблица суммирует и сравнивает расширения Item и NestedElement.

Расширения Item по сравнению с расширениями NestedElement
	Расширение Item	Расширение NestedElement
Хранение	Иерархия расширения Item хранится в своих собственных таблицах	Хранится подобно вложенным элементам
Запрос/поиск	Может запрашивать таблицы расширений предмета	Может, в основном, запрашиваться только в контексте, включающем предмет
Область действия запроса/поиска	Может выполнять поиск по всем экземплярам типа расширений предмета	Может, в основном, выполнять поиск только в пределах экземпляров типа вложенного элемента единственного (включающего) предмета
Программируемость	Требует специальные ИПП (API) расширений и специальные запросы по таблицам расширений	Расширения NestedElement подобны любому другому полю со многими значениями вложенного элемента; используются ИПП (API) нормального типа вложенного элемента
Метод поведения	Может ассоциировать метод поведения	Методы поведения не разрешены (?)
Семантика Связей	Нет Связей к расширениям предмета	Нет Связей к расширениям NestedElement
ИД (ID) предмета	Совместно использует ИД (ID) предмета у предмета	Не имеет своего собственного ИД (ID) предмета. Расширение NestedElement является частью предмета

D. ПРОЦЕССОР БАЗЫ ДАННЫХ

Как упомянуто выше, хранилище данных реализуется на процессоре базы данных. В настоящем варианте осуществления процессор базы данных содержит процессор реляционной базы данных, который реализует язык запросов ЯСЗ (SQL), такой как процессор Microsoft SQL Server, с объектно-реляционными расширениями. В этом разделе описывается отображение модели данных, которое хранилище данных реализует для реляционного хранилища, и предоставляет информацию по логическому ИПП (API), используемому клиентами платформы хранения, согласно настоящему варианту осуществления. Понятно, однако, что может применяться другое отображение, когда применяется другой процессор базы данных. Действительно, в дополнение к реализации концептуальной модели данных платформы хранения на процессоре реляционной базы данных, она также может быть реализована на других типах баз данных, например на объектно-ориентированных базах данных и базах данных РЯР (XML).

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

Аналогично объектно-ориентированным системам, базы данных РЯР (XML), основанные на определении РЯР (XML)-схемы (ОРС; XSD), поддерживают системы типа на основе единичного наследования. Система типов предметов настоящего изобретения может отображаться на модель типов ОРС (XSD). ОРС (XSD) также не обеспечивают поддержку методов поведения. ОРС (XSD) для предметов необходимо дополнить методами поведения предметов. Базы данных РЯР (XML) имеют дело с единственными ОРС (XSD)-документами, и в них отсутствует возможность организации и широкого поиска. Как и с объектно-ориентированными базами данных, для поддержки модели данных, описанной в данном документе, другие понятия, подобные связям и папкам, необходимо встроить в такие базы данных РЯР (XML); также необходимо реализовать механизмы, подобные синхронизации, уведомления и защите (безопасности).

1. Реализация хранилища данных, используя ОПТ (UDT)

В настоящем варианте осуществления процессор 314 реляционной базы данных, который в одном варианте осуществления содержит процессор Microsoft SQL Server, поддерживает встроенные скалярные типы. Встроенные скалярные типы являются «родными» и «простыми». Они являются родными в том смысле, что пользователь не может определять свои собственные типы, и они являются простыми в том, что они не могут инкапсулировать составную структуру. Определяемые пользователем типы (ниже: ОПТ (UDT)) обеспечивают механизм для расширяемости типов над и за пределы родной системы скалярного типа, тем самым позволяя пользователям расширять систему типов посредством определения составных, структурированных типов. Если он определен пользователем, ОПТ (UDT) может использоваться где угодно в системе типов, где может использоваться встроенный скалярный тип.

Согласно аспекту настоящего изобретения схемы платформы хранения отображаются на классы ОПТ (UDT) в хранилище процессора базы данных. Предметы хранилища данных отображаются на классы ОПТ (UDT), выводимые из типа Base.Item. Подобно Предметам, Расширения также отображаются на классы ОПТ (UDT) и используют наследование. Корневым типом Extension является Base.Extension, из которого выводятся все типы Extension.

ОПТ (UDT) представляет собой класс ОЯСВ (CLR) – он имеет состояние (т.е. поля данных) и метод поведения (т.е. подпрограммы). ОПТ (UDT) определяются с использованием любого управляемого языка – С#, VB.NET и др. Методы и операторы ОПТ (UDT) могут вызываться в T-SQL в отношении экземпляра этого типа. ОПТ (UDT) может быть: типом столбца в строке, типом параметра подпрограммы в T-SQL или типом переменной в T-SQL.

Следующий пример иллюстрирует основы ОПТ (UDT). Предположим, что MapLib.dll имеет сборку, названную MapLib. В этой сборке имеется класс, названный Point, в пространстве имен BaseTypes:

namespace BaseTypes

{

public class Point

{

public double Distance(Point p)

{

}

}

}

Следующий код T-SQL связывает класс Point с ОПТ (UDT) SQL Server, названным Point. На первом шаге вызывается «CreateAssembly», который загружает сборку MapLib в базу данных. На втором шаге вызывается «Create Type» для создания Определяемого пользователем типа «Point» и связывает его с управляемым типом BaseTypes.Point:

CREATE ASSEMBLY MapLib

go

CREATE TYPE Point

EXTERNAL NAME ‘BaseTypes.Point’

go

Если он создан, ОПТ (UDT) «Point» может использоваться в качестве столбца в таблице и методы могут вызываться в T-SQL, как показано ниже:

Create table Cities(

Name varchar(20),

State varchar(20),

Location Point)

— Извлечь Distance городов

— из координат (32, 23)

Declare @p point(32, 23), @distance float

Select Location::Distance(@p)

From Cities

Отображение схем платформы хранения на классы ОПТ (UDT) является довольно непосредственным на высоком уровне. В основном, Схема платформы хранения отображается на пространство имен ОЯСВ (CLR). Тип платформы хранения отображается на класс ОЯСВ (CLR). Наследование класса ОЯСВ (CLR) отражает наследование Типа платформы хранения, и Свойство платформы хранения отображается на свойство класса ОЯСВ (CLR).

Иерархия Предметов, изображенная на фиг.29, используется в качестве примера в данном документе. Она показывает тип Base.Item, из которого выводятся все типы Item, вместе с набором производных типов Item (например, Contact.Person и Contact.Employee), с наследованием, указанным стрелками.

2. Отображение предметов

Задаваясь желательностью глобального поиска для Предметов и поддержки в реляционной базе данных настоящего варианта осуществления наследования и замещаемости типов, одной возможной реализацией хранения Предметов в хранилище базы данных было бы хранение всех Предметов в единственной таблице со столбцом типа Base.Item. Используя замещаемость типов, Предметы всех типов могли бы храниться, и поиск мог бы фильтроваться по типу и подтипу Item, используя оператор Yukon «is of (Тип)».

Однако вследствие важности служебных данных, связанных с таким подходом, в настоящем варианте осуществления Предметы делятся типом верхнего уровня, так что Предметы каждого «семейства» типа хранятся в отдельной таблице. При такой схеме разделения таблица создается для каждого типа Item, наследуя непосредственно из Base.Item. Типы, наследующие ниже этих, хранятся в соответствующей таблице семейства типа, используя замещаемость типов, как описано выше. Только первый уровень наследования из Base.Item рассматривается специально. Для примерной иерархии Предметов, показанной на фиг.29, это приводит к следующим таблицам семейства типа:

create table Contact.[Table!Person] (

_Item Contact.Person not null,

{Информация по отслеживанию изменений}

)

create table Doc.[Table!Document] (

_Item Doc.Document not null,

{Информация по отслеживанию изменений}

)

«Теневая» таблица используется для хранения копий свойств глобального поиска для всех Предметов. Эта таблица может поддерживаться методом Update() ИПП (API) платформы хранения, при помощи которого выполняются все изменения данных. В отличие от таблиц семейства типа эта глобальная таблица Предметов содержит только скалярные свойства верхнего уровня Предмета, не полного объекта ОПТ (UDT) Item. Структура глобальной таблицы Предметов следующая:

create table Base.[Table!Item] (

ItemID uniqueidentifier not null constraint [PK_Clu_Item!ItemID] primary key clustered,

TypeID uniqueidentifier not null,

{Дополнительные свойства Base.Item},

{Информации по отслеживанию изменений}

)

Глобальная таблица Предметов дает возможность выполнять навигацию к объекту Item, хранимому в таблице семейства типа, посредством раскрытия ItemID и TypeID. ItemID, в основном, однозначно идентифицирует Предмет в хранилище данных. TypeID может отображаться, используя метаданные, которые не описываются здесь, на имя типа и представление, включающее Предмет.

Так как обнаружение Предмета по его ItemID может быть простой операцией как в контексте глобальной таблицы Предметов, так и иным образом, предусматривается функция GetItem() для извлечения объекта Item по ItemID Предмета. Эта функция имеет следующее объявление:

Base.Item Base.GetItem (uniqueidentifier ItemID)

Для удобного доступа и скрытия подробностей реализации до возможной степени все запросы Предметов могут выполняться в отношении представлений, построенных на таблицах Предметов, описанных выше. Конкретно, представления могут создаваться для каждого типа Item в отношении соответствующей таблицы семейства типа. Эти представления типов могут выбирать все Предметы ассоциированного типа, включая подтипы. Для удобства в дополнение к объекту ОПТ (UDT) представления могут раскрывать столбцы для всех полей верхнего уровня этого типа, включая наследуемые поля. Представления для примерной иерархии Предметов, показанной на фиг.29, следующие:

create view Contact.Person as

select _Item.ItemID, {Свойства Base.Item}, {Свойства Contact.Person}, {Информация по отслеживанию изменений}, _Item

from Contact.[Table!Person]

–Отметьте, что представление Contact.Employee использует предикат «where»

–для ограничения набора обнаруженных Предметов до экземпляров Contact.Employee

create view Contact. Employee as

select _Item.ItemID, {Свойства Base.Item}, {Свойства Contact.Person}, {Свойства

Contact. Employee},

{Информация по отслеживанию изменений}, cast (_Item as Contact.Employee)

from Contact.[Table!Person]

where _Item is of (Contact. Employee)

create view Doc. Document as

select _Item.ItemID, {Свойства Base.Item}, {Свойства Doc.Document}, {Информация по

отслеживанию изменений}, _Item

from Doc.[Table!Document]

–Отметьте, что представление Doc.WordDocument использует предикат «where»

–для ограничения набора обнаруженных Предметов до экземпляров Doc.WordDocument

create view Doc.WordDocument as

select _Item.ItemID, {Свойства Base.Item}, {Свойства Doc.Document}, {Свойства

Doc.WordDocument},

{Информация по отслеживанию изменений}, cast (_Item as Doc.WordDocument)

from Doc.[Table!Document]

where _Item is of (Doc.WordDocument)

Для полноты представление также может создаваться по глобальной таблице Предметов. Это представление первоначально может раскрывать такие же столбцы, что и таблица:

create view Base.Item as

select ItemID, TypeID, {Свойства Base.Item}, {Информация по отслеживанию

изменений}

from Base.[Table!Item]

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

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

В настоящем варианте осуществления Расширение ассоциируется с точно одним Предметом посредством ItemID и содержит ExtensionID, который является уникальным в контексте Предмета. Таблица Расширений имеет следующее определение:

create table Base.[Table!Extension] (

ItemID uniqueidentifier not null,

ExtensionID uniqueidentifier not null,

TypeID uniqueidentifier not null,

{Свойства Base.Extension},

{Информация по отслеживанию изменений},

constraint [PK_Clu_Extension!ItemID!ExtensionID]

primary key clustered (ItemID asc, ExtensionID asc)

)

Как и с Предметами может быть предусмотрена функция для извлечения Расширения по его идентификатору, который состоит из пары ItemID и ExtensionID. Эта функция имеет следующее объявление:

Base.Extension Base.GetExtension (uniqueidentifier ItemID, uniqueidentifier ExtensionID,)

Для каждого типа Extension создается Представление, аналогичное представлениям типа Item. Предположим, что иерархия Расширений параллельна примерной иерархии Предметов со следующими типами: Base.Extension, Contact.PersonExtension, Contact.

create view Contact.[Extension!PersonExtension] as

select _Extension.ItemID, _Extension.ExtensionID, { EmployeeExtension. Могут быть созданы следующие представления:

create view Base.Extension as

select ItemID, ExtensionID, TypeID, {Свойства Base.Extension}, {Информация по

отслеживанию изменений}

from Base.[Table!Extension]Свойства Base.Extension, {Свойства

Contact.PersonExtension},

{Информация по отслеживанию изменений}, _Extension

from Base.[Table!PersonExtension]

create view Contact.[Extension!EmployeeExtension] as

select _Extension.ItemID, _Extension.ExtensionID, {Свойства Base.Extension), {Свойства

Contact.PersonExtension},

{Свойства Contact.EmployeeExtension}, {Информация по отслеживанию

изменений},

cast (_Extension as Contact.EmployeeExtension)

from Base.[Table!PersonExtension]

where _Extension is of (Contact.EmployeeExtension)

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

Вложенные элементы представляют собой типы, которые могут внедряться в Предметы, Расширения, Связи или другие Вложенные элементы, формируя структуры с большой глубиной вложения. Подобно Предметам и Расширениям Вложенные Элементы реализуются как ОПТ (UDT), но они хранятся в Предметах и Расширениях. Поэтому Вложенные Элементы не имеют отображения хранения кроме их контейнеров Предметов и Расширений. Другими словами, нет таблиц в системе, которые непосредственно хранят экземпляры типов NestedElement, и нет представлений, специально выделенных Вложенным элементам.

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

Каждая сущность в модели данных, т.е. каждый Предмет, Расширение и Связь, имеет уникальное значение ключа. Предмет однозначно идентифицируется посредством его ItemID. Расширение однозначно идентифицируется посредством составного ключа (ItemId, ExtensionId). Связь идентифицируется составным ключом (ItemId, RelationshipId). ItemId, ExtensionId и RelationshipId представляют собой значения GUID.

6. Именование объектов ЯСЗ (SQL)

Все объекты, созданные в хранилище данных, могут храниться в имени схемы ЯСЗ (SQL), выводимом из имени схемы платформы хранения. Например, Базовая схема платформы хранения (часто называемая «Base») может создавать типы в схеме ЯСЗ (SQL) «[System.Storage]», такой как «[System.Storage].Item». К генерируемым именам добавляется префикс при помощи квалификатора для устранения конфликтов именования. Когда это является подходящим, восклицательный знак (!) используется в качестве разделителя для каждой логической части имени. В таблице ниже вкратце изложено соглашение об именовании, используемое для объектов в хранилище данных. Каждый элемент схемы (Предмет, Расширение, Связь и Представление) перечисляется вместе с соглашением о декорированном именовании, используемом для доступа к экземплярам в хранилище данных.

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

При отображении любой объектной модели на хранилище имеет место возможность конфликтов именования вследствие дополнительной информации, хранимой вместе с объектом-приложением. Чтобы исключить конфликты именования, все столбцы, не характерные для типа, (столбцы, которые не отображаются непосредственно на именованное Свойство в объявлении типа) дополняются префиксом при помощи символа подчеркивания (_). В настоящем варианте осуществления символы подчеркивания (_) запрещены в качестве начального знака любого свойства идентификатора. Далее, чтобы унифицировать именование между ОЯСВ (CLR) и хранилищем данных, все свойства типов или элемента схемы (связь и т.д.) платформы хранения должны иметь написанный заглавными буквами первый символ.

8. Представления поиска

Представления предусматриваются платформой хранения для поиска хранимого содержимого. Представление ЯСЗ (SQL) предоставляется для каждого типа Item и Extension. Далее, представления предоставляются для поддержки Связей и Представлений (определенных Моделью Данных). Все представления ЯСЗ (SQL) и лежащие в основе таблицы в платформе хранения являются только для чтения. Данные могут храниться или изменяться с использованием метода Update() ИПП (API) платформы хранения, как описано более подробно ниже.

К каждому представлению, явно определенному в схеме (определяемой разработчиком схемы и не генерируемой автоматически платформой хранения) платформы хранения, может обращаться именованное представление ЯСЗ (SQL) [<имя-схемы].[View!<имя-представления>]. Например, к представлению, именованному «BookSales» в схеме «AcmePublisher.Books», можно обращаться с использованием имени «[AcmePublisher.Books].[View!BookSales]». Так как выходной формат представления настраивается на основе каждого представления (определяемый посредством произвольного запроса, предоставляемого стороной, определяющей представление), столбцы непосредственно отображаются, основываясь на определении представления схемы.

Все представления поиска ЯСЗ (SQL) в хранилище данных платформы хранения используют следующее соглашение об упорядочении для столбцов:

1. Логический «ключевой» столбец (столбцы) результата представления, такой как ItemId, ElementId, RelationshipId,

2. Информация метаданных по типу результата, такая как TypeId.

3. Столбцы отслеживания изменений, такие как CreateVersion, UpdateVersion,

4. Характерный для типа столбец (столбцы) (Свойства объявленного типа).

5. Характерные для типа представления (представления семейства) также содержат столбец объекта, который возвращает объект.

Члены каждого семейства типа являются доступными для поиска, используя последовательность представлений Предметов, причем имеется одно представление на тип Item в хранилище данных.

а) Предмет

Каждое представление поиска Предмета содержит строку для каждого экземпляра Предмета конкретного типа или его подтипов. Например, представление для Document может возвращать экземпляры Document, LegalDocument и ReviewDocument. Принимая во внимание данный пример, представления Предметов могут быть представлены на концептуальном уровне так, как показано на фиг.28.

(1) Главное представление поиска предметов

Каждый экземпляр хранилища данных платформы хранения определяет специальное представление Предметов, названное Главное представление Предметов. Это представление предусматривает информационную сводку по каждому Предмету в хранилище данных. Представление предусматривает один столбец на свойство типа Item, столбец, который описывает тип Предмета, и несколько столбцов, которые используются для предоставления информации по отслеживанию изменений и синхронизации. Главное представление предметов идентифицируется в хранилище данных, используя имя «[System.Storage].[Master!Item]».

Столбец	Тип	Описание
ItemId	ItemId	Идентификация платформы хранения Предмета
_TypeId	TypeId	TypeId Предмета идентифицирует точный тип Предмета и может использоваться для извлечения информации по типу, используя каталог Metadata.
_RootItemId	ItemId	ItemId первого невнедренного предшественника, который управляет временем существования этого предмета.
<глобальное отслеживание изменений>		Информация о глобальном отслеживании изменений
<Свойства Item>	не применяется	Один столбец на свойство типа Item

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

Каждый тип Item также имеет представление поиска. Наряду с тем, что оно является аналогичным представлению корневого Предмета, это представление также обеспечивает доступ к объекту Item при помощи столбца «_Item». Каждое типизированное представление поиска предмета идентифицируется в хранилище данных с использованием имени [Имясхемы].[Имятипаitem]. Например, [AcmeCorp.Doc].[OfficeDoc].

Столбец	Тип	Описание
ItemId	ItemId	Идентификация платформы хранения Предмета
<отслеживание изменений типа>		Информация по отслеживанию изменений типа
<родительские свойства>	<характерные для свойства	Один столбец на родительское свойство
<свойства предмета>	<характерные для свойства>	Один столбец на исключительное свойство этого типа
_Item	Тип ОЯСВ (CLR) Предмета	Объект ОЯСВ (CLR) – тип объявленного Предмета

b) Расширения предмета

Все Расширения Предмета в WinFS также являются доступными с использованием представлений поиска.

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

Каждый экземпляр хранилища данных определяет специальное представление Расширений, названное Главное представление Расширений. Это представление предоставляет информационную сводку по каждому Расширению в хранилище данных. Представление имеет столбец на свойство Расширения, столбец, который описывает тип Расширения, и несколько столбцов, которые используются для предоставления информации по отслеживанию изменений и синхронизации. Главное представление расширений идентифицируется в хранилище данных с использованием имени «[System.Storage].[Master!Extension]».

Столбец	Тип	Описание
ItemId	ItemId	Идентификация платформы хранения Предмета, с которым ассоциируется это расширение
ExtensionId	ExtensionId (GUID)	ИД (ID) этого экземпляра расширения
_TypeId	TypeId	TypeId Расширения – идентифицирует точный тип расширения и может использоваться для извлечения информации по расширению, используя каталог Metadata.
<глобальное отслеживание изменений>		Информация по глобальному отслеживанию изменений
<свойства расширений>	<характерные для расширений>	Один столбец на свойство типа Extension

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

Каждый тип Extension также имеет представление поиска. Наряду с тем, что оно является аналогичным главному представлению расширений, это представление также предоставляет доступ к объекту Item посредством столбца _Extension. Каждое типизированное представление поиска расширений идентифицируется в хранилище данных с использованием имени [Имясхемы].[Extension!ИмяТипарасширения]. Например, [AcmeCorp.Doc].[Extension!OfficeDocExt].

Столбец	Тип	Описание
ItemId	ItemId	Идентификация платформы хранения Предмета, с которым ассоциируется это расширение
ExtensionId	ExtensionId (GUID)	ИД (ID) этого экземпляра расширения
<отслеживание изменений типа>		Информация по отслеживанию изменений типа
<родительские свойства>	<характерные для свойства>	Один столбец на родительское свойство
<свойства расширения>	<характерные для свойства>	Один столбец на исключительное свойство этого типа
_Extension	Тип ОЯСВ (CLR) экземпляра Расширения	Объект ОЯСВ (CLR) – тип объявленного Расширения

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

Все вложенные элементы хранятся в экземплярах Предметов, Расширений или Связей. По существу, к ним обращаются посредством запроса соответствующего представления поиска Предметов, Расширений или Связей.

d) Связи

Как описано выше, Связи формируют фундаментальную единицу связывания между Предметами в хранилище данных платформы хранения.

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

Каждое хранилище данных предоставляет Главное представление Связей. Это представление предоставляет информацию по всем экземплярам связей в хранилище данных. Главное представление связей идентифицируется в хранилище данных с использованием имени «[System.Storage].[Master!Relationship]».

Столбец	Тип	Описание
ItemId	ItemId	Идентификация конечной точки (ItemId) источника
RelationshipId	RelationshipId (GUID)	ИД (ID) экземпляра связи
_RelTypeId	RelationshipTypeId	RelTypeId Связи – идентифицирует тип экземпляра связи, используя каталог Metadata
<глобальное отслеживание изменений>		Информация по глобальному отслеживанию изменений
TargetItemReference	ItemReference	Идентификация конечной точки цели
_Relationship	Relationship	Экземпляр объекта Relationship для этого экземпляра

(2) Представления поиска экземпляров связи

Каждая объявленная Связь также имеет представление поиска, которое возвращает все экземпляры конкретной связи. Наряду с тем, что оно является аналогичным главному представлению связи, это представление также предоставляет именованные столбцы для каждого свойства данных связи. Каждое представление поиска экземпляров связи идентифицируется в хранилище данных с использованием имени [Имясхемы].[Relationship!Имясвязи]. Например, [AcmeCorp.Doc].[Relationship!DocumentAuthor].

Столбец	Тип	Описание
ItemId	ItemId	Идентификация конечной точки (ItemId) источника
RelationshipId	RelationshipId (GUID)	ИД (ID) экземпляра связи
<отслеживание изменений типа>		Информация по отслеживанию изменений типа
TargetItemReference	ItemReference	Идентификация конечной точки цели
<имя источника>	ItemId	Именованное свойство идентификации конечной точки источника (псевдоним для ItemId)
<имя цели>	ItemReference или производный класс	Именованное свойство идентификации конечной точки цели (псевдоним и приведение типов для TargetItemReference)
<свойство связи>	<характерное для свойства>	Один столбец на свойство определения связи
_Relationship	Тип ОЯСВ (CLR) экземпляра Связи	Объект ОЯСВ (CLR) – тип объявленной Связи

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

Все представления в хранилище данных платформы хранения являются только для чтения. Чтобы создать новый экземпляр элемента модели данных (предмет, расширение или связь) или обновить существующий экземпляр, должны использоваться методы ProcessOperation или ProcessUpdategram ИПП (API) платформы хранения. Метод ProcessOperation представляет собой единственную хранимую процедуру, определенную хранилищем данных, которая использует «операцию», которая детализирует действие, подлежащее выполнению. Метод ProcessUpdategram представляет собой хранимую процедуру, которая принимает упорядоченный набор операций, известный как «updategram», который вместе детализирует набор действий, подлежащих выполнению.

Формат операции является расширяемым и обеспечивает различные операции над элементами схемы. Некоторые общие операции включают в себя:

1. Операции над Предметами:

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

b. UpdateItem (обновляет существующий Предмет)

2. Операции над Связями:

а. CreateRelationship (создает экземпляр связи ссылки или прикрепления)

b. UpdateRelationship (обновляет экземпляр связи)

c. DeleteRelationship (удаляет экземпляры связей)

3. Операции над Расширениями:

а. CreateExtension (добавляет расширение к существующему Предмету)

b. UpdateExtension (обновляет существующее расширение)

с. DeleteExtension (удаляет расширение)

10. Отслеживание изменений и объекты-памятники

Службы отслеживания изменений и объектов-памятников предоставляются хранилищем данных, как описано более подробно ниже. В данном разделе предоставляется общая структура информации по отслеживанию изменений, раскрытой в хранилище данных.

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

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

Для каждого элемента в хранилище данных информация по отслеживанию изменений доступна из двух мест – «главного» представления элементов и «типизированного» представления элементов. Например, информация по отслеживанию изменений по типу Item AcmeCorp.Document.Document доступна из Главного представления Предметов «[System.Storage].[Master!Item]» и типизированного представления поиска Предметов [AcmeCorp.Document].[Document].

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

Информация по отслеживанию изменений в главных представлениях поиска предоставляет информацию по версиям создания и обновления элемента, информацию по тому, какой партнер синхронизации создал элемент, какой партнер синхронизации последним обновил элемент, и номера версий от каждого партнера для создания и обновления. Партнеры в связях синхронизации (описанные ниже) идентифицируются посредством ключа партнера. Единственный объект ОПТ (UDT), названный _ChangeTrackingInfo, типа [System.Storage.Store].ChangeTrackingInfo содержит всю эту информацию. Тип определяется в схеме System.Storage. _ChangeTrackingInfo доступна во всех глобальных представлениях поиска для Предмета, Расширения и Связи. Определение типа ChangeTrackingInfo представляет собой:

Nullable=”False” />

Type=”SqlTypes.SqlInt32″ Nullable=”False” />

Type=”SqlTypes.SqlInt64″ Nullable=”False” />

Type=”SqlTypes.SqlInt64″ Nullable=”False” />

Type=”SqlTypes.SqlInt32″ Nullable=”False” />

Nullable=”False” />

Эти свойства содержат следующую информацию:

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

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

Столбец	Тип	Описание
<глобальное отслеживание изменений>		Информация от глобального отслеживания изменений
_ChangeUnitVersions	MultiSet	Описание номеров версий единиц изменения в конкретном элементе
_ElementSyncMetadata	ElementSyncMetadata	Дополнительные независимые от версии метаданные об этом предмете, которые представляют интерес только для периода выполнения Синхронизации.
_VersionSyncMetadata	VersionSyncMetadata	Дополнительные характерные для версии метаданные об этой версии, которые представляют интерес только для периода выполнения Синхронизации.

b) Объекты-памятники

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

(1) Объекты-памятники предметов

Объекты-памятники предметов извлекаются из системы при помощи представления [System.Storage].[Tombstone!Item].

Столбец	Тип	Описание
ItemId	ItemId	Идентификация Предмета
_TypeID	TypeId	Тип Предмета
<Свойства Предмета>		Свойства, определенные для всех предметов
_RootItemId	ItemId	ItemId первого невнедряющего предмета, который содержит этот предмет.
_ChangeTrackingInfo	Экземпляр ОЯСВ (CLR) типа ChangeTrackingInfo	Информация по отслеживанию изменений для этого предмета
_IsDeleted	BIT	Это флаг, который равен 0 для действующих предметов, и 1 для предметов, которые представляют собой объекты-памятники.
_DeletionWallclock	UTCDATETIME	Время/дата местного времени Всемирного координированного времени (ВКВ) в соответствии с партнером, который удалил предмет. Он равен NULL, если Предмет является действующим.

(2) Объекты-памятники расширений

Объекты-памятники расширений извлекаются из системы с использованием представления [System.Storage].[Tombstone!Extension]. Информация по отслеживанию изменений расширений аналогична той, которая предусматривается для Предметов с добавлением свойства ExtensionId.

(3) Объект-памятник связей

Объекты-памятники связей извлекаются из системы при помощи представления [System.Storage].[Tombstone!Relationship]. Информация об объектах-памятниках связей аналогична той, которая предусматривается для Расширений. Однако предусматривается дополнительная информация по ItemRef цели экземпляра связи. Кроме того, также выбирается объект связи.

(4) Очистка объектов-памятников

Чтобы предотвратить неограниченный рост информации по объектам-памятникам, хранилище данных предусматривает задачу очистки объектов-памятников. Эта задача определяет, когда может быть отброшена информация по объектам-памятникам. Задача вычисляет границу по локальной версии создания/обновления и затем усекает информацию по объектам-памятникам посредством отбрасывания всех более ранних версий объектов-памятников.

11. Вспомогательные средства API и функции

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

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

Возвращает объект Предмета при данном ItemId

Item GetItem (ItemId ItemId )

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

Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId )

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

Relationship GetRelationship ( ItemId ItemId, RelationshipId RelationshipId )

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

Существует два типа метаданных, представленных в Хранилище: метаданные экземпляра (тип Предмета и т.д.) и метаданные типа.

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

Метаданные схемы хранятся в хранилище данных в качестве экземпляров типов Item из Метасхемы.

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

Метаданные экземпляра используются приложением для запроса типа Предмета и находят расширения, ассоциированные с Предметом. При данном ItemId для Предмета приложение может запросить глобальное представление предмета для возврата типа Предмета и использовать это значение для запроса представления Meta.Type для возврата информации по объявленному типу Предмета. Например,

SELECT m._Item AS metadataInfoObj

FROM [System.Storage].[Item] i INNER JOIN [Meta].[Type] m ON i._TypeId = m.ItemId

WHERE i.ItemId = @ItemId

Е. ЗАЩИТА

В этом разделе описывается модель защиты для платформы хранения настоящего изобретения согласно одному варианту осуществления.

1. Обзор

Согласно настоящему варианту осуществления степень детализации, с которой задается и вводится в действие политика безопасности платформы хранения, находится на уровне различных операций над предметом в данном хранилище данных; нет возможности обеспечивать защиту для частей предмета отдельно от целого. Модель защиты задает набор принципалов, которым может быть предоставлен доступ или отказано в доступе к выполнению этих операций над предметом посредством списков управления доступом (СУД; ACL’s). Каждый СУД (ACL) представляет собой упорядоченную коллекцию записей управления доступом (ЗУД; ACE’s).

Политика безопасности для предмета может быть полностью описана политикой управления дискреционным доступом и политикой управления системным доступом. Каждый из них представляет собой набор СУД (ACL’s). Первый набор (список управления дискреционным доступом (СУДД; DACL’s) описывает дискреционный доступ, предоставляемый различным принципалам владельцем предмета, тогда как второй набор СУД (ACL’s) упоминается как списки управления системным доступом (СУСД; SALC’s), которые задают то, как выполняется аудит системы, когда объектом манипулируют некоторым образом. В дополнение к ним, каждый предмет в хранилище данных ассоциируется с идентификатором безопасности (ИДБ; SID), который соответствует владельцу предмета (ИДБ; SID) Владельца).

Первичным механизмом для организации предметов в хранилище данных платформы хранения является механизм иерархии включения. Иерархия включения реализуется с использованием связей прикрепления между предметами. Связь прикрепления между двумя предметами А и В, выраженная как «А включает В», позволяет предмету А оказывать влияние на время существования предмета В. В основном, предмет в хранилище данных не может существовать до тех пор, пока не будет связи прикрепления от другого предмета к нему. Связь прикрепления, в дополнение к управлению временем существования предмета, обеспечивает необходимый механизм для распространения политики безопасности для предмета.

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

Так как политика безопасности передается при помощи связей прикрепления и также может замещаться на любом предмете, необходимо задать, как определяется действующая политика безопасности для предмета. В настоящем варианте осуществления предмет в иерархии включения хранилища данных наследует СУД (ACL) по каждому пути от корня хранилища к предмету.

В наследуемом СУД (ACL) для любого данного пути упорядочение различных ЗУД (ACE’s) в СУД (ACL) определяет окончательную политику безопасности, которая вводится в действие. Следующее понятие используется для описания упорядочения ЗУД (ACE) в СУД (ACL). Упорядочение ЗУД (ACE) в СУД (ACL), который наследуется предметом, определяется следующими двумя правилами.

Первое правило расслаивает ЗУД (ACE’s), наследуемые от различных предметов на пути к предмету I от корня иерархии включения. ЗУД (ACE’s), наследуемые от ближнего контейнера, имеют преимущественное право над записями, наследуемыми от удаленного контейнера. Интуитивно, это предоставляет администратору возможность замещать ЗУД (ACE’s), наследуемые от более отдаленных в иерархии включения. Правило следующее:

Для всех L наследованных СУД (ACL’s) по предмету I

Для всех предметов I1, I2

Для всех ЗУД (ACE’s) А1 и А2 в L,

I1 является предшественником I2, и

I2 является предшественником I3, и

А1 является ЗУД (ACE), наследованный от I1, и

А2 является ЗУД (ACE), наследованный от I2,

означает, что

А2 предшествует А1 в L

Второе правило упорядочивает ЗУД (ACE’s), которые не разрешают доступ к предмету, перед ЗУД (ACE’s), которая предоставляет доступ к предмету.

Для всех L наследованных СУД (ACL’s) по предмету I

Для всех предметов I1′

Для всех ЗУД (ACE’s) А1 и А2 в L,

I1 является предшественником I2 и,

А1 является ACCESS_DENIED_ACE, наследованной от I1, и

А2 является ACCESS_GRANTED_ACE, наследованной от I1,

означает, что

А1 предшествует А2 в L

В том случае, когда иерархия включения представляет собой дерево, существует точно один путь от корня дерева к предмету, и предмет имеет точно один наследованный СУД (ACL). В таких случаях СУД (ACL), наследованный предметом, соответствует СУД (ACL), наследуемым файлом (предметом) в существующей модели защиты Windows, на основе относительного упорядочения ЗУД (ACE’s) в них.

Однако иерархия включения в хранилище данных представляет собой ориентированный ациклический граф (ОАГ; DAG), так как к предметам разрешено множество связей прикрепления. При таких условиях имеется множество путей к предмету от корня иерархии включения. Так как предмет наследует СУД (ACL) по каждому пути, каждый предмет ассоциируется с коллекцией СУД (ACL’s) в противоположность единственному. Следует отметить, что это отличается от традиционной модели файловой системы, где точно один СУД (ACL) ассоциируется с файлом или папкой.

Существуют два аспекта, которые должны быть уточнены, когда иерархией включения является ОАГ (DAG), в противоположность дереву. Требуется описание того, как вычисляется действующая политика безопасности для предмета, когда он наследует более одного СУД (ACL) от своих родителей, и то, как они организуются и представляются, имеет непосредственное отношение к администрированию модели защиты для хранилища данных платформы хранения.

Следующий алгоритм оценивает права доступа для данного принципала к данному предмету. В этом документе используется следующая система обозначений для описания СУД (ACL’s), ассоциированных с предметом.

Inherited_ACLs(ItemId) – набор СУД (ACL’s), наследованных предметом, идентификацией предмета которого является ItemId, от своих родителей в хранилище.

Explicit_ACL(ItemId) – СУД (ACL), явно определенный для предмета, идентификацией которого является ItemId.

NTSTATUS

ACLAccessCheck(

Вышеприведенная подпрограмма возвращает STATUS_SUCCESS, если не было явно отказано в требуемом доступе, и pGrantedAccess определяет, какое из прав, требуемых пользователем, было предоставлено заданным СУД (ACL). Если было явно отказано в любом требуемом доступе, подпрограмма возвращает STATUS_ACCESS_DENIED.

NTSTATUS

WinFSItemAccessCheck(

{

pExplicitACL = GetExplicitACLForItem(ItemId);

GetInheritedACLsForItem(ItemId,&pInheritedACLs,&NumberOfInheritedACLs)

Status = ACLAccessCheck(

pOwnerSid,

pExpficitACL,

DesiredAccess,

ClientToken,

pPrivilegeSet,

&GrantedAccess);

if (Status != STATUS_SUCCESS)

return Status;

if (DesiredAccess == GrantedAccess)

return STATUS SUCCESS;

for(

i = 0;

(i < NumberOfInheritedACLs && Status == STATUS_SUCCESS) ;

i++){

GrantedAccessForACL = 0;

Status = ACLAccessCheck(

pOwnerSid,

pExpficitACL,

DesiredAccess,

ClientToken,

pPrivilegeSet,

&GrantedAccessForACL);

if (Status = STATUS_SUCCESS) {

GrantedAccess |= GrantedAccessForACL;

}

}

If ((Status == STATUS_SUCCESS) &&

(GrantedAccess != DesiredAccess)) {

Status = STATUS_ACCESS_DENIED;

}

return Status;

}

Сфера влияния политики безопасности, определенной на любом предмете, охватывает всех потомков предмета в иерархии включения, определенной на хранилище данных. Для всех предметов, где определяется явная политика, изобретатели, фактически, определяют политику, которая наследуется всеми их потомками в иерархии включения. Действительный СУД (ACL), наследованный всеми потомками, получается взятием каждого СУД (ACL), наследованного предметом, и добавлением наследуемых ЗУД (ACE’s) в явный СУД (ACL) к началу СУД (ACL). Это упоминается как набор наследуемых СУД (ACL’s), ассоциированных с предметом.

В отсутствие любой явной спецификации безопасности в иерархии включения с корнем в предмете папки спецификация защиты папки применяется ко всем потомкам этого предмета в иерархии включения. Таким образом, каждый предмет, для которого предусмотрена явная спецификация политики безопасности, определяет зону идентично защищенных предметов, и действительные СУД (ACL’s) для всех предметов в зоне представляют собой набор наследуемых СУД (ACL’s) для этого предмета. Это полностью определяет зоны в случае иерархии включения, которая представляет собой дерево. Если бы каждая зона должна была ассоциироваться с номером, тогда было бы достаточным просто включить зону, к которой принадлежит предмет, вместе с предметом.

Однако для иерархий включения, которые представляют собой ОАГ (DAG’s), точки в иерархии включения, в которых изменяется эффективная политика безопасности, определяются двумя видами предметов. Первый представляет собой предметы, для которых был задан явный СУД (ACL). Обычно ими являются точки в иерархии включения, где администратор явно задал СУД (ACL). Второй представляет собой предметы, которые имеют более одного родителя, и родители имеют различные политики безопасности, ассоциированные с ними. Обычно это предметы, которые представляют собой точки слияния политики безопасности, заданной для тома, и указывают начало новой политики безопасности.

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

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

В данном разделе приведены подробности того, как предметы защищаются, посредством описания того, как индивидуальные права в Дескрипторе Защиты и содержащиеся в нем СУД (ACL’s) воздействуют на различные операции.

а) Структура дескриптора защиты

Перед описанием подробностей модели защиты полезно элементарное описание дескрипторов защиты. Дескриптор защиты содержит информацию по защите, ассоциированную с защищаемым объектом. Дескриптор защиты состоит из структуры SECURITY_DESCRIPTOR и связанной с ней информации по защите. Дескриптор защиты может включать в себя следующую информацию по защите:

1. ИДБ (SID’s) для владельца и первичной группы объекта.

2. СУДД (DACL), который задает права доступа, разрешаемые или отказываемые конкретным пользователям или группам.

3. СУСД (SACL), который задает типы попыток доступа, которые генерируют записи аудита для объекта.

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

Предпочтительно, что приложения не могут непосредственно манипулировать содержимым дескриптора защиты. Имеются функции для установки и извлечения информации по защите в дескрипторе защиты объекта. Кроме того, имеются функции для создания и инициализации дескриптора защиты для нового объекта.

Список управления дискреционным доступом (СУДД; DACL) идентифицирует опекунов, которым разрешен или запрещен доступ к защищаемому объекту. Когда процесс пытается обратиться к защищаемому объекту, система проверяет ЗУД (ACE’s) в СУДД (DACL) объекта для определения, предоставить ли доступ к нему. Если объект не имеет СУДД (DACL), система предоставляет полный доступ каждому. Если СУДД (DACL) объекта не имеет ЗУД (ACE’s), система запрещает все попытки доступа к объекту, так как СУДД (DACL) не предоставляет никаких прав доступа. Система проверяет ЗУД (ACE’s) последовательно до тех пор, пока она не обнаружит один или несколько ЗУД (ACE’s), которые предоставляют все запрашиваемые права доступа, или до тех пор, пока не будут запрещены любые из запрашиваемых прав доступа.

Список управления системным доступом (СУСД; SACL) дает возможность администраторам регистрировать попытки доступа к защищенному объекту. Каждый ЗУД (ACE) задает типы попыток доступа заданным опекуном, которые вызывают генерирование системой записи в журнале регистрации событий в системе защиты. ЗУД (ACE) в СУСД (SACL) может генерировать записи аудита, когда попытка доступа не достигает успеха, когда она достигает успеха или в обоих случаях. СУСД (SACL) также может подать предупредительный сигнал, когда незарегистрированный пользователь пытается получить доступ к объекту.

Все типы ЗУД (ACE’s) содержат следующую информацию по управлению доступом:

1. Идентификатор защиты (ИДБ; SID), который идентифицирует опекуна, к которому применяется ЗУД (ACE).

2. Маска доступа, которая задает права доступа, управляемые посредством ЗУД (ACE).

3. Флаг, который указывает тип ЗУД (ACE).

4. Набор битовых флагов, которые определяют, могут ли дочерние контейнеры или объекты наследовать ЗУД (ACE) от первичного объекта, к которому присоединен СУД (ACL).

В следующей таблице перечислены три типа ЗУД (ACE), поддерживаемые всеми защищаемыми объектами.

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

Все защищаемые объекты упорядочивают свои права доступа, используя формат маски доступа, показанный на фиг.26. В данном формате младшие 16 битов предназначены для характерных для объекта прав доступа, следующие 7 битов предназначены для стандартных прав доступа, которые применяются к большинству типов объектов, и 4 старших бита используются для задания обобщенных прав доступа, которые каждый тип объекта может отображать на набор стандартных и характерных для объекта прав. Бит ACCESS_SYSTEM_SECURITY соответствует праву доступа к СУСД (SACL) объекта.

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

Обобщенные права задаются в 4 старших битах маски. Каждый тип защищаемого объекта отображает эти биты на набор своих стандартных и характерных для объекта прав доступа. Например, объект файла отображает бит GENERIC_READ на стандартные права доступа READ_CONTROL и SYNCHRONIZE и на характерные для объекта права доступа FILE_READ_DATA, FILE_READ_EA и FILE_READ_ATTRIBUTES. Другие типы объектов отображают бит GENERIC_READ на любой набор прав доступа, который является соответствующим для этого типа объекта.

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

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

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

b) Характерные для предмета права

В структуре маски доступа по фиг.26 характерные для предмета права размещаются в секции Характерные для объекта права (младшие 16 битов). Так как в настоящем варианте осуществления платформа хранения раскрывает два набора ИПП (API’s) для администрирования безопасности – Win32 и ИПП (API) платформы хранения, характерные для объекта права файловой системы должны рассматриваться для того, чтобы мотивировать разработку характерных для объекта прав платформы хранения.

(1) Характерные для объекта права файла и каталога

Рассмотрим следующую таблицу:

Ссылаясь на вышеприведенную таблицу, следует отметить, что в файловых системах имеются фундаментальные различия между файлами и каталогами, вот почему права файлов и каталогов перекрываются на одних и тех же битах. Файловые системы определяют очень гранулированные права, позволяя приложениям управлять методом поведения этих объектов. Например, они дают возможность приложениям различать Атрибуты (FILE_READ/WRITE_ATTRIBUTES), Расширенные атрибуты и поток DATA, ассоциированный с файлом.

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

Следующие права предметов задаются со связанными с ними допустимыми операциями. Также обеспечиваются эквивалентные права Win32, поддерживающие каждое из этих прав предметов.

(2) WinFSItemRead

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

Файл:

(FILE_READ_DATA|SYNCHRONIZE)

Папку:

(FILE_LIST_DIRECTORY|SYNCHRONIZE)

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

(3) WinFSItemReadAttributes

Это право предоставляет доступ для чтения к базовым атрибутам Предмета почти так же, как файловые системы различают базовые атрибуты файла и потоки данных. Предпочтительно, что этими базовыми атрибутами являются те, которые постоянно находятся в базовом предмете, из которого выводятся все предметы. Это право отображается на:

Файл:

(FILE_READ_ATTRIBUTES)

Папку:

(FILE_READ_ATTRIBUTES)

(4) WinFSItemWriteAttributes

Это право предоставляет доступ для записи к базовым атрибутам Предмета почти так же, как файловые системы различают базовые атрибуты файла и потоки данных. Предпочтительно, что эти базовые атрибуты постоянно находятся в базовом предмете, из которого выводятся все предметы. Это право отображается на:

Файл:

(FILE_WRITE_ATTRIBUTES)

Папку:

FILE_WRITE_ATTRIBUTES)

(5) WinFSItemWrite

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

Файл:

(FILE_WRITE_DATA)

Папку:

(FILE_ADD_FILE)

В хранилище данных платформы хранения нет различия между предметами и папками, так как предметы также могут иметь Связи прикрепления к другим предметам в хранилище данных. Следовательно, если у вас есть права FILE_ADD_SUBDIRECTORY (или FILE_APPEND_DATA), вы можете иметь предмет, который является источником Связей к другим предметам.

(6) WinFSItemAddLink

Это право предоставляет возможность добавлять Связи прикрепления к предметам в хранилище. Необходимо отметить, что, так как модель защиты для множества Связей прикрепления изменяет защиту предмета и изменения могут обходить WRITE_DAC, если они поступают от точки с более высоким положением в иерархии, WRITE_DAC требуется на предмете назначения, чтобы можно было создавать к нему Связь. Это право отображается на:

Файл:

(FILE_APPEND_DATA)

Папку:

(FILE_ADD_SUBDIRECTORY)

(7) WinFSItemDeleteLink

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

Файл:

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

Папку:

(FILE_DELETE_CHILD)

(8) Права на удаление предмета

Предмет становится удаленным, если пропадает последняя Связь прикрепления к предмету. Нет явного понятия удаления предмета. Имеется операция очистки, которая удаляет все Связи прикрепления к предмету, но это возможность более высокого уровня и не является примитивом системы.

Любой предмет, заданный с использованием пути, может быть отсоединен, если удовлетворяется любое одно из двух условий: (1) родительский предмет по этому пути предоставляет доступ для записи субъекту, или (2) стандартные права на сам предмет предоставляют DELETE. Когда удаляется последняя Связь, предмет удаляется из системы. Любой предмет, заданный с использованием ItemID, может быть отсоединен, если стандартные права на сам предмет предоставляют DELETE.

(9) Права на копирование предмета

Предмет может копироваться из источника в папку назначения, если субъекту предоставляется WinFSItemRead на предмет и WinFSItemWrite на папку назначения.

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

Перемещение файла в файловой системе требует только права DELETE на файл источника и FILE_ADD_FILE на каталог назначения, так как он сохраняет СУД (ACL) на пункт назначения. Однако флаг может задаваться в вызове MoveFileEx (MOVEFILE_COPY_ALLOWED), который позволяет приложению задавать, что в случае перемещения между томами он может допускать семантику CopyFile. Существует 4 потенциальных варианта в отношении того, что происходит с дескриптором защиты при перемещении:

1. Переносит весь СУД (ACL) с файлом – семантика перемещения внутри тома по умолчанию.

2. Переносит весь СУД (ACL) с файлом и помечает СУД (ACL) как защищенный.

3. Переносит только явные ЗУД (ACE’s) и повторно наследует в пункте назначения.

4. Ничего не переносит и повторно наследует в пункте назначения – семантика перемещения между томами по умолчанию – как и при копировании файла.

В настоящей модели защиты, если приложение задает флаг MOVEFILE_COPY_ALLOWED, четвертый вариант выполняется для случаев как между томами, так и внутри тома. Если этот флаг не задан, выполняется второй вариант, если только пунктом назначения не является также та же зона безопасности (т.е. одинаковая семантика наследования). Перемещение на уровне платформы хранения также реализует четвертый вариант и требует READ_DATA на источник почти так же, как было бы при копировании.

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

Защита предмета может быть просмотрена, если предмет предоставляет стандартное право READ_CONTROL субъекту.

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

Защита предмета может быть изменена, если предмет предоставляет стандартное право WRITE_DAC субъекту. Однако, так как хранилище данных обеспечивает не явное наследование, это имеет последствия на то, как защита может изменяться по иерархиям. Правило такое, что, если корень иерархии предоставляет WRITE_DAC, тогда политика безопасности изменяется на всей иерархии, независимо от того, что конкретные предметы внутри иерархии (или ОАГ; DAG) не предоставляют WRITE_DAC субъекту.

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

В настоящем варианте осуществления FILE_EXECUTE (FILE_TRAVERSE для каталогов) не имеют прямого эквивалента в платформе хранения. Модель сохраняет их для совместимости с Win32, но не имеет никаких решений о доступе, выполненных для предметов, основанных на этих правах. Что касается FILE_READ/WRITE_EA, так как предметы хранилища данных не имеют понятия о расширенных атрибутах, не предусмотрена семантика для этого бита. Однако бит остается для совместимости с Win32.

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

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

Запись Идентификация Предмета представляет собой Идентификацию Предмета корня идентично защищенной зоны безопасности. Запись Ordpath Предмета представляет собой ordpath, ассоциированный с корнем идентично защищенной зоны безопасности. Запись Явный СУД (ACL) Предметов представляет собой явный СУД (ACL), определенный для корня идентично защищенной зоны безопасности. В некоторых случаях им может быть NULL, например, когда определяется новая зона безопасности, так как предмет имеет множество родителей, принадлежащих различным зонам. Запись СУД (ACL’s) Пути представляет собой набор СУД (ACL’s), наследуемых предметом, и запись СУД (ACL’s) Зоны представляет собой набор СУД (ACL’s), определенных для идентично защищенной зоны безопасности, ассоциированной с предметом.

Вычисление действующей защиты для любого предмета в данном хранилище усиливает эту таблицу. Чтобы определить политику безопасности, ассоциированную с предметом, получают зону безопасности, ассоциированную с предметом, и извлекают СУД (ACL’s), ассоциированные с этой зоной.

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

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

а) Создание нового предмета в контейнере

Когда предмет вновь создается в контейнере, он наследует все СУД (ACL’s), ассоциированные с контейнером. Так как вновь создаваемый предмет имеет только одного родителя, он принадлежит к той же зоне, что и его родитель. Таким образом, нет необходимости создавать новую запись в таблице защиты.

b) Добавление явного СУД (ACL) к предмету

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

Введение этой новой зоны безопасности может запускать дополнительные определения зоны для всех тех предметов, которые имеют множество Связей прикрепления с предшественниками, которые охватывают старую зону безопасности и вновь определенную зону безопасности. Для всех таких предметов необходимо определить новую зону безопасности и повторить процедуру.

Фиг.27(а), (b) и (с) изображают новую идентично защищенную зону безопасности, вырезаемую из существующей зоны безопасности посредством введения нового явного СУД (ACL). Это указано узлом, обозначенным 2. Однако введение этой новой зоны приводит к дополнительной зоне 3, создаваемой вследствие предмета, имеющего множество Связей прикрепления.

Следующая последовательность обновлений в таблицах защиты отражает разложение идентично защищенных зон безопасности.

с) Добавление связи прикрепления к предмету

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

d) Удаление связи прикрепления из предмета

Когда удаляется Связь прикрепления из предмета, можно свернуть зону безопасности до зоны его родителей, если удовлетворяются определенные условия. Более конкретно, это может быть выполнено при следующих условиях: (1) если удаление Связи прикрепления приводит к предмету, который имеет одного родителя, и явный СУД (ACL) не задан для этого предмета; (2) если удаление Связи прикрепления приводит к предмету, родители которого все находятся в одной и той же зоне безопасности, и явный СУД (ACL) не определен для этого предмета. При таких условиях зона безопасности может помечаться, что она такая же, что и у родителя. Эта отметка должна применяться ко всем предметам, зона безопасности которых соответствует сворачиваемой зоне.

е) Удаление явного СУД (ACL) из предмета

Когда из предмета удаляется явный СУД (ACL), можно свернуть зону безопасности с корнем в этом предмете до зоны его родителей. Более конкретно, это можно выполнить, если удаление явного СУД (ACL) приводит к предмету, родители которого в иерархии включения принадлежат к этой же зоне безопасности. При таких условиях зона безопасности может помечаться, что она такая же, что и у родителя, и изменение применяется ко всем предметам, зона безопасности которых соответствует сворачиваемой зоне.

f) Модифицирование СУД (ACL), ассоциированного с предметом

В этом сценарии не требуются новые дополнения к таблице защиты. Обновляется действующий СУД (ACL), ассоциированный с зоной, и новое изменение СУД (ACL) распространяется на зоны безопасности, на которые он оказывает влияние.

F. УВЕДОМЛЕНИЯ И ОТСЛЕЖИВАНИЕ ИЗМЕНЕНИЙ

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

Согласно одному варианту осуществления ИПП (API) 322 платформы хранения предоставляет два вида интерфейсов для уведомлений. Во-первых, приложения регистрируют простые события изменения данных, инициируемые изменениями в предметах, расширениях предметов и связях предметов. Во-вторых, приложения создают объекты «наблюдателей» для контролирования наборов предметов, расширений предметов и связей между предметами. Состояние объекта наблюдателя может сохраняться и создаваться заново после сбоя системы или после того, как система перешла в автономный режим для продолжительного периода времени. Единственное уведомление может отражать множество обновлений.

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

В данном разделе представлено несколько примеров того, как используются интерфейсы уведомлений, предоставляемые ИПП (API) 322 платформы хранения.

а) События

Item, ItemExtension и ItemRelationship раскрывают события изменения данных, которые используются приложениями для регистрации уведомлений об изменении данных. Следующий образец кода показывает определение обработчиков событий ItemModified и ItemRemoved по базовому классу Item.

public event ItemModifiedEventHandlerItem_ItemModified;

public event ItemRemovedEventHandlerItem_ItemRemoved;

Все уведомления несут достаточно данных для извлечения измененного предмета из хранилища данных. Следующий образец кода показывает, как регистрировать события на Item, ItemExtension или ItemRelationship:

myItem.ItemModified += new ItemModifiedEventHandler(this.onItemUpdate);

myItem.ItemRemoved += new ItemRemovedEventHandler(this.onItemDelete);

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

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

В настоящем варианте осуществления платформа хранения определяет классы наблюдателей для контролирования объектов, ассоциированных с (1) папкой или иерархией папок, (2) контекстом предмета или (3) конкретным предметом. Для каждой из трех категорий платформа хранения предоставляет конкретные классы наблюдателей, которые контролируют ассоциированные предметы, расширения предметов или связи предметов, например, платформа хранения обеспечивает соответствующие классы FolderItemWatcher, FolderRelationshipWatcher и FolderExtensionWatcher.

При создании наблюдателя приложение может запросить уведомления о предварительно существующих предметах, т.е. предметах, расширениях или связях. Этот вариант, главным образом, для приложений, которые сопровождают закрытый кэш предметов. Если не запрашивается, приложения принимают уведомления обо всех обновлениях, которые происходят после того, как был создан объект наблюдателя.

Вместе с доставкой уведомлений платформа хранения предоставляет объект «WatcherState». WatcherState может сериализоваться и сохраняться на диске. Состояние наблюдателя впоследствии может использоваться для повторного создания соответствующего наблюдателя после сбоя или при повторном соединении после перехода в автономный режим. Вновь повторно создаваемый наблюдатель будет повторно генерировать неподтвержденные уведомления. Приложения указывают доставку уведомления посредством вызова метода «Exclude» на соответствующее состояние наблюдателя, подавая ссылку на уведомление.

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

В качестве примера следующий образец кода показывает определение FolderItemWatcher.

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

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

Платформа хранения предоставляет простой, тем не менее, эффективный механизм для отслеживания изменений данных и генерирования уведомлений. Клиент извлекает уведомления по тому же соединению, что и используемое для извлечения данных. Это в значительной степени упрощает проверки системы безопасности (защиты), устраняет задержки и ограничения на возможные сетевые конфигурации. Уведомления извлекаются посредством вызова операторов выбора. Чтобы предотвратить опрос, клиенты могут использовать особенность «waitfor», предоставляемую процессором 314 базы данных. Фиг.13 изображает базовый принцип уведомлений платформы хранения. Этот запрос waitfor может исполняться синхронно, в этом случае вызывающий поток блокируется до тех пор, пока не будут доступны результаты, или асинхронно, в этом случае поток не блокируется, и результаты возвращаются по отдельному потоку, когда доступны.

Комбинация «waitfor» и «select» привлекательна для контролирования изменений данных, которые входят в конкретный диапазон данных, так как изменения могут контролироваться посредством установки блокировки уведомлений на соответствующий диапазон данных. Это справедливо для многих общих сценариев платформы хранения. Изменения индивидуальных предметов могут эффективно контролироваться посредством установки блокировок уведомлений на соответствующий диапазон данных. Изменения папок и деревьев папок могут контролироваться посредством установки блокировок уведомлений на диапазоны путей. Изменения типов и их подтипов могут контролироваться посредством установки блокировок уведомлений на диапазоны типов.

В общих чертах, существуют три отдельные фазы, связанные с обработкой уведомлений: (1) изменение или даже обнаружение данных, (2) соответствие подписки и (3) доставка уведомлений. Исключая синхронную доставку уведомлений, т.е. доставку уведомлений как часть транзакции, выполняющей изменение данных, платформа хранения может реализовывать две формы доставки уведомлений:

1) Немедленное обнаружение событий: Обнаружение событий и соответствие подписки выполняется как часть транзакции обновления. Уведомления вставляются в таблицу, контролируемую подписчиком; и

2) Отложенное обнаружение событий: Обнаружение событий и соответствие подписки выполняется после фиксации транзакции обновления. Впоследствии фактический подписчик или посредник обнаруживают события и генерируют уведомления.

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

Отложенное обнаружение событий устраняет необходимость добавления дополнительного кода к операциям обновления. Обнаружение событий выполняется окончательным подписчиком. Отложенное обнаружение событий естественно группирует обнаружение событий и доставку событий и хорошо подходит для инфраструктуры исполнения запросов процессора 314 базы данных (например, SQL Server).

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

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

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

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

Все определения предметов, расширений и связей предметов имеют уникальный идентификатор. Отслеживание изменений сопровождает набор логических временных меток для записи моментов времени создания, обновления и удаления для всех предметов данных. Записи объектов-памятников используются для представления удаленных предметов данных.

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

Все удаленные предметы, расширения предметов и связи записываются в соответствующую таблицу объектов-памятников. Шаблон показан ниже.

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

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

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

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

Фиг.14 изображает две транзакции, причем обе вставляют новую запись в одно и то же В-дерево. Так как транзакция Т3 вставляет свою запись до того, как планируется вставка транзакцией T2, приложение, сканирующее В-дерево, может видеть записи, вставленные транзакцией Т3, перед записями, вставленными транзакцией Т2. Таким образом, считыватель может неправильно предположить, что он видел все записи, созданные до момента времени «10». Чтобы решить этот вопрос, процессор 314 базы данных предусматривает функцию, которая возвращает низший предел, до которого все обновления были завершены и вставлены в соответствующие лежащие в основе структуры данных. В вышеприведенном примере возвращаемым низшим пределом был бы «5», предполагая, что считыватель начал до того, как была завершена транзакция Т2. Низший предел, предусмотренный процессором 314 базы данных, дает возможность приложениям эффективно определять, какие предметы игнорировать при сканировании базы данных или диапазона данных в отношении изменения данных. В общих чертах, предполагается, что транзакции атомарности, непротиворечивости, изоляции, надежности (АНИН; ACID), таким образом, продолжаются очень короткое время, низшие пределы, как ожидается, очень близки к наиболее недавним распределенным временным меткам. В присутствии длительно продолжающихся транзакций приложения должны сохранять индивидуальные временные метки для обнаружения и отбрасывания дубликатов.

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

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

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

G. СИНХРОНИЗАЦИЯ

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

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

Различные реплики могут выполнять изменения независимо (т.е. одновременно). Процесс синхронизации определяется как предоставление сведений каждой реплике об изменениях, сделанных другими репликами. Эта возможность синхронизации, по сути, является со многими ведущими.

Возможность синхронизации настоящего изобретения дает возможность репликам:

– определить, какие изменения известны другой реплике;

– запросить информацию об изменениях, которые не известны этой реплике;

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

– определить, когда два изменения находятся в конфликте друг с другом;

– применить изменения локально;

– передать разрешение конфликтов другим репликам для гарантии объединения; и

– разрешить конфликты, основываясь на заданных политиках для разрешения конфликтов.

1. Синхронизация платформы хранения с платформой хранения

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

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

Служба синхронизации, в основном, не признает границ транзакции. Другими словами, если два изменения выполняются в хранилище данных платформы хранения в одной транзакции, нет гарантии, что эти изменения будут применены ко всем другим репликам атомарным образом – одно может быть показано без другого. Исключением из этого принципа является то, что, если два изменения выполняются в одном Предмете в одной и той же транзакции, тогда гарантируется, что эти изменения будут посланы и применены к другим репликам атомарным образом. Таким образом, Предметы представляют собой единицы непротиворечивости службы синхронизации.

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

Любое приложение может подсоединиться к службе синхронизации и инициировать операцию синхронизации. Такое приложение предоставляет все параметры, необходимые для выполнения синхронизации (см. ниже профиль синхронизации). Такие приложения в данном документе упоминаются как Приложения управления синхронизацией (ПУС; SCAs).

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

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

b) Аннотирование схем

Фундаментальным понятием службы синхронизации является понятие Единицы Изменения. Единица Изменения представляет собой самую малую часть схемы, которая индивидуально отслеживается платформой хранения. Для каждой Единицы Изменения служба синхронизации может определять, изменилась ли она или не изменилась со времени последней синхронизации.

Обозначение Единиц Изменения в схеме служит нескольким целям. Во-первых, оно определяет, как часто служба синхронизации посылает сообщения. Когда выполняется изменение внутри Единицы Изменения, вся Единица Изменения посылается другим репликам, так как службе синхронизации не известно, какая часть Единицы Изменения была изменена. Во-вторых, оно определяет гранулярность обнаружения конфликтов. Когда два одновременных изменения (эти термины подробно определяются в последующих разделах) выполняются в одной единице изменения, служба синхронизации устанавливает конфликт; с другой стороны, если одновременные изменения выполняются в различных единицах изменения, тогда не устанавливается конфликт и изменения автоматически объединяются. В-третьих, оно оказывает сильное влияние на количество метаданных, сохраняемых системой. Большая часть метаданных службы синхронизации сохраняется на основе Единицы Изменения; таким образом, выполнение Единиц Изменения меньшими увеличивает служебные данные синхронизации.

Определение Единиц Изменения требует нахождения правильных компромиссов. По этой причине служба синхронизации дает возможность разработчикам схем участвовать в процессе.

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

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

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

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

Это понятие наилучшим образом иллюстрируется при помощи примера. Если Джо хочет держать папки My Documents своих нескольких компьютеров в синхронизме, Джо определяет папку сообщества, называемую, скажем, JoesDocuments. Затем на каждом компьютере Джо конфигурирует отображение между гипотетической папкой JoesDocuments и локальной папкой My Documents. С этого момента, когда компьютеры Джо синхронизируются друг с другом, они общаются на языке документов в JoesDocuments, а не их локальных предметов. Таким образом, все компьютеры Джо понимают друг друга без необходимости иметь сведения, кем являются другие, – Папка Сообщества становится лингва-франка (общепринятым языком) сообщества синхронизации.

Конфигурирование службы синхронизации состоит из трех этапов: (1) определения отображений между локальными папками и папками сообщества; (2) определения профилей синхронизации, которые определяют, что синхронизируется (например, с кем синхронизироваться и какие поднаборы должны посылаться и какие – приниматься); и (3) определения расписаний, по которым должны выполняться различные профили синхронизации или выполнять их вручную.

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

Отображения Папки Сообщества хранятся в виде файлов конфигурации РЯР (XML) на индивидуальных машинах. Каждое отображение имеет следующие схемы:

/mappings/communityFolder

Этот элемент именует папку сообщества, для которой предназначено это отображение. Имя придерживается правил синтаксиса Папок.

/mappings/localFolder

Этот элемент именует локальную папку, в которую преобразуется отображение. Имя придерживается правил синтаксиса Папок. Папка должна уже существовать, чтобы отображение было действительным. Предметы в этой папке рассматриваются для синхронизации на это отображение.

/mappings/transformations

Этот элемент определяет, как преобразовывать предметы из папки сообщества в локальную папку и обратно. Если отсутствует или пустая, не выполняется преобразование. В частности, это означает, что не отображаются ИД (ID). Эта конфигурация используется, главным образом, для создания кэша Папки.

/mappings/transformations/mapIDs

Этот элемент запрашивает, чтобы вновь генерируемые локальные ИД (ID) присваивались всем предметам, отображаемым из папки сообщества, а не повторно использовать ИД (ID) сообщества. Период выполнения Синхронизации сохраняет отображения ИД (ID) для преобразования предметов туда и обратно.

/mappings/transformations/localRoot

Этот элемент запрашивает, чтобы все корневые предметы в папке сообщества были сделаны дочерними заданного корня.

/mappings/runAs

Этот элемент управляет, под чьими полномочиями обрабатываются запросы в отношении этого отображения. Если отсутствуют, предполагается отправитель.

/mappings/runAs/sender

Присутствие этого элемента указывает на то, что должен имитироваться отправитель сообщений для этого отображения, и запросы должны обрабатываться под его параметрами доступа.

(2) Профили

Профиль синхронизации представляет собой полный набор параметров, необходимых для запуска синхронизации. Он поставляется посредством ПУС (SCA) Периоду выполнения Синхронизации для инициирования синхронизации. Профили синхронизации для синхронизации платформы хранения с платформой хранения содержат следующую информацию:

– Локальную Папку, служащую в качестве источника и назначения для изменений;

– Имя Удаленной папки для синхронизации с ней – эта Папка должна быть опубликована от удаленного партнера посредством отображения, как определено выше;

– Направление – служба синхронизации поддерживает синхронизацию только в режиме отправки, только в режиме приема и в режиме отправки-приема;

– Локальный Фильтр – выбирает, какую локальную информацию посылать удаленному партнеру. Выражается как запрос платформы хранения по локальной папке;

– Удаленный Фильтр – выбирает, какую удаленную информацию извлекать из удаленного партнера – выражается как запрос платформы хранения по папке сообщества;

– Преобразования – определяют, как преобразовывать предметы в локальный формат и из него;

– Локальная защита – задает, должны ли изменения, извлекаемые из удаленной конечной точки, применяться при разрешениях удаленной конечной точки (имитированной) или пользователя, инициирующего синхронизацию локально; и

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

Служба синхронизации предусматривает класс ОЯСВ (CLR) периода выполнения, который позволяет выполнять простое построение Профилей Синхронизации. Профили также могут сериализоваться в файлы РЯР (XML) и из них для легкого хранения (часто вместе с расписаниями). Однако нет стандартного места в платформе хранения, где хранятся все профили; ПУС (SCAs) имеют право создавать профиль на месте даже без обеспечения его постоянства. Следует отметить, что нет необходимости иметь локальное отображение для инициирования синхронизации. Вся информация о синхронизации может задаваться в профиле. Отображение, однако, требуется для того, чтобы отвечать на запросы синхронизации, инициируемые удаленной стороной.

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

В одном варианте осуществления служба синхронизации не обеспечивает свою собственную инфраструктуру планирования. Вместо этого она основывается на том, что другой компонент выполняет эту задачу – Windows Scheduler, имеющийся в операционной системе Microsoft Windows. Служба синхронизации включает в себя утилиту, работающую в режиме командной строки, которая действует в качестве ПУС (SCA), и запускает синхронизацию, основываясь на профиле синхронизации, сохраненном в РЯР (XML)-файле. Эта утилита делает очень легким конфигурирование Windows Scheduler для выполнения синхронизации или по расписанию, или в ответ на события, такие как вход пользователя в систему или выход его из системы.

d) Оперирование конфликтами

Оперирование конфликтами в службе синхронизации делится на три этапа: (1) обнаружение конфликтов, которое происходит в момент времени применения изменений, – этот этап определяет, может ли изменение безопасно быть применено; (2) автоматическое разрешение и регистрация конфликтов – во время этого этапа (который происходит непосредственно после обнаружения конфликта) обращаются к средствам автоматического разрешения конфликтов, чтобы выяснить, может ли быть разрешен конфликт – если нет, конфликт может быть, необязательно, зарегистрирован; и (3) инспектирование и разрешение конфликтов – этот этап имеет место, если были зарегистрированы некоторые конфликты, и происходит вне контекста сеанса синхронизации – в этот момент времени зарегистрированные конфликты могут разрешаться и удаляться из журнала.

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

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

(а) Основанные на сведениях конфликты

Основанные на сведениях конфликты происходят тогда, когда две реплики выполняют независимые изменения в одной и той же Единице Изменений. Два изменения называются независимыми, если они выполняются без сведений друг о друге, другими словами, версия первого не охватывается сведениями о втором, и наоборот. Служба синхронизации автоматически обнаруживает все такие конфликты, основанные на сведениях реплик, как описано выше.

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

(b) Основанные на ограничениях конфликты

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

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

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

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

Когда обнаруживается конфликт, служба синхронизации может предпринять одно из трех действий (выбираемых инициатором синхронизации в Профиле Синхронизации): (1) отклонить изменение, возвращая его отправителю; (2) зарегистрировать конфликт в журнале конфликтов; или (3) автоматически разрешить конфликт.

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

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

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

Служба синхронизации предусматривает ряд средств разрешения конфликтов по умолчанию. Этот список включает в себя:

– локальные выигрыши: игнорировать поступающие изменения, если они в конфликте с локально хранимыми данными;

– удаленные выигрыши: игнорировать локальные данные, если они в конфликте с поступающими изменениями;

– выигрыши последнего автора: выбор или локальных выигрышей, или удаленных выигрышей на единицу изменений, основываясь на временной метке изменения (отметьте, что служба синхронизации, в основном, не полагается на значения часов; это средство разрешения конфликтов является единственным исключением для этого правила);

– детерминированный: выбор выигрывающего так, чтобы гарантировать, что он является одинаковым на всех репликах, но не значащий в других отношениях – один вариант осуществления служб синхронизации использует лексикографические сравнения ИД (ID) партнеров для реализации этой особенности.

Кроме того, НППО (ISV) может реализовывать и устанавливать свои собственные средства разрешения конфликтов. Специализированные средства разрешения конфликтов могут принимать конфигурационные параметры; такие параметры должны задаваться посредством ПУС (SCA) в разделе Разрешение Конфликтов Профиля Синхронизации.

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

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

При рассматривании конфликтов в качестве ветвей в предыстории версий предмета разрешения конфликтов могут рассматриваться как соединения, объединяющие две ветви для образования одной точки. Таким образом, разрешения конфликтов превращают предыстории версий в ОАГ (DAGs).

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

Очень частным видом механизма разрешения конфликтов является Регистратор Конфликтов. Служба синхронизации регистрирует конфликты в качестве Предметов типа ConflictRecord. Эти записи ссылаются обратно на предметы, которые находятся в конфликте (если только сами предметы не были удалены). Каждая запись конфликта содержит поступающее изменение, которое вызвало конфликт; тип конфликта: обновление-обновление, обновление-удаление, удаление-обновление, вставка-вставка или ограничение; и версию поступающего изменения и сведения реплики, посылающей его. Зарегистрированные конфликты доступны для инспектирования и разрешения, как описано ниже.

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

Служба синхронизации предусматривает ИПП (API) для приложений для проверки журнала конфликтов и предложения разрешений конфликтов в нем. ИПП (API) дает возможность приложению перечислять все конфликты или конфликты, относящиеся к данному Предмету. Он также дает возможность таким приложениям разрешать зарегистрированные конфликты одним из трех путей: (1) удаленные выигрыши – принимая зарегистрированное изменение и перезаписывая конфликтующее локальное изменение; (2) локальные выигрыши – игнорируя конфликтующие части зарегистрированного изменения; и (3) предложить новое изменение – где приложение предлагает объединение, которое, по его мнению, разрешает конфликт. Если конфликты разрешены приложением, служба синхронизации удаляет их из журнала.

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

В сложных сценариях синхронизации один и тот же конфликт может обнаруживаться на множестве реплик. Если это происходит, могут произойти следующие вещи: (1) конфликт может быть разрешен на одной реплике, и разрешение может быть послано другой; (2) конфликт автоматически разрешается на обеих репликах; или (3) конфликт разрешается вручную на обеих репликах (посредством ИПП (API) инспектирования конфликтов).

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

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

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

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

Согласно другому аспекту платформы хранения настоящего изобретения, платформа хранения обеспечивает архитектуру, чтобы НППО (ISVs) реализовали Адаптеры Синхронизации, которые дают возможность синхронизации платформы хранения с унаследованными системами, такими как Microsoft Exchange, AD (Active Directory), Hotmail и др. Адаптеры Синхронизации имеют преимущества по сравнению с многими Службами Синхронизации, предусматриваемыми службой синхронизации, как описано ниже.

Несмотря на название, нет необходимости реализовывать Адаптеры Синхронизации в виде дополнительных программных модулей для некоторой архитектуры платформы хранения. Если требуется, «адаптером синхронизации» просто может быть любое приложение, которое использует интерфейсы рабочей среды службы синхронизации для получения служб, таких как перечисление и применение изменений.

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

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

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

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

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

Изменения перечисляются, основываясь на принципе «точки привязки» – непрозрачной структуры, которая представляет информацию о последней синхронизации. Привязка принимает вид Сведений платформы хранения, как описано в предыдущих разделах. Адаптеры Синхронизации, использующие службы перечисления изменений, делятся на две большие категории: те, которые используют «хранимые привязки», в сравнении с теми, которые используют «поставляемые привязки».

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

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

Часто Адаптерам необходимо хранить характерные для адаптеров данные вместе с предметами, которые они вставляют в хранилище данных платформы хранения. Общими примерами таких данных являются удаленные ИД (ID) и удаленные версии (временные метки). Служба синхронизации предоставляет механизм для хранения этих данных, и Перечисление Изменений предоставляет механизм для приема этих дополнительных данных вместе с возвращаемыми изменениями. Это в большинстве случаев устраняет необходимость для адаптеров повторно запрашивать базу данных.

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

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

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

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

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

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

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

3. Защита

Служба синхронизации старается вносить минимально возможное в модель защиты, реализуемую платформой хранения. Чем определять новые права для синхронизации, используются существующие права. Конкретно,

– любой, кто может прочитать Предмет хранилища данных, может перечислить изменения для этого предмета;

– любой, кто может записать в Предмет хранилища данных, может применить изменения к этому предмету; и

– любой, кто может расширить Предмет хранилища данных, может ассоциировать метаданные синхронизации с этим предметом.

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

Когда инициируется служба синхронизации, она выполняется Приложением Управления Синхронизацией. Служба синхронизации имитирует идентификацию ПУС (SCA) и выполняет все операции (как локальные, так и удаленные) под этой идентификацией. Для иллюстрации отметьте, что пользователь U не может инициировать извлечение локальной службой синхронизации изменений из удаленной платформы хранения для предметов, к которым у пользователя U нет доступа для чтения.

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

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

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

H. ВОЗМОЖНОСТЬ ВЗАИМОДЕЙСТВИЯ С ТРАДИЦИОННЫМИ ФАЙЛОВЫМИ СИСТЕМАМИ

Как упомянуто выше, платформа хранения настоящего изобретения, по меньшей мере в некоторых вариантах осуществления, предназначена для реализации в виде интегральной части аппаратной/программной интерфейсной системы компьютерной системы. Например, платформа хранения настоящего изобретения может быть реализована в виде интегральной части операционной системы, такой как семейство операционных систем Microsoft Windows. При такой возможности ИПП (API) платформы хранения становится частью ИПП (API) операционной системы, посредством которых программы приложений взаимодействуют с операционной системой. Таким образом, платформа хранения становится средством, посредством которого программы приложений хранят информацию об операционной системе, и основанная на Предметах модель данных платформы хранения поэтому заменяет традиционную файловую систему такой операционной системы. Например, как реализовано в семействе операционных систем Microsoft Windows, платформа хранения может заменять файловую систему ФСНТ (NTFS), реализованную в этой операционной системе. В настоящее время программы приложений обращаются к службам файловой системы ФСНТ (NTFS) при помощи ИПП (API’s) Win32, раскрываемых семейством операционных систем Windows.

Признавая, однако, что полная замена файловой системы ФСНТ (NTFS) платформой хранения настоящего изобретения потребовала бы запись существующих, основанных на Win32 программ приложений, и такая запись может быть нежелательной, было бы полезным, чтобы платформа хранения настоящего изобретения обеспечивала некоторую возможность взаимодействия с существующими файловыми системами, такими как ФСНТ (NTFS). В одном варианте осуществления настоящего изобретения поэтому платформа хранения дает возможность программам приложений, которые основываются на модели программирования Win32, обращаться к содержимому хранилища данных платформы хранения, а также к традиционной файловой системе ФСНТ (NTFS). С этой целью платформа хранения использует соглашение об именовании, которое представляет собой поднабор соглашений об именовании Win32, чтобы способствовать легкой возможности взаимодействия. Далее, платформа хранения поддерживает обращение к файлам и каталогам, хранимым на томе платформы хранения, при помощи ИПП (API) Win32.

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

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

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

2. Так как и файловые, и нефайловые предметы являются доступными с использованием ИПП (API’s) платформы хранения и в этом подходе для файлов не налагаются специальные правила, она представляет более безошибочную модель программирования для работы с ней разработчиков приложений.

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

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

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

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

Чтобы обеспечить требуемый уровень возможности взаимодействия, в одном варианте осуществления реализуются следующие особенности хранилища данных платформы хранения.

а) Не том

Хранилище данных платформы хранения не раскрывается в качестве отдельного тома файловой системы. Платформа хранения на новом уровне использует FILESTREAMы, непосредственно хостируемые на ФСНТ (NTFS). Таким образом, нет изменения формата на диске, тем самым устраняется любая необходимость раскрытия платформы хранения в качестве новой файловой системы на уровне тома.

Вместо этого, хранилище данных (пространство имен) формируется в соответствии с томом ФСНТ (NTFS). База данных и FILESTREAMы, поддерживающие эту часть пространства имен, располагаются на томе ФСНТ (NTFS), с которым ассоциируется хранилище данных платформы хранения. Также предусматривается хранилище данных, соответствующее системному тому.

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

Структура хранилища наилучшим образом иллюстрируется примером. Рассмотрим в качестве примера дерево каталогов на системном томе машины, названной HomeMachine

В данном варианте осуществления файлы и/или папки должны явно мигрировать (переноситься) с ФСНТ (NTFS) на платформу хранения. Поэтому, если пользователь желает переместить папку My Document в хранилище данных платформы хранения, чтобы он воспользовался всеми дополнительными особенностями поиска/категоризации, предлагаемыми платформой хранения, иерархия будет выглядеть такой, как показано на фиг.17. Важно отметить, что эти папки фактически перемещаются в этом примере. Другим вопросом, который следует отметить, является то, что пространство имен перемещается в платформу хранения, фактические потоки переименовываются как FILESTREAMы с соответствующими указателями, подключаемыми в платформе хранения.

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

Файлы, которые соответствуют пользовательским данным или которые требуют поиска/категоризации, которые предоставляет платформа хранения, являются кандидатами на миграцию в хранилище данных платформы хранения. Предпочтительно, что, чтобы ограничить вопросы совместимости программ приложений с платформой хранения, набор файлов, которые мигрируют в платформу хранения настоящего изобретения, в контексте операционной системы Microsoft Windows, ограничиваются файлами в папке MyDocuments, папке Favorites в Internet Explorer (IE), папке History в IE и файлами .ini в Desktop в папке Documents and Settings. Предпочтительно, что не разрешается миграция системных файлов Windows.

d) Доступ пространства имен ФСНТ (NTFS) к файлам платформы хранения

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

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

. Для класса приложений, которые требуют буквы накопителей для работы, буква накопителя может отображаться на это имя УСИ (UNC).

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

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

Фиг.19 изображает базовую архитектуру ИПП (API) платформы хранения согласно настоящему варианту осуществления. ИПП (API) платформы хранения использует SQLClient 1900 для взаимодействия с локальным хранилищем 302 данных и также может использовать SQLClient 1900 для взаимодействия с удаленными хранилищами данных (например, хранилищем 340 данных). Локальное хранилище 302 также может взаимодействовать с удаленным хранилищем 340 данных с использованием или Распределенного процессора запросов (РПЗ; DQP), или при помощи службы синхронизации платформы хранения, описанной выше. ИПП (API) 322 платформы хранения также служит в качестве ИПП (API) моста для уведомлений хранилища данных, передачи подписок приложений средству обработки 332 уведомлений и маршрутизации уведомлений к приложению (например, приложению 350а, 350b или 350с), что также описано выше. В одном варианте осуществления ИПП (API) 322 платформы хранения также может определять ограниченную архитектуру «поставщика», так что он может обращаться к данным в Microsoft Exchange и AD.

1. Обзор

Механизм доступа к данным настоящего варианта осуществления ИПП (API) платформы хранения настоящего изобретения касается четырех областей: запрос, навигация, действия, события.

Запрос

В одном варианте осуществления хранилище данных платформы хранения реализуется на процессоре 314 реляционной базы данных; как результат, полностью выразительная сила языка ЯСЗ (SQL) присуща платформе хранения. Объекты запроса более высокого уровня обеспечивают упрощенную модель для запроса хранилища, но не могут инкапсулировать полную выразительную силу хранения.

Навигация

Модель данных платформы хранения строит систему с широкими возможностями и расширяемого типа на абстракциях лежащей в основе базы данных. Для разработчика данные платформы хранения представляют собой сеть предметов. ИПП (API) платформы хранения позволяет выполнять навигацию от предмета к предмету при помощи фильтрации, связей, папок и т.д. Это является более высоким уровнем абстракции, чем базовые запросы ЯСЗ (SQL); одновременно, это позволяет использовать мощные возможности фильтрации и навигации с хорошо известными шаблонами кодирования ОЯСВ (CLR).

Действия

ИПП (API) платформы хранения раскрывает общие действия над всеми предметами – Create, Delete, Update; они раскрываются в виде методов объектов. Кроме того, характерные для домена действия, такие как SendMail, CheckFreeBusy и т.д., также доступны как методы. Интегрированная среда ИПП (API) использует четко определенные шаблоны, которые НППО (ISV’s) могут использовать для добавления возможностей посредством определения дополнительных действий.

События

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

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

Полезно указать отличие между пространством имен и именованием. Термин пространство имен, как он широко используется, ссылается на множество всех имен, доступных в некоторой системе. Системой может быть схема РЯР (XML), программа, Всемирная паутина, множество всех сайтов ftp (и их содержимого) и т.д. Именование представляет собой процесс или алгоритм, используемый для присвоения уникальных имен всем сущностям, представляющим интерес, в пространстве имен. Таким образом, именование представляет интерес, так как желательно однозначно ссылаться на данную единицу в пространстве имен. Таким образом, термин «пространство имен» в том виде, как он используется в данном документе, ссылается на множество всех имен, доступных во всех экземплярах платформы хранения в универсуме. Предметы представляют собой именованные сущности в пространстве имен платформы хранения. Соглашение об именовании УСИ (UNC) используется для гарантии единственности имен предметов. Каждый предмет в каждом хранилище платформы хранения в универсуме является адресуемым по имени УСИ (UNC).

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

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

Ссылаясь на фиг.18, Папка Включения представляет собой предмет, который содержит Связи прикрепления к другим Предметам и эквивалентен общему принципу папки файловой системы. Каждый Предмет «включается» по меньшей мере в одну папку включения.

Виртуальная Папка представляет собой более динамичный путь организации коллекции Предметов; это просто имя, данное набору Предметов – набор или перечисляется явно, или задается по запросу. Виртуальная Папка сама представляет собой Предмет и может рассматриваться как представляющая набор Связей (не прикрепления) к набору Предметов.

Иногда существует необходимость моделирования более сжатого представления включения; например, документ Word, внедренный в сообщение электронной почты, в известном смысле, привязывается более плотно к своему контейнеру, чем, например, файл, содержащийся в папке. Это представление выражается принципом Внедренных Предметов. Внедренный Предмет имеет специальный вид связи, которая ссылается на другой Предмет; ссылаемый Предмет может привязываться или иным образом подвергаться манипуляции только в пределах контекста включающего Предмета.

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

Однозначное имя для данного предмета представляет собой тройку: (, , ). Некоторые предметы (конкретно, Folder и VirtualFolder) представляют собой коллекции других предметов. Это приводит к альтернативному способу идентификации предметов: (, , ).

Имена платформы хранения включают в себя понятие контекста службы: контекст службы представляет собой имя, которое отображается на пару (, ). Оно идентифицирует предмет или набор предметов – например, папку, виртуальную папку и т.д. С принципом контекста службы именем УСИ (UNC) для любого предмета в пространстве имен платформы хранения становится:

Пользователи могут создавать и удалять контексты службы. Также, корневой каталог в каждом томе имеет предварительно определенный контекст: volume-name$.

ItemContext оценивает запрос (например, операцию Find) посредством ограничения результатов, возвращаемых тем Предметам, которые находятся на заданном пути.

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

Фиг.20 схематически представляет различные компоненты ИПП (API) платформы хранения согласно настоящему варианту осуществления изобретения. ИПП (API) платформы хранения состоит из следующих компонентов: (1) классов 2002 данных, которые представляют типы элементов и предметов платформы хранения, (2) интегрированной среды 2004 выполнения, которая управляет обеспечением постоянства объекта и предусматривает классы 2006 поддержки; и (3) инструментальных средств 2008, которые используются для генерирования классов ОЯСВ (CLR) из схем платформы хранения.

Согласно одному аспекту настоящего изобретения в течение периода проектирования автор схемы подает документ 2010 схемы и код для методов 2012 домена набору инструментальных средств 2008 периода проектирования ИПП (API) платформы хранения. Эти инструментальные средства генерируют классы 2002 данных на стороне клиента и схему 2014 хранилища и определения 2016 классов хранилища для этой схемы. «Домен» относится к конкретной схеме; например, изобретатели говорят о методах домена для классов в схеме Контактов и т.д. Эти классы 2002 данных используются во время прогона разработчиком приложения во взаимодействии с классами 2006 интегрированной среды выполнения ИПП (API) платформы хранения для манипулирования данными платформы хранения.

С целью иллюстрации различных аспектов ИПП (API) платформы хранения настоящего изобретения представляются примеры, основанные на примерной схеме Контактов. Графическое представление этой примерной схемы иллюстрируется на фиг.21А и 21В.

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

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

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

Для каждой схемы S:

Для каждого Предмета I в S генерируется класс, названный System.Storage.S.I. Этот класс имеет следующие члены:

– Перегруженные конструкторы, включающие в себя конструкторы, которые дают возможность задавать первоначальные папку и имя нового предмета.

– Свойство для каждого поля в I. Если поле является многозначным, свойство будет представлять собой коллекцию соответствующего типа Element.

– Перегруженный статический метод, который находит множество предметов, соответствующих фильтру (например, метод, названный «FindAll»).

– Перегруженный статический метод, который находит единственный предмет, соответствующий фильтру (например, метод, названный «FindOne»).

– Статический метод, который находит предмет по его ИД (ID) (например, метод, названный «FindByID»).

– Статический метод, который находит предмет по его имени относительно ItemContext (например, метод, названный «FindByName»).

– Метод, который сохраняет изменения в предмете (например, метод, названный «Update»).

– Перегруженные статические методы Create, которые создают новые экземпляры предмета. Эти методы позволяют различным образом задавать первоначальную папку предмета.

Для каждого Элемента Е в S генерируется класс, названный System.Storage.S.E. Этот класс имеет следующие члены:

– Свойство для каждого поля в Е. Если поле является многозначным, свойство будет коллекцией соответствующих типов Element.

Для каждого Элемента Е в S генерируется класс, названный System.Storage.S.ECollection. Этот класс придерживается общих директив .NET Framework для сильно типизированных классов коллекций. Для основанных на Связях типов элементов этот класс также будет включать в себя следующие члены:

– Перегруженный метод, который находит множество объектов Item, которые соответствуют фильтру, который неявно включает в себя предмет, в котором коллекция проявляется в роли источника. Перегрузки включают в себя некоторые, которые позволяют выполнять фильтрацию, основанную на подтипе Item (например, метод, названный «FindAllTargetItems»).

– Перегруженный метод, который находит единственный объект Item, который соответствует фильтру, который неявно включает в себя предмет, в котором коллекция проявляется в роли источника. Перегрузки включают в себя некоторые, которые позволяют выполнять фильтрацию, основанную на подтипе Item (например, метод, названный «FindOneTargetItem»).

– Перегруженный метод, который находит объекты типа вложенного элемента, который соответствует фильтру, который неявно включает в себя предмет, в котором коллекция проявляется в роли источника (например, метод, названный «FindAllRelationships»).

– Перегруженный метод, который находит объекты типа вложенного элемента, который соответствует фильтру, который неявно включает в себя предмет, в котором коллекция проявляется в роли источника (например, метод, названный «FindAllRelationshipsForTarget»).

– Перегруженный метод, который находит единственный объект типа вложенного элемента, который соответствует фильтру, который неявно включает в себя предмет, в котором коллекция проявляется в роли источника (например, метод, названный «FindOneRelationship»).

– Перегруженный метод, который находит единственный объект типа вложенного элемента, который соответствует фильтру, который неявно включает в себя предмет, в котором коллекция проявляется в роли источника (например, метод, названный «FindOneRelationshipForTarget»).

Для Связи R в S генерируется класс, названный System.Storage.S.R. Этот класс имеет один или два подкласса, зависящие от того, задает ли одна или обе роли связи поле конечной точки.

Классы также генерируются таким же образом для каждого Расширения Предмета, который был создан.

Классы данных существуют в пространстве имен System.Storage.<Имясхемы>, где <Имясхемы> представляет собой имя соответствующей схемы, такой как Контакты, Файлы и т.д. Например, все классы, соответствующие схеме Контакты, находятся в пространстве имен System.Storage.Contacts.

В качестве примера, со ссылкой на фиг.21А и 21В, схема контактов приводит к следующим классам, содержащимся в пространстве имен System.Storage.Contact:

– Предметы: Item, Folder, WellKnownFolder, LocalMachineDataFolder, UserDataFolder, Principal, Service, GroupService, PersonService, PresenceService, ContactService, ADService, Person, User, Group, Organization, HouseHold

– Элементы: NestedElementBase, NestedElement, IdentityKey, SecurityID, EAddress, ContactEAddress, TelehoneNumber, SMTPEAddress, InstantMessagingAddress, Template, Profile, FullName, FamilyEvent, BasicPresence, WindowsPresence, Relationship, TemplateRelationship, LocationRelationship, FamilyEventLocationRelationship, HouseHoldLocationRelationship, RoleOccupancy, EmployeeData, GroupMemberShip, OrganizationLocationRelationship, HouseHoldMemberData, FamilyData, SpouseData, ChildData

В качестве другого примера подробная структура типа Person, как определено в схеме Contacts, показана в РЯР (XML) ниже:

ExtendsType=”Core.Principal” ExtendsVersion=”1″>

Nullable=”true” TypeMajorVersion=”1″/>

Nullable=”true” MultiValued=”false”

TypeMajorVersion=”l”/>

Nullable=”true” MultiValued=”true”

TypeMajorVersion=”1″/>

Nullable=”true” MultiValued=”true”

TypeMajorVersion=”1″/>

Type=”Core.PostalAddress” Nullable=”true”

MultiValued=”true” TypeMajorVersion=”1″/>

Nullable=”true” TypeMajorVersion=”1″/>

MultiValued=”true” TypeMajorVersion=”1″/>

Nullable=”true” MultiValued=”true”

TypeMajorVersion=”1″/>

Nullable=”true” MultiValued=”true”

TypeMajorVersion=”1″/>

Nullable=”true” TypeMajorVersion=”1″/>

Nullable=”true” TypeMajorVersion=”1″/>

Nullable=”true” MultiValued=”true”

TypeMajorVersion=”1″/>

Этот тип приводит к следующему классу (показаны только открытые члены):

partial public class Person :

System.Storage.Core.Principal,

System.Windows.Data.IDataUnit

{

public System.Data.SqlTypes.SqlDateTime

Birthdate { get; set; }

public System.Storage.Base.CategoryRef

Gender { get; set: )

public System.Storage.Contact.FullNameCollection

PersonalNames { get; }

public System.Storage.Core.EAddressCollection

PersonalEAddresses { get; }

public System.Storage.Core.PostalAddressCollection

PersonalPostalAddresses { get; }

public System.Data.SqlTypes.SqlBinary

PersonalPicture { get; set; }

public System.Storage.Core.RichTextCollection

Notes { get; }

public System.Storage.Base.CategoryRefCollection

Profession { get; }

public System.Storage.Base.IdentityKeyCollection

DataSource { get; }

public System.Data.SqlTypes.SqlDateTime

ExpirationDate { get; set; }

public System.Data.SqlTypes.SqlBoolean

HasAllAddressBookData { get; set; }

public System.Storage.Contact.EmployeeDataCollection

EmployeeOf { get; }

public Person();

public Person( System.Storage.Base.Folder folder, string name );

public static new System.Storage.FindResult

FindAll( System.Storage.ItemStore store);

public static new System.Storage.FindResult

FindAll(

System.Storage.ItemStore store,

string filter );

public static new Person

FindOne(

System.Storage.ItemStore store,

string filter );

public new event

System.Windows.Data.PropertyChangedEventHandler

PropertyChangedHandler;

public static new Person

FindByID(

System.Storage.ItemStore store,

long item_key );

}

В качестве еще другого примера подробная структура типа TelephoneNumber, как определено в схеме Contacts, показана в РЯР (XML) ниже:

MajorVersion=”1″ MinorVersion=”0″ ExtendsVersion=”1″>

Nullable=”true” MultiValued=”false”

TypeMajorVersion=”1″/>

Nullable=”true” TypeMajorVersion=”1″/>

Nullable=”true” TypeMajorVersion=”1″/>

Nullable=”true” TypeMajorVersion=”1″/>

Nullable=”true” TypeMajorVersion=”1″/>

Этот тип приводит к следующему классу (показаны только открытые члены):

partial public class TelephoneNumber:

System.Storage.Core.EAddress,

System.Windows.Data.IDataUnit

{

public System.Data.SqlTypes.SqlString CountryCode

{ get; set; }

public System.Data.SqlTypes.SqlString AreaCode

{ get; set; }

public System.Data.SqlTypes.SqlString Number

{ get; set; }

public System.Data.SqlTypes.SqlString Extension

{ get; set; }

public System.Data.SqlTypes.SqlString PIN

{ get; set; }

public TelephoneNumber();

public new event

System.Windows.Data.PropertyChangedEventHandler

PropertyChangedHandler;

}

Иерархия классов, являющаяся следствием данной схемы, прямо отражает иерархию типов в этой схеме. В качестве примера рассмотрим типы Item, определенные в схеме Contact (см. фиг.21А и 21В). Иерархия классов, соответствующая этому в ИПП (API) платформы хранения, будет следующей:

Object

DataClass

ElementBase

RootItemBase

Item

Principal

Group

Household

Organization

Person

User

Service

PresenceService

ContactService

ADService

RootNestedBase

(Классы Element)

Еще другая схема, схема, которая дает возможность представлять все носители аудио/видео в системе (конвертированные звуковые файлы, звуковые компакт-диски, цифровые многофункциональные диски (ЦМД; DVD), домашнее видео и т.д.), позволяет пользователям/приложениям хранить, организовывать, выполнять поиск и манипулировать различными видами носителей аудио/видео. Базовая схема документов носителей является достаточно обобщенной, чтобы представлять любые носители, и расширения для этой базовой схемы предназначены для оперирования характерными для домена свойствами отдельно для носителей аудио и видео. Эта схема, и многие, многие другие, как предполагается, работают прямо или косвенно под Основной схемой.

5. Интегрированная среда выполнения

Базовая модель программирования ИПП (API) платформы хранения представляет собой персистентность (постоянство) объектов. Программы приложений (или «приложения») выполняют поиск в хранилище и извлекают объекты, представляющие данные в хранилище. Приложения модифицируют извлекаемые объекты или создают новые объекты, затем вызывают распространение этих изменений в хранилище. Этот процесс управляется объектом ItemContext. Поиски исполняются с использованием объекта ItemSearcher, и результаты поиска являются доступными при помощи объекта FindResult.

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

Согласно другому обладающему признаками изобретения аспекту ИПП (API) платформы хранения интегрированная среда выполнения реализует ряд классов для поддержки работы классов данных. Эти классы интегрированной среды определяют общий набор методов поведения для классов данных и вместе с классами данных обеспечивают базовую модель программирования для ИПП (API) платформы хранения. Классы в интегрированной среде выполнения принадлежат пространству имен System.Storage. В настоящем варианте осуществления классы интегрированной среды содержат следующие основные классы: ItemContext, ItemSearcher и FindResult. Также могут предусматриваться другие второстепенные классы, значения перечисления и делегаты.

(1) ItemContext

Объект ItemContext (i) представляет набор доменов предмета, в котором программа приложения хочет выполнить поиск, (ii) поддерживает информацию о состоянии для каждого объекта, который представляет состояние данных, извлекаемых из платформы хранения, и (iii) управляет транзакциями, используемыми при взаимодействии с платформой хранения и любой файловой системой, с которой может взаимодействовать платформа хранения.

В качестве процессора постоянства объектов ItemContext предусматривает следующие службы:

1. Десериализует данные, считанные из хранилища, в объекты.

2. Сопровождает идентификацию объекта (один и тот же объект используется для представления данного предмета независимо от того, сколько раз этот предмет был включен в результат запросов).

3. Отслеживает состояние объекта.

ItemContext также выполняет ряд служб, уникальных для платформы хранения:

1. Генерирует и исполняет операции updategram платформы хранения, необходимые для обеспечения постоянства изменений.

2. Создает соединения с множеством хранилищ данных, необходимых для осуществления прямой навигации по связям ссылок и для модифицирования и сохранения объектов, извлеченных из многодоменного поиска.

3. Обеспечивает, что поддерживаемые файлами предметы правильно обновляются, когда сохраняются изменения в объекте (объектах), представляющем этот предмет.

4. Управляет транзакциями по множеству соединений платформы хранения и, когда выполняется обновление данных, хранимых в поддерживаемых файлами предметах и свойствах файловых потоков, транзакционной файловой системы.

5. Выполняет операции создания, копирования, перемещения и удаления предметов, которые учитывают семантику связей платформы хранения, поддерживаемые файлами предметы и типизированные свойства потоков.

В Приложении А представлен листинг исходного кода класса ItemContext согласно одному варианту осуществления.

(2) ItemSearcher

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

(а) Тип цели

Тип цели поиска устанавливается при построении ItemSearcher. Типом цели является тип ОЯСВ (CLR), который отображается на запрашиваемый экстент хранилищем данных. Конкретно, именно тип ОЯСВ (CLR) отображается на тип предмета, связи и расширение предмета, а также схематизированные представления.

При извлечении искателя, используя метод ItemContext.GetSearcher, тип цели искателя задается в качестве параметра. Когда статический метод GetSearcher вызывается на тип предмета, связи или расширения предмета (например, Person.GetSearcher), типом цели является тип предмета, связи или расширения предмета.

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

Тип цели поиска делается доступным при помощи свойства только для чтения (например, свойство ItemSearcher.Type).

(b) Фильтры

ItemSearcher содержит свойство для задания фильтров (например, свойство, именованное «Filters» в виде коллекции объектов SearchExpression), которое определяет фильтр, используемый в поиске. Все фильтры в коллекции объединяются с использованием оператора логического И, когда выполняется поиск. Фильтр может содержать ссылки на параметры. Значения параметров задаются при помощи свойства Parameters.

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

В тех ситуациях, когда один и тот же поиск должен выполняться неоднократно, возможно, только с изменениями параметров, может быть получено некоторое улучшение рабочих характеристик посредством предварительной компиляции или подготовки поиска. Это выполняется с набором методов подготовки ItemSearcher (например, метод для подготовки Find, который возвращает один или несколько Предметов, возможно, называемый «PrepareFind», и метод для подготовки Find, который возвращает проекцию, возможно, называемый «PrepareProject»). Например:

ItemSearcher searcher = ;

PreparedFind pf = searcher.PrepareFind();

result = pf.FindAll();

result = pf.FindAll();

(d) Варианты поиска

Имеется ряд вариантов, которые могут быть применены к простому поиску. Они могут задаваться, например, в объекте FindOptions и передаваться методам Find. Например:

ItemSearcher searcher = Person.GetSearcher( context );

FindOptions options = new FindOptions();

options.MaxResults = 10;

options.SortOptions.Add( “PersonalNames.Surname”, SortOrder.Ascending);

FindResult result = searcher.FindAll( options );

Для удобства варианты сортировки также могут передаваться непосредственно методам Find:

ItemSearcher searcher = Person.GetSearcher( context );

FindResult result = searcher.FindAll(

new SortOption( “PersonalNames.Surname”, SortOrder.Ascending ));

Вариант DelayLoad определяет, загружаются ли значения больших двоичных свойств, когда извлекаются результаты поиска, или задерживается ли загрузка до тех пор, пока не будут выполнены ссылки на них. Вариант MaxResults определяет максимальное количество результатов, которые возвращаются. Он эквивалентен заданию TOP в запросе ЯСЗ (SQL). Он очень часто используется совместно с сортировкой.

Последовательность объектов SortOption может задаваться (например, используя свойство FindOptions.SortOptions). Результаты поиска будут сортироваться так, как задано первым объектом SortOption, затем, как задано вторым объектом SortOption и т.д. SortOption задает выражение поиска, которое указывает свойство, которое будет использоваться для сортировки. Выражение задает одно из следующих:

1) скалярное свойство в типе цели поиска;

2) скалярное свойство во вложенном элементе, который может быть вызван из типа цели поиска посредством прохождения по свойствам с единственным значением; или

3) результат функции агрегирования с действительным аргументом (например, Max, применяемым к скалярному свойству во вложенном элементе, который может быть вызван из типа цели поиска посредством прохождения по свойствам с множеством значений или связи).

Например, предположим, что типом цели поиска является System.Storage.Contact.Person:

1. «Birthdate» – действительный, дата рождения представляет собой скалярное свойство типа Person;

2. «PersonalNames.Surname» – недействительный, PersonalNames представляет собой свойство с множеством значений, и не использовалась функция агрегирования;

3. «Count(PersonalNames)» – действительный, число PersonalNames.

4. «Case(Contact.MemberOfHousehold).Household.HouseholdEAddresses.StartDate» – недействительный, использует связь и свойства с множеством значений без функции агрегирования.

5. «Max(Cast(Contact.MemberOfHousehold).Household.HouseholdEAddresses.StartDate)» – действительный, наиболее недавняя начальная дата домашнего электронного адреса.

(3) Поток результатов предметов («FindResult»)

ItemSearcher (например, при помощи метода FindAll) возвращает объект, который может использоваться для доступа к объектам, возвращаемым в результате поиска (например, объект «FindResult»). В Приложении С представлен листинг исходного кода класса FindResult и несколько близкородственных классов согласно их одному варианту осуществления.

Существуют два отдельных способа для получения результатов от объекта FindResult: использование шаблона считывателя, определенного посредством IObjectReader (и IAsyncObjectReader), и использование шаблона перечислителя, определенного посредством IEnumerable и IEnumerator. Шаблон перечислителя является стандартным в ОЯСВ (CLR) и поддерживает языковые конструкции, подобные foreach в C#. Например:

ItemSearcher searcher = Person.GetSearcher( context );

searcher.Filters.Add( “PersonalNames.Surname = ‘Smith'”);

FindResult result = searcher.FindAll();

foreach( Person person in result);

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

ItemSearcher searcher = Person.GetSearcher( context );

searcher.Filters.Add( “PersonalNames.SurName = ‘Smith'”);

FindResult result = searcher.FindAll();

while( result.Read())

{

Person person = (Person)result.Current;

}

Кроме того, шаблон считывателя поддерживает асинхронную операцию:

ItemSearcher searcher = Person.GetSearcher( context );

searcher.Filters.Add( “PersonalNames.SurName = ‘Smith'”);

FindResult result = searcher.FindAll();

IAsyncResult asyncResult = result.BeginRead( new AsyncCallback( MyCallback ));

void MyCallback( IAsyncResult asyncResult)

{

if( result.EndRead( asyncResult))

{

Person person = (Person)result.Current;

}

}

В настоящем варианте осуществления FindResult должен быть закрыт, когда он больше не нужен. Это может быть выполнено посредством вызова метода Close или использования языковых конструкций, таких как оператор using в C#. Например:

ItemSearcher searcher = Person.GetSearcher( context );

searcher.Filters.Add( “PersonalNames.SurName = ‘Smith'” );

using( FindResult result = searcher.FindAll())

{

while( result.Read())

{

Person person = (Person)result.Current;

}

}

b) Интегрированная среда выполнения в работе

Фиг.22 иллюстрирует интегрированную среду выполнения в работе. Интегрированная среда выполнения работает следующим образом:

1. Приложение 350а, 350b или 350с связывается с предметом в платформе хранения.

2. Интегрированная среда 2004 создает объект 2202 ItemContext, соответствующий привязанному предмету, и возвращает его приложению.

3. Приложение подает Find на этот ItemContext для получения коллекции Предметов; возвращаемая коллекция концептуально представляет собой граф 2204 объектов (вследствие связей).

4. Приложение изменяет, удаляет и вставляет данные.

5. Приложение сохраняет изменения посредством вызова метода Update().

с) Общие шаблоны программирования

В данном разделе представлено множество примеров того, как классы интегрированной среды ИПП (API) платформы хранения могут использоваться для манипулирования предметами в хранилище данных.

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

Приложение получает объект ItemContext, который оно будет использовать для взаимодействия с хранилищем данных, например, посредством вызова статического метода ItemContext.Open и предоставления пути или путей, которые идентифицируют домены предметов, которые будут ассоциироваться с ItemContext. Домены Предметов ограничивают область действия поисков, выполняемых с использованием ItemContext, так что только предмет домена и предметы, содержащиеся в этом предмете, будут подвергаться поиску. Примерами являются следующие:

Открыть ItemContext с совместно используемым ресурсом платформы хранения DefaultStore на локальном компьютере

ItemContext ic = ItemContext.Open();

Открыть ItemContext с данным совместно используемым ресурсом платформы хранения

Открыть ItemContext с предметом под совместно используемым ресурсом платформы хранения

Открыть ItemContext с множеством доменов предметов

Когда ItemContext больше не нужен, он должен быть закрыт.

Явное Закрытие ItemContext

ItemContext ic = ItemContext.Open();

ic.Close();

Закрытие ItemContext оператором using

using( ItemContext ic = ItemContext.Open())

{

;

}

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

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

Приложения могут выполнять поиск по доменам, задаваемым тогда, когда ItemContext был открыт, используя объект ItemSearcher, возвращаемый методом ItemContext.GetSearcher. К результатам поиска обращаются с использованием объекта FindResult. Предположим следующие объявления для примеров ниже:

ItemContext ic = ;

ItemSearcher searcher = null;

FindResult result = null;

Item item = null;

Relationship relationship = null;

ItemExtension itemExtension = null;

Базовый шаблон поиска включает в себя использование объекта ItemSearcher, извлекаемого из ItemContext посредством вызова метода GetSearcher.

Поиск всех предметов данного типа

searcher = ic.GetSearcher( typeof( Person ));

result = searcher.FindAll();

foreach( Person p in result) ;

Поиск предметов данного типа, которые удовлетворяют фильтру

searcher = ic.GetSearcher( typeof( Person ));

searcher.Filters.Add( “PersonalNames.Surname = ‘Smith'”);

result = searcher.FindAll();

foreach( Person p in result) ;

Использовать параметр в строке фильтра

searcher = ic.GetSearcher( typeof( Person ));

searcher.Filters.Add( “Birthdate < @Date”);

searcher.Parameters[“Date”] = someDate;

result = searcher.FindAll();

foreach( Person p in result) ;

Поиск связей данного типа и удовлетворяющих фильтру

searcher = ic.GetSearcher( typeof( EmployeeEmployer));

searcher.Filters.Add( “StartDate <= @Date AND (EndDate >= @Date OR isnull(EndDate))”);

searcher.Parameters[“Date”] = someDate;

result = searcher.FindAll();

Foreach( EmployeeEmployer ee in result) ;

Поиск предметов со связями данного типа и удовлетворяющими фильтру

searcher = ic.GetSearcher( typeof( Folder));

result = searcher.FindAll();

Foreach( Folder f in result) ;

Поиск расширений предмета данного типа и удовлетворяющих фильтру

searcher = ic.GetSearcher( typeof( ShellExtension ));

searcher.Filters.Add( “Keywords.Value = ‘Foo'”);

result = searcher.FindAll();

foreach( ShellExtension se in result) ;

Поиск предметов с расширениями предметов данного типа и удовлетворяющих фильтру

searcher = ic.GetSearcher( typeof( Person ));

searcher.Parameters[“Type”] = typeof( ShellExtension );

result = searcher.FindAll();

foreach( Person p in result) ;

(а) Варианты поиска

Могут быть заданы различные варианты при выполнении поиска, включая сортировку, загрузку с задержкой и ограничение количества результатов.

Сортировка результатов поиска

searcher = ic.GetSearcher( typeof( Person ));

searcher.Filters.Add( “PersonalNames.Surname = ‘Smith'” );

SearchOptions options = new SearchOptions();

options.SortOptions.Add( new SortOption( “Birthdate”, SortOrder.Ascending ));

result = searcher.FindAll( options );

foreach( Person p in result) ;

searcher = ic.GetSearcher( typeof( Person ));

searcher.Filters.Add( “PersonalNames.Surname = ‘Smith'” );

result = searcher.FindAll( new SortOption( “Birthdate”, SortOrder.Ascending ));

foreach( Person p in result) ;

Ограничить количество результатов

searcher= ic.GetSearcher( typeof( Person ));

searcher.Filters.Add( “PersonalNames.Surname = ‘Smith'” );

SearchOptions options = new SearchOptions();

options.MaxResults = 10;

result = searcher.FindAll( options );

foreach( Person p in result) ;

(b) FindOne и FindOnly

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

Поиск одного объекта

searcher = ic.GetSearcher( typeof( Person ));

searcher.Filters.Add( “PersonalNames.Surname = ‘Smith'” );

Person p = searcher.FindOne( new SortOption( “Birthdate” SortOrder.Ascending )) as Person;

if( p != null);

Поиск единственного объекта, который, как ожидается, всегда существует

searcher = ic.GetSearcher( typeof( Person ));

searcher.Filters.Add( “PersonalNames[Surname = ‘Smith’ AND Givenname ‘John’]”);

try

{

Person p = searcher.FindOnly();

;

}

catch( Exception e )

{

;

}

(с) Краткие формы поиска по ItemContext

Также существует несколько сокращенных методов по ItemContext, которые делают максимально легким исполнение простых поисков.

Поиск с использованием краткой формы ItemContext.FindAll

result = ic.FindAll( typeof( Person ), “PersonalNames.Surname = ‘Smith'” );

foreach( Person p in result ) ;

Поиск с использованием краткой формы ItemContext.FindOne

Person p = ic.FindOne( typeof( Person ), “PersonalNames.Surname = ‘Smith'”) as Person;

(d) Поиск по ИД (ID) или пути

Кроме того, Предметы, связи и расширения предметов могут извлекаться посредством предоставления их ИД (ID). Предметы также могут извлекаться по пути.

Получить предметы, связи и расширения предметов по их ИД (ID)

item = ic.FindItemById( iid );

relationship = ic.FindRelationshipById( iid, rid );

itemExtension = ic.FindItemExtensionById( iid, eid );

Получить предметы по пути

foreach( Item I in result) ;

(е) Шаблон GetSearcher

Имеется много мест в ИПП (API) платформы хранения, где желательно предусмотреть вспомогательный метод, который исполняет поиск в контексте другого объекта или с конкретными параметрами. Шаблон GetSearcher делает возможными такие сценарии. Существует много методов GetSearcher в ИПП (API). Каждый возвращает ItemSearcher, предварительно сконфигурированный на выполнение данного поиска. Например:

searcher = itemContext.GetSearcher();

searcher = Person.GetSearcher();

searcher = EmployeeEmployer.GetSearcherGivenEmployer( organization );

searcher = person.GetSearcherForReports();

Можно добавить дополнительные фильтры перед выполнением поиска:

searcher = person.GetSearcherForReports();

searcher.Filters.Add( “PersonalNames.Surname= ‘Smith'” );

Можно выбрать, сколько хотите результатов:

FindResult findResult = searcher.FindAll();

Person person = searcher.FindOne();

(3) Обновление хранилища

Если объект был извлечен посредством поиска, он может модифицироваться приложением, как необходимо. Новые объекты также могут создаваться и ассоциироваться с существующими объектами. Если приложение сделало все изменения, которые формируют логическую группу, приложение вызывает ItemContext.Update для обеспечения постоянства этих изменений в хранилище. Согласно еще другому аспекту ИПП (API) платформы хранения настоящего изобретения, ИПП (API) собирает изменения в предмете, сделанные программой приложения, и затем организует их в корректные обновления, требуемые процессором базы данных (или любым видом процессора хранения), на котором реализовано хранилище данных. Это делает возможным выполнение программистами приложения изменений предмета в памяти, в то же самое время оставляя сложность обновлений хранилища данных для ИПП (API).

Сохранить Изменения в Единственном Предмете

Person p = ic.FindItemById( pid ) as Person;

p.DisplayName = “foo”;

p.TelephoneNumbers.Add( new TelephoneNumber( “425-555-1234”));

ic.Update();

Сохранить Изменения во Множестве Предметов

Household h1 = ic.FindItemById( hid1 ) as Household;

Household h2 = ic.FindItemById( hid2 ) as Household;

Person p = ic.FindItemById( pid ) as Person;

h1.MemberRelationships.Remove( p );

h2.MemberRelationships.Add( p );

ic.Update();

Создать новый Предмет

Folder f = ic.FindItemById( fid ) as Folder;

Person p = new Person();

p.DisplayName = “foo”;

f.Relationships.Add( new FolderMember( p, “foo” ));

ic.Update();

Folder f = ic.FindItemById( fid) as Folder;

Person p = new Person();

p.DisplayName = “foo”;

f.MemberRelationships.Add( p, “foo” );

ic.Update();

Удалить связи (и, возможно, Предмет цели)

searcher = ic.GetSearcher( typeof( FolderMember ));

searcher.Filters.Add( “SourceItemId=@fid” );

searcher.Filters.Add( “TargetItemId=@pid” );

searcher.Parameters.Add( “fid”, fid );

searcher.Parameters.Add( “pid”, pid );

foreach( FolderMember fm in searcher.FindAll()) fm.MarkForDelete();

ic.Update();

Folder f = ic.FindItemById( fid ) as Folder;

f.MemberRelationships.Remove( pid );

ic.Update();

Добавить Расширение Предмета

Item item = ic.FindItemById( iid);

MyExtension me = new MyExtension();

me.Foo = “bar”;

item.Extensions.Add( me );

ic.Update();

Удалить Расширения Предмета

searcher = ic.GetSearcher( typeof( MyExtension ));

searcher.Filters.Add( “ItemId=@iid” );

searcher.Parameters.Add( “iid”, iid );

foreach( MyExtension me in searcher.FindAll()) me.MarkForDelete();

ic.Update();

Item i = ic.FindItemById( iid );

i.Extensions.Remove( typeof( MyExtension ));

ic.Update();

6. Защита

Со ссылкой на раздел II.E выше (Защита) в настоящем варианте осуществления ИПП (API) платформы хранения имеется пять методов, доступных в Item Context, для извлечения и модифицирования политики обеспечения безопасности, ассоциированной с предметом в хранилище. Ими являются:

1. GetItemSecurity;

2. SetItemSecurity;

3. GetPathSecurity;

4. SetPathSecurity;

5. GetEffectiveItemSecurity.

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

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

СУД (ACL), который может быть установлен на предмете при помощи SetItemSecurity и SetPathSecurity, ограничивается до наследуемых и характерных для объекта ЗУД (ACE’s). Они не могут содержать никакую ЗУД (ACE), отмеченную как наследованная.

GetEffectiveItemSecurity извлекает основанные на различных путях СУД (ACL), а также явный СУД (ACL) на предмете. Это отражает политику авторизации, действующую на данном предмете.

7. Поддержка связей

Как описано выше, модель данных платформы хранения определяет «связи», которые дают возможность предметам быть связанными друг с другом. Когда генерируются классы данных для схемы, следующие классы получаются для каждого типа связи:

1. Класс, который представляет саму связь. Этот класс выводится из класса Relationship и содержит члены, характерные для типа связи.

2. Сильно типизированный класс «виртуальной» коллекции. Этот класс выводится из VirtualRelationshipCollection и дает возможность экземплярам связи создаваться и удаляться.

В данном разделе описывается поддержка связей в ИПП (API) платформы хранения.

а) Базовые типы связей

ИПП (API) платформы хранения предусматривает несколько типов в пространстве имен System.Storage, которые формируют базу ИПП (API) связей. Ими являются:

1. Relationship – базовый тип всех классов связей

2. VirtualRelationshipCollection – базовый тип для всех коллекций связей

3. ItemReference, ItemIdReference, ItemPathReference – представляют типы ссылки на предмет; связи между этими типами изображены на фиг.11.

(1) Класс Relationship

Нижеследующее представляет собой базовый класс для классов связей.

public abstract class Relationship : StoreObject

{

protected Relationship( ItemIDReference targetItemReference);

internal AddedToCollection( VirtualRelationshipCollection collection );

public RelationshipId RelationshipId { get; }

public ItemId SourceItemId { get; }

public Item SourceItem { get; }

public ItemIdReference TargetItemReference { get; }

public Item TargetItem { get; }

public bool IsTargetDomainConnected { get; }

public OptionalValue Name {get; set;}

public OptionalValue IsOwned {get; set;}

}

(2) Класс ItemReference

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

public abstract class ItemReference : NestedElement

{

protected ItemReference();

public virtual Item GetItem();

public virtual bool IsDomainConnected();

}

Объекты ItemReference могут идентифицировать предметы, которые существуют в хранилище, кроме хранилища, в котором постоянно находится сама ссылка на предмет. Каждый производный тип задает то, как ссылка на удаленное хранилище создается и используется. Реализации GetItem и IsDomainConnected в производных классах используют многодоменную поддержку ItemContext для загрузки предметов из необходимого домена и определения, установлено ли уже соединение с доменом.

(3) Класс ItemIdReference

Нижеследующее представляет собой класс ItemIdReference – ссылку на Предмет, которая использует ИД (ID) предмета для идентификации предмета цели (целевого предмета).

public class ItemIdReference : ItemReference

{

public ItemIdReference();

public ItemIdReference( Item item );

public ItemIdReference( ItemId itemId );

public ItemIdReference( string locator, ItemId itemId );

public ItemId ItemId {get; set;}

public OptionalValue Locator {get; set;}

public override bool IsDomainConnected();

public override Item GetItem();

}

GetItem и IsDomainConnected используют многодоменную поддержку ItemContext для загрузки предметов из необходимого домена и определения, было ли уже установлено соединение с доменом. Эта особенность еще не реализована.

(4) Класс ItemPathReference

Класс ItemPathReference представляет собой ссылку на предмет, которая использует путь для идентификации предмета цели. Код для класса следующий:

public class ItemPathReference : ItemReference

{

public ItemPathReference();

public ItemPathReference( string path );

public ItemPathReference( string locator, string path );

public OptionalValue Locator {get; set;}

public string Path {get; set;}

public override bool IsDomainConnected();

public override Item GetItem();

}

GetItem и IsDomainConnected используют многодоменную поддержку ItemContext для загрузки предметов из необходимого домена и определения, было ли уже установлено соединение с доменом.

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

Структура RelationshipId инкапсулирует ГУИД (GUID) ИД (ID) связи.

public class RelationshipId

{

public static RelationshipId NewRelationshipId();

public RelationshipId();

public RelationshipId( Guid id );

public RelationshipId( string id );

public override string ToString();

public static implicit operator RelationshipId(Guid guid);

public static implicit operator Guid(RelationshipId relationshipId);

}

Этот размерный тип заключает в оболочку guid, так что параметры и свойства могут сильно типизироваться в качестве ИД (ID) связи. OptionalValue должен использоваться, когда ИД (ID) связи является обнуляемым. Значение Empty, такое как предоставляемое посредством System.Guid.Empty, не раскрывается. RelationshipId не может быть построено с пустым значением. Когда конструктор по умолчанию используется для создания RelationshipId, создается новый ГУИД (GUID).

(6) Класс VirtualRelationshipCollection

Класс VirtualRelationshipCollection реализует коллекцию объектов связи, которая включают в себя объекты из хранилища данных, плюс новые объекты, которые были добавлены к коллекции, но не включает объекты, которые были удалены из хранилища. Объекты заданного типа связи с данным ИД (ID) предмета источника включены в коллекцию.

Он представляет собой базовый класс для класса коллекции связей, который генерируется для каждого типа связи. Этот класс может использоваться в качестве типа свойства в типе предмета источника для предоставления доступа и обеспечения легкой манипуляции данными связями предмета.

Перечисление содержимого VirtualRelationshipCollection требует того, чтобы потенциально большое количество объектов связи загружалось из хранилища. Приложения должны использовать свойство Count для определения того, сколько связей может быть загружено, до того как они перечислят содержимое коллекции. Добавление и удаление объектов в/из коллекции не требует загрузки связей из хранилища.

Для эффективности предпочтительно, чтобы приложения выполняли поиск связей, которые удовлетворяют конкретным критериям, вместо перечисления всех связей предмета, используя объект VirtualRelationshipCollection. Добавление объектов связи к коллекции побуждает создание представленных связей в хранилище, когда вызывается ItemContext.Update. Удаление объектов связи из коллекции вызывает удаление представленной связи в хранилище, когда вызывается ItemContext.Update. Виртуальная коллекция содержит корректный набор объектов независимо от того, добавляется/удаляется ли или нет объект связи при помощи коллекции Item.Relationships или любой другой коллекции связей этого предмета.

Следующий код определяет класс VirtualRelationshipCollection:

public abstract class VirtualRelationshipCollection : ICollection

{

protected VirtualRelationshipCollection( ItemContext itemContext,

ItemId itemId,

Type relationshipType);

public IEnumerator GetEnumerator();

public int Count { get; }

public bool ICollection.IsSynchronized() { get; }

public object ICollection.SyncRoot { get; }

public void Refresh();

protected void Add( Relationship relationship );

protected void Remove( Relationship relationship );

public ICollection RemovedRelationships { get; }

public ICollection AddedRelationships { get; }

public ICollection StoredRelationships { get; }

public IAsyncResult BeginGetCount( IAsyncCallback callback, object state );

public int EndGetCount( IAsyncResult asyncResult);

public IAsyncResult BeginRefresh( IAsyncCallback callback, object state );

public void EndRefresh( IAsyncResult asyncResult);

}

b) Генерируемые типы связей

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

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

(1) Генерируемые типы связей

В данном разделе описываются классы, которые генерируются для каждого типа связи. Например:

Relationship Name=”RelationshipPrototype” BaseType=”Holding”>

При наличии этого определения связи будут генерироваться классы RelationshipPrototype и RelationshipPrototypeCollection. Класс RelationshipPrototype представляет саму связь. Класс RelationshipPrototypeCollection обеспечивает доступ к экземплярам RelationshipPrototype, которые имеют заданный предмет в качестве конечной точки источника.

(2) Класс RelationshipPrototype

Это прототипный класс связей для связи прикрепления, названный «HoldingRelationshipPrototype», где конечная точка источника называется «Head» и задает тип предмета «Foo», и конечная точка цели называется «Tail» и задает тип предмета «Bar». Он определяется следующим образом:

public class RelationshipPrototype: Relationship

{

public RelationshipPrototype( Bar tailItem );

public RelationshipPrototype( Bar tailItem, string name);

public RelationshipPrototype( Bar tailItem, string name, bool IsOwned );

public RelationshipPrototype( Bar tailItem, bool IsOwned );

public RelationshipPrototype( ItemIdReference tailItemReference);

Head (вызывает base.SourceItem).

public Foo HeadItem { get; }

Tail (вызывает base.TargetItem).

public Bar TailItem { get; }

public string SomeProperty {get; set;}

public static ItemSearcher GetSearcher( ItemContext itemContext);

public static ItemSearcher GetSearcher( Foo headItem );

public static FindResult FindAll( string filter );

public static RelationshipPrototype FindOne( string filter );

public static RelationshipPrototype FindOnly( string filter );

}

(3) Класс RelationshipPrototypeCollection

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

public class RelationshipPrototypeCollection : VirtualRelationshipCollection

{

public RelationshipPrototypeCollection( ItemContext itemContext,

ItemId headItemId);

public void Add( RelationshipPrototype relationship );

public RelationshipPrototype Add( Bar bar );

public RelationshipPrototype Add( Bar bar, string name );

public RelationshipPrototype Add( Bar bar, string name, bool IsOwned );

public RelationshipPrototype Add( Bar bar, bool IsOwned );

public void Remove( RelationshipPrototype relationship );

public void Remove( Bar bar );

public void Remove( ItemId barItemId );

public void Remove( RelationshipId relationshipId );

public void Remove( string name );

}

c) Поддержка связей в классе Item

Класс Item содержит свойство Relationships, которое обеспечивает доступ к связям, в которых этот предмет является источником связи. Свойство Relationships имеет тип RelationshipCollection.

(1) Класс Item

Следующий код показывает свойства контекста связи класса Item:

public abstract class Item : StoreObject

{

public RelationshipCollection Relationships {get;}

}

(2) Класс RelationshipCollection

Этот класс обеспечивает доступ к экземплярам связей, в которых данный предмет является источником связи. Он определяется следующим образом:

public class RelationshipCollection : VirtualRelationshipCollection

{

public RelationshipCollection( ItemContext itemContext,

ItemId headItemId );

public void Add( Relationship relationship );

public Relationship Add( Bar bar );

public Relationship Add( Bar bar, string name );

public Relationship Add( Bar bar, string name, bool IsOwned );

public Relationship Add( Bar bar, bool IsOwned );

public void Remove( Relationship relationship );

public void Remove( Bar bar );

public void Remove( ItemId barItemId );

public void Remove( RelationshipId relationshipId );

public void Remove( string name );

}

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

Можно задавать прохождение соединения между связями и соответствующими предметами в выражении поиска.

(1) Прохождение от предметов к связям

Когда текущий контекст выражения поиска представляет собой набор предметов, соединение между предметами и экземплярами связей, где предмет является источником, может быть выполнено с использованием свойства Item.Relationships. Присоединение к связям конкретного типа может задаваться с использованием оператора Cast выражения поиска.

Коллекции сильно типизированных связей (например, Folder.MemberRelationships) также могут использоваться в выражении поиска. Приведение к типу связи является неявным.

Если набор связей был установлен, свойства этой связи доступны для использования в предикатах или в качестве цели проекции. При использовании для задания цели проекции будет возвращаться набор связей. Например, следующий оператор будет находить всех людей, относящихся к организации, где свойство StartDate связей имеет значение, большее или равное «1/1/2000».

FindResult result = Person.FindAll( context,

“Relationships.Cast(Contact.EmployeeOfOrganization).StartDate > ‘1/1/2000′”);

Если тип Person имеет свойство EmployerContext типа EmployeeSideEmployerEmployeeRelationships (генерируемый для типа связей EmployeeEmployer), это может быть записано как:

FindResult result = Person.FindAll( context,

“EmployerRelationships.StartDate > ‘1/1/2000′” );

(2) Прохождение от связей к предметам

Когда текущий контекст выражения поиска представляет собой набор связей, прохождение соединения от связи к любой конечной точки связи может выполняться посредством задания имени конечной точки. Если был установлен набор относящихся предметов, свойства этих предметов являются доступными для использования в предикатах или в качестве цели проекции. При использовании для задания цели проекции будет возвращаться набор предметов. Например, следующий оператор будет находить все связи EmployeeOfOrganization (независимо от организации), где фамилией служащего является имя «Smith».

FindResult result = EmployeeOfOrganization.FindAll( context,

“Employee.PersonalNames[SurName=’Smith’]”);

Оператор Cast выражения поиска может использоваться для фильтрации типа предмета конечной точки. Например, чтобы найти все экземпляры связи MemberOfFolder, где членом является предмет Person с фамилией «Smith»:

FindResult result = MemberOfFolder.FindAll( context,

“Member.Cast(Contact.Person).PersonalNames[Surname=’Smith’]”);

(3) Объединение прохождения связи

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

FindResult result = Organization.FindAll( context,

“EmployeeRelationships.” +

“Employee.” +

“PersonalNames[SurName = ‘Smith’]”);

Пример ниже находит все предметы Person, представляющие людей, которые живут в семье, которая находится в районе «New York» (TODO: это больше не поддерживается какая альтернатива).

FindResult result = Person.FindAll( context,

“Relationships.Cast(Contact.MemberOfHousehold).” +

“Household.” +

“Relationships.Cast(Contact.LocationOfHousehold).” +

“MetropolitonRegion = ‘New York'”);

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

Нижеследующее представляет собой примеры того, как поддержка связей в ИПП (API) платформы хранения может использоваться для манипулирования связями. Для примеров ниже предположим следующие объявления:

ItemContext ic =;

ItemId fid =

Folder folder = Folder.FindById( ic, fid );

ItemId sid =

Item source = Item.FindById( ic, sid );

ItemId tid =

Item target = Item.FindById( ic, tid );

ItemSearcher searcher = null;

(1) Поиск связей

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

Все связи, где данный предмет является источником

searcher = Relationship.GetSearcher( folder );

foreach( Relationship relationship in searcher.FindAll());

Все связи, где данный предмет является источником, который имеет имя, которое соответствует «А%»

searcher = Relationship.GetSearcher( folder );

searcher.Filters.Add( “Name like ‘A%'”);

foreach( Relationship relationship in searcher.FindAll() );

Все связи FolderMember, где данный предмет является источником

searcher = FolderMember.GetSearcher( folder );

foreach( FolderMember folderMember in searcher.FindAll());

Все связи FolderMember, где данный предмет является источником и имя, подобное «А%»

searcher = FolderMember.GetSearcher( folder );

searcher.Filters.Add( “Name like ‘A%'”);

foreach( FolderMember folderMember in searcher.FindAll());

Все связи FolderMember, где предметом цели является Person

searcher = FolderMember.GetSearcher( folder );

searcher.Filters.Add( “MemberItem.Cast(Person)” );

foreach( FolderMember folderMember in searcher.FindAll());

Все связи FolderMember, где предметом цели является Person с фамилией «Smith»

searcher = FolderMember.GetSearcher( folder );

searcher.Filters.Add( “MemberItem.Cast(Person).PersonalNames.Surname=’Smith'” );

foreach( FolderMember folderMember in searcher.FindAll());

В дополнение к ИПП (API) GetSearcher, показанном выше, каждый класс связей поддерживает статические ИПП (API) FindAll, FindOne и FindOnly. Кроме того, тип связей может задаваться при вызове ItemContext.GetSearcher, ItemContext.FindAll, ItemContext.FindOne или ItemContext.FindOnly.

(2) Навигация от связи к предметам источника и цели

Если объект связи был извлечен посредством поиска, можно выполнять «навигацию» к предмету цели или источника. Базовый класс связей предусматривает свойства SourceItem и TargetItem, которые возвращают объект Item. Генерируемый класс связей предусматривает эквивалентные сильно типизированные и именованные свойства (например, FolderMember.FolderItem и FolderMember.MemberItem). Например:

Выполнить навигацию к предмету источника и цели для связи с именем «Foo»

searcher = Relationship.GetSearcher();

searcher.Filters.Add( “Name=’Foo'” );

foreach( Relationship relationship in searcher.FindAll())

{

Item source = relationship.SourceItem;

Item target = relationship.TargetItem;

}

Выполнить навигацию к предмету цели

searcher = FolderMember.GetSearcher( folder );

searcher.Filters.Add( “Name like ‘A%'” );

foreach( FolderMember folderMember in searcher.FindAll() )

{

Item member = folderMember.TargetItem;

}

Навигация к предмету цели работает, даже если предмет цели не находится в домене, где была обнаружена связь. В таких случаях ИПП (API) платформы хранения открывает соединение к домену цели, когда необходимо. Приложения могут определить, потребуется ли соединение перед извлечением предмета цели.

Проверить предмет цели в неприсоединенном домене

searcher = Relationship.GetSearcher( source );

foreach( Relationship relationship in searcher.FindAll())

{

if( relationship.IsTargetDomainConnected)

{

Item member = relationship.TargetItem;

}

}

(3) Навигация от предметов источника к связям

При наличии объекта предмета можно выполнять навигацию к связям, для которых этот предмет является источником без выполнения явного поиска. Это выполняется с использованием свойства коллекции Item.Relationships или сильно типизированного свойства коллекции, такого как Folder.MemberRelationships. От связи можно выполнять навигацию к предмету цели. Такая навигация работает, даже если предмет цели не находится в домене цели, ассоциированном с ItemContext предмета источника, включая тот случай, когда предмет цели не находится в этом же хранилище, что и предмет цели. Например:

Выполнить навигацию от Предмета Источника к Связи к Предметам Цели

Console.WriteLine( “Предмет {0} является источником следующих связей:”, source.ItemId);

foreach( Relationship relationship in source.Relationships)

{

Item target = relationship.TargetItem;

Console.WriteLine(” {0} ==> {1}”, relationship.RelationshipId, target.ItemId );

}

Выполнить навигацию от Предмета Папки к Связям Foldermember к Предметам Цели

Console.WriteLine( “Предмет {0} является источником следующих связей:”, folder.ItemId );

foreach( FolderMember folderMember in folder.MemberRelationships )

{

Item target = folderMember.GetMemberItem();

Console.WriteLine(” {0} ==> {1}”, folderMember.RelationshipId, target.ItemId );

}

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

Проверить размер коллекции связей

if( folder.MemberRelationships.Count > 1000 )

{

Console.WriteLine( “Слишком много связей!” );

}

else

{

}

Коллекции связей, описанные выше, являются «виртуальными» в том смысле, что они фактически не заполняются объектами, которые представляют каждую связь, если только приложение не предпринимает попытку выполнить перечисление коллекции. Если коллекция перечисляется, результаты отражают то, что находится в хранилище, плюс то, что было добавлено приложением, но еще не сохранено, но не любые связи, которые были удалены приложением, но не сохранены.

(4) Создание связей (и предметов)

Новые связи создаются посредством создания объекта связи, добавления его в коллекцию связей в предмете источника и обновления ItemContext. Чтобы создать новый предмет, должна быть создана связь прикрепления или внедрения. Например:

Добавить новый предмет в существующую папку

Bar bar = new Bar();

folder.Relationships.Add( new FolderMember( bar, “name”));

ic.Update();

Bar bar = new Bar();

folder.MemberRelationships.Add( new FolderMember( bar, “name”));

ic.Update();

Bar bar = new Bar();

folder.MemberRelationships.Add( bar, name );

ic.Update();

Добавить существующий предмет в существующую папку

folder.MemberRelationships.Add( target, “name” );

ic.Update();

Добавить существующий предмет в новую папку

Folder existingFolder = ic.FindItemById( fid ) as Folder;

Folder newFolder = new Folder();

existingFolder.MemberRelationships.Add( newFolder, “a name” );

newFolder.MemberRelationships.Add( target, “a name” );

ic.Update();

Добавить новый предмет в новую папку

Folder existingFolder = ic.FindItemById( fid ) as Folder;

Folder newFolder = new Folder();

existingFolder.MemberRelationships.Add( newFolder, “a name” );

Bar bar = new Bar();

newFolder.MemberRelationships.Add( bar, “a name” );

ic.Update();

(5) Удаление связей (и предметов)

Удалить связь прикрепления

RelationshipId rid = ;

Relationship r = ic.FindRelationshipById( fid, rid );

r.MarkForDelete;

ic.Update();

folder.MemberRelationships.Remove( target );

ic.Update();

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

Как отмечено выше, каждая схема платформы хранения приводит к набору классов. Эти классы имеют стандартные методы, такие как Find*, и также имеют свойства для получения и установки значений полей. Эти классы и связанные с ними методы образуют основу ИПП (API) платформы хранения.

а) Методы поведения домена

В дополнение к этим стандартным методам каждая схема имеет набор характерных для домена методов для этого. Изобретатели называют их методами поведения доменов. Например, некоторыми из методов поведения доменов в схеме Contact являются:

– Является ли адрес электронной почты действительным?

– Для данной папки получить коллекцию всех членов папки.

– Для данного ИД (ID) предмета получить объект, представляющий этот предмет.

– Для данного Person получить его оперативное состояние.

– Вспомогательные функции для создания нового контакта или временного контакта.

– И т.п.

Важно отметить, что, хотя изобретатели делают различие между «стандартными» методами поведения (Find* и т.д.) и методами поведения доменов, они просто выглядят как методы для программиста. Различие между этими методами заключается в том, что стандартные методы поведения генерируются автоматически из файлов схемы инструментальными средствами периода проектирования ИПП (API) платформы хранения, тогда как методы поведения доменов жестко программируются.

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

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

partial public class Person : DerivedItemBase

{

}

Теперь методы поведения домена для Person могут быть помещены в другой файл, подобно этому:

partial public class Person

{

public EmailAddress PrimaryEmailAddress

{

get {/*реализация*/}

}

}

b) Дополнительные методы поведения

Классы данных с методами поведения доменов образуют основу, на которой создают разработчики приложений. Однако не является ни возможным, ни желательным, чтобы классы данных раскрывали любой потенциальный метод поведения, относящийся к этим данным. Платформа хранения позволяет разработчику создавать на базовой функциональной возможности, предлагаемой посредством ИПП (API) платформы хранения. Базовым шаблоном здесь является запись класса, методы которого принимают один или несколько классов платформы хранения в качестве параметров. Например, дополнительные классы для отправки сообщения электронной почты с использованием Microsoft Outlook или с использованием Microsoft Windows Messenger могут быть такими, которые приведены ниже:

MailMessage m = MailMessage.FindOne();

OutlookEMailServices.SendMessage(m);

Person p = Person.FindOne();

WindowsMessagerServices m = new WindowsMessagerServices(p);

m.MessageReceived += new MessageReceivedHandler( f );

m.SendMessage(“Hello”);

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

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

с) Дополнительные методы поведения в качестве поставщиков служб

В настоящем варианте осуществления ИПП (API) платформы хранения предусматривает механизм, посредством которого дополнительные классы могут регистрироваться как «службы» для данного типа. Это позволяет приложению установить и получить поставщиков служб (= дополнительные классы) данного типа. Дополнительные классы, желающие использовать этот механизм, должны реализовывать общеизвестный интерфейс; например:

interface IChatServices

{

void SendMessage(string msg);

event MessageReceivedHandler MessageReceived;

}

class WindowsMessengerServices: IChatServices

{

}

class YahooMessengerServices: IChatServices

{

}

Все классы данных ИПП (API) платформы хранения реализуют интерфейс ICachedServiceProvider. Этот интерфейс расширяет интерфейс System.IServiceProvider следующим образом:

interface ICachedServiceProvider: System.IServiceProvider

{

void SetService(System.Type type, Object provider);

void RemoteService(System.Type type);

}

Используя этот интерфейс, приложения могут установить экземпляр поставщика служб, а также запросить поставщика служб конкретного типа.

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

9. Интегрированная среда периода проектирования

В данном разделе описывается то, как Схема платформы хранения превращается в классы ИПП (API) платформы хранения на клиенте и классы ОПТ (UDT) на сервере согласно настоящему варианту осуществления изобретения. Схема на фиг.24 изображает участвующие компоненты.

Со ссылкой на фиг.24, типы в схеме содержатся в РЯР (XML)-файле (блок 1). Этот файл также содержит ограничения уровня поля и уровня предмета, ассоциированные со схемой. Генератор (xfs2cs.exe – блок 2) Класса платформы хранения принимает этот файл и генерирует частичные классы для ОПТ (UDT) (блок 5) хранилища и частичные классы для классов (блок 3) клиента. Для каждого домена схемы существуют дополнительные методы, которые изобретатели называют методами поведения доменов. Существуют методы поведения доменов, которые имеют смысл на хранилище (блок 7), на клиенте (блок 6) и в обоих местах (блок 4). Код в блоках 4, 6 и 7 пишется вручную (не генерируется автоматически). Частичные классы в блоках 3, 4 и 6 вместе образуют полную реализацию классов для классов доменов ИПП (API) платформы хранения. Блоки 3, 4 и 6 компилируются (блок 8), формируя классы ИПП (API) платформы хранения – блок 11 (фактически, ИПП (API) платформы хранения представляет собой результат компиляции блоков 3, 4 и 6, которые являются следствием всех начальных доменов схемы). В дополнение к классам доменов также существуют дополнительные классы, которые реализуют дополнительный метод поведения. Эти классы используют один или несколько классов в одном или нескольких доменах схемы. Это представлено блоком 10. Частичные классы в блоках 4, 5 и 7 вместе формируют полную реализацию классов для классов ОПТ (UDT) сервера. Блоки 4, 5 и 7 компилируются (блок 9), формируя сборку ОПТ (UDT) на стороне сервера – блок 12 (фактически, сборка ОПТ (UDT) на стороне сервера представляет собой результат компилятора плюс компиляции блоков 4, 5 и 7, которые являются результатом всех начальных доменов схемы). Модуль (блок 13) Генератора команд динамичной библиотеки данных (ДБД; DDL) принимает сборку (блок 12) ОПТ (UDT) и файл (блок 1) Схемы и устанавливает их на хранилище данных. Этот процесс задействует, среди прочих вещей, генерирование таблиц и представлений для типов в каждой схеме.

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

Обращаясь к основам, шаблон приложения при использовании ИПП (API) платформы хранения представляет собой: Открыть ItemContext; использовать Find с критерием фильтра для извлечения требуемых объектов; выполнить операцию над объектами и послать изменения обратно в хранилище. Данный раздел касается синтаксиса того, что используется в строке фильтра.

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

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

Строка фильтра является или пустой, указывая, что все объекты заданного типа должны быть возвращены, или булевым выражением, которому должен удовлетворять каждый возвращаемый объект. Выражение ссылается на свойства объекта. Среда выполнения ИПП (API) платформы хранения знает, как эти имена свойств отображаются на имена полей типа платформы хранения и, в конечном счете, на представления ЯСЗ (SQL), поддерживаемые хранилищем платформы хранения.

Рассмотрим следующие примеры:

FindResult res1 = Person.FindAll(ctx)

FindResult res2 = Person.FindAll(ctx, “Gender=’Male'”)

FindResult res3 = Person.FindAll(

ctx,

“Gender= ‘Male’ And Birthdate < ‘1/1/2001′”)

Свойства вложенных объектов также могут использоваться в фильтре. Например:

FindResult res1 = Person.FindAll(

ctx,

String.Format(“Item.Modified > ‘{0}'”,DateTime.Now.Subtract(new TimeSpan(24,0,0))));

Для коллекций можно фильтровать члены, используя условие в квадратных скобках. Например:

FindResult res1 = Person.FindAll(

ctx,

“PersonalNames[GivenName=’John’ And Surname=’Smith’]”)

FindResult res2 = Person.FindAll(

ctx,

“PersonalRealtimeAddress[ProviderURI=’x’].BasicPresence.” +

“OnlineStatus.Category=’y'”)

Следующий пример перечисляет всех людей, которые родились после 31/12/1999:

ItemContext ctx = ItemContext.Open(“Work Contacts”);

FindResult results =

Person.FindAll( ctx, “Birthdate > ’12/31/1999′” );

foreach( Person person in results)

Console. WriteLine(person.DisplayName);

ctx.Close();

Строка 1 создает новый объект ItemContext для доступа к «Work Contacts» на совместно используемом ресурсе платформы хранения на локальном компьютере. Строки 3 и 4 получают коллекцию объектов Person, где свойство Birthdate задает дату после 31/12/1999, как задано выражением «Birthdate > ’12/31/1999’». Исполнение этой операции FindAll иллюстрируется на фиг.23.

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

Часто бывает так, что тип значения, хранимого в свойстве, выводится из типа с объявленными свойствами. Например, свойство PersonalEAddresses в Person содержит коллекцию типов, выведенных из EAddress, таких как EMailAddress и TelephoneNumber. Чтобы отфильтровать на основе телефонного кода зоны, необходимо приведение из типа EAddress в тип TelephoneNumber:

FindResult res1 = Person.FindAll(

ctx,

“PersonalEAddresses.” +

“Cast(System.Storage.Contact.TelephoneNumber)). ” +

“AreaCode=’425′”);

FindResult res1 = Person.FindAll(

ctx,

String.Format(“PersonalEAddresses.Cast({0})).AreaCode=’425′”,

typeof(TelephoneNumber).FullName))

с) Синтаксис фильтра

Ниже представлено описание синтаксиса фильтра, поддерживаемого ИПП (API) платформы хранения, согласно одному варианту осуществления.

Filter ::= EmptyFilter | Condition

EmptyFilter ::=

Condition ::= SimpleCondition | CompoundCondition |

ParenthesizedCondition

SimpleCondition ::= ExistanceCheck | Comparison

ExistanceCheck ::= PropertyReference

Comparison ::= PropertyReference ComparisonOp Constant

CompoundCondition ::= SimpleCondition BooleanOp Condition

ParenthesizedCondition ::= ‘(‘ Condition ‘) ‘

ComparisonOp ::= ‘!= ‘ | ‘==’ | ‘=’ | ‘<‘ | ‘>’ | ‘>=’ | ‘<=’

BooleanOp ::= ‘And ‘ | ‘&&’ | ‘Or ‘ | ‘||’

Constant ::= StringConstant | NumericConstant

StringConstant ::= ”’ (любой символ Уникода)* ”’

Примечание: вставленные знаки ‘ отключаются посредством дублирования

NumericConstant ::= 0-9*

PropertyReference ::= SimplePropertyName | CompoundPropertyName

SimplePropertyName ::= (все символы Уникода за исключением‘.’и пробела)* Filter?

Filter ::= ‘ [‘ Condition ‘] ‘

CompoundPropertyName ::=

(TypeCast | RelationshipTraversal | SimplePropertyName) ‘.’ PropertyReference

Typecast ::= ‘Cast(‘ TypeName ‘)’

RelationshipTraversal ::= TraversalToSource | TraversalToTarget

TraversalToSource ::= ‘Source(‘ FullRelationshipName ‘)’

TraversalToTarget ::= ‘Target(‘ FullRelationshipName ‘)’

TypeName ::= полное уточненное имя типа ОЯСВ (CLR)

FullRelationshipName ::= SchemaName ‘.’ RelationshipName

SchemaName ::= the storage platformName

RelationshipName ::= the storage platformName

the storage platformName ::= как определено в [SchemaDef]

11. Удаленное взаимодействие

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

Доступ к данным в платформе хранения нацелен на локальный экземпляр платформы хранения. Локальный экземпляр служит в качестве маршрутизатора, если запрос (или часть его) ссылается на удаленные данные. Уровень ИПП (API), таким образом, обеспечивает локальную/удаленную прозрачность: нет структурного различия в ИПП (API) между доступом к локальным и удаленным данным. Это просто функция запрашиваемой области действия.

Хранилище данных платформы хранения также реализует распределенные запросы; таким образом, можно соединиться с локальным экземпляром платформы хранения и выполнить запрос, который включает в себя предметы с различных томов, некоторые из которых находятся на локальном хранилище, а другие – на удаленном хранилище. Хранилище объединяет результаты и представляет их приложению. С точки зрения ИПП (API) платформы хранения (и, следовательно, разработчика приложения) любой удаленный доступ является полностью прямым и прозрачным.

ИПП (API) платформы хранения дает приложению возможность определить, представляет ли данный объект ItemContext (возвращаемый методом ItemContext.Open) локальное или удаленное соединение с использованием свойства IsRemote – это свойство объекта ItemContext. Среди других вещей приложению может потребоваться обеспечение визуальной обратной связи, чтобы способствовать установке ожидаемых пользователем результатов рабочих характеристик, надежности и т.д.

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

Хранилища данных платформы хранения общаются друг с другом с использованием специального поставщика СВОБД (OLEDB), который выполняется по протоколу передачи гипертекста (ППГТ (HTTP);) (поставщик СВОБД (OLEDB) по умолчанию использует протокол передачи потока табличных данных (ПТД; TDS)). В одном варианте осуществления распределенный запрос обрабатывается функциональной возможностью OPENROWSET по умолчанию процессора реляционной базы данных. Специальная определяемая пользователем функция (ОПФ (UDF)) DoRemoteQuery(server, queryText) предоставляется для выполнения фактического удаленного взаимодействия.

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

В одном варианте осуществления платформы хранения настоящего изобретения нет обобщенной архитектуры поставщика, которая дает возможность любому хранилищу участвовать в доступе к данным платформы хранения. Однако предусматривается ограниченная архитектура поставщика для конкретного случая Microsoft Exchange и Microsoft Active Directory (AD). Это означает, что разработчики могут использовать ИПП (API) платформы хранения и обращаться к данным в AD и Exchange, как если бы они были в платформе хранения, но что данные, к которым они могут обращаться, ограничиваются схематизированными типами платформы хранения. Таким образом, адресная книга (= коллекция типов Person платформы хранения) поддерживается в AD, и почта, календарь и контакты поддерживаются для Exchange.

d) Связи с РФС (DFS)

Распространитель свойств платформы хранения не распространяет за пределы точек монтирования. Даже если пространство имен является достаточно наполненным для доступа через точки монтирования, запросы не проходят через них. Тома платформы хранения могут выглядеть как листья в дереве РФС (DFS).

е) Связи к ГАР (GXA)/Indigo

Разработчик может использовать ИПП (API) платформы хранения для раскрытия «головной части ГАР (GXA)» в верхней части хранилища данных. Концептуально, это не отличается от создания любой другой веб-службы. ИПП (API) платформы хранения не взаимодействует с хранилищем данных платформы хранения с использованием ГАР (GXA). Как упомянуто выше, ИПП (API) взаимодействует с локальным хранилищем, используя ПТД (TDS); любое удаленное взаимодействие управляется локальным хранилищем, используя службу синхронизации.

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

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

Вспомним, что Схема платформы хранения задается в РЯР (XML)-файле, который используется платформой хранения для генерирования соответствующих объектов базы данных, представляющих схему. Он также используется интегрированной средой периода проектирования ИПП (API) платформы хранения для автоматического генерирования классов.

Вот частичный листинг РЯР (XML)-файла, используемого для генерирования схемы Contacts:

ExtendsType=”Principal” ExtendsVersion=”1″>

Nullable=”true” MultiValued=”false” />

Nullable=”true” MultiValued=”false” />

Nullable=”true” MultiValued=”true” />

TypeMajorVersion=”1″ Nullable=”true” MultiValued=”true” />

TypeMajorVersion=”1″ Nullable=”true” MultiValued=”true” />

expression

Теги Проверки в РЯР (XML) выше задают ограничения на тип Person. Может быть более одного тега проверки. Вышеупомянутое ограничение, как правило, проверяется в хранилище. Чтобы задать, что ограничение также может явно проверяться приложением, вышеупомянутый РЯР (XML) модифицируется подобно приведенному ниже:

>

Nullable=”true” MultiValued=”false” />

expression

Отметьте новый атрибут «InApplication» элемента , который устанавливается в true. Это обуславливает выявление ИПП (API) платформы хранения ограничения в ИПП (API) при помощи метода экземпляра класса Person, названного Validate(). Приложение может вызывать этот метод объекта для обеспечения того, что данные являются действительными, и для предотвращения потенциально бесполезного полного обхода для сервера. Он возвращает булево выражение для индикации результатов проверки. Отметьте, что ограничения на значения все же применяются на сервере, независимо от того, вызывает или нет клиент метод <объект>.Validate(). Вот пример того, как может использоваться Validate:

ItemContext ctx = ItemContext.Open();

Folder f = UserDataFolder.FindMyPersonalContactsFolder( ctx );

Person p = new Person( f );

p.Birthdate = new DateTime( 1959, 6, 9 );

FullName name = new FullName( FullName.Category.PrimaryName );

name.GivenName = “Joe”;

name.Surname = “Smith”;

p.PersonalNames.Add( name );

if (p.Validate() == false)

{

}

p.Update();

ctx.Close();

Существует множество путей доступа к хранилищу платформы хранения – ИПП (API) платформы хранения, ADO.Net, открытый интерфейс взаимодействия с базами данных (ОИВБД (ODBC)), СВОБД (OLEDB) и объекты данных ActiveX (ADO). Это поднимает вопрос проверки надежности ограничений, т.е. как можно гарантировать, что данные, записанные из, например, ОИВБД (ODBC), проходят через одни и те же ограничения целостности данных, что и данные, записанные из ИПП (API) платформы хранения. Так как все ограничения проверяются в хранилище, ограничения являются теперь надежными. Независимо от того, какой путь ИПП (API) используют для доступа к хранилищу, все записи в хранилище фильтруются при помощи проверок ограничений в хранилище.

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

Совместно используемый ресурс в платформе хранения имеет вид:

где <Имя СДИ> представляет собой имя службы доменных имен (СДИ; DNS) машины, и <Служба контекста> представляет собой папку включения, виртуальную папку или предмет в томе на этой машине. Например, предположим, что машина «Johns_Desktop» имеет том, названный Johns_Information, и в этом томе существует папка, названная Contacts_Categories; эта папка содержит папку, названную Work, которая имеет рабочие контакты для John:

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

Name=”Share” MajorVersion=”1″ MinorVersion=”0″>

ExtendsType=”Base.Item” ExtendsVersion=”1″>

TypeMajorVersion=”1″/>

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

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

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

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

В одном варианте осуществления программа приложения может обнаруживать совместно используемые ресурсы, доступные на данном <Имя СДИ>, следующим образом. Согласно первому способу ИПП (API) платформы хранения принимает имя СДИ (DNS) (например, Johns_Desktop) в качестве параметра области действия в методе ItemContext.Open(). ИПП (API) платформы хранения затем соединяется с хранилищем платформы хранения с этим именем СДИ (DNS) в качестве части строки соединения. С этим соединением единственно возможным, что приложение может сделать, является вызов ItemContext.FindAll(typeof(Share)). Служба платформы хранения затем объединяет все совместно используемые ресурсы на всех присоединенных томах и возвращает коллекцию совместно используемых ресурсов. Согласно второму способу на локальной машине администратор легко может обнаружить совместно используемые ресурсы на конкретном томе посредством FindAll(typeof(Share)) или конкретную папку посредством FindAll(typeof(Share), “Target(ShareDestination).Id=FolderId”).

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

Методы Find* (независимо от того, вызываются ли они на объект ItemContext или на индивидуальный предмет), в основном, применяются к Предметам (включая внедренные предметы) в данном контексте. Вложенные элементы не имеют Find – над ними нельзя выполнять поиск независимо от их включающих Предметов. Это согласуется с семантикой, требуемой моделью данных платформы хранения, где вложенные элементы выводят свою «идентификацию» из включающего предмета. Чтобы сделать это представление более ясным, здесь приведены примеры действительных и недействительных операций поиска:

а) Покажите все телефонные номера в системе, которые имеют код зоны 206?

Недействительный, так как поиск выполняется по телефонным номерам – элемент – без ссылки на предмет.

b) покажите все телефонные номера во всех Person, которые имеют код зоны 206?

Недействительный, даже если ссылается на Person (=предмет), критерий поиска не задействует этот предмет.

с) Показать все телефонные номера Murali (=одна единственная личность), которые имеют код зоны 206?

Действительный, так как существует критерий поиска по Предмету (Личность по имени «Murali»). Исключением из этого правила являются типы вложенных элементов, выводимые непосредственно или косвенно из типа Base.Relationship. Эти типы могут запрашиваться индивидуально при помощи классов связей. Такие запросы могут поддерживаться, так как реализация платформы хранения использует «главную таблицу связывания» для хранения элементов Relationship вместо внедрения их в ОПТ (UDTs) предмета.

15. ИПП (API) контактов платформы хранения

В этом разделе приводится обзор ИПП (API) Контактов платформы хранения. Схема, поддерживаемая ИПП (API) Контактов, показана на фиг.21А и 21В.

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

ИПП (API) платформы хранения включает в себя пространство имен для работы с предметами и элементами в схеме Contacts. Это пространство имен называется System.Storage.Contact.

Эта схема имеет, например, следующие классы:

– Предметы: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location

– Элементы: Profile, PostalAddress, EmailAddress, TelephoneNumber, RealTimeAddress, EAddress, FullName, BasicPresence, GroupMembership, RoleOccupancy

b) Методы поведения доменов

Ниже представлен список методов поведения доменов для схемы Contacts. Если рассматривать с достаточно высокого уровня, методы поведения доменов делятся на хорошо распознаваемые категории:

– Статические вспомогательные функции, например, Person.CreatePersonalContact() для создания нового персонального контакта;

– Вспомогательные функции экземпляров, например, user.AutoLoginToAllProfiles(), которая регистрирует пользователя (экземпляр класса User) во всех профилях, которые отмечены для автоматической регистрации;

– CategoryGUID, например, Category.Home, Category.Work и т.д.;

– Производные свойства, например, emailAddress() – возвращает строку, которая объединяет имя пользователя и поля домена данного emailAddress (=экземпляр класса EmailAddress); и

– Производные коллекции, например, person.PersonalEmailAddresses – при наличии экземпляра класса Person получаем ее персональные адреса электронной почты.

В таблице ниже приведен для каждого класса в Контактах, который имеет методы поведения доменов, список этих методов и категория, к которой они принадлежат.

BasicPresence	Унифицированные идентификаторы ресурса (УИР; URI) категории	UnknownCategoryURI, OfflineCategoryURI, BusyCategoryURI, AwayCategoryURI, OnlineCategoryURI
Статические вспомогательные функции	ConvertPresenceStateToString – форматирует состояние присутствия в качестве локализованной строки (фактически необходимо добавить локализацию; именно то, что делает дружественная английская строка в настоящее время).
Category	ГУИД (ID) категории	Home, Work, Primary, Secondary, Cell, Fax, Pager
EmailAddress	Производные свойства	Address – объединяет имя пользователя и домен
Статические вспомогательные функции	IsValidEmailAddress
Folder	Производные свойства	GetChildItemCollection – создает коллекцию предметов, основанную на Targets из FolderMembership.
Статические вспомогательные функции	GetKnownFolder – специализированные запросы для получения общеизвестных папок
	AddToPersonalContacts – добавляет предмет к общеизвестной папке персональных контактов
Items	Статические вспомогательные функции	GetItemFromID – выполняет запрос, основанный на ИД (ID)
Relationship	Вспомогательные функции экземпляра	BindToTarget – возвращает Item для Target
Person	Производные коллекции	PersonalRealtimeAddresses, PersonalEmailAddresses, PersonalTelephoneNumbers
Производные свойства	OnlineStatus, OnlineStatusIconSource, PrimaryEmailAddress, PrimarySecurityID
Статические вспомогательные функции	CreatePersonalContact, CreateTemporaryContact – создает новую личность в общеизвестной папке
GetCurrentUser – получает Person для зарегистрированного в настоящее время пользователя
SecurityID	Производные свойства	UserName, DomainName, DomainUserName
TelephoneNumber	Вспомогательные функции экземпляра	SetFromUserInputString – выполняет синтаксический разбор строки телефонного номера на части
Статические вспомогательные функции	ParseNumber – выполняет синтаксический разбор строки телефонного номера на части
User	Вспомогательные функции экземпляра	AutoLoginToAllProfiles – регистрирует все профили, которые отмечены для автоматической регистрации

16. ИПП (API) файла платформы хранения

В данном разделе представлен обзор ИПП (API) Файла платформы хранения согласно одному варианту осуществления настоящего изобретения.

а) Введение

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

Платформа хранения обеспечивает способ индексирования по содержимому в существующих томах ФСНТ (NTFS). Это выполняется посредством извлечения («распространения») свойств из каждого файлового потока или каталога в ФСНТ (NTFS) и сохранения этих свойств в качестве Предметов в платформе хранения.

Схема Файла платформы хранения определяет два типа предметов – File и Directory – для хранения распространенных сущностей файловой системы. Тип Directory представляет собой подтип типа Folder; он представляет собой папку включения, которая содержит другие предметы Directory или предметы File.

Предмет Directory может содержать предметы Directory и File; он не может содержать предметы любого другого типа. Что касается платформы хранения, то предметы Directory и File являются только для чтения из любого ИПП (API) доступа к данным. Служба диспетчера распространения файловой системы (FSPM) асинхронно распространяет измененные свойства в платформу хранения. Свойства предметов File и Directory могут быть изменены посредством ИПП (API) Win32. ИПП (API) платформы хранения может использоваться для считывания любых свойств этих предметов, включая поток, ассоциированный с предметом File.

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

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

Остальная часть пространства имен этого тома может содержать обычный диапазон типов предметов платформы хранения – Principal, Organization, Document, Folder и т.д. Платформа хранения также позволяет создавать Файлы и Каталоги в любой части пространства имен платформы хранения. Эти «родные» Файлы и Каталоги не имеют эквивалентов в файловой системе ФСНТ (NTFS); они хранятся исключительно в платформе хранения. Кроме того, изменения в свойствах немедленно становятся видимыми.

Однако модель программирования остается такой же: они все же остаются только для чтения, что касается ИПП (APIs) доступа к данным платформы хранения. «Родные» Файлы и Каталоги должны обновляться с использованием ИПП (APIs) Win32. Это упрощает интеллектуальную модель разработчика, которая представляет собой:

1. Любой тип предмета платформы хранения может создаваться в любом месте в пространстве имен (если только не предотвращается разрешениями, конечно).

2. Любой тип предмета платформы хранения может считываться с использованием ИПП (API) платформы хранения.

3. Любые типы предметов платформы хранения являются записываемыми с использованием ИПП (API) платформы хранения, за исключением File и Directory.

4. Для записи в предметы File и Directory независимо от того, где они находятся в пространстве имен, использовать ИПП (API) Win32.

5. Изменения в предметах File/Directory в пространстве имен «распространения» могут не появляться немедленно в платформе хранения; в пространстве имен «без распространения» изменения отражаются немедленно в платформе хранения.

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

Фиг.25 иллюстрирует схему, на которой основывается ИПП (API) Файла.

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

ИПП (API) платформы хранения включает в себя пространство имен для работы с файловыми объектами. Это пространство имен называется System.Storage.Files. Члены данных классов в System.Storage.Files непосредственно отражают информацию, хранимую в хранилище платформы хранения; «распространяется» эта информация из объектов файловой системы или эта информация может создаваться собственным образом с использованием ИПП (API) Win32. Пространство имен System.Storage.Files имеет два класса: FileItem и DirectoryItem. Члены этих классов и их методы легко могут быть предсказаны при взгляде на диаграмму схемы на фиг.25. FileItem и DirectoryItem только считываются из ИПП (API) платформы хранения. Чтобы модифицировать их, необходимо использовать ИПП (API) Win32 или классы в System.IO.

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

в данном разделе представлено три примера кода, иллюстрирующие использование классов в System.Storage.Files.

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

Этот пример показывает, как выполнить «традиционную» манипуляцию над файлом.

ItemContext ctx = ItemContext.Open();

if (!f.IsReadOnly)

{

FileStream fs = f.OpenWrite();

}

ctx.Close();

Строка 3 использует метод FindByPath для открытия файла. Строка 7 показывает использование свойства после его распространения IsReadOnly для проверки, является ли файл записываемым. Если да, тогда на строке 9 изобретатели используют метод OpenWrite() объекта FileItem для получения файлового потока.

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

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

FindResult result = FileItem.FindAll(

ctx,

“Modified >= ‘{0}'”,

DateTime.Now.AddDays(-3));

foreach ( FileItem file in result )

{

}

Вот другой пример использования запросов – в этом примере выполняется поиск всех записываемых файлов определенного типа (= расширение):

DirectoryItem dir =

FindResult result = dir.GetFiles(

“Extension=’cs’ and IsReadOnly=false”);

foreach ( File file in result )

{

}

е) Методы поведения доменов

В одном варианте осуществления, в дополнение к стандартным свойствам и методам, класс файлов также имеет методы поведения доменов (свойства и методы с ручным кодированием). Эти методы поведения, в основном, основываются на методах в соответствующих классах System.IO.

J. ЗАКЛЮЧЕНИЕ

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

Как очевидно из вышеупомянутого, все или части различных систем, способов и аспектов настоящего изобретения могут реализовываться в виде программного кода (т.е. инструкций). Этот программный код может запоминаться на считываемых компьютером носителях, таких как магнитные, электрические или оптические носители данных, включая без ограничения дискеты, компакт-диски (CD-ROM), перезаписываемые компакт-диски (CD-RW), ЦМД, предназначенные только для чтения (DVD-ROM), перезаписываемые ЦМД (DVD-RAM), магнитную ленту, флэш-память, накопитель на жестких дисках или любой другой считываемый машиной носитель данных, в котором, когда программный код загружается и исполняется машиной, такой как компьютер или сервер, машина становится устройством для осуществления на практике изобретения. Настоящее изобретение также может осуществляться в виде программного кода, который передается по некоторой среде передачи данных, такой как по электрическим проводам или кабелям, по оптоволоконным кабелям, по сети, включая Интернет или интрасеть, или при помощи любого другого вида передачи, при которой, когда программный код принимается и загружается и исполняется машиной, такой как компьютер, машина становится устройством для осуществления на практике изобретения. При реализации на процессоре общего назначения программный код объединяется с процессором и обеспечивает уникальное устройство, которое работает аналогично специальным логическим схемам.

ПРИЛОЖЕНИЕ А

namespace System.Storage

{

abstract class ItemContext: IDisposable, IServiceProvider

{

Члены создания и управления ItemContext

interal ItemContext();

public static ItemContext Open();

public static ItemContext Open( string path );

public static ItemContext Open( params string[] paths );

public string[] GetOpenPaths();

public ItemContext Clone();

public void Close();

void IDisposable.Dispose();

public bool IsRemote { get; }

public object GetService( Type serviceType );

Относящиеся к обновлению члены

public void Update();

public void Update( object objectToUpdate );

public void Update( IEnumerable objectsToUpdate );

public void Refresh( object objectToRefresh );

public void Refresh( IEnumerable objectsToRefresh );

public event ChangeCollisionEventHandler UpdateCollision;

public event UpdateProgressEventhandler UpdateProgress;

public IAsyncResult BeginUpdate( IAsyncCallback callback, object state );

public IAsyncResult BeginUpdate( object objectToUpdate,

IAsyncCallback callback,

object state );

public IAsyncResult BeginUpdate( IEnumerable objectsToUpdate,

IAsyncCallback callback,

object state );

public void EndUpdate( IAsyncResult result);

public IAsyncResult BeginRefresh( object objectToRefresh,

IAsyncCallback callback,

object state );

public IAsyncResult BeginRefresh( IEnumerable objectsToRefresh,

IAsyncCallback callback,

object state );

public void EndRefresh( IAsyncResult result );

Относящиеся к транзакции члены

public Transaction BeginTransaction();

public Transaction BeginTransaction( System.Data.IsolationLevel isolationLevel );

Относящиеся к поиску члены

public ItemSearcher GetSearcher( Type type );

public Item FindItemById( ItemId ItemId );

используемый ресурс домена для извлечения предмета.

public Item FindItemByPath( string path );

public Item FindItemByPath( string domain, string path );

public FindResult FindAllItemsByPath( string path );

public Relationship FindRelationshipById( ItemId itemID,

RelationshipId relationshipId );

public ItemExtension FindItemExtensionById( ItemId itemId,

ItemExtensionId itemExtensionId );

public FindResult FindAll( Type type);

public FindResult FindAll( Type type, string filter );

public object FindOne( Type type, string filter );

public object FindOnly( Type type, string filter );

public bool Exists( Type type, string filter );

public SearchCollisionMode SearchCollisionMode { get; set; }

public event ChangeCollisionEventHandler SearchCollision;

public Item IncorporateItem( Item item );

public Relationship IncorporateRelationship( Relationship relationship );

public ItemExtension IncorporateItemExtension( ItemExtension itemExtension );

}

public delegate void ChangeCollisionEventHandler( object source,

ChangeCollisionEventArgs args );

public class ChangeCollisionEventArgs : EventArgs

{

public object ModifiedObject { get; }

public IDictionary StoredProperties { get; }

}

public delegate void UpdateProgressEventHandler( ItemContext item Context,

UpdateProgressEventArgs args );

public class ChangeCollisionEventArgs : EventArgs

{

public UpdateOperation CurrentOperation { get; }

public object CurrentObject { get; }

}

public enum SearchCollisionMode

{

DoNotMapSearchResults,

PreserveModifiedObjects,

OverwriteModifiedObjects

}

public enum UpdateOperation

{

OverallUpdateStarting,

OverallUpdateCompletedSucessfuIly,

OverallUpdateCompletedUnsuccessfully,

ObjectUpdateStaring,

OpeningConnection

}

}

ПРИЛОЖЕНИЕ В

namespace System.Storage

{

public class ItemSearcher

{

Конструкторы

public ItemSearcher();

public ItemSearcher( Type targetType, ItemContext context );

public ItemSearcher( Type targetType, ItemContext context,

params SearchExpression[] filters );

Свойства

public SearchExpressionCollection Filters {get;}

public ItemContext ItemContext {get; set;}

public ParameterCollection Parameters {get;}

public Type TargetType {get; set;}

Методы поиска

public FindResult FindAll();

public FindResult FindAll( FindOptions findOptions );

public FindResult FindAll( params SortOption[] sortOptions );

public object FindOne();

public object FindOne( FindOptions findOptions );

public object FindOne( params SortOption[] sortOptions );

public object FindOnly();

public object FindOnly( FindOptions findOptions );

public bool Exists();

public PreparedFind PrepareFind();

public PreparedFind PrepareFind( FindOptions findOptions );

public PreparedFind PrepareFind( params SortOption[] sortOptions );

public int GetCount();

public IAsyncResult BeginFindAll( AsyncCallback callback,

object state );

public IAsyncResult BeginFindAll( FindOptions findOptions,

AsyncCallback callback,

object state );

public IAsyncResult BeginFindAll( SortOption[] sortOptions,

AsyncCallback callback,

object state );

public FindResult EndFindAll( IAsyncResult ar );

public IAsyncResult BeginFindOne( AsyncCallback callback,

object state );

public IAsyncResult BeginFindOne( FindOptions findOptions,

AsyncCallback callback,

object state );

public IAsyncResult BeginFindOne( SortOption[] sortOptions,

AsyncCallback callback,

object state );

public object EndFindOne( IAsyncResult asyncResult);

public IAsyncResult BeginFindOnly( AsyncCallback callback,

object state );

public IAsyncResult BeginFindOnly( FindOptions findOptions,

AsyncCallback callback,

object state );

public IAsyncResult BeginFindOnly( SortOption[] sortOptions,

AsyncCallback callback,

object state );

public object EndFindOnly( IAsyncResult asyncResult );

public IAsyncResult BeginGetCount( AsyncCallback callback,

object state );

public int EndGetCount( IAsyncResult asyncResult );

public IAsyncResult BeginExists( AsyncCallback callback,

object state );

public bool EndExists( IAsyncResult asyncResult );

public class FindOptions

{

public FindOptions();

public FindOptions( params SortOption[] sortOptions );

public bool DelayLoad {get; set;}

public int MaxResults {get; set;}

public SortOptionCollection SortOptions {get;}

}

public class Parameter

{

public Parameter( string name, object value );

public string Name {get;}

public object Value {get; set;}

}

public class ParameterCollection : ICollection

{

public ParameterCollection();

public int Count {get;}

public object this[string name] {get; set;}

public object SyncRoot {get;}

public void Add( Parameter parameter );

public Parameter Add( string name, object value );

public bool Contains( Parameter parameter);

public bool Contains( string name );

public void CopyTo( Parameter[] array, int index );

void ICollection.CopyTo( Array array, int index );

IEnumerator IEnumerable.GetEnumerator();

public void Remove( Parameter parameter );

public void Remove( string name );

}

public class PreparedFind

{

public ItemContext ItemContext {get;}

public ParameterCollection Parameters {get;}

public FindResult FindAll();

public object FindOne();

public object FindOnly();

public bool Exists();

}

public class SortOption

{

public SortOption();

public SortOption( SearchExpression searchExpression, SortOrder order );

public SearchExpression Expression {get; set;}

public SortOrder Order {get; set;}

}

public class SortOptionCollection : IList

{

public SortOptionCollection();

public SortOption this[int index] {get; set;}

public int Add( SortOption value );

public int Add( SearchExpression expression, SortOrder order );

int IList.Add( object value );

public void Clear();

public bool Contains( SortOption value );

bool IList.Contains( object value );

public void CopyTo( SortOption[] array, int index );

void ICollection.CopyTo( Array array, int index );

public int Count {get;}

IEnumerator IEnumerable.GetEnumerator();

public void Insert( int index, SortOption value );

void IList.Insert( int index, object value );

public int IndexOf( SortOption value );

int IList.IndexOf( object value );

public void Remove( SortOption value );

void IList.Remove( object value );

public void RemoveAt( int index );

public object SyncRoot {get;}

}

public enum SortOrder

{

Ascending,

Descending

}

}

ПРИЛОЖЕНИЕ С

namespace System.Storage

{

public abstract class FindResult: IAsyncObjectReader

{

public FindResult();

public bool Read();

public IAsyncResult BeginRead( AsyncCallback callback, object state );

public bool EndRead( IAsyncResult asyncResult);

public object Current {get;}

public bool HasResults {get;}

public bool IsClosed {get;}

public Type ObjectType {get;}

public void Close();

void IDisposable.Dispose();

IEnumerator IEnumerable.GetEnumerator();

public FindResultEnumerator GetEnumerator();

}

public abstract class FindResultEnumerator : IEnumerator, IDisposable

{

public abstract object Current { get; }

public abstract bool MoveNext();

public abstract void Reset();

public abstract void Close();

void IDisposable.Dispose();

}

}

namespace System

{

public interface IObjectReader : IEnumerable, IDisposable

{

object Current {get;}

bool IsClosed {get;}

bool HasResults {get;}

Type ObjectType {get;}

bool Read();

void Close();

}

public interface IAsyncObjectReader : IObjectReader

{

IAsyncResult BeginRead( AsyncCallback callback, object state );

bool EndRead( IAsyncResult result );

}

}

Формула изобретения

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

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

3. Способ по п.1, в котором дополнительно организуют хранилище данных таким образом, что хранилище данных содержит множество Предметов, причем упомянутое множество Предметов содержит Категорию и по меньшей мере один другой Предмет, который является членом упомянутой Категории.

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

5. Способ по п.1, в котором каждый Предмет из набора основных Предметов выводят из Общего Единственного Базового Предмета.

6. Способ по п.1, в котором упомянутый Общий Единственный Базовый Предмет представляет собой основополагающий Предмет в Базовой Схеме.

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

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

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

10. Считываемый компьютером носитель по п.7, дополнительно содержащий исполняемые компьютером инструкции для организации хранилища данных таким образом, что хранилище данных содержит второй Элемент, и в котором упомянутая Связь содержит упомянутый второй Элемент.

11. Компьютерная система, содержащая:
процессор и
память, содержащую:
Предмет;
Элемент;
Множество Связей, содержащих связи Включения и Ссылки, причем связи Включения управляют временем существования Предметов, причем упомянутые связи Включения классифицируют на связи Прикрепления и Внедрения, причем Предмет удаляют, когда удаляют все связи Прикрепления для Предмета;
причем упомянутый Предмет представляет собой единицу данных, хранимую в хранилище данных, и имеет, по меньшей мере, один из типа или подтипа и включает в себя упомянутый Элемент и упомянутое Множество Связей, причем упомянутый Элемент представляет собой экземпляр типа, содержащий одно или несколько полей, и причем упомянутое Множество Связей представляет собой связывание, по меньшей мере, между двумя Предметами;
Базовую Схему, которая устанавливает структуру для создания и организации каждого Предмета и устанавливает основополагающий набор свойств; и
Основную Схему, которая определяет набор основных типов, причем каждый Предмет характеризуется в, по меньшей мере, одном основном типе, основанном на типе Предмета или подтипе Предмета.

12. Компьютерная система по п.11, в которой память содержит множество Предметов, причем упомянутое множество Предметов содержит Папку Предметов и по меньшей мере один другой Предмет, который является членом упомянутой Папки Предметов.

13. Компьютерная система по п.11, в которой память содержит множество Предметов, причем упомянутое множество Предметов содержит Категорию и, по меньшей мере, один другой Предмет, который является членом упомянутой Категории.

14. Компьютерная система по п.11, в которой память содержит второй Элемент и в которой упомянутая Связь содержит упомянутый второй Элемент.

РИСУНКИ