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

105 страниц

Является стандартом прикладного уровня архитектуры взаимосвязи открытых систем, установленной ГОСТ 28906. Он определяет концепции и услуги для ПОЗ. Стандарт требует от пользователя ПОЗ: - указать открытые системы, в которых должна быть выполнена работа; - знать локальные функции и возможности открытых систем, в которых должна быть выполнена работа; - знать управляющие языки, используемые для указания локальной работы в открытых системах, в которых должна быть выполнена работа. Стандарт обеспечивает возможность для: - указания работы, которая должна быть выполнена в одной или нескольких открытых системах; - управления выполнением предварительно указанной работы; - модификации предварительно указанной работы. Стандарт не определяет управляющие языки, но он применим для использования стандартного управляющего языка. Стандарт не определяет интерфейсы пользователя

 Скачать PDF

Оглавление

Предисловие

Раздел 1. Общее описание

     1.1 Назначение

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

     1.3 Определения

     1.3.1 Определения услуг СПВ

     1.3.2 Определения услуг ПОЗ

     1.4 Сокращения

     1.5 Соглашения

Раздел 2. Обзор

     2.1 Обзор и общее описание

     2.1.1 Обзор

     2.1.2 Содержимое спецификации работы

     2.1.3 Проформы и порождение

     2.1.4 Исходные, принимающие и исполняющие агентства

     2.1.5 Задания ВОС

     2.1.6 Обработка спецификаций работы

     2.1.7 Отчетность и функция монитора

     2.1.8 Исполнение, совмещение и восстановление

     2.1.9 Управление передачами

     2.1.10 Управление отчетами

     2.1.11 Выполнение работы

     2.1.12 Управление передачами

     2.1.13 Полномочия и учет

     2.1.14 Идентификация спецификаций работы

     2.1.15 Ответственность службы отчетности

     2.1.16 Документы

     2.1.17 Промежуточные системы ПОЗ

     2.2 Обзор службы

     2.3 Базовые и расширенные реализующие системы

     2.4 Модель спецификации услуг

Раздел 3. Определение примитивов

     3.1 Сервисные примитивы ПОЗ

     3.1.1 Группы сервисных примитивов

     3.1.2 Компоненты групп сервисных примитивов

     3.1.3 Параметры примитивов, относящихся к СИВ

     3.1.4 Последовательность групп сервисных примитивов

     3.1.5 Последовательность сервисных примитивов

     3.2 Нотация для сервисных примитивов и определение структуры данных

     3.2.1 Базовые типы данных

     3.2.2 Механизмы структурирования

     3.2.3 Определение базовых типов данных

     3.3 События ПОЗ и параметры отчетов

     3.3.1 Категории событий

     3.3.2 Отчеты

     3.3.3 Параметр «диагностическая информация»

     3.4 Поля концептуальных структур данных

     3.4.1 Спецификации работы

     3.4.2 Параметры задания ВОС

     3.4.3 Параметры подзадания ВОС

     3.4.4 Параметры действия ПОЗ

     3.4.5 Проформы

     3.4.6 Списки заголовков

     3.4.7 Записи управления передачей

     3.5 Документы ПОЗ

     3.5.1 Документ «отображение-отчета» ПОЗ

     3.5.2 Документ «отображение-работы» ПОЗ

     3.5.3 Документ «отображение-ЗУП» ПОЗ

     3.6 Параметры сервисных примитивов ПОЗ

     3.6.1 Примитивы запроса и подтверждения J-INITIATE

     3.6.2 Сервисные примитивы J-DISPOSE

     3.6.3 Сервисные примитивы J-GIVE

     3.6.4 Примитивы индикации и ответа J-ENQUIRE

     3.6.5 Примитив запроса J-MESSAGE

     3.6.6 Примитив запроса J-SPAWN

     3.6.7 Примитив запроса J-END-SIGNAL

     3.6.8 Примитивы индикации и ответа J-STATUS

     3.6.9 Примитивы индикации J-HOLD, J-RELEASE, J-KILL, J-STOP

     3.6.10 Краткое описание

Раздел 4. Базовый класс

     4.1 Группы примитивов и типы документов для базового класса

     4.1.1 Группы сервисных примитивов

     4.1.2 Типы документов

     4.2 Концептуальные структуры данных для базового класса

     4.2.1 Отчеты

     4.2.2 Спецификации работы

     4.2.3 Операции перемещения документов

     4.2.4 Операции выполнения работы

     4.2.5 Операции перемещения отчетов

     4.2.6 Проформы

     4.2.7 Прозрачность проформ

     4.2.8 Записи управления передачей

     4.2.9 Документы ПОЗ

     4.3 Параметры группы примитивов J-INITIATE для базового класса

     4.3.1 Параметры верхнего уровня

     4.3.2 Параметры задания ВОС

     4.3.3 Параметры подзадания ВОС

     4.3.4 Параметры действия ПОЗ

     4.3.5 Проформы

     4.3.6 Краткое описание информации, содержащейся в примитиве запроса J-INITIATE базового класса

     4.4 Другие группы примитивов в базовом классе

     4.4.1 Примитив J-DISPOSE

     4.4.2 Примитив J-GIVE

     4.4.3 Другие группы примитивов

     4.5 Сводный перечень примитивов и параметров базового класса

Приложение А. Соглашения по услугам ПОЗ

     А.1 Введение

     А.2 Назначение

     А.3 Ссылки

     А.4 Определения

     А.5 Модель ПОЗ

     А.6 Сервисные примитивы

     А.7 Временные диаграммы

     А.8 Соглашения по наименованиям сервисных примитивов

Приложение В. Регистры типов документов

     В.1 Введение

     В.2 Назначение элемента

     В.3 Идентификация

     В.4 Семантика документов

     В.5 Синтаксис передачи

     В.6 Взаимоотношения синтаксиса и семантики

     В.7 Синтаксические соглашения

     В.8 Содержимое регистра

Приложение С. Консультативный материал

     С.1 Введение

     С.2 Архитектура

     С.3 Служба отчетности

     С.4 Обработка

     С.5 Примитивы J-INITIATE

     С.6 Присвоение имен

     С.7 Аутентификация

     С.8 Терминология ПОЗ

     С.9 Параметры заданий ВОС

     С.10 Идентификация систем административного управления

     С.11 Активность ПОЗ (подзадания)

     С.12 Действия при ошибках

     С.13 Документы

     С.14 Ретрансляционные системы ПОЗ

     С.15 Протоколы доступа к агентству

     С.16 Временные соотношения между сервисными примитивами

     С.17 Подмножества и соответствие

     С.18 Взаимодействие базовых и расширенных реализаций

     С.19 Протокол ПОЗ

     С.20 Примеры механизма назначения полномочий

Приложение D. Словарь терминов

 

105 страниц

Дата введения01.01.2000
Добавлен в базу01.09.2013
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

25.03.1999УтвержденГосстандарт России95
РазработанМНИЦ ГК РФ по связи и информатизации
ИзданИПК Издательство стандартов1999 г.

Information technology. Open systems interconnection. Job transfer and manipulation concepts and services

Нормативные ссылки:
Стр. 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

ГОСТ Р ИСО/МЭК 8831-99

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология Взаимосвязь открытых систем

КОНЦЕПЦИИ И УСЛУГИ ПЕРЕДАЧИ И ОБРАБОТКИ ЗАДАНИЙ

БЗ 1-98/83


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

ГОССТАНДАРТ РОССИИ Москва

ГОСТ Р ИСО/МЭК 8831-99

Предисловие

1    РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного Ко

митета Российской Федерации по связи и информатизации

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

2    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 марта

1999 г. N° 92

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 8831—92 «Информационная технология. Взаимосвязь открытых систем. Концепции и услуги передачи и обработки заданий»

3    ВВЕДЕН ВПЕРВЫЕ

©ИПК Издательство стандартов, 1999

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

II

Поля «идентификация инициатора» и «время предоставления» формируются при создании СР в результате предоставления задания инициирующим агентством. Эти поля копируются при создании службой ПОЗ новых СР в результате обработки предыдущих СР.

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

Может быть указано поле «мониторы задания ВОС»; это — открытые системы, в которые должны быть посланы выбранные отчеты.

Поле «селектор отчетов» определяет (для каждого монитора задания ВОС), о каких категориях событий должны посылаться отчеты в такой монитор.

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

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

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

Могут быть указаны поля «срочность» и «удержание» требуемой работы.

Поле «действия ПОЗ» указывает (в зависимости от различных типов СР) конкретные действия, которые должен выполнить поставщик услуг ПОЗ. Эти поля определяют взаимодействие между поставщиком услуг ПОЗ и его локальной системной средой и действия, которые должны быть выполнены им над своими собственными данными или относящимися к отчетам о событиях.

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

2.1.3    Проформы и порождение

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

2.1.4    Исходные, принимающие и исполняющие агентства

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

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

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

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

a)    поставщик услуг ПОЗ может после обработки запроса на выполнение работы (см. 2.1.11) потребовать, чтобы активность была уничтожена, остановлена, задержана или выполнить разъединение;

b)    поставщик услуг ПОЗ может запросить информацию о состоянии активности;

ГОСТ Р ИСО/МЭК 8831-99

c)    если запрошено активностью, агентство в течение существования активности может побудить поставщика услуг ПОЗ сформировать отчет о некотором значащем событии;

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

Все СП, предназначенные для взаимодействия с агентством, относятся к одной СР и не зависят от примитивов, используемых для других СР.

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

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

a)    в форме «специфичная-для-ПОЗ», которая соответствует простому локальному или удаленному доступу в нестандартном виде;

b)    в форме, определенной ГОСТ Р 34.1980.3, которая соответствует локальному или удаленному доступу при условии обеспечения службы ПДУФ.

2.1.5    Задания ВОС

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

2.1.6    Обработка спецификаций работы

2.1.6.1    Нормальная обработка

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

a)    осуществляется доступ к исходным агентствам и документы, переданные этими агентствами, (концептуально) вводятся в СР;

b)    СР (включая любые вложенные документы) передается в другую открытую систему, используя протокол ПОЗ;

c)    документы внутри СР передаются в одно или несколько принимающих и исполняющих агентств, как указано СР;

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

e)    при завершении всех вышеперечисленных действий активности начальная СР уничтожается.

Если при обработке СР были сформированы и новые СР, то после обработки эти новые СР

могут в дальнейшем обусловить доступ к исходным агентствам, как это было описано выше.

Иллюстрация обработки СР, активностей поставщика услуг ПОЗ, относящихся к заданию ВОС, включая уведомляющую службу (см. 2.1.7), выполнение (см. 2.1.11) и взаимоотношения элементов модели ПОЗ, приведена в приложении С.

2.1.6.2    Ошибки при обработке задания ВОС

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

7

Ошибки, обнаруживаемые открытой системой (ответственной за СР) во время ее обработки, трактуются, как описано ниже.

1-3:

Нормальная обработка СР, как описано в 2.1.6.1, включает в себя получение документов из исходных агентств и перемещение документов к исполняющим и принимающим агентствам. Могут возникнуть ошибки, которые будут препятствовать успешному завершению обмена этими документами. Например, СР может содержать имя документа, не существующего в хранилище файлов, доступном указанному исходному агентству, или может содержать имя принимающего или исполняющего агентства, не существующего в указанной открытой системе. Такие ошибки представляют собой события, при которых могут формироваться отчеты ПОЗ (см. 2.1.7).

При обнаружении ошибки, препятствующей получению какого-либо документа, нет необходимости прекращать дальнейшую обработку задания ВОС, поскольку еще возможна дальнейшая успешная обработка других документов, которые были успешно получены. В СР может быть указано, что диагностика ошибки должна быть включена в СР на место того документа, который не был получен; такая диагностика ошибки передается вместо документа предполагаемому принимающему или исполняющему агентству. В этом случае все указанные взаимодействия с агентствами все еще продолжаются, а принимающее или исполняющее агентство решает, какое именно действие необходимо выполнить в случае наличия диагностики ошибки. Ошибка, обнаруженная во время перемещения документа к принимающему или исполняющему агентству или во время попытки передачи ПОЗ, препятствует дальнейшей обработке задания ВОС. В этом случае можно запросить, чтобы поставщик услуг ПОЗ сохранил СР на определенный период времени, чтобы позволить последующей обработкой СР исправить ошибку (см. 2.1.11). (СР может также указать такую форму обработки ошибок, при котором документы должны быть получены от исходного агентства). Например, ошибочное имя принимающего, исходного агентства или целевой системы может быть изменено на правильное. Если ошибка не была исправлена по истечении этого периода времени, поставщик услуг ПОЗ удаляет СР, формируя отчет об аварийном завершении (см. 2.1.7). Такое окончательное действие может быть указано в СР в качестве непосредственного действия при ошибках и это действие выполняет только обработку ошибок, обеспечиваемую в подмножестве базового класса.

Обработка ошибок открытой системой, которая ответственна за СР, может быть представлена следующим образом:

a)    при обращении к исходному агентству:

1)    вставить диагностическое сообщение и продолжить;

2)    аварийно завершить;

3)    приостановить, чтобы позволить пользователю исправить ошибку и позже повторить

попытку;

b)    при обращении к принимающему агентству:

1)    аварийно завершить;

2)    приостановить, чтобы позволить пользователю исправить ошибку и позже повторить

попытку;

c)    при попытке передать СР:

1)    аварийно завершить;

2)    приостановить, чтобы позволить пользователю исправить ошибку и позже повторить

попытку.

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

2.1.7 Отчетность и функция монитора

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

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

ГОСТ Р ИСО/МЭК 8831-99

чтобы все отчеты были переданы монитором задания ВОС принимающим агентствам по своему выбору. За предоставление отчета в соответствующем формате (читабельном) ответственность несет принимающее агентство, и этот процесс не стандартизован.

Данные, необходимые для построения СР отчета и выбора событий, о которых следует уведомить, включаются в поля той СР, для которой предстоит выполнить отчет.

Обеспечиваются два типа монитора задания ВОС. Первичный монитор (и категории отчетов, которые должны быть посланы к нему) определяется поставщиком услуг ПОЗ в системе предоставления заданий ВОС. Эти данные могут изменяться только САУ данной открытой системы. Вторичные мониторы (и категории отчетов, которые должны посылаться к каждому монитору) определяются пользователем с помощью параметров в СП инициирования. Пользователь может изменить эти данные при выполнении работы (см. 2.1.11).

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

СР отчетов отличаются от других СР следующим:

a)    СР отчетов не содержат никаких документов пользователя; информация отчета содержится в них в закодированной форме;

b)    СР отчетов не создается с помощью порождения из проформы; она создается из спецификации монитора, содержащейся в начальной СР, и копируется во все СР, сформированные порождением;

c)    идентификация СР отчетов является такой же, как и для СР, о которых должен быть сформирован отчет;

d)    обработка СР отчетов никогда не вызывает создания дополнительных отчетов, которые должны быть сформированы; ошибки, обнаруженные во время их обработки или передачи, вызывают потерю этих СР;

e)    СР отчетов содержат все возможности (см. 2.1.13), которые имелись в тех СР, о которых должны быть выданы отчеты; однако они игнорируются, если предпринимается любая попытка модифицировать СР отчетов; эти СР существуют, чтобы предоставить информацию монитору задания ВОС при обработке последующих запросов управления отчетами (см. 2.1.10);

f)    передача СР отчетов (и управление, см. 2.1.11) имеет более высокий приоритет относительно другого трафика ПОЗ.

Для уведомляющей службы могут быть выбраны следующие категории событий (определены в 3.3):

a)    формирование задания ВОС;

b)    передача (ответственности за) СР из одной открытой системы в другую;

c)    формирование новой СР путем порождения;

d)    прием документов принимающими или исполняющими агентствами;

e)    нормальное завершение СР после завершения подзадания;

f)    преждевременное окончание подзадания вследствие управляющего запроса (ОСТАНОВ);

g)    удаление СР и завершение подзадания вследствие управляющего запроса (УНИЧТОЖИТЬ);

h)    модификация подзадания с помощью управляющего запроса;

i)    обнаружение ошибок в СР, результатом чего является вложенная в нее диагностика ошибки;

j)    задержка СР для корректировки ошибок;

k)    аварийное завершение СР вследствие ошибок;

l)    формирование учетной информации, относящейся к подзаданию, из функциональной среды локальных систем;

ш) формирование информации активностью в исполняющем агентстве (сообщения пользователя);

п) аварийное завершение СР вследствие запроса средств, которые не обеспечены;

о) попытка модификации СР подзаданием, которое не имеет необходимых полномочий;

9

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

СР отчетов содержит одно или несколько отчетов. Каждый отчет имеет следующие параметры:

a)    имя открытой системы, формирующей отчет (см. 2.1.14);

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

с)    тип события, о котором необходимо выдать отчет;

d)    дата и время формирования отчета (факультативно);

e)    нестандартное текстовое сообщение.

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

2.1.8 Исполнение, совмещение и восстановление

2.1.8.1    Общее описание

Чтобы обеспечить правильное выполнение услуги ПОЗ при наличии сбоев в прикладном процессе или системе связи (восстановление после ошибок), нечувствительность к влиянию других активностей (управление совмещением) и возможность выполнения задания ВОС в виде одного или нескольких элементарных действий (исполнение), используются процедуры СИВ, определенные в ГОСТ Р ИСО/МЭК 9804.

Каждая передача ПОЗ между открытыми системами и каждое взаимодействие с агентством использует СП, к которым применяется семантика СИВ. Процедуры, определенные в ГОСТ Р ИСО/МЭК 9804, выполняются каждой открытой системой и концептуально — каждым агентством.

В приложении С к ГОСТ Р ИСО/МЭК 9804 описывается сущность СИВ для тех, кто не знаком с его работой. Понимание работы СИВ существенно для понимания ПОЗ.

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

Служба СИВ предоставляет параметр «данные пользователя» во всех примитивах.

Эти данные пользователя используются, чтобы:

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

b)    указать управляемому ДО набор символов, которые ГУЛО предпочитает для диагностических сообщений;

c)    указать, когда управляемый ДО возвратится в исходное состояние, может ли последующая попытка быть успешной («повторить—позже») или сбой был по той же причине («не-повторять»);

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

2.1.8.2    Уровни исполнения операций для ПОЗ

Чтобы выполнить задание ВОС, служба ПОЗ использует одно или несколько элементарных действий в соответствии с уровнем исполнения операций, запрошенного инициирующим агентством. Начальное элементарное действие начинается в тот момент, когда инициирующее агентство предоставляет поставщику услуг ПОЗ задание ВОС. (Инициирующее агентство представляет собой ГУЛО исполнения операций для этого начального элементарного действия).

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

2.1.8.2.1 Уровень исполнения «завершение» (уровень 3)

Наивысшим уровнем исполнения является ЗАВЕРШЕНИЕ (уровень 3). В этом случае все задание ВОС завершается как часть начального элементарного действия.

Когда исполнение имеет место, вся указанная работа завершена и все СР, построенные как часть обработки этого задания ВОС, считаются полностью обработанными и прекращают свое существование.

10

ГОСТ Р ИСО/МЭК 8831-99

Такой уровень исполнения операций иногда описывается, как «неавтономная» обработка.

2.1.8.2.2    Уровень исполнения «приемлемый для агентства» (уровень 2)

Следующим более низким уровнем исполнения операций является ПРИЕМЛЕМЫЙ ДЛЯ АГЕНТСТВА (уровень 2). В этом случае исполнение по отношению к начальному элементарному действию означает, что начальное подзадание ВОС было обработано, по меньшей мере, до момента, когда все указанные исходные агентства стали доступными, и все взаимодействия с принимающими и исполняющими агентствами представили в результате соответствующие документы, обеспечиваемые данным агентством, для более позднего завершения подзадания ВОС, как части последующих элементарных действий.

2.1.8.2.3    Уровень исполнения «приемлемый для поставщика» (уровень 1)

Самым низким уровнем исполнения операций является ПРИЕМЛЕМЫЙ ДЛЯ ПОСТАВЩИКА (уровень 1). (Этот уровень относится также ко всем элементарным действиям, инициированным после начального элементарного действия). На этом уровне начальное элементарное действие заканчивается сохранением СР, сформированной поставщиком услуг ПОЗ, и она становится видимой другим открытым системам. При этом нет гарантии, что указанные исходные документы будут доступны, или какой-либо материал будет передан принимающим или исполняющим агентствам. Этот уровень исполнения всегда доступен пользователю, даже если локальная система в данный момент неспособна установить никакой связи с другими открытыми системами. Он может быть описан как «автономная» обработка.

2.1.8.2.4    Определение действий агентства

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

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

2.1.8.3    Тай м-а у т ы

Не указываются для обеспечения требуемых ответов. Неспособность выполнить требуемые действия из-за временного отсутствия ресурсов (перегруженность или управление параллельностью действий) приводит к локальным повторениям в этой открытой системе. ГУЛО исполнения операций (например, инициирующее агентство) может установить тайм-аут, в зависимости от локальной PC и при истечении тайм-аута выдать СП возврата.

2.1.8.4    Данные пользователя при запуске элементарного действия

Содержат параметры «уровень исполнения операций» и «указатель кода диагностики».

2.1.8.4.1 Уровень исполнения

Параметр «уровень исполнения» представляет собой целое число (см. 2.1.8.2). Самым низким уровнем исполнения является уровень 1, самым высоким — уровень 3.

Если параметр «уровень исполнения» имеет максимальное значение, все действия завершаются прежде, чем управляемый ЛО предложит уровень исполнения. Если он имеет минимальное значение, управляемому ЛО необходимо только отметить действия, которые должны быть выполнены (например, сохранение данных), и выполнить их несколько позже.

Примечание — Управляемый ЛО может сделать попытку выполнить действие на более высоком уровне исполнения, чем это затребовал его управляющий ЛО, возможно, включая несколько новых управляемых ЛО. Если эта попытка заканчивается безуспешно (ПОВТОРИТЬ-ПОЗЖЕ), то имеется возможность возвратить в первоначальное состояние все новые управляемые ЛО и выполнить действие на более низком уровне исполнения исключительно в зависимости от локальной PC.

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

Элементарное действие, начатое управляемым ЛО, имеет равный или более высокий уровень исполнения, чем принятый от управляющего ЛО в начале действия.

11

2.1.8.4.2 Указатель кода диагностики

Параметр «указатель кода диагностики» представляет собой список определителей кода. Каждый определитель кода состоит из одного или нескольких целых чисел или имеет значение «ВСЕ». Каждое целое число представляет собой номер регистра наборов знаков ИСО (см. ИСО 2375).

Каждый определитель кода имеет ссылку на один или несколько наборов графических знаков в элементах регистра с данными номерами. Каждое последующее диагностическое сообщение, сформированное ПОЗ, содержит только знак ПРОБЕЛ вместе со знаками из набора знаков, на который указывает один из определителей кода.

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

Определители кода представлены в указателе кода диагностики в порядке предпочтительности ГУЛО СИВ. Определитель кода с одним числом 2, указывающим графические знаки международной справочной версии по ГОСТ 27463, всегда неявно существует, по меньшей мере, в качестве предпочтительного выбора. Пустой указатель кода диагностики указывает только ГОСТ 27463.

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

2.1.8.5 Использование данных пользователя СИВ при предложении исполнения

Данное использование включает в себя параметр «уровень исполнения», необязательную предупреждающую диагностику и необязательную учетную информацию.

2.1.8.5.1    Уровень исполнения

Формат параметра «уровень исполнения» описан в 2.1.8.4.1. Его значение в предложении уровня исполнения выше или равно его значению при запуске элементарного действия.

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

2.1.8.5.2    Параметр «диагностика»

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

a)    имени формирователя диагностического сообщения;

b)    кода диагностики ПОЗ;

c)    читабельного текста сообщения или структуры данных ПДУФ, содержащей предупреждение.

Имя формирователя диагностического сообщения представляет собой символическое имя прикладного процесса. Его формат не определяется настоящим стандартом. Он однозначно идентифицирует формирователя сообщения.

Значения кода диагностики ПОЗ описываются в спецификациях протокола ПОЗ.

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

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

Примечания

1    Количество строк знаков не ограничивается.

2    Язык, используемый в тексте, выбирается формирователем диагностического сообщения; требуемые наборы знаков могут использоваться в качестве указания предпочитаемого языка.

2.1.8.5.3    Параметр «учет»

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

Его формат представляет собой список, состоящий из четырех частей и содержит:

a)    (глобально однозначную) идентификацию счета (см. 2.1.13);

b)    идентификатор ресурса в виде строки знаков;

ГОСТ Р ИСО/МЭК 8831-99

c)    единицу затрат в виде строки знаков;

d)    затраты в виде целого числа.

Значения в Ь) и с) назначаются идентификационным полномочием (см. 2.1.13), связанным с идентификацией учета.

2.1.8.6 Использование данных пользователя СИВ при возврате в исходное состояние

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

Отметим, что средства СИВ не гарантируют передачу данных пользователя при возврате примитива в исходное состояние.

2.1.8.6.1    Параметр «диагностика»

Указывает значение «повторить-позже» или «не-повторять».

В значении «не-повторять» параметр состоит из одного или нескольких диагностических сообщений, содержащих:

a)    имя формирователя диагностического сообщения;

b)    код диагностики ПОЗ;

c)    читабельный текст сообщения, или структуру данных службы ПДУФ, содержащий значение «не-повторять».

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

Параметр «тайм-аут повторения», при его наличии, указывает, что управляющий ЛО должен подождать указанное время перед попыткой повторить элементарное действие. Он может игнорироваться управляющим Л О.

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

Порядок предпочтительности следующий:

a)    предупреждение (наинизшая);

b)    «повторить-позже»;

c)    «не-повторять» (наивысшая).

2.1.8.6.2    Параметр «учет»

Имеет формат, описанный в 2.1.8.5.3.

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

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

2.1.9    Управление передачами

ЗУП используется для определения СР, подходящих для передачи в другую (указанную) открытую систему, и указания числа таких передач, которые могут выполняться одновременно.

ЗУП не влияет на передачу СР управления передачей (см. 2.1.12). Она может управлять всеми другими типами СР в зависимости от значения селекторов.

Открытая система с СР для передачи другой открытой системе при отсутствии ЗУП для адресуемой системы пытается выполнить передачи по порядку и со степенью совмещения выполнения, определяемой локально.

ЗУП, при ее наличии, побуждает PC ограничить попытки передач количеством, необходимым для продолжения работы СР с заданными характеристиками.

Наличие ЗУП может предотвратить исполнение для элементарных действий. Такие отказы всегда отмечаются как «повторить позже».

2.1.10    Управление отчетами

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

Первый тип — операция УДАЛИТЬ, которая вызывает удаление всех принятых отчетов об указанном задании ВОС или о дереве подзаданий. Параметром такого типа является только «идентификация СР», который используется для ссылки на отчеты в указанной СР или в спецификации, созданной из нее.

13

Второй тип — операция ОТОБРАЗИТЬ, которая имеет два параметра. Первый параметр «идентификация СР», используется для обращения к части или ко всему заданию ВОС. Второй параметр — «имя документа», на которое ссылается проформа, содержащаяся в управляющей СР. Эта проформа определяет подзадание произвольной сложности для размещения поименованного документа.

Действием, которое выполняется поставщиком услуг ПОЗ в открытой системе, является прием каждого отчета, который был получен в соответствии с указанной СР, в том порядке, в котором они поступали, и формирование документа, содержащего отчет. Если две операции ОТОБРАЗИТЬ указывают одно и то же имя документа, то обе эти операции помещаются в один и тот же документ. Конец активности формирует обычным способом порождение новых СР из проформ; они образуют документ отображения.

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

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

2.1.11 Выполнение работы

СР выполнения работы содержит одну или несколько операций выполнения работы ПОЗ. Они предназначены для операций «выбор», «модификация», «уничтожение», «останов», «отображение» и связанных с ними подзаданий. (Действия этих операций описываются ниже).

Первой является операция «выбор»; выбранными СР или проформами являются такие, к которым применяются все операции, предшествующие следующей операции «выбор». Формат селектора СР описывается в 2.1.11.1.

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

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

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

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

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

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

Если подзаданием А предпринимается неполномочная попытка модификации СР В, то результатом является событие ПОПЫТКА-НАРУШЕНИЯ для В, по которому может быть послан отчет в один или несколько пунктов монитора В.

ГОСТ Р ИСО/МЭК 8831-99

2.1.11.1 Селекторы

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

Базовые тесты имеют формат

Оператор имя-поля значение, где диапазон допустимых имен полей и операций определен в разделе 3.

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

СР также могут быть выбраны согласно полям проформ, которые они содержат.

2.1.11.2. Обновления

Операция обновления имеет формат

Оператор имя-поля значение и используется в операции «модификация», чтобы указать, какие изменения должны быть выполнены. Это указывается в разделе 3. Имена определенных полей, которые доступны для выбора, не могут модифицироваться.

Концептуальная структура данных «список-заголовков» используется кроме того для указания обновления, но изменения этих полей вызывают соответствующие изменениям в соответствующей СР.

2.1.12    Управление передачами

СР управления передачами содержит одну или несколько операций управления передачами.

Имеются операции управления передачами ПОЗ для установки, отображения и проверки ЗУП.

Операция «установка» имеет параметр, представляющий ЗУП.

Операция «отображение» имеет один параметр, который идентифицирует ЗУП, и второй параметр, содержащий имя документа; он отображает текущую ЗУП в указанном документе для формирования путем порождения.

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

СР управления передачами нуждается в элементе полномочий для системы управления любой открытой системы, на которую имелся указатель в ЗУП операции «установка» или «отображение», а также для системы управления открытой системы, выполняющей операцию «проверка» (см. 2.1.13).

2.1.13    Полномочия и учет

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

Чтобы воспринять поле доступа как «уже проверенное», должна быть доступна аутентифицированная идентификация открытой системы, которая выполнила проверку. Это достигается пошаговым способом. Услуги более нижнего уровня предоставляют поставщику услуг ПОЗ аутентифицированное имя вызывающей открытой системы. Эти данные записываются в СР, так что она содержит имя каждой открытой системы, через которую передается СР (или имя одного из ее «порождающего»), Таким образом, открытая система способна определить при помощи проверки этих данных доступность элементов полномочий, требующих, чтобы идентификация была уже аутентифицирована. (Подробная операция этой процедуры указывается в ГОСТ Р ИСО/МЭК 8832). Дальнейшее описание (и примеры) такого механизма содержатся в приложении С.

Элемент полномочий может идентифицировать пользователя, систему управления идентификационного полномочия или САУ открытой системы.

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

15

ГОСТ Р ИСО/МЭК 8831-99

Содержание

Предисловие......................................... II

Раздел 1. Общее описание......... I

1.1    Назначение............. 1

1.2    Нормативные ссылки................................. 1

1.3    Определения..................................... 2

1.3.1    Определения услуг СПВ............................. 2

1.3.2    Определения услуг ПОЗ............................. 2

1.4    Сокращения............ 4

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

Раздел 2. Обзор....................................... 5

2.1    Обзор и общее описание...... 5

2.1.1    Обзор...................................... 5

2.1.2    Содержимое спецификации работы....................... 5

2Л .3 Проформы и порождение............................ 6

2.1.4    Исходные, принимающие и исполняющие агентства.............. 6

2.1.5    Задания ВОС.......... 7

2.1.6    Обработка спецификаций работы........................ 7

2.1.7    Отчетность и функция монитора........................ 8

2.1.8    Исполнение, совмещение и восстановление.................. 10

2.1.9    Управление передачами ............................. 13

2.1.10    Управление отчетами..... 13

2.1.11    Выполнение работы.............................. 14

2.1.12    Управление передачами............................ 15

2.1.13    Полномочия и учет...... 15

2.1.14    Идентификация спецификаций работы.................... 16

2.1.15    Ответственность службы отчетности...................... 16

2.1.16    Документы................................... 18

2.1.17    Промежуточные системы ПОЗ......................... 18

2.2    Обзор службы.................................... 19

2.3    Базовые и расширенные реализующие системы................... 19

2.4    Модель спецификации услуг ............................. 20

Раздел 3. Определение примитивов ............................. 21

3.1    Сервисные примитивы ПОЗ............................. 21

3.1.1    Группы сервисных примитивов ......................... 21

3.1.2    Компоненты групп сервисных примитивов................... 22

3.1.3    Параметры примитивов, относящихся к СИВ.................. 23

3.1.4    Последовательность групп сервисных примитивов............... 24

3.1.5    Последовательность сервисных примитивов................... 24

3.2    Нотация для сервисных примитивов и определение структуры данных....... 25

3.2.1    Базовые типы данных.............................. 25

3.2.2    Механизмы структурирования.......................... 25

3.2.3    Определение базовых типов данных....................... 26

3.3 События ПОЗ и параметры отчетов ........................ 27

3.3.1    Категории событий............................... 28

3.3.2    Отчеты...................................... 29

3.3.3    Параметр «диагностическая информация»................... 31

3.4    Поля концептуальных структур данных....................... 32

3.4.1    Спецификации работы............................. 33

3.4.2    Параметры задания ВОС............................. 34

3.4.3    Параметры подзадания ВОС........................... 37

3.4.4    Параметры действия ПОЗ ............................ 39

3.4.5    Проформы.................................... 50

3.4.6    Списки заголовков............................... 51

III

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

Полномочные данные также предоставляют имя идентификациям пользователей, которым дается разрешение выполнять модификации в этой СР. Неявное разрешение предоставляется допустимым идентификациям, отображающим САУ идентификационными полномочиями, вводящую эти идентификации, и тем идентификациям, которые отображают САУ открытыми системами для открытых систем, включенных в это задание ВОС.

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

Разрешение модифицировать ЗУП явно предоставляется аутентифицированным идентификациям, отображающим включение САУ открытыми системами.

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

2.1.14    Идентификация спецификаций работы

Идентификатор СР предоставляет явное имя, посредством которого к СР можно обращаться для формирования отчета или СР обработки.

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

В результате все СР имеют идентификацию, известную как идентификатор СР. Полное задание ВОС, которое представляется множеством всех его СР, может указываться путем ссылки на имя системы предоставления задания ВОС или:

а) идентификации инициирующего пользователя и имени задания ВОС;

в) локального указателя задания ВОС.

Отдельное подзадание может указываться ссылкой на идентификатор полной СР. Группа подзаданий с общим источником может указываться ссылкой на идентификатор СР их источника.

2.1.15    Ответственность службы отчетности

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

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

Формирование отчетов с уровнем исполнения 1, или выполняемое отдельной уведомляющей службой, никогда не является предметом отказа. Результатом последующей обработки отчета может быть сбой, при котором это формирование может быть отклонено. О таких событиях не сообщается. При уровне исполнения 2 или 3 безуспешность доставки отчетов, сформированных интегрированной уведомляющей службой, вызывают безуспешность выполнения всего элементарного действия.

2.1.15.1    Отдельная служба отчетности

К отчетам, формируемым в качестве отдельных элементарных действий, относятся:

a)    отчеты учетной информации;

b)    отчеты о попытке нарушений защиты;

c)    отчеты о безуспешности элементарного действия, выражающееся в невыполнении СР или в его аварийном завершении.

2.1.15.2    Интегрированная служба отчетности

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

a)    отчеты о том, что по примитиву J-INITIATE создана новая СР;

b)    отчеты о порождении новой СР;

16

ГОСТ Р ИСО/МЭК 8831-99

3.4.7 Записи управления передачей.......................... 53

3.5    Документы ПОЗ................................... 54

3.5.1    Документ «отображение-отчета» ПОЗ...................... 54

3.5.2    Документ «отображение-работы» ПОЗ...................... 54

3.5.3    Документ «отображение-ЗУП» ПОЗ....................... 55

3.6    Параметры сервисных примитивов ПОЗ....................... 55

3.6.1    Примитивы запроса и подтверждения J-INITIATE............... 55

3.6.2    Сервисные примитивы J-DISPOSE....................... 56

3.6.3    Сервисные примитивы J-GIVE......................... 57

3.6.4    Примитивы индикации и ответа J-ENQUIRE.................. 58

3.6.5    Примитив запроса J-MESSAGE......................... 58

3.6.6    Примитив запроса J-SPAWN.......................... 59

3.6.7    Примитив запроса J-END-SIGNAL....................... 59

3.6.8    Примитивы индикации и ответа J-STATUS................... 59

3.6.9    Примитивы индикации J-HOLD, J-RELEASE, J-KILL, J-STOP........ 59

3.6.10    Краткое описание............................... 60

Раздел 4. Базовый класс.................................. 62

4.1    Группы примитивов и типы документов для базового класса............ 62

4.1.1    Группы сервисных примитивов......................... 62

4.1.2    Типы документов................................ 62

4.2    Концептуальные структуры данных для базового класса............... 63

4.2.1    Отчеты...................................... 63

4.2.2    Спецификации работы.............................. 64

4.2.3    Операции перемещения документов....................... 65

4.2.4    Операции выполнения работы.......................... 65

4.2.5    Операции перемещения отчетов......................... 66

4.2.6    Проформы.................................... 66

4.2.7    Прозрачность проформ............................. 66

4.2.8    Записи управления передачей......................... 66

4.2.9    Документы ПОЗ................................. 66

4.3    Параметры группы примитивов J-INITIATE для базового класса.......... 67

4.3.1    Параметры верхнего уровня........................... 67

4.3.2    Параметры задания ВОС............................. 67

4.3.3    Параметры подзадания ВОС........................... 67

4.3.4    Параметры действия ПОЗ............................ 67

4.3.5    Проформы.................................... 68

4.3.6    Краткое описание информации, содержащейся в примитиве запроса J-INITIATE

базового класса................................. 69

4.4 Другие группы примитивов в базовом классе .................... 69

4.4.1    Примитив J-DISPOSE.............................. 69

4.4.2    Примитив J-GIVE................................ 69

4.4.3    Другие группы примитивов........................... 69

4.5    Сводный перечень примитивов и параметров базового класса............ 69

Приложение А. Соглашения по услугам ПОЗ........................ 71

А.1 Введение....................................... 71

А.2 Назначение..................................... 71

А. 3 Ссылки........................................ 71

А.4 Определения..................................... 71

А.5 Модель ПОЗ..................................... 71

А.6 Сервисные примитивы............................... 71

А.7 Временные диаграммы................................ 72

A. 8 Соглашения по наименованиям сервисных примитивов............... 74

Приложение В. Регистры типов документов........................ 75

B. 1 Введение....................................... 75

В.2 Назначение элемента................................ 75

IV

ГОСТ Р ИСО/МЭК 8831-99

В.З Идентификация................................... 75

В.4 Семантика документов................................ 75

В.5 Синтаксис передачи................................. 75

В.6 Взаимоотношения синтаксиса и семантики..................... 76

В.7 Синтаксические соглашения............................. 76

B. 8 Содержимое регистра................................ 76

Приложение С. Консультативный материал......................... 77

С Л Введение....................................... 77

C. 2 Архитектура..................................... 77

С.З Служба отчетности................................. 79

С.4 Обработка...................................... 79

С.5 Примитивы J-INITIATE............................... 79

С.6 Присвоение имен.................................. 80

С.7 Аутентификация................................... 80

С.8 Терминология ПОЗ................................. 81

С.9 Параметры заданий ВОС............................... 81

СЛО Идентификация систем административного управления.............. 82

С Л1 Активность ПОЗ (подзадания)........................... 82

СЛ2 Действия при ошибках............................... 87

СЛЗ Документы..................................... 87

С. 14 Ретрансляционные системы ПОЗ.......................... 87

С Л 5 Протоколы доступа к агентству........................... 91

С Л 6 Временные соотношения между сервисными примитивами............ 91

С Л 7 Подмножества и соответствие........................... 91

С Л 8 Взаимодействие базовых и расширенных реализаций............... 94

С Л 9 Протокол ПОЗ................................... 95

С.20 Примеры механизма назначения полномочий................... 95

Приложение D. Словарь терминов............................. 97

V

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология Взаимосвязь открытых систем

КОНЦЕПЦИИ И УСЛУГИ ПЕРЕДАЧИ И ОБРАБОТКИ ЗАДАНИЙ

Information technology. Open Systems Interconnection.

Job transfer and manipulation concepts and services

Дата введения 2000—01—01

РАЗДЕЛ 1. ОБЩЕЕ ОПИСАНИЕ

1.1    Назначение

Настоящий стандарт является стандартом прикладного уровня архитектуры взаимосвязи открытых систем (ВОС), установленной ГОСТ 28906.

Он определяет концепции и услуги для ПОЗ.

Настоящий стандарт требует от пользователя ПОЗ:

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

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

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

Настоящий стандарт обеспечивает возможность для:

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

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

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

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

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

Настоящий стандарт содержит ссылки на следующие стандарты:

ГОСТ 34.971-91 (ИСО 8822—88) Информационная технология. Взаимосвязь открытых систем. Определение услуг уровня представления с установлением соединения

ГОСТ 34.973-91 (ИСО/МЭК 8824—87) Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)

ГОСТ 34.981-91 (ИСО 8649—88) Системы обработки информации. Взаимосвязь открытых систем. Определение службы для элемента услуги управления ассоциацией

ГОСТ 27463-87 Обработка информации. Набор символов 7-битного кода ИСО для обмена информацией

ГОСТ 27466-87 Обработка информации. Наборы символов 7- и 8-битных кодов ИСО. Методы расширения кода

ГОСТ 28906-91 (ИСО 7498—84, Доп. 1—84 ИСО 7498—84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель

1

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

1-2-1048

ГОСТ Р 34.1980.3-92 (ИСО 8571-3—88) Информационная технология и взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла

ГОСТ Р ИСО/ТО 8509—95. Системы обработки информации. Взаимосвязь открытых систем. Условные обозначения служб

ГОСТ Р ИСО/МЭК 9804—96 Системы обработки информации. Взаимосвязь открытых систем. Определение услуг для сервисного элемента исполнения, совмещения и восстановления

ИСО 2375—851 Обработка данных и процедуры регистрации выходной последовательности

ИСО/МЭК 8832—921 Информационная технология. Взаимосвязь открытых систем. Спецификация протокола базового класса и полного протокола для передачи и обработки заданий.

1.3 Определения

1.3.1    Определения услуг СПВ

В настоящем стандарте применимы следующие термины, определенные в ГОСТ Р ИСО/МЭК 9804:

a)    элементарное действие;

b)    главный управляющий логический объект (ГУЛ О);

c)    управляющий логический о б ъ е к т (Л О);

d)    управляемый Л О;

e)    исполнение;

Т)возврат в первоначальное состояние.

1.3.2    О п р е д е л е н и я услуг ПОЗ

Определения группируются в основные категории в соответствии с 2.1.

Для настоящего стандарта применяют следующие определения.

1.3.2.1    Общее описание

1.3.2.1.1    Агентство — абстрактное описание таких функций реальной открытой системы, которые необходимы для обеспечения услуги ПОЗ.

1.3.2.1.2    Спецификация работы (С Р) — концептуальная структура данных, формируемая поставщиком услуг ПОЗ, указывающая определенным способом работу, которая должна быть выполнена.

1.3.2.1.3    Документ — совокупность данных, при помощи которых формируют часть СР и элемент взаимодействия между поставщиком услуг ПОЗ и агентством.

1.3.2.1.4    Инициирующее агентство — агентство, которое вызывает создание СР.

1.3.2.2 Проформы и порождение

1.3.2.2.1    Проформа — часть СР, которая указывает дальнейшую работу и используется для формирования новой СР, как части выполнения более ранней работы.

1.3.2.2.2    Пор ождение — процесс получения данных из проформы и использования их для формирования новой СР.

1.3.2.2.3    Данные управления порождением — данные, содержащиеся в проформе и управляющие состояниями, при которых имеет место порождение из этой проформы.

1.3.2.2.4    Проформа верхнего уровня — проформа, которая не содержится внутри никакой другой проформы.

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

1.3.2.3 Исходные, принимающие и исполняющие агентства

1.3.2.3.1    Исходное агентство — любая часть открытой системы, которая может предоставить документы в результате обработки СР для формирования новой СР, когда эти документы запрашиваются поставщиком услуг ПОЗ.

1.3.2.3.2    Принимающее агентство — любая часть открытой системы, в которую в результате обработки СР поставщиком услуг ПОЗ могут быть переданы документы.

Примечание — Исходные и принимающие агентства могут получать и размещать документы местными средствами при помощи использования нестандартных протоколов или использования службы «передача файлов, доступ к файлам и управление файлами» (ПДУФ).

ГОСТ Р ИСО/МЭК 8831-99

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

1.3.2.3.4    Активность {в агентстве) — работа, выполняемая агентством, инициируемым сервисным примитивом (СП), выданным этому агентству поставщиком услуг ПОЗ; завершение этой активности указывается СП, выданным этим агентством поставщику услуг ПОЗ.

1.3.2.4    Задания ВОС

1.3.2.4.1    Начальная спецификация работы— СР, созданная в результате выдачи инициирующим агентством СП инициирования.

1.3.2.4.2    Задание ВОС — общая работа во всех открытых системах, являющаяся непосредственно или косвенно результатом обработки начальной СР.

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

'.3.2.4.4 П р едзстазлеяие задания ВОС— использование СП кнкцккрованкя инициирующим агентством для создания начальной СР.

1.3.2.4.5    Система предоставления заданий ВОС — открытая система, в которой имеет место предоставление задания ВОС.

1.3.2.5    Отчетность и функция монитора

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

1.3.2.5.2    Мониторы задания В О С — открытые системы, в которые посылаются отчеты ПОЗ о состоянии определенного задания ВОС.

1.3.2.5.3    С Р отчета — тип СР, созданной поставщиком услуг ПОЗ для перемещения отчетов ПОЗ; целевая открытая система для таких СР представляет собой открытую систему мониторов задания ВОС.

1.3.2.6    Исполнение, совмещение и восстановление (СИВ)

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

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

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

1.3.2.6.4    Диагностика «н е-п овторять» — информация, передаваемая услугой СПВ при возврате в исходное состояние, если действие не может быть завершено и позже попытка повторного выполнения не предполагается.

1.3.2.7    Управление передачами

1.3.2.7.1    Передача С Р — элементарное действие, при котором СР создается в принимающей открытой системе и разрушается в Досылающей открытой системе.

1.3.2.7.2    Запись управления передачей (3 У П) — концептуальная структура данных, сохраняемая открытой системой, для управления передачей СР и введением СП.

1.3.2.8    Управление отчетами

1.3.2.8.1    Операции управления отчетами — операции, запрашивающие удаление или отображение отчетов, сохраняемых открытой системой, назначенной некоторой СР в качестве пункта монитора.

1.3.2.8.2    Спецификация работы управления отчетами — СР, содержащая операции управления отчетами.

1.3.2.9    Выполнение работы

3

1.3.2.9.1 Операции выполнения работы — операции, которые выбирают одну или несколько СР или проформ и запрашивает отображение, уничтожение, останов или модификацию.

1-2*

ГОСТ Р ИСО/МЭК 8831-99

1.3.2.9.2    С Р выполнения работы — СР, содержащая операции выполнения работы.

1.3.2.9.3    Селектор — данные, которые используются для указания выбора СР.

1.3.2.9.4    Обновление — данные, которые используются для модификации выбранной СР или проформы.

1.3.2.10    Управление передачами

1.3.2.10.1    Операции управления передачами — операции, запрашивающие ЗУП установки, отображения или проверки.

1.3.2.10.2    Спецификация работы управления передачами — управляющие СР, содержащие операции управления передачами.

1.3.2.11    Полномочия и учет

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

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

1.3.2.11.3    Идентификация пользователя — данные, которые могут использоваться в определенном контексте, чтобы идентифицировать пользователя, от имени которого должна запрашиваться работа.

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

П р имечание — Идентификация пользователя и счета состоят из имени идентифицированного полномочия вместе с одной из идентификаций, которые выдает этот пользователь.

1.3.2.11.5    Идентификация САУ открытыми системами — имя открытой системы, которая, если она аутентифицирована, предоставляет полномочия активностям ПОЗ или подсчитывает расходы, затраченные на административное управление этой открытой системой.

П р имечание — Примерами таких активностей является удержаний СР, подлежащих передаче, или установка ЗУП.

1.3.2.11.6    Идентификация САУ идентифицированными уполномоченными— имя идентифицированного уполномоченного, который, будучи аутентифицирован, предоставляет полномочия активностям ПОЗ, относящимся к управлению активностью, инициируемой идентификациями пользователя, выдаваемыми этим уполномоченным.

1.3.2.12    Идентификация СР

1.3.2.12.1    Л окал ьный указатель задания ВО С— указатель задания ВОС, который является уникальным в пределах системы предоставления задания ВОС, назначенной этой открытой системой.

1.3.2.12.2    Идентификация инициирования — идентификация, обеспечиваемая пользователем ПОЗ во время предоставления задания для идентификации инициатора задания ВОС.

1.3.2.12.3    Имя задания ВОС— строка знаков, обеспечиваемая инициирующим агентством во время предоставления задания ВОС.

1.3.2.12.4    Идентификатор С Р — уникальный указатель СР, содержащий имя системы предоставления задания ВОС, идентификацию инициирующего пользователя, локальный указатель задания ВОС и имя задания ВОС; если СР была создана порождением, идентификатор содержит также одно или несколько имен проформ.

1.4    Сокращения

ВОС — взаимосвязь открытых систем;

ГУЛО — главный управляющий логический объект;

ЗУП    —    запись управления передачей;

ЛО    —    логический объект;

ПДУФ    —    передача, доступ и управление файлом;

ПОЗ    —    передача и обработка заданий;

4

ГОСТ Р ИСО/МЭК 8831-99

PC — реализующая система;

САУ    —    система административного    управления;

СП    —    сервисный примитив;

СИВ    —    исполнение, совмещение и    восстановление;

СР    —    спецификация работы;

СЭПУ — сервисный элемент прикладного уровня;

СЭУА — сервисный элемент управления ассоциацией.

1.5 Соглашения

Соглашения, используемые в настоящем стандарте, приведены в приложении А.

РАЗДЕЛ 2. ОБЗОР

2.1    Обзор и общее описание

Чтобы определить услуги ПОЗ, требуется модель элементов, входящих в услуги. Эта модель ПОЗ получается из определений в ГОСТ 28906 с добавлением последующих уточнений, относящихся к этим услугам.

2.1.1    Обзор

Модель ПОЗ предполагает наличие некоторого числа независимых прикладных ЛО в различных открытых системах, которые объединяются для обеспечения ПОЗ и вместе представляют собой поставщика услуг ПОЗ. Модель ПОЗ предполагает также наличие некоторого числа агентств, которые являются пользователями услуг ПОЗ. Концептуальные взаимодействия между поставщиком услуг ПОЗ и агентством определяются СП. Поставщик услуг ПОЗ принимает от инициирующего агентства информацию, достаточную для создания СР.

Запрошенная работа выполняется при помощи:

a)    стандартизованных функций поставщика услуг ПОЗ;

b)    функций среды локальной системы, доступных при помощи перемещения документов между поставщиком услуг ПОЗ и агентствами.

2.1.2    Содержимое спецификации работы

СР имеет поля, содержащие данные для:

a)    идентификации работы;

b)    полномочий работы;

c)    определения адресата для передачи отчетов о выполнении работы;

d)    выбора требуемых отчетов;

e)    идентификации типа СР;

f)    идентификации открытых систем, которые должны выполнять работу;

g)    указания срочности выполнения работы;

h)    задержки частей работы до тех пор, пока не произойдут определенные события;

i)    указания действий, которые должны быть выполнены поставщиком услуг ПОЗ для выполнения начальной работы;

j)    указания дальнейшей работы, которая должна быть выполнена при завершении начальной работы.

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

Содержимое СР имеет отношение к следующим возможностям, которые обеспечиваются службой ПОЗ и полностью определены в 3.4.

5

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

1-3-1048

1

Оригиналы и проекты ИСО/МЭК — во ВНИИКИ Госстандарта России.

2