Исходя из этих соображений, по инициативе Совета по автоматизации научных исследований Российской академии наук был издан совместный Приказ - Постановление N 136/16 от 16 сентября 1993 г. Министерства науки и технической политики Российской Федерации и Президиума Российской академии наук о мерах по обеспечению развития работ по научному направлению "Развитие и применение открытых систем" (Приложение 1). С этой целью образована рабочая группа специалистов, которой поручено формирование межотраслевой научно-технической программы "Развитие и применение открытых систем". В состав группы вошли около 30 специалистов из 8 ведомств:

• - Российской академии наук;
• - Министерства науки и технической политики;
• - Комитета при Президенте РФ по политике информатизации;
• - Госстандарта РФ;
• - Комитета РФ по оборонным отраслям промышленности;
• - Федерального агентства правительственных систем связи;
• - Комитета по Высшей Школе.

Часть I - Состояние работ по открытым системам на Западе - содержит основные положения концепции открытых систем, важнейшие определения и понятия. Рассмотрены модели среды открытых систем и ее компонент, подчеркивается определяющая роль функциональных профилей стандартов, дано подробное описание профилей GOSIP и АРР США, рассмотрен технологический цикл построения открытых систем и организация работ в международных стандартизующих организациях. Показано, что проблема открытых систем очень многогранна, весьма далека от решения, даже не устоялись многие понятия, и имеются разночтения в терминологии. Работа крайне трудоемка, для выработки согласия требуется участие представителей всех сфер информационного процесса, силовые методы здесь неприемлемы.

Затраты весьма значительны - правительство США потратило на работы по стандартизации 3,5 млрд. долларов, такая компания как Sun тратит ежегодно на работу в стандартизирующих организациях десятки миллионов долларов.

Однако и экономический эффект весьма значителен, как уже говорилось, - составляет миллиарды долларов.

Часть I строится, в основном, по материалам книги [5] , которая является на сегодняшний день наиболее полной по охвату проблемы.

Часть II - Развитие и применение открытых систем в России - рассматривает перспективы решения проблемы в Российской Федерации в современных условиях.

Безусловно, по самому смыслу проблемы, она должна решаться на тех же технических принципах, что и на Западе, иначе просто невозможно будет осуществить интеграцию, но при организации работ следует учитывать особенности современного этапа развития России:

Решать проблему в Российской Федерации предлагается, проводя работу по нескольким взаимосвязанным направлениям:

• 1. Исследование роли открытых систем в России, проведение системного анализа важнейших областей применения открытых систем, построение профилей стандартов и определение первоочередных стандартов, требующих разработки.
• 2. Разработка концепции развития и применения открытых систем в России.
• 3. Создание методологии и инструментальных средств поддержки проектирования открытых систем
• 4. Разработка методов и средств тестирования, аттестации, верификации, измерения производительности открытых систем.
• 5. Информационное обеспечение работ в области открытых систем.
• 6. Образование в области открытых систем.
• 7. Новые направления развития открытых систем.
• 8. Создание пилотных систем.
• 9. Координация с другими программами по информационным технологиям.
• 10. Международное сотрудничество.

Документ содержит следующие приложения:

Приложение 1: Глоссарий.
Приложение 2: Перечень основных международных стандартов и стандартов США по информационным технологиям.
Приложение 3: Перечень организаций РФ, принимающих участие в Программе и сокращения названий этих организаций.
Приложение 4: Перечень зарубежных и международных стандартизующих организаций.
Приложение 5: Сеть центров открытых систем.

Реализация программы "Развития и применения открытых систем" составляет важнейшую народно-хозяйственную задачу.

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

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

1.1.1. История развития открытых систем.

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

Частичное решение проблемы мобильности для программ и программистов обеспечили и ранние стандарты языков, например, ФОРТРАН'а и КОБОЛ'а. Языки позволяли создавать переносимые программы, хотя зачастую и ограничивали функциональные возможности. Мобильность обеспечивалась также и за счет того, что эти стандарты были приняты многими производителями различных платформ. Когда языки приобретали статус стандарта де-факто, их разработкой и сопровождением начинали заниматься национальные и международные организации по стандартизации. В результате языки развивались уже независимо от своего создателя. Достижение этого уровня мобильности было первым примером истинных возможностей открытых систем.

Однако мобильность без достаточной функциональной полноты, вообще говоря, не слишком полезна. Функциональная полнота без мобильности полезна, но ограничивает развитие технологии и возможность выбора. Оптимальный вариант для каждого пользователя - достаточная мобильность и достаточная функциональная полнота. Для некоторых пользователей совместимость на уровне двоичного кода в рамках серии IBM 360 - достаточное решение обеих проблем. Для других достаточен стандартизованный язык. А кто-то нуждается в использовании средств, которые не имеют прямого отношения к языкам программирования. Так, задачи реального времени с трудом поддавались решению в рамках системы 360 и для этих задач в начале 70-х годов стали широко применяться мини-ЭВМ, со своей специфической архитектурой.

Следующий этап в развитии концепции открытости - это вторая половина семидесятых годов. Он связан с областью интерактивной обработки и увеличением объема продуктов, для которых требуется переносимость (пакеты для инженерной графики, системы автоматизации проектирования, базы данных). В это время фирма DIGITAL начала выпуск супермини-ЭВМ VAX, работающих под управлением операционной системы VMS [1]. ЭВМ этой серии имели уже 32-х разрядную архитектуру, что обеспечило значительно более высокую эффективность программного кода и сократило издержки на работу с виртуальной памятью. Программисты получили возможность прямо использовать адресное пространство объемом до 4-х Гбайт, что практически снимало все ограничения на размеры решаемых задач. Машины этого типа надолго стали стандартной платформой для систем проектирования, сбора и обработки данных, обслуживания эксперимента и т.п. Именно VAX'ы стимулировали создание наиболее мощных систем САПР, управления базами данных и машинной графики, которые широко используются до настоящего времени.

Конец 70-х годов характеризуется и массовым применением сетевых технологий. DIGITAL интенсивно внедряла свою архитектуру DECnet, разработка которой началась еще в начале десятилетия. Сети, использующие протоколы Internet (TCP/IP), первоначально реализованные DARPA, начали широко применяться для объединения систем как военных, так и академических организаций США. IBM применяла собственную сетевую архитектуру SNA (System Network Architecture), которая стала основой для предложенной Международной организацией стандартизации ISO архитектуры Open Systems Interconnection (OSI).

Когда сетевая обработка стала реальностью, пользователи начали обращать внимание на совместимость и возможность интеграции как на необходимые атрибуты открытых систем. ISO в 1977-78 годах развернула интенсивные работы по созданию стандартов взаимосвязи в сетях открытых систем. На основе архитектуры SNA в ходе этих работ была создана семиуровневая модель взаимосвязи открытых систем OSI - Open Systems Interconnection Basic Reference Model [2] .

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

В это же время были сделаны первые системы, которые обеспечивали организацию использования распределенных ресурсов в системе. Реализованная фирмой DIGITAL EQUIPMENT система VAXclaster обеспечила объединение до 42-х VAX'ов с помощью специальной высоко скоростной линии связи или локальной сети Ethernet. Поскольку все ЭВМ в системе были однотипными, задача обеспечения мобильности программ в рамках системы решалась за счет бинарной совместимости. Однако в этой системе уже реально решались задачи разделения ресурсов (памяти, процессоров, баз данных и т.п.) [1] . Таким образом, уже в то время были сделаны первые шаги к архитектуре "клиент-сервер", широко используемой сегодня.

Первая половина восьмидесятых годов характеризуется прежде всего массовым распространением персональных компьютеров с операционной системой MS-DOS корпорации Microsoft. Низкая цена и широкое распространение создали огромный рынок для данной ОС и прикладных программ, написанных для нее. Бинарная совместимость разрешила массу проблем. Многие прикладные программы, выполняющиеся в MS-DOS, могут выполняться и на любой другой совместимой системе. Но эта "клоновая" совместимость ограничена архитектурой Intel 80x86 с 16-разрядной адресацией, графикой низкого разрешения и невозможностью исполнять более одного задания одновременно. Для среды MS-DOS характерен также риск быстрого распространения вирусов, поскольку система слабо (или никак не) защищена на программном и аппаратном уровнях.

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

• - Большинство машинных команд исполняется за один машинный цикл.
• - Регистровая архитектура: все команды обработки выбирают операнды и помещают результаты только в регистрах. Обращение к ОЗУ производится только командами чтения/записи.
• - Конвейерная обработка команд, которая позволяет исполнять несколько команд одновременно.
• - Простой фиксированный формат команд с небольшим количеством методов адресации ОЗУ.
• - Наличие быстродействующей памяти: любая RISC машина имеет, по крайней мере, 32 регистра общего назначения и большую кэш-память.
• - Упрощенный набор команд, из которого исключены многоцикловые команды, предназначенные для реализации сложных функций, что обеспечивает предельно короткий машинный цикл и высокое быстродействие аппаратуры.

Хотя OC UNIX была разработана до создания MS-DOS, она не могла эффективно использоваться, так как требовала значительных аппаратных ресурсов. С появлением мощных RISC-микропроцессоров с 32-х разрядной архитектурой UNIX проявила себя как наиболее перспективная открытая операционная среда. Исторически OC UNIX оказалась самым жизненным вариантом для создания общей базы переносимости. Она удовлетворяет большинству требований, предъявляемых к открытым системам. Прикладные программы, создаваемые для работы в UNIX, при определенных условиях могут иметь весьма высокую переносимость как в другие UNIX-подобные системы, так, во многих случаях, и в системы, удовлетворяющие стандартам на интерфейсы, подобные тем, которые разработаны X/Open и POSIX (см. п. 1.7.).

Одна из причин рассматривать систему UNIX в качестве базовой ОС для использования в открытых системах состоит в том, что эта ОС почти целиком написана на языке высокого уровня, модульна и относительно гибка. OC UNIX составлена из основных компонентов, включающих ядро, инструментальные утилиты и оболочку. Ядро, составляющее сердцевину UNIX`a, состоит из относительно маленького набора программ, предоставляющих системные ресурсы и непосредственно взаимодействующих с аппаратурой.

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

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

Привлекательный аспект, связанный с OC UNIX, также состоит в том, что компания AT&T готова предоставлять лицензии на нее. Однако это приводит также и к появлению множества различных и несовместимых реализаций. К тому же, особенно в начале, не все поставщики выбирали лицензионные продукты, останавливаясь вместо этого на разработке систем подобных UNIX с различной степенью совместимости. Деятельность ряда организаций, таких как UniForum, POSIX и X/Open, направлена на поиск общего функционального ядра, которое позволило бы достичь переносимости между различными системами.

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

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

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

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

1.1.2. Существующие определения открытых систем и терминология.

В качестве иллюстрации этих разночтений приведем несколько определений, которые дали разные организации:

Определение Ассоциации французских пользователей UNIX и открытых систем (AFUU) [6]:

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

Так, например, существует определение, данное IEEE [13].

Определение NIST [9]:

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

В рамках данного документа, целесообразно пользоваться каким-то одним определением. В качестве такого определения предлагается пользоваться определением, которое дал комитет IEEE POSIX 1003.0 и которое дает широкую и исчерпывающую трактовку понятия открытых систем [5]:

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

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

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

Есть несколько причин тому, что определение IEEE PОSIX 1003.0 целесообразно взять за основу в рамках данного документа. Наиболее важной причиной служит то, что это определение было создано при участии представителей различных секторов индустрии информационных технологий - от поставщиков до пользователей.

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

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

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

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

1.1.3. Различные подходы к понятию "открытые системы".

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

1.1.3.1. Стандартные платформы.

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

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

1.1.3.2. Технология вычислительных сетей.

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

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

1.1.3.3. Источники возникновения продуктов открытых систем и способов обеспечения доступности.

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

Во-вторых, продукт, который имеет один источник, но который может идти на многих платформах. Так, графический пользовательский интерфейс Motif, поставляемый корпорацией Open System Foundation (OSF), представляет собой другой образец продукта, который может быть отнесен к открытым. Любой поставщик может купить лицензию на Motif для его перепродажи. Другим примером может служить операционная система UNIX, впервые предложенная AT&T, и теперь распространяемая и поддерживаемая UNIX System Laboratories (USL), которая является дочерней компанией AT&T. USL владеет правами на UNIX и контролирует процесс ее лицензирования. Продукты, построенные на базе ОС UNIX компании AT&T, можно получать из различных источников, включая как поставщиков технических средств, которые предлагают системы на базе UNIX, так и поставщиков программных средств, которые поставляют изделия для различных платформ. В обоих случаях поставщик может адаптировать базовый продукт к своей реализации.

Совсем другим примером является система управления базами данных (СУБД) ORACLE. Эта СУБД поставляется только самой фирмой Oracle Corporation либо поставщиками аппаратных средств, имеющими соглашение о кооперации с ORACLE. Однако система ORACLE используется очень широким разнообразием платформ различных поставщиков. В данном случае владельцы лицензий не имеют права изменять технологию ORACLE. Открытые системы часто сопоставляются с системами, на которые распространяются права собственности. В лучшем случае, это является заблуждением. В историческом и правовом смысле термин "собственность" указывает на то, что данный продукт принадлежит одной какой-либо компании и является предметом лицензирования и технического контроля с ее стороны. Это сегодня справедливо практически для всех продуктов, имеющихся на рынке. Например, AT&T контролирует операционную систему UNIX System V, компания Microsoft контролирует операционную систему MS DOS и т.д. То, что эти компании избрали путь лицензионного предоставления своей технологии за умеренную цену всем заинтересованным сторонам, можно приветствовать, но они вовсе не обязаны это делать. Более того, под единоличным контролем владельца оказывается зависимость от архитектуры, также как и последующее развитие интерфейсов к продукту.

1.1.4. Потенциальные возможности открытых систем и ограничения в открытых системах.

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

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

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

Имеются, однако, два ограничения, которые не позволяют этой кривой полностью приблизиться к теоретической (кривая 3, рис. 1.1).

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

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

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

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

1.1.5. Стандарты для открытых систем.

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

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

При этом различают стандарты де-факто и де-юре.

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

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

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

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

Детальную картину процесса получения стандартов и модель того, как этот процесс должен успешно реализоваться в современной индустрии информационных технологий можно получить из книги Information Technology Standardisation: Theory, Process, and Organisations, Carl F.Cargill [7].

1.2. Среда открытых систем.

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

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

1.2.1. Существующие модели открытых систем.

1.2.1.2. Модель MIC.

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

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

1.2.1.3. Модель OSE/RF.

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

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

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

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

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

К достоинству этой модели стоит отнести выделение внешней среды в самостоятельный элемент, с определенными функциями и соответствующими интерфейсами. Эта модель, в отличие от рассмотренных выше, описывает также и системы, построенные на основе архитектуры "клиент-сервер", которые сейчас получили широкое распространение.

1.2.1.4. Модель MUSIC.

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

Среди других моделей можно также отметить ряд специальных [6], т. е. проблемно ориентированных моделей. В частности, предлагаемая ISO модель ODP (Open Distributed Processing) - Открытая Распределенная Обработка - ориентирована, как следует из названия, на распределенную обработку в различных вычислительных сетях. Известны также модели CIM, EDI, Data Management DISC и др. Однако эти модели скорее можно отнести к Прототипным Профилям, о которых речь пойдет в п. 1.3.

1.2.2. Компоненты модели MUSIC.

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

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

Основные усилия в разработке и внедрении стандартов и спецификаций, обеспечивающих данную функциональную область, предпринимаются рядом международных и национальных организаций. ISO совместно с IEC в рамках концепции модели OSI/ISO разработала документ: ISO 7498-4 OSI Reference Model Part 4 [5] , Management Framework, который определяет структуру и основные функции для обеспечения системной администрации в рамках коммуникационных взаимодействий, описываемых моделью OSI. Документом определяются пять основных областей, являющихся объектами данной функциональной области: отказы и сбои, регистрация, управление конфигурацией, управление производительностью и безопасность. В рамках документа выпущен или находится в стадии разработки ряд стандартов:

Группой Internet также предпринимаются значительные усилия по созданию стандартов для управления и администрирования в сетях, использующих протоколы TCP/IP. Основой, определяющей концепции администрации в рамках TCP/IP, является документ RFC 1157 - Simple Network Management Protocol (SNMP). Концепция SNMP определяет сеть, как совокупность сетевых управляющих (management) станций и элементов сети (главные машины, шлюзы и маршрутизаторы, терминальные серверы), которые поддерживают административные свя- зи между сетевыми "управляющими станциями" и "сетевыми агентами".

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

К данной функциональной области относятся следующие документы SNMP Internet:

Протоколы SNMP основаны на спецификациях языка OSI Abstract Sintax Notation - ASN.1 (ISO 8224).

Одной из наиболее насущных задач сообщества сетей, входящих в Internet, является определение стратегии сосуществования TCP и OSI. Исследования в этой области ведутся обеими сторонами. Для решения этой проблемы существует несколько подходов. Спецификация RFC 1006 [15] - верхний уровень транспортной службы TCP (см. п. 1.2.2.5.) - обеспечивает пользователям Internet доступ к прикладным уровням OSI. Однако спецификации RFC не пригодны для взаимодействия через все уровни OSI.

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

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

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

Корпорация OSF (Open Software Foundation) также занимается проблемой системной администрации. OSF предложила свою архитектуру, которая получила наименование DME (Distributed Management Environment). DME должна обеспечивать согласованную поддержку для широкого диапазона систем от отдельных машин до больших распределенных неоднородных систем.

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

1.2.2.2. Пользовательский интерфейс (User Interface).

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

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

Один из примеров реализации функций, определяемых элементом "U" - это известный графический пользовательский интерфейс X Windows. Интерфейс представляет собой реализацию концепции обобщенного терминала, разработанной в рамках совместного проекта МТИ (Массачузетского Технологического Института), Digital Equipment Corp. и AT&T в течение 1985-1988 года. Система X Windows обеспечивает пользователю многооконный интерфейс, позволяя создать на одном устройстве в нескольких различных окнах виртуальные терминалы для разных заданий или программ. Интерфейс является "прозрачным" для сетей, он разрабатывался как машинонезависимый и принят в большинстве используемых сегодня операционных систем. В 1988 году был создан Х консорциум, объединивший основных производителей аппаратуры и программного обеспечения, поддержавших стандарт X Windows, который взял на себя поддержку его дальнейшей разработки, развития и сопровождения.

Технический комитет по компьютерной графике X3H3.6 ANSI выбрал оконный протокол системы X Windows и функциональный интерфейс X Lib в качестве исходных для создания своего стандарта пользовательского интерфейса. NIST одобрил в качестве национального стандарта США FIPS 158 протокол системы X Windows версии 11, X Lib, инструментальный пакет Xt. Компания X/Open также приняла основные компоненты системы X Windows как часть своей стандартной среды Common Applications Environment.

Ряд коммерческих продуктов также построены на основе системы X Windows. К числу таких продуктов относится графический пользовательский интерфейс OPEN Windows фирмы SUN Microsistem. Этот продукт создан по спецификации Open Look, разработанной совместно SUN Microsystems и AT&T.

На основе X Windows версии 11 создан также графический пользовательский интерфейс OSF/Motif. Корпорация OSF предоставляет этот интерфейс изготовителям аппаратных средств, разработчикам программного обеспечения и конечным пользователям.

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

1.2.2.3. Обслуживание в системе (Service interfaces for programs).

Этот элемент включает Интерфейсы для Прикладной Программы (API - Application Programming Interfaces), с помощью которых осуществляется прямое обращение к операционной системе, к управлению графическими средствами и стандартным языковым процессорам. Именно этот элемент наиболее сильно влияет на мобильность и представляет наибольший интерес для программистов.

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

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

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

Особенности ввода/вывода являются еще одним значительным свойством, по которому языки могут заметно отличаться. Так, для КОБОЛ'а и PL/1 характерен индексно-последовательный доступ к файлам (ISAM), однако для других языков стандартные способы доступа не определены. Языки также различаются по способам взаимодействия с пользователем.

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

Языковые процессоры разрабатываются уже давно и хорошо отработаны. Существуют стандарты на все широко используемые языки программирования. Так стандартом ISO 8652 описывается язык АДА. Имеются стандарты на языки Pascal, Fortran77, PL/1. Стандартом ISO 9899, описан язык С.

Графические пакеты представлены стандартом GKS, ISO 7942 1985 (двумерная графика), GKS -3D ISO 8805-1988 (трехмерная графика, PHIGS ISO 9592 (двумерная и трехмерная графика), а также библиотекой X Lib, входящей в состав уже упомянутой системы X Windows.

В таблице 1.1 приведены основные характеристики языков программирования и их статус как международных стандартов, в таблице 1.2 - отношение языков со стандартами ISO.

1.2.2.4. Обслуживание доступа к информации и форматы данных (Information and Data Formats).

Сюда же входят и средства, обеспечивающие объектно-ориентированное представление данных. Функции, объединяемые этим элементом, имеют решающее значение для обеспечения интероперабельности в открытой (и в распределенной) системе. В рамках элемента "I" обращение к файловой системе, в частности, может осуществляться через систему IRDS (Data Depository and Management System). Система обеспечивает разделение доступа к файлам между различными заданиями как на локальной ЭВМ, так и через сеть.

Наиболее известным и широко используемым стандартом, регламентирующим способы доступа к базам данных, является язык SQL. Существующий стандарт ISO 9075-1989 с дополнением ANSI X3.168 определяет SQL интерфейс для всех основных языков программирования. SQL обеспечивает доступ к СУБД ORACLE, Ingres, SYBASE и другим.

1.2.2.5. Коммуникационные интерфейсы (Communications interfaces).

Одним из наиболее значительных достижений информационных технологий в девяностых годах является создание глобальных коммуникационных сетей, которые предоставляют возможность обмена информацией между разнородными вычислительными и информационными системами. В этой области за прошедшее десятилетие возник ряд решений, поддержанных в той или иной степени международными стандартизующими организациями. Два их них, которые стали наиболее известными: это модель ВОС (OSI) и протокол TCP/IP (Transmission Control Protocol/Internet Protocol).

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

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

С точки зрения пользователя нижние уровни модели относятся к типу применяемой локальной сети: Ethernet, Token Ring, FDDI и т.д., а верхние уровни к таким службам, как передача файлов (стандарт FTAM), электронная почта (X.400), каталогизация удаленных данных (X.500).

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

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

Протокол TCP/IP (Internet) был разработан как набор функциональных стандартов для военных сетей Соединенных Штатов и стал общепринятым индустриальным стандартом де-факто. TCP/IP предоставляет средства, определяемые транспортным уровнем модели OSI, и ряд функций, обслуживающих пакетные передачи данных (почта, передача файлов). TCP/IP организован как многоуровневая структура протоколов более низкого уровня, которые определяют функции низкого уровня, используемые прикладными программами. Ряд протоколов используется для выполнения особых функций. Также как и в модели OSI, функции TCP/IP группируются по независимым уровням. Существует четыре таких уровня: уровень сетевого доступа, межсетевой уровень, уровень межмашинного (host-to-host) взаимодействия и уровень процессов. Каждый уровень состоит из взаимосвязанных и управляемых заданий и обеспечивает взаимодействие со смежными уровнями.

Элементы модели MUSIC имеют различную функциональную нагрузку и в этом смысле неэквивалентны. Так, например, компоненты элемента M, в общем случае, не будут непосредственно взаимодействовать с прикладной программой, в отличие от элемента I, для которого такое взаимодействие будет иметь постоянный характер. Пользовательский интерфейс (элемент U), элементы I и C связаны с внешней средой (пользователи, сети, сетевые файловые серверы), а элемент S - связывает непосредственно данную ЭВМ (аппаратура и системное обеспечение) и прикладную программу.

Большая часть известных программных продуктов и соответствующих стандартов не укладывается в точности в рамки, ограничивающие элементы MUSIC или любой другой модели. Большинство программных продуктов включает компоненты более, чем одного элемента и одиночный стандарт также сочетает функции нескольких элементов. Так стандарт SQL, описывающий интерфейсы систем управления базами данных (СУБД), может быть определен как стандарт элемента "S", как сервисный интерфейс. С другой стороны, этот же стандарт можно отнести и к элементу "I", поскольку он обеспечивает доступ к данным.

К числу стандартов, обеспечивающих функции элемента "U" ( интерфейс пользователя), относится язык SHELL операционной системы UNIX. Однако SHELL представляет собой и программный интерфейс, с помощью которого обеспечивается обращение к службам операционной системы из программ. Таким образом, SHELL входит также и в элемент "S".

Подобная ситуация возникает и со стандартом графического пользовательского интерфейса X Windows. Входящая в состав X Windows графическая библиотека X Lib также обеспечивает графический вывод из прикладной программы. Таким образом, X Windows удовлетворяет не только элементу "U", но и обеспечивает часть функций, определяемых элементом "S".

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