ГОСТ Р МЭК 62264-5—2012
Данная модель используется для составления ответа на запрос.
Приложения провайдера информации фиксируют сообщения GET (получить) и отвечают сообщения
ми SHOW (показать)для завершения транзакции.
Приложения пользователя информации отправляют сообщения GET.
1) Запросы на информацию отправляются с помощью сообщений GET.
2) Сообщение GET описываетобласть применения запрашиваемой информации.
3) Сообщение SHOW возвращает информацию.
b
) Модель «PUSH» используется, когда отправитель информации отправляет новую (измененную)
информацию получателю для обработки запросов, т. е. для выполнения групповой операции.
Приложения получателя фиксируют сообщения PROCESS (обработка), CHANGE (изменение) или
CANCEL (отмена).
Приложения отправителя направляют сообщения PROCESS. CHANGE и CANCEL.
1) Новая информациядоставляется получателю с помощью сообщений PROCESS. Ответы могут
быть возвращены отправителю через сообщение ACKNOWLEDGE (подтверждение приема).
2) Изменения информации направляются получателю с помощью сообщений CHANGE. Ответы
могут быть возвращены отправителю черезсообщение RESPOND (ответ).
3) Уведомление об удалении информации направляется получателю сообщением CANCEL.
c) Модель «PUBLISH» используется, когда провайдер данных публикует ихдля пользователей (под
писчиков) данных. Эта модель используется для синхронизации данных.
Приложения подписчика получают сообщения SYNC.
Приложения издателя отправляют сообщения SYNC.
1) Издатель отправляет сообщения SYNC, содержащие новую, измененную или удаленную ин
формацию, подписчику.
2) Подписчик получает сообщения SYNC, содержащие новую, измененную или удаленную ин
формацию.
Временной режим публикации и область применения опубликованной информации в сообщении не
определяются. Они определяются вспомогательным соглашением между издателем и подписчиком. По
этой причине сообщения SUBSCRIBE (подписка) в настоящем стандарте не определены.
Пример — Вспомогательное соглашение означает, что оно не определяется в протоколе тран
закции. Например: соглашение между издателем и подписчиком может быть достигнуто:
1) путем задания параметров конфигурации в приложении;
2) динамически через сетевые соглашения:
3) с помощью некоторого приложения третьей стороны.
Одно приложение может поддерживать одну или несколько моделей транзакций. Рассматриваемое
приложение может играть несколько ролей (отправителя, получателя, провайдера и пользователя).
П р и м е ч а н и е1 — Транзакции основаны на допущении, что обмениваемая информация (обьект)
содержится в сообщении некоторой формы. Точная форма такого сообщения в настоящем стандарте не опреде
ляется. Например, сообщения могут быть файлами с разделителями табуляции, файлами в формате XML. сооб
щениями электронной почты или данными в именованном канале. Точная форма механизма транспортировки,
предназначенного для отправки, получения, прослушивания и публикации сообщений, в настоящем стандарте не
определяется.
П р и м е ч а н и е 2 — Модели сообщений транзакций не подразумевают использования какой-либо
специальной архитектуры или механизма для транспортировки сообщений.
Использование транзакций предполагает наличие возможности отправлять пустые или почти пустые
сообщения, которые идентифицируют специальные объекты (как правило, с помощью специального иден
тификатора), перечни специальных объектов (путем составления перечня идентификаторов) или классы
объектов (с помощью групповых символов или путем определения значений свойств).
Рисунок 1 иллюстрируетобмен сообщениями при транзакции, когда сообщениеотправляется от пользо
вателя информации с идентификацией объекта (оборудование GET) и когда сообщение возвращается от
провайдера информации с информацией об объекте (оборудование SHOW).
3