Предисловие

1    РАЗРАБОТАН Государственным научно-исследовательским и конструкторско-технологическим институтом «ТЕСТ» Государственного комитета Российской Федерации по телекоммуникациям

ВНЕСЕН Государственным комитетом Российской Федерации по телекоммуникациям

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 28 ноября 2000 г. № 317-ст

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 10031-1—91 «Информационная технология. Текстовые и учрежденческие системы. Модель приложений распределенного учреждения. Часть 1. Общая модель»

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

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

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

Ц

Операции СДО не обязательно ограничиваются доступом к фиксированным или постоянным объектам данных.

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

5.3.2.2    Операции создания

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

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

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

5.3.2.3    Операции потребления

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

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

5.3.2.4    Операции СДО

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

5.3.2.5    Функции, подразумеваемые поддержкой СДО

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

а)    исполнитель должен быть способен предоставлять в ответ на операцию создания ООС, а не значение объекта данных;

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

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

г)    исполнитель должен быть способен осуществить операцию доступа.

В специфических для приложений протоколах стандарты могут:

а)    либо допускать использование ООС в любых элементах протокола, когда предоставляется или возвращается ссылка на объект данных,

б)    либо налагать дополнительные ограничения на допустимость использования ООС,

в)    либо определять специальные элементы протокола для работы с операциями СДО-создания и СДО-потребления.

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

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

8

ГОСТ Р ИСО/МЭК 10031-1—2000

5.3.2.6    Качество услуги

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

а)    либо указывает на значение объекта данных, которое было в момент создания ООС,

б)    либо указывает на текущее значение объекта данных,

в)    либо становится неопределенным, если объект был обновлен.

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

5.3.2.7    Структура ООС

Подробности структуры ООС и связанные с ней процедуры определены в ИСО/МЭК 10031-2 [1].

6 Руководство по проектированию протоколов

6.1    Введение

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

6.2    Учрежденческая информация

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

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

6.3    Модель объекта и удаленные операции

6.3.1    Использование удаленных операций

Удаленные операции, определенные в ГОСТ Р ИСО/МЭК 9072-1 и ГОСТ Р ИСО/МЭК 9072-2, обеспечивают нотацию и спецификацию протокола для операций связывания, развязывания и операций, вызванных в модели объекта операциями типа. В последующих подразделах приведено руководство по наименованию и стандартным установкам для операций.

Все протоколы доступа для распределенных учрежденческих приложений должны соответствовать удаленным операциям, установленным в ГОСТ Р ИСО/МЭК 9072-1 и ГОСТ Р ИСО/МЭК 9072-2. Протоколы доступа должны использовать нотацию и концепции настоящего стандарта и должны допускать любое отображение, определенное в ГОСТ Р ИСО/МЭК 9072-1, раздел 11. В приложении J дано краткое введение в эти концепции в контексте протокола доступа с учетом правил 6.4.

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

6.3.2    Использование метода абстрактных услуг для определения х-у слуги

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

Макросы абстрактных услуг определены в ГОСТ Р ИСО/МЭК 10021-3.

6.4    Прикладные правила

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

9

6.4.1    Конкуренция и разделение ресурсов

6.4.1.1    Конкуренция

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

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

а)    допускать несогласованные данные;

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

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

г)    минимизировать взаимосвязи между элементами данных на разных серверах;

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

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

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

6.4.1.2    Разделение ресурсов

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

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

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

6.4.2    Прозрачность сети

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

6.4.3    Общее определение времени

Все протоколы в среде распределенных учрежденческих приложений должны выражать время, используя тип данных «GeneralizedTime», определенный в ГОСТ Р ИСО/МЭК 8824.

Time:: = GeneralizedTime

Примечание — В стандартах серий ГОСТ Р ИСО/МЭК 9594 и ГОСТ Р ИСО/МЭК 10021 в настоящее время используется тип «UTCTime» вместо « GeneralizedTime». В этих стандартах планируется использование типа «GeneralizedTime», сохраняющего обратную совместимость.

6.4.4    Общее определение идентификаторов

Все объекты, определенные в стандартах РУП, должны иметь по крайней мере одно глобально однозначное имя. Общее понимание имен и общее определение идентификаторов определены в ГОСТ Р ИСО/МЭК 7498-3, ГОСТ Р ИСО/МЭК 8824 и ГОСТ Р ИСО/МЭК 9594-1. Подробнее см. приложение Е.

Данная модель придерживается кодирования АСН.1 имен, используемого приложениями, определенного в ГОСТ Р ИСО/МЭК 9594-1.

6.4.5    Использование атрибутов и фильтров

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

Понятие атрибута, нотация, обеспечивающая определения атрибутов, и абстрактный синтаксис атрибутов определены в ИСО/МЭК 9594-2 [2]. Подмножество определено в ГОСТ Р ИСО/МЭК 10

ГОСТ Р ИСО/МЭК 10031-1-2000

10021-5. Стандарты распределенных учрежденческих приложений должны использовать атрибуты, когда это возможно, и должны ссылаться на ИСО/МЭК 9594-2 [2].

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

Семантика и абстрактный синтаксис фильтров определены в ГОСТ Р ИСО/МЭК 9594-3, а подмножество — в ГОСТ Р ИСО/МЭК 10021-5. Стандарты для распределенных учрежденческих приложений должны использовать фильтры, когда это возможно, и должны ссылаться на ГОСТ Р ИСО/МЭК 9594-3.

Типы атрибутов, определенные для одного приложения, могут использоваться другим приложением, если определения и семантика одинаковы. В качестве инструмента для достижения этого используется идентификатор объекта, определенный в ГОСТ Р ИСО/МЭК 8824.

Макрос для атрибутов определен в ИСО/МЭК 9594-2 [2].

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

6.4.6    Ссылочный доступ к объекту

Значения объектов данных и ООС в протоколах доступа обычно могут появляться как внешние типы АСН.1.

6.4.7    Элементы прикладных услуг и прикладной контекст

Элементы прикладных услуг, выполняющие функции, требуемые для нескольких протоколов

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

6.5 Правила безопасности

6.5.1    Введение

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

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

Примечание — Подробнее о понятии безопасности см. приложение F.

6.5.2    Субъект безопасности

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

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

САП должен передаваться в примитиве BIND и применяться ко всем последующим операциям в ассоциации до тех пор, пока примитив UNBIND или ABORT ее не завершат. Каждая отдельная операция должна позволять клиенту передать другой САП; он будет дополнением для данной операции к САП из примитива BIND.

Когда операция вызывает последующую обработку или следует за примитивами UNBIND или ABORT, САП, использованный в операции, должен применяться и для последующей обработки.

6.5.3    Объекты безопасности

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

11

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

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

6.5.4    Управление доступом

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

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

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

6.5.5    Ошибки безопасности

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

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

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

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

6.6 Стандартный набор операций

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

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

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

Стандартный набор абстрактных операций РУП включает в себя следующие операции:

а)    перечислить (List);

б)    читать (Read);

в)    изменить (Modify);

г)    копировать (Сору);

д)    переместить (Move);

е)    искать (Search);

ж)    создать (Create);

и)    удалить (Delete);

к)    зарезервировать (Reserve);

л)    отметить (Notify);

м)    отказать (Abandon).

Пример этих операций приведен в приложении К.

12

ГОСТ Р ИСО/МЭК 10031-1—2000

ПРИЛОЖЕНИЕ А

(справочное)

Ссылки, определения и сокращения для последующих справочных приложений

А.1 Введение

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

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

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

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

ГОСТ Р ИСО/МЭК 7498-4—99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 4. Основы административного управления

ГОСТ Р ИСО 8613-1-99 Информационная технология. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 1. Введение и общие принципы

ГОСТ Р ИСО/МЭК 8879—99 Обработка информации. Текстовые и учрежденческие системы. Стандартный обобщенный язык разметки (SGML)

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

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

А.3.1 Определения базовой эталонной модели ВОС

В последующих приложениях к настоящему стандарту используют следующий термин, определенный в ГОСТ 28906: прикладной процесс.

А.3.2 Определения безопасности базовой эталонной модели ВОС В последующих приложениях к настоящему стандарту используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 7498-2:

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

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

в)    проверка;

г)    прослеживание проверки;

д)    информация аутентификации;

е)    средство;

ж)    конфиденциальность;

и)    целостность данных;

к)    аутентификация источника данных;

л)    цифровая подпись;

м)    шифрование;

н)    ключ;

о)    управление ключами;

п)    отвержение.

А.3.3 Определения систем передачи текста, ориентированных на сообщения (MOTIS)

В последующих приложениях к настоящему стандарту используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10021-2:

а)    передача сообщений;

б)    система передачи сообщений;

в)    хранилище сообщений;

г)    Р2;

д)    агент пользователя.

А.3.4 Определения модели распределенных учрежденческих приложений (МРУП)

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

А.3.4.1 политика управления доступом: Набор правил, часть политики безопасности, по которым проводится аутентификация людей-пользователей или их представителей и по которым доступ этих пользователей к услугам и объектам безопасности предоставляется или закрывается.

А.3.4.2 контекст доступа: Контекст в терминах таких переменных, как положение, время дня, уровень безопасности установленных ассоциаций и т. п., в котором осуществляется доступ к объектам безопасности.

А.3.4.3 криптографический ключ: См. ключ.

А.3.4.4 спецификация формата объекта данных: Тип данных в смысле АСН.1, который определен независимо от протоколов х-доступа.

13

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

А.3.4.6 пользователь УП: Часть прикладного процесса, которая непосредственно взаимодействует с пользователем-человеком и использует одно или несколько учрежденческих приложений в интересах этого пользователя-человека.

А.3.4.7 администратор безопасности: Уполномоченный (лицо или группа лиц), ответственный за реализацию политики безопасности для области безопасности.

А.3.4.8 область безопасности: Ограниченная группа объектов и субъектов безопасности, к которым применяется единая политика безопасности, осуществляемая единственным администратором безопасности.

А.3.4.9 средства безопасности: Процедуры, процессы, методы или их наборы, которые моделируют функции, относящиеся к безопасности.

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

А.3.4.11 пользователь: Пользователь-человек или х-пользователь.

А.3.4.12 прикладной процесс пользователя: Прикладной процесс, который содержит пользователя УП и одного или нескольких клиентов распределенного (учрежденческого) приложения (например, х-клиент, у-клиент и т. п.).

А.3.4.13 х~, у-, Z-, • . . : Родовые представления для конкретных имен приложений.

А.3.4.14 интерфейс х-приложения: Интерфейс к х-ириложению так, как он виден между х-пользователем и х-клиентом.

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

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

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

СЭП — сервисный элемент приложения.

ПРИЛОЖЕНИЕ В (справочное)

Взаимосвязь с другими стандартами

В.1 Содержание

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

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

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

В.2 Использование других стандартов

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

В.З Согласованность с другими стандартами

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

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

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

14

ГОСТ Р ИСО/МЭК 10031-1-2000

В.4 Сосуществование с другими стандартами

В.4.1 Протокол виртуального терминала (VTP)

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

В.4.2 Протоко лы передачи файлов

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

ВАЗ Обработка транзакций (ТР), завершение, конкуренция и откатка (CCR)

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

В.4.4 Открытая распределенная обработка (ODP)

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

ПРИЛОЖЕНИЕ С (справочное)

Требования

С.1 Введение

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

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

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

С.2 Функциональные требования

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

а)    межперсональные сообщения — для взаимодействия с другими пользователями;

б)    групповое взаимодействие — для групп пользователей;

в)    преобразование — для обмена документами с разными синтаксисами или кодированиями;

г)    запись и поиск документов — для упорядоченной записи и многоключевого поиска документов;

д)    ввод и вывод документов — для распределенных учрежденческих систем с различными физическими устройствами, такими как сканеры, принтеры и пр.;

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

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

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

сети;

к)    прямой доступ — для удаленных серверов (например, видеотексту) и пользователей (например, через видеотекст);

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

м)    передача данных между различными приложениями — для удаленных серверов.

15

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

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

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

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

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

С.З Требования проектирования

Проектирование протоколов должно обеспечивать:

а)    устойчивость —

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

б)    модульное проектирование:

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

2)    допускающее требование высокой степени интеграции;

в)    общий стиль проекта протокола, включающий единообразное использование:

1)    поддерживающих приложений и возможностей,

2)    элементов услуг удаленных операций;

г)    безопасность — различные уровни, задаваемые пользователем;

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

В настоящем стандарте установлены принципы взаимодействия между' различными приложениями.

ПРИЛОЖЕНИЕ D (справочное)

Основные понятия

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

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

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

Узел сервера является устройством, которое управляет ресурсами, совместно используемыми несколькими пользователями.

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

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

16

ГОСТ Р ИСО/МЭК 10031-1-2000

D.2 Модель клиент-сервер

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

D.2.1 Единственное нераспределенное приложение

В единственном нераспределенном х-приложении х-пользователь и х-приложение находятся в одном месте. В специальном случае, когда х-пользователь находится во взаимодействии с пользователем-человеком и с х-приложением в интересах этого пользователя-человека, х-пользователь называется УП-пользователь, а прикладной процесс — прикладным процессом пользователя (см. D.3.1). Х-пользователь взаимодействует с х-приложением через интерфейс х-приложения, который, обычно, является чей-либо собственностью и не является целью стандартизации (см. рисунок D.1).

Прикладной процесс

х-приложения х-пользова- тель х-клиент х-сервер

Интерфейс Определение х-приложения х-услуг

Рисунок D. 1 — Нераспределенное учрежденческое приложение

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

D.2.2 Е д и н с т в е н н о е распределенное приложение

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

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

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

Новая ситуация отображена на рисунке D.2, где показано определение х-услуг рисунка D. 1, расширенное до квадрата, содержащего протокол х-доступа.

Интерфейс    Определение х-приложения    х-услуг

Рисунок D.2 — Распределенное учрежденческое приложение

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

D.2.3 Взаимодействие ВОС клиент — сервер

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

Согласно базовой модели ВОС, протокол используется между парой категорий. На рисунке D.2 взаимосвязь ВОС осуществляется только в пределах прямоугольника, изображенного пунктиром. Таким образом, взаимосвязь ВОС пары категорий имеется только внутри, но не вне этого прямоугольника.

17

ГОСТ Р ИСО/МЭК 10031-1-2000

Содержание

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

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

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

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

5    Модель................................................................. 5

6    Руководство по проектированию протоколов.................................... 9

Приложение А    Ссылки, определения и сокращения для последующих справочных

приложений..................................................13

Приложение В    Взаимосвязь с другими стандартами.................................14

Приложение С    Требования...................................................15

Приложение D    Основные понятия.............................................16

Приложение Е    Рассмотрение идентификации.....................................26

Приложение F    Концепции безопасности.........................................27

Приложение G    Управление...................................................32

Приложение Н    Категории и взаимосвязь приложений...............................32

Приложение J    Модель объекта................................................37

Приложение К    Стандартный набор операций.....................................39

Приложение L    Библиография....................... 41

Ш

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

На рисунке D.3 содержимое изображенного пунктиром прямоугольника показывает более детальную модель взаимосвязи ВОС между х-клиентом и х-сервером.

j

Рисунок D.3 — Распределенное учрежденческое приложение с взаимосвязью ВОС

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

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

Дополнительные подробности взаимосвязи клиент/сервер описаны в D.4.

D.2.4 Объектная модель распределенного учрежденческого приложения

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

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

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

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

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

D.3 Функциональная модель

D.3.1 Несколько приложений в интегрированной системе

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

18

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

ТЕКСТОВЫЕ И УЧРЕЖДЕНЧЕСКИЕ СИСТЕМЫ.

МОДЕЛЬ ПРИЛОЖЕНИЙ РАСПРЕДЕЛЕННОГО УЧРЕЖДЕНИЯ

Часть 1

Общая модель

Information technology. Text and office systems. Distributed-office-applications model.

Part 1. General model

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

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

Стандарты серии ГОСТ Р ИСО/МЭК 10031 предоставляют каркас для разработки стандартов протоколов распределенных учрежденческих приложений (РУЛ, distributed-office-application — DOA). Они применимы для приложений, распределенных на значительных физических расстояниях, а также для «тесно связанных» учрежденческих систем.

Стандарты серии ГОСТ Р ИСО/МЭК 10031 описывают модель. Для того чтобы распределенные учрежденческие приложения были стандартизованы, они должны использовать принципы, установленные в этих стандартах.

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

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

В стандартах серии ГОСТ Р ИСО/МЭК 10031 не определяется какой-либо интерфейс человек—машина, используемый с распределенными приложениями. Также в них не определяется интерфейс между программным обеспечением, непосредственно взаимодействующим с пользователем, и программным обеспечением конкретных приложений.

Содержание стандартов серии ГОСТ Р ИСО/МЭК 10031 разбито на две части.

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

а)    модель;

б)    руководства по проектированию протоколов.

В ИСО/МЭК 10031-2 [1] описана отличающая объект ссылка и соответствующие процедуры, которые могут быть использованы всеми РУП.

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

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

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

ГОСТ 6.20.1-90 Электронный обмен данными в управлении, торговле и на транспорте (ЭДИФАКТ). Синтаксические правила

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

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

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

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

ГОСТ Р ИСО/МЭК 7498-2—99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 2. Архитектура защиты информации

ГОСТ Р ИСО/МЭК 7498-3—97 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 3. Присвоение имен и адресация

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

ГОСТ Р ИСО/МЭК 9066-1—93 Системы обработки информации. Передача текста. Надежная передача. Часть 1. Модель и определение услуг

ГОСТ Р ИСО/МЭК 9072-1—93 Системы обработки информации. Передача текста. Удаленные операции. Часть 1. Модель, нотация и определение услуг

ГОСТ Р ИСО/МЭК 9072-2—93 Системы обработки информации. Передача текста. Удаленные операции. Часть 2. Спецификация протокола

ГОСТ Р ИСО/МЭК 9594-1—98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 1. Общее описание принципов, моделей и услуг

ГОСТ Р ИСО/МЭК 9594-3—98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 3. Определение абстрактных услуг

ГОСТ Р ИСО/МЭК 10021-2—98 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 2. Общая архитектура

ГОСТ Р ИСО/МЭК 10021-3—98 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 3. Соглашения по определению абстрактных услуг

ГОСТ Р ИСО/МЭК 10021-5—96 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 5. Хранилище сообщений: определение абстрактных услуг

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

3.1    Определения базовой эталонной модели ВОС

В настоящем стандарте используют следующие термины, определенные в ГОСТ 28906:

а)    прикладной уровень;

б)    прикладная категория;

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

г)    уровень представления;

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

е)    протокол;

ж)    определение услуги.

3.2    Определения безопасности базовой эталонной модели ВОС

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

а)    аутентификация;

б)    авторизация;

г)    полномочия;

д)    политика безопасности.

3.3    Определения сервисного элемента управления ассоциацией (СЭУА, ACSE)

В настоящем стандарте используют следующие термины, определенные в ГОСТ 34.981:

а)    прикладной контекст;

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

3.4    Определение услуг уровня представления

В настоящем стандарте используют следующий термин, определенный в ГОСТ 34.971: абстрактный синтаксис.

3.5    Определения абстрактной синтаксической нотации

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

8824:

а) АСН.1

2

ГОСТ Р ИСО/МЭК 10031-1-2000

б)    внешний тип;

в)    обобщенное время;

г)    макро;

д)    идентификатор объекта;

е)    время UTC.

3.6    Определение сервисного элемента надежной передачи (СЭНП, RTSE)

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

сервисный элемент надежной передачи (СЭНП).

3.7    Определения сервисного элемента удаленных операций (СЭУО, ROSE)

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

а)    аргумент;

б)    операция связывания;

в)    вызов;

г)    операция;

д)    выполнение;

е)    удаленные операции;

ж)    сервисный элемент удаленных операций (СЭУО);

з)    результат;

и)    операция развязывания.

3.8    Определения справочника

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

а)    атрибут;

б)    макроатрибут;

в)    тип атрибута;

г)    значение атрибута;

д)    фильтр.

3.9    Определение EDIFACT

В настоящем стандарте используют следующий термин, определенный в ГОСТ 6.20.1: EDIFACT.

3.10    Определения систем передачи текста, ориентированных на сообщения (MOTIS)

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

а)    часть тела (сообщения);

б)    IP-сообщение;

в)    сообщение.

3.11    Определения соглашения по определению абстрактных услуг

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

а)    абстрактная модель;

б)    абстрактные операции;

в)    абстрактные услуги;

г)    макро абстрактных услуг;

д)    асимметричный;

е)    порт;

ж)    очистка;

з)    симметричный.

3.12    Определения модели распределенных учрежденческих приложений (МРУП)

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

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

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

3.12.3    атрибуты управления: Атрибуты, связанные с объектом защиты, которые, при согласо-

3

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

3.12.4    пакет атрибутов управления: Совокупность атрибутов управления.

3.12.5    операция потребления: Операция, вызванная х-клиентом у соучастника, объекты которой указаны ООС.

3.12.6    объект данных: Объект, который представляет данные.

3.12.7    значение объекта данных: Значение, полученное из объекта данных в соответствии с набором правил или, при отсутствии таких правил, значение всего объекта.

3.12.8    прямой доступ к значению: Доступ к объекту данных по значению, а не по ссылке.

3.12.9    прямая передача значения: Непосредственная передача значения объекта данных, а не передача ссылки.

3.12.10    отличающая объект ссылка (ООС): Однозначная ссылка на реальный объект в среде

РУЛ.

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

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

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

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

3.12.15    учрежденческая информация: Данные, используемые в учреждении.

3.12.16    атрибуты привилегий: Атрибуты, связанные с субъектом защиты, которые, при согласовании с атрибутами контроля объекта защиты, используются для предоставления доступа или отказа в доступе к этому объекту защиты.

3.12.17    сертификат атрибутов привилегий: Сертификат, использующий атрибуты привилегий.

3.12.18    операция создания: Операция, вызванная х-клиентом у исполнителя, в которой запрашивается ООС, а не значение объекта данных.

3.12.19    квалифицированные атрибуты: Атрибуты, которые имеют квалификацию использования.

3.12.20    ссылочный доступ к объекту (СДО): Доступ к объектам с помощью ссылок.

3.12.21    операция СДО: Операция, вызванная соучастником у исполнителя.

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

3.12.23    объект безопасности: Играющая пассивную роль категория, доступ к которой предоставляется или в доступе отказывается в соответствии с политикой авторизации.

3.12.24    субъект безопасности: Играющая активную роль категория, которой предоставляет доступ или отказывает в доступе к объекту безопасности в соответствии с политикой авторизации.

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

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

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

3.12.28    абстрактная услуга х-доступа: Абстрактная услуга между х-клиентом и х-сервером.

3.12.29    протокол х-доступа: Протокол, используемый между х-клиентом и х-сервером.

3.12.30    х-приложение: Некоторого рода распределенное учрежденческое приложение, например приложение электронной почты или приложение хранения и поиска.

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

3.12.32    х-клиент: Та часть х-приложения, которая является частью прикладного процесса, содержащей х-пользователь.

4

ГОСТ Р ИСО/МЭК 10031-1-2000

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

3.12.34    система х-серверов: Совокупность одного или нескольких х-серверов.

3.12.35    абстрактные услуги х-системы: Абстрактные услуги между х-серверами.

3.12.36    протокол х-системы: Протокол, используемый между х-серверами.

3.12.37    х-пользователь: Часть прикладного процесса, играющая роль, принятую при использовании х-приложения.

4    Сокращения

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

АСН.1 — абстрактная синтаксическая нотация версии 1 ВОС — взаимосвязь открытых систем КУ — качество услуги

МРУП — модель распределенного учрежденческого приложения

ООС — отличающая объект ссылка

РУП — распределенное учрежденческое приложение

САП — сертификат атрибутов привилегий

СДО — ссылочный доступ к объекту

СЭНП — сервисный элемент надежной передачи

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

СЭУО — сервисный элемент удаленных операций

EDIFACT — электронный обмен данными в управлении, коммерции и на транспорте (Electronic Data Interchange For Administration, Commerce and Transport)

UTC — всемирное скоординированное время (Coordinated Universal Time)

5    Модель

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

5.1    Абстрактная модель РУП

5.1.1    Абстрактная модель доступа

Распределенные учрежденческие приложения должны развиваться в соответствии с абстрактной моделью клиент—сервер, показанной на рисунке 1, используя соглашения по определению абстрактных услуг, приведенные в ГОСТ Р ИСО/МЭК 10021-3.

На рисунке 1 х-пользователь есть пользователь х-приложения, которое обеспечивается х-приклад-ной системой. х-Пользователь взаимодействует с х-клиентом для использования услуг, предоставляемых х-приложением. х-Клиент получает доступ к х-серве-ру через х-доступ. Система х-серверов может быть разделенной и распределенной по нескольким х-сер-верам. Детали внутренней структуры системы х-серверов определены в 5.1.2.

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

П римечание 1 - Услуги доступа, предоставляемые асимметричными портами, находятся вне области применения настоящего стандарта.

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

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

а)    документы,

б)    сообщения,

в)    данные EDIFACT,

5

г)    атрибуты документов,

д)    время,

е)    информация, относящаяся к сообщениям,

ж)    информация о файлах документов,

з)    информация для печати документов (включая шрифты),

и)    управляющая информация для серверов.

Эта информация выглядит как совокупность учрежденческих объектов данных, к которым можно получить доступ и работать с ними по отдельности или в группе.

Примечание 2 — Обмен информацией, отличной от учрежденческой, определен или будет определен в других стандартах.

х-клиент    5.1.2    Система    х-серверов на рисунке 1

может быть уточнена для распределенной системы х-серверов путем определения абстрактных услуг между серверами, как предлагается в ГОСТ Р ИСО/МЭК 10021-3. На рисунке 2 показана детализация системы х-серверов.

На рисунке 2 х-клиент получает доступ к системе х-серверов через абстрактную услугу х-доступа (а). В системе х-серверов доступу соответствует х-сервер. Для предоставления запрошенных х-клиентом услуг х-сервер может взаимодействовать с другими х-серверами через абстрактные услуги х-системы (s).

Система х-серверов может охватывать различные типы х-серверов.

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

o.z.i геализация аострактнои модели доступа

Для реализации абстрактной модели доступа должен использоваться СЭУО, определенный в стандартах серии ГОСТ Р ИСО/МЭК 9072, и его отображение в ВОС. Модель уровня приведена на рисунке 3. Дополнительную информацию об идентификации х-клиентов х-серверов см. в 6.4.4.

5.2.2 Реализация абстрактной модели для систем серверов

Нет ограничений на реализацию абстрактной модели для систем серверов. Примеры приведены в приложении D.

5.3 Ссылочный доступ к объекту

5.3.1 Классы доступа к данным

Доступ к значениям объектов данных концептуально вовлекает три стороны:

а)    инициатора, который запрашивает доступ;

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

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

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

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

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

Аналогично, в языках программирования высокого уровня аргумент или результат передаются «по значению», когда используется прямой доступ, и «по имени», когда используется ссылочный доступ к данным.

6

ГОСТ Р ИСО/МЭК 10031-1-2000

5.3.2 Функциональная модель для ссылочного доступа к объекту

5.3.2.1 Функциональная модель

Функциональная модель ссылочного доступа к объекту (СДО) применяется, когда инициатор, исполнитель и соучастник разделены либо в пространстве, либо во времени. Эта модель показана на рисунке 4. Например, инициатор, исполнитель и соучастник могут выполняться в трех разных системах, или система инициатора может работать там же, где позже будет работать исполнитель или соучастник.

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

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

7