ГОСТ Р 55768—2013
и цифровая подпись, вдополнение (или вместо) безопасности транспортного уровня «точка—точка». В
дополнение к безопасности уровня сообщений интероперабельная и многокомпонентная инфраструк
тура нуждается в собственных компонентах безопасности, предоставляемых в виде сервисов.
Существуют различные способы, реализуемые для спецификации определений сервисов таких
сервисов безопасности.
Пример — Сервис авторизации СОАОГС м ож ет использовать предложенный ста н д а р т соглаш е
ний web-сервисов совм естно со стандартам и OASIS для описания формальных утверждений безопас
н о сти и описания
к
онтроля доступа. Когда и где э т о ум естно, СОАОГС будет приним ать или опреде л я
ть та
к
и е сервисы безопасности.
5.3.4 Представляющее состояние
Одной из ключевыхобластей, в которыхтребования Гридопределяютсоздание новыхспецифика
ций(таких, которыенеимеютотношенияксценариям Грид). являетсяобласть представлениясостояний
и манипулирование ими, т. е. способность моделировать, получать доступ и управлять состоянием и
соответствующимидействиями. Такие возможности играют фундаментальную роль не только в постро
ении Грид-систем, но ив управлении обычными системами вдругих областях.
Л
юбой соответствующий набор спецификаций может быть использован в качестве основы для
построения Грид-системы, удовлетворяющей требованиям СОАОГС.
5.3.5 Уведомления
В динамической Грид-среде критичным является то, что ее компоненты могут регулярно запраши
вать иполучатьуведомления об изменении состояния других компонент.
Существует необходимость использования спецификаций, определяющих механизмы уведомле
ния. которые поддерживают подписки, а также последующее уведомление об изменениях компонент
состояния.
5.3.6 Транзакции
СОАОГС не определяет механизм транзакций как таковой. Эти функции должны быть предостав
лены другим разработкам в сообществе web-сервисов.
Спецификация транзакциизависитотпроведенияконтекста транзакциивместес каждымобменом
сообщениями. Решение о том. выполнять контекст транзакции или игнорировать его, принимается
самим приложением (реализацией). Нет необходимости явно изменять подпись интерфейса для обес
печения транзакции. Описательная информациядля реализации должна включать информацию о том.
как реализация будетобрабатывать контексттранзакции.
Сами клиенты определенных сервисов должны принимать решение об обеспечении возможности
конкретной реализации совершатьтранзакцию.
5.3.7 Гармонизация
Многие сервисы СОАОГС могут бытьчастично или полностью построены с использованием вызо
вовдругих сервисов. Один изпримеров — менеджер задач. Есть целый ряд механизмов, которые могут
быть использованы для этой цели:
- Хореография — описывает необходимые закономерности взаимодействия между сервисами и
шаблоныдля последовательностей (илидругих структур) взаимодействий.
- Оркестровка — описывает, каким образом бизнес-процессы строятся на основе web-сервисов и
других бизнес-процессов, икакэти процессы взаимодействуют.
- Технологический процесс — определяетструктуру взаимодействия бизнес-процесса, не обяза
тельно соответствующего фиксированному набору бизнес-процессов.
Все эти взаимодействия могут быть междусервисами, расположеннымив пределаходногоцентра
обработкиданных или на целом ряде различных платформ и реализаций влюбом месте.
СОАОГС не определяет новые механизмы в этой области.
5.3.8 Обеспечение интероперабельности: профили СОАОГС
Указанные ранееспецификации представляют собой лишьмалую частьиз быстро растущего чис
ла спецификацийweb-сервисов, многие изкоторыхбудутиспользованы при спецификациииразработке
компонентовСОАОГС.
Общим свойствомавторов спецификацийявляетсястремлениеразрабатыватьих гибкими, напри
мер. делая разработку реализации некоторых сервисов опциональной. Хотя такой подход может ока
заться полезным для разработчиков, в некоторых сценариях он уменьшает вероятность того, что
компоненты, основанные на различных реализациях, будут полностью интероперабельны.
Поскольку интероперабельность является основным условием для компонент Грид. основанной
на стандартах, указанный ранее подход может представлять проблему.
13