Стандартизация грид-служб

Грид-служба на практике является Web-службой, которая построена в соответствии с частным видом кодирования, а именно с использованием стандартных XML-соглашений. Например, грид-службы могут быть определены в терминах WSDL, основанного на стандартных конструкциях XML, возможно с некоторыми небольшими расширениями языка XML. Эти грид-службы используют такие технологии связывания стандартных Web-служб, как SOAP, WS-Reliable Messaging, WS-Transaction и WS-Security. Грид-службы действительно выглядят как Web-службы, в особенности с точки зрения программирования.

Ранее было установлено, что все физические и логические ресурсы в OGSA смоделированы в виде служб. Службы конструируются как надстройки над SOA, более

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

Эволюция стандартов Web-служб

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

НЕ нашли? Не то? Что вы ищете?

На Рис.6 показаны развивающиеся стандарты, которые поддерживаются ведущими компьютерными компаниями IBM и Microsoft [15]. Эти стандарты включают в себя следующие элементы:

  1. модель данных XML – как определено в W3C (консорциум WWW), модель данных XML (или информационный набор XML) образует ядро спецификаций XML, включая SOAP и WSDL. Эта общая основа дает возможность создавать более гибкие инструменты и XML-процессоры;

  2. модульность (Modularity) – SOAP обеспечивает оболочку и механизм обработки XML-сообщений. SOAP также обеспечивает независимый от транспортных протоколов формат данных для передачи XML-сообщений, основанный на формате SOAP, определённом спецификацией SOAP или схемой XML. Сообщения, кодированные с использованием схемы XML, рекомендованы для применения и обычно называются документами или текстовыми сообщениями;

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

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

  5. открытые стандарты. Большинство упомянутых здесь спецификаций и стандартных протоколов относятся к различным источникам стандартов, включая OASIS (Organization for the Advancement of Structured Information Standards) и W3C. Далее в этой статье мы обсудим некоторые из стандартов, играющих главную роль в процессе стандартизации грида.

Как показано на Рис.6, главные строительные блоки этих расширенных стандартов оперативного подключения (plug-and-play) поддерживают возможности обеспечения безопасности на уровне передачи сообщений, уведомительных сообщений о транзакциях, координацию обмена сообщениями среди участников и шаблоны, обеспечивающие надежность такого обмена. Другие возможности включают в себя механизмы адресации, сервисную политику для надлежащей обработки сообщений, обмен метаданными и систему уведомлений потребителей и провайдеров услуг, обменивающихся сообщениями.

Рис.6

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

   

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

PortType (интерфейс)

Операция

Описание операции

GridService (Грид-служба)

FindServiceData (Найти данные, ассоциированные со службой)

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

SetTerminationTime (Установка времени завершения)

Установка (и получение) времени завершения экземпляра грид-службы

Destroy (Ликвидация)

Завершение экземпляра грид-службы

NotificationSource (Источник уведомления)

SubsribeToNotificftionTopic (Подписка на раздел уведомлений)

Подписка на уведомления о связанных со службой событиях, c указанием типа сообщения. Разрешается доставка через сторонние службы сообщений

NotificationSink (Приёмник уведомлений)

DeliverNotification (Доставка уведомлений)

Выполнение асинхронной доставки уведомительных сообщений.

Registry (Реестр)

RegisterService (Регистрация службы)

Мягкая (soft-state) регистрация дескрипторов грид-службы

UnregisterService (Удаление регистрационной записи)

Удаление из реестра дескриптора грид-службы

Factory (Фабрика)

CreateService (Создание службы)

Создание нового экземпляра грид-службы

HandleMap (Дескриптор)

FindByHandle (Обнаружение с помощью дескриптора)

Возвращение ссылки (GSR) , в настоящее время связанной с данным дескриптором (GSH) грид-службы

Модель службы OGSA

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

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

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

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

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

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

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

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

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

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

Грид-службы как Web-службы

Существуют два основных стандарта в сфере грид: Open Grid Services Infrastructure (OGSI) и Web Services Resource Framework (WSRF).

Стандарт OGSI

Базовой компонентой архитектуры OGSA является OGSI. OGSI представляет собой стандарт компьютерной инфраструктуры грид, основанный на использовании появившихся стандартов Web-служб. Цель OGSI заключается в обеспечении максимально возможной интероперабельности между программными компонентами OGSA. Примером грид-службы, созданной на основе спецификаций OGSI [17], является Web-служба, которая построена в соответствии с набором соглашений, записанных на WSDL, и включает в себя интерфейсы службы, расширения и модели поведения службы. Грид-служба обеспечивает контролируемое управление распределённой и, часто, имеющей достаточно продолжительное время жизни системой, что обычно требуется для выполнения сложных распределенных приложений.

На Рис.7 показано расположение слоями компонент OGSI в Web-службе с новыми интерфейсами и моделями поведения. Самым значимым пунктом является расширение WSDL для обеспечения дополнительных механизмов описания информации о состоянии. Кроме того, спецификация представляет множество моделей поведения и интерфейсы для поддержки стадий жизненного цикла службы, например: управление на уровне службы, корпоративное управление, уведомления об изменении состояния, механизмы создания служб и управление ссылками на экземпляры служб.

Рис.7

Интероперабельность на уровне сообщений является ключевой характеристикой этого стандарта, и она достигается путем использования XML, как базового формата передаваемых сообщений, и схемы XML. Одним из требований к службам, определенным OGSI, является способность описать данные о состоянии, характеристики жизненного цикла и поведение экземпляров служб, используя модель описаний OGSI, которая на самом деле представляет собой комбинацию WSDL и GWSDL (Grid Web Services Definition Language) [5,16].

Стандарт WSRF

WSRF представляет собой набор спецификаций для поддержки грид-служб или других ресурсов, обладающих состоянием (т. е. ресурсов, чье поведение определено с учетом нижележащего состояния), и является сравнимым со стандартом OGSI. Существует много доводов в пользу спецификаций WSRF [17]. Как показано на Рис.8, наиболее значительный вклад состоит в скрещивании грид-компьютинга и стандартов Web-служб, а также их совмещения с принципами SOA.

Рис.8

Такое совмещение поможет определить открытые стандарты через совместимые, оперативно подключаемые расширения служб для архитектур гридов, обеспечивая тем самым более приемлемую и легкую интеграцию. Благодаря этому грид-службы могут использовать существующие стандарты для Web-служб, такие, как WS-Notification [18], WS-Addressing [19] и WS-Security [20], а также создавать расширения для новых возможностей, таких, как получение данных о состоянии службы, управление временем жизни, группирование и управление ссылками на службы.

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

Введение в WSRF

Существует много аргументов в пользу использования WSRF-спецификаций. Самый значительный вклад WSRF состоит в объединении грида и Web стандартов. Это требует развитию открытых стандартов и интероперабельных, подключаемых к грид-архитектуре расширений служб. Как было отмечено, спецификация OGSI в противоположность WSRF, является более объектно-центрированной, так как вводит набор понятий, переопределяющих схемы XML; некоторые доводы указывают на то, что такие расширения не соответствуют существующим инструментальным средствам разработки Web-служб [21].

Другим мотивационным фактором является конвергенция грид-служб с существующими языками, моделями программирования, инструментами и технологическими решениями, принятыми в Web-службах, системном управлении и компьютинге по запросу. Лучшими примерами такой конвергенции являются система распределённого управления Web-службами (Web Services Distributed Management) и виртуализационная инфраструктура по запросу компании IBM.

Спецификации WSRF основываются на шаблоне неявного ресурса (implied resource pattern), описанном в следующем разделе. Этот расширенный набор спецификаций позволяет управлять временем жизни ресурса с состоянием, отправлять и получать уведомления об изменении состояния, показывать информацию о состоянии в виде XML-документов и обрабатывать ошибки.

Шаблон неявного ресурса для ресурсов с состоянием

Шаблон неявного ресурса указывает на механизм связывания Web-служб и ресурсов с состоянием через набор соглашений, используемых в комбинированных технологиях построения Web-служб, таких как стандарт WS-Addressing. Под термином "комбинированный" здесь имеется в виду набор расширенных возможностей Web-служб, позволяющий объединять спецификации этих служб для достижения более высоких показателей их функционирования. Заказчик определяет ресурс с состоянием при помощи механизма WS-Addressing, называемого ссылкой на крайнюю точку (endpoint reference, EPR). В EPR содержится достаточная информация, представленная в виде EPR-свойств, для диспетчеризации соответствующей крайней точки. Такой шаблон обмена сообщениями с точной идентификацией ресурса в контексте сообщения (с использованием свойств ссылки, определяемых спецификацией WS-Addressing), однозначно идентифицирует целевой ресурс. Ресурс с состоянием, поддерживаемый шаблоном неявного ресурса, будем называть WS-Resource.

Спецификация WS-Addressing

WS-Addressing обеспечивает транспортно-независимые механизмы определения местоположения Web-служб [9]. Спецификация предусматривает использование следующих конструкций: гибкая и расширяемая модель описания EPR, набор заголовков SOAP-сообщений (характеристики SOAP) и правила отображения элементов ссылки на элементы заголовков SOAP.

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

Спецификация WS-Addressing стандартизирует представление адреса Web-службы, развертываемое в сетевой адрес крайней точки, и обеспечивает поддержку WS-адресуемой ссылки на крайнюю точку (WS - Addressing EPR), которая является XML-сериализацией сетевого указателя на Web-службу. EPR содержит следующие компоненты: адрес службы (wsa:Аddress), метаданные, ассоциированные с этой службой (такие, как описание службы с помощью конструкций WSDL), информацию о политике использования службы и свойства ссылки (wsa:ReferenceProperties), которые могут использоваться для точной идентификации экземпляра ресурса с состоянием, ассоциированным с Web-службой в адресе крайней точки.

Спецификация WS-Resource

WS-Resource – это ресурс с состоянием, например, память на диске, компьютерная система, операционная система или кредитная карта. Ресурсы отождествляются с ресурсами Web-служб в соответствии с шаблоном неявного ресурса (т. е. в соответствии с моделью взаимодействий объектов, обладающих состоянием). WS-ресурс представляет собой ресурс с состоянием и связанную с ним Web-службу.

WS-ресурс имеет доступную в сети ссылку на крайнюю точку, в которой определены Web-служба и набор свойств ссылки для однозначной идентификации конкретного ресурса с помощью механизма WS-Addressing. Например, на Рис.9 показаны три ресурса, представляющих собой компьютерные системы и фасад1 – Web-служба с сетевой крайней точкой. Каждая компьютерная система определяется, используя свойства ссылки (reference properties) механизма WS-Addressing.

Рис.9

Идентифицирующая информация для WS-Resource предназначена для связывания, и заказчик службы избавлен от необходимости её интерпретации. Эта информация, снабженная заголовком SOAP, используется фасадом Web-службы для нахождения подходящего ресурса. WS-ресурс может быть реализован с использованием множества интерфейсов и быть связан с несколькими фасадами Web-служб, и соответственно, с различными EPR.

Информация о состоянии ресурса доступна заказчику службы из документов свойств ресурса (XML-документы/формы). Каждый ресурс с состоянием имеет свой жизненный цикл с точно определённой семантикой для его создания и уничтожения. Идентификация ресурса происходит во время его создания.

Спецификация WS-Notification

WS-Notification – это основанная на механизме событий модель взаимодействий,. используемая обычно для межобъектных коммуникаций [18]. Например, в системах подписки/рассылки, поставляемых продавцами промежуточного программного обеспечения, ориентированного на передачу сообщений, или в сферах управления системами и устройствами. Более широко эта модель уведомлений используется в контексте функционирования Web-служб.

Стандарт WS-Notification представляет собой семейство белых книг2 (white papers) и соответствующих им спецификаций, которые определяют стандартный подход, принятый в Web-службах для уведомительных сообщений, используя предметную модель подписки/рассылки. Этот стандарт включает в себя типовые механизмы обмена сообщениями, реализованные провайдерами услуг, участвующих в уведомлениях. А также механизмы обмена сообщениями для провайдера-брокера уведомительных услуг (позволяя рассылку сообщений от объектов, не являющихся провайдерами услуг), операционные требования для провайдеров и заказчиков, участвующих в схеме уведомлений, и, наконец, модель XML, которая описывает разделы уведомлений (т. е. вопросы, представляющие интерес для подписчиков).

Семейство документов WS-Notification включает белую книгу (white paper) [см.18] с тремя нормативными спецификациями: WS-BaseNotification [23], WS-BrokeredNotification [24] и WS-Topics [25]. Спецификация WS-BaseNotification определяет интерфейсы Web-служб для поставщиков и потребителей уведомлений. Спецификация включает в себя стандартные схемы обмена сообщениями, реализованные провайдерами услуг, и операционные требования для этих провайдеров. В спецификации WS-BrokeredNotification определяется интерфейс Web-служб для брокера уведомлений. Брокер уведомлений является посредником, который, помимо всего прочего, предоставляет возможность рассылки сообщений от объектов, не являющихся провайдерами. Спецификация включает в себя стандартные схемы обмена сообщениями, реализованные провайдерами-брокерами уведомлений, вместе с операционными требованиями, налагаемыми на провайдеров и заказчиков брокерских уведомлений. Спецификация WS-Topics устанавливает механизм для организации и классификации разделов уведомлений. Здесь определяются три диалекта описания разделов, которые могут быть использованы в сообщениях "заказ на подписку" и других компонентах системы WS-Notification. Далее в WS-Topics специфицируется модель XML для описания метаданных, ассоциированных с разделами.

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

  1. создание ресурса, обладающего состоянием, с его идентификацией [26] и интерфейсом службы;

конкретный сценарий показан на Рис.10, где определены три компьютерные системы, обладающие состоянием, с такими элементами состояния, как память, версия CPU, скорость шины и т. д. Эти ресурсы являются ресурсами с состоянием по своей природе, и их идентификация осуществляется менеджером времени исполнения в процессе их создания. Кроме того, для этих ресурсов определена Web-служба с информацией о крайней точке, кодированной с помощью спецификации WS-Addressing. Идентификация каждого ресурса является уникальной в домене связанной с ним Web-службы, но совершенно не обязательно уникальной в глобальном смысле;

  2. заказчики служб взаимодействуют с ресурсами, обладающими состоянием, через шаблон неявного ресурса;

заказчик служб может взаимодействовать с ресурсом, обладающим состоянием, с помощью контекста, установленного спецификацией WS-Addressing и соответствующими свойствами ссылки. В ссылке на крайнюю точку содержится сетевой адрес (логический или физический) ресурса Web-службы. Компонента wsa:свойства-ссылки (wsa:ReferenceProperties) содержит дополнительную информацию о ресурсе.

Упомянутый выше шаблон взаимодействия с ресурсом является неявным. Таким образом, заказчик не должен указывать точную идентификацию ресурса в теле сообщения заказа; вместо этого контекст устанавливается в заголовках сообщений, как это предписывается свойствами ссылки EPR. Результирующее SOAP-сообщение показано на Рис.11.

Рис.10

Рис.11

На Рис.12 показана конвергенция стандартов грид-служб и Web-служб. Технологические расхождения и различия программных моделей сокращаются с помощью модели сближения стандартов, развивающейся по направлению к созданию общей инфраструктуры. Это проявилось в таких ключевых сферах, как расширенные спецификации Web-служб, WSDL и WSRF.

Рис.12

Далее мы рассмотрим новый набор стандартов, введённых к настоящему времени, для создания грид-служб и использующих упомянутые выше шаблоны неявных ресурсов для описания ресурсов с состоянием. Перечислим спецификации WSRF, являющиеся предметом нашего обсуждения: Свойства WS-ресурса (WS-ResourceProperties). Время жизни WS-ресурса (WS-ResourceLifetime) и Группы WS-ресурсов (WS-ServiceGroup). Мы детально исследуем эти новые стандарты и обсудим их взаимосвязь с концепцией грид-служб.

Спецификация WS-ResourceProperties

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

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

Рис.13

На Рис.14 показан фрагмент кода XML, где ресурс “Computer System” показывает свойство "текущая память" ("current_memory"). Это свойство определено как часть элемента глобальной XML-схемы (например, "Получить системную память" ("GetComputerSystemMemory") и связано со значением доступного атрибута WSDL:тип порта.

Рис.14

Заказчик службы может получить значение этого свойства от ресурса в момент исполнения в виде XML-документа, используя операции "Заказ на получение свойств ресурса" ("GetMultiplyResourcePropertiesRequest") или "Заказ на получение свойства на получение свойства ресурса" приведено во фрагменте кода XML на Рис.15. Этот заказ интерпретируется Web-службой, которая затем возвращает значение соответствующего свойства от нижележащего ресурса. Заказчик службы может добавлять, удалять или обновлять значение свойства ресурса. Результат заказчик получает в виде кода XML, как показано ни Рис.16.

Рис.15

Рис.16

Наконец, эта спецификация обеспечивает возможности для запросов путем посылок запросных выражений (query expressions) с целью получения фрагментов свойств ресурсов. Формат таких запросов показан на Рис.17. Атрибут "диалект" определяет язык задания запросов (XPath, XQuery или SQL), а запросное выражение определяет собственно запрос к свойствам ресурса.

Рис.17

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

Спецификация WS-ResourceLifetime

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

Эта спецификация определяет набор свойств службы и два типа шаблонов сообщений для уничтожения службы. Свойствами службы, используемыми для управления её временем жизни, являются Исходное Время Завершения (InitialTerminationTime), Текущее Время (CurrentTime) и Время Завершения (TerminationTime). Перечислим шаблоны сообщений для управления временем жизни и уничтожения службы:

  1) немедленное уничтожение (immediate destruction) – ресурс, созданный с помощью шаблона неявного ресурса, может послать службе сообщение DestroyRequest (запрос на уничтожение) для немедленного уничтожения ресурса. Формат такого сообщения показан на Рис.18. Web-служба, принимающая это сообщение, может либо уничтожить неявный ресурс, либо вернуть сообщение об отказе;

  2) планируемое уничтожение (sheduled destruction) – ресурс, созданный с помощью шаблона неявного ресурса, может, посредством реализации интерфейса планируемого завершения (sheduled termination), принять сообщение Установка времени завершения (SetTerminationTimeRequest) для уничтожения ресурса после указанного в сообщении периода времени.

Спецификация WS-ResourceLifetime также обеспечивает возможность получения заказчиком службы текущего времени службы (используя свойство ресурса Текущее время).

Рис.18

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

Спецификация WS-ServiceGroup

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

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

В следующем разделе мы сравним существующую спецификацию OGSI с концепциями, введёнными WSRF.

Сравнительная характеристика WSRF и OGSI

В таблице 1 [27] показано отображение "один в один" концепций OGSI и решений, принятых в WSRF. Наиболее заслуживающие внимания аспекты такого сравнения таковы:

  • шаблон неявного ресурса вводит концепцию ресурса с состоянием (WS-Ресурса) и заменяет мандатный интерфейс грид-службы, определённый в спецификации OGSI. Это даёт возможность управления всеми видами ресурсов с состоянием, включая грид-службы, с помощью обычного набора Web-служб;

  • концепции Дескриптора грид-службы (Grid Service Handle, GSH) и Ссылки на грид-cлужбу (Grid Service References, GSR), введенные спецификацией OGSI, заменены стандартом WS-Addressing для Web-служб. GSH и GSR, кодированные с помощью спецификации WS-Addressing, используют EPR и свойства ссылки. Это является наиболее значимым вкладом WSRF;

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

Таблица 1. Сравнение концепций OGSI и WSRF.

Таблица 3. Грид-стандарты и требования к ним