Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

50 страниц

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

  Скачать PDF

Идентичен ISO/IEC 18384-1:2016

Действие завершено 01.09.2018

Оглавление

1 Область применения

2 Термины и определения

3 Сокращения

4 Обозначения

4.1 Общие положения

4.2 UML

4.3 Диаграммы «сущность-связь»

4.4 Циклические диаграммы

4.5 Диаграммы потоков

5 Соглашения

6 Соответствие

7 Концепции SOA

7.1 Введение в SOA

7.2 Концепции

7.3 Сквозные аспекты

8 Архитектурные принципы SOA

8.1 Определение архитектурных принципов

8.2 Функциональная совместимость — синтаксически и семантически

8.3 Описание службы

8.4 Повторное использование службы

8.5 Обнаружение службы

8.6 Позднее связывание

8.7 Компонуемость

8.8 Автономность

8.9 Слабое связывание

8.10 Управляемость

Приложение А (справочное) Структура управления SOA

Приложение В (справочное) Управление и проблемы безопасности

Библиография

Показать даты введения Admin

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

ИСО/МЭК 18384-1-

2017

Информационные технологии

ЭТАЛОННАЯ АРХИТЕКТУРА ДЛЯ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ (SOA RA)

Ч а с т ь 1

Терминология и концепции SOA

(ISO/IEC 18384-1:2016, IDT)

Издание официальное

Москва

Стандартинформ

2017

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 5 сентября 2017г. № 1012-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 18384-1:2016 «Информационные технологии. Эталонная архитектура для сервис-ориентированной архитектуры (SOA RA). Часть 1. Терминология и концепции SOA» (ISO/IEC 18384-1:2016 «Information technology — Reference Architecture for Service Oriented Architecture (SOA RA) — Part 1: Terminology and concepts for SOA», IDT).

ИСО/МЭК 18384-1 разработан подкомитетом ПК 38 «Облачные вычисления и распределенные платформы» Совместного технического комитета СТК 1 «Информационные технологии» Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК)

5    ВВЕДЕН ВПЕРВЫЕ

6    Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе « Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случав пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ. 2017

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

ГОСТ Р ИСО/МЭК 18384-1—2017

QoS — качество обслуживания;

RA — эталонная архитектура;

REST — передача состояния через представление1*;

RPC — удаленный вызов процедур;

SLA — соглашение об уровне обслуживания;

SOA — сервис-ориентированная архитектура;

SOAP — стандартный протокол обмена структурированными данными в сообщениях;

SQL — язык структурированных запросов;

UML — унифицированный язык моделирования;

VPN — виртуальная частная сеть;

WSDL — язык описания веб-сервисов;

WSRP — веб-службы для удаленных портлетов;

XML — расширяемый язык разметки.

4    Обозначения

4.1    Общие положения

Ниже приведена инструкция по интерпретации диаграмм.

4.2    UML

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

4.3    Диаграммы «сущность-связь»

Диаграммы «сущность-связь» (Entity relationship) (такие, как приведенные на рисунках 1 и 2). состоящие из прямоугольников, линий, стрелок и обведенных кружками номеров, следует интерпретировать по следующим правилам;

-    блоки — метамодельные понятия, уровни, стандартные блоки архитектуры, возможности или компоненты;

-    стрелки — отношения между понятиями метамодели; односторонние стрелки показывают направление отношения; двойные стрелки указывают на то. что отношения двунаправленны:

-    отношения имеют имена и представлены как маркированные строки или стрелки, число элементов. входящих в отношение не подразумевается;

-    число элементов, входящих в отношение, обозначается традиционным образом с использованием математической нотации (* = = 0..*; 0..1 = = необязательный и только 1:1 = = обязательный, в соответствии с ИСО/МЭК 15474-1).

4.4    Циклические диаграммы

Циклические диаграммы с состояниями показывают эволюцию состояния или жизненного цикла в направлении почасовой стрелке. Пример циклической диаграммы приведен на рисунке 10.

4.5    Диаграммы потоков

Диаграммы потоков часто используются в качестве примеров. Диаграммы следует интерпретировать по следующим правилам:

-    прямоугольники представляют уровни, стандартные блоки архитектуры или компоненты;

-    стрелки показывают направление потока между прямоугольниками;

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

Примеры диаграмм потоков приведены на рисунках 5 и 6.

5    Соглашения

Настоящая эталонная архитектура определена в трех частях комплекса стандартов ИСО/МЭК 18384. Настоящий стандарт определяет терминологию и концепции для сервис-ориентированной архитектуры. Прежде чем читать или использовать ИСО/МЭК 18384-2 и ИСО/МЭК 18384-3, важно понимать термины и концепции, определенные в настоящем стандарте. ИСО/МЭК 18384-2 определяет эталонную архитектуру для решений SOA. Он описывает метамодель, ряд уровней для мно-

1 Технология адресации оконечных точек веб-сервисов (примечание переводчика).

7

гоуровневой архитектуры и ряд общих типов служб. ИСО/МЭК 18384-3 определяет онтологию SOA с более формальным выражением концепций SOA и отношений между ними. Терминология настоящего стандарта соответствует онтологии, приведенной в ИСО/МЭК 18384-3.

Настоящий стандарт можно читать последовательно или использовать в качестве справочника. Стандарт содержитсловарьтерминов, подробное введение и концепции SOA В ИСО/МЭК 18384-2 дается краткое введение в SOA. После введения представлен высокоуровневый обзор всех десяти уровней и типов служб, определенных в этом стандарте. Далее следуют определения и объяснение метамодели, используемой в эталонной архитектуре SOA. Метамодель определяет уровень, возможности и концепции СБА. а также другие логические концепции. Каждый СБА и каждая возможность определены единственным образом в каждом уровне. Для выполнения требований архитектуры возможности и СБА могут потребовать возможности и СБА, определенные для других уровней. Уровни, возможности и СБА. определенные в этом стандарте, являются логическими элементами, и любое упоминание логических элементов вида «выполняет)», «поддерживает» или «взаимодействует» означает, что при разработке решения SOA физическая реализация возможностей и СБА в действительности «выполняет», «поддерживает» или «взаимодействует».

6    Соответствие

Комплекс стандартов ИСО/МЭК 18384 содержит три части, требования к соответствию для которых различаются:

a)    терминология и концепции — соответствие только терминам и точное следование семантике в определениях:

b)    эталонная архитектура для решений SOA — соответствие только семантике метамодели и используемых уровней. СБА или возможностей:

c)    онтология SOA — соответствие для приложений OWL или иных приложений (не-OWL).

Соответствие данной части ИСО/МЭК 18384 определено следующим образом.

Если некоторый документ, продукт или стандарт заявляет о соответствии, то термины из данной части ИСО/МЭК 18384 должны использоваться с той же семантикой, что и в настоящих определениях.

Принципы и концепции приведены для объяснения и не предназначены для исполнения.

7    Концепции SOA

7.1 Введение в SOA

Сервис-ориентированная архитектура (сокращенно SOA) (см. 2.48) — это архитектурный стиль, который поддерживает ориентированность на службы (см. 2.46) и является парадигмой для бизнеса и ИТ. Данный архитектурный стиль предназначен для разработки систем с точки зрения служб, доступных через интерфейс, и результатов действий этих служб. Как определено в 2.20. служба — это логическое представление ряда действий, который имеет определенные результаты, является автономным, может быть составлен из других служб и является «черным ящиком» для потребителей службы.

Аналогично другим архитектурным стилям SOA:

-    предъявляет уникальные требования к инфраструктуре системы;

-    имеет реализации, зависящие от окружения, ограниченные или разрешенные контекстом и описываемые в этом контексте;

-    рекомендует руководство ИТ, системами и корпоративным лицензированием;

-    имеет бизнес-решения, предназначенные для отражения реальной деятельности бизнеса;

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

Кроме того, SOA имеет ряд характеристик, которые выделяют его среди других архитектурных стилей, в первую очередь:

a)    SOA способствует использованию открытых стандартов и интерфейсов для достижения функциональной совместимости и независимости от местоположения;

b)    службы и процессы разработаны явным образом для функционирования как внутри организации. так и между организациями;

c)    SOA требует четких описаний предлагаемой службы;

d)    службы и процессы разработаны таким образом, чтобы отражать реальную деятельность бизнеса;

8

ГОСТ Р ИСО/МЭК 18384-1—2017

e)    представление службы использует бизнес-описание для задания контекста (т. е. бизнес-процесс, цель, правило, политика, интерфейс службы и компонент службы);

f)    SOA требует надлежащего руководства представлением и реализацией службы;

д) композиция служб используется как средство реализации бизнес-процессов;

h) SOA устанавливает критерии, позволяющие потребителям служб определять, была ли служба правильно и полностью выполнена в соответствии с описанием службы.

В рамках SOA «служба» является основным элементом для сборки и интеграции информационных систем, которые способны удовлетворять различным требованиям при решении той или иной задачи. Служба с точки зрения бизнеса — это представление результатов бизнес-процессов; служба с точки зрения ИТ — реализация этих бизнес-процессов средствами ИТ. Деятельности по разработке решения SOA могут быть внутренними для организации (например, развертывание службы), совместными между рядом предприятий (например, вызовы службы и хореографии службы) или совместными мероприятиями для поддержания жизнеспособности экосистемы службы (например, публикации новых служб).

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

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

Следует отметить, что концепции SOA, определенные в настоящем стандарте, применимы к разработке программного обеспечения и могут также применяться в системном проектировании для формализации систем, основанных на службах (например, сложных систем, федеративных систем, системы систем (system of systems), архитектур уровня предприятия).

7.2 Концепции

7.2.1    Роли

7.2.1.1    Обзор

В целом роль определяется рядом действий, которые служат общей цели. Когда сущности назначается роль или она принимает некоторую роль, она выполняет действия этой роли. Определение роли включает в себя указание, все ли действия являются обязательными и когда они выполняются. Поставщики службы и потребители службы являются фундаментальными ролями в сервис-ориентированной архитектуре. Экосистема SOA включает в себя службы, предоставляющие функциональность, потребителей службы, которые взаимодействуют со службами, и поставщиков службы, которые разрабатывают и размещают службы для потребителя. Однако роли поставщиков службы и потребителей службы охватывают целый спектр действий и могут выполняться различными сторонами, ответственными за различные действия, т. е. в дальнейших обсуждениях сторона, которая может нести ответственность за функционирование, может не нести контрактной ответственности, и наоборот. Кроме того, сторона, исполняющая роль поставщика службы водном контексте, может исполнять роль потребителя службы в другом. Далее термин «поставщик службы» используется для указания на сущность, выполняющую действия, связанные с ролью поставщика службы; термин «потребитель службы» —для указания на сущность, выполняющую действия, связанные с ролью потребителя службы.

7.2.1.2    Поставщики службы

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

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

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

9

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

-    разработку служб: процессы жизненного цикла для моделирования и создания реализаций служб, одним из которых является реализация службы (см. концепции жизненного цикла службы в 7.2.8);

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

-    предоставление служб: поддержка использования развернутой службы через обмен сообщениями и необходимая поддержка экосистемы SOA для реализации функциональности службы и эффектов службы;

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

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

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

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

-    ценовую политику службы: решение о ценообразовании служб или о целесообразности их использования за иную стоимость:

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

-    определение контрактов службы: разработка соглашений о предоставлении службы и применимых аспектов управления однозначным способом, который упрощает их исполнение;

-    исполнение контрактов службы: участие в процессах, которые, вероятно, определены в контракте службы, с целью обеспечения выполнения контракта или предписанных действий по исправлению последствий нарушения контрактов;

-    управление бизнесом и контрактами: установление бизнес-правил, политики и требований к контрактам. а также обеспечение и контроль оперативного управления службами.

7.2.1.3 Потребители службы

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

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

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

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

ГОСТ Р ИСО/МЭК 18384-1—2017

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

-    обнаружение служб: поиск и анализ доступных описаний служб для идентификации служб, соответствующих потребностям (например, посредством взаимодействия с реестром/репозиторием спужб или следуя рекомендациям консультантов);

-    вызов службы: обмен сообщениями с предоставленной службой для вызова ее функциональности и реализации ее соответствующих эффектов;

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

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

-    контракт: заключение и соблюдение контрактов:

-    оплата службы: соблюдение соглашений о предоставлении службы, определяющих обмен финансовыми средствами или услугами в обмен на использование предоставленных служб;

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

-    определение контрактов службы: разработка соглашений о предоставлении службы и применимых аспектов управления однозначным способом, который упрощает их исполнение;

-    исполнение контрактов службы: участие в процессах, которые, вероятно, определены в контракте службы, с целью обеспечения выполнения контракта или предписанных действий по исправлению последствий нарушения контрактов;

-    управление контрактами: обеспечение соответствия контрактов растущим потребностям бизнеса, а также их выполнение.

Рисунок 1 — Поставщики службы и потребители службы

11

7.2.2 Службы

Как определено в настоящем стандарте, служба (см. 2.20) является логическим представлением ряда действий, который имеет определенные результаты, является автономным, может быть составлен из других служб и является «черным ящиком» для потребителей данной службы (см. ИСО/МЭК 18384-3:2016, 7.4). Для службы не имеет значения, применяется ли данная концепция к сфере бизнеса или к сфере ИТ. Служба может иметь одного или нескольких поставщиков службы или потребителей службы и производить указанные результаты.

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

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

Аналогичным образом служба может использоваться другими элементами, при этом сама служба (как чисто логическое представление) не использует другие элементы. Однако сущность, которая выполняет службу, может использовать другие элементы (и. безусловно, будет использовать в случае композиции службы).

Элемент, взаимодействующий со службой, может выполнять следующие шаги:

-    выбрать службу, с которой будет взаимодействовать (данный пункт не определяет, осуществляется ли это динамически во время выполнения или статически при проектировании и/или во время сборки);

-    выбрать элемент, который выполняет эту службу |в типичном окружение SOA этот выбор, чаще всего, делается «внутри» шины служб (см. 2.22));

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

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

Рисунок 2 — Служба и элементы SOA

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

ГОСТ Р ИСО/МЭК 18384-1—2017

Содержание

1    Область применения...................................................1

2    Термины и определения................................................1

3    Сокращения........................................................6

4    Обозначения........................................................7

4.1    Общие положения..................................................7

4.2    UML...........................................................7

4.3    Диаграммы «сущность-связь»..........................................7

4.4    Циклические диаграммы..............................................7

4.5    Диаграммы потоков................................................7

5    Соглашения........................................................7

6    Соответствие.......................................................8

7    Концепции SOA......................................................8

7.1    Введение в SOA...................................................8

7.2    Концепции.......................................................9

7.3    Сквозные аспекты.................................................24

8    Архитектурные принципы SOA............................................29

8.1    Определение архитектурных принципов...................................29

8.2    Функциональная совместимость — синтаксически и семантически..................30

8.3    Описание службы.................................................30

8.4    Повторное использование службы.......................................31

8.5    Обнаружение службы...............................................32

8.6    Позднее связывание................................................32

8.7    Компонуемость...................................................33

8.8    Автономность....................................................33

8.9    Слабое связывание................................................33

8.10    Управляемость..................................................34

Приложение А (справочное) Структура управления SOA............................35

Приложение В (справочное) Управление и проблемы безопасности.....................38

Библиография........................................................43

ГОСТ Р ИСО/МЭК 18384-1—2017

Введение

Комплекс стандартов ИСО/МЭК 18384 под общим наименованием «Эталонная архитектура для сервис-ориентированной архитектуры (SOA RA)» состоит из следующих частей:

-    Часть 1. Терминология и концепции SOA;

-    Часть 2. Эталонная архитектура для решений SOA;

-    Часть 3. Онтология сервис-ориентированной архитектуры.

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

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

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

Настоящий стандарт определяет терминологию SOA, ее технические принципы, эталонную архитектуру и онтологию SOA. Целевая аудитория настоящего стандарта включает в себя (но не ограничивается ими): организации по стандартизации, архитекторов, методологов по архитектуре, разработчиков систем и программного обеспечения, деловые круги, поставщиков служб SOA. разработчиков решений SOA и служб, а также потребителей службы SOA, которые заинтересованы в принятии и разработке SOA. Настоящий стандарт может быть использован для определения понятий SOA и руководства разработкой и управлением решениями SOA.

Комплекс стандартов ИСО/МЭК 18384 состоит из трех частей:

a)    ИСО/МЭК 18384-1 определяет терминологию, основные принципы и понятия SOA;

b)    ИСО/МЭК 18384-2 детализирует уровни эталонной архитектуры SOA. включая метамодель, возможности, стандартные блоки архитектуры, а также типы служб в решениях SOA;

c)    ИСО/МЭК 18384-3 определяет базовые понятия SOA и их отношения в онтологии.

Пользователи настоящего стандарта сочтут его полезным для понимания основ SOA. Настоящий

стандарт следует изучить, прежде чем приступить кчтению или применению ИСО/МЭК 18384-2. Для тех. кто мало знаком с SOA, следует обратиться к разделу 4 ИСО/МЭК 18384-2:2016 для получения общего понимания эталонной архитектуры для решений SOA. В остальных разделах всесторонне представлены детали стандартных архитектурных блоков и компромиссов, необходимых для решений SOA. ИСО/МЭК 18384-3 содержит онтологию SOA, которая формализует базовые понятия и термины и вводит отображения в UML и OWL. Онтология SOA может использоваться независимо или в сочетании с настоящим стандартом и ИСО/МЭК 18384-2.

В настоящем стандарте представлены и разъясняются основные концепции SOA. В нем даны определения терминов, используемых в комплексе стандартов ИСО/МЭК 18384 со специфическими значениями, которые могут отличаться или быть более точными, чем определения этих терминов, встречающиеся в основных словарях английского языка. Термины, определенные в настоящем стандарте, используются уникальным образом для SOA. Слова английского языка, используемые в обычном значении, не переопределены.

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии ЭТАЛОННАЯ АРХИТЕКТУРА ДЛЯ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ (SOA RA)

Часть 1

Терминология и концепции SOA

Information technology. Reference architecture for service oriented architecture (SOA RA). Part 1 .Terminology and concepts for SOA

Дата введения — 2018—09—01

1    Область применения

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

2    Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

2.1

агент (actor): Человек или компонент системы, взаимодействующий с системой в целом, который оказывает воздействия, вызывающие последующие действия.

[ИСО/МЭК 16500-8:1999. статья 3.1]_

2.2

архитектура (architecture): Основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.

[ИСО/МЭК/ИИЭР 42010:2011. статья 3.2)_

2.3    хореография (choreography): Тип композиции (2.5), элементы (2.8) которой взаимодействуют децентрализованным образом с каждой автономной частью, зная определенный заранее шаблон поведения для всей (глобальной) композиции и следуя ему.

Примечания

1    Хореография не требует полного или точного знания шаблона поведения.

2    См. ИСО/МЭК 18384-3:2016. статья 8.3.

2.4    коллаборация (collaboration): Тип композиции (2.5), элементы(2.8) которой взаимодействуют децентрализованным образом, каждый из них — согласно своему собственному плану и целям без предопределенного шаблона поведения.

Примечание — См. ИСО/МЭК 18384-3:2016. статья 8.3.

2.5    композиция (composition): Результат сборки набора элементов (2.8) для конкретной цели.

Примечание — См. ИСО/МЭК 18384-3.2016. статья 8.2.

Издание официальное

2.6    оконечная точка (end point): Местоположение, в котором принимается информация для вызова и конфигурации взаимодействия.

2.7    эффект (effect): Результат взаимодействия со службой (2.20).

Примечания

1    Эффект заключается в том. каким образом служба предоставляет результаты своему потребителю посредством элемента (2.8). выполняющего ее.

2    См. ИСО/МЭК 18384-3:2016. статья 7.10.

2.8    элемент (element): Единица на заданном уровне абстракции, имеющая четко определенные границы.

Примечания

1    Элемент может быть сущностью (2.9) любого типа.

2    См. ИСО/МЭК 18384-3:2016, статья 5.1.

2.9    сущность (entity): Отдельный идентифицируемый элемент (2.8) в системе, который может выступать в качестве поставщика службы (2.50) или потребителя службы (2.29).

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

2.10    событие (event): Нечто, что происходит и на что элемент (2.8) может решить дать ответ.

Примечания

1    Любой элемент может генерировать (порождать) событие или отвечать на событие.

2    См. ИСО/МЭК 18384-3:2016. статья 10.

2.11    контекст выполнения (execution context): Набор технических и бизнес элементов (2.8), необходимый тем. у кого имеются потребности и возможности разрешить поставщикам служб (2.50) и потребителям служб (2.29) создание экземпляра службы и взаимодействие со службой.

Примечания

1    Контекст выполнения для взаимодействия со службой (2.37) представляет собой набор элементов инфраструктуры, процессов, соглашений и положений политик, которые идентифицируются как часть взаимодействия между экземплярами служб и таким образом формируют связь между тем. кто может предоставить возможности и тем. кому это необходимо.

2    См. (8).

2.12    интерактивный areHT(human actor): Агент (2.1), ограниченный сущностью (2.9). представляющей физическое лицо или организацию.

Примечания

1    Данная классификация не является исчерпывающей.

2    См. ИСО/МЭК 18384-3:2016. статья 6.2.

2.13    интерактивная задача (human task): Задача (2.60), которая выполняется интерактивным агентом (2.12).

2.14

интерфейс (interface): Совместно используемая граница между двумя функциональными единицами. определяемая различными функциональными характеристиками, параметрами физического соединения, параметрами взаимосвязи при обмене сигналами, а также другими характеристиками в зависимости от задаваемых требований.

[ИСО/МЭК 2382:2015, статья 21213081_

2.15    слабое связывание (loose coupling): Принцип, в котором зависимости между элементами (2.8) решения SOA (2.56) преднамеренно уменьшены.

2.16    оркестровка (orchestration): Тип композиции (2.5), где один определенный элемент (2.8) используется для наблюдения за другими элементами и управления ими.

Примечания

1    Элемент, который управляет оркестровкой, сам не является частью оркестровки (экземпляра композиции).

2    См. ИСО/МЭК 18384-3:2016. статья 8.3.

ГОСТ Р ИСО/МЭК 18384-1—2017

2.17    политика (policy): Положения, которые намеревается выполнять сущность (2.9) либо рассчитывает, что их будет выполнять другая сущность.

Примечание — См. ИСО/МЭК 18384-3:2016. статья 9.

2.18    процесс (process): Тип композиции (2.5), элементы (2.8) которой составлены в последовательность или поток действий и взаимодействий с целью выполнения определенной работы.

Примечания

1    Процесс также может быть коллаборацией (2.4). хореографией (2.3) или оркестровкой(2.16).

2    См. ИСО/МЭК 18384-3:2016. статья 8.6.

2.19    наблюдаемый эффект (real-world effect): Изменение, относящееся к конкретным заинтересованным сторонам.

Примечание — См. (8].

2.20    служба (service): Логическое представление ряда действий, который имеет определенные результаты, является автономным, может быть составлен из других служб и является «черным ящиком» для потребителей данной службы.

Примечания

1    Термин «действие» (activity) в определении «службы» используется в общем значении в обычном языке, а не в специальном значении для процессов (т. е. действие не обязательно является действием процесса (2.18)).

2    См. ИСО/МЭК 18384-3:2016. статья 7.2.

2.21    брокер службы (service broker): Элемент (2.8), который обеспечивает связь со служба-ми (2.20) либо на деловом уровне, либо на уровне реализации, т. е. через промежуточное программное обеспечение (ПО).

Примечание — Промежуточное ПО предоставляет поставщикам службы (2.50) и потребителям службы (2.29) одну или несколько функций, таких как единая регистрация службы (2.51) и публикация, обнаружение службы (2.34). маршрутизация, независимый от местоположения доступ к службе.

2.22    шина служб (service bus): Шаблон проектирования и времени выполнения для обеспечения взаимодействий служб (2.20). таких как передача данных, доступ, потребление, преобразование, промежуточное ПО и маршрутизация сообщений.

Примечание — Шина служб может включать в себя как логический набор таких функций, так и функции, собранные в единый коммерческий продукт. Шина служб широко используется в организационном контексте и часто совпадает с шиной служб предприятия (Enterprise Service Bus. ESB).

2.23    служба-кандидат (service candidate): Служба (2.20). идентифицированная во время жизненного цикла решения SOA (2.58), отвечающая широким требованиям к службе: из набора служб-кан-дидатов выбирается одна или несколько служб для дальнейшей разработки как части полного решения SOA (2.56).

2.24    каталог службы (service catalogue), реестр/репозиторий служб (service registry/repository, reg/rep): Логический набор описаний службы (2.31) и связанных артефактов, который поддерживает публикацию, регистрацию, поиск, управление и извлечение этих артефактов.

2.25    хореография служб (service choreography): Хореография (2.3), элементы (2.8) которой являются службами (2.20).

Примечание — См. ИСО/МЭК 18384-3:2016. статья 8.

2.26    коллаборация служб (service collaboration): Коллаборация (2.4), элементы (2.8) которой являются службами (2.20).

Примечание — См. ИСО/МЭК 18384-3:2016, статья 8.

2.27    компонент службы (service component): Элемент (2.8), который реализует службы (2.20).

2.28    композиция службы/сборка службы (service composition/service assembly): Композиция (2.5), предоставляющая (в функциональном смысле) высокоуровневые службы (2.20), которые являются лишь сборкой других служб (2.20).

Примечания

1    Композиция может поддерживать различные шаблоны композиции, такие как коллаборация (2.4). хореография (2.3). оркестровка (2.16).

2    См. ИСО/МЭК 18384-3:2016. статья 8.

3

ГОСТ Р ИСО/МЭК 18384-1—2017

2.29    потребитель службы (service consumer): Сущность (2.9), которая использует службы (2.20).

Примечания

1    Потребители могут взаимодействоватьсо службами функционально или по контракту (юридическая ответственность).

2    См. ИСО/МЭК 18384-3:2016. статья 7.4.

2.30    контракт службы (service contract): Термины, условия и правила взаимодействия, которые принимают (прямо или косвенно) взаимодействующие потребители службы (2.29) и поставщики службы (2.50).

Примечания

1    Контракт службы является обязательным для всех участников взаимодействия, включая саму службу (2.20) и элемент (2.8). который ее предоставляет, для конкретного рассматриваемого взаимодействия.

2    См. ИСО/МЭК 18384-3:2016. статья 7.6.

2.31    описание службы (service description): Информация, необходимая для использования службы (2.20) или принятия решения об ее использовании.

Примечания

1    Описание службы обычно включает интерфейсы службы (2.38). контракты и политики.

2    См. ИСО/МЭК 18384-3:2016. статья 7.

2.32    развертывание службы (service deployment): Деятельность, посредством которой реализации служб (2.20) становятся доступными в конкретной аппаратно-программной среде и могут использоваться потребителями службы (2.29).

2.33    проектирование службы (service development): Деятельность по выявлению потребностей и ограничений и проектированию службы (2.20) как части решения SOA (2.56), для того, чтобы удовлетворять данным потребностям в рамках заданных ограничений.

2.34    обнаружение службы (service discovery): Деятельность, посредством которой потребитель службы (2.29) может найти службы (2.20), удовлетворяющие его определенным функциональным и/или нефункциональным требованиям.

2.35    руководство службой (service governance): Стратегия и механизм управления, которые применяются в жизненном цикле службы (2.41) и портфеле службы, включающие установление цепочек ответственности, мониторинг за соблюдением политик путем предоставления соответствующих процессов (2.18) и измерений в рамках руководства решением SOA (2.57).

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

2.36    реализация службы (service implementation): Деятельности по технической разработке и физической реализации службы (2.20), которые являются частью жизненного цикла службы (2.41) и приводят к созданию компонента службы (2.27).

2.37    взаимодействие со службой (service interaction): Деятельность, связанная с использованием предлагаемой возможности, как правило, через границу владения, для достижения определенного желаемого наблюдаемого эффекта (2.19).

Примечание — См. [8).

2.38    интерфейс службы (service interface): Интерфейс (2.14). посредством которого другие элементы (2.8) могут взаимодействовать и обмениваться информацией со службой, где форма запроса и результат запроса находятся в описании службы (2.31).

Примечание — См. ИСО/МЭК 18384-3:2016. статья 7.13.

2.39    функциональная совместимость службы (service interoperability): Возможность поставщиков службы (2.50) и потребителей службы (2.29) взаимодействовать и вызывать службы (2.20). а также обмениваться информацией на синтаксическом и семантическом уровнях, порождая эффекты, в соответствии с описанием службы (2.31).

2.40    соглашение об уровне обслуживания (service level agreement. SLA): Tил контракта службы (2.30), который определяет измеримые условия взаимодействий между поставщиком службы (2.50) и потребителем службы (2.29).

4

ГОСТ Р ИСО/МЭК 18384-1—2017

Примечание — Соглашение об уровне обслуживания может определять: набор служб (2.20), предоставляемых поставщиком службы; конкретное определение каждой службы, обязанности поставщика службы и потребителя службы, набор метрик для определения того, насколько предоставление службы поставщиком службы соответствует заданному в контракте; механизм аудита для мониторинга службы, механизмы компенсаций для потребителей и поставщиков службы на тот случай, если условия SLA не выполняются, и как будет меняться SLA со временем.

2.41    жизненный цикл службы (service lifecycle): Последовательность этапов для реализации службы (2.20), от концепции и идентификации до создания экземпляра службы и снятия с эксплуатации.

2.42    управление службой (service management): Мониторинг, контроль, сопровождение, оптимизация служб (2.20) и управление службами.

2.43    моделирование службы (service modeling): Набор операций для разработки набора служб-кандидатое (2.23) для функций или действий над решением SOA (2.56) с использованием процесса анализа, ориентированного на службы (2.47).

2.44    мониторинг службы (service monitoring): Отслеживание состояния и условий эксплуатации, связанных с выполнением, производительностью и наблюдаемыми эффектами (2.19) служб (2.20).

2.45    оркестровка служб (service orchestration): Оркестровка (2.16). чьи элементы (2.8) являются службами (2.20).

2.46    ориентированность на службы (service orientation): Подход к проектированию систем с точки зрения служб (2.20) и разработки, основанной на службах.

2.47    анализ, ориентированный на службы (service oriented analysis): Предварительные шаги по сбору информации, которые выполняются в поддержку моделирования службы (2.43) — подпроцесса. который приводит к созданию набора служб (2.20).

Примечание — Анализ дает информацию для последующих фаз жизненного цикла SOA и может выполняться один раз для каждого бизнес-процесса (2.18) или итеративно.

2.48    сервис-ориентированная архитектура (service oriented architecture. SOA): Архитектурный стиль, который поддерживает ориентированность на службы (2.46) и является парадигмой для создания бизнес-решений.

Примечания

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

2    См. ИСО/МЭК 18384-3:2016. статья 4.

2.49    политика службы (service policy): Политика (2.17) применительно к службе (2.20).

2.50    поставщик службы (service provider): Сущность (2.9), предоставляющая службу (2.20).

Примечания

1    Поставщики служб могут быть ответственными за функционирование служб или за контракт для служб (юридическая ответственность), или за то и другое.

2    См. ИСО/МЭК 18384-3:2016. статья 7.4.

2.51    публикация службы/регистрация службы (service publishing/service registration): Каталогизация описаний служб (2.31) в доступном месте, например в реестре/репозитории служб (2.24), где поддерживаются такие действия, как поиск и извлечение описаний, что позволяет обнаружить информацию потенциальным потребителям службы (2.29).

2.52    реализация SOA (SOA implementation): Методы, используемые для разработки решений на основе SOA (2.48).

2.53    зрелость SOA (SOA maturity): Оценка возможности организации по внедрению SOA (2.48) и текущего уровня внедрения.

2.54    модель зрелости SOA (SOA maturity model): Подход, включающий цели внедрения SOA и методы оценки зрелости SOA (2.53) организации в сопоставлении с этими целями.

2.55    ресурс SOA (SOA resource): Элементы(2.8), которые предоставляют ИТ-ресурсы. исполь-зуе м ые службами (2.20).

2.56    решение SOA (SOA solution): Решения, частично или полностью реализованные с применением принципов, концепций и методов SOA (2.48).

5

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

2.57    руководство решением SOA (SOA solution governance): Частный случай руководства информационными технологиями, сфокусированный на стратегиях и механизмах управления решением SOA (2.56) конечных пользователей.

Примечания

1    Руководство решением SOA управляет всем жизненным циклом решения SOA (2.58) посредством назначения персонала, ролей, процедур управления, а также принятия решений. Руководство решением SOA должно внедрить надлежащую методологию и лучшие практики. Руководство решением SOA обычно требует инструменты для настройки и управления стратегией руководства в соответствии с потребностями.

2    Хотя управление означает определенный процесс (2.18) руководства и контроля для выполнения политики. в рамках руководства фокусируются на назначении прав по принятию решений и принятии решения о том. какие меры следует предпринимать, а также каким политикам следовать для выполнения этих решений.

2.58    жизненный цикл решения SOA (SOA solution lifecycle): Набор деятельностей по технической реализации решений SOA (2.56). включая анализ, проектирование, реализацию, развертывание, тестирование и управление.

2.59    управление решением SOA (SOAsolution management): Измерение, мониторинг и конфигурация всего жизненного цикла решения SOA (2.56).

Примечание — Во время эксплуатации управление решением SOA представляет собой набор деятельностей по измерению и управлению реализацией решения SOA в соответствии со стратегиями и механизмами, определенными процессом руководства решениями SOA (2.57).

2.60    задача (task): Атомарное действие, которое приводит к определенному результату.

Примечания

1    Задачу выполняют люди или организации, в частности интерактивные агенты {2.12).

2    См. ИСО/МЭК 18384-3:2016. статья 6.4.

2.61    веб-службы (web services): Программная система, разработанная для поддержки сетевого межмашинного взаимодействия.

Примечания

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

2    См. [8).

3    Сокращения

В настоящем стандарте используются следующие сокращения:

АВВ — стандартный блок архитектуры (СБА);

BPMN — модель и нотация бизнес-процессов;

COBIT — цели управления для получения информации и связанной технологии;

ЕА — архитектура предприятия;

ESB — шина службы предприятия;

HTTP — протокол передачи гипертекста;

HTTPS — безопасный протокол передачи гипертекста;

IT — информационные технологии (ИТ);

ITIL — библиотека инфраструктуры информационных технологий;

KPI — ключевой показатель эффективности (КПЗ);

L2TP — протокол туннелирования второго уровня;

MPLS — многопротокольная коммутация по меткам;

OWL — язык онтологии всемирной паутины:

PKI — инфраструктура открытых ключей;

6