ИНТЕРФЕЙС ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ ХРАНИЛИЩА ДЛЯ ОБЩЕЙ ПЛАТФОРМЫ ДАННЫХ Российский патент 2010 года по МПК G06F13/00 

Настоящая заявка испрашивает приоритет по предварительной заявке на выдачу патента США с серийным номером 60/657,522, озаглавленной «ИПП ХРАНИЛИЩА ДЛЯ ОБЩЕЙ ПЛАТФОРМЫ ДАННЫХ», поданной 28 февраля 2005. Эта заявка связана с предварительной заявкой на выдачу патента США с серийным номером 60/657,556, озаглавленной «ПЛАТФОРМА ДЛЯ УСЛУГ ПО ПЕРЕДАЧЕ ДАННЫХ ПО НЕРАВНОПРАВНЫМ ПРИКЛАДНЫМ СТРУКТУРАМ», поданной 28 февраля 2005, заявкой на выдачу патента США с серийным номером 11/171,905, озаглавленной «ПЛАТФОРМА ДЛЯ УСЛУГ ПО ПЕРЕДАЧЕ ДАННЫХ ПО НЕРАВНОПРАВНЫМ ПРИКЛАДНЫМ СТРУКТУРАМ», поданной 30 июня 2005, предварительной заявкой на выдачу патента США с серийным номером 60/657,295, озаглавленной «МОДЕЛЬ ДАННЫХ ДЛЯ ОБЪЕКТНО-ОТНОСИТЕЛЬНЫХ ДАННЫХ», поданной 28 феврале 2005, и заявкой на выдачу патента США (номер дела поверенного MSFTP974USA), озаглавленной «МОДЕЛЬ ДАННЫХ ДЛЯ ОБЪЕКТНО-ОТНОСИТЕЛЬНЫХ ДАННЫХ». Содержание вышеупомянутых заявок включено в настоящие материалы посредством ссылки.

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

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

Традиционно, клиент/серверные приложения отсылали запрос и действия по перманентным объектам к системам управления базой данных (СУБД), используемой в ярусе данных. Если имеется логика, интегрированная по данным, ее кодируют, как сохраненные процедуры в системе базы данных. Система базы данных оперирует данными в выражении таблицами и строками, и приложения, в ярусе приложений, оперируют данными в выражении объектами языка программирования (например/ Классами и Структурами). Несоответствие в услугах по обработке данных (и механизмах) в приложении и ярусах данных было терпимо в клиент/серверных системах. Однако, с появлением сетевой технологии (и Сервис-Ориентированной Архитектуры) и с более широким принятием серверов приложений, приложения становятся многоярусными, и, что еще более важно, данные теперь присутствуют в каждом ярусе.

В такой ярусной прикладной архитектуре данные обрабатывают во множестве ярусов. Кроме того, в связи с аппаратными усовершенствованиями в адресуемости и большими объемами памяти, больше данных становятся резидентными. Приложения также имеют дело с различными типами данных, такими, как объекты, файлы и XML-данные (XML, РЯР, Расширяемый Язык Разметки), например.

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

Раскрытие изобретения

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

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

В другом аспекте ИПП включает в себя пять основных классов. Класс TableSet может быть выработан из схемы модели данных и обеспечивает доступ со строгим контролем типов к таблицам, заданным в схеме. Класс StorageDomain определяет хранилище, по которому работают остальные классы. Класс StorageContext обеспечивает контекст для сеанса. Класс StorageContext определяет область для управления идентификационными данными, отслеживания изменений и обработки конфликтов при совмещении операций с методами для обновления или сохранения изменений в объектах в текущем контексте. Классы StorageSearcher используют для построения компонуемых основывающихся на объектах запросов к хранилищу данных. Класс StorageView обеспечивает обширное представление приложения по набору результатов. Классы StorageView поддерживают операции, такие как фильтрация, сортировка, прокрутка, группирование, секционирование, растяжение/свертывание разделов и т.д.

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

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

Фиг.1 - интерфейс прикладного программирования (ИПП) хранилища платформы данных, в соответствии с новым аспектом.

Фиг.2 - методология, обеспечивающая ИПП хранилища, в соответствии с раскрытым аспектом.

Фиг.3 - более детальная схема компонента обобщенного доступа к данным ИПП хранилища.

Фиг.4 - методология обеспечения ИПП хранилища для модели данных.

Фиг.5 - методология экспонирования типов табличного набора.

Фиг.6 - методология обеспечения функциональных возможностей WinFS в ИПП.

Фиг.7 - методология представления класса в хранилище.

Фиг.8 - методология инкапсуляции подключения между клиентом и одним или несколькими хранилищами.

Фиг.9 - методология формирования запросов к хранилищу.

Фиг.10 - методология просмотра по набору результатов.

Фиг.11 - методология обеспечения начального представления данных по результатам.

Фиг.12 - методология расширения класса записи хранилища.

Фиг.13 - система, которая использует ИПП хранилища для общей платформы данных.

Фиг.14 - структурная схема компьютера, пригодного для выполнения раскрытой архитектуры.

Фиг.15 - схематичное структурное представление приводимой в качестве примера вычислительного окружения.

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

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

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

Новая общая платформа данных (CDP, ОПД) состоит из общей модели общих данных (CDM, ОМД), которая описывает объекты и как они связаны, и долговременного хранилища и услуг для работы с представлениями этих объектов «в памяти». ОПД обеспечивает новую платформу для работы с долговременными данными, как объектами приложений. ОПД включает в себя новый интерфейс прикладного программирования (ИПП), который выполнен специально под нижележащие модель данных и услуги, определенные как часть платформы. Функциональные возможности ОПД экспонируются через набор классов. Определение этих классов, включая их общедоступные члены (например, методы и свойства), включает в себя ИПП для работы с объектами в ОПД.

Обратимся вначале к Фиг.1, на которой представлен ИПП 100 хранилища платформы 102 данных (например, ОПД) в соответствии с новым аспектом. ИПП 100 обеспечивает интерфейс программирования для приложений, используя платформу данных (например, ОПД) в форме классов, интерфейсов и статических функций поддержки. Интеграция языка программирования базы данных (например, операторы последовательности С#) также представляет собой часть этого уровня ИПП. В поддержку этого ИПП 100 включает в себя компонент классов данных 104 ОМД, который является набором канонических, независимых от приложений классов, которые экспонируют концепты ОМД, такие как Сущность (Entity), Отношение (Relationship), Расширение (Extension) и т.д. Компонент 106 обобщенного доступа к данным обеспечен, как часть ИПП 100, чтобы экспонировать хранилища, сеансы, транзакции (например, StorageContext), услуги запроса (например, StorageSearcher) и услуги СООУ (например, SaveChanges). Услуги СООУ (Создать, Отыскать, Обновить и Удалить, CRUD) представляют собой основные процессы, которые применены к данным. ИПП 100 также включает в себя компонент 108 классов доменных данных, которые являются специфическими для конкретного приложения/инфраструктуры классами Контакт (Contact), Сообщение (Message), Заказы на Поставку (PurchaseOrders), которые соответствуют ОМД, но экспонируют доменно-ориентированные свойства и поведения.

На Фиг.2 представлена методология, обеспечивающая ИПП хранилища в соответствии с раскрытым аспектом. Несмотря на то, что для целей простоты объяснения одна или несколько представленных в настоящих материалах методологий, например, в виде блок-схемы или структурной схемы, показаны и описаны, как последовательность действий, понятным и очевидным является, что новое решение не ограничено порядком действий, поскольку некоторые действия могут, в соответствии с ним, происходить в ином порядке и/или одновременно с другими действиями, иными, чем показанные и описанные здесь. Например, для специалистов в данной области техники будет понятным и очевидным, что методология может альтернативно быть представлена как ряд взаимосвязанных состояний или событий таких, как в диаграмме состояния. Более того, для осуществления методологии в соответствии с новым решением могут потребоваться не все представленные действия. На 200 получают ИПП хранилища. На 202 ИПП определяет класс для запроса данных. На 204 ИПП определяет класс для извлечения данных. На 206, ИПП определяет класс для навигации по данным. На 208 ИПП определяет класс для модификации данных. На 210, ИПП определяет класс для сохранения данных.

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

ИПП 300 хранилища состоит из следующих основных классов и на Фиг.3 представлены отношения между StorageDomain, StorageContext, TableSet, StorageSearcher и StorageView. В поддержку этих основных классов могут быть определены дополнительные классы.

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

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

StorageContext - класс, который обеспечивает контекст для сеанса. Класс StorageContext определяет область для управления идентификационными данными, отслеживания изменений и обработки конфликтов при совмещении операций с методами для обновления или сохранения изменений в объектах в текущем контексте. Класс StorageContext использует Класс StorageDomain для связи с хранилищем (например, при обновлении данных или сохранении изменений). StorageContext может быть использован непосредственно или в связке с TableSet.

StorageSearcher - Классы StorageSearcher используются для построения компонуемого, основанного на объектах запроса к хранилищу данных. Класс StorageSearcher вырабатывает класс StorageExpression, который исполняется посредством StorageDomain, обычно в StorageContext. StorageSearcher поддерживает перечисление результатов однонаправленным поточным образом или построение обширного прокручиваемого StorageView.

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

Обратимся теперь к Фиг.4, на которой представлена методология обеспечения ИПП хранилища для модели данных. На 400 получают платформу данных (например, ОПД) для использования с хранилищем данных. На 402 обеспечивают ИПП, который включает в себя базовые классы, которые представляют концепты ОМД, такие как, например, сущность, отношение, расширение. Нижележащие функциональные возможности платформы данных могут быть экспонированы вышележащим приложениям и инфраструктурам приложений через общие классы данных ОМД, определенные в ИПП по предмету изобретения. На 404 обеспечивают класс, который определяет хранилище данных, по которому работают другие классы ИПП. На 406 обеспечивают класс, который используют для формирования основанных на объектах запросов к хранилищу данных. На 408 обеспечивают класс, который задает контекст сеанса и включает в себя управление идентификационными данными, отслеживание изменений, обработку конфликта и т.д. На 410 обеспечивают класс, который формирует из схемы и обеспечивает доступ со строгим контролем типов к таблицам схемы. На 412 обеспечивают класс, который обеспечивает просмотр набора(наборов) результатов. На 414 определяют набор специфических для конкретного домена классов для того, чтобы представлять конкретные сущности и отношения, описанные экземпляром схемы ОМД.

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

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

Класс WinFSDomain. Пример StorageDomain относительно хранилища WinFS может выглядеть следующим образом:

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

Класс SqlStorageDomain. Пример StorageDomain относительно реляционного хранилища (например, базы данных SQL) может выглядеть следующим образом:

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

На Фиг.5 представлена методология экспонирования типов табличного набора. На 500 получают базовый класс для типов таблицы. Класс TableSet используют как базовый класс для типов табличного набора. Экземпляры этого типа могут также быть созданы и использованы непосредственно приложением, если это желательно. Базовый тип TableSet имеет следующие члены:

public class TableSet: Idisposable

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

На 502 может быть обеспечен метод SaveChanges для сохранения объектов данных, ассоциированных с табличным набором. Может быть также обеспечена асинхронная версия этого метода. На 504, может быть обеспечен метод GetTable для конструирования и выдачи объекта, представляющего таблицу в схеме (например, Table<T>), на основании предоставленного имени. На 506 может быть обеспечен метод GetTableSetReference для выдачи TableSetReference.

На Фиг.6 представлена методология обеспечения функциональных возможностей WinFS в ИПП по предмету нового решения. На 600 применяют класс для функциональных возможностей WinFS. Класс WinFSData может быть получен в качестве производного от класса TableSet, для обеспечения специфических для WinFS функциональных возможностей. Класс WinFSData имеет следующие члены:

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

На 602 может быть обеспечен метод GetRootItem, для выдачи корня домена. Может быть также обеспечена асинхронная версия этого метода. На 604 может быть обеспечен метод GetItemByPath для выдачи элемента заданного его путем. Может быть также обеспечена асинхронная версия этого метода.

На 606 могут быть обеспечены свойства Items, ItemExtensions и ItemFragments для выдачи объектов, представляющих таблицы Items, ItemExtensions, и ItemFragments таблицы. На 608 может быть обеспечено свойство Link для выдачи объекта, представляющего таблицу Links. На 610 обеспечивают методы копирования, перемещения и удаления элементов. Может быть обеспечен метод Copyltem для копирования заданного элемента в другое местоположение в хранилище. Может быть обеспечен метод Moveltem для перемещения заданного элемента в пределах хранилища. Метод Deleteltem обеспечивает удаление заданного элемента из хранилища. На 612 обеспечивают методы для импорта и экспорта элементов. Может быть обеспечен метод Exportltem для экспорта заданного элемента из хранилища. Может быть обеспечен метод Importltem для импорта заданного элемента в хранилище. Также могут быть обеспечены асинхронные версии метода Copyltem, метода Moveltem, метода Deleteltem, метода Exportltem и метода Importltem.

На Фиг.7 показана методология представления класса в хранилище. На 700, задают класс, который представляет экстент в хранилище. Класс Table<Т> используют для представления экстента в хранилище. Класс Table<Т> может содержать методы добавления или удаления объектов в экстенте, а также для построения StorageSearcher по содержимому экстента.

Класс Table<Т> может быть создан с информацией, которая задает StorageContext или StorageDomain, наряду с именем соответствующей таблицы в схеме. На 702 может быть обеспечено свойство Context для выдачи StorageContext, ассоциированного с классом Table<Т>. На 704 может быть обеспечено свойство Domain для выдачи StorageDomain, ассоциированного с классом Table<T>. На 706 может быть экспонировано свойство Searcher для выдачи StorageSearcher по соответствующей таблице в хранилище. На 708 обеспечиваются методы добавления, удаления и очистки объектов. Метод Add может быть экспонирован для того, чтобы добавлять объект в таблицу. Метод Remove может быть экспонирован для того, чтобы определять объект, который будет удален из таблицы. Метод Clear может быть экспонирован для того, чтобы очищать таблицу. На 710 метод Contains может быть экспонирован для того, чтобы выдать, содержит или нет таблица заданный объект. На 712 метод Count может быть экспонирован для того, чтобы задавать общее количество объектов в таблице. На 714 обеспечивают метод, который копирует объекты в таблицу. На 716 обеспечивают свойство, которое экспонирует то, является ли таблица доступной только для чтения. Метод СоруТо может быть экспонирован для того, чтобы копировать заданные объекты в таблицу. Свойство IsReadOnly может быть экспонировано для того, чтобы выдать то, действительно ли в отношении таблицы может быть выполнено добавление или удаление.

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

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

На 802 обеспечивают метод, который выдает объект по ключу. Метод GetObjectByKey может быть обеспечен для выдачи объекта в пределах StorageContext, ассоциированного с конкретным ключом. Этот метод в качестве альтернативы может быть развернут в отдельный объект StateManagement. Асинхронная версия этого метода может также быть обеспечена. На 804 может быть обеспечен метод GetObjectKey для выдачи ключа, ассоциированного с конкретным объектом в StorageContext. Этот метод может в качестве альтернативы быть развернут в отдельный объект StateManagement. На 806 может быть обеспечен метод SaveChanges для сохранения, добавления, удаления или модификации объекта в StorageContext. Также может быть обеспечена асинхронная версия этого метода.

На 808 может быть обеспечен метод Refresh для обновления объектов в StorageContext текущими значениями хранилища. Может быть задан явный набор объектов для обновления, например, посредством перечислителя или как параметры. Дополнительные варианты могут быть определены для управления тем, как обрабатывать конфликты изменений. Также может быть обеспечена асинхронная версия этого метода. На 810 метод Add может быть обеспечен для ассоциирования нового объекта с StorageContext. Этот метод может в качестве альтернативы быть развернут в отдельный объект StateManagement. На 812 может быть обеспечен метод MarkForDeletion для помечания объекта в StorageContext, который подлежит удалению при вызове SaveChanges. Этот метод в качестве альтернативы может быть развернут в отдельный объект StateManagement. На 814 может быть обеспечено свойство StorageDomain для выдачи StorageDomain, ассоциированного с StorageContext.

На Фиг.9 представлена методология формирования запросов к хранилищу. На 900 определяют базовый класс для формирования запросов к хранилищу. Класс StorageSearcher используют для формирования компонуемых основанных на объектах запросов к хранилищу. StorageSearcher вырабатывает StorageExpression, который исполняется посредством StorageDomain, обычно в пределах StorageContext. StorageSearcher поддерживает результаты перечисления однонаправленным поточным образом или путем построения обширного прокручиваемого StorageView.

StorageSearcher может быть сконструирован с StorageContext или StorageDomain для задания контекста или хранилища, с которым связан StorageSearcher. Дополнительно, выражение запроса может быть задано так, чтобы инициализировать StorageSearcher либо как строку, либо как дерево объектов StorageExpression.

На 902 может быть обеспечен метод Query для создания нового StorageSearcher, который инкапсулирует произвольное выражение запроса. На 904 обеспечивают методы фильтрования. Метод Filter может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует фильтр по результатам запроса, которые вырабатывает средство поиска по входным данным (входной искатель). Может быть обеспечен метод FilterByType для конструирования нового StorageSearcher, который инкапсулирует фильтр по результатам запроса, которые вырабатывает входной искатель. Может быть обеспечен метод TreatAsType для конструирования нового StorageSearcher, который обрабатывает результаты запроса, которые вырабатывает входной искатель, как иной тип.

На 906 обеспечивают методы Sort, Project, Group и Union. Метод Sort может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует сортировку результатов запроса, вырабатываемых входным искателем. Метод Project может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует проекцию результатов запроса, вырабатываемых входным искателем. Метод Group может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует группировку результатов запроса, которые вырабатывает входной искатель. Метод Union может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует объединение результатов запроса, которые вырабатывают два входных искателя. Вышеупомянутое представляет собой только примеры, которые не должны рассматриваться как ограничивающие. Дополнительно могут быть обеспечены методы StorageSearcher для представления дополнительных операций запроса. Другими словами, операции запроса могут быть экспонированы как методы класса StorageSearcher, который выдает новые StorageSearchers.

На 908 может быть обеспечен метод GetEnumerator для выдачи перечислителя, который может быть использован для доступа к результатам запроса. Может быть также обеспечена асинхронная версия этого метода. На 910 обеспечиваются методы, которые выдают первый результат запроса. Могут также быть обеспечены асинхронные версии этих методов. Может быть обеспечен метод GetFirst для выдачи первого результата. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод GetCount для выдачи подсчета результатов. Может также быть обеспечена асинхронная версия этого метода. На 912 может быть обеспечен метод CreateView для создания StorageView из запроса StorageSearcher. Метод CreateView может принять StorageViewDefinition с дополнительными опциями или без них для задания информации, специфической для конкретного просмотрового вида.

Класс StorageRecord используется как тип результата искателя, когда по запросу выдаются данные, которые не соответствуют никакому конкретному типу, определенному приложением. Например, результат операции Project или Group является совокупностью объектов StorageRecord.

На Фиг.10 представлена методология рассмотрения по набору результатов. На 1000 обеспечивают класс для просмотра результатов. Класс StorageView обеспечивает обширный просмотровый вид приложения по набору результатов. StorageView поддерживает такие операции, как фильтрация, сортировка, прокрутка, группировка, секционирование, растяжение/свертывание разделов и т.д.

Ha 1002 может быть обеспечен метод CopyDefinition для создания нового экземпляра StorageViewDefinition. Может быть обеспечен метод ApplyDefinition для применения заданного StorageViewDefinition к текущему StorageView. Также может быть обеспечена асинхронная версия этого метода. На 1004 обеспечивают методы для нахождения записей, выдачи подсчетов записей и текущей записи. Может быть обеспечен метод FindRecord для обнаружения StorageViewRecord в текущем StorageView, в соответствии с заданным фильтром, относительно заданной позиции или закладки. Может также быть обеспечена асинхронная версия этого метода. Метод Count может быть обеспечен для выдачи количества записей в текущем StorageView. Может также быть обеспечена асинхронная версия этого метода. Метод Current может быть обеспечен для выдачи текущего StorageViewRecord в пределах StorageView.

На 1006 может быть обеспечено индексированное средство доступа (например, this[]) для выдачи StorageViewRecord для данной Bookmark. Может также быть обеспечена асинхронная версия этого метода. На 1008 обеспечивают методы для перемещения позиции и обновления просмотрового вида. Может быть обеспечен метод MoveCurrentPosition для перемещения текущей позиции в пределах StorageView в соответствии с заданной позицией или закладкой и смещением. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод Refresh для обновления данных в статическом StorageView текущими значениями из хранилища. Может также быть обеспечена асинхронная версия этого метода. На 1010, обеспечивают методы получения закладок и двоичного их представления. Может быть обеспечен метод GetBookraarkFroraBinary для получения закладки из постоянного двоичного представления. Может быть обеспечен метод GetBinaryFromBookmark для получения постоянного двоичного представления из Bookmark.

На 1012 обеспечивают методы для растяжения, свертывания разделов, уровней и полей. Может быть обеспечен метод CollapseAllSections для свертывания всех разделов, определенных в пределах StorageView. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод ExpandAllSections для расширения всех разделов, определенных в пределах StorageView. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод ExpandSectionLevel для растяжения всех разделов, вплоть до и включая заданный уровень. Может также быть обеспечена асинхронная версия этого метода.

На 1014 обеспечивают метод для расширения полей записей. Может быть обеспечен метод SetExtendedFields для того, чтобы задать расширенные поля, ассоциированные с набором StorageViewRecords. На 1016 обеспечивают методы для сохранения и загрузки состояния растянутых разделов. Может быть обеспечен метод LoadSectionExpandState для загрузки состояния, определяющего набор разделов, которые растянуты. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод SaveSectionExpandState для того, чтобы сохранять состояние, задающее набор разделов, которые растянуты. StorageView может экспонировать событие ViewChanged для уведомления средства прослушивания, когда StorageView изменится.

На Фиг.11 показана методология представления начального просмотрового вида данных по результатам. На 1100 обеспечивают класс, который определяет начальный просмотровый вид данных. Класс StorageViewDefinition определяет начальный просмотровый вид данных по результатам, определенным посредством StorageSearcher.

}

На 1102 может быть обеспечено свойство Sort для получения или установки критериев сортировки для StorageView. На 1104 обеспечивают свойства для изменения и растяжения разделов. Свойство Sections может быть обеспечено для изменения списка Sections, определенных в StorageView. Может быть обеспечено свойство SectionExpandLevel для растяжения разделов вплоть до и включая заданный уровень. На 1106 обеспечивают свойство и метод для операций фильтрации. Свойство Filter может быть экспонировано для того, чтобы фильтровать StorageView для экспонирования только StorageViewRecords, соответствующих заданному условию фильтрации. Метод SetFilter может быть экспонирован для того, чтобы фильтровать StorageView для экспонирования только тех StorageViewRecords, которые соответствуют заданному условию фильтрации, использующему заданные параметры. На 1108 обеспечивают свойство и метод, которые ограничивают экспонируемые поля. Свойство Field может быть экспонировано для того, чтобы ограничить поля, экспонируемые посредством StorageView, заданными полями (Fields). Метод Field может быть экспонирован для того, чтобы ограничить поля, экспонируемые StorageView, теми полями (Fields), которые заданы с использованием заданных параметров.

На 1110 обеспечивают совокупность (коллекцию), которая перечисляет параметры, использованные фильтром, сортировкой и разделами. Совокупность Parameters (Параметры) может быть экспонирована, перечисляя параметры, используемые фильтрами, сортировкой и описаниями разделов. На 1112 булево свойство AutoRefresh (Автообновление) может быть экспонировано для того, чтобы задать то, поддерживается или нет StorageView автоматически в синхронизме с изменениями в хранилище. На 1114 свойство PageSize (Размер Страницы) может быть экспонировано для того, чтобы задать количество StorageViewRecord (ЗаписейВидаХранилища), подлежащих извлечению из хранилища единовременно.

На Фиг.12 представлена методология расширения класса записи хранилища. На 1200 обеспечивают класс, который добавляет свойства просмотрового вида. StorageViewRecord расширяет StorageRecord, добавляя StorageView конкретные свойства, такие как информацию секционирования, закладки и установки полей. StorageViewRecord поддерживает IPropertyChange для уведомления средств прослушивания, когда значения в StorageViewRecord изменятся.

На 1202 может быть экспонировано свойство IsSectionRecord для выдачи того, представляет или нет StorageViewRecord запись заголовка раздела в StorageView. На 1204 обеспечивают свойства для информации раздела. Свойство SectionLevel может быть экспонировано для выдачи уровня StorageViewRecord в StorageView. Свойство SectionName может быть экспонировано для выдачи имени раздела в StorageView. Свойство IsSectionExpanded может быть экспонировано для выдачи того, растянут или нет раздел. На 1206 свойство Bookmark может быть экспонировано для выдачи закладки для текущего StorageViewRecord. На 1208 может быть экспонирован метод SetValueinRecord для того, чтобы установить значение заданного поля в пределах StorageViewRecord. Поле может быть задано по имени или по порядку.

StorageViwSection используют для определения раздела (группы) в StorageView.

StorageViewSection может быть сконструирован посредством задания поля в StorageView, по которому определяют раздел. Свойство Field может быть экспонировано для выдачи поля в StorageView, по которому определен раздел. Свойство AggregateFields может быть экспонировано для того, чтобы получить или установить множества для выполнения вычислений для раздела. Свойство Sort может быть экспонировано для того, чтобы определять упорядочение для StorageViewRecords в пределах раздела. Свойство Having (Наличие) может быть экспонировано для того, чтобы ограничить StorageViewRecords в соответствии с заданными полями Aggregate. Метод SetHaving может быть экспонирован для того, чтобы ограничить StorageViewRecords в соответствии с полями Aggregate, заданными наряду с набором параметров.

Класс StorageCollection<T> используют для представления совокупности объектов со строгим контролем типов, заполнение которой может быть отложено. Например, StorageCollection может быть использован в свойстве совокупности родительского объекта. StorageCollection может быть заполнен явно или неявно при доступе к его содержимому.

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

Свойство ContextProperty может быть обеспечено для того, чтобы выдать StorageContext, ассоциированный с StorageCollection. Свойство Domain может быть обеспечено для того, чтобы выдать StorageDomain, ассоциированный с StorageCollection. Метод Fill (Заполнить) может быть обеспечен для того, чтобы добавить объекты в совокупность. Метод заполнения Fill может принять IEnumerable<T> или StorageSearcher, либо может использовать родительские и ролевые свойства, наряду с StorageDomain или StorageContext, для выработки запроса заполнения StorageCollection. Свойство IsFilled может быть экспонировано для того, чтобы выдать то, заполнен или нет StorageCollection. Метод Reset (Сброс) может быть экспонирован для того, чтобы сбросить StorageCollection.

Свойство Searcher (Искатель) может быть экспонировано для того, чтобы выдать StorageSearcher по хранилищу, в соответствии с определением совокупности. Метод GetEnumerator (ПолучитьПеречислитель) может быть экспонирован для того, чтобы выдать перечислитель по содержимому StorageCollection. Метод Add (Добавить) может быть экспонирован для того, чтобы добавить объект к StorageCollection. Метод Remove (Удалить) может быть экспонирован для того, чтобы удалить объект из StorageCollection. Метод Clear (Очистить) может быть экспонирован для того, чтобы очистить StorageCollection. Метод Contains (Содержит?) может быть экспонирован для того, чтобы выдать то, содержит или нет StorageCollection определенный экземпляр объекта. Метод Count (Считать) может быть экспонирован для того, чтобы определить общее количество объектов в StorageCollection. Метод СоруТо (КопироватьВ) может быть экспонирован для того, чтобы копировать определенные объекты в StorageCollection. Свойство IsReadOnly (ТолькоДляЧтения?) может быть экспонировано для того, чтобы выдать то, можно или нет добавить в или удалить из StorageCollection.

На Фиг.13 представлена система 1300, которая использует ИПП 100 хранилища 100 для ОПД 1302. ОПД 1302 используют для обеспечения управления данными между приложениями данных и инфраструктурами 1304 приложений данных и данными в хранилище 1306 данных. ОВД 1302 обеспечивает услуги по обработке данных, которые являются общими по инфраструктурам приложений и приложениям конечного пользователя, ассоциированным с ними. ОПД 1302 дополнительно включает в себя ИПП 100, который обеспечивает интерфейс с приложениями и инфраструктурами 1304 приложений, компонент 1308 времени исполнения и компонент 1310 механизма ограничения/защиты. ИПП 100 обеспечивает интерфейс программирования для приложений с использованием ОПД 1302 в форме общедоступных классов, интерфейсов и статических вспомогательных функций. Примеры включают в себя StorageContextr StorageSearcher, Entity, Entity, TableSet, Таблицу, EntityReference и TableReference.

Компонент 1308 времени исполнения ОПД представляет собой уровень, который реализует различные функциональные аспекты, экспонируемые в общедоступном уровне ИПП 100. Он реализует общую модель данных, обеспечивая объектно-реляционное сопоставление и сопоставление запроса, вводит в действие ограничения модели данных и т.д. Более конкретно, компонент 1308 времени исполнения ОПД включает в себя: реализацию компонента общей модели данных; компонент обработчика запроса; компонент сеансов и транзакций; кэш объекта, который может включать в себя кэш сеанса и явный кэш; компонент обслуживания, который включает в себя отслеживание изменений, обнаружение конфликтов и обработку событий; компонент курсоров и правил; компонент размещения бизнес-логики; средство сохранения и запроса, которое обеспечивает сохранение ядра и услуги запроса. Внутренним по отношению к сохранению и услугам запроса являются объектно-реляционные сопоставления, включающие в себя сопоставления запроса/обновления. ОПД 1302 также включает в себя средство 1310 ограничения/защиты, которое обеспечивает применение ограничений к хранилищу 1306 данных и политики безопасности, например, ролевую безопасность.

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

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

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

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

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

Обратимся еще раз к Фиг.14, на которой представлен пример окружения 1400 для осуществления различных аспектов изобретения, содержащей компьютер 1402, причем компьютер 1402 включает в себя процессор 1404, системную память 1406 и системную шину 1408. Системная шина 1408 связывает компоненты системы, включающие в себя, но без ограничения только ими, системную память 1406 и процессор 1404. Процессор 1404 может быть любым из различных коммерчески доступных процессоров. В качестве процессора 1404 могут быть также использованы двойные микропроцессоры и другие многопроцессорные архитектуры.

Системная шина 1408 может относиться к любому из нескольких типов шинных структур, которые могут быть далее связаны с шиной памяти (с или без контроллера памяти), периферийной шиной и локальной шиной, с использованием любой из разнообразных коммерчески доступных шинных архитектур. Системная память 1406 включает в себя постоянное запоминающее устройство (ПЗУ, ROM) 1410 и оперативное запоминающее устройство (ОЗУ, RAM) 1412. Базовая система ввода-вывода (БСВВ, BIOS) сохранена в энергонезависимой памяти 1410, такой как ПЗУ, СППЗУ, ЭСППЗУ, причем БСВВ содержит основные подпрограммы, которые помогают передавать информацию между элементами в компьютере 1402, например, при запуске. ОЗУ 1412 может также включать в себя высокоскоростное ОЗУ, такое как статическое ОЗУ для кэширования данных.

Компьютер 1402 дополнительно включает в себя внутренний накопитель 1414 на жестком диске (НЖД) 1414 (например, УЭСУВД (с Усовершенствованной Электронной Схемой Управления Встроенным Дисководом (EDDE), ПППТ (Последовательного Подсоединения по Передовой Технологии, SATA), причем внутренний накопитель 1414 на жестком диске может также быть конфигурирован для внешнего использования в подходящем аппаратном блоке (не показан), накопитель 1416 на гибких магнитных дисках (НГМД) (например, для чтения с или записи на сменную дискету 1418) и накопитель 1420 на оптических дисках (например, считывающий диск 1422 CD-ROM или для чтения с и записи на другой оптический носитель большой емкости, такой, как DVD). Накопитель 1414 на жестком диске, накопитель 1416 на магнитном диске и накопитель 1420 на оптическом диске может быть связан с системной шиной 1408 посредством интерфейса 1424 накопителя на жестком диске, интерфейса 1426 накопителя на магнитном диске и интерфейса 1428 накопителя на оптическом диске, соответственно. Интерфейс 1424 для внешних вариантов выполнения накопителя включает в себя, по меньшей мере, одну или обе из технологий интерфейсов Универсальной Последовательной Шины (USB) и IEEE 1394. Другие технологии подсоединения внешнего накопителя находятся в рамках сущности предмета изобретения.

Накопители и связанные с ними читаемые компьютером носители обеспечивают энергонезависимое хранение данных, структур данных, компьютерно-исполнимых команд и так далее. Для компьютера 1402 накопители и носители обеспечивают хранение любых данных в подходящем цифровом формате. Хотя приведенное выше описание читаемых компьютером носителей относится к НЖМД, сменной магнитной дискете и сменным оптическим носителям, таким как CD или DVD, для специалистов в данной области техники очевидным является, что другие типы носителей, которые являются читаемыми компьютером, такие как zip-дисководы, магнитные кассеты, карты флэш-памяти, картриджи и подобные устройства, также могут быть использованы в приводимом в качестве примера рабочем окружении, и кроме того, любые такие носители могут содержать компьютерно-исполнимые команды для выполнения способов по изобретению.

Некоторое количество программных модулей может быть сохранено на дисках и в ОЗУ 1412, в том числе операционная система 1430, одна или несколько прикладных программ 1432, другие программные модули 1434 и программные данные 1436. Вся операционная система или ее части, приложения, модули и/или данные могут также быть кэшированы в ОЗУ 1412. Очевидным является, что изобретение может быть осуществлено с различными коммерчески доступными операционными системами или комбинациями операционных систем.

Пользователь может вводить команды и информацию в компьютер 1402 посредством одного или нескольких проводных/беспроводных устройств ввода данных, например клавиатуры 1438 и координатно-указательного устройства, такого как мышь 1440. Другие устройства ввода данных (не показаны) могут включать в себя микрофон, ИК-устройство дистанционного управления, джойстик, игровую клавиатуру, перо, сенсорный экран или подобное устройство. Эти и другие устройства ввода данных часто подсоединяют к процессору 1404 посредством интерфейса 1442 устройства, который связан с системной шиной 1408, но они могут быть подсоединены другими интерфейсами, такими как параллельный порт, последовательный порт IEEE 1394, игровой порт, USB порт, ИК-интерфейс и т.д.

Монитор 1444 или дисплейное устройство другого типа также связан с системной шиной 1408 посредством интерфейса, такого как видеоадаптер 1446. В дополнение к монитору 1444 компьютер обычно включает в себя другие периферийные устройства вывода (не показаны), такие как громкоговорители, принтеры и т.д.

Компьютер 1402 может работать в сетевом окружении с использованием логических соединений по проводным и/или беспроводным линиям связи к одним или несколькими удаленными компьютерами, такими как удаленный(удаленные) компьютер(ы) 1448. Удаленный(удаленные) компьютер(ы) 1448 могут быть рабочей станцией, серверным компьютером, маршрутизатором, персональным компьютером, переносным компьютерным, развлекательным устройством на основе микропроцессора, равноправным устройством или другим общесетевым узлом и типично включают в себя многие или все элементы, описанные в отношении компьютера 1402, хотя, в целях краткости показано только память/запоминающее устройство 1450. Показанные логические соединения включают в себя проводное/беспроводное обеспечение связи с локальной сетью (ЛС, LAN) 1452 и/или более большими сетям, например глобальной сетью (ГС, WAN) 1454. Такие рабочие среды ЛС и ГС являются обыкновенными в офисах и компаниях, и обеспечивают компьютерные сети масштаба предприятия, такие как сети Intranet, все из которых могут быть соединены с глобальной сетью связи, например Интернет.

При использовании в рабочем окружении среде ЛС компьютер 1402 связан с локальной сетью 1452 посредством сетевого интерфейса проводной и/или беспроводной связи или адаптера 1456. Адаптер 1456 позволяет обеспечить проводную или беспроводную связь с локальной сетью 1452, которая может также включать в себя точку беспроводного доступа, расположенную в ней для связи с беспроводным адаптером 1456.

При использовании в рабочем окружении ГС компьютер 1402 может включать в себя модем 1458 или связан с сервером связи в ГС 1454, или имеет другое средство для установления связи по ГС 1454, такое как обеспечиваемое посредством Интернет. Модем 1458, который может быть внутренним или внешним, а также проводным или беспроводным устройством, связан с системной шиной 1408 через интерфейс 1442 последовательного порта. В сетевом окружении программные модули, представленные в отношении компьютера 1402 или его частей, могут быть сохранены в удаленной памяти/запоминающем устройстве 1450. Очевидным является, что показанные сетевые соединения приведены в качестве примера и может быть использовано другое средство установления линии связи между компьютерами.

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

Wi-Fi или Wireless Fidelity (Беспроводная Точность) позволяет выполнить беспроводное подключение к Internet с дивана дома, кровати в гостиничном номере или из зала заседаний на работе. Wi-Fi представляет собой беспроводную технологию, подобную используемой в сотовом телефоне, которая позволяет таким устройствам как, например, компьютеры, отправлять и получать данные в помещении и вне его, где-либо в пределах области обслуживания базовой станции. Сети Wi-Fi используют технологии радиосвязи, называемые IEEE 802.11 (a, b, g и т.д.) для обеспечения возможности безопасной, надежной, быстрой беспроводной связи. Сеть Wi-Fi может быть использована для подключения компьютеров друг к другу, к Internet и к проводным сетям (которые используют IEEE 802.3 или Ethernet). Сети Wi-Fi работают в нелицензируемом 2,4 и 5 ГГц диапазоне, со скоростью передачи данных в 11 Mbps (802.11а) или 54 Mbps (802.11b), например, или с составляющими, которые содержат обе полосы (двухполосными), так что сети могут обеспечить реальную работу, подобную основным 10BaseT проводным сетям Ethernet, используемым во многих офисах.

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

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

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

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

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

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

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

3. Считываемый компьютером носитель по п.1, в котором компонент классов данных включает в себя класс контекста, который обеспечивает контекст для сеанса.

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

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

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

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

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

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

10. Способ по п.7, дополнительно включающий в себя этап, на котором запрашивают домен хранилища посредством искателя хранилища.

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

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

13. Считываемый компьютером носитель, хранящий интерфейс прикладного программирования (ИПП) для экспонирования платформы данных, причем платформа данных сопряжена с хранилищем данных для обеспечения приложениям из множества различных инфраструктур приложений возможности осуществлять доступ к хранилищу данных, при этом ИПП включает в себя:
компонент обобщенного доступа к данным, который экспонирует каждое из хранилищ, сеансов, транзакций и услуг запроса платформы данных;
компонент классов данных, образованный каноническими независимыми от приложений классами, которые экспонируют типы и отношения модели данных платформы данных; и
компонент классов доменных данных, образованный специфическими для конкретного приложения и специфическими для конкретной инфраструктуры классами, которые экспонируют специфические для конкретного домена свойства и поведения платформы данных, при этом домен отличается от приложения,
при этом компонент обобщенного доступа к данным содержит класс TableSet, сгенерированный из схемы модели данных и обеспечивающий доступ со строгим контролем типов к таблицам, определенным в схеме;
класс StorageDomain, определяющий хранилище, по которому работает остальная часть классов в ИПП;
класс StorageContext, обеспечивающий контекст для сеанса и определяющий область для управления идентификационными данными, отслеживания изменений и обработки конфликтов при совмещении операций, с методами для обновления или сохранения изменений в отношении объектов в текущем контексте;
класс StorageSearcher, приспособленный для построения компонуемых основанных на объектах запросов к хранилищу данных; и
класс StorageView, обеспечивающий просмотровый вид приложения по набору результатов и поддерживающий фильтрацию, сортировку, прокрутку, группирование, секционирование, растяжение и свертывание разделов.