Платформа для служб передачи данных между несопоставимыми объектными сруктурами приложений

Платформа для служб передачи данных между несопоставимыми объектными сруктурами приложений

Иллюстрации

Показать все

Реферат

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Эта заявка испрашивает приоритет по U.S. Provisional Patent Application Serial No. 60/657556, названной «PLATFORM FOR DATA SERVICES ACROSS DISPARATE APPLICATION FRAMEWORKS» и поданной 28 февраля 2005. Эта заявка также имеет отношение к следующим заявкам США: Provisional Patent Application Serial No. 60/657295, названная «DATA MODEL FOR OBJECT-RELATIONAL DATA», поданная 28 февраля 2005, Patent Application Serial No. ___________, названная «DATA MODEL FOR OBJECT-RELATIONAL DATA», поданная ________________, Provisional Patent Application Serial No. 60/657522, названная «STORAGE API FOR A COMMON DATA PLATFORM», поданная 28 февраля 2005, и Patent Application Serial No. _________, названная «STORAGE API FOR A COMMON DATA PLATFORM» поданная __________. Названия этих заявок включены сюда по ссылке.

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

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

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

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

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

ОБЪЕКТ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

Фиг. 1 иллюстрирует систему, которая использует общую платформу данных (CDP) в соответствии с архитектурой предмета.

Фиг. 2 иллюстрирует более детальную систему CDP в соответствии с раскрытой архитектурой.

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

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

Фиг. 5 иллюстрирует поток данных в пределах различных компонентов CDP.

Фиг. 6 иллюстрирует различные структуры, которые могут быть осуществлены с CDP.

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

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

Фиг. 9 иллюстрирует CDP, разделяющую данные с множественными приложениями, связанными с множеством несопоставимых структур.

Фиг. 10 иллюстрирует двухслойное развертывание CDP для облегчения управлением данными.

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

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

Фиг. 13 иллюстрирует третью конфигурацию так, что другие приложения получают доступ к хранилищу непосредственно.

Фиг. 14 иллюстрирует трехслойную конфигурацию развертывания компонентов CDP.

Фиг. 15 иллюстрирует трехслойную конфигурацию развертывания компонентов CDP.

Фиг. 16 иллюстрирует диаграмму логики приложения, запущенной и на слое клиента, и на среднем слое.

Фиг. 17 иллюстрирует диаграмму прикладной логики, запущенной и на слое клиента, и на среднем слое.

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

Фиг. 19 иллюстрирует расширяемые механизмы для осуществления различных функциональных возможностей, включая UAF на вершине CDP.

Фиг. 20 иллюстрирует пример приложения LOB, осуществляемого по CDP.

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

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

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

Фиг. 24 иллюстрирует схематическую блок-схему образцовой компьютерной среды в соответствии с объектом изобретения.

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

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

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

Платформа данных является платформой, которая обеспечивает набор служб (или механизмов) для приложений для доступа, манипулирования и управления данными, которые хорошо интегрированы с прикладной программной средой. Объектом изобретения является усовершенствование в обычной платформе данных. Архитектура является общей платформой данных (CDP), которая предоставляет службы доступа к данным, которые являются обычными для разнообразия прикладных структур (например, структура PIM (персональная информационная система) и LOB (отраслевая) структура). Диапазон приложений включает приложения для конечного пользователя, типа Обозревателя, Почты и медиа-приложений; приложения для специалиста, работающего с информацией, типа приложений управления и координации документооборота; приложения LOB, типа ERP (планирование ресурсов предприятия) и CRM (управление отношениями с клиентами); веб-приложений и приложений управления системой.

CDP обеспечивает, по меньшей мере, следующие выгоды для приложений:

1. Мощное хранилище - способное моделировать и хранить все типы данных (структурированные, частично структурированные и неструктурированные).

a. Реляционное моделирование и доступ к данным.

b. Широкую объектную абстракцию и программную среду.

c. Частично структурированные данные, моделируемые через хранилище XML и запросы.

d. Неструктурированные данные в виде файлов.

2. Гибкая организация - способность организовывать произвольные наборы объектов и не статически, как таблица.

a. Поддержка пространства имен и организации файловой системы.

3. Широкие возможности запроса/поиска - способность запрашивать все данные.

a. Поддержка широких возможностей запросов (например, SQL, OSQL (объектно-ориентированный SQL), XML запрос, последовательности C#). OSQL является функциональным языком, который является расширенным набором SQL.

4. Широкие возможности поведения - поддерживаются для широкого поведения данных. Это не является заменой для логики приложения/бизнес-процесса.

5. Гибкое администрирование - администрирование при различных степенях детализации (например, элементы уровня операции, типа копии, движения и преобразования в последовательную форму).

6. Синхронизация данных - синхронизация одноранговых узлов и синхронизация главный-подчиненный для произвольных наборов данных.

7. Разделение - способность разделять данные для множества приложений и множества прикладных структур. Например, разделяя контакты между Outlook и приложениями CRM.

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

9. Гибкое развертывание - развертывание в двух- и трехслойных средах.

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

Обратимся вначале к чертежам, фиг.1 иллюстрирует систему 100, которая использует CDP 102. CDP 102 используется для обеспечения управления данных между приложениями для обмена данными и прикладными структурами 104 и данными на хранилище 106 данных. Хранилище 106 данных может хранить, например, структурированные, частично структурированные и неструктурированные типы данных. Как обозначено выше, CDP 102 предоставляет службы доступа к данным, которые являются обычными для прикладных структур и приложений для конечного пользователя, связанных с ними. CDP 102 дополнительно включает API 108, который облегчает взаимодействие с приложениями и прикладными структурами 104, компонентами 110 времени выполнения и компонентом 112 механизма ограничения/безопасности. API 108 обеспечивает программный интерфейс для приложений, используя CDP в форме открытых классов, интерфейсов и статических вспомогательных функций. Примеры включают StorageContext, StorageSearcher, Entity, TableSet, Table, EntityReference и TableReference. Необходимо оценить, что интеграция языка программирования базы данных (например, операторы последовательности C#) может быть частью API 108.

Компонент 110 времени выполнения CDP является слоем, который осуществляет различные особенности, видимые в слое открытого API 108. Он осуществляет общую модель данных, обеспечивая объектно-реляционное отображение и отображение запроса, накладывает ограничения модели данных и т.д. Более определенно, компонент 110 времени выполнения CDP включает: реализацию компонентов общей модели данных; компонент процессора запроса; компонент сессии и транзакции; кэш-объект, который может включать кэш сессии и явный кэш; компонент служб, который включает отслеживание изменений, обнаружение конфликтов и события; компонент курсоров и правил; компонент, несущий бизнес логику; и механизм поддержки существования и запроса, который обеспечивает основную поддержку существования и службы запросов. Внутренней к службам поддержки существования и запроса является объектно-реляционное отображение, включая отображение запроса/обновления. CDP 102 также включает механизм 112 ограничения/безопасности, который предназначен для применения ограничений к хранилищу 106 данных и политики безопасности, например безопасности на основе ролей.

Фиг. 2 иллюстрирует более детальную систему 200 CDP, которая может включать CDP 102, которая соединяется с компонентом управления хранилища 202 из отдельного хранилища данных (не показанного здесь). Альтернативно, компонент 202 управления хранилища может включать хранилище данных, типа того, что может быть связан с реализацией сервера SQL. Необходимо оценить, что хранилище данных может хранить структурированные, частично структурированные и неструктурированные типы данных.

Цель CDP состоит в том, чтобы поддержать быструю разработку программ, позволяя поддерживать разнообразные прикладные структуры 204 (обозначенные AF1, AF2, …, AFZ). Структуры 204 могут включать прикладные структуры LOB, конечного пользователя и управления системой например. Приложения 206 (обозначенные APP₁, …, APP_s; APP₁, …, APP_T), связанные с прикладными структурами 204 (AF₁, AF₂, и … AF_Z соответственно) может усилить соответствующие прикладные структуры 204, CDP 102 и основные хранилища 202 для разработки мощных приложений. Выгоды многослойного подхода описаны ниже.

Слой 202 управления хранилищем обеспечивает поддержку для базовых возможностей управления данными (например, масштабируемости, вместимости, доступности и безопасности); слой 102 CDP поддерживает широкую по возможностям модель данных, отображение, запросы и механизмы доступа к данным для прикладных структур 204. Механизмы CDP расширяемы так, чтобы множественные прикладные структуры 204 могли быть основаны на платформе данных. Прикладные структуры 204 являются дополнительными моделями и механизмами, определенными для прикладных областей (например, приложения для конечного пользователя и приложения LOB). Многослойный архитектурный подход имеет несколько преимуществ. Он позволяет для каждого слоя вводить новшества и развертывать их независимо и быстро. Слой 102 CDP может быть более подвижным, иметь больше свободы для новшеств и может вводить новшества более часто, чем слой 202 хранилища. Многослойный подход подстраивает слой 102 CDP к стратегии компании. Наконец, слой 202 хранилища может сосредоточиться на основных возможностях управления данными, совместимых со стратегией.

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

В 300 предоставлен основной слой управления данными, который моделирует и хранит структурированные, частично структурированные и неструктурированные типы данных в хранилище данных. В 302 слой 110 CDP применяют поверх основного слоя управления данными для обеспечения служб доступа к данным, которые поддерживают широкую по возможностям модель данных, отображение, запросы и механизмы доступа данных для прикладных структур. В 304 одна или более прикладных структур накладывается на CDP. В 306 одно или более приложений предоставляют в пределах каждой из прикладных структур, которые могут теперь получить доступ к данным хранилища данных через службы доступа к данным, предоставленные CDP.

Фиг. 4 иллюстрирует схематическую диаграмму компонентов CDP архитектуры изобретения. Необходимо оценить, что расположение любых компонентов и/или блоков в этом схемном решении не подразумевает (или обязательно предотвращает) любое специфическое развертывание в границах процесса/машины. CDP использует оптимистическую модель параллелизма так, чтобы, если изменения должны быть сохранены и другие изменения в основных данных уже были сделаны, обнаружение конфликтов разрешает эту проблему в определенной для приложения манере. Чтобы быть эффективной платформой данных, CDP включает возможности, типа интеграции языка программирования, богатого по возможностям моделирования данных, постоянные структуры, службы и так далее. API 108 облегчает языковую интеграцию и доступ к данным приложением 400 через выполнение CDP 110 к хранилищу 202. Быть агностиком области подразумевает то, что CDP делает самый минимум предположений о природе и форме данных и семантических ограничениях, требуемых при этом. С этой стороны, CDP обеспечивает следующие возможности (описанные более подробно ниже):

Общая Модель Данных (CDM): В центре исполняемого модуля 110 CDP - CDM 402. Цель CDM 402 состоит в том, чтобы вынести концепции моделирования, общие для множественных прикладных областей, из приложений, работающих главным образом с пользовательскими данными (PIM, документы и т.д.) в данные LOB и предприятия. В дополнение к предоставлению широких объектных и взаимосвязанных абстракций, CDM 402 обеспечивает поддержку структурированным, неструктурированным и частично структурированным данным.

Данные строки/объекта: CDM 402 поддерживает модель широких взаимосвязей-объектов для захвата структуры и поведения структурированных данных (например, бизнес данных). CDM 402 является расширенным набором основной модели отношений, с расширениями для широкой объектной абстракции и моделирования взаимосвязей (например, отношения «Автор» между «Документами» и «Контактами»; отношения «Строки» между «Заказами на поставку» и «Строками Заказа»).

Файловые данные: CDM 402 поддерживает тип данных «файловый поток» для хранения и управления неструктурированными (файловыми) данными. Тип данных «файловый поток» может хранить данные как файл и поддерживать API доступа к файлам. Тип данных файлового потока имеет родную поддержку в SQL сервере, отражается на файловый поток NTFS и поддерживает все операции, основанные на дескрипторе файла/потока. В дополнение к моделированию неструктурированного содержания в виде файлового потока в CDM 402, используя типы объекта, полезное содержание может быть выдано как структурированные свойства. Системы файлового хранилища на основе базы данных определяют представление элемента поддержанного файлового элемента, который является объектом, который моделирует структурированные свойства наряду с файловым потоком неструктурированного содержания. Поддерживаемые файловые элементы предусматривают широкие возможности запросов наряду с основанными на потоке операциями на ассоциированном файловом потоке.

Данные XML: Документы XML могут быть смоделированы двумя первичными путями в CDM 402: (1) сохранять его как тип данных XML; (2) отобразить документ XML на один или более объектов (например, подобно данным о контрактах). CDM 402 поддерживает тип данных XML, как это поддерживается в SQL сервере. Тип данных XML может быть типом любого свойства объекта; тип данных XML разрешен для нетипизованных или типизованных документов XML, которые будут сохранены. Строгая типизация обеспечивается с помощью связывания одной или более схем XML со свойствами документа XML.

Интеграция языка программирования, включающая Запросы, в API 108: Основные особенности CDP сессий-компонентов и транзакции 404, запрос 406, поддержка 408 живучести, курсоры 410, службы 412, кэш 414 объекта и поддержка 416 бизнес логики инкапсулированы в нескольких классах «времени выполнения», доступных в API CDP 108 (например, StorageContext). Основанные на типах авторизации в CDM 402, инструменты для разработки CDP генерируют строго типизованные классы CLR (общеязыковая среда времени выполнения). CDP требует языка запроса поверх типа системы, определенной CDM 402. CDP может поддерживать последовательность операторов C# и OPATH, как свой язык запросов. Ради целей данного изобретения, языки запроса, поддерживаемые CDP, упоминаются, в общем случае, как общий язык запросов (CQL). В CQL предполагается включить основную относительную алгебру (например, операторы выбора, объединения и проекта). Хотя синтаксис, возможно, не идентичен SQL, CQL может быть отображен на SQL прямым способом. CQL позволяет создавать широкие по возможностям запросы, в отличие от объектных структур, с которыми работает программист. Цель состоит в том, чтобы настроить CQL к работе с последовательностью операторов, сделанной группой C#. Эти возможности эффективно обеспечивают строго типизованную, основанную на объекте абстракцию в отличие от данных, сохраненных в системе управления реляционной базой данных (RDBMS) (или любому другому, разрешенному для CDP хранилищу). Кроме того, может использоваться структура сохранения живучести CDP для длительного сохранения и запросов для простых старых объектов CLR (POCO).

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

Файл запроса/поиска и данные XML: Как объяснено выше, CDM 402 хранят неструктурированные и частично структурированные данные, используя соответственно файловый поток и типы данных XML. CQL способен к запросу этих типов данных. Для содержания файла, положенного на структурированные объекты (например, элементы поддержки файлов WinFS), операторы отношений CQL могут запросить эти объекты. Неструктурированные данные, сохраненные как файловый поток, могут быть запрошены, используя полнотекстовый поиск. Содержание XML может быть запрошено, используя XPath или XQuery.

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

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

Процессор запроса: Когда запрашивается хранилище, запросы CQL отображаются к SQL; однако, идя к явному кэшу, запросы CQL обрабатываются компонентом QP. Доступ к базе данных идет через процессор запроса. Процессор запроса позволяет множеству клиентских программ обращаться с множеством языков запросов, которые будут выражены, а затем отображены на внутренний канонический формат. Это делается в терминах модели области и объектов приложения, на которое это воздействует. Запросы тогда передают на процессор, который является каналом передачи, а затем преобразовываются в определенные для данной серверной части запросы.

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

Хост бизнес логики: CDP обеспечивает среду времени выполнения для расположения ориентированной на данных логикой на типах/экземплярах и на операциях. Такая ориентированная на данных бизнес логика отлична от логики приложения/бизнес-процесса, которая может находиться на сервере приложений. Объекты являются не только строками в базе данных. Когда объекты осуществлены в памяти, они фактически являются объектами, которые ведут себя так, как требует приложение. В системе есть пункты расширения, которые являются, главным образом, событиями и обратными вызовами, которыми управляют для расширения CDP во время выполнения. Эти объекты являются не только объектами, но и CLR объектами, .NET объектами, и т.д. CDP дает возможность перехватывать вызовы метода свойства орта в этих объектах. Приложения могут настроить поведение этих объектов.

Службы: CDP предоставляет основной набор служб, которые являются доступными для всех клиентов CDP. Эти службы включают правила, отслеживание изменений, обнаружение конфликтов, события и уведомления. События расширяют исполняемый объект CDP 110 от служб уровня объектной структуры или для приложений, чтобы добавить дополнительные поведения, и также используется для закрепления данных в пользовательском интерфейсе.

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

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

Отметим, что компонент 112 ограничений/безопасности проиллюстрирован как отдельная форма компонента 110 времени выполнения CDP, так как он может работать как отдельный объект. Альтернативно, и возможно более эффективно, компонент 112 ограничений/безопасности объединен с компонентом 202 хранилища, который может быть системой базы данных.

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

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

1) Некоторые из компонентов, показанных на Фиг.4, «мобильны» в том смысле, что они могут находиться в различных процессах/слоях. Определенно, механизм 112 ограничения/безопасности обычно находится в процессе хранилища 202 из Фиг.2.

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

Несколько возможностей и/или компонентов CDP описаны более подробно ниже. Как заявлено выше, в центре CDP лежит общая модель 402 данных (CDM), где цель CDM 402 состоит в том, чтобы вынести концепции моделирования, общие для множества прикладных областей, от приложений, работающих главным образом с пользовательскими данными (например, PIM, документами и т.д.), к данным LOB и предприятия. Вообще, есть два возможных способа, которые могут использоваться для осуществления таких функциональных возможностей: 1) концепции модели, определенные для каждой мыслимой (или предположительно важной) области. Например, определите точно, что значит «Клиент» (из области LOB) и что значит «Персона» (из пользовательской области) и так далее; и 2) обеспечьте гибкую основу, в которой проектировщики приложений смогут создавать свои собственные, определенные для области, типы, ограничения, отношения. CDM 402 использует второй подход так, что это обеспечивает основной набор типов и определяет гибкую структуру для разработки новых типов. В этом смысле, CDM 402 может быть и моделью данных (например, фактически это определяет определенные типы и их семантику) и также модель метаданных (например, это позволяет спецификацию других моделей).

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

CDM 402 может вызвать множество понятий. Следующие понятия могут использоваться метамоделью, которая будет реализована для проектирования модели данных, определенных для области. В особенности следующие понятия можно счесть ядром CDM 402: 1) тип объекта может быть спецификацией проектировщика приложения для группировки свойств и методов, где объект является экземпляром типа объекта. Необходимо оценить, что тип объекта может быть организован через иерархию наследования; 2) таблица - собрание объектов, которые могут быть свойствами других объектов. Используя объекты, наследование и таблицы приложения, могут рекурсивно определять иерархию данных. Таблица может быть строгим типом в том смысле, что данная таблица может содержать только объекты данного типа или его подтипов; 3) набор таблиц может быть объектом, свойства которого являются таблицами. Это является основным случаем для рекурсивной иерархии данных, определяющей использование таблиц и объектов. Оно может быть существенно подобным понятию базы данных; и 4) отношения могут вырази