от 16 октября 2014 г. N 1344-ст
Information technologies. The open grid services
architecture. Terms and definitions
1 РАЗРАБОТАН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО "ИАВЦ"), Федеральным государственным бюджетным учреждением науки Институтом радиотехники и электроники им. В.А. Котельникова РАН (ИРЭ им. В.А. Котельникова РАН)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
5 ПЕРЕИЗДАНИЕ. Октябрь 2018 г.
Установленные в стандарте термины расположены в систематизированном порядке, отражающем систему понятий в Грид-среде.
Для каждого понятия установлен один стандартизованный термин.
В тех случаях, когда в термине содержатся все необходимые и достаточные признаки понятия, определение не приводится, и вместо него ставится прочерк.
В стандарте приведены иноязычные эквиваленты стандартизованных терминов на английском (en) языке.
Стандартизованные термины набраны полужирным шрифтом, их краткие формы - светлым.
Настоящий стандарт устанавливает термины и определения (буквенные обозначения) понятий из области архитектуры, предназначенной для обеспечения интероперабельности в Грид-среде <1>.
Настоящий стандарт не распространяется на ИТ-технологии, не связанные с Грид-средой.
Настоящий стандарт предназначен для заказчиков, разработчиков, поставщиков, потребителей, а также персонала сопровождения информационных систем, программного обеспечения и услуг в Грид-среде. Термины, установленные настоящим стандартом, обязательны для применения во всех видах документации и литературы в области Грид-технологий, входящих в сферу работ по стандартизации и (или) использующих результаты этих работ.
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3.1 Термины и определения согласно международному источнику GFD-I.120 |
3.1.1 архитектура мониторинга Грид-систем; GMA: Архитектура, которая описывает комплекс компонентов, реализующих мониторинг и полностью определяющих характеристики Грид-платформ. | en Grid monitoring architecture (GMA) |
3.1.2 базовая структура протоколов Грид: Минимальный набор служебных интерфейсов, которые должны быть созданы для реализации OGSA <1> Грид. | en Grid fabric |
Примечание - Базовая структура протоколов Грид известна также как сервисы инфраструктуры OGSA. | |
3.1.3 базовый профиль OGSA: Профиль в формате WS-Interoperability (WS-I), который определяет рекомендованное применение стандартов уровня инфраструктуры для Грид-сценариев. | en OGSA basic profile |
Примечание - службы OGSA должны соответствовать одному такому профилю, чтобы, когда это необходимо, реализовать свойство инфраструктуры. | |
3.1.4 брокер сообщений: Посредник в обслуживании сообщений. | en message broker |
Примечание - Брокер сообщений может исполнять дополнительные функции - такие, как фильтрация и хранение/пересылка. | |
3.1.5 бронирование: Процесс бронирования ресурсов для будущего применения в запланированной задаче. | en reservation |
3.1.6 вариант использования: Сценарий, по которому обеспечивается взаимодействие агента или объекта с системой и/или ее составляющими и ожидаемым поведением участников для достижения в результате определенной цели. | en use case |
3.1.7 веб-сервис: Программное обеспечение, разработанное для обеспечения интероперабельности приложения в сети. | en web service |
3.1.8 виртуальная организация; VO: Набор из отдельных лиц и/или организаций, имеющих прямой доступ к компьютерам, программному обеспечению, данным и другим ресурсам для совместного разрешения проблем или для других целей. | en virtual organization (VO) |
3.1.9 виртуализация: Создание виртуальной среды, которая функционирует при помощи удаленного доступа по согласованному пользователями протоколу. | en virtualization |
3.1.10 возврат: Практика оплаты отдельными подразделениями потребленных ИТ-ресурсов внутри организации. | en chargeback |
3.1.11 восстановление после сбоя: Восстановление сервиса или другого объекта в предписанном состоянии. | en failure recovery |
3.1.12 выделение: Процесс присвоения набора ресурсов для выполнения задачи. | en allocation |
3.1.13 высвобождение ресурса: Действие по возвращению занятого ресурса в общий фонд доступных ресурсов. | en release |
3.1.14 генератор набора кандидатов: Сервис в EMS, который определяет набор ресурсов рабочей среды, на которых выполняется обслуживание или решается задача. | en candidate set generator |
3.1.15 грид, грид-вычисления: Система, образованная с помощью интеграции, виртуализации и управления сервисами и ресурсами в распределенной, гетерогенной среде. | en grid, grid-computing |
Примечания 1 Система поддерживает объединение пользователей и ресурсов (виртуальных организаций) параллельно традиционным административным и организованным областям (доменам - реальным организациям). 2 Любая Грид - это среда вычисления, комбинирующая распределенные объединения ресурсов, на которых приложения или сервисы могут быть динамически собраны и пересобраны с целью снижения расходов, повышения эффективности, возможности быстрой сборки в новом качестве, мощности (показателей назначения), масштабирования, готовности и использования. 3 Участвующие ресурсы часто собраны из некоторого числа небольших объединений, которыми ресурсы уже используются, и по этой причине Грид-система имеет тенденцию к гетерогенности. | |
3.1.16 грид-сервис: Веб-сервис, который создан для операций в Грид-среде и соответствует требованиям той (тех) Грид(ов), в которой(ых) он задействован. | en grid-service |
3.1.17 доверие: Готовность к действиям с ожиданием полезных результатов, основанная на утверждениях других сторон. | en trust |
3.1.18 достижение уровня сервиса: Акт соответствия цели предустановленным уровнем сервиса. | en service level attainment |
3.1.19 единица работы: Запрос пользователя для выполнения OGSA приложения или наследуемой программы. | en Unit of work |
3.1.20 е-Наука: Научные исследования, интенсивно использующие информационно-коммуникационные технологии, которые выполняются в сугубо распределенной сетевой среде и которые требуют Грид-вычислений. | en e-Science |
3.1.21 задача: Определенная пользователем задача, которая с помощью планировщика посылается на исполнение некоторой подсистеме. | en job |
3.1.22 идентификатор: Атрибут, который позволяет один объект отличать от всех других. | en identity |
3.1.23 извещение: Коммуникационное сообщение, содержащее подробности какого-либо события заинтересованному участнику. | en notification |
3.1.24 интернационализированный идентификатор ресурса; IRI: Расширение синтаксиса URI на знаки, отличающиеся от латиницы. | en internationalized resource identifier (IRI) |
3.1.25 интерфейс: Спецификация действий, которые сервис предлагает своим клиентам. | en interface |
3.1.26 интерфейс передачи сообщений; MPI: Стандартный интерфейс прикладной программы, обеспечивающий пересылку сообщений библиотек. | en message passing interface (MPI) |
Примечание - MPI обычно используют для координации действий параллельных приложений. | |
3.1.27 интерфейс управляемости: Интерфейс, посредством которого происходит управление ресурсом. | en anageability interface |
3.1.28 информационная модель: Обобщение и представление объектов в управляемой среде, включая свойства, действия и взаимосвязи. | en information model |
Примечания 1 Информационная модель не зависит от протокола, репозитория и платформы и может быть представлена на формализованном языке, подобном UML, или на естественном языке - таком, как английский. 2 Любая информационная модель полезна для разработчиков и администраторов в качестве руководства по функциональности. | |
3.1.29 информационные сервисы OGSA: Свойство OGSA, обеспечивающее доступ к информации о приложениях, ресурсах и сервисах. | en OGSA information services |
3.1.30 источник сообщения: Сервис, направляющий сообщение | en Massage producer |
3.1.31 качество обслуживания: Мера достигнутого уровня обслуживания: безопасность, пропускная способность сети, среднее время ответа или наличие сервиса. | en quality of service (QoS) |
3.1.32 клиент: Компонент программного обеспечения или добавленный блок программы в сервис-ориентированной архитектуре, делающие доступным свойство, предложенное сервисом. | en Client |
3.1.33 композиция сервисов: Объединение множества малых сервисов в большие сервисы. | en service composition |
3.1.34 компонент: Заменяемая часть системы, передающая свое содержимое и планирующая действия согласно определениям публичного интерфейса. | en component |
3.1.35 композиция ресурсов: Процесс конфигурирования ресурсов с целью удовлетворения определенных требований задачи, для которой ресурсы были выделены. | en resource configuration |
Пример - Композиция ресурсов может включать установку параметров и политики для промежуточного программного обеспечения, операционной системы, прошивку и аппаратные средства. | |
3.1.36 концептуальная модель ресурса: Набор спецификаций, касающихся совокупности веб-сервисов с учетом состояния ресурсов. | en WS-resource framework |
3.1.37 межпроцессное взаимодействие; IPC: Передача сообщений посредством разделяемой памяти (включая разделяемые файлы) или TCP-протокол. | en intercrosses communication (IPC) |
3.1.38 менеджер задач: Служба (сервис), которая управляет набором из одной или более постановок задачи, возможно структурированной, или неструктурированной. | en job manager |
Примечания 1 Менеджер задач включает все аспекты исполнения, включая взаимодействие с сервисами (службами) планирования исполнения, обеспечивающей системой, контейнерами и сервисами мониторинга. 2 Менеджер задач может иметь дело со сбоями и перезапусками, может планировать задания для ресурсов, может накапливать соглашения, бронирование и данные сервиса задачи. | |
3.1.39 менеджер ресурсов: Управляющая программа, которая выполняет одну или более функций по управлению ресурсом. | en resource manager |
3.1.40 менеджер уровня сервиса; SLM: Управляющая программа, гарантирующая достижение цели уровнем сервиса для набора ресурсов. | en service level manager (SLM) |
3.1.41 метаданные: Данные о данных. | en metadata |
Примечание - Метаданные могут содержать ссылки на схемы, источник и качество информации. | |
3.1.42 модель данных: Разметка содержимого информационной модели по форме, смоделированной для конкретного типа репозитория, протокола, платформы и т.д., и представленная информационной моделью в соответствии со спецификацией набора механизмов для представления, организации, хранения и управления данными. | en data model |
Примечания 1 Типичны три части: сборник структур данных, таких как списки, таблицы, и донесения; сборник операций, какие могут быть совершены со структурами, таких как поиск, обновление и накопление; сборник правил соединения, которые определяют правомочность значений или изменения состояния (операции над значениями). 2 Модель данных необходима для создания баз данных. Инициативная группа WBEM служит примером воплощения CIM в качестве модели данных. | |
3.1.43 модель ресурса: Информационная модель или модель данных. | en resource model |
3.1.44 наследование/наследуемая файловая система/наследуемая программа: Описание ранее существовавших программ или файловых систем в OGSA, которые должны быть допущенными для использования Гридом до их применения в качестве Грид-ресурса. | en legacy, legacy file system, legacy program |
3.1.45 наименование: Атрибут, используемый для идентификации некоторого объекта. | en name |
Примечание - В OGSA различают три типа наименований: наименования, ориентированные на имя человека, абстрактное наименование и наименования адресного типа. | |
3.1.46 обеспечение и развертывание: Перевод ресурса или набора ресурсов в такое состояние, когда они становятся доступными для использования. | en provisioning (and deployment) |
Примечание - В зависимости от контекста операции, процесс подготовки может включать в себя такие мероприятия, как резервирование и выделение. | |
3.1.47 обнаружение ресурса: Процесс поиска ресурсов, удовлетворяющих объявленным критериям. | en resource discovery |
| en entity |
Примечание - Например, в OGSA объект может быть ресурсом или службой. | |
3.1.49 оркестровка: Описание способов, в которых бизнес-процессы построены из веб-служб и других бизнес-процессов, и как эти процессы взаимодействуют. | en orchestration |
Примечание - Оркестровка тесно связана с понятиями "Хореография" и "Рабочий процесс". | |
3.1.50 отношения доверия: Установленная иерархия, определяющая, кому предоставить право действовать в разных областях. | en trust relationships |
Примечание - Власти можно полностью доверять, например, любое распоряжение власти будет принято в качестве основы для действия или доверие может быть ограниченным, в этом случае распоряжения принимаются в определенном диапазоне. | |
3.1.51 план: Разметка (связь) между сервисами и ресурсами, возможно, с временными ограничениями. | en schedule |
3.1.52 планирование: Процесс бронирования ресурсов для будущего применения плановой задачей. | en scheduling |
3.1.53 политика: Заявления, правила или утверждения, которые определяют правильное или ожидаемое исполнение объектом. | en policy |
Примечание - Например, политика авторизации может указать правильный доступ к правилам управления доступом для программного компонента. | |
3.1.54 получатель сообщения: Сервис, который получает сообщение. | en message consumer |
3.1.55 потребитель сервиса: - | en service requestor |
Примечание - В некоторых случаях потребитель сервиса может относиться к человеку, организации или системе вышестоящего уровня, которые пользуются сервисом, предложенным поставщиком сервиса. | |
3.1.56 послать извещение: Передача сообщения с уведомлением. | en notify |
3.1.57 посредник: Сервис в информационных сервисах OGSA, который отделяет взаимодействующие конечные точки. | en intermediary |
3.1.58 поставщик сервиса: - | en service provider |
Примечание - В некоторых случаях поставщик сервиса может относиться к человеку, организации или к системе вышестоящего уровня, ответственным за предоставление сервиса, доступного для запрашивающих. | |
3.1.59 протокол передачи гипертекста; HTTP: Протокол на основе текста, который обычно работает в сети Интернет. | en hypertext transfer protocol (HTTP) |
3.1.60 протокол передачи гипертекста с шифрованием: Протокол, использующий для шифровки язык SSL. | en HTTPS |
3.1.61 профиль: Нормативный документ, который помогает разработать интероперабельное программное обеспечение путем предоставления руководства по применению набора спецификаций или других профилей. | en profile |
3.1.62 путь к файлу: Строка в директории. | en file path |
Пример - /home/mydir/data. | |
3.1.63 рабочая среда: Любая среда, в которой может исполняться задача. | en hosting environment |
Пример - Среда исполнения Веб-сервисов, какая-либо операционная система или просто контейнер. | |
3.1.64 реальная организация: Компьютеры и ресурсы, которые образуют административный и организационный ресурс. | en real organization |
3.1.65 реестр: Узаконенное централизованно-контролируемое хранилище информации. | en registry |
Примечания 1 Веб-сервисы используют реестры для рекламы своего существования и для описания их интерфейсов и другие атрибуты. 2 Веб-сервисы используют реестры очереди клиентов на выделение необходимых сервисам и открытие атрибутов. | |
3.1.66 регистрационная запись: Запись события с целью его сохранения сервисом регистрации. | en log record |
3.1.67 ресурс: Физический или логический объект; применение или действие вычисления приложения или среды. | en resource |
Примечания 1 В OGSA Грид-ресурсы получают с помощью сервисов. 2 В контексте Грид термин включает объекты, которые определяют свойства или производительность (например, серверы, сети, диски, запоминающее устройство, приложения, базы данных, IP-адреса и лицензии на программное обеспечение). 3 Динамические объекты, такие как процессы, задания на печать, результаты запросов к базам данных и виртуальные организации могут также быть представлены и обрабатываться как ресурсы. | |
3.1.68 ресурс хранилища: Ресурс, который обеспечивает физическую или логическую способность к хранению. | en storage resource |
Примечание - Примеры включают в себя устройства хранения данных, технику хранения, дисковые тома и файловые системы. | |
3.1.69 самоадминистрирование: Свойство, на основе которого компоненты системы, в том числе аппаратные, такие как компьютеры, сети и устройства хранения данных и программного обеспечения и компонентов, таких как операционные системы и бизнес-приложения, являются самоконфигурирующимися, самовосстанавливающимися и самооптимизирующимися. | en self management |
3.1.70 сбой: Состояние, в котором оказалась служба или некий объект, отличающееся от предписанного. | en failure |
3.1.71 свойство: Один или несколько скомпонованных сервисов, обеспечивающих требуемую Грид-функцию. | en capability |
3.1.72 сервис: Объект, составленный из одного или более компонентов программного обеспечения, которое обеспечивает функциональность в ответ на запросы клиентов. | en service |
Примечание - Сервис часто - часть сервис-ориентированной архитектуры, и участвует в реализации одного или более свойств. Например, сервис высокого уровня, такой как электронный книжный магазин, может состоять из нескольких сервисов более низкого уровня, таких как инвентаризация, проверка и отслеживание заказов. | |
3.1.73 сервис-ориентированная архитектура; SOA: Архитектурный стиль построения надежных распределенных систем, которые обеспечивают функциональность, как сервисы, с дополнительным акцентом на слабую связь между взаимодействующими сервисами. | en service-oriented architecture (SOA) |
Примечание - SOA может быть основана на веб-сервисах (которые обеспечивают основную интероперабельность), но вместо веб могут быть использованы другие технологии. | |
3.1.74 сервис передачи сообщений: Сервис, который передает послание от источников получателям послания. | en messaging service |
3.1.75 сервисы управления исполнением; OGSA-EMS: Свойство OGSA, касающееся проблем подтверждения и администрирования и завершения блоков заданий. | en execution management services (OGSA-EMS) |
3.1.76 служба планирования исполнения; EPS: Служба в OGSA-EMS, которая сопоставляет задание ресурсу для целей планирования. | en execution planning service (EPS) |
3.1.77 служба регистрации и протоколирования: Посредник, который служит в качестве хранилища записей регистрации. | en log service, logging service |
3.1.78 событие: Все, что происходит в/или по отношению к IT-системам, что является потенциально интересным персоне, части той же системы или какой-то внешней системе, и может рассматриваться как событие. | en event |
Примечание - Информация о событии может регистрироваться в виде записи о регистрации и сохраняться в службе регистрации. Запись может быть передана другим заинтересованным службам в виде посылки с извещением. | |
3.1.79 соглашение: Динамически учреждаемые и управляемые взаимоотношения между двумя абонентами. | en agreement |
Примечания 1 Объектом взаимоотношений является обмен сервисами между абонентами в контексте соглашения. 2 Администрирование взаимоотношения достигается с помощью согласования соответствующих ролей, прав и обязательств абонентов. 3 Соглашение может специфицировать не только функциональные свойства для идентификации и создания сервисов, но и нефункциональные свойства сервисов - такие, как показатели назначения и доступность. 4 Объекты могут динамически учреждать и администрировать соглашения посредством интерфейсов Веб-сервиса. | |
3.1.80 соглашение об уровне сервиса: Договор между поставщиком и потребителем, который определяет уровень сервиса, ожидаемый в течение срока действия договора. | en service level agreement (SLA) |
Примечания 1 SLA обычно включает один или более уровней обслуживания целей. 2 Соглашения об уровне сервиса используются поставщиками и клиентами, а также внутри ИТ-магазинов и их конечных пользователей. Они могли бы указать требования к доступности и времени отклика для нормальной эксплуатации и для решения проблем (сеть не работает, техническая неисправность и др.), и они могут определять платежи и/или штрафы, связанные с покрытием или невыполнением согласованных критериев. | |
3.1.81 состояние: Состояние объекта, являющееся комбинированным значением его индикаторов состояния. | en state |
Примечания 1 Индикаторы состояния - те индикаторы, по которым внешние наблюдатели могут увидеть изменения состояния с течением времени. 2 Примеры включают в себя положение переключателя, цену акции или объем памяти, выделенной для процесса. Так как не все индикаторы могут быть доступны или показательны всем возможным наблюдателям, различные наблюдатели могут иметь разные взгляды на состояние объекта в данный момент времени. 3 Изменение значения индикатора является событием. | |
3.1.82 сценарий: Определенная последовательность или путь от начала до цели, происходящий в определенной среде и/или контексте. | en scenario |
Примечание - Прецедент может содержать несколько сценариев. OGSA - сценарии высокого уровня и описаны в произвольном стиле. | |
3.1.83 удостоверяющая организация: Организация, которая уполномочена удостоверять. | en trust authority |
3.1.84 управление: Процесс совершения действий: развертывание, конфигурирование, мониторинг, измерение, настройка и/или ремонт ресурса вручную или автоматически. | en management |
3.1.85 управление жизненным циклом ресурса: Процесс управления ресурсами, выделенными для исполнения задачи от момента выделения до момента выключения. | en resource lifecycle management |
3.1.86 управление ресурсами: Обобщенное представление нескольких форм управления, которые могут быть применены к ресурсу. | en resource management |
3.1.87 управляемость: Способность управлять ресурсом или наличие возможности у ресурса быть управляемым. | en manageability |
3.1.88 управляемый ресурс: Ресурс, который может быть управляем программным способом посредством интерфейса управляемости или другого механизма вроде "файла политики". | en manageability resource |
3.1.89 управляющая программа: Программа, которая управляет ресурсами. | en manager |
Примечание - Управляющая программа может привлекать, а может и не привлекать к своим действиям человека - оператора. | |
3.1.90 хореография: Шаблоны взаимодействия между службами и шаблоны для последовательностей (или несколько структур) взаимодействий. | en choreography |
Примечание - Хореография тесно связана с понятиями "Оркестровка" и "Рабочий процесс". | |
3.1.91 цель уровня сервиса: Измеримые цели, определенные в соглашении об уровне сервиса, для сервиса или для набора из одного или нескольких ресурсов. | en service level objective (SLO) |
Примечание - SLO может быть выражен в таких единицах, как среднее время ответа для репрезентативного набора типов транзакций. | |
3.1.92 язык представления описания задачи: Язык для описания представления задачи, включающий подробности требований к исполняющему сервису. | en job submission description language (JSDL) |
3.2 Термины и определения согласно межгосударственным и национальным источникам |
3.2.1 архитектура: Фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и с окружающей средой, и руководящие правила проектирования и развития системы. | en architecture |
Примечание - Термин "архитектура" определяется в стандартах системной и программной инженерии применительно к системам. | |
3.2.2 интегрированная система: Система, в которой все входящие в нее подсистемы работают по единому алгоритму, т.е. имеет единую точку управления. | en integrated system |
3.2.3 интероперабельность: Способность двух или более информационных систем или компонентов к обмену информацией и к использованию информации, полученной в результате обмена. | en interoperability |
3.2.4 интероперабельная система: Система, в которой входящие в нее подсистемы работают по независимым алгоритмам, не имеют единой точки управления, все управление определяется единым набором стандартов - профилем интероперабельности. | en interoperable system |
3.2.5 организационная интероперабельность: Способность участвующих систем достигать общих целей на уровне бизнес-процессов. | en organizational interoperability |
3.2.6 переносимость: Степень легкости, с которой прикладные программные средства и данные могут быть перенесены с одной прикладной платформы на другую. | en portability |
3.2.7 план (стратегия) развития стандартов: Документ, содержащий последовательность разработки необходимых стандартов для обеспечения интероперабельности. | en roadmap |
3.2.8 подход к достижению интероперабельности: Способ, с помощью которого решаются проблемы и преодолеваются барьеры интероперабельности. | en interoperability approach |
3.2.9 профиль интероперабельности: Согласованный набор стандартов, структурированный в терминах модели интероперабельности. | en interoperability profile |
3.2.10 реализация: Программно-аппаратная реализация конкретной интероперабельной системы в соответствии с профилем интероперабельности. | en solution |
3.2.11 семантическая интероперабельность: Способность любых взаимодействующих в процессе коммуникации информационных систем одинаковым образом понимать смысл информации, которой они обмениваются. | en semantic interoperability |
3.2.12 техническая интероперабельность: Способность к обмену данными между участвующими в обмене системами. | en technical interoperability |
3.2.13 уровень интероперабельности: Уровень, на котором осуществляется взаимодействие участников. | en interoperability concern |
3.2.14 эталонная модель интероперабельности: Развитие известной эталонной семиуровневой модели взаимосвязи открытых систем. | en interoperability reference model |