Физиология ГРИД Фостер

Я. Фостер, К. Кессельман, Д.М. Ник, С.
Тьюке “ФИЗИОЛОГИЯ ГРИД”
ФИЗИОЛОГИЯ ГРИД
Открытая архитектура грид-служб для интеграции распределённых систем
Ян Фостер Карл Кессельман Джефри М. Ник Стивен Тьюке
***
THE PHYSIOLOGY OF THE GRID
An Open Grid Services Architecture for Distributed Systems Integration
Ian Foster1,2 Carl Kesselman3 Jeffrey M. Nick4 Steven Tuecke1

1
Mathematical and Computer Science Division, Argonne National Laboratory, Argonne, IL
60439
2
Department of Computer Science, University of Chicago, Chicago, IL 60637
3
Information Science Institute, University of Southern California, Marina del Rey, CA 90292
4
IBM Corporation, Poughkeeeepsie, NY 12601
foster@mcs.anl.gov, carl@isi.edu, jnick@us.ibm.com, tuecke@mcs.anl.gov
Перевод с англ.: Корягин Д.А., ИПМ РАН

1
Я. Фостер, К. Кессельман, Д.М. Ник, С. Тьюке “ФИЗИОЛОГИЯ ГРИД”
Аннотация
При компьютеризации как бизнеса, так и научных исследований мы часто

сталкиваемся с необходимостью объединения служб пространственно распределённых,
гетерогенных, динамичных “виртуальных организаций”, базирующихся на отдельных
ресурсах, принадлежащих одной организации, и/или на внешних разделяемых ресурсах и
средствах провайдеров услуг. Такое объединение может оказаться технически очень
сложной задачей, поскольку необходимо обеспечивать разное качество обслуживания во
время прогона программ на несходных локальных платформах. Мы представляем для
обсуждения Открытую архитектуру грид-служб (OGSA), ориентированную на
разрешение подобного рода проблем. Эта архитектура базируется на концепциях и
технологиях, развитых в сферах Web-служб и грид, и устанавливает единообразное
представление семантики службы (а именно грид-службы); определяет стандартные
механизмы для создания, присваивания имён и обнаружения временных экземпляров
грид-служб; обеспечивает независимость от размещения и возможность доступа по
различным протоколам для экземпляров служб; поддерживает интеграцию с
возможностями ниже лежащих локальных платформ. Кроме того, OGSA определяет (в
терминах языка описания Web-служб – WSDL) интерфейсы и ассоциированные с ними
соглашения, а также механизмы, необходимые для создания и формирования сложных
распределённых систем, в том числе средства для управления временем жизни службы,
управлением изменениями и уведомлениями. Если это требуется, связывания служб могут
поддерживать надёжную активизацию, аутентификацию, авторизацию и делегирование.
Данная публикация дополняет предыдущую, фундаментальную статью, “Анатомия грид”,
и описывает, как грид-механизмы могут воплощаться в архитектуре, ориентированной на
службы, объясняет, как грид-функциональные возможности могут быть включены в
инфраструктуру Web-служб, а также иллюстрирует, как представляемая архитектура
может быть применена в бизнес-компьютинге в качестве базы для интеграции
распределенных систем – как в рамках единственного домена, принадлежащего
организации, так и в рамках объединения многих таких доменов.

2
Содержание
Аннотация .....................................................................................................................................2
Содержание ...................................................................................................................................3
1 Введение .....................................................................................................................................4
2 Потребность в технологиях грид...........................................................................................6
2.1 Эволюция систем корпоративного компьютинга ............................................................7
2.2 Провайдеры услуг и B2B-компьютинг..............................................................................9
3 Источники................................................................................................................................10
3.1 Инструментальный комплекс Globus ..............................................................................10
3.2 Web-службы .......................................................................................................................12
4 Открытая архитектура грид-служб ....................................................................................14
4.1 Ориентация и виртуализация служб................................................................................14
4.2 Семантика службы: грид-служба.....................................................................................17
4.2.1 Соглашения об обновляемости и транспортные протоколы ..............................17
4.2.2 Стандартные интерфейсы ......................................................................................18
4.3 Роль исполнительной среды.............................................................................................21
4.4 Использование механизмов OGSA для построения ВО структур................................22
5 Пример приложения ..............................................................................................................25
6 Технические подробности .....................................................................................................26
6.1 Модель службы OGSA......................................................................................................26
6.2 Создание временных служб: фабрики.............................................................................28
6.3 Управление временем жизни службы .............................................................................29
6.4 Управление дескрипторами и ссылками .........................................................................30
6.5 Обнаружение данных, ассоциированных со службой, и служб ...................................32
6.6 Уведомление ......................................................................................................................33
6.7 Управление изменениями .................................................................................................34
6.8 Другие интерфейсы ...........................................................................................................34
7 Связывания сетевых протоколов........................................................................................34
8 Высокоуровневые службы...................................................................................................35
9 Родственные работы ..............................................................................................................36
10 Заключение ............................................................................................................................38
Благодарности............................................................................................................................39
Библиография ............................................................................................................................39

3
1 Введение
До недавнего времени разработчики приложений часто могли рассчитывать на то,

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

и развёртыванию распределённых приложений. Сегодня приложения и промежуточное
программное обеспечение (middleware), как правило, разрабатываются для конкретной
платформы (например, такой, как Windows NT, разновидность Unix, некий мэйнфрейм,
J2EE, Microsoft.NET), которая обеспечивает исполнительную среду для выполнения
приложений. Возможности, обеспечиваемые этими платформами, могут варьироваться от
функций управления интегрированными ресурсами до интеграции баз данных, служб
создания кластеров, безопасности, управления рабочей нагрузкой и выявления отказов –
различающихся (от платформы к платформе) по способу реализации, исполнительной
семантике и API для этих функций. Однако, несмотря на это разнообразие,
продолжающаяся тенденция децентрализации и рассредоточения программного
обеспечения, аппаратуры и человеческих ресурсов особо остро ставит вопрос обеспечения
желаемого качества обслуживания (qualities of service – QoS) -независимо от того,
измерены ли они через показатели семантики общей безопасности, производительности
при распределенном потоке работ и управлении ресурсами, согласованного преодоления
сбоев, служб выявления отказов или другие метрики – на ресурсах, динамически
собираемых из потенциала корпоративных систем, систем провайдеров услуг и систем
заказчика. Нам необходимы новые абстракции и концепции, которые позволяют
приложениям получить доступ и разделять ресурсы и службы по всему пространству
территориально-распределённых сетей.
В течение определённого времени такие проблемы находились в центре внимания

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

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

4
также описали Инструментальный комплекс Globus (Globus Toolkit тм 1 [29]), реализацию

(с открытыми исходными кодами) ключевых грид-протоколов, который поддерживает
широкий спектр важных научных проектов с использованием вычислительной техники.
Для того, чтобы более точно выяснить, как могут быть реализованы и применены
грид-функции и грид-технологии, в настоящей работе мы расширяем круг рассмотрений в
трех направлениях. Во-первых, если ранее [34] мы строили наши обсуждения на основе
протоколов, необходимых для обеспечения интероперабельности между компонентами
ВО, то здесь мы фокусируем внимание на основных свойствах служб, реагирующих на
протокольные сообщения. Мы рассматриваем грид-инфраструктуру, как расширяемый
набор грид-служб, объединяемых разными способами для удовлетворения потребностей
ВО, которые сами могут быть частично определены с помощью служб, ими используемых
и разделяемых. Далее мы устанавливаем дисциплину, которой должны придерживаться
грид-службы для поддержки интеграции распределённых систем. Ставя ударение на
вопросах функциональных возможностей (то есть, “физиологии”), такой взгляд на грид
дополняет предыдущее протокольно-ориентированное (“анатомическое”) описание.
Во-вторых, мы объясняем, как можно грид-технологии совместить с технологиями

Web-служб [40, 47] для того, чтобы воспользоваться весьма привлекательными
возможностями Web-служб. Например, такими как описание и обнаружение службы;
автоматическая генерация программных частей на сторонах клиента и сервера на основе
описаний служб; связывание описаний служб с интероперабельными сетевыми
протоколами; совместимость с появляющимися высокоуровневыми открытыми
стандартами, службами и инструментариями; а также обширная коммерческая поддержка.
Мы называем такое совмещение и расширение грид-технологий и технологий Web-служб
Открытой архитектурой грид-служб (Open Grid Services Architecture – OGSA). При
этом термин архитектура указывает на вполне определённый набор основных
интерфейсов, с помощью которых можно конструировать системы с заданными
свойствами, а термин открытая, как это принято, использован для обозначения
расширяемости, нейтральности по отношению к производителям и обязательного
представления для общественного процесса стандартизации. Для обеспечения
самоописываемости, возможности обнаружения служб и интероперабельности
протоколов эта архитектура использует Язык описания Web-служб (Web Services
Description Language – WSDL), расширенный конструкциями для поддержки множества
согласованных интерфейсов и управления изменениями. OGSA учитывает опыт,
приобретённый практикой использования Инструментального комплекса Globus что
позволяет описывать соглашения и WSDL-интерфейсы для грид-службы, полную
информацию о текущем состоянии (потенциально временного) экземпляра службы,
предоставляющей возможность: надёжной и безопасной активизации процессов (когда это
требуется), управления временем жизни службы, рассылки уведомлений, управления
политикой, управления сертификатами и виртуализации. Кроме того, OGSA определяет
интерфейсы для обнаружения экземпляров грид-служб и для создания временных
экземпляров грид-служб. Результатом такого подхода является распределённая система
стандартизированных служб, (мы избегаем использования термина распределённая
система объектов из-за его смысловой перегруженности) которая поддерживает
разработку сложных распределённых служб, необходимых в современных компаниях и
объединениях компьютеризированных организаций.
В-третьих, мы фокусируем наши рассмотрения на коммерческих, а не на научных и
инженерных приложениях, как это было сделано в ранних публикациях [30, 34]. Мы
считаем, что одни и те же принципы и механизмы вполне применимы в обеих сферах. Тем

5
не менее, в условиях коммерческой среды для нас особенно необходима возможность

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

исследуем проблемы, стимулирующие использование грид-технологий в коммерческой
среде. Раздел 3 посвящён обзору Инструментального комплекса Globus и Web-служб, а в
Разделе 4 мы мотивируем и вводим нашу Открытую архитектуру грид-служб. В Разделах
5 – 8 мы представляем пример и рассматриваем реализации протоколов и службы более
высоких уровней. В Разделе 9 мы обсуждаем связанные с нашими интересами работы, а в
Разделе 10 подводим итог нашей дискуссии.
Мы подчёркиваем, что Открытая архитектура грид-служб и связанные с ней

спецификации грид-служб продолжают развиваться как в результате работ по
стандартизации в рамках Всемирного грид-форума (Global Grid Forum), так и работ по
реализации программного обеспечения в рамках проекта Globus и где-либо ещё. Таким
образом, техническое содержание данной статьи, так и её более раннего сокращённого
представления [32], являются всего лишь «мгновенным снимком» находящейся в
развитии работы.
2 Потребность в технологиях грид
Грид-технологии поддерживают разделение и согласованное использование

разнообразных ресурсов в динамичных ВО – то есть создание из географически и
организационно распределённых компонент таких виртуальных компьютерных систем,
которые скомпонованы так, что могут обеспечивать желаемое качество обслуживание
(QoS [34]).
Концепции и технологии грид сначала разрабатывались для обеспечения

возможности разделения ресурсов внутри распределенных по всему миру объединений
научно-исследовательских коллективов [18, 19, 28, 30, 46, 64]. При этом приложения
включали совместную визуализацию больших наборов научных данных (объединение
опыта), распределённый компьютинг для проведения вычислений, связанных с анализом
данных (объединение компьютерных мощностей и систем хранения), и комплексацию

6
научных измерительных устройств с удалёнными компьютерами и архивами (расширение

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

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

В прошлом, как правило, работы с применением компьютеров производилась в
пределах объединений базовых компьютерных центров корпораций. Между тем как
существовавшие в это же время сложные распределённые системы (например, такие как
системы автоматического управления и контроля, системы резервирования и доменная
система именования интернет – DNS [52]) оставались узко специализированными
разработками [9, 54].
Однако подъём интернет и появление электронных коммерческих приложений

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

имеет место также и внутри ИТ-инфраструктуры самого предприятия. Новые приложения
разрабатываются применительно таким моделям программирования (например,
компонентной модели Enterprise Java Beans [65]), которые изолируют приложение от
нижележащей компьютерной платформы и поддерживают возможность его мобильного
распространения на множестве платформ. В свою очередь, такая мобильность позволяет
выбирать платформы, с учётом требований цена/производительность и QoS, а не в
зависимости от типа операционной системы платформы. Так, например, приложения Web-
обслуживания и кэширования ориентированы на использование обыкновенных серверов,
а не традиционных больших компьютерных платформ (мэйнфреймов). Устойчивый рост
числа используемых в приложениях Unix и NT серверов неизбежно влечёт за собой
создание множества распределённых соединительных узлов, через которые можно

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

Увеличение нагрузки на эти активы заставляет компании переносить выполнение
несущественных функций (например, таких, как обработка запросов) с центральных
систем обработки транзакций на серверы среднего уровня. Между тем, использование
Web-технологии для доступа к корпоративным ресурсам беспрестанно требует
ускоренного обслуживания запросов, что, естественно, приводит к необходимости
распределения и выполнения кэширования на крайних компьютерах сети. Общим итогом
является декомпозиция высоко интегрированной внутренней ИТ-инфраструктуры в
совокупность гетерогенных и фрагментированных систем. После этого предприятия
должны в соответствии с требуемым QoS заново интегрировать такие распределённые
серверы и ресурсы данных, решая проблемы навигации, распределённой защиты и
распространения информационного наполнения как внутри корпорации, так и во внешних
сетях.
Параллельно с этими разработками корпорации всё более энергично вовлекаются в

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

качество обслуживания, традиционно связываемое с централизованной обработкой
данных на мэйнфреймах [56], теперь весьма существенно для эффективного ведения
электронного бизнеса на распределённых компьютерных ресурсах как внутри, так и вне
предприятия. Например, предприятия должны обеспечивать пользователям согласованное
с ними время ответа, несмотря на текущую рабочую нагрузку и значительные отклонения
между средним и пиковыми значениями нагрузки. Таким образом, необходимо гибкое
распределение ресурсов в соответствии с требованиями рабочей нагрузки и приоритетов.
Кроме того, предприятия должны обеспечивать: а) безопасность и надёжную среду для
выполнения распределённых транзакций, проходящих через множество разнородных
серверов; b) предоставление непрерывного, с точки зрения конечного пользователя,
доступа; c) восстановление после сбоев потока работ, протекавшего в распределённой
сети приложения и серверов данных. Однако принятая в настоящее время парадигма
обеспечения должного QoS для приложений путём вертикальной интеграции
специфических компонент платформы и служб оказывается неприемлемой для
современной распределённой среды обработки данных: декомпозиция монолитных ИТ-
инфраструктур не согласуется с предоставлением необходимого QoS через механизмы
вертикальной интеграции служб на данной платформе. При этом, будучи ограничены
средствами локальных систем, оказываются не эффективными возможности управления
распределёнными ресурсами, возникает недоступность к ресурсам платформы и
несогласованность между подобными ресурсами в распределённой среде.
Следствие всех этих тенденций проявляется в том, что интеграторы ИТ-систем

вынуждены заново интегрировать распределённые компьютерные ресурсы с учётом
должного качества обслуживания. Однако без соответствующей инструментальной
инфраструктуры управление рабочим потоком распределённого компьютинга становится

8
всё более и более напряжённым, сложным и уязвимым, поскольку персонал,

поддерживающий специфические для платформы возможности, должен отслеживать все
“огни”, затрагивающие полную доступность и производительность, а также устно
координировать с коллегами внесение корректив на различных платформах. Перед лицом
изменений, имеющих место в среде компьютинга и пакетах приложений, такой подход к
реинтеграции не обеспечивает возможности для масштабирования, достижения
эффективной стоимости ИТ-инфраструктуры и должной надёжности.
2.2 Провайдеры услуг и B2B-компьютинг

Ещё одна важная тенденция связана с появлением различных видов провайдеров
услуг (service providers – SPs), предоставляющих такие услуги как Web-хостинг,
распределение информационного наполнения, доступ к приложениям и системам
хранения данных. Благодаря масштабной экономии, достигаемой за счёт массовости
клиентуры, провайдеры услуг стремятся охватить стандартные процессы электронного
бизнеса, такие как создание Web-порталов, доступных для многочисленных
пользователей при превосходном показателе стоимость/производительность. Даже
традиционные предприятия, имеющие собственные ИТ-инфраструктуры, избавляются от
таких процессов, поскольку они рассматриваются как общепринятые функции.
Появление такого рода “электронных коммунальных служб” (“eUtilies” – это

термин, используемый провайдерами услуг, предлагающими постоянный доступ по
запросу), открывает возможность использования модели, предоставления ИТ-ресурсов по
подписке с повременной оплатой. В отличие от существовавших в прошлом компаний
компьютерных услуг, ориентированых на обеспечение процессов закрытой пакетной
обработки, электронные коммунальные службы предоставляют средства и возможности,
как правило, хорошо интегрируемые с инфраструктурами корпоративного компьютинга и
используемые для поддержки бизнес-процессов, протекающих как на внутренних, так и
внешних ресурсах. Следствием улучшения показателя стоимость/производительность,
обеспечиваемого структурами электронных коммунальных служб, является стремление к
дальнейшей декомпозиции и распределению функций корпоративного компьютинга.
Собственные технические проблемы встают и перед провайдерами электронных услуг.
Для того чтобы достигнуть экономии за счет массового обслуживания, провайдерам
необходимы серверные инфраструктуры, которые можно легко настраивать, учитывая
соответствующие требования пользователей. Поэтому нужна ИТ-инфраструктура,
которая: 1) поддерживает в соответствии с оговорённым уровнем обслуживания
динамическое распределение ресурсов, эффективное разделение и многократное,
использование ИТ-инфраструктуры и распределённую защиту в пределах от границы сети
до приложения и серверов данных, а также 2) обеспечивает согласованные времена
ответов и высокий уровень доступности, что в свою очередь обуславливает
необходимость проведения сквозного мониторинга производительности и
конфигурирования в реальном времени.
Другая ключевая тенденция развития ИТ-индустрии – это межкорпоративное

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

9
компьютинг является еще одним источником заказа на интеграцию распределённых

систем, часто характеризующихся большими различиями в информационных
технологиях, распространённых в разных организациях.
3 Источники
Мы рассмотрим две технологии, на основе которых определим Открытую

архитектуру грид-служб: во-первых, это Инструментальный комплекс Globus, который
широко распространен в качестве грид-технологии, используемой для научно-
инженерных вычислений, и, во-вторых, это хорошо известная инфраструктура Web-
служб, которые применяются для доступа к сетевым приложениям.
3.1 Инструментальный комплекс Globus

Инструментальный комплекс Globus (далее ИК Globus) [29, 34] представляет собой
систему, основанную на общепринятых стандартах, обладающую открытой архитектурой
и свободно распространяемую в исходных кодах. В его состав входят пакет служб и
программные библиотеки, которые поддерживают грид-системы и грид-приложения. Этот
инструментальный комплекс решает вопросы, связанные с обеспечением безопасности,
обнаружением информации, управлением ресурсами, управлением данными,
коммуникациями, выявлением отказов и переносимостью разработок. Механизмы ИК
Globus используются в сотнях узлов и десятках крупных грид-проектах по всему миру
Наиболее существенными для архитектуры OGSA компонентами ИК Globus

являются: грид-протокол Распределения и управления ресурсами (Grid Resource
Allocation and Management protocol -GRAM) и его служба, так называемый,
“привратник”– gatekeeper, обеспечивающая безопасное, надёжное создание служб и
управление [25]; служба мета каталогов (Meta Directory Service – MDS-2 [24]),
осуществляющая на основе программно выполняемой регистрации [59,69] обнаружение
информации и построение модели данных и ведение локального системного реестра
(“GRAM reporter” [25]); грид-инфраструктура безопасности (Grid Security Infrastructure
– GSI), которая поддерживает одноразовую регистрацию (single sign on), делегирование
полномочий и отображение сертификатов. Как показано на Рисунке 1, эти компоненты
обеспечивают жизненно важные элементы архитектуры, ориентированной на
предоставление услуг, однако с меньшей степенью универсальности, чем это достигнуто в
OGSA.

10
Рисунок 1: Избранные механизмы ИК Globus иллюстрируют первоначальное

создание прокси-сертификата и последующие аутентификационные запросы к
удалённой службе привратника. В результате запросов создается пользовательский
процесс #2, с которым ассоциируется делегированный прокси-сертификат
(возможно, ограниченный). Затем следует запрос к другой удаленной службе. Также
показана программно реализуемая служба регистрации через MDS-2.
Протокол GRAM обеспечивает надёжное, безопасное, удалённое создание и

управление произвольными вычислениями: того, что мы в данной статье называем
временными экземплярами служб. Механизмы GSI используются для аутентификации,
авторизации и делегирования полномочий [38] при удалённых расчётах. Для обеспечения
надёжной активизации применяется протокол двухфазного проведения транзакций,
основанный на методах, используемых в системе Condor [50]. Создание служб
осуществляет небольшой, выполняющийся с правами системы процесс “привратника”
(терминах данной статьи фабрики), в то время как GRAM reporter выполняет мониторинг
и публикует информацию о состоянии выполняемых локальных вычислений.
MDS-2 [24] обеспечивает единообразную схему для обнаружения и доступа к

системной компьютерной конфигурации, а также для получения информации о
компонентах аппаратно-программного оборудования. Например, о конфигурации
вычислительного сервера или состоянии сети, о размещении реплицируемых баз данных
(того, что мы в данной статье называем интерфейсом для обнаружения). Для управления
сроком действия предоставляемой информации MDS-2 использует грид-протокол
Уведомления (Grid Notification Protocol – GNP [44]).
Базирующийся на технологии открытых ключей грид-протокол Инфраструктуры

безопасности (Grid Security Infrastructure – GSI [33]) осуществляет аутентификацию
пользователя в условиях однократной регистрации, коммуникационную защиту и
начальную поддержку ограниченного делегирования полномочий. Вкратце, однократная
регистрация обеспечивает пользователю возможность только один раз пройти процедуру
аутентификации и, таким образом, создать прокси-сертификат, который может быть
предъявлен программой любой удалённой службе для аутентификации от имени
пользователя. Делегирование делает возможным создание и передачу удаленной службе
делегированного прокси-сертификата, который может быть использован этой службой для
выполнения действий от имени пользователя (возможно, с некоторыми ограничениями);

11
эта возможность оказывается важной при выполнении операций, имеющих вложенную

структуру. (Подобного рода механизмы могут быть реализованы в контексте
использования других технологий обеспечения безопасности, например, такой как в
системе Kerberos [63], хотя может быть и с другими характеристиками).
В качестве основы для идентификации пользователя GSI использует сертификаты

X.509, широко распространённого стандарта для сертификатов инфраструктуры открытых
ключей. Для того чтобы приспособить X.509 для поддержки однократной регистрации и
делегирования полномочий, GSI определяет X.509 прокси-сертификат[67]. (Этот прокси-
сертификат является аналогом пересылаемого тикета, используемого в системе Keberos,
но основывается исключительно на методах криптографии с открытыми ключами).
Обычно при выполнении аутентификации GSI использует протокол Безопасности
Транспортного Уровня (Transport Layer Security – TLS), являющийся модификацией
протокола Уровня Защиты Сокетов (Secure Socket Level – SSL), хотя и другие
протоколы аутентификации на основе технологии открытых ключей могут использоваться
для работы с X.509 прокси-сертификатами. Протокол удаленного делегирования X.509
прокси-сертификатами надстроен над уровнем TLS. Комитет по Инженерным проблемам
интернет (Internet Engineering Task Force – IETF) утвердил предварительный документ
(draft), определяющий расширения X.509 сертификата для прокси-сертификата [67].
Всемирный грид-форум (GGF) утвердил предварительные документы (drafts),
определяющие протокол делегирования для удаленного создания X.509 прокси-
сертификата [67] и расширения GSS-API (API обобщенной службы безопасности),
позволяющие использовать это API для грид-программирования. Развитая поддержка для
ограниченного делегирования была продемонстрирована в прототипах и является
существенной составляющей предлагаемого профиля X.509 прокси-сертификата.
Ограниченное делегирование позволяет одному объекту передать конкретное
подмножество пула своих привилегий другому объекту. Такое ограничение важно в плане
уменьшения вреда при преднамеренном или случайном злоупотреблении делегированным
сертификатом.
3.2 Web-службы
Термин Web-службы характеризует появившуюся парадигму распределённого
компьютинга, которая отличается от других подходов к этой проблеме, таких как DCE,
CORBA и Java RMI, тем, что в её фокусе лежит применение простых, базирующихся на
интернет стандартов (например, Расширяемого языка разметки - eXtensible Markup
Language – XML [14 ,27]) для решения вопросов, связанных с организацией гетерогенной
распределённой обработкой данных. Web-службы определяют способы описания
компонентов программного обеспечения, к которым должен быть предоставлен доступ,
методы доступа к этим компонентам и методы обнаружения, позволяющие опознавать
подходящих провайдеров служб. Важно, что Web-службы нейтральны по отношению к
языкам и моделям программирования, а также системному программному обеспечению.
Стандарты Web-служб устанавливаются в комитете W3C и других структурах и

создают базу для новых больших промышленных разработок таких, как Microsoft (.NET),
IBM (Dynamic e-Business) и Sun (Sun ONE). Для нас особенно важны три из этих
стандартов SOAP, WSDL и WS-Inspection.
• Простой Протокол Доступа к Объекту (Simple Object Access Protocol – SOAP

[4]) обеспечивает средства обмена сообщениями между провайдером службы и издателем

12
запроса. SOAP это простой оболочечный механизм отправлений, представленных на

XML, который определяет соглашение для удалённого вызова процедуры (RPC) и
соглашение о порядке передачи сообщений. SOAP независим от нижележащего
транспортного протокола; SOAP-отправления могут быть переданы средствами HTTP,
FTP, Службы сообщений Java (Java Messaging Services – JMS) и тому подобное. Мы
подчёркиваем, что Web-службы дают возможность описывать множество механизмов
доступа к нижележащим компонентам программного обеспечения. SOAP просто одно из
средств форматирования вызова Web-служб.
• Язык описания Web-служб (Web Services Description Language – WSDL [22])
представляет собой XML-документ для описания Web-служб в виде набора крайних
точек (endpoints) обработки сообщений, содержащих либо документы (то есть собственно
сообщения), либо удалённые вызовы процедур. Интерфейсы служб определяются
абстрактно в виде структур сообщений и наборов простых обменов сообщениями (или
операций, в терминологии WSDL), и затем привязываются к конкретному сетевому
протоколу и формату кодирования данных для определения крайней точки. Связанные
конкретные крайние точки объединяются в пучки, определяя абстрактные крайние точки
(службы). Язык WSDL расширяемый, что даёт возможность описывать крайние точки и
конкретные представления их сообщений для целого ряда различных форматов
сообщений и сетевых протоколов. Для использования WSDL вместе с SOAP 1.1, HTTP
GET/POST, и MIME установлено несколько стандартных соглашений о связывании.
• Инспекция Web-служб (WS-Inspection [15]) предусматривает простой XML-язык и
набор соглашений для обнаружения описаний служб, публикуемых провайдером службы.
Документ на Языке инспекции Web-служб (WS-Inspection Language – WSIL) может
содержать собрание описаний служб и ссылок на другие источники описаний служб.
Обычно описание службы представляет собой универсальный указатель (URL) на WSDL-
документ; иногда, описание службы может быть ссылкой на запись в Универсальном
реестре описания, обнаружения и интеграции (Universal Description, Discovery and
Integration (UDDI) registry [5]). Обыкновенно ссылка – это указатель URL на другой WS-
Inspection-документ; в некоторых случаях, ссылка может указывать на UDDI-объект.
Используя WS-Inspection, провайдер службы создаёт WSIL-документ и обеспечивает к
нему доступ по сети. Абоненты служб используют для получения WSIL-документа
стандартные Web-механизмы доступа (например, HTTP GET) и обнаруживают, какие
службы рекламируются провайдерами услуг. WSIL-документы могут быть также
представлены в разных индексных формах.
В настоящее время ведётся работа по созданию других стандартов в области Web-
служб. Например, Язык потоков Web-служб (Web Services Flow Language – WSFL [6]
решает проблему оркестровки Web-служб, то есть построения сложных Web-служб,
составляя их из более простых.
С точки зрения наших целей важны два достоинства инфраструктуры Web-служб.

Во-первых, нам необходимо поддерживать динамическое обнаружение и оркестровку
служб в гетерогенной среде, что неизбежно влечёт за собой необходимость создания
механизмов, регистрирующих и обнаруживающих определения интерфейсов и описания
реализаций крайних точек, а также динамически генерировать прокси, основанные на
(возможно множественных) связываниях с заданными интерфейсами. Язык WSDL
удовлетворяет этому требованию, поскольку обеспечивает стандартный механизмы для
задания описаний интерфейсов отдельно от их вхождения в конкретноe связываниe

13
(транспортный протокол и формат кодирования данных). Во-вторых, широкое

применение механизмов Web-служб означает, что среда, базирующаяся на Web-службах,
может использовать многочисленные инструментарии и существующие в настоящее
время службы. Например, такие, как WSDL-процессоры, генерирующие связывания для
различных языков, Среда активизации Web-служб (Web Services Invocation Framework –
WSIF [53]), системы управления заданиями, расположенные выше WSDL, и
исполнительные среды для Web-служб (например, Microsoft.NET и Apache Axis). Следует
подчёркнуть, что использование Web-служб вовсе не предполагает применение SOAP во
всех коммуникациях. Если это необходимо, то можно воспользоваться альтернативными
транспортными средствами, например, для достижения большей производительности или
для запуска поверх специализированных сетевых протоколов.
4 Открытая архитектура грид-служб
Мы убеждены, что во внутренних ИТ-инфраструктурах предприятий,

усовершенствованных однопроцессорных (single-processor – SP) инфраструктурах и
межведомственных грид конфигурациях, компьютинг всё чаще и больше оказывается
связан с созданием, управлением и применением динамичных объединений ресурсов и
служб (и людей), которые мы называем виртуальными организациями (ВО) [34]. В
зависимости от контекста их деятельности, эти объединения могут быть маленькими или
большими, краткосрочными или долговременными, внутри- или межкорпоративными,
гомогенными или гетерогенными. Отдельные объединения могут быть иерархическими
структурами, образованными из меньших систем и перекрываться по членству.
Мы считаем, что вне зависимости от этих различий, разработчики приложений для

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

практического разрешения. Мы расширим поле анализа, проведенного раннее [34],
включив него Открытую архитектуру грид-служб, которая поддерживает создание,
обслуживание и использование ансамблей служб, применяемых ВО.
Мы начнём обсуждение с нескольких общих замечаний, касающихся полезности

грид-архитектуры, ориентированной на службы, важности виртуализации грид-служб и
других весьма существенных характеристик служб. Затем мы рассмотрим специфические
постановки проблемы, которые будут стандартизированы в нашем определении того, что
мы называем грид-служба. Более детальное обсуждение этих вопросов проведено в
Разделе 6 (и в [66]).
4.1 Ориентация и виртуализация служб

При описании ВО мы можем сосредоточить внимание на разделяемых физических
ресурсах (как в [34]) или на службах, поддерживаемых этими ресурсами. (Служба – это
доступный по сети компонент, обеспечивающий некоторую функциональность. Конечно,
можно было бы использовать термин объект, но мы избегаем этого из-за смысловой
перегруженности данного термина.). При рассмотрении OGSA главный интерес для нас

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

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

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

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

в некой стандартной форме так, чтобы любая реализация службы активировалась бы
одним и тем же способом. Язык WSDL, который мы приняли для достижения этой цели,
даёт возможность такого определения интерфейса службы, которое отделено от
протокольных связываний, используемых для активизации (вызова) службы. На языке
WSDL для одного интерфейса можно задать несколько связываний, в том числе через
распределённые протоколы связи, (например, HTTP), а также локально
оптимизированные связывания (например, через локальную межпроцессорную связь -
IPC) для взаимодействия между процессами обработки запросов и обслуживания на
одном и том же хосте. К другим свойствам связываний можно отнести надёжность и иные
характеристики качества обслуживания, а также аутентификацию и делегирование
полномочий. Для издателя запроса выбор связывания всегда должен быть прозрачным
относительно семантик активизации служб, но не относительно других случаев:
например, издатель запроса должен иметь возможность выбора конкретного связывания,
исходя из соображений производительности.
Определение интерфейса службы и связывание доступа также отделены от

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

15
2. На платформе, обладающей специализированными средствами, для обеспечения

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

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

прозрачность в отношении местонахождения и активизации служб. Кроме того, она
обеспечивает множественные протокольные связывания для выполнения локальной
оптимизации вызовов служб, в том случае, когда служба и источник запросов находятся
на одной и той же платформе. Эта архитектура также поддерживает “переговоры”
протоколов, связанные с обеспечением сетевых потоков в границах организации,
предоставляя возможность выбора между несколькими interГрид протоколами, каждый из
которых оптимизирован для определённой цели. Наконец, отметим, что реализация
конкретного интерфейса Грид-службы может отображаться на нераспределённые
функции и возможности локальной платформы.

16
4.2 Семантика службы: грид-служба

Рассмотренная возможность виртуализации зависит не только от стандартных
интерфейсов – необходима также стандартизация семантик взаимодействия служб,
например, для того, чтобы различные службы поддерживали одни и те же соглашения,
касающиеся уведомления об ошибках. С этой целью, OGSA определяет грид-службы как
Web-службы, предоставляющие набор хорошо определённых интерфейсов и
подчиняющиеся определённым соглашениям. Интерфейсы разрешают вопросы,
связанные с динамическим созданием и обнаружением службы, управлением временем
жизни службы, уведомлением и управляемостью; соглашения также касаются именования
и обновляемости. Ожидается, что в процессе развития OGSA будут разрешены задачи,
связанные с авторизацией и управлением параллельным выполнением служб. Две другие
важные проблемы - аутентификация и надёжная активизация, рассматриваются как
связывания протоколов служб, и поэтому представляются внешними по отношению к
определению базовых грид-служб, но должны быть решены в полной реализации OGSA.
Такой раздельный подход к рассмотрению возможностей способствует достижению
большей общности архитектуры без кого-либо ущерба её функциональности.
Интерфейсы и соглашения, определяющие грид-службы, в частности, связаны с

дисциплинами управления временными экземплярами служб. Как правило, участники ВО
поддерживают не только фиксированный набор постоянных служб, который
обрабатывает поток сложных запросов, поступающих от клиентов. Нередко, в связи
запросами, возникающими в процессе работ, им приходится создавать временные
экземпляры новых служб, которые затем используются для управления и взаимодействий,
связанных с состоянием дел в конкретном рабочем контексте. После того как работы
завершены, такого рода служба (точнее, экземпляр) может быть ликвидирована.
Например, при использовании системы сопровождения видеоконференций, для
проведения сеанса может оказаться необходимым создание временных экземпляров
служб, исполняемых в промежуточных точках для управления сквозными потоками
данных в соответствии с требованиями качества обслуживания. Вместе с тем, в среде
Web-служб временные экземпляры могут создаваться динамически для обеспечения
постоянного времени ответа на запрос пользователя, управляя загрузкой приложений
через динамически добавленную возможность. Другими примерами временных
экземпляров служб могут быть очередь запросов к базе данных, операция извлечения
знаний, распределение полос пропускания в каналах сети, пересылка текущих данных и
предварительное резервирование средств обработки. (Эти примеры подчеркивают, что
временные экземпляры могут в значительной степени облегчить и упростить компоненты,
создаваемые для управления даже кратковременными потребностями). Фактор
временного существования оказывает значительное влияние на то, как организуется
управление службами, их именование, обнаружение и использование.
4.2.1 Соглашения об обновляемости и транспортные протоколы

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

17
Поэтому OGSA определяет соглашения, которые позволяют нам узнать, когда служба
изменяет и обладают ли эти изменения обратной совместимостью в отношении
интерфейса и семантики (но необязательно относительно сетевого протокола). OGSA
также определяет механизмы для обновления знаний клиента о службе, предоставляя
информацию о том, какие операции она поддерживает или какие сетевые протоколы
могут быть использованы для связи со службой. Описание службы показывает
протокольные связывания, которые могут быть использованы для связи со службой. Два
свойства часто желательны в таких связываниях:
• Надёжная активизация службы. Службы взаимодействуют друг с другом,
обмениваясь сообщениями. В распределённых системах склонных к отказам
компонентов, тем не менее, невозможно гарантировать, что сообщение будет
доставлено. Для обеспечения гарантии того, что служба получит сообщение лишь
однажды или вовсе не получит, важно иметь информацию о внутреннем состоянии
службы. На основе этих сведений можно построить широкий ряд семантик
высокоуровневых операций, таких как транзакции.
• Аутентификация. Механизмы аутентификации позволяют установить личности
(who is who) пользователей и служб, что необходимо для проведения политики.
Так, например, часто удобно применять транспортный протокол, который
обеспечивает взаимную аутентификацию клиента и экземпляра службы, а также
делегирование прокси-сертификата. На этом основании можно построить широкий
ряд высокоуровневых механизмов авторизации.
4.2.2 Стандартные интерфейсы

В Таблице 1, приведенной ниже, перечислены интерфейсы (в терминологии WSDL,
portTypes), которые определяют грид-службу. Более подробно они описаны в Разделе 6 (и
в [66]). Отметим, что хотя OGSA и устанавливает разнообразие дисциплин служб и
связанных с ними интерфейсов, все перечисленные, кроме одного из этих интерфейсов
(GridService), являются необязательными.

18
Таблица 1: Предлагаемые OGSA интерфейсы грид-служб (см. детали в тексте).

Имена указанные здесь, вероятно, будут в будущем изменены. Интерфейсы для
авторизации, управления политикой, управляемости и, вероятно, для других целей
остаётся определить.
PortType Операция Описание операции
(интерфейс)
GridService FindServiceData Запрос различной информации
(Грид-служба) (Найти данные, об экземпляре грид-службы,
ассоциированные со службой) включая базовые внутренние
сведения (должны быть указаны
дескриптор, ссылка, первичный
ключ, домашний handleMap –
эти термины объясняются
ниже), более обширная
информация, привязанная к
данному интерфейсу, и
информация, специфичная для
службы (например,
зарегистрированные экземпляры
службы). Расширяемая
поддержка для различных
языков запросов
SetTerminationTime Установка (и получение)
(Установка времени времени завершения экземпляра
завершения) грид-службы
Destroy Завершение экземпляра грид-
(Ликвидация) службы
NotificationSource SubsribeToNotificftionTopic Подписка на уведомления о
(Источник (Подписка на раздел связанных со службой
уведомления) уведомлений) событиях, c указанием типа
сообщения. Разрешается
доставка через сторонние
службы сообщений
NotificationSink DeliverNotification Выполнение асинхронной
(Приёмник (Доставка уведомлений) доставки уведомительных
уведомлений) сообщений.
Registry RegisterService Мягкая (soft-state) регистрация
(Реестр) (Регистрация службы) дескрипторов грид-службы
UnregisterService Удаление из реестра
(Удаление регистрационной дескриптора грид-службы
записи)
Factory CreateService Создание нового экземпляра
(Фабрика) (Создание службы) грид-службы
HandleMap FindByHandle Возвращение ссылки (GSR) , в
(Дескриптор) (Обнаружение с помощью настоящее время связанной с
дескриптора) данным дескриптором (GSH)
грид-службы

19
Обнаружение. Для того, чтобы приложения могли конфигурировать себя и свои

запросы к службам, им нужны механизмы для обнаружения доступных служб и
определения характеристик последних. Мы удовлетворяем это требование, определяя:
• Стандартное представление данных, ассоциированных со службой, то есть
информации об экземплярах грид-службы, которую мы структурируем в виде
набора поименованных и типизированных XML- элементов, называемых
элементами данных службы, заключенных в стандартный формат контейнера.
• Стандартную операцию FindServiceData (в составе обязательного интерфейса
GridService), применяемую для получения данных, ассоциированных с конкретным
экземпляром грид-служб (доступ в режиме “pull”; смотри ниже интерфейс
NotificationSource для доступа в режиме “push”);
• Стандартные интерфейсы для регистрации в реестре служб (Registry) информации
об экземплярах грид-служб и для отображения дескрипторов (“handles”) в ссылки
(references). (Интерфейс HandleMap будет объяснен в разд. 6, при обсуждении
именования)
Динамическое создание служб. Возможность динамически создавать и управлять
новыми экземплярами служб является базовой принципом OGSA-модели и влечёт за
собой существование служб создания служб. OGSA-модель определяет стандартный
интерфейс (Factory) и семантику, которую должна поддерживать любая служба создания
служб.
Управление временем жизни. Любая распределённая система должна быть

способной обрабатывать непредусмотренные отказы. В системе, которая содержит
временные, обладающие описанием состояния экземпляры служб, должны быть
предусмотрены механизмы для восстановления служб и связанных с ними состояний в
случае отказа операций. Например, завершение сессии видеоконференции может также
потребовать завершения служб, созданных в промежуточных точках для управления
потоком. Мы удовлетворяем этому требованию, определяя (в составе обязательного
интерфейса GridService) две стандартных операции: Destroy (Ликвидация) и
SetTerminationTime (Установка времени завершения), используемые, соответственно, для
явной ликвидации экземпляров службы и мягкого (soft state) управления сроком действия
временем жизни экземпляров Грид-служб. Мягкие (soft state) протоколы [59, 69] дают
возможность со временем сбрасывать удалённо установленное состояние, если только оно
не освежается потоком последовательных “keepalive”сообщений о сохранении. Такие
протоколы отличаются устойчивостью к сбоям: потеря одного сообщения не влечёт
непоправимого ущерба и просты: поскольку не нужно надёжного “сбрасывающего”
протокольного сообщения.
Уведомление. Для набора динамических, распределённых служб должна быть

предусмотрена возможность, позволяющая им асинхронно извещать друг друга об
изменениях своего состояния. OGSA определяет общие абстракции и интерфейсы
NotificationSource (Источник уведомлений) и NonificationSink (Приёмник уведомлений)
для подписки и доставки таких уведомлений, чтобы службы, конструируемые из более
простых служб, могли обрабатывать уведомления (например, об ошибках) стандартными
способами. Интерфейс NotificationSource интегрирован с данными службы, и поэтому
запрос уведомления выражается как запрос последующей доставки данных службы в
режиме «push». (Мы могли бы сослаться на возможности, обеспечиваемые этими

20
интерфейсами, как на службу событий [10], но мы избегаем употребления этого термина

из-за его смысловой перегруженности).
Другие интерфейсы. Мы предполагаем в ближайшем будущем определить

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

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

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

хостинг-среды процессы операционной системы, установленной на локальной платформе,
например, создание нового экземпляра службы влечёт создание нового процесса. В таких
средах служба сама может быть реализована на различных языках, таких как C, C++, Java
или Fortran. Грид-семантика может быть реализована непосредственно как часть службы
или через использование соответствующей библиотеки [39]. Обычно семантика службы
не поддерживается внешними программными средствами кроме тех, которые
обеспечиваются операционной системой. Поэтому, если это требуется, то, например,
функции управления временем жизни должны выполняться внутри самого приложения.
С другой стороны, Web-службы могут быть реализованы в более сложных хостинг-

средах, основанных на контейнерной или компонентной технологии, такой, как J2EE,
Websphere, .NET и Sun One. Такие среды определяет объектную структуру (контейнер),
внутри которой могут создаваться и объединяться для построения сложных приложений
компоненты, строго придерживающиеся определяемых средой стандартных интерфейсов.
По сравнению с низкоуровневой функциональностью, поддерживаемой локальными
хостинг-средами, контейнерная/компонентная хостинг-среда ориентирована на
предоставление более развитых средств, обеспечивающих программирование,
управление, гибкость и безопасность. Поэтому такого рода базовые среды весьма
привлекательны при создании служб электронной коммерции.
В контексте OGSA, контейнер (хостинг-среда), прежде всего, гарантирует, что

службы, которые он поддерживает, строго соответствуют семантикам Грид-служб, и
поэтому OGSA может мотивировать внесение изменений и дополнений к интерфейсу
контейнера или компонента.

21
Определяя семантики служб, OGSA устанавливает правила взаимодействия между

службами, независимые от любой хостинг-среды. Тем не менее, как отмечалось выше,
успешная реализация Грид-службы может быть облегчена заданием базовых
характеристик, которыми должны обладать все хостинг-среды для определения
“внутреннего” интерфейса реализации службы с глобальной Грид-средой. Эти
характеристики необходимо потом отразить в различных технологиях реализации
(например, J2EE или разделяемых библиотеках).
Вопросы детального обсуждения характеристик хостинг-среды выходят за рамки

этой статьи. Тем не менее, можно ожидать, что хостинг-среда должна преодолевать
проблемы, связанные: с отображением расширенных грид-имен (то есть, дескрипторов
грид-служб) в конкретные элементы реализации (в указатели C, в объектные ссылки Java
и т.п.); с диспетчеризацией грид-активизаций и событий уведомления, выражаемых при
реализации в конкретные действия (события, вызовы процедур); с выполнением
протоколов и форматированием данных для сетевых передач; - с управлением временем
жизни экземпляров грид-служб; с взаимной аутентификацией служб.
4.4 Использование механизмов OGSA для построения ВО структур

Приложения и пользователи должны иметь возможность создавать временные
службы, обнаруживать и определять свойства доступных служб. В архитектуре OGSA
интерфейсы Factory, Registry, GridService и HandleMap поддерживают создание
экземпляров временных служб, обнаружение и определение характеристик экземпляров,
связанных с деятельностью ВО. (Фактически служба реестра – это экземпляр службы,
который реализует интерфейс Registry для регистрации, а операция FindServiceData
интерфейса GridService, располагая необходимыми для обнаружения данными службы,
определяет набор служб, связанных с ВО.). Эти интерфейсы могут быть использованы для
конструирования разнообразных структур служб ВО, как показано на Рисунке 2 и
описывается далее.

22
Рисунок 2: Три разных структуры ВО, как это описано в тексте. Сверху вниз:
простая хостинг-среда, виртуальная хостинг-среда и коллектив служб.
Простая хостинг-среда. Простая исполнительная среда представляет собой набор

ресурсов, которые размещёны внутри одного административного домена, и поддерживает
локальные возможности необходимые для управления службами, например, сервер
приложений J2EE, система Microsoft .NET или Linux-кластер. В OGSA интерфейс
пользователя с такой средой, как правило, будет представлен структурой, включающей
системный реестр, одну или несколько фабрик и службу handleMap (отображения).
Каждая фабрика учитывается в системном реестре, что предоставляет клиентам
возможность обнаруживать доступные фабрики. Когда фабрика получает клиентский
запрос на создание экземпляра грид-службы, она активизирует определённые
возможности хостинг-среды для создания нового экземпляра, присваивает ему
дескриптор, регистрирует экземпляр в системном реестре и открывает для службы
handleMap доступ к дескриптору. Реализации этих различных услуг отображаются
непосредственно в локальные операции.
Виртуальная хостинг-среда. В более сложных средах ресурсы, связанные с ВО,

будут размещаться на гетерогенных, географически распределённых “хостинг-средах”.
(Например, на Рисунке 2, эти ресурсы принадлежат двум простым средам). Тем не менее,
эта “виртуальная хостинг-среда” (которая, возможно, соответствует набору ресурсов,
связанных с реализацией В2В партнерства) может быть открыта клиенту для доступа
через точно такие же интерфейсы, которые использовались для только что описанной
простой хостинг-среды. Можно создать одну или несколько “высокоуровневых фабрик”,
которые передают запросы создания экземпляров фабрикам более низкого уровня.
Аналогично можно создать высокоуровневый реестр, который содержит сведения о
высокоуровневых фабриках и о созданных ими экземплярах служб, а также о конкретных
ВО-политиках, которые управляют использованием ВО-служб. При этом клиенты смогут
использовать реестр ВО для обнаружения фабрик и других служб, связанных с ВО, и
потом применять дескрипторы, возвращаемые реестром, для непосредственного общения

23
с этими экземплярами служб. Высокоуровневые фабрики и системный реестр реализуют

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

может использоваться как глобальное уникальное имя набора служб, сопровождаемых
ВО. Ориентируя ВО по этому уникальному имени, можно установить и задействовать
политики управления ресурсами на хостинг-платформах служб ВО.
Среда для совместной деятельности. Можно также сконструировать

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

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

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

24
Рисунок 3: Пример работы грид-служб. Пояснение деталей в тексте.
5 Пример приложения
На Рисунке 3 изображены основные этапы цикла извлечения информации, который

используется для иллюстрации работы базовой удалённой службы активизации,
управления сроком действия и функций уведомления.
1. Первоначально среда охватывает (слева на право) четыре простые хостинг-среды,
из которых:
- одна выполняет приложение пользователя;
- одна включает вычислительные ресурсы и ресурсы хранения (и поддерживает две
службы фабрик, одна для создания служб резервирования ресурсов хранения, а
другая для создания служб извлечения информации);
- и две включают службы баз данных.
Буквой R помечены службы локального системного реестра; будем считать, что

25
дополнительная служба реестра ВО предоставляет информацию о размещении всех

изображённых служб.
2. Приложение пользователя выдаёт запросы “создать грид-службу” двум фабрикам,
находящимся во второй хостинг-среде, требуя создания такой “службы извлечения
информации”, которая от его имени будет выполнять операцию извлечения
информации и выделение временного хранилища для использования данным
приложением. Каждый запрос подразумевает взаимную аутентификацию
пользователя и соответствующей службы (с помощью механизма аутентификации,
описанного в дескрипторе службы-фабрики), после чего выполняется процедура
авторизация запроса. Если запрос является успешным, то в результате создаётся
экземпляр грид-службы с некоторым начальным временем жизни. Новый
экземпляр службы извлечения информации также снабжается делегированным
прокси-сертификатом, что позволяет ему выполнять последующие удалённые
операции от имени пользователя.
3. Вновь созданная служба извлечения информации использует прокси-сертификат
для того, чтобы инициировать выборку требуемых данных из двух служб баз
данных и размещает промежуточные результаты в локальном хранилище. Служба
извлечения данных также обращается к механизмам уведомления, чтобы
обеспечивать приложение пользователя периодическими обновлениями её статуса.
С другой стороны, приложение пользователя периодически генерирует запросы
“сохранения жизни” для двух экземпляров грид-служб, созданных им.
4. Приложение пользователя по некоторым причинам дало сбой. Выполнение
извлечения информации продолжается и в этой ситуации, но так, как нет другого
участника, заинтересованного в получаемых результатах, то дальнейшие
сообщения о “сохранении жизни“ не генерируется.
5. (Не показано на рисунке). Вследствие отказа приложения, сообщения о
“сохранении жизни” службы перестают поступать и оба экземпляра грид-службы в
конце концов исчерпывают время жизни и завершаются, освобождая хранилище и
вычислительные ресурсы, которые они потребляли.
6 Технические подробности
Теперь мы изложим более детальное описание абстракции грид-службы и

связанных с ней интерфейсов и соглашений.
6.1 Модель службы OGSA

Основная посылка концепции OGSA состоит в том, что каждая её компонента
представляется службой: то есть доступной по сети сущностью, которая обеспечивает
некоторую функциональность путём обмена сообщениями. Вычислительные ресурсы,
ресурсы запоминающих устройств, сети, программы, базы данных и прочее – это всё
службы. Принятие такой универсальной ориентированной на службы модели
подразумевает, что все компоненты среды виртуальны.
Более конкретно, OGSA представляет каждую компоненту как грид-службу: то

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

26
службами, облегчает конструирование служб более высоких уровней, которые можно

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

предлагают. Грид-служба реализует один или несколько интерфейсов, каждый из
которых определяет набор операций, активизируемых путём обмена определённой
последовательностью сообщений. Интерфейсы грид-службы соответствуют понятию
“portType” (тип порта) в WSDL. Поддерживаемый грид-службой набор portTypes, наряду с
некоторой дополнительной информацией, характеризующей версию, задаются в
serviceType (тип службы) грид-службы - элементе расширения WSDL, предусмотренным
OGSA.
Грид-службы могут обладать описанием внутреннего состояния в течение времени

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

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

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

способ, позволяющий отличать один динамически созданный экземпляр службы от
другого. Поэтому каждому экземпляру грид-службы присваивается глобальное
уникальное имя – “дескриптор”, Grid service handle (GSH), позволяющий отличать
данный экземпляр грид-службы от всех других экземпляров грид-служб, которые
существовали, существуют или будут существовать в будущем. (Если при выполнении
экземпляра грид-службы происходит сбой, и он перезапускается с сохранением того
состояния, что было до сбоя, тогда это, по существу, тот же самый экземпляр и можно
использовать тот же самый GSH).
В течение установленного срока действия грид-службы могут обновляться.

Например, с целью поддержки новых версий протоколов или в результате добавления
альтернативных протоколов. Поэтому GSH не несёт никакой конкретной информации о
протоколах или экземпляре, например такой, как сетевой адрес или поддерживаемые

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

конкретизирующей экземпляр информацией, которая необходима для организации
взаимодействия с данным экземпляром службы, целиком инкапсулируется в
единственной абстракции, называемой Grid service reference (GSR). В отличие от
дескриптора GSH, который инвариантен, GSR экземпляра грид-службы может изменяться
в течение времени жизни службы. Либо GSR имеет явно определенный срок, по
истечении которого он становится недействительным, либо он может стать
недействительным в любой момент существования службы. OGSA определяет
описываемые ниже механизмы преобразования, используемые для получения
обновленного GSR.
Использование GSR экземпляра, время жизни которого закончилось, приводит к

неопределённому результату. Заметим, что сохранение действительной GSR не
гарантирует доступ к экземпляру грид-службы: локальная политика или ограничения при
управлении доступом (например, максимальное число одновременно обслуживаемых
запросов) могут воспрепятствовать обслуживанию запроса. Кроме того, экземпляр грид-
службы, на который ссылается GSR, может дать сбой в работе, предотвращая
использование GSR.
Поскольку каждый компонент OGSA является грид-службой, то должны быть

грид-службы которые обрабатывают абстракции, определенные моделью OGSA: грид-
службу, дескриптор (GSH) и ссылку (GSR). Определение конкретного набора служб
можно было бы получить в результате конкретного отображения моделей служб OGSA.
Поэтому мы используем более гибкий подход и вводим для обработки абстракций модели
OGSA набор базовых OGSA-интерфейсов (то есть portTypes в терминах WSDL). Эти
интерфейсы могут затем объединяться различными способами для создания широкого
ряда грид-служб. В Таблице 1 представлены названия и описания для интерфейсов грид-
служб, определённых к настоящему времени. Отметим, что только GridService-
интерфейс должен поддерживаться всеми грид-службами.
6.2 Создание временных служб: фабрики

Архитектура OGSA определяет класс грид-служб, реализующих интерфейс,
который создаёт новые экземпляры грид-служб. Мы называем его Factory-интерфейсом, а
службу, которая применяет этот интерфейс фабрикой. Операция CreateService этого
интерфейса создаёт требуемую грид-службу и возвращает GSH-дескриптор и
первоначальную GSR-ссылку для нового экземпляра службы.
Factory-интерфейс не указывает, как создаётся экземпляр службы. Один обычный

сценарий состоит в том, что Factory-интерфейс должен быть реализован средствами
некоторой хостинг-среды (например, такой, как .NET или J2EE), обеспечивающей
стандартные механизмы для создания (и, следовательно, управления) новых экземпляров
служб. Хостинг-среда может определять, как службы реализуются (например, указывать
язык), но это прозрачно для издателей запросов в OGSA, которые видят только Factory-
интерфейс. Альтернативно можно конструировать "высокоуровневые" фабрики, которые
создают службы, делегируя запрос другим factory-службам (См. раздел 4.4). Например,
при включении нового компьютера в пул активного оборудования среды Web-
обслуживания можно обратиться к соответствующей службе-фабрике, чтобы она создала
службу “Web-обслуживания” на свободном компьютере.

28
6.3 Управление временем жизни службы

Введение временных экземпляров служб порождает проблему определения
времени жизни службы, то есть определения, когда службу можно или следует
ликвидировать так, чтобы соответствующие ресурсы могли бы быть освобождены. В
обычных условиях работы временный экземпляр службы создаётся, чтобы выполнять
конкретную задачу, ликвидируется либо после завершения этой задачи, либо на
основании явного запроса от клиента или от другой службы, спроектированной клиентом.
Однако компоненты распределённой системы могут давать отказы, и в результате
некоторые сообщения окажутся потерянными. Одним из последствий этого события
может быть то, что служба так никогда и не сможет увидеть ожидаемого запроса о явном
завершении, а это приводит к неопределённости в потреблении ресурсов.
Архитектура OGSA разрешает эту проблему с помощью мягкого (“soft-state”)

подхода [23,69], при этом важно, что экземпляры грид-служб создаются указанием
определенного времени жизни. Первоначальное время жизни службы может быть
увеличено на определённый период времени явным запросом от клиента или от другой
грид-службы действующей от имени клиента (это, конечно, связано с политикой службы).
Если этот период времени истекает без получения нового подтверждения интереса от
клиента, то либо хостинг-среда, либо сам экземпляр службы могут ликвидировать
экземпляр службы и освободить любые связанные с ней ресурсы.
Наш подход к управлению сроком действия службы имеет два привлекательных
свойства:
• Клиент знает или может выяснить, когда экземпляр грид-службы будет
ликвидирован. Это знание позволяет клиенту достоверно установить, что
экземпляр службы ликвидирован, и поэтому его ресурсы будут освобождены, даже
в случае возникновения системного сбоя (например, из-за отказов серверов, сетей
или ошибок клиентов). Клиент точно знает, каким временем он располагает для
того, чтобы запросить информацию о конечном состоянии экземпляра службы или
запросить продление времени жизни. Более того, он также знает, что если
происходит системный сбой, то не надо пытаться устанавливать со службой
контакт после истечения известного ему времени жизни, и что любые ресурсы,
связанные с данной службой, будут освобождены после этого срока – если только
другой клиент не преуспеет в продлении времени жизни этого экземпляра службы.
Короче говоря, управление временем жизни службы позволяет удобно
ликвидировать службу и выявить отказ, путём чёткого определения семантики
времени жизни для экземпляра службы.
• Хостинг-среде гарантировано, что потребление ресурсов ограничено, даже при
возникновении отказов вне управления средой. Если срок действия службы истёк,
то хостинг-среда может вернуть для использования все связанные с этой службой
ресурсы.
Мы реализуем средства программного управления временем жизни службы,
используя операцию SetTerminationTime в рамках обязательного интерфейса GridService,
которая определяет операции для проведения переговоров об установке первоначального
времени жизни для нового экземпляра службы, для продления времени жизни и для
ликвидации экземпляра службы, когда время его жизни истекло. Мы опишем каждый из
этих механизмов по очереди.

29
Переговоры о начальном сроке действия. Когда запрос о создании нового

экземпляра грид-службы проходит через фабрику, клиент указывает минимальный и
максимальный приемлемые начальные времена жизни службы. Фабрика выбирает
начальное время жизни службы и возвращает его клиенту.
Запрос продления времени жизни службы. Клиент требует увеличить время жизни,
посылая с помощью операции SetTerminationTime экземпляру Грид-службы сообщение, в
котором указывается минимальный и максимальный приемлемые новые времена жизни
службы. Экземпляр службы выбирает новое время жизни и возвращает его клиенту.
Заметим, что посылка сообщения о продлении времени жизни службы является
устойчивым механизмом: результат обработки последовательности запросов будет один и
тот же, даже если промежуточные запросы утеряны или переупорядочены, до тех пор,
пока не будет потеряно так много запросов, что время жизни истечет.
Периодичность сообщений о продлении времени жизни может быть определена

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

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

целью, в элементах информации грид-служб, и в сертификатах безопасности -
предполагает наличие хорошо синхронизированных глобальных часов. Протокол
Сетевого Времени (Network Time Protocol–NTP) обеспечивает стандартизированные
механизмы для синхронизации часов и, как правило, может синхронизировать часы самое
большее в пределах десяти миллисекунд, которых более чем достаточно для целей
управления временем жизни службы. Заметим, что здесь не идёт речь об операторах,
устанавливающих порядок событий, хотя мы рассчитываем ввести некоторые такие
механизмы в будущие версии.
6.4 Управление дескрипторами и ссылками

Как обсуждалось выше, результатом factory-запроса являются GSH и GSR. Хотя
гарантируется, что GSH всегда относится к созданному экземпляру грид-службы (точнее,
не всегда, но пока служба существует), срок действия GSR ограничен; более того, GSR
может измениться за время существования службы. Хотя, с точки зрения провайдера
грид-службы, такая стратегия привлекательна большей гибкостью, она порождает
проблему получения валидного GSR (т.е. действительно указывающего на существующий
экземпляр службы), когда у GSR, возвращённого операцией создания службы, истекает
срок действия. По её сути это проблема раскрутки: как установить связь с грид-службой,
определённой только её GSH? Рассмотрим, как эти проблемы решаются согласно

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

преобразователя дескриптора в ссылку (HandleMap). Операции, обеспечиваемые этим
интерфейсом, берут GSH и возвращают достоверный GSR. Операции преобразования
(отображения) могут иметь управляемый доступ, и поэтому запрос отображения может
быть отклонён. Для реализации интерфейса HandleMap может оказаться желательным
вести учёт фактически существующих экземпляров грид-служб и не возвращать ссылки
экземпляры, о которых известно, что они ликвидированы. Тем не менее, владение
достоверным GSR ещё не гарантирует, что с экземпляром грид-службы может быть
установлен контакт: служба может дать отказ или завершиться между моментом времени
выдачи GSR и временем, когда им воспользовались. (Очевидно, что если ликвидация
службы планируется, то желательно, но не обязательно, указать это в сроке действия
GSR).
Вводя интерфейс HandleMap, мы разделяем общую проблему получения GSR для

произвольной службы на две конкретные подзадачи:
1) Идентификация службы преобразования (handleMap), которая содержит процедуру

отображения конкретного GSH и
2) Обращение к этой службе для получения желаемого GSR.
Мы решаем эти две подзадачи по очереди. Для того чтобы всегда можно было
отобразить GSH в GSR, необходимо, чтобы каждый экземпляр грид-службы был
зарегистрирован, по меньшей мере, в одной службе handleMap, которую мы называем
домашней службой handleMap. Структурируя GSH так, чтобы он содержал идентификатор
домашней службы handleMap, можно легко и масштабируемо определять, к какой службе
handleMap нужно обратиться, чтобы для данного GSH получить GSR. Поскольку
уникальные имена могут быть задаваться локально, то исключаются проблемы
масштабируемости, связанные с централизованными службами распределением имён –
полагаясь в этом на доменную систему имён (Domain Name System [52]). Следует
отметитъ, что для отображения данного GSH могут существовать и другие службы
handleMap. Тем не менее, каждый GSH должен иметь только одну домашнюю службу
handleMap.
Как мы идентифицируем домашнюю службу handleMap внутри GSH? Любая

служба, которая реализует интерфейс HandleMap, является грид-службой и, как таковая,
будет иметь GSH. Если же мы воспользуемся этим именем (GSH домашней службы
handleMap) при конструировании GSH, то вернемся в ту же самую позицию, пытаясь
получить GSR из GSH службы handleMap. Чтобы разрешить эту проблему раскрутки,
необходимо иметь возможность получения GSR по данному handleMap, не запрашивая
handleMap! Достичь этого можно, требуя, чтобы все домашние службы handleMap
идентифицировались с помощью URL, и использовать операцию раскрутки, которая
связана только с одним хорошо известным протоколом, а именно, HTTP (или HTTPS).
Поэтому вместо того, чтобы использовать GSR для описания протоколов, которые следует
применять для связи со службой handleMap, обращаемся посредством операции HTTP
GET по URL, который указывает на домашнюю службу handleMap, и получим
соответствуюший ему GSR, записанный на языке WSDL.

31
Заметим, что существует взаимосвязь между службами, которые реализуют

интерфейсы HandleMap и Factory. Более конкретно, GSH возвращается в ответ на запрос к
фабрике, который должен содержать URL домашней службе handleMap, и отображение
GSH/GSR должно быть зарегистрировано и обновляемо в этой службе handleMap.
Реализация фабрики должна решить, какую службу использовать в качестве домашней
службы handleMap. Лишь одна служба может реализовывать оба интерфейса Factory и
HandleMap.
В настоящее время в работах Всемирного грид-форума рассматривается вопрос о

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

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

стандартную операцию FindServiceData, используемую для запроса и получения данных
службы. Эта операция использует простой язык запросов “по имени” и расширяема,
позволяя указать используемый язык запросов, которым может быть, например, Xquery
[20].
Описание грид-службы устанавливает для каждого интерфейса грид-службы набор
(может быть не пустой), содержащий элементы данных службы, которые должен
поддерживаться любым экземпляром грид-службы, реализующей этот интерфейс.
Связанные с интерфейсом GridService, а потому обязательные для любого экземпляра
грид-служб, наборы элементов содержат базовую информацию об экземпляре грид-
службы, например, такую как её GSH, GSR, первичный ключ и домашнюю службу
handleMap.
Операция FindServiceData интерфейса GridService используется для обнаружения

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

(registry). Реестр определяется двумя компонентами: интерфейсом Registry,
обеспечивающим операции, с помощью которых можно регистрировать дескрипторы
GSH, и соответствующим элементом данных службы, используемым для хранения
информации о зарегистрированных GSH. Таким образом, интерфейс Registry используется
для регистрации GSH, а операция FindServiceData интерфейса GridService – для поиска
информации о зарегистрированных дескрипторах GSH.

32
Интерфейс Registry позволяет с помощью службы реестра регистрировать

дескриптор GSH, дополняя его набором дескрипторов GSH, которые считаются
специальным подмножеством. Так, в MDS-2 [24] некая служба (или ВО) могут
использовать эту операцию для того, чтобы уведомить заинтересованные группы ВО
своём существовании и функции(ях), которые она обеспечивает. Обычно, эти
заинтересованные группы собирают разновидности служб обнаружения, которые
накапливают и структурируют информацию о службе, для ускорения обработки запросов
на обнаружения служб. Как и другие интерфейсы OGSA, снабжённые полным описанием
состояния, регистрация дескрипторов GSH является операцией с программно
поддерживаемым описанием состояния, и должна периодически обновляться, обеспечивая
тем самым большую динамичность служб обнаружения.
Заметим, что описание атрибутов, ассоциированных с дескриптором GSH, не

связано с регистрацией GSH для службы, применяющий интерфейс GridService. Это
свойство важно, поскольку значения атрибутов могут быть динамическими, и способы
получения значений атрибутов разнообразны, включая консультации с другой службой,
использующей интерфейс GridService
6.6 Уведомление
Схема уведомлений OGSA даёт возможность клиентам регистрировать их
заинтересованность в конкретных уведомительных сообщениях (интерфейс
NotificationSource) и поддерживает асинхронную одностороннюю доставку таких
уведомлений (интерфейс NotificationSink). Если конкретная служба хочет поддерживать
подписку на уведомительные сообщения, то она должна реализовывать интерфейс
NotificationSource, чтобы управлять подписками. Служба, которая хочет получать
уведомительные сообщения, должна реализовывать интерфейс NotificationSink, который
используется для доставки уведомительных сообщений. Чтобы начать доставку
уведомлений от конкретной службы, нужно вызвать операцию подписки из интерфейса
службы-источника уведомления, указав ей дескриптор GSH службы-приёмника
уведомления. После этого поток уведомительных сообщений передаётся от источника к
приёмнику, при этом приёмник периодически посылает сообщения о продлении времени
жизни службы-источника, уведомляя его, что приемник ещё заинтересован в получении
уведомлений. Если желательна надёжная доставка, то это может быть реализовано путём
определения соответствующего связывания протоколов для данной службы.
Важным аспектом такой модели уведомления является тесная интеграция данными

службы: операция подписки является просто требованием для последующей доставки (в
режиме “push”) данных службы при выполнении определенных условий. (Напомним, что
операция FindServiceData обеспечивает получение информации в режиме “pull”).
Такая схема допускает как прямую, от службы к службе, доставку уведомительного

сообщения, так и интеграцию с разработанными сторонними организациями службами
сообщений, широко используемыми в коммерческой среде, или специализироваными
службами, которые фильтруют, преобразовывают или особым образом поставляют
уведомительные сообщения от имени источника уведомления. Семантика уведомления –
это свойство связывания протоколов, используемых для доставки сообщения. Например,
SOAP/HTTP протокол или прямое UDP-связывание могли бы эффективно обеспечивать
двухточечную (point-to-point) передачу уведомления, хотя другие связывания (например,
некоторая частная служба сообщений) могли бы обеспечить передачу ещё лучше.

33
Связывание широковещательных протоколов могло бы поддерживать множество

получателей.
6.7 Управление изменениями

Для того чтобы поддерживать обнаружение и управление изменениями грид-служб,
интерфейсы грид-служб должны быть глобально и уникально поименованы. В терминах
WSDL интерфейс определяется как portType, и глобально и уникально именуется
квалифицированным именем qname, например, XML-пространством имен, заданным в
атрибуте targetNamespace элемента definitions WSDL-документа, и локальным именем,
заданным в атрибуте name элемента portType. Любые изменения определения грид-
службы, связанные либо c изменением её интерфейса, либо с изменением семантики
реализуемых операций, должны быть отражены через новые имена интерфейсов (то есть
новых элементов portType и/или serviceType). Такое свойство позволяет клиентам,
которые запрашивают грид-службы с конкретными свойствами (то есть с конкретными
интерфейсами или семантиками реализации) обнаруживать совместимые службы
6.8 Другие интерфейсы

Мы рассчитываем определить в будущем необязательный интерфейс
Управляемости (Manageability), который поддерживает набор операций управляемости.
Такие операции позволят осуществлять мониторинг потенциально больших наборов
экземпляров грид-служб и управление ими с пультов администраторов, использовать
инструментарий автоматизации и тому подобное. Необязательный интерфейс Concurrency
будет обеспечивать операции управления параллельным выполнением.
7 Связывания сетевых протоколов
Инфраструктура Web-служб может использовать различные связывания

протоколов. Например, для обеспечения безопасности может применяться связывание
SOAP+HTTP с TLS, но могут быть определены и уже используются и другие связывания.
Здесь мы обсуждаем некоторые вопросы, возникающие в контексте OGSA.
При выборе связываний сетевых протоков в рамках контекста OGSA мы должны

обеспечить выполнение следующих четырёх основных требований:
• Надёжная передача. Как обсуждалось выше, абстракция грид-служб может
потребовать надёжной активизации службы. Один из способов удовлетворения
этого требования состоит в том ввести в связывание сетевых протоколов
соответствующую поддержку, например, как в протоколе HTTP-R.
• Аутентификация и делегирование. Как отмечалось выше, абстракция грид-служб
может потребовать поддержки связи прокси-сертификата с удалёнными сайтами.
Один из способов разрешения этого требования состоит в том, чтобы осуществлять
соответствующую поддержку внутри связывания сетевых протоколов, например,
как это сделано в TLS, расширенным поддержкой прокси-сертификата.
• Повсеместность. Цель грид - предоставить возможность динамичного
формирования ВО из распределённых ресурсов, означает, что, в принципе, должно
быть обеспечено взаимодействие для любой произвольной пары служб.

34
• Формат GSR. Напомним, что Grid Service Reference может иметь формат,
специфический для связывания. Одним из возможных форматов GSR является
WSDL документ целиком; другим форматом является.CORBA IOR.
Определение небольшого числа стандартных связываний протоколов,
обеспечивающих обнаружение грид-служб и их активизацию будет способствовать
успешному распространению крупномасштабных интероперабельных OGSA-реализаций.
Точно так же, как повсеместное распространение Интернет-протоколов делает
возможным устанавливать, по существу, связь для двух любых объектов, повсеместное
распространение подобных интерГрид-протоколов позволит устанавливать связь двум
любым службам. Поэтому для клиентов всё будет весьма просто, поскольку им
необходимо знать только один набор протоколов. (Заметим, что определение таких
стандартных протоколов не исключает возможность использования некой парой служб
альтернативного протокола, если обе службы поддерживают его). Увидим, будут или нет
такие интергрид протоколы определены и получат ли широкое применение. Во всяком
случае, их определение находится вне рамок данной статьи.
8 Высокоуровневые службы
Абстракции и службы, описанные в этой статье, обеспечивают строительные

блоки, которые могут быть использованы при разработке разнообразных
высокоуровневых грид-служб. Мы намерены тесно сотрудничать с общественностью при
определении и разработке широкого спектра таких служб, которые, будучи
используемыми коллективно, удовлетворят разным требованиям электронных
коммерческих и научных приложений. Вероятно, следует обратить внимание на
следующие службы:
• Службы управления распределёнными данными, поддерживающие доступ и
манипуляции с распределёнными данными, размещаемыми в базах данных или
файлах [58]. Представляют интерес службы, обеспечивающие доступ к базам
данных, преобразование данных, управление репликацией, определением
местоположения репликации и транзакций.
• Службы рабочих потоков, способствующие скоординированному выполнению
множества прикладных задач на множестве распределённых грид-ресурсов.
• Службы аудита, поддерживающие регистрацию используемых данных,
безопасное хранение этих данных и их анализ для целей выявления
злоумышленного использования или вмешательства и т.д.
• Службы мониторинга и инструментальные службы, помогающие обнаруживать
“чувствительные элементы” (“sensors”)в распределённом оборудовании, собирать и
анализировать информацию от этих элементов, генерировать сигналы, когда
обнаруживаются необычные состояния, и так далее.
• Службы выявления отказов при распределённом компьютинге, обеспечивающие
аварийную выдачу, трассировку, механизмы журналирования с возможностями
регистрации событий и исправления.
• Службы отображения протокола безопасности, способствующие прозрачному
отображению распределённых протоколам безопасности на средства безопасности
локальной платформы для использования этих протоколов при создании

35
отсутствующих на платформе средств управления ресурсами, которые

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

Инструментального комплекса Globus; справа потенциальная перестройка с целью
использования OGSA механизмов.
В связи с этим, у нас возникает желание произвести реинжениринг управления

ресурсами, передачей данных и протоколов информационных служб, используемых в
текущей версии Инструментального комплекса Globus, для построения его на таких
общих механизмах (см. Рисунок 4). Фактически мы можем перепроектировать (refactor)
эти протоколы, вычленяя аналогичные элементы для общего применения. Далее, мы
усовершенствуем возможности действующих протоколов и придём к инфраструктуре
общих служб. В результате такого процесса будет создан Инструментальный комплекс
Globus 3.0.
9 Родственные работы
Мы кратко охарактеризуем некоторые предыдущие родственные и другие

связанные с обсуждаемой проблемой работы, фокусированные, в частности, на вопросах,
касающихся безопасности, надёжным удалённым созданием и управлением временными
службами, обладающими состоянием.
Как обсуждалось в Разделе 3.1, многие механизмы OGSA заимствованы у

Инструментального комплекса Globus v2.0. В частности, фабрика (привратник GRAM
[25]), реестр (GRAM reporter [25] и MDS-2 [24]) используют мягкую (soft-state)
регистрацию (MDS-2 [24]), безопасный удалённый вызов с делегированием полномочий
(GSI [33]) и надёжный удалённый вызов (GRAM [25]). Главные отличия связаны с тем,
что эти различные механизмы интегрированы с реконструированными ключевыми
элементами OGSA так, что, например, общие механизмы уведомления используются и для
регистрации службы и для поддержки информации о состоянии службы.

36
OGSA можно рассматривать как распределённую систему объектов [21], в том

смысле, что в этой системе каждый экземпляр грид-службы имеет уникальный
идентификатор по отношению к другим экземплярам и каждый экземпляр может быть
охарактеризован описанием его состояния и дисциплиной исполнения, опубликованными
посредством специфических для каждого типа операций. В этом отношении, OGSA
использует идеи, ранее воплощенные в таких системах, как Eden [7], Argus [48], CORBA
[1], SOS [60], Spring [51], Globe [62], Mentat [42], Legion [41, 43] и в ряде других. В
отличие от CORBA, OGSA подобно Web-службам непосредственно разрешает проблемы
безопасной интероперабельности и обеспечивает более богатый язык определения
интерфейсов. В контексте грид-компьютинга коллектив разработчиков системы Legion
активно использовал технологию моделей объектов, и мы можем провести параллели
между определёнными конструкциями OSGA и системы Legion, в частности, фабрикой
(“Class Object”), handleMap (Binding Agent). Тем не менее, мы также подчёркиваем, что
OGSA вовсе не предназначена для поддержки ряда проблем, которые часто
рассматриваются как центральные для распределённых объектных систем, например
таких, как использование объектных технологий при проведении разработок, обеспечение
механизмов наследования на уровне интерфейса и хостинг-технологии.
Мягкие (soft-state) механизмы использованы для управления конкретным

состоянием в сетевых сущностях внутри Интернет–протоколов [23, 61, 69], а также (под
именем “leases”) в RMI и Jini [57]. В OGSA все службы и информация открыты для
мягкого (soft-state) управления. Мы предпочитаем мягкие (soft-state) методы
альтернативным таким, как подсчет распределённых ссылок [12], потому что они
сравнительно проще.
Наши механизмы надёжной активизации вдохновлены теми, что использованы в

системе Condor [36, 49, 50], которые, в свою очередь, основываются на многих
предыдущих работах в распределённых системах.
Как отмечалось в Разделе 4.3, дисциплины базовых служб OGSA будут, вообще
говоря, поддерживаться средствами некоторой хостинг-среды, которая упрощает
разработку отдельных компонентов, обеспечивая живучесть управления, безопасность,
управление временем жизни и т.д. Идея хостинг-среды появляется в различных
операционных системах и объектных системах.
Приложения механизмов Web-служб для грид-компьютинга исследовались и

защищались и в других работах (например, [35, 37]), и на недавней рабочей встрече,
представившей обзоры ряда разработок, касающихся рассматриваемой проблемы [2].
Гэннон (Gannon) и другие в [37] обсуждают применение различных современных
технологий для научно-технических приложений и предлагают “фабрики приложений” (с
WSDL-интерфейсами), в качестве средств динамического создания служб приложений. Де
Рур (De Roure) и другие в [26] предлагает описание грид-семантики (Semantic Grid) по
аналогии с Web-семантикой в [11], и описывают ряд высокоуровневых служб. Работы по
ориентированным на службы интерфейсам для программного обеспечения численных
методов в проектах NetSolve [16, 17] и Ninf [55] также родственны обсуждаемой теме.
Система JXTA [3] фирмы Sun Microsystems решает несколько важных проблем,
встречающихся в грид, включая обнаружение, и членство в виртуальных организациях,

37
которые в JXTA называются группами участников (“peer groups”). Мы полагаем, что эти
абстракции могут быть реализованы в инфраструктуре OGSA.
Следует отметить родственность с моделями компонентов для распределённого и

высокопроизводительного компьютинга [8, 13, 68], несколько реализаций которых
построены на механизмах Инструментального комплекса Globus.
10 Заключение
Мы определили Открытую архитектуру грид-служб (OGSA), которая посредством

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

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

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

комплекса Globus 2.0, в котором существуют ключевые концепции фабрики, системного
реестра, надёжно и безопасной активизации и т. д., но в менее общей и гибкой форме, чем
рассмотрено здесь и без преимущества использования универсального языка определения
интерфейса. Фактически OGSA заново воссоздаёт ключевые элементы конструирования
так, что, например, для регистрации и поддержки информации о состоянии службы
используются общие механизмы уведомления. Кроме того, OGSA абстрагирует эти
элементы так, что они могут быть применены на любом уровне виртуализации ВО
ресурсов. Инструментальный комплекс Globus обеспечивает базу для открытой
разработки OGSA и Инструментального комплекса Globus 3.0, который поддерживает
существующие API ИК Globus, а также WSDL-интерфейсы, как это описано в
www.globus.org/ogsa.
Разработка OGSA также представляется естественным развитием концепции Web-

служб. Интегрируя поддержку временных, обладающих описанием состояния
экземпляров служб с существующими технологиями Web-служб, архитектура OGSA

38
значительно расширяет мощность инфраструктуры Web-служб, в то же время требуя

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

OGSA, Карла Чайковски (Karl Czajkowski), Джеффри Фрея (Jeffrey Frey) и Стива Грехама
(Steve Graham). Мы также признательны многочисленным коллегам, принявшим участие в
обсуждении по данной тематике и/или за полезные комментарии к различным версиям
этой статьи, в частности, Малкому Эткинсону (Malcolm Atkinson), Брайану Карпентуру
(Brian Carpenter), Дэвиду Де Роу (David De Roure), Эндрю Гримшоу (Andrew Grimshow),
Марти Хамфрею (Marty Humphrey), Кит Джексон (Keith Jackson), Билли Джонсону (Bill
Johnston), Кэйт Кихей (Kate Keahey), Грегору фон Лазевски (Gregor von Laszewsky), Ли
Лимингу (Lee Liming), Мирону Ливни (Miron Livny), Норману Патону (Norman Paton),
Жану-Пьеру Просту (Jean-Pierre Prost), Томасу Сэндхолму (Thomas Sandholm), Питеру
Вандербильту (Peter Vanderbilt) и Вону Велчу (Von Welch).
Эта работа была частично поддержана подпрограммой Отделения математики,

информации и информатики Отдела передовых научных компьютерных исследований
Министерства энергетики США (Mathematical, Information, and Computational Sciences
Division subprogram of the Office of Advanced Scientific Computing Research ,U.S Department
of Energy) в соответствии с Контрактом W-31-109-Eng-38; Национальным научным
фондом (National Science Foundation); программой Информационная грид-среда НАСА
(NASA Information Power Grid program) и корпорацией IBM.
Библиография
1. Common Object Request Broker: Architecture and Specification, Revision 2.2. Object
Management Group Document 96.03.04, 1998.
2. Grid Web Services Workshop. 2001,
https://gridport.npaci.edu/workshop/webserv01/agenda.html.
3. JXTA. www.jxta.org.
4. Simple Object Access Protocol (SOAP) 1.1. W3C, Note 8, 2000.
5. UDDI: Universal Description, Discovery and Integration. http://www.uddi.org.
6. Web Services Flow Language.
www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.
7. Almes, G.T., Black, A.P., Lazowska, E.D. and Noe, J.D. The Eden System: A Technical
Review. IEEE Transactions on Software Engineering, SE-11 (1). 43--59. 1985.
8. Armstrong, R., Gannon, D., Geist, A., Keahey, K., Kohn, S., McInnes, L. and Parker, S.
Toward a Common Component Architecture for High Performance Scientific Computing. In
Proc. 8th IEEE Symp. on High Performance Distributed Computing, 1999.
9. Bal, H.E., Steiner, J.G. and Tanenbaum, A.S. Programming Languages for Distributed
Computing Systems. ACM Computing Surveys, 21 (3). 261--322. 1989.
10. Barrett, D.J., Clarke, L.A., Tarr, P.L. and Wise, A.E. A Framework for Event-based Software
Integration. ACM Transactions on Software Engineering and Methodology, 5 (4). 378-421.
1996.
11. Berners-Lee, T., Hendler, J. and Lassila, O. The Semantic Web. Scientific American. 2001.
12. Bevan, D.I., Distributed Garbage Collection Using Reference Counting. In PARLE Parallel
Architectures and Languages Europe, (1987), Springer Verlag, LNCS 259, 176-187

39
13. Bramley, R., Gannon, D., Stuckey, T., Villacis, J., Balasubramanian, J., E. Akman, Breg, F.,
Diwan, S. and Govindaraju, M. Component Architectures for Distributed Scientific Problem
Solving. IEEE Computational Science and Engineering, 5 (2). 50-63. 1998.
14. Bray, T., Paoli, J. and Sperberg-McQueen, C.M. The Extensible Markup Language (XML)
1.0. 1998.
15. Brittenham, P. An Overview of the Web Services Inspection Language. 2001,
http://www.ibm.com/developerworks/webservices/library/ws-wsilover.
16. Casanova, H. and Dongarra, J. NetSolve: A Network Server for Solving Computational
Science Problems. International Journal of Supercomputer Applications and
HighPerformance Computing, 11 (3). 212-223. 1997.
17. Casanova, H., Dongarra, J., Johnson, C. and Miller, M. Application-Specific Tools. In
Foster, I. and Kesselman, C. eds. The Grid: Blueprint for a New Computing Infrastructure,
Morgan Kaufmann, 1999, 159-180.
18. Catlett, C. In Search of Gigabit Applications. IEEE Communications Magazine (April). 42-
51. 1992.
19. Catlett, C. and Smarr, L. Metacomputing. Communications of the ACM, 35 (6). 44--52. 1992.
20. Chamberlin, D. Xquery 1.0: An XML Query Language. W3C Working Draft 07, 2001.
21. Chin, R.S. and Chanson, S.T. Distributed Object-based Programming Systems. ACM
Computing Surveys, 23 (1). 91-124. 1991.
22. Christensen, E., Curbera, F., Meredith, G. and Weerawarana., S. Web Services Description
Language (WSDL) 1.1. W3C, Note 15, 2001, http://www.w3.org/TR/wsdl.
23. Clark, D.D., The Design Philosophy of the DARPA Internet Protocols. In SIGCOMM
Symposium on Communications Architectures and Protocols, (1988), ACM Press, 106- 114
24. Czajkowski, K., Fitzgerald, S., Foster, I. and Kesselman, C., Grid Information Services for
Distributed Resource Sharing. In 10th IEEE International Symposium on High Performance
Distributed Computing, (2001), IEEE Press, 181-184
25. Czajkowski, K., Foster, I., Karonis, N., Kesselman, C., Martin, S., Smith, W. and Tuecke, S.
A Resource Management Architecture for Metacomputing Systems. In 4th Workshop on Job
Scheduling Strategies for Parallel Processing, Springer-Verlag, 1998, 62-82.
26. De Roure, D., Jennings, N. and Shadbolt, N. Research Agenda for the Semantic Grid: A
Future e-Science Infrastructure. UK National eScience Center, 2002,
http://www.semanticgrid.org.
27. Fallside, D.C. XML Schema Part 0: Primer. W3C, Recommendation, 2001,
http://www.w3.org/TR/xmlschema-0/.
28. Foster, I. The Grid: A New Infrastructure for 21st Century Science. Physics Today, 55(2).
42-47. 2002.
29. Foster, I. and Kesselman, C. Globus: A Toolkit-Based Grid Architecture. In Foster, I. and
Kesselman, C. eds. The Grid: Blueprint for a New Computing Infrastructure, Morgan
Kaufmann, 1999, 259-278.
30. Foster, I. and Kesselman, C. (eds.). The Grid: Blueprint for a New Computing Infrastructure.
Morgan Kaufmann, 1999.
31. Foster, I., Kesselman, C., Lee, C., Lindell, R., Nahrstedt, K. and Roy, A., A Distributed
Resource Management Architecture that Supports Advance Reservations and Co- Allocation.
In Proc. International Workshop on Quality of Service, (1999), 27-36
32. Foster, I., Kesselman, C., Nick, J.M. and Tuecke, S. Grid Services for Distributed Systems
Integration. IEEE Computer, 35 (6). 2002.
33. Foster, I., Kesselman, C., Tsudik, G. and Tuecke, S. A Security Architecture for
Computational Grids. In ACM Conference on Computers and Security, 1998, 83-91.

40
34. Foster, I., Kesselman, C. and Tuecke, S. The Anatomy of the Grid: Enabling Scalable Virtual
Organizations. International Journal of High Performance Computing Applications, 15 (3).
200-222. 2001. http://www.globus.org/research/papers/anatomy.pdf.
35. Fox, G., Balsoy, O., Pallickara, S., Uyar, A., Gannon, D. and Slominski, A. Community
Grids. Community Grid Computing Laboratory, Indiana University, 2002.
36. Frey, J., Tannenbaum, T., Foster, I., Livny, M. and Tuecke, S., Condor-G: A Computation
Management Agent for Multi-Institutional Grids. In 10th International Symposium on High
Performance Distributed Computing, (2001), IEEE Press, 55-66
37. Gannon, D., Bramley, R., Fox, G., Smallen, S., Rossi, A., Ananthakrisnan, R., Bertrand, F.,
Chiu, K., Farrellee, M., Govindaraju, M., Krishnan, S., Ramakrishnan, L., Simmhan, Y.,
Slominski, A., Ma, Y., Olariu, C. and Rey-Cenvaz, N., Programming the Grid: Distributed
Software Components, P2P, and Grid Web Services for Scientific Applications. In Grid
2001, (2001)
38. Gasser, M. and McDermott, E., An Architecture for Practical Delegation in a Distributed
System. In Proc. 1990 IEEE Symposium on Research in Security and Privacy, (1990), IEEE
Press, 20-30
39. Getov, V., Laszewski, G.v., Philippsen, M. and Foster, I. Multiparadigm Communications in
Java for Grid Computing. Communications of the ACM, 44 (10). 118-125. 2001.
40. Graham, S., Simeonov, S., Boubez, T., Daniels, G., Davis, D., Nakamura, Y. and Neyama, R.
Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI. Sams,
2001.
41. Grimshaw, A.S., Ferrari, A., Knabe, F.C. and Humphrey, M. Wide-Area Computing:
Resource Sharing on a Large Scale. IEEE Computer, 32 (5). 29-37. 1999.
42. Grimshaw, A.S., Ferrari, A.J. and West, E.A. Mentat. In Parallel Programming Using C++,
MIT Press, 1997, 383-427.
43. Grimshaw, A.S. and Wulf, W.A. The Legion Vision of a Worldwide Virtual Computer.
Communications of the ACM, 40 (1). 39-45. 1997.
44. Gullapalli, S., Czajkowski, K., Kesselman, C. and Fitzgerald, S. The Grid Notification
Framework. Global Grid Forum, Draft GWD-GIS-019, 2001.
45. Johnston, W. Realtime Widely Distributed Instrumentation Systems. In Foster, I. and
Kesselman, C. eds. The Grid: Blueprint for a New Computing Infrastructure, Morgan
Kaufmann, 1999, 75-103.
46. Johnston, W.E., Gannon, D. and Nitzberg, B., Grids as Production Computing Environments:
The Engineering Aspects of NASA's Information Power Grid. In Proc. 8th IEEE Symposium
on High Performance Distributed Computing, (1999), IEEE Press
47. Kreger, H. Web Services Conceptual Architecture. IBMTechnical Report WCSA 1.0, 2001.
48. Liskov, B. Distributed Programming in Argus. Communications of the ACM, 31 (3). 300-
312. 1988.
49. Litzkow, M. and Livny, M. Experience With The Condor Distributed Batch System. In IEEE
Workshop on Experimental Distributed Systems, 1990.
50. Livny, M. High-Throughput Resource Management. In Foster, I. and Kesselman, C. eds. The
Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 1999, 311- 337.
51. Mitchell, J.G., Gibbons, J., Hamilton, G., Kessler, P.B., Khalidi, Y.Y.A., Kougiouris, P.,
Madany, P., Nelson, M.N., Powell, M.L. and Radia, S.R., An Overview of the Spring
System. In COMPCON, (1994), 122-131
52. Mockapetris, P.V. and Dunlap, K., Development of the Domain Name System. In
SIGCOMM, (1988), ACM, 123-133
53. Mukhi, N. Web Service Invocation Sans SOAP. 2001,
http://www.ibm.com/developerworks/library/ws-wsif.html.
54. Mullender, S. (ed.), Distributed Systems, 1989.

41
55. Nakada, H., Sato, M. and Sekiguchi, S. Design and Implementations of Ninf: towards a
Global Computing Infrastructure. Future Generation Computing Systems, 15 (5-6). 649-658.
1999.
56. Nick, J.M., Moore, B.B., Chung, J.-Y. and Bowen, N.S. S/390 Cluster Technology: Parallel
Sysplex. IBM Systems Journal, 36 (2). 172-201. 1997.
57. Oaks, S. and Wong, H. Jini in a Nutshell. O'Reilly, 2000.
58. Paton, N.W., Atkinson, M.P., Dialani, V., Pearson, D., Storey, T. and Watson, P.Database
Access and Integration Services on the Grid. Manchester University, 2002.
59. Raman, S. and McCanne, S. A Model, Analysis, and Protocol Framework for Soft Statebased
Communication. Computer Communication Review, 29 (4). 1999.
60. Shapiro, M. SOS: An Object Oriented Operating System—Assessment and Perspectives.
Computing Systems, 2 (4). 287-337. 1989.
61. Sharma, P., Estrin, D., Floyd, S. and Jacobson, V., Scalable Timers for Soft State Protocols.
In IEEE Infocom '97, (1997), IEEE Press
62. Steen, M.v., Homburg, P., Doorn, L.v., Tanenbaum, A. and Jonge, W.d. Towards
Objectbased Wide Area Distributed Systems. In Carbrera, L.-F. and Theimer, M. eds.
International Workshop on Object Orientation in Operating Systems, 1995, 224-227.
63. Steiner, J., Neuman, B.C. and Schiller, J., Kerberos: An Authentication System for Open
Network Systems. In Proc. Usenix Conference, (1988), 191-202
64. Stevens, R., Woodward, P., DeFanti, T. and Catlett, C. From the I-WAY to the National
Technology Grid. Communications of the ACM, 40 (11). 50-61. 1997.
65. Thomas, A. Enterprise Java Beans Technology: Server Component Model for the Java
Platform. 1998, http://java.sun.com/products/ejb/white_paper.html.
66. Tuecke, S., Czajkowski, K., Foster, I., Frey, J., Graham, S. and Kesselman, C. Grid Services
Specification. 2002, http://www.globus.org/research/papers/gsspec.pdf.
67. Tuecke, S., Engert, D., Foster, I., Thompson, M., Pearlman, L. and Kesselman, C. Internet
X.509 Public Key Infrastructure Proxy Certificate Profile. IETF, Draft draft-ietfpkix-proxy-
01.txt, 2001.
68. Villacis, J., M.Govindaraju, Stern, D., Whitaker, A., Breg, F., Deuskar, P., Temko, B.,
Gannon, D. and Bramley, R., CAT: A High Performance, Distributed Component
Architecture Toolkit for the Grid. In IEEE Intl Symp. on High Performance Distributed
Computing, (1999)
69. Zhang, L., Braden, B., Estrin, D., Herzog, S. and Jamin, S., RSVP: A new Resource
ReSerVation Protocol. In IEEE Network, (1993), 8-18

42

Физиология ГРИД Фостер

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Физиология ГРИД Фостер

Загружено:

Авторское право:

Доступные форматы

Я. Фостер, К. Кессельман, Д.М. Ник, С.

Тьюке “ФИЗИОЛОГИЯ ГРИД”

Открытая архитектура грид-служб для интеграции распределённых систем

Ян Фостер Карл Кессельман Джефри М. Ник Стивен Тьюке

THE PHYSIOLOGY OF THE GRID

An Open Grid Services Architecture for Distributed Systems Integration

Ian Foster1,2 Carl Kesselman3 Jeffrey M. Nick4 Steven Tuecke1

foster@mcs.anl.gov, carl@isi.edu, jnick@us.ibm.com, tuecke@mcs.anl.gov

Перевод с англ.: Корягин Д.А., ИПМ РАН

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

Перевод с англ.: Корягин Д.А., ИПМ РАН

Перевод с англ.: Корягин Д.А., ИПМ РАН

До недавнего времени разработчики приложений часто могли рассчитывать на то,

Эти эволюционные факторы обусловили появление новых требований к разработке

В течение определённого времени такие проблемы находились в центре внимания

В более ранней статье [34], мы определили, что грид-технологии и инфраструктуры

Перевод с англ.: Корягин Д.А., ИПМ РАН

также описали Инструментальный комплекс Globus (Globus Toolkit тм 1 [29]), реализацию

Во-вторых, мы объясняем, как можно грид-технологии совместить с технологиями

Перевод с англ.: Корягин Д.А., ИПМ РАН

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

Далее в данной статье обсуждаются следующие вопросы. В Разделе 2 мы

Мы подчёркиваем, что Открытая архитектура грид-служб и связанные с ней

2 Потребность в технологиях грид

Грид-технологии поддерживают разделение и согласованное использование

Концепции и технологии грид сначала разрабатывались для обеспечения

Перевод с англ.: Корягин Д.А., ИПМ РАН

научных измерительных устройств с удалёнными компьютерами и архивами (расширение

Тем не менее, мы убеждены, что грид-концепции чрезвычайно важны для бизнес-

2.1 Эволюция систем корпоративного компьютинга

Однако подъём интернет и появление электронных коммерческих приложений

В общем, эти попытки оказались неудачными, поскольку декомпозиция ИТ-служб

Перевод с англ.: Корягин Д.А., ИПМ РАН

наследовать имеющиеся на мэйнфреймах активные прикладные пакеты и наборы данных.

Параллельно с этими разработками корпорации всё более энергично вовлекаются в

Совокупный эффект, получаемый от этих разработок выражается в том, что

Следствие всех этих тенденций проявляется в том, что интеграторы ИТ-систем

Перевод с англ.: Корягин Д.А., ИПМ РАН

всё более и более напряжённым, сложным и уязвимым, поскольку персонал,

2.2 Провайдеры услуг и B2B-компьютинг

Появление такого рода “электронных коммунальных служб” (“eUtilies” – это

Другая ключевая тенденция развития ИТ-индустрии – это межкорпоративное

Перевод с англ.: Корягин Д.А., ИПМ РАН

компьютинг является еще одним источником заказа на интеграцию распределённых

Мы рассмотрим две технологии, на основе которых определим Открытую

3.1 Инструментальный комплекс Globus

Наиболее существенными для архитектуры OGSA компонентами ИК Globus

Перевод с англ.: Корягин Д.А., ИПМ РАН

Рисунок 1: Избранные механизмы ИК Globus иллюстрируют первоначальное

Протокол GRAM обеспечивает надёжное, безопасное, удалённое создание и

MDS-2 [24] обеспечивает единообразную схему для обнаружения и доступа к

Базирующийся на технологии открытых ключей грид-протокол Инфраструктуры

Перевод с англ.: Корягин Д.А., ИПМ РАН

эта возможность оказывается важной при выполнении операций, имеющих вложенную

В качестве основы для идентификации пользователя GSI использует сертификаты

Стандарты Web-служб устанавливаются в комитете W3C и других структурах и

• Простой Протокол Доступа к Объекту (Simple Object Access Protocol – SOAP

Перевод с англ.: Корягин Д.А., ИПМ РАН

запроса. SOAP это простой оболочечный механизм отправлений, представленных на

С точки зрения наших целей важны два достоинства инфраструктуры Web-служб.

Перевод с англ.: Корягин Д.А., ИПМ РАН

(транспортный протокол и формат кодирования данных). Во-вторых, широкое

4 Открытая архитектура грид-служб

Мы убеждены, что во внутренних ИТ-инфраструктурах предприятий,