Результат интеллектуальной деятельности: СПОСОБ И СИСТЕМА ДЛЯ ТРАНЗАКЦИОННЫХ ФАЙЛОВЫХ ОПЕРАЦИЙ ПО СЕТИ

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

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

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

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

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

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

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

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

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

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

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

Фиг.1 - пример системы, использующей транзакционные удаленные файловые операции;

фиг.2 - пример компонентов клиента и сервера системы по фиг.1;

фиг.3 и 3А - примерная блок-схема последовательности операций обработки для транзакционной удаленной файловой операции между клиентом и сервером по фиг.2;

фиг.4 - пример многочисленных обращений к удаленному файлу клиентом и сервером по фиг.2;

фиг.5 - примерная блок-схема операций обработки для выполнения двухфазной фиксации транзакции по сети;

фиг.6 - пример компонентов для реализации управления транзакциями;

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

фиг.8 - пример признака защиты; и

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

Подробное описание предпочтительного варианта выполнения

Примерная сетевая среда

Как ранее описано, транзакции использовались в базах данных и системах обработки транзакций, но в нижеследующих вариантах выполнения транзакции используются для удаленных файловых операций. На фиг.1 изображена система 100, в которой клиент может провести транзакцию файловых операций на клиенте по сети 101. В примерной сетевой среде по фиг.1, многочисленные клиентские вычислительные устройства 105, 110, 115 и 120, которые также могут упоминаться как клиентские устройства, подсоединены по меньшей мере к одному серверному устройству 125 по сети 101. Сеть 101, как предполагается, представляет любую из многочисленных обычных сетевых топологий и типов, которые могут включать в себя проводные и/или беспроводные сети. Сеть 101 дополнительно может использовать любой из множества обычных сетевых протоколов, включая общие и/или узкоспециализированные протоколы. Сеть 101 может включать в себя, например, Интернет, а также, возможно, по меньшей мере части одной или нескольких локальных сетей (ЛС), глобальных сетей (ГС) и т.д.

Клиентское устройство 105 может включать в себя любое из множества обычных вычислительных устройств, включая в себя, но не ограничиваясь ими, настольный персональный компьютер (ПК), рабочие станции, мэйнфреймы, устройства для доступа к Интернету и игровые консоли. Другие клиентские устройства, связанные с сетью 101, могут включать в себя персональный цифровой помощник (ПЦП) 110, портативный компьютер 115 и сотовый телефон 120 и т.д., которые могут устанавливать связь с сетью 101 посредством проводной и/или беспроводной линии связи. Дополнительно, один или несколько из клиентских устройств 105, 110, 115 и 120 могут включать в себя некоторые типы устройств или, альтернативно, различные типы устройств.

Серверное устройство 125 может предоставлять любые из множества данных и/или функциональных возможностей вычислительным устройствам 105, 110, 115 и 120. Данные могут быть публично доступными или, альтернативно, ограниченными, например ограниченные только для некоторых пользователей или доступные только, если будет оплачена соответствующая плата и т.д.

Серверное устройство 125 представляет собой по меньшей мере один из сетевого сервера и сервера приложений, или их комбинацию. Серверное устройство 125 представляет собой любое устройство, которое является источником контента (содержания), и клиентские устройства 105, 110, 115 и 120 включают в себя любые устройства, которые принимают такой контент. Поэтому в одноранговой сети устройство, которое является источником контента, упоминается как серверное устройство, и устройство, которое принимает контент, упоминается как клиентское устройство. Оба типа устройств имеют возможность загружать и выполнять программы, включая операционные системы и приложения, согласно примерным вариантам выполнения, описанным в данной заявке. Далее, данные и функциональные возможности могут совместно использоваться клиентскими устройствами 105, 110, 115 и 120. Т.е. сервисное устройство 125 не является единственным источником данных и/или функциональных возможностей для соответствующих клиентских устройств.

На источнике 130 или 135 данных программы, включая операционные системы и приложения, готовятся и/или предоставляются для выполнения любому одному из серверного устройства 125 или клиентских устройств 105, 110, 115 и 120. Для согласованности, описание ниже ссылается на «приложения», которые охватывают любые из, по меньшей мере, программ, операционных систем и приложений, или в единственном числе, или в комбинации, как известно в технике. Кроме того, приложения распределяются на серверное устройство 125 автономно, как например, от источника 130 данных, или неавтономно, как например от источника 135 данных. Далее, приложения обычно распределяются на клиентские устройства 105, 110, 115 и 120 неавтономно от серверного устройства 125 или от источника 135 данных. Также известны средства и способы для их автономного распределения.

Согласно различным вариантам выполнения, описанным ниже, распределение по меньшей мере одного из данных и функциональных возможностей среди устройств 105, 110, 115, 120 и 125 может выполняться в виде транзакции. Более конкретно транзакция представляет собой группу операций, которые выполняются синхронно или асинхронно в виде единственной атомарной (неделимой) операции или в одном из устройств 105, 110, 115, 120 и 125, или в сетевой среде, такой как пример на фиг.1. Пример транзакционных удаленных файловых операций, выполняемых по сети, описывается более подробно ниже в связи с фиг.2-7.

Транзакционная удаленная файловая операция

На фиг.2 изображены компоненты двух устройств системы 100 (например, выбранные из устройств 105, 110, 115, 120 и 125) по фиг.1, которые работают в качестве клиента 202 и сервера 204 для целей транзакционной удаленной файловой операции. В данном варианте выполнения как клиент 202, так и сервер 204 используют версию операционной системы Microsoft® Windows®. В других вариантах выполнения могут использоваться различные операционные системы.

В данном варианте выполнения клиент 202 включает в себя приложение 212, диспетчер 214 ввода-вывода, файловую систему (ФС) 216, селектор 218 редиректора, администратор 222 транзакций (АТ) и редиректор (РДР) 220. Сервер 204 в данном варианте выполнения включает в себя серверный компонент (СРВ) 234, диспетчер 214А ввода-вывода, ФС 216А и АТ 222А. В данном варианте выполнения клиент 202 и сервер 204 могут устанавливать связь друг с другом по сети 100 (фиг.1). В некоторых вариантах выполнения эти компоненты реализуются программно.

В данном варианте выполнения, основанном на Windows, диспетчеры 214 и 214А ввода-вывода, ФС 216 и 216А реализуются файловой системой новой технологии (ФСНТ), и селектор 218 редиректора реализуется при помощи провайдера множественных УСИ (ПМУ), где УСИ представляет собой акроним для универсального соглашения об именовании. Таким образом, селектор 218 редиректора также упоминается в данной заявке как ПМУ 218. Кроме того, РДР и СРВ операционной системы Microsoft® Windows® (с добавленными функциональными возможностями) реализуют РДР 220 и СРВ 234 соответственно. Приведенные для примера дополнения к РДР и СРВ операционной системы Microsoft® Windows® описываются ниже. Далее, в данном варианте выполнения АТ 222 и АТ 222А реализуются в качестве администраторов транзакций уровня ядра в данном варианте выполнения и описываются ниже более подробно. В других вариантах выполнения могут использоваться различные диспетчеры ввода-вывода, файловые системы, селекторы редиректора, АТ и/или РДР.

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

В блоке 302 РДР 220 принимает запрос на транзакционную файловую операцию на файле, который является резидентным в сервере 204. Типовые файловые операции включают в себя создание нового файла, чтение файла, запись файла, копирование файла, переименование файла и т.д. В данном варианте выполнения запрос на транзакционную файловую операцию генерируется приложением 212, которое представляет собой приложение уровня пользователя, как показано на фиг.2. Запрос использует структуру, которая включает в себя поле для контекста транзакции. Запрос принимается диспетчером 214 ввода-вывода, который определяет, предназначен ли запрос для локального файла или для удаленного файла. В данном варианте выполнения диспетчер 214 ввода-вывода представляет собой стандартный компонент операционной системы Microsoft® Windows®. Например, приложение 212 может выполнить запрос при помощи вызова диспетчера 214 ввода-вывода с именем УСИ (которое присутствует в виде \\сервер\совместно используемый ресурс\подкаталог\имя файла). Диспетчер 214 ввода-вывода затем передает запрос на ПМУ 218. Могут быть многочисленные дескрипторы для транзакции и многочисленные транзакции для данного файла. С другой стороны, если запрос был в отношении файла на клиенте, диспетчер 214 ввода-вывода передает запрос ФСНТ 216 стандартным образом.

ПМУ 218 затем локализует редиректор, необходимый для выполнения запроса. В данном случае редиректором является РДР 220. В данном варианте выполнения ПМУ 218 представляет собой стандартный компонент операционной системы Microsoft® Windows®. В данном варианте выполнения РДР 220 представляет собой версию РДР операционной системы Microsoft® Windows® с дополнением, поэтому РДР может взаимодействовать с АТ 222 для выполнения транзакций. Дополнения включают в себя, например, способность извлекать контексты транзакции для транзакционных файловых операций из запросов, назначать блоки управления файлом (БУФ) для транзакционных файловых операций, посылать транзакции на удаленные устройства по сети, принимать ответы для транзакционных файловых операций (включая идентификаторы файла и идентификаторы версии), выполнять операции транзакции под управлением АТ 222 и вовлекать в качестве администратора ресурсов АТ 222, так что РДР 220 может быть осведомлен в отношении состояния транзакции. В некоторых вариантах выполнения РДР 220 реализуется так, как описано в совместно поданной и переуступленной патентной заявке США №09/539 233, поданной 30 марта 2000 г., на «Транзакционную файловую систему», и заявке №[номер дела поверенного №MS1-1781US]. Вовлечение в качестве администратора ресурсов описывается ниже. РДР 220 содержит ресурсы для буферизации транзакции, отображения кэша, блоков управления файлом (БУФ), расширений файлового объекта (РФО) и других структур, необходимых для обработки транзакции и запроса.

В блоке 304 РДР 220 извлекает транзакцию из АТ 222 и выполняет маршалинг для передачи клиенту 204. В одном варианте выполнения РДР 220 извлекает транзакцию посредством вызова интерфейса прикладного программирования (ИПП) (варианты выполнения которого описаны ниже), раскрываемого при помощи АТ 222, и выполняет маршалинг транзакции посредством форматирования информации транзакции (например, блоба маршалинга) для передачи с использованием версии протокола блока сообщений сервера (БСС), который был расширен для поддержки транзакций. Расширения БСС одного примерного варианта выполнения суммируются ниже в связи с таблицами 1-3. В блоке 306 РДР 220 посылает транзакцию и запрос на сервер 204, как указано стрелкой 236. В блоке 308 РДР 220 принимает результаты файловой операции от сервера 204. Например, сервер 204 посылает ответ на запрос, который содержит вышеупомянутые идентификаторы файла и версии. В данном варианте выполнения СРВ 234 представляет собой версию СРВ операционной системы Microsoft® Windows® с дополнениями, так что СРВ может взаимодействовать с клиентом по сети для выполнения транзакций с использованием расширения для БСС, включая передачу идентификаторов файла и версии клиентам во время транзакционных удаленных файловых операций.

REQ_CREATE_WITH_EXTRA_OPTIONS

RESP_CREATE_WITH_EXTRA_OPTIONS

REQ_FIND_FIRST2

Rsp_find_first2

REQ_ECHO

Rsp_echo

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

РДР 220 затем назначает БУФ запросу. Как упомянуто ранее, многочисленные транзакции с многочисленными запросами могут открывать данный файл. Таким образом, в одном варианте выполнения блока 302 (фиг.3) выполняется блок 314, в котором РДР 220 определяет, может ли существующий БУФ использоваться для запроса. В данном варианте выполнения РДР 220 проверяет, совпадает ли файл (т.е. имя пути) запроса и контекста транзакции, ассоциированного с потоком, выполняющим запрос, с файлом существующего БУФ. Например, если две операции записи одного и того же файла были запрошены в одной и той же транзакции, во время обработки второго запроса БУФ уже существует для первого запроса. Так как обеими операциями являются операции записи, один и тот же БУФ может использоваться для обоих.

Если в блоке 314 РДР 220 определяет, что БУФ существует с таким же контекстом транзакции и таким же файлом (т.е. именем файла) и такой же версией, то тогда в блоке 316 для запроса используется существующий БУФ. В некоторых вариантах выполнения РДР 220 будет использовать БУФ, который имеет самую последнюю версию. Например, если операция чтения файла следует за незафиксированной операцией записи этого же файла, РДР 220 будет использовать версию файла, которая в настоящее время используется операцией записи. Этот подход позволяет более эффективно использовать кэширование.

Однако если в блоке 314 существующий БУФ не может использоваться для запроса, в блоке 318 РДР создает новый БУФ для запроса. В альтернативном варианте выполнения новый БУФ создается для каждого запроса.

На фиг.4 изображен пример многочисленных незафиксированных транзакционных запросов одного и того же файла. Как показано на фиг.4, операция 401 соответствует запросу на операцию чтения файла. Т.е. файловой операцией является «открыть для чтения». Операция 401 имеет дескриптор Н1 и транзакцию Т1, ассоциированные с ней. Версия файла, которая запрашивается при помощи РДР 220 (фиг.2), обозначается как версия А. Предполагая, что это первая незафиксированная транзакция для этого файла, версия А извлекается с сервера 204 (фиг.2) и кэшируется в клиенте 202 (фиг.2).

В более поздний момент времени запрашивается операция 402 на этом же файле. В этом примере операцией 402 также является операция чтения, имеющая дескриптор Н2 и транзакцию Т2. Так как транзакция отлична от транзакции операции 401, РДР 220 снова извлекает версию А файла с сервера 204.

В этом примере затем запрашивается операция 403 над этим же файлом в этой же транзакции, что и операция 402. Таким образом, операция 403 имеет дескриптор Н3 и присоединяется к транзакции Т2. Однако операцией 403 является операция записи в данном примере, и, таким образом, РДР 220 локально запоминает (например, кэширует) версию В файла. Версия В иногда упоминается как «недействительная версия».

Затем запрашивается операция 404 на этом же файле в этой же транзакции, что и операции 402 и 403. Таким образом, операция 404 имеет дескриптор Н4 и также присоединяется к транзакции Т2. В данном примере операцией 404 является операция чтения. В данном варианте выполнения в результате действия блока 314 (фиг.3А) РДР 220 запоминает и, возможно, кэширует версию В для операции 404.

Затем запрашивается операция 405 над этим же файлом в другой транзакции. Таким образом, операция 405 имеет дескриптор Н5 и ассоциируется с новой транзакцией Т3. Так как транзакция отличается от транзакции предыдущих операций, в одном варианте выполнения РДР 220 снова извлекает версию А файла с сервера 204. В другом варианте выполнения РДР 229 распознает, что версия А все еще является текущей версией без обращения за справкой к серверу 204 (фиг.2) и использует «локальную» версию А. Например, данный альтернативный вариант выполнения может использовать оппортунистические блокировки, чтобы получить сведения о любых новых версиях файла, которые являются резидентными в сервере 204. Т.е. РДР 220 может ассоциировать уступающую блокировку с файлом, который не предотвращает запись в файл на сервере 204, но действительно вызывает сигнализацию сервером 204 РДР 220, что блокировка была нарушена. В таком случае РДР 200 будет тогда знать, что версия А больше не является текущей версией. В еще другом варианте выполнения РДР 220 может обратиться за справкой к серверу 204 с целью определения текущей версии файла и затем повторно использовать существующий БУФ, который ассоциируется с текущей версией.

Затем в операции 406 фиксируется транзакция Т2. Это вызывает изменение версии на сервере 204. Эта новая версия, хранимая на сервере 204, обозначается как версия С. Как ранее описано, так как РДР 220 вовлекается в качестве администратора ресурсов во время всех удаленных транзакций, РДР 220 узнает, что сервер 204 имеет новую версию файла.

Затем запрашивается операция 407 на этом же файле в этой же транзакции, что и операция 401. Таким образом, операция 407 имеет дескриптор Н6 и присоединяется к транзакции Т1. Однако так как РДР 220 знает о версии С файла на сервере 204, РДР 220 запоминает и, возможно, кэширует версию С для данной операции. В некоторых вариантах выполнения РДР 220 извлекает версию С с сервера 204.

Аналогично, когда запрашивается операция 408 для этого же файла в этой же транзакции, что и операция 405, операция 408 имеет дескриптор Н7 и присоединяется к транзакции Т3. Снова, так как РДР 220 знает о версии С файла на сервере 204, РДР 220 запоминает и, возможно, кэширует версию С для этой операции.

На фиг.5 показано, как кэшированные данные с клиента 202 (фиг.2) сбрасываются (т.е. долговременно запоминаются) на сервер 204 (фиг.2) согласно одному варианту выполнения. Как показано на фиг.2 и 5, клиент 202 сбрасывает данные на сервер 204, как описано ниже, согласно одному варианту выполнения.

В блоке 502 приложение, генерирующее данные, выполняет вызов или выдает запрос на фиксацию транзакции. Данный вызов или запрос передается на АТ 222. В ответ АТ 222 генерирует Уведомление Pre-prepare (описанное ниже в связи с Примерным администратором транзакций).

В данном варианте выполнения РДР 220 принимает Уведомление Pre-prepare от АТ 222, как показано в блоке 504. В ответ РДР 220 сбрасывает данные на СРВ 234 по сети. СРВ 234 в свою очередь передает данные ФСНТ 216А. Эти операции представляются блоком 506. В некоторых вариантах выполнения АТ 222А сервера 204 сигнализирует РДР 220, когда завершается операция Pre-prepare. Блоки 504 и 506 обеспечивают, что данные с клиента 202, подлежащие записи на сервере 204, присутствуют на сервере 204 до выполнения операции Prepare (описанной ниже в связи с Примерным администратором транзакций).

В блоке 508 РДР 220 принимает Уведомление Prepare (описанное ниже в связи с Примерным администратором транзакций) от АТ 222. В одном варианте выполнения РДР 220 посылает сообщение с Уведомлением Prepare на сервер 204 в ответ на Уведомление Prepare, которое передается на АТ 222А. В свою очередь АТ 222А передает Уведомление Prepare ФСНТ 216А. Эти операции представляются блоками 510 и 512. Уведомление Prepare вызывает запоминание клиентом 202 и сервером 204 данных так, что возможна или фиксация, или откат данных. В некоторых вариантах выполнения АТ 222А сервера 204 сигнализирует РДР 220, когда завершается операция Prepare. Данные затем обрабатываются с использованием стандартных операций двухфазной фиксации (например, операций, которые вызывают фиксацию или преждевременное прекращение транзакции), как представлено блоком 514.

Хотя управление транзакциями описано выше как выполняемое с использованием отдельных компонентов АТ (т.е. АТ 222 и 222А), в других вариантах выполнения инфраструктура управления транзакциями может интегрироваться в инфраструктуру файловой системы. Далее, в таких интегрированных вариантах выполнения сообщения транзакции (например, PrePrepare, Prepare, Commit, Abort и т.д., как описано ниже) передаются с файловыми сообщениями по каналу передачи.

Примерный администратор транзакций

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

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

На фиг.6 транзакция, соответствующая клиентскому приложению 600, использует, по меньшей мере, администратор 605 транзакций на первом устройстве, а также клиентское приложение 600 В и администратор 635 транзакций на втором устройстве. Клиентское приложение 600 В ассоциируется с клиентским приложением 600. Администраторы 605 и 635 транзакций, которые организуют связь друг с другом, могут быть агрегатами объектов ядра, которые сохраняют информацию о состоянии всех транзакций и ресурсов, и дополнительно координировать взаимодействие или протокол между клиентскими приложениями и ассоциированными администраторами ресурсов (АР).

Администраторы ресурсов, включающие в себя АР 625 и АР 630 в примере на фиг.6, сохраняют состояние по меньшей мере одного лежащего в основе ресурса, который может хранить данные в долговременном состоянии. Неисключающие примеры таких ресурсов включают в себя базы данных и очереди сообщений. В первом устройстве в примерном варианте выполнения по фиг.6 АР 625 соответствует ресурсу 627; АР 630 соответствует ресурсу 632; и во втором устройстве АР 655 соответствует ресурсу 657.

Как показано на фиг.6, администратор 605 транзакций на первом устройстве включает в себя следующие объекты ядра: объект 610 транзакции (ТХ), объект 615 администратора ресурсов (ОАР) и объект 620 вовлечения (ВОВ); и администратор 635 транзакций на втором устройстве включает в себя следующие объекты ядра: ТХ 640, ОАР 645 и ВОВ 650. ТХ представляет конкретную транзакцию и может быть открыт процессом, участвующим в транзакции.

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

ВОВ представляет зависимость между транзакцией и администратором ресурсов. Администратор ресурсов указывает, что он будет участвовать в транзакции посредством создания вовлечения в нее. Когда ОАР запрашивается выполнить операцию (такую как Prepare, Commit и т.д.) в конкретной транзакции, он использует ВОВ для указания участия. Администратор ресурсов может иметь более одного ВОВ на конкретной транзакции.

Протокол двухфазной фиксации, который реализуется для обеспечения, что транзакция успешно обновляет все соответствующие файлы, описывается для среды ядра с ссылкой на примеры по фиг.6 и 7 следующим образом. В частности, после открытия клиентским приложением 600 объектов ядра, соответствующих администратору 605 транзакций на первом устройстве, и открытием СРВ 234 (фиг.2) объектов ядра, соответствующих администратору 635 транзакций на втором устройстве, фаза 705 «подготовки» начинается с того, что каждому АР в транзакции посылается (705) порядок «подготовки» от соответствующего администратора транзакций. Извещенный таким образом АР подготавливается (710) путем представления данных ресурса в долговременном состоянии, так что данные в соответствующих ресурсах могут «фиксироваться» или «отклоняться». После подготовки АР передает 715 сообщение подтверждения на ТХ соответствующего администратора транзакций.

Фаза 720 «фиксации» выполняется при разрешении транзакции, посредством чего ТХ администратора транзакций передает (725) результат транзакции как «фиксировано», или «прекращено/отклонено» на каждый ассоциированный АР. АР затем регистрирует результат в ассоциированном журнале регистрации, и лежащие в основе данные ресурса или фиксируются, или отклоняются в соответствии с итогом транзакции. Альтернативные варианты выполнения могут предусматривать непостоянные вовлечения, для которых данные для транзакции не являются долговременными, и, поэтому, данные ни регистрируются, ни восстанавливаются.

Управление транзакциями на уровне ядра может реализовываться посредством использования интерфейсов прикладного программирования (ИПП), которые применимы к системным архитектурам, включая, но не ограничиваясь ими, интерфейс прикладного программирования Microsoft® Win32® и операционную систему Microsoft® Windows®. Описанные в данной заявке ИПП раскрываются при помощи интерфейса на базе дескрипторов, «дескриптора», ссылающегося на предназначенный для ИПП объект. Далее, если не запрашивается явно асинхронная операция, то операции на соответствующих объектах ядра являются синхронными, в частности ТХ и ОАР. Далее, операции, соответствующие различным вариантам выполнения транзакции, могут реализовываться различными комбинациями одного или нескольких ИПП, описанных в данной заявке. Т.е. в некоторых вариантах выполнения могут использоваться все ИПП, описанные в данной заявке, тогда как в других вариантах выполнения могут использоваться их различные комбинации.

ИПП для реализации операций на объектах ядра ТХ и соответствующее описание функциональных возможностей ИПП представлены ниже (более подробное описание ассоциированных подпрограмм представлено еще ниже):

- PreprepareEnlistment: также известные как обработка «Phase 0» запрашивает, чтобы ТХ передал сообщение о предварительной подготовке на все ассоциированные АР;

- PrepareEnlistment: запрашивает, чтобы ТХ передал запрос подготовки на все вовлеченные АР;

- CreateTransaction: открывает новый ТХ;

- OpenTransaction: открывает существующий ТХ;

- CommitTransaction: запрашивает, чтобы ТХ был фиксирован;

- RollbackTransaction: запрашивает, чтобы ТХ был преждевременно прекращен или произведен откат транзакции;

- SavepointTransaction: запрашивает, чтобы ТХ сохранил состояние транзакции;

- GetTransactionInfo: извлекает информацию о ТХ; и

- SetTransactionInfo: устанавливает информацию о ТХ.

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

- CreateResourceManager: создает новый ОАР, который представляет ресурс;

- OpenResourceManager: открывает существующий ОАР;

- DestroyResourceManager: разрушает ОАР, делая его несуществующим;

- GetResourceManagerInfo: извлекает информацию об ОАР;

- SetResourceManagerInfo: устанавливает информацию об ОАР;

- CreateEnlistment: вызывает присоединение ОАР к транзакции и извлекает относящиеся уведомления; и

- GetNotificationResourceManager: запрашивает и возвращает доступное уведомление АР.

ИПП, использованные для реализации операций на объектах ядра ТХ посредством объекта ядра ОАР после присоединения к транзакции, и соответствующее описание функциональных возможностей ИПП представлены ниже (более подробное описание ассоциированных подпрограмм представлено еще ниже):

- PrePrepareComplete: указывает, что АР завершил предварительную подготовку, запрошенную соответствующим администратором транзакций;

- PrepareComplete: указывает, что АР завершил подготовку транзакции, запрошенную соответствующим администратором транзакций;

- RollbackComplete: указывает, что АР завершил откат действий транзакции, которые были выполнены по запросу соответствующего администратора транзакций; и

- CommitComplete: указывает, что АР завершил фиксацию действий транзакции, запрошенных соответствующим администратором транзакций.

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

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

В первом устройстве СУД 660 применяется к ТХ 610, СУД 665 применяется к ОАР 615, и СУД 670 применяется к ВОВ 620. Во втором устройстве СУД 675 применяется к ТХ 640, СУД 680 применяется к ОАР 645, и СУД 685 применяется к ВОВ 650.

СУД определяет «права», которые разрешены или запрещены для применения к определенному объекту конкретным пользователем или группой пользователей. Более конкретно, как показано в примерном СУД 810 на фиг.8, СУД, который применяется или прикрепляется к объекту ядра, включает в себя по меньшей мере запись управления доступом (ЗУД), которая содержит соответствующий идентификатор защиты (ИДЗ) и соответствующий набор прав. Записи 1-12 ЗУД на фиг.8 включают в себя соответствующие ИДЗ 1-12 и соответствующие ПРАВА 1-12 соответственно.

ИДЗ 1-12 идентифицируют или пользователя, или группу пользователей, которые могут делать попытку реализовать операцию, или группу операций, на объекте ядра, к которому применяется СУД. ПРАВА 1-12 определяют операцию или группу операций, которые можно выполнять на соответствующем объекте ядра пользователем или группой пользователей, идентифицированных при помощи ИДЗ, и дополнительно определяют доступность такой операции или операций идентифицированному пользователю или группе пользователей. Т.е. ПРАВА 1-12 могут указывать, что идентифицированному пользователю или группе пользователей разрешено выполнять конкретную операцию или что идентифицированному пользователю или группе пользователей запрещено выполнять конкретную операцию.

Ниже представлен список примерных операций, которые могут определяться ПРАВАМИ 1-12 в СУД, применяемом к ТХ, за которыми следует описание функциональных возможностей операции. ПРАВА 1-12 дополнительно определяют, что операция разрешена или запрещена на ТХ для пользователя или группы пользователей, идентифицированных соответствующим ИДБ.

- TRANSACTION_QUERY_INFORMATION: для получения информации о ТХ;

- TRANSACTION_SET_INFORMATION: для установки информации о ТХ;

- TRANSACTION_ENLIST: для вовлечения ТХ в транзакцию;

- TRANSACTION_COMMIT: для представления долговременными всех обновлений данных, ассоциированных с ТХ;

- TRANSACTION_ROLLBACK: для преждевременного прекращения, т.е. отката операции на ТХ;

- TRANSACTION_PROPOGATE: для передачи данных с ТХ на другой объект;

- TRANSACTION_SAVEPOINT: для сохранения текущей точки транзакции; и

- TRANSACTION_MARSHAL: для передачи данных, относящихся к транзакции, на другое устройство.

Ниже представлен список примерных операций, которые могут определяться ПРАВАМИ 1-12 в СУД, применяемом к ОАР, за которыми следует описание функциональных возможностей операции. ПРАВА 1-12 дополнительно определяют, что операция разрешена или запрещена на ОАР для пользователя или группы пользователей, идентифицированных соответствующим ИДБ.

- RESOURCEMANAGER_QUERY_INFORMATION: для получения информации об ОАР;

- RESOURCEMANAGER_SET_INFORMATION: для установки информации об ОАР;

- RESOURCEMANAGER_RECOVER: для определения состояния транзакции в момент отказа транзакции;

- RESOURCEMANAGER_ENLIST: для вовлечения ОАР в транзакцию;

- RESOURCEMANAGER_GET_NOTIFICATION: для приема уведомления при разрешении транзакции от администратора транзакций;

- RESOURCEMANAGER_REGISTER_PROTOCOL: для регистрации протокола, который ОАР поддерживает в транзакции; и

- RESOURCEMANAGER_COMPLETE_PROPOGATION: для установки ресурса в соответствии с разрешением транзакции.

Ниже представлен список примерных операций, которые могут определяться ПРАВАМИ 1-12 в СУД, применяемом к ВОВ, за которыми следует описание функциональных возможностей операции. ПРАВА 1-12 дополнительно определяют, что операция разрешена или запрещена на ВОВ для пользователя или группы пользователей, идентифицированных соответствующим ИДБ.

- ENLISTMENT_QUERY_INFORMATION: для получения информации о ВОВ;

- ENLISTMENT_SET_INFORMATION: для установки информации о ВОВ;

- ENLISTMENT_RECOVER: для определения состояния вовлечений в момент отказа транзакции;

- ENLISTMENT_REFERENCE: для получения и ссылки (или отмены ссылки) на ключ вовлечения;

- ENLISTMENT_SUBORDINATE_RIGHTS: для отката транзакции и ответа на уведомления; и

- ENLISTMENT_SUPERIOR_RIGHTS: для выполнения операций, которые выполняет высший администратор транзакций; такие как инициирование операции предварительной подготовки, подготовки или преимущественного отката в транзакции.

Следовательно, каждый из объектов ядра ТХ, ОАР и ВОВ может иметь СУД, примененный соответственно к нему. Таким образом, когда ИПП пытается инициировать операцию на соответствующем одном из объектов ядра, СУД должен быть принят на обработку для определения, разрешена или запрещена операция для пользователя или группы пользователей, от которой исходит ИПП.

Более конкретно, когда дескриптор открывается для выполнения операции, пользователь или группа пользователей, соответствующие ИПП, проверяются в отношении ИДБ в СУД; генерируется список разрешенных операций; и операция, заданная ИПП, проверяется на разрешенные операции для ИДБ на данном дескрипторе.

Альтернативные варианты выполнения для защиты управления транзакциями среди объектов ядра и усиления параметров защиты включают в себя применение дескрипторов защиты к объектам ядра, которые могут принимать участие в транзакции, в соответствии с моделью защиты для операционной системы Microsoft® Windows®.

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

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

- Если эта подпрограмма не вызывается, и участник транзакции запросил обработку Phase0, запросы PrePrepare выдаются по запросу, когда принимается Prepare. Однако некоторые конфигурации, которые включают в себя кэшеподобные АР, могут вызывать необязательные откаты транзакции в распределенных сценариях, если нет PreprepareEnlistment.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий, что транзакция должна быть предварительно подготовлена;

ResourceManagerHandle: Предоставляет дескриптор высшему АТ/АР связи (АРС), который выполняет предварительную подготовку транзакции. Только этот высший АТ/АРС может вызвать PrepareEnlistment, SuperiorCommitTransaction и SuperiorRollbackTransaction на эту транзакцию.

- Возвращаемое значение:

STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_TOO_LATE

- Эта подпрограмма запрашивает, чтобы транзакция была «подготовлена» посредством выдачи запроса Prepare на все ассоциированные с ней администраторы ресурсов. Этот запрос начинает протокол двухфазной фиксации.

- Участник транзакции, выдающий PrepareEnlistment, переводит объект «транзакция» в долговременное состояние, которое сохранит работоспособность при полном отказе системы или аварийном завершении приложения; такой участник выполняет восстановление транзакции после отказа любого типа для доставки итога. Не выполнение этого требования может приводить к утечке ресурсов, а также к противоречивым итогам транзакции.

- Аргументы:

TransactionHandle: Предоставляет дескриптор для подготовки транзакции; и

ResourceManagerHandle: Предоставляет дескриптор АТ, который готовит транзакцию. Если транзакция была предварительно подготовлена (при помощи вызова PreprepareEnlistment), то тогда ResourceManagerHandle совпадает с высшим АТ/АРС, который использовался в вызове PreprepareEnlistment. Кроме того, только высшему АТ/АРС, который вызывает этот ИПП, будет разрешено вызвать SuperiorCommittransaction и SuperiorRollbackTransaction на этой транзакции.

- Возвращаемое значение:

STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES

STATUS_TM_TOO_LATE

STATUS_RM_NOT_RECOVERABLE

CreateTransaction

- Эта подпрограмма создает новый объект транзакция и возвращает дескриптор на новый объект.

- Альтернативно (если задан параметр ResourceManagerHandle), эта подпрограмма выполняет операцию «Join» на транзакции после успешного создания.

- Клиенты закрывают дескриптор транзакции, используя ИПП CloseHandle. Если последний дескриптор транзакции закрывается без вызова кем-нибудь CommitTransaction на транзакцию, то тогда транзакция неявно откатывается назад.

- Аргументы:

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

DesiredAccess: Предоставляет маску, задающую требуемый уровень доступа.

Варианты допустимых масок доступа:

SYNCHRONIZE Может выполнять операции синхронизации этого дескриптора.

TRANSACTION_COMMIT Может использовать этот дескриптор для фиксации транзакции;

TRANSACTION_PREPARE Может использовать этот дескриптор для фиксации транзакции;

TRANSACTION_ROLLBACK Может использовать этот дескриптор для преждевременного прекращения транзакции;

TRANSACTION_SAVEPOINT Может использовать этот дескриптор для создания точек сохранения для транзакции;

TRANSACTION_JOIN Может использовать этот дескриптор для присоединения к этой транзакции в качестве АР;

TRANSACTION_READ_ATTRIBUTES Может считывать атрибуты, ассоциированные с транзакцией;

TRANSACTION_WRITE_ATTRIBUTES Может записывать атрибуты, ассоциированные с транзакцией;

ObjectAttributes: Предоставляет указатель на необязательную структуру атрибутов объекта;

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

TRANSACTION_CREATE_PRESUMED_NOTHING Создает транзакцию «ничего не предполагается».

ResourceManagerHandle: Предоставляет дескриптор на ResourceManager, который принимает уведомления о заданной транзакции;

NotificationMask: Определяет уведомления, которые этот ResourceManager хотел бы получить в отношении этой транзакции; и

TransactionKey: Определяет непрозрачное значение указателя, которое АР хотело бы получить вместе с любым уведомлением для этой транзакции. АР может использовать это для ассоциирования уведомлений с некоторым объектом в адресном пространстве АР, таким образом устраняя необходимость выполнения поиска всякий раз, когда происходит уведомление.

- Возвращаемое значение:

- Эта подпрограмма производит поиск существующего объекта «транзакция» и возвращает дескриптор транзакции. Вызывающая программа задает строковое представление ГУИ в поле ObjectName ObjectAttributes.

- Альтернативно (если задан параметр ResourceManagerHandle), эта подпрограмма также выполняет операцию «Join» на транзакции после ее открытия.

- Клиенты закрывают дескриптор транзакции, используя ИПП CloseHandle. Если последний дескриптор транзакции закрывается без вызова кем-нибудь CommitTransaction на транзакцию, то тогда транзакция неявно откатывает назад транзакцию.

- Аргументы:

TransactionHandle: Предоставляет указатель на ячейку, которая будет принимать дескриптор для транзакции в случае успешной операции открытия;

DesiredAccess: Предоставляет маску, задающую требуемый уровень доступа.

ObjectAttributes: Предоставляет указатель на необязательную структуру атрибутов объекта;

ResourceManagerHandle: Предоставляет дескриптор на ResourceManager, который принимает уведомления о заданной транзакции;

NotificationMask: Определяет уведомления, которые этот ResourceManager может принимать в отношении этой транзакции; и

TransactionKey: Необязательно определяет непрозрачное значение указателя, которое АР хотел бы получить вместе с любым уведомлением для этой транзакции. АР может использовать это для ассоциирования уведомлений с некоторым объектом в адресном пространстве АР, таким образом устраняя необходимость выполнения поиска всякий раз, когда происходит уведомление.

- Возвращаемое значение:

- Эта подпрограмма запрашивает, чтобы была зафиксирована транзакция, ассоциированная с TransactionHandle. Любой дескриптор транзакции, который был открыт или создан, может быть зафиксирован при помощи Transaction_Сommit Desired Access. Так как нет ограничения, утверждающего, что только создателю транзакции разрешено ее фиксировать.

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

- Эта подпрограмма не вызывается, если транзакция ранее была подготовлена при помощи PrepareEnlistment. Только АР, который вызвал PrepareEnlistment, может разрешить состояние транзакции, используя подпрограмму SuperiorCommitTransaction.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий, что транзакция подлежит фиксации; и

CommitOptions: транзакция COMMIT_RETAINING будет фиксирована.

- Возвращаемое значение:

- Эта подпрограмма запрашивает, чтобы транзакция, ассоциированная с TransactionHandle, была отклонена. Отказ может быть частичным отказом, если задана необязательная SavePoint, и она является допустимой точкой сохранения. Аргумент SavePoint NULL указывает, что транзакция должна быть полностью отклонена или преждевременно прекращена. Может предоставляться необязательная структура RollbackReason; она будет удерживаться в объекте «транзакция» и может извлекаться заинтересованными участниками транзакции при помощи вызова GetInformationTransaction.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий, что транзакция должна быть отклонена; и

SavePoint: Предоставляет имя SavePoint, указывающее, насколько далеко назад должно быть возвращено состояние транзакции; и

RollbackReason: Предоставляет причину отклонения.

- Возвращаемое значение:

- Эта подпрограмма запрашивает, формирование «точки сохранения» для транзакции, ассоциированной с TransactionHandle; эта точка сохранения используется в качестве цели для последующих запросов отката.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий транзакцию, для которой должна быть установлена SavePoint;

SavepointFlags: Необязательно предоставляет набор флагов, которые оказывают влияние на генерирование точки сохранения; и

SavePoint: Предоставляет указатель на ячейку, где хранится идентификатор Savepoint.

- Возвращаемое значение:

- Эта подпрограмма возвращает запрошенную информацию об объекте «транзакция», представленном при помощи TransactionHandle.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий транзакцию, для которой запрашивается информация;

TransactionInformationClass: Указывает, какой класс информации об объекте «транзакция» запрашивается;

TransactionInformation: Предоставляет указатель на буфер, где хранится запрашиваемая информация транзакции;

TransactionInformationLength: Указывает длину буфера, указываемого посредством TransactionInformation; и

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

- Возвращаемое значение:

- Эта подпрограмма устанавливает запрашиваемую информацию об объекте «транзакция», представленном посредством TransactionHandle.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий транзакцию, информация которой будет модифицироваться;

TransactionInformationClass: Указывает, какой класс информации об объекте «транзакция» запрашивается;

TransactionInformation: Предоставляет указатель на буфер, где хранится запрашиваемая информация транзакции;

TransactionInformationLength: Указывает длину буфера, указываемого посредством TransactionInformation; и

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

- Возвращаемое значение:

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

- Эта подпрограмма создает новый объект ResourceManager для представления ресурса.

- Объект ResourceManager также служит в качестве конечной точки для уведомлений АТ, касающихся транзакции, к которым присоединился АР; АР запрашивает эти уведомления посредством вызова GetNotificationResourceManager.

- ResourceManager обычно представляет собой устойчивый объект, т.е. объект должен повторно открываться и выполнять восстановление после каждого сбоя (системы или АР). Временная версия объекта ResourceManager может быть создана посредством задания варианта RESOURCEMANAGER_NO_RECOVERY. Временный АР не обязан или ему не разрешается выполнять восстановление. Невосстанавливаемый вариант АР дает возможность приложению или АР принимать уведомления о развитии транзакции (например, PREPREPARE, PREPARE, COMMIT), не требуя реализации полной сложности регистрации подготовок и выполнения восстановления.

- Аргументы:

ResourceManagerHandle: Предоставляет указатель на ячейку, которая будет принимать дескриптор на новый ResourceManager;

DesiredAccess: Предоставляет маску, задающую требуемый уровень доступа. Доступные варианты маски доступа:

SYNCHRONIZE: для синхронизации операций на дескрипторе,

RESOURCE MANAGER_DESTROY: для уничтожения этого администратора ресурсов,

RESOURCE MANAGER_READ_ATTRIBUTES: для чтения атрибутов, ассоциированных с администратором ресурсов,

RESOURCE MANAGER_WRITE_ATTRIBUTES: для записи атрибутов, ассоциированных с администратором ресурсов;

ObjectAttributes: Определяет атрибуты для нового объекта АР; он включает в себя имя АР;

CreateOptions: Определяет опции для создаваемого объекта;

RESOURCEMANAGER_NO_RECOVERY: Объект ResourceManager является неустойчмвым и не выполняет восстановление;

RESOURCEMANAGER_COMMUNICATION: ResourceManager знает, как установить связь с другими компьютерами. ResourceManager может использоваться для выполнения маршалинга или демаршалинга транзакций;

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

NotificationRoutine: Определяет вызов подпрограммы уведомления, если уведомления доступны для этого ResourceManager.

- Возвращаемое значение:

- Эта подпрограмма открывает существующий объект ResourceManager по имени. Если целевой объект ResourceManager является устойчивым, но в настоящее время не открыт, объект находится первоначально в состоянии «восстановления» и должен быть восстановлен; после завершения восстановления должен быть вызван RecoveryCompleteResourceManager.

- Аргументы:

ResourceManagerHandle: Предоставляет указатель на ячейку, которая будет принимать дескриптор существующего объекта ResourceManager;

DesiredAccess: Предоставляет маску, определяющую требуемый доступ к этому объекту;

ObjectAttributes: Определяет атрибуты для нового объекта АР;

OpenOptions: Определяет опции для объекта. Допустимые опции включают в себя:

RESOURCE_MANAGER_DETAILED_RECOVERY_NOTIFICATIONS Администратор ресурсов принимает подробные уведомления восстановления (с дополнительной информацией о конечных точках связи) вместо обычных уведомлений восстановления; и

NotificationRoutine: Определяет подпрограмму уведомления, которая будет вызываться, когда уведомления доступны для этого ResourceManager.

- Возвращаемое значение:

- Эта подпрограмма уничтожает объект ResourceManager, обуславливая то, что он больше не является устойчивым.

- Аргументы:

ResourceManagerHandle: Предоставляет дескриптор, указывающий, что объект ResourceManager подлежит уничтожению.

- Возвращаемое значение:

- Эта подпрограмма возвращает запрашиваемую информацию об ОАР, представленным посредством ResourceManagerHandle.

- Аргументы:

ResourceManagerHandle: Предоставляет дескриптор, указывающий ResourceManager, для которого запрашивается информация;

ResourceManagerInformationClass: Указывает, какой класс информации об объекте ResourceManager запрашивается;

ResourceManagerInformation: Предоставляет указатель на буфер, где будет храниться запрашиваемая информация ResourceManager;

ResourceManagerInformationLength: Указывает длину буфера, указываемого посредством ResourceManagerInformation; и

ReturnLength: Предоставляет указатель на ячейку для приема длины информации, записываемой в буфер ResourceManagerInformation.

- Возвращаемое значение:

- Эта подпрограмма устанавливает запрашиваемую информацию об ОАР, представленном посредством ResourceManagerHandle.

- Аргументы:

ResourceManagerHandle: Предоставляет дескриптор, указывающий ResourceManager, для которого модифицируется информация;

ResourceManagerInformationClass: Указывает, какой класс информации об объекте ResourceManager запрашивается;

ResourceManagerInformation: Предоставляет указатель на буфер, где хранится запрашиваемая информация ResourceManager;

ResourceManagerInformationLength: Указывает длину буфера, указываемого посредством ResourceManagerInformation.

- Возвращаемое значение:

- Эта подпрограмма вызывает «присоединение» ОАР к конкретной транзакции и получение уведомлений, относящихся к ней.

- Вызов CreateEnlistment является идемпотентным, и АР может вызывать эту подпрограмму множество раз, чтобы изменить ее NotificationMask или TransactionKey. Последующие вызовы CreateEnlistment заменяют маску уведомления и ключ транзакции без создания нового вовлечения в транзакцию.

- NotificationMask может использоваться для запроса, чтобы уведомления принимались множество раз. Например, один АР, принимающий уведомление PREPREPARE, может запросить другой посредством вызова JoinTransaction и задания флага PREPREPARE. Таким образом, АР может принимать множество запросов PREPREPARE. Такие запросы могут быть отклонены, что может быть желательным, если транзакция прошла через точку, где было бы принято запрашиваемое уведомление. Например, не может быть разрешен запрос PREPREPARE, если некоторые АР уже были уведомлены о PREPARE.

- Аргументы:

ResourceManagerHandle: Предоставляет дескриптор АР для приема уведомлений о заданной Transaction;

TransactionHandle: Предоставляет дескриптор для транзакции, к которой АP желает присоединиться;

NotificationMask: Задает уведомления, которые АР хотел бы получить в отношении данной транзакции. Допустимыми масками являются следующие, и они могут быть обработаны вместе посредством операции ИЛИ:

TRANSACTION_NOTIFY_MASK_RM: Общие уведомления, требуемые АР (PREPARE, COMMIT, ROLLBACK, SAVEPOINT),

TRANSACTION_NOTIFY_MASK_CRM: Общие уведомления, требуемые для АРС или высшего АТ (PrePrepare_Complete, PrepareComplete, CommitComplete, RollbackComplete, SavebackComplete),

TRANSACTION_NOTIFY_PREPREPARE: Уведомление PrePrepare,

TRANSACTION_NOTIFY_PREPARE: Уведомление PREPARE,

TRANSACTION_NOTIFY_COMMIT: Уведомление COMMIT,

TRANSACTION_NOTIFY_ROLLBACK: Уведомление ROLLBACK,

TRANSACTION_NOTIFY_PREPREPARE_COMPLETE: Уведомление, что PREPREPARE завершено,

TRANSACTION_NOTIFY_PREPARE_COMPLETE: Уведомление, что PREPARE завершено,

TRANSACTION_NOTIFY_COMMIT_COMPLETE: Уведомление, что COMMIT завершено,

TRANSACTION_NOTIFY_ROLLBACK_COMPLETE: Уведомление, что ROLLBACK завершено и

TRANSACTION_NOTIFY_SAVEPOINT_COMPLETE: Уведомление, что SAVEPOINT завершено; и

TransactionKey: Задает непрозрачное значение указателя, что АР хотел бы принять вместе с любым уведомлением для этой транзакции. АР может использовать его для ассоциирования уведомлений с некоторым объектом в адресном пространстве АР, таким образом устраняя необходимость выполнения поиска всякий раз, когда происходит уведомление.

- Возвращаемое значение:

- Эта подпрограмма запрашивает и возвращает уведомление АР, если какие-либо доступны.

- Аргументы:

ResourceManagerHandle: Предоставляет дескриптор, указывающий ResourceManager, для которого должно быть возвращено уведомление;

TransactionNotification: Предоставляет указатель на структуру TRANSACTION_NOTIFICATION, подлежащую заполнению первым доступным уведомлением; и

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

- Возвращаемое значение:

STATUS_SUCCESS

STATUS_TIMEOUT

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES.

Нижеследующее включает в себя более подробное описание перечисленных выше ИПП для выполнения операций над объектами ядра ТХ объектами ядра ОАР после присоединения к транзакции. Описания включают в себя описание подпрограммы, соответствующих аргументов и возвращаемых значений.

PrePrepareComplete

(IN PHANDLE EnlistmentHandle);

- Эта подпрограмма указывает, что АР завершил обработку предварительной подготовки (известной также как «Phase0») транзакции, запрашиваемой КТМ

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий Transaction, для которой была завершена операция предварительной подготовки.

- Возвращаемое значение:

- Эта подпрограмма указывает, что АР завершил подготовку транзакции, как запрашивалось посредством КТМ

- Аргументы:

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

- Возвращаемое значение:

- Эта подпрограмма указывает, что АР успешно завершил откат действий, выполненных посредством запрашиваемой транзакции. Если АР не может успешно выполнить откат запрашиваемой транзакции, он должен выдать запрос на полный откат посредством RollbackTransaction.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий транзакцию, для которой была завершена операция отката.

- Возвращаемое значение:

- Эта подпрограмма указывает, что АР завершил фиксацию действий, выполненных посредством запрашиваемой транзакции.

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий транзакцию, для которой была завершена операция фиксации.

- Возвращаемое значение:

Кроме того, подпрограммы распространения могут быть предусмотрены для объектов ядра. Пример таких подпрограмм приведен ниже.

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

- Аргументы:

ResourceManager: Предоставляет дескриптор для администратора ресурсов, который регистрируется;

ProtocolId: ГУИ, идентифицирующий протокол;

ProtocolInformationSize: Размер ProtocolInformation;

ProtocolInformation: Необязательный блоб для ассоциации с данным протоколом;

- Возвращаемые значения:

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

- Аргументы:

TransactionHandle: Предоставляет дескриптор, указывающий транзакцию, для которой была завершена операция фиксации;

NumberOfProtocols: Указывает размер массива протоколов;

ProtocolArray: Массив PROTOCOL_ID (GUID), который задает протоколы, которые могут использоваться для выполнения маршалинга данной транзакции. Массив должен быть упорядочен по предпочтению - первый протокол в массиве является предпочтительным протоколом, второй протокол является вторым наиболее предпочтительным протоколом и т.д.

BufferLength: Предоставляет длину буфера, который доступен;

Buffer: Предоставляет указатель на буфер, где должно храниться последовательное упорядочение транзакции; и

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

- Возвращаемые значения:

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

- Аргументы:

AddressBufferSize: Предоставляет длину буфера, который доступен;

AddressBuffer: Предоставляет длину буфера, который доступен.

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

- Возвращаемое значение:

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

- Аргументы:

TransactionHandle: Предоставляет указатель, где должен храниться дескриптор, представляющий новую транзакцию;

NumberOfProtocols: Указывает размер массива протоколов;

ProtocolArray: Массив PROTOCOL_ID (GUID), который задает протоколы, которые могут быть использованы для выполнения маршалинга данной транзакции. Массив должен быть упорядочен по предпочтению - первый протокол в массиве является предпочтительным протоколом, второй протокол является вторым наиболее предпочтительным протоколом и т.д.

BufferLength: Предоставляет длину буфера, который доступен;

Buffer: Предоставляет указатель на буфер, где хранится последовательное упорядочение транзакции.

- Возвращаемые значения:

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

- Аргументы:

TransactionHandle: Предоставляет указатель на объект транзакции, который должен быть распространен на удаленную машину;

DestinationInfoLength: Предоставляет длину DestinationInfoLength, который является доступным;

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

ResponseBufferLength: Предоставляет длину ResponseBuffer, который является доступным;

ResponseBuffer: Предоставляет указатель на буфер, где хранится последовательное упорядочение транзакции; и

PushCookie: Предоставляет указатель на буфер, где будут храниться Сookie-файлы (идентификационные файлы), представляющие данный запрос принудительной рассылки.

- Возвращаемое значение:

- Данный вызов используется для извлечения выходного результата вызова PushTransaction в том случае, если первоначальный вызов PushTransaction принял код возврата STATUS_BUFFER_TOO_SMALL. В данном случае, вызывающей программе необходимо вызвать GetPushTransactionBuffer и передать достаточный размер буфера.

- Аргументы:

TransactionHandle: Предоставляет указатель на ячейку, где должен храниться дескриптор, представляющий новую транзакцию;

BufferLength: Предоставляет длину буфера, который доступен; и

Buffer: Предоставляет указатель на буфер, где хранится последовательное упорядочение транзакции.

- Возвращаемое значение:

- Данная подпрограмма вызывается посредством АРС после его успешного завершения распространения транзакции.

- Аргументы:

TransactionHandle: Предоставляет указатель на ячейку, где должен храниться дескриптор, представляющий новую транзакцию;

RequestCookie: Предоставляет RequestCookie, который был принят в первоначальном аргументе уведомления PROPAGATE для указания, какой запрос был завершен;

BufferLength: Предоставляет длину буфера, который доступен; и

Buffer: Предоставляет указатель на буфер, где хранится последовательное упорядочение транзакции.

- Возвращаемое значение:

- АРС использует данную подпрограмму для указания, что он не смог распространить запрашиваемую транзакцию.

- Аргументы:

TransactionHandle: Предоставляет указатель на ячейку, где должен храниться дескриптор, представляющий новую транзакцию;

BufferLength: Предоставляет длину буфера, который доступен; и

Buffer: Предоставляет указатель на буфер, где хранится последовательное упорядочение транзакции.

- Возвращаемое значение:

STATUS_SUCCESS

STATUS_ACCESS_DENIED

STATUS_INVALID_HANDLE

STATUS_INSUFFICIENT_RESOURCES.

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

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

Компьютерная среда 900 включает в себя вычислительное устройство общего назначения в виде компьютера 902. Компоненты компьютера 902 могут включать в себя, но не ограничиваются ими, один или несколько процессоров или блоков 904 обработки, системную память 906 и системную шину 908, которая соединяет различные компоненты системы, включая процессор 904 с системной памятью 906.

Системная шина 908 представляет собой один или несколько из любых нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессор или локальную шину, использующие любую из множества шинных архитектур. В качестве примера, такие архитектуры могут включать в себя шину архитектуры промышленного стандарта (АПС), шину микроканальной архитектуры (МКА), шину расширенной АПС (РАПС), локальную шину ассоциации по стандартизации в области видеотехники (АСВТ), шину межсоединений периферийных компонентов (МПК), также известную как шина расширения, шину МПК Экспресс, Универсальную последовательную шину (УПШ), шину SD (Secure Digital) или шину IEEE 1394, т.е. FireWire.

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

Системная память 906 включает в себя считываемые компьютером носители в виде энергозависимой памяти, такой как оперативное запоминающее устройство (ОЗУ) 910; и/или энергонезависимой памяти, такой как постоянное запоминающее устройство (ПЗУ) 912 или флэш-ОЗУ. Базовая система 914 ввода-вывода (БСВВ), содержащая основные подпрограммы, которые способствуют переносу информации между элементами внутри компьютера 902, например во время запуска, хранится в ПЗУ 912 или флэш-ОЗУ. ОЗУ 910 обычно содержит данные и/или программные модули, к которым происходит немедленное обращение блоком 904 обработки и/или которые обрабатываются им в настоящий момент.

Компьютер 902 также может включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые носители данных компьютера. В качестве примера, на фиг.9 изображен накопитель 916 на жестких дисках для считывания и записи на несъемные энергонезависимые магнитные носители (не показаны), накопитель 918 на магнитных дисках для считывания и записи на съемный энергонезависимый магнитный диск 920 (например, «дискету») и накопитель 922 на оптических дисках для считывания и/или записи на съемный энергонезависимый оптический диск 924, такой как компакт-диск, цифровой многофункциональный диск, предназначенный только для чтения, или другой оптический носитель. Накопитель 916 на жестких дисках, накопитель 918 на магнитных дисках и накопитель 922 на оптических дисках каждый подключается к системной шине 908 при помощи одного или нескольких интерфейсов 925 носителей данных. Альтернативно, накопитель 916 на жестких дисках, накопитель 918 на магнитных дисках и накопитель 922 на оптических дисках могут подключаться к системной шине 908 при помощи одного или нескольких интерфейсов (не показаны).

Накопители на дисках и связанные с ними считываемые компьютером носители обеспечивают энергонезависимое хранение считываемых компьютером инструкций, структур данных, программных модулей и других данных для компьютера 902. Хотя в примере изображен жесткий диск 916, съемный магнитный диск 920 и съемный оптический диск 924, понятно, что другие типы считываемых компьютером носителей, которые могут хранить данные, к которым обращается компьютер, такие как магнитные кассеты или другие магнитные запоминающие устройства, карты флэш-памяти, компакт-диск, цифровые многофункциональные диски (ЦМД) или другие оптические запоминающие устройства, оперативные запоминающие устройства (ОЗУ), постоянные запоминающие устройства (ПЗУ), электрически стираемые программируемые постоянные запоминающие устройства (ЭСППЗУ) и т.п.также могут использоваться для реализации примерной вычислительной системы и среды.

Любое количество программных модулей может храниться на жестком диске 916, магнитном диске 920, оптическом диске 924, в ПЗУ 912 и/или ОЗУ 910, включая в себя, в качестве примера, операционную систему 926, одну или несколько программ 928 приложений, другие программные модули 930 и программные данные 932. Каждая из таких, как операционная система 926, одна или несколько программ 928 приложений, другие программные модули 930 и программные данные 932 (или их некоторые комбинации), могут установить транзакции в соответствии с примерными вариантами выполнения, описанными выше, для реализации всех или части резидентных компонентов, которые поддерживают распределенную файловую систему.

Пользователь может вводить команды и информацию в компьютер 902 при помощи устройств ввода, таких как клавиатура 934 и указательное устройство 936 (например, «мышь»). Другие устройства 938 ввода (специально не показаны) могут включать в себя микрофон, джойстик, игровой планшет, антенну спутниковой связи, последовательный порт, сканер и/или т.п. Эти и другие устройства ввода подключаются к блоку 904 обработки при помощи интерфейсов 940 ввода-вывода, которые подсоединены к системной шине 908, но могут подключаться к другим интерфейсам и шинным структурам, таким как параллельный порт, игровой порт или универсальная последовательная шина (УПШ).

Монитор 942 или устройство отображения другого типа также может подключаться к системной шине 908 при помощи интерфейса, такого как видеоадаптер 944. В дополнение к монитору 942 другие периферийные устройства вывода могут включать в себя компоненты, такие как громкоговорители (не показаны) и принтер 946, которые могут подключаться к компьютеру 902 при помощи интерфейсов 940 ввода-вывода.

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

Логические соединения между компьютером 902 и удаленным компьютером 948 изображаются в виде локальной сети (ЛС) 950 и общей глобальной сети (ГС) 952. Такие сетевые среды являются обычным явлением в офисах, компьютерных сетях масштаба предприятия, интрасетях и Интернете.

При реализации в сетевой среде ЛС компьютер 902 подключается к локальной сети 950 при помощи сетевого интерфейса или адаптера 954. При реализации в сетевой среде ГС компьютер 902 обычно включает в себя модем 956 или другое средство для установления связи по глобальной сети 952. Модем 956, который может быть внутренним или внешним по отношению к компьютеру 902, может подключаться к системной шине 908 при помощи интерфейсов 940 ввода-вывода или других соответствующих механизмов. Изображенные сетевые соединения приведены для примера, и могут использоваться другие средства установления по меньшей мере одной линии связи между компьютерами 902 и 948.

В сетевой среде, такой как изображенная с вычислительной средой 900, программные модули, описанные в отношении компьютера 902, или его частей, могут храниться на устройстве хранения удаленной памяти. В качестве примера, удаленные программы 958 приложений являются резидентными на устройстве памяти удаленного компьютера 948. Для целей иллюстрации приложения или программы и другие исполняемые программные компоненты, такие как операционная система, изображаются в данной заявке как дискретные блоки, хотя понятно, что такие программы и компоненты являются резидентными в различные моменты времени в различных компонентах хранения вычислительного устройства 902 и выполняются по меньшей мере одним процессором данных компьютера.

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

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

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

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

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

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

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