Системы и способы для обеспечения услуг синхронизации для блоков информации, управляемых аппаратной/программной интерфейсной системой

Системы и способы для обеспечения услуг синхронизации для блоков информации, управляемых аппаратной/программной интерфейсной системой

Иллюстрации

Показать все

Реферат

Настоящая заявка испрашивает приоритет по заявке на патент США №10/692,515 (номер в реестре поверенного MSFT-2844), поданной 24 октября 2004, озаглавленной "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; заявке на патент США №10/646,575 (номер в реестре поверенного MSFT-2733), поданной 21 августа 2003, озаглавленной "SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM"; и международной заявке №PCT/US 03/26150 (номер в реестре поверенного 2777), поданной 21 августа 2003, озаглавленной "SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM"; раскрытия которых включены в описание по ссылке в их полном содержании.

Настоящая заявка связана объектом изобретения с изобретениями, раскрытыми в следующих заявках, права на которые обычным образом переданы, содержание которых тем самым включено в эту настоящую заявку в их полноте (и частично кратко изложены для удобства): заявка на патент США №10/647,058 (номер в реестре поверенного MSFT-1748), поданная 21 августа 2003, озаглавленная "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION"; заявка на патент США №10/646,941 (номер в реестре поверенного MSFT-1749), поданная 21 августа 2003, озаглавленная "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION"; заявка на патент США №10/646,940 (номер в реестре поверенного MSFT-1750), поданная 21 августа 2003, озаглавленная "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; заявка на патент США №10/646,632 (номер в реестре поверенного MSFT-1751), поданная 21 августа 2003, озаглавленная "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"; заявка на патент США №10/646,645 (номер в реестре поверенного MSFT-1752), поданная 21 августа 2003, озаглавленная "SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; заявка на патент США №10/646,646 (номер в реестре поверенного MSFT-2734), поданная 21 августа 2003, озаглавленная "STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA"; заявка на патент США №10/646,580 (номер в реестре поверенного MSFT-2735), поданная 21 августа 2003, озаглавленная "SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM"; заявка на патент США №10/692,779 (номер в реестре поверенного MSFT-2829), поданная 24 октября 2003, озаглавленная "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; заявка на патент США №10/692,508 (номер в реестре поверенного MSFT-2845), поданная 24 октября 2003, озаглавленная "SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; заявка на патент США №10/693,362 (номер в реестре поверенного MSFT-2846), поданная 24 октября 2003, озаглавленная "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"; и заявка на патент США №10/693,574 (номер в реестре поверенного MSFT-2847), поданная 24 октября 2003, озаглавленная "SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM".

Область техники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель данных, реализованная хранилищем данных, определяет модули хранения данных в терминах порций данных (Items), элементов (elements) и отношений (relationship). Порция данных (Item) - блок данных, сохраняемых в хранилище данных и который может содержать один или более элементов и отношений. Элемент - экземпляр такого типа, который содержит одно или более полей (также называемых как свойство). Отношение - связь между двумя порциями данных. (Используемые здесь эти и другие специфические термины могут быть напечатаны прописными буквами, чтобы отличить их от других терминов, используемых в близком смысле; однако обычно не имеется никакого намерения отличать напечатанный прописными буквами термин, например "Порция данных" (Item), и тот же самый термин, не напечатанный прописными буквами, например, "порция данных" (item), и никакое такое различие не должно предполагаться или подразумеваться.)

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

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

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

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

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

В качестве части этой перекрывающейся структуры взаимосвязанных изобретений (описанной подробно в разделе II подробного описания) настоящее изобретение конкретно посвящено API синхронизации (описанный подробно в Разделе III подробного описания). Другие признаки и преимущества изобретения очевидны из нижеследующего подробного описания изобретения и сопроводительных чертежей.

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

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

На чертежах:

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

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

аппаратный компонент, аппаратный/программный компонент интерфейсной системы и компонент прикладных программ;

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

Фиг.3 изображает схематическую диаграмму, иллюстрирующую платформу хранения;

Фиг.4 иллюстрирует структурные отношения между Порциями данных. Папками Порций данных и Категориями;

Фиг.5А изображает схематическую диаграмму, иллюстрирующую структуру Порции данных;

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

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

Фиг.6А иллюстрирует Порцию данных как подтип Порции данных, найденной в Базовой Схеме;

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

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

Фиг.8А изображает схематическую диаграмму, иллюстрирующую Порции данных в Основной Схеме;

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

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

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

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

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

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

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

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

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

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

Фиг.18 иллюстрирует концепцию Папок Включения;

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

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

Фиг.21А изображает графическое представление примерной схемы Порции данных "Контакты";

Фиг.21В изображает графическое представление Элементов для примерной схемы Порции данных "Контакты" на фиг.21А;

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

Фиг.23 иллюстрирует выполнение операции "FindAll";

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

Фиг.25 иллюстрирует схему, на которой основан API File;

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

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

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

Фиг.29 изображает диаграмму, иллюстрирующую примерную иерархию Порций данных;

Фиг.30А иллюстрирует интерфейс Interface1 как канал, через который связываются первый и второй сегменты кода;

Фиг.30В иллюстрирует интерфейс как содержащий объекты I1 и I2 интерфейсы, которые дают возможность первому и второму сегментам кода системы обмениваться через среду М;

Фиг.31А иллюстрирует, как функция, обеспеченная интерфейсом Interface1, может быть подразделена для преобразования обменов интерфейса в множество интерфейсов Interface1A, Interface1B, Interface1C;

Фиг.31В иллюстрирует, как функция, обеспеченная интерфейсом II, может быть подразделена на множество интерфейсов 11а, 11b, 11 с;

Фиг.32А иллюстрирует сценарий, где ненужная точность параметра может быть игнорирована или заменена произвольным параметром;

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

Фиг.33А иллюстрирует сценарий, где 1-й и 2-й Сегменты Кода объединены в модуль, содержащий их оба;

Фиг.33В иллюстрирует сценарий, где часть или весь интерфейс могут быть вписаны в другой интерфейс, чтобы формировать объединенный интерфейс.

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

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

Фиг.35А иллюстрирует, как динамический компилятор (JIT) может преобразовывать обмены информацией из одного сегмента кода в другой сегмент кода;

Фиг.35В иллюстрирует JIТ-метод динамической перезаписи одного или более интерфейсов, которые могут применяться, чтобы динамически разделять или иначе изменять упомянутый интерфейс;

Фиг.36 иллюстрирует три экземпляра обычного хранилища данных и компоненты для их синхронизации; и

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

Подробное описание

ОГЛАВЛЕНИЕ

I. ВВЕДЕНИЕ

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

В. ТРАДИЦИОННАЯ ПАМЯТЬ, ОСНОВАННАЯ НА ФАЙЛАХ

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

А. ГЛОССАРИЙ

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

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

1. Порции данных

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

3. Папки Порции данных и Категории

4. Схемы

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

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

5. Отношения

a) Объявление Отношения

b) Отношение Хранения

c) Отношения Внедрения

d) Отношения Ссылки

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

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

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

a) Расширения Порции данных

b) Расширяющие типы NestedElement

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

1. Реализация Хранилища Данных, используя UDT

2. Отображение Порции данных

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

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

5. Идентичность Объектов

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

7. Наименование Столбцов

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

a) Порция данных

(1) Главное представление поиска Порции данных

(2) Имеющие тип представления поиска Порции данных

b) Расширения Порции данных

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

(2) Имеющие тип представления поиска Расширения

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

d) Отношения

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

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

е)

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

10. Отслеживание изменений & оповещения

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

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

(2) Отслеживание изменений в "имеющих тип" представлениях поиска

b) Оповещения

(1) Оповещения Порции данных

(2) Оповещения Расширения

(3) Оповещение Отношений

(4) Очистка Оповещения

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

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

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

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

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

a) Схема Метаданные

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

Е. ЗАЩИТА

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

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

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

III. API СИНХРОНИЗАЦИИ

А. КРАТКИЙ ОБЗОР СИНХРОНИЗАЦИИ

1. Синхронизация "Платформа хранения - Платформа хранения"

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

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

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

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

(2) Профили

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

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

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

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

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

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

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

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

(c) Проверка и разрешение конфликтов

(d) Сходимость точных копий и распространение

24 разрешения конфликтов

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

a) Услуги синхронизации

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

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

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

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

3. Защита

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

В. КРАТКИЙ ОБЗОР API СИНХРОНИЗАЦИИ

1. Общая Терминология

2. Принципы API Синхронизации

С. УСЛУГИ API СИНХРОНИЗАЦИИ

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

2. Применение изменений

3. Код образца

4. Способы API синхронизации

D. ДОПОЛНИТЕЛЬНЫЕ АСПЕКТЫ SYNC-СХЕМЫ IV.

ЗАКЛЮЧЕНИЕ

Введение

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

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

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

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