ПЛАТФОРМА ДЛЯ СЛУЖБ ПЕРЕДАЧИ ДАННЫХ МЕЖДУ НЕСОПОСТАВИМЫМИ ОБЪЕКТНЫМИ СРУКТУРАМИ ПРИЛОЖЕНИЙ Российский патент 2011 года по МПК G06F17/30 

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

Эта заявка испрашивает приоритет по 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) отношения могут выразить семантические связи между объектами. Необходимо оценить, что отношения могут быть расширены, чтобы определить партнеров, ограничения и т.д.

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

<Schema Пространство имен="MySchemas.MyLOB">

<TableSetType Name="LOBData">

<Property Name="Orders" Type="Table(Order)"/>

<Property Name="Customers" Type="Table(Customer)"/>

<Property Name="Products" Type="Table(Product)"/>

<Property Name="Suppliers" Type="Table(Supplier)"/>

<Property Name="PSLinks" Type="Table(ProductSupplierLink)"/>

</TableSetType>

<TableSet Name="LOB" Type="TableSetType"/>

</Schema>

Тип Entity может иметь свойства и методы, связанные с ним. Для того чтобы определять типы для свойств, параметров метода и значения, возвращаемые методом, CDM 402 предоставляет несколько встроенных типов: 1) простые типы: Int32, string, другие типы значений CLR; 2) типы перечислений: эквивалентные CLR enums; 3) ссылочные типы (обсуждаются ниже); и 4) типы массивов: упорядоченные наборы подставляемых типов (обсуждаются ниже). Свойства этих встроенных типов могут группироваться так, чтобы сформировать тип Inline, где подставляемый тип может иметь членов других подставляемых типов. Ниже приводится пример упомянутого выше:

<InlineType Name="Address">

<Property Name="Line1" Type="String" Nullable="false">

<Length Maxiumum="100"/>

</Property>

<Property Name="Line2" Type="String" Nullable="true">

<Length Maxiumum="100"/>

</Property>

<Property Name="City" Type="String" Nullable="false">

<Length Maxiumum="50"/>

</Property>

<Property Name="State" Type="String" Nullable="false">

<Length Minimum="2" Maximum="2"/>

</Property>

<Property Name="ZipCode" Type="String" Nullable="false">

<Length Minimum="5" Maximum="5"/>

</Property>

</InlineType>

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

<EntityType Name="Customer" Key="CustomerId">

<Property Name="CustomerId" Type="String" Nullable="false">

<Length Minimum="10" Maximum="10"/>

</Property>

<Property Name="Name" Type="String" Nullable="false">

<Length Maximum="200"/>

</Property>

<Property Name="Addresses" Type="Array(Address)">

<Occurs Minumum="1" Maximum="3"/>

</Property>

<NavigationProperty Name="Orders" Association="OrderCustomer" FromRole="Customer" ToRole="Orders"/>

</EntityType>

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

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

Данные, связанные с CDM 402, имеют отношения среди его составных частей. Реляционная модель явно не поддерживает отношения; Целостность PK/FK/Ссылок предоставляет инструменты для осуществления отношения ограниченным способом. Все же, CDM 402 поддержки - явное концептуальное моделирование ассоциаций, при использовании отношений и составных частей. Следующий пример может быть проиллюстрирован для понимания возможностей ассоциаций и составных частей:

1. <EntityType Name="Order" Key="OrderId">

2. <Property Name="OrderId" Type="String" Nullable="false">

3. <Length Minimum="10" Maximum="10"/>

4. </Property>

5. <Property Name="Date" Type="DateTime" Nullable="false"/>

6. <Property Name="Customer" Type="Ref(Customer)"

7. Association="OrderCustomer"/>

8. <Property Name="Lines" Type="Table(OrderLine)"

9. Composition="OrderOrderLine"/>

10. <Property Name="ShippingAddress" Type="Address"

Nullable="false"/>

11. </EntityType>

12. <Association Name=”OrderCustomer”>

13. <End Role=”OrderRole” Type=”Order” Multiplicity=”*”

14. Table=”SalesData.Customers”/>

15. <End Role=”CustomerRole” Type=”Customer” Multiplicity=”1” />

16. <Reference FromRole=”OrderRole” ToRole=”CustomerRole”

Property=”Customer” />

17. </Association>

18. <Composition Name="OrderOrderLine">

19. <ParentEnd Role="Order" Type="Order" Property="Lines"/>

20. <ChildEnd Role="OrderLine" Type="OrderLine" Multiplicity="100"/>

21. </Composition>

Ассоциации могут представить одноранговые отношения между объектами. В вышеупомянутом примере, заказ связан с клиентом через ассоциацию. В примере кода выше, строка 6 показывает, что заказ имеет ассоциированного клиента (который определен собственной ссылкой Customer). Природа ассоциации определена в строках 12-15: это значит, что ассоциация OrderCustomer - от Order до Customer (строка 15); это также значит, что для каждого Customer (Multiplicity= «1» на строке 14) могут быть множественные Orders (Multiplicity = ”*” на строке 13). Тип ассоциации, изображенной выше, можно назвать ассоциативной ссылкой.

CDM 402 определяет два других типа ассоциаций: Ассоциации по значению и Ассоциации по объектам ассоциации. Ассоциации по значению позволяют выражать отношения через любые свойства, не только через ссылку идентичности (например, свойство Document.Author имеет отношение к Contact.Name через условие равенства). Объекты ассоциации позволяют моделировать отношения, когда сами отношения несут некоторые данные (например, отношения занятости между компанией и человеком могли бы нести такие свойства, как период занятости или разряд и должность человека в компании).

Составные части могут представлять отношения родители-дети и/или отношения сдерживания. Рассмотрим Order и OrderLines (например, Order является общей суммой того, что положили в корзину покупок на вэб-сайте; OrderLine является каждым индивидуальным элементом в корзине - книга, DVD и т.д.). Каждая OrderLine имеет смысл только в пределах контекста Order. OrderLine не может независимо существовать вне содержания Order. Другими словами, OrderLine содержится в пределах Order, и вся его жизнь определена всей жизнью Order.

Вышеупомянутые изображенные отношения могут быть смоделированы, используя составные части. Строка 8 показывает пример составных частей. Свойства Lines и составные части OrderOrderLines (строки 18-22) выражают то, что заказ управляет своими строками и что строки зависят от заказа, который предоставляет им жилище. Необходимо оценить, что заказ является родителем, а строки - детьми. Главное различие между составными частями и встраиваемыми типами состоит в том, что составные части вовлекают в себя объекты. Другими словами, OrderLine может быть целью ссылки, тогда как встраиваемый тип не может быть в вышеупомянутом примере.

Одна выгода CDM 402 и его явного моделирования отношений состоит в том, что она дает поддержку метаданных для запроса. Также может использоваться предыдущий запрос. Например, учитывая клиента, нахождение всех заказов (без необходимости хранить явный обратный указатель) может быть реализовано, осуществляя NavigationProperty в CDM 402. Это показано на строке 28 из фрагмента кода, увиденного выше и воспроизведенного ниже для удобства.

28. <EntityType Name="Customer" Key="CustomerId">

29. <NavigationProperty Name="Orders" Association="OrderCustomer"

FromRole="Customer" ToRole="Orders"/>

30. </EntityType

Механизм 408 поддержки живучести может включать объектно-реляционные отображения. Другими словами, моделирование, доступ и абстракции запроса, предоставленные CDP, являются основанными на объекте. Первичная технология хранения, используемая CDP, является реляционной (например, SQL 2000). Механизм 408 поддержки живучести использует объектно-реляционные отображения (также называя «отображения O-R»), где механизм 408 поддержки живучести может отобразить классы языка на основное табличное представление.

Механизм 408 поддержки живучести может обеспечить два случая при рассмотрении отображения O-R: 1) предписывающие отображения O-R; и 2) не предписывающие отображения O-R. Предписывающие отображения O-R являются отображением между типами CDP, где их относительное представление может быть жестко закодировано в CDP. Проектировщик типа имеет мало и/или не имеет никакой гибкости в выборе расположения основных таблиц. Примером этого может быть система файлового хранилища на основе базы данных. Не предписывающие отображения O-R являются теми, где разработчик имеет различную степень гибкости для выбора, как классы CLR отображаются на основные структуры хранения. Есть два подчиненных случая, которые можно рассмотреть. 1) Выставление существующей реляционной схемы в виде объектов. Проектировщик типа использует язык спецификации высокого уровня, чтобы проектировать типы CDM, инструменты для генерации классов, основанных на них, и гибкость для определения, как типы отображаются на таблицы. Этот сценарий возникает, когда приложения CDP развернуты бок о бок (в смысле использования существенно подобных данных) с существующими реляционными приложениями. Например, IT отдел автомобильной компании может иметь LOB приложение, где требуется написать приложение CDP, которое идет по тем же самым данным (вероятно, как часть постепенной стратегии перемещения). Но требованием является то, чтобы и LOB приложение, и новое приложение CDP запускались вместе на тех же самых данных. 2) Поддержка живучести собрания классов в реляционной схеме. Разработчик не использует сгенерированные классы; скорее он используют классы собственной разработки. Разработчик хочет отобразить эти классы на реляционной схеме. Необходимо оценить, что есть много различных сценариев, которые генерируют это требование.

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

CDP предоставляет декларативный язык определения общей схемы (CSDL), аналогичный языку определения данных SQL или определению класса C# для того, чтобы определить типы объекта, таблицы объекта, отношения между типами объекта и ограничения. Там - три основных компонента времени разработки.

1. Генератор API. Проектировщик приложения проектирует типы CDM и отношения, используя CSDL и инструмент CDP разработки по имени APIG (произносится ay-pig), который генерирует частичные классы CLR, соответствующие этим типам и отношениям. Сгенерированные APIG классы доступны как собрания для программистов приложений, и на них можно ссылаться прикладными программами с использование выражения C#. Классы, сгенерированные APIG, в некотором смысле являются каноническими классами; они могут быть прямым представлением типов CDM в прикладной программе. В одном примере, прикладные классы могут быть ограничены в их определении - таким, как, например, когда приложение использует классы от предварительно написанной библиотеки класса (графический пакет, математический пакет и т.д.). Приложение может использовать структуру поддержки живучести объекта CDP, чтобы длительно сохранять и запрашивать экземпляры этих классов в хранилище. Такие объекты могут упоминаться как простые старые объекты CLR или POCO. CDP также поддерживает сценарии POCO.

2. Объектно-реляционные отображения. Этот компонент CSDL помогает проектировщикам программ объявлять конкретные, не предписывающие отображения между понятиями хранилища, типа таблиц и представлений, и CLR классов. Также можно определить, как ограничение, определенное в терминах CDM 402, может быть отображено на декларативное ограничение SQL, триггер или хранимую процедуру.

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

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

1. Основной доступ CDP к данным. Это является частью API, который делает видимым хранилище, сессии, транзакции (например, StorageContext), службы запроса (например, StorageSearcher) и службы CRUD (например, SaveChanges).

2. Классы данных CDM. Это является набором канонических, независимых от приложения классов, делающих видимым понятия CDM, типа объекта, отношений, расширения и т.д.

3. Классы области данных. Они являются классами, специфичными для приложения/структуры, типа Contact, Message, PurchaseOrderes, которые соответствуют CDM 402, но делают видимыми проблемно-ориентированные свойства и поведения.

CDM 402 может также определить язык запроса, CQL. CQL разработан для того, чтобы позволить широкие по возможностям запросы по отношению к объектным структурам, с которыми программист работает. Следующее является тремя идентифицированными способами, используемыми для основы формализма CQL:

1. OPath: Язык OPath имеет свои корни в SQL и XPath и был разработан для того, чтобы быть версией объекта CLR XPath. Проект основывается на концепции XPath выражения пути для того, чтобы сделать видимым метод разыменования свойств объектов в последовательности. Проект основан на одном простом принципе: разработчики ожидают увидеть коллекцию объектов, поскольку первичная «структурная» конструкция в объекте ориентирована на API. OPath может быть формализмом запроса POR для системы файлового хранилища на основе базы данных.

2. Объектный SQL: Этот подход расширяет язык запросов SQL для управления графами и коллекциями объектов CDM. Язык запросов Windows (WinQL), вариант SQL, разработанный для запросов и управления графами объектов CLR, является кандидатом на проект расширений, необходимых в SQL.

3. Операторы последовательности C#: Это является набором C# расширений для строго типизованного, проверяемого во время компиляции запроса и набора операций, которые могут быть применены к широкому классу переходных или постоянных коллекций объектов CLR (например, через объектно-реляционное отображение).

Стратегически, подход операторов последовательности C# максимально подходит для того, чтобы стать структурой для CQL. CQL - язык запроса. Создание, обновление, удаление выполняются как операции объекта (new, property settings и т.д.). Компонента отображения O-R в пределах механизма 408 поддержки живучести может отобразить эти операции на основные операции DML в SQL.

Отношения между типами CDM и программной поверхностью описаны ниже. Понятие «типа» в CDM 402 может рассматриваться на трех различных уровнях:

1. Место Схемы: Описание типа в схеме CDM. Они - абстрактные типы в том смысле, что они не могут явно быть осуществлены в любом компоненте стека во время выполнения (например, от приложения полностью вниз к хранилищу).

2. Пространство приложения: Представление типов в виде классов CLR в пределах API CDP. Может быть соответствием 1-1 между типами объекта/встраиваемыми типами в пространстве схемы и классах данных в пространстве приложения. Другими словами, каждый объект и встраиваемый тип в схеме CDM могут привести к классу CLR. Часто, эти классы автоматически генерируются APIG; однако, в случае POCO, разработчик может явно определить отображение между классами CLR и типами в месте схемы. Пространство приложения может также содержать классы отношений в дополнение к классам для объекта и встраиваемых типов.

3. Пространства хранилища: Формат поддержки живучести типа в основном хранилище. Если хранилище является реляционным хранилищем, то эти типы являются таблицами/UDT/основными типами SQL. Компонента отображения O-R CDP поддерживает схему отображения, которая разрешает типам в пространстве схемы быть отображенными к типам в пространстве хранилища (например, тип объекта заказа на поставку мог быть отображен к таблице PurchaseOrder в сервере SQL).

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

CDP может также включать ограничения/безопасность 112. Почти все данные, при исследовании их в пределах большого семантического контекста, будут ограничены по области своего типа в некоторой форме или другим образом. Таким образом, очень важно для CDP обеспечить путь для типа и проектировщиков приложений для выражения этих ограничений. CSDL может использоваться для создания ограничений декларативно во время разработки типа. Примеры ограничений включают, но не ограничены, следующее: 1) ограничения простого типа, такие как длина, точность, масштаб, значение по умолчанию и проверка; 2) ограничения типа множества, такие как ограничения элементов, появление, уникальность и проверка; и 3) ограничения свойств и т.д.

Эти ограничения могут быть предписаны механизмом ограничения CDP во время выполнения. Отметим, что сам акт приспособления к CDM 402 подразумевает набор ограничений, как видно из уровня основного реляционного хранилища. Например, CDM 402 требует, чтобы «каждый объект имел уникальный ключ в рамках его содержания таблицы». Это переводит к уникальному ключевому ограничению на уровне хранилища. Есть несколько других примеров таких ограничений. Точкой здесь является то, что механизм ограничения CDP предписывает два типа ограничений: те, которые подразумеваются (и требуются для приспособления) CDM 402, и те, которые являются созданными проектировщиком типа. В дополнение к декларативным ограничениям, созданным в CSDL, ограничения могут также быть написаны, используя хранимые процедуры сервера SQL. Этот способ дает выражению более сложные ограничения, чем возможный декларативный язык.

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

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

Авторизация: Модель безопасности CDP может поддержать авторизацию безопасности на, по меньшей мере, уровне объекта. Это должно также позволить управлять отдельными разрешениями для чтения и обновления объекта. По минимуму, ограничение/безопасность 112 предусматривает «свойства» и/или ряд свойств объекта, которое считается идентификатором безопасности объекта. Права доступа объекта определены функцией, связанной с таблицей, которая берет идентификатор безопасности в качестве параметра. CDP должен также позволить раздельно инициализировать пользователей, которые могут изменять идентификатор безопасности, от пользователей, которые могут изменять остальную часть объекта. Необходимо оценить, что CDP может поддерживать модель, основанную на более общей роли, которая также позволяет различные разрешения, чем чтение и запись.

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

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

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

CDP может также включать поддержку 416 бизнес логики. Когда множественные приложения управляют существенно подобными данными, требование ключа должно гарантировать, что данные остаются заслуживающими доверия - то есть, гарантировать, что данные соответствуют различным правилам проверки, бизнес правилам и любой другой системе проверки и балансировки, назначенной проектировщиком типа и/или владельцем данных. Хорошим предположением является то, что приложения вообще не являются заслуживающими доверия. Из глупости, преступного намерения и/или просто крайней необходимости непредвиденного использования образцов, приложения сохраняют и/или пытаются сохранить поврежденные данные. Например, пользователь может ввести 292 как междугородный код, и приложение сохранит такое число даже притом, что 292 является недействительным междугородным кодом, и, следовательно, значение в области номера телефона больше не представляет номер телефона. Другими словами, ему нельзя «доверять» как номеру телефона. Обычный способ предотвратить это состоит в том, чтобы создать границу доверия: некоторая часть декларативного кода/кода проверки/и т.д. (например, обычно называемой бизнес логикой), который запускается в отдельном процессе и просматривает изменения данных, сделанные приложением для «одобрения» такого изменения. После этого можно сохранять эти изменения в хранилище. Часто бизнес логика делает больше, чем просто осматривать-и-одобрять; она также предписывает бизнес правила, причины технологического процесса для случая и т.д. (например, когда вставлен новый клиент, нужно послать электронную почту отделу проверки кредита для гарантии кредитоспособности).

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

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

Вообще говоря, могут быть следующие типы событий: 1) проверка (например, эти события обеспечивают возможность заинтересованной стороны просмотреть предложенную цену и утвердить ее); 2) перед сохранением (например, это событие порождается как раз перед сохранением изменений в хранилище, и может быть существенно подобным в намерении и поведении триггеру «ПЕРЕД» в сервере SQL); и 3) после сохранения (например, это событие порождается после сохранения изменений в хранилище, и может быть существенно подобным в намерении и поведении триггеру «ПОСЛЕ» в сервере SQL). Эти типы BL запускаются в CDP и, следовательно, могут быть запущены на любом слое, на котором развернут CDP. Таким образом, когда оно запущено на слое клиента, оно может быть передано другими приложениями (например, не запущенным в границах доверия).

Кроме того, поддержка 416 бизнес логики может вызвать статические методы/методы события. Классы, автоматически сгенерированные для типов CDM, являются частичными классами. Проектировщик типа может завершить эти частичные классы, добавляя к ним дополнительные методы, обычно осуществляя логику, которая имеет смысл для специфического типа или набора типов. Рассмотрим следующие примеры: person.GetOnlineStatus(), где person - событие типа Person; emailAddr.IsValidAddress(), где emailAddr - событие типа SMTPEmailAddress; и т.д. По самой своей природе этот вид BL неосуществим; например, приложению надо вызвать IsValidAddress(), чтобы гарантировать правильность. Это запускается на любом слое, на котором развернут CDP. Таким образом, оно не запущено в пределах границы доверия, когда CDP находится на слое клиента.

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

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

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

Фиг.5 иллюстрирует поток данных в пределах различных компонентов CDP. Полезно исследовать взаимодействие различных компонентов в ответ на вызов метода приложением 500 (подобного приложениям 206 и приложению 400), используя следующий пример.

1. void AddToCart (String customerId, String productId)

2. {

3. using (OrderData od = new OrderData())

4. {

5. ShoppingCart cart = od.ShoppingCarts.Searcher.Filter(

6. "CustomerId={0}", customerId).GetFirst();

7. if(cart == null)

8. throw new Exception(“No shopping cart”);

9. Product product = od.Products.Searcher.Filter(

10. "ProductId={0}", productId).GetFirst();

11. if(product == null) throw new Exception(“Missing product);

12. cart.Products.Add(product);

13. od.SaveChanges();

14. }

15. }

Этот пример добавляет элемент к постоянному ShoppingCart. Вообразите, что этот метод вызван, например, как часть обработки веб-страницы ASP.NET.

Строка 3: Создание контекста хранения. StorageContext инкапсулирован объектом OrderData, который создан приложением 500. Класс OrderData может представить тип набора таблиц, который описан в схеме CDM. Объект OrderData создает объект StorageContext, формируемый по мере необходимости, чтобы взаимодействовать с хранилищем 202. Код инициализации StorageContext может быть частью сессии во время выполнения и компонента 404 транзакций, который открывает связь с хранилищем 202 и делает работу, необходимую для начала сессии и создания операционного контекста. Контекст безопасности установлен в компоненте 112 ограничений/безопасности. Наконец, событие StorageContext возвращается API 108 приложению 500. В случае с 2 слоями, получение StorageContext приводит к соединению с хранилищем 202. Необходимо оценить, что соединение в развертывании с 3 слоями может быть немного другим.

Строка 5: Запрос. Правая сторона выражения на строке 5 - запрос OPath. Механизм 408 поддержки живучести и запроса открывает элементарный интерфейс с методами для получения объектов, основанных на запросе CDM. CDM реализован в вызове метода 402 CDM с указанным OPath. Механизм 408 поддержки живучести и запроса отображает запрос к SQL и посылает его по проводам как полезную нагрузку TDS. Компонент 112 ограничения/безопасности гарантирует, что безопасность применена должным образом и что приложение/пользователь видит только данные, которые им позволено видеть. Хранилище выполняет запрос и возвращает результаты назад исполняемому объекту 110 CDP. CDM 402 и механизм 408 живучести/запроса работают вместе для извлечения объектов из результатов TDS, и эти объекты помещаются в кэш 414 объекта (например, кэш сессии). Результат состоит в том, что API 108 возвращает объект ShoppingCart приложению 500.

Строка 9: Запрос. Ни этот запрос, ни предыдущий, не привели ни к каким созданным курсорам (GetFirst(), метод по существу обращается к «top 1» элементу запроса). Однако если запрос требовал, чтобы курсор был создан, то компонент 410 курсоров/правил выполняет эту операцию.

Строка 12: Обновление. Объект ShoppingCart в кэше 414 объекта обновлен указанным Product.

Строка 13: Сброс изменений. Реализация SaveChanges() на объекте OrderData вызывает SaveChanges() на скрытом объекте StorageContext. StorageContext.SaveChanges () - часть поддержки 416 бизнес логики. Это вовлекает следующие шаги. Сначала запускается логика перед сохранением. Тогда запускается код проверки, следующий, за процессами после сохранения. Код проверки вызывается при событии, определенном API CDP 108. Отметим, что в другом варианте осуществления, код проверки может быть привязан к механизму включения для объекта. Затем запускается перед сохранением. Этот код вызывается при событии, определенным API CDP 108. Записываем изменения в хранилище. Сначала, компонент 416 поддержки бизнес логики работает с кэшем 414 объекта для получения вектора изменения, который содержит все изменения, сделанные в пределах этого контекста хранения. Механизм 408 поддержки живучести открывает интерфейс по имени IPersist, который является элементарным интерфейсом с методами, типа, Write(<changeVector>), и т.д. Компонент 416 поддержки получает IPersist от механизма 408 поддержки живучести и вызывает IPersist.Write() с вектором изменения. Механизм 408 поддержки живучести отображает записанный запрос в соответствующее обновление SQL (или фактическое утверждение UPDATE или вызов хранимой процедуры) и использования его для записи изменений в хранилище 202. Во время этого процесса компонент 112 ограничения/безопасности гарантирует, что сделано соответствующее осуществление безопасности. Оно также управляет любой логикой ограничения. Наконец, запускается код после сохранения. Этот код вызывается при событии, определенном API CDP 108.

Отметим, что запуск бизнес логики может привести к изменениям объектов в кэше 414. Эти изменения сохраняются в хранилище 202 вызовом myStorageContext.SaveChanges(), который гарантирует, что бизнес логика 416 не обходится. Множество ISV (независимые поставщики поддержки) могут захотеть управлять логикой изменения данных, когда они устанавливают свои обработчики на события и обработчики в FIFO (Первый вошел/первый вышел), вызванные в CLR. В этом примере, бизнес логика 416 содержит проверку ISV, логику перед сохранением и после сохранения.

Фиг.6 иллюстрирует различные структуры, которые могут быть осуществлены с CDP. CDP является платформой данных, которая разработана, чтобы быть годными к употреблению для различных специализированных вертикальных областей - таких, как пользовательские данные, LOB данные и т.д. CDM обеспечивает модель данных агностика области, которая является достаточно богатой, чтобы выразить определенную для области структуру и семантику, но в то же самое время, достаточно общую, чтобы быть годным к употреблению для различных областей. Различные возможности CDP основаны на CDM и, следовательно, являются доступными через приложения для всех областей.

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

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

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

3. «Регулярные» приложения: Только приложение CDP означает достижения определенного набора задач. Не специализируется никакой тип CDP, или открывается программная модель, или используется любая структура или вертикальная платформа.

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

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

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

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

4. Структуры обычно не открывают свою собственную программную модель; даже если они это делают, это может быть в дополнение, не вместо API CDP.

5. Структуры предоставляют дополнительные специализированные службы на вершине CDP. Эти службы могут быть осуществлены как бизнес логика CDP или как дополнительные вспомогательные классы и методы.

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

Фиг.6 иллюстрирует три (3) структуры на вершине слоя CDP 602: пользовательская прикладная структура 604 (UAF) (например, система файлового хранилища на основе базы данных, WinFS и т.д.), структура 608 совместной работы (типа WSS), и бизнес структура 610 (BF) (например, структура LOB). Данные, принадлежащие каждой структуре, показаны в том же самом образце в виде блока структуры. Например, UAF 604 имеет данные 618 контакта и элемент 620; структура 608 совместной работы имеет библиотеку данных 622 документа; и BF 610 имеет данные 624 заказа. Заметьте, что все эти типы являются предельно типизованными к объекту 626.

Фиг.6 также иллюстрирует три (3) приложения в прикладном слое: приложение 612 управления контактами, приложение 614 совместной работы (типа приложения электронной почты) и приложение 616 управления отношениями с клиентом (CRM). Приложение 612 управления контактами полностью работает с данными от UAF 604; приложение CRM 616 работ с данными и от UAF 604, и от BF 610; и приложение 614 совместной работы работает с данными от всех трех структур (например, UAF 604, структуры 608 совместной работы и BF 610).

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

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

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

Понятно, что есть данные в приложении электронной почты, которые являются концептуально подобными данным, сохраненным приложением CRM - например - информация о контактах. Насколько пользователь заинтересован, Контакт есть Контакт есть Контакт; из этой перспективы трудно понять, почему одна и та же информация о контакте сохранена дважды: один раз в CRM и один раз в почтовом ящике электронной почты. Проблемой здесь является не только избыточное хранилище, но и все аномалии, которые подразумевают это - необходимость делать обновления в обоих местах, удаление соответствия, и гарантировать вставки в обоих местах и так далее. Рассмотрим то, что случается, когда и приложение электронной почты, и приложение CRM основаны на хранилище CDP 702. Используя CDM, тип Contact может быть получен из типа Entity, и его структура становится прозрачной и для приложения электронной почты, и для приложения CRM. Таким образом, пока эти два приложения договариваются о схеме для типа, каждое из несоизмеримых приложений могут использовать данные других, не зная, в каждом случае, о существовании других. Поскольку CDP предлагает общую модель запроса, приложение CRM (например) может запросить данные контакта независимо от того, принадлежит ли специфический экземпляр Контакта ему или нет.

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

В частности Фиг.7 иллюстрирует общий сценарий UAF, где множество приложений разделяют данные, которые в этом случае являются набором типов UAF, полученных из элемента 706. CDP и хранилище 792 могут включать ряд типов UAF, связанных со структурой 704 UAF. Набор типов UAF может происходить от элемента 706, где набор может включать сообщение 708 электронной почты, документ 710 и контакт 712. Необходимо оценить, что элемент 706 может быть получен из объекта 714. Множество приложений может использоваться вместе с CDP и структурой UAF 704, такими как, но не ограничиваясь этим, приложение 716 электронной почты, широкий по возможностям клиент 718 evite и проект 720 М. Необходимо оценить и понять, что никакое ограничение не является по месту в слое, в котором приложение CDP, UAF находится. Например, одно из приложений на Фиг.7 может быть выполнено и/или запущено в среднем слое (например, приложение совместной работы).

Фиг.8 иллюстрирует единственное приложение, использующее множество структур в соответствии с CDP и связанной архитектурой. CDP и хранилище 702 могут предоставить единственную платформу данных для операционной системы, которая усилена всеми приложениями. Приложение CRM 802, который может быть прежде всего написан на LOB структуре 804, может использовать данные 806 контакта, связанные со структурой UAF 808. Необходимо оценить, что приложение CRM 802 обычно использует данные, связанные с, но не ограничиваясь этим, деталями 814 заказа и заказом 816 на поставку. Приложение CRM 802 может использовать абстракции уровня CDP при использовании данных UAF (например, данные 806 контакта, элемент 810, объект 812 и т.д.). Другими словами, приложение CRM 802 не должно использовать структуру 808 методов UAF. Кроме того, необходимо оценить и понять, что приложение CRM 802 может находиться на любом слое.

Фиг.9 иллюстрирует CDP, разделяющую данные с множеством приложений, связанных с множеством несопоставимых структур. Фиг.9 изображает три структуры - структуру 904 UAF, структуру 908 совместной работы и структуру 910 BF на вершине CDP 902. Множество приложений может использовать комбинацию уровня структуры и уровня программирования CDP. В частности, приложение 912 управления контактами, приложение 914 совместной работы и приложение 916 CRM могут использовать комбинацию уровня структуры и уровня программирования CDP. CDP 902 дает множеству приложений, связанных с множеством несопоставимых структур, возможность разделять данные в хранилище 928.

Определенно, есть различные способы, в которых множество приложений взаимодействуют с данными. Приложение 912 управления контактами может использовать CQL, чтобы запросить контакт 918; оно может использовать методы 904 UAF, типа перемещения, копирования, contact.GetBestEAddress() уровня элемента и т.д. Приложение 912 управления контактами может дополнительно использовать основные классы исполняемого объекта CDP, таких как, но не ограничиваясь этим, StorageContext, StorageSearcher и классы данных CDP (например, класс контакта и связанных получателей и установщиков).

Приложение 914 совместной работы может использовать CQL, чтобы запросить контакты 918, любые документы в библиотеке 922 документов и, возможно, даже заказ 924. Приложение 914 совместной работы не должно знать, что существование UAF 904 и/или BF 910 делает такие же запросы - это может быть сделано просто на уровне CDP, не используя никакого специального кода, написанного другими структурами. Оно использует операции, определенные для структуры 908 совместной работы, чтобы управлять библиотекой 922 документов, типа AddDocumentToDocLib (<document >, <docLib>) и т.д. Приложение 914 совместной работы может дополнительно использовать классы уровня CDP, типа StorageContext, StorageSearcher, Contact, Order, DocLibrary, и связанные установщики и получатели.

Приложение CRM 916 использует CQL, чтобы запросить все заказы для данного контакта. Необходимо отметить, что приложение CRM 916 может сделать этот запрос без знания того, что контакт был фактически создан, используя UAF 904. Оно управляет Заказами, использующими методы и службы, предоставленные BF 910 (например, FindShipStatus(<Order>)). Оно может дополнительно использовать классы уровня CDP, типа StorageContext, StorageSearcher, Contact, Order, DocLibrary, и связанные установщики и получатели.

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

Фиг.10 иллюстрирует двухъярусное развертывание CDP. Различные компоненты, которые включают CDP, являются, по существу, мобильными. С определенными ограничениями они могут быть развернуты для различных процессов и машинных границ, приводя к 2-слойной, 3-слойной, и N-слойной (где N - целое число, больше или равное 1) конфигурации. Необходимо оценить и понять, что, хотя проиллюстрировано развертывание с 2 слоями, объект изобретения не ограничен этим и что может использоваться любое число конфигураций слоев.

В частности, API CDP 1002 и исполняемый объект 1004 CDP, оба могут быть в процессе приложения, связанном с приложением 1006. Таким образом, компоненты CDP (например, исполняемый объект CDP 1004, API 1002 и компонент 1008 ограничения/безопасности) могут существовать в различных слоях. Например, API 1002, исполняемый объект 1004 CDP и приложение 1006 могут существовать в слое клиента 1010, где компоненты могут существовать в своих собственных границах процесса/машины. Дополнительно, хранилище 1012 и компонент 1008 ограничения/безопасности могут существовать в слое сервера 1014, где компоненты там могут существовать в их собственной соответствующей границе процесса/машины. Необходимо оценить, что компонент 1008 ограничения/безопасности может находиться в процессе хранилища, в то время как остальная часть компонентов CDP может находиться в процессе клиента. Это является главным примером того, как компоненты CDP можно располагать, чтобы они были мобильными.

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

Приложение может взаимодействовать с API и исполняемым объектом CDP, где различные приложения могут существовать с каждым соответствующим компонентом так, чтобы каждое приложение с API и исполняемым объектом CDP могли иметь свою собственную границу машины/процесса, проиллюстрированную как граница 1102, граница 1104 и граница 1006. Ради краткости, проиллюстрированы три приложения (например, приложение 1, приложение 2 и приложение 3), но необходимо понимать, что может использоваться любое число приложений. Приложения могут получить доступ к разделяемым данным 1108 в пределах совместно используемого ресурса 1110 в его собственной границе 1112 процесса/машины. Необходимо оценить, что ограничения/безопасность 1114 предписаны для такого разделения данных между несоизмеримыми приложениями.

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

Фиг.12 иллюстрирует вторую конфигурацию так, что приложение имеет частные данные, которые не должны быть видимыми и/или использоваться другими приложениями. Другими словами, есть двухслойное развертывание, связанное с частными данными. Есть много пользователей и сценариев ISV, которые требуют представления частных данных приложений. Например, если приложение решает сохранять свои данные конфигурации (например, эквивалентные файла ini) в системе файлового хранилища на основе базы данных, желательно, чтобы они были частным для приложения. Много раз, для частичной секретности есть требование - чтение разрешено, но запись - нет. Например, в приложении электронной почты было бы желательно показать почтовый ящик, но для себя должно быть зарезервировано право на изменение почтового ящика.

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

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

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

- С помощью документации.

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

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

Продолжим с Фиг.12, где проиллюстрирована граница машины/процесса 1202 с приложением, которое взаимодействует с API и исполняемым объектом CDP и границей 1204 машины/процесса с приложением, которое взаимодействует с API и исполняемым объектом CDP. Ради краткости, проиллюстрированы только два приложения, но необходимо оценить, что любое число приложений может получить доступ к разделяемым данным 1210 и/или доступ к соответствующим частным данным (например, приложение 1, частные данные 1210; и приложение 2, частные данные 1212) в пределах хранилища 1206 в своей собственной границе 1208 машины/процесса.

Фиг.13 иллюстрирует третью конфигурацию интереса, в которой другие приложения имеют доступ непосредственно к хранилищу. Другими словами, есть двухслойное развертывание с прямым доступом к хранилищу. Приложение 2 в пределах границы 1302 машины/процесса может получить доступ к хранилищу 1306 SQL непосредственно, возможно, например, через ADO.NET или через другой API доступа к данным. Например, большие магазины IT (информационной технологии), которые имеют существующие приложения SQL, вряд ли устранят это и перейдут в массе на приложения на основе CDP. Скорее, может быть осуществлено перемещение к CDP на постепенной основе. Так как нулевое время простоя и стабильность являются ключевыми вопросами в производственной среде, вероятно, что приложения CDP могут запускаться бок о бок с приложением SQL в течение некоторого времени. Поскольку CDP дает гибкие, не предписывающие О-R (объект к отношению) отображения, приложение CDP может быть развернуто поверх существующей схемы. Архитектура CDP позволяет, естественно, давать прямой доступ к SQL. Это происходит потому, что «Данные приложения 1» являются просто рядом таблиц, и нет ничего такого, чтобы препятствовать Приложению 2 получать доступ к ним непосредственно, пока оно имеет соответствующие разрешения.

Отметим следующие последствия для приложения 2:

1) Оно, возможно, не имеет доступа к службам CDP (или любым службам, построенным структурой на верху CDP).

2) Определенно, оно не имеет выгоды CDM - таким образом, должно быть выяснено табличное представление и проблемы запросов/обновления непосредственно на этом уровне.

Отметим следующие последствия для приложения 1:

1) Бизнес логика в BL службе(ах) эффективно обходится приложением 2.

2) Некоторые ограничения - например, те, которые не осуществлены как триггеры/DRI (декларативная справочная целостность) - также обходятся приложением 2.

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

Фиг.14 и Фиг.15 иллюстрируют конфигурацию развертывания с тремя слоями компонентов CDP. Различные компоненты CDP могут быть развернуты в конфигурации с 3 слоями. В этой конфигурации, исполняемый объект CDP 1402 присутствует и на слое клиента, и на средних слоях (показанных на Фиг.15). Приложение находится на слое клиента, и хранилище 1404 находится на слое сервера (проиллюстрированного на Фиг..15). Логика приложения может коснуться двух претендентов на фиг.14 и 15: первый является клиентом 1406. Вторые являются посредниками 1408 веб-служб, веб-службой 1410 (отмеченной на Фиг.15), и носитель 1412 бизнес логики, (отмеченный на Фиг.15) (например, проверка, логика перед сохранением и логика после сохранения). В то время как клиент 1406 является приложением, и, следовательно, логику, содержавшуюся в нем, можно законно назвать «логикой приложения», это не то, что упоминалось. Скорее, это ссылка на логику, содержащуюся в посреднике 1408 веб-службы, веб-службе 1410 и носителе 1412 бизнес логики. Это является кодом, написанным ISV, и это означает, что она должна быть развернута на среднем слое; таким образом, в очень реальном смысле, это является «приложением среднего слоя». Логика приложения может находиться и на клиенте, и на среднем слое. В зависимости от того, где запущена логика приложения, есть несколько возможных сценариев, которые рассматривают ниже.

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

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

2. Неявный удаленный запрос обслуживания CDP: Запросы API CDP, типа FindAll(), FindOne(), SaveChanges(), посылаются среднему слою неявно через удаленный агент и удаленные компоненты обслуживания. Эта архитектура описана ниже. Кроме того, последующие секции имеют примеры, которые описывают, как это работает.

3. Явное, отсоединенное удаленное взаимодействие: API CDP определяет программный образец, посредством чего приложение явно определяет, когда должны произойти межслойные операции. Если эта операция привела к поиску данных, то извлеченные данные кэшируются на слое клиента. Этот образец обычно упоминается как «отсоединенный способ» (обсуждается ниже).

В частности Фиг.14 и Фиг.15 иллюстрируют логику приложения, запущенного на среднем слое (например, веб-службы). Имеет место первичный сценарий для развертывания на среднем слое, где логика приложения запускается исключительно на среднем слое; клиент 1406 вызывает эту логику через механизм веб-службы (например, посредника 1408 веб-службы и веб-службы 1410). Необходимо отметить, что механизм безопасности на слое сервера может быть расположен на процессе CDP среднего слоя. В развертывании с 2 слоями, вызовы CDP обрабатываются исполняемым объектом 1402 CDP в процессе клиента; исполняемый объект связывается с сервером, когда это необходимо. В развертывании с 3 слоями, некоторые запросы CDP обрабатываются локально (через слой клиента), и некоторые обрабатываются удаленно (через средний слой). Кроме того, некоторые другие запросы могут быть обработаны в обоих местах. Развертывание с 3 слоями определяет методологию для удаленного взаимодействия соответствующих вызовов.

Агент 1414 удаленного взаимодействия на слое клиента, который является компонентом, который может использовать канал (например, Indigo), чтобы упаковать и послать запросы CDP на средний слой (это фактически является актом удаленного вызова процедуры). На среднем слое сидит служба 1416 удаленного взаимодействия (отмеченная на Фиг.15), которая, соответственно, обслуживает эти запросы. Этот образец является частью того, что обычно известно как ориентированная на службу архитектура (SOA). Особенностью SOA является то, что различные слои общаются друг с другом с помощью обмена сообщениями. CDP может использовать инфраструктуру Indigo с этой целью.

Поставщики удаленных услуг обеспечивают набор ориентированных на данные служб, таких как «выполнить запрос», «вставить», «удалить», «обновить», «создать», «сохранить», «получить данный объектом ключ», «получить корневой ключ». В соответствии с парадигмой SOA, эти операции могут быть командой в пределах сообщения SOAP. Любое действие, которое слой клиента хочет выполнить на среднем слое, выражается в терминах этих простых команд. Эти основные команды сообщений абстрагируются в методы на 2-х интерфейсах, используя средства обслуживания, предоставленные Indigo; фактически, это - IPersist и интерфейсы IQuery, которые были обсуждены выше. Таким образом, агент 1414 удаленного взаимодействия и удаленная служба 1416 вместе являются конечными точками канала Indigo для интерфейсов IQuery и IPersist удаленных методов. Необходимо оценить и понять, что методы в IQuery и IPersist являются «крупнозернистыми» в следующем смысле: они могут использоваться, чтобы запросить, или работать над большим набором объектов. Например, в ответ на метод SaveChanges(), агент 1414 удаленного взаимодействия выдает IPersist.Write() один раз к удаленной службе 1416 с полным набором измененных объектов. Таким образом, интерфейсы между клиентом и средним слоем ориентируются на большие объемы данных и не являются «болтливыми».

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

1. WinFSData wd = new WinFSData(@"\\CorpSvr01\SharedSchedule\AnilNori"))

2. ScheduleEntry s = wd.Items.FilterByType<ScheduleEntry>().Filter(

"StartTime > @0", new DateTime(xxxx, 10, 29, 9, 0, 0)).GetFirst();

3. s.DisplayName = s.DisplayName + "[important, please come!]";

4. ScheduleService ss = new ScheduleService(wd);

/* public bool CreateAppointment(ScheduleEntry appointment,

* string path)*/

5. if (ss.CreateAppointment(s, @"\\CorpSvr01\SharedSchedule\PCelis"))

6. {

7. Console.WriteLine("Appointment created!");

8. }

В этом примере, приложение запрашивает разделяемый календарь для Anri Nori на корпоративном интранете, чтобы получить его запись в календаре на 29-е октября, xxxx в 9:00. Это представлено объектом ScheduleEntry, который является типом, полученным из Entity (например, ScheduleEntry является частью схемы PIM и представляет элемент в расписании пользователя). Здесь изменяется ScheduleEntry - добавляется текст «[important, please come!]» к названию назначенного события. После этого вызывается метод CreateAppointment веб-службы (названной ScheduleService), чтобы поместить этот измененный ScheduleEntry в разделяемый календарь Pedro Celis. Этот фрагмент кода иллюстрирует несколько ключевых элементов в развертывании с 3 слоями:

1. Клиент использует локальный исполняемый объект CDP для запроса объектов хранилища. Запросы выполняются на среднем слое.

2. Результаты запроса находятся в кэше сессии CDP слоя клиента.

Всей «логикой приложения» - включая бизнес логику, проверку, и т.д. - управляют на среднем слое веб-службой механизмом, несущим BL CDP. Эта обработка запускается вызовом метода CreateAppointment(). Следующее является детальным описанием потока данных между/через различные модули.

Строка 1: Создание контекста хранилища. Объект StorageContext (например, API 1418 на слое клиента) инкапсулирован объектом данных, который создан приложением и/или клиентом 1406. Класс данных представляет собой тип набора таблиц, который был описан в схеме CDM. Объект данных создает объект StorageContext, формируемый по мере необходимости, чтобы взаимодействовать с хранилищем 1404. Код инициализации StorageContext является частью исполняемого объекта CDP 1402 на слое клиента.

Строка 2: Запрос. RHS выражения на строке 2 является запросом OPath. Этот запрос возвращается вместе с самым большим объектом ScheduleEntry - первым объектом (например, предположим, что там существует точное определение «первого объекта»), 10/29/04, 9AM. Исполняемый объект CDP 1402 на слое клиента получает интерфейс IQuery на агенте 1414 удаленного взаимодействия и вызывает ExecuteQuery(<Opath>) на нем. Агент 1414 удаленного взаимодействия может использовать канал Indigo и посылает этот запрос удаленной службе 1416 на среднем слое. Запрос отображается и выполняется так же, как в случае двух слоев, и результаты возвращаются слою клиента. Здесь есть две возможности:

1. Необработанные результаты TDS возвращаются из среднего слоя в слой клиента без поглощения объектов. Исполняемый объект CDP 1402 на слое клиента после этого поглощает объекты.

2. Если эти объекты уже существуют в кэше 414 объекта, поглощенные объекты возвращаются на слой клиента.

Необходимо отметить, что весь этот запрос OPath посылают через канал Indigo. Например, если запрос был «найти все объекты типа ScheduleEntry» (то есть вызов метода FindAll()), то весь этот запрос послали бы (удаленной службе 1416 на среднем слое) в одном SOAP сообщении - а не одно сообщение на объект.

Строка 3: Управление кэшом объекта слоя клиента. Как только объект ScheduleEntry возвращен на слой клиента, он доступен для дальнейшей манипуляции в пределах кэша сессии исполняемого объекта CDP 1402 на слое клиента. Когда клиент 1406 изменяет свойство DisplayName объекта ScheduleEntry, это полностью обрабатывается исполняемым объектом CDP 1402 на слое клиента.

Строка 4: Новый посредник веб-службы на слое клиента. По-видимому, клиент 1406 уже добавил ссылку на соответствующий asmx (или эквивалент в Indigo) во время проекта. Строка 4 может создать экземпляр объекта посредника веб-службы на клиенте. Этот вызов обслуживается полностью посредником 1408 Веб-службы.

Строка 5: Вызов метода веб-службы. CreateAppointment() является одним из методов удаленной веб-службы 1410 на среднем слое. Этот метод берет объект ScheduleEntry и строку соединения CDP; он использует эту информацию для создания объекта ScheduleEntry в пределах StorageContext, определенного строкой соединения. Наследованный внутри этого оператор записи является функционированием соответствующей бизнес логики и логики проверки. Этот метод упаковывается посредником 1408 веб-службы и посылается через SOAP сообщение через канал Indigo к веб-службе 1410 на среднем ряду. Веб-служба 1410 реализует этот метод через вызовы в API CDP 1420 на среднем слое так же, как если бы это было любое другое приложение. Ключевой вещью, отмеченной здесь, является то, что всей логикой для CreateAppointment() управляют на среднем слое.

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

1. void AddToCart (String customerId, String productId)

2. {

3. using (OrderData od = new OrderData())

4. {

5. ShoppingCart cart = od.ShoppingCarts.Searcher.Filter(

6. "CustomerId={0}", customerId).GetFirst();

7. if(cart == null)

8. throw new Exception(“No shopping cart”);

9. Product product = od.Products.Searcher.Filter(

10. "ProductId={0}", productId).GetFirst();

11. if(product==null) throw new Exception(“Missing product);

12. cart.Products.Add(product);

13. od.SaveChanges();

14. }

15. }

16.

Как можно было заметить в предыдущих примерах, строка 3 создает контекст хранения, строка 5 и строка 9 относятся к запросу, и строка 12 относится к обновлению.

Строка 13: Сброс изменений. Рассмотрим две следующие возможности:

1. BL запускается и на слое клиента, и на среднем слое: В этом случае, поддержка 416 бизнес логики на слое клиента, управляет проверкой логик и перед сохранением и вызывает агента 1414 удаленного взаимодействия на слое клиента с IPersist.Write(<change vector>). Агент 1414 удаленного взаимодействия посылает вызов в удаленную службу 1416 (как можно видеть на Фиг.17) на среднем слое. Удаленная служба 1416 изменяет кэш 414 объекта на среднем слое и вызывает SaveChanges(). Этим запускается BL и шаги по поддержке живучести, как описано ранее, и возвращается к удаленной службе 1416, где удаленная служба 1416 возвращается к агенту 1414 удаленного взаимодействия на слое клиента, который в свою очередь возвращается назад к поддержке 416 бизнес логики. Логика после сохранения на стороне клиента может не запускаться поддержкой 416 бизнес логики.

2. BL запускается только на среднем слое. В этом случае, поддержка 416 бизнес логики немедленно переходит к вызову агента 1414 удаленного взаимодействия, который в свою очередь посылает это удаленной службе 1416. Обработка происходит на среднем слое, как описано выше.

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

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

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

- Пересечение слоев потенциально дорого и, следовательно, может не происходить неявно: нет никакого явного признака на строке 2, что это приводит к операции пересечения слоя - другими словами, вовлекая «волшебство». «Волшебство» используется здесь в том смысле, что кое-что происходит без приложения, знающего об этом или имеющего возможность управлять возникновением этого. Во многих случаях, волшебство является хорошим вариантом; фактически, цель большого количества программного обеспечения - скрыть лежащую в основе сложность и заставить вещи происходить «как по волшебству». Однако, в этом специфическом случае, долгий опыт показывает, что авторы приложений волей-неволей посылают огромные запросы, предполагая, что код внизу так или иначе возвратит много данных, не удушая сеть или приводя к стрессу сервер. Доказанной парадигмой разработки является то, что любой слой, пересекающий волшебство, может быть сделан явным для приложения, поддерживая, таким образом, разумные методы кодирования (являющийся «select *, что необходимо из <таблицы с миллионом строк>” или возможно, где может использоваться оператор WHERE).

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

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

1. Приложение создает экземпляр «локальный кэш» следующим образом:

LocalContext lc = new LocalContext();

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

lc.QueryCollection.Add(“<query1>”);

lc.QueryCollection.Add(“<query2>”);

// etc.

3. Приложение «заполняет» локальные контекст

lc.Fill();

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

ScheduleEntry s =

lc.Entities.FilterByType<ScheduleEntry>().Filter(

"StartTime > @0", new DateTime(

2004, 10, 29, 9, 0, 0)).GetFirst();

s.DisplayName = s.DisplayName + "[important, please come!]";

5. Наконец, оно посылает изменения в массе хранилищу, определенному следующим образом:

// sc является StorageContext

lc.SaveChanges(sc);

Обратите внимание, как приложение может быть явным, когда требуется, чтобы произошла операция пересечения слоя lc.Fill() на шаге 3 так, чтобы не было никакого волшебства, запущенного невинным кодом. Заметим также, что все последующие операции могут произойти в локальном кэше и, следовательно, пересечение слоя минимизировано (наряду с сопутствующей поддержкой состояния на среднем слое). Необходимо оценить, что модель, подразумеваемая кодовыми фрагментами выше, весьма подобна модели набора данных в ADO.NET. CDP может также обеспечить отсоединенную модель.

Приложение с 2 слоями не должно быть развернуто в среде с 3 слоями, если неверно одно из следующего: (a) оно использует только отсоединенную программную модель или (b) оно переписано, чтобы использовать отсоединенную программную модель.

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

Для установления контекста для следующей секции, в которой обсуждаются хранилища CDP, отметим, что совокупность всех данных сервера SQL разделена в следующей иерархии на 4 уровня: экземпляр, база данных, схема и таблица. Присоединяемой единицей является экземпляр; база данных является контейнером, для которого определены резервное копирование, восстановление и репликация. Комбинация базы данных и схемы обеспечивает контекст для запросов. CDP использует иерархию с 3 уровнями: хранилище, схема и тип. Хранилище CDP является единицей подсоединения; схема обеспечивает контекст для запросов. Данная схема может нести множество хранилищ CDP (например, ряд типов (схема CRM) может быть развернут на двух различных экземплярах CDP). Если желательно «сходство», то должны использоваться механизмы вне CDP (репликация, поточное копирование). Данное хранилище CDP может иметь множественные схемы, развернутые на нем, - типа схемы HR, бухгалтерскую схему и т.д.

Здесь обсуждаются обозначения и раскрытие. Обратимся к строке 3 из следующего кода, обсужденного выше.

Using (StorageContext sc =

new StorageContext(@\\corp001\defaultstore))

Следующее обозначение адресов CDP хранит и раскрывает доступные хранилища. Хранилище CDP определяется более ясно. Есть две возможности:

1. Оно является актуальным, физическим хранилищем - базой данных на актуальном серверу.

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

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

Относительно формата ctor аргумента, строка подключения является унифицированным идентификатором ресурса, или URI. Индивидуальные объектные структуры могут определить альтернативный формат обозначения для использования их приложениями. Например, UAF может захотеть позволить своим приложениям устанавливать контекст хранения, определяя имя UNC (например, \\server\share). Однако всегда должна быть возможность соединиться с хранилищем CDP с помощью URI; другими словами, любые альтернативные имена, используемые структурой, должны иметь хорошо определенное отображение на соответствующие URI уровня CDP.

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

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

- Службы наблюдения/уведомления.

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

- Службы явного кэша.

- Сервисные операции.

Эту секцию нужно счесть описательной, не архитектурной.

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

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

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

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

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

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

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

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

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

- Различные типы кэшируемых данных (например, объекты, неструктурированные, и данные XML).

- Различные режимы доступа к кэшу (например, только для чтения, только для записи, разделяемый и т.д.).

- Согласованность кэша с сохраненными данными (например, для данных, сохраненных в сервере SQL).

- Кэш (определенный тип данных, например данные контекста сессии) согласуется для множества кэшей CDP для приложения с обработкой отказа.

Программная поверхность для явного кэша может открыть:

создание кэшей;

заполнение кэшей;

сохранение кэшей (части данных) в основные хранилища;

запрос и обновление по кэшированным данным.

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

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

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

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

К основной инфраструктуре CDP UAF добавляет:

- Основной тип Item (и связанные типы).

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

- Ограничения, типа пожизненного управления, сдерживания и т.д.

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

- Организационные конструкции для элементов: контейнеры, списки, автосписки, аннотации, категории.

- Конечный пользователь, программирующий абстракции по элементам (типа разработки правил).

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

Фиг.18 изображает понятие элемента в UAF и как оно фактически получено из нескольких объектов. Элемент 1802 документа может быть получен из нескольких объектов, типа, но не ограничиваясь этим, документа 1804, множества 1806 ссылок и расширения 1808 документа. Элемент 1810 автора может быть получен из нескольких объектов, типа, но не ограничиваясь этим, автора 1812 и расширения 1814 автора.

Обратимся к Фиг.19, где проиллюстрированы расширяемые механизмы для осуществления различных функциональных возможностей осуществления UAF на верху CDP. Так как UAF построен на верху CDP, он может использовать механизмы расширяемости CDP для осуществления дополнительных функциональных возможностей. Построение UAF на CDP может включать различные слои и/или компоненты. Хранилище 1902 может включить механизм 1904 ограничения CDP, где механизм 1904 ограничения CDP содержит, по меньшей мере, одно ограничение 1906 UAF. Исполняемый объект CDP 1908 может включать поддержку 1912 BL, которая может включать поведение 1910 элемента UAF. Поведение 1910 элемента UAF может дополнительно включать граничное 1914 поведение UAF. На верху исполняемого объекта 1908 CDP могут существовать любые другие службы 1916 UAF.

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

Описанное ниже применимо к разделяемой системе файлового хранилища на основе базы данных между CDP и UAF. Следующие возможности в системе файлового хранилища на основе базы данных принадлежат слою CDP:

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

2. Отображение запроса OPath.

3. Реализация объекта и другого корневого типа CDM.

4. StorageContext и StorageSearcher, наряду с сессией и управлением транзакциями.

5. Кэш сессии, логика сброса изменений кэша (SaveChanges).

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

7. Наблюдатели на типах объекта.

8. Службы курсора, включая RAV.

9. Механизмы осуществления безопасности уровня элемента (безопасность уровня строки, предикаты безопасности, включенные в представления типа).

Следующие возможности в системе файлового хранилища на основе базы данных принадлежат слою UAF:

1. Граничное, для конкретного экземпляра, поведение.

2. Метаданные API системы файлового хранилища на основе базы данных (классы клиента и поведения, выраженные как метаданные CLR).

3. Методы уровня элементом (копирование, перемещение, преобразование в последовательную форму, переименование).

4. Синхронизация, возможности синхронизации, изменение перечисления.

5. Наблюдатели на контейнерах.

6. Таблица пути для расчета имени эффективного пути и области элемента.

7. Обработчики метаданных.

8. Система файлового хранилища на основе базы данных пространства имен.

9. Код для предписывания целостности элемента (контейнер, части элемента, ссылки, файловые потоки, управление во время всей жизни и т.д.).

Фиг.20 иллюстрирует пример LOB приложения, реализуемого по CDP. Ниже описаны требования LOB структуры и как они могут быть поддержаны CDP. Приложение бизнес структуры можно счесть LOB приложением. Основным набором возможностей для бизнес приложений являются пакеты в виде разделяемых бизнес компонентов. Группы этих компонентов управляют различными бизнес функциями, типа общей бухгалтерской книги в финансовой системе для служб автоматизации продаж в CRM. Ключевой особенностью является то, что эти компоненты являются безликими, расширяемыми и могут использоваться для нужд множества рынков в зависимости от того, какой уровень функциональных возможностей и сложности используется.

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

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

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

Жизнеспособность Объекта (EP), подсистема доступа к данным в бизнес структуре, поддерживает богатую по возможностям модель данных, основанную на структуре отображения отношений прагматического объекта. Это является отношением объекта в том, что разработчик соглашается с (C#) объектами, которые отображены на реляционные строки. Основными концепциями моделирования данных являются объекты и отношения между объектами. Общая модель данных (CDM), по существу, поддерживает данные, моделируя требования BF по доступу к данным. MBF EP требует поддержки следующим действиям по доступу к данным:

- Создание, чтение, обновление и удаление объекта.

- Запросы по случаю, которые возвращают набор данных.

- Операции на основе набора, которые выполняют в базе данных.

BF предписывает структуру агента/службы для поддержки распределенных, ориентированных на службу конфигураций. Учитывая некоторую часть функциональных бизнес возможностей, агент запускается так близко к пользователю функциональных возможностей, насколько это возможно, и служба запускается так близко к данным, насколько это возможно. «Так близко, насколько возможно» отличается для каждого сценария развертывания и вида пользователя. Образец агента/службы обеспечивает гибкость развертывания от 2-х слоев (клиент - сервер) к многослойному развертыванию. В таком развертывании службы предоставляют интерфейсы, которые могут быть вызваны через границы служб; агенты обычно доставляют данные близко к клиенту (пользователю), управляя ими на нем и размножая изменения на службы.

В частности Фиг.20 иллюстрирует, как LOB структура и/или приложение могут использовать CDP. Структуру и приложение, построенные при использовании структуры, можно расположить в крайнем сервере 2002 приложений на среднем слое. Этим можно обеспечить стандарты LOB службы, такие как, но не ограничиваясь этим, технологический поток, сообщения, бизнес-процессы и т.д. в форме интерфейса веб-служб к клиентскому приложению 2004. Крайний сервер 2002 приложений может использовать CDP для созданного ограничения 2006 хранилища (через механизм ограничения CDP 2014) и данные 2008, направленные на бизнес логику. Клиентское приложение 2004 может вызвать метод веб-служб (например, используя посредника 2010 веб-служб и интерфейс 2012 веб-службы) по каналу Indigo. Дополнительно может использоваться CDP на слое клиента для нужд доступа поддержки объекта жизнеспособности/данных.

Следующее может быть удовлетворено CDP: 1) Управление сессией; 2) CRUD; 3) Поддержка общей модели данных (CDM) (например, абстракция объекта, расширение объекта); 4) Запрос (например, моментальный, объект); 5) Запущенный объект кэша (неявного); 6) Управление параллелизмом (например, оптимистический, уровни изоляции, обнаружение конфликтов и т.д.); 7) Бизнес логика (например, в методе проверки/ значения по умолчанию, образцы свойств, события); 8) Расширение безопасности; 9) Отображение (запрос, схема) с поставщиками (например, реляционные, система файлового хранилища на основе базы данных); 10) Способность расширять метаданные (поддержка других пользователей объекта); 11) Операции набора; 12) Возможность вызова хранимых процедур; и 13) N-слойное развертывание.

Поддержка жизнеспособности объекта BF является естественно пригодной для CDP. Большинство требований поддержки жизнеспособности BF полностью поддержано CDP. К некоторым из требований SOA также обращается с помощью CDP. Однако полная поддержка модели агента/службы, бизнес операций и процессов BF может быть построена выше CDP, как структура LOB. Структура бизнес решений MBF также расположена на вершине CDP.

Фиг.21 и 22 иллюстрируют методологии в соответствии с объектом изобретения. Для простоты объяснения, методологии изображены и описаны как ряд действий. Необходимо понять и оценить, что объект изобретения не ограничен иллюстрированными действиями и/или порядком действий, например, действия могут произойти в различном порядке и/или одновременно с другими действиями, не представленными и описанными здесь. Кроме того, не все проиллюстрированные действия могут обязательно быть осуществлены методологией в соответствии с объектом изобретения. Кроме того, специалисты в данной области техники поймут и оценят, что методологии могут, альтернативно, быть представлены как ряд взаимосвязанных состояний через диаграмму состояний или событий.

Фиг.21 иллюстрирует методологию 2100, которая облегчает управление потоком данных в пределах различных компонентов CDP. В ссылке по номеру 2102 приложение создает объект данных заказа. Класс данных заказа может представлять собой тип набора таблиц, который был описан в схеме CDM. Объект данных заказа создает объект контекста хранения, который может формироваться по мере необходимости для взаимодействия с хранилищем. В ссылке по номеру 2104 открывается соединение с хранилищем, начинается сессия и создается транзакционный контекст, в котором установлен контекст безопасности. В ссылке по номеру 2106 экземпляр контекста хранения возвращается приложению.

В ссылке по номеру 2108 открывается интерфейс для получения объектов, основываясь на запросе CDM. В ссылке по номеру 2110 запрос отображается на SQL, применяя безопасность должным образом. Кроме того, приложение/пользователь могут видеть только данные, которым ему разрешено видеть. В ссылке по номеру 2112 результаты запроса возвращаются исполняемому объекту CDP и возвращаются приложению. В ссылке по номеру 2114 функция сохранения изменений может быть вызвана на инкапсулированном объекте контекста хранения для сброса изменений.

Фиг.22 иллюстрирует методологию, которая облегчает развертывание CDP для множества несопоставимых структур, где несопоставимые приложения могут быть связаны с каждой структурой. В ссылке по номеру 2202 создается хранилище данных, которое может хранить структурированные, частично структурированные и не структурированные данные. В ссылке по номеру 2204 создается CDP и накладывается на хранилище данных. Переходя к ссылке по номеру 2206, множественные структуры со связанными несопоставимыми приложениями могут получить доступ к хранилищу данных. В ссылке по номеру 2208 разделенные данные обеспечиваются для несопоставимых приложений на несопоставимых структурах. Другими словами, данные в пределах хранилища данных могут быть разделены среди множества несопоставимых приложений независимо от соответствующей структуры. В ссылке по номеру 2210 могут использоваться частные данные так, что частные данные могут быть определены для специфического приложения на специфической структуре.

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

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

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

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

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

Обратимся вновь к Фиг.23, где примерная среда 2300 для осуществления различных аспектов изобретения включает компьютер 2302, где компьютер 2302 включает процессорный модуль 2304, системную память 2306 и системную шину 2308. Системная шина 2308 соединяет компоненты системы, включая, но не ограничиваясь этим, системную память 2306 к процессорному модулю 2304. Процессорный модуль 2304 может быть любым из различных, коммерчески доступных процессоров. Двойные микропроцессоры и другие многопроцессорные архитектуры могут также использоваться как процессорный модуль 2304.

Системная шина 2308 может быть любой из нескольких типов шинных структур, которая может дополнительно связываться с шиной памяти (с или без диспетчера памяти), периферийной шиной и локальной шиной, используя любую из разнообразия коммерчески доступных шинных архитектур. Системная память 2306 включает постоянную память 2310 (ROM) и память 2312 произвольного доступа (RAM). Базовая система ввода/вывода (BIOS) сохранена в энергонезависимой памяти 2310, типа ROM, EPROM, EEPROM, и эта BIOS содержит основные подпрограммы, которые помогают передавать информацию между элементами в компьютере 2302, например, во время запуска. RAM 2312 может также включить быстродействующую RAM, типа статической RAM для кэширования данных.

Компьютер 2302 дополнительно содержит внутренний жесткий диск 2314 (HDD) (например, EIDE, SATA), и этот внутренний жесткий диск 2314 может также быть сконфигурированным для внешнего использования в подходящем шасси (не показанное здесь), дисковод 2316 гибких магнитных дисков (FDD), (например, для чтения или записи на сменный диск 2318) и дисковод 2320 оптического диска, (например, читая диск 2322 CD-ROM или читая или записывая другие высокопроизводительные оптические носители, типа DVD). Дисковод 2314 жесткого диска, дисковод 2316 магнитного диска и оптический дисковод 2320 могут быть связаны с системной шиной 2308 интерфейсом 2324 жесткого диска, интерфейсом 2326 магнитного диска и интерфейсом 2328 оптического диска соответственно. Интерфейс 2324 для реализации внешнего диска включает, по меньшей мере, один или оба интерфейса из универсальной последовательной шины (USB) и интерфейса по технологии IEEE 1394. Другие технологии подсоединения внешнего диска находятся в рассмотрении.

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

Множество программных модулей может быть сохранено в накопителях и RAM 2312, включая операционную систему 2330, одну или более прикладных программ 2332, другие программные модули 2334 и программные данные 2336. Вся или части операционной системы, приложений, модулей и/или данных могут также быть кэшированы в RAM 2312. Необходимо оценить, что различные, коммерчески доступные операционные системы или комбинации операционных систем, могут быть осуществлены с данной архитектурой.

Пользователь может вводить команды и информацию в компьютер 2302 через одно или более проводных/беспроводных устройств ввода, например клавиатуру 2338 и устройство позиционирования, типа мыши 2340. Другие устройства ввода (не показанные здесь) могут включать микрофон, IR дистанционное управление, джойстик, игровую клавиатуру, световое перо, сенсорный экран или подобное устройство. Эти и другие устройства ввода часто связаны с процессорным модулем 2304 через интерфейс 2342 устройств ввода, который соединен с системной шиной 2308, но может быть связан с другими интерфейсами, типа параллельного порта, IEEE 1394 последовательного порта, игрового порта, порта USB, интерфейса IR и т.д.

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

Компьютер 2302 может работать в сетевой среде, используя логические соединения через проводные и/или беспроводные соединения к одному или более удаленным компьютерам, типа удаленного компьютера(ов) 2348. Удаленный компьютер(ы) 2348 может быть рабочей станцией, серверным компьютером, маршрутизатором, персональным компьютером, портативным компьютером, развлекательным прибором на основе микропроцессора, одноранговым устройством или другим общим узлом сети и обычно включает многие или все элементы, описанные для компьютера 2302, хотя, в целях краткости, проиллюстрировано только устройство 2350 памяти/хранения. Изображенные логические соединения включают проводное/беспроводное соединение с локальной сетью 2352 (LAN) и/или большими сетями, например глобальной сетью (WAN) 2354. Такие сетевые среды LAN и WAN являются обычными в офисах и компаниях и содействуют компьютерным сетям масштаба предприятия, типа интранета, все из которых могут соединяться с глобальной коммуникационной сетью, например Интернет.

При использовании в сетевой среде LAN, компьютер 2302 связан с локальной сетью 2352 через проводной и/или беспроводной сетевой интерфейс или адаптер 2356. Адаптер 2356 может облегчить проводную или беспроводную связь с LAN 2352, которая может также включить беспроводную точку доступа, расположенную на ней для того, чтобы общаться с беспроводным адаптером 2356.

При использовании в сетевой среде WAN, компьютер 2302 может включать модем 2358 или связываться с коммуникационным сервером на WAN 2354, или иметь другие средства для установления связи по WAN 2354, например, посредством Интернета. Модем 2358, который может быть внутренним или внешним, проводным или беспроводным устройством, связан с системной шиной 2308 через интерфейс последовательного порта 2342. В сетевой среде программные модули, изображенные для компьютера 2302 или частей его, могут быть сохранены на удаленном устройстве 2350 памяти/хранения. Необходимо оценить, что показанные сетевые соединения являются примерными и могут использоваться другие средства установления связи между компьютерами.

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

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

Обратимся теперь к Фиг.24, где проиллюстрирована схематическая блок-схема примерной компьютерной среды 2400, которая может использоваться CDP и соответствующими компонентами и/или процессами для обеспечения управлением данными. Система 2400 включает одного или более клиентов 2402. Клиент(ы) 2402 могут быть аппаратными средствами и/или программным обеспечением (например, потоками, процессами, компьютерными устройствами). Клиент(ы) 2402 могут хранить cookie(s) (строка с данными о пользователе, возвращаемая Web-сервером при регистрации пользователя) и/или связанную контекстную информацию, используя архитектуру, например.

Система 2400 также включает один или более серверов 2404. Сервер(а) 2404 могут также быть аппаратными средствами и/или программным обеспечением (например, потоками, процессами, компьютерными устройствами). Сервера 2404 могут принять потоки для выполнения преобразования, используя архитектуру, например. Одно возможное взаимодействие между клиентом 2402 и сервером 2404 может быть в форме пакета данных, приспособленного для передачи между двумя или более компьютерными процессами. Пакет данных может включать cookie и/или связанную контекстную информацию, например. Система 2400 включает коммуникационную структуру 2406 (например, глобальную коммуникационную сеть, типа Интернета), которая может использоваться для облегчения взаимодействия между клиентом(ами) 2402 и сервером(ами) 2404.

Коммуникации могут быть облегчены через проводную (включая оптическое волокно) и/или беспроводную технологию. Клиент(ы) 2402 является работающим устройством, связанным с одним или более хранилищами 2408 данных клиента, которое может использоваться для хранения информации, локальной для клиента(ов) 2402 (например, cookie(s), и/или связанную контекстную информацию). Точно так же сервер(а) 2404 является работающим устройством, связанным с одним или более хранилищами данных 2410 сервера, которое может использоваться для хранения информации, локальной для серверов 2404.

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

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

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

2. Машиночитаемый носитель по п.1, где общая модель данных обеспечивает создание, по меньшей мере, одного элемента из типа, определенного для области, ограничения, и отношения.

3. Машиночитаемый носитель по п.2, где тип, определенный для области, является типом объекта, который является спецификацией для группировки, по меньшей мере, одного элемента из свойства и метода, где тип, определенный для области, использует, по меньшей мере, один элемент из объекта, таблицы, набора таблиц и отношения.

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

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

6. Машиночитаемый носитель по п.5, где язык запроса является, по меньшей мере, одним из Opath и OSQL (объектно-ориентированный структурированный язык запроса).

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

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

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

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

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

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

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

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

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

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

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

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

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

20. Система по п.17, дополнительно содержащая механизм ограничения/безопасности, который обеспечивает декларативное создание ограничений и управляет доступом к одному, по меньшей мере, объекту системы.