Назад
21
Стандарты Открытых Систем
В настоящее время в мире существует несколько авторитетных
сообществ, занимающихся выработкой стандартов открытых систем.
Однако исторически и, по-видимому, до сих пор наиболее важной
деятельностью в этой области является деятельность комитетов POSIX.
В этом разделе мы приведем краткий обзор этой деятельности.
Первая рабочая группа POSIX (Portable Operating System Interface)
была образована в IEEE в 1985 г. на основе UNIX-ориентированного
комитета по стандартизации /usr/group (ныне UniForum). Отсюда видна
первоначальная направленность работы POSIX на стандартизацию
интерфейсов ОС UNIX. Однако постепенно тематика работы рабочих
групп POSIX (а со временем их стало несколько) расширилась
настолько, что стало возможным говорить не о стандартной ОС UNIX, а
о POSIX-совместимых операционных средах, имея в виду любую
операционную среду, интерфейсы которых соответствуют
спецификациям POSIX.
Сейчас функционируют и регулярно выпускают документы
следующие рабочие группы POSIX.
POSIX 1003.0. Рабочая группа, выпускающая "Руководство по
POSIX-совместимым средам Открытых Систем". Это руководство
содержит сводную информацию о работе и текущем состоянии
документов всех других рабочих групп POSIX, а также других
тематически связанных организаций, связанных со стандартизацией
интерфейсов Открытых Систем.
POSIX 1003.1. Интерфейсы системного уровня и их привязка к
языку Си. В документах этой рабочей группы определяются
обязательные интерфейсы между прикладной программой и
операционной системой. С выпуска первой версии этого документа
началась работа POSIX, и он в наибольшей степени связан с ОС UNIX,
хотя в настоящее время интерфейсы 1003.1 поддерживаются в любой
операционной среде, претендующей на соответствие принципам
Открытых Систем. Заметим, что несмотря на очевидную важность
1003.1, в документе отсутствуют спецификации многих важных
интерфейсов, в частности, интерфейсы системных вызовов,
обеспечивающих межпроцессные взаимодействия.
POSIX 1003.2. Shell и утилиты. Рабочая группа специфицирует
стандартный командный язык shell, основанный главным образом на
Bourne shell, но включающий некоторые черты Korn shell. Кроме того, в
документах этой рабочей группы специфицировано около 80 утилит,
которые можно вызывать из процедур shell или прямо из прикладных
программ. В документах серии 1003.2a описываются дополнительные
средства, позволяющие пользователям работать с системой с помощью
только ASCII-терминалов.
22
POSIX 1003.3. Общие методы проверки совместимости с POSIX.
Целью рабочей группы является разработка методологии проверки
соответствия реализаций стандартам POSIX. Документы рабочей
группы используются в различных организациях при разработке
тестовых наборов.
POSIX 1003.4. Средства, предоставляемые системой для
прикладных программ реального времени. В соответствии с
определением 1003.4, системой реального времени считается система,
обеспечивающая предсказуемое и ограниченное время реакции. Работа
ведется в трех секциях: файловые системы реального времени,
согласованные многопотоковые (multithread) архитектуры, а также в
секции, занимающейся такими вопросами, как семафоры и сигналы.
POSIX 1003.5. Привязка языка Ада к стандартам POSIX. В
документах этой рабочей группы определяются правила привязки
программ, написанных на языке Ада, к системным средствам,
определенным в POSIX 1003.1.
POSIX 1003.6. Расширения POSIX, связанные с безопасностью.
Разрабатываемый набор стандартов базируется на критериях
министерства обороны США и будет определять безопасную среду
POSIX.
POSIX 1003.7. Расширения, связанные с администрированием
системы. Стандарт, разрабатываемый рабочей группой, будет
определять общий интерфейс системного администрирования, в
частности, разнородных сетей. Отправной точкой является модель OSI.
POSIX 1003.8. Прозрачный доступ к файлам. Будут обеспечены
интерфейсы и семантика прозрачного доступа к файлам,
распределенным в сети. Работа основывается на анализе существующих
механизмов: NFS, RFS, AFS и FTAM.
POSIX 1003.9. Привязка языка Фортран. Определяются правила
привязки прикладных программ, написанных на языке Фортран, к
основным системным средствам.
POSIX 1003.10. Общие черты прикладной среды
суперкомпьютеров (Application Environment Profile - AEP).
POSIX 1003.11. Общие черты прикладной среды обработки
транзакций (On-line Transaction Processing Application Environment -
OLTP).
POSIX 1003.12. Независимые от протоколов коммуникационные
интерфейсы. Разрабатываются два стандартных набора интерфейсов для
независимых от сетевых протоколов коммуникаций "процесс-процесс".
Результаты должны обеспечивать единообразную работу с TCP/IP, OSI и
другими системами коммуникаций.
POSIX 1003.13. Общие черты прикладных сред реального
времени. POSIX 1003.14. Общие черты прикладных сред
мультипроцессоров. Помимо прочего, должны быть предложены
соответствующие расширения стандартов других рабочих групп.
23
POSIX 1003.15. Расширения, связанные с пакетной обработкой.
Определяются интерфейсы пользователя и администратора и сетевые
протоколы для пакетной обработки.
POSIX 1003.16. Привязка языка Си. Задача проекта, выполняемого
реально рабочей группой 1003.1, состоит в выработке правил привязки
международного стандарта языка Си (ISO 9989) к независимым от языка
интерфейсам, определяемым POSIX 1003.1-1990 (ISO 9945-1).
POSIX 1003.17. Справочные услуги и пространство имен. Задачей
рабочей группы является анализ и выработка рекомендаций по работе со
справочниками и пространством имен в контексте X.500.
POSIX 1003.18. Общие черты среды POSIX-платформы. В одном
документе должны быть специфицированы основные характеристики
интерактивной многопользовательской прикладной платформы,
соответствующей стандартам POSIX. Работа выполняется группой
1003.1.
Среда Открытых систем
Основой, обеспечивающей возможность реализации открытых
систем, является совокупность стандартов, с помощью которых
унифицируется взаимодействие аппаратуры и всех компонент
программной среды: языки программирования, средства ввода/вывода,
графические интерфейсы, системы управления базами данных,
протоколы передачи данных в сетях и т.п. В результате сотрудничества
многих национальных и международных организаций был определен
набор стандартов, направленных на реализацию требований,
обеспечивающих различные аспекты открытых систем.
Важным инструментом для выявления взаимосвязи различных
функциональных компонент, используемых прикладной системой в
открытой среде, является модель такой среды. Модель отражает
взаимодействие прикладных программ с системными программами и
другими компонентами среды и позволяет в каждом конкретном случае
решить, какие стандарты необходимы для функционирования
прикладной программы в выбранной среде. На сегодняшний день не
существует общепринятой и всеобъемлющей модели открытых систем.
Различными организациями предложены свои версии моделей. Часть
моделей отражает отдельные аспекты взаимодействий в открытых
системах, другие модели представляют обобщенный взгляд на системы
в целом. Модели отличаются также и степенью проработанности и
набором используемых функциональных стандартов, обеспечивающих
реализацию функций того или иного элемента модели.
Основное отличие между моделями заключается, как правило, в
том, что внешняя по отношению к прикладной программе (или
программной системе) среда подразделяется на различные элементы
(службы) различным образом. Общим для всех моделей является то, что
24
с их помощью определяются положения и функциональных компонент и
интерфейсов, обеспечивающих взаимодействие между прикладной
программой и компонентами среды, которые обеспечивают те или иные
виды обслуживания прикладным программам. Таким образом, модель
позволяет структурировать и формально описать среду, в которой
функционирует прикладная программа, и с этой точки зрения модель
может стать серьезной основой для применения точных методов для
анализа характеристик системы и оптимизации последних с помощью
различных методик и критериев, которые еще предстоит разработать. До
настоящего времени серьезных исследований в этом направлении не
проводилось, если не считать отдельных попыток введения взвешенных
оценок для различного типа стандартов, выбираемых при построении
прикладных систем, как например, методики оценки, предлагаемые
NIST [12].
Референсная модель ВОС (OSI/ISO).
Когда речь заходит о моделях открытых систем, обычно сразу
упоминают известную референсную модель OSI-ISO или в русском
варианте, "модель взаимосвязи открытых систем" ВОС [2,3,14]. Эта
модель берет свое начало из сетевой архитектуры SNA, предложенной
IBM. Модель развивается и используется уже около двадцати лет. Она
описывает систему взаимодействий в процессах обмена сообщениями и
данными между прикладными системами в вычислительных сетях.
Модель является наиболее проработанной с функциональной точки
зрения, полноты набора стандартов и определения их совместимости
друг с другом. Модель основана на разбиении среды на семь уровней,
взаимодействие между которыми описывается соответствующими
стандартами, что обеспечивает практически полную "прозрачность"
взаимодействия через эти уровни вне зависимости от того, каким
образом построен любой из уровней в каждой конкретной реализации
(см. рис. 1.2). С этой точки зрения моделью задается открытая
коммуникационная среда, полностью независимая от того, как и на
какой аппаратной и программной основе реализован каждый уровень.
Вместе с тем, эта модель относится исключительно к области
коммуникационных взаимодействий и не рассматривает взаимодействия
составных элементов прикладных процессов в отдельной машине, на
основе анализа которых возможно обеспечение мобильности
прикладных программ. Это свойство модели легко объяснимо, так как в
то время, когда формировалась основная концепция модели,
мобильность программ основывалось, главным образом, на аппаратной
совместимости платформ. Это, кстати, составляло основу технической
политики ведущих фирм изготовителей ЭВМ и разработчиков
программного обеспечения: IBM, DIGITAL EQUIPMENT, HP и др. В
рамках данной модели отдельная машина рассматривается как единое
целое. Подробнее на модели OSI, как составной части более общих
25
моделей, мы остановимся ниже, при рассмотрении коммуникационного
элемента более общих моделей открытых систем.
Модель MIC.
Модель открытой системы, разработанная AFUU (Французская
Ассоциация пользователей UNIX и открытых систем) и AFNOR
(Французская Ассоциация стандартизации), названа MIC (Model for
Interactions between Components) - модель взаимодействия между
компонентами, авторы также называют ее конвергентой моделью [6].
Эта модель представляет собой попытку объединить различные подходы
к классификации компонент среды.(рис. 1.3) Она строится в виде
матрицы 7х4, столбцы которой соответствуют видам взаимодействия
(обслуживания) в системе: взаимодействие с пользователем, системные
средства, доступ к данным, коммуникационние средства. Легко видеть,
что столбцы этой матрицы в точности соответствуют разбиению,
предложенному в модели MUSIC (см. разд. 1.2.1.4.), за исключением
отсутствующего элемента M (Management).
Строки матрицы соответствуют уровням обслуживания в рамках
каждого типа взаимодействия от физического уровня до уровня связи с
прикладной программой (или пользователем). Этот тип классификации
соответствует разбиению на уровни принятом в коммуникационной
модели OSI. Поэтому для варианта, использующего спецификации OSI
для коммуникационных взаимодействий, столбец коммуникаций в
точности соответствует модели OSI. Однако такое разбиение в
настоящее время можно считать достаточно условным, поскольку на
основе существующих стандартов далеко не все элементы допускают
четкое разбиение на семь уровней. Так, даже коммуникационный
элемент, реализованный на основе спецификаций TCP/IP, будет иметь
другое разбиение.
Модель допускает использование различных стандартов для
реализаций тех или иных функций, поэтому, в общем виде, модель
представима в виде трехмерной матрицы, в которой третья координата
используется для вариантов среды, которые строятся на основе
различных стандартов, реализующих функциональные элементы
модели.
Модель OSE/RF.
Рабочей группой POSIX P1003.0 Института инженеров по
электронике и электротехнике (IEEE) предложена Референсная Модель
Среды Открытых Систем (OSE/RF) [12], которая используется в США
(рис. 1.4). В отличие от рассмотренных выше европейских моделей,
данная модель предусматривает разбиение среды на три составных
части:
- прикладное обеспечение;
- прикладная платформа;
- внешняя среда.
26
В рамках этой модели под прикладным обеспечением понимаются
собственно прикладные программы, данные, а также документация и
средства обучения пользователей.
Прикладная платформа состоит из аппаратной платформы и
программного обеспечения. Сюда входят: операционная система,
компиляторы, СУБД, графические системы, т. е. все средства,
составляющие операционную среду для прикладных систем.
К внешней среде относятся все системные элементы, которые
являются внешними по отношению к прикладной платформе и
прикладному обеспечению. Это утилиты и подсистемы, реализуемые на
других (удаленных) платформах, а также периферийные устройства.
Взаимодействие между прикладным обеспечением и прикладной
платформой осуществляется с помощью Прикладных Программных
Интерфейсов (API). В области API предусматривается четыре
интерфейсных элемента для взаимодействия с:
- системными службами;
- коммуникационными службами;
- информационными службами;
- службами, обеспечивающими человеко-машинный интерфейс.
Взаимодействие между прикладной платформой и внешней средой
производится через область интерфейсов внешней среды (EEI). В этой
области предусматривается три типа интерфейсов для взаимодействия с:
- коммуникационными службами;
- информационными службами;
- службами, обеспечивающими человеко-машинный интерфейс.
К достоинству этой модели стоит отнести выделение внешней
среды в самостоятельный элемент, с определенными функциями и
соответствующими интерфейсами. Эта модель, в отличие от
рассмотренных выше, описывает также и системы, построенные на
основе архитектуры "клиент-сервер", которые сейчас получили широкое
распространение.
Модель MUSIC.
Модель MUSIC была предложена Центральным Агенством по
вычислительной технике и телекоммуникации (CCTA) Великобритании.
(рис. 1.5) [5]. MUSIC - это акроним от английских названий основных
элементов модели:
M - Management;
U - User interface;
S - Service interface for programs;
I - Information and data formats;
C - Comunications interfaces.
В модели MUSIC наибольшее внимание уделено тем аспектам
взаимодействия и интерфейсам, которые могут оказаться критическими
именно для прикладной системы, функционирующей в открытой среде.
Несмотря на то, что модель не является ни всеобъемлющей ни
27
уникальной в смысле категорий используемых объектов, она
обеспечивает ясность и четкое понимание связей между процессами,
которые имеют место в открытых средах. Дальнейшее изложение
строится в основном с использованием модели MUSIC. В следующих
параграфах будут подробно рассмотрены функции и спецификации,
определяемые для каждого из элементов модели.
Среди других моделей можно также отметить ряд специальных
[6], т. е. проблемно ориентированных моделей. В частности,
предлагаемая ISO модель ODP (Open Distributed Processing) - Открытая
Распределенная Обработка - ориентирована, как следует из названия, на
распределенную обработку в различных вычислительных сетях.
Известны также модели CIM, EDI, Data Management DISC и др. Однако
эти модели скорее можно отнести к Прототипным Профилям, о которых
речь пойдет в п. 1.3.
Компоненты модели MUSIC.
Рассмотрим элементы, составляющие модель MUSIC (рис. 1.5).
(Поскольку определения и терминология открытых систем пока не
имеют устоявшихся русских эквивалентов, в дальнейшем мы будем
использовать исходные английские обозначения, термины и
сокращения. Смысл этих терминов будет поясняться по ходу
изложения.)
Рис. 1.5. Модель MUSIC
28
Администрация (Management).
Элемент, названный Management, включает следующие
функциональные компоненты: системная администрация, защита
данных и надежность системы, управление работой в сетях, учет
использования ресурсов и поддержка конфигурации системы.
Некоторые компоненты, такие, как защита данных или учет
использования ресурсов, должны функционировать определенным,
совместимым для всего множества систем, имеющихся в организации,
образом, с тем, чтобы все ресурсы открытой вычислительный среды
организации были доступны для служб, обеспечивающих функции
такого типа.
Назначение этого элемента модели состоит в обслуживании
особого класса пользователей: системных администраторов,
администраторов сети и операторов. Функциональные возможности,
предоставляемые открытыми системами в этой области улучшают
мобильность профессиональных навыков для этих пользователей и
обеспечивают централизованную поддержку для всей распределенной
среды в целом.
Стандартизация функций, связанных с системной
администрацией, стала одной из самых последних задач в области
стандартизации программной среды. Большая часть работы в этой
области относится к определению самих объектов управления и
системных функций, которые должны быть стандартизованы. Работа в
этой области продолжается и в настоящее время. Для системных
администраторов разрабатывается обобщенный список процедур и
системных интерфейсов для использования при установке,
конфигурировании, обслуживании операционной системы и связанных с
ней системных программ. Основные функции, которые должны быть
включены в этот стандарт следующие: системная поддержка устройств и
обслуживание носителей информации, поддержка файловых систем,
включая средства для управления сохранением и восстановлением
файлов, управление производительностью системы, мониторинг в
системе, управление очередями ввода/вывода, поддержка стандартных
программных средств и систем коммуникации.
Основные усилия в разработке и внедрении стандартов и
спецификаций, обеспечивающих данную функциональную область,
предпринимаются рядом международных и национальных организаций.
ISO совместно с IEC в рамках концепции модели OSI/ISO разработала
документ: ISO 7498-4 OSI Reference Model Part 4 [5]
, Management
Framework, который определяет структуру и основные функции для
обеспечения системной администрации в рамках коммуникационных
взаимодействий, описываемых моделью OSI. Документом определяются
пять основных областей, являющихся объектами данной
функциональной области: отказы и сбои, регистрация, управление
29
конфигурацией, управление производительностью и безопасность. В
рамках документа выпущен или находится в стадии разработки ряд
стандартов:
ISO 9595 Common Management Information Services (CMIS).
ISO 9596-1 Common Management Information Protocols (CMIP).
ISO 10040 Systems Management Overview (SM0).
ISO 10164 Systems Management.
ISO 10165 Structure of Management Information.
ISO 10165-1 DIS Management Information Model.
ISO 10165-2 DIS Definition of Management Information.
ISO 10165-4 DIS Guidelines for the Definition of Managed Objects.
ISO 10733 CD Elements of Management Information Related to OSI
Network Layer Standards.
ISO 10737 CD Elements of Management Information Related to OSI
Transport Layer Standards.
Группой Internet также предпринимаются значительные усилия по
созданию стандартов для управления и администрирования в сетях,
использующих протоколы TCP/IP. Основой, определяющей концепции
администрации в рамках TCP/IP, является документ RFC 1157 - Simple
Network Management Protocol (SNMP). Концепция SNMP определяет
сеть, как совокупность сетевых управляющих (management) станций и
элементов сети (главные машины, шлюзы и маршрутизаторы,
терминальные серверы), которые поддерживают административные свя-
зи между сетевыми "управляющими станциями" и "сетевыми агентами".
Концепция SNMP позволяет минимизировать количество и
сложность функций, реализуемых сетевыми агентами. Простота
управляющих функций обеспечивает их понятность для разработчиков и
способствует снижению стоимости разработки программного
обеспечения, связанного с реализацией этих функций. К тому же,
данный подход способствует увеличению объема административных
функций выполняемых дистанционно, посредством чего
обеспечиваются минимальные ограничения на форму и сложность
механизмов поддержки сети.
К данной функциональной области относятся следующие
документы SNMP Internet:
RFC 1157 - Simple Network Management Protocol;
RFC 1155 - Structure and Identifications of Management Information
for TCP/IP-based Internets
и
RFC 1156 - Management Information Base for Network Management
of TCP/IP-based Internets.
Протоколы SNMP основаны на спецификациях языка OSI Abstract
Sintax Notation - ASN.1 (ISO 8224).
Одной из наиболее насущных задач сообщества сетей, входящих в
Internet, является определение стратегии сосуществования TCP и OSI.
30
Исследования в этой области ведутся обеими сторонами. Для решения
этой проблемы существует несколько подходов. Спецификация RFC
1006 [15]
- верхний уровень транспортной службы TCP - обеспечивает
пользователям Internet доступ к прикладным уровням OSI. Однако
спецификации RFC не пригодны для взаимодействия через все уровни
OSI.
Рабочей группой POSIX 1003.7 разрабатывается набор процедур и
системных интерфейсов для использования системными
администраторами при установке, конфигурировании и сопровождении
операционной среды. Разрабатываемые стандарты относятся к
следующим разделам системной поддержки: поддержка администрации
пользователей, поддержка устройств и носителей информации,
управление и поддержка файловой системой, включая сохранение и
восстановление, поддержка состояния системы, управление
производительностью, системный мониторинг, учет ресурсов,
управление очередями ввода/вывода, поддержка программного
обеспечения и коммуникационных служб.
Целью названной рабочей группы является создание набора
согласованных объектно-ориентированных интерфейсов и обеспечение
интероперабильности в неоднородных вычислительных сетях.
Исходнойточкой для этой работы является модель сетевого
менеджмента, предложенная OSI.
Рабочая группа POSIX.15, которая занимается управлением
очередями в пакетной обработке, в рамках этой проблемы также
разрабатывает административный интерфейс.
Корпорация OSF (Open Software Foundation) также занимается
проблемой системной администрации. OSF предложила свою
архитектуру, которая получила наименование DME (Distributed
Management Environment). DME должна обеспечивать согласованную
поддержку для широкого диапазона систем от отдельных машин до
больших распределенных неоднородных систем.
В рамках DME должны быть определены интерфейсы для
прикладных программ (API), которые будут использоваться
прикладными программами для обращения к таким общим службам, как
сохранение и использование управляющей информации и обмен
управляющей информацией с управляемыми объектами в локальных и
удаленных системах.
Пользовательский интерфейс (User Interface).
Элемент U (User Interface) распадается на две основных
компоненты. Первая - представляет группу взаимодействий, которые
имеют место между пользователем и прикладной системой в целом
(прикладная программа и системные средства, включая аппаратуру), вне
зависимости от конкретного типа прикладной системы, которая
используется. Примерами такого взаимодействия могут быть функции,
задаваемые последовательностью команд, исполняемой, когда