9.Понятие об открытых системах

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

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

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

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

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

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

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

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

Следующий этап в развитии концепции открытости - это вторая половина семидесятых годов. Он связан с областью интерактивной обработки и увеличением объема продуктов, для которых требуется переносимость (пакеты для инженерной графики, системы автоматизации проектирования, базы данных). В это время фирма DIGITAL начала выпуск супермини-ЭВМ VAX, работающих под управлением операционной системы VMS. ЭВМ этой серии имели уже 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.

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

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

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

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

• - Большинство машинных команд исполняется за один машинный цикл.

• - Регистровая архитектура: все команды обработки выбирают операнды и помещают результаты только в регистрах. Обращение к ОЗУ производится только командами чтения/записи.

• Конвейерная обработка команд, которая позволяет исполнять несколько команд одновременно.

• Простой фиксированный формат команд с небольшим количеством методов адресации ОЗУ.

• Наличие быстродействующей памяти: любая RISC машина имеет, по крайней мере, 32 регистра общего назначения и большую кэш-память.

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

Эти особенности приводят к тому, что сложные многошаговые функции перемещаются в область программной реализации. В результате, ручное программирование становится малоэффективным и основную роль начинают играть языки высокого уровня. Исполняемый машинный код становится длиннее и требует ОЗУ большего объема, чего так стремились избежать разработчики традиционных CISC ЭВМ, поскольку тогда стоимость ОЗУ была высокой. Однако стоимость оперативной памяти в течение последнего десятилетия очень быстро уменьшается и к середине восьмидесятых годов экономически приемлемой становится оперативная память объемом в единицы Мегабайт (даже для небольших персональных ЭВМ), и размеры исполняемого кода уже не ограничивают применение RISC процессоров. Характерная для архитектуры RISC элементарность набора команд позволяет приблизить эффективность программ, написанных на языках высокого уровня, к эффективности программ в машинном коде и автоматизировать процесс настройки программ для их оптимизации. В результате, использование стандартных компиляторов, сделало возможным обеспечить на уровне языков высокого уровня эффективную мобильность программ. RISC процессоры обеспечили идеальные условия и для массового внедрения операционной системы (ОС) UNIX.

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

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

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

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

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

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

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

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

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