ГОСТ Р 58546-2019 Интеграция систем управления предприятием. Часть 6. Модель службы обмена сообщениями

ГОСТ Р 58546-2019
(IEC/PAS 62264-6:2016)

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

ИНТЕГРАЦИЯ СИСТЕМ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ

Часть 6

Модель службы обмена сообщениями

Enterprise-control system integration. Part 6. Messaging service model

ОКС 25.040; 35.240.50

Дата введения 2020-01-01

Предисловие

1 ПОДГОТОВЛЕН ООО "НИИ экономики связи и информатики "Интерэкомс" (ООО "НИИ "Интерэкомс") на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"

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

4 Настоящий стандарт является модифицированным по отношению к международному документу IEC/PAS 62264-6:2016* "Интеграция систем управления предприятием. Часть 6. Модель службы обмена сообщениями" (IEC/PAS 62264-6:2016 "Enterprise-control system integration. Part 6: Messaging Service Model", MOD). При этом дополнительные фразы, слова и нормативные ссылки, включенные в текст настоящего стандарта, выделены курсивом**. В настоящем стандарте ссылки на международные стандарты заменены ссылками на соответствующие национальные стандарты

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей.

** В оригинале обозначения и номера стандартов и нормативных документов в разделах "Предисловие", 2 "Нормативные ссылки", приложении ДА и отмеченные в п.5.5.2 знаком "**" приводятся обычным шрифтом; отмеченные в разделе "Предисловие" знаком "**" и остальные по тексту документа выделены курсивом; отмеченные в п.5.5.2 знаком "***" - полужирным курсивом. - Примечания изготовителя базы данных.

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

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

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

Введение

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

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

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

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

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

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

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

1) локальный формат ALPHA преобразуется в глобальный формат данных запросов,

2) глобальный формат преобразуется в локальный формат BETA для данных запросов,

3) локальный формат BETA преобразуется в глобальный формат данных ответов,

4) глобальный формат преобразуется в локальный формат ALPHA для данных ответов.

b) Рассматриваемое преобразование выравнивает пространства имен обменивающихся данными приложений. Обычно для двусторонних связей преобразование выполняется четыре раза.

Пример 2 - Именами элементов данных могут быть коды, имена тегов, идентификаторы оборудования.

Пример 3 - Данные, представленные в пространстве имен с одним элементом (например, коды 1,2,3,4), могут иметь различные пространства имен в другом приложении (например, коды Ok, Done, Error, Delay).

c) Как только информация приобретает глобальный формат и надлежащие глобальные имена, обмениваемая информация отсылается от одного приложения к другому.

d) Сообщения транспортируются от одного приложения к другому либо в среде одного компьютера, либо между компьютерами. Механизмы транспортирования соответствуют различным стандартам (например, TCP/IP, Ethernet и т.п.).

e) Как только информация об обмене данными получена, в силу вступают особые правила, определяющие, какие результирующие данные должны быть возвращены. Правила транзакций определены в ГОСТ Р МЭК 62264-5.

Рисунок 1 - Этапы обмена данными между приложениями

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

Настоящий стандарт определяет модель набора сервисов пересылки сообщений для обмена информацией между уровнями 3 и 4, на уровне 3, между коммерческими приложениями и производственными процессами. Настоящий стандарт определяет стандартный интерфейс обмена информацией между системами.

2 Нормативные ссылки

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

ГОСТ Р МЭК 62264-1 Интеграция систем управления предприятием. Часть 1. Модели и терминология

ГОСТ Р МЭК 62264-2 Интеграция систем управления предприятием. Часть 2. Объекты и атрибуты

ГОСТ Р МЭК 62264-5 Интеграция систем управления предприятием. Часть 5. Операции "бизнес - производство"

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

3 Термины, определения и сокращения

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

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

3.1.1 описание канала (channel description): Текст, описывающий канал.

3.1.2 тип канала (channel type): Предпочтительное использование канала для публикаций и запросов.

3.1.3 канальный URI (channel URI): Предпочтительный идентификатор канала.

3.1.4 выражение фильтра (filter expression): Элемент фильтрации сообщений канала.

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

3.1.6 содержание сообщения (message content): Тело сообщения.

3.1.7 истечение срока годности сообщения (message expiry): Время до момента истечения срока годности сообщения о публикации в канале публикаций.

3.1.8 идентификатор сообщения (message ID): Идентификатор, генерируемый при выкладывании сообщения в канале во время сеанса связи.

3.1.9 пространство имен (namespace): Набор имен (слов), представляющий собой четкое формализованное множество.

3.1.10 маркер безопасности (security token): Физическое устройство и/или программный код, используемые для получения доступа к каналу.

3.1.11 идентификатор сеанса связи (session ID): Идентификатор, генерирующийся, как только приложение запускает сеанс связи с каналом. Идентификатор указывается приложением при использовании MSM-сервисов.

3.1.12 тема (topic): Идентификация содержания информации в сообщении.

3.2 Сокращения

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

B2MML - язык разметки связи между бизнесом и производством;

СВ (radio) - система персональной радиосвязи;

CCOM-ML - язык разметки, описывающий общую концептуальную модель объекта;

ERP - планирование ресурсов предприятия;

ESB - сервисная шина предприятия;

FTP - протокол передачи файлов;

HTTP - протокол передачи гипертекстовых файлов;

JMS - служба сообщений Java;

MSM - модель службы обмена сообщениями;

MIMOSA - объединение открытых систем по управлению данными в машиностроении;

OAG - сообщество открытых приложений;

OAGIS - интеграционные спецификации группы открытых приложений;

ОМАС - организация по управлению и автоматизации производства;

Open О&М - группа по управлению производством и техническим обслуживанием;

OPC-UA - унифицированная архитектура ОРС, определяющая передачу данных в промышленных сетях и взаимодействие устройств в них;

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

RSS - действительно простое приобретение информации;

SOAP - простой протокол доступа к объектам;

TCP/IP - протокол управления передачей/интернет-протокол, сетевая модель передачи данных, представленных в цифровом виде;

UDDI - стандарт универсального описания, обнаружения и интеграции;

URI - универсальный идентификатор ресурса;

WS_* - стандарт сервисов Всемирной паутины;

XML - расширяемый язык разметки;

XSLT - расширяемый язык преобразований таблиц стилей.

3.3 Условия применения настоящего стандарта

В соответствии с разделом 6 необходимо определить входные и возвращаемые параметры. Параметры допускается не вводить, если они явно определены как необязательные.

4 Модель службы обмена сообщениями

4.1 Модель интерфейса

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

MSM обеспечивает стандартный интерфейс системы, интерфейс ESB, интерфейс какой-либо другой системы обмена сообщениями (файлами), гарантирующий доставку сообщений, упорядочивание сообщений, хранение сообщений, кэширование сообщений.

_________________

Краткое описание работы Сервисной шины предприятия приведено в приложении В.

Примечание 1 - Допускается наличие нескольких различных вариантов практической реализации сервиса. Например, на основе унифицированной архитектуры ОРС, путем пересылки файлов по протоколу FTP с помощью сервисной шины предприятия ESB.

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

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

4.2 Обмен данными между приложениями

Обмен данными между приложениями представляется моделью связи как один-единственный уровень приложения. При разработке стандартов на объекты данных, сообщения представления данных (например, B2MML, MIMOSA, CCOM-ML, "объекты" (существительные) OAGIS), а также транзакционные сообщения (например, ГОСТ Р МЭК 62264-5, "действия" (глаголы) OAGIS 9.0), учитывается, что одного простого уровня недостаточно для описания сложных объектов, работающих на основе транзакционной связи между приложениями.

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

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

Рисунок 2 - Стек связи приложений

Каждый из указанных уровней соответствует конкретному элементу обмена данными приложения (см. рисунок 3):

а) Уровень объекта данных (Data Object) определяет смысл, формат и структуру базовых элементов обмена информацией.

Примечание 1 - Данный уровень использует особые определения пространства приложений, например, определения объекта по стандарту ГОСТ Р МЭК 62264-2, MESA B2MML, объекты MIMOSA, CCOM-ML, а также существительные (объекты) OAGIS.

Рисунок 3 - Определение стандартов для каждого уровня приложения

b) Уровень транзакций (Transaction) определяет смысл, формат и структуру действий, предпринятых с объектами данных.

Примечание 2 - Данный уровень использует особые стилизованные определения транзакций в соответствии с ГОСТ Р МЭК 62264-5. Другим определением уровня транзакций может быть определение глагола (действия) OAGIS.

c) Сервисный интерфейс MSM (MSM Service Interface) определяет минимальный интерфейс сервиса обмена данными уровня приложения.

d) Прикладной уровень, уровень представления, сеансовый и другие нижние уровни определяют смысл, формат и структуру для согласования порядка использования буферного запоминающего устройства, а также для обмена сообщениями (файлами). Указанные уровни содержат особые стилизованные определения для пересылки данных или обмена данными (например, для сервисной шины предприятия, системы доставки сообщений предприятия, спецификации OPC-UA, RSS, FTP, именованных каналов (Named Pipes), Ethernet, TCP/IP, HTTP и др.).

ГОСТ Р МЭК 62264-5 определяет информационные транзакции. Модель службы обмена сообщениями MSM определяет интерфейс реализации метода обмена информацией. В некотором смысле, MSM формирует стандартные пилообразные сигналы типа "on-ramp (Вкл)" и "off-ramp (Выкл)" и определяет порядок отсылки и получения данных в соответствии с применяемыми методами обмена информацией.

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

4.3 Модель транзакции

ГОСТ Р МЭК 62264-5 определяет три модели бизнес-транзакций:

1) модель публикации (publish model);

2) модель отсылки (транзакции); подача запроса, т.е. принудительная доставка данных [push model];

3) модель приема (транзакции); извлечение информации по запросу [pull model].

________________

Типы и форматы транзакций установлены стандартом ISA-95.

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

Транзакции, поддерживаемые MSM, поддерживают:

a) модель "публикации/(подписки на уведомление)" с несколькими подписчиками и несколькими публикаторами. При этом подписчики и публикаторы не знают о всех приложениях;

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

4.4 Приложения связи

Комплекс стандартов ГОСТ Р МЭК 62264 определяет четыре роли:

1) Провайдер информации (для получения сообщений GET и отсылки сообщений SYNC).

2) Получатель информации (для получения сообщений PROCESS, CHANGE и CANCEL).

3) Пользователь информации (для отсылки сообщений GET и получения сообщений SYNC).

4) Отправитель информации (для отсылки сообщений PROCESS, CHANGE и CANCEL).

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

Приложение провайдера является собственником данных. Приложение провайдера может:

1) публиковать изменения данных;

2) получать запросы на изменение данных;

3) отвечать на запросы данных.

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

Рассматриваемое приложение может быть приложением провайдера, приложением потребителя, может содержать их оба. Если рассматриваемое приложение содержит их оба, то роль провайдера данных выполняет потребитель.

Рисунок 4 - Имена моделей службы обмена сообщениями MSM

4.5 Управляемые каналы связи

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

Примечание 1 - Аналогом MSМ-канала может быть канал персональной радиосвязи.

Примечание 2 - Аналогом темы может быть разговорная тема на канале персональной радиосвязи. Пользователь может одни темы слушать, другие игнорировать.

Примечание 3 - Допущением в рамках настоящего стандарта является то, что сервисы MSM поддерживаются приложениями связи, программным обеспечением промежуточного уровня, провайдерами ESB. Настоящий стандарт не определяют* метода практической реализации сервиса MSM. Возможно использование различных архитектур (например, унифицированной архитектуры OPC-UA, FTP систем, директорий совместного пользования, системы управления очередями сообщений, RSS и т.п.).

___________________

* Текст документа соответствует оригиналу. - .

MSM устанавливает определение стандартного интерфейса сервисов, но не устанавливает порядок его практической реализации.

Управляемый канал связи называют MSM-каналом (MSM Channel).

Сервисы, обеспечиваемые MSM-каналом, называют сервисами MSM-канала (MSM Channel Service).

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

Провайдер сервиса MSM - это приложение (сетевой сервис), которое представляет и задействует сервисы MSM-канала.

Настоящий стандарт определяют* структуру иерархии MSM-канала.

___________________

* Текст документа соответствует оригиналу. - .

Каждый MSM-канал поддерживает три общих типа обмена информацией:

А - Публикации: это информация, отсылаемая нескольким приложениям потребителя.

В - Запросы: это информация, отсылаемая одному или нескольким приложениям провайдера.

С - Отклики (ответы): это информация, возвращаемая приложением потребителя по запросу.

Каждый MSM-канал поддерживает два варианта связи между приложениями провайдера и приложениями потребителя.

a) MSM-канал поддерживает либо сервис публикаций, либо сервис запросов.

b) Приложение провайдера может выкладывать публикации в MSM-канал публикаций.

c) Приложение потребителя может подписаться на уведомления о публикации (если это поддерживается особым сервисом MSM-канала публикаций). Допускается чтение публикаций. Если услуга подписки на уведомления не поддерживается, то приложение потребителя может упорядочивать сервис MSM-канала публикаций путем применения сервиса чтения публикаций.

d) Приложение потребителя выдает запросы в MSM-канале запросов.

e) Приложение провайдера может подписаться на уведомления о запросах (если это поддерживается особым сервисом MSM-канала запросов). Допускается читать запросы. Если услуга подписки на уведомления не поддерживается, то приложение провайдера может упорядочивать сервис MSM-канала запросов путем чтения запросов сервиса.

f) MSM-каналы имеют ассоциированные темы. Темы идентифицируются при подписке на канал, при выкладывании публикаций и запроса.

4.6 Сервисы уведомлений

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

Доступ к сервису уведомлений организуется с помощью услуги Notify Listener (уведомление слушателя) для подписчика, запрашивающего лица и отвечающего лица.

Наличие интерфейса сервиса уведомлений необязательно для провайдера сервиса MSM.

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

Примечание - Формат идентификации слушателя для уведомления определяется особенностями практической реализации сервиса.

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

4.7 Сервисы MSM-канала

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

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

Рисунок 5 - Сервисы управления MSM-каналом

4.8 Сервисы MSM-канала публикаций

4.8.1 Сервисы канала публикаций

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

Сервис MSM-канала публикаций показан на рисунке 6. Данные сервисы позволяют нескольким приложениям провайдера публиковать публикации в данном канале. Приложения потребителя обеспечивают подписку на уведомления (если это поддерживается каналом) и могут читать публикации.

Рисунок 6 - Сервисы MSM-канала публикаций

4.9 Сервисы MSM-канала запросов

4.9.1 Сервисы канала запросов

Сервисы MSM-канала запросов присылают сообщения о запросах, читают сообщения об отклике.

Сервисы MSM-канала для транзакций типа Push (отослать) и Pull (получить) по ГОСТ Р МЭК 62264-5 показаны на рисунке 7. Данные сервисы работают с транзакциями PROCESS (обработать), CHANGE (изменить), CANCEL (отменить) и GET (получить).

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

Пример - "Темы" могут определять формат и содержание сообщения (в соответствии с используемым определением XSD-схемы на языке XML) для создания и верификации сообщения.

Рисунок 7 - Сервисы запросов/откликов

5 Принципы работы MSM-каналов

5.1 Идентификация каналов и тем

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

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

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

5.2 Имена и иерархия каналов

5.2.1 Имена каналов

Имена каналов определяются иерархией имен в синтаксисе URI.

5.2.2 Иерархия имен канала

Имена каналов должны соответствовать установленной иерархии имен:

\ <MSM root (корень)> \ <channel scope (область применения канала)> \ <information scope (область применения информации)> \ <channel use (использование канала)>

Пример 1 - \AJAEnterprises\Company\Material\Checkpoint.

Пример 2 - \AJAXEnterprises\Company\Material\Request.

Пример 3 - \SystemTest\Final\OurMaterialManager\lnventory\Changes.

Пример 4 - \AJAXEnterprises\France\Personnel\Checkpoint.

5.2.3 Корневой MSM-каталог

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

Для работы провайдера MSM сервиса корневой MSM-каталог может потребовать специальные данные.

Пример -

Название корневого MSM-каталога может содержать название компании:

- например, "AJAX" или "AJAXEnterprises\SpecialToolCo".

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

- например, "SystemTest\Beta", "SystemTest\Final", "SpecialToolCo\Operations".

Примечание - MSM-сервисы не определяют порядок поиска корневых MSМ-каталогов. Указанные специальные сервисы не зависят от практической реализации MSM-сервиса. Также имеются ограничения безопасности. В настоящем стандарте указанные ограничения не рассматриваются.

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

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

Пример -

Область применения канала может включать имя сайта (региона), чтобы ограничить число присылаемых сообщений (например, "AsiaPacifc", "SouthAfrica", "France").

Область применения канала может ограничиваться возможностями программного обеспечения. Тогда в названии можно указать его рыночный бренд (например, "OurMaterialManager", "PersonnelTracker", "InventoryDataBase").

Область применения канала может ограничиваться только одной компанией (только ее приложениями). Тогда название канала может идентифицировать данную компанию (например, "Enterprise", "Company" и т.п.). Идентификация также может отсутствовать.

5.2.5 Область применения информации

Область применения информации определяет диапазон или общий тип обмена информацией. Область применения информации может быть связана с существительными (объектами) транзакций, определенными в ГОСТ Р МЭК 62264-2, а также с другими наборами объектов.

Пример -

Приложение, работающее со всеми формами информации о материалах, может определить канал с областью применения "Material".

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

5.2.6 Использование канала

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

Для обеспечения интероперабельности использование канала должно учитывать классы глаголов сообщений о транзакциях в соответствии с ГОСТ Р МЭК 62264-5.

Пример 1 - Классы глаголов сообщений в соответствии с ГОСТ Р МЭК 62264-5:

Запрос: GET / SHOW.

Команда: PROCESS / ACKNOWLEDGE, CHANGE / RESPOND, CANCEL.

Публикация: SYNC ADD, SYNC CHANGE, SYNC DELETE.

Пример 2 - Приложение, отсылающее сообщение GET, может определять канал с использованием глагола класса "Query (Запрос)".

Приложение, отсылающее сообщения PROCESS, CHANGE, CANCEL может определять канал с использованием глагола класса "Command (Команда)".

Приложение, отсылающее сообщения SYNC, может определять канал с использованием глагола класса "Publication (Публикация)". Данный канал используется только для публикаций. Он делает "моментальные снимки" (snapshot) всей обмениваемой информации.

Пример 3 - Каналы "PublicationChanges (Изменения публикаций)" и "PublicationCheckPoint (Контрольная точка публикации)" могут быть задействованы вместе в приложении провайдера (см. рисунок 8).

Канал CheckPoint публикует текущие моментальные снимки всей обмениваемой информации.

Канал Changes публикует все изменения последнего моментального снимка.

Если моментальный снимок доступен, то приложение провайдера может удалить все публикации в канале Changes и все предшествующие моментальные снимки в канале CheckPoint.

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

Рисунок 8 - Пример работы каналов Changes и Сheckpoint

5.3 Фильтрация сообщений

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

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

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

Одна и та же тема может работать в нескольких каналах.

Пример 1 - Тема ProductionSchedule (Календарный план) может работать в каналах CheckPoint и Changes в рамках области применения канала производственного участка. Тема ProductionSchedule может работать в каналах CheckPoint и Changes в области применения на производственном участке.

Пример 2 - Тема QualificationTest (Квалификационные испытания) может работать в канале Request (Запрос) в рамках области применения канала предприятия. Тема QualificationTest может работать в канале Request (Запрос) в области применения в масштабах страны.

5.4 Истечение срока годности публикации

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

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

Годность публикации определяется разными критериями. Если годность публикации определяется временем, то срок годности определяется моментом completion invocation (завершения вызова) сервиса выкладывания публикации в дополнительный установленный интервал времени.

Любое просроченное сообщение о публикации может быть удалено сервисом ExpirePublication (сервисом удаления просроченных сообщений).

5.5 Темы

5.5.1 Определение темы

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

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

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

5.5.2 Стандартные темы

Для поддержки интероперабельности темы должны соответствовать глаголам и существительным транзакционных сообщений в соответствии с ГОСТ Р МЭК 62264-2**.

Пример 1 - Классы существительных по стандарту ГОСТ Р МЭК 62264-2***.

Имена тем могут содержать ассоциированный номер стандарта (версии стандарта), ассоциированное существительное.

Пример 2 - Одна тема может быть определена для сообщений, использующих определения типа B2MML-V0402-MaterialLot. Другая тема может содержать определения типа B2MML-V0501-MaterialLot. Третья тема может содержать определения типа B2MML-V0600-MaterialLot.

Одна и та же тема может быть определена на нескольких каналах.

Пример 3 - Тема ProductionSchedule может быть определена для каналов CheckPoint и Changes с областью применения канала на сайте. Тема ProductionSchedule может быть определена для каналов CheckPoint и Changes в рамках области применения канала производственной площадки.

Пример 4 - Тема QualificationTest может быть определена в канале Request с областью применения канала на предприятии. Тема QualificationTest может определена в канале Request в рамках области применения канала в масштабах страны.

5.6 Сеансы связи MSM

Соединение с каналом производится через сеанс связи MSM (MSM-сессии). MSM-сессии проводятся с помощью сервиса открытого сеанса связи. Данный сервис возвращает идентификатор сеанса связи.

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

5.7 Безопасность

5.7.1 Обмен сообщениями безопасности

Безопасность при обмене сообщениями определяется как аутентифицированный доступ к сервисам MSM-канала.

Примечание - Обеспечение безопасности MSM-сервисов - дело первостепенной важности. В модели сервиса MSM-приложения "ничего не знают" о своих партнерах по связи. Они не знают количества возможных партнеров: 1) отсутствие партнеров (публикаторы работают без подписки), 2) один партнер, 3) несколько партнеров. Безопасность не может определяться как связь с доверенными партнерами. Безопасность подразумевает взаимодействие по безопасным каналам.

5.7.2 Маркеры безопасности каналов

Безопасность доступа по каналу обеспечивается маркерами безопасности.

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

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

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

Маркер безопасности используется приложением при открытии канала, при подписке в канале. Если маркер безопасности приложения не соответствует маркеру безопасности канала, то информация из канала не поступает.

Маркерами безопасности обмениваются на внеполосных каналах связи (например, в ручном режиме, в электронном режиме на безопасных каналах типа "точка-точка").

Рисунок 9 - Безопасность каналов

5.7.3 Формат маркера безопасности

Формат маркера безопасности определяется в спецификации практической реализации MSM-сервиса. Варианты практической реализации MSM-сервиса могут основываться на различных методах представления и форматах маркеров безопасности.

5.7.4 Рекомендации для провайдеров MSM-сервисов

1) Все провайдеры MSM-сервисов должны использовать маркеры безопасности.

2) Для обеспечения безопасности провайдеры MSM-сервисов могут ограничить использование сервисов управления MSM-каналами в отношении приложений, серверов, доменов и т.д.

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

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

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

6 Определение сервиса MSM

6.1 Типы определений

Таблица 1 содержит типы определений, ассоциированные с определением сервиса.

Таблица 1 - Типы определений MSM-сервисов

6.2 Возвращение результатов и отказы MSM-сервисов

Таблица 2 содержит определения вариантов возвращения результатов работы и отказов MSM-сервиса. Отказы должны подтверждаться удобочитаемыми объяснениями.

Таблица 2 - Определения возвращения результатов работы и отказов MSM-сервиса

6.3 Сервис управления MSM-каналом

6.3.1 Создание канала

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

Таблица 3 - Создание канала

6.3.2 Добавление маркеров безопасности

Описание функции сервиса добавления маркеров безопасности, входных параметров и возвращаемых результатов работы приведено в таблице 4.

Таблица 4 - Добавление маркеров безопасности

6.3.3 Удаление маркера безопасности

Описание функции сервиса удаления маркера безопасности, входных параметров и возвращаемых результатов работы приведено в таблице 5.

Таблица 5 - Удаление маркера безопасности

6.3.4 Удаление канала

Описание функции сервиса удаления канала, входных параметров и возвращаемых результатов работы приведено в таблице 6.

Таблица 6 - Удаление канала

6.3.5 Получение канала

Описание функции сервиса получения канала, входных параметров и возвращаемых результатов работы приведено в таблице 7.

Таблица 7 - Получение канала

6.3.6 Получение нескольких каналов

Описание функции сервиса получения нескольких каналов, входных параметров и возвращаемых результатов работы приведено в таблице 8.

Таблица 8 - Получение нескольких каналов

6.4 Сервис уведомления слушателя

6.4.1 Уведомление слушателя

Описание функции сервиса уведомления слушателя, входных параметров и возвращаемых результатов работы приведено в таблице 9.

Таблица 9 - Уведомление слушателя

Примечание - Сервисы уведомления слушателя обычно возвращают значения переменных SessionID (идентификатор сеанса связи), MessagelD (идентификатор сообщения), Topic (идентификатор темы), RequestMessagelD (идентификатор сообщения о запросе, необязательный параметр).

6.5 Сервис публикации MSM-провайдера

6.5.1 Открытие сеанса связи для публикации

Описание функции сервиса открытия сеанса связи для публикации, входных параметров и возвращаемых результатов работы приведено в таблице 10.

Таблица 10 - Открытие сеанса связи для публикации

6.5.2 Выкладывание публикации

Описание функции сервиса выкладывания публикации, входных параметров и возвращаемых результатов работы приведено в таблице 11.

Таблица 11 - Выкладывание публикации

6.5.3 Перевод публикации в разряд просроченных

Описание функции сервиса перевода публикации в разряд просроченных, входных параметров и возвращаемых результатов работы приведено в таблице 12.

Таблица 12 - Перевод публикации в разряд просроченных

6.5.4 Закрытие сеанса связи для публикации

Описание функции сервиса закрытия сеанса связи для публикации, входных параметров и возвращаемых результатов работы приведено в таблице 13.

Таблица 13 - Закрытие сеанса связи для публикации

6.6 Сервисы публикации MSM-потребителя

6.6.1 Открытие сеанса связи для подписки

Описание функции сервиса открытия сеанса связи для подписки, входных параметров и возвращаемых результатов работы приведено в таблице 14.

Таблица 14 - Открытие сеанса связи для подписки

6.6.2 Чтение публикаций

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

Таблица 15 - Чтение публикаций

6.6.3 Удаление публикации

Описание функции сервиса удаления публикации, входных параметров и возвращаемых результатов работы приведено в таблице 16.

Таблица 16 - Удаление публикации

6.6.4 Закрытие сеанса связи для подписки

Описание функции сервиса закрытия сеанса связи для подписки, входных параметров и возвращаемых результатов работы приведено в таблице 17.

Таблица 17 - Закрытие сеанса связи для подписки

6.7 Сервисы запросов MSM-провайдера

6.7.1 Открытие сеанса связи для запросов провайдера

Описание функции сервиса открытия сеанса связи для запросов провайдера, входных параметров и возвращаемых результатов работы приведено в таблице 18.

Таблица 18 - Открытие сеанса связи для запросов провайдера

6.7.2 Чтение запросов

Описание функции сервиса чтения запросов, входных параметров и возвращаемых результатов работы приведено в таблице 19.

Таблица 19 - Чтение запросов

6.7.3 Удаление запроса

Описание функции сервиса удаления запроса, входных параметров и возвращаемых результатов работы приведено в таблице 20.

Таблица 20 - Удаление запроса

6.7.4 Выкладывание отклика

Описание функции сервиса выкладывания отклика, входных параметров и возвращаемых результатов работы приведено в таблице 21.

Таблица 21 - Выкладывание отклика

6.7.5 Закрытие сеанса связи для запросов провайдера

Описание функции сервиса закрытия сеанса связи для запросов провайдера, входных параметров и возвращаемых результатов работы приведено в таблице 22.

Таблица 22 - Закрытие сеанса связи для запросов провайдера

6.8 Сервис запросов MSM-потребителя

6.8.1 Открытие сеанса связи для запросов потребителя

Описание функции сервиса открытия сеанса связи для запросов потребителя, входных параметров и возвращаемых результатов работы приведено в таблице 23.

Таблица 23 - Открытие сеанса связи для запросов потребителя

6.8.2 Выкладывание запросов

Описание функции сервиса выкладывания запросов, входных параметров и возвращаемых результатов работы приведено в таблице 24.

Таблица 24 - Выкладывание запросов

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

6.8.3 Чтение отклика

Описание функции сервиса чтение отклика, входных параметров и возвращаемых результатов работы приведено в таблице 25.

Таблица 25 - Чтение отклика

6.8.4 Удаление отклика

Описание функции сервиса удаления отклика, входных параметров и возвращаемых результатов работы приведено в таблице 26.

Таблица 26 - Удаление отклика

6.8.5 Закрытие сеанса связи для запросов потребителя

Описание функции сервиса закрытия сеанса связи для запросов потребителя, входных параметров и возвращаемых результатов работы приведено в таблице 27.

Таблица 27 - Закрытие сеанса связи для запросов потребителя

7 Сценарии

7.1 Сценарии публикации и подписки

7.1.1 Простой сценарий публикации и подписки

Простой сценарий публикации и подписки с одним приложением провайдера и одним приложением потребителя, использующий сервис уведомлений, показан на рисунке 10.

Примечание 1 - Обычно публикации приходят сразу нескольким приложениям потребителя. В данном примере принято, что приложение только одно.

Примечание 2 - Принято, что рассматриваемый канал и соответствующая тема уже созданы до начала разработки сценария.

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

Для подписки приложения потребителя на канал публикаций MSM нужно иметь:

1) URI канала;

2) маркер безопасности;

3) перечень Тем.

Идентификатор сеанса связи нужно сохранить на случай внезапного отключения приложения потребителя.

Если выкладывается новое сообщение с корректной темой, то приложению потребителя присылается уведомление о выложенном сообщении. Приложение читает новое сообщение о публикации на канале MSM.

Если приложению потребителя больше не требуются данные, то оно:

1) аннулирует подписку в ходе сеанса связи для подписки;

2) удаляет идентификатор сеанса связи из накопителя постоянного хранения.

При повторном запуске системы открывается новый сеанс связи.

Рисунок 10 - Сценарий публикации с уведомлением

7.1.2 Сценарий публикации и подписки с несколькими сообщениями

На рисунке 11 показаны:

1) простой сценарий публикации/подписки с несколькими сообщениями;

2) одно приложение провайдера;

3) доступ к сервисам уведомлений;

4) доступ к приложениям потребителя с помощью сервисов уведомлений.

В настоящем сценарии приложение провайдера открывает сеанс связи для публикации MSM в данном канале. Если приложение провайдера принимает решение о публикации данных, то выкладывается публикация [а], указывается тема сообщения, сообщение считается непросроченным.

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

Рисунок 11 - Сценарий публикации с несколькими сообщениями

При получении уведомления приложение потребителя читает и удаляет все публикации до момента возвращения пустого сообщения из блока ReadPublication (чтение публикации).

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

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

7.1.3 Сценарий публикации и подписки без уведомления

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

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

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

7.1.4 Сценарий с несколькими публикаторами

Один и тот же канал публикаций может быть задействован несколькими приложениями провайдера. Сценарий, показанный на рисунке 13, имеет два приложения провайдера. Например, одно приложение публикует изменения по теме "определения материала (MaterialDefinitions)". Другое приложение публикует изменения по теме "партии материала (MaterialLots)".

Рисунок 12 - Сценарий публикации без уведомления

Рисунок 13 - Сценарий публикации с несколькими приложениями провайдера

7.1.5 Сценарий публикации и подписки с учетом срока годности публикации

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

- для просроченного прочитанного сообщения;

- для просроченного непрочитанного сообщения.

При повторном вызове процедуры ReadPublication (чтение публикации) приложением потребителя, провайдер MSM-сервиса возвращает следующее сообщение в очередь на подписку. В данном случае следующего сообщения может не быть. Третий вызов процедуры чтение публикации возвращает следующую непросроченную публикацию в очередь на подписку (см. сообщение [с]).

Рисунок 14 - Сценарий публикации с просроченными публикациями

7.2 Сценарии канала запросов

7.2.1 Сценарий запросов и ответов с уведомлением

Рисунок 15 иллюстрирует сценарий для транзакции GET/SHOW (получить/показать) при наличии приложения провайдера, приложения потребителя, а также канала, поддерживающего уведомления.

На рисунке 15 приложение провайдера открывает сеанс связи для запросов провайдера. Приложение потребителя открывает сеанс связи для запросов потребителя, выкладывает запрос [а]. Провайдер получает уведомление, читает запрос [а]. Приложение провайдера работает в штатном режиме (в данном случае в режиме получения данных). Оно отсылает сообщение об отклике [b] (в данном случае сообщение в формате SHOW), а затем удаляет запрос [а]. Приложение потребителя получает уведомление о выкладывании сообщения, читает отклик [b], затем удаляет данный отклик.

7.2.2 Сценарий запросов и ответов без уведомления

Если рассматриваемые приложения или MSM-сервис не поддерживают уведомления, то провайдер может выложить запрос, а приложение потребителя может представить отклик. Рисунок 16 иллюстрирует сценарий с транзакцией CHANGE-RESPONSE (изменение-отклик), где и потребитель, и провайдер могут рассчитывать на отклик.

Рисунок 15 - Сценарий сервиса запросов в формате GET/SHOW

Рисунок 16 - Сценарий сервиса запросов CHANGE/RESPONSE

Транзакции GET/SHOW, PROCESS/ACKNOWLEDGE, CHANGE/RESPONSE и CANCEL работают с помощью каналов запросов.

7.2.3 Сценарий с несколькими приложениями провайдера

Рисунок 17 иллюстрирует сценарий с несколькими приложениями провайдера. В данном случае два приложения провайдера оформили подписку на уведомление о запросе в том же самом MSM-канале.

Приложение потребителя выкладывает запрос типа CHANGE (изменение) со специальной темой (например, Personnellnformation (информация о персонале).

Приложение 1 получает уведомление о запросе, соответствующем теме подписки. Приложение 1 получает сообщение [а] типа CHANGE об изменении, генерирует Сообщение [b] типа RESPONSE об отклике. Приложение 2 не получает уведомления о запросе (например, тема запроса не соответствует его подписке).

Рисунок 17 - Сценарий для сообщений типа CHANGE/RESPONSE (изменение/отклик) с несколькими провайдерами

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

8 Соответствие требованиям

Настоящий стандарт не содержит положений о соответствии рассматриваемых объектов установленным требованиям. Оценку соответствия рассматриваемых объектов установленным требованиям проводят с учетом нижеследующих положений:

a) использование терминологии настоящего стандарта;

b) кроме того, для каждого поддерживаемого сервиса:

I) обеспечение поддержки сервисов уведомлений в соответствии с разделом,

II) декларация уровня поддержки в выражениях фильтра,

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

Приложение А
(справочное)

Требования к провайдеру MSM-сервиса

А.1 Требования к провайдеру сервиса

Нижеследующие разделы определяют сервисы ESB типа (сервисной шины предприятия). Данные сервисы обеспечиваются провайдерами MSM-сервисов. Указанные сервисы не входят в MSM-спецификацию. Они формируют области, в которых продавцы и другие заинтересованные стороны обеспечивают работу дифференцированных сервисов.

А.2 Уведомление

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

А.3 Требования безопасности

Провайдер MSM-сервисов должен принимать во внимание следующие соображения:

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

b) Запросы на доступ с недопустимыми маркерами безопасности регистрируются в журнале. Наличие записей в журнале указывает либо на проблемы с конфигурацией, либо на возможные атаки на систему.

c) Запросы на доступ к недопустимым URI канала также регистрируются в журнале. Наличие записей в журнале указывает либо на проблемы с конфигурацией, либо на возможные атаки на систему.

d) Внутренние сообщения конкретного MSM-сервиса могут шифроваться. Они могут передаваться по специальному безопасному каналу. Используемый метод коммуникации может зависеть от используемых сервисов транспортировки. Он может не определяться в интерфейсе MSM-сервиса.

e) Идентификатор сеанса связи MSM должен быть уникальным в глобальном масштабе. Его использование ограничивается конкретным провайдером (потребителем). Доступ к каналу производится только через маркер безопасности.

А.4 Требования к практической реализации MSM-приложения

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

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

b) В средах с высокой безопасностью уникальные маркеры безопасности могут быть назначены для каждого возможного пути связи. Маркеры безопасности могут заменяться на регулярной основе. Для замены маркеров безопасности на регулярной основе действуют специальные механизмы.

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

А.5 Требования безопасности к MSM-каналам

Некоторые практические реализации могут потребовать дополнительных уровней безопасности, отличных от уровней, определенных в 5.2.6. Например, рассматриваемые практические реализации могут потребовать особой безопасности для сообщений типа GET/SHOW (получить/показать), для сообщений типа PROCESS (обработать), CHANGE (изменить), CANCEL (снять). Одни каналы могут специализироваться по запросам (типа GET/SHOW), другие - по обработке сообщений (типа PROCESS, CHANGE, CANCEL).

А.6 Требования к идентификаторам сеансов связи MSM

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

А.7 Валидация формата данных

Провайдер MSM-сервиса обеспечивает проверку формата данных в сообщениях. Если формат данных в сообщении соответствует установленным требованиям (например, требованиям B2MML, BatchML и т.п.), то провайдер сервиса проверяет корректность синтаксиса выложенных сообщений.

Сообщения подлежат контрольной проверке.

В данном случае провайдер MSM-сервиса должен задействовать карту перекрестных связей перечня тем и файлов XML-схемы. Данная карта используется провайдером для проверки корректности подписки, запросов и ответов.

А.8 Допустимые проверки приложений

Провайдер MSM-сервиса обеспечивает контрольные проверки, которые создаются приложением (приложение подписывается на них). Данные проверки создают дополнительный уровень безопасности. Это необходимо, если рассматриваемый MSM-сервис задействуется за пределами компании.

А.9 Регистрация обмена данных в журнале

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

А.10 Обработка типовых ошибок

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

А.11 Сервис преобразования данных

Провайдер MSM-сервиса может преобразовывать данные в сообщениях. Обычно это преобразование специального формата данных приложения провайдера (приложения потребителя) в какой-либо стандартный формат (например, формат B2MML, формат BatchML и т.п.). И наоборот, это может быть преобразование из стандартного формата в специальный формат конкретного приложения.

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

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

Провайдер MSM-сервиса обеспечивает корректное соотношение между:

1) Темой приложения;

2) правилами преобразования специального формата в стандартный;

3) определением "стандартной" Темы.

Специальные Темы и преобразования конкретных приложений

Рисунок А.1 - Сервисы MSM-преобразований

А.12 Корпоративный мост

Провайдер MSM-сервиса обеспечивает корпоративную связь и аутентифицированный сервис для сообщений.

Требований к порядку обеспечения корпоративного сервиса MSM провайдером не предъявляется.

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

Примечание - Спецификации безопасных (аутентифицированных) каналов связи в настоящем стандарте не рассматриваются.

Корпоративный мост

Рисунок А.2 - Корпоративный мост между несколькими MSM-сервисами

А.13 Техническое обслуживание сообщений

Провайдер MSM-сервиса управляет сообщениями в канале. При этом сервис обладает следующими возможностями:

- стирание "висячих" сообщений, не стертых ранее вследствие отказа транзакции запроса (отклика);

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

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

Приложение B
(справочное)

Сервисная шина предприятия

Типовая среда информационной технологии - "федерация" систем. Термин "федерация" в мире информационных технологий относится к набору приложений нескольких продавцов. Продавцы работают вместе и поддерживают совместимые производственные процессы. Федерация может включать отдельные приложения для управления материальными ресурсами, обработки прохождения заказов, управления цепью поставок, поддержания отношений с заказчиками, для производственного и календарного планирования. Даже если компания задействует продвинутого ERP-специалиста, то ему зачастую приходится иметь дело с федерацией унаследованных систем, поддерживающих старые производственные процессы. Федеральные системы имеют высокую стоимость, их интеграция отнимает большую часть имеющихся средств. Наиболее эффективный метод сокращения затрат на интеграцию - использование сервисной шины предприятия (ESB). Ее также называют шиной интеграции предприятия (EIB). Это не интеграционные электронные шины в их обычном понимании, это специализированные приложения, работающие на резервных серверах. Они функционируют как концентраторы и распределители данных. Производственные системы, постоянно обменивающиеся данными с финансово-хозяйственными информационными структурами, должны быть подключены к сервисной шине предприятия ESB.

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

- один источник совместного использования информации;

- одно место предоставления услуг приложений;

- одного адресата предоставления услуги.

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

Выделим пять основных ESB-элементов. Их необходимо учитывать при соединении приложения с сервисной шиной:

a) элемент пересылки данных;

b) элемент обнаружения сервиса;

c) элемент преобразования данных;

d) элемент протокола транзакции;

e) элемент полезной нагрузки.

Все вышеуказанные элементы используют XML-технологии. Новейшие сервисные шины предприятий ESB предоставляют сетевые услуги. Элемент пересылки данных транспортирует XML-сообщения из одного приложения в другое с помощью общего сервера. Он отказывается от интерфейса типа "точка-точка", обеспечивает централизованно управляемый механизм, задействует связи между приложениями. HTTP-сообщения и сервисы сообщений Java (JMS) - это типовые практические реализации (с открытым исходным кодом) элемента пересылки данных заданного уровня. Стандартным механизмом пересылки данных при интеграции производственных систем может стать архитектура OPC-UA (www.opcfoundation.org).

Элемент обнаружения сервиса обеспечивает возможность приложениям обнаруживать услуги и данные с помощью шины ESB. Обычно здесь задействуется стандарт интеграции сетевых сервисов UDDI (www.uddi.org) в среде информационных технологий. Это часть архитектуры OPC-UA. Практическая реализация MSM-сервиса должна определять механизм обнаружения услуги.

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

Элемент протокола транзакции задействует формальное определение допустимой транзакции сообщения. Определение соответствует ГОСТ Р МЭК 62264-5, требованиям OAGIS (www.openapplications.org) и стандартов RosettaNet (www.rosettanet.org).

Элемент полезной нагрузки определяет данные, составляющие тело сообщения. Организации по стандартизации, которые входят в OpenO&M (ISA, WBF, MIMOSA, ОРС и т.п.) определяют содержание информации на XML-языке.

Основная цель MSM-сервисов - создание общего интерфейса сервисной шины ESB или любой другой системы обмена сообщениями (см. рисунок В.1).

Рисунок В.1 - Стандартный интерфейс ESB и различные системы обмена сообщениями

Приложение ДА
(справочное)

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

Таблица ДА.1

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

Электронный текст документа
и сверен по:

, 2019