Содержание к диссертации
Введение
ГЛАВА 1. Эволюция технологий построения распределенных вычислительных сред . 12
1.1 Концепция распределенных вычислительных сред 12
1.2 Современные технологии построения распределенных вычислительных сред 16
1.2.1 Промежуточное программное обеспечение. 16
1.2.2 Организация параллельных вычислений «масштабах глобальной сети. 33
1.2.3 Grid-вычисления 42
1.2.4 Современные средства решения декомпозируемых вычислительных задач в РВС. 85
1.3 Описание и классификация основных видов ресурсов РВС 94
1.3.1 Аппаратные ресурсы 94
1.3.2 Программные ресурсы 95
1.3.3 Информационные ресурсы. 95
1.3.4 Сетевые ресурсы 96
1.3.5 Инструментальные ресурсы 96
1.3.6 Человеческие ресурсы 97
1.4 ОСНОВНЫЕ ЗАДАЧИ РАБОТЫ 97
1.4.1 Проблемы современной программной инфраструктуры РВС. 97
1.4.2 Основные задачи работы 100
ГЛАВА 2 Принципы построения распределенной вычислительной среды на основе концепции информационно-алгоритмических ресурсов 102
2.1 Понятие информационно-алгоритмического ресурса 102
2.1.1 Интеграция первичных ресурсов на основе агентов доступа . 103
2.1.2 Модель доступа к информационно-алгоритмическим ресурсам 103
2.1.3 Типизация информационно-алгоритмических ресурсов. 104
2.1.4 Композиция информационно-алгоритмических ресурсов и прикладные сценарии. 105
2.2 Архитектура распределенной вычислительной среды на основе концепции ИАР 105
2.2.1 Уровень агентов доступа. 106
2.2.2 Уровень служб. 107
2.2.3 Уровень прикладного API. 108
2.3 Основные требования к программной инфраструктуре РВС 108
2.3.1 Функциональные требования. 109
2.3.2 Нефункциональные требования. 112
2.3.3 Проектные ограничения 113
2.4 Архитектура системы iarnet 113
2.4.1 Агент доступа. 114
2.4.2 Контейнер ИАР. 115
2.4.3 Клиентская библиотека. 117
2.4.4 Коннекторы 117
2.4.5 Служба. 118
ГЛАВА 3. Организация вычислений в распределенной вычислительной среде на основе iarnet ... 120
3.1 Интеграция первичных ресурсов 120
3.1.1 Разработка агента доступа. 120
3.1.2 Организация удаленного доступа к ресурсу. 122
3.1.3 Задачи, связанные с организацией доступа к ресурсу. 127
3.2 Идентификация ресурсов 134
3.2.1 Постановка задачи. 134
3.2.2 Идентификатор ресурса. 135
3.2.3 Ссылка на ресурс. 137
3.2.4 Отображение идентификатора ресурса в ссылку на ресурс. 138
3.2.5 Идентификатор типа ресурса. 140
3.3 Типы данных и описание интерфейсов ресурсов 141
3.3.1 Постановка задачи 141
3.3.2 Система типов данных lARnet. 141
3.3.3 Нотация для описания интерфейсов ресурсов . 143
3.4 Информационная служба 145
3.4.1 Постановка задачи. 145
3.4.2 Представление информации о РВС. ,.146
3.4.3 Хранение информации о РВС. 151
3.4.4 Доступ к информации о РВС. 151
3.4.5 Сбор информации о РВС. 152
3.4.6 Информационная служба. 153
3.4.7 Управление информацией а ресурсе в агенте доступа. 157
3.5 Групповое взаимодействие ресурсов 159
3.5.1 Постановка задачи. 159
3.5.2 Огужба рассылки сообщений. 160
3.5.3 Интерфейс потребителя сообщений 162
3.5.4 Дальнейшее развитие подхода. 162
3.6 Описание и выполнение прикладных вычислительных сценариев 163
3.6.1 Постановка задачи. 163
3.6.2 Описание прикладных вычислительных сценариев. 164
3.6.3 Служба управления сценариями. 169
3.7 Другие службы iarnet 173
3.7.1 Служба журналов. 173
3.8 Модель прикладного программирования iarnet 175
3.8.1 Интерфейс представителя ресурса на клиентской стороне. 176
3.8.2 Интерфейс клиента информационной службы 177
3.8.3 Пример использования lARnet АРІ для поиска и вызова ресурса. 178
ГЛАВА 4. Применение iarnet для решения прикладных задач 180
4.1 Распределенное решение задачи оптимального управления ISO
4.1.1 Процедура продолжения оптимальных траекторий 181
4.1.2 Основные вычислительные подзадачи. 186
4.1.3 Символьное представление задачи Кошидля системы ОДУ и алгоритм решения 189
4.1.4 Требуемые типы ресурсов. 196
4.1.5 Схема распределенного решения задачи оптимального управления. 196
4.2 Распределенное решение системы обыкновенных дифференциальных уравнений 198
4.2.1 Схема распределенного решения системы ОДУ. 199
4.3 Распределенная имитационная модель экологической, экономической и социалы юй
Динамики , 202
Заключение 204
Список литературы
- Современные технологии построения распределенных вычислительных сред
- Интеграция первичных ресурсов на основе агентов доступа
- Организация удаленного доступа к ресурсу.
- Нотация для описания интерфейсов ресурсов
Введение к работе
Диссертация посвящена разработке целостной программно-алгоритмической модели решения декомпозируемых вычислительных задач в распределенной среде.
Более точно класс рассматриваемых вычислительных задач можно определить как задачи, декомпозируемые на слабо связанные в вычислительном отношении и, в общем случае, функционально различные типовые подзадачи. Первое обстоятельство учитывает специфику проведения вычислений в распределенной среде, где для эффективного решения задачи необходимо минимизировать сетевые обмены данными. Формально это требование можно сформулировать в следующем виде: характерные времена процессов вычислений в рамках подзадач должны быть много больше характерных времен процессов обменов данными между подзадачами. Второе обстоятельство указывает на более широкий класс задач, чем задачи, решаемые в рамках параллельных вычислений, где подзадачи, как правило, являются функционально однотипными. Слово "типовой" означает, что данная подзадача не является специфической, а имеет общее значение и встречается в целом ряде исходных задач.
В качестве основного примера подобной декомпозируемой вычислительной задачи в диссертации рассматривается процедура решения задачи оптимального управления. Общепризнанно, что задачи оптимального управления со смешанными ограничениями остаются трудными для численного решения на обычных компьютерах, несмотря на большое количество работ, посвященных алгоритмам решения этих задач. Зачастую бывает трудно оценить требуемые для решения задачи вычислительные мощности априори, перед запуском решения. Это может привести к тому, что, будучи запущенным на ограниченных ресурсах одного компьютера (и даже нескольких), вычислительный процесс в определенный момент столкнется с нехваткой ресурсов, и процесс решения задачи остановится.
В случае задачи оптимального управления интерес представляет алгоритм, который мог бы привлечь к решению задачи одновременно разнородные вычислительные ресурсы, доступные через глобальную (или локальную) сеть. Таким алгоритмом является известный алгоритм продолжения оптимальных траекторий, допускающий эффективную декомпозицию на слабо связанные в вычислительном отношении подзадачи. Подобная декомпозиция позволяет реализовать решение задачи оптимального управления в распределенной вычислительной среде (РВС), которая состоит из набора вычислительных ресурсов, развернутых на узлах глобальной сети. Каждый из ресурсов среды реализует некоторый метод решения одной из подзадач.
В качестве еще одной задачи, характерной для указанного класса, в диссертации рассматривается задача имитационного моделирования. В настоящее время в различных организациях накоплено большое количество имитационных моделей в самых разнообразных областях и программных комплексов, позволяющих выполнять в их рамках имитационные эксперименты. Среди этих моделей и программных комплексов имеются такие, которые разработаны разными группами исследователей, однако, описывают один и тот же процесс, возможно, разные его части (стороны). Поэтому, задача интеграции этих ресурсов посредством организации удаленного доступа к ним, представляется актуальной. Решение этой задачи позволит формировать и выполнять имитационные эксперименты с гораздо более сложными имитационными моделями, чем это возможно сейчас. Это существенно расширяет область применения технологии имитационного моделирования при анализе и прогнозе реальных явлений, процессов, систем. Очевидно, что предлагаемый подход применим и для других важных классов задач.
Несмотря на наличие развитых средств построения распределенных систем, организация РВС и её использование для решения вычислительных задач остается сложной технической и организационной проблемой. Фактически, в каждом конкретном случае, это выливается в разработку и развертывание специальной программной инфраструктуры, создаваемой под конкретную задачу и требующей высокой квалификации программистов. Таким образом, существует объективная необходимость создания общей программной инфраструктуры РВС, интегрирующей распределенные ресурсы для решения указанного класса задач. Современные комплексы программ, направленные на создание подобной инфраструктуры (т.н. Grid-технологии), отличаются недостаточно высоким уровнем работы с вычислительными ресурсами и не всегда учитывают специфику решения декомпозируемых вычислительных задач. В диссертации предлагается новый подход к построению распределенной вычислительной среды, призванный заполнить пробел между прикладными задачами и современными технологиями построения РВС.
Целью диссертации является разработка целостной программно-алгоритмической модели решения декомпозируемых вычислительных задач в РВС и применение полученных результатов для решения прикладных задач (на примере задач оптимального управления и имитационного моделирования).
Для решения поставленных задач использовались методы математического моделирования, оптимального управления, вычислительной математики, методы построения распределенных комплексов проблемно-ориентированных программ.
В первой главе диссертации рассмотрена эволюция технологий построения распределенных вычислительных систем, проведена классификация основных видов ресурсов РВС и сформулированы основные задачи работы. Рассматривается общая концепция распределенных вычислительных сред, а также проблемы, связанные с переносом вычислительного процесса в распределенную среду. Проведено сравнение и анализ различных концепций построения РВС от идеи метакомпьютера до Grid-вычислений. Рассмотрены современные технологии, используемые для построения РВС и решения декомпозируемых вычислительных задач. Приводится описание и классификация основных видов ресурсов, которые могут быть использованы для организации вычислительного процесса в рамках РВС. Для каждого класса ресурсов описан современный уровень его интеграции в РВС. На основе рассмотрения общей структуры программного обеспечения РВС, описываются проблемы современных технологий построения РВС, которые не позволяют эффективно решать распределенным образом декомпозируемые вычислительные задачи. Показано, что современная программная инфраструктура РВС не является достаточно полной и не всегда поддерживает в равной мере различные типы ресурсов.
Из проведенного обзора современного состояния технологий построения РВС вытекают следующие основные задачи диссертации:
Разработка целостной программно-алгоритмической модели решения декомпозируемых вычислительных задач в РВС.
Разработка общего подхода к построению РВС для решения задач оптимального управления и имитационного моделирования.
Разработка универсальной модели интеграции ресурсов в РВС.
Разработка набора служб, которые реализуют базовые механизмы, востребованные приложениями и компонентами среды.
Разработка модели прикладного программирования, позволяющей исследователям работать с ресурсами и службами среды максимально прозрачным образом.
Во второй главе описываются основополагающие принципы разработанного подхода к организации РВС для решения задачи оптимального управления. Данный подход с самого начала описывается в максимально общем виде, допускающем его перенос на решение других декомпозируемых вычислительных задач.
В первом параграфе вводятся составляющие основу разработанного подхода понятия. Главным из них является понятие информационно-алгоритмического ресурса (ИАР) как абстракции, позволяющей сформировать РВС для решения декомпозируемых вычислительных задач. Предварительно вводится понятие первичного ресурса. Первичный ресурс - любой ресурс "как он есть" в отрыве от РВС, который поддерживает программный доступ к своей функциональности и может быть полезен для решения задачи, то есть реализует некоторый метод ее решения. Тогда под информационно-алгоритмическим ресурсом (ИАР) будем понимать абстрактный ресурс с четко описанной функциональностью и программным интерфейсом удаленного доступа к этой функциональности, скрывающий за собой один или несколько первичных ресурсов. Абстракция ИАР скрывает от других компонентов среды особенности реализации первичного ресурса и его интеграции в среду, делая видимым только саму функциональность ресурса в виде унифицированного интерфейса. Так как в рамках рассматриваемого подхода ИАР фактически является ресурсом РВС, далее вместо ИАР часто будет употребляться термин "ресурс".
Далее рассматривается интеграция первичных ресурсов в РВС и вводится второе важное понятие - агент доступа. Агент доступа представляет собой программный компонент, непосредственно взаимодействующий с первичным ресурсом и интегрирующий его в распределенную вычислительную среду. Первичный ресурс, снабженный агентом доступа к нему, представляет собой ИАР, готовый к включению в РВС.
Затем рассматривается модель доступа к ИАР. Концепция ИАР позволяет определить на уровне прикладного инструментария высокоуровневую модель доступа к ресурсам РВС, удобную для решения в среде декомпозируемых вычислительных задач.
Далее рассматриваются вопросы типизации ресурсов РВС. Для объединения гетерогенных ресурсов в единую вычислительную среду необходима унификация их внешних интерфейсов на основе четко определенных типов ресурсов. Это принципиально важно для решения декомпозируемых вычислительных задач, поскольку каждая из подзадач исходной задачи фактически требует для своего решения наличия в среде ресурса {или ресурсов) четко заданного типа. Данная типизация ресурсов должна быть произведена на основе их детальной классификации по функциональности и предоставляемым возможностям. Конечным результатом этой работы должны стать спецификации внешних интерфейсов ИАР различных типов.
В заключение первого параграфа рассматриваются вопросы композиции ИАР-ов и поддержки прикладных сценариев. Модель типизированных ИАР-ов позволяет осуществлять композицию ресурсов РВС в новые, более сложные ресурсы. Применительно к рассматриваемому классу задач ресурс-агрегат может реализовывать алгоритм решения исходной задачи, а составные ресурсы - алгоритмы решения отдельных подзадач. Подобные сценарии координированного взаимодействия набора ИАР, реализующие алгоритм решения определенной задачи, были названы прикладными вычислительными сценариями.
Во втором параграфе описывается архитектура распределенной вычислительной среды на основе концепции ИАР. Рассматриваются основные уровни данной архитектуры:
Уровень агентов доступа, который включает программные средства, позволяющие интегрировать в распределенную вычислительную среду существующие ресурсы,
Уровень служб* содержащий программную инфраструктуру общего назначения, обеспечивающую функционирование распределенной вычислительной среды.
Уровень прикладного API, который содержит программные средства для разработки приложений, использующих ресурсы РВС для решения вычислительных задач,
В третьем параграфе формулируются требования к программной инфраструктуре РВС, соответствующей рассмотренной выше архитектуре.
В четвертом параграфе рассматривается архитектура системы lARnet, которая реализует программную инфраструктуру РВС для решения декомпозируемых вычислительных задач, удовлетворяющую описанным выше требованиям.
Уровню агентов доступа соответствуют агенты доступа и контейнеры ИАР. Агент доступа в lARnet представляет собой программный компонент, реализующий набор операций, через которые осуществляется доступ к функциональности первичного ресурса. Помимо специфической задачи унификации интерфейса первичного ресурса, агент доступа должен решать такие стандартные задачи, как контроль доступа к ресурсу, обеспечение одновременной работы с ресурсом нескольких пользователей, учет использования ресурса и т.д.
Агент доступа в lARnet не решает задачу организации удаленного доступа к ресурсу. Для обеспечения гибкости и расширяемости архитектуры данная задача изолирована в другом компоненте - контейнере ресурсов, который представляет собой среду, в которой развертываются и функционируют агенты доступа. Контейнер обеспечивает удаленный доступ к агентам посредством определенного коммуникационного механизма и технологии ППО. Описывается общая схема устройства контейнера ИАР и процедура развертывания агента доступа в контейнере.
Уровень прикладного API образует клиентская библиотека, которая использует для вызова ресурсов так называемые коннекторы. Клиентская библиотека lARnet представляет собой реализацию интерфейса прикладного программирования (API), который соответствует высокоуровневой модели доступа к ИАР.
Для поддержки различных технологий и протоколов ППО при доступе к ресурсам, в архитектуре lARnet на клиентской стороне был введен отдельный уровень коннекторов. Коннектор представляет собой программный компонент, скрывающий за стандартным интерфейсом детали реализации доступа к ресурсу посредством определенного коммуникационного механизма.
Для обеспечения общности и однородности архитектуры, службы lARnet реализованы в виде агентов доступа и развертываются в контейнерах ресурсов. Каждый из подобных агентов доступа должен реализовывать унифицированный интерфейс одной из служб lARnet. В рамках lARnet были разработаны следующие службы:
Информационная служба, осуществляющая сбор и хранение информации о ресурсах и службах РВС;
Служба рассылки сообщений, реализующая механизм группового взаимодействия ресурсов и уведомлений;
Служба управления сценариями, осуществляющая развертывание и запуск в РВС прикладных сценариев пользователей;
Служба журналов, позволяющая вести единый системный журнал распределенного приложения.
В третьей главе описывается программная реализация предложенного подхода к построению РВС в виде системы lARnet. Разработанная система исследуется на возможность повторного использования для решения широкого круга декомпозируемых вычислительных задач и на универсальность.
В первом параграфе рассматривается реализация уровня интеграции первичных ресурсов. Описываются базовые интерфейсы агента доступа, контейнера ИАР и коннектора, а также готовые реализации.
Во втором параграфе рассматривается механизм идентификации ресурсов РВС. Для идентификации ресурсов в IARnet введено два типа идентификаторов:
Идентификатор ресурса - уникальный идентификатор ресурса, который не изменяется при перемещении ресурса и изменении способа доступа к нему.
Ссылка на ресурс - идентификатор ресурса, который содержит информацию, необходимую для вызова ресурса, и не является постоянным.
Помимо описания указанных типов идентификаторов, приводится также описание механизма отображения идентификатора ресурса в ссылку на ресурс. В заключение, описывается идентификатор типа ресурса, который однозначно определяет некоторый набор операций (тип) и группу ресурсов.
В третьем параграфе описывается система типов данных IARnet и рассматривается описание интерфейсов (типов) ресурсов.
В четвертом параграфе показано, что задача поиска ресурсов в динамичной среде может быть в более общей форме описана как задача управления информацией о среде, которая имеет следующие измерения: представление, сбор,хранение и доступ к информации о среде. Информация о РВС включает в себя глобальную информацию и информацию об отдельных компонентах среды. Глобальная информация, такая как определения схем метаданных и классификаторы типов ресурсов, относится к среде в целом и не связана с каким-либо компонентом среды. Информация об отдельном компоненте среды может включать его описание (метаданные), а также информацию о состоянии компонента.
Для представления информации о РВС был выбран стандарт Resource Description Framework (RDF), который допускает эффективное хранение и передачу информации, а также - поиск в ней. Определяется базовый словарь терминов (RDF-схема), используемый для описания ресурсов, а также их типов. Рассматривается представление информации о состоянии ресурса и глобальной информации о среде. Для хранения информации о РВС, представленной в виде высказываний на RDF, могут быть применены существующие средства хранения RDF-данных. Задача доступа к информации о РВС может быть сведена к организации доступа к данным, хранящимся в RDF-репозитории. Рассматриваются существующие языки запросов, предназначенные для выборки информации из RDF-репозитория.
Описаны две модели сбора информации о РВС:
Пассивный сбор или регистрация, при которой информация помещается в репозиторий (публикуется) непосредственно поставщиками информации.
Активный сбор или опрос, при котором некий механизм производит опрос поставщиков информации, а затем помещает полученную от них информацию в репозиторий.
Рассмотрена целесообразность использования той или иной модели при сборе различной информации о РВС.
Описанный подход к управлению информацией о РВС реализован в IARnet при помощи создания специальной службы - информационной службы. Описана архитектура службы и ее унифицированный интерфейс. Также описаны стандартные операции, позволяющие опрашивать агента доступа на предмет определенной информации о ресурсе.
В пятом параграфе описывается реализация механизма группового взаимодействия ресурсов в системе IARnet. Под групповым взаимодействием мы будем понимать обмен информацией в виде сообщений внутри группы из нескольких ресурсов. Показано, что наиболее эффективный подход заключается в создании специального компонента, регистрирующего участников группы и рассылающего полученные от них сообщения всей группе. Указанный компонент назван службой рассылки сообщений. Рассматривается реализация данной службы, основанная на модели подписки.
В шестом параграфе рассматривается описание и выполнение в РВС прикладных сценариев. Прикладной сценарий можно определить как формальное представление распределенного вычислительного алгоритма решения некоторой задачи, включающее в себя
Описание элементарных типовых подзадач, из которых состоит решение исходной задачи;
Описание ресурсов, которые решают указанные подзадачи;
Описание зависимостей между подзадачами, а именно - потоков управления, которые определяют последовательность выполнения подзадач и синхронизацию между ними, и потоков данных, которые определяют передачу информации между подзадачами;
Описание событий, которые могут влиять на ход выполнения алгоритма, и правил их обработки.
Рассматриваются возможные подходы к описанию прикладных сценариев. Описывается архитектура службы управления сценариями, предназначенной для развертывания и реализации прикладных сценариев в РВС.
В седьмом параграфе описывается служба журналов, которая позволяет вести единый журнал для всех компонентов распределенного приложения или вьпислительного процесса. Данная возможность существенно облегчает контроль и отладку распределенного вычислительного алгоритма.
В восьмом параграфе описывается модель прикладного программирования IARnet. Описывается интерфейс представителя ресурса на клиентской стороне для языка Java. Приводится пример программы на языке Java, в которой осуществляется поиск ресурса заданного типа и его вызов.
В четвертой главе рассматривается применение разработанного подхода и системы IARnet для решения следующих декомпозируемых вычислительных задач: распределенное решение задачи оптимального управления; распределенное решение системы обыкновенных дифференциальных уравнений (ОДУ); распределенное имитационное моделирование экологической, экономической и социальной динамики.
В первом параграфе рассматривается линейная по управлениям задача оптимального управления со смешанными ограничениями, вида: J[x, и] = \ {g(x(t))} u(t)) dt -> min i^O = н(ґ), K(x(t))u(t) = L(x(t)), M(x(t))u(t)>N(x(t)), *(0 = *. 1 є ['0 > ^]> T ~ фиксировано, x(t): R -» R", g(x): R" -» R1*" K(x):R"^R'"',L(x):R"^RM,M(x):Rn^R'"x%N(x):R'l->R'"'1.
Процедура продолжения оптимальных траекторий модифицируется для использования её в распределенной среде. Исходная задача декомпозируется на следующие подзадачи: задачи математического программирования (МП) - для получения новых режимов в процессе продолжения оптимальной траектории; задача Коши для системы ОДУ - для получения траектории вдоль каждого режима; поиск корней нелинейных уравнений - для определения моментов переключения режимов.
Проводится анализ каждой из подзадач как с точки зрения возможных методов ее решения, так и с точки зрения ее вычислительной сложности. На основе данного анализа определяется набор типовых ресурсов, необходимых для реализации алгоритма в распределенной среде.
Большое число возникающих вспомогательных задач МП являются задачами линейного программирования (ЛП). Так, в случае, когда g,K,L,M,N _ матрицы с постоянными коэффициентами, все вспомогательные задачи являются задачами ЛП. При решении задач ЛП необходимо выяснять структуру оптимального решения: регулярность решения, количество активных устойчивых ограничений в случае вырождения в прямой или двойственной задаче. Для решения этих задач разработаны методы и алгоритмы доступны реализующие их программные средства. Данные средства могут быть развернуты в РВС в виде ИАР-ов.
Еще один класс возникающих задач МП - это задачи с билинейной целевой функцией и линейными ограничениями. Эти задачи возникают, когда происходит вырождение в интегранте целевой функции и возникает вспомогательная задача для определения нового режима. Для этих задач необходима разработка специальных методов решения и их программная реализация. Важно отметить, что при решении данных задач в качестве подзадач могут возникать задачи ЛП.
Процедура продолжения оптимальных траекторий позволяет решать задачу локального синтеза оптимальной траектории, но для этого необходимо устанавливать зависимость фазовых переменных от начальных условий. При этом удобно иметь зависимость решения задачи Коши от начальных условий в каком-либо символьном виде. Наиболее естественным подходом является метод разложения решения в ряд с последующим использованием операций символьного дифференцирования для вычисления производных, входящих в квазианалитическое решение. С вычислительной точки зрения, процесс символьного дифференцирования правых частей для широкого класса задач (полиномиальных или дробно-рациональных функций) может быть эффективно распараллелен. Требуемый ресурс представляет собой программный компонент, реализующий решение задачи Коши путем организации параллельных вычислений на суперкомпьютере или кластере с установленным ПО для символьного дифференцирования.
Для рассматриваемого класса задач квазианалитическое решение задачи Коши, полученное указанным методом, имеет вид многомерного многочлена. Таким образом, последующее вычисление значений полученного решения сводится к общей задаче о вычислении некоторого многомерного многочлена. Для этого может быть использована обобщенная на случай многомерного многочлена схема Горнера.
Проверка условий сохранения режима с вычислительной точки зрения представляет собой нахождение корней нелинейных уравнений. Существует множество методов и программных средств для их решения, которые могут быть развернуты в РВС в виде ИАР-ов. При выборе того или иного метода необходимо учитывать вид многочлена. Так как данные подзадачи требуют относительно небольших объемов вычислений, ресурсы, отвечающие за их решение, могут функционировать, например, на обычных рабочих станциях. При этом необходимо учитывать, что, так как число режимов (и условий) априори неизвестно, то в процессе вычислений может возникнуть необходимость в динамическом подключении к решению задачи новых ресурсов.
Таким образом, для рассматриваемой задачи можно выделить несколько групп типовых ресурсов, необходимых для распределенного поиска решения: ресурсы решения задач математического программирования (ЛП и специальных задач); ресурс решения задачи Коши указанным методом; ресурсы символьного дифференцирования; ресурсы решения нелинейных уравнений;
В заключение, приводится сценарий координированного использования указанных типов ресурсов для решения задачи оптимального управления в РВС.
Во втором параграфе рассматривается распределенный алгоритм решения системы ОДУ. В качестве примера ситуации, где естественным образом возникает необходимость решения системы ОДУ в распределенной среде, можно указать случай, когда компоненты правой части системы заданы не аналитически, а являются выходами некоторых сложных имитационных моделей или программно-аппаратных комплексов, которые затруднительно переместить из одного места в другое. Для решения системы ОДУ в РВС применен вычислительный алгоритм, который позволяет минимизировать накладные расходы, связанные с сетевым обменом данными между решателями. Описаны необходимые типы ресурсов и приведен сценарий координированного использования указанных ресурсов для решения системы ОДУ в среде на базе IARnet.
В третьем параграфе рассматривается распределенная имитационная модель экологической, экономической и социальной динамики, основанная на имитационной модели ЭСЭИМ, разработанной в ВЦ РАН. Модель воспроизводит эволюцию системы, состоящей из нескольких регионов (стран) на характерных временах, соизмеримых с жизнью поколения.
При создании распределенной имитационной модели, минимальные наборы компонентов модели ЭСЕИМ, которые могли быть размещены на одной рабочей станции, рассматривались как единый ИАР. В результате, были выделены три типа ресурсов: модель страны (региона), база демографических данных и модель внешнего мира. Кроме того, был предусмотрен еще один ресурс - информационный сервер. Это программный модуль, задачей которого является общее управление процессом моделирования на заданном интервале времени, а именно, задание начального и финального года модельного интервала; начало/завершение эксперимента; координация работы всех остальных ресурсов при совершении «шага» моделирования и, наконец, отображение результатов моделирования. Приводится сценарий координированного использования указанных ресурсов для проведения имитационного эксперимента в РВС.
В заключении формулируются основные выводы и результаты работы.
Современные технологии построения распределенных вычислительных сред
Взаимодействие между компонентами распределенной системы осуществляется путем передачи заявок на обслуживание (в виде вызовов удаленных объектов или процедур), через сеть, соединяющую узлы системы.
Данное взаимодействие может быть реализовано путем непосредственного использования возможностей современных сетевых операционных систем. Однако в общем случае такой подход является неэффективным с точки зрения удобства разработки и сопровождения. Существует большой концептуальный разрыв между низкоуровневыми функциями сетевых операционных систем (чтение и запись байтовых потоков) и высокоуровневыми потребностями разработчиков (вызов операций удаленных объектов). При непосредственном использовании сетевой операционной системы разработчику распределенной системы приходится самостоятельно ликвидировать этот разрыв, что повышает трудоемкость разработки и вероятность ошибок.
Для ликвидации упомянутого разрыва между сетевыми операционными системами и распределенными системами размещают слой промежуточного ПО (middleware, ППО) [30]. ППО позволяет разработчику подняться на более высокий уровень абстракции, который реализуется на основе низкоуровневых примитивов, предоставляемых сетевыми операционными системами. При этом ППО скрывает от разработчиков сложность работы с сетевой операционной системой.
Слой ППО реализует уровень сессии и уровень представления эталонной модели ISO/OSI, тем самым, избавляя разработчиков распределенных систем от работы непосредственно с реализацией транспортного уровня, например TCP или UDP. К основным задачам, решаемым ППО, относятся:
1. Преобразование сложных параметров (записи, символьные строки, массивы) в представление, необходимое для передачи их по сети (последовательности байтов).
2. Преобразование данных в случае, если компоненты-клиенты и компоненты-серверы используют разное представление данных в памяти.
3. Реализация ссылок на компоненты в терминах доменных имен, номеров портов и дополнительной адресной информации,
4. Обеспечение активизации компонентов-серверов, в том случае, если при поступлении заявки серверный процесс не запущен операционной системой,
5. Обеспечение типовой безопасности, то есть гарантии того, что запрашиваемая клиентом операция действительно реализована серверным компонентом, а фактические параметры, переданные клиентом, соответствуют описанию сервиса.
6. Обеспечение синхронизации при взаимодействии между компонентами-клиентами и компонентами-серверами.
7. Обеспечение требуемого качества обслуживания, например, атомарности реализации заявки, т.е. выполнение либо всей заявки, либо никакой из её частей.
Было предложено и реализовано много различных типов ППО, которые широко используются при разработке распределенных систем. Все существующие реализации ППО можно разделить на четыре основных категории:
Транзакционно-ориентированное ППО обеспечивает поддержку транзакций в системах распределенных баз данных, Данный тип ППО часто используется в распределенных архитектурах, где компонентами являются приложения баз данных. Примеры подобного ПО: IBM CICS, BE A Tuxedo и т.д.
ППО, ориентированное на отправку сообщений, (Message Oriented Middleware, MOM) организует взаимодействие между компонентами распределенной системы посредством обмена сообщениями. Клиентские компоненты используют эти системы для отправки серверу сообщения с заявкой на обслуживание, которое содержит параметры запрашиваемой операции. Результаты выполнения заявки возвращаются в другом сообщении, посылаемом сервером клиенту. Преимуществами данного типа ППО являются поддержка асинхронной доставки сообщений и групповой рассылки, которые обеспечивают развязку клиента и сервера и позволяют достичь лучшей масштабируемости. Примеры подобного ПО: IBM MQSeries, Microsoft MSMQ, BEA MessageQ, Oracle AQ, Sybase dbQ.
Объектно-ориентированное ППО организует взаимодействие между компонентами распределенной системы путем передачи вызовов между распределенными объектами. Данный тип ППО рассматривается в разделе 1.2,1.3.
Примеры подобного ПО и технологий: CORBA (см. раздел 1.2.1.4), Java RMI [73], Microsoft DCOM [49].
Сервисно-ориентированное НПО организует взаимодействие между компонентами распределенной системы путем вызовов так называемых сервисов. Данное ППО основано на сервисно-ориентированной архитектуре (Service Oriented Architecture, SOA). Можно говорить о том, что данный подход является развитием объектно ориентированного ППО и ППО, ориентированного на отправку сообщений, на более высоком уровне абстракции, позволяющим обеспечить взаимодействие слабо связанных компонентов. Примеры подобного ППО и технологий: Web-сервисы (см. раздел 1.2.1.5), Jini.
Объектно-ориентированное ППО ведёт свое начало от удаленных вызовов процедур (Remote Procedure Calls, RFC), которые были впервые реализованы в начале 1980-х гг. компанией Sun Microsystems как часть платформы Открытых сетевых вычислений (Open Network Computing, ONC). Удаленные вызовы процедур - это технология ППО, которая позволяет вызывать процедуры на удаленных машинах на различных аппаратных и программных платформах. Компания Sun включила удаленные вызовы процедур в свою ОС Sun OS, раннюю реализацию Unix, а также предложила их в качестве стандарта консорциуму Х/Ореп. В результате RPC стал частью стандарта Среды распределенных вычислений (DCE).
Серверные компоненты, выполняющие удаленные вызовы процедур, называются RPC-программами. Каждая RPC-программа имеет определение интерфейса, содержащее сигнатуры процедур, допускающих удаленный вызов. В стандарт DCE входит стандарт языка определения интерфейсов, предназначенный для описания экспортируемых операций независимо от языков программирования.
Реализация уровня представления RPC отображает структуру данных приложения в форму, допускающую передачу на транспортном уровне. При этом необходимо решать две принципиальные задачи; устранение неоднородности, то есть устранение различий в представлении данных между компонентами-клиентами и компонентами-серверами; преобразование сложных структур данных в блоки или потоки байтов для передачи транспортным уровнем, называемое маршалингом.
Уровень представления должен выполнять и обратное преобразование, то есть восстановление структур данных из последовательностей блоков или байтов, которое называется демаршалингом.
Набор параметров, подвергаемых маршалингу, определяется сигнатурами операций компонентов-серверов. Способ устранения неоднородности также зависит от запрашиваемой операции. Поэтому существуют два варианта реализации устранения неоднородности и маршалинга:
Статически во время компиляции, то есть компилировать процедуры маршалинга и устранения неоднородности и компоновать их с компонентами-клиентами и компонентами-серверами;
Динамически во время выполнения, интерпретируя сигнатуру операции, экспортированной компонентом-сервером.
Системы удаленных вызовов позволяют генерировать так называемые стабы (stubs), которые представляют собой статические реализации устранения неоднородности и маршалинга. Входными данными для процесса генерации служат определения интерфейсов, содержащие определения формальных параметров процедур, экспортируемых RPC-программой. В состав систем RPC в Unix входит компилятор языка определения интерфейсов rpcgen, который генерирует пары стабов: клиентский стаб и серверный стаб. Клиентский стаб устраняет неоднородность фактических параметров процедуры и выполняет их маршалинг. Кроме того, он выполняет демаршалинг результата и воспроизводит представление данных, используемое клиентом. Аналогично этому, серверный стаб выполняет демаршалинг фактических параметров процедуры и преобразует их к тому представлению, которое используется узлом и RPC-программой. Как только результат выполнения процедуры станет доступен, он возвращается серверному стабу, который устраняет неоднородность и осуществляет маршалинг результата в форму, пригодную для передачи.
Интеграция первичных ресурсов на основе агентов доступа
Уровень служб соответствует уровню служебных сервисов программной инфраструктуры РВС, который содержит общую программную инфраструктуру, обеспечивающую функционирование распределенной вычислительной среды.
Под службой РВС будем понимать программную систему, реализующую некоторый механизм, востребованный приложениями и другими компонентами среды. Службы могут быть разбиты на две группы: базовые, реализующие фундаментальные механизмы, и высокоуровневые, использующие базовые службы для реализации более сложных сервисов.
Основные компоненты служб развертываются на высокодоступных узлах сети, таких как выделенные серверы. Кроме того, отдельные компоненты служб, как правило, предназначенные для доступа к службе, размещаются рядом с другими элементами распределенной вычислительной среды.
Для обеспечения открытости архитектуры распределенной вычислительной среды, службы должны определяться путем спецификации их внешних интерфейсов. Это позволит разработчикам создавать различные реализации одной и той же службы, а пользователям - работать с этими реализациями прозрачным образом. Следовательно, на уровне служб возникает задача, аналогичная типизации информационно-алгоритмических ресурсов.
Как изображено на Рис.23, существующая программная Grid-инфраструктура уровня служебных сервисов может быть использована на уровне служб для реализации некоторых базовых механизмов, таких как, например, управление безопасностью. По мере развития Grid-технологий в данный уровень могут интегрироваться новые службы и реализации. Следовательно, на уровне служб возникает задача, аналогичная интеграции первичных ресурсов.
Указанные аналогии с типизацией и интеграцией ресурсов наводят на мысль об использовании аналогичных подходов к службам. То есть, интеграция существующих служб в РВС может проводиться на основе агентов доступа, а унификация интерфейсов служб - путем спецификации интерфейсов агентов доступа для различных служб.
Таким образом, службы распределенной вычислительной среды могут быть представлены в виде информационно-алгоритмических ресурсов, и для доступа к ним может использоваться модель доступа к ИАР. Данный подход повышает общность и однородность архитектуры РВС. В этом случае распределенная вычислительная среда состоит из элементов только одного типа - информационно-алгоритмических ресурсов, а уровень служб образован ИАР-ами специальных типов. При этом уровни интеграции ресурсов и служб фактически сливаются в один уровень.
В рамках разработанного подхода описаны следующие базовые службы: Информационная служба, осуществляющая сбор и хранение информации о ресурсах и службах РВС (см. раздел 3.4); Служба рассылки сообщений, реализующая механизм группового взаимодействия ресурсов и уведомлений (см. раздел 3.5); Служба журналов (см. раздел 3.7.1), позволяющая вести единый системный журнал распределенного приложения.
В рамках разработанного подхода описаны следующие высокоуровневые службы: Служба управления сценариями, осуществляющая развертывание в РВС и запуск прикладных сценариев пользователей (см. раздел 3.6).
Уровень прикладного API соответствует уровню прикладного инструментария программной инфраструктуры РВС, включающего программные средства для разработки приложений, использующих ресурсы распределенной вычислительной среды.
На данном уровне описывается стандартный интерфейс прикладного программирования (Application Programming Interface, API), предназначенный для вызова ресурсов и служб распределенной вычислительной среды в рамках высокоуровневой модели доступа к ИАР (см. раздел 2.1.2).
Данный API может быть определен на различных языках программирования и поддерживать различные реализации. В общем случае, реализация данного API представляет собой прикладную библиотеку, которую программист подключает к разрабатываемому приложению и использует для вызова ресурсов и служб РВС.
В данном разделе описываются требования к универсальной программной инфраструктуре распределенной вычислительной среды, соответствующей рассмотренной выше архитектуре.
Под требованием будем понимать некоторое качество, которым должна обладать разрабатываемая система для того, чтобы решать поставленную задачу [SWEBOK]. Требования к системе могут быть разделены на две группы: функциональные и нефункциональные. Функциональные требования описывают видимые пользователям возможности системы- Нефункциональные требования включают требования к удобству использования, требования к надежности, требования к производительности и т.п.
Организация удаленного доступа к ресурсу.
Как было отмечено в разделе 2.4 при описании архитектуры системы IARnet, агент доступа непосредственно не обеспечивает удаленный доступ к первичному ресурсу. Эту задачу решает отдельный компонент системы - контейнер ИАР. Это позволяет скрыть от разработчика агента доступа детали, связанные с обеспечением удаленных вызовов посредством определенной технологии ППО. Таким образом, от разработчика агента доступа не требуется знание данных технологий. Стандартный интерфейс контейнера, описанный ниже, позволяет разработчику произвести развертывание агента доступа в контейнере, передав ему ссылку на экземпляр агента. При этом реализация контейнера должна обеспечить развертывание в слое ППО представителя агента доступа, доступного удаленно, и вернуть разработчику ссылку на полученный ИАР.
Типичный сценарий использования контейнера разработчиком агента доступа выглядит следующим образом. Разработчик пишет простое приложение, в котором он создает экземпляр контейнера (Java-класса), производит запуск контейнера, инициализирует экземпляр своего агента доступа и развертывает его в контейнере. После чего приложение (и контейнер) продолжает работать до тех пор, пока требуется обеспечить удаленный доступ к ресурсу. При останове приложения производится останов контейнера.
Другой возможный сценарий состоит в запуске контейнера как отдельного приложения, которое функционирует постоянно, и развертывании агента доступа при помощи вызова данного приложения некоторым стандартным способом. В этом случае разработчик может в любой момент произвести развертывание (и удаление) своего агента доступа в уже работающем контейнере. Данный вариант более удобен для одновременной работы с контейнером сразу нескольких разработчиков, которые работают с разными агентами доступа.
Базовый интерфейс контейнера является обязательным для реализации каждым контейнером ИАР. Интерфейс контейнера ResourceContainer на языке Java содержит следующие операции. getProfile() : String Возвращает имя профиля ППО (см. раздел 3.1.2.3), поддерживаемого контейнером. start():void Производит запуск контейнера. stop () :void Производит останов контейнера. deploy(Resourcelmplementation resource):ResourceReference Производит развертывание агента доступа в контейнере. Агент доступа представлен в виде экземпляра класса, реализующего базовый интерфейс агента доступа (см. раздел 3.1.1).
Возвращает ссылку на ИАР (см. раздел 3.2.3) в случае, если развертывание прошло успешно, и null в противном случае. Полученная ссылка может в дальнейшем использоваться для публикации ресурса в информационной службе (см. раздел 3.4) и удаленного вызова ресурса. undeploy(ResourceReference reference):boolean
Производит удаление агента доступа из контейнера по ссылке на ИАР. Возвращает true в случае, если агент был найден и успешно удален из контейнера, и false в противном случае.
Полученная при развертывании агента доступа в контейнере ссылка на ресурс должна содержать всю информацию, необходимую для удаленного вызова ресурса на клиентской стороне. Очевидно, что вид данной информации будет зависеть от того, какую технологию ППО использует контейнер. Также очевидно, что и способ удаленного вызова ресурса будет определяться используемой контейнером технологией ППО. Поэтому для каждого коммуникационного механизма доступа к ресурсу, базирующегося на определенной технологии ППО, вводится так называемый профиль ППО, содержащий: стандартное представление указанной информации в ссылке на ресурс (см. раздел 3.2.3); стандартный интерфейс представителя агента доступа в слое ППО; правила передачи параметров вызова ресурса представителю агента доступа. Реализация контейнера ИАР должна поддерживать один из стандартных профилей ППО, то есть должна обеспечивать генерацию ссылки на ресурс в стандартном формате и развертывание представителя агента доступа со стандартным интерфейсом.
Для вызова ресурсов на клиентской стороне используются подключаемые программные компоненты - коннекторы. Каждый коннектор поддерживает удаленный вызов ресурса в соответствии с одним из стандартных профилей ППО. Внутри коннектора решается задача удаленного вызова представителя агента доступа посредством того или иного ППО, в соответствии с определенными в профиле интерфейсом представителя агента доступа и правилами передачи параметров вызова. Эти детали скрыты от пользователей и разработчиков приложений, от которых требуется только разместить на своем компьютере набор готовых коннекторов. При этом они смогут вызывать любой из ресурсов, для которого (точнее, для используемого при развертывании которого профиля ППО) имеется подходящий коннектор. Стандартный интерфейс коннектора описан в разделе 3.1.2.4.
Данный подход позволяет изолировать детали реализации, связанные с организацией удаленного доступа к ресурсу, внутри контейнеров и коннекторов, и скрыть эти детали от пользователей и разработчиков. Более того, это позволяет сделать остальные компоненты системы нейтральными по отношению к используемому ППО, поддерживать сразу несколько технологий ППО, легко добавлять поддержку новых технологий, а также осуществлять переход с одного ППО на другое.
В качестве примера, в разделе 3.1.2.5 приводится описание реализации удаленного доступа к ресурсу на базе технологий Web-сервисов.
Базовый интерфейс коннектора является обязательным для реализации каждым коннектором. Интерфейс коннектора ResourceConnector на языке Java содержит следующие операции. getProfile(): String Возвращает имя профиля ППО, поддерживаемого данным коннектором. createProxy(ResourceReference reference):ResourceProxy Создает по ссылке на ресурс экземпляр представителя ресурса на клиентской стороне (см. раздел 3.8.1), который может быть использован для вызова операций ресурса. getOperations(ResourceProxy proxy): Operation[] Возвращает список операций, поддерживаемых ресурсом. В качестве параметра указывается экземпляр представителя ресурса, для которого необходимо получить список поддерживаемых операций. connect(ResourceProxy proxy): Context Производит соединение (начало сеанса работы) с ресурсом. В качестве параметра указывается экземпляр представителя ресурса, с которым необходимо соединиться.
Нотация для описания интерфейсов ресурсов
Отображение идентификатора ресурса в ссылку на ресурс производится при помощи информационной службы, описанной в разделе 3.4. Информационная служба может быть развернута на нескольких узлах сети, в разных организациях. Как было отмечено выше, каждая из служб хранит соответствия между идентификаторами и ссылками для некоторого подмножества ресурсов, идентификаторы которых относятся к обслуживаемым данной службой пространствам имен (см. раздел 3.2.2).
Информационную службу, обслуживающую пространство имен, содержащееся в идентификаторе ресурса, будем называть базовой для данного ресурса. С учетом выше написанного, для того, чтобы получить ссылку на ресурс по его идентификатору, необходимо связаться с его базовой информационной службой. Так как служба IARnet сама является ИАР-ом, то, следовательно, необходимо получить ссылку на базовую информационную службу.
Рассмотрим проблему получения ссылки на базовую информационную службу по идентификатору ресурса. Возможно два подхода к решению данной проблемы.
Наиболее простой подход заключается во внедрении ссылки на базовую службу в идентификатор ресурса. Однако при этом нарушается описанная структура идентификатора ресурса. Более того, подобное смешение идентификатора и ссылки на ресурс противоречит сформулированным определениям, так как идентификатор ресурса больше не будет постоянным, а будет изменяться каждый раз при изменении ссылки на базовую службу. Возможный ввод ограничения на неизменность ссылок на информационные службы нарушает гибкость системы.
Второй, более грамотный подход состоит во внедрении идентификатора базовой службы в идентификатор ресурса. Этот подход не нарушает сформулированные определения идентификатора и ссылки, а также их структуру. Как было указано в описании формата идентификатора ресурса (см. раздел 3.2,2), для идентификации информационных служб используются обслуживаемые ими пространства имен. С учетом выше написанного, данный выбор нетрудно обосновать. Действительно, в этом случае идентификатор ресурса автоматически содержит в себе идентификатор соответствующей базовой информационной службы.
Однако при втором подходе возникает новая проблема - проблема получения ссылки на информационную службу по ее идентификатору. Для решения уже данной проблемы также можно использовать два подхода.
Первый подход заключается в реализации некоторого внутреннего механизма разрешения идентификаторов информационных служб в ссылки на них. Например, информационные службы могут хранить информацию о ссылках на другие информационные службы, и обслуживать запросы по разрешению идентификаторов в ссылки. При этом, очевидно, что информационные службы должны быть соответствующим образом организованы в единую структуру. В случае РВС небольшого размера, также можно использовать централизованную службу, хранящую ссылки на все информационные службы. Однако данное решение снижает отказоустойчивость и масштабируемость системы, а также автономность отдельных ее компонентов. Поэтому в общем случае речь идет о реализации полноценного внутреннего механизма разрешения имен, сопоставимого как по функциональности, так и по сложности с DNS. Этот механизм может использовать иерархическую организацию, как DNS, или же опираться на новые децентрализованные подходы, развитые в контексте пиринговых систем [26],
Второй подход состоит в использовании уже существующих внешних механизмов разрешения имен для разрешения идентификаторов информационных служб в ссылки на них. В первую очередь, речь идет об использовании существующей инфраструктуры DNS и Web. Подобный подход был применен в Open Grid Services Architecture (см. раздел 1.2.3.7) для получения ссылки (Grid Service Reference) на домашний сервис отображения, аналогом которого в нашем случае является базовая информационная служба, по ее дескриптору (Grid Service Handle). Дескриптор сервиса отображения имеет вид URL, отправив по которому запрос HTTP GET можно получить текущую ссылку на данный сервис отображения. В данном случае для обнаружения машины, на которой хранится ссылка, используется механизм DNS, а для запроса на получение ссылки — протокол HTTP.
При создании прототипа системы IARnet был выбран второй подход, как более простой в реализации. Ссылка на информационную службу размещается в текстовом виде на Web-сервере под URL, который является идентификатором данной службы. Таким образом, для того, чтобы получить ссылку на информационную службу по ее идентификатору, необходимо отправить запрос HTTP GET по данному идентификатору (URL).
Ссылка на информационную службу должна размещаться под соответствующим URL на Web-сервере и обновляться администратором данной службы. Используемый подход позволяет сохранить автономность отдельных информационных служб. Кроме того, он эффективно препятствует злонамеренной подмене ссылок и внедрению "ложных" служб, которые не обладают правами на обслуживание заявленных ими пространств имен и могут при отображении идентификаторов ресурсов в ссылки возвращать ссылки на подмененные ресурсы. Поскольку URL пространства имен и соответствующий Web-сервер находится в ведении организации, обслуживающей данное пространство имен, то она обладает полным контролем над тем, как происходит получение ссылки на данную информационную службу.
Подводя итог, приведем последовательность действий, образующих алгоритм получения ссылки на ресурс по его идентификатору: Определение идентификатора базовой информационной службы как пространства имен идентификатора искомого ресурса; Получение ссылки на базовую информационную службу по ее идентификатору путем отправки запроса HTTP GET по данному идентификатору (URL); Получение искомой ссылки на ресурс путем вызова операции базовой информационной службы, отображающей заданный идентификатор ресурса в ссылку.
Для того чтобы не повторять указанные действия каждый раз при начале работы с определенным ресурсом, можно хранить ссылку на ресурс, полученную при первом обращении к нему. Однако необходимо помнить, что ссылка на ресурс может со временем измениться, и тогда при попытке вызова ресурса по старой ссылке произойдет ошибка. В этом случае, необходимо вновь провести указанные шаги по получению новой ссылки на ресурс.
Помимо идентификаторов отдельных ресурсов в lARnet присутствует идентификатор типа ресурса (resource type identifier, IARTID), который однозначно определяет некоторый набор операций и группу ресурсов, реализующих данный набор операций или тип ресурса. При помощи информационной службы (см. раздел 3.4) по идентификатору типа ресурса можно получить описание операций, содержащихся в данном типе, а так же запросить список конкретных ресурсов, реализующих все операции этого типа.
В общем случае, один и тот же идентификатор типа ресурса может идентифицировать несколько различных ресурсов, а несколько различных идентификаторов типов ресурсов могут идентифицировать один и тот же ресурс.
Использование идентификатора типа ресурса в клиентских приложениях позволяет избежать зависимости приложения от конкретного ресурса в тех случаях, когда существует несколько ресурсов подобного типа.
